Vedúci projektu: Doc. Ing. Jana Minárová, CSc. 17. 11. 1999

Posudzovaný tím: Tím č. 2, ktorý predstavujú, menovite:

Bc. Marek Greško

Bc. Ondrej Habala

Bc. Aleš Procházka

Bc. Branislav Šimo

Predkladaná dokumentácia sa skladá (okrem úvodu) z troch hlavných kapitol

• Analýza,
• Špecifikácia požiadaviek a
• Hrubý návrh

a štyroch príloh

• Slovník pojmov,
• Ponuka,
• Plán projektu a
• Zápisy zo stretnutí.

Poznámky k titulnej strane:

1. Na titulnej strane dokumentu nie je uvedené meno vedúceho projektu (zadávateľ) ako aj dátum riešenia projektu (napr. 1999/2000).
2. Uvedený názov projektu „C-inšpektor“ je veľmi nápaditý, ale skutočný názov projektu (ako bol zadaný) je „Počítačová podpora hodnotenia programov v C-jazyku“.

Úprava dokumentácie ku projektu je na kvalitnej úrovni. Neobsahuje prakticky žiadne gramatické chyby, je kvalitne vytlačená a zviazaná. Kvôli zvýšeniu čitateľnosti dokumentu odporúčame tímu č. 2 zväčšiť písmo na veľkosť 12 a na začiatku odstavcov používať tabulátor.

Za jeden z najväčších problémov formálnej stránky považujeme schémy diagramov tokov údajov. Tieto schémy vyvolávajú dojem chaosu a neprehľadnosti, lebo sa v nich nenachádzajú názvy dátových tokov. Tie sú len očíslované a pod diagramom sú k číslam pridelené názvy. Takýto spôsob ich pomenovania zhoršuje čitateľnosť diagramov. Diagram tokov údajov 1. úrovne je pritom veľmi malý vzhľadom ku svojej zložitosti – ak ho nebolo možné zväčšiť kvôli šírke strany, mohol sa uviesť až na konci dokumentácie v niektorej prílohe v patričnej veľkosti. Príliš veľký počet dátových úložísk vytvára neprehľadnú schému – tím č. 2 vytvoril pre každú údajovú entitu systému osobitné úložisko údajov a to už na prvej úrovni DFD.

V kontexte systému nie je uvedený popis externých entít, je tam len odkaz na kapitolu návrhu. Myslíme si, že uvedenie názvov entít priamo pri diagrame by zvýšilo čitateľnosť a prehľadnosť a popisy nie sú až také rozsiahle, aby ich pod diagramom nebolo možné uviesť. Podľa nášho názoru odkaz zo špecifikácie a analýzy do návrhu nie je korektný, pretože špecifikácia je písaná aj pre zákazníka a ten nemá k dispozícii návrh (ani ho nechce čítať), ktorý je písaný pre vývojových pracovníkov.

Odsek 2.4.7. je písaný v prvom rode jednotného čísla. Tvorcom dokumentu je pritom tím, a preto je podľa nášho názoru takáto formulácia nevyhovujúca.

Štylistická stránka dokumentácie je veľmi dobrá, nevhodné formulácie sa vyskytujú len na niekoľkých miestach, napr. Hypoteticky sa môže stať... (Znamená to, že nehypoteticky sa to nemôže stať? ; Buď sa to môže stať, alebo nie.)

V časti 4.4 nie je očíslovaný a pomenovaný proces. V uvedenom diagrame tokov údajov by sa jednotlivé toky nemali krížiť (pokiaľ je to možné). Uvedomujeme si, že model systému je dosť zložitý, ale vhodnejšie by bolo zmeniť umiestnenie jednotlivých entít, alebo použiť duplikáty externých entít.

V DFD (4.5.2) by sa po premiestnení úložiska Študenti nemusel tok číslo 7 krížiť s ostatnými tokmi údajov.

V časti 4.10 možno vytýkať znovu estetickú úpravu DFD a pomenovanie dekomponovaného procesu nie je v súlade s pomenovaním procesu v DFD na vyššej úrovni.

Slovo užívateľ je po česky (takýto výraz existuje síce aj v Slovenčine, ale znamená niečo iné). Po slovensky by to malo byť používateľ. Táto zámena sa vyskytuje na viacerých miestach.

Veľmi prehľadne sú vypracované záznamy zo stretnutí tímu, kde je veľmi prakticky vyčlenená prezencia prítomných do hlavičky zápisnice. Záznamy sú veľmi kvalitné a obsahujú všetky potrebné informácie.

Úvod upresňuje obsah a účel dokumentu. Kladne hodnotíme uvedenie rozdelenia úloh na jednotlivých členov tímu. Na tomto mieste sme si však nemohli nevšimnúť, že v rozdelení úloh chýba pridelenie analýzy programátorského štýlu. V návrhu tím síce vysvetľuje, že kvôli nedostatku času sa táto časť systému nachádza ešte len vo fáze analýzy, avšak v čase rozdelenia úloh ešte nebolo možné presne vedieť, koľko času to bude trvať. Okrem toho nám nie je jasné, že keď sa problém nachádza v etape analýzy, kto túto analýzu robí, keď nikomu nebola úloha pridelená. V odseku 2.7. sa uvažuje o probléme, ale nie je to analýza, ale zoznam činností, ktoré program nebude robiť a zoznam dôvodov, pre ktoré ich nebude robiť. Z celého odseku 2.7. vyplýva len to, že podsystém analýzy programovacieho štýlu bude sledovať len úpravu textu, ale čo to znamená (t.j. chartakteristiky dobrej úpravy tu už uvedené nie je). Domnievame sa, že tím č. 2 na danej úlohe vôbec nepracuje a to napriek tomu, že táto úloha je tiež súčasťou zadania projektu, ktoré je všeobecne záväzné pre všetky tímy.

Štruktúru dokumentu považujeme za nevhodnú. Na jednej strane síce nie je nevyhnutné dodržiavať dokumentovú šablónu, tím č. 2 by sa však takto mohol vyhnúť problémom zlého rozdelenia obsahu dokumentácie do nevhodných celkov a taktiež by členovia tímu postrehli, že im chýbajú niektoré dôležité časti dokumentácie ako je napríklad Špecifikácia správania systému.

Kapitola 2 s názvom Analýza je zmesou aj takých údajov, ktoré by mali patriť sčasti do špecifikácie a sčasti do návrhu. Samotný názov kapitoly nič nehovorí – nie je jasné, či ide o analýzu súčasného stavu, analýzu problému, analýzu požiadaviek, alebo analýzu alternatív. V úvode je uvedené, že je to analýza problému, avšak po prečítaní kapitoly nemôžeme s týmto pomenovaním súhlasiť. Pod touto kapitolou je totiž skryté všetko, čo aspoň trochu súvisí s analýzou „ľubovolného druhu“ – obsahuje aj analýzu spôsobu riešenia, čo je podľa našich poznatkov jednoducho návrh. Keďže je kapitola uvedená ešte pred špecifikáciou, okrem požiadaviek a súčasného stavu niet čo analyzovať, pretože požiadavky ešte nie sú vyšpecifikované. Analýzu súčasného stavu však tím č. 2 odbavil vetou: „V dostupnej literatúre a na sieti Internet sme bohužiaľ nenašli obdobný projekt, takže sa nám veľmi ťažko tvoria úvahy o súčasnom stave.“ Myslíme si, že autor tejto vety nepochopil, že analýza súčasného stavu sa týka stavu na fakulte a spôsobu odovzdávania a hodnotenia zadaní v súčasnosti a nie súčasného stavu na Internete. Tím síce napriek tomu vypracoval analýzu súčasného stavu, ale je zle zaradená do štruktúry dokumentu a nenesie názov Analýza súčasného stavu.

Myslíme si, že odseky 2.2.1. a 2.2.2. by mali patriť do hrubého návrhu. Tím uviedol výraz „vyhovuje našim požiadavkám“. Tím by mal vytvárať špecifikáciu na základe požiadaviek fakulty, zadávateľa a cvičiacich. V ďalšom by mali vytvoriť produkt, ktorý spĺňa ich vlastnú špecifikáciu, ale nie ich vlastné požiadavky.

V odseku 2.4. Príprava údajov pre rozoznávanie podobnosti sa uvádza: „Rozhodli sme sa zisťovať histogramy jednotlivých charakteristických čŕt zdrojového textu." V ďalšom sú vymenované charakteristické črty a je uvedený popis spôsobu sledovania týchto čŕt (úroveň tohto popisu si vyžaduje zaradiť odsek do návrhu). Avšak nie je jasné, načo slúži sledovanie histogramov. Nikde v dokumentácii nie je spomenuté, čo sa s histogramom stane a čo program urobí, keď má hotové histogramy. Na tento účel by mohla slúžiť Špecifikácia správania systému, kde by sa uviedli akcie vykonané po získaní histogramov, takúto kapitolu však dokumentácia neobsahuje.

V odseku 2.4.7. sa v súvislosti s programami lexikálnej a syntaktickej analýzy uvádza: „Ak sa ukáže, že vygenerované programy sú nepoužiteľné, budem musieť oba analyzátory navrhnúť a naprogramovať svojpomocne.“. Túto vetu možno považovať za analýzu rizika. Z predmetu Architektúra softvérových systémov vieme, že za identifikáciou každého rizika musí nasledovať jeho riešenie, alebo návrh na jeho zjemnenie. V celej dokumentácii sme pritom podobné riešenie nenašli a preto nám nie je jasné, kedy chce tím zistiť, či sú programy použiteľné a aké opatrenia urobil, aby sa stihol splniť projektový plán. V prípade, že tím bude pokračovať podľa svojho pôvodného projektového plánu, zistenie vhodnosti týchto programov odhadujeme na polovicu letného semestra. V takomto prípade však nemôže tím č. 2 stihnúť urobiť novú špecifikáciu, návrh, implementáciu a testovanie daného podsystému.

Pri hodnotení kapitoly Špecifikácia požiadaviek budeme vychádzať z faktu, že kapitola je zle pomenovaná a v skutočnosti ide o všeobecnú špecifikáciu celého systému a nielen o špecifikáciu požiadaviek na tento systém – vyplýva to z obsahu danej kapitoly.

Jedným zo závažných problémov špecifikácie je, že sa začína popisom jednotlivých podsystémov a pritom diagram modelu údajov prvej úrovne, ktorý popisuje architektúru a rozdeľuje systém na subsystémy je uvedený až v návrhu. Ako mohol tím č. 2 rozdeliť program na subsystémy, keď ešte nebola známa jeho architektúra? Myšlienka zaradiť diagramy tokov údajov do návrhu a žiaden z nich nezaradiť do špecifikácie je v rozpore so všetkými známymi metódami analýzy a návrhu. Ak si architektúra systému vyžaduje uviesť diagramy tokov údajov aj v návrhu, je to samozrejme možné, ale je neprípustné vynechať všetky diagramy zo špecifikácie.

Špecifikácia neuvažuje s podsystémom kontroly programátorského štýlu, pritom tento podsystém je neskôr zahrnutý do architektúry systému v návrhu. V prípade správneho postupu vývoja by mal návrh vyplývať zo špecifikácie.

Odsek 3.4.1. Vstupy a výstupy obsahuje vetu: „Ak má program viac súborov, predpokladá sa, že súbory budú spojené do jedného.“ Z tejto vety nie je jasné, kto a kde bude toto spájanie robiť. V prípade, že chcú autori uviesť spôsob spájania až v návrhu, môžu to urobiť (podrobný návrh bude ešte len vytváraný), ale to, či spájanie súborov bude robiť niektorý subsystém a či to vôbec bude robiť program, alebo to musí urobiť používateľ (nebolo by to síce rozumné) treba popísať v špecifikácii. Fráza „predpokladá sa“ nie je postačujúca.

3.5. Rozoznávanie podobnosti programov: „Vzhľadom na nedostatok informácií o možnostiach riešenia tohto problému, keďže tento problém pravdepodobne nemá uspokojivé deterministické riešenie, bude zrejme vhodné zvoliť vzor štruktúry architektúry podsystému s tabuľovou organizáciou.“ Prečo? Popísané dôvody nevedú k tabuľkovej organizácii. Tabuľkovú organizáciu zdôvodňuje vo všeobecnosti veľký počet údajov zdieľaný viacerými podsystémami. Ťažisko tohto podsystému však nevidíme vo veľkom počte zdieľaných údajov, ale v požiadavke na kvalitné algoritmy schopné spolupracovať na riešení úlohy bez deterministických požiadaviek.

V ďalšom členení časti 3.5. sa uvádza, že podsystém porovnáva dve zadania ktoré sú vstupom tohto subsystému. To by však znamenalo, že musí existovať ďalší subsystém, ktorý postupne vyberá dve a dve zadania z úložiska zadaní. Takýto podsystém však neexistuje. Okrem toho sme si všimli, že autor tohto odseku stotožňuje pojmy podsystém a modul, čo nie je to isté. V obmedzeniach sa uvádza: „Podsystém by mal rozoznávať podobné zdrojové texty programov na 80%“. Podľa našich odhadov je táto hodnota príliš pesimistická – je to však len náš subjektívny názor.

3.7. Kontrola funkčnosti - tu uvedený popis nemožno považovať za špecifikáciu, nakoľko určuje ako sa bude funkčnosť kontrolovať. Odporúčame túto časť zaradiť do návrhu a do špecifikácie prevziať časť z analýzy.

3.8. Rozhranie pre používateľov - Informácia, že rozhranie bude oknová aplikácia je v špecifikácii nadbytočná. Tu by mal byť skôr popis údajov, ktoré môže používateľ zadať a ktoré si môže prečítať. Chýba nám definícia používateľa – pravdepodobne sa jedná o cvičiaceho, ale nebolo to špecifikované.

4.2. Členenie systému – systém je rozdelený na tri hlavné časti, avšak nepokrývajú celú architektúru. Napríklad proces zadávania definícií zadaní nemožno začleniť do žiadneho z troch uvedených častí. Je potrebné toto členenie doplniť o ďalšie zložky.

4.3.2. V tejto časti z popisu vyplýva, že učiteľ má širšie možnosti ako študent, ale má aj všetky jeho právomoci. Môže teda aj učiteľ odovzdávať zadania? Podľa nášho názoru treba definovať používateľa učiteľ úplne osobitne a nenadväzovať pri jeho definícii na definíciu používateľa študent.

4.4. V diagrame tokov údajov je naznačené, že učiteľ môže zmeniť hodnotenie študenta zásahom do výsledkov. Skôr než to urobí, by však mal mať možnosť vidieť odovzdané zadanie študenta – ako by ho inak mohol zhodnotiť. Dátový tok, ktorý by sprístupňoval učiteľovi zadanie sa však v diagrame nenachádza.

4.5.2. Popisy elementárnych procesov popisujú procesy s mierne odlišnými názvami ako je to v DFD 2. úrovne. Prítomnosť riadiacich procesov v diagrame tokov údajov považujeme za nevhodné. Ak vznikla nutnosť uvažovania takýchto procesov, mal sa vytvoriť diagram tokov riadenia (CFD) 2. úrovne.

4.6. a 4.7. Príprava údajov pre rozoznávanie podobnosti obsahuje Rozoznávanie podobnosti zdrojových textov programov. Z funkčného hľadiska je toto členenie v poriadku, ale podľa týchto pomenovaní sa zdá, že je to nezmysel. Odporúčame tieto časti dokumentácie premenovať.

4.7.2.1. Názvy procesov nesúhlasia s diagramom 4.7.2.

4.8. Centrálny manažment úložísk údajov – Táto časť návrhu sa mala vyskytnúť skôr. Popisy entít, ktoré obsahuje sa vyžadovali už v predchádzajúcich kapitolách. Model údajov by však mal byť uvedený ešte pred samotným popisom entít.

Ďalej nás prekvapil vzťah m:n medzi učiteľom a študentom. O takomto vzťahu sa nikde v dokumentácii neuvažuje. Ak jeden študent môže mať pridelených viacero učiteľov, treba v systéme riešiť aj problém, že hodnotenie ktorého učiteľa platí a ak chce učiteľ zmeniť výsledok zadania (jeho bodové hodnotenie), treba mu oznámiť ktorý učitelia už toto hodnotenie modifikovali. S riešením tohto a podobných problémov sme sa však v dokumentácii nestretli a ani model údajov neuvažuje o možnosti uchovávania takýchto informácií.

4.9. Kontrola programátorského štýlu. Tím zdôvodnil neprítomnosť tejto časti návrhu nedostatkom času a dohodou s pedagogickým vedúcim projektu. Nazdávame sa však, že ak tím nemal dostatok času, mal navrhnúť všetky subsystémy s menším stupňom podrobnosti.

4.10. Kontrola funkčnosti. Subsystém je navrhnutý vcelku dobre, jedinou výčitkou môže byť predčasné určenie štruktúry dátových tokov – napr. „príznak úspešnosti..." – tu stačilo uviesť, že ide o úspešnosť, informácia, že pôjde o logickú premennú je predčasne zadefinovaná. Toto však nie je závažný problém.

V dokumente nie sú špecifikované priority jednotlivých funkcií systému, resp. je uvedené autonómne použitie funkcií kontroly zadaní. Domnievame sa, že to nie je správne, pretože je zbytočné aplikovať kontrolu programátorského štýlu, ak je program zadania nepreložiteľný. Študent môže poslať ako súčasť zadania (zhodou okolností s príponou „c") napr. vtipy a v tom prípade nie je kontrola programátorského štýlu opodstatnená.

Takúto kapitolu dokumentácia neobsahuje. Pritom je nevyhnutná na určenie toho, čo systém v skutočnosti robí. Diagramy tokov údajov určujú len to, aké dielčie úlohy vykonávajú jednotlivé subsystémy a moduly. To v akom poradí sa aktivujú, čo spôsobuje ich spustenie, kedy čítajú ktoré vstupy a kedy zapisujú ktoré výstupy nebolo nikde určené. Určité zlomky týchto informácií sú roztrúsené po rozličných častiach dokumentácie a s troškou fantázie si ich môže čitateľ doplniť a domyslieť, ale očakávať niečo takéto od čitateľa dokumentácie nesvedčí o inžinierskom prístupe k jej tvorbe.

Problém je o to závažnejší, že celý program nie je informačným systémom, kde 90% riadiacej funkcie plní používateľ systému. Úlohu popisu správania systému by mohli plniť scenáre spracovania, diagramy tokov riadenia (CFD), vývojové diagramy, alebo aj jednoduchý popis neformálnym textom.

Neprítomnosť špecifikácie správania systému považujeme za veľmi vážny nedostatok posudzovanej dokumentácie.

Z dokumentácie nie je jasné, čo bude výsledkom prototypu systému. Či to bude používateľské prostredie, alebo budú implementované aj ďalšie funkcie a pod.