International Software Process Association (ISPA)

author(s):	Kurt Walk, Richard Messnarz
title:	Object Oriented Modeling of Work Processes
organisation(s):	IBM Austria, ISCN Ltd.
copyright:	ISCN Ltd.

Object Oriented Modeling of Work Processes

The formal modeling of work processes is gaining increasing significance for the analysis of organizations with respect to their efficiency and the quality of the products delivered and services rendered. Besides being the basis for the comparison of organizations and for planning improvement, process models allow insights into the roles of people in an organization, and also in the views participating people may have of their work environment. An adequate notion of 'process' should therefore be selected with care, in order to provide a common, firm basis for modern analysis of work environments.

Informal process descriptions may somehow be adequate as long as they are just the means of communication among people. However, in particular for designing computer services for the support of work processes, a precise notion of 'process' is required. Many notational systems for the modeling of processes are in use, which are mostly variants of an activity centered approach (Hump89). In contrast, a strictly object-oriented foundation is being proposed here.

The development of computer services is itself a rather demanding work process. It is, actually, more complex than many other types of processes like, for example, administrative processes. As a goal, we specifically want to describe software development processes with methods built on a firm architectural basis, usable in actual practice, and detailed enough for the design of support environments.

Software development, like most other work processes, exhibits the general characteristics that:

• certain activities have to be performed in a certain sequence
• there are points where activities need to be synchronized
• production activities are often followed by check and repair activities, which causes loops in the process.

Further analysis, however, reveals more properties of work processes, which must find adequate representation in process descriptions: ctivities are performed by people in different roles. Roles differ in the type of activities, the services used, the required access to information, levels of authorization, besides, of course, requiring different skills. The specification of the roles of people participating in a process must be a part of the process models.

People are related to one another in various ways by customer-supplier arrangements, communication channels, or management structures. We need to model these relationships.

Activities are either assigned to people by the process, or people take the initiative to assume activities in conformance with the process rules. The level of freedom left to people participating in a process is an important aspect of process design.

Work processes - and software development processes in particular - are accompanied continually by change. Backward changes (caused by the discovery of problems in the course of development) as well as forward changes (caused by new insights or new requirements) impact work already performed.

Processes do interact. One person may be involved in a production process, a planning process, a change process, and a personnel process, all at the same time.

The proceedings of a process in general are determined by the combined effects of: a central control agent (which may be a person or an automated service), the logic inherent in the work objects (for example: a source program module must be compiled before it can be executed), and the choices and decisions made by the people participating in the process.

A process is the behavior of a system. The above characteristics suggest the use of a system architecture of active, uniquely named objects, cooperating asynchronously by exchanging stimuli.

A system representing work processes typically is constructed from objects representing 'work objects' and the access paths to the work objects, from objects representing central control agents, and from objects representing users' work places:

In the above figure, circles represent objects, and the arrows indicate that objects are 'associated', meaning that they may exchange stimuli.

Work objects model the items on which work is performed in the processes. They usually undergo a history of change through various states, from creation to destruction. State transition diagrams, specifying the permissible transitions from states to states can be used for modeling the logic inherent in the work objects (HuKe89, ShMe92). Directory objects model the access paths to the work objects, specifying naming, access authorization, and search mechanisms. Work objects in certain states may directly represent 'work to be done': an object in state 'incomplete' represents work to be done for getting it into the state 'complete'. A change process then may reset the status to 'incomplete', reopening work assignments in a controlled way.

Control objects interact with work places and with work objects, assigning work to be done to people, calling services to be performed, and receiving feedback from user activities and from service calls. They model the logic of the work flow in processes. They can be candidates for being implemented by work flow management systems (Walk94).

Work places model the interfaces to the people interacting with the system, receiving user input and displaying system output. They are associated with the various other system components with which the work place user may interact. The type of work place corresponds to the roles the user plays in the work processes. A work place may contain information controlling user identification and authorization (in 'user objects'), as well as objects making dialog, display and view capabilities available to its user. In particular, it may also contain (and display) work objects, which represent 'work to be done' by the user. They play the role of real work objects populating a work bench, being at disposal to the user, and representing the current status of work at any point in time. Relationships between people are modeled as relationships between their work places.

Object systems designed in the way sketched above allow the modeling of interacting processes. System components are loosely coupled by asynchronous communication and may respond to stimuli from various different sources in a controlled way. A work place, for example, may receive information and requests for work from a number of different processes. It is possible in this way also to model the interference of a development process with a process requesting changes and causing work to be partially redone.

Modeling work processes means designing an object system. Modeling in general starts with the analysis of scenarios (also called 'use cases', see (Jaco92) and others) with the aim to identify the user roles of concern, the work object types, the associations between the objects, the life cycle of objects, and the work places corresponding to the user roles. Part of this analysis is the question: who creates an object, and who destroys it?

Process models can gradually be extended by adding more detail to the description of object properties, by designing the stimuli carrying information between objects, and by adding more objects of concern. Since objects are loosely coupled by asynchronous communication, refinement of different system components may proceed quite independently over longer periods of modeling activity.

A case study performed for a middle-sized Austrian company confirmed the benefits of the architectural approach. The members of a software development team actively participated in the modeling and improvement of their work processes. They were motivated to cooperate as their roles in the model were clearly identifiable and comprehensible and it also was possible to model a multifunctional team structure (one person playing several roles).

Table of Contents