Posudek oponenta bakalářské práce
Studijní program:Aplikovaná informatika Studijní obor:Aplikovaná informatika Akademický rok:2020/2021
Název práce:Návrh a realizace systému pro správu faktur Řešitel:Daniel Novotný
Vedoucí práce:RNDr. Helena Palovská, Ph.D.
Oponent:Ing. Jan Říha
Hlediska Stupeň
hodnocení
1. Jasnost a srozumitelnost formulace tématu a cíle práce 2
2. Rozsah a relevance popisu současného poznání 2
3. Náročnost řešeného tématu práce 1
4. Adekvátnost metod k řešení stanoveného problému, správnost jejich výběru a použití 1
5. Rozsah, hloubka a preciznost popisu výsledku 3
6. Relevance a správnost diskuse výsledku 2
7. Věcný přínos výsledku dosaženého v práci 3
8. Relevance informačních zdrojů a korektnost jejich citování 3
9. Logická stavba práce a vzájemná konzistence jednotlivých částí 2 10. Gramatika, jazykový styl, terminologie a celková úprava práce 2
Konkrétní připomínky a dotazy k práci:
Autor se ve své bakalářské práci zabývá procesem vývoje webové aplikace představující jednoduchou evidenci faktur. Jedná se o prakticky orientovanou práci, jejímž hlavním cílem je publikování funkční aplikace. Autor v jednotlivých kapitolách práce postupně popisuje proces vývoje. Nejprve se zabývá sběrem a zachycením funkčních požadavků od zadavatele, dále se věnuje základnímu návrhu architektury, datového modelu a uživatelského rozhraní, největší prostor pak věnuje popisu implementace back-endové části aplikace a na závěr popisuje uvedení aplikace do provozu.
K práci mám několik připomínek:
Autor se rozhodl svou práci zaměřit prakticky a jejím stěžejním výstupem by měla být naimplementovaná aplikace. Tuto aplikaci ale jako součást práce neodevzdal – k obhajobě předkládá pouze text, ve kterém postupný vývoj aplikace zjednodušeně popisuje a přikládá vybrané ukázky zdrojových kódů
a konfiguračních skriptů, nicméně kompletní aplikaci nemá čtenář k dispozici. Navíc v čase vyhotovení posudku není funkční aplikace k dispozici ani na webu k vyzkoušení(na webové adrese monancer.com, kde by měla být dle kapitoly 4.4 aplikace přístupná, se nachází blog ve španělském jazyce, který s předloženou prací zjevně nemá nic společného). Splnění cílů práce, v rámci kterých měl autor implementovat front-endovou
i back-endovou část aplikace, proto není spolehlivě doložené.
Chápu, že autor aplikaci vyvíjel jako komerční projekt a kompletní zdrojové kódy nechtěl nebo na základě smluvních vztahů nemohl bez dalšího zveřejnit. V tom případě ale mohl prostřednictvím vedoucí práce požádat o odložení zveřejnění až na dobu 3 let dle § 47b odst. 4 Zákona č. 111/1998 Sb.(zákon o vysokých školách). Vzhledem k minimálnímu rozsahu funkcionality této prvotní verze projektu by případná
monetizace nebyla zveřejněním zdrojových kódů po uplynutí 3 let již nijak ohrožena. Případně autor mohl z projektu vyjmout business logiku a zveřejnit alespoň funkční kostru aplikace, která by obsahovala možnost registrace, přihlášení a např. banální funkcionalitu sčítání čísel. Autorem zvolené řešení aplikaci
‚prostě neodevzdat‘ je to nejméně vhodné a zásadním způsobem degraduje kvalitu celé práce.
Nelze akceptovat ani autorem formulované přínosy práce. Autor v závěru uvádí, že přínosem práce je naimplementovaná aplikace, která má jednak komerční využití a druhak může sloužit jako vzor pro vývoj dalších projektů. Jak již bylo zmíněno, aplikace aktuálně není na uvedené webové adrese dostupná.
Nicméně i kdyby dostupná byla, podobně zaměřené aplikace již na trhu existují a obvykle nabízí mnohem
širší spektrum funkcionalit(příkladem může být Fakturoid, který lze v omezeném rozsahu využívat i zdarma).
V tomto směru tedy autor nepřináší nic nového a zmíněné komerční využití aplikace je velice sporné. Co se týče využití aplikace jakožto vzoru pro vývoj dalších projektů, čtenář práce může převzít pouze dílčí prvky detailněji rozebrané v textu, ale vzhledem k tomu, že nemá k dispozici kompletní zdrojové kódy, práce rozhodně nemůže sloužit jako komplexní šablona pro vývoj jiné aplikace.
Autor si také stanovil značné množství dílčích cílů. Ve snaze je všechny splnit se velmi často uchyluje k výraznému zjednodušování a práce pak na mnoha místech působí zmateně a nevyváženě. Např.:
• V kapitole č. 1.2 se autor zabývá sběrem a zaznamenáním požadavků na aplikaci. Zabývá se ale pouze funkčními požadavky, tzv. nefunkční požadavky zcela pomíjí, ty jsou přitom podstatné pro návrh architektury aplikace, nastavení parametrů provozní infrastruktury apod.
• V kapitole č. 2.1 se autor zabývá návrhem datového modelu aplikace, který je ale velmi zmatený.
Objevuje se v něm entitacost, pro kterou neexistuje žádný US a nevztahuje se k ní ani žádný wireframe. Nejsou jasné významy některých atributů, např. jaký je rozdíl mezi atributyissue_date aissued_dateu téže entity. Není jasné, proč má entitacompanydvě vazby k entitěuser_account (pokud je uživatel vlastníkem záznamu, nikdy by nemělo dojít k situaci, kdy bude tatáž entita dodavatelem pro jednoho uživatele a odběratelem pro jiného). V ERD diagramu se také vyskytuje technická tabulka flyway_schema_history, o které v textu není ani zmínka, o jejím významu lze začít něco usuzovat teprve po přečtení kapitoly č. 3.1.
• V kapitole č. 2.2 autor poněkud směšuje pojmy architektura a infrastruktura. V kapitole by měla být popsána architektura aplikace skládající se z několika komponent, které mohou běžet ve více instancích, aby bylo dosaženo potřebné spolehlivosti a škálovatelnosti celé aplikace. Nicméně tento popis architektury není nutné fixovat přímo na nástroj Kubernetes. To, jestli aplikace následně poběží v Kubernetes, v OpenShiftu nebo v jiném orchestrátoru, je z hlediska návrhu architektury nepodstatné.
• V kapitole č. 3.4 se autor věnuje implementaci front-endové části aplikace, což je jeden z dílčích cílů práce. Kapitola sestává z jednoho odstavce o přesně 60-ti slovech, neobsahuje žádné obrázky ani ukázky zdrojového kódu. Vzhledem k tomu, že front-end je nepostradatelnou součástí aplikace, takovýto rozsah považuji za zcela neadekvátní.
Celá práce také trpí nedostatečným podložením zdroji. Autor v seznamu zdrojů uvádí celkem šest položek, v textu práce se přitom odkazuje pouze na tři z nich, zbylé nejsou nikde zmíněné a v seznamu jsou jen ‚do počtu‘. Kapitoly č. 3 a 4 nejsou podložené téměř nijak. Bylo by vhodné doplnit zdroje k popisu přístupů k realizaci databáze v kapitole 3.1.1 a dále k popisům jednotlivých technologií a produktů, které autor zmiňuje(odkazy na dokumentaci JPA, Springu, OpenAPI, Cognita, Kubernetes apod.).
Byť práce obsahuje značné množství nesrovnalostí a autor společně s textem neodevzdal praktické výstupy, stále považuji práci za obhajitelnou. Obzvláště kapitoly č. 3 a 4, kde autor popisuje implementaci back-endové části aplikace a její následné nasazení do provozu, jsou dobře zpracované, autor se zde drží současných trendů a je patrné, že popisovaným technologiím rozumí.
K obhajobě navrhuji následující otázky:
• Front-end jste vyvinul jako javascriptovou aplikaci. Jakým způsobem je řešen jeho provoz – je poskytován prostřednictvím nějakého light-weight webového serveru typu Nginx, který běží v kontejneru? Nebo jste připravil jednoduchou aplikaci na platformě Spring Boot, která poskytuje potřebné soubory?
• Třídy představující RESTové controllery back-endové části aplikace jste vytvořil ručně. V rámci větších projektů se typicky definice RESTového API vytváří prostřednictvím OpenAPI a controllery i DTO třídy se z této definice následně generují. Uvažoval jste nad touto možností? Jaké výhody a nevýhody by to přineslo?
Autorovi zároveň doporučuji, aby si k obhajobě připravil notebook s kompletním projektem a v případě potřeby byl schopen demonstrovat fungující aplikaci i zdrojové kódy.
Závěr: Bakalářskou práci doporučuji k obhajobě.
Navrhovaná výsledná klasifikace práce: 3
Datum: 23. 8. 2021 Ing. Jan Říha
oponent práce
