University of Economics, Prague

Transkript

S c i e n t i f i c J o u r n a l | Vě d e c k ý č a s o p i s
ACTA INFORMATICA
PRAGENSIA
Vysoká škola ekonomická v Praze
Faculty of Informatics and Statistics
Fakulta informatiky a statistiky
1
2015
Editorial Board / Redakční rada
Stanislava Mildeová (Editor-in-Chief)
Eve Mitleton-Kelly
University of London
Klára Antlová
Technical University of Liberec
Ingeborg Němcová
Martin Boháček
Jan Rauch
Tomáš Bruckner
Václav Řezníček
Vesna Čančer
University of Maribor
Markus Schwaninger
University of St. Gallen
Rasa Daugėlienė
Kaunas University of Technology
Antonín Slabý
University of Hradec Kralove
Jiří Fišer
J. E. Purkyne University, Usti nad Labem
Zdeněk Smutný
Milan Houška
Czech University of Life Sciences, Prague
Olga Štěpánková
Czech Technical University, Prague
Miloslav Hub
University of Pardubice
Prokop Toman
Czech University of Life Sciences, Prague
Petr Kučera
Independent consultant, Prague
Milan Turčáni
Constantine the Philosopher University, Nitra
Petr Máša
Partners Financial Services, Prague
Viktor Vojtko
University of South Bohemia, Ceske Budejovice
Jan Ministr
VSB-Technical University of Ostrava
Jan Voráček
College of Polytechnics, Jihlava
Contact address / Kontakt:
Technical editors / Editoři:
Acta Informatica Pragensia
Zdeněk Smutný & Václav Řezníček
nám. W. Churchilla 4, 130 67 Praha 3, Czech Republic
e-mail: [email protected]
web: aip.vse.cz
tel.: +420 224 095 362
ACTA INFORMATICA PRAGENSIA
ISSN 1805-4951 (Online)
Acta
Informatica
Pragensia
is
focused
on
the
field
of
applied
informatics,
including
its
inter- and transdisciplinary character with an emphasis on management and administration in the field
of socio-economic environment. The journal is published biannually by the University of Economics,
Prague
and
is
included
in
the
government
list
of
peer-reviewed
journals
published
in the Czech Republic.
Časopis Acta Informatica Pragensia se zaměřuje na oblast aplikované informatiky, a to včetně jejího
v současnosti inter- a transdisciplinárního charakteru s akcentem na problematiku řízení a správy v oblasti
sociálně-ekonomického prostředí. Časopis vydává VŠE v Praze a je publikován dvakrát ročně. Časopis
je uveden v Seznamu recenzovaných neimpaktovaných periodik vydávaných v ČR – platný v roce 2015.
1
2015
ACTA INFORMATICA
PRAGENSIA
CONTENTS / Obsah
Peer-reviewed papers / Recenzované stati
Tománek, M.: Current State of Agile Methodologies Worldwide
and in the Czech Republic (in Czech) ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 04
Hronza, R., Pavlíček, J., Mach, R., Náplava, P.: Measures of Quality
in Business Process Modelling (in Czech) |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 18
Tůma, J., Pícka, M., Hanzlík, P.: Generated Report of the ORD BORM Model ||||||||||||||| 30
Měsíček, L.: Context Sources and their Processing in Company Security |||||||||||||||||||||||| 44
Pásler, M.: Evaluation of Web GIS Applications and their Development
Tools Using AHP (in Czech) |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 52
Vlčková, V., Hrubeš, P.: Traffic Accident, System Model and Cluster
Analysis in GIS (in Czech) ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 64
Říhová, Z.: Influence of Organization Management on Systems of Performance
Measurement and Management Control |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 80
Hub, M., Chudoba, M.: Usability of Public Administration Electronic
Forms (in Czech) |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 90
© Authors of the articles / Autoři jednotlivých článků.
Acta Informatica Pragensia, 2015, 4(1): 4–17
DOI: 10.18267/j.aip.48
Peer-reviewed paper
Současný stav používání agilních
metodik ve světě a v ČR
Current State of Agile Methodologies Worldwide
and in the Czech Republic
Martin Tománek*
Abstrakt
Cílem článku je porovnat používání agilních metodik ve světě a v České republice. Toto
porovnání je provedeno formou komparativní analýzy dvou dostupných průzkumů
uskutečněných v roce 2013 a publikovaných v roce 2014. Porovnání je dále obohaceno
o výsledky dosud nepublikovaného průzkumu používání agilních metodik v nadnárodní
logistické společnosti, který byl také proveden v roce 2013. Na základě tohoto celkového
porovnání je dále diskutován možný další vývoj používání agilních přístupů v České
republice s ohledem na světový trend.
Klíčová slova: Agilní metodika, Scrum, Extrémní programování, vývoj softwaru.
Abstract
The objective of this research paper is to compare the current state of agile methodologies
in the world and in the Czech Republic. The comparison is executed as the comparative
analysis of two publicly available researches conducted in 2013 and published in 2014.
The comparison is further enriched by the results of the unpublished survey in the global
logistics company which was conducted also in 2013. The potential trend for agile
methodologies in the Czech Republic is also discussed with regard to the worldwide trend.
Keywords: Agile, Scrum, Extreme programming, Software development.
1 Úvod
Článek se zabývá používáním agilních metodik ve světě a v České republice. Základ agilních
metodik tvoří principy a hodnoty, které byly definovány v roce 2001 v agilním manifestu
(Beck et al., 2001). Od té doby vznikají různé agilní metodiky, které jsou zaměřeny na
specifické oblasti. Jako příklad lze uvést nejrozšířenější metodiku Scrum, která se soustředí na
řízení agilního vývoje softwaru a dále metodiku Extrémního programování, která se soustředí
na techniky vývoje softwaru. Agilní metodiky byly zprvu vnímány velice skepticky, protože
byly v rozporu s dlouhodobě vyvíjenými tradičními (rigorózními) metodikami, které jsou
založeny na detailním plánování a robustním vývojovém modelu.
*
Department of Systems Analysis, Faculty of Informatics and Statistics, University of Economics, Prague,
 [email protected]
4
Volume 04 | Number 01 | 2015
Používáním agilních metodik ve světě se zabývá společnost VersionOne, která každoročně
provádí průzkum a vydává zprávu „State of agile“. Její první zpráva vyšla roku 2006
(VersionOne, 2006). Průzkum byl tehdy proveden na vzorku 722 účastníků a 84% z nich
uvedlo, že využívá agilní metodiky. Ve zprávě se dále uvádí, že průměrná doba využívání
agilních metodik byla 1,9 let a nejčastěji byly využívány metodiky Scrum a Extrémní
programování. Začátkem roku 2014 byla vydána zatím poslední a to osmá zpráva o používání
agilních metodik (VersionOne, 2014). Tato zpráva je založena na dotazníkovém šetření, které
bylo uskutečněno v roce 2013 a zúčastnilo se ho 3501 respondentů.
Ve stejném roce 2006, kdy společnost VersionOne vydala svoji první zprávu o používání
agilních metodik, byl proveden podobný průzkum i na území České republiky (Buchalcevová,
2006). Ze šetření vyplynulo, že 57% respondentů mělo malé nebo žádné znalosti o agilních
metodikách, pouze 5% respondentů využívalo Extrémní programování a nikdo z nich
nepoužíval metodiku Scrum. Výsledky tohoto průzkumu ukázaly značné zaostávání České
republiky vůči světu z pohledu používání agilních metodik v české praxi (Buchalcevová,
2009, s. 84).
Agilní metodiky se celosvětově stále více používají a tento trend je v posledních letech možné
vidět i v České republice. Pro podporu agilních přístupů v České republice se uskutečnila
v roce 2011 první konference „Agile Prague“. Následně vzniká sdružení Agilní Asociace
s cílem zvýšit povědomí o agilních metodách řízení a vytvořit platformu pro sdílení informací
a zkušeností z oblasti agilních přístupů. Tato asociace v současné době pořádá každoroční
agilní konference pod názvem „Agile Prague“ (Agilní Asociace, 2014).
Od roku 2006 se průzkumem používání agilních metodik v České republice žádná společnost
ani jednotlivec průběžně nevěnují a ani nebyl proveden žádný rozsáhlejší průzkum zabývající
se tímto tématem. Zlom však přichází v roce 2013, kdy Agilní Asociace spolu se společností
Etnetera provedly rozsáhlý průzkum používání agilních metodik v České republice (Pulkert,
2014), kterého se celkově zúčastnilo 171 respondentů.
Na základě výsledků průzkumů je nejčastěji používaná agilní metodika Scrum, která je
popsaná v druhé kapitole. Autor článku také provedl rešerši dostupné literatury za účelem
identifikace silných stránek této metodiky a jejich přínosů při vývoji softwaru. Výsledky
rešerše jsou uvedeny ve třetí kapitole.
Hlavní část článku, srovnání stavu používání agilních metodik ve světě a v ČR, je založena na
metodě komparativní analýzy dvou zmíněných veřejných průzkumů, které proběhly v roce
2013 (Pulkert, 2014; VersionOne, 2014) a dále třetího průzkumu, který byl uskutečněn
autorem článku v prostředí nadnárodní logistické společnosti (dále jen společnost) roku 2013.
Výsledky analýzy jsou uvedeny ve čtvrté kapitole.
2 Metodika agilního vývoje softwaru Scrum
Scrum je metodika pro agilní vývoj a údržbu složitých a komplexních softwarů. Fungování
Scrumu je popsáno v Průvodci Scrumem – Pravidla hry (Schwaber & Sutherland, 2013). Tato
metodika má jen 16 stránek a právě její jednoduchost přispěla k jejímu celosvětovému
rozšíření a užití. Sami autoři Scrum popisují jako rámec, který je jednoduchý, srozumitelný,
ale extrémně obtížný pro dokonalé zvládnutí. Metodika Scrum se využívá již přes 20 let a je
soustavně revidována. Poslední revize tohoto dokumentu je ze srpna roku 2013.
Metodika Scrum se skládá ze tří pilířů, tří rolí tvořící Scrum tým, čtyř činností (schůzek) a tří
artefaktů.
5
2.1
Pilíře
Scrum je empirická procesní metodika, která je postavena na následujících třech základních
pilířích (Schwaber & Sutherland, 2013, s. 3):



2.1.1
transparentnost,
kontrola,
adaptace.
Transparentnost
V rámci agilního vývoje je zapotřebí, aby všechny zúčastněné strany měly k dispozici
informace, které potřebují ke správnému rozhodování a řízení procesu vývoje. Těmto
informacím musejí také rozumět, proto je důležité se dohodnout na jednotném jazyce, který
pomůže všem stranám si navzájem porozumět a tím sladit jednotlivé požadavky, které od sebe
očekávají.
Scrum pro zajištění transparentnosti navrhuje používání tzv. artefaktů, které obsahují
identifikované požadavky na vyvíjený software včetně všech jejich charakteristik. Tyto
artefakty se dále využívají jako komunikační prostředek mezi vlastníkem produktu a
vývojovým týmem pro pochopení a upřesnění těchto požadavků.
2.1.2
Kontrola
Kontrola jednotlivých činností a výstupů je důležitá pro identifikaci potenciálních problémů,
které mohou nastat. Čím dříve se na problém přijde, tím je snazší tento problém odstranit.
Scrum včlenil kontrolu do hlavních činností vývoje a kontrola se tak stala nedílnou součástí
agilního vývoje softwaru.
2.1.3
Adaptace
Adaptace těsně navazuje na kontrolu. Je-li identifikována nepřijatelná odchylka od chtěného
stavu, poté je třeba reagovat a přizpůsobit proces tak, aby se vývoj dostal zpátky do správných
kolejí. Adaptace se, stejně jako kontrola, vyskytuje ve všech hlavních činnostech vývoje
softwaru a to v plánování sprintu, denních schůzkách, ve vyhodnocení sprintu
a v retrospektivě sprintu.
2.2
Role
Základní role ve Scrumu je Scrum tým, který se skládá z následujících dalších rolí (Schwaber
& Sutherland, 2013, s. 4):



vlastník produktu,
vývojový tým,
Scrum master.
Diagram organizační struktury Scrum týmu je vyobrazen na obrázku 1.
6
Scrum tým
Vlastník produktu
Vývojový tým
Scrum master
Obr. 1. Organizační struktura Scrum týmu. Zdroj: autor
Hlavní charakteristikou Scrum týmu je, že je sebeorganizující a multifunkční.
Sebeorganizující tým je takový, který si sám dokáže zvolit nejlepší cestu, jak dosáhnout
očekávaných výstupů a nemusí být tedy přímo řízen někým, kdo stojí mimo tým.
Multifunkční tým představuje tým, který je schopný sám dodat požadované výstupy a není
závislý na někom, kdo je mimo tým. Multifunkční tým tak disponuje všemi schopnostmi
a zdroji, které jsou zapotřebí.
2.2.1
Vlastník produktu
Vlastník produktu představuje roli, která je primárně odpovědná za maximalizaci hodnoty
finálního produktu (softwaru) a maximalizaci hodnoty práce vývojového týmu. Vlastník
produktu také formuluje produktovou vizi a cíle. K této odpovědnosti má vlastník produktu
k dispozici produktový backlog, který obsahuje všechny identifikované požadavky. Vlastník
produktu používá tento produktový backlog pro jasnou definici požadavků a jejich
prioritizaci. Pomocí backlogu také zajišťuje transparentnost nad všemi plánovanými
požadavky, nad požadavky, které se právě vyvíjí a které už byly dodány.
2.2.2
Vývojový tým
Vývojový tým je odpovědný za dodání přírůstku softwaru na konci každého sprintu.
Každý člen vývojového týmu je nazýván vývojářem, i přestože každý z nich může disponovat
jinými dovednostmi a schopnostmi. Vývojový tým neobsahuje žádné podtýmy a je složen
čistě z jednotlivých členů. Ideální velikost vývojového týmu se udává jako sedm členů. Tým
by však měl mít nejméně tři členy, aby se projevily synergické účinky a bylo zajištěno, že tým
bude disponovat všemi potřebnými dovednostmi. Jako maximální velikost týmu se udává
devět členů, kdy koordinace tohoto týmu je ještě na přijatelné úrovni a tým je schopen se sám
organizovat.
2.2.3
Scrum master
Scrum master je odpovědný za správné používání metodiky Scrum při agilním vývoji
softwaru. Scrum master také moderuje jednotlivé Scrum schůzky a činnosti, aby účastníci
dodržovali stanovený čas a dospěli k cílům schůzek. Často také Scrum master vystupuje jako
vedoucí vývojového týmu, ale jeho odpovědností v tomto případě je snaha o to, aby vývojový
tým pracoval co nejefektivněji. Scrum master dále poskytuje řadu služeb nejen vlastníkovi
produktu a vývojovému týmu, ale také celé organizaci. Vlastníkovi produktu Scrum master
radí, jak správně zacházet s produktovým backlogem, jak jasně specifikovat a udržovat
jednotlivé požadavky a jak plánovat celkový vývoj softwaru. Scrum master vede a učí
vývojový tým, aby byl sebeorganizovaný a multifunkční, snaží se o dodržování Scrum
technik a principů, chrání tým před negativními vlivy z okolí a odstraňuje překážky, které
7
brání vývojovému týmu v postupu. Vůči organizaci se Scrum master stará o osvojování
Scrum procesu v organizaci a o postupné zlepšování celého Scrum procesu.
2.3
Artefakty
Artefakty se ve Scrumu používají pro poskytování transparentnosti a umožňují kontrolu
a adaptaci. Scrum definuje následující tři artefakty (Schwaber & Sutherland, 2013, s. 12):



2.3.1
produktový backlog,
backlog sprintu,
přírůstek.
Produktový backlog
Produktový backlog obsahuje všechny požadavky na produkt (software), které jsou známy.
Za produktový backlog je odpovědný vlastník produktu a odpovídá za obsah, dostupnost
a prioritizaci. Produktový backlog je živý dokument a je neustále aktualizován, aby mohl
odrážet neustále se měnící požadavky na produkt. Kromě měnících se požadavků, produktový
backlog obsahuje také například nalezené chyby při testování softwaru. Každá položka
produktového backlogu má popis, prioritu a odhad náročnosti.
2.3.2
Backlog sprintu
Backlog sprintu obsahuje všechny požadavky a úkoly z produktového backlogu, na kterých
vývojový tým pracuje v současném sprintu. Tento backlog sprintu obsahuje detailní
informace o jednotlivých úkolech, které umožňují řídit proces vývoje softwaru na denní bázi,
a podporuje každodenní schůzky.
Backlog sprintu slouží také pro odhad celkové náročnosti všech úkolů v rámci daného sprintu
a k predikci, zdali budou všechny úkoly a požadavky uspokojeny včas.
2.3.3
Přírůstek
Přírůstek je software, který obsahuje všechny hotové požadavky, které byly dodány
v současném sprintu a ve všech minulých sprintech.
Důležitým aspektem při plánování sprintu a přírůstku je také definice „hotového“ přírůstku.
Vývojový tým musí definovat kritéria, při kterých je možné přírůstek označit jako hotový
a nasaditelný do produkce či do oběhu. Při definici tohoto kvalitativního kritéria je nutné vzít
v potaz požadavky kladené interními směrnicemi či externími standardy například
na bezpečnost či testování (Tomanek & Klima, 2015).
2.4
Činnosti
Činnosti definované Scrumem jsou časově omezené, pravidelné a mající jasné cíle. Činnosti
jsou také navrhnuty tak, aby splňovaly nároky kladené na transparentnost, kontrolu a
adaptaci. Je-li vynechána některá z předepsaných činností, vede tato skutečnost ke snížení
transparentnosti a částečnou ztrátu kontroly nad vývojem. Podstatou Scrumu je sprint, který
v sobě obsahuje jednotlivé činnosti a definuje jejich sled (Schwaber & Sutherland, 2013, s. 7).
2.4.1
Sprint
Cílem sprintu je během předem dané doby dodat přírůstek softwaru, který je možné přímo
předat vlastníkovi produktu a nasadit do produkce. Sprint obvykle trvá jeden měsíc a může
8
být i zkrácen na kratší dobu. Nedoporučuje se plánovat sprinty na dobu delší než jeden měsíc,
protože se mohou výrazně změnit podmínky na trhu či uvnitř organizace. Tímto by se pak
snížila flexibilita Scrum týmu pružně reagovat na měnící se požadavky.
Sprint se skládá z činností, které na sebe navazují. Jedná se o:




plánovací schůzka,
denní schůzka,
vyhodnocení sprintu,
retrospektiva sprintu.
Na obrázku 2 je znázorněn procesní model Scrumu kombinující role a artefakty popsané
v minulých kapitolách spolu s činnostmi.
Obr. 2. Procesní model Scrum. Zdroj: autor
2.4.2
Plánovací schůzka
Plánovací schůzka se koná na začátku sprintu, kdy se setkává celý Scrum tým, který
diskutuje, které jednotlivé požadavky budou vybrány a dodány na konci sprintu, a dále co je
zapotřebí vykonat pro dodání onoho přírůstku. Celou schůzku metodicky vede Scrum master,
který zajišťuje především splnění cíle této schůzky a dodržení časového harmonogramu
schůzky.
Základním vstupem do této schůzky je produktový backlog, kde jsou obsaženy prioritizované
požadavky na software. Vlastník produktu vysvětluje vývojovému týmu jednotlivé požadavky
a vývojový tým se snaží požadavkům porozumět a odhadnout, kolik těchto požadavků je
reálné během sprintu dodat. Poté, co se vyberou požadavky, které přinesou vlastníkovi
9
produktu největší hodnotu a které je vývojový tým schopen dodat v příštím sprintu, se vytvoří
backlog sprintu, který obsahuje seznam těchto požadavky. Tento backlog sprint dále
vývojový tým používá pro plánování činností, které je třeba vykonat, aby jednotlivé
požadavky byly uspokojeny a výsledný přírůstek (software) vytvořen. Na konci schůzky
vývojový tým prezentuje vlastníkovi produktu způsob a plán, jak budou postupovat při vývoji
softwaru, aby splnili cíl sprintu.
2.4.3
Denní schůzka
Tato schůzka se koná každý den a trvá maximálně 15 minut. Povinně se schůzky účastní
členové vývojového týmu a každý člen prezentuje, co udělal včera, co bude dělat dnes a zdali
vidí některé překážky, které mu brání ve splnění cíle sprintu. Tyto schůzky mají za úkol
synchronizovat aktivity mezi členy a vytvořit plán na příštích 24 hodin. Také slouží pro
identifikaci problémů, na které jednotliví členové týmu narazili.
2.4.4
Vyhodnocení sprintu
K vyhodnocení sprintu dochází v závěru sprintu, kdy se prezentuje přírůstek vlastníkovi
produktu. Hodnotí se také celkový průběh sprintu. Důraz je kladen na zpětnou vazbu a
vzájemnou komunikaci mezi vývojovým týmem a vlastníkem produktu. Vlastník produktu
má také právo pozvat další zúčastněné strany, aby byly informovány o výsledku sprintu.
V průběhu této schůzky se prochází produktový backlog a diskutuje se, jak jednotlivé
požadavky byly splněny či nesplněny. V rámci této schůzky probíhá také prezentace onoho
přírůstku softwaru. Jsou-li jednotlivé požadavky uspokojeny, poté se v produktovém backlogu
zavírají jako hotové.
2.4.5
Retrospektiva sprintu
Těsně po vyhodnocení sprintu se také koná retrospektiva sprintu, kde Scrum tým analyzuje
poslední sprint s ohledem na procesy, podpůrné nástroje, lidi a vztahy. Cílem je identifikovat
oblasti, které byly úspěšné a oblasti, které by bylo možné zlepšit. Po identifikaci těchto oblastí
se vytváří plán, jak celý Scrum proces zlepšit a zvýšit výkonnost nadcházejícího sprintu.
3 Silné stránky agilní metodiky Scrum
Agilní metodiky byly vytvořeny, aby bylo možné rychleji a levněji reagovat na změny.
U tradičních rigorózních metodik náklady na změny exponenciálně rostou, zatímco u agilních
metodik jsou náklady na změny v průběhu vývoje konstantní (Beck, 2000).
Další oblastí, kde agilní metodiky pozitivně přispívají k úspěšnosti projektu, je testování.
U tradičních metodik se testování provádí až ke konci projektu. U agilních metodik však
testování probíhá v jednotlivých sprintech a software se tedy testuje častěji a dříve. (Kettunen,
Kasurinen, Taipale, & Smolander, 2010; Li, Moe, & Dyba, 2010; Stoica, Mircea, & GhilicMicu, 2013; Sumrell, 2007) došli k názoru, že agilní přístupy nevedou k menšímu počtu chyb
v průběhu vývoje, ale vedou k dřívějšímu odhalení těchto chyb, k rychlejší a k efektivnější
nápravě a ke zvýšení spokojenosti zákazníka, který neobjeví tolik chyb při konečném
testování. (Li et al., 2010) dále uvádí, že Scrum umožňuje měřit počet chyb v jednotlivých
sprintech, tudíž lze měřit, jestli počet chyb při vývoji klesá nebo roste. Scrum zvýšil také
efektivitu odstraňování chyb, protože vývojáři snadněji opraví chyby, které programovali před
pár týdny, než chyby, které implementovali před pár měsíci. Další výhodou Scrumu je
vhodnost automatizace testování, protože se software opakovaně testuje v každém sprintu a
právě automatizace přispívá k efektivnějšímu pravidelnému testování. (Sutherland, Jakobsen,
10
& Johnson, 2007) dokazuje, že dřívější testování při agilním vývoji softwaru redukuje počet
chyb ve finálním testu o 42%. (Li et al., 2010) dokazuje, že 50% kritických chyb bylo
odstraněno dva týdny před nasazením do provozu. Tyto skutečnosti umožnily se vyvarovat
velkým chybám při nasazení do produkce a přispěly k dodání projektů včas.
Scrum také pomáhá přesněji odhadovat náklady na celý vývoj softwaru. Jelikož je vývoj
rozdělen do jednotlivých sprintů, je možné brzy vyčíslit náklady na jeden sprint a tento odhad
použít pro odhad nákladů celého životního cyklu vývoje softwaru (Baumeister & Ilg, 2013).
Další výhodou Scrumu je redukce plýtvání časem, pro které hlasovalo 68% respondentů
v průzkumu dle (Benefield, 2008).
4 Porovnání současného stavu používání agilních metodik
Porovnání současného stavu používání agilních metodik ve světě a České republice je
založeno na komparativní analýze výsledků dvou veřejně dostupných průzkumů provedených
v roce 2013 a publikovaných v roce 2014 (Pulkert, 2014; VersionOne, 2014). Takto
vytvořené porovnání je dále obohaceno o dosud nepublikovaná data z průzkumu, který je
popsán v následující kapitole.
4.1
Průzkum používání agilních
logistické společnosti
metodik
v prostředí
nadnárodní
Průzkum byl proveden autorem článku v průběhu roku 2013 formou dotazníkového šetření,
a to v nadnárodní logistické společnosti. Tato společnost má v České republice jedno ze svých
datových center a spolu s datovými centry v Německu, Malajsii a USA poskytuje interně IT
služby na globální úrovni. Mezi poskytované služby patří také vývoj softwaru. Cílem tohoto
průzkumu bylo zjistit, které projektové týmy využívají agilní metodiky.
Dotazníkové šetření probíhalo ve dvou kolech. První kolo šetření probíhalo na začátku
projektu, kdy projektový manažer obdržel odkaz na dotazník, který měl vyplnit. Druhé kolo
probíhalo na konci projektu, kdy projektový manažer měl zrevidovat již existující poskytnutá
data z prvního kola. Účelem tohoto dvoukolového šetření bylo identifikovat projektové týmy,
které nepoužívaly agilní metodiky a pomoct těmto projektovým týmům adoptovat agilní
metodiky při vývoji softwaru.
Samotné dotazníky byly vytvořeny na platformě MS SharePoint. Celkem bylo vyplněno 452
dotazníků. Výsledky tohoto průzkumu nebyly zatím nikde publikovány.
4.2
Výsledky komparativní analýzy
Tabulka 1 obsahuje informace o jednotlivých průzkumech.
Název průzkumu
Zaměření
Období
Počet dotazníků
Zdroj
8th Annual State
of Agile Survey
Celosvětové
2013
3501
(VersionOne,
2014)
Průzkum agilního
řízení v ČR 2013
Česká republika
2013
171
(Pulkert, 2014)
Průzkum agilního
řízení ve
společnosti
Česká republika,
Německo,
Malajsie, USA
2013
452
Autor článku
Tab. 1. Přehled analyzovaných průzkumů. Zdroj: autor
11
Porovnání se skládá z odpovědí na následující otázky, které byly kladeny v průzkumech.





Používáte ve vaší společnosti některé agilní metodiky?
Jak dlouho agilní metodiky používáte?
Kolik procent projektů řídíte pomocí agilních metodik?
Které agilní metodiky používáte?
Které agilní techniky používáte?
Celosvětový průzkum ukázal, že 88% respondentů používá agilní metodiky ve svých
společnostech, zatímco výsledek českého průzkumu ukázal 81% z dotazovaných. Tyto
výsledky naznačují časté využívání agilních metodik ve společnostech jak ve světě, tak
v České republice. Výsledky těchto výzkumů mohou být zkresleny, protože tyto dotazníky
jsou většinou odpovídány konzultanty, kteří se zabývají agilním vývojem (Stavru, 2014).
Výsledky průzkumu ohledně doby používání agilních metodik ve světě a České republice je
znázorněn na následujícím obrázku 3. Ve zkoumané společnosti se agilní metodiky začaly
nasazovat v roce 2011. Doba používání je tedy 3 roky a společnost by byla takto zařazena do
kategorie 2 až 5 let.
Doba používání agilních metodik
Svět
Procento respondentů
60%
ČR
53%
50%
40%
32%
32%
27%
30%
21%
19%
20%
10%
9%
7%
0%
méně než 1 rok
1 až 2 roky
2 až 5 let
více než 5 let
Obr. 3. Doba používání agilních metodik. Zdroj: autor na základě (Pulkert, 2014; VersionOne, 2014).
Ve světě se začaly agilní metodiky používat dříve než v České republice. Tento časový posun
je možné vypozorovat právě z obrázku 3. Ve světě mají respondenti dlouhodobější zkušenosti
s použitím agilních metodik a to 53% respondentů 2 až 5 let a 19% respondentů delší než
5 let. V České republice je situace jiná a 59% respondentů má zkušenosti s používáním
agilních metodik kratší než 2 roky a 32% respondentů v období 2 až 5 let. Pouhých 9%
českých respondentů má s agilními metodikami zkušenost delší než 5 let.
12
Následující obrázek 4 zobrazuje relativní četnosti projektů, které jsou řízeny pomocí agilních
metodik ve světě a v České republice. Ve zkoumané společnosti se v roce 2013 agilně řídilo
36% projektů a výsledek by takto patřil do druhé oblasti 26% až 50%.
Relativní četnosti projektů řízených agilně
Procento respondentů
Svět
ČR
46%
50%
38%
40%
30%
27%
21%
22%
20%
19%
14%
13%
10%
0%
méně než 25 %
26 % až 50 %
51 % až 75 %
více než 75 %
Počet projektů v procentech
Obr. 4. Procento projektů řízených agilně. Zdroj: autor na základě (Pulkert, 2014; VersionOne, 2014).
Relativní četnosti projektů řízených agilně vypovídají o adopci agilních metodik ve
společnostech a jejich používání na reálných projektech. Výsledek porovnání souvisí
i s dobou využívání agilních metodik ve světě a v České republice. Ve světě jsou agilní
metodiky častěji a dlouhodoběji používány, a proto je pomocí nich řízeno i větší množství
projektů.
Z pohledu použitých agilních metodik se shodně v obou průzkumech nejčastěji uvádí
metodika Scrum a její různé variace (Scrum kombinovaný s Extrémním programováním a
Scrumban). Užití Scrumu a jeho variací dosahuje ve světě 73% a v ČR 87%. Vyšší užití
Scrumu v České republice oproti celosvětovému průměru si autor vysvětluje pozdějším
nasazováním agilních metodik v ČR. V minulosti vznikla celá řada agilních metodik jako
například metodika Feature driven development (vývoj řízený vlastnostmi), Test driven
development (vývoj řízený testy), Crystal metodiky atd. Scrum se ve světě postupem času stal
nejrozšířenější agilní metodikou díky jednoduchosti a efektivnosti. České společnosti proto
nemusely experimentovat s různými agilními metodikami a přiklonily se k nejrozšířenější
metodice Scrum.
Ve zkoumané společnosti se jako vhodná agilní metodika zvolila právě metodika Scrum spolu
s technikami Extrémního programování. Následující obrázek 5 zobrazuje používání
jednotlivých agilních technik, a to ve světě, ČR a zkoumané společnosti. Průzkum ve
společnosti nepokrýval všechny agilní techniky, a proto u některých technik míra používání
chybí.
13
Používání jednotlivých agilních technik
Svět
ČR
Společnost
Denní schůzka
Plánování iterací
Retrospektiva
Jednotkové testování
Plánování vydání (release)
Agilní technika
Přehled práce v iteraci (burndown)
Rychlost vývoje (velocity)
Kontinuální integrace
Automatizované buildování
Dedikovaný vlastník produktu
Standardy kódování
Refaktoring
Vývoj řízený testy
Párové programování
Kolektivní vlastnictví kódu
Tabule s lístečky
0%
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Míra používání agilní techniky
Obr. 5. Používání agilních technik. Zdroj: autor na základě (Pulkert, 2014; VersionOne, 2014) a svého
průzkumu.
Mezi nejrozšířenější agilní techniky ve světě a ČR patří denní schůzka, plánování iterací,
retrospektiva a jednotkové testování. V České republice, ve srovnání se světem, často
dominují technicky zaměřené agilní techniky jako například automatizované buildování
(stavění) softwaru a refaktoring (čištění kódu).
Ve světě, na druhé straně, jsou častěji využívány techniky sloužící pro plánování a kontrolu
vývoje softwaru jako například plánování vydání softwaru (release planning), přehled práce
v iteraci (burndown) a měření rychlosti vývoje (velocity).
U zkoumané společnosti se používání některých agilních technik výrazně liší. Tyto odlišnosti
jsou způsobeny prostředím dané společnosti a faktem, že se jedná o logistickou společnost
s vlastním vývojem IT a ne o společnost, která se zabývá komerčním vývojem softwaru.
Z tohoto pohledu je nejrozšířenější agilní technikou právě kolektivní vlastnictví kódu. Ze
stejného důvodu je i ve společnosti velmi rozšířena agilní technika dedikovaného vlastníka
produktu.
Oba veřejné průzkumy dále obsahují důvody, proč agilní metodiky nebyly zavedeny, a také
největší obavy, které existují při zavádění agilních metodik do společností. Ve světě se jako
nejčastější důvody uvádí problémy s organizační změnou jako například nemožnost změnit
organizační kulturu, odolnost ke změně, odmítavý postoj managementu a zaměstnanců.
Zajímavé zjištění však je, že v České republice se na prvním místě objevil důvod „vědomostní
deficit“, který ve světě již není vnímán jako důvod bránící dalšímu zavádění agilních metodik
14
do praxe. Mezi obavy při zavádění agilních metodik patří u obou veřejných průzkumů strach
ze ztráty počátečního plánování a ztráty manažerské kontroly nad vývojem softwaru. Tyto
obavy je možné zmírnit pomocí uplatnění principů projektového managementu při agilním
vývoji software (Tomanek, Cermak, & Smutny, 2014).
5 Závěr
Článek porovnává používání agilních metodik ve světě, České republice a nadnárodní
logistické společnosti. Agilní metodiky jsou ve světě vysoce rozšířené a používá je 88%
respondentů. V České republice bylo hromadné nasazování agilních metodik opožděno.
Uvědomíme-li si, že v roce 2006 většina respondentů českého průzkumu vykazovala malé
nebo žádné povědomí o agilních metodikách, tak současný stav, kdy agilní metodiky využívá
81% respondentů, je z pohledu autora velice příznivý.
Na základě porovnání je možné vypozorovat, že české společnosti používají agilní metodiky
kratší dobu, mají s nimi menší zkušenost a pomocí těchto agilních metodik řídí menší
množství projektů než dle celosvětového průzkumu.
Z pohledu použití agilních technik, české společnosti dohnaly celosvětovou míru používání
základních Scrumových činností, které tvoří jádro sprintů, a to denní schůzky, plánování
iterací (sprintu) a retrospektiva sprintu.
U technicky orientovaných agilních technik české společnosti také dosahují celosvětovou
úroveň (například jednotkové testování a kontinuální integrace) a u některých technik
dokonce přesahují celosvětovou úroveň (refaktoring, automatizované buildování a kolektivní
vlastnictví kódu). Používání tabule s lístečky při denních schůzkách je celosvětově na ústupu
z důvodu používání aplikací pro týmovou spolupráci. Každá druhá česká společnost však tuto
techniku stále používá. Budou-li však české společnosti následovat světový trend, tak autor
očekává postupné omezení této techniky.
Podíváme-li se ale na techniky, ve kterých české společnosti zaostávají, tak se jedná
o manažerské, kontrolní a kvalitativní techniky jako je například přehled vykonané a
zbývající práce pomocí burndown reportů, měření rychlosti vývoje (velocity), plánování
celkových softwarových vydání (release planning), vývoj řízený testy, standardy kódování a
dedikovaný vlastník produktu.
Postupné nasazování agilních metodik a jejich zvyšující se obliba přispívá k celkovému
pozitivnímu vnímání agilních metodik. Do budoucna proto používání agilních metodik bude
dle autora dále růst. K hlavním důvodům, které brání širšímu užití agilních metodik, patří
nejčastěji problémy s organizační změnou. Na základě českého průzkumu je však
„vědomostní deficit“ označen jako hlavní důvod bránící širšímu nasazování agilních metodik
u českých společností. Uvědomíme-li si, že mezi často používané techniky v ČR patří
technicky orientované a mezi nejméně používané patří manažerské, kontrolní a kvalitativní
techniky, poté je nutné propagovat agilní přístupy u manažerů a vedoucích pracovníků
českých společností. Mezi argumenty, které lze použít pro větší nasazení agilních metodik,
patří například snížení nákladů na změny v průběhu vývoje, dřívější odhalení chyb, rychlejší
a efektivnější náprava chyb, zvýšení spokojenosti zákazníka při konečném testování,
automatizace testování a také přesnější odhadování nákladů na celý vývoj softwaru.
15
Poděkování:
Tento příspěvek byl vytvořen díky podpoře z grantu IGA F4/5/2013 řešeném na Fakultě
informatiky a statistiky, VŠE v Praze.
Seznam použitých zdrojů
Agilní Asociace. (2014). Agile Prague Conference. Dostupné z http://agileprague.com/
Baumeister, A., & Ilg, M. (2013). Financial Management and Control of Iterative Software Processes.
In Annual International Conference on Accounting & Finance (s. 33–38). doi: 10.5176/22511997_AF13.16
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Indianapolis: Addison-Wesley
Professional.
Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., et al.
(2001). Manifesto for Agile Software Development. Dostupné z http://agilemanifesto.org/
Benefield, G. (2008). Rolling Out Agile in a Large Enterprise. In 41st Annual Hawaii International
Conference on System Sciences. doi: 10.1109/HICSS.2008.382
Buchalcevová, A. (2006). Stav používání agilních metodik v ČR. Systémová integrace, 13(4), 23-31.
Buchalcevová, A. (2009). Metodiky budování informacních systému. Praha: Oeconomica.
Kettunen, V., Kasurinen, J., Taipale, O., & Smolander, K. (2010). A study on agility and testing
processes in software organizations. In 19th international symposium on Software testing and
analysis (s. 231–240). New York: ACM. doi: 10.1145/1831708.1831737
Li, J., Moe, N. B., & Dyba, T. (2010). Transition from a plan-driven process to Scrum: a longitudinal
case study on software quality. In Proceedings of the 2010 ACM-IEEE International Symposium
on Empirical Software Engineering and Measurement. New York: ACM. doi:
10.1145/1852786.1852804
Pulkert, D. (2014). Průzkum agilního řízení v ČR 2013. Etnetera. Dostupné z
http://www.etnetera.cz/public/1b/43/e5/52571_103079_agilni_dotaznik_report_2013_5.pdf
Schwaber, K., & Sutherland, J. (2013, srpen). The Scrum Guide, Průvodce Scrumem: Pravidla hry.
Dostupné z https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-GuideCS.pdf
Stavru, S. (2014). A critical examination of recent industrial surveys on agile method usage. Journal of
Systems and Software, 94, 87-97. doi: 10.1016/j.jss.2014.03.041
Stoica, M., Mircea, M., & Ghilic-Micu, B. (2013). Software Development: Agile vs. Traditional.
Informatica Economica, 17(4), 64-76. doi: 10.12948/issn14531305/17.4.2013.06
Sumrell, M. (2007). From Waterfall to Agile - How does a QA Team Transition? In Proceedings of the
Agile Conference (AGILE) 2007 (s. 291-295). Washington: IEEE Computer Society. doi:
10.1109/AGILE.2007.29
Sutherland, J., Jakobsen, C. R., & Johnson, K. (2007). Scrum and CMMI Level 5: The Magic Potion
for Code Warriors. In Proceedings of the Agile Conference (AGILE) 2007 (s. 272-278). doi:
10.1109/AGILE.2007.52
Tomanek, M., Cermak, R., & Smutny, Z. (2014). A Conceptual Framework for Web Development
Projects Based on Project Management and Agile Development Principles. In 10th European
Conference on Management Leadership and Governance (s. 550-558). Reading: ACPI.
Tomanek, M., & Klima, T. (2015). Penetration Testing in Agile Software Development Projects.
International Journal on Cryptography and Information Security, 5(1). doi:
10.5121/ijcis.2015.5101
16
VersionOne. (2006). Survey: The State of Agile Development. VersionOne Inc. Dostupné z
http://www.versionone.com/pdf/2006-state-of-agile-survey.pdf
VersionOne. (2014, červen 30). 8th Annual State of Agile Survey. VersionOne Inc. Dostupné z
http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
17
DOI: 10.18267/j.aip.57
Peer-reviewed paper
Míry kvality v procesním modelování
Measures of Quality in Business Process Modelling
Radek Hronza*, Josef Pavlíček*, Richard Mach†, Pavel Náplava*
Abstrakt
Procesní analýza a modelování byznys procesů je jedna z významných částí aplikované
(byznys) informatiky. Kvalita byznys procesů (diagramů) je v této oblasti velmi důležitá.
Cílem každého procesního analytika by měla být tvorba srozumitelných, jednoznačných
a bezchybných procesních diagramů. Pokud je proces řádně popsán, lze jej využít jako vstup
pro detailnější analýzu a optimalizaci. Lze předpokládat, že řádně vytvořený a popsaný
diagram byznys procesu (obdobně jako řádně napsaný algoritmus) bude obsahovat
charakteristiky, které lze matematicky popsat. Kromě toho by bylo možné vytvořit nástroj,
který by pomohl procesním analytikům vytvářet vhodné procesní diagramy. V rámci tohoto
přehledového článku bude realizována rešerše dostupné literatury, jejíž cílem je nalezení
a následné provedení analýzy míry návrhu a kvality byznys procesů. Rešerší bylo nalezeno,
že zmíněná oblast již byla předmětem výzkumu. Bylo nalezeno třicet tři vědeckých publikací
a dvacet dva měr kvality. Závěrem lze říci, že nalezené vědecké publikace a míry kvality
nereflektují všechny důležité atributy jasnosti, jednoduchosti a úplnosti modelů byznys
procesů. Z toho důvodu by bylo vhodné obohatit existující míry kvality diagramů byznys
procesů.
Klíčová slova: Modelování byznys procesů, analýza byznys procesů, byznys procesy, míry
kvality, BPMN.
Abstract
Business process modelling and analysing is undoubtedly one of the most important parts
of Applied (Business) Informatics. Quality of business process models (diagrams) is crucial
for any purpose in this area. The goal of a process analyst’s work is to create generally
understandable, explicit and error free models. If a process is properly described, created
models can be used as an input into deep analysis and optimization. It can be assumed that
properly designed business process models (similarly as in the case of correctly written
algorithms) contain characteristics that can be mathematically described. Besides it will be
possible to create a tool that will help process analysts to design proper models. As part of
this review will be conducted systematic literature review in order to find and analyse
business process model’s design and business process model’s quality measures. It was
found that mentioned area had already been the subject of research investigation in the past.
*
Center for Knowledge Management, Faculty of Electrical Engineering, Czech Technical University in Prague,
Technická 2, 166 27 Praha 6 - Dejvice, Czech Republic
 [email protected], [email protected], [email protected]
†
Faculty of Information Technology, Czech Technical University in Prague,
Technická 2, 166 27 Praha 6 - Dejvice, Czech Republic
18
Thirty-three suitable scientific publications and twenty-two quality measures were found.
Analysed scientific publications and existing quality measures do not reflect all important
attributes of business process model’s clarity, simplicity and completeness. Therefore
it would be appropriate to add new measures of quality.
Keywords: Business process modelling, Business process analysing, Business processes,
Measures of quality, BPMN.
Úvod
1
Drtivá většina institucí (komerčních i nekomerčních) je čím dál tím více nucena přemýšlet
nad efektivitou svého fungování. Nejen kvůli nedostatku financí na vlastní provoz, ale
především z důvodu znatelného růstu konkurenčního prostředí, narůstající globalizaci
a rychlosti změn na trhu. Bez znalosti fungování organizace a schopnosti jejího hodnocení to
v podstatě není možné. Proto hraje výkonnost a efektivní využití zdrojů organizace čím dál
tím významnější roli. Nejen dnes, ale i v budoucnu. Jedním z možných způsobů, jak řízeně
zlepšovat efektivitu fungování organizace, je zavedení procesního řízení, založeného na
sdílené znalosti vlastních procesů.
Toho si je vědoma i Fakulta elektrotechnická Českého vysokého učení technického v Praze,
kde již od roku 2009 probíhá projekt procesního mapování podpůrných a vybraných hlavních
procesů. Realizaci projektu zajišťuje, pro tyto účely nově založené a specializované, interní
Centrum Znalostního Managementu (Hronza & Špeta, 2013; Náplava et al., 2014) dále jen
CZM. Identické projekty, které potvrzují potřebu efektivního řízení organizace jak
v nekomerčním, tak i komerčním prostředí, jsou / byly ze strany CZM realizovány také na
Fakultě strojní Českého vysokého učení technického v Praze, Západočeské univerzitě v Plzni,
Univerzitním centru energeticky efektivních budov Českého vysokého učení technického
v Praze a ve firmě Škoda Praha Invest. Do budoucna lze očekávat, že poptávka po procesním
mapování (případně navazující optimalizaci procesů) bude, nejen ze strany akademických
institucí, vysoká. Také se dá očekávat, že se v aktuální nebo modifikované podobě stane
nezbytným standardem pro efektivní fungování všech organizací. Praktické zavedení
procesního řízení ale není ani jednoduchou, ani krátkodobou a ani jednorázovou činností.
Například v rámci výše zmíněných několika projektů bylo zmapováno a namodelováno
řádově přes tisíc procesů. Vše v notaci BPMN, která je pro svou jednoduchost a intuitivnost
pro tyto účely jednou z nejvhodnějších.
Jednoduchost a intuitivnost notace BPMN na jedné straně, přináší celou řadu problémů na
straně druhé. V průběhu procesního mapování se jak pracovníci CZM, tak i samotní uživatelé
(zaměstnanci) mapovaných institucí empiricky setkávali s celou řadou problémů, které
z nedostatků notace BPMN vycházely (Van Nuffel, Mulder, & Van Kervel, 2009). Jednalo se
především o následující problémy:



Značná rozdílnost úrovně zachycených detailů (komplexitě) mapovaných procesů,
které byly namodelovány různými analytiky a uživateli.
o Různí analytici dle svých schopností, zkušeností a informací od uživatelů
zachytí stejný proces různě. Lze měřit úroveň zachycených detailů?
Syntaktické chyby ve zmapovaných procesech, zachycených pomocí notace BPMN.
o Často zapříčiněno nejasným a nedefinovaným způsobem využití příslušných
prvků notace BPMN. Lze strojově rozpoznávat špatné vzory?
Změna rolí účastníků zmapovaných procesů v průběhu vykonávání jediného procesu.
19



o V jednom procesu by každý uživatel měl mít přiřazenou jedinou roli. Pokud
dochází ke změně role, je potřeba proces rozdělit na podprocesy.
Nesrozumitelnost zmapovaných procesů, které bylo zapříčiněno vysokým množstvím
použitým symbolům BPMN v rámci jediného procesu.
o Již s principu lze prohlásit, že proces o malém počtu elementů bude zajisté
přehlednější než proces s vysokým počtem elementů. Jaký je však optimální
počet BPMN elementů v rámci jednoho procesu?
Duplicitní využití stejných symbolů BPMN v rámci jediného procesu.
o Například jeden koncový stav procesu byl reprezentován více BPMN symboly
charakterizující konec.
Odlišná míra dekompozice jednoho procesu do více podprocesů.
o Koresponduje s vysokým počtem použitých symbolů notace BPMN. Jaký je
maximální počet BPMN elementů na jeden proces?
Výše zmíněné problémy v praxi často vedly k nutnosti nového zmapování celého procesu,
nadměrnému (redundantnímu) času, vyžadovanému pro mapování a modelování, zvýšení
počtu kontrol kvality a následných úprav vytvořených modelů tak, aby byly výsledné modely
jednoduché, pochopitelné, dostatečně detailní a odpovídající reálnému průběhu procesu.
Pouze správně zmapovaný a zakreslený proces bylo a je možné považovat za výchozí
předpoklad pro následnou analýzu a optimalizaci, která vede ke zlepšení chodu celé
organizace.
Cílem tohoto článku je realizace systematické rešerše dostupné literatury (Budgen
& Brereton, 2006), za účelem nalezení odpovědí na následující otázky:





Lze nějakým způsobem měřit kvalitu zmapovaného a namodelovaného procesu?
Pokud ano, existují již nějaké metody, míry či jiné indikátory kvality?
Pokud metody, míry či jiné indikátory kvality existují, jsou běžně používané v praxi?
Pokud metody, míry či jiné indikátory kvality existují, jsou součástí některého
z existujících standardů?
Existují SW nástroje, umožňující míry či ukazatele kvality modelu odpovídajícím
způsobem hodnotit?
Smysluplnost položených otázek potvrzuje článek (Vanderfeesten et al., 2007a), kde se autoři
zabývají podobnou problematikou měření efektivity řádově desítek tisíc zmapovaných a
namodelovaných procesů díky převzatým mírám z oblasti vývoje SW. Z tohoto důvodu
v následujícím textu popíšeme průběh a výsledky rešerše dostupné literatury tak, aby došlo
k nalezení aktuálních odpovědí na výše položené otázky.
Rešerše dostupné literatury
2
2.1
Průběh rešerše
Rešerše dostupné literatury byla provedena na základě článku (Budgen & Brereton, 2006).
Pro zajištění vysoké odbornosti a kvality získaných výstupních dat bylo rozhodnuto o využití
následujících informačních zdrojů: Web of Science, ACM Digital Library, EBSCO, IEEE
Xplore, Scopus, SpringerLink.
Oblast informací, na které byla rešerše zaměřena, byla zúžena na „procesní míry“, které lze
využít pro měření kvality procesních modelů. Na začátku rešerše byly nejdříve využity
klíčové slova „Process metrics“ a „BPMN measures“. Následně byl počet nalezených zdrojů
informací postupně upravován pomocí změn klíčových slov. Finální podoba klíčových slov se
20
ustálila na kombinaci "Process quality metrics" a "Process complexity metrics". Použitím
těchto klíčových slov a výše zmíněných informačních zdrojů byla vybrána výsledná množina
relevantních zdrojů informací. V posledním kroku došlo k ověření, zda výslednou množinu
relevantních zdrojů lze ještě doplnit o specifické míry. Toho bylo dosaženo pomocí
následujících výrazů:



Process coupling complexity.
Process cohesion complexity.
Control flow complexity.
Výsledná množina relevantních zdrojů informací byla průběžně redukována pomocí
následujících doplňkových omezujících kritérii:



Celý text je dostupný online.
Akceptovaný jazyk je angličtina nebo čeština.
Zdroje informací mají formu vědeckého článku, knihy nebo příspěvku na konferenci.
Rešerše informačních zdrojů proběhla v termínu 22. ledna 2015 až 24. února 2015. Obsahuje
informace, publikované a dostupné do tohoto data.
2.2
Výsledky rešerše, způsob extrakce a syntézy dat
V průběhu rešerše literatury bylo nalezeno celkem 33 relevantních informačních zdrojů
(Ghani et al., 2008; Cardoso et al., 2006; Cardoso, 2005b, 2006, 2007, 2008; Fu et al., 2010;
Gruhn & Laue, 2006a, 2006b; Henry & Kafura, 1981; Huang & Kumar, 2009; Khlif et al.,
2009, 2010; Kluza & Nalepa, 2012; Lassen & Van Der Aalst, 2009; Latva-Koivisto, 2001;
Mendling, Neumann, & Aalst, 2007; Mendling, 2006; Muketha et al., 2010; Parizi & Ghani,
2008; Reijers & Vanderfeesten, 2004; Reijers, 2003; Rolón et al., 2009; Roy et al., 2014;
Sánchez-González et al., 2011; Shao & Wang, 2003; Solichah et al., 2013; Thammarak, 2010;
Vanderfeesten, Cardoso, & Reijers, 2007; Vanderfeesten et al., 2007a; Vanderfeesten et al.,
2008; Vanderfeesten, Reijers, & Van Der Aalst, 2008). Každý z nalezených zdrojů byl autory
tohoto článku přečten a analyzován. Během čtení a analýzy bylo nakonec nalezeno celkem 22
vhodných měr kvality procesních modelů.
Výsledky rešerše dostupné literatury
3
3.1
Míry kvality
Nalezených 22 měr kvality procesních modelů lze rozdělit následujícím způsobem:
1. Number of activities (NOA, NOT) - (Ghani et al., 2008; Cardoso et al., 2006; Gruhn
& Laue, 2006b; Khlif et al., 2009; Kluza & Nalepa, 2012; Mendling et al., 2007;
Muketha et al., 2010; Thammarak, 2010; Vanderfeesten et al., 2007a).
a. Nejjednodušší forma měření komplexity procesu. Bere v úvahu pouze délku
procesu a nebere v úvahu žádné další vlastnosti procesu.
2. Control-Flow Complexity (CFC) - (Ghani et al., 2008; Cardoso et al., 2006; Jorge
Cardoso, 2005b, 2006, 2007, 2008; Fu et al., 2010; Gruhn & Laue, 2006b; Khlif et al.,
2009; Kluza & Nalepa, 2012; Lassen & van der Aalst, 2009; Mendling et al., 2007;
Muketha et al., 2010; Parizi & Ghani, 2008; Rolón et al., 2009; Roy et al., 2014;
Sánchez-González et al., 2011; Solichah et al., 2013; Thammarak, 2010;
Vanderfeesten et al., 2007a; Vanderfeesten et al., 2008).
21
a. Míra se zaměřuje na komplexitu struktury větvení procesu (OR-split, XORsplit, AND-split). CFC vyjadřuje složitost jako počet možných průchodů
procesem.
3. Max/mean nesting depth - (Ghani et al., 2008; Gruhn & Laue, 2006b; Kluza &
Nalepa, 2012).
a. Míra vyjadřuje složitost vnoření procesu jako počet struktur větvení
potřebných k dosáhnutí daného elementu procesu. Míra může být použitá
spolu s CFC za účelem přesnějšího měření složitosti.
4. Number of handles - (Gruhn & Laue, 2006b).
a. Míra vyjadřuje počet struktur větvení procesu, který nesplňují kritérium „wellstructuredness“. Toto kritérium přikazuje, aby byli struktury větvení správně
vnořené.
5. Cognitive weight (Cognitive Complexity) - (Ghani et al., 2008; Gruhn & Laue,
2006a, 2006b; Kluza & Nalepa, 2012; Shao & Wang, 2003; Thammarak, 2010).
a. Vyjadřuje složitost porozumění modelu procesu. Tuto složitost vyjadřuje jako
sumu kognitivních vah jednotlivých elementů. Váhy elementů jsou určené na
základe empirických studií.
6. BPM (Anti)Patterns - (Ghani et al., 2008; Gruhn & Laue, 2006b).
a. Míra rozeznává výskyt anti vzorů v procesech. Tj. často se vyskytujících
konstrukcí, které vedou ke zvýšení nekorektnosti a složitosti procesu.
7. Fan-in/Fan-out (Modularization) - (Ghani et al., 2008; Gruhn & Laue, 2006b;
Makni et al., 2010; Thammarak, 2010).
a. Míra popisuje míru využívanosti podprocesů a vyjadřuje tak jejich
funkcionalitu a složitost v rámci procesu.
8. Coefficient of network complexity (CNC) - (Cardoso et al., 2006; Kluza & Nalepa,
2012; Latva-Koivisto, 2001; Makni et al., 2010; Mendling et al., 2007; Muketha et al.,
2010; Roy et al., 2014; Vanderfeesten et al., 2007a).
a. Míra vyjadřuje složitost procesu jako poměr počtu přechodů k počtu aktivit,
joinů a splitů procesu.
9. Cyclomatic number - (Lassen & van der Aalst, 2009; Latva-Koivisto, 2001; Roy et
al., 2014).
a. Je přímou adaptací SW měr. Podobně jako CNC vyjadřuje složitost pomocí
počtu přechodů a aktivit procesu.
10. Complexity index (CI) - (Cardoso et al., 2006; Latva-Koivisto, 2001; Roy et al.,
2014; Vanderfeesten et al., 2007a).
a. Míra adaptovaná z teorie grafů. Definuje složitost procesu jako počet redukcí
uzlů procesního grafu, které zredukují graf na jediný uzel.
11. Restrictiveness estimator (RT) - (Cardoso et al., 2006; Latva-Koivisto, 2001; Roy et
al., 2014).
22
a. Míra
adaptovaná
z teorie
grafů.
Vyjadřuje
složitost
procesu
ve standardizovaném rozsahu [0,1] pomocí hodnot počtu uzlů procesního grafu
a matice dosažitelnosti.
12. Number of trees in graph - (Latva-Koivisto, 2001; Roy et al., 2014).
a. Hodnota míry vyjadřuje počet navzájem odlišných stromů, které obsahují
procesní graf. Se zvyšující se konektivitou grafu se zvyšuje počet stromů a tím
i složitost procesu.
13. Process Cohesion (TPC, LPC) - (Khlif et al., 2009; Reijers & Vanderfeesten, 2004;
Reijers, 2003; Vanderfeesten, Reijers, & Van Der Aalst, 2008).
a. Míra vyjadřuje soudržnost částí procesního modelu. Tuto oblast složitosti
procesu popisuje jen několik měr, popisujících komunikaci a přenos informací
mezi aktivitami procesu.
14. Process Coupling (CBO, RFC, MPC, ICP) - (Khlif et al., 2009, 2010; Reijers &
Vanderfeesten, 2004; Vanderfeesten, Reijers, & Van Der Aalst, 2008).
a. Míra vyjadřuje složitost procesu jako složitost přechodů mezi jednotlivými
aktivitami, stupeň jejich spojitosti a závislosti.
15. Process coupling / cohesion ratio - (Reijers & Vanderfeesten, 2004; Vanderfeesten,
Reijers, & Van Der Aalst, 2008).
a. Míra je definovaná jako podíl hodnot složitosti předcházejících dvou měr.
Vyšší hodnota tohoto podílu značí vyšší složitost procesu.
16. Halstead-based Process Complexity (HPC) - (Cardoso et al., 2006; Khlif et al.,
2009; Kluza & Nalepa, 2012; Muketha et al., 2010; Solichah et al., 2013; Thammarak,
2010).
a. Míra vyjadřuje složitost a srozumitelnost procesu jako funkci počtu
jedinečných a celkových operandů a operátorů.
17. Interface Complexity (IC) - (Cardoso et al., 2006; Henry & Kafura, 1981; Khlif et
al., 2009; Kluza & Nalepa, 2012; Makni et al., 2010; Muketha et al., 2010;
Thammarak, 2010).
a. Míra vyjadřuje složitost procesu jako počet vstupů a výstupů jednotlivých
aktivit. Současně bere ohled i na délku aktivity reprezentované buď jako
„white box“ nebo „black box“.
18. Density - (Mendling, 2006).
a. Míra vyjadřuje složitost procesu jako poměr realizovaných propojení mezi
aktivitami k počtu všech potencionálních propojení.
19. Cross-Connectivity (CC) - (Mendling, 2006; Muketha et al., 2010; Vanderfeesten et
al., 2008).
a. Míra počítá váhu propojení mezi dvojicemi aktivit procesu. Váha propojení
závisí na typu propojení aktivit.
20. CP - (Vanderfeesten, Cardoso, & Reijers, 2007).
23
a. Je přímou adaptací SW měr. Míra se zaměřuje na počet přechodů mezi
aktivitami procesu. Hodnota složitosti podle této míry závisí na složitosti a
typu přechodů.
21. GQM (Goal-Question-Metric) - (Ghani et al., 2008).
a. Míra se snaží měřit složitost procesu pomocí množiny otázek. Nejdříve jsou
definovány cíle projektu a soubor otázek pro dosažení dílčích cílů. Potom jsou
využívány různé míry na adresování každé otázky.
22. Q0, Q1, Q3 - (Huang & Kumar, 2009).
a. Míry Q0, Q1, Q2 měří kvalitu procesu na základě skóre vyjádřeného z počtu
cyklů, nepovinných aktivit a bloků procesu.
3.2
Četnosti výskytů měr a demografické údaje
Četnost výskytu jednotlivých měr ve výše uvedených informačních zdrojích shrnuje obrázek
č. 1. Jak je z grafu patrné, nejčastěji uvažované míry jsou 1) the Control-Flow Complexity, 2)
Number of Activities and 3) Coefficient of Network Complexity.
22
10
8
7
6
1
1
1
2
4
3
1
1
2
3
4
3
4
2
7
4
2
Obr. 1. Četnost výskytu jednotlivých měr. Zdroj: autoři
Z časového hlediska nalezené relevantní zdroje informací pokrývají rozpětí let 2001 až 2014.
Starší datum publikace má jen jediný zdroj. Více viz obrázek č. 2, ze kterého je zřejmé, že se
zájem o problematiku měření kvality procesních modelů začal zvyšovat v roce 2005. Nejvíce
publikací připadá na rozpětí roků 2006 až 2010.
24
5
5
4
4
3
2
1
2
1
1
1
1
1
1
0
1981 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
Obr. 2. Počty relevantních informačních zdrojů dle data jejich publikace. Zdroj: autoři
Z demografického pohledu pocházejí relevantní informační zdroje především ze zemí západní
Evropy. Konkrétně pak z Nizozemí a Portugalska. Více viz obrázek č. 3.
6
5
3
3
2
2
2
2
2
2
1
USA
FIN
NLD
PRT
DEU AUT MYS TUN
ESP
1
CHN THA
1
POL
AUS
Obr. 3. Počty relevantních informačních zdrojů dle původu. Zdroj: autoři
4
Diskuze
Z výše uvedené rešeršní práce je patrné, že podobné otázky, které si položili autoři tohoto
článku, již řeší také řada jiných vědeckých týmů ve světě. Dle počátečního předpokladu tedy
existují míry, které umožňují definovaným způsobem (vlastním pro každou míru) měřit
kvalitu navrženého procesního modelu. Většina, v rešerši nalezených a obecně požívaných
měr, je založena na analýze grafického zobrazení procesního modelu - BPM (Business
Process Model). Na procesní model se tvůrci měr často dívají jako na graf, tedy objekt
složený z uzlů a hran. Každá hrana pak může být v konkrétní míře kvality např. vstupem pro
výpočet složitosti modelu. Stejně tak je možný použít každý uzel, který dle svého druhu
(Aktivita versus Brána) může být navíc ohodnocen ještě např. vahou. Váhy je pak možné
nastavovat na základě operace, kterou uzel symbolizuje. Například brána (Gateway),
rozdělující procesní tok, logicky graf zesložiťuje. Sjednocující brána naopak proces fakticky
slučuje. Je tudíž logické brány rozdělující proces ohodnotit takovou vahou, která reprezentuje
„pokutu“ za zvýšení složitosti. Naopak sjednocující brány není nutné handicapovat žádnou
vahou. Podobně lze konkrétní vahou ohodnotit části modelu typu „Podprocess“ (Sub-process)
a „Úloha“ (Task). Je patrné, že „Podprocess“ symbolizuje větší složitost celkového procesu
než výskyt „Úlohy“. Na základě těchto a podobných úvah dnes jsou fakticky definované
25
a autory často zmiňované míry typu: Number of activities, Control-Flow Complexity,
Cyclomatic number a další.
Z našeho praktického výzkumu však vyplývá, že výpočet měr z pouhého grafického
zaznamenání procesu nemusí být vždy účelný. Velmi často se totiž na realizaci procesu
podílejí i faktory (obvyklé na první pohled skryté), které jej ovlivňují nepřímo. Typickým
příkladem může být (viz problémy detekované autory článku a popsané v úvodní kapitole
tohoto článku):



Nejasně definovaný aktér (konzument procesu). Například proces „odevzdání žádosti
ke studiu na studijním oddělením“. V tomto případě je definovaný aktér procesu
studijní oddělení. Nejedná se však o jasně definovanou odpovědnou osobu či
odpovědný systém. V tomto případě tvůrce modelu předpokládá, že existuje nějaká
vnitřní směrnice detailně upravující, co se stane s žádostí, když padne do schránky
studijního oddělení. Tato nejasnost není z modelu patrná, ale v tomto příkladu může
úspěšné dokončení procesu značně ovlivnit.
Dalším faktorem, který není z grafického vyjádření modelu bez detailní znalosti
procesu a jeho uchopitelnosti jednotlivými aktéry vůbec patrný, je např. schopnost
modelujícího týmu zaznamenat korektně a s odpovídajícími detaily obchodní proces:
o Jedná se o začátečníky se základní znalostí problematiky a oblasti analýzy
a modelování procesů.
o Jedná se o pokročilé analytiky, kteří se účastnili alespoň jednoho projektu,
zaměřeného na analýzu a modelování procesů.
o Jedná se o experty s dlouholetou praxí v oblasti analýzy a modelování procesů.
A v neposlední řadě je faktorem, který ovlivňuje vznik a finální zavedení procesu do
reálného prostředí, typ analyzované a modelované organizace (firmy). Pokud
použijeme podobný postup jako tvůrci metody COCOMO (Boehm et al., 1995), je
možné prostředí firmy označit jako:
o organické prostředí (tedy malá firma s bezproblémovým přenosem znalostí
a informací mezi jejími zaměstnanci),
o přechodné prostředí (středně velké firmy – do cca 200 zaměstnanců),
o vázané prostředí (Velké firmy a nadnárodní korporace).
Je zajímavým zjištěním, že z provedené a výše popsané rešerše zdrojů, autoři pro tvorbu
nalezených měr tento přístup nepoužívají. Přitom výše zmíněné faktory prokazatelně kvalitu
procesů výrazně ovlivňují, ale z pouhé analýzy grafu vytvořeného procesního modelu jsou
měřitelné jen obtížně.
Závěr
5
Odpovědi na otázky, které byly náplní provedené a popsané rešerše, můžeme shrnout
následovně:



26
Lze nějakým způsobem měřit kvalitu zmapovaného a namodelovaného procesu?
o Ano je to možné. Nejčastěji se používá míra založená na rozboru grafu
(grafického vyjádření) procesního modelu.
Pokud ano, existují již nějaké metody, míry či jiné indikátory kvality?
o Ano existují. Bylo nalezeno celkem 22 různých měr kvality procesních
modelů. Míry jsou blíže specifikovány v kapitole 3.1 – Míry kvality.
Pokud metody, míry či jiné indikátory kvality existují, jsou běžně používané v praxi?


o Z provedené rešerše vychází, že nejčastěji jsou používány míry Control-Flow
Complexity, Number of activities, Coefficient of network complexity,
Halstead-based Process Complexity a Interface Complexity.
Pokud metody, míry či jiné indikátory kvality existují, jsou součástí některého
z existujících standardů?
o Pokus o standardizaci jsme v rámci prováděné rešerše fakticky zaznamenali u
míry Control-Flow Complexity. Nejedná se však o oficiální standardizaci
ISO.
Existují SW nástroje, umožňující míry či ukazatele kvality modelu odpovídajícím
způsobem hodnotit“?
o Žádné obecně používané nástroje pro výpočet měr nebyly v rámci provedené
rešerše nalezeny. Softwarové nástroje, pokud jsou použity, jsou součástí
nástrojů pro výzkum dílčích týmů, nikoliv obecně dostupné.
o Existuje pokus o standardizaci formátu pro uložení procesních modelů
(XPDL). Zatím nemáme ověřeno, zda tento formát je obecně používán
modelovacími nástroji jako např. Bizagi či QPR. Tyto nástroje dle našeho
výzkumu tento formát podporují, nevíme, zda formát dodržují komplexně, či
jej využívají pouze parciálně.
Z výše uvedených závěrů je patrné, že práce na návrzích měr kvality procesních modelů je
účelná a zabývá se jimi řada vědeckých týmů. Z našeho pohledu je zajímavé rozšířit nalezené
míry o další atributy, ovlivňující tvorbu procesních modelů. Například využít principů
a metod, které jsou součástí COCOMO či Function Point. Ačkoliv jsou tyto metody navrženy
primárně pro odhad složitosti programů na základě počtu řádků zdrojového kódu (COCOMO)
či na základě počtu funkcí (Function Point), existují zde z našeho pohledu a na základě
provedené analýzy a praktické zkušenosti paralely s procesním modelováním. Zmíněná oblast
problematiky je však rozsáhlá a výzkumných oblastí je zde celá řada. Jako možné další směry
výzkumu lze uvést možnost rozšíření o takové míry, které by dokázaly vyjádřit míru
srozumitelnosti procesních diagramů ze strany jejich „konzumentů / čtenářů“. Tj. obohatit
výzkum i o některé oblasti kognitivních věd. Za zmínku také stojí ověření možnosti
strojového zpracování a vyhodnocení měr kvality návrhu procesního diagramů. Výše zmíněné
je však předmětem dalšího výzkumu autorů tohoto přehledového článku.
Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995). Cost models for
future software life cycle processes: COCOMO 2.0. In Annals of Software Engineering, 1, 57–94.
doi:10.1007/BF02249046
Budgen, D., & Brereton, P. (2006). Performing Systematic Literature Reviews in Software
Engineering. In Proceedings of the 28th International Conference on Software Engineering
(pp. 1051–1052). New York, NY, USA: ACM. doi:10.1145/1134285.1134500
Cardoso, J. (2005). How to measure the control-flow complexity of web processes and workflows.
In L. Fischer (Ed.), Workflow Handbook 2005 (pp. 199–212). Lighthouse Point: WfMC.
Cardoso, J. (2006). Process control-flow complexity metric: An empirical validation. In IEEE
International Conference on Services Computing (pp. 167–173). Chicago, IL, USA: IEEE.
doi:10.1109/SCC.2006.82
Cardoso, J. (2007). Control-flow Complexity Measurement of Processes and Weyuker-s Properties.
International Journal of Computer, Control, Quantum and Information Engineering, 1(8),
2521 - 2526.
Cardoso, J. (2008). Business process control-flow complexity: Metric, evaluation, and validation.
International Journal of Web Services Research, 5(2), 49-76.
27
Cardoso, J., Mendling, J., Neumann, G., & Reijers, H. A. (2006). A discourse on complexity of
process models. In Business process management workshops (pp. 117-128). Springer: Berlin
Heidelberg.
Fu, X., Zou, P., Ma, Y., Jiang, Y., & Yue, K. (2010). A Control-Flow Complexity Measure of Web
Service Composition Process. In Services Computing Conference (APSCC) (pp. 712 – 716).
Hangzhou: IEEE. doi:10.1109/APSCC.2010.27
Ghani, A., Azim, A., Koh, T. W., Muketha, G. M., & Wong, P. W. (2008). Complexity metrics for
measuring the understandability and maintainability of business process models using goalquestion-metric (GQM). International Journal of Computer Science and Network Security, 8(5),
219-225.
Gruhn, V., & Laue, R. (2006a). Adopting the Cognitive Complexity Measure for Business Process
Models. In 5th IEEE International Conference on Cognitive Informatics (pp. 236 – 241). Beijing:
IEEE. doi:10.1109/COGINF.2006.365702
Gruhn, V., & Laue, R. (2006b). Complexity Metrics for Business Process Models. In 9th international
conference on business information systems (pp. 1–12). Klagenfurt: STI International.
Henry, S., & Kafura, D. (1981). Software Structure Metrics Based on Information Flow. IEEE
Transactions on Software Engineering, SE-7(5), 510–518. doi:10.1109/TSE.1981.231113
Hronza, R., & Špeta, M. (2013). Business Process Center of Excellence at the Faculty of Electrical
Engineering at the Czech Technical University in Prague. In IEEE 15th Conference on Business
Informatics (CBI) (pp. 346–349). Vienna: IEEE. doi:10.1109/CBI.2013.56
Huang, Z., & Kumar, A. (2009). New Quality Metrics for Evaluating Process Models. In Business
Process Management Workshops (pp. 164–170). Milano: Springer Berlin Heidelberg.
doi:10.1007/978-3-642-00328-8_16
Khlif, W., Makni, L., Zaaboub, N., & Ben-Abdallah, H. (2009). Quality metrics for business process
modeling. In WSEAS International Conference on Applied Computer Science (ACS 09). Genova:
WSEAS Press (pp. 195-200).
Khlif, W., Zaaboub, N., & Ben-Abdallah, H. (2010). Coupling Metrics for Business Process Modeling.
WSEAS Transactions on Computers, 9(1), 31–41.
Kluza, K., & Nalepa, G. J. (2012). Proposal of square metrics for measuring Business Process Model
complexity. In Federated Conference on Computer Science and Information Systems
(pp. 919 - 922). Wroclaw: IEEE.
Lassen, K. B., & van der Aalst, W. M. (2009). Complexity metrics for workflow nets. Information
and Software Technology, 51(3), 610-626.
Latva-Koivisto, A. M. (2001). Finding a complexity measure for business process models - Research
Report. Helsinki: Helsinki University of Technology. Retrieved from
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.2991&rep=rep1&type=pdf
Makni, L., Khlif, W., Haddar, N. Z., & Ben-Abdallah, H. (2010). A tool for evaluationg the quality
of business process models. In Business Process and Service Science - Proceedings of ISSS
and BPSC P-177 (pp. 230–242). Bonn: Gesellschaft für Informatik.
Mendling, J. (2006). Testing Density as a Complexity Metric for EPCs. Vienna: Vienna University
of Economics and Business. Retrieved from http://www.mendling.com/publications/TR06density.pdf
Mendling, J., Neumann, G., & van der Aalst, W. (2007). On the correlation between process model
metrics and errors. In 26th International Conference on Conceptual modeling (pp. 173-178).
Darlinghurst: Australian Computer Society.
Muketha, G. M., Ghani, A. A. A., Selamat, M. H., & Atan, R. (2010). A survey of business process
complexity metrics. Information Technology Journal, 9(7), 1336–1344.
doi:10.3923/itj.2010.1336.1344
Náplava, P., Hronza, R., Kočí, J., & Pavlíček, J. (2014). How to Successfully Start the
Transformation of an Academic Institution. Case study on the process mapping project at the
Czech Technical University. In 8th Workshop on Transformation & Engineering of Enterprises
28
(TEE 2014), and the 1st International Workshop on Capability-oriented Business Informatics
(CoBI 2014) co-located with the 16th IEEE International Conference on B (pp. 1–15.). Aachen:
RWTH Aachen University
Parizi, R. M., & Ghani, A. A. A. (2008). An Ensemble of Complexity Metrics for BPEL Web
Processes. In 9th ACIS International Conference on Software Engineering, Artificial Intelligence,
Networking, and Parallel/Distributed Computing (pp. 753 – 758). Phuket: IEEE.
doi:10.1109/SNPD.2008.152
Reijers, H. A. (2003). A Cohesion Metric for the Definition of Activities in a Workflow Process.
In International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design
(pp. 116–125). Velden: CAiSE/IFIP 8.1.
Reijers, H. A., & Vanderfeesten, I. T. P. (2004). Cohesion and Coupling Metrics for Workflow
Process Design. In Business Process Management (pp. 290–305). Potsdam: Springer Berlin
Heidelberg. doi:10.1007/978-3-540-25970-1_19
Rolón, E., Cardoso, J., García, F., Ruiz, F., & Piattini, M. (2009). Analysis and Validation of ControlFlow Complexity Measures with BPMN Process Models. In Enterprise, Business-Process and
Information Systems Modeling SE - 6 (pp. 58–70). Amsterdam: Springer Berlin Heidelberg.
doi:10.1007/978-3-642-01862-6_6
Roy, S., Sajeev, A. S. M., Bihary, S., & Ranjan, A. (2014). An Empirical Study of Error Patterns in
Industrial Business Process Models. IEEE Transactions on Services Computing, 7(2), 140–153.
doi:10.1109/TSC.2013.10
Sánchez-González, L., Ruiz, F., García, F., & Cardoso, J. (2011). Towards Thresholds of Control
Flow Complexity Measures for BPMN Models. In Proceedings of the 2011 ACM Symposium on
Applied Computing (pp. 1445–1450). New York: ACM. doi:10.1145/1982185.1982496
Shao, J., & Wang, Y. (2003). A new measure of software complexity based on cognitive weights.
Canadian Journal of Electrical and Computer Engineering, 28(2), 69–74.
doi:10.1109/CJECE.2003.1532511
Solichah, I., Hamilton, M., Mursanto, P., Ryan, C., & Perepletchikov, M. (2013). Exploration on
software complexity metrics for business process model and notation. In International
Conference on Advanced Computer Science and Information Systems (ICACSIS) (pp. 31–37).
Bali: IEEE. doi:10.1109/ICACSIS.2013.6761549
Thammarak, K. (2010). Survey Complexity Metrics for Reusable Business Process. In 1st National
Conference on Applied Computer Technology and Information System (pp. 18–22). Nonthaburi:
ACTIS.
Van Nuffel, D., Mulder, H., & Van Kervel, S. (2009). Enhancing the Formal Foundations of BPMN
by Enterprise Ontology. In Advances in Enterprise Engineering III (pp. 115–129). Amsterdam:
Springer Berlin Heidelberg. doi:10.1007/978-3-642-01915-9_9
Vanderfeesten, I., Cardoso, J., & Reijers, H. A. (2007). A weighted coupling metric for business
process models. In 19th International Conference on Advanced Information Systems
Engineering (pp. 41–44). Trondheim: CAiSE’07. Retrieved from http://ceur-ws.org/Vol247/FORUM_11.pdf
Vanderfeesten, I., Cardoso, J., Mendling, J., Reijers, H. A., & Van Der Aalst, W. (2007a). Quality
Metrics for Business Process Models. In BPM and Workflow Handbook (pp. 179–190.).
Lighthouse Point, Florida: Future Strategies.
Vanderfeesten, I., Reijers, H., Mendling, J., van der Aalst, W. P., & Cardoso, J. (2008).
On a Quest for Good Process Models: The Cross-Connectivity Metric. In Advanced Information
Systems Engineering (pp. 480–494). Montpellier: Springer Berlin Heidelberg.
doi: 10.1007/978-3-540-69534-9_36
29
DOI: 10.18267/j.aip.58
Peer-reviewed paper
Generated Report of the ORD BORM Model
Jakub Tůma*, Marek Pícka*, Petr Hanzlík*
Abstract
This contribution focuses on documentation of model-to-model transformation, respectively
on converting model represented by BORM notation (Business Object Relation Modelling)
to a HTML-based textual report. The transformation is from the management-level business
process model into the operation-level business process model. The operation-level model
should be textual and tailored for each individual participant. This article introduces
a modular extension of OpenCASE software that utilizes OpenCASE knowledge base and
API to generate textual reports automatically. This report is based on HTML language,
because of the portability and easy distribution of the format. Such report is easy
to understand even for business people without hard technical skills. We present both the
transformation, and the modular extension on a case study.
Keywords: BORM, Transformation, Tool, Report, HTML, Case study.
1
Introduction
Models created in CASE tools are probably the most comprehensive description of system.
However, these models, and relationships among them, can be difficult to understand. Even
though BORM diagrams are generally easy to understand, it may still be challenging to fully
comprehend the situations modelled, especially for non-specialists and businesspeople.
A textual report describing BORM diagram can significantly contribute to better
understanding of problem as a whole and increase the accessibility of information stored
within models. A repository of CASE tool can be used as a source of data for generating such
documentation. When a report is generated automatically from models, the safe consistency
between the model and documentation is guaranteed. Another advantage is the possibility
to reinstate documentation when source model changes.
We want to present our approach for flexible modelling of business processes both at the
management and operations level. This approach consists of combining a suitable modelling
method (BORM – Business Object Relation Modelling) and developing an original software
tool (OpenCASE) to support it, as well as to perform automated model transformations.
This article focuses on transformation of source model created in CASE tool to textual output
model and technologies used for implementation of this transformation. Input of this
transformation is a model using BORM notation, output of the transformation is model
represented as a HTML report.
*
Department of Information Engineering, Faculty of Economics and Management, Czech University of Life Sciences,
Prague, Kamýcká 129, 165 21 Praha 6, Czech Republic
 [email protected], [email protected], [email protected]
30
This research is based on the BORM method described in publications by (Knott, Merunka,
Polak, 2000, 2006; Struska, Merunka, 2007; Struska, Pergl, 2009). The presented tool
OpenCase (Pergl, Tůma, 2012) follows this modelling method, and uses it as input
of transformation. Core transformations are based on the HOT (High Order Transformation)
approach published by (Brambilla, Fraternali, Tisi, 2008). This transformation is presented on
the case study which demonstrates the transformation from the management-level business
process model into the operation-level business process model. More specifically the case
study deals with the process of E-shop order goods.
2
Materials and methods
2.1
Methodology
In order to realize the proposed transformation, we have followed a stepwise research plan:
1. Define requirements for a suitable management-level business process model
and operation-level business process model (BPM).
2. Describe how the transformation modelling method and the OpenCASE support these
requirements.
3. Design a case study to illustrate the results.
2.2
Requirements for Management-Level and Operation-Level BPM
For purposes of this research, let us define that management level is focused on process
orchestration, specifically:
●
●
●
●
●
Terminology
Logic of processes
Relations of processes (transition, decomposition)
Communication among participants
Optimisation of the overall process
The language of models needs to support the aspects listed above. That is why a combination
of graphical and textual language is usually used. The management level BPM specifies
terms and their relations that are consequently manipulated in different ways:
●
●
●
●
●
They need to be verified for correctness.
They need to be communicated.
They are used for reasoning.
Various reports and statistics need to be calculated.
They are often changed (they evolve).
This is why the management-level BPM needs to be some sort of knowledge base, not just
a set of diagrams (graphical objects). Terms and their relations are necessary for full domain
specification and to fulfil knowledge base.
By operational level, we mean concrete processes (operations) here, which are performed by
assigned process participants (staff, systems). Systems (as participants) are software, thus
31
subject of computer science and software engineering. For further discussion we will consider
just human participants. We set following requirements on operation model:
●
●
●
●
Language of the model is close to the language of participants.
Model is accurate.
Model contains just the necessary amount of details to perform operations required.
Model is up to date and consistent with corresponding management-level model.
Staff is not supposed to be interested in the “big picture” at the operation level, they just need
accurate instructions for performing their tasks, i.e. the management needs to answer their
questions:
●
●
●
●
What are the steps I should follow to successfully complete a task?
How should I make decisions and select correct approach?
What are the inputs I will get? From whom, how and when?
What are the outputs I should produce? To whom shall I handle them, how and when?
To answer these questions, textual operation manuals are typically used, as operation-level
staff does not have to understand graphical objects with abstract notations.
2.3
Business Object Relationship Modelling (BORM)
Business Object Relationship Modelling (Knott, Merunka, Polak, 2006; Polák, Merunka,
Carda, 2003) is an object-oriented software engineering methodology, which has proven to be
very effective in the development of business information and knowledge systems. Its
effectiveness is achieved by unified and simple method for presenting all aspects of the
relevant model. The BORM methodology makes extensive use of business process modelling
(Knott, Merunka, Polak, 2000). BORM was designed as a method covering all phases of the
software development. BORM focuses mainly on the first phases of the project also
known as business analysis. BORM uses only limited, easily comprehensible group of
concepts for every lifecycle phase. This makes it easier to understand even for the first-time
users with almost no knowledge of business analysis.
Another fact that makes the BORM methodology more expressive is that it doesn´t
need the division to static and dynamic views of the model and therefore does not
bring a need of creation of different diagrams with a different viewpoints. BORM introduces
the following types of diagrams:



32
Business architecture diagram
Object relationship diagram (ORD) (see Figure 1)
Class diagram
Fig. 1. Example of Object Relationship Diagram (ORD). Source: (Pergl, Tůma, 2012)
BORM represents every concept with the same symbols in the data structure, the
communication or other diagrams. For visual presentation of the information BORM
uses simple diagrams that contain only a necessary number of concepts and symbols.
These concepts and symbols cover most of the needs for the initial description of the
model and its processes. The following symbols belong to the symbols used in the initial
description:







Participant – an object representing the stakeholder involved in one of the
modelled processes, which is recognised during the analysis.
State – sequential changes of the participants in time are described by these states.
Association – data-orientated relation between the participants.
Activity – represents an atomic step of the behaviour of the object recognised
during the analysis.
Communication – represents the data flow and dependencies between the
activities. Data may flow bidirectionally during the communication.
Transition – connects the state-activity-state and represents changes of the states
through activities.
Condition – expresses constraint that holds for the communication or activity,
(Polák, Merunka, Carda, 2006; Šplíchal, Pergl, Pícka, 2011).
33
2.4
OpenCASE
OpenCASE Tool (2014) is a CASE tool designed to support the research in the field of
conceptual modelling and related ontologies. Snapshot of OpenCASE prototype is presented
in the Figure 2. It is built upon the Eclipse Modelling Framework and it utilizes many of its
advanced possibilities. Right now, we have implemented the BORM method’s Business
Architecture Diagrams and Object Relation Diagrams (Pergl, Tůma, 2012).
Fig. 2. Snapshot of OpenCASE prototype. Source: (Pergl, Tůma, 2012)
3
Results and discussion
3.1
Documentation generating
The case study demonstrates the transformation from management-level business process
model into operation-level business process model. As we specified in the requirements,
operation-level model should be textual and tailored for each participant. This is where we
utilize the OpenCASE as a knowledge base and its API to generate HTML page for each
participant. This HTML output is similar to SBVR, (Cabot, Pau, Raventós, 2010; OMG,
2008; Booch, Rumbaugh, Jacobson, 1999).
The transformation is based on approach HOT (High Order Transformation) and this model
generation has theoretical background in publication (Šplíchal, Pergl, Pícka, 2011). Modelling
tool OpenCASE includes this transformation as an extendable module.
The higher order transformation phase addresses mapping (see Figure 3.), guaranteeing the
coherence between the conforms to relationship of the two technical spaces. This task is
performed in two subtasks:
1. a promotion transformation obtains the DSL metamodel by promoting the model M1
resulting from the model generation phase to metamodel (M2);
34
2. a manually deﬁned HOT derives the M1T transformation by translating the M2T
transformation, and eventually analyzing the structure of the DSL metamodel
published by (Brambilla, Fraternali, Tisi, 2008).
Fig.3. Diagram of framework using HOT. Source: (Brambilla, Fraternali, Tisi, 2008)
HOT approach was theoretically described by (Brambilla, Fraternali, Tisi, 2008) and cited in
this paper above and shown in Figure 3. This HOT implementation is used for report
generation of the ORD BORM Model.
A programing implementation of this mechanism is presented below, in the Snippet 1 and
Snippet 2. These implementations are used for HTML report generation from ORD BORM
Model.
(defn or-report [or-diagram]
(let [name
(first (return or-diagram :entity :id))
reports (map participant-report (participants or-diagram))
notes (note-report (or-diagram))
]
(list*
(element :h1 {} (str "OR Diagram: " name))
reports
notes
)))
Snippet 1: Main function for generating report from ORD diagram
(defn -write [this manager file]
(with-open [writer (java.io.OutputStreamWriter. (java.io.FileOutputStream. file) "UTF-8")]
(let [ords (diagrams (.getProject manager) :ORDiagram)
35
reports (mapcat or-report ords)]
(emit (xhtml-page "XHTML Report" reports) writer :encoding "UTF-8"))))
Snippet 2: Export function for creating XHTML
Snippet number 1 shows the main function. This function is called OR-report, and it generates
a semi model from the inner structure (metamodel of ORD BORM model) representing ORdiagram. This semi model is processed by the write function (see Snippet 2) which produces a
XHTML report page. These functions have been implemented using function programming
paradigm, which takes advantage of simplification of equational reasoning (Wadler, 1992).
More information about functional programming can be found in Wadler (1992). DOM
(Document Object Model) is used for transformation to HTML. DOM is tree structure of
HTML transformation output.
To generate documentation (XHTML report) was implementated in functional language.
Functional programming is simplicity of equational reasoning Wadler (1992) and more info
about functional programming in publication (Wadler, 1992). DOM (Document Object
Model) is used for generating or more precisely transformation to HTML. DOM is tree
structure of HTML transformation output.
3.2
Case study
The case study is based on the processes order goods from e-shop. The case study was written
with team cooperation based on the course information management. Course information
management is part of the field Project management at the Czech University of Life Sciences,
Prague. In order to demonstrate the principals of proposed BORM to HTML transformation
and other concepts outlined in this paper, a part of the processes related to order goods from
e-shop is presented in a simplified version.
The order goods process is carried out by cooperation among five participants: Customer,
Deliverer, Economics department, Order processor and Supplier. This process is shown in
details in Figure 4.
36
Fig. 4. Case study management process model in BORM: E-shop order goods. Source: authors.
The HTML operation manuals are generated for each participant (Figures 5 – 9).
37
Fig. 5. Operation model (manual) for participant Customer. Source: authors.
Fig. 6. Operation model (manual) for participant Deliverer. Source: authors.
38
Fig. 7. Operation model (manual) for participant Economics department. Source: authors.
Fig. 8. Operation model (manual) for participant Supplier. Source: authors.
39
Fig. 9. Operation model (manual) for participant Order processor. Source: authors.
The transformation engine is handling correctly the branching, loops and hierarchical
processes (process in a state). It uses paragraphs labelling to navigate the user along the
process flow.
4
Discussion
There are currently two CASE tools that are able to operate with BORM ORD notation
– CraftCase and OpenCASE. OpenCASE is a commercial product developed by CraftCase
Company. OpenCASE on the other hand is a platform, which was developed and designed at
the Faculty of Economics and Management, Czech University of Life Sciences, in
cooperation with Faculty of Information Technology, Czech Technical University. It provides
an open modular platform available for free for community of registered scholars and experts.
It is based on generally available Eclipse plugin. Any interested developer can hence
contribute to the development of the platform, and take part in experiments and research.
Thanks to this background, OpenCASE can currently offer several state of art components,
such as above presented transformation module.
40
5
Future works
Possible future works:
● Listings, like all input/output flows from/to a participant.
● Calculation of metrics (like numbers of states and activities in participants) that may
be used for complexity estimations Struska and Pergl (2009), Struska and Merunka
(2007).
● Calculation of statistics, e.g. about data flows and communications (which
participants communicate the most/least, above/below average, etc.).
● Semantics checks: there is a starting state in every participant, at least one final state
(According to the BORM, there may be exceptions to these rules, see (Gronback,
2009) for more details.),
● Conceptual normalization to be implemented in tool that is described by Molhanec
(2011).
● Any further custom reporting / calculations / processing.
6
Conclusion
In this paper we presented our solution that generates HTML documentation from BORM
diagrams and supports business process engineering in general. This is accomplished using
a combination of suitable modelling method and notation (BORM) and software tool
(OpenCASE). The key principle of the solution is that the modelled process is not just
a diagram, but a whole knowledge base that may be used in operations, reporting, decision
making and other areas. We presented one of consequences of this assumption: automatic
generation of operations manuals.
The OpenCASE is created as an open platform for studying BORM method and business
modelling in general. Apart from this, it is already a stable tool for effective drawing
of BORM models and their management. It is implemented using open architecture based on
Eclipse plugins, which makes it extensible and scalable. The presented extension
of OpenCASE tool makes the BORM models more accessible for businesspeople who are
typically not familiarised with state-based diagrams and business diagrams.
Acknowledgements
Many thanks to my supervisor Vojtěch Merunka and to the team leader Robert Pergl for a lot
hints and mental support. This paper documents summarise previous and future developing
process of dissertation thesis.
References
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modelling Language User Guide.
Massachusetts: Addison-Wesley Longman.
Brambilla, M., Fraternali, P. & Tisi, M. (2008). A Transformation Framework to Bridge Domain
Specific Languages to MDA. In MoDELS Workshops 2008, (pp. 167-180). Berlin: Springer.
Cabot, J., Pau R. & Raventós, R. (2010). From UML/OCL to SBVR specifications: A challenging
transformation. Information Systems, 35(4), 417-440.
41
Gronback, R. C. (2009) Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit.
Massachusetts: Addison-Wesley Longman.
Knott, R. P., Merunka, V., & Polak, J. (2000). Process modeling for object oriented analysis using
BORM object behavioral analysis. In IEEE International Conference on Requirements
Engineering (pp. 7-16). Chicago: IEEE & ACM.
Knott, R., Merunka, V. & Polák, J. (2006). The BORM Method: A Third Generation Object-Oriented
Methodology. In Liu, L. & Roussev B. (Eds) Management of the Object-Oriented Development
Process. (pp. 337-360). Hershey: IGI Publishing.
Merunka, V., Milena, S., Arvilla, C., Plas, M. & Tuma, J. (2013). BORM-II and UML as accessibility
process in knowledge and business modelling. In 22nd International Scientific Conference
Agrarian perspectives (pp. 155-163). Prague: Czech University Life Sciences Prague.
Molhanec, M. (2011). Some Reasoning Behind Conceptual Normalisation. In Information Systems
Development: Business Systems and Services (pp. 517-525). Berlin: Springer.
OMG. (2008). Semantics of Business Vocabulary and Rules (SBVR) Specification, v 1.0 (formal/0801-02). Retrieved from http://doc.omg.org/formal/08-01-02.pdf.
OpenCASE Tool. (2014). Retrieved from http://www.opencase.net.
Pergl, R., & Tůma, J. (2012). OpenCASE–a tool for ontology-centred conceptual modelling. In
Advanced Information Systems Engineering Workshops (pp. 511-518). Berlin: Springer
Heidelberg.
Polák, J., Merunka, V. & Carda, A. (2003). Umění systémového návrhu: objektové orientovaná
tvorba informačních systémů pomocí původní metody BORM. Prague: Grada.
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modelling Language Reference
Manual. Massachusetts: Addison-Wesley Longman.
Šplíchal, P., Pergl, R. & Pícka, M. (2011) BORM Model Transformation. Systémová integrace, 18(2),
112-123.
Šplíchal, P. (2011) Model Transformation. In 20th International Scientific Conference Agrarian
perspectives (pp. 423-430). Prague: Czech University of Life Sciences.
Steinberg, D., Budinsky, F., Merks, E. & Paternostro, M. (2008). EMF: eclipse modelling
framework. New York: Pearson Education.
Struska Z. & Merunka V. (2007) BORM points new concept proposal of complexity estimation
method. In 9th International Conference on Enterprise Information Systems (pp. 580-586).
Berlin: Springer.
Struska Z. & Pergl R. (2009) BORM-points: Introduction and Results of Practical Testing. In Lecture
notes in business information processing: Enterprise information systems (pp. 590-599).
Berlin: Springer.
Wadler, P. (1992). The essence of functional programming, In 19th ACM SIGPLAN-SIGACT
symposium on Principles of programming languages (pp. 1-14). New York: ACM.
42
43
DOI: 10.18267/j.aip.59
Peer-reviewed paper
Context Sources and their Processing
in Company Security
Libor Měsíček*
Abstract
This article deals with the problem of critical employees’ oversight. In the article is proposed
set of processes which can with cooperation with Data Mining and Ambient Intelligence,
in some cases, predict behaviour and movement of monitored objects/people based
on reasoned context from set of different sources. The difference between prediction and
observed reality can be evaluated and based on rules and gathered information about
context can be taken action to prevent security breach and damages to the company. At the
end a case scenario is presented which demonstrate behaviour of the system and possible
options how the system can prevent damages to assets.
Keywords: Ambient Intelligence, Context, Security, Process, Surveillance, Security
Management.
1
Introduction
Threats to the security of a company are as old as companies. In the past there were mainly
threats in the form of physical document theft or destruction, information smuggling or selling
to competitors or just a simple break into companies’ building and stealing or damaging
valuable equipment. The number of ways how to interact with the company to harm its
position nowadays is much wider. Almost every company has to be connected to the Internet,
has local network and servers with sensitive data which must be protected by encryption and
in case of a security problem set of pre-set countermeasures.
Ko et al. (2011) pointed out that the weakest part of this chain remains human factor. We can
observe similar situation in air traffic, simple data insertion by some office clerks or system
administrators using simple passwords into critical company systems, the percentage
of wrong action or entries is much higher than success rate of a modern aviation systems and
OCR systems. Other connected problem is ontology linked with Ambient Intelligence,
generation of device specific user interfaces, automatic code generation, application
adaptation and code mobility (Preuveneers et al., 2004).
The main goal of this article is to demonstrate concept of combination of different sources
of information to be able to identify context and also security level of an employee and
according to this level take appropriate action. Presented model suggests a way how to use
already widely spread technologies combined with new techniques to detect unusual
behaviour of valuable employee with great importance to the company. The reason why
*
Department of Informatics, Faculty of Science, J. E. Purkinje University,
Ceske mladeze 8, 400 96 Usti nad Labem, Czech Republic
44
should this be done is to identify irregularities in the employees’ actions and link them with
possible security threats. This set of processes could be also used to evaluate behaviour of
wider group of employees in order to increase level of security in the company and its ability
to defend critical systems. Context aware devices and systems can provide additional layer of
security and can add new function into the system.
2
Materials and Methods
Method of analysis and synthesis is mainly used in this article accompanied by Data Mining
and Ambient Intelligence. Context in human-computer interaction can be defined from
several points of view (e.g. Positivist and phenomenal, location awareness of a device, etc.).
Daunish (2004, pp. 19-30) deals with different perspectives related with context definitions.
In this article, context will be used as awareness of intentions, plans, situation of a user of the
system and his or her needs, probable situation and limitations (e.g. geographical, physical)
based on his or her current location and other limitations. Urban theory and use of sensors are
described in (Rabari & Storper, 2015).
The idea of analysing user history and creating his or her profile based on it and use them to
provide personalized services is mentioned in (Hong, 2009). Proposed processes consist
of three steps. First step of the process is data and information collection from different
sources. These sources can differ according to the needs of company and purpose of the
surveillance. Second step is data evaluation, searching for patterns and prediction of
behaviour and movement through space. Last step is comparison of created patterns and
information which comes from information sources and searching for important deviation
from standard and probable behaviour.
3
Results and Discussion
To be able to construct intelligent system which could detect patterns of the employee it is
necessary to have sufficient amount of information from the environment, public information
systems or employees’ work schedule.
Table 1 shows list of important information inputs used in particular model scenario. Also,
inputs connected with Intrusion Detection Systems could be used (Vokorokos, Balas &
Mados, 2012). We can see that most of the inputs are linked to companies’ environment.
Information and metadata from the companies’ information systems is important and still
underestimated source of knowledge which can be used for several purposes Mesicek and
Svoboda (2012).
45
Information
source
Typical delay
of detection
ID
Input name
Description
1
Entrance
system
Systems based on NFC or RFID Internal system < 1second
technology used for identification of of a company
presence of employees ID Card.
2
Surveillance
cameras
Processed information from surveillance Internal system <1 second
cameras around and inside companies’ of a company
buildings with car ID recognition.
3
Public
transport
information
system
Information about delays of public Public
transportation system and traffic jams information
and alternative roads.
systems API
4
Employees’
work
schedule
Employees work schedule with planned Internal system N/A
meetings, vacations and other important of a company
events.
5
Phone
Information about position of employees Internal system <1 minute
of a company /
’ phone, use of auto check-in.
API of a third
party application
6
Facial
expression
analysis
Surveillance cameras can not only detect Internal system <1 minute
presence of a person but also recognise of a company
mood of a person in our case fear or pain
(Xu et. al., 2014).
< 5 minutes
Tab. 1. List of inputs used in the scenario to establish context of employees’ behaviour and selected objects.
Source Author.
Information from these sources is transformed in process shown on Figure 1. Difficulty
of transformation differs based on particular type of information source. Information from
public sources about delays of trains, traffic jams, etc. can be usually use as is, but pictures
from cameras must be processed by specialized software and methods (Xu et. al., 2014), after
that the output can be used to identify required parameters, e.g. presence of car owned by
employee or a human face expression.
46
Beginning of data
collection
Required
recognized
values
Entrance system
Surveillance
camera
Recognition process
of selected
parameters
Transformation of
inputs to structured
database
Identified
objects
Information
about object
position in
environment
and time
Public transport
information
system
Employees'
work
schedule
Phone
Information
about position of
the phone
Data collection
finished
Fig. 1. Process of inputs procession and insertion to object time database. Source Author.
In the database of objects we must keep at least information about object ID, name, position,
time, category of record (whether is it estimated position, e.g. planned meeting of the
employee next week at a restaurant or position of the object in the past or present).
Once is available information where selected object were, where they are and where some
of them should be in the future it is possible to use Data Mining and Ambient Intelligence to
reason current security status of the employee.
Result of this step should provide information about the usual behavior, its probability
distribution in time, patterns of movement and interaction with companies’ information
systems. Figure 2 briefly describes process of this reasoning.
47
Beginning of the
process
Information
about object
position in
environment
and time
Data mining
processes
Usual
patterns of
object
movement
Data mining process
and ambient
intelligence
Prediction of
object
movement
Process finished
Fig. 2. Use of gathered information for reasoning patterns and prediction of future movement. Source Author.
Example of the output should be information that employee arrives to work by his car on
Mondays between 8:35 and 8:45 with probability of 0.7. When there is traffic jam at
particular part of his route from home he will arrive with 15 minutes delay with probability of
0.6. On Tuesdays he usually uses a train because of regular heavy jams and the train is usually
five minutes delayed on arrival (but we can use Public information system with information
about current delay of used train), then he has to walk for five minutes, so on Tuesdays his
probable arrival is from 8:45 to 8:50 with 0.8 probability, but if he has any planned work
meeting in the city center he will arrive after the meeting is finished (this can be checked in
his calendar and scheduled meetings).
Once we have information about usual patterns of movement and interaction of selected
employee we can use it for prediction of his or her behavior, and the most importantly
potentially dangerous situations.
The success rate of the prediction should be measured in short- and mid-term.
𝑠𝑢𝑐𝑐𝑒𝑠𝑠 𝑟𝑎𝑡𝑒 =
𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑢𝑐𝑐𝑒𝑠𝑠𝑓𝑢𝑙𝑙 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠
× 100%
𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑙𝑙 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛
(1)
We can easily find out that some employees keep their routines almost perfectly, but some
behave unexpectedly and this way of security oversight cannot be applied on them (this group
has usually free work hours or can work from remote places).
For group of employees which tend to behave according model prediction is possible to use
security level setting according how they behave in real world and what is the usual behavior.
Process of comparison is described at Figure 3.
48
Information
about object
position in
environment
and time
Usual
patterns of
object
movement
Beginning of the
process
Security
threat
representing
the
employee
Comparison of usual
and actual
movement of object
Prediction of
object
movement
Is the threat
higher than base
value?
Yes
Start security
countermeasures
and limit user rights
No
Process finished
Fig. 3. Comparison process of predicted and actual behavior and security threat level evaluation of current
employee. Source Author.
In case there is unusual movement, actions or difference between detected positions
of companies’ employee and his or her phone and ID card there should be started security
countermeasures to prevent damages caused by possible, and in this case probable, stolen or
forgotten phone and ID card. For example, there is information from the phone that it’s
moving along the train tracks but the employee should have left the train several train stops
before these stations and his ID card was used recently to open his office. Conclusion of the
system should be that either the employee is in the train and his ID card was stolen or the
employee is in his office and he just lost his phone. Neither of these options is safe. The first
one requires lock down of all endangered systems and presence of security guard or police in
employees’ office to detain possible burglar. The second described option requires silent
remote locking and encrypting the content of the phone and preventive suspension of access
to the information system. Set of sources of information and reaction can be of course much
wider, it depends on companies’ needs, requirements and options.
4
Conclusion
Context has become one of important parts of modern information systems. People use smart
devices (e.g. power cords, fridge, watch, wrist band or mobile phone whit shared calendar and
personal data) and some of them carry everywhere they go. We are observed by cameras,
have RFID chips in our wallets and this all could be used as relatively cheap source of
information about our behaviour and plans. Once we have these sources we can apply
Ambient Intelligence and other methods and tools to reason probable behaviour of one
specific person. Purpose of this article is to introduce concept of resources combination and
its use for companies’ security improvement.
Presented processes show example how to harvest selected sources of information and how to
use them to prevent unwanted situation regarding companies’ security. It is important to
49
detect undesired situations to improve critical companies’ systems level of security and apply
sufficient countermeasures.
Brief example showed one possible scenario how could be used detection of situation context.
Presented scenario shows that it is feasible to reason information about employees based on
mix of available data sources. After the information is compared with behaviour patterns,
probability distribution, predictions etc. with certain reliability could be possible to say what
the security threat the employee and his or her authorization rights could be.
Company which handles sensitive information with restricted access should implement
algorithms which are able to track key employees (with theirs knowledge and agreement) and
in case the company detects some abnormality (e.g. impossible speed of movement,
unexplained access to dozens customers records, etc.) the action must be taken to prevent any
additional damage.
References
Dourish, P. (2004). What we talk about when we talk about context. Personal and Ubiquitous
Computing, 8(1), 19-30.
Hong, JY., Suh, EH., Kim, J., & Kim, S. (2009). Context-aware system for proactive personalized
service based on context history. Expert Systems with Applications, 36(4), 7448-7457.
Ko, H., Marrieros, G., An, K., Vale, Z. Kim, T., & Choi, J. (2011). Contexts-Management Strategy
with Security Consideration in Urban Computing based on urban design. In 2011 Fifth
International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing
(pp.65-72). Seoul: Korean Bible University.
Mesicek, L., & Svoboda, J. (2012). Composition of ICT Project Teams from Social Network Analysis
Point of View. In Proceedings of the 13th European Conference on Knowledge Management (pp.
1462-1470). Cartagena.
Preuveneers, D., Van den Bergh, J., Wagelaar, D., Georges, A., Rigole, P., Clerckx, T., Berbers,
Y., Coninx, K., Jonckers, V., De Bosschere, K. (2004). Towards an extensible context
ontology for ambient intelligence. In Proceedings on Ambient Intelligence, (pp. 148-159).
Eindhoven: Springer.
Rabari, C., & Storper, M. (2015). The digital skin of cities: urban theory and research in the age of the
sensored and metered city, ubiquitous computing and big data. Cambridge Journal of Regions
Economy and Society, 8(1) pp. 27-42.
Vokorokos, L., Balas, A., & Mados, B. (2012). Intrusion Detection Architecture Utilizing Graphics
Processors. Acta Informatica Pragensia, 1(1), 50-59. doi: 10.18267/j.aip.5
Xu, C., Hu, Q. H., Xu, G. Q., & Feng, Z. Y. (2014). An approach to facial expression analysis with
multi-model interactions. International Journal of Computer Mathematics, 91(11), 2329-2340.
50
51
DOI: 10.18267/j.aip.60
Peer-reviewed paper
Hodnocení Web GIS aplikací a nástrojů
pro jejich tvorbu pomocí AHP
Evaluation of Web GIS Applications
and their Development Tools Using AHP
Miroslav Pásler*
Abstrakt
Analyticko-hierarchický proces (AHP) je široce využívaným přístupem v oblasti
rozhodovacích procesů, hodnocení a skupinovém rozhodování. Je oblíben zejména pro svá
specifika související s konzistentností hodnotitelových rozhodnutí a přístupu k dekompozici
daného problému. AHP a jeho formy jsou také využívány v oblasti geografických
informačních systémů (GIS) a to při řešení mnoha různých problémů. V tomto článku je AHP
použit jako metoda výběru možných hodnotících kritérií a stanovení vah kritérií pro
hodnocení Web GIS aplikací interaktivně prezentujících zájmové body a nástrojů sloužících
k tvorbě tohoto druhu Web GIS aplikací. V rámci výzkumu byly stanoveny váhy kritérií
dotazováním hodnotitelů rozdělených do kategorií dle jejich vztahu k tvorbě a využití Web
GIS aplikací. Proces hodnocení je vztažen ke konkrétní Web GIS mapové aplikaci. Článek
konfrontuje výsledky šetření s výstupy předešlých prací hledajících nejvhodnější nástroj pro
tvorbu podobných Web GIS aplikací. Součástí článku je také zhodnocení konzistentnosti
rozhodnutí hodnotitelů vzhledem ke stanoveným kategoriím.
Klíčová slova: AHP, hodnocení, konzistentnost, rozhodování, Web GIS.
Abstract
The Analytic hierarchy process (AHP) is a widely used approach in the field of decision
making, evaluation and group decision making processes. It is popular especially for its
specifics related to consistency of an evaluator's decisions and an approach
to decomposition of a certain problem. AHP and its forms are also exploited in the area of
geographic information systems (GIS) while solving variety of multiple problems. In this
article the role of AHP is a method of determining a set of criteria and weights of the criteria
of evaluating Web GIS applications which are presenting points of interest and of evaluating
the development tools. Within the research weights of criteria were defined by interviewing
evaluators divided into categories according to their relationships to creation and usage
of Web GIS applications. The evaluation process focuses on a particular Web GIS map
*
Institute of System Engineering and Informatics, Faculty of Economics and Administration, University of Pardubice,
Studentská 95, 532 10 Pardubice, Czech Republic
52
presentation. The article compares results of this research with results of previous works
which were searching for the best development tool of similar Web GIS applications. This
article also includes an assessment of evaluators' decision making consistency according
to their categories.
Keywords: AHP, Web GIS, Evaluation, Decision making, Consistency.
1 Úvod
Článek se zabývá používáním agilních metodik ve světě a v České republice. Základ agilních
metodik tvoří principy a hodnoty, které byly definovány v roce 2001 v agilním manifestu
(Beck et al., 2001). Od té doby vznikají různé agilní metodiky, které jsou zaměřeny na
specifické oblasti. Jako příklad lze uvést nejrozšířenější metodiku Scrum, která se soustředí na
řízení agilního vývoje softwaru a dále metodiku Extrémního programování, která se soustředí
na techniky vývoje softwaru. Agilní metodiky byly zprvu vnímány velice skepticky, protože
byly v rozporu s dlouhodobě vyvíjenými tradičními (rigorózními) metodikami, které jsou
založeny na detailním plánování a robustním vývojovém modelu.
2 Úvod
Od doby, kdy byl na přelomu sedmdesátých a osmdesátých let dvacátého století profesorem
Thomasem L. Saatym představen princip analyticko-hierarchického procesu (AHP), našla tato
metoda široké uplatnění napříč mnoha obory lidské činnosti. Metodika AHP je
neodmyslitelně spjata s oblastí rozhodování a rozhodovacích procesů, konkrétně pak s multikriteriálním rozhodováním, tedy procesem, kdy je vybírána nejlepší alternativa na základě
dvou, ale zpravidla více, hodnotících nebo posuzovacích kritérií. Tato specifikace vede k ne
příliš překvapujícímu faktu, že metoda AHP je používána všude tam, kde je vyžadován
specifický, metodický a systémový přístup k rozhodování. Výjimkou z oblasti uplatnění AHP
nejsou ani geografické informační systémy (GIS).
Tento článek navazuje na předchozí práce autora (uvedeno v následující kapitole) týkající se
výběru nejvhodnějšího nástroje pro tvorbu Web GIS aplikací. Výzkum je prováděn na
konkrétní modelové aplikaci interaktivně prezentující rozmístění kontejnerů na recyklovaný
odpad v Pardubicích. Součástí aplikace jsou funkce, vlastnosti a možnosti vybrané tak, aby
porovnání jejich významu bylo zobecnitelné na Web GIS aplikace obdobného charakteru,
tedy takové, které prezentují bodové vrstvy v rámci zájmového území. Příkladem takových
aplikací mohou být interaktivní mapy zastávek autobusů (například s možností zobrazení
jízdního řádu), restauračních zařízení (například včetně otevírací doby), schránek geokeší
apod. Zmíněná aplikace prezentující kontejnery na recyklovaný odpad byla vytvořena ve
třech vybraných nástrojích pro tvorbu Web GIS aplikací. Konkrétně se jednalo o Google
Maps API, ArcGIS API a Mapy.cz API (ve všech případech je myšleno rozhraní pro
JavaScript). Ve zmíněných předchozích pracích byla váha stanovených kritéria určena
metodou vzájemného kvantitativního párového srovnání (Saatyho metodou). Stejně tak
ohodnocení alternativ (tedy jednotlivých nástrojů) bylo provedeno touto metodou. V obou
případech bylo ohodnocení provedeno autorem. Tento fakt je žádoucí u ohodnocení alternativ
(jednotlivých nástrojů), kde u některých kritérií je posouzení ze strany autora aplikace jedinou
možností. Jinak je tomu u stanovení vah jednotlivých kritérií, kdy se zdá vhodné, aby byl
zohledněn úsudek většího počtu lidí. Právě použití metodiky AHP ke sběru a vyhodnocení
priorit uživatelů i odborníků si klade za cíl tento příspěvek. V rámci sběru dat, byli
53
hodnotitelé rozděleni do dvou skupin dle jejich přístupu k vývoji a využívání Web GIS
aplikací, přičemž metodika hodnocení pomocí párového srovnání kritérií byla zachována.
V článku jsou výsledky hodnocení konfrontovány s výstupy zmíněných předchozích prací.
Z důvodů podrobněji zmíněných dále byl přehodnocen výčet posuzovaných kritérií.
Metoda AHP mimo jiné umožňuje stanovovat míru nekonzistence hodnotitelových
rozhodnutí. Jedná se o významné specifikum této metody (a příbuzných popř. odvozených
metod), jež nese určitou informaci o hodnotitelově přístupu, charakteru rozhodování, ale
může mnoho napovědět i o rozložení kritérií v rámci hierarchického procesu. Výstupní
hodnota tohoto ukazatele je v rámci práce také analyzována a to s ohledem na zvolené
kategorie hodnotitelů.
Rešerše a výzkumné metody
3
Jak bylo zmíněno v úvodu této práce, analyticko hierarchický proces (AHP) byl formulován
Thomasem L. Saatym v knize The Analytic Hierarchy Process: Planning, Priority Setting,
Resource Allocation (Saaty, 1980). Od té doby byl princip AHP rozšiřován, upravován,
vysvětlován a aplikován mnoha autory včetně samotného T. L. Saatyho. Jedná se o metodiku
hojně citovanou a využívanou, jak dokládá například práce Analytic hierarchy process:
An overview of applications (Vaydia, 2006), která mapuje využití AHP napříč vědními
disciplínami a obory lidské činnosti. Relevanci, vzhledem k tomuto příspěvku, mají zejména
ta využití AHP, která aplikují rozhodovací přístup AHP v geografických informačních
systémech (GIS). Protože samotná problematika GIS je značně obsáhlá, i zde lze nalézt velké
množství aplikací AHP a to zejména v souvislosti s hodnocením. Příkladem mohou být
publikace v Computers and Electronics in Agriculture věnované zejména hodnocení využití
krajiny a půdy (Akinci et al., 2013). Bohaté je také využití přímo v geoinformatice a Web GIS
a to jak pro skupinové hodnocení tak jako součást geograficky orientovaných systémů pro
podporu rozhodování (Karnatak et al., 2007).
Problematice Web GIS se obsáhle a uceleně věnuje především práce Web GIS: Principles and
Applications (Fu, 2011), kde jsou popsány základní možnosti a principy vizualizace
geografických informací v prostředí webu, jsou zde uvedeny základní přístupy a architektury
Web GIS aplikací, jejich souvislost s architekturou klient-sever a možnosti využití Web GIS
s ohledem na moderní trendy vývoje prostředí internetu. Autoři definují pojem Web GIS jako:
„jakýkoli GIS, který používá webové technologie ke komunikaci mezi komponentami.“
Praktické využití Web GIS se vzhledem ke své povaze odehrává spíše v rovině aplikační než
vědecké, přesto lze najít práce věnující se především moderním trendům ve vývoji Web GIS
aplikací, jak je tomu například v pracích S. Di Martina (Di Martino et al., 2007).
Princip metody AHP je vyčerpávajícím způsobem popsán v mnoha původních pracích, je tedy
nad rámec tohoto příspěvku se do větší hloubky věnovat jeho podstatě. Nicméně základní
seznámení s metodikou vzhledem k řešenému problému je žádoucí. Následující popis
metodiky AHP a jeho základních principů vychází zejména z práce T. L Saatyho Decision
Making for Leaders publikované v roce 1999 (Saaty, 1999), která svým rozsahem umožňuje
podrobný popis metody zejména se zaměřením na princip dekompozice v hierarchii problému
a konkrétní příklady z praktického využití metodiky.
Jestliže v prvním kroku bude abstrahováno od matematické roviny AHP, nabízí tato metoda
postup dekompozice rozhodovacího problému do několika úrovní. Dle Saatyho (Saaty, 1999,
s. 21) nejvyšší úroveň hierarchie představuje vlastní cíl rozhodování (výběru), tedy nejlepší
alternativu. V druhé úrovni se nacházejí hodnoticí kritéria, která se mohou hierarchicky
rozpadat na sub-kritéria. Nejnižší úroveň hierarchického rozložení rozhodovacího problému
54
dle AHP představují vlastní alternativy, mezi kterými probíhá výběr. Vzhledem
k předchozímu popisu si lze celou hierarchii graficky představit jako hranově ohodnocený
orientovaný graf, kde jednotlivé uzly představují pojmenované alternativy, kritéria a cíl,
ohodnocení hran mezi kritérii a cílem představují váhy jednotlivých kritérií a ohodnocení hran
mezi alternativami a kritérii (předpokládejme všeobecný případ, kdy je každá alternativa
hodnocena vzhledem ke každému kritériu) představuje vlastní hodnocení daných alternativ
k příslušným kritériím. Orientaci hran lze chápat jako reprezentaci procesu výběru, tedy jejich
orientace bude směřovat od nejnižší úrovně (zvolených alternativ) směrem k nejvyšší
(konkrétní nejlepší alternativě). Vlastní hierarchická struktura rozhodovacího problému
řešeného v tomto příspěvku je graficky zpracována v následující kapitole.
Matematická podstata AHP v její základní podobě byla plně rozvinuta samotným Saatym a je
dobře popsána například v jeho příspěvku z roku 1987 (Saaty, 1987). Celý princip výběru
vyhází z volby nejlepší alternativy A* z množiny alternativ A = {A1, A2, ...,An} dle
následujícího vztahu:
𝐴∗ = 𝑀𝐴𝑋𝑗 {𝐴𝑗 }
(1)
kde Aj představuje ohodnocení j-té alternativy dle vztahu:
𝐴𝑗 = {𝑤1 , 𝑤2 , … , 𝑤𝑚 } ∙ {𝑣1𝑗 , 𝑣2𝑗 , … , 𝑣𝑚𝑗 }
(2)
Ve vztahu (2) představuje vektor w = {w1, w2 , …, wm}normované váhy reprezentující
relativní důležitost jednotlivých kritérií a tedy ohodnocení hran mezi nejvyšší a prostřední
vrstvou hierarchie. Druhý vektor ve vztahu (2) představuje ohodnocení j-té alternativy dle
daných kritérií. Ohodnocení alternativ dle kritérií tedy tvoří matici V = {v11, v12, …, v1n; v21,
v22, …, v2n; …; vm1, vm2 , …vmn} pro m kritérií a n alternativ.
Klíčovou roli v postupu navrženém Saatym (Saaty, 1987) hraje sestavení matice párového
kvantitativního srovnání (Saatyho matice). Ta je sestavována vždy pro prvky ze stejné
hierarchické úrovně. Slouží tedy pro stanovení vah kritérií a k ohodnocení alternativ dle
jednotlivých kritérií. Pro vlastní ohodnocení alternativ je tato metoda vhodná zejména
v případech kvalitativního hodnocení alternativ, pro kvantitativní ohodnocení (například
pokud je kritériem cena, výkon apod.) není nezbytná. Saatyho matice pro m prvků má velikost
mxm a představuje kvantitativně vyjádřenou významnost každého prvku vůči každému. Sám
Saaty navrhl škálu od jedné do devíti, kdy hodnota jedna představuje shodnou významnost
obou prvků (například kritéria C1 a C2) a hodnota devět představuje maximální důležitost
jednoho prvku vůči druhému. Z uvedených faktů a za předpokladu symetričnosti porovnání
je Saatyho matice tvořena čísly od jedné do devíti a jejich reciprokými hodnotami, přičemž
hlavní diagonála (kde je porovnáván význam prvku samého se sebou) je tvořena jedničkami.
Hypoteticky tak stačí získat hodnoty nad diagonálou pro vytvoření celé matice. Z toho lze
odvodit vzájemný vztah mezi počtem porovnávaných prvků m a počtem nutných srovnání
k jako:
𝑚(𝑚 − 1)
(3)
2
Výpočet vlastního ohodnocení pro jednotlivé prvky (ať už jsou to váhy kritérií nebo
ohodnocení alternativ) vychází z určení nejvyššího vlastního čísla sestavené Saatyho matice.
Metodik výpočtu vah však existuje více a výsledky, které dávají, se liší jen minimálně.
Vhodným kompromisem mezi přesností a jednoduchostí výpočtu je použití metod vycházející
z geometrického průměru prvků v řádcích Saatyho matice (Ishizaka, 2006).
𝑘=
55
Jedno ze specifik metody AHP vychází ze Saatyho slov o tom, že lidé jsou ve svých
rozhodnutích spíše nekonzistentní (Saaty, 1999). Proto metodika AHP a určení ohodnocení
pomocí párového srovnání nejen že umožňuje existenci nekonzistence v rozhodnutích, ale
přímo dokáže tuto nekonzistentnost kvantifikovat pomocí konzistenčního indexu (consistency
index – CI) a konzistenčního poměru (consistency ratio – CR). Rozhodnutí o tom, jaká míra
nekonzistence je přijatelná, je vždy na autorovi příslušné studie. Saaty považoval za
rozumnou hranici hodnotu konzistenčního poměru 0,1 (10%). V případech, kdy konzistenční
poměr vyjde vyšší, je na zvážení přehodnotit některé soudy (Saaty, 1987).
Zejména z praktického hlediska, ať již s ohledem na případnou výpočetní náročnost nebo
s ohledem na náročnost na hodnotitele a složitost zpracování výsledků, hraje velmi důležitou
roli počet párových srovnání vyjádřených vztahem (3). Je třeba vzít v úvahu, že pokud je
použit systém AHP pro skupinová rozhodování nebo hodnocení, může mít vysoký počet
srovnání několik negativních průvodních jevů odvislých od situace. Při rozhodování
v krizových situacích, kdy hraje významnou roli doba rozhodování, je počet srovnání hlavním
faktorem, který degraduje AHP metodiku pro použití v této oblasti. Při použití AHP
v hodnocení může mít vysoký počet srovnání negativní dopad na hodnotitelova rozhodnutí
zejména v souvislosti s konzistencí, protože udržet konzistentní odpovědi pro velký počet
srovnání je logicky těžší a to i za předpokladu, že hodnocení pomocí konzistenčního poměru
zohledňuje počet srovnávaných prvků. Vzhledem k uvedeným argumentům je vhodné při
větším počtu kritérií zvážit některou z možností, jak redukovat počet párových srovnání.
Pakliže nebudeme uvažovat možnost nahrazení párového srovnání některou alternativní
metodou stanovení vah kritérií (například některou z přímých metod) ani možnost
predikování hodnotitelových rozhodnutí, jeví se jako nejrozumnější použití dekompozice
množiny kritérií do skupin, tak aby byla vytvořena kritéria a sub-kritéria, kdy jsou vždy
párově srovnána pouze sub-kritéria v rámci jim nadřazeného kritéria a poté kritéria mezi
sebou. Počet párových srovnání k je tak redukován dle následujícího vztahu:
𝑙
𝑙(𝑙 − 1)
𝑚𝑖 (𝑚𝑖 − 1)
𝑘=
+∑
2
2
(4)
𝑖=1
pokud je m sub-kritérií v i-tém kritériu z l kritérií. To tedy znamená, že například pro 10 subkritérií rozdělených do dvou skupin po pěti je redukován počet srovnání dle vztahů (3) a (5)
ze 45 na 21. Ne vždy však logika úlohy dovoluje dekomponovat kritéria na sub-kritéria.
Pro sběr dat a vyhodnocování dílčích výsledků za použití metody AHP byl v této práci použit
software Transparentchoice. Jedná se o webovou aplikaci umožňující tvůrci projektu vytvořit
hierarchii rozhodovacího problému tj. určit cíl rozhodování, stanovit kritéria a sub-kritéria,
stanovit alternativy a přidat libovolné množství hodnotitelů. U každého hodnotitele je možné
nastavit, zda má hodnotit pouze kritéria nebo porovnávat i alternativy. Hodnocení je
prováděno dotazováním hodnotitele dle párového srovnávání, kdy vybírá vždy významnost na
škále 1-9 resp. 1-1/9. Díky faktu, že se jedná o webovou aplikaci lze proces hodnocení
distribuovat paralelně mezi velký počet hodnotitelů a značně tak urychlit sběr dat. Výsledky
hodnocení lze po té zpracovat dle skupin hodnotitelů.
Řešení a výsledky
4
4.1
Charakteristika řešeného problému
V rámci předcházejících prací na toto téma (Pásler, 2014a; Pásler, 2014b) byla řešena
problematika výběru nejvhodnějšího nástoroje na tvorbu určitého druhu Web GIS aplikací.
56
Nástroje byly hodnoceny na základě tvorby konkrétní Web GIS aplikace prezentující
rozmístění kontejnerů na recyklovaný odpad v Pardubicích. Kritéria hodnocení nástrojů byla
zvolena tak, aby výběr mohl být zobecněn na použití daného nástroje na tvorbu Web GIS
aplikací obdobného charakteru tj. prezentující bodové vrstvy v rámci zájmového území.
Hodnocení nástrojů včetně stanovení vah kritérií v předchozích pracích bylo provedeno
autorem. Cílem práce prezentované v tomto příspěvku je provedení stejného hodnocení ze
strany uživatelů aplikací tohoto charakteru a ze strany potenciálních tvůrců Web GIS aplikací
zmíněného charakteru. V rámci tohoto jsou konfrontovány výsledky hodnocení skupin
hodnotitelů s výsledky hodnocení v předchozích pracích. Ze strany hodnotitelů jsou párově
porovnávána pouze kritéria hodnocení a příslušná sub-kritéria. Samotné hodnocení alternativ
tedy jednotlivých nástrojů vzhledem ke kritériím je stejně jako v předchozích pracích
provedeno autorem. Některá kritéria jsou takového charakteru, že by hodnocení skupinou
osob postrádalo smysl.
Zejména vzhledem k faktu, že byla skupina hodnotitelů rozdělena na dvě pod skupiny tak,
aby byla oddělena skupina potenciálních tvůrců Web GIS aplikací od skupiny koncových
uživatelů, byla přepracována hierarchie problému. Některá hodnotící kritéria byla odebrána
nebo upravena. Dále vzhledem k potenciálně velkému počtu vzájemných porovnání (viz
předchozí kapitola) byla hodnotící kritéria zařazena do dvou skupin tak, že první skupina
kritérií má předpokládanou vysokou váhu pro koncové uživatele a druhá skupina pro
potenciální tvůrce aplikací. Při použití tohoto postupu se ukazuje jako velká výhoda metoda
kvantitativního porovnání, která umožňuje každému hodnotiteli na škále 1-9 posoudit jak moc
se cítí být koncovým uživatelem v kontrastu s tím, jak moc se cítí být potenciálním tvůrcem
Web GIS aplikací a to bez ohledu na to, do jaké ze dvou zmíněných skupin byl hodnotitel
předem zařazen.
4.2
Charakteristika skupin hodnotitelů
Jak bylo nastíněno v předchozím textu, hodnotitelé byli rozděleni do dvou skupin dle povahy
jejich zkušeností s Web GIS aplikacemi. V dalším textu bude skupina uživatelů bez přímých
zkušeností s tvorbou Web GIS aplikací označována jako skupina koncoví uživatelé. Tato
skupina je tvořena převážně studenty prvních a druhých ročníků bakalářského studia na
Univerzitě Pardubice a lidmi z řad širší neodborné veřejnosti. Druhou skupinu tvoří
hodnotitelé se vzděláním v oboru GIS a tvorby Web GIS aplikací. Tato skupina je převážně
tvořena studenty, kteří absolvovali předmět Služby mapových serverů, jehož součástí je
i tvorba Web GIS aplikace, a dále doktorandi a odborníci z různých pracovišť univerzit v ČR
se zkušenostmi s tvorbou Web GIS aplikací. Tato skupina je v dalším textu označována jako
vývojáři. Každá z obou skupin je tvořena 20 hodnotiteli.
4.3
Hodnotící kritéria a hierarchická struktura
Hodnotící kritéria a sub-kritéria jsou uvedena v následujícím seznamu včetně dodržené
hierarchie a stručného popisu.

Možnosti aplikace – soubor kritérií, která zajímají zejména koncového uživatele,
protože souvisejí s vlastními nástroji poskytovanými aplikací.
o Možnosti vrstev – představuje možnost zobrazení typů bodů jako samostatné
mapové vrstvy, která se dá samostatně zobrazovat nebo skrývat.
o Podkladové mapy – Představuje počet a typy použitelných (poskytovaných)
podkladových map.
57

o Rychlost – představuje průměrnou rychlost potřebnou pro odezvu aplikace na
stanovené úkony (načtení mapy, vyhledání nejbližšího zájmového bodu,
vyhledání trasy k nejbližšímu bodu).
o Vyhledání lokality – umožňuje vyhledat konkrétní lokalitu (ulici, městskou
část atp.) v rámci zájmového území.
o Vyhledání nejbližšího zájmového bodu – umožňuje nalézt nejbližší zájmový
bod daného typu ze zvoleného místa na mapě.
o Vyhledání trasy – představuje možnost vyhledání trasy k nejbližšímu
zájmovému bodu od zvoleného místa na mapě.
o Zjištění atributů – představuje možnost zobrazení atributů o vybraném bodu
zájmu.
Možnosti vývojových nástrojů – soubor kritérií, které zajímají především vývojáře,
protože souvisejí s možnostmi a způsobem práce s jednotlivými nástroji.
o Čas potřebný pro tvorbu aplikace – představuje čas, který je zhruba
potřebný pro dosažení stejného výsledku (podoby aplikace) v jednotlivých
nástrojích.
o Licenční podmínky – představují možnosti využití nástroje vzhledem
k licenčním podmínkám (zda je zdarma, opensource, za jakých omezení atp.).
o Bohatost API – představuje souhrn všech (tedy i nevyužitých) nástrojů,
možností a funkcí API daného nástroje. Jinak řečeno představuje možnosti pro
usnadnění vývoje aplikací tohoto druhu z hlediska vývojáře (předdefinované
funkce, možnosti nastavení atp.)
o Zpracování a podpora API – Představuje přehlednost, bohatost
a srozumitelnost nápovědy, tutoriálu, dokumentace atp. dále také možnosti
zpětné vazby od vývojářů, "živost" nástroje a komunity obecně atd.
Podobného popisu bylo použito i v rámci hodnocení ze strany hodnotitelů, přičemž všechna
hodnocení probíhala asistovanou formou (buď s fyzickou přítomností autora projektu, nebo
možností elektronické formy supervize) pro případ potřeby dovysvětlení nejasností v popisu
kritérií. Vzhledem k tomu, že byla kriteria hierarchicky rozdělena tímto způsobem, je dle
vztahu (4) počet párových srovnání (otázek) předložených každému hodnotiteli celkem 28
oproti 55, pokud by hierarchické rozdělení nebylo využito. Vlastní hierarchická struktura
včetně alternativ a cíle je zachycena na obrázku (Obr. 1). Graf je kreslen jako neorientovaný,
pokud by hranám měla být přiřazena orientace je nutno mít na paměti, že při tvorbě hierarchie
se postupuje od cíle přes kritéria k alternativám, ale při výběru nejlepší alternativy je orientace
obrácená.
58
Obr. 1. Hierarchická struktura problému. Zdroj: autor.
4.4
Výsledky hodnocení
Výsledné hodnocení bylo získáno pomocí nástrojů aplikace Transparentchoice, která mimo
jiné umožňuje třídění výsledků dle skupin. Dále tato aplikace umožňuje u každého
hodnotitele nastavit, zda má hodnotit pouze kritéria nebo také alternativy. V konkrétním
případě řešeném v tomto článku všech 40 hodnotitelů hodnotilo pouze kritéria, alternativy
byly stejně jako v původních pracích hodnoceny autorem. Obě skupiny hodnotitelů tedy
stanovily váhy kritérií dle svých priorit. Váhy kritérií včetně rozdělení na sub-kritéria dle
jednotlivých skupin v konfrontaci s váhami zvolenými autorem pomocí stejné metodiky
zobrazuje následující tabulka (Tab. 1).
Možnosti aplikace
Možnosti vývojových nástrojů
Možnosti vrstev
Podkladové mapy
Rychlost
Vyhledání lokality
Vyhledání nejbližšího bodu
Vyhledání trasy
Zjištění atributů
Bohatost API
Čas potřebný pro tvorbu aplikace
Licenční podmínky
Zpracování a podpora API
Autor
0,125
0,125
0,875
0,875
0,292
0,037
0,106
0,013
0,178
0,022
0,053
0,007
0,096
0,012
0,031
0,004
0,244
0,031
0,409
0,358
0,322
0,282
0,104
0,091
0,165
0,145
Koncoví uživatelé
0,800
0,800
0,200
0,200
0,048
0,038
0,090
0,072
0,138
0,110
0,198
0,158
0,188
0,150
0,215
0,172
0,123
0,098
0,250
0,050
0,250
0,050
0,250
0,050
0,250
0,050
Vývojáři
0,333
0,333
0,667
0,667
0,085
0,028
0,053
0,018
0,125
0,042
0,137
0,046
0,293
0,098
0,191
0,064
0,116
0,039
0,289
0,193
0,246
0,164
0,175
0,117
0,289
0,193
Tab. 1. Váhy kritérií dle skupin hodnotitelů. Zdroj: autor.
Jak bylo zmíněno, soubor kritérií byl oproti předchozímu hodnocení poupraven, to znamená,
že nelze dosáhnout úplného srovnání za každé jednotlivé kritérium, proto tabulka zobrazuje
jako hodnocení autora hodnocení provedené před sběrem dat od hodnotitelů, při zachování
původních priorit, ale aplikaci na nový soubor kritérií.
59
Výsledky hodnocení kritérií uvedené v tabulce (Tab. 1) ukazují, že hodnotitelé očekávaným
způsobem rozhodli o vzájemné důležitosti skupin sub-kritérií dle jejich rozdělení do skupin.
Koncoví uživatelé upřednostňují možnosti aplikace větší měrou, než upřednostňují Vývojáři
možnosti vývojových nástrojů. Určení vah je rozděleno na kategorie lokální a globální.
V rámci lokálního srovnání jsou vždy porovnávána sub-kritéria v rámci jedné kategorie
(jednoho ze dvou hlavních kritérií), u globálního srovnání je zohledněno stanovení priorit
vzhledem k hlavním kritériím. Součet lokálních vah tedy dává hodnotu jedna za každou
kategorii zvlášť, součet globálních vah dává hodnotu jedna za všechny váhy dohromady.
V tabulce (Tab. 1) jsou zvýrazněny ty hodnoty, které v dané kategorii odpovídají nejvyšším
resp. nejnižším vahám. Zde lze nalézt výrazný rozpor v prioritách jednotlivých skupin
hodnotitelů. Ještě výraznější rozpor je pak mezi původním hodnocením provedeným autorem
a skupinovým hodnocením uživatelů. Zatímco dle původního hodnocení například kritérium
Vyhledání trasy bylo ohodnoceno jako relativně nejméně významné, hodnotitelé ze skupiny
koncových uživatelů ho naopak považují za relativně nejvíce významné. Tento poznatek má
významný dopad na výsledné hodnocení nástrojů, jak je uvedeno dále.
Původní výsledek v závislosti na předchozích pracích, v nichž byly váhy kritérií stanoveny
autorem a samotný soubor hodnotících kritérií se drobně lišil od souboru použitého v této
práci, byl následovný: Google Maps API – 38,2%, ArcGIS API – 31,4%, Mapy.cz API
30,4%. Jak je z výsledků patrné, přestože rozdíl mezi jednotlivými nástroji dle původního
hodnocení nebyl příliš velký, jako nejvhodnější nástroj dle tohoto hodnocení se jeví Google
Maps API (Pásler, 2014a).
Součástí možných výstupů aplikace Transparentchoice je i grafický výstup hodnocení
alternativ. Tento výstup však není dostatečně vypovídající, protože nezobrazuje hodnocení za
jednotlivá sub-kritéria, ale pouze za kategorie jak ilustruje obrázek níže (Obr. 2).
Obr. 2. Ilustrace grafického výstupu aplikace Transparentchoice. Zdroj: autor.
Výstupy byly tedy dodatečně zpracovány za jednotlivé skupiny na základě ohodnocení
alternativ (jednotlivých nástrojů), které zobrazuje tabulka níže (Tab. 2). Ohodnocení bylo
taktéž provedeno párovým srovnáním, tudíž výsledná tabulka již zohledňuje, zda se jednalo
o kritérium maximalizačního nebo minimalizačního typu.
Možnosti vrstev
Podkladové mapy
Rychlost
Vyhledání lokality
Vyhledání nejbližšího bodu
Vyhledání trasy
Zjištění atributů
60
Google Maps API
0,33
0,30
0,46
0,14
0,33
0,47
0,33
Mapy.cz API
0,33
0,60
0,46
0,43
0,33
0,47
0,33
ArcGIS API
0,33
0,10
0,08
0,43
0,33
0,05
0,33
Bohatost API
Čas potřebný pro tvorbu aplikace
Licenční podmínky
Zpracování a podpora API
0,32
0,23
0,12
0,63
0,09
0,65
0,68
0,14
0,59
0,12
0,20
0,24
Tab. 2. Ohodnocení alternativ. Zdroj: autor.
Na základě tabulek (Tab. 1 a 2), které zachycují váhy jednotlivých kritérií dle skupin resp.
ohodnocení alternativ, byl vytvořen následující grafický výstup (Obr. 3), který zohledňuje
vliv vah na výsledné ohodnocení.
Obr. 3. Výsledné hodnocení alternativ dle vybraných skupin hodnotitelů. Zdroj: autor.
Z obrázku (Obr. 3) je patrný vliv preferencí jednotlivých skupin. U obou skupin při zachování
ohodnocení alternativ se jeví jako nejvhodnější nástroj Mapy.cz API. Nástroj ArcGIS API
z pohledu koncových uživatelů znevýhodňuje zejména vysoká priorita kritéria Vyhledání
trasy. Naopak z pohledu Vývojářů poráží Mapy.cz API Google Maps API jen velmi těsně a to
zejména díky bohatosti, zpracování a podpoře API. Výsledky procentního finálního
hodnocení jednotlivých nástrojů za obě skupiny i celkově zobrazuje následující tabulka (Tab.
3). Součástí tabulky je i výsledné hodnocení při stanovení vah kritérií autorem včetně
výsledku z dřívějšího hodnocení, kdy byl stanoven jiný set kritérií.
Původní hodnocení autorem
Současné hodnocení autorem
Hodnocení dle koncových uživatelů
Hodnocení dle vývojářů
Celkové hodnocení za obě skupiny
Google Maps API
38,2%
32,5%
33,7%
35,0%
34,1%
Mapy.cz API
30,4%
34,5%
41,7%
36,4%
39,3%
ArcGIS API
31,4%
33,0%
24,6%
28,5%
26,5%
Tab. 3. Finální hodnocení nástrojů. Zdroj: autor, (Pásler, 2014a ).
61
U obou skupin byla dosažena míra nekonzistence do 10%. Hodnota CR pro skupinu
koncových uživatelů činí 0,07, u vývojářů pak 0,06. Nízkých hodnot je dosaženo zejména
způsobem zpracování výsledků, kdy je výsledné hodnocení každého párového srovnání bráno
jako geometrický průměr. Výraznější odchylky od konzistentnosti rozhodnutí jednotlivých
hodnotitelů jsou tedy značně vyhlazeny. Použitý nástroj také umožňuje vizualizovat analýzu
citlivosti výsledků vzhledem ke změnám vah, jak ilustruje obrázek níže (Obr. 4). Z něho je
mimo jiné patrné, že se zvyšující se vahou kritéria Možnosti aplikace se zvyšuje také relativní
hodnocení alternativy Mapy.cz API.
Obr. 4. Příklad analýzy citlivosti pro kritérium Možnosti aplikace. Zdroj: autor.
5
Diskuze
Jak vyplývá z předchozího textu, využití metody AHP jde nad rámec pouhého stanovení vah
kritérií popřípadě ohodnocení alternativ. Jedná se také o metodiku, která nabízí návod jak
dekomponovat rozhodovací problém. Stanovení nové množiny hodnotících kritérií a jejich
vhodné rozdělení na sub-kritéria do dvou skupin, tak, že preference hodnotitelů je vyjádřitelná
právě přidělením vyššího hodnocení jedné ze skupin kritérií, se ukázalo jako přístup, který
přinesl v některých případech zcela odlišné výsledky oproti předchozím pracím.
V rámci práce byly hodnoceny tři vybrané nástroje pro tvorbu Web GIS aplikací. Nástrojů na
trhu existuje větší množství. Metodika hodnocení popsaná v tomto a předchozích článcích
autora je zobecnitelná v tom smyslu, že na případné ohodnocení jakéhokoli dalšího nástroje
dle uvedených kritérií lze snadno aplikovat uvedenou metodiku a zjištěné hodnoty vah
kritérií.
Vzhledem k povaze řešeného problému a jeho specifikům neexistují relevantní zdroje, s nimiž
by bylo možné konfrontovat dosažené výsledky s výjimkou předchozích prací autora
citovaných výše v textu.
Závěr
6
Hlavním cílem příspěvku bylo prezentovat zjištěné priority hodnotitelů, kteří při použití
metodiky vzájemného kvantitativního párového srovnání určovali priority kritérií hodnotících
62
nástroje pro tvorbu Web GIS aplikací. Na problematiku bylo nahlíženo jako na rozhodovací
problém, k jehož řešení byla využita metoda AHP. Jako cíl byl stanoven výběr
nejvhodnějšího nástroje a hodnotící kritéria byla hierarchicky dekomponována, tak, že
vznikly dvě skupiny sub-kritérií. Podobně hodnotitelé byli rozděleni do dvou stejně velkých
skupin dle jejich vztahu k využití a tvorbě Web GIS aplikací (koncoví uživatelé a vývojáři).
K zjištění priorit uživatelů zmíněnou metodikou bylo využito specializované webové aplikace
pro podporu více-kriteriálního rozhodování.
Zjištěné výsledky byly porovnány za jednotlivé skupiny hodnotitelů a konfrontovány
s výsledky předchozích prací. Byly zjištěny významné rozdíly v prioritách jednotlivých
skupin v rámci obou skupin kritérií i v rámci celkového ohodnocení. Výstupní priority obou
skupin se navíc liší od priorit autora, na jejichž základě bylo provedeno předchozí hodnocení.
Lze tedy říci, že stanovení důležitosti jednotlivých kritérií autorem není dostatečně
reprezentativní metoda, která by vedla k výběru nejvhodnějšího nástroje.
Na základě zmíněného byl jako nevhodnější stanoven nástroj Mapy.cz API. Jako druhý byl
zvolen nástroj Google Maps API a jako třetí nástroj ArcGIS API. Stejného výsledku bylo
dosaženo v rámci jednotlivých skupin i celkově. Jedná se o odlišný výsledek, než jaký byl
prezentován jako výstup předchozích prací. Tento fakt není chybou logiky předchozích prací,
pouze dokládá, že zjištění priorit na základě hromadného rozhodnutí vede k odlišným v tomto
případě lépe zobecnitelným výsledkům.
Akinci, H., Ozalp, A., & Turgut, B. (2013). Agricultural land use suitability analysis using GIS
and AHP technique. Computers and Electronics in Agriculture, (97), 71-82.
Di Martino, S., Ferrucci, F., Paolino, L., Sebillo, M., Vitiello, G., & Avagliano, G. (2007).
A WebML-based visual language for the development of Web GIS applications. In IEEE
Symposium on Visual Languages and Human-Centric Computing, VL/HCC 2007
(pp. 209-212). United States.
Fu, P., & Sun, J. (2011) Web GIS: Principles and Applications. Redlands: ESRI Press.
Ishizaka, A., & Lusti M. (2006). How to derive priorities in AHP: a comparative study. Central
European Journal of Operations Research, 14(4), 387-400. doi: 10.1007/s10100-006-0012-9
Karnatak, H. Ch., Sameer, S., Karamjit, B., & Roy, P. S. (2007). Multicriteria Spatial Decision
Analysis in Web GIS Environment. Geoinformatica, 11(4), 407-429.
Pásler, M. (2014a). Multi-criteria decision-making used in selection of the best web gis devlopment
tool. In System approaches´14, (pp. 51-57).
Pásler, M. (2014b). Web GIS mapová prezentace kontejnerů na recyklovaný odpad. In Mezinárodní
Masarykova konference 2014 (pp. 3288-3306).
Saaty, T. L. (1980). The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation.
New York: McGraw-Hill International Book Company.
Saaty, T. L. (1987). The Analytic Hierarchy process – what it is and how it is used. Math modelling,
9(3), 161-176.
Saaty, T. L. (1999). Decision Making for Leaders: The Analytic Hierarchy Process for Decisions
in a Complex World. Pittsburgh: RWS Publications.
Vaidya, O.S., & Kumar, S. (2006). Analytic hierarchy process: An overview of applications. European
Journal of Operational Research, 169(1), 1-29. doi: 10.1016/j.ejor.2004.04.028
63
DOI: 10.18267/j.aip.61
Peer-reviewed paper
Dopravní nehoda, systémový model
a shluková analýza v prostředí GIS
Traffic Accident, System Model and Cluster Analysis in GIS
Veronika Vlčková*, Pavel Hrubeš*
Abstrakt
Jedním z mnoha často frekventovaných témat jak běžné publicistiky, tak odborné veřejnosti
je problém dopravní nehodovosti. Tento příspěvek si vytkl za úkol nasměrovat úvahy do
zatím poměrně nezkoumaných souvislostí dopravní nehodovosti, a to s pomocí nástrojů
konstruktivní teorie systémů a jejích metod, vícerozměrné a shlukové analýzy
i geoinformačního inženýrství. Dopravní nehoda jako systémově chápaná událost je jevem
časoprostorovým, a tedy na ní lze studovat vlastnosti z pohledu technologie geografických
informačních systémů. Aplikace základních systémových principů umožňuje formulaci jejího
systémového modelu, uchopitelného geoinformačním inženýrstvím a zprostředkovávajícího
maximální využití nástrojů vícerozměrné i shlukové analýzy.
Klíčová slova: Konstruktivní teorie systémů, geoinformační
nehodovost, vícerozměrná analýza, shluková analýza.
inženýrství,
dopravní
Abstract
One of the many often frequented topics as normal journalism, so the professional public,
is the problem of traffic accidents. This article illustrates the orientation of considerations to
a less known context of accidents, with the help of constructive systems theory and its
methods, cluster analysis and geoinformation engineering. Traffic accident is reframing the
space-time, and therefore it can be to study with tools of technology of geographic
information systems. The application of system approach enabling the formulation of the
system model, grabbed by tools of geoinformation engineering and multicriterial and cluster
analysis.
Keywords: Constructive theory of systems, Geoinformation engineering, Traffic accident
rate, Multicriterial analysis, Cluster analysis.
Úvod
1
Jedním z mnoha často frekventovaných témat jak běžné publicistiky, tak i odborné veřejnosti
je dnes kromě ostatního problém dopravní nehodovosti. Nejen, že jde jak o samotnou
truchlivost samotných nehodových událostí, o zdraví a životy lidí, tak i o náklady
*
Faculty of Transportation Sciences, Czech Technical University in Prague,
Konviktská 20, 110 00 Praha 1, Czech Republic
 [email protected], [email protected]
64
– způsobená škoda, náprava škod, provozní náklady na související opatření, obchodní ztráty
aj. To na straně jedné. Na straně druhé lze sledovat úpornou snahu dopravních policistů
a jejich odborných kolegů o zvrat nepříznivého vývoje, jenže stále nic nestačí a vykazované
statistické výsledky nehovoří o žádných pozitivních změnách současného trendu.
Tento příspěvek si vytkl za úkol nasměrovat úvahy i do zatím poměrně nezkoumaných
souvislostí dopravní nehodovosti, a to s pomocí nástrojů konstruktivní teorie systémů a jejích
metod (např. Vlček, 2002 aj.). Dopravní nehoda jako systémově chápaná událost je jevem
prostorovým, a tedy na ní lze studovat vlastnosti z pohledu technologie geografických
informačních systémů (dále jen „GIS“), s jejíž podporou lze nalézat další cesty způsoby
vyhodnocování dopravní nehodovosti (př. Vlčková, 2014, Hrubeš et al., 2009 aj.).
Samotné zacílení příspěvku je vedeno snahou vymezit vhodnější rámec úvah
o vyhodnocování dopravní nehodovosti. Příspěvek si neklade za úkol tuto problematiku
konečně řešit, ale - s ohledem na její komplikovanost a komplexnost - navést na systémové
cesty jejího uspokojivého řešení. Výsledné efekty takového bádání mohou pomoci
nejrůznějším zúčastněným složkám - dopravní policii pro její každodenní praxi, expertům
a výzkumníkům při dalším rozvíjení metod klasifikace a kvalifikace dopravní nehodovosti,
v neposlední řadě i Ředitelství silnic a dálnic i krajům, obcím a dalším v rámci jejich
ekonomických analýz, případně i pojišťovnám ohledně schopnosti „správně“ vyhodnotit
závažnost a následnou výši narovnání škod, nakonec i státnímu a veřejnému aparátu pro
zlepšení práce s občany státu v kontextu pravidel chování na nejrůznějších typech komunikací
či při řešení vlivů na životní prostředí apod.
V příspěvku autoři předkládají návrh na základní koncept systémového modelu dopravní
nehody, využívající nástrojů a metod řešení technologie geografických informačních
systémů, a předznamenávající následnou aplikaci metod shlukové analýzy.
Současná praxe a vybrané nástroje
statistického hodnocení
2
2.1
Stávající způsob evidence a vyhodnocování dopravní nehodovosti
Od roku 2007, kdy se autoři tohoto příspěvku měli možnost poprvé seznámit se stavem
evidence dopravních nehod, provozované Policií ČR (dále „PČR“), se toho k letošnímu roku
moc nezměnilo. Z práce se zapůjčenými vybranými (a samozřejmě anonymizovanými) údaji
o dopravních nehodách za roky 2007 až 2013 jsou patrné následující skutečnosti:



evidenci nehody vede každá složka Integrovaného záchranného systému pro své
potřeby sama ve vlastním, s ostatními de facto nesrovnatelným formátu;
v dostupných datech PČR se objevují závažné vnitřní problémy, plynoucí opět z další
úrovně roztříštěnosti zejména dle jednotlivých správ policejních pracovišť:
o odlišný způsob formátování časových údajů (jednou středoevropský krátký
formát, jinde podle americké domluvy);
o obměny v číslování dnů v týdnu - neděle jednou jako 0, jindy jako 7 či 1;
o ne zcela stoprocentně shodné struktury vyplňovaných tabulek (rozlišnost
především pražských údajů od mimopražských) apod.;
složitosti s lokalizací nehod (nejasné způsoby zjišťování souřadnic) - dopravní
policista nemůže být stejně kvalifikován jako průměrný zeměměřič, a právě proto by
měl mít v ruce pomocnou aplikaci s potřebnou výbavou;
65


vlastní odůvodnění struktury, resp. konstrukce databáze policejně sledovaných
dopravních nehod - jde jen o položky a jejich klíčování pouze z pohledu
vyšetřovatelů nehod, zatímco jiné, ze systémově chápaného konceptu dopravní
nehody (viz dále) nijak zjišťované nejsou (vlastnosti širšího okolí nehody ve smyslu
charakteru krajiny, obvyklé, a tedy předvídatelné vzory chování příslušných komunit,
z nichž se rekrutují účastníci dopravních nehod aj.);
bohužel zásadní časová nesrovnatelnost jednotlivých ročníků dat především
z legislativních důvodů - zavedení limitu pro alarmování PČR k dopravní nehodě ve
výši 20 000,- Kč zcela znemožnilo věrohodnou, dlouhodobě profilovanou analýzu
„drobných“ dopravních nehod.
Různých nepříjemností při pokusech vyrobit časově srovnatelné soubory o dopravních
nehodách v uvedených letech je samozřejmě víc, ovšem zde uvedené jsou ty nejzávažnější,
s nimiž se autoři tohoto příspěvku setkali.
Na tomto místě, pro hrubou ilustraci způsobu evidence dopravních nehod dnes, je čistě
orientačně uveden částečný seznam položek v Tab. 1, které dopravní policista musí na místě
vyplnit (a které zároveň nejsou předmětem ochrany osobních údajů):
Pracovní
označení
p1
p36
p37
p2a
@weekda
y(p2a)
p2b
p6
p7
p8
p9
p10
p11
p12
p13a
p13b
p13c
p14
p15
p16
p17
p18
p19
p20
identifikační číslo
druh pozemní komunikace
číslo komunikace
datum ddmmrr
0=sobota, 1=neděle, 6=pátek
Pracovní
označení
p21
p22
p23
p24
p27
čas hhmm
druh nehody
druh srážky jedoucích vozidel
druh pevné překážky
charakter nehody
zavinění nehody
alkohol u viníka
hlavní příčina nehody
usmrcených
těžce zraněných
lehce zraněných
p28
p34
p35
p39
p44
p45a
p47
p48a
p49
p50a
p50b
celková škoda ve 100 Kč
druh povrchu vozovky
stav povrchu vozovky
stav komunikace
povětrnostní podmínky
viditelnost
rozhledové poměry
p51
p52
p53
p55a
p57
p58
Význam položky
Význam položky
dělení komunikace
situování nehody na komunikaci
řízení provozu
místní úprava přednosti v jízdě
specifická místa a objekty
směrové poměry
počet zúčastněných vozidel
místo dopravní nehody
druh křižující komunikace
druh vozidla
výrobní značka
rok výroby vozidla
charakteristika vozidla
smyk
vozidlo po nehodě
únik provozních nebo přepravovaných
hmot
způsob vyproštění osob z vozidla
směr jízdy nebo postavení vozidla
škoda na vozidle ve 100 Kč
kategorie řidiče
stav řidiče
vnější ovlivnění řidiče
Tab. 1. Seznam vybraných zveřejnitelných položek evidence dopravních nehod. (ýtah ze zapůjčených pracovních
podkladů Policie ČR (2008).
66
2.2
Shluková analýza nástrojem multikriteriální analýzy
dopravní nehodovosti
V kontextu současné informační exploze a snahy naplnit pojmy tzv. „informační společnosti“,
případně „znalostní společnosti“ je zcela nezbytné dokázat se v množství informací a znalostí
orientovat a být schopni získávat navazující informace a znalosti, a to nejen „prostou“
interpretací získaného informačního materiálu, ale i odvozováním a další dedukcí či indukcí
nových informací, nových znalostí (data  informace  znalosti - Vlček, 1999).
Ovšem v souvislosti s tím narůstá složitost samotného „informačního“, resp. „znalostního“
prostoru, a to jak v jeho objemu, tak v „hustotě struktury“ („houstnutí prostoru“ - Vlček,
2002) a nezbývá, než uplatňovat odpovídající metody. Roste tak potřeba účelové klasifikace,
třídění, případně typologie objektů, jimiž se konkrétní úlohy zabývají a které teprve skutečně
umožní uživatelsky srozumitelně a dále zužitkovatelně interpretovat získané výsledky.
Těmito objekty mohou být libovolné množiny hmotných předmětů, abstraktních prvků - př.
dopravních nehod. Jejich efektivní rozdělení do skupin, tříd, vhodných pro nasazení
specializovaných matematických metod je možné provést mnoha různými způsoby
a s odlišným cílem, a proto je vhodné zprvu vymezit hlavní principy přístupu k obecným
dekompozičním (třídicím, filtrovacím, klasifikačním aj.) postupům. Samotná „cluster
analysis“ je nástrojem multikriteriálních hodnocení jako takových, kdy se vyhodnocují
dostupné charakteristiky objektů jakoby současně (neměla by ovšem být zaměňována či
nahrazována hierarchickými rozhodovacími stromy a postupy regresních analýz - „data
mining“).
Základními skupinami úloh, vyžadujícími některý ze způsobů vytváření tříd prvků
(Sovjáková, Kopecký, 1989), jsou zhruba tyto:




etapy statistického zpracování množiny prvků, zde tedy dopravních nehod, s cílem
zjistit obecné statistické charakteristiky souboru příslušných dat: v tomto případě
vytvoření určitých tříd objektů = dopravních nehod umožní hledat vhodný způsob
dekompozice systému dopravní nehodovosti;
úlohy optimální regulace a plánování, kdy je třeba znát členění prvků (zde se uplatní
dopravní nehoda již ve formě systémového modelu) na různých úrovních podrobností
zkoumání v kontextu s posunem již do oblasti systémových strategií (Vlčková, 2014);
prognózování ekonomicko-sociologických situací, kde s ohledem na systémové
charakteristiky jevu dopravní nehodovosti lze dojít až k uplatnění pojmu systémové
aliance (Votruba et al., 2009);
typologie území pro potřeby úloh geografie, prostorového plánování a řízení
územního rozvoje, kdy je dopravní nehodovost chápána jako vlastnost prostředí,
v němž se řeší příslušné prostorové úlohy, tedy jde již o úlohy systémových strategií
s uplatněním nástrojů technologie GIS (Vlčková, 2013) atd.
Zatímco metody třídění rozdělují prvky do podmnožin na základě jednoho kritéria, resp.
opakovaně po jednom kritériu (hierarchické stromy), metody vícerozměrné analýzy, a tedy
i shlukování využívají celého vektoru různých ukazatelů, charakteristik současně. Tím
umožňují lépe získávat objektivnější členění vstupní množiny prvků, než při jednoduché
klasifikaci (např. Vlčková, 1983).
Shluková analýza je metoda, která pro vytvoření rozkladu, resp. pokrytí dané množiny prvků
využívá zhodnocení jejich vzájemné vzdálenosti, podobnosti, stanovené v rámci metriky
definovaného prostoru charakteristik - do tříd = shluků umisťuje ty prvky, jejichž vzdálenost,
podobnost dosahuje minimální, resp. maximální hodnoty. Jinými slovy jde o seskupování
67
prvků, které si jsou nejbližší, nejpodobnější, vykazují maximum shodných vlastností nebo
jejich konkrétních hodnot (Kopecká, 1989).
Výchozím předpokladem pro užití metody shlukové analýzy (př. Ajvazjan, 1981 nebo
Kopecká, 1989) je tedy existence N zkoumaných objektů - prvků, z nichž každý je popsán p
charakteristikami. To znamená, že pro každý objekt existuje vektor měření x obsahující p
složek takový, že:
(1)
𝐱: = {𝑥1 , 𝑥2 , 𝑥3 , … 𝑥𝑝 }
Všechny vektory 𝐱 lze shrnout do matice dat (matice vlastností, podobností) o rozměru N×p.
Samotné shlukování má za úkol zkonstruovat buď pokrytí množiny shluky v případě shluků
se společnými prvky, nebo rozklad množiny se zcela disjunktními shluky. Do shlukové
analýzy je možno zavést i metody práce s fuzzy-množinami, kdy rozhraní shluků, daná
společnými prvky, lze chápat jako úlohu zjišťování míry nejistoty náležitosti prvku do shluku.
Obecné rozhodnutí o náležitosti prvku do shluku je určeno vzájemnou vzdáleností podobností prvků, která se v širším pojetí zavádí jako míra nepodobnosti prvků. Míra
nepodobnosti prvků je nezáporná reálná funkce d, definovaná na zavedené množině všech
vektorů měření 𝐱 tak, že v daném prostoru platí:
(2)
∀ 𝑥𝑖 , 𝑥𝑗 ∃ 𝐱 × 𝐱: 𝑑(𝑥𝑖 , 𝑥𝑗 ) ∶= 𝑑(𝑥𝑗 , 𝑥𝑖 )
∀ 𝑥𝑖 ∃ 𝐱: 𝑑(𝑥𝑖 , 𝑥𝑖 ) ∶= 0
Typy úloh shlukové analýzy je možno dělit podle typu rozkladu (Vlčková, 1983; Kopecká,
1989), a to na:



nalezení rozkladu množiny prvků na n shluků, kdy n je předem známé;
nalezení rozkladu množiny prvků na n shluků, kdy n není předem známé;
vytvoření hierarchického stromu rozkladů,
a to buď divisivní, nebo aglomerativní metodou (analogicky např. systémové projektování
shory dolů či zdola nahoru).
 Hierarchické shlukování
Principem tohoto způsobu řešení nalezení shluků podobných objektů je vytvoření
hierarchického stromu rozkladů. Vzdálenost n prvků je definována jako normovaná
vzdálenost v m-rozměrném prostoru. Množina objektů se poté rozkládá tak, že na každé
úrovni rozkladů vznikají z původní množiny dvě podmnožiny, tedy na první úrovni vznikají
dva shluky, na druhé čtyři a na s-té úrovni 2s shluků.
 Frekvenční shlukování s určováním řídících vlastností shluků
V tomto postupu jsou shluky, resp. jejich jádra určována na základě zjištění tzv. řídících
vlastností shluků. Řídící vlastnost je společnou charakteristikou všech objektů shluku a pro
prvky tohoto shluku nabývá její hodnota výskytu maxima. Prvky shluku pak s sebou nesou
i celý vektor svých ostatních vlastností, jejichž souhrn vytváří doplňující popis celého shluku.
Vzájemné vyhodnocení řídících vlastností shluků a dalších přitahovaných vlastností ostatních
prvků shluku napomáhá zjištění skrytých, odvozených (tranzitivních) informací jak o prvcích,
tak i o shlucích, vyplývajících právě z kombinací vlastností prvků ve výsledném rozkladu.
 Centroidní shlukování
Principem tohoto shlukovacího postupu je úvodní stanovení center - jader shluků, k nimž
jsou ostatní prvky rozřazovány podle vybraných kritérií. Tyto centroidy, jádra shluků lze
vybírat podle určitého pravidla jako představitele příslušných skupin; např. z průběhu
distribučních funkcí nebo hustot rozložení atd.
68
Pomocí takto chápané shlukové analýzy lze podle autorů příspěvku především zkoumat
vlastnosti vybraných reálných objektů (např. úseků silničních komunikací, souborů dat
o dopravních nehodách aj.) komplexně, se zahrnutím více sledovaných charakteristik
současně. V nejpodrobněji zpracovaných analýzách lze studovat na základě vytvořených
shluků skryté - tranzitivní vlastnosti objektů shlukování, přičemž vzájemný vztah
diferencovaně hodnocených objektů není z pouhého výčtu jejich charakteristik zřejmý.
Dalším možným způsobem interpretace výsledků shlukové analýzy podle autorů může být
i např. studium analogií vývoje, kdy při tvoření shluků za určitých podmínek lze
předpokládat, že každé dva prvky v určitém shluku budou mít shodné předpoklady, a tedy i
průběh a důsledky dalšího rozvoje, podobný genetický kód, reprezentující daný abstraktní
systémový model příslušného jevu - zde dopravní nehodovosti.
3
Koncept systémového prostorového modelu
dopravní nehodovosti
Odůvodněním pro autory a zároveň smyslem vypracování tohoto příspěvku je demonstrovat
aplikaci systémových pojmů jako podpůrné prostředí pro systémové zkoumání jevu
dopravní nehodovosti a možnosti zúročení v praktické úloze jak hodnotit stav dopravní
nehodovosti. Vhodně zkoncipovaný systémový model dopravní nehody je úvodním krokem.
Samotný soubor prvků systémového modelu dopravní nehody a jejich funkce představují
vstupní analýzu pro konstrukci složek, dále vstupujících do shlukování. Konkrétní předpis
pro následné hodnocení shluků je odvislý od odpovídajícího tvaru produkční funkce,
který předznamená i výběr metody shlukování i následně zaměření a očekávaný obsah
výpovědi a podrobnost celého výsledku. Aplikace měkkého přístupu je v podstatě obrazem
intenzity vnímání „okolí“ systému dopravní nehody: do jaké míry řešitel chce či je schopen
rozpoznat a posléze do analýz zahrnout „měkčeji“ připojené okolí - v tomto případě např.
charakter krajiny, kromě aktuálního počasí i místní klimatické podmínky. Nabízí se i
uplatnění teorie řádu efektů (Vlček, 2002) ve vazbě na celkové ekonomické (hospodářské)
prostředí (ovlivňuje např. komplexní stav komunikací apod.) či na sociální rozměry (vliv na
obvyklé chování řidičů vozidel apod.) či dokonce i na udržitelnost dopravy v kontextu se
škodami, působenými dopravními nehodami apod.
Systémový přístup, o jehož uplatnění se tento příspěvek v problematice dopravní nehodovosti
maximálně snaží (př. Newnam, Goode, 2015; Votruba, Novák, Brandejský, Fábera,
Bouchner, 2009), je možné shrnout parafrází Ludvíka Součka (Souček, 1974) ve smyslu, že
systémový přístup, systémové inženýrství je vědou o „tušení souvislostí“. Cílem je nalezení
těchto souvislostí a jejich deskripce na vhodné rozlišovací úrovni. Autory zaznamenané
dosavadní způsoby evidence a vyhodnocování dopravních nehod systémový charakter
dopravní nehodovosti poněkud pomíjejí a soustředí se na až konečnou úroveň statistického
vyhodnocení.
V následující části příspěvku je tedy autory příspěvku předložen nástin možností, jak se vůči
„jevu“ dopravní nehody stavět systémově, právě ve smyslu konstruktivní teorie systémů
a systémového přístupu k řešení složitých vícerozměrných úloh.
3.1
Stručně k rozvinuté definici systému
Vstupem dalších úvah je aplikace tezí tzv. konstruktivní teorie systémů ve smyslu původní
studie Jaroslava Vlčka Systémové inženýrství (Vlček, 2002). Autoři příspěvku vycházejí
zásadně z motivu, že dopravní nehoda je výsledkem nejen okamžité chyby řidiče či
69
aktuální technické závady na vozidle nebo na dopravní cestě, ale z podstatné části
i důsledkem tzv. souhry okolností - tedy právě výše zmíněných souvislostí uvnitř jevu
dopravní nehody i z okolí, vně jevu dopravní nehody.
3.1.1
Základní tvar rozvinuté definice systému
Pro úplnost vyjádření a vyjasnění dále používaných termínů a odkazů je zde uvedena
rozvinutá definice obecného systému (Vlček, 2002) ve tvaru:
𝑆 ∶= ( 𝐴/𝐹, 𝑅/𝑃, 𝛾, 𝛿, 𝐸, 𝑀, 𝐼, 𝐾)
(3)
kde S značí samotný systém;
A/F je množinou prvků (částí) systémového modelu s jejich funkcemi;
R/P je množina vazeb mezi nimi a jejich parametrů;
γ označuje množinu procesů genetického kódu, resp. druhového chování;
δ znamená množinu procesů cílového chování;
E je symbol etiky systému;
M je mohutnost množina všech procesů v/na systému;
I označuje identitu systému vůči jeho okolí;
K charakterizuje kompetenci systému (v dalších pojetích případně kapacitu systému).
Další podrobnější rozvedení této definice zde není pro účely článku nezbytné, lze je řádně
dohledat v další literatuře - pro tento příspěvek slouží pouze jako formální nástroj dalších
úvah.
3.1.2
Přiřazení složek rozvinuté definice systému k rozpoznaným
systémovým složkám dopravní nehody
Je zřejmé, že pro vedoucí myšlenku tohoto příspěvku - na zvolené podrobnosti vyjádření nepoužili autoři pro následující výklady všechny výše zmíněné složky definice systému, ale
jen vybrané, podstatné pro předkládané úvahy.
Ve výše zmíněném kontextu tedy autoři vnímají jev dopravní nehody jako předlohu pro
specificky zaměřený systémový model, v němž uvažují jeho jednotlivé složky následovně:

70
A/F, tedy množina prvků s jejich funkcemi zahrnuje veškeré účastníky nehody, jež
lze - v rovni podrobnosti, využitelné v tomto příspěvku - rozpoznat jako:
o řidič vozidla - kontroluje pohyb vozidla, zahrnuje v to vlivy na jeho standardní
způsob vedení vozidla jako např. úroveň vzdělání řidiče, absolvování kurzů
bezpečné jízdy, kvalita autoškoly, případně anomálie jeho aktuálního chování
jako např. jeho fyzický či psychický stav, věk, horečka aj.;
o vozidlo - zprostředkovává transport nákladu po dopravní cestě a analogicky
řidiči nosič vlivů stavu konkrétních technických parametrů vozidla;
o dopravní cesta - omezení pohybu vozidla po určité prostorové trajektorii
s počátkem cesty a cílem cesty;
o bezprostřední okolí dopravní cesty - představuje konkrétní geofyzikální,
geografické apod. vlastnosti užité dopravní cesty;
o krajinné prostředí - zprostředkovává ovlivnění řidiče vozidla vizuálními,
emočními apod. parametry;
o klima - určuje hydrometeorologické okolnosti jako např. aktuální počasí,
světelné či teplotní poměry aj. určujícími stav a rychlost změn vlastností
dopravní cesty;
o administrativně ekonomické podmínky - předurčují celkový technický stav
dopravní cesty, intenzitu provozu na dotčené dopravní cestě, obvyklou
technickou úroveň užívaných vozidel atd.;
o sociální podmínky - představují obvyklé individuální schopnosti účastníků
nehody plynoucí z vlastností jejich sociálního prostředí; podvědomý způsob
reakcí jak účastníků nehody, tak jejího okolí na konfliktní situace v dotčeném
krajinném prostředí apod.

R/P, množina vazeb mezi nimi a jejich parametrů je stručně ilustrovatelná
následujícím schématem (komentáře vazeb ve schématu jsou upřesněním obsahu,
významu vazeb na vybrané rozlišovací úrovni systémového modelu), který autoři
stručně formulovali v Obr. 1:
71
Obr. 1. Schematické zobrazení konceptu systémového modelu dopravní nehody. Zdroj: Autoři.
72

M, množina všech procesů v/na systému, může obsahovat procesy jako např.:
o vedení vozidla řidičem;
o poškození dopravní cesty vozidlem;
o ovlivnění směru a způsobu pohybu vozidla dopravní cestou;
o „uspání“ řidiče vozidla jednotvárností krajiny či naopak roztříštění jeho
pozornosti mezi nadměrné množství podnětů z okolní krajiny;
o uvedení vozidla do nežádaného způsobu pohybu po dopravní cestě v důsledku
hodnot parametrů klimatu, resp. aktuálního počasí;
o chování řidiče po události „nehoda“ ohledně míry zavinění nehody jím samým
v přímém důsledku jeho sociálního zařazení a sním spojeného vnímání
závažnosti dopravní nehody;
o vypořádání následků nehody postupy specifickými pro konkrétní sociální
prostředí či ve vztahu k místním administrativně ekonomickým podmínkám aj.

γ, z toho množina procesů genetického kódu, resp. druhového chování
(mimochodem patrně ty procesy, které dosud zásadně formují způsob evidence
dopravních nehod):
o vzájemné poškození vozidla a dopravní cesty;
o vzájemné poškození řidiče a dopravní cesty;
o vzájemné poškození řidiče a vozidla.

δ, z toho množina procesů cílového chování:
o odstranění (následků nehody) „nefunkčních“ řidiče a vozidla z dopravní cesty;
o vypořádání poškození dopravní cesty (nelze vždy počítat s tím, že bude tzv.
„opravena“ dopravní cesta, čili uvedena do alespoň takového stavu,
„bezprostředně“ předcházejícího jevu dopravní nehody).

E, etika systému - kromě vysloveně negativní klasifikace jevu dopravní nehody jako
takové (ekonomická újma, zdravotní újma či újma na životech atp.) lze nalézt i určité
pozitivní přínosy - byť to zní nepřístojně - např. ve smyslu:
o další obohacení vstupů pro žádané upřesnění statistických vyhodnocování;
o morální naučení pro široké okolí jevu dopravní nehody;
o možnost klasifikace dalších, doposud nerozpoznaných souvislostí a možností
vzniku jevu dopravní nehody atd.
I, identita systému vůči jeho okolí - tuto složku lze pro daný účel tohoto příspěvku
chápat ve smyslu „významnosti“ různých úrovní jevů dopravních nehod ve vztahu ke
krajině, ke klimatu, k administrativně ekonomickému či sociálnímu okolí aj.;


3.2
3.2.1
K, kompetence systému zahrnuje v podstatě míru působení důsledků jevu dopravní
nehody na další, již skutečně ve vnějším okolí dopravní nehody probíhající zdánlivě
nezávislé procesy (př. výuka dopravní bezpečnosti v základních školách, kácení alejí
podél silničních komunikací atd.).
Naplnění vybraných vstupních předpokladů identifikace systému a
projekce do GIS
Produkční funkce a řády efektů
Uplatnění teorie produkčních funkcí (Vlček, 2002) znamená pro systémovou úlohu zjištění
a přiřazení funkcí k prvkům využít obecný předpis funkčního vztahu:
73
𝑆 𝑎i ∶= 𝑓(𝐱)  𝐲, (v jiném tvaru např.  𝑎i  𝑨  𝐲j = 𝑓j(𝐱1 … 𝐱n), 𝑓j  𝑭)
(4)
kde ai  A množiny částí (prvků) celku (modelu) pro i=1, 2, .... n celkového počtu částí celku;
f je tvar funkce, schopnosti jednotlivého prvku;
x jsou argumenty funkce, resp. vstupy do schopnosti prvku;
y je hodnota výsledků schopnosti prvku.
Pro další úvahy autoři pro přehlednost užili (na velmi hrubé rozlišovací úrovni) pro
systémový model dopravní nehody základní tvar produkční funkce:
𝐲 ∶= 𝑓(𝐱)
(5)
v němž:
f reprezentuje samotný jev dopravní nehody;
x jsou vstupní argumenty, činitele, jejichž konkrétně nabyté hodnoty způsobí událost =
dopravní nehoda; tedy strukturální složky výše zmíněného systémového modelu
dopravní nehody;
y je v tomto případě „kvalita“ výsledku uskutečnění jevu dopravní nehody; tedy
důsledky, dopady na okolí systému - kromě známých výstupních parametrů jako jsou
počet mrtvých, počet zraněných či finanční škoda i třeba ztráty hospodaření, zamoření
krajiny či poškození životního prostředí nebo i např. rozvoj specializovaných
zdravotnických oborů, způsob organizace záchranných složek apod.
Odkazy na teorii řádu efektů (Vlček, 2002, Vlčková, 2011) autoři demonstrují pro řešení
systémové struktury dopravní nehody a jejího okolí v Tab. 2:
Prvek systémové
struktury
dopravní nehody
Odpovídající řád
efektu
Funkce
řidič vozidla
kontroluje pohyb vozidla atd.
vozidlo
zprostředkovává transport nákladu po dopravní úsečka
cestě
dopravní cesta
omezení pohybu vozidla po určité prostorové
trajektorii s počátkem cesty a cílem cesty
bod
linie
bezprostřední okolí představuje konkrétní geofyzikální, geografické plocha
dopravní cesty
apod. vlastnosti užité dopravní cesty
krajinné prostředí
zprostředkovává
ovlivnění
řidiče
vizuálními, emočními apod. parametry
klima
určuje hydrometeorologické okolnosti jako např.
aktuální počasí, světelné či teplotní poměry aj.
určujícími stav a rychlost změn vlastností dopravní
cesty
„4D“
ve
smyslu
zavedení
dynamiky
chování
prostředí
dopravní nehody
sociální podmínky
představují obvyklé individuální schopnosti řidičů,
podvědomý způsob reakcí na konfliktní situace v
dotčeném krajinném prostředí apod.
sociální prostředí
74
vozidla „3D“
ve
smyslu
doplnění
dalších
rozměrů uzlům sítě,
tvořících plochu
administrativně
ekonomické
podmínky
předurčují celkový technický stav dopravní cesty,
intenzitu provozu na dotčené dopravní cestě,
obvyklou technickou úroveň užívaných vozidel atd.
udržitelnost dopravy
Tab. 2. Ilustrace možného uplatnění tezí teorie řádů efektu na systémový model dopravní nehody. Zdroj: Autoři.
3.2.2
Užití technologie GIS jako systémového nástroje modelování dopravní
nehodovosti
Další uplatnění pojmu technologie geografických informačních systémů a s ním související
konceptu tzv. geoinformačního inženýrství (Vlčková, 2010a a 2011) vyžaduje úvodní
připomenutí základních systémově informatických pojmů z teorie znalosti (např. Vlček, 2002)
a jejich průmět do technologie GIS (Vlčková, 2011):

data: prostorově orientovaná data čili geodata - pořízena přímo z terénních šetření,
lokalizující vybraný (homogenní) územní jev, v tomto případě dopravní nehodu;

informace: prostorová informace čili geoinformace - geodata, vybavená
uživatelskou kvalitou ve vztahu k řešiteli a dalšími připojenými (relačními)
vlastnostmi či charakteristikami, rozšiřující původní pořízená geodata o další
vlastnosti;

znalost: prostorová znalost čili geoznalost - výslednice propojování, relací mezi
geodaty a geoinformacemi, přičemž toto propojení lze konstruovat nejen datově, ale
i prostorově, tedy vztahem vzdálenosti v prostoru v definované souřadné soustavě.
Přepis obecného tvaru produkční funkce systémového modelu prostorového jevu (zde
dopravní nehodovosti) lze uvést ve formulkách (Vlčková, 2012) - pro názornost zde autoři
užívají slovní vyjádření namísto písmenných zkratek:
𝐠𝐞𝐨𝐳𝐧𝐚𝐥𝐨𝐬𝐭 ∶= 𝐠𝐞𝐨𝐢𝐧𝐟𝐨𝐫𝐦𝐚č𝐧í 𝐯𝐳𝐭𝐚𝐡(𝐠𝐞𝐨𝐝𝐚𝐭𝐚)
(6)
Tento koncept dále posunuje úvahy směrem k představě dopravní nehodovosti jako určité
funkce území, vyjádřenou nástroji geoinformačního inženýrství:

samotnými geodaty jsou argumenty x, rozpoznané prvky územního jevu dopravní
nehodovosti, vybavené příslušnou databází - (geo)data dopravních nehod
o údaje o nehodě ve smyslu systémového modelu dopravní nehody

geoinformacemi lze rozumět postup jejich zpracování:
𝐲 ∶= f(údaje o nehodě; údaje o komunikaci … )
(7)
o čili samotné propracování vzniku dopravní nehody ve vazbě na konkrétní
hodnoty vstupních parametrů (systémového modelu) dopravní nehody

geoznalostí se stává výstup příslušné produkční funkce:
(kvalifikace dopravní nehody, důsledky
(8)
do okolí dopravní nehody) ∶= f (údaje o nehodě; údaje o komunikaci … )
75
Diskusní koncept využití shlukové analýzy pro klasifikaci
úseků komunikací
4
Autory navrhovaný základní koncept využití shlukové analýzy pro vícerozměrnou klasifikaci
komunikací z hlediska nebezpečnosti jejích úseků nástroji geoinformačního inženýrství
především kromě jiného předpokládá i roztřídění dosud evidovaných položek podle
systémového modelu s uvážením výhod možností práce v prostředí GIS (mj. Cope,
Elwood, 2009; Li, Leung, 2011; Miller, 2001; Rybansky, 2014). Takové úvodní setřídění
dovolí pregnantně formulovat jak zdroje externích dat (RÚIAN - Registr územní identifikace
a adres nemovitostí, NDIC – Národní dopravní informační centrum apod.), tak i úlohy, které
za řešitele „provede“ účelová aplikace GIS (lokalizace v síti komunikací, zahrnutí do
celostátních statistik a generelů aj.).
Souvisejícím důsledným odlišením funkcí prvků systémového modelu autoři dospěli mj. až
k představě samostatné funkce „dopravního koronera“. I to by též znamenalo další pomoc při
optimalizaci práce zúčastněných složek: zkráceně řečeno nechat policistům řešení deliktů
s trestněprávními důsledky, zatímco ohledání, zaevidování a celou úřední a evidenční agendu
následně přesunout na úředníka - zmíněného „dopravního koronera“, který provede kompletní
ohledání místa a dopadů nehody, její fundovanou jednotnou lokalizaci, zaevidování atd.,
včetně zavedení konkrétní dopravní nehody do celého projektu dopravní nehodovosti v GIS
pro její další zapracování do propojených ostatních statistik, modelů atp.
Kompletní koncept diskutovaného propojení zmíněných metodologií, metodik autoři shrnuli
do obr. 2 níže:
Obr. 2. Koncept uplatnění nástrojů technologie GIS a shlukové analýzy v problematice dopravní nehodovosti.
Zdroj: Autoři.
76
5
Závěr
V závěrečném shrnutí autoři dospěli k přesvědčení, že významnou pomocí pro snižování
dopravní nehodovosti je kvalifikované využití metod a nástrojů jednak systémového
přístupu – vede ke kvalitnějšímu vyhodnocení skutečných příčin vzniku dopravních nehod,
jednak shlukové analýzy - v souladu se systémovým přístupem efektivněji zvládá vnitřní
propojenost zahrnutých faktorů, jednak technologie GIS ve smyslu oboru geoinformačního
inženýrství (navazující pojem za termínem geoinformatika (Vlčková, 2010a), zahrnujícího
podle autorů jen základ práce s prostorovými informacemi na rozdíl od inženýrských principů
obecně dle Vlčka (2001)) - optimalizace jak analytických prací, tak i jejich interpretace
i vizualizace moderními informačními technologiemi (např. Hrubeš, 2010). Dosavadní
postupy, založené víceméně jen na jednoduchých početních úkonech typu součet či
aritmetický průměr počtu nehod na vybraných úsecích, zdaleka již neodpovídají významnosti,
rozsahu i komplikovanosti celé problematiky. Přitom zmíněné tři obory a jejich metodické
nástroje dávají dostatek možností, jak lépe vyhodnocovat stav i věrohodněji a účinněji hledat
možnosti nápravy. Doporučením ze strany autorů je jednak zavedení zmíněných postupů při
klasifikaci a kvalifikaci dopravní nehodovosti, tak případné úpravy ve způsobu práce
dopravní policie s cílem systémově zkvalitnit práci policistů s odlišením podle obsahu
jejich agendy - trestněprávní odpovědnost vůči evidenčním a analytickým činnostem.
Ajvazjan, B. S. (1981). Metody vícekriteriální analýzy. Praha: SNTL.
Bašta, A. (1986). Kvantifikace a měření ve společenských vědách. Praha: VÚVTR.
Cope, M., Elwood, S. (2009). Qualitative GIS, A Mixed Method Approach. Thousand Oaks, CA: Sage.
Dale, P. (2005). Introduction to Mathematical Techniques used in GIS. Boca Raton: CRC Press.
Hrubeš, P. (2010). Analýza statistických dat silniční nehodovost [Habilitační práce]. Praha: ČVUT.
Sovjáková, E., & Kopecký, A. (1989). Moderní matematické disciplíny v územním plánování. Praha:
TERPLAN - Státní ústav pro územní plánování.
Li, R, & Leung, Y. (2011). Multi-objective route planning for dangerous goods using compromise
programming. Journal of Geographical Systems, 13(3): 249-271.
doi: 10.1007/s10109-010-0124-6
Mazaheri, A., Montewka, J., Nisula, J., Kujala, P. (2015). Usability of accident and incident reports
for evidence-based risk modeling - A case study on ship grounding reports. Safety Science.
2015, 76: 202-214. doi: 10.1016/j.ssci.2015.02.019
Míchal, I. (1992). Ekologická stabilita. Brno: Veronica pro Ministerstvo životního prostředí
České republiky.
Miller, H. (2001). Geographic Information Systems for Transportation: principles and applications.
New York: Oxford University Press.
Newnam, S., & Goode, N. (2015). Do not blame the driver: A systems analysis of the causes of road
freight crashes. Accident Analysis, 76: 141-151. doi: 10.1016/j.aap.2015.01.016
Policie ČR (2008). Vybrané položky evidence dopravních nehod. Výtah ze zapůjčených pracovních
podkladů. Praha: MV ČR.
Rybansky, M. (2014). Modelling of the optimal vehicle route in terrain in emergency situations using
GIS data. In 8th International Symposium of the Digital Earth (ISDE) (pp. 1755-1307). doi:
10.1088/1755-1315/18/1/012131
Souček, L. (1974). Tušení stínů. Praha: Československý spisovatel.
77
Vlček, J. (1996). Doprava jako věda. In Doprava předmět vědeckého zkoumání – sborník příspěvků,
kolokvium. Praha: ČVUT.
Vlček, J. (2001). Systémové inženýrství. Praha: ČVUT.
Vlček, J. (2002). Znalostní inženýrství. Praha: ČVUT.
Vlček, J. (2002). Informační výkon. Praha: ČVUT.
Vlčková, V., Hrubeš, P. et al. (2010). Harmonizace výuky geoinformačního inženýrství na fakultách
ČVUT [studie pro Fond celoškolských aktivit ČVUT]. Praha: ČVUT.
Vlčková, V. (2010a). Geoznalost a geoinformační inženýrství. In GIS na ČVUT (pp. 6-12). Praha:
ČVUT.
Vlčková, V. (2010b). Kudy tudy systémovým inženýrstvím. [Upravený přepis Vlček Jaroslav:
Systémové inženýrství]. Praha: ČVUT.
Vlčková, V. (2011). Kudy kam geoinformačním inženýrstvím. Praha: ČVUT.
Vlčková, V. (2013). Kudy dál systémovými strategiemi. Praha: ČVUT.
Vlčková, V., & Votruba, Z. (2010). The Synergy Transportation. Transactions on Transport Sciences,
3(4):179-186. doi: 10.2478/v10158-010-0024-y
Votruba Z., Kaliková J., & Kalika, M. (2008). Systémová analýza. Praha: ČVUT.
Votruba, Z., Novák, M., Brandejský, T., Fábera, V., Bouchner, P., Zelenka, J., Vysoký, P.,
Bělinová, Z., & Sadil, J. (2009). Theory of System Alliances in Transportation Science. Praha:
ČVUT.
78
79
DOI: 10.18267/j.aip.62
Peer-reviewed paper
Influence of Organization Management
on Systems of Performance Measurement
and Management Control
Zora Říhová*
Abstract
This article is focused on investigating the influence of organization management
on Performance Measurement Systems (PMS) and Management Control Systems (MCS).
The goal of the paper is to draw attention to the fact that designing PMS the validity of which
could not be disputed, needs to correctly determine the organization structure and the role
competences. In the example of matrix structures are shown some of the difficulties that
may distort the results obtained from these systems. PMS + MCS is to be created after
a thorough critical analysis of the organizational structure and set competences.
Keywords: Organizational structure, System aspects of organizational structure, Matrix
structure, Performance measurement systems, Management control systems.
1
Introduction
Performance Measurement Systems (PMS) and Management Control Systems (MCS) are
important systems for the measurement of company performance. The company's
performance is substantially given by a positive response and long-term (contentment)
of customers.
There is an extensive amount of research going on in the direction of PMS. Many papers
concern the PMS in business and management, e.g. (Bititci et al., 2005; Bititci, et al., 2012),
or from the perspective of business process management (Pádua, Jabbour, 2015) and also
in public management (Boyne, et al, 2009).
This paper is focused on investigating the influence of organization management on PMS and
MCS. The goal of the paper is to draw attention to the fact that designing PMS the validity
of which could not be disputed, needs to correctly determine the organization structure and
the role competences.
Systems PMS + MCS are thus used for two main purposes:


Improve customer related orientation.
Increase the effectiveness and performance of the company.
*
Department of Systems Analysis, Faculty of Informatics and Statistics, University of Economics, Prague,
80
The orientation of all activities toward the customer, however, is often a problem, and
attention is focused on the correct functioning of the company and its refinement in terms of
communication, personal, financial, culture.
Given that PMS + MCS basically must always correspond to any organizational structure, it is
necessary to know the organizational structure of the company. Even the best controlling
systems that do not reflect the organizational structure are based exactly on the fact that we
have good results from non-relevant documentation. It is therefore necessary before the
formation of PMS and MCS to analyze the organizational structure of the company.
First of all it should be examined whether the organizational structure, which requires a PMS
+ MCS system, corresponds to the above requirements. It means whether it is sufficiently
customer-oriented and if it is possible to obtain relevant data to assess the performance and
effectiveness.
This seemingly trivial argument can be well demonstrated in concrete cases. One of the
recommended (more in theory) arrangements is a matrix organizational structure. From a brief
analysis of this form we shall try to demonstrate the thesis of the importance of analyzing the
organizational structure when creating PMS + MCS. It can be based on the results of the
survey (Pilzová, 2010), which addressed the strengths and weaknesses of the matrix
arrangement in terms of company managers in the Czech Republic. Also author´s practical
experience in information systems implementing (Information system SAP in years
1996-2013) confirms that it is impossible to establish efficient and correct indicators without
a detailed analysis of the organizational structure and examining weaknesses.
2
Theoretical framework for critical discussion of difficulties
in organization structure
Before we proceed to discuss the difficulties in organization structure related to PMS + MCS
(in the Section 3), it is useful to introduce at least key concepts from organization theory and
the process of organizing.
Inefficient arrangements in organizations have great consequences, among which most often
include: bureaucracy, unresolved power and responsibility, delaying of the decision-making
process, the emergence of conflicts, late or incorrect responses in the event of internal and
external business activities, and a disproportionate cost of operations (Vodáček, Vodáčková,
2005).
2.1 Organizational structure
The word organization is used in the sense of the organization as a company, firm, and also as
an organizational structure in terms of the inner product. Organizational structure can be
defined as a formal system of tasks and relationships of subordination and superiority, which
manages, coordinates and motivates workers (Dědina, Odcházel, 2007, p. 134). Today, this
term is understood as departmental organizational structure, and process, but also as modern
association of organizations into strategic alliances or virtual teams and organizations
(Dědina, Odcházel, 2007, p.16). Individual elements of the organization act back on its
system and also affect behavior and other elements of the system and thus contribute to selforganization. Organization theory deals with the clarification of the principles and possibility
of arrangement of the elements and their linkages and implications for the behavior of the
system.
81
The fundamental questions of the formation of the organization (Picot et al., 2012) are:



Formal and informal structure - the formal structure is specifically established
relationships which are grounded in formal rules (eg. Organizational Regulations).
Informal organization includes spontaneous relationships between people and
complements the formal structure.
Processes and relationships - organization linked to the formal structure defines
long-term relationships.
Differentiation and Integration - regulates the division of labor, both vertically and
horizontally while integration acts as a coordination and arrangement of the whole.
Organizational structure therefore organizes relationships; addiction behavior defines the
behavior of parts of a whole and supports the business strategy. It is necessary to examine the
question of how to meet the requirement of organizational structure for rapid and active
response in favor of the customer.
Organizational structures respect the objectives of the organization, organizational tools and
marginal conditions (Říhová, 1996). The goal of organization (C) is related to marginal
condition (P) and structural variable (S):
Where P are not influenceable marginal conditions determined by:




Company environment – not only global as social, legal, technical,
environmental, but also as competition, technology development and
customer structure.
The internal situation of the company in the past (as company age,
tradition, development stage, way of establishing), in the present (size
company, legal form, ownership, level of informatics) and the future
(strategies).
Employees that are available.
Characters of the task as structuring (possibility of spreading to a clear
process of follow-up), variability (predictable changes in prices, quality,
quantity, frequency), volume (the number or amount in time) and similarity
of the task.
Structural variables (S) are based on an analysis of work roles and the organizational tools:




Specialization of task – verticals, by products.
Allocation of responsibility and competence – different types
of organizational structures.
Process structuring and standardization as task progress, the framework
conditions, results programming etc.
Job or roles creation.
The basic formula C = f (S,P) answers questions about which targets (C) the organization has
to fulfill (flexibility, productivity, profits, satisfaction of needs of people), what organizational
tools (S) has the company available to influence the running of the company and what
conditions (P) are uncontrollable. The structure of the company thus creates a framework
within which to implement the goals and objectives of a particular group of people to build
and maintain linkages, that due to the vicinity, ensure the prosperity of the organization
(Říhová, 1996).
82
2.2
Creation of organizational structure
Organizational structures are of different types – flat, steep, linear, functional and matrix and
others. This distinction is also sometimes called the "viewpoint competence and
responsibility" (Vodáček, Vodáčková, 2005). The line relationship is a vertical relationship
between superiors and subordinates. It is the oldest relationship in which the command is
passed from top to bottom, single-level management. Efforts to be better suited to the
organizational structure are reflected in the structuring of product, geography, by market and
under.
In practice, they are rarely applied as purely one type of structure. Most of these are
combinations and the most frequent variant combinations are linearly staff or target
programming (Vodáček, Vodáčková, 2005). For the second variant, we also classify different
types of matrix organizational structures. Matrix structures include more complex hierarchical
systems, which can be multiple. Sometimes it is only a short-term status (defined timescale of
the project), but may also continue for a long time. Matrix organizational structure is used
especially for large businesses or multinational corporations as a customer-organized
structure.
The functioning of the matrix structure is mostly based on the management structure in terms
of geography, with offices in different countries, which are managed by local country
managers (with its own budget in each country) and multinational divisional managers, who
are responsible for product specialization (government, industry, energy, telco, commerce,
etc.) and have a budget for these divisions. Divisions are mostly represented in local offices
and are subject to management at all levels – e.g. Trade – a local branch CZ, office for Middle
Europe, Central Europe (Middle + Germany), a pan-European management, EMEA (Europe
+ Middle East + Africa), CEO. Also CZ are subject to direct managing of Finance and Human
Relations (HR) on the high level. Fig. 1.
83
Fig.1. Geography matrix structure with multinational divisional managing. Source: Author
84
IT companies may be more structurally divided into divisions of software, hardware, servers,
services, outsourcing, etc. In contrast, for example, the Finance Division is managed centrally
and reports directly to headquarters. For IT companies it is broken down on the vertical
divisional level, representing the different product specialization (hardware, servers, etc.). The
horizontal structure is broken down in terms of sectors (Finance, Public, Global Business,
etc.). The third dimension is the territorial aspect – the geographical breakdown. In terms of
management levels it can go up to five levels of management.
3
Discussion
In several examples (not an exhaustive list) from the author‘s own experience and from
survey (Pilzová, 2010) we show the complexity of the issue and matrix organizational
structure with respect to the determination of PMS + MCS.
3.1
Several decision-making subjects
The matrix structure does not contain only the double linkages, but additionally it may
concern the project teams what results in multiple and complex linkages across the whole
organization. Consequently, it is connected to the level of management with given
competences. Each decision making subject may have other preferences, rules, and may
complicate the creation of PMS + MCS so as to ensure adequate impact assessment decisions.
The decision may be in conflict with the interests of the level at which the problem originated
(some level of management assesses the importance of the problem differently than, for
instance the republican level) or the decision was made late due to a lengthy decision-making
process. In this situation it is difficult to make a simple, true and correct system of indicators.
3.2
Multiplicity reporting
From the organizational structure and more decision-making places, there is the obligation of
reporting on several senior positions, which can be very stressful for employees. There can
also be various reporting systems and they may use different indicators for the same reporting
aspect or conversely the same pointers to more examined activities. Decision points can then
attach a different weight to the reported indicators. It is therefore necessary to establish a PMS
+ MCS with a view to optimizing indicators and regular reports processed.
3.3
Unclearly specified competences
It is a problematic area and measuring the performance of employees / departments /
divisions, where it may be unclear to what extent can affect the performance of the entire
organization. Often they do not even realize what goals the organization has and how it relates
to the objectives of the employee or department. And the question is therefore how to define
indicators of the workplace. Someone is focused on performance, someone on some type of
profit, and may not be obvious what is important for the parent level.
Unclearly specified powers and responsibilities may enable prioritization of local optima
before optimum whole. Moreover, it criticized ambiguous responsibility between roles and
superiority. This problem is also related to the emergence of the endless "space" that is
difficult to control, and many employees could be demotivating. This area therefore should be
considered before introducing systems PMS + MCS.
85
3.4
Contradictory interests of close cooperating subjects
From the vaguely specified competencies it implies the possibility of different preferences
in activities of the institutions of the company. Workers local affiliates may be in an
environment that creates a competitive space for internal rivalries and can negatively impact
customers. The customer can be serviced by one or more account managers from one
company. Individual account managers are evaluated for the amount budgeted to their
division, and their motivation is to get the largest share of the total investment budget. Thus,
to ensure optimum customer needs may not be their main concern.
The final budget and the related services offer depend more on the business and
communication skills of a particular account manager, rather than on the real needs of the
customer. The same problem occurs if the company performs for multiple account managers
who prioritize their own interest before the interest of the customer. It is therefore
a contradictory interest and the question is, how do we define PMS + MCS indicators and
select the right data? It is possible to assume that there are conflicting interests and there are
various different data important for individual subjects and it is therefore difficult to
determine which data to select and how to evaluate it, especially in relation to the customer.
Another example illustrates the various interests of the longer-term implications
of a particular decision. A trader can have a clear understanding of customer needs.
Purchasing divisions, however, prioritize their own target – business spending – and then take
a cheaper but less convenient product. In the short term, it could be that the manager of the
purchasing department is satisfied with his decision, because he managed to show lower
expenses. In terms of the long-term, however, this decision proved to be unfortunate, and it
had been for all the divisions that were forced to deal with the arisen shortage. A bad purchase
also featured a great risk of loss of customer confidence, and risk in damaging the brand
image. Purchasing divisions find themselves in practice in organizational conflicts quite often.
The question therefore is what is the relevant indicator in the system PMS + MCS. Whether it
is the immediate effect of reducing cost as an advantage or customer dissatisfaction, which is
reflected as a negative as the decline in sales even for a longer period. The question is, who
will assess it and how are these contradictory data reflected in the company's activities.
Conflicts arising in the business divisions are usually solved by their managers. Then
it depends on communication skills and abilities of individual managers. For example the
business manager must be able to convince his colleagues that the implementation of the new
solution is really needed and must be able to explain what impact it has on customers.
Otherwise, the manager responsible for the purchasing division must be able to explain the
situation to others in the company, why it is for instance not possible on such a scale to spend
resources.
A similar problem with a problematic impact on PMS + MCS can also arise at the level of the
human resources department if you do not pursue the best staff, which the company may not
have enough resources to pay. It does not address only the issue of salaries and bonuses for
employees, but also their number. The personnel department, along with the finance
department must decide whether it is better for the company to accept a worker's salary or
split between two less-skilled workers. Furthermore, how to reflect similar decisions to the
controlling system in the short and long term. In such cases it is necessary to consider the
enterprise-wide scale, and to assess the real needs of the organization.
86
3.5
Other possible aspects of the impact of organizational
structures on PMS+MCS
From the perspective of organizational structures on systems PMS+MCS include also some
others aspects:






4
Divergence of interests of close associates
Conflict in valuation of larger contracts – the decision-making process can be very
lenghty
Favoring an optimum before a maximum
A large number of complex relationships and links
Ignoring the customer's perspective
The effect of cultural influences in multinational corporations.
Conclusion
Creating PMS + MCS is very important, but must be based on what we need:
customer-oriented systems, based on the correct system and also use the true and relevant
data. Data reality in systems PMS + CMS often generates information outputs based on input
data from lower management levels that are overloaded by operativecontrol and antisense
contradictory requirements of different various higher decision-making subjects.
Then, they do not have left much time, strength and energy to investigate the truthfulness
of reported data. Other levels of management then build on these data further analyses and
reports for the other higher levels of the management. These often irrelevant data are
transmitted to the next levels in well arranged tables. This increases the difference between
the theoretical point of view of idealistic systems PMS + CMS and the real life of people
in the organizational structure.
The division of labor enforces organizing people, provides the framework and space in which
to realize objectives and goals of the company. In the example of matrix structures it was
shown that MCS + PMS systems need to be created after a thorough critical analysis of the
organizational structure and set of powers. We need to measure what has some meaning to the
organization (focus, goals, status, how it is focused on customers). The created systems PMS
+ CMS must be individually designed for the specific organization.
The requirement of effectiveness of the organizational structure in relation to the customer
and sales efficiency is essential and serves to maintain a closer relationship with the customer.
It is impossible to establish efficient and correct indicators without a detailed analysis of the
organizational structure and examining weaknesses. Each decision making subject may have
other preferences, rules, competences and may complicate the creation of PMS + MCS so as
to ensure adequate impact assessment decisions. To conclude, the paper contributes to the
complex view of the problems associated with designing PMS + CMS systems.
References
Bititci, U. S., Mendibil, K., Martinez, V., & Albores, P. (2005). Measuring and managing
performance in extended enterprises. International Journal of Operations and Production
Management, 25(4), 333-353
Bititci, U. S., Garengo, P., Dörfler, V., & Nudurupati, S. (2012). Performance Measurement:
Challenges for Tomorrow. International Journal of Management Reviews, 14(3), 305-327.
87
Boyne, G. A., Meier, K. J., O’Toole, L. J. and Walker, R. M. (2006). Public management and
organizational performance: An agenda for research. In Boyne, G.A., Meier, K.J., O’Toole,
L.J. and Walker, R.M. (eds). Public services performance: Perspectives on measurement and
management (pp. 295-311). Cambridge: University Press.
Dědina, J., & Odcházel, J. (2007). Management a moderní organizování firmy. Prague: Grada.
Pádua, S.I.D, & Jabour, C.J.C. (2015). Promotion and evolution of sustainability performance
measurement systems from a perspective of business process management. Business Process
Management Journal, 21, 403-418.
Picot, A., Dietl, H., Franck, E., Fiedler, M., & Royer, S. (2012). Organisation – Theorie und Praxis
aus ökonomischer Sicht. Stuttgart: Schäffer-Poeschel.
Pilzová, H. (2010). Zákaznicky orientovaná organizační struktura společnosti. Diploma thesis.
Prague: VŠE, Praha.
Říhová, Z. (1996). Informační zabezpečení a organizační změny. Prague: VŠE, Praha.
Vodáček, L., & Vodáčková O. (2005). Management, teorie a praxe v informační společnosti. Prague:
Management Press.
88
89
DOI: 10.18267/j.aip.63
Peer-reviewed paper
Použitelnost elektronických formulářů
veřejné správy
Usability of Public Administration Electronic Forms
Miloslav Hub*, Michal Chudoba*
Abstrakt
Tento příspěvek se zabývá testováním a hodnocením formulářů veřejné správy z pohledu
jejich použitelnosti. Jeho cílem je navrhnout vhodnou metodiku, jak testovat použitelnost
elektronických formulářů včetně jejího popisu a tuto metodiku distribuovat odborníkům
v oblasti informačních systémů veřejné správy. Nejprve jsou vyjmenovány metody
inženýrství použitelnosti a vybrána vhodná metoda pro testování a samotné hodnocení
použitelnosti elektronických formulářů. Poté je navržena metodika testování použitelnosti
elektronických formulářů využívající zvolenou metodu. V poslední části příspěvku
je navržena a realizována případová studie, která využívá navrženou metodiku. Hlavním
přínosem této práce je navržení metodiky a návrh doporučení pro návrh nových
elektronických formulářů veřejné správy.
Klíčová slova: Inženýrství použitelnosti, uživatelské rozhraní, veřejná správa, informační
systémy, kvalita software.
Abstract
This paper is focused on the testing and evaluating of public administration electronic forms
from the usability point of view. Its objective is to design a suitable methodology for usability
testing of electronic forms and their description and distribution to public administration
information systems professionals. Firstly, methods of usability engineering are summarized
and a suitable method for usability testing and evaluation of electronic forms is selected.
Farther, the methodology of electronic forms usability testing that uses the selected method
is suggested. In the last part of the paper the case study that uses the proposed
methodology is suggested and performed. The main benefit of the work is the design
of testing methodology and proposition of the set of recommendations for new public
administration electronic forms design.
Keywords: Usability engineering, User interface, Public administration, Information systems,
Software quality.
*
Institute of System Engineering and Informatics, Faculty of Economics and Administration, University of Pardubice,
Studentská 95, 532 10 Pardubice, Czech Republic
 [email protected], [email protected]
90
1
Úvod
Informační systémy spravují informace i velmi vysoké hodnoty (Myšková, 2006). Uživatelé
těchto informačních systémů si volí software, který je pro ně srozumitelný a se kterým se jim
dobře pracuje – který je použitelný. Použitelnost nemusí souviset pouze s grafickým
uživatelským rozhraním software (Černá & Poulová, 2009), ale i například s kartografickými
díly (Sedlák et al., 2010). Z tohoto důvodu je testování použitelnosti důležitou součástí návrhu
a vývoje každého softwaru.
Hlavním zdrojem formulujícím problematiku použitelnosti software je norma ISO/IEC 9241,
která specifikuje, jak by měl software vypadat, aby splňoval podmínky použitelnosti.
K hodnocení slouží množství technik umožňujících identifikaci problémů v používání
softwaru. Hodnocení může posloužit vývojovým pracovníkům produktu k odstranění závad
a problémů, čímž se zvyšuje konkurenční výhoda produktu, na druhé straně přináší výhodu
koncovému uživateli formou větší srozumitelnosti a použitelnosti.
U veřejných zakázek vypisovaných orgány veřejné správy mnohdy nastávají problémy
s kvalitou dodaných produktů, protože kontrola kvality není vždy zcela objektivní.
Elektronické formuláře veřejné správy nejsou výjimkou, proto je třeba navrhnout metodiku
testování elektronických formulářů z hlediska jejich použitelnosti tak, aby ji mohly využít
orgány veřejné správy při posuzování a výběru softwarových produktů ze širší nabídky
z různých vývojových pracovišť.
Elektronické formuláře orgánů veřejné správy a místní samosprávy musí v souladu
se zákonem č. 365/2000 Sb. (Zákon o informačních systémech veřejné správy) a zákonem
č. 300/2008 Sb. (Zákon o elektronických úkonech a autorizované konverzi dokumentů, tzv.
„zákon o eGovernmentu“) splňovat zásady přístupnosti webových stránek veřejné správy
stanovených vyhláškou 64/2008 Sb. vyhláška o přístupnosti. Tato vyhláška ve své příloze
stanovuje sadu 33 pravidel pro tvorbu přístupných webových stránek (Vyhláška č. 64/2008
Sb.). Problematikou použitelnosti se však žádný zákon ani vyhláška žádného z ministerstev
nezabývají. Proto je pouze na vývojářích daného formuláře, zda se budou testováním
použitelnosti zabývat či nikoli (Komárková, Máchová & Bednarčíková, 2008). Pokud se však
mají elektronické formuláře stát plnohodnotnou náhradou svých papírových protějšků, je
potřebné, aby tyto formuláře byly uživatelsky přívětivé a mohly být bez větších problémů
využívány. Testy použitelnosti elektronických formulářů veřejné správy mají také velký
význam pro instituce, které jejich tvorbu financují, neboť jim údaje z testů poskytují podklady
pro hodnocení kvality dodaného produktu.
Proto by stanoven jako cíl návrh vhodné metodiky pro testování a hodnocení použitelnosti
elektronických formulářů veřejné správy, na jejímž základě lze testování provádět. S využitím
navržené metodiky bude posléze provedeno otestování a ohodnocení vybraných formulářů
z hlediska použitelnosti. Výsledky získané z testů mohou sloužit k vytvoření doporučujících
návrhů sloužících k odstranění nalezených problémů, čímž dojde ke zlepšení kvality
testovaných formulářů. Tento příspěvek přímo navazuje na předešlou práci (Chudoba, 2010).
2
Rešerše a výzkumné metody
V současné době je v oboru inženýrství použitelnosti používána celá řada metod, např.
kognitivní průchod (Cognitive Walkthrough) (Nielsen, 1994a), analýza vlastností (Feature
Inspection) (Nielsen, 1994b), heuristická analýza (Heuristic Evaluation) (Nielsen, 2010), oční
kamera (Eye-Tracking) (Hrom, 2003), metoda koučování (Coaching Method) (Nielsen,
2004a), spoluodhalující učení (Co-Discovery Learning) (Nielsen, 1994a), hodnocení činnosti
91
(Performance Measurement) (Nielsen, 2004a), dotazovací metoda (Question-Asking
Protocol) (Hrom, 2003), vzdálené testování (Remote Testing) (Usability Evaluation, 2012),
retrospektivní testování (Retrospective Testing) (Nielsen, 2004a), uvažování nahlas (Thinking
Aloud Protocol) (Nielsen, 2004a), ohniskové skupiny (Focus Group) (Usability Evaluation,
2012), pozorování v terénu (Field Observation/Ethnography) (Nielsen, 2004a), individuální
rozhovor (Individual Interview) (Nielsen, 2004a), zápis aktuálního užívání (Logging Actual
Use) (Usability Evaluation, 2012), dotazníky (Questionnaires) (Hrom, 2003) a uživatelské
testy (User Testing) (Usability.gov, 2007).
Při výběru vhodné metody pro testování a hodnocení použitelnosti bylo využito poznatků
získaných z (Budinská, 2009). Kromě toho na základě dotazníkového šetření byla s využitím
odborníků na testování použitelnosti stanovena kritéria, která jsou považována za důležitá při
výběru vhodné metody testování a hodnocení použitelnosti software. Jsou jimi vývojová
etapa, místo výkonu testů, typ výstupních dat, výstupy testů, počet participantů a počet
expertů na testování použitelnosti.
Tato jmenovaná kritéria jsou použita pro výběr vhodné metody pro testování a hodnocení
použitelnosti elektronických formulářů veřejné správy. Prvním kritériem je vývojová etapa.
Jako možné použitelné metody jsou tedy uvažovány pouze ty, které se uplatňují ve fázi
nasazení daného softwaru. Druhé kritérium typ výstupních dat omezuje výběr možných metod
na ty, které poskytují jak kvantitativní tak i kvalitativní data. Kvantitativní data se lépe
zaznamenávají, jsou vhodná pro srovnávání a snadněji se interpretují. Kvalitativní data zase
lépe zachycují subjektivní pocity a důvody jejich vzniku. Proto je vhodné, aby vybraná
metoda poskytovala oba typy dat.
Dalším omezujícím faktorem je místo výkonu testu, nelze tedy uvažovat metody vzdáleného
testování, ke kterému je potřeba specializovaného software. Tato skutečnost má nepříjemné
omezení v tom, že participanti by neprováděli testování na výkonově srovnatelných
počítačích. Počet participantů je stanoven minimálně na jednoho účastníka, protože snahou
testů je prověření schopnosti skutečných uživatelů pracovat s daným formulářem, zda ho jsou
schopni vyplnit a podat či nikoliv. Pro účely testování nejsou uvažovány metody, u nichž
se na testování podílí více než jeden expert na testování použitelnosti. Dalším požadavkem je,
aby počet expertů nebyl vyšší než jeden, proto aby testování mohla provádět pouze jedna
osoba se znalostmi z oblasti testování použitelnosti. Náklady na testování tedy nebudou
neúměrně vysoké, a proto si jej mohou dovolit i nižší orgány veřejné správy hospodařící
s nízkými rozpočty.
Některé z výše uvedených metod poskytují pouze kvalitativní nebo kvantitativní výstupy,
některé metody vyžadují speciální vybavení, přítomnost většího množství expertů a podobně.
Na základě rešerše byla zvolena metoda uživatelských testů, která splňuje formulovaná
kritéria.
92
3
3.1
3.1.1
Řešení a výsledky
Formulace metodiky testování a hodnocení použitelnosti
elektronických formulářů prostřednictvím metody uživatelského
testování
Předmět testování
Navržená metodika je koncipovaná pro fázi nasazení elektronických formulářů veřejné
správy. Slouží tedy k testování hotových elektronických formulářů používaných v oblasti
veřejné správy, neboť se předpokládá, že veřejná správa si sama tyto formuláře nevytváří.
Navřená metodika má tři možné uplatnění. První možností je její využití k odhalení zásadních
i méně závažných chyb, nacházejících se v již existujících formulářích. Druhou možností je
porovnání dvou vývojových verzí jednoho elektronického formuláře. Posledním využitím
metodiky jsou testy sloužící k porovnání dvou nebo více konkurenčních verzí formulářů
veřejné správy vytvořených různými vývojovými týmy. Podle toho bude testována pouze
jedna verze webového formuláře, nebo verzí více.
3.1.2
Cíl testování
Úkolem tohoto kroku je definování cílů a obav. Nejprve je potřeba definovat jejich obecné
znění, na jehož základě jsou vytvořeny konkrétní cíle a obavy. Definování cílů a obav je pro
každý test odlišné a jedinečné, protože vychází z testovaného formuláře a webové stránky,
na níž se nachází. Existují ale typické příklady cílů a obav, jejichž využití je pro testy vhodné.
Příkladem obecného cíle může být ověření schopnosti uživatelů pracovat s formulářovým
menu rychle a snadno. Z tohoto obecného cíle vyplývají konkrétní cíle a obavy, kterými jsou
otázky, zda budou uživatelé s využitím menu schopni uložit vyplněný formulář, vytisknout
ho, provést jeho elektronické podání, najít potřebné informace v nápovědě, provést kontrolu
vyplněných údajů a podobně.
Současně je třeba v tomto kroku zodpovědět i otázku, zda bude proveden důkladný test, který
je sice časově a finančně náročný, na druhou stranu poskytuje lepší a komplexnější výsledky
nežli jednoduchý test. Nebo zda bude proveden základní test, který je oproti komplexnímu
testu méně finančně a časově náročný.
3.1.3
Výběr participantů
Při používání formulářů veřejné správy nejsou zapotřebí žádné specifické znalosti ani
dovednosti, proto není výběr testovaných osob nijak zvláště limitovaný. Uživatelem
elektronických formulářů může být jakákoliv osoba, která zvládá alespoň minimální základy
práce s počítačem a internetem, proto aby byla schopná provést vyplnění a podání formuláře.
Nezáleží přitom na jejích znalostech dané problematiky veřejné správy. Jediným kritériem
omezujícím výběr participantů je jejich věk. Podávat elektronické formuláře, stejně jako jejich
papírové obdoby, totiž mohou osoby způsobilé k právním úkonům, tedy zletilé svéprávné
osoby starší 18 let.
V případě testování některých formulářů jsou ale na participanty kladeny určité požadavky
týkající se jejich vzdělání a schopností. Příkladem jsou daňové formuláře, protože
k vyplňování těchto formulářů jsou potřebné uživatelovy znalosti z oblasti daňové správy
a zákonů upravujících výběr daní, protože bez znalosti potřebné problematiky by nebyli
případní participanti schopni správně formuláře vyplnit.
93
Z tohoto důvodu je potřeba pro účely testování vybrat pouze ty uživatele, kteří mají potřebné
znalosti a zkušenosti týkající se této oblasti. Požadované znalosti a zkušenosti s touto
problematikou je důležité ověřit sadou otázek v dotazníkovém šetření zkoumající profil
uživatele.
Dělení participantů do dílčích podskupin je vhodné využít pouze v případě, že je prováděn
důkladný test, protože poskytuje informaci, jak si s testem poradila daná skupina uživatelů.
Pro účely jednoduchých testů nemá toto dělení výrazné opodstatnění. Na základě
definovaných profilů participantů jsou vytvořeny skupiny, z nichž každá reprezentuje jeden
konkrétní profil.
Stanovení počtu participantů úzce souvisí se zvoleným typem testu. Pro účely jednoduchých
testů je ideální využít čtyř respektive pěti participantů, protože testování s tímto počtem
participantů dokáže odhalit 78% respektive 85% problémů v testovaných formulářích
(Krug, 2003), (Nielsen & Landauer, 1993). Pro důkladný test je vhodné vybrat deset nebo
více participantů, protože s využitím deseti participantů je testy identifikováno více než 97 %
problémů (Nielsen & Landauer, 1993). Pokud je prováděn důkladný test využívající
podskupiny participantů, každá z podskupin bude složena z pěti osob. Celkový počet
participantů u tohoto druhu testu je tedy potom závislý na počtu podskupin.
3.1.4
Výběr úkolů a tvorba testovacích scénářů
Dalším bodem, který je potřeba vypracovat před začátkem testů je definování a výběr úkolů,
které budou participanti během testů vypracovávat. První zdroj, s jehož pomocí lze úkoly
určit jsou cíle testování. Další oblastí, sloužící pro identifikaci úkolů jsou typické úkony, které
uživatel může s elektronickými formuláři provádět. Například pro elektronický formulář Daň
z příjmů fyzických to jsou: vyplnění osobních údajů, vyplnění položek příjmů a výdajů,
kontrola chyb ve formuláři, tisk formuláře, elektronické podání formuláře a mnohé další.
Scénáře jsou participantům předkládány v písemné podobě, je potřeba je vypracovat tak, aby
byly krátké, napsané v jazyce uživatelů, dávaly participantovi všechna potřebná data a byly
jednoznačné, aby je každý participant bez obtíží pochopil. Při tvorbě scénářů opět hraje
významnou roli typ testu. U důkladných testů představuje každý úkol samostatný scénář.
Díky tomu lze lépe monitorovat údaje zaznamenávané během testu, jako jsou čas potřebný
k plnění scénáře, čas strávený pročítáním nápovědy, počet chyb a další. U jednoduchých testů
je možné, aby v jednom scénáři bylo participantovi zadáno více úkolů, monitorovaná data
jsou u těchto testů zaznamenávány opět jako v případě důkladných testů pro celý scénář.
3.1.5
Volba metrik a způsobu jejich měření
Stanovení dat, jež budou během testu zaznamenávána, závisí opět na typu a účelu daného
testu a také souvisí s vytyčenými cíli a obavami a konkrétním zadáním jednotlivých scénářů.
Při důkladných testech, jejichž účelem je odhalení chyb v testovaném formuláři vedoucí
k jeho vylepšení je důležité zejména monitorovat tato výkonnostní data: počet chybně
vyplněných polí, počet nevyplněných polí, počet nevybraných položek, počet stisknutých
kláves, počet stisknutí klávesy pro mazání textu, počet kliknutí levého tlačítka myši, počet
využití funkce pro kontrolu vyplněných údajů, počet chyb ve vyplněných údajích,
čas potřebný k vyplnění formuláře, čas strávený při práci s menu testovaného formuláře a čas
strávený čtením nápovědy. Pokud je prováděn důkladný test, jehož úkolem je porovnání dvou
vývojových verzí, nebo porovnání konkurenčních formulářů je k předešlému pozorování
důležité ještě pozorovat frustraci uživatele, zmatení a vyjádření jeho spokojenosti.
Ze subjektivních dat je potřeba zaznamenat snadnost naučení, snadnost použití, snadnost
94
vypracovávání konkrétních úkolů, pomoc nápovědy, celkový dojem z testovaného formuláře,
dojem z uspořádání formuláře, dojem z menu formuláře a dojem z uspořádání menu
formuláře.
Při jednoduchých testech jsou zaznamenávána tato výkonnostní data: splnění zadaného úkolu,
který je součástí testovacího scénáře. Tento údaj nabývá dvou hodnot, ano nebo ne. Dalším
sledovaným jevem je počet chyb, doba potřebná ke splnění scénáře, počet kliknutí levým
tlačítkem myši a počet stisknutých kláves. Ze subjektivních dat jsou zaznamenávány celkové
dojmy z testu, dojmy z testovaného formuláře, dojmy z menu formuláře a dojmy z plnění
zadaných úkolů.
Po stanovení, která data budou zaznamenávána, je důležité stanovit způsob jejich záznamu.
K tomuto účelu lze využít specializovaný software, jehož úkolem je zaznamenávání
požadovaných dat, video sekvencí a zvukových záznamů. Druhou možností, jak získávat
potřebná data je svěřit tuto práci jednotlivým členům testovacího týmu. K zachycení
subjektivních dat slouží dotazník Při vypracovávání dotazníků je v závislosti na definovaných
měřených datech vhodné využít strukturovaných hodnotících stupnic, například s testovaným
formulářem se mi pracovalo velmi snadno – snadno – ne snadno ale ne obtížně – obtížně
– velmi obtížně. Jednodušší hodnotící stupnici pak představuje typ odpovědí ano – ne.
U některých odpovědí typu ano nebo ne je vhodné ještě požádat participanty o zdůvodnění
jejich odpovědi.
3.1.6
Příprava testování a testování
Pro tyto účely lze zpravidla využit jednoduché prosté testovací místnosti, v níž se nachází
participant, testující a skupina pozorovatelů. K nezbytnému vybavení testovací místnosti,
v níž se bude testování elektronických formulářů odehrávat, patří počítač. Proto je nutné
specifikovat, jeho hardwarové a softwarové parametry. Testování musí probíhat na počítači,
který je svou konfigurací dostupný široké skupině potencionálních uživatelů testovaných
formulářů. V případě testování formulářů nacházejících se na již provozovaných webových
stránkách je nutné připojení k síti internet s rychlostí alespoň 1 Mb/s.
Na průběhu testování se podílí tým lidí, proto je nutné přiřadit členům testovacího týmu
jednotlivé role. Důležité je tedy stanovit administrátora testu, zastávajícího roli vedoucího
týmu. Tato osoba odpovídá za průběh testů, vyhodnocení získaných dat a vytvoření zprávy
zachycující průběh testu. Další rolí je moderátor, jehož úkolem je komunikovat s participanty,
zadávat jím scénáře a dotazníky. Dále je potřeba určit roli osoby zaznamenávající data během
testu, poslední rolí je role pozorovatele, který si během testu píše poznámky. Tyto role je
nutné definovat v případě důkladných testů, u kterých je vhodné využití alespoň dvou osob
zaznamenávajících potřebná data.
V případě jednoduchých testů je důležité stanovit roli administrátora, který zároveň zastává
funkce moderátora a osoby zaznamenávající požadovaná data. Po zpracování všech
předešlých bodů je před zahájením testů důležité provést pilotní test. Pilotní test vypadá zcela
stejně jako plánovaný skutečný test. Jeho účelem je odhalení nedostatků a problémů
v navřených scénářích a dotaznících, v plánovaném průběhu testu a v materiálech a datech
připravených pro test.
3.1.7
Analýza dat a vyhodnocení testu
Prvním krokem po provedení samotných testů je provedení sumarizace a tabulace získaných
dat. Data získaná během jednotlivých testů je nutné nejdříve rozdělit na výkonnostní
95
a subjektivní. Výkonnostní data naměřena jednotlivým participantům jsou dále uspořádána
do tabulek pro každý scénář zvlášť.
K porovnání konkurenčních variant formulářů, nebo jednotlivých vývojových verzí formuláře
slouží bodovací metoda. Nejdříve je nutné oddělit výkonnostní data naměřená pro jednotlivé
formuláře. Například čas, který potřebovali participanti k vyplnění prvního formuláře, a čas
který potřebovali k vyplnění druhého formuláře.
Z takto získaných hodnot je poté pro každý formulář zvlášť vypočítán aritmetický průměr
z výsledků všech participantů. Po vypočítání všech hodnot je sestaveno pořadí testovaných
formulářů vždy podle daného kritéria, tedy dat zaznamenaných během testu. Podle
dosaženého pořadí jsou poté formuláře obodovány.
U testů zaměřených na nalezení chyb, jejichž odstranění vede ke zlepšení použitelnosti
formulářů, jsou nejdůležitějším ukazatelem pro jejich identifikaci data zaznamenávající počet
chyb, kterých se participant dopustil během vypracovávání zadaného scénáře. Dále je potřeba
z naměřených dat uspořádaných do tabulek vytvořit pro každý zaznamenávaný ukazatel
samostatný graf, ve kterém lze lépe vypozorovat určité trendy, překvapivé výsledky a odlehlé
hodnoty. Na základě těchto pozorování lze poté odhalit další problémy a nedostatky
v testovaných formulářích. U důkladných testů je po nalezení všech problémů důležité
provést jejich klasifikaci na základě závažnosti a frekvence jejich výskytu. Na základě
vážnosti lze chyby rozdělit na kritické chyby bránící v dokončení úkolu, chyby frustrující
a vytvářející výrazné zpoždění práce, chyby mající malý vliv na použitelnost a drobné chyby.
Na základě zjištěných hodnot lze doporučit příslušná opatření, třeba volbu jednoho
z konkurenčních produktů, případně navrhnout technické změny, které povedou k vyšší
použitelnosti stávajícího produktu.
3.2
3.2.1
Případová studie aplikace navržené metodiky
Předmět testování
Předmětem provedeného testování byly formuláře státní sociální podpory nacházející
se na webovém portálu ministerstva práce a sociálních věcí (https://portal.mpsv.cz). Důvodem
pro otestování těchto formulářů, je skutečnost, že na stránkách ministerstva práce a sociálních
věcí existuje velké množství formulářů, které ještě nemají svojí kompletní podobu, nebo je
teprve plánován jejich převod do elektronické podoby. Z tohoto důvodu se jeví jako velice
vhodné provést testování jmenovaných formulářů, protože odhalené nedostatky mohou být
použity pro zkvalitnění tvorby nových elektronických formulářů a odstranění chyb v těch
stávajících. Z testované oblasti byly konkrétně vybrány formuláře žádosti o přídavek na dítě
a žádosti o pohřebné a to proto, že jsou svou strukturou, uspořádáním i obsahem velice
podobné ostatním elektronickým formulářům, které se na daných stránkách nacházejí.
3.2.2
Cíl testování
V rámci případové studie byly definovány následující cíle a obavy:

96
Budou uživatelé schopni nalézt požadované webové stránky a informace, které
se na nich nacházejí? (Naleznou uživatelé potřebný elektronický formulář? Budou
uživatelé schopni určit, zda lze daný formulář podat elektronicky? Naleznou uživatelé
na stránkách s formuláři informace potřebné k práci s danými formuláři a jejich
podání?)



3.2.3
Zvládnou uživatelé vyplnit elektronický formulář? (Vyplní uživatelé formulář Žádosti
o pohřebné zadanými údaji? Vyplní uživatelé formulář Žádosti o přídavek na dítě
zadanými údaji? Zvládnou uživatelé vyplnit formuláře bez chyb?)
Budou uživatelé schopni správně použít položky formulářového menu? (Využijí
uživatelé navigačních položek menu? Použijí uživatelé pro práci
s formulářem vždy vhodnou položku z menu sloužící k jeho uložení, podání, tisku
a podobně?)
Výběr participantů
K testování mohla být vybrána pouze zletilá, svéprávná osoba starší 18 let. Vybraná osoba
musela mít alespoň základní uživatelské znalosti s používáním počítače a internetu.
K testování daných formulářů bylo vybráno v souladu s navrhovanou metodikou celkem pět
participantů.
Nábor proběhl opět ve snaze o dodržení finanční nenáročnosti testu formou vlastního hledání
a vytipování vhodných participantů. Ke zjištění vhodnosti využití oslovených osob byl využit
písemný dotazník, jehož úkolem bylo zachycení profilu participanta a z něj vyplývající
potvrzení vhodnosti jeho spolupráce při testech.
3.2.4
Výběr úkolů a tvorba testovacích scénářů
K definování úkolů byly využity typické úlohy, které uživatelé s formuláři provádí. Na jejich
základě byly definovány úkoly, které lze s formuláři provádět. Pro výběr konkrétních úkolů,
které byly předloženy participantům, bylo nutné stanovit jejich časovou náročnost a potřebné
hardwarové, softwarové a datové zdroje.
Ze stanovených úkolů byly po zohlednění jejich důležitosti vybrány následující konkrétní
úkoly: nalezení webových stránek s testovanými formuláři, zjištění, zda lze formulář podat
elektronicky, nalezení podporovaných webových prohlížečů, nalezení certifikátů nutných pro
elektronické podání, vyplnění formuláře Žádosti o pohřebné, vyplnění formuláře Žádosti
o přídavek na dítě, uložení vyplněného formuláře, uložení vyplněného formuláře na disk.
Z těchto vybraných úkolů byly poté sestaveny konkrétní podoby jednotlivých testovacích
scénářů.
S ohledem na plánovanou délku testovacích sezení kolem jedné hodiny byla zvolena stručná
podoba testovacích scénářů, tak aby měli participanti dostatek času na vypracování zadaných
úkolů a dostatečně se na test koncentrovali (Nielsen, 2005). Každý scénář obsahuje ještě před
samotným zadáním jednotlivých úkolů krátký popisek situace, aby uživatel lépe pochopil,
co je po něm žádáno.
První scénář je zaměřen na ověření skutečnosti, zda jsou uživatelé schopni nalézt požadovaný
formulář a provést jeho elektronické podání. K tomuto účelu jsou stanoveny dva úkoly. První
zkoumá, zda jsou uživatelé schopni nalézt požadovaný formulář, druhý dává participantům
za úkol zjistit, zda lze elektronicky podat zadané formuláře.
Druhý scénář se zaměřuje na definovaný účel zjištění, jaké nástroje jsou potřebné k vyplnění
a podání formulářů. V prvním úkolu jsou uživatelé požádaní, aby nalezli seznam prohlížečů,
které tento produkt podporuje. Toto zjištění je vhodné hlavně pro reálné použití tak, aby
si osoba podávající formulář mohla stáhnout potřebný software a neměla s jejich vyplňováním
a podáváním žádné problémy. Druhý úkol nabádá uživatele ke zjištění, u jakých společností
mu může být vystaven certifikát nutný k elektronickému podání.
97
Třetí scénář je zaměřen na zkoumání schopnosti participantů vyplnit konkrétní elektronický
formulář. Pro tento test byl vybrán formulář žádosti o pohřebné. První úkol prověřuje
schopnost uživatelů doplnit tento předvyplněný formulář zadanými údaji. Druhým úkolem je
znovu uložení formuláře zpět na disk, tak aby byly vyplněné údaje zálohovány a mohlo s nimi
být později ještě pracováno. Poslední úkol žádá participanty o uložení formuláře tak, aby
mohl být později vytištěn. Jedná se tedy o uložení formuláře do formátu PDF, formulář pak
vypadá přesně jako jeho papírová předloha.
Čtvrtý scénář je zaměřen na schopnost uživatelů vyplnit formulář žádosti o přídavek na dítě.
Hlavním úkolem tohoto scénáře je zjištění faktu, zda uživatelé zvládnou vyplnit formulář
správně všemi zadanými údaji, nebo budou mít s některými položkami potíže. Toto zjištění je
velmi důležité pro posouzení celkové kvality formuláře.
3.2.5
Volba metrik a způsobu jejich měření
Při testech vybraných elektronických formulářů byla zaznamenávána data týkající se splnění
zadaných úkolů. Tato data nabývají dvou hodnot, splnil nebo nesplnil. Dalším sledovaným
jevem byl počet chyb, kterých se participant dopustil
v jednotlivých úkolech, doba potřebná ke splnění zadaného scénáře, počet kliknutí levým
tlačítkem myši a počet stisknutých kláves.
Záznam sledovaných dat dostal na starost testovací tým. K měření času byly použity stopky
a k zaznamenání počtu stisknutých kláves a počtu kliknutí bylo využito jednoduchého
monitorovacího programu.
3.2.6
Příprava testování a testování
Nejprve bylo realizováno pilotní uživatelské testování, kdy bylo ověřeno technické,
administrativní a personální zajištění tohoto testování. Poté bylo provedeno uživatelské
testování jednotlivých scénářů jednotlivými participanty, přičemž byly změřeny hodnoty
jednotlivých metrik.
3.2.7
Analýza dat a vyhodnocení testu
Při plnění jednotlivých scénářů bylo vždy měřeno, zda participant tento scénář splnil a do jaké
míry, čas, který ke splnění scénáře potřeboval, počet správných a špatných kliknutí myší,
množství stisknutých kláves a subjektivní hodnocení a připomínky získané dotazníkem.
Na získaná data byly aplikovány metody explorativní analýzy dat, data byla znázorněná jak
prostřednictvím tabulek, tak i prostřednictvím grafů. Z provedené analýzy dosažených
výsledků bylo nutné specifikovat jednotlivé problémy s použitelností, které participanti
během testů měli. Dalším krokem bylo na základě těchto problémů navrhnout vhodná
opatření, aby došlo k odstranění nalezených problémů.
Scénář č. 1
Problémy:


Problém s nalezením vhodného formuláře přes menu pro výběr formuláře v levé části
stránky, protože neobsahuje kompletní názvy formulářů.
Na stánkách pro výběr formuláře se nedá určit, zda ho lze elektronicky podat.
U konkrétního formuláře potom dlouho trvá, než je tato možnost uživatelem objevena
ve formulářovém menu.
Doporučení:
98


Horní lišta záložek na hlavní stránce formulářů státní sociální podpory by měla být
výraznější, aby si jí uživatelé při vstupu na stránky hned všimli a rychleji nalezli to, co
potřebují.
U popisu jednotlivých formulářů v záložce výběr formulářů by se měl nacházet údaj
o tom, zda lze provést elektronické podání formuláře či nikoliv.
Scénář č. 2
Problémy:

Problém s nalezením podporovaných prohlížečů, protože se nacházeli až v dolní
polovině části stránky technické podpory. V horní polovině stránky je odborný popis
prohlížeče, který běžnému uživateli neposkytne potřebnou informaci.
Doporučení:

Umístit seznam internetových prohlížečů, v nichž aplikace funguje hned k popisu
internetového prohlížeče namísto umístění ve spodní části stránky.
Scénář č. 3
Problémy:






Špatné logické uspořádání formuláře, participantům se zdál přehledný. Nedostatečně
graficky oddělené jednotlivé oddíly formuláře.
Problém při výběru více položek z roletkového menu.
Při vyplňování položek dávky v nezaměstnanosti, rodinné dávky a důchod nastal
problém, pokud osoba nepobírala některou z těchto dávek. Participanti očekávali
nabízenou odpověď Ne, toto pole se však mělo proškrtnout.
Problém s velikostí výběrových tlačítek a hlavně jejich popisku v oddílu způsob
výplaty dávky. Možnost výplaty pomocí poštovní poukázky v ostatních údajích
zanikala a byla snadno přehlédnutelná.
Při ukládání formuláře pro jeho pozdější využití na pevný disk použili všichni
testovaní participanti nejprve možnost vytisknout / uložit vyplněný formulář namísto
uložení na disk.
Problém při výběru vhodné položky pro uložení formuláře na disk. Možnosti uložit
pro datové schránky a uložit vyplněné údaje na disk mají totiž obě v popisku napsáno,
že uloží vyplněné údaje formuláře na lokální disk.
Doporučení:




Lépe od sebe graficky odlišit jednotlivé oddíly formuláře, nebo vytvořit průvodce,
který umožní uživateli vyplnit formulář po menších částech.
U výběrových polí s více možnostmi zobrazit nápovědu, že pro výběr více možností
slouží tlačítko Ctrl nebo Shift.
Přepracovat oddíl způsob výplaty dávky tak, aby byla lépe patrná možnost výběru
poštovní poukázky, například větší mezery mezi možnostmi a větší popisky.
Výstižněji zpracovat popisky u menu formuláře, aby bylo na první pohled patrné,
k čemu daná možnost slouží.
Scénář č. 4
Problémy:

Položka údajů o společně posuzovaných osobách pro účely vyplácení sociálních dávek
v rámci Evropské unie není označena jako povinná, přitom je nutné jí
99




k podání formuláře vyplnit.
V oddílu žadatele jsou nevýrazné položky příjmů a nezaopatřenosti, participanti je
totiž nevyplnili.
Participanti nevěděli, co mají psát do položek dalších dětí, pokud žadatel další děti
nemá, očekávali možnost proškrtnutí položek, ta však ve formuláři není.
Do pole čísla účtu nelze psát, dokud není vybrána možnost platby na bankovní účet,
což participanty mátlo.
Doporučení:





4
Položku údajů o společně posuzovaných osobách pro účely vyplácení sociálních
dávek v rámci Evropské unie označit jako povinně vyplňovanou položku.
U kolonek nezaopatřenost zobrazit nápovědu, kdo je považován
za nezaopatřeného žadatele, nebo nezaopatřené dítě.
Více zvýraznit položky příjmy a nezaopatřenost, aby byly lépe viditelné.
Při kliknutí do pole pro zadání čísla účtu banky automaticky vybrat možnost.
Diskuze
Navržená metodika je založena na využití metody uživatelského testování. Kromě této
metody bývá v inženýrství použitelnosti také často aplikována metoda heuristického
hodnocení, která nevyžaduje provádění experimentů prostřednictvím participantů řešících
zadané úlohy, ale vyžaduje seznam heuristických kritérií pro daný typ uživatelského rozhraní.
V současné době neexistuje podobný seznam, nicméně v případě, že by tento seznam byl na
základě empirických zkušeností vytvořen, bylo by možno využívat i tuto metodu, která je
často levnější, než metoda uživatelského testování. Je však otázkou, zda mají všechny
elektronické formuláře shodné aspekty, aby na ně bylo možno aplikovat stejnou sadu
heuristických kritérií.
Závěr
5
Po stanovení kritérií a požadavků na testování a hodnocení použitelnosti elektronických
formulářů veřejné správy byla na základě výsledků rešerše stávajících metod testování
a hodnocení použitelnosti grafického uživatelského rozhraní software zvolena metoda
uživatelského testování použitelnosti.
Následně byla navržena metodika testování a hodnocení použitelnosti elektronických
formulářů veřejné správy využívající tuto metodu. Navržená metodika zahrnuje formulaci
předmětu a cíle testování, výběr participantů, výběr úkolů a tvorbu testovacích scénářů,
způsob měření použitelnosti, podobu testovacího prostředí, způsob sestavení testovacího
týmu, průběh a provedení pilotního testu a výslednou analýzu a způsob vyhodnocení dat.
Na základě vypracované metodiky proběhlo testování a hodnocení použitelnosti
elektronických formulářů státní sociální podpory nacházejících se na webovém portálu
ministerstva práce a sociálních věcí. Konkrétně se jednalo o formuláře žádosti o pohřebné
a žádosti o přídavek na dítě. Pomocí testování byly identifikovány nedostatky
a problémy s použitelností jak v testovaných formulářích, tak i na stránkách formulářů státní
sociální podpory, na kterých se tyto formuláře nacházejí. Zároveň byly navrženy doporučení
sloužící k jejich odstranění. Z těchto doporučení byla odvozena sada obecných doporučení
sloužící vývojářům budoucích elektronických formulářů veřejné správy. Tato doporučení
slouží k odstranění problémů s použitelností nově vytvářených formulářů.
100
Poděkování
Tento článek byl zpracován s podporou výzkumného projektu MV ČR č. VF20112015018
s názvem „Bezpečnost občanů – krizové řízení BOKR“.
Budinská, I. (2009). Klasifikace a porovnání metod testování a hodnocení použitelnosti software.
Diplomová práce. Pardubice: Univerzita Pardubice Fakulta ekonomicko-správní.
Černá, M., & Poulová, P. (2009). User testing of language educational portals. E+M Ekonomie
a management, 12(3), 104-117.
Hrom, J. (2003). The Usability Methods Toolbox. Retrieved from http://jthom.best.vwh.net/usability/.
Chudoba, M. (2010). Testování a hodnocení použitelnosti elektronických formulářů VS. Bakalářská
práce. Pardubice: Univerzita Pardubice.
Komárková, J., Máchová, R., & Bednarčíková, I. (2008). Požadavky uživatelů na kvalitu webových
stránek městského úřadu. E+M Ekonomie a management, 11(3), 116-125.
Krug, S. (2003). Web design: nenuťte uživatele přemýšlet!. Brno: Computer Press.
Myšková, R. (2006). Ekonomický rozměr hodnoty informace. Scientific Papers of the University
of Pardubice, Series D, 10(1), 228-232.
Nilelsen, J. (1994a). Usability Engineering. San Francisco: Morgan Kaufmann.
Nielsen, J. (1994b). Usability inspection methods. New York: John Wiley & Sons.
Nielsen, J. (2005). Time Budgets for Usability Sessions. Retrieved from
http://www.useit.com/alertbox/usability_sessions.html.
Nielsen, J. (2010). How to Conduct a Heuristic Evaluation. Retrieved from
http://www.useit.com/papers/heuristic/heuristic_evaluation.html.
Nielsen, J., & Landauer, T. K. (1993) A mathematical model of the finding of usability problems.
In Proceedings of ACM INTERCHI'93 (pp. 206-213). Amsterdam: ACM.
Sedlák, P. et al. (2010). Nový přístup k testování a hodnocení kvality map. Geodetický
a kartografický obzor. 56(9), 182-188.
Usability Evaluation. (2012) Usability Evaluation methods. Retrieved from
http://www.usabilityhome.com/.
Usability.gov. 2007. Learn about usability testing. Retrieved from
http://www.usability.gov/refine/learnusa.html.
101
Call for paper / Informace pro autory
Detailed information about the scope of the journal and its sections including the review process
can be found here. Templates for the articles are available on the journal website.
Podrobné informace o zaměření časopisu a jednotlivých sekcích včetně průběhu recenzního
řízení získáte zde. Šablony pro psaní příspěvků jsou k dispozici na webových stránkách.
December issue / Prosincové číslo
Deadline 18 October 2015 / Termín uzávěrky 18. říjen 2015
th
June issue / Červnové číslo
Deadline 27 March 2016 / Termín uzávěrky 27. března 2016
th
Acta Informatica Pragensia
Publisher
Layout
Daniel Hamerník & Zdeněk Smutný
Faculty of Informatics and Statistics
The journal Acta Informatica Pragensia
nám. W. Churchilla 4, 130 67 Praha 3
Editor-in-Chief
is open access and has no charge
for article publishing.
Stanislava Mildeová
e-mail: [email protected], tel.: +420 224 095 474
Abstracting & Indexing
Research Papers in Economics (RePEc), Open Archives Initiative (OAI), Directory of Open Access
Journals (DOAJ), Google Scholar, Academic Journals Database, ResearchBib Journal Database,
National Library of the Czech Republic (WebArchiv project).
The journal Acta Informatica Pragensia is also included in the government list
of peer-reviewed journals published in the Czech Republic.
General partner University of Economics, Prague
Generální partner Vysoké školy ekonomické v Praze
http://aip.vse.cz

University of Economics, Prague

Transkript

Podobné dokumenty

18. 7. 2011

IGS 2015 - ROZPIS DÍLEN - PÁTEK 2. 10. 2015 / WORKSHOPS

PřEDMěTY PRO RYCHLÉ POUŻITÍ

Jan Neruda - poems

informační systémy 2

IGS 2015 - ROZPIS DÍLEN - SOBOTA 3. 10. 2015 / WORKSHOPS

Finální dokumentaci projektu

Pravidla OpenAIRE 1.1

tutoriál CodeBlocks 10.05 v1.1.cz

Endovaskulární léčba varixů dolních končetin

Únor 2010 - agilia.cz

PHP Developer

University of Economics, Prague

Průmysl 4.0 ve vazbě na kvalifikovanou pracovní sílu v oboru IT_ICT

Vulvovaginální kandidózy u žen ve spádové oblasti ZÚ Ostrava poster

Svobodné IT firmy v ČR - Jan Miřacký Photography

klikněte zde

Open Up! Creative Placemaking Festival

Metody řízení projektů - Centrum pro rozvoj výzkumu pokročilých

OBCHODNÍ PODMÍNKY

The Scrum Guide

CHROMIUM