II. iterace¶

Obecné informace¶

Začátek: 3. dubna 2020 (posun na 6. dubna viz konec první iterace)
Konec: 17. dubna 2020
Plánovaný výstup (LCA milník):

• DSP
• Architektura
• Doladění nástroje pro deserializaci (stabilní verze pro převod z binárních dat do JSON)
• Návrh GUI, popř. exportu do HTML/JScript

Poznámky¶

Info z týmových schůzek¶

Vždy probírán aktuální stav + plány do další schůzky.

Důležité body:

• problém se vstupem - problém se zkopírovanými byty z editorů
• toString() se zvýrazněnou syntaxí (+ hledání?) - na pátek ukázka pro zákazníka (formát pro název hlavní třídy) - HTML atributy, CSS, celý HTML dokument, ...
• CLI pouze jako příkaz (bez Scanner(System.in))? Nebo s menu? Návrh pro zákazníka s definovanými volbami, bez cyklu, uvidíme co na to řekne zákazník
• plánované odeslání aplikace 16.04.
• návrh pro třetí iteraci - HTML formátování výstupního zobrazovaného JSON, JDBC driver
• týmová domluva ohledně implementace - rozhraní čtení bytů (různě vytvářené archivy), rozhraní pro UI (kvůli výsledkům z vlákna Converter)
• formátování zobrazovaného JSON přes dvojí volání toString() + přidání konfigů, kde si uživatel nastaví barvy, odsazování apod.
• textovou oblast pro kopírované byty vyhodit, brát data rovnou ze schránky při "zaktivování" okna - animace pod vstupem (spíše se ze schránky bude brát ID BLOBU pro JDBC driver).

Ukončení iterace - poznámky ze schůzek (se zákazníkem, s mentory)¶

Zákazník

• kopírování není úplně nutný, spokojenost s načítáním ze souboru
• JDBC driver není zajímavý (nakonec jako náhrada místo textové oblasti pro byty)
• connectionString v konfiguraci aplikace - okno nastavení aplikace přímo v GUI
• textarea pro vložení ID pro nalezení záznamu - blobu
• barvičky nekonfigurovat
• vyhledávání - zamítnuto

• posílat zazipované .jar soubory
• zákazníkovi .jar běží
• chybové hlášky u vstupů ze schránky
• možnosti kopírování?

p. Pícha

• deployment line nedobrá (zazipované .jar přes mail!), vzhledem k málu zbývající práce netřeba (docker, přístup zákazníka na školní repo apod.)
• "jakákoli databáze" - struktura? ER? SQL? - vyřešit před "puštěním se do toho"

• REDMINE

• Hodiny vyrovnaně rozložené
• Wiki v plánu je fajn
• jediný otevřený Task = schůzky -> v pořádku
• burndown není ideál, ale 1) ostatní závazky, 2) Velikonoce

• ISSUES

• z II. iterace Vypadá vše OK
• kritéria pro rozhození mezi Trackery - nejsou reálně stanoveny - stanovit
• ! moc velká časová rezerva dána přiřazením Estimated time rodičovskému úkolu - ten to prostě sčítá!
• nechat na nadřazeném úkolu pár hodin "pro sychr" ? - došlo k duplikaci.

• VIZE

• stakeholders - přidat skupinu cílových uživatelů

• DSP

• celkově dobrý, spousta pěknejch věcí
• akceptační kritéria lépe roztříděné - viditelné, zvýraznění, lépe uvést, není nutné uvádět rušení předchozích
• priorita nevýrazná
• Obrázky nemaj popisky
• use case není !USE CASE! dle UML - nedošlo k dementaci, hraničí s procesním / workflow /něčím jiným, USE CASE scénář VS USE CASE diagram, paralelismus GUI a CLI v diagramech - jak to správně dělat?
• původní popisky byly sice přesnější, ale hodnoceny jako příliš formální
• GUI náčrtem - popisky jednotlivých grafických prvků - screenshot neplní funkci

• ARCHITEKTURA

• tématově, obsahově v pohodě (pokryto to, co by mělo)
• moc textu, málo obrázků - fakt jenom obrázky, není použit standardizovaný formát obrázků

• ?REPOSITORY TAGY?

• realease se neobjevuje v issue trackeru (ačkoliv validní)
• tagy jinak než "II. iterace"

p. Mouček

• neplánovat na svátky ;)
• málo obrázků, STANDARDIZACE, vazby úplně blbě -> překopat!

• nevíme kdo bude aplikaci používat
• 24. 4. schůzka ASWI v době cvičení

Současná průměrná konfigurace
Vize – celkový plán, produkční prostředí - Typ databáze, verze (mysql 7 nebo co)
Databáze, use case diagramy spíše scénáře, priority, popis GUI
Architektura méně textu více obrázků, uml-komponentový diagram data-flow package
Cílový uživatelé, databáze a grafy standardizovat.
4.5. 15:30 zákazník
Hodnotící 17:30