ASWI - Pokročilé softwarové inženýrství » ASWI 2025 » Dolování dat z ALM nástrojů do SPADe databáze (Pícha) - SKIBIDI OHIO RIZZLERS

h1. 3. iterace - Schůzka se zadavatelem ohledně technických dotazů 2

----

h3. Informace o schůzce

* *Datum: 1.4.2025* 

* *Čas: 10:00 - 11:00*

* *Forma: online přes Teams*

h3. Účastníci:

* Bc. Jakub Pavlíček, jpvlck@students.zcu.cz

* Bc. Štěpán Faragula, farag844@students.zcu.cz

h3. Poznámky ze schůzky

Zeptali jsme se na dotazy:

# Jak máme uložit data do tabulky <code>project</code>? Je <code>startDate</code> datum prvního commitu?

** Ano, <code>startDate</code> je datum prvního commitu.

** Ne každé ALM má svůj vlastní koncept pro startdate, máme vzít jakékoliv první datum čehokoliv (první commit / první změna v projektu čehokoliv)

*** <code>startDate</code> máme uložit na konci dolování až po tom, co budeme znát všechny <code>work_item</code> a <code>configuration</code>

*** Na konci vybereme položku s nejnižší hodnotou

# V tabulce <code>work_unit</code> je atribut <code>progress</code> nastavený na NOT NULL, jakou hodnotu zde máme nastavit pro GitHub pumpu?

** Máme nastavit 0, tak jak děláme teď

# Máme dodržovat strukturu dat v ukázkových datech? Např. že URL GitHub projektu končí koncovkou <code>.git</code> či název <code>project_instance</code> obsahuje i datum.

** Je to jedno, ale u Git pumpy to dává smysl, u GitHub pumpy to může být jinak

*** Dříve bylo nutné zadat .git kvůli knihovně JGit, protože to procházelo Git pumpou, když se repository muselo stáhnout na lokál

** Datum u <code>project_instance</code> = datum těžení (nemusíme vyplňovat, sloužilo pro debug, můžeme ignorovat)

# Můžeme v tabulce <code>project_instance</code> do atributu <code>description</code> dát text z About na GitHubu? Tento text je uložen v atributu <code>description</code> tabulky <code>project</code>, takže bychom ho ukládali i zde (tj. <code>project_instance.description</code> by byl stejný jako <code>project.description</code>).

** Může být v obojím

** Otázka, jestli dávat podle délky (nejdelší popis je správný), nebo přidávat k existujícím -> víc detailnější

*** Na <code>description</code> nebude žádná analýza viset, jde spíš o orientační záznam a lepší vědět co nejvíce informací (appendování)

** <code>project_instance</code> může mít každá jiný název, u těch se vezme nejdelší možné jméno (dobrá heuristika, fungovalo dříve)

# V tabulce <code>role</code> jsou uloženy role (v případě GitHub repozitáře), které se nepoužívají, např. documenter, tester apod., máme je tedy také vždy vytvářet? Můžeme v GitHub pumpě mapovat roli <code>Contributor</code> na SPADe <code>Developer</code>?

** Ano, je to tam z důvodu, když se chtějí lidi po těžení přemapovat

*** Člověk reálně ví, jaké role zastává a měli bychom umožnit přemapování dat, když už budou v databázi a budou se nad nimi dělat analýzy

** I u ostatních enumů bychom měli vytvářet všechny

*** Dává smysl u stavů, resolutions

*** Priority nejspíše ne

** Contributor a developer dává smysl

# Máme počítat s tím, že Git pumpa se bude spouštět také na lokálním repozitáři, tj. bez zadaného URL?

** Není pro to rozumný usecase, i kdyby chtěl uživatel těžit na lokále, tak repozitář spíš zveřejní online a vytěží

*** Důvod: na lokále jsou necommitované změny a ty nás nezajímají

# U Git pumpy, do jaké tabulky máme ukládat změny souborů (tj. smazán, přidán, upraven)? Co všechno by měla Git pumpa umět? Naše zatím umí dolovat: <code>Identity</code>, <code>Person</code>, <code>Commit</code>, <code>Tag</code>, <code>Branch</code>, <code>Project</code>, <code>ProjectInstance</code> a <code>ToolInstance</code>.

** work_item_change -> atribut name

** U čistě gitové pumpy není nic jiného, co by se dalo těžit, takhle stačí

** Configuration person relation se dá najít přes parsování řádků na commit message

*** Lze se spoléhat na formát, kde je na konci commitu je "Reviewed by: ...", můžeme splitnout dvojtečkou a vzít člověka

# V GitHub pumpě, jak máme těžit tabulky <code>iteration</code>, <code>phase</code>, <code>milestone</code>? U <code>iteration</code> a <code>phase</code> jsou v ukázkových datech stejná data, proč? V <code>milestone</code> není nic, proč? Když GitHub milestone nemá žádný issues, máme milestone i tak těžit?

** Data u <code>phase</code> a <code>milestone</code> jsou stejné kvůli testům

** U těchto dvou položek je lepší je dávat do iterace, protože to více odpovídá skutečnému kontextu.

*** Vše dáme do iterace, zbytečné dávat data do obou

** Milestones neřešíme vůbec

*** Velmi zřídka se dá najít koncept v ALM který by jim odpovídal

*** Spíše odpovídá popisu na Wiki a to je moc složitý koncept těžení

*** Uživatel si dodefinuje sám

** Když GitHub nemá issues, i tak to máme těžit, je to zajímavá informace 

# Když ukládáme časy do tabulek, máme vždy používat časová pásma těch akcí, nebo naše? Tj. <code>issue.createdAt() = "Mon Jun 01 19:10:43 CEST 2020"</code> -> <code>“2020-06-01T19:10:43Z"</code> s Timezone, nebo <code>"2020-06-01T17:10:43Z"</code> bez Timezone (tj. -2 hodiny).

** Bez timezone a vše máme převést na UTC

** Lidé mohou commitovat z různých timezone, takže je potřeba standarzidovat

# Jaký význam má relace mezi <code>work_item</code> a <code>configuration</code>?

** id w_i = id configuration

*** Relace 1:1

** <code>configuration</code> je jeden z typů work itemu (speciální typ work_item)

*** <code>configuration</code> je rozšíření <code>work_item</code>, stejně jako <code>work_unit</code> je rozšíření <code>work_item</code>

** <code>configuration</code> = změna ticketů/artefaktů

** <code>commited_configuration</code> = worklog (nutné rozlišovat kdy se vytvořil záznam a kdy se strávil čas, může být i zpětně)

** ve SPADe PDF je hierarchická struktura mezi jednotlivými typy <code>configuration</code>

Dále jsme se bavili o schématu architektury systému

* High-level má dobré schéma, dále to chce lépe popsat systém uvnitř Docker kontejneru (udělat nové, detailnější schéma)

** Bude tam popis naší abstraktní třídy na pumpy

*** Popis jednotlivých tříd a rozhraní, pak jak jsou implementovány v jednotlivých pumpách

*** DAO vrstva

** Můžeme tam zanést i věci co se budou dělat v TSP2

*** Modul na pseudonimizaci, modul na čtení konfigurací a na těžení jednotlivých konceptů

* Se zadavatelem jsme se dohodli, že *dosavadní architektura je pro tuto iteraci dostačující*, detailnější pohled můžeme udělat v další iteraci

Poté nám přidal zadavatel nový požadavek týkající se způsobu pumpování a také GUI

* Pumpy by měly umožňovat zakomponovat různé <code>project_instance</code> (Redmine, GitLab) do již vydolovaného projektu

** Tím se rozšíří sada lidí a identit (buďto se identity přiřadí k již existujícím lidem z vydolovaného <code>project_instance</code>, nebo se vytvoří nové)

*** *Pozor*, lidé jsou připojeni k <code>project</code> a ne k <code>project_instance</code>

** Dále nám to i umožní propojení mezi ticketama a commitama

*** Když dotahujeme další instanci tak musíme dohledávat propojující dotazy

*** Nutné projet všechny commit messages již uložených instancí -> nutné udělat manuálně zpětně

**** Kdybychom spojovali 4 ALM dohromady, u přidávání posledního projdeme commit messages všech 3 předchozích

*** Odkazy na tickety se mohou vyskytovat např. u Redmine i v popisu a komentářích

**** Zachyceno v tabulce <code>work_item</code> odkazem sama na sebe (odkaz ticket -> ticket)

**** Vše se propojí v tabulce <code>project</code>

* GUI by mělo umožňovat 

** Před těžením se zeptá, jestli bude těžit *nový projekt* nebo jestli bude *přidávat do existujícího projektu*

*** Implementace přes CheckBox (chci/nechci přidávat do exitujícího) + SelectBox (když chci, do jakého konkrétně)

* Nové požadavky by bylo *vhodné zprovoznit do konce TSP1* v základní verzi, funkcionalitu *můžeme však přesunout do TSP2*

* Důležité je zdokumentovat, co všechno jsme zprovoznili do konce TSP1

Nakonec ještě přibyl požadavek na CICD

* Měla by být možnost připojení na vlastní reálnou databázi místo dockerizované

* Důvod: na tuto reálnou databázi se následně mohou napojit i jiné nástroje

* Tuto funkcionalitu máme naplánovat *až na TSP2*, zatím nedává smysl

----

Autor: Štěpán Faragula

Datum: 1.4.2025

Stav: hotový