Co s tunami informací?

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

INVEX 2003 6. – 10. 10. 2003 expozice „Vinný sklípek“ pavilon V, stánek 54

Co nás čeká? 13. června letošního roku jsme rozhodli, že vstoupíme do EU. Řada z nás s přesvědčením, že z EU přiletí nějaký ten pečený holub, jiní proto, že ANO považovali za jedinou možnost a NE za krok k izolaci.

Nyní je třeba vystřízlivět a začít se starat o důsledky tohoto rozhodnutí, aby nás nezaskočily, jako zima naše silničáře. Co nás bezprostředně čeká? 1. Konkurence. 2. Vládní reforma. 3. Vybudování struktur, které nám umožní plnit závazky, které na sebe bereme, a také se podílet na výhodách, které EU nabízí. Pokusím se tyto tři body okomentovat z pohledu IT. Konkurence – asi můžeme konstatovat, že v IT segmentu již všichni silní světoví hráči působí. IT technologie se prodávají za světové ceny, zde by tedy k vážné změně dojít nemělo. Lze očekávat vyšší konkurenci ze strany středních a menších firem zejména firem z okolních států jako je Polsko, Slovensko, Maďarsko. Nový zákon o zadávání veřejných zakázek by měl zprůhlednit rozhodování ve výběrových řízeních a také odstranit možnosti zvýhodnění lokálních firem. V Německu se silně projevuje konkurence levné programátorské kapacity ze zemí bývalého Východního bloku, můžeme očekávat stejný trend. Bude sílit mezinárodní kooperace. KOMIX již dnes navazuje kontakty s německými firmami, aby byl schopen kooperovat jak na českém trhu, tak na trzích třetích zemí. Vládní reforma je zatím trochu v mlze a tak lze těžko komentovat její dopad. Nicméně, mají-li se snížit náklady na správu země a zkvalitnit služby občanům, bez nasazení IT technologií to nepůjde, takže můžeme očekávat investice do této oblasti. Velký dluh vidím v budování struktur, které by měly zajistit komunikaci s EU a také, to považuji za velice důležité, podpořit naše firmy v administrativně náročných procesech, které je nutné absolvovat, chce-li se firma účastnit projektů EU ať již jako zadavatel projektu nebo ve výběrovém řízení na jeho řešení. Podle mého názoru máme velký dluh v informování o možnostech využití unijních fondů. I tyto činnosti bude třeba podpořit IT technologiemi, takže i zde se bude jistě investovat. KOMIX jako technologicky vyspělá firma vidí ve vstupu do EU příležitost. Hrozbu pro nás představuje vládní reforma, pokud by mělo dojít v důsledku reformy ke zdražení lidské práce, budou české firmy v silném konkurenčním prostředí znevýhodněny. Petr Kučera, ředitel, [email protected]

Co s tunami informací? Patrik Šálek, [email protected] Moderní podnik poskytuje svému okolí velké množství nejrůznějších dokumentů. Přitom skupiny uživatelů těchto dokumentů jsou velmi různorodé – zákazníci, potenciální zákazníci, investoři, zaměstnanci, případně další. Zvládnout kvalitu poskytovaného obsahu s ohledem na potřeby cílových skupin je velmi náročné. Důležité je, že dnes už nestačí, aby se uvedeným uživatelům obsah dal „nějak“ k dispozici. Jméno a kvalita podniku jsou dnes vnímány nejen prostřednictvím obsahu dokumentů, ale také prostřednictvím jejich formy, způsobu doručení adresátovi a dalších parametrů. Nepotřebné a staré informace obtěžují většinu z nás. Do procesu poskytování informací tak ve stále větší míře musí vstupovat marketing, k jehož úkolům v této souvislosti patří: • udržovat a rozvíjet firemní značku a image, • udržet stávající zákazníky/klienty, • podpořit akvizici nových klientů. Konkrétně pak marketing: • podporuje zajištění optimálního množství informací o firmě a jejích službách či produktech, jejich publikaci a selektivní distribuci vybraným cílovým skupinám (různé formy inzerce, reklamní akce, návrh vzhledu a obsahu webových stránek…), • působí na udržování konzistentního vzhledu firemních do-kumentů (od vizitek, přes letáky, webové stránky až po projektové dokumenty a technické specifikace), • napomáhá rozvoji firemní kultury – způsobu komunikace, vystupování a chování zaměstnanců apod., • je odpovědný za prezentaci společnosti na různých obchodních, společenských a jiných akcích. Stejně jako u vzhledu firemních dokumentů je třeba si uvědomit, jaké nároky jsou dnes na prezentaci společnosti kladeny – prezentace musí kromě věcného sdělení např. podporovat značku firmy, musí být včasná, nesmí být nákladná, má oslovit odpovídající množství členů cílových skupin apod. Enterprise Content Management (ECM) v tomto světle představuje poměrně nový „business“ nástroj, který dnes může marketing – a nejen marketing! – při zajištění uvedených činností využít. Cílem ECM je podpora správy jak strukturovaných, tak nestrukturovaných údajů – jejichž zdrojem mohou být podnikové aplikace i jednotlivé dokumenty v různých formátech. Přitom se nemusí jednat jen o textové dokumenty, ale také o obrázky, videa, zvukové nahrávky atd. V tomto kontextu hovoříme o správě obsahu.

Web Content Management je část ECM a využívá k publikování obsahu webové technologie. Využití webových technologií neznamená, že každý dokument musí ve výsledku mít jen formu HTML. Naopak, dnes je snahou vycházet vstříc zákazníkovi a nabídnout mu formáty, které jsou pro jeho práci přirozené. Typickým příkladem jsou PDF soubory, které respektují požadavky na profesionální vzhled, který se nemění v závislosti na použitém výstupním zařízení a lze zajistit, aby nebyl uživatelem měněn. Uživatelé si takové dokumenty mohou stahovat a uschovávat pro pozdější využití. Stejně jako u jiných oblastí, také pro poskytování obsahu bychom mohli definovat něco jako vlastní „Capability Maturity Model Content Managementu“ a ukázat, že většina podniků jej už vlastně delší dobu nějak řeší, avšak z dnešního pohledu pouze na základní úrovni. V každé firmě, která má nějaké internetové stránky, existují postupy, jak se na ně dostávají informace. Někde tyto postupy definují striktní pravidla pro řízení a obsah určený k publikaci prochází několika koly schvalování, jinde jsou volné a záleží na osobnostech, co a jakým způsobem publikují. Důležitým prvkem takového způsobu publikování informací je fakt, že někde tyto informace věcně musí vzniknout, marketingoví pracovníci je pak opracovávají do podoby, která je z jejich pohledu publikovatelná, a technologové – weboví administrátoři – jim dají konečnou formu. A jaký je pohled Content Managementu? S čím může podnik, který se rozhodne řešit Content Management, počítat? Řešení Content Managementu zahrnuje: • Definici struktury obsahu pro jednotlivé účely, ke kterým je určen. Pro každý typ informací (např. technické informace o produktech, informace o podniku, možnosti zaměstnání apod.) se určí, jaké složky má publikovaný obsah mít. V případě produktu to může být krátký popis, detailní popis, jak dlouho má být zařazen mezi novinky atd. • Definici / formalizaci procesu publikování a správy obsahu určeného k publikování. Musí zahrnovat vznik informace, její zpracování do požadované struktury (viz předchozí bod), schvalovací pravidla a další. • Definici rolí Content Managementu – role, která definuje strukturu údajů, které se zaznamenávají a dále využívají, role, která zadává data (tvůrce obsahu), role, která schvaluje obsah (schvalovatel, manažer), role, která rozhoduje o formě publikovaného obsahu (designér) a role, která publikování technicky zajišťuje (webový administrátor). • Zpracování konkrétních šablon, do kterých budou data na-

1

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

pokračování ze strany 1

plňována uživateli (např. různé aplikační • Zjednodušení publikace obsahu, navíc formuláře) a šablon používaných pro puv různých formách. Jakmile obsah jednou blikování obsahu (šablony HTML stránek, vznikne a je zkompletován, může být předoprovodných dokumentů). Zatímco prvváděn do různých formátů podle toho, co ní typ šablon je prostředek pro sběr údajů, uživatelé stránek preferují. Nástroje obdruhý typ slouží pro udržení jednotného vykle také působí jako integrační prvek vzhledu publikovaného obsahu. mezi poněkud těžko slučitelnými profe• Nasazení nástroje a jeho případné proposemi (odborníky na věcnou problematiku, jení na jiné systémy – systémy pro správu marketingovými pracovníky, webovými dokumentů, portály aj. administrátory). To ocení především spoKouzlo většiny takových nástrojů tkví lečnosti, které se snaží být aktivní a chtěv tom, že každá ze stran, která se podílí na -jí poskytovat informace, chtějí mít své publikování obsahu, se může věnovat tomu, stránky živé, ale potřebují k tomu armádu co je jí přirozené – odborníci vytváří obsah webových specialistů. (a nemusí vědět, kde všude a v jaké formě se Vhodnost použití softwarových nástrojů používá), marketingoví pracovníci se zaměřují roste s tím, jak se firma přibližuje jedné či na vzhled v šablonách, manažeři schvalují, co více z následujících situací: může a nemůže být publikováno a weboví • Firma se skládá z více poboček (částí), administrátoři pak zveřejňují stránky. Navíc z nichž každá potřebuje zveřejňovat indíky vytvářeným šablonám a automatické formace. konverzi formátů lze výrazně šetřit čas • Firma podporuje nejen firemní značku, a věnovat jej např. komunikaci se zákazníky. ale také samostatně propaguje proŠablony se používají nejen pro konkrétní dukt/y – např. Twist nebo Go u našich dokumenty, ale také případně pro strukturu operátorů. webu, web administrátoři tak mají významně • Firma produkuje velké množství informaušetřenou práci. cí a potřebuje je dávat k dispozici svému Pokud bychom měli přínosy shrnout, jedná okolí. se o následující: • Firma má interně několik částí (oddělení, • Podpora udržování jednotného image. poboček), které interně poskytují své Potřeba zabezpečení jednotného image služby širšímu okruhu zaměstnanců. Jejich roste s množstvím poboček a jejich vlastkonzistentní popisy by měly být zveřejňoních stránek. Typicky se jedná o problém vány na intranetu společnosti. nadnárodních společností, u kterých si Co říci závěrem? Udělat z rozbouřeného každá národní pobočka vytváří vlastní moře informací klidně plynoucí potůčky, vywebové stránky. Často se stane, že z inter- žaduje nemalé úsilí tento živel zkrotit a jeho netové prezentace není moc patrné jestli potenciální sílu využít ve svůj prospěch. Conse vůbec jedná o stejnou firmu či nikoliv tent Management (jak byla tato problematia zákazník je zmaten. Podobný problém ka pojmenována) pomáhá, aby firemní inforse dotýká i holdingů, samostatných firem, mace byly ve správné podobě doručovány na které provozují více webových adres nebo patřičná místa. Je přece hezké, když zákazníci firem, kde je odpovědnost za obsah a for- rádi sledují informace svého dodavatele, mísmu distribuovaná mezi více věcných oddě- to aby byli zmatení, případně hledali úkryty lení. Mimo uvedené příklady se nástroje před desítkami „zajímavých“ mailů. pro Web Content Management běžně Síla Content Managementu je v tom, že využívají také v rámci intranetů. odděluje jednotlivé profese, které se na vzni• Úspory při administraci webů. Nástroje ku a publikaci informací podílejí, odděluje pro Web Content Management zpravidla obsah (jako materiál, určený k publikaci) od disponují funkcemi, které zamezí publi- způsobu jeho prezentace. Web Content Makaci slepých odkazů, umožní jednoduše nagement se stará o obojí – tj. obsah i formu sdílet strukturu pro více webových adres – pro obojí zavádí standardy. (případ národních poboček) a podpoří víZavádí standardy jak procesní, prezentačcejazyčnou prezentaci (včetně respekto- ní, tak i standardy pro strukturu prvotního vání národních specifik). Použití nástrojů obsahu určeného k publikaci. Vedle toho nelze než doporučit společnostem, které šetří práci tím, že poskytuje a automatizuje disponují větším počtem „webistů“, kteří užitečné konverze nebo hlídá dodržování se zabývají konstrukcí stránek. pravidel.

Úvodní film k seriálu: Žurnál Brig-IT Komix Patrik Šálek, [email protected] Můj milý deníčku, jako duchovi mi můj moderní šéf dal za úkol, abych se pohyboval v jedné nejmenované firmě a tak trochu na ně dohlížel a tak trochu jim pomáhal. Pro tuto misi jsem si původně vybral kódový název Brigáda v IT, ale to bylo moc dlouhé a tak jsem skončil u zkratky Brig-IT. Začal jsem předevčírem. Byl jsem se tam podívat a viděl jsem spoustu zajímavých věcí, ještě teď jsem z toho celý rozlítaný. Je tam skoro sto lidí a všichni dělají takové věci, kterým nerozumím. Pořád o něčem mluví takovým divným jazykem, ťukají do počítače a tváří se strašně zadumaně. Tak jsem je chvíli poslouchal. Mají tam projekty a ISO. Chvíli jsem tomu moc nerozuměl, pak jsem ale zjistil, co to ISO znamená. To je, že mají přesně napsané postupy, jak jsou takové projekty řízeny, dokumentovány, co vedoucí projektu (to je něco jako můj šéf) zajišťuje, jak vypadá tým apod. Například je přesně stanoveno, kdy se vytváří jaké dokumenty, kdo je vytváří, kdo schvaluje a kde jsou uloženy.

Je to ale složitější nebo možná jednodušší. Může se totiž říci, že některé projekty jsou sledovány podrobněji a některé méně – např. podle velikosti, složitosti, požadavků zákazníka apod. Takže na začátku projektu musí vedoucí zvolit odpovídající postupy a činnosti v souladu se stanovenými pracovními postupy. Vedoucí tak na začátku projektu např. musí zpracovat plán. Vybere si z firemních šablon, které uplatní. Stanoví, jak budou řízeny změny, rizika a další. Definuje způsob označování dokumentů, rozdělí odpovědnosti a potom sleduje průběh prací. Zákazníkovi tímto způsobem lze doložit zabezpečení úrovně jakosti produktu. Deníčku, řízení projektů – to je první věc, na kterou musím dávat pozor. Na chodbě jsem zaslechl, že ve firmě zavládl dobrý duch spolupráce. Šéf ale neříkal, že by posílal ještě někoho… Teď ale budu končit. I když duchové nespí, musí taky někdy odpočívat. Jsem z toho všeho nějaký celý rozlítaný. Až zas narazím na něco zajímavého, ozvu se.

Zajistit trasovatelnost nebo tápat? Tomáš Hrubý, [email protected] O tom co je potřeba dělat proto, aby projekt vývoje IS dobře skončil, bylo už napsáno mnoho stran. Zpravidla jde o popisy dílčích nutných, avšak nikoliv postačujících podmínek. Kompletní skládanka z těchto podmínek pak může vést k úspěchu. Jedním z významných předpokladů úspěchu je i koncept tzv. trasovatelnosti, který byl v minulých letech analytickým týmem KOMIXu rozvíjen. Přiblížení tohoto konceptu je předmětem následujícího článku.

Neznáte tyto situace? Zpravidla každý, kdo pracoval na nějakém projektu tvorby IS, se někdy dostal do situace, kterou bylo z nějakého důvodu velmi obtížné řešit. Neznáte náhodou některou z následujících situací? - Uživatel potřebuje změnu funkčnosti systému, ale je obtížné zjistit, kde všude se změna musí promítnout. - Je třeba zjistit, zda a jak jsou zapracovány všechny uživatelské požadavky, ale je to značně obtížné. - Existuje implementovaná funkčnost, ale nikdo neví, jaký uživatelský požadavek realizuje a proč tam vůbec je. - Testeři chtějí specifikovat testy, ale nevědí, jaké informace k tomu mají využít.

2

- Uživatelé by rádi věděli, které z jejich požadavků prošly systémovými testy, ale nevědí, jak to zjistit. Pokud vám některá z uvedených nebo obdobných situací připadá povědomá, pokud jste se v ní osobně ocitli a už ji nechcete opakovat, anebo pokud vás jen zajímá, co dělat, abyste se do takovéto situace nedostali, čtěte dál.

Co je to trasovatelnost? Vývoj systému si je možné představit jako transformaci výstupů jednotlivých etap projektu. Uživatelské požadavky jsou transformovány na globální analýzu a návrh, tato pak na detailní analýzu a návrh a dále na programový kód. Všechny zmíněné výstupy jsou dále vstupem pro tvorbu testů a testovacích případů. Projektové dokumenty se skládají resp. obsahují mnoho prvků. Například katalog uživatelských požadavků obsahuje jako své prvky jednotlivé uživatelské požadavky nebo hodnoty rozšiřujících atributů požadavků. Mezi všemi uvedenými prvky existují určité vztahy. Právě znalost těchto vztahů je jednou z podmínek, které mohou pomoci dovést projekt k úspěšnému konci. Co je tedy v tomto kontextu trasovatelnost (angl. tracebility)? Jde o možnost

vztahy mezi uvedenými projektovými výstupy dohledávat.

O vztazích a o vazbách Cesta k zajištění trasovatelnosti je v definici vazeb. Vazbou nazýváme záznam určitého vztahu mezi projektovými výstupy (formalizaci vztahu). Mezi projektovými informacemi může existovat určitý vztah a je na nás, zda mezi nimi vytvoříme vazbu. Transformace projektových výstupů znamená, že určitý prvek výstupu předchozí etapy je transformován na prvek (prvky) etapy následující. Náročnost zajištění trasovatelnosti spočívá ve skutečnosti, že v průběhu celého vývojového cyklu se setkáváme s transformacemi typu M:N. Jeden prvek může být transformován do více prvků následující fáze a opačně, jeden prvek může vzniknout transformací více prvků fáze předchozí. Vztahy mohou existovat buď v rámci dokumentace jednotlivých vývojových etap nebo mezi prvky dokumentů různých etap. Vazby říkají, jakými prvky globální analýzy a návrhu jsou pokryty jednotlivé uživatelské požadavky, do jakých prvků se promítnou v detailním návrhu, jakými částmi programového kódu jsou řešeny a jakými testy jsou ověřovány. Vzhledem k M:N transformacím zde existuje

obrovské množství vztahů. Obdobně je to se vztahy v rámci dokumentace jednotlivých vývojových etap. Těmi jsou například vztahy mezi uživatelskými požadavky.

Softwarová podpora trasovatelnosti Mít koncept trasovatelnosti zvládnutý teoreticky nestačí. Pokud jej budeme chtít skutečně aplikovat v praxi, nutně narazíme na otázku technické realizace vazeb. Objem projektových výstupů, které by měly být trasovány, může být značně veliký. Proto je nezbytné přesunout část práce na softwarové nástroje. Jiné „ruční“ podpůrné techniky (matice vazeb, atributy prvků s odkazy na jiné prvky apod.) dnes zpravidla nestačí. Zajištění trasovatelnosti je inženýrská úloha – tvorbu všech definovaných vazeb nelze zcela automatizovat. Lze ji ale vhodným softwarovým nástrojem efektivně podpořit. Podpora trasovatelnosti je součástí téměř všech nástrojů, které jsou při vývoji systémů využívány: - nástroje pro podporu procesního inženýrství (např. BPWin) - nástroje pro správu požadavků (např. DOORS)

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

pokračování ze strany 2

- nástroje pro analýzu a návrh systému (např. Telelogic Tau) - nástroje pro podporu kódování a obecná vývojová prostředí (např. Eclipse) - nástroje pro podporu testování (např. TestDirector) - a další typy nástrojů (konfigurační management, change management, řízení projektu apod.). V současné době je patrný trend integrovat více typů těchto nástrojů do samostatných systémů (např. podpora analýzy a návrhu, kódování a testování v nástroji Together ControlCenter) nebo do komplexních vývojových linek (např. integrace nástrojů DOORS – Telelogic Tau – TestDirector).

Přínosy kvalitní trasovatelnosti jsou nesporné. Tento článek akcentuje pouze oblast věcného procesu vývoje systému. Trasovatelnost však můžeme chápat v širším pojetí a zohlednit i proces řízení projektových prací. Potom by bylo třeba uvedený popis přínosů ještě výrazně rozšířit.

Úskalí trasovatelnosti

S čím nám nástroj může pomoci? Nezanedbatelný podíl práce při zajištění trasovatelnosti se v uvedených nástrojích musí stále provádět ručně. Sem patří například definice vazeb mezi uživatelskými požadavky, definice časové souslednosti aktivit procesních modelů nebo definice vazeb mezi testy v testovacích sadách. Patří sem dále velká část vazeb mezi výstupy jednotlivých vývojových etap. I úlohy tohoto typu však softwarové nástroje dokáží efektivně podpořit. Například v nástroji DOORS je možné, kromě vlastního vytvoření vazby mezi požadavky, definovat volitelné atributy vazeb, vazby zařazovat podle typů do skupin, celý systém vazeb přehledně vizualizovat a provádět nad ním velmi přínosné analýzy (např. analýzu dopadu změny požadavku).

Obrázek 2: Trasovatelnost mezi prvky diagramů a programovým kódem v nástroji Together ControlCenter vývojovou linku složenou obvykle z několika nástrojů - nástrojem pro správu požadavků počínaje a nástroji pro tvorbu a správu testů konče. Některé oblasti vztahů je zde opět možné automatizovat. Takováto integrace pak například umožňuje generování struktury testů a testovacích případů na základě

Využití a přínosy Klíčový přínos trasovatelnosti spočívá v existenci kvalitních podkladů pro změnové řízení systému. V průběhu vývoje i po dokončení musí být do systému a jeho dokumentace zapracovávány potřebné změny. Pouze díky trasovatelnosti je možné zjistit, kde všude je nutné změnu promítnout a jaké části programu musí být přetestovány. Bez kvalitní trasovatelné dokumentace nemůže tedy být systém úspěšně a ekonomicky udržovatelný. Znalost vztahů mezi prvky projektových výstupů je dále nezbytná pro realizaci vlastních vývojových činností. Znalost souvislostí umožňuje lepší pochopení věcné problematiky systému a tak jednotlivým vývojářům usnadňuje práci a zefektivňuje ji. Umožňuje dále zjistit, jaké vstupy je nutné pro práci využít a kde je hledat. Analytici potřebují vědět, jaké jsou vztahy mezi uživatelskými požadavky, návrháři musí vědět o všech vztazích prvků analýzy a testerům ukáže trasovatelnost cestu ke všem informacím, které je třeba pro tvorbu testů využít. Koncept trasovatelnosti významně přispívá i k redukci objemu projektových výstupů. Každou informaci udržujeme jen na jediném místě a pokud s ní potřebujeme pracovat jinde, jednoduše na ni vedeme vazbu (odkážeme se na ni). V popisu přínosů bychom mohli pokračovat. Významné je například využití trasovatelnosti pro sledování softwarových metrik (možnost zjištění pokrytí požadavků testy apod.).

Jaká má trasovatelnost úskalí, kde může být problém a na co si dát pozor? Předně, vybudování trasovatelnosti není zadarmo. Vytváření a údržba definovaných vazeb jsou časově náročné činnosti a je třeba počítat s tím, že odčerpají část projektových zdrojů a že na větším projektu si mohou vyžádat i nemalé investice. Ty se však vrátí. Za vynaložené peníze si kupujeme jakousi slevu na další budoucí výdaje (zvýšení efektivnosti vývoje, zlepšení udržovatelnosti apod.). Tvorba trasovatelnosti klade dále určité nároky na důslednost lidské práce. Každá změna se musí v systému vazeb odpovídajícím způsobem promítnout. Neaktuální vazby mohou způsobit více škod než vazby žádné. Zde opět výrazně pomáhají softwarové nástroje. Určitým problémem, před kterým každý projektový tým stojí, je optimální míra trasovatelnosti, tj. rozsah v jakém jsou projektové výstupy vzájemně propojeny vazbami. Jedním extrémem může být definice vazeb pro naprosto všechny dílčí prvky projektových výstupů, které společně mohou vytvářet nezvládnutelně složitou síť. Druhým extrémem může být vazby vůbec nedefinovat. Univerzální jednoznačné pravidlo neexistuje. Trasovatelnost se především musí vyplatit. Je nutné najít rozumný kompromis mezi náklady, které by bylo za ni nutné zaplatit, a mezi přínosy, které z ní můžeme vytěžit. Neméně důležité je, aby systém vazeb měl dostatečnou informační hodnotu, ale zároveň aby zůstal jednoduchý. Do detailu propracovaná spleť vazeb může být při její velké složitosti spíše problémem než přínosem. Nejhorší je dojít k tomu, že vše souvisí se vším. Při tvorbě každé vazby si je proto třeba klást otázku, zda je její záznam nezbytný a k čemu tuto informaci později využijeme. Vždy záleží na konkrétní situaci, na konkrétním projektu. Trasovatelnost je v projektech tvorby IS nezbytnou podmínkou. Výrazně může zvýšit přidanou hodnotu projektových výstupů. Pokud se nám ji podaří zajistit, můžeme čerpat z řady jejích přínosů. Nenahraditelnou úlohu zde hrají podpůrné softwarové nástroje, které dokáží ušetřit velkou část práce. Trasovatelnost má i svá úskalí. Pokud však budeme respektovat zásady zdravého rozumu, zajistíme jeden z klíčových faktorů úspěchu projektu.

Obrázek 1: Zobrazení vazeb mezi požadavky v nástroji DOORS Obrázek 3: Ukázka integrace nástrojů DOORS a Telelogic Tau V řadě oblastí lze vhodnými nástroji zajištění trasovatelnosti do určité míry automatizovat. Vazby jsou často automaticky vytvářeny souběžně se standardní tvorbou projektových výstupů a stávají se jejich přirozenou součástí. Tuto významnou pomoc softwarových nástrojů si mnohdy ani neuvědomujeme. Při dekompozici určitého prvku v analytickém diagramu je automaticky CASE nástrojem definována vazba mezi tímto prvkem a dceřinným diagramem, vazby jsou definovány při opětovném využití jednoho objektu ve více diagramech apod. Mnoho práce bylo uděláno v oblasti trasovatelnosti výstupů analýzy a návrhu systému na programový kód. Pro příklad lze opět uvést CASE nástroj Together ControlCenter. Zde je možné na základě určitých návrhových diagramů (Class diagram a Sequence diagram) generovat kostru programového kódu, přičemž mezi prvky těchto diagramů a částmi kódu je také automaticky uložena vazba. Změny v diagramech se pak automaticky promítají do kódu a opačně. Zajištění podpory trasovatelnosti napříč celým životním cyklem systému je složitější úlohou. Znamená to vybudovat komplexní

vytvořených analytických diagramů (např. Use case a Sequence diagramů) a zpětné vztažení výsledků testů k uživatelským požadavkům. Vybudování kvalitní vývojové linky není jednoduché a není levné. Je to však cesta ke komplexní podpoře trasovatelnosti a velké úspoře lidské práce. (viz obr. 3)

3

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

S Microstrategy na datový sklad Systém MicroStrategy 7i je jedním z řady produktů, které společnost KOMIX s.r.o. nabízí svým zákazníkům pro kvalitní prezentaci informací z datových skladů. Systém MicroStrategy 7i představuje kompletní platformu, která zahrnuje podporu celé oblasti tzv. Business Intelligence od definování faktů, dimenzí a reportů přes správu uživatelů až po sofistikovanou distribuci informací různou formou na základě rozličných podnětů. Firma Microstrategy byla založena roku 1989 v USA a může se pochlubit 2000 zákazníků včetně Bank of Montreal, Amway nebo Benetton. V České republice zatím počet zákazníků dosahuje spíše jednotek. Hlavní příčinu vidím kromě krátké tradice v poměrně vysoké ceně produktu. Za příslušnou cenu však zákazník dostává špičkový software s velikým potenciálním přínosem. Společnost KOMIX s.r.o. jako jeden z partnerů distributorské firmy Insight Strategy může přispět k dalšímu rozšíření tohoto bezpochyby kvalitního a výkonného software. Produkt MicroStrategy 7i se skládá z jednotlivých modulů, z nichž si zákazník podle svých potřeb poskládá cílovou konfiguraci. Základním modulem je Microstrategy 7i Intelligence Server, který zajišťuje zpracování požadavků od klientů, jejich převedení na SQL dotazy a spuštění těchto dotazů v relační databázi. Vlastní datový sklad může být vytvořen v libovolné databázi. Je potřeba pouze definovat tuto databázi jako ODBC zdroj. Po vrácení výsledků dotazu z databáze jsou tyto ve formě tabulky či grafu předány zpět klientovi. Všechna metadata (definice reportů, dimenzí, faktů, filtrů, uživatelů a jejich práv nebo databázových spojení) jsou uložena rovněž ve formě databáze. Podmínkou je opět pouze existence ODBC spojení na tuto databázi, takže i ta může existovat v libovolných SŘBD. Není pak problém provádět vývoj aplikace v prostředí dodavatele nad malým vzorkem dat a poté zkopírovat databázi metadat k zákazníkovi. Metadata lze takto také snadno zálohovat v důležitých momentech vývoje.

Microstrategy Intelligence Server dále zajišťuje řízení přístupových práv uživatelů, je možné omezit množství připojených uživatelů, počty najednou zpracovávaných dotazů nebo dobu provádění jednoho dotazu. Důležitá je práce s vyrovnávací pamětí (cache), která umožňuje rychlé zobrazení výsledků dotazu již v minulosti spočítaného a to i pro jiný typ klienta (Desktop, web). Po nahrání nových dat do datového skladu je třeba související reporty z cache vymazat, aby se nová data v sestavách objevila. Vhodné je i nastavení trvanlivosti cache, která by měla odpovídat periodě pumpování dat. Důležité je, že Microstrategy optimalizuje dotaz tak, aby se prováděl nad co nejmenší tabulkou. Pro podporu této vlastnosti je výhodné v datovém skladu navrhnout, či později doplnit příslušné úrovně agregací. Architektura s MicroStrategy 7i je důsledně objektová, definované objekty lze opakovaně použít na dalších úrovních. Například vytvořené filtry lze použít v reportech, metrikách nebo jako součást složitějších filtrů. Pokud se změní struktura nebo název datové tabulky, stačí tuto změnu promítnout v objektu typu fakt a odvozené objekty nadále bez problémů fungují. Systém hlídá závislosti mezi objekty, takže nedovolí smazat objekt použitý v jiných objektech. Během vývoje aplikace nám jsou nápomocny různé nástroje, které při vhodném pojmenování tabulek a sloupců umožní rychlou definici základních objektů typu fakt a atribut. Vedle klasických sestav typu „zisk podle distributora“ lze vytvářet i složité sestavy využívající rozsáhlý aparát matematických, statistických a dalších funkcí. Nelze upravit vygenerovaný SQL dotaz, ale pomocí mnoha voleb ho lze optimalizovat a ovlivnit počet vrácených řádků (inner / outer join apod.). Produkt MicroStrategy 7i je možno využívat v několika modifikacích v závislosti na kladených požadavcích. Microstrategy Desktop je aplikace typu těžký klient, která umožňuje tvorbu a správu veškerých objektů v projektu používaných. MicroStrategy Desktop tvoří konzoli, která integruje moduly Designer, Analyst,

Architekt a Administrator. Aplikace podporuje různé úrovně práce uživatele tj. spouštění a modifikace reportů, vytváření a definice nových objektů, návrh a konfigurace celých datových tržišť. Další možností využití produktu MicroStrategy 7i je použití modulu MicroStrategy Web, opět s třemi typy (Reporter, Analyst, Professional). Mezi Intelligence Serverem a webovým prohlížečem je v tomto případě umístěn ještě webový server, typicky MS Internet Information Server. Jedná se o čisté HTML řešení, takže na klientský systém nejsou kladeny žádné zvláštní požadavky. Kromě práce s objekty na nejnižší úrovni skýtá webové prostředí stejné možnosti jako Desktop, záleží jen na nastavení práv jednotlivých uživatelů nebo uživatelských skupin. Kromě sdílených sestav viděných všemi uživateli je možné ukládat si své sestavy do soukromých adresářů. Při práci s tak rozsáhlým systémem se samozřejmě nelze vyhnout některým problémům. Například exporty z prostředí MS7i Web do prostředí MS Excel, který je standardně podporován, byl citlivý na verzi

I

T

A

K

V

A

L

I

T

Petr Matoušek, [email protected]

MS Excel na straně serveru i u klienta. Další komplikace, s nimiž jsme se setkali, pramenily nejčastěji z nastavení národního prostředí OS serveru, databází nebo Microstrategy serveru. Občas chyba spočívala i ve špatném generování SQL dotazu, což je samozřejmě závažné, ale zatím se vše i díky podpoře dodavatele podařilo vyřešit. V krátkém článku jsem se nemohl zmínit o všech vlastnostech systému. Za zmínku stojí ještě například modul Narrowcast Server, který transformuje Intelligence Serveru požadavky zasílané e-mailem, faxem nebo SMS a vrací výsledky v přiměřené formě zpět na tato zařízení. Pro vývojáře je důležitý modul MicroStrategy SDK, který otevírá funkce používané v systému a umožňuje zahrnout objekty MicroStrategy 7i do jiných aplikací. Potřeba získávání významných podnikových informací z prostředí datových skladů hovoří jasně pro nasazení kvalitního software. Jsem rád, že na závěr mohu zodpovědně říci, že produkt MicroStrategy 7i takovým softwarem rozhodně je. http://www.microstrategy.com

Obr: Architektura MicroStrategy pro analýzu a distribuci podnikových informací

Selektivní šifrování dat uložených v databázi Jan Rada, [email protected]

Hrozby odcizení, pozměnění či zneužití citlivých dat Podle údajů odvozených z přehledu 2002 Computer Crime and Security Survey, který vypracoval americký Computer Security Institute ve spolupráci s FBI, došlo v minulém roce v USA k odcizení dat zhruba v 10% z několika set oslovených organizací; průměrná škoda přitom činila přes 6 milionů dolarů. Například v únoru 2003 bylo v Severní Americe oznámeno odcizení 8 milionů čísel kreditních karet Visa, MasterCard, American Express a Morgan Stanley internetovému obchodníkovi. Podle různých odhadů směřuje 60 i více procent úspěšných útoků zevnitř organizace. Vnitřní útočník, často v roli správce, nemusí překonávat firewally, běžně se přihlašuje s velkými privilegii a může využít svou znalost zranitelných míst systému. Důležitým opatřením proti vnitřnímu pokusu o neoprávněné přečtení či pozměnění citlivých dat a poslední instancí při útoku z vnějšku je zašifrování citlivých dat uložených v databázi, kde tato data stráví většinu svého životního cyklu. Poznamenejme ovšem,

4

že samotné šifrování obvykle pro utajení dat uložených v databázi nepostačí a že ochrana dat zahrnuje kromě utajení dat uložených v databázi i zajištění dalších bezpečnostních požadavků, například dostupnosti dat, utajení přenášených dat a utajení dokumentů uložených v souborovém systému.

Zašifrování pro utajení a autentičnost dat Zašifrování dat uložených v databázi je důležité opatření pro utajení dat vůči uživateli, který k nim nemá oprávněný přístup, ale mohl by potřebná přístupová práva nějak získat a data posléze odcizit. K šifrovacím funkcím bývají přiřazovány i různé kontrolní součty a hashovací funkce, sloužící pro kontrolu toho, že data nebyla pozměněna. Pro utajení dat uložených v databázi se běžně používají symetrické šifrovací algoritmy, které jsou rychlejší než asymetrické. Navíc v databázích se obecně méně hodí obvyklé postupy použití dvojice soukromý+veřejný klíč asymetrického algoritmu, protože data musejí být sdílena relativně dlouho velkým počtem uživatelů, a to jak pro čtení, tak pro vkládání, opravy a rušení.

Lze si ovšem představit využití asymetrického šifrování databázových dat v případě, že v bezpečnostních požadavcích je kladen důraz na autentičnost dat a odpovědnost uživatele za ně. Při vkládání či opravě dat by data byla zašifrována soukromým klíčem daného uživatele. Při čtení by pak data byla odšifrována pomocí veřejného klíče uživatele, který je zapsal. Veřejné klíče by byly sdíleny všemi oprávněnými uživateli, ovšem ostatním by musely být utajeny, pokud by mělo být zachováno utajení dat. Daný přístup by tak byl spojen s relativně velkými nároky na správu klíčů.

Správa šifrovacích klíčů Správa klíčů pokrývá celý jejich životní cyklus, tj. generování, distribuci, uchování, použití, rušení, změnu a obnovu. Správa klíčů je velice důležitou součástí ochrany dat; důvěrnost zašifrovaných dat je zajištěna pouze do té míry, do jaké je zajištěna důvěrnost šifrovacích klíčů. Klíče by měly být uchovávány odděleně od dat a v zašifrovaném tvaru či ještě lépe v důvěryhodném výpočetním prostředí hardwarového bezpečnostního modulu. Bývají pou-

žívány i kombinace různých způsobů uchování, například klíče pro zašifrování aplikačních dat se ukládají v zašifrovaném tvaru do oddělené databáze, a klíč vyšší úrovně, který slouží pro zašifrování klíčů s nižší úrovní, je uložen v hardwarovém bezpečnostním modulu, který pokud možno ani neopouští. V úvahu přichází též uchování šifrovacího klíče vyšší úrovně mimo výpočetní systém a jeho zadávání uživatelem, například prostřednictvím čipové karty, případně generováním klíče na základě silného hesla. Nejlepší správa klíčů je ovšem správa automatizovaná, minimalizující vliv lidského faktoru a možnost individuálního selhání. Operace zadání klíče uživatelem je pak vyhrazena pro situaci, kdy je potřeba obnovit klíč vyšší úrovně, například po zapomenutí hesla či selhání hardwaru.

Šifrovací práva autentizovaných uživatelů Aby oprávněný uživatel mohl pracovat s daty chráněnými šifrováním a neoprávněný ne, musí být spolehlivě ověřeny identity uživatelů a rozlišena resp. řízena jejich šifrovací práva.

A

Z

N

A

L

O

S

T

Z

K

Šifrovací práva jsou v zásadě práva přístupu k šifrovacímu mechanismu a šifrovacímu klíči použitému pro daná data. Navenek mohou mít i podobu práv přístupu k daným citlivým datům, zejména v případě plně automatizované správy klíčů. Šifrovací práva musí být nedostupná útočníkům, jinak by zašifrování citlivých dat bylo zbytečné. Například zašifrování kombinované s běžným řízením přístupu k datům na databázové úrovni by mohlo pomoci proti útočníkovi, který je schopen získat pouze přístup k databázovým souborům (nebo jejich zálohám) na úrovni operačního systému. Nepomohlo by již proti útočníkovi, který je schopen se přihlásit jako oprávněný uživatel do databáze. Což může být případ databázového administrátora, který může například změnit databázová přístupová práva libovolného uživatele, přihlásit se jako libovolný databázový uživatel poté, co změní jeho heslo, a zamést stopy po své činnosti v databázových auditních záznamech. Tytéž možnosti má samozřejmě i jakýkoli vnitřní případně vnější útočník, kterému se podařilo získat identitu databázového správce.

Bezpečnostní audit Generování a vyhodnocování auditních záznamů o činnostech uživatelů slouží zejména k tomu, aby případné selhání šifrování a ostatních bezpečnostních opatření neproběhlo nepozorovaně, aby bylo možné prokázat nevinu či naopak odpovědnost příslušných pracovníků a doporučit zdokonalení ochrany. Audit je nezastupitelný pro kontrolu činnosti bezpečnostního správce a uživatelů, kteří mají přístupová práva k citlivým datům a mohli by je zneužít pro jiné než pracovní účely.

U

Š

E

N

O

S

T

P

R

Při auditu je nutno řešit otázky objemu auditních záznamů a postupů zjišťování podezřelých činností, například neobvyklých přístupů k citlivým datům. Pro tyto účely jsou žádoucí možnosti pružného řízení rozsahu generování a prohlížení auditních záznamů, případně možnosti exportovat je pro další využití, například pro vyhodnocení pomocí analytických nástrojů. Důležitou podmínkou použitelnosti auditních záznamů je jejich důvěryhodnost. Záznamy by stejně jako šifrovací práva a mechanismy měly být chráněny i proti útokům správců. Měly by například být uloženy odděleně od dat, v zašifrovaném tvaru, s kontrolou integrity.

Centrálně spravované selektivní šifrování v databázi Selektivním šifrováním rozumíme šifrování vybraných sloupců databázových tabulek. Hlavním důvodem pro selektivnost šifrování je výkon. Při šifrování celé databáze či databázového souboru by byla šifrována nejen ta aplikační data, která případně nepotřebují ochranu, ale i „režijní“ a pracovní data (hlavičky uložení dat, tabulky transakcí a volného prostoru, adresy a odkazy atd.). Šifrování celé databáze by tak mohlo být vhodné pro okrajové požadavky – například pro menší databáze s velkým podílem citlivých položek nebo pro ochranu proti vyvození důvěrných informací z údajů systémového katalogu. V ideálním případě je selektivní šifrování centrálně spravované. Centrální správa umožní snáze prosadit konzistentní politiku ochrany dat v celé organizaci a svěřit tento úkol specializovanému bezpečnostnímu správci, který nebude potřebovat zna-

O

F

E

S

I

O

N

A

L

losti konkrétních aplikací a databázových a operačních systémů. Selektivní šifrování lze realizovat v databázové či v aplikační vrstvě. Hlavní výhodou první možnosti je aplikačně průhledná ochrana dat. Kdyby šifrování bylo volané z aplikační vrstvy, byla by k jeho zavedení a ke každé změně šifrovací politiky nutná účast vývojářů aplikací. Principem aplikační průhlednosti je zašifrování sloupce tabulky, náhrada původní tabulky stejnojmenným dešifrujícím pohledem na zašifrovanou tabulku a zavedení šifrujících triggerů pro modifikace dat tohoto pohledu. V ideálním případě jsou uvedené operace prováděny automatizovaně – bezpečnostnímu správci stačí pouze vybrat sloupec a zmáčknout tlačítko. Nositelem šifrovacích práv je obvykle databázový uživatel. Vlastní šifrovací operace může být výhodné provádět mimo databázi, pokud takto lze využít existující šifrovací mechanismus či rezervní výpočetní kapacity nebo zajistit bezpečnější výpočetní prostředí, například pomocí hardwarového bezpečnostního modulu. V praxi jsou i přes aplikační průhlednost někdy nutné dílčí úpravy aplikace resp. její databázové vrstvy. Například triggery, defaultní hodnoty a integritní kontroly navržené pro nezašifrovaný sloupec obecně nebudou fungovat po jeho zašifrování a jejich funkčnost je vhodné přesunout do šifrujících triggerů. Většinu takových úprav by ovšem bylo nutné řešit i při šifrování na aplikační vrstvě, nemluvě o dalších potřebných úpravách.

I

T

A

K

V

A

L

I

T

jednou provždy a pro zpracování v jediné aplikaci - automaticky budou utajeny při přístupu z ostatních aplikací, například z univerzálních nástrojů databázového správce. Spolehlivost takového „opatření“ samozřejmě závisí mimo jiné na tom, zda útočník nemůže vyvinout svou aplikaci využívající stejné šifrovací funkce a klíče.

Realizace selektivního šifrování Pro aplikačně průhledné selektivní šifrování je možné použít několika hotových řešení, například produktu Secure.Data od Protegrity, DbEncrypt od Application Security a Encryption Wizard for Oracle od RDC. Největší bezpečnost dat, funkčnost a komfort poskytuje zřejmě produkt Secure.Data, který se vyznačuje například řadou opatření pro ochranu šifrovacích a auditních mechanismů před útoky databázového správce. Při speciálních požadavcích může být potřebný či užitečný vlastní vývoj selektivního šifrování. Na trhu je k dispozici řada knihoven šifrovacích funkcí a SW či HW modulů s API, které tento vývoj různou měrou podporují. Vlastní vývoj by například asi mohl být finančně výhodný při malých nárocích na bezpečnost citlivých dat jedné aplikace nad databází Oracle, která je dodávána s knihovnou základních šifrovacích algoritmů.

Šifrování na aplikační vrstvě může být výhodné, pokud citlivé položky jsou určené

PRONÁJEM POČÍTAČOVÉ UČEBNY • dostupná lokalita • kvalitní zázemí • moderní počítačová a projekční technika • možnost celodenního, půldenního či týdenního pronájmu za velmi příznivé ceny

Volejte: +420 225 989 811

www.komix.cz

Ochrana dat Ztratilo se Vám někdy něco, nebo Vám něco ukradli? Jistě mi dáte za pravdu, že kromě zlého pocitu Vám vznikly i jiné problémy. Při ztrátě dokladů je těch problémů ještě mnohem více. Tomu všemu se dá předejít koupením toho správného zabezpečení. Že je jich na trhu hodně, dokazují reklamy, které dostávám každý týden do své dopisní schránky. Přistupujeme i k ochraně elektronických informací s takovou péčí jako k hmotnému majetku? A existuje vůbec nějaká možnost chránit si tyto informace před „nenechavci“? Můžu Vás uklidnit, tyto možnosti tady jsou a něco si o nich povíme. Již v minulosti při psaní dopisů sdělujících něco důležitého vznikla potřeba tyto informace zašifrovat. Nejjednodušší formou bylo, v docela nevinném textu, do těch správných míst doplnit text naší zprávy. Příjemce vlastnil tabulku, podle které se dostal k zašifrovanému textu. Tato metoda v době počítačů se jeví k pousmání, ale v té době byla docela efektivní. Doba nám dává za pravdu, jak je důležité si

své informace chránit. Je možné připomenout příběh šifrovacího stroje Enigma, který používali Němci za druhé světové války. Spojencům se v tomto případě podařilo jeden exemplář ukořistit a napomoct tak k vyluštění šifry, kterou se šifrovaly důležité zprávy pro velitelství Německé armády. Dá se říci, že rozluštění této šifry mělo nemalý vliv na průběh Druhé světové války. A co dnes, když nás bankovní ústavy přesvědčují o výhodách elektronické komunikace a platbách kreditními kartami, existuje nějaké riziko zcizení našich dat? Co musí takový bezpečný systém splňovat, je shrnuto v následujících bodech: • důvěrnost informací – systém musí zabezpečit, že neautorizované subjekty nebudou mít možnost přístupu k důvěrným informacím, • integrita - systém musí zabezpečit informace proti neautorizované modifikaci, • neodmítnutelnost odpovědnosti – systém musí zabezpečit prevenci proti ztrátě schopnosti přesvědčit třetí nezávislou stranu

Martin Janček, [email protected] o přímé odpovědnosti subjektu za odeslání, případně přijetí zprávy. Otázkou zůstává, jak tyto předchozí body uskutečnit. Fyzická ochrana přenášených dat by byla náročná, takže nám zbývá ochrana logická a to pomocí šifrování. Znamená to zašifrovat data na straně odesilatele, odeslat je a na straně příjemce zase dešifrovat. Kvalita logické ochrany zprávy je dána šifrovací metodou, typem užitého algoritmu, jeho aplikací a délkou šifrovacího klíče. Je možné říci, že rozlišujeme dvě metody pro zabezpečení našich dat: Symetrická metoda (Symetrická kryptografie), Asymetrická metoda (Asymetrická kryptografie).

Symetrická kryptografie Princip této kryptografie spočívá v tom, že stejný klíč, který byl použit k zašifrování zprávy na straně odesílatele, bude použit i na straně příjemce pro dešifrování zprávy. Z toho vyplývá nutnost před začátkem ko-

munikace poslat šifrovací klíč spolu s dalšími údaji příjemci. Současná výpočetní technika aplikuje algoritmy (např. DES, TRIPLEDES, AES) téměř v reálném čase. Na druhé straně pomocí té samé techniky je možné data dešifrovat i bez znalosti privátního klíče. Pomocí dostupných metod je možné docela přesně určit, za jak dlouho je možné data dešifrovat. Tyto metody jsou však nákladné. Volbou délky klíče, který se použije pro šifrování, lze čas potřebný pro rozluštění šifry podstatně ovlivnit. Co uvádějí dostupné prameny? Při použití klíče s délkou 40 bitů je možné zdolat šifru za pomoci paralelního algoritmu s použitím 1200 propojených počítačů za necelé 4 hodiny. Doba rozkódování s délkou klíče roste velmi rychle (128 bitů 1000 počítačů a 3.10exp22 let). Použití symetrických algoritmů představuje způsob, jak zabezpečit důvěrnost. Ale neřeší požadavek neodmítnutelnosti odpovědnosti. Nelze totiž určit, která strana zprávu odeslala, a která přijala. Každá strana používá stejný klíč.

5

A

Z

N

A

L

O

S

T

Z

K

Asymetrická kryptografie Oproti symetrické kryptografii se zde užívá dvojice klíčů. Tuto dvojici klíčů si vygeneruje uživatel pomocí některého z běžně dostupných produktů. K tomuto je například možné použít OpenSSL http://www.openssl.org. Princip použití spočívá v tom, že data šifrovaná jedním z klíčů lze dešifrovat pouze pomocí druhého z dvojice klíčů a naopak. Jeden z nich, takzvaný privátní klíč má jenom majitel, zatímco druhý klíč je publikován. Pokud známe vlastníka veřejného klíče, kterým jsme zprávu dešifrovali, známe i odesílatele. Protože je veřejný klíč obecně znám všem, nelze zašifrovanou zprávu považovat za zašifrovanou v plném smyslu slova, ale pouze za podepsanou. Celý tento systém pro šifrování a podepisování zpráv pomocí asymetrické kryptografie pracuje tedy následovně. Zpráva je na straně odesilatele nejpr-

U

Š

E

N

O

S

T

P

R

ve podepsána privátním klíčem odesílatele a potom šifrována veřejným klíčem příjemce. Na straně příjemce je zpráva nejprve dešifrována privátním klíčem příjemce a teprve potom je pomocí veřejného klíče odesilatele ověřena identifikace.

Certifikační autorita a certifikáty K čemu slouží certifikační autorita? V předchozích řádcích jsme uváděli dvojici klíčů. Jistě mi dáte za pravdu, že uchovávat a zabezpečit klíče někdy bývá problematické. Nestačí se starat o svůj privátní klíč, je nutno uchovávat veřejné klíče všech komunikujících účastníků a k nim jednoznačnou identifikaci vlastníků těchto klíčů. V tomto nám může pomoct právě certifikační autorita, která tyto služby poskytuje. Certifikační autorita vystupuje při vzájemné komunikaci dvou subjektů jako třetí důvěryhodný sub-

O

F

E

S

I

O

N

A

L

může snadno komunikovat s partnerem či zákazníkem kdekoli na světě. Zákon 3.: Cena obchodní transakce se bude snižovat Celý proces marketingu, objednávek, prodeje a zákaznického servisu může být využitím Internetu do značné míry automatizován a tím mohou být zredukovány náklady spojené s obchodováním. Možnost nakupování po Internetu také snižuje minimální „aktivační energii“, kterou musí zákazník pro uzavření obchodu vyvinout. I ten zákazník, který si raději půjde koupit zboží do obchodu, aby si jej mohl fyzicky prohlédnout, použije Internet pro výběr obchodu, zjištění parametrů zboží a porovnání cen.

T

A

K

V

A

L

I

T

jekt, který prostřednictvím jím vydaného žeme kdykoliv ověřit se znalostí veřejného certifikátu jednoznačně svazuje identifikaci klíče certifikační autority, respektive jejího subjektu s jeho dvojicí klíčů,respektive s jeho certifikátu. Existence certifikační autority digitálním podpisem. Tím pádem se certifi- také umožňuje důvěryhodnou komunikaci kát stává elektronickým průkazem totožnos- i subjektů, jenž se navzájem fyzicky nikdy ti. Certifikát obsahuje veřejný klíč, jméno nepotkaly nebo neabsolvovaly složitou proa další údaje zajišťující nezaměnitelnost sub- ceduru vzájemné důvěryhodné výměny svých jektů. Obsahuje též datum počátku platnosti, klíčů. Další službou, kterou certifikační autodatum ukončení platnosti, jméno certifikač- rita poskytuje, je možnost zrušení certifikátu. ní autority, která certifikát vydala, sériové Toto oceníme při ztrátě našeho privátního číslo a některé další informace. Certifikační klíče. Každá certifikační autorita poskytuje autorita zaručuje správnost jí vydaného cer- seznam odvolaných certifikátů a stvrzuje ho tifikátu, odstraňuje nutnost smluvní důvě- svým podpisem. ryhodné výměny klíčů mezi dvěma subjekty Zdá se, že principy ochrany elektronických navzájem a jejich dohoda spočívá pouze dat jsou propracovány a je možné se na ně v domluvě o společně uznávané certifikační spolehnout. Tento článek měl přiblížit možautoritě. Důležité je, že utajovaná data na nosti, jak lze svá data chránit před možnými straně klienta jsou redukována pouze na „vetřelci“. Je však důležité neopomenout bezpečné uchovávání privátního klíče, pro- lidský faktor, který nám většinou přinese tože ostatní je řešeno certifikáty. Ty si mů- nepředpokládané problémy.

Internet a cena informací Informace zdarma?

I

Pokud je o takovýto software zájem, začne jej používat široká komunita uživatelů a vývojářů, kteří budou odhalovat a odstraňovat chyby a bezpečnostní rizika, přidávat další funkčnost a provádět úpravy podle svých potřeb. A to vše díky Internetu paralelně a s rychlostí, která je nesrovnatelná s tradičním modelem vývoje, kdy se vývoje a testování účastní jen relativně malá skupina programátorů a testerů. Výsledkem má být stabilní a ověřený software, založený na otevřených standardech, nezávislý na monopolním výrobci. Příkladem, že tento způsob vývoje funguje, je nejen Linux, ale i mnoho dalších, v úvodu zmíněných projektů. Open Source už není doménou jen programátorských fandů, programujících zdarma pro své potěšení a pro zvýšení své prestiže nebo studentů, učících se na zdrojovém kódu. Do vývoje OSS se častěji zapojují firmy, které se z uživatelů stávají vývojáři. Do Open Source také investují značné částky velké technologické firmy (IBM, Oracle, Dell, Computer Associates, Intel, HP, Sun) a podle Olliance Consulting Group tyto investice rostou každým rokem o 35 %. Návratnost takovýchto investic je rychlá – společnost IBM v roce 2002 uvedla, že miliarda dolarů investovaná do OSS – především do podpory Linuxu a převodu portfolia SW na Linux, se téměř celá vrátila během jednoho roku. OSS slaví úspěchy především v oblasti Internetu – má podíl více než 65% web serverů. Například IBM založila na OSS a otevřených standardech svá e-business řešení. Základem IBM HTTP Serveru je Apache, IBM WebSphere Studio je založeno na open source nástroji Eclipse. Stále více významných společností zahrnuje OSS komponenty do své IT infrastruktury.

Tomáš Vahalík, [email protected]

Rizika OSS z pohledu uživatele

V poslední době stále více organizací zvažuJistě jste si všimli, že v poslední době lze na je výhody používání OSS. Ovšem to, že za OSS Internetu najít zdarma nejenom informace nemusíte platit licenční poplatky, neznamená, o počasí, vlakových spojích, programech kin či že nebudete mít náklady spojené s implerad pro zahrádkáře. Zdarma lze najít i takové mentací a provozem. informace, o kterých by se dalo předpokládat, Pro uživatele je rozhodující, jak jsme si ukáže je to střežené firemní tajemství, „knowzali dříve, právě podpora softwarového pro-how“ na kterém lze vydělávat a získávat duktu. Nyní se sice objevuje stále více firem konkurenční výhody. Zkuste například v Goposkytujících podporu OSS, problémem však oglu (nebo jiném vyhledávači – samozřejmě může být nedostatek zkušeností těchto firem zdarma) vyhledat odkazy podle hesla „best s podporou rozsáhlejších provozních aplikací practices“ nebo „design patterns“. založených na OSS. Obdobné je to při hledání Zdarma jsou nejen informace, ale i prograzaměstnanců. Je jednodušší najít zkušeného my. A to ne ledajaké. Namátkou, od operačadministrátora např. Solarisu, než Linuxu. ního systému (Linux), přes vývojové nástroje Některé OSS produkty se osvědčily v rozsáh(Eclipse), databáze (MySQL), web server lých podnikových systémech (Linux, Apache), (Apache), kancelářský balík (Open Office) jiné se však vyvinuly z menších aplikací. Napříaž po J2EE aplikační server (JBoss). Existuje Software jako služba klad Open Source databáze za sebou nemají tolik kategorií programů zdarma (někdy se Software má mnoho ekonomických chadlouhodobé reference o použití v rozsáhlých vzájemně překrývajících), že není úplně jed- rakteristik odlišných od fyzického zboží, provozních systémech, což je z hlediska výběnoduché se v nich vyznat (Free Software, Pu- svým charakterem má blíže ke službě. Podle ru databáze dost podstatná informace. blic Domain, Copyleft, GPL’ed, Open Source, odhadů je až 95% kódu psáno pro speciFreeware ...). fické prostředí firmy (ať už vlastními silami, Budoucnost OSS Jak je možné, že v době přechodu do věku přizpůsobováním komerčního SW produktu informační společnosti, kdy by firmy mohly nebo nákupem softwaru vyvinutého na Přes uvedená rizika lze očekávat, že se bude na prodeji informací vydělávat, je stále čas- míru), proto znovupoužitelnost takovéhoobjevovat stále více řešení založených na OSS tějším jevem, že informace i software jsou to kódu pro další prodej je relativně nízká. a to především tam, kde licenční poplatky za zdarma? Platí zde stále ještě zákony tržního Pouze 5% kódu je psáno pro software na komerční produkty představují podstatnou hospodářství? část celkových nákladů. “krabicový“ prodej. Navíc je obvyklé, že značOpen Source model však není vhodný ná část nákladů životního cyklu projektu pro veškerý software. Najde uplatnění ve se týká fáze údržby, tj. technické podpory, Internet a tři zákony vrstvě infrastruktury (operační systémy, korozšiřování a přizpůsobování měnícímu se „kyber-ekonomiky“ munikační SW), méně často potom v oblasti prostředí firmy. Podle Gartner Group je to Odpověď na tyto otázky je nutné hledat typicky 30% ale často i více než 50%, podle middleware (web servery, aplikační servery, ve způsobu, jakým Internet ovlivňuje téměř ButlerBloor Computer Research je to dokondatabázové servery, vývojové nástroje), oblast všechny oblasti našeho života, ekonomiku ce 66%. I když tato čísla nemusí být přesná, aplikací na míru bude nadále doménou monevyjímaje. Internet zásadně usnadňuje pu- podstatné je, že značná část mzdy vývojářů delu tradičního vývoje. blikování, vyhledávání a přenášení informací je placena za práci, kterou není možné proZatímco příznivci Open Source vidí v souodkudkoli na světě. Proto bývá Internet ozna- dávat opakovaně, jako je tomu u krabicovéčasných miliardových investicích velkých firem čován jako technologie, která nám otevírá ho softwaru. do OSS potvrzení životaschopnosti OSS modeinformační věk, a je tím, čím byl vynález parlu, skeptici v tom spatřují začátek konce OSS, Cena za software, kterou je zákazník ochoního stroje pro industriální věk. Internet ovliv- ten platit, je často více než užitnou hodnotou neboť podle nich komercializace způsobí, že Jak vydělat na OSS ňuje ceny na třech úrovních, proto se hovoří softwaru ovlivněna očekávanou kvalitou dalLze vydělávat na něčem, co je zdarma? OSS přestane přitahovat nadšené individuální o třech zákonech „kyber-ekonomiky“: ší podpory. Zákazník pravděpodobně nebude Každý produkt na trhu má zpravidla svůj vývojáře a bez široké komunity takovýchto Zákon 1.: Cena informace se bude snižovat chtít koupit proprietární software od krachu- doplňkový produkt, přičemž oba tyto pro- nadšenců ztratí OSS podstatu své existence. Tento zákon vychází z působení dvou faktorů: jícího dodavatele nebo od „ičáka“ programu- dukty se obvykle kupují společně. Například Otázka budoucnosti Open Source Softwaru a) nízká cena publikování informací na jícího doma v obýváku, protože zde je další doplňkem k hardware je operační systém. tedy zůstává - otevřená. Informace a software zdarma nejsou anoInternetu ve srovnání například s papí- podpora problematická. Firmy se snaží snížit cenu svých doplňkových rovými médii Software se svým charakterem tedy více produktů až na nulu, aby stoupla poptávka málie, ale je to stále zřetelnější tendence b) snaha firem upozornit na sebe nabídkou blíží službě, je to dlouhodobý vztah mezi do- po hlavním produktu. Netýká se to jen SW vývoje, která není v rozporu s tržními principy některých užitečných informací či soft- davatelem a zákazníkem. Přechod od modelu, a HW, možná také znáte obchod s potravi- a se kterou bude nutné v nejbližších letech waru zdarma kdy se platí za kopii SW jako za kus zboží, nami, který nabízí zdarma dovoz nákupu počítat. Díky kombinaci obou faktorů dochází k modelu, kdy dominantní je cena služby, podle telefonické objednávky. Odkazy: k tomu, že informací i softwaru zdarma je je jednou z odpovědí na otázku položenou Existují tyto základní modely jak vydělat Michel Bauwens: The Three Laws Of the Cyna Internetu stále větší množství. Informace v úvodu. na OSS: zdarma slouží firmám jako návnada, forma • Příjmy pocházejí ze služeb – školení, kon- ber-economy, marketingu. Bez toho, aniž by nabízely Open Source Software zultací, technických podpor, nikoli z po- http://users.skynet.be/michel.bauwens/ některé užitečné informace zdarma, si jich platků za licenci. professional/articles/digitalrevolution/ Zvláštní kategorií softwaru zdarma je na Internetu nikdo nevšimne, a dříve či poz- Open Source software (OSS). Na tomto pří• Příjmy ze SW nadstaveb, doplňků a spe- threelaws.htm ději se objeví konkurence, která je nabízet kladě si ukážeme, že software zdarma může cializovaných modulů k OSS, které jsou • Eric S. Raymond: The Magic Cauldron zdarma bude. Problémem se naopak stává mít své ekonomické opodstatnění. Vznik noprodávány podle tradičního modelu. schopnost orientovat se v množství informací vého modelu vývoje softwaru umožnil právě • OSS zvýší prodej hlavního produktu, kte- http://catb.org/~esr/writings/cathedrala schopnost informace využít. rým je hardware (například drivery pro bazaar/magic-cauldron/ Internet. Tento model spočívá v tom, že Zákon o snižování ceny informace se uplat- jádro SW produktu je co nejdříve zveřejněgrafické karty nebo operační systém pro • Olliance Consulting Group: Open Source ňuje i uvnitř organizací. Schopnost firmy no i se zdrojovými kódy a dáno uživatelům Software Position Briefing počítač). uspět v konkurenci je závislá na sdílení zna- k dispozici zdarma s licencí, která umožňuje • Prodej příslušenství k OSS - od hrníčků http://www.oss-institute.org/newspdf/ lostí mezi jejími zaměstnanci. Společnosti, je- volné kopírování a modifikaci zdrojového a triček až po knihy a dokumentaci. OSSIPosition011503.pdf jichž zaměstnanci hlídají své „know-how“ pro kódu. Licence ale neumožňuje komerční Výše uvedené možnosti, jak ekonomicky • Sanjay Murthi: Free and Clear? udržení vlastní pozice, nemohou uspět. zneužití – tedy prodej takovéhoto softwaru. získat na softwaru zdarma, nejsou jediný Zákon 2.: Cena komunikace se bude sni- Umožňuje jej však zahrnovat do komerčních druh zisku. Dalším a možná ještě podstat- http://www.intelligententerprise.com/ žovat aplikací, účtované poplatky ale nesmí zahr- nějším přínosem z volného poskytování 030405/606feat3_1.shtml Již dnes znamená Internet globální komuni- novat tento software, pouze to, co k němu informací, je získání vlivu a dobrého jména „experta“, což může být k nezaplacení. kaci za lokální ceny. Každý obchodní subjekt prodejce přidá.

6

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

Vyplatí se vůbec testovat software? Dan Petřivalský, [email protected] Návratnost investic – ROI – Return on Investment. To je obchodní zaklínadlo dnešní doby. Snad nikdo si dnes nedovolí udělat jakoukoliv „jen trochu větší investici“ bez důkladného propočtu její očekávané návratnosti. Nebudeme se zabývat definicí pojmu „jen trochu větší investice“, její velikost záleží na velikosti a finanční síle investora. Příkladem „větší investice“ bývá podnikový software. V případě investice do nového podnikového informačního systému či jen jeho nové verze si každý(!) klade otázky: Je nutné jej pořizovat? Nestačí nám to co, máme teď? Co bude stát? Vyplatí se? Méně lidí si už položí otázky: Jak zajistím, že dostaneme aplikaci v pořádku? Co se stane, když nový software bude mít podstatnou chybu, na kterou se hned nepřijde? Nebo otázku z nadpisu - Vyplatí se vůbec testovat software? Zda je únosné podstoupit riziko spojené s používáním neotestované aplikace, je jedním úhlem pohledu na problém. Druhým je, jakým způsobem testování provádět a zda investovat do zefektivnění testovacího procesu. Při vývoji rozsáhlých systémů se investoři často snaží ušetřit právě na testování. Většinou spíše jeho okleštěním než zefektivněním. Podívejme se na věc z obou zmíněných úhlů:

ÚHEL PRVNÍ (ANO ČI NE?) Asi nikdo neočekává, že účetní firma o dvou zaměstnancích bude složitě testovat svůj účetní software nebo textový editor. Naopak málokdo by uvěřil tvrzení, že nějaká banka spustí své internetové bankovnictví bez jeho předchozích důkladných testů. Na Carnegie Mellon University zjistili, že opravit chybu před spuštěním živého provozu softwarové aplikace je 40x až 1 000x

levnější, něž když se na chybu přijde až v produkčním prostředí. Čím je systém pro jeho provozovatele důležitější, čím častěji je inovován nebo čím méně má jiných instalací, tím častěji bývá uživatelem-zákazníkem testován. Je obtížné stanovit jednoduchou matematickou formulku pro rozhodnutí zda testovat či ne, vlastní rozhodnutí je proto velmi subjektivní. Investor si klade na misky vah možná rizika a svůj odhad, zda je systém dostatečně důležitý, dostatečně často inovován či dostatečně unikátní, aby mělo smysl jej testovat. Rozhodování to nemusí být jednoduché, pravidlo však zní: „mám-li sebemenší pochybnost, musím testovat“.

ÚHEL DRUHÝ (JAK A ČÍM?) Pro podporu procesu testování existuje celá řada softwarových nástrojů. Protože jejich nasazení znamená investici do jejich pořízení, vyškolení pracovníků a další náklady (dále jen ŘEŠENÍ), vyhodnocuje investor návratnost svojí investice (ROI) do testovacího software. Definujme návratnost investice v procentech jako zlomek: ROI = (NQB/NC) x 100%, kde NQB je čistý měřitelný přínos – rozdíl mezi přínosem dosaženým prostřednictvím ŘEŠENÍ ve srovnání se stávajícím (nebo alternativním) postupem. Hodnota NQB může znamenat přímé úspory, zisk nebo nepřímé náklady na činnosti, které by jinak musely být prováděny. NQB lze stanovit zpětně či odhadnout na několik let dopředu. NC jsou čisté náklady - rozdíl mezi celkovými náklady na ŘEŠENÍ a náklady spojené se stávajícím (nebo alternativním) postupem (které nemusí být vůbec žádné).

ROI je poměr souhrnného čistého přínosu k souhrnným čistým nákladům. Jestliže je hodnota ROI vyšší než 100 %, pak se vložená investice ve vyhodnocovaném období více než vrací. Jako poměrová veličina může ROI sloužit nejen porovnání uvažovaného ŘEŠENÍ se stávajícím stavem, ale i k porovnání dvou ŘEŠENÍ mezi sebou.

Případová studie velké americké pojišťovny Společnost IDC zpracovala analýzu ROI pro ŘEŠENÍ společnosti Mercury Interactive, leadera na trhu testovacích produktů, kterou KOMIX s.r.o. zastupuje. Analyzovaná pojišťovna má zhruba 35 000 zaměstnanců, z toho asi 1 000 v IT. Před vypsáním výběrového řízení na ŘEŠENÍ využívala již zastaralou alternativu na mainframu. Vítězné ŘEŠENÍ Mercury Interactive pokrývá komplexní správu procesu testování, automatizované funkční testování a zátěžové testování. ŘEŠENÍ bylo nejprve nasazeno na nově implementovaný CRM systém. Bylo vytvořeno 95 skriptů pro automatizované testování, které jsou využívány k přetestování systému asi jednou za tři týdny, což je interval, v jakém dochází ke změnám na CRM aplikaci. Se systémem pracuje více než 4 000 uživatelů, kterým je potřeba zajistit dostatečný výkon aplikace. Výpočet ROI pro funkční testování: • NQB – Příprava testů bez ŘEŠENÍ a s ním se ukázala jako rovnocenná. Úspora (za práci manuálních testerů) při automatizovaném provádění testů však byla vyčíslena na 71 825 USD ročně. Úspora nákladů za pronájem 18 stolních počítačů pro použití při manuálním testování činí 7 560 USD za rok. Celkový roční čistý přínos projektu je 79 385 USD.

• NC – Náklady na licence a školení činí 25 000 USD. • ROI = 79 385 USD / 25 000 USD x 100% = = 317,54% v jednom roce. Více než trojnásobná návratnost vložených prostředků během jediného roku je jistě důvod ke spokojenosti všech účastníků projektu. Samotné návratnosti investice bylo dosaženo za méně než půl roku. Výpočet ROI pro zátěžové testování: • NQB – zvýšení výkonnosti aplikace a tím i produktivity práce byl jediný přínos, pro který byl vyhodnocován ekonomický užitek (nepokoušíme se určit obchodní hodnotu silnějšího konkurenčního postavení nebo zabránění ztráty obchodů způsobené špatnou výkonností aplikace). Čistý přínos za tříleté období přesáhl 825 000 USD. • NC – Náklady na licence, technickou podporu, konzultace a školení dosáhly 670 000 USD během tří let. • ROI = 825 000 USD/670 000 USD x 100% = = 123,13% za tři roky. Investice vložená do zátěžového testování se vrátila za dobu kratší tří let, což je považováno za dobrou investici. V porovnání s funkčním testováním je to třetinová návratnost za trojnásobné období, což nepůsobí tak impozantně. Je však nutné brát v potaz, že velkou část nákladů tvořila počáteční cena licencí a množství nutných konzultačních služeb je rok od roku nižší. ROI vyhodnocované za 4. a 5. rok již budou vypadat mnohem lépe. Závěrem lze říci, že investice do ŘEŠENÍ Mercury Interactive se mohou vracet velmi rychle, stačí si zvolit vhodnou konfiguraci (s tím vám v KOMIXu rádi pomůžeme) a příznivé výsledky se objeví už v prvním roce používání.

Rozhovor s Ing. Petrem Srdínkem o průběhu projektu pro GE Capital Multiservis Účastníci: Petr Srdínko za GE Capital Multiservis, Dan Petřivalský a Vlasta Vršecký za KOMIX Společnost KOMIX ve spolupráci se společností LBMS realizovala v GE Capital Multiservis v průběhu roku 2002 a 2003 projekt „Systém pro podporu vývojového cyklu software“, který měl 4 etapy: 1. Evidence požadavků 2. Testování 3. Analýza, datové a funkční modelování 4. Konfigurační řízení Společnost KOMIX byla dodavatelem etapy „Testování“, která zahrnovala vytvoření metodiky a zavedení specializovaných SW nástrojů na podporu a automatizaci fáze testování. Zeptali jsme se interního sponzora tohoto projektu v GE Capital Multiservis Petra Srdínka jak vidí průběh projektu a jeho výsledky s odstupem tří měsíců po jeho ukončení. Jaký byl prvotní impuls v GE Capital Multiservis pro rozhodnutí o realizaci projektu „Systém pro podporu vývojového cyklu SW“ a z jaké úrovně vzešel (management, testeři, vývoj)? Prvotní impulsy k řešení těchto problémů se u nás datují již od roku 2000 až 2001, přičemž hlavními iniciátory hledání vhodného řešení byli především zaměstnanci z řad vývojářů a analytiků. Společně s managementem se následně došlo k rozhodnutí řešit tento problém komplexně: řešit ho nejenom pro fázi analýzy a testování, ale i pro fázi vývoje, včetně konfiguračního řízení. Závěrem

našich úvah bylo vypsání výběrového řízení, ke kterému došlo v březnu 2002. Výběrové řízení na tento projekt trvalo více než 3 měsíce a během něj jsme oslovili větší počet partnerů. Jeho výsledkem byl výběr dvou dodavatelů projektu – společnosti KOMIX pro část testování a společnosti LBMS pro ostatní části vývoje a pro řízení projektu jako takového. To znamená, že už původní koncepce byla komplexní? Nebo jste ze začátku zvažovali třeba jen některou z etap a zbytek se doplnil postupně? Musím říci, že již od počátku byl náš záměr komplexní. Nechtěli jsme řešit tuto problematiku po částech, zavádět odděleně jednotlivé části metodiky a postupně vybírat podpůrné nástroje a řešit jejich návaznost a případné problémy až ve chvíli, kdy už některé máme nasazené. Od začátku existovala myšlenka pojmout řešení problému komplexně a dnes jsem přesvědčen, že to byl správný přístup. Vybrané řešení se skládá z produktů několika výrobců. Neuvažovali jste o nasazení uceleného řešení od jednoho výrobce? Nikdo na našem trhu, alespoň jsme nikoho takového nenašli, nenabízí řešení, které by bylo jasnou jedničkou, a přitom pokrývalo vše co jsme v rámci výběrového řízení poptávali a mělo reference v České republice.

[email protected]; [email protected]

V průběhu výběrového řízení se ukázalo, že existují firmy, které nabízejí ucelená řešení od začátku až do konce, od jednoho výrobce, ale že tato ucelená řešení mají své poměrně výrazné slabé stránky. Nakonec jsme se rozhodli pro kombinaci, která vypadala složitě, nicméně ve světle konečných výsledků tohoto projektu to bylo správné rozhodnutí. Od začátku jsme důrazně uplatňovali požadavek, aby nástroje od různých výrobců spolu komunikovaly, aby to nebylo pomocí rozhraní vyvinutého pouze pro naše potřeby, ale aby šlo o rozhraní ověřené v rámci dřívějších instalací. Samozřejmě, že se vyskytly problémy, ale všechny se podařilo vyřešit a jsme rádi, že jsme se rozhodli pro „Best-ofBreed“ řešení. Jaké bylo vaše očekávání přínosů tohoto projektu pro GE Capital? Tušili jsme, co by nám projekt asi měl přinést, byly to však spíš odhady či přání. S odstupem mohu říci, že naše očekávání byla z části reálná, z části méně reálná. Jak sám název projektu napovídá, jde o systém pro podporu celého vývojového cyklu SW. Proto jsme hledali komplexní metodiku a nástroje, které od vzniku požadavku až po jeho nasazení do živého provozu podpoří jeho vývoj i případné pozdější úpravy a opravy. Takže očekávání se dají shrnout do dvou částí – komplexní metodika a vzájemně propojené nástroje. Kromě toho jsme

samozřejmě očekávali v dlouhodobějším horizontu zvýšení efektivity vývoje, postupné snížení pracnosti vývoje a snížení počtu chyb a z toho plynoucí ekonomické přínosy. Vzhledem k tomu, že už uplynuly tři měsíce od ukončení projektu, můžeme se tedy ohlédnout na realizaci projektu s určitým odstupem. Jak se podle vašeho názoru zdařilo provázání čtyř fází toho projektu. Řekl bych, že provázání a synchronizace čtyř fází projektu bylo určitě jednou z nejtěžších věcí vůbec, a to z několika důvodů. Projekt se realizoval za normálního provozu a bez přerušení jiných projektů a implementace nových požadavků, takže docházelo k poměrně velkým problémům na naší straně, z důvodů nedostatku našich personálních kapacit. Dalším problémem bylo, že jednotlivé etapy projektu musely jít za sebou v určitém logickém sledu. Těžko jsme mohli začínat například etapou datového a funkčního modelování, když se nevědělo nic o řešení evidence požadavků. Takže jsme se spolehli na zkušenosti dodavatelů. Myslím si, že se nám to vyplatilo, protože časování jednotlivých etap, jejich vzájemné překrývání nebo souběžný běh bylo naplánováno jak to nejlépe šlo. Návaznost jednotlivých fází vyplývala z logiky vývojového cyklu a výstupy jedné etapy byly často vstupem do etapy další. Nebyla to věc jednoduchá, nicméně nakonec se povedla.

7

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

Nyní bych se rád zaměřil speciálně na ob- dne tuto metodiku v základech nastudovat last metodiky testování. Jaký je váš zpětný a používat na projektu. Pak se k ní může pohled na průběh projektu v této etapě? vrátit v případě potřeby a podívat se, co by Jak jste to vnímal vy a jaké jsou ohlasy měl třeba ve fázi jednotlivých testů udělat, co od lidí např. z vývojových týmů, na které nesmí zapomenout. Právě proto si myslím, že byl, zejména v období konce roku, vyvíjen byla nastavena rozumná míra konkrétnosti ohromný tlak? a že metodika nesklouzla do zbytečně poCelá fáze testování byla v projektovém drobných pracovních postupů. plánu rozložena do poměrně časově dlouhého období, a přestože se mi tento čas Jedna věc je metodika, druhou věcí je, zdál na začátku zbytečně dlouhý, nakonec jakými nástroji je tato metodika podpořena. to byla doba, za kterou se etapa dala v od- Rád bych se zeptal na vaše tříměsíční zkušepovídající kvalitě stihnout, a to jak ze strany nosti s TestDirectorem a WinRunnerem? dodavatele, tak i ze strany nás jako odběraJá bych tuto odpověď rozdělil do dvou tele. Bylo to hodně časově náročné napří- částí, protože jinak je to s TestDirectorem klad i v oblasti vyškolení našich lidí. Projekt a trochu jinak s WinRunnerem, i když jde probíhal v době, kdy v GE Capital Multiservis o členy jedné rodiny a jednoho výrobce. vrcholí obraty a kdy byly kladeny mimořád- TestDirector je produkt, který se vlastně né požadavky na provoz systému a provoz „chytil“ sám od sebe. Je to zejména díky tak měl samozřejmě před projektem prio- tomu, jak jednoduché a srozumitelné je jeho ritu. Nakonec se projekt a zajištění provozu ovládání, jak má propracovanou funkčnost systémů povedlo sladit. Vše se podařilo zre- a ještě z řady dalších důvodů. V podstatě alizovat tak, že metodika testování prošla se TestDirector stal velmi rychle populárním dvěma nebo třemi koly připomínkování, což nástrojem pro řízení a správu testů a dnes se ukázalo jako velmi důležité a užitečné, už ho u nás používá řada týmů. Neměli jsme a potom v návaznosti na implementaci me- jediný problém s tím, že by ho lidé kvůli vrotodiky jsme nasazovali testovací nástroje. zené nechuti k novým nástrojům používat Trochu specifické bylo, že se začínalo na ze- nechtěli. Naopak TestDirector vhodně zapllené louce. Znamená to, že tu nebyly, až na nil bílé místo na naší IT mapě a dnes je s ním jednu výjimku, žádné nástroje, které by tes- velká spokojenost jak ze strany testerů, tak tování nebo jeho automatizaci podporovaly. ze strany ostatních pracovníků firmy mimo To vše přispělo k tomu, že jsme testovací IT, kteří jej také používají. Na zaučení člověnástroje i metodiku v daném časovém plánu ka pro práci s TestDirectorem, s přihlédnustihli nasadit a že metodika odpovídá našim tím k existenci metodiky testování, je dnes požadavkům. potřeba poměrně krátká doba a není nutné žádné drahé školení, takže TestDirector bych Myslíte, že vytvořená metodika testování klasifikoval výbornou. byla dostatečně obecná a na druhou stranu U WinRunneru věřím, že jeho hodnocení i dostatečně konkrétní? bude podobné, ale ještě nejsme dost daleko Dle mého názoru byla rovnováha mezi od ukončení projektu, protože WinRunner obecností a konkrétností nastavena na správ- je spíše investice do budoucnosti. Je to z tonou úroveň. My jsme před zahájením projek- ho důvodu, že než se systémy, které mají tu měli jen neúplná a nejednotná pravidla po- být automaticky testované WinRunnerem krývající pouze část fáze testování, takže i to, „načtou“, tak to nějakou dobu trvá. Dnes už že najednou všichni ve vývojových týmech jeden z našich hlavních systémů máme přimají postupovat podle jednotné a komplex- praven k automatizovaným testům a teprve ní písemné metodiky pro nás byla poměrně za čas dokážeme vyhodnotit přínosy a zenová věc. Myslím si, že vytvořená metodika jména ušetřený čas při provádění automatitestování není něco, co by se dalo nastudovat zovaných testů. za dvě hodiny, ale není ani nikterak složitá. TestDirector je tedy už dnes hodnocen Myslím si, že člověk dokáže během jednoho jako věc, která se rozhodně povedla, myslím

O

F

E

S

I

O

N

A

L

si, že WinRunner, pokud ho budeme důsledně a vhodně používat, jej bude následovat. Rád bych se ještě zeptal, jestli tento projekt měl nějaké negativní dopady na vývojové projekty, například zda se zvýšila administrativa, náklady na projekt atd.? Neřekl bych přímo negativní dopady na projekty, které běžely v průběhu projektu a ani na projekty, které vlastně dnes víceméně už přes implementované nástroje procházejí, spíš to byly logické dopady a změny jako u ostatních projektů tohoto typu. Zmínil jste zvýšenou administrativu. Samozřejmě se objevila zvýšená administrativa nebo spíše pracnost, která je ale nutnou součástí práce při prvním zvládnutí práce s TestDirectorem a nutností zadat do něj testovací scénáře a skripty. Načtení aplikace do WinRunneru by se také dala definovat jako zvýšená administrativa, ale bez těchto kroků nelze postoupit dál. Zcela určitě nám ubylo papírování. Dnes máme všechno ve stejných nástrojích, na jednom místě a hlavně, což je velký přínos, tři týmy a systémy, jichž se zavedení nástrojů týkalo, teď používají jednotnou metodiku, což nikdy předtím nebylo. Takže negativní dopady bych neviděl, byly to spíše logické dopady vzhledem k zaměření a velikosti projektu. Jak byste zhodnotil v krátkém období tří měsíců od konce projektu klíčové přínosy zavedení metodiky testování? Mohli bychom se na to podívat ze dvou pohledů, a to z pohledu lidí z vývojových týmů a z pohledu manažera? Z pohledu lidí, kteří testují a mají testování jako svou většinovou pracovní náplň, jsem už některé výhody zmínil. Jednou z výhod je, že metodika umožňuje podívat se, jak postupovat v určitých fázích projektu a případně s kým spolupracovat atd. Druhá výhoda je jednotné úložiště, ať už testovacích skriptů, testovacích sad a scénářů v jednom společném nástroji. Třetí výhodou je, že téměř po celou dobu trvání projektu lidé vědí, v jaké fázi je testování, co už otestováno bylo a co ještě ne. Tam, kde testování proběhlo, vědí jak dopadlo, jaké jsou výsledky testování. Tady již přecházím k výhodám ze

Testování změněného softwaru Změnové řízení – rámec pro testování změněného softwaru Ve firmě střední velikosti mohou v závislosti na jejím zaměření vznikat stovky požadavků na změny ročně. Problémy s jejich vyřešením mohou nabývat hrozivých rozměrů, například v okamžiku větší provázanosti a složitosti více požadavků. Vyšší četnost výskytu požadavků na změny, jejich rozsah a vzájemné působení ovlivňuje existenci podnikového řízení změn a ovlivňuje také jeho formu. Zpravidla je zabudováno do podnikových procesů a alespoň v elementární míře podporováno informačním systémem. Proces podnikového řízení změn předpokládá, že má-li kdokoliv v podniku potřebu něco změnit, vyřešit nebo vylepšit, podá požadavek na změnu. Za požadavek lze považovat i rozhodnutí managementu, neboť způsob jeho řešení se podstatně blíží způsobu řešení „klasického“ požadavku. Požadavek na změnu může dokonce podat i zákazník podniku. Změna se může týkat kterékoliv podnikové sféry: vytvářených produktů, vnitropodnikových procesů, organizační struktury atd. Dnešní podniky zcela jistě využívají podpůrné prostředky IT, proto je nedílnou součástí podnikového řízení změn také řízení změn softwaru. Za jeho dílčí ale významnou složku je považováno testování změněného softwaru. Jeho úkolem je podpořit změnové řízení v oblasti verifikace a validace prováděné softwarové změny a následně v rozhodování o nasazení změněného programového

8

vybavení do provozu. Jinými slovy testování softwaru po úpravách zajišťuje, aby do živého, provozního prostředí byly nasazovány pouze takové verze programového vybavení, které jsou přezkoušeny a u kterých byla míra chybovosti minimalizována.

Význam testování softwaru po úpravě Testování je integrální součástí řízení změn softwaru. Bez respektování jeho důležitosti, bez jeho existence v podniku, bez využití jeho přínosů pro správnost aplikací výrazně klesá efektivita a výkonnost řešení změn.

������ ���������

������������ ��������� ���������

������������������� ���������� �����������

������������� ������������ ���������������

��������� �����

��������������������� ���������������

������������� ������������ ��������� ��������� ������������������ ������������������ �������������

����������������� �������������������

������������� ����������������� �����

����������������������������

Obr. 1 – Vazba změnového řízení a testování změněného softwaru

I

T

A

K

V

A

L

I

T

strany vedoucích nebo manažerů. Přehled o testování získáte v rámci jednoduchého vyhotovení jednoho nebo dvou standardních reportů, na což stačí pět minut, místo toho aby se někdo musel věnovat tomu, že by pravidelně reportoval v různých systémech, v jakém stavu je testování, kolik je chyb, jak jsou řešeny a co ještě opraveno není. Další výhoda je stejně tak jednotná evidence chyb a v podstatě on-line přehled o tom, kolik chyb bylo opraveno, kolik chyb se třeba objevilo znovu a v jaké fázi jsou opravy jednotlivých chyb. Jak jsou s TestDirectorem a WinRunnerem spokojeni vlastní uživatelé, jaké jsou jejich názory? Do jaké míry by jim vadilo vrátit se do stavu před nástroji? Z pohledu IT lidí, kteří s těmito nástroji pracují, jsme na podobné téma měli již několik diskusí a nikdo z nich si už asi nedokáže představit, že by se zase znovu testovací skripty nebo data uchovávala v Excelu nebo v Accessu a někdo by se o ně musel složitě starat. Myslím si, že když člověk pozná, že v těchto nástrojích je ukryto opravdu velké množství know-how a zkušeností lidí z vývojových týmů z celého světa, nemá důvod vracet se zpátky k původnímu stavu. Mohl byste na závěr shrnout situaci, která byla před začátkem tohoto projektu a nyní? Jsem rád, že jsme se do tohoto projektu po delším uvažování pustili a prozatím nelituji ani peněz ani času, který jsme do projektu investovali. Myslím si, že všem, kteří dnes testují ručně nebo napůl ručně a nemají popsán jednotný postup a pravidla testování, mohu z vlastní zkušenosti doporučit, aby se do toho pustili. Bez tohoto kroku se nedá v oblasti vývoje větších systémů rozumně konkurovat, aniž by celkový vývoj a zejména testování nových aplikací nebo funkčností nebyl opakovaně příliš drahý, dlouhotrvající a celkově nepříliš efektivní. Děkuji za rozhovor.

Sebastian Petrů, [email protected]

V případě zanedbání této oblasti si zahráváme s důvěrou uživatelů, vznikají bezpečnostní incidenty, protahuje se plné a funkční nasazení změněného softwarového řešení. Velmi závažným důsledkem jsou zvyšující se náklady provozu a údržby programového vybavení. Testování softwaru je důležité vždy. Hlavním důvodem, proč tento článek zdůrazňuje testování po úpravách, spočívá v pravděpodobnosti zavlečení chyby. Pokud analytik ve spolupráci s programátorem vytvářejí nový software či programový modul, je pravděpodobnost, že udělají chybu, 3x až 10x menší než při úpravě již existujícího programového vybavení. Význam testování změněného softwaru roste v případě, že v podniku funguje více provázaných softwarových systémů. Růst počtu systémů a růst počtu vazeb mezi nimi klade zvýšené nároky na řešení změn promítajících se z jednoho systému do dalších. Způsob technické realizace vazeb je další faktor, který může vést k nárůstu obtížnosti řešení změn. Lokalizace a odstranění chyby dotýkající se dvou nebo více integrovaných systémů bývá komplikované, integrační testy jako součást komplexního otestování nové verze softwaru se zapracovanou změnou (v tomto případě změnou dvou či více systémů) zajišťují kontrolu funkčnosti propojení těchto systémů s ohledem na řešenou změnu.

A

Z

N

A

L

O

S

T

Z

K

U

Nástroje podporující testování změněného softwaru

E

N

O

S

T

P

R

Možné důsledky zavlečení chyby

Fungování celého procesu změnového řízení, jakož i jeho části – testování změněného programového vybavení, je závislé na softwarové podpoře. Zatímco změnové řízení malých systémů je evidenčně uchopitelné i „papírově“, testování a jeho organizace u větších systémů nejsou takovým způsobem efektivně zvládnutelné. Nástrojů podporujících testování je celá řada. Každý podnik by měl při volbě takového nástroje uvažovat, nakolik se mu vyplatí investice do něj. Vysoce specializované testovací nástroje jsou drahé, někdy může stačit jednodušší evidence. Možnosti, ze kterých mohou manažeři volit, jsou následující: 1. Základní podpora spočívá v jednoduché evidenci průběhu testování. Nástroje na této úrovni jsou poměrně levné a často je již podnik využívá k jiným účelům (např. MS Excel nebo MS Access). Jejich používání poskytuje základní orientaci o změnách a průběhu testování verzí softwaru, které tyto změny řeší. 2. Na vyšší úrovni se setkáváme se specializovanými testovacími nástroji (např. TestDirector), které vytvářejí podmínky pro plánování a evidenci testů, evidenci jejich výsledků, případně i evidenci neshod a sledování postupu jejich řešení. Rozdíl proti základní podpoře spočívá v tom, že tyto specializované nástroje mají implementovánu metodiku testování a dodržování předepsaných postupů do značné míry vynucují. Nasazení nástrojů pokrývajících tuto úroveň zvyšuje kvalitu organizace samotného testování a zvětšuje míru znovupoužitelnosti jednou připravených testovacích případů. 3. Nástroje na nejvyšší úrovni již podporují nejenom organizaci testování, ale testování samotné. Dovolují uživateli nejen připravovat, ale i provádět testovací případy. Platí to jak pro manuální testy, kdy uživatele vedou krok za krokem podle připraveného testovacího případu, tak pro automatizované testy. Příkladem takových nástrojů je TestDirector, v případě realizace automatizovaného testování propojený s WinRunnerem. Jednotlivé úrovně podpory softwarovými nástroji shrnuje obrázek 2.

���������

Š

Způsob otestování změny velmi ovlivňuje skutečnost, do jaké části aplikace míří. Působí-li změna z hlediska možných důsledků chyby na kritickou část aplikace, měla by se testovat celá aplikace. Při změně dopadající do nekritické části aplikace stačí otestovat pouze změnou ovlivněnou část a její blízké okolí. S výhodou, významnou zejména u kritických změn, je možné využít trasovatelnost projektových výstupů. Jsou-li známy vazby mezi částmi aplikace, není problém dohledat místa, kam všude se změna promítne a co všechno ovlivní, což umožňuje omezit rozsah prováděných testů a tím výrazně snížit náklady.

Kategorizace změn z hlediska rychlosti jejich implementace Řešení chyb (jako typu změny) vyžaduje trochu odlišný přístup než zavádění nové funkčnosti. Kritické chyby (havárie) se vyznačují tím, že musí být rychle odstraněny. Požadavek na rychlost bývá v rozporu s požadavkem na úplnou verifikaci a validaci opravy. Důsledkem tohoto rozporu a důsledkem faktu, že negativní důsledky zavlečení další chyby při neúplném otestování budou pravděpodobně menší než trvání havarijního stavu, je oprava havárie „záplatou“ a až následná kompletní verifikace a validace. Nasazování nové funkčnosti a realizace oprav nekritických chyb je úplně jiný případ. Implementaci do provozního prostředí předchází kompletní verifikace a validace a k nasazení dochází až po minimalizaci míry chybovosti.

Úroveň podpory týmové spolupráce Volba vhodného nástroje, který podporuje sdílení potřebných informací a řízení testování, umožňuje prostorovou diverzifikaci, např. mezi členy vývojového a testovacího týmu.

Volba automatizovaného testování a jeho poměr k manuálním testům Automatizované testování je svým charakterem náročné na přípravu a vyplatí se v případech častějšího opakování – pro aplikace

�������������������������������������� ����������������������������������� ������������������������������� �����������������������������������������

��������������������

��������������������������

�������������������������������������� ������������������������������������� ���������������

������������������������������� ��������������������������������� ��������

Obr. 2 – Úrovně aplikační podpory testování

Výsledná podoba testování změněného software v podniku Závěrečná podoba podnikového testování změn softwaru závisí na mnoha faktorech. Následující výčet představuje faktory, které z pohledu různých podniků mohou mít pro výslednou podobu odlišnou důležitost.

Softwarová infrastruktura podniku Počet, rozsah a provázanost programového vybavení, ale i četnosti změn ovlivňují množství testů, které musí být řízeny a realizovány.

vytvářené přírůstkovým způsobem (který vede k opakovanému testování stejných částí aplikace), případně pro kontrolu velkého množství dat. Na rozdíl od manuálních testů, jejichž opakování je vždy časově stejně náročné, je testování prostřednictvím spouštění automatizovaných testů výrazně úspornější. Nevýhodou automatizovaných testů je složitější příprava. Z tohoto důvodu je nutné uvážit, pro jaké aplikace zvolit manuální a pro jaké automatizované testování. Poměr manuálních a automatizovaných testů ovlivňuje nejen rychlost verifikace a validace změněného softwaru, ale i volbu

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

nástroje pro podporu testování změněného softwaru (viz obrázek 2).

Dopad do uživatelské důvěryhodnosti

Možnosti zásahů do okolních procesů a existující organizační struktury

Závažným faktorem, který ovlivňuje výslednou podobu testování softwaru po úpravách a kterým se musí manažeři zabývat, je ohrožení důvěryhodnosti měněného systému pro uživatele. Projeví-li se kritická chyba až za provozu a práce uživatelů je nepříjemnější či v horším případě úplně znemožněná, může vlna odporu proti chybové aplikaci ztížit její rozvoj či rozšiřování do dalších částí podniku.

Tento faktor ovlivňují odpovědi na následující otázky: Vychází se při tvorbě systému testování změněného softwaru z existujícího změnového řízení nebo zatím neexistuje jednotná koncepce? Lze vázat na okolní procesy a je možné je alespoň částečně přizpůsobit? Je stávající organizační struktura pevná nebo mohou tvůrci systému navrhovat její změny?

Firemní kultura, zvyklosti a standardy S ohledem na kvalitu firemních standardů nelze nezmínit skutečnost, že zavádění standardu ISO 9001 nezbytně povede také k implementaci testování změněného softwaru.

Závěr Testování změněného softwaru neexistuje samo o sobě, ale zapadá do celkového rámce změnového řízení. Článek se nezabývá popisem jednotlivých činností testování softwaru po úpravách. Cílem je spíše upozornit na význam a ukázat na možné faktory, které zpravidla ovlivňují jeho podobu.

Jak „doběhnout“ databázový server Petr Sobotka, [email protected] Jeden praktický příklad toho, proč si dávat pozor na čistotu návrhu databázových schémat Před nedávnem jsem řešil zajímavý problém: Uživatel hlásil, že se aplikace při vyhledávání klientů v databázi podle jím zadaných kritérií „zasekne“ a po jisté době nahlásí chybu, že požadavek nebyl vyřešen do vypršení nastaveného časového limitu. Aplikace umožňuje vyhledávání v množině klientů podle různých hledisek a uživatel v tomto případě zadal příjmení, město a PSČ. A skutečně - při vložení uvedené kombinace kritérií se aplikace nechtěla hnout z místa. Provedl jsem ještě několik pokusů a zjistil, že pokud se pro vyhledávání zadalo pouze příjmení a město nebo příjmení a PSČ, výsledky se objevily během okamžiku. Uživatel se, nutno přiznat na první pohled logicky, divil, proč tomu tak je. Vždyť zadáním více kritérií se přesněji určí množina dat, kterou je třeba prohledávat, a celý dotaz by proto měl být rychleji zpracován. Pro pochopení důvodu takového chování, bylo potřeba prozkoumat plán zpracování dotazu, který zvolil databázový server při vyhodnocování dotazu. Nejprve však naznačme, jak jsou uložena data v těch tabulkách aplikace, které souvisí s uvedeným problémem: • tabulka klientů, která obsahuje mj. příjmení klienta, • tabulka adres, ve které jsou uloženy ulice, město a PSČ, • vazební tabulka, která spojuje předchozí dvě a realizuje vazbu M:N mezi klienty a adresami. Jak tedy vypadal plán zpracování pro dotaz, ve kterém bylo zadáno pouze příjmení a PSČ? Databázový server vzhledem k četnosti zastoupení údajů v tabulce a konkrétním zadaným hodnotám vyhledávacích kritérií správně vyhodnotil, že z tabulky klientů podle zadaného příjmení bude vybrán velmi malý počet řádků, podstatně menší než z tabulky adres. Začal proto výběrem dat z tabulky klientů a k nim připojoval dohledáváním podle indexu zbylé dvě tabulky. Ve druhém případě, kdy byla zadána všechna tři kritéria, tj. příjmení, město i PSČ, se ovšem databázový server rozhodoval jinak. Protože byla nad tabulkou adres zadána dvě kritéria, usoudil, že jejich kombinace bude definovat množinu dat ještě menší, než při hledání podle příjmení v tabulce klientů a začal proto jako první vybírat řádky z tabulky adres. A zde je právě kámen úrazu. Uvedené chování by naprosto vyhovovalo

v případě, kdyby hodnoty v jednotlivých sloupcích tabulky adres, podle kterých se vyhledávalo, byly na sobě navzájem nezávislé. Potom by za předpokladu rovnoměrné distribuce hodnot v tabulce skutečně platilo, že pokud se použijí obě kritéria, bude s velkou pravděpodobností výsledkem velmi malá množina vyhovujících řádků. V našem případě ovšem hodnoty město a PSČ jsou vzájemně závislé – k jednomu městu vždy patří jedno či více PSČ. Tudíž použití obou vyhledávacích kritérií nijak neomezilo množinu dat oproti situaci, kdy nebylo zadáno město, a volba tabulky adres jako výchozí byla proto zcela nevhodná. Databázový server v době, kdy počítá statistiku nad tabulkami, nijak nezjišťuje, zda mezi hodnotami jednotlivých sloupců existují nějaké závislosti. Nelze ho proto vinit z chybného chování při vytváření plánu zpracování pro náš problémový dotaz. Naopak – pokud zavzpomínáme na teorii relačního uložení dat, měli bychom si uvědomit, že uvedené uložení nevyhovuje tzv. normálním formám databázových relací. Normální formy relačního schématu definují taková pravidla pro uložení dat, která zabraňují problémovým situacím (např. redundanci dat ap.). Pro náš případ je relevantní tzv. Boyce-Coddova normální forma (BCNF), která je splněna, pokud „pro každou závislost X à Y platí, že X obsahuje klíč tabulky“. Její aplikací dojdeme k závěru, že uvedené údaje, ulice, město a PSČ, nelze uchovávat pohromadě v jedné tabulce. Problém je, že tabulka může jako klíč použít dvojice {ulice, město} nebo {ulice, PSČ}, ale zároveň existuje závislost PSČ à město. To odporuje BCNF, protože PSČ samo o sobě není klíčem tabulky. Správné uložení údajů by bylo do dvou tabulek, z nichž jedna by obsahovala sloupce PSČ a město a druhá ulici a PSČ. Díky tomu bychom snížili redundanci dat a také bychom mohli nezávisle ukládat vazbu mezi PSČ a městem, která samozřejmě může existovat i bez záznamu o konkrétní ulici. Pokud bychom provedli uvedené oddělení dat do dvou tabulek, databázový server by z definice první tabulky věděl o závislosti mezi údaji PSČ a město a lépe by se mohl rozhodovat při vytváření plánu zpracování dotazu. Vzhledem ke konkrétní povaze zdroje dat pro aplikaci bylo v našem případě téměř nemožné provést uvedené rozdělení tabulek. Rozhodli jsme se proto posunout řešení do aplikační úrovně a uživateli vůbec neumožnit současné zadání města i PSČ coby vyhledávacích kritérií.

9

A

Z

N

A

L

O

S

T

Z

K

U

Š

E

N

O

S

T

P

R

O

F

E

S

I

O

N

A

L

I

T

A

K

V

A

L

I

T

Křížovka Tomáš Vahalík, [email protected] Návod: Při luštění tajenky počítejte, kolikrát použijete nápovědu. Za každé použití nápovědy si zapište jeden bod. Na konci Vás čeká vyhodnocení. Pozor, v nápovědě naleznete skutečně pouze nápovědu ukazující přibližný směr dalšího hledání, nikoliv samotné řešení (obdobně jako při použití nápovědy k většině programů). Díky tomu Vám nic nezkazí radost z toho, že problém dokážete vyřešit samostatně. Tajenka: Jeden z největších vynálezců přelomu 19. a 20. století

A

B

C

D

E

F

G

1 2 3

Legenda: Vodorovně: 1. • 2. díl tajenky •• Iniciály klasika vědeckého materialismu, anebo iniciály autora románu o rudém gentlemanovi, anebo iniciály dětského románového hrdiny, který vyrostl v lese. 2. • To, k čemu se snadno dostane zvěř v krmelci, k tomu se mnohem obtížněji dostane Váš dávkový proces na serveru. •• Rezavý produkt vyráběný ze zeleného zlata, přesto u zákazníků velmi oblíbený, a to díky tradici a kvalitě, nikoliv jen díky marketingové strategii. ••• Oblíbená koncovka názvu softwarových produktů a firem. 3. • Rodina je základ státu, základem naší firmy je … (psáno anglicky) •• Jméno baby, která je ve skutečnosti chlap. 4. • Sídlo u našich severních sousedů, také název jednoho z našich pracovišť. •• Souhlas. 5. • Zkratka Národní outsourcingové asociace (pozor, některá cizí slova se jinak vyslovují a jinak píší). •• Lyžařský vlek. 6. • Nechutné vedro v kanceláři, kdy ani klimatizace nepomáhá. •• Přídavné jméno vztahující se například k nabídce vypracované v naší firmě. 7. • Vitamín nebo také programovací jazyk. •• 1. díl tajenky Svisle : A • Býval největší a nejlepší, ale brzy po nasazení do ostrého provozu neslavně skončil, stal se synonymem zkázy ale současně legendou a námětem úspěšného filmu, který vydělal spoustu peněz (psáno anglicky), jinak také připomíná název jednoho z našich pracovišť. B • Opak ostrova nebo také geomorfologický útvar inspirující Petra Iljiče Čajkovského. •• Název anglicky mluvící televizní stanice přinášející aktuální zpravodajství. C • Předložka (7. pád) •• Regionální vládce v osmanské říši, spravující jemu přidělenou část území. ••• Římsky 51 D • Podnebí. •• Mechanický princip umožňující snadněji pohybovat s těžkými břemeny, ale se zatuhnutým počítačem nepohne. E • Univerzální čistící prášek na mytí van, umyvadel, nádobí. Vyroben na bázi přírodních abraziv a odbouratelných tenzidů, příjemně citronově parfémovaný. •• V rámci naplňování norem jakosti je jistý pracovník požádán, aby to (hledaný výraz) „hodil“ na dokument vypracovaný jiným pracovníkem před odevzdáním tohoto dokumentu zákazníkovi (i když dotyčný pracovník má chuť hodit na to něco docela jiného). F • Základ života. •• Africký stát , na jehož území leží město Timbuktu. G • Římsky 1002 •• Programovací jazyk, jehož název je občas zaměňován s názvem ostrova v Indickém oceánu.

4 5 6 7

Nápověda: Vodorovně: 1. •• Všichni byli Karlové. 2. ••• Také římsky 9 3. • Skupina zaměstnanců sdružená za účelem spolupráce na realizaci dodávky, výraz je také často používán v souvislosti s kolektivními sporty. •• Jméno známé z pohádek Orientu. 4. • Hlavní město Polska. 6. •• Vábná. Svisle : B • Ostrov = (voda, voda, země, voda, voda), opak ostrova = (země, země, voda, země, země) E • Možnosti: a) Jar b) AVA c) TIX •• Čidlo zraku hovorově. F • Chodíme se tam vzdělávat abychom pak mohli jinam chodit vydělávat. •• Rýmuje se s 2. výrazem ve 3. řádku G •• CÉjlon to není

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á pobočku v Brně a 93 zaměstnanců.

Vyhodnocení: Podle počtu bodů, které jste si připsali za každé použití nápovědy, si můžete ověřit, do které kategorie patříte: 0–2 3–5

To jste asi špatně počítali body anebo jste křížovkářský génius. Jste velmi zdatný křížovkář, navíc dobře obeznámený s prostředím naší firmy. 6–8 Jste velmi zdatný křížovkář. 9 – 12 Jste velmi zdatný křížovkář, navíc poctivě (narozdíl od jiných) evidující počet použití nápovědy. 13- 15 Tak to jste určitě počítali špatně, tolik nápověd zde uvedeno není. 16 a více To pro Vás nebyla křížovka, to byla krizovka. Pokud Vám řešení tajenky připomíná název ulice, ve které sídlila společnost KOMIX na sklonku minulého století, potom určitě patříte k dlouholetým přátelům, zákazníkům či zaměstnancům KOMIXu.

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

10

A