Slovenská technická univerzita v Bratislave Fakulta elektrotechniky a informatiky Študijný odbor Informatika Tímový projekt Multimediálna podpora predmetu Architektúra počítačov Dokumentácia k inžinierskemu dielu Analýza, špecifikácia požiadaviek, hrubý návrh, prototypovanie, podrobný návrh, implementácia, testovanie a záver Tím č. 9 Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel Mésároš Vedúci tímového projektu: Ing. Ján Hudec letný semester šk. r. 2003/2004 10. 5. 2004 KINEDRYL S T A Y C O O L
142
Embed
Multimediálna podpora predmetu Architektúra počítačovlabss2.fiit.stuba.sk/TeamProject/2003/team09/dokum/doc.pdf · 2020. 9. 26. · Slovenská technická univerzita v Bratislave
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Slovenská technická univerzita v Bratislave
Fakulta elektrotechniky a informatiky
Študijný odbor Informatika
Tímový projekt
Multimediálnapodpora predmetuArchitektúra počítačovDokumentácia k inžinierskemu dieluAnalýza, špecifikácia požiadaviek, hrubý návrh, prototypovanie,podrobný návrh, implementácia, testovanie a záver
Tím č. 9Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel MésárošVedúci tímového projektu: Ing. Ján Hudecletný semester šk. r. 2003/200410. 5. 2004
KINEDRYLS T A Y C O O L
Obsah0 Úvod 5
0.1 Zadanie projektu 50.2 Skratky 60.3 Slovník pojmov z problémovej oblasti 6
1 Opis problematiky 71.1 Výučba predmetov 7
1.1.1 Predmet Architektúra počítačov 71.1.2 Výučba predmetu Architektúra počítačov 71.1.3 Ciele projektu 8
1.2 Elektronické štúdium alebo „e-learning“ 91.2.1 E-learning a školstvo 101.2.2 Spôsoby využitia e-learningu 101.2.3 Rozdelenie pod�a spôsobu komunikácie 111.2.4 Hybridný spôsob výučby 121.2.5 Použitie multimediálnych technológií v e-learningu 12
1.3 Prostredia pre tvorbu prezentácií na Internete 131.3.1 PowerPoint 2000 141.3.2 Multimedia Builder 4.9 151.3.3 Illuminatus 15
1.4 Analýza podobných prezentácií 161.4.1 Cisco Network Academy Program 161.4.2 Kurz signalizácie v ISDN 18
2 Špecifikácia a analýza požiadaviek 192.1 Katalóg požiadaviek 192.2 Scenáre použitia 31
2.2.1 Vloženie textovej komponenty na obrazovku prezentácie 31
2.2.2 Vloženie novej obrazovky prezentácie 312.2.3 Export prezentácie do HTML 31
2.4 Interview s Ing. J. Hudecom 353 Hrubý návrh 37
3.1 Základné vlastnosti editora prezentácii 373.1.1 Vzh�ad aplikácie 373.1.2 Štruktúra prezentácie 373.1.3 Komponenty a práca s nimi 373.1.4 Výstup prezentácie 39
4.2.1 Prostredie pre tvorbu prezentácii 554.2.2 Tvorba výstupnej prezentácie 55
4.3 Vyhodnotenie prototypovania (prezentácia) 565 Podrobný návrh 57
5.1 Editor prezentácie 575.2 Konverzná utilita 58
5.2.1 Vnútorná štruktúra konverznej utility 595.2.2 Rozhranie konverznej utility 60
5.3 Návrh konverznej utility do formátu HTML 615.3.1 Nastavenie konverznej utility 615.3.2 Konvertovanie projektu prezentácie 625.3.3 Zobrazenie prezentácie 64
Použité názvy spoločností a produktov môžu by� registrovanými obchodnýmiznámkami alebo obchodnými značkami príslušných vlastníkov.
Tímový projekt | Dokumentácia k inžinierskemu dielu iii
0 ÚvodTento dokument vznikol na základe zadania projektu pre predmetTímový projekt, ktorý sa vyučuje v prvom ročníku inžinierskeho štúdia naFakulte informatiky a informačných technológií Slovenskej technickej univerzityv Bratislave.
0.1 Zadanie projektu
Zadanie projektu je nasledovné:
Multimediálna podpora predmetu Architektúra počítačov
Predmet Architektúra počítačov je jedným zo základných predmetov v prvomroku bakalárskeho štúdia konaného prezenčnou vzdelávacou metódou.V bakalárskom štúdiu konanom dištančnou vzdelávacou metódou sa tentopredmet vyučuje pod názvom Informatika 1. Štandardné učebné pomôckyvytvárané pre tento predmet (učebnice, skriptá, a pod.) sa vyznačujú tým,že ich obsahová náplň podlieha rýchlemu zastarávaniu, k čomu prispieva aj časpotrebný na ich výrobu. Na jednej strane je nevyhnutné neustále aktualizova�obsah predmetu o najnovšie poznatky, na druhej strane, aj ke� ve�ká čas�poznatkov z oblasti architektúry počítačov sa nemení, najmä preto, že časovýpriestor pre predmet je vymedzený, je potrebné postupne prehodnocova� ichdôležitos� a najmä ich rozsah, a intenzívne ich aj zovšeobecňova�.
Využitie multimediálnych technológií pri tvorbe učebných pomôcokmôže významným spôsobom zlepši� ich obsahovú aktuálnos� a cenovúdostupnos�, a čo je najpodstatnejšie, zredukujú sa časové nároky na ichinováciu a výrobu. Vzh�adom na stanovenú rámcovú obsahovú náplň predmetuje možné kedyko�vek vymeni� náplň (texty, obrázky, fotografie, animácie,videosekvencie, akustické efekty a pod.) jednotlivých častí, upravi� ich rozsah a takvytvára� učebnú pomôcku, ktorá bude zodpoveda� aktuálnemu stavu poznania voblasti architektúry počítačov.
Cie�om projektu je podpora uvedených činností. V rámci riešenia bude potrebné: – navrhnú� a realizova� produkt, ktorý multimediálnymi prostriedkami
– navrhnú� a realizova� náplň jednotlivých častí – produkt implementova� ako hypermediálnu prezentáciu s kapacitnými
nárokmi na jedno CD-ROM médium a vo�ne dostupný prehliadač.
Odporúčaná vzorová literatúra: 1. Krajčovič, T.: Počítače. Vydavate�stvo STU, Bratislava 2000. 2. Jelšina, M.: Architektúry počítačových systémov.
Vydavate�stvo ELFA, s.r.o., Košice 2002.
Vedúci tímu: Ing. J. Hudec
Tímový projekt | Dokumentácia k inžinierskemu dielu 5
0.2 Skratky
CSS2Cascading Style Sheets version 2
HTMLHypertext Markup Language
HWhardvér
LMSLearning Management Systems
SWsoftvér
WWWWorld Wide Web
zad.zadávate� Tímového projektu
0.3 Slovník pojmov z problémovej oblasti
Obrazovka – jeden súvislý HTML dokument.
Komponenta – elementárny prvok (text, obrázok, hypertextová linka, …)
s pomocou ktorej je možné posklada� obsah obrazovky.Návrhový systém
– prostredie pre vytváranie multimediálnych prezentácií.Tvorca prezentácie
– učite� alebo iná osoba, ktorá bude tvori� prezentáciu.Študent prezentácie
– študent (resp. osoba), ktorá používa vytvorenú prezentáciu.Zadávate�
– zadávate� Tímového projektu.
Tímový projekt | Dokumentácia k inžinierskemu dielu 6
1 Opis problematikyCie�om tejto kapitoly je oboznámi� čitate�a s problematikou dištančnéhovzdelávania elektronickou formou, ozrejmenie pojmov z tejto oblasti, ako ajrozčlenenie rôznych druhov a typov elektronických prezentácií. Budeme sazaobera� technológiami používanými v týchto prezentáciách a naznačíme, akýmsmerom sa vydá náš projekt. Nako�ko celý projekt má by� realizovaný akomultimediálna podpora predmetu Architektúra počítačov, bude úlohou tejtokapitoly predstavi� aj tento predmet.
1.1 Výučba predmetov
Ak sa chceme pozrie� na komplexný problém výučby predmetov, je potrebnéurobi� isté predpoklady. V našom prípade sa budeme zaobera� predovšetkýmvýučbou predmetov na Fakulte informatiky a informačných technológiíštandardnou formou denným štúdiom, nako�ko táto fakulta (ako aj jej materskáFakulta elektrotechniky a informatiky) externú formu štúdia nepodporuje. Našouúlohou však je hlbšie sa pozrie� aj na iné formy štúdia a navzájom ich porovna�.Takýto náh�ad nám poslúži pri h�adaní výhod a perspektív, ktoré poskytujeelektronická forma vzdelávania. Prv však než sa doňho pustíme, priblížme sisamotný predmet Architektúra počítačov.
1.1.1 Predmet Architektúra počítačov
V tomto článku by sme radi dali čitate�ovi stručnú informáciu o obsahupredmetu Architektúra počítačov. Cie�om predmetu Architektúra počítačov, ktorýsa vyučuje v druhom semestri bakalárskeho štúdia, je poskytnú� študentomvšetkých študijných odborov základné informácie o technických prostriedkochčíslicových počítačov a počítačových systémov. V anotácii predmetu sa hovorí :
Predmet poskytuje preh�ad o koncepcii číslicového počítača, zobrazeníinformácie v počítači, základoch číslicových obvodov a koncepcii procesora,inštrukčnom súbore, hierarchickom usporiadaní pamäti, vstupno-výstupnýchprenosoch a zariadeniach, osobných počítačoch a počítačových sie�ach.
Predmet prednášajú Doc. Ing. Tibor Krajčovič, PhD., Ing. KatarínaJelemenská, PhD. a Ing. Ján Hudec
1.1.2 Výučba predmetu Architektúra počítačov
Fakulta informatiky a informačných technológií Slovenskej technickej univerzityv Bratislave garantuje výučbu predmetu Architektúra počítačov iba v dennejforme štúdia. Takáto forma je bežná pre výučbu predmetov na tejto fakultea má na Slovensku dlhodobé tradície. Predmetu je vyhradený pevný početprednášok a cvičení za semester, pričom každá prednáška a cvičenie má pevnestanovenú dobu výučby v rámci jedného študijného týždňa. Pre predmetArchitektúra počítačov je to štandardne dvanás� trojhodinových prednášoka dvanás� cvičení trvajúci jednu hodinu za semester. Vo všeobecnosti platí, žeúčas� na prednáškach nie je povinná, ale naopak účas� na cvičeniach je jednou
Tímový projekt | Dokumentácia k inžinierskemu dielu 7
z podmienok udelenia zápočtu. Ako vidí takúto formu vzdelávania študent?Túto otázku môžeme jednoducho a kvalifikovane zodpoveda�, nako�ko každýz členov tímu tento predmet absolvoval (aj ke� pod iným názvom) a s toutoformou štúdia má skúsenosti.
Prednášky, nako�ko účas� na nich nie je povinná, sú navštevované asi lenpolovicou študentov, ktorí si predmet zapísali. Prečo? Nie je to spôsobené ibanezáujmom o predmet, aj ke� treba prizna�, že sú študenti, ktorých tento predmetpramálo zaujíma a majú ho zapísaný len preto, že je povinný. Spomenutá účas�(možno by bolo lepšie slovo neúčas�) je spôsobená vo ve�kej miere aj inýmipovinnos�ami študentov, či už sú to povinnosti študijné alebo pracovné.Zo strany cvičení, je situácia iná. Účas�, nako�ko je to podmienka zápočtu, jetakmer stopercentná a teda študenti sú nútení prís� na cvičenie v presnestanovenú dobu. Toto je bežná forma vzdelávania a ako taká zrejme najviacvyhovuje študentom, ktorí si vyhradili nieko�ko rokov na štúdium vysokej školy.Existuje však aj skupina študentov, ktorým by viac vyhovovala externá formaštúdia, pri ktorej by boli nútení navštevova� fakultu v minimálnej mierea vzdeláva� sa predovšetkým samoštúdiom vo svojom vo�nom čase. Samotnávysoká škola by potom iba vykonávala preskúšanie zvládnutia danej problematiky.Je treba pripomenú�, že Fakulta informatiky a informačných technológiív súčasnej dobe externé štúdium nepodporuje, a preto nie sú skúsenosti s toutoformou štúdia predmetu Architektúra počítačov. Bez oh�adu nato, projekt,ktorý riešime, si kladie za cie� vytvori� takýto systém multimediálnej podpory,ktorý by mohol by� plne použite�ný aj pre túto formu štúdia.
V problematike podpory štúdia predmetu Architektúra počítačov sú ajiné aspekty, ktoré by náš projekt vedel efektívne rieši�. Náplňou predmetu súpredovšetkým informačné technológie a všetko s nimi spojené. Nepoviem žiadnunovinku ak tvrdím, že táto oblas� vedy sa vyvíja závratným tempom. Preto jenutné, v záujme udržania aktuality informácií poskytovaných v predmete, neustáleobnovova� obsah skrípt a iných študijných materiálov. Rýchlej a jednoduchejaktualizácii týchto materiálov však bránia vysoké finančné náklady a časovánáročnos�. A práve tu sa črtá možnos� využita informačných technológií.Na to, akým spôsobom, by mal odpoveda� tento projekt.
1.1.3 Ciele projektu
Aké sú ciele, ktoré si kladieme a aké máme plány s projektom? Predovšetkýmmusíme nájs� miesto, kde sa v rámci výučby predmetu Architektúra počítačovnáš projekt uplatní. Externá forma štúdia je práve to pole pôsobnosti, na ktoromby sa mohol realizova� práve náš projekt. Informačné technológie sa v súčasnejdobe rozvíjajú závratným tempom a bolo by škoda nevyuži� ich v maximálnejmožnej miere. Jedným možným využitím by bola predstava, že študent bykomunikoval so svojim učite�om cez internet a tak isto by získaval študijnémateriály. Takto by sa dosiahla požiadavka externého študenta na minimálnunávštevnos� školy a štúdium vo svojom vo�nom čase. To je jeden smer, ktorýmby sme sa mohli vybra�. Iná možnos� je, aby samotné študijné materiály boliv elektronickej forme s maximálnou multimediálnou podporou. To by do značnejmiery vyriešilo problém s aktualizáciou informácií, ktoré sa v rámci predmetupreberajú.
Tímový projekt | Dokumentácia k inžinierskemu dielu 8
Aby sme správne určili smer, ktorým sa pri realizácii vybra�, je potrebné,aby sme si dobre rozobrali požiadavky zo zadania. Autori zadania argumentujúrýchlym zastarávaním informácií podávaných v predmete ako aj vysokýminákladmi na výrobu študijných materiálov. Aký produkt je teda potrebné vytvori�?V prvom rade musí ís� o systém, ktorý bude umožňova� uchováva� a prezentova�informácie v elektronickej forme. Týmto sa odstráni nutnos� tlačenia skrípt,čo stojí čas a peniaze. Bude potrebné vytvori� systém, ktorý umožní jednoduché,ale efektívne narábanie so samotnými informáciami, aby mal pedagóg možnos�rýchlo vytvori� svoju prezentáciu, inovova� údaje, niektoré zastaranejšie údajevymaza� a opätovne ich distribuova� ku študentovi. V dnešnej dobe sa vyvíjajúrôzne možnosti ako podpori� názornos� prednášanej tematiky a toto je oblas�,ktorú môže náš systém plne využi�. A v neposlednom rade je potrebné,aby systém čo najmenej obmedzoval používate�a z poh�adu požadovanejtechnickej výbavy.
Ke� zhrnieme tento náh�ad na budúci systém, vybavuje sa nám riešenie,ktoré by všetky tieto požiadavky riešilo z dvoch poh�adov. Jedným by bol poh�adpedagóga resp. tvorcu prezentácie a druhým poh�adom by bol poh�ad študentaprezentácie, teda toho, čo daný predmet študuje. Pre pedagóga by systémposkytoval výkonný nástroj na tvorbu prezentácie podporovanú najmodernejšímimultimediálnymi prostriedkami a pre študenta samotnú prezentáciu, pomocouktorej by si mohol doma na počítači študova� látku daného predmetu.V neposlednej rade by sme radi spomenuli, že nie je zanedbate�nou myšlienkourealizova� systém nezávisle na type prezentácie. To znamená, že by ho bolo možnépouži� aj na iné predmety ako predmet Architektúra počítačov. V každom prípadebude našou prioritou vytvori� systém, ktorý bude v maximálnej miere spĺňa�požiadavky naň kladené, ktorý bude (aspoň sčasti) naplnený údajmi z obsahupredmetu Architektúra počítačov a ktorý bude na konci letného semestra plnepoužite�ný pre nasadenie.
1.2 Elektronické štúdium alebo „e−learning“
E-learning predstavuje širokú oblas� získavania vedomostí vo vyučovacom proceseprostredníctvom moderných informačných a telekomunikačných technológií. Jejedným z prúdov tzv. e-odvetví, ktoré sa čoraz častejšie skloňujú s transformáciouspoločnosti na tzv. „informačnú spoločnos�“. Oblas� elektronického vzdelávaniaje pomerne rozsiahla, pričom pokrýva tvorbu a distribúciu interaktívnychelektronických kurzov (e-learningové kurzy), riadenie vyučovania a s ňou súvisiacuspätnú väzbu – to všetko za využitia moderných technológií. E-learningové kurzymôžu pozostáva� z multimediálnych prezentácií, simulácií, kombinácie animácií,videa, zvuku a textového výkladu a v neposlednom rade z testov pre overovanieznalostí študujúceho. Aby však bola zabezpečená spätná väzba medzi študujúcima lektorom, aby bolo vzdelávanie riadené a usmerňované a bolo ho možné presnevyhodnocova�, existujú systémy pre riadenie vyučovania, tzv. LearningManagement Systems (LMS). Okrem týchto základných vlastností zabezpečujúLMS systémy aj mnohé funkcie on-line štúdia (chat, videokonferencie, zdie�anieaplikácií, virtuálne učebne a pod.).
Tímový projekt | Dokumentácia k inžinierskemu dielu 9
V�aka e-learningu je možné rieši� niektoré špecifické problémy, ktoréúzko súvisia so vzdelávaním dospelých. V dnešnej uponáh�anej dobe plnejneustálych zmien v živote každého z nás hrá obrovskú úlohu čas. Čas je fenomén,ktorého má bohužia� takmer každý z nás čoraz menej, o čase na naše vzdelávanieani nehovoriac. A práve množstvo problémov vo vzdelávaní dospelých s nímsúvisí. E-learning sa tu môže uplatni� ako ve�mi užitočný a výkonný nástroj nazvyšovanie znalostí, schopností a kvalifikácie ako jednotlivcov, tak aj personálumoderných spoločností. V dnešnej dobe je prínos elektronického vzdelávanianesporný.
1.2.1 E−learning a školstvo
Klasické vzdelávanie, pod vedením učite�a, existuje už od počiatku histórie.Vzdelávanie pod vedením lektora je najčastejšou a najrozšírenejšou formouvzdelávania vo svete aj u nás. Učite� dokáže študentovi poradi�, správne honasmerova� a v neposlednom rade ohodnoti� jeho úspechy. V každom z nás sacelý život ukrývajú spomienky na učite�a, ktorý v nás niečo zanechal. Sú toučitelia, ktorí formujú naše životy a práve školstvo výraznou mierou určujespoločnos�. Klasické a osvedčené postupy vzdelávania sa využívajú aj dnes. Žijemevšak v dobe zmien, dobe nových myšlienok, nápadov, ale aj úloh. Jednouz nových a moderných foriem vzdelávania, ktoré sa už dlhšie presadzuje vovyspelých krajinách, ale aj u nás, je e-learning. E-learning prináša do škôl novýimpulz a nové možnosti.
Kombináciou klasického vzdelávania a e-learningu je možné dosiahnu�formu, v ktorej sa spájajú skúsenosti učite�a – lektora a výhody výpočtovejtechniky a multimédií. Vzdelávanie sa tak stáva pútavejším, adresnejším aefektívnejším. E-learning dokáže učite�a oslobodi� od každodenného opakovaniavýkladu, navyše dokáže často prostredníctvom obrázku, či animácie vysvetli�problém jednoduchšie a dostatočne názorne na to, aby si ho študent lepšiezapamätal. Môže to vzbudi� dojem, že úloha učite�a tým zaniká. Opak je všakpravdou. E-learning umožňuje učite�ovi sta� sa lektorom, ktorý svoju pozornos�venuje len problematickým oblastiam, zdokona�ovaniu svojich kurzov, vytváraniunových komunikácii so študentom a iným činnostiam, na ktoré mu doteraznezostával dostatok času. Práve komunikácia so študentom je ve�mi dôležitousúčas�ou vzdelávania prostredníctvom elektronických médií.
Už dnes je jasné, že e-learning nahradí tradičnú formu externého štúdia,ako ju poznáme dnes. E-learning posúva školstvo na vyššie priečky, otvára novémožnosti učite�om aj študentom a stáva sa novou, modernou a plnohodnotnousúčas�ou vzdelávania.
1.2.2 Spôsoby využitia e−learningu
Aby sme sa bližšie oboznámili s prostriedkami a možnos�ami použitia e-learningu,popíšeme si základnú terminológiu a pojmy z tejto oblasti. Využitie e-learningu vovýučbe sa dá rozdeli� pod�a toho, či sa vo výučbe používa ako učebná pomôcka(väčšia čas� výučby je vykonávaná klasickým spôsobom), alebo je priamoprostriedkom, prostredníctvom ktorého výučba prebieha.
Tímový projekt | Dokumentácia k inžinierskemu dielu 10
Pod�a spôsobu, akým je prístupný e-learning študentovi, môžeme rozdeli�spôsob výučby na tieto kategórie:
Technológiou podporovaná výučba – Pri tomto spôsobe výučby majúštudenti možnos� často sa stretáva� s vyučujúcim. Dopĺňa pritom štandardnýspôsob štúdia, a môže nahradi� materiály pre študentov, predtým dodávanév klasickej forme učebníc, papierových kópií a pod. Typicky to znamenáuverejňovanie osnov, odkazov na materiály a �alších materiálov pre výučbuon-line.
Technológiou podávaná výučba – Nikdy (alebo ve�mi málo) nie jevyžadovaný fyzický kontakt študenta s vyučujúcim. Je tiež známa ako „dištančnévzdelávanie“, „distribuované vzdelávanie“ alebo „dištančná výučba“. Vyučujúcimvedené tradičné triedy sú minimalizované, nahradené inými formami pôsobenianie v reálnom čase fungujúcimi „virtuálnymi triedami“. Pri on-line vzdelávaní savyužíva doručenie kurzu lebo programu vzdelávania, ktorý nie je typickým pretradičné, „kamenné univerzity“, až k používate�ovi (študentovi)
V súčasnosti sa väčšia čas� výučby na školách a univerzitách realizujevo forme technológiou podporovanej výučby, a ve�mi málo informatickýchpredmetov u nás je realizovaných za pomoci technológiou podávanej výučby.Práve z dôvodu ve�kého záujmu o informatické predmety a z dôvodu zvýšeniakapacít sa uvažuje a prechádza z technológie podporovanej výučby technológioupodávaný spôsob výučby.
1.2.3 Rozdelenie podľa spôsobu komunikácie
Pod�a spôsobu, akým sa študujúci stretáva a dostáva do kontaktu s obsahomučebných materiálov a vyučujúcim sa dá rozdeli� spôsob výučby na tieto kategórie:
Samoštúdium – Samoštúdium sa spolieha na určitý presne formulovanýplán, ktorý študenta vedie štúdiom, bez interakcie (odohrávajúcej sa v reálnomčase) s vyučujúcim. Príkladom materiálov pre túto formu štúdia súmultimediálne, na CD-ROM uložené materiály, písomná korešpondencia a tzv.„Click-To-Learn“, na web technológiách postavené systémy. Môže by� pritomdoplnené asynchrónnym vzájomným pôsobením študenta s vyučujúcim,prostredníctvom elektronickej pošty, hlasovej pošty či komentárov v tematickejdiskusii. Výučba postavená čisto na samoštúdiu vyžaduje, aby mal študentvytvorenú vlastnú motiváciu k štúdiu. Počet študentov korešpondenčných kurzov,ktorí nedokončia štúdium je ove�a vyšší, ako v prípade študentov tradičných„kamenných univerzít“. Samoštúdium môže by� použité pre tvorbu a potvrdenieschopnosti pre zvládnutie základov výučby, o zjednodušenie učiaceho procesu(prístup k osnovám predmetu, pridelenie úloh, chod kurzu, študentovisprístupnené hodnotenie), o odhad úspešnosti študenta prostredníctvom danýchcie�ov a merate�ných metód, testov, analýzy a dosiahnutých bodov)
Vyučujúcim vedené štúdium – Tento spôsob štúdia je dôležitý z dôvoduspoločného zdie�ania skúseností či udalostí. Obvykle sa koná v reálnom čase, jeinteraktívne a má dynamický priebeh. Vyučujúcim vedené štúdium má možnos�dynamicky reagova� na prostredie a meni� plán štúdia alebo jeho priebeh pod�apotrieb vyučujúceho v konkrétnom čase. Toto napomáha udrža� pozornos�študenta a pomáha znižova� počet študentov, ktorý nedokončia kurz. Môžeme pritom rozlíši� dva prístupy:
Tímový projekt | Dokumentácia k inžinierskemu dielu 11
– „vysielací model“ – štýl semináru, prednášky. Vyučujúci prednášas malou alebo žiadnou odozvou a interakciou od publika. Tentomodel je možné �ahko rozšíri� na väčšie množstvá študujúcich a jeasi najčastejšie používaný (ako príklad môžu slúži� klasicképrednášky na univerzitách),
– „dialógový model“ – malá skupina vedená vyučujúcim (expertomv danej problematike) – často ve�mi interaktívne, dynamickysledovaná a prispôsobovaná aktuálnym potrebám dialógu a výučby.Tento model je typický pre „kamenné univerzity“ a vyžaduje menšípočet študentov na skupinu (napríklad cvičenia v učebniachvýpočtovej techniky).
1.2.4 Hybridný spôsob výučby
Zmiešaný spôsob výučby je taký spôsob, ktorý využíva možnosti výučby za pomociprostriedkov informačno-komunikačných technológií (multimediálne CD-ROM,lokálne počítačové siete, Internet) a je ho možné kombinova� ho s klasickýmspôsobom výučby „tvárou v tvár“ (prednášky a cvičenia). Dá sa poveda� žev súčasnosti ešte nenastali podmienky pre výučbu prostredníctvom lenpočítačových sietí. Samozrejme, tento spôsob je pri súčasnom stave techniky plnevyužite�ný aj u nás, avšak ešte stále nenastali vhodné podmienky, ktoré byumožňovali využíva� možnosti dištančného vzdelávania bez živého kontaktus vyučujúcim všetkým potencionálnym záujemcom. Preto je dnes pre tie školya univerzity, ktoré chcú využíva� najmodernejšie trendy vo výučbe,najprijate�nejším spôsobom pre vedenie výučby hybridný spôsob výučby.
1.2.5 Použitie multimediálnych technológií v e−learningu
E-learning je proces, ktorý zahŕňa tvorbu a distribúciu e-learningových kurzov,riadenie výuky a následnú spätnú väzbu. E-learningové kurzy sú aplikácie, ktoréväčšinou obsahujú simulácie a multimediálne lekcie, t.j. kombinácie textovéhovýkladu a multimédií. Študijné materiály pre kurzy dištančného vzdelávania saväčšinou skladajú z nasledovných častí:
Tlačené texty – ktoré vytvára špecialista na obsah, obvykle učite�(prostriedky pre tvorbu tohto typu materiálov sú obvyklé textové editory, nakoniecv tomto prípade nie je dôležitý prostriedok, ktorý sa pre vytváranie danéhomateriálu používa, ale jeho obsah). Texty by mali by� vytvorené pod�a zásadpedagogiky dištančného vzdelávania. Dištančný text musí by� usporiadanýv krátkych moduloch. Musia by� jasne vymedzené ciele výučby. Každý študijnýtext by mal obsahova� obsah, úvod, text a záver. Nemal by chýba� slovníkpojmov, k�úč k úlohám a testom a zoznam literatúry. Súčas�ou každého modulusú jednoduché úlohy a testy, ktoré má študujúci vypracova� a posla� v zadanýchtermínoch, čím sa kontroluje jeho aktivita a zais�uje sa spätná väzba.
Multimediálne materiály – animácie, grafika, schémy, zvuk, videoa elektronické testy. Vytvorenie kvalitných multimediálnych materiálov je vysokoprofesionálna úloha pre špecialistov, pretože vyžaduje znalosti príslušných HWa SW technológií. Počítačový expert musí samozrejme ma� od učite�a k dispozícii
Tímový projekt | Dokumentácia k inžinierskemu dielu 12
pedagogicky a odborne pripravený obsah príslušného výučbového materiálua scenár usporiadania jednotlivých prvkov.
Grafika a schémy – predstavujú základný doplnok k učebným textom,bez ktorého sa nezaobíde žiadna kvalitná učebnica. Slúžia na �ahšie aintuitívnejšie pochopenie látky, ktorá je opísaná v príslušnom texte. Sú statickéhocharakteru, čiže neobsahujú pohybujúce sa prvky. Grafika sa dá vytvára vovektorových (napr. CorelDraw) alebo bitmapových (napr. Adobe Photoshop)grafických editoroch.
Animácie – slúžia na dodatočné vysvetlenie danej problematiky, prípadnena preh�adné zopakovanie prebranej kapitoly. Slúžia najmä ako doplnok grafiky,avšak v dnešnej dobe sa čoraz viac dostáva do popredia flash animácia. Takétoanimácie umožňujú ma� úplnú kontrolu nad jej priebehom pomocouinteraktívnej komunikácie s používate�om, čo je v priebehu výučby ve�ká výhoda.
Zvuk a video – väčšinou slúžia ako sprievodný materiál k danej téme.V prípadoch jednoduchej látky však môžu by� postačujúce na celkové pochopenieučiva a preto sa môžu distribuova� i samostatne. Ďalšie použitie zvuku a videavychádza z potreby spätnej väzby medzi študentom a učite�om, ktorá môže by�realizovaná práve týmto spôsobom (napr. videokonferenciou), čo si však vyžadujeve�ké nároky na kvalitu spojovacej siete.
Elektronické testy – s ich pomocou sa študent môže sám otestova�, akozvládol danú problematiku. S patričným zabezpečením sa môžu využi� i naohodnotenie študenta učite�om. Väčšinou sú realizované v prostredí HTMLs použitím JavaScript-u, môže sa tu využi� aj flash animácia.
Distribúcia multimediálnych študijných materiálov od vzdelávacejinštitúcie k študujúcemu sa realizuje na dátových nosičoch, ktorými môžu by�napríklad audio a video kazety, počítačové diskety alebo CD disky. Pre rôznepedagogické ciele sú vhodné rôzne technológie či kombinácie viacerých cenovodostupných technológií. Pre distribúciu multimediálnych študijných materiálov sačoraz častejšie používa Internet. Všetky vyššie spomenuté materiály vyžadujúpreh�adnos�, orientáciu, prezentáciu, štruktúru a prístup k informáciám, čo spolutvorí kvalitný učebný materiál pre potreby dištančného vzdelávania.
1.3 Prostredia pre tvorbu prezentácií
Tvorba prezentácii sa v poslednej dobe stala pomerne aktuálnou. Sú súčas�ouvyučovacieho procesu používaného na vysokých školách, pri prednášaní,umožňujú oživova� konferencie a začali sa používa� pre dištančné štúdium.Hlavným dôvodom ob�úbenosti je ich jednoduchos� na ovládanie, názornos�,doplnenie obrázkami a animáciami, ktoré oživujú text.
Túto skutočnos� si všimli mnohé firmy, ktoré sa zaoberajú tvorbousoftvéru. Po jednoduchých aplikáciách, ktoré umožňovali len jednoduchévkladanie obrázkov a textu sa začali objavova� prvé profesionálne aplikácie. Vývoja konkurencia v tejto oblasti však pracuje správne, takže v súčasnosti mámemnožstvo nástrojov na tvorbu prezentácii s obrovskými možnos�ami. Vývojspôsobil ich rozdelenie na dve základné skupiny:
Tímový projekt | Dokumentácia k inžinierskemu dielu 13
Jednoduché aplikácie pre začiatočníkov – aplikácie, ktorých základom jeskĺbenie podporovaných funkcií a jednoduchos� práce pri tvorbe prezentácie, takaby aj začínajúci používate� mal možnos� tvorby prezentácie. Často ide leno jednoduché zadávanie postupností obrazoviek, ktoré sú tvorené obrázkamia jednoduchým sprievodným textom. Je to dané tým, že prezentácie vytvorenév týchto aplikáciách sa používajú hlavne na prednes, pri ktorom slúžia akografické pozadie k hovorenému slovu. Nie je možné tvori� zložito štruktúrovanéprezentácie, ktoré sú určené napríklad pre dištančné štúdium.
Profesionálne aplikácie – aplikácie, ktoré sa snažia poskytnú� ve�kémnožstvo funkcií. Jednoduchos� práce s aplikáciou je až na druhom mieste.Samozrejmos�ou je poskytnutie ovládania, ktoré nebude pre používate�aprekážkou, ale pomôckou. Aplikácie poskytujú možnosti grafického editovania,a tiež podporu skriptovacieho jazyku. Je možné tvori� aj jednoduché prezentácie,ale hlavné �ažisko je v tvorbe štruktúrovanej prezentácie s možnos�ou použitiavšetkých moderných technológií, predovšetkým internetových.
Aj napriek rozdeleniu aplikácii na dve základné skupiny je možnépoukáza� na spoločnú vlastnos� – tvorba prezentácie je plne grafická. Toznamená, že na plochu sú pridávané grafické komponenty, ktoré podporujeaplikácia. Je možné meni� ich umiestnenie na stránke a vlastnosti. V závislostiod aplikácie potom závisia aj �alšie možnosti úpravy komponent.
U aplikácií na tvorbu prezentácií je však možné vidie� �alší dôležitýfaktor, ktorý určuje ich použitie: výstupný formát prezentácie. Pod�a toho ichmožno rozdeli� do nieko�kých skupín:
a) prezentácie, ktoré potrebujú aplikáciu, v ktorej boli vytvorené na ichprezeranie. Typickým predstavite�om je aplikácia PowerPoint 2000.
b) prezentácie, ktoré sú tvorené spustite�ným súborom. V tomto prípadeje to napríklad aplikácia Multimedia Builder 4.9.
c) prezentácie vo forme www stránky. Typickým príkladom je aplikáciaIlluminatus.Aplikácie umožňujú grafickú editáciu. Multimedia Builder navyše
obsahuje skriptovací jazyk, pomocou ktorého je možné vytvára� vlastné udalosti,ktoré môžu nasta� v programe, napríklad po stlačení tlačidla. Je dobré predstavi�si základné vlastnosti niektorých aplikácií.
1.3.1 Power Point 2000
Program PowerPoint je asi najčastejšie používaným nástrojom pre tvorbuprezentácii. Jeho základom je jednoduché rozhranie, ktoré je intuitívne a najmäefektívne. Je možne importova� do prezentácie výstupy z iných programovkancelárskeho balíka Microsoft Office. Ďalším významným plusom aplikácie jeexistencia šablón obrazoviek prezentácii. Aplikácia obsahuje množstvosprievodcov pre �alšie zjednodušenie práce.
Jednoduchos� aplikácie je aj mínusom. Je to v dôsledku orientácieaplikácie na začínajúcich používate�ov. Neobsahuje teda možnos� tvorbyzložitejších štruktúr, tvorbu tlačidiel s možnos�ou nastavova� akcie po vykonanía podobne. Vytvorené prezentácie je možné prehliada� len v aplikácii, teda ideo �alšie obmedzenie prenosite�nosti prezentácie. Je však možné exportova�výstupnú prezentáciu do HTML. Stráca sa tak však podpora medziobrazovkových
Tímový projekt | Dokumentácia k inžinierskemu dielu 14
efektov a zvukových súborov, ktoré HTML značky nepodporujú. Nie je možnépouži� animácie, ktoré sa používajú na internete ako Flash a animovaný GIF.Pretože ide iba o jednoduchú aplikáciu jej použitie pre dištančné štúdium jenedostatočné.
1.3.2 Multimedia Builder 4.9
Multimedia Builder predstavuje profesionálny nástroj. Aplikácia je jednoducháa nie je problém sa v nej vyzna� po prvom spustení. Ovládanie je intuitívne,podporuje priame grafické editovanie metódou Drag & Drop. Obsahujemnožstvo komponent, ktoré je možné vklada� do prezentácie.
Základná obrazovka je rozdelená na tri časti. V hornej časti je lištas tlačidlami pre ovládanie, �avú čas� tvorí lišta s komponentmi, ktoré aplikáciapodporuje. V dolnej časti je zoznam obrazoviek, ktoré tvoria prezentáciu a vpravoje zoznam komponent, ktoré sú v prezentácii. Používate� tak má okamžitý prístup,ku všetkým dôležitým prvkom prezentácie.
Jednotlivým komponentom, ktoré sa nachádzajú v okne prezentácie jemožné nastavova� udalosti. Ich podpora je rozšírená o existenciu skriptovaciehojazyka. Je tak zabezpečená podpora pre tvorbu vlastných udalostí napríklad pristlačení tlačidla. Do prezentácie je možné vklada� zvukové súbory vo formáteMP3, WAV, MID. Ďalším možným prvkom sú videá vo formáte AVI, MPEGa animovaný GIF. Obrázky, ktoré sa pridávajú do prezentácie je možné oživi�jedným z obrázkových efektov. Aplikácia obsahuje navyše možnos� vytvára�vlastné typy efektových klipov. Pre kompatibilitu s WWW stránkami je možnévklada� do prezentácie vytvorené WWW stránky, poprípade Flash animácie.
Aplikácia podporuje tvorbu zložitej štruktúry prezentácie. Chýba všakmožnos� zobrazenia štruktúry v strome. Nie je možné prezera� ako sú pospájanéobrazovky prezentácie. Aplikácia nepodporuje pokročilú prácu s textom, čo súvisís jej orientáciou na tvorbu grafických prezentácii. Je možné meni� len vlastnosticelého textu v textovej komponente. Farbu, font a štýl písma. Chýba tak možnos�formátovania časti textu v textovej komponente. Nie je možné vytvára�štruktúrované nadpisy.
Výstupom aplikácie je vykonate�ný súbor. Z toho vyplýva aj základnýmínus aplikácie. Do výstupného súboru sa integrujú všetky súbory, teda ajanimácie a obrázky, čím je zhoršená spustite�nos�, pretože je nutné nahra� celúaplikáciu do pamäti, a tiež je tým spomalená práca pri tvorbe. Ďalší mínusvychádza z orientácie aplikácie na grafiku a nepodporuje tak lepšiu prácus textom. Nie je možné exportova� prezentáciu do formátu HTML.
Aplikácia predstavuje profesionálny produkt. Jej možnosti použitia predištančné štúdium sú však značne obmedzené.
1.3.3 Illuminatus
Aplikácia Illuminatus podporuje komponenty podobne ako Multimedia Builder,aj ke� možnosti udalostí pri jednotlivých komponentoch sú slabšie anepodporuje skriptovací jazyk. Nie je možné používa� grafické efekty na zlepšeniekvality obrázkov. Je to v dôsledku orientácie aplikácie na Internet, pretožezákladným výstupom aplikácie je WWW stránka. Posledná verzia obsahuje
Tímový projekt | Dokumentácia k inžinierskemu dielu 15
chybu, ktorá neumožňuje export do čistého jazyku HTML, ale len jazyku Java. Jejpoužitie je obmedzené na prehliadače s podporou Java.
Aplikácia neposkytuje jednoduché ovládanie ako Multimedia Builder a ajpráca s ňou je o trochu náročnejšia. Preto sa jej opisom nebudem zaobera�podrobne.
1.4 Analýza podobných prezentácií
1.4.1 Cisco Network Academy Program
Popredný výrobca sie�ových smerovačov, firma Cisco Systems Incorporated,využíva multimediálne prezentácie v rámci vzdelávacích kurzov pre budúcichsie�ových špecialistov – Cisco Network Academy Program (CNAP).
Vzdelávací program je rozdelený do nieko�kých stupňov a každý stupeňdo nieko�kých modulov. Stupne možno prirovna� rozsahom k predmetom navysokej škole a moduly k častiam predmetov. Každý modul obsahuje nieko�kokapitol alebo okruhov, ktoré sú �alej rozčlenené na podkapitoly a články.Prezentácie sú nezávislé na úrovni modulov.
Orientácia v prostredí prezentácie
Používate� si po otvorení modulu môže vybra� okruh, o ktorý má záujem. Zobrazísa látka prvého článku okruhu. V záhlaví prezentácie je uvedený názov stupňaa verzia spolu s logom spoločnosti. Používate� sa môže pohybova� o článok vpreda vzad pomocou tlačidiel so šípkami, ktoré sú umiestnené vpravo dole. Okremnich sa tam nachádzajú aj tlačidlá pre zobrazenie obsahu, spustenie testovzvládnutia látky okruhu a pre zobrazenie slovníka pojmov. Pomocou roletovejponuky na spodnom okraji obrazovky je možné zvoli� si iný okruh.
Tímový projekt | Dokumentácia k inžinierskemu dielu 16
Organizácia obsahu
Látka je prezentovaná v dvoch oddelených častiach obrazovky. avá, väčšia čas�,zaberá asi 60 % šírky a pravá zvyšný priestor. V �avej časti sa zobrazujú obrázky,animácie, tabu�ky a diagramy. Pomocou očíslovaných záložiek pri �avom okraji simožno zvoli�, ktorý objekt sa má zobrazi�. Nad touto čas�ou sa pri niektorýchdruhoch obsahu zobrazujú �alšie ovládacie prvky, ktoré umožňujú napríkladspustenie animácie, prehrávanie zvuku, zobrazenie prepisu nahrávky, tlačeniea zväčšenie alebo zmenšenie.
V pravej časti sa nachádza text prezentácie. Na jeho začiatku sanachádzajú nadpis podkapitoly a článku uvedené ich číslovaním(v rámci modulu). Za odstavcom, ktorý súvisí s obrázkom alebo iným objektomzobrazovaným v �avej časti, sa nachádza číslo tohto objektu (číslovanie je v rámcičlánku). Číslo nie je hyperlinka. Na konci väčšiny článkov sa nachádzajú odkazyna zdroje súvisiacich informácií na Internete, prípadne informácie o súvisiacichmateriáloch a aktivitách CNAP.
Formátovanie
Celá prezentácia je formátovaná pod�a presných pravidiel. Farby boli zvolené zrôznych tónov neutrálnych farieb. Odstavce textu sú oddelené polriadkom bezodsadenia prvého riadku. V celej prezentácii je použitý jeden bezpätkový font(Arial) vo viacerých rezoch. Základný text je v obyčajnom reze, nadpisy, nápisy vobrázkoch a záhlaví sú v polotučnom reze. Odkazy sú vyznačené inou farboupísma a podčiarknutím.
Tímový projekt | Dokumentácia k inžinierskemu dielu 17
Záver
CNAP je prepracovaný vzdelávací program na vysokej úrovni tak po obsahovejako aj po formálnej stránke. Prezentácia je vo svojej forme jednoduchá a pritomelegantná. Ako kompromis pôsobí umiestnenie textu na pravý okraj obrazovky amultimediálnych objektov v�avo. Prispieva to síce k preh�adnosti a zrejme aj kimplementačnej jednoduchosti, avšak degraduje čitate�nos� textu, ktorý tvorívýznamnú čas� prezentácie, nehovoriac o plytvaní plochou obrazovky.
1.4.2 Kurz signalizácie v ISDN
V rámci predmetu Integrované služby digitálnych sietí sme mohli na vlastnej koživyskúša�, čo to znamená vzdeláva� sa elektronicky. Vo forme multimediálnejprezentácie bola spracovaná čas� látky tohto predmetu.
Pohyb v prezentácii na úrovni častí umožňujú odkazy na začiatku a koncikaždej časti. Zoznam všetkých častí je zobrazený len pri úvodnej časti. Prezentáciamá ve�mi vo�né členenie (8 častí a v rámci nich nadpismi uvedené podčasti), kvôličomu je predložená látka menej preh�adná. Text s vloženými objektmi(obrázkami, animáciami, tabu�kami, at�.) je prezentovaný na celej plocheobrazovky s okrajom v�avo a malým okrajom vpravo. Praktické je umiestnenieväčšej časti obsahu do jedného súvislého prúdu. Používate�ovi to umožňuje ma�väčšiu kontrolu nad priebehom prezentácie a lepšie sa orientova� v látke, ke�ženie je odkázaný na listovanie po jednej strane.
Pri tvorbe tejto prezentácie sa zrejme kládol ove�a väčší dôraz naobsahovú ako na formálnu stránku. Text prezentácie nie je �ahko čitate�ný, čomuzo strany formátovania prispievajú tučné bezpätkové písmo, dlhé riadky, malýpreklad a slabá podpora členenia textu. Avšak kurz signalizácie v ISDN je, ike�nie ideálna, predsa jedna z mála naozaj fungujúcich a používanýchmultimediálnych prezentácií na našej škole.
Tímový projekt | Dokumentácia k inžinierskemu dielu 18
2 Analýza2.1 Katalóg požiadaviek
Táto kapitola obsahuje požiadavky na informačný systém pre tvorbumultimediálnych prezentácií. Požiadavky sú zoskupené hierarchicky. Identifikovalisme tieto skupiny požiadaviek:
– funkcionálne požiadavky (t. j. požiadavky na funkcie systému) –Súborová správa prezentácie, Správa základných parametrov prezentácie,Vytváranie štruktúry prezentácie, Tvorenie obsahu obrazoviek, Tvorenieautomatických obrazoviek, Ovládacie panely, Pomocník, Vyh�adávanie,Doplnkové funkcie
– systémové požiadavky – Garantované zdroje, Parametre návrhovéhosystému
– bezpečnostné – Ochrana údajov Požiadavky sú detailne opísané v tabu�kách uvedených nižšie. Stĺpce
v tabu�kách majú takýto význam:
IdIdentifikátor požiadavky
ČísloHierarchické číslo pod�a umiestnenia v strome požiadaviek
Názov Výstižný názov požiadavky
OpisStručný opis požiadavky
ÚroveňÚroveň požiadavky:
U – nelistová (rozvíja)L – listová (nerozvíja sa)
TypTyp požiadavky:
F – funkcionálna požiadavkaS – systémová požiadavkaB – bezpečnostná požiadavka
ZdrojReferencia na zdroj požiadavky:
Zad. (zadávate�)Tím (členovia tímu)
PrioritaPriorita môže nadobúda� nasledovné hodnoty:
1 – vysoká2 – stredná3 – nízka
Tímový projekt | Dokumentácia k inžinierskemu dielu 19
Tímový projekt | Dokumentácia k inžinierskemu dielu 20
Tímový projekt | Dokumentácia k inžinierskemu dielu 21
Tímový projekt | Dokumentácia k inžinierskemu dielu 22
Tímový projekt | Dokumentácia k inžinierskemu dielu 23
Tímový projekt | Dokumentácia k inžinierskemu dielu 24
Tímový projekt | Dokumentácia k inžinierskemu dielu 25
Tímový projekt | Dokumentácia k inžinierskemu dielu 26
Tímový projekt | Dokumentácia k inžinierskemu dielu 27
Tímový projekt | Dokumentácia k inžinierskemu dielu 28
Tímový projekt | Dokumentácia k inžinierskemu dielu 29
Tímový projekt | Dokumentácia k inžinierskemu dielu 30
2.2 Scenáre použitia
2.2.1 Vloženie textovej komponenty na obrazovku prezentácie
Opis situácie: Pridanie novej textovej komponenty na obrazovku prezentácie.Typické kroky:
1. Požívate� stlačí tlačidlo textovej typovej komponenty.2. Systém pridá komponentu na koniec zoznamu komponent na
obrazovke.3. Požívate� stlačí komponentu na obrazovke.4. Systém otvorí používate�ovi editačné okno.5. Požívate� zadá text a pomocou menu ho naformátuje do požadovanej
podoby.6. Požívate� ukončí editáciu zatvorením okna.7. Systém uloží text do výstupného súboru a čaká na �alší krok.
2.2.2 Vloženie novej obrazovky prezentácie
Opis situácie: Pridanie novej obrazovky do prezentácie.Typické kroky:
1. Používate� stlačí tlačidlo pridanie novej obrazovky.2. Systém zobrazí okno s možnos�ou nastavenia mena a parametrov.3. Používate� zadá základné parametre.4. Systém uloží parametre obrazovky a pridá ju na koniec zoznamu
obrazoviek.
2.2.3 Export prezentácie do HTML
Opis situácie: Vytvorenie výslednej HTML prezentácie.Typické kroky:
1. Používate� stlačí tlačidlo export.2. Systém odovzdá parametre prezentácie a jej štruktúru používate�skej
knižnici.
Tímový projekt | Dokumentácia k inžinierskemu dielu 31
3. Používate�ská knižnica vytvorí z prezentácie v návrhovej forme HTMLstránku výslednej prezentácie.
2.3 Analýza formátovania prezentácie
Formátovanie prezentácie by malo napomáha� používate�ovi vníma� obsahprezentácie, orientova� sa v ňom a pohodlne riadi� jej priebeh. Ke�že naformátovanie používate�ského rozhrania a obsahu (látky) prezenácie sú kladenéodlišné nároky tak z používate�ského ako aj implementačného h�adiska, je vhodnézaobera� sa nimi oddelene. Na�alej ich však bude spája� požiadavka na jednotnýdizajn celej prezentácie.
2.3.1 Obsah prezentácie
Obsah prezentácie sa delí na časti kvôli preh�adnosti a taktiež za účelomodkazovania. Môže by� prezentovaný v zásade dvoma spôsobmi:
– ako súvislý tok textu a vložených objektov alebo – ako postupnos� stránok s vopred definovaným rozmiestnením textu
a objektov. Súvislý tok textu a vložených objektov (nadpisov, obrázkov, tabuliek,
animácií, a pod.) môže používate� posúva� vo vertikálnom smere, a tak si plynuloprezera� predložený materiál. V postupnosti stránok sa používate� pohybujeprostredníctvom navigačných tlačidiel (o stránku vpred, o stránku vzad, príp.iných) a tak sa môže sústredi� len na vopred určenú čas� obsahu.
Jednotlivé časti textu látky je potrebné odlíši� pod�a významu. Preto jevhodné zaradi� ich do týchto kategórií s oh�adom na možnosti jazyka HTMLv spolupráci s CSS2: nadpisy, holý text, zoznamy, tabu�ky, poznámky, definície,texty popisujúce vložený objekt.
Nadpisy
Nadpis slúži na získanie rýchlej informácie o obsahu jemu príslušnej časti textu.Nadpisy zoskupujú malé časti textu do väčších celkov alebo naopak, rozde�ujúdlhšie texty na menšie časti, a tým vytvárajú hierarchiu dokumentu.
Nadpisy jednotlivých úrovní je potrebné od seba odlíši�. Zo skúsenosti jeznáme, že príliš pestré členenie textu narušuje väzby medzi jednotlivými jehočas�ami, dezorientuje čitate�a a nie je ani estetické. Preto je potrebné urči�kategórie nadpisov pod�a možnosti korešpondujúce s úrovňami hierarchie a zvoli�vlastnosti ich písma a umiestnenia – formátovanie.
Špecifikácia jazyka HTML a CSS2 umožňuje prispôsobi� a používa� ažšes� úrovní nadpisov. V praxi sa však osvedčuje používanie nadpisov najviacštyroch úrovní. Väčší počet úrovní je problém rozumným spôsobom od sebaodlíši�.
Nadpisy vyššej úrovne odde�ujú väčšie časti textu, preto bývajú zvyčajnevýraznejšie. Naopak, nadpisy nižších úrovní by nemali zbytočne rozbíja� text,preto by mali by� nenápadnejšie. V odborných textoch sa často využíva číslovanie
Tímový projekt | Dokumentácia k inžinierskemu dielu 32
nadpisov, ktoré pomáha pri odkazovaní na určité časti textu. Číslovanie nadpisovje hierarchické.
Holý text
Najväčšiu čas� prezentácie bude tvori� holý text učiva. V ňom sa nachádza �ažiskoprezentovaných informácií. Najdôležitejším kritériom pri jeho formátovaní ječitate�nos� (pod�a možnosti na rôznom hardvéri) najmä pri dlhšom čítaní.
Niekedy je potrebné v texte zvýrazni� určité slová, slovné spojenia,prípadne vety, na ktoré sa kladie väčší dôraz. Môžu to by� napr. pojmyterminológie, tvrdenia, závery ale aj odkazy na iné časti prezentácie. Klasickátypografia odporúča zvýrazňova� text zmenou jeho rezu pod�a nasledovných zásad:
– kurzíva: najmenej ruší šedos� textu; najbežnejší a najšetrnejší spôsobzvýrazňovania,
– polotučné písmo: výrazne ruší šedos� textu; používa� len v osobitneodôvodnených prípadoch,
– polotučná kurzíva: klasická typografia ju nepozná, vznikla až spolus elektronickou sadzbou; neodporúča sa používa�.Ďalšie možnosti zvýrazňovania sú:
– zmena farby písma,– zmena prestrkania,– zmena ve�kosti písma,– verzálky,– kapitálky,– podčiarknutie,– horný index,– dolný index a �alšie.
Zoznamy
Vymenovanie položiek zoznamu sa v texte často vyznačuje špeciálnym spôsobom.Každá položka zoznamu začína na novom riadku a je uvedená značkou. Pod�adruhu značky možno rozdeli� zoznamy na číslované (každá položka má priradenéoznačenie z všeobecne známeho radu) a nečíslované (uvedené špeciálnymznakom, symbolom).
Najbežnejšie spôsoby číslovania sú:– arabské číslice,– abeceda z malých písmen,– rímske číslice a – abeceda z ve�kých písmen
Číslovania môžu by� viacúrovňové, pričom úrovne sa odde�ujúnajčastejšie bodkou. Viacúrovňové číslovanie zoznamov nebude v našomprodukte podporované, pretože by mohlo pôsobi� rušivo v súvislosti s číslovanímnadpisov.
Nezriedka je potrebné v rámci zoznamu uvies� �alší zoznam.Pri číslovaných zoznamoch sa zvyčajne uplatní iný spôsob číslovania, prinečíslovaných sa môže ale nemusí použi� iný symbol ako v nadradenom zozname.
Pre zvýrazňovanie častí zoznamov platia tie isté pravidlá ako pre holý text.
Tímový projekt | Dokumentácia k inžinierskemu dielu 33
Tabu�ky
Tabu�ky sme sa rozhodli rieši� ich včlenením ako obrázky. Rozsah predmetuneumožňuje vytvori� editor tabuliek. Iným možným riešením môže by� vloženieHTML kódu z externého súboru vygenerovaného bežným editorom HTML.
Poznámky
Na spresnenie a doplnenie textu možno použi� poznámky. V tlačených kniháchsú uvedené zvyčajne menším písmom, často na spodnej časti strany pod čiarou sodkazom v texte. Iný často používaný spôsob formátovania poznámok je ichvloženie za odstavec, obsahu ktorého sa týkajú. Pritom sú poznámky taktiežpísané malým písmom, oproti predchádzajúcemu spôsobu však naviac odsadenéa často oddelené aj iným spôsobom (linkami pred a za poznámkou, ikonou,uvedené textom "Poznámka", at�.)
Definície
V náučnom texte majú zvláštne postavenie definície. Skladajú sa z objektudefinície (slovo alebo slovné spojenie) a textu samotnej definície.
Vložené objekty
Prepojenie obrázkov, tabuliek, animácií, schém, diagramov s textom sa realizujeodkazom v texte na číslo daného objektu. Každý objekt takéhoto charakteru byvšak kvôli preh�adnosti mal ma� okrem čísla aj stručný opis, jednou vetouvystihujúci jeho obsah.
Vložené objekty môžu by� v texte umiestnené v zásade dvomaspôsobmi – vložením s obtekaním textu pozdĺž jednej strany objektu alebovloženie medzi dva odstavce bez obtekania.
2.3.2 Používateľské rozhranie prezentácie
Látku prezentácie používate�ovi sprístupňuje používate�ské rozhranie prezentácie.K jeho hlavným úlohám patria:
– informovanie o názve prezentácie, autoroch, podmienkach použitia,kontakte na správcu,
– jednoduchá navigácia v malom rozsahu článkov,– primerane zložitá navigácia v rámci celej prezentácie,– prístup k obsahu, indexu, slovníku pojmov, testom,– prístup k súvisiacim zdrojom informácií na Internete,– informovanie o aktuálnej pozícii v prezentácii (v hrubom meradle).
2.3.3 Záver
Zoznam tried textu prezentácie, pre ktoré je potrebné navrhnú� formátovanie:– holý text– nadpisy
Tímový projekt | Dokumentácia k inžinierskemu dielu 34
– nadpis kapitoly– nadpis podkapitoly– nadpis článku– nadpis štvrtej úrovne
– zoznamy– nečíslovaný zoznam
– obyčajný nečíslovaný zoznam– vnorený nečíslovaný zoznam– vnorený číslovaný zoznam
V každej triede je potrebné okrem základného textu navrhnú�formátovanie pre:
– zvýraznenie– odborný termín– odkaz
Zoznam prvkov používate�ského rozhrania prezentácie, pre ktoré jepotrebné navrhnú� formátovanie:
– názov prezentácie– autor prezentácie– administratívne informácie– štruktúra prezentácie– ovládacie prvky– úvodná obrazovka
2.4 Interview s Ing. J. Hudecom
V tejto podkapitole uvádzame interview s vedúcim tímového projektuJ. Hudecom na tému multimediálna podpora predmetu Architektúra počítačov.Otázky boli kladené na zistenie základných, ale aj podrobných požiadaviek a slúžihlavne pre ozrejmenie si predstáv v tejto oblasti.
Aké formáty výstupných súborov majú by� podporované?Okrem štandardného HTML výstupu by mal by� podporovaný hlavne
PDF formát z h�adiska jeho univerzálnosti a rozšírenosti. Ďalšie formáty nie jenutné podporova�.
Tímový projekt | Dokumentácia k inžinierskemu dielu 35
Aké by mali by� typy šablón?Šablóny by mali by� rozdelené do dvoch skupín. Prvá skupina by bola na
vytváranie bežných multimediálnych prezentácií a druhá skupina určená špeciálnena dištančné štúdium. Z každej skupiny by ich malo by� nieko�ko, aby boloz čoho vybera�.
Aké typy fontov by mali by� podporované?Rozhodne by nemla chýba� podpora všetkých štandardných fontov, ktoré
sú poskytované prostredím, prioritne ktoré sú podporované v operačnom systémeWindows s dôrazom na správnu diakritiku. Podpora špeciálnych fontov nie jenutná.
Je nutné implementova� funkciu "vráti� spä�"? Ak áno, do akej hĺbky?Samozrejme takáto funkcia by u�ahčila vytváranie prezentácií. Hĺbka by
mala by� aspoň tri kroky, samozrejme závisí to aj od implementačných možností.Je potrebné zavádza� kontrolu pravopisu?O tejto funkcii by sa dalo uvažova�, ale predpokladám, že vstupné texty
už budú skontrolované. O kontrole pravopisu by sa dalo uvažova� akoo prídavnej funkcii.
Je požadovaná ochrana údajov?Systém by mal podporova� zálohovacie funkcie, ktoré by mohli by� do
určitej miery aj automatizované. Autorizácia prístupu nie je nutná. Systém totižbude fungova� na počítačoch, ku ktorým majú prístup iba autorizované osoby.
Do akej miery by mal by� vypracovaný pomocník?Pomocník by mal by� v rozsiahlejšej forme vrátane príkladov tvorby
základných typov prezentácií. Vítaná by bola aj možnos� použitia onlinepomocníka, s ktorým by bolo možné rieši� aj zložitejšie problémy.
Akým spôsobom podporova� vyh�adávanie v dokumentoch?Bude postačova� vyh�adávanie základných odborných termínov a
definícií. Mohli by ste uvažova� aj o rozšírenom vyh�adávaní nadpisov a obrázkov.Mal by systém poskytova� aj nejaké štatistické informácie, ako počet slov, viet
a podobne?Myslím že pri niektorých typoch prezentácií je takáto funkcia určite
užitočná, a preto by malo zmysel o nej uvažova�.Aký počítačový systém bude používaný na vytváranie prezentácií na fakulte?Predpokladáme požitie produktu na modernejších počítačoch, ktoré
budú v blízkej dobe k dispozícii. Prostredie by malo by� optimalizované nabezproblémový chod na počítačoch Pentium 4 s operačným systémom Windows2000. Samozrejme, musí to by� funkčné aj na pomalších počítačoch.
Tímový projekt | Dokumentácia k inžinierskemu dielu 36
3 Návrh3.1 Základné vlastnosti editora prezentácii
Z analýzy prostredí pre tvorbu prezentácií je možné vidie�, že existujúce komerčnéaplikácie neposkytujú možnosti vytvorenia plnohodnotnej prezentácie vhodnejpre dištančné štúdium, ktoré by vyhovovali podmienkam zadania tímovéhoprojektu. Základnou podmienkou zadania je export do formátu, ktorý podporujúvo�ne dostupné prehliadače. Ide o formát HTML. Ďalšia dôležitá podmienka jemožnos� jednoduchej úpravy existujúcej prezentácie.
Jediná aplikácia, ktorá poskytuje tieto kritéria je Illuminatus. Jehoovládanie však nie je na dostatočnej úrovni. Tiež preh�ad štruktúry prezentácie jenedostatočný.
Je dôležité zhrnú� základné požiadavky pre aplikáciu, ktorá by vyhovovalapodmienkam zadania a prebrala by tie najlepšie vlastnosti z už existujúcichprezentácii:
Vlastnosti možno spoji� do nieko�kých základných tried, ktoré sa týkajúvzh�adu aplikácie, úpravy štruktúry prezentácie, komponent a ich vlastností.Poslednou dôležitou čas�ou je výstup programu.
3.1.1 Vzhľad aplikácie
Základom aplikácie je nieko�ko líšt. Lišta s komponentami, ktoré je možnévklada� do prezentácie a možnos� nastavovania ich parametrov pre každúkomponentu, spolu s možnos�ou práce spôsobom Drag & Drop. Zoznamobrazoviek tvoriacich prezentáciu a možnos� prezerania štruktúry prezentácie ajv stromovom zobrazení. Tretia lišta zobrazuje komponenty, ktoré sa nachádzajúv prezentácii. Tým je k nim zabezpečený jednoduchý prístup a je možné meni� ichvlastnosti. Hlavnou čas�ou je obrazovka s oknom prezentácie, do ktorého savkladajú jednotlivé komponenty.
3.1.2 Štruktúra prezentácie
Prezentácia je tvorená obrazovkami. Vzájomné prepojenie obrazoviek vytváraštruktúru prezentácie. Zoznam obrazoviek nie je postačujúci na celkovú predstavuo štruktúre prezentácie. Preto aplikácia musí podporova� možnos� zobrazenia celejštruktúry aj s následnos�ou obrazoviek. Používate� tak získa preh�ad aj nadzložitou prezentáciou. Pretože aplikácia obsahuje nadpisy, je žiadúce vytvára� ajštruktúru na základe nadpisov, aby používate� mal možnos� vidie� aj textovúštruktúru.
3.1.3 Komponenty a práca s nimi
Podstatou celej prezentácie sú komponenty, ktoré možno vklada� na obrazovkuprezentácie. Zjednodušene možno poveda�, že komponenty určujú možnostiaplikácie a tým aj výslednej prezentácie.
Tímový projekt | Dokumentácia k inžinierskemu dielu 37
Zoznam podporovaných komponent
Pri tvorbe prezentácie pre potreby dištančného štúdia je dôležitá názornos� učiva.Preto musí by� správne skĺbený text s podpornou grafikou v jednotlivýchobrazovkách prezentácie. Aplikácia tak musí podporova� vkladanie grafickýcha textových komponent.
Textové komponenty tvoria základ prezentácie určenej pre dištančnéštúdium. Základná komponenta je text. Pre lepšiu preh�adnos� textu je nutnámožnos� úpravy textu: farba, font, ve�kos�, štýl, zarovnanie. V prípade potreby jemožné použi� nastavenie konkrétnych slov v texte ako odkazov na iný textv prezentácii. Je tak možné vysvet�ova� pojmy v texte. Pre názornos� je niekedypotrebné umiestni� text učiva do tabu�ky. Samozrejmos�ou je tvorba nadpisov, priktorých je možnos� ich použitia ako odkazy na iné miesta prezentácie a určova�ich úroveň. Nadpisy by mali tvori� štruktúru, ktorú je možné použi� na tvorbuobsahu v prezentácii. Táto štruktúra tak umožňuje zobrazova� tematickú štruktúruučiva, ktorá môže by� odlišná od štruktúry obrazoviek prezentácie. Ďalšímikomponentmi, ktoré umožňujú zlepši� preh�adnos� sú obsah, ktorý je možnévklada� do prezentácie. S podporou obsahu súvisí číslovanie nadpisov. Programby tak mal podporova� aj automatické číslovanie nadpisov. Pre možnostitestovania zvládnutého učiva je potrebná komponenta test, ktorá bude obsahova�testové otázky. Na zoznam najdôležitejších pojmov je dobré vytvori� v prezentáciiindex. Zaujímavou by bola tvorba automatického indexu z už existujúcich pojmovv texte.
Pre grafické znázornenie učiva musia by� použité technológie, ktoré súpodporované prehliadačmi internetových stránok. Preto bude možne vklada� doprezentácie dva typy komponent. Jedna na vkladanie obrázkov, druhá navkladanie animácii. Pretože najpoužívanejšie obrázky sú typu jpg, gif a bmp, budemožný ich import, do prezentácie. Pri animáciách ide o súbory typu AVI, MPEGa Flash animácie, ktoré umožňujú vytvára� interaktívne animácie.
Pre možnos� zlepšenia komfortu bude možné vklada� do prezentáciezvukové súbory. Bude ich možné použi� na predčítavanie existujúceho textu,prípadne ako zvukovú kulisu.
Samozrejmos�ou je nastavovanie vlastností komponent. Na obrazovke prezentácie bude možné použi� dvojitý náh�ad na
komponenty. Prvý, kde komponenty budú predstavova� ikony, pri druhom sakomponenty nahradia svojím obsahom. Napríklad ikona s nápisom text, textom,ktorý obsahuje.
Tvorba šablón
Pri dištančnom štúdiu je snaha o vytvorenie jednotného zobrazenia. Je to danépsychologickým efektom na používate�a, ktorý číta text. Preto je potrebné abyprogram podporoval tvorbu šablón, ktoré bude možné uklada� do výstupnéhosúboru.
Tímový projekt | Dokumentácia k inžinierskemu dielu 38
3.1.4 Výstup prezentácie
Ukladanie prezentácie
Prezentáciu je možné uloži� do výstupného súboru. Je tak možnos� neskoršiehonávratu k nej a jej modifikácia.
Export prezentácie
Prezentáciu bude možné exportova� do formátu HTML a PDF. Tento formátumožňuje prehliadanie vo vo�ne dostupných prehliadačoch. Je tiež možnos�umiestnenia celej prezentácie na internet. Bude tak všeobecne prístupná.Samozrejmos�ou je tlač výstupnej prezentácie. Vidie�, že existuje viacero možnostíexportu prezentácie. V súčasnosti sa na tento účel používajú samostatné moduly,ktoré sa dajú pridáva� k programu. Tento prístup umožňuje nezávislos� prostrediapre tvorbu prezentácie od výstupu aplikácie. Výstup aplikácie je možné meni�pod�a požiadaviek.
3.2 Roly používateľov
V tejto podkapitole identifikujeme jednotlivých používate�ov systému a podrobnerozoberieme ich roly z poh�adu vytváraného prostredia. V zásade je vhodnéhovori� o dvoch používate�och, a to takých, ktorí používajú systém z rôznehouvažovaného prístupu k systému. Je to „tvorca prezentácie“, ktorý pristupujek systému z poh�adu tvorby prezentácie a „študent prezentácie“, ktorý prezentáciuprezerá (a zrejme študuje). Nasledovne si rozoberieme každého z nich.
3.2.1 Tvorca prezentácie
Je taký používate�, ktorý prezentáciu vytvára, modifikuje, prípadne ju inakautorsky pozmeňuje. Predpokladáme, že tvorca prezentácie má k dispozíciipočítač, na ktorom má nainštalovaný vytvorený systém pre multimediálnupodporu predmetu Architektúra počítačov a je oprávnený so systémom narába�.Tomuto používate�ovi sú prístupné všetky funkčné požiadavky popísané vkatalógu požiadaviek (vi�. 2.1). Predovšetkým sú to vytvorenie novej prezentácie,vkladanie komponent ako text, obrázok a pod., správa šablón prezentácie,narábanie s ovládacími panelmi a mnohé iné. Výslednú prezentáciu si tvorcaprezentácie samozrejme má možnos� prezrie�.
3.2.2 Študent prezentácie
Je taký používate�, ktorý prezentáciu iba prezerá. To znamená, že to nie jepoužívate� priamo vytvoreného systému, ale iba výstupu, ktorý tento systémprodukuje. Predpokladáme, že študent prezentácie je teda �ubovo�ná osoba, ktorávlastní produkt (prezentáciu), vytvorený systémom pre multimediálnu podporupredmetu Architektúra počítačov.
Tímový projekt | Dokumentácia k inžinierskemu dielu 39
3.3 Návrh aplikácie pre tvorbu prezentácie
Navrhovaný systém pre podporu dištančného štúdia je možné vidie� z dvochzákladných poh�adov. Prvý poh�ad sa zakladá na používate�och aplikáciea funkciách, ktoré im poskytuje. Druhý poh�ad pozerá na systém z h�adiskaimplementácie.
3.3.1 Koncepcia návrhu softvérového systému
z pohľadu používateľa
Základné rozdelenie navrhovaného systému vychádza z toho, že k systémupristupujú dvaja používatelia. Prvým je pedagóg alebo tvorca prezentácie. Ten máprístup k aplikácii na návrh prezentácie. Tu pomocou prostredia, ktoré muposkytuje prezentácia vytvára prezentáciu. Je možné identifikova� �alší modul,ktorý je pod vplyvom používate�a. Ide o konverziu prezentácie do výstupnéhosúboru. Druhým používate�om je študent, poprípade iný používate�, ktorýpristupuje k prezentácii.
Obr. 5. Základné rozdelene aplikácie z poh�adu používate�a
Prostredie pre tvorbu prezentácie
Prostredie pre tvorbu prezentácie je základným modulom, ktorý umožňujetvorcovi prezentácie určova� výstupnú prezentáciu. Základom je intuitívneovládanie. Návrh aplikácie vychádza z analýzy existujúcich aplikácii.
Základom je intuitívne prostredie. V prostredí je možné rozozna� trizákladné lišty:
– zoznam typových komponent, ktoré je možné vklada� do prezentácie,– zoznam obrazoviek tvoriacich prezentáciu a– zoznam komponent, ktoré sa nachádzajú v prezentácii
Hlavnú čas� okna vypĺňa obrazovka prezentácie. Prostredie poskytujepoužívate�ovi základnú prácu s prezentáciou a jej štruktúrou. Zabezpečuje tvorbunových prezentácii, načítanie existujúcich prezentácii a ich úpravu. Pomocoukomponent, ktoré je možné vklada� do obrazovky prezentácie je možné upravova�vzh�ad samotnej prezentácie. Výsledkom práce v prostredí je prezentáciav pracovnej podobe, ktorú �alej spracováva konverzia prezentácie do výstupu.
Tímový projekt | Dokumentácia k inžinierskemu dielu 40
Prostredie pre tvorbuprezentácie – editor
Konverzný modul
Prezentácia
Konverzia prezentácie na výstupný formát
Podstatou modulu je konvertova� existujúcu pracovnú prezentáciu do výslednejpodoby. Ide o samostatný modul, ktorý je možno nahradi� a zmeni� tak výstupprostredia pre tvorbu prezentácii. Zabezpečí sa tak modulárnos� prezentácie.Pretože zadanie si vyžaduje výstup do formátu podporovaného dostupnýmiprehliadačmi, tento modul zabezpečuje jeho konverziu do formátu HTML.Tvorca prezentácie môže meni� iba zobrazované lišty vo výstupnej prezentácii.Prezentácia bude tvorená dvomi základnými čas�ami. Pretože ide o formát HTML,ide o rámce (frames). Pevnou súčas�ou bude samotné okno prezentácie, ktorébolo vytvárané v prostredí na tvorbu prezentácie. Ďalšie okno je volite�né.V tomto okne je zobrazená celková štruktúra prezentácie. používate� ma takmožnos� pristupova� k �ubovo�nej časti prezentácie. Posledným rozšírením jemožnos� zakomponova� do okna prezentácie ovládanie, ktoré umožňujeprechádza� po prezentácií vo vopred určenom slede obrazoviek, tak ako ich určiltvorca prezentácie.
Prezentácia
Samotný model prezentácie je HTML stránka. Tento modul je prístupnýprimárne študentovi, ktorý bude získava� informácie z prezentácie.
3.3.2 Komunikácia používateľov so systémom
Prostredie pre tvorbu prezentácie
Základom systému na tvorbu prezentácie je prostredie, v ktorom je možnévytvára� prezentáciu. Prostredie preto musí poskytova� používate�ovi dostatokfunkcií, ktoré zjednodušia jeho prácu. Prostredie obsahuje lišty, ktoré poskytujúzákladné funkcie pre používate�a.
Základom celej prezentácie sú obrazovky. Obrazovka predstavuje jednookno prezentácie, ktoré sa vo výslednej prezentácii zobrazí ako celok naobrazovke. V našom prípade ide o jednu stránku HTML, pretože výstupom jeprezentácia vo forme HTML. Na obrazovku je možné vklada� základnékomponenty typu text, obrázok, animácia a zvuk. Komponentom sa nedá určova�presné umiestnenie na obrazovke. Komponenty sa ukladajú pod seba v poradí,ako ich používate� vkladá na obrazovku. Samozrejmos�ou je možnos� presúvaniakomponent.
Komponenta text má nieko�ko odvodených typov. Základným typomtextovej komponenty je holý text. Ide o �ubovolný text, ktorý tvorí v prípadedištančného štúdia vysvet�ované učivo.
Ďalšia textová komponenta je linka. Ide o slovo, ktoré predstavuje odkazna inú čas� textu. Samozrejmos�ou je odkaz na text, ktorý sa nenachádza naobrazovke. Táto komponenta umožňuje vytvára� odkaz na pojmy, ktoré je dobréozrejmi� počas štúdia a používate� tak má prístup k ich vysvetleniu.
Všetky tieto pojmy je možné združova� do indexu, v ktorom sanachádzajú najdôležitejšie pojmy. Používate�, ktorý si prehliada prezentáciu mátak stály prístup k pojmom, aj v prípade, že sa v texte nenachádza odkaz na danýpojem.
Tímový projekt | Dokumentácia k inžinierskemu dielu 41
Text je možné štruktúrova� pod�a nadpisov a je teda možné vytvára�kapitoly a podkapitoly. Pre každý nadpis je možné urči� úroveň. Túto štruktúrunadpisov je možné očíslova�. Číslovanie je automatické s jeho možnou ručnouúpravou.
Z nadpisov je možné generova� automatický obsah. Ten je možné vklada�do prezentácie ako automatickú komponentu.
Ďalšími komponentmi sú grafické komponenty obrázok, ktorý môžeslúži� aj ako odkaz a animácia. Obsah týchto komponent tvorí súbor animáciealebo obrázku, ktorý sa priradí danej komponente.
Jednotlivé typové komponenty sa nachádzajú na lište programu. Po ichpresunutí do obrazovky prezentácie je možné určova� ich vlastnosti.
Komponenty sa v na obrazovke dajú zobrazi� dvomi spôsobmi. Prvým spôsobom je zobrazenie malých obdĺžnikov. Po "dvojkliku" na
danú komponentu je možné meni� jej vlastnosti. V prípade obrázku a animácieide len o zadávanie súboru, ktorý bude tvori� obrázok, prípadne animáciu.Špeciálny prípad predstavuje text. V tomto prípade sa zobrazí editor textupodobný programom na úpravu textu ako Wordpad, kde používate� môže zadáva�text a meni� jeho vlastnosti: font, štýl písma, zarovnanie a podobne.
Druhý spôsob je zobrazenie komponent na obrazovke tak ako budúvyzera� v skutočnosti. Ide teda o nahradenie "malých obdĺžničkov" textom aobrázkami. Iba animácie zostanú zobrazené ako "biele obdĺžniky" bez obsahu.
Na bočnej lište vo vývojom prostredí je zoznam komponent, ktoré sanachádzajú v prezentácii. Je možné zvoli� dva základné poh�ady na tento zoznam.Prvým poh�adom je zobrazenie všetkých komponent, ktoré sa nachádzajú vprezentácii. Pri druhom zobrazení sa zobrazí len zoznam komponent, ktoré sanachádzajú na práve upravovanej obrazovke prezentácie. Komponenty budúzatriedené do skupín pod�a typových komponent, aby mal používate� preh�ad nadkomponentmi. Iba v prípade zobrazenia komponent v rámci jednej obrazovky jemožné zobrazenie komponent, tak ako idú po sebe v rámci obrazovky.
Jednotlivé obrazovky tvoria štruktúru zre�azenia. Pretože obrazovkynemôžu existova� ako samostatné jednotky je nutné vytvori� ich zre�azenie.Zre�azenie vytvára tvorca prezentácie a určuje v akom slede sa budú obrazovkyzobrazova� v prípade, že používate� použije ovládanie na presun v rámciprezentácie, ktoré je možné prida� k prezentácii. Táto štruktúra sa tiež zobrazí nabočnej strane výslednej prezentácie. Do tohto zre�azenia môže tvorca zasahova�.Prostredie mu umožní presúva� jednotlivé obrazovky v štruktúre prezentácie.
Okrem tohto zre�azenia je možné vytvori� ešte jedno zre�azenie. Ide ozre�azenie pomocou nadpisov. Toto zre�azenie nahradí zre�azenie na bočnej lištevo výslednej prezentácii. Zre�azenie, ktoré je možné prida� do prezentácie naprechod medzi obrazovkami však bude na�alej prechádza� prezentáciou nazáklade poradia obrazoviek, ako je definované v štruktúre obrazoviek.
Konverzný modul do HTML
Tento modul bude zabezpečova� konverziu prezentácií vytvorených v editore doformátu HTML pre možnos� prezerania prezentácie pomocou vo�ne dostupnýchinternetových prehliadačov. Nako�ko sa nepredpokladá ich neustála aktualizácia,
Tímový projekt | Dokumentácia k inžinierskemu dielu 42
ke�že sa ráta s ich distribúciou aj na CD nosičoch, výsledná prezentácia budereprezentovaná ako statická HTML stránka, s prípadnou podporou JavaScript-u.
Konverzný modul bude samostatne stojaca jednotka, ktorá bude ma� seditorom spoločný iba dátový model pre vnútornú reprezentáciu prezentácie.Nebude poskytova� žiadne používate�ské prostredie, nako�ko všetky informáciepotrebné pre vykonanie konverzie mu budú poskytnuté pri jeho volaní editorom.
Z funkčného h�adiska sa dá rozdeli� na dve časti – Tvorenie štruktúryprezentácie a Tvorenie obrazoviek, tak ako to vidie� na nasledujúcom obrázku.
Obr. 6. Základná koncepcia konverzného modulu
Tvorenie štruktúry HTML prezentácie bude zabezpečova� načítanievstupných parametrov pre vykonanie konverzie, �alej vytvorenie HTMLdokumentov, ktoré budú tvori� základné rozhranie prezentácie pre zobrazeniejednotlivých obrazoviek a budú tiež umožňova� riadenie prezerania prezentácie.Taktiež bude zabezpečova� vytvorenie súborovej organizácie prezentácie tak, abyobsahovala všetky potrebné zdroje, pre správne zobrazenie jednotlivých častíprezentácie. To sa týka hlavne obrázkov, animácií a audiovizuálnych ukážok, ktorévo všeobecnosti môžu by� počas tvorby prezentácie v editore umiestnené na�ubovolnom mieste. Takto vznikne ucelená forma, ktorá je pripravená naprípadnú distribúciu pomocou elektronických nosičov, ako Internet a CDmédium.
Tvorenie obrazoviek bude zabezpečova� preklad obrazoviek z vnútornejreprezentácie editora na HTML dokumenty. V základe sa budú rozoznáva� dvatypy obrazoviek a to obrazovky vytvorené používate�om, vyskladané z editoromponúkaných komponent a obrazovky, ktoré sa budú tvori� automaticky až prisamotnom preklade ako napríklad zoznam obrázkov, index dôležitých pojmova iné.
3.3.3 Koncepcia návrhu z implementačného hľadiska
Z implementačného h�adiska bude aplikácia realizovaná modulovo a budepozostáva� z dvoch modulov. Tieto dva moduly vytvárajú aplikáciu, ktorápredstavuje konkrétne riešenie navrhovaného softvérového systému.
Tímový projekt | Dokumentácia k inžinierskemu dielu 43
Vstup z návrhovéhosystému
Tvorenie štruktúryHTML prezentácie
Tvorenie obrazoviek
Základným modulom je prostredie pre tvorbu prezentácie, ktorépredstavuje hlavný program. Zabezpečuje používate�ovi vizuálnu tvorbuprezentácie.
Druhú čas� tvorí používate�ská knižnica, ktorá bude realizovaná akosúbor typu DLL. V súboroch DLL sa nachádzajú funkcie, ktoré zabezpečujúkonverziu prezentácie z návrhovej formy do výstupnej HTML prezentácie.
Prednos�ou takto navrhnutého riešenia je to, že sa dá ponaprogramovaní modulov DLL realizova� �ubovo�ný formát výstupnej prezentácie.
3.4 Prezentácia
Prvá zo šablón formátovania prezentácie bude obsahova� predpis preformátovanie všetkých prvkov prezentácie. Ostatné môžu by� jednoduchšie,pričom sa zoh�adnia požiadavky kladené na špecifické druhy prezentácií.
Základná a asi najpoužívanejšia koncepcia formátovania používate�skéhorozhrania prezentácie vychádza z rozdelenia plochy obrazovky do piatich častí:titulného pruhu, pruhu so štruktúrou obsahu, hlavného okna prezentácie,navigačného pruhu a okrajov.
Titulný pruh bude obsahova� informácie o názve prezentácie, a autoroch.Pruh so štruktúrou obsahu bude obsahova� stromovú štruktúru
prezentácie s možnos�ou zbali� a rozbali� jednotlivé vetvy. Bude obsahova� triúrovne nadpisov. Po kliknutí na nadpis v nej sa v hlavnom okne prezentácieobjaví príslušná čas� textu.
Hlavné okno prezentácie bude ma� posuvník vo zvislom smere.Navigačný pruh bude obsahova� tlačidlá pre pohyb v prezentácii na
zvolenej úrovni vpred a vzad, o úroveň vyššie a pre presun na začiatokprezentácie.
Tímový projekt | Dokumentácia k inžinierskemu dielu 44
3.5 Model funkcií
V tejto kapitole sa budeme venova� funkcionálnemu modelu vytváranéhosoftvérového systému. Berúc do úvahy rozsah vytváraného systému sa sústredímeiba na diagram tokov údajov (DFD). V DFD diagrame sa dajú identifikova�niektoré samostatné bloky (procesy), v ktorých prebieha spracovanie informácií.Tieto budú slúži� ako základ architektúry systému. Načrtnutá je štruktúra systémuaž do druhej úrovne. Podrobnému opisu procesov druhej úrovne sa budemevenova� v kapitole podrobný návrh systému. V DFD sme identifikovalinasledujúce komponenty:
3.5.1 Externé entity
Softvérový systém je používaný dvoma externými entitami:– [E01] Tvorca prezentácie – používate� systému, ktorý vytvára, prípadne
modifikuje prezentáciu. Má k dispozícii všetky nástroje potrebné navykonanie funkcií, ktoré boli opísané v katalógu požiadaviek (kap. 2.1).Ďalšie podrobnosti vi� kap. 3.2.1.
– [E02] Študent prezentácie – používate�, ktorému je určený finálny výstupsystému – prezentácia. Ďalšie podrobnosti vi� kap. 3.2.2.
3.5.2 Úložiská údajov
Po analýze kap. 3.3 boli v systéme identifikované nasledujúce úložiská údajov: – [D1] Projekty – obsahuje kompletnú informáciu o celom projekte.
V dohodnutom formáte sú tu uložené informácie z dátových úložísk D3,D4 a D5. Bude pritom uložený v samostatnom súbore a dá sa pod�apotreby načíta� spä� do editora prezentácie alebo môže by� použitý nakonverziu do formy vhodnej na prezentáciu (napr. do HTML pomocoukonverzného modulu).
– [D2] Šablóny – obsahuje informácie o formátovaní všetkých objektov, naktoré môže by� dané formátovanie použité (napr. odsadenie textu,farba…). Toto umožňuje doda� celej prezentácii jednotný vzh�ad aprispie� tak k jej čitate�nosti.
– [D3] Komponenty – hlavné úložisko celého systému. Obsahuje všetkykomponenty, ktoré sa vyskytujú v projekte vrátane ich atribútov.Komponenty môžu by� rôznych typov, napr. text, obrázok, linka… Ďalšiepodrobnosti o komponentoch vi� kap. 3.1.3.
– [D4] Obrazovky – na tomto mieste sú uložené všetky obrazovky použitév projekte, vrátane ich atribútov a vzájomného prepojenia. Predstavujúzáklad pre HTML obrazovky výslednej prezentácie.
– [D5] Štruktúra nadpisov – obsahuje stromovú štruktúru nadpisov(nadpisy sú taktiež komponenty a sú uložené v D3). Určuje celkovúštruktúru prezentácie a je z nej odvodený aj obsah prezentácie.
– [D6] Komponenty a [D7] Obrazovky – predstavujú prúd údajov potrebnýna vytvorenie výslednej HTML prezentácie, sú odvodené z úložiska D1.Formálne sú zhodné z úložiskami D3 a D4, ale sú používané inýmprocesom, a preto obsahujú navyše údaje potrebné na HTML konverziu
Tímový projekt | Dokumentácia k inžinierskemu dielu 45
(vi� kap. 3.3.2). Ak by bol použitý iný konverzný modul (napr. do PDF),mali by tieto úložiská úplne iný charakter ako D3 a D4.
– [D7] CSS šablóny – sú použité na formátovanie výslednej HTMLprezentácie. Sú vyextrahované z úložiska D1 vytváraním množínkomponentov s rovnakým výsledným formátovaním. Následne sú CSSšablóny aplikované na HTML výstup.
3.5.3 Procesy
V DFD diagrame sme identifikovali na základe rozboru kap. 3 nasledujúceprocesy:
(1) Editor prezentácie – Hlavný proces ktorý vytvára a modifikuje vytváranúprezentáciu. Umožňuje tvorcovi prezentácie manipuláciu s projektom,ktorý je aj graficky znázornený na ploche. Viac sa o editore prezentáciedozviete z kap. 3.1. Z funkčného h�adiska je možné rozdeli� editor natieto procesy:(1.1) Správa šablón – proces na základe pokynov tvorcu prezentácia
manipulije so šablónami. Umožňuje ich vytváranie, modifikáciu,uloženie a načítanie šablón.
(1.2) Správa komponentov – proces s najvyššou prioritou, riadi všetkypožiadavky spojené s komponentami – pridávanie, modifikáciua ich odoberanie z projektu. Zároveň modifikuje komponentypod�a priložených šablón. Stará sa o konzistenciu a správneradenie konponentov do úložiska údajov D3.
(1.3) Správa obrazoviek – proces koordinujúci vytváranie a radenieobrazoviek pod�a pokynov tvorcu prezentácie. Zabezpečuje taktiežprira�ovanie komponentov na dané obrazovky.
(1.4) Správa nadpisov – interný proces, ktorý sa stará o konzistenciustromovej štruktúry nadpisov. Automaticky modifikuje číslovaniea úrovne nadpisov pri pridávaní nových kapitol do prezentácie.Zo získaných informácií vytvára strom nadpisov, ktorý slúži nagenerovanie obsahu ako aj na uchovanie štruktúry prezentácie.
(1.5) Správa projektov – Zabezpečuje rozhranie s diskovým subsystémompočítača. Zhromaž�uje všetky informácie o stave projektu a ukladáich do úložiska údajov D1. Následne môže z D1 spätne načíta�uložený stav projektu.
(2) Konverzný modul – zabezpečuje konverziu prezentácií vytvorenýchv editore prezentácie do formátu HTML. Výsledný produkt bude potomdostupný študentovi prezentácie. Vnútorne je členený z dvoch procesov.(2.1) Interpretátor údajov – zabezpečuje prevod projektu do stavu
vhodného na vykonanie HTML konverzie. Vytvára dátové toky,ktoré tvoria základ obrazoviek a komponentov analýzou dátovéhoúložiska D1. Zabezpečuje taktiež vytvorenie CSS šablón.
(2.2) Tvorenie obrazoviek – vykonáva samotný prevod do HTML. Vytvárazoznamy použitých komponentov, index, obsah a dodávaprezentácii pomocou CSS šablón jednotný vzh�ad. Pridáva taktiežprvky na ovládanie prezentácie.
Tímový projekt | Dokumentácia k inžinierskemu dielu 46
3.5.4 Použitá notácia
Obr. č. 8. Prvá úroveň DFD diagramu
Tímový projekt | Dokumentácia k inžinierskemu dielu 47
– externá entita
– proces (elementárny)
– úložisko údajov
– tok údajov
��
����
��
����
�
��������������
�� �����
�����������
�
��� �����������
���������
�����������
�
����������������
������������� �!�"�
�#���� !�!��������$�#�%�� �����������
��� �!���� �!�
Obr. č. 9. Druhá úroveň DFD diagramu – Konverzný modul
Obr. č. 10. Druhá úroveň DFD diagramu – Editor prezentácie
Tímový projekt | Dokumentácia k inžinierskemu dielu 48
Táto podkapitola sa zaoberá návrhom logického modelu údajov vyvíjanéhosystému. Rozhodli sme sa poskytnú� konceptuálny náh�ad na údaje v systémea preto predkladáme konceptuálny diagram, ktorý má znázorni� základné vz�ahymedzi údajovými entitami. Na tejto úrovni abstrakcie sa nezaoberáme atribútamiani metódami, našim cie�om je len predstavi� vz�ahy medzi údajmi. Obr. č. 11zobrazuje diagram tohto modelu. Pri návrhu sme použili bežné technikytypovania, generalizácie a agregácie na vyjadrenie vz�ahov medzi údajmi.Z dôvodov preh�adnosti sme do diagramu neuviedli názvy vz�ahov, ktorévyplývajú z použitej notácie a podrobne ich opisujeme pri popise údajových entít.
3.6.1 Diagram modelu údajov
Použitá notácia
Tímový projekt | Dokumentácia k inžinierskemu dielu 49
Názoventity Vyjadrenie údajovej entity s jej názvom.
Vz�ah medzi entitami.Možná kardinalita vz�ahu:
n – môže ma� vz�ah k 0 až viacerým prvkom,1 – má vz�ah iba k jednej inštancii entity,0..1 – nemá vz�ah k žiadnej alebo iba jednej
inštancii entity.
Vz�ah generalizácie.
Vz�ah agregácie.
Obr. č. 11. Diagram logického modelu údajov
3.6.2 Údajové entity
Prezentácia – Entita reprezentuje údaj samotnej prezentácie. Je to komplexnévyjadrenie súhrnných informácií o dokumente, ktorý je výsledkom vytváranéhosystému. Vo všeobecnosti uvažujeme, že Prezentácia môže pozostáva� z Kapitol az Obrazoviek. Takáto koncepcia umožňuje členenie dokumentu pod�a kapitol avytvori� tak bežnú hierarchiu. Typické použitie tohto prístupu je pre písanieskrípt, učebných textov a pod. Členenie pod�a obrazoviek umožňujeprepracovanejšie a hlavne univerzálnejšie riešenia pre používate�a. Takýmtoprístupom môže používate� jednoducho vytvori� dokumenty typu elektronickénápovedy a pod.
Obrazovka – Reprezentuje objekt, ktorý zodpovedá jednej stránke nazobrazenie. To znamená, že obsah obrazovky sa zobrazuje naraz na obrazovkepočítača. Vz�ah agregácie pri tejto entite vyjadruje hierarchické členenieobrazoviek. Jedna obrazovka pozostáva z elementárnych prvkov zvanékomponenty.
Komponenta – Ide o údaj, ktorý reprezentuje element na obrazovke.Takýmto elementom môže by� Nadpis (text reprezentujúci názov kapitoly,podkapitoly, článku, resp. nižšie úrovne), Text (štandardný text), Obrázok(statický grafický objekt), Linka (odkaz na iný údaj v prezentácii), Animácia
Tímový projekt | Dokumentácia k inžinierskemu dielu 50
Prezent á cia
Obrazovka
Komponenta
Nadpis
TypNadpisu
Kapitola Šablóna
Text
Typ Textu
Obrázok
TypObrázku
Linka
Typ Linky
Animácia
TypAnimácie
Zvuk
Typ Zvuku
ŠtýlNadpisu
Štýl Textu
Štýl Linky
ŠtýlObrázku
1
1
n
n
n
n
nnn
1
1
1
10..1
0..1
0..1
0..1 nn n
1
n1
n1
n1
n1
n1
n1
n0..1
0..1
1
n
ŠtýlAnimácie
Štýl Zvuku
nn
1
1
(dynamický grafický objekt), Zvuk (zvukový objekt). Komponenty sú v rámciobrazovky zre�azené tak, ako za sebou nasledujú, čo je vyjadrené vz�ahom. EntitaKomponenta generalizuje entity Nadpis, Text, Obrázok, Linka, Animácia a Zvuk.Naviac každá z generalizovaných entít má svoj typ, ktorý vyjadruje vlastnostientity. Entity Nadpis a Text sú špecializované vz�ahom z typmi šablóny Štýlnadpisu a Štýl textu.
Kapitola – Táto entita vyjadruje kontext údajov spojených s kapitolou vrámci prezentácie. Ako sme spomenuli pri entite Prezentácia, prezentácia môžepozostáva� z nieko�kých kapitol. Táto entita vyjadruje hierarchické členeniekapitol so vz�ahom na nadpis kapitoly.
Šablóna – Reprezentuje údaj o predrobených šablónach aplikovate�nýchna obrazovku. Šablóna je predpis, akým štýlom majú by� zobrazené nadpisy,textu, pozadia prezentácie a podobne. Preto má táto entita vz�ahy s rôznymištýlmi. Samotné štýlu potom špecializujú typy jednotlivých komponent (vdiagrame je naznačená iba špecializácia textu a nadpisu kvôli preh�adnostidiagramu), tz. predpisujú typ pre konkrétnu komponentu.
Nadpis – Ide o základnú komponentu označujúcu kapitolu aleboobrazovku. Nadpis môže by� v priamom vz�ahu s kapitolou a ako taký ju definuje.Naopak, každá kapitola môže by� definovaná nadpisom, ale nie je to nutnos�.Obrazovky nemajú priamy vz�ah s nadpisom, ale môžu nadpis obsahova�.
Text – Ide o základnú komponentu prezentácie. Obsahuje textové pole�ubovolnej ve�kosti. Typ tejto komponenty môže by� druh písma, ve�kos� písma,farba písma, okraje a pod.
Obrázok – Ide o súbor s grafickým zobrazením. Typ obrázku sa v�ahujepredovšetkým na jeho formát, ale aj rozmery a pod.
Linka – Ide o odkaz prepájajúci rôzne časti textu v rámci prezentácie,alebo odkaz na index prezentácie (zoznam k�účových slov), alebo odkaz na inýdokument (dokument mimo prezentácie). Typy linky sa vz�ahuje na tietomožnosti a na rôzne druhy formátovania ako sú farba, ve�kos� a pod.
Animácia – Ide o súbor s dynamickým grafickým objektom. Typanimácie môže by� podobne ako pri obrázku jej rozmery, formát a pod.
Zvuk – Ide o odkaz na súbor so zvukovým záznamom. Typ zvuku hovorío formáte zvukového záznamu.
3.7 Návrh šablón
Cie�om návrhu šablón je vytvori� súbor napísaný v jazyku CSS2, ktorý dovolíopísa� základnú množinu elementov použitých pri značkovaní textu látkyprezentácie. Vzh�adom na to, že konkurenčný tím je postavený pred rovnakúúlohu, a na možnos� zdie�ania látky prezentácie medzi oboma tímami sme sarozhodli kooperova� s jeho členmi na vytvorení jednotého predpisu preformátovanie prezentácie. Okrem možnosti zdie�ania obsahu, formy alebo oboch,by táto spolupráca mala prinies� aj zvýšenie kvality návrhu, ke�že sa zvýšikontrola pri používaní týchto predpisov. Proces návrhu prebieha v úzkom súvises jeho implementáciou a ešte nie je ukončený, preto je potrebné prezentovanévýsledky bra� s oh�adom na túto skutočnos�.
Tímový projekt | Dokumentácia k inžinierskemu dielu 51
Jazyk CSS2 dovo�uje opísa� ve�mi širokú množinu elementov a umožňujerôzne spôsoby výberu týchto elementov. Preto je potrebné definova� zvládnute�núpodmnožinu elementov, ktorá by najlepšie vystihovala potreby tvorbymultimediálnej prezentácie obsahu predmetu na odbore Informatika.
3.7.1 Aktuálny zoznam elementov
Tento zoznam obsahuje elementy HTML, ktorých použitie je dohodnutés konkurenčným tímom a ktoré sú použité v prezentácii časti látky predmetuArchitektúra počítačov. Zoznam sa pravdepodobne ešte rozšíri, avšak tu uvedenéelementy by sa mali zachova�.
Element OpisBODY Reprezentuje pozadie, na ktorom je umiestnený všetok obsah
dokumentu.P Všeobecný odstavec. Základný text.P.formula Odstavec obsahujúci vzorec alebo iný obsah, ktorý má by�
odsadený z�ava ale nemá by� uvedený značkou.P.noteheader Odstavec obsahujúci text „Poznámka“. Má menší význam
ako nadpis štvrtej úrovne.P.note Odstavec obsahujúci text poznámky. Poznámka by mala by�
zobrazená písmom s menšou ve�kos�ou ako je základný textprezentácie.
P.object Odstavec obsahujúci vložený objekt. Napr. obrázok aleboanimáciu.
P.objecttext Odstavec obsahujúci opis obrázku. Napr. „Obr. č. x. …“PRE Odstavec obsahujúci text príkladu, výpis programu alebo iný
text, ktorý je potrebné zobrazi� fontom s pevnou šírkouznaku.
P.code Detto s tým rozdielom, že ide o normálny odstavec a teda jemožné použi� �alšie formátovanie ako úvodzovky, indexy,mocniny, zvýraznenia a pod.
SUB Dolný index. Používa sa najmä v matematických výrazoch.SUP Horný index. Detto.EM Bežné zvýraznenie. Používa sa všade, kde je potrebné vyznači�
čas� textu. Zvyčajne sa zobrazí ako kurzíva.STRONG Zvláštne zvýraznenie. Používa sa, ak je potrebné upozorni� na
zvláš� dôležitú čas� textu. Je potrebné používa� ho s mierou.Zvyčajne sa zobrazí ako polotučné písmo.
VAR Označenie premennej.IMG Obrázok.A Odkaz.H1 Nadpis kapitoly.H2 Nadpis podkapitoly.H3 Nadpis článku.H4 Nadpis štvrtej úrovne.UL Nečíslovaný zoznam.OL Číslovaný zoznam.
Tímový projekt | Dokumentácia k inžinierskemu dielu 52
LI Položka zoznamu.DL Definícia.DT Objekt definície.DD Text definície.TABLE Tabu�ka.
Tímový projekt | Dokumentácia k inžinierskemu dielu 53
4 Prototypovanie4.1 Ciele prototypovania
Táto čas� dokumentácie sa zaoberá prototypovaním vytváraného systému.Prototyp sme sa rozhodli vytvori� z dôvodov predvedenia niektorých požiadaviek,a teda predovšetkým pre spoluprácu so zadávate�om projektu. To znamená, že sazameriame na implementáciu jasných a zrejmých požiadaviek, s ktorými nie súžiadne pochybnosti vzh�adom na predstavy zadávate�a. Radi by sme poznamenali,že k nižšie uvedeným cie�om prototypovania sme dospeli po konzultácii sozadávate�om projektu.
Cie�om prototypovania je vytvori� jednoduché ovládacie prostredie, ktoréby umožnilo vytvori� základnú štruktúru prezentácie, umožnilo by editova� text avklada� niektoré základné komponenty ako obrázky, animácie a pod. Prototyp máposkytnú� preh�ad o vložených komponentách, poskytnú� zoznam týchtokomponent a zoznam obrazoviek. Dôležité je, aby systém vedel prekonvertova�špecifikáciu prezentácie do univerzálneho jazyka, aby bolo možné výslednúprezentáciu prezera� na �ubovolnom počítači. Nie je požiadavka, aby totoprostredie malo ucelenú formu, ktorá by bola použitá aj vo finálnom produkte.Je potrebné, aby toto prostredie jednoduchým spôsobom predviedlo príslušnépožiadavky. Nasleduje zoznam požiadaviek, ktoré má prototyp predvies�(požiadavky sú uvádzané s číslom zhodným s ID uvedeným v katalógupožiadaviek [vi� 2.1]):
1.1 Vytvorenie novej prezentácie1.2 Uloženie prezentácie1.3 Otvorenie existujúcej prezentácie.
Tieto požiadavky musia by� implementované, aby bolo umožnenézákladné manipulovanie s prezentáciou.
1.8.1 Export do HTML.Táto požiadavka musí by� implementovaná kvôli predvedeniumožností prekladania špecifikácie prezentácie do univerzálnehojazyka, pomocou ktorého je prezentácia prezerate�ná na�ubovolnom počítači. Túto požiadavku realizuje tzv. konverznáutilita.
2.1 Šablóny vzh�adu prezentácie. Je potrebné implementova� jednu šablónu, ktorá by bolaaplikovate�ná na prezentáciu a predpísala by jej vzh�ad.
Je potrebné poskytnú� už v prototype väčší komfort pre používate�aa umožni� mu do prezentácie vloži� obrázok alebo animáciu
6.1 Nové komponenty: Používate�ovi bude poskytnutý zoznamkomponent, z ktorého bude môc� jednoducho vybra� žiadanúkomponentu a použi� ju v prezentácii.
6.4 Obrazovková štruktúra prezentácie: Je potrebné, aby mal používate�k dispozícii preh�ad komponent, z ktorých pozostáva aktuálnaprezentácia.
1.0.0.1.1 Požiadavka na počítač tvorcu prezentácie.1.0.0.1.2 Požiadavka na počítač študenta prezentácie.
Samozrejme už v tejto fáze je potrebné, aby prototyp spĺňalsystémové požiadavky na náročnos� vyžadovaného hardvéru.
4.2 Vyhodnotenie prototypovania (systém)
Vyhodnotenie prototypu možno rozdeli� do dvoch základných skupín, ktorévychádzajú z návrhu softvérového systému.
4.2.1 Prostredie pre tvorbu prezentácii
Základom bola práca užívate�a so systémom a grafické prostredie. Navrhovanérozloženie základných prvkov na obrazovke, ktoré bude použité vo výslednejaplikácii, plne vyhovuje komfortnej práci. Prototyp umožňuje vkladanie trochrôznych druhov komponent na obrazovku – text, nadpis, obrázok. Obrázok a textsa vkladá ako cesta k súboru na disku. Nadpis je možné vytvára� v prostredíprototypu. Text a obrázok je možné upravova� len v externom editore. Výslednáaplikácia bude podporova� viacej komponent, ale výber bol zúžený len na tútomnožinu kvôli možnostiam prekladača realizovaného v prototype.
Text možno upravova� priamo v prototype. Ďalšia možnos�, ktorúprototyp podporuje, je vytvori� nový textový súbor a prida� ho priamo doprezentácie. Tento spôsob načrtol základné požiadavky pri úprave komponenty,ktoré sa bude da� využi� vo výslednej aplikácii – jednoduchos� prístupu k textu,jeho úprava a aktualizovanie komponenty v prezentácii.
Jednoduchos� práce s prototypom je možné zlepši� zadefinovanímklávesových skratiek pre najčastejšie používané funkcie, prípadne pridanietlačidiel, ktoré zastúpia najčastejšie používané funkcie.
4.2.2 Tvorba výstupnej prezentácie
Návrh prototypu predpokladal možnos� vytvorenia len jednej obrazovkyprezentácie. Po zadefinovaní základnej štruktúry pre prezentáciu bol návrhrozšírený na podporu viacerých obrazoviek. Odsimulovali sme si aj rozhranie,ktoré bude použité v hlavnej aplikácii pre komunikáciu s používate�skouknižnicou. Na simuláciu sme použili jedinú funkciu, ktorej vstupom je vytvorenáštruktúra obsahujúca prezentáciu. Funkcia predstavujúca používate�skú knižnicupotom z informácii obsiahnutých v štruktúre vytvorila výslednú prezentáciu.
Tímový projekt | Dokumentácia k inžinierskemu dielu 55
Pri realizácii bola tiež odskúšaná práca prekladača. Ten vytvára zo štruktúryvýsledné HTML dokumenty, ktoré potom pospája pomocou jednej stránky dovýslednej prezentácie. Z h�adiska toho, že nebolo možné implementova� všetkymožnosti prekladača, bol výber komponent zúžený na tri.
4.3 Vyhodnotenie prototypovania (prezentácia)
Ke�že prototyp prostredia pre tvorbu prezentácií nemôže a ani nemá za cie�obsiahnu� všetky potrebné elementy HTML, bolo potrebné vytvori� dokument,ktorý by umožnil návrh a odladenie šablóny formátovania. Za týmto účelom bolaupravená čas� textu skrípt z danej problematiky. Do tohto dokumentu bolapridaná sekcia, ktorá by mala obsahova� všetky navrhnuté elementy a takdemonštrova� vlastnosti šablóny.
Tímový projekt | Dokumentácia k inžinierskemu dielu 56
5 Podrobný NávrhKoncepcia návrhu systému priblížila spôsob práce a prístupu používate�ak systému. Detailnejší návrh jednotlivých častí systému poskytujú nasledujúcekapitoly. Zamerali sme sa na opis najdôležitejších vlastností systému. Niektorédetaily boli vynechané.
Základom systému je editor prezentácie.
5.1 Editor prezentácie
Základný modul aplikácie. Jeho úlohou je správa štruktúry celej prezentácie.Základom celej prezentácie sú komponenty umiestnené na obrazovkách.Obrazovky sú organizované pod�a následnosti.
Komponenty predstavujú vstup do systému. Text, obrázok, animáciaa zvuk sú komponenty uložené v externých súboroch. Sú podporovanénajčastejšie používane typy súborov. Ostatné komponenty – nadpis a odkaz sazadávajú priamo cez rozhranie aplikácie. Komponenty vstupujú do aplikácie cezmodul načítanie komponent. Ten na základe typu komponentu zabezpečínačítanie externých súborov v prípade, ak sú dáta komponenty uložené v súbore,alebo priame načítanie cez rozhranie v prípade odkazu a nadpisu. Externé súborysa automaticky kopírujú do adresára projektu.
Komponenty majú svoje vlastnosti. Napríklad font, zarovnanie, ve�kos�písma u textovej komponenty. Všetky tieto vlastnosti sú uložené v pamätikomponentov projektu. Pamä� komponentov obsahuje len vlastnostikomponentov a odkaz na súbor, kde sa nachádzajú dáta. Je tým zníženánáročnos� na pamä�. Text nadpisu a odkazu je vlastnos� komponenty, nie sú tedauložené na disku.
Pretože vlastnosti komponentov je potrebné upravova� aj neskôr cezrozhranie programu je tu modul správa vlastností komponent. Tá umožňujezmenu vlastností jednotlivých komponent. Pre textové komponenty jeimplementovaný jednoduchý textový editor, ktorý umožňuje úpravu textukomponenty.
Komponenty sú umiestňované na obrazovky. Obrazovky potom tvoriaprezentáciu. Po načítaní komponenty a jej uložení do pamäti komponent sakomponent umiestni na niektorú obrazovku, pod�a potrieb používate�a.Túto činnos� zabezpečuje modul správa štruktúry prezentácie. Jej úlohou jeposkytnú� používate�ovi možnos� meni� poradie komponent a obrazoviekprezentácie. Takto vzniknutá štruktúra prezentácie je uložená v moduleprezentácia.
Prezentácia je vlastne zre�azenie obrazoviek. Na každej obrazovkesa potom nachádza zre�azenie komponent. Komponenty na obrazovkesú určované len svojím poradovým číslom v pamäti komponent. Je tak možnépoveda�, že sú to len odkazy na komponenty uložené v pamäti komponent.
Prezentáciu je potrebné uloži� do výstupného súboru pre neskoršiepoužitie. Túto činnos� zabezpečuje v/v modul prezentácie. Jeho úloha je tedaukladanie a opätovné načítanie súboru prezentácie. Poskytuje však tiež pridanie
Tímový projekt | Dokumentácia k inžinierskemu dielu 57
prezentácie k už existujúcej prezentácii. Je tak možné spája� viaceré prezentáciedo jednej.
Prezentácia je nakoniec preložená pomocou externého modulu dll(konverzná knižnica) do výslednej prezentácie. Konverzná knižnica podporujeniektoré nastavenia, informácie o sebe a možnos� náh�adu prezentácie. Tietofunkcie sú prístupné pomocou modulu rozhranie dll.
Posledná funkcia, ktorú poskytuje konverzná knižnica je konverziaprezentácie. Pri tomto sa predá prezentácia konverznej knižnici, ktorá vykoná jejpreklad.
Obr. 12. DFD editora prezentácie
5.2 Konverzná utilita
Konverzná utilita je určená pre exportovanie projektu prezentácie, vytvorenejv editačnom programe, do �ubovolného formátu, ktorý je definovaný príslušnoukonverznou utilitou. Je reprezentovaná ako používate�ská knižnica, dynamickypripájaná k editoru (DLL – Dynamic-Link Library). Takýmto spôsobomje zabezpečená univerzálnos� editora a možnos� jeho rozšírenia o �ubovo�ný početformátov určených pre export projektu prezentácie.
Tímový projekt | Dokumentácia k inžinierskemu dielu 58
5.2.1 Vnútorná štruktúra konverznej utility
Na obrazku 2. sa nachádza základná koncepcia konverznej utility, ktorá zachytávaspoločne črty pre �ubovo�nú z nich. Poskytuje nasledovné funkcie:
Interpret údajov
Predstavuje načítanie projektu prezentácie zo vstupného súboru do údajovýchštruktúr, ktoré sú zhodné s údajovými štruktúrami editora pre uchovávanieprojektu prezentácie.
Obr. 13. DFD používate�skej knižnice
Tímový projekt | Dokumentácia k inžinierskemu dielu 59
Konvertovanie projektu prezentácie
Táto funkcia zabezpečuje samotné konvertovanie projektu prezentáciedo definovaného formátu, od ktorého taktiež závisí aj presný spôsob tejtokonverzie. Výsledok konverzie je súbor, alebo skupina súborov, ktoré v diagramepredstavuje úložisko prezentácia.
Zobrazenie prezentácie
Zabezpečí zobrazenie prezentácie po vykonaní konvertovania, pre účelskontrolovania výsledku. Z dôvodu použitia �ubovo�ného exportného formátu,je nutné, aby konverzná utilita samotná, definovala spôsob, akým sa prezentáciazobrazí po vykonaní konvertovania. Zobrazenie konvertovanej a uloženejprezentácie môže by� riešené interným prehliadačom, ktorý je súčas�ou konverznejutility, alebo pomocou externého prehliadača nainštalovaného na počítači,ktorý je definovaný explicitne programátorom alebo používate�om. Konečnériešenie zobrazenia je na slobodnej vôli programátora konverznej utility.Nako�ko zobrazenie prezentácie po vykonaní každého konvertovania môže by�rušivé, je možnos� túto funkciu obís� implementačne, alebo v rámci nastaveniakonverznej utility.
Nastavenie konverznej utility
Táto funkcia umožňuje vykona� nastavenie parametrov konverznej utility, ktorépriamo súvisia s konverziou, alebo so zobrazením prezentácie. Konkrétneparametre, ktoré bude možné nastavova�, závisia od typu konverznej utility.Nastavenie vykonáva tvorca projektu prezentácie prostredníctvom editora,pomocou ktorého bude možné funkciu nastavenia konverznej utility vyvola�.
5.2.2 Rozhranie konverznej utility
Nako�ko konverzná utilita bude môc� vykonáva� export do rozličných formátov,je nutné navrhnú� univerzálne rozhranie, ktoré umožní realizova� jej základnéfunkcie spolu s funkciami, ktoré sú nevyhnutné pre spoluprácu programus používate�skou knižnicou.
Identifikácia konverznej utility
Pomocou tohto rozhrania je možné, prenosom re�azca písmen, zisti� názovkonverznej utility, ktorý slúži na jednoznačné pomenovanie, pod ktorýmsa konverzná utilita bude v editori identifikova�.
Opis konverznej utility
Pomocou tohto rozhrania je možné, taktiež prenosom re�azcom písmen, zisti�stručný opis používate�skej knižnice, ktorý poskytuje základné informácieo používate�skej knižnici.
Tímový projekt | Dokumentácia k inžinierskemu dielu 60
Konvertovanie projektu prezentácie
V tomto prípade je prenášaným údajom opä� re�azec písmen, ktorý definujeumiestnenie a názov súboru, v ktorom je projekt prezentácie uložený.To znamená, že pred vykonaním konvertovania je nutné projekt prezentácieuloži� na pevný disk alebo iné záznamové médium.
Náh�ad na projekt prezentácie
Toto rozhranie je prakticky totožné s rozhraním konvertovania projektuprezentácie, no dopĺňa ho o možnos� definovania časti projektu prezentácie,na ktorú sa náh�ad vytvára. Definovanie týchto častí je umožnené pomocou dvochceločíselných parametrov.
Nastavenie konverznej utility
Cez toto rozhranie sa neprenášajú žiadne údaje. Ide iba o volanie funkciekonverznej utility, ktorá umožní jej nastavenie priamym editovaním parametrovkonverznej utility. Toto riešenie je opodstatnené tým, že každá konverzná utilitamôže ma� vlastnú sadu parametrov pre nastavovanie, prípadne žiadne, a niejepreto možné vykonáva� nastavenie univerzálne pomocou editora a následnýmprenosom parametrov vo forme toku údajov.
5.3 Návrh konverznej utility do formátu HTML
Nako�ko cie�om projektu je vytvorenie webovej multimediálnej prezentácie,je navrhnutá konverzná utilita, ktorá zabezpečí konvertovanie projektu prezentáciedo statickej HTML stánky. Pre potreby formátovania vzh�adu stránky sú použitékaskádové štýly.
Základná koncepcia konverznej utility do formátu HTML(HTML konvertor) je totožná so základnou koncepciou uvedenou v kapitole 5.2.Nako�ko však ide o konkrétnu implementáciu, je nutné upresni� významyjednotlivých funkcií a opísa� detailnejšie ich funkciu.
5.3.1 Nastavenie konverznej utility
Parametre, ktoré je možné ovplyvňova� sú nasledovné:– výber externého prehliadača pre prezeranie prezentácie po skonvertovaní,
pričom je umožnené deaktivova� zobrazenie skonvertovanej prezentácie,alebo jej časti po vykonaní konverzie
– cesta k priečinku, do ktorého sa budú uklada� súbory vytváranépri tvorení náh�adu na určitú čas� prezentácie
– druh použitých kaskádových štýlov pre formátovanie obsahupoužívate�om vytvorených obrazoviek (predpripravené, špeciálne určenépre konvertovaný projekt prezentácie)
– nastavenie vzh�adu používate�ského rozhrania prezentácie,kde si používate� môže vybra� časti, ktoré budú tvori� používate�skérozhranie (nadpis prezentácie, obsah, navigačnú lištu) ako aj ich rozmer.
Tímový projekt | Dokumentácia k inžinierskemu dielu 61
V prípade obsahu si môže ešte vybra� spôsob použitej technológiepre jeho vytvorenie (HTML, JavaScript). Pre potreby špecifikovaniaformátovania používate�ského rozhrania je možné vybra� súborkaskádových štýlov, v ktorom je definované jeho formátovanie nezávisleod formátovania používate�ských obrazoviek.
5.3.2 Konvertovanie projektu prezentácie
Na obrázku 3. je znázornený DFD funkcie, ktorá vykonáva samotnékonvertovanie projektu prezentácie do HTML stránky. Táto funkcia zabezpečujekonvertovanie projektu prezentácie do HTML stránky. Ako zdroj prekladu čerpáúdaje z úložísk Obrazovky, Komponenty a Štruktúra nadpisov, v ktorých súuložené všetky potrebné údaje o projekte prezentácie. Pre potreby riadeniakonverzie použije údaje z úložiska Nastavenie, v ktorom sú uložené všetkypotrebné parametre nastavené pomocou funkcie Nastavenie konverznej utility,určujúce spôsob konverzie. Výsledok konverzie predstavuje úložisko HTMLprezentácia, ktorého obsah je tvorený skupinou súborov (HTML dokumenty,súbory kaskádových štýlov, obrázky, animácie…), zaradené do viacerých adresárovpre väčšiu preh�adnos�i.
Obr. 14. DFD konvertovania projektu prezentácie do HTML
Z analýzy vychádzajúc poskytuje nasledovné funkcie, ktoré sú potrebnépre vykonanie konverzie a to v nasledovnom poradí:
Tímový projekt | Dokumentácia k inžinierskemu dielu 62
Tvorenie CSS šablón
Ide o funkciu, ktorá zabezpečuje tvorbu dvoch nezávislých súborov kaskádovýchštýlov (*.CSS súbory) pre formátovanie používate�ského rozhrania a obrazoviek.
Pre potrebu formátovania vzh�adu používate�ského rozhrania sa používapredpripravený súbor kaskádových štýlov s pevným formátom, v ktorompoužívate� môže dodatočne meni� parametre jednotlivých štýlov.
Pre potrebu formátovania vzh�adu vytváraných obrazoviek sa používa bu�predpripravený, podobne ako pri používate�skom rozhraní, alebo generovanýkaskádový súbor. Obsah generovaného kaskádového súboru sa tvorí na základeinformácii získaných z nastavení jednotlivých komponent, ktoré tvoria obsahobrazoviek prezentácie.
Tvorenie používate�ského rozhrania prezentácie
Funkcia vytvorí HTML dokumenty, ktoré budú tvori� základ používate�skéhoprostredia HTML prezentácie. Ide o vytvorenie nasledovných častí:
– Štartovacia stránka – ktorá tvorí základ celej HTML prezentácie adefinuje rozmiestnenie jednotlivých prvkov rozhrania.
– Nadpis – slúži na zobrazenie názvu a prípadne autora prezentácie– Obsah – obsahuje obsah prezentácie tvorený z nadpisov umiestnených
v prezentácii. Pomocou neho je možná rýchla navigácia a pohyb pojednotlivých kapitolách prezentácie.
– Navigačná lišta – obsahuje tlačítka pre jednoduchý pohybpo obrazovkách. Pohyb je umožnený o jednu obrazovku vpred a vzada zobrazenie prvej obrazovky.
Tvorenie používate�ských obrazoviek
Je to najdôležitejšia funkcia, ktorá zabezpečuje konvertovanie obrazovieka komponentov z projektu prezentácie do HTML dokumentov a ich formátovaniezabezpečuje pomocou už vytvorených kaskádových štýlov. Aby sa zabezpečilamodulárnos� tejto funkcie, a umožnilo sa jednoduché dopĺňanie nových druhovkomponent, obsah obrazovky sa vytvára postupným konvertovaním jednotlivýchkomponent. Pre každú komponentu je tak určená samostatná konverzná funkcia,ktorých doplnením, alebo zmenením sa dajú jednoducho rozširova� možnostikonverznej utility.
Kopírovanie zdrojov
Táto funkcia zabezpečuje skopírovanie všetkých súborov (obrázky, animácie,odkazované dokumenty…) potrebných pre správne zobrazenie a fungovanieHTML prezentácie do adresárov prezentácie. Takýmto spôsobom sú všetkypotrebné súbory sústredené na jedno miesto, čo umožňuje jednoduchúmanipuláciu s vytvorenou prezentáciou, jej prípadné kopírovanie, alebodistribuovanie na CD-ROM nosičoch.
Tímový projekt | Dokumentácia k inžinierskemu dielu 63
5.3.3 Zobrazenie prezentácie
Umožňuje zobrazenie prezentácie pomocou externého web prehliadača.Jeho výber je umožnený prostredníctvom funkcie nastavenia konverznej utility.
5.4 Formátovanie prezentácie
Táto čas� dokumentácie nadväzuje na kapitolu 3.7 a venuje sa opisu prvkovpoužívate�ského rozhrania prezentácie – titulného pruhu, navigačného pruhua pruhu s obsahom.
5.4.1 Titulný pruh
Titulný pruh plní orientačnú funkciu na najvyššej úrovni – prezentuje názovprezentácie a autora jej obsahu. Z rôznych dôvodov sa najčastejšie umiestňujena horný okraj priestoru pre prezentáciu.
Vzh�adom na to, že pri prezeraní prezentácie plochu obrazovky častozaberajú aj �alšie prvky (panel úloh a stavový riadok naspodu a titulný panel,panel ponuky, lišta s ikonami a prípadne �alšie hore), zmenšuje sa priestor presamotný obsah prezentácie vo vertikálnom smere. Naopak, požiadavkana rozumnú šírku riadkov vedie k uvolneniu okrajov tohto priestoru. Na základetýchto okolností boli vytvorené dve alternatívne riešenia umiestnenia titulnéhopruhu – zvyčajné (hore) a moderné (na pravom okraji umiestnené zvislo).
Pri použití prvého je potrebné minimalizova� jeho rozmery. V jehoprospech hrá to, že text môže by� priamo zapísaný v HTML. Druhý naopakumožňuje uvo�ni� priestor navrchu, avšak jeho obsah je potrebné vytvori�v grafickom editore a vloži� ako obrázok.
Bolo by ideálne, keby si používate� mohol zvoli�, ktoré umiestnenie a akýspôsob zadávania informácií mu vyhovuje.
5.4.2 Navigačný pruh
Navigačný pruh by mal pomáha� používate�ovi orientova� sa v prezentácii(napr. poskytnú� informáciu o pozícii v texte) a u�ahči� mu základný pohyb v jejobsahu (vpred, vzad, o úroveň vyššie).
Pri našom projekte sme sa rozhodli umiestni� navigačný pruh na spodnýokraj. Toto umiestnenie ako i rozhodnutie o minimalizácii ve�kosti navigačnýchprvkov (nezaberajú ani tretinu šírky pruhu) prirodzene vytvorilo priestorna umiestnenie informácie o vlastníkovi autorských práv k prezentácii.
Kvôli jednoduchosti a prenosite�nosti boli navigačné funkcie obmedzenéna odkazy umožňujúce presun na predchádzajúcu, nasledujúcu a prvú obrazovkuv rámci prezentácie. Tieto odkazy sú umiestnené v�avo a umiestnenie informácieo vlastníkovi autorských práv vpravo.
Tímový projekt | Dokumentácia k inžinierskemu dielu 64
5.4.3 Pruh s obsahom
Významným pomocníkom pri orientácii a navigácii v prezentácii je obsah.Je dobré, ak je vždy poruke, ale. Čím je podrobnejší (a tým aj užitočnejší),tým je rozsiahlejší a znovu sú�aží o priestor s podávanou látkou.
Jeho dostupnos� je vyriešená tým, že je mu venovaný samostatný pruhumiestnený na�avo. Kompromisom medzi použite�nos�ou, podrobnos�oua zabraným priestorom bolo obmedzenie hĺbky zobrazovanej hierarchie na triúrovne. To znamená, že nadpisy štvrtej úrovne, ktoré namajú ani číslovanie,sa v obsahu nezobrazujú. Hierarchia je vystihnutá ve�kos�ou a rezom písmaa odsadením. Takže číslovanie, ktoré nie je kritické pre orientáciu a zaberánezanedbate�né miesto, bolo presunuté do popisiek, ktoré sa zobrazia pri krátkompodržaní ukazovate�a myši na položke.
Ďalším spôsobom ako spríjemni� prácu s obsahom je použitierozba�ovacieho stromu. Jeho vetvy sa rozbalia / zbalia pri kliknutí na symbol prednadpisom.
Po kliknutí na nadpis v obsahu je zobrazená v hlavnom priestoreprezentácie čas� látky začínajúca zvoleným nadpisom.
Tímový projekt | Dokumentácia k inžinierskemu dielu 65
6 Implementácia6.1 Editor prezentácie
Základom celej aplikácie je štruktúra zre�azená vo�ná pamä� (ZVP).
6.1.1 Zreťazená voľná pamäť
Ide o obojsmerne zre�azenú pamä�, do ktorej je možné uloži� �ubovo�nú dátovúštruktúru. Poskytuje množstvo operácií, takže pri dedení nie je potrebnéimplementova� také ve�ké množstvo nových metód.
6.1.2 Dedené dátové štruktúry
Zo zre�azenej vo�nej pamäti sú potom odvodené ostatné dátové štruktúryv programe.
6.1.3 Štruktúra prezentácie
Prezentácia je využitie možnosti vklada� do ZVP �ubovolnú štruktúru. ZVPpredstavuje zoznam obrazoviek. Prvkom je obrazovka. Tá obsahuje zre�azeniekomponentov na obrazovke. Toto zre�azenie je tiež tvorené ZVP. Do jednotlivýchbuniek ZVP zre�azenia obrazoviek sa tak vkladá opä� ZVP zre�azeniekomponentov na obrazovke. Prvok zre�azenia komponentov je tvorený typomkomponentu a odkazom do pamäte komponentov. V nej sú uložené atribútyobrazoviek.
6.1.4 Pamäť komponentov
Pamä� komponentov je špeciálna štruktúra. V tomto prípade je celá ZVProzdelená na časti. Každá čas� je číslovaná od nuly. Jednotlivé časti sú použiténa ukladanie komponentov. Pridávanie komponentov je jednoduchá záležitos�.Stačí prida� komponent a priradi� jej prvé vo�né poradové číslo. Prvé vo�né,pretože ak sa zmaže komponent, ostatné komponenty si musia zachova� svojeporadové číslo. Vznikajú tak diery. A nové komponenty sa musia uklada� na prvévo�né miesto. Dôvod, prečo sa vznikajú tieto diery je v tom, že v štruktúreprezentácie sú uložené len odkazy do pamäti komponent. Ak by sa číslovanieposúvalo, musela by sa prečíslova� celá prezentácia.
6.2 Rozhranie konverznej utility
Rozhranie konverznej utility má za úlohu sprístupni� funkcie používate�skejknižnice. Zároveň presne definuje spôsob komunikácie medzi používate�skouknižnicou a programom, ktorý využíva jej funkcie. Pre zabezpečenie tejtokomunikácie sú definované nasledovné funkcie:
Tímový projekt | Dokumentácia k inžinierskemu dielu 66
�������������� �������������������
����������������������
Funkcia, ktorá po zavolaní vráti znakový re�azec ukončený znakom ����,obsahujúci názov konverznej utility.
Funkcia, ktorá zabezpečí vytvorenie náh�adu na preložený projektprezentácie v definovanom formáte. Vstupom je znakový re�azecukončený znakom ���� (���%�&�'! ��), ktorý obsahuje absolútnu cestuk projektovému súboru a dvojica celočíselných parametrov(���, ���)�����), ktoré bližšie definujú čas� prezentácie, pre ktorú sa mánáh�ad vytvori�. Výstupom funkcie je dvojhodnotový príznak, ktorýurčuje, či bolo vytvorenie náh�adu na vybranú čas� prezentácie úspešnéalebo nie.
Funkcia, ktorá zabezpečí finálny preklad projektu prezentáciedo definovaného formátu. Vstupom je znakový re�azec ukončený znakomNULL (���%�&�'! ��), ktorý obsahuje absolútnu cestu k projektovémusúboru. Výstupom funkcie je dvojhodnotový príznak, ktorý určuje, či bolpreklad prezentácie úspešný alebo nie.
6.3 Konvertovanie projektu prezentáciedo formátu HTML
Finálny preklad ako aj vytváranie náh�adu prezentácie je v podstate rovnaké.Líšia sa iba v spôsobe adresovania zdrojov (obrázky, animácie, prípadne iné nietextové časti prezentácie) v jednotlivých HTML dokumentoch. V prípadefinálnej kompilácie sú všetky tieto zdroje nakopírované v poslednej fázekompilácie do adresárov vytváranej prezentácie a použijú sa referencie na taktoskopírované zdroje pomocou relatívnych adries. V prípade vytvárania náh�adu,
Tímový projekt | Dokumentácia k inžinierskemu dielu 67
aby sa zamedzilo zbytočnému kopírovaniu niekedy objemných súborov,sa použijú referencie na zdroje uložené v projektových adresároch pomocouabsolútnych adries.
Pre účely procesu kompilácie projektu prezentácie sú implementovanénasledovné objekty:
��������� – slúži ako hlavný objekt, ktorý v sebe združuje ostatné pomocnéobjekty. Obsahuje všetky potrebné parametre a metódy pre vytvorenieHTML prezentácie z údajov získaných z projektu prezentácie.
�'���� �������� – slúži pre tvorbu súborov kaskádových štýlov a topredovšetkým v prípade tvorby explicitných kaskádových štýlov, kde saprezentácia formátuje presne pod�a používate�ského nastaveniajednotlivých komponentov.
�'�������� – slúži ako preklenutie medzi vnútorným procesom kompiláciea používate�om. Nako�ko proces kompilácie je nezávislý od vývojovéhoprostredia, slúži tento objekt ako akási jednotná informačná štruktúra,do ktorej sa počas procesu kompilácie zapisuje jej stav, a metódy,ktoré slúžia pre správu používate�ského rozhrania konverznej utility,z nej tieto informácie môžu číta� a následne zobrazova�.
6.3.1 Tvorenie CSS šablón
Pre potrebu vytvárania kaskádových štýlov je implementovaná metóda���������**������'���� , ktorá vytvorí obsah súborov kaskádových štýlova uloží ich do príslušných súborov.
Pre tvorbu obsahu kaskádového súboru pre používate�ské prostredie slúžimetóda �'���� ��������**������'����+������������, ktorá iba otvorísúbor kaskádových štýlov vybraný používate�om a vráti jeho obsah.
Pre tvorbu obsahu kaskádového súboru pre obrazovky slúži metóda�'���� ��������**������'����+���'����� , ktorá pracuje v dvoch módoch.V prvom obdobne ako predošlá metóda a v druhom, ak používate� vyberiepoužitie explicitného formátovania, zabezpečí programové vytvorenie obsahusúboru kaskádových štýlov pod�a formátovacích informácií obsiahnutýchv komponentoch. Na to využíva metódy �'���� ��������**+��#�����,pomocou ktorej sa identifikujú jedinečne zformátované komponenty a '����"�'���� ��������**������'����+���'����� ,�������, ktorá slúžina vytvorenie samotného obsahu kaskádového súboru na základe jedinečnezformátovaných komponent.
6.3.2 Tvorenie používateľského prostredia prezentácie
Vytváranie používate�ského prostredia prezentácie zabezpečuje metóda���������**���������������, ktorá postupne zavolá metódy, ktoré zabezpečiavytvorenie jednotlivých HTML dokumentov tvoriacich používate�ské prostredie.
���������**���������� – vytvorenie štartovacieho HTML dokumentu(index.html), ktorý definuje rozmiestnenie jednotlivých častípoužívate�ského prostredia pomocou HTML rámcov.
���������**������-�� – vytvorenie hornej časti používate�skéhoprostredia, ktorá obsahuje názov prezentácia a jej autora.
Tímový projekt | Dokumentácia k inžinierskemu dielu 68
���������**������-�� – vytvorenie obsahovej časti navigácie. V základezabezpečí vytvorenie obsahovej štruktúry prezentácie pomocou HTMLtagov, no taktiež je možnos� jej vytvorenia pomocou JavaScriptu, čozabezpečí metóda ���������**������-��.���.
���������**������/����� – vytvorenie spodnej časti používate�skéhoprostredia, ktoré obsahuje možnos� navigácie pohybom po obrazovkáchpomocou jednoduchého JavaScriptu.
���������**������+���� – vytvorenie prázdneho dokumentu, ktorý jepoužitý ako okreje používate�ského prostredia.
6.3.3 Tvorenie používateľských obrazoviek
Tvorenie obrazoviek zabezpečuje jednoduchá metóda���������**������'��������, ktorá v slučke pre každú obrazovku volámetódu ���������**������'�����0��, ktorá zabezpečuje vytvorenie HTMLdokumentu reprezentujúceho konkrétnu obrazovku. Táto metóda v slučkeprechádza a prekladá jednotlivé komponenty umiestnené na obrazovke a takskladá obsah danej obrazovky.
Pre preklad každého druhu komponenty je určená jedna metóda,ktorá špecifickým spôsobom zabezpečí jej preklad a vráti jej HTML zápis.
Pri preklade jednotlivých komponent sa používa tiež metóda�'���� ��������**1��'��������, ktorá slúži na zistenie označeniakaskádového štýlu pre konkrétnu komponentu.
6.3.4 Kopírovanie zdrojov
Kopírovanie zdrojov zabezpečuje metóda ���������**����+��� ���,ktorá podobne ako v prípade tvorenia obrazoviek, v slučke volá metódu���������**����+��� 0��, ktorá zabezpečuje kopírovanie zdrojovz jednotlivých komponent nachádzajúcich sa na konkrétnej obrazovke.
Pre každú relevantnú komponentu je implementovaná samostatnámetóda, ktorá zabezpečuje identifikovanie zdroja v komponente a pomocoumetódy ���������**����+��� jeho skopírovanie do adresárov prezentácie.
6.3.5 Stav konvertovania prezentácie
Aby používate� mohol by� informovaný o stave práve prebiehajúcejprezentácie je implementovaný objekt �'��������. Ten reprezentuje stavprekladu prezentácie vo vnútorných premenných spolu s ich prípadným bližšímpopisom či doplňujúcimi informáciami. Počas prekladu sa jeho stav spolus informáciami zapisuje do tohoto objektu pomocou metódy�'��������**'��#��"�� a �'��������**'��'����. Pomocou metódy���������**1��'�������� sa tieto informácie môžu z objektu prečíta�a následne zobrazi� používate�ovi.
Tímový projekt | Dokumentácia k inžinierskemu dielu 69
6.4 Formátovanie prezentácie
Súhra HTML, CSS, JavaScript-u, Flash a obrázkov vytvára komplex prezentácie,ktorá je výsledným produktom programu a ktorá je zodpovedná za dojemkoncového používate�a. Pre potreby knižnice konvertujúcej prezentáciu do HTMLboli vytvorené tri prototypy prezentácie (�alej ich budeme nazýva� skrátenešablóny).
Šablóna č. 1 bola vytvorená ako prvá s umiestnením titulného pruhuhore. Šablóny č. 2 a 3 majú titulný pruh umiestnený vertikálne na pravom okraji.Šablóny č. 1 a 2 sú totožné až na umiestnenie titulného pruhu. Šablóna č. 3má modernejší vzh�ad.
Obr. 15. Šablóna č. 1
6.4.1 Organizácia súborov
Prezentácia je organizovaná do súborov. Súbor ����2���� obsahuje opisrozloženia jednotlivých rámcov prezentácie (hlavný [����], titulný, navigačnýa obsah). Každý z týchto rámcov je opísaný vo zvláštnom súbore(jednotlivé súbory [obrazovky] prezentácie, ���2����, ��2���� a ���2����).
Štýly sú definované v samostatnom súbore s príponou .css a pripájajúsa ku každému súboru reprezentujúcemu rámec prostredníctvom značky 3���45v hlavičke HTML. Rovnako je v hlavičke definovaná znaková sada a titul súboru.
6.4.2 Používateľské rozhranie
Ako už bolo spomenuté, používate�ské rozhranie je tvorené súbormi ���2����, ��2���� a ���2����.
Súbor ���2���� v šablóne č. 1 obsahuje dva riadky textu, pričom prvý jeoznačený ako 67 triedy -���� a druhý ako # triedy �!����. V šablónach č. 2 a 3je miesto nich použitý obrázok vo formáte JPEG s rozmermi 32 × 423 pixelov.
Tímový projekt | Dokumentácia k inžinierskemu dielu 70
Vo všetkých šablónach je telo titulného pruhu triedy ��� a v ňom je definovaný)�8 tiež triedy ���.
Obr. 16. Šablóna č. 2
Navigácia v súbore ���2���� je riešená vloženým JavaScript kódom.Tri funkcie (������, ��&�� a ������) operujú nad po�om ��"�����,v ktorom sú zapísané mená súborov obsahujúcich jednotlivé obrazovky,a premennou �� �����, uchovávajúcou aktuálnu obrazovku. Po kliknutína navigačné odkazy (# triedy ���, � tridy ���) sa zavolá príslušná funkcia,ktorá do hlavného rámu prezentácie načíta príslušný súbor. Navigačné odkazysú uzavreté do )�8 triedy ��� �� a informácia o vlastníkovi autorských právdo � triedy ����� � a )�8 triedy ������"��. Telo je opä� triedy ���.
Najzložitejšou čas�ou používate�ského rozhrania je pruh s obsahom.Do súboru ���2���� sú vložené odkazy na dva JavaScript-ové súbory – – ����2% a ��!��!��2% . Prvý z nich obsahuje kód rozba�ovacieho stromu(ide o upravený kód z ����*99$$$2 �����$��2���9���!�� 9����9), druhýdefinuje jeho štruktúru. Čo sa týka formátovania, telo i oddiel )�8 sú triedy ���.Pre obsah je definované zvláštne formátovanie nadpisov, ke�že takto sú označenéjeho jednotlivé položky. So stromom súvisí trojica obrázkov rozmeru 22 × 12pixelov �2%�", �2%�" a �2%�" zobrazujúcich sa pri otvorenej a zatvorenej vetvestromu a pri listoch v tomto poradí.
Štruktúra obsahu sa určuje obsahom premennej -:,,�0),'.tá obsahuje záznamy ������ (globálne formátovanie obsahu) a ! (vlastná štruktúra). Záznam ! obsahuje nadpisy najvyššej hierarchie definovanépoložkami ���� (nadpis), !�� (cesta k cie�u), ���"�� (vždy ;����;), �����(popis v bubline, štandardne nadpis s číslom), prípadne �alší ! obsahujúcinižšiu úroveň. Položka ! teda umožňuje rekurzívne použitie.Obsah sa do vlastného súboru ���2���� vloží vytvorením nového'���)��$��-��� v kóde JavaScript-u.
Tímový projekt | Dokumentácia k inžinierskemu dielu 71
Obr. 17. Šablóna č. 3
6.4.3 Látka prezentácie
Vlastný obsah prezentácie sa nachádza v hlavnom ráme prezentácie označenomako ����. Rovnako všetky odkazy nasledované z látky prezentácie sa zobrazujúv tomto priestore. Umiestnenie textu prezentácie do prostriedka obrazovky bolodocielené použitím 20% okraja vpravo.
Tímový projekt | Dokumentácia k inžinierskemu dielu 72
7 TestovanieTáto kapitola sa zaoberá testovaním vytváraného systému. Testovanie systému jedôležitou fázou životného cyklu softvéru a nie je možné túto čas� opomenú� alebozanedba�. Testovanie prebiehalo na verzii systému VSAM Editor v2.0 a podie�alisa na ňom tak vývojári ako aj externí spolupracovníci. V tejto kapitole opisujemevšetky testy, ktoré boli vykonané na spomenutej verzii systému.
Samotnú fázu testovania sme rozdelili na dve časti – alfa testovanie a betatestovanie. Čas� alfa testovania bola vykonávaná v prostredí vývoja. To znamená,že testovaný systém bol spustený na počítači, na ktorom sa vyvíjal a testovali hovývojári. Po úspešnom dokončení alfa testovana, sme prešli k beta testovaniu.Ide o fázu, kedy bol systém poskytnutý externým spolupracovníkom, ktorí systémtestovali pod�a návodu v prostredí zákazníka.
7.1 Alfa testovanie
V tejto časti uvádzame zoznam všetkých testov, ktoré boli vykonané na systémevo fáze alfa testovania. Testy boli vykonávané vývojármi systému a vyústilido verzie systému 0.9. Testy sú zoradené v tabu�kách pre väčšiu preh�adnos�.
Legenda:
ID – Identifikačné číslo testuNázov – Názov testuPožiadavky – Číslo požiadavky, ktorá je testovaná
(pod�a katalógu požiadaviek)Účel – Cie� testuPodmienky – Podmienky, ktoré musia by� splnené pri vykonaní testu.Krok – Čas� testuAkcia – Úloha, ktorá sa musí pri teste vykona�Očak. reakcia – Želané správanie sa systému pri vykonanej akciiPoznámka – Dodatok k časti testu
Tímový projekt | Dokumentácia k inžinierskemu dielu 73
Tímový projekt | Dokumentácia k inžinierskemu dielu 74
Tímový projekt | Dokumentácia k inžinierskemu dielu 75
Tímový projekt | Dokumentácia k inžinierskemu dielu 76
Tímový projekt | Dokumentácia k inžinierskemu dielu 77
Tímový projekt | Dokumentácia k inžinierskemu dielu 78
7.2 Beta testovanie
Beta testovanie slúži na overenie funkčnosti systému v prostredí používate�a.Na tento účel sme poskytli systém VSAM verzie 0.9 nieko�kým používate�om,ktorý nespolupracovali na vývoji, aby systém otestovali. Ako postup testovaniaslúži nasledujúca tabu�ka. Pod�a šablóny vyplní obsluha náhodný početobrazoviek, nie však menší ako 15. Výsledný projekt od nieko�kých nezávislýchzdrojov je overovaný, či sú splnené všetky požiadavky kladené na systém.
Tímový projekt | Dokumentácia k inžinierskemu dielu 79
Tímový projekt | Dokumentácia k inžinierskemu dielu 80
8 ZáverVýsledkom nášho dvojsemetrového snaženia je systém, ktorý umožňuje vytvára�prezentácie pre potreby predmetu Architektúra počítačov. Pozostáva z dvoch častí.Prvou je samotný editor prezentácie, kde je možné pridáva� podporovanékomponenty. Prístup k tomuto modulu má pedagóg, ktorý tvorí prezentáciu.Výstup je zabezpečený cez používate�skú knižnicu. Tá konvertuje prezentáciudo výstupnej formy HTML stránky. K tomuto výstupu ma prístup študent.Prezentáciu je možné prehliada� vo vo�ne dostupných prehliadačoch, takžeje zabezpečená jej dostupnos�.
Z h�adiska možností však musíme konštatova�, že návrh systému je�aleko širší a umožňuje ve�ké možnosti. Náš implementovaný systém je plnefunkčná demonštrácia jeho možností. Na komplexnú implementáciu je všakpotrebný dlhší čas. Predbehli sme tak aj požiadavky zadania.
Funkčnos� navrhnutého systému je možné overi� na implementovanejaplikácii so vzorkou študijných materiálov z predmetu Architektúra počítačov.
Tímový projekt | Dokumentácia k inžinierskemu dielu 81
Tímový projekt | Dokumentácia k riadeniu projektu
1
Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Tímový projekt
Multimediálna podpora predmetu Architektúra počítačov
Dokumentácia k riadeniu projektu
Tím č. 9 Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel Mésároš Vedúci tímového projektu: Ing. Ján Hudec letný semester šk. r. 2003/2004
Tímový projekt | Dokumentácia k riadeniu projektu
2
Obsah 0 Úvod................................................................................................................................I 1 Ponuka............................................................................................................................II 2 Plán projektu.................................................................................................................III 3 Úlohy členov tímu........................................................................................................IV 4 Zápisy zo stretnutí..........................................................................................................V 5 Posudky........................................................................................................................VI 6 Preberacie protokoly...................................................................................................VII 7 Štábna kultúra............................................................................................................VIII
Tímový projekt | Dokumentácia k riadeniu projektu
1
0. Úvod Dokumentácia riadenie projektu obsahuje všetky aspekty potrebné k získaniu prehľadu o riadení nášho projektu Multimediálna podpora predmetu Architektúra počítačov. Jej účelom je v čo najväčšej miere zefektívniť prácu tímu ako aj podporovať plánovanie a riadenie procesu tvorby výsledného produktu. Obsahovo je tvorený z nasledujúcich častí: • Ponuka – obsahuje kompletnú ponuku nášho tímu spolu s jej prezentáciou • Plán projektu – rozpis dlhodobých plánov na dané časti vývoja systému, ako aj
krátkodobé plány, ktoré sa budú priebežne dopĺňať. • Úlohy členov tímu - obsahuje podrobne rozpísané jednotlivé úlohy členov tímu
z dlhodobého ako krátkodobého hľadiska. Ďalej obsahuje rozdelenie práce pri tvorbe jednotlivých článkov ako aj percentuálne vyjadrenie práce členov tímu na jednotlivých kapitolách.
• Zápisy zo stretnutí – záznamy zo všetkých doposiaľ vykonaných stretnutí, ktoré boli venované tímovému projektu.
• Posudky – k jednotlivým kontrolným bodom pre náš projekt ako aj projekt konkurenčného tímu.
• Preberacie protokoly – doklady o prevzatí dokumentácie vedúcim tímového projektu na príslušných kontrolných bodoch.
• Štábna kultúra – všeobecne dodržiavané pravidlá pri tvorbe projektu a dokumentácie.
Tímový projekt | Dokumentácia k riadeniu projektu
1
1. Ponuka V tejto kapitole uvádzame kompletnú ponuku ako sme ju prezentovali v treťom týždni semestra. Ponuka sa bola vypracovaná na projekt Multimediálna podpora predmetu Architektúra počítačov. Na tomto mieste uvádzame aj priesvitky vytvorené za účelom prezentácie. 1.1 Obsah ponuky Predstavenie tímu
Riešiteľský tím pozostáva z piatich študentov inžinierskeho štúdia Fakulty informatiky a informačných technológií Slovenskej technickej univerzity v Bratislave. Bc. Viliam Bedeč Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje už devä_ rokov. Začal programovaním v jazyku Basic. Štyri roky programuje v jazyku C/C++. Vytvoril softvérový produkt EIFL vo vývojovom prostredí Borland C++ Builder, ktorý bol publikovaný v časopise PC World. (Ide o kompresor zvukových súborov do formátu MP3.) V rámci bakalárskeho projektu vytvoril softvérový systém pre chemickotechnologickú fakultu STU v Bratislave pre spracovanie cyklovoltampérmetrických meraní. Ďalej ovláda programovanie v jazykoch asemblér, VHDL, PHP, HTML. Má skúsenosti s tvorbou aplikácii menšieho rozsahu. Bc. Peter Hlocký Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Tvorbe softvérových produktov sa venuje vyše 8 rokov. Prvé skúsenosti s programovaním nabral pri kódovaní v jazyku Pascal. Z ďalších programovacích jazykov ovláda C++ a VHDL. Má skúsenosti s tvorbou programov v strojovom jazyku procesorov rodiny 51 a x86. Je tvorcom hardvérovej časti statického vnútroobvodového emulátora a jeho firmvéru pre KIVT FEI STU. Počas praxe nabral skúsenosti s webovými aplikáciami, HTML a s interpretom PHP. Bc. Marek Hrablay Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje sedem rokov. Ovláda programovanie v C/C++ a Macromedia Flash MX. Má praktické skúsenosti s tvorbou aplikácií menšieho rozsahu. Je tvorcom ovládacieho programu vnútroobvodového emulátora S–ICE v. 1.0 vytvoreného pre KIVT FEI STU Bratislava. Ďalším prínosom pre tím je absolvovanie predmetov Princípy softvérového inžinierstva a zapísaný predmet Architektúra softvérových systémov.
Tímový projekt | Dokumentácia k riadeniu projektu
2
Bc. Tomáš Chmel Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje 5 rokov. Ovláda programovanie v jazykoch Asemblér, C/C++, OpenGL, VHDL,PHP. Svoje skúsenosti získal programovaním softvérových systémov menšieho rozsahu v rámci bakalárskeho štúdia, ako aj v rámci svojho voľného času. Je tvorcom programu PCIV, určeného pre meranie koncentračných profilov nosičov náboja v polovodičových vzorkách, vypracovaného v rámci záverečného projektu bakalárskeho štúdia. Bc. Marcel Mésároš Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Elektronika. Programovaniu sa venuje už vyše 11 rokov. Ovláda programovanie v jazykoch Asemblér (x86, TMS370, x51, Z80), C/C++, BASIC, Pascal, SQL, HTML a ďalších. Približne rovnaký čas má skúsenosti s DTP a prípravou dokumentov pre tlač, ovláda programy QuarkXPress, Adobe Photoshop, Adobe PageMaker, Adobe Illustrator, Adobe Acrobat.
Motivácia
Prvý kontakt s počítačovým inžinierstvom získavajú študenti FIIT STU v Bratislave na hodinách predmetu Architektúra počítačov. Náplňou tohto predmetu je predovšetkým oboznámenie sa so základnými stavebnými prvkami počítačových systémov a princípmi ich fungovania. Doterajší spôsob výučby spočíval v štúdiu skrípt, účasti na prednáškach a cvičeniach dennej formy štúdia. Nakoľko problematika architektúry počítačov napreduje závratným tempom, vydávané skriptá nestíhajú zachytáva_ nové poznatky v tejto oblasti. Rýchlej a jednoduchej aktualizácii študijného materiálu bránia s ňou spojené vysoké finančné a časové náklady.
V súčasnosti existujú technológie, ktoré umožňujú jednoduchšiu prezentáciu, aktualizáciu a v neposlednom rade aj dostupnosť učebných materiálov. Riešením tohto problému sa zaoberá téma Multimediálna podpora predmetu Architektúra počítačov v rámci Tímového projektu, na ktorej sa náš tím rozhodol pracovať. Za dôvody, ktoré nás viedli k tomuto rozhodnutiu, považujeme najmä chuť využiť vedomosti členov tímu nadobudnuté počas bakalárskeho štúdia v odbore Informatika v zameraní Počítačové systémy a siete a taktiež náš odborný záujem v tejto oblasti. Náš tím má ambíciu poskytnúť riešenie, ktoré bude spĺňať všetky požiadavky naň kladené a v maximálnej možnej miere poskytnúť používateľovi prijemné pracovné prostredie s množstvomdoplnkových funkcií.
Snahou nášho tímu je ušiť produkt na mieru zákazníka podľa jeho predstáv. Jednou z našich základných priorít je vytvoriť plne funkčný systém s použitím metód a techník softvérového inžinierstva, tak aby bolo možné výsledný produkt nasadiť v reálnom prostredí.
Tímový projekt | Dokumentácia k riadeniu projektu
3
Ponuka
Náš produkt bude spĺňať kompletnú špecifikáciu zadania: – navrhnúť a realizovať produkt, ktorý multimediálnymi prostriedkami
umožní vytvoriť rámce zodpovedajúce požadovaným kapitolám predmetuArchitektúra počítačov,
– navrhnúť a realizovať náplň jednotlivých častí, – produkt implementovať ako hypermediálnu prezentáciu
s kapacitnými nárokmi na jedno CD-Rom médium a voľne dostupný prehliadač.
Na základe požiadaviek zákazníka bude vytvorený systém, ktorý bude tvorený dvomi modulmi. Prvý modul bude predstavovať vývojové prostredie pre tvorbu multimediálnych prezentácii. Tvorcovi prezentácie bude umožňovať:
– vytvorenie štruktúry multimediálnej prezentácie, – vkladanie článkov, obrázkov a animácii do štruktúry prezentácie, – jednoduché aktualizovanie údajov prezentácie, – jednoduché modifikovanie celej štruktúry prezentácie, – využitie softvérových výstupov z iných aplikácii, – použiť systém pre ľubovoľné prezentácie, – vytváranie testov pre kontrolu zvládnutia problematiky, – podporu tvorby pomocou elektronickej dokumentácie, – pracovať v interaktívnom, jednoduchom a graficky prepracovanom
rozhraní. Druhým modulom je prezentácia vytvorená vo vývojovom prostredí a bude prístupná študentom predmetu Architektúra počítačov. Výsledná prezentácia bude študentom umožňovať:
– prezeranie multimediálnej prezentácie vo voľne dostupných prehliadačoch,
– prehľadné a intuitívne ovládanie, – otestovať zvládnutie problematiky.
Tímový projekt | Dokumentácia k riadeniu projektu
4
Predpokladané zdroje
Implementačné prostredie Výsledný systém sa bude skladať z dvoch modulov. Vývojové prostredie – prvý modul – bude vytvorené vo vývojovom prostredí Borland C++ Builder 5. Vývojové prostredie bude možné používať na počítači s operačným systémom Windows verzie 95 a novšom. Vytvorená prezentácia – druhý modul – bude HTML stránka. Do prezentácie sa budú dať pomocou vývojového prostredia vkladať nasledovné typy súborov:
– textové dokumenty – obrázky – animácie Výsledným produktom je prezentácia, ktorú je možné prezerať
pomocou voľne dostupných prehliadačov podporujúcich HTML verzie 4 a vyššie.
Hardvérové požiadavky Hardvérové požiadavky budú vyplývať z požiadaviek jednotlivých modulov. Pre vývojové prostredie to bude systém s procesorom Pentium, min. 32 MB pamäte a obrazovku s rozlíšením 800 × 600 / 16 bit. Hardvérové požiadavky na výslednú prezentáciu budú vychádzať z požiadaviek prehliadača webových stránok, na ktorom bude prezentácia spustená. Časové a priestorové požiadavky Na vypracovanie projektu v danom rozsahu bude potrebných 8 hodín týždenne na člena tímu počas dvoch semestrov. Z toho vyplývajú aj požiadavky na priestory pre prácu tímu na projekte. V miestnosti musia byť voľné počítače prístupné pre členov tímu s pripojením na Internet.
Príloha
Zoradenie ponúkaných tém podľa priority Ponúkané témy preferujeme v nasledovnom poradí:
1. Multimediálna podpora predmetu Architektúra počítačov (APS) 2. Podpora dištančného vzdelávania v predmete Systémové
programovanie a asembléry (SPA) Rozvrh členov tímu
Tímový projekt | Dokumentácia k riadeniu projektu
5
Rozvrh členov tímu uvádzame samostatne na nasledujúcej strane.
Tímový projekt | Dokumentácia k riadeniu projektu
6
Tímový projekt | Dokumentácia k riadeniu projektu
7
1.2 Priesvitky
Slovenská technická univerzita v Bratislave Fakulta elektrotechniky a informatiky Katedra informatiky a výpočtovej techniky
Tímový projekt
Multimediálna podpora predmetu Architektúra počítačov Prezentácia ponuky Tím č. 9 Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel Mésároš letný semester šk. r. 2003/2004 6. 10. 2003
Ponuka
– splnenie kompletnej špecifikácie zadania – systém tvorený dvomi modulmi
Prvý modul – prostredie pre tvorbu multimediálnych prezentácii
– vytvorenie štruktúry, vkladanie článkov, obrázkov a animácii – interaktívne rozhranie – jednoduchá aktualizácia údajov – jednoduchá modifikácia celej štruktúry prezentácie – využitie softvérových výstupov z iných aplikácii – univerzálnosť systému pre ľubovoľné prezentácie – možnosť vytvárania testov pre kontrolu zvládnutia problematiky – podpora tvorby pomocou elektronickej dokumentácie
Druhý modul – prezentácia vytvorená vo vývojovom prostredí
– prezeranie multimediálnej prezentácie vo voľne dostupných prehliadačoch – prehľadné a intuitívne ovládanie – možnosť otestovať zvládnutie problematiky
Tímový projekt | Dokumentácia k riadeniu projektu
1
2. Plán projektu V tejto kapitole uvedieme dlhodobý plán projektu na zimný semester školského roku 2003/2004. V tab. č. 1 sú zobrazené jednotlivé body, ktoré sú rozplánované na jednotlivé týždne semestra. Tab. č. 1 – Dlhodobý plán na zimný semester 2003/2004
1. týždeň úvod do predmetu 2. týždeň návrh ponuky a návrh jej prezentácie 3. týždeň prezentácia ponuky 4. týždeň prvý pohovor s tímovým vedúcim, počiatočná analýza požiadaviek 5. týždeň hlbšia analýza požiadaviek, príprava otázok na interview 6. týždeň zostavenie katalógu požiadaviek 7. týždeň hrubý návrh dátových štruktúr 8. týždeň vytvorenie dokumentácie pre prvý kontrolný termín 9. týždeň podrobný návrh - funkčný diagram, dátový diagram 10. týždeň Rozčlenenie úloh implementácie, počiatok implementácie prototypu 11. týždeň implementácia prototypu 12. týždeň prezentácia riešenia a prototypu
V tab. č. 2 sú zobrazené podrobné úlohy, ktoré sú rozplánované na posledné
štyri týždne semestra škol. roku 2003/2004. Tab. č. 2 – Krátkodobý plán na posledné štyri týždne zimného semestra
9. týždeň - Definovanie základných funkcií prototypu, ktoré sa budú implementovať - Návrh dátového modelu prototypu - Návrh funkčného modelu prototypu
10. týždeň - Hlavný návrhár systému rozdelí úlohy na podúlohy a určí zodpovedných na implementovanie (traja členovia tímu) - Hlavný návrhár prezentácie rozdelí úlohy na podúlohy z pohľadu dizajnu prezentácie a určí zodpovedných na implementáciu (dva členovia tímu) - Počiatok implementácie prototypu
11. týždeň - Implementácia prototypu - Každý z členov implementuje svoju časť prototypu - Spojenie systému - Verifikácia a validácia
12. týždeň - Naplnenie systému netriviálnou vzorkou údajov - Príprava prezentácie riešenia a prototypu - Prezentácia prototypu
Tímový projekt | Dokumentácia k riadeniu projektu
2
V tab. č. 3 sú zobrazené úlohy, ktoré sú rozplánované na celý letný semester
škol. roku 2003/2004. Prvé štyri týždne sú rozplánované do konkrétnych úloh, úlohy na posledné týždne sú iba hrubo načrtnuté a v priebehu riešenia projektu môžu byť prispôsobené časovým možnostiam. Tab. č. 3 - Dlhodobý plán na letný semester 2003/2004
1. týždeň Návrh základných modulov nezávislých od prostredia Návrh – fyzický model údajov Návrh – fyzický model funkcií
2. týždeň Návrh – fyzický model údajov - dokončenie Návrh – fyzický model funkcií – dokončenie Vytvorenie dokumentácie pre fyzické modely Návrh abstraktného dátového typu - strom pre štruktúru nadpisov Návrh abstraktného dátového typu - úložisko komponent Návrh abstraktného dátového typu – index Návrh zreťazenia obrazoviek
3. týždeň Implementácia abstraktného dátového typu – strom pre štruktúru nadpisov Implementácia abstraktného dátového typu - úložisko komponent Implementácia abstraktného dátového typu – index Implementácia zreťazenia obrazoviek
4. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility
5. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility Vytvorenie novej šablóny – viacerých
6. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility Tvorba obrázkov Tvorba animácií
7. týždeň Naplnenie systému údajmi – vytvorenie prezentácie predmetu AP 8. týždeň Testovanie 1. modulu
10. týždeň Validácia systému Tvorba elektronickej príručky Vytvorenie dokumentácie k implementácii a testovaniu
11. týždeň Dokončenie dokumentácie k implementácii a testovaniu Tvorba používateľskej príručky
12. týždeň Finalizácia
Tímový projekt | Dokumentácia k riadeniu projektu
1
3. Úlohy členov tímu V tejto kapitole rozpíšeme jednotlivé úlohy členov tímu z dlhodobého a krátkodobého hľadiska. Dlhodobé úlohy sú také, ktoré člen tímu vykonáva neustále v priebehu semestra alebo také, ktoré majú charakter manažmentu činností a teda člen tímu má vedúcu úlohu v tejto oblasti. Krátkodobé úlohy majú skôr charakter čiastkových úloh, ktoré sú zadávané z týždňa na týždeň. Jednou z podkapitol tejto kapitoly je aj rozpis podielu členov tímu na autorstve dokumentácie projektu a dokumentácie k riadeniu a tiež podiel činnosti členov tímu na tvorbe ponuky k projektu. 3.1 Dlhodobé úlohy členov tímu Viliam Bedeč – Hlavný návrhár programového systému pre tvorbu dokumentácie Peter Hlocký – Vedúci tímu a správa web prezentácie Marek Hrablay – Hlavný grafik Tomáš Chmel – Hlavný analytik Marcel Mésároš – Hlavný návrhár prezentácie predmetu 3.2 Krátkodobé úlohy členov tímu Krátkodobé úlohy členov tímu sú pridelované vždy na stretnutí tímu a podľa potrieb súčasného stavu projektu. V tab. č. 3 uvádzame podrobný rozpis krátkodobých úloh členov tímu na jednotlivé týždne semestra počnúc druhým. Tab. č. 3 – Krátkodobé úlohy na zimný semester 2003/2004
2. týždeň
všetci
- stretnutie za účelom prejednania návrhov na obsah ponuky - spísanie návrhov a nápadov do dokumentu - príprava priesvitiek
úloha splnená
3. týždeň
všetci - sociálne aktivity za účelom zblíženia sa členov tímu úloha splnená
4. týždeň
- skúmať možnosti implementácie konštruktora prezentácie
- zistené možnosti implementačného prostredia Viliam Bedeč
- analýza existujúcich riešení - v úlohe pokračuje ďalší týždeň Peter Hlocký - návrh dizajnu web prezentácie - návrh vytvorený, schválený tímom
- návrh loga tímu - logo bolo navrhnuté, nebolo schválené tímom Marek Hrablay
- analýza existujúcich riešení - v úlohe pokračuje ďalší týždeň - skúmať možnosti implementácie prekladača do HTML
- analýza vykonaná, vysledky sú registrované v rácmi požiadaviek
Tomáš Chmel
- návrh plagátu tímu - návrh plagátu vykonaný, schválený tímom - návrh loga tímu - logo bolo schválené tímom Marcel
Mésároš - návrh grafickej úpravy prezentácie - návrhy prednesené na tímovom stretnutí
Tímový projekt | Dokumentácia k riadeniu projektu
2
5. týždeň
- analýza existujúcich riešení prezentácií - získal materiály, pokračuje budúci týždeň Viliam Bedeč
- vytvorenie základnej úrovne katalógu požiadaviek
- úloha splnená, katalóg je kostrou analýzy projektu
Peter Hlocký - vytvoriť web prezentáciu - web prezentácia bola vytvorená a v čas spustená
- analýza existujúcich riešení - analýza v priebehu, do 6. týždňa spracuje text do dokumentácie
Marek Hrablay - analyzovať produkt ACDL - produkt analyzovaný, objaví sa v rámci
dokumentácie
Tomáš Chmel - vytvoriť spolu s Viliamom hlbšie úrovne kat. požiadaviek
- v úlohe pokračuje, do 6.týždňa bude mať komplet. výsledok
Marcel Mésároš
- analýza CICSO vzdelávacieho produktu
- produkt analyzovaný, bude súčasťou dokumentácie
6. týždeň
- analýza existujúcich aplikácii na tvorbu prezentácii
OK - vytvorený text, ktorý bude uvedený v opise problematiky
- zhrnutie výsledkov analýzy na návrh novej prezentácie - detto
Viliam Bedeč
- rozposlanie osnovy analýzy a zápisnice zo stretnutia - detto
Peter Hlocký - úvod do analýzy a popis predmetu Architektúra počítačov
OK - vytvorený úvodný text, ktorý bude uvedený v opise problematiky
- analýza výučby pomocou e-learningu OK - vytvorený text, ktorý bude uvedený v opise problematiky
Marek Hrablay - použitie multimediálnych technológii
v e-learningu - detto
- dopracovať katalóg požiadaviek
- bola vytvorená základná vrstva katalógu požiadaviek a jeho hlavných podúrovní. Na stretnutí bol doplnený podrobnejšími požiadavkami tak, aby bol pripravený na budúci týždeň
Tomáš Chmel
- dokončenie plagátu tímu - plagát bol vytvorený - analýza a návrh formátovania prezentácie - analýza bola kompletne dokončená
Marcel Mésároš
- zhrnutie výsledkov na návrh novej prezentácie - návrh je vo fáze dokončovania
Tímový projekt | Dokumentácia k riadeniu projektu
3
7. týždeň
- napísať kapitolu 2.2 - scenáre použitia OK - napísať kapitolu 3.1 - hrubý návrh - architektúra systému OK
Viliam Bedeč
- napísať kapitolu 3.3 - 1. Modul OK - doplnenie katalógu požiadaviek OK - podrobný plán do konca semestra OK
fomátovanie navrhnuté, treba ešte dopracovať pre potreby prototypu
Tímový projekt | Dokumentácia k riadeniu projektu
4
9. týždeň - vypracovať podrobný dátový diagram spolu s Marekom OK Viliam Bedeč - rozčlenenie úloh pre implementáciu OK - vypracovať podrobný DFD diagram spolu s Tomášom OK
Peter Hlocký - vypracovať posudok ku stavu projektu tímu č.12 OK - vypracovať podrobný dátový diagram spolu s Vilom OK
Marek Hrablay - získať materiály potrebné pre implementáciu prototypu OK
Tomáš Chmel - vypracovať podrobný DFD diagram spolu s Petrom OK - vypracovať kapitolu Štábna kultúra pre riadenie projetu OK Marcel
Mésároš - vypracovať finálne formátovanie prezentácie pre prototyp riešené
10. týždeň
Viliam Bedeč - implementovať 1. časť prototypu OK
Peter Hlocký - vytvoriť E-R diagram - bol vytvorený diagram tried, kvôli lepšej názornosti
- vypracovať DFD diagram - bol vypracovaný po 2. úroveň Marek Hrablay - vytvoriť FLASH animáciu
- určená téma pre animáciu, implementovaná bude v nasledujúcom týždni
Tomáš Chmel - implementovať konverznú utilitu OK - návrh formátovania preznetácie - vytvorená šablóna pre prototyp Marcel
Mésároš - úprava dizajnu výslednej prezentácia OK
11. týždeň
- dokončenie prototypu OK Viliam Bedeč - vytvorenie kapitoly 4.2 - Vyhodnotenie
prototypovania (systém) OK
- vytvoriť kapitolu 3.6 - Model údajov OK Peter Hlocký - vytvoriť kapitolu 4.1 - Ciele
prototypovania OK - vypracovať kapitolu 3.5 - Model funkcií OK
Marek Hrablay - vytvoriť dokumentáciu k riadeniu OK
Tomáš Chmel - dokončenie prototypu - konverzná utilita OK
- vytvoriť kapitolu 3.7 - Návrh šablóny OK - vytvoriť kapitolu 4.3 - Vyhodnotenie prototypovania (prezentácia) OK Marcel
Mésároš - dokončiť implementáciu šablóny pre prototyp OK
Tímový projekt | Dokumentácia k riadeniu projektu
5
3.3 Krátkodobé úlohy členov tímu – Letný semester Tab. č. 4 – Krátkodobé úlohy na letný semester 2003/2004
2. týždeň
Viliam Bedeč - návrh abstraktného dátového typu – zreťazená volná pamäť OK
Peter Hlocký - návrh abstraktného dátového typu - index OK
Marek Hrablay - návrh abstraktného dátového typu - strom OK
Tomáš Chmel - zjemnenie DFD konverznej utility OK - návrh a vytvorenie ukážky ku navigovaniu v prezentácii pomocou JavaScriptu
Pokračuje v riešení Marcel
Mésároš - návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent
OK
3. týždeň Viliam Bedeč - zreťazenie komponent a obrazoviek Pokračuje v riešení
Peter Hlocký - index – doriešenie triedenia s diakritikou OK
Marek Hrablay - návrh vizuálnej stránky animácií OK Tomáš Chmel - dokumentácia návrhu OK
- návrh a vytvorenie ukážky ku navigovaniu v prezentácii pomocou JavaScriptu
Pokračuje v riešení Marcel Mésároš
- dokončenie 2. kapitoly skrípt Pokračuje v riešení 4. týždeň
Viliam Bedeč - dokončiť zreťazenie komponent a obrazoviek OK
Peter Hlocký - spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do konca OK
Marek Hrablay - dokončiť štruktúru nadpisov a zdokumentovať OK
Tomáš Chmel - vytvoriť html prehliadač OK - spolu s Petrom spracovať skriptá od kapitoly 4.4 až do konca OK Marcel
Mésároš - navigovanie v prezentácii pomocou JavaScriptu OK
5. týždeň
Viliam Bedeč - sfunkčnenie prostredia aplikácie – možnosť vytvárať štruktúru prezentácie OK
Peter Hlocký - prebranie skrípt v elektronickej forme a práca na ich spracovaní spolu s Marcelom
OK
Marek Hrablay - štúdium práce v prostredí C++ Builder, príprava na prezentáciu OK
Tomáš Chmel - úprava utility na tvorbu používateľského prostredia výslednej prezentácie
OK
Marcel Mésároš
- pomoc pri formátovaní skrípt spolu s Peťom OK
Tímový projekt | Dokumentácia k riadeniu projektu
6
6. týždeň - implementácia editora na zmenu a úpravu komponentov Pokračuje v riešení
Viliam Bedeč – implementácia funkcií načítania a uloženia prezentácie OK
Peter Hlocký - dokončiť kap. 4.2, urobiť kap 4.1 do podoby výslednej prezentácie OK - vypracovanie prezentácie o spôsoboch komunikácie OK
Marek Hrablay – integrácia stromovej štruktúry do projektu Pokračuje v riešení
Tomáš Chmel - implementovať konverziu obrazoviek a štruktúry komponent OK
Viliam Bedeč - implementácia editora na zmenu a úpravu komponentov Pokračuje v riešení
Peter Hlocký - testovanie editoru naplnením systému kapitolou 4.1 a 4.2. OK – Vrátené na dopracovanie
Marek Hrablay - integrácia stromovej štruktúry do projektu Pokračuje v riešení
Tomáš Chmel - pokračovanie v implementácii konverznej utility Pokračuje v riešení - pridať funkcionalitu do používateľského rozhrania výslednej prezentácie rozbaľovaním hierarchie nedpisov
Pokračuje v riešení Marcel Mésároš
– príprava prezentácie o dosiahnutom progrese OK
8. týždeň
Viliam Bedeč - implementácia editora na zmenu a úpravu komponentov OK - testovanie nasledujúcej verzie editoru OK – VSAM v.0.9 sa môže odovzdať Peter Hlocký príprava dotazníka na testovanie OK - integrácia stromovej štruktúry do projektu Úloha pozastavená
Marek Hrablay príprava používateľskej príručky OK
Tomáš Chmel - pokračovanie v implementácii konverznej utility – atribúty komponent OK
- sfunkčnenie prostredia aplikácie – možnosť vytvárať štruktúru prezentácie OK
Viliam Bedeč Oprava chýb nájdených alfa testom vo verzii 0.9 Pokračuje v riešení
- Príprava Beta testovania OK Peter Hlocký
Príprava testovacích vzoriek Pokračuje v riešení - Finalizácia používateľskej príručky OK
Marek Hrablay - Testovanie VSAM v0.9 OK
Tomáš Chmel - Prirobenie konverzie rozbaľovatelného obsahu do konverznej utility OK
Marcel Mésároš - Vytvorenie druhej šablóny OK
10. týždeň
Viliam Bedeč - oprava chýb a napísanie návrhu a implementácie na editor OK
Peter Hlocký - naplnenie programu kapitolami 4.1 a 4.2 OK
Marek Hrablay - testovanie a naplnenie programu kapitolami 4.3 OK
Tomáš Chmel - oprava chýb a úprava dokumentácie návrhu a implementácie konvertoru OK
Marcel Mésároš
- dokumentácia návrhu a implementácie výslednej prezentácie OK
11. týždeň - oprava drobných chýb VSAM OK
Viliam Bedeč - opraviť spájanie projektov - prerobiť kapitoly 4.1 a 4.2 OK
Peter Hlocký - Testovanie VSAM OK
Marek Hrablay - napísanie dokumentácie k riadeniu projektu na letný semester OK
Tomáš Chmel - oprava chýb konverznej utility OK - doplnenie kaskádového štýlu o štvrtú úroveň OK Marcel
Mésároš - formátovanie dokumentácie OK
12. týždeň - oprava posledných chybičiek editora OK
Viliam Bedeč - dopísať záver ku dokumentácii
Peter Hlocký - dokončenie prezentácie podľa kapitoly 4. pomocou editora OK - vyrobenie flash animácie do ku kapitole 4. OK
Marek Hrablay - prepísať používateľskú príručku pre najnovšiu verziu produktu
Tomáš Chmel - vyhotoveni CD média s produktom OK Marcel
Mésároš - doplniť dokumentáciu o chýbajúce časti OK
Tímový projekt | Dokumentácia k riadeniu projektu
8
3.4 Podiel na autorstve dokumentácie a tvorbe ponuky Dokumentácia k projektu Kapitola 1 Opis problematiky
1.1 Výučba predemtov - Peter Hlocký 1.2 Elektronické štúdium alebo „E-Learnig“ - Marek Hrablay 1.3 Prostredia pre tvorbu prezentácií na internete - Viliam Bedeč 1.4 Analýza podobných prezentácií - Marcel Mésároš
Kapitola 2 Analýza problematiky 2.1 Katalóg požiadaviek - Tomáš Chmel 2.2 Scenáre použitia - Viliam Bedeč 2.3 Analýza formátovania prezentácie - Marcel Mésároš 2.4 Interview s J. Hudecom – Marek Hrablay Kapitola 3 Hrubý návrh architektúry 3.1 Základné vlastnosti editora prezentácií – Viliam Bedeč 3.2 Roly používateľov – Peter Hlocký 3.3 Návrh aplikácie pre tvorbu prezentácie – Viliam Bedeč a Tomáš Chmel 3.4 Návrh prezentácie – Tomáš Chmel 3.5 Model funkcií – Marek Hrablay 3.6 Model údajov - Peter Hlocký
3.7 Návrh šablóny - Marcel Mésároš Kapitola 4 Prototyp 4.1 Ciele prototypovania - Peter Hlocký
Kapitola 5 Podrobný návrh 5.1 Editor prezentácie - Viliam Bedeč 5.2 Konverzná utilita - Tomáš Chmel 5.3 Návrh konverznej utility do formátu HTML - Tomáš Chmel 5.4 Formátovanie prezentácie - Marcel Mésároš
Kapitola 6 - Implementácia 6.2 Editor prezentácie - Viliam Bedeč
6.1 Rozhranie konverznej utility - Tomáš Chmel 6.2 Konvertovanie projektu prezentácie do formátu HTML - Tomáš Chmel 6.3 Formátovanie prezentácie - Marcel Mésároš
Kapitola 7 - Testovanie - Peter Hlocký Dokumentácia k riadeniu projektu Úvod – Marek Hrablay 1. Ponuka – Marcel Mésároš 2. Plán projektu – Peter Hlocký 3. Úlohy členov tímu – Peter Hlocký 4. Zápisnice zo stretnutí tímu – Marek Hrablay 5. Posudky na projekty – Marek Hrablay 6. Preberacie protokoly – Marek Hrablay 7. Štábna kultúra – Marcel Mésároš Používateľská príručka – Marek Hrablay
Tímový projekt | Dokumentácia k riadeniu projektu
9
Podiel činnosti na tvorbe ponuky Viliam Bedeč – 25% Peter Hlocký – 20% Marek Hrablay – 15% Tomáš Chmel – 15% Marcel Méšároš – 25% Podiel činnosti na tvorbe špecifikácie Viliam Bedeč – 15% Peter Hlocký – 25% Marek Hrablay – 25% Tomáš Chmel – 15% Marcel Méšároš – 20% Podiel činnosti na tvorbe prototypu Viliam Bedeč – 30% Peter Hlocký – 10% Marek Hrablay – 10% Tomáš Chmel – 30% Marcel Méšároš – 20% Podiel činnosti na tvorbe výsledném dokumentácie Viliam Bedeč – 10% Peter Hlocký – 20% Marek Hrablay – 30% Tomáš Chmel – 15% Marcel Méšároš – 25% Podiel činnosti na tvorbe výsledného produktu Viliam Bedeč – 30% Peter Hlocký – 20% Marek Hrablay – 10% Tomáš Chmel – 25% Marcel Méšároš – 15%
Tímový projekt | Dokumentácia k riadeniu projektu
1
4. Zápisy zo stretnutí Náš tím sa stretáva raz do týždňa. Na každom stretnutí preberáme aktuálne
problémy projektu, referujeme kolegom o dosiahnutých výsledkoch a rozdeľujeme nové úlohy. Po každom stretnutí je vypracovaná zápisnica zo stretnutia, ktorá má napomáhať celému tímu pri práci na projekte a slúži zároveň aj ako pomôcka pri kontrole stavu projektu. V tejto kapitole uvádzame zápisy zo všetkých doterajších stretnutí tímového projektu. 4.1 Zápisnica zo stretnutia ÚVTP č. 1 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 14.10.2003 Čas: 10:30 – 12:15 Prítomní:
Program stretnutia: • Rozprava o procese tvorby multimediálnych prezentácií • Rozprava o možných spôsoboch uloženia dát vývojového prostredia. • Zadanie úloh pre jednotlivých členov tímu. Priebeh Stretnutia: • Po krátkej diskusii sme odhlasovali oficiálny názov nášho tímu: Kinedryl. • Spolu s vedúcim tímového projektu Ing. Jánom Hudecom sme diskutovali
o základných vlastnostiach nami vytváraného systému. Boli definované základné funkcionálne požiadavky kladené na systém, ako aj základy rozhrania s používateľom.
• Po predbežnej analýze sme rozdelili vytváraný systém na dve časti. Konštruktor prezentácie a preklad prezentácie do formátu HTML. Nasledovala diskusia o základných vlastnostiach oboch modulov ako aj o ich prepojení.
• Boli navrhnuté základy štruktúry prezentácie, ako aj rozdelenie prezentácie na komponenty. Diskusia o vlastnostiach komponentov a o ich vkladaní do prezentácie. Definovali sme základné komponenty prezentácie.
• Rozprava o možných spôsoboch uloženia dát vývojového prostredia. Viliam Bedeč načrtol možnosti implementácie navrhovanej štruktúry prezentácie.
Pripomienky: • bude potrebný indexu pojmov (OK) • obrázky by mali byť vložené priamo do textu a nie mimo neho – potenciálny
zdroj problémov pri implementácii (?) • tabuľky – editor tabuliek príliš zložitý na vytvorenie, avšak ani vloženie
tabuliek ako obrázkov nie je ideálnym riešením (?) • práca s odkazmi, možnosť asistencie programu pri vytváraní indexu /
odkazov (?) • potrebná hĺbka hierarchie štruktúry (kapitoly, podkapitoly, články, …) (?) • možnosť uložiť dáta v adresárovej štruktúre (?) Rozdelenie úloh do budúceho týždňa: • pre všetkých - pokračovať v analýze systému • Marek Hrablay - návrh loga tímu
- analýza existujúcich riešení • Peter Hlocký - návrh HTML stránky tímu • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie
- analýza existujúcich riešení • Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML
- analýza spôsobu uloženia dát systému - návrh plagátu tímu
• Marcel Mésároš - návrh loga tímu - návrh grafickej úpravy dokumentácie
Rozdelenie dlhodobých úloh: • Marek Hrablay - tvorba dokumentácie
- tvorba flash animácií - analýza a programovanie
• Peter Hlocký - tvorba HTML stránky tímu - vedúci tímu • Viliam Bedeč - dohľad nad tvorbou konštruktora prezentácie
- analýza a programovanie • Tomáš Chmel - dohľad nad tvorbou analýza prekladača do HTML
- analýza a programovanie • Marcel Mésároš - návrh dizajnu aplikácie
- dizajn a tvorba dokumentácie Zápisnicu vypracoval: Marcel Mésároš
Tímový projekt | Dokumentácia k riadeniu projektu
3
4.2 Zápisnica zo stretnutia ÚVTP č. 2 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 21.10.2003 Čas: 10:15 – 12:30 Prítomní:
Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Pokračovanie analýzy systému • Návrh katalógu požiadaviek • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - návrh loga tímu (OK)
- analýza existujúcich riešení (riešené) • Peter Hlocký - návrh HTML stránky tímu (OK) • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie
(riešené) - analýza existujúcich riešení (OK)
• Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML (riešené)
- analýza spôsobu uloženia dát systému (OK) - návrh plagátu tímu (OK)
• Marcel Mésároš - návrh loga tímu (OK) - návrh grafickej úpravy dokumentácie (OK)
Priebeh Stretnutia: • Zo všetkých podaných návrhov na logo tímu a plagát sme vybrali logo od
marcela Mésároša a plagát od Tomáša Chmela. • Viliam Bedeč prezentoval dve možné koncepcie zobrazenia učebného
materiálu – orientovanej stránkovo a so súvislým tokom textu a vloženými obrázkami. Nasledovala diskusia, ktorá možnosť bude najvhodnejšia.
• Nasledovalo stretnutie s Ing. Jánom Hudecom. Spolu s ním sme hodnotili našu ponuku ako aj prezentáciu ponuky. Následne sme ho oboznámili s aktuálnym stavom projektu a konzultovali sme s ním problémy spojené so špecifikáciou, na ktoré sme narazili počas minulého týždňa.
• Ing. Ján Hudec nás informoval o existujúcich riešeniach dištančného štúdia. • Začali sme s analýzou základnej úrovne katalógu požiadaviek. Po diskusii
na túto tému sme začali s rozdeľovaním práce na katalógu požiadaviek. Závery a pripomienky: • obrázky a animácie nebudú vkladané priamo do textu, ale budú tvori ť
samostatné komponenty vkladané do prezentácie (OK) • 2 triedy odkazov - na časti textu súvisiace s problematikou, a vytvorenie
slovníka pojmov – indexu (OK) • obmedzenie hĺbky úrovne nadpisov v prezentácii na 4. (OK) • nie je potrebné vytváranie tabuliek, túto možnosť však ponechávame na
ďalšiu analýzu (OK) • dáta prezentácie nebudú uložené v stromovej štruktúre, ale v jednom súbore
(kôli rýchlosti systému) (OK) • podporované formáty súborov na import a export (?) • možnosť editovania prezentácie aj v inom programe ako bude naše
vývojové prostredie (?) • možnosť asistencie pri vytváraní indexu (?) Rozdelenie úloh do budúceho týždňa: • pre všetkých - pokračovať v analýze systému
- analyzovať možné úrovne katalógu požiadaviek • Marek Hrablay - návrh flash animácií pre výsladný produkt
- analyzovať produkt ACDL (www.acdl.cz) • Peter Hlocký - vylepšenie vzľadu HTML stránky tímu • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie
- analýza existujúcich riešení • Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML
- dokončenie plagátu tímu - vytvorenie a rozposlanie základnej úrovne katalógu požiadaviek
4.3 Zápisnica zo stretnutia ÚVTP č. 3 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 28.10.2003 Čas: 9:55 – 12:10 Prítomní:
Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Rozdelenie úloh na analýzu podľa osnovy • Prezentovanie základného návrhu aplikácie na tvorbu prezentácie • Diskusia o návrhu Stav plnenia úloh z minulého týždňa • Marek Hrablay - analýza produktu ACDL
- analýza existujúcich riešení ??? (riešené) • Peter Hlocký - vytvoriť web prezentáciu (OK) • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie
(riešené) - analýza existujúcich riešení aplikácii pre tvorbu prezentácii (OK) - vytvorenie a rozoslanie katalógu požiadaviek (OK)
• Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML (riešené)
- dokončenie plagátu tímu (OK) • Marcel Mésároš - návrh grafickej úpravy dokumentácie (OK) Priebeh Stretnutia: • Vilam Bedeč prezentoval základnú osnovu analýzy. Popísal jednotlivé jej
body analýzy. • Rozdelili sme si jednotlivé body analýzy s tým, že nasledujúci týždeň každý
donesie svoju časť vypracovanú a prečítame si ich navzájom, aby sme našli chyby.
• Viliam Bedeč prezentoval základnú koncepciu práce aplikácie, tvorbu prezentácie a celkovú filozofiu práce s aplikáciou. Po tomto prednese nastala hodinová diskusia o možnostiach, ktoré vyplývajú z daného riešenia.
Tímový projekt | Dokumentácia k riadeniu projektu
6
Závery a pripomienky: • Rozdelili sme si časti analýzy a nasledujúci týždeň donesieme vypracované
časti • Upravili sme základný návrh aplikácie • Viliam Bedeč zakomponuje do návrhu pripomienky, ktoré boli opodstatnené • Pomocou diskusie sa všetci členovia týmu dozvedeli ako bude realizovaná
aplikácia a tvorivou diskusiou pridali ďalšie vylepšenia do návrhu Rozdelenie úloh do budúceho týždňa: • pre všetkých - spísať základnú analýzu problému • Marek Hrablay - analýza výučby pomocou e-learningu
- použitie multimediálnych technológii v e-learningu • Peter Hlocký - úvod do analýzy a popis predmetu Architektúra počítačov • Viliam Bedeč - analýza existujúcich aplikácii na tvorbu prezentácii
- zhrnutie výsledkov analýzy na návrh novej prezentácie - rozposlanie osnovy analýzy a zápisnice zo stretnutia
• Tomáš Chmel - dopracovať katalóg požiadaviek - dokončenie plagátu tímu
• Marcel Mésároš – analýza existujúcich prezentácii na internete - zhrnutie výsledkov na návrh novej prezentácie
Zápisnicu vypracoval: Viliam Bedeč 4.4 Zápisnica zo stretnutia ÚVTP č. 4 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 4.11.2003 Čas: 10:10 – 11:40 Prítomní:
Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Vyhodnotenie stavu opisu problematiky - uzavretie • Posledné úpravy katalógu požiadaviek • Dohoda na scenároch použitia • Rozprava o obsahu hrubého návrhu • Rozprava o obsah dokumentácie k riadeniu • Zadanie úloh pre jednotlivých členov tímu.
Stav plnenia úloh z minulého týždňa • Marek Hrablay - analýza existujúcich foriem e-learningu (OK – vytvorený text, ktorý bude uvedený v opise problematiky) • Peter Hlocký - úvod do problematiky (OK – vytvorený úvodný text, ktorý bude uvedený v opise problematiky ) • Viliam Bedeč - analýza existujúcich produktov elektronického vzdelávania (OK - vytvorený text, ktorý bude uvedený v opise problematiky) • Tomáš Chmel - Vytvorenie katalógu požiadaviek (Bola vytvorená základná vrstva katalógu požiadaviek a jeho hlavných podúrovní. Na stretnutí bol doplnený podrobnejšími požiadavkami tak, aby bol pripravený na budúci týždeň) • Marcel Mésároš - Analýza a hrubý návrh možností formátovania (Analýza bola kompletne dokončená a návrh je vo fáze dokončovania.) Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Každý dostal za úlohu spísať doteraz vykonanú
prácu do formátovaného textu, aby bolo možné na budúci týždeň pristúpiť k tlačeniu dokumentu.
• Dohoda o obsahu dokumentácie : Časť 1 (opis problematiky) 1.1 – Výučba predmetov 1.2 - Formy e-learningu 1.3 – Existujúce formy elektronických prezentácií 1.4 - Analýza vzdelávacích produktov CISCO a ACDL Čast 2 (analýza) : 2.1 – katalóg požiadaviek 2.2 – Scenáre použitia 2.3 – Analýza formátovania 2.4 – Interview s Ing. J. Hudecom Časť 3 (Hrubý návrh) : 3.1 – Pohľad na systém (hrubá architektúra) 3.2 – Funkčný diagram (diagram používateľov) 3.3 – 1. Modul – strana pedagóga 3.4 – 2. Modul – konverzná utilita 3.5 – 3. Modul - prezentácia
• Dohoda termínov :
Do 10.11.2003 (pondelok), 18:00 – odovzdať všetky materiály na formátovanie Marcelovi Do 12.11.2003 (streda), 20:00 – odovzdať zformátované materiály Petrovi na vytlačenie Do 14.11.2003 (piatok), 13:00 – odovzdať dokumentáciu J. Hudecovi
• Interview s Ing. J. Hudecom o podrobných požiadavkách na systém.
Tímový projekt | Dokumentácia k riadeniu projektu
8
Závery a pripomienky: • Boli jednoznačne určené ciele do ďalšieho týždňa. • Celý nasledujúci týždeň sa bude niesť v duchu tvorby a formátovania
finálnej dokumentácie na odovzdanie • Boli dopracované požiadavky do katalógu požiadaviek na základe informácií
z interview. Tým bol vytvorený podrobný katalóg požiadaviek Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Úvod k dokumentácii riadenia
- Napísať kapitolu 2.3 – Analýza formátovania - Napísať kapitolu 3.5 – 3. Modul – Prezentácia - Vytvoriť preberacie dokumenty - Vytvoriť metódy a šablóny pre dokumentáciu riadenia Zápisnicu vypracoval: Peter Hlocký
Tímový projekt | Dokumentácia k riadeniu projektu
9
4.5 Zápisnica zo stretnutia ÚVTP č. 5 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 11.11.2003 Čas: 10:10 – 11:30 Prítomní:
Bc. Marek Hrablay Bc. Peter Hlocký
Bc. Viliam Bedeč Bc. Tomáš Chmel
Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Kompletizovanie dokumentácie k prvému kontrolnému bodu • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - Úvod k dokumentácii riadenia (OK)
- Napísať kapitolu 3.5 – 3. Modul – Prezentácia (OK) - Vytvoriť preberacie dokumenty (OK) - Vytvoriť metódy a šablóny pre dokumentáciu riadenia
(OK)
Tímový projekt | Dokumentácia k riadeniu projektu
10
Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Každý spísal časť prideleného textu a odoslal ju
Marcelovi, ktorý ju má za úlohu zformátovať do výslednej podoby a pripraviť na vytlačenie. Z dôvodu jeho práce na tejto úlohe bola jeho prítomnos ť na stretnutí ospravedlnená.
• Na žiadosť správy od Marcela, mu boli opätovne poslané niektoré časti
dokumentu, ktoré zrejme zablúdili na ceste Internetom spolu s upresňujúcimi inštrukciami.
• Dohoda termínov :
Do 12.11.2003 (streda), 20:00 – odovzdať zformátované materiály Petrovi na vytlačenie Do 14.11.2003 (piatok), 13:00 – odovzdať dokumentáciu J. Hudecovi a Tímu č.12 na posúdenie
Závery a pripomienky: • Boli jednoznačne určené ciele do ďalšieho týždňa. • Nasledujúci týždeň sa bude dokončovať finálne formátovanie dokumentácie
a príprava na podrobný návrh systému pre tvorbu multimediálnych prezentácií.
Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Vytvorenie Flash Animovanej ukážky
- Doplniť dokumentáciu riadenia projektu - Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp
• Peter Hlocký - Vytlačenie dokumentácie pre prvý kontrolný bod - Získanie študijných materiálov pre predmet Architektúra počítačov
• Viliam Bedeč - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Tomášom Chmelom
• Tomáš Chmel - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Viliamom Bedečom
• Marcel Mésároš - Dokončiť formátovanie dokumentácie pre prvý kontrolný bod - Detailný návrh formátovania výslednej prezentácie
Zápisnicu vypracoval: Tomáš Chmel
Tímový projekt | Dokumentácia k riadeniu projektu
11
4.6 Zápisnica zo stretnutia ÚVTP č. 6 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 18.11.2003 Čas: 10:15 – 12:20 Prítomní:
Bc. Marek Hrablay Bc. Peter Hlocký
Bc. Viliam Bedeč Bc. Tomáš Chmel Bc. Marcel Mésároš
Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Rozprava o dátovom a funkčnom modely vytváraného systému • Návrh funkcií prototypu • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - Doplniť dokumentáciu riadenia projektu
(OK) - Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp (pokračuje)
• Peter Hlocký - Vytlačenie dokumentácie pre prvý kontrolný bod (OK) - Získanie študijných materiálov pre predmet Architektúra počítačov (pokračuje)
• Viliam Bedeč - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Tomášom Chmelom (OK)
• Tomáš Chmel - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Viliamom Bedečom (OK)
• Marcel Mésároš - Dokončiť formátovanie dokumentácie pre 1. kontrolný bod (OK) - Detailný návrh formátovania výslednej prezentácie (OK)
Tímový projekt | Dokumentácia k riadeniu projektu
12
Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Prioritne sme sa zaoberali stavom odovzdanej
dokumentácie k prvému kontrolnému bodu. Padli niektoré pripomienky ku štruktúre dokumentácie, ktoré začleníme do kontrolného bodu č. 2.
• Diskusia o dokumentácii konkurenčného tímu. Preberali sme pritom hlavne klady a zápory, na ktoré sme narazili počas prehliadky dokumentu.
• Začala sa rozprava o aktuálnom stave rozpracovania modelov systému. Tomáš prezentoval aktuálny stav dátového ER diagramu, Viliam načrtol hrubú štruktúru DFD diagramu.
• Ďalej sme pokračovali v príprave prototypu. Príprava dát sa presunula na
ďalší týždeň vzhľadom na to, že sa nám nepodarilo zastihnúť J. Hudeca. Diskutovali sme ďalej o funkciách, ktoré by mal prototyp obsahovať, ako aj o vizuálnej stránke systému.
• Záver stretnutia sme venovali príprave na prezentáciu stavu projektu 24.11.2003. Dohodli sme sa na forme vystúpenia ako aj na rozdelení tém a vytvorení priesvitiek na prezentáciu.
Závery a pripomienky: • Funkčný model sa javí ako príliš komplexný, bude treba zjednoduši ť niektoré
časti. • Dátový model sa bude odvíjať z hrubého náčrtu tried prototypu, ktorý
navrhol Viliam Bedeč. • Prototyp by mal obsahovať základné zložky prezentácie, čiže aspoň náčrt
štruktúry kapitol, text, obrázok a animáciu. Presnú špecifikáciu prototypu budeme hľadať budúci týžden.
Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Vypracovať podrobný dátový model systému (s Vilom)
- Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp
• Peter Hlocký - Vypracovať podrobný funkčný model systému (s Tomášom) - Vypracovanie posudku k dokumentácii konkurenčného tímu
• Viliam Bedeč - Vypracovať podrobný dátový model systému (s Marekom) - Pokračovať v špecifikácii prototypu
• Tomáš Chmel - Vypracovať podrobný funkčný model systému (s Petrom) • Marcel Mésároš - Vypracovať kapitolu štábna kultúra v riadení projektu
- Návrh výslednej prezentácie vhodný pre prototyp Zápisnicu vypracoval: Marek Hrablay
Tímový projekt | Dokumentácia k riadeniu projektu
13
4.7 Zápisnica zo stretnutia ÚVTP č. 7 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 25.11.2003 Čas: 9:55 – 11:40 Prítomní:
Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Zhrnutie poznatkov pre tvorbu DFD a E-R diagramu • Diskusia s vedúcim tímového projektu o prototype a posudku • Identifikácia základných požiadaviek na prototyp • Reakcia na posudok a vyjadrenie jednotlivých členov tímu k posudku
konkurenčného tímu • Bol prezentovaný počiatočný návrh vzhľadu prezentácie • Zadelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay - Vypracovať podrobný dátový model systému (s Vilom)
(OK) - Získanie študijných materiálov z predmetu APS pre potreby prototypu (OK)
• Peter Hlocký - Vypracovať podrobný funkčný model systému (s Tomášom) (OK) - Vypracovanie posudku k dokumentácii konkurenčného tímu (OK)
• Viliam Bedeč - Vypracovať podrobný dátový model systému (s Marekom) (OK)
- Pokračovať v špecifikácii prototypu (OK) • Tomáš Chmel - Vypracovať podrobný funkčný model systému (s Petrom)
(OK) • Marcel Mésároš - Vypracovať kapitolu štábna kultúra v riadení projektu
(OK) - Návrh výslednej prezentácie vhodný pre prototyp (riešené)
Tímový projekt | Dokumentácia k riadeniu projektu
14
Priebeh Stretnutia: • Vilam Bedeč a Marek Hrablay prezentovali návrh entitno-relačného
diagramu. • Tomáš Chmeľ a Peter Hlocký prezentovali návrh DFD. • Zhrnuli sme poznatky z diagramov a vzhľadom na nutnosť programovať
prototyp, úloha vytvoriť finálne verzie pripadla na Mareka – DFD a Petra – entitno-relačný diagram.
• Po príchode ing. Jána Hudeca sme prebrali otázku odovzdania rekcie na posudok a hodnotenie našej dokumentácie. Opísali sme ako chceme zjednodušiť náš finálny produkt, pretože jeho obšírnosť by mohla spôsobiť neschopnosť odovzdať funkčný produkt na posledný termín. Okrem toho sme prezentovali aj funkcie, ktoré chceme implementovať do prototypu.
• Po odchode vedúceho tímu sme si rozdelili úlohy pre tvorbu prototypu. Vilo bude robiť editor na tvorbu prezentácii a Tomáš konverznú utilitu. Marcel vytvorí design výslednej prezentácie.
• Nakoniec sme zhrnuli pripomienky k posudku konkurenčného tímu a dohodli sa, že Peter vypracuje reakciu na posudok.
• Marcel ukázal základný vzhľad prezentácie a ostatní členovia sa k nemu vyjadrili
Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Definovali sme si úlohu prototypu • Návrh DFD a E-R diagramu sa dostal do finálnej fázy Rozdelenie úloh do budúceho týždňa: • pre všetkých -- spísať základnú analýzu problému • Marek Hrablay -- finalizácia DFD diagramu
-- tvorba Flash animácie • Peter Hlocký -- finalizácia E–R diagramu • Viliam Bedeč – tvorba prototypu prostredia pre tvorbu prezentácie • Tomáš Chmel – tvorba prototypu konverznej utility • Marcel Mésároš – analýza a návrh formátovania prezentácie
– úprava dizajnu výslednej prezentácie Zápisnicu vypracoval: Viliam Bedeč
Tímový projekt | Dokumentácia k riadeniu projektu
15
4.8 Zápisnica zo stretnutia ÚVTP č. 8 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 2.12.2003 Čas: 10:15 – 11:55 Prítomní:
Ing. J. Hudec Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia vytvorených DFD diagramov a diagramu tried • Prezentácia 1. fázy prototypu • Prezentácia šablóny • Rozčlenenie dokumentácie do konca semestra – pridelenie autorov • Pridelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- finalizácia DFD diagramu – diagram vytvorený – s
chválený s niekoľkými pripomienkami - OK -- tvorba Flash animácie – bola určená téma, ktorej sa animácia bude venovať. Preložené do nasledovného týždňa
• Peter Hlocký -- finalizácia E–R diagramu – diagram bol prerobený na diagram tried, ktorý lepšie vystihuje daný problém – bol schválený - OK
• Viliam Bedeč – tvorba prototypu prostredia pre tvorbu prezentácie – prvá fáza implementácie prebehla úspešne – bola prezentovaná – (viď nižšie) - OK
• Tomáš Chmel – tvorba prototypu konverznej utility – prvá fáza implementácie úspešne prebehla - OK
• Marcel Mésároš – analýza a návrh formátovania prezentácie – bola vytvorená prvá šablóna pre formátovanie prezentácie prototypu - OK – úprava dizajnu výslednej prezentácie - OK
Priebeh Stretnutia: • Bol prezentovaný implementovaný prototyp. Editovacie prostredie sp ĺňa
základné požiadavky naň kladené a konverzná utilita implementovaná Tomášom bez problémov funguje.
• Boli pripomienkované detailnejšie požiadavky na prototyp, ktoré budú implementované v budúcom týždni
Tímový projekt | Dokumentácia k riadeniu projektu
16
• Peter prezentoval diagram tried. Tento bol pretransformovaný z entitino – relačného diagramu kvôli lepšej názornosti. Tím sa zhodol, že diagram dobre znázorňuje problematiku a je prehľadný. S miernymi pripomienkami može byť použitý do dokumentácie.
• Marek odprezentoval DFD diagram. Tento bol rozpracovaný na 2. úroveň (0. úr. je kontextová). Tím sa zhodol, že podrobnejší diagram nemá zmysel v tejto fáze robiť a tento stav dobre znázorňuje problematiku.
• Po príchode Ing. Hudeca mu boli prezentované všetky diagramy a prototyp. Vyjadril spokojnosť s odvedenou robotou.
• Na záver sme rozdelili úlohy do budúceho týždňa (viď závery a pripomienky).
Závery a pripomienky: • Dokumentácia bude obsahovať tieto kapitoly (priložené k už vytvorenej
dok.): 3.5 – Model funkcií (autor Marek Hrablay) 3.6 – Model údajov (autor Peter Hlocký) 3.7 – Návrh šablón (autor Marcel Mésároš) 4 – Prototypovanie 4.1 – Ciele prototypovania (autor Peter Hlocký) 4.2 – Vyhodnotenie prototypovania (systém) (autor Villiam Bedeč) 4.3 – Vyhodnotenie prototypovania (prezentácia) (autor Marcel Méšároš)
• Dokumentácia k riadeniu bude rozšírená o nové zápisnice, priebeh riešenia
projektu a formálne dokumenty (zodpovedný Marek Hrablay) • Do 9.12.2003 musí byť vytvorená finálna verzia prototypu (zodpovedný
Viliam Bedeč). • S ing. Hudecom sme sa dohodli na prezentácii finálnej verzie prototypu dňa
15.12.2003 o 10:00 Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vytvorenie dokumentácie k riadeniu
-- vytvorenie kapitoly 3.5 • Peter Hlocký -- vytvorenie kapitoly 3.6, 4.1 • Viliam Bedeč – dokončenie prototypu
-- vytvorenie kapitoly 4.2 • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3
– dokončenie implementácie šablóny pre prototyp Zápisnicu vypracoval: Peter Hlocký
Tímový projekt | Dokumentácia k riadeniu projektu
17
4.9 Zápisnica zo stretnutia ÚVTP č. 9 Zápisnica zo stretnutia ÚVTP č. 9 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 9.12.2003 Čas: 10:15 – 10:45 Prítomní:
Ing. J. Hudec Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia 2. fázy prototypu • Kontrola stavu podkladov pre dokumentáciu a prototyp na kontrolný termín • Pridelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- vytvorenie dokumentácie k riadeniu – prakticky hotová,
chýba posledná zápisnica a problém s pripojením kapitoly Štábna kultúra – pripojí sa ku kompletnej -- tvorba Flash animácie – nedodané podklady, vytvorená iná -- vytvorenie kapitoly 3.5 – splnená
• Peter Hlocký -- vytvorenie kapitoly 3.6, 4.1 – splnená • Viliam Bedeč – dokončenie prototypu – po doladení splnená
-- vytvorenie kapitoly 4.2 – splnená • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita – práce
budú pokračovať až do termínu odovzdania • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3 – nesplnené, nutné dokončiť
do termínu odovzdania – dokončenie implementácie šablóny pre prototyp – pokračuje, zdržanie spôsobené negociačným procesom s konkurenčným tímom ohľadom kompatibility šablón
Priebeh Stretnutia: • Bola odprezentovaná druhá fáza prototypu. Rozšírenie o správu nadpisov. • Vzájomne sme sa informovali o plnení úloh • Navrhli sme vedúcemu projektu hodnotenie práce za etapu špecifikácie a
prototyp • Pokúsili sme sa začleniť animáciu do výslednej prezentácie
Tímový projekt | Dokumentácia k riadeniu projektu
18
• Dohodnutie technických detailov okolo dokumentácie • Na záver sme rozdelili úlohy do budúceho týždňa (viď závery a
pripomienky). Závery a pripomienky: • Potreba dotiahnuť detaily na prototype – ikony, nestabilita pri
o špecifikácia: § Peter 25 % § Marek 25 % § Vilo 15 % § Tomáš 15 % § Marcel 20 %
o prototyp: § Peter 10 % § Marek 10 % § Vilo 30 % § Tomáš 30 % § Marcel 20 %
• Nepodarilo sa jednoducho začleniť animáciu do prezentácie • Rozdelenie tlače dokumentácie medzi Mareka a Tomáša; podklady dostanú
od Marcela Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vytvorenie animácie k jednej vybranej časti 2. kapitoly
učebných materiálov -- dokončenie dokumentácie k riadeniu
• Peter Hlocký -- dohľad nad dokončovacími prácami na dokumentácii • Viliam Bedeč – doladenie prototypu • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3
– dokončenie implementácie šablóny pre prototyp – pripravenie 2. kapitoly učebných materiálov pre prezentáciu
Zápisnicu vypracoval: Marcel Mésároš
Tímový projekt | Dokumentácia k riadeniu projektu
19
4.10 Zápisnica zo stretnutia ÚVTP č. 10 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 24.2.2004 Čas: 13:00 – 14:00 Prítomní:
Ing. J. Hudec Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Vyhodnotenie zimného semestra • Prezentácia 2. fázy prototypu • Kontrola stavu podkladov pre dokumentáciu a prototyp na kontrolný termín • Pridelenie úloh na nasledujúci týždeň Priebeh Stretnutia: • Oboznámili sme sa s hodnotením zimného semestra • Určili sme si náš plán a postup práce pri dokončovaní projektu (viz. Plán na
web stránke) • Informovali sme vedúceho projektu a našej predstave pokračovania práce
na projekte • Bola určená časť skrípt ktorá bude spracovaná naším týmom • Na záver sme rozdelili úlohy do budúceho týždňa Závery a poznámky: • Náš tím bude spracovávať druhú polovicu skríp Počítače. Kapitola 4.4 až do
konca. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- návrh abstraktného dátového typu - strom • Peter Hlocký -- návrh abstraktného dátového typu - index • Viliam Bedeč – návrh abstraktného dátového typu – zreťazená volná
pamäť • Tomáš Chmel – zjemnenie DFD konverznej utility • Marcel Mésároš – návrh a vytvorenie ukážky ku navigovaniu v prezentácii
pomocou JavaScriptu – návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent
Zápisnicu vypracoval: Tomáš Chmel
Tímový projekt | Dokumentácia k riadeniu projektu
20
4.11 Zápisnica zo stretnutia ÚVTP č. 11 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 2. 3. 2004 Čas: 13:05 – 13:45 Prítomní:
Ing. J. Hudec Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel Marcel Mésároš
Program stretnutia: • Kontrola plnenia zadaných úloh • Informovanie vedúceho projektu o problémoch pri prístupe k elektronickej
verzii skrípt • Pridelenie úloh na nasledujúci týždeň Stav riešenia úloh: • Marek Hrablay -- návrh abstraktného dátového typu - strom – splnené • Peter Hlocký -- návrh abstraktného dátového typu - index – splnené
(problémy s triedením s diakritikou sa riešia) • Viliam Bedeč – návrh abstraktného dátového typu – zreťazená voľná
pamäť – splnené • Tomáš Chmel – zjemnenie DFD konverznej utility – splnené • Marcel Mésároš – návrh a vytvorenie ukážky k navigovaniu v prezentácii
pomocou JavaScriptu – rieši sa – návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent – splnené
Závery a poznámky: • Vedúci projektu sa pokúsi pomôcť získať elektronickú verziu skrípt
z Architektúry počítačov • Druhá kapitola bude hotová do budúceho stretnutia • Stretnutie nabudúce nebude Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- návrh vizuálnej stránky animácií • Peter Hlocký -- index – doriešenie triedenia s diakritikou • Viliam Bedeč – zreťazenie komponent a obrazoviek • Tomáš Chmel – dokumentácia návrhu • Marcel Mésároš – návrh a vytvorenie ukážky ku navigovaniu
v prezentácii pomocou JavaScriptu – dokončenie 2. kapitoly skrípt
Zápisnicu vypracoval: Marcel Mésároš
Tímový projekt | Dokumentácia k riadeniu projektu
21
4.12 Zápisnica zo stretnutia ÚVTP č. 12 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 9. 3. 2004 Čas: 13:05 – 13:50 Prítomní:
Marek Hrablay Peter Hlocký
Viliam Bedeč Tomáš Chmel
Program stretnutia: • Kontrola plnenia zadaných úloh • Zhodnotenie stavu implementácie • Upresnenie plánu • Pridelenie úloh na nasledujúci týždeň Stav riešenia úloh: • Marek Hrablay -- implementácia štruktúry nadpisov pomocou a.d.t. – strom
- splnené • Peter Hlocký -- riešenie problému s diakritikou a triedením - splnené • Viliam Bedeč – implementovanie zreťazenia komponent a obrazoviek
– v stave riešenia • Tomáš Chmel – zdokumentovanie návrhu konverznej utility – splnené • Marcel Mésároš – návrh a vytvorenie ukážky k navigovaniu v prezentácii
pomocou JavaScriptu – rieši sa – dokončenie spracovania druhej kapitoly skrípt Počítače
– rieši sa Závery a poznámky: • Všetky predchádzajúce úlohy implementácie boli splnené. Po dokončení
zreťazenia komponent a obrazoviek (naplánované na nasledujúci týždeň), budeme spájať súčiastky hlavného modulu a Tomáš započne implementáciu konverznej utility.
• Elektronická verzia skrípt je pripravená u doc. Krajčoviča – treba ju vyzdvihnúť.
• Začneme spracúvať skritá od kapitoly 4.4 do konca • Vilo predviedol návrh hlavnej obrazovky: S malými pripomienkami týkajúcich
sa editora html sme návrh schválili Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- dokončiť štruktúru nadpisov a zdokumentovať • Peter Hlocký -- spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do
konca • Viliam Bedeč – dokončiť zreťazenie komponent a obrazoviek • Tomáš Chmel – vytvoriť html prehliadač • Marcel Mésároš – spolu s Petrom spracovať skriptá od kapitoly 4.4 až
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prebranie problému skrípt • Popis funkcií, ktoré budú implementované v prototype • Rozdelenie implementácie • Problém spracovania skrípt • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay - dokončiť štruktúru nadpisov a zdokumentovať (OK) • Peter Hlocký - spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do
konca (OK) • Viliam Bedeč - dokončiť zreťazenie komponent a obrazoviek (OK) • Tomáš Chmel - vytvoriť html prehliadač (OK) • Marcel Mésároš - navigovanie v prezentácii pomocou JavaScriptu (OK)
- spolu s Petrom spracovať skriptá od kapitoly 4.4 až do konca (OK)
Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peťo doniesol potešujúcu správu – sú skriptá • Marek popísal ako dokončil stromovú štruktúru nadpisov • Marcel prezentoval navigáciu pomocou javascriptu • Tomáš popísal a ukázal nastavenia konverznej utility • Vilo nakoniec prezentoval ako si predstavuje ďalšie pokračovanie
v implementácii • Načrtol ako sa bude ďalej pokračovať v implementácii a ako sa opäť zadelia
úlohy medzi členov
Tímový projekt | Dokumentácia k riadeniu projektu
23
Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Pri opise implementácie sme si určili priority na funkčnosť aplikácie, teda
ktorým funkciám dať prioritu • Vyriešil sa problém so skriptami, takže je možné pokračovať v tvorení
prezentácie Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- štúdium práce v prostredí C++ Builder, príprava na
prezentáciu • Peter Hlocký -- prebranie skrípt v elektronickej forme a práca na ich
spracovaní spolu s Marcelom • Viliam Bedeč – sfunkčnenie prostredia aplikácie – možnosť vytvárať
štruktúru prezentácie • Tomáš Chmel – úprava utility na tvorbu používateľského prostredia
výslednej prezentácie • Marcel Mésároš – pomoc pri formátovaní skrípt spolu s Peťom Zápisnicu vypracoval: Viliam Bedeč
Marcel Mésároš Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prebranie problému skrípt • Popis funkcií, ktoré budú implementované v prototype • Rozdelenie implementácie • Problém spracovania skrípt • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrabaly -- štúdium práce v prostredí C++ Builder, príprava na
prezentáciu (OK) • Peter Hlocký -- prebranie skrípt v elektronickej forme a práca na ich
spracovaní (OK)
Tímový projekt | Dokumentácia k riadeniu projektu
24
• Viliam Bedeč – sfunkčnenie prostredia aplikácie možnosť vytvárať štruktúru prezentácie (OK)
• Tomáš Chmel – úprava utility - tvorba používateľského prostredia výslednej prezentácie (OK)
• Marcel Mésároš – pomoc pri formátovaní skrípt spolu s Peťom (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peter doniesol vypracovanú kapitolu 4.2 v HTML štruktúre
o Po ozrejmení situácie s HTML textom sme zistili že ďalšia práca na ňom je pre náš tím zbytočná z dôvodu nekompatibility s editorom prezentácie
o Konverzácia a následná dohoda s tímom č. 12 o pozastavení spoločnej tvorby skrípt vzhľadom na to, že pre náš projekt je nepoužiteľný formát skrípt spracúvaných tímom č. 12 (viď HTML)
o Peter sa zaviazal vytvoriť o probléme správu a referovať o ňom na ďalšom stretnutí
o kapitoly budú ďalej vytvárané v našom vlastnom formáte • Tom s Vilom prezentovali nové verzie programov spolu s podrobným
komentárom k postupu implementácie – zatiaľ všetko postupuje podľa časového plánu
• Marcel navrhol začať napĺňať obsahovú stránku prezentácie s daným prototypom aplikácie
o zamietnuté kvôli problémom s ukladaním prezentácie – v štádiu riešenia
• Rozprava o nadchádzajúcej prezentácii o spôsoboch komunikácie tímu o Marek dostal za úlohu vypracovať správu a pripraviť prezentáciu
• Rozdelenie úloh na ďalší týždeň Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Vyriešili sme problém so zbytočnou prácou s HTML textami • Progres vo vývoji aplikácie je na veľmi dobrej úrovni Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vypracovanie prezentácie o spôsoboch komunikácie
– integrácia stromovej štruktúry do projektu • Peter Hlocký -- dokončiť kap. 4.2, urobiť kap 4.1 do podoby výslednej
prezentácie • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov
– implementácia funkcií načítania a uloženia prezentácie • Tomáš Chmel – implementovať konverziu obrazoviek a štruktúry
komponent • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentovanie prvej verzie editora a konverznej utility • Diskusia o tematickom dizajne web stránky • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- vypracovanie prezentácie o spôsoboch komunikácie (OK)
– integrácia stromovej štruktúry do projektu (Pokračuje) • Peter Hlocký -- dokončiť kap. 4.2, urobiť kap 4.1 do podoby výsledném
prezentácie (OK) • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov
(Pokračuje) – implementácia funkcií načítania a uloženia prezentácie (OK)
• Tomáš Chmel – implementovať konverziu obrazoviek a struktury komponent (OK)
Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Marek bol pokarhaný za neskoré dodanie zápisnice s minulého týždňa • Peter zreferoval, že správu ktorú uvažoval vytvoriť nevytvoril, nakoľko by do
danej situácie aj tak nepriniesla viacej svetla • Tom s Vilom prezentovali nové verzie programov, ktoré boli predvedené aj
vedúcemu projektu. Bola prezentovaná možnosť ukladania a začítavania projektu prezentácie.
o Pri prezentovaní konverznej utility sa objavili malé problémy a tak neboli jej možnosti zatiaľ prezentované.
• Rozprava o nadchádzajúcej prezentácii o dosiahnutom progrese na stretnutí RvPI 7.4.2004.
o Marcel dostal za úlohu vypracovať a pripraviť prezentáciu. Táto skutočnosť mu bude dodatočne oznámená
• Diskusia a hľadanie vhodného obrázku pre potreby tematického dizajnovania web stránky s blížiacou sa veľkou nocou.
• Rozdelenie úloh na ďalší týždeň
Tímový projekt | Dokumentácia k riadeniu projektu
26
Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Progres vo vývoji aplikácie je na veľmi dobrej úrovni Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – integrácia stromovej štruktúry do projektu • Peter Hlocký -- testovanie editoru naplnením systému kapitolou 4.1 a 4.2.
-- oboznámenie sa vývojovým prostredím Borland Builder a implementácia Indexu do editora
• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov • Tomáš Chmel – pokračovanie v implementácii konverznej utility • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Informácia o stave implementácie • Hodnotenie priebežného testovania • Dohodnutie informácií, ktoré budú uvedené v prezentácii stavu projektu • Rozdelenie úloh pri príprave dokumentácie Stav plnenia úloh z minulého týždňa • Marek Hrablay – integrácia stromovej štruktúry do projektu (Pokračuje) • Peter Hlocký -- testovanie editoru naplnením systému kapitolou 4.1 a 4.2. (Nesplniteľná – nefungovali nadpisy a atribúty komponent) -- oboznámenie sa vývojovým prostredím Borland Builder a implementácia Indexu do editora. (Pokračuje)
Tímový projekt | Dokumentácia k riadeniu projektu
27
• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov (Pokračuje) • Tomáš Chmel – pokračovanie v implementácii konverznej utility (Pokračuje) • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania
výslednej prezentácie rozbaľovaním hierarchie nadpisov (Pokračuje) – príprava prezentácie o dosiahnutom progrese (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peter nemohol splniť úlohu naplnenia a testovania, pretože program nebol v
stave, aby sa s ním dalo pracovať (chýbali základné prvky pre orientáciu v projekte – zobrazenie aspoň časti vložených textov); ďalšie nedostatky boli v neimplementovanom generovaní HTML kódu pre nadpisy a atribúty textu.
• Tom s Vilom zaznamenali a následne riešili problémy pri linkovaní oboch častí programu – zdržanie
• Stále chýba stromová štruktúra, ktorú má implementovať Marek • Rozprava o nadchádzajúcej prezentácii o dosiahnutom progrese na stretnutí
RvPI 7.4.2004. Dohodnuté prezentovanie častí oddelene (UI, KU, prezentácia); prototyp na zahodenie; na technické otázky budú odpoveda ť tí, ktorí sa v nich vyznajú.
• Rozdelenie úloh na ďalší týždeň Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Je potrebné dotiahnuť funkcie umožňujúce použiteľnosť aplikácie pre
Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – integrácia stromovej štruktúry do projektu
– príprava používateľskej príručky • Peter Hlocký – testovanie nasledujúcej verzie editoru
– príprava dotazníka na testovanie • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov • Tomáš Chmel – pokračovanie v implementácii konverznej utility – atribúty
komponent • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Príprava na odovzdanie priebežnej verzie • Zhodnotenie stavu verzie systému 0.9, ktorá sa bude odovzdávať • Prezentácie tejto verzie Ing. Hudecovi • Príprava krátkodobého plánu na nasledujúce štyri týždne • Zhodnotenie používateľskej príručky • Zhodnotenie alfa testovania verzie 0.9 Stav plnenia úloh z minulého týždňa • Marek Hrablay – integrácia stromovej štruktúry do projektu
• Peter Hlocký – testovanie nasledujúcej verzie editoru (verzia 0.9 je pripravená na odovzdanie) – príprava dotazníka na testovanie (úloha splnená)
• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov (úloha splnená) • Tomáš Chmel – pokračovanie v implementácii konverznej utility – atribúty
Priebeh Stretnutia: • Dohodli sme sa na krátkodobom pláne na ostatné štyri týždne :
o beta testovanie verzie systému 0.9 o naplnenie systému vzorkou údajov – kapitola 4 – skriptá o v prípade plnej funkčnosti za splnenie podmienok kladených na
softvérový produkt doplnenie funkcií – index a stromová štruktúra nadpisov.
o otestovanie systému a odovzdanie finálnej verzie • Zhodnotili sme systém VSAM v0.9 a zhodli sme sa, že po odstránení
miernych nedostatkov vyplývajúcich z alfa testov, je pripravený na odovzdanie
• Systém VSAM v0.9 sme prezentovali Ing. Hudecovi. Mierne nedostatky, ktoré sa pri neformálnej prezentácii objavili, odstránime
Tímový projekt | Dokumentácia k riadeniu projektu
29
• Zhodli sme sa, že našou prvoradou úlohou je vytvoril systém plne funkčný a otestovaný, ktorý bude stabilný a tak pripravený na odovzdanie
Závery a pripomienky: Našou prvoradou úlohou je vytvoriť stabilný systém, ktorý by sme mohli vo finálnej verzii odovzdať. Preto sme pozastavili dopĺňanie funkcionality a v nasledujúcich dvoch týždňoch sa zameriame na testovanie a napĺňanie systému. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – Finalizácia používateľskej príručky
- Testovanie VSAM v0.9 • Peter Hlocký - Príprava Beta testovania - Príprava testovacích vzoriek • Viliam Bedeč – Oprava chýb nájdených alfa testom vo verzii 0.9 • Tomáš Chmel – Prirobenie konverzie rozbaľovatelného obsahu do
konverznej utility • Marcel Mésároš – Vytvorenie druhej šablóny Zápisnicu vypracoval: Peter Hlocký
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Rozvrh prác na dokumentácii • Otázka implementácii ďalších funkcií do aplikácie • Testovanie aplikácie Stav plnenia úloh z minulého týždňa • Marek Hrablay - Finalizácia používateľskej príručky (OK)
- Príprava testovacích vzoriek (splnené a pokračuje) • Viliam Bedeč - Oprava chýb nájdených alfa testom vo verzii 0.9
(splnené a pokračuje) • Tomáš Chmel - Prirobenie konverzie rozbaľovateľného obsahu do
konverznej utility (OK) • Marcel Mésároš - Vytvorenie druhej šablóny (OK)
Tímový projekt | Dokumentácia k riadeniu projektu
30
Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Nájdené chyby sa podarilo odstrániť, preto sa začneme venovať dokončeniu
dokumentácie • Rozdelili sme si dokumentáciu • Opäť sme si dali priority na implementáciu ďalších funkcií • Prebrali sme si chyby, ktoré sme našli počas testovania Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Počas testovania sa vyskytli opäť chyby, takže sme získali ďalšie možnosti
vylepšenia • Rozdelili sme si dokumentáciu a naplánovali jej ukončenie na ďalší týždeň Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- testovanie a naplnenie programu kapitolami 4.3 • Peter Hlocký -- naplnenie programu kapitolami 4.1 a 4.2 • Viliam Bedeč – oprava chýb a napísanie návrhu a implementácie na
editor • Tomáš Chmel – oprava chýb a úprava dokumentácie návrhu
a implementácie konvertoru • Marcel Mésároš – dokumentácia návrhu a implementácie výslednej
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia beta verzie VSAM • Rozvrh prác na dokumentácii • Testovanie aplikácie • Finalizácia tímového projektu Stav plnenia úloh z minulého týždňa • Marek Hrablay -- testovanie a naplnenie programu kapitolami 4.3
(pracoval na 4.2.2) • Peter Hlocký -- naplnenie programu kapitolami 4.1 a 4.2 (OK po 4.2.1)
Tímový projekt | Dokumentácia k riadeniu projektu
31
• Viliam Bedeč – oprava chýb a napísanie návrhu a implementácie na editor (OK)
• Tomáš Chmel – oprava chýb a úprava dokumentácie návrhu a implementácie konvertoru (OK)
• Marcel Mésároš – dokumentácia návrhu a implementácie výslednej prezentácie (pokračuje)
Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa. • Peter a Marek prezentovali kapitoly 4.1, 4.2, a 4.3 naplnené pomocou
VSAMu. • Tom a Vilo referovali o dodatkoch k dokumentácii o návrhu a implementácii. • Vilo prezentoval ďalšiu beta verziu VSAM. • Znova sme preberali chyby, ktoré sme našli počas testovania a napĺňania
skrípt kapitolami. • Rozdelili sme si úlohy spojené s finalizáciou tímového projektu. Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Ďalšie objavené chyby beta verzie VSAM a konvertora do HTML, budú
riešené do budúceho týždňa. • Ukončenie dokumentácie, rozdelenie jednotlivých častí dokumentácie na
formátovanie a prípravu na tlač. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- napísanie dokumentácie k riadeniu projektu na letný
semester • Peter Hlocký -- prerobiť kapitoly 4.1 a 4.2
Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Dohodnutie termínu odovzdania a prezentácie produktu • Dohodnutie posledných úprav dokumentu a produktu • Rozdelenie percentuálneho hodnotenia členov tímu Stav plnenia úloh z minulého týždňa • Marek Hrablay -- napísanie dokumentácie k riadeniu projektu na letný semester (OK) • Peter Hlocký -- prerobiť kapitoly 4.1 a 4.2 (OK) • Viliam Bedeč – oprava drobných chýb VSAM, opraviť spájanie projektov (OK) • Tomáš Chmel – oprava chýb konverznej utility (OK) • Marcel Mésároš – formátovanie dokumentácie (OK)
-- doplnenie kaskádového štýlu o štvrtú úroveň (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa. • Za účasti členov tímu 12 sme sa dohodli na dátume a čase odovzdania a prezentovania
produktu – 17.5.2004 11:00. • Marcel doniesol sformátovanú dokumentáciu pripravenú na tlač, no zistilo sa, že v nej chýba
implementačná časť k editoru. • Rozhodlo sa, že funkciu pripájania projektov prezentácií bude s produktu vynechaná kvôli jej
prílišnej implementačnej zložitosti. • Zhodli sme sa na obsahu CD prílohy ku dokumentácii. Závery a pripomienky: • Obsah CD prílohy ku dokumentácii bude obsahovať:
o Dokumentáciu k produktu o Produkt ako inštalačný súbor o Posledná verzia internetovej stránky o Ukážky prezentácií vytvorených v editori a ručne o Zdrojové súbory produktu
• Percentuálne hodnotenie členov tímu: Člen Dokumentácia Produkt
Peter Hlocky 20% 20% Viliam Bedeč 10% 30% Marek Hrablay 30% 10% Tomáš Chmel 15% 25% Marel Mésároš 25% 15%
• Posledné úlohy na projekte, ktoré treba dorobiť do odovzdania, prípadne skorej: • Marek Hrablay -- vyrobenie flash animácie do ku kapitole 4.
-- prepísať používateľskú príručku pre najnovšiu verziu produktu • Peter Hlocký -- dokončenie prezentácie podľa kapitoly 4. pomocou editora • Viliam Bedeč – oprava posledných chybičiek editora
– dopísať záver ku dokumentácii • Marcel Mésároš – doplniť dokumentáciu o chýbajúce časti
• Dokumentáciu vytlačia a CD médiu vyhotovia Viliam Bedeč a Tomáš Chmel . Zápisnicu vypracoval: Tomáš Chmel
Tímový projekt | Dokumentácia k riadeniu projektu
1
5. Posudky V tejto kapitole sú uvedené všetky doposiaľ vytvorené posudky. Jedná sa
o posudky jednotlivých častí nášho projektu konkurenčným tímom, posudky jednotlivých častí konkurenčného projektu našim tímom ako aj vyjadrenia nášho tímu k jednotlivým posudkom.
Tímový projekt | Dokumentácia k riadeniu projektu
2
5.1 Posudok konkurenčného projektu, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím : Tím č. 12 Dátum: 20.11.2003 Posudzoval: Tim č.9 Autor: Peter Hlocký OBSAHOVÁ STRÁNKA Nakoľko dokumentácia k vývoju softvérového systému začína číslovaním kapitol obsahom, prejdeme rovno ku kapitole 2 – Analýza požiadaviek. Autori zaradili na začiatok tejto kapitoly úvod do problematiky. Tento je napísaný prehľadne a dobre približuje čitateľovi diskutovaný problém. Obzvlášť by sme chceli vyzdvihnúť podkapitolu 2.3 – prístup k multimediálnym kurzom, ktorá veľmi dobre opisuje prehľad životného behu elektronickej výučby. Chceli by sme sa však pozastaviť pri podkapitole 2.5 – Analýza existujúcich systémov, konkrétne Cisco Networking Academy Program. Táto časť popisuje vzdelávací program, avšak nie je z nej zrejmé ako to súvisí s elektronický vzdelávaním. Po prečítaní textu vzniká skôr dojem, že ide o denné štúdium. Celkovo by sa dalo k analýze existujúcich riešení povedať, že aj keď riešenia predstavila, neposkytla žiadne východiská. Bolo by vhodné spomenúť výhody a nevýhody jednotlivých riešení a prípadné výhody využiť vo vytváranom systéme. Využijú autori nejaké poznatky nadobudnuté analýzou alebo bola zbytočná? Ku kapitole 3 – Špecifikácia požiadaviek máme tieto pripomienky. Autori identifikovali niektoré požiadavky, avšak všetky sú funkcionálne. Na systém nie sú kladené iné druhy požiadaviek, napríklad bezpečnostné, systémové atď.? Čo sa týka uvedených požiadaviek : je ich šestnásť, ktoré popisujú funkcie systému, avšak možno by mohli byť bližšie popísané. Napríklad požiadavka č.1 – vytvoriť kapitolu. Z popisu nie je jasné či systém poskytuje napr. voľbu číslovania kapitol alebo ako je to s hierarchickým členením kapitol. Tento príklad uvádzame predovšetkým preto, aby sme upozornili, že zoznam požiadaviek by mal obsahovať podrobne rozpracované požiadavky. Existuje možnosť vytvorenia katalógu požiadaviek , kde sa môžu požiadavky hierarchicky členiť, čo pomáha pri orientovaní. Časť 3.4 – špecifikácia používateľov systému uvádza dva druhy používateľom, avšak nie sú jednoznačne určené ich názvy, čo sťažuje orientáciu v ďalšom texte. V nasledujúcej časti 3.5 je uvedené, že prezentácia je prístupná cez voľne dostupný internetovský prehľadiač, avšak potom vyvstáva otázka, či študent prezentácie, je používateľom vytváraného systému, ak využíva iba jeho výstup (ako bolo uvedené v časti 3.4 „... nebudú mať možnosť ani dôvod meniť obsah a štruktúru jednotlivých častí.“). V kapitole 4 – Návrh je zrejmá absencia časti, ktorá by čitateľovi priblížila hrubý náhľad na systém. Konkrétne by mohla obsahovať hrubú blokovú architektúru systému, ktorá by čitateľa bližšie dostala k nasledovne diskutovanému problému pri funkčnom a dátovom návrhu. Autori sa zrejme o toto pokúsili v podkapitole 4.2 – dekompozícia systému, avšak určite sa nehodí hneď do článku 4.2.1 vložiť pojednanie o súborovej správe prezentácie a probléme rušenia krížových referencií v kapitolách. Toto sú užšie problémy, na ktoré je miesto v pokročilejších fázach riešenia. V časti 4.2.2 sú spomenuté prvky obrazovky ako navigátor, navigačné tlačítka a iné. Prečo nie sú uvedené medzi požiadavkami na systém v kapitole 3?
Podkapitola 4.3 pojednáva o prípadoch použitia systému. Keď sa používa táto technika, je vhodné uviesť aj roly používateľov. Tie síce sú uvedené v kapitole 3, ale
Tímový projekt | Dokumentácia k riadeniu projektu
3
názvy používateľov sú uvedené iné ako sú použité v samotnom diagrame a potom nie je jasné, kto je kto. Dostali sme sa k diagramu prípadov použitia systému tvorby prezentácií, ktorý je zobrazený na obr. 4.1 v dokumentácii. Sú tu uvedené prípady, ktoré však po dekomponovaní dávajú funkcie, ktoré nie sú nikde popísané. Máme predovšetkým na mysli vzťah k už spomínanej špecifikácii požiadaviek. Obr 4.2 znázorňuje prípady použitia systému na prehliadanie prezentácií. Prehliadanie prezentácií nie je prístupné role s popisom „pedagóg“ (nakoľko v diagrame nie je)?
Teraz by sme sa radi vyjadrili k podkapitole 4.4 – Diagramy tokov údajov. Ku kontextovému diagramu (obr. 4.3) by sme radi pripomenuli, že by sa tu mal vyskytovať iba jediný proces, ktorý reprezentuje celý systém. Nasledovne v nižších úrovniach diagramu nie je dobré dávať externé entity (ako vidíme na obr. 4.4 až 4.7). Tie by mali komunikovať iba na kontextovej úrovni s hlavným procesom. Obr. 4.4 - Ako môže z úložiska dát „Prezentácie“ vychádzať údaj „test kapitoly“? Obdobný problém sa vyskytuje aj v ostatných diagramoch. Tiež sa vyskytol problém (obr. 4.5) s úložiskom „prezentácie“, z ktorého nevychádza žiaden tok údajov. Celkovo by sa dalo povedať, že diagram tokov údajov nie je vytvorený najvhodnejšie, čomu prispela aj veľká neprehľadnosť. Neboli použité číslovanie procesov a úložiská údajov z vyšších úrovní sa bežne vyskytujú na nižších úrovniach.
Prejdime k modelu údajov popisovanom v podkapitole 4.5 – údaje v systéme. Na úvod by sme radi spomenuli, že model údajov, podobne ako model funkcií (diagram tokov údajov) nie je spracovaný dobre. Vytknúť sa mu dajú predovšetkým zásadné chyby, ktoré by sa tu nemali vyskytnúť. Model údajov nemôže obsahovať atribúty, ktoré sú zároveň entitami. Ak boli tieto atribúty myslené ako cudzie kľúče, treba pripomenúť, že tie sa uvažujú až pri fyzickom modeli a nie už pri modeli logickom. Vysvetlenie nepriniesol ani popis atribútov entít, ktorý je spracovaný biedne a takže vlastne ani nemusel byť v dokumentácii uvedený. Tiež je dobrým zvykom popisovať vzťahy medzi entitami, ktoré tu úplne chýbajú. Entita „test“ obsahuje atribúty „otázky“, „možnosti“ a pod.. Toto sú zrejme textové komponenty a asi by mal byť znázornený vzťah s entitou, ktorá by ich vystihovala (asi mali autori na mysli vyjadrenie cez kompozíciu a entitu „Element“... na čo sú tam potom tie atribúty?). Vzťah generalizácie medzi entitou „Test“ a „Dokument“ nechápeme. V predloženom modely údajov by sa dalo nájsť viac chýb, avšak zrejme už nemá zmysel ich vymenovávať všetky. Nedá nám ale nepripomenúť nevhodný príklad kompozície na strane 4.18. K obsahovej stránke dokumentácie k riadeniu projektu by sme mali iba výhrady k absencii podrobného plánu do konca zimného semestra. Ináč je táto časť spracovaná veľmi dobre. Týmto by sme chceli uzavrieť posudok k obsahovej stráne predloženej časti projektu s hodnotením, že autori evidentne vyvinuli značné úsilie pri tvorbe dokumentácie, čo sa prejavilo na dobrej analýze. Toto úsilie však mierne zmaril návrh, ktorý by možno bolo dobré prepracovať. Sumarizácia :
• klady o úvod do problematiky o dokumentácia k riadeniu projektu
• zápory o neúplný zoznam požiadaviek o absencia hrubého pohľadu na systém (architektúra) o diagram tokov údajov o dátový model
Tímový projekt | Dokumentácia k riadeniu projektu
4
5.2 Posudok nášho projektu, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím : Tím č. 9 Dátum: 21.11.2003 Posudzoval: Tim č.12 Autori: Bc. Eduard Chrvala, Bc. Roman Páterek
5.2.1 Úvod Tento dokument je posudkom ku tímovému projektu Multimediálna podpora
predmetu Architektúra počítačov tímu č. 9. Je tu hodnotená výsledná dokumentácia konkurenčného tímu, čo sa týka formálnej a obsahovej stánky dokumentu. Posudok obsahuje náš názor a vylepšenia k jednotlivým hlavným kapitolám a ich spracovaniu, ako bol daný systém navrhnutý. Čo tam chýba a čo by tam nemuselo byť.
5.2.2 Formálna stránka dokumentu
Členenie dokumentu do kapitol a podkapitol je logické a štrukturované podľa obsahu rozoberanej témy na veľmi dobrej úrovni. Autori majú premyslený formát dokumentácie. V obsahu majú pomenované kapitoly „Špecifikácia a analýza požiadaviek“ a na str. 19 je jej meno iba „Analýza“ a takisto „Návrh požiadaviek“ ako „Prezentácia“. V posudzovanom dokumente sa nachádza zopár gramatických chýb. Str. 3, str. 7. Vety v dokumente sú dlhé a sem tam formulované mierne nejednoznačné, ale správnu informatívnu hodnotu. Vidno že na dokumente pracovalo viacero autorov, každý z nich má iný spôsob tvorenia dokumentácie. Formátovanie textu je zle čitateľné a únavné pre čitateľa, odporúčali by sme zväčšiť veľkosť písma a zarovnanie textu do bloku, nakoľko ešte dokument je dosť nekvalitne vytlačený, to zvyšuje jeho nečitateľnosť a prehľadnosť. Pri obrázkoch použitých ako náhľad str. 16,17,18,31 ... chýbajú ich čísla a stručný popis a ich označenie ku ktorému opisu problematiky patria (začlenenie odkazov v texte na obrázky). Pričom v hrubom návrhu sú dva obrázky jednoducho očíslované. Na číslovanie obsahu mali autori použiť formát čísel i,ii,iii a nie číslovať hneď od obsahu až po koniec dokumentu. Dokumentácia zverejnená na internetovej stránke tímu sa jednoznačne nezhoduje s vytlačenou dokumentáciou, chýba posledná kapitola.
5.2.3 Obsahová stránka dokumentu Obsahová stránka je spracovaná na vysokej úrovni, čo je znak toho, že na
projekte pracujú ľudia z dobrými znalosťami o danej problematike. Obsahová stránka je rozobraná v tomto dokumente jednotlivo pre každú kapitolu a sú tu spomenuté pripomienky k formálnej stránke jednotlivých kapitol.
Kapitola Úvod Po obsahovej stránke obsahuje všetky potrebné informácie.
Kapitola Opis problematiky V tejto kapitole je celkom dobre rozobraná problematika výučby predmetov a možnosti zvýšenia kvality výučby využitím počítačovej techniky. V cieľoch projektu autori nejednoznačne naznačili vetou „V každom prípade bude našou prioritou vytvoriť systém, ktorý bude v maximálnej miere spĺňať požiadavky naň kladené, ktorý bude na konci (aspoň sčasti) naplnený údajmi z obsahu predmetu Architektúra počítačov a ktorý
Tímový projekt | Dokumentácia k riadeniu projektu
5
bude na konci letného semestra plne použiteľný na nasadenie.“, čo bude výsledkom ich práce. Výsledkom má byť CD nosič, ktorý bude multimediálna prezentácia o predmete Architektúra počítačov zadané na začiatku zimného semestra. Systém môže byť použiteľný aj s pár kapitolami, ale nespĺňa zadané požiadavky. Podkapitoly E-learning a školstvo, spôsoby komunikácie a jeho využitie sú pekne spracované. Autori sa zaoberali iba komerčnými prostrediami pre tvorbu prezentácií, čo je pre školskú výučbu dosť neefektívne. Pri analýze jednotlivých elektronických systémov využitých na výučbu sa nemuseli zaoberať formátovaním dokumentov.
Kapitola Katalóg požiadaviek Pomerne rozsiahla kapitola, ktorá vystihuje dostatočne do hĺbky všetky funkcie
systému. Hodila by sa skôr do návrhu a tiež čo sa týka chronologického poradia by bolo vhodnejšie keby návrh vysvetlil členenie systému na čo by potom detailne nadviazal katalóg požiadaviek.
Kapitola Scenáre použitia Takisto by sa táto kapitola hodila skôr do návrhu. Autori zvolili scenáre, ktoré sú
navzájom dosť podobné, dali by sa zvoliť aj scenáre zaujímavejších situácií. Niektoré formulácie viet nie sú celkom výstižné. Obrázok použitý v scenároch je málo reprezentatívny. Po formálnej stránke je táto kapitola na dobrej úrovni.
Kapitola Analýza formátovania Je pomerne rozsiahla a prehľadne spracovaná. Veľmi dobre sú popísané
jednotlivé doporučované konvencie formátovania textu. Mohli byť uvedené aj zásady vkladania audiovizuálnych dokumentov do textu. V kapitole chýba zoznam konvencií použitých v samotnej práci, obsahuje drobné pravopisné chyby. Paradoxne záver analýzy formátovania by mohol byť lepšie formátovaný.
Kapitola Interview s Ing. J. Hudecom Kapitola je výborným doplnkom v dokumentácií, slúži ako dobrá náhrada za
špecifikáciu požiadaviek. Jednotlivé otázky by mohli byť výraznejšie oddelené a lepšie formátované.
Kapitola Návrh Po formálnej stránke je návrh dobre členený. Hodil by sa pred katalóg
požiadaviek, čitateľovi by boli jednotlivé funkcie popisované v katalógu zrejmejšie. Úvod k návrhu by sa skôr hodil do analýzy existujúcich produktov. Dekompozícia systému je na dobrej úrovni. Niektoré vety nie sú dobre formulované, čitateľovi uniká ich význam. Použité diagramy názorne popisujú problematiku. Návrh mohol byť doplnený o model údajov aspoň najvyššej úrovne. Dva diagramy v návrhu sú číslované a v podkapitole prezentácia sa nachádza obrázok, ktorý nie je očíslovaný.
5.2.4 Záver Celkovo hodnotíme výsledný projekt konkurenčného tímu veľmi pozitívne.
Problematika je rozobraná na dobrej úrovni, čo sa týka opisu, analýzy a hrubého návrhu. Pokryli požiadavky zadávateľa projektu a navyše do daného projektu pridali svoje funkcie, ktoré obohacujú výsledný produkt. Len treba dať pozor na to, že aby tím bol schopný dokončiť funkcie systému, ktoré si tam navyše pridali, čo môže byť faktorom že nestihnú urobiť výsledný produkt v požadovanom čase.
Tímový projekt | Dokumentácia k riadeniu projektu
6
5.3 Vyjadrenie sa k posudku, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím posudku: Tím č. 12 Dátum: 29.11.2003 Autor: Peter Hlocký
Tento dokument slúži ako vyjadrenie k posudku k prvému kontrolnému termínu stavu projektu Multimediálna podpora predmetu Architektúra počítačov vyvíjaným tímom č.9. Na úvod by sme radi uviedli, že mierne nižšia štylistická úroveň posudku nás viedla k neporozumeniu niektorých, možno konštruktívnych kritík. Preto sa vyjadríme iba k nasledovným :
Súhlasíme s námietkami k nekonzistencii dokumentácie vytlačenej a uvedenej na internete. Tento nedostatok, spôsobený problémom pri prenose súboru, bol bezodkladne napravený. Rovnako pripúšťame nedostatok pri označovaní obrázkov a náprava bude zjednaná pri ďalšej verzii dokumentácie v druhom kontrolnom termíne.
Dovoľujeme si nesúhlasiť s námietkami k formátovaniu textu v časti 2 posudku. Domnievame sa, že formát dokumentácie bol vytvorený s maximálnym dôrazom na prehľadnosť a zrozumiteľnosť, a veľkosť písma je štandardná pre takýto druh textu. V časti 3.2 posudku nesúhlasíme s námietkou na zaradenie formátovania dokumentov, pretože je nedeliteľnou a podstatnou časťou nášho projektu a vhodne dopĺňa analýzu o poznatky z tejto oblasti. V časti 3.3 sa nám vyčíta zaradenie katalógu požiadaviek medzi analýzu a návrh systému. K takémuto rozhodnutiu nás viedol fakt, že katalóg požiadaviek je súhrnom všetkých požiadaviek na systém, ktoré sme identifikovali a ktoré priamo vyplynuli z analýzy. Pri návrhu potom tieto požiadavky realizujeme. Toto sú dôvody, ktoré nás viedli k rozhodnutiu uviesť katalóg požiadaviek medzi analýzu a návrh. Nemenej podstatným faktom však bola aj bežná prax takéhoto usporiadania aj skúsenejšími tímami ako sme my.
K ostatným námietkam sa vyjadrovať nebudeme, pretože vychádzajú iba z iného názoru na tvorbu dokumentácie k inžinierskemu dielu a pokladáme ich za nekonštruktívne.
Tímový projekt | Dokumentácia k riadeniu projektu
1
6. Preberacie protokoly V tejto kapitole uvádzame preberacie protokoly, ktoré potvrdzujú prevzatie dokumentácie k projektu zadávateľom a zároveň aj posudzovateľom projektu. Preberacie protokoly sú vytvorené pre každý kontrolný bod, v ktorom sa preveruje stav riešenia projektu.
Tímový projekt | Dokumentácia k riadeniu projektu
1
7. Štábna kultúra Na tomto mieste budú uvedené spoločné dohody pri tvorbe projektu ako aj príslušnej dokumentácie s cieľom zprehľadniť a uniformovať jednotlivé časti a umožniť tak bezproblémové zlúčenie výsledného produktu. Obsah štábnej dokumentácie: 1) Štábna kultúra dokumentácie k projektu