ASWI - Pokročilé softwarové inženýrství » ASWI 2020 » Java object universal deserializer (GK Software) - Horký

h1. II. iterace

h2. 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

h2. Poznámky

h3. 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).

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

* 24. 4. schůzka ASWI v době cvičení

*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ů

> * upravit celkový plán, produkční prostředí ("současná průměrná konfigurace") + typ databáze, verze (mysql 7 nebo co), ERA model?

* 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ů (uml: komponentový diagram, data-flow, package, ...)

* ?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!