Co s tunami informací?

Transkript

1 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. INVEX expozice Vinný sklípek pavilon V, stánek 54 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, kucera@komix.cz Co s tunami informací? 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. Patrik Šálek, salek@komix.cz 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

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

3 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). 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.). 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 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 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) Obrázek 3: Ukázka integrace nástrojů DOORS a Telelogic Tau 3

4 S Microstrategy na datový sklad Petr Matoušek, 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 Micro- Strategy 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 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é em, 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. Obr: Architektura MicroStrategy pro analýzu a distribuci podnikových informací Selektivní šifrování dat uložených v databázi 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, ž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- Jan Rada, rada@komix.cz ží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. 4

5 Š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. 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 znalosti 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. Šifrování na aplikační vrstvě může být výhodné, pokud citlivé položky jsou určené 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ů. 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: Ochrana dat Martin Janček, jancek@komix.cz 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 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 komunikace 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ů 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

6 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 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 nejprve 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 Internet a cena informací 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ý subjekt, který prostřednictvím jím vydaného certifikátu jednoznačně svazuje identifikaci subjektu s jeho dvojicí klíčů,respektive s jeho digitálním podpisem. Tím pádem se certifikát stává elektronickým průkazem totožnosti. Certifikát obsahuje veřejný klíč, jméno a další údaje zajišťující nezaměnitelnost subjektů. Obsahuje též datum počátku platnosti, datum ukončení platnosti, jméno certifikační autority, která certifikát vydala, sériové číslo a některé další informace. Certifikační autorita zaručuje správnost jí vydaného certifikátu, odstraňuje nutnost smluvní důvěryhodné výměny klíčů mezi dvěma subjekty navzájem a jejich dohoda spočívá pouze v domluvě o společně uznávané certifikační autoritě. Důležité je, že utajovaná data na straně klienta jsou redukována pouze na bezpečné uchovávání privátního klíče, protože ostatní je řešeno certifikáty. Ty si můžeme kdykoliv ověřit se znalostí veřejného klíče certifikační autority, respektive jejího certifikátu. Existence certifikační autority také umožňuje důvěryhodnou komunikaci i subjektů, jenž se navzájem fyzicky nikdy nepotkaly nebo neabsolvovaly složitou proceduru vzájemné důvěryhodné výměny svých klíčů. Další službou, kterou certifikační autorita poskytuje, je možnost zrušení certifikátu. Toto oceníme při ztrátě našeho privátního klíče. Každá certifikační autorita poskytuje seznam odvolaných certifikátů a stvrzuje ho svým podpisem. Zdá se, že principy ochrany elektronických dat jsou propracovány a je možné se na ně spolehnout. Tento článek měl přiblížit možnosti, jak lze svá data chránit před možnými vetřelci. Je však důležité neopomenout lidský faktor, který nám většinou přinese nepředpokládané problémy. Tomáš Vahalík, vahalik@komix.cz Informace zdarma? Jistě jste si všimli, že v poslední době lze na Internetu najít zdarma nejenom informace o počasí, vlakových spojích, programech kin či rad pro zahrádkáře. Zdarma lze najít i takové informace, o kterých by se dalo předpokládat, že je to střežené firemní tajemství, know- -how na kterém lze vydělávat a získávat konkurenční výhody. Zkuste například v Googlu (nebo jiném vyhledávači samozřejmě zdarma) vyhledat odkazy podle hesla best practices nebo design patterns. Zdarma jsou nejen informace, ale i programy. A to ne ledajaké. Namátkou, od operačního systému (Linux), přes vývojové nástroje (Eclipse), databáze (MySQL), web server (Apache), kancelářský balík (Open Office) až po J2EE aplikační server (JBoss). Existuje tolik kategorií programů zdarma (někdy se vzájemně překrývajících), že není úplně jednoduché se v nich vyznat (Free Software, Public Domain, Copyleft, GPL ed, Open Source, Freeware...). Jak je možné, že v době přechodu do věku informační společnosti, kdy by firmy mohly na prodeji informací vydělávat, je stále častějším jevem, že informace i software jsou zdarma? Platí zde stále ještě zákony tržního hospodářství? Internet a tři zákony kyber-ekonomiky Odpověď na tyto otázky je nutné hledat ve způsobu, jakým Internet ovlivňuje téměř všechny oblasti našeho života, ekonomiku nevyjímaje. Internet zásadně usnadňuje publikování, vyhledávání a přenášení informací odkudkoli na světě. Proto bývá Internet označován jako technologie, která nám otevírá informační věk, a je tím, čím byl vynález parního stroje pro industriální věk. Internet ovlivňuje ceny na třech úrovních, proto se hovoří o třech zákonech kyber-ekonomiky : Zákon 1.: Cena informace se bude snižovat Tento zákon vychází z působení dvou faktorů: a) nízká cena publikování informací na Internetu ve srovnání například s papírovými médii b) snaha firem upozornit na sebe nabídkou některých užitečných informací či softwaru zdarma Díky kombinaci obou faktorů dochází k tomu, že informací i softwaru zdarma je na Internetu stále větší množství. Informace zdarma slouží firmám jako návnada, forma marketingu. Bez toho, aniž by nabízely některé užitečné informace zdarma, si jich na Internetu nikdo nevšimne, a dříve či později se objeví konkurence, která je nabízet zdarma bude. Problémem se naopak stává schopnost orientovat se v množství informací a schopnost informace využít. Zákon o snižování ceny informace se uplatňuje i uvnitř organizací. Schopnost firmy uspět v konkurenci je závislá na sdílení znalostí mezi jejími zaměstnanci. Společnosti, jejichž zaměstnanci hlídají své know-how pro udržení vlastní pozice, nemohou uspět. Zákon 2.: Cena komunikace se bude snižovat Již dnes znamená Internet globální komunikaci za lokální ceny. Každý obchodní subjekt 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. Software jako služba Software má mnoho ekonomických charakteristik odlišných od fyzického zboží, svým charakterem má blíže ke službě. Podle odhadů je až 95% kódu psáno pro specifické prostředí firmy (ať už vlastními silami, přizpůsobováním komerčního SW produktu nebo nákupem softwaru vyvinutého na míru), proto znovupoužitelnost takovéhoto kódu pro další prodej je relativně nízká. Pouze 5% kódu je psáno pro software na krabicový prodej. Navíc je obvyklé, že značná část nákladů životního cyklu projektu se týká fáze údržby, tj. technické podpory, rozšiřování a přizpůsobování měnícímu se prostředí firmy. Podle Gartner Group je to typicky 30% ale často i více než 50%, podle ButlerBloor Computer Research je to dokonce 66%. I když tato čísla nemusí být přesná, podstatné je, že značná část mzdy vývojářů je placena za práci, kterou není možné prodávat opakovaně, jako je tomu u krabicového softwaru. Cena za software, kterou je zákazník ochoten platit, je často více než užitnou hodnotou softwaru ovlivněna očekávanou kvalitou další podpory. Zákazník pravděpodobně nebude chtít koupit proprietární software od krachujícího dodavatele nebo od ičáka programujícího doma v obýváku, protože zde je další podpora problematická. Software se svým charakterem tedy více blíží službě, je to dlouhodobý vztah mezi dodavatelem a zákazníkem. Přechod od modelu, kdy se platí za kopii SW jako za kus zboží, k modelu, kdy dominantní je cena služby, je jednou z odpovědí na otázku položenou v úvodu. Open Source Software Zvláštní kategorií softwaru zdarma je Open Source software (OSS). Na tomto příkladě si ukážeme, že software zdarma může mít své ekonomické opodstatnění. Vznik nového modelu vývoje softwaru umožnil právě Internet. Tento model spočívá v tom, že jádro SW produktu je co nejdříve zveřejněno i se zdrojovými kódy a dáno uživatelům k dispozici zdarma s licencí, která umožňuje volné kopírování a modifikaci zdrojového kódu. Licence ale neumožňuje komerční zneužití tedy prodej takovéhoto softwaru. Umožňuje jej však zahrnovat do komerčních aplikací, účtované poplatky ale nesmí zahrnovat tento software, pouze to, co k němu prodejce přidá. 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. Jak vydělat na OSS Lze vydělávat na něčem, co je zdarma? Každý produkt na trhu má zpravidla svůj doplňkový produkt, přičemž oba tyto produkty se obvykle kupují společně. Například doplňkem k hardware je operační systém. Firmy se snaží snížit cenu svých doplňkových produktů až na nulu, aby stoupla poptávka po hlavním produktu. Netýká se to jen SW a HW, možná také znáte obchod s potravinami, který nabízí zdarma dovoz nákupu podle telefonické objednávky. Existují tyto základní modely jak vydělat na OSS: Příjmy pocházejí ze služeb školení, konzultací, technických podpor, nikoli z poplatků za licenci. Příjmy ze SW nadstaveb, doplňků a specializovaných modulů k OSS, které jsou prodávány podle tradičního modelu. OSS zvýší prodej hlavního produktu, kterým je hardware (například drivery pro grafické karty nebo operační systém pro počítač). Prodej příslušenství k OSS - od hrníčků a triček až po knihy a dokumentaci. Výše uvedené možnosti, jak ekonomicky získat na softwaru zdarma, nejsou jediný druh zisku. Dalším a možná ještě podstatnějším přínosem z volného poskytování informací, je získání vlivu a dobrého jména experta, což může být k nezaplacení. Rizika OSS z pohledu uživatele V poslední době stále více organizací zvažuje výhody používání OSS. Ovšem to, že za OSS nemusíte platit licenční poplatky, neznamená, že nebudete mít náklady spojené s implementací a provozem. Pro uživatele je rozhodující, jak jsme si ukázali dříve, právě podpora softwarového produktu. Nyní se sice objevuje stále více firem poskytujících podporu OSS, problémem však může být nedostatek zkušeností těchto firem s podporou rozsáhlejších provozních aplikací založených na OSS. Obdobné je to při hledání zaměstnanců. Je jednodušší najít zkušeného administrátora např. Solarisu, než Linuxu. Některé OSS produkty se osvědčily v rozsáhlých podnikových systémech (Linux, Apache), jiné se však vyvinuly z menších aplikací. Například Open Source databáze za sebou nemají dlouhodobé reference o použití v rozsáhlých provozních systémech, což je z hlediska výběru databáze dost podstatná informace. Budoucnost OSS Přes uvedená rizika lze očekávat, že se bude objevovat stále více řešení založených na OSS a to především tam, kde licenční poplatky za komerční produkty představují podstatnou část celkových nákladů. Open Source model však není vhodný pro veškerý software. Najde uplatnění ve vrstvě infrastruktury (operační systémy, komunikační SW), méně často potom v oblasti middleware (web servery, aplikační servery, databázové servery, vývojové nástroje), oblast aplikací na míru bude nadále doménou modelu tradičního vývoje. Zatímco příznivci Open Source vidí v současných miliardových investicích velkých firem do OSS potvrzení životaschopnosti OSS modelu, skeptici v tom spatřují začátek konce OSS, neboť podle nich komercializace způsobí, že OSS přestane přitahovat nadšené individuální vývojáře a bez široké komunity takovýchto nadšenců ztratí OSS podstatu své existence. Otázka budoucnosti Open Source Softwaru tedy zůstává - otevřená. Informace a software zdarma nejsou anomálie, ale je to stále zřetelnější tendence vývoje, která není v rozporu s tržními principy a se kterou bude nutné v nejbližších letech počítat. professional/articles/digitalrevolution/ threelaws.htm Eric S. Raymond: The Magic Cauldron Odkazy: Michel Bauwens: The Three Laws Of the Cyber-economy, Olliance Consulting Group: Open Source Software Position Briefing OSSIPosition pdf Sanjay Murthi: Free and Clear? /606feat3_1.shtml 6

7 Vyplatí se vůbec testovat software? Dan Petřivalský, 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 zaměstnanců, z toho asi 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ž 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 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í USD za rok. Celkový roční čistý přínos projektu je USD. NC Náklady na licence a školení činí USD. ROI = USD / 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 USD. NC Náklady na licence, technickou podporu, konzultace a školení dosáhly USD během tří let. ROI = USD/ 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 vrsecky@komix.cz; dan.petrivalsky@komixbrn.cz 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 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. 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-of- Breed ř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

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

9 Nástroje podporující testování změněného softwaru 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. 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. Možné důsledky zavlečení chyby 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 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 nástroje pro podporu testování změněného softwaru (viz obrázek 2). Možnosti zásahů do okolních procesů a existující organizační struktury 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. Jak doběhnout databázový server 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 Dopad do uživatelské důvěryhodnosti 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. 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. Petr Sobotka, sobotka@komix.cz 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

10 Křížovka Tomáš Vahalík, 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 Legenda: Vodorovně: 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. 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í 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 To jste asi špatně počítali body anebo jste křížovkářský génius. 3 5 Jste velmi zdatný křížovkář, navíc dobře obeznámený s prostředím naší firmy. 6 8 Jste velmi zdatný křížovkář Jste velmi zdatný křížovkář, navíc poctivě (narozdíl od jiných) evidující počet použití nápovědy 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 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ů. KOMIX ověřená kvalita produktů a služeb KOMIX s.r.o. Holubova 1, Praha 5, tel.: , fax: , sales@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