komixí noviny 2008/2009

S tím souvisí i to, že vy-

hledáváme zákazní-

ky, kteří chtějí inovo-

vat, kteří chtějí dělat

svůj business jinak než

konkurence. Pochopi-

telně při tom nemů-

žeme zůstat stranou

dění ve státní správě,

kdy se zákazník s nej-

větším IT budgetem

v republice rozhodl přihlásit k trendům e-govern-

mentu a investovat do rozsáhlého využití IT tech-

nologií ve prospěch občanů a zjednodušení jejich

komunikace se státem. Probíhající reformy vyvo-

lávají též rozsáhlé změny stávajících informačních

systémů.

KOMIX se v roli subdodavatele softwarového ře-

šení účastní na integračních projektech, podporu-

jících začlenění České republiky do Evropské unie,

další týmy pracují na podpoře reforem nemocen-

ského a důchodového pojištění a zdravotní reforma

zase vyvolává tlak na úpravy informačních systémů

zdravotních pojišťoven, pro které také pracujeme.

Jsem hrdý na to, že naši pracovníci opakovaně do-

kazují, že jsou schopni spolehlivě realizovat tyto

rozsáhlé a často i rizikové projekty.

Naši specialisté dnes působí i na projektech mimo

Českou republiku – v Polsku, Maďarsku, Bulharsku

nebo Německu.

V uplynulém roce KOMIX uvedl na český IT trh i ně-

kolik novinek založených na moderních technolo-

giích. Námi uváděné produkty se dostaly do finále

soutěže o IT produkt roku jak v roce 2007, tak v roce

2008. Jedná se o programové vybavení pro podpo-

ru prodejních týmů od německé společnosti CAS

genesisWorld (CRM) a CAS teamWorks nebo o pro-

dukt z oblasti bezpečnosti společnosti KOBIL či ná-

stroj QlikView pro rychlou analýzu dat pro podpo-

ru manažerského rozhodování raketově rostoucího

start-upu QlikTech.

Na přelomu roku 2008 a 2009 budeme moci nabíd-

nout CAS genesisWorld i v hostované verzi. Tj. KO-

MIX zajistí kompletní provoz aplikace na své tech-

nice a zákazník si ji bude moci pouze pronajmout.

Potřebuje k tomu jen dobré internetové propojení.

Stejnou službu již dnes poskytujeme se softwaro-

vým vybavením pro Service Desk. Uvažujete-li tedy

o změně obchodních procesů nebo chcete svým

zákazníkům poskytovat podporu v souladu s náro-

ky norem ISO nemusíte začínat rozsáhlou investicí

do softwarové podpory, tuto službu si můžete pro-

najmout.

Začtete-li se do příspěvků v těchto novinách, jis-

tě poznáte, že KOMIX disponuje poměrně rozsáh-

lým know-how z řady oborů. To vidím jako velikou

přednost naší společnosti, která nám umožňuje ře-

šit i složité situace a problémy. Na řadě projektů

jsme prokázali, že jsme schopni i v průběhu pro-

jektu nalézt a aplikovat nové technologické prv-

ky nebo postupy a s jejich pomocí realizovat řešení

splňující požadavky zákazníka.

Na závěr svého textu bych se chtěl vrátit k jed-

né myšlence zmíněné v úvodu. KOMIX nabízí ře-

šení vytvářená na míru, a proto hledáme zákazní-

ky, kteří chtějí spolu s námi vytvářet něco nového,

užitečného, co jim pomůže v jejich práci, v rozvinu-

tí obchodu nebo zkvalitnění služeb. Máte-li něja-

ký nápad, jak něco změnit, inovovat, zavést novou

službu nebo naopak vidíte problém a chtěli bys-

te s někým diskutovat jeho řešení, prosím napište

na adresu napad@komix.cz. Zkusme problémy ře-

šit společně!

Petr Kučera

Vážení čtenáři,

KOMIX v roce 2008 vstupuje do sedmnáctého roku svého působení na trhu. Za tu dobu se několikrát

změnila vnitřní organizace, výrazně se změnila struktura obratu – klesl významný podíl hardware

a licencí a naopak podstatným způsobem vzrostl podíl služeb. Od svého založení však KOMIX

zůstává společností, která sleduje vývoj IT technologií a osvojuje si ty progresivní, aby svým

zákazníkům mohla nabídnout moderní aplikace, které jim přinesou konkurenční výhodu.

Iterační vývojZákladní myšlenka iteračního vývoje je jednodu-

chá: realizaci díla rozdělíme do kratších etap (ty-

pická délka 1-4 týdny) nazývaných iterace. V rámci

každé z nich musí vzniknout funkční verze softwa-

ru, kterou lze potenciálně předat zákazníkovi k ově-

ření a používání. Běžně se nenasazuje do provozu

nová verze po každé iteraci, ale vždy po několika

iteracích dle dohody se zákazníkem.

Hlavní důvodem pro tento postup je rychlé získání

zpětné vazby od zákazníka při skutečném užívání

systému. Jedině tak lze plnohodnotně ověřit, že vy-

tvořený systém odpovídá jeho potřebám. Předchá-

zí se tomu, že bude vytvořeno velké množství funk-

cí, které v okamžiku nasazení do provozu již nejsou

potřeba. Proto se funkce zařazované do jednotli-

vých iterací vybírají podle priority stanovené zákaz-

níkem. Zrealizuje se primárně to, co zákazník nejví-

ce potřebuje, a pak na základě zkušeností z provozu

se řeší, jakými funkcemi se bude pokračovat dále.

Použití na CDBP1. i 2. etapa projektu CDBP byly založeny na stan-

dardním vodopádovém vývojovém cyklu. Na po-

čátku je celková analýza, po které následuje návrh,

obé zakončené akceptačním řízením vytvořených

dokumentů. Na tyto fáze navazuje vlastní konstruk-

ce (programování). Vzhledem k nedostatku času

na realizaci (jak typické pro projekty tohoto typu)

se uvedené tři fáze částečně překrývaly, jinak by

ITerační VýVOj V PraXIIterační (někdy také přírůstkový) vývoj je výrazným a důležitým rysem moderních přístupů k tvor-

bě softwaru. Tento článek popisuje použití iterační metody v rámci interního vývoje a testování

na projektu CDBP (biometrické pasy).

2

systém nemohl vzniknout v potřebných termínech.

Následuje rozsáhlé testování, které se skládá z in-

terních testů uvnitř jednotlivých týmů, integrač-

ních testů mezi zúčastněnými dodavateli, nezávis-

lých testů, které realizuje třetí subjekt, a konečně

testů akceptačních, při kterých zákazník schvaluje

vytvořený systém.

Ve 2. etapě projektu CDBP, realizované v průběhu

roku 2008, jsme se v rámci konstrukční fáze pro-

jektu rozhodli ověřit použití iterační metody pro

programování a interní testování. Princip metody

zachycuje Ganttův diagram na obrázku. Zjedno-

dušeně řečeno: Konstrukční práce jsou rozdělené

do 2-týdenních iterací, na každou z nich navazuje

zhruba týden testování nově vytvořených funkcí.

Vzhledem k tomu, že 2. etapa projektu CDBP je roz-

vojem již existujícího a funkčního systému, není po-

užití iterační metody problematické. U nově vzni-

kajícího systému by bylo potřeba počítat s úvodní

„náběhovou“ fází, kdy ještě není nic hotovo a testo-

vání je zpočátku poněkud složitější.

Popis metodyPodívejme se na jednotlivé kroky podrobněji. Kaž-

dá iterace je zahájena detailním naplánováním kon-

strukčních prací v dané iteraci. Tuto činnost prová-

dí vedoucí programátor s ohledem na dlouhodobý

postup prací, příp. aktuální priority. Jednotlivým

programátorům jsou přiřazeny dílčí úkoly, z nichž

žádný svým rozsahem nesmí přesahovat dobu tr-

vání jedné iterace (tj. musí být reálné je v rámci

dané iterace dokončit).

Následují 2 týdny konstrukčních prací, jejichž sou-

částí má být také vytvoření vývojářských testů (unit

testy apod.). Po ukončení programování je vytvoře-

na nová verze softwaru a je připravena do testova-

cího prostředí. Programátoři napíší stručné shrnu-

tí ke způsobu řešení jednotlivých úkolů, což slouží

mj. jako podklad pro testování či tvorbu dokumen-

tace.

V průběhu druhého týdne konstrukce se připravu-

jí testovací scénáře pro nově vznika-

jící funkce, na základě kterých bude

ověřena jejich kvalita a soulad se za-

dáním. Vedoucí testování následně

naplánuje průběh testování a přiřadí

jednotlivým testerům dílčí úkoly.

Ve 3. týdnu probíhá testování. Nejpr-

ve je snahou najít fatální problémy,

které znemožňují další postup testo-

vacích prací. Takové chyby jsou ihned

opraveny. Chyby menšího rázu jsou

pouze evidovány a jejich oprava je

provedena v rámci vývojových prací

další konstrukční iterace, která je za-

hájena paralelně s testováním. Retest

opravených chyb se pak provádí při

dalším kole testování.

V týdnu, kdy probíhá testování, se rovněž aktuali-

zuje dokumentace v rozsahu, který odpovídá nově

implementovaným funkcím. Tato průběžná aktuali-

zace po každé iteraci se týká především systémové

dokumentace. Uživatelské příručky jsou aktualizo-

vány později v odděleném režimu především v zá-

vislosti na tom, zda se již nemění uživatelské roz-

hraní aplikací. Vzhledem k tomu, že dokumentaci

považujeme za plnohodnotnou součást dodávky,

je rovněž podrobována ověření kvality ze strany

testerů. Po ukončení konstrukčních a testovacích

prací je provedeno zhodnocení dokončené itera-

ce a řeší se např. optimalizace pracovních postupů,

aby lépe reflektovaly získané praktické zkušenosti.

Jak již bylo uvedeno (a je patrno i z obrázku), testo-

vací práce probíhají paralelně s konstrukčními pra-

cemi další iterace. V rámci plánování iterací musí

tedy vedoucí programátor zohlednit skutečnost, že

se při testování objevují chyby, které je třeba ihned

(u fatálních chyb) či v rámci další iterace opravit.

Podpůrné nástrojePro podporu výše popsaného iteračního režimu

práce používáme na projektu CDBP 2 nástroje:

MS Excel a ProjectX. Pomocí MS Excel se evidu-

je ucelený seznam funkcí, které je třeba vytvo-

řit, a plán jejich realizace v jednotlivých iteracích.

U každé funkce je uveden stručný popis, odhado-

vaná pracnost, plánované zařazení do iterace a pro-

gramátor, který bude funkci realizovat. Je zde ob-

sažen jak dlouhodobý orientační plán, tak přesný

plán na nejbližší jednu či dvě iterace. Pomocí agre-

gačních funkcí MS Excel lze poměrně snadno zob-

razit např. plán vytížení jednotlivých programátorů

nebo odhad dokončení prací na konci jednotlivých

iterací.

V nástroji ProjectX, který se na CDBP obecně využí-

vá pro evidenci úkolů, jsou průběžně zadávány čin-

nosti vyplývající z obsahu jednotlivých iterací pro

programátory i testery. Rovněž sem mohou být

doplňovány podrobnější údaje k řešení úkolů, ko-

mentáře programátorů, resp. testerů, podklady pro

tvorbu dokumentace apod. ProjectX je v rámci in-

terního testování používán také pro evidenci chyb.

Očekávané přínosyCíle, které sledujeme při použití popsané iterační

metody, jsou následující:

• Průběžnákontrolavytvořenéhosoftwaru,rychlá

„zpětná“ vazba od testerů, kteří de facto zastupu-

jí cílové uživatele systému. Chyby v nově vytvo-

řených funkcích se řeší v době, kdy programátoři

mají vše ještě v čerstvé paměti.

• Lepšípřehledoskutečnémpostupuprací–coje

otestováno a opraveno, lze považovat za dokon-

čené. Z praktických zkušeností totiž vyplývá, že

konstrukční práce není možné považovat za ho-

tové, pokud neproběhlo testování.

• Rytmus a řád ve fungování celého týmu, a tím

zvýšení efektivity práce týmu. Pozitivně se to

projevuje především ve vztahu mezi vývojáři

a testery.

• Vícečasunatestování,protožetestováníjevlast-

ně přirozenou součástí konstrukčních prací

od počátku vývoje. Díky tomu také očekáváme

méně problémů a stresu v závěrečném testová-

ní po ukončení konstrukčních prací. Negativním

(z hlediska nákladů) důsledkem může být v cel-

kovém souhrnu zvýšená pracnost testování.

ZhodnoceníKonečné zhodnocení a shrnutí zkušeností bude

provedeno až na konci projektu, kdy bude mož-

né ověřit, jaký měl použitý přístup dopad na nejen

na konstrukční, ale také na návazné fáze projektu,

a zejména na kvalitu díla. Po zhruba 6 vývojových

iteracích se však zdá, že použití iterační metody

bude plnit výše uvedené cíle, a přispěje tak k hlad-

šímu průběhu po organizační stránce dosti nároč-

ného projektu.

Petr Sobotka

sobotka@komix.cz

3

Přistoupení České republiky do Evropské unie dalo

českým firmám možnost podílet se na evropských

orientovaných aktivitách a využívat pro rozvojové

projekty jejích fondů. Jedním z projektů financova-

ných EU je i projekt Village. Na projektu Village se

podílí 8 členů z 5 evropských zemí, které jsou sdru-

žené do projektového konsorcia. Členové konsor-

cia se pravidelně scházejí, vyhodnocují jednotlivé

projektové mezníky a společným úsilím se podí-

lí na jeho směřování k dosažení projektového cíle.

Členem konsorcia je i KOMIX, který hraje v projek-

tu Village roli plnoprávného člena. V červnu 2008

jsme v rámci projektu úspěšně hostili dvoudenní

Project Meeting Board, kterého se zúčastnili všich-

ni členové konsorcia.

Hlavním cílem projektu Village je rozvinout koope-

rativní CRM poskytované ve formě služby zacílené

pro trh malých a středních podniků. Plánovaným

výsledkem projektu je technické řešení, které bude

odpovídat stávajícím a budoucím platným para-

digmatům trhu, kde je CRM poskytováno ve formě

Vývojový plán společnosti CAS Software AG garan-

tuje každoročně vydání nové verze CRM aplikace

CAS genesisWorld. Nové verze vychází každoročně

vždy v létě. Letošní nová verze se vyznačuje celou

řadou novinek, které se neomezují pouze na tech-

nické inovace.

Největší změnou pro zákazníky je nový licenční sys-

tém. CAS genesisWorld je nyní prodáván ve třech

edicích Standard, Premium a vše zahrnující Sui-

te. Rozdělení CAS genesisWorld na jednotlivé edi-

ce bylo způsobeno množstvím nových funkcí, kte-

ré byly do systému zahrnuty.

Kromě zmíněných edic disponuje nyní CAS gene-

sisWorld novými moduly. Mezi tyto moduly patří

CAS Marketing, CAS Sales, CAS Reports, CAS Pro-

jects, CAS Helpdesk, CAS Timeclient, CAS Mobile

CRM for Blackberry.

SaaS (Software as a Service). SaaS je způsob využí-

vání počítačových aplikací, kdy se intenzivně využí-

vá provozovatelem služby hostovaná aplikace. Vý-

hody modelu SaaS představují pro zákazníky rychlé

nasazení produktu, nízké náklady na správu IT, od-

stranění nutnosti správy hardware a vyčlenění dal-

ších služeb mimo zákazníka používající CRM. Využí-

vání SaaS nabývá celosvětově stále větší popularity

a je jednoznačně jedním ze silných trendů svědčí-

cím o budoucích způsobech využívání prostředí In-

ternetu pro byznys účely.

Pro české a slovenské zákazníky představuje účast

KOMIXu v projektu Village příslib brzkého předsta-

vení technologicky i obchodně zcela nově pojaté-

ho řešení pro správu jejich CRM aktivit.

Chcete vědět více? Navštivte www stránky projektu

na adrese http://www.village-project.eu/village/

Miroslav Žebrák

zebrak@komix.cz

Především CAS Marketing přináší dlouho očekáva-

nou změnu v práci s kampaněmi, grafické navrho-

vání work-flow kampaní, definice následných akcí

a vyhodnocení úspěšnosti jednotlivých marketin-

gových akcí přináší do marketingového oddělení

zvýšenou efektivitu. CAS Sales umožňuje řízení ob-

chodních zástupců nad rámec standardního sledo-

vání obchodních příležitostí s důrazem sledování

výkonnosti jednotlivých obchodních zástupců.

CAS Helpdesk a CAS Timeclient přidávají do pro-

středí CAS genesisWorld nové typy informací. V pří-

KOMIX sPOluVyTVáří PrOjeKT eu

nOVInKy V Cas genesIsWOrlD VerZe 10

4

V roce 2008 vyhlásila redakce časopisu Compu-

terWorld druhý ročník soutěže o IT produkt roku.

Podmínky soutěže umožňovaly přihlásit jakéko-

li zařízení, software, řešení nebo službu z oblasti in-

formačních a komunikačních technologií, jež lze vy-

užít v podnikovém prostředí. Produkt, respektive

jeho přihlašovaná verze, nesměl být na trhu déle jak

od 15. srpna 2007. Základními kategoriemi soutěže

byly zvoleny: software, hardware, řešení a služba.

Soutěž ComputerWorld IT produkt roku 2008 je ví-

cekolová, v hodnotících kritériích je kladen důraz

na inovativnost řešení, které může spočívat v celku,

v detailech a na míru pozitivního odlišení od po-

dobných konkurenčních produktů. Produkty spl-

ňující uvedená kritéria v dostatečné míře postupu-

jí do finále. V rámci finále dojde k výběru vítězného

produktu v každé kategorii.

KOMIX přihlásil do soutěže 3 produkty a výsled-

ky jsou pro KOMIX velmi příjemné, neboť hned

všechny 3 produkty uspěly a postoupily do první-

ho finálového kola. V kategorii Podnikový systém se

o úspěch postaral CRM systém od společnosti CAS

Software - Cas genesisWorld ve verzi 9 a systém

pro řízení a plánování kapacit od společnosti Hy-

performix - IPs Performance Optimizer. V katego-

rii Informační systémy postoupilo portálové řešení

pro týmovou spolupráci od společnosti CAS Soft-

ware AG - Cas teamWorks ve verzi 6.

Celkem třikrát se KOMIX může v roce 2008 pyšnit

logem ComputerWorld IT produkt roku. Pojďme si

tedy naše úspěšné finalisty blíže představit.

IPs Performance Optimizer slouží k modelová-

ní budoucí výkonnosti IT systémů, plánování jejich

změn a rozvoje na základě dat z monitoringu tes-

tovacího či produkčního prostředí. Umožňuje od-

halit problémová místa systému a najít způsob je-

jich odstranění při minimalizaci zákroků v reálném

prostředí. Jednotlivé modely jsou vyhodnocovány

z hlediska dostatečnosti výkonu a splnění finanč-

ních omezení. Typické je nasazení pro extrapolaci

výstupů zátěžových testů provedených ve zmenše-

ném testovacím prostředí na produkční prostředí,

kde zátěžové testy nelze provádět.

Cas genesisWorld představuje CRM řešení pro

správu adres, projektů, dokumentů, úkolů a dalších

aktivit nejen marketingového a obchodního oddě-

lení. Jeho hlavním úkolem je zvýšit efektivitu pro-

dejních a marketingových aktivit, přičemž CAS ge-

nesisWorld pomáhá k dosažení cíle za použití celé

řady uživatelsky přívětivých funkcí a s pomocí pro-

pojování informací přináší 360stupňový pohled

na zákazníka. CAS genesisWorld umožňuje práci

v kanceláři, on-line v terénu, ale i off-line s pomo-

cí tzv. replikace dat. Velmi dobrou vlastností CAS

genesisWorld je rychlá implementace a velmi sil-

COMPuTerWOrlD IT PrODuKT rOKu 2008

padě CAS HelpDesku pracuje zákazník v prostředí

speciální www aplikace, informace jsou však přene-

seny do prostředí CRM a k dispozici jeho uživate-

lům. CAS HelpDesk disponuje takovými funkcemi,

jako jsou notifikace o změnách v trouble tiketech,

úrovni poskytovaných služeb dle SLA, historii ře-

šení jednotlivých problémů apod. CAS Timeclient

je vhodným doplňkem všude tam, kde je potřeba

vykazovat pracovní čas na vyšší úrovni detailu. Při-

řazování času jednotlivým projektům a úkolům je

vhodným doplňkem k modulu CAS Projects. CAS

Timeclient disponuje vlastním www rozhraním,

které umožňuje vykazovat časy i mobilním zaměst-

nancům.

Novinky postihly i oblast mobility. CAS Mobile-

Access a CAS WebAccess jsou nyní součástí edice

CAS genesisWorld Premium edition, k dispozici je

nyní nový modul CAS MobileCRM pro Blackberry.

Na rozdíl od standardního modulu CAS MobileAc-

cess mohou mobilní uživatelé s přístroji Blackberry

využívat výhod PUSH technologie.

CAS genesisWorld nabízí i branžová řešení. Zákaz-

níci mohou profitovat ze speciálně upravených edic

aplikace, které umožňují rychlou implementaci,

spuštění a speciální funkce pro jejich odvětví. V loň-

ském roce byl vydán CAS Drive, branžové řešení pro

dealery automobilů umožňující napojení na dealer-

ské systémy a snadné mapování nabídek a poptá-

vek po automobilech. CAS genesisWorld ve verzi 10

přidává nová branžová řešení CAS IT Services, CAS

Consulting, CAS Engineering a CAS Research.

Mottem nové verze CAS genesisWorld bylo nabíd-

nout uživatelům drobná vylepšení, která lze vyu-

žít zejména v každodenní práci. Spolu s novou ver-

zí CAS genesisWorld 10 získají nově čeští zákazníci

jako dárek lokalizaci oblíbeného bezplatného ná-

stroje CAS Info@Click. CAS Info@Click umožňuje

rychlé vyhledávání v adresách CAS genesisWorld,

synchronizaci adres, úkolů, schůzek s Microsoft

Outlookem, ale také třeba s Google kalendářem.

Mezi zajímavé funkce CAS Info@Click patří i mož-

nost využití VoIP klientů jako je např. Skype či we-

bové telefonie s telefonními čísly uloženými v CAS

genesisWorld.

CAS genesisWorld verze 10 je k dispozici od 1. 8.

2008, česká verze je plánována na prvního čtvrtle-

tí 2009. Spolu s novou verzí CAS genesisWorld byla

vydána i nová v pořadí již sedmá verze oblíbeného

groupwarového nástroje.

Miroslav Žebrák

zebrak@komix.cz

né možnosti přizpůsobení aplikace, bez nutnosti

úprav aplikace programátory.

Cas teamWorks přináší přidanou hodnotu zejmé-

na pro použití ve skupinové spolupráci. Sdílení ka-

lendáře, plánování a delegování úkolů, přehled

o vnitropodnikových procesech, realizovaných

projektech, zobrazení zodpovědností, pravomo-

cí a práce dle předem vytvořených checklistů jsou

jeho silnými stránkami. CAS teamWorks umožňu-

je správu služebních cest, evidenci klíčů, místnos-

tí, automobilů a dalších praktických požadavků.

Uživatel pro práci potřebuje pouze prohlížeč www

stránek. CAS teamWorks může být nasazen spo-

lu s CAS genesisWorld. Současné nasazení přináší

synergické efekty využití společné datové základ-

ny a sdílení informací v back-office i front-office čás-

ti společnosti.

Miroslav Žebrák

zebrak@komix.cz

5

Během posledních let se oblast řízení portfolia

(PPM - Project Portfolio Management) těší rostoucí-

mu zájmu. Řada firem spojila svoji snahu o zvyšová-

ní efektivnosti právě s tímto druhem řízení a poza-

du nezůstávají ani výrobci softwaru, kteří na tento

trend reagují uváděním stále dokonalejších nástro-

jů. Dnešní PPM aplikace disponují širokou funkcio-

nalitou vycházející z všeobecně uznávaných stan-

dardů projektového řízení a poskytují tak svým

uživatelům dostatečnou podporu pro správu jejich

projektů. Přesto se stále můžeme setkat s řadou ne-

úspěšných implementací a skutečný přínos z užívá-

ní PPM dokáže vyčíslit jen opravdu málokdo. Nabízí

se zde tedy otázka, zda jsou současné aplikace sku-

tečně tak dobré, jak jejich výrobci proklamují a jest-

liže ano, proč jejich zavádění nepřináší očekávané

výsledky? Odpověď je jednoduchá. PPM není pou-

ze software.

Podíváme-li se na problematiku portfolio mana-

gementu blíže, zjistíme, že se jedná o velmi kom-

plexní oblast, do které je při správném využití za-

pojeno množství subjektů napříč celou organizací.

A s množstvím subjektů souvisí také celá řada fakto-

rů, které mohou implementaci ovlivnit. V následují-

cích odstavcích jsou uvedeny některé z nejdůleži-

tějších faktorů, které je nutné vzít při implementaci

portfolio managementu v úvahu.

skutečný rozsah projektuJednou z prvních chyb při posuzování realizace,

zda řízení portfolia zavádět, jsou mylné představy

o rozsahu takového projektu. Projekty implemen-

tace PPM jsou již ze své podstaty velmi obsáhlé

a konkrétní dopady na organizaci závisí především

na rozsahu, jakým je ve firmě využíváno projek-

tového řízení. Ve společnostech, kde jsou formou

projektů realizovány kromě podpůrných také hlav-

ní činnosti společnosti, se z implementace PPM stá-

vá celopodniková záležitost ovlivňující prakticky

veškeré činnosti a zdroje. V takových případech je

nutné postupovat s adekvátní obezřetností a vě-

novat projektu náležitou pozornost. Vysoká priori-

ta, správné naplánování, zajištění dostatku zdrojů

nebo dostatečně zkušený projektový manažer jsou

jen příklady aspektů, na které by nemělo být zapo-

mínáno. Zároveň je nutné vzít v úvahu ostatní pro-

bíhající akce a činnosti, aby nedošlo k neúměrnému

zatížení společnosti.

Podpora vedeníPokud bychom sestavovali žebříček nejvýznam-

nějších faktorů rozhodujících o úspěchu či neúspě-

chu jakéhokoliv projektu, kvalitní podpora ze stra-

ny vrcholového vedení by zcela jistě obsadila jedno

z předních míst. Její význam se ještě zvyšuje v přípa-

dě rozsáhlých a dlouhodobých projektů, u kterých

hrozí vznik pocitu marnosti a nedosažitelnosti sta-

novených cílů. Kromě tohoto jde při zavádění PPM

ještě o další, neméně důležitý aspekt. Řízení port-

folia je primárně zaměřeno na vyšší úroveň řízení,

kam také směřují jeho hlavní přínosy. Svým charak-

terem ovšem zásadně ovlivňuje práci managerů

prakticky na všech úrovních a vyžaduje od nich in-

tenzivní spolupráci často bez adekvátních přínosů.

Lehce se tak může stát, že zejména v řadách projek-

tových managerů je implementace PPM vnímána

jako něco, co pouze přidělává práci a nepřináší žád-

né výhody. Následuje chladný a odměřený přístup,

který k celkové úspěšnosti projektu zcela jistě ne-

přidá. Právě v takových chvílích je na managemen-

tu firmy, aby převzal iniciativu a svým entusiasmem

podpořil realizaci projektu. Každý budoucí uživatel

by měl být seznámen nejen s důvody a cíli projek-

tu, ale také se způsobem, jakým právě on přispívá

k realizaci celkových přínosů.

Zapojení klíčových uživatelůDalším, neméně důležitým aspektem při zavádě-

ní portfolio managementu je zapojení klíčových

uživatelů a správná distribuce pravomocí a odpo-

vědností. Jak již bylo zmíněno výše, cílová oblast

směřování hlavních přínosů PPM spadá mezi vyš-

ší management. Zde ovšem narážíme na problém

vysokého vytížení jednotlivých managerů, kte-

ří vzhledem k množství svých povinností často ani

nejsou schopni věnovat projektu náležitou pozor-

nost. Výsledkem bývá laxní přístup k projektu nebo

delegování odpovědnosti na nižší stupně řízení. Ta-

kové chování je však krajně nevhodné. Jsou to to-

tiž pouze příslušní vedoucí pracovníci, kteří by měli

definovat základní požadavky a kvalifikovaně roz-

hodnout o jejich úspěšném dosažení. Účinnou me-

todou jak dosáhnout, aby zapojení klíčových uživa-

telů nezůstalo pouze na formální rovině, je navázat

spolupráci na projektu na systém motivací a odmě-

ňování. V řadě případů je to jediné možné řešení jak

dosáhnout, aby se budoucích uživatelé sami zají-

mali o projekt a osobně byli zainteresováni na jeho

hladkém průběhu.

Celková zralost organizaceJsou projekty, které může realizovat prakticky kte-

rákoli organizace, a pak jsou projekty, k jejichž reali-

zaci je zapotřebí splnění řady vstupních předpokla-

dů. Implementace PPM patří bezpochyby do druhé

skupiny. Řízení portfolia je úzce spojeno s projekto-

vým řízením. Tvoří vlastně jeho logickou nadstav-

bu. Z pohledu úspěšnosti tak množství přínosů do-

sažených implementací portfolio managementu

přímo souvisí se stupněm vyzrálosti firmy v oblas-

ti řízení projektů. Jinými slovy, k tomu, abychom

mohli efektivně řídit portfolio, potřebujeme do-

statečně kvalitní základy v podobě všeobecně ak-

ceptovaných a používaných procesů projektového

řízení a v neposlední řadě také zkušené uživatele.

Tato podmínka, jakkoli se může zdát triviální, bývá

velmi často podceňována. Jedním z hlavních příno-

sů zavedení PPM je sjednocení postupů a zvýšení

míry standardizace napříč celou organizací. V pří-

padě nedostatečně vyzrálých procesů se však tato

výhoda může rychle změnit v nepříjemnou překáž-

ku a z implementace se stává pouze bezpředmětná

sbírka výjimek a změnových řízení.

Výběr aplikaceÚlohu výběru vhodné aplikace nelze samozřejmě

zcela opominout. Právě naopak, správným výbě-

rem je možné implementaci PPM podstatným způ-

sobem usnadnit a předejít řadě problémů. Ze zku-

šenosti se ukazuje, že spíše než množství funkcí je

při výběru dobré klást důraz na schopnost aplika-

ce přizpůsobit se specifickým požadavkům a také

možnost napojení na ostatní používané systémy.

Typicky se jedná o možnosti integrace se služba-

mi Service Desku, HR systémy, ERP systémy nebo

lokálně používanými plánovači projektů. Kvalitní

software by měl být především schopen přizpůso-

bit se vnitřnímu fungování organizace a akceptovat

nastavení jejích procesů. Na druhou stranu je třeba

mít na paměti, že každá PPM aplikace částečně ob-

sahuje i vlastní know-how, jak by proces řízení port-

folia měl vypadat. Nerespektování těchto pravidel

a přílišnou kustomizací může dojít k narušení vnitř-

ní filozofie aplikace, což se negativně projeví na vý-

konu a kvalitě poskytovaných služeb.

Účelem tohoto článku nebylo přinést vyčerpávají-

cí seznam kritických faktorů souvisejících s imple-

mentací Project Portfolio Managementu, nýbrž

poukázat na komplexitu a rozsáhlost změn, které

s projekty tohoto typu souvisí. Efektivně adopto-

vat systém PPM znamená závazek zodpovědného

a cíleného chování pro všechny podílející se osoby.

Každý jedinec, který se na implementaci podílí, by

měl vědět, jaká je jeho role, jaké jsou jeho povin-

nosti a úkoly. I tak je ale nasazování PPM cestou ná-

ročnou a často také bolestnou. Vyžaduje koopera-

ci prakticky všech oddělení a velmi silnou iniciativu

nejvyššího vedení. Jedině tak lze zaručit, že na kon-

ci této cesty bude zasloužená odměna v podobě

dosažení požadovaných výsledků.

Petr Šťastný

stastnyp@komix.cz

PPM není POuZe sOfTWare

6

Po akvizici společnosti Mercury Interactive Corpo-

ration společností Hewlett-Packard došlo k zásad-

ním změnám ve způsobu poskytování technické

podpory testovacích produktů.

Změny se projevily v postupném začleňování pro-

duktů bývalé společnosti Mercury Interactive

do standardů divize HP Software a od září 2007

již bylo uvolněno do používání přepracované uži-

vatelské rozhraní webové služby pro poskytování

podpory software společnosti HP, které už obsahu-

je podporu produktů, získaných akvizicemi jiných

společností včetně produktů bývalé společnosti

Mercury Interactive.

Webová služba HP Support Service Online (HP SSO,

http://support.openview.hp.com) umožňuje tři

úrovně přístupu.

1. V první úrovni nabízí obsah přístupný bez nut-

nosti přihlásit se pod uživatelským účtem a zahr-

nuje návody k používání technické podpory, zprá-

vy o proběhlých událostech, ale také o novinkách

v HP, různé obchodní informace a seznam kontaktů

na centra technické podpory HP.

2. Ve druhé úrovni se zpřístupní už více informací

poté, co si zákazník založí na webu společnosti HP

osobní uživatelský účet, tzv. HP Passport. Tato úro-

veň přístupu umožňuje stahování zkušebních ver-

zí software, stahování opravných balíčků (patches),

individuální nastavení emailových upozornění

po uvolnění nových verzí softwarových produk-

tů. Obsahuje například také informace o termínech

ukončení podpory starších verzí software HP.

3. Pro třetí, tj. nejvyšší úroveň přístupu k podpo-

ře software HP, je nutné zadat do profilu osobního

účtu HP Passport platné identifikátory servisní pod-

pory, vycházející z uzavřených smluv se společnos-

tí HP. Jedná se o tzv. SAID (Support Agreement ID).

Po vložení SAID se plnohodnotně zpřístupní služ-

ba podpory software HP, kdy lze využívat znalostní

databázi HP, zadávat, vyhledávat a prohlížet poža-

davky na technickou podporu nebo zadávat poža-

davky na změnu vlastností a funkčnosti podporo-

vaných softwarových produktů, tzv. Enhancement

requests.

S přechodem na nový webový portál technické

podpory HP zůstaly pro rok 2008 v HP k dořešení

akce jako převedení znalostní databáze, diskusního

fóra a řešených problémů technické podpory s pů-

vodními identifikátory bývalé společnosti Mercury

Interactive.

Společnost KOMIX v nedávném období investovala

další prostředky do podpůrného software i do or-

ganizace technické podpory svých zákazníků. Díky

těmto změnám došlo ke zvýšení kvality poskytova-

ných služeb technické podpory softwarových pro-

duktů HP.

Pro komunikaci se zákazníky využívá KOMIX v sou-

časné době nový systém Service Desk, nakonfigu-

rovaný pro provádění technické podpory, včetně

dodržování smluvních požadavků (SLA – Service

Level Agreement). Prostřednictvím Service Des-

ku KOMIX mají zákazníci k dispozici trvalý přístup

(24 x 7) k informacím přes webové uživatelské roz-

hraní, které umožňuje jak zadávat nové požadav-

ky technické podpory, tak i prohlížet postup řeše-

ní dříve zadaných požadavků.

V oblasti podpory HP software zajišťuje společnost

KOMIX pro své zákazníky první úroveň technické

podpory. Výhodou tohoto typu podpory je komu-

nikace v českém jazyce a naše zkušenosti s instala-

cí HP software na různá softwarová prostředí a také

znalost konkrétních implementací podporovaného

software.

Ke standardu péče o zákazníky technické podpo-

ry KOMIXu patří zasílání informací o nových verzích

HP software a konzultace o vhodnosti jejich nasa-

zení. Před uvolněním nových hlavních verzí soft-

ware předáváme našim zákazníkům výsledky tzv.

„kalibrace“, tedy závěrečnou zprávu z interního tes-

tování software dle normy ISO 9001 (ověření vlast-

ností software deklarovaných výrobcem), kde se

mj. zaměřujeme na testy českého národního jazy-

kového prostředí.

V rámci poskytování technické podpory může KO-

MIX pro své zákazníky zajistit také aktualizace no-

vých verzí software (instalační média HP update

software) a dodávky licencí.

Rovněž dokážeme řešit nestandardní požadavky

zákazníků nad rámec dojednané technické podpo-

ry, například vyžádané mimořádné práce nebo pra-

covní pohotovost v mimopracovní době či o víken-

du. Poskytujeme také rozmanité rozšiřující služby

v souvislosti s podporovaným software, nejčastěji

se jedná o instalace a konzultace prováděné na pra-

covišti zákazníka, zejména při provádění upgrade

HP software na vyšší verzi či při migracích nebo up-

grade databází.

Miloslav Richter, Štěpán Janča

richter@komix.cz, janca@komix.cz

PrOč PrOVáDĚT ZáTĚŽOVÉ TesTyZáklady zátěžového testování aplikací

ZMĚny V PrOVáDĚní TeChnICKÉ PODPOry TesTOVaCíCh PrODuKTů PO PřeChODu OD MerCury K hP

Co jsou zátěžové testyZátěžový test slouží k nalezení problémů a jejich

příčin projevujících se při větším zatížení aplika-

ce. Například při větším počtu současně pracují-

cích uživatelů může docházet k tomu, že je aplikace

pomalá, někdy dokonce bez odezvy, vrací chybová

hlášení, další uživatelé se do ní nemohou přihlásit

nebo dojde k jejímu zhroucení.

Takové chování aplikace přináší nejen ekonomic-

ké ztráty, ale rovněž demotivaci pracovníků a sníže-

ní důvěry u zákazníků, kteří musí čekat na dlouhé

odezvy systému.

Zátěžové testy ověřují výkonnost aplikace při jejím

požadovaném zatížení. Míra testovaného zatíže-

ní se volí tak, aby odpovídala podmínkám v provo-

zu a cíli zátěžového testu. Nejběžnější praxí je simu-

lovat zatížení při některé špičce (denní, týdenní či

roční). Lze také simulovat zatížení, kterému bude

aplikace vystavena v budoucnu, např. při plánova-

ném zvýšení počtu uživatelů této aplikace.

Co ovlivňuje výkon aplikaceAplikace je obvykle provozována v prostředí se slo-

žitou architekturou, které má výrazný vliv na vý-

kon aplikace. Koncový uživatel pak chápe jako vý-

kon aplikace délku uživatelských odezev aplikace

na jeho požadavky.

Zde jsou nejobvyklejší příčiny problémů s výko-

nem:

1. Výkon hardware serverů. Ten můžeme rozčlenit

na problémy s výkonem procesorů, správou a ve-

likostí paměti, průchodností diskového systému

a síťových rozhraní.

2. Přetížení části sítě, která má nedostačující šíři

pásma.

Cílem zátěžového testu je zjistit výkonnost aplikace v závislosti na stupni a druhu zatížení.

7

3. Nastavení parametrů operačního systému (Li-

nux, HP Unix, IBM AIX …).

4. Nastavení parametrů aplikačních a webových

serverů včetně Javy.

5. Nastavení databáze a databázového serveru (vy-

užívání cache, nastavení indexů …).

6. Problémy v aplikaci (neoptimalizované dotazy

do databáze, pomalá místa kódu, chyby …).

7. Pomalé odezvy spolupracujících systémů, se kte-

rými si testovaný systém vyměňuje nebo sdílí

data.

V jakém případě je třeba udělat zátěžový testPříprava a provedení zátěžového testu trvá několik

týdnů a není levnou záležitostí, a proto je třeba

se již ve fázi plánování projektu zamyslet nad tím,

zda bude potřeba aplikaci výkonnostně testovat.

Zde uvádíme několik obecných důvodů proč je

dobré, aby aplikace byla vyladěna i po výkonnostní

stránce:

• Fungující,alepomaláaplikacesnižujeprodukti-

vitu práce a také demotivuje zaměstnance.

• Můžedojítkeztrátězákazníků.Napříkladpokud

se zákazník nemůže přihlásit do internetového

obchodu nic mu nebrání nakoupit u jiného do-

davatele.

• Pokuddojdedíkypřetíženíkúplnémuvýpadku

aplikace, může, například ve finančním sektoru,

hrozit i požadavek na úhradu škody od zákazní-

ků, kteří ji nemohou používat.

• Případnýkolapsinternetovéhobankovnictvímá

vždy značnou publicitu v médiích a může vést

ke ztrátě renomé společnosti o finančních ztrá-

tách nemluvě. Obdobné pravidlo platí i pro stát-

ní sektor. I zde jsou často medializovány výpadky

celostátních informačních systémů.

Kromě obecných důvodů, které jistě stojí za zvážení,

jsou standardní situace, v nichž je doporučeno

udělat zátěžový test na ověření výkonnosti

aplikace:

• Zadavatelpřebíránovouaplikacioddodavatele.

Zátěžový test by měl být součástí akceptačního

řízení.

• Přinasazenínovéverzeaplikace.

• Připřesunuaplikacenajinýhardware.

• Připřechodunajinouverzidatabáze(např.pře-

chod z Oracle 9 na 10).

U kritických aplikací by mělo být samozřejmostí,

aby byl zátěžový test zařazen do procesu testování

již v rámci vývoje u jejího dodavatele, jako součást

jeho vnitřních testovacích procesů.

Co vám zátěžový test přineseZátěžový test slouží k ověření výkonnosti a fungo-

vání aplikace při definované zátěži a může sloužit

také jako podklad pro zvyšování výkonu aplikace

(ladění). Samotný běh zátěžového testu samozřej-

mě výkon aplikace nijak nezvýší, ale jeho výstupy

pomohou odborníkům (správci prostředí, správci

aplikací, specialisté na aplikační, databázové a we-

bové servery, vývojáři aplikace …) určit případné

„úzké místo“. Pro ladění výkonu samozřejmě po-

třebujeme monitorovat servery, případně i další

zdroje, na kterých je aplikace provozována. Moni-

toring může být na různé úrovni, což je dáno mož-

nostmi použitého software pro zátěžové testování.

Z naměřených výsledků pak můžeme vyvodit, kte-

rý server (webový, aplikační, databázový) je přetí-

žen. Pokud použijeme pokročilé diagnostiky, které

jsou součástí některého komerčního software pro

zátěžové testy, můžeme dobu odezvy konkrétního

požadavku rozložit na doby provádění požadavku

v jednotlivých částech zdrojového kódu voláních

aplikace a tím identifikovat, kde je příčina problé-

mu. Po odstranění příčiny ověříme dalším během

zátěžového testu, zda navržené řešení skutečně při-

spělo ke zvýšení výkonu.

řešením problému nemusí být vždy jen navýšení výkonu hardwareStejně jako u jiných chyb i pro ladění výkonu pla-

tí, že nejobtížnější je najít příčinu chyby. V odstav-

ci „Co ovlivňuje výkon aplikace“ je uvedeno 7 vrs-

tev, na kterých se může chyba vyskytnout. Navíc

jde často o kumulaci příčin vyskytujících se na růz-

ných vrstvách. Posílením hardware můžete zvýšit

jeho výkon zhruba o desítky procent, ale optima-

lizací na ostatních vrstvách může dojít k mnohoná-

sobně vyššímu výkonu bez investice do hardware.

Je dobré si rovněž uvědomit, že zvýšení výkonnos-

ti aplikace, třeba i nad požadované limity, přináší

ve většině případů snížení zátěže některého serve-

ru nebo serverů. To přináší buď rezervu do budouc-

na, nebo prostor pro další aplikace pokud využívají

společné servery s laděnou aplikací.

Základní typy zátěžových testů• load Test – obvyklý typ testu, kdy jsou měřeny

odezvy systému při předem definované zátěži.

• Capacity Test – při tomto typu testu je hledána

největší zátěž, při které je aplikace ještě použi-

telná. Jinými slovy zátěž postupně zvyšujeme až

do doby, kdy aplikace přestane splňovat požado-

vaná výkonnostní kritéria.

• stress Test – zjišťujeme jak se bude aplikace

chovat v případě přetížení díky nadměrné zátě-

ži nebo při omezení některého zdroje, například

při výpadku jednoho ze dvou webových serverů

či restartování databáze za běhu testu.

Manuální nebo automatizovaný zátěžový test?Potřebné zatížení aplikace je možno zajistit přímo

lidskými zdroji (manuální test) nebo specializova-

ným software spouštěným na počítačích k tomuto

účelu vyhrazených (automatizovaný test).

Manuální zátěžové testy jsou vhodné pouze pro

malé systémy, orientačně cca do 20 uživatelů nebo

pro systémy, kde by byla automatizace příliš technic-

ky náročná. Největší výhodou této metody je rela-

tivně rychlá realizace zátěžového testu bez nutnosti

využití specializovaného software a vytváření zátě-

žových skriptů. Tato metoda má ale řadu nevýhod:

• Obtížnéřízenízátěže.

• Při opakování testu nelze vzhledem k lidskému

faktoru realizovat přesně stejnou zátěž.

• Složitésledováníodezevsystémuasběrnaměře-

ných hodnot.

• Vyššíchybovostzhlediskalidskéhofaktoru.

Příprava automatizovaných zátěžových testů je ča-

sově náročnější. Zpravidla zahrnuje analýzu, přípra-

8

vu (přípravu dat, tvorbu a odladění skriptů a přípra-

vu prostředí pro ZT), realizaci definovaného počtu

běhů a jejich vyhodnocení. Výstupy automatizo-

vaných testů jsou ve srovnání s manuálními dale-

ko přesnější. Automatizovaný test je možno opako-

vat ve stejném rozsahu zátěže jako jeho provedení

v předchozím běhu.

Prostředí pro zátěžový testVlastní příprava automatizovaného zátěžového

testu se obvykle uskutečňuje na některém z tes-

tovacích prostředí. Ideálním stavem je, pokud lze

uskutečnit běhy zátěžových testů na testovacím

prostředí, které je přesnou, nebo alespoň velice

blízkou, kopií infrastruktury produkčního prostře-

dí, včetně objemů dat v databázi. Vybudovat tako-

vé prostředí je však velmi nákladné, proto se tato

varianta v reálu nevyskytuje často.

Další variantou je realizovat zátěžový test přímo

na produkčním prostředí. Tady je potřeba předem

velmi důkladně zvážit a eliminovat velké množství

rizik, která tato varianta přináší.

Nejčastější variantou je realizace běhů zátěžového

testu na testovacím prostředí zákazníka, které má

odlišný a často slabší hardware než produkční pro-

středí. Tím vzniká problém jak určit, jaký bude vý-

kon aplikace v produkčním prostředí. Lze to řešit

několika způsoby, jedním z nich je běh v produkč-

ním prostředí, poté co se provedly běhy na pro-

středí testovacím a aplikace projevila stabilitu pod

zátěží. Tento běh zátěžového testu většinou nebě-

ží s maximálním (kritickým) počtem uživatelů, ale

s počtem, který se na daném prostředí může běžně

objevit. Tímto během získáme reálné doby odezev

na cílovém prostředí.

Jinou variantou je kvalifikovaný odhad. Mimo málo

přesných odhadů lze použít i některého speciali-

zovaného software (například HyPerformix Perfor-

mance Optimizer). Jako vstupy tomuto software

zadáme výsledky zátěžového testu a údaje o in-

frastruktuře testovacího a produkčního prostředí

(všech serverů a dalších prvků včetně jejich výkon-

nostních parametrů). Tento software pak vyhodno-

tí jak by test s určitou pravděpodobností dopadl

na produkčním prostředí. Program lze samozřejmě

použít i v tom případě, kdy plánujete posílit nebo

inovovat produkční prostředí a rádi byste znali do-

pad změny hardware na výkon aplikace.

na co se soustředit při plánování zátěžového testuV první řadě je potřeba stanovit, co bude cílem

zátěžového testu a jestli jsme schopni realizovat

jej vlastními kapacitami nebo bude výhodnější si

na tuto práci najmout profesionální firmu.

V harmonogramu prací je nutno počítat s dostateč-

nou dobou pro jednotlivé etapy zátěžového testu

(analýza, příprava skriptů a testovacích dat, prove-

dení běhů a vyhodnocení).

Pokud se rozhodnete pro profesionální firmu,

doporučujeme, aby jste si připravili pro jednání

tyto podklady:

• Jakým způsobem je aplikace zatěžována (napří-

klad pracovníky přistupujícími přes webového kli-

enta, přes tlustého klienta SAP, jiným systémem,

se kterým komunikuje pomocí web services).

• Jakájecílovápožadovanávelikostzátěže.

• Coodzátěžovéhotestuočekáváte,jakébyměly

být jeho cíle a přínosy, proč ho plánujete (např.

nová aplikace, nová verze aplikace …).

• Základnítechnologickéúdajeoaplikaci,prostře-

dích a protokolech (například aplikace je v SAPu

či Siebelu včetně jejich verze).

• Cosebudevprůběhutestuvyhodnocovat?Ty-

picky jde o doby odezev na jednotlivé uživatel-

ské akce, doby trvání u dávkového zpracování

dat, vytížení hardware (procesoru, paměti, dis-

ků), parametry databáze, aplikačních a webových

serverů, vytížení síťových prvků. V tomto případě

je dobré uvést alespoň zhruba počet monitoro-

vaných serverů a jejich charakteristiky.

• Tabulkupožadovanýchvýkonnostníchlimitůpro

sledované odezvy aplikace

Co vám můžeme nabídnoutKOMIX má rozsáhlé a dlouholeté zkušenosti v ob-

lasti provádění zátěžových testů a technické pod-

pory software HP LoadRunner. Díky našim širokým

znalostem můžeme nabídnout provedení zátěžo-

vých testů „na klíč“ jak komerčním, tak freeware

software.

Dále nabízíme školení, a to nejen pro pracovníky

provádějící zátěžové testy (jak provádět zátěžové

testování, školení práce se software pro zátěžové

testy), ale také obecnější školení pro vedoucí pra-

covníky.

Libor Kotoun

kotoun@komix.cz

Přenesme se tedy do projektové reality a pojďme se

podívat, koho z testovacího týmu můžeme potkat

na SW projektu, jehož součástí je manuální funkční

testování, a jak takové testování vlastně vypadá.

Standardní řízený proces testování by měl obsaho-

vat 4 fáze - plánování, přípravu, provedení a vy-

hodnocení.

Úkolem plánovací fáze je mimo jiné zjistit, co je

cílem testování, zhruba určit metody, kterými se

k těmto cílům dostaneme a nastavit základní rámec

pravidel, podle kterých se bude dále postupovat.

Ve fázi přípravy nastává ten správný čas na pro-

studování dostupných podkladů, upřesnění nejas-

ností, zvolení vhodného způsobu testování a ze-

jména čas pro přípravu podkladů, podle kterých

se testování provede. Vývoj aplikací nejčastěji pro-

bíhá v několika etapách, je tedy více než vhodné,

aby testeři tento způsob respektovali. Proto je nut-

né mít připravené odpovídající typy testů pro kaž-

dou fázi projektu – při akceptačním testování je již

pozdě na zjišťování, zda při zadání textu do číselné

položky aplikace nezhavaruje.

Od první spustitelné verze aplikace může (a má) za-

čít provádění testů, tedy určení vhodné sady tes-

tů, odpovídající aktuální fázi vývoje, jejich spuště-

ní a ohlášení nalezených chyb. Po ukončení testů

následuje jejich vyhodnocení – tedy rekapitulace

toho, co se udělalo, ocenění dobré práce a získání

námětů na to, co příště udělat lépe. Vhodným ter-

mínem pro tuto činnost jsou milníky projektu.

Práce v jednotlivých fázích testování se od sebe vý-

znamně liší, a je tedy vhodné, když si je mezi sebou

rozdělí sehraná skupina odborníků. Nejčastěji se

rOle V PrOCesu ManuálníhO TesTOVánítak v týmu sejde vedoucí testování, analytik testo-

vání a jeden nebo více testerů.

Vedoucí testování (manager testování, koordinátor testování…)Jeho hlavním úkolem je plánovat, vést a řídit testo-

vání. V úvodních fázích projektu domlouvá a speci-

fikuje záměry a cíle testování, rozhoduje, které typy

testů a zhruba v jakém rozsahu je třeba provést.

V některých případech také trpělivě vysvětluje, že

opravdu není možné, aby testeři poprvé nastoupili

na projekt tři dny před finálním releasem.

Během projektu organizuje práci testerů, pomáhá

jim zajišťovat podmínky k práci a kromě standard-

ních manažerských činností také dbá na to, aby

jeho tým dodržoval přijatou metodiku. V neposled-

ní řadě komunikuje s vedením projektu, řeší problé-

my a urovnává menší krize, kterých je na projektu

vždy více, než by si přál.

Na projektu ho buď potkáte málokdy (pokud jste

vývojář nebo analytik), nebo naopak téměř na kaž-

dé schůzce (pokud jste projektový manažer).

Testování už dnes (naštěstí) většinou neprobíhá tak, že si „někdo“ na pár minut sedne k aplikaci,

„tak nějak“ prokliká obrazovky a myslí si, že zázračně na první pokus odhalí všechny závady

a nedostatky, které se v programu skrývají. Ověřování kvality tak přestává být i v našich krajích

vnímáno jako „práce pro juniory“ a „přestupní stanice k lepší pozici“ a stále více lidí si uvědomuje,

že jde o exaktní disciplínu, řídící se jasnými pravidly a vyžadující souhru několika odborníků.

9

Co nerad slyší:

Testovací prostředí fungovat nebude, ale testy se

udělat musí. Nějak to otestujte, hlavně ať tam ne-

jsou chyby, ať to můžeme nechat zakceptovat.

analytik testováníJeho doménou je testovací dokumentace – tedy

příprava a údržba podkladů pro testování. Poznáte

ho snadno už podle prvních otázek, které většinou

zní: „Kde najdu požadavky, kde máte uloženou ana-

lýzu a jaký je telefon na analytika vývoje?“

Pak se stáhne do tichého kouta, odkud se něko-

lik dní ozývá zuřivé šustění zvýrazňovače a nespo-

kojené „Odkdy má happy-day scénář dva konce?“,

„Tady je potřeba dopsat alternativní průběh.“, pří-

padně zoufalé „Kdo odsouhlasil požadavek ‘Systém

je dostatečné výkonný?!‘ “. Po následujícím krátkém

intermezzu s analytikem vývoje se vrací s uprave-

nou analýzou a hrubou kostru naplánovaných tes-

tů začne obalovat testovacími případy a testovací-

mi daty. Jednotlivé testy se začnou skládat do sad

a v okamžiku, kdy si spokojeně vydechne nad ho-

tovou prací, je zpravidla čas na zapracování první

dávky změn a úprav. Se začátkem testování se vě-

nuje hlavně určování, které testy budou v aktuál-

ním běhu spuštěny a část času věnuje zapracovává-

ní změn a úpravám testovacích případů.

Na projektu se nejvíce potkává s analytikem vývo-

je a s odborníky zákazníka, kterých se ptá a ptá až

do oboustranného vyčerpání.

Co nerad slyší:

Analýza ani požadavky nejsou a nebudou, funkč-

nost je triviální a každý ví, co to má dělat.

Není čas něco analyzovat, musíme hlavně začít

rychle testovat. Pusť si aplikaci, zjisti si co dělá, a pak

podle toho napiš testy.

TesterVe své praxi jsem se setkal se dvěma krajními po-

hledy na roli testera. Podle jednoho z nich to má

být někdo, kdo si ráno bez jakékoli podpory sedne

k neznámé aplikaci, mrknutím levého oka ji nain-

staluje, nakonfiguruje a rozchodí, mrknutím pravé-

ho oka pak vyčaruje tři megabajty testovacích dat,

analýzou se nezdržuje, do oběda celý systém doko-

nale otestuje a bude hlavou ručit za to, že v aplikaci

žádné chyby nejsou a nikdy nebudou.

Podle druhého pohledu je tester zbytečná přítěž,

případně nezkušený junior, kterého je nejlépe ig-

norovat a co nejdříve nahradit nějakým pěkným

systémem pro automatizované testování.

(Existuje ještě třetí pohled: “Hlavně se nám v té naší

dokonalé aplikaci nerejpej, ještě bys tam něco na-

šel a my to museli opravovat“. Tam pro testera exis-

tuje jen jedna cesta – zmizet co nejrychleji do jiné

firmy.) Jak už to u extrémních příkladů bývá, prav-

da je někde uprostřed cesty. U dokonale připra-

vených testů, tedy tam, kde byl dostatek času pro

analýzu a přípravu podrobných testovacích scéná-

řů a kde jsou scénáře ověřeny mnoha běhy, může

být testování vhodnou prací pro studenta, juniora

nebo pro automat (koho by také uspokojovalo kli-

kat v jedné aplikaci pořád dokola). Čím méně do-

konalá byla příprava a analýza, čím více se aplika-

ce mění pod rukama a čím méně je času na vlastní

testování, tím fundovanější musí být tester, tím více

musí spoléhat na zkušenosti, intuici, znalost oboru

a na různé fortele a triky, které mu umožní i takový

projekt zdárně dokončit.

Úkolem testera je tedy otestovat aplikaci – ale co

to vlastně znamená? Stručně řečeno, podle podkla-

dů provádět s aplikací předepsané operace, porov-

nat je s předepsaným očekávaným chováním a za-

znamenat neshody, na které narazí. Kromě toho je

žádoucí, aby netestoval pouze to, co je předepsáno

– v rámci „free testů“ mají testeři spoustu prosto-

ru pro invenci při vymýšlení, jak aplikaci co nejlé-

pe shodit. Dobře namíchané, několikrát provedené

testy, složené jak z rutinního procházení, tak z vol-

ného hraní s aplikací, dokáží odhalit velké množství

chyb, v rozumném čase a s malým rizikem, že tým

otupí z únavy. Samostatným uměním je správné re-

portování chyb – tak, aby bylo možné ověřit opravu

chyby, kterou nalezl před půl rokem kolega, který

již ve firmě nepracuje, v aplikaci o pět verzí zpátky

a poté, co se dvakrát přemazala databáze.

Nejčastěji tester komunikuje s vývojáři a s analyti-

kem testování.

Co nerad slyší:

To není chyba, to je vlastnost.

To jsme udělali jinak.

Na mém počítači to funguje, přeinstaluj si Win-

dows.

Testování přirozeně neprobíhá ve vzduchoprázd-

nu, testovací tým spolupracuje a komunikuje s řa-

dou dalších lidí. Nejdůležitější pro testovací tým

jsou projektový manager, analytik vývoje a progra-

mátor, ale neobejdou se ani bez součinnosti odbor-

níků ze strany zákazníka – neocenitelná je zejmé-

na pomoc specialistů na data a na vlastní business

zákazníka. A nedovedu si

představit efektivní testo-

vání bez pomoci specialistů

na databáze, testovací pro-

středí a vývojářů různých

speciálních nástrojů – těm

všem patří poděkování nás

testerů.

Bohužel nikdo - ani mistři

badatelských testů, ani nej-

dražší software pro testy, ani

nedokonalejší analýzy - ne-

zaručí, že nějaká chyba ne-

proklouzne až k uživatelům.

Testovací tým se snaží dob-

rým naplánováním, pocti-

vou přípravou a pečlivým

provedením testů o to, aby

takových chyb bylo co nej-

méně.

Pavel Hönigschmied

honigschmied@komix.cz

10

Od konce roku 2005 pracuje KOMIX na projektu vý-

voje systému cestovních pasů s biometrickými prv-

ky (CDBP), na kterém se podílí celá řada dalších sub-

jektů. Projekt je rozdělen do několika etap, přičemž

předmětem minulé etapy (tj. období roku 2006) byl

vývoj centrální aplikace a k ní skupiny (čítající cca

12) klientských aplikací: klientská aplikace pro obce,

klientská aplikace pro cizineckou a pohraniční po-

licii atd.

V současné době, probíhá další etapa projektu,

ve které je předmětem vývoje rozšíření stávajících

aplikací o zpracování otisků prstů. Dále dochází

ke zvýšení zabezpečení údajů v čipu elektronické-

ho pasu prostřednictvím složité struktury certifiká-

tů a také jsou realizovány další drobné změny a roz-

šíření systému.

Již v době, kdy se tvořil plán celého projektu, byla

navržena období, během kterých se bude testování

realizovat. Je potřeba si uvědomit, že proces testo-

vání se skládá, kromě plánování, z přípravy testová-

ní (což bývá náročná a dlouhodobá činnost) a pak

ze samotného provedení testování.

Po naplánování byl sestaven testovací tým, který

zahrnuje následující role: vedoucího testování, ana-

lytika testování a testery.

Vedoucí testování zastřešuje celý tým, tj. komuni-

kuje s jinými vedoucími týmů a managementem

projektu, zajišťuje rozdělení prací v týmu, koordi-

nuje činnosti v týmu, kontroluje výsledky práce čle-

nů týmu a poskytuje jim podporu, sestavuje Plán

testování, odhaduje pracnost činností, sestavuje

Harmonogram testování, sestavuje návrh testování

(součást dokumentu Návrh programového vybave-

ní), vytváří společně s analytikem testovací scénáře

a testovací případy (tj. pro všechny klientské aplika-

ce projektu CDBP).

Analytik testování vychází ze schválených analytic-

kých podkladů k aplikaci, na jejichž základě navrhu-

je rozsah pokrytí aplikace testy, tvoří testovací pří-

pady, testovací scénáře a specifikaci testovacích dat

(potřebných pro provedení testů).

Tester provádí samotné testování na základě tes-

tovacích případů a testovacích scénářů s použitím

testovacích dat.

V reálu většinou dochází ke kumulaci rolí. Na tomto

projektu je vedoucí testování zároveň i analytikem

a v případě potřeby také testerem. Stejně tak analy-

tik testování bývá současně testerem.

Úkolem týmu je seznámit se s projektovou doku-

mentací, tak aby byl schopen vytvořit testy ještě

před tím, než jsou k dispozici testovatelné klient-

ské aplikace. Projektová dokumentace na CDBP za-

hrnuje Analýzu programového vybavení (dále jen

APV), kde jsou podrobně rozpracované požadavky

na systém od zákazníka, dále obsahuje popisy roz-

hraní, slovní popisy procesů, UML diagramy proce-

sů, infrastruktury apod. Druhým neméně důležitým

dokumentem, který vzniká na základě Analýzy je

Návrh programového vybavení (dále jen NPV). Sou-

částí NPV je také kapitola o funkčním a zátěžovém

testování, kde je rozepsán požadovaný rozsah tes-

tování pro tuto etapu vývoje. Tyto dva dokumenty

jsou důležitým podkladem pro návrh a tvorbu tes-

tovací dokumentace (tj. Plán testů, Testovací přípa-

dy a scénáře, specifikace testovacích dat).

Po seznámení týmu s projektovou dokumenta-

cí aktualizoval vedoucí testování dokument Plán

testování, který vznikl již v minulé etapě a obsahu-

je popis konkrétního provedení jednotlivých stádií

testování, požadavky na součinnost ze strany zá-

kazníka, kritéria zahájení a ukončení testování, spe-

cifikace testovacích dat, definice rolí, definice tříd

chyb atd.

Po aktualizaci Plánu testů přichází fáze přípravy tes-

tovacích případů a testovacích scénářů, a to na zá-

kladě informací z dokumentů APV a NPV.

Pro zajímavost: na projektu CDBP bylo za obě eta-

py vytvořeno celkem 130 testovacích scénářů, které

mají dohromady cca 520 stránek A4 a obsahují po-

drobné testovací případy.

Testovací dokumentace je finalizována do začátku

systémového testování.

Projekt CDBP prochází následujícími stádii testo-

vání:

•Interní

•Systémové

•Integrační

•Nezávislé

•Akceptační

•Pilotníprovoz

Interní testování na projektu CDBP je stádium pro-

jektu, kdy dochází k tvorbě veškeré testovací do-

kumentace (jak jsem popsal již výše) a prvotnímu

otestování vyvíjeného systému na testovacím pro-

středí v KOMIXu. Výsledkem interního testování je

„funkční“ verze centrálního systému a klientských

aplikací, které se následně nahrají na prostředí zá-

kazníka, v tomto případě na prostředí vytvořeném

na Ministerstvu vnitra.

Vývoj aplikací a interní testování projektu CDBP je

rozděleno do iterací, které mají 14 denní opaková-

ní. Jeden týden testovací tým vždy připravuje testy

a druhý týden tyto testy provádí. Stejně tak vývo-

jový tým jeden týden vyvíjí a druhý týden opravu-

je chyby. Plánované práce vývoje jsou evidovány

v dokumentu Evidence iterací, podle kterého mají

testeři dokonalý přehled o tom, co bude v následu-

jících několika týdnech naprogramováno a postup-

ně uvolněno pro testování. Posledním zdrojem in-

formací pro testery je firemní aplikace ProjectX, kde

každému záznamu z Evidence iterací odpovídá je-

den úkol přiřazený konkrétnímu řešiteli. V úkolu je

popsán zdroj, ze kterého programátoři vycházejí, tj.

Analýza, Návrh, ZP (změnové požadavky). Dále zde

bývá stručný popis řešení a také návrh na otesto-

vání. Na základě těchto informací vedoucí testová-

ní připraví postup provedení testů, který většinou

vychází z testovacích případů a testovacích scé-

nářů. Tento návrh testování pak zaeviduje do Pro-

jectX ve své složce Testování jako úkoly a přiřadí

je konkrétnímu řešiteli, tj. členu testovacího týmu

- testerovi. Aplikace zašle úkol e-mailem odpověd-

né osobě, která pak v testovacím týdnu iterace úkol

provede. Musím podotknout, že tento způsob vý-

voje je velmi přehledný a funkční.

Po dokončení interního testování a oprav je uvolně-

na k testování první verze systému na testovací pro-

středí zákazníka, tedy k systémovému testování.

Velmi často jsou systémové a integrační testy pro-

váděny víceméně současně, protože bez napojení

TesTOVání sysTÉMu CDBP V KOMIXu

11

na ostatní vyvíjené komponenty celého systému

se nedá vyvíjený systém dostatečně otestovat. Cí-

lem systémového a integračního testování je pro-

pojit produkt vyvíjený KOMIXem s ostatními část-

mi systému, které vyvíjejí další subjekty účastnící

se projektu. Poté, co je propojen centrální systém

klientské aplikace s testovacími evidencemi obyva-

tel a cestovních dokladů a dalšími okolními systémy

(na prostředí zákazníka), probíhá testování zhruba

stejným způsobem jako v rámci interních testů. Tes-

teři procházejí klientské aplikace podle testovacích

případů a testovacích scénářů, jediným rozdílem

bývají testovací data, která musí do testovacích evi-

dencí připravit pracovníci Ministerstva vnitra.

Na konci systémových a integračních testů se vět-

šinou provádí zátěžový test, který je možné pro-

vést až tehdy, kdy je aplikace „plně“ funkční a je z ní

odstraněna většina chyb. Cílem zátěžového testu

na tomto projektu je otestování výkonnosti cent-

rálního systému, tedy zda je systém schopen při za-

sílání velkého množství požadavků v určitém časo-

vém intervalu (např. jedné hodiny) tyto požadavky

zpracovat, vyřídit (např. podepsat příslušnými certi-

fikáty) a poslat zpět. Zátěžový test celého systému

byl proveden už v minulé etapě, v této etapě dojde

pouze k otestování jedné nové komponenty cent-

rálního systému, která je součástí nově doprogra-

movaných funkcí.

Po provedení interního, systémového a integrační-

ho testování provede jiný subjekt účastnící se pro-

jektu tzv. nezávislé testování našeho produktu

Možná, že jste se již někdy setkali s úkolem převést

systém provozovaný u zákazníka do zcela nového

řešení, a to se zachováním funkčnosti, na kterou

jsou uživatelé zvyklí. Pokud jste i vy už něco tako-

vého řešili, určitě mi dáte za pravdu, že ne všechny

věci běží tak, jak by měly a v průběhu prací se mů-

žete setkat s menšími nebo většími problémy. Ani

převod systémů TARIC (systém integrovaného ta-

rifu Evropské unie) a NIT (národní integrovaný ta-

rif) z prostředí UNIX do prostředí Windows nebyl

výjimkou. V následujících řádcích popíšu některé

z postupů, které jsme implementovali, budu mluvit

o problémech a jejich řešeních, které tento převod

provázely. I když se tento článek nesoustředí na de-

tailní popis systémů TARIC a NIT, je nutno zmínit pár

základních údajů.

Systém TARIC slouží ke sledování statistiky zahra-

ničního obchodu Společenství a obchodu mezi

členskými státy Evropské unie. Tento systém je za-

ložen na kombinované nomenklatuře. Systém NIT

doplňuje TARIC o netarifní opatření, sazby daně

z přidané hodnoty a spotřební daně. Tyto systémy

resp. celého systému. V minulé etapě si tato firma

vytvořila vlastní testovací případy a scénáře na zá-

kladě stejné dokumentace, kterou měl k dispozi-

ci testovací tým KOMIXu. Stejný režim je plánován

i pro současnou etapu projektu, kdy tato firma do-

stane navíc k dispozici testovací dokumentaci KO-

MIXu. Proces nezávislého testování probíhá podob-

ně jako interní a systémové testování prováděné

KOMIXem. Testeři firmy provádějící nezávislé tes-

tování projdou všechny klientské aplikace pod-

le testovacích případů a testovacích scénářů, zapí-

šou chyby (pokud jsou nějaké nalezeny), tyto chyby

jsou opraveny, dojde k uvolnění nové verze a k re-

testu atd.

Pokud je nezávislé testování celého systému CDBP

úspěšné a dojde ze strany firmy provádějící nezá-

vislé testy k potvrzení, že KOMIX i ostatní subjekty

účastnící se projektu CDBP vytvořily dílo odpovída-

jící smluvnímu zadání, je tento systém předán k ak-

ceptačnímu testování.

akceptační testování většinou probíhá tak, že se

předvedou zákazníkovi všechny funkce odpoví-

dající jeho zadání (požadavkům). Testování probí-

há na základě testovacích případů a scénářů, podle

kterých byly prováděny testy v rámci předchozích

stádií testování. Tato testovací dokumentace je však

zredukována na ty nejdůležitější funkčnosti (které

zastřešují všechny ostatní). Důvodem této reduk-

ce je fakt, že testovací dokumentace i celý systém

CDBP je velmi rozsáhlý a složitý a jeho komplexní

byly doposud provozovány na operačním systému

UNIX a pro uchovávaní dat byl zvolen databázový

server Informix. Část řešení, importující data přichá-

zející z Evropské unie ve výměnném formátu EDI-

FACT,bylanapsánajakoautonomníúlohapřistupu-

jící k databázi pomocí ANSI C a ESQL/C. Pro přístup

uživatelů k datům byly vytvořeny webové aplikace

provozované na webovém serveru Apache za po-

užitímoduluFastCGI.Tolikshrnutítechnologie,ze

které se převádělo. Dále již druhá strana mince –

technologie, do které se převod uskutečnil. Micro-

soft, takto by se dalo jedním slovem shrnout cílové

prostředí. Buďme však konkrétnější. Celkové řeše-

ní se skládá z aplikačního, databázového a webové-

ho serveru. Všechny servery běží na operačním sys-

tému MS Windows Server 2003. Logické rozdělení

tohoto systému je, že autonomní úlohy a část ko-

munikující s Bruselskou bránou jsou provozovány

na aplikačním serveru. Databázový server, v našem

případě MS SQL Server 2005, pokrývá migrované

databáze. Integrace webových aplikací, určených

pro práci uživatelů, se připravovala do portálového

funkcionalita byla ověřena několikrát v předcháze-

jících stádiích a v rámci akceptačních testů není vět-

šinou možné realizovat testy v úplném rozsahu. Zá-

kazníkovi se proto předvedou základní uživatelské

funkce systému (odpovídající jeho požadavkům)

a podle kritérií stanovených a odsouhlasených

s dostatečným předstihem se pak akceptační testy

vyhodnotí. Zákazník po skončení akceptačních tes-

tů podepíše Akceptační protokol s vyjádřením, že

systém byl dodán tak, jak bylo smluveno a všichni

účastníci projektu dostáli svým závazkům.

Jedna z nejdůležitějších a nejsledovanějších fází

projektu je tzv. Pilotní provoz. Pilotní provoz pro-

bíhá následujícím způsobem: veškerý systém, tes-

tovaný na „testovacím“ prostředí, se převede

do tzv. ostrého prostředí. Celý systém se tak propo-

jí se skutečnými evidencemi a skutečnou produkční

databází. V rámci tohoto pilotního provozu jsou už

vyráběny skutečné pasové knížky s reálnými daty.

V rámci pilotního provozu mohou být ještě naleze-

ny a opravovány chyby vycházející z reálného na-

pojení na spolupracující systémy. Neshody z pilot-

ního provozu jsou hlášeny na tzv. „hotline“, kde jsou

tříděny a řešeny.

Po úspěšném ukončení pilotního provozu, který

může trvat řádově několik týdnů, bude systém uve-

den do běžného provozu. Plánované nasazení ino-

vovaného systému CDBP bude od dubna 2009.

Michal Černický

cernicky@komix.cz

řešení provozovaném na Windows SharePoint Ser-

vices 2.0. Z použitých technologií se dá vyčíst, že

jsme pro programování zvolili opět Microsoft, a to

vpodáníMicrosoft .NETFramework2.0,ASP .NET

2.0 a C++.

Z obrázku 1 si můžete udělat představu o celkovém

řešení.

Dějství první – migrace databázeVýhoda této migrace je, že známe stávající řešení,

a tudíž nás nic nemůže překvapit, říkáme si. Nikdo

však není prorokem a na tato slova si ještě v průbě-

hu prací několikrát vzpomeneme. Ty začátky jsou

asi všude stejné, je potřeba připravit vývojové pro-

středí, nastavit pravidla, přístupy atd. Již po prvních

jednáních se zákazníkem je však jasné, že ke štěstí

nám nepomůže jenom naše interní vývojové pro-

středí, ale pro integraci je zapotřebí ještě prostředí,

a to přímo u zákazníka. Ještě, že existuje virtuali-

zace, vzpomenu si, když poměrně brzy dostávám

informaci o tom, že je již možné tyto prostřed-

ky na straně zákazníka využít. Protože mezitím

PřeVOD sysTÉMů TarIC a nIT Z PrOsTřeDí unIX DO PrOsTřeDí WInDOWs

12

nezahálíme, je připravován převod databáze z IBM

Informix řady 9.X do MS SQL Server 2005. Instalu-

jeme IBM Informix Client SDK 2.90.TC1 a připravu-

jeme převod databáze. Volba na tuto verzi padla

z důvodu stability v současně provozovaných ře-

šeních. (Jak jsme se v tomto případě mýlili, ukáže

až pozdější nepříjemné zjištění). Nastavujeme pro-

středíklientapropodporuUTF-8,avšakjižpřiprv-

ních testech zjišťujeme, že nám zcela zjevně něco

chybí. Na data se dostaneme, ale jejich zobraze-

ní není správné. Chybí nám Global Language Sup-

port, vzpomeneme si, a po instalaci této podpory je

již vše v pořádku, data se zobrazují tak, jak by měly.

Následně zálohujeme prostředí IBM Informix Clien-

ta a můžeme začít připravovat balíčky pro přenos

dat na SQL Server 2005.

Dějství druhé – příprava autonomních úkolůProgramové vybavení na straně aplikačního serve-

ru obsahuje autonomní úlohy pro import a export

dat. Toto řešení bylo provozováno i na platformě

UNIX. Pro vývoj nových autonomních úkolů bude

použit jižnavrženýMicrosoft .NETFramework2.0.

S úspěchem převádíme metadata popisující EDI-

FACTzprávudoXMLformátuapřipravujemealgo-

ritmus importu dat. Nebudu čtenáře zdržovat in-

formacemi o tom, jak jsme rozdělovali části kódů,

abychom docílili vytvoření znovupoužitelného fra-

meworku pro autonomní úlohy, a také webové čás-

ti řešení. Musím však říci, že pokud se chystáte vy-

tvořit takto obecnější

framework, je potřeba

myslet na to, jak se vám

budou chovat standard-

ní části logování .NET

v některých portálových

prostředích. Neměli bys-

te taky zapomenout,

že některé z těchto ře-

šení vyžadují registraci

použitelných knihoven

do GAC (Global assemb-

ly cache). Abych se však

vrátil zpět k naší implementaci. Mluvíme-li o impor-

tu dat ze vstupního souboru, tak část těchto prací

není závislá na existenci databáze. V našem případě

tomu nebylo jinak. Oddělením částí programování,

rozebránímEDIFACzprávyajejívalidacíjsmemoh-

li pokračovat v pracích nezávisle na stavu migrace

dat, která nebyla ještě

v té době kompletní.

Dějství třetí – ko-munikace s infra-strukturou BruseluBrusel zasílá zprávy typu

EDIFACTvšemčlenským

státům pomocí infra-

struktury určené pro

tento účel. Pro podporu komunikace s touto infra-

strukturou distribuuje speciální SDK, a to jako C++

knihovny. Chvíli jsme váhali, zda pro vytvoření pro-

gramového vybavení stahující data z této brány ne-

použítMicrosoft .NETFramework,alevtomtopří-

padě převážily výhody nativní integrace s C++.

Zajímavostí tohoto SDK je, že může spolupracovat

s bránou dvěmi následujícími způsoby:

a) komunikaci zahajuje infrastruktura,

b) komunikaci zahajuje klient

ad a/ celková konfigurace je nastavena v tzv. módu

“OnDemand“.

Toto se jeví jako efektivní řešení, ve kterém nedo-

chází ke zbytečné zátěži této infrastruktury. Abych

objasnil tento princip, musím říci, že v tomto módu

infrastruktura samotná aktivně oslovuje na defino-

vaném TCP/IP portu poslouchající kanál na straně

klienta, a po navázaní komunikace probíhá spoje-

ní již pomocí tohoto kanálu. Nezbytným předpo-

kladem je, že na straně klienta je programové

vybavení umožňující nejenom poslouchat na vy-

hrazeném portu, ale i předat řízení dalšímu progra-

movému vybavení. Tato část na straně klienta také

slouží jako most pro komunikaci mezi volaným pro-

gramovým vybavením na jedné straně a infrastruk-

turou na straně druhé. Pokud se to zdá příliš složité,

tak uživatelé UNIX přesto jistě tuší, že programové

vybavení inetd je trefa do černého.

Komunikace typu OnDemand je znázorněná na ná-

sledujícím obrázku.

Zastánci Windows zřejmě již ví, že pod tímto sys-

témem to není takovým standardem jako u UNIX.

Pokud byste připravovali takovéto řešení ve vašem

produktu, tak byste se měli striktně vyhnout použi-

tí funkcí zapisujících informace na standardní vstup

nebo výstup. Důvodem proč nezapisovat je to, že

pokud vaše programové vybavení volá někdo tím-

to způsobem, tak vám do procesu předává komu-

nikační rouru právě formou standardního vstupu

a výstupu. I když na Windows se něco takového

moc nepoužívá, nehodíme však flintu do žita, po-

mysleli jsme si. Začali jsme tedy hledat, zda lze tako-

véto řešení rozumně pokrýt. Kdo hledá najde, říká

se. Po nalezení pár placených odkazů a ověření ně-

kolika ne zcela funkčních řešení jsme nalezli koneč-

ně to, co jsme potřebovali. Pak mohlo začít testo-

vání. První problémy se objevily hned na počátku,

kdy náš program sice začal po oslovení komuniko-

vat, avšak po prvních voláních bylo spojení přeru-

šeno. Snažili jsme se zjistit, co může být příčinou

tohoto chování a pro podporu jeho detekce jsme

zaslali všechny podklady tvůrci SDK. Po několika

komunikacích s dodavatelem SDK a neúspěšných

testech však dostáváme zprávu, že ve funkcionalitě

SDK určené pro operační systém Windows je chyba

a oprava bude uvolněna někdy v příští verzi. Ještě,

že algoritmus zůstává stejný a mění se jenom konfi-

gurace, pomysleli jsme si.

ad b/

Protože čas je neúprosný, naše úsilí se soustře-

dí na co nejrychlejší konfiguraci prostředí brá-

ny v módu OnInitiator. Konfigurace prostředí není

zcela v naší moci a je potřeba oslovit Brusel, ale

tady nám něco říká, že zítra to asi nebude. Vrhá-

me se proto na definování automatické části, kte-

rá bude oslovovat tuto bránu v předem určených

intervalech, a to nejlépe s možností definice rozdíl-

ných intervalů v průběhu celého dne. Dlouho hle-

dat nemusíme a rozšířeným nastavením automa-

ticky spustitelných úkolů v operačním systému MS

Windows 2003 lze tuto funkcionalitu zcela pokrýt.

Po zprávě, že Brusel již prostředí nakonfiguroval,

provádíme testovací ověřování a po pár kolech mů-

žeme říci, že algoritmus je funkční.

Dějství čtvrté – pokračování vývoje au-tonomních úkolůMigrace dat v době, kdy jsme řešili problémy brány,

pokročila tak, že data jsme již měli k dispozici, jak

na našem vývojovém serveru, tak také v prostředí

zákazníka. Při samotném vývoji importu jsme se se-

tkali s problémem implementace odložených kon-

trol vkládaných záznamů. Tato funkcionalita je pod

Informix řešena přímo, avšak Microsoft na to jaksi

pozapomněl. Řešení jsme však nakonec nalezli, ale

až na úrovni ovládání constraints nad samotnými

tabulkami databáze. Po testování importu a odla-

dění případných chyb se již rozeběhly práce na pří-

pravě exportů. Postupující práce nám daly možnost

provést vzájemné srovnání exportů z UNIX a Win-

dows. Jenže tady jsme se nestačili divit. Všechny

položky seděly, avšak datumové položky se zce-

la náhodně rozcházely o jeden den, a to jak do-

předu, tak i dozadu. Začali jsme kontrolovat mig-

rovaná data v MS SQL Serveru a tam bylo přesně

to, co jsme exportovali pomocí našeho algoritmu.

Obrázek 1: Obecná architektura celkového řešení

Obrázek 2: Komunikace typu OnDemand

13

Po následné kontrole v Informix jsme zjistili, že data

se přenesla chybně. Verdiktem je, že v migraci je ně-

kde chyba a je ji potřeba co nejdříve objevit. Začíná

zdlouhavé hledání a testování za podpory software

umožňujícím porovnání datových tabulek, rozdě-

lování připravených importních balíků na menší

(po rozdělení na obsahově menší balíčky se frek-

vence o poznání snížila) a další činnosti. Nebudu

čtenáře zdržovat výčtem všeho, co jsme podnika-

li k tomu, abychom objevili v čem je problém, ale

řešení se nakonec nalezlo. V našem případě to byla

nutnost aktualizace použité verze IBM Informix Cli-

ent SDK 2.90.TC1 na verzi novou, a to IBM Informix

Client SDK 2.90.TC6R1. Po nasazení této verze již vše

proběhlo správně.

Dějství páté - webové aplikaceImplementace webových aplikací do prostředí zá-

kazníka mimo jiné předpokládala integraci Active

Directory, použití impersonifikace (změna identi-

ty) při přístupu na datové zdroje, a také byl předpo-

klad, že uživatelům zanecháme systém upozorně-

ní při provádění autonomních úkolů přistupujících

do databáze. Z celkového řešení se nakonec nej-

problémovější ukázala část pro přístup na datové

zdroje pod jinou identitou. Tato část je dostatečně

popsána na MSDN, ale ne všechny doporučení jsou

s ohledem na prostředí portálu funkční. Po hledání

řešení metodou pokus omyl se nám úpravou kódu

a zařazením volání Windows API funkce RevertTo-

Self (zruší předcházející impersonifikaci), před sa-

motnou záměnou identity uživatele, podařilo

upravit tuto část kódu tak, aby byla funkční i pro vy-

stavení do portálu. Co nás dále překvapilo při vý-

voji webových aplikací? Jak jsem již předeslal, ne-

bylo toho příliš. Co však možná stojí za zmínku, je

to,žepropřípravuexportůdoformátuDBFbylpo-

užit standardní MS Jet OLEDB poskytovatele. Po-

kud však použijete tohoto poskytovatele s vlast-

ností dBASE 5.0, počítejte s omezením velikosti

textových datových položek na hodnotu 255. Pro

formát Excel jsme zvolili “standardní” možnost to-

hoto produktu zpracovávat HTML soubor. Jediné,

co pro korektní zpracování tohoto formátu samot-

ným Excelem musíte dodržet, je konvence hlavičky

a samotných stylů. Za zmínění také stojí fakt, že při

použití stejného frameworku (ve kterém jsou defi-

novány globální proměnné) pro obě aplikace a po-

třeby registrace těchto aplikací do GAC může dojít

k problémům při aktualizaci, nebo samotné funkč-

nosti těchto aplikací na provozovaném portálu.

Tuto situaci jsme vyřešili stanovením jednoho z čí-

sel určených pro verzi, a to pro každou webovou

aplikaci samostatně. Z pohledu dvou aplikací je si-

tuace jednoduchá a určení padlo na rozlišení dle

sudé a liché. Posledním překvapením, přesto po-

těšujícím, je to, že MS SQL Server 2005 podporuje

pro optimalizaci pokládání dotazů výběr z části dat.

Při vývoji webových aplikací nám tato funkcionalita

přišla „jako na zavolanou“.

Dějství šesté - nasazeníNasazení systému proběhlo až nad očekávání hlad-

ce, řekl bych. Dílem i proto, že v našem případě již

všechny aplikace byly instalované v produkčním

prostředí a předtím proběhl pilotní provoz. Také

z toho důvodu, že jsme migraci již měli, jak se říká,

v malíčku. Co by se tedy dalo v tomto místě zmínit?

Jak se na to dívám zpětně, tak organizační část pře-

vedení systému s dopadem na všechny vstupující

subjekty se nám v časovém skloubení harmonogra-

mu ukázala výhodou.

Martin Janček

jancek@komix.cz

MeTODy a TeChnIKy OBjeKTOVĚ OrIenTOVanÉ analýZy

Tentokrát se zaměříme na základní metody a tech-

niky při analýze. Připomeneme si základní charakte-

ristiky disciplín Requirements Engineering a Object

Oriented Analysis, metody Object Behavior Analy-

sis a techniky Unified Modeling Language. Využi-

tím praktických zkušeností můžeme získat souhrn

jejich hlavních výhod.

rekapitulace disciplín pro popis poža-davků

requirements engineering (re) je osvědčená dis-

ciplína, vhodná pro popis uživatelských požadavků

složitějších systémů.

RE má především tyto cíle:

• zlepšeníkomunikacemezidodavatelemaodbě-

ratelem,

• dokumentacepožadavků,

• zpřesněnípožadavků,

• sjednoceníprotichůdnýchpožadavků,

• setříděnípožadavkůpodledůležitosti.

Použití RE má tyto důsledky:

• rychlývývojpožadavkůnastraněodběratele,

• formapopisujesrozumitelnáodběrateli,definu-

je CO se má řešit, ne JAK,

• včasnévyjasněnípriorit,

• méněproblémůpřipředánídílaodběrateli.

V minulém článku jsme se soustředili na strukturu

katalogu uživatelských požadavků – zmínili jsme

se o často používaných typech atributů požadav-

ku a popisu ve formě strukturovaného textu formá-

tovaného v tabulce. Právě to jsou charakteristické

rysy techniky používané při RE. Jedním z atributů

požadavku je také podrobný popis požadavku. To-

muto jedinému atributu se budeme tentokrát vě-

novat podrobněji.

Objektově orientovaná analýza (OOa) je mno-

hem mladší disciplína a je mnohem bližší objekto-

vě orientovaným technologiím realizace SW aplika-

cí. Může navázat na RE a sebrané požadavky popsat

podrobněji a ve struktuře vhodné pro využití ob-

jektových technologií.

Hlavním cílem OOA je taková struktura popisu, kte-

rá umožňuje snadnou modifikaci nebo jednoduché

doplnění bez nežádoucích vedlejších efektů. Použi-

tí OOA umožňuje tvorbu větších a složitějších sys-

témů. Pro OOA je charakteristické obohacení sta-

tického modelu o základní prvky chování systému

– metody tříd.

V minulém čísle KOMIXích novin 2007 / 2008 byl zveřejněn článek „Tvorba a využití katalogu uživa-

telských požadavků“. V tématu „uživatelské požadavky“ pokračujeme a volně navazujeme na uve-

dený článek z minulého čísla.

Při popisu požadavků je možné respektovat struk-

turu informací odpovídající objektovým dynamic-

kým a statickým modelům (viz rozdělení popisu

požadavků na popis okolí, chování a statické struk-

tury v minulém článku).

Object Behavior analysis (OBa) je jedna z prv-

ních metod OOA. Je velice jednoduchá, přesto do-

dnes jedna z „nejobjektovějších“ (vznikla společně

se Smalltalkem v ParcPlace Systems).

Metoda má tyto cíle:

• jednoduchýačistěobjektovýpopissystému,

• odvození popisu statického modelu od popisu

dynamického modelu.

Dokumentace vytvořená podle OBA je charakteris-

tická vysokou mírou integrity popisu systému (těs-

nými vazbami mezi dynamickým a statickým mo-

delem).

14

my (hodí se vý-

borně především

pro znázornění va-

zeb ve statickém

modelu nebo pro

popis variant při

postupu dynamic-

kým modelem).

Pro popis detailů

je vhodnější dobře

strukturovaný text

(v tabulce).

uMl diagramyV současné době

jsou UML diagramy

velmi často použí-

vaným prostřed-

kem pro dokumen-

taci požadavků.

UML obsahuje

mnoho typů dia-

gramů (více či mé-

ně specializova-

ných na různé činnosti). Někdy dochází k míchání

typů objektů z různých typů diagramů v jediném di-

agramu – to ztěžuje orientaci začátečníka ještě více.

Pro popis požadavků v dynamickém modelu jsou

vhodné diagramy:

• UMLActivity(vhodnýprojednoduchýpopispro-

cesů),

• UMLUseCase (vhodnýpropopis interaktivních

systémů).

Oba uvedené typy diagramů lze používat s výho-

dou v jediném do-

kumentu (podle

povahy přísluš-

né části úlohy).

Je důležité dbát

na jednoduchost

diagramu z hle-

diska kvalitativ-

ního (používejte

co nejméně typů

prvků na diagra-

mu) i kvantitativ-

ního (složité dia-

gramy přetvořte

na hierarchickou

strukturu jed-

noduchých dia-

gramů). Pro po-

pis požadavků

ve statickém mo-

delu použijte dia-

gram

•UMLClass

Při popisu poža-

davků není vhod-

né rozdělovat tří-

dy do skupin podle vrstev architektury (uživatelské

rozhraní, aplikační logika, databázová vrstva). Toto

rozdělení je nezbytné později při návrhu (volbě ar-

chitektury).Místotříd„Formulářobjednávky“,„Ob-

sluha objednávky“ a „Databázová tabulka objed-

návky“ je vhodné použít jedinou tzv. „doménovou“

třídu „Objednávka“. Analogie platí i o metodách ta-

kové doménové třídy – místo metod „Zobrazení

formuláře“, „Validace dat“ a „Uložení záznamu“ je

vhodné použít jedinou metodu „Uložení“.

Při popisu atributů stačí použít obecné datové ty-

py (řetězce definované maximální délky, čísla s da-

ným maximálním rozsahem, datum, čas, ...) – je to

vhodnější než použití konkrétních datových typů

programovacího jazyka nebo databázového serve-

ru. Volba konkrétního typu proběhne opět pozdě-

ji v rámci návrhu. Dodržení uvedených pravidel do-

ménového modelování má dva kladné následky:

• modely jsou jednodušší – tedy lépe čitelné při

schvalování odběratelem,

• zkušenýnávrhářdokáže lépeoptimalizovatpro

cílovou architekturu a technologie.

scénáře OBaPři použití několika modelů popisu požadavků

jsou důležité vazby mezi těmito modely. Tuto ne-

zbytnou podmínku kvalitního popisu požadavků

je možné zajistit s pomocí techniky scénáře z me-

tody OBA. Scénář OBA slouží k jednoduchému po-

pisu požadavků na chování. Má podobu tabulky, je-

jíž řádky popisují posloupnost vyvolání metod tříd.

Vlastní vyvolání metody třídy je popsáno v řádku

tabulky.

Na rozdíl od Use Case scénářů nepředpokládá scé-

nář OBA variantní cesty (Alternative Paths). Pro po-

Nejcennějším přínosem OBA je doplnění techniky

CRC (Class – Responsibility – Collaborator) o tech-

niku OBA scénářů, které detailně popisují dynamic-

ký model.

unified Modeling language (uMl) je poměrně

mladá technika, která pomáhá při OOA.

Cílem UML je jednotný způsob komunikace během

analýzy a návrhu. Výhodou je možnost snadného

a rychlého osvojení informací při předávání práce

v týmu. Pro UML je charakteristický popis pomocí

modelů, jejichž nedílnou součástí jsou standardizo-

vané diagramy.

Využití disciplín pro popis požadavkůPřednosti RE (popis strukturovaným textem) a OOA

(základní části katalogu uživatelských požadavků)

jsme zdůraznili v minulém článku. Tentokrát se za-

měříme na použití UML diagramů a OBA scénářů při

podrobném popisu požadavku v dynamickém mo-

delu. Detailní popis požadavků ve statickém mode-

lu není z pohledu tohoto článku tak důležitý – po-

pis atributů tříd vychází z tradiční metody datového

modelování, je doplněn popisem metod a rozšířen

je také popis typů vazeb.

Použití diagramu a strukturovaného textuPři popisu požadavků se občas setkáváme se dvě-

ma extrémy – stovkami stran textu bez jediného

obrázku nebo naopak s mnoha obrázky bez zjev-

ných návazností a bez jakéhokoliv vysvětlující-

ho textu. Doporučit lze samozřejmě střední cestu.

Pro vytvoření nadhledu je vhodné použít diagra-

Obrázek 1 – Volba techniky podle úrovně podrobnosti

Obrázek 2 - Použití uMl diagramů

Obrázek 3 - OBa scénář - vazby mezi modely

Obrázek 4 - správná míra podrobností

15

pis větvení je praktické (názorné) použít diagram

UML Activity.

Zápis OBA scénářů a údržbu vazeb mezi dynamic-

kým a statickým modelem automatizuje CASE ná-

stroj QuickCRC firmy Excel Software.

Úroveň podrobnosti požadavkuCelý článek se zabýval metodami a technikami ana-

lýzy požadavků, ale to samo o sobě začátečníkovi

nepomůže. Již v minulém článku byla zmínka o de-

finici požadavku „na úrovni uživatele“ jako protiklad

k popisu z pohledu programátora (pomocí termi-

nologie technologie IT). Ještě jednou připomínám

důležitost správné úrovně popisu požadavku!

ZávěrUvedené disciplíny, metody a techniky nestojí pro-

ti sobě. Vhodným výběrem jejich výhod je lze pro-

pojit do jednotného celku, který zůstává jedno-

duchým a účinným nástrojem pro dokumentaci

požadavků na různé úrovni podrobnosti.

Milan Číha

ciha@komix.cz

POhleD na DWh&MIs&BI (s ÚsMĚVeM !!!!) aneB CO nás čeKá a MIne/neMIne?

Nechť nám uvedené motto přiblíží skok, kterého

jsme v oblasti IT (ale samozřejmě i v jiných oblas-

tech) během historicky zanedbatelně dlouhého

resp. krátkého období svědky. Snad pro přiblížení,

ještě naši tatíci při hledání potřebných informací

využívali spíše zdroje lidské. Našinec dnes nejvýše

osloví kolegu, ale spíše si prvotní přiblížení dané-

ho problému „vygůgluje“ a poté volí další optimál-

ní postup.

Ale nezůstávejme u našince, takto více či méně pro-

fesně postižené IT osoby. Je vypovídající, že ob-

dobný postup volí nejen teenageři (tam je příklon

k novému, rychlému, … jistě očekávaný), ale i ta-

kové skupiny spoluobčanů, u kterých bychom toto

v době ještě nedávno minulé očekávali značně

méně (učitelé, lékaři, sousedi v domě, … ). Že všich-

ni tito již počítač z velké části využívají i pro čin-

nosti rozumné, spojené jak s profesí tak i s volným

časem, je další strana téže mince.

Zkusme se podívat výše uvedenou optikou na vý-

voj v oblasti DWH & MIS & BI a na to, kam vývoj

bude pokračovat dále. Jen pro ujasnění - tento ela-

borát si zcela jistě neklade za cíle býti strategickým

či prognostickým či jakýmkoliv jiným zásadním pří-

spěvkem k dané problematice. Spíše se jedná o leh-

kým perem pojatou krátkou rekapitulaci a stejným

způsobem pojatou vizi co by nás v blízké budouc-

nosti potkati mohlo.

Ti starší z nás si jistě dobře pamatují na okouzle-

ní z prvních on-line provozních IS, kdy jsme s ob-

divem sledovali kroky od pořízení dokumentu

až po jeho zaúčtování a zanesení všech relevant-

ních údajů do datových struktur. Postupem doby

se výše uvedené okouzlení posunulo kvalitativně

dále, z oblasti provozních IS do prostředí MIS, BI,

DWH či jak jsme si zvykli navazující nadstavbová ře-

šení nazývat. Dalším postupem doby se pak MIS, BI,

DWH staly nedílnou součástí dodávaných řešení,

objemy dat začaly nabývat objemů nebývalých.

S objemy dat se začaly rojit i další objemy tentokrát

terminologické – od zaužívaných ROLAPů, MOLA-

Pů, HOLAPů, CRM, ODS a přehršle dalších až k sou-

časně silně atraktivním záležitostem typu In Memo-

ry Analysis (že by IMA ?).

Kratince se u pojmu IMA zastavme - v čem tedy spo-

čívá kouzlo právě tohoto termínu? Věc je zdánlivě

prostá – veškerá data nejsou uložena v databázo-

vém prostředí, ale přímo v souboru na disku. Nu

a při práci s aplikací se celý tento soubor či jeho po-

třebná část načte do operační paměti a tudíž veške-

ré počítání, vyhledávání a další činnosti se dějí pří-

mo v operační paměti a tudíž velice rychle (odezvy

v jednotkách vteřin).

Potud teorie. Jaká ale byla praktická zkušenost

v KOMIXu?

Mnozí z Vás, kolegů, zaregistrovali, že v minulém

roce se stal součástí KOMIX nabídky v oblasti MIS,

BI, DWH produkt QlikView firmy QlikTech. Dodej-

me to podstatné – jedná se o produkt postavený

právě na výše zmíněné IMA architektuře. K prvním

kontaktům s firmou i produktem došlo právě před

rokem, následovalo seznámení, zaškolení a snaha

cosi prodat.

Rád bych se na tomto místě krátce vrátil právě

k seznamovací etapě. Je dobře známo, že v rámci

KOMIXu je zkušenost s produkty a řešeními pro ob-

last MIS, BI, DWH letitá a nasazená řešení jsou ve-

směs úspěšná a dlouhodobě provozovaná. Také

je známo, že během uplynulých let byly KOMIXu

představovány různé úžasně výkonné, uživatel-

sky komfortní, technologicky progresivní a i jinak

zázračná řešení od různých, většinou renomova-

ných dodavatelů. Druhou stránkou věci je skuteč-

nost, že z výše zmíněných řešení se mnohé nepo-

dařilo uspokojivě zprovoznit ani v „laboratorních“

podmínkách KOMIXu, a to ani s vydatným přispě-

ním specialistů dodavatele. A tak zůstalo u osvěd-

čeného řešení a občasné vpády revolučních novi-

nek byly brány shovívavě.

S výše popsanými zkušenostmi jsme proto při-

stupovali i ke zmíněnému produktu QlikView. Pro

rychlé posouzení proklamovaných vlastností se

nabízela cesta nejjednodušší – vzít fungující řeše-

ní s daným rozsahem dat a s danou funkcionalitou

(konkrétně DAPO1: Kmen pojištěnců) a celou zá-

ležitost převést do prostředí QlikView a otestovat,

zdali a jak bude řešení fungovat v novém prostře-

dí. Řečeno, vykonáno a ejhle. Ono to fungovalo nad

očekávání. Jen pro ilustraci – jednalo se o aplika-

ci s cca 25 mil. záznamů. Doby odezvy u standard-

ního řešení (MicroStrategy) se pohybovaly v závis-

losti na složitosti výstupu na úrovni 1 až 3 minut,

u rozsáhlých porovnání pak i k 8 minutám. Výstupy

v prostředí QlikView pak byly k dispozici za neuvě-

řitelných 1 až 3 vteřiny.

A rázem jsme u leitmotivu celého tohoto pojedná-

ní. Kam jsme došli (kdo to ví?) a kam že to spěje-

me? Máme mít obavy o to, co a jak bude následo-

vat, co a jak bude dál? Zjistíme jako naši předkové,

že ani IT svět není placatý (jako se předkům jevila

Země jako taková) a že obzory jsou otevřené? Kam

až dojde uplatňování nano, bio, a dalších technolo-

gií, o kterých zatím moc veřejnosti dostupných in-

formací není k dispozici ani v „gůglu“? Jak dlouho

ještě bude platit Mooreův zákon?

A co říci na závěr? Nenapadá mne nic lepšího, nežli

odkaz na kultovní TV seriál „Návštěvníci“. Míra vizi-

onářství zmíněného díla, reprezentovaná známou

„bradavicí“ v případě nutnosti umísťovanou na čelo

uživatele vyvolávala v době vzniku díla shovívavý

úsměv. V dnešní době však vyvolává spíše mrazení

– skutečně spěje vývoj k CML (pro nepamětníky –

Centrální Mozek Lidstva)? Aby se ještě Orwell a jeho

„Velký bratr“ tam někde nahoře nedivili …

a TeĎ VáŽnĚBusIness InTellIgenCe

frOM WIKIPeDIa, The free enCyClOPeDIa

sTanDarDIZaCe BI násTrOjůŘada podniků dnes pociťuje přeplněnost informa-

Nevíte, kde je tady nejbližší datový sklad?To nevím, ale zeptejte se u holiče,

tam to určitě budou vědět.

16

cemi. Množství a koncentrace dat v podnikových

databázích a dalších zdrojích dat narůstá. Naproti

tomu pokračující fragmentace BI nástrojů pro jejich

zpracování a vizualizaci redukuje možnosti reálné-

ho využití těchto informací. Proto dnes většina pod-

niků soustřeďuje své úsilí na standardizaci BI. Jejím

cílem je nejen snížení nákladů, ale i vytváření vyšší

hodnoty zpřístupněním podnikových informací ši-

rokému okruhu pravidelných a příležitostných uži-

vatelů. Výsledkem kombinace těchto faktorů bývá

zlepšení provozní výkonnosti podniku.

BI – násTrOj KOnKurenCesChOPnOsTI PODnIKáníBusiness intelligence, datové sklady a další souvise-

jící pojmy se staly nedílnou součástí světa jak infor-

mačních technologií tak managementu firem a in-

stitucí. Problematika BI jako celku je v současnosti

již velmi rozsáhlá. V tomto krátkém článku se bude-

me věnovat vybraným oblastem, které jsou z hle-

diska zákazníka pro úspěšnou realizaci BI systémů

stěžejní.

BI jako pojem. Přístup k BI.

Úvodem si pro účel tohoto článku dovolím upřesnit

vymezení pojmu business intelligence. Přesto, že se

s pojmem BI setkáváme stále častěji, je jeho obsah

mnohdy chápán odlišně. Z mnoha významů ang-

lického slova business vybereme výraz podniká-

ní. Pod pojmem intelligence pak nadále uvažujme

prostředí a v něm realizovaný nástroj pro podporu

rozhodování. Po sjednocení můžeme provést určité

zjednodušení a nadále rozumět pod pojmem BI ná-

stroj pro podporu konkurenceschopnosti podniká-

ní. V souladu s vymezením pojmu BI se změnil i pří-

stup k problematice samotné. Zdaleka již není ze

strany IT firem nutné tak velkého úsilí v oblasti pře-

svědčování zákazníků o výhodnosti BI řešení, jako

tomu bylo v nedávné minulosti. Naopak, stále čas-

těji se setkáváme s aktivním zájmem ze strany firem

či institucí. Zdálo by se, že tato situace je pro doda-

vatele BI bezmála ideální. Pro kvalitní realizaci ta-

kovýchto aktivních přístupů je však třeba věnovat

pozornost mnoha oblastem. V následujícím textu

se zmíním o některých z nich, které mají obecnou

platnost.

Zaměření BI.

Kvalitní BI řešení by zcela jistě mělo co nejvíce spl-

ňovat požadavky, citované prakticky ve všech pu-

blikacích k dané problematice. Uveďme alespoň ty

nejdůležitější.

Poskytnout uživateli řešení a současně i ná-

stroj. Dodržení této zásady umožní, aby uživatel

nebyl pasivním prvkem, žádající po někom dalším

realizaci svých požadavků, ale aby měl k dispozi-

ci prostředí pro přímou realizaci svých požadavků.

Uživatel se stává aktivním tvůrcem.

strukturovaná data a následně i informace.

Správné BI řešení musí být nástrojem pro přemě-

nu dat na informace. Otevřenost řešení. Otevře-

nost musí být podporována jak co do struktury dat

tak co do rozsahu. Všechny části řešení tak musí co

nejvíce podporovat schopnost dynamických změn

řešení jako celku. Klasickým záměrem BI řešení je

poskytnutí vybraných dat ve vhodně strukturo-

vané podobě pro podporu přehledových údajů,

analytických výstupů, realizaci ad-hoc dotazů, do-

lování dat, sledování trendů, vývojových řad a po-

dobně. Pro tyto oblasti jsou požadovány údaje ze

zdrojových provozních IS, včetně údajů archivních

a historických. V souladu s neustále se zvyšujícími

možnostmi HW a SW se však stále častěji ukazuje

možnost a výhodnost pokrytí některých typů vý-

stupů, které byly dříve realizovány výhradně v pro-

středí provozních IS.

Požadavky na BI. Přehnaná očekávání.

Výše zmíněné rozšíření možností BI řešení je pro za-

davatele záležitost velmi příjemná a žádoucí. Tento

široký záběr v sobě skrývá jisté záludnosti. Krátce se

pokusím popsat některé základní.

Požadavky. Pro úspěšnou realizaci BI řešení je zá-

kladním předpokladem definice požadavků, které

by měly být pokryty. Jak bylo uvedeno výše, záběr

BI je v současné době velmi široký. Při realizaci je sa-

mozřejmě možné stanovit soubory požadavků tře-

ba i ze všech oblastí a pojmout BI řešení jako projekt

velice rozsáhlý. Tento přístup však v sobě skrývá ne-

bezpečí, že požadavky na jednotlivé oblasti nebu-

dou specifikovány dostatečně přesně a úplně a ná-

vaznost jednotlivých oblastí ve výsledném řešení

nebude dostatečná. Pro minimalizaci komplikací

tohoto druhu je často vhodné využít jedné ze zá-

kladních vlastností řešení BI a DWH – otevřenosti –

a realizovat záměr po jednotlivých částech.

Přehnaná očekávání. Při definici požadavků je ne-

zbytná úzká spolupráce zákazníka se zkušeným do-

davatelem. Požadavky pro jednotlivé oblasti pak

lze snadněji definovat tak, aby je bylo možno BI ře-

šením maximálně pokrýt a současně eliminovat ty

požadavky, které je možné či vhodné řešit až v dal-

ších fázích projektu. Výše popsaným způsobem je

možné z velké míry omezit jedno ze zásadních ne-

bezpečí – přehnaná očekávání a následné zklamání

nad realizovaným řešením.

Data. Data. Data.

Pro pokrytí jakékoliv funkcionality jakýmkoliv ná-

strojem potřebujeme v souladu s definovaný-

mi požadavky zcela zásadní věc: vhodným způ-

sobem uspořádaná verifikovaná a konsolidovaná

data v prostředí datového skladu. Na tomto místě

je třeba citovat odhady renomovaných společnos-

tí, že převážnou příčinou (více než 50 % - dle pra-

mene) neúspěšnosti BI projektů jsou právě nekva-

litní data. Podle stejných zdrojů dochází často až při

snaze o BI řešení k odhalení významné části nesou-

ladů v datech provozních IS. Problém s daty je tedy

zřejmý. Podívejme se na to, jak jej nejlépe vyřešit.

Primární databáze.

Pro dosažení co nejvyšší kvality dat pro potřeby BI

se osvědčila architektura řešení s využitím primár-

ní databáze. Primární databáze je nejčastěji reali-

zována v prostředí zvolené relační DB. Do prostře-

dí primární databáze (PD) jsou z jednotlivých zdrojů

(provozní IS, historické a archivní údaje, vnější zdro-

je) přenášeny požadované číselníkové a hodnotové

údaje v požadované podrobnosti. V prostředí PD je

tedy k dispozici kopie vybraných provozních údajů.

Primární databáze pokrývá tyto základní a z hledis-

ka BI řešení nezbytné funkce:

• PDjejednoznačnědefinovanýmrozhranímmezi

prostředím provozních IS (obecně zdroji dat)

a prostředím DWH

• PDjezdrojemprorealizaciDWHjakocelkuajed-

notlivých specializovaných datových tržišť

• PD umožňuje jednoznačně odhalit případné ne-

soulady mezi výstupy BI řešení a údaji získávanými

nástroji provozního IS z prostředí provozních IS

Datová pumpa.

Datová pumpa (DP) je ta část BI řešení, která zajišťu-

je plnění struktur PD ze zdrojů dat (provozní IS, … )

a nad takto naplněnými a aktualizovanými údaji vy-

tváří a aktualizuje DWH struktury ve formě specia-

lizovaných datových tržišť. Problematika DP je jis-

tě značně rozsáhlá a pro účel tohoto příspěvku se

omezím pouze na popis základních skutečností.

Pro realizaci DP můžeme použít několik způsobů či

jejich kombinací. Jedná se o ETL nástroje (extrak-

ce, transformace, načtení) případně ETLC (extrakce,

transformace, načtení, čištění) či řešení DP specia-

lizovanou aplikací. Vhodnost použití jednotlivých

způsobů je silně závislá na typu, rozsahu a kvalitě

zdrojových údajů.

V případě, že kvalita dat v provozním IS je proka-

zatelně velmi dobrá a dále že množství a složitost

kontrol při plnění PD je dobře zvládnutelné ETL,

ETLC nástroji, je jistě na místě jejich použití.

Další možností je pro plnění PD vytvořit specializo-

vanou aplikaci. Toto řešení nám snáze pokryje po-

žadavky i na komplikované kontroly a řešení pří-

padných chybových stavů. Moderně vytvořené DP

ve formě specializované aplikace jsou řízeny vlast-

ními daty (metadaty). Takováto řešení umožňu-

17

jí významnou část požadavků na změnu či rozšíře-

ní funkčnosti DP realizovat právě úpravou metadat

bez zásahu do aplikace jako takové.

Při výběru řešení na realizaci DP je třeba pečli-

vě zvážit výše uvedené skutečnosti. Při volbě ETL,

ETLC nástroje je zřejmé, že čím je daný nástroj vý-

konnější a komfortnější, tím bývá i jeho cena vyšší.

Též samotné zakoupení nástroje není konečnou zá-

ležitostí, požadované řešení je třeba implemento-

vat. Při volbě aplikace je třeba dbát na to, aby rea-

lizované řešení bylo maximálně otevřené (viz řízení

metadaty) a podporovalo uvažované úpravy či roz-

šíření pro další fáze BI řešení.

Otevřenost BI řešení

Otevřenost BI řešení je pojem, který prolíná vše-

mifázemirealizacejakočervenániť.Frekvencevý-

skytu tohoto pojmu může být často až nepříjemná,

avšak na základě zkušeností s realizací je třeba kon-

statovat, že se jedná o vlastnost skutečně zásadní.

Otevřenost pro oblast struktury dat, objemu dat

a pokrytí uživatelských požadavků jsou pojmy, kte-

ré se prolínají a jsou na sobě závislé.

struktura dat. Zmínili jsme se, že BI řešení jsou čas-

to s výhodou realizovaná po menších částech, eta-

pách. Je samozřejmým požadavkem, že struktury

dat realizované v úvodních částech budou využitel-

né i v dalších částech. Současně je zřejmé, že bude

docházet k jejich rozšiřování v souvislosti s realiza-

cí dalších požadavků. BI řešení tak musí podporovat

snadné zahrnutí přenosu dalších údajů ze zdrojo-

vých IS do prostředí PD a následně do navazujících

struktur DWH.

Objem dat. Tato oblast bývala v minulosti, v době

podstatně menších možností HW a systémového

SW, často kritickou částí řešení. Je třeba si uvědomit,

že účelně navržené struktury DWH často bývají roz-

sáhlejší, než struktury zdrojových IS. V prostředí PD

jsou vytvářeny kopie vybraných údajů provozních IS,

včetně údajů archivních a historických. Pro pokrytí

požadavků na rychlou odezvu jsou v prostředí DWH

vytvářeny potřebné agregované struktury.

uživatelské požadavky. Architektura BI řešení je

otevřená také z hlediska uživatelských požadavků.

Jak bylo výše zmíněno, nabízí se realizace BI řeše-

ní po jednotlivých částech, které pokrývají rozdílně

zaměřené skupiny uživatelských požadavků. Při de-

finování nových požadavků lze s výhodou vycházet

z realizovaných částí a maximálně využít již realizo-

vaných datových struktur a příslušných částí řešení.

Závěrem …

Pokud se nám podaří navrhnout a posléze realizo-

vat BI řešení co nejvíce splňující v úvodu uvedené

teze, jsme na dobré cestě dostát často citovaným

sloganům typu „Změňte svá data na konkurenční

výhodu“ a naopak vyhnout se varujícím odhalením

typu „Manažeři nedostatečně využívají možností BI

řešení“.

Jak je zřejmé, v tomto příspěvku jsme se zabývali

pouze vybranými částmi BI řešení. Neméně pod-

statným částem – například oblasti publikování

a komunikace – se budeme věnovat v některém

z dalších příspěvků.

Pavel Seibert

seibert@komix.cz

18

1. Úvodem

Smyslem tohoto krátkého sdělení je upozornit

na vlastnosti nejnovějších verzí databázového ser-

veru IBM Informix, které umožňují mnohá praktická

rozšíření jak pro vývoj aplikací, tak pro optimaliza-

ci a monitoring jejich provozu. Autor se soustředil

zejména na vlastnosti, které subjektivně považuje

za nejvýznamnější z hlediska správy databázového

serveru a ze znalosti provozu u našich zákazníků,

kteří se již zejména o verzi 11 zajímají. Verze 11.10

byla oficiálně uvedena na trh v červenci 2007 a ver-

ze 11.50 v květnu 2008.

2. novinky ve verzi 10.00

Volitelná velikost stránky

Od verze 9.40 je možné vytvářet databázové pro-

story (dbspace), jejichž základní velikost (velikost

chunku) není omezena na 2GB. Implicitně bylo

nastaveno, že správu velkých chunků je nutno na-

stavit ručně, od verze 10 je tato správa automaticky

zapnuta při instalaci. Nově verze 10 umožňuje ur-

čit velikost stránky dočasného nebo standardního

datového prostoru dbspace při jeho vytváření. Lze

určit jinou velikost než je velikost výchozí, pokud

je potřeba větší délka klíče než odpovídá výchozí

velikosti stránky. Kořenový prostor dbspace sestává

vždy ze stránek výchozí velikosti. Velikost stránky

musí být celočíselný násobek výchozí velikosti, ma-

ximálně však 16 kB.

Definování společných oblastí vyrovnávací pa-

měti

KonfiguračníparametrBUFFERPOOLdefinuje spo-

lečnou oblast vyrovnávací paměti, která odpovídá

velikosti stránky prostoru dbspace. Správce serveru

může tuto oblast definovat též pomocí obslužné-

ho programu onparams. Kromě velikosti stránky

definuje parametr BUFFERPOOL počet stránek

vyrovnávací paměti, počet front LRU ve společné

oblasti a hodnoty lru_min_dirty a lru_max_dirty.

KonfiguračníparametryBUFFERS,LRUS,LRU_MAX_

DIRTY a LRU_MIN_DIRTY se již nepoužívají.

správa prostoru tblspace typu tblspace

Správa prostoru tblspace typu tblspace je pružněj-

ší. Prostor tblspace typu tblspace je sada stránek,

které popisují umístění a strukturu všech prosto-

rů typu tblspace v daném prostoru typu dbspa-

ce. Pomocí obslužného programu onspaces lze

přesunout nebo vypustit blok obsahující prostor

tblspace typu tblspace. Velikost první i následující

oblasti jevolitelnápomocíparametrůTBLTBLFIRST

a TBLTBLNEXT. Tato vlastnost umožňuje snížit počet

oblastí prostoru tblspace typu a snížit počet přípa-

dů, ve kterých se tyto oblasti nacházejí v jiných než

primárních blocích.

administrace databázového serveru v jednouži-

vatelském režimu

Administrátor databázového serveru může nyní vy-

užít nový jednouživatelský (single-user) režim, který je

přechodným režimem mezi quiescent a online. Na rozdíl

od režimu quiescent přijímá nová připojení pouze pro

uživatele informix. Pomocí tohoto režimu může

administrátor provádět libovolné úlohy administra-

ce včetně úloh vyžadující provádění příkazů jazyků

SQL a DDL, zatímco k serveru nejsou připojeni jiní

uživatelé.

správa přístupových oprávnění pomocí výcho-

zích rolí

Administrátor může vytvořit roli, přidělit jí opráv-

nění a přiřadit ji jako výchozí roli jednotlivým uži-

vatelům nebo skupině PUBLIC na úrovni databáze.

Každý uživatel, jemuž je přidělena výchozí role, získá

oprávnění této role společně s libovolnými dalšími

oprávněními udělenými jednotlivě. Výchozí role pů-

sobí automaticky od okamžiku přihlášení uživatele

k databázi, aniž by ji bylo nezbytné nastavit příka-

zem SET ROLE. Nová syntax příkazů GRANT, REVOKE

a SET ROLE podporuje tuto vlastnost, která může

poskytnout vhodná oprávnění k databázovým

objektům skupině uživatelů v relacích, ve kterých

spouštějí aplikace bez příslušných příkazů GRANT.

Přejmenování prostorů typu dbspace

Uživatel informix nebo uživatel s oprávněním ad-

ministrátora DBA mohou v režimu quiescent nebo

single-user přejmenovat dříve definovaný standardní

prostor typu dbspace. To může být zapotřebí při re-

organizaci dat ve stávajícím prostoru typu dbspace.

Vytvoření několika oddílů tabulky nebo indexu

v prostoru typu dbspace

V případě fragmentovaných tabulek využívajících

schéma distribuce založené na výrazu nebo typu

cyklická obsluha (round robin) lze nyní vytvořit více

oddílů, které jsou kolekcemi stránek tabulky nebo

indexu v jediném prostoru typu dbspace. Pomocí

nového klíčového slova PARTITION a názvu oddílu

lze vytvořit tabulky a indexy s oddíly a vytvářet, vy-

pouštět nebo měnit fragmenty oddílů.

určení událostí, které spouštějí program alarm

Program

Pomocí nového konfiguračního parametru ALRM_

ALL_EVENTS se definuje rozsah událostí, které

spouští alarm.

určení sdílené paměti větší než 4 gB

Segmenty sdílené paměti lze vytvořit tak velké, jak

dovoluje platforma operačního systému nebo para-

metr SHMMAX.

nastavení replikace hDr s externím zálohová-

ním a obnovením

Replikaci High-Availability Data Replication lze pou-

žít k externímu zálohování a obnovení pomocí stan-

dardních příkazů onbar a ontape.

Opětné odesílání indexů do sekundárních ser-

verů replikace hDr

Lze znovu odeslat index, který je v sekundárním

indexu páru replikace HDR poškozený. Opětné

odeslání indexu je rychlejší než vypuštění a opětné

vytvoření indexu v primárním serveru. Tato funkce

zvyšuje dostupnost primárního serveru replikace

HDR.

Přejmenování instance serveru Dynamic server

v systému Windows

Obslužný program IBM Informix Server Instance

Manager obsahuje možnost změnit název instan-

ce serveru Dynamic Server v systému Windows.

Ke změně názvu již není zapotřebí odinstalovat

a přeinstalovat server ani vytvořit novou instanci

a znovu zavést data.

Zjištění informací o verzích

Volba -version všech obslužných programů serveru

vypisuje podrobné informace o operačním systému

sestavení, číslu sestavení a datu sestavení. Volba -ver-

sion poskytuje více informací než stávající volba -V.

Podpora formátu adres IP IPv6

Pro adresy IP lze se serverem Dynamic Server pou-

žít formát IPv6. Ovladač IBM Informix JDBC Driver

verze 3.0 s podporou prostředí JDK 1.4 podporuje

formát IPv6. To znamená, že kód analyzující adresu

URL připojení dokáže zpracovat dlouhou (režim 128

b) adresu IPv6 (stejně jako formát IPv4). Tato adresa

IP může být literálem formátu IPv6.

Vylepšení výkonu

Vylepšení výkonu zahrnují zlepšený výkon dotazů

a čas potřebný pro zotavení. Dále bylo dosaženo vy-

lepšeného výkonu v následujících oblastech:

• transakceXA

• vnořenálevávnějšíspojeníkompatibilní

se standardem ANSI

• poddotazy

• úplnávnějšíspojení

Vytváření a vypouštění indexů bez uzamykání

tabulek

Pomocí nových příkazů CREATE INDEX ONLINE

a DROP INDEX ONLINE se vytváří a vypouští indexy

v režimu online, zatímco databáze a přidružené ta-

nOVÉ VlasTnOsTI VerZí 10 a 11 DaTaBáZOVÉhO serVeru IBM InfOrMIX

19

bulky jsou trvale dostupné. Tyto příkazy jazyka SQL

umožňují vytvářet a vypouštět indexy, aniž by bylo

nutné uzamknout tabulku po dobu vytváření nebo

vypouštění indexu.

3. novinky ve verzi 11

Instalace

Pokud administrátor preferuje grafické uživatelské

rozhraní při instalace IDS má možnost spustit skript

ids_install s argumentem –gui. Implicitně zůstává

instalace v klasickém znakovém prostředí. Nově byl

přidán skript pro odstranění instalace.

rozšířená škálovatelnost replikací

Zavedením tzv. Multi-node Active Cluster for High

availability (MaCh11) dochází k výraznému rozšíře-

ní dosavadních možností sdílení datových prostorů

a replikačních konfigurací. Kromě již známých hDr

a eDr lze vytvořit tzv. Remote Standalone Servers (rss), což

jsou sekundární databázové servery s asynchronní

obousměrnou komunikací. Na rozdíl od hDr není

omezen počet rss. Další variantou je tzv. Continual Log

Restore (Clr), kdy je tento sekundární server trvale

ve stavu rychlé obnovy a v případě výpadku pri-

márního serveru jej lze manuálně přestavět na pri-

már. Clr je určen pro edice Workgroup a Express. Dalším

rozšířením funkcionality MaCh11 je možnost mo-

difikace dat na sekundárních serverech a možnost

definice pořadí přepínání serverů v clusteru.

Zlepšení výkonnosti

Nová implementace kontrolních bodů (checkpoints) –

starší verze často trpěly dlouhou dobou blokování

provozu během kontrolního bodu. Problém se běž-

ně řeší snižováním hodnot parametrů LRU_MIN_

DIRTY a LRU_MAX_DIRTY resp. atributů lru_min_

dirty a lru_max_dirty u parametru BUFFERPOOL,

což vede k výraznému nárůstu zátěže procesorů.

Poslední úpravy mechanismu kontrolního bodu

vedly ke zrušení fuzzy checkpoints a novou technikou au-

tomatického kontrolního bodu se dosahuje toho, že

blokování kontrolním bodem je uživatelsky nepozo-

rovatelné. Stanovení maximální doby zotavení – za-

vedením nového parametru RTO_SERVER_RESTART

lze nastavit dobu, po níž při výpadku začne server

automaticky provádět proces fast recovery, tj. obnovení

konzistence dat pomocí logů.

Automatizované dynamické ladění IDS se týká již

zmíněných automatických kontrolních bodů, dy-

namického ladění počtu lru, aIO VP a stanovení

rychlosti I/O operací pro fyzický a logický log při zo-

tavování. Pro CPu VP je možné vyhradit paměť.

administrace

Při instalaci databázového serveru je nově genero-

vána databáze sysadmin, která zachycuje historii

příkazů a správce databázového serveru má pomocí

vestavěných funkcí task a admin možnost monito-

rovat historii provozu.

Nové obslužné vlákno (thread) umožňuje automati-

zovat proces monitorovacích a administrativních

úloh a to na úrovní SQL, SPL i uživatelských funkcí.

Konfigurační parametr SQLTRACE deklaruje úroveň

sledování a analýzy SQL příkazů. Škálovatelnost je

ve čtyřech stupních a počet sledovaných dotazů je

nastavitelný. Sledování lze provádět globálně nebo

specifikovat uživatele.

Nedostatkem starších verzí byla skutečnost, že

po importu dat resp. masivním příkazu INSERT,

DELETE nebo UPDATE bylo nutno ručně provést ak-

tualizaci systémového katalogu příkazem UPDATE

STATISTICS… Verze 11 tyto statistiky automaticky

aktualizuje na úrovni LOW a MEDIUM.

Při zapnutí výpisu query plánu se zatím generoval je-

diný soubor sqexplain.out, do kterého se zapisovaly (ap-

pend) všechny informace. SQL příkazem SET EXPLAIN

FILETO<jmeno>lzedefinovatvýstupnísouborpro

konkrétní SQL dotaz.

4. ZáVĚrSmyslem článku není poskytnout úplnou informaci

o nových vlastnostech IDS verze 10 a 11, ale obrátit

pozornost jak vývojářů, tak uživatelů na možnosti,

které tyto verze poskytují. Po některých vlastnos-

tech již bylo dávno voláno (nastavitelná velikost da-

tové stránky, lepší mechanismus kontrolních bodů,

rozšíření SQL aj.), jiné mohou pomoci řešit provozní

problémy zejména rozsáhlých aplikací s velkým po-

čtem uživatelů. Na závěr si autor dovolí drobnou

poznámku o tom, že společnost KOMIX má vlastní

program pro trasování SQL dotazů již od roku 1994

a mnohokrát ho u zákazníků úspěšně použila.

Petr Paul

paulp@komix.cz

nOVÉ VlasTnOsTI OraCle DaTaBase 11gV srpnu 2008 uplynul jeden rok od prvního vydání

verze 11g databázového serveru Oracle a v okamži-

ku, kdy čtete tyto noviny, je již možná venku Release

2 verze 11g. Máme tedy nejvyšší čas podívat se, co

je ve verzi 11 nového, abychom to stihli, než Oracle

přijde s verzí 12.

Je jistě pouze náhodná shoda okolností, že zhruba

ve stejnou dobu jako Oracle doklopýtal k verzi 11

i nejmenovaný jiný databázový server. V každém

případě verze 11g Oracle vznikla v reakci na kon-

krétní potřeby zákazníků a prohlubuje cíle, které si

začaly klást již předešlé verze Oracle, zejména 10g:

• snadné užití (správa a provoz, změna/upgrade,

vývoj aplikací),

• použitelnostprovšechnydruhydatavcelémži-

votním cyklu,

• vysoká kvalita služeb a technologie umožňující

vyniknout aplikacím.

Hezký, i když ne zcela úplný popis nových vlastnos-

tí verze 11g najdete např. na adrese http://www.

oracle.com/technology/pub/articles/oracle-data-

base-11g-top-features. Zde se pokusíme stručně

charakterizovat nové vlastnosti zajímavé pro vývo-

jáře, ale také pro datové architekty a testery aplika-

cí. Laskaví čtenáři nám doufejme odpustí smíchání

anglické a počeštěné terminologie.

Virtuální sloupce

Tabulka může mít virtuální sloupce, jejichž hod-

noty nejsou uloženy, nýbrž odvozují se dynamicky

pomocí SQL výrazů z ostatních sloupců. Virtuální

sloupce mohou být indexovány funkčními indexy.

sQl operace pivot a unpivot

V dotazu lze použít konstrukci unpivot, která „otá-

čí“ data z několika sloupců výsledku do řádků, a po-

dobnou konstrukci pro opačný směr „otočení“ (jejíž

funkce bohužel není zcela inverzní).

Partitioning

Jsou přidány další kombinace způsobů víceúrovňo-

vé segmentace tabulek. Dále, lze segmentovat též

dle virtuálních sloupců, dle referenčního omezení

(segmentace je pak dána segmentací otcovské ta-

bulky) nebo bez předem daných hranic resp. pravi-

del (zařazení do konkrétní partition explicitně volí

aplikace v každém příkazu insert). Lze též použít

intervalovou segmentaci s automatickým vytváře-

ním nových partitions dle potřeby.

OlTP Table Compression

Je přidán nový způsob komprese relačních dat,

s nímž se zmenšuje objem dat uložených na disku

(běžně cca 2-4x, ale to asi bude záviset na datech),

zrychluje se fyzické čtení a snižují se nároky na da-

tabázovou cache, do níž jsou bloky načítány též

v komprimovaném stavu. Komprimovaný blok ob-

sahuje „symbol table“ s hodnotami, které se v něm

opakovaně vyskytují; v místech výskytů jsou pak

jen odkazy. Blok není komprimován při každém zá-

pisu dat, ale jen tehdy, je-li dosaženo určitého pra-

hu zaplnění bloku - režie komprese při zápisu tak

činí údajně pouze několik procent.

20

secure files

Je přidán nový způsob uložení LOB (velkých ob-

jektů), který kombinuje výhody uložení v databázi

s výhodami obvyklými při uložení v souborovém

systému. Máte tak k dispozici rychlý přístup k vel-

kým objektům, zajištění jejich konzistence a mož-

nosti zálohování, šifrování, komprese, deduplika-

ce a kontrolovaného cachování a logování změn.

Deduplikace znamená, že při opakovaném výskytu

téže hodnoty ve sloupci se hodnota LOBu ukládá

jen jednou, v dalších výskytech se ukládá jen od-

kaz na ni. Pro kompresi používá databázový server

standardní kompresní algoritmy - ale jen tehdy, je-

li šance na úsporu objemu daného LOBu. Kromě

potlačení logování změn můžete též logovat jen

metadata o LOBu, což podobně jako v souboro-

vých systémech postačuje k obnově při výpadku.

Způsob uložení LOBů v tabulce a jejich vlastnosti

se volí v příkazu create table a alter table, techniky

práce s LOBy v aplikaci se nemění.

XMl Binary storage

Je přidán další způsob uložení dat typu XMLType,

který kombinuje výhody nestrukturovaného ulo-

žení XML v CLOB s výhodami objektově relačního

uložení založeného na schematu XML (úspora pro-

storu a možnost rychlého relačního přístupu k prv-

kům XML).

OlaP

Pokračuje integrace OLAP do databázového ser-

veru. Je možné používat materializované pohledy

OLAP, pro které fungují mechanismy automatické

aktualizace a query rewrite SQL dotazu na kostky

OLAP. Metadata OLAP jsou součástí systémového

katalogu a pro OLAP objekty se používají standard-

ní mechanismy řízení přístupových práv. K dispozici

jsou skripty pro přípravu kostek, které v řadě aplika-

cí mohou nahradit programování kostek.

DDl_lOCK_TIMeOuT

DDL příkazy, které potřebují zamknout tabulku,

doposud končily chybou, pokud zámek nebyl mo-

mentálně dostupný (např. pokud uživatelská trans-

akce držela zámky řádků tabulky). Toto chování lze

pozměnit nastavením parametru ddl_lock_time-

out pro seanci či celý databázový server: server se

pak pokouší provést příkaz DDL, dokud není zámek

dostupný a dokud nevypršel zadaný timeout.

flashback Data archive

Tento prostředek slouží pro audit, undo, debug

změn dat či pro uchování historie dat požadované

některými právními předpisy. Historie dat uživa-

telské tabulky se uchovává v interních tabulkách

(SYS_FBA_*)povytvořeníarchivupříkazemCREATE

FLASHBACKARCHIVEapředepsánímdanéhoarchi-

vu pro uživatelskou tabulku pomocí příkazu ALTER

TABLE. Archiv můžete umístit do samostatného

tabulkového prostoru - třeba na nízkonákladové

disky. Archiv se automaticky čistí podle přede-

psané doby retence. Historická data se z archivu

vytahují pomocí SQL dotazu s modifikátorem AS

OFTIMESTAMPjménauživatelskétabulkyveslož-

ce FROM (podobné možnosti byly zavedeny již

veverzi9iresp.10gvespojenísnástrojiFlashback

Queryresp.FlashbackVersionsQuery;tytonástroje

ovšem využívají undo informaci, která má omeze-

nou životnost).

Transaction flashback

PomocíproceduryDBMS_FLASHBACK.

TRANSACTION_BACKOUT či grafického prostředí

Enterprise Manageru lze stornovat zadanou trans-

akci včetně transakcí na ní závislých (pracujících

s daty v ní modifikovanými). Databázový server při

stornování vychází z undo a redo informace.

Continuous Query Notification

Můžete předepsat a programově zpracovávat au-

tomatické notifikace o změně tabulek, na které se

odkazuje zadaný SQL dotaz, nebo o změně výsled-

ku dotazu.

result Cache

Výsledky SQL dotazů a PL/SQL funkcí lze uchovávat

pro opakované užití ve vyhrazené oblasti sdílené

paměti databázového serveru. Uchovaný výsledek

se automaticky aktualizuje, pokud se od jeho před-

chozího použití změnil obsah tabulek, z nichž se

odvozuje; cachování neustále se měnících výsledků

bychom se ovšem asi měli vyhnout.

Mechanismus cachování můžete aktivovat pro

zvolený dotaz či poddotaz (pomocí hintu result_

cache), pro všechny dotazy (nastavením parametru

result_cache_mode=FORCE)aprozvolenoufunkci

(pomocí speciálního zápisu na konci její hlavičky).

Můžete též využít obdobné cachování výsledků

dotazů na klientech (pro klienty založené na OCI8

driverech), jímž se navíc sníží zátěž sítě a využije se

lacinější paměť.

Connection Pool

Aby odpadlo opakované vytváření databázových

připojení, které je poměrně náročné, bývá v apli-

kacích zaváděn connection pool.

Nyní můžete využít pooly zřízené přímo v databá-

zi, sdílené podle potřeby větším počtem aplikač-

ních serverů či aplikací.

nativní kompilace Pl/sQl

Lze jednoduše předepsat nativní kompilaci PL/

SQL (či Java) programů bez nutnosti zavádět

C-kompilátor a starat se o knihovny v souborovém

systému.

Šifrování a maskování dat

Je přidána možnost šifrování tabulkových prostorů

(bez potíží s indexy), exportovaných dat a záloh; při

exportu dat můžete též předepsat maskování citli-

vých dat pomocí zvolené uživatelské funkce.

sQl Plan Baselines

Je zaveden mechanismus pro automatizovanou

a kontrolovanou podporu dobrých výpočetních

plánů. Uchovává se historie plánů, v níž klíčovou

roli hrají dobré plány uložené jako „plan baselines“.

Plány se zařazují jako baselines buď ručně nebo

automatizovaně (je-li to předepsáno parametrem

optimizer_capture_sql_plan_baselines=TRUE); op-

timalizátor vybírá plán pouze tehdy, je-li výrazně

lepší než stávající. Ruční správu plánů lze provádět

z příkazové řádky i z grafického rozhraní Enterprise

Manageru, které mimo jiné poskytuje i nabídku pro

srovnání výkonnosti kandidátského plánu s dosa-

vadním baseline.

rozšířené statistiky dat

Optimalizátoru lze pomoci při výběru vhodného

výpočetního plánu zavedením statistiky popisující

rozložení hodnot výrazu nad sloupcem či statistiky

rozložení hodnot v kombinaci sloupců. Tyto statis-

tiky jsou užitečné, pokud výraz zkresluje rozložení

hodnot sloupce resp. pokud jsou sloupce navzájem

závislé.

adaptivní kursory pro příkazy s bind-proměn-

nými

Optimalizátor při opakovaných výpočtech příka-

zu SQL s vázanými proměnnými postupně zjišťuje

a začíná využívat případnou závislost optimálního

výpočetního plánu daného příkazu na hodnotách

vázaných proměnných. Závislost bývá způsobena

nerovnoměrným rozložením hodnot sloupců tabu-

lek srovnávaných s hodnotami proměnných.

automatic sQl Tuning advisor

Automatické ladění SQL je založeno na nástro-

ji SQL Tuning Advisor zavedeném ve verzi 10g.

Nástroj umí pro zadaný příkaz či příkazy SQL na-

vrhnout vylaďující opatření typu přidání indexu,

přepsání příkazu, přepočet statistik dat či přidání

SQL Profilu (doplňujících statistik specifických pro

daný příkaz, získaných vzorkováním dat a dílčími

výpočty). Ve verzi 11g může být nástroj automatic-

ky spouštěn v časovém okně údržby systému pro

nejnáročnější příkazy určené podle statistik výpo-

čtu příkazů za uplynulé období. Navrhne-li nástroj

doporučení typu SQL Profile, jsou tato doporučení

hned vyzkoušena, a přináší-li alespoň trojnásobné

výkonnostní zlepšení, jsou automaticky zavedena

(ostatní doporučení zůstávají uložena v databázi

pro pozdější ruční využití).

Partition advisor a sQl access advisor

Je přidán nástroj pro návrh segmentace tabu-

lek. Nástroj je zároveň integrován do SQL Access

Advisoru zavedeného ve verzi 10g a sloužícího pro

celkové vyladění schématu vůči sadě sledovaných

příkazů SQL. SQL Access Advisor nyní umí navrh-

nout optimální kombinaci přidání a zrušení indexů,

materializovaných pohledů a partitions s ohledem

21

na sledované příkazy SQL, jejich náročnost a čet-

nost výskytu a předpokládané přínosy i náklady

na udržování přístupových cest (indexů apod.).

sQl Test Case Builder

Pomocí balíku dbms_sqldiag nebo pomocí grafic-

kého prostředí Enterprise Manageru můžete vyex-

portovat do souboru veškeré informace potřebné

pro spuštění zadaného SQL příkazu a naimporto-

vat je do testovacího prostředí. Informace zahrnují

např. samotný příkaz, jeho výpočetní plán, po-

třebná data a metadata (definice tabulek a dalších

objektů, úplná data či jejich vzorky, statistiky dat),

údaje o uživateli a o prostředí kompilace a výpočtu

příkazu. Poznamenejme, že balík dbms_sqldiag

poskytuje též funkčnost SQL Repair Advisoru, kte-

rý vám může pomoci vyřešit resp. obejít případné

bugy Oracle hlášené při zpracování SQL příkazu.

Database replay

Tento nástroj umožňuje zaznamenat aktivity v da-

tabázi (SQL příkazy) do souborů, znovu je přehrát

v téže nebo jiné databázi a prostředí a srovnat

výkonnostní statistiky za období zaznamenávání

a přehrávání. Slouží tak např. pro otestování vlivu

různých změn v databázi či jejím prostředí na pl-

nění aplikačních požadavků. Jako změna může

vystupovat např. instalace patche, upgrade OS

či databáze, přechod na clusterovanou databázi,

změna platformy, nastavení parametrů databáze,

statistik optimalizátoru či indexů apod. Při užívání

databáze Replay se mohou hodit i jiné mechanismy

poskytované databázovým serverem Oracle, napří-

klad Flashback Database pro pohodlnou obnovu

výchozího stavu dat nebo Standby Snapshot pro

pohodlné využití standby databáze jako testovací-

ho prostředí.

sQl Performance analyzer

Tento nástroj slouží pro ověřování vlivu různých

změn na výpočet zvolených příkazů SQL. Přehrává

sledované příkazy před a po změně a kvantitativně

srovnává výkonnostní statistiky z obou přehrání.

Umožňuje snadno předem stanovit vliv povýšení

verze optimalizátoru či změny inicializačního pa-

rametru, ale i jiných změn, např. přidání či ubrání

indexů a přepočtu statistik dat. Při naposled zmí-

něných změnách lze využít i další dvě nové vlast-

nosti – „skrytí“ indexu před optimalizátorem, resp.

dočasnou aktivaci statistik s odloženou platností

(nastavením parametru optimizer_use_pending_

statistics=true).

je to vše?

Na všechny nové vlastnosti verze 11g se zde nedo-

stalo. Nejvíce jsme asi ošidili databázové adminis-

trátory. Neprobrali jsme též produkty Oracle, které

více či méně souvisejí s databázovým serverem

– a tyto produkty se množí s tím, jak Oracle kom-

plexně pokrývá více a více oblastí potřeb zákaz-

níků. Zmiňme alespoň tři nástroje dodávané spo-

lečně s databázovým serverem - SQL Developer,

Warehouse Builder a Application Express (nástroj

pro snadné sestavování a zavádění webových apli-

kací nad databází bez nutnosti většího programo-

vání). Z dalších produktů zmiňme alespoň Times

Ten In-memory Database pro extrémní požadav-

ky na rychlost a Enterprise Manager, který byl pri-

márně určen pro správu a monitorování produktů

Oracle a nově umí např. monitorovat aplikace z po-

hledu koncového uživatele.

licencování

Znějí vám názvy nových vlastností verze 11g jako

jména cizokrajných zemí, do kterých jste se odjak-

živa toužili podívat? Zdá se, že tyto země máte nyní

za humny – jen si na některé z nich musíte dokoupit

příslušné options k databázovému serveru Oracle

Enterprise.

Jan Rada

rada@komix.cz

vytvoříme vám řešení na míru VýVoj aplikací manažerské informační systémy systémy pro podporu obchodu procesní a projektoVé řízení testoVání aplikací monitoring a podpora proVozu is

KOMIX s.r.o.Avenir Business Park Radlická 751/113e150 00 Praha 5tel.: +420 257 288 211fax: +420 257 288 221sales@komix.cz

Zelený KOMIX

Proč se KOMIX věnuje také ekologii, životnímu pro-

středí a jak to souvisí s IT technologiemi? Jedí snad

zaměstnanci pouze bio jogurty a jiné biopotraviny,

nebo chodí do práce pěšky nebo jezdí na kole?

Ekologie je trendem 21. století a ekologické chová-

ní se stává nedílnou součástí dnešního běžného ži-

vota některých občanů, firem a také i IT firem. Při

dodržování norem ekoprovozu mohou IT firmy do-

sáhnout dvojího efektu v podobě úspor nákladů

a ochrany životního prostředí. Nejlepší firmy v obo-

ru IT postupně „zelenají“. Příkladem může být inicia-

tiva Big Green, společnosti IBM, jejíž cílem je dosáh-

nout co největších energetických a jiných úspor.

jak je to tedy u nás v KOMIXu?Vedení společnosti KOMIX se v souvislosti s poža-

davky zákazníků státní správy při výběrových říze-

ních a v rámci společensky odpovědného chování

rozhodlo v roce 2006 zavést systém environmen-

tálního managementu (EMS) podle standardu ISO

14001. EMS je systémem managementu, který je

zaměřen na sledování a zlepšování všech činnos-

tí společnosti, které ovlivňují nebo mohou ovliv-

nit kvalitu životního prostředí. Životní prostředí se

přitom chápe v širokém kontextu ochrany přírody,

ochrany zdraví zaměstnanců i kvalitního pracovní-

ho prostředí.

Z hlediska působení na životní prostředí nemá naše

společnost žádné významné environmentální as-

pekty (prvek, který může ovlivňovat životní pro-

středí). Například nemáme v naší společnosti žádný

nebezpečný odpad související s vyráběným pro-

duktem. Charakter naší výroby v KOMIXu je už ta-

kový, že k naší „výrobě“ nepoužíváme ani žádné

chemické látky nebo přípravky, které by bylo po-

třebné skladovat nebo likvidovat a používat v sou-

ladu s požadavky zákonných nařízení a nařízení

z hlediska bezpečnosti práce. Jediným naším ovliv-

ňováním životního prostředí je produkce kancelář-

ského odpadu, spotřeba energií a chování našich

zaměstnanců.

OdpadyOdpady, které naše společnost produkuje, se sa-

mozřejmě snažíme nejen třídit, ale také jejich vznik

minimalizovat. Používáme v maximální míře elek-

tronickou formu komunikace, a také elektronic-

ké dokumenty. Odpad, který nám vznikne třídíme,

tam kde je to možné, na plast a papír. Takto vytří-

děný odpad je potom odevzdán k dalšímu zpraco-

vání autorizovaným firmám. V následují tabulce je

uvedeno množství vytříděných a předaných odpa-

dů k likvidaci.

Odpady 2006 2007 1-6/2008

Papír 0,2704 t 0,6749 t 0,1512 t

Plastické hmoty 0,0444 t 0,2886 t 0,1443 t

směsný odpad 2,2214 t 2,2154 t 0,2886 t

Společnosti KOMIX byl magistrátem hlavního měs-

ta Prahy vydán souhlas k nakládání s nebezpečný-

mi odpady pro klasické CRT monitory (s katodovou

obrazovkou), které se při vyřazování z použití stáva-

jí nebezpečným odpadem. Z těchto důvodů máme

také uzavřenu smlouvu s Pražskými službami a.s.

na likvidaci nebezpečných odpadů, elektroodpa-

du, likvidaci komunálního odpadu a tříděného pa-

píru. Dále pak se společností REMA máme uzavře-

nou smlouvu na likvidaci nebezpečných odpadů

a elektroodpadu.

Recyklace se tedy také týká veškeré techniky (elek-

troodpadu), kterou ve společnosti vyřazujeme

z použití. Platí, že zařízení, které bylo vyřazeno

z provozu, musí být znovu využito nebo recyklová-

no. V následují tabulce je uvedeno množství předa-

ných nebezpečných odpadů a elektroodpadů.

nebezpečné odpady

2006 2007 1-6/2008

Televizory, monitory, obrazovky

0,272 t 0,120 t 0,250 t

elektroodpad (vyřa-zené elektrické a elek-tronické zařízení)

0,120 t 0,400 t 0,075 t

V rámci systému environmentálního managemen-

tu je také každý rok odevzdáváno hlášení o pro-

dukci a nakládání s odpady, dále je prováděno pře-

zkoumání registru environmentálních aspektů,

hodnocení environmentálního profilu apod.

Každý rok se rovněž provádí ověřování shody s práv-

ními předpisy uvedenými v registru právních a ji-

ných požadavků a interní audity celého IMS, včetně

Od prosince roku 2006 má naše společnost certifikát dle normy čsn en IsO 14001 pro eMs (systém environmentálního managementu), který spolu s již dříve získaným certifikátem systém managementu kvality dle normy čsn en IsO 9001 je součástí integrovaného ma-nagementu systému (IMs). V rámci IMs naše společnost v současné době vytváří podmín-ky pro splnění požadavků mezinárodní normy čsn IeC IsO 20000-1 pro systém manage-mentu IT služeb, která je určena zejména pro firmy, působící a poskytující služby v oblasti informačních technologií.

požadavků normy ČSN EN ISO 14001 na systém en-

vironmentálního (ekologického) managementu.

Také spotřeba elektrické energie představuje jeden

z nejvýznamnějších environmentálních dopadů ak-

tivit téměř každé firmy. Proto jsme se v KOMIXu za-

měřili na zvyšování energetické efektivity provozu

naší společnosti. Postupná výměna klasických CRT

monitorů za moderní LCD monitory je prvním kro-

kem, včetně postupné orientace na výrobky s co

nejmenšími dopady na životní prostředí. To jsou

priority naší společnosti v oblasti životního prostře-

dí a postupné „ozeleňování“ KOMIXu. KOMIX se také

zapojil do projektu „Zelená pro vaši firmu“, který se

týká řešení firemního elektroodpadu (PC, monitory,

apod.) a sběru drobného elektroodpadu z domác-

ností (prostřednictvím zaměstnanců). V rámci to-

hoto projektu je v KOMIXu umístěn zdarma jeden

nerezový sběrný box určený pro všechna elektrická

a elektronická zařízení od zaměstnanců a zde mo-

hou zaměstnanci odevzdat například svůj nepo-

třebný mobil, příslušenství nebo baterii a my již za-

jistíme ve spolupráci se společností REMA zdarma

likvidaci a recyklaci.

Z uvedeného výčtu aktivit je vidět, že společnost

KOMIX není „zelená“ pouze formálně, pro získá-

ní certifikátu, ale že se jedná o celou řadu aktivit,

které směřují k postupnému zlepšení všech činnos-

tí, které mohou ovlivnit kvalitu životního prostře-

dí. Tyto činnosti nelze změnit jednorázovým pro-

jektem nebo marketingovou kampaní, ale jedná

se o dlouhodobé působení různých aktivit směrem

k našim dodavatelům, zaměstnancům i zákazníkům

naší společnosti. Každé i dílčí zlepšení v této oblas-

ti a rozšiřování těchto aktivit a myšlenek má smysl

a pomáhá něco změnit, ovlivnit či zlepšit v oblasti

životního prostředí pro všechny naše občany i oby-

vatele naší planety.

JiříFeřtek

fertek@komix.cz

22

23

Zapomenuté klíče

Test V poslední době se setkáváme s mnoha novými pojmy a zkratkami, týkajícími se nových technologií. Tyto zkratky sami běžně používáme, často při tom ale jen vzdáleně tušíme, co daná zkratka znamená. následují test Vám dává příležitost nejen si prověřit své znalosti, ale hlavně se pobavit. autorem testu jsou zaměstnanci společnosti KOMIX.

Je velmi pozdní odpoledne. Po odchodu z prá-

ce jste zjistil(a), že jste si ve své kanceláři ve 3. pat-

ře zapomněl(a) klíče od bytu. Musíte se pro ně vrá-

tit. Protože venku na ulici probíhá rekonstrukce

tramvajové trati a pozůstatky chodníků jsou poně-

kud blátivé, nechcete riskovat střet s uklízečkami.

Na obrázku vidíte plán budovy (3 patra) rozkresle-

ný vedle sebe ve třech navazujících časových úse-

cích , ve kterých se mění pohyb uklízeček po budo-

vě. Vaším úkolem je do 30 minut dojít do kanceláře

ve 3. patře pro klíče.

1. Bluetooth jea) Viagra uvízlá mezi zubyb) V slangu ochránců Krkonošského národního

parku označení pro sběrače borůvek v ochranné zóně.

c) Jméno dánského krále (Harald Modrozub) z 10. století, který si pravděpodobně nečistil zuby, ale zato dokázal přimět válčící kmeny k vzájemné komunikaci a dohodě.

2. gsM jea) Gramofon s Magičemb) Global System for Mobile Communicationsc) Generální Sekretář Mongolska

3. lan jea) Local Area Networkb) Lace And Nab (napráskat a sbalit) způsob

seznamování z konce doby ledové, v součastnosti časteji známá jako nová sexuální praktika

c) Levný Ale Nechutný - v žargonu ČOI označení pro některé restaurace

4. MP3 jea) Motorka Pro 3 - oblíbené motorové jízdní kolo

vyhledávané hlavně vietnamskými zákazníkyb) Motorová Pila k jejímuž ovládání stačí 3 prstyc) MPEG-1 Audio Layer 3

5. IP jea) Izraelský Polibek - označení pro izraelské tříštivé střely

vysílané do hustě obydlených míst pásma Gazyb) Intenzivní Píchání - převratný směr přístupu k práci

praktikovaný v textilních továrnách z období perestrojky

c) Internet Protocol

6. gPs jea) Geographic Public Serviceb) Global Positioning Systemc) Gde Preboha Som?

7. hDD jea) Hard defection destructionb) Hard disk drivec) Head digital derange

8. DVD jea) Divotvorný video diskb) Defect video diskc) Digital Versatile Disc

9. rOM jea) příslušník menšinyb) Read-only memoryc) Real oracle men

10. aDsl jea) Asymetric Digital Subscriber Line - Technologie umožňující velmi rychlý přenos dat po telefonní lince.b) Alkoholik Doražený Syntetickým Lihemd) Auto Do Sovětských Lesů

Pravidla:

Během každého desetiminutového časového úseku můžete projít

maximálně 10 polí.

Nesmíte vstoupit na čerstvě vytřenou podlahu (modré pole).

Po projití maximálně 10ti polí se automaticky přesunujete do další-

ho časového úseku do stejného místa v budově.

Pohybovat se můžete pouze pravoúhle, nikoli diagonálně.

Přesun po schodech do dalšího patra se počítá jako přesun

o 1 pole. Na schodišti se nesmíte zastavit.

Nesmíte se zastavit na poli, na které v dalším časovém

úseku přijde uklízečka. Tomáš Vahalík

vahalik@komix.cz

řešení zapomenutých klíčů:10 min: běžte do 2. patra, zastavte se mezi schodišti (posun o 9 polí)20 min: stůjte a čekejte až vyschne podlaha30 min: pokračujte do 3. patra ke klíči ( posun o 10 polí)ponaučení : stát na místě může být nejrychlejší cesta k cíli (jára cimrman)

KOMIX s.r.o.Avenir, Radlická 751/113e, 150 00 Praha 5, Tel.: +420 257 288 211, sales@komix.cz, www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o.

DTP a produkce: SDP V.I.P. Servis, s.r.o. © KOMIX s.r.o. 2008

Děkujeme všemnašim klientům za Důvěru