Content deleted Content added
Wikification, some more |
m Removing link(s) Wikipedia:Articles for deletion/SAP implementation closed as delete (XFDcloser) |
||
| (30 intermediate revisions by 21 users not shown) | |||
Line 1:
[[
A '''process-data diagram (PDD)''', also known as '''process-deliverable diagram''' is a [[diagram]] that describes [[process (computing)|process]]es and [[data]] that act as output of these processes. On the left side the [[meta-process model]] can be viewed and on the right side the [[metadata modeling|meta
A process-data diagram can be seen as combination of
== Overview ==
Line 8:
The process-data diagram that is depicted at the right, gives an overview of all of these activities/processes and deliverables. The four gray boxes depict the four main [[implementation]] phases, which each contain several processes that are in this case all sequential. The boxes at the right show all the deliverables/[[concept]]s that result from the processes. Boxes without a shadow have no further sub-concepts. Boxes with a black shadow depict complex closed concepts, so concepts that have sub-concepts, which however will not be described in any more detail. Boxes with a white shadow (a box behind it) depict open closed concepts, where the sub-concepts are expanded in greater detail. The lines with diamonds show a has-a relationship between concepts.
The
== Process-data diagram building blocks ==
=== Sequential activities ===
{{main article|Activity diagram}}
Sequential activities are activities that need to be carried out in a pre-defined order. The activities are connected with an arrow, implying that they have to be followed in that sequence. Both activities and sub-activities can be modeled in a sequential way. In Figure 1 an activity diagram is illustrated with one activity and two sequential sub-activities. A special kind of sequential activities are the start and stop states, which are also illustrated in Figure 1.
In Figure 2 an example from practice is illustrated. The example is taken from the requirements capturing workflow in UML-based Web Engineering. The main activity, user & ___domain modeling, consists of three activities that need to be carried out in a predefined order.
Image:
Image:
Image:
Image:
</gallery>
Line 27 ⟶ 28:
Unordered activities are used when sub-activities of an activity do not have a pre-defined sequence in which they need to be carried out. Only sub-activities can be unordered. Unordered activities are represented as sub-activities without transitions within an activity, as is represented in Figure 3.
=== Concurrent activities ===
Activities can occur concurrently. This is handled with forking and joining. By drawing the activities parallel in the diagram, connected with a synchronization bar, one can fork several activities. Later on these concurrent activities can join again by using the same synchronization bar. Both activities and sub-activities can occur concurrently. In the example of Figure 5, Activity 2 and Activity 3 are concurrent activities.
In Figure 6, a fragment of a requirements capturing process is depicted. Two activities, defining the actors and defining the use cases, are carried out concurrently. The reason for carrying out these activities concurrently is that defining the actors
Image:
Image:
Image:Process-Data Diagram 27.gif|7: Conditional activities
Image:Process-Data Diagram 28.gif|8: Example
Line 46 ⟶ 47:
In Figure 8 an example from practice is illustrated. A requirements analysis starts with studying the material. Based on this study, the decision is taken whether to do an extensive requirements elicitation session or not. The condition for not carrying out this requirements session is represented at the left of the branch, namely [requirements clear]. If this condition is not met, [else], the other arrow is followed.
The integration of both types of diagrams is quite straightforward. Each action or activity results in a concept. They are connected with a dotted arrow to the produced artifacts, as is demonstrated in Figure 9. The concepts and activities are abstract in this picture.
::[[Image:Mm41.gif|frame|left|Figure 9: Process-Data Diagram]]
In Table 1 a generic table is presented with the description of activities, sub-activities and their relations to the concepts. In section 5 examples are given of both process-data diagram and activity table.
Line 67:
== Example of a process-data diagram ==
In Figure 10 an example of a process-data diagram is illustrated. It concerns an example from
Notable is the use of open and closed concepts. Since project management is actually not within the scope of this research, the concept CONTROL MANAGEMENT has not been expanded. However, in a complex project is RISK MANAGEMENT of great importance. Therefore, the choice is made to expand the RISK MANAGEMENT concept.
::[[
In Table 2 the activities and sub-activities, and relation to the concepts are described.
Line 129:
== See also ==
{{
* [[Acquisition Initiation (ISPL)]]
* [[Change management (engineering)]]
* [[Dynamic Systems Development Method]]
* [[ITIL Security Management]]
* [[Implementation Maturity Model Assessment]]
Line 140 ⟶ 139:
* [[Object Process Methodology]]
* [[PREview]]
* [[Product Family Engineering]]
* [[Product Structure Modeling]]
* [[Synchronization model]]
Line 146 ⟶ 145:
== References ==
{{reflist}}
{{
{{DEFAULTSORT:Process-Data Diagram}}
[[Category:Diagrams]]
[[Category:Systems engineering]]
| |||