Tipl bych, že FEI VŠB-TUO - tento příspěvek mi nápadně připomíná borce, který tento týden přesně na tomto vyletěl od inženýrských státnic.
Drobný rejpanec: UserStory není UML diagram - ta otázka od té ženské prý byla na UML diagramy.
Nicméně UserStory i UseCase samozřejmě patří do sběru požadavků (obecně UserStory u agilních metodik, UseCase u OpenUP a RUP).
UseCase je textový dokument s přesně definovanými náležitostmi (viz příklad:
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html ); UseCase UML diagram zobrazuje pouze vztahy aktéři <-> případy užití a mezi případy užití samotnými, ale scénáře samotných případů užití nikoliv.
Samufaj: Dá se tam kromě UseCase diagramu (který se AFAIK může a nemusí dělat) použít i diagram aktivit. Sekvenční bych jim osobně řekl že ne, že to je spíš do návrhu.
V praxi platí, že pokud Ti pomůže v komunikaci se zákazníkem, tak ho udělej - pokud popisuješ business procesy pomocí UML, tak ten sekvenční lze použít (viz např. předmět MSPS). Jenomže škola není praxe a p*ča co v životě neviděla reálný projekt k tomu bude přistupovat jinak. Zkus zajít za Štolfou, který má vlastní firmu a slušnou praxi, ale ptej se ho na konkrétní otázky - je to totální bordelář a jeho studijní materiály, výklady, projev i přednášky se vyznačují extrémně vysokou mírou entropie
, což ale asi víš. Z odpovědi na obecnou otázku se nedozvíš nic, ale konkrétní otázky jsou v pohodě a fakt dokáže pomoct. (Měl jsem ho jako vedoucího diplomky ... no chvilu mi trvalo, než jsem si na jeho styl zvykl.)
Jinak Štolfa by IMHO na tuto otázku chtěl slyšet odpověď něco v tom smyslu, že výstupem fáze definice požadavků jsou artefakty (to slovo "artefakt" je pro něj důležité), které jsou v řádku "outputs" v tabulce v tomto dokumentu:
http://epf.eclipse.org/wikis/openup/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements_90D272B9.html?nodeId=e1fcc9d0On je hodně zatížený na OpenUP, celý ten framework i s dokumentací najdeš tady:
http://epf.eclipse.org/wikis/openup/Je na to možno koukat jako na trochu odlehčenou (a bezplatnou) verzi Rational Unified Process a lze s tím pracovat i bez drahého a nákladného školení, nicméně se hodí jen pro menší týmy. Jo a není to agilní metodika, tam to probíhá jinak.
Petriho sítě jsem nikde při samotném vývoji softwaru neviděl použité. Ale při vývoji, validaci a optimalizacích byznys procesů ano - na základě takto optimalizovaných procesů můžeš vyvinout řídící software nebo informační systém. Těžko říct, jestli to u státnic zmiňovat či nikoliv.
37 Odpovědí
179215 Zhlédnutí