Požadavky milníku LCA » Historie » Revize 2
Revize 1 (Michal Linha, 2020-04-15 19:40) → Revize 2/3 (Vojtěch Danišík, 2020-04-17 07:34)
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 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