Software Process Modeling and Enactment:
An Experience Report related to Problem Tracking in an Industrial Project
|Volker Gruhn||Juri Urbainczyk|
|University of Dortmund||Open Software Associates|
|Computer Science||Mainzer Landstrasse 82-84|
|44221 Dortmund||60489 Frankfurt|
|++ 49 (0) 231 755 2782||++49 (0) 69 7896 0145|
In this article we discuss our experience in applying software process modeling and enactment to a real-world software process. This software process covers problem tracking for a large information system. The problem tracking process is modeled with FUNSOFT nets (high-level Petri nets) and it is enacted. The enactment is based on a commercial workflow management system, called LEU. The software process discussed is a distributed one. Certain activities are carried out at the software house, others are carried out at customer sites. The experience discussed is put into relation to the last decade of software process research. We point out which promises of the software process community have been be kept, which may be kept and which seem overemphasized from our point of view. Based on our experience, we discuss which research directions in software process research seem promising for the future.
software process technology, workflow management, FUNSOFT nets, problem tracking
1 State of Software Process Research
A lot of attention is paid to software process modeling and enactment in software process research community. There are regular European workshops on software process technology , there are International Software Process Workshops, there is a series of International Conferences on the Software Process  and most conferences on software engineering spend one or several sessions on software process issues. The focus of this mainly academic research work has changed over time. While the late 80ies were determined by the question whether or not software process models should be considered programs  or if they are too much dependent on human interaction and creativity as if they could be managed as programs , the early 90ies basically focused on the question what a suitable software process modeling language should look like. A number of languages following different language paradigms were proposed. The most prominant representatives of such languages include rule-based, [12,18,23] Petri-net-based [1,7] and object-oriented languages[11,16].
The most recent years show another trend: the software process community is ready to accept that there is room for many process modeling languages and there is an emerging consensus that graphical process modeling would help to alleviate process modeling for non-language experts. At the same time, we recognize a research emphasis on software process evolution issues. While the need for software process evolution has been recognized early [3,5] the community seems now ready to accept what M. Lehman and L. Belady have proposed already in 1985 : software processes are complex entities which are inherently evolution based. This means, evolution of process models is not due to planning errors or unexpected technology shifts, but due to the fact that software processes have an impact on their surrounding and that this impact evokes feedbacks and thereby process model modifications. Another trend is to focus on certain activities of the lifecycle for software process models and to point out how these activities are related to the corresponding software engineering activties.
Concurrent to these shifts in software process research, many research groups worldwide have been building prototypes of toolsets supporting software process modeling, software process model analysis and software process enactment. Examples of these environments are ALF , Arcadia , Marvel and its successor Oz , MELMAC , HFSP  and SPADE .
Summing this up, much effort has been spent on software process research and there is some progress. Despite this multitude of prototypes and research groups, the software process research has not had as much impact onto industrial software processes as expected a decade ago (at least as far as actual enaction of industrial software processes based on software process models is concerned). Actually most experience in software process enaction relates to small and somewhat isolated software process experiments, but not to the real-world of industrial software development [10, 15].
2 Applying Software Process Modeling and Enactment in INDUSTRY
In this section we describe our experience of putting an academic prototype of a toolset for software process modeling into practice. Even though this experience is based on only one prototype we assume that our experience in software process technolgy transfer reveals some aspects that are symptomatic for the gap between software process research and industrial software engineering. This assumption is underpinned by the experience made in similar experiments [4, 10].
2.1 Enthusiam (1987-1990)
After building a prototype (the MELMAC system mentioned above) we felt that we knew enough about software processes to improve the real-world. Of course, the prototype was neither stable, nor documented, nor used by anybody else, but there was a deep conviction that the ideas and concepts were great. At that time, most developers and enthusiasts of MELMAC left to a company. There was little doubt that real real-world software processes would urgently demand for formal process modeling and process enactment.
2.2 Frustration (1990 - 1993)
The attempt to model real-world software processes and to even enact them in an industrial setting (a software house with about 400 employees) showed one thing very clearly: MELMAC was in principle powerful enough to model the core of software processes, but it lacked documentation, robustness and other product features, which are usually not implemented in prototypes. Another issue in this phase was that the terminology of software process researchers and software practitioners did hardly overlap. While the software process researchers were used to a terminology built of process, object models, process modeling language, prescriptive and descriptive style of modeling processes, the industrial software developers were communicating in terms of budget overruns, patches for bug fixes and transaction monitors. Thus, it took lengthy discussions and many meetings to agree on some experiments in software process modeling. These experiments essentially showed one thing: the typical software process toy problems discussed in the late 80ies (like the simplified edit/compile/test examples and like the change request examples as discussed at the 6th and the 9th International Software Process Workshop) oversimplified the real-world problems dramatically. Software process support in an industrial setting turned out to suffer most from inappropriate configuration management, from communication problems between developers, customers and sales people, from systematic test approaches and from change management mechanisms.
Looking at these problems, software process enactment was not the most urgent problem. An overall and explicit model of the software process was much more important. Thus, the benefits of software process modeling were obvious. Unfortunately, the requirements for this kind of software process modeling were not fulfilled by most of the process modeling tools available at that time. MELMAC, as a typical representative of this class of tools focused very much on an integrated modeling and enactment. Accordingly, the representations of process models were workflow-engine-understandable, but not very intuitive for human users. Instead of representing the different aspects of software processes (organizational context, structure of object types and documents, involved roles and their permissions) in an intuitive way, all facets of edit-compile-test cycles could be expressed and had a formal semantics definition.
Besides of this mismatch of requirements and tool support, the multitude of exceptions in industrial software processes turned out to be a major obstacle in process modeling. Most of the processes to be modeled were on level 1 or between level 1 and 2 of the CMM . Thus, they were unclear for important parts, interactions between process participants were not explicitly defined. In other words: there was hardly a process idea.
Summing this up, the low maturity of industrial processes and the mismatch between this situation and the enactment focus of software process tools both did not promise a fast return on investment for software process modeling at that time.
2.3 Consolation (1992 - 1996)
Once we recognized that there was little benefit in software process modeling and enactment, we had the opportunity to investigate business process which were to be supported by a new software system. The development of this software system started in 1992. The system to be developed, called WIS, was supposed to support all business processes from the area of housing construction and administration (contract management, accounting, real estate management, repairs, etc.). It was decided to develop this system in a process-oriented way. This means, business processes were modeled, dialogs, reports and other functions were plugged into these models, and the runtime support was created by workflow management on the basis of the business process models. Business process models were described with FUNSOFT nets (as they were implemented in the MELMAC prototype before), by extended entity-relationship diagrams and by organizational diagrams showing who is responsible for what. The experience in the WIS development is described in  in more detail. Since MELMAC suffered from being a prototype, but not a product, a reimplementation was done first. The result, called LEU, is a toolset for process modeling, process model analysis and workflow management .
In the meantime, the WIS is used at several large customers from the housing construction and administration areas. The largest of these customers uses WIS to administrate about 40.000 apartments. LEU as basis of WIS is used at these customers to workflow-manage their everyday administration processes.
2.4 Late Finding (1996 - 1997)
After building and deploying the WIS system in a business process oriented way, we came across one problem: the tracking of errors in WIS and the change request mechanisms for WIS were basically manual processes. Since more and more customers were issuing change requests (at the very beginning of the introduction up to 50 per day and customer), we decided to implement this part of the overall WIS software process in a workflow style based on LEU. This perfectly fits to what is described in . Here it is described that software developers first tend to automate the problem tracking process. Since the deviation to business processes and back to certain parts of software processes eventually means, that software process technology is applied to (parts of) software processes, we describe the support for the problem tracking process in more detail in the following.
3 The Probem Tracking System Example
The implementation and maintenance of the software system WIS must be supported by appropriate software. Most important are a Helpdesk system and a large error data base. Above all the systems main objectives are support and enactment of the processes problem tracking, software configuration management and requirements management. These processes are strongly cooperative and show an extreme repetitiveness. Furthermore all internal business processes (BP) have been examined and described due to the introduction of a quality management system (QMS) for attaining ISO-9000 certification. Therefore they are well defined and documented thoroughly. As a consequence we decided to develop a business process based Problem Tracking System (PTS) using the available LEU environment.
The main requirements for the new system are as follows:
By introducing the new software-based and business-process-oriented problem tracking system we intend to make the life cycle of the problem reports visible and understandable. Information on the problem reports currently processed must be available for everyone at any time. This would make it easy to decide whether a problem has already been registered or even been solved lately. Inquiries of customers concerning the state of the problem solving process and concerning the duration could be answered faster. The effort for registering an error shall be essentially decreased and the process made much less error-prone. The latter will be achieved by consistency checking functions, that are located in the dialogs and prevent bad data from being inserted. Some activities could even be made automatic, like the printing of customer letters. Therefore the duration of the problem solving process should decrease.
In the context of LEU a project consists of object model, organization model and workflow model. These parts of the PTS are described in the following.
3.1 The object model of the PTS
LEU uses an extended entity-relationship-representation for its object model. The main object types of the PTS are Problem Report (PR), Configuration Unit (CU) and Patch. They are connected by n:m-relations (compare picture 1).
Incoming problem messages are stored in instances (objects) of the object type Problem Report. The boolean attribute Internal differentiates between:
Every single problem report is identified by one unique key, which is stored in the attribute Problem Number. The contents of the problem message is stored in the attributes Problem Description, Error Code and Effect of Error. At any time, every problem report has a Person Responsible who is in charge to handle the PR. The name of this employee as well as time and state of the PR are recorded. This means that they are stored in a list, which represents the whole lifetime history of the problem report and can be recalled at any time in order to initiate escalation mechanisms. The attributes State and Result describe the current condition of a Problem Report. State shows the position of the problem report in the business process. Some of the registered problem messages are rather new requirements than errors. This can be documented by setting the Boolean attribute Request to 'True'. Thus, requirements can be managed by the PTS as well.
Picture 1: PTS Object Model
As shown in the entity-relationship-diagram problem reports can be connected to one or more configuration units. Vice versa one configuration unit may be related to a group of problem reports, but it has to belong to one problem report at least. Configuration units come into being as during the work on a problem report the developers have to make changes to the existing software system. Problem Reports can be grouped together to Patches as described by the n:m-relationship. Each patch must have at least one connection to a problem report. Since there is also a relationship between Problem Report and Configuration Unit, every patch can be traced back to its configuration units.
3.2 Organizational model of the PTS
There are five groups participating in the processes connected with the PTS:
Every activity of the business process models can be related to only one of these groups. The PTS presents only those actions to the individual users which are part of their tasks in accordance to their membership in one of the groups.
3.3 Business process models of the PTS
The business process model governs the possible pathways of a problem report through the work flow. Which path is actually chosen depends on the problem report's attribute State. In relation to the current value of the attribute State only certain changes are allowed (compare picture 2). Basically two business processes are supported by the PTS: Acceptance and Maintenance. In addition, there is an email demon process which translates incoming emails into problem reports.
Picture 2: State transition chart for problem reports
The process model Acceptance (compare picture 3) describes the process of inspecting a new software system for acceptance. When the QM finds errors or deviations from the requirements description, this results in an problem report that is passed to the developers. After removing the error the problem report is handed to the QM again, which have to verify the correctness. This cycle may be repeated as often as necessary to achieve the acceptance of the product.
The process model Maintenance (compare picture 4) describes the process of discovering and resolving an error in an existing and already shipped software system. Customers as well as employees can announce a problem to the support group. Eventually the problem reports lead to Patches for the software system which have to be documented and distributed. The QM again tests the patches for acceptance.
Picture 3: Process Model ‘Acceptance’
Business process models are described with FUNSOFT nets . They consist of instances and channels. Channels represent activities. Some activities are manual, they require human interaction. These activities are dialog activities. Other activities can be executed automatically, they are called batch activities. Channels represent information storage devices. They can contain objects (speaking in Petri net vocabulary: they are marked). Instances are shown graphically by using different rectangular symbols. The various types of symbols only serve for visualization and are free of semantic value. Channels are represented by circles. If there is an edge from a channel to an instance, it means, that the instance reads from this channel before it starts. An edge leading from an instance to a channel means, that the instance writes an object into the channel after terminating execution. FUNSOFT nets contain ways of modeling that allow a very dense description of process models. E.g. there are several predefined firing behaviors. One of this is the either-or firing behavior, which gives us the possibility to describe instances that write just in one of many output channels. The other modeling constructs of FUNSOFT nets similarly serve for the intuitively accessible description of process models. Their semantics can be described by a mapping to Predicate/Transaction nets .
Process model ‘Acceptance’
This process model contains six activities four of which can be repeated in a cycle. There is just one channel with problem report type between any two activities. All activities are dialog activities, which means they have to be started by the user from his agenda and open a dialog window when started. In this business process the QM always must be able to create a new problem report. Therefore the activity Create PR has to be in the agenda all the time. Technically speaking, this is achieved by using a control channel in the preset and a copy edge leading from the control channel to the activity. The same technique is utilized to model the activities View PR and Edit PR, which have to be always in the agenda, too. The other instances can only be started and they only appear in the agenda if there are problem report tokens in the channel of their preset.
An OUT-edge connects the last activity Accept PR with the channel in the preset of the activity Handle PR. Thus, an unsolved problem (or a PR with an error in the solution) can be directed back to the development group. The activity View PR may be carried out by every user. This dialog activity enables the user to search for and to view every PR, that was created in this business process, in read only mode. The activity Edit PR may only be started by special users like the system administrator. The authorization system of LEU can be used to define roles and to bind these roles to certain users. The role RoleEditPR which contains the permission to start the activity Edit PR should only be assigned to some dedicated users. Only users having the role QS are allowed to execute the activities Create PR or Accept PR. The activity Handle PR only appears in the agendas of developers. Install PR is reserved for people with the CM role.
Picture 4: Process Model ‘Maintenance’
Process model ‘ Maintenance’
The Maintenance process deals with external problem reports, which are mainly announced by the customer. The process of treating these problem reports results in the creation of patches. Only the activity Inform Customer is automatic. There are six cycles which make it possible to repeat certain parts of the process as often as needed. Depending on the state of the PR the activities Analyze PR, Handle PR and Establish PR Priority can choose to write back a token back into the preset channel. This enables us to execute them repeatedly with one and the same document. The channel Analyze PR is a system channel. LEU uses system channels to exchange data between business processes. In this case the channel is needed in order to import problem reports which arrive via email directly into the maintenance process. Thus, the system channel can as well be filled by the activity Create PR and by an automatic activity in the email batch.
Picture 5: PTS Web Page
The email process model automatically registers problem reports that arrive via email. It is started once and runs until the PTS is shut down. It reads the email file of one special UNIX user and scans the emails for predefined keywords like#DESCRIPTION. The batch generates a problem report from the data found in the email. The state attribute of the PR is set to In Analysis and the support group is set to be in charge of the PR. After that the problem report token is written into the system channel of the postset of the activity. The same system channel can be found in the preset of the activity Analyze PR in the maintenance process. Thus, the incoming PR can be imported into the PTS directly. Since emails are received even when the PTS is off line, there is no danger of losing problem reports. This mechanism offers an ideal interface to customers or consultants, who are not able to log on to the PTS.
Moreover an HTML interface is included. The HTML page shown in picture 5 is available internally and externally. It offers an input form for all relevant attributes, that are necessary to create a new PR. Some attributes are accessible per selection box only, in order to minimize mistakes during conversion. When the Send button is pressed a CGI script generates an email from the data read from the form. The created email contains the correct key words for the batch which reads the email. If the data found in the HTML form is not sufficient, the email is not submitted and an error message is shown. Normally the email is sent to the address which is read by the email batch process. This mechanism offers two new media for problem report input by using just one interface of the PTS.
4 Working with the PTS
The first level support receives problem messages by telephone call, facsimile or email. If the problem is new or unknown to the person responsible, he starts the activity Create PR from his agenda. The dialog mask for filling in a new PR (compare picture 7) appears and the fields for date and time as well as the current person responsible are already set. The system knows who is in charge from the name of the UNIX user who started the activity. Since this activity belongs to the maintenance process, the PR is already marked external, too. When the Create-button is pressed, a new unique problem number is generated. Furthermore the name of the person currently in charge is appended to the history of the problem report together with the current date, time and state. Subsequently the problem report is inserted into the data base. There is no possible mechanism in the PTS to delete a PR from the data base. If the state attribute is set to Archived, the problem report is removed from the process and cannot be edited anymore. The creation of the PR fails, if values for mandatory fields like the problem description are missing. In this case the status line displays an error message showing which information is missing.
Picture 6: Projection from FUNSOFT nets to STDs
If you want to pass a problem report on, its state or the person responsible must be changed. The state attribute of a new PR has the value Created. The state can remain unchanged as long as there are still some fields to be filled or necessary data to be acquired. Once the state is changed to In Analysis the problem report appears in the preset of the corresponding activity. If the name of the employee changes from the start of a dialog to its end, the new person responsible is informed by email.
Thus, the recipient of the email can decide just by looking at the subject, which PR he has to work on and which activity he has to start. Additionally, the body of the email contains the problem description, its last person responsible and the priority.
If there is the possibility to write the PR in different postset channels, the state attribute decides which channel is actually chosen (compare picture 2). State and name may only be changed in accordance with the consistency mechanisms of the PTS. E.g. in the activity Handle PR the state mustn't be changed to Created, In Analysis or to Archived.
5.1 Modeling the PTS
While implementing the first process models of the new PTS, we realized that we needed some kind of state transition diagram (STD) for problem reports in order to get an overview of their behavior throughout the system. We also found a strong connection between the channels in the FUNSOFT nets and the possible states of the problem reports as shown in the STD (compare picture 2). Every channel should contain objects of one state only. As a consequence we analyzed how our process models could be described by a STD (compare picture 6).
This showed that the STD gave a very straight forward representation of the main characteristics of some parts of our process models. E.g. cycles can be seen very intuitively. Furthermore the development of the main object type and the direction of the process can be illustrated easily. Although we went very well with the prescriptive style of description as used in FUNSOFT nets, STD modeling shows advantages when dealing with certain kinds of processes, namely those processes which describe how objects of one type are created and manipulated. It is important to note, that the STD way of modeling tends to lose the process view onto the problem in favor of an constraint-based specification. We believe that modeling with STDs is suitable for:
5.2 Using the PTS
Apparently one of the objectives of the PTS development has been achieved: once a problem report is in the system, it can be requested very fast and comfortably. Furthermore the various enumeration types of the PTS have proven very helpful: type writing errors, which make searching a very difficult task, don't occur anymore. The pathway of the PR through the process can be recalled anytime just by examining the history of its employee in charge, its date and its time. This offers possibilities for analyzing and improving the process. Also problem reports cannot get lost anymore. Formerly every ninth document vanished on the desks of the employees. It is still true that some problems are reported twice or even more. But now it is easier to determine that this is the case. This clearly shows that our decision concerning strict enactment of the PTS was right. These processes are not creative and self-organized but rather repetitive and simple. Thus, the strict enactment is the best way of enactment support.
Picture 7: PTS Dialog
All in all 91 employees work with the PTS to date. On the average one third of the possible users have an active agenda and again half of them are working actually on one activity. Currently between 20 and 30 problem reports are created every day. The registration of a new PR is remarkably easier with the new system than with the old paper form. This is the explanation why the number of new problem reports per day increased by 25% since the PTS has been introduced. Especially employees who don't announce problems regularly are now able to register problem reports easier during their normal work.
6 THE Impact on Software Process Research
The application of software process technology to industrial software processes as described in this article and as partially also reported in other experiments may lead to a refocusing of software process research. In more detail, this means:
Our experience clearly shows, that it is reasonable to have a mixture between models, which are defined in detail, and others, which only describe the frameworks for the process to happen. As mentioned above, processes which focus on the creation and manipulation of objects of one type can be illustrated by state transition diagrams. It may be useful to specify parts of processes in this way and thus, to specify constraints which should not be violated in process enactment. For other processes it has to be predefined in detail what has to happen and when. For processes of this type a FUNSOFT net description is appropriate. Thus, it may be useful to model some parts in a prescriptive style (e.g. with FUNSOFT nets) and to describe the frameworks of other processes with state transition diagrams, without specifying in detail when every state transition can occur.