TERBR, F. Klient server aplikace pro tvorbu spisových stránek pro PČR [online]. Brno: Vysoké učení technické v Brně. Fakulta informačních technologií. 2023.
Student splnil všechny body zadání a aktivně konzultoval problematiku s PČR. Nasazení aplikace bylo implementováno pomoci umístění na server s veřejnou adresou, tak aby mohlo dojít k otestování, před případným schvalování za účelem získání atestace daného systémů pro možnost plného nasazení. Celkové dosažené výsledky a aktivitu studenta tak hodnotím za C.
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Informace k zadání | Složitost diplomové práce bych hodnotil jako průměrnou. Součástí práce je však hodně závislostí a různých částí, které se po dobu implementace lehce měnili z pohledu uživatele. V tomto případě se jedná od dvě nezávislé aplikace a to aplikaci serverovou, která si ukládá všechna data a uživatelskou, která umožňuje editaci daných záznamů. | ||
| Práce s literaturou | Student použil navrženou literaturu a dále aktivně sháněl další zdroje pro řešení dané problematiky. | ||
| Aktivita během řešení, konzultace, komunikace | Student po čas implementace komunikoval především se zástupci od PČR, na konzultace však chodil vždy řádně připraveny. Dále dodržoval všechny stanovené termíny. | ||
| Aktivita při dokončování | Práce byla odevzdána s předstihem pro kontrolu a případné doplnění. | ||
| Publikační činnost, ocenění |
Autor vytvořil desktopovou aplikaci s GUI pro tvorbu spisových stránek pro PČR. Zadání je čistě implementačního charakteru a požadavky na aplikaci jsou detailně specifikované. Technická zpráva až příliš odráží implementační charakter práce a uchyluje se spíše k převzatým obecným popisům technologií a pak k technické dokumentaci k API serveru. Autor prokázal vynikající realizační schopnosti. Výsledné dílo je rozsáhlé, propracované ve všech svých částech a postaveno na relevantních moderních technologiích. U diplomové práce bych ale očekával hlubší zaměření na nějakou konkrétní oblast IT, více koncepčního nadhledu a úvah o problémech a možnostech jejich řešení, argumentaci zvažovaných postupů a především více tvůrčího přístupu. Výslednou kvalitu kazí obsahová kvalita technické zprávy a absence jakéhokoliv testování řešení.
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Náročnost zadání | Zadání je implementačního charakteru a definuje velmi pečlivě požadavky na výslednou aplikaci. Tvůrčí prostor tak zůstává v oblasti návrhu GUI ve spolupráci s koncovým uživatelem a ve výběru vhodných technologií. Zadání ale explicitně nevyžaduje studium a získání znalostí metod a teorií. Tvůrčí prostor v práci s uživateli (na uživatele zaměřený návrh GUI), revize uživatelských procesů, iterativní testování GUI s uživateli atd. využit nebyl. | ||
| Rozsah splnění požadavků zadání | Technická zpráva neobsahuje dostatečné informace o řešení bodu 2. ohledně vytváření vlastní dokumentace s ohledem na definovanou kvalitu tisku. Práce naopak obsahuje rozšíření o automatické rozpoznání číselných karet v obraze, ke které využívá moderní detekční algoritmus YOLO. | ||
| Rozsah technické zprávy | Některé části technické zprávy jsou s ohledem na jiné části nepřiměřeně rozsáhlé (kap. 4.2 s popisem REST API serveru, nebo kap. 4.3, která obsahuje rozsáhlý popis kombinující technické informace s návodem na použití aplikace). Nejsou zřejmé důvody, proč se ER diagram navrženého datového modelu v kap. 3.5 (Obr. 3.4) liší od realizovaného v kap. 4.1 (Obr. 4.1). Obrázky 4.3, 4.4, 4.5 a 4.7 se zdají být spíše zbytečné. Na druhou stranu, řada kapitol obsahující popis použitých technologií by si zasloužila detailnější popis a zejména autorskou diskuzi dané problematiky reflektující konkrétní zadání (např. kap. 2.4). Odevzdané řešení obsahuje řadu dalších podstatných dokumentů, které jsou dobře a pečlivě zpracovány, ale textová zpráva se na ně odkazuje velmi nevhodně (odkaz na nějaké soubory pdf) a ani autor se při úvahách a návrhu o ně tyto informace příliš neopírá. Jedná se o detailní specifikace použití, sekvenční diagramy, přijímací testy apod. U těchto dokumentů ovšem není zřejmé, kdo je autorem, zda-li autor řešení této práce nebo PČR. | ||
| Prezentační úroveň technické zprávy | 60 | Text je psán stylem, kdy jsou převzaté znalosti i vlastní návrh často kombinovány ve jednotlivých podkapitolách. Autor se vyjadřuje srozumitelně a odborně. V textu je ale relativně málo pasáží, který by obsahoval nějakou odbornou polemiku. Text je totiž složen převážně z převzatých (přeložených) textů nebo z popisu implementace. Autor v textu nediskutuje o problémech a možnostech řešení, ale rovnou představuje jím vybrané technologie a postupy. To není a-priory špatně, ale když je namísto definice problému a možnostech jeho řešení představeno rovnou řešení, zdá se, že žádný problém vlastně není třeba řešit a zkoumat, ale stačí to pouze naprogramovat. Chybí koncepční nadhled, autorská diskuze a návrh řešení. Představení implementačních technologií (kap. 3.2) je nevhodně umístěno v kapitole Návrh, kde by čtenář očekával spíše tvůrčí diskuzi a návrhy řešení problémů týkajících se tvorby požadovaného systému. Technická zpráva není informačně příliš zajímavá, existující technologie jsou představeny bez diskuze jejich výběru, při popisu autor zůstává na povrchu a u obecných popisů. To pak někdy vede i k nepřesným definicím, jako např. v kap 2.12, kdy metoda HOG je prezentována jako detektor, ačkoliv se jedná o postup extrakce příznaků z obrazu, které jsou až následně (nějakou jinou klasifikační metodou) využity pro detekci objektů. Nebo v problematice návrhu GUI, které se nezaměřuje primárně na vzhled a dojem z prostředí , ale na reflexi uživatelských potřeb (co potřebuje pomocí počítače a SW udělat), definici uživ. procesů (které reflektují potřeby uživatele dostat se rychle a přehledně k cíli), návrh informační struktury (rozdělení procesu na části a rozmístění GUI prvků tak, aby reflektovaly proces a usnadnily orientaci v procesu) atd. Nebo v kap. 3.2, autor navrhuje databázi , i když by měl spíše hovořit o návrhu datového modelu s využitím ER diagramu. Obr. 2.5 obsahuje pravděpodobně chybu. | |
| Formální úprava technické zprávy | 70 | Typografická úroveň textové zprávy je dobrá, text ale obsahuje nemalé množství interpunkčních chyb. Text dále obsahuje řadu prohřešků, jako např. absence odkazů na obrázky v textu, reference na literaturu jsou často mimo text (tedy za odstavcem nebo za větou, čímž se často dostane odkaz do další věty, kam logicky nepatří) nebo autor v číslovaných odkazech v textu uvádí nějaká čísla, ale neuvádí, co ta čísla znamenají (obrázek, přílohu, rovnici). Na str. 6 vznikl chybně posun číslování odkazů pod čarou. | |
| Práce s literaturou | 65 | Autor by mohl v textu lépe vysvětlit, podle čeho vybíral a nakonec vybral studijní zdroje. Autor často volí nějaké internetové stránky, což není úplně ideální (nejedná se o recenzované dílo, na web si může každý napsat cokoliv). Převzaté prvky jsou náležitě citovány, ale značná část textů v kap. 2 jsou spíše překladem celých pasáží z uvedených zdrojů (namátkou např. kap. 2.8 přeloženo z [3], 2.12 přeloženo ze [14]). U diplomové práce by se očekávala větší diskuze řešených problémů a jejich technických či metodických aspektů, k tomu argumentace při výběru převzatých znalostí a především jejich autorská intepretace reflektující konkrétní řešený problém autorova zadání. V kap. 2.10 není jasné využití zdrojů [30] a [33], když kap. obsahuje překlad vybraných částí ze zdroje [32]. | |
| Realizační výstup | 95 | Realizační výstup je programové řešení nové desktopové aplikace pro tvorbu spisových stránek pro PČR s využitím klient-server architektury. Programové řešení má velmi dobrou úroveň a je funkční. Kromě vlastního informačního systému obsahuje výsledné řešení i editor obrázků s potřebnými funkcemi k dané úloze a integruje dotrénovanou CNN architekturu v algoritmu YOLOv7 pro automatickou detekci specifických číselných karet ve scéně (včetně klasifikace číslic). Autor se při realizaci zaměřil převážně na vlastní implementaci, méně již nad úvahami, jak např. navrhnout výsledné GUI. V kap. 4.3 autor popisuje, co může uživatel na obrázku GUI vidět, vůbec ale nezdůvodňuje, proč právě takto výsledné GUI navrhuje. Tabulka není jediná možnost, jak prezentovat seznam datových struktur v digitální podobě, jsou i jiné možnosti, které mají své výhody a nevýhody. Toto ale autor nezvažuje, rovnou volí tabulkový přístup. Je-li to efektivní nebo ne, již nezvažuje a už vůbec nijak netestuje a nevaliduje. Ve zdrojových souborech ani v textové zprávě není dohledatelné ani zřejmé, jak (a zda-li vůbec) autor vyřešil tvorbu tiskových výstupů dle specifikace v Příloze A. Ve skriptu pro dotrénování modelu YOLOv7 se data načítají z adresářové struktury a souborů, které v odevzdaném archivu nejsou k dohledání (nebo není zřejmý způsob dělení datasetu). Není vysvětleno, proč autor pro práci s datovým modelem nevyužívá některé z ODM/ORM knihoven. Využití přímo SQL je sice z pohledu výkonnosti nejvhodnější, ale řešená úloha, resp. množství zpracovávaných dat, explicitně takovýto přístup nevyžadují a pro efektivnost údržby a perzistence datového modelu by bylo vhodnější využít některou s celé řady ODM/ORM nadstaveb. Realizační výstup neobsahuje jakékoliv formy testování: jednotkové, funkční nebo uživatelské. | |
| Využitelnost výsledků | Výsledná aplikace je plně funkční. Jelikož nejsou známy realizované testy (ani funkční, ani uživatelské), o použitelnosti nyní nelze nic říct. Lze ale očekávat, že aplikace testována bude a ve výsledku bude PČR využita, jedná se totiž o kvalitní výsledek. |
eVSKP id 146220