Process-data diagram: Difference between revisions

Revision as of 16:45, 18 July 2013

Revision as of 17:21, 31 January 2015

Line 1:

[[File:Process-Data Diagram 01.jpg|thumb|360px|right|The process data diagram]]

A '''process-data 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 meta concept model can be viewed.<ref name="WSVB">I. Van de Weerd, J. Souer, J. Versendaal and [[Sjaak Brinkkemper]] (2005). ''Situational Requirements Engineering of Web Content Management Implementations''. SREP2005.</ref>

A process-data diagram can be seen as combination of an [[business process model]] and [[data model]].

Line 11:

== Process-data diagram building blocks ==

=== Sequential activities ===

{{main|Activity diagram}}

Line 32 ⟶ 33:

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 influences the use cases greatly, and vice versa.

::<gallery>

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.

== Process-data diagram ==

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]]<br {{clear=|left>}}

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 71:

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.

::[[File:Process-Data Diagram 41.gif|frame|left|Figure 10: Example Process-Data Diagram - Orientation phase in a complex project]]<br {{clear=|left>}}

In Table 2 the activities and sub-activities, and relation to the concepts are described.