VOLÁK, D. Klient pro správu požadavků [online]. Brno: Vysoké učení technické v Brně. Fakulta informačních technologií. 2025.
Student pracoval samostatně a cíle práce splnil. Vytvořené řešení je plně funkční i když některé aspekty implementace mohly být více konzultovány s vedoucím práce. Technická zpráva mohla být vypracována s větším předstihem aby bylo možné její celkový obsah i formu dostatečně připomínkovat.
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Informace k zadání | Cílem práce bylo vytvořit klienta umožňujícího spravovat požadavky ve vybraném nástroji pro správu požadavků, konkrétně v nástroji JIRA a jeho rozšíření Requirements for JIRA (R4J), skrz OSLC rozhraní založené na OSLC Requirements Management (RM) specifikaci. Práce rozšiřuje existujícího univerzálního OSLC klienta pro Python o definici OSLC Requirements Management (RM) domény a klienta podporujícího tuto doménu. Práce sice vyžadovala nastudování rozsáhlé specifikace OSLC RM domény, její implementaci v jazyce Python ovšem zjednodušoval univerzální OSLC klient a jeho sada dekorátorů pro definici OSLC domén. Práci tedy hodnotím jako průměrně obtížnou. Práce byla vytvořena ve spolupráci se společností Honeywell, jenž využívá nástroj JIRA a jeho rozšíření R4J jako jeden z nástrojů pro správu požadavků. Předpokládá se také, že vytvořený klient bude tvořit důležitý základ plánovaného OSLC RM klienta pro nástroj IBM DOORS NG, jenž slouží ke správě požadavků komplexních bezpečnostně-kritických systémů, a je dominantním nástrojem pro správu požadavků ve společnosti Honeywell. | ||
| Práce s literaturou | Student využil jak doporučenou literaturu, tak si samostatně vyhledával další relevantní a potřebné zdroje. | ||
| Aktivita během řešení, konzultace, komunikace | Student pracoval samostatně, řešení konzultoval jen zřídka, obvykle přes platformu MS Teams. Na konzultace byl vždy dostatečně připraven. Aktivita studenta mohla být určitě vyšší, hlavně z pohledu průběžného informování vedoucího o postupu práce. | ||
| Aktivita při dokončování | Student dokončil implementaci zhruba dva týdny před odevzdáním, kdy začal pracovat na sepisování technické zprávy. Draft práce byl zaslán vedoucímu necelý týden před odevzdáním a to bez kapitoly věnované evaluaci, jejíž předpokládaný obsah byl pouze probrán v rámci konzultace. Připomínky k obsaženým kapitolám byly studentovi dodány, student již ale nestihl do odevzdání zaslat verzi technické zprávy se zapracovanými připomínkami a kapitolou věnovanou evaluaci. | ||
| Publikační činnost, ocenění | Výsledky práce budou zveřejněny formou open-source software na GitLab serveru výzkumné skupiny VeriFIT. Předpokládá se využití firmou Honeywell, ať již přímo pro interakci s nástrojem JIRA a jeho rozšířením R4J, nebo jako základ plánovaného OSLC RM klienta pro nástroj IBM DOORS NG. |
Mírně složitější zadání bylo splněno, výstup práce je funkční a má potenciál pro další praktické využití. Identifikoval jsem ale řadu nedostatků ze strany informační, typografické, bibliografické i implementační. Hodnotím tedy celkově jako průměrnou práci stupněm C.
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Náročnost zadání | Seznámit se se standardem OSLC, souvisejícími technologiemi a dostupnými nástroji pouvažuji za obtížné. Zároveň ale práce stavěla na již existujícím frameworku, který ulehčuje implementaci OSLC domén a poskytuje základního klienta, což práci ulehčilo. Celkově tedy jen mírně obtížnější zadání. | ||
| Rozsah splnění požadavků zadání | |||
| Rozsah technické zprávy | |||
| Prezentační úroveň technické zprávy | 70 | Logická struktura je v pořádku. Z pohledu pochopitelnosti práce nejasně vysvětluje, co je jejím hlavním smyslem a výsledkem. Text práce směřuje na to, že byl především vytvořen klient s rozhraním na příkazové řádce, který lze použít pro komunikaci. Toto rozhraní však ale vůbec není důležitým výstupem práce. Hlavním plánovaným využitím je import modulů domény a klienta do kódu jiných aplikací. Z informační stránky mám dvě výhrady: Sekce 5.6.3 diskutuje limitaci implementovaného klienta, která je způsobená limitací klienta, na kterém tato práce stavěla. Jedná se o neschopnost zpracovat složky s zanořenými podsložkami, které adaptér R4J reprezentuje v rámci jednoho RDF jako přímo vnořené (inline) RDF zdroje. Toto chování je v práci označeno za nestandardní, neočekávané a za porušení standardu OSLC. Toto je ale chybné tvrzení. Standard OSLC explicitně podporuje odkazované i zanořené (inline) zdroje. Zanořené zdroje jsou dokonce v některých doménách i explicitně doporučeny. Sekce 6.2.6 udává jako důvod pro selhání některých testů známou chybu v adaptéru pro některý z nástrojů JIRA nebo R4J. V práci ale není vysvětleno, o jakou chybu se jedná a jaký má dopad na funkcionalitu. Dle popisu v citovaném zdroji se jedná o chybu v API nástroje R4J a tedy ne o chybu v jednom z adaptérů. Chybný je dále pouze návratový kód v odpovědi na požadavek, ale operace proběhne v pořádku. Tohle chování tedy mohlo být v této práci jednoduše vyřešeno ignorováním chybného návratového kódu. | |
| Formální úprava technické zprávy | 70 | Po jazykové stránce je práce v pořádku až na pár drobných překlepů. K typografické stránce mám několik výhrad: Rozbitá reference na obrázek na straně 10. Nedodržení konvence kapitalizace některých nadpisů včetně samotného názvu práce. Nadměrná velikost některých obrázků (5.1, 5.2). Chybně vysázená vsuvka pomocí dlouhých pomlček (např. strana 13 a 33). | |
| Práce s literaturou | 70 | Všechny relevantní zdroje jsou citovány. Nedostatky: Nenašel jsem referenci na nástroje JIRA a R4J, které jsou pro práci klíčové. Řada záznamů v bibliografii má nevhodně vysázeného autora (např. IBM Corp., OSLC, Docker Inc.). Především v úvodních sekcích o použitých technologiích se nachází velké množství odstavců s citací na konci ve stylu parafráze. Ve skutečnosti ale jde jen o nevhodně vysázené odkazy na zdroje informací, ze kterých student volně čerpal. Při demonstraci student uvedl, že do určité míry převzal testovací sadu ze závěrečné práce, ve které byly vytvořeny adaptéry pro nástroje JIRA a R4J. V textu práce tohle ale není řečeno. | |
| Realizační výstup | 70 | Kusy kódu, které byly převzaty, jsou jasně vyznačeny. Hlavním výstupem práce je korektní implementace tříd pro jednotlivé OSLC zdroje (resource) podle specifikace OSLC RM. Výhradu mám proti tomu, že modul implementované domény míchá dohromady i zdroje z jiných domén, které by měly být umístěny ve svých vlastních modulech. Dalším výstupem je modul klienta, který poskytuje metody pro komunikaci s adaptéry pro nástroje JIRA a R4J. Poskytnuté metody jsou funkční a byly dostatečně otestovány. Za nedostatek považuji zvolenou signaturu metod, jelikož mají parametry zvlášť pro každý atribut daného OSLC zdroje. Není tedy možné metodě předat předpřipravený objekt. Tohle ztěžuje především update existujících zdrojů, který typicky probíhá získáním aktuální verze zdroje pomocí GET, úpravou potřebných atributů a následným PUT celého upraveného zdroje. Posledním výstupem, který je ale nedůležitý a jen pro účely demonstrace, je rozhraní na příkazové řádce. Jeho kvalita a použitelnost je poměrně nízká a celkově působí nedodělaně. Rozhraní poskytuje neužitečné odpovědi (např. není vždy poznat zda se operace povedla) a některé informace skrze klienta nelze získat (např. URI zdroje v odpovědi na GET). Funkcionalita je navíc limitována tím, že není schopen brát OSLC zdroje na vstupu přímo ve formátech RDF/XML/JSON. Každý zdroj a jeho jednotlivé parametry musí být rozebrány do jednotlivých argumentů příkazové řádky. Podobně pak klient na výstupu vypisuje OSLC zdroje v jednoduchém nestandardním formátu namísto formátu RDF/XML/JSON. | |
| Využitelnost výsledků | Je možné, že dojde k praktickému vyzkoušení vytvořených modulů ve firmě Honeywell. Dále je pak pravděpodobné jejich další využití jako základ pro navazující závěrečné práce. |
eVSKP id 164594