Co s tunami informací?

Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
INVEX 2003
6. – 10. 10. 2003
expozice „Vinný sklípek“
pavilon V, stánek 54
Co nás čeká?
13. června letošního roku jsme rozhodli, že
vstoupíme do EU. Řada z nás s přesvědčením, že
z EU přiletí nějaký ten pečený holub, jiní proto,
že ANO považovali za jedinou možnost a NE za
krok k izolaci.
Nyní je třeba vystřízlivět a začít se starat o důsledky tohoto rozhodnutí, aby nás nezaskočily,
jako zima naše silničáře. Co nás bezprostředně
čeká?
1. Konkurence.
2. Vládní reforma.
3. Vybudování struktur, které nám umožní plnit závazky, které na sebe bereme, a také se
podílet na výhodách, které EU nabízí.
Pokusím se tyto tři body okomentovat z pohledu IT.
Konkurence – asi můžeme konstatovat, že
v IT segmentu již všichni silní světoví hráči působí. IT technologie se prodávají za světové ceny,
zde by tedy k vážné změně dojít nemělo. Lze
očekávat vyšší konkurenci ze strany středních
a menších firem zejména firem z okolních států
jako je Polsko, Slovensko, Maďarsko. Nový zákon o zadávání veřejných zakázek by měl zprůhlednit rozhodování ve výběrových řízeních
a také odstranit možnosti zvýhodnění lokálních
firem. V Německu se silně projevuje konkurence
levné programátorské kapacity ze zemí bývalého Východního bloku, můžeme očekávat stejný
trend. Bude sílit mezinárodní kooperace. KOMIX
již dnes navazuje kontakty s německými firmami, aby byl schopen kooperovat jak na českém
trhu, tak na trzích třetích zemí.
Vládní reforma je zatím trochu v mlze a tak
lze těžko komentovat její dopad. Nicméně, mají-li se snížit náklady na správu země a zkvalitnit
služby občanům, bez nasazení IT technologií to
nepůjde, takže můžeme očekávat investice do
této oblasti.
Velký dluh vidím v budování struktur, které
by měly zajistit komunikaci s EU a také, to považuji za velice důležité, podpořit naše firmy
v administrativně náročných procesech, které
je nutné absolvovat, chce-li se firma účastnit
projektů EU ať již jako zadavatel projektu nebo
ve výběrovém řízení na jeho řešení. Podle mého
názoru máme velký dluh v informování o možnostech využití unijních fondů. I tyto činnosti
bude třeba podpořit IT technologiemi, takže
i zde se bude jistě investovat.
KOMIX jako technologicky vyspělá firma vidí
ve vstupu do EU příležitost. Hrozbu pro nás
představuje vládní reforma, pokud by mělo dojít v důsledku reformy ke zdražení lidské práce,
budou české firmy v silném konkurenčním prostředí znevýhodněny.
Petr Kučera, ředitel, [email protected]
Co s tunami informací?
Patrik Šálek, [email protected]
Moderní podnik poskytuje svému okolí velké množství nejrůznějších dokumentů. Přitom skupiny uživatelů těchto dokumentů jsou velmi různorodé – zákazníci, potenciální zákazníci,
investoři, zaměstnanci, případně další. Zvládnout kvalitu poskytovaného obsahu s ohledem na potřeby cílových skupin je
velmi náročné.
Důležité je, že dnes už nestačí, aby se uvedeným uživatelům
obsah dal „nějak“ k dispozici. Jméno a kvalita podniku jsou
dnes vnímány nejen prostřednictvím obsahu dokumentů, ale
také prostřednictvím jejich formy, způsobu doručení adresátovi a dalších parametrů. Nepotřebné a staré informace obtěžují
většinu z nás.
Do procesu poskytování informací tak ve stále větší míře musí
vstupovat marketing, k jehož úkolům v této souvislosti patří:
• udržovat a rozvíjet firemní značku a image,
• udržet stávající zákazníky/klienty,
• podpořit akvizici nových klientů.
Konkrétně pak marketing:
• podporuje zajištění optimálního množství informací o firmě
a jejích službách či produktech, jejich publikaci a selektivní
distribuci vybraným cílovým skupinám (různé formy inzerce, reklamní akce, návrh vzhledu a obsahu webových
stránek…),
• působí na udržování konzistentního vzhledu firemních do-kumentů (od vizitek, přes letáky, webové stránky až po
projektové dokumenty a technické specifikace),
• napomáhá rozvoji firemní kultury – způsobu komunikace,
vystupování a chování zaměstnanců apod.,
• je odpovědný za prezentaci společnosti na různých obchodních, společenských a jiných akcích. Stejně jako u vzhledu
firemních dokumentů je třeba si uvědomit, jaké nároky
jsou dnes na prezentaci společnosti kladeny – prezentace
musí kromě věcného sdělení např. podporovat značku firmy,
musí být včasná, nesmí být nákladná, má oslovit odpovídající
množství členů cílových skupin apod.
Enterprise Content Management (ECM) v tomto světle představuje poměrně nový „business“ nástroj, který dnes může marketing – a nejen marketing! – při zajištění uvedených činností
využít. Cílem ECM je podpora správy jak strukturovaných, tak
nestrukturovaných údajů – jejichž zdrojem mohou být podnikové aplikace i jednotlivé dokumenty v různých formátech. Přitom
se nemusí jednat jen o textové dokumenty, ale také o obrázky,
videa, zvukové nahrávky atd. V tomto kontextu hovoříme
o správě obsahu.
Web Content Management je část ECM a využívá k publikování obsahu webové technologie. Využití webových technologií
neznamená, že každý dokument musí ve výsledku mít jen formu
HTML. Naopak, dnes je snahou vycházet vstříc zákazníkovi a nabídnout mu formáty, které jsou pro jeho práci přirozené. Typickým příkladem jsou PDF soubory, které respektují požadavky na
profesionální vzhled, který se nemění v závislosti na použitém
výstupním zařízení a lze zajistit, aby nebyl uživatelem měněn.
Uživatelé si takové dokumenty mohou stahovat a uschovávat
pro pozdější využití.
Stejně jako u jiných oblastí, také pro poskytování obsahu
bychom mohli definovat něco jako vlastní „Capability Maturity
Model Content Managementu“ a ukázat, že většina podniků
jej už vlastně delší dobu nějak řeší, avšak z dnešního pohledu
pouze na základní úrovni. V každé firmě, která má nějaké internetové stránky, existují postupy, jak se na ně dostávají informace.
Někde tyto postupy definují striktní pravidla pro řízení a obsah
určený k publikaci prochází několika koly schvalování, jinde jsou
volné a záleží na osobnostech, co a jakým způsobem publikují.
Důležitým prvkem takového způsobu publikování informací je
fakt, že někde tyto informace věcně musí vzniknout, marketingoví pracovníci je pak opracovávají do podoby, která je z jejich
pohledu publikovatelná, a technologové – weboví administrátoři – jim dají konečnou formu.
A jaký je pohled Content Managementu? S čím může podnik,
který se rozhodne řešit Content Management, počítat? Řešení
Content Managementu zahrnuje:
• Definici struktury obsahu pro jednotlivé účely, ke kterým je
určen. Pro každý typ informací (např. technické informace
o produktech, informace o podniku, možnosti zaměstnání
apod.) se určí, jaké složky má publikovaný obsah mít. V případě produktu to může být krátký popis, detailní popis, jak
dlouho má být zařazen mezi novinky atd.
• Definici / formalizaci procesu publikování a správy obsahu
určeného k publikování. Musí zahrnovat vznik informace,
její zpracování do požadované struktury (viz předchozí bod),
schvalovací pravidla a další.
• Definici rolí Content Managementu – role, která definuje
strukturu údajů, které se zaznamenávají a dále využívají,
role, která zadává data (tvůrce obsahu), role, která schvaluje
obsah (schvalovatel, manažer), role, která rozhoduje o formě
publikovaného obsahu (designér) a role, která publikování
technicky zajišťuje (webový administrátor).
• Zpracování konkrétních šablon, do kterých budou data na-
1
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
pokračování ze strany 1
plňována uživateli (např. různé aplikační
• Zjednodušení publikace obsahu, navíc
formuláře) a šablon používaných pro puv různých formách. Jakmile obsah jednou
blikování obsahu (šablony HTML stránek,
vznikne a je zkompletován, může být předoprovodných dokumentů). Zatímco prvváděn do různých formátů podle toho, co
ní typ šablon je prostředek pro sběr údajů,
uživatelé stránek preferují. Nástroje obdruhý typ slouží pro udržení jednotného
vykle také působí jako integrační prvek
vzhledu publikovaného obsahu.
mezi poněkud těžko slučitelnými profe• Nasazení nástroje a jeho případné proposemi (odborníky na věcnou problematiku,
jení na jiné systémy – systémy pro správu
marketingovými pracovníky, webovými
dokumentů, portály aj.
administrátory). To ocení především spoKouzlo většiny takových nástrojů tkví
lečnosti, které se snaží být aktivní a chtěv tom, že každá ze stran, která se podílí na
-jí poskytovat informace, chtějí mít své
publikování obsahu, se může věnovat tomu,
stránky živé, ale potřebují k tomu armádu
co je jí přirozené – odborníci vytváří obsah
webových specialistů.
(a nemusí vědět, kde všude a v jaké formě se
Vhodnost použití softwarových nástrojů
používá), marketingoví pracovníci se zaměřují roste s tím, jak se firma přibližuje jedné či
na vzhled v šablonách, manažeři schvalují, co více z následujících situací:
může a nemůže být publikováno a weboví
• Firma se skládá z více poboček (částí),
administrátoři pak zveřejňují stránky. Navíc
z nichž každá potřebuje zveřejňovat indíky vytvářeným šablonám a automatické
formace.
konverzi formátů lze výrazně šetřit čas
• Firma podporuje nejen firemní značku,
a věnovat jej např. komunikaci se zákazníky.
ale také samostatně propaguje proŠablony se používají nejen pro konkrétní
dukt/y – např. Twist nebo Go u našich
dokumenty, ale také případně pro strukturu
operátorů.
webu, web administrátoři tak mají významně
• Firma produkuje velké množství informaušetřenou práci.
cí a potřebuje je dávat k dispozici svému
Pokud bychom měli přínosy shrnout, jedná
okolí.
se o následující:
• Firma má interně několik částí (oddělení,
• Podpora udržování jednotného image.
poboček), které interně poskytují své
Potřeba zabezpečení jednotného image
služby širšímu okruhu zaměstnanců. Jejich
roste s množstvím poboček a jejich vlastkonzistentní popisy by měly být zveřejňoních stránek. Typicky se jedná o problém
vány na intranetu společnosti.
nadnárodních společností, u kterých si
Co říci závěrem? Udělat z rozbouřeného
každá národní pobočka vytváří vlastní moře informací klidně plynoucí potůčky, vywebové stránky. Často se stane, že z inter- žaduje nemalé úsilí tento živel zkrotit a jeho
netové prezentace není moc patrné jestli potenciální sílu využít ve svůj prospěch. Conse vůbec jedná o stejnou firmu či nikoliv tent Management (jak byla tato problematia zákazník je zmaten. Podobný problém ka pojmenována) pomáhá, aby firemní inforse dotýká i holdingů, samostatných firem, mace byly ve správné podobě doručovány na
které provozují více webových adres nebo patřičná místa. Je přece hezké, když zákazníci
firem, kde je odpovědnost za obsah a for- rádi sledují informace svého dodavatele, mísmu distribuovaná mezi více věcných oddě- to aby byli zmatení, případně hledali úkryty
lení. Mimo uvedené příklady se nástroje před desítkami „zajímavých“ mailů.
pro Web Content Management běžně
Síla Content Managementu je v tom, že
využívají také v rámci intranetů.
odděluje jednotlivé profese, které se na vzni• Úspory při administraci webů. Nástroje ku a publikaci informací podílejí, odděluje
pro Web Content Management zpravidla obsah (jako materiál, určený k publikaci) od
disponují funkcemi, které zamezí publi- způsobu jeho prezentace. Web Content Makaci slepých odkazů, umožní jednoduše nagement se stará o obojí – tj. obsah i formu
sdílet strukturu pro více webových adres – pro obojí zavádí standardy.
(případ národních poboček) a podpoří víZavádí standardy jak procesní, prezentačcejazyčnou prezentaci (včetně respekto- ní, tak i standardy pro strukturu prvotního
vání národních specifik). Použití nástrojů obsahu určeného k publikaci. Vedle toho
nelze než doporučit společnostem, které šetří práci tím, že poskytuje a automatizuje
disponují větším počtem „webistů“, kteří užitečné konverze nebo hlídá dodržování
se zabývají konstrukcí stránek.
pravidel.
Úvodní film k seriálu:
Žurnál Brig-IT Komix
Patrik Šálek, [email protected]
Můj milý deníčku,
jako duchovi mi můj moderní šéf dal za
úkol, abych se pohyboval v jedné nejmenované firmě a tak trochu na ně dohlížel a tak
trochu jim pomáhal. Pro tuto misi jsem si
původně vybral kódový název Brigáda v IT,
ale to bylo moc dlouhé a tak jsem skončil
u zkratky Brig-IT.
Začal jsem předevčírem. Byl jsem se tam
podívat a viděl jsem spoustu zajímavých
věcí, ještě teď jsem z toho celý rozlítaný. Je
tam skoro sto lidí a všichni dělají takové věci,
kterým nerozumím. Pořád o něčem mluví
takovým divným jazykem, ťukají do počítače a tváří se strašně zadumaně. Tak jsem je
chvíli poslouchal. Mají tam projekty a ISO.
Chvíli jsem tomu moc nerozuměl, pak jsem
ale zjistil, co to ISO znamená.
To je, že mají přesně napsané postupy, jak
jsou takové projekty řízeny, dokumentovány,
co vedoucí projektu (to je něco jako můj šéf)
zajišťuje, jak vypadá tým apod. Například je
přesně stanoveno, kdy se vytváří jaké dokumenty, kdo je vytváří, kdo schvaluje a kde
jsou uloženy.
Je to ale složitější nebo možná jednodušší.
Může se totiž říci, že některé projekty jsou
sledovány podrobněji a některé méně – např.
podle velikosti, složitosti, požadavků zákazníka apod. Takže na začátku projektu musí
vedoucí zvolit odpovídající postupy a činnosti v souladu se stanovenými pracovními
postupy.
Vedoucí tak na začátku projektu např. musí
zpracovat plán. Vybere si z firemních šablon,
které uplatní. Stanoví, jak budou řízeny změny, rizika a další. Definuje způsob označování
dokumentů, rozdělí odpovědnosti a potom
sleduje průběh prací. Zákazníkovi tímto způsobem lze doložit zabezpečení úrovně jakosti
produktu.
Deníčku, řízení projektů – to je první věc,
na kterou musím dávat pozor. Na chodbě
jsem zaslechl, že ve firmě zavládl dobrý duch
spolupráce. Šéf ale neříkal, že by posílal ještě
někoho…
Teď ale budu končit. I když duchové nespí,
musí taky někdy odpočívat. Jsem z toho všeho
nějaký celý rozlítaný. Až zas narazím na něco
zajímavého, ozvu se.
Zajistit trasovatelnost nebo tápat?
Tomáš Hrubý, [email protected]
O tom co je potřeba dělat proto, aby projekt vývoje IS dobře skončil, bylo už napsáno
mnoho stran. Zpravidla jde o popisy dílčích
nutných, avšak nikoliv postačujících podmínek. Kompletní skládanka z těchto podmínek pak může vést k úspěchu. Jedním z významných předpokladů úspěchu je i koncept
tzv. trasovatelnosti, který byl v minulých
letech analytickým týmem KOMIXu rozvíjen.
Přiblížení tohoto konceptu je předmětem
následujícího článku.
Neznáte tyto situace?
Zpravidla každý, kdo pracoval na nějakém
projektu tvorby IS, se někdy dostal do situace, kterou bylo z nějakého důvodu velmi
obtížné řešit. Neznáte náhodou některou
z následujících situací?
- Uživatel potřebuje změnu funkčnosti systému, ale je obtížné zjistit, kde všude se
změna musí promítnout.
- Je třeba zjistit, zda a jak jsou zapracovány
všechny uživatelské požadavky, ale je to
značně obtížné.
- Existuje implementovaná funkčnost, ale
nikdo neví, jaký uživatelský požadavek
realizuje a proč tam vůbec je.
- Testeři chtějí specifikovat testy, ale nevědí,
jaké informace k tomu mají využít.
2
- Uživatelé by rádi věděli, které z jejich
požadavků prošly systémovými testy, ale
nevědí, jak to zjistit.
Pokud vám některá z uvedených nebo
obdobných situací připadá povědomá, pokud jste se v ní osobně ocitli a už ji nechcete
opakovat, anebo pokud vás jen zajímá, co
dělat, abyste se do takovéto situace nedostali, čtěte dál.
Co je to trasovatelnost?
Vývoj systému si je možné představit jako
transformaci výstupů jednotlivých etap projektu. Uživatelské požadavky jsou transformovány na globální analýzu a návrh, tato
pak na detailní analýzu a návrh a dále na
programový kód. Všechny zmíněné výstupy
jsou dále vstupem pro tvorbu testů a testovacích případů. Projektové dokumenty
se skládají resp. obsahují mnoho prvků.
Například katalog uživatelských požadavků
obsahuje jako své prvky jednotlivé uživatelské požadavky nebo hodnoty rozšiřujících
atributů požadavků. Mezi všemi uvedenými
prvky existují určité vztahy. Právě znalost
těchto vztahů je jednou z podmínek, které
mohou pomoci dovést projekt k úspěšnému
konci. Co je tedy v tomto kontextu trasovatelnost (angl. tracebility)? Jde o možnost
vztahy mezi uvedenými projektovými výstupy dohledávat.
O vztazích a o vazbách
Cesta k zajištění trasovatelnosti je v definici vazeb. Vazbou nazýváme záznam určitého
vztahu mezi projektovými výstupy (formalizaci vztahu). Mezi projektovými informacemi může existovat určitý vztah a je na nás,
zda mezi nimi vytvoříme vazbu.
Transformace projektových výstupů znamená, že určitý prvek výstupu předchozí etapy
je transformován na prvek (prvky) etapy následující. Náročnost zajištění trasovatelnosti
spočívá ve skutečnosti, že v průběhu celého
vývojového cyklu se setkáváme s transformacemi typu M:N. Jeden prvek může být
transformován do více prvků následující fáze
a opačně, jeden prvek může vzniknout transformací více prvků fáze předchozí.
Vztahy mohou existovat buď v rámci dokumentace jednotlivých vývojových etap nebo
mezi prvky dokumentů různých etap. Vazby
říkají, jakými prvky globální analýzy a návrhu
jsou pokryty jednotlivé uživatelské požadavky, do jakých prvků se promítnou v detailním
návrhu, jakými částmi programového kódu
jsou řešeny a jakými testy jsou ověřovány.
Vzhledem k M:N transformacím zde existuje
obrovské množství vztahů. Obdobně je to se
vztahy v rámci dokumentace jednotlivých
vývojových etap. Těmi jsou například vztahy
mezi uživatelskými požadavky.
Softwarová podpora
trasovatelnosti
Mít koncept trasovatelnosti zvládnutý
teoreticky nestačí. Pokud jej budeme chtít
skutečně aplikovat v praxi, nutně narazíme na otázku technické realizace vazeb.
Objem projektových výstupů, které by
měly být trasovány, může být značně veliký. Proto je nezbytné přesunout část práce
na softwarové nástroje. Jiné „ruční“ podpůrné techniky (matice vazeb, atributy
prvků s odkazy na jiné prvky apod.) dnes
zpravidla nestačí.
Zajištění trasovatelnosti je inženýrská úloha – tvorbu všech definovaných vazeb nelze
zcela automatizovat. Lze ji ale vhodným softwarovým nástrojem efektivně podpořit.
Podpora trasovatelnosti je součástí téměř
všech nástrojů, které jsou při vývoji systémů
využívány:
- nástroje pro podporu procesního inženýrství (např. BPWin)
- nástroje pro správu požadavků (např.
DOORS)
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
pokračování ze strany 2
- nástroje pro analýzu a návrh systému
(např. Telelogic Tau)
- nástroje pro podporu kódování a obecná
vývojová prostředí (např. Eclipse)
- nástroje pro podporu testování (např.
TestDirector)
- a další typy nástrojů (konfigurační management, change management, řízení projektu apod.).
V současné době je patrný trend integrovat více typů těchto nástrojů do samostatných systémů (např. podpora analýzy a návrhu, kódování a testování v nástroji Together
ControlCenter) nebo do komplexních
vývojových linek (např. integrace nástrojů
DOORS – Telelogic Tau – TestDirector).
Přínosy kvalitní trasovatelnosti jsou
nesporné. Tento článek akcentuje pouze
oblast věcného procesu vývoje systému.
Trasovatelnost však můžeme chápat v širším
pojetí a zohlednit i proces řízení projektových prací. Potom by bylo třeba uvedený
popis přínosů ještě výrazně rozšířit.
Úskalí trasovatelnosti
S čím nám nástroj může pomoci?
Nezanedbatelný podíl práce při zajištění
trasovatelnosti se v uvedených nástrojích
musí stále provádět ručně. Sem patří například definice vazeb mezi uživatelskými požadavky, definice časové souslednosti aktivit
procesních modelů nebo definice vazeb mezi
testy v testovacích sadách. Patří sem dále
velká část vazeb mezi výstupy jednotlivých
vývojových etap. I úlohy tohoto typu však
softwarové nástroje dokáží efektivně podpořit. Například v nástroji DOORS je možné,
kromě vlastního vytvoření vazby mezi požadavky, definovat volitelné atributy vazeb,
vazby zařazovat podle typů do skupin, celý
systém vazeb přehledně vizualizovat a provádět nad ním velmi přínosné analýzy (např.
analýzu dopadu změny požadavku).
Obrázek 2: Trasovatelnost mezi prvky diagramů a programovým kódem v nástroji Together
ControlCenter
vývojovou linku složenou obvykle z několika
nástrojů - nástrojem pro správu požadavků
počínaje a nástroji pro tvorbu a správu testů
konče. Některé oblasti vztahů je zde opět
možné automatizovat. Takováto integrace
pak například umožňuje generování struktury testů a testovacích případů na základě
Využití a přínosy
Klíčový přínos trasovatelnosti spočívá v existenci kvalitních podkladů pro změnové řízení
systému. V průběhu vývoje i po dokončení
musí být do systému a jeho dokumentace
zapracovávány potřebné změny. Pouze díky
trasovatelnosti je možné zjistit, kde všude je
nutné změnu promítnout a jaké části programu musí být přetestovány. Bez kvalitní
trasovatelné dokumentace nemůže tedy být
systém úspěšně a ekonomicky udržovatelný.
Znalost vztahů mezi prvky projektových
výstupů je dále nezbytná pro realizaci vlastních vývojových činností. Znalost souvislostí
umožňuje lepší pochopení věcné problematiky systému a tak jednotlivým vývojářům
usnadňuje práci a zefektivňuje ji. Umožňuje
dále zjistit, jaké vstupy je nutné pro práci
využít a kde je hledat. Analytici potřebují
vědět, jaké jsou vztahy mezi uživatelskými
požadavky, návrháři musí vědět o všech
vztazích prvků analýzy a testerům ukáže trasovatelnost cestu ke všem informacím, které
je třeba pro tvorbu testů využít.
Koncept trasovatelnosti významně přispívá i k redukci objemu projektových výstupů.
Každou informaci udržujeme jen na jediném
místě a pokud s ní potřebujeme pracovat
jinde, jednoduše na ni vedeme vazbu (odkážeme se na ni).
V popisu přínosů bychom mohli pokračovat.
Významné je například využití trasovatelnosti
pro sledování softwarových metrik (možnost
zjištění pokrytí požadavků testy apod.).
Jaká má trasovatelnost úskalí, kde může
být problém a na co si dát pozor?
Předně, vybudování trasovatelnosti není
zadarmo. Vytváření a údržba definovaných
vazeb jsou časově náročné činnosti a je třeba
počítat s tím, že odčerpají část projektových
zdrojů a že na větším projektu si mohou vyžádat i nemalé investice. Ty se však vrátí. Za
vynaložené peníze si kupujeme jakousi slevu
na další budoucí výdaje (zvýšení efektivnosti
vývoje, zlepšení udržovatelnosti apod.).
Tvorba trasovatelnosti klade dále určité
nároky na důslednost lidské práce. Každá
změna se musí v systému vazeb odpovídajícím způsobem promítnout. Neaktuální
vazby mohou způsobit více škod než vazby
žádné. Zde opět výrazně pomáhají softwarové nástroje.
Určitým problémem, před kterým každý
projektový tým stojí, je optimální míra trasovatelnosti, tj. rozsah v jakém jsou projektové výstupy vzájemně propojeny vazbami.
Jedním extrémem může být definice vazeb
pro naprosto všechny dílčí prvky projektových výstupů, které společně mohou vytvářet nezvládnutelně složitou síť. Druhým extrémem může být vazby vůbec nedefinovat.
Univerzální jednoznačné pravidlo neexistuje.
Trasovatelnost se především musí vyplatit. Je
nutné najít rozumný kompromis mezi náklady, které by bylo za ni nutné zaplatit, a mezi
přínosy, které z ní můžeme vytěžit. Neméně
důležité je, aby systém vazeb měl dostatečnou informační hodnotu, ale zároveň aby
zůstal jednoduchý. Do detailu propracovaná
spleť vazeb může být při její velké složitosti
spíše problémem než přínosem. Nejhorší je
dojít k tomu, že vše souvisí se vším. Při tvorbě každé vazby si je proto třeba klást otázku,
zda je její záznam nezbytný a k čemu tuto
informaci později využijeme. Vždy záleží na
konkrétní situaci, na konkrétním projektu.
Trasovatelnost je v projektech tvorby IS
nezbytnou podmínkou. Výrazně může zvýšit přidanou hodnotu projektových výstupů.
Pokud se nám ji podaří zajistit, můžeme čerpat z řady jejích přínosů. Nenahraditelnou
úlohu zde hrají podpůrné softwarové
nástroje, které dokáží ušetřit velkou část
práce. Trasovatelnost má i svá úskalí. Pokud
však budeme respektovat zásady zdravého
rozumu, zajistíme jeden z klíčových faktorů
úspěchu projektu.
Obrázek 1: Zobrazení vazeb mezi požadavky v nástroji DOORS
Obrázek 3: Ukázka integrace nástrojů DOORS a Telelogic Tau
V řadě oblastí lze vhodnými nástroji
zajištění trasovatelnosti do určité míry automatizovat. Vazby jsou často automaticky
vytvářeny souběžně se standardní tvorbou
projektových výstupů a stávají se jejich
přirozenou součástí. Tuto významnou pomoc softwarových nástrojů si mnohdy ani
neuvědomujeme. Při dekompozici určitého
prvku v analytickém diagramu je automaticky CASE nástrojem definována vazba mezi
tímto prvkem a dceřinným diagramem, vazby jsou definovány při opětovném využití
jednoho objektu ve více diagramech apod.
Mnoho práce bylo uděláno v oblasti trasovatelnosti výstupů analýzy a návrhu systému
na programový kód. Pro příklad lze opět
uvést CASE nástroj Together ControlCenter.
Zde je možné na základě určitých návrhových diagramů (Class diagram a Sequence
diagram) generovat kostru programového
kódu, přičemž mezi prvky těchto diagramů
a částmi kódu je také automaticky uložena
vazba. Změny v diagramech se pak automaticky promítají do kódu a opačně.
Zajištění podpory trasovatelnosti napříč
celým životním cyklem systému je složitější
úlohou. Znamená to vybudovat komplexní
vytvořených analytických diagramů (např.
Use case a Sequence diagramů) a zpětné
vztažení výsledků testů k uživatelským požadavkům. Vybudování kvalitní vývojové linky není jednoduché a není levné. Je to však
cesta ke komplexní podpoře trasovatelnosti
a velké úspoře lidské práce.
(viz obr. 3)
3
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
S Microstrategy na datový sklad
Systém MicroStrategy 7i je jedním z řady
produktů, které společnost KOMIX s.r.o. nabízí svým zákazníkům pro kvalitní prezentaci
informací z datových skladů.
Systém MicroStrategy 7i představuje kompletní platformu, která zahrnuje podporu
celé oblasti tzv. Business Intelligence od definování faktů, dimenzí a reportů přes správu
uživatelů až po sofistikovanou distribuci
informací různou formou na základě rozličných podnětů.
Firma Microstrategy byla založena roku
1989 v USA a může se pochlubit 2000 zákazníků včetně Bank of Montreal, Amway nebo
Benetton. V České republice zatím počet
zákazníků dosahuje spíše jednotek. Hlavní
příčinu vidím kromě krátké tradice v poměrně vysoké ceně produktu. Za příslušnou cenu
však zákazník dostává špičkový software
s velikým potenciálním přínosem. Společnost
KOMIX s.r.o. jako jeden z partnerů distributorské firmy Insight Strategy může přispět k
dalšímu rozšíření tohoto bezpochyby kvalitního a výkonného software.
Produkt MicroStrategy 7i se skládá z jednotlivých modulů, z nichž si zákazník podle
svých potřeb poskládá cílovou konfiguraci.
Základním modulem je Microstrategy 7i
Intelligence Server, který zajišťuje zpracování požadavků od klientů, jejich převedení na
SQL dotazy a spuštění těchto dotazů v relační databázi. Vlastní datový sklad může být
vytvořen v libovolné databázi. Je potřeba
pouze definovat tuto databázi jako ODBC
zdroj. Po vrácení výsledků dotazu z databáze jsou tyto ve formě tabulky či grafu předány zpět klientovi. Všechna metadata (definice reportů, dimenzí, faktů, filtrů, uživatelů
a jejich práv nebo databázových spojení)
jsou uložena rovněž ve formě databáze.
Podmínkou je opět pouze existence ODBC
spojení na tuto databázi, takže i ta může
existovat v libovolných SŘBD. Není pak
problém provádět vývoj aplikace v prostředí
dodavatele nad malým vzorkem dat a poté
zkopírovat databázi metadat k zákazníkovi.
Metadata lze takto také snadno zálohovat
v důležitých momentech vývoje.
Microstrategy Intelligence Server dále
zajišťuje řízení přístupových práv uživatelů, je možné omezit množství připojených
uživatelů, počty najednou zpracovávaných
dotazů nebo dobu provádění jednoho dotazu. Důležitá je práce s vyrovnávací pamětí
(cache), která umožňuje rychlé zobrazení
výsledků dotazu již v minulosti spočítaného
a to i pro jiný typ klienta (Desktop, web). Po
nahrání nových dat do datového skladu je
třeba související reporty z cache vymazat, aby
se nová data v sestavách objevila. Vhodné je
i nastavení trvanlivosti cache, která by měla
odpovídat periodě pumpování dat. Důležité
je, že Microstrategy optimalizuje dotaz tak,
aby se prováděl nad co nejmenší tabulkou.
Pro podporu této vlastnosti je výhodné v datovém skladu navrhnout, či později doplnit
příslušné úrovně agregací.
Architektura s MicroStrategy 7i je důsledně
objektová, definované objekty lze opakovaně použít na dalších úrovních. Například
vytvořené filtry lze použít v reportech, metrikách nebo jako součást složitějších filtrů.
Pokud se změní struktura nebo název datové
tabulky, stačí tuto změnu promítnout v objektu typu fakt a odvozené objekty nadále
bez problémů fungují. Systém hlídá závislosti
mezi objekty, takže nedovolí smazat objekt
použitý v jiných objektech. Během vývoje
aplikace nám jsou nápomocny různé nástroje, které při vhodném pojmenování tabulek
a sloupců umožní rychlou definici základních
objektů typu fakt a atribut. Vedle klasických
sestav typu „zisk podle distributora“ lze
vytvářet i složité sestavy využívající rozsáhlý
aparát matematických, statistických a dalších
funkcí. Nelze upravit vygenerovaný SQL dotaz, ale pomocí mnoha voleb ho lze optimalizovat a ovlivnit počet vrácených řádků (inner
/ outer join apod.).
Produkt MicroStrategy 7i je možno využívat v několika modifikacích v závislosti na
kladených požadavcích.
Microstrategy Desktop je aplikace typu
těžký klient, která umožňuje tvorbu a správu veškerých objektů v projektu používaných. MicroStrategy Desktop tvoří konzoli,
která integruje moduly Designer, Analyst,
Architekt a Administrator. Aplikace podporuje různé úrovně práce uživatele tj. spouštění
a modifikace reportů, vytváření a definice
nových objektů, návrh a konfigurace celých
datových tržišť.
Další možností využití produktu MicroStrategy 7i je použití modulu MicroStrategy
Web, opět s třemi typy (Reporter, Analyst,
Professional). Mezi Intelligence Serverem a
webovým prohlížečem je v tomto případě
umístěn ještě webový server, typicky MS
Internet Information Server. Jedná se o čisté HTML řešení, takže na klientský systém
nejsou kladeny žádné zvláštní požadavky.
Kromě práce s objekty na nejnižší úrovni
skýtá webové prostředí stejné možnosti jako
Desktop, záleží jen na nastavení práv jednotlivých uživatelů nebo uživatelských skupin. Kromě sdílených sestav viděných všemi
uživateli je možné ukládat si své sestavy do
soukromých adresářů.
Při práci s tak rozsáhlým systémem se samozřejmě nelze vyhnout některým problémům.
Například exporty z prostředí MS7i Web do
prostředí MS Excel, který je standardně podporován, byl citlivý na verzi
I
T
A
K
V
A
L
I
T
Petr Matoušek, [email protected]
MS Excel na straně serveru i u klienta. Další
komplikace, s nimiž jsme se setkali, pramenily nejčastěji z nastavení národního prostředí
OS serveru, databází nebo Microstrategy
serveru. Občas chyba spočívala i ve špatném
generování SQL dotazu, což je samozřejmě
závažné, ale zatím se vše i díky podpoře dodavatele podařilo vyřešit.
V krátkém článku jsem se nemohl zmínit o
všech vlastnostech systému. Za zmínku stojí
ještě například modul Narrowcast Server,
který transformuje Intelligence Serveru požadavky zasílané e-mailem, faxem nebo SMS
a vrací výsledky v přiměřené formě zpět na
tato zařízení. Pro vývojáře je důležitý modul
MicroStrategy SDK, který otevírá funkce
používané v systému a umožňuje zahrnout
objekty MicroStrategy 7i do jiných aplikací.
Potřeba získávání významných podnikových informací z prostředí datových skladů
hovoří jasně pro nasazení kvalitního software. Jsem rád, že na závěr mohu zodpovědně říci, že produkt MicroStrategy 7i takovým
softwarem rozhodně je.
http://www.microstrategy.com
Obr: Architektura MicroStrategy pro analýzu a distribuci podnikových informací
Selektivní šifrování dat uložených v databázi
Jan Rada, [email protected]
Hrozby odcizení, pozměnění či
zneužití citlivých dat
Podle údajů odvozených z přehledu 2002
Computer Crime and Security Survey, který vypracoval americký Computer Security
Institute ve spolupráci s FBI, došlo v minulém
roce v USA k odcizení dat zhruba v 10% z několika set oslovených organizací; průměrná
škoda přitom činila přes 6 milionů dolarů.
Například v únoru 2003 bylo v Severní
Americe oznámeno odcizení 8 milionů čísel
kreditních karet Visa, MasterCard, American
Express a Morgan Stanley internetovému
obchodníkovi.
Podle různých odhadů směřuje 60 i více procent úspěšných útoků zevnitř organizace.
Vnitřní útočník, často v roli správce, nemusí
překonávat firewally, běžně se přihlašuje
s velkými privilegii a může využít svou znalost zranitelných míst systému.
Důležitým opatřením proti vnitřnímu pokusu o neoprávněné přečtení či pozměnění
citlivých dat a poslední instancí při útoku
z vnějšku je zašifrování citlivých dat uložených v databázi, kde tato data stráví většinu
svého životního cyklu. Poznamenejme ovšem,
4
že samotné šifrování obvykle pro utajení dat
uložených v databázi nepostačí a že ochrana
dat zahrnuje kromě utajení dat uložených
v databázi i zajištění dalších bezpečnostních
požadavků, například dostupnosti dat, utajení přenášených dat a utajení dokumentů
uložených v souborovém systému.
Zašifrování pro utajení
a autentičnost dat
Zašifrování dat uložených v databázi je důležité opatření pro utajení dat vůči uživateli,
který k nim nemá oprávněný přístup, ale
mohl by potřebná přístupová práva nějak
získat a data posléze odcizit. K šifrovacím
funkcím bývají přiřazovány i různé kontrolní
součty a hashovací funkce, sloužící pro kontrolu toho, že data nebyla pozměněna.
Pro utajení dat uložených v databázi se běžně používají symetrické šifrovací algoritmy,
které jsou rychlejší než asymetrické. Navíc
v databázích se obecně méně hodí obvyklé
postupy použití dvojice soukromý+veřejný
klíč asymetrického algoritmu, protože data
musejí být sdílena relativně dlouho velkým
počtem uživatelů, a to jak pro čtení, tak pro
vkládání, opravy a rušení.
Lze si ovšem představit využití asymetrického šifrování databázových dat v případě,
že v bezpečnostních požadavcích je kladen
důraz na autentičnost dat a odpovědnost
uživatele za ně. Při vkládání či opravě dat by
data byla zašifrována soukromým klíčem daného uživatele. Při čtení by pak data byla odšifrována pomocí veřejného klíče uživatele,
který je zapsal. Veřejné klíče by byly sdíleny
všemi oprávněnými uživateli, ovšem ostatním by musely být utajeny, pokud by mělo
být zachováno utajení dat. Daný přístup by
tak byl spojen s relativně velkými nároky na
správu klíčů.
Správa šifrovacích klíčů
Správa klíčů pokrývá celý jejich životní cyklus,
tj. generování, distribuci, uchování, použití,
rušení, změnu a obnovu. Správa klíčů je velice důležitou součástí ochrany dat; důvěrnost
zašifrovaných dat je zajištěna pouze do té
míry, do jaké je zajištěna důvěrnost šifrovacích klíčů.
Klíče by měly být uchovávány odděleně od
dat a v zašifrovaném tvaru či ještě lépe v důvěryhodném výpočetním prostředí hardwarového bezpečnostního modulu. Bývají pou-
žívány i kombinace různých způsobů uchování, například klíče pro zašifrování aplikačních
dat se ukládají v zašifrovaném tvaru do
oddělené databáze, a klíč vyšší úrovně, který
slouží pro zašifrování klíčů s nižší úrovní, je
uložen v hardwarovém bezpečnostním modulu, který pokud možno ani neopouští.
V úvahu přichází též uchování šifrovacího
klíče vyšší úrovně mimo výpočetní systém
a jeho zadávání uživatelem, například prostřednictvím čipové karty, případně generováním klíče na základě silného hesla. Nejlepší
správa klíčů je ovšem správa automatizovaná, minimalizující vliv lidského faktoru
a možnost individuálního selhání. Operace
zadání klíče uživatelem je pak vyhrazena pro
situaci, kdy je potřeba obnovit klíč vyšší úrovně, například po zapomenutí hesla či selhání
hardwaru.
Šifrovací práva autentizovaných
uživatelů
Aby oprávněný uživatel mohl pracovat s daty chráněnými šifrováním a neoprávněný
ne, musí být spolehlivě ověřeny identity
uživatelů a rozlišena resp. řízena jejich šifrovací práva.
A
Z
N
A
L
O
S
T
Z
K
Šifrovací práva jsou v zásadě práva přístupu
k šifrovacímu mechanismu a šifrovacímu
klíči použitému pro daná data. Navenek
mohou mít i podobu práv přístupu k daným
citlivým datům, zejména v případě plně automatizované správy klíčů.
Šifrovací práva musí být nedostupná útočníkům, jinak by zašifrování citlivých dat bylo
zbytečné. Například zašifrování kombinované s běžným řízením přístupu k datům na
databázové úrovni by mohlo pomoci proti
útočníkovi, který je schopen získat pouze
přístup k databázovým souborům (nebo
jejich zálohám) na úrovni operačního systému. Nepomohlo by již proti útočníkovi,
který je schopen se přihlásit jako oprávněný
uživatel do databáze. Což může být případ
databázového administrátora, který může
například změnit databázová přístupová
práva libovolného uživatele, přihlásit se
jako libovolný databázový uživatel poté, co
změní jeho heslo, a zamést stopy po své činnosti v databázových auditních záznamech.
Tytéž možnosti má samozřejmě i jakýkoli
vnitřní případně vnější útočník, kterému
se podařilo získat identitu databázového
správce.
Bezpečnostní audit
Generování a vyhodnocování auditních
záznamů o činnostech uživatelů slouží
zejména k tomu, aby případné selhání šifrování a ostatních bezpečnostních opatření
neproběhlo nepozorovaně, aby bylo možné prokázat nevinu či naopak odpovědnost
příslušných pracovníků a doporučit zdokonalení ochrany. Audit je nezastupitelný pro
kontrolu činnosti bezpečnostního správce
a uživatelů, kteří mají přístupová práva
k citlivým datům a mohli by je zneužít pro
jiné než pracovní účely.
U
Š
E
N
O
S
T
P
R
Při auditu je nutno řešit otázky objemu
auditních záznamů a postupů zjišťování podezřelých činností, například neobvyklých
přístupů k citlivým datům. Pro tyto účely
jsou žádoucí možnosti pružného řízení
rozsahu generování a prohlížení auditních
záznamů, případně možnosti exportovat je
pro další využití, například pro vyhodnocení
pomocí analytických nástrojů.
Důležitou podmínkou použitelnosti auditních záznamů je jejich důvěryhodnost.
Záznamy by stejně jako šifrovací práva
a mechanismy měly být chráněny i proti
útokům správců. Měly by například být
uloženy odděleně od dat, v zašifrovaném
tvaru, s kontrolou integrity.
Centrálně spravované selektivní šifrování v databázi
Selektivním šifrováním rozumíme šifrování
vybraných sloupců databázových tabulek.
Hlavním důvodem pro selektivnost šifrování je výkon. Při šifrování celé databáze
či databázového souboru by byla šifrována
nejen ta aplikační data, která případně nepotřebují ochranu, ale i „režijní“ a pracovní
data (hlavičky uložení dat, tabulky transakcí a volného prostoru, adresy a odkazy
atd.). Šifrování celé databáze by tak mohlo
být vhodné pro okrajové požadavky – například pro menší databáze s velkým podílem citlivých položek nebo pro ochranu
proti vyvození důvěrných informací z údajů
systémového katalogu.
V ideálním případě je selektivní šifrování
centrálně spravované. Centrální správa
umožní snáze prosadit konzistentní politiku ochrany dat v celé organizaci a svěřit
tento úkol specializovanému bezpečnostnímu správci, který nebude potřebovat zna-
O
F
E
S
I
O
N
A
L
losti konkrétních aplikací a databázových
a operačních systémů.
Selektivní šifrování lze realizovat v databázové či v aplikační vrstvě. Hlavní výhodou
první možnosti je aplikačně průhledná
ochrana dat. Kdyby šifrování bylo volané
z aplikační vrstvy, byla by k jeho zavedení
a ke každé změně šifrovací politiky nutná
účast vývojářů aplikací.
Principem aplikační průhlednosti je zašifrování sloupce tabulky, náhrada původní
tabulky stejnojmenným dešifrujícím pohledem na zašifrovanou tabulku a zavedení šifrujících triggerů pro modifikace
dat tohoto pohledu. V ideálním případě
jsou uvedené operace prováděny automatizovaně – bezpečnostnímu správci
stačí pouze vybrat sloupec a zmáčknout
tlačítko. Nositelem šifrovacích práv je obvykle databázový uživatel. Vlastní šifrovací
operace může být výhodné provádět mimo
databázi, pokud takto lze využít existující
šifrovací mechanismus či rezervní výpočetní
kapacity nebo zajistit bezpečnější výpočetní
prostředí, například pomocí hardwarového
bezpečnostního modulu.
V praxi jsou i přes aplikační průhlednost
někdy nutné dílčí úpravy aplikace resp.
její databázové vrstvy. Například triggery,
defaultní hodnoty a integritní kontroly
navržené pro nezašifrovaný sloupec obecně nebudou fungovat po jeho zašifrování
a jejich funkčnost je vhodné přesunout do
šifrujících triggerů. Většinu takových úprav
by ovšem bylo nutné řešit i při šifrování na
aplikační vrstvě, nemluvě o dalších potřebných úpravách.
I
T
A
K
V
A
L
I
T
jednou provždy a pro zpracování v jediné
aplikaci - automaticky budou utajeny při
přístupu z ostatních aplikací, například
z univerzálních nástrojů databázového
správce. Spolehlivost takového „opatření“
samozřejmě závisí mimo jiné na tom, zda
útočník nemůže vyvinout svou aplikaci využívající stejné šifrovací funkce a klíče.
Realizace selektivního šifrování
Pro aplikačně průhledné selektivní šifrování je možné použít několika hotových
řešení, například produktu Secure.Data
od Protegrity, DbEncrypt od Application
Security a Encryption Wizard for Oracle
od RDC. Největší bezpečnost dat, funkčnost a komfort poskytuje zřejmě produkt
Secure.Data, který se vyznačuje například
řadou opatření pro ochranu šifrovacích
a auditních mechanismů před útoky databázového správce.
Při speciálních požadavcích může být potřebný či užitečný vlastní vývoj selektivního
šifrování. Na trhu je k dispozici řada knihoven šifrovacích funkcí a SW či HW modulů
s API, které tento vývoj různou měrou podporují. Vlastní vývoj by například asi mohl
být finančně výhodný při malých nárocích
na bezpečnost citlivých dat jedné aplikace
nad databází Oracle, která je dodávána
s knihovnou základních šifrovacích algoritmů.
Šifrování na aplikační vrstvě může být výhodné, pokud citlivé položky jsou určené
PRONÁJEM
POČÍTAČOVÉ
UČEBNY
• dostupná lokalita
• kvalitní zázemí
• moderní počítačová
a projekční technika
• možnost celodenního,
půldenního či týdenního
pronájmu za velmi
příznivé ceny
Volejte:
+420 225 989 811
www.komix.cz
Ochrana dat
Ztratilo se Vám někdy něco, nebo Vám
něco ukradli? Jistě mi dáte za pravdu, že
kromě zlého pocitu Vám vznikly i jiné problémy. Při ztrátě dokladů je těch problémů
ještě mnohem více. Tomu všemu se dá předejít
koupením toho správného zabezpečení. Že je
jich na trhu hodně, dokazují reklamy, které
dostávám každý týden do své dopisní schránky. Přistupujeme i k ochraně elektronických
informací s takovou péčí jako k hmotnému
majetku? A existuje vůbec nějaká možnost
chránit si tyto informace před „nenechavci“?
Můžu Vás uklidnit, tyto možnosti tady jsou
a něco si o nich povíme.
Již v minulosti při psaní dopisů sdělujících
něco důležitého vznikla potřeba tyto informace zašifrovat. Nejjednodušší formou bylo,
v docela nevinném textu, do těch správných
míst doplnit text naší zprávy. Příjemce vlastnil
tabulku, podle které se dostal k zašifrovanému textu. Tato metoda v době počítačů se jeví
k pousmání, ale v té době byla docela efektivní. Doba nám dává za pravdu, jak je důležité si
své informace chránit. Je možné připomenout
příběh šifrovacího stroje Enigma, který používali Němci za druhé světové války. Spojencům
se v tomto případě podařilo jeden exemplář
ukořistit a napomoct tak k vyluštění šifry, kterou se šifrovaly důležité zprávy pro velitelství
Německé armády. Dá se říci, že rozluštění této
šifry mělo nemalý vliv na průběh Druhé světové války.
A co dnes, když nás bankovní ústavy přesvědčují o výhodách elektronické komunikace
a platbách kreditními kartami, existuje nějaké
riziko zcizení našich dat? Co musí takový bezpečný systém splňovat, je shrnuto v následujících bodech:
• důvěrnost informací – systém musí zabezpečit, že neautorizované subjekty nebudou
mít možnost přístupu k důvěrným informacím,
• integrita - systém musí zabezpečit informace proti neautorizované modifikaci,
• neodmítnutelnost odpovědnosti – systém musí zabezpečit prevenci proti ztrátě
schopnosti přesvědčit třetí nezávislou stranu
Martin Janček, [email protected]
o přímé odpovědnosti subjektu za odeslání,
případně přijetí zprávy.
Otázkou zůstává, jak tyto předchozí body
uskutečnit. Fyzická ochrana přenášených dat
by byla náročná, takže nám zbývá ochrana
logická a to pomocí šifrování. Znamená to
zašifrovat data na straně odesilatele, odeslat
je a na straně příjemce zase dešifrovat. Kvalita
logické ochrany zprávy je dána šifrovací metodou, typem užitého algoritmu, jeho aplikací
a délkou šifrovacího klíče.
Je možné říci, že rozlišujeme dvě metody
pro zabezpečení našich dat:
Symetrická metoda (Symetrická kryptografie),
Asymetrická metoda (Asymetrická kryptografie).
Symetrická kryptografie
Princip této kryptografie spočívá v tom,
že stejný klíč, který byl použit k zašifrování
zprávy na straně odesílatele, bude použit
i na straně příjemce pro dešifrování zprávy.
Z toho vyplývá nutnost před začátkem ko-
munikace poslat šifrovací klíč spolu s dalšími
údaji příjemci. Současná výpočetní technika
aplikuje algoritmy (např. DES, TRIPLEDES,
AES) téměř v reálném čase. Na druhé straně pomocí té samé techniky je možné data
dešifrovat i bez znalosti privátního klíče.
Pomocí dostupných metod je možné docela
přesně určit, za jak dlouho je možné data
dešifrovat. Tyto metody jsou však nákladné.
Volbou délky klíče, který se použije pro šifrování, lze čas potřebný pro rozluštění šifry
podstatně ovlivnit. Co uvádějí dostupné
prameny? Při použití klíče s délkou 40 bitů
je možné zdolat šifru za pomoci paralelního
algoritmu s použitím 1200 propojených počítačů za necelé 4 hodiny. Doba rozkódování
s délkou klíče roste velmi rychle (128 bitů 1000 počítačů a 3.10exp22 let). Použití symetrických algoritmů představuje způsob, jak
zabezpečit důvěrnost. Ale neřeší požadavek
neodmítnutelnosti odpovědnosti. Nelze totiž určit, která strana zprávu odeslala, a která přijala. Každá strana používá stejný klíč.
5
A
Z
N
A
L
O
S
T
Z
K
Asymetrická kryptografie
Oproti symetrické kryptografii se zde užívá
dvojice klíčů. Tuto dvojici klíčů si vygeneruje
uživatel pomocí některého z běžně dostupných produktů. K tomuto je například možné použít OpenSSL http://www.openssl.org.
Princip použití spočívá v tom, že data šifrovaná jedním z klíčů lze dešifrovat pouze
pomocí druhého z dvojice klíčů a naopak.
Jeden z nich, takzvaný privátní klíč má
jenom majitel, zatímco druhý klíč je publikován. Pokud známe vlastníka veřejného
klíče, kterým jsme zprávu dešifrovali, známe
i odesílatele. Protože je veřejný klíč obecně
znám všem, nelze zašifrovanou zprávu považovat za zašifrovanou v plném smyslu slova,
ale pouze za podepsanou. Celý tento systém
pro šifrování a podepisování zpráv pomocí
asymetrické kryptografie pracuje tedy následovně. Zpráva je na straně odesilatele nejpr-
U
Š
E
N
O
S
T
P
R
ve podepsána privátním klíčem odesílatele
a potom šifrována veřejným klíčem příjemce.
Na straně příjemce je zpráva nejprve dešifrována privátním klíčem příjemce a teprve
potom je pomocí veřejného klíče odesilatele
ověřena identifikace.
Certifikační autorita a certifikáty
K čemu slouží certifikační autorita?
V předchozích řádcích jsme uváděli dvojici
klíčů. Jistě mi dáte za pravdu, že uchovávat
a zabezpečit klíče někdy bývá problematické. Nestačí se starat o svůj privátní klíč, je
nutno uchovávat veřejné klíče všech komunikujících účastníků a k nim jednoznačnou
identifikaci vlastníků těchto klíčů. V tomto
nám může pomoct právě certifikační autorita, která tyto služby poskytuje. Certifikační
autorita vystupuje při vzájemné komunikaci
dvou subjektů jako třetí důvěryhodný sub-
O
F
E
S
I
O
N
A
L
může snadno komunikovat s partnerem či
zákazníkem kdekoli na světě.
Zákon 3.: Cena obchodní transakce se bude
snižovat
Celý proces marketingu, objednávek, prodeje a zákaznického servisu může být využitím Internetu do značné míry automatizován
a tím mohou být zredukovány náklady spojené s obchodováním. Možnost nakupování po
Internetu také snižuje minimální „aktivační
energii“, kterou musí zákazník pro uzavření
obchodu vyvinout. I ten zákazník, který si raději půjde koupit zboží do obchodu, aby si jej
mohl fyzicky prohlédnout, použije Internet
pro výběr obchodu, zjištění parametrů zboží
a porovnání cen.
T
A
K
V
A
L
I
T
jekt, který prostřednictvím jím vydaného žeme kdykoliv ověřit se znalostí veřejného
certifikátu jednoznačně svazuje identifikaci klíče certifikační autority, respektive jejího
subjektu s jeho dvojicí klíčů,respektive s jeho certifikátu. Existence certifikační autority
digitálním podpisem. Tím pádem se certifi- také umožňuje důvěryhodnou komunikaci
kát stává elektronickým průkazem totožnos- i subjektů, jenž se navzájem fyzicky nikdy
ti. Certifikát obsahuje veřejný klíč, jméno nepotkaly nebo neabsolvovaly složitou proa další údaje zajišťující nezaměnitelnost sub- ceduru vzájemné důvěryhodné výměny svých
jektů. Obsahuje též datum počátku platnosti, klíčů. Další službou, kterou certifikační autodatum ukončení platnosti, jméno certifikač- rita poskytuje, je možnost zrušení certifikátu.
ní autority, která certifikát vydala, sériové Toto oceníme při ztrátě našeho privátního
číslo a některé další informace. Certifikační klíče. Každá certifikační autorita poskytuje
autorita zaručuje správnost jí vydaného cer- seznam odvolaných certifikátů a stvrzuje ho
tifikátu, odstraňuje nutnost smluvní důvě- svým podpisem.
ryhodné výměny klíčů mezi dvěma subjekty
Zdá se, že principy ochrany elektronických
navzájem a jejich dohoda spočívá pouze dat jsou propracovány a je možné se na ně
v domluvě o společně uznávané certifikační spolehnout. Tento článek měl přiblížit možautoritě. Důležité je, že utajovaná data na nosti, jak lze svá data chránit před možnými
straně klienta jsou redukována pouze na „vetřelci“. Je však důležité neopomenout
bezpečné uchovávání privátního klíče, pro- lidský faktor, který nám většinou přinese
tože ostatní je řešeno certifikáty. Ty si mů- nepředpokládané problémy.
Internet a cena informací
Informace zdarma?
I
Pokud je o takovýto software zájem, začne jej používat široká komunita uživatelů
a vývojářů, kteří budou odhalovat a odstraňovat chyby a bezpečnostní rizika, přidávat
další funkčnost a provádět úpravy podle
svých potřeb. A to vše díky Internetu paralelně a s rychlostí, která je nesrovnatelná
s tradičním modelem vývoje, kdy se vývoje
a testování účastní jen relativně malá skupina programátorů a testerů. Výsledkem má
být stabilní a ověřený software, založený na
otevřených standardech, nezávislý na monopolním výrobci. Příkladem, že tento způsob
vývoje funguje, je nejen Linux, ale i mnoho
dalších, v úvodu zmíněných projektů.
Open Source už není doménou jen
programátorských fandů, programujících
zdarma pro své potěšení a pro zvýšení
své prestiže nebo studentů, učících se na
zdrojovém kódu. Do vývoje OSS se častěji
zapojují firmy, které se z uživatelů stávají
vývojáři. Do Open Source také investují
značné částky velké technologické firmy
(IBM, Oracle, Dell, Computer Associates,
Intel, HP, Sun) a podle Olliance Consulting
Group tyto investice rostou každým rokem
o 35 %. Návratnost takovýchto investic je
rychlá – společnost IBM v roce 2002 uvedla, že miliarda dolarů investovaná do OSS
– především do podpory Linuxu a převodu
portfolia SW na Linux, se téměř celá vrátila
během jednoho roku.
OSS slaví úspěchy především v oblasti Internetu – má podíl více než 65% web serverů.
Například IBM založila na OSS a otevřených
standardech svá e-business řešení. Základem
IBM HTTP Serveru je Apache, IBM WebSphere Studio je založeno na open source nástroji
Eclipse. Stále více významných společností
zahrnuje OSS komponenty do své IT infrastruktury.
Tomáš Vahalík, [email protected]
Rizika OSS z pohledu uživatele
V poslední době stále více organizací zvažuJistě jste si všimli, že v poslední době lze na
je výhody používání OSS. Ovšem to, že za OSS
Internetu najít zdarma nejenom informace
nemusíte platit licenční poplatky, neznamená,
o počasí, vlakových spojích, programech kin či
že
nebudete mít náklady spojené s implerad pro zahrádkáře. Zdarma lze najít i takové
mentací a provozem.
informace, o kterých by se dalo předpokládat,
Pro uživatele je rozhodující, jak jsme si ukáže je to střežené firemní tajemství, „knowzali
dříve, právě podpora softwarového pro-how“ na kterém lze vydělávat a získávat
duktu. Nyní se sice objevuje stále více firem
konkurenční výhody. Zkuste například v Goposkytujících podporu OSS, problémem však
oglu (nebo jiném vyhledávači – samozřejmě
může být nedostatek zkušeností těchto firem
zdarma) vyhledat odkazy podle hesla „best
s podporou rozsáhlejších provozních aplikací
practices“ nebo „design patterns“.
založených
na OSS. Obdobné je to při hledání
Zdarma jsou nejen informace, ale i prograzaměstnanců. Je jednodušší najít zkušeného
my. A to ne ledajaké. Namátkou, od operačadministrátora např. Solarisu, než Linuxu.
ního systému (Linux), přes vývojové nástroje
Některé OSS produkty se osvědčily v rozsáh(Eclipse), databáze (MySQL), web server
lých podnikových systémech (Linux, Apache),
(Apache), kancelářský balík (Open Office)
jiné se však vyvinuly z menších aplikací. Napříaž po J2EE aplikační server (JBoss). Existuje Software jako služba
klad Open Source databáze za sebou nemají
tolik kategorií programů zdarma (někdy se
Software má mnoho ekonomických chadlouhodobé reference o použití v rozsáhlých
vzájemně překrývajících), že není úplně jed- rakteristik odlišných od fyzického zboží,
provozních systémech, což je z hlediska výběnoduché se v nich vyznat (Free Software, Pu- svým charakterem má blíže ke službě. Podle
ru databáze dost podstatná informace.
blic Domain, Copyleft, GPL’ed, Open Source, odhadů je až 95% kódu psáno pro speciFreeware ...).
fické prostředí firmy (ať už vlastními silami,
Budoucnost OSS
Jak je možné, že v době přechodu do věku přizpůsobováním komerčního SW produktu
informační společnosti, kdy by firmy mohly nebo nákupem softwaru vyvinutého na
Přes uvedená rizika lze očekávat, že se bude
na prodeji informací vydělávat, je stále čas- míru), proto znovupoužitelnost takovéhoobjevovat stále více řešení založených na OSS
tějším jevem, že informace i software jsou to kódu pro další prodej je relativně nízká.
a to především tam, kde licenční poplatky za
zdarma? Platí zde stále ještě zákony tržního Pouze 5% kódu je psáno pro software na
komerční produkty představují podstatnou
hospodářství?
část celkových nákladů.
“krabicový“ prodej. Navíc je obvyklé, že značOpen Source model však není vhodný
ná část nákladů životního cyklu projektu
pro
veškerý software. Najde uplatnění ve
se
týká
fáze
údržby,
tj.
technické
podpory,
Internet a tři zákony
vrstvě infrastruktury (operační systémy, korozšiřování a přizpůsobování měnícímu se
„kyber-ekonomiky“
munikační SW), méně často potom v oblasti
prostředí firmy. Podle Gartner Group je to
Odpověď na tyto otázky je nutné hledat typicky 30% ale často i více než 50%, podle
middleware (web servery, aplikační servery,
ve způsobu, jakým Internet ovlivňuje téměř ButlerBloor Computer Research je to dokondatabázové servery, vývojové nástroje), oblast
všechny oblasti našeho života, ekonomiku ce 66%. I když tato čísla nemusí být přesná,
aplikací na míru bude nadále doménou monevyjímaje. Internet zásadně usnadňuje pu- podstatné je, že značná část mzdy vývojářů
delu tradičního vývoje.
blikování, vyhledávání a přenášení informací je placena za práci, kterou není možné proZatímco příznivci Open Source vidí v souodkudkoli na světě. Proto bývá Internet ozna- dávat opakovaně, jako je tomu u krabicovéčasných miliardových investicích velkých firem
čován jako technologie, která nám otevírá ho softwaru.
do OSS potvrzení životaschopnosti OSS modeinformační věk, a je tím, čím byl vynález parlu, skeptici v tom spatřují začátek konce OSS,
Cena za software, kterou je zákazník ochoního stroje pro industriální věk. Internet ovliv- ten platit, je často více než užitnou hodnotou
neboť
podle nich komercializace způsobí, že
Jak vydělat na OSS
ňuje ceny na třech úrovních, proto se hovoří softwaru ovlivněna očekávanou kvalitou dalLze vydělávat na něčem, co je zdarma? OSS přestane přitahovat nadšené individuální
o třech zákonech „kyber-ekonomiky“:
ší podpory. Zákazník pravděpodobně nebude Každý produkt na trhu má zpravidla svůj vývojáře a bez široké komunity takovýchto
Zákon 1.: Cena informace se bude snižovat chtít koupit proprietární software od krachu- doplňkový produkt, přičemž oba tyto pro- nadšenců ztratí OSS podstatu své existence.
Tento zákon vychází z působení dvou faktorů: jícího dodavatele nebo od „ičáka“ programu- dukty se obvykle kupují společně. Například Otázka budoucnosti Open Source Softwaru
a) nízká cena publikování informací na jícího doma v obýváku, protože zde je další doplňkem k hardware je operační systém. tedy zůstává - otevřená.
Informace a software zdarma nejsou anoInternetu ve srovnání například s papí- podpora problematická.
Firmy se snaží snížit cenu svých doplňkových
rovými médii
Software se svým charakterem tedy více produktů až na nulu, aby stoupla poptávka málie, ale je to stále zřetelnější tendence
b) snaha firem upozornit na sebe nabídkou blíží službě, je to dlouhodobý vztah mezi do- po hlavním produktu. Netýká se to jen SW vývoje, která není v rozporu s tržními principy
některých užitečných informací či soft- davatelem a zákazníkem. Přechod od modelu, a HW, možná také znáte obchod s potravi- a se kterou bude nutné v nejbližších letech
waru zdarma
kdy se platí za kopii SW jako za kus zboží, nami, který nabízí zdarma dovoz nákupu počítat.
Díky kombinaci obou faktorů dochází k modelu, kdy dominantní je cena služby, podle telefonické objednávky.
Odkazy:
k tomu, že informací i softwaru zdarma je je jednou z odpovědí na otázku položenou
Existují tyto základní modely jak vydělat
Michel Bauwens: The Three Laws Of the Cyna Internetu stále větší množství. Informace v úvodu.
na OSS:
zdarma slouží firmám jako návnada, forma
• Příjmy pocházejí ze služeb – školení, kon- ber-economy,
marketingu. Bez toho, aniž by nabízely Open Source Software
zultací, technických podpor, nikoli z po- http://users.skynet.be/michel.bauwens/
některé užitečné informace zdarma, si jich
platků za licenci.
professional/articles/digitalrevolution/
Zvláštní kategorií softwaru zdarma je
na Internetu nikdo nevšimne, a dříve či poz- Open Source software (OSS). Na tomto pří• Příjmy ze SW nadstaveb, doplňků a spe- threelaws.htm
ději se objeví konkurence, která je nabízet kladě si ukážeme, že software zdarma může
cializovaných modulů k OSS, které jsou • Eric S. Raymond: The Magic Cauldron
zdarma bude. Problémem se naopak stává mít své ekonomické opodstatnění. Vznik noprodávány podle tradičního modelu.
schopnost orientovat se v množství informací vého modelu vývoje softwaru umožnil právě
• OSS zvýší prodej hlavního produktu, kte- http://catb.org/~esr/writings/cathedrala schopnost informace využít.
rým je hardware (například drivery pro bazaar/magic-cauldron/
Internet. Tento model spočívá v tom, že
Zákon o snižování ceny informace se uplat- jádro SW produktu je co nejdříve zveřejněgrafické karty nebo operační systém pro • Olliance Consulting Group: Open Source
ňuje i uvnitř organizací. Schopnost firmy no i se zdrojovými kódy a dáno uživatelům
Software Position Briefing
počítač).
uspět v konkurenci je závislá na sdílení zna- k dispozici zdarma s licencí, která umožňuje
• Prodej příslušenství k OSS - od hrníčků http://www.oss-institute.org/newspdf/
lostí mezi jejími zaměstnanci. Společnosti, je- volné kopírování a modifikaci zdrojového
a triček až po knihy a dokumentaci.
OSSIPosition011503.pdf
jichž zaměstnanci hlídají své „know-how“ pro kódu. Licence ale neumožňuje komerční
Výše uvedené možnosti, jak ekonomicky • Sanjay Murthi: Free and Clear?
udržení vlastní pozice, nemohou uspět.
zneužití – tedy prodej takovéhoto softwaru. získat na softwaru zdarma, nejsou jediný
Zákon 2.: Cena komunikace se bude sni- Umožňuje jej však zahrnovat do komerčních druh zisku. Dalším a možná ještě podstat- http://www.intelligententerprise.com/
žovat
aplikací, účtované poplatky ale nesmí zahr- nějším přínosem z volného poskytování 030405/606feat3_1.shtml
Již dnes znamená Internet globální komuni- novat tento software, pouze to, co k němu informací, je získání vlivu a dobrého jména
„experta“, což může být k nezaplacení.
kaci za lokální ceny. Každý obchodní subjekt prodejce přidá.
6
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
Vyplatí se vůbec testovat software?
Dan Petřivalský, [email protected]
Návratnost investic – ROI – Return on
Investment. To je obchodní zaklínadlo dnešní doby. Snad nikdo si dnes nedovolí udělat
jakoukoliv „jen trochu větší investici“ bez
důkladného propočtu její očekávané návratnosti. Nebudeme se zabývat definicí pojmu
„jen trochu větší investice“, její velikost
záleží na velikosti a finanční síle investora.
Příkladem „větší investice“ bývá podnikový
software. V případě investice do nového
podnikového informačního systému či jen
jeho nové verze si každý(!) klade otázky:
Je nutné jej pořizovat? Nestačí nám to co,
máme teď? Co bude stát? Vyplatí se?
Méně lidí si už položí otázky: Jak zajistím,
že dostaneme aplikaci v pořádku? Co se stane, když nový software bude mít podstatnou
chybu, na kterou se hned nepřijde? Nebo
otázku z nadpisu - Vyplatí se vůbec testovat
software?
Zda je únosné podstoupit riziko spojené
s používáním neotestované aplikace, je jedním úhlem pohledu na problém. Druhým je,
jakým způsobem testování provádět a zda
investovat do zefektivnění testovacího procesu.
Při vývoji rozsáhlých systémů se investoři často snaží ušetřit právě na testování.
Většinou spíše jeho okleštěním než zefektivněním. Podívejme se na věc z obou zmíněných úhlů:
ÚHEL PRVNÍ (ANO ČI NE?)
Asi nikdo neočekává, že účetní firma
o dvou zaměstnancích bude složitě testovat
svůj účetní software nebo textový editor.
Naopak málokdo by uvěřil tvrzení, že nějaká
banka spustí své internetové bankovnictví
bez jeho předchozích důkladných testů.
Na Carnegie Mellon University zjistili, že
opravit chybu před spuštěním živého provozu softwarové aplikace je 40x až 1 000x
levnější, něž když se na chybu přijde až
v produkčním prostředí.
Čím je systém pro jeho provozovatele
důležitější, čím častěji je inovován nebo čím
méně má jiných instalací, tím častěji bývá
uživatelem-zákazníkem testován.
Je obtížné stanovit jednoduchou matematickou formulku pro rozhodnutí zda testovat či ne, vlastní rozhodnutí je proto velmi
subjektivní. Investor si klade na misky vah
možná rizika a svůj odhad, zda je systém dostatečně důležitý, dostatečně často inovován
či dostatečně unikátní, aby mělo smysl jej
testovat. Rozhodování to nemusí být jednoduché, pravidlo však zní: „mám-li sebemenší
pochybnost, musím testovat“.
ÚHEL DRUHÝ (JAK A ČÍM?)
Pro podporu procesu testování existuje
celá řada softwarových nástrojů. Protože
jejich nasazení znamená investici do jejich
pořízení, vyškolení pracovníků a další náklady (dále jen ŘEŠENÍ), vyhodnocuje investor
návratnost svojí investice (ROI) do testovacího software.
Definujme návratnost investice v procentech jako zlomek:
ROI = (NQB/NC) x 100%, kde
NQB je čistý měřitelný přínos – rozdíl mezi
přínosem
dosaženým
prostřednictvím
ŘEŠENÍ ve srovnání se stávajícím (nebo alternativním) postupem. Hodnota NQB může
znamenat přímé úspory, zisk nebo nepřímé
náklady na činnosti, které by jinak musely
být prováděny. NQB lze stanovit zpětně či
odhadnout na několik let dopředu.
NC jsou čisté náklady - rozdíl mezi celkovými náklady na ŘEŠENÍ a náklady spojené
se stávajícím (nebo alternativním) postupem
(které nemusí být vůbec žádné).
ROI je poměr souhrnného čistého přínosu
k souhrnným čistým nákladům. Jestliže je
hodnota ROI vyšší než 100 %, pak se vložená investice ve vyhodnocovaném období
více než vrací. Jako poměrová veličina může
ROI sloužit nejen porovnání uvažovaného
ŘEŠENÍ se stávajícím stavem, ale i k porovnání dvou ŘEŠENÍ mezi sebou.
Případová studie velké americké
pojišťovny
Společnost IDC zpracovala analýzu ROI pro
ŘEŠENÍ společnosti Mercury Interactive, leadera na trhu testovacích produktů, kterou
KOMIX s.r.o. zastupuje.
Analyzovaná pojišťovna má zhruba 35 000
zaměstnanců, z toho asi 1 000 v IT. Před vypsáním výběrového řízení na ŘEŠENÍ využívala již zastaralou alternativu na mainframu.
Vítězné ŘEŠENÍ Mercury Interactive pokrývá
komplexní správu procesu testování, automatizované funkční testování a zátěžové
testování. ŘEŠENÍ bylo nejprve nasazeno
na nově implementovaný CRM systém. Bylo
vytvořeno 95 skriptů pro automatizované
testování, které jsou využívány k přetestování systému asi jednou za tři týdny, což je
interval, v jakém dochází ke změnám na
CRM aplikaci.
Se systémem pracuje více než 4 000 uživatelů, kterým je potřeba zajistit dostatečný
výkon aplikace.
Výpočet ROI pro funkční testování:
• NQB – Příprava testů bez ŘEŠENÍ a s ním
se ukázala jako rovnocenná. Úspora (za práci manuálních testerů) při automatizovaném
provádění testů však byla vyčíslena na 71 825
USD ročně. Úspora nákladů za pronájem 18
stolních počítačů pro použití při manuálním
testování činí 7 560 USD za rok. Celkový roční čistý přínos projektu je 79 385 USD.
• NC – Náklady na licence a školení činí
25 000 USD.
• ROI = 79 385 USD / 25 000 USD x 100% =
= 317,54% v jednom roce.
Více než trojnásobná návratnost vložených prostředků během jediného roku je
jistě důvod ke spokojenosti všech účastníků
projektu. Samotné návratnosti investice bylo
dosaženo za méně než půl roku.
Výpočet ROI pro zátěžové testování:
• NQB – zvýšení výkonnosti aplikace a tím
i produktivity práce byl jediný přínos, pro
který byl vyhodnocován ekonomický užitek
(nepokoušíme se určit obchodní hodnotu
silnějšího konkurenčního postavení nebo zabránění ztráty obchodů způsobené špatnou
výkonností aplikace). Čistý přínos za tříleté
období přesáhl 825 000 USD.
• NC – Náklady na licence, technickou podporu, konzultace a školení dosáhly 670 000
USD během tří let.
• ROI = 825 000 USD/670 000 USD x 100% =
= 123,13% za tři roky.
Investice vložená do zátěžového testování
se vrátila za dobu kratší tří let, což je považováno za dobrou investici. V porovnání
s funkčním testováním je to třetinová
návratnost za trojnásobné období, což
nepůsobí tak impozantně. Je však nutné
brát v potaz, že velkou část nákladů tvořila
počáteční cena licencí a množství nutných
konzultačních služeb je rok od roku nižší.
ROI vyhodnocované za 4. a 5. rok již budou
vypadat mnohem lépe.
Závěrem lze říci, že investice do ŘEŠENÍ
Mercury Interactive se mohou vracet velmi
rychle, stačí si zvolit vhodnou konfiguraci
(s tím vám v KOMIXu rádi pomůžeme) a příznivé výsledky se objeví už v prvním roce
používání.
Rozhovor s Ing. Petrem Srdínkem o průběhu
projektu pro GE Capital Multiservis
Účastníci: Petr Srdínko za GE Capital Multiservis,
Dan Petřivalský a Vlasta Vršecký za KOMIX
Společnost KOMIX ve spolupráci se společností LBMS realizovala v GE Capital
Multiservis v průběhu roku 2002 a 2003 projekt „Systém pro podporu vývojového cyklu
software“, který měl 4 etapy:
1. Evidence požadavků
2. Testování
3. Analýza, datové a funkční modelování
4. Konfigurační řízení
Společnost KOMIX byla dodavatelem etapy „Testování“, která zahrnovala vytvoření
metodiky a zavedení specializovaných SW
nástrojů na podporu a automatizaci fáze
testování. Zeptali jsme se interního sponzora tohoto projektu v GE Capital Multiservis
Petra Srdínka jak vidí průběh projektu a jeho výsledky s odstupem tří měsíců po jeho
ukončení.
Jaký byl prvotní impuls v GE Capital
Multiservis pro rozhodnutí o realizaci projektu „Systém pro podporu vývojového cyklu SW“ a z jaké úrovně vzešel (management,
testeři, vývoj)?
Prvotní impulsy k řešení těchto problémů
se u nás datují již od roku 2000 až 2001, přičemž hlavními iniciátory hledání vhodného
řešení byli především zaměstnanci z řad vývojářů a analytiků. Společně s managementem se následně došlo k rozhodnutí řešit
tento problém komplexně: řešit ho nejenom
pro fázi analýzy a testování, ale i pro fázi vývoje, včetně konfiguračního řízení. Závěrem
našich úvah bylo vypsání výběrového řízení,
ke kterému došlo v březnu 2002. Výběrové
řízení na tento projekt trvalo více než 3 měsíce a během něj jsme oslovili větší počet
partnerů. Jeho výsledkem byl výběr dvou
dodavatelů projektu – společnosti KOMIX
pro část testování a společnosti LBMS pro
ostatní části vývoje a pro řízení projektu
jako takového.
To znamená, že už původní koncepce byla
komplexní? Nebo jste ze začátku zvažovali
třeba jen některou z etap a zbytek se doplnil postupně?
Musím říci, že již od počátku byl náš
záměr komplexní. Nechtěli jsme řešit tuto
problematiku po částech, zavádět odděleně
jednotlivé části metodiky a postupně vybírat
podpůrné nástroje a řešit jejich návaznost
a případné problémy až ve chvíli, kdy už
některé máme nasazené. Od začátku existovala myšlenka pojmout řešení problému
komplexně a dnes jsem přesvědčen, že to
byl správný přístup.
Vybrané řešení se skládá z produktů několika výrobců. Neuvažovali jste o nasazení
uceleného řešení od jednoho výrobce?
Nikdo na našem trhu, alespoň jsme nikoho
takového nenašli, nenabízí řešení, které by
bylo jasnou jedničkou, a přitom pokrývalo
vše co jsme v rámci výběrového řízení poptávali a mělo reference v České republice.
[email protected]; [email protected]
V průběhu výběrového řízení se ukázalo, že
existují firmy, které nabízejí ucelená řešení
od začátku až do konce, od jednoho výrobce,
ale že tato ucelená řešení mají své poměrně
výrazné slabé stránky. Nakonec jsme se rozhodli pro kombinaci, která vypadala složitě,
nicméně ve světle konečných výsledků tohoto projektu to bylo správné rozhodnutí.
Od začátku jsme důrazně uplatňovali požadavek, aby nástroje od různých výrobců
spolu komunikovaly, aby to nebylo pomocí
rozhraní vyvinutého pouze pro naše potřeby,
ale aby šlo o rozhraní ověřené v rámci dřívějších instalací. Samozřejmě, že se vyskytly
problémy, ale všechny se podařilo vyřešit
a jsme rádi, že jsme se rozhodli pro „Best-ofBreed“ řešení.
Jaké bylo vaše očekávání přínosů tohoto
projektu pro GE Capital?
Tušili jsme, co by nám projekt asi měl
přinést, byly to však spíš odhady či přání.
S odstupem mohu říci, že naše očekávání
byla z části reálná, z části méně reálná. Jak
sám název projektu napovídá, jde o systém
pro podporu celého vývojového cyklu SW.
Proto jsme hledali komplexní metodiku
a nástroje, které od vzniku požadavku až
po jeho nasazení do živého provozu podpoří jeho vývoj i případné pozdější úpravy
a opravy. Takže očekávání se dají shrnout
do dvou částí – komplexní metodika a vzájemně propojené nástroje. Kromě toho jsme
samozřejmě očekávali v dlouhodobějším horizontu zvýšení efektivity vývoje, postupné
snížení pracnosti vývoje a snížení počtu chyb
a z toho plynoucí ekonomické přínosy.
Vzhledem k tomu, že už uplynuly tři měsíce od ukončení projektu, můžeme se tedy
ohlédnout na realizaci projektu s určitým
odstupem. Jak se podle vašeho názoru zdařilo provázání čtyř fází toho projektu.
Řekl bych, že provázání a synchronizace
čtyř fází projektu bylo určitě jednou z nejtěžších věcí vůbec, a to z několika důvodů.
Projekt se realizoval za normálního provozu
a bez přerušení jiných projektů a implementace nových požadavků, takže docházelo k poměrně velkým problémům na naší
straně, z důvodů nedostatku našich personálních kapacit. Dalším problémem bylo,
že jednotlivé etapy projektu musely jít za
sebou v určitém logickém sledu. Těžko jsme
mohli začínat například etapou datového
a funkčního modelování, když se nevědělo
nic o řešení evidence požadavků. Takže jsme
se spolehli na zkušenosti dodavatelů. Myslím
si, že se nám to vyplatilo, protože časování
jednotlivých etap, jejich vzájemné překrývání nebo souběžný běh bylo naplánováno jak
to nejlépe šlo. Návaznost jednotlivých fází
vyplývala z logiky vývojového cyklu a výstupy jedné etapy byly často vstupem do etapy
další. Nebyla to věc jednoduchá, nicméně
nakonec se povedla.
7
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
Nyní bych se rád zaměřil speciálně na ob- dne tuto metodiku v základech nastudovat
last metodiky testování. Jaký je váš zpětný a používat na projektu. Pak se k ní může
pohled na průběh projektu v této etapě? vrátit v případě potřeby a podívat se, co by
Jak jste to vnímal vy a jaké jsou ohlasy měl třeba ve fázi jednotlivých testů udělat, co
od lidí např. z vývojových týmů, na které nesmí zapomenout. Právě proto si myslím, že
byl, zejména v období konce roku, vyvíjen byla nastavena rozumná míra konkrétnosti
ohromný tlak?
a že metodika nesklouzla do zbytečně poCelá fáze testování byla v projektovém drobných pracovních postupů.
plánu rozložena do poměrně časově dlouhého období, a přestože se mi tento čas
Jedna věc je metodika, druhou věcí je,
zdál na začátku zbytečně dlouhý, nakonec jakými nástroji je tato metodika podpořena.
to byla doba, za kterou se etapa dala v od- Rád bych se zeptal na vaše tříměsíční zkušepovídající kvalitě stihnout, a to jak ze strany nosti s TestDirectorem a WinRunnerem?
dodavatele, tak i ze strany nás jako odběraJá bych tuto odpověď rozdělil do dvou
tele. Bylo to hodně časově náročné napří- částí, protože jinak je to s TestDirectorem
klad i v oblasti vyškolení našich lidí. Projekt a trochu jinak s WinRunnerem, i když jde
probíhal v době, kdy v GE Capital Multiservis o členy jedné rodiny a jednoho výrobce.
vrcholí obraty a kdy byly kladeny mimořád- TestDirector je produkt, který se vlastně
né požadavky na provoz systému a provoz „chytil“ sám od sebe. Je to zejména díky
tak měl samozřejmě před projektem prio- tomu, jak jednoduché a srozumitelné je jeho
ritu. Nakonec se projekt a zajištění provozu ovládání, jak má propracovanou funkčnost
systémů povedlo sladit. Vše se podařilo zre- a ještě z řady dalších důvodů. V podstatě
alizovat tak, že metodika testování prošla se TestDirector stal velmi rychle populárním
dvěma nebo třemi koly připomínkování, což nástrojem pro řízení a správu testů a dnes
se ukázalo jako velmi důležité a užitečné, už ho u nás používá řada týmů. Neměli jsme
a potom v návaznosti na implementaci me- jediný problém s tím, že by ho lidé kvůli vrotodiky jsme nasazovali testovací nástroje. zené nechuti k novým nástrojům používat
Trochu specifické bylo, že se začínalo na ze- nechtěli. Naopak TestDirector vhodně zapllené louce. Znamená to, že tu nebyly, až na nil bílé místo na naší IT mapě a dnes je s ním
jednu výjimku, žádné nástroje, které by tes- velká spokojenost jak ze strany testerů, tak
tování nebo jeho automatizaci podporovaly. ze strany ostatních pracovníků firmy mimo
To vše přispělo k tomu, že jsme testovací IT, kteří jej také používají. Na zaučení člověnástroje i metodiku v daném časovém plánu ka pro práci s TestDirectorem, s přihlédnustihli nasadit a že metodika odpovídá našim tím k existenci metodiky testování, je dnes
požadavkům.
potřeba poměrně krátká doba a není nutné
žádné drahé školení, takže TestDirector bych
Myslíte, že vytvořená metodika testování klasifikoval výbornou.
byla dostatečně obecná a na druhou stranu
U WinRunneru věřím, že jeho hodnocení
i dostatečně konkrétní?
bude podobné, ale ještě nejsme dost daleko
Dle mého názoru byla rovnováha mezi od ukončení projektu, protože WinRunner
obecností a konkrétností nastavena na správ- je spíše investice do budoucnosti. Je to z tonou úroveň. My jsme před zahájením projek- ho důvodu, že než se systémy, které mají
tu měli jen neúplná a nejednotná pravidla po- být automaticky testované WinRunnerem
krývající pouze část fáze testování, takže i to, „načtou“, tak to nějakou dobu trvá. Dnes už
že najednou všichni ve vývojových týmech jeden z našich hlavních systémů máme přimají postupovat podle jednotné a komplex- praven k automatizovaným testům a teprve
ní písemné metodiky pro nás byla poměrně za čas dokážeme vyhodnotit přínosy a zenová věc. Myslím si, že vytvořená metodika jména ušetřený čas při provádění automatitestování není něco, co by se dalo nastudovat zovaných testů.
za dvě hodiny, ale není ani nikterak složitá.
TestDirector je tedy už dnes hodnocen
Myslím si, že člověk dokáže během jednoho jako věc, která se rozhodně povedla, myslím
O
F
E
S
I
O
N
A
L
si, že WinRunner, pokud ho budeme důsledně a vhodně používat, jej bude následovat.
Rád bych se ještě zeptal, jestli tento
projekt měl nějaké negativní dopady na
vývojové projekty, například zda se zvýšila
administrativa, náklady na projekt atd.?
Neřekl bych přímo negativní dopady na
projekty, které běžely v průběhu projektu
a ani na projekty, které vlastně dnes víceméně už přes implementované nástroje
procházejí, spíš to byly logické dopady
a změny jako u ostatních projektů tohoto
typu. Zmínil jste zvýšenou administrativu.
Samozřejmě se objevila zvýšená administrativa nebo spíše pracnost, která je ale nutnou
součástí práce při prvním zvládnutí práce
s TestDirectorem a nutností zadat do něj testovací scénáře a skripty. Načtení aplikace do
WinRunneru by se také dala definovat jako
zvýšená administrativa, ale bez těchto kroků
nelze postoupit dál. Zcela určitě nám ubylo
papírování. Dnes máme všechno ve stejných
nástrojích, na jednom místě a hlavně, což
je velký přínos, tři týmy a systémy, jichž se
zavedení nástrojů týkalo, teď používají jednotnou metodiku, což nikdy předtím nebylo.
Takže negativní dopady bych neviděl, byly to
spíše logické dopady vzhledem k zaměření
a velikosti projektu.
Jak byste zhodnotil v krátkém období tří
měsíců od konce projektu klíčové přínosy
zavedení metodiky testování? Mohli bychom se na to podívat ze dvou pohledů, a to
z pohledu lidí z vývojových týmů a z pohledu manažera?
Z pohledu lidí, kteří testují a mají testování jako svou většinovou pracovní náplň, jsem
už některé výhody zmínil. Jednou z výhod
je, že metodika umožňuje podívat se, jak
postupovat v určitých fázích projektu a případně s kým spolupracovat atd. Druhá výhoda je jednotné úložiště, ať už testovacích
skriptů, testovacích sad a scénářů v jednom
společném nástroji. Třetí výhodou je, že téměř po celou dobu trvání projektu lidé vědí,
v jaké fázi je testování, co už otestováno
bylo a co ještě ne. Tam, kde testování proběhlo, vědí jak dopadlo, jaké jsou výsledky
testování. Tady již přecházím k výhodám ze
Testování změněného softwaru
Změnové řízení – rámec pro
testování změněného softwaru
Ve firmě střední velikosti mohou v závislosti na jejím zaměření vznikat stovky požadavků na změny ročně. Problémy s jejich
vyřešením mohou nabývat hrozivých rozměrů, například v okamžiku větší provázanosti
a složitosti více požadavků.
Vyšší četnost výskytu požadavků na změny,
jejich rozsah a vzájemné působení ovlivňuje
existenci podnikového řízení změn a ovlivňuje také jeho formu. Zpravidla je zabudováno do podnikových procesů a alespoň
v elementární míře podporováno informačním systémem.
Proces podnikového řízení změn předpokládá, že má-li kdokoliv v podniku potřebu
něco změnit, vyřešit nebo vylepšit, podá
požadavek na změnu. Za požadavek lze
považovat i rozhodnutí managementu, neboť způsob jeho řešení se podstatně blíží
způsobu řešení „klasického“ požadavku.
Požadavek na změnu může dokonce podat
i zákazník podniku. Změna se může týkat
kterékoliv podnikové sféry: vytvářených
produktů, vnitropodnikových procesů, organizační struktury atd.
Dnešní podniky zcela jistě využívají podpůrné prostředky IT, proto je nedílnou součástí podnikového řízení změn také řízení
změn softwaru. Za jeho dílčí ale významnou
složku je považováno testování změněného
softwaru. Jeho úkolem je podpořit změnové
řízení v oblasti verifikace a validace prováděné softwarové změny a následně v rozhodování o nasazení změněného programového
8
vybavení do provozu. Jinými slovy testování
softwaru po úpravách zajišťuje, aby do živého, provozního prostředí byly nasazovány
pouze takové verze programového vybavení, které jsou přezkoušeny a u kterých byla
míra chybovosti minimalizována.
Význam testování softwaru
po úpravě
Testování je integrální součástí řízení změn
softwaru. Bez respektování jeho důležitosti,
bez jeho existence v podniku, bez využití
jeho přínosů pro správnost aplikací výrazně
klesá efektivita a výkonnost řešení změn.
������
���������
������������
���������
���������
�������������������
����������
�����������
�������������
������������
���������������
���������
�����
���������������������
���������������
�������������
������������
���������
���������
������������������
������������������
�������������
�����������������
�������������������
�������������
�����������������
�����
����������������������������
Obr. 1 – Vazba změnového řízení a testování změněného softwaru
I
T
A
K
V
A
L
I
T
strany vedoucích nebo manažerů. Přehled
o testování získáte v rámci jednoduchého
vyhotovení jednoho nebo dvou standardních reportů, na což stačí pět minut, místo
toho aby se někdo musel věnovat tomu, že
by pravidelně reportoval v různých systémech, v jakém stavu je testování, kolik je
chyb, jak jsou řešeny a co ještě opraveno
není. Další výhoda je stejně tak jednotná
evidence chyb a v podstatě on-line přehled
o tom, kolik chyb bylo opraveno, kolik chyb
se třeba objevilo znovu a v jaké fázi jsou
opravy jednotlivých chyb.
Jak jsou s TestDirectorem a WinRunnerem
spokojeni vlastní uživatelé, jaké jsou jejich
názory? Do jaké míry by jim vadilo vrátit se
do stavu před nástroji?
Z pohledu IT lidí, kteří s těmito nástroji
pracují, jsme na podobné téma měli již několik diskusí a nikdo z nich si už asi nedokáže představit, že by se zase znovu testovací
skripty nebo data uchovávala v Excelu nebo
v Accessu a někdo by se o ně musel složitě
starat. Myslím si, že když člověk pozná, že
v těchto nástrojích je ukryto opravdu velké
množství know-how a zkušeností lidí z vývojových týmů z celého světa, nemá důvod
vracet se zpátky k původnímu stavu.
Mohl byste na závěr shrnout situaci, která
byla před začátkem tohoto projektu a nyní?
Jsem rád, že jsme se do tohoto projektu po
delším uvažování pustili a prozatím nelituji
ani peněz ani času, který jsme do projektu
investovali. Myslím si, že všem, kteří dnes
testují ručně nebo napůl ručně a nemají popsán jednotný postup a pravidla testování,
mohu z vlastní zkušenosti doporučit, aby se
do toho pustili. Bez tohoto kroku se nedá
v oblasti vývoje větších systémů rozumně
konkurovat, aniž by celkový vývoj a zejména
testování nových aplikací nebo funkčností
nebyl opakovaně příliš drahý, dlouhotrvající
a celkově nepříliš efektivní.
Děkuji za rozhovor.
Sebastian Petrů, [email protected]
V případě zanedbání této oblasti si zahráváme s důvěrou uživatelů, vznikají bezpečnostní incidenty, protahuje se plné a funkční
nasazení změněného softwarového řešení.
Velmi závažným důsledkem jsou zvyšující
se náklady provozu a údržby programového
vybavení.
Testování softwaru je důležité vždy. Hlavním důvodem, proč tento článek zdůrazňuje
testování po úpravách, spočívá v pravděpodobnosti zavlečení chyby. Pokud analytik ve
spolupráci s programátorem vytvářejí nový
software či programový modul, je pravděpodobnost, že udělají chybu, 3x až 10x menší
než při úpravě již existujícího programového
vybavení.
Význam testování změněného softwaru
roste v případě, že v podniku funguje více
provázaných softwarových systémů. Růst
počtu systémů a růst počtu vazeb mezi nimi
klade zvýšené nároky na řešení změn promítajících se z jednoho systému do dalších.
Způsob technické realizace vazeb je další
faktor, který může vést k nárůstu obtížnosti
řešení změn. Lokalizace a odstranění chyby
dotýkající se dvou nebo více integrovaných
systémů bývá komplikované, integrační
testy jako součást komplexního otestování
nové verze softwaru se zapracovanou změnou (v tomto případě změnou dvou či více
systémů) zajišťují kontrolu funkčnosti propojení těchto systémů s ohledem na řešenou
změnu.
A
Z
N
A
L
O
S
T
Z
K
U
Nástroje podporující testování
změněného softwaru
E
N
O
S
T
P
R
Možné důsledky zavlečení chyby
Fungování celého procesu změnového
řízení, jakož i jeho části – testování změněného programového vybavení, je závislé na
softwarové podpoře. Zatímco změnové řízení malých systémů je evidenčně uchopitelné
i „papírově“, testování a jeho organizace
u větších systémů nejsou takovým způsobem
efektivně zvládnutelné.
Nástrojů podporujících testování je celá
řada. Každý podnik by měl při volbě takového nástroje uvažovat, nakolik se mu vyplatí investice do něj. Vysoce specializované
testovací nástroje jsou drahé, někdy může
stačit jednodušší evidence. Možnosti, ze kterých mohou manažeři volit, jsou následující:
1. Základní podpora spočívá v jednoduché
evidenci průběhu testování. Nástroje na
této úrovni jsou poměrně levné a často
je již podnik využívá k jiným účelům
(např. MS Excel nebo MS Access). Jejich
používání poskytuje základní orientaci
o změnách a průběhu testování verzí
softwaru, které tyto změny řeší.
2. Na vyšší úrovni se setkáváme se specializovanými testovacími nástroji (např.
TestDirector), které vytvářejí podmínky
pro plánování a evidenci testů, evidenci
jejich výsledků, případně i evidenci neshod a sledování postupu jejich řešení.
Rozdíl proti základní podpoře spočívá
v tom, že tyto specializované nástroje
mají implementovánu metodiku testování a dodržování předepsaných postupů do značné míry vynucují. Nasazení
nástrojů pokrývajících tuto úroveň
zvyšuje kvalitu organizace samotného
testování a zvětšuje míru znovupoužitelnosti jednou připravených testovacích případů.
3. Nástroje na nejvyšší úrovni již podporují
nejenom organizaci testování, ale testování samotné. Dovolují uživateli nejen
připravovat, ale i provádět testovací případy. Platí to jak pro manuální testy, kdy
uživatele vedou krok za krokem podle
připraveného testovacího případu, tak
pro automatizované testy. Příkladem
takových nástrojů je TestDirector, v případě realizace automatizovaného testování propojený s WinRunnerem.
Jednotlivé úrovně podpory softwarovými
nástroji shrnuje obrázek 2.
���������
Š
Způsob otestování změny velmi ovlivňuje skutečnost, do jaké části aplikace
míří. Působí-li změna z hlediska možných
důsledků chyby na kritickou část aplikace,
měla by se testovat celá aplikace. Při změně
dopadající do nekritické části aplikace stačí
otestovat pouze změnou ovlivněnou část
a její blízké okolí.
S výhodou, významnou zejména u kritických změn, je možné využít trasovatelnost
projektových výstupů. Jsou-li známy vazby
mezi částmi aplikace, není problém dohledat místa, kam všude se změna promítne
a co všechno ovlivní, což umožňuje omezit
rozsah prováděných testů a tím výrazně snížit náklady.
Kategorizace změn z hlediska rychlosti jejich implementace
Řešení chyb (jako typu změny) vyžaduje
trochu odlišný přístup než zavádění nové
funkčnosti. Kritické chyby (havárie) se vyznačují tím, že musí být rychle odstraněny.
Požadavek na rychlost bývá v rozporu s požadavkem na úplnou verifikaci a validaci
opravy. Důsledkem tohoto rozporu a důsledkem faktu, že negativní důsledky zavlečení
další chyby při neúplném otestování budou
pravděpodobně menší než trvání havarijního stavu, je oprava havárie „záplatou“ a až
následná kompletní verifikace a validace.
Nasazování nové funkčnosti a realizace
oprav nekritických chyb je úplně jiný případ. Implementaci do provozního prostředí
předchází kompletní verifikace a validace
a k nasazení dochází až po minimalizaci
míry chybovosti.
Úroveň podpory týmové spolupráce
Volba vhodného nástroje, který podporuje
sdílení potřebných informací a řízení testování, umožňuje prostorovou diverzifikaci,
např. mezi členy vývojového a testovacího
týmu.
Volba automatizovaného testování
a jeho poměr k manuálním testům
Automatizované testování je svým charakterem náročné na přípravu a vyplatí se v případech častějšího opakování – pro aplikace
��������������������������������������
�����������������������������������
�������������������������������
�����������������������������������������
��������������������
��������������������������
��������������������������������������
�������������������������������������
���������������
�������������������������������
���������������������������������
��������
Obr. 2 – Úrovně aplikační podpory testování
Výsledná podoba testování
změněného software v podniku
Závěrečná podoba podnikového testování
změn softwaru závisí na mnoha faktorech.
Následující výčet představuje faktory, které
z pohledu různých podniků mohou mít pro
výslednou podobu odlišnou důležitost.
Softwarová infrastruktura podniku
Počet, rozsah a provázanost programového vybavení, ale i četnosti změn ovlivňují
množství testů, které musí být řízeny a realizovány.
vytvářené přírůstkovým způsobem (který
vede k opakovanému testování stejných částí aplikace), případně pro kontrolu velkého
množství dat.
Na rozdíl od manuálních testů, jejichž
opakování je vždy časově stejně náročné,
je testování prostřednictvím spouštění automatizovaných testů výrazně úspornější.
Nevýhodou automatizovaných testů je složitější příprava. Z tohoto důvodu je nutné
uvážit, pro jaké aplikace zvolit manuální
a pro jaké automatizované testování.
Poměr manuálních a automatizovaných
testů ovlivňuje nejen rychlost verifikace
a validace změněného softwaru, ale i volbu
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
nástroje pro podporu testování změněného
softwaru (viz obrázek 2).
Dopad do uživatelské důvěryhodnosti
Možnosti zásahů do okolních procesů a existující organizační struktury
Závažným faktorem, který ovlivňuje
výslednou podobu testování softwaru po
úpravách a kterým se musí manažeři zabývat, je ohrožení důvěryhodnosti měněného
systému pro uživatele. Projeví-li se kritická
chyba až za provozu a práce uživatelů je
nepříjemnější či v horším případě úplně znemožněná, může vlna odporu proti chybové
aplikaci ztížit její rozvoj či rozšiřování do
dalších částí podniku.
Tento faktor ovlivňují odpovědi na následující otázky: Vychází se při tvorbě systému
testování změněného softwaru z existujícího změnového řízení nebo zatím neexistuje
jednotná koncepce? Lze vázat na okolní
procesy a je možné je alespoň částečně přizpůsobit? Je stávající organizační struktura
pevná nebo mohou tvůrci systému navrhovat její změny?
Firemní kultura, zvyklosti a standardy
S ohledem na kvalitu firemních standardů
nelze nezmínit skutečnost, že zavádění standardu ISO 9001 nezbytně povede také k implementaci testování změněného softwaru.
Závěr
Testování změněného softwaru neexistuje
samo o sobě, ale zapadá do celkového rámce změnového řízení. Článek se nezabývá
popisem jednotlivých činností testování softwaru po úpravách. Cílem je spíše upozornit
na význam a ukázat na možné faktory, které
zpravidla ovlivňují jeho podobu.
Jak „doběhnout“
databázový server
Petr Sobotka, [email protected]
Jeden praktický příklad toho, proč
si dávat pozor na čistotu návrhu databázových schémat
Před nedávnem jsem řešil zajímavý problém: Uživatel hlásil, že se aplikace při
vyhledávání klientů v databázi podle jím
zadaných kritérií „zasekne“ a po jisté době
nahlásí chybu, že požadavek nebyl vyřešen
do vypršení nastaveného časového limitu.
Aplikace umožňuje vyhledávání v množině
klientů podle různých hledisek a uživatel
v tomto případě zadal příjmení, město a PSČ.
A skutečně - při vložení uvedené kombinace
kritérií se aplikace nechtěla hnout z místa.
Provedl jsem ještě několik pokusů a zjistil, že
pokud se pro vyhledávání zadalo pouze příjmení a město nebo příjmení a PSČ, výsledky
se objevily během okamžiku. Uživatel se,
nutno přiznat na první pohled logicky, divil,
proč tomu tak je. Vždyť zadáním více kritérií
se přesněji určí množina dat, kterou je třeba
prohledávat, a celý dotaz by proto měl být
rychleji zpracován.
Pro pochopení důvodu takového chování,
bylo potřeba prozkoumat plán zpracování dotazu, který zvolil databázový server
při vyhodnocování dotazu. Nejprve však
naznačme, jak jsou uložena data v těch tabulkách aplikace, které souvisí s uvedeným
problémem:
• tabulka klientů, která obsahuje mj. příjmení klienta,
• tabulka adres, ve které jsou uloženy ulice,
město a PSČ,
• vazební tabulka, která spojuje předchozí
dvě a realizuje vazbu M:N mezi klienty
a adresami.
Jak tedy vypadal plán zpracování pro dotaz, ve kterém bylo zadáno pouze příjmení
a PSČ? Databázový server vzhledem k četnosti zastoupení údajů v tabulce a konkrétním zadaným hodnotám vyhledávacích kritérií správně vyhodnotil, že z tabulky klientů
podle zadaného příjmení bude vybrán velmi
malý počet řádků, podstatně menší než
z tabulky adres. Začal proto výběrem dat
z tabulky klientů a k nim připojoval dohledáváním podle indexu zbylé dvě tabulky.
Ve druhém případě, kdy byla zadána
všechna tři kritéria, tj. příjmení, město i PSČ,
se ovšem databázový server rozhodoval jinak. Protože byla nad tabulkou adres zadána dvě kritéria, usoudil, že jejich kombinace
bude definovat množinu dat ještě menší,
než při hledání podle příjmení v tabulce klientů a začal proto jako první vybírat řádky
z tabulky adres. A zde je právě kámen úrazu.
Uvedené chování by naprosto vyhovovalo
v případě, kdyby hodnoty v jednotlivých
sloupcích tabulky adres, podle kterých se
vyhledávalo, byly na sobě navzájem nezávislé. Potom by za předpokladu rovnoměrné
distribuce hodnot v tabulce skutečně platilo, že pokud se použijí obě kritéria, bude
s velkou pravděpodobností výsledkem velmi
malá množina vyhovujících řádků. V našem
případě ovšem hodnoty město a PSČ jsou
vzájemně závislé – k jednomu městu vždy
patří jedno či více PSČ. Tudíž použití obou
vyhledávacích kritérií nijak neomezilo množinu dat oproti situaci, kdy nebylo zadáno
město, a volba tabulky adres jako výchozí
byla proto zcela nevhodná.
Databázový server v době, kdy počítá
statistiku nad tabulkami, nijak nezjišťuje,
zda mezi hodnotami jednotlivých sloupců
existují nějaké závislosti. Nelze ho proto
vinit z chybného chování při vytváření plánu zpracování pro náš problémový dotaz.
Naopak – pokud zavzpomínáme na teorii
relačního uložení dat, měli bychom si uvědomit, že uvedené uložení nevyhovuje tzv.
normálním formám databázových relací.
Normální formy relačního schématu definují
taková pravidla pro uložení dat, která zabraňují problémovým situacím (např. redundanci dat ap.). Pro náš případ je relevantní
tzv. Boyce-Coddova normální forma (BCNF),
která je splněna, pokud „pro každou závislost X à Y platí, že X obsahuje klíč tabulky“.
Její aplikací dojdeme k závěru, že uvedené
údaje, ulice, město a PSČ, nelze uchovávat
pohromadě v jedné tabulce. Problém je, že
tabulka může jako klíč použít dvojice {ulice, město} nebo {ulice, PSČ}, ale zároveň
existuje závislost PSČ à město. To odporuje
BCNF, protože PSČ samo o sobě není klíčem
tabulky. Správné uložení údajů by bylo do
dvou tabulek, z nichž jedna by obsahovala
sloupce PSČ a město a druhá ulici a PSČ. Díky
tomu bychom snížili redundanci dat a také
bychom mohli nezávisle ukládat vazbu mezi
PSČ a městem, která samozřejmě může existovat i bez záznamu o konkrétní ulici.
Pokud bychom provedli uvedené oddělení
dat do dvou tabulek, databázový server by
z definice první tabulky věděl o závislosti
mezi údaji PSČ a město a lépe by se mohl
rozhodovat při vytváření plánu zpracování
dotazu.
Vzhledem ke konkrétní povaze zdroje dat
pro aplikaci bylo v našem případě téměř nemožné provést uvedené rozdělení tabulek.
Rozhodli jsme se proto posunout řešení do
aplikační úrovně a uživateli vůbec neumožnit současné zadání města i PSČ coby vyhledávacích kritérií.
9
A
Z
N
A
L
O
S
T
Z
K
U
Š
E
N
O
S
T
P
R
O
F
E
S
I
O
N
A
L
I
T
A
K
V
A
L
I
T
Křížovka
Tomáš Vahalík, [email protected]
Návod:
Při luštění tajenky počítejte, kolikrát použijete nápovědu. Za každé použití nápovědy si zapište jeden bod. Na konci Vás čeká vyhodnocení. Pozor, v nápovědě naleznete skutečně pouze
nápovědu ukazující přibližný směr dalšího hledání, nikoliv samotné řešení (obdobně jako při použití nápovědy k většině programů). Díky tomu Vám nic nezkazí radost z toho, že problém
dokážete vyřešit samostatně.
Tajenka: Jeden z největších vynálezců přelomu 19. a 20. století
A
B
C
D
E
F
G
1
2
3
Legenda:
Vodorovně:
1. • 2. díl tajenky •• Iniciály klasika vědeckého materialismu, anebo iniciály autora románu o rudém gentlemanovi, anebo iniciály dětského románového hrdiny,
který vyrostl v lese.
2. • To, k čemu se snadno dostane zvěř v krmelci, k tomu se mnohem obtížněji
dostane Váš dávkový proces na serveru. •• Rezavý produkt vyráběný ze zeleného
zlata, přesto u zákazníků velmi oblíbený, a to díky tradici a kvalitě, nikoliv jen
díky marketingové strategii. ••• Oblíbená koncovka názvu softwarových produktů a firem.
3. • Rodina je základ státu, základem naší firmy je … (psáno anglicky) •• Jméno
baby, která je ve skutečnosti chlap.
4. • Sídlo u našich severních sousedů, také název jednoho z našich pracovišť. ••
Souhlas.
5. • Zkratka Národní outsourcingové asociace (pozor, některá cizí slova se jinak
vyslovují a jinak píší). •• Lyžařský vlek.
6. • Nechutné vedro v kanceláři, kdy ani klimatizace nepomáhá. •• Přídavné
jméno vztahující se například k nabídce vypracované v naší firmě.
7. • Vitamín nebo také programovací jazyk. •• 1. díl tajenky
Svisle :
A • Býval největší a nejlepší, ale brzy po nasazení do ostrého provozu neslavně
skončil, stal se synonymem zkázy ale současně legendou a námětem úspěšného
filmu, který vydělal spoustu peněz (psáno anglicky), jinak také připomíná název
jednoho z našich pracovišť.
B • Opak ostrova nebo také geomorfologický útvar inspirující Petra Iljiče
Čajkovského. •• Název anglicky mluvící televizní stanice přinášející aktuální
zpravodajství.
C • Předložka (7. pád) •• Regionální vládce v osmanské říši, spravující jemu přidělenou část území. ••• Římsky 51
D • Podnebí. •• Mechanický princip umožňující snadněji pohybovat s těžkými
břemeny, ale se zatuhnutým počítačem nepohne.
E • Univerzální čistící prášek na mytí van, umyvadel, nádobí. Vyroben na bázi
přírodních abraziv a odbouratelných tenzidů, příjemně citronově parfémovaný.
•• V rámci naplňování norem jakosti je jistý pracovník požádán, aby to (hledaný
výraz) „hodil“ na dokument vypracovaný jiným pracovníkem před odevzdáním
tohoto dokumentu zákazníkovi (i když dotyčný pracovník má chuť hodit na to
něco docela jiného).
F • Základ života. •• Africký stát , na jehož území leží město Timbuktu.
G • Římsky 1002 •• Programovací jazyk, jehož název je občas zaměňován s názvem ostrova v Indickém oceánu.
4
5
6
7
Nápověda:
Vodorovně:
1. •• Všichni byli Karlové.
2. ••• Také římsky 9
3. • Skupina zaměstnanců sdružená za účelem spolupráce na realizaci dodávky,
výraz je také často používán v souvislosti s kolektivními sporty. •• Jméno známé
z pohádek Orientu.
4. • Hlavní město Polska.
6. •• Vábná.
Svisle :
B • Ostrov = (voda, voda, země, voda, voda), opak ostrova = (země, země, voda,
země, země)
E • Možnosti: a) Jar b) AVA c) TIX •• Čidlo zraku hovorově.
F • Chodíme se tam vzdělávat abychom pak mohli jinam chodit vydělávat.
•• Rýmuje se s 2. výrazem ve 3. řádku
G •• CÉjlon to není
KOMIX s.r.o. je systémový integrátor zaměřený na dodávky vlastních řešení informačních systémů
s využitím moderních a ověřených technologií. Svým klientům poskytuje služby ve všech fázích
životního cyklu informačního systému od definice požadavků na jeho funkčnost, až po provedení
akceptačních testů a podporu jeho provozu.
KOMIX se přitom spoléhá především na vlastní vývoj, know-how a tým odborníků, kteří se
dokonale orientují v informačních technologiích, znají potřeby svých zákazníků a mají praktické
zkušenosti z realizace rozsáhlých systémů.
Hlavními kritérii úspěšnosti našich projektů jsou míra spokojenosti zákazníka a trvale dobré
vztahy. Předáním systému spolupráce nekončí, ale pokračuje ve formě technické podpory, školení
a dalších navazujících služeb.
Společnost KOMIX byla založena v září 1992 v Praze. V současné době má pobočku v Brně a 93
zaměstnanců.
Vyhodnocení:
Podle počtu bodů, které jste si připsali za každé použití nápovědy, si můžete
ověřit, do které kategorie patříte:
0–2
3–5
To jste asi špatně počítali body anebo jste křížovkářský génius.
Jste velmi zdatný křížovkář, navíc dobře obeznámený s prostředím
naší firmy.
6–8
Jste velmi zdatný křížovkář.
9 – 12
Jste velmi zdatný křížovkář, navíc poctivě (narozdíl od jiných) evidující
počet použití nápovědy.
13- 15
Tak to jste určitě počítali špatně, tolik nápověd zde uvedeno není.
16 a více To pro Vás nebyla křížovka, to byla krizovka.
Pokud Vám řešení tajenky připomíná název ulice, ve které sídlila společnost
KOMIX na sklonku minulého století, potom určitě patříte k dlouholetým přátelům, zákazníkům či zaměstnancům KOMIXu.
KOMIX – ověřená kvalita produktů a služeb
KOMIX s.r.o.
Holubova 1, 150 00 Praha 5, tel.: +420 225 989 811, fax: +420 225 989 803, [email protected], www.komix.cz
Redakční zpracování: kolektiv pracovníků KOMIX s.r.o., DTP a produkce: ARDEA grafické studio, s.r.o.
KOMIX s.r.o. 2003
10
A