SLOVENSKÁ
TECHNICKÁ UNIVERZITA
Fakulta informatiky a informačných
technológií
Posudok na tímový projekt
TVORBA TESTOV S VYUŽITÍM LATEXU
tímu č.5 (FOO)
Vypracovali za tím č.10: Bc. Miroslava Romanová
Bc. Lukáš Slížik
Študijný odbor: Informačné systémy
Kontakt: team1078@gmail.com
Školský rok: 2007/2008
Dátum: 22. novembra 2007
Cieľom tohto dokumentu je vypracovanie posudku na časť dokumentácie vytvorenej tímom číslo 5 (FOO). Témou ich tímového projektu je Tvorba testov s využitím Latexu. Dá sa tvrdiť, že zmysel riešenia ich projektu je podobný tomu nášmu, nakoľko sa oba projekty usilujú o zlepšenie efektívnosti výučby na našej fakulte.
Posudok je rozdelený na dve hlavné časti, v ktorých sme sa venovali obsahovej a formálnej stránke tímovej dokumentácie a dokumentácie k riadenie projektu. Obsahová stránka je zameraná najmä na analýzu, špecifikáciu požiadaviek a návrh projektu posudzovaného tímu.
OBSAHOVÁ STRÁNKA
Jednotlivé časti tímovej dokumentácie sú rozdelené do 4 základných kapitol (Úvod, Analýza problémovej oblasti, Špecifikácia požiadaviek a analýza systému, Návrh systému), ktoré na seba logickým spôsobom nadväzujú.
Úvod
V úvodnej kapitole sa okrem zadania projektu, slovníka pojmov a skratiek a použitej notácie (tieto časti sú bežné vo väčšine dokumentácií) nachádza aj stručný prehľad dokumentu, ktorý čitateľovi poskytne rýchly prehľad celým dokumentom. Oceňujeme zaradenie tohto prehľadu, kvôli jeho stručnosti a výstižnosti.
Pri použitej notifikácií sa autori rozhodli uviesť len diagram požiadaviek, pretože ako uvádzajú, ostatné diagramy vychádzajú z jazyka UML. Na jednej strane hodnotíme tento fakt pozitívne, pretože väčšina čitateľov tohto dokumentu jazyk UML ovláda, ale z pohľadu osoby, ktorá UML neovláda, sa vyžaduje jeho dodatočné doštudovanie.
Analýza problémovej oblasti
Problémová oblasť je preštudovaná do primeranej hĺbky. Značná časť tejto kapitoly je venovaná analýze už existujúceho systému TestGen. Autori však vôbec nespomínajú odkiaľ sa k tomuto systému dostali, kto je jeho autorom a kedy vznikol. Tieto informácie by pre úplnosť nemali chýbať. V tejto časti je takisto spomínaný logický model systému TestGen, o ktorom sa autori vyjadrujú pozitívne, no nakoľko nie je uvedený alebo aspoň popísaný, je táto informácia pre nezainteresovaného čitateľa irelevantná.
Ďalej autori upriamili pozornosť vo svojej analýze na softvérový systém Moodle, pretože členovia zvažujú myšlienku prepojenia tohto systému so svojím. Ich hlavnou snahou je import vytvorených otázok do Moodle, kde by sa potom vytvárali testy. Niektoré funkcionality, ktoré Moodle poskytuje, však v nimi vytváranom systéme nebudú podporované.
V poslednej podkapitole sa zamerali na analýzu existujúcich testov, z ktorých by chceli umožniť získanie už vytvorených otázok. Možnosť takéhoto spôsobu získavania otázok názorne a pochopiteľne vysvetľuje popísaný príklad, ktorí v tejto časti vhodne uviedli.
V sumáre je celá analýza spracovaná maximálne zrozumiteľne a pri jej študovaní čitateľ získa potrebný prehľad o problémovej oblasti.
Špecifikácia požiadaviek a analýza systému
Táto kapitola je venovaná špecifikácií jednotlivých požiadaviek na vytváraný systém. Tie sú rozdelené do troch základných kategórií podľa stupňa priority. Oceňujeme toto rozdelenie požiadaviek, pretože je zrejmé, ktoré z nich sú kľúčové a na ktoré sa je nutné zamerať v prvom rade. Otázne však zostáva, prečo je otázka bezpečnosti riešená len so strednou prioritou (v súčasnosti je otázka bezpečnosti pri väčšine projektov riešená s najvyššou prioritou). Po podrobnejšom preštudovaní tejto kapitoly sme zistili, že systém bude vyvíjaný iba ako standalone aplikácia pre jedného používateľa, preto požiadavku bezpečnosti nie je potrebné riešiť na najvyššej úrovni. Tento fakt mohli autori uviesť explicitne, pretože na prvý pohľad to nemusí byť úplne jasné. Uvedené požiadavky na funkcionalitu systému mohli byť aspoň stručne popísané. Názov pri väčšine z nich hovorí aj o samotnej požiadavke, no pri niektorých nie je jasný ich význam (napr.: najvyššia priorita - zvýraznenie syntaxe).
V špecifikácii sa vyskytuje zopár nezrovnalostí, ktoré pre nás zostali po prečítaní nevysvetlené, napr. pri UC 1 Vytvor kategóriu, kategóriu bude možné vytvoriť iba v inej kategórii, ktorá už existuje, ale čo ak sa kategória nebude dať zaradiť do žiadnej z existujúcich? Nemala by byť podľa správnosti možnosť pridať kategóriu, ktorá sa nepridá do niektorej z kategórií? Ďalej sa v opise prípadov použitia nevyskytli obsahovo nejaké závažné chyby, pokiaľ majú autori dostatočne vyriešenú otázku týkajúcu sa zdvojenia dát. Odporúčame im, aby si do budúcna dávali pozor na rovnaké pomenovanie požiadaviek v diagramoch a v ich opise.
Dovoľujeme si tvrdiť, že sa v tejto časti asi najviac prejavila sila
celého tímu vytvárajúceho daný systém. Nezainteresovaný čitateľ získa jasnú
predstavu o tom, ako by mal systém fungovať, a to aj vďaka štýlu
písania, ktorý autori používajú. Celá špecifikácia je relevantná, všetky
uvedené informácie spĺňajú určitý význam, zbytočne neuvádzajú nepodstatné
údaje. Názornosť celej dokumentácie zvyšuje aj použitie rôznych diagramov,
ktoré sú dostatočne popísané.
Návrh systému
Na začiatku tejto kapitoly (4.1 Výber technológií) sa autori venujú analýze technológií, ktorých použitie zvažujú. Vhodnejšie by bolo, keby bola táto časť uvedená v kapitole 2. Analýza problémovej oblasti. Uvedená analýza je spravená podrobne a vyplýva z nej, ktoré technológie budú použité pri implementácií, avšak mohli by ju rozšíriť o analýzu Javy, Java Swing a Java DBC, ktoré uviedli v obrázku 4.1. Pri jednotlivých technológiách mohli pre úplnosť autori ešte uviesť aj hardvérové požiadavky a celú túto časť zhrnúť do akéhosi celkové zhodnotenia, zhrnutia vybraných technológií ako časť 4.1.9.
V dokumentácii sa niekoľkokrát vyskytuje slovo „Genex“, ale nikde autori bližšie neuvádzajú, že sa jedná o názov ich vytváraného systému, ktorý si preň zvolili.
V tejto kapitole oceňujeme návrh logického modelu a aj fyzického modelu, ktoré sú premyslené a dostatočne popísané. Na záver tejto kapitoly sú uvedené akceptačné testy.
Tím priradil ku svojej tímovej dokumentácii ešte aj informáciu o požitej literatúre. Pre jej značenie nepoužili čísla, ale skratky jednotlivých názvov diel. Do zoznamu by sme odporúčali kvôli úplnosti pridať odkaz týkajúci sa informácií ohľadom systému TestGen.
Projektové riadenie
Dokumentácia k riadeniu je rozdelená na 7 častí: Úvod, Ponuka, Úlohy, Organizácia projektu, Plán projektu, Záznamy zo stretnutí a Preberací protokol. O tomto rozdelení dokumentu sa dozvedáme opäť v akomsi prehľade nachádzajúcom sa v prvej časti.
Druhá časť je venovaná ponuke, ktorý tím č.5 vypracoval na začiatku zimného semestra a uchádzal sa o tému, ktorú nakoniec získali aj vďaka jej vysokému hodnoteniu 7 z 8. Ponuka je skutočne vypracovaná na vysokej úrovni, autori v nej uviedli svoj prvý hrubý návrh (predstavu o tom, ako chcú riešiť daný projekt).
Časť Úlohy má ako jediná
v projektovom riadení chybné číslovanie strán. Nachádza sa tu tabuľka, ktorá presne určuje,
ktorý člen tímu pracoval na danej časti dokumentácie. Je veľmi prehľadná, ale
má skôr informatívny charakter, nakoľko sa tímová dokumentácia poníma ako
inžinierske dielo, a teda ako spoločný výtvor celého tímu (bez uvedenia
kto ktorú časť robil).
Organizácia projektu je rozdelená na kapitoly Riadenie projektu a Štábnu kultúru, ktorá je veľmi zaujímavým a dobrým podnetom, ktorá sa v našej riadiacej dokumentácii nenachádza.
Plán projektu je stručne a výstižne spracovaný.
V záznamoch zo stretnutí sa nachádza šablóna a jednotlivé zápisnice z doteraz piatich stretnutí tímu vytvorených podľa nej. V tabuľkách obsahujúcich úlohy z predošlého stretnutia by sa zišla okrem uvedenia stavu úlohy „splnená“ aj informácia kedy bola splnená (dátum).
Posledná časť predstavuje dva typy šablón preberacieho protokolu. Oba sú prehľadne urobené s potrebnými formalitami. Prvý sa týka preberania diela vedúcim práce a druhý by mal slúžiť tímu č.5 ako potvrdenie, že sme ich prácu prebrali, ale nakoľko je zle formulovaný, je nutné ho opraviť.
Reprezentácia tímu na webovej stránke
Autori webovej stránky používajú tabuľky na rozloženie textu a iného obsahu na stránke, čo môže viesť k neprehľadnosti zdrojového kódu a niektoré prehliadače so zákazom vnorených tabuliek nemusia zobraziť obsah ich webovej stránky správne.
Menu je riešené neprehľadne a dosť nevýrazne, je potrebné sa preklikávať zakaždým na úvodnú stránku, aby návštevník mohol prehliadať ďalšie časti web stránky. V jednotlivých podkategóriách, keď užívateľ klikne na niektorú z možností, zobrazí sa odkaz Domov, čo je v podstate odkaz Späť, ktorý sa taktiež nachádza v tomto menu danej podkategórie. V menu sa nachádza položka Kontakt a po kliknutí zobrazená stránka obsahuje názov Kontakt a linky. V novinkách sa nachádzajú podnadpisy Pridané dokumenty/zápisnica a zvlášť nadpis aktualizácia stránky. V konečnom dôsledku je aj pridanie akéhokoľvek dokumentu na stránku samotná aktualizácia danej stránky.
Vypracované dokumenty obsahujú len odkazy na stiahnutie a nespĺňajú tak požiadavku prof. Bielikovej na priamu čitateľnosť (neobsahujú dokumenty vo formáte HTML alebo ASCII).
Tím č.5 však chválime za to, že stránka sa zobrazuje v rôznych prehliadačoch rovnako, obsahuje relevantné texty a až na absenciu priamej čitateľnosti dokumentov, obsahuje všetky požadované dokumenty.
FORMÁLNA STRÁNKA
Rozsah tohto dokumentu zodpovedá štádiu riešenia, v ktorom sa projekt momentálne nachádza. Jeho členenie je na vysokej úrovni až na zlé použitie číslovania strán v tímovej dokumentácii. Nedostatok dokumentu spočíva aj v chýbajúcich odvolávkach na niektoré obrázky (3.2, 3.4, 3.7), no pri použití väčšieho počtu obrázkov je tento počet minimálny. Po formálnej stránke by bolo lepšie, keby sa obrázky a tabuľky nachádzali čo najbližšie pri texte, v ktorom sa prvý raz spomínajú, aby sme ich nemuseli v dokumente stále hľadať až na ďalších stranách.
Z gramatického a štylistického hľadiska je dokument na priemernej úrovni. Pri jeho čítaní sme mali občas pocit, akoby sa jeho autori snažili šetriť slovami na úkor štylistickej kvality (málo súvetí, jednoduché, strohé vety, často začínajúce spojkami). Z gramatického hľadiska dokument obsahuje niekoľko preklepov (napr. časť 4.1.3 Groovy – Java Virtual Mashine, správne by malo byť Java Virtual Machine) a veľa gramatických chýb pri používaní inštrumentálu množného aj jednotného čísla. Taktiež by sme chceli upozorniť autorov na používanie čiarok vo vetách (buď prebývali alebo chýbali).
Z uvedeného je zrejmé, že sa autori zamerali hlavne na obsahovú stránku dokumentu, ktorá je na veľmi dobrej úrovni a z uvedených formálnych nedostatkov by sa mali do budúcna poučiť.
ZHODNOTENIE
Z vyššie posudzovaných častí vyplýva, že po obsahovej stránke je kvalita dokumentu vysoká a prevažuje nad hodnotením formálnej stránky, ktorej nedostatky kazia celkový dojem z vypracovaného dokumentu. Obsahovú stránku považujeme v tomto prípade za oveľa dôležitejšiu a celkovo hodnotíme prácu tímu č.5 ako výbornú (stupeň hodnotenia 7 z 8).