komixí noviny 2008/2009

Transkript

1 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 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. KO- MIX 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 napad@komix.cz. 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). 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ákazní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 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. Použití na CDBP 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

2 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. 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ů, komentář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 sobotka@komix.cz 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

3 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 Miroslav Žebrák zebrak@komix.cz 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í obchodní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

4 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. Novinky postihly i oblast mobility. CAS Mobile- Access a CAS WebAccess jsou nyní součástí edice CAS genesisworld Premium edition, k dispozici je nyní nový modul CAS MobileCRM pro Blackberry. Na rozdíl od standardního modulu CAS MobileAccess mohou mobilní uživatelé s přístroji Blackberry využívat výhod PUSH technologie. 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. 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 , česká verze je plánována na prvního čtvrtletí Spolu s novou verzí CAS genesisworld byla vydána i nová v pořadí již sedmá verze oblíbeného groupwarového nástroje. Miroslav Žebrák zebrak@komix.cz 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 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. 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 zebrak@komix.cz 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

5 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 stanovený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ý stastnyp@komix.cz 5

6 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, 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. 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í ový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. úč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. 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ů. 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 KO- MIX 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 richter@komix.cz, janca@komix.cz 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ížení 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. 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. 6

7 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ů. 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 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- 7

8 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 kotoun@komix.cz 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é, 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). 8

9 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. 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. 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 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 honigschmied@komix.cz 9

10 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 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 em 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í 10

11 na ostatní vyvíjené komponenty celého systému se nedá vyvíjený systém dostatečně otestovat. Cílem systémového a integračního testování je 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 KO- MIXu. 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 Michal Černický cernicky@komix.cz 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 EDI- FACT, 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 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

12 Obrázek 1: Obecná architektura celkového řešení nezahálíme, je připravován převod databáze z IBM Informix řady 9.X do MS SQL Server Instalujeme IBM Informix Client SDK 2.90.TC1 a připravujeme převod databáze. Volba na tuto verzi padla z důvodu stability v současně provozovaných řešeních. (Jak jsme se v tomto případě mýlili, ukáže až pozdější nepříjemné zjištění). Nastavujeme prostředí klienta pro podporu UTF-8, avšak již při prvních testech zjišťujeme, že nám zcela zjevně něco chybí. Na data se dostaneme, ale jejich zobrazení není správné. Chybí nám Global Language Support, vzpomeneme si, a po instalaci této podpory je již vše v pořádku, data se zobrazují tak, jak by měly. Následně zálohujeme prostředí IBM Informix Clienta a můžeme začít připravovat balíčky pro přenos dat na SQL Server Dějství druhé příprava autonomních úkolů Programové vybavení na straně aplikačního serveru obsahuje autonomní úlohy pro import a export dat. Toto řešení bylo provozováno i na platformě UNIX. Pro vývoj nových autonomních úkolů bude použit již navržený Microsoft.NET Framework 2.0. S úspěchem převádíme metadata popisující EDI- FACT zprávu do XML formátu a připravujeme algoritmus importu dat. Nebudu čtenáře zdržovat informacemi o tom, jak jsme rozdělovali části kódů, abychom docílili vytvoření znovupoužitelného frameworku pro autonomní úlohy, a také webové části řešení. Musím však říci, že pokud se chystáte vytvoř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 assembly cache). Abych se však vrátil zpět k naší implementaci. Mluvíme-li o importu dat ze vstupního souboru, tak část těchto prací není závislá na existenci databáze. V našem případě tomu nebylo jinak. Oddělením částí programování, rozebráním EDIFAC zprávy a její validací jsme mohli pokračovat v pracích nezávisle na stavu migrace 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í infrastruktury určené pro tento účel. Pro podporu komunikace s touto infrastrukturou distribuuje speciální SDK, a to jako C++ knihovny. Chvíli jsme váhali, zda pro vytvoření programového vybavení stahující data z této brány nepoužít Microsoft.NET Framework, ale v tomto případě převážily výhody nativní integrace s C++. Zajímavostí tohoto SDK je, že může spolupracovat s bránou dvěmi následujícími způsoby: a) komunikaci zahajuje infrastruktura, b) komunikaci zahajuje klient ad a/ celková konfigurace je nastavena v tzv. módu OnDemand. Toto se jeví jako efektivní řešení, ve kterém nedochází ke zbytečné zátěži této infrastruktury. Abych objasnil tento princip, musím říci, že v tomto módu infrastruktura samotná aktivně oslovuje na definovaném TCP/IP portu poslouchající kanál na straně klienta, a po navázaní komunikace probíhá spojení již pomocí tohoto kanálu. Nezbytným předpokladem je, že na straně klienta je programové vybavení umožňující nejenom poslouchat na vyhrazeném portu, ale i předat řízení dalšímu programovému vybavení. Tato část na straně klienta také slouží jako most pro komunikaci mezi volaným programovým vybavením na jedné straně a infrastrukturou na straně druhé. Pokud se to zdá příliš složité, tak uživatelé UNIX přesto jistě tuší, že programové vybavení inetd je trefa do černého. Komunikace typu OnDemand je znázorněná na následujícím obrázku. Obrázek 2: Komunikace typu OnDemand Zastánci Windows zřejmě již ví, že pod tímto systémem to není takovým standardem jako u UNIX. Pokud byste připravovali takovéto řešení ve vašem produktu, tak byste se měli striktně vyhnout použití funkcí zapisujících informace na standardní vstup nebo výstup. Důvodem proč nezapisovat je to, že pokud vaše programové vybavení volá někdo tí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. 12

13 Po následné kontrole v Informix jsme zjistili, že data se přenesla chybně. Verdiktem je, že v migraci je někde chyba a je ji potřeba co nejdříve objevit. Začíná zdlouhavé hledání a testování za podpory software umožňujícím porovnání datových tabulek, rozdělování připravených importních balíků na menší (po rozdělení na obsahově menší balíčky se 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 RevertTo- Self (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 jancek@komix.cz 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

14 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. Využití disciplín pro popis požadavků Přednosti RE (popis strukturovaným textem) a OOA (základní části katalogu uživatelských požadavků) jsme zdůraznili v minulém článku. Tentokrát se 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. Použití diagramu a strukturovaného textu Při popisu požadavků se občas setkáváme se dvěma extrémy stovkami stran textu bez jediného obrázku nebo naopak s mnoha obrázky bez zjevných návazností a bez jakéhokoliv vysvětlujícího textu. Doporučit lze samozřejmě střední cestu. Pro vytvoření nadhledu je vhodné použít diagra- 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 1 Volba techniky podle úrovně podrobnosti Obrázek 2 - Použití UML diagramů Obrázek 3 - OBA scénář - vazby mezi modely Obrázek 4 - Správná míra podrobností UML diagramy V současné době jsou UML diagramy velmi často používaným prostředkem pro dokumentaci požadavků. UML obsahuje mnoho typů diagramů (více či méně specializovaných na různé činnosti). Někdy dochází k míchání typů objektů z různých typů diagramů v jediném diagramu to ztěžuje orientaci začátečníka ještě více. Pro popis požadavků v dynamickém modelu jsou vhodné diagramy: UML Activity (vhodný pro jednoduchý popis procesů), UML Use Case (vhodný pro popis interaktivních systémů). Oba uvedené typy diagramů lze používat s výhodou v jediném dokumentu (podle povahy příslušné části úlohy). Je důležité dbát na jednoduchost diagramu z hlediska kvalitativního (používejte co nejméně typů prvků na diagramu) i kvantitativního (složité diagramy přetvořte na hierarchickou strukturu jednoduchých diagramů). Pro popis požadavků ve statickém modelu použijte diagram UML Class Při popisu požadavků není vhodné rozdělovat třídy do skupin podle vrstev architektury (uživatelské rozhraní, aplikační logika, databázová vrstva). Toto rozdělení je nezbytné později při návrhu (volbě architektury). Místo tříd Formulář objednávky, Obsluha objednávky a Databázová tabulka objednávky je vhodné použít jedinou tzv. doménovou třídu Objednávka. Analogie platí i o metodách takové doménové třídy místo metod Zobrazení formuláře, Validace dat a Uložení záznamu je vhodné použít jedinou metodu Uložení. Při popisu atributů stačí použít obecné datové typy (řetězce definované maximální délky, čísla s daným maximálním rozsahem, datum, čas,...) je to vhodnější než použití konkrétních datových typů programovacího jazyka nebo databázového serveru. Volba konkrétního typu proběhne opět později v rámci návrhu. Dodržení uvedených pravidel doménového modelování má dva kladné následky: modely jsou jednodušší tedy lépe čitelné při schvalování odběratelem, zkušený návrhář dokáže lépe optimalizovat pro cílovou architekturu a technologie. Scénáře OBA Při použití několika modelů popisu požadavků jsou důležité vazby mezi těmito modely. Tuto nezbytnou podmínku kvalitního popisu požadavků je možné zajistit s pomocí techniky scénáře z metody OBA. Scénář OBA slouží k jednoduchému popisu požadavků na chování. Má podobu tabulky, jejíž řádky popisují posloupnost vyvolání metod tříd. Vlastní vyvolání metody třídy je popsáno v řádku tabulky. Na rozdíl od Use Case scénářů nepředpokládá scénář OBA variantní cesty (Alternative Paths). Pro po- 14

15 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. Úroveň podrobnosti požadavku Celý článek se zabýval metodami a technikami analýzy požadavků, ale to samo o sobě začátečníkovi 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! Závěr Uvedené disciplíny, metody a techniky nestojí proti sobě. Vhodným výběrem jejich výhod je lze propojit 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 ciha@komix.cz 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ů, MOLA- Pů, 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

16 cemi. Množství a koncentrace dat v podnikových databázích a dalších zdrojích dat narůstá. Naproti tomu pokračující fragmentace BI nástrojů pro jejich zpracování a vizualizaci redukuje možnosti reálného využití těchto informací. Proto dnes většina 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. 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- 16

17 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. 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. Uživatelské požadavky. Architektura BI řešení je otevřená také z hlediska uživatelských požadavků. Jak bylo výše zmíněno, nabízí se realizace BI řeš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í. 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ů. Pavel Seibert seibert@komix.cz 17

18 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 byla oficiálně uvedena na trh v červenci 2007 a verze v květnu Novinky ve verzi 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. 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í. 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 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. 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é. 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. 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. 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- 18

19 bulky jsou trvale dostupné. Tyto příkazy jazyka SQL umožňují vytvářet a vypouštět indexy, aniž by bylo nutné uzamknout tabulku po dobu vytváření nebo vypouštění indexu. 3. Novinky ve verzi 11 Instalace Pokud administrátor preferuje grafické uživatelské rozhraní při instalace IDS má možnost spustit skript ids_install s argumentem gui. Implicitně zůstává instalace v klasickém znakovém prostředí. Nově byl přidán skript pro odstranění instalace. Rozšířená škálovatelnost replikací Zavedením tzv. Multi-node Active Cluster for High availability (MACH11) dochází k výraznému rozšíř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 paulp@komix.cz 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 oracle.com/technology/pub/articles/oracle-database-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

20 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é 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 20