Iterace 1 zadavatel demo » Historie » Revize 3
Revize 2 (Štěpán Faragula, 2025-03-03 21:53) → Revize 3/7 (Štěpán Faragula, 2025-03-03 22:17)
h1. 1. iterace - Demo schůzka se zadavatelem ---- h3. Informace o schůzce * *Datum: 3.3.2025* * *Čas: 11:00 - 11:45* * *Forma: online přes Teams* h3. Účastníci: * Jakub Pavlíček * Jakub Homolka * Štěpán Faragula * Jan Vandlíček * František Urban * Na schůzce byl i přítomný mentor, který pozoroval průběh h3. Poznámky ze schůzky * Postupně jsme ukázali zadavateli všechny artefakty (vize, specifikace požadavků, konvence, repozitář GitLab) ** Zadavatel byl s těmito artefakty spokojený ** Vize zůstala bez výčitek a zadavatel s ní souhlasí * Komentáře ke specifikaci požadavků ** Implementaci dotahování změn z ALM bychom bysme si mohli v prvotních fází ulehčit přes soft delete (tzn. ALM se z databáze smaže a načte se celý projekt znovu) ** Dostali jsme doporučení ohledně způsobu pumpování *** Pumpa na GitHub by mohla fungovat tak, že nejprve spustí pumpu na Git a potom spustí dolování zbylých dat *** Git neumí např. zmiňování commitů mezi sebou *** Github vrací mentions na release. Git pouze tagy *** Ve SPADe je koncepční rozdíl u tagů (ne každý tag je nutně release) ** Požadavky na GUI *** Měli bychom bysme umožnit uživateli zvolit, co konkrétně chce pumpovat (pouze commity, commity + issues, pouze main branch) *** Uživatel by si měl být schopný zvolit čas od kdy do kdy chce data pumpovat **** Datetime až na úroveň hodin, minut **** Prozatím není nutné abychom uměli dotáhnout data od posledního pumpování či od konkrétního release, datum + čas natvrdo stačí *** GUI může být postaveno jako React aplikace ** Přibyl požadavek na pseudonimizaci dat *** Data mohou být dolována na základě NDA a není vhodné je ukládat do databáze v plaintextu *** Na konci těžícího procesu si uživatel bude moci vybrat, jestli data (a které konkrétně) chce pseudonimizovat **** Název projektu, názvy artefaktů, popisky ticketů, autoři, commit message, atd. *** Na vyžádání by i pumpa měla vygenerovat přepisovací tabulku pseudonimizovaných textů na skutečné **** Hodí se, když budeme dělat analýzu anti-patternů pro firmu, aby pracovala s konkrétními daty **** Tabulka může být v libovolném formátu (nejspíš XML nebo JSON) **** Dotahování nových dat musí s tabulkou také umět pracovat (přibyl nový uživatel) *** Pro některé analýzy anti-patternů je důležité mít počet znaků **** Není možné v databázi nahradit číslem integer **** Místo konkrétního plaintextu bychom mohli uložit stejně dlouhé LIPSUM *** Pseudonimizace artefaktů **** Uložit si, k čemu se artefakt vztahuje (specifikace požadavků, testy, ...) **** Obsah se v databázi dává do description, týká se pouze textu či markdown (ne PDF, s tim pseudonimizaci neuděláme) **** Kvůli analýze anti-patternů je vhodné umístit popisky na předem definovaném místě (začátek úvodu, konec úvodu, začátek analytické části, ...) **** Nutné důkladněji promyslet, současná databáze na to není stavěná ** Je nutné psát veškeré dokumentace v angličtině (uživatelský manuál, JavaDoc, instalační, README, GUI) *** Lokalizace na češtinu je možná, ale ne nutná ** Nice to have = nasazení projektu přes CICD ** Specifikace jinak obsahuje vše o čem jsme se bavili a zadavatel byl spokojený * Komentáře ke konvencím ** Pro zadavatele dobré vědět, ale je to spíše interní věc h3. Poznámky mentora * Na konci schůzky jsme neprobrali, co bude obsahem další iterace ** Nutné mít vzájemně domluvené a odsouhlasené ** Ideálně si udělat bullet points a jít bod po bodu, co se povedlo naplnit a co ne ** Dávat těmto úkolům priority * Je nutné lépe moderovat schůzku a nebát se zadavatele při povídání zastavit ** Ztrácíme tak čas, který jsme mohli využít někde jinde ---- Autor: Štěpán Faragula Datum: 3.3.2025 Stav: hotový