Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb
Specifikace požadavků na informační systém administrace závěrečných prací na VOŠIS Bakalářská práce
Autor: Jana Svitalská Vedoucí práce: PhDr. Helena Kučerová Rok vypracování: 2011
Čestné prohlášení: Prohlašuji, že jsem bakalářskou práci na téma „Specifikace požadavků na informační systém administrace závěrečných prací na VOŠIS“ vypracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury.
V Praze dne ……………...
Podpis: ................................................. 1
Poděkování: Na tomto místě bych ráda poděkovala PhDr. Heleně Kučerové za cenné rady, připomínky a metodické vedení práce. Dále děkuji jí, Ing. Antonínovi Skopcovi, Ing. Davidovi Klimánkovi Ph.D., Ing. Stanislavě Hruškové Ph.D. a knihovnici Anežce Nedomové za poskytnutí rozhovorů, které byly cenným přínosem při vypracovávání této práce. 2
Identifikační záznam: SVITALSKÁ, Jana. Specifikace požadavků na informační systém administrace závěrečných prací na VOŠIS = Requirements specification for VOŠIS theses information system. Praha, 20. 08. 2011, 62 s.: 11 obr. Bakalářská práce (Bc.). Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Vyšší odborná škola informačních služeb. Vedoucí bakalářské práce PhDr. Helena Kučerová. Abstrakt: Bakalářská práce popisuje a zdůvodňuje postup inženýrství požadavků na příkladu informačního systému administrace závěrečných prací na VOŠIS. V teoretické části vymezuje problematiku získávání, analýzy, specifikace a ověřování požadavků a popisuje vztah vývoje a správy požadavků. Dále objasňuje základní pojmy související s problematikou závěrečných prací a zmiňuje základní činnosti, které s nimi souvisejí. V praktické části je vysvětlena použitá metodika sběru a analýzy požadavků, výstupem této části je pak dokument specifikace požadavků. Klíčová slova: závěrečná práce, inženýrství požadavků, získávání požadavků, analýza požadavků, informační systém Abstract: Bachelor thesis describes and justifies the requirements engineering process used for the specification of the VOŠIS theses information system. In the theoretical section are defined terms such as requirements elicitation, analysis, specification and verification and is described the relationship between requirements development and management. Further are clarifying the basic concepts relating to thesis issues, including definitions and activities associated with them. In the field section is explained the methodology used for data collection and requirements analysis, the output of this section is the requirements specification. Keywords: thesis,
requirements
engineering,
requirements
requirements specification, information system 3
elicitation,
requirements
analysis,
Obsah 1
ÚVOD ..................................................................................................................... 7
1.1
Motivace pro výběr tématu ............................................................................................ 7
1.2
Cíle a hypotézy ............................................................................................................... 7
2
INŽENÝRSTVÍ POŽADAVKŮ ........................................................................... 9
2.1
Požadavek ...................................................................................................................... 9
2.1.1
Definice požadavku ..................................................................................................... 9
2.1.2
Zainteresované osoby ............................................................................................... 10
2.1.3
Vlastnosti požadavků ................................................................................................ 10
2.1.4
Typy požadavků ........................................................................................................ 10
2.2
Vývoj a správa požadavků .............................................................................................12
2.3
Získávání požadavků .....................................................................................................13
2.3.1
Proces získávání požadavků ...................................................................................... 13
2.3.2
Metody získávání požadavků .................................................................................... 14
2.4
Analýza požadavků ........................................................................................................16
2.5
Specifikace požadavků ..................................................................................................16
2.6
Potvrzení a ověření požadavků ......................................................................................18
3
PROBLEMATIKA ZÁVĚREČNÝCH PRACÍ ................................................. 20
3.1
Závěrečná práce ............................................................................................................20
3.1.1
Absolventské práce ................................................................................................... 21
3.1.2
Vysokoškolské závěrečné práce ................................................................................ 21
3.2
Klíčové role....................................................................................................................23
3.2.1
Student ..................................................................................................................... 23
3.2.2
Vedoucí závěrečné práce .......................................................................................... 23
3.2.3
Oponent závěrečné práce ......................................................................................... 23
3.2.4
Zkušební komise ....................................................................................................... 24
4
3.3
Proces závěrečných prací...............................................................................................24
3.3.1
Zadání ....................................................................................................................... 24
3.3.2
Vypracování a odevzdání .......................................................................................... 25
3.3.3
Obhajoba .................................................................................................................. 25
4
POUŽITÁ METODIKA .................................................................................... 26
4.1
Použité metody získávání požadavků ............................................................................26
4.1.1
Studium dokumentace .............................................................................................. 27
4.1.2
Rozhovory se zainteresovanými osobami ................................................................. 30
4.2
Popis analýzy požadavků ...............................................................................................31
4.2.1
Případy užití vyplývající z analýzy stávajících systémů .............................................. 31
4.2.2
Definice dat vyplývající z analýzy dokumentů .......................................................... 36
4.2.3
Analýza současného systému ................................................................................... 37
5
SPECIFIKACE POŽADAVKŮ ......................................................................... 40
5.1
Úvod..............................................................................................................................40
5.1.1
Předmět specifikace .................................................................................................. 40
5.1.2
Typografické konvence ............................................................................................. 40
5.1.3
Odkazy ...................................................................................................................... 41
5.2
Obecný popis.................................................................................................................41
5.2.1
Kontext systému ....................................................................................................... 41
5.2.2
Funkce systému ........................................................................................................ 42
5.2.3
Třídy uživatelů ........................................................................................................... 43
5.2.4
Provozní prostředí, omezení návrhu a implementace .............................................. 44
5.3
Funkční požadavky ........................................................................................................45
5.3.1
PU-1 Prohlížení témat .............................................................................................. 46
5.3.1
PU-2 Uložení projektu .............................................................................................. 47
5.3.2
PU-3 Formulace zadání ............................................................................................ 47
5.3.3
PU-4 Vložení práce ................................................................................................... 48
5.3.4
PU-5 Prohlížení posudku .......................................................................................... 48
5.3.5
PU-6 Správa témat ................................................................................................... 49
5.3.6
PU-7 Vložení jména oponenta ................................................................................. 49
5.3.7
PU-8 Tisk zadání ....................................................................................................... 50
5.3.8
PU-9 Vložení posudku .............................................................................................. 50
5
5.3.9
PU-10 Stažení souborů práce ................................................................................... 51
5.3.10
PU-11 Prohlížení projektů ........................................................................................ 51
5.3.11
PU-12 Schvalování tématu ....................................................................................... 52
5.3.12
PU-13 Schvalování oponenta ................................................................................... 52
5.3.13
PU-14 Zápis obhajoby .............................................................................................. 53
5.3.14
PU-15 Nastavování termínů ..................................................................................... 53
5.3.15
PU-16 Uložení seznamu prací .................................................................................. 54
5.3.1
PU-17 Sledování stavu ............................................................................................. 54
Dodatek: Stavový diagram ......................................................................................................55
6
ZÁVĚR ................................................................................................................ 56
7
SEZNAM POUŽITÉ LITERATURY ............................................................... 57
8
SEZNAM OBRÁZKŮ ........................................................................................ 62
9
SEZNAM ZKRATEK ......................................................................................... 62
6
1 Úvod 1.1 Motivace pro výběr tématu Vyšší odborná škola informačních služeb v Praze (dále jen „VOŠIS“) nabízí studentům jednak nebakalářské vzdělávací programy a jednak realizuje i bakalářské studijní programy ve spolupráci s vysokými školami. V rámci první skupiny programů VOŠIS nabízí studium oborů Podniková informatika, Služby knihoven a Služby muzeí a galerií (dále jen souhrnně „nebakalářské obory“). Ve spolupráci s Vysokou školou ekonomickou v Praze (dále jen „VŠE“) realizuje studium bakalářského oboru Podnikové informační systémy (dále jen „PIS“) a ve spolupráci s Univerzitou Karlovou v Praze (dále jen „UK“) studium taktéž bakalářského oboru Informační studia a knihovnictví (dále jen „INSK“) [VOŠIS, 2011]. VOŠIS používá svůj současný interní informační systém (dále jen „intranet VOŠIS“) pro účely zápisu rozvrhů, přihlašování na zkoušky a pro účely ukládání a zobrazování výsledků těchto zkoušek. V souvislosti s administrací závěrečných prací však žádný komplexní informační systém nepoužívá. Objevila se tak potřeba zavedení takového informačního systému a to formou „na míru“ vytvořeného systému. V rámci předmětu „Projekt“ na oboru PIS tak byli jeho účastníci požádáni PhDr. Helenou Kučerovou vypracováním projektu, který by se zabýval procesní analýzou, specifikací požadavků a návrhem vybraných funkcionalit pro webovou aplikaci řešící administraci závěrečných prací na VOŠIS. Výběr tématu této bakalářské práce byl ovlivněn zadaným tématem na předmětu „Projekt“ a dále zájmem o problematiku požadavků na informační systém. V rámci studia oboru INSK jsem vypracovala a úspěšně obhájila bakalářskou práci zabývající se metodami získávání požadavků [Svitalská, 2010]. V této bakalářské práci bych proto chtěla aplikovat získané poznatky z oblasti inženýrství požadavků na konkrétní projekt.
1.2 Cíle a hypotézy Cílem práce je zpracovat dokument specifikace požadavků na informační systém administrace závěrečných prací na VOŠIS (dále jen „ISAZP“) 1. Tento dokument by
1
Týkající se závěrečných prací všech studijních programů, které VOŠIS realizuje samostatně či ve spolupráci s VŠE a UK.
měl shrnovat požadavky zainteresovaných osob ve formalizované podobě. Dalším cílem práce je zdokumentovat použité postupy a zdůvodnit volbu metodiky. Předpokládá se, že se podaří tyto cíle naplnit za použití metod pro získávání požadavků, analýzy takto získaných informací a prostřednictvím aplikování „best practices“ disciplíny inženýrství požadavků. S velkou pravděpodobností bude potřeba využít metod analýzy dokumentů, zejména normativních, neboť proces závěrečných prací je z velké části stanoven zákony Ministerstva školství, mládeže a tělovýchovy a dále upravován příslušnými interními předpisy vzdělávací instituce. Dále bude potřeba ověřit tyto informace během rozhovorů s vybranými klíčovými osobami a doplnit je případně využitím dalších metod pro sběr a analýzu požadavků. Pravděpodobně bude nutné uskutečnit i skupinové sezení, na kterém se sejdou zástupci jednotlivých budoucích uživatelů ISAZP, budou komunikovat své požadavky a na kterém dojde k dohodě nad těmito požadavky. Není vyloučeno ani využití metody dotazování studentů formou elektronického dotazníku. Pokud se vyskytnou některé velmi nejasné požadavky, bude muset být vytvořen prototyp ISAZP či analytické modely, aby tyto neurčitosti odhalily. Analýza požadavků se neobejde bez modelování a vyjádření procesů, stavů, činností, operací, struktury dat a funkcí prostřednictvím grafické reprezentace (UML diagramy apod.). Dokument specifikace požadavků na ISAZP pak bude dodržovat strukturu některé z osvědčených šablon a bude obsahovat zejména funkční požadavky. Měl by pak být východiskem pro vývojáře či studenty předmětu „Projekt“ v dalších fázích vývoje aplikace pro účely správy závěrečných prací. Tato počáteční verze požadavků by měla být aktualizována v průběhu změn požadavků v čase.
8
2 Inženýrství požadavků V následující kapitole je vymezena za použití odborné literatury problematika související s vývojem a správou požadavků na informační systém (dále jen „IS“), čímž se zabývá disciplína zvaná anglicky „requirements engineering“, zde přeložena jako „inženýrství požadavků“. Potřeba takové disciplíny vyplývá z mnoha studií, které odhalují, že počáteční etapa vývoje IS je pro jeho úspěch kritická [Standish Group, 1994; Davey a Cope, 2008]. Nesprávně specifikované požadavky jsou totiž nejčastějším důvodem toho, že projekt není dokončen včas a v rámci rozpočtu. Zadavatel a uživatelé nejsou spokojení se systémem a nemohou v něm vykonávat potřebné úkoly tak, jak by chtěli. Proto by se fázi stanovování požadavků měl věnovat dostatek času a finančních prostředků [Wiegers, 2001]. Inženýrství požadavků pak pokrývá všechny aktivity zahrnující objevování, dokumentování a správu požadavků a poskytuje systematický přístup pro vykonávání těchto aktivit [Kotonya a Sommerville, 1998]. Zabývá se tím, co je potřeba navrhnout, aby bylo dosaženo budoucího žádoucího stavu [Macaulay, 1996]. V textu dále je objasněno, co se skrývá pod pojmem požadavek a jaké jsou jeho vlastnosti a typy. Dále se kapitola zabývá vztahem mezi vývojem a správou požadavků a popisuje pak podrobněji jednotlivé fáze vývoje požadavků.
2.1 Požadavek 2.1.1 Definice požadavku Vývoj IS je většinou iniciován potřebou člověka či skupiny osob vyřešit nějaký nedostatek týkající se ukládání, zpracování nebo správy informací. Tato potřeba je potom vyjádřena jako konkrétní požadavek, který je obvykle formulován v přirozeném jazyce v podobě ústní nebo písemné [TDKIV, 2003]. Požadavky tedy vyjadřují, co by mělo být implementováno, aby tyto potřeby byly uspokojeny. Představují takové vlastnosti, funkce, služby, úlohy a omezení systému, které mají hodnotu pro některého z účastníků, např. pro uživatele systému [Wiegers, 2008]. Přesnou definici požadavku vymezuje Institut pro elektrotechnické a elektronické inženýrství [IEEE Std 610.121:1990], který pod požadavkem rozumí:
a) podmínku nebo funkci, kterou uživatel potřebuje pro řešení problému nebo dosažení cíle, b) podmínku nebo funkci, kterou musí systém nebo jeho část splňovat, aby vyhověl smlouvě, standardu, specifikaci nebo jinému dokumentu, jenž se na něj formálně vztahuje, c) jejich dokumentovaná podoba. 2.1.2 Zainteresované osoby Požadavky jsou odvozovány pečlivou analýzou potřeb tzv. „zainteresovaných osob“ (anglicky „stakeholders“), kterými jsou lidé nebo organizace, které jsou ovlivněné systémem a které mají přímý nebo nepřímý vliv na systémové požadavky. Neměly by být opomenuty ani takové osoby, které novým systémem spíše ztrácejí [Nuseibeh a Easterbrook, 2000]. Zainteresované osoby zahrnují koncové uživatele systému, zadavatele systému, manažery, vývojáře zodpovědné za vývoj a údržbu systému, zákazníky organizace, kterým bude systém poskytovat nějakou službu, a externí organizace, jako jsou regulační a kontrolní úřady nebo certifikační autority [Kotonya a Sommerville, 1998]. Jejich cíle mohou být různé a protichůdné, jejich přání a potřeby výslovně řečené, ale také těžko definovatelné [Nuseibeh a Easterbrook, 2000]. 2.1.3 Vlastnosti požadavků Podle IEEE [IEEE Std 830-1998] by měl požadavek být jednoznačný, úplný, ověřitelný, dohledatelný, schopný změny, dále by měl být v souladu s ostatními požadavky a použitelný během fáze provozu a údržby systému. Dalším důležitým znakem požadavku by měla být jeho srozumitelnost a to i pro takové zainteresované osoby, které nemají technické znalosti [Zhou, 2004]. Jednoznačnosti požadavku se dá docílit poměrně obtížně, protože přirozený jazyk je náchylný k víceznačnostem. Wiegers [2008] proto doporučuje psát požadavky co nejstručnějším a nejjednodušším způsobem. Dále navrhuje zavést slovníček pojmů a používat nástrojů pro správu požadavků, které umožňují dohledat požadavek v příslušné verzi a propojit jej odkazy na požadavky jiné. 2.1.4 Typy požadavků Požadavky mohou být různého typu. Maiden [2008] například rozlišuje požadavky uživatelské a systémové. Uživatelský požadavek pochází od uživatele nebo 10
jiné zainteresované osoby a vyjadřuje vlastnost nebo funkci, kterou přinese nový systém. Systémový požadavek oproti tomu popisuje žádoucí vlastnost systému, která po implementaci
povede
k naplnění
nejméně
jednoho
uživatelského
požadavku.
Zdůrazňuje tím potřebu propojovat každý uživatelský požadavek se systémovým, aby bylo zajištěno, že nebude implementováno do systému něco, co vůbec uživatelem není požadováno. Nejčastěji se však rozlišují požadavky funkční a mimofunkční. Funkční požadavky určují, co by měl systém dělat jako odpověď na určitý podnět. Jsou snadno ověřitelné. Oproti tomu mimofunkční požadavky jsou těžko definovatelné, neboť se týkají kvalitativních vlastností systému, mezi které patří např. výkonnost, spolehlivost, bezpečnost, rychlost a přenositelnost, a dále systémových omezení, která ovlivňují vývoj a návrh systému, do kterých může patřit např. omezení hardwarovým vybavením nebo externím rozhraním či používání určitého programovacího jazyka [Kendall a Kendall, 2002]. Wiegers [2008] pak ještě podrobněji rozlišuje různé typy v rámci těchto dvou hlavních skupin požadavků. Toto rozdělení požadavků reprezentuje Obr. 1 a je dále komentováno v textu níže. Do funkčních požadavků Wiegers [2008] zařazuje podnikatelské požadavky, které odrážejí hlavní cíle organizace nebo zákazníka. Definuje je hlavní investor, vedoucí uživatelů nebo jiná pověřená osoba. Podnikatelské požadavky určují rozsah navrhovaného systému a jsou jim podřízené ostatní požadavky. Patří mezi ně předpisy organizace, státní nařízení, průmyslové standardy, systém účetnictví nebo výpočetní algoritmy. Z podnikatelských pravidel mohou kromě funkčních požadavků plynout i mimofunkční požadavky (nejčastěji v podobě požadavků na bezpečnost a ochranu informací). Uživatelské požadavky potom popisují cíle a úkoly uživatelů systému a jsou reprezentovány často jako případy užití (anglicky „use cases“), které popisují, co systém dělá a jak interaguje s uživatelem [Lauesen, 2003]. Funkční požadavky pak představují požadavky na chování výsledného systému a určují, co přesně má být vývojáři naprogramováno. Spolu s mimofunkčními požadavky jsou pak formálně sepsány v dokumentu s názvem „Specifikace požadavků na IS“. Tento dokument je pak použit ke komunikaci požadavků zadavateli, uživateli systému,
11
systémovým inženýrům a vývojářům. Zároveň slouží i jako kontrakt mezi klientem a vývojářem [Kotonya a Sommerville, 1998].
Obr. 1 Rozdělení požadavků, upraveno podle [Wiegers, 2008]
2.2 Vývoj a správa požadavků Wiegers [2008] dělí práci s požadavky IS na dvě základní větve:
vývoj požadavků, během něhož se požadavky získávají, analyzují, specifikují a kontrolují, a
správu požadavků, při které se řeší změny v požadavcích a sleduje se každý jednotlivý požadavek až k jeho implementaci. Výstupem procesu vývoje požadavků je formální dokument obsahující
specifikaci požadavků, které mají být implementovány (viz výše). Tento dokument pak slouží jako tzv. směrná verze specifikace, která zahrnuje požadavky pro danou verzi systému, který je vyvíjen. Vývoj požadavků je totiž stejně jako vývoj celého IS iterativní proces. Požadavky se neustále mění, dochází k jejich upřesňování a odhalování jejich nedostatků. Objevují se někdy i zcela nové požadavky. Příčinou jsou změny v prostředí,
12
ve kterém se IS nachází. Tyto změny mohou být spojeny s technologickým vývojem, definováním jiných cílů organizace, která IS používá, či změnami v legislativě. Správným přístupem k těmto změnám je proto jejich správa, která je spojená s verzováním požadavků, jejich přepracováním a sledováním jejich stavu. Směrná verze specifikace je proto aktualizována a vytváří se nové verze systému. Směrná verze specifikace je tak společným pojítkem obou výše uvedených procesů, jak je vidět na Obr. 2, které většinou probíhají paralelně [Kotonya a Sommerville, 1998].
Obr. 2 Vztah mezi vývojem a správou požadavků, upraveno podle [Wiegers, 2008]
2.3 Získávání požadavků Prvotní fází vývoje požadavků je získávání požadavků. Zahrnuje takové činnosti, které napomáhají shromáždit informace o potřebách týkající se vyvíjeného systému. 2.3.1 Proces získávání požadavků Etapa získávání požadavků zahrnuje několik činností, jejichž cílem je shromáždit všechny potřebné požadavky na systém prostřednictvím komunikace se zúčastněnými stranami a analýzou dalších zdrojů požadavků, kterými bývá dokumentace a podnikové procesy [Pfleeger a Atlee, 2006]. Na samotném počátku se nejdříve určuje rozsah systému, který popisuje hranici mezi vyvíjeným systémem a jeho okolím. K těmto účelům dobře slouží kontextový diagram obsahující koncové prvky a dále datové, řídící a materiální toky mezi těmito prvky a systémem [Wiegers, 2008]. Poté je potřeba stanovit podnikové cíle a pečlivě analyzovat prostředí systému, kam patří kultura organizace, aplikační doména, stávající systémy, systémová omezení, a aplikační doména [Kotonya a Sommerville, 1998]. 13
Jednou z klíčových aktivit etapy získávání požadavků je určení všech zúčastněných stran a jejich rozdělení do tříd. Třídou je míněna skupina zúčastněných osob se stejnými či podobnými požadavky. Třídy se mezi sebou navzájem liší frekvencí v užívání systému, ve znalostech aplikační domény a v tom, jaké funkce systému užívají nebo budou užívat. Po identifikaci tříd a stanovení jejich priority se určují nejvhodnější zástupci dané třídy, se kterými analytik pak uskutečňuje rozhovory a získává od nich požadavky [Wiegers, 2008]. Po vykonání předchozích činností může analytik přistoupit k samotnému sběru požadavků, do kterého by měly být zapojeny všechny zainteresované osoby nebo jejich zástupci, aby bylo minimalizováno riziko nesprávného odvození požadavků. V důsledku toho se však objeví mnoho rozporuplných požadavků, které je potřeba vyjednat mezi třídami zúčastněných osob navzájem. Mělo by být proto i jasné, které zúčastněné strany mají větší rozhodovací pravomoc [Kotonya a Sommerville, 1998]. 2.3.2 Metody získávání požadavků Při sběru požadavků používá analytik většinou metody, které mu napomáhají shromáždit relevantní informace z různých zdrojů. Nejčastějším zdrojem požadavků bývají rozhovory se zúčastněnými osobami, zejména uživateli. Analytik jim napomáhá prostřednictvím dotazování pochopit a vyjádřit jejich požadavky, které pak budou komunikovány vývojářům [Robertson a Robertson, 2006]. Z interview se dá zjistit mnohé o tom, co uživatelé či organizace očekává od nového systému. Funkční požadavky lze odvodit ze sloves a podstatných jmen, mimofunkční požadavky se však většinou v počátečních rozhovorech zjišťují těžko, protože se dotazovaný většinou soustředí na to, co chce od systému, nikoliv v jaké kvalitě [Zhou, 2004]. U větších projektů vývoje IS se využívají poměrně často i skupinové metody dotazování zúčastněných osob. Patří mezi ně tzv. požadavkové workshopy a brainstorming. Workshopy plánuje a řídí moderátor, který pak celou skupinu zúčastněných osob vede ke konsenzu ohledně požadavků. Součástí workshopů může být i brainstorming, který umožňuje odhalit nové požadavky a inovativní řešení k existujícím problémům [Zowghi a Coulin, 2005]. Další užitečné informace k požadavkům nachází analytik v dokumentaci. Studuje standardy, nařízení, zákony, organizační diagramy, firemní směrnice nebo manuály ke stávajícím či konkurenčním systémům [Wiegers, 2008].
14
V určitých
případech
je
vhodné
čerpat
informace
o požadavcích
i
z dotazníkového šetření. Výhodou této metody je možnost získat potřebné údaje od velkého množství uživatelů za poměrně krátkou dobu. Nevýhodu však lze spatřovat v náročnosti na sestavení dotazníku a v návratnosti dotazníků [Kendall a Kendall, 2002]. Jako doplňující metoda se používá pozorování uživatelů při práci. Informace z něho získané mohou sloužit k ověření informací získaných z jiných zdrojů (zejména z rozhovorů). Sledování uživatelů však napomáhá získat požadavky, které jsou obtížně vyslovitelné během interview [Goguen a Linde, 1993]. Pokud jsou požadavky hodně nejasné nebo v případě, kdy je zapotřebí rychlá zpětná vazba, přistupuje se při stanovování požadavků k prototypování. Tato metoda spočívá ve vytvoření částečného řešení systému, které uživatel komentuje a nabízí návrhy na zlepšení [Nuseibeh a Easterbrook, 2000]. Požadavky jsou tak neustále zpřesňovány a vyvíjeny do té doby, dokud je to potřeba. K objevení požadavků souvisejících s uživatelskými úkoly se používají již výše zmíněné případy užití, které vyjadřují posloupnost akcí prováděných systémem, které přináší pozorovatelný výsledek a hodnotu pro určitého aktéra [Ham, 1998]. Aktéra představuje osoba nebo jiný systém nebo hardwarové zařízení, které systém používá k dosažení nějakého užitečného cíle. U každého případu užití se uvádějí vstupní a výstupní podmínky a dále číslovaný seznam kroků sekvence interakcí mezi aktérem a systémem [Wiegers, 2008]. Další zajímavé metody pro získávání požadavků na systém představují protokolová analýza nebo třídění kartiček, které napomáhají odhalit kognitivní procesy zúčastněných osob. V případě protokolové analýzy je odborník požádán, aby nahlas popisoval svůj myšlenkový postup při provádění nějakého úkolu. U metody třídění kartiček je vyzván k seřazení kartiček do kategorií. Na kartičce je krátký název nebo obrázek představující obsah nebo funkčnost IS, do kategorií. Pak vysvětluje, které kritérium pro řazení použil a proč [Zowghi a Coulin, 2005]. Analytik tak může získat vhled do mentálních procesů zkoumané osoby a získat nové požadavky. Tyto dvě kognitivní metody se většinou používají v případě hledání požadavků na expertní systém [Celbová, 1999].
15
2.4 Analýza požadavků Poté, co jsou shromážděny potřebné informace ze všech relevantních zdrojů, se provádí jejich analýza. Tato analýza se zaměřuje na nejednoznačné, neúplné a nekonzistentní požadavky. Je kontrolována nezbytnost požadavků a jsou odhalovány chybějící požadavky a další omezení pro budoucí systém. Součástí analýzy je i ověřování uskutečnitelnosti každého požadavku, aby bylo zajištěno, že je daný požadavek reálný v kontextu rozpočtu a času, který je na vývoj systému věnován [Kotonya a Sommerville, 1998]. Požadavky jsou dále sestavovány dohromady, popisují se do větší hloubky detailu, diskutují se a řeší se konflikty mezi nimi navzájem [Hull, Jackson a Dick, 2005]. Proto je tato fáze inženýrství požadavků velmi úzce svázána s předchozí – je zapotřebí získat další informace od zúčastněných osob nebo jiných zdrojů, aby byly doplněny zjištěné nedostatky v požadavcích [Westfall, 2005]. Součástí analýzy požadavků bývá i jejich reprezentace ve formě modelů, které slouží zároveň i jako komunikační prostředek mezi analytikem a vývojářem. Využívají se datové modely (například entitně-relační datové modely nebo diagramy tříd a objektů) a dále modely vyjadřující dynamickou povahu reality (například diagramy datových toků) [Nuseibeh a Easterbrook, 2000]. Cílem analýzy je stanovit prostřednictvím vyjednávání soubor požadavků, na kterých se shodují všechny zúčastněné osoby, a které jsou úplné, konzistentní a jednoznačné [Sommerville, 2007].
2.5 Specifikace požadavků Po důkladné analýze shromážděných požadavků jsou dále dokumentovány. Nejčastěji jsou reprezentovány ve strukturovaných dokumentech a vyjádřeny v přirozeném jazyce, a to i přes veškeré nedostatky spočívající v jeho nejednoznačnosti. Pro větší srozumitelnost a přehlednost se tyto dokumenty doplňují grafickými ztvárněními požadavků v podobě modelů [Wiegers, 2000]. Snahou této fáze inženýrství požadavků je totiž vytvořit takový dokument, který bude srozumitelný pro všechny jeho uživatele. Čtenářem tohoto dokumentu bývá často projektový manažer, který na základě nastudování rozsahu požadavků odhaduje pracnost a plánuje časový rozvrh prací na dalších fázích vývoje. Dokument využívá vývojářský a testovací tým při fázi implementace IS. V neposlední řadě je určen i pro 16
zadavatele a řešitele, pro něž slouží většinou i jako předmět smluvního závazku [Wiegers, 2008]. Dokument specifikace požadavků by měl obsahovat všechny podstatné a relevantní požadavky, které by měly být hierarchicky číslovány. Chybějící informace k některým požadavkům je důležité zmínit a v textu zvýraznit, aby byly řešeny v dalších fázích vývoje a nebylo na ně zapomenuto. Dále by měla být umožněna snadná modifikace dokumentu a to formou vedení evidence změn. U požadavků by měly být uváděny jejich zdroje, které může představovat například případ užití, požadavek na vyšší úrovni nebo vyjádření některé ze zúčastněných osob. V dalších fázích vývoje by se měly doplňovat i odkazy na prvky návrhu, skripty a testovací scénáře [Robertson a Robertson, 2006]. Wiegers [2008] doporučuje dokumentovat zvlášť podnikatelská pravidla, která mohou mít platnost i pro jiné aplikace. Organizace by tak měla vytvářet svůj katalog podnikatelských pravidel a neustále ho aktualizovat. Měl by obsahovat jedinečnou identifikaci každého pravidla, jeho zdroj a typ. Mezi typy podnikatelských pravidel Wiegers [2008] řadí fakta, omezení, aktivátory, implikace a výpočty. Faktem pak rozumí neměnnou pravdu, tedy základní pravidlo podnikání, kterým je například vyjádření, že každá objednávka musí mít stanovenou cenu. Omezením je chápáno takové pravidlo, které limituje nějakým způsobem uživatelské nebo systémové akce. Příkladem omezení jsou například bezpečnostní předpisy řídící přístup do IS. Pravidla, která za určitých podmínek spouští nějakou akci, označuje jako aktivátory a dají se popsat pomocí rozhodovacích tabulek. Implikace se podobají aktivátorům, ale nespouští akci, ale za splnění určitých podmínek popisují nějaký fakt. Posledním uváděným typem podnikatelských pravidel jsou potom výpočty, které jsou reprezentovány matematickými vzorci nebo algoritmy. Dokument specifikace požadavků tedy popisuje ve vhodném stupni detailu dohodnuté funkční a mimofunkční požadavky. Může obsahovat i návrh uživatelského rozhraní, avšak to už spíš popisuje řešení a nikoliv požadavky [Wiegers, 2008]. Umožňuje však vzbudit větší představu o vyvíjeném systému, v žádném případě však nesmí být další fáze upnuty na tento návrh ve specifikaci požadavků. Dokument by neměl vůbec obsahovat projektové plány nebo konkrétní navrhované řešení, to je definováno až v pozdějších fázích [Hull, Jackson a Dick, 2005].
17
Náročnost této fáze inženýrství požadavků může být snížena používáním ozkoušených šablon a jejich přizpůsobením konkrétnímu projektu. Zaručují, že nebude žádná důležitá součást specifikace opomenuta a že bude dosaženo přehledného výsledku [Westfall, 2005]. Druhým usnadňujícím prostředkem je používání nástrojů pro sběr a analýzu požadavků, které se označují anglickou zkratkou RCAT (Requirements Collection and Analyses Tools) [Kopřiva, 2010]. Umožňují ukládat požadavky do databáze, manipulovat s nimi a napojit je k objektům uložených při návrhu a testování. U každého požadavku se může tak přehledně evidovat jeho verze, autor, status, zdroj, účel a priorita. Navíc je možné požadavky mezi sebou propojovat, což usnadňuje v případě změn nebo rušení některých požadavků analýzu dopadů. Mezi takové nástroje patří například Caliber-RM, DOORS, RequisitePro a RTM Workshop [Wiegers, 2000].
2.6 Potvrzení a ověření požadavků Cílem fáze V&V (z anglických výrazů „validation and verification“) je potvrzení, že požadavky odráží všechna přání a očekávání zainteresovaných osob, a ověření, že jsou požadavky popsány správně a v úplnosti [Wiegers, 2000]. Jedná se o iterativní proces spolu s ostatními procesy pro stanovení požadavků. V případě včasného odhalení nedostatků v požadavcích se totiž analytik může vrátit k předchozím fázím a získat tak další potřebné informace či si ujasnit některé nesrovnalosti [Westfall, 2005]. V první řadě provádí kontrolu dokumentu specifikace požadavků sám autor formou pročítání a hledání nekonzistencí. Musí sledovat, že žádný požadavek není v rozporu s jiným a že neodporuje ani požadavkům na vyšší úrovni, kterými jsou podnikatelské požadavky a požadavky na celý systém organizace. Dále by mělo být zajištěno, že každý požadavek je umístěn v dokumentu jen na jednom místě, a tam, kde je ho potřeba uvést znovu, je použit odkaz [Pfleeger a Atlee, 2006]. Hlavní používanou metodou v této fázi je recenzování, při kterém je požádána jiná osoba než autor, aby zkontrolovala dokument specifikace po stránce správnosti, srozumitelnosti a úplnosti. V případě formálního přístupu se pro tuto metodu používá označení inspekce, kdy je veškerá kontrola naplánována a kdy je požadován oficiální výstupní dokument obsahující připomínky k zapracování [Wiegers, 2008]. Specifikace požadavků by měla být hodnocena z různých perspektiv a toho lze kromě recenzování docílit i pomocí vytváření testovacích případů. Analytik je pak 18
předá vybraným uživatelům, kteří po přečtení dokumentu vysvětlí, jak nejspíš scénář proběhne a jaký bude mít výsledek [Zhou, 2004]. Kromě toho jsou analytikům pro tuto fázi vývoje požadavků k dispozici kontrolní seznamy, které analytik prochází a odškrtává si, co je dle seznamu zkontrolováno [např. Wiegers, 1999].
19
3 Problematika závěrečných prací Tato
kapitola
se
soustředí
na
věcné
objasnění
pojmů
souvisejících
s problematikou závěrečných prací. Teoretické znalosti, které z ní plynou, jsou nezbytným předpokladem pro pochopení aplikačního prostředí, ve kterém se nachází ISAZP. Hodně pojmů, procesů, prvků a omezení tohoto systému stanovuje legislativa2 nebo z ní vyplývají. V následujícím textu jsou proto vysvětleny a pro větší přehlednost jsou rozděleny do uměle vytvořených kategorií. První kategorie obsahuje samotné vymezení pojmu „závěrečná práce“ a jsou uvedeny její možné varianty. Druhá kategorie pak zahrnuje definování účastníků, kteří jsou v procesu závěrečných prací nějakým způsobem zainteresováni. Poslední kategorii pak tvoří pojmy související s jednotlivými činnostmi prováděnými v procesu závěrečných prací.
3.1 Závěrečná práce Závěrečnou prací se pro účely této bakalářské práce rozumí dokument, jehož autorem je student VŠ nebo VOŠ, který jej vytváří za účelem úspěšného ukončení svého studia a získání titulu. Jedná se o zvláštní typ dokumentu (tzv. „šedá literatura“) [Boldiš, 2004, s. 4] zpracovávající odborné téma odpovídající danému studijnímu oboru. Kromě toho závěrečná práce je předmětem autorského práva, neboť se jedná o dílo, které je výsledkem tvůrčí činnosti autora [§ 2 autorského zákona, 2006]. Student by měl ve své závěrečné práci prokázat schopnost samostatně zkoumat či řešit dílčí problém či téma související s obsahem jeho studijního oboru a následně jej systematicky a samostatně písemně zpracovat [článek 18 Studijního a zkušebního řádu VŠE, 2009]. Během vypracovávání své práce uplatňuje znalosti a dovednosti získané při studiu. Dovršením tohoto snažení je pak obhajoba, při níž student prezentuje svou práci [Gregarová, 2010, s. 3]. Každý typ studijního nebo vzdělávacího programu má jiné označení závěrečné práce, což prezentuje Obr. 3 spolu s uvedením zákona, ze kterého tento pojem pochází. V textu dále jsou pak postupně jednotlivé pojmy objasněny detailněji.
2
V této kapitole je abstrahováno od konkrétních interních předpisů škol a je objasňována problematika jen na základě zákonů týkajících se závěrečných prací.
státní doktorská zkouška obhajoba disertační práce
Doktorský studijní program
státní závěrečná / rigorózní zkouška obhajoba diplomové / rigorózní práce Navazující magisterský studijní program
Magisterský studijní program
státní závěrečná zkouška obhajoba bakalářské práce
Bakalářský studijní program
Vysokoškolské vzdělávání
Vyšší odborné vzdělávání část šestá školského zákona
část čtvrtá zákona o vysokých školách
Obr. 3 Terciární vzdělávání, upraveno dle [Ústav pro informace ve vzdělávání, 2010]
3.1.1 Absolventské práce Student vyšší odborné školy své vzdělávání ukončuje absolutoriem, jehož součástí je zkouška z odborných předmětů, zkouška z cizího jazyka a obhajoba absolventské práce [§ 102 vyhlášky o vyšším odborném vzdělávání, 2004]. Absolventskou práci může zpracovat a obhajovat společně více studentů, přičemž jsou ale studenti hodnoceni jednotlivě. Práce a její obhajoba navíc může obsahovat i část ověřující praktické dovednosti [§ 102 vyhlášky o vyšším odborném vzdělávání, 2004]. 3.1.2 Vysokoškolské závěrečné práce Pro vysokoškolské závěrečné práce zákon stanovuje povinnost je nevýdělečně zveřejňovat nejméně pět pracovních dnů před konáním obhajoby [§ 47b zákona o vysokých školách]. Platí to pro všechny práce, u kterých proběhla obhajoba, tedy musejí být zveřejnovány i neúspěšné práce. Kromě toho musí vysoká škola zpřístupnit veřejnosti i posudky oponentů a záznamy o průběhu a výsledku obhajoby. Pro tyto účely proto školy spravují vlastní databázi závěrečných prací, která je většinou součástí interního IS školy. Vnitřními předpisy pak stanovují další detaily týkající se ukládání, vypracování, zveřejňování, obhajoby a prohlížení těchto prací.
21
Závěrečné práce vypracované v rámci jednotlivých studijních programů se liší v požadavcích na ně kladené. Text níže popisuje jednotlivé „varianty“ těchto prací a souvislost se závěrečnými zkouškami. Bakalářská práce
Při bakalářském studiu jsou využívány soudobé poznatky a metody a v potřebném rozsahu jsou rozvíjeny teoretické poznatky. Ukončuje se státní závěrečnou zkouškou, jejíž součástí je zpravidla obhajoba bakalářské práce [§ 45 zákona o vysokých školách]. Diplomová práce
Absolvent bakalářského studia může pokračovat ve svém studiu na magisterském studijním programu. Některé magisterské studijní programy však nemusí navazovat přímo na bakalářský studijní program, pokud to vyžaduje jeho charakter. Studium se ukončuje státní závěrečnou zkouškou, jejíž součástí je obhajoba diplomové práce. V oblasti lékařství a veterinárního lékařství a hygieny se studium ukončuje státní rigorózní zkouškou [§ 46 zákona o vysokých školách]. Rigorózní práce
Pro absolventy magisterského studia, kteří již získali akademický titul „magistr“ existuje možnost konat v téže oblasti studia státní rigorózní zkoušku, jejíž součástí je obhajoba rigorózní práce. Jsou jim pak udělovány akademické tituly jako např. JUDr., PhDr., RNDr. apod. [§ 45, odst. 5 zákona o vysokých školách]. Disertační práce
Disertační práce vypracovávají studenti, kteří po magisterském studiu byli přijati do doktorského studijního programu. Ten je zaměřen na vědecké bádání, samostatnou teoretickou a tvůrčí činnost [§ 47, odst. 1 zákona o vysokých školách]. Studium je ukončeno státní doktorskou zkouškou a obhajobou disertační práce, kterými se prokazuje schopnost a připravenost k samostatné činnosti v oblasti výzkumu nebo k samostatné teoretické a tvůrčí umělecké činnosti [§ 47, odst. 4 zákona o vysokých školách]. Zákon se navíc na tomto místě odkazuje na autorský zákon, a to konkrétně na § 10 definující den uveřejnění a vydání díla. Disertační práce tak musí obsahovat výsledky týkající se uveřejnění. 22
3.2 Klíčové role Níže v textu jsou definovány osoby, které hrají klíčovou roli v problematice závěrečných prací. Nejsou zde uvedeni všichni zúčastnění, např. ti, kteří rozhodují o některých záležitostech či kteří vykonávají administrativu spojenou se závěrečnými pracemi. 3.2.1 Student Osoby, které získaly střední vzdělání s maturitní zkouškou, mohou být po úspěšném splnění podmínek přijímacích zkoušek přijati ke studiu na VŠ nebo VOŠ. Dnem zápisu do studia3 se stávají studenty [§ 61 zákona o vysokých školách; § 97 školského zákona]. Student je zapsán zároveň do matriky studentů, kterou škola vede k rozpočtovým a statistickým účelům [§ 88 zákona o vysokých školách]. Student přestává být studentem dnem ukončení studia [§ 61 zákona o VŠ; § 98 školského zákona], které může být řádné v případě naplnění všech studijních požadavků, nebo může spočívat v zanechání studia, nesplnění studijních požadavků, vyloučení ze studia nebo odnětí či zániku akreditace studijního programu. 3.2.2 Vedoucí závěrečné práce Student konzultuje vypracovávání své závěrečné práce s vedoucím práce a to většinou formou osobních setkání či emailové komunikace. Jeho připomínky a návrhy pak zapracovává do textu své závěrečné práce [Hakalová, 2008]. Vedoucím závěrečné práce bývá zpravidla pracovník dané školy, který vykonává pedagogickou, výzkumnou nebo jinou tvůrčí činnost [článek 18, odst. 4 studijního a zkušebního řádu VŠE]. 3.2.3 Oponent závěrečné práce Oponent závěrečné práce, popřípadě i vedoucí práce vyhotovují na odevzdanou práci písemný posudek, jenž obsahuje navržené hodnocení práce [§ 18, odst. 5 studijního řádu VŠE] spolu s připomínkami, které se pak diskutují při obhajobě. Oponentem většinou bývá odborně vzdělaná osoba či konzultant z praxe [Hakalová, 2008].
3
U studentů VOŠ zákon hovoří o zápisu ke vzdělávání. V této bakalářské práci jsou pojmy vzdělávání a studium nerozlišovány.
23
3.2.4 Zkušební komise Oba výše uvedení účastníci jsou pak přítomni u obhajoby závěrečné práce, kde jsou členy zkušební komise. Komise se dále skládá z předsedy a dalších odborných, většinou pedagogických pracovníků. V případě komise, která zkouší při absolutoriu, jsou jimi učitelé VOŠ a předsedou může být jen pracovník jiné VŠ nebo VOŠ [§ 102, odst. 4 školského zákona]. U státních zkoušek na VŠ mohou zkoušet pouze profesoři, docenti a odborníci schválení příslušnou vědeckou radou [§ 53 zákona o vysokých školách].
3.3 Proces závěrečných prací Procesem je zde chápána posloupnost takových činností, jejichž výstupem je závěrečná práce přihlášená k obhajobě. Jelikož se jedná o proces, dochází k přeměně vstupů na výstupy. Nejvýstižněji jej znázorňuje Obr. 4. V následujícím textu jsou pak nastíněny nezbytné činnosti tohoto procesu. Jejich bližším a konkrétním průběhem na VOŠIS se zabývá praktická část této práce, zde je tato problematika jen stručně naznačena.
Obr. 4 Základní činnosti probíhající v procesu závěrečných prací, převzato z [Kučerová, 2009]
3.3.1 Zadání Na začátku procesu si student volí téma své závěrečné práce. Většinou si jej vybírá z nabídky, která je relevantní jeho oboru a která je vypsána jednotlivými vedoucími práce dané školy [Hakalová, 2008]. Podle § 62 zákona o vysokých školách může student navrhnout i své vlastní téma.
24
Poté kontaktuje příslušného pedagoga a s jeho pomocí formuluje konkrétní název práce, cíle, hypotézu, osnovu a vhodnou odbornou literaturu. Zejména důležité je i stanovit metody, které student použije [Hakalová, 2008]. Výstupem této činnosti je pak oficiální dokument se zadáním závěrečné práce, které student musí odevzdat v předem stanoveném termínu. 3.3.2 Vypracování a odevzdání Poté student vypracovává své téma závěrečné práce, při němž aplikuje nejrůznější metody, jako je studium odborné literatury, analogie nebo dedukce [Kučerová, 2009] a řídí se zásadami pro vypracování závěrečných prací, které jsou většinou dány školou. Během této činnosti student konzultuje koncepci, problémy a otázky s vedoucím práce, případně i s jiným odborníkem. Výstupem tohoto kroku potom je dokument závěrečné práce, který je většinou vyhotoven ve dvou výtiscích s pevnou vazbou a v elektronické verzi, kterou student odevzdává na elektronickém nosiči nebo ji přímo ukládá do databáze školy. Spolu s odevzdáním se přihlašuje k závěrečným zkouškám a obhajobě závěrečné práce. 3.3.3 Obhajoba V rámci závěrečné zkoušky obvykle probíhá i obhajoba závěrečné práce. Student si na ni připraví úvodní slovo, aby seznámil zkušební komisi s důvody výběru tématu, s cílem práce, s přístupem k řešení problému včetně použitých metod a postupů a dále s východisky a závěry, které z práce vyplývají [Synek, Sedláčková a Vávrová, 2002]. Po uvedení své práce student reaguje na připomínky a otázky uvedené v posudku oponenta, případně v hodnocení práce jejím vedoucím. Jak bylo uvedeno výše, jsou to dokumenty vytvořené vedoucím a oponentem práce, ve kterých hodnotí studentovu práci a uvádějí její klasifikaci formou známky (výborně, velmi dobře, dobře, nevyhověl). Posuzují zejména míru naplnění cílů práce, způsob aplikace teoretických znalostí, přínos, obsahovou a formální úroveň práce [Synek, Sedláčková a Vávrová, 2002]. Dále se zaměřují i na aktuálnost a vhodnost zpracovávaného tématu, logiku postupu vypracování, práci s literaturou a kvalitu výkladu [Hakalová, 2008]. Neobhájí-li student svou práci, může konat její opravu, a to zpravidla nejvýše dvakrát [§ 102 školského zákona; článek 16, odst. 7 studijního a zkušebního řádu VŠE]. 25
4 Použitá metodika V této kapitole je zdůvodněn výběr metod použitých pro sběr požadavků na ISAZP a je v ní popsán postup analýzy takto získaných požadavků. Sběr požadavků spolu s analýzou probíhaly paralelně od října roku 2010 do března roku 2011. Během července a srpna pak tyto požadavky byly dokumentovány a byl vytvořen dokument se specifikací požadavků na ISAZP, který tvoří pátou kapitolu této bakalářské práce.
4.1 Použité metody získávání požadavků V teoretické části, konkrétně v kapitole 2.3, byly vyjmenovány a stručně popsány některé nejpoužívanější metody pro sběr požadavků. Tyto metody byly i předmětem mé předchozí bakalářské práce, jak již bylo zmíněno v úvodu práce. Některé z uvedených metod je vhodné použít pro účely sestavení požadavků na ISAZP, který je předmětem této bakalářské práce. Na začátku této fáze inženýrství požadavků byly vybrány nejvhodnější metody a stanoveno pořadí jejich použití: 1. Logickým výchozím bodem pro zjišťování základních informací bylo samostatné studium dokumentů souvisejících s aplikační doménou ISAZP – aplikací této metody se zabývá kapitola 4.1.1. 2. Poté se objevila potřeba získat další informace a ujistit se o správném pochopení dosavadně získaných informací. Bylo nutné proto identifikovat zainteresované osoby a uskutečnit s nimi rozhovory – aplikací této metody se zabývá kapitola 4.1.2. Na začátku bylo počítáno i s uskutečněním skupinových rozhovorů s více zainteresovanými stranami a vytvoření dotazníků pro zjištění požadavků ze strany studentů diplomového semináře, avšak informace získané prostřednictvím výše uvedených metod byly dostatečné pro následující analýzu. Ani nebylo potřeba vytvářet částečné řešení systému v podobě prototypu, neboť požadavky byly poměrně jasné. Většina z nich totiž vyšla ze závazných pravidel vyplývajících z legislativy a ty, které vyšly z rozhovorů s jednotlivci, tyto požadavky dále rozšířily a upřesnily. S žádnou větší neurčitostí se tedy sběr a ani analýza požadavků nesetkala.
4.1.1 Studium dokumentace V kapitole 3 byly uvedeny základní informace týkající se problematiky závěrečných prací a vymezeny její klíčové pojmy. Tyto informace byly získány především na základě studia a analýzy legislativních norem ČR (především školského zákona a zákona o VŠ). Bylo abstrahováno od úprav jednotlivých institucí, které si definují ve svých interních předpisech detaily týkající se mj. závěrečných prací. Pro účely sestavení požadavků na ISAZP však musely být tyto informace doplněny, aby odpovídaly konkrétnímu prostředí. Jednalo se tedy o další studium dokumentů, zejména předpisů souvisejících se závěrečnými pracemi, a to na VOŠIS, VŠE a FF UK, přičemž musela být nejdříve analyzována organizace a vztahy mezi jednotlivými institucemi. Kromě toho bylo vhodné zjistit informace o existujících systémech, které problematiku závěrečných prací již řeší. Pro tyto účely byly nastudovány manuály a další dokumentace těchto systémů, příp. ověřeny i samotným vyzkoušením aplikace, pokud to bylo možné. Úvodní analýza organizace
V prvé řadě bylo důležité objasnit vztahy mezi zúčastněnými vzdělávacími institucemi, kterých se specifikace požadavků ISAZP týká, aby bylo možné rozhodnout, které jejich předpisy jsou relevantní k dalšímu studiu. Jak již z názvu této bakalářské práce je patrné, předmětem této bakalářské práce je v prvé řadě VOŠIS a její závěrečné práce, které zahrnují v případě vyššího odborného vzdělávání absolventské práce. Jelikož VOŠIS také realizuje studium bakalářských oborů (PIS a INSK), jak bylo nastíněno v úvodu, mělo by být zjištěno, zda musí nebo chce zahrnout pod svou správu i bakalářské práce. Bakalářský studijní obor PIS je realizován od akademického roku 2006/2007 ve spolupráci s VŠE. Vztah těchto dvou institucí je upraven Opatřením děkana Fakulty informatiky a statistiky VŠE č. 4/2002 ze dne 10. 9. 2002, kde je stanoveno, že ředitel VOŠIS v Praze je zmocněn k výkonu pravomocí děkana v rámci realizace tohoto studijního oboru, s výjimkou rozhodovacích procedur spojených s přijímáním, ukončováním a řádným ukončením studia [VOŠIS, 2011]. V dalším textu této bakalářské práce proto bude používán jen jeden pojem „ředitel VOŠIS“, který však bude zahrnovat i funkci děkana pro obor PIS. Z tohoto vyplývá, že je nezbytné studium příslušné legislativy VOŠIS a VŠE, přičemž je nutné se zaměřit i na vymezení úloh ředitele/děkana ve vztahu k závěrečným pracím. 27
Druhým bakalářským studijním oborem je INSK, který VOŠIS realizuje ve spolupráci s Filozofickou fakultou UK (dále jen „FF UK“) od zimního semestru akademického roku 2003/2004 [VOŠIS, 2011]. Vztah mezi těmito institucemi spočívá v tom, že část přijatých studentů na INSK absolvuje převážnou část výuky v prostorách VOŠIS, přičemž ale i tito studenti mají práva a povinnosti studentů FF UK bez rozdílu [ÚISK, 2010]. Navíc je na VOŠIS realizována kombinovaná forma tohoto studia od roku 2010/2011 [VOŠIS, 2011]. V tomto případě tedy ředitel VOŠIS neplní zároveň funkci děkana a pravděpodobně nebude proto povinen zajistit evidenci závěrečných prací. Tuto skutečnost bylo však potřeba ověřit prostřednictvím studia patřičných dokumentů nebo dotázáním se některé kompetentní osoby. Předpisy VOŠIS
Výchozí právní úpravu stanovuje pro vyšší odborné vzdělávání školský zákon, který byl diskutován v kapitole 3. Vyšší odborné školy však také musejí respektovat vyhlášku o vyšším odborném vzdělávání, která mj. stanovuje další specifikace týkající se závěrečných prací. Zejména ustanovuje pravidla související s termíny konání absolutoria, konkrétně stanovuje, že tyto termíny určuje ředitel školy, dále v jakém období mohou být vypsány a jak moc předem musejí být zveřejněny [§ 7 vyhlášky o vyšším odborném vzdělávání]. Tyto termíny jsou relevantní k ISAZP, neboť předurčují časový harmonogram procesu závěrečných prací. Dále se vyhláška zabývá organizací a způsobem hodnocení absolutoria. Studijní řád VOŠIS [2009] pak upřesňuje ještě další podmínky pro závěrečné práce. K vykonání absolutoria se student podle tohoto předpisu přihlašuje podle organizačních předpisů VOŠIS. Tato skutečnost byla zpřesněna během rozhovorů se zainteresovanými osobami. Předpisy VŠE
Na studenty oboru PIS se mj. vztahuje Studijní a zkušební řád VŠE [2009]. Článek 16 tohoto předpisu vymezuje pravidla státních závěrečných zkoušek, jejichž součástí je i obhajoba bakalářské práce. Každá část této zkoušky lze opakovat nejvýše dvakrát, přičemž obhajoba práce je možná nejdříve tři měsíce ode dne neúspěšného pokusu. Student v tomto případě musí předložit upravenou práci, nebo musí zpracovat novou práci na nové téma. O tomto rozhoduje zkušební komise. 28
Bakalářská práce spadá dle tohoto předpisu pod tzv. kvalifikační práce [článek 18 studijního a zkušebního řádu VŠE], kam patří ještě i diplomové práce. Dále je v něm předepsáno, aby oponent práce byl vždy vysokoškolsky vzdělaný odborník. Další relevantní informace k ISAZP představuje odstavec 6 předchozího článku, který ukládá povinnost pracovišti, kde je práce zpracovávána, umožnit studentovi seznámit se s posudky práce nejpozději tři pracovní dny před termínem obhajoby. Další pravidla související se závěrečnými pracemi jsou uvedeny v odstavci 3 článku 18. Týká se pravomocí děkana, který určuje termíny, v nichž vedoucí vyhlašují témata prací a přidělují je studentům. Dále určuje způsob a náležitosti jmenování vedoucích a oponentů prací a pro studenty pak postup a způsob od výběru tématu práce a přihlášení k němu, až po její odevzdání a obhajobu, včetně časového harmonogramu. Vůbec nejdůležitějším článkem tohoto předpisu pro ISAZP je článek 18a, který se týká zveřejňování závěrečných prací. Zákon o vysokých školách totiž ukládá vysokým školám, jak již bylo psáno dříve, povinnost zveřejňovat závěrečné práce. VŠE proto vede databázi prací, u nichž již proběhla obhajoba nebo je plánována. Tato databáze je součástí Integrovaného studijního informačního systému VŠE (dále jen „ISIS VŠE“). Předpisy UK
Opatření děkana FF UK č. 21/2010 upřesňuje a doplňuje postupy pro evidenci, odevzdávání a zveřejňování závěrečných prací, které je UK jakožto vysoké škole stanoveno zákonem. Student ukládá elektronickou verzi do Studijního informačního systému UK (dále jen „SIS UK“), přičemž je zodpovědný za správnost a úplnost souborů práce a soulad elektronické verze práce s její listinnou podobou. Vzhledem k tomu, že jsem sama roku 2010 úspěšně absolvovala studium tohoto oboru, mohu doložit, že bakalářské práce odevzdávají všichni studenti (tedy i ti, kteří větší část výuky absolvují na VOŠIS) na sekretariát Ústavu informačních studií a knihovnictví, který patří pod FF UK, a jejich veškerou evidenci zajišťuje i tato fakulta. V době odevzdávání mé práce ještě výše uvedené opatření nenabylo účinnosti a elektronická verze práce byla přikládána k práci na CD a její nahrání do databáze závěrečných prací zajišťoval pověřený pracovník. Proto
byly
tyto
rok
staré
informace
ověřeny
při
rozhovorech
se
zainteresovanými osobami a bylo s nimi diskutováno, zda bakalářské práce studentů INSK by měly být také evidovány na VOŠIS. 29
Dokumentace stávajících ISAZP
Předmětem studia dokumentů byly i manuály k již existujícím ISAZP, které jsou většinou součástí integrovaného studijního IS školy. Pro analýzu byla vybrána:
aplikace ISIS VŠE „Závěrečné práce na VŠE“ [VŠE, 2011],
modul „Témata prací“ v rámci SIS UK [UK, 2008],
sekce Informačního systému Masarykovy univerzity v Brně (dále jen „IS MUNI“) „Přihlašování se k tématům/variantám z balíků témat“ [MUNI, 200?] a
aplikace „Kvalifikační práce“ v rámci Informačního systému studijní agendy Západočeské univerzity v Plzni (dále jen „IS/STAG ZČU“) [ZČU, 2009].
Požadavky, které vyšly ze studia těchto manuálů, byly analyzovány do podoby diagramu případů užití, aby byly odhaleny základní funkce těchto systémů. Tato analýza je blíže popsána v kapitole 4.2.1. Konkrétní dokumenty
V neposlední řadě bylo vhodné provést sběr informací z konkrétních dokumentů, které jsou výstupem procesu závěrečných prací. Jsou jimi zejména oficiální zadání práce, posudky a samotné závěrečné práce. Na základě toho pak bylo možné definovat požadavky na strukturu dat, což je součástí analýzy požadavků, konkrétně kapitoly 4.2.2. 4.1.2 Rozhovory se zainteresovanými osobami V rámci uskutečnění rozhovorů bylo důležité nejdříve identifikovat třídy uživatelů, kterých se ISAZP nějakým způsobem týká, a pak vybrat vhodné zástupce z každé třídy a požádat je o rozhovor. K tomuto účelu byly nejdříve definovány případy užití na základě analýzy manuálů konkurenčních ISAZP, neboť odhalují aktéry systému. Prosba o poskytnutí rozhovoru byla komunikována emailově, v některých případech vyslovena při osobním setkání. Celkem bylo uskutečněno pět interview, přičemž první bylo realizováno s PhDr. Kučerovou, protože má velké znalosti aplikační domény ISAZP. Dlouho vedla diplomové semináře, na kterých seznamovala studenty s procesem závěrečných prací a prováděla i jejich evidenci. Na konci prvního rozhovoru
30
mi pak doporučila další osoby, které bych měla kontaktovat, abych si upřesnila nově získané informace a získala další pohledy budoucích uživatelů ISAZP. Proto jsem požádala o rozhovor další osoby. Celkový přehled o jménech těchto dotazovaných prezentuje Tab. 1 spolu s datem uskutečnění rozhovoru, jeho přibližné délky a uvedením důvodu výběru osoby pro interview. Dotazovaný
Datum
Délka
Důvod výběru osoby
[hod] PhDr. Helena Kučerová
26.10.2010
1,5
Znalost aplikační domény, vedla dříve diplomové semináře, spravuje systém Paradox pro správu záznamů o závěrečných prací.
Ing. Stanislava Hrušková PhD.
2.11.2010
1,0
Vede v současné době diplomové semináře pro studenty bakalářského oboru PIS.
Ing. David Klimánek
11.11.2010
0,5
Vytvořil aplikaci pro přihlašování se k tématům závěrečných prací, kterou ale bohužel nevyužívají všichni vedoucí prací.
Ing. Antonín Skopec
11.11.2010
1,0
Je správcem intranetu VOŠIS a má znalosti o technickém řešení IS školy.
Anežka Nedomová
11.11.2010
0,5
Je knihovnicí ve VOŠIS, ukládá závěrečné práce do knihovního fondu a vytváří k nim katalogizační záznam.
Tab. 1 Uskutečněná interview se zainteresovanými osobami
4.2 Popis analýzy požadavků 4.2.1 Případy užití vyplývající z analýzy stávajících systémů Na základě analýzy dokumentace konkurenčních ISAZP (viz kapitola 4.1.1) byly sestaveny případy užití, které pomohly objevit klíčové funkce a činnosti prováděné v rámci takového systému. V následujícím textu jsou dále stručně komentovány spolu s aktéry těchto případů užití. Určení aktérů napomohlo identifikaci zainteresovaných osob a mohly tak být uskutečněny rozhovory s konkrétními osobami. Samotné diagramy jsou rozděleny do tří obrázků (Obr. 5, Obr. 6, Obr. 7). Nutno podotknout, že pořadí uvádění těchto popisů nemá žádnou časovou či jinou následnost.
31
Aktéři
Bylo zjištěno, že skutečnými uživateli ISAZP, jsou studenti, vedoucí a oponenti práce, kteří jsou definováni v kapitole 3.2. Dalšími zatím nezmíněnými aktéry pak jsou:
vedoucí ústavu, který má rozhodovací pravomoci, co se týče závěrečných prací;
studijní referentka, která je zaměstnancem instituce a zajišťuje administrativní činnosti spojené se závěrečnými pracemi;
knihovnice, která zajišťuje zařazení závěrečných prací do knihovního fondu.
Stručný popis případů užití
Návrh tématu, Volba tématu, Schválení tématu, Sledování témat Téma práce může navrhovat pedagogický pracovník, který jej pak zároveň
většinou i vede, nebo student sám. V obou případech je většinou schvaluje vedoucí ústavu, aby se v následujících krocích z nich staly konkrétní zadání práce. Student si může prostřednictvím seznamu nabízených témat vybrat téma a následně kontaktovat příslušného vedoucího práce. Tuto komunikaci může zajišťovat i systém sám formou emailových oznámení. Rozpracovaná témata, témata odeslaná ke schválení vedoucímu ústavu, nabízená i nenabízená témata a témata ke schválení by měl systém umožnit zobrazovat patřičným aktérům, aby měli přehled o současném stavu. Student prostřednictvím nabízených témat si z nich může vybírat téma.
Vytvoření/uložení zadání, Schválení zadání, Tisk zadání Vedoucí práce (v některých případech i student či studijní referentka) může
vytvářet za pomoci formuláře v systému zadání práce, případně do něj uložit soubor obsahující zadání. Lze jej vytvořit jen pro aktivní studenty. Zadání si pak vedoucí práce i student mohou zobrazovat a dělat v něm patřičné změny. Zadání musí následně schválit vedoucí ústavu a potom jej může vedoucí práce vytisknout a odevzdat kompetentním osobám k podpisu. Toto zadání pak student vkládá do své práce.
32
ISAZP sledování témat volba tématu
vložení práce
prohlížení posudku vytvoření/uložení zadání
doplnění dalších informací
sledování kompletnosti
student
tisk zadání
vrácení práce k přepracování formulace zadání
návrh tématu úprava souborů práce
Obr. 5 Případy užití – student
Změna vedoucího práce Systém by měl zajistit i funkce pro případnou změnu vedoucího práce, při
kterém by vedoucí práce mohl požádat o převzetí vedené práce svého kolegu.
Sledování kompletnosti Sledování kompletnosti odevzdání závěrečné práce je případ užití vysledovaný
u ISIS VŠE [VŠE, 2011]. Během celého procesu student a jeho vedoucí práce vědí, ve kterém kroku se nachází a jsou informováni červeně zvýrazněnými upozorněními na nekompletnost některých informací (např. chybějící oponent, zadání, nevyplnění abstraktu).
33
ISAZP zobrazení zadání
vložení posudku
stažení souborů práce
oponent práce sledování témat
vytvoření/uložení zadání
potvrzení volby oponenta
návrh tématu
schválení tématu
vedoucí ústavu
sledování kompletnosti
vedoucí práce
schválení zadání vrácení práce k přepracování
tisk zadání změna vedoucího práce
vložení jména oponenta správa a kontrola vedených prací
Obr. 6 Případy užití - vedoucí a oponent práce, vedoucí ústavu
Správa a kontrola vedených prací Vedoucí prací by měli mít k dispozici přehledný seznam jimi vedených prací,
který je možno různě filtrovat např. dle roku, studentů a stavu, ve kterém se daný proces nachází.
Vložení práce, Úprava souborů práce Studentovi by měl systém umožnit vložit patřičné soubory související s jeho
závěrečnou prací v době, kdy se přihlašuje k závěrečným zkouškám. Nejčastějším povoleným ukládaným souborem je PDF formát alespoň ve verzi 1.4, která umožňuje prohledávání v souboru. Dále student může vkládat přílohy své práce. Soubory by mu mělo být umožněno editovat do té doby, dokud nepotvrdí odevzdání, příp. do vykonání obhajoby. SIS FF UK [UK, 2008] dále dovoluje studentovi vložit návrh na vyloučení příloh práce ze zveřejnění v případech, kdy se jedná o zvláště citlivé údaje. Tento návrh pak putuje kompetentní osobě ke schválení a dle jeho výsledku potom práce může být z části utajena či nahrazena jinými údaji.
Stažení souborů práce, Vrácení práce k přepracování Po odevzdání souborů do systému, jsou přístupny ke stažení a prohlížení
vedoucímu práce a oponentovi. Vedoucímu práce by mohlo být umožněno vrátit 34
studentovi práci k přepracování s připomínkami. Student pak je o této skutečnosti informován systémem a nahraje novou opravenou verzi práce.
Vložení jména oponenta, Potvrzení volby oponenta, Vložení posudku, Prohlížení posudku Jméno oponenta většinou vkládá vedoucí práce [VŠE, 2011]. Volba oponenta
však musí být potvrzena vedoucím ústavu. Pokud je schválen oponent, je zpřístupněna funkce pro vkládání posudků vedoucím a oponentem práce, které jsou pak k dispozici k prohlížení studentovi před obhajobou.
ISAZP tisk seznamu prací
studijní referentka nastavení termínů
knihovnice vložení informací o obhajobě
stažení metadat o práci
Obr. 7 Případy užití - studijní referentka a knihovnice
Doplnění dalších informací Student doplňuje v průběhu informace týkající se jeho závěrečné práce, kterými
jsou například abstrakt, klíčová slova v češtině a angličtině a po obhajobě errata4. Většinu údajů by však systém měl předvyplňovat automaticky dle údajů o přihlášeném uživateli (např. typ práce, studijní obor, adresa školy), aby byla zaručena unifikace dat.
4
Tvůrcem errata je student a jedná se o soubor, který obsahuje opravy k seznamu připomínek, který na základě obhajoby studenta sestavila komise [VŠE, 2011].
35
Nastavení termínů Studijní referentka, příp. jiná kompetentní osoba by měla mít možnost
nastavovat termíny spojené s procesem závěrečných prací (termín volby tématu, odevzdání zadání, obhajob apod.), se kterými pak systém řídí příslušné operace.
Vložení informací o obhajobě Studijní referentka většinou doplňuje po obhajobě její hodnocení, datum a místo
jejího konání, případně další informace týkající se průběhu obhajoby. Potom není umožněné studentovi upravovat soubory nebo jiné údaje v systému.
Tisk seznamu prací, Stažení metadat o práci Zajímavý případ užití se dá najít v IS/STAG ZČU [ZČU, 2009], kde studijní
referentka po obhajobě má možnost vytisknout přejímkový seznam prací a pak jej předat knihovně, která práce fyzicky ukládá a potřebuje je zaevidovat do knihovního IS. 4.2.2 Definice dat vyplývající z analýzy dokumentů Prostřednictvím analýzy konkrétních závěrečných prací, zadání a posudků, které byly vytvořeny na VOŠIS, mohla být stanovena struktura dat na konceptuální úrovni, kterou zobrazuje Obr. 8. Závěrečná práce * * * * o o o
Ředitel
0,1
Abstrakt CZ Text Abstrakt EN Text Klíčová slova CZ Text Klíčová slova EN Text Text práce PDF Přílohy PDF/XLS/... Hodnocení Short integer
Zadání
podepisuje
# # * * * * * * * o
0,n 0,n
Vedoucí práce
vede
0,n
1,1
Název práce Jméno studenta Typ práce Studijní obor Cíl práce Jméno vedoucího práce Datum zadání práce Termín odevzdání práce Odpovědný ústav a jeho adresa Podpis ředitele ...
Variable characters (50) Variable characters (30) Characters (1) Variable characters (30) Text Variable characters (30) Date Date Date Date
0,n
zapisuje známku 0,1 Studijní referentka
formuluje 1,1
Téma práce # # o o
0,1
Název Vedoucí Vhodnost pro obor Datum vyhlášení tématu ...
Variable characters (50) Variable characters (30) Variable characters (30) Date
0,n
volí 1,1
Student 0,3
Posudek
vyhotovuje2
0,n 0,n
Oponent práce 1,1
* Jméno oponenta/vedoucího Variable characters (30) o Kritérium hodnocení Short integer * Navržená známka Short integer
vyhotovuje1
Obr. 8 Konceptuální model ISAZP
36
vypracovává
1,n
Tento diagram vyžaduje komentář. Jsou v něm prezentovány navrhované entity v ISAZP a u některých jsou uvedeny i jednotlivé atributy, které jsou odvozeny na základě analýzy příslušných dokumentů. Model není normalizován, je to skutečně jen konceptuální návrh. Jsou v něm ale zachyceny některé důležité zákonitosti. Zejména důležitá je kardinalita vztahu student-závěrečná práce a student-téma. Z první totiž vyplývá, že systém musí počítat s tím, že student může opakovat obhajobu své práce dvakrát. Tudíž může nastat případ, že vyhotoví tři odlišné závěrečné práce, z nichž minimálně dvě budou neobhájené. Dále lze z ní usoudit, že jedna práce může mít více autorů (studentů). Toto platí však jen pro studenty VOŠIS, kteří mohou v rámci svého studia vypracovávat týmovou absolventskou práci. Tento vztah je nejspíše nadbytečný, jelikož se na VOŠIS týmové práce nevypracovávají. Druhá kardinalita pak odráží skutečnost, že student může témat mít během svého studia vybráno hodně (až n témat). Zde totiž není nikterak studijním řádem limitován. Může téma zvolit a pak se rozhodnout pro jiné apod. Další zajímavý vztah vzniká mezi posudky a vedoucím práce. Ze zákona přímo nevyplývá, že by vedoucí práce musel vyhotovovat posudek, jako je tomu u oponenta. Tudíž by tato skutečnost měla být systémem také odrážena, případně stanovena v metodice pro závěrečné práce. Posledním důležitým vysvětlením tohoto diagramu jsou šipky mezi entitami téma, zadání a závěrečná práce. Ačkoliv se jedná o datový model, je tímto naznačen proces přeměny a přesunu údajů od volby tématu přes vytvoření zadání po vypracování práce. 4.2.3 Analýza současného systému Na základě informací získaných z rozhovorů se zainteresovanými osobami je v následujícím textu popisován a analyzován současný stav prostředí závěrečných prací na VOŠIS. Budoucí stav systému je pak popsán prostřednictvím případů užití ve specifikaci požadavků (kapitola 1), která se soustředí na definování hlavních funkcí systému. Současný proces závěrečných prací na VOŠIS
Evidenci studentů VOŠIS a oboru PIS vede a vlastní přímo VOŠIS a je součástí interního IS. Studenti VŠE jsou dále předáváni prostřednictvím správce intranetu do
37
ISIS VŠE. Studenti oboru INSK jsou samostatně evidováni v SIS UK. Evidence vedoucích a oponentů práce neexistuje. Samotnou evidenci závěrečných prací má na starost učitel ročníku podle studijního oboru. V současné době je evidováno ve stávajícím systému PARADOX asi 1000 záznamů o závěrečných pracích a to rozpracovaných, obhájených i neobhájených. V samotné databázi je uloženo cca. 100 dokumentů závěrečných prací. Závěrečné práce studentů INSK jsou evidovány UK a nejsou proto ani předmětem další analýzy. Studenti musejí získat zápočet z předmětu „Diplomový seminář“, aby mohli mít zadané téma závěrečné práce. Tento předmět si mohou zapsat kdykoliv v průběhu studia, není to omezeno ročníkem. V rámci tohoto semináře musejí studenti vypracovat projekt k závěrečné práci, který zahrnuje název tématu, jméno vedoucího práce, vymezení problematiky, stanovení cíle a hypotézy práce a je v něm popsána metodologie vypracování práce, informační zdroje a další údaje [Kučerová, 2009]. Podmínkou pro udělení zápočtu z tohoto předmětu je dále i odevzdání zadávacího formuláře. Pro studenty VOŠIS je však podmínkou jen odevzdání závěrečné práce. Zápočet jim je tak mnohdy udělován zpětně. Témata závěrečných prací jsou studentům k dispozici ve formě statického seznamu v HTML formátu . Někteří vedoucí zveřejňují své práce na svých osobních stránkách . U tématu je uveden název a vedoucí práce, příp. je označeno, zda je téma vhodné pro studenta VOŠIS nebo oboru PIS. Student může sám navrhnout téma práce a to tak, že zajde osobně za vedoucím či ho kontaktuje emailem a dohodne s ním detaily. Vedoucí diplomového semináře by měl mít pak přehled o tématech, která si studenti navrhli nebo vybrali, a měl by posoudit, zda je předá řediteli VOŠIS ke schválení. Ředitel tak obdrží vytištěný seznam témat ke schválení a rozhodne o jejich vhodnosti. Tento seznam obsahuje kolem 40 témat a ředitel jej většinou posoudí do tří dnů po obdržení. Tato lhůta však není oficiálně dána. Ředitel pak téma a) schválí a student tak může pokračovat na vypracování své práce, nebo jej b) zamítne a student si musí vybrat nové téma či přepracovat dosavadní za pomoci svého vedoucího. Tyto informace se dozví na diplomovém semináři. V případě schválení student vypracuje svou závěrečnou práci a do systému PARADOX je pak doplněno kompetentní osobou (nejčastěji vedoucím diplomového semináře) datum odevzdání a obhajoby. 38
Studenti pak odevzdávají své práce ve dvou výtiscích na studijní oddělení, které se nachází přímo na VOŠIS. Studenti oboru PIS musejí navíc odevzdat elektronickou podobu práce ve formátu PDF do intranetu VOŠIS. Oponent a vedoucí ukládají do systému posudky prací, aby je mohl vidět student. V případě externího oponenta nebo vedoucího práce uložení zajišťuje studijní referentka naskenováním zaslaného posudku, neboť posudek musí být vždy odevzdán podepsaný v písemné podobě. Pokud oponent nenapíše posudek, musí vedoucí práce zajistit někoho jiného ze školy. Neobhájené práce se vracejí studentovi a nejsou zpřístupněny na internetu. Jeden výtisk obhájené práce je uložen do knihovny VOŠIS a druhý do archivu VOŠIS. Závěrečné práce studentů PIS v papírové formě neputují na VŠE, jsou ale zveřejněny v rámci ISIS VŠE. Současné problémy
Výše popsaný postup zadávání a odevzdávání závěrečných prací je podle jeho účastníků nevyhovující z důvodu chybějícího jednotného rozhraní, které by poskytovalo na jednom místě možnost vykonávat potřebné operace. Současný proces je nesystematický a nepřehledný. Podle vedoucí semináře pro obor PIS představuje problém celý proces výběru tématu práce. Většinou by studenti měli mít vybrané téma do 14 dnů od začátku semestru, kdy si zapsali diplomový seminář. Tento termín však často nedodržují. Vedoucí semináře se pak snaží studenta kontaktovat formou emailu nebo přímo na semináři, ale na některé studenty, kteří navíc nenavštěvují ani seminář, nemá kontakt. Další kritický bod vedoucí semináře shledává v případě neschválení tématu ředitelem, kdy opět nemá mnohdy možnost, jak studenta o tomto kontaktovat.
39
5 Specifikace požadavků 5.1 Úvod 5.1.1 Předmět specifikace Tato specifikace popisuje funkční požadavky první verze (1.0) informačního systému administrace závěrečných prací na Vyšší odborné škole informačních služeb v Praze (dále jen „ISAZP“). Je určena vývojářskému týmu, který bude uvedené požadavky implementovat. ISAZP by měl sloužit zejména studentům oborů realizovaných VOŠIS, vedoucím a oponentům závěrečných prací pro vykonávání jednotlivých činností souvisejících se závěrečnými pracemi od volby tématu, přes zadání, odevzdání k jejímu obhájení. Kromě toho by měl usnadňovat administrativní práce spojené s evidencí závěrečných prací, kterou zajišťuje zejména studijní oddělení, a v neposlední řadě proces schvalování témat a oponentů prací ředitelem VOŠIS. ISAZP by měl sloužit ke snadné komunikaci mezi jednotlivými účastníky formou zabezpečeného přihlášení, respektuje studijní předpisy související se závěrečnými pracemi. 5.1.2 Typografické konvence
Tento dokument vychází ze šablony uvedené ve [Wiegers, 2008].
Pro modelování je preferována notace UML a používán program firmy Sybase PowerDesigner verze 15.
Zkratka
Význam
ISAZP
Informační systém administrace závěrečných prací na VOŠIS
VOŠIS
Vyšší odborná škola informačních služeb
VŠE
Vysoká škola ekonomická
FIS
Fakulta informatiky a statistiky
UK
Univerzita Karlova
FF
Filozofická fakulta
5.1.3 Odkazy Název
Odkaz
Zákony a vyhlášky Školský zákon
http://aplikace.mvcr.cz/archiv2008/sbirka/2004/sb190-04.pdf
Vyhláška o vyšším odborném vzdělávání
http://aplikace.mvcr.cz/archiv2008/sbirka/2005/sb003-05.pdf
Zákon o vysokých školách
http://aplikace.mvcr.cz/archiv2008/sbirka/1998/sb039-98.pdf
Vnitřní předpisy Studijní a zkušební řád VŠE
http://www.vse.cz/predpisy/doc/211_20090722_085125.pdf
Studijní a zkušební řád VOŠIS
http://www.sks.cz/soubory/sturadVOSIS.pdf
Studijní a zkušební řád UK
http://www.cuni.cz/UK-2535-version1-02UKuzVISZRUK.pdf
Opatření děkana FIS VŠE č. 4/2002 Opatření děkana FF UK č. 21/2010
5.2 Obecný popis 5.2.1 Kontext systému ISAZP by měl být součástí intranetu VOŠIS. Jeho funkcionalita by měla být vytvořena na míru požadavkům organizace. Obr. 9 zobrazuje prostředí ISAZP a datové toky mezi externím subjektem a systémem. Tento kontextový diagram tak ukazuje rozsah systému, který musí pojmout všechny klíčové datové a jiné toky. studenti správce sítě závěreč ná práce projekt informace a o schválení tématu zadání tématu
knihovna
přístupová práva
ředitel/děkan
informace o schválení tématu popisné údaje Informač ní systém administrace závěreč ných prací (ISAZP)
zadávací list
témata ke schválení informace o schválení tématu projekt
témata vedoucí a oponenti
vedoucí semináře
posudek závěreč né práce
závěreč ná práce
veřejnost
výsledky obhajoby termíny
informace o uživatelích
VŠE
Novell
studijní oddělení
Obr. 9 Kontext systému ISAZP
41
5.2.2 Funkce systému Základní funkční celky ISAZP znázorňuje diagram na Obr. 10, ze kterého je patrné i rozhraní k jiným systémům. Podrobnější popis jednotlivých požadavků na tyto funkce, které by měly být implementovány je popsán v kapitole 1.1. Rezervace témat však není požadována pro první verzi systému. Systém bude jen zajišťovat funkce pro přidání tématu do statického seznamu vedoucím práce a pro jeho případnou úpravu. Student si témata bude moci prohlížet, avšak není požadováno, aby systém zajišťoval rezervaci tématu přímo v uživatelském rozhraní5.
Obr. 10 Funkční celky ISAZP
Přihlášení uživatele do systému ISAZP by také nemělo být funkcí tohoto systému, ale mělo by být využito současné autentizace prostřednictvím již zavedeného systému Novell. Tomu by měly být poskytnuty pouze informace o udělení přístupových práv uživatelům nebo skupinám uživatelů.
5
Během zjišťování požadavků na budoucí ISAZP prostřednictvím rozhovorů se téměř nevyskytovaly rozpory v požadavcích. Bylo však vyjádřeno přání ze strany vedoucí semináře, aby systém do budoucna umožnil i rezervaci témat. Tomuto požadavku však byla stanovena nižší priorita na základě požadavku od bývalé vedoucí závěrečných prací, které spočívá pouze ve statickém seznamu témat, které vedoucí prací mohou upravovat. Tento požadavek by však neměl být opomenut a měl by být blíže analyzován během vyvíjení dalších verzí systému.
42
V dalších fázích vývoje ISAZP by mělo být modifikováno rozhraní mezi tímto systémem a systémem ISIS VŠE. Zejména by měla být analyzována možnost exportu/importu záznamů a souborů prací do/z ISAZP. 5.2.3 Třídy uživatelů Studenti
Studenti jsou osoby, které jsou řádně na daný akademický či školní rok zapsané ke studiu na některý z oborů realizovaných na VOŠIS. Všichni aktivní studenti VOŠIS a oboru PIS mají přístup do ISAZP, do něhož se přihlašují prostřednictvím aplikace Novellu. Někteří z nich mohou vypracovávat závěrečnou práci podruhé, příp. potřetí v případě neúspěchu při obhajobě. Vedoucí semináře
Vedoucí semináře je osoba, která vede v daném školním roce diplomový seminář. Každý studijní obor má stanoveného vedoucího tohoto semináře, proto této role může nabývat v daný okamžik více osob, ale vždy jedna by měla být zodpovědná za daný obor. Vedoucí práce
Vedoucí práce je pedagogický zaměstnanec školy, který vede nebo dříve vedl některou závěrečnou práci. Nabízí témata studentům, formuluje s nimi zadání práce, které pak tiskne pro potřeby podpisu ředitelem školy. Dále volí oponenta pro své vedené práce. Oponenti práce
Oponentem práce je vysokoškolsky vzdělaný odborník, kterého volí vedoucí práce a schvaluje ředitel VOŠIS. Je povinen vyhotovit posudek práce. Ředitel VOŠIS
Ředitel VOŠIS hraje rozhodovací roli, co se týče závěrečných prací. Schvaluje témata, podepisuje zadání a schvaluje oponenta prací. Studijní referentky
Studijní referentka zajišťuje administrativní práce závěrečných prací. Informuje o termínech odevzdávání závěrečných prací a zapisuje výsledky obhajoby.
43
Knihovnice
Knihovnice využívá výstup z ISAZP, který mu však poskytne studijní referentka. Není tedy přímým uživatelem systému. Tento výstup používá ke katalogizaci závěrečných prací. Správce sítě
Správce sítě zajišťuje bezpečnost přihlášení, ochranu a zálohování dat a řeší případné výpadky systému nebo problémy uživatelů. Zajišťuje tak spíše mimofunkční požadavky. 5.2.4 Provozní prostředí, omezení návrhu a implementace
Správu uživatelů a jejich přihlašování bude zajišťovat Novell.
Systém by měl být naprogramován v PHP, aby byl kompatibilní s ostatními součástmi intranetu VOŠIS.
Systém musí fungovat na serveru Apache.
Systém by měl být přístupný přes webové rozhraní a část by měla být přístupna veřejnosti.
Závěrečné práce, projekty, zadání, posudky musejí být ukládány do školní databáze.
44
5.3 Funkční požadavky Funkční požadavky na systém jsou vyjádřeny prostřednictvím případů užití (viz Obr. 11) a popsány v následujícím textu.
ISAZP
zápis obhajoby uložení projektu
studijní referentka
nastavení termínů
prohlížení posudku
student
uložení seznamu prací
vedoucí semináře prohlížení témat
student VOŠIS
student PIS
vložení práce
formulace zadání
sledování stavu
ředitel prohlížení projektů
schvalování tématu
vedoucí práce
sledování témat schvalování oponenta
vložení posudku
vložení jména oponenta
tisk zadání
stažení souborů práce
Obr. 11 Případy užití systému ISAZP (funkce systému)
oponent práce
Hlavní aktér Student
Vedoucí práce
Oponent Ředitel Vedoucí semináře Studijní referentka
Případ užití PU-1 Prohlížení témat PU-2 Uložení projektu PU-4 Vložení práce PU-5 Prohlížení posudku PU-17 Sledování stavu PU-6 Správa témat PU-3 Formulace zadání PU-7 Vložení jména oponenta PU-8 Tisk zadání PU-9 Vložení posudku PU-10 Stažení souborů práce PU-11 Prohlížení projektů PU-17 Sledování stavu PU-9 Vložení posudku PU-10 Stažení souborů práce PU-12 Schvalování zadání PU-13 Schvalování oponenta PU-1 Prohlížení témat PU-11 Prohlížení projektů PU-17 Sledování stavu PU-14 Zápis obhajoby PU-15 Nastavování termínů PU-16 Uložení seznamu prací
5.3.1 PU-1 Prohlížení témat Aktéři: Popis:
Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Student Vedoucí semináře Student a vedoucí semináře si mohou prohlížet nabízená témata závěrečných prací. Mohou si je třídit podle vedoucího a vhodnosti pro obor. Vedoucí semináře by navíc měl vidět i informaci o přiřazení tématu danému studentovi. Uživatel musí být přihlášen do ISAZP Seznam navržených témat a) Student Student si prohlíží navrhovaná témata. V případě zájmu o některé z nich si jej rozklikne pro více podrobností. Pokud se student pro téma rozhodne, kontaktuje elektronicky nebo jinou (nejčastěji osobní) cestou příslušného vedoucího práce. b) Vedoucí semináře Vedoucí semináře si prohlíží navrhovaná témata. žádné
5.3.1 PU-2 Uložení projektu Aktéři: Popis: Vstupní podmínky:
Výstup: Běžná cesta:
Výjimky:
Student Student ukládá svůj projekt k závěrečné práci do ISAZP ve standardním formátu PDF. Student musí být přihlášen do ISAZP. Student má domluvené téma s vedoucím závěrečné práce a byl seznámen s obsahem projektu k závěrečné práci na semináři. Projekt k závěrečné práci Student po přihlášení do systému si rozklikne menu, kde má k dispozici administraci své práce, příp. prací. Přes souborového klienta nahraje ze svého umístění projekt ve formátu PDF a zadá svůj kontaktní email (pro potřeby vedoucího semináře). Systém studentovi ohlásí úspěšné nahrání dokumentu. Dokument po uložení do systému může student změnit do 24 hodin, poté je již dostupný ostatním uživatelům k prohlížení. Systém studenta upozorní, že ukládá dokument v nesprávném formátu či že dokument přesahuje max. velikost dokumentu a že dokument tak nebude uložen.
5.3.2 PU-3 Formulace zadání Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Vedoucí práce Vedoucí práce vyplňuje formulář týkající se názvu a cílů závěrečné práce. Vedoucí práce musí být přihlášen do ISAZP. Student požádal svého vedoucího práce o vytvoření zadání a konzultoval s ním cíle své práce. Zadání práce Vedoucí práce v systému vyplní formulář zadávacího listu práce. Některé údaje systém předvyplní (jméno studenta, škola a adresa, datum zadání, termín odevzdání), další údaje (téma, cíl) musí vyplnit vedoucí práce sám. Po vyplnění formuláře vedoucí práce klikne na tlačítko „poslat ke schválení“ a tím odešle požadavek ke schválení ředitelovi/děkanovi. Student si po odeslání může sledovat stav vyřízení svého požadavku na schválení. žádné
47
5.3.3 PU-4 Vložení práce Aktéři: Popis: Vstupní podmínky:
Výstup: Běžná cesta:
Výjimky:
Student Student ukládá svou závěrečnou práci v elektronické podobě do systému v okamžiku přihlášení k obhajobě. Student musí být přihlášen do IAZP. Student musí mít ředitelem schválené téma. Student musí ukládat závěrečnou práci před termínem pro odevzdání. Student musí mít soubor se svou závěrečnou prací ve formátu PDF. Závěrečná práce s přílohami Student po přihlášení do systému vstoupí do administrace své závěrečné práce. Systém mu nabídne v menu možnost uložení závěrečné práce. Po kliknutí na tuto volbu se studentovi zobrazí předvyplněný formulář. Student údaje zkontroluje a doplní ty, které chybí (klíčová slova, abstrakt apod.). Vloží svou práci ve formátu PDF, příp. přílohy. Poté, když si je jist, že vše je správně vyplněno, klikne na tlačítko pro uložení práce. Systém zobrazí studentovi zprávu, že uložení proběhlo úspěšně. V případě neúspěšného uložení systém nabídne studentovi řešení v podobě kontaktování správce či v podobě zobrazení důvodu neuložení. V případě, že student údaje omylem chybně vyplnil či uložil nesprávný dokument, musí kontaktovat studijní oddělení, které zajistí opravu.
5.3.4 PU-5 Prohlížení posudku Aktéři: Popis:
Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Student, příp. ostatní uživatelé Student se může seznámit s posudky své práce prostřednictvím IAZP. Posudky si mohou prohlížet i jiní uživatelé systému (vedoucí semináře, vedoucí závěrečné práce, ředitel apod.). Student musí být přihlášen do IAZP. Vedoucí a oponent práce musí vložit svůj posudek do ISAZP nejméně 3 pracovní dny před konáním obhajoby. Posudek oponenta/vedoucího práce Student po přihlášení do systému zvolí administraci své závěrečné práce. U své závěrečné práce uvidí připojené posudky. Posudky si může stáhnout na svůj disk nebo si je vytisknout. žádné 48
5.3.5 PU-6 Správa témat Aktéři: Popis: Vstupní podmínky: Výstup:
Běžná cesta:
Výjimky:
Vedoucí práce Vedoucí práce spravuje svá témata závěrečných prací. Může přidávat nová, zneaktivnit neaktuální a editovat již nabízená témata. Vedoucí musí být přihlášen do ISAZP. Nové téma Modifikované téma Zrušené téma Seznam témat (nabízených, schválených, neschválených) Vedoucí práce po přihlášení do systému si zobrazí seznam svých témat, u kterých bude mít možnost editace. Po rozkliknutí příslušného tématu jej může podrobněji specifikovat, příp. zneaktivnit. Bude mít k dispozici pole u každého tématu, kde si bude moci psát poznámky – např. kdo si již téma zarezervoval, případné modifikace tématu apod. Pokud bude chtít vedoucí přidat nové téma, klikne na patřičné tlačítko ve správě svých závěrečných prací a nabídne se mu dialogové okno. Vyplní název tématu, podrobnější popis a příp. určení cílové skupiny studentů, kterým je téma určeno. žádné
5.3.6 PU-7 Vložení jména oponenta Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Vedoucí práce Vedoucí práce doplní oponenta práce (většinou po odevzdání práce nebo před obhajobou) ze seznamu a odešle požadavek ke schválení ředitelovi. Vedoucí práce musí být přihlášen do ISAZP. Student musí mít odevzdaný projekt závěrečné práce. Student musí mít schválené téma. žádný Vedoucí po přihlášení si zobrazí v menu závěrečné práce, které aktuálně vede. U příslušné závěrečné práce klikne na tlačítko „zadávací list“. Zadávací list doplní o jméno oponenta a odešle jej ředitelovi ke schválení. Pokud oponent práce není nabídnut v seznamu oponentů, musí vedoucí práce kontaktovat administrátora, aby jej vložil, nebo zadá jen jeho jméno s tituly.
49
5.3.7 PU-8 Tisk zadání Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Vedoucí práce Vedoucí práce schválený zadávací list vytiskne a předá na podpis ředitelovi. Ten pak vkládá student do své závěrečné práce. Vedoucí práce musí být přihlášen do ISAZP. Student musí mít odevzdaný projekt závěrečné práce. Student musí mít schválené téma. Zadání práce určené k podpisu Vedoucí práce po přihlášení si zobrazí v menu závěrečné práce, které aktuálně vede. U příslušné závěrečné práce klikne na tlačítko „zadávací list“. Vedoucí práce zkontroluje a případně doplní údaje. Formulář uzavře a vytiskne. žádné
5.3.8 PU-9 Vložení posudku Aktéři: Popis:
Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Vedoucí práce, Oponent práce Oponent a vedoucí práce vyhotovují na odevzdanou práci písemný posudek, jenž musí obsahovat navrhovanou klasifikaci práce. Tento posudek bude vyplňován přímo v ISAZP, odkud si jej pak oponent/vedoucí vytisknou, podepíší a odevzdají na studijní oddělení nejméně 3 pracovní dny před konáním obhajoby. Vedoucí/oponent práce musí být přihlášen do ISAZP. Student odevzdal práci ve stanoveném termínu. Posudek práce Vedoucí/oponent práce se po přihlášení do systému přesune do menu se závěrečnými pracemi, které vede nebo jejichž je oponentem. Po kliknutí na příslušnou práci si zobrazí její detail. Bude mít k dispozici tlačítko pro uložení posudku do systému. Vybere dokument ve formátu PDF či DOC/DOCX a dokument uloží, nebo využije formuláře, ve kterém potřebné údaje vyplní. Systém oznámí vedoucímu/oponentovi práce, že proběhlo uložení úspěšně. V případě neúspěšného uložení posudku systém nabídne kontakt na správce systému, příp. oznámí důvod chyby. V případě, že bude složité pro oponenta (zejména externího) do systému soubor uložit, postará se o to vedoucí práce nebo studijní oddělení. 50
5.3.9 PU-10 Stažení souborů práce Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Vedoucí práce, Oponent práce Vedoucí práce nebo oponent práce si stáhnou soubory práce. Vedoucí/oponent práce musí být přihlášen do ISAZP. Student odevzdal práci ve stanovený termín. žádný Vedoucí/oponent práce si může po přihlášení do systému stáhnout soubory závěrečné práce, kterou vede/vedl. To zahrnuje i přílohy a zobrazení dalších metadat, které student při ukládání doplnil. žádné
5.3.10 PU-11 Prohlížení projektů Aktéři: Popis: Vstupní podmínky:
Výstup: Běžná cesta:
Výjimky:
Vedoucí semináře, Vedoucí práce Vedoucí semináře nebo práce si může prohlížet jednotlivé projekty k závěrečným pracím pomocí stažení v uloženém formátu. Vedoucí semináře/práce musí být přihlášen do ISAZP. Student uložil příslušný projekt k závěrečné práci do ISAZP. Student má schválené téma. Přehled o projektech k závěrečným pracím Vedoucí semináře/práce po přihlášení do systému si může zobrazit závěrečné práce svého okruhu studentů. Vedoucí semináře/práce po rozkliknutí příslušné závěrečné práce může otevřít, stáhnout nebo si vytisknout projekt k závěrečné práci. žádné
51
5.3.11 PU-12 Schvalování tématu Aktéři: Popis: Vstupní podmínky: Výstup:
Běžná cesta:
Výjimky:
Ředitel Ředitel schvaluje téma závěrečné práce. Ředitel musí být přihlášen do ISAZP. Vedoucí práce vyplnila zadávací formulář. Schválené/zamítnuté téma Student obdrží informaci, zda je jeho téma schváleno či zamítnuto. O této informaci se může dozvědět i vedoucí závěrečné práce a vedoucí semináře. Ředitel po přihlášení do systému bude moci zobrazit seznam témat ke schválení. Ředitel může zaškrtnout jednotlivá témata a hromadně je schválit/zamítnout pomocí tlačítka. U každého tématu, ať schváleného nebo zamítnutého, může připojit poznámku (důvod zamítnutí, návrh na modifikaci názvu apod.). žádné
5.3.12 PU-13 Schvalování oponenta Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Ředitel Ředitel schvaluje oponenta závěrečné práce. Ředitel musí být přihlášen do ISAZP. Vedoucí práce předložil ke schválení jméno oponenta. Schválený/zamítnutý oponent Ředitel po přihlášení do systému bude moci zobrazit seznam prací, které čekají na schválení oponenta. Ředitel může zaškrtnout hromadně více prací a schválit/neschválit u nich oponenta, příp. může mít zapnutou funkci automatického schvalování oponentů. žádné
52
5.3.13 PU-14 Zápis obhajoby Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Studijní referentka Studijní referentka zapisuje výsledek obhajoby příslušné závěrečné práce do ISAZP. Studijní referentka musí být přihlášena do ISAZP. Student je přihlášen k obhajobě příslušné závěrečné práce. Obhajoba již proběhla. Doplněné údaje o obhajobě (výsledek, datum apod.) Studijní referentka se po přihlášení do ISAZP přesune do menu se závěrečnými pracemi, které byly odevzdány a zatím neohodnoceny. Připojí k příslušné závěrečné práci hodnocení a další údaje a tím ji uzavře. žádné
5.3.14 PU-15 Nastavování termínů Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Studijní referentka Studijní referentka nastavuje časové údaje do ISAZP týkající se závěrečných prací (zejména termín odevzdání a datum obhajoby). Studijní referentka musí být přihlášena do ISAZP. Nastavení termínů, které slouží pro řízení procesů v systému. Studijní referentka se po přihlášení do systému přesune do správy termínů. Zadá nový termín s údaji o datu, předmětu termínu a druhu termínu (pro koho je určen apod.), příp. změní již zadaný termín, pokud ještě neproběhl. žádné
53
5.3.15 PU-16 Uložení seznamu prací Aktéři: Popis: Vstupní podmínky: Výstup: Běžná cesta:
Výjimky:
Studijní referentka Studijní referentka tiskne seznam obhájených závěrečných prací. Studijní referentka musí být přihlášena do ISAZP. Všechny závěrečné práce pro dané období jsou uzavřené. Seznam závěrečných prací (obhájených/neobhájených) Studijní referentka se po přihlášení do systému přesune na uzavřené práce a uloží, příp. vytiskne seznam (obhájených/neobhájených/všech) prací. Ten pak předá knihovnici, která jej použije pro účely uložení prací do knihovny (přírůstkový seznam, identifikační a věcný popis). žádné
5.3.1 PU-17 Sledování stavu Aktéři:
Popis: Vstupní podmínky: Výstup: Běžná cesta: Výjimky:
Student Vedoucí práce Vedoucí semináře Student, vedoucí práce a vedoucí semináře mohou sledovat průchod stavy závěrečné práce (od výběru tématu po odevzdání). Uživatelé musejí být přihlášení do ISAZP. žádný Uživatel se po přihlášení do systému přesune do nabídky pro sledování stavu závěrečných prací. žádné
54
Dodatek: Stavový diagram [zvolené téma, kontaktování vedoucího]
vybraná
[nové téma] [neschválené téma]
[schválené téma]
nezadaná zadaná
vypracovaná
[doplněna metadata, vloženo PDF] [nové téma]
odevzdaná
[přepracování] [vyhovění u obhajoby] obhájená
[překroč ení č asové lhůty]
[nevyhovění u obhajoby]
neobhájená
archivovaná
55
6 Závěr Cílem této bakalářské práce bylo zpracovat dokument specifikace požadavků na informační systém administrace závěrečných prací na VOŠIS, zdokumentovat použité postupy a zdůvodnit volbu metodiky. Dokument specifikace požadavků byl vypracován a tvoří kapitolu 1 této práce, přičemž použité metody a postup jsou komentovány v kapitole 4. Cíle se tedy podařilo naplnit, přičemž některé počáteční hypotézy nebyly potvrzeny. Pro získání potřebných informací o požadavcích totiž dostačovalo použití metody analýzy dokumentů, stávajících systémů a dotazování se uživatelů formou rozhovorů. Skupinové sezení nebylo nutné uskutečnit, protože si požadavky navzájem neodporovaly, aby musely být komunikovány mezi zainteresovanými osobami. Jelikož uživatelé dokázali vyjádřit své požadavky jasně, nebylo ani nutné vytvářet částečné řešení v podobě prototypu či uskutečnit dotazníkové šetření. Navíc tento problém již řeší některé systémy škol a tak bylo možno odvodit některé požadavky přímo na základě studia manuálů těchto systémů. Konkrétní specifika organizace však bylo potřeba zapracovat a k tomu dopomohlo studium interních předpisů a požadavky vyplývající s rozhovorů. Hypotéza týkající se analýzy požadavků však byla potvrzena v plném rozsahu. Modelování velmi dopomohlo odvodit konkrétní požadavky na funkce, procesy, činnosti a struktury dat. Při fázi dokumentování požadavků byla použita šablona [Wiegers, 2008], která však byla modifikována. Zejména část s funkčními požadavky se odchýlila od struktury této šablony. Vyhovovalo popsat jednotlivé funkční požadavky prostřednictvím případů užití. Mimofunkční požadavky dokument téměř neobsahuje. Jejich zjišťování, analýzy a specifikace přesahuje rozsah této práce, ale do budoucna by se s nimi mělo počítat. Závěrem lze tedy říci, že dokument se specifikací požadavků na ISAZP by mohl být použit k implementaci vybraných funkcí, které by v průběhu času měly být modifikovány a upravovány dle konkrétních potřeb a možností.
7 Seznam použité literatury
Autorský zákon. 2006. Česká republika. Úplné znění zákona č. 121 /2000 Sb., o právu 9autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). In Sbírka zákonů ČR. 398/2006, částka 126, s. 5506-5543. Dostupný také z WWW: .
BOLDIŠ, Petr. 2004. Bibliografické citace dokumentů podle ČSN ISO 690 a ČSN ISO 690-2: Část 2 – Modely a příklady citací u jednotlivých typů dokumentů. Verze 3.0 (2004). c 1999–2004, [cit. 08.08.2011]. Poslední aktualizace 11. 11. 2004. Dostupné z WWW: .
CELBOVÁ, Iva. 1999. Úvod do problematiky expertních systémů. Ikaros [online]. 1999, roč. 3, č. 8 [cit. 09. 04. 2011]. Dostupné z WWW: . URN-NBN:cz-ik393. ISSN 1212-5075.
DAVEY, Bill; COPE, Chris. 2008. Requirements Elicitation: What’s Missing? 2008. Issues in Informing Science and Information Technology [online]. 2008, vol. 5 [cit. 14. 06. 2010], 9 s. Dostupné z WWW: .
GOGUEN, Joseph A.; LINDE, Charlotte. 1993. Techniques for Requirements Elicitation. In Proceedings of IEEE International Symposium on Requirements Engineering ’93. IEEE Computer Society, 1993 [cit. 06. 04. 2011], s. 152-164. Dostupné z WWW: .
GREGAROVÁ, Magda. 2010. Zpracování bakalářských prací : metodická příručka. Upravila a aktualizovala Ing. Martina Juříková, Ph.D.. Zlín : Univerzita Tomáše Bati, 2010. 15 s.
HAKALOVÁ, Jana. 2008. Příprava na bakalářskou práci [online]. 2008 : http://www.vsporadenstvi.cz/cs/node/5 [cit. 2011-06-20]. Dostupné z WWW: .
HAM, Gary A. 1998. 1998. Four Roads to Use Case Discovery : There Is a Use (and a Case) for Each One [online]. Arlington (Virginia, USA) : Battelle Memorial Institute, 1998 [cit. 2011-02-23]. Dostupné z WWW:
57
stds.org/Document-library/Projects/11179-Terminology-studyarea/Use%20Case%20Related/ham.html>.
HULL, Elizabeth; JACKSON, Ken; DICK, Jeremy.
2005. Requirements
Engineering. 2nd ed. London; Berlin; Heidelberg: Springer, 2005. 198 s. ISBN 185233-879-2.
KENDALL, Kenneth E.; KENDALL, Julie E. 2002. Systems analysis and design. 5th ed. New Jersey: Prentice Hall, 2002. 752 s. ISBN 978-0131454552.
KOPŘIVA, Petr. 2010. Pro šťastné vykročení (do projektu) : Nástroje pro evidenci a analýzu požadavků [online]. Praha : Komix, c2010 [cit. 14. 03. 2011]. Dostupné z WWW: .
KOTONYA, Gerald; SOMMERVILLE, Ian. 1998. Requirements engineering : processes and techniques. 1. vyd. [s.l.] : Wiley, 1998. 294 s. ISBN 978-0471972082.
KUČEROVÁ, Helena. 2009. Diplomový seminář 2009/2010 pro specializaci Podnikové informační systémy [online]. Praha : Vyšší odborná škola informačních služeb, [2009], [cit. 06. 01. 2011]. Datum poslední aktualizace 14. 5. 2010. Dostupné z WWW: .
LAUESEN, S. 2003. Task descriptions as functional requirements. IEEE Software : building the community of leading software practitioners [online]. Mar/Apr 2003, 2, [cit. 2010-09-21], s. 58-65. Dostupný komerčně z WWW: . ISSN 0740-7459.
MACAULAY, Linda A. 1996. Requirements engineering. Londýn (Velká Británie) : Springer-Verlag, 1996. 202 s. ISBN 3-540-76006-7.
MAIDEN, Neil. 2008. User Requirements and System Requirements. IEEE Software [online]. 2008, vol. 25, no. 2 [cit. 23.3.2010], s. 90-91. Dostupné komerčně z ACM: . ISSN 0740-7459.
MUNI. 200?. Informační systém Masarykovy univerzity: nápověda [online]. Brno: Masarykova univerzita, [200?] [cit. 16. 3. 2011]. Dostupné z WWW: .
NUSEIBEH, Bashar; EASTERBROOK, Steve. 2000. Requirements engineering : a roadmap. In IEEE. Proceedings of the Conference on The Future of Software Engineering [online]. New York, USA : ACM, 2000 [cit. 2010-07-12]. Dostupné z WWW: . ISBN 1-58113-253-0.
IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specifications. 1998 : IEEE, 1998. 31 s. ISSN 0-7381-0332-2.
58
IEEE Std 610.121:1990. Standard glossary of software engineering terminology. New York: Institute of Electrical and Electronics Engineers, 1990. 63 s. ISBN 155937-067-X.
PFLEEGER, Shari Lawrence; ATLEE, Joanne M. 2006. Software engineering: theory and practice. 3rd ed. Upper Saddle River (NJ, USA): Prentice Hall, 2006. 736 s. ISBN 0-13-146913-4.
ROBERTSON, Suzanne; ROBERTSON, James. 2006. Mastering the requirements process. 2nd ed. Upper Saddle River, NJ: Addison-Wesley, 2006. 560 s. ISBN 0321419499.
SOMMERVILLE, Ian. 2007. Software engineering. 8th ed. Essex: Addison-Wesley, 2007. 840 s. ISBN 978-0-321-31379-9.
Standish Group. 1994. The CHAOS Report [online]. 1994, 10-Oct-00 14:35. [cit. 03. 11. 2010], 10 s. Dostupné z WWW: .
SVITALSKÁ, Jana. 2010. Metody získávání požadavků na podnikový informační systém: přehled a srovnání s výzkumem potřeb zákazníků = Requirements elicitation: techniques and comparison with customer needs survey. Praha, 3. 8. 2010. 73 s., 2 s. příl. Bakalářská práce (Bc.). Univerzita Karlova v Praze, Filozofická fakulta, Ústav informačních studií a knihovnictví. Vedoucí bakalářské práce PhDr. Helena Kučerová.
SYNEK, Miloslav; SEDLÁČKOVÁ, Helena; VÁVROVÁ, Hana. 2002. Jak psát diplomové a jiné písemné práce [online]. Praha : Vysoká škola ekonomická, 2002 [cit. 2011-07-12], 49 s. Dostupné z WWW: .
Školský zákon. 2004. Česká republika. Zákon č. 561/2004 Sb. ze dne 24. září 2004, o předškolním, základním, středním, vyšším odborném a jiném vzdělávání (školský zákon). In Sbírka zákonů. Ročník 2004, částka 190, č. 561, s. 10262-10324. Dostupný také z WWW: . ISSN 1211-1244.
TDKIV. 2003. KTD: Česká terminologická databáze knihovnictví a informační vědy (TDKIV) [online]. Praha: Národní knihovna České republiky, 2003 [cit. 03. 04. 2011]. Dostupné z WWW: .
ÚISK. 2010. Přijímací řízení ÚISK na šk. rok 2011/2012 [online]. Praha: Ústav informačních studií a knihovnictví FF UK, 2010 [cit. 4.8.2010]. Dostupné z WWW: .
59
UK. 2010. Opatření děkana Filozofické fakulty Univerzity Karlovy č. 21/2010 : pravidla pro evidenci, odevzdávání a zveřejňování závěrečných prací [online]. Praha: Univerzita Karlova, 2010 [cit. 1. 4. 2011]. Dostupné z WWW: .
UK. 2008. Studijní informační systém (SIS) FF UK [online]. Praha: Univerzita Karlova, c2008 [cit. 6. 2. 2011]. Poslední aktualizace: 19.08.2011. Dostupné z WWW: .
Ústav pro informace ve vzdělávání. 2010. Schéma vzdělávacího systému České republiky ve školním / akademickém roce 20010/2011 [online]. 2010 [cit. 2011-0522]. Dostupné z WWW:< http://www.icm.cz/files/CZSchema%2020102011%20CZ.pdf>.
VOŠIS. 2011. Vyšší odborná škola informačních služeb [online]. Praha : 2011 [cit. 2010-10-05]. Hlavní stránka školy. Dostupné z WWW: .
VOŠIS. 2009. Studijní a zkušební řád VOŠIS. Praha : Vyšší odborná škola informačních
služeb,
2009.
Dostupné
také
z WWW:
.
VŠE. 2011. Dokumentace ISIS [online]. Praha: Vysoká škola ekonomická, c2011 [cit. 8. 8. 2010]. Dostupné z WWW: .
VŠE. 2009. Studijní a zkušební řád VŠE v Praze pro studium v bakalářských a magisterských studijních programech (ECTS) ze dne 7. července 2009. 2009. Dostupný také z WWW: .
VŠE. 2002. Opatření děkana Fakulty informatiky a statistiky VŠE č. 4/2002 ze dne 10. 9. 2002. Praha : Vyšší odborná škola informačních služeb, 2002.
Vyhláška o vyšším odborném vzdělávání. 2004. Česká republika.Vyhláška ze dne 27. prosince 2004, o vyšším odborném vzdělávání. In Sbírka zákonů. Ročník 2004, částka 3, č. 10, s. 38-43. Dostupný také z WWW: . ISSN 1211-1244.
WESTFALL, Linda. 2005. Software Requirements Engineering: What, Why, Who, When and How. Software Quality Professional [online] 2005, vol. 7, no. 4 [cit. 24.11.2010], s. 17-26. Dostupné komerčně z ACM: .
WIEGERS, Karl E. 2008. Požadavky na software : od zadání k architektuře aplikace. Překlad Tomáš Znamenáček. Vyd. 1. Brno : Computer Press, 2008. 448 s. ISBN 978-80-251-1877-1.
60
WIEGERS, Karl E. 2001. Karl Wiegers Describes 10 Requirements Traps to Avoid [online]. 2001 [cit. 23. 2. 2010]. Dostupné z WWW: .
WIEGERS, Karl E. 2000. When Telepathy Won’t Do : Requirements Engineering Key Practices. Cutter IT Journal [online]. May 2000, roč. 5, č.13, [cit. 2010-11-04]. Dostupný z WWW:< http://www.processimpact.com/articles/telepathy.pdf>. ISSN 1522-7383.
WIEGERS, Karl E. Inspection Checklist for Software Requirements Specifications [online]. [s.l.] : Process Impact, 1999 [cit. 2011-07-11]. Dostupné z WWW: <www.processimpact.com/process_assets/requirements_review_checklist.doc>.
Zákon o vysokých školách. 1998. Česká republika. Zákon ze dne 22. dubna 1998, o vysokých školách a o změně doplnění dalších zákonů (zákon o vysokých školách). In Sbírka zákonů. Ročník 1998, částka 39, č. 111, s. 5388-5419. Dostupný také z WWW:
.
ISSN
1211-1244.
ZČU. 2009. IS/STAG Helpcentrum: kvalifikační práce [online]. [Plzeň]: Západočeská univerzita, c2009 [cit. 8. 11. 2010]. Dostupné z WWW:
ZOWGHI, Didar; COULIN, Chad. 2005. Requirements elicitation: a survey of techniques, approaches and tools. In Aurum, A.; Wohlin, C. Engineering and managing software requirements. 1st ed. 2,. Berlin; Heidelberg: Springer, 2005. 1946 s. ISBN 978-3-540-25043-2.
ZHOU, Jun Ying. 2004. A major report in the department of computer science. Montreal (Quebec, Kanada) : National Library of Canada, April 2004. 49 s. Dizertační práce. Concordia University. ISBN 0-612-91163-2.
61
8 Seznam obrázků Obr. 1 Rozdělení požadavků, upraveno podle [Wiegers, 2008] ............................................................12 Obr. 2 Vztah mezi vývojem a správou požadavků, upraveno podle [Wiegers, 2008] ............................13 Obr. 3 Terciární vzdělávání, upraveno dle [Ústav pro informace ve vzdělávání, 2010] .........................21 Obr. 4 Základní činnosti probíhající v procesu závěrečných prací, převzato z [Kučerová, 2009] ............24 Obr. 5 Případy užití – student ...............................................................................................................33 Obr. 6 Případy užití - vedoucí a oponent práce, vedoucí ústavu ...........................................................34 Obr. 7 Případy užití - studijní referentka a knihovnice ..........................................................................35 Obr. 8 Konceptuální model ISAZP .........................................................................................................36 Obr. 9 Kontext systému ISAZP ..............................................................................................................41 Obr. 10 Funkční celky ISAZP .................................................................................................................42 Obr. 11 Případy užití systému ISAZP (funkce systému) .........................................................................45
9 Seznam zkratek FIS VŠE
Fakulta informatiky a statistiky Vysoké školy ekonomické
FF UK
Filozofická fakulta Univerzity Karlovy
INSK
Informační studia a knihovnictví (bakalářský studijní obor)
IS
Informační systém
IS MUNI
Informační systém Masarykovy univerzity v Brně
IS/STAG ZČU
Informační systém studijní agendy Západočeské univerzity v Plzni
ISAZP
Informační systém administrace závěrečných prací
ISIS VŠE
Integrovaný studijní informační systém Vysoké školy ekonomické
PIS
Podnikové informační systémy (bakalářský studijní obor)
SIS UK
Studijní informační systém Univerzity Karlovy
ÚISK
Ústav informačních studií a knihovnictví FF UK
UK
Univerzita Karlova
VOŠ
Vyšší odborná škola (obecný termín)
VOŠIS
Vyšší odborná škola informačních služeb v Praze
VŠ
Vysoká škola (obecný termín)
VŠE
Vysoká škola ekonomická v Praze
ZČU
Západočeská univerzita v Plzni
62
