ASWI - Pokročilé softwarové inženýrství » ASWI 2024 » Využití Deep Learning v medicínských aplikacích - MedicalBugs

Průběh a stav projektu (slušné 2b)¶

• zhruba LCA
• zhruba standardní ASWI proces

pozitiva

• dobrá organizace práce a komunikace
• tým postupuje sice částečně intuitivně, ale správně

negativa

• lehce nevyrovnaný objem příspěvků (zejm. jeden z členů, 115/150/130 vs 70 hodin a 18/10/10 vs 1 commit), diskutováno

další komentáře

• dosud strávený čas: 478 hodin

Iterace (slušné 2b)¶

• delší (3 týdny) vzhledem k cíli (dosahnout LCA) a již vyjasněným potřebám uživatelů

pozitiva

• cíl v souladu s fází
• aktivně řeší situace v týmu a komunikaci se zadavatelem

negativa

• "verfied -> closed" až na konci iterace hromadně => burndown spíše "rock edge" => neslouží účelu v průběhu iterace
• dost nadhodnocené effort estimates (Estimated time 237.00 hours, Spent time 178.00 hours), diskutováno

Technická kvalita (slabé 1b)¶

• základní sada artefaktů je pohromadě

pozitiva

• SRS a SAD dobře strukturované, čitelně a srozumitelně napsané
• SAD: využití pohledů vč. vhodně zdůrazněného procesního pohledu, stručně ale informačně hutně psáno
• množství (pro ASWI doplňkových) ekonomicko-manažerských dokumentů/artefaktů (OBS, matice odpovědnosti, ...)

negativa

• stále není vůbec trasovatelnost potřeby <-> požadavky <-> issues <-> commits <-> tests, diskutováno
• SRS: struktura ok, ale specifikace požadavků ne - nejde o use cases, ani něco jiného; technologie jsou takto požadovány uživateli??? ; není specifikován rozsah "první verze aplikace" a "finální aplikace"
  • žádné informace ohledně cílového prostředí a nasazení
• SAD: chyby ve workflow v procesním pohledu; design decisions jsou jen u technologií a nejsou navázány na požadavky; impl pohled neozřejmuje strukturu implementačního projektu (komplet flask-driven? nebo nějaké odchylky? kde je "schovaný" React?) + charakter "krabiček" (třídy? moduly? flask controllery? importované hotové knihovny/komponenty?) a škoda, že tyto "krabičky" nejsou provázaně odkazované v Datové toky; chybí informace o datovém modelu (použité podmnožiny?) MRS a interních datových/funkčních API (např. schemata pro JSON)
  • např. SRS "Odezva systému maximálně do 3 sekund." -- odpovídá tomu architektura s dat. pumpou a získáváním dat vždy on-demand z MRE?
  • např. impl pohled "Predikce mRS" vs tok dat "Model pro predikci mRS" -- jde o tentýž subsystém?
• LCA prototyp není explicitně mapován na uživatelsky a/nebo architektonicky kritické use cases z SRS
  • PoT implementace je triviální tj. příliš jednoduchá a nad rámec propojení prohlížeč<->MRS v podstatě nic neověřuje
  • repo: kompletní RDF connection info vč hesla commitnuté do git repo (!) uff
• klíčové dokumenty nemají "košilku"

Postupy a praktiky (slušné 2b)¶

• jednotlivé praktiky vcelku ok, chybí vědomé použití těch navázaných na risk / priority / value management

pozitiva

• code review pro vybrané merge requests (dle významu změn) dělají, není vidět ve workflow issues ale je vidět v gitlab
  • zapsat do interních pravidel týmu, kde není vůbec
• effort estimates: priorita autorovi issue, celkem to funguje (až na případy průzkumných úkolů typu "naučit se technologii")

negativa

• workflow na ticketech často neodpovídá interním pravidlům týmu (výskyty new -> closed, accepted -> closed)
  • námět na retrospektivu?

Doporučení¶

• diskutováno lack of traceability ("my to máme v hlavě" nestačí)