Zdroj: UNICORN. Interní dokumenty, 2013
3.8.3 Vzor životního cyklu
Životní cyklus každého artefaktu, který jsme si popsali dříve v této kvalifikační práci, vychází přímo z tzv. vzoru životního cyklu. V rámci něj se definují vzorové stavy artefaktu a vzorové aktivity, které lze poté na jednotlivých instancích, vytvořených podle meta artefaktu, nastavovat a vytvářet. Jednotlivé vzory aktivit se dají dále konfigurovat, lze zde nastavit vzorového řešitele, vzorové stavy aktivity a především podmínky a akce pro danou aktivitu.
36
Podmínkou na vzoru aktivity určíme, za jakých podmínek dojde k automatickému vytvoření instance podle tohoto vzoru. Podmínkou může být nastavení konkrétního stavu artefaktu, stavu aktivity či podmínka časová. Naopak akce slouží k automatickému vykonání nějakého procesu. Pomocí definované akce lze nastavit stav aktivity, stav artefakt, popřípadě pustit skript. Oboje, akce a podmínky, jsou základními prostředky k automatizaci v rámci uuOS.
3.8.4 Vzor obsahu
Obsah artefaktu lze standardizovat obdobně jako životní cyklus. Ovšem nelze tak učinit u každého prvku obsahu artefaktu. Na meta artefaktu se definuje osnova, která slouží jako šablona jednotlivých listů, a vzory vlastností. Přílohy a komentáře není možné nějak standardizovat, ty už se vytváří na jednotlivých artefaktech nehledě na konfiguraci v metodice.
37
4 Shrnutí IS/STAG a Unicorn Universe Operatin System
IS/STAG je SIS s dlouholetou tradicí využívaný v dnešní době na více jak desítce českých univerzit. V systému jsou všechny potřebné standardní funkčnosti, které dnešní univerzity pro evidenci studentů na škole s kreditním systémem potřebují. Systém se soustředí čistě na evidenci studentů a jejich závěrečných výsledků. Nelze zde evidovat známky z dílčích testů a množství informací, které student v systému nalezne, je velmi omezené. Naopak je zajímavé, že vybrané informace jsou poskytovány i uživatelům, kterým do systému nebyl udělen přístup, což uuOS nijak umožnit nemůže.
Na druhé straně se systémem Unicorn Universe Operating System pracuje jediná vysoká škola. Artefakt v systému naopak slouží jako dokonalý prvek pro uchování jakéhokoliv druhu informace. Formou příloh a tvorbou různých artefaktů lze v systému jednoduše uchovávat všechny studijní materiály a potřebné informace. Není tedy potřeba dalších subsystémů či jiných služeb, které by doplňovaly e-learning či jiné formy studijní podpory, na druhé straně systém však postrádá některé ze standardních funkčností, např. tvorbu rozvrhu. Variabilitou artefaktu lze v systému vytvářet i různé informační tabule či portály, které mohou jednoduše nahradit školní web, který už poté může sloužit pouze k prezentaci školy nových uchazečům či veřejnosti. Všechny interní záležitost pro studenty, či zaměstnance lze bez jakýchkoliv problémů spravovat v rámci systému, kam veřejnost přístup nemá.
38
5 Systém uuOS na Vysoké škole Unicorn College
Vysoká škola Unicorn College (dále UCL) využívá ke správě studijní agendy své vlastní Business territory UCL-BT. Systém je na škole již několik let úspěšně provozován, avšak na jeho vývoji a optimalizaci vybraných procesů se stále pracuje.
V této kapitole si představíme dvě zásadní aplikace, které byly do systému v akademickém roce 2013/2014 naimplementovány.
5.1 Vysoká škola Unicorn College
Vysoká škola Unicorn College, člen skupiny Unicorn, je renomovaná vysoká škola se sídlem v Praze, která čerpá z více jak 20leté praxe společnosti Unicorn. Škola nabízí tři bakalářské studijní obory, jimiž jsou Management ICT projektů, Informační technologie a Ekonomika a management. Zájem o tyto obory je v dnešní době značný a jinak tomu není ani na UCL, kde každým rokem roste počet přihlášek do prvních ročníků. Optimalizace některých procesů se tak zdá být nevyhnutelná, pokud si škola chce zachovat konkurenční výhodu a ustát nápor přibývajících studentů.
5.2 UCL Uznání předmětu
V rámci aplikace Uznání předmětu je řešena problematika uznávání předmětu, který student úspěšně absolvoval na jiné vysoké škole, případně v rámci dřívějších studií na UCL. Celý proces je touto aplikací značně automatizován, čímž by se mělo dosáhnout velké časové úspory zaměstnanců UCL, kteří se o proces uznání starali před implementací aplikace. Žádostí o uznání byly v posledních letech stovky, automatizace se tedy stala nevyhnutelnou a způsob, jak byla provedena, bude nyní popsán v několika následujících kapitolách.
5.2.1 Produktový a procesní pohled
V aplikaci UCL Uznání předmětu jsou zahrnuty tři důležité artefakty, přičemž předmětným artefaktem je Žádost o uznání předmětu, viz Obrázek 6. Tento dokument nese veškeré důležité informace, které jsou potřeba k vyřízení žádosti. Student může tento artefakt vytvořit stisknutím tlačítka na Kartě studenta v předmětu, o jehož uznání se snaží.
39 Obrázek 6: Stavy artefaktu Žádost o uznání předmětu Zdroj: UNICORN. Interní dokumenty, 2013
Karta studenta v předmětu vychází z Karty studenta, kde jsou udržovány základní osobní a kontaktní informace o studentovi. Karta studenta v předmětu pak reprezentuje vztah studenta k danému předmětu, jsou zde udržovány informace o povinnostech daného jedince v předmětu či o prospěchu. Posledním artefaktem, kde se žádost projeví, je Elektronický index, na který se v případě schválení žádosti vedoucím katedry uznání předmětu zapíše. V indexu jsou zaznamenány všechny zapsané předměty, jejich kreditové ohodnocení a případný záznam o absolvování předmětu. Produktový pohled shrnuje Obrázek 7.
40
Obrázek 7: Produktový pohled aplikace UCL Uznání předmětu Zdroj: UNICORN. Interní dokumenty, 2013
Je důležité si ještě sumarizovat role, které se tohoto procesu účastní. V systému jsou do procesu zahrnuty 3 business role – student, Koordinátor běhů předmětů a vedoucí katedry.
Student je role, která celý proces iniciuje podáním žádosti o uznání. Dále jsou na studenta delegovány aktivity, které jej informují o průběhu uznání či dávají pokyn k doplnění žádosti. Druhým zúčastněným je Koordinátor běhů předmětů, který je za celý proces kompetentní a má za úkol na jeho průběh dohlížet. Koordinátor působí jako zadavatel všech aktivit spojených s celým procesem. Poslední rolí, jež se podílí na uznání, je role vedoucího katedry, která má za úkol rozhodnout o případném schválení/zamítnutí.
Z hlediska procesní dekompozice se dá celá aplikace rozdělit do několika procesů, které pak byly individuálně řešeny v rámci implementace. Hlavními procesy jsou:
Podání žádosti o uznání předmětu
Přijetí žádosti o uznání předmětu
Rozhodnutí o uznání předmětu
Kromě těchto tří stěžejních dílčích procesů jsou v aplikaci řešeny ještě dva vedlejší – Podání žádosti o uznání v zastoupení, to je využíváno pouze ve výjimečných případech, kdy žádost podá studentovým jménem Koordinátor běhů předmětů, a Doplnění žádosti.
41 5.2.2 Podání žádosti o uznání předmětu
Studenti si mohou zažádat o uznání předmětu pomocí tlačítka na Kartě studenta v předmětu. Po vyplnění potřebných údajů, kterými jsou předmět, rok absolvování, škola, kopie indexu a sylabus předmětu, může student odesláním formuláře zažádat o uznání.
Odesláním žádosti se vygenerují automaticky dvě aktivity:
Přijmi žádost o uznání – úkol na Koordinátora běhů předmětů, aby zkontroloval všechny potřebné náležitosti. Nastavením konkrétního stavu na aktivitě posune žádost dál v jejím životním cyklu.
Žádost se zpracovává – informační aktivita na studenta o průběhu stavu žádosti.
Kromě generování aktivit je artefakt s žádostí uložen na odpovídající místo v organizační struktuře a je odkázán do popisu Karty studenta v předmětu.
5.2.3 Přijetí žádosti o uznání předmětu
Podáním žádosti o uznání předmětu se avizuje aktivita „Přijmi žádost o uznání“ na Koordinátora běhů předmětů, který má na výběr ze tří možných scénářů, viz Obrázek 8.
Koordinátor zkontroluje všechny potřebné náležitosti žádosti, především kopii sylabu předmětu a indexu, a nastavením aktivity do jednoho ze stavů posune proces dál v jeho životním cyklu. Koordinátor může žádost přijmout, vrátit ji studentovi k doplnění nebo ji zamítnout. Výběr konkrétní možnosti povede opět k automatickému vygenerování další aktivity:
Uznat předmět – aktivita k rozhodnutí pro vedoucího katedry, pod kterou uznávaný předmět spadá.
Doplň žádost o uznání – aktivita pro studenta, aby žádost aktualizoval a doplnil nedostatky. Po splnění tohoto úkolu se proces Přijetí žádosti opět opakuje.
Žádost byla zrušena – informační aktivita pro studenta, informující jej o zamítnutí žádosti.
42 Obrázek 8: Přijetí žádosti o uznání předmětu Zdroj: UNICORN. Interní dokumenty, 2013
Jestliže Koordinátor žádost vrátí studentovi k doplnění, student je nucen doplnit konkrétní nedostatky a celý proces se opakuje. V případě, že tak student neučiní, bude žádost Koordinátorem zamítnuta a celý proces ukončen.
5.2.4 Rozhodnutí o uznání předmětu a jeho zpracování
Rozhodnutí o uznání předmětu, viz Obrázek 9, se po přijetí Koordinátorem deleguje dále na vedoucího katedry, pod kterou je uznávaný předmět vyučován. Přijetí či zamítnutí žádosti je v systému opět zprostředkováno nastavením aktivity do příslušného stavu.
Tentokrát je řešitelem právě vedoucí katedry, jež má v tomto procesu finální slovo. Na aktivitě „Uznat předmět“ má na výběr ze tří možností a poté, co si žádost prostuduje, může zvolit její schválení, zamítnutí či vrácení studentovi k doplnění nedostatků.
43 Obrázek 9: Rozhodnutí o uznání předmětu
Zdroj: UNICORN. Interní dokumenty, 2013
V případě schválení se nastaví artefakt žádosti do stavu Schválena a započne zpracování uznání předmětu. Systém automaticky nastaví Kartu studenta v předmětu do stavu Uznáno a doplní známku. Student již nadále nebude součástí studijní skupiny v daném předmětu a jeho absolvování se mu zapíše do elektronického indexu, kde je vytvořen záznam s datem schválení žádosti a odkázán vedoucí katedry, jež jí schválil. Nakonec je Žádost o uznání předmětu nastavena do finálního stavu Předmět uznán a její životní cyklus je ukončen.
5.2.5 Zhodnocení aplikace
Aplikace, ačkoliv její vývoj trval relativně krátkou dobu, přinesla významnou přidanou hodnotu a časovou úsporu do procesu uznání předmětu. Před implementací proces nebyl nijak automatizován a veškeré zpracování či případné doplnění stálo na ruční práci.
Na každé schválené žádosti je po implementaci ušetřeno zhruba 20 minut práce, kterou by vyžadovala komunikace studenta spolu s jednotlivými zaměstnanci UCL a výsledné zpracování uznání do všech artefaktů. Při počtu 100 žádostí o uznání za rok je tedy ušetřeno ročně přes 33 hodin administrativní práce zaměstnanců UCL. Žádostí však může být v některých letech podáno i mnohonásobně více.
44
5.3 UCL Přihlašování na zkoušky / mimořádné testy
Implementací této aplikace se klade za cíl optimalizace procesů správy zkouškových termínů, přihlašování3 na zkouškové termíny a následné zapsání známky do elektronických indexů. Tyto procesy jsou pravidelnou součástí chodu vysoké školy, které se opakují ve velkém množství na konci každého semestru. Aplikace je tedy používána v pravidelných intervalech, kdy je její využití, po dobu zhruba dvou měsíců, velmi intenzivní. Díky tomu se při tvorbě musí vzít v potaz, že nápor studentů může být v některých chvílích značný a celou aplikaci na to pokud možno připravit.
Před implementací této aplikace byla automatizována pouze část dílčích procesů spojených s přihlašováním na zkoušky a několik funkcí nebylo vůbec možných. Nejedná se tedy o novou etapu vývoje již stávajícího stavu, nýbrž o zcela novou aplikaci sloužící ke správě zkouškových termínů na Unicorn College.
5.3.1 Produktový a procesní pohled
Aplikace Přihlašování na zkoušky je značně rozsáhlá a v rámci UCL zasahuje do mnoha metodických artefaktů, několik jich v rámci implementace muselo být vytvořeno úplně nových. Pro přehlednost bude tedy lepší, když si jednotlivé typy artefaktů přehledně představíme, viz Obrázek 10:
Zkouškový termín – vzhled artefaktu byl při implementaci upraven a přibyla zde tlačítka na spuštění nových funkcí. Artefakt uchovává všechny potřebné informace ohledně termínu, jako jsou místo, čas, kapacita nebo seznam přihlášených studentů.
Účast na zkoušce – je artefakt, který reprezentuje účast vždy jednoho studenta na jednom konkrétním termínu. Při přihlášení na termín se vždy založí tento artefakt a následné počínání na zkoušce se projevuje v jeho životním cyklu. Pouze jedna Účast na zkoušce může být pro studenta aktivní v jednom předmětu. Je zde umístěno spouštěcí tlačítko pro odhlášení se z termínu.
Řídicí panel běhu předmětu – slouží jako rozcestník k jednotlivým funkcím nad vyučovaným předmětem. Implementací aplikace zde přibyl přehled všech vypsaných zkouškových termínu z daného předmětu a jsou zde umístěna tlačítka ke
3 Na Unicorn College neprobíhá při procesu přihlášení na zkoušku kontrola splnění zápočtu. Zápočty jsou zde nahrazeny průběžným hodnocením, které se následně sečte se závěrečným hodnocením (výsledkem zkoušky). Ze součtu následně vyplyne výsledná známka z předmětu. Minimální hranice pro splnění předmětu je dosažení 60 % z průběžného i závěrečného hodnocení.
45
spuštění všech funkcí ohledně termínu. Je zde také možné přihlásit nebo odhlásit studenta z termínu v zastoupení.
Karta studenta v předmětu – slouží jako rozcestník a přehled studentova počínání v předmětu. Implementací byl kompletně upraven vzhled celého artefaktu a přibyl zde přehled všech Účastí na zkoušce k danému předmětu. Jedná se o druhý artefakt, ze kterého má student možnost přihlásit se na zkouškový termín.
Karta pedagoga v předmětu – slouží jako rozcestník a přehled pro pedagoga v daném předmětu. Implementací přibyl přehled všech zkouškových termínů, na kterých pedagog působí jako zkoušející.
Elektronický index – elektronická obdoba klasického indexu, ve kterém jsou evidovány zapsané předměty studenta a kam se zapisují výsledky z jednotlivých zkoušek.
Plán zkoušek – je jediný artefakt v rámci celého SIS na Unicorn College, kde jsou evidovány všechny vypsané zkouškové termíny ze všech vyučovaných předmětů.
Slouží jako kalendář zkouškových termínů.
Obrázek 10: Produktový pohled aplikace UCL Přihlašování na zkoušky Zdroj: UNICORN. Interní dokumenty, 2013
46
Do procesu se aktivně zapojují tři typy rolí, jimiž jsou Koordinátor běhů předmětů, pedagog a student. Koordinátor spouští veškeré funkčnosti z Řídicího panelu běhu předmětu a má na starosti správu jednotlivých zkouškových termínů. V jeho kompetenci je termíny vypisovat, aktualizovat a případně rušit. Pedagog zde působí jako zkoušející na vypsaných termínech, a tudíž jsou na něj delegovány aktivity ohledně zkoušení. Na zkouškovém termínu je vždy jeden zkoušející hlavní, jedná se o pedagoga, který se bude zapisovat do elektronických indexů k výsledné známce. Nakonec zde figuruje student, který se na jednotlivé zkouškové termíny může přihlásit, případně z nich odhlásit. Na studenta jsou delegované aktivity spojené s jeho účastí na zkoušce.
Celou aplikaci pro přehlednost dekomponujeme na 2 základní procesy, které si pak postupně přiblížíme.
Správa zkouškového termínu
Přihlášení a odhlášení ze zkouškového termínu
5.3.2 Správa zkouškového termínu
Správa zkouškového termínu je složitý proces, který se skládá z mnoha dílčích procesů.
Termín je nejprve potřeba vypsat, poté otevřít. Po otevření je umožněno studentům se na zkouškový termín začít hlásit. Následně v předem definovaný datum se termín uzavře pro přihlašování, a poté i pro odhlašování všem studentům. Na konci životního cyklu se zpracují výsledky a termín se uzavře. Toto byl stručně popsaný životní cyklus s výjimkou všech alternativních scénářů, kterých je hned několik: aktualizace termínu, zrušení termínu, přidání zkoušejícího na termín či odebrání zkoušejícího.
Obrázek 11: Stavy artefaktu Zkouškový termín Zdroj: UNICORN. Interní dokumenty, 2013
47 5.3.3 Vypsání zkouškového termínu
Zkouškový termín lze vypsat pomocí tlačítka na Řídicím panelu běhu předmětu, po jehož stisknutí se uživateli objeví formulář, ve kterém specifikuje všechny důležité informace potřebné k vypsání termínu. Po vyplnění povinných údajů a odeslání formuláře proběhne na pozadí zpracování vypsání termínu. náležitosti a případně zkouškový termín otevřel studentům.
Zkoušení – rezervace času od Koordinátora na zkoušejícího pedagoga. V popisu aktivity bude zapsáno místo konání zkoušky. Čas samozřejmě odpovídá době konání.
5.3.4 Otevření zkouškového termínu
Koordinátor poté, co nalezne úkol Otevři termín, zkontroluje všechny náležitosti na právě vytvořeném artefaktu Zkouškový termín. Na aktivitě má následně na výběr ze dvou stavů, nastavením stavu Otevírám spustí proces otevření termínu pro studenty a nastavením stavu Ruším může zkouškový termín zrušit.
Otevřením termínu se nastaví artefakt Zkouškový termín do stavu Otevřen a je odkázán na artefaktu Plán zkoušek, kde jsou všechny aktuálně vypsané termíny až do doby, než jsou jim zpracovány výsledky. Termín je také odkázán na portál Novinek UCL, kde se zobrazuje vždy několik posledních vypsaných termínů. Otevřením termínu jsou opět naplánovány aktivity:
Zpracování výsledků – úkol na Koordinátora naplánovaný na +1 den po termínu konání zkoušky, aby zpracoval výsledky studentů.
48
Uzavření přihlašování – je aktivita, která slouží k automatickému nastavení stavu Ukončeno přihlašování. Aktivita je naplánována na den ukončení přihlašování,
5.3.5 Uzavření přihlašování a odhlašování
Na základě aktivit naplánovaných při otevření termínu je v předem specifikovaný čas termín nastaven do stavu Ukončeno přihlašování či Ukončeno odhlašování. Po nastavení těchto stavů již není možné se na termín přihlásit, případně se z něj odhlásit. Tyto operace lze po nastavení stavů provést pouze ve výjimečných případech přihlášením/odhlášením v zastoupení.
5.3.6 Zpracování výsledků
Zpracuj výsledky, viz Obrázek 12, je aktivita naplánovaná na Koordinátora, která se avizuje přesně den po termínu konání zkoušky. Koordinátor poté zapíše výsledky studentů do formulářových polí na Zkouškovém termínu, čímž se výsledky automaticky zapíší také do jednotlivých artefaktů s účastmi studentů. V případě, že se student ze zkouškového termínu omluvil, může být namísto známky zapsáno „omluven“ a při zpracování se student z termínu automaticky odhlásí.
Koordinátor má na aktivitě Zpracuj výsledky na výběr ze dvou stavů. Nastavením stavu aktivity Zpracováno proběhne automaticky proces zpracování zapsaných výsledků ze zkoušky. Na druhé straně může zvolit stav Zrušeno a Zkouškový termín se nastaví do stavu Zrušen, tím se dostane na konec svého životního cyklu a spustí se proces zrušení zkouškového termínu.
49 Obrázek 12: Proces zpracování výsledků
Zdroj: UNICORN. Interní dokumenty, 2013
V případě, že se Koordinátor rozhodne výsledky zpracovat, dojde k nastavení stavu Uzavřen na artefaktu Zkouškový termín. U každého přihlášeného studenta se nastaví artefakt Účast na zkoušce do stavu odpovídající známce (viz Obrázek 13), případně může být také nastaven do stavu Odhlášen, jestliže byl student z termínu omluven. Dále je aktualizován artefakt Karta studenta v předmětu pro všechny přihlášené, kde se zapíše výsledek ze zkoušky (závěrečné hodnocení), celkové hodnocení z předmětu a z něho vyplývající výsledná známka. Nakonec je zkouška zapsána do elektronických indexů, kde je vytvořen záznam u daného předmětu s termínem konání zkoušky, výslednou známkou a hlavním zkoušejícím.
50 Obrázek 13: Stavy artefaktu Účast na zkoušce Zdroj: UNICORN. Interní dokumenty, 2013
5.3.7 Zrušení zkouškového termínu
Ke zrušení zkouškového termínu může dojít přímo pomocí tlačítka na Řídicím panelu běhu předmětu či nastavením konkrétního stavu aktivity na aktivitách Otevři termín a Zpracuj výsledky. Proběhnutím procesu na zrušení termínu je odstraněn odkaz na daný termín
Ke zrušení zkouškového termínu může dojít přímo pomocí tlačítka na Řídicím panelu běhu předmětu či nastavením konkrétního stavu aktivity na aktivitách Otevři termín a Zpracuj výsledky. Proběhnutím procesu na zrušení termínu je odstraněn odkaz na daný termín