E-pasy: mýty a skutečnost

v

á

š

s

p

o

l

e

h

Vážení čtenáři, nové číslo našich tradičních novin vznikalo letos v  období, kdy se formovala nová vláda a  kdy se dokončovaly projekty zahájené za vlády staré. Jedním z těchto projektů viditelných v celé republice bylo zavedení pasů s  biometrickými identifikačními prvky, na kterém se KOMIX výrazně podílel – vyvíjel softwarovou část, která zabezpečovala příjem žádostí o pas a jejich zadání do výroby a byl dodavatelem kiosků sloužících ke kontrole pasů. Rok 2006 je rokem, kdy český trh IT výrazně roste a naší společnosti se podařilo tento trend zachytit. Očekávaný meziroční růst obratu v letošním roce je cca 20% a  je tažen do značné míry nárůstem služeb.

Kromě biometrických pasů, se nám podařilo předat Generálnímu ředitelství cel projekt zaměřený na on-line analýzu rizik celních deklarací, který si klade za cíl, zefektivnit kontrolu oběhu zboží při vývozu a dovozu a zvýšit její účinnost. Technologie, které jsou na tomto projektu použité, jsou obecně použitelné i  pro jiné aplikace, kdy je třeba rychle rozhodovat o nějakém podání nebo v krátkém čase vyhodnotit dopady určité události. Lze je aplikovat například na rizikové profily lidí, kteří o  něco žádají, nebo je možno zpracovávat měřené hodnoty z nějakého technologického procesu a vyhodnocovat jeho nežádoucí stavy. Na konci roku 2005 se KOMIX stal zakládajícím členem Czech ICT Alliance – uskupení IT firem, které mají zájem exportovat své produkty nebo služby do zahraničí. V rámci nabídky našich služeb na zahraniční trhy jsme se účastnili výstav Systems v Mnichově (říjen 2005) a CeBIT v Hannoveru (březen 2006). V současné době již máme za sebou počáteční etapy dvou projektů v  zahraničí. Dalším výsledkem této mise je podpis smlouvy o  distribuci systému genesisWorld německé firmy CAS Software AG. Tento software patří do kategorie CRM řešení (CAS – Computer Aided Sales). GenesisWorld je však podstatně více než jen aplikace pro správu kontaktů a  organizaci práce obchodníků. Jedná se o kompletní podporu komunikace ve společnosti (workgroup software včetně archivu dokumentů s velice dobrou podporou mobilních zařízení), v současnosti je celoplošně zaváděn i v naší společnosti. Plocha úvodníku samozřejmě nemůže být dostatečná k tomu, abych zde probral vše, co se v době od vydání minulého čísla povedlo nebo nepovedlo. Ty projekty a  technologie, které jsme považovali za zajímavé, zmiňují mí kolegové na dalších stránkách. Věřím, že každý z čtenářů, kterým se tento výtisk dostane do rukou, v něm najde něco zajímavého nebo pro něj nového.

Petr Kučera, [email protected]

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

E-pasy: mýty a skutečnost Petr Sobotka, [email protected] Možná si vzpomenete na článek v loňském čísle KOMIXích novin, který pojednával o našem podílu na vytvoření programového vybavení pro zpracování žádostí o nové řidičské průkazy. Mohli jsme si tehdy dovolit i krátké zhodnocení, protože systém měl za sebou již více než rok ostrého provozu. Naše aktivity v oblasti státní správy, přesněji řečeno systémů pro podporu vydávání osobních dokladů se od té doby ještě rozšířily – KOMIX se významnou měrou účastnil tvorby systému pro zpracování žádostí o nové cestovní doklady s biometrickými prvky, zkráceně e-pasy. V době vzniku tohoto textu je tomu teprve pár dnů, co byl zahájen ostrý provoz, na jakákoliv hodnocení je tudíž příliš brzy. V následujícím článku se proto pokusíme zmínit především pár technických a bezpečnostních aspektů, které s biometrickými doklady souvisí a kolem kterých se za poslední rok vynořilo množství povětšinou účelových mediálních bublin. Řekněme si na úvod, jak vlastně takový e-pas vypadá. Na první pohled se jedná o standardní pasovou knížku, jak jsme na ně byli již dříve zvyklí. Ihned po jejím otevření je však patrný rozdíl: první vnitřní list není z papíru, ale jedná se o tvrdou, tzv. polykarbonátovou desku. Na jejím povrchu jsou gravírovány („vypáleny“ laserem) mj. základní textové údaje o držiteli dokladu (jméno, příjmení, datum narození atd.), černobílá fotografie a podpis držitele, číslo dokladu a různé bezpečnostní prvky. Ve spodní části stránky je tzv. strojově čitelná zóna (MRZ, Machine Readable Zone). Jsou to 2 řádky souvislých alfanumerických znaků, ve kterých jsou obsaženy obdobné údaje jako v jednotlivých polích na této pasové stránce s tím rozdílem, že řádky slouží k automatizovanému načítání ve speciálních zařízeních. Strojově čitelná zóna je běžnou součástí všech v současné době vydávaných typů osobních dokladů. Nyní se dostáváme k tomu nejdůležitějšímu, co odlišuje e-pas od „běžných“ dokladů. Uvnitř polykarbonátové stránky je zalisován tzv. RFID čip (Radio Frequency Identification). RFID čipy jsou bezkontaktní čipy, které umožňují komunikovat se čtecím zařízením i na dálku. Podle konstrukce čipu je možné číst data v něm uložená na vzdálenost od několika centimetrů do několika metrů. RFID čipy se běžně používají např. pro automatizované evidování zboží v dopravních kontejnerech nebo jako klíčenky umožňující vstup do chráněného objektu. Čip v  e-pase obsahuje kromě různých řídících údajů především barevnou digitální fotografii držitele dokladu a rovněž vybrané textové údaje. V nedaleké budoucnosti (v České republice v roce 2008) se do čipu budou dále ukládat otisky levého a pravého ukazováku. Biometrické údaje v čipu splňují kritéria daná standardy ICAO (International Civil Aviation Organization), aby je bylo možné využít pro automatizované porovnávání (např. na letištních terminálech). Data v čipu jsou elektronicky podepsána výrobcem dokladu, což zabraňuje zfalšování informací v něm uložených. Vysvětleme si, jak probíhá čtení dat z čipu, a tím uvedeme na pravou míru jeden z mnoha mýtů, které se objevily kolem elektronických dokladů – sice, že „data z čipu je možné číst na dálku“. Čtení dat z e-pasu se skládá ze dvou fází. Nejprve musí dojít k načtení strojově čitelné zóny. Jedná se o optické snímání, které vyžaduje, aby pas byl vložen do příslušného čtecího zařízení (čtečky pasů). Část údajů ze strojově čitelné zóny je pak využita jako klíč pro přístup k datům v čipu. Bez tohoto klíče data z čipu přečíst nelze. Není tudíž pravda, že data z vašeho čipu si bude moci přečíst každý, kdo kolem vás projde se zařízením umožňujícím číst RFID čipy. Zůstaňme ještě u  metod, které slouží k zajištění bezpečnosti čipu. Jak bylo zmíněno výše, data v čipu jsou podepsána elektronickým klíčem výrobce dokladů. Tento podpis jakož i certifikát výrobce dokladů s  jeho veřejným klíčem je uložen v  čipu. Pomocí tohoto certifikátu lze ověřit pravost podpisu, tj. že data v  čipu byla skutečně vytvořena správným výrobcem dokladů. Certifikát výrobce dokladů vydává tzv. Národní certifikační autorita (NCA). Pravost certifikátu výrobce dokladů, který je uložen v čipu, se ověřuje pomocí certifikátu NCA, který musí být důvěryhodnou cestou přenesen do všech zařízení, ve kterých probíhá zpracování dat z čipu e-pasu. Další metodou, která je v současné době využívána pro zajištění bezpečnosti dat, je tzv. aktivní autentizace. Jejím smyslem je zabránit kopírování dat z čipu na jiný čip.

Aktivní autentizace je založena na tom, že každý čip je jedinečný a obsahuje unikátní privátní klíč (z venku nedostupný), kterým sám čip může podepisovat data. Čtecí zařízení pošle do čipu náhodně vygenerovaná data a nechá je čipem podepsat. Pomocí veřejného klíče čipu, který lze z čipu snadno přečíst a který je součástí dat podepsaných výrobcem dokladů, se následně ověří, že čip podepsal náhodně vygenerovaná data správným privátním klíčem. Možnost klonování dat je dalším tématem, kolem kterého se v poslední době hodně diskutuje. Aktivní autentizace je jedna z metod, jak tomuto nebezpečí zabránit. Co je vlastně tak převratného na uchovávání biometrických údajů v elektronické podobě v čipu? Předpokládá se, že postupem času budou hraniční terminály (ale i jiná místa, např. hotely, banky apod.) vybaveny přístroji pro snímání aktuálních biometrických prvků člověka (podoba obličeje, otisk prstu), který prokazuje svoji totožnost. Tyto přístroje pak provedou srovnání sejmutých údajů s daty uloženými v čipu e-pasu a tím dojde k ověření, že e-pas a údaje v něm uložené kontrolované osobě náleží. Strojové porovnání biometrických prvků je podstatně spolehlivější metoda, než vizuální kontrola, kterou je schopen provést člověk. A to i přes existující diskuze kolem kvality automatizovaného porovnávání např. podoby obličeje.

Zmiňme ještě jeden často kritizovaný aspekt použití dokladů s elektronickými daty. Tím je ochrana osobních údajů před neoprávněným uchováváním. Není totiž pravda, že data v čipu jsou šifrována, jak se lze dočíst v některých „odborných“ článcích. Jinými slovy, každé zařízení, které po načtení klíče ze strojově čitelné zóny získá přístup k datům v čipu, je může bez problémů načíst. A nic nezabrání tomu, aby pak data byla uložena do nějaké evidenční databáze. Jednotlivé státy se sice povětšinou zavazují k tomu, že data získaná např. při letištních kontrolách nebudou uchovávat, ale pokud se váš pas dostane do ruky někomu, kdo se rozhodne si vaše údaje zaznamenat, ani se o tom nedozvíte. Cestování s biometrickými pasem do „nedůvěryhodných“ zemí proto bude z hlediska bezpečnosti osobních údajů spíše kontraproduktivní. Mimochodem, ani USA se dosud jednoznačně nezavázaly k tomu, že data z čipu nebudou dlouhodobě uchovávat. Na závěr odhlédněme od moderních a často komplikovaných technologií a potěšme se tím, co nový systém přináší skutečně pozitivního: je to jedno z  prvních řešení v  oblasti státní správy, které nenutí běžného občana vyplňovat nekonečné formuláře informacemi o své osobě. Informacemi, které státní aparát má ve svých evidencích a není proto důvod chtít po žadateli, aby je znovu ručně vypisoval a měl hrůzu z toho, že se někde splete a bude muset začít znovu od začátku. Aplikace pro e-pasy na obecních úřadech totiž vytiskne kompletní žádost se všemi údaji dotaženými z  centrálních evidencí. Žadatel musí „pouze“ provést kontrolu a formulář opatřit dvěma podpisy – jedním vzorovým do pasu a jedním stvrzujícím správnost všech údajů na žádosti. Doufejme, že je tímto dán nový směr, kterým se bude i  nadále ubírat vývoj systémů a služeb, které stát využívá pro styk s občanem.

1

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

Elektronická riziková analýza V letech 2004 až 2005 byl v  rámci projektu PHARE na Celní správě České republiky vyvinut systém pro on-line elektronickou rizikovou analýzu projednávaných celních deklarací (systém ERIAN). Společnost KOMIX, jako významný hráč na poli IT, byla vybrána ke kompletnímu dodání tohoto ojedinělého systému. Hlavním cílem nového systému bylo nahradit dosavadní dosluhující poloautomatický lokální systém tzv. „Blokačních tabulek“, jehož funkčnost byla omezená, systémem novým, centralizovaným, s větší pružností specifikace hledaných rizik a s dostatečnou propustností. Zvolené řešení bylo koncipováno jako univerzální expertní systém pracující v reálném čase, jehož znalostní báze je plně spravovatelná uživatelským způsobem. V porovnání s ostatními členskými zeměmi EU se Česká republika zařadila implementací systému ERIAN mezi prvních několik málo zemí, které mají realizovánu moderní plnohodnotnou automatizovanou elektronickou rizikovou analýzu.

Motivace a požadavky Budovaný systém by měl zpracovávat průměrně cca 10 – 15 tis. deklarací za 24 hodin, z toho cca 80% v průběhu 6-ti hodin. Ve špičce tedy zhruba 30 deklarací za minutu. Bylo tedy nutné navrhnout takovou architekturu systému, aby byl schopen ohodnocovat příchozí deklarace v  závislosti na jejich složitosti během řádově jednotek sekund. Architektonický návrh musel zároveň počítat s tím, že v budoucnu bude objem ohodnocovaných dokladů významně růst především v důsledku plánovaného zapojení systému do zpracování dalších typů agend. Velmi důležitým, ne-li stěžejním požadavkem kladeným na nově budovaný systém bylo, aby byl maximálně otevřený vzhledem ke správě, údržbě a rozšiřování množiny apriorních informací, podle kterých ohodnocování dokladů probíhá. Tj. aby bylo možné uživatelským způsobem co možná nejjednodušeji množinu apriorních informací měnit a  upravovat bez nutnosti programátorských zásahů do systému. Neméně důležitým důvodem pro uživatelskou správu množiny apriorních informací je i to, že nositelem znalostí o modelech podezřelého chování jsou specialisté z řad uživatelů, nikoliv vývojáři. V neposlední řadě je

důležitým důvodem i to, že právě modely rizikového chování a jejich popis jsou tím nejcennějším a tudíž nejdůvěrnějším na celém systému, a proto je účelné, aby s jeho obsahem bylo obeznámeno co nejméně lidí. Jak již bylo řečeno, systém ERIAN primárně provádí elektronickou rizikovou analýzu zpracovávaných celních deklarací. Neomezuje se však na čistou on-line analýzu, tj. na analýzu pouze na základě statických apriorních informací-profilů rizik. Aby částečně eliminoval hlavní nevýhody čisté on-line analýzy (především neschopnost odhalit nové modely rizikového chování), zavádí systém ERIAN propojení čisté on-line analýzy s offline analýzou. Toto propojení rozšiřuje možnosti on-line analýzy o schopnost automatické adaptace chování na průběžně se měnící charakteristiky reálného světa a rizikového chování.

Naopak, je-li to potřeba, může strategický profil obsahovat i sadu složitých algoritmů. Při tvorbě profilů obsluha značně čerpá z offline analýz historických dat uložených v datovém skladu. K tomu jí slouží různé analytické nástroje, které, stejně jako samotný datový sklad, nejsou součástí systému ERIAN. Mezi datovým skladem, resp. off-line analýzou v něm uložených dat, a profily rizik systému ERIAN existuje přímá vazba, a  to v  podobě automatických výpočtů externích parametrů pro některé strategické profily rizik.

v

ě

t

ě

IT

Jan Vrána, [email protected] koliv jiné on-line agendy, která vyžaduje vysoký výkon a pružnost z hlediska definice chování. V  nedaleké budoucnosti se rýsuje rozšíření systému na další typ agend vykonávaných celní správou, konkrétně na agendu správy spotřebních daní. Z  technologického hlediska by v  budoucnu bylo možné uvažovat o  rozšíření nástrojů pro popis a vyhodnocení profilů rizik o nástroje pro práci s neurčitostí, např. o fuzzy logiku, která by mohla především strategickým profilům dodat ještě vyšší robustnost a  zároveň je přiblížit

Architektura Transakce začíná v okamžiku, kdy, zjednodušeně řečeno, deklarant podá celní deklaraci, celník ji přijme a klientská aplikace ji v XML podobě odešle k vyhodnocení rizikovosti. Systém ERIAN má centrální charakter, tj. všechny přijaté deklarace jsou posílány k vyhodnocení do centra a zpět putuje odpověď opět v XML podobě. Vyhodnocení rizikovosti probíhá na základě zadaných profilů rizik. V systému ERIAN jsou dva typy profilů rizik: • Taktické profily (také nazývané blokační) • Strategické profily. Posláním taktických profilů je co možná nejjednodušším způsobem zachytit relativně jednoduchý, konkrétní model rizikové situace, typicky požadavek na zastavení nebo kontrolu avizované zásilky, atd. Strategické profily mají odlišné poslání, charakter i filozofii. Na rozdíl od taktických profilů, jejichž smyslem je jednoduchost, strategické profily dávají svému tvůrci plnou volnost a velmi širokou paletu nástrojů, pomocí nichž mu umožňují formalizovat i velice složité modely rizikových situací. Vytváření strategických profilů vyžaduje na rozdíl od taktických profilů velmi znalé tvůrce, kteří musí dokonale ovládat věcnou podstatu modelované problematiky a musí mít také určité zkušenosti s algoritmizací. Strategické profily totiž poskytují obecné vývojové prostředí s možností využití podle potřeby prvků imperativního i deklarativního programování. Speciálně deklarativní programování představuje velmi mocný nástroj pro formalizaci požadovaného modelu bez nutnosti imperativně definovat postup vyhodnocení.

Aplikace pro správu blokačních (taktických) profilů

Použité technologie Pro implementaci systému ERIAN byly použity následující technologie: • Výměna dat (příchozí deklarace, výsledky ohodnocení): XML • Správa profilů:.NET • Klientské aplikace:.NET • Kritické části:C • Databáze:MS SQL Technologie .NET a MS SQL byly určeny zákazníkem jako součást zadání.

Současnost a výhled Systém ERIAN byl vyvinut pro ohodnocování rizikovosti celních deklarací. V současnosti systém zpracovává přes 90% všech celních deklarací (denně více než 10 tis. deklarací). Svou koncepcí systém ERIAN poskytuje už nyní možnost nasazení na jiné typy celních agend, ale nejen tam, uplatnění může najít v analýze jaké-

přirozenému chápání. Pokud by ve vzdálenější budoucnosti došlo k rozšíření systémů provádějících on-line rizikovou analýzu celních deklarací v okolních zemích, bylo by možné uvažovat např. také o možnostech automatické výměny profilů rizik mezi těmito systémy, a tím dále výrazně zefektivnit proces ochrany širšího ekonomického prostoru (např. EU).

Závěr Výjimečnost systému spočívá především v míře, v jaké mohou uživatelé prostřednictvím strategických profilů měnit chování systému a přizpůsobovat jej novým poznatkům a potřebám bez nutnosti programátorských zásahů do systému. Dále pak v třídě nástrojů, které mají uživatelé prostřednictvím strategických profilů k  dispozici, v  automatickém rozšíření on-line analýzy o výsledky off-line analýzy a v neposlední řadě pak v efektivitě zpracování a v otevřenosti vzhledem ke změnám a ke zpracování jiných agend.

Správná dokumentace – podmínka kvalitního softwarového díla Vladimír Říha, [email protected] Bez řádné dokumentace nelze žádné rozsáhlejší softwarové dílo ani efektivně užívat, ani bezpečně spravovat a udržovat. Proto součástí každého softwarového díla (jako koneckonců každého většího díla) je i příslušná dokumentace, která k softwaru poskytuje doplňující informace. Dokumentaci lze s ohledem na účel, jejž má plnit, rozdělit na několik základních typů: •D  okumentace uživatelská slouží jako návodná pomůcka koncovým uživatelům softwaru a usnadňuje jim jeho zvládnutí a efektivní užívání; podává zejména informace vysvětlující, co se na obrazovce (a někdy i „za ní“) děje, jak a  proč má uživatel reagovat při vzniku určité situace apod. Uživatelská dokumentace by neměla prostě popisovat stav na obrazovce, ale měla by informovat o tom, co se stane, když..., nebo jak a  proč reagovat při vzniku určité situace. Např. pokud je na obrazovce zaškrtávací políčko s popisem „Korekce alfa“, pak dokumentace by měla podat informaci podstatnější než jen že „zaškrtnutí políčka zapne korekci alfa“; dokumentace v  tomto

2

případě musí vysvětlit, co to je korekce alfa a jak se její zapnutí/vypnutí projeví ve výstupu nebo na chodu programu. • Dokumentace technická slouží ke správě, údržbě a  případnému dalšímu rozvoji softwarového systému; popisuje systém na logické, datové, technické i technologické úrovni – schémata, tabulky, seznamy a katalogy patří mezi její nejdůležitější prvky; technickou dokumentaci lze dále členit třeba na analytickou, systémovou, zdrojovou a další. Především tuto dokumentaci užívá technický personál, který zajišťuje provoz systému; tvůrcům pak slouží pro údržbu a další rozvoj systému. • Dokumentace administrativní a  ekonomická je na první pohled poněkud odtažitá, přesto své místo v dokumentaci systému má: obsahuje informace související s vyhodnocováním úspěšnosti projektu (u  tvůrce), nebo s nákladovostí na vlastnictví a provoz systému (u vlastníka). Konkrétní obsah, rozsah a struktura dokumentace jsou samozřejmě určeny rozsahem a komplikovaností popisovaného systému a  účelem,

pro který má být dokumentace užita (ten je v neposlední řadě určován i cílovým uživatelem dokumentace): dokumentace programu „Hello, world!“ bude asi obsahovat jen několik řádků – totiž jen zdrojový text, pokud to ovšem nebude naprogramováno zrovna v assembleru – na rozdíl od rozsáhlého informačního systému, který zřejmě bude doprovázen mnohosvazkovou dokumentací, která popisuje, rozvádí a vysvětluje všechny technické, funkční a uživatelské aspekty díla. V  dnešní době, kdy programování již není „uměním“, ale je systematickou technickou disciplínou, se při tvorbě uživatelské dokumentace vychází nejen z chování vlastního programu, ale především z analytické dokumentace. Především z té lze snadno a spolehlivě zjistit logiku programu a kritická místa, na něž je nutno uživatele upozornit. Samozřejmě za předpokladu, že vytvořený systém svými vlastnostmi a chováním odpovídá analytickému popisu. Jednou vytvořená dokumentace může mít několikeré užití (pro technickou dokumentaci to nemusí platit zcela, pro uživatelskou dokumentaci to však platí úplně), např. může být vytiště-

na jako kniha, může mít elektronickou podobu, může být využita pro nápovědu atd.; text může být opakovaně použit s drobnými úpravami znění nebo i věcného obsahu pro různé varianty užití. Zdroj pro tvorbu dokumentace by proto měl být vytvořen v takovém formátu, který umožňuje snadné, spolehlivé a v co největší míře automatizované generování konečných formátů pro požadované užití. Tento cíl je dosažitelný, pokud je zdrojový text vytvořen strukturovaně s jasným a  jednoznačným označením struktur v  textu, např. jako XML text za použití XML WYSIWYG editorů. Takto vytvořenou dokumentaci lze pak snadno nejen transformovat pro různá užití, ale také udržovat a aktualizovat. Co se formy zpracování týká, dokumentace by měla ctít obecná gramatická pravidla, styl by měl být lehký, nikoli však nevázaný, stylistické konstrukce jasné a přehledné (snad jen s výjimkou tohoto textu), informační obsah hutný a účelný, nikoli účelový. Při tvorbě je nutno mít neustále na paměti, že dokumentace nesmí být jen formální součástí díla, ale že je to produkt navýsost důležitý a nutný pro provoz a užívání systému.

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

Cesta informačního systému Řešení Nástroj WOIS (Workflow Oriented Information System), který má potřebné vlastnosti, nasazuje společnost KOMIX již několik let pro zpracování velkého objemu dat ve velkých organizacích. Pro integraci dat aplikací používá WOIS rozhraní XML. Je to známá a osvědčená technologie, která se pro konstrukci rozhraní používá velice často.

n

e

r

v

e

Milan Číha, [email protected]

(například upozornění na překračování termínů apod.).

Rizika Známým rizikem při implementaci procesního řízení je přístup k datům integrovaných aplikací – podmínkou je kvalitní spolupráce jejich autorů. Toto riziko je však nutno akceptovat a řídit – jde o samotnou podstatu procesního řízení.

WOIS Každý větší informační systém (dál jen IS) je složitý mechanismus, na kterém je vidět postupný vývoj – vliv technologií, správce či dodavatelů. Čím je IS starší, tím větší množství kompromisů se v něm objevuje, tím více je konzervativnější, tím více bolí jakékoliv rozsáhlejší změny. Právě v takových případech jsou oceňovány nástroje a technologie, které umožňují postupný vývoj při zachování stávajících prvků IS. A  právě o takových nástrojích a technologiích je tento krátký příspěvek.

XML ROZHRANÍ

... integrované aplikace IS

Automatizace procesu se ve WOISu realizuje konfigurací workflow. Při tvorbě základní kostry workflow se nepoužívá žádný programovací jazyk – workflow je konfigurováno pomocí parametrů v metadatech. Pouze specifické funkce, spouštěné v jednotlivých stavech procesu je třeba programovat. WOIS nabízí také vyspělé řešení pro dynamickou tvorbu dokumentů – na základě XSL šablony a dat procesu lze generovat PDF dokumenty. Atraktivní a  užitečnou vlastností WOISu je také možnost zasílání elektronické pošty

Shrnutí Společnost KOMIX nenabízí nástroj WOIS – nabízí tvorbu řešení na míru. Za několik let práce s  WOISem si vychovala specialisty ve všech oblastech potřebných pro tvorbu aplikací v oblasti procesního řízení. Zákazník tak nedostává nástroj pro vývoj aplikace, ale již vytvořenou aplikaci komunikující pomocí webového prohlížeče. Proces ve WOISu integruje data, zajišťuje správný průběh jejich životního cyklu, tiskne potřebné dokumenty a upozorňuje elektronickými zprávami na významné události v procesu.

automatizace procesů

Procesní řízení Procesní řízení není jenom termín, jehož hvězda prudce zazářila a zase rychle pobledla. Důvodem pomíjivosti byl možná chybný přístup – většinou není možné zavádět workflow technologie pro podporu procesního řízení „na zelené louce“ bez ohledu na velké množství investic do existujících aplikací a jejich dat. Procesní řízení je možné chápat jinak – především jako dobrou myšlenku, ke které se lze přibližovat postupnými jednoduchými kroky. Jaké jsou požadavky? Postupné sjednocení aplikací (jejich dat) a automatizace procesu zpracování dat, která je třeba mezi aplikacemi vyměňovat (úplná automatizace životního cyklu dat). Obsahují-li integrované aplikace dostatek informací potřebných k rozhodování v průběhu procesu, lze zcela automatizovat významnou část aktivit v  procesu, omezit zásahy obsluhy a tím celý proces významně zrychlit.

WOIS zasílání zpráv

generace dokumentů

integrace dat

Závěr

formalizovaný přenos dat ❑

v aplikacích IS

❑

procesy mezi aplikacemi IS

procesy

v

ě

t

ě

IT

Business Intelligence – nástroj konkurenceschopnosti podnikání Pavel Seibert, [email protected] Business Intelligence (dále jen BI), 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.

Historie IS Zárodek IS (tvorba dat v elektronické podobě) je už v  prvním stádiu – izolovaných aplikacích (specializované izolované aplikace, MS-Office, ...). Zároveň přicházejí první (obvykle špatné) zkušenosti (většinou s pracnou správou). Zkušenosti vedou provozovatele IS ke snaze o integraci. Prvním krokem bývá nákup víceuživatelských aplikací. Ty do značné míry omezí přenos dat osobním stykem, telefonováním a elektronickou poštou a často kladou důraz na tvorbu strukturovaných dat. Tím dojde ke sjednocení formátů dat v oblasti, kterou aplikace pokrývá. Vznikly tedy ostrůvky automatizace na vyšším stupni vývoje, ale stále to ještě není ono – občas musí data „utéci“ z aplikací, „potulují“ se mimo ně a opět (ručním vstupem) do jiných aplikací „pronikají“. Důvodů k nespokojenosti je několik – ztráta času, kvality a někdy i dat samotných. Co dál?

s

Zákazník získá následující výhody: • vedoucí pracovníci řeší převážně výjimky (nikoli běžné situace) • řadoví pracovníci mají přehled o  úkolech a jejich prioritách • koncový odběratel služby, kterou zákazník dodává, je informován o stavu zakázky, získává řešení dříve a ve zvýšené kvalitě WOIS může obohatit data o časové a stavové údaje. Taková data se pak hodí pro statistické zpracování nástroji BI (Business Intelligence). Statistické zpracování umožňuje vyhodnocení dat procesu (počty zakázek, délky odezev, počty nestandardních situací) a  jeho zlepšení a  tím dává podklady pro manažerská rozhodnutí.

Úvodem si pro účel tohoto článku dovolím upřesnit vymezení pojmu BI. Přesto, že se s tímto pojmem setkáváme stále častěji, je jeho obsah mnohdy chápán odlišně. Z mnoha významů anglického slova business vybereme výraz podnikání. Pod pojmem intelligence pak nadále uvažujme prostředí a v něm realizovaný nástroj pro podporu rozhodování. Po sjednocení můžeme provést určité zjednodušení a nadále rozumět pod pojmem BI nástroj pro podporu konkurenceschopnosti podnikání. V  souladu s  vymezením pojmu BI se změnil i  přístup k  problematice samotné. Zdaleka již není ze strany IT firem nutné tak velkého úsilí v oblasti přesvědčování zákazníků o výhodnosti BI řešení, jako tomu bylo v nedávné minulosti. Naopak, stále častěji se setkáváme s  aktivním zájmem ze strany firem či institucí. Zdálo by se, že tato situace je pro dodavatele BI bezmála ideální. Pro kvalitní realizaci takovýchto aktivních přístupů je však třeba věnovat pozornost mnoha oblastem. V následujícím textu se zmíním o některých z nich, které mají obecnou platnost.

Zaměření BI. Kvalitní BI řešení by zcela jistě mělo co nejvíce splňovat požadavky, citované prakticky ve všech publikacích k dané problematice. Uveďme alespoň ty nejdůležitější. Poskytnout uživateli řešení a  současně i  nástroj. Dodržení této zásady umožní, aby uživatel nebyl pasivním prvkem, žádající po někom dalším realizaci svých požadavků, ale aby měl k dispozici prostředí pro přímou realizaci svých požadavků. Uživatel se stává aktivním tvůrcem. Strukturovaná data a  následně i  informace. Správné BI řešení musí být nástrojem pro přeměnu dat na informace. Otevřenost řešení. Otevřenost musí být podporována jak co do struktury dat tak co do rozsahu. Všechny části řešení tak musí co nejvíce podporovat schopnost dynamických změn řešení jako celku. Klasickým záměrem BI řešení je poskytnutí vybraných dat ve vhodně strukturované podobě pro podporu přehledových údajů, analytických výstupů, realizaci ad-hoc dotazů, dolování dat, sledování trendů, vývojových řad a  podobně. Pro tyto oblasti jsou požadovány údaje ze zdrojových provozních IS, včetně údajů archivních a historických. V souladu s neustále se zvyšujícími možnostmi HW a SW se však stále častěji ukazuje možnost a výhodnost pokrytí některých typů výstupů, které byly dříve realizovány výhradně v prostředí provozních IS.

Požadavky na BI. Přehnaná očekávání. Výše zmíněné rozšíření možností BI řešení je pro zadavatele záležitost velmi příjemná a žádoucí. Tento široký záběr v sobě skrývá jisté záludnosti. Krátce se pokusím popsat některé základní. Požadavky. Pro úspěšnou realizaci BI řešení je základním předpokladem definice požadavků, které by měly být pokryty. Jak bylo uvedeno výše, záběr BI je v současné době velmi široký. Při

3

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

pokračování ze strany 3

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žňují 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í.

středí PD a následně do navazujících struktur DWH. Objem dat. Tato oblast bývala v minulosti, v době podstatně menších možností HW a systémového SW, často kritickou částí řešení. Je třeba si uvědomit, že účelně navržené struktury DWH často bývají rozsáhlejší, než struktury zdrojových IS. V prostředí PD jsou vytvářeny kopie vybraných údajů provozních IS, včetně údajů archivních a historických. Pro pokrytí požadavků na rychlou odezvu jsou v prostředí DWH vytvářeny potřebné agregované struktury. Uživatelské požadavky. Architektura BI řešení je otevřená také z hlediska uživatelských požadavků. Jak bylo výše zmíněno, nabízí se realizace BI řešení po jednotlivých částech, které pokrývají rozdílně zaměřené skupiny uživatelských požadavků. Při definování nových požadavků lze s výhodou vycházet z realizovaných částí a maximálně využít již realizovaných datových struktur a příslušných částí řešení.

Otevřenost BI řešení.

Závěrem …

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 pro-

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

Bezpečnostní mechanizmy v platformě .NET Martin Janček, [email protected] Na bezpečnost aplikací je kladen čím dále větší důraz a je zapotřebí tuto oblast řešit již na počátku každého projektu. Platforma Microsoft .NET nabízí vývojářům větší podporu ovládání nastavení bezpečnosti aplikací než bylo kdy předtím v produktech firmy Microsoft zvykem. Můj příspěvek si nebere za cíl objasnit všechna zákoutí nastavení bezpečnostních mechanizmů při vytváření aplikací na platformě Microsoft .NET. V  tomto příspěvku bude popsáno, čím nám tato platforma pomůže při vytváření bezpečných aplikací. Řekneme si něco o základních aspektech, které by měla bezpečná aplikace splňovat. A na úplný závěr si podrobněji rozebereme jeden z  mechanizmů, se  kterým se můžete setkat při vytváření vašich řešení. Když se mi poprvé dostal do „ruky“ Microsoft .NET Framework a při studiu nových tříd jsem objevil, jak veliký prostor je věnován bezpečnosti pro aplikace psané v tomto prostředí a neméně i samotné bezpečnosti kódu, byl jsem velmi překvapen. Programátoři, kteří v té době vyvíjeli svá řešení povětšinou v klasickém C/C++, se mnou budou jistě souhlasit, jak lehce je možné v tomto novém prostředí řídit bezpečnost kódu, ale i  celého dodávaného řešení. Někdo může namítnout, že na úrovni Windows API, nebo nějakého rozšiřujícího SDK jsou všechny tyto funkce také k dispozici, ale až v .NET Framework a technologiích, které jsou postaveny nad tímto rámcem, máme všechno integrovaně dosažitelné. Typickým případem, kdy uživatel vyžaduje důkaz o bezpečnosti kódu, je v současné době nedozírný prostor Internetu. Představte si, že máte aplikaci, která je napsaná v prostředí .NET Framework. Tato aplikace zjistí, že má k dispozici novou funkcionalitu, a tu se pokusí stáhnout právě z Internetu. A tady nastává “malý“ problém. Jak můžeme vědět, že daná funkcionalita,

4

která je stahovaná z Internetu, je důvěryhodná? Odpovědí je, že v operačním systému lze nastavit zásady pro zabezpečení, které určují, jaké oprávnění se danému kódu přidělí. Toto zabezpečení vychází z míry důvěry, kterou pro daný kód určíme, a lze ho nastavit v prostředí MMC konzoly, která je integrální součástí operačního systému. Pokud je tato důvěra omezena nějakou sadou oprávnění, tak se tato aplikace spouští v omezeném prostředí, které jí umožní jenom to, co jsme definovali. Řekneme si, na čem je tato koncepce postavena. • Kódové skupiny – slouží k tomu, aby určily kód s podobnou charakteristikou. Tato skupina má jenom jednu podmínku pro členství. Jako nejčastěji používaná podmínka pro členství je tzv. Zóna, která určuje, odkud kód pochází. Specifikovat lze tyto zóny: Tento počítač, Internet, Místní internet, Důvěryhodné servery a nakonec Nedůvěryhodné servery. • Sady oprávnění – definují akce, které může kód, který je zařazen do jednotlivých kódových skupin, vykonávat. Typicky se tady definují oprávnění pro přístup k souborům, nebo k možnosti ovládat uživatelské rozhraní a jiné. Jak takové zabezpečení pro platformu .NET Framework funguje? První podmínkou je, že důvěřujeme běhovému prostředí, které tyto zásady vyžaduje. Tady si je nutno říci, že zásady řízení bezpečnosti se nevztahují na aplikace, které nebyly napsány v prostředí .NET Framework. Toto prostředí je již součástí operačního systému Windows XP. Představme si, že kód, který je právě spuštěn, vyžaduje specifická oprávnění pro přístup k souboru na disku. Běhové prostředí zjistí prostřednictvím průchodu zásobníku volajících, že jak volající tak i všichni v daném řetězci mají právo pro danou operaci. Když jsem

se zmiňoval o  tom, že se zjišťují všichni volající, měl jsem na mysli třeba případ, kdy existuje důvěryhodná část kódu, kterou však volá nedůvěryhodná aplikace. A právě tady by nastal problém. A proto, i když můžeme mít dojem, že takto postavené ověřování je pomalejší, tak musíme přiznat, že je bezpečnější. Zabezpečení přístupu ke kódu není jediným mechanizmem, který vám tato platforma poskytuje. Další neméně důležitou vlastností, kterou můžete využít, je zabezpečení postavené na rolích. S  tímto zabezpečením se pravděpodobně setkáváte nejčastěji při své každodenní práci. Toto zabezpečení vám umožní dle členství uživatele v některé z rolí efektivně omezit přístup k vámi definovaným prostředkům. Příkladem může být webová aplikace, která poskytuje komplexní řešení pro malou firmu. Tady je na místě umožnit uživatelům této aplikace přístup jenom k těm zdrojům, na které mají právo. Tohoto dosáhneme rozdělením uživatelů do rolí a definováním přístupových práv, které umožní v aplikaci přístup jenom k tomu, k čemu má uživatel oprávnění. Ideálním řešením takovéto aplikace může být intranetový web, který pracuje s účty systému Windows 2000 a vyšším a lze ho jednoduše integrovat do prostředí Windows autentizace. Tady stojí za to si vysvětlit, jakou podporu pro programátory, kteří chtějí psát aplikace postavené na rolích prostředí, .NET Framework poskytuje. Tato platforma má možnost dotázat se na uživatele, v  jehož kontextu je daná aplikace spuštěna. Základním kamenem, o který se může programátor opřít, je tzv. Principál. Tento objekt poskytuje identitu uživatele a lze se ho dotazovat na členství v rolích. Principál je jako většina základních objektů tvořen rozhraním, a proto je ho možné jednoduše předefinovat. V našem prostředí jsou již některé objekty pro programátory dopředu připraveny a lze je použít. Typic-

kým příkladem je WindowsPrincipal, který nám poskytne základní údaje o aktuálním účtu přihlášeného uživatele. Jistě mi dáte za pravdu, že možnost snadného přístupu k identitě uživatele a jeho členství v rolích jsou užitečné při rozhodování, které operace danému uživateli povolíme a které zakážeme. Zatím jsme si přiblížili možnosti, které nám nabízí objekt Principál. Teď bychom se blíže podívali, jak je možné takovou jednoduchou bezpečnost založenou na rolích implementovat. V  tomto jednoduchém kódu si ukážeme, jak může programátor přistoupit k  jednotlivým již výše zmíněným objektům a ukážeme si novou vlastnost, kterou můžeme využít při programování v .NET Framework, a to deklaraci pomocí atributů.

static void Main(string[] args) { // Nastavíme politiku AppDomain.CurrrentDomain.SetPrinc ipalPolicy(PrincipalPolicy. WindowsPrincipal); try { // Voláme metodu, kde deklarujeme deklarativní zabezpečení DelejNeco(); // Voláme metodu, kde testujeme zabezpečení sami DelejNecoEx(); } catch (SecurityException e) { Console.WriteLine(e.Message); } } [PrincipalPermissionAttribute(Secu rityAction.Demand, Role = „Administrators“)]

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

pokračování ze strany 4

static void DelejNeco() { System.Console.WriteLine(„Jsem v roli Administrators“); } static void DelejNecoEx() { IPrincipal ptrIPrincipal = Thread.CurrentPrincipal; if (null != ptrIPrincipal && ptrPrncipal.IsInRole(„Adminis trators“)) { System.Console. WriteLine(„Jsem v roli Administrators“); } V tomto krátkém přikladu je zobrazeno volání dvou metod, které přistupují k ověření uživatele a jeho možnosti vykonat nějaký kód dvěma způsoby. V první metodě jsme použili ověřování pomocí atributů. Toto je velmi jednoduché pro počet úhozů do klávesnice, avšak osobně dávám v tomto případě přednost klasickému rozhodovacímu kódu, který je použit v druhém případě. Tímto úvodem, který nám vysvětlil základní možnosti platformy .NET, se přesouváme do prostředí, po kterém se přímo vyžaduje, aby v něm fungovaly výše zmíněné principy. Toto prostředí se jmenuje ASP .NET a slouží nám pro psaní webových aplikací. Řekněme si, co by takovéto aplikace měly dle úrovně bezpečnosti implementovat. • Autentizace – slouží k určení o jakého uživatele se jedná. Procedura, která řeší autentizaci, se vlastně ptá, kdo chce pracovat s vaší aplikací. • Autorizace – když jsme již vyřešili autentizaci, je nutné určit, na které operace a k jakým zdrojům bude mít daný uživatel přístup. Tyto dva body, které jsme si objasnili, jsou jenom základem toho, co by mohlo být na bezpečnou aplikaci kladeno. Mezi dalšími můžeme uvést požadavky Utajení a Integrita. Ne vždy je však vyžadován utajovaný přenosový kanál a  digitální podpis pro zabezpečení integrity dat. Jistě se však setkáte s jedním ze čtyř typů autentizace. • Formulářová autentizace. • Windows autentizace. • Passport autentizace. • Vaše vlastní autentizace.

Všechny tyto způsoby zabezpečují fakt, že aplikaci umožní určit dle nějakých přihlašovacích údajů, například jména a hesla, identitu uživatele. Při každém dalším požadavku, který přijde od uživatele, je jeho identita známa. Příkladem je Windows autentizace, která používá pro identifikaci uživatele 96bitové číslo známé jako SID. Dalším příkladem je vydávání tiketů, které se využívají v Formulářové autentizaci, a které jsou kombinací hodnot v cookie. Než se budeme blíž věnovat autorizaci, tak si musíme říci, že existuje i možnost “změny identity”. Určitě vám to zní mysticky, ale nehledejte v tom nic záhadného. Jistě jste se setkali s potřebou přistoupit například k databázovému zdroji pod jinou identitou než má právě přihlášený uživatel. Je to vůbec možné, a pokud ano, jak toto můžeme zabezpečit? V prostředí platformy .NET nám k tomu slouží mechanizmus nazvaný jako Impersonalizace. Právě pomocí něj je nám umožněno vykonávání činností kódu, nebo přístup ke zdrojům pod identitou jiného uživatele. Tohoto mechanizmu rádi využijeme při přístupu i k jiným než databázovým zdrojům, jako jsou například soubory. Tímto jsme se dostali až k procesu Autorizace, která slouží k stanovení práv, které omezují autentizovaného uživatele. Pro vysvětlení můžeme použít jednoduchého příkladu, na kterém si vysvětlíme, co to autorizace je. Představme si, že se v našem městě koná vývojářská konference, na které bude přítomen i významný host. Této konference se chceme zúčastnit, a proto se na ni přihlásíme. Bohužel jsme si nevšimli, že ve formuláři pro přihlášení existuje možnost vyslechnout si daného hosta, kterou však explicitně musíme zvolit. Po příchodu na danou akci bude ověřena naše identita (budeme autentizováni) a následně dostaneme visačku pro přístup na konferenci. Rádi bychom si vyslechli již zmiňovaný proslov, a proto začneme hledat konferenční sál, kde bude tento host vystupovat. Avšak chyba lávky, ještě než můžeme do tohoto sálu vstoupit, tak personál ověřuje naši visačku a přitom se zjistí, že “nejsme zváni”. Tento právě popsaný příklad, můžeme nazvat autorizací, která je založená na základě rolí. Tato autorizace tedy není založená na základě toho, kdo daný uživatel je, ale na roli, kterou má uživatel nebo skupina, ke které přináleží, přiřazenu. V našem případě jsme tedy nebyli v roli uživatele, který se může zúčastnit proslovu tohoto hosta, ale ostatní akce na konferenci nám byly zpřístupněny. Jak to tedy všechno společně funguje, to prezentuje obrázek, na němž si ukážeme přístup k jedné z webových stránek, která vyžaduje jak autentizaci, tak i autorizaci.

ANO požadavek k přístupu na zdroj

ověření autentizace

nějaká akce

NE

ANO ověření autorizace

NE

zdroj

nějaká akce

Přístup k chráněnému zdroji, který vyžaduje autentizaci a autorizaci

Když už máme jasno v základních pojmech, tak si představíme Windows autentizaci, při které lze využít již stávajících účtů Windows. Tato autentizace není přímo implementována v ASP.NET, ale spoléhá na webový server IIS, který si při dotazu uživatele ověří údaje, které mu zaslal prohlížeč oproti uživatelským účtům Windows. Dojde-li k úspěšnému ověření, tak je žádost uživatele povolena a informace o identitě uživatele jsou předány výkonnému kódu ASP.NET. Výhody použití tohoto řešení spočívají v nenáročnosti implementace integrace s uživatelskými účty a použití impersonalizace. To, že jsme prezentovali možnost využít uživatelské účty Windows jako výhodu, se může při některém požadovaném řešení jevit jako nepřekonatelný problém. Takže na použití tohoto principu v Intranetu můžeme rovnou zapomenout. Aby to však nebylo tak jednoduché, musíme si říci, že existují tři mechanizmy předání identity, ze kterých si můžeme vybrat, když jsme se rozhodli použít tento typ autentizace. • Základní autentizace – uživatelské jméno a heslo jsou předány jako otevřený text. • Digest autentizace – místo otevřených údajů se posílá jejich hodnota ve formě hash. • Integrovaná autentizace – identita se předává ve formě tokenu. Z výše uvedených se krátce zastavíme u integrované autentizace, která je nejvhodnější pro intranetové řešení. Komunikace mezi klientem a webovým serverem je založena na zaslání identifikačního tokenu, kterým se klient po požádání webového servera autentizuje. Pokud tento server dle zaslaného tokenu není schopen ověřit danou identitu, tak se klientovi následně objeví dialogové okno, kde je umožněno uživateli zadat pomocí jména a hesla identitu novou. Následně vše proběhne totožně tak, jak již bylo popsáno výše. Klientem v tomto popisovaném příkladu je IE, jehož integrovanou součástí je zobrazování uživatelského dialogu pro přihlášení.

U použití klientů IE, kteří pracují s tímto druhem autentizace, je však třeba mít na paměti, že ne každá verze toto umí. V  materiálech Microsoftu se lze dočíst, že již od verze IE 2.0 se tato vlastnost vyskytuje. Avšak neměl jsem to možnost vyzkoušet. Jako protokol pro přenášení údajů uživatele může být využit NTLM nebo Kerberos. Vše závisí na použití verze operačního systému klienta a serveru. Pokud se rozhodnete pro Kerberos, tak počítejte s klientem, který běží na Windows 2000 a vyšším a server je zapojen do domény Active Directory. Jako vhodné řešení se nabízí použít na straně serveru Windows 2003 s již integrovaným IIS, který představuje webový server. I tady však nesmíme zapomenout upravit nastavení IIS pro podporu protokolu Kerberos. Pokud jste zabezpečili vše, aby daná autentizace mohla za podpory protokolu Kerberos probíhat, je možné konfigurovat vrstvu ASP .NET. Aplikace psané pro tuto technologii využívají konfigurační soubor, který je formátu xml a jmenuje se web.config. Pomocí nastavení v tomto souboru řídíte mimo jiné i způsob autentizace. Jak toto v  konfiguračním souboru nastavím, můžete vidět dále.

<system.web> Když máme nastavené celé vývojové prostředí, můžeme využít všech mechanizmů ověřování, které jsme již ve výše uvedeném textu probrali. Na samém konci tohoto příspěvku lze říci, že požadavky na zabezpečení vašich řešení a jejich implementace v  prostředí .NET Framework a  jeho nadstaveb jdou v  současné době ruku v ruce. I nejnovější trendy, jako je příklad potřeby zabezpečení komunikace webových služeb, lze najít jako součást dodávaných vývojových kitů s jednoduchou integrací do vašich řešení.

Vývojová, školicí, testovací a provozní prostředí u zákazníků Při přípravách vývojových, školicích, testovacích a provozních prostředí pro naše aplikace se u  zákazníků setkáváme s  různými přístupy. Článek si klade za cíl tyto přístupy stručně popsat, poukázat na jejich výhody a nevýhody a nabídnout tak čtenáři určitý přehled a možnost zamyšlení. Úmyslně se nevěnuje prostředím u dodavatele, protože tato prostředí mají své zvláštnosti.

Co je co Vývojové prostředí – prostředí určené především pro vývojáře ke zkoušení na datech, která zákazník nemůže poskytnout mimo svou firmu, a k předvádění připravovaných novinek v aplikaci tak, aby je zákazník mohl potvrdit nebo připomínkovat již v ranném stádiu vývoje a nikoliv až po jejich úplném dokončení a předání k  testování. Neočekává se, že vše bude bezchybné. Školicí prostředí – prostředí určené na školení pro práci s aplikací. Akceptační testovací prostředí – prostředí, které slouží pro převzetí aplikace zákazníkem. Testovací prostředí – prostředí určené především pro testy úprav, ke kterým má dojít

v provozním prostředí. Instaluje se do něj jako do předposledního a  je to poslední možnost zachytit chybu před nasazením aplikace do provozního prostředí. Provozní prostředí – prostředí, v němž pracují uživatelé s reálnými daty. Instaluje se do něj jako do posledního po ověření v testovacím prostředí.

Kompromisy Ideální stav je samozřejmě takový, že všechna prostředí jsou shodná. To ovšem není reálné kvůli velkým a neefektivně využitým nákladům, které by pořízení a provoz všech těchto prostředí znamenaly. Hledání kompromisů umožňujících úspory záleží do značné míry na požadavcích na spolehlivost jednotlivých prostředí a na bezpečnost. Někteří zákazníci si chtějí všechno instalovat sami z dodaných instalačních médií podle příslušné dokumentace, jiní požadují veškeré instalace od dodavatele a sami instalaci ani nechtějí umět. Vývojové prostředí: Vzhledem k určení nevadí jeho nižší výkonnost. V porovnání s ostatními prostředími může

Jiří Malý, [email protected]

tedy obsahovat pomalejší procesory i  jejich menší počet, menší paměť i  diskový prostor, zálohování není kritické.

mentování zadají nesmyslně náročnou akci a na delší dobu nejen sobě, ale i ostatním znemožní rozumnou práci.

Školicí prostředí: Nižší výkonnost může, ale nemusí vadit. Zde velmi záleží, kolik osob se má školit zároveň a jestli jsou přijatelné pomalejší odezvy. Aplikace by měla být stejná jako na provozním nebo akceptačním testovacím prostředí (podle toho, na co je uživatel školen). V porovnání s provozním prostředím lze počítat se značně menším počtem uživatelů, takže postačí méně paměti a  menší diskový prostor. Zálohování není kritické, pokud nehrozí poškození systému (typické při školení administrátorů, kdy naopak je zvýšené riziko poškození instalace a je žádoucí možnost rychlé obnovy do výchozího stavu). S ohledem na typický průběh školení, kdy obvykle uživatelé dělají stejnou akci zároveň, je třeba posoudit, zda a do jaké míry je možné zmenšit v porovnání s provozním systémem počet a rychlost procesorů, použít server s pomalejšími dalšími součástmi (rychlost sběrnic, pamětí apod.). Za připomenutí snad stojí poměrně běžný jev, kdy uživatelé při experi-

Akceptační testovací prostředí: Nevadí mírně nižší výkonnost. Uživatelů je málo. Kritické nejsou ani odezvy, uživatelé již aplikaci znají a nedělají neúmyslné výkonnostně náročné akce. Obvykle tedy postačí méně i pomalejších procesorů než v provozním prostředí, menší paměť, diskový prostor, pomalejší další součásti (rychlost sběrnic, pamětí apod.). Důležité a  často nedoceňované je zálohování. Pro testování je důležitá možnost vrátit se k nějakému stavu, především kvůli otestování opravy nějaké chyby. Pokud tato možnost chybí, může být náročné vytvořit nová testovací data a může se snížit průkaznost testu (testuje se nad jinými daty a mohla být opravena jiná chyba – ano, i to se občas stane). Testovací prostředí: Mělo by být shodné s prostředím provozním. Na provozním prostředí by se měly dělat jen ty kroky, které se nejdříve odzkoušely v testovacím prostředí. Bohužel jsem se setkal i s tím,

5

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

pokračování ze strany 5

že zákazník u delšího projektu nejen několikrát změnil cílovou konfiguraci, ale i pro testování použil jiný než cílový hardware a software. Testy proběhly v pořádku, ale po instalaci do provozního prostředí aplikace nefungovala. Jak se ukázalo, příčinou byla jiná verze (update) softwaru třetí strany, která se chovala jinak. Z  hlediska zálohování je důležitá možnost obnovy, která by měla být možná ze záloh provozního systému. Pokud je testovací prostředí shodné s prostředím provozním, lze na něm spouštět např. i zátěžové testy, které poskytnou velmi hodnověrné výsledky, aniž by bylo nutné omezovat užívání provozního systému. Zároveň může v případě velké havárie provozního prostředí posloužit i  jako jeho plnohodnotná náhrada.

Ne všechny výše zmíněné činnosti se dělají stále. Bývá tedy možné použít jednu instalaci aplikace na jednom serveru pro více činností a  používat ji střídavě jako vývojovou, školicí a/nebo akceptačně testovací. Další možností je mít více instalací aplikace (instancí) na jednom serveru. Platí to však jen pro aplikace, které je možné konfigurovat, aby běžely vzájemně nezávisle (na jiných portech apod.). Výhodou je, že příslušná prostředí běží na stejném hardwaru. Nevýhoda je zřejmá a  vyplývá ze sdílení serveru – jednotlivá prostředí se navzájem ovlivňují a přetížení nebo dokonce pád systému způsobené jednou instancí zpomalí nebo dokonce přeruší běh ostatních instancí. Pro vývojové, školicí a akceptačně tes-

tovací prostředí to může být přijatelné riziko. Mnoho zákazníků, a  kupodivu jsou to i finanční instituce, nemá testovací server a po akceptačním testování se instaluje rovnou do provozního prostředí. Pak se instaluje s vědomým rizikem, že může dojít k chybě a odstávka provozního prostředí se protáhne. Tento přístup považuji už spíš za hazard než jen riziko a nedoporučuji jej. To už je lepší přistoupit i na serveru pro provozní systém k instalaci druhé instance aplikace (na jiných portech atd.) a tu používat jako testovací, přestože je tu možnost vzájemného ovlivnění obou instancí aplikace. Pokud již byla aplikace akceptována, riziko, že testovací instalace významněji naruší chod provozní instance, je malé.

Závěr Jak je zřejmé, možností uspořádání je mnoho a vhodnost či nevhodnost toho kterého přístupu se v jednotlivých projektech i zákazník od zákazníka velmi liší. Za nejdůležitější zásady lze považovat používání alespoň podobných (srovnatelných) platforem pro všechna prostředí z hlediska hardwaru, operačního systému a softwaru třetích stran a instalaci vzájemně si odpovídajících jejich updatů.

Performance Engineering není jen testování Dan Petřivalský, [email protected] „Maximalizace výkonu“ je heslem dneška, samozřejmě při stejných nebo ještě lépe menších nákladech. V  cyklistice je cestou k  vyšší „performance“ transfuze vlastní krve, v atletice hrstička tabletek s analogickými stereoidy. V IT se (v tomto případě povolený) doping jmenuje Performance Engineering. Všechny tři případy jsou založeny na vědeckých postupech, ale KOMIX se zabývá pouze třetí z uvedených. Definicí, co už je a co ještě není Performance Engineering, je mnoho, všechny však mají společnou myšlenku, že Performance Engineering pokrývá celý životní cyklus softwaru. Performance Engineering začíná už ve fázi návrhu architektury a končí (pokud vůbec lze říct, že někdy končí) u monitorování a analýzy každodenního provozu. Vždy se jedná o systematický proces plánování, vyhodnocování a zlepšování. Naštěstí jsou dnes k  dispozici softwarové nástroje, které jednotlivé fáze Performance Engineeringu usnadňují.

Fáze návrhu Pro uspokojivou výkonnost aplikace je nejdůležitější správně zvolená architektura celého systému. Aby mohla být navržena dostatečně výkonná architektura aplikace, je zapotřebí znát (pokud možno) veškeré požadavky na systém. Důležité jsou jak funkční, tak výkonnostní požadavky. Požadavky a tím pádem i aplikace se budou v čase měnit a vyvíjet, ale základní architektura je neměnná, respektive zásahy do ní jsou velmi bolestivé. Je to podobné jako zásahy do základů domu. Když si po roce bydlení vzpomenu, že nutně potřebuji sklep, se kterým projekt nepočítal, bude to stejně špatné, jako když stejný „objev“ učiním „už“ ve fázi dokončování příček v podkroví. Architekti ve stavebnictví mají k dispozici různé CAD nástroje, které velmi plasticky namodelují budoucí novostavbu, takže onu větu: „Ještě bych tam chtěl sklep, prosím!“, je možné pronést už v dostatečně „bezpečné fázi“, kdy dům existuje pouze na obrazovce počítače. Softwarový architekt má možnosti modelování „výkonnosti“ v této fázi značně omezené a často bývá rozhodnutí o výrobci serverů, databázového stroje, aplikačního serveru, webového serveru, programovacím jazyku (či jazycích) atd. učiněno spíše na základě politických či obchodních argumentů než v zájmu optimální výkonnosti za dostupné finanční zdroje. Hodně záleží na datovém modelu, zvolené vývojové technologii a spoustě dalších zdánlivých drobností. Naši experti za 14 let působení firmy nasbírali spoustu zkušeností, které dokáží zužitkovat již ve fázi návrhu a tím položit dobré základy pro dostatečnou „performance“.

Fáze vývoje Při vývoji, rozumí se vlastním programování, se už pouze realizuje návrh. Realizace může být

6

lepší, či horší, tedy výkonnější=rychlejší, nebo ta druhá. Změřit si, jak rychlé jsou jednotlivé komponenty systému, pokusit se je zlepšit=zrychlit za rozumnou cenu už možné je. Dokonce existuje i řada celkem uspokojivých nástrojů, které jsou zadarmo. Bohužel v běžném životě se častěji zrychluje vývoj a opravy aplikací, namísto zrychlování aplikací samých. Přitom při správně provedeném návrhu je už v této fázi jasné, které komponenty systému by měly být optimalizovány z výkonnostního hlediska více a u kterých není výkon tak podstatný. Naši programátoři si sami otestují výkonnost jimi vyvíjených komponent a neopováží se předložit je testerům, natož zákazníkovi, aniž by byly patřičně vyladěné. Dobrým pomocníkem jim v tom je CA/Wily Introscope, resp. LeakHunter.

Fáze testování Jestliže aplikace už je k dispozici celá, jsou splněny (implementovány) veškeré funkční požadavky, hardware byl dodán, můžeme se začít věnovat testování aplikace z  pohledu, požadavků na výkonnost. Vše je nainstalováno, někdy v laboratorních podmínkách, jindy na skutečném produkčním prostředí, úkolem je ověřit, že jsou splněny i výkonnostní požadavky. Požadavek specifikující výkonnost aplikace zpravidla bývá popsán maximálním časem na provedení nějaké akce (interaktivní nebo neinteraktivní) za předpokladů, jako jsou počet záznamů v databázi, počet současně přistupujících uživatelů a některé další. Vyzkoušet si a změřit rychlost neinteraktivní akce zvláště pokud nezávisí na počtu právě pracujících uživatelů není velký problém. Mnohem obtížnější je provést věrohodné měření, jaké jsou odezvy aplikace, pokud s ní soustavně pracuje několik stovek nebo tisíc uživatelů, zákazníků, návštěvníků webu … K simulaci jejich činnosti je potřeba použít nějaký, k tomu určený nástroj. Opět je možné najít (někdy i skutečně použít) nejeden freeware. Pokud by se nemělo jednat o  čistě pokusný stress test, ale o zátěžové testování dle zásad Performance Engineeringu, je nutné sáhnout po prověřeném komerčním produktu pro zátěžové testování. Ve společnosti KOMIX s úspěchem používáme Mercury LoadRunner, který na rozdíl od jednoúčelových „udělátek“ pokrývá řadu platforem a disponuje škálou monitorů pro podrobné sledování aplikace pod zátěží. Freeware často zvládnou pouze měření délky trvání definovaného programového úseku. Navíc příprava skriptů pro LoadRunner je mnohem komfortnější a rychlejší než u freewarů, což se výrazně projeví zvláště při jejich dlouhodobé údržbě. Ucelené uživatelské transakce pro skriptování jsou vybrány s  ohledem na očekávanou charakteristiku využívání aplikace, vytváří se zjednodušený model chování aplikace. Připraví se testovací data, nastaví systémové a aplikační monitory, aby nebyla sledována pouze celková doba odezvy aplikace, ale aby bylo možné

získat informace nutné pro následné ladění výkonnosti celého systému. Při ladění často stačí změnit nastavení hodnoty parametru operačního systému nebo middlewaru a výkonnost systému jako celku je do značné míry ovlivněna. Někdy se jedná o procentuální zlepšení, často o zlepšení v řádu desítek procent a nezřídka i o zlepšení o stovky procent. Několikanásobné zlepšení je jistě dobrá zpráva, ale také svědčí o  zanedbání Performance Engineering ve fázích předcházejících. Obvyklé „vycpeme to železem“, pak nemusí být vůbec aplikováno. Nehledě na dodací lhůty hardwaru je značně jednodušší „pokus-omyl“ přístup v případě systémové proměnné než v případě, doplňování procesorů, pamětí, atd. Model chování systému při zátěžovém testu je vždy do určité míry zkreslen. Míra zkreslení závisí na přesnosti vstupních informací pro přípravu dat a výběr transakcí a také na srovnatelnosti testovacího prostředí s prostředím produkčním. Není-li možné testovat na produkčním prostředí je nutné „přepočítat“ odladěné nastavení a konfiguraci testovacího prostředí na prostředí produkční. Ve světě se využívá kapacitní modelování (Capacity Planning). Nástroj umožňující extrapolovat naměřené hodnoty pro testovací prostředí na předpokládané produkční prostředí je založen na znalosti chování serverů, aplikačních serverů, databází, … Nástroj modeluje, jak se bude systém chovat, jestliže bude do clusteru přidán další uzel, nebo naopak jestliže bude hardware nahrazen jiným, třeba od jiného dodavatele.

Fáze produkční Až do této fáze byly všechny zásahy v rámci Performance Engineering prováděny na základě modelů, simulací a někdy i intuice. V produkční fázi už je možné sledovat skutečný život aplikace, trendy jednotlivých charakteristik systému, nejen výkonnostních. Požadavky na výkonnost aplikace jsou právě tou „požadovanou úrovní služeb“, která má být garantována provozovatelem systému. Provozovatel aplikace pak má dostatečnou motivaci neopouštět Performance Engineering ani po úspěšném uvedení aplikace do rutinního provozu. Jestliže SLA je založeno na měření dostupnosti služby, nikoliv na dostupnosti prvků infrastruktury, získává uživatel fungující systém a nikoliv lakonickou odpověď operátora helpdesku, že nechápe, na co si stěžuje, vždyť všechno jede. Námi preferovaným nástrojem pro sledování aplikací z pohledu uživatele a dalších systémových a aplikačních metrik je Mercury Business Availability Center. Nástroj sleduje vybrané metriky nad celým systémem tak, aby bylo možno včas identifikovat počínající zhoršování výkonnosti a předcházet dopadu na uživatele, při překročení prahových hodnot upozorňuje zodpovědné pracovníky či přímo spouští opravnou akci, sleduje SLA postavené na dostupnosti

aplikací pro uživatele. Hodnoty získané z produkčního monitorování mohou být, stejně jako měření ze zátěžových testů použity jako vstupy pro kapacitní modelování, při plánovaných rozšířeních a upgradech systému. Model založený na těchto datech je přesnější a predikce spolehlivější. Nástroje, které jsem v  textu zmínil a  které nám umožňují služby Performance Engineeringu poskytovat, na svých projektech používáme a naším zákazníkům dodáváme včetně technické a konzultační podpory. KOMIX je pro svoje zákazníky partnerem, který pomůže se zajištěním výkonnosti aplikací, nejsme jen jeden z řady dodavatelů „IT řešení“.

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

Řešení automatizace funkčních testů Jan Kovanic, [email protected] Přehlednost, udržovatelnost, široká funkčnost a přitom jednoduchá a rychlá tvorba. To jsou požadavky na skripty pro automatizované funkční testování. Vývoj skriptů, které používá testovací software, tak vlastně musí splňovat všechny požadavky, jaké obvykle klademe na samotný vývoj aplikace. V  podstatě je vytvářen miniaturní program, který prochází funkce testované aplikace a kontroluje, zda její chování odpovídá specifikovaným požadavkům. Obdobně je tomu u předpisu manuálního testu, ten deklaruje činnosti testera nutné k ověření správného chování aplikace. Na rozdíl od testera-člověka, nemá tester-automat ani ždibec představivosti. Zatímco tedy lidskému testerovi můžeme v nejhorším případě dát jen vstupní data a očekávané výsledky a on si nějak poradí, testovací software musí mít jednotlivě přesně určeno jaké tlačítko stisknout, z jakého objektu načíst hodnotu, co udělat v případě objevení chybového hlášení nebo neočekávaného chování aplikace. Je jasné, že v závislosti na chování aplikace a našich požadavcích na skript může být vývoj skriptu pro automatizované funkční testování poměrně náročnou a pracnou záležitostí. Důraz je tedy především kladen na znovupoužitelnost již vytvořeného kódu skriptu. Zde se dostáváme k jedné z hlavních otázek, která před námi při automatizaci testů vyvstává: Jak a podle čeho skripty členit? Představme si situaci, kdy máme automatizovat testovací skript, jehož

a nejrychleji. Tvůrce automatizovaného skriptu pak zpravidla zpracuje skript tak, jak to jemu v  dané situaci připadá nejvhodnější. Vzniká tak situace, kdy je identická činnost na aplikaci popsána několika na sobě nezávislými skripty. Společnost Mercury Interactive poskytuje technologickou základnu pro řešení (nejen) tohoto problému při automatizaci funkčního testování, Business Process Testing. Tento produkt spolupracuje se software TestDirector for Quality Center (správa procesu testování) a QuickTest Professional + WinRunner (automatizace funkčních testů) společnosti Mercury. Činnosti při použití Business Process Testing jsou zhruba tyto: Nejprve je aplikace logicky rozdělena do jednotlivých částí, takzvaných komponent. Jako jednu komponentu si například můžeme uvést přihlášení do aplikace. Toto rozdělení provádí pracovník znalý aplikace, který může rozdělení provést již ve chvíli, kdy je známa podrobná funkční specifikace aplikace (tedy co budou jednotlivé obrazovky dělat). Dále jsou deklarovány vstupní a výstupní hodnoty pro danou část aplikace. Pro přihlášení by byly vstupními parametry jméno a  heslo, výstupem by pak byla informace o tom, zda přihlášení proběhlo v pořádku. Je také vytvořen popis jednotlivých kroků (obsahující rovněž ověření chování aplikace), které budou na této komponentě v rámci testování prováděny.

Pracovník se zkušenostmi s metodikou testování vytváří testy pomocí skládání jednotlivých komponent. Deklaruje, které komponenty se jakým způsobem opakují, jak si mají předávat parametry a jaké budou vstupní hodnoty ať už u hodnot přímo zadávaných do aplikace, nebo u očekávaných výsledků. Test si poté sám kontroluje, zda jsou mezi jeho komponentami předávány parametry správných typů či zda se rovná počet spouštění vzájemně navazujících komponent v rámci testu. Připravenost komponenty ke spouštění je automaticky promítána do stavu všech testů, které danou komponentu používají.

Obr. 3 – Skládání komponent do testu

Obr. 1 – Pohled na manuální popis kroku skriptu

zjednodušený zápis pro testera-člověka vypadá asi takto: 1. Přihlaš se do aplikace 2. Založ nový záznam, zkontroluj existenci založeného záznamu a poznamenej si jeho unikátní ID 3. Nově založený záznam smaž 4. Zkontroluj smazání záznamu 5. Založ další nový záznam a zkontroluj, že jeho unikátní ID není rovné ID záznamu založenému v kroku 2 6. Odhlaš se z aplikace

Další dva kroky již mohou být prováděny v čase nezávisle na sobě. Autor automatizovaných skriptů přebírá zodpovědnost za převedení kroků, popsaných při deklaraci komponenty, do skriptu. Postupuje podle popisu, který se automaticky předepsal do automatizovaného skriptu z deklarace dané komponenty. Má také možnost přímo ze skriptu tuto textovou deklaraci jednotlivých kroků jednoduše modifikovat, případně přidávat popis dalších kroků, které byl nucen při zpracování skriptu doprogramovat a  které v  původním zadání nebyly brány v potaz.

Vidíme, že skript se skládá z transakcí přihlášení, založení záznamu (2x), kontroly záznamu (3x), smazání záznamu a odhlášení. Opakující se transakce by bylo možné zpracovat pomocí identického skriptu, který bude pouze volán s jinými parametry a bude vracet jiné výsledky. Je také velmi pravděpodobné, že některé z těchto transakcí (například přihlášení/odhlášení) využijeme i u jiných testů. To ovšem pracovník, který je pověřen automatizací tohoto konkrétního testu nemusí vůbec tušit. Tento člověk, tvůrce automatizovaných skriptů, nemá zpravidla přehled o všech testovacích případech na aplikaci a už vůbec nemůže rozpoznat, že některé z  transakcí, pro které zpracovává automatizovaný skript, jsou použity i v jiných testech. Jeho zadáním bývá pouze zpracovat automatizovaný skript a to co možná nejlépe

Obr. 2 – Pohled na automatizovaný skript kroku testu

Automatizované skripty jsou tedy skládány z  menších celků, které jsou znovupoužitelné v jiných testech. Odpadají také starosti o udržování dokumentace ke skriptům. Dalším benefitem je možnost začít s deklarací komponent a jejich svazováním do testů v počátku vývoje aplikace a již v té době řešit otázky navázání komponent tak, aby pokryly business procesy v aplikaci. Dokonce je možné, pokud je již známa alespoň struktura GUI (tedy že např. na stránce Login je editační pole Jméno), začít přímo automatizovat jednotlivé kroky skriptu. Koncept Business Process Testing tedy umožňuje: • Zapojit do tvorby automatizovaných testů i  pracovníky bez technických znalostí, zato se znalostmi procesů aplikace či postupů při testování. • Začínat s vývojem automatizovaných testů již na počátku vývoje aplikace. • Velmi významně zredukovat náklady na znovupoužitelnost a údržbu skriptů. • Automaticky udržovat dokumentaci ke s kriptům.

7

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

CRM není software – CRM je řešení, strategie, filosofie! Customer Relationship Management nelze chápat pouze jako počítačový program, tedy softwarový produkt. Jde především o filosofii, která specifikuje jednu z  firemních strategií, tu kde je zákazník středem veškerého snažení a vztah s ním jednou z priorit firmy. Jde o definici firemní kultury, která srozumitelně představuje základní podmínky pro dosažení stanoveného obchodního cíle. K realizaci vlastních cílů je ale nutné i vhodné technologické řešení, CRM systém integrovaný s celou firemní informační infrastrukturou. Teprve pomocí vhodného nástroje lze definovanou strategii uskutečnit.

Požadavky Při specifikování vlastností nového informačního systému, který se firma rozhodla pořídit zejména pro podporu obchodních a marketingových aktivit, velmi pravděpodobně vznikne podobný přehled požadavků, které má nový systém splňovat, jaké informace má zpracovávat: • Kontaktní informace o firmách a zaměstnancích. • Záznamy z jednání (schůzka, email, telefonát) • Obchodní příležitosti a jednání k nim. • Přehled dosavadních vztahů, dodaných produktů. • Sledování životního cyklu obchodního případu • Převod ze stávajících systémů (nejčastěji *.xls, Outlook, různé databáze). A  když je poté přehled požadavků sestaven a porovnán s nabídkou na trhu, která je, zejména pro oblast SME, velmi rozsáhlá, nastává střídavě nadšení a zděšení. Požadavky, které jsme MY nadefinovali, splňují podle průzkumu trhu prakticky všechny nabízené SW produkty! A co tedy dál? Je třeba si uvědomit, že všichni máme obdobné požadavky na funkčnost informačního systému. Co se týká obsahu (dat) skoro shodné, co se týká funkcí velmi podobné. A dodavatelé určité kategorie nabízejí obdobné produkty obdobné kvality. Podle výzkumů je ve finále výběru cena až na samém konci zájmu. Mezi výběrovými parametry činí s téměř 80 % vlivu na výběr systému podpora zákazníka. Nikoliv tedy cena, technologie nebo kvalita, ale porozumění potřebám budoucího uživatele a přizpůsobení informačního systému jeho firemní filosofii.

o plnění povinnosti tento systém zásobovat novými záznamy (a aktualizovat starší!!!), ale i tom, že je tento systém opravdovou „pracovní pomůckou“ a nikoliv brzdou. • Uživatelské hledisko musí být v  rovnováze s technickým řešením. • Zavedení CRM musí mít jednoznačnou podporu vedení firmy. • Zásadou správného systému je poskytnutí správných informací správným uživatelům ve správný čas a správným způsobem.

CRM řešení pro SME CRM řešení pro oblast SME, mají několik společných znaků. Jednak je to krátká doba implementace, pohybující se v řádu týdnů až měsíců, podporovaná možností využití přednastavených parametrů podle oblasti nasazení. Dále je to možnost integrace s dalšími informačními systémy, zejména ERP. A konečně systém musí být natolik nastavitelný, aby ho bylo možno z hlediska procesů a uživatelského prostředí plně přizpůsobit požadavkům zákazníka, pokud na tom trvá. Schopnost CRM systému modelovat vnitřní procesy firmy je také vítanou vlastností. CRM systém musí být jednoduchý, efektivní a z dlouhodobého pohledu levný. Krátká doba implementace a intuitivní ovládání jsou základními předpoklady. Ale co ještě nabízejí uživatelům systémy splňující shora uvedené představy a jaké jsou jejich základní vlastnosti? Konkurence v  oblasti CRM systémů je ještě rozsáhlejší, než např. v ERP systémech. Na druhé straně trh se systémy CRM roste a tento trend si podle konzultačních společností hodlá ještě nějakou chvíli zachovat. Společnost KOMIX navázala na CeBITu spolupráci s firmou CAS Software AG, která se zaměřuje právě na oblast softwaru pro podporu prodeje a na německém trhu s CRM systémy je na třetím místě za velikány SAP a Siebel a na trhu malých a středních firem je v Německu první.

• Zpracování korespondence ve spolupráci s Microsoft Office. • Centrální evidenci kontaktních informací a jejich přenos do druhého systému, nejčastěji ERP. • Vícevrstvou architekturu, integraci s dalšími produkty, možnost partnerských řešení pro zpracování vlastních agend. • Webový přístup ke všem základním datům a funkcím CRM řešení. • Konzistentní centrální realizovaný systém napříč celou firmou, který nahrazuje původní „informační ostrůvky“. • Centrální správu dat optimalizovanou s minimálními časovými nároky a s minimálním úsilím. • Rychlý, trvalý a přehledný přístup k aktuálním, správným a relevantním údajům o zákazníkovi.

Rang

Unternehmen

1 SAP 2 Siebel (now Oracle)

Umsatz M€ 2004

Umsatz M€ 2005

04/05

114

122

7%

53

45

-15 %

Nebezpečí

10,5

13

24 %

Co ale může zhatit správnou filosofii podporovanou skvělým IT řešením? Na jedné straně je to neúspěšná implementace systému (čísla hovoří až o 50%!), na druhé straně je to přístup dodavatelů. Značná část systémů nevychází z praktického používání systému, ale z  optimalizovaného modelu, uživatelské praxi značně vzdáleného. A do třetice je zde osobní aspekt. Nástroj, který má podporovat aktivity obchodníků a marketérů těmto lidem nevyhovuje. Svazuje je v jejich „rozletu“, vyžaduje po nich pečlivost. A přiznejme si, že to nejsou ty nejzákladnější vlastnosti lidí z této oblasti. Pokud je tedy nechceme sešněrovat výkazy, reporty a hlášeními, je třeba jim nabídnout produkt přizpůsobený nejen jejich potřebám ale i jejich naturelu. Ale – CRM neslouží jen pracovníkům obchodu a marketingu. Tento nástroj využije řada dalších pracovníků firmy, o spolupracujících informačních systémech ani nemluvě. Základní podmínkou efektivity CRM řešení je naprostá přizpůsobivost softwarového řešení konkrétním procesům uživatelů. A tak se z předpokládaného poměrně jednoduchého SW řešení stává docela slušný oříšek.

4 People Soft (now Oracle)

9,5

8

-16 %

8

IT

• Podporu obchodního oddělení informacemi o produktech používaných zákazníkem. • Možnost vhodné marketingové a  obchodní strategie založené na informacích o globálních zákaznících. • Efektivnější přípravu nabídek s využitím podrobných informací o zákaznících. • Vhodné nástroje pro přípravu marketingových aktivit. • Vyhodnocení efektivity marketingových akcí a kampaní, zpracování reportů a analýz chování zákazníků. • Integraci, dokumentaci a  archivaci veškerých kontaktů se zákazníky a  dodavateli, včetně interních aktivit.

Top Software-Hersteller* im deutschen CRM-Markt

CAS AG

Úspěšnost CRM systému lze posuzovat docela jednoduše – z množství uložených dat. To svědčí

ě

Jiří Šmíd, [email protected]

3

Nasazení CRM systému

t

5

CAS GmbH

5

6

20 %

6

update software

5

6

20 %

7

Microsoft

4

5

25 %

Proč CAS genesisWorld?

8

Cursor

3

3,5

17 %

2,7

3

Kdy je CRM systém úspěšný? Když skloubí vyspělé technické řešení s příjemným uživatelským prostředím a s odpovídající firemní strategií.

9 SuperOffice * exklusive BI-Spezialisten

11 % © PAC, 2006

Zdroj: stav CRM systémů v Německu, Pierre Audion Consultants

Klíčovým produktem společnosti CAS Software AG je systém CAS genesisWorld, držitel řady ocenění v oblasti CRM systémů, který uživatelům nabízí rozsáhlé možnosti při správě kontaktů a všech souvisejících agend: • Vedení základních kontaktních informací. • Vedení agendy, přehledu schůzek a jednání, telefonátů a  emailů, pozvánek, akcí, úkolů, dokumentů, projektů a obchodních příležitostí ve vztahu k jednotlivým zákazníkům. • Vstupní eliminace duplicitních dat. • Spolupráci s telefonní ústřednou, a to nejen možnost přímého vytočení telefonního čísla z  CRM systému nebo okamžitou informaci na obrazovce o volajícím, ale i automatickou archivaci telefonátu, kde je třeba pouze doplnit informace o jednání.

UŽIVATEL ovládání Intuitivní ovládání, v mnoha případech stačí klávesy kurzorových šipek, Esc a Enter; snadné a operativní úpravy podle individuálních požadavků. nabídka (menu) Nejenže v rámci implementace vznikne pro každého uživatele specifický přístup podle jeho potřeb a povinností, ale každý uživatel si může uzpůsobit menu podle svých představ. minimální nároky Automatické vyplňování max. množství položek – uživatel pak   na obsluhu vyplňuje jen neautomatizovatelné položky (např. záznam telefonátu). dostupnost informací Informace jsou k dispozici v aktuální podobě a v odpovídajícím množství. podpora Podpora poskytnutá nezkušených uživatelů.

MARKETING zpracování hromadné Veškerá korespondence (emaily, dopisy, pozvánky)   korespondence může být personalizovaná. příprava a sledování Rozeslání pozvánek, sledování odpovědí a reakcí, přímý záznam   marketingových akcí k zákazníkům.

MANAGEMENT reporty Sady výstupních formulářů s trvale aktuálními daty (stavy obchodních případů, jednotlivé aktivity atd.).

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

pokračování ze strany 8

a co ocení všichni dostupnost mobilními Synchronizace dat mezi firemními pobočkami.   zařízeními Automatická replikace mezi kanceláří a notebookem. Přístup přes PDS/ Smartphone (Mobile Access). On-line přístup přes Web-Access. propojení s telefonní Snadná evidence příchozích, odchozích i zmeškaných hovorů.   ústřednou Dohody sjednané telefonicky jsou trvale kompletně dostupné. Podpora denní práce. Žádné informace se už neztratí, všechny jsou propojeny. Telefonát lze zrealizovat i zaevidovat jedním kliknutím z adresáře a následně doplnit pouze záznam jednání. emailová komunikace Obdobně jako u telefonátů – zde není ani třeba pořizovat záznam. využití mapy Podle uložené adresy nabídne příslušnou mapku nebo trasu k zákazníkovi. rozšiřitelnost Zákazníci mohou využít řady řešení od partnerských firem (např. XXX), případně realizovat vlastní.

Společnost CAS Software AG Společnost CAS Software AG (www.cas.de) byla založena v roce 1986 a sídlí v německém městě Internetu, Karlsruhe. Zastoupení a  partnerské společnosti v Německu, Švýcarsku, Rakousku, Itálii, Řecku, Maďarsku a Rumunsku se díky společnosti KOMIX s.r.o. rozšiřují i do České republiky. CAS software AG je držitelem řady certifikátů a ocenění, včetně The European IT Prize, udělené Jacquesem Santerem.

Mezi dodavateli CRM v Německu je na druhém místě a blízkým cílem je Evropa. Více než 100 zaměstnanců společnosti se trvale věnuje hledání nových cest ke zlepšení vztahů se zákazníky. Výsledkem je CRM produkt ušitý na míru podle potřeb a požadavků malých a středních firem – CAS genesisWorld, vlajková loď mezi produkty. Vztah KOMIX – CAS Software AG Po podpisu partnerské smlouvy se KOMIX stává Value Added Resellerem. Lokalizuje produkty nabízené společností CAS (nejde jen o CRM systém) a vytváří partnerskou distribuční síť.

Integrovaný Change Management v podání CA Petr Mrázek, [email protected] V oblasti vývoje a provozu SW aplikací ovlivňuje Change Management (řízení změn) zásadním způsobem kvalitu i náklady každého projektu. Je nedílnou součástí vývojových projektů, protože i sebelepší design systému je vždy konfrontován s množstvím reálných omezujících faktorů na straně testerů a následně provozovatelů, uživatelů i okolního prostředí. Z těchto konfrontací vznikají zpětné vazby generující požadavky na změny (vylepšení, přizpůsobení) vyvíjeného SW. Význam kvalitního Change Managementu stoupá se stupněm složitosti vyvíjeného nebo provozovaného systému a samozřejmě s mírou případné integrace s jinými systémy cizích výrobců. Další často zmiňované kritické faktory jsou omezené řešitelské kapacity a krátké termíny požadované na provedení změny. Každý, kdo se v této problematice alespoň trochu orientuje, si dokáže představit, že v případě nesprávně provedené změny v systému rozsahu typického ERP (SAP, Oracle E-Business Suite, atd.) mohou způsobit problémy velkému počtu jejich zákazníků (to mohou být tisíce společností) a poškodit jejich byznys. Náklady spojené s opravou takové nesprávně provedené změny potom dosahují závratných částek, nehledě ke škodám na dobrém jménu výrobce systému. A podobná pravidla platí i uvnitř společností, pro které je vlastně dodavatelem služeb (funkcí SW) jejich interní IT oddělení se zodpovědností za provoz SW nakoupeného nebo vyvinutého vlastními silami. S vědomím důležitosti procesu řízení změn byl také Change Management zařazen mezi procesy definované ve standardu IT Infrastructure Library (ITIL). Velké společnosti vyvíjející systémy pro podporu správy IT služeb (IT Service Management – ITSM) se snaží pokrýt svými produkty celou tuto oblast, což řeší většinou akvizicí menších ale úspěšných dodavatelů, resp. jejich produktů vynikajících v dané konkrétní oblasti. Následně vyvinou potřebný interface a zajistí integraci do svého komplexního řešení. Tímto způsobem se daří postupně provázat jednotlivé oblasti a zákazník tak může získat ucelené řešení od jednoho dodavatele. Jedním z takových dodavatelů je i společnost CA (dříve Computer Associates), která po akvizici společnosti NIKU a jejího nástroje pro Portfolio/Project Management (Clarity) vyvinula interface mezi Clarity a dalšími dvěma aplikacemi CA – Unicenter ServiceDesk a Harvest Change Manager. Nabízí tak zákazníkům integrovaný Change Management systém pod názvem CA Enterprise Change Management, který je určen pro řízení změn během celého životního cyklu SW aplikací – tedy změn vyplývajících jak z projektů a návrhů ve fázi vývoje a testování SW, tak i ze zákaznických požadavků nebo chyb zjištěných během provozu u zákazníka. Představme si stručně jednotlivé komponenty, celé řešení a jeho výhody.

CA Harvest Change Manager umožňuje sledování a řízení změn SW a řízení vývojového procesu. Podporuje řízení změn v aplikacích i v jejich dokumentaci, umožňuje členům vývojových týmů sdílet aktuální informace o stavu vývoje včetně dodržování harmonogramu. CA Clarity – Portfolio / Project Management je nástroj pro multiprojektové řízení včetně řízení projektových financí, zdrojů/kapacit, hodnocení rizik, podporuje automatizaci řízení projektů využitím integrovaného workflow, obsahuje správu a vyhodnocování portfolií projektů a jejich prioritizaci.

Hlavní přínosy popisované integrace pro řízení změn SW jsou následující: • Vyšší produktivita díky těsnější spolupráci týmů ve výše zmíněných oblastech. • Snížení možnosti duplikování dat a manuálních vstupů (a tím snížení potenciálních chyb). • Kratší časy odezvy díky vzájemnému zviditelnění postupu a aktuálního stavu.

CA Unicenter Service Desk umožňuje kompletní správu požadavků na služby IT včetně hlášení problémů se SW, podporuje efektivní řešení těchto požadavků a hlášení, automatizuje postup řešení prostřednictvím integrovaného workflow. CA Enterprise Change Management je interface podporující proces řízení celého životního cyklu změn nebo vývoje nového SW integrací výše uvedených nástrojů. Je zajištěna automatizovaná vzájemná aktualizace dat nezbytných pro identifikaci jednotlivých změn a jejich momentálního stavu. Podle charakteru procesu v konkrétní společnosti lze použít několik scénářů, jeden z nich může být následující: 1. Uživatel zaregistruje na Service Desk svůj problém se SW. 2. Analytik Service Desku analyzuje toto hlášení a vyhodnotí jej jako oprávněný požadavek s nutností změny SW. 3. Konvertuje hlášení na „objednávku změny“ (change order) reprezentující požadavek na dodání opravného SW. 4. Vytvoří zároveň úkol v Clarity na příslušném vývojovém projektu (přímo ze Service Desku). 5. V  edoucí daného projektu v Clarity ověří a případně vyžádá doplnění informací o úkolu, přiřadí potřebné kapacity a naplánuje termín úkolu. 6. Následně vytvoří „Harvest package“ přímo z Clarity a dále sleduje aktivity (a náklady) na úkolu přímo v Clarity. 7. Vedoucí vývoje v Harvestu zkontroluje a potvrdí přiřazení kapacit na vytvořeném „Harvest package“. 8. Určený vývojář (nebo tým) vytvoří požadovaný SW, otestuje, zdokumentuje a připraví ke schválení a vydání. 9. Po schválení a implementaci je úkol uzavřen v Harvest i v Clarity včetně vyhodnocení jeho nákladů. Je aktualizován (uzavřen) také příslušný případ v Service Desku a o provedení změny je informován uživatel, případně další, kterých se provedená změna týká.

Service Desk

Clarity

Harvest

Change Order

Project/Task

Package

• Zlepšení transparentnosti procesu pro potřeby procesního auditu k posouzení souladu s procesními standardy společnosti. • Zpřesnění sledování nákladů na změny a vyhodnocování jejich dopadu v projektových portfoliích. • Zlepšení možností vyhodnocení prioritizace zajišťování změn v souladu s cíli společnosti.

9

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

Nové vlastnosti databázového serveru Microsoft SQL Server 2005 I když je MS SQL Server 2005 již nějakou dobu na trhu, mnoho uživatelů stále váhá, zda stojí za to na novou verzi upgradovat. Budu rád, když jim tento článek v jejich rozhodování alespoň trochu pomůže. Při porovnání vlastností databázového SQL serveru od Microsoftu je samozřejmě výhodou znalost předešlé verze, ale snažil jsem se text formulovat pokud možno tak, aby i čtenář bez zkušenosti s MS SQL 2000 získal alespoň rámcový obrázek toho, co s sebou nová verze přináší. Článek je také koncipován poněkud praktičtěji, lze ho použít jako určitý návod pro seznámení s prací v prostředí SQL Server 2005. SQL Server 2005 kromě své primární úlohy databázového serveru poskytuje několik druhů služeb, které je možné vybrat již v okamžiku instalace. V nabídce jsou tyto komponenty: • databázové služby • analytické služby (OLAP analýzy, datamining) • reportovací služby (generování reportů a sestav) • notifikační služby • služby pro transformaci údajů (DTS – Data Transformation Services) • administrátorské a  vývojářské nástroje, pomocné komponenty, dokumentace, atd. V případě, že jsme instalovali reportovací služby, se v systému vytvoří dva virtuální adresáře pro webový přístup k reportům. Pro fungování reportovacích služeb je potřebná samostatná databáze pro ukládání pracovních a konfiguračních údajů a metadata reportů. Tato databáze může být přímo na lokálním databázovém serveru nebo její vytvoření můžeme požadovat na jiné instanci SQL Serveru 2005. Reportovací služby umožňují rozesílání reportů elektronickou poštou; je tedy nutné nastavit adresu SMTP serveru a emailovou adresu odesílatele. Pro webový přístup k reportům je samozřejmě třeba mít nejprve nainstalovaný webserver Microsoft IIS, který je volitelnou součástí instalace Windows. V této části související s instalací SQL Serveru 2005 bych si dovolil malou odbočku. Při instalaci serverového softwaru obecně se jistě nevyhneme polemice mezi množstvím nainstalovaných služeb a  komponent a  bezpečností provozu. Z toho vyplývají dva možné způsoby přístupu: • při implicitní instalaci převážnou většinu služeb zakázat s předpokladem, že zkušený administrátor je při jejich doinstalování nebo povolování náležitě zabezpečí • seznam požadovaných komponent a služeb se určí při zadávání parametrů instalace nebo v průběhu samotného instalačního procesu Budeme-li postupovat druhým způsobem a nainstalujeme služby, které nebudeme hned využívat, je vhodné je zakázat, aby se postupem času nestaly potenciálním slabým místem pro průnik do systému. Po nainstalování SQL Serveru 2005 máme možnost v posledním dialogu instalace spustit nástroj Surface Area Configuration a s jeho pomocí zakázat všechny služby, které nemíníme hned po instalaci využívat. Z předcházející statě je zřejmé, že databázový server je z  hlediska fungování na počítači poměrně komplexní záležitost. V  porovnání s  jinými produkty (typu grafický editor nebo hra) instalace databázového serveru v kombinaci s vývojovým prostředím s konfigurací počítače pořádně zamává. Navíc například vývojář, který musí udržovat staré produkty, nemůže přejít na novou verzi databázového serveru a  vývojového prostředí kdy se mu zachce. Vyhradit pro testování nových produktů samostatný hardware je sice excelentní, ale poměrně nákladné řešení. Řešením nejen naznačených problémů, ale i řady dalších jsou virtuální počítače (např. MS Virtual Server, VM Ware). Jejich výhody jsou

10

natolik zřetelné, že není těžké jim předvídat široké uplatnění v budoucnosti.

Architektura Globální blokové schéma SQL Serveru 2005 můžeme znázornit pomocí následujícího obrázku:

Využití skriptových šablon Management Studio v  módu Template Explorer zobrazí seznam šablon, které jsou předpřipravené pro nejpoužívanější druhy skriptů, například pro vytváření a rušení objektů, databází a podobně.

s

v

ě

t

ě

IT

Jan Krejčí, [email protected]

dokumentů. Administrátor dokáže zjistit informace o  sloupcích, na kterých byly vytvořeny agregace, případně zjistit, jakého počtu řádků se ta která operace týkala. Je také možné nastavit tzv. šablonu trasování, tj. na co se při trasování zaměřit, například na dobu trvání příkazů, způsob zpracování agregací a podobně. Pro časově ohraničené ladění výkonu databáze a různé druhy analýz typu „what if?“ je možné použít nástroj Database Engine Tuning Advisor. Pracuje na základě výsledků z Profileru. Ladit je možno buď celou databázi nebo případně jen vybrané tabulky.

Novinky v oblasti vysoké dostupnosti databází

Základním stavebním kamenem architektury je relační databázový stroj. Jeho služby mají na starosti správu údajů, jejich vkládání a mazání, vyhledávání, atd. Kromě výše zmiňovaných reportovacích, analytických a notifikačních služeb zde můžeme zmínit replikační a integrační služby a dále komponenty pro administraci a vývoj aplikací. Databázový server s naznačenou infrastrukturou najde uplatnění nejenom při budování rozsáhlých relačních databází, ale také analytických databází a datových skladů (datawarehouse). Databázové a analytické služby byly integrovány i v předcházející verzi SQL Serveru 2000, přesněji řečeno byly tam integrovány od začátku. Reportovací služby pro verzi 2000 byly uváděny na trh později jako doplňkový balík; proto rozdíly mezi tímto balíkem a reportovacími službami integrovanými do verze 2005 nejsou nijak veliké.

SQL Server Management Studio SQL Server Management Studio je komplexní integrované prostředí pro správu databázového serveru SQL Serveru 2005. V první betaverzi mělo toto prostředí pracovní název SQL Server Workbench. Kdybychom se snažili určit pozici tohoto nástroje vzhledem k předcházející verzi SQL serveru 2000, dalo by se zjednodušeně říci, že se jedná o sloučení nástrojů Enterprise Manager, Query Analyser a do určité míry i nástroje Analysis Manager. Management Studio je vybudováno na základě unifikovaného vývojového prostředí Microsoft Development Environment, které vychází z vývojového prostředí Visual Studio 2005. Na tomto základu jsou postaveny i další nástroje, například Business Intelligence Development Studio pro práci s integračními službami, OLAP kostkami a  data-miningovými modely. Je to významný krok k unifikaci v nové řadě vývojářských produktů a technologií Microsoftu.

Dotazy v  prostředí SQL Server Management Studio Stisknutím tlačítka New Query aktivujeme dotazovací funkce Management Studia. Uvedená funkce je nástupcem nástroje Query Analyzer ze starší verze SQL Serveru 2000. Kromě klasických SQL a T-SQL dotazů je možné přepnout Management Studio do těchto dalších režimů: • MDX Query • DMX Query • XMLA Query • SQL Mobile Query podle toho, zda pracujeme s relačními, multidimenzionálními nebo data-miningovými databázemi. SQLCMD Pro správu databázového serveru a  ladění databázové části aplikací často využijeme i jednoduchou interaktivní textovou konzolovou aplikaci SQLCMD. Slouží pro zadávání příkazů jazyka SQL databázovému serveru a v okně té samé aplikace vidíme výstupy, které databázový server vygeneruje jako odezvu na naše příkazy, např. výpis obsahu databázových tabulek, potvrzení vykonání příkazů, chybová hlášení a podobně. Konzole SQLCMD nahrazuje aplikace osql a isql známé z předcházející verze. Pro připojení k databázovému serveru využívá SQL Native Client. SQL Profiler Ladící nástroj Profiler slouží pro monitorování instancí databázového a analytického serveru. Pomáhá odhalovat problematické požadavky a dávky příkazů, které neúměrně zatěžují databázový server a snižují tak jeho výkon. Pro zvýšení komfortu ladění výkonu a optimalizaci požadavků je možné přehrávat zaznamenané SQL příkazy. Profiler umožňuje zobrazení Performance čítačů i  vizualizaci dead-locků. Výsledky trasování je možné ukládat do XML

Na úvod této části věnované popisu novinek pro vysoký výkon, dostupnost a  zabezpečení údajů uvedeme přehled nových vlastností. Ne všechny vlastnosti jsou však dostupné ve všech verzích SQL Serveru 2005. Database Mirroring – okamžitá náhrada (<3 s), úplná odolnost vůči chybě, možnost použití různých topologií. Z  hlediska HW se využívají standardní komponenty. Online Restore – administrátor může provádět restore operace za běhu instance SQL Serveru. Fast Recovery – možnost rychlé obnovy dat zvyšuje dostupnost a spolehlivost databází. Bezpečnost – rozšířený bezpečnostní model, důslednější zabezpečení při implicitní instalaci, šifrování obsahu databáze, možnost nastavení „silných hesel“, přesnější specifikace a vymezení přístupových práv. SQL Server Management Studio – integrovaný nástroj pro správu databází a práci s databázovými objekty. Umožňuje zadávání dotazů v jazycích T-SQL, MDX a DMX. Dedikované administrátorské připojení – umožňuje administrátorovi přístup a spouštění diagnostických T-SQL skriptů i v době, kdy je SQL Serveru 2005 pro ostatní přístupy zamknutý. Database Snapshot – trvalý „snímek“ databáze na disku. Snapshot Isolation – umožňuje přístup k poslednímu potvrzenému řádku při zachování konzistence transakce. Partitions – možnost rozdělení tabulky, která obsahuje velké množství údajů na několik částí, což umožňuje následný rychlejší přístup k datům. Nyní se na některé vlastnosti podíváme podrobněji. Nová transakční izolační úroveň Snapshot Isolation (SI) umožňuje na začátku transakce vykonat snapshot (statický snímek, momentku) databáze. Následující operace pak pracují s takto vytvořeným pohledem na data, čímž se výrazně sníží doba čekání v důsledku uzamykání záznamů. Snapshot čte vždy souvislá data, proto není potřebné používat „read lock“ ani v případě, že data byla změněna. Verze každé hodnoty se drží podle typu požadavku. Transakce čte verzi hodnot korespondující s momentem spuštění transakce. Dedikované administrátorské připojení — jedná se o zvláštní vyhrazený typ spojení na SQL server za všech okolností. Pro spojení tohoto typu jsou vyhrazeny zvláštní systémové prostředky, což umožní jeho fungování i v případě, kdy zbytek databáze (serveru) je přetížený nebo nefunkční. Toto spojení umožňuje administrátorovi pokusit se ukončit kritické procesy, případně ve specifických situacích zjednat nápravu pomocí příkazů T-SQL. Rozdělení tabulek do více částí (partitions). Jestliže databázová aplikace pracuje s velkým množstvím dat, je z hlediska manipulace výhodné ukládat tyto data do tabulek rozdělených do více částí. Tabulku můžeme na partitions rozdělit podle více kritérií, nejčastěji však podle časového hlediska. Jako typický příklad bychom

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

a

r

t

n

e

r

v

e

s

v

ě

t

ě

IT

pokračování ze strany 10

mohli uvést získávání údajů o telefonních hovorech zákazníků na veřejné telefonní ústředně nebo u  mobilního operátora. Měsíčně získáme milióny až desítky miliónů údajů. Proto je v takovém případě výhodné rozdělit tabulku na několik logických oddílů; v našem případě bude jeden logický oddíl obsahovat údaje za jeden kalendářní měsíc. Takovéto rozdělení je nejen výhodné pro rychlejší dotazování v  menších tabulkách, ale je logické i z hlediska zpracování údajů, protože např. reklamace nebo fakturace se obvykle vykonávají také měsíčně.

Bezpečnost Nová verze databázového serveru obsahuje kromě významných vylepšení v oblasti funkcionality a výkonu také neméně důležitá vylepšení v oblasti bezpečnosti. Vzhledem k velmi omezenému rozsahu tohoto článku jsme vybrali pouze dvě záležitosti týkající se bezpečnosti a to sché-

mata a šifrování údajů. Jednou z  nejvýznamnějších novinek, které s sebou nový SQL Server přináší, jsou schémata. SQL Server 2005 umožňuje použití více schémat v jedné databázi. Schémata existují nezávisle na uživatelích, přičemž každý uživatel má přednastavené vlastní schéma. Tento koncept ulehčuje správu databáze, např. při migraci uživatelů může schéma nahrazovat uživatele ve jménu objektu. Při odstraňování uživatele z databáze již tedy není nutné nejprve smazat všechny jeho uživatelské objekty. Ačkoli v předchozí verzi SQL serveru existovaly určité nástroje pro šifrování dat (pomocí uživatelsky definovaných funkcí nebo jednocestné hashovací funkce PWDENCRYPT), byly dosti omezené a  poměrně zřídkakdy používané. Nová verze v této oblasti přináší značný posun kupředu, neboť nativně podporuje většinu nezbytných funkcí pro šifrování. K dispo-

zici jsou algoritmy DES, TRIPLE_DES, RC2, RC4, DESX, AES_128, AES_192, AES_256. Je dobré si připomenout, že použití asymetrických klíčů a  asociovaných certifikátů poskytuje sice silnější zabezpečení dat, na druhou stranu je zřetelně náročnější na čas procesoru, zvláště při větších objemech dat. Zde se pak nabízí použití symetrických klíčů jako určitý kompromis mezi bezpečností a rychlostí zpracování. Mnohé další důležité vlastnosti a  novinky v SQL Serveru 2005 zde již vzhledem k omezenému rozsahu tohoto článku nelze blíže zmínit, ať už se jedná o rozšíření jazyka SQL a T-SQL, práce s daty ve formátu XML, rozšiřování funkčnosti SQL Serveru v  jazycích .NET, webových služeb atd. Pro případné zájemce odkazujeme na webové stránky Microsoftu http://www. microsoft.com/sql/, kde je tato problematika celkem přehledně zpracována. Popisem dalších komponent, jako jsou např.

analytické a  reportovací služby se budeme zabývat v některém z příštích článků. Závěrem nezbývá než konstatovat, že databázové servery Microsoftu představují v současné době plnohodnotnou alternativu ostatním produktům etablovaným na trhu a v některých směrech, zvláště co se týká přidaných funkcí v  oblastech multidimenzionálních analýz, reportingu a  notifikačních služeb je s  ohledem na cenu i předčí. Vysoký stupeň integrace s vývojovými nástroji Visual Studia 2005 .NET bude jistě představovat nemalý přínos k oblibě tohoto produktu mezi vývojáři a zákazníky. Pro některé vybrané aplikace lze s výhodou použít i SQL Server 2005 Express Edition, který je distribuován zcela zdarma.

Informační technologie na cestách Každý den se setkáváme s informačními technologiemi, aniž bychom si to uvědomovali. Čím dál více nám zasahují do života díky rychlému tempu jejich vývoje, který je jednou z  příčin propojování celého světa, rychlého tempa životního stylu, mobility lidí především v profesním životě a tím pádem nutnosti rychlému přístupu k informacím. V dnešní době mají informace větší hodnotu než hmotné statky a služby. A kdo má více cest k informacím a rychlejší přístup k nim, může získat více než ostatní členové naší populace. Společnost KOMIX s.r.o. by vám ráda představila několik řešení, jak můžete informace rychle získat, převést, zpracovat a zpřístupnit v elektronické podobě. Jedním z těchto řešení jsou skenery od společnosti Plustek Technology Inc., která patří mezi přední výrobce v oblasti skenovací techniky. Plustek OpticSlim M12 je ideálním mobilním řešením pro barevné skenování formátu A4. Díky jeho malým rozměrům jej můžete mít stále po ruce v brašně společně s notebookem. Aplikace, která je součástí dodávky, vám umožní jednoduše skenovat a organizovat vaše dokumenty, fotky, brožury a  vizitky, vše pouhým zmáčknutím „jednoho tlačítka“. Skener lze připojit pomocí USB rozhraní.

Zakoupením Secure ID Stick získáte tyto výhody a funkce: • Autorizaci osobního počítače nebo notebooku pomocí osobního hesla pro používání flash disku. • Přístupnost dat na flash disku ze tří autorizovaných počítačů (například: doma, v kanceláři a na notebook). • Ochranu dat v  případě ztráty flash disku a možnosti zneužití dat nežádoucím uživatelem. • Možnost jednoho použití flash disku na neautorizovaném počítači po zadání osobního hesla.

Pavel Vrtílka, [email protected]

• Funkci Autorun, která zobrazuje okno pro zadání hesla a kartu s identifikačními údaji uživatele. • Možnost úpravy karty s identifikačními údaji uživatele. • Upozornění na malou kapacitu paměti v případě jejího nedostatku .

Závěr Dva příklady moderní techniky nabízené KOMIX s.r.o. ukazují možnosti rychlé, efektivní a bezpečné práce s daty v terénu.

Dalším řešením, které můžete použít na cestách pro práci se svými daty, je externí paměť Innodisk Secure ID Stick. Tento unikátní koncept flashdisku umožní ochránit vaše citlivá data před zneužitím jinou osobou. Tento výrobek má dvě speciální funkce – AutoSecure a AutoRun. Funkce AutoSecure zajišťuje ochranu vašich dat pomocí autorizace osobního PC či notebooku, kdy data jsou dostupná pouze z autorizovaného přístroje (počítače). Druhá funkce AutoRun umožňuje zobrazení karty s vašimi osobními identifikačními údaji.

11

v

á

š

s

p

o

l

e

h

l

i

v

ý

p

Lehké SUDOKU

8 2 5 7

r

t

n

e

r

v

e

s

1

9

2

3

6

8

1

3 3

3 5

4

8 3

t

ě

IT

2 1 6 4

9 6

8 7

4

2

1

5 2

7

1

6

5 7

6

ě

6

5

4 7 2

v

Středně těžké SUDOKU

5 1

a

1 6

5

2

8 3

8

6

5

Těžké SUDOKU

7 3

Pravidla Sudoku

5 4 1

4

9

8

7

1 2

4

5 6

9

6

1 2 4

7

Co je to Sudoku

2 9

Cílem hry je doplnit chybějící čísla 1 až 9 v předem dané předvyplněné tabulce. Tato tabulka je rozdělená na 9x9 polí, která jsou seskupena do 9 čtverců (3x3). K předem vyplněním číslům je potřeba doplnit další čísla tak, aby platilo, že v každé řadě, v každém sloupci a v každém z devíti čtverců byla použita vždy všechna čísla jedna až devět. Pořadí čísel není důležité. Čísla se nesmí opakovat v žádném sloupci, řadě nebo v malém čtverci. Na první pohled se zdá řešení lehké, nicméně opak je pravdou. Obtížnost Sudoku není dána počtem skrytých políček, ale jejich vzájemnými vazbami, které na první pohled nejsou vidět. Základní metodou řešení je vyhledání vhodných čísel (variant) pro jednotlivé pole tak, že postupně pro každé prázdné pole vezmeme čísla od 1 do 9 a prohledáme vždy příslušný sloupec, řádek a čtverec, zda už tam číslo není. Pokud není, zapíšeme si ho jako možnou variantu do pole (malým písmem, někam do poznámek na papír). Pokud pro pole vyjde jako varianta jen jedno číslo, doplníme ho jako řešení do pole a proškrtáme toto číslo ve variantách v polích ve stejném sloupci, řádku a čtverci. Takto můžeme přijít na další jednoznačně vhodná čísla do buněk. Provádíme dokola, dokud nám vychází nějaké jednoznačné varianty. Touto metodou jdou vyřešit jen lehké hlavolamy, obtížnější vyžadují kombinaci více metod řešení.

8

KOMIX s.r.o. je systémový integrátor zaměřený na dodávky vlastních řešení informačních systémů s využitím moderních a ověřených technologií. Svým klientům poskytuje služby ve všech fázích životního cyklu informačního systému od definice požadavků na jeho funkčnost, až po provedení akceptačních testů a podporu jeho provozu. KOMIX se přitom spoléhá především na vlastní vývoj, know-how a tým odborníků, kteří se dokonale orientují v informačních technologiích, znají potřeby svých zákazníků a mají praktické zkušenosti z realizace rozsáhlých systémů. Hlavními kritérii úspěšnosti našich projektů jsou míra spokojenosti zákazníka a trvale dobré vztahy. Předáním systému spolupráce nekončí, ale pokračuje ve formě technické podpory, školení a dalších navazujících služeb. Společnost KOMIX byla založena v září 1992 v Praze. V současné době má 125 zaměstnanců.

Sudoku je poměrně mladá logická hra. První Sudoku pravděpodobně publikoval Howard Garns v USA v roce 1979 pod názvem Number Place. Poté se jej v roce 1984 chtili v Japonsku, kde se tato hra stala velmi oblíbenou a kde také později získala svůj název Sudoku. V Evropě se tato hra prosadila masověji až v roce 2005, kdy se začala objevovat v různých denících. Od té doby zaznamenala její popularita prudký vzestup a dnes ji již zná skoro každý.

KOMIX – ověřená kvalita produktů a služeb

KOMIX s.r.o. Holubova 1, 150 00 Praha 5, tel.: +420 225 989 811, fax: +420 225 989 803, [email protected], www.komix.cz Redakční zpracování: kolektiv pracovníků KOMIX s.r.o., DTP a produkce: ARDEA grafické studio, s.r.o. KOMIX s.r.o. 2006

12