Diagram procesních dat - Process-data diagram

Diagram procesních dat

A diagram procesních dat (PDD), také známý jako diagram procesu dodání je diagram který popisuje procesy a data které fungují jako výstup těchto procesů. Na levé straně je metaprocesní model lze zobrazit a na pravé straně ikonu meta-datový model lze zobrazit.^[1]

Na diagram procesních dat lze pohlížet jako na kombinaci a model obchodního procesu a datový model.

Přehled

Diagram procesních dat implementace SAP

Diagram procesních dat, který je zobrazen vpravo, poskytuje přehled všech těchto aktivit / procesů a výstupů. Čtyři šedé rámečky zobrazují čtyři hlavní implementace fáze, které každá obsahuje několik procesů, které jsou v tomto případě všechny sekvenční. Krabice vpravo ukazují všechny výstupy /koncepty které jsou výsledkem procesů. Krabice bez stínu nemají žádné další dílčí koncepty. Krabice s černým stínem zobrazují složité uzavřené koncepty, tedy koncepty, které mají subkoncepty, které však nebudou podrobněji popsány. Krabice s bílým stínem (rámeček za ním) zobrazují otevřené uzavřené koncepty, kde jsou subkoncepty rozbaleny podrobněji. Čáry s diamanty ukazují vztah mezi koncepty.

The Implementace SAP proces je tvořen čtyřmi hlavními fázemi, tj. přípravou projektu, kde se vytváří vize budoucího stavu řešení SAP, fází dimenzování a plánování, kde softwarový zásobník je získán a výcvik probíhá fáze funkčního vývoje a nakonec fáze poslední přípravy, když je poslední testy jsou prováděny před skutečným spuštěním. Pro každou fázi jsou řešeny zásadní činnosti a výstupy /produkty jsou vysvětleny.

Stavební bloky diagramu procesních dat

Postupné činnosti

Sekvenční činnosti jsou činnosti, které je třeba provádět v předem definovaném pořadí. Aktivity jsou propojeny šipkou, což znamená, že je třeba je sledovat v tomto pořadí. Činnosti i dílčí činnosti lze modelovat sekvenčním způsobem. Na obrázku 1 je ilustrován diagram aktivity s jednou aktivitou a dvěma sekvenčními dílčími aktivitami. Zvláštním druhem sekvenčních aktivit jsou stavy spuštění a zastavení, které jsou také znázorněny na obrázku 1.

Na obrázku 2 je znázorněn příklad z praxe. Příklad je převzat z pracovního postupu zachycení požadavků ve webovém inženýrství založeném na UML. Hlavní aktivita, modelování uživatelů a domén, se skládá ze tří aktivit, které je třeba provést v předem definovaném pořadí.

1: Postupné činnosti
2: Příklad
3: Neuspořádané aktivity
4: Příklad

Neuspořádané aktivity

Neuspořádané aktivity se používají, když dílčí aktivity aktivity nemají předem definovanou sekvenci, ve které je třeba je provádět. Uspořádat lze pouze dílčí aktivity. Neuspořádané aktivity jsou reprezentovány jako dílčí aktivity bez přechodů v rámci aktivity, jak je znázorněno na obrázku 3.

Někdy se aktivita skládá z postupných i neuspořádaných dílčích činností. Řešením tohoto problému modelování je rozdělení hlavní činnosti do různých částí. Na obrázku 4 je znázorněn příklad, který objasňuje nutnost umět modelovat neuspořádané aktivity. Příklad je převzat z pracovního postupu analýzy požadavků Unified Process. Hlavní aktivita, „popsat požadavky kandidátů“, je rozdělena do dvou částí. První část je postupná aktivita. Druhá část se skládá ze čtyř činností, které ke správnému provedení nepotřebují žádnou sekvenci.

Souběžné činnosti

Činnosti mohou probíhat souběžně. To se řeší rozdvojením a spojením. Kreslením aktivit paralelně v diagramu, spojeným se synchronizačním pruhem, lze rozvětvit několik aktivit. Později se tyto souběžné aktivity mohou znovu připojit pomocí stejné synchronizační lišty. Mohou nastat souběžně činnosti i dílčí činnosti. V příkladu na obrázku 5 jsou aktivity 2 a aktivity 3 souběžné aktivity.

Na obrázku 6 je znázorněn fragment procesu zachycování požadavků. Souběžně jsou prováděny dvě činnosti, definování aktérů a definování případů použití. Důvodem pro současné provádění těchto činností je to, že definování aktérů velmi ovlivňuje případy použití a naopak.

5: Souběžné činnosti
6: Příklad
7: Podmíněné činnosti
8: Příklad

Podmíněné činnosti

Podmíněné činnosti jsou činnosti, které se provádějí, pouze pokud je splněna předem definovaná podmínka. To je graficky znázorněno pomocí větve. Větve jsou ilustrovány diamantem a mohou mít příchozí a odchozí přechody. Každý odchozí přechod má strážný výraz, podmínku. Tento strážný výraz je ve skutečnosti booleovský výraz, který se používá k výběru, kterým směrem se vydat. Činnosti i dílčí činnosti lze modelovat jako podmíněné činnosti. Na obrázku 7 jsou znázorněny dvě podmíněné aktivity.

Na obrázku 8 je znázorněn příklad z praxe. Analýza požadavků začíná studiem materiálu. Na základě této studie je rozhodnuto, zda provést rozsáhlou relaci vyvolání požadavků nebo ne. Podmínka neprovedení této relace požadavků je představována nalevo od větve, jmenovitě [požadavky jasné]. Pokud tato podmínka není splněna, [else], následuje druhá šipka.

Integrace obou typů diagramů je docela přímá. Každá akce nebo aktivita vyústí v koncept. Jsou spojeny tečkovanou šipkou k vyprodukovaným artefaktům, jak ukazuje obrázek 9. Koncepty a aktivity jsou na tomto obrázku abstraktní.

Obrázek 9: Diagram procesních dat

V tabulce 1 je uvedena obecná tabulka s popisem činností, dílčích činností a jejich vztahů k pojmům. V části 5 jsou uvedeny příklady diagramu procesních dat a tabulky aktivit.

Aktivita	Dílčí aktivita	Popis
Aktivita 2	Dílčí aktivita 4	Výsledkem dílčí aktivity 4 je STANDARDNÍ KONCEPCE

Tabulka 1: Tabulka aktivit

Příklad diagramu procesních dat

Na obrázku 10 je znázorněn příklad diagramu procesních dat. Jedná se o příklad z fáze orientace komplexního projektu metodou WebEngineering.^[1]

Pozoruhodné je použití otevřených a uzavřených konceptů. Jelikož projektové řízení ve skutečnosti nespadá do rozsahu tohoto výzkumu, koncept CONTROL MANAGEMENT nebyl rozšířen. V komplexním projektu je však RIZIKOŘÍZENÍ velmi důležité. Proto je rozhodnuto rozšířit koncept RISK MANAGEMENT.

Obrázek 10: Příklad diagramu procesních dat - fáze orientace v komplexním projektu

V tabulce 2 jsou popsány aktivity a dílčí aktivity a vztah k konceptům.

Aktivita	Dílčí aktivita	Popis
Popište projekt		Popis projektu se provádí z hlediska účastníků, cílů, produktů, rozsahu a předpokladů. Tyto informace jsou odvozeny z návrhu, ale s větším důrazem na otázky řízení projektu. Aktivita končí projektem POPIS.
Plánování konstrukce	Popište fáze projektu	PLÁNOVÁNÍ je rozděleno do pěti PROJEKTOVÝCH FÁZE, které by měly být krátce popsány.
Plánování konstrukce	Popište činnosti	AKTIVITY projektu jsou popsány a seskupeny do PROJEKTOVÝCH FÁZE.
Plánování konstrukce	Popište výstupy	Jsou popsány VÝSLEDKY, které vyplývají z projektu AKTIVITY.
Plánování konstrukce	Nastavit plán	Pro každý DODÁVATELNÝ údaj je stanoven DATUM a pro každou AKTIVITU je odhadován ČASOVÝ AUTOMAT.
Kontrolní projekt		Výsledkem ovládání projektu je artefakt CONTROL MANAGEMENT. Tento artefakt zde není dále vysvětlen, protože se týká pravidelných problémů se správou projektů, jako je správa komunikace, řízení pokroku, správa změn a správa problémů, které leží mimo rozsah tohoto výzkumu.
Kontrolní riziko	Identifikujte rizika	Identifikace rizik lze provést pomocí standardních kontrolních seznamů nebo uspořádáním seminářů o rizicích. RIZIKA jsou zahrnuta v PROJEKTOVÉM PLÁNU.
Kontrolní riziko	Vyhodnoťte rizika	Každé RIZIKO je opatřeno HODNOCENÍM; je uveden popis a odhad složitosti nebo nejistoty projektu.
Kontrolní riziko	Analyzujte dopad	Při analýze dopadu rizik na dopady má riziko na úspěch projektu. Hodnoty hodnocení a rizika jsou označeny výběrem hodnoty: nízká, střední nebo vysoká.
Kontrolní riziko	Upřednostněte rizika	Stanovení priorit rizik se provádí kombinací DOPADU a HODNOCENÍ v tabulce. Vysoká priorita je pak dána RIZIKŮM s nejvyššími skóre.
Definujte opatření pro strategii rizik		Opatření ke strategii rizika lze získat ze zkušeností nebo z relevantní literatury. Manažer projektu přizpůsobuje akce projektu v SEZNAMU AKCÍ PRO STRATEGII RIZIK. RIZIKA s nejvyšší prioritou jsou na vrcholu seznamu a je třeba s nimi zacházet jako první.

Tabulka 2: Činnosti a dílčí činnosti ve složité orientační fázi

Viz také

Reference

^ ^A ^b I. Van de Weerd, J. Souer, J. Versendaal a Sjaak Brinkkemper (2005). Inženýrství situačních požadavků implementací správy webového obsahu. SREP2005.

[WSVB-1] A ^b I. Van de Weerd, J. Souer, J. Versendaal a Sjaak Brinkkemper (2005). Inženýrství situačních požadavků implementací správy webového obsahu. SREP2005.

[1]