GDPA  
Event-based Model  

A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z

Identification

Event-based Model

Definitions/Uses

1998
Reference /Wolf, 1993a/ A Study in Software Process Data Capture and Analysis
Definition/
Use
The figure above depicts the fundamental notion of events and events intervals, and their correspondence with process activities. The figure depicts three different activities, which are carried out in parallel by one or more persons or machines as a part of a software process. The heavy, solid bars denote the period of time during which separate instances of the activities occur.

An event is an instantaneous happenstance that occurs during an activity as a specific, identifiable point in time, events are depicted in Figure 1 as solid circles. An event interval is the period of time between a pair of events. Any arbitrary pair of events can potentially define an interesting event interval. To date, we have found four kinds of event intervals to be particularly useful in process analysis.

  • Events occurring within a single instance of a particular activity. (e.g. BEGIN, END)
  • The complement of the event interval characterizing an instance of an activity
  • Period of time throughout a sequence of instances of an activity
  • The interval between events of different activities
Events occurring within a single instance of a particular activity. (e.g. BEGIN, END)
The first of these involves the events occurring within a single instance of a particular activity. Two special kinds of events are the beginning and ending events, which we refer to as BEGIN and END events, respectively. Figure 1 illustrates this kind of interval for the instance of activity A carried out between the BEGIN and END events at times t5 and t7. The BEGIN/END interval is intended to indicate the period of time during which the main purpose of the activity is being carried out. For some activities, however, this main period may be preceded by an initial setup period and/or followed by a final wrapup period. It is often desirable to keep such setup and wrapup intervals as short as possible. Consider, for example, a meeting. The time between the scheduling of the meeting and the actual beginning of the meeting is the setup period. After the end of the meeting a record of the meeting is generated and distributed during the wrapup period. In a sense, the meeting activity spans these setups and wrapup time periods. The instance of Activity B in Figure 1 illustrates this klind of activity, with the event interval associated with the activity extending from the SETUP event at time t4 to the WRAPUP event at time t9.

The complement of the event interval characterizing an instance of an activity
The second kind of event intervals is the complement of the event interval characterizing an instance of an activity. In particular, it is the period of time between the last event of one instance of the activity and the first event of the next instance of that same activity. Such event intervals are often indicators of idle, and possibly wasted, time. Figure 1 illustrates this kind of interval between the END event of the second instance of Activity A at time t7 and the BEGIN event at the third instance of Activity A at time t8.

Period of time throughout a sequence of instances of an activity
The third kind of event interval corresponds to the period of time throughout a sequence of instances of an activity. For instance, an activity that must be repeated until some goal has been met can be characterized by the interval between the first event of the first instance of the activity and the last event of the last instance of that activity; such an interval characterizes the amount of time needed to achieve the goal associated with the activity. Figure 1 illustrates this kind of interval between the BEGIN event of the first instance of the Activity A at time t1 and the END event of the third instance of Activity A at time t10.

The interval between events of different activities
The fourth kind of event interval is an interval between events of different activities. This kind of interval typically corresponds to the time taken between sequential steps in a process. Figure 1 illustrates this kind of interval between the END event of the first instance of Activity A at the time t2 and the SETUP event of Activity B at time t4.

While in our experience most activities involve multiple events, there are some activities that are considered to occur instantaneously and thus have a single event associated with their instances. We refer to the event of an instantaneously occurring activity as a DO event, as illustrated in the figure by the instances of Activity C at times t3 and t7.

Event Taxonomy
In order to provide a more insightful event-based characterization of some process of interest, and to provide a richer level of detail in the information that is captured about that process, we have designed a general taxonomy of events characterizing the different activities that are carried out in a software process. The taxonomy comprises six categories of events:

  • 1. communication events;
  • 2. automation events;
  • 3. analysis events;
  • 4. work events;
  • 5. workday events; and
  • 6. decision events.
An instance of this taxonomy for a particular process will contain a number of event kinds within each category characterizing the particular activities of that process.

The first category of events is communication events. Communication plays a central role in large processes, for it is primarily through coordination of a sizeable and sometimes geographically dispersed group of people that large software systems are built. An instance of a communication activity can be characterized by the period of time between its initiation (the BEGIN event) and termination (the END event).Several kinds of communication may take place before actual communication between humans can occur.; for instance, it may be necessary to leave voice-mail messages when some intended parties to a communication are unavailable. For clarity, we further identify the BEGIN events and communications intervals as either BEGIN-Send events or BEGIN-Receive events.

The second category of events is automation events, which demarcate intervals of activity in which a computer performs some task, such as compilation. In some cases, an automation activity is instantiated by a setup procedure to prepare the computer for the automation task. For instance, job requests may be placed in a queue in order to allocate computer resources more efficiently. In this case, the instances of the automation activity would be characterized by an interval starting with a SETUP event (denoting the beginning of the period during which the job is in the queue), followed by a BEGIN event (denoting the beginning of the requested-task), and followed finally by an END event (denoting the completion of the task). Some automation activities may be terminated before they would complete normally. Thus, we further identify the END events of automation intervals as either END-Normal events or END-Abort events.

The next three categories of events are straightforward characterizations of process activities carried out over intervals between corresponding pairs of BEGIN and END events. Analysis events identify intervals in which the results of a previous process chore are analyzed for validation or problem resolution; typical analysis event intervals correspond to code inspections, debugging sessions, and the like. Work events identify intervals in which a person is performing tasks such as fixing code, writing documentation, mounting a tape, and so on. Workday events correspond to times at which a person stops or resumes work in the process; typical workday events include arriving at work, going to lunch, starting work on some other assignment related to the process, and so on.

The final category of events is decision events. Decision events correspond to a person synthesizing the results of a number of previously completed activities and using information about those results to select from a set of possible new activities to begin. Decision events are extremely sensitive to their inputs (i.e., the results of previous activities) and can thus provide a great deal of information about the efficiency of a process. For example, a decision may be made based on information gleaned from previously completed analysis intervals and in anticipation of an imminent workday event. Retrospective analysis can reveal where additional information could have led to a better decision. Decisions are considered to be made instantaneously and are thus characterized by a single DO event rather than by an event interval.

Related terms in the glossary

Process Operators
Process Plan

Publications on this area

Plan-based process

This page online  •  GDPA Online  •  Last Updated 16.June.2002 by C. Freericks