Části SW Analýzy
1.Business analýza
Business cíle (BG)
Zdůvodnění ekonomické smysluplnosti projetu
náklady (TCO,...)
přínosy (finanční, jiné)
jednotkové náklady (např. průměrné náklady na uživatele/rok, jednu prodanou vstupenku, jednu realizovanou zakázku, poskytnutou půjčku,...)
Business Domain Model (pomocí UML class diagram v EA)
Business Proces Model (pomocí UML activity diagram v EA)
Business požadavky (BRQ) včetně vazeb na business cíle (pomocí diagramu požadavků v EA)
2. Prvotní softwarová analýza
Systémové požadavky (SRQ) včetně vazeb na business požadavky (pomocí diagramu požadavků v EA)
Digramy případů užití
Analytický doménový model tříd
Jedná se v podstatě změněný/vylepšený Business Domain Model, který odpovídá potřebám implementace. Lze z něj například automaticky generovat DB tabulky či třídy v MODELu (v architektuře MVC).
Třídy musí mít definované všechny atributy i jejich datové typy.
Musí být definované všechny násobnosti.
3. Detailní softwarová analýza
Systémové požadavky (SRQ) včetně vazeb na business požadavky (pomocí diagramu požadavků v EA)
Digramy případů užití
Analytický doménový model tříd
Jedná se v podstatě o transformovaný Business Domain Model, který odpovídá potřebám implementace. Lze z něj například automaticky generovat DB tabulky či třídy v MODELu (v architektuře MVC).
Třídy musí mít definované všechny atributy i jejich datové typy.
Musí být definované všechny násobnosti.
Mají mít pojmenované všechny vazby.
Pokud může třída nabývat různých stavů, tak:
Musí být definována množina přípustných stavů (např. pomocí pomocné třídy typu <<enumeration>>, stavového diagramu, poznámky u aributu, ...).
Musí být definovány stavové digramy pro složitejší okolnosti přechodů mezi jednotlivými stavy.
Detailní specifikace jednotlivých případů užití
Stručný popis
Možnosti spuštění případu užití
Detailní průchod případu užití (Scénáře hlavní, alternativní i výjimečné)
Schématický návrh obrazovek (wireframes) včetně validačních hlášek a nápověd
Mapování analytického doménového modelu na elementy wireframes
UC kontext diagram
Každý člen týmu vytvoří detailní specifikaci mimálně pro 5 netriviálních případů užití týkající se řešeného problému. Tedy nikoliv například administrace či logování uživatelů atd.
4. Návrh aplikace (architektura + wireframes včetně navigace)
Návrh logické architektury aplikace
Diagram komponent (společné za tým!)
digram komponent a jejich propojení
diagram interfaců a jejich služeb
diagram jednotlivých komponent a jejich realizací interfaců
Sekvenční diagram
Každý člen týmu vytvoří alespoň jeden digram pro jeden svůj složitější scénář případu užití.
Odkaz na sekveční digram doplní do kontextového diagramu UC.
Entity (lifelines) v sekvenčním diagramu musí "tahány" z diagramu komponent.
Služby (metody) uvedené u jednotlivých volání musí být až na vyjímky uvedeny v diagramů interfaců a sekvenčním digramu jen odkazovány.
Návrh fyzické architektury = Diagram nasazení
Kompletní schématický návrh uživatelské rozhraní ve formě wireframes
Navigace = proklikávání/prolinkování jednotlivých stránek,
nápovědy,
validační hlášky,
chybové hlášky.
5. Finální dokumentace
Kompletní dokumentace projektu včetně zapracovaných všech dřívějších připomínek cvičícího a oponentů spojená v jednom dokumentu.
Opravená byznys analýza
Opravená detailní analýza
Opravený návrh aplikace
Opravená kompletní schématický návrh uživatelské rozhraní ve formě wireframes
Finální dokumentace projektu musí dále obsahovat:
individuální sebehodnocení práce na celém projektu za každého člena týmu,
finální tabulku s hodnocením členů a přerozdělením bodů,
počty hodin odpracovaných za jednotlivé členy týmu,
zpětné hodnocení tvorby dokumentu především z pohledu organizace práce
Co se osvědčilo/fungovalo?
Jaké byly problémy?
Co bychom dělali lépe/jinak, kdychom předmět dělali znovu? Aneb minimalně 5 doporučení pro studenty v příštím roce.