1. iterace – Demo schůzka se zadavatelem¶

Informace o schůzce¶

• Datum: 3.3.2025
• Čas: 11:00 - 11:45
• Forma: online přes Teams

Účastníci:¶

• Bc. Jakub Pavlíček, jpvlck@students.zcu.cz
• Bc. František Urban, furban@students.zcu.cz
• Bc. Jakub Homolka, homolka7@students.zcu.cz
• Bc. Jan Vandlíček, vandl@students.zcu.cz
• Bc. Štěpán Faragula, farag844@students.zcu.cz
• Na schůzce byl i přítomný mentor, který pozoroval průběh

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 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 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 tím 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

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ý