User Interfaces supporting the Software Process - CiteSeerX

Download PDF
6 downloads 116 Views 406KB Size Report
Comment
PSEE, and how these interfaces support the user during process enact- ... tion about the involved process(es), the software artifacts which should be processed,.
User Interfaces supporting the Software Process Hans-Ulrich Kobialka

Claus Lewerentz

GMD, Schloß Birlinghoven D-53754 Sankt Augustin, Germany

Technical University of Cottbus Postbox 10 13 44 D-03013 Cottbus, Germany [email protected]

email: [email protected]

Abstract: User interfaces determine the process support that is really delivered to the user. In order to support a process effectively, individually tailored user interfaces have to be provided. Most process centered software engineering environments (PSEEs) provide predefined user interfaces, but only low-level languages which can be used by customers to build process-specific user interfaces. This paper describes how user interfaces can be specified in the ADDD PSEE, and how these interfaces support the user during process enactment.

1

Introduction

During process enactment, the quality of a PSEE’s user interface strongly influences the user acceptance of process technology. If someone would ask “How can we gain more productivity? Should we improve the process program or the user interfaces?”, we suppose that in most cases the answer should be “Improve the user interface!”. We claim that each process step has to be supported by a dedicated user interface. There may be universal browsing tools and powerful command or query interfaces, but effective process support requires actions to be performed with a minimum of manual input. As a prerequisite, the information needed for the actions must be retrieved and displayed automatically. This can be only achieved by a user interface which is explicitly designed for the particular process step. In this paper, we discuss two questions: 1. How should user interfaces be built and integrated with a process engine? 2. What are good examples of process-sensitive user interfaces? Answering the second question requires many examples and discussions. There won’t be “the best” user interface even for a specific process step, but in order to find appropriate solutions, one has to know many approaches. In section 3, we introduce the various interfaces which are supported by a PSEE called ADDD, and discuss their rationale and the underlying technical concepts. Section 2 debates general issues of user interfaces and PMLs, and section 4 summarizes our conclusions on this topic.

2

Interfacing Software Processes

It is common sense that process support should not be implemented by many lines of code written in general purpose languages. Instead, process modeling languages (PMLs) should be used. A PML is a domain specific language which should be easy to understand and change. A PML requires a user interface used by the process designer to develop and debug process models. Here we are not focussing on these interfaces but on those which are used during process execution. First, we describe the benefits which can be gained by process-specific user interfaces and then we look at how user interfaces can be integrated with process programs.

2.1 Benefits of User Interfaces in PSEEs During process enactment, the basic questions for each user are “where am I?” and “what are the next steps which could be performed?”. Further questions are “Which events have lead to this situation?” or “How does the work of my colleagues affect mine?”. User interfaces help answering such questions. We give a short classification of the benefits which can be gained from a user interface of a PSEE. A particular user interface can provide multiple of these benefits simultaneously. a) Enabling Work The user interface should enable the user to select work items and to perform actions on them. In many cases, information has to be retrieved and coworkers have to be contacted before an action can be performed. b) Browsing the State of Enactment User interfaces have to display various information about the involved process(es), the software artifacts which should be processed, and the dependencies between them. For example, many PSEEs provide an agenda [McCa98] which displays the current tasks to be performed by a particular user. c) Viewing the Process History Most tasks need historical information, i.e., what has been done during previous tasks. This includes information about how a task has been accomplished, which changes have been performed, version histories, and event records. Using the user interfaces mentioned above, people may recognize changes while things are changing on the computer screen, or by inspecting historical information. Of course, this is not reliable enough to ensure proper cooperation (e.g. it is not clear whether all information has been received and accepted by the people concerned). d) Communication and Cooperation A simple way of notifying a person about an event is sending a message, e.g., an email. Receiving such a message need not to cause any action. In contrast, other kind of messages require action. For instance, sending a change request triggers a process of analyzing. coding and reviewing this request. Within such a process, participants cooperate by using some communication protocols, i.e., a participant may send a message to another one and expects him to reply in a certain way. Depending on the meaning and the context of a message, there should be specialized user interfaces which again may be different for senders and receivers.

Often the receivers of an information are not known exactly. In such cases, information can be broadcasted or stored at places where it could be retrieved later by anyone who is interested. e) Viewing the Impact of Process Programs A user whose work is influenced by a process program may want to know which process statements have caused the system to react in the way it did. This information enables the user to distinguish between the normal system behavior and the enhancements/restrictions imposed by the process program. Having appropriate user interfaces, users can provide feedback for improving process programs without analyzing any low-level data.

2.2 PMLs and User Interfaces In [Band94] it has been advocated that user interfaces should be “decoupled” from PML paradigms, i.e., the user interface should be designed according to the needs of the process; the terms and execution paradigms (e.g., whether the PML is based on rules or on a net formalism) of the PML should not constrain user interface design. Implementation of User Interfaces Current PMLs concentrate on the design of data and control flow between process steps, but less on user interfaces. There are different techniques to derive or bind user interfaces to process models written in some PML: • Many PSEEs let the user view process enactment in the same way as the process designer when (s)he writes process models using a PML editor. Such animated process models are available, for instance, in Process Weaver [Fern93] (animated token flow in a Petri net) and Serendipity [Grun98] (activities are highlighted in a net where nodes are connected by event flows). • Some PSEEs offer to generate user interfaces from (parts of) a process model. For instance in LEU [Gruh95], form based user interfaces can be generated from the database schema and further refined using a user interface editor. In APEL [Dami98], each activity has a desktop on which the products managed by that activity, as well as its sub-activities can be manipulated. The desktop is generated from the actual activity hierarchy and the object-oriented schema, i.e. the methods of the displayed objects are displayed. The process designer can reduce the methods available in a given activity. • In most PSEEs, user interfaces are treated as tools, i.e., the tool integration mechanisms of the PSEE have to be used. For this purpose, command language (or programming language) interfaces are offered. It can be argued whether these languages and interfaces are part of the PML, or not. Anyway, the implementation of process support becomes a multi-lingual effort. Usually a command language interface provides a context for a user interface, i.e. it is bound to some part of the process which should be viewed or enacted using this user interface. For instance, Process Weaver creates a work context for each action which has to be performed by a user. The work context is displayed by a user interface (which has been created manually using either Process Weaver’s work context editor or Visual Basic). In the code, the user interface refers to variables which are

bound at runtime to specific objects (for instance, the inputs of the action to be performed) in the current work context. After a user interface has been started, its events/actions have to be considered by the process engine. Process Weaver and SPADE-1 [Band96] (both offering a netbased PML) provide a message broadcast mechanism: after a user interface is started, the code associates an event pattern with an event handler function; this function is executed each time an event matches the pattern. In this way, it is possible to interact with a user interface and to influence its appearance and behavior. This is needed especially for the integration of tools for computer supported cooperative wort (CSCW) [Band96]. In most cases (e.g., in Oz [BS95]), only the outcome of a user interface dialog is caught (by an event handler or a tool wrapper) and passed to the process engine. Animated process models are useful for viewing the impact of process programs [point e) above], but (as people can not watch the animation all the time) historical views are required in addition. A generated user interface can not fulfill all possible needs of the user [points a) to e) above] at once. Therefore it has to be tailored. It seems that for many purposes the generated user interface hinders more than it helps in order to get to the desired solution. We think that the best user interfaces can be built using general purpose user interface construction tools, and connecting them to the PSEE via a command interface. But in this approach it is not specified/controlled by the PML when such user interfaces should be used by whom. Invocation of User Interfaces in a Process-specific Way During the process, development techniques are selected and refined according to the characteristics of the system to be built. Appropriate tools are selected and working styles evolve. This has to be reflected in the user interfaces. Hence, there is not a single set of interrelated user interfaces. Instead, some user interfaces will be used only in specific processes. Some user interfaces will be customized according to the current process - for some other user interfaces there may exist several variants. Therefore, it has to be determined (preferable in the process model) when which (variant of a) user interface should be used and/or how it should be customized. Net-based PMLs (like used in Process Weaver, SPADE-1, or LEU) allow to start a tool or a user interface during a net transition. If the refinement of a net into subnets can be determined at runtime (like in Process Weaver), then special processes are modeled by specialized (sub)nets and therefore special user interfaces can be associated to them. Without such a (e.g. hierarchical) modularization, the process-specific selection of the appropriate user interface becomes difficult. For instance in Oz, the use of variants of user interfaces (or cooperative tools) are hard to specify, because variants of rules are not supported. In object-oriented approaches, each object may have a different user interface, but this choice is independent of the process currently performed by the user. In APEL, an activity may only be viewed by the people performing it, so in this case the user interface of the activity can also be called “process-specific”.

Adaptation of User Interfaces to the User’s Needs The user interfaces delivered with the PSEE can not be changed. For instance in existing PSEEs (except Grapevine [McCa98]), the agenda is a user interface which can not be adapted to the individual needs of a user. Similarly, the animated viewers of enacted process models have to be used “as is”. The drawback of user interfaces which are generated from a process model, is that a change at the user interface requires a change of the process model in order to keep both consistent. The latter is a major operation and may have serious consequences. Adaptation of user interfaces has to be performed by the process designer(s). User interfaces which are connected via command interfaces or tool wrappers can be changed independently from the process model. ____

Our conclusions of the discussion above are: • The user interfaces should be written independently from the process model [Band94]. User interfaces should be a “first class” part of the process model. • At runtime, processes should be bound to specific user interfaces. • This binding and the user interfaces should be changed by the users themselves, not by the process “guru”.

3

The ADDD PSEE

ADDD is a PSEE which integrates process technology and configuration management [Kobi93a, Kobi98a]. Active process support is based on triggers. Triggers are eventcondition-action rules, as known from active database systems [Daya91]. In section 3.1, we give a short introduction to the concepts of ADDD and its PML, called ALADYN. The rest of this section focuses on the user interface of ADDD.

3.1 Basic Concepts In ADDD, work is organized in a task hierarchy which can be extended dynamically. A task is a concrete piece of work which has to be performed. During its lifetime, a task can receive input documents and produce results several times. Each task has a number of team members; at least one of them plays the role of its manager. A manager of a task can perform privileged actions (like the creation of subtasks) on this task and recursively on all its subtasks. The artifacts used and created by tasks are versioned items. Versions can be grouped into version sets, called configurations. Old states of a configurations can be preserved, because a configuration is a version too [Kobi93b]. A user views the system as a set of entities (tasks, documents, versions, configurations, users) and relationships between them. Entities and relationships can be created dynamically at runtime. ADDD offers a Tcl [Oust94] command interface which ensures basic consistency during operation.

Commands and Execution Contexts Using user interfaces, the user can issue commands which are tagged by his user id and a task id. The system accepts only commands of a user which are tagged with a task of which (s)he is a team member. The pair (user id, task id) is called the execution context of the command. The execution context is used for several purposes: • Bookkeeping: The execution context is recorded, for instance, to set the attribute “author” of versions and relationships. • Access control: Privileged commands are reserved for managers of the concerned task or its parent tasks. Further access restrictions can be added by defining triggers. • The process support to be applied. Depending on the current task, the system behavior is customized and specific triggers are active. Customization and active triggers can be totally different for the same command when it is issued on behalf of different tasks. As a convention, the execution context is noted in the title of a window, in the form @. For instance, simon@coding_cr86 expresses that commands sent by this window will have the execution context of user simon working on task coding_cr86. Policies Besides the organization of work, the task hierarchy is used to organize process descriptions, called policies. A task can be associated with a policy (figure 1). The policy influences the work of the task and its subtasks. A policy contains parameters, procedures, and trigger definitions written in ALADYN. Parameters and procedures are used for customization, and triggers are used for process monitoring, notification, automation and consistency control. A manager can select a policy file to add process support to a task. Furthermore, (s)he can associate specific policy files with each subtask depending on its characteristics, i.e., the tools being used, the goals to be met, and the skills of the developers. During execution, a user interface (or any other system component) can retrieve certain parameters or procedures from the policy of the actual execution context. For project_XY

project_policy set start_editor {emacs $filepath} proc icon {name} {...} notify TASK_EV_NEW_RESULT SELF/* MANAGER

development_of _component_B

team_policy_B set start_editor {vi $filepath} proc icon {name} {...}

Figure 1: Example of policies defined on different levels in the task hierarchy.

example, a user interface may retrieve how it should configure its appearance and functionality (e.g., should a particular button appear or not). Parameters and procedures are inherited by subtasks and can be redefined for their execution contexts. In figure 1, the parameter start_editor is redefined in team_policy_B, so developers working on component B will use the vi editor while the rest of the project is using emacs. Similarly, the redefinition of procedure icon leads to the fact that (some) items are displayed with different icons for people working on B than for the rest of the project. The notify command defines a trigger which is explained in section 3.3.

3.2 General User Interfaces ADDD is delivered with a set of general user interfaces which provide intuitive access to its services. For effective process support, these interfaces are complemented by process-specific user interfaces and checklists (described below in 3.5, 3.6). The existence of general user interfaces enables users to start working with ADDD without any process-specific support; they can add it during the process in an incremental way. In ADDD, each user has an agenda which offers him all his active and suspended tasks. In the agenda, it is possible to open a session for a task; this causes all windows to reappear which were present the last time when the session was closed. ADDD offers several kinds of windows to the user:

Figure 2: The agenda of user simon (left window). After he opens his task coding_cr86 in the agenda, the windows of his session (all entitled “simon@coding_cr86”) appear. One of these windows is the management view on this task (right window)

The management view shows information about a task: its team members, its inputs, its subtasks, and its results. In case the user has management permissions, the window offers menus to manipulate these issues, for example, to assign a team member to a subtask. Other kinds of views are the history view (displaying the version graph of a document), the configuration view (showing the versions of a configuration), the hierarchy view (displaying hierarchies of tasks or directories) and the browser view (displaying a net of interrelated objects). The browser view is a very general tool which offers quite different views depending on the object used as the starting point. ADDD also offers a command line interface.

3.3 Notification In order to make the system reactive, ALADYN offers triggers. General triggers are used first of all for process automation and the implementation of process constraints. Here, we focus on specialized triggers used for notification and process monitoring. “Caused by” vs. “Happened on” In ALADYN, we distinguish between triggers on an object (i.e., they wait for events happening on a particular object) and triggers observing events caused by a task (i.e. the current execution context refers to this task, see 3.1). In the example below (taken from figure 1), the trigger waits for the event TASK_EV_NEW_RESULT caused by a task matching the pattern SELF/*. SELF stands for the pathname of the task the policy is associated with. For instance in figure 1, the policy project_policy is associated with task project_XY. Thus SELF/* is expanded to /project_XY/*. In case task /project_XY/development_of_component_B causes the event TASK_EV_NEW _RESULT, the pathname matches the pattern and the trigger is fired. notify TASK_EV_NEW_RESULT SELF/* MANAGER

This trigger notifies the managers of the task to which this policy is assigned (/project_XY) whenever one of its subtasks produces a result. The notification is similar

Figure 3: A notification received by kobi@CCB. For traceability reasons, the last line mentions the trigger which has caused the notification, and the policy file in which it is contained.

to the one displayed in figure 3. If the pattern would be SELF*, the managers are also notified when a result is produced by the task /project_XY itself. In the next example, the manager(s) of an associated task should be notified if any input is assigned to this task. notify_on_task TASK_EV_NEW_INPUT SELF MANAGER

This trigger listens for the event TASK_EV_NEW_INPUT happening on the specified task regardless of which task has caused the event. Such triggers have the postfix _on_task.

3.4 Monitoring of Process Events Monitoring of events and automatic notification of people are very simple but effective measures for providing process support. In the current ADDD PSEE, there are about 50 events defined, thus message texts can be provided for all of them. These texts are defined as ALADYN parameters (so, if needed, they can be redefined in the policies of a task). The following trigger records all input assignments happening on subtasks in a particular file. log_on_task TASK_EV_NEW_INPUT SELF/* /usr/tmp/subtask_IO.log

Each task and each document has its own log file in which some event history can be recorded. The trigger below records all events raised on a task (event SO_EV_ALL matches all events) in its log file (*tasklog* means “record the event in the log file of the task”1). log_on_task SO_EV_ALL * *tasklog*

Log files can be inspected or analyzed with general text processing software. We found it useful to incorporate a view on the log into task-specific user interfaces (see figure 4).

3.5 Task-specific User Interfaces Process support can gain much productivity and acceptance if user interfaces can be adapted to the needs of a task and the people performing it. Using ALADYN, various aspects can be adapted in a task-specific way. The user interface of a task is retrieved by a policy procedure [proc gui_script {name type}] which is evaluated whenever the user selects a particular menu entry (“display”) in a general user interface (3.2). For instance, figure 4 shows the user interface of a task which initiates and controls the execution of change requests. Using this user interface, change requests can be rejected, edited, and assigned to subtasks for either analysis, coding, or review. The user interface also supports communication and cooperation. For instance, the lower subwindow displays the log of the task. By looking at the log, team members are informed about the event history of this task. Users can also write memos to the log of a task explicitly.

1. The log files of tasks and documents are located in dedicated directories in the file system.

Figure 4: The user interface of the CCB task (CCB stands for “configuration control board”) coordinating the handling of change requests. The upper left subwindow shows change requests which are retrieved according to the radio buttons above (new, scheduled, ..., or all change requests). The upper right subwindow shows the current subtasks of CCB. It shows whether there exists any results (indicated by * or -), the state, and the team members. The lower subwindow displays the log of task CCB. By specifying a pattern (which is applied to each line) the log file can be viewed in various ways.

3.6 Checklists In order to ensure that some tasks are performed properly, a finer granularity of actions beyond the task level should be monitored. The focus should not be on tool executions, because a tool may be invoked several times to achieve a goal, and it is the user who has to assess the results of tools. Thus, we take a result oriented approach: a checklist can be associated with a task. A checklist is a list of sentences to be fulfilled/answered by the user. The developer working on the task can answer these questions, or leave them open if they are not applicable. A manager or other developers can look at these checklists in order to see, how far an ongoing task is completed, or how a finished task has been performed. Change of checklist fields can be recorded in the log file of the task. The checklist of a task is retrieved by a process procedure [proc checklist_file {task_pathname}] which computes the checklist file from the pathname of the task. In a checklist file, fields for user input are indicated by ‘#’. Default values or further advice (e.g., “[This is a] mandatory field”) can be placed after the ‘#’ (see figure 5).

Detailed comments should be appended to the change request !! Please, fill out only those questions which are applicable. Urgency / Priority

#mandatory field

Is this request caused by - misunderstanding ? # - wrong or incomplete specification ? # - wrong or incomplete documentation ? # - an implementation error ? # Is the problem already fixed ? Related change requests:

# #

Does the request conflict with the specification ? # require a change of the documentation ? # require a change of the testcases ? # require a change of code ? # Estimated time for fixing the problem: Modules affected: Do you propose a solution ? Have you already fixed the problem ?

# # # #

Figure 5: The checklist of task analysis_cr86 as it is displayed to the user (left) and the file from which it is generated.

3.7 Changing the User Interface A major advantage of ADDD is the fact that policies can be easily changed during enactment and that changes need not influence the whole project, but can be limited to particular tasks [see Kobi98a]. Here we want to give a short demonstration how user interfaces can be changed during process enactment. Let us assume that there are complaints about the checklist used for analyzing change requests (figure 5). Some people think that an important question is missing and that two other questions should be specific to the programming language and the tools they use. First, one may think of changing the checklist file (Analyse.clist). This would lead to the fact that each task which uses this file will see the modified checklist (see

figure 6, left). Maybe this is not a good idea, because other people are using other programming languages and tools, and may have their own opinion about which questions are important for their work. So we create a copy of the checklist file (Analyse_NEW.clist) and perform the changes. In order to make it available for the tasks where it should be used, a policy file has to be modified. In this policy, a single line in the procedure checklist_file (which usually contains a single switch statement) has to be changed: proc checklist_file { task_pathname } { switch -glob $task_pathname { */analysis_* {set checklist Analyse_NEW.clist} */coding_* {set checklist Coding.clist} */review_* {set checklist Review.checklist} ... } return $checklist }

If the policy file is also used by other tasks which should not share the modified checklist, again the file should be copied first before applying the change. The new policy file (Policy1_NEW) should then be assigned to the tasks (e.g. TaskA) where Analyse_NEW.clist should be used. After the policy file is assigned, Analyse_NEW.clist will appear for these tasks while others still use Analyse.clist.

TaskA

TaskB

Policy1

Analyse.clist

TaskC Policy2

TaskA

TaskB

TaskC

Policy1_NEW Policy1 Policy2

Analyse_NEW.clist

Analyse.clist

Figure 6: The situation before (left) and after introducing the modified checklist Analyse_NEW.clist to TaskA. The other tasks still use Analyse.clist.

The change of task-specific user interfaces (3.5) is performed in a similar way while the change of a trigger only requires the modification of a policy file. The assignment of a (changed) policy file to a task is performed as a single command. After that, the change is operative for subsequent commands which are executed on behalf of this task and its subtasks. The assignment of a policy to a task is a privileged operation which can only be performed by the managers of this tasks or one of its parent tasks. Thus, user interfaces can be adapted locally by the people working on the task rather than issuing a change request to be performed by some process “guru”.

3.8 Some Observations Observation 1: No kind of user interface can be substituted by another one. Notification, process monitoring, and checklists are tailored to clearly defined purposes. These user interfaces are easy to implement and to understand. Task-specific user interfaces (3.5) can be designed according to the needs of the user. On the other hand, user interface programming is labor intensive. In our implementation of the ISPW9 example [Pene94], the hand written1 code of the user interfaces covered more than 2000 lines while the policies contained 307 LoC [Kobi98b]. Surprisingly, notification, process monitoring, and checklists can not be viewed as special cases of task-specific user interfaces. The latter are implemented by designing the screen layout and writing command scripts to be sent to the ADDD server. Notification, for instance, is implemented by writing triggers contained in policies, i.e., the language, the location, and the programming paradigm are different. Observation 2: Specific user interfaces exploit specific properties of the PSEE. Each user interface of ADDD depends on certain properties of the PSEE: • Process monitoring depends on the concept of a task’s log file. • Monitoring and notification are based on ALADYN’s trigger paradigm. • Checklists rely on the ability to attach an arbitrary amount of attributes (name-value pairs) to tasks. • Writing task-specific user interfaces would be hazardous if the PSEE would not offer a sound command interface which ensures basic consistency.

4

Conclusions

Many PMLs focus on control and data flow between process steps. In this paper, we have omitted such kind of process rules in order to demonstrate that important process support can even be gained without them2. There is currently not enough experience in user interfaces supporting the software process. This is because previously people attempted to generate user interfaces from the process model information (control and data flows, database schemas) rather than building the user interfaces according to the needs of the users. The implementation/integration of appropriate user interfaces is usually a great effort. In order to provide process-specific user interfaces, this effort has to be performed by the customers, not by the PSEE builders. Existing tool encapsulation and message broadcast technology seems to be too low level, because this technology does not consider concepts which are specific to the process domain. Users need process languages which allow them to implement typical user interfaces within a few lines.

1. We used an user interface builder and augmented the generated code with hand written code. 2. Of course, control and data flow rules are needed for comprehensive process support. [Kobi98b] illustrates how ADDD supports them.

This paper describes the user interfaces of ADDD, the languages used to implement them, and the conceptual and technical background. The main contributions of the user interface concept of ADDD are • Developers use different user interfaces depending on the process step they are currently performing. This binding (process step -> user interface) can be specified (among other things) in policies. • The appearance and the functionality of user interfaces are specified orthogonal to other aspects, like control and data flow. ADDD offers some small languages: 1. Triggers to specify notification and process monitoring. 2. A simple language to specify checklist forms. Task-specific user interfaces can be implemented using general-purpose user interface construction tools. • Changes (of the policies, of the checklist specifications, of the task-specific user interfaces) can be performed during process enactment by the people involved in the particular process and do not necessarily depend on some process “guru”. • The use of checklists is not known from other PSEEs. Checklists help the developer not forgetting important aspects and collecting important data which can be used later, e.g., during process analysis. Checklists are simple to use and provide effective process support. Similar to agendas, checklists should be available in every PSEE. Future research on software process support need much more examples of successful user interfaces. This will enable a sound classification of user interfaces and their properties. Future user interface construction will be specific to the process domain. User interfaces depend on services and properties of the underlying PSEE. The identification of these services/properties requires to look at the PSEEs from the user’s point of view rather than from the one of the process designer.

References [Band94]

[Band96]

[BS95] [Dami98]

[Daya91]

[Fern93]

Sergio Bandinelli, Elisabetta Di Nitto, Alfonso Fuggetta, and Luigi Lavazza. “Coupled vs. decoupled user interaction environments in PSEEs.” In C. Ghezzi, editor, Proceedings of the 9th International Software Process Workshop, pages 50–52. IEEE Computer Society Press, October 1994. Sergio Bandinelli, Elisabetta Di Nitto, and Alfonso Fuggetta. “Supporting cooperation in the SPADE-1 environment.” IEEE Transactions on Software Engineering, 22(12):841–865, December 1996. Israel Ben-Shaul and Gail Kaiser. A Paradigm for Decentralized Process Modeling. Kluwer, 1995. Samir Dami, Jacky Estublier, and Mahfoud Amiour. “APEL: A graphical yet executable formalism for process modeling.” Automated Software Engineering, 5(1):61–96, January 1998. Umeshwar Dayal, Meichun Hsu, and Rivka Ladin. “A transactional model for longrunning activities.” In Proceedings of the 17th Conference on Very Large Databases. Morgan Kaufmann, September 1991. Christer Fernström. “Process WEAVER: Adding process support to UNIX.” In Proceedings of the Second International Conference on the Software Process, pages 12– 26. IEEE Computer Society Press, February 1993.

[Gruh95]

[Grun98]

[Kobi93a]

[Kobi93b]

[Kobi98a] [Kobi98b] [McCa98]

[Oust94] [Pene94]

Volker Gruhn and Stefan Wolf. “Software process improvement by business process orientation.” Software Process–Improvement and Practice, Pilot Issue:49–56, August 1995. John C. Grundy and John G. Hosking. “Serendipity: Integrated environment support for process modelling, enactment and work coordination.” Automated Software Engineering, 5(1):27–60, January 1998. Hans-Ulrich Kobialka and Carsten Meyke. “Views on an object-oriented software engineering environment.” In H-Y. Lee, T.F. Reid, and S. Jarzabek, editors, Proceedings of the Sixth International Workshop on Computer-Aided Software Engineering, pages 338–347. IEEE Computer Society Press, July 1993. Hans-Ulrich Kobialka and Carsten Meyke. “Configurations are versions, too.” In Proceedings of the 4th International Workshop on Software Configuration Management (Preprint), pages 156–164, Baltimore, Maryland, May 1993. Hans-Ulrich Kobialka and Claus Lewerentz. “Incremental change of process support.” 1998. ftp://set.gmd.de/pub/fit/kobialka/ProcessChange.ps.gz. Hans-Ulrich Kobialka and Claus Lewerentz. “Support for change request driven software processes.” 1998. ftp://set.gmd.de/pub/fit/kobialka/CRdSP.ps.gz. Eric K. McCall, Lori A. Clarke, and Leon J. Osterweil. “An adaptable generation approach to agenda management.” In Proceedings of the 21st International Conference on Software Engineering. ACM Press, April 1998. John K. Ousterhout. Tcl and the Tk Toolkit. Addison Wesley, 1994. Maria H. Penedo. “Life-cycle (sub) process scenario.” In C. Ghezzi, editor, Proceedings of the 9th International Software Process Workshop, pages 141–143. IEEE Computer Society Press, October 1994.