ACTA INFORMATICA PRAGENSIA

Transkript

1 Scientific Journal Vědecký časopis ACTA INFORMATICA PRAGENSIA University of Economics, Prague Vysoká škola ekonomická v Praze Faculty of Informatics and Statistics Fakulta informatiky a statistiky

2 Editorial Board / Redakční rada Stanislava Mildeová (Editor-in-Chief) University of Economics, Prague Klára Antlová Technical University of Liberec Martin Boháček University of Economics, Prague Tomáš Bruckner University of Economics, Prague Vesna Čančer University of Maribor Rasa Daugėlienė Kaunas University of Technology Jiří Fišer J. E. Purkyne University, Usti nad Labem Milan Houška Czech University of Life Sciences, Prague Miloslav Hub University of Pardubice Petr Kučera Independent consultant, Prague Petr Máša Partners Financial Services, Prague Jan Ministr VSB-Technical University of Ostrava Eve Mitleton-Kelly University of London Ingeborg Němcová University of Economics, Prague Jan Rauch University of Economics, Prague Václav Řezníček University of Economics, Prague Markus Schwaninger University of St. Gallen Antonín Slabý University of Hradec Kralove Zdeněk Smutný University of Economics, Prague Olga Štěpánková Czech Technical University, Prague Prokop Toman Czech University of Life Sciences, Prague Milan Turčáni Constantine the Philosopher University, Nitra Viktor Vojtko University of South Bohemia, Ceske Budejovice Jan Voráček College of Polytechnics, Jihlava Contact address / Kontakt: Acta Informatica Pragensia University of Economics, Prague nám. W. Churchilla 4, Praha 3, Czech Republic web: aip.vse.cz Technical editors / Editoři: Zdeněk Smutný & Václav Řezníček University of Economics, Prague zdenek.smutny@vse.cz tel.: ACTA INFORMATICA PRAGENSIA ISSN (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.

3 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ů.

4 Acta Informatica Pragensia, 2015, 4(1): 4 17 DOI: /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 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 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 The comparison is further enriched by the results of the unpublished survey in the global logistics company which was conducted also in 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, Praha 3, Czech Republic martin.tomanek@vse.cz 4 ACTA INFORMATICA PRAGENSIA Volume 04 Number

5 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 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 Metodika Scrum se skládá ze tří pilířů, tří rolí tvořící Scrum tým, čtyř činností (schůzek) a tří artefaktů. Volume 04 Number ACTA INFORMATICA PRAGENSIA 5

6 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): 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ů 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 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

7 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í 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 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 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é Volume 04 Number ACTA INFORMATICA PRAGENSIA 7

8 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): 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 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 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) 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

9 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 Plánovací schůzka Obr. 2. Procesní model Scrum. Zdroj: autor 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 Volume 04 Number ACTA INFORMATICA PRAGENSIA 9

10 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 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 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é 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, & Ghilic- Micu, 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

11 & 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 metodik v prostředí nadnárodní logistické společnosti 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 8 th Annual State of Agile Survey Průzkum agilního řízení v ČR 2013 Průzkum agilního řízení ve společnosti Celosvětové (VersionOne, 2014) Česká republika (Pulkert, 2014) Česká republika, Německo, Malajsie, USA Autor článku Tab. 1. Přehled analyzovaných průzkumů. Zdroj: autor Volume 04 Number ACTA INFORMATICA PRAGENSIA 11

12 Procento respondentů 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 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 ČR 60% 50% 53% 40% 30% 20% 10% 7% 27% 21% 32% 32% 19% 9% 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

13 Procento respondentů 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ě Svět ČR 50% 46% 40% 38% 30% 20% 27% 21% 22% 14% 13% 19% 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í. Volume 04 Number ACTA INFORMATICA PRAGENSIA 13

14 Agilní technika 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) 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

15 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. Volume 04 Number ACTA INFORMATICA PRAGENSIA 15

16 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 Baumeister, A., & Ilg, M. (2013). Financial Management and Control of Iterative Software Processes. In Annual International Conference on Accounting & Finance (s ). doi: / _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 Benefield, G. (2008). Rolling Out Agile in a Large Enterprise. In 41st Annual Hawaii International Conference on System Sciences. doi: /HICSS Buchalcevová, A. (2006). Stav používání agilních metodik v ČR. Systémová integrace, 13(4), 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 ). New York: ACM. doi: / 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: / Pulkert, D. (2014). Průzkum agilního řízení v ČR Etnetera. Dostupné z Schwaber, K., & Sutherland, J. (2013, srpen). The Scrum Guide, Průvodce Scrumem: Pravidla hry. Dostupné z CS.pdf Stavru, S. (2014). A critical examination of recent industrial surveys on agile method usage. Journal of Systems and Software, 94, doi: /j.jss Stoica, M., Mircea, M., & Ghilic-Micu, B. (2013). Software Development: Agile vs. Traditional. Informatica Economica, 17(4), doi: /issn / Sumrell, M. (2007). From Waterfall to Agile - How does a QA Team Transition? In Proceedings of the Agile Conference (AGILE) 2007 (s ). Washington: IEEE Computer Society. doi: /AGILE 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 ). doi: /AGILE 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 ). Reading: ACPI. Tomanek, M., & Klima, T. (2015). Penetration Testing in Agile Software Development Projects. International Journal on Cryptography and Information Security, 5(1). doi: /ijcis ACTA INFORMATICA PRAGENSIA Volume 04 Number

17 VersionOne. (2006). Survey: The State of Agile Development. VersionOne Inc. Dostupné z VersionOne. (2014, červen 30). 8th Annual State of Agile Survey. VersionOne Inc. Dostupné z Volume 04 Number ACTA INFORMATICA PRAGENSIA 17

18 Acta Informatica Pragensia, 2015, 4(1): DOI: /j.aip.57 Peer-reviewed paper Míry kvality v procesním modelování Measures of Quality in Business Process Modelling Radek Hronza *, Josef Pavlíček *, Richard Mach, Pavel Náplava * Abstrakt Procesní analýza a modelování byznys procesů je jedna z významných částí aplikované (byznys) informatiky. Kvalita byznys procesů (diagramů) je v této oblasti velmi důležitá. Cílem každého procesního analytika by měla být tvorba srozumitelných, jednoznačných a bezchybných procesních diagramů. Pokud je proces řádně popsán, lze jej využít jako vstup pro detailnější analýzu a optimalizaci. Lze předpokládat, že řádně vytvořený a popsaný diagram byznys procesu (obdobně jako řádně napsaný algoritmus) bude obsahovat charakteristiky, které lze matematicky popsat. Kromě toho by bylo možné vytvořit nástroj, který by pomohl procesním analytikům vytvářet vhodné procesní diagramy. V rámci tohoto přehledového článku bude realizována rešerše dostupné literatury, jejíž cílem je nalezení a následné provedení analýzy míry návrhu a kvality byznys procesů. Rešerší bylo nalezeno, že zmíněná oblast již byla předmětem výzkumu. Bylo nalezeno třicet tři vědeckých publikací a dvacet dva měr kvality. Závěrem lze říci, že nalezené vědecké publikace a míry kvality nereflektují všechny důležité atributy jasnosti, jednoduchosti a úplnosti modelů byznys procesů. Z toho důvodu by bylo vhodné obohatit existující míry kvality diagramů byznys procesů. Klíčová slova: Modelování byznys procesů, analýza byznys procesů, byznys procesy, míry kvality, BPMN. Abstract Business process modelling and analysing is undoubtedly one of the most important parts of Applied (Business) Informatics. Quality of business process models (diagrams) is crucial for any purpose in this area. The goal of a process analyst s work is to create generally understandable, explicit and error free models. If a process is properly described, created models can be used as an input into deep analysis and optimization. It can be assumed that properly designed business process models (similarly as in the case of correctly written algorithms) contain characteristics that can be mathematically described. Besides it will be possible to create a tool that will help process analysts to design proper models. As part of this review will be conducted systematic literature review in order to find and analyse business process model s design and business process model s quality measures. It was found that mentioned area had already been the subject of research investigation in the past. * Center for Knowledge Management, Faculty of Electrical Engineering, Czech Technical University in Prague, Technická 2, Praha 6 - Dejvice, Czech Republic hronzrad@fel.cvut.cz, pavlijo5@fel.cvut.cz, naplava@fel.cvut.cz Faculty of Information Technology, Czech Technical University in Prague, Technická 2, Praha 6 - Dejvice, Czech Republic machrich@fit.cvut.cz 18 ACTA INFORMATICA PRAGENSIA Volume 04 Number

19 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. 1 Úvod 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. Volume 04 Number ACTA INFORMATICA PRAGENSIA 19

20 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. 2 Rešerše dostupné literatury 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

21 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 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ů. 3 Výsledky rešerše dostupné literatury 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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 21

22 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

23 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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 23

24 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 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ž 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 Nejvíce publikací připadá na rozpětí roků 2006 až ACTA INFORMATICA PRAGENSIA Volume 04 Number

25 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 č USA FIN NLD PRT DEU AUT MYS TUN ESP CHN THA POL AUS 4 Diskuze Obr. 3. Počty relevantních informačních zdrojů dle původu. Zdroj: autoři 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é Volume 04 Number ACTA INFORMATICA PRAGENSIA 25

26 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ě. 5 Závěr Odpovědi na otázky, které byly náplní provedené a popsané rešerše, můžeme shrnout následovně: 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? 26 ACTA INFORMATICA PRAGENSIA Volume 04 Number

27 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, doi: /bf Budgen, D., & Brereton, P. (2006). Performing Systematic Literature Reviews in Software Engineering. In Proceedings of the 28th International Conference on Software Engineering (pp ). New York, NY, USA: ACM. doi: / Cardoso, J. (2005). How to measure the control-flow complexity of web processes and workflows. In L. Fischer (Ed.), Workflow Handbook 2005 (pp ). Lighthouse Point: WfMC. Cardoso, J. (2006). Process control-flow complexity metric: An empirical validation. In IEEE International Conference on Services Computing (pp ). Chicago, IL, USA: IEEE. doi: /scc Cardoso, J. (2007). Control-flow Complexity Measurement of Processes and Weyuker-s Properties. International Journal of Computer, Control, Quantum and Information Engineering, 1(8), Cardoso, J. (2008). Business process control-flow complexity: Metric, evaluation, and validation. International Journal of Web Services Research, 5(2), Volume 04 Number ACTA INFORMATICA PRAGENSIA 27

28 Cardoso, J., Mendling, J., Neumann, G., & Reijers, H. A. (2006). A discourse on complexity of process models. In Business process management workshops (pp ). 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 ). Hangzhou: IEEE. doi: /apscc 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), Gruhn, V., & Laue, R. (2006a). Adopting the Cognitive Complexity Measure for Business Process Models. In 5th IEEE International Conference on Cognitive Informatics (pp ). Beijing: IEEE. doi: /coginf 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), doi: /tse 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 ). Vienna: IEEE. doi: /cbi Huang, Z., & Kumar, A. (2009). New Quality Metrics for Evaluating Process Models. In Business Process Management Workshops (pp ). Milano: Springer Berlin Heidelberg. doi: / _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 ). Khlif, W., Zaaboub, N., & Ben-Abdallah, H. (2010). Coupling Metrics for Business Process Modeling. WSEAS Transactions on Computers, 9(1), 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 ). Wroclaw: IEEE. Lassen, K. B., & van der Aalst, W. M. (2009). Complexity metrics for workflow nets. Information and Software Technology, 51(3), Latva-Koivisto, A. M. (2001). Finding a complexity measure for business process models - Research Report. Helsinki: Helsinki University of Technology. Retrieved from 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 ). 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 density.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 ). 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), doi: /itj 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

29 (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 ). 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 ). Phuket: IEEE. doi: /snpd 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 ). 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 ). Potsdam: Springer Berlin Heidelberg. doi: / _19 Rolón, E., Cardoso, J., García, F., Ruiz, F., & Piattini, M. (2009). Analysis and Validation of Control- Flow Complexity Measures with BPMN Process Models. In Enterprise, Business-Process and Information Systems Modeling SE - 6 (pp ). Amsterdam: Springer Berlin Heidelberg. doi: / _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), doi: /tsc 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 ). New York: ACM. doi: / Shao, J., & Wang, Y. (2003). A new measure of software complexity based on cognitive weights. Canadian Journal of Electrical and Computer Engineering, 28(2), doi: /cjece 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 ). Bali: IEEE. doi: /icacsis Thammarak, K. (2010). Survey Complexity Metrics for Reusable Business Process. In 1st National Conference on Applied Computer Technology and Information System (pp ). 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 ). Amsterdam: Springer Berlin Heidelberg. doi: / _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 ). Trondheim: CAiSE 07. Retrieved from 247/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 ). 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 ). Montpellier: Springer Berlin Heidelberg. doi: / _36 Volume 04 Number ACTA INFORMATICA PRAGENSIA 29

30 Acta Informatica Pragensia, 2015, 4(1): DOI: /j.aip.58 Peer-reviewed paper Generated Report of the ORD BORM Model Jakub Tůma *, Marek Pícka *, Petr Hanzlík * Abstract This contribution focuses on documentation of model-to-model transformation, respectively on converting model represented by BORM notation (Business Object Relation Modelling) to a HTML-based textual report. The transformation is from the management-level business process model into the operation-level business process model. The operation-level model should be textual and tailored for each individual participant. This article introduces a modular extension of OpenCASE software that utilizes OpenCASE knowledge base and API to generate textual reports automatically. This report is based on HTML language, because of the portability and easy distribution of the format. Such report is easy to understand even for business people without hard technical skills. We present both the transformation, and the modular extension on a case study. Keywords: BORM, Transformation, Tool, Report, HTML, Case study. 1 Introduction Models created in CASE tools are probably the most comprehensive description of system. However, these models, and relationships among them, can be difficult to understand. Even though BORM diagrams are generally easy to understand, it may still be challenging to fully comprehend the situations modelled, especially for non-specialists and businesspeople. A textual report describing BORM diagram can significantly contribute to better understanding of problem as a whole and increase the accessibility of information stored within models. A repository of CASE tool can be used as a source of data for generating such documentation. When a report is generated automatically from models, the safe consistency between the model and documentation is guaranteed. Another advantage is the possibility to reinstate documentation when source model changes. We want to present our approach for flexible modelling of business processes both at the management and operations level. This approach consists of combining a suitable modelling method (BORM Business Object Relation Modelling) and developing an original software tool (OpenCASE) to support it, as well as to perform automated model transformations. This article focuses on transformation of source model created in CASE tool to textual output model and technologies used for implementation of this transformation. Input of this transformation is a model using BORM notation, output of the transformation is model represented as a HTML report. * Department of Information Engineering, Faculty of Economics and Management, Czech University of Life Sciences, Prague, Kamýcká 129, Praha 6, Czech Republic jtuma@pef.czu.cz, picka@pef.czu.cz, petr.hanzlik6@gmail.com 30 ACTA INFORMATICA PRAGENSIA Volume 04 Number

31 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 Volume 04 Number ACTA INFORMATICA PRAGENSIA 31

32 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: Business architecture diagram Object relationship diagram (ORD) (see Figure 1) Class diagram 32 ACTA INFORMATICA PRAGENSIA Volume 04 Number

33 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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 33

34 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

35 2. a manually defined 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) Volume 04 Number ACTA INFORMATICA PRAGENSIA 35

36 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

37 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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 37

38 Fig. 5. Operation model (manual) for participant Customer. Source: authors. Fig. 6. Operation model (manual) for participant Deliverer. Source: authors. 38 ACTA INFORMATICA PRAGENSIA Volume 04 Number

39 Fig. 7. Operation model (manual) for participant Economics department. Source: authors. Fig. 8. Operation model (manual) for participant Supplier. Source: authors. Volume 04 Number ACTA INFORMATICA PRAGENSIA 39

40 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

41 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 ). Berlin: Springer. Cabot, J., Pau R. & Raventós, R. (2010). From UML/OCL to SBVR specifications: A challenging transformation. Information Systems, 35(4), Volume 04 Number ACTA INFORMATICA PRAGENSIA 41

42 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 ). 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 ). Prague: Czech University Life Sciences Prague. Molhanec, M. (2011). Some Reasoning Behind Conceptual Normalisation. In Information Systems Development: Business Systems and Services (pp ). Berlin: Springer. OMG. (2008). Semantics of Business Vocabulary and Rules (SBVR) Specification, v 1.0 (formal/ ). Retrieved from OpenCASE Tool. (2014). Retrieved from Pergl, R., & Tůma, J. (2012). OpenCASE a tool for ontology-centred conceptual modelling. In Advanced Information Systems Engineering Workshops (pp ). 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), Šplíchal, P. (2011) Model Transformation. In 20th International Scientific Conference Agrarian perspectives (pp ). 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 ). 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 ). 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

43 Volume 04 Number ACTA INFORMATICA PRAGENSIA 43

44 Acta Informatica Pragensia, 2015, 4(1): DOI: /j.aip.59 Peer-reviewed paper Context Sources and their Processing in Company Security Libor Měsíček * Abstract This article deals with the problem of critical employees oversight. In the article is proposed set of processes which can with cooperation with Data Mining and Ambient Intelligence, in some cases, predict behaviour and movement of monitored objects/people based on reasoned context from set of different sources. The difference between prediction and observed reality can be evaluated and based on rules and gathered information about context can be taken action to prevent security breach and damages to the company. At the end a case scenario is presented which demonstrate behaviour of the system and possible options how the system can prevent damages to assets. Keywords: Ambient Intelligence, Context, Security, Process, Surveillance, Security Management. 1 Introduction Threats to the security of a company are as old as companies. In the past there were mainly threats in the form of physical document theft or destruction, information smuggling or selling to competitors or just a simple break into companies building and stealing or damaging valuable equipment. The number of ways how to interact with the company to harm its position nowadays is much wider. Almost every company has to be connected to the Internet, has local network and servers with sensitive data which must be protected by encryption and in case of a security problem set of pre-set countermeasures. Ko et al. (2011) pointed out that the weakest part of this chain remains human factor. We can observe similar situation in air traffic, simple data insertion by some office clerks or system administrators using simple passwords into critical company systems, the percentage of wrong action or entries is much higher than success rate of a modern aviation systems and OCR systems. Other connected problem is ontology linked with Ambient Intelligence, generation of device specific user interfaces, automatic code generation, application adaptation and code mobility (Preuveneers et al., 2004). The main goal of this article is to demonstrate concept of combination of different sources of information to be able to identify context and also security level of an employee and according to this level take appropriate action. Presented model suggests a way how to use already widely spread technologies combined with new techniques to detect unusual behaviour of valuable employee with great importance to the company. The reason why * Department of Informatics, Faculty of Science, J. E. Purkinje University, Ceske mladeze 8, Usti nad Labem, Czech Republic l.mesicek@ujep.cz 44 ACTA INFORMATICA PRAGENSIA Volume 04 Number

45 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 ) 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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 45

46 ID Input name Description 1 Entrance system 2 Surveillance cameras 3 Public transport information system 4 Employees work schedule Systems based on NFC or RFID technology used for identification of presence of employees ID Card. Processed information from surveillance cameras around and inside companies buildings with car ID recognition. Information about delays of public transportation system and traffic jams and alternative roads. Employees work schedule with planned meetings, vacations and other important events. 5 Phone Information about position of employees phone, use of auto check-in. 6 Facial expression analysis Surveillance cameras can not only detect presence of a person but also recognise mood of a person in our case fear or pain (Xu et. al., 2014). Information source Internal system of a company Internal system of a company Public information systems API Internal system of a company Internal system of a company / API of a third party application Internal system of a company Typical delay of detection < 1second <1 second < 5 minutes N/A <1 minute <1 minute 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

47 Beginning of data collection Surveillance camera Required recognized values Entrance system Recognition process of selected parameters Identified objects Transformation of inputs to structured database 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. Volume 04 Number ACTA INFORMATICA PRAGENSIA 47

48 Beginning of the process Information about object position in environment and time Data mining processes Usual patterns of object movement Data mining process and ambient intelligence Prediction of object movement Process finished Fig. 2. Use of gathered information for reasoning patterns and prediction of future movement. Source Author. Example of the output should be information that employee arrives to work by his car on Mondays between 8:35 and 8:45 with probability of 0.7. When there is traffic jam at particular part of his route from home he will arrive with 15 minutes delay with probability of 0.6. On Tuesdays he usually uses a train because of regular heavy jams and the train is usually five minutes delayed on arrival (but we can use Public information system with information about current delay of used train), then he has to walk for five minutes, so on Tuesdays his probable arrival is from 8:45 to 8:50 with 0.8 probability, but if he has any planned work meeting in the city center he will arrive after the meeting is finished (this can be checked in his calendar and scheduled meetings). Once we have information about usual patterns of movement and interaction of selected employee we can use it for prediction of his or her behavior, and the most importantly potentially dangerous situations. The success rate of the prediction should be measured in short- and mid-term. success rate = number of successfull predictions number of all prediction 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

49 Information about object position in environment and time Beginning of the process Usual patterns of object movement Comparison of usual and actual movement of object Security threat representing the employee 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 Volume 04 Number ACTA INFORMATICA PRAGENSIA 49

50 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), 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), 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 ). 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 ). 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 Vokorokos, L., Balas, A., & Mados, B. (2012). Intrusion Detection Architecture Utilizing Graphics Processors. Acta Informatica Pragensia, 1(1), doi: /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), ACTA INFORMATICA PRAGENSIA Volume 04 Number

51 Volume 04 Number ACTA INFORMATICA PRAGENSIA 51

52 Acta Informatica Pragensia, 2015, 4(1): DOI: /j.aip.60 Peer-reviewed paper Hodnocení Web GIS aplikací a nástrojů pro jejich tvorbu pomocí AHP Evaluation of Web GIS Applications and their Development Tools Using AHP Miroslav Pásler * Abstrakt Analyticko-hierarchický proces (AHP) je široce využívaným přístupem v oblasti rozhodovacích procesů, hodnocení a skupinovém rozhodování. Je oblíben zejména pro svá specifika související s konzistentností hodnotitelových rozhodnutí a přístupu k dekompozici daného problému. AHP a jeho formy jsou také využívány v oblasti geografických informačních systémů (GIS) a to při řešení mnoha různých problémů. V tomto článku je AHP použit jako metoda výběru možných hodnotících kritérií a stanovení vah kritérií pro hodnocení Web GIS aplikací interaktivně prezentujících zájmové body a nástrojů sloužících k tvorbě tohoto druhu Web GIS aplikací. V rámci výzkumu byly stanoveny váhy kritérií dotazováním hodnotitelů rozdělených do kategorií dle jejich vztahu k tvorbě a využití Web GIS aplikací. Proces hodnocení je vztažen ke konkrétní Web GIS mapové aplikaci. Článek konfrontuje výsledky šetření s výstupy předešlých prací hledajících nejvhodnější nástroj pro tvorbu podobných Web GIS aplikací. Součástí článku je také zhodnocení konzistentnosti rozhodnutí hodnotitelů vzhledem ke stanoveným kategoriím. Klíčová slova: AHP, hodnocení, konzistentnost, rozhodování, Web GIS. Abstract The Analytic hierarchy process (AHP) is a widely used approach in the field of decision making, evaluation and group decision making processes. It is popular especially for its specifics related to consistency of an evaluator's decisions and an approach to decomposition of a certain problem. AHP and its forms are also exploited in the area of geographic information systems (GIS) while solving variety of multiple problems. In this article the role of AHP is a method of determining a set of criteria and weights of the criteria of evaluating Web GIS applications which are presenting points of interest and of evaluating the development tools. Within the research weights of criteria were defined by interviewing evaluators divided into categories according to their relationships to creation and usage of Web GIS applications. The evaluation process focuses on a particular Web GIS map * Institute of System Engineering and Informatics, Faculty of Economics and Administration, University of Pardubice, Studentská 95, Pardubice, Czech Republic miroslav.pasler@student.upce.cz 52 ACTA INFORMATICA PRAGENSIA Volume 04 Number

53 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 Volume 04 Number ACTA INFORMATICA PRAGENSIA 53

54 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ů. 3 Rešerše a výzkumné metody 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

55 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: kde Aj představuje ohodnocení j-té alternativy dle vztahu: A = MAX j {A j } (1) A j = {w 1, w 2,, w m } {v 1j, v 2j,, v mj } (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: m(m 1) k = (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). Volume 04 Number ACTA INFORMATICA PRAGENSIA 55

56 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: k = l(l 1) 2 l + m i(m i 1) 2 i=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ů. 4 Řešení a výsledky 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í. (4) 56 ACTA INFORMATICA PRAGENSIA Volume 04 Number

57 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. Volume 04 Number ACTA INFORMATICA PRAGENSIA 57

58 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

59 4.4 Výsledky hodnocení Obr. 1. Hierarchická struktura problému. Zdroj: autor. 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). Autor Koncoví uživatelé Vývojáři Možnosti aplikace 0,125 0,125 0,800 0,800 0,333 0,333 Možnosti vývojových nástrojů 0,875 0,875 0,200 0,200 0,667 0,667 Možnosti vrstev 0,292 0,037 0,048 0,038 0,085 0,028 Podkladové mapy 0,106 0,013 0,090 0,072 0,053 0,018 Rychlost 0,178 0,022 0,138 0,110 0,125 0,042 Vyhledání lokality 0,053 0,007 0,198 0,158 0,137 0,046 Vyhledání nejbližšího bodu 0,096 0,012 0,188 0,150 0,293 0,098 Vyhledání trasy 0,031 0,004 0,215 0,172 0,191 0,064 Zjištění atributů 0,244 0,031 0,123 0,098 0,116 0,039 Bohatost API 0,409 0,358 0,250 0,050 0,289 0,193 Čas potřebný pro tvorbu aplikace 0,322 0,282 0,250 0,050 0,246 0,164 Licenční podmínky 0,104 0,091 0,250 0,050 0,175 0,117 Zpracování a podpora API 0,165 0,145 0,250 0,050 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í. Volume 04 Number ACTA INFORMATICA PRAGENSIA 59

60 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. Google Maps API Mapy.cz API ArcGIS API Možnosti vrstev 0,33 0,33 0,33 Podkladové mapy 0,30 0,60 0,10 Rychlost 0,46 0,46 0,08 Vyhledání lokality 0,14 0,43 0,43 Vyhledání nejbližšího bodu 0,33 0,33 0,33 Vyhledání trasy 0,47 0,47 0,05 Zjištění atributů 0,33 0,33 0,33 60 ACTA INFORMATICA PRAGENSIA Volume 04 Number

61 Bohatost API 0,32 0,09 0,59 Čas potřebný pro tvorbu aplikace 0,23 0,65 0,12 Licenční podmínky 0,12 0,68 0,20 Zpracování a podpora API 0,63 0,14 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í. Google Maps API Mapy.cz API ArcGIS API Původní hodnocení autorem 38,2% 30,4% 31,4% Současné hodnocení autorem 32,5% 34,5% 33,0% Hodnocení dle koncových uživatelů 33,7% 41,7% 24,6% Hodnocení dle vývojářů 35,0% 36,4% 28,5% Celkové hodnocení za obě skupiny 34,1% 39,3% 26,5% Tab. 3. Finální hodnocení nástrojů. Zdroj: autor, (Pásler, 2014a ). Volume 04 Number ACTA INFORMATICA PRAGENSIA 61

62 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. 5 Diskuze Obr. 4. Příklad analýzy citlivosti pro kritérium Možnosti aplikace. Zdroj: autor. 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. 6 Závěr 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

63 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), 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 ). 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), doi: /s Karnatak, H. Ch., Sameer, S., Karamjit, B., & Roy, P. S. (2007). Multicriteria Spatial Decision Analysis in Web GIS Environment. Geoinformatica, 11(4), Pásler, M. (2014a). Multi-criteria decision-making used in selection of the best web gis devlopment tool. In System approaches 14, (pp ). Pásler, M. (2014b). Web GIS mapová prezentace kontejnerů na recyklovaný odpad. In Mezinárodní Masarykova konference 2014 (pp ). 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), 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), doi: /j.ejor Volume 04 Number ACTA INFORMATICA PRAGENSIA 63

64 Acta Informatica Pragensia, 2015, 4(1): DOI: /j.aip.61 Peer-reviewed paper Dopravní nehoda, systémový model a shluková analýza v prostředí GIS Traffic Accident, System Model and Cluster Analysis in GIS Veronika Vlčková *, Pavel Hrubeš * Abstrakt Jedním z mnoha často frekventovaných témat jak běžné publicistiky, tak odborné veřejnosti je problém dopravní nehodovosti. Tento příspěvek si vytkl za úkol nasměrovat úvahy do zatím poměrně nezkoumaných souvislostí dopravní nehodovosti, a to s pomocí nástrojů konstruktivní teorie systémů a jejích metod, vícerozměrné a shlukové analýzy i geoinformačního inženýrství. Dopravní nehoda jako systémově chápaná událost je jevem časoprostorovým, a tedy na ní lze studovat vlastnosti z pohledu technologie geografických informačních systémů. Aplikace základních systémových principů umožňuje formulaci jejího systémového modelu, uchopitelného geoinformačním inženýrstvím a zprostředkovávajícího maximální využití nástrojů vícerozměrné i shlukové analýzy. Klíčová slova: Konstruktivní teorie systémů, geoinformační inženýrství, dopravní nehodovost, vícerozměrná analýza, shluková analýza. 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. 1 Úvod 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, Praha 1, Czech Republic vlckova@fd.cvut.cz, hrubes@fd.cvut.cz 64 ACTA INFORMATICA PRAGENSIA Volume 04 Number

65 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. 2 Současná praxe a vybrané nástroje statistického hodnocení 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; Volume 04 Number ACTA INFORMATICA PRAGENSIA 65

66 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 ,- 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í Pracovní Význam položky označení označení Význam položky p1 identifikační číslo p21 dělení komunikace p36 druh pozemní komunikace p22 situování nehody na komunikaci p37 číslo komunikace p23 řízení provozu p2a datum ddmmrr p24 místní úprava přednosti v 0=sobota, 1=neděle, 6=pátek p27 specifická místa a objekty y(p2a) p2b čas hhmm p28 směrové poměry p6 druh nehody p34 počet zúčastněných vozidel p7 druh srážky jedoucích vozidel p35 místo dopravní nehody p8 druh pevné překážky p39 druh křižující komunikace p9 charakter nehody p44 druh vozidla p10 zavinění nehody p45a výrobní značka p11 alkohol u viníka p47 rok výroby vozidla p12 hlavní příčina nehody p48a charakteristika vozidla p13a usmrcených p49 smyk p13b těžce zraněných p50a vozidlo po nehodě p13c lehce zraněných p50b únik provozních nebo přepravovaných hmot p14 celková škoda ve 100 Kč p51 způsob vyproštění osob z vozidla p15 druh povrchu vozovky p52 směr jízdy nebo postavení vozidla p16 stav povrchu vozovky p53 škoda na vozidle ve 100 Kč p17 stav komunikace p55a kategorie řidiče p18 povětrnostní podmínky p57 stav řidiče p19 viditelnost p58 vnější ovlivnění řidiče p20 rozhledové poměry 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

67 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í Volume 04 Number ACTA INFORMATICA PRAGENSIA 67

68 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: x: = {x 1, x 2, x 3, x p } (1) Všechny vektory x 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í x tak, že v daném prostoru platí: x i, x j x x: d(x i, x j ) = d(x j, x i ) (2) x i x: d(x i, x i ) = 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 2 s 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number

69 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 Volume 04 Number ACTA INFORMATICA PRAGENSIA 69

70 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 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: S = ( A/F, R/P, γ, δ, E, M, I, K) (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 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ě: 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; 70 ACTA INFORMATICA PRAGENSIA Volume 04 Number

71 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: Volume 04 Number ACTA INFORMATICA PRAGENSIA 71

72 Obr. 1. Schematické zobrazení konceptu systémového modelu dopravní nehody. Zdroj: Autoři. 72 ACTA INFORMATICA PRAGENSIA Volume 04 Number

73 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.; 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.). 3.2 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: Volume 04 Number ACTA INFORMATICA PRAGENSIA 73

74 S ai = f(x) y, (v jiném tvaru např. ai A yj = fj(x1 xn), fj F) (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: v němž: y = f(x) (5) 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 Funkce Odpovídající řád efektu řidič vozidla kontroluje pohyb vozidla atd. bod vozidlo dopravní cesta bezprostřední okolí dopravní cesty zprostředkovává transport nákladu po dopravní cestě omezení pohybu vozidla po určité prostorové trajektorii s počátkem cesty a cílem cesty představuje konkrétní geofyzikální, geografické apod. vlastnosti užité dopravní cesty krajinné prostředí zprostředkovává ovlivnění řidiče vozidla vizuálními, emočními apod. parametry klima sociální podmínky 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 představují obvyklé individuální schopnosti řidičů, podvědomý způsob reakcí na konfliktní situace v dotčeném krajinném prostředí apod. úsečka linie plocha 3D ve smyslu doplnění dalších rozměrů uzlům sítě, tvořících plochu 4D ve smyslu zavedení dynamiky chování prostředí dopravní nehody sociální prostředí 74 ACTA INFORMATICA PRAGENSIA Volume 04 Number

75 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 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: geoznalost = geoinformační vztah(geodata) (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í: y = 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 do okolí dopravní nehody) = f (údaje o nehodě; údaje o komunikaci ) (8) Volume 04 Number ACTA INFORMATICA PRAGENSIA 75

76 4 Diskusní koncept využití shlukové analýzy pro klasifikaci úseků komunikací 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 ACTA INFORMATICA PRAGENSIA Volume 04 Number