Slovenská technická univerzita v Bratislave
Fakulta informatiky a informačných technológií
Ilkovičova 3, 842 16 Bratislava 4
Informačný systém pre komunikáciu s absolventmi
Posudok na dokument Systém na evidenciu
a prezentáciu absolventov
Tento dokument je posudkom tímu č.18 na dokumentáciu odovzdanú tímom číslo 15. Tím číslo 15 má, rovnako ako náš tím, pridelený projekt „Systém na evidenciu a prezentáciu absolventov“. Základ dokumentácie bol stanovený už minulý rok predchádzajúcim tímom.
Posudok je členený na základe dokumentu, ktorý nám bol odovzdaný.
Tento posudok hodnotí všeobecne označenú dokumentáciu Systém na evidenciu a prezentáciu absolventov bez podrobnejšieho stanovenia verzie dokumentu, ktorý bol odovzdaný, a bez určenia dňa zostavenia dokumentácie.
Posudzovaná práca sa zaoberá analýzou, špecifikáciou a návrhom riešenia pre informačný systém, umožňujúci komunikáciu s absolventami. Hlavnými cieľmi vytváraného informačného systému má byť možnosť informovať verejnosť o absolventoch fakulty a umožniť vzájomnú komunikáciu medzi fakultou a absolventami. Cieľom posudku je zhodnotiť klady a poukázať na nedostatky daného dokumentu z formálnej a obsahovej stránky.
V tejto kapitole sa budeme venovať jednotlivým častiam dokumentácie konkurenčného tímu. Uvedieme niektoré nedostatky, na ktoré sme pri kontrole dokumentu narazili a navrhneme ich odstránenie.
2.1.
Formálna stránka dokumentácie
Niekoľko formálnych výhrad máme voči titulnej strane, na ktorej chýba podrobnejšie označenie dokumentácie, a dátum jej vytvorenia. Žiaľ, ani v ďalšom texte sa informácia o verzii dokumentácie nenachádza. Vhodné by bolo uviesť aspoň jeden kontaktný údaj na tím.
Dokument je prehľadne štruktúrovaný, tím dodržal predpísané členenie na časť analýzy, špecifikácie a návrhu. Vizuálne členenie textu je dostatočne prehľadné, jednotlivé kapitoly sú uvádzané nadpismi, dôležité informácie v texte sú zvýraznené, pod každým obrázkom sa nachádza jeho popis, spolu s číslom obrázku.
Obrázok, na ktorý sa tím odkazuje na strane 20 je uvedený pod nesprávnym číslom, obrázku na strane 27 chýba popis, za nedostatok považujeme absenciu prehľadného zoznamu použitých obrázkov.
Po gramatickej a štylistickej stránke sa dokument vyznačuje výraznými nedostatkami. Najčastejšou gramatickou chybou je absencia čiarok na miestach, kde sa použitie čiarky vyžaduje. Naopak čiarky sú použité aj na miestach, kde nepatria. Aj keď sa môže niekomu zdať táto chyba ako nepodstatná, nesprávne dodržanie oddeľovania viet môže viesť až k zmene významu celého bloku textu.
Pretože však ide o študentskú prácu, hodnotíme túto časť mierne. Dôraznejšie budeme hodnotiť obsahovú stránku jednotlivých častí dokumentácie.
Zo štylistického hľadiska je častým problémom použitie nevhodných slov a nesprávneho slovosledu, vetné konštrukcie sa tým stávajú neprehľadnými a ťažšie pochopiteľnými. Netreba sa báť spájať vety do súvetí, používať synonymá a využívať všetky možnosti písomného prejavu, ktoré slovenský jazyk poskytuje. Práca pôsobí často dojmom, akoby bola písaná “o päť minút dvanásť” a na jej kontrolu alebo prípadné prepracovanie, už nezostal čas.
Do budúcnosti by sme preto odporučili venovať viacej pozornosti kvalite vypracovania, ktorá môže, aj napriek tomu, že dokument je po obsahovej stránke spracovaný kvalitne, znížiť celkové hodnotenie.
2.2.
Úvod
V tejto časti tím uvádza zadanie projektu, cieľ vypracovania projektu a zoznam použitých skratiek. Kapitola 1.1 - Cieľ neuvádza žiadne informácie o cieľoch systému. Skôr bola využitá na predstavenie prostredia a problémovej oblasti. V časti “Zoznam použitých skratiek“ uvádza tím vysvetlenie pojmov - systém, škola, absolvent a študent, patriacich do časti “Vysvetlenie použitých pojmov“, ktorá v dokumente chýba.
Keďže je možné túto časť dokumentácie neskôr zmeniť, považujeme tieto nedostatky za dočasné a odporúčame ich pri najbližšej príležitosti upraviť.
2.3.
Analýza
V časti “Analýza“ sa tím zaoberá analýzou prostredia, v ktorom bude systém tvorený a analýzou účelov, na ktoré bude vytváraný systém slúžiť.
Pre vývoj systému sa tím rozhodol použiť technológiu PHP
namiesto technológie Java, v ktorej bol systém vyvíjaný minuloročným
tímom. V tabuľke, ktorá nemá označenie a nachádza sa na strane
5, tím uvádza klady a zápory, ktoré ovplyvnili ich výber. V časti
týkajúcej sa technológie Java sú však uvedené dôvody, ktoré v analýze
uviedol minuloročný tím. Dosť zvláštne preto pôsobí zistenie, ktoré hovorí o tom, že aj napriek
nedostatku skúseností členov tímu s technológiou Java a ochote naučiť
sa v Java programovať, bude nakoniec pri implementácií informačného
systému použitá technológia PHP.
Časť “Fakty, ktoré by preferovali zmenu technológie na PHP“ (strana 6) by sme taktiež uviedli ako protiklady k tvrdeniam vyzdvihujúcim pozitívne stránky technológie Java, namiesto tých, ktoré boli uvedené minuloročným tímom.
Nasleduje časť “Podporné knižnice (frameworks) pre jazyk PHP“ (kapitola 2.1.2). Táto časť je pomerne dobre spracovaná. Tím uvádza v súčasnosti najpoužívanejšie frameworky na vývoj webových aplikácií a porovnáva ich pozitívne a negatívne stránky.
V časti “Využitie CMS v projekte“ (kapitola 2.1.3) tím analyzuje možnosti použitia CMS systémov pri implementácií, ktoré môžu výrazne uľahčiť používateľom spravovanie obsahu webových stránok. Sú uvedené výhody a nevýhody použitia týchto systémov, spolu s vymenovaním v súčasnosti tých najpoužívanejších. Tak ako predchádzajúca časť je i táto časť dobre spracovaná, avšak rovnako ako v predchádzajúcej časti chýba konečné zhodnotenie, či a ktorý CMS systém bude vo fáze implementácie použitý.
V analýze častí systému - časť „Nástenka“ (kapitola 2.3.1) nerozumieme významu viet:
„Ľudia spravujúci nástenku môžu byť rozdelení do viacero skupín, alebo môže nástenku spravovať len jedna jediná osoba. Na nástenke s neobmedzeným prístupom môžu zverejňovať oznamy ľubovoľné osoby.“ - konkrétne ak existuje skupina ľudia spravujúci nástenku, prečo sa rozdeľujú na správu nástenky do ďalších skupín, prípadne prečo spravuje nástenku iba jedna osoba. Ďalej je uvedené, že na nástenku s neobmedzeným prístupom môžu umiestňovať oznamy ľubovoľné osoby - to by nemalo platiť o neregistrovaných používateľoch systému, ako je to aj znázornené v prípadoch použitia na obrázku 3-1.
Kapitola 2.3.2 zaoberajúca sa analýzou komunikácie medzi používateľmi je spracovaná na vysokej úrovni. Autori však oddelili analýzu komunikácie medzi absolventami a analýzu samotného fóra. Toto riešenie nie je veľmi dobré, pretože je opísaná rovnaká časť systému v dvoch častiach dokumentu. Ideálnym riešením by bolo tieto podkapitoly spojiť a vyhnúť sa duplicite informácií. Autori sa ďalej rozhodli implementovať vlastné fórum. Toto rozhodnutie je z pohľadu analýzy správne.
V kapitole 2.3.3 sú spomenuté pojmy kapacita a kategória. Tieto pojmy by bolo vhodné v texte, alebo v slovníku vysvetliť (napríklad: ktoré typy akcií chcú kapacitne obmedzovať a ako pri tom budú postupovať).
Výroky ako „Keďže použité fórum má byť prepojené z modulom nástenky“ (v kapitole 2.3.5) by bolo vhodné podporiť zobrazením v dátovom modeli, ktorý sa v dokumentácii nenachádza.
2.4.
Špecifikácia systému
Autori veľmi dobre opísali jednotlivých hráčov v systéme. Avšak textový opis prípadu použitia nie je až taký vhodný ako opis s použitím tabuľky z dôvodu lepšej prehľadnosti pri použití tabuľky. V opise hráčov je napísané, že hráč Alumnus môže robiť to isté ako akýkoľvek používateľ. Nikde sa však neuvádza, čo môže robiť „akýkoľvek používateľ“.
V kapitole 3.2.1 na obrázku 3-1 je nesprávne znázornené dedenie (prejavuje sa to aj na ďalších obrázkoch uvedených v tejto kapitole) jednotlivých používateľov systému, ktoré má byť v schéme znázornené opačne. Rovnako prípady použitia filtruj oznamy a vyhľadaj oznamy majú mať vzťah k zobrazeniu oznamov <<include>> a nie <<extends>>. Podrobné potvrdzovanie všetkých akcií správcom nástenky sa nám zdá dosť zložité a vyžaduje časté návštevy nástenky správcom. Napríklad prípad, ak si chce alumnus zrušiť vlastný oznam, si podľa nášho uváženia nevyžaduje potvrdenie správcom, ale bolo by vhodné ho ešte v systéme určitý čas zobrazovať ako zrušený.
Bolo by vhodné podrobnejšie rozlíšiť prípady použitia zobraziť záznamy a filtrovať záznamy v entite Nástenka, nie je nám zrejmý rozdiel medzi týmito prípadmi.
V diagrame prípadov použitia časti komunikácia (obr.3-2, str.19) sa nachádza prípad použitia „Svoje skupiny“. Pravdepodobne sa jedná o chybu, pretože prípad použitia vyjadruje činnosť a nie časť systému.
Obrázok 3-6 týkajúci sa bezpečnosti systému znázorňuje, že používateľ môže vytvoriť účet používateľa, čo považujeme za formálnu chybu pri znázornení v názve používateľa. Pravdepodobne ide o administrátora, inak by to predstavovalo výrazné bezpečnostné riziko.
2.5.
Návrh systému
V časti Použitá technológia možno nájsť isté zdôvodnenie výberu implementačnej technológie. Táto časť sa viac hodí do analýzy ako doplnenie a zakončenie rozsiahlejšej kapitoly, ktorá sa témou implementačného prostredia zaoberala. Tvrdenie „implementácia v systéme PHP vie byť oveľa rýchlejšia“ (v kapitole 4.1) by bolo tiež vhodné doložiť nejakými údajmi. Pri schéme číslo 4-1 chýba nadpis, preto nevieme, čo tento obrázok vyjadruje.
Architektúra systému – v tejto časti sa nachádza popis modelu MVC a predstavenie Framework CakePhp. O architektúre navrhovaného systému však táto časť nehovorí nič, popisuje len technologické veci.
Hlavný layout stránok v kapitole 4.3.1 je pomerne dobre a rozsiahlo definovaný. Poskytuje používateľovi dostatočnú predstavu o možnostiach systému.[1]
V návrhu obrazoviek sa už však vyskytuje viacero chýb. Chýba možnosť rušenia oznamov, príspevkov a pod. Keďže sa v práci nenachádza podrobný diagram aktivít pre prípady použitia, bolo by vhodné uviesť jednotlivé možnosti aspoň pri návrhu obrazoviek.
Z dokuemtácie nebolo jasné, ako sa dá z hlavnej stránky napísať nová sprava. Táto možnosť je uvedená na obrázku 4-6, ale nie na obrázku 4-3.
Nasleduje znázornenie štruktúry obrazoviek rôznych častí systému.
Nedostatkom vyskytujúcim sa na všetkých ponúknutých schémach je používanie pojmu „kategória“, pre ktorý sa síce pri každej schéme nachádza stručné vysvetlenie, no zo zvyšku textu nie je zrejmé, kto tieto kategórie tvorí. Ide pritom o pomerne dôležitú časť systému, keďže je súčasťou väčšiny stránok.
Podľa 4-6 sa z hlavnej stránky dá dostať do zoznamu správ. Nie je však uvedené, či ide o správu z nástenky, informáciu z fóra, alebo správu o podujatí. O časti spravujúcej skupiny nie sú podrobnejšie informácie. Predpokladáme, že sú tým myslené kategórie používateľov, avšak chýba vysvetlenie a pravdepodobne prístup by mal byť iba pre správcu systému.
Pre absenciu dátového modelu nevieme posúdiť, či budú správy niekomu adresované. Môže byť adresát celý ročník, prípadne všetci?
Na obrázkoch kapitoly 4 nie je vhodne použité zobrazenie niektorých prvkov systému. Napríklad prihlásený používateľ, správca alebo alumnus (od obrázku 4-7) je definovaný ako entita, ktorá má vzťah k niektorej skupine funkcií systému. Takéto zoskupovanie UML notácia nedovoľuje. Ak bola použitá vlastná notácia, bolo by vhodné jej vysvetlenie uviesť v úvode dokumentácie.
Na obr. 4-8 Štruktúra obrazoviek časti podujatia sa spomína hráč Prihlásený užívateľ. Ide pravdepodobne o hráčov Alumnus a Správca systému, no v texte sa tento pojem nikde neuvádza.
Štruktúra obrazoviek časti fórum (obrázok 4-10) uvádza možnosť pridania témy priamo z hlavnej stránky. Nastáva tu otázka, do ktorej kategórie bude takýto príspevok zaradený.
Logický model údajov – obsahuje časti logického modelu údajov pre kalendár, nástenku a bezpečnosť. V diagrame 4-11 na strane 37 evokujú vzťahy medzi entitami Message a MessageState resp. MessageConfirmation dojem, že v systéme môže existovať oznam bez stavu resp. potvrdenia. Popísanie entít časti logického modelu údajov je presné a stručné, a plne postačuje pre účely hrubého návrhu systému.
Časť logický model údajov obsahuje prehľadné a v postačujúcej kvalite spracované časti logického modelu údajov a to časti nástenka, kalendár, bezpečnosť a ich prepojenia s ďalšími časťami systému.
Ďalšia časť logického modelu údajov sa zaoberá bezpečnosťou. Riešenie bezpečnosti aplikácie je vybrané vhodne. Výhrady máme len k tomu, že používateľ môže získať viacero skupín práv. Okrem toho sme nenašli možnosť nastavenia množiny práv užívateľom.
V kapitole 4.4 absentuje celkové znázornenie logického modelu, kde by boli znázornené všetky vzťahy medzi entitami.
3.
Celkové zhodnotenie posudku
Celkovo môžeme zhodnotiť dokumentáciu konkurenčného tímu pre účely návrhu systému v školskom prostredí ako vyhovujúcu. Formálnu stránku je možné v ďalších verziách dokumentácie postupne upraviť a v prípade obsahovej stránky sme, dúfam, podnietili tím k zmenám alebo prehodnoteniu niektorých častí, čo aj bolo naším cieľom.
Tento posudok bol spracovaný za účelom priblížiť konkurenčnému tímu niektoré postrehy a námety, ktoré sme počas kontroly dokumentácie zistili. Rovnako upozorniť na niektoré nedostatky, ktoré je možné v nasledujúcich verziách odstrániť.
Preto dúfame, že náš posudok pomôže konkurenčnému tímu upraviť konečnú dokumentáciu tak, aby bola z hľadiska používateľa čo najprehľadnejšia a poskytovala mu dostatok presných a zrozumiteľných informácií o systéme, ktorý navrhujú.
Dokumentáciu
kontrolovali všetci členovia tímu 18:
Michal Bubanský, Martin Stanček, Michal Samiec, Marián Vašš, Jozef Ďuriš, Jozef
Pažin
Jozef Pažin
dokumentarista tímu
23. novembra 2006