2009

komixí noviny 2008/2009 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. S tím souvisí i to, že vyhledáváme zákazníky, kteří chtějí inovovat, kteří chtějí dělat svůj business jinak než konkurence. Pochopitelně při tom nemůžeme zůstat stranou dění ve  státní správě, kdy se zákazník s  největším IT budgetem v  republice rozhodl přihlásit k  trendům e-governmentu a  investovat do  rozsáhlého využití IT technologií ve prospěch občanů a zjednodušení jejich komunikace se státem. Probíhající reformy vyvolá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, podporujících začlenění České republiky do Evropské unie, další týmy pracují na  podpoře reforem nemocenské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ě dokazují, ž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 technologií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 podporu prodejních týmů od  německé společnosti CAS genesisWorld (CRM) a CAS teamWorks nebo o produkt z oblasti bezpečnosti společnosti KOBIL či nástroj QlikView pro rychlou analýzu dat pro podporu manažerského rozhodování raketově rostoucího start-upu QlikTech. Na přelomu roku 2008 a 2009 budeme moci nabídnout CAS genesisWorld i v hostované verzi. Tj. KOMIX zajistí kompletní provoz aplikace na své technice 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 softwarový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ároky norem ISO nemusíte začínat rozsáhlou investicí do softwarové podpory, tuto službu si můžete pronajmout. Začtete-li se do  příspěvků v  těchto novinách, jistě poznáte, že KOMIX disponuje poměrně rozsáhlý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 projektu nalézt a  aplikovat nové technologické prvky 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  jedné 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 rozvinutí obchodu nebo zkvalitnění služeb. Máte-li nějaký nápad, jak něco změnit, inovovat, zavést novou službu nebo naopak vidíte problém a  chtěli byste s  někým diskutovat jeho řešení, prosím napište na adresu [email protected]. Zkusme problémy řešit společně! Petr Kučera

Iterační vývoj v praxi Iterační (někdy také přírůstkový) vývoj je výrazným a důležitým rysem moderních přístupů k tvorbě 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).

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.

Iterační vývoj

Použití na CDBP

Základní myšlenka iteračního vývoje je jednoduchá: realizaci díla rozdělíme do  kratších etap (typická délka 1-4 týdny) nazývaných iterace. V rámci každé z nich musí vzniknout funkční verze softwaru, 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 vytvořený systém odpovídá jeho potřebám. Předchází se tomu, že bude vytvořeno velké množství funkcí, které v okamžiku nasazení do provozu již nejsou potřeba. Proto se funkce zařazované do  jednotlivých iterací vybírají podle priority stanovené zákaz-

1. i 2. etapa projektu CDBP byly založeny na standardní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í konstrukce (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

systém nemohl vzniknout v potřebných termínech. Následuje rozsáhlé testování, které se skládá z  interních testů uvnitř jednotlivých týmů, integračních testů mezi zúčastněnými dodavateli, nezávislý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 projektu rozhodli ověřit použití iterační metody pro programování a  interní testování. Princip metody zachycuje Ganttův diagram na  obrázku. Zjednoduš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 rozvojem již existujícího a funkčního systému, není použití iterační metody problematické. U  nově vznikajícího systému by bylo potřeba počítat s úvodní „náběhovou“ fází, kdy ještě není nic hotovo a testování je zpočátku poněkud složitější.

Popis metody Podívejme se na jednotlivé kroky podrobněji. Každá iterace je zahájena detailním naplánováním konstrukč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 trvá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řena nová verze softwaru a je připravena do testovacího prostředí. Programátoři napíší stručné shrnutí ke způsobu řešení jednotlivých úkolů, což slouží mj. jako podklad pro testování či tvorbu dokumentace. V průběhu druhého týdne konstrukce se připravují testovací scénáře pro nově vznikající funkce, na  základě kterých bude ověřena jejich kvalita a  soulad se zadá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í. Nejprve je snahou najít fatální problémy, které znemožňují další postup testovací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 zahájena paralelně s testováním. Retest opravených chyb se pak provádí při dalším kole testování.

2

V  týdnu, kdy probíhá testování, se rovněž aktualizuje dokumentace v rozsahu, který odpovídá nově implementovaným funkcím. Tato průběžná aktualizace po každé iteraci se týká především systémové dokumentace. Uživatelské příručky jsou aktualizovány později v odděleném režimu především v závislosti na  tom, zda se již nemění uživatelské rozhraní 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é iterace 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), testovací práce probíhají paralelně s konstrukčními pracemi 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ástroje Pro 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 eviduje 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, odhadovaná pracnost, plánované zařazení do iterace a programátor, který bude funkci realizovat. Je zde obsažen jak dlouhodobý orientační plán, tak přesný plán na nejbližší jednu či dvě iterace. Pomocí agregačních funkcí MS Excel lze poměrně snadno zobrazit 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 činnosti 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 interního testování používán také pro evidenci chyb.

Očekávané přínosy Cíle, které sledujeme při použití popsané iterační metody, jsou následující: • Průběžná kontrola vytvořeného softwaru, rychlá „zpětná“ vazba od testerů, kteří de facto zastupují 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řehled o skutečném postupu prací – co je 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 hotové, 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 času na testování, protože testování je vlastně 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  celkové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 [email protected]

KOMIX spoluvytváří projekt EU 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ů financovaný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é konsorcia 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 projektu 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šichni členové konsorcia. Hlavním cílem projektu Village je rozvinout kooperativní 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 paradigmatům trhu, kde je CRM poskytováno ve formě

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, odstraně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í Internetu pro byznys účely. Pro české a slovenské zákazníky představuje účast KOMIXu v projektu Village příslib brzkého představení 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 [email protected]

Novinky v CAS genesisWorld verze 10 Vývojový plán společnosti CAS Software AG garantuje 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 technické inovace. Největší změnou pro zákazníky je nový licenční systém. CAS genesisWorld je nyní prodáván ve  třech edicích Standard, Premium a  vše zahrnující Suite. Rozdělení CAS genesisWorld na jednotlivé edice bylo způsobeno množstvím nových funkcí, které byly do systému zahrnuty. Kromě zmíněných edic disponuje nyní CAS genesisWorld novými moduly. Mezi tyto moduly patří CAS Marketing, CAS Sales, CAS Reports, CAS Projects, CAS Helpdesk, CAS Timeclient, CAS Mobile CRM for Blackberry.

Především CAS Marketing přináší dlouho očekávanou změnu v práci s kampaněmi, grafické navrhování work-flow kampaní, definice následných akcí a  vyhodnocení úspěšnosti jednotlivých marketingový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 sledová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  prostředí CAS genesisWorld nové typy informací. V pří-

3

Na rozdíl od standardního modulu CAS MobileAccess mohou mobilní uživatelé s přístroji Blackberry využívat výhod PUSH technologie.

padě CAS HelpDesku pracuje zákazník v prostředí speciální www aplikace, informace jsou však přeneseny do  prostředí CRM a  k  dispozici jeho uživatelů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ěstnancům.

CAS genesisWorld nabízí i branžová řešení. Zákazní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 dealerské 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.

Novinky postihly i  oblast mobility. CAS MobileAccess a  CAS WebAccess jsou nyní součástí edice CAS genesisWorld Premium edition, k  dispozici je nyní nový modul CAS MobileCRM pro Blackberry.

Mottem nové verze CAS genesisWorld bylo nabídnout uživatelům drobná vylepšení, která lze využít zejména v každodenní práci. Spolu s novou verzí 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 webové 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 čtvrtletí 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 [email protected]

Computerworld IT produkt roku 2008 V  roce 2008 vyhlásila redakce časopisu ComputerWorld druhý ročník soutěže o  IT produkt roku. Podmínky soutěže umožňovaly přihlásit jakékoli zařízení, software, řešení nebo službu z oblasti informačních a komunikačních technologií, jež lze využí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  podobných konkurenčních produktů. Produkty splňující uvedená kritéria v dostatečné míře postupují 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ýsledky 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 Hyperformix - IPS Performance Optimizer. V kategorii Informační systémy postoupilo portálové řešení pro týmovou spolupráci od  společnosti CAS Software 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

4

změn a rozvoje na základě dat z monitoringu testovacího či produkčního prostředí. Umožňuje odhalit problémová místa systému a najít způsob jejich 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šené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 prodejních a marketingových aktivit, přičemž CAS genesisWorld pomáhá k dosažení cíle za použití celé řady uživatelsky přívětivých funkcí a s pomocí propojová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 pomocí tzv. replikace dat. Velmi dobrou vlastností CAS genesisWorld je rychlá implementace a  velmi sil-

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í kalendáře, plánování a  delegování úkolů, přehled o  vnitropodnikových procesech, realizovaných projektech, zobrazení zodpovědností, pravomocí a práce dle předem vytvořených checklistů jsou jeho silnými stránkami. CAS teamWorks umožňuje správu služebních cest, evidenci klíčů, místností, 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 spolu s  CAS genesisWorld. Současné nasazení přináší synergické efekty využití společné datové základny a sdílení informací v back-office i front-office části společnosti.

Miroslav Žebrák [email protected]

PPM není pouze software 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 pozadu nezůstávají ani výrobci softwaru, kteří na tento trend reagují uváděním stále dokonalejších nástrojů. Dnešní PPM aplikace disponují širokou funkcionalitou vycházející z  všeobecně uznávaných standardů 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 skutečně tak dobré, jak jejich výrobci proklamují a jestliže ano, proč jejich zavádění nepřináší očekávané výsledky? Odpověď je jednoduchá. PPM není pouze software. Podíváme-li se na  problematiku portfolio managementu blíže, zjistíme, že se jedná o  velmi komplexní oblast, do  které je při správném využití zapojeno množství subjektů napříč celou organizací. A s množstvím subjektů souvisí také celá řada faktorů, které mohou implementaci ovlivnit. V následujících odstavcích jsou uvedeny některé z  nejdůležitějších faktorů, které je nutné vzít při implementaci portfolio managementu v úvahu.

Skutečný rozsah projektu Jednou 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 implementace 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 projektového řízení. Ve  společnostech, kde jsou formou projektů realizovány kromě podpůrných také hlavní č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á priorita, 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 zapomínáno. Zároveň je nutné vzít v úvahu ostatní probí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ýznamnějších faktorů rozhodujících o úspěchu či neúspěchu jakéhokoliv projektu, kvalitní podpora ze strany vrcholového vedení by zcela jistě obsadila jedno z předních míst. Její význam se ještě zvyšuje v případě 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í portfolia je primárně zaměřeno na vyšší úroveň řízení, kam také směřují jeho hlavní přínosy. Svým charakterem ovšem zásadně ovlivňuje práci managerů prakticky na všech úrovních a vyžaduje od nich intenzivní spolupráci často bez adekvátních přínosů. Lehce se tak může stát, že zejména v řadách projektových managerů je implementace PPM vnímána jako něco, co pouze přidělává práci a nepřináší žádné výhody. Následuje chladný a odměřený přístup, který k  celkové úspěšnosti projektu zcela jistě nepřidá. Právě v takových chvílích je na managementu 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 projektu, 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  odpově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 pozornost. Výsledkem bývá laxní přístup k projektu nebo delegování odpovědnosti na nižší stupně řízení. Takové chování je však krajně nevhodné. Jsou to totiž pouze příslušní vedoucí pracovníci, kteří by měli definovat základní požadavky a  kvalifikovaně rozhodnout o jejich úspěšném dosažení. Účinnou metodou jak dosáhnout, aby zapojení klíčových uživatelů 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 organizace Jsou projekty, které může realizovat prakticky kterákoli organizace, a pak jsou projekty, k jejichž realizaci je zapotřebí splnění řady vstupních předpokladů. Implementace PPM patří bezpochyby do druhé skupiny. Řízení portfolia je úzce spojeno s projektovým řízením. Tvoří vlastně jeho logickou nadstavbu. Z pohledu úspěšnosti tak množství přínosů dosažených implementací portfolio managementu přímo souvisí se stupněm vyzrálosti firmy v oblasti řízení projektů. Jinými slovy, k  tomu, abychom mohli efektivně řídit portfolio, potřebujeme dostatečně kvalitní základy v podobě všeobecně akceptovaný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řínosů 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 aplikace 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žbami 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ůsobit 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ě obsahuje i vlastní know-how, jak by proces řízení portfolia 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  implementací Project Portfolio Managementu, nýbrž poukázat na  komplexitu a  rozsáhlost změn, které s  projekty tohoto typu souvisí. Efektivně adoptovat 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 povinnosti a úkoly. I tak je ale nasazování PPM cestou náročnou a často také bolestnou. Vyžaduje kooperaci prakticky všech oddělení a velmi silnou iniciativu nejvyššího vedení. Jedině tak lze zaručit, že na konci této cesty bude zasloužená odměna v  podobě dosažení požadovaných výsledků. Petr Šťastný [email protected]

5

Změny v provádění technické podpory testovacích produktů po přechodu od Mercury k HP Po akvizici společnosti Mercury Interactive Corporation společností Hewlett-Packard došlo k zásadní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í produktů 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živatelské rozhraní webové služby pro poskytování podpory software společnosti HP, které už obsahuje 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 nutnosti přihlásit se pod uživatelským účtem a  zahrnuje 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.

účtu HP Passport platné identifikátory servisní podpory, vycházející z uzavřených smluv se společností 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žadavky na technickou podporu nebo zadávat požadavky na  změnu vlastností a  funkčnosti podporovaný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 organizace technické podpory svých zákazníků. Díky těmto změnám došlo ke zvýšení kvality poskytovaných služeb technické podpory softwarových produktů 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 úroveň přístupu umožňuje stahování zkušebních verzí software, stahování opravných balíčků (patches), individuální nastavení emailových upozornění po  uvolnění nových verzí softwarových produktů. Obsahuje například také informace o termínech ukončení podpory starších verzí software HP.

Pro komunikaci se zákazníky využívá KOMIX v současné době nový systém Service Desk, nakonfigurovaný pro provádění technické podpory, včetně dodržování smluvních požadavků (SLA – Service Level Agreement). Prostřednictvím Service Desku KOMIX mají zákazníci k  dispozici trvalý přístup (24 x 7) k informacím přes webové uživatelské rozhraní, které umožňuje jak zadávat nové požadavky technické podpory, tak i prohlížet postup řešení dříve zadaných požadavků.

3. Pro třetí, tj. nejvyšší úroveň přístupu k  podpoře software HP, je nutné zadat do profilu osobního

V oblasti podpory HP software zajišťuje společnost KOMIX pro své zákazníky první úroveň technické

PROČ PROVÁDĚT ZÁTĚŽOVÉ TESTY Základy zátěžového testování aplikací Cílem zátěžového testu je zjistit výkonnost aplikace v závislosti na stupni a druhu zatížení.

Co jsou zátěžové testy Zátěžový test slouží k  nalezení problémů a  jejich příčin projevujících se při větším zatížení aplikace. 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 ekonomické ztráty, ale rovněž demotivaci pracovníků a sníže-

6

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ížení se volí tak, aby odpovídala podmínkám v provozu a cíli zátěžového testu. Nejběžnější praxí je simulovat 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ánovaném zvýšení počtu uživatelů této aplikace.

podpory. Výhodou tohoto typu podpory je komunikace v českém jazyce a naše zkušenosti s instalací 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é podpory KOMIXu patří zasílání informací o nových verzích HP software a konzultace o vhodnosti jejich nasazení. Před uvolněním nových hlavních verzí software předáváme našim zákazníkům výsledky tzv. „kalibrace“, tedy závěrečnou zprávu z interního testování software dle normy ISO 9001 (ověření vlastností software deklarovaných výrobcem), kde se mj. zaměřujeme na testy českého národního jazykového prostředí. V rámci poskytování technické podpory může KOMIX pro své zákazníky zajistit také aktualizace nový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é podpory, například vyžádané mimořádné práce nebo pracovní pohotovost v mimopracovní době či o víkendu. 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 pracovišti zákazníka, zejména při provádění upgrade HP software na vyšší verzi či při migracích nebo upgrade databází. Miloslav Richter, Štěpán Janča [email protected], [email protected]

Co ovlivňuje výkon aplikace Aplikace 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ýkonem: 1. Výkon hardware serverů. Ten můžeme rozčlenit na problémy s výkonem procesorů, správou a velikostí 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.

3. Nastavení parametrů operačního systému (Linux, 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 (využí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 kterými si testovaný systém vyměňuje nebo sdílí data.

V jakém případě je třeba udělat zátěžový test Pří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í, ale pomalá aplikace snižuje produktivitu práce a také demotivuje zaměstnance. • Může dojít ke ztrátě zákazníků. Například pokud se zákazník nemůže přihlásit do  internetového obchodu nic mu nebrání nakoupit u  jiného dodavatele. • Pokud dojde díky přetížení k úplnému vý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ý kolaps internetového bankovnictví 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átní 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: • Zadavatel přebírá novou aplikaci od dodavatele. Zátěžový test by měl být součástí akceptačního řízení. • Při nasazení nové verze aplikace. • Při přesunu aplikace na jiný hardware. • Při přechodu na jinou verzi databáze (např. přechod 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ů.

aplikací, specialisté na aplikační, databázové a webové servery, vývojáři aplikace …) určit případné „úzké místo“. Pro ladění výkonu samozřejmě potřebujeme monitorovat servery, případně i  další zdroje, na  kterých je aplikace provozována. Monitoring 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, který 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řispělo ke zvýšení výkonu.

Řešením problému nemusí být vždy jen navýšení výkonu hardware Stejně jako u  jiných chyb i  pro ladění výkonu platí, že nejobtížnější je najít příčinu chyby. V odstavci „Co ovlivňuje výkon aplikace“ je uvedeno 7 vrstev, na  kterých se může chyba vyskytnout. Navíc jde často o kumulaci příčin vyskytujících se na různých vrstvách. Posílením hardware můžete zvýšit jeho výkon zhruba o  desítky procent, ale optimalizací 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ýkonnosti aplikace, třeba i  nad požadované limity, přináší ve většině případů snížení zátěže některého serveru nebo serverů. To přináší buď rezervu do budoucna, 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žitelná. Jinými slovy zátěž postupně zvyšujeme až do doby, kdy aplikace přestane splňovat požadovaná 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 specializovaný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š technicky náročná. Největší výhodou této metody je relativně 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í odezev systému a sběr naměřených hodnot. • Vyšší chybovost z hlediska lidského faktoru. Příprava automatizovaných zátěžových testů je časově náročnější. Zpravidla zahrnuje analýzu, přípra-

Co vám zátěžový test přinese Zátěžový test slouží k ověření výkonnosti a fungová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řejmě výkon aplikace nijak nezvýší, ale jeho výstupy pomohou odborníkům (správci prostředí, správci

7

vu (přípravu dat, tvorbu a odladění skriptů a přípravu prostředí pro ZT), realizaci definovaného počtu běhů a  jejich vyhodnocení. Výstupy automatizovaných testů jsou ve  srovnání s  manuálními daleko přesnější. Automatizovaný test je možno opakovat ve stejném rozsahu zátěže jako jeho provedení v předchozím běhu.

Prostředí pro zátěžový test Vlastní příprava automatizovaného zátěžového testu se obvykle uskutečňuje na  některém z  testovací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ředí, včetně objemů dat v databázi. Vybudovat takové 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í prostř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  prostř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 specializovaného software (například HyPerformix Performance Optimizer). Jako vstupy tomuto software zadáme výsledky zátěžového testu a  údaje o  infrastruktuře testovacího a  produkčního prostředí (všech serverů a dalších prvků včetně jejich výkonnostních parametrů). Tento software pak vyhodnotí 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 dopad změny hardware na výkon aplikace.

Na co se soustředit při plánování zátěžového testu V  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, provedení 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 klienta, přes tlustého klienta SAP, jiným systémem, se kterým komunikuje pomocí web services).

• Jaká je cílová požadovaná velikost zátěže. • Co od zátěžového testu očekáváte, jaké by měly být jeho cíle a přínosy, proč ho plánujete (např. nová aplikace, nová verze aplikace …). • Základní technologické údaje o aplikaci, prostředích a protokolech (například aplikace je v SAPu či Siebelu včetně jejich verze). • Co se bude v průběhu testu vyhodnocovat? Typicky jde o  doby odezev na  jednotlivé uživatelské akce, doby trvání u  dávkového zpracování dat, vytížení hardware (procesoru, paměti, disků), 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 monitorovaných serverů a jejich charakteristiky. • Tabulku požadovaných výkonnostních limitů pro sledované odezvy aplikace

Co vám můžeme nabídnout KOMIX má rozsáhlé a dlouholeté zkušenosti v oblasti provádění zátěžových testů a  technické podpory software HP LoadRunner. Díky našim širokým znalostem můžeme nabídnout provedení zátěžový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í pracovníky. Libor Kotoun [email protected]

Role v procesu manuálního testování 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ů. 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 obsahovat 4 fáze - plánování, přípravu, provedení a vyhodnocení. Ú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  prostudování dostupných podkladů, upřesnění nejasností, zvolení vhodného způsobu testování a  zejména čas pro přípravu podkladů, podle kterých se testování provede. Vývoj aplikací nejčastěji probíhá v  několika etapách, je tedy více než vhodné,

8

aby testeři tento způsob respektovali. Proto je nutné 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 testů, 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 termí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

tak v týmu sejde vedoucí testování, analytik testová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 testování. V úvodních fázích projektu domlouvá a specifikuje 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ě standardních manažerských činností také dbá na  to, aby jeho tým dodržoval přijatou metodiku. V neposlední ř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).

Co nerad slyší: Testovací prostředí fungovat nebude, ale testy se udělat musí. Nějak to otestujte, hlavně ať tam nejsou chyby, ať to můžeme nechat zakceptovat.

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.

Tester 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 analýzu a jaký je telefon na analytika vývoje?“ Pak se stáhne do  tichého kouta, odkud se několik dní ozývá zuřivé šustění zvýrazňovače a nespokojené „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  upravenou analýzou a hrubou kostru naplánovaných testů 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 hotovou 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ální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ývoje 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.

Ve své praxi jsem se setkal se dvěma krajními pohledy 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 nainstaluje, 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 dokonale 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 ignorovat 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 existuje jen jedna cesta – zmizet co nejrychleji do jiné firmy.) Jak už to u extrémních příkladů bývá, pravda je někde uprostřed cesty. U  dokonale připravený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 klikat v  jedné aplikaci pořád dokola). Čím méně dokonalá byla příprava a analýza, čím více se aplikace 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 podkladů provádět s aplikací předepsané operace, porovnat je s předepsaným očekávaným chováním a zaznamenat 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 prostoru 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 volné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é reportová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 analytikem 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 Windows. Testování přirozeně neprobíhá ve  vzduchoprázdnu, testovací tým spolupracuje a komunikuje s řadou dalších lidí. Nejdůležitější pro testovací tým jsou projektový manager, analytik vývoje a programátor, ale neobejdou se ani bez součinnosti odborní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í testování bez pomoci specialistů na databáze, testovací prostř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 nejdražší software pro testy, ani nedokonalejší analýzy - nezaručí, že nějaká chyba neproklouzne až k uživatelům. Testovací tým se snaží dobrým naplánováním, poctivou přípravou a  pečlivým provedením testů o  to, aby takových chyb bylo co nejméně. Pavel Hönigschmied [email protected]

9

Testování systému CDBP v KOMIXu Od konce roku 2005 pracuje KOMIX na projektu vývoje systému cestovních pasů s biometrickými prvky (CDBP), na kterém se podílí celá řada dalších subjektů. 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í policii 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 testová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í, analytika testování a testery. Vedoucí testování zastřešuje celý tým, tj. komunikuje s  jinými vedoucími týmů a  managementem projektu, zajišťuje rozdělení prací v  týmu, koordinuje činnosti v týmu, kontroluje výsledky práce členů 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 vybavení), vytváří společně s analytikem testovací scénáře a testovací případy (tj. pro všechny klientské aplikace projektu CDBP). Analytik testování vychází ze schválených analytických podkladů k aplikaci, na jejichž základě navrhuje 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ě testovací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 analytik testování bývá současně testerem. Úkolem týmu je seznámit se s  projektovou dokumentací, tak aby byl schopen vytvořit testy ještě před tím, než jsou k  dispozici testovatelné klientské aplikace. Projektová dokumentace na CDBP zahrnuje 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 rozhraní, slovní popisy procesů, UML diagramy procesů, infrastruktury apod. Druhým neméně důležitým

10

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 testování pro tuto etapu vývoje. Tyto dva dokumenty jsou důležitým podkladem pro návrh a tvorbu testovací dokumentace (tj. Plán testů, Testovací případy a scénáře, specifikace testovacích dat). Po  seznámení týmu s  projektovou dokumentací aktualizoval vedoucí testování dokument Plán testování, který vznikl již v minulé etapě a obsahuje 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í, specifikace testovacích dat, definice rolí, definice tříd chyb atd. Po aktualizaci Plánu testů přichází fáze přípravy testovací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ě etapy vytvořeno celkem 130 testovacích scénářů, které mají dohromady cca 520 stránek A4 a obsahují podrobné 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 testování: • Interní • Systémové • Integrační • Nezávislé • Akceptační • Pilotní provoz Interní testování na projektu CDBP je stádium projektu, kdy dochází k  tvorbě veškeré testovací dokumentace (jak jsem popsal již výše) a  prvotnímu

otestování vyvíjeného systému na testovacím prostř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ývojový tým jeden týden vyvíjí a druhý týden opravuje 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ásledujících několika týdnech naprogramováno a postupně uvolněno pro testování. Posledním zdrojem informací pro testery je firemní aplikace ProjectX, kde každému záznamu z Evidence iterací odpovídá jeden ú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  otestová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 ProjectX 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ědné 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í prostředí zákazníka, tedy k systémovému testování. Velmi často jsou systémové a integrační testy prováděny víceméně současně, protože bez napojení

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 propojit produkt vyvíjený KOMIXem s  ostatními částmi 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 obyvatel 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ů. Testeř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 evidencí 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é prové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 centrálního systému, tedy zda je systém schopen při zasílání velkého množství požadavků v určitém časovém intervalu (např. jedné hodiny) tyto požadavky zpracovat, vyřídit (např. podepsat příslušnými certifiká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 centrálního systému, která je součástí nově doprogramovaných funkcí. Po provedení interního, systémového a integračního testování provede jiný subjekt účastnící se projektu tzv. nezávislé testování našeho produktu

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  dispozici testovací tým KOMIXu. Stejný režim je plánován i pro současnou etapu projektu, kdy tato firma dostane navíc k dispozici testovací dokumentaci KOMIXu. Proces nezávislého testování probíhá podobně jako interní a  systémové testování prováděné KOMIXem. Testeři firmy provádějící nezávislé testování projdou všechny klientské aplikace podle 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 retestu 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ídající smluvnímu zadání, je tento systém předán k akceptač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 redukce je fakt, že testovací dokumentace i celý systém CDBP je velmi rozsáhlý a  složitý a jeho komplexní

funkcionalita byla ověřena několikrát v předcházejí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 testů 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 probíhá následujícím způsobem: veškerý systém, testovaný na  „testovacím“ prostředí, se převede do tzv. ostrého prostředí. Celý systém se tak propojí 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ě nalezeny a  opravovány chyby vycházející z  reálného napojení na spolupracující systémy. Neshody z pilotní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 uveden do běžného provozu. Plánované nasazení inovovaného systému CDBP bude od dubna 2009. Michal Černický [email protected]

Převod systémů TARIC a NIT z prostředí UNIX do prostředí Windows 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 takové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 tarifu Evropské unie) a  NIT (národní integrovaný tarif) 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 detailní popis systémů TARIC a NIT, je nutno zmínit pár základních údajů. Systém TARIC slouží ke sledování statistiky zahraničního obchodu Společenství a  obchodu mezi členskými státy Evropské unie. Tento systém je založ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

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 EDIFACT, byla napsána jako autonomní úloha přistupují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  použití modulu FastCGI. Tolik shrnutí technologie, ze které se převádělo. Dále již druhá strana mince – technologie, do které se převod uskutečnil. Microsoft, takto by se dalo jedním slovem shrnout cílové prostředí. Buďme však konkrétnější. Celkové řešení se skládá z aplikačního, databázového a webového serveru. Všechny servery běží na operačním systému MS Windows Server 2003. Logické rozdělení tohoto systému je, že autonomní úlohy a část komunikují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

řešení provozovaném na Windows SharePoint Services 2.0. Z  použitých technologií se dá vyčíst, že jsme pro programování zvolili opět Microsoft, a to v  podání Microsoft .NET Framework 2.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áze Vý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é prostř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é prostředí, ale pro integraci je zapotřebí ještě prostředí, a  to přímo u  zákazníka. Ještě, že existuje virtualizace, vzpomenu si, když poměrně brzy dostávám informaci o  tom, že je již možné tyto prostředky na  straně zákazníka využít. Protože mezitím

11

dat, která nebyla ještě v té době kompletní.

Dějství třetí – komunikace s  infrastrukturou Bruselu Brusel zasílá zprávy typu EDIFACT všem členským státům pomocí infraObrázek 1: Obecná architektura celkového řešení struktury určené pro tento účel. Pro podporu komunikace s touto infranezahálíme, je připravován převod databáze z IBM strukturou distribuuje speciální SDK, a to jako C++ Informix řady 9.X do MS SQL Server 2005. Instaluknihovny. Chvíli jsme váhali, zda pro vytvoření projeme IBM Informix Client SDK 2.90.TC1 a připravugramového vybavení stahující data z této brány nejeme převod databáze. Volba na  tuto verzi padla použít Microsoft .NET Framework, ale v tomto příz  důvodu stability v  současně provozovaných řepadě převážily výhody nativní integrace s  C++. šeních. (Jak jsme se v  tomto případě mýlili, ukáže Zajímavostí tohoto SDK je, že může spolupracovat až pozdější nepříjemné zjištění). Nastavujeme pros bránou dvěmi následujícími způsoby: středí klienta pro podporu UTF-8, avšak již při prva) komunikaci zahajuje infrastruktura, ních testech zjišťujeme, že nám zcela zjevně něco b) komunikaci zahajuje klient chybí. Na  data se dostaneme, ale jejich zobrazení není správné. Chybí nám Global Language Supad a/ celková konfigurace je nastavena v tzv. módu port, vzpomeneme si, a po instalaci této podpory je “OnDemand“. již vše v pořádku, data se zobrazují tak, jak by měly. Toto se jeví jako efektivní řešení, ve kterém nedoNásledně zálohujeme prostředí IBM Informix Clienchází ke zbytečné zátěži této infrastruktury. Abych ta a  můžeme začít připravovat balíčky pro přenos objasnil tento princip, musím říci, že v tomto módu dat na SQL Server 2005. infrastruktura samotná aktivně oslovuje na definovaném TCP/IP portu poslouchající kanál na  straně Dějství druhé – příprava autonomních klienta, a po navázaní komunikace probíhá spojeúkolů ní již pomocí tohoto kanálu. Nezbytným předpoProgramové vybavení na straně aplikačního servekladem je, že na  straně klienta je programové ru obsahuje autonomní úlohy pro import a export vybavení umožňující nejenom poslouchat na  vydat. Toto řešení bylo provozováno i  na  platformě hrazeném portu, ale i předat řízení dalšímu prograUNIX. Pro vývoj nových autonomních úkolů bude movému vybavení. Tato část na straně klienta také použit již navržený Microsoft .NET Framework 2.0. slouží jako most pro komunikaci mezi volaným proS  úspěchem převádíme metadata popisující EDIgramovým vybavením na jedné straně a infrastrukFACT zprávu do XML formátu a připravujeme algoturou na straně druhé. Pokud se to zdá příliš složité, ritmus importu dat. Nebudu čtenáře zdržovat intak uživatelé UNIX přesto jistě tuší, že programové formacemi o  tom, jak jsme rozdělovali části kódů, vybavení inetd je trefa do černého. abychom docílili vytvoření znovupoužitelného frameworku pro autonomní úlohy, a také webové čásKomunikace typu OnDemand je znázorněná na náti řešení. Musím však říci, že pokud se chystáte vysledujícím obrázku. tvořit takto obecnější framework, je potřeba myslet na to, jak se vám budou chovat standardní části logování .NET v některých portálových prostředích. Neměli byste taky zapomenout, že některé z  těchto řešení vyžadují registraci použitelných knihoven do GAC (Global assembObrázek 2: Komunikace typu OnDemand ly cache). Abych se však vrátil zpět k naší implementaci. Mluvíme-li o imporZastánci Windows zřejmě již ví, že pod tímto systu dat ze vstupního souboru, tak část těchto prací témem to není takovým standardem jako u UNIX. není závislá na existenci databáze. V našem případě Pokud byste připravovali takovéto řešení ve vašem tomu nebylo jinak. Oddělením částí programování, produktu, tak byste se měli striktně vyhnout použirozebráním EDIFAC zprávy a její validací jsme mohtí funkcí zapisujících informace na standardní vstup li pokračovat v pracích nezávisle na stavu migrace nebo výstup. Důvodem proč nezapisovat je to, že

12

pokud vaše programové vybavení volá někdo tímto způsobem, tak vám do procesu předává komunikač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, pomysleli jsme si. Začali jsme tedy hledat, zda lze takové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 testování. První problémy se objevily hned na počátku, kdy náš program sice začal po oslovení komunikovat, 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 konfigurace, pomysleli jsme si. ad b/ Protože čas je neúprosný, naše úsilí se soustředí 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, která bude oslovovat tuto bránu v  předem určených intervalech, a to nejlépe s možností definice rozdílných intervalů v průběhu celého dne. Dlouho hledat nemusíme a  rozšířeným nastavením automaticky 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 autonomní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 setkali s problémem implementace odložených kontrol 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  odladě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 Windows. Jenže tady jsme se nestačili divit. Všechny položky seděly, avšak datumové položky se zcela náhodně rozcházely o  jeden den, a  to jak dopředu, tak i  dozadu. Začali jsme kontrolovat migrovaná data v  MS SQL Serveru a  tam bylo přesně to, co jsme exportovali pomocí našeho algoritmu.

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 frekvence o  poznání snížila) a  další činnosti. Nebudu čtenáře zdržovat výčtem všeho, co jsme podnikali 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 Client 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é aplikace Implementace webových aplikací do prostředí zákazníka mimo jiné předpokládala integraci Active Directory, použití impersonifikace (změna identity) při přístupu na datové zdroje, a také byl předpoklad, ž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 nejproblé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 RevertToSelf (zruší předcházející impersonifikaci), před samotnou záměnou identity uživatele, podařilo upravit tuto část kódu tak, aby byla funkční i pro vystavení do  portálu. Co nás dále překvapilo při vývoji webových aplikací? Jak jsem již předeslal, nebylo toho příliš. Co však možná stojí za zmínku, je to, že pro přípravu exportů do formátu DBF byl použit standardní MS Jet OLEDB poskytovatele. Pokud však použijete tohoto poskytovatele s  vlastností 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 tohoto produktu zpracovávat HTML soubor. Jediné, co pro korektní zpracování tohoto formátu samotný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 definovány globální proměnné) pro obě aplikace a potř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 situace jednoduchá a  určení padlo na  rozlišení dle sudé a  liché. Posledním překvapením, přesto potěš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í hladce, ř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řevedení systému s  dopadem na  všechny vstupující subjekty se nám v časovém skloubení harmonogramu ukázala výhodou. Martin Janček [email protected]

Metody a techniky objektově orientované analýzy V minulém čísle Komixích novin 2007 / 2008 byl zveřejněn článek „Tvorba a využití katalogu uživatelských požadavků“. V tématu „Uživatelské požadavky“ pokračujeme a volně navazujeme na uvedený článek z minulého čísla. Tentokrát se zaměříme na základní metody a techniky při analýze. Připomeneme si základní charakteristiky disciplín Requirements Engineering a Object Oriented Analysis, metody Object Behavior Analysis a  techniky Unified Modeling Language. Využitím praktických zkušeností můžeme získat souhrn jejich hlavních výhod.

Rekapitulace disciplín pro popis požadavků Requirements Engineering (RE) je osvědčená disciplí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í komunikace mezi dodavatelem a odběratelem, • dokumentace požadavků, • zpřesnění požadavků, • sjednocení protichůdných požadavků, • setřídění požadavků podle důležitosti. Použití RE má tyto důsledky: • rychlý vývoj požadavků na straně odběratele, • forma popisu je srozumitelná odběrateli, definuje CO se má řešit, ne JAK,

• včasné vyjasnění priorit, • méně problémů při předání díla odbě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žadavku 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. Tomuto jedinému atributu se budeme tentokrát věnovat podrobněji. Objektově orientovaná analýza (OOA) je mnohem mladší disciplína a je mnohem bližší objektově orientovaným technologiím realizace SW aplikací. Může navázat na RE a sebrané požadavky popsat podrobněji a  ve  struktuře vhodné pro využití objektových technologií. Hlavním cílem OOA je taková struktura popisu, která umožňuje snadnou modifikaci nebo jednoduché doplnění bez nežádoucích vedlejších efektů. Použití OOA umožňuje tvorbu větších a složitějších systémů. Pro OOA je charakteristické obohacení statického modelu o základní prvky chování systému – metody tříd.

Při popisu požadavků je možné respektovat strukturu informací odpovídající objektovým dynamickým a  statickým modelům (viz rozdělení popisu požadavků na popis okolí, chování a statické struktury v minulém článku). Object Behavior Analysis (OBA) je jedna z  prvních metod OOA. Je velice jednoduchá, přesto dodnes jedna z „nejobjektovějších“ (vznikla společně se Smalltalkem v ParcPlace Systems). Metoda má tyto cíle: • jednoduchý a čistě objektový popis systému, • odvození popisu statického modelu od  popisu dynamického modelu. Dokumentace vytvořená podle OBA je charakteristická vysokou mírou integrity popisu systému (těsnými vazbami mezi dynamickým a  statickým modelem).

13

Nejcennějším přínosem OBA je doplnění techniky CRC (Class – Responsibility – Collaborator) o techniku OBA scénářů, které detailně popisují dynamický 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 standardizované diagramy.

my (hodí se výborně především pro znázornění vazeb ve statickém modelu nebo pro popis variant při postupu dynamickým modelem). Pro popis detailů je vhodnější dobře strukturovaný text (v tabulce).

Obrázek 3 - OBA scénář - vazby mezi modely

UML diagramy Využití disciplín pro popis požadavků

V současné době jsou UML diagramy velmi často používaným prostředkem pro dokumentaci požadavků. UML obsahuje mnoho typů diaObrázek 4 - Správná míra podrobností gramů (více či méně specializovady do skupin podle vrstev architektury (uživatelské ných na různé činnosti). Někdy dochází k míchání rozhraní, aplikační logika, databázová vrstva). Toto typů objektů z různých typů diagramů v jediném dirozdělení je nezbytné později při návrhu (volbě aragramu – to ztěžuje orientaci začátečníka ještě více. Použití diagramu a strukturovaného chitektury). Místo tříd „Formulář objednávky“, „ObPro popis požadavků v  dynamickém modelu jsou textu sluha objednávky“ a  „Databázová tabulka objedvhodné diagramy: Při popisu požadavků se občas setkáváme se dvěnávky“ je vhodné použít jedinou tzv. „doménovou“ • UML Activity (vhodný pro jednoduchý popis proma extrémy – stovkami stran textu bez jediného třídu „Objednávka“. Analogie platí i o metodách tacesů), obrázku nebo naopak s mnoha obrázky bez zjevkové doménové třídy – místo metod „Zobrazení • UML Use Case (vhodný pro popis interaktivních ných návazností a bez jakéhokoliv vysvětlujícíformuláře“, „Validace dat“ a  „Uložení záznamu“ je systémů). ho textu. Doporučit lze samozřejmě střední cestu. vhodné použít jedinou metodu „Uložení“. Oba uvedené typy diagramů lze používat s  výhoPro vytvoření nadhledu je vhodné použít diagraPři popisu atributů stačí použít obecné datové tydou v jediném dopy (řetězce definované maximální délky, čísla s dakumentu (podle ným maximálním rozsahem, datum, čas, ...) – je to povahy příslušvhodnější než použití konkrétních datových typů né části úlohy). programovacího jazyka nebo databázového serveJe důležité dbát ru. Volba konkrétního typu proběhne opět pozděna  jednoduchost ji v rámci návrhu. Dodržení uvedených pravidel dodiagramu z  hleménového modelování má dva kladné následky: diska kvalitativ• modely jsou jednodušší – tedy lépe čitelné při ního (používejte schvalování odběratelem, co nejméně typů • zkušený návrhář dokáže lépe optimalizovat pro prvků na  diagracílovou architekturu a technologie. mu) i  kvantitativObrázek 1 – Volba techniky podle úrovně podrobnosti ního (složité diagramy přetvořte Scénáře OBA na  hierarchickou Při použití několika modelů popisu požadavků strukturu jedjsou důležité vazby mezi těmito modely. Tuto nenoduchých diazbytnou podmínku kvalitního popisu požadavků gramů). Pro poje možné zajistit s pomocí techniky scénáře z mepis požadavků tody OBA. Scénář OBA slouží k jednoduchému pove statickém mopisu požadavků na chování. Má podobu tabulky, jedelu použijte diajíž řádky popisují posloupnost vyvolání metod tříd. gram Vlastní vyvolání metody třídy je popsáno v  řádku • UML Class tabulky. Při popisu požadavků není vhodNa rozdíl od Use Case scénářů nepředpokládá scéObrázek 2 - Použití UML diagramů né rozdělovat třínář OBA variantní cesty (Alternative Paths). Pro poPř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 zaměříme na použití UML diagramů a OBA scénářů při podrobném popisu požadavku v dynamickém modelu. Detailní popis požadavků ve statickém modelu není z pohledu tohoto článku tak důležitý – popis 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.

14

pis větvení je praktické (názorné) použít diagram UML Activity. Zápis OBA scénářů a údržbu vazeb mezi dynamickým a statickým modelem automatizuje CASE nástroj QuickCRC firmy Excel Software.

nepomůže. Již v minulém článku byla zmínka o definici požadavku „na úrovni uživatele“ jako protiklad k  popisu z  pohledu programátora (pomocí terminologie technologie IT). Ještě jednou připomínám důležitost správné úrovně popisu požadavku!

Úroveň podrobnosti požadavku

Závěr

Celý článek se zabýval metodami a technikami analýzy požadavků, ale to samo o sobě začátečníkovi

Uvedené disciplíny, metody a techniky nestojí proti sobě. Vhodným výběrem jejich výhod je lze pro-

pojit do  jednotného celku, který zůstává jednoduchým a  účinným nástrojem pro dokumentaci požadavků na různé úrovni podrobnosti. Milan Číha [email protected]

Pohled na DWH&MIS&BI (s ÚSMĚVEM !!!!) aneb co nás čeká a mine/nemine? 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. Nechť nám uvedené motto přiblíží skok, kterého jsme v  oblasti IT (ale samozřejmě i  v  jiných oblastech) 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ální postup. Ale nezůstávejme u našince, takto více či méně profesně postižené IT osoby. Je vypovídající, že obdobný postup volí nejen teenageři (tam je příklon k  novému, rychlému, … jistě očekávaný), ale i  takové 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šichni tito již počítač z  velké části využívají i  pro činnosti 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 elaborá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 lehkým perem pojatou krátkou rekapitulaci a stejným způsobem pojatou vizi co by nás v blízké budoucnosti potkati mohlo. Ti starší z  nás si jistě dobře pamatují na  okouzlení z  prvních on-line provozních IS, kdy jsme s  obdivem sledovali kroky od  pořízení dokumentu až po  jeho zaúčtování a  zanesení všech relevantní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ů, MOLAPů, HOLAPů, CRM, ODS a přehršle dalších až k současně silně atraktivním záležitostem typu In Memory 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ázovém prostředí, ale přímo v  souboru na  disku. Nu a při práci s aplikací se celý tento soubor či jeho potřebná část načte do operační paměti a tudíž veškeré 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. Dodejme 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 oblast MIS, BI, DWH letitá a nasazená řešení jsou vesmě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živatelsky komfortní, technologicky progresivní a  i  jinak zázračná řešení od  různých, většinou renomovaných dodavatelů. Druhou stránkou věci je skutečnost, že z výše zmíněných řešení se mnohé nepodař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 novinek byly brány shovívavě.

S  výše popsanými zkušenostmi jsme proto přistupovali i  ke  zmíněnému produktu QlikView. Pro rychlé posouzení proklamovaných vlastností se nabízela cesta nejjednodušší – vzít fungující řešení 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ředí. Řečeno, vykonáno a ejhle. Ono to fungovalo nad očekávání. Jen pro ilustraci – jednalo se o  aplikaci s cca 25 mil. záznamů. Doby odezvy u standardního řešení (MicroStrategy) se pohybovaly v závislosti 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ějeme? Máme mít obavy o to, co a jak bude následovat, 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 technologií, o kterých zatím moc veřejnosti dostupných informací 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 vizionář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-

15

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 podniků 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í širokému okruhu pravidelných a příležitostných uživatelů. 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ší související pojmy se staly nedílnou součástí světa jak informačních technologií tak managementu firem a institucí. Problematika BI jako celku je v současnosti již velmi rozsáhlá. V tomto krátkém článku se budeme věnovat vybraným oblastem, které jsou z  hlediska 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ů anglické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řesvědčování zákazníků o výhodnosti BI řešení, jako tomu bylo v nedávné minulosti. Naopak, stále častěji se setkáváme s aktivním zájmem ze strany firem či institucí. Zdálo by se, že tato situace je pro dodavatele BI bezmála ideální. Pro kvalitní realizaci takový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 publikací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  dispozici 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.

16

Správné BI řešení musí být nástrojem pro přeměnu dat na  informace. Otevřenost řešení. Otevřenost 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ě strukturované podobě pro podporu přehledových údajů, analytických výstupů, realizaci ad-hoc dotazů, dolování dat, sledování trendů, vývojových řad a podobně. 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 prostř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 zadavatele 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 samozřejmě možné stanovit soubory požadavků třeba i ze všech oblastí a pojmout BI řešení jako projekt velice rozsáhlý. Tento přístup však v sobě skrývá nebezpečí, že požadavky na jednotlivé oblasti nebudou 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 nezbytná úzká spolupráce zákazníka se zkušeným dodavatelem. 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 nebezpečí – 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čností, že převážnou příčinou (více než 50 % - dle pramene) neúspěšnosti BI projektů jsou právě nekvalitní data. Podle stejných zdrojů dochází často až při snaze o BI řešení k odhalení významné části nesouladů 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ární databáze. Primární databáze je nejčastěji realizována v prostředí zvolené relační DB. Do prostředí primární databáze (PD) jsou z jednotlivých zdrojů (provozní IS, historické a archivní údaje, vnější zdroje) 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 hlediska BI řešení nezbytné funkce: • PD je jednoznačně definovaným rozhraním mezi prostředím provozních IS (obecně zdroji dat) a prostředím DWH • PD je zdrojem pro realizaci DWH jako celku a jednotlivých specializovaných datových tržišť • PD umožňuje jednoznačně odhalit případné nesoulady 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šťuje plnění struktur PD ze zdrojů dat (provozní IS, … ) a nad takto naplněnými a aktualizovanými údaji vytváří a aktualizuje DWH struktury ve formě specializovaných datových tržišť. Problematika DP je jistě 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 (extrakce, transformace, načtení) případně ETLC (extrakce, transformace, načtení, čištění) či řešení DP specializovanou 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 prokazatelně 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 specializovanou 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 vlastními daty (metadaty). Takováto řešení umožňu-

jí významnou část požadavků na změnu či rozšíření 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člivě 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 implementovat. Při volbě aplikace je třeba dbát na to, aby realizované ř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šemi fázemi realizace jako červená niť. Frekvence výskytu tohoto pojmu může být často až nepříjemná, avšak na základě zkušeností s realizací je třeba konstatovat, ž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, které se prolínají a jsou na sobě závislé.

Struktura dat. Zmínili jsme se, že BI řešení jsou často s výhodou realizovaná po menších částech, etapách. Je samozřejmým požadavkem, že struktury dat realizované v úvodních částech budou využitelné i v dalších částech. Současně je zřejmé, že bude docházet k jejich rozšiřování v souvislosti s realizací dalších požadavků. BI řešení tak musí podporovat snadné zahrnutí přenosu dalších údajů ze zdrojových IS do prostředí PD a následně do navazujících struktur DWH.

Jak bylo výše zmíněno, nabízí se realizace BI řešení po jednotlivých částech, které pokrývají rozdílně zaměřené skupiny uživatelských požadavků. Při definování nových požadavků lze s výhodou vycházet z realizovaných částí a maximálně využít již realizovaných datových struktur a příslušných částí řešení.

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í rozsá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.

Závěrem … Pokud se nám podaří navrhnout a posléze realizovat 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ě podstatným částem – například oblasti publikování a  komunikace – se budeme věnovat v  některém z dalších příspěvků.

Uživatelské požadavky. Architektura BI řešení je otevřená také z  hlediska uživatelských požadavků.

Pavel Seibert [email protected]

17

Nové vlastnosti verzí 10 a 11 databázového serveru IBM Informix 1. Úvodem Smyslem tohoto krátkého sdělení je upozornit na  vlastnosti nejnovějších verzí databázového serveru IBM Informix, které umožňují mnohá praktická rozšíření jak pro vývoj aplikací, tak pro optimalizaci 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 verze 11.50 v květnu 2008.

oblastí prostoru tblspace typu a snížit počet případů, ve kterých se tyto oblasti nacházejí v jiných než primárních blocích.

2. Novinky ve verzi 10.00

Administrace databázového serveru v jednouživatelském režimu Administrátor databázového serveru může nyní využí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 administrace 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é.

Volitelná velikost stránky Od  verze 9.40 je možné vytvářet databázové prostory (dbspace), jejichž základní velikost (velikost chunku) není omezena na  2GB. Implicitně bylo nastaveno, že správu velkých chunků je nutno nastavit 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, maximálně však 16 kB.

Správa přístupových oprávnění pomocí výchozích rolí Administrátor může vytvořit roli, přidělit jí oprávnění a  přiřadit ji jako výchozí roli jednotlivým uživatelů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říkazem 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.

Definování společných oblastí vyrovnávací paměti Konfigurační parametr BUFFERPOOL definuje společ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í parametry BUFFERS, LRUS, LRU_MAX_ DIRTY a LRU_MIN_DIRTY se již nepoužívají.

Přejmenování prostorů typu dbspace Uživatel informix nebo uživatel s  oprávněním administrá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 reorganizaci dat ve stávajícím prostoru typu dbspace.

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 prostorů typu tblspace v  daném prostoru typu dbspace. 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 je volitelná pomocí parametrů TBLTBLFIRST a TBLTBLNEXT. Tato vlastnost umožňuje snížit počet

18

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, vypouš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 parametr 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í standardních příkazů onbar a ontape. Opětné odesílání indexů do sekundárních serverů 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 instance 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 -version 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 vylepšeného výkonu v následujících oblastech: • transakce XA • 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-

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šíření 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 primárního serveru jej lze manuálně přestavět na primár. CLR je určen pro edice Workgroup a Express. Dalším rozšířením funkcionality MACH11 je možnost modifikace 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 automatického kontrolního bodu se dosahuje toho, že blokování kontrolním bodem je uživatelsky nepozorovatelné. Stanovení maximální doby zotavení – zavedení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ů, dynamického ladění počtu LRU, AIO VP a  stanovení rychlosti I/O operací pro fyzický a logický log při zotavování. Pro CPU VP je možné vyhradit paměť. Administrace Při instalaci databázového serveru je nově generová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 monitorovat historii provozu. Nové obslužné vlákno (thread) umožňuje automatizovat 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 aktualizaci 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 jediný soubor sqexplain.out, do kterého se zapisovaly (append) všechny informace. SQL příkazem SET EXPLAIN FILE TO <jmeno> lze definovat výstupní soubor pro konkrétní SQL dotaz.

4. ZÁVĚR Smyslem č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 vlastnostech již bylo dávno voláno (nastavitelná velikost datové 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 [email protected]

NOVÉ VLASTNOSTI ORACLE DATABASE 11G V srpnu 2008 uplynul jeden rok od prvního vydání verze 11g databázového serveru Oracle a v okamžiku, 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  konkré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žitelnost pro všechny druhy dat a v celém životním cyklu, • vysoká kvalita služeb a  technologie umožňující vyniknout aplikacím. Hezký, i když ne zcela úplný popis nových vlastností 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ývojáře, ale také pro datové architekty a testery aplikací. 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ž hodnoty 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 podobnou 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ňové segmentace tabulek. Dále, lze segmentovat též

dle virtuálních sloupců, dle referenčního omezení (segmentace je pak dána segmentací otcovské tabulky) nebo bez předem daných hranic resp. pravidel (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áření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 databázovou cache, do  níž jsou bloky načítány též v komprimovaném stavu. Komprimovaný blok obsahuje „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 prahu zaplnění bloku - režie komprese při zápisu tak činí údajně pouze několik procent.

19

Secure Files Je přidán nový způsob uložení LOB (velkých objektů), 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 velkým objektům, zajištění jejich konzistence a  možnosti zálohování, šifrování, komprese, deduplikace 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 odkaz na ni. Pro kompresi používá databázový server standardní kompresní algoritmy - ale jen tehdy, jeli š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  souborový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 prostoru a možnost rychlého relačního přístupu k prvkům XML). OLAP Pokračuje integrace OLAP do  databázového serveru. 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í standardní mechanismy řízení přístupových práv. K dispozici jsou skripty pro přípravu kostek, které v řadě aplikací mohou nahradit programování kostek. DDL_LOCK_TIMEOUT DDL příkazy, které potřebují zamknout tabulku, doposud končily chybou, pokud zámek nebyl momentálně dostupný (např. pokud uživatelská transakce držela zámky řádků tabulky). Toto chování lze pozměnit nastavením parametru ddl_lock_timeout 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živatelské tabulky se uchovává v  interních tabulkách (SYS_FBA_*) po vytvoření archivu příkazem CREATE FLASHBACK ARCHIVE a předepsáním daného archivu 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é

20

disky. Archiv se automaticky čistí podle předepsané doby retence. Historická data se z  archivu vytahují pomocí SQL dotazu s  modifikátorem AS OF TIMESTAMP jména uživatelské tabulky ve složce FROM (podobné možnosti byly zavedeny již ve verzi 9i resp. 10g ve spojení s nástroji Flashback Query resp. Flashback Versions Query; tyto nástroje ovšem využívají undo informaci, která má omezenou životnost). Transaction Flashback Pomocí procedury DBMS_FLASHBACK. TRANSACTION_BACKOUT či grafického prostředí Enterprise Manageru lze stornovat zadanou transakci 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 automatické notifikace o změně tabulek, na které se odkazuje zadaný SQL dotaz, nebo o změně výsledku 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ředchozí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) a pro zvolenou funkci (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 aplikací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í citlivý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); optimalizá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  dosavadní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 statistiky 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ěnnými Optimalizátor při opakovaných výpočtech příkazu 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ů tabulek srovnávaných s hodnotami proměnných. Automatic SQL Tuning Advisor Automatické ladění SQL je založeno na  nástroji SQL Tuning Advisor zavedeném ve  verzi 10g. Nástroj umí pro zadaný příkaz či příkazy SQL navrhnout 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 automaticky 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 tabulek. 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í navrhnout optimální kombinaci přidání a zrušení indexů, materializovaných pohledů a partitions s ohledem

na  sledované příkazy SQL, jejich náročnost a  četnost 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í grafického prostředí Enterprise Manageru můžete vyexportovat do  souboru veškeré informace potřebné pro spuštění zadaného SQL příkazu a  naimportovat je do testovacího prostředí. Informace zahrnují např. samotný příkaz, jeho výpočetní plán, potř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, který 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 databá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  plně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 parametru, 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é vlastnosti – „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 nedostalo. 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 komplexně pokrývá více a  více oblastí potřeb zákazníků. Zmiňme alespoň tři nástroje dodávané společ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 aplikací nad databází bez nutnosti většího programování). Z  dalších produktů zmiňme alespoň Times Ten In-memory Database pro extrémní požadavky na rychlost a Enterprise Manager, který byl primárně určen pro správu a monitorování produktů Oracle a nově umí např. monitorovat aplikace z pohledu 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 [email protected]

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/113e 150 00 Praha 5 tel.: +420 257 288 211 fax: +420 257 288 221 [email protected]

21

Zelený KOMIX 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 managementu systému (IMS). V rámci IMS naše společnost v současné době vytváří podmínky pro splnění požadavků mezinárodní normy ČSN IEC ISO 20000-1 pro systém managementu 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í. Proč se KOMIX věnuje také ekologii, životnímu prostř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 života některých občanů, firem a  také i  IT firem. Při dodržování norem ekoprovozu mohou IT firmy dosáhnout dvojího efektu v  podobě úspor nákladů a ochrany životního prostředí. Nejlepší firmy v oboru IT postupně „zelenají“. Příkladem může být iniciativa Big Green, společnosti IBM, jejíž cílem je dosáhnout 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žadavky zákazníků státní správy při výběrových řízeních a v rámci společensky odpovědného chování rozhodlo v  roce 2006 zavést systém environmentá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 činností společnosti, které ovlivňují nebo mohou ovlivnit 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í aspekty (prvek, který může ovlivňovat životní prostředí). Například nemáme v naší společnosti žádný nebezpečný odpad související s  vyráběným produktem. Charakter naší výroby v KOMIXu je už takový, že k  naší „výrobě“ nepoužíváme ani žádné chemické látky nebo přípravky, které by bylo potřebné skladovat nebo likvidovat a používat v souladu 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ů.

Odpady Odpady, které naše společnost produkuje, se samozřejmě snažíme nejen třídit, ale také jejich vznik minimalizovat. Používáme v  maximální míře elektronickou formu komunikace, a  také elektronické dokumenty. Odpad, který nám vznikne třídíme,

22

tam kde je to možné, na plast a papír. Takto vytříděný odpad je potom odevzdán k dalšímu zpracování autorizovaným firmám. V následují tabulce je uvedeno množství vytříděných a předaných odpadů 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ěsta 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ávají 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ů, elektroodpadu, likvidaci komunálního odpadu a tříděného papíru. Dále pak se společností REMA máme uzavřenou smlouvu na  likvidaci nebezpečných odpadů a elektroodpadu. Recyklace se tedy také týká veškeré techniky (elektroodpadu), 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ředaný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řazené elektrické a elektronické zařízení)

0,120 t

0,400 t

0,075 t

V rámci systému environmentálního managementu je také každý rok odevzdáváno hlášení o  produkci a nakládání s odpady, dále je prováděno přezkoumá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ávními předpisy uvedenými v  registru právních a  jiných požadavků a interní audity celého IMS, včetně

požadavků normy ČSN EN ISO 14001 na systém environmentálního (ekologického) managementu. Také spotřeba elektrické energie představuje jeden z nejvýznamnějších environmentálních dopadů aktivit téměř každé firmy. Proto jsme se v KOMIXu zaměř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 krokem, 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ředí 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ácností (prostřednictvím zaměstnanců). V  rámci tohoto 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 mohou zaměstnanci odevzdat například svůj nepotřebný mobil, příslušenství nebo baterii a my již zajistí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 činností, které mohou ovlivnit kvalitu životního prostředí. Tyto činnosti nelze změnit jednorázovým projektem 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 oblasti 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 obyvatele naší planety. Jiří Feřtek [email protected]

Zapomenuté klíče 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) rozkreslený vedle sebe ve třech navazujících časových úsecích , ve kterých se mění pohyb uklízeček po budově. Vaším úkolem je do 30 minut dojít do kanceláře ve 3. patře pro klíče.

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. Ř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 podlaha 30 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)

Test

Tomáš Vahalík [email protected]

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.

1. Bluetooth je a) Viagra uvízlá mezi zuby b) 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 je a) Gramofon s Magičem b) Global System for Mobile Communications c) Generální Sekretář Mongolska 3. LAN je a) Local Area Network b) 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 je a) Motorka Pro 3 - oblíbené motorové jízdní kolo vyhledávané hlavně vietnamskými zákazníky b) Motorová Pila k jejímuž ovládání stačí 3 prsty c) MPEG-1 Audio Layer 3 5. IP je a) Izraelský Polibek - označení pro izraelské tříštivé střely vysílané do hustě obydlených míst pásma Gazy b) 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 je a) Geographic Public Service b) Global Positioning System c) Gde Preboha Som? 7. HDD je a) Hard defection destruction b) Hard disk drive c) Head digital derange

8. DVD je a) Divotvorný video disk b) Defect video disk c) Digital Versatile Disc 9. ROM je a) příslušník menšiny b) Read-only memory c) Real oracle men 10. ADSL je a) Asymetric Digital Subscriber Line Technologie umožňující velmi rychlý přenos dat po telefonní lince. b) Alkoholik Doražený Syntetickým Lihem d) Auto Do Sovětských Lesů

23

Děkujeme všem našim klientům za důvěru

KOMIX s.r.o. Avenir, Radlická 751/113e, 150 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o. DTP a produkce: SDP V.I.P. Servis, s.r.o. © Komix s.r.o. 2008