ACTA INFORMATICA PRAGENSIA

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 University of Economics, Prague 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) University of Economics, Prague

Eve Mitleton-Kelly University of London

Klára Antlová Technical University of Liberec

Ingeborg Němcová University of Economics, Prague

Martin Boháček University of Economics, Prague

Jan Rauch University of Economics, Prague

Tomáš Bruckner University of Economics, Prague

Václav Řezníček University of Economics, Prague

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ý University of Economics, Prague

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

University of Economics, Prague


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, nám. W. Churchilla 4, 130 67 Praha 3, Czech Republic  [email protected]

4

ACTA INFORMATICA PRAGENSIA

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


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  [email protected]

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.

Seznam použitých zdrojů 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


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


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  [email protected]

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


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




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


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  [email protected]

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.

Seznam použitých zdrojů 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


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.

Seznam použitých zdrojů 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


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, nám. W. Churchilla 4, 130 67 Praha 3, Czech Republic  [email protected]

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


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

Seznam použitých zdrojů 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

ACTA INFORMATICA PRAGENSIA

Recommend Documents