ASWI - Pokročilé softwarové inženýrství » ASWI 2020 » Webová aplikace simulující kontingenční tabulku (CIV) - VLDC

h1. Požadavky milníku LCA

Ve fázi Elaboration se vývojový tým soustředí na dokončení popisu projektu a stabilizaci požadavků (finalizaci Vize), výběr a popis vhodného architektonického řešení systému, přípravám na samotnou realizaci (implementaci) systému a jeho testování. Hlavními artefakty je konečná verze Vize a dokument Architektura.

(poznámky platné k 15.4.2020 21:30, některé body se ve výsledku spojí do jednoho)

# *Finalizace vize* - dále by se už neměla měnit, musí schválit zákazník -> zde bych řekl, že bude stačit upravit a doplnit to, co řekl mentor

# *Vytvoření popisu požadavků* (funkčních a mimofunkčních) - use case scénáře, nebo user stories, alespoň dva úrovně pohledu, alespoň 80% požadavků -> _máme jen use case diagram, ale ten patří asi spíš modelu_

# *Vytvořit model požadavků - "Seznam požadavků (ať už funkčních, či mimofunkčních) je jedním z nejdůležitějších artefaktů v rámci projektu vůbec. Proto je téměř nutné zachytit tyto požadavky v grafické podobě, jelikož ta je pro mnoho lidí (především zákazníka) názornější a srozumitelnější a může odhalit mnohé nesrovnalosti a nutná zpřesnění. Tým by měl k modelování požadavků vybrat patřičný způsob v závislosti na specifikách projektu, resp. systému. Jednou z nejrozšířenějších forem modelu požadavků je use-case model" -> _viz bod 2_

# *Vytvořit dokument specifikace požadavků* - podrobný a detailní popis, pokud ho vyžaduje zákazník -> _máme jen prvotní požadavky_

# *Vytvořit skript databáze* -> _hotovo (snad, ví Vojta)_

# *Vytvořit testovací případy* -> _nemáme, nevím jestli budou_

# *Vytvořit prototyp UI* -> _částečně hotovo_

# *Vytvořit modely* - např. graficky -> _některé jsou vytvořeny, budou pak v dokumentu Architektura_

# *Vytvořit (implementovat) spustitelnou architekturu* - pokrývá všechny oblasti činností výsledného systému, "základ uživatelských rozhraní s nefunkčními (nebo minimálně funkčními) ovládacími prvky, propojení subsystémů přes rozhraní za účelem ověření průchodnosti a konzistence dat mezi nimi, procedury či metody, které místo výpočů provádějí prosté úkoly (např. vracejí kontrolní řetězec nebo jinou vždy stejnou hodnotu) a počítají s naprosto správným postupem uživatele a funkcí okolních systémů, tudíž nemá např. kontrolu formátu vstupních dat, reakce na provedení akcí, k nimž nejsou aktéři oprávněni, atd. Úspěšná implementace spustitelné architektury vede k eliminaci nebo minimalizaci většiny architektonických rizik" -> _částečně hotovo_

# *Vytvoření dokumentu Architektura* - "Jeden z hlavních artefaktů v celém projektu. Zahrnuje celkový model a popis architektury, ERA model databáze a další vhodné modely (workflow, komponentový, class diagram, package diagram, procesní, diagram aktivit apod.) a popisy atributů nebo částí architektury (rozhraní, návrhové vzory, atd.). Jako jeden z předních dokumentů projektu by měl být jeho obsah schválen zákazníkem. Detaily dokumentu se mohou postupem vývoje měnit, celková architektura by měla být dostatečně stabilní." -> _vůbec není_

h2. Možné otázky

Zda jsme dosáhli tohoto milníku nám pomůže zjistit následující kontrolní seznam:

# Je vize produktu stabilní, jsou stabilní požadavky? -> _částečně, ano_

# Máme stabilní architekturu? -> _částečně_

# Jsou klíčové postupy a přístupy, které budeme používat, otestovány a je dokázána jejich použitelnost? -> _částečně_

# Ukázalo testování spustitelného prototypu, že jsou klíčová rizika identifikována a vyřešena? -> _nevím_

# Máme definovány plány iterací pro následující Construction fázi v náležitých podrobnostech, abychom byli schopni podle nich postupovat? -> _zatím ne_

# Jsou tyto plány podpořeny důvěryhodnými odhady? -> _###_

# Naplněním plánu s použitím definované architektury dosáhneme cílů shrnutých ve vizi? -> _ano_

# Jsou aktuální náklady akceptovatelné vůči plánovaným? -> _asi neřešíme_

Zdroj: https://www1.osu.cz/~zacek/ropr1/ROPR-skripta.pdf