Požadavky milníku LCO¶
Artefakty milníku LCO - pro nás je nejdůležitější možnost 3¶
Možnost 1
Definice provozní koncepce¶
Top-level systémové cíle a rozsah
hranice systému
parametry prostředí a úvahy
evoluční parametry
Operační koncept
Prototypy systému¶
Vyzkoušet klíčové scénáře užití
Najít kritické (hlavní) nebezpečí systému
Definice požadavků¶
Top-level funkce, rozhraní nebo parametry kvality
vektory růstu
priority
Souhlas stakeholderů s požadavky
Definice systému a softwarové architektury¶
Top-level definice alespoň jedné proveditelné (implementovatelné architektury)
fyzické a logické součásti a jejich vazby
volba existujících prostředků (knihovny) a znovupoužitelných prvků
Identifikace nepoužitelných architektur
Definice Life-Cycle plánu (životního cyklu)¶
Identifikace uživatelů během životního cyklu
uživatelé, zákazníci, vývojáři, údržbáři, obecná veřejnost a další
Identifikace procesního modelu životního cyklu
Top-level fáze, přírůstky
Top-level "Who, What,....." pro fáze
Odůvodnění proveditelnosti¶
Ověření konzistence mezi výše zmíněnými prvky
pomocí analýzy, měření, prototypování, simulace,...
analýza obchodního případu pro požadavky, architektury
Možnost 2
Souhlas s rozsahem¶
Stakeholdeři (lidi, kteří mají s vyvíjeným softwarem co dočinění) se shodnou na rozsahu projektu
Definice prvotních požadavků¶
Všichni souhlasí (team a zadavatel) s tím, že byla zachycena správná skupina vysokoúrovňových požadavků požadavků a všichni jim rozumí
Souhlas s plánováním¶
Všichni souhlasí s cenou a odhadovaným rozvrhem práce
Souhlas rizik¶
Byla zjištěna rizika, posouzena a byly nalezeny vhodné strategie jejich řešení
Souhlas s procesem¶
Agile Unified Proces (nebo RUP) byl vytvořen a odsouhlasen všemi
Proveditelnost¶
Projekt dává smysl z obchodního, ekonomického, technického a operačního hlediska
Plán projektu¶
Jsou vytvořeny adekvátní plány pro další fázi projektu
Vhodnost projektu do portfolia firmy¶
Hodí se projekt do portfolia organizace ? (pro nás zbytečnost)
Zdroj: http://www.ambysoft.com/unifiedprocess/aup11/html/milestones.html#LCO
Možnost 3 - CW
Milník ukončující fázi Elaboration. Jeho dosažení nejčastěji podmiňuje stabilizace popisu projektu a požadavků na finální systém, provedení výběru vhodné architektury a její ověření, příprava na implementaci systému (všechno je již nastaveno, stačí začít psát kód), a finalizace Vize projektu a sepsání dokumentu Architektura.
Vize produktu
doménový či datový model
model nasazení
model či prototyp uživatelského rozhraní, zákazníkovi předvedený
prvotní soupis požadavků
fungující bugtracker, úložiště, komunikční prostředky v týmu
Dokument vize¶
Obvyklé části¶
historie revizí
stránka s podpisy
úvod
důvod vytváření projektu
rozsah projektu
co dokument vize řeší
business potřeby nebo požadavky
náhled problému a řešení
hlavní vlastnosti (volitelné)
definice uživatelů a všech lidí, kteří budou mít s projektem co dočinění
detaily rozpočtu
úvahy
definice
detaily procesu
Zdroj: https://en.wikipedia.org/wiki/Vision_document
Vhodné kroky při vytváření dokumentu vize¶
Definice business šancí na úspěch
Ukázání výhod a pozitivních věcí získaných po dokončení projektu.
Definice problému
Vyjasnění problému, který projekt bude řešit. Jeho popis, důsledek a očekávání od úspěšně vyřešeného problému.
Identifikace stakeholderů a uživatelů
Zjištění všech lidí, kteří budou mít s projektem co do činění, rozdělení do skupin. I lidi, na které to bude mít negativní dopad. Uživatelé, programátoři,...
Sumarizace potřeb stakeholderů a uživatelů
Po zjištění uživatelů a stakeholderů a jejich rozdělení do skupin musí dojít k nalezení jejich požadavků a potřeb.
Vytvoření přehledu produktu
Zjištění rozsahu projektu (systému) a jeho rozhraní s ostatními lidmi. Lze pomocí digramu, kde každá skupina uživatelů bude mít závislosti s vytvářeným systémem a kde bude zakreslen průběh informací.
Definice vlastností produktu
Podle požadavků stakeholderů lze vytvořit vysokoúrovňové vlastnosti produktu, které budou splňovat požadavky. Každá vlastnost by měla popisovat funkčnost v systému, která bude řešit jeden nebo více požadavků.
Seznam úvah a omezení
Seznam úvah do budoucnosti, které by mohli ovlivnit vizi. Seznam limitací.
Definice požadavků na dokumentaci
Podle složitosti problému navrhnout rozsah dokumentace. Manuály, návody, README,...
Vzor dokumentu vize a další odkaz¶
Template: http://www.startupcto.com/templates/software-vision-document-template
Další odkaz: https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html
Obsah datového či doménového modelu¶
Definice doménového modelu¶
Doménový model je strukturovaná vizuální reprezentace propojených konceptů, nebo reálných objektů, který spojuje slovní zásobu, klíčové koncepty, chování a závislosti všech svých entit.
Další informace¶
Lze popsat UML diagramem. Popisuje objekty a jejich chování a závislosti.
Zdroj: https://medium.com/@olegchursin/a-brief-introduction-to-domain-modeling-862a30b38353
Zdroj: https://en.wikipedia.org/wiki/Domain_model
Data model¶
Popis dat v systému (software) a jejich závislostí a vazeb mezi nimi. Pomáhá zjistit, co se musí ukládat v systému a jak to ukládat.
Obsah prvotního soupisu požadavků¶
Artefakty¶
prvotní doménový model
UI model
omezení
Data Flow Diagram
Use Case Diagram
vlastnosti
technické požadavky
a další
Zdroj: http://agilemodeling.com/essays/agileRequirements.htm#InitialRequirementsModeling
Další info: https://en.wikipedia.org/wiki/Requirements_analysis
Aktualizováno uživatelem Michal Linha před více než 4 roky(ů) · 14 revizí