Rád bych chtěl touto cestou poděkovat panu Ing. Františku Dařenovi, Ph.D. za vedení mé diplomové práce, za cenné rady, připomínky a odbornou pomoc

Rád bych chtěl touto cestou poděkovat panu Ing. Františku Dařenovi, Ph.D. za vedení mé diplomové práce, za cenné rady, připomínky a odbornou pomoc. Dále bych chtěl poděkovat Bc. Petru Hanákovi z Ústavu managementu za uvedení do problematiky simulační hry a za poskytnutí cenných rad při analýze tohoto projektu. Rovněž musím poděkovat Doc. Ing. Jiřímu Rybičkovi, Dr. za poskytnutí stylu sazby diplomových prací v systému LATEX. V neposlední řadě pak všem, kteří mě podporovali po celou dobu mého studia.

Prohlašuji, že jsem diplomovou práci na téma Analýza a návrh simulační hry Ústavu managementu PEF MZLU v Brně vypracoval samostatně s použitím literatury uvedené v přiloženém seznamu.

V Břeclavi

.........................................................

Abstract Stránský Libor, Analysis and proposal of Simulation game from Department of Management FBE MUAF in Brno. Diploma thesis. Brno, 2008. Diploma thesis deals with the project of simulation game from Department of Management. Its begins with analysis and evaluation of an actual status of simulation game, whereas is this project compared with similar projects from other universities. Thesis further consider of creation the new version of simulation game. The development subsequently comes through some phases of software development live cycle from planning up to systems design. Part of this thesis is also developement of simulation game prototype.

Abstrakt Stránský Libor, Analýza a návrh simulační hry Ústavu managementu PEF MZLU v Brně. Diplomová práce. Brno, 2008. Diplomová práce se zabývá projektem simulační hry Ústavu managementu. Začíná analýzou a hodnocením aktuálního stavu hry, přičemž projekt obecně srovnává s podobnými projekty z jiných univerzit. Práce se dále zaměřuje na tvorbu nové verze hry. Vývoj postupně prochází několika kroky životního cyklu vývoje softwaru od plánování až do fáze návrhu systému. Součástí práce je i vytvoření prototypu simulační hry.

3

Obsah 1 Úvod a cíl práce 1.1 Uvedení do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 7

2 Teoretická východiska 2.1 Manažerské simulátory . . . . . . . . . . 2.2 Proces vývoje softwaru . . . . . . . . . . 2.3 Přehled modelů životního cyklu softwaru 2.3.1 Model vodopád . . . . . . . . . . 2.3.2 V - model . . . . . . . . . . . . . 2.3.3 Spirálový model . . . . . . . . . 2.4 Hlavní fáze životního cyklu . . . . . . . 2.4.1 Plánování . . . . . . . . . . . . . 2.4.2 Analýza . . . . . . . . . . . . . . 2.4.3 Návrh . . . . . . . . . . . . . . . 2.4.4 Implementace . . . . . . . . . . . 2.4.5 Celkové hodnocení a podpora . . 2.5 Objektová analýza . . . . . . . . . . . . 2.5.1 UML . . . . . . . . . . . . . . . . 2.5.2 Historie a vývoj . . . . . . . . . 2.5.3 Třídy . . . . . . . . . . . . . . . 2.5.4 Objekty . . . . . . . . . . . . . . 2.6 Diagramy UML . . . . . . . . . . . . . . 2.6.1 Diagram případu užití . . . . . . 2.6.2 Diagram tříd . . . . . . . . . . . 2.6.3 Sekvenční diagram . . . . . . . . 2.6.4 Diagram aktivit . . . . . . . . . . 2.7 Prototypování . . . . . . . . . . . . . . . 2.7.1 Rapidní prototypování . . . . . . 2.7.2 Evoluční prototypování . . . . . 2.7.3 Inkrementální prototypování . . 2.7.4 Extrémní prototypování . . . . . 2.8 Nástroje pro tvorbu prototypu . . . . . 2.8.1 Programovací jazyk . . . . . . . 2.8.2 Framework . . . . . . . . . . . . 2.8.3 Správa dat . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 9 9 10 11 12 13 13 14 14 15 15 16 16 16 17 17 18 18 18 18 18 19 19 19 20 20 21 21 21 21

3 Metodika 3.1 Analýza současného vývoje hry 3.2 Nástroj pro modelování . . . . 3.3 Analýza a design systému . . . 3.4 Tvorba prototypu . . . . . . . . 3.5 Rozhraní . . . . . . . . . . . . . 3.6 Programovací jazyk . . . . . . . 3.7 Framework . . . . . . . . . . . 3.8 Databáze . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

22 22 22 22 22 23 23 23 24

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4

4 Vlastní práce 4.1 Poznámka o číslování verzí hry . . . . . . . . 4.2 Obecně o simulační hře Ústavu managementu 4.3 O hře 1.0 . . . . . . . . . . . . . . . . . . . . 4.3.1 Vývoj . . . . . . . . . . . . . . . . . . 4.3.2 Funkčnost . . . . . . . . . . . . . . . . 4.4 Podobné projekty . . . . . . . . . . . . . . . . 4.4.1 Promis . . . . . . . . . . . . . . . . . . 4.4.2 Manahra . . . . . . . . . . . . . . . . 4.5 Shrnutí hodnocení verze 1.0 . . . . . . . . . . 4.6 Plánování verze hry 1.2 . . . . . . . . . . . . 4.6.1 Běh hry . . . . . . . . . . . . . . . . . 4.6.2 Pravidla hry . . . . . . . . . . . . . . 4.7 Systémová analýza . . . . . . . . . . . . . . . 4.7.1 Analýza aktuální verze . . . . . . . . . 4.7.2 Diagramy aktivit . . . . . . . . . . . . 4.8 Tvorba prototypu . . . . . . . . . . . . . . . . 4.8.1 Postup implementace . . . . . . . . . 4.8.2 Nastavení Frameworku . . . . . . . . . 4.8.3 Hierarchická struktura . . . . . . . . . 4.8.4 Návrh databáze . . . . . . . . . . . . . 4.8.5 Realizovaná funkčnost . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

25 25 25 25 26 26 27 27 27 28 28 28 29 34 36 39 43 43 43 43 44 46

5 Diskuze a srovnání 5.1 Další vývoj simulační hry 5.2 Implementované funkce . 5.3 Zpracování rozhodnutí kol 5.4 Nasazení . . . . . . . . . . 5.5 Rozšíření hry . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

57 57 57 57 57 58

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 Závěr

59

7 Literatura

60

5

1 1.1

Úvod a cíl práce Uvedení do problematiky

Pojem manažerská simulace, či simulace manažerských rozhodování je v současnosti stále častěji vyhledávané téma nejen manažerskými pracovníky. Různé formy simulace v podnikových prostředích dokážou usnadnit a zpřesnit rozhodovací činnosti pracovníků. Manažerský simulátor je nástroj napodobující chod konkrétního prostředí ke vztahu k danému podniku. Lze jej aplikovat na nejrůznější firemní procesy. Jejich využití má dvě hlavní roviny. Tyto simulátory lze využívat pro snižování rizik rozhodovacích procesů nebo, právě jako je tomu v případě simulační hry Ústavu managementu, jako cvičný systém. Simulace v uměle vytvořených prostředích vytváří ze zadaných dat, které se týkají charakteristik prostředí, výsledky odpovídající reakcím tohoto prostředí. V prvním případě umožňují dobře nastavené a přesné simulátory minimalizovat náklady chybných rozhodnutí manažerů. V druhém pak budoucí manažeři, vedoucí pracovníci či uchazeči o zaměstnání v assement centrech testují nebo zdokonalují své schopnosti, a tak získávají určitou praxi. Projekt Simulační hry Ústavu managementu MZLU je pro jeho hráče velkým přínosem při ověřování informací, které na škole získali. Svou formou jde jistě o první způsob využití manažerského simulátoru na naší univerzitě. Schopnost uplatnit, otestovat, případně rozšířit své znalosti zatím využívají studenti předmětu Strategický management a je škoda, že jen v jednom předmětu se k takto praktickému a zábavnému způsobu simulace budoucí manažeři dostanou. Ústav managementu se právě proto snaží simulační hru dále rozšiřovat a zavádět do hry nejen více ovlivnitelných faktorů a tržních specifik, které přibližují simulaci reálnému prostředí, ale i zpřístupnit hru studentům jiných předmětů, kteří by si na jejích konkrétních částech otestovali znalosti v těchto předmětech získané.

6

1.2

Cíl práce

Cílem diplomové práce je provést analýzu a návrh nové verze simulační hry. Při těchto postupech se bude vycházet ze současného fungujícího systému, který je využíván pro cvičení Strategického managementu. V nové verzi se zaměřím na eliminaci problémů a nedostatků současné hry a začlením do ní požadovanou novou funkčnost. Součástí práce bude i hodnocení současné verze hry a srovnání této hry s podobnými projekty jiných škol. Analýzu a návrh nové verze budu směřovat k vytvoření prototypu. Ten bude stavět na principech původní hry a bude zahrnovat novou funkčnost. Zároveň se budu snažit udělat prototyp systému jako komplexní portál, združující všechny oddělené prvky současné verze. Jelikož aktuální hra je pro letní semestr akademického roku 2007/2008 již odehrána a nová se spustí až začátkem dalšího semestru, nebudu se zabývat nasazením a testováním nové verze simulační hry, pro tyto činnosti však systém připravím. Souhrně lze za jednotný univerzální cíl stanovit zjednodušení aplikace simulační hry a zavedení nově požadované funkčnosti.

7

2

Teoretická východiska

Stěžejní částí mé práce bude analýza projektu Simulační hry a následně tvorba jeho prototypu, proto nyní popíšu techniky a technologie, které mi pro realizaci projektu přišli jako nejvhodnější a vyberu z nich nejvíce vyhovující prostředky. Tématem diplomové práce je analýza a návrh manažerského simulátoru (simulační hry), proto nejdříve popíši manažerské simulátory obecně a až pak se pustím do popisu vývoje softwaru a jeho technik.

2.1

Manažerské simulátory

Manažeři jsou hlavně a především pracovníci se znalostmi, které představují vytváření rozhodnutí ať už individuálně nebo týmově prováděné. Tuto činnost lze vhodně (výhodně) podporovat systémy, které usnadňují, rozšiřují nebo zvyšují schopnost manažera pracovat s jedním nebo více druhy vědomostí. Tato báze znalostí je známá pod označením systém pro podporu rozhodování neboli manažerský simulátor. (Holsapple, Whinston, 2000) Manažerský simulátor je ekonomický model v počítačové podobě. Jeho těžištěm je mentální model podniku, který kvantitativně vyjadřuje jeho hlavní rysy - nejvýznamnější prvky struktury - a je schopen postihnout jejich zpětnovazební a dynamické souvislosti. Umožňuje celkový pohled na chování a fungování podniku.(Neumayerová, 2005) Simulátory se využívají především v situacích, kdy je velmi nákladné nebo rizikové vyzkoušet rozhodnutí manažerů na reálném trhu a firmě, kde by mohlo mít chybné rozhodnutí nevratné následky. Simulátor lze však s výhodou využít i v situacích, kdy zaměstnancům slouží jako tréninkový program. Zde se tedy jedná proces, kde není prioritou eliminace ztrát jako v prvním případě, ale výcvik osob pro konkrétní situace. Tímto způsobem pak zaměstnanci získávají dodatečné zkušenosti a zvyšují si tak kvalifikaci. Pro podnik pak toto školení personálu není tak rizikové, jako kdyby jej zapojili do reálného chodu firmy. Třetí možností je pak využití manažerských simulátorů při náboru zaměstnanců v tzv. assessment centrech, kde je jeho výsledek brán jako jeden z faktorů hodnocení uchazečů o zaměstnání. Zaměstnavatelé nebo firma assessment centrum pořádající tak může sledovat reakce a jednání potenciálních zaměstnanců firmy, které je dle mého názoru klíčovým parametrem pro přijetí. Určitě je tento parametr pro přijetí důležitější než vzdělání či dosavadní praxe. Nasazení manažerského simulátoru do podniku bývá z pravidla v situaci před důležitým rozhodnutím (např. podnik se rozhoduje mezi velkým rozšířením firmy spojeným s rizikem a setrváním v současném stavu). Z počátku pak simulátor slouží především k jednomu účelu a jeho výstupy směřují k jedinému cíli. Je však nutné si uvědomit, že otázek vždy vznikne dříve nebo později mnohem více. Co všechny změny mohou pro organizaci znamenat? Je její management schopen správně a rychle vyhodnotit hrozby i příležitosti, které ze situace plynou? Mají manažeři k dispozici nějaký model, na kterém by si mohli svá rozhodnutí dopředu a bez rizika škod otestovat? Zodpovězení těchto a mnoha dalších otázek mohou usnadnit právě manažerské simulátory. Na základě modelu popisujícího procesy v organizaci (a někdy i mimo ni) umožňují rychle a bez rizika odhadovat důsledky různých vnějších událostí nebo interních rozhodnutí a strategií. (Vojtko, 2005)

8

Využívání simulátorů jen pro jedno, byť zásadní rozhodnutí, je však pro firmu nevýhodné. Simulátor jistě pomůže při řešení náročného problému, ale jeho význam by měl být dlouhodobějšího rázu pro permanentnější používání. Teprve tak se projeví naplno jeho vlastnosti. Tyto simulátory lze využít i průběžně např. pro posuzování krátkodobých i dlouhodobých dopadů dalších rozhodnutí a strategií, trénování a rozvíjení manažerských schopností a znalostí (např. u nových pracovníků nebo studentů), při změnách okolních podmínek (jste schopni velmi rychle správně vyhodnotit dopady - získáváte reakční čas navíc), pro stanovení hraničních hodnot různých parametrů nebo pro rychlou tvorbu plánů, která je odvozena ne z minulosti, ale z aktuálního fungování firmy a znalostí o chování trhu. (Vojtko, 2005)

2.2

Proces vývoje softwaru

Projekt musí, ať už při svém vývoji od nuly, nebo přes re-design starého systému, projít několika vývojovými fázemi. Obecně se jedná o fáze plánování (specifikace požadavků, předběžného výzkumu), analýzy, návrhu, implementace a testování. Jak je dle literatury (Holsapple, Whinston, 2000) podotýkáno, stupeň úspěchu manažerského simulátoru či obecně jakéhokoliv softwaru závisí na jeho schopnosti začlenit se do nového systému, na schopnostech ho rozšířit, na dojmech uživatelů o jednoduchosti jeho používání, schopnosti systému správně a včasně poskytovat odpovědi a nesmíme zapomenout i na ekonomickou stránku projektu. Tito autoři dále definují faktory napomáhající k úspěchu vývoje projektu: 1. 2. 3. 4. 5.

2.3

Ohodnocení koncových uživatelských potřeb Výběr správných vývojových nástrojů Dostatečné schopnosti a znalosti ve spojení s vyhovující výpočetní technikou Dostatečné porozumnění příslušné problémové doméně Přístup k adekvátní bázi znalostí

Přehled modelů životního cyklu softwaru

Neustálý vzrůst počtu počítačů a dalších programovatelných mikroprocesorových systémů přináší s sebou zvýšené požadavky na tvorbu programového vybavení všeho druhu. Zdá se, že se prostřednictvím moderních programovacích jazyků podařilo částečně překonat softwarovou krizi, o které se tolik hovořilo začátkem osmdesátých let minulého století. (Lacko, 2003) Vývoj softwaru lze rozložit do několika období (cyklů). Formalizovaný popis činností těchto cyklů se pak označuje jako model životního cyklu softwaru. Životní cykly, které popisují základní představu o tvorbě softwaru, nazýváme často konceptuálními modely tvorby softwaru. Zabývá se jimi softwarové inženýrství. Dobře jsou pak popsány v literatuře (Král, Demner, 2003) nebo (Zyka, 2000). Uvedu zde jen ty nejdůležitější. Za ně považuji vodopádový model, V-model a iterační model. Poslední jmenovaný je dle mého názoru nejdůležitější.

9

2.3.1

Model vodopád

Nejstarším modelem vývoje softwaru je model ”vodopád”. Každý výstup jedné jeho etapy je vstupem etapy následující. Tyto etapy jsou přesně definované, dokonale na sebe navazují a prolínají se. Způsob předávání výstupů etap (ve formě dokumentů) je prováděn vždy shora dolů, od toho taky nese tento model svůj název.

Obr. 1: Model vodopád

Velkou nevýhodou tohoto modelu je nemožnost vracet se mezi etapami zpět. Tato skutečnost pak klade velké nároky jak na uživatele (při počáteční specifikaci požadavků na systém), tak na tvůrce systému (posloupnost vývojových etap se může pro různé projekty měnit). Výstup systému pak uživatel vidí až v závěrečných fázích celého procesu. Využití tohoto modelu je však již historickou záležitostí.

10

2.3.2

V - model

Životní cyklus, jehož diagram připomíná písmeno ”V” je založen na potřebě neustálého testování a psaní testů pro jednotlivé vývojové fáze. Psaní testů výrazně snižuje chybovost výsledného systému. Využívá se především u Extrémního programování, kde jsou testy důležitou složkou vývoje systému. Psaní testů je však časově velmi náročné. Teoreticky zabere psaní testů časově dobu stejně dlouhou jako psaní kódu programu, protože se píší kódy vlastně dvakrát (jednou pro testy a podruhé znovu pro vlastní program, který pak testujeme). Tento způsob s výhodou využijeme např. při tvorbě rozsáhlého systému, na kterém participuje velké množství programátorů.

Obr. 2: Model V - životního cyklu

11

2.3.3

Spirálový model

V poslední době se v důsledku použití prototypovacích nástrojů zdůrazňuje iterační postup při tvorbě programového vybavení, jehož schematické znázornění je na následujícím obrázku. Chce se zdůraznit, že vývoj probíhá postupně, stále na kvantitativně širší a kvalitativně vyšší úrovni, a že je omezen okamžikem, kdy se produkt z různých důvodů (zásadní změna technického vybavení, změna uživatelského přístupu apod.) vyřadí z používání. V anglosaské literatuře bývá označován pojmem ITERATION LIFE CYCLE nebo PROTOTYPING LIFE CYCLE. Ten lépe vystihuje okamžik zahájení tvorby softwaru, tvorbu jednotlivých verzí programového produktu a zachycuje i okamžik ukončení používání programového produktu. Navíc vyjadřuje skutečnost zvyšování kvalitativní úrovně v průběhu jednotlivých cyklů. (Lacko, 2003)

Obr. 3: Model spirálového životního cyklu

Model je založen na kombinaci prototypování a analýzy rizik. Jednotlivé kroky při vývoji systému se ve spirále opakují, ale pokud možno na vyšším stupni zvládnuté problematiky. Tyto kroky se opakují do doby, než je systém vyřazen z provozu. Výhodou je, že již v počátečních fázích vývoje se využívá SW nástrojů. Dochází tak k efektivnějšímu hledání chyb v navrhovaných analýzách a prototypech. Tuto metodiku využívají spíše odborníci s určitou mírou zkušeností. Méně zkušení vývojáři by pak mohli procházet příliš mnoho iterací bez větších pokroků.

12

2.4

Hlavní fáze životního cyklu

Fáze životního cyklu softwaru se dle předchozího textu liší v závislosti na zvoleném typu. Odlišné podmínky vývoje konkrétního softwaru pak mohou jednotlivé fáze rozšiřovat, zkracovat či úplně vypouštět. Omezování nastává z důvodu nedostatku času, prostředků pro vývoj, nebo také z důvodu nepotřebnosti dané etapy. 2.4.1

Plánování

Prvotní seznámení s projektem, stanovení cílů, sběr a analýza požadavků budoucích i současných uživatelů systému patří do první fáze realizace systému, do plánování. Tato bývá velmi často vývojáři podceňována, ale její význam je minimálně stejně důležitý jako u fází následujících. Důležitost přesného zadání požadavků a jejich analýza se projevuje v dodatečných úpravách celého systému a časovém zpoždění, které právě neúplností či nepřesností požadavků může nastat. Obecně platí, že čím přesnější specifikace, tím má systém menší pravděpodobnost vrácení k přepracování od zadavatelů. Tento prvotní výzkum požadavků lze rozdělit do několika kroků. Přesná procedura nicméně závisí na přirozenosti úkolu, velikosti projektu a naléhavosti řešení. Jak je popsané v literatuře (Shelly, Cashman, Rosenblatt, 2001): Porozumění problematice a příležitostem - Požadavky na systém se často mění a vývojáři by měli rychle pochopit i třeba malou změnu v kontextu celého systému. Definování hloubky projektu a omezení - Hloubkou systému se myslí jeho hranice či rozšíření. Definice omezení pak určuje podmínky, které musí systém uspokojovat, nebo výsledek, který musí systém uchovat. Příprava a hledání faktů - Skládá se z analýzy statistik, uskutečňování rozhovorů, prohlížení současných podnikových dokumentů, procházení operací podniku nebo tvorby jiných druhů výzkumů pomáhajících sbírat fakta o podniku. Odhad výhod projektu Součástí této fáze je zhodnocení proveditelnosti celého projektu. Odhad pracnosti a nákladů - Část, která je rozhodující pro realizaci celého projektu ze strany zadavatelů. Určuje technickou, operační a ekonomickou proveditelnost projektu. Prezentace výsledků zadavatelům - Finální úloha, která určí další vývoj projektu. Výstupem je report pro management zadavatele. Pro úvodní analýzu specifikace požadavků se využívají rovněž UML diagramy a to především USE CASE, který popisuje základní komunikaci uživatelů s navrhovaným systémem, a lze na něm tak objasnit požadavky na systém, které zadavatelé nedokázali definovat sami.

13

2.4.2

Analýza

Počátečním krokem této fáze je projektová analýza. Analyzovat lze ze dvou úhlů. Tím prvním je datové a procesní modelování (strukturovaná analýza) a druhým analýza objektová. Jak píší autoři (Shelly, Cashman, Rosenblatt, 2001): Strukturovaná analýza - Popisuje systém z pohledu jeho vstupů, výstupů, dat a procesů. Během strukturované analýzy se využívají data a procesní modelování k zobrazení toho, jak systémový proces transformuje data do použitelných informací. Objektová analýza - Nahlíží na systém z rozdílného úhlu. Popisuje systém určováním objektů. Objekt reprezentuje skutečnou osobu, místo, událost nebo transakci (Tento způsob analýzy popíšu podrobněji v části Objektová analýza). Hlavním cílem fáze analýzy je vytvoření logického modelu systému, který slouží jako výchozí bod pro následující fázi. Objektová či strukturální analýza však není jedinou částí celé fáze. Může obsahovat i další dodatečné prvky. Ty jsou závislé od typu projektu, a proto je neuvádím mezi nejdůležitějšími. Jde o fáze, které na analýzu navazují. Patří sem evaluace alternativních řešení, příprava dokumentace požadavků a prezentace systémových požadavků managementu. Můžeme sem zahrnout i fázi tvorby prototypu či návrhu struktury kódu. 2.4.3

Návrh

Převodem logického modelu jako výstupu fáze analýzy do modelu fyzického se zabývá fáze návrhu neboli designu. Během této fáze se identifikují vstupy a výstupy systému, jeho rozhraní, provádí se návrh datových úložišť nebo plánování aplikační architektury. Cílem fáze návrhu je vytvořit efektivní, spolehlivý a udržitelný systém. Musí být ale také schválen jeho uživateli. Systém je udržitelný, jestliže je dobře navržen a zároveň je flexibilní. Musí také počítat s budoucím rozšířením, které vyplyne z pozdějších uživatelských požadavků. Očekávání či požadavky od návrhu systému rozdělujeme do 3 kategorií a to podle toho, z jakého místa v systému přicházejí: Uživatelské požadavky - Jsou založeny na snadnosti ovládání systému (”user-friendly”), což spočívá ve vytvoření přívětivého grafického uživatelského rozhraní s dobře definovanou, logickou, přívětivou, ale však nutnou vazbou mezi uživateli a systémem. Jinými slovy jde o tvorbu vstupů a výstupů systému. Požadavky pro data a datová úložiště - Týkají se především způsobu práce s daty, jejich ukládání, ověřování nebo zpřístupnění. Procesní požadavky - Týkají se funkčnosti navrhovaného systému. Zabývají se architekturou systému a propojením jednotlivých jejích částí.

14

2.4.4

Implementace

Cílem této fáze je vytvoření fungující aplikace systému. K tomu využívá výstupů z předchozích fází, především z fáze návrhu. Ten je používán jako návod či plán výstavby. Během implementace jsou neustále vytvářeny, dokumentovány, integrovány a testovány jednotlivé aplikační části(moduly). Konkrétní postup zavisí na konkrétní situaci, projektu a vývojovém týmu. Po vytvoření aplikace začíná druhá část implementační fáze a to instalace, hodnocení a testování. Tato část zahrnuje tyto body: 1. 2. 3. 4. 5.

Příprava operačního prostředí a instalace nového systému Zaškolení uživatelů systému Vykonání převodu dat do systému Provedení poinstalačního hodnocení systému Prezentace finálního řešení managementu

2.4.5

Celkové hodnocení a podpora

Názvy této fáze bývají různé, ale cíl mají vesměs podobný. Tím je analyzovat vytvořený projekt jako zaběhlý systém a srovnat zamýšlenou a vytvořenou funkčnost. Zároveň k vytovřenému produktu jeho autoři poskytují podporu a případně systém dále upravují. Tím se ale vrátí k počáteční fázi životního cyklu vývoje softwaru.

15

2.5

Objektová analýza

Objektová analýza v dnešní době při vývoji aplikací převažuje nad strukturní, proto jsem se jí rozhodl věnovat v samostatné sekci. Informační systém je popsán objektově orientovanou analýzou pomocí identifikace objektů. Objektem rozumíme osoby, místa, události nebo transakce. Pro vytvoření a zaznamenání objektové analýzy využíváme především jazyka UML 2.5.1

UML

UML (Unified Modeling Language) je univerzální jazyk pro vizuální modelování systémů. Byl navržen, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Neposkytuje žádný druh metodiky modelování, jde jenom o vizuální syntaxi, kterou můžeme využít při sestavování svých modelů. (Arlow, Neustadt, 2007) 2.5.2

Historie a vývoj

Jazyk UML vznikl z potřeby. Ještě počátkem devadesátých let se svět vizuálního modelování zmítal v chaosu. Existovalo několik rozdílných technik, kde každá znamenala rozdílnou notaci a jen výjimečně novou kvalitu. Hlavním proudem zde byly metody Booch a OMT, které měly více jak polovinu současného trhu. Prvním pokusem o sjednocení byla metodika Fusion. Ta ale rychle zapadla především proto, že tvůrci, kteří tvořili pro převážnou většinu trhu (Booch, Jacobson a Rumbaugh), v ní nebyli zapojeni. Když se tyto tři osobnosti spojily ve firmě Rational Corporation, která v té době pracovala na tvorbě jazyka UML, začal se projekt UML blížit k finální verzi. První uveřejněnou specifikaci UML jako standard přijalo sdružení OMG (Object Management Group, sdružení vzniklé za účelem definování a prosazování specifikace objektů) v roce 1997. Od této doby pak ostatní metodiky vizualizace postupně odpadaly a UML se stalo standardem i pro vývojáře. UML verze 2.0 byla specifikována v roce 2005. Bylo v ní zavedeno mnoho nových prvků vizuální syntaxe, ale základní pravidla zůstala víceméně stejná, takže i méně zkušeným uživatelům UML přechod nedělal problémy. Standard ve verzi 2.0 se skládá z těchto hlavních specifikací: UML 2.0 SuperStructure - Popis UML z hlediska uživatele (analytik/programátor). Tato část popisuje jednotlivé diagramy. UML 2.0 Infrastructure - Metamodel stojící v pozadí za UML, specifikovaný pomocí MetaObject Facility (MOF). UML 2.0 Object Constraint Language (OCL) - Jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech. UML 2.0 Diagram Interchange - Popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji. Kromě hlavních částí existuje také celá spousta dílčích profilů UML určených pro různé specifické oblasti.

16

2.5.3

Třídy

Třídy popisují chování objektů. Jsou jim nadřazeny a lze je chápat jako abstraktní prvky. Každá třída má své instance v podobě objektů. Vytvořené instance pak musí dodržovat pravidla objektů, ze kterých byly odvozeny. Objekt je tedy instancí přesně jedné třídy. Můžeme ji brát taky jako šablonu či razítko. Vazby mezi třídami se musí promítnout do vazeb mezi konkrétními objekty z těchto tříd odvozených. 2.5.4

Objekty

Jazyk UML modeluje software jako kolekce spolupracujících objektů. Objekty nahrazují rozvržení strukturálního přístupu na data a funkce. Tyto vlastnosti mají objekty přímo v sobě. Data jsou zastoupena atributy a funkce operacemi. Atributem rozumíme atomickou vlastnost objektu a operací schopnost objektu reagovat na podněty, kterými jsou zasílané zprávy. Každý objekt má pak určité vlastnosti, které jej jednoznačně odlišují od jiných. Patří sem: Identita - Jedinečná existence objektu v čase a prostoru, která jej odlišuje od ostatních (např. sériové číslo). Stav - Je určen hodnotami atributů objektu v určitém okamžiku. Chování - Představuje volání metod daného objektu, které změní atributy, a tedy mění i jeho stav. Jediným způsobem jak komunikovat s objekty je pomocí zasílání zpráv. Schopnosti ukrývání dat se říká zapouzdření a společně s dědičností a polymorfismem patří k hlavním výhodám objektově orientovaného přístupu. Zapouzdření - představuje schopnost objektu uchovávat hodnoty skryté před ostatními a přistupovat k nim umožňuje jenom pomocí zasílání zpráv. Dědičnost - představuje efektivní využívání vlastností již jednou napsaných objektů, které vlastní objekt zdědí. Vytváří takto hierarchii mezi objekty. Tyto vlastnosti pak může i měnit (viz polymorfismus) Polymorfismus - neboli mnohotvárnost umožňuje předávat objektům různých tříd stejnou zprávu a příslušné objekty se přitom chovají tak, jak se od nich očekává.

17

2.6

Diagramy UML

Je nutné připomenout, že diagram není model. Diagramy představují určitý pohled na model. Pro tvorbu diagramů se využívají CASE nástroje (Computer-Aided Software Engeneering). Ty v sobě většinou zahrnují nástroje pro tvorbu všech diagramů, které UML specifikuje. Jedná se celkem o 13 různých typů diagramů, které se dají rozdělit do dvou kategorií na: Diagramy struktury (diagram tříd, diagram komponent, diagram nasazení, objektový diagram, diagram balíčku, diagram složené struktury) Diagramy chování (diagram aktivit, diagram posloupnosti, diagram komunikace, stručný diagram interakce, diagram časování, diagram případu užití, diagram stavového automatu) Ve verzi UML 2.0 byly do specifikace přidány diagramy složené struktury, časování a stručný diagram interakce. 2.6.1

Diagram případu užití

Modelování případů užití je jednou z forem inženýrství požadavků. Tento diagram se z pravidla využívá ze všech diagramů jako první (není to však nutnou podmínkou). Jeho cílem je nalezení hranic systému, vyhledání aktérů a nalezení případů užití (dále pak jejich specifikace a určení scénářů). Komponenty diagramu: Hranice systému - Určují hranice modelovaného systému. Aktéři - Jsou role přidělené osobám nebo předmětům užívajícím daný systém. Nacházejí se vždy mimo něj. Případy užití - Činnosti, které aktéři mohou se systémem vykonávat. Relace - Představují vztahy mezi aktéry a případy užití. Přestože se diagramy případů užití využívají velmi hojně, nehodí se na všechny modelované situace. Nehodí se např. na modelování systému, kde převládají nefunkční požadavky, kde je málo uživatelů nebo málo rozhraní. 2.6.2

Diagram tříd

Model tříd je pro kvalitu systému velmi důležitým prvkem, neboť popisuje chování budoucích objektů. Diagram tříd se využívá ve fázi analýzy a představuje odlišný pohled na celý model narozdíl od diagramu případu užití. Jedná se o logický model systému. Z vývoje tohoto modelu do fyzické podoby se nakonec stane fungující informační systém. Notace třídy obsahuje její název, atributy a metody. 2.6.3

Sekvenční diagram

Jedná se o dynamický model případů užití ukazující interakci mezi třídami během specifického časového okamžiku. Sekvenční diagram graficky dokumentuje případ užití zobrazením tříd, zpráv mezi třídami a časováním odesílání zpráv. 2.6.4

Diagram aktivit

Představuje objektově orientovaný vývojový diagram. Díky nim lze proces modelovat jako aktivitu, která se skládá z kolekce uzlů spojených hranami.

18

2.7

Prototypování

Prototyp je rychle vytvořená fungující verze navrhovaného informačního systému. Prototypování je běžné ve výrobě, kde inženýři používají modely pro řešení problémů ještě předtím, než začnou vytvářet finální produkt. Uživatelský vstup a schválení jsou nezbytné v každé etapě vývojového procesu produktu. Prototypování umožňuje uživatelům zkoumat a testovat model, který poměrně věrně reprezentuje vstupy, výstupy, rozhraní a procesy plánovaného systému. Uživatelé mohou model testovat. Mohou jej buď schválit, nebo požadovat změny. V některých případech se prototyp vyvine do finální verze informačního systému. V ostatních případech slouží model jen k ověření uživatelských požadavků a je po ukončení smazán. (Shelly, Cashman, Rosenblatt, 2001) 2.7.1

Rapidní prototypování

Obr. 4: Throwaway prototypování

Bývá též označováno jako ”Throwaway prototyping” nebo ”Close ended prototyping”. Z anglického názvu jasně vyplývá, co se stane s prototypem, až nebude potřeba. Tato metoda si klade za úkol co nejrychleji ukázat klientovi, jak jeho budoucí systém bude fungovat. Klient pak může lépe specifikovat a upřesňovat své požadavky. Po splnění těchto cílů je prototyp odložen a začíná se s vývojem nového systému od začátku. Jak je možné vidět z obrázku, lze tento prototyp brát jako slepou vývojovou větev. 2.7.2

Evoluční prototypování

Obr. 5: Evoluční prototypování

Cílem této metody je vytvořit robustní prototyp, který se vyvine do finálního systému. Výhodou tohoto modelu je, že vlastní prototyp již obsahuje srdce celého systému a po schválení požadavků klienty se ve vývoji pokračuje už jenom přidáním dodatečných vylepšení. Vývoj tohoto prototypu je pak dlouhodobější záležitostí.

19

2.7.3

Inkrementální prototypování

Inkrementální (dílčí) prototypování využívá několik prototypů současně, kde každý obsahuje funkčnost produktu. Při vývoji se začíná z pravidla návrhem uživatelského rozhraní. Výhodou je možnost porovnávat vývojová stádia rozdílných verzí prototypů. Tento vývoj je však technicky i časově velmi nákladný. 2.7.4

Extrémní prototypování

Je využíváno především pro vývoj webových aplikací. Lze jej rozdělit do 3 fází, kdy každá je závislá na té předchozí. První fází je vývoj statického prototypu tvořeného HTML kostrou a bez jakékoliv funkčnosti. Druhou fází je tvorba funkčnosti webu na simulovaných službách. Po druhé fázi je celá metoda pojmenována. Ta potom klade důraz na rychlé programování funkcionality služeb jen s malým ohledem na funkčnosti smluvených služeb. Třetí fází je pak přidání požadované funkčnosti služeb.

20

2.8

Nástroje pro tvorbu prototypu

Prototypování je činnost, která je obecně časově rychlou záležitostí, proto bude důležité eliminovat různá hrozící omezení či mimořádné nároky na prototyp. S výhodou se využívají různé nástroje usnadňující vývoj. Volba nástrojů je závislá na času, který vývojáři pro vytvoření prototypu mají, dále na počtu pracovníků podílejících se na vývoji, a především na systémových požadavcích, které dávají rámcovou strukturu celému systému. Pro tvorbu prototypu lze využít odlišných nástrojů a technik než pro tvorbu skutečného systému. Prioritou prototypu je ukázat plánovanou funkčnost ještě dříve než těsně před spuštěním oficiální verze celého systému. Tohoto se samozřejmě využívá jen u rychlého prototypování, tedy u toho typu, kde je prototyp po otestování a schválení odložen a pokračuje se ve tvorbě nového systému od začátku. 2.8.1

Programovací jazyk

Volba programovacího jazyka je spjata s účelem využití aplikace. Je zřejmé, že každý z velkého výčtu programovacích jazyků byl vytvořen pro konkrétnější úkoly. Možnosti daného jazyka určující jeho využití dávají poměrně jasnou informaci o způsobu jeho spolupráce s ostatními prvky systému a o přístupu uživatelů k tomuto systému. Pro online projekt simulační hry se nejvíce hodí jazyky jako PHP, Perl nebo ASP. Každý má své výhody. Ne všechny ale naleznete na většině dostupných hostingů nebo na většině akademických pracovišť na vysokých školách. 2.8.2

Framework

Využití Frameworku, tedy již vytvořených funkcí připravených k použití, umožňuje vývojářům nezabývat se činnostmi, které zabírají spoustu času a projektu přinesou jen malou část funkčnosti. Takový soubor funkcí, pravidel a struktury aplikace, za což lze Framework považovat, lze buď vytvořit, nebo jej získat jako hotový projekt. Pokud se vydáme druhou cestou je pro nás limitující kritérium zvolený programovací jazyk. Trendem v oblasti programování a Frameworků je využití modelu MVC, tedy model, viewer a controller. Principem je odělení uživatelského rozhraní od logické struktury. Model - Zapouzdřuje data z jádra aplikace a funkcionalitu doménové logiky. Viewer - Získává data z modelu a prezentuje je uživateli. Controller - Získává a překládá vstupy pro model nebo pro viewer. 2.8.3

Správa dat

Využití dat a jejich správa v projektu závisí na způsobu přístupu uživatelů, způsobu zpracování systémem a nutnosti rychlosti přístupu k datům. Nutnost data vůbec ukládat je zřejmá, využít lze tedy relační či objektové databáze, XML nebo např., jako je tomu aktuálně, MS Excel. O výběru datového úložiště bude také rozhodovat snadná přenositelnost systému. Velkou roli bude hrát i zabezpečení báze dat.

21

3 3.1

Metodika Analýza současného vývoje hry

Celá práce bude založena na teoretických znalostech z oblasti plánování, analýzy, návrhu systému a na tvorbě prototypu programu. Nejprve budu analyzovat současný stav projektu ÚMA simulační hry a pokusím se jej zhodnotit. Dále budu porovnávat simulační hru s podobnými projekty z jiných vysokých škol. Jelikož nemám přístup k programovému kódu ani k vlastní simulaci těchto projektů, budu srovnávat jejich zaměření a principy popsané v jejich pravidlech.

3.2

Nástroj pro modelování

Jako modelovací nástroj pro analýzu a návrh jsem si z dostupných programů zvolil nástroj Visual Paradigm for UML Standard Edition v nejnovější dostupné verzi 6.2, ke kterému má naše škola licence. Získání kvalitního nástroje bylo tak poměrně jednoduché. Navíc svou kvalitou dle mého názoru zastiňuje nástroje jako Rational Rose nebo Enterprise Architect. Jedinou nevýhodou při modelování byla nutnost připojení k internetu při spuštění tohoto programu, neboť si sám ověřuje, oproti vlastním serverům, platnost zadané licence. Po ověření lze počítač od sítě internet zase odpojit, ale tento fakt celý proces vývoje poněkud brzdil.

3.3

Analýza a design systému

Při vývoji nové aplikace, resp. jejího prototypu, budu postupovat dle jednotlivých životních fází vývoje softwaru. V první fázi (plánování) nového modelu se pokusím analyzovat získané požadavky ÚMA na nový systém. Ze specifikace pak bude jasný směr postupu vývoje nových verzí hry. Jako pomocnou metodu využiji mimo slovního popisu i diagram případu užití, který ukazuje na spoustu dalších systémových požadavků, které zadavatelé neuvedly. V druhé fázi se budu zabývat analýzou požadavků a vytvořím diagramy tříd. Na ně budou navazovat diagramy aktivit. Nejprve provedu obecnější analýzu plánovaného systému, kde se zaměřím na možnost další rozšiřitelnosti systému. Následně odvodím z tohoto modelu konkrétnější analýzu pro následující verzi simulační hry, kde zahrnu i plánované změny funkčnosti. Fáze návrhu pak bude propojena s tvorbou prototypu, kde při definici vstupů, výstupů a rozhraní budu do něj poznatky souběžně zahrnovat, proto ji zvlášť zmiňovat nebudu.

3.4

Tvorba prototypu

Vývoj prototypu simulační hry je součástí mé diplomové práce. Při této činnosti na jeho tvorbě nikdo jiný participovat nebude. Prototyp vyvíjený jediným člověkem, proto nemusí dokonale odpovídat požadavkům týmu Ústavu managementu, který se na dlouhodobém vývoji hry podílí. Neznamená to ovšem, že prototyp vychází jen z mé hlavy. Před fází realizace jsem prošel všemi vývojovými fázemi systému (fází specifikace požadavků i analýzy). Naopak bych chtěl prototypem ukázat novou cestu při vývoji simulační hry. Prototyp by pak měl jít snadno dokončit tak, aby jej šlo brát jako hotový systém, který lze testovat a uvést v ostrý provoz. Prvním krokem bude volba technologií pro návrh prototypu a následovat bude jeho realizace. Tvorba prototypu by měla být rychlou záležitostí, která klade důraz spíše na vyjádření principu funkčnosti než na design, proto jsem se rozhodl využít technologií, které jsou mi dobře známé, mám s nimi delší zkušenosti a samy poskytují dostatečnou (dodatečnou) výhodu v podobě usnadnění vývoje různými funkcemi. Jak je již zřejmé, rozhodl jsem pro novou verzi simulační hry využít jednotného systému pro administraci, správu i hraní hry. Rozhraní by mělo být online dostupné. Stejně tak jsem se rozhodl přehodnotit způsob řešení výpočtové části hry, se kterou souvisí i způsob správy báze dat a začlenit tuto výpočtovou logiku do nově vzniklého rozhraní tak, aby byla celá funkčnost na jednom místě.

22

Volba webového online rozhraní zjednodušuje přístup všem zainteresovaným osobám ke hře. Web bude realizován formou portálu, kde login rozdělí osoby mezi hráče, instruktory hry a administrátory. Vývoj aplikace prototypu simulační hry budu provádět na instalovaném serveru Apache 2.0 na svém počítači. Proto budu hledat technologie, které lze bez větších obtíží zprovoznit na osobním počítači a které umožní jednoduché převedení hry do online podoby na pravděpodobně některém ze školních serverů. Využití lokálního serveru oproti jiným (dostupným přes internet - tedy i školním) poskytuje výhodu především v rychlosti odezvy, zpracování a neexistence výpadků, které by projekt brzdily. Pro prototyp jsem se jednoznačně rozhodl pro využití některých z dostupných Frameworků, které tvůrcům systému usnadňují práci v mnoha ohledech a standardizují do jisté míry postupy tvorby kódu. Důležitou součástí prototypu bude i výběr databázového systému, kterého chci využít pro ukládání veškerých dat ze hry.

3.5

Rozhraní

V úvahu připadají dvě řešení. Každé řešení pak vyžaduje odlišný přístup k tvorbě a využití rozdílných technik a technologií. Prvním je využití webového rozhraní a druhým využití rozhraní aplikační (v podobě programu). Webové rozhraní, v dnešní době rychlého a dostupného internetu, dává větší volnost při přístupu k systému simulační hry. Tento způsob by kladl pro uživatele minimální nároky na stroj či prohlížeč, ze kterého k systému přistupují. Řešení pomocí aplikace instalované na konkrétním stroji by sice skýtalo větší možnosti při tvorbě, ale kladlo by i úměrně vyšší nároky na pracovní stanice. Tam by byl program provozován a zavedením nových pravidel by se musel přeinstalovat (pokud by neexistovala možnost upgrade). Navíc není jisté, byla-li by aplikace dostupná ke stáhnutí a hráči by mohli hrát z různých stanic nebo by se hra ovládala jen z jedné učebny na škole. Vytvoření finálního modelu systému již nebude součástí mé diplomové práce, ale poskytnu zde dostatečné podklady pro jeho dokončení právě v podobě prototypu, ze kterého lze dále dotvářet finální systém nebo jej lze brát právě jako model popisující fungující mechanizmy nového systému.

3.6

Programovací jazyk

Osobně jsem zastáncem PHP, se kterým mám nejvíce zkušeností a bylo tedy pro mě jasnou volbou. Navíc současný systém Simulační hry je na něm vystavěn, takže lze teoreticky jednodušeji do nového systému integrovat starší kód, bude-li to nutné či výhodné. S ostatními jazyky jako je PERL nebo JAVA, které by se pro systém simulační hry rovněž hodily, zkušenosti nemám a vývoj prototypu by nebyl efektivní. Jsem si vědom jeho nedostatků a nevýhod, ale velké možnosti právě ve využití Frameworků, a i možnost srovnání se současnou verzí, mě ve volbě jazyka utvrdily. PHP svou dostupností umožní lepší přenositelnost aplikace na případně další servery.

3.7

Framework

Rozhodl jsem se využít některého Open Source Frameworku, který svou integrovanou funkčností vývoj usnadní. Požadavky na Framework byly především jednoduchost ovládání, rychlost, dostatečné množství knihoven, helperů a především dokumentace a podpora. Samozřejmostí bylo i využití modelu MVC (Model, Viewer a Controller). Naopak jsem se neohlížel na integraci šablonovacích systémů (pro šablony, z důvodu rychlosti, využívám PHP). Z existujících PHP Frameworků jsem jsi po předběžné studii zvolil pro podrobnější srovnání Zend Framework, CakePHP a CodeIgniter. Všechny 3 na modelu MVC staví. Každý je pak svou velikostí a funkčností v jiné kategorii.

23

Zend Framework - Patří mezi nejrozšířenější PHP Frameworky. Jeho robustnost poskytuje dostatečnou funkčnost pro téměř každý projekt. Velké množství integrovaných funkcí a velikost kódu pak tento projekt staví mezi ty pomalejší. Dokumentace je dostačující díky velké uživatelské a vývojářské komunitě. CakePHP - Svou velikostí patří spíše mezi střední třídu. Práce s ním připomíná Ruby on Rails. Je bohatě vybavený a dost se řídí konvencemi. Dokumentací a podporou patří však mezi slabší projekty. Proto je využití velké části funkcí pak otázkou testování a náhody. Navíc CakePHP dosud nemá komunitní fórum, takže jsou jeho uživatelé odkázáni na pár blogů nadšenců. CodeIgniter - Framework CodeIgnitor (CI) patří mezi menší projekty. Za jeho vývojem sice stojí komerční firma, ale na jeho funkčnosti to vliv příliš nemá (dostatečná podpora, stálý vývoj nových verzí). Díky malé velikosti je Framework velmi rychlý. Nemá sice funkčnost výše zmíněných, ale dodatečně se spousta funkcí dá řešit pluginy. Dokumentace k projektu je velmi dobrá. Existuje i několik fór, zabývajících se fukčností CI. Pro prototyp jsem zvolil právě poslední zmíněný (CI), protože svou funkčností plně odpovídá záměrům prototypu. Je rychlý a jednoduchý právě pro zprovoznění prototypu.

3.8

Databáze

Osobní zkušenosti mám s databází MySQL, MSSQL i ORACLE, ale protože u první zmíněné znalosti převažují a navíc je všeobecně dostupná na většině serverů, rozhodl jsem se pro ni. Databáze bude využívána pro ukládání jak herních specifikací týkajících se hraných her a jejich hráčů, tak i jednotlivých parametrů trhů a rozhodnutí firem v každém kole. Využití Frameworku skrývá specifika různých databázových systémů a umožňuje tak uživateli pracovat nezávisle na typu či verzi databáze. Důvodem využití databáze MySQL je i to, že celý prototyp jsem vyvíjel na svém počítači, kde pod serverem Apache 2.0 běží právě zmiňovaná databáze. Pokud by se ve vývoji prototypu pokračovalo, nebyl by problém převést jej na školní server, kde běží databáze ORACLE. Tato změna by si vyžadovala jen úpravu tabulek při převodu a jen drobné změny ve skriptech. V závěru se pokusím nastínit způsoby testování prototypu a návrhy na jeho dokončení a spuštění jako hotového systému.

24

4 4.1

Vlastní práce Poznámka o číslování verzí hry

Simulační hra se již několik let hraje na cvičeních předmětu Strategický management a s dalším jejím vývojem a využitím se počítá do budoucna. Abychom diverzifikovali jednotlivé vývojové verze, zavedli jsme interní číslování. Popíšu nyní nejdůležitější vývojové verze hry. Verze 1.0 - První verze, kde bylo pro zadávání rozhodnutí, průběh simulace i stahování výsledků využito výpočetní techniky a webového rozhraní pro komunikaci. Předchozí verze fungovala na papírovém zadávání a odevzdávání. Verze 1.1 - Současná verze, se liší od verze počáteční (1.0) jen v malých detailech a pro zobecnění se budu dále bavit o obou prvních verzích jako o jedné. Verze 1.2 - Této verzi se věnuji ve své diplomové práci. Její spuštění plánuje Ústav managementu v zimním semestru akademického roku 2008/2009. Verze 2.0 - Je plánována radikálně odlišně od původní verze 1.0. Jde o implementaci velkých rozšíření, které budou mnohem věrněji simulovat podmínky reálného trhu a umožní hráčům více způsoby ovlivňovat objemy prodeje svých firem.

4.2

Obecně o simulační hře Ústavu managementu

Projekt simulační hry vznikl jako nápad v hlavách pracovníků Ústavu managementu před asi 10 lety. Model pak byl vytvořen pro ověření praktických manažerských dovedností studentů předmětu Strategický management. Jeho cílem je simulovat chování skutečného trhu nebo spíše se jeho chování co nejvíce přiblížit. Velkou výhodou simulace je, že chybná rozhodnutí manažerů nebudou mít tak drastické důsledky jako by měla v reálném světě. Dle mého názoru neexistuje levnější způsob procvičení manažerských schopností, než na simulovaném modelu, kde chyba hráčů znamená maximálně snížení bodového zisku za cvičení a nikoliv bankrot skutečného podniku. Snahou Ústavu managementu je model co nejvíce přizpůsobit skutečnosti a zavést do něj co nejvíce vlastností reálného trhu.

4.3

O hře 1.0

Jako student MZLU jsem předmět Strategický management, kde se na cvičeních tato hra hrála, absolvoval v letním semestru akademického roku 2006/2007. Od té doby se hra rozšířila, ale ne tak zásadně. Aktuální verzi proto interně označujeme jako 1.1. Níže se budu proto zabývat problémy a nedostatky, které jsem ve verzi viděl při jejím hraní spíše z pohledu samotného hráče. Tento první úhel hodnocení jsem zaměřil na pravidla simulační hry, je ale ještě potřeba zhodnotit hru z druhé strany, tedy od jejich instruktorů a administrátorů. V další fázi pak budu hodnotit principy průběhu hry. Simulační hra, která je v zimním i letním semestru akademického roku 2007/2008 na cvičeních Strategického managementu hrána, nedává příliš velké pravomoci hráčům ovlivňovat chod firmy, nicméně dostatečně vystihuje hlavní princip fungování trhu. Nelze samozřejmě ani očekávat, že se simulace skutečnosti přiblíží v míře, kdy budou obě verze splývat, ale je nasnadě, že je zde ještě spousta míst, kde lze dodatečnou funkčnost implementovat. Rozsah rozhodovacích pravomocí nezohledňuje čas strávený nad tvorbou rozhodnutí jednotlivých firem. Samozřejmě, že nejlepší firmou nemusí být zákonitě ta, která si s výpočty nejvíce lámala hlavu, ale na druhou stranu se pravidelně stávalo, že mezi nejlepšími firmami na trhu se objevovaly ty, které rozhodnutí sázely bez velkého promyšlení a rozhodnování. To je dáno především malou možností plánovat dlouhodoběji. Systém se točí ohledně prodeje a výroby dvou typů výrobků, kde není právě příliš prostor na rozdílné strategie a velké plánování.

25

4.3.1

Vývoj

Doposud na škole podobný systém nikdy neběžel a i Simulační hra překonala řadu vývojových fází. Hra je založena na kolovém systému, kde každé kolo se skládá ze tří částí (rozhodovací fáze, simulace a výsledková fáze). Jedno kolo pak trvá většinou jeden kalendářní týden. Hru hrají studenti předmětu, kteří si ”založí” firmy čítající z pravidla 2 - 4 hráče. Simulační hra je v předmětu Strategický management používána od akademického roku 2001/2002. V tomto roce byl dokončen vývoj její první funkční verze, ke kterému dala impuls nakonec neúspěšná spolupráce s holandskou firmou Rematch, b. v., již v roce 1994. Vývoj hry probíhal z vnitřních zdrojů Ústavu managementu, kde po několika letech hledání vhodného simulačního software, bylo nakonec přistoupeno k pokusu realizovat simulaci prostřednictvím tabulkového procesoru Excel. V tomto prostředí byla také hra dokončena a je v něm dosud realizována, jak v české, tak v anglické jazykové verzi. V dosavadních cca patnácti bězích simulace byly postupně dolaďovány chyby původního modelu a teprve nedávno bylo přistoupeno ke snaze přiblížit realitě prostředí modelu. Měnilo se také uživatelské rozhraní simulace, jak ze strany studenta, tak ze strany instruktora. Při prvních bězích simulace byla rozhodnutí jednotlivých hráčů (firem) odevzdávána v papírové podobě a instruktoři je následně vyplňovali do excelové tabulky. Další verze již měly jednoduché uživatelské rozhraní, které jednoznačně zrychlilo sběr dat a tím výrazně snížilo pracnost vyhodnocování rozhodnutí instruktory. 4.3.2

Funkčnost

V současné době je funkčnost systému založena na webovém rozhraní, které sbírá a zároveň kontroluje zadané rozhodnutí hráčů tak, aby nebylo, svými hodnotami, mimo povolené meze a systém jej tak dokázal vyhodnotit. Fáze zadávání rozhodnutí byla vždy omezena na několik dní. Po jeho ukončení musí mít všechny firmy rozhodnutí zadáno, jinak je rozhodnutí vyplněno instruktory osobně ”pseudonáhodnými” hodnotami. Výsledná data se exportují do souboru typu CSV, které pak otevřou jednotlivě (za každou firmu zvlášť) v Excelu, který již z těchto údajů, pomocí uložených specifických funkcí a několika dalších souborů zdrojových dat (potenciálů trhů, cen surovin apod.) vypočte výsledek počínání firmy v příslušném kole. Výsledky jednotlivých kol jsou poskytovány v tabulkovém souboru, který v podstatě představuje základní účetní výkazy (rozvaha a výkaz zisků a ztrát) a další informace o průběhu daného kola (prodaná a vyrobená množství produktů, údaje o vývoji trhu, apod.). Tyto údaje jsou pak k určitému datu, z pravidla k začátku kola dalšího, zveřejněna konkrétním firmám, které na jejich základě staví při rozhodnutích dalších. Tématicky je projekt zasazen do výrobního prostředí firmy vyrábějící nábytek (pro jednoduchost zatím jen dvou typů výrobků). Manažeři - hráči rozhodují pak v oblastech marketingového výzkumu, odbytu, zásobování, výroby, řízení lidských zdrojů a financování. Hráčům je dán prostor pro pochopení a otestování hry v podobě jednoho zkušebního kola. Po jeho dohrání a prezentaci výsledků jsou hry vytvořeny znovu. Samozřejmě s jinými zdrojovými daty, aby hráči nemohli rozhodovat na základě výsledků ze zkušebního kola. Současný stav neumožňuje spouštět více her současně. Aktuálně se problém řeší kopií celého systému do jiného adresáře. Toto řešení je ale velmi neefektivní a je náročné na správu. Řeší se takto právě jazykové lokalizace.

26

4.4

Podobné projekty

Na půdách mnohých ekonomických škol se vyskytují podobné projekty v různých mírách propracovanosti a v různých stádiích vývoje. Rovněž některé větší firmy využívají východ manažerských simulátorů, mezi ty největší patří např. Microsoft, k jehož simulátoru se ale lidem mimo firmu přiblížit nepodaří, proto jej zde zmiňuji jen informativně. Rovněž i vysoké školy si své projekty hlídají a jsou jen velmi málo ochotny o nich cpkoliv sdělit. Projekty níže jsou zde jen pro porovnání simulovaných problematik. Při jejich analýze jsem vycházel z veřejně dostupných pravidel hry nebo z dostupného popisu jejich funkčností. 4.4.1

Promis

Simulační manažerská projektová hra Ekonomicko-správní fakulty Masarykovy univerzity je jedním z několika projektů zabývajících se problematikou manažerských simulátorů. Jak její další přídomek ”projektová” napovídá, cílem hry je řídit jeden projekt. Hráči se v projektu stávají manažery stavební firmy a snaží se svým rozhodováním realizovat stavbu obchvatu v co nejkratším čase a s co nejmenšími náklady. Hra se skládá ze dvou hlavních částí. První je plánovací etapa a druhá řízení vlastní stavby obchvatu. Během obou částí jsou pak hráčům předkládány různé nástrahy vycházející ze skutečných situací. Bez přístupu k systému je velmi těžké rozlišit úroveň projektu, ale rozhodně je projekt simulovanou problematikou přinejmenším zajímavý. 4.4.2

Manahra

Druhým projektem je simulační hra rovněž z Ekonomicko-správní fakulty Masarykovy univerzity, která se využívá přímo pro hodnocení studentů daného předmětu. Hodnotícím kritériem je zhodnocení majetku studenta v této simulaci. Tento zajímavý motivační prvek jistě zatraktivňuje celý průběh hry. Dle zveřejných výsledků hry lze odhadnout, že hra není příliš jednoduchá, neboť ji několik procent hráčů dohrálo neúspěšně. Cílem hráčů je překvapivě zhodnotit svůj majetek. Ten lze totiž brát jako nejvýraznější ukazatel úsilí daného hráče. Ve hře vystupují vždy v několika rolích a to především jako jednotlivci - fyzické osoby nebo jako členové týmů. Každý tým má určitou hierarchickou strukturu, do které jsou jednotlivci voleni. Na trhu se pak týmy vyskytují v několika podobách, a to buď jako management automobilového výrobního závodu nebo jako management banky. Hra je hrána kolovým způsobem a je rozdělena na 3 fáze. Během první se hráči seznamují s herním prostředím a utvářejí (volí) si jednotlivé pozice v týmu. Další fází je již sehrávka hry (rozdělena do kol), kdy již hráči provádějí rozhodnutí. Tato fáze se skládá z analýzy výsledků kol předchozích, z přípravy strategií pro aktuální kolo a z uskutečnění těchto kroků. Závěrečná třetí fáze je fáze hodnocení hry, které je pro hráče ukončeno známkou z předmětu. Stejně jako do předchozí hry Masarykovy univerzity, nevidím do její funkčnosti a odvozuji ji jen z dostupných popisů a pravidel, které jsou zveřejněny na stránkách hry. Přijde mi propracovanější než simulační hra ÚMA. První plus hry vidím v rozdělení rolí mezi hráči. Tímto jsou obchody především závislé ne na náhodně vygenerovaných hodnotách, ale na potřebách, náladách i schopnostech jednotlivých hráčů. Rozdělení rolí, v kterých hráči vystupují, zajišťuje, že hlavním smyslem hry není komunikace s počítačem spravovaným trhem, ale komunikace s hráči a s týmy samotnými. Všeobecně každá hra, kde je soupeřem jiný ”živý” člověk, je pro hráče přitažlivější a zábavnější. První fáze Manahry, kdy se hráči seznamují s prostředím, je u simulační hry částečně promítnuta do zkušebního kola.

27

4.5

Shrnutí hodnocení verze 1.0

Největším problémem simulační hry v této verzi, který vidí samozřejmě i vedoucí hry a který je v každém semestru upravován, jsou pravidla. Umožnit hráčům větší možnosti pro ovlivnění svých rozhodnutí by zatraktivnil i ztížil hratelnost hry. Větší obtížností pak vznikla možnost vyhodnocovat pomocí výsledků ze hry zápočty nebo i zkoušky z daných předmětů. Tímto krokem by se určitě zvýšila zainteresovanost hráčů. Druhou problémovou doménou je samotné hraní her, jejich tvorba, ovládání a zpracování výsledků. Současný stav neumožňuje spravovat více her současně a počítá taky jen s jedinými pravidly pro hraní. Výpočtovou částí umístěnou do souborů tabulkového procesoru pak nijak neusnadňuje správu tvorby výsledků a naopak dává prostor k tvorbě chyb.

4.6

Plánování verze hry 1.2

Nová verze pravidel i celé hry je plánována na zimní semestr akademického roku 2008/2009, bude obsahovat již pozměněnou funkčnost. Ta počítá především se zavedením více druhů výrobků a surovin a taky rozdílného typu strojů pro výrobu výrobků. Naopak se stále počítá s využitím Excelu pro výpočty. Zde se pokusím požadavky doplnit, navrhnout a implementovat kompletní funkčnost (tedy i výpočtovou část) pod jedno rozhraní. Detailnější požadavky na nový systém budu analyzovat v následujících kapitolách. 4.6.1

Běh hry

Nedostatky, které vidí její zadavatelé, jsou především v nedostatečné lokalizaci hry a v nemožnosti simulovat více běhů hry. Během je myšleno rozdílné období začátku a konce kola, což je nezbytné pro rovnoměrné rozložení času na hru na všechny týmy v různých cvičeních. Je zřejmé, že většina studentů řeší výpočty a rozhodnutí na cvičeních. A pokud dříve při jednom běhu byla uzávěrka kola v pátek, studenti pondělního cvičení měli jasnou výhodu v podobě dostatečného množství času. Oproti studentům z pátečních cvičení, tak mohli korigovat své výpočty a rozhodnutí delší dobu. Aktuálně byly běhy řešeny založením nové hry, toto však neumožňovalo hodnotit hráče resp. jejich firmy v rámci jedné hry. Lokalizace do více jazyků, především tedy do angličtiny, by umožnila hrát souběžně na jednom trhu i studentům studujícím na naší škole v angličtině. Počet kol rovněž neumožňuje lépe uplatit strategie jednotlivých firem, nicméně se počet kol již nyní, oproti předchozím ročníkům, zdvojnásobil. Správa hry během jejího běhu je nyní náročnou činností. Především spočívá v ručním zpracování výsledků jednotlivých rozhodnutí firem pro každé kolo a firmu zvlášť. Instruktoři hry musí vždy ke každé firmě data uložená z webového formuláře otevřít v MS Excelu a zpracovat. Existence předpřipravených tabulek zpracování sice usnadňují, ale i tak zpracování zabere jistý čas, který by mohl být využit efektivněji. Existuje zde rovněž i velká možnost pro vznik chyb ze strany instruktora, které by vedly k nekorektním výsledkům a tedy k poškození firem v simulovaném prostředí trhu. Systému jednoznačně prospěje přesunutí výpočtové fáze pod jedno rozhraní společně se zadáváním a prezentací výsledku a ovládáním tvorby hry. S přechodem simulační hry na zadávání rozhodnutí přes webový formulář se celá správa hry výrazně zjednodušila. Začleněním i výpočtového rámce do této struktury umožní vedoucím hry lépe spravovat její průběh. Nevýhoda přechodu na webový portál je způsob jeho údržby. Vždy je nutné změnu ve výpočtech konzultovat s programátorem, který ji pak uvede do činnosti. Faktem je, že i změnu ve funkčnosti v tabulkovém procesoru musel provádět člověk z určitými zkušenostmi. Takže tato nevýhoda je jen relativní.

28

Jednotné rozhraní pro administraci her vytvoří možnost realizovat souběžně více her pro rozdílné skupiny hráčů. Celá simulační hra je založena na myšlence utkávání se studentů v rámci předmětů. Obtížnost hry nebo rozdílná pravidla by se pro daný předmět dala nastavit různě (je nutné je pak mít předdefinované) a tím by se mohli utkávat studenti v rámci svých předmětů či v rámci ročníku nebo fakulty. 4.6.2

Pravidla hry

Celá hra je postavena na rozhodování o ceně výrobku a o plánování výroby, které jsou sice stěžejním, nikoli však jediným parametrem reálného trhu. Pro zlepšení kvality hry a tedy i její přiblížení realitě je potřeba přidat více nastavitelných či ovlivnitelných parametrů hry. Téměř do každé sekce současné simulované firmy by šlo přidat několik vlastností, atributů a funkcí, které by ji více přiblížili reálně fungující společnosti a trhu. Spoustu jich má ÚMA již připraven a počítá se zavedením během dalších vývojových verzí. Celé dění okolo fiktivní firmy spočívá pro členy týmů jen v zadávání hodnot do systému. Hodnocení jednotlivých kroků je pak věcí druhotnou. Přiznám se, že v tomto se mi, byť už jen z popisu v pravidlech hry, líbila Manahra z ESF MUNI, kde existují role v týmu a tedy teoreticky nikdo se nemůže vést s týmem. Hra zavedením rolí získá na zajímavosti a zvýší hratelnost, navíc hráči by se mohli ve hře lépe profilovat. Jako hlavní novinka ve fungování simulovaných trhů ve verzi 1.2 bude zavedení více typů výrobků, více druhů surovin a více strojů, na kterých se dají výrobky vyrábět. Přechodem na online systém by pak počet těchto výrobků, surovin i strojů byl teoreticky nekonečný a omezený jen výpočtovou náročností, kterou by server byl schopen unést. Instruktorům tato změna dává možnost rozdělit stroje podle výkonu a ceny (např. stroj level 1, level 2) nebo podle toho, který výrobek zpracují rychleji a levněji (např. stroj na dřevěné židle, plastové stoly).

29

Nové ovládání všech hraných her z jednoho místa dále umožní nastavovat rozdílná pravidla pro rozdílné hry daných předmětů. Toho lze s výhodou využít např. u předmětu Management, který je na bakalářském stupni studia, kde by studenti předmětu mohli hrát jednodušší verzi hry na méně kol, aby si procvičili základní principy fungování trhu a předmětu Strategický management na inženýrském stupni, kde by zvolená pravidla umožnila znalosti studentům ještě více prohloubit. Pro specifikaci požadavků jsem využil diagram případů užití.

Obr. 6: Diagram případu užití

30

Diagram případu užití zobrazuje hlavní funkčnost simulace běhu hry. Obsahuje kroky, které uživatelé systému musí vykonat pro zajištění svých požadavků na systém. Pro notaci bylo použito velbloudího zápisu, toto je standardně doporučovaná forma popisu UC. Popis jednotlivých aktorů: Administrátor - Tato role, která má na starosti tvorbu hry a všechny operace s tímto spojené, nastavuje všechny herní parametry, volí pravidla hry, počet běhů, termíny zadávání rozhodnutí. Nastavuje trhy, firmy a spravuje hráčskou agendu. Instruktor - Role instruktora je odlišná od role administrátora, i když fyzicky je velmi pravděpodobné, že se bude jednat o stejnou osobu. Jeho úlohou je spravovat průběh hry, tedy kontrolovat zadaná rozhodnutí hráčů a tvorbu výsledků pro každé kolo. Hráč - Tento aktor je schopen pouze zadávat rozhodnutí za svou firmu a může si zobrazovat výsledky svých počínání. Podmínkou u všech aktorů pro komunikaci se systémem je být přihlášen a mít zvolený jazyk. Popis vybraných případů užití: Zadat Rozhodnutí - Tento UC spouští hráč. Nutnou podmínkou je, aby bylo aktivní období pro zadávání rozhodnutí (u simulační hry je to vždy několik dní v týdnu, zaleží pak na běhu hry, které to jsou). Dle zvolených pravidel se pak uživateli vygeneruje formulář pro rozhodnutí. Hráč pak vyplní povinné položky a formulář odešle ke zpracování. Systém data ověří, a pokud jsou v pořádku, uloží je.

Obr. 7: Specifikace případu užití Zadat Rozhodnutí

31

Vytvořit výsledky - UC spouští instruktor. Podmínkou spuštění je potvrzení a překontrolování všech výsledků firem, které v dané hře hrají. UC vypočítá výsledky dle zvolených pravidel. Ty pak uloží a jednotliví hráči (firmy) si je můžou prohlédnout.

Obr. 8: Specifikace případu užití Vytvořit výsledky

Potvrdit Rozhodnutí - UC spouští instruktor. Podmínkou spuštění je ukončení zadávání rozhodnutí pro hráče a zadané rozhodnutí firmou. Instruktor zobrazené výsledky hráče ještě jednou překontroluje (předtím to dělá systém automaticky, který odhalí jen chyby v nesprávném formátu zadaného parametru nebo v jeho odchylce od limitů), tímto způsobem může ovlivnit automatický výpočet výsledku.

Obr. 9: Specifikace případu užití Potvrdit rozhodnutí

32

Hromadně importovat hráče - UC jespouštěno adminem v začátku hry. Kdy je potřeba nahrát velké množství studentů - hráčů. Při změnách v registracích se ještě dodatečně přihlásí či odhlásí již jen několik hráčů, které lze zadat ručně a rovnou je přiřadit do firem.

Obr. 10: Specifikace případu užití Hromadně importovat hráče

Specifikace požadavků vyjasnila principy fungování systému. Zejména se objasnila potřeba funkčnosti pro zajištění chodu hry. Fáze plánování připravila výchozí podklady pro analýzu simulační hry a vytváření jejího prototypu.

33

4.7

Systémová analýza

Základní fungování systému nastínila již specifikace požadavků. Je ale potřeba prohloubit tyto znalosti a připravit model na vytvoření prototypu. Při systémové analýze jsem se zaměřil na pravidla hry, která tvoří jádro celé simulační hry a naopak jsem se již tak důkladně nezabýval uživatelským rozhraním a tedy komunikací uživatelů s celým systémem. Pro analýzu jsem využil diagramy tříd a aktivity. Hlavní myšlenkou při tvorbě modelu pravidel byla snaha jej navrhnout tak, aby byl plánovaný systém lehce rozšiřitelný. Systém se totiž plánuje rozšiřovat v etapách představujících vždy jeden semestr. Proto jsem rozdělil analýzu do dvou částí. V první se budu zabývat obecným modelem pravidel hry, který bude lépe osvětlovat rozšiřitelnost než konkrétní funkčnost. V druhé se naopak zaměřím na analýzu modelu pravidel nejbližší připravované verze systému. Tady bude naopak cílem konkretizovat funkčnosti jednotlivých částí modelů pravidel. Jak již jsem několikrát zmínil, projekt simulační hry se pravidelně rozšiřuje. Spousty možností pro další rozšíření jsou již naplánovány a rozvrženy do dalších etap. Jen namátkou zmíním ty nejbližší, týkající se nejbližší vývojové verze nebo verze hned další v pořadí. Jako hlavní změna pro další období se plánuje zvýšení diverzifikace a rozmanitosti výroby, tedy konkrétně v počtu surovin, výrobků a typů výrobní techniky. Nyní se využívalo 2 surovin, 2 výrobků a univerzálního typu stroje. Další uvažovanou změnou je zavedení speciálních povolání zatím jen pro výrobu. Jednalo by se např. o povolání truhláře nebo lakýrníka, tedy o osoby nutné pro určité vývojové fáze výrobku. Zavedení rozdílných povolání by ale udělalo systém příliš složitým právě proto, že nebude otestována verze s více typy strojů a nebudou tak nastaveny pro ni celé podmínky trhu. Hra by pak činila problémy hlavně tvůrcům hry při nastavovaní parametrů, než samotným hráčům. Po otestování a zavedení plánované funkčnosti bych ale zavedení povolání začlenil hned do další vývojové fáze hry (pro další rok). Cílem těchto změn je zatraktivnit celý proces simulace a větší zainteresovanost jejich hráčů. Implementace těchto dílčích změn by si však neměla vyžadovat změnu v celém programu. Je to hlavně z důvodu snahy implementovat změny pravidelně. Velké změny v celých pravidlech by si pak vyžadovali mnohem více času na přetvoření programu a delší období testování. Jak je ostatně vidět z mého příkladu změn, týkají se vždy ne více než jedné sekce simulované firmy. Proto je také celý diagram tříd, který jsem pro tuto analýzu zvolil, rozdělen dle pracovišť firmy a dle segmentů trhu, se kterými podnik přichází do styku. Toto rozdělění do sekcí či modulů pak rovněž využiji při tvorbě kódu pravidel. V diagramu jsem nastínil i způsoby (směry) rozšíření (třídy šedou barvou). Cílem těchto změn je kromě neustálého vylepšování hry i využití starších jednodušších modulů nebo jejich specifických kombinací pro hraní v jiných předmětech, kde bude hra zacílena na procvičení konkrétnějších okruhů znalostí nebo pro nižší ročníky zase pro ověření základních schopností hráčů vžít se do simulovaného tržního prostředí. Struktura činnosti a funkčnosti simulační hry v kontextu její rozšiřitelnosti by nyní měla být z diagramu patrnější. V diagramu jsou zahrnuty předpokládané směry rozšíření pravidel.

34

Obr. 11: CLASS diagram obecné verze pravidel

35

4.7.1

Analýza aktuální verze

V následující části se budu zabývat analýzou konkrétní plánované verze pravidel a zaměřím se na její funkčnost. K tomuto využiji diagram tříd, na který navážu diagramem sekvenčním a diagramem aktivit. Diagram tříd je složen z dílčích objektů představujících na jedné straně firmu a její sekce a na straně druhé faktory vnějšího prostředí, které jsou ve vzájemné interakci.

36

Obr. 12: CLASS diagram pro verzi pravidel 1.2

37

Snaha o sjednocení tématicky podobných částí, které budou pro další rozšiřitelnost výhodné, mě vedla k vytváření balíků. V diagramu tříd lze najít dva. První do sebe zahrnuje zdroje a snaží se je hierarchicky rozčlenit a druhý zahrnuje všechno zboží. Lze si pak jednoduššeji představit rozšiřování i v těchto diagramech.

Obr. 13: CLASS diagram pro package zboží

Obr. 14: CLASS diagram pro package zdroje

38

4.7.2

Diagramy aktivit

Při tvorbě diagramů tříd vyvstaly požadavky na podrobnější specifikaci jednotlivých metod některých tříd. Zavedl jsem proto diagramy aktivity, které potřebnou dodatečnou funkčnost dobře postihly. Metoda Prodej zboží - Diagram postihuje princip fungování prodeje zboží na trhu v simulační hře.

Obr. 15: Diagram aktivit pro metodu Prodej zboží

39

Metoda Výroba zboží - Patří mezi nejsložitější procesy v simulační hře. Omezuje plánované rozhodnutí uživatelů, kteří špatně naplánovali svou výrobu a ovlivňuje výrazně výsledek podobně jako odbyt.

Obr. 16: Diagram aktivit pro metodu Výroba zboží

40

Metoda Nákup suroviny - Principem metody je v každém kole získat potřebné množství surovin pro výrobu.

Obr. 17: Diagram aktivit pro metodu Nákup suroviny

Metoda Změna stav zaměstnanců - Jejím cílem je nábor nebo propouštění zaměstnanců.

Obr. 18: Diagram aktivit pro metodu Změna stavu zaměstnanců

41

Metoda změn stav strojů - Tato metoda zajišťuje nákup a prodej strojů pro výrobní proces podniku.

Obr. 19: Diagram aktivit pro metodu Změna stavu strojů

42

4.8 4.8.1

Tvorba prototypu Postup implementace

Při tvorbě prototypu jsem se nejdříve seznámil a nastavil Framework CodeIgnitor(CI) a propojil ho s databází. Dále jsem vytvořil databázové schéma tabulek, které vychází ze systémové analýzy a diagramu tříd. Následnou implementaci funkčnosti jsem pak rozdělil dle iterativní metody životního cyklu do několika částí, ke kterým jsem postupně funkčnosti iterativně přidával. Nejprve se jednalo o přihlašovací moduly, po kterých následovala správa hry administrátorem. Pak jsem začal vytvářet zadávání rozhodnutí a následně jejich zpracování do potřebných výsledků. Poslední fází pak bylo zobrazování výsledků. 4.8.2

Nastavení Frameworku

Pro spuštění CI s požadovanou funkčností bylo potřeba načtení tříd, modulů a helperů, nastavení automaticky načítaných souborů a nastavení mod rewrite pro přepisování URL. 4.8.3

Hierarchická struktura

Framework CI již určitou hierarchickou strukturu má. Je založena na MVC (Model, Viewer, Controller), kterou jsem dále rozvinul v příslušných úpravách pro správu různých verzí pravidel. Adresářovou strukturu přikládám.

Obr. 20: adresářová struktura prototypu

Červeně označené adresáře v poslední sekci označují základní logickou strukturu CI, založenou na MVC, kterou jsem v každém z těchto adresářů rozšířil o pravidla. Každé pravidlo je ve všech těchto adresářích uloženo v adresáři, který má vždy stejné jméno. Pro nová pravidla jsem zvolil označení p1. Označení souborů je v této hierarchii rozděleno jak podle MVC, tak podle mého interního označení, kdy první část názvu souboru označuje kategorii. Na prototyp jsem použil 3 kategorie odpovídající rozdělení činností 3 aktorů Předpona game pro hraní hry hráči, control pro správu hry instruktory a admin pro administraci hry. První dvě jmenované jsou vždy součástí konkrétních pravidel.

43

Názvy automaticky načítaných souborů se zapisují do config/autoload.php. Jedná se především o knihovny pro práci s databází a session. $autoload[’libraries’] = array(’database’,’session’); S výhodou jsem využil i některé z předpřipravených helperů, které CI nabízí. Šlo o helpery pro práci s URL, formuláři a bezpečnostími prvky. $autoload[’helper’] = array(’url’,’form’,’security’); I pro použití dalších funkcí, které jsem si vytvořil např. v modelech, jsem využil třídu autoload, která vše načte již při úvodním spuštění. 4.8.4

Návrh databáze

Pro návrh databázového modelu jsem se rozhodl využít ERD diagramu. Vytvořil jsem jej pak v programu PowerDesigner 6. Návrh databáze mi pak pomohl rychleji realizovat její skutečnou podobu a dalším vývojářům osvětlí lépe mé záměry. K označení tabulek jsem zvolil formát sh nazevTabulky, kde prefix značí simulační hru(sh). Tímto způsobem zjednodušíme práci s tabulkami, pokud by databázi bylo více jiných tabulek. Pro označení tabulek patřících ke konkrétním pravidlům jsem přidal ještě i verzi pravidla. Formát pro tabulku nesoucí informaci o části pravidel je pak sh nazevPravidla nazevTabulky.

44

Obr. 21: Návrh databázového schématu

45

4.8.5

Realizovaná funkčnost

Při tvorbě prototypu jsem se snažil postihnout co největší část současné verze pravidel simulační hry a zahrnout většinu jejich aspektů. Zároveň měl prototyp obsahovat plánovanou novou funkčnost. Nesnažil jsem se ale za každou cenu zahrnout všechny detaily modelu původního. Prioritou bylo postihnout novou funkčnost spočívající v převedení výpočtové části z MS Excelu do webového rozhraní, které integruje všechny požadované funkce na systém. Pro návrh některých částí funkčnosti jsem využil sekvenčních diagramů. Ty by měly přiblížit principy funkčnosti kódu prototypu. Administrátor Role administrátora umožňuje spravovat jednotlivé hry, různě je modifikovat, spouštět i mazat. To vše z jednoho místa. Každou vytvořenou hru označí administrátor unikátním názvem, přiřadí ji k předmětu, ve kterém se má hrát (pro přehlednost). Dále musí vybrat pravidla, podle kterých se hra bude hrát. Pravidla se nachází ve formě programového kódu v adresářích označených jejich verzí. Volbou pravidla se pak zvolený adresář promítne do výběru skriptů pro konkrétní funkčnost. Nastavuje se rovněž datum začátku hry. Stejné označení pro pravidla v názvu tabulek platí i pro adresář s programem pravidel. Po nastavení těchto základních parametrů hry se ze jejich seznamu jedna nastaví jako výchozí a lze ji podrobněji editovat. Možná se tento krok zdá poněkud nesrozumitelný, ale jeho opodstatnění je logické. Důvody jsou hned dva. Nejčastěji budou měněny detailnější parametry hry (běhy, trhy, firmy a hráči) a je potřeba tyto funkce pod hlavičkou hry sjednotit. Tento způsob by pak jednoduchou úpravou kódu administrace umožnil vytvořit individuální přihlašování přes formulář právě jen do konkrétních her. Tím by si její vlastníci mohli nastavit potřebné parametry své hry a nemohli by ovlivňovat, byť třeba nedopatřením hry ostatních. Toto rozdělení by se teoreticky dalo využívat při hraní ve více předmětech či na více fakultách.

Obr. 22: Sekvenční diagram Vytvořit hru

Tento diagram popisuje princip vytvoření nové hry v závislosti na funkcích prototypu. Předpokladem je úspěšné přihlášení administrátora do systému. Ten pak volá operace nutné pro vytvoření hry.

46

Pro představu o funkčnosti a ovládání aplikace prototypu zde budu kromě částí kódu uvádět i náhledy obrazovek tak, jak je vidí osoba, která s ní přijde do styku. První screen ukazuje ovládací část pro správu hry jejím administrátorem.

Obr. 23: Pohled na administraci hry

Na funkčnosti základních operací s hrou chci ukázat výhodu Frameworku oproti klasickému přístupu. Níže uvedený kód je součástí skriptu controlleru admin.php a ukazuje proces generování přesných časů začátků a konců zadávacích období. /*********************************** * OPERACE S HROU * základní volba pro admina bude * právě operace s hrou * vytvořit, upravit, nastavit a zkopirovat **********************************/ function game_op($type = ’add’, $save = false) {

/* Metoda je volána ve dvou krocích. * V prvním případě není parametr save nastaven na hodnotu ’save’ * a zavolá se viewer, který vytvoří formulář z předložených dat. * Druhá část funkce pak data uloží. * Toto platí pro insert a update, delete nepotřebuje mít formulář. */ switch($type) { // PŘIDÁNÍ NOVÉ HRY: case ’add’: // UKLÁDÁM ... if($save == ’save’) { $this->admin_model->add(’sh_hra’); redirect(’admin’, ’redirect’);

47

} // NAČÍTÁM FORMULÁŘ ... else { $this->load->view(’head’); $data = $this->admin_model->get_param(’sh_hra’); $data[’op’] = ’add’; $data[’dir’] = ’system/application/controllers’; $data[’subj’] = $this->admin_model->get_all(’sh_predmety’); $this->load->view(’admin_game_view’,$data); } break; // ÚPRAVA EXISTUJÍCÍ HRY: case ’update’: if($save == ’save’) { $this->admin_model->update(’sh_hra’); redirect(’admin’, ’redirect’); } else { $this->load->view(’head’); $data = $this->admin_model->get_param(’sh_hra’,$save); $data[’op’] = ’update’; $data[’subj’] = $this->admin_model->get_all(’sh_predmety’); $data[’dir’] = ’system/application/controllers/rules’; $this->load->view(’admin_game_view’,$data); } break; // mazání hry case ’delete’: $str = $this->db->delete(’sh_hra’,’id=’.$save); redirect(’admin’, ’redirect’); break; } }

Jak je vidět, tak základní operace s hrou se vlezly na 50 řádků. Samozřejmě k tomu je třeba připočíst helpery, modely i viewery, ale vzhledem k poměrně striktnímu rozvření struktury celého Frameworku je sem nezahrnuji. Po zvolení verze hry, kterou chce administrátor dále upravovat, se mu otevře možnost spravovat dílčí specifika hry jako jeho běhy, trhy, firmy i jednotlivé hráče. Při nastavení běhu hry volí dobu zahájení a ukončení zadávání. Jelikož je plánováno hrát vždy jedno kolo týdně, protože velmi pravděpodobně se bude rozhodnutí zadávat na cvičeních, volí se jednotlivé dny.

48

Po uložení běhu hry se na základě zvoleného začátku hry a počtu kol vytvoří plán jednotlivých kol tak, že se vyhledá nejbližší den začátku běhu a jeho konce pro každé kolo hry. Na základě těchto časů je pak hráčům umožněno zadávat rozhodnutí jen v příslušném termínu. Detail obrazovky po zvolení hry i s jejími operacemi můžete vidět na obrázku níže.

Obr. 24: Pohled na detail administrace hry

A právě výpočet časového harmonogramu zde uvedu jako jednu z komplexnějších funkcí. Začátek i konec kola (myšleno hodinou a minutou okamžiku) je zvolen tak, aby odpovídal současným nárokům na hru. Je možné skript v budoucnu upravit tak, aby každé kolo trvalo jen několik hodin, takže kol se do týdne vleze 5. Každý večer po konci kola by instruktoři rozhodnutí překontrolovali a vygenerovali z nich výsledky. Další den by pak měly firmy možnost ve hře pokračovat, apod. /************************* * * Generování a uložení rozhodovacích období pro každé kolo, * je založeno na nalezení nejbližšího zadaného dne (zadávají se dny v týdnu) * a systém si pak z něj dopočítá timestampy pro každé kolo * *************************/ // vyber timestampu a poctu kol $query = $this->db->get_where(’sh_hra’,’id=’.$id); $row = $query->row(); $kol = $row->kol; list($rok,$mesic,$den) = split("-",$row->zahajeni); $zahajeni = mktime(0, 0, 0, $mesic, $den, $rok); for($i=1;$i<=$kol;$i++) { // ZAČÁTEK KOLA JE VŽDY V 00:00 ZADANÉHO DNE switch($_POST["zadavani_od"]) { case 1:

49

$from = strtotime("next Monday",$zahajeni); break; case 2: $from = strtotime("next Tuesday",$zahajeni); break; . . . case 7: $from = strtotime("next Sunday",$zahajeni); break; } // KONEC KOLA JE VŽDY MINUTU PŘED PŮLNOCÍ ZADANÉHO DNE. switch($_POST["zadavani_do"]) { case 1: $to = strtotime("next Monday 23 hours 59 minutes",$from); break; case 2: $to = strtotime("next Tuesday 23 hours 59 minutes",$from); break; . . . case 7: $to = strtotime("next Sunday 23 hours 59 minutes",$from); break; } $zahajeni = $to; $values = array( ’beh’ => $last_id, ’kolo’ => $i, ’zadavani_od’ => date(’Y-m-d H:i:s’,$from), ’zadavani_do’ => date(’Y-m-d H:i:s’,$to) ); $this->db->insert(’sh_kola_behu’,$values); }

Trhem je skupina firem, které spolu soupeří o umístění. V jednom běhu je těchto skupin více. Důležitým parametrem, který trh charakterizuje je jeho tržní potenciál pro prodeje výrobků a pro nákupy surovin. Tyto hodnoty musí být uloženy v databázi. Systém předpokládá, že potenciály jsou vytvořeny pro stejný počet kol jako má zvolená hra. Všechny potenciály jsem vygeneroval skriptem. Vycházel jsem z původních hodnot. Ty jsem totiž nemohl použít, především z důvodu časové náročnosti vkládání všech potenciálních prodejů pro každou cenu a kolo ze zdrojových dat a pak také proto, že počet výrobků jsem na novém trhu rozšířil. Proto vyšlo vygenerování nových výsledků mnohem lépe. Při začátku hry se do ní hromadně nahraje seznam hráčů. Pro tyto účely je zde formulář pro jednorázový upload. Jelikož ne všichni hráči jsou v začátku hry známi (z důvodu registrací a změn při registraci), umožňuje systém hráče přidávat jednotlivě. V posledním kroku registrace kdy si hráči vytvoří skupiny a založí firmy je v systému nutné tyto vzniklé firmy přiřadit na daný trh. Činnost administrátora hry je tedy důležitá v začátku hraní. Během průběhu hry má nejvíce práce osoba v roli instruktora hry. Není vyloučeno, že administrátor a instruktor jsou ta samá osoba. 50

Instruktor Instruktor má za úkol kontrolovat rozhodnutí firem, které může v případě porušení pravidel hráči upravit, a hlavně vytváří výsledky. Instruktor se přihlašuje jen ke konkrétní hře. Po úspěšném přihlášení se mu otevře stránka s aktuálním kolem simulace. Může vidět, které firmy již rozhodnutí zadaly a které ještě ne. Po ukončení zadávání rozhodnutí od firem (omezení v běhu hry), musí instruktor rozhodnutí všech firem potvrdit a případně je poopravit. Tento krok je nutný, protože všechna rozhodnutí nelze ošetřit pomocí programu. Jde např. o poskytování úvěrů. Instruktoři se většinou radí, zdali poskytnou úvěr v zadané výši nebo ji sníží či vůbec úvěr neposkytnou. V dalších verzích hry se těchto automaticky nerozhodnutelných aspektům může objevit více. Ty dodávají simulaci právě na reálnosti, neboť chování trhu není nikdy úplně stejné.

Obr. 25: Sekvenční diagram Potvrdit Rozhodnutí

Tento diagram ukazuje princip potvrzení zadaných verzí rozhodnutí instruktorem hry. Předpokladem je opět úspěšné přihlášení instruktora do správy konkrétní hry, ukončení zadávání rozhodnutí pro aktuální kolo pro hráče a vyplněné rozhodnutí. Druhým úkolem instruktora je zadat rozhodnutí pro firmu, která jej z neznámých důvodů nezadala. Instruktor se tak vlastním zadaným rozhodnutím snaží firmu penalizovat, protože jeho rozhodnutí nebude úmyslně patřit k nejlepším. Třetím úkolem osoby v roli instruktora je vyhodnocení rozhodnutí. Toto nyní automaticky provádí skript, jejž instruktor volá. Pro vytvoření výsledků je potřeba mít zadána a potvrzena všechna rozhodnutí firem ve hře. Výsledek se sice generuje pro každý trh zvlášť, a tedy není nutné čekat, až vyplní rozhodnutí všechny firmy v celé hře nebo v konkrétním běhu hry. Nechám jej zde však jak z historických důvodů, tak z plánů pro další verze hry. V současnosti hra s více trhy je hrána všemi firmami na různých trzích současně. To pak umožňuje větší přehled o hraní jak pro hráče, tak pro jejich instruktory. Plány pro budoucí rozšíření hry počítají s hrou mnohem většího množství firem na jednom trhu a je tedy možné že zůstane trh jenom jeden pro každou hru.

51

Pro představu níže uvádím rozhraní pro ovládání hry instruktorem. Na obrázku je vidět detail zadaného rozhodnutí pro firmu ABC, která jej ještě nemá potvrzeno. Vše se odehrává v prvním kole.

Obr. 26: Rozhraní pro správu hry instruktorem

Skript, který jsem vytvořil pro zpracování výsledků, pracuje postupně v několika cyklech, které lze teoreticky rozdělit do modulů. Jeho funkčnost je vždy dána příslušnou verzí pravidel, které pro hru platí. Výpočet vyžaduje jistou posloupnost činností jednotlivých firemních sekcí. Začíná se fází prodeje, následuje fáze zásobování, výroba, personalistika a fáze marketingového výzkumu. Poslední fází výpočtů je vyhodnocení financování firmy. Výsledky jsou uloženy a od tohoto momentu jsou dostupné každé firmě k prohlížení. Během výpočtu jsou případné chybně zadané hodnoty převedeny na povolené limitní a je vygenerována informativní hláška, kterou si hráči firmy mohou po zpřístupnění výsledků přečíst. Tento soubor poznámek pak instruktoři mohou doplnit o vlastní připomínky k vývoji chodu této firmy. Princip zpětné vazby mezi instruktory a hráči je z předchozích poznámek pod čarou a informativních značkách přetvořen do ucelenější podoby.

52

Nejzajímavější částí programování simulační hry resp. jejího prototypu bylo generování výsledků. Jednotlivé výpočty budu, tak jako u předchozích příkladů, komentovat přímo v kódu. Pro příklad uvádím výpočet odbytu firmy. /********************* * * VÝPOČET ODBYTU * *********************/ $q1 = $this->db->query("SELECT * FROM $tab_vyrobek"); // PRO KAŽDÝ VÝROBEK: foreach($q1->result() AS $row1) { $q2 = $this->db->query("SELECT *,sh_rozhodnuti.id AS ro_id, $tab_odbyt.id AS od_id,vyrobek FROM sh_firma, sh_rozhodnuti,$tab_odbyt WHERE sh_firma.trh=" . $row->tid . " AND sh_firma.id=sh_rozhodnuti.firma AND kolo=" . $this->session->userdata(’round’) . " AND sh_rozhodnuti.id=$tab_odbyt.rozhodnuti AND $tab_odbyt.vyrobek=" . $row1->id); if($q2->num_rows()) { //NASTAVENÍ PROMĚNNÝCH $potencial_trhu = $row->potencial_trhu; $ceny = $mnozstvi = array(); $mnozstvi_celkem = $cena_x_mnozstvi_celkem = 0; // PRO KAŽDOU FIRMU foreach($q2->result() AS $row2) { $poznamky[$row2->ro_id] = ""; // ÚPRAVA NA MIN NEBO MAX CENU VÝROBKU if($max_cena[$row2->vyrobek] < $row2->cena) { $ceny[$row2->ro_id] = $max_cena[$row2->vyrobek]; } elseif($min_cena[$row2->vyrobek] > $row2->cena) { $ceny[$row2->ro_id] = $min_cena[$row2->vyrobek]; } else $ceny[$row2->ro_id] = $row2->cena; // UPRAVA PRODAVANEHO MNOZSTVI - PRODAVAM JEN TO CO JE NA SKLADE $minule = $this->db->get_where("sh_rozhodnuti","firma=" . $row2->firma . " AND kolo=" . ($row2->kolo-1)); $minule_kolo = $minule->row();

53

$m = $this->db->get_where("$tab_sklad a, $tab_sklad_jednotka b", "rozhodnuti=" . $minule_kolo->id . " AND a.skladovaci_jednotka=b.id AND b.typ=".$row2->vyrobek); if($m->num_rows()) { $mn = $m->row(); // SNIŽUJU MNOŽSTVÍ KTERÉ CHCI PRODAT if($mn->mnozstvi < $row2->nabizene_mn) { $mnozstvi[$row2->ro_id] = $mn->mnozstvi; } else { $mnozstvi[$row2->ro_id] = $row2->nabizene_mn; } } // NEBO -> NA SKLADĚ NIC NENÍ, NASTAVUJU 0 else { $mnozstvi[$row2->ro_id] = 0; } // ČÁST VÝPOČTU TRŽEB $mnozstvi_celkem += $mnozstvi[$row2->ro_id]; $cena_x_mnozstvi_celkem += $mnozstvi[$row2->ro_id]* $row2->cena; $attr = array(’stav’ => 3); $this->db->update(’sh_rozhodnuti’,$attr,’id=’.$row->ro_id); } // PRŮMĚRNÉ NÁKUPNÍ CENY $pnc = ceil($cena_x_mnozstvi_celkem/$mnozstvi_celkem); $odchylky_od_PNC = array(); $abs_sum_pnc = 0; // sum absolutnich hodnot prum. nabidkovych // cen odectenych od zadanych cen firem // ABSOLUTNÍ SUMA PNC foreach($ceny as $key=>$val) { $odchylky_od_PNC[$key] = $pnc-$val; $abs_sum_pnc += abs($odchylky_od_PNC[$key]); } $odchylky_od_PNC_procenta = array(); foreach($odchylky_od_PNC as $key=>$val) { $odchylky_od_PNC_procenta[$key] = round($val/$abs_sum_pnc,2); }

54

// VÝPOČET SKUTEČNÉHO PRODEJE - VYPOČÍTÁVÁ SE OD POTENCIÁLNÍHO PRODEJE $celkem_firem = count($odchylky_od_PNC_procenta); $skutecny_prodej = array(); foreach($ceny AS $key=>$val) { $this->db->select(’mnozstvi, cena’); $this->db->order_by(’cena’,’ASC’); $q3 = $this->db->get_where($tab_potencial_trhu,’kolo=’ . $this->session->userdata(’round’) . ’ AND oznaceni="’ . $potencial_trhu . ’" AND vyrobek=’ . $row1->id); $odpovidajici_potencial = 0; //VÝBĚR SPRÁVNÉHO POTENCIÁLNÍHO PRODEJE foreach($q3->result() as $potencial_pro_cenu) { if($potencial_pro_cenu->cena <= $val) $odpovidajici_potencial = $potencial_pro_cenu->mnozstvi; } // VÝPOČET MOŽNÉHO FINÁLNÍHO PRODEJE $potencialni_prodej = ceil((1+$odchylky_od_PNC_procenta[$key])*ceil ($odpovidajici_potencial/($celkem_firem-1))-0.5); // POKUD FIRMA NEUSPOKOJÍ POPTAVKU, VZNIKAJÍ JÍ DODATEČNÉ NÁKLADY $NNP[$key] = ($potencialni_prodej>$mnozstvi[$key]) ? $naklady_neuspokojene_poptavky[$row2->vyrobek]* ($potencialni_prodej-$mnozstvi[$key]) : 0; // VÝPOČET FINÁLNÍHO PRODEJE: // ZÁVISÍ NA MNOŽSTVÍ VÝROBKŮ, KTERÉ FA NABÍZÍ $skutecny_prodej[$key] = ($potencialni_prodej<=$mnozstvi[$key]) ? $potencialni_prodej : $mnozstvi[$key]; }

Rychlost zpracování zadaných rozhodnutí ve výsledky je dána velikostí trhu a počtem firem na každém z nich. Přesná měření jsem neprováděl, ale nevidím v jejich tvorbě problém s příliš dlouhou výpočtovou dobou a tudíž s ukončením skriptu serverem. Počítám zde samozřejmě s předpokladem, že instruktor i server jsou na univerzitě a můžu tedy vyloučit časté výpadky spojení mezi linkami internet providerů.

55

Hráč Skupiny hráčů se pomocí přihlašovacích údajů firmy přihlašují ke hrám, které ve cvičeních předmětu hrají. Funkčnost tohoto třetího a posledního logického bloku programu obsahuje nejméně změn. Je to hlavně proto, že jeho činnost spočívá jen na aktuálních pravidlech a méně na logice simulační hry. Hráč změny u administrátorů ani instruktorů příliš nezaznamená. Je stále povinen zadat v příslušném termínu rozhodnutí a v určitý čas si zde rozhodnutí vyzvedne. Drobně se změní pravidla hry, zavedením nových funkcí. Změnil se rovněž způsob prezentace výsledků. Nyní jsou shromažďovány a sortovány ve webovém rozhraní. Rozhraní pro ovládání hry hráčem je velmi podobné ovládání instruktorem. Hráči si logicky mohou zadávat rozhodnutí a kontrolovat výsledky jen pro svou firmu. Přikládám zde pouze formulář pro přihlašování hráčů ke hře. Ten pracuje na stejném principu jako u instruktorů. Ti se jenom přihlašují do jiného prostoru s jinými právy, volí si ale při přihlašování, stejně jako hráči, hru, kterou chtějí ovládat.

Obr. 27: Pohled na přihlašovací formulář

56

5 5.1

Diskuze a srovnání Další vývoj simulační hry

Prototyp, vytvořený jako součást diplomové práce, nevyniká kompletní funkčností původní verze, i když obsahuje její velkou část a i části a funkce, které jsou naplánovány do budoucích verzí. Byl však založen na principu, který umožní celý systém dále mnohem jednodušeji rozšiřovat. Princip rozšiřitelnosti byl položen ve fázi analýzy. Plánované úpravy a rozšíření jsou a budou pravidelnou součástí spuštění každé hry. Tyto fáze pak lze rozdělit na hlavní změny, které proběhnou během léta a drobnější dílčí, které lze realizovat během zimní přestávky mezi semestry. Prototyp je ve fázi, kdy se do něj dají přidat dodatečné funkce a požadavky na zobrazování výstupů, které díky nově implementované funkčnosti nyní naskytly tuto možnost. Myslím si, že prototyp poskytne velmi pevný odrazový můstek pro rozvoj simulační hry Ústavu managementu.

5.2

Implementované funkce

Implementace nových funkcí a zautomatizování některých procesů, především ze strany administrátorské a instruktorské výrazně zrychlí práci kolem hry. Velkou výzvou byla integrace výpočtové části hry do celého rozhraní simulace. Nepopírám jisté výhody MS Excel při výpočtech vzorců, ale lze jej nahradit právě programovým kódem. V tomto bodě vidím největší nevýhodu nového projektu oproti staré verzi. Rychlost změny pravidel se do MS Excelu promítne rychleji, než do několika výpočtových skriptů. Pokud se ale podíváme na rychlost zpracování rozhodnutí, musíme tabulkový procesor jednoznačně zamítnout.

5.3

Zpracování rozhodnutí kol

Stará verze hry, využívající tabulkový procesor pro generování výsledků, vyžadovala delší pobyt instruktorů u tohoto procesu. Automatizací se zpracování zrychlí několikanásobně. Když si vezmeme čas na zpracování jednoho kola, kde bylo 18 firem a jedno zpracování trvalo 20 až 30 minut, dokážeme si představit náročnost jejich výsledků. Při neustálém zvyšování počtu firem a trhů v simulaci to představovalo limitující faktor rozšiřování.

5.4

Nasazení

Rozhodnutí o dokončení vývoje prototypu v simulační hru další verze, její nasazení již je na pracovnících Ústavu managementu, kteří projekt budou dále spravovat. Na nich pak bude finální rozhodnutí o nasazení resp. nenasazení vývojové verze vzniklé z prototypu. Jelikož by šlo o první verzi, která by nebyla založena na tabulkovém procesoru jako jádru výpočtové části, bylo by nutné rozsáhlejší testování. K němu by pak byl využit, kromě napsaných testů, i tabulkový procesor pro komparaci výsledků.

57

5.5

Rozšíření hry

Desetiletou historii simulační hry lze označit jen za začátek, vždyť webové rozhraní pro zadávání rozhodnutí se využívá jen 2 roky. Autoři s ní mají velké plány a návrhů na její rozšíření je celá řada. O konkrétních dílčích změnách, které se do systému integrují každý semestr, se rozhoduje mezi autory, instruktory a cvičícími a v posledních letech se počítá i s vyjádřeními studentů prostřednictvím evaulací předmětu. Podnětů a nápadů k rozšíření je spousta. První výtky k systému se týkaly funkčnosti a jeho chybovosti. Dnes je již funkčnost na vysoké úrovni a umožňuje hrát hráčům sofistikovanou hru. Přes všechny tyto seznamy na změnu bych rád navrhl úpravy, které by se do hry měly zahrnout co nejdříve. Podněty k tomu mi dal samotný proces vývoje prototypu. Změny se mohou týkat jak vnějšího prostředí, tak vnitřní struktury podniku. Otázkou je jen, kterým směrem rozšiřování se chce Ústav managementu vydat. Vnější prostředí by výrazně oživila geografická segmentace trhu. S tím by souvisela celá řada faktorů (distribuce výrobků, surovin, rozdílné hustoty zalidnění apod.). K tomu by bylo potřeba zavést novou sekci firmy - logistiku. Tím by plánování dostalo další dimenzi. Jelikož nový systém umožňuje využívat různé typy výrobních strojů, surovin i výrobků, zatraktivněním by bylo i jejich postupné zavádění na trh v průběhu simulace. Tím by vznikl další prostor pro strategie firem. Další rozšíření bych viděl ve zpětné vazbě mezi firmou a trhem (instruktory). Zavedl bych určité formy informací článků, které by pomohli predikovat vývoj poptávky na trhu nebo příchodu nové technologie. Ve vnitřním prostředí podniku figuruje dosud několik faktorů, které jsou brány jako konstanty s neomezenou velikostí. Jde především o velikost podniku, jeho výrobních nebo skladovacích prostor, neomezeného náboru apod. Zajímavým krokem by bylo zavedení fiktivních firem do trhů, aby ”živé” firmy měly více soupeřů. Možnosti řešení jsou buď pomocí umělé inteligence rozhodovat o datech nebo, což je jednodušší, předpřipravit si výsledky těchto firem do souboru.

58

6

Závěr

Projekt simulační hry Ústavu managementu se zabývá mně osobně velmi zajímavou tematikou. Využití manažerského simulátoru pro ověřování schopností studentů je výborný způsob testování těchto osob a lze jej využít i pro jejich hodnocení v daném projektu. Záměrně jsem si zvolil toto téma práce, neboť jsem hru v minulém roce hrál a tudíž jsem měl o ní nějaké informace již z dřívějška, byť byly jen ze strany hráčské. Téma, které by bylo zaměřeno na vývoj nového systému, by nemělo tak dlouhou fázi analýzy jako jsem měl já u simulační hry. Tento proces mi trval téměř 2 měsíce. Byl tak delší než fáze tvorby prototypu. Plánované zavedení nové verze hry s interním označením 1.2, která tvoří stěžejní část mé práce, je již na osobách z Ústavu managementu. Zdrojové data jsem jim předal a je jen na nich kdy, jak a zda-li vůbec hru zavedou do ostrého nebo alespoň zkušebního provozu. Nejobtížnější částí byla pro mě analýza pravidel a následné začlenění funkčnosti zadávání, zpracování, vyhodnocování a prezentace rozhodnutí hráčů. Zajímavá byla i zkušenost z PHP Frameworkem CI, který mi začal usnadňovat práci, až po důkladné analýze jeho funkcí. Jeho použití vnímám jako velkou výhodu, především v hierarchické struktuře, která mým pokračovatelům usnadní orientaci v systému. Přínos práce, bude-li zavedena, je určen především pro administrátory a instruktory her. Ti dostanou komplexní systém na správu herních parametrů i jednotlivých trhů a nemusí tak využívat několik různých rozhraní pro zajištění chodu hry.

59

7

Literatura

ARLOW, J., NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikace. 2. vyd. Brno: Computer Press 2007. 568 s. ISBN 978-80-251-1503-3. . HOLSAPPLE, C., WHINSTON, A. Decision Support Systems: A Knowledge-Based Approach. Boston: Thompson Learning, 2000. ISBN 0-324-03578-0. . LACKO B. Nové pohledy na životní cyklus tvorby Software z hlediska jakosti aplikací automatizovaného řízení. 2003. http://honor.fi.muni.cz/tsw/2003/076.pdf. KRÁL J., DEMNER. J. Softwarové inženýrství. 1991. Akademia Praha. NEUMAYEROVÁ I. Manažerské simulátory umožňují komplexní poznání podniku. 2005. http://www.mmspektrum.com/clanek/manazerske-simulatoryumoznuji-komplexni-poznanipodniku. SHELLY, G. B., CASHMAN, J. T., ROSENBLATT J. H. System Analysis and Design. 4. vyd. Boston: Thompson Learning, 2001. ISBN 0-7895-5957-9. . SWAAN A. H. de, JELLEMA M. An object-oriented model http://publishing.eur.nl/ir/repub/asset/762/eur-few-cs-98-03.pdf.

for

strategic

analysis.

1998.

SWAAN A., H. de, WAALEWIJN P., FLAES M. Implementation and Results of a Prototype Expert System on Strategic Analysis. Research Paper, Erasmus University Rotterdam, 1998. http://publishing.eur.nl/ir/repub/asset/755/eur-few-cs-98-07.pdf. SWAAN A., H. de, WAALEWIJN P. A Knowledge Base Representing Porter’s Five Forces Model. 1999. http://publishing.eur.nl/ir/repub/asset/753/eur-few-cs-99-02.pdf. VOJTKO V. K čemu manažerské profess.cz/data/art/kcemumngsim.pdf.

simulátory?.

2005.

http://www.e-

ZYKA, V. Řízení objektově orientované analýzy a designu. In: Sborník konference Tvorba softwaru 2000. VŠB-TU Ostrava 2000, str. 195-204.

60