ITerační VýVOj V PraXI

komixí noviny 2008/2009
Vážení čtenáři,
KOMIX v roce 2008 vstupuje do sedmnáctého roku svého působení na trhu. Za tu dobu se několikrát
změnila vnitřní organizace, výrazně se změnila struktura obratu – klesl významný podíl hardware
a licencí a naopak podstatným způsobem vzrostl podíl služeb. Od svého založení však KOMIX
zůstává společností, která sleduje vývoj IT technologií a osvojuje si ty progresivní, aby svým
zákazníkům mohla nabídnout moderní aplikace, které jim přinesou konkurenční výhodu.
S tím souvisí i to, že vyhledáváme zákazníky, kteří chtějí inovovat, kteří chtějí dělat
svůj business jinak než
konkurence. Pochopitelně při tom nemůžeme zůstat stranou
dění ve státní správě,
kdy se zákazník s největším IT budgetem
v republice rozhodl přihlásit k trendům e-governmentu a investovat do rozsáhlého využití IT technologií ve prospěch občanů a zjednodušení jejich
komunikace se státem. Probíhající reformy vyvolávají též rozsáhlé změny stávajících informačních
systémů.
KOMIX se v roli subdodavatele softwarového řešení účastní na integračních projektech, podporujících začlenění České republiky do Evropské unie,
další týmy pracují na podpoře reforem nemocenského a důchodového pojištění a zdravotní reforma
zase vyvolává tlak na úpravy informačních systémů
zdravotních pojišťoven, pro které také pracujeme.
Jsem hrdý na to, že naši pracovníci opakovaně dokazují, že jsou schopni spolehlivě realizovat tyto
rozsáhlé a často i rizikové projekty.
Naši specialisté dnes působí i na projektech mimo
Českou republiku – v Polsku, Maďarsku, Bulharsku
nebo Německu.
V uplynulém roce KOMIX uvedl na český IT trh i několik novinek založených na moderních technologiích. Námi uváděné produkty se dostaly do finále
soutěže o IT produkt roku jak v roce 2007, tak v roce
2008. Jedná se o programové vybavení pro podporu prodejních týmů od německé společnosti CAS
genesisWorld (CRM) a CAS teamWorks nebo o produkt z oblasti bezpečnosti společnosti KOBIL či nástroj QlikView pro rychlou analýzu dat pro podporu manažerského rozhodování raketově rostoucího
start-upu QlikTech.
Na přelomu roku 2008 a 2009 budeme moci nabídnout CAS genesisWorld i v hostované verzi. Tj. KOMIX zajistí kompletní provoz aplikace na své technice a zákazník si ji bude moci pouze pronajmout.
Potřebuje k tomu jen dobré internetové propojení.
Stejnou službu již dnes poskytujeme se softwarovým vybavením pro Service Desk. Uvažujete-li tedy
o změně obchodních procesů nebo chcete svým
zákazníkům poskytovat podporu v souladu s nároky norem ISO nemusíte začínat rozsáhlou investicí
do softwarové podpory, tuto službu si můžete pronajmout.
Začtete-li se do příspěvků v těchto novinách, jistě poznáte, že KOMIX disponuje poměrně rozsáhlým know-how z řady oborů. To vidím jako velikou
přednost naší společnosti, která nám umožňuje řešit i složité situace a problémy. Na řadě projektů
jsme prokázali, že jsme schopni i v průběhu projektu nalézt a aplikovat nové technologické prvky nebo postupy a s jejich pomocí realizovat řešení
splňující požadavky zákazníka.
Na závěr svého textu bych se chtěl vrátit k jedné myšlence zmíněné v úvodu. KOMIX nabízí řešení vytvářená na míru, a proto hledáme zákazníky, kteří chtějí spolu s námi vytvářet něco nového,
užitečného, co jim pomůže v jejich práci, v rozvinutí obchodu nebo zkvalitnění služeb. Máte-li nějaký nápad, jak něco změnit, inovovat, zavést novou
službu nebo naopak vidíte problém a chtěli byste s někým diskutovat jeho řešení, prosím napište
na adresu [email protected]. Zkusme problémy řešit společně!
Petr Kučera
Iterační vývoj v praxi
Iterační (někdy také přírůstkový) vývoj je výrazným a důležitým rysem moderních přístupů k tvorbě softwaru. Tento článek popisuje použití iterační metody v rámci interního vývoje a testování
na projektu CDBP (biometrické pasy).
níkem. Zrealizuje se primárně to, co zákazník nejvíce potřebuje, a pak na základě zkušeností z provozu
se řeší, jakými funkcemi se bude pokračovat dále.
Iterační vývoj
Použití na CDBP
Základní myšlenka iteračního vývoje je jednoduchá: realizaci díla rozdělíme do kratších etap (typická délka 1-4 týdny) nazývaných iterace. V rámci
každé z nich musí vzniknout funkční verze softwaru, kterou lze potenciálně předat zákazníkovi k ověření a používání. Běžně se nenasazuje do provozu
nová verze po každé iteraci, ale vždy po několika
iteracích dle dohody se zákazníkem.
Hlavní důvodem pro tento postup je rychlé získání
zpětné vazby od zákazníka při skutečném užívání
systému. Jedině tak lze plnohodnotně ověřit, že vytvořený systém odpovídá jeho potřebám. Předchází se tomu, že bude vytvořeno velké množství funkcí, které v okamžiku nasazení do provozu již nejsou
potřeba. Proto se funkce zařazované do jednotlivých iterací vybírají podle priority stanovené zákaz-
1. i 2. etapa projektu CDBP byly založeny na standardním vodopádovém vývojovém cyklu. Na počátku je celková analýza, po které následuje návrh,
obé zakončené akceptačním řízením vytvořených
dokumentů. Na tyto fáze navazuje vlastní konstrukce (programování). Vzhledem k nedostatku času
na realizaci (jak typické pro projekty tohoto typu)
se uvedené tři fáze částečně překrývaly, jinak by
systém nemohl vzniknout v potřebných termínech.
Následuje rozsáhlé testování, které se skládá z interních testů uvnitř jednotlivých týmů, integračních testů mezi zúčastněnými dodavateli, nezávislých testů, které realizuje třetí subjekt, a konečně
testů akceptačních, při kterých zákazník schvaluje
vytvořený systém.
Ve 2. etapě projektu CDBP, realizované v průběhu
roku 2008, jsme se v rámci konstrukční fáze projektu rozhodli ověřit použití iterační metody pro
programování a interní testování. Princip metody
zachycuje Ganttův diagram na obrázku. Zjednodušeně řečeno: Konstrukční práce jsou rozdělené
do 2-týdenních iterací, na každou z nich navazuje
zhruba týden testování nově vytvořených funkcí.
Vzhledem k tomu, že 2. etapa projektu CDBP je rozvojem již existujícího a funkčního systému, není použití iterační metody problematické. U nově vznikajícího systému by bylo potřeba počítat s úvodní
„náběhovou“ fází, kdy ještě není nic hotovo a testování je zpočátku poněkud složitější.
Popis metody
Podívejme se na jednotlivé kroky podrobněji. Každá iterace je zahájena detailním naplánováním konstrukčních prací v dané iteraci. Tuto činnost provádí vedoucí programátor s ohledem na dlouhodobý
postup prací, příp. aktuální priority. Jednotlivým
programátorům jsou přiřazeny dílčí úkoly, z nichž
žádný svým rozsahem nesmí přesahovat dobu trvání jedné iterace (tj. musí být reálné je v rámci
dané iterace dokončit).
Následují 2 týdny konstrukčních prací, jejichž součástí má být také vytvoření vývojářských testů (unit
testy apod.). Po ukončení programování je vytvořena nová verze softwaru a je připravena do testovacího prostředí. Programátoři napíší stručné shrnutí ke způsobu řešení jednotlivých úkolů, což slouží
mj. jako podklad pro testování či tvorbu dokumentace.
V průběhu druhého týdne konstrukce se připravují testovací scénáře pro nově vznikající funkce, na základě kterých bude
ověřena jejich kvalita a soulad se zadáním. Vedoucí testování následně
naplánuje průběh testování a přiřadí
jednotlivým testerům dílčí úkoly.
Ve 3. týdnu probíhá testování. Nejprve je snahou najít fatální problémy,
které znemožňují další postup testovacích prací. Takové chyby jsou ihned
opraveny. Chyby menšího rázu jsou
pouze evidovány a jejich oprava je
provedena v rámci vývojových prací
další konstrukční iterace, která je zahájena paralelně s testováním. Retest
opravených chyb se pak provádí při
dalším kole testování.
2
V týdnu, kdy probíhá testování, se rovněž aktualizuje dokumentace v rozsahu, který odpovídá nově
implementovaným funkcím. Tato průběžná aktualizace po každé iteraci se týká především systémové
dokumentace. Uživatelské příručky jsou aktualizovány později v odděleném režimu především v závislosti na tom, zda se již nemění uživatelské rozhraní aplikací. Vzhledem k tomu, že dokumentaci
považujeme za plnohodnotnou součást dodávky,
je rovněž podrobována ověření kvality ze strany
testerů. Po ukončení konstrukčních a testovacích
prací je provedeno zhodnocení dokončené iterace a řeší se např. optimalizace pracovních postupů,
aby lépe reflektovaly získané praktické zkušenosti.
Jak již bylo uvedeno (a je patrno i z obrázku), testovací práce probíhají paralelně s konstrukčními pracemi další iterace. V rámci plánování iterací musí
tedy vedoucí programátor zohlednit skutečnost, že
se při testování objevují chyby, které je třeba ihned
(u fatálních chyb) či v rámci další iterace opravit.
Podpůrné nástroje
Pro podporu výše popsaného iteračního režimu
práce používáme na projektu CDBP 2 nástroje:
MS Excel a ProjectX. Pomocí MS Excel se eviduje ucelený seznam funkcí, které je třeba vytvořit, a plán jejich realizace v jednotlivých iteracích.
U každé funkce je uveden stručný popis, odhadovaná pracnost, plánované zařazení do iterace a programátor, který bude funkci realizovat. Je zde obsažen jak dlouhodobý orientační plán, tak přesný
plán na nejbližší jednu či dvě iterace. Pomocí agregačních funkcí MS Excel lze poměrně snadno zobrazit např. plán vytížení jednotlivých programátorů
nebo odhad dokončení prací na konci jednotlivých
iterací.
V nástroji ProjectX, který se na CDBP obecně využívá pro evidenci úkolů, jsou průběžně zadávány činnosti vyplývající z obsahu jednotlivých iterací pro
programátory i testery. Rovněž sem mohou být
doplňovány podrobnější údaje k řešení úkolů, ko-
mentáře programátorů, resp. testerů, podklady pro
tvorbu dokumentace apod. ProjectX je v rámci interního testování používán také pro evidenci chyb.
Očekávané přínosy
Cíle, které sledujeme při použití popsané iterační
metody, jsou následující:
• Průběžná kontrola vytvořeného softwaru, rychlá
„zpětná“ vazba od testerů, kteří de facto zastupují cílové uživatele systému. Chyby v nově vytvořených funkcích se řeší v době, kdy programátoři
mají vše ještě v čerstvé paměti.
• Lepší přehled o skutečném postupu prací – co je
otestováno a opraveno, lze považovat za dokončené. Z praktických zkušeností totiž vyplývá, že
konstrukční práce není možné považovat za hotové, pokud neproběhlo testování.
• Rytmus a řád ve fungování celého týmu, a tím
zvýšení efektivity práce týmu. Pozitivně se to
projevuje především ve vztahu mezi vývojáři
a testery.
• Více času na testování, protože testování je vlastně přirozenou součástí konstrukčních prací
od počátku vývoje. Díky tomu také očekáváme
méně problémů a stresu v závěrečném testování po ukončení konstrukčních prací. Negativním
(z hlediska nákladů) důsledkem může být v celkovém souhrnu zvýšená pracnost testování.
Zhodnocení
Konečné zhodnocení a shrnutí zkušeností bude
provedeno až na konci projektu, kdy bude možné ověřit, jaký měl použitý přístup dopad na nejen
na konstrukční, ale také na návazné fáze projektu,
a zejména na kvalitu díla. Po zhruba 6 vývojových
iteracích se však zdá, že použití iterační metody
bude plnit výše uvedené cíle, a přispěje tak k hladšímu průběhu po organizační stránce dosti náročného projektu.
Petr Sobotka
[email protected]
KOMIX spoluvytváří projekt EU
Přistoupení České republiky do Evropské unie dalo
českým firmám možnost podílet se na evropských
orientovaných aktivitách a využívat pro rozvojové
projekty jejích fondů. Jedním z projektů financovaných EU je i projekt Village. Na projektu Village se
podílí 8 členů z 5 evropských zemí, které jsou sdružené do projektového konsorcia. Členové konsorcia se pravidelně scházejí, vyhodnocují jednotlivé
projektové mezníky a společným úsilím se podílí na jeho směřování k dosažení projektového cíle.
Členem konsorcia je i KOMIX, který hraje v projektu Village roli plnoprávného člena. V červnu 2008
jsme v rámci projektu úspěšně hostili dvoudenní
Project Meeting Board, kterého se zúčastnili všichni členové konsorcia.
Hlavním cílem projektu Village je rozvinout kooperativní CRM poskytované ve formě služby zacílené
pro trh malých a středních podniků. Plánovaným
výsledkem projektu je technické řešení, které bude
odpovídat stávajícím a budoucím platným paradigmatům trhu, kde je CRM poskytováno ve formě
SaaS (Software as a Service). SaaS je způsob využívání počítačových aplikací, kdy se intenzivně využívá provozovatelem služby hostovaná aplikace. Výhody modelu SaaS představují pro zákazníky rychlé
nasazení produktu, nízké náklady na správu IT, odstranění nutnosti správy hardware a vyčlenění dalších služeb mimo zákazníka používající CRM. Využívání SaaS nabývá celosvětově stále větší popularity
a je jednoznačně jedním ze silných trendů svědčícím o budoucích způsobech využívání prostředí Internetu pro byznys účely.
Pro české a slovenské zákazníky představuje účast
KOMIXu v projektu Village příslib brzkého představení technologicky i obchodně zcela nově pojatého řešení pro správu jejich CRM aktivit.
Chcete vědět více? Navštivte www stránky projektu
na adrese http://www.village-project.eu/village/
Miroslav Žebrák
[email protected]
Novinky v CAS genesisWorld verze 10
Vývojový plán společnosti CAS Software AG garantuje každoročně vydání nové verze CRM aplikace
CAS genesisWorld. Nové verze vychází každoročně
vždy v létě. Letošní nová verze se vyznačuje celou
řadou novinek, které se neomezují pouze na technické inovace.
Největší změnou pro zákazníky je nový licenční systém. CAS genesisWorld je nyní prodáván ve třech
edicích Standard, Premium a vše zahrnující Suite. Rozdělení CAS genesisWorld na jednotlivé edice bylo způsobeno množstvím nových funkcí, které byly do systému zahrnuty.
Kromě zmíněných edic disponuje nyní CAS genesisWorld novými moduly. Mezi tyto moduly patří
CAS Marketing, CAS Sales, CAS Reports, CAS Projects, CAS Helpdesk, CAS Timeclient, CAS Mobile
CRM for Blackberry.
Především CAS Marketing přináší dlouho očekávanou změnu v práci s kampaněmi, grafické navrhování work-flow kampaní, definice následných akcí
a vyhodnocení úspěšnosti jednotlivých marketingových akcí přináší do marketingového oddělení
zvýšenou efektivitu. CAS Sales umožňuje řízení ob-
chodních zástupců nad rámec standardního sledování obchodních příležitostí s důrazem sledování
výkonnosti jednotlivých obchodních zástupců.
CAS Helpdesk a CAS Timeclient přidávají do prostředí CAS genesisWorld nové typy informací. V pří-
3
Na rozdíl od standardního modulu CAS MobileAccess mohou mobilní uživatelé s přístroji Blackberry
využívat výhod PUSH technologie.
padě CAS HelpDesku pracuje zákazník v prostředí
speciální www aplikace, informace jsou však přeneseny do prostředí CRM a k dispozici jeho uživatelům. CAS HelpDesk disponuje takovými funkcemi,
jako jsou notifikace o změnách v trouble tiketech,
úrovni poskytovaných služeb dle SLA, historii řešení jednotlivých problémů apod. CAS Timeclient
je vhodným doplňkem všude tam, kde je potřeba
vykazovat pracovní čas na vyšší úrovni detailu. Přiřazování času jednotlivým projektům a úkolům je
vhodným doplňkem k modulu CAS Projects. CAS
Timeclient disponuje vlastním www rozhraním,
které umožňuje vykazovat časy i mobilním zaměstnancům.
CAS genesisWorld nabízí i branžová řešení. Zákazníci mohou profitovat ze speciálně upravených edic
aplikace, které umožňují rychlou implementaci,
spuštění a speciální funkce pro jejich odvětví. V loňském roce byl vydán CAS Drive, branžové řešení pro
dealery automobilů umožňující napojení na dealerské systémy a snadné mapování nabídek a poptávek po automobilech. CAS genesisWorld ve verzi 10
přidává nová branžová řešení CAS IT Services, CAS
Consulting, CAS Engineering a CAS Research.
Novinky postihly i oblast mobility. CAS MobileAccess a CAS WebAccess jsou nyní součástí edice
CAS genesisWorld Premium edition, k dispozici je
nyní nový modul CAS MobileCRM pro Blackberry.
Mottem nové verze CAS genesisWorld bylo nabídnout uživatelům drobná vylepšení, která lze využít zejména v každodenní práci. Spolu s novou verzí CAS genesisWorld 10 získají nově čeští zákazníci
jako dárek lokalizaci oblíbeného bezplatného nástroje CAS Info@Click. CAS Info@Click umožňuje
rychlé vyhledávání v adresách CAS genesisWorld,
synchronizaci adres, úkolů, schůzek s Microsoft
Outlookem, ale také třeba s Google kalendářem.
Mezi zajímavé funkce CAS Info@Click patří i možnost využití VoIP klientů jako je např. Skype či webové telefonie s telefonními čísly uloženými v CAS
genesisWorld.
CAS genesisWorld verze 10 je k dispozici od 1. 8.
2008, česká verze je plánována na prvního čtvrtletí 2009. Spolu s novou verzí CAS genesisWorld byla
vydána i nová v pořadí již sedmá verze oblíbeného
groupwarového nástroje.
Miroslav Žebrák
[email protected]
Computerworld IT produkt roku 2008
V roce 2008 vyhlásila redakce časopisu ComputerWorld druhý ročník soutěže o IT produkt roku.
Podmínky soutěže umožňovaly přihlásit jakékoli zařízení, software, řešení nebo službu z oblasti informačních a komunikačních technologií, jež lze využít v podnikovém prostředí. Produkt, respektive
jeho přihlašovaná verze, nesměl být na trhu déle jak
od 15. srpna 2007. Základními kategoriemi soutěže
byly zvoleny: software, hardware, řešení a služba.
Soutěž ComputerWorld IT produkt roku 2008 je vícekolová, v hodnotících kritériích je kladen důraz
na inovativnost řešení, které může spočívat v celku,
v detailech a na míru pozitivního odlišení od podobných konkurenčních produktů. Produkty splňující uvedená kritéria v dostatečné míře postupují do finále. V rámci finále dojde k výběru vítězného
produktu v každé kategorii.
KOMIX přihlásil do soutěže 3 produkty a výsledky jsou pro KOMIX velmi příjemné, neboť hned
všechny 3 produkty uspěly a postoupily do prvního finálového kola. V kategorii Podnikový systém se
o úspěch postaral CRM systém od společnosti CAS
Software - CAS genesisWorld ve verzi 9 a systém
pro řízení a plánování kapacit od společnosti Hyperformix - IPS Performance Optimizer. V kategorii Informační systémy postoupilo portálové řešení
pro týmovou spolupráci od společnosti CAS Software AG - CAS teamWorks ve verzi 6.
Celkem třikrát se KOMIX může v roce 2008 pyšnit
logem ComputerWorld IT produkt roku. Pojďme si
tedy naše úspěšné finalisty blíže představit.
IPS Performance Optimizer slouží k modelování budoucí výkonnosti IT systémů, plánování jejich
4
změn a rozvoje na základě dat z monitoringu testovacího či produkčního prostředí. Umožňuje odhalit problémová místa systému a najít způsob jejich odstranění při minimalizaci zákroků v reálném
prostředí. Jednotlivé modely jsou vyhodnocovány
z hlediska dostatečnosti výkonu a splnění finančních omezení. Typické je nasazení pro extrapolaci
výstupů zátěžových testů provedených ve zmenšeném testovacím prostředí na produkční prostředí,
kde zátěžové testy nelze provádět.
CAS genesisWorld představuje CRM řešení pro
správu adres, projektů, dokumentů, úkolů a dalších
aktivit nejen marketingového a obchodního oddělení. Jeho hlavním úkolem je zvýšit efektivitu prodejních a marketingových aktivit, přičemž CAS genesisWorld pomáhá k dosažení cíle za použití celé
řady uživatelsky přívětivých funkcí a s pomocí propojování informací přináší 360stupňový pohled
na zákazníka. CAS genesisWorld umožňuje práci
v kanceláři, on-line v terénu, ale i off-line s pomocí tzv. replikace dat. Velmi dobrou vlastností CAS
genesisWorld je rychlá implementace a velmi sil-
né možnosti přizpůsobení aplikace, bez nutnosti
úprav aplikace programátory.
CAS teamWorks přináší přidanou hodnotu zejména pro použití ve skupinové spolupráci. Sdílení kalendáře, plánování a delegování úkolů, přehled
o vnitropodnikových procesech, realizovaných
projektech, zobrazení zodpovědností, pravomocí a práce dle předem vytvořených checklistů jsou
jeho silnými stránkami. CAS teamWorks umožňuje správu služebních cest, evidenci klíčů, místností, automobilů a dalších praktických požadavků.
Uživatel pro práci potřebuje pouze prohlížeč www
stránek. CAS teamWorks může být nasazen spolu s CAS genesisWorld. Současné nasazení přináší
synergické efekty využití společné datové základny a sdílení informací v back-office i front-office části společnosti.
Miroslav Žebrák
[email protected]
PPM není pouze software
Během posledních let se oblast řízení portfolia
(PPM - Project Portfolio Management) těší rostoucímu zájmu. Řada firem spojila svoji snahu o zvyšování efektivnosti právě s tímto druhem řízení a pozadu nezůstávají ani výrobci softwaru, kteří na tento
trend reagují uváděním stále dokonalejších nástrojů. Dnešní PPM aplikace disponují širokou funkcionalitou vycházející z všeobecně uznávaných standardů projektového řízení a poskytují tak svým
uživatelům dostatečnou podporu pro správu jejich
projektů. Přesto se stále můžeme setkat s řadou neúspěšných implementací a skutečný přínos z užívání PPM dokáže vyčíslit jen opravdu málokdo. Nabízí
se zde tedy otázka, zda jsou současné aplikace skutečně tak dobré, jak jejich výrobci proklamují a jestliže ano, proč jejich zavádění nepřináší očekávané
výsledky? Odpověď je jednoduchá. PPM není pouze software.
Podíváme-li se na problematiku portfolio managementu blíže, zjistíme, že se jedná o velmi komplexní oblast, do které je při správném využití zapojeno množství subjektů napříč celou organizací.
A s množstvím subjektů souvisí také celá řada faktorů, které mohou implementaci ovlivnit. V následujících odstavcích jsou uvedeny některé z nejdůležitějších faktorů, které je nutné vzít při implementaci
portfolio managementu v úvahu.
Skutečný rozsah projektu
Jednou z prvních chyb při posuzování realizace,
zda řízení portfolia zavádět, jsou mylné představy
o rozsahu takového projektu. Projekty implementace PPM jsou již ze své podstaty velmi obsáhlé
a konkrétní dopady na organizaci závisí především
na rozsahu, jakým je ve firmě využíváno projektového řízení. Ve společnostech, kde jsou formou
projektů realizovány kromě podpůrných také hlavní činnosti společnosti, se z implementace PPM stává celopodniková záležitost ovlivňující prakticky
veškeré činnosti a zdroje. V takových případech je
nutné postupovat s adekvátní obezřetností a věnovat projektu náležitou pozornost. Vysoká priorita, správné naplánování, zajištění dostatku zdrojů
nebo dostatečně zkušený projektový manažer jsou
jen příklady aspektů, na které by nemělo být zapomínáno. Zároveň je nutné vzít v úvahu ostatní probíhající akce a činnosti, aby nedošlo k neúměrnému
zatížení společnosti.
Podpora vedení
Pokud bychom sestavovali žebříček nejvýznamnějších faktorů rozhodujících o úspěchu či neúspěchu jakéhokoliv projektu, kvalitní podpora ze strany vrcholového vedení by zcela jistě obsadila jedno
z předních míst. Její význam se ještě zvyšuje v případě rozsáhlých a dlouhodobých projektů, u kterých
hrozí vznik pocitu marnosti a nedosažitelnosti sta-
novených cílů. Kromě tohoto jde při zavádění PPM
ještě o další, neméně důležitý aspekt. Řízení portfolia je primárně zaměřeno na vyšší úroveň řízení,
kam také směřují jeho hlavní přínosy. Svým charakterem ovšem zásadně ovlivňuje práci managerů
prakticky na všech úrovních a vyžaduje od nich intenzivní spolupráci často bez adekvátních přínosů.
Lehce se tak může stát, že zejména v řadách projektových managerů je implementace PPM vnímána
jako něco, co pouze přidělává práci a nepřináší žádné výhody. Následuje chladný a odměřený přístup,
který k celkové úspěšnosti projektu zcela jistě nepřidá. Právě v takových chvílích je na managementu firmy, aby převzal iniciativu a svým entusiasmem
podpořil realizaci projektu. Každý budoucí uživatel
by měl být seznámen nejen s důvody a cíli projektu, ale také se způsobem, jakým právě on přispívá
k realizaci celkových přínosů.
Zapojení klíčových uživatelů
Dalším, neméně důležitým aspektem při zavádění portfolio managementu je zapojení klíčových
uživatelů a správná distribuce pravomocí a odpovědností. Jak již bylo zmíněno výše, cílová oblast
směřování hlavních přínosů PPM spadá mezi vyšší management. Zde ovšem narážíme na problém
vysokého vytížení jednotlivých managerů, kteří vzhledem k množství svých povinností často ani
nejsou schopni věnovat projektu náležitou pozornost. Výsledkem bývá laxní přístup k projektu nebo
delegování odpovědnosti na nižší stupně řízení. Takové chování je však krajně nevhodné. Jsou to totiž pouze příslušní vedoucí pracovníci, kteří by měli
definovat základní požadavky a kvalifikovaně rozhodnout o jejich úspěšném dosažení. Účinnou metodou jak dosáhnout, aby zapojení klíčových uživatelů nezůstalo pouze na formální rovině, je navázat
spolupráci na projektu na systém motivací a odměňování. V řadě případů je to jediné možné řešení jak
dosáhnout, aby se budoucích uživatelé sami zajímali o projekt a osobně byli zainteresováni na jeho
hladkém průběhu.
Celková zralost organizace
Jsou projekty, které může realizovat prakticky kterákoli organizace, a pak jsou projekty, k jejichž realizaci je zapotřebí splnění řady vstupních předpokladů. Implementace PPM patří bezpochyby do druhé
skupiny. Řízení portfolia je úzce spojeno s projektovým řízením. Tvoří vlastně jeho logickou nadstavbu. Z pohledu úspěšnosti tak množství přínosů dosažených implementací portfolio managementu
přímo souvisí se stupněm vyzrálosti firmy v oblasti řízení projektů. Jinými slovy, k tomu, abychom
mohli efektivně řídit portfolio, potřebujeme dostatečně kvalitní základy v podobě všeobecně akceptovaných a používaných procesů projektového
řízení a v neposlední řadě také zkušené uživatele.
Tato podmínka, jakkoli se může zdát triviální, bývá
velmi často podceňována. Jedním z hlavních přínosů zavedení PPM je sjednocení postupů a zvýšení
míry standardizace napříč celou organizací. V případě nedostatečně vyzrálých procesů se však tato
výhoda může rychle změnit v nepříjemnou překážku a z implementace se stává pouze bezpředmětná
sbírka výjimek a změnových řízení.
Výběr aplikace
Úlohu výběru vhodné aplikace nelze samozřejmě
zcela opominout. Právě naopak, správným výběrem je možné implementaci PPM podstatným způsobem usnadnit a předejít řadě problémů. Ze zkušenosti se ukazuje, že spíše než množství funkcí je
při výběru dobré klást důraz na schopnost aplikace přizpůsobit se specifickým požadavkům a také
možnost napojení na ostatní používané systémy.
Typicky se jedná o možnosti integrace se službami Service Desku, HR systémy, ERP systémy nebo
lokálně používanými plánovači projektů. Kvalitní
software by měl být především schopen přizpůsobit se vnitřnímu fungování organizace a akceptovat
nastavení jejích procesů. Na druhou stranu je třeba
mít na paměti, že každá PPM aplikace částečně obsahuje i vlastní know-how, jak by proces řízení portfolia měl vypadat. Nerespektování těchto pravidel
a přílišnou kustomizací může dojít k narušení vnitřní filozofie aplikace, což se negativně projeví na výkonu a kvalitě poskytovaných služeb.
Účelem tohoto článku nebylo přinést vyčerpávající seznam kritických faktorů souvisejících s implementací Project Portfolio Managementu, nýbrž
poukázat na komplexitu a rozsáhlost změn, které
s projekty tohoto typu souvisí. Efektivně adoptovat systém PPM znamená závazek zodpovědného
a cíleného chování pro všechny podílející se osoby.
Každý jedinec, který se na implementaci podílí, by
měl vědět, jaká je jeho role, jaké jsou jeho povinnosti a úkoly. I tak je ale nasazování PPM cestou náročnou a často také bolestnou. Vyžaduje kooperaci prakticky všech oddělení a velmi silnou iniciativu
nejvyššího vedení. Jedině tak lze zaručit, že na konci této cesty bude zasloužená odměna v podobě
dosažení požadovaných výsledků.
Petr Šťastný
[email protected]
5
Změny v provádění technické podpory testovacích
produktů po přechodu od Mercury k HP
Po akvizici společnosti Mercury Interactive Corporation společností Hewlett-Packard došlo k zásadním změnám ve způsobu poskytování technické
podpory testovacích produktů.
Změny se projevily v postupném začleňování produktů bývalé společnosti Mercury Interactive
do standardů divize HP Software a od září 2007
již bylo uvolněno do používání přepracované uživatelské rozhraní webové služby pro poskytování
podpory software společnosti HP, které už obsahuje podporu produktů, získaných akvizicemi jiných
společností včetně produktů bývalé společnosti
Mercury Interactive.
Webová služba HP Support Service Online (HP SSO,
http://support.openview.hp.com) umožňuje tři
úrovně přístupu.
1. V první úrovni nabízí obsah přístupný bez nutnosti přihlásit se pod uživatelským účtem a zahrnuje návody k používání technické podpory, zprávy o proběhlých událostech, ale také o novinkách
v HP, různé obchodní informace a seznam kontaktů
na centra technické podpory HP.
účtu HP Passport platné identifikátory servisní podpory, vycházející z uzavřených smluv se společností HP. Jedná se o tzv. SAID (Support Agreement ID).
Po vložení SAID se plnohodnotně zpřístupní služba podpory software HP, kdy lze využívat znalostní
databázi HP, zadávat, vyhledávat a prohlížet požadavky na technickou podporu nebo zadávat požadavky na změnu vlastností a funkčnosti podporovaných softwarových produktů, tzv. Enhancement
requests.
S přechodem na nový webový portál technické
podpory HP zůstaly pro rok 2008 v HP k dořešení
akce jako převedení znalostní databáze, diskusního
fóra a řešených problémů technické podpory s původními identifikátory bývalé společnosti Mercury
Interactive.
Společnost KOMIX v nedávném období investovala
další prostředky do podpůrného software i do organizace technické podpory svých zákazníků. Díky
těmto změnám došlo ke zvýšení kvality poskytovaných služeb technické podpory softwarových produktů HP.
2. Ve druhé úrovni se zpřístupní už více informací
poté, co si zákazník založí na webu společnosti HP
osobní uživatelský účet, tzv. HP Passport. Tato úroveň přístupu umožňuje stahování zkušebních verzí software, stahování opravných balíčků (patches),
individuální nastavení emailových upozornění
po uvolnění nových verzí softwarových produktů. Obsahuje například také informace o termínech
ukončení podpory starších verzí software HP.
Pro komunikaci se zákazníky využívá KOMIX v současné době nový systém Service Desk, nakonfigurovaný pro provádění technické podpory, včetně
dodržování smluvních požadavků (SLA – Service
Level Agreement). Prostřednictvím Service Desku KOMIX mají zákazníci k dispozici trvalý přístup
(24 x 7) k informacím přes webové uživatelské rozhraní, které umožňuje jak zadávat nové požadavky technické podpory, tak i prohlížet postup řešení dříve zadaných požadavků.
3. Pro třetí, tj. nejvyšší úroveň přístupu k podpoře software HP, je nutné zadat do profilu osobního
V oblasti podpory HP software zajišťuje společnost
KOMIX pro své zákazníky první úroveň technické
PROČ PROVÁDĚT ZÁTĚŽOVÉ TESTY
Základy zátěžového testování aplikací
Cílem zátěžového testu je zjistit výkonnost aplikace v závislosti na stupni a druhu zatížení.
Co jsou zátěžové testy
Zátěžový test slouží k nalezení problémů a jejich
příčin projevujících se při větším zatížení aplikace. Například při větším počtu současně pracujících uživatelů může docházet k tomu, že je aplikace
pomalá, někdy dokonce bez odezvy, vrací chybová
hlášení, další uživatelé se do ní nemohou přihlásit
nebo dojde k jejímu zhroucení.
Takové chování aplikace přináší nejen ekonomické ztráty, ale rovněž demotivaci pracovníků a sníže-
6
ní důvěry u zákazníků, kteří musí čekat na dlouhé
odezvy systému.
Zátěžové testy ověřují výkonnost aplikace při jejím
požadovaném zatížení. Míra testovaného zatížení se volí tak, aby odpovídala podmínkám v provozu a cíli zátěžového testu. Nejběžnější praxí je simulovat zatížení při některé špičce (denní, týdenní či
roční). Lze také simulovat zatížení, kterému bude
aplikace vystavena v budoucnu, např. při plánovaném zvýšení počtu uživatelů této aplikace.
podpory. Výhodou tohoto typu podpory je komunikace v českém jazyce a naše zkušenosti s instalací HP software na různá softwarová prostředí a také
znalost konkrétních implementací podporovaného
software.
Ke standardu péče o zákazníky technické podpory KOMIXu patří zasílání informací o nových verzích
HP software a konzultace o vhodnosti jejich nasazení. Před uvolněním nových hlavních verzí software předáváme našim zákazníkům výsledky tzv.
„kalibrace“, tedy závěrečnou zprávu z interního testování software dle normy ISO 9001 (ověření vlastností software deklarovaných výrobcem), kde se
mj. zaměřujeme na testy českého národního jazykového prostředí.
V rámci poskytování technické podpory může KOMIX pro své zákazníky zajistit také aktualizace nových verzí software (instalační média HP update
software) a dodávky licencí.
Rovněž dokážeme řešit nestandardní požadavky
zákazníků nad rámec dojednané technické podpory, například vyžádané mimořádné práce nebo pracovní pohotovost v mimopracovní době či o víkendu. Poskytujeme také rozmanité rozšiřující služby
v souvislosti s podporovaným software, nejčastěji
se jedná o instalace a konzultace prováděné na pracovišti zákazníka, zejména při provádění upgrade
HP software na vyšší verzi či při migracích nebo upgrade databází.
Miloslav Richter, Štěpán Janča
[email protected], [email protected]
Co ovlivňuje výkon aplikace
Aplikace je obvykle provozována v prostředí se složitou architekturou, které má výrazný vliv na výkon aplikace. Koncový uživatel pak chápe jako výkon aplikace délku uživatelských odezev aplikace
na jeho požadavky.
Zde jsou nejobvyklejší příčiny problémů s výkonem:
1.Výkon hardware serverů. Ten můžeme rozčlenit
na problémy s výkonem procesorů, správou a velikostí paměti, průchodností diskového systému
a síťových rozhraní.
2.Přetížení části sítě, která má nedostačující šíři
pásma.
3.Nastavení parametrů operačního systému (Linux, HP Unix, IBM AIX …).
4.Nastavení parametrů aplikačních a webových
serverů včetně Javy.
5.Nastavení databáze a databázového serveru (využívání cache, nastavení indexů …).
6.Problémy v aplikaci (neoptimalizované dotazy
do databáze, pomalá místa kódu, chyby …).
7. Pomalé odezvy spolupracujících systémů, se kterými si testovaný systém vyměňuje nebo sdílí
data.
V jakém případě je třeba udělat
zátěžový test
Příprava a provedení zátěžového testu trvá několik
týdnů a není levnou záležitostí, a proto je třeba
se již ve fázi plánování projektu zamyslet nad tím,
zda bude potřeba aplikaci výkonnostně testovat.
Zde uvádíme několik obecných důvodů proč je
dobré, aby aplikace byla vyladěna i po výkonnostní
stránce:
• Fungující, ale pomalá aplikace snižuje produktivitu práce a také demotivuje zaměstnance.
• Může dojít ke ztrátě zákazníků. Například pokud
se zákazník nemůže přihlásit do internetového
obchodu nic mu nebrání nakoupit u jiného dodavatele.
• Pokud dojde díky přetížení k úplnému výpadku
aplikace, může, například ve finančním sektoru,
hrozit i požadavek na úhradu škody od zákazníků, kteří ji nemohou používat.
• Případný kolaps internetového bankovnictví má
vždy značnou publicitu v médiích a může vést
ke ztrátě renomé společnosti o finančních ztrátách nemluvě. Obdobné pravidlo platí i pro státní sektor. I zde jsou často medializovány výpadky
celostátních informačních systémů.
Kromě obecných důvodů, které jistě stojí za zvážení,
jsou standardní situace, v nichž je doporučeno
udělat zátěžový test na ověření výkonnosti
aplikace:
• Zadavatel přebírá novou aplikaci od dodavatele.
Zátěžový test by měl být součástí akceptačního
řízení.
• Při nasazení nové verze aplikace.
• Při přesunu aplikace na jiný hardware.
• Při přechodu na jinou verzi databáze (např. přechod z Oracle 9 na 10).
U kritických aplikací by mělo být samozřejmostí,
aby byl zátěžový test zařazen do procesu testování
již v rámci vývoje u jejího dodavatele, jako součást
jeho vnitřních testovacích procesů.
aplikací, specialisté na aplikační, databázové a webové servery, vývojáři aplikace …) určit případné
„úzké místo“. Pro ladění výkonu samozřejmě potřebujeme monitorovat servery, případně i další
zdroje, na kterých je aplikace provozována. Monitoring může být na různé úrovni, což je dáno možnostmi použitého software pro zátěžové testování.
Z naměřených výsledků pak můžeme vyvodit, který server (webový, aplikační, databázový) je přetížen. Pokud použijeme pokročilé diagnostiky, které
jsou součástí některého komerčního software pro
zátěžové testy, můžeme dobu odezvy konkrétního
požadavku rozložit na doby provádění požadavku
v jednotlivých částech zdrojového kódu voláních
aplikace a tím identifikovat, kde je příčina problému. Po odstranění příčiny ověříme dalším během
zátěžového testu, zda navržené řešení skutečně přispělo ke zvýšení výkonu.
Řešením problému nemusí být vždy
jen navýšení výkonu hardware
Stejně jako u jiných chyb i pro ladění výkonu platí, že nejobtížnější je najít příčinu chyby. V odstavci „Co ovlivňuje výkon aplikace“ je uvedeno 7 vrstev, na kterých se může chyba vyskytnout. Navíc
jde často o kumulaci příčin vyskytujících se na různých vrstvách. Posílením hardware můžete zvýšit
jeho výkon zhruba o desítky procent, ale optimalizací na ostatních vrstvách může dojít k mnohonásobně vyššímu výkonu bez investice do hardware.
Je dobré si rovněž uvědomit, že zvýšení výkonnosti aplikace, třeba i nad požadované limity, přináší
ve většině případů snížení zátěže některého serveru nebo serverů. To přináší buď rezervu do budoucna, nebo prostor pro další aplikace pokud využívají
společné servery s laděnou aplikací.
Základní typy zátěžových testů
• Load Test – obvyklý typ testu, kdy jsou měřeny
odezvy systému při předem definované zátěži.
• Capacity Test – při tomto typu testu je hledána
největší zátěž, při které je aplikace ještě použitelná. Jinými slovy zátěž postupně zvyšujeme až
do doby, kdy aplikace přestane splňovat požadovaná výkonnostní kritéria.
• Stress Test – zjišťujeme jak se bude aplikace
chovat v případě přetížení díky nadměrné zátěži nebo při omezení některého zdroje, například
při výpadku jednoho ze dvou webových serverů
či restartování databáze za běhu testu.
Manuální nebo automatizovaný
zátěžový test?
Potřebné zatížení aplikace je možno zajistit přímo
lidskými zdroji (manuální test) nebo specializovaným software spouštěným na počítačích k tomuto
účelu vyhrazených (automatizovaný test).
Manuální zátěžové testy jsou vhodné pouze pro
malé systémy, orientačně cca do 20 uživatelů nebo
pro systémy, kde by byla automatizace příliš technicky náročná. Největší výhodou této metody je relativně rychlá realizace zátěžového testu bez nutnosti
využití specializovaného software a vytváření zátěžových skriptů. Tato metoda má ale řadu nevýhod:
• Obtížné řízení zátěže.
• Při opakování testu nelze vzhledem k lidskému
faktoru realizovat přesně stejnou zátěž.
• Složité sledování odezev systému a sběr naměřených hodnot.
• Vyšší chybovost z hlediska lidského faktoru.
Příprava automatizovaných zátěžových testů je časově náročnější. Zpravidla zahrnuje analýzu, přípra-
Co vám zátěžový test přinese
Zátěžový test slouží k ověření výkonnosti a fungování aplikace při definované zátěži a může sloužit
také jako podklad pro zvyšování výkonu aplikace
(ladění). Samotný běh zátěžového testu samozřejmě výkon aplikace nijak nezvýší, ale jeho výstupy
pomohou odborníkům (správci prostředí, správci
7
vu (přípravu dat, tvorbu a odladění skriptů a přípravu prostředí pro ZT), realizaci definovaného počtu
běhů a jejich vyhodnocení. Výstupy automatizovaných testů jsou ve srovnání s manuálními daleko přesnější. Automatizovaný test je možno opakovat ve stejném rozsahu zátěže jako jeho provedení
v předchozím běhu.
Prostředí pro zátěžový test
Vlastní příprava automatizovaného zátěžového
testu se obvykle uskutečňuje na některém z testovacích prostředí. Ideálním stavem je, pokud lze
uskutečnit běhy zátěžových testů na testovacím
prostředí, které je přesnou, nebo alespoň velice
blízkou, kopií infrastruktury produkčního prostředí, včetně objemů dat v databázi. Vybudovat takové prostředí je však velmi nákladné, proto se tato
varianta v reálu nevyskytuje často.
Další variantou je realizovat zátěžový test přímo
na produkčním prostředí. Tady je potřeba předem
velmi důkladně zvážit a eliminovat velké množství
rizik, která tato varianta přináší.
Nejčastější variantou je realizace běhů zátěžového
testu na testovacím prostředí zákazníka, které má
odlišný a často slabší hardware než produkční prostředí. Tím vzniká problém jak určit, jaký bude výkon aplikace v produkčním prostředí. Lze to řešit
několika způsoby, jedním z nich je běh v produkčním prostředí, poté co se provedly běhy na prostředí testovacím a aplikace projevila stabilitu pod
zátěží. Tento běh zátěžového testu většinou neběží s maximálním (kritickým) počtem uživatelů, ale
s počtem, který se na daném prostředí může běžně
objevit. Tímto během získáme reálné doby odezev
na cílovém prostředí.
Jinou variantou je kvalifikovaný odhad. Mimo málo
přesných odhadů lze použít i některého specializovaného software (například HyPerformix Performance Optimizer). Jako vstupy tomuto software
zadáme výsledky zátěžového testu a údaje o infrastruktuře testovacího a produkčního prostředí
(všech serverů a dalších prvků včetně jejich výkonnostních parametrů). Tento software pak vyhodnotí jak by test s určitou pravděpodobností dopadl
na produkčním prostředí. Program lze samozřejmě
použít i v tom případě, kdy plánujete posílit nebo
inovovat produkční prostředí a rádi byste znali dopad změny hardware na výkon aplikace.
Na co se soustředit při plánování
zátěžového testu
V první řadě je potřeba stanovit, co bude cílem
zátěžového testu a jestli jsme schopni realizovat
jej vlastními kapacitami nebo bude výhodnější si
na tuto práci najmout profesionální firmu.
V harmonogramu prací je nutno počítat s dostatečnou dobou pro jednotlivé etapy zátěžového testu
(analýza, příprava skriptů a testovacích dat, provedení běhů a vyhodnocení).
Pokud se rozhodnete pro profesionální firmu,
doporučujeme, aby jste si připravili pro jednání
tyto podklady:
• Jakým způsobem je aplikace zatěžována (například pracovníky přistupujícími přes webového klienta, přes tlustého klienta SAP, jiným systémem,
se kterým komunikuje pomocí web services).
• Jaká je cílová požadovaná velikost zátěže.
• Co od zátěžového testu očekáváte, jaké by měly
být jeho cíle a přínosy, proč ho plánujete (např.
nová aplikace, nová verze aplikace …).
• Základní technologické údaje o aplikaci, prostředích a protokolech (například aplikace je v SAPu
či Siebelu včetně jejich verze).
• Co se bude v průběhu testu vyhodnocovat? Typicky jde o doby odezev na jednotlivé uživatelské akce, doby trvání u dávkového zpracování
dat, vytížení hardware (procesoru, paměti, disků), parametry databáze, aplikačních a webových
serverů, vytížení síťových prvků. V tomto případě
je dobré uvést alespoň zhruba počet monitorovaných serverů a jejich charakteristiky.
• Tabulku požadovaných výkonnostních limitů pro
sledované odezvy aplikace
Co vám můžeme nabídnout
KOMIX má rozsáhlé a dlouholeté zkušenosti v oblasti provádění zátěžových testů a technické podpory software HP LoadRunner. Díky našim širokým
znalostem můžeme nabídnout provedení zátěžových testů „na klíč“ jak komerčním, tak freeware
software.
Dále nabízíme školení, a to nejen pro pracovníky
provádějící zátěžové testy (jak provádět zátěžové
testování, školení práce se software pro zátěžové
testy), ale také obecnější školení pro vedoucí pracovníky.
Libor Kotoun
[email protected]
Role v procesu manuálního testování
Testování už dnes (naštěstí) většinou neprobíhá tak, že si „někdo“ na pár minut sedne k aplikaci,
„tak nějak“ prokliká obrazovky a myslí si, že zázračně na první pokus odhalí všechny závady
a nedostatky, které se v programu skrývají. Ověřování kvality tak přestává být i v našich krajích
vnímáno jako „práce pro juniory“ a „přestupní stanice k lepší pozici“ a stále více lidí si uvědomuje,
že jde o exaktní disciplínu, řídící se jasnými pravidly a vyžadující souhru několika odborníků.
Přenesme se tedy do projektové reality a pojďme se
podívat, koho z testovacího týmu můžeme potkat
na SW projektu, jehož součástí je manuální funkční
testování, a jak takové testování vlastně vypadá.
Standardní řízený proces testování by měl obsahovat 4 fáze - plánování, přípravu, provedení a vyhodnocení.
Úkolem plánovací fáze je mimo jiné zjistit, co je
cílem testování, zhruba určit metody, kterými se
k těmto cílům dostaneme a nastavit základní rámec
pravidel, podle kterých se bude dále postupovat.
Ve fázi přípravy nastává ten správný čas na prostudování dostupných podkladů, upřesnění nejasností, zvolení vhodného způsobu testování a zejména čas pro přípravu podkladů, podle kterých
se testování provede. Vývoj aplikací nejčastěji probíhá v několika etapách, je tedy více než vhodné,
8
aby testeři tento způsob respektovali. Proto je nutné mít připravené odpovídající typy testů pro každou fázi projektu – při akceptačním testování je již
pozdě na zjišťování, zda při zadání textu do číselné
položky aplikace nezhavaruje.
Od první spustitelné verze aplikace může (a má) začít provádění testů, tedy určení vhodné sady testů, odpovídající aktuální fázi vývoje, jejich spuštění a ohlášení nalezených chyb. Po ukončení testů
následuje jejich vyhodnocení – tedy rekapitulace
toho, co se udělalo, ocenění dobré práce a získání
námětů na to, co příště udělat lépe. Vhodným termínem pro tuto činnost jsou milníky projektu.
Práce v jednotlivých fázích testování se od sebe významně liší, a je tedy vhodné, když si je mezi sebou
rozdělí sehraná skupina odborníků. Nejčastěji se
tak v týmu sejde vedoucí testování, analytik testování a jeden nebo více testerů.
Vedoucí testování (manager testování,
koordinátor testování…)
Jeho hlavním úkolem je plánovat, vést a řídit testování. V úvodních fázích projektu domlouvá a specifikuje záměry a cíle testování, rozhoduje, které typy
testů a zhruba v jakém rozsahu je třeba provést.
V některých případech také trpělivě vysvětluje, že
opravdu není možné, aby testeři poprvé nastoupili
na projekt tři dny před finálním releasem.
Během projektu organizuje práci testerů, pomáhá
jim zajišťovat podmínky k práci a kromě standardních manažerských činností také dbá na to, aby
jeho tým dodržoval přijatou metodiku. V neposlední řadě komunikuje s vedením projektu, řeší problémy a urovnává menší krize, kterých je na projektu
vždy více, než by si přál.
Na projektu ho buď potkáte málokdy (pokud jste
vývojář nebo analytik), nebo naopak téměř na každé schůzce (pokud jste projektový manažer).
Co nerad slyší:
Testovací prostředí fungovat nebude, ale testy se
udělat musí. Nějak to otestujte, hlavně ať tam nejsou chyby, ať to můžeme nechat zakceptovat.
Není čas něco analyzovat, musíme hlavně začít
rychle testovat. Pusť si aplikaci, zjisti si co dělá, a pak
podle toho napiš testy.
Tester
Analytik testování
Jeho doménou je testovací dokumentace – tedy
příprava a údržba podkladů pro testování. Poznáte
ho snadno už podle prvních otázek, které většinou
zní: „Kde najdu požadavky, kde máte uloženou analýzu a jaký je telefon na analytika vývoje?“
Pak se stáhne do tichého kouta, odkud se několik dní ozývá zuřivé šustění zvýrazňovače a nespokojené „Odkdy má happy-day scénář dva konce?“,
„Tady je potřeba dopsat alternativní průběh.“, případně zoufalé „Kdo odsouhlasil požadavek ‘Systém
je dostatečné výkonný?!‘ “. Po následujícím krátkém
intermezzu s analytikem vývoje se vrací s upravenou analýzou a hrubou kostru naplánovaných testů začne obalovat testovacími případy a testovacími daty. Jednotlivé testy se začnou skládat do sad
a v okamžiku, kdy si spokojeně vydechne nad hotovou prací, je zpravidla čas na zapracování první
dávky změn a úprav. Se začátkem testování se věnuje hlavně určování, které testy budou v aktuálním běhu spuštěny a část času věnuje zapracovávání změn a úpravám testovacích případů.
Na projektu se nejvíce potkává s analytikem vývoje a s odborníky zákazníka, kterých se ptá a ptá až
do oboustranného vyčerpání.
Co nerad slyší:
Analýza ani požadavky nejsou a nebudou, funkčnost je triviální a každý ví, co to má dělat.
Ve své praxi jsem se setkal se dvěma krajními pohledy na roli testera. Podle jednoho z nich to má
být někdo, kdo si ráno bez jakékoli podpory sedne
k neznámé aplikaci, mrknutím levého oka ji nainstaluje, nakonfiguruje a rozchodí, mrknutím pravého oka pak vyčaruje tři megabajty testovacích dat,
analýzou se nezdržuje, do oběda celý systém dokonale otestuje a bude hlavou ručit za to, že v aplikaci
žádné chyby nejsou a nikdy nebudou.
Podle druhého pohledu je tester zbytečná přítěž,
případně nezkušený junior, kterého je nejlépe ignorovat a co nejdříve nahradit nějakým pěkným
systémem pro automatizované testování.
(Existuje ještě třetí pohled: “Hlavně se nám v té naší
dokonalé aplikaci nerejpej, ještě bys tam něco našel a my to museli opravovat“. Tam pro testera existuje jen jedna cesta – zmizet co nejrychleji do jiné
firmy.) Jak už to u extrémních příkladů bývá, pravda je někde uprostřed cesty. U dokonale připravených testů, tedy tam, kde byl dostatek času pro
analýzu a přípravu podrobných testovacích scénářů a kde jsou scénáře ověřeny mnoha běhy, může
být testování vhodnou prací pro studenta, juniora
nebo pro automat (koho by také uspokojovalo klikat v jedné aplikaci pořád dokola). Čím méně dokonalá byla příprava a analýza, čím více se aplikace mění pod rukama a čím méně je času na vlastní
testování, tím fundovanější musí být tester, tím více
musí spoléhat na zkušenosti, intuici, znalost oboru
a na různé fortele a triky, které mu umožní i takový
projekt zdárně dokončit.
Úkolem testera je tedy otestovat aplikaci – ale co
to vlastně znamená? Stručně řečeno, podle podkladů provádět s aplikací předepsané operace, porovnat je s předepsaným očekávaným chováním a zaznamenat neshody, na které narazí. Kromě toho je
žádoucí, aby netestoval pouze to, co je předepsáno
– v rámci „free testů“ mají testeři spoustu prostoru pro invenci při vymýšlení, jak aplikaci co nejlépe shodit. Dobře namíchané, několikrát provedené
testy, složené jak z rutinního procházení, tak z volného hraní s aplikací, dokáží odhalit velké množství
chyb, v rozumném čase a s malým rizikem, že tým
otupí z únavy. Samostatným uměním je správné reportování chyb – tak, aby bylo možné ověřit opravu
chyby, kterou nalezl před půl rokem kolega, který
již ve firmě nepracuje, v aplikaci o pět verzí zpátky
a poté, co se dvakrát přemazala databáze.
Nejčastěji tester komunikuje s vývojáři a s analytikem testování.
Co nerad slyší:
To není chyba, to je vlastnost.
To jsme udělali jinak.
Na mém počítači to funguje, přeinstaluj si Windows.
Testování přirozeně neprobíhá ve vzduchoprázdnu, testovací tým spolupracuje a komunikuje s řadou dalších lidí. Nejdůležitější pro testovací tým
jsou projektový manager, analytik vývoje a programátor, ale neobejdou se ani bez součinnosti odborníků ze strany zákazníka – neocenitelná je zejména pomoc specialistů na data a na vlastní business
zákazníka. A nedovedu si
představit efektivní testování bez pomoci specialistů
na databáze, testovací prostředí a vývojářů různých
speciálních nástrojů – těm
všem patří poděkování nás
testerů.
Bohužel nikdo - ani mistři
badatelských testů, ani nejdražší software pro testy, ani
nedokonalejší analýzy - nezaručí, že nějaká chyba neproklouzne až k uživatelům.
Testovací tým se snaží dobrým naplánováním, poctivou přípravou a pečlivým
provedením testů o to, aby
takových chyb bylo co nejméně.
Pavel Hönigschmied
[email protected]
9
Testování systému CDBP v KOMIXu
Od konce roku 2005 pracuje KOMIX na projektu vývoje systému cestovních pasů s biometrickými prvky (CDBP), na kterém se podílí celá řada dalších subjektů. Projekt je rozdělen do několika etap, přičemž
předmětem minulé etapy (tj. období roku 2006) byl
vývoj centrální aplikace a k ní skupiny (čítající cca
12) klientských aplikací: klientská aplikace pro obce,
klientská aplikace pro cizineckou a pohraniční policii atd.
V současné době, probíhá další etapa projektu,
ve které je předmětem vývoje rozšíření stávajících
aplikací o zpracování otisků prstů. Dále dochází
ke zvýšení zabezpečení údajů v čipu elektronického pasu prostřednictvím složité struktury certifikátů a také jsou realizovány další drobné změny a rozšíření systému.
Již v době, kdy se tvořil plán celého projektu, byla
navržena období, během kterých se bude testování
realizovat. Je potřeba si uvědomit, že proces testování se skládá, kromě plánování, z přípravy testování (což bývá náročná a dlouhodobá činnost) a pak
ze samotného provedení testování.
Po naplánování byl sestaven testovací tým, který
zahrnuje následující role: vedoucího testování, analytika testování a testery.
Vedoucí testování zastřešuje celý tým, tj. komunikuje s jinými vedoucími týmů a managementem
projektu, zajišťuje rozdělení prací v týmu, koordinuje činnosti v týmu, kontroluje výsledky práce členů týmu a poskytuje jim podporu, sestavuje Plán
testování, odhaduje pracnost činností, sestavuje
Harmonogram testování, sestavuje návrh testování
(součást dokumentu Návrh programového vybavení), vytváří společně s analytikem testovací scénáře
a testovací případy (tj. pro všechny klientské aplikace projektu CDBP).
Analytik testování vychází ze schválených analytických podkladů k aplikaci, na jejichž základě navrhuje rozsah pokrytí aplikace testy, tvoří testovací případy, testovací scénáře a specifikaci testovacích dat
(potřebných pro provedení testů).
Tester provádí samotné testování na základě testovacích případů a testovacích scénářů s použitím
testovacích dat.
V reálu většinou dochází ke kumulaci rolí. Na tomto
projektu je vedoucí testování zároveň i analytikem
a v případě potřeby také testerem. Stejně tak analytik testování bývá současně testerem.
Úkolem týmu je seznámit se s projektovou dokumentací, tak aby byl schopen vytvořit testy ještě
před tím, než jsou k dispozici testovatelné klientské aplikace. Projektová dokumentace na CDBP zahrnuje Analýzu programového vybavení (dále jen
APV), kde jsou podrobně rozpracované požadavky
na systém od zákazníka, dále obsahuje popisy rozhraní, slovní popisy procesů, UML diagramy procesů, infrastruktury apod. Druhým neméně důležitým
10
dokumentem, který vzniká na základě Analýzy je
Návrh programového vybavení (dále jen NPV). Součástí NPV je také kapitola o funkčním a zátěžovém
testování, kde je rozepsán požadovaný rozsah testování pro tuto etapu vývoje. Tyto dva dokumenty
jsou důležitým podkladem pro návrh a tvorbu testovací dokumentace (tj. Plán testů, Testovací případy a scénáře, specifikace testovacích dat).
Po seznámení týmu s projektovou dokumentací aktualizoval vedoucí testování dokument Plán
testování, který vznikl již v minulé etapě a obsahuje popis konkrétního provedení jednotlivých stádií
testování, požadavky na součinnost ze strany zákazníka, kritéria zahájení a ukončení testování, specifikace testovacích dat, definice rolí, definice tříd
chyb atd.
Po aktualizaci Plánu testů přichází fáze přípravy testovacích případů a testovacích scénářů, a to na základě informací z dokumentů APV a NPV.
Pro zajímavost: na projektu CDBP bylo za obě etapy vytvořeno celkem 130 testovacích scénářů, které
mají dohromady cca 520 stránek A4 a obsahují podrobné testovací případy.
Testovací dokumentace je finalizována do začátku
systémového testování.
Projekt CDBP prochází následujícími stádii testování:
• Interní
• Systémové
• Integrační
• Nezávislé
• Akceptační
• Pilotní provoz
Interní testování na projektu CDBP je stádium projektu, kdy dochází k tvorbě veškeré testovací dokumentace (jak jsem popsal již výše) a prvotnímu
otestování vyvíjeného systému na testovacím prostředí v KOMIXu. Výsledkem interního testování je
„funkční“ verze centrálního systému a klientských
aplikací, které se následně nahrají na prostředí zákazníka, v tomto případě na prostředí vytvořeném
na Ministerstvu vnitra.
Vývoj aplikací a interní testování projektu CDBP je
rozděleno do iterací, které mají 14 denní opakování. Jeden týden testovací tým vždy připravuje testy
a druhý týden tyto testy provádí. Stejně tak vývojový tým jeden týden vyvíjí a druhý týden opravuje chyby. Plánované práce vývoje jsou evidovány
v dokumentu Evidence iterací, podle kterého mají
testeři dokonalý přehled o tom, co bude v následujících několika týdnech naprogramováno a postupně uvolněno pro testování. Posledním zdrojem informací pro testery je firemní aplikace ProjectX, kde
každému záznamu z Evidence iterací odpovídá jeden úkol přiřazený konkrétnímu řešiteli. V úkolu je
popsán zdroj, ze kterého programátoři vycházejí, tj.
Analýza, Návrh, ZP (změnové požadavky). Dále zde
bývá stručný popis řešení a také návrh na otestování. Na základě těchto informací vedoucí testování připraví postup provedení testů, který většinou
vychází z testovacích případů a testovacích scénářů. Tento návrh testování pak zaeviduje do ProjectX ve své složce Testování jako úkoly a přiřadí
je konkrétnímu řešiteli, tj. členu testovacího týmu
- testerovi. Aplikace zašle úkol e-mailem odpovědné osobě, která pak v testovacím týdnu iterace úkol
provede. Musím podotknout, že tento způsob vývoje je velmi přehledný a funkční.
Po dokončení interního testování a oprav je uvolněna k testování první verze systému na testovací prostředí zákazníka, tedy k systémovému testování.
Velmi často jsou systémové a integrační testy prováděny víceméně současně, protože bez napojení
na ostatní vyvíjené komponenty celého systému
se nedá vyvíjený systém dostatečně otestovat. Cílem systémového a integračního testování je propojit produkt vyvíjený KOMIXem s ostatními částmi systému, které vyvíjejí další subjekty účastnící
se projektu. Poté, co je propojen centrální systém
klientské aplikace s testovacími evidencemi obyvatel a cestovních dokladů a dalšími okolními systémy
(na prostředí zákazníka), probíhá testování zhruba
stejným způsobem jako v rámci interních testů. Testeři procházejí klientské aplikace podle testovacích
případů a testovacích scénářů, jediným rozdílem
bývají testovací data, která musí do testovacích evidencí připravit pracovníci Ministerstva vnitra.
Na konci systémových a integračních testů se většinou provádí zátěžový test, který je možné provést až tehdy, kdy je aplikace „plně“ funkční a je z ní
odstraněna většina chyb. Cílem zátěžového testu
na tomto projektu je otestování výkonnosti centrálního systému, tedy zda je systém schopen při zasílání velkého množství požadavků v určitém časovém intervalu (např. jedné hodiny) tyto požadavky
zpracovat, vyřídit (např. podepsat příslušnými certifikáty) a poslat zpět. Zátěžový test celého systému
byl proveden už v minulé etapě, v této etapě dojde
pouze k otestování jedné nové komponenty centrálního systému, která je součástí nově doprogramovaných funkcí.
Po provedení interního, systémového a integračního testování provede jiný subjekt účastnící se projektu tzv. nezávislé testování našeho produktu
resp. celého systému. V minulé etapě si tato firma
vytvořila vlastní testovací případy a scénáře na základě stejné dokumentace, kterou měl k dispozici testovací tým KOMIXu. Stejný režim je plánován
i pro současnou etapu projektu, kdy tato firma dostane navíc k dispozici testovací dokumentaci KOMIXu. Proces nezávislého testování probíhá podobně jako interní a systémové testování prováděné
KOMIXem. Testeři firmy provádějící nezávislé testování projdou všechny klientské aplikace podle testovacích případů a testovacích scénářů, zapíšou chyby (pokud jsou nějaké nalezeny), tyto chyby
jsou opraveny, dojde k uvolnění nové verze a k retestu atd.
Pokud je nezávislé testování celého systému CDBP
úspěšné a dojde ze strany firmy provádějící nezávislé testy k potvrzení, že KOMIX i ostatní subjekty
účastnící se projektu CDBP vytvořily dílo odpovídající smluvnímu zadání, je tento systém předán k akceptačnímu testování.
Akceptační testování většinou probíhá tak, že se
předvedou zákazníkovi všechny funkce odpovídající jeho zadání (požadavkům). Testování probíhá na základě testovacích případů a scénářů, podle
kterých byly prováděny testy v rámci předchozích
stádií testování. Tato testovací dokumentace je však
zredukována na ty nejdůležitější funkčnosti (které
zastřešují všechny ostatní). Důvodem této redukce je fakt, že testovací dokumentace i celý systém
CDBP je velmi rozsáhlý a složitý a jeho komplexní
funkcionalita byla ověřena několikrát v předcházejících stádiích a v rámci akceptačních testů není většinou možné realizovat testy v úplném rozsahu. Zákazníkovi se proto předvedou základní uživatelské
funkce systému (odpovídající jeho požadavkům)
a podle kritérií stanovených a odsouhlasených
s dostatečným předstihem se pak akceptační testy
vyhodnotí. Zákazník po skončení akceptačních testů podepíše Akceptační protokol s vyjádřením, že
systém byl dodán tak, jak bylo smluveno a všichni
účastníci projektu dostáli svým závazkům.
Jedna z nejdůležitějších a nejsledovanějších fází
projektu je tzv. Pilotní provoz. Pilotní provoz probíhá následujícím způsobem: veškerý systém, testovaný na „testovacím“ prostředí, se převede
do tzv. ostrého prostředí. Celý systém se tak propojí se skutečnými evidencemi a skutečnou produkční
databází. V rámci tohoto pilotního provozu jsou už
vyráběny skutečné pasové knížky s reálnými daty.
V rámci pilotního provozu mohou být ještě nalezeny a opravovány chyby vycházející z reálného napojení na spolupracující systémy. Neshody z pilotního provozu jsou hlášeny na tzv. „hotline“, kde jsou
tříděny a řešeny.
Po úspěšném ukončení pilotního provozu, který
může trvat řádově několik týdnů, bude systém uveden do běžného provozu. Plánované nasazení inovovaného systému CDBP bude od dubna 2009.
Michal Černický
[email protected]
Převod systémů TARIC a NIT z prostředí UNIX
do prostředí Windows
Možná, že jste se již někdy setkali s úkolem převést
systém provozovaný u zákazníka do zcela nového
řešení, a to se zachováním funkčnosti, na kterou
jsou uživatelé zvyklí. Pokud jste i vy už něco takového řešili, určitě mi dáte za pravdu, že ne všechny
věci běží tak, jak by měly a v průběhu prací se můžete setkat s menšími nebo většími problémy. Ani
převod systémů TARIC (systém integrovaného tarifu Evropské unie) a NIT (národní integrovaný tarif) z prostředí UNIX do prostředí Windows nebyl
výjimkou. V následujících řádcích popíšu některé
z postupů, které jsme implementovali, budu mluvit
o problémech a jejich řešeních, které tento převod
provázely. I když se tento článek nesoustředí na detailní popis systémů TARIC a NIT, je nutno zmínit pár
základních údajů.
Systém TARIC slouží ke sledování statistiky zahraničního obchodu Společenství a obchodu mezi
členskými státy Evropské unie. Tento systém je založen na kombinované nomenklatuře. Systém NIT
doplňuje TARIC o netarifní opatření, sazby daně
z přidané hodnoty a spotřební daně. Tyto systémy
byly doposud provozovány na operačním systému
UNIX a pro uchovávaní dat byl zvolen databázový
server Informix. Část řešení, importující data přicházející z Evropské unie ve výměnném formátu EDIFACT, byla napsána jako autonomní úloha přistupující k databázi pomocí ANSI C a ESQL/C. Pro přístup
uživatelů k datům byly vytvořeny webové aplikace
provozované na webovém serveru Apache za použití modulu FastCGI. Tolik shrnutí technologie, ze
které se převádělo. Dále již druhá strana mince –
technologie, do které se převod uskutečnil. Microsoft, takto by se dalo jedním slovem shrnout cílové
prostředí. Buďme však konkrétnější. Celkové řešení se skládá z aplikačního, databázového a webového serveru. Všechny servery běží na operačním systému MS Windows Server 2003. Logické rozdělení
tohoto systému je, že autonomní úlohy a část komunikující s Bruselskou bránou jsou provozovány
na aplikačním serveru. Databázový server, v našem
případě MS SQL Server 2005, pokrývá migrované
databáze. Integrace webových aplikací, určených
pro práci uživatelů, se připravovala do portálového
řešení provozovaném na Windows SharePoint Services 2.0. Z použitých technologií se dá vyčíst, že
jsme pro programování zvolili opět Microsoft, a to
v podání Microsoft .NET Framework 2.0, ASP .NET
2.0 a C++.
Z obrázku 1 si můžete udělat představu o celkovém
řešení.
Dějství první – migrace databáze
Výhoda této migrace je, že známe stávající řešení,
a tudíž nás nic nemůže překvapit, říkáme si. Nikdo
však není prorokem a na tato slova si ještě v průběhu prací několikrát vzpomeneme. Ty začátky jsou
asi všude stejné, je potřeba připravit vývojové prostředí, nastavit pravidla, přístupy atd. Již po prvních
jednáních se zákazníkem je však jasné, že ke štěstí
nám nepomůže jenom naše interní vývojové prostředí, ale pro integraci je zapotřebí ještě prostředí,
a to přímo u zákazníka. Ještě, že existuje virtualizace, vzpomenu si, když poměrně brzy dostávám
informaci o tom, že je již možné tyto prostředky na straně zákazníka využít. Protože mezitím
11
dat, která nebyla ještě
v té době kompletní.
Dějství třetí – komunikace s infrastrukturou Bruselu
Brusel zasílá zprávy typu
EDIFACT všem členským
státům pomocí infraObrázek 1: Obecná architektura celkového řešení
struktury určené pro
tento
účel.
Pro
podporu
komunikace
s touto infranezahálíme, je připravován převod databáze z IBM
strukturou distribuuje speciální SDK, a to jako C++
Informix řady 9.X do MS SQL Server 2005. Instaluknihovny. Chvíli jsme váhali, zda pro vytvoření projeme IBM Informix Client SDK 2.90.TC1 a připravugramového vybavení stahující data z této brány nejeme převod databáze. Volba na tuto verzi padla
použít Microsoft .NET Framework, ale v tomto příz důvodu stability v současně provozovaných řepadě převážily výhody nativní integrace s C++.
šeních. (Jak jsme se v tomto případě mýlili, ukáže
Zajímavostí tohoto SDK je, že může spolupracovat
až pozdější nepříjemné zjištění). Nastavujeme pros bránou dvěmi následujícími způsoby:
středí klienta pro podporu UTF-8, avšak již při prva) komunikaci zahajuje infrastruktura,
ních testech zjišťujeme, že nám zcela zjevně něco
b) komunikaci zahajuje klient
chybí. Na data se dostaneme, ale jejich zobrazení není správné. Chybí nám Global Language Supad a/ celková konfigurace je nastavena v tzv. módu
port, vzpomeneme si, a po instalaci této podpory je
“OnDemand“.
již vše v pořádku, data se zobrazují tak, jak by měly.
Toto se jeví jako efektivní řešení, ve kterém nedoNásledně zálohujeme prostředí IBM Informix Clienchází ke zbytečné zátěži této infrastruktury. Abych
ta a můžeme začít připravovat balíčky pro přenos
objasnil tento princip, musím říci, že v tomto módu
dat na SQL Server 2005.
infrastruktura samotná aktivně oslovuje na definovaném TCP/IP portu poslouchající kanál na straně
Dějství druhé – příprava autonomních
klienta, a po navázaní komunikace probíhá spojeúkolů
ní již pomocí tohoto kanálu. Nezbytným předpoProgramové vybavení na straně aplikačního servekladem je, že na straně klienta je programové
ru obsahuje autonomní úlohy pro import a export
vybavení umožňující nejenom poslouchat na vydat. Toto řešení bylo provozováno i na platformě
hrazeném portu, ale i předat řízení dalšímu prograUNIX. Pro vývoj nových autonomních úkolů bude
movému vybavení. Tato část na straně klienta také
použit již navržený Microsoft .NET Framework 2.0.
slouží jako most pro komunikaci mezi volaným proS úspěchem převádíme metadata popisující EDIgramovým vybavením na jedné straně a infrastrukFACT zprávu do XML formátu a připravujeme algoturou na straně druhé. Pokud se to zdá příliš složité,
ritmus importu dat. Nebudu čtenáře zdržovat intak uživatelé UNIX přesto jistě tuší, že programové
formacemi o tom, jak jsme rozdělovali části kódů,
vybavení inetd je trefa do černého.
abychom docílili vytvoření znovupoužitelného frameworku pro autonomní úlohy, a také webové čásKomunikace typu OnDemand je znázorněná na náti řešení. Musím však říci, že pokud se chystáte vysledujícím obrázku.
tvořit takto obecnější
framework, je potřeba
myslet na to, jak se vám
budou chovat standardní části logování .NET
v některých portálových
prostředích. Neměli byste taky zapomenout,
že některé z těchto řešení vyžadují registraci
použitelných knihoven
do GAC (Global assembObrázek 2: Komunikace typu OnDemand
ly cache). Abych se však
vrátil zpět k naší implementaci. Mluvíme-li o imporZastánci Windows zřejmě již ví, že pod tímto systu dat ze vstupního souboru, tak část těchto prací
témem to není takovým standardem jako u UNIX.
není závislá na existenci databáze. V našem případě
Pokud byste připravovali takovéto řešení ve vašem
tomu nebylo jinak. Oddělením částí programování,
produktu, tak byste se měli striktně vyhnout použirozebráním EDIFAC zprávy a její validací jsme mohtí funkcí zapisujících informace na standardní vstup
li pokračovat v pracích nezávisle na stavu migrace
nebo výstup. Důvodem proč nezapisovat je to, že
12
pokud vaše programové vybavení volá někdo tímto způsobem, tak vám do procesu předává komunikační rouru právě formou standardního vstupu
a výstupu. I když na Windows se něco takového
moc nepoužívá, nehodíme však flintu do žita, pomysleli jsme si. Začali jsme tedy hledat, zda lze takovéto řešení rozumně pokrýt. Kdo hledá najde, říká
se. Po nalezení pár placených odkazů a ověření několika ne zcela funkčních řešení jsme nalezli konečně to, co jsme potřebovali. Pak mohlo začít testování. První problémy se objevily hned na počátku,
kdy náš program sice začal po oslovení komunikovat, avšak po prvních voláních bylo spojení přerušeno. Snažili jsme se zjistit, co může být příčinou
tohoto chování a pro podporu jeho detekce jsme
zaslali všechny podklady tvůrci SDK. Po několika
komunikacích s dodavatelem SDK a neúspěšných
testech však dostáváme zprávu, že ve funkcionalitě
SDK určené pro operační systém Windows je chyba
a oprava bude uvolněna někdy v příští verzi. Ještě,
že algoritmus zůstává stejný a mění se jenom konfigurace, pomysleli jsme si.
ad b/
Protože čas je neúprosný, naše úsilí se soustředí na co nejrychlejší konfiguraci prostředí brány v módu OnInitiator. Konfigurace prostředí není
zcela v naší moci a je potřeba oslovit Brusel, ale
tady nám něco říká, že zítra to asi nebude. Vrháme se proto na definování automatické části, která bude oslovovat tuto bránu v předem určených
intervalech, a to nejlépe s možností definice rozdílných intervalů v průběhu celého dne. Dlouho hledat nemusíme a rozšířeným nastavením automaticky spustitelných úkolů v operačním systému MS
Windows 2003 lze tuto funkcionalitu zcela pokrýt.
Po zprávě, že Brusel již prostředí nakonfiguroval,
provádíme testovací ověřování a po pár kolech můžeme říci, že algoritmus je funkční.
Dějství čtvrté – pokračování vývoje autonomních úkolů
Migrace dat v době, kdy jsme řešili problémy brány,
pokročila tak, že data jsme již měli k dispozici, jak
na našem vývojovém serveru, tak také v prostředí
zákazníka. Při samotném vývoji importu jsme se setkali s problémem implementace odložených kontrol vkládaných záznamů. Tato funkcionalita je pod
Informix řešena přímo, avšak Microsoft na to jaksi
pozapomněl. Řešení jsme však nakonec nalezli, ale
až na úrovni ovládání constraints nad samotnými
tabulkami databáze. Po testování importu a odladění případných chyb se již rozeběhly práce na přípravě exportů. Postupující práce nám daly možnost
provést vzájemné srovnání exportů z UNIX a Windows. Jenže tady jsme se nestačili divit. Všechny
položky seděly, avšak datumové položky se zcela náhodně rozcházely o jeden den, a to jak dopředu, tak i dozadu. Začali jsme kontrolovat migrovaná data v MS SQL Serveru a tam bylo přesně
to, co jsme exportovali pomocí našeho algoritmu.
Po následné kontrole v Informix jsme zjistili, že data
se přenesla chybně. Verdiktem je, že v migraci je někde chyba a je ji potřeba co nejdříve objevit. Začíná
zdlouhavé hledání a testování za podpory software
umožňujícím porovnání datových tabulek, rozdělování připravených importních balíků na menší
(po rozdělení na obsahově menší balíčky se frekvence o poznání snížila) a další činnosti. Nebudu
čtenáře zdržovat výčtem všeho, co jsme podnikali k tomu, abychom objevili v čem je problém, ale
řešení se nakonec nalezlo. V našem případě to byla
nutnost aktualizace použité verze IBM Informix Client SDK 2.90.TC1 na verzi novou, a to IBM Informix
Client SDK 2.90.TC6R1. Po nasazení této verze již vše
proběhlo správně.
Dějství páté - webové aplikace
Implementace webových aplikací do prostředí zákazníka mimo jiné předpokládala integraci Active
Directory, použití impersonifikace (změna identity) při přístupu na datové zdroje, a také byl předpoklad, že uživatelům zanecháme systém upozornění při provádění autonomních úkolů přistupujících
do databáze. Z celkového řešení se nakonec nejproblémovější ukázala část pro přístup na datové
zdroje pod jinou identitou. Tato část je dostatečně
popsána na MSDN, ale ne všechny doporučení jsou
s ohledem na prostředí portálu funkční. Po hledání
řešení metodou pokus omyl se nám úpravou kódu
a zařazením volání Windows API funkce RevertToSelf (zruší předcházející impersonifikaci), před samotnou záměnou identity uživatele, podařilo
upravit tuto část kódu tak, aby byla funkční i pro vystavení do portálu. Co nás dále překvapilo při vývoji webových aplikací? Jak jsem již předeslal, nebylo toho příliš. Co však možná stojí za zmínku, je
to, že pro přípravu exportů do formátu DBF byl použit standardní MS Jet OLEDB poskytovatele. Pokud však použijete tohoto poskytovatele s vlastností dBASE 5.0, počítejte s omezením velikosti
textových datových položek na hodnotu 255. Pro
formát Excel jsme zvolili “standardní” možnost tohoto produktu zpracovávat HTML soubor. Jediné,
co pro korektní zpracování tohoto formátu samotným Excelem musíte dodržet, je konvence hlavičky
a samotných stylů. Za zmínění také stojí fakt, že při
použití stejného frameworku (ve kterém jsou definovány globální proměnné) pro obě aplikace a potřeby registrace těchto aplikací do GAC může dojít
k problémům při aktualizaci, nebo samotné funkč-
nosti těchto aplikací na provozovaném portálu.
Tuto situaci jsme vyřešili stanovením jednoho z čísel určených pro verzi, a to pro každou webovou
aplikaci samostatně. Z pohledu dvou aplikací je situace jednoduchá a určení padlo na rozlišení dle
sudé a liché. Posledním překvapením, přesto potěšujícím, je to, že MS SQL Server 2005 podporuje
pro optimalizaci pokládání dotazů výběr z části dat.
Při vývoji webových aplikací nám tato funkcionalita
přišla „jako na zavolanou“.
Dějství šesté - nasazení
Nasazení systému proběhlo až nad očekávání hladce, řekl bych. Dílem i proto, že v našem případě již
všechny aplikace byly instalované v produkčním
prostředí a předtím proběhl pilotní provoz. Také
z toho důvodu, že jsme migraci již měli, jak se říká,
v malíčku. Co by se tedy dalo v tomto místě zmínit?
Jak se na to dívám zpětně, tak organizační část převedení systému s dopadem na všechny vstupující
subjekty se nám v časovém skloubení harmonogramu ukázala výhodou.
Martin Janček
[email protected]
Metody a techniky
objektově orientované analýzy
V minulém čísle Komixích novin 2007 / 2008 byl zveřejněn článek „Tvorba a využití katalogu uživatelských požadavků“. V tématu „Uživatelské požadavky“ pokračujeme a volně navazujeme na uvedený článek z minulého čísla.
Tentokrát se zaměříme na základní metody a techniky při analýze. Připomeneme si základní charakteristiky disciplín Requirements Engineering a Object
Oriented Analysis, metody Object Behavior Analysis a techniky Unified Modeling Language. Využitím praktických zkušeností můžeme získat souhrn
jejich hlavních výhod.
Rekapitulace disciplín pro popis požadavků
Requirements Engineering (RE) je osvědčená disciplína, vhodná pro popis uživatelských požadavků
složitějších systémů.
RE má především tyto cíle:
• zlepšení komunikace mezi dodavatelem a odběratelem,
• dokumentace požadavků,
• zpřesnění požadavků,
• sjednocení protichůdných požadavků,
• setřídění požadavků podle důležitosti.
Použití RE má tyto důsledky:
• rychlý vývoj požadavků na straně odběratele,
• forma popisu je srozumitelná odběrateli, definuje CO se má řešit, ne JAK,
• včasné vyjasnění priorit,
• méně problémů při předání díla odběrateli.
V minulém článku jsme se soustředili na strukturu
katalogu uživatelských požadavků – zmínili jsme
se o často používaných typech atributů požadavku a popisu ve formě strukturovaného textu formátovaného v tabulce. Právě to jsou charakteristické
rysy techniky používané při RE. Jedním z atributů
požadavku je také podrobný popis požadavku. Tomuto jedinému atributu se budeme tentokrát věnovat podrobněji.
Objektově orientovaná analýza (OOA) je mnohem mladší disciplína a je mnohem bližší objektově orientovaným technologiím realizace SW aplikací. Může navázat na RE a sebrané požadavky popsat
podrobněji a ve struktuře vhodné pro využití objektových technologií.
Hlavním cílem OOA je taková struktura popisu, která umožňuje snadnou modifikaci nebo jednoduché
doplnění bez nežádoucích vedlejších efektů. Použití OOA umožňuje tvorbu větších a složitějších systémů. Pro OOA je charakteristické obohacení statického modelu o základní prvky chování systému
– metody tříd.
Při popisu požadavků je možné respektovat strukturu informací odpovídající objektovým dynamickým a statickým modelům (viz rozdělení popisu
požadavků na popis okolí, chování a statické struktury v minulém článku).
Object Behavior Analysis (OBA) je jedna z prvních metod OOA. Je velice jednoduchá, přesto dodnes jedna z „nejobjektovějších“ (vznikla společně
se Smalltalkem v ParcPlace Systems).
Metoda má tyto cíle:
• jednoduchý a čistě objektový popis systému,
• odvození popisu statického modelu od popisu
dynamického modelu.
Dokumentace vytvořená podle OBA je charakteristická vysokou mírou integrity popisu systému (těsnými vazbami mezi dynamickým a statickým modelem).
13
Nejcennějším přínosem OBA je doplnění techniky
CRC (Class – Responsibility – Collaborator) o techniku OBA scénářů, které detailně popisují dynamický model.
Unified Modeling Language (UML) je poměrně
mladá technika, která pomáhá při OOA.
Cílem UML je jednotný způsob komunikace během
analýzy a návrhu. Výhodou je možnost snadného
a rychlého osvojení informací při předávání práce
v týmu. Pro UML je charakteristický popis pomocí
modelů, jejichž nedílnou součástí jsou standardizované diagramy.
my (hodí se výborně především
pro znázornění vazeb ve statickém
modelu nebo pro
popis variant při
postupu dynamickým modelem).
Pro popis detailů
je vhodnější dobře
strukturovaný text
(v tabulce).
Obrázek 3 - OBA scénář - vazby mezi modely
UML diagramy
Využití disciplín pro popis požadavků
V současné době
jsou UML diagramy
velmi často používaným prostředkem pro dokumentaci požadavků.
UML obsahuje
mnoho typů diaObrázek 4 - Správná míra podrobností
gramů (více či méně specializovady do skupin podle vrstev architektury (uživatelské
ných na různé činnosti). Někdy dochází k míchání
rozhraní, aplikační logika, databázová vrstva). Toto
typů objektů z různých typů diagramů v jediném dirozdělení je nezbytné později při návrhu (volbě aragramu – to ztěžuje orientaci začátečníka ještě více.
Použití diagramu a strukturovaného
chitektury). Místo tříd „Formulář objednávky“, „ObPro popis požadavků v dynamickém modelu jsou
textu
sluha objednávky“ a „Databázová tabulka objedvhodné diagramy:
Při popisu požadavků se občas setkáváme se dvěnávky“ je vhodné použít jedinou tzv. „doménovou“
• UML Activity (vhodný pro jednoduchý popis proma extrémy – stovkami stran textu bez jediného
třídu „Objednávka“. Analogie platí i o metodách tacesů),
obrázku nebo naopak s mnoha obrázky bez zjevkové doménové třídy – místo metod „Zobrazení
• UML Use Case (vhodný pro popis interaktivních
ných návazností a bez jakéhokoliv vysvětlujícíformuláře“, „Validace dat“ a „Uložení záznamu“ je
systémů).
ho textu. Doporučit lze samozřejmě střední cestu.
vhodné použít jedinou metodu „Uložení“.
Oba uvedené typy diagramů lze používat s výhoPro vytvoření nadhledu je vhodné použít diagraPři popisu atributů stačí použít obecné datové tydou v jediném dopy (řetězce definované maximální délky, čísla s dakumentu (podle
ným maximálním rozsahem, datum, čas, ...) – je to
povahy příslušvhodnější než použití konkrétních datových typů
né části úlohy).
programovacího jazyka nebo databázového serveJe důležité dbát
ru. Volba konkrétního typu proběhne opět pozděna jednoduchost
ji v rámci návrhu. Dodržení uvedených pravidel dodiagramu z hleménového modelování má dva kladné následky:
diska kvalitativ• modely jsou jednodušší – tedy lépe čitelné při
ního (používejte
schvalování odběratelem,
co nejméně typů
• zkušený návrhář dokáže lépe optimalizovat pro
prvků na diagracílovou architekturu a technologie.
mu) i kvantitativObrázek 1 – Volba techniky podle úrovně podrobnosti
ního (složité diagramy přetvořte
Scénáře OBA
na hierarchickou
Při použití několika modelů popisu požadavků
strukturu
jedjsou důležité vazby mezi těmito modely. Tuto nenoduchých diazbytnou podmínku kvalitního popisu požadavků
gramů). Pro poje možné zajistit s pomocí techniky scénáře z mepis
požadavků
tody OBA. Scénář OBA slouží k jednoduchému pove statickém mopisu požadavků na chování. Má podobu tabulky, jedelu použijte diajíž řádky popisují posloupnost vyvolání metod tříd.
gram
Vlastní vyvolání metody třídy je popsáno v řádku
• UML Class
tabulky.
Při popisu požadavků není vhodNa rozdíl od Use Case scénářů nepředpokládá scéObrázek 2 - Použití UML diagramů
né rozdělovat třínář OBA variantní cesty (Alternative Paths). Pro poPřednosti RE (popis strukturovaným textem) a OOA
(základní části katalogu uživatelských požadavků)
jsme zdůraznili v minulém článku. Tentokrát se zaměříme na použití UML diagramů a OBA scénářů při
podrobném popisu požadavku v dynamickém modelu. Detailní popis požadavků ve statickém modelu není z pohledu tohoto článku tak důležitý – popis atributů tříd vychází z tradiční metody datového
modelování, je doplněn popisem metod a rozšířen
je také popis typů vazeb.
14
pis větvení je praktické (názorné) použít diagram
UML Activity.
Zápis OBA scénářů a údržbu vazeb mezi dynamickým a statickým modelem automatizuje CASE nástroj QuickCRC firmy Excel Software.
nepomůže. Již v minulém článku byla zmínka o definici požadavku „na úrovni uživatele“ jako protiklad
k popisu z pohledu programátora (pomocí terminologie technologie IT). Ještě jednou připomínám
důležitost správné úrovně popisu požadavku!
Úroveň podrobnosti požadavku
Závěr
Celý článek se zabýval metodami a technikami analýzy požadavků, ale to samo o sobě začátečníkovi
Uvedené disciplíny, metody a techniky nestojí proti sobě. Vhodným výběrem jejich výhod je lze pro-
pojit do jednotného celku, který zůstává jednoduchým a účinným nástrojem pro dokumentaci
požadavků na různé úrovni podrobnosti.
Milan Číha
[email protected]
Pohled na DWH&MIS&BI (s ÚSMĚVEM !!!!)
aneb co nás čeká a mine/nemine?
Nevíte, kde je tady nejbližší datový sklad?
To nevím, ale zeptejte se u holiče,
tam to určitě budou vědět.
Nechť nám uvedené motto přiblíží skok, kterého
jsme v oblasti IT (ale samozřejmě i v jiných oblastech) během historicky zanedbatelně dlouhého
resp. krátkého období svědky. Snad pro přiblížení,
ještě naši tatíci při hledání potřebných informací
využívali spíše zdroje lidské. Našinec dnes nejvýše
osloví kolegu, ale spíše si prvotní přiblížení daného problému „vygůgluje“ a poté volí další optimální postup.
Ale nezůstávejme u našince, takto více či méně profesně postižené IT osoby. Je vypovídající, že obdobný postup volí nejen teenageři (tam je příklon
k novému, rychlému, … jistě očekávaný), ale i takové skupiny spoluobčanů, u kterých bychom toto
v době ještě nedávno minulé očekávali značně
méně (učitelé, lékaři, sousedi v domě, … ). Že všichni tito již počítač z velké části využívají i pro činnosti rozumné, spojené jak s profesí tak i s volným
časem, je další strana téže mince.
Zkusme se podívat výše uvedenou optikou na vývoj v oblasti DWH & MIS & BI a na to, kam vývoj
bude pokračovat dále. Jen pro ujasnění - tento elaborát si zcela jistě neklade za cíle býti strategickým
či prognostickým či jakýmkoliv jiným zásadním příspěvkem k dané problematice. Spíše se jedná o lehkým perem pojatou krátkou rekapitulaci a stejným
způsobem pojatou vizi co by nás v blízké budoucnosti potkati mohlo.
Ti starší z nás si jistě dobře pamatují na okouzlení z prvních on-line provozních IS, kdy jsme s obdivem sledovali kroky od pořízení dokumentu
až po jeho zaúčtování a zanesení všech relevantních údajů do datových struktur. Postupem doby
se výše uvedené okouzlení posunulo kvalitativně
dále, z oblasti provozních IS do prostředí MIS, BI,
DWH či jak jsme si zvykli navazující nadstavbová řešení nazývat. Dalším postupem doby se pak MIS, BI,
DWH staly nedílnou součástí dodávaných řešení,
objemy dat začaly nabývat objemů nebývalých.
S objemy dat se začaly rojit i další objemy tentokrát
terminologické – od zaužívaných ROLAPů, MOLAPů, HOLAPů, CRM, ODS a přehršle dalších až k současně silně atraktivním záležitostem typu In Memory Analysis (že by IMA ?).
Kratince se u pojmu IMA zastavme - v čem tedy spočívá kouzlo právě tohoto termínu? Věc je zdánlivě
prostá – veškerá data nejsou uložena v databázovém prostředí, ale přímo v souboru na disku. Nu
a při práci s aplikací se celý tento soubor či jeho potřebná část načte do operační paměti a tudíž veškeré počítání, vyhledávání a další činnosti se dějí přímo v operační paměti a tudíž velice rychle (odezvy
v jednotkách vteřin).
Potud teorie. Jaká ale byla praktická zkušenost
v KOMIXu?
Mnozí z Vás, kolegů, zaregistrovali, že v minulém
roce se stal součástí KOMIX nabídky v oblasti MIS,
BI, DWH produkt QlikView firmy QlikTech. Dodejme to podstatné – jedná se o produkt postavený
právě na výše zmíněné IMA architektuře. K prvním
kontaktům s firmou i produktem došlo právě před
rokem, následovalo seznámení, zaškolení a snaha
cosi prodat.
Rád bych se na tomto místě krátce vrátil právě
k seznamovací etapě. Je dobře známo, že v rámci
KOMIXu je zkušenost s produkty a řešeními pro oblast MIS, BI, DWH letitá a nasazená řešení jsou vesměs úspěšná a dlouhodobě provozovaná. Také
je známo, že během uplynulých let byly KOMIXu
představovány různé úžasně výkonné, uživatelsky komfortní, technologicky progresivní a i jinak
zázračná řešení od různých, většinou renomovaných dodavatelů. Druhou stránkou věci je skutečnost, že z výše zmíněných řešení se mnohé nepodařilo uspokojivě zprovoznit ani v „laboratorních“
podmínkách KOMIXu, a to ani s vydatným přispěním specialistů dodavatele. A tak zůstalo u osvědčeného řešení a občasné vpády revolučních novinek byly brány shovívavě.
S výše popsanými zkušenostmi jsme proto přistupovali i ke zmíněnému produktu QlikView. Pro
rychlé posouzení proklamovaných vlastností se
nabízela cesta nejjednodušší – vzít fungující řešení s daným rozsahem dat a s danou funkcionalitou
(konkrétně DAPO1: Kmen pojištěnců) a celou záležitost převést do prostředí QlikView a otestovat,
zdali a jak bude řešení fungovat v novém prostředí. Řečeno, vykonáno a ejhle. Ono to fungovalo nad
očekávání. Jen pro ilustraci – jednalo se o aplikaci s cca 25 mil. záznamů. Doby odezvy u standardního řešení (MicroStrategy) se pohybovaly v závislosti na složitosti výstupu na úrovni 1 až 3 minut,
u rozsáhlých porovnání pak i k 8 minutám. Výstupy
v prostředí QlikView pak byly k dispozici za neuvěřitelných 1 až 3 vteřiny.
A rázem jsme u leitmotivu celého tohoto pojednání. Kam jsme došli (kdo to ví?) a kam že to spějeme? Máme mít obavy o to, co a jak bude následovat, co a jak bude dál? Zjistíme jako naši předkové,
že ani IT svět není placatý (jako se předkům jevila
Země jako taková) a že obzory jsou otevřené? Kam
až dojde uplatňování nano, bio, a dalších technologií, o kterých zatím moc veřejnosti dostupných informací není k dispozici ani v „gůglu“? Jak dlouho
ještě bude platit Mooreův zákon?
A co říci na závěr? Nenapadá mne nic lepšího, nežli
odkaz na kultovní TV seriál „Návštěvníci“. Míra vizionářství zmíněného díla, reprezentovaná známou
„bradavicí“ v případě nutnosti umísťovanou na čelo
uživatele vyvolávala v době vzniku díla shovívavý
úsměv. V dnešní době však vyvolává spíše mrazení
– skutečně spěje vývoj k CML (pro nepamětníky –
Centrální Mozek Lidstva)? Aby se ještě Orwell a jeho
„Velký bratr“ tam někde nahoře nedivili …
A TEĎ VÁŽNĚ
BUSINESS INTELLIGENCE
FROM WIKIPEDIA, THE FREE ENCYCLOPEDIA
STANDARDIZACE BI NÁSTROJŮ
Řada podniků dnes pociťuje přeplněnost informa-
15
cemi. Množství a koncentrace dat v podnikových
databázích a dalších zdrojích dat narůstá. Naproti
tomu pokračující fragmentace BI nástrojů pro jejich
zpracování a vizualizaci redukuje možnosti reálného využití těchto informací. Proto dnes většina podniků soustřeďuje své úsilí na standardizaci BI. Jejím
cílem je nejen snížení nákladů, ale i vytváření vyšší
hodnoty zpřístupněním podnikových informací širokému okruhu pravidelných a příležitostných uživatelů. Výsledkem kombinace těchto faktorů bývá
zlepšení provozní výkonnosti podniku.
BI – NÁSTROJ
KONKURENCESCHOPNOSTI
PODNIKÁNÍ
Business intelligence, datové sklady a další související pojmy se staly nedílnou součástí světa jak informačních technologií tak managementu firem a institucí. Problematika BI jako celku je v současnosti
již velmi rozsáhlá. V tomto krátkém článku se budeme věnovat vybraným oblastem, které jsou z hlediska zákazníka pro úspěšnou realizaci BI systémů
stěžejní.
BI jako pojem. Přístup k BI.
Úvodem si pro účel tohoto článku dovolím upřesnit
vymezení pojmu business intelligence. Přesto, že se
s pojmem BI setkáváme stále častěji, je jeho obsah
mnohdy chápán odlišně. Z mnoha významů anglického slova business vybereme výraz podnikání. Pod pojmem intelligence pak nadále uvažujme
prostředí a v něm realizovaný nástroj pro podporu
rozhodování. Po sjednocení můžeme provést určité
zjednodušení a nadále rozumět pod pojmem BI nástroj pro podporu konkurenceschopnosti podnikání. V souladu s vymezením pojmu BI se změnil i přístup k problematice samotné. Zdaleka již není ze
strany IT firem nutné tak velkého úsilí v oblasti přesvědčování zákazníků o výhodnosti BI řešení, jako
tomu bylo v nedávné minulosti. Naopak, stále častěji se setkáváme s aktivním zájmem ze strany firem
či institucí. Zdálo by se, že tato situace je pro dodavatele BI bezmála ideální. Pro kvalitní realizaci takovýchto aktivních přístupů je však třeba věnovat
pozornost mnoha oblastem. V následujícím textu
se zmíním o některých z nich, které mají obecnou
platnost.
Zaměření BI.
Kvalitní BI řešení by zcela jistě mělo co nejvíce splňovat požadavky, citované prakticky ve všech publikacích k dané problematice. Uveďme alespoň ty
nejdůležitější.
Poskytnout uživateli řešení a současně i nástroj. Dodržení této zásady umožní, aby uživatel
nebyl pasivním prvkem, žádající po někom dalším
realizaci svých požadavků, ale aby měl k dispozici prostředí pro přímou realizaci svých požadavků.
Uživatel se stává aktivním tvůrcem.
Strukturovaná data a následně i informace.
16
Správné BI řešení musí být nástrojem pro přeměnu dat na informace. Otevřenost řešení. Otevřenost musí být podporována jak co do struktury dat
tak co do rozsahu. Všechny části řešení tak musí co
nejvíce podporovat schopnost dynamických změn
řešení jako celku. Klasickým záměrem BI řešení je
poskytnutí vybraných dat ve vhodně strukturované podobě pro podporu přehledových údajů,
analytických výstupů, realizaci ad-hoc dotazů, dolování dat, sledování trendů, vývojových řad a podobně. Pro tyto oblasti jsou požadovány údaje ze
zdrojových provozních IS, včetně údajů archivních
a historických. V souladu s neustále se zvyšujícími
možnostmi HW a SW se však stále častěji ukazuje
možnost a výhodnost pokrytí některých typů výstupů, které byly dříve realizovány výhradně v prostředí provozních IS.
Požadavky na BI. Přehnaná očekávání.
Výše zmíněné rozšíření možností BI řešení je pro zadavatele záležitost velmi příjemná a žádoucí. Tento
široký záběr v sobě skrývá jisté záludnosti. Krátce se
pokusím popsat některé základní.
Požadavky. Pro úspěšnou realizaci BI řešení je základním předpokladem definice požadavků, které
by měly být pokryty. Jak bylo uvedeno výše, záběr
BI je v současné době velmi široký. Při realizaci je samozřejmě možné stanovit soubory požadavků třeba i ze všech oblastí a pojmout BI řešení jako projekt
velice rozsáhlý. Tento přístup však v sobě skrývá nebezpečí, že požadavky na jednotlivé oblasti nebudou specifikovány dostatečně přesně a úplně a návaznost jednotlivých oblastí ve výsledném řešení
nebude dostatečná. Pro minimalizaci komplikací
tohoto druhu je často vhodné využít jedné ze základních vlastností řešení BI a DWH – otevřenosti –
a realizovat záměr po jednotlivých částech.
Přehnaná očekávání. Při definici požadavků je nezbytná úzká spolupráce zákazníka se zkušeným dodavatelem. Požadavky pro jednotlivé oblasti pak
lze snadněji definovat tak, aby je bylo možno BI řešením maximálně pokrýt a současně eliminovat ty
požadavky, které je možné či vhodné řešit až v dalších fázích projektu. Výše popsaným způsobem je
možné z velké míry omezit jedno ze zásadních nebezpečí – přehnaná očekávání a následné zklamání
nad realizovaným řešením.
Data. Data. Data.
Pro pokrytí jakékoliv funkcionality jakýmkoliv nástrojem potřebujeme v souladu s definovanými požadavky zcela zásadní věc: vhodným způsobem uspořádaná verifikovaná a konsolidovaná
data v prostředí datového skladu. Na tomto místě
je třeba citovat odhady renomovaných společností, že převážnou příčinou (více než 50 % - dle pramene) neúspěšnosti BI projektů jsou právě nekvalitní data. Podle stejných zdrojů dochází často až při
snaze o BI řešení k odhalení významné části nesouladů v datech provozních IS. Problém s daty je tedy
zřejmý. Podívejme se na to, jak jej nejlépe vyřešit.
Primární databáze.
Pro dosažení co nejvyšší kvality dat pro potřeby BI
se osvědčila architektura řešení s využitím primární databáze. Primární databáze je nejčastěji realizována v prostředí zvolené relační DB. Do prostředí primární databáze (PD) jsou z jednotlivých zdrojů
(provozní IS, historické a archivní údaje, vnější zdroje) přenášeny požadované číselníkové a hodnotové
údaje v požadované podrobnosti. V prostředí PD je
tedy k dispozici kopie vybraných provozních údajů.
Primární databáze pokrývá tyto základní a z hlediska BI řešení nezbytné funkce:
• PD je jednoznačně definovaným rozhraním mezi
prostředím provozních IS (obecně zdroji dat)
a prostředím DWH
• PD je zdrojem pro realizaci DWH jako celku a jednotlivých specializovaných datových tržišť
• PD umožňuje jednoznačně odhalit případné nesoulady mezi výstupy BI řešení a údaji získávanými
nástroji provozního IS z prostředí provozních IS
Datová pumpa.
Datová pumpa (DP) je ta část BI řešení, která zajišťuje plnění struktur PD ze zdrojů dat (provozní IS, … )
a nad takto naplněnými a aktualizovanými údaji vytváří a aktualizuje DWH struktury ve formě specializovaných datových tržišť. Problematika DP je jistě značně rozsáhlá a pro účel tohoto příspěvku se
omezím pouze na popis základních skutečností.
Pro realizaci DP můžeme použít několik způsobů či
jejich kombinací. Jedná se o ETL nástroje (extrakce, transformace, načtení) případně ETLC (extrakce,
transformace, načtení, čištění) či řešení DP specializovanou aplikací. Vhodnost použití jednotlivých
způsobů je silně závislá na typu, rozsahu a kvalitě
zdrojových údajů.
V případě, že kvalita dat v provozním IS je prokazatelně velmi dobrá a dále že množství a složitost
kontrol při plnění PD je dobře zvládnutelné ETL,
ETLC nástroji, je jistě na místě jejich použití.
Další možností je pro plnění PD vytvořit specializovanou aplikaci. Toto řešení nám snáze pokryje požadavky i na komplikované kontroly a řešení případných chybových stavů. Moderně vytvořené DP
ve formě specializované aplikace jsou řízeny vlastními daty (metadaty). Takováto řešení umožňu-
jí významnou část požadavků na změnu či rozšíření funkčnosti DP realizovat právě úpravou metadat
bez zásahu do aplikace jako takové.
Při výběru řešení na realizaci DP je třeba pečlivě zvážit výše uvedené skutečnosti. Při volbě ETL,
ETLC nástroje je zřejmé, že čím je daný nástroj výkonnější a komfortnější, tím bývá i jeho cena vyšší.
Též samotné zakoupení nástroje není konečnou záležitostí, požadované řešení je třeba implementovat. Při volbě aplikace je třeba dbát na to, aby realizované řešení bylo maximálně otevřené (viz řízení
metadaty) a podporovalo uvažované úpravy či rozšíření pro další fáze BI řešení.
Otevřenost BI řešení
Otevřenost BI řešení je pojem, který prolíná všemi fázemi realizace jako červená niť. Frekvence výskytu tohoto pojmu může být často až nepříjemná,
avšak na základě zkušeností s realizací je třeba konstatovat, že se jedná o vlastnost skutečně zásadní.
Otevřenost pro oblast struktury dat, objemu dat
a pokrytí uživatelských požadavků jsou pojmy, které se prolínají a jsou na sobě závislé.
Struktura dat. Zmínili jsme se, že BI řešení jsou často s výhodou realizovaná po menších částech, etapách. Je samozřejmým požadavkem, že struktury
dat realizované v úvodních částech budou využitelné i v dalších částech. Současně je zřejmé, že bude
docházet k jejich rozšiřování v souvislosti s realizací dalších požadavků. BI řešení tak musí podporovat
snadné zahrnutí přenosu dalších údajů ze zdrojových IS do prostředí PD a následně do navazujících
struktur DWH.
Jak bylo výše zmíněno, nabízí se realizace BI řešení po jednotlivých částech, které pokrývají rozdílně
zaměřené skupiny uživatelských požadavků. Při definování nových požadavků lze s výhodou vycházet
z realizovaných částí a maximálně využít již realizovaných datových struktur a příslušných částí řešení.
Objem dat. Tato oblast bývala v minulosti, v době
podstatně menších možností HW a systémového
SW, často kritickou částí řešení. Je třeba si uvědomit,
že účelně navržené struktury DWH často bývají rozsáhlejší, než struktury zdrojových IS. V prostředí PD
jsou vytvářeny kopie vybraných údajů provozních IS,
včetně údajů archivních a historických. Pro pokrytí
požadavků na rychlou odezvu jsou v prostředí DWH
vytvářeny potřebné agregované struktury.
Závěrem …
Pokud se nám podaří navrhnout a posléze realizovat BI řešení co nejvíce splňující v úvodu uvedené
teze, jsme na dobré cestě dostát často citovaným
sloganům typu „Změňte svá data na konkurenční
výhodu“ a naopak vyhnout se varujícím odhalením
typu „Manažeři nedostatečně využívají možností BI
řešení“.
Jak je zřejmé, v tomto příspěvku jsme se zabývali
pouze vybranými částmi BI řešení. Neméně podstatným částem – například oblasti publikování
a komunikace – se budeme věnovat v některém
z dalších příspěvků.
Uživatelské požadavky. Architektura BI řešení je
otevřená také z hlediska uživatelských požadavků.
Pavel Seibert
[email protected]
17
Nové vlastnosti verzí 10 a 11 databázového
serveru IBM Informix
1. Úvodem
Smyslem tohoto krátkého sdělení je upozornit
na vlastnosti nejnovějších verzí databázového serveru IBM Informix, které umožňují mnohá praktická
rozšíření jak pro vývoj aplikací, tak pro optimalizaci a monitoring jejich provozu. Autor se soustředil
zejména na vlastnosti, které subjektivně považuje
za nejvýznamnější z hlediska správy databázového
serveru a ze znalosti provozu u našich zákazníků,
kteří se již zejména o verzi 11 zajímají. Verze 11.10
byla oficiálně uvedena na trh v červenci 2007 a verze 11.50 v květnu 2008.
oblastí prostoru tblspace typu a snížit počet případů, ve kterých se tyto oblasti nacházejí v jiných než
primárních blocích.
2. Novinky ve verzi 10.00
Administrace databázového serveru v jednouživatelském režimu
Administrátor databázového serveru může nyní využít nový jednouživatelský (single-user) režim, který je
přechodným režimem mezi quiescent a online. Na rozdíl
od režimu quiescent přijímá nová připojení pouze pro
uživatele informix. Pomocí tohoto režimu může
administrátor provádět libovolné úlohy administrace včetně úloh vyžadující provádění příkazů jazyků
SQL a DDL, zatímco k serveru nejsou připojeni jiní
uživatelé.
Volitelná velikost stránky
Od verze 9.40 je možné vytvářet databázové prostory (dbspace), jejichž základní velikost (velikost
chunku) není omezena na 2GB. Implicitně bylo
nastaveno, že správu velkých chunků je nutno nastavit ručně, od verze 10 je tato správa automaticky
zapnuta při instalaci. Nově verze 10 umožňuje určit velikost stránky dočasného nebo standardního
datového prostoru dbspace při jeho vytváření. Lze
určit jinou velikost než je velikost výchozí, pokud
je potřeba větší délka klíče než odpovídá výchozí
velikosti stránky. Kořenový prostor dbspace sestává
vždy ze stránek výchozí velikosti. Velikost stránky
musí být celočíselný násobek výchozí velikosti, maximálně však 16 kB.
Správa přístupových oprávnění pomocí výchozích rolí
Administrátor může vytvořit roli, přidělit jí oprávnění a přiřadit ji jako výchozí roli jednotlivým uživatelům nebo skupině PUBLIC na úrovni databáze.
Každý uživatel, jemuž je přidělena výchozí role, získá
oprávnění této role společně s libovolnými dalšími
oprávněními udělenými jednotlivě. Výchozí role působí automaticky od okamžiku přihlášení uživatele
k databázi, aniž by ji bylo nezbytné nastavit příkazem SET ROLE. Nová syntax příkazů GRANT, REVOKE
a SET ROLE podporuje tuto vlastnost, která může
poskytnout vhodná oprávnění k databázovým
objektům skupině uživatelů v relacích, ve kterých
spouštějí aplikace bez příslušných příkazů GRANT.
Definování společných oblastí vyrovnávací paměti
Konfigurační parametr BUFFERPOOL definuje společnou oblast vyrovnávací paměti, která odpovídá
velikosti stránky prostoru dbspace. Správce serveru
může tuto oblast definovat též pomocí obslužného programu onparams. Kromě velikosti stránky
definuje parametr BUFFERPOOL počet stránek
vyrovnávací paměti, počet front LRU ve společné
oblasti a hodnoty lru_min_dirty a lru_max_dirty.
Konfigurační parametry BUFFERS, LRUS, LRU_MAX_
DIRTY a LRU_MIN_DIRTY se již nepoužívají.
Přejmenování prostorů typu dbspace
Uživatel informix nebo uživatel s oprávněním administrátora DBA mohou v režimu quiescent nebo
single-user přejmenovat dříve definovaný standardní
prostor typu dbspace. To může být zapotřebí při reorganizaci dat ve stávajícím prostoru typu dbspace.
Správa prostoru tblspace typu tblspace
Správa prostoru tblspace typu tblspace je pružnější. Prostor tblspace typu tblspace je sada stránek,
které popisují umístění a strukturu všech prostorů typu tblspace v daném prostoru typu dbspace. Pomocí obslužného programu onspaces lze
přesunout nebo vypustit blok obsahující prostor
tblspace typu tblspace. Velikost první i následující
oblasti je volitelná pomocí parametrů TBLTBLFIRST
a TBLTBLNEXT. Tato vlastnost umožňuje snížit počet
18
Vytvoření několika oddílů tabulky nebo indexu
v prostoru typu dbspace
V případě fragmentovaných tabulek využívajících
schéma distribuce založené na výrazu nebo typu
cyklická obsluha (round robin) lze nyní vytvořit více
oddílů, které jsou kolekcemi stránek tabulky nebo
indexu v jediném prostoru typu dbspace. Pomocí
nového klíčového slova PARTITION a názvu oddílu
lze vytvořit tabulky a indexy s oddíly a vytvářet, vypouštět nebo měnit fragmenty oddílů.
Určení událostí, které spouštějí program Alarm
Program
Pomocí nového konfiguračního parametru ALRM_
ALL_EVENTS se definuje rozsah událostí, které
spouští alarm.
Určení sdílené paměti větší než 4 GB
Segmenty sdílené paměti lze vytvořit tak velké, jak
dovoluje platforma operačního systému nebo parametr SHMMAX.
Nastavení replikace HDR s externím zálohováním a obnovením
Replikaci High-Availability Data Replication lze použít k externímu zálohování a obnovení pomocí standardních příkazů onbar a ontape.
Opětné odesílání indexů do sekundárních serverů replikace HDR
Lze znovu odeslat index, který je v sekundárním
indexu páru replikace HDR poškozený. Opětné
odeslání indexu je rychlejší než vypuštění a opětné
vytvoření indexu v primárním serveru. Tato funkce
zvyšuje dostupnost primárního serveru replikace
HDR.
Přejmenování instance serveru Dynamic Server
v systému Windows
Obslužný program IBM Informix Server Instance
Manager obsahuje možnost změnit název instance serveru Dynamic Server v systému Windows.
Ke změně názvu již není zapotřebí odinstalovat
a přeinstalovat server ani vytvořit novou instanci
a znovu zavést data.
Zjištění informací o verzích
Volba -version všech obslužných programů serveru
vypisuje podrobné informace o operačním systému
sestavení, číslu sestavení a datu sestavení. Volba -version poskytuje více informací než stávající volba -V.
Podpora formátu adres IP IPv6
Pro adresy IP lze se serverem Dynamic Server použít formát IPv6. Ovladač IBM Informix JDBC Driver
verze 3.0 s podporou prostředí JDK 1.4 podporuje
formát IPv6. To znamená, že kód analyzující adresu
URL připojení dokáže zpracovat dlouhou (režim 128
b) adresu IPv6 (stejně jako formát IPv4). Tato adresa
IP může být literálem formátu IPv6.
Vylepšení výkonu
Vylepšení výkonu zahrnují zlepšený výkon dotazů
a čas potřebný pro zotavení. Dále bylo dosaženo vylepšeného výkonu v následujících oblastech:
• transakce XA
• vnořená levá vnější spojení kompatibilní
se standardem ANSI
• poddotazy
• úplná vnější spojení
Vytváření a vypouštění indexů bez uzamykání
tabulek
Pomocí nových příkazů CREATE INDEX ONLINE
a DROP INDEX ONLINE se vytváří a vypouští indexy
v režimu online, zatímco databáze a přidružené ta-
bulky jsou trvale dostupné. Tyto příkazy jazyka SQL
umožňují vytvářet a vypouštět indexy, aniž by bylo
nutné uzamknout tabulku po dobu vytváření nebo
vypouštění indexu.
3. Novinky ve verzi 11
Instalace
Pokud administrátor preferuje grafické uživatelské
rozhraní při instalace IDS má možnost spustit skript
ids_install s argumentem –gui. Implicitně zůstává
instalace v klasickém znakovém prostředí. Nově byl
přidán skript pro odstranění instalace.
Rozšířená škálovatelnost replikací
Zavedením tzv. Multi-node Active Cluster for High
availability (MACH11) dochází k výraznému rozšíření dosavadních možností sdílení datových prostorů
a replikačních konfigurací. Kromě již známých HDR
a EDR lze vytvořit tzv. Remote Standalone Servers (RSS), což
jsou sekundární databázové servery s asynchronní
obousměrnou komunikací. Na rozdíl od HDR není
omezen počet RSS. Další variantou je tzv. Continual Log
Restore (CLR), kdy je tento sekundární server trvale
ve stavu rychlé obnovy a v případě výpadku primárního serveru jej lze manuálně přestavět na primár. CLR je určen pro edice Workgroup a Express. Dalším
rozšířením funkcionality MACH11 je možnost modifikace dat na sekundárních serverech a možnost
definice pořadí přepínání serverů v clusteru.
Zlepšení výkonnosti
Nová implementace kontrolních bodů (checkpoints) –
starší verze často trpěly dlouhou dobou blokování
provozu během kontrolního bodu. Problém se běž-
ně řeší snižováním hodnot parametrů LRU_MIN_
DIRTY a LRU_MAX_DIRTY resp. atributů lru_min_
dirty a lru_max_dirty u parametru BUFFERPOOL,
což vede k výraznému nárůstu zátěže procesorů.
Poslední úpravy mechanismu kontrolního bodu
vedly ke zrušení fuzzy checkpoints a novou technikou automatického kontrolního bodu se dosahuje toho, že
blokování kontrolním bodem je uživatelsky nepozorovatelné. Stanovení maximální doby zotavení – zavedením nového parametru RTO_SERVER_RESTART
lze nastavit dobu, po níž při výpadku začne server
automaticky provádět proces fast recovery, tj. obnovení
konzistence dat pomocí logů.
Automatizované dynamické ladění IDS se týká již
zmíněných automatických kontrolních bodů, dynamického ladění počtu LRU, AIO VP a stanovení
rychlosti I/O operací pro fyzický a logický log při zotavování. Pro CPU VP je možné vyhradit paměť.
Administrace
Při instalaci databázového serveru je nově generována databáze sysadmin, která zachycuje historii
příkazů a správce databázového serveru má pomocí
vestavěných funkcí task a admin možnost monitorovat historii provozu.
Nové obslužné vlákno (thread) umožňuje automatizovat proces monitorovacích a administrativních
úloh a to na úrovní SQL, SPL i uživatelských funkcí.
Konfigurační parametr SQLTRACE deklaruje úroveň
sledování a analýzy SQL příkazů. Škálovatelnost je
ve čtyřech stupních a počet sledovaných dotazů je
nastavitelný. Sledování lze provádět globálně nebo
specifikovat uživatele.
Nedostatkem starších verzí byla skutečnost, že
po importu dat resp. masivním příkazu INSERT,
DELETE nebo UPDATE bylo nutno ručně provést aktualizaci systémového katalogu příkazem UPDATE
STATISTICS… Verze 11 tyto statistiky automaticky
aktualizuje na úrovni LOW a MEDIUM.
Při zapnutí výpisu query plánu se zatím generoval jediný soubor sqexplain.out, do kterého se zapisovaly (append) všechny informace. SQL příkazem SET EXPLAIN
FILE TO <jmeno> lze definovat výstupní soubor pro
konkrétní SQL dotaz.
4. ZÁVĚR
Smyslem článku není poskytnout úplnou informaci
o nových vlastnostech IDS verze 10 a 11, ale obrátit
pozornost jak vývojářů, tak uživatelů na možnosti,
které tyto verze poskytují. Po některých vlastnostech již bylo dávno voláno (nastavitelná velikost datové stránky, lepší mechanismus kontrolních bodů,
rozšíření SQL aj.), jiné mohou pomoci řešit provozní
problémy zejména rozsáhlých aplikací s velkým počtem uživatelů. Na závěr si autor dovolí drobnou
poznámku o tom, že společnost Komix má vlastní
program pro trasování SQL dotazů již od roku 1994
a mnohokrát ho u zákazníků úspěšně použila.
Petr Paul
[email protected]
NOVÉ VLASTNOSTI ORACLE DATABASE 11G
V srpnu 2008 uplynul jeden rok od prvního vydání
verze 11g databázového serveru Oracle a v okamžiku, kdy čtete tyto noviny, je již možná venku Release
2 verze 11g. Máme tedy nejvyšší čas podívat se, co
je ve verzi 11 nového, abychom to stihli, než Oracle
přijde s verzí 12.
Je jistě pouze náhodná shoda okolností, že zhruba
ve stejnou dobu jako Oracle doklopýtal k verzi 11
i nejmenovaný jiný databázový server. V každém
případě verze 11g Oracle vznikla v reakci na konkrétní potřeby zákazníků a prohlubuje cíle, které si
začaly klást již předešlé verze Oracle, zejména 10g:
• snadné užití (správa a provoz, změna/upgrade,
vývoj aplikací),
• použitelnost pro všechny druhy dat a v celém životním cyklu,
• vysoká kvalita služeb a technologie umožňující
vyniknout aplikacím.
Hezký, i když ne zcela úplný popis nových vlastností verze 11g najdete např. na adrese http://www.
oracle.com/technology/pub/articles/oracle-data-
base-11g-top-features. Zde se pokusíme stručně
charakterizovat nové vlastnosti zajímavé pro vývojáře, ale také pro datové architekty a testery aplikací. Laskaví čtenáři nám doufejme odpustí smíchání
anglické a počeštěné terminologie.
Virtuální sloupce
Tabulka může mít virtuální sloupce, jejichž hodnoty nejsou uloženy, nýbrž odvozují se dynamicky
pomocí SQL výrazů z ostatních sloupců. Virtuální
sloupce mohou být indexovány funkčními indexy.
SQL operace pivot a unpivot
V dotazu lze použít konstrukci unpivot, která „otáčí“ data z několika sloupců výsledku do řádků, a podobnou konstrukci pro opačný směr „otočení“ (jejíž
funkce bohužel není zcela inverzní).
Partitioning
Jsou přidány další kombinace způsobů víceúrovňové segmentace tabulek. Dále, lze segmentovat též
dle virtuálních sloupců, dle referenčního omezení
(segmentace je pak dána segmentací otcovské tabulky) nebo bez předem daných hranic resp. pravidel (zařazení do konkrétní partition explicitně volí
aplikace v každém příkazu insert). Lze též použít
intervalovou segmentaci s automatickým vytvářením nových partitions dle potřeby.
OLTP Table Compression
Je přidán nový způsob komprese relačních dat,
s nímž se zmenšuje objem dat uložených na disku
(běžně cca 2-4x, ale to asi bude záviset na datech),
zrychluje se fyzické čtení a snižují se nároky na databázovou cache, do níž jsou bloky načítány též
v komprimovaném stavu. Komprimovaný blok obsahuje „symbol table“ s hodnotami, které se v něm
opakovaně vyskytují; v místech výskytů jsou pak
jen odkazy. Blok není komprimován při každém zápisu dat, ale jen tehdy, je-li dosaženo určitého prahu zaplnění bloku - režie komprese při zápisu tak
činí údajně pouze několik procent.
19
Secure Files
Je přidán nový způsob uložení LOB (velkých objektů), který kombinuje výhody uložení v databázi
s výhodami obvyklými při uložení v souborovém
systému. Máte tak k dispozici rychlý přístup k velkým objektům, zajištění jejich konzistence a možnosti zálohování, šifrování, komprese, deduplikace a kontrolovaného cachování a logování změn.
Deduplikace znamená, že při opakovaném výskytu
téže hodnoty ve sloupci se hodnota LOBu ukládá
jen jednou, v dalších výskytech se ukládá jen odkaz na ni. Pro kompresi používá databázový server
standardní kompresní algoritmy - ale jen tehdy, jeli šance na úsporu objemu daného LOBu. Kromě
potlačení logování změn můžete též logovat jen
metadata o LOBu, což podobně jako v souborových systémech postačuje k obnově při výpadku.
Způsob uložení LOBů v tabulce a jejich vlastnosti
se volí v příkazu create table a alter table, techniky
práce s LOBy v aplikaci se nemění.
XML Binary Storage
Je přidán další způsob uložení dat typu XMLType,
který kombinuje výhody nestrukturovaného uložení XML v CLOB s výhodami objektově relačního
uložení založeného na schematu XML (úspora prostoru a možnost rychlého relačního přístupu k prvkům XML).
OLAP
Pokračuje integrace OLAP do databázového serveru. Je možné používat materializované pohledy
OLAP, pro které fungují mechanismy automatické
aktualizace a query rewrite SQL dotazu na kostky
OLAP. Metadata OLAP jsou součástí systémového
katalogu a pro OLAP objekty se používají standardní mechanismy řízení přístupových práv. K dispozici
jsou skripty pro přípravu kostek, které v řadě aplikací mohou nahradit programování kostek.
DDL_LOCK_TIMEOUT
DDL příkazy, které potřebují zamknout tabulku,
doposud končily chybou, pokud zámek nebyl momentálně dostupný (např. pokud uživatelská transakce držela zámky řádků tabulky). Toto chování lze
pozměnit nastavením parametru ddl_lock_timeout pro seanci či celý databázový server: server se
pak pokouší provést příkaz DDL, dokud není zámek
dostupný a dokud nevypršel zadaný timeout.
Flashback Data Archive
Tento prostředek slouží pro audit, undo, debug
změn dat či pro uchování historie dat požadované
některými právními předpisy. Historie dat uživatelské tabulky se uchovává v interních tabulkách
(SYS_FBA_*) po vytvoření archivu příkazem CREATE
FLASHBACK ARCHIVE a předepsáním daného archivu pro uživatelskou tabulku pomocí příkazu ALTER
TABLE. Archiv můžete umístit do samostatného
tabulkového prostoru - třeba na nízkonákladové
20
disky. Archiv se automaticky čistí podle předepsané doby retence. Historická data se z archivu
vytahují pomocí SQL dotazu s modifikátorem AS
OF TIMESTAMP jména uživatelské tabulky ve složce FROM (podobné možnosti byly zavedeny již
ve verzi 9i resp. 10g ve spojení s nástroji Flashback
Query resp. Flashback Versions Query; tyto nástroje
ovšem využívají undo informaci, která má omezenou životnost).
Transaction Flashback
Pomocí procedury DBMS_FLASHBACK.
TRANSACTION_BACKOUT či grafického prostředí
Enterprise Manageru lze stornovat zadanou transakci včetně transakcí na ní závislých (pracujících
s daty v ní modifikovanými). Databázový server při
stornování vychází z undo a redo informace.
Continuous Query Notification
Můžete předepsat a programově zpracovávat automatické notifikace o změně tabulek, na které se
odkazuje zadaný SQL dotaz, nebo o změně výsledku dotazu.
Result Cache
Výsledky SQL dotazů a PL/SQL funkcí lze uchovávat
pro opakované užití ve vyhrazené oblasti sdílené
paměti databázového serveru. Uchovaný výsledek
se automaticky aktualizuje, pokud se od jeho předchozího použití změnil obsah tabulek, z nichž se
odvozuje; cachování neustále se měnících výsledků
bychom se ovšem asi měli vyhnout.
Mechanismus cachování můžete aktivovat pro
zvolený dotaz či poddotaz (pomocí hintu result_
cache), pro všechny dotazy (nastavením parametru
result_cache_mode=FORCE) a pro zvolenou funkci
(pomocí speciálního zápisu na konci její hlavičky).
Můžete též využít obdobné cachování výsledků
dotazů na klientech (pro klienty založené na OCI8
driverech), jímž se navíc sníží zátěž sítě a využije se
lacinější paměť.
Connection Pool
Aby odpadlo opakované vytváření databázových
připojení, které je poměrně náročné, bývá v aplikacích zaváděn connection pool.
Nyní můžete využít pooly zřízené přímo v databázi, sdílené podle potřeby větším počtem aplikačních serverů či aplikací.
Nativní kompilace PL/SQL
Lze jednoduše předepsat nativní kompilaci PL/
SQL (či Java) programů bez nutnosti zavádět
C-kompilátor a starat se o knihovny v souborovém
systému.
Šifrování a maskování dat
Je přidána možnost šifrování tabulkových prostorů
(bez potíží s indexy), exportovaných dat a záloh; při
exportu dat můžete též předepsat maskování citlivých dat pomocí zvolené uživatelské funkce.
SQL Plan Baselines
Je zaveden mechanismus pro automatizovanou
a kontrolovanou podporu dobrých výpočetních
plánů. Uchovává se historie plánů, v níž klíčovou
roli hrají dobré plány uložené jako „plan baselines“.
Plány se zařazují jako baselines buď ručně nebo
automatizovaně (je-li to předepsáno parametrem
optimizer_capture_sql_plan_baselines=TRUE); optimalizátor vybírá plán pouze tehdy, je-li výrazně
lepší než stávající. Ruční správu plánů lze provádět
z příkazové řádky i z grafického rozhraní Enterprise
Manageru, které mimo jiné poskytuje i nabídku pro
srovnání výkonnosti kandidátského plánu s dosavadním baseline.
Rozšířené statistiky dat
Optimalizátoru lze pomoci při výběru vhodného
výpočetního plánu zavedením statistiky popisující
rozložení hodnot výrazu nad sloupcem či statistiky
rozložení hodnot v kombinaci sloupců. Tyto statistiky jsou užitečné, pokud výraz zkresluje rozložení
hodnot sloupce resp. pokud jsou sloupce navzájem
závislé.
Adaptivní kursory pro příkazy s bind-proměnnými
Optimalizátor při opakovaných výpočtech příkazu SQL s vázanými proměnnými postupně zjišťuje
a začíná využívat případnou závislost optimálního
výpočetního plánu daného příkazu na hodnotách
vázaných proměnných. Závislost bývá způsobena
nerovnoměrným rozložením hodnot sloupců tabulek srovnávaných s hodnotami proměnných.
Automatic SQL Tuning Advisor
Automatické ladění SQL je založeno na nástroji SQL Tuning Advisor zavedeném ve verzi 10g.
Nástroj umí pro zadaný příkaz či příkazy SQL navrhnout vylaďující opatření typu přidání indexu,
přepsání příkazu, přepočet statistik dat či přidání
SQL Profilu (doplňujících statistik specifických pro
daný příkaz, získaných vzorkováním dat a dílčími
výpočty). Ve verzi 11g může být nástroj automaticky spouštěn v časovém okně údržby systému pro
nejnáročnější příkazy určené podle statistik výpočtu příkazů za uplynulé období. Navrhne-li nástroj
doporučení typu SQL Profile, jsou tato doporučení
hned vyzkoušena, a přináší-li alespoň trojnásobné
výkonnostní zlepšení, jsou automaticky zavedena
(ostatní doporučení zůstávají uložena v databázi
pro pozdější ruční využití).
Partition Advisor a SQL Access Advisor
Je přidán nástroj pro návrh segmentace tabulek. Nástroj je zároveň integrován do SQL Access
Advisoru zavedeného ve verzi 10g a sloužícího pro
celkové vyladění schématu vůči sadě sledovaných
příkazů SQL. SQL Access Advisor nyní umí navrhnout optimální kombinaci přidání a zrušení indexů,
materializovaných pohledů a partitions s ohledem
na sledované příkazy SQL, jejich náročnost a četnost výskytu a předpokládané přínosy i náklady
na udržování přístupových cest (indexů apod.).
SQL Test Case Builder
Pomocí balíku dbms_sqldiag nebo pomocí grafického prostředí Enterprise Manageru můžete vyexportovat do souboru veškeré informace potřebné
pro spuštění zadaného SQL příkazu a naimportovat je do testovacího prostředí. Informace zahrnují
např. samotný příkaz, jeho výpočetní plán, potřebná data a metadata (definice tabulek a dalších
objektů, úplná data či jejich vzorky, statistiky dat),
údaje o uživateli a o prostředí kompilace a výpočtu
příkazu. Poznamenejme, že balík dbms_sqldiag
poskytuje též funkčnost SQL Repair Advisoru, který vám může pomoci vyřešit resp. obejít případné
bugy Oracle hlášené při zpracování SQL příkazu.
Database Replay
Tento nástroj umožňuje zaznamenat aktivity v databázi (SQL příkazy) do souborů, znovu je přehrát
v téže nebo jiné databázi a prostředí a srovnat
výkonnostní statistiky za období zaznamenávání
a přehrávání. Slouží tak např. pro otestování vlivu
různých změn v databázi či jejím prostředí na plnění aplikačních požadavků. Jako změna může
vystupovat např. instalace patche, upgrade OS
či databáze, přechod na clusterovanou databázi,
změna platformy, nastavení parametrů databáze,
statistik optimalizátoru či indexů apod. Při užívání
databáze Replay se mohou hodit i jiné mechanismy
poskytované databázovým serverem Oracle, například Flashback Database pro pohodlnou obnovu
výchozího stavu dat nebo Standby Snapshot pro
pohodlné využití standby databáze jako testovacího prostředí.
SQL Performance Analyzer
Tento nástroj slouží pro ověřování vlivu různých
změn na výpočet zvolených příkazů SQL. Přehrává
sledované příkazy před a po změně a kvantitativně
srovnává výkonnostní statistiky z obou přehrání.
Umožňuje snadno předem stanovit vliv povýšení
verze optimalizátoru či změny inicializačního parametru, ale i jiných změn, např. přidání či ubrání
indexů a přepočtu statistik dat. Při naposled zmíněných změnách lze využít i další dvě nové vlastnosti – „skrytí“ indexu před optimalizátorem, resp.
dočasnou aktivaci statistik s odloženou platností
(nastavením parametru optimizer_use_pending_
statistics=true).
Je to vše?
Na všechny nové vlastnosti verze 11g se zde nedostalo. Nejvíce jsme asi ošidili databázové adminis-
trátory. Neprobrali jsme též produkty Oracle, které
více či méně souvisejí s databázovým serverem
– a tyto produkty se množí s tím, jak Oracle komplexně pokrývá více a více oblastí potřeb zákazníků. Zmiňme alespoň tři nástroje dodávané společně s databázovým serverem - SQL Developer,
Warehouse Builder a Application Express (nástroj
pro snadné sestavování a zavádění webových aplikací nad databází bez nutnosti většího programování). Z dalších produktů zmiňme alespoň Times
Ten In-memory Database pro extrémní požadavky na rychlost a Enterprise Manager, který byl primárně určen pro správu a monitorování produktů
Oracle a nově umí např. monitorovat aplikace z pohledu koncového uživatele.
Licencování
Znějí vám názvy nových vlastností verze 11g jako
jména cizokrajných zemí, do kterých jste se odjakživa toužili podívat? Zdá se, že tyto země máte nyní
za humny – jen si na některé z nich musíte dokoupit
příslušné options k databázovému serveru Oracle
Enterprise.
Jan Rada
[email protected]
Vytvoříme vám řešení na míru
 Vývoj aplikací
 manažerské informační systémy
 Systémy pro podporu obchodu
 Procesní a projektové řízení
 Testování aplikací
 Monitoring
a podpora
provozu IS
KOMIX s.r.o.
Avenir Business Park
Radlická 751/113e
150 00 Praha 5
tel.: +420 257 288 211
fax: +420 257 288 221
[email protected]
21
Zelený KOMIX
Od prosince roku 2006 má naše společnost certifikát dle normy ČSN EN ISO 14001 pro EMS
(systém environmentálního managementu), který spolu s již dříve získaným certifikátem
systém managementu kvality dle normy ČSN EN ISO 9001 je součástí integrovaného managementu systému (IMS). V rámci IMS naše společnost v současné době vytváří podmínky pro splnění požadavků mezinárodní normy ČSN IEC ISO 20000-1 pro systém managementu IT služeb, která je určena zejména pro firmy, působící a poskytující služby v oblasti
informačních technologií.
Proč se KOMIX věnuje také ekologii, životnímu prostředí a jak to souvisí s IT technologiemi? Jedí snad
zaměstnanci pouze bio jogurty a jiné biopotraviny,
nebo chodí do práce pěšky nebo jezdí na kole?
Ekologie je trendem 21. století a ekologické chování se stává nedílnou součástí dnešního běžného života některých občanů, firem a také i IT firem. Při
dodržování norem ekoprovozu mohou IT firmy dosáhnout dvojího efektu v podobě úspor nákladů
a ochrany životního prostředí. Nejlepší firmy v oboru IT postupně „zelenají“. Příkladem může být iniciativa Big Green, společnosti IBM, jejíž cílem je dosáhnout co největších energetických a jiných úspor.
Jak je to tedy u nás v KOMIXu?
Vedení společnosti KOMIX se v souvislosti s požadavky zákazníků státní správy při výběrových řízeních a v rámci společensky odpovědného chování
rozhodlo v roce 2006 zavést systém environmentálního managementu (EMS) podle standardu ISO
14001. EMS je systémem managementu, který je
zaměřen na sledování a zlepšování všech činností společnosti, které ovlivňují nebo mohou ovlivnit kvalitu životního prostředí. Životní prostředí se
přitom chápe v širokém kontextu ochrany přírody,
ochrany zdraví zaměstnanců i kvalitního pracovního prostředí.
Z hlediska působení na životní prostředí nemá naše
společnost žádné významné environmentální aspekty (prvek, který může ovlivňovat životní prostředí). Například nemáme v naší společnosti žádný
nebezpečný odpad související s vyráběným produktem. Charakter naší výroby v KOMIXu je už takový, že k naší „výrobě“ nepoužíváme ani žádné
chemické látky nebo přípravky, které by bylo potřebné skladovat nebo likvidovat a používat v souladu s požadavky zákonných nařízení a nařízení
z hlediska bezpečnosti práce. Jediným naším ovlivňováním životního prostředí je produkce kancelářského odpadu, spotřeba energií a chování našich
zaměstnanců.
Odpady
Odpady, které naše společnost produkuje, se samozřejmě snažíme nejen třídit, ale také jejich vznik
minimalizovat. Používáme v maximální míře elektronickou formu komunikace, a také elektronické dokumenty. Odpad, který nám vznikne třídíme,
22
tam kde je to možné, na plast a papír. Takto vytříděný odpad je potom odevzdán k dalšímu zpracování autorizovaným firmám. V následují tabulce je
uvedeno množství vytříděných a předaných odpadů k likvidaci.
Odpady
2006
2007
1-6/2008
Papír
0,2704 t
0,6749 t
0,1512 t
Plastické hmoty
0,0444 t
0,2886 t
0,1443 t
Směsný odpad
2,2214 t
2,2154 t
0,2886 t
Společnosti KOMIX byl magistrátem hlavního města Prahy vydán souhlas k nakládání s nebezpečnými odpady pro klasické CRT monitory (s katodovou
obrazovkou), které se při vyřazování z použití stávají nebezpečným odpadem. Z těchto důvodů máme
také uzavřenu smlouvu s Pražskými službami a.s.
na likvidaci nebezpečných odpadů, elektroodpadu, likvidaci komunálního odpadu a tříděného papíru. Dále pak se společností REMA máme uzavřenou smlouvu na likvidaci nebezpečných odpadů
a elektroodpadu.
Recyklace se tedy také týká veškeré techniky (elektroodpadu), kterou ve společnosti vyřazujeme
z použití. Platí, že zařízení, které bylo vyřazeno
z provozu, musí být znovu využito nebo recyklováno. V následují tabulce je uvedeno množství předaných nebezpečných odpadů a elektroodpadů.
Nebezpečné
odpady
2006
2007
1-6/2008
Televizory,
monitory,
obrazovky
0,272 t
0,120 t
0,250 t
Elektroodpad (vyřazené elektrické a elektronické zařízení)
0,120 t
0,400 t
0,075 t
V rámci systému environmentálního managementu je také každý rok odevzdáváno hlášení o produkci a nakládání s odpady, dále je prováděno přezkoumání registru environmentálních aspektů,
hodnocení environmentálního profilu apod.
Každý rok se rovněž provádí ověřování shody s právními předpisy uvedenými v registru právních a jiných požadavků a interní audity celého IMS, včetně
požadavků normy ČSN EN ISO 14001 na systém environmentálního (ekologického) managementu.
Také spotřeba elektrické energie představuje jeden
z nejvýznamnějších environmentálních dopadů aktivit téměř každé firmy. Proto jsme se v KOMIXu zaměřili na zvyšování energetické efektivity provozu
naší společnosti. Postupná výměna klasických CRT
monitorů za moderní LCD monitory je prvním krokem, včetně postupné orientace na výrobky s co
nejmenšími dopady na životní prostředí. To jsou
priority naší společnosti v oblasti životního prostředí a postupné „ozeleňování“ KOMIXu. Komix se také
zapojil do projektu „Zelená pro vaši firmu“, který se
týká řešení firemního elektroodpadu (PC, monitory,
apod.) a sběru drobného elektroodpadu z domácností (prostřednictvím zaměstnanců). V rámci tohoto projektu je v KOMIXu umístěn zdarma jeden
nerezový sběrný box určený pro všechna elektrická
a elektronická zařízení od zaměstnanců a zde mohou zaměstnanci odevzdat například svůj nepotřebný mobil, příslušenství nebo baterii a my již zajistíme ve spolupráci se společností REMA zdarma
likvidaci a recyklaci.
Z uvedeného výčtu aktivit je vidět, že společnost
KOMIX není „zelená“ pouze formálně, pro získání certifikátu, ale že se jedná o celou řadu aktivit,
které směřují k postupnému zlepšení všech činností, které mohou ovlivnit kvalitu životního prostředí. Tyto činnosti nelze změnit jednorázovým projektem nebo marketingovou kampaní, ale jedná
se o dlouhodobé působení různých aktivit směrem
k našim dodavatelům, zaměstnancům i zákazníkům
naší společnosti. Každé i dílčí zlepšení v této oblasti a rozšiřování těchto aktivit a myšlenek má smysl
a pomáhá něco změnit, ovlivnit či zlepšit v oblasti
životního prostředí pro všechny naše občany i obyvatele naší planety.
Jiří Feřtek
[email protected]
Zapomenuté klíče
Je velmi pozdní odpoledne. Po odchodu z práce jste zjistil(a), že jste si ve své kanceláři ve 3. patře zapomněl(a) klíče od bytu. Musíte se pro ně vrátit. Protože venku na ulici probíhá rekonstrukce
tramvajové trati a pozůstatky chodníků jsou poněkud blátivé, nechcete riskovat střet s uklízečkami.
Na obrázku vidíte plán budovy (3 patra) rozkreslený vedle sebe ve třech navazujících časových úsecích , ve kterých se mění pohyb uklízeček po budově. Vaším úkolem je do 30 minut dojít do kanceláře
ve 3. patře pro klíče.
Pravidla:
Během každého desetiminutového časového úseku můžete projít
maximálně 10 polí.
Nesmíte vstoupit na čerstvě vytřenou podlahu (modré pole).
Po projití maximálně 10ti polí se automaticky přesunujete do dalšího časového úseku do stejného místa v budově.
Pohybovat se můžete pouze pravoúhle, nikoli diagonálně.
Přesun po schodech do dalšího patra se počítá jako přesun
o 1 pole. Na schodišti se nesmíte zastavit.
Nesmíte se zastavit na poli, na které v dalším časovém
úseku přijde uklízečka.
Řešení zapomenutých klíčů:
10 min: běžte do 2. patra, zastavte se mezi schodišti (posun o 9 polí)
20 min: stůjte a čekejte až vyschne podlaha
30 min: pokračujte do 3. patra ke klíči ( posun o 10 polí)
Ponaučení : stát na místě může být nejrychlejší cesta k cíli (Jára Cimrman)
Test
Tomáš Vahalík
[email protected]
V poslední době se setkáváme s mnoha novými pojmy a zkratkami, týkajícími se nových technologií. Tyto zkratky sami
běžně používáme, často při tom ale jen vzdáleně tušíme, co daná zkratka znamená. Následují test Vám dává příležitost
nejen si prověřit své znalosti, ale hlavně se pobavit. Autorem testu jsou zaměstnanci společnosti Komix.
1. Bluetooth je
a) Viagra uvízlá mezi zuby
b)V slangu ochránců Krkonošského národního
parku označení pro sběrače borůvek
v ochranné zóně.
c) Jméno dánského krále (Harald Modrozub)
z 10. století, který si pravděpodobně nečistil
zuby, ale zato dokázal přimět válčící kmeny
k vzájemné komunikaci a dohodě.
2. GSM je
a) Gramofon s Magičem
b)Global System for Mobile Communications
c) Generální Sekretář Mongolska
3. LAN je
a) Local Area Network
b)Lace And Nab (napráskat a sbalit) způsob
seznamování z konce doby ledové,
v součastnosti časteji známá jako nová sexuální
praktika
c) Levný Ale Nechutný - v žargonu ČOI označení
pro některé restaurace
4. MP3 je
a) Motorka Pro 3 - oblíbené motorové jízdní kolo
vyhledávané hlavně vietnamskými zákazníky
b)Motorová Pila k jejímuž ovládání stačí 3 prsty
c) MPEG-1 Audio Layer 3
5. IP je
a) Izraelský Polibek - označení pro izraelské tříštivé střely
vysílané do hustě obydlených míst pásma Gazy
b)Intenzivní Píchání - převratný směr přístupu k práci
praktikovaný v textilních továrnách z období
perestrojky
c) Internet Protocol
6. GPS je
a) Geographic Public Service
b)Global Positioning System
c) Gde Preboha Som?
7. HDD je
a) Hard defection destruction
b)Hard disk drive
c) Head digital derange
8. DVD je
a) Divotvorný video disk
b)Defect video disk
c) Digital Versatile Disc
9. ROM je
a) příslušník menšiny
b)Read-only memory
c) Real oracle men
10. ADSL je
a) Asymetric Digital
Subscriber Line Technologie umožňující
velmi rychlý přenos dat
po telefonní lince.
b)Alkoholik Doražený
Syntetickým Lihem
d)Auto Do Sovětských
Lesů
23
Děkujeme všem
našim klientům
za důvěru
KOMIX s.r.o.
Avenir, Radlická 751/113e, 150 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o.
DTP a produkce: SDP V.I.P. Servis, s.r.o.
© Komix s.r.o. 2008