TECHNICKÁ UNIVERZITA V LIBERCI
Fakulta mechatroniky, informatiky a mezioborových studií
Studijní program: N 2612 - Elektrotechnika a informatika Studijní obor: 1802T007 - Informační technologie
RUP v návrhu nového e-learningového portálu pro TUL RUP in new e-lerning portal concept for TUL
DIPLOMOVÁ PRÁCE
Autor práce: Bc. Lukáš Vít
Vedoucí práce: RNDr. Klára Císařová, Ph.D
V Liberci dne
TECHNICKÁ UNIVERZITA V LIBERCI
Fakulta mechatroniky a mezioborových inženýrských studií
Ústav mechatroniky a technické informatiky Akademický rok: 2008/09
ZADÁNÍ DIPLOMOVÉ PRÁCE
Jméno a příjmení:
Lukáš Vít
studijní program: N 2612 - Elektrotechnika a informatika
obor: 1802T007 - Informační technologie
Vedoucí ústavu Vám ve smyslu zákona o vysokých školách č.111/1998 Sb.
určuje tuto diplomovou práci:
Název tématu:
RUP v návrhu nového e-learningového portálu pro TUL
Zásady pro vypracování:
1. Seznamte se a prostudujte OO technologie tvorby a návrhu IS.
2. Technologii RUP – Rational Unified Process zpracujte do několika e-learningových lekcí.
3. Navrhněte nový „inteligentní“ e-learningový portál pro univerzitní prostředí – zaměřte se na fázi incepční a fázi elaborační.
4. Porovnejte proces vzniku IS technikou extrémního programování s postupem RUP.
Rozsah grafických prací: dle potřeby dokumentace
Prohlášení
Byl(a) jsem seznámen(a) s tím, že na mou diplomovou práci se plně vztahuje zákon č.121/2000 o právu autorském, zejména § 60 (školní dílo).
Beru na vědomí, že TUL má právo na uzavření licenční smlouvy o užití mé diplomové práce, a prohlašuji, že s o u h l a s í m s případným užitím mé diplomové práce (prodej, zapůjčení apod.).
Jsem si vědom(a) toho, že užít své diplomové práce či poskytnout licenci k jejímu využití mohu jen se souhlasem TUL, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených univerzitou na vytvoření díla (až do jejich skutečné výše).
Diplomovou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.
Datum:
Podpis:
Poděkování
Na tomto místě bych rád poděkoval vedoucí diplomové práce, konzultantovi a celé katedře za rady a připomínky a za celkově velmi kladný profesní i lidský přístup. Dále bych rád poděkoval manželce za podporu.
Anotace
Tato diplomová práce se zabývá návrhem e-learningového portálu pro Technickou univerzitu v Liberci s využitím metodiky Rational Unified Process.
Práce je součástí aktivit akademických pracovníků, kteří usilují o zkvalitnění e-learningových možností na FM. E-learningové technologie provozuje TUL několik let, a proto je v tuto chvíli k dispozici dostatek zkušeností, připomínek i žádostí směřujících k funkčosti této technologie. Návrh by měl stát na důkladné analýze, aby reflexe uživatelských nároků byla provedena systematicky a vznikající produkt byl robustní, odolný v čase (přiměřeně světu informačních technologíí) a aby byl postaven na moderních principech návrhu softwarových produktů.
V úvodní fázi seznamuje práce s metodikou Rational Unified Process a porovnává ji se zástupcem agilních metodik, vybraná je metodika Extrémního programování. Stežejní částí práce je analýza a samotný návrh. V práci jsou shromážděny požadavky na systém a uživatele. V rámci prvních dvou fází vývoje, fáze incepční a fáze elaborační, je navržena funkcionalita a architektura systému s využitím UML diagramů, je určen plán a rizika vývoje.
Výstup této práce bude použit jako vstup pro další fáze vývoje systému.
Klíčová slova
Návrh a analýza softwaru, e-learning, Rational Unified Process, Extrémní Programování, UML diagramy.
Abstract
This diploma thesis deals with the design of the e-learning portal for the Technical University in Liberec using the Rational Unified Process methodology.
The thesis has been worked out as an integral part of the activities of the academic personnel aimed at the enhancement of e-learning opportunities at the Faculty of Mechatronics. The Technical University in Liberec has been utilizing e- learning technology for a number of years, and nowadays there is a sufficient amount of experience, comments and requests concerning the functionality of this technology available there. The design should be based on a thorough analysis so that user requirements are reflected systematically and the product under development is robust, resistant in time (appropriately to the IT world) and based on the modern principles of software product design.
The introductory section of the thesis outlines the Rational Unified Process methodology and compares it to the Extreme Programming methodology as the chosen representative of agile methodologies. The core section of the thesis includes the analysis and the design itself. The thesis summarises system and user requirements. The functionality and the architecture of the system has been designed using UML graphs, the plan has been established and development risks specified within the first two development phases – the inception phase and the elaboration phase. The output of this thesis will be used as the input for the next system development phases.
Keywords
Software design and analysis, e-learning, Rational Unified Process, Extreme Programming, UML diagrams.
Obsah
Poděkování...4
Seznam použitých zkratek a výrazů...12
Úvod...13
1 Metodiky vývoje softwaru...14
1.1 Úvod ...14
1.2 Porovnání RUP a XP...15
1.2.1 Základní charakteristické rysy RUP...15
1.2.2 Základní charakteristické rysy XP...16
1.2.3 Náročnost implementace...17
1.2.4 Role...17
1.2.5 Pružnost...18
1.2.6 Závěrečné shrnutí...18
2 Metodika Rational Unified Process ...19
2.1 Praktiky ...19
2.1.1 Iterativní vývoj softwaru...19
2.1.2 Komponentová architektura...20
2.1.3 Visuální modelování...20
2.1.4 Ověřování kvality...20
2.1.5 Správa požadavků a řízení změn...20
2.2 Fáze...21
2.2.1 Incepční...21
2.2.2 Elaborační...22
2.2.3 Konstrukční...22
2.2.4 Předávání ...22
3 Vize...23
3.1 Úvod...23
3.2 Základní přehled produktu...23
3.2.1 Obchodní příležitost produktu...23
3.2.2 Definice problému...24
3.2.3 Definice produktu ...24
3.3 Zúčastněné osoby a uživatelé ...25
3.3.1 Demografie trhu...25
3.3.2 Zúčastněné osoby - přehled...26
3.3.3 Uživatelé - přehled...26
3.3.4 Uživatelské prostředí...26
3.3.5 Profily zúčastněných osob a uživatelů...27
3.3.6 Klíčové potřeby zúčastněných osob nebo uživatelů...28
3.3.7 Alternativy a konkurenční produkty...29
3.4 Přehled produktu...30
3.4.1 Perspektiva produktu...30
3.4.2 Souhrn klíčových vlastností produktu...31
3.4.3 Předpoklady a závislosti...32
3.4.4 Náklady a finanční omezení...32
3.4.5 Licence a instalace...32
3.5 Vlastnosti produktu...32
3.5.1 Vstup do systému...32
3.5.2 Vytváření a úprava kurzů...32
3.5.3 Vytváření a úprava obsahu kurzů...33
3.5.4 Vytváření a úprava definicí testů...33
3.5.5 Tvorba a vyhodnocování testů...34
3.5.6 Tvorba testových otázek ...34
3.5.7 Generování statistik...34
3.5.8 Přihlašování studentů do kurzů...35
3.5.9 Komunikace uživatelů...35
3.6 Omezení ...36
3.7 Oblast kvality...36
3.8 Precedence...37
3.9 Další požadavky...37
3.9.1 Příslušné standardy...37
3.9.2 Systémové požadavky...37
3.9.3 Výkonové požadavky...37
3.10 Požadavky na dokumentaci...38
3.10.2 Online pomoc...38
3.10.3 Instalační průvodce a “Read Me” soubor...38
3.10.4 Označení a balení...38
4 Plán ...39
4.1 Plán fází ...39
4.2 Jednotlivé vydání (Releases)...39
4.2.1 Povinný obsah prvního vydání (Release 1)...40
4.2.2 Povinný obsah druhého vydání (Release 2) ...40
4.2.3 Obsah třetího vydání (Release 3) ...40
4.3 Finanční plán...40
4.4 Plán zdrojů...40
5 Rizika...41
5.1 Neporozumění požadavkům zadavatele...41
5.2 Neoblíbenost ELP...41
5.3 Nekompatibilita rozhraní pro komunikaci se Stagem...42
5.4 Pomalá odezva systému...42
6 Model případů užití ...43
6.1 Přihlášení...43
6.1.1 Popis ...43
6.1.2 Základní posloupnost událostí (přihlášení)...43
6.1.3 Alternativní posloupnosti událostí...44
6.1.4 Doplňující informace...44
6.1.5 Diagram případu užití...44
6.2 Administrace kurzů ...44
6.2.1 Popis ...44
6.2.2 Základní posloupnost událostí (založení nového kurzu)...44
6.2.3 Alternativní posloupnosti událostí...46
6.2.4 Doplňující informace...47
6.2.5 UC diagram...47
6.2.6 Prototyp zakládání kurzu...48
6.3 Administrace obsahu kurzu...48
6.3.1 Popis ...48
6.3.3 Alternativní posloupnosti událostí...49
6.3.4 Doplňující informace...50
6.3.5 Diagram případu užití...50
6.3.6 Prototyp přidání obsahu...51
6.4 Administrace testů...51
6.4.1 Popis ...51
6.4.2 Základní posloupnost událostí (tvorba definice testu)...51
6.4.3 Alternativní posloupnosti událostí...52
6.4.4 Doplňující informace...53
6.4.5 Diagram případu užití...54
6.4.6 Prototyp tvorby definice testu...54
6.5 Vzdělávání...54
6.5.1 Popis...54
6.5.2 Základní posloupnost událostí (detail obsahu)...55
6.5.3 Alternativní posloupnosti událostí...55
6.5.4 Doplňující informace...56
6.5.5 Diagram případu užití...56
6.5.6 Prototyp přehledu obsahu kurzu...56
6.6 Výběr kurzu...57
6.6.1 Popis...57
6.6.2 Základní posloupnost událostí (Přehled kurzů)...57
6.6.3 Alternativní posloupnosti událostí...57
6.6.4 Doplňující informace...58
6.6.5 Diagram případu užití...58
6.7 Testování...58
6.7.1 Popis ...58
6.7.2 Základní posloupnost událostí (povinný test)...58
6.7.3 Alternativní posloupnosti událostí...59
6.7.4 Doplňující informace...59
6.7.5 Diagram případu užití...60
6.7.6 Prototyp povinného testu...60
6.8 Administrace systému...60
6.8.2 Základní posloupnost událostí (správa uživatelů)...61
6.8.3 Alternativní posloupnosti událostí...61
6.8.4 Doplňující informace...61
6.8.5 Diagram případu užití...62
6.8.6 Prototyp správy uživatelů...62
7 Architektura...63
7.1 Úvod...63
7.2 Reprezentace architektury...63
7.3 Architektonické cíle a omezení...63
7.4 Pohled na architekturu prostřednictvím případů užití...64
7.5 Logický pohled na architekturu ...65
7.5.3 Rozdělení do vrstev a balíčků...66
7.5.4 Use-case realizace...67
7.6 Procesní pohled...74
7.7 Pohled nasazení ...74
7.7.1 Klientský počítač...74
7.7.2 Externí klientský počítač ...74
7.7.3 E-learningový server...75
7.7.4 Studijní agenda...75
7.8 Velikost a výkon...75
7.9 Kvalita...75
8 Závěr...76
Seznam použité literatury...78
Přílohy...82
Příloha A: Obsah přiloženého CD...83
Příloha B: Prototypy...87
Seznam použitých zkratek a výrazů
RUP Rational Unified Process
XP Extrémní programování
ELP E-learningový portál
SW Software
IBM International Business Machines Corporation LIANE Počítačová síť Technické univerzity v Liberci
UML Unified Modeling Language
PC Personal computer
PDF Přípona souboru označující přenosný formát dokumentu DOC Přípona souboru označující dokument
EXE Přípona souboru označující spustitelný soubor HTML HyperText Markup Language
SMS Krátká textová zpráva
SeWe Sémantický web
Úvod
E-learningový portál (dále jen ELP) bude využíván jako jeden z nástrojů výuky na Technické univerzitě v Liberci (dále jen TUL), a to především k distribuci studijních materiálů, komunikaci mezi studenty potažmo akademickými pracovníky a k celkovému usnadnění procesu vzdělávání na univerzitě. Cílem je vytvořit portál využívající informační technologie, který by byl oblíbeným nástrojem a usnadnil by celý proces vzdělávání pedagogům i studentům. Do budoucna by mohl nahradit stávající systémy, které se v současném uspořádání jeví jako nedostatečné z hlediska stoupajících nároků na funkcionalitu a které dnes už nesplňují nároky na vlídné moderně postavené uživatelské rozhraní. Mohl by částečně odstranit roztříštěnost stávajících řešení.
Celý proces návrhu systému je podřízen metodice Rational unified process firmy IBM. Součástí diplomové práce je i úvod do této metodiky. Pilířem práce je pak návrh a analýza ELP v prvních dvou fázích vývoje, konkrétně se jedná o fázi incepční a fázi elaborační z označní podle Rational unified process. Zbývající fáze vývoje, fáze konstrukční a samotné zavedení, budou případně řešeny mimo rámec této práce.
Některé ilustrace v této diplomové práci mohou být v textu nečitelné – větší obrázky by neúměrně prodloužily text, proto jsou v čitelné podobě umístěny v příloze.
1 Metodiky vývoje softwaru
V této kapitole jsou obecně popsány důvody vedoucí k používání racionálních metodik při vývoji softwaru. Dále jsou v této kapitole srovnány dvě v praxi používané metodiky vývoje. Rational unified process, dále jen RUP, a metodika Extrémního programování, dále jen XP.
1.1 Úvod
Při vývoji Softwaru se často stává, že se vyvíjený software nepodaří dodat v požadovaném termínu za určené náklady nebo v požadované kvalitě. Podle neoficiálních zdrojů se procento neúspěšných softwaerových projektů pohybuje nad hranicí šedesáti procent. To je mimo jiné důsledkem tlaku trhu, který požaduje kvalitní software vyrobený v co možná nejkratším časovém úseku. Nejen z těchto důvodů vzniká potřeba celý proces vývoje softwaru podřídit určitým pravidlům, metodice, která je dostatečně universální a vede ke včasnému ukončení vývoje, jehož výstupem je kvalitní software, který přesně odpovídá potřebám zadavatele softwaru (zákazníka). Jako reakci na tyto potřeby trhu byly vytvořeny i výše uvedené metodiky, které si kladou za cíl eliminovat základní problémy vývoje softwaru.
1.2 Porovnání RUP a XP
1.2.1 Základní charakteristické rysy RUP
RUP je komerční produkt, který od roku 2003 vlastní firma IBM. Je to metodika řízená případy užití. Obsahuje velké množství pokynů, návodů a postupů poskytovaných v elektronické formě. RUP poskytuje i vhodné softwarové nástroje.
Metodika je neustále obnovována a jsou vydávané aktualizované verze. Další informace k metodice jsou v kapitole 3 a podrobněji v diplomové praci Filipa Aldorfa[1].
Obrázek 1: Schéma projektu RUP
Zdroj:[2]
1.2.2 Základní charakteristické rysy XP
XP je freeware, který Kent Beck popsal ve své knize Extreme Programming Explained. Tato metodika se řadí do skupiny agilních metodik. Oficiálně nejsou k této metodice poskytovány žádné softwarové nástroje a většinou si tým vystačí s fixou a tabulí. Hlavním cílem metodiky je co nejjednodušeji a nejrychleji dosáhnout požadovaného výsledku (programu), a to i za cenu obcházení zažitých konvencí.
Nabádá k programování co nejmenších a nejjednodušších funkčních celků, které se postupně skládají do jednoho celku.
Vytvářený kód je neustále revidován a testován. Příkladem budiž skutečnost, že u každého počítače spolupracují dva programátoři, čímž je zajištěna neustálá revize kódu. Metodika mimo jiné vyžaduje, aby zákazník byl součástí týmu.
Zákazník je k dispozici během celého procesu vývoje softwaru. Dohlíží na případné změny a odpovídá na dotazy programátorů.
XP neklade velký důraz na dokumentaci a nesnaží se o tvorbu znovupoužitelného kódu. Nabádá k dodržování svých zásad jen do chvíle, kdy na daném projektu fungují. Nepožaduje slepé následování těchto zásad a radí je měnit podle potřeb daného projektu.
Obrázek 2: Schéma projektu XP
Zdroj:[3]
1.2.3 Náročnost implementace
RUP je sestaven tak, aby mohl být použit na velkých projektech. Jeho dokumentace je rozsáhlá a orientace v ní může být zdlouhavá. Implementace vyžaduje studium metodiky a poměrně složitou implementaci na konkrétním projektu.
Implementace XP je oproti tomu jednodušším a přirozenějším procesem.
Nastudování základních principů a jejich převedení do praktického použití není časově příliš náročnou operací.
Z pohledu složitosti implementace je RUP pro malé projekty nevhodný a může jim naopak dokonce uškodit. Jednoduché principy XP a jeho implementace pro malé projekty se zdají být vhodnější. S nárůstem složitosti a velikosti projektu se rozdíly náročnosti implementace stávají méně podstatnými ukazateli.
1.2.4 Role
Obě metodiky obsazují jednotlivé osoby do rolí. RUP má těchto rolí o poznání více. Tam, kde si XP vystačí s rolí programátor, rozlišuje RUP jeho činnosti do přibližně čtyř různých rolí. Role si nejsou ekvivalentní, jak by se mohlo na první pohled zdát. Přesto existuje mezi některými rolemi souvislost tak, jak ukazuje porovnávací tabulka vybraných rolí.
Jiné role jsou pak unikátní pro konkrétní metodiku. Příkladem takové role z XP je Kouč, který sleduje nejen vyvíjený software, ale i mezilidské vztahy ve vývojářském týmu.
Tabulka 1: Vybrané role z XP a jejich obdoby v RUP
Role v XP Role v RUP
Programátor
Implementátor Systémový integrátor Revizor kódu
Tester Zákazník
Zákazník
Systémový analytik Návrhář testů Tester
Vedoucí testování Analytik testů Tester
1.2.5 Pružnost
Ve většině případů zákazník v průběhu vývoje obměňuje nebo upřesňuje své požadavky na produkt. Pružnosti neboli schopnosti reakce na požadované změny jsou schopny obě metodiky, každá svým vlastním způsobem.
RUP reaguje na změny změnovým řízením, vytvoří se změnový požadavek, jehož oprávněnost posoudí analytik a případně jej zapracuje do projektu. Toto se děje primárně v rámci jednotlivých iterací.
V XP je změna možná téměř kdykoliv. Ať už je to v rámci programující dvojice nebo v rámci naplánované iterace. Vyplývá to ze samotné filozofie XP.
1.2.6 Závěrečné shrnutí
Obě metodiky byly vytvořeny na základě praktických zkušeností z vývoje softwaru. Kladou si za cíl eliminovat problémy související s vývojem softwaru.
Metodiky používají podobné terminologie. RUP i XP nabádají k tvoření menších funkčních celků, které společně tvoří danou funkčnost celého systému.
XP zastává hodnoty, jakými jsou volnost a jednoduchost. Obchází konvence a snaží se o jakýkoliv funkční výsledek. Spíš než modelovací jazyky (UML) používají vývojáři tzv. pseudokód a náčrtky. RUP oproti tomu razí cestu hrubé síly a dává k dispozici velké množství návodů a doporučení, mimo jiné jak efektivně využívat UML, podle kterých je vývoj veden. Dává k dispozici modelovací nástroje a klade důraz na dokumentaci.
RUP se zdá být profesionálnější a vhodnější pro velké projekty velkých týmů.
V takovýchto podmínkách jsou využity všechny přednosti RUP. Oproti tomu má XP své limity, je vhodný pro menší týmy (cca. 10 lidí) a projekty střední velikosti.
Efektivnost některých zásad XP, jakou je třeba spolupráce dvou programátorů u jednoho PC, je diskutabilní. Velkou slabinou XP oproti RUP je fakt, že není prováděna analýza a není udržována dokumentace.
Přesto, že jsou obě metodiky diametrálně odlišné, existuje zde jistá paralela.
Při velké míře zobecnění a pominutí některých faktů by se dalo říct, že XP je v jistém slova smyslu derivátem RUP.
2 Metodika Rational Unified Process
Metodiku Rational Unified Process vyvinula firma Rational Software a, jak již bylo zmíněno, od roku 2003 ji zaštituje firma IBM. Jedná se o procesní framework vývoje softwaru. Základními stavebními prvky této metodiky jsou role, produkt a úkoly.
2.1 Praktiky
Metodika je založena na šesti praktikách, iterativním vývoji softwaru, správě požadavků, komponentové architektuře, vizuálním modelování, ověřování kvality a řízení změn. V následujících podkapitolách je nastíněno, co tyto praktiky znamenají.
2.1.1 Iterativní vývoj softwaru
Iterativní vývoj softwaru, jak již samotný název napovídá, jedná se o vývoj softwaru v jednotlivých iteracích. Jednotlivé fáze vývoje jsou rozdělěny do různého počtu iterací. Na následujícím obrázku je vidět životní běh takovéto iterace. Na konci každé iterace je otestovaná funkční část produktu.
Obrázek 3: Iterace
2.1.2 Komponentová architektura
RUP klade důraz na tvoření softwaru postupným skládáním z menších funkčních celků, které nazývá komponentami. Jinými slovy software je rozdělen do funkčních celků, nejlépe znovupoužitelných, které spolu tvoří požadovaný software. Tento postup vede mimo jiné k lepší testovatelnosti a snažšímu rozdělení práce ve vývojovém týmu.
2.1.3 Visuální modelování
V rámci návrhu a vývoje softwaru jsou v metodice RUP hojně využívány všechny druhy UML diagramů. Jedná se o diagramy případů užití, diagramy tříd, sekvenční diagramy a další. RUP je i jistým návodem, jak vhodně UML při vývoji softwaru využívat. Graficke znazornění pomocí UML jazyka vede k větší přehlednosti a uspořádanosti celého vývoje a k celkovému usnadnění.
2.1.4 Ověřování kvality
V rámci návrhu systému jsou určena kvalitativní kritéria. V průběhu vývoje a předávání softwaru jsou tato kritéria ověřována. V případě, že některé z kritérií není splněno, je software přepracován, upraven. Tento postup zajišťuje, že výstupem je otestovaný software požadované kvality.
2.1.5 Správa požadavků a řízení změn
Správa požadavků, změny je možné do projektu zapracovávat v průběhu celého vývoje v rámci každé iterace. Neděje se tak však náhodně či nekontrolovatelně, slouží k tomu tzv. změnové řízení, v rámci něhož je rozhodnuto, zda a jakým způsobem je změnový požadavek do projektu a dokumentace zapracován.
2.2 Fáze
Životní cyklus celého projektu je rozdělen na čtyři zákládní fáze. Fáze incepční, elaborační, konstrukční a fáze předávání. Tyto jsou dále rozdělěny na různý počet iterací. Počet iterací je odvozen od velikosti a náročnosti konkrétního projektu a velikosti týmu. Jednotlivé fáze jsou blíže popsány v následujících podkapitolách.
Na následujícím obrázku je zobrazena poměrná časová a zdrojová náročnost jednotlivých fází.
2.2.1 Incepční
Incepční fáze je první fází vývoje. V rámci této fáze jsou schromažďovány důležité a prvotní informace o navrhovaném produktu. Je vytvořena vize, přesněji dokument vize koncového produktu, modely případů užití, plán fází. Určují se
Obrázek 4: Fáze vývoje a jejich milníky
Obrázek 5: Zdrojová a časová náročnost fází
náklady na produkt a vytváří rozpočet. Jsou identifikovány a popsány základní vlastnosti produktu.
V rámci této fáze se nejintezivněji komunikuje s koncovými uživateli a zákazníkem. Na konci fáze, na základě shromážděných informací, padne rozhodnutí zda projekt realizovat, zrušit či znovu projít incepční fází. Jsou vytipována základní rizika celého vývoje včetně nastínění prevence a jejich řešení. Při opouštění této fáze by mělo být detailně popsáno alespoň 20% případů užití[4].
2.2.2 Elaborační
Důležitým předpokladem pro zahájení elaborační fáze je úspěšné dokončení fáze incepční. Výstup fáze incepční je použit jako vstup ve fázi elaborační.
U následujících fází je tomu obdobně. Elaborační fáze je fází nejkritičtější.
Nejdůležitějším výstupem je základ modelu architektury produktu. Jestliže se nepodaří vypracovat akceptovatelné fundamenty architektury, je i v tuto chvíli možné se bez větších (v porovnání s dalšími fázemi) nákladů vrátit k první fázi vývoje a tu přepracovat. Další možností je v této fázi rozhodout o zrušení celého projektu. V rámci elaborační fáze jsou zaktualizována rizika. Zákazník je obeznámen s navženým systémem a jeho architekturou.
2.2.3 Konstrukční
Jak již název napovídá v rámci této fáze je systém tvořen, v jednotlivých iteracích je vytvářen zdrojový kód a jsou vydávaná tzv. releases (vydání). Výstupem každé iterace je funkční testovatelná podmnožina produktu.V průběhu celého vývoje je produkt a jeho funkční části testovány. Konstrukční fáze se dá popsat jednou větou jako výrobní proces, kde je důraz kladen na řízení operací s cílem optimalizovat náklady a kvalitu[5].
2.2.4 Předávání
V poslední fázi vývoje je produkt předáván zákazníkovi. Jsou prováděna školení uživatelů a testy na nasazené verzi. Je zjišťována míra splnění výkonostních a kvalitativních požadavků. Na konci předávání je hotový produkt splňující vytvořená kritéria.
3 Vize
3.1 Úvod
Cílem této kapitoly je shromáždění důležitých informací o navrhovaném ELP a jeho uživatelích. Vymezit potřeby zákazníka a určit hlavní vlastnosti systému. Tato kapitola slouží jako základ následujících kapitol.
3.2 Základní přehled produktu
3.2.1 Obchodní příležitost produktu
ELP, který bude více reflektovat přání pedagogů a studentů, může postupně nahradit stávající systémy podpory výuky a mohl by být velkým přínosem pro vzdělávání na Technické univerzitě.
Univerzita nyní využívá nekoordinovaně více systémů, což je jedním z problémů současného řešení. Přičemž ani jeden používaný systém plně nevyhovuje požadavkům univerzity.
Jedním z používaných systémů je systém Clix. Tento měla fakulta mechatroniky otestovat a uvést do provozu na TUL. Clix je však složitý, neprůhledný a studenty i lektory nepříliš oblíbený. Intenzivní komunikace mezi fakultou a výrobcem, ve snaze nejhrubší chyby odstranit, nevedla k pozitivním výsledkům. Proces modifikace byl především zdlouhavý, složitý a řešení relevantních požadavků ze strany fakulty bylo většinou nemožné nebo nepřiměřeně nákladné.
Na TUL jsou také používané různé klony Open Source systému MOODLE, často jen lokálně, co katedra nebo pracoviště, to jiná instalace. Na Textilní fakultě existuje vlastní e-learningový portál s neúplnou množinou e-learningových funkcí, ale je jednou z možných alternativ pro budoucnost.
Naléhavou potřebu jednoho integrovaného zdroje elektronických materiálů studenti řeší již dnes vlastními, opět roztříštěnými, servery, kde bez organizačních bariér celá studentská akademická obec ukládá formou podobnou „wikipedii“
materiály k předmětům. Tato nepokrývá celý odborný rámec TUL, dokumentuje
nahodilé skupinky aktivních studentů a publikované texty nejsou autorizované, proto lze zde najít řadu chybných textů a materiálů.
Nový nebo zásadně inovovaný e-learningový portál integrující materiály a funkce napříč univerzitou, usnadní a zkvalitní proces vzdělávání pedagogům i studentům. Zlepší uplatnitelnost absolventa univerzity na trhu práce. Odstraní dosavadní problémy roztříštěného přístupu a měl by poskytnout uživatelsky jednoduchý a jednotný sytém.
3.2.2 Definice problému
Problémem je Současné řešení elektronické podpory výuky je roztříštěné, málo oblíbené a nevyhovující.
Ovlivňuje Pedagogy, studenty a administrátory.
Má dopad na Výuku. Dostupnost studijních materiálů.
Ověřováni znalostí studentů. Studijní výsledky.
Vyřešení problému přinese Usnadnění a zkvalitnění procesu vzdělávání.
Zjednodušení ověřování znalostí studentů.
Zrychlení provádění změn v systému.
3.2.3 Definice produktu
Pro Pedagogy, studenty a zaměstnance TUL.
Kteří Navštěvují, vyučují nebo administrují vyučované předměty na TUL.
ELP je Nástroj.
Který Umožní sdílení studijních materiálů.
Zjednoduší ověřování znalostí studentů.
Umožní generování reportů a statistik.
Zjednoduší komunikaci mezi účastníky.
Vyhoví požadavkům univerzity a studentů.
Umožní jednoduše provádět změny v systému.
Oproti Clixu a ostatním již zmíněným roztříštěným zdrojům.
Náš produkt Zjednoduší a ulehčí přístup ke studijním materiálům.
Nabídne flexibilitu a více funkčnosti.
3.2.4 Definice pojmů kurz a předmět
Pojmem předmět je označen fyzicky vyučovaný předmět na TUL, který je zapsán ve studijní agendě STAG.
Pojmem kurz je označován základní stavební prvek ELP, který existuje pouze v elektronické formě na ELP.
Kurz může být přiřazen konkrétnímu předmětu ze studijní agendy nebo může existovat i samostatně. Ke každému předmětu ze studijní agendy lze založit více kurzů, které se musí lišit názvem. Každý kurz na sebe váže obsah (studijní materiály, úkoly, ...), testy a komunikaci. Při zakládání kurzu je možné omezit jeho přístupnost časovými a věcnými podmínkami (max. počet studentů, přístupnost skupině uživatelů, ...).
3.3 Zúčastněné osoby a uživatelé
V rámci této podkapitoly jsou určeny a popsány zúčastněné osoby a uživatelé systému. Existují tři druhy uživatelů ELP: Administrátor, Pedagog a Student.
Uživatelé Pedagog a Student mohou vystupovat ve více rolích.
3.3.1 Demografie trhu
Univerzitní komunita je rozmanitá. Je složena z členů 6 různých fakult a jejich zaměstnanců. Skupina uživatelů systému je vzdělaná a počítačově gramotná.
Drtivá většina vlastní osobní počítač s přístupem na internet. Ti, co osobní počítač nevlastní, mají možnost využívat školních počítačů s přístupem na internet, které jim univerzita dává k dispozici.
3.3.2 Zúčastněné osoby - přehled
Název Reprezentuje Vystupuje jako
Pedagog Osoby pověřené výukou. Koordinátor a tvůrce kurzů a jejich obsahu. Zastupuje požadavky univerzity.
Student Studenty TUL Vzdělávaná osoba. Zastupuje
potřeby studentů.
Administrátor Osoby (zaměstnanci) pověřené správou a obnovou systému.
Administrátor systému
3.3.3 Uživatelé - přehled
Název Popis Zúčastněná osoba
Pedagog Vyučuje předměty, vzdělává studenty, ověřuje jejich znalosti, vytváří kurzy, vytváří studijní materiály, komunikuje s ostatními uživateli. To vše v rozsahu přidělené role.
Zastoupený osobně
Student Je vzděláván, testován, získává potřebné materiály, ověřuje si své nabyté znalosti, komunikuje s ostatními uživateli.
Zastoupený osobně
Administrátor Provádí administrativní zásahy do systému, stará se o plynulý chod systému. Provádí údržbu a úpravy systému. Spravuje uživatelské účty.
Zastoupený osobně
3.3.4 Uživatelské prostředí
Univerzita používá studijní agendu Stag. Je nutná spolupráce systému s touto studijní agendou. Stag poskytne seznam předmětů zapsaných konkrétním studentem a seznam vyučovaných předmětů.
Všichni uživatelé musí mít přístup k internetové síti. Musí mít platné uživatelské jméno a heslo do LIANE. LIANE je počítačová síť Technické univerzity
v Liberci, která pokrývá veškeré hlavní budovy univerzity. V současné době je do ní zapojeno kolem 6000 počítačů a přibližně 10 000 registrovaných uživatelů[6].
ELP bude sloužit uživatelům z komunity zaměstnanců a studentů TUL především jako doplněk a pomoc při výuce. Nepočítá se s nasazením systému na jiné univerzitě.
3.3.5 Profily zúčastněných osob a uživatelů
3.3.5.1 Pedagog
Popis Vyučující, obvykle zaměstnanec TUL, pověřený výukou a úkony s tím souvisejícími.
Typ Uživatel
Zodpovědnosti Předávání znalostí studentům. Ověřování znalostí studentů.
Kritéria úspěchu Po vynaložení úměrného prvotního úsílí je používání systému přínosné a nekomlikované.
Systém časem ulehčí pedagogům výuku, testování a hodnocení studentů. Pedagog bude mít k dispozici více informací o aktivitě studentů.
Angažovanost Tvorba kurzů, jejich obsahu a úkony s tím spjaté.
Role Přednášející garant – zakladatel kurzu, v kurzu je jen jeden.
Přednášející – vyučující pedagog.
Cvičící – cvičící pedagog.
Komentář Může být i externista 3.3.5.2 Student
Popis Osoba, která je v rámci celého procesu vzdělávána.
Typ Uživatel
Zodpovědnosti Účast v povinných kurzech a s tím úkony spjaté.
Kritéria úspěchu Kvalitní obsah portálu, nabídka zdrojů je dostatečně kvalifikovaná a pestrá. ELP obsahuje dostatek studijních materiálů, vzorových příkladů a řešení. Student je schopen jednoduše a intuitivně vyhledat studijní materiály. Systém nebude pro studenty představovat nadměrnou zátěž.
Role Učastník - plnohodnotný student se všemi právy a povinostmi plynoucích z daného kurzu, student má typicky zapsaný předmět, který náleží danému kurzu.
Pozorovatel - dobrovolný účastník kurzu, typicky nemá zapsaný předmět náležící k danému kurzu.
Komentář Student musí být informován o aktivitách, při kterých je monitorován.
3.3.5.3 Administrátor
Popis Obvykle zaměstnanec TUL. Technicky vzdělaná osoba provádějící administrativní zásahy do systému.
Typ Uživatel s neomezenými právy v systému
Zodpovědnosti Plynulý chod systému, řešení krizových situací, zálohování databáze, obměny systému, administrace uživatelských účtů..
Kritéria úspěchu Spolehlivost
Angažovanost Po nasazení systému provádí jeho změny a údržbu.
Komentář Vyžaduje se detailní znalost systému
3.3.6 Klíčové potřeby zúčastněných osob nebo uživatelů
Následující tabulka zobrazuje klíčové potřeby uživatelů sytému. Potřeby jsou rozděleny podle priorit do tří skupin: vysoká, střední a nízká.
Potřeba Priorita Současné řešení Navrhované řešení Sdílení stujních
materiálů různých formátů(pdf, pps, doc, exe, html, ...).
Vysoká Uložení materiálů na webové stránky předmětu. Umístění materiálů na některý ze síťových disků.
Využití služeb Clixu, Moodle a dalších již zmíněných systémů.
Materiály budou dostupné příslušným studentům v sekci daného kurzu na ELP.
Dostupnost lze omezit na základě časových nebo věcných podmínek
Testování znalostí studentů pedagogy.
Vysoká Pedagog vytvoří test, který studentům předá a později opraví.
Pedagog vytvoří testové otázky a testy, systém tvoří unikátní testy pro jednotlivé
Potřeba Priorita Současné řešení Navrhované řešení Studenti vyplňují testy elektronicky. Po dokončení testu systém vyhodnotí odpovědi. Vygenerované testy je možno rovněž vytisknout a nechat vypracovat studenty ručně.
Testování znalostí studentů studenty samotnými.
Střední Student si vypracuje soubor otázek, pomocí nichž ověřuje své znalosti.
Student vypracovává
systémem vygenerované testy složené z poskytnutých otázek.
Tvorba statistik a reportů
Nízká Pedagog si na základě shromážděných údajů vytvoří statistiky.
Systém umožní generovat statistiky a reporty různých druhů a rozsahů.
Komunikace Nízká Verbální komunikace.
Neautomatická komunikace pomocí e-mailů.
Synchroní a asynchroní diskuze k danému kurzu nebo tématu. Automatická
komunikace systému směrem k uživatelům(e-mail).
3.3.7 Alternativy a konkurenční produkty
Jistou alternativou a konkurencí tohoto produktu je již nasazený Clix, mnoho instalací Moodle, studentský server Mapik a univerzitní e-learningový systém Fakulty textilní se svým publikačním a testovacím modulem.
3.4 Přehled produktu
Tato podkapitola obsahuje tzv. „high level“ pohled na systém. Zobrazuje napojení e-learningového systému na systém studijní agendy a poskytuje náhled do hlavních funkčností systému.
3.4.1 Perspektiva produktu
Systém bude nasazen na TUL a postupně, přirozenou cestou, by měl nahradit část stávajících řešení. Nový systém bude spolupracovat se systémem studijní agendy tak, jak je zobrazeno na kontextovém diagramu na obrázku 3, ze kterého bude získávat informace o předmětech.
ELP bude umístěn na školním serveru a využívat bude s největší pravděpodobností databázový server Oracle.
Uživatelská část systému je platformě nezávislá. Uživatelé přistupují do systému pomocí „tenkého klienta“ přes internetové rozhraní. Systém podporuje nejpoužívanější internetové prohlížeče: Internet Explorer, Firefox, Opera, Google Chrome a Safari.
Obrázek 6: Kontextový diagram ELP
3.4.2 Souhrn klíčových vlastností produktu
Užitek pro uživatele Podporovaná funkčnost
Dostupnost systému Systém je přístupný přes webové rozhraní z kteréhokoli počítače s přístupem na internet.
Snadné sdílení studjních materiálů Pedagog může vytvořit kurzy a následně i jejich obsah, k tomu může využít vestavěný editor nebo nahrát soubory z disku. Studenti mohou procházet kurzy, na které mají oprávnění, a využívat jejich obsahu.
Kontrola nad dostupností vloženého obsahu
Pedagog může omezit dostupnost vloženého obsahu. Řízení dostupnosti obsahu časem a věcnými podmínkami.
Snadné zakládání nových kurzů.
Snadná orientace v poskytovaných materiálech.
Systém získává informace o vyučovaných předmětech ze studijní agendy. Systém získává informace o předmetech pro daného studenta ze studijní agendy.
Prohloubení porozumění studovaných témat dalšími prostředky .
Podpora vícedruhových médií v rámci každého kurzu. Systém umožňuje vkládat ke kurzům víceproudové záznamy přednášek, které jsou poté dostupné studentům.
Snadné ověřování znalostí. Systém generuje a vyhodnocuje testy.
Ověřování identity uživatele.
Není nutná nová registrace.
Uživatel se do systému přihlašuje pomocí svého hesla do sítě LIANE.
Konzultace a komunikace v rámci systému.
Systém umožňuje komunikace v rámci jednotlivých kurzů. Konzultace mají různou podobu (systém dotazů, chaty, diskuzní fóra a zprávy). Komunikace může být soukromá nebo veřejná a probíhá napříč všemi uživateli.
Přehledy o studentech a jejich aktivitách
Systém uchovává informace o studentech a jejich studijních výsledcích. Generuje statistiky a reporty.
3.4.3 Předpoklady a závislosti
Zde jsou uvedeny předpoklady a závislosti, které by při své změně vedly k nutnosti přepracovat dokument vize.
• Studijní agenda Stag bude poskytovat informace o předmětech nejpozději před zahájením kostrukční fáze projektu.
• Univerzita bude provozovat zvolený aplikační a databázový server potřebný pro běh ELP po dobu jeho existence.
3.4.4 Náklady a finanční omezení
V současné době nejsou vymezeny finanční prostředky na tento systém.
3.4.5 Licence a instalace
Vzhledem k nasazení systému pouze na TUL nejsou na licencování produktu kladeny žádné nároky. Veškerá práva na tento systém náleží TUL. Výjimkou by mohlo být použití hotových Open Source částí systému. V takovém případě by licence byla upravena v souladu s daným produktem.
Serverová část bude uváděna do provozu z přenosného média obsahujícího potřebné soubory a informace o jeho zprovoznění. Uživatelská část systému je řešena jako webová aplikace a není nutné instalovat žádný dodatečný software.
3.5 Vlastnosti produktu
Kapitola obsahuje souhrn nejdůležitějších vlastností navrhovaného systému.
3.5.1 Vstup do systému
Systém je umístěn na webovém serveru, který je přístupný široké veřejnosti přez internetový prohlížeč. Vstup do systému je umožněn jen kompetentním osobám.
Ty do systému vstupují pomocí svého uživatelského jména a hesla, které je totožné s přístupovými údaji do sítě LIANE. Autorizace přístupu je zajištěna přístupovým protokolem Lightweight Directory Access.
3.5.2 Vytváření a úprava kurzů
Tato funkčnost systému je primárně určena pro pedagogy. Pedagog vytváří a
které s ním budou spolupracovat ve výuce tohoto předmětu, a přiřadit jim jednotlivé role. Dále má možnost určit časovou osu kurzu a další doplňkové vlastnosti (fórum ke kurzu apod.).
Standardně pedagog kurz přiřadí k jednomu z vyučovaných předmětů.
Seznam předmětů poskytuje studijný agenda. Pokud se kurz neváže k žádnému z vyučovaných předmětů, je možné založit kurz speciální (bez předmětu).
3.5.3 Vytváření a úprava obsahu kurzů
Pedagog vytváří a upravuje obsah jednotlivých kurzů. Má možnost tento obsah logicky členit a určovat podmínky jeho přístupnosti. Obsah se dělí do několika základních skupin (studijní materiál, úkoly, odkazy, atd.). Standardně jsou při tvorbě obsahu vkládány již připravené materiály z disku.
Pedagog má však možnost využít i vestavěný textový editor k tvorbě obsahu online. Jedná se o zjednodušenou obdobu MS Word, která nabízí základní operace s textem, obrázky a odkazy.
3.5.4 Vytváření a úprava definicí testů
Pedagog vytváří a upravuje definice testů. Definice testů je možné vícenásobně využít pro tvorbu testů v různých kurzech. Každá definice musí obsahovat alespoň jeden soubor otázek, tyto se přidělují při zakládání a úpravě definice.
Obrázek 7: Tvorba definic testů, testů a instancí
3.5.5 Tvorba a vyhodnocování testů
Pedagog má možnost vytvořit test z definice testu ke konkrétnímu kurzu.
Systém po spuštění takového testu vygeneruje pro každého studenta unikátní instanci testu. Po dokončení instance testu systém instanci vyhodnotí, zobrazí a uloží výsledky. Pedagog má možnost vytvořit i otázky, které není systém schopen vyhodnotit. Takové mu jsou po vyhodnocení instance přiděleny k vyhodnocení.
Výsledek instance testu se zobrazí až po opravení těchto otázek.
Pedagog má možnost vygenerovat instance testu k tisku. Systém vygeneruje požadovaný počet unikátních testů, které připraví k tisku.
Student má možnost nechat si vygenerovat instanci testu z otázek, které jsou určeny pro studenty. Test se rovněž po vyplnění vyhodnotí a zobrazí se výsledky.
3.5.6 Tvorba testových otázek
Pedagog tvoří a upravuje v rámci souboru testových otázek jednotlivé otázky.
U otázek lze rozlišit jejich určení, otázky určené k ověřování znalostí studentů, otázky určené k samotestům a otázky určené k obojímu. Systém dále rozlišuje 9 typů testových otázek tak jak je naznačeno v následujícím souhrnu.
Kód Popis Poznámka
T1 Odpovědí je jednoznačná jednoslovní odpověď. Nepovolují se odchylky.
T2 Odpověď je vybrána z nabízených možností. DropdownList.
T3 Odpovědí je doplnění chybějícího slova ve větě. Nepovolují se odchylky.
T4 Odpovědí je určení pravdivosti výroku. Formát Ano/Ne.
T5 Hledání správných dvojic z nabízených možností. Dvojice DropdownListů.
T6 Řazení prvků do skupin a skládání obrazců, schémat. Drag and drop.
T7 Odpovědí je věta či souvětí. Požadována je nutnost
manuálního vyhodnocení.
T8 Odpovědí je výběr jedné či více správných možností. Checkboxy.
T9 Odpovědí je numerický údaj Posuvník, kalendář, apod.
3.5.7 Generování statistik
Systém umožňuje generovat a exportovat (formát PDF) statistiky. Uživatel vybere jednu z následujících statistik. Doplní omezující podmínky vybrané statistiky, kterými jsou například časové období, skupina studentů, role studentů, druh testu a
další relevantní podmínky. Omezující podmínky jsou individuální pro každý druh statistiky.
Systém umožnuje generování agregovaných statistik. Jedná se o statistiky složené z více jednotlivých statistik. Existují dva druhy agregovaných statistik:
funkční a skládané. Funkční se vztahují k jednomu zkoumanému jevu. Skládané, jak již název napovídá, vznikají pouze složením jednotlivých statistik do jednoho dokumentu.
Kód Popis Zkoumaný jev
S1 Čas strávený na portále, kurzu, obsahu. Studentova aktivita.
S2 Úspěšnosti jednotlivých testů. Instance testů.
S3 Návštěvnost daného kurzu a obsahu. Kurz, obsah.
S4 Komunikace a dotazy. Komunikace v kurzech.
S5 Čas potřebný k vypracování testu (max., min., průměr). Insatance testu.
S6 Počet zhlédnutí daného obsahu skupinou, studentem. Obsah.
S7 Splnění povinností v kurzu, studenta, skupiny. Obsah (povinné aktiv.).
S8 Úspěšnost ukončení kurzu. Kurz
S9 Oblíbenost daného kurzu, obsahu. Zpětná vazba.
3.5.8 Přihlašování studentů do kurzů
Studenti se v rámci ELP přihlašují k jednotlivým kurzům. Systém ulehčuje tento proces nabídkou filtru, který umožnuje zobrazení různě seskupených kurzů, podle fakult, podle předmětů, které má student zapsané, podle vyučujících a jiných relevantních parametrů.
3.5.9 Komunikace uživatelů
Systém umožňuje několik druhů komunikace: konzultace s pedagogem, fórum, chat a zprávy.
Konzultace s pedagogem – systém dotazů pro pedagoga, každý dotaz má vlastní vlákno a 3 stavy: položený, zodpovězený a uzavřený. Uživatel, který dotaz položil, má právo změnit stav na uzavřený nebo položený, pedagog na zodpovězený.
Ostatní uživatelé mohou přidávat komentáře do doby, kdy dotaz není ve stavu uzavřený. Dotazy, odpovědi a komentáře jsou barevně rozlišeny. Systém implicitně upozorňuje příslušného uživatele a zodpovědné pedagogy na změnu stavu dotazu.
Fóra – komunikace pomocí diskusních fór na určité téma, uživatelé mohou vlákna zakládat a příspívat do již vytvořených.
Chat – každý kurz má jeden chat. Uživatelé mohou přidávat komentáře, které se zobrazují v reálném čase na obrazovce.
Zprávy – uživatel má možnost zaslat jinému uživateli soukromou zprávu v rámci systému. Uživatel pedagog má možnost zaslat zprávu i určité skupině uživatelů, přičemž je možné vybrat i jiné než interní komunikační kanály.
3.6 Omezení
Jistá omezení jsou kladena v rámci kapitoly 3.4.3, kde jsou uvedeny předpoklady a závislosti. Dalším omezením je fakt, že systém musí podporovat komunikaci ve formátu, který nabízí studijní agenda. Jistým omezením by mohl být i nutnost nákupu nového HW ve školním prostředí TUL, tato varianta se prozatím nepřipouští.
3.7 Oblast kvality
Intuitivnost ovládání Systém bude uživatelsky přívětivý. Cílová skupina uživatelů nebude mít problém s jeho ovládáním. Využití moderních technologíí: drag and drop, vícenásobný výběr, automatické doplňování, tooltipy s ilustracemi, vestavěný textový editor, ...
Oblíbenost Uživatelé budou systém považovat za přínosný a vyhovující.
Přístupnost Systém nebude mít fatální výpadky a bude neustále k dispozici.
Flexibilnost Systém bude snadno modifikovatelný podle relevantích požadavků uživatelů.
Obrázek 8: Dotazy v rámci kurzu
3.8 Precedence
Jednotlivé funkčnosti z kapitoly 3.5 jsou v následující tabulce rozděleny do tří skupin podle významu a vlivu na funkci celého systému.
Významnost Funkčnosti systému
Vysoká Přihlášení do systému.
Tvorba a úprava kurzů.
Tvorba a úprava obsahu kurzů.
Přihlašování studentů do kurzů.
Střední Tvorba a úprava testů, testových otázek.
Generování a vyhodnocování testů.
Tvorba a úprava komunikačních prostředků.
Nízká Generování statistik a reportů.
Úprava profilu uživatele.
3.9 Další požadavky
3.9.1 Příslušné standardy
Systém je uspůsoben pro běh v jednom z nějpoužívanějších internetových prohlížeču pro rok 2009. Podporované internetové prohlížeče jsou: Internet Explorer (od verze 6), Firefox (od verze 2), Opera (od verze 9), Google Chrome, Safari (od verze 3). Celý systém dodžuje webové standardy (XHTML, CSS, …).
3.9.2 Systémové požadavky
• Systém musí být schopen spolupracovat se studijní agendou Stag.
• Serverové komponenty systému musí být umístěny na školním serveru.
• Klientská část systému musí být platformě nezávislá.
3.9.3 Výkonové požadavky
Hlavním výkonostním požadavkem je schopnost systému plynule, v řádech sekund, zpracovávat požadavky připojených uživatelů. Nepředpokládá se aktivita více než 90 uživatelů současně.
3.10 Požadavky na dokumentaci
3.10.1 Uživatelský manuál
Uživatelský manuál bude přístupný na webové stránce ELP. Bude podrobně popisovat všechny úkony v systému. Tento manuál bude rozdělen do několika logických sekcí. Manuál bude v českém a anglickém jazyce a bude obsahovat velké množství ilustrací a video návodů.
3.10.2 Online pomoc
Online pomoc uživateli bude řešena prostřednictvím tzv. tooltipů. Tato pomoc bude umístěna na všech ovládacích prvcích systému. Online pomoc bude podmnožinou uživatelského manuálu. Bude stručná a velmi konkretizovaná.
3.10.3 Instalační průvodce a “Read Me” soubor
Instalační průvodce bude obsahovat hardwarové požadavky systému a podrobný návod uvedení systému i jeho databáze do funkčního stavu. Distribuován bude elektronickou formou spolu se samotnou aplikací a souborem “Read Me”.
“Read Me” soubor bude obsahovat krátký seznam a popis souborů, který obsahuje instalační médium.
3.10.4 Označení a balení
Vzhledem k tomu, že produkt je určen výhradně pro TUL, která se bude podílet i na jeho vývoji, nejsou na označení a balení produktu kladeny žádné konkrétní požadavky.
4 Plán
4.1 Plán fází
Vývoj ELP bude probíhat ve čtyřech fázích, jednotlivé fáze jsou dále rozděleny na různý počet iterací. Konstrukční fáze je rozdělena do tří iterací a výstupem každé iterace bude testovatelná verze.
Fáze Počet iterací Popis Milník Ukončení
Incepční 1 V kapitole 2.2.1 Cíle projektu Březen 2009
Elaborační 1 V kapitole 2.2.2 Architektura Květen 2009 Konstrukční 3 V kapitole 2.2.3 Funkční verze -
Předávání 2 V kapitole 2.2.4 Nasazení -
4.2 Jednotlivé vydání (Releases)
V průběhu konstrukční fáze vývoje budou vydány tři verze systému. Každá vydaná verze bude obsahovat funkcionalitu verze předchozí. První s druhou vydanou verzí bude obsahovat většinu funkcionality systému. Třetí vydaná verze bude obsahovat všechny klíčové funkcionality popsané v kapitole 3.5.
Třetí verze bude vydána jako beta a alfa verze. Nejprve bude beta verze nasazena a předána k otestování vybraným uživatelům. V alfa verzi bude poté systém připraven na nasazení do konečného provozu.
Obrázek 9: Časová osa projektu
4.2.1 Povinný obsah prvního vydání (Release 1)
• Přihlášení do systému.
• Tvorbu a úpravu kurzů.
• Tvorbu a úpravu obsahu kurzů.
• Přihlašování studentů do kurzů.
4.2.2 Povinný obsah druhého vydání (Release 2)
• Tvorba a úprava testových otázek.
• Generování a vyhodnocování testů.
• Tvorba a úprava komunikačních prostředků.
4.2.3 Obsah třetího vydání (Release 3)
• Generování statistik a reportů.
• Úprava profilu uživatele.
• Případně další doplňující funkcionality.
4.3 Finanční plán
Incepční a elaborační fáze jsou tvořeny v rámci diplomové práce a nevyžadují žádné finanční prostředky. Zbylé fáze nemají doposud určeny finanční náročnost ani finanční plán.
4.4 Plán zdrojů
Fakulta mechatroniky, informatiky a mezioborových studií disponuje velkým množstvím kvalifikovaných odborníků a programátorů schopných celý projekt řídit a realizovat. Dále je možné využít potenciálu studentů v rámci jejich projektů, bakalařských a diplomových prací.
5 Rizika
Tato kapitola se zabývá základními riziky vývoje ELP pro TUL. Mapuje rizika i dopad případného problému na projekt. Navrhuje, jakým způsobem tomuto konkrétnímu problému předejít, ale i jakým způsobem potencionální problém zmírnit v případě, že se mu nepodaří předejít. Největším problémem je neporozumění požadavkům zadavatele, což vede k tvorbě softwaru s odlišnými vlastnostmi, než je požadováno. Prevence tohoto rizika má nejvyšší prioritu.
5.1 Neporozumění požadavkům zadavatele
Závažnost Vysoká.
Popis Nebylo porozuměno potřebám zadavatele. Vyvíjí se software s jinými vlastnostmi než zadavatel požaduje.
Dopad na projekt Systém nesplňuje očekávání zadavatele. Projekt se musí přepracovat. Oddálení data odevzdání.
Ukazatel Nepřiměřené množství změnových požadavků.
Prevence Důkladné prodiskutování požadavků a později časté interakce se zákazníkem.
Zmírňující plán Úprava systému odložení realizace.
5.2 Neoblíbenost ELP
Závažnost Vysoká.
Popis Systém není oblíben jeho uživateli.
Dopad na projekt Projekt nesplnil očekávání a je nepoužitelný.
Ukazatel Komunita TUL nevyužívá služeb systému.
Prevence Důraz na jednoduchost a funkčnost systému.
Komunikace s koncovými uživateli v průběhu vývoje.
Zmírňující plán Doplnit uživatelský manuál o video návody. Uspořádat informační přednášky.
5.3 Nekompatibilita rozhraní pro komunikaci se Stagem
Závažnost Střední.
Popis Systém není schopen získat od Stagu potřebné informace.
Dopad na projekt Přepracování rozhraní. Odsun data dokončení ELP.
Ukazatel ELP nekomunikuje se Stagem
Prevence Konzultace s kompetentním zástupcem systému Stag Zmírňující plán Návrh a přepracování nového rozhraní.
5.4 Pomalá odezva systému
Závažnost Nízká.
Popis Systém není schopen v požadovaném čase reagovat na požadavky uživatelů.
Dopad na projekt Dodatečné náklady.
Ukazatel Odezva systému je delší než udává specifikace.
Prevence Důkladná analýza výkonostních požadavků.
Zmírňující plán Dodatečné zrychlení systému přikoupením hardwaru, optimalizace zdrojových kódů.
6 Model případů užití
Tato kapitola popisuje podstatné případy užití ELP. Tyto případy užití tvoří základ funkčnosti ELP. Případy užití poskytují obecný náhled na systém a jeho funkčnost. Zobecněný pohled na systém je na následujícím obrázku.
6.1 Přihlášení
6.1.1 Popis
Případ užití, pomocí kterého se uživatelé přihlašují do systému. Jedná se o jednoduchý případ užití, který zabraňuje neoprávněnému užití systému a rozlišuje jednotlivé typy uživatelů.
6.1.2 Základní posloupnost událostí (přihlášení)
1. Systém uživatele vyzve k vyplnění přihlašovacích údajů.
2. Uživatel zadá :
• Uživatelské jméno ve tvaru jméno.příjmení.
• Heslo.
3. Systém ověří zadané údaje. Jestliže jsou v pořádku, přihlásí uživatele a dojde k ukončení tohoto případu užití. Jestliže zadané údaje nejsou v pořádku, informuje o tom uživatele a vyzve ho k opětovnému zadání přihlašovacích Obrázek 10: Diagram podstatných případů užití ELP
4. Po úspěšném přihlášení je zobrazena úvodní stránka s odkazem na manuál a všechny základní případy užití (dáneho uživatele) v právé části menu.
6.1.3 Alternativní posloupnosti událostí
6.1.3.1 Uživatelský manuál
1. Uživatel vybere odkaz ''Uživatelský manuál''.
2. Systém přejde na případ užití uživatelský manuál.
6.1.4 Doplňující informace
Speciální požadavky Přihlašování pomocí protokolu Lightweight Directory Access.
Předpoklady Tento případ užití nemá žádné podmínky, které musí být splněny před jeho spuštěním.
Konečné podmínky Přechod na úvodní stránku ELP Přidaná hodnota Autorizovaný přistup do systému.
6.1.5 Diagram případu užití
6.2 Administrace kurzů
6.2.1 Popis
Tento případ užití je přístupný primárně pedagogům. Poskytuje pohled na všechny kurzy, v nichž je pedagog zainteresován a detaily jednotlivých kurzů.
V neposlední řadě pak umožnuje tvorbu, úpravu a mazání kurzů.
6.2.2 Základní posloupnost událostí (založení nového kurzu) 1. Pedagog vybere „Založit nový kurz“.
Obrázek 11: Diagram případu užití
2. Systém zobrazí formulář pro vyplnění základních údajů o kurzu. Nabídne předměty, ke kterým může být kurz založen, a seznam pedagogů, kteří mohou být ke kurzu přiřazeni.
3. Pedagog vybere:
• Typ kurzu (kurz k předmětu nebo speciální kurz bez předmětu).
• Předmět ze Stagu, ke kterému kurz patří (pokud je vyžadováno).
4. V případě, kdy je vybrán kurz k předmětu, jsou předvyplněny všechny dostupné informace o kurzu podle příslušného předmětu. Takto předvyplněná pole mohou být dále upravována.
5. Pedagog může vybrat:
• Spoluzodpovědné osoby a jejich role.
• Délku trvání kurzu.
• Skpinu uživatelů, pro které je kurz určen.
6. Pedagog vyplní:
• Název a zkratku kurzu.
• Popis kurzu.
7. Pedagog může vyplnit:
• Omezující podmínky kurzu: začátek a konec kurzu, max. počet studentů (rozlišuje se role účastníka a pozorovatele), kritéria nepřijetí dalšího účastníka (fronta, prospěch, fakulta).
• Kredity, cíle předmětu, požadavky na studenta, přehled probírané látky, akreditaci, přehled literatury, získané vědomosti, hodnotící metody, studijní programy, do kterých je předmět zařazen, garanta, rozsah, semestr, použité místnosti, formu zápočtu, formu zkoušky, způsob ukončení.
8. Pedagog vybere „Vytvořit“.
9. Systém zkontroluje správnost zadaných údaju. Jestliže nejsou zadaná data v pořádku, zobrazí systém informaci o chybě v zadaných datech na patřičném místě a vyzve uživatele ke korektuře. Jestliže je vše v pořádku, zobrazí se informace o úspěšném vytvoření kurzu a přejde přehled kurzů. Zde případ užití končí.
6.2.3 Alternativní posloupnosti událostí
6.2.3.1 Detail kurzu
1. Uživatel zvolí „Detail kurzu“ u příslušného kurzu.
2. Systém zobrazí Stránku se záložkami detail kurzu, obsah kurzu.
3. Záložka detail kurzu obsahuje všechny dostupné informace o daném kurzu, konkrétně jsou popsány v předchozí kapitole, a možnost přejít na případ užití Úprava kurzu.
4. Záložka obsah kurzu obsahuje stručný přehled (formou tabulky) obsahu kurzu a možnost přejít na případ užití Administrace obsahu kurzu.
6.2.3.2 Úprava kurzu
1. Uživatel pedagog zvolí „Úprava kurzu“ z detailu kurzu.
2. Systém zobrazí stejný formulář jako je zobrazen při zakládání nového kurzu a předvyplní jednotlivé volby a výběry.
3. Uživatel změní určitý počet vlatností kurzu.
4. Uživatel vybere „Uložit změny“.
5. Systém překontroluje správnost zadaných hodnot a závislosti. Jestliže je vše v pořádku, zobrazí informaci o úspěšném upravení kurzu a přejde na detail kurzu.V tuto chvíli případ užití končí.
6. V případě, že systém vyhodnotí některá zadání jako nevyhovující, informuje o tom uživatele a vyzve ho k opravení těchto hodnot.
6.2.3.3 Odebrání účastníků z kurzu
1. Uživatel pedagog zvolí „Odebrat účastníky“ z detailu kurzu.
2. Systém zobrazí seznam na kurz přihlášených uživatelů spolu s ovládacím prvkem pro odebrání uživatelů z kurzu.
3. Pedagog vyplní důvod odebrání uživatelů.
4. Pedagog pomocí vícenásobného výběru a následného potvrzení odebre 1-n uživatelů z kurzu.
5. Odebraní uživatelé jsou systémem informování o této skutečnosti.
6.2.3.4 Administrace obsahu kurzu
Popsáno v kapitole 6.3 Administrace obsahu kurzu.
6.2.4 Doplňující informace
Speciální požadavky Nejsou definovány
Předpoklady Uživatel je přihlášen jako pedagog.
Uživatel má potřebná práva na daný kurz.
Konečné podmínky Přechod na úvodní stránku.
Přidaná hodnota Vytváření, přehled a administrace základních prvků ELP.
6.2.5 UC diagram
Obrázek 12: Případ užití Administrace kurzů
6.2.6 Prototyp zakládání kurzu
6.3 Administrace obsahu kurzu
6.3.1 Popis
Tento případ užití slouží k tvorbě, úpravě a katalogizaci obsahu jednotlivých kurzů. Obsahem kurzu rozumíme studijní materiály v různých formátech, dále pak úkoly, testy, odkazy a diskuze.
6.3.2 Základní posloupnost událostí (přidání obsahu) 1. Uživatel pedagog zvolí „Přidat obsah“ z přehledu obsahu.
2. Uživatel vybere:
• Kategorii obsahu, případně založí novou kategorii.
• Typ obsahu (soubor, odkaz, text, …).
3. Uživatel určí:
• Časovou a věcnou dostupnost obsahu.
• Název obsahu.
Obrázek 13: Prototyp zakládání kurzu
5. Uživatel potvrdí tvorbu obsahu ovládacím prvkem „Provést založení“.
6. Systém zkontroluje zadaná data, jestliže je obsah v pořádku, informuje o úspěšném přidání obsahu, přejde na přehled obsahu.
7. V opačném případě (formulář je chybě vyplněn) vyzve uživatele k upravení chybných údajů, jakými může být nevybraná kategorie.
6.3.3 Alternativní posloupnosti událostí
6.3.3.1 Úprava obsahu
1. Uživatel zvolí „Upravit obsah“ u konkrétního obsahu z přehledu obsahu.
2. Systém zobrazí stejný formulář jako při přidávání nového obsahu a předvyplní dané volby podle konkrétního obsahu.
3. Uživatel má možnost upravit jakoukoli volbu.
4. Uživatel potvrdí volbu stiskem ovládacího prvku „Uložit změny“.
5. Systém provede kontrolu zadaných dat stejně jako při založení, jestliže je vše v pořádku, informuje uživatele o úspěšné změně obsahu a přejde na přehled obsahu. Systém informuje uživatele o špatně zadaných datech stejně jako při založení.
6.3.3.2 Smazání obsahu
1. Uživatel zvolí „Smazat obsah“ u konkrétního obsahu z přehledu obsahu.
2. Systém zobrazí dialog s otázkou, zda opravdu obsah smazat.
3. Jestliže uživatel potvrdí volbu, systém obsah smaže, informuje o jeho úspěšném smazání uživatele a přejde zpět na přehled obsahu.
4. Jestliže uživatel nepotvrdí volbu, systém přejde zpět na přehled obsahu.
6.3.3.3 Přidání kategorie obsahu
1. Uživatel zvolí „Vytvořit novou kategorii obsahu“.
2. Systém zobrazí formulář.
3. Uživatel zadá:
• Název kategorie.
• Popis kategorie.
• Globální pravidla dostupnosti kategorie (časové a věcné).
