ColD SPA: A Tool for Collaborative Process Model ... - CiteSeerX

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

ColD SPA: A Tool For Collaborative Process Model Development James D. Lee University of Arizona [email protected]

Ann M. Hickey Univ. of Colorado at C.S. [email protected]

Eric Santanen University of Arizona [email protected]

Abstract Awareness of the need for business analysis has grown faster than the evolution of tools to support collaborative development of business analysis models. Involvement of key personnel is important for model accuracy and buyin, which is not trivial, especially if they are distributed geographically. Traditionally, models have been developed by individuals or small groups because of the complexity of collaborative modeling. University of Arizona researchers have created specialized electronic meeting systems tools and methods to support several types of collaborative business models. This paper discusses the creation of the Collaborative Distributed Scenario and Process Analyzer (ColD SPA) tool, developed to support collaborative business scenario and process modeling. The ColD SPA prototype serves as “proof-of-concept” that a web-based tool can support collaborative modeling in face-to-face and distributed settings. Flexibility integrated into SPA enables it to support a wide range of problem analysis tasks and has resulted in a type of “build-your-own” collaborative tool.

1. Introduction Awareness of the need for business analysis has grown faster than the evolution of tools to support the collaborative development of business models. Appropriate models may support conceptualization, communication, analysis, and design of improved business processes and information systems. In addition, involvement of key personnel during model development and analysis is important for model accuracy as well as for buy-in [1, 6]. Traditionally, however, models have been developed by individuals and small groups because of the complexity and difficulties involved in the modeling process. Researchers at the University of Arizona have worked for the past several years creating specialized electronic meeting systems (EMS) tools and methods to support the development of various types of business models including IDEF0 activity models and enterprise data models [8, 10, 11, 12, 18]. These tools and methods were

Dongsong Zhang University of Arizona [email protected] Lina Zhou University of Arizona [email protected]

designed to effectively involve users in the development of business models and were designed for use in a face-toface setting. With increasing globalization and the use of virtual teams, the need to support distributed teams has increased significantly. These modeling tools are an important part of the Collaborative Software Engineering Methodology (CSEM) [9]. CSEM also describes the development of behavioral models of the business processes needing improvement or information system support. These behavioral models integrate scenarios (narrative descriptions of human work processes that identify the sequence of actions taken to accomplish a goal [4]), with process models which graphically display the action sequence and decision logic of the scenario. Although there are general-purpose collaborative tools and special-purpose single-user graphical process modeling tools available, there are not any tools specifically designed to support collaborative user development of integrated textual scenario and graphical business process models. This paper focuses on the creation of the Collaborative Distributed Scenario and Process Analyzer (ColD SPA, hereafter referred to as SPA) tool which was developed to support this aspect of CSEM. This is only a small part of the research to date on CSEM and SPA. Other papers discuss aspects of CSEM and SPA not detailed in this paper [9, 15, 17].

2. Background Previous research in the development of IDEF0 activity models showed that these models were very well suited for describing “what” an organization does, but lacked some important details such as sequence of activities and decision logic [8]. Recent research has suggested that scenarios may be an effective means of capturing rich descriptions of this type of business process behavior [4]. Surveys of scenario usage in industry have found that although there are many options for documenting scenarios (e.g., text, diagrams, graphics, animation), unstructured text is used most often. However, our experiments [16, 17] showed completeness problems when using unstructured text descriptions. This

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1


led to the use of structured scenario descriptions with specific prompts for information. Further research determined that business process models could be used to more clearly portray additional information. Like scenarios, there are also many techniques for developing process models. For example, Vreede [27, 28] discusses the use of dynamic animated models. More common are static graphical diagrams such as flowcharts, Petri nets, IDEF3, and UML's Sequence and Activity Diagrams. With so many approaches to process modeling, it was necessary for us to develop a set of criteria for selecting the best approach. A process model can be described as “an abstract description of an actual or proposed process that represents selected process elements that are considered important to the purpose of the model and can be enacted by a human or a machine” [5, p. 76]. So, our first criteria is "what process elements" do we need to support CSEM and integrated scenario and process modeling? Mandatory elements are: process, sequence, iteration, and selection (i.e., conditional/decision logic). Desired elements are: actor and object flow. Process models can be developed from different perspectives such as functional, informational, behavioral, or organizational perspectives [5, p. 76]. In MIS, some of the earliest process models (e.g., data flow diagrams) took a functional perspective. Business process reengineering and other process improvement initiatives have shifted the focus to behavioral and organizational perspectives for modeling general business processes. This is what we need and hence, our second criteria. The target audience for this tool is comprised of non-analyst/modeler user groups. Research [23, 26, 27] has shown that when these types of users are working with graphics, the user interface must be very simple with minimal elements (third criteria). With this in mind, the final criteria is that certain process elements are used only when needed or desired by analysts or modelers. Recently, Butler et al. [3] stated that “one of the bestspecified languages for representing work processes in the physical world is IDEF3” [3, p. 41]. The IDEF3 Process Description Capture Method was developed by Knowledge Based Systems, Inc. (KBSI) for the U.S. Air Force [19]. The basic process element in IDEF3 is the “Unit of Behavior (UOB)” which describes “things that happen in the world” (e.g., function, process, scenario, activity, action, operation, event, decision, or procedure) [19]. The other major IDEF3 constructs are links used to specify relationships between UOBs (e.g., temporal precedence, constraints, object flows, or relationships) and junctions which can be used to ‘join’ two or more links together or to ‘fork’ out to links to two or more processes. Junctions are annotated to indicate the timing of forks and joins as synchronous or asynchronous. [19, 20].

As can be seen from the preceding discussion, the IDEF3 process description method provides a comprehensive business process modeling capability. However, University of Arizona researchers’ experiences with IDEF3 indicate that some portions, such as the different types of synchronous and asynchronous junctions, may be too complex for users to quickly grasp. Therefore, while the capabilities of IDEF3 served as input to the SPA requirements process, several other alternatives were investigated in the search for a simplified, easy-to-use graphical process modeling technique. Petri-nets [30] were eliminated from consideration since they are even more complex than IDEF3 [7]. In contrast, several Unified Modeling Language diagrams seemed to have potential as a usercomprehensible representation. The Unified Modeling Language (UML) was adopted by the Object Management Group as the standard objectoriented modeling language [2]. The UML standard defines several diagrams for behavior modeling that could possibly be used to graphically portray business processes. UML’s Sequence Diagram is commonly used to document use case scenarios. It is a type of interaction diagram which shows the objects participating in a scenario and a time-sequenced list of messages the objects exchange to accomplish the scenario goal [2]. The Sequence Diagram’s focus on objects and messages increases its complexity beyond what is desirable for a simplified, graphical process modeling technique targeted to non-analyst users. UML’s State Diagrams are also too complicated for users to independently create without significant training and assistance from analysts or modelers. These technical diagrams are more suitable for use by experienced analysts and developers than by untrained users. Description Activity Diagram Construct Action State Represents the execution of an atomic action. A simple state with an entry action whose only exit transition is triggered by the implicit event of completing the entry action. Activity State Represents the execution of a nonatomic sequence of steps that has some duration. A hierarchical action where an associated sub-activity model is executed. Pseudo State Abstraction of different types of nodes in a state machine graph which function as transient points in transitions from one state to another, such as branching and forking, simple transitions, or object flows. Table 1 – UML Activity Diagram constructs [24]

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2


In contrast, UML’s Activity Diagram is a greatly simplified version of the UML state diagram which can easily be used for business process modeling [14]. It is designed to provide a dynamic view of a system or process which shows the flow from activity to activity [2, 24]. The basic constructs in the UML Activity Diagram are defined in Table 1. These definitions seem rather technical, however, they are relatively simple in practice. Activity and action states are directly comparable to IDEF3’s UOB and can be used to represent a business process and the steps in the process, respectively. The user does not even have to be concerned with the difference between activity and action states since they are both represented with the same graphical symbol (see Figure 1). Decision

Transition

Fork or Join

Object Flow

observation was used to address the research questions associated with this research. Experimental and observation research results are discussed in [15, 17]. This paper focuses on the systems development task of the overall project. The research design for this effort is described next.

3.2 Systems development research design The primary purpose of this research was to develop and evaluate a new system that provided better support for collaborative scenario and process model development than existing tools. To ensure the appropriate research perspective, the systems development research methodology defined in [22] was used to guide this research. This methodology consists of five stages which are described in the following sections.

Activity/Action State Name

Activity and Action States

Theory Building

Pseudo-States

Figure 1 – UML Activity Diagram graphical symbols [24] The graphical symbols for pseudo-states are also much simpler than its definition would imply. The decision, fork, and join pseudo-states are simply different types of branches that can occur in process flows and are comparable to IDEF3 junctions. Transitions and object flows represent two types of links between activity or action states. In summary, both IDEF3 and the UML Activity Diagram satisfy SPA’s criteria for graphical business process modeling. The basic elements of each are directly comparable. However, because the Activity Diagram has a simpler representation and can be linked to other UML diagrams, it was selected for SPA’s initial graphical process modeling representation.

3. Research approach 3.1 Overview – multi-methodological approach Selection of an appropriate research methodology can make the difference between success and failure of a research project. The emerging consensus is that multimethodological approaches provide the greatest insight into the complex social and technical issues involved in GSS research [25, 29]. Differences between GSS field and experimental research results (e.g., [13]) emphasize the importance of multiple methods to achieve a balanced research perspective. The tradition for GSS research at the University of Arizona is a multi-methodological approach with systems development as its core (Figure 2) [21]. This systems development research approach incorporating theory building, systems development, experimentation, and

Systems Development ColD SPA Prototype

Observation

Experiments

Figure 2 – Multi-methodological research approach (Adapted from [22]) 3.2.1 Construct a conceptual framework. The research perspective of this methodology is firmly established in this first stage which requires the researcher to clearly state and justify the significance of his or her research question. The question should be discussed in terms of an appropriate conceptual framework to set the stage for theory building. The goal of this research was to continue to refine the response to this primary research question: What are the collaborative modeling processes and tools needed to effectively elicit scenarios and process model information from users in a group environment? As part of this task, system functionalities and requirements were explored in more depth by pondering the question: What are the functional requirements for a collaborative and distributed scenario and process modeling tool? Two other issues traditionally addressed during this stage are (1) to develop an understanding of the system

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3


building processes and procedures and (2) to study relevant disciplines for new approaches and ideas. Both issues were directly applicable to this research and provided direction throughout the development process. 3.2.2 Develop a system architecture. Development of a system architecture not only requires definition of a unique architecture and functionalities of system components, it also requires identification of constraints imposed by the environment, statement of development objectives, and specification of measurable requirements. This information is necessary to ensure that the system functionalities satisfy the known constraints, objectives and requirements. 3.2.3 Analyze and design the system. During this stage of the systems development research methodology, requirements are analyzed, databases and user interfaces are designed, and, for object-oriented systems, system functions and behaviors are allocated to classes. 3.2.4 Build the system. System building is essential for proof-of-concept and to provide an artifact which can be evaluated to provide feedback to the theory building process. It allows researchers to “learn about the concepts, frameworks, and design” and “gain insights about the problems and complexity of the system” [22, p. 98]. 3.2.5 Observe and evaluate the system. The final stage in the systems development research methodology is to observe and evaluate the system to determine compliance with the stated requirements, assess its impact on users and groups, and identify desired improvements. Use of the SPA prototype was observed during case studies described in [15]. Lessons learned during systems development and the case studies were used to revise the SPA prototype and identify future research directions.

4. Results: SPA systems development The goal of this research was to design and develop a new system that provides easy-to-use support for collaborative scenario and process model development. The SPA prototype evolved from the lessons learned in previous research [15, 17] and the integration of two DOD funded research prototypes: (1) Process Modeler and (2) Scenario Modeler. Results of this research are presented in the following sections for the five stages of the systems development research methodology [22].

4.1 Construction of a conceptual framework The CSEM scenario framework, collaborative scenario elicitation methodology, and contextual scenario data model developed and revised during previous research [15] served as the overarching conceptual framework for this research. This framework served as the starting point

for investigating the required functionality for the SPA prototype. Next, the business process modeling literature was studied to identify alternative approaches for satisfying those requirements. Results of these first two steps were analyzed to develop an integrated scenario and process modeling framework for the SPA prototype. Finally, a brief overview of the SPA system building process is provided in section 4.1.3. 4.1.1 Core SPA prototype functionality requirements. The lessons learned from earlier research [15, 17] were combined with previous experiences in developing general-purpose and modeling GSS to identify five core requirements for SPA: 1. SPA must include the ability to hierarchically decompose processes to multiple levels and allow commenting on all processes. GroupSystems Group Outliner functionality served as the baseline since it provides collaborative support for process decomposition and users consistently rated Group Outliner very easy-ofuse. 2. SPA must implement the essential features of a modeling GSS including a user-comprehensible interface that focuses on information the user can provide. Lessons learned from development of Activity Modeler and Group Data Modeler were used to guide implementation of this capability. 3. SPA must be application-specific and include prompts for scenario and action data included in the integrated contextual scenario and business process data model. 4. SPA must provide flexible support for an iterative methodology for collaborative scenario and process model development. It must also support easy integration into the CSEM process and with existing CSEM tools. 5. SPA must include an integrated graphical process modeling capability. Initially, it should support UML's Activity Diagram. Future enhancements should also provide the capability to support alternative representations, e.g., IDEF3. 4.1.2 Integrated scenario and process modeling framework. The initial conceptual framework and data model developed during earlier research [15] were specifically designed to support scenario elicitation. Scenario and process modeling have very different constructs and terminology. These differences had to be reconciled before an integrated scenario and process modeling capability could be included in SPA. One of the first major challenges was to define what the basic components that are successively decomposed to create a SPA process model are and what they should be called. The CSEM specifies that business activities and functions should be decomposed into subactivities/functions. For each of the subactivities/functions with system implications, users identify business scenarios which provide concrete

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4


examples of how users currently accomplish those functions. Business scenarios are then decomposed into the specific steps or actions that users perform during those scenarios. Using CSEM as a guideline, the basic SPA components could be called activities, functions, sub-activities, scenarios, steps or actions – depending on the level of the decomposition. From a graphical process modeling perspective, processes are decomposed into sub-processes, which are further decomposed into tasks or actions. The UML Activity Diagram decomposes activity states into action states. Again, the name of the component depends on the level of decomposition. The IDEF3 Process Description Capture Method eliminates this dependency by calling all the basic components at all levels “Units of Behavior” which represent a function, process, scenario, activity, operation, decision, action, event, or procedure [19]. While the IDEF3 concept provided the simplicity desired for the SPA prototype, it was not clear whether all these different components could be consolidated into one generic element. A comparison of data requirements for all levels for both scenarios and processes showed that there was enough overlap to support consolidation into a single basic component with standardized data elements. The other advantages of consolidating into a single component are: 1. The abstraction problem (e.g., where one person’s scenario is another’s step, or where a scenario step in the requirements phase becomes a use case during design) does not have to be dealt with – all components will be the same. 2. The user does not have to understand the differences between the separate components. These advantages, when combined with the results of the data analysis, resulted in the decision to combine all SPA components at all levels of decomposition into a single generic component. The next question was what to call this generic component. The IDEF3 term, “unit of behavior,” seemed too awkward. After extensive discussion, the term “process” was selected as the generic term to represent the basic components of the SPA model, regardless of decomposition level. Therefore, the term “process” is used whenever the component being referred to could be an activity, function, sub-activity/function, process, sub-process, scenario, task, action, or step. 4.1.3 SPA system building process. The SPA prototype was developed using a collaborative, incremental, rapid prototyping approach to systems building. Development of SPA was a team effort, with each team member having clearly defined roles and responsibilities. The project leaders served as primary researchers and requirements engineers. Other team members served as system architect, interface designer, and programmers. Critical SPA requirements, priority, design, and development

decisions were jointly discussed during weekly project team meetings. All team members participated in the discussion, although the individual responsible for a particular area had final decision authority. Increments were time-constrained to coincide with research contract deliverables. Understanding the strengths and weaknesses of the prototyping process used was critical to successful on-time delivery of the first version of SPA to the research sponsors.

4.2 Development of a SPA system architecture The SPA prototype is based on a two-tier Client-Server architecture to support distributed collaborative computing. This architecture allows users to access SPA through Java-enabled Web browsers regardless of their location, time or type of computer. The server is capable of supporting simultaneous connection of multiple users. SPA consists of three main components: the server component, client component and supporting administration module. Server. The server component of SPA is developed in Delphi and resides on a Windows NT server. It processes the requests from clients, stores or retrieves the data from the back-end Paradox database, and broadcasts update messages to each active client. There are two types of tables in the Paradox database for the usage of SPA: administration tables and process-related tables. Six administration tables keep information about sessions, users, privileges and login passwords, etc. The other six tables store all the data related to processes created in the sessions. In order to keep consistency and integrity of the data in a multi-user environment, the server implements required concurrency controls. Client. The SPA client component is initialized by a Java applet that is also stored on the NT server. The Java applet is downloaded through the Internet to the client computer whenever an authorized user logs in. A copy of the process model data is downloaded to the local machine when the user selects a specific process modeling session. The client component has a graphical user interface that allows users to perform a wide variety of tasks, such as viewing, adding, editing or deleting information about processes in the model. Whenever a user updates the data, the process model on the local machine will be modified only after the corresponding data physically stored in the server database has been changed successfully. This design ensures the consistency of the process model. Although the client component can be used by any authorized user, facilitators have additional administrative options, including: 1. Setting or modifying the session configuration by specifying what panels and prompts to display through the facilitator panel.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5


2. Granting or modifying user privileges by defining whether users have the rights to view, add, modify, or delete various components of the model. 3. Viewing deleted processes and recovering them if necessary. Administration module. The administration module is a generic module supporting several different projects. For SPA, it is primarily an administration utility used by system administrators and facilitators. Administrators are specially designated users who have all privileges including those required to create new SPA sessions, maintain user lists/passwords, and designate users as session facilitators. Facilitators have access to their own sessions and can use the administration module to add/remove users to/from a session, and perform general session file management and clean-up, etc.

used for process depiction (see right side of Figure 4). The hierarchical tree is a relatively simple tool which supports the decomposition of processes into sub-processes and tasks.

4.3 Analysis and design of SPA SPA analysis and design was a team effort consisting of the logical database and user interface design, discussed next. SPA object classes are summarized in section 4.4. 4.3.1 Logical database design. The logical data model was developed by adapting the proposed contextual scenario data model based on the integrated scenario and process modeling concepts described in section 4.1.2 and adding the new data items that were identified during development of the integrated concept. The data model was then revised further to take advantage of the flexibility provided by the proposed user interface design. The primary entity in the model is the process. All other entities are either directly or indirectly related to process. 4.3.2 User interface design. The functional requirements provided by the project leaders were the primary input for the user interface design process. Different non-functional interface alternatives, each with different tradeoffs dealing with ease of use and data display, were mocked up using Microsoft Visual Basic. By presenting and discussing strengths and weaknesses of different approaches during the weekly team meetings, the best components of each design alternative were combined to create the final screens. Throughout the design process, all of the interface design considerations, alternative screen mockups, intended functionality, and system behaviors were stored in a web-based planning and design repository which served as the primary focus point for the weekly team meetings and allowed each of the team members to revisit the screen mockups outside of the regular meeting times. The final interface design contained three primary components: a hierarchical tree structure for process decomposition (see left side of Figures 3 and 4), a tabbed panel text entry area to record details about each process in the tree (see right side of Figure 3), and a graphical area

Figure 3. Process hierarchy and information panels The text entry area was designed to capture different types of detailed information for each process in the tree structure. The two categories of data that can be captured for each process: (1) fixed-structure data (e.g., Overview, Metrics, Actors) and (2) generic, unstructured textual data (e.g., Description, Prerequisites, Results), each with its own layout and appearance in the tabbed panel display. The tabbed-panel approach provides a method for displaying and accessing a great deal of information while simultaneously conserving screen space. The fixedstructure panel format cannot be changed, and contains fields which are geared to recording specific data about each process (e.g., cost, frequency, viewpoint, equipment requirements). The generic panels provide the flexibility to customize SPA to suit specific process modeling needs in a wide variety of organizations. Each panel contains a single large text box that allows the users to describe a certain aspect of the current process (e.g., Prerequisites, Results). Each individual item input by a user creates a new entry in the respective panel. A session facilitator has the ability to focus the attention of the users to specific aspects of the process being modeled by making specific tabbed panels visible or not. For example, if all panels but the Description panel are hidden from view, the users can focus their attention on describing each process in the tree. Once group consensus has been achieved on the process description, other aspects of the process may then be modeled by making the appropriate panels visible. Additionally, if there is some dimension of the process for which a generic text panel does not exist (e.g., security issues), the

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6


facilitator can either rename an existing generic panel, or create a brand new generic panel to fill that need.

Figure 4. Graphical view of a process The final interface component involves the graphical diagram capability. This functionality is placed on the last of the tabbed panels, and is labeled “Graphical Diagram.” The graphical diagram allows more details to be added to the hierarchical process decomposition contained in the tree structure such as process sequence, decision logic, and conditional flow.

4.4 Building the SPA prototype 4.4.1 Development environment. Java was selected as the programming language for the Client component of SPA for a number of reasons. Java is an object-oriented programming language and has extensive built-in networking capabilities that allow us to develop distributed applications. Java is also portable and architecturally neutral. This means it can be executed on any platforms that supports Java virtual machine, such as Windows NT, Windows 95/98, Unix or Macintosh. 4.4.2 SPA object model. The Client component of SPA consists of five different types of objects: 1. Process Model objects (e.g., Process, Actor, Object) 2. GUI objects for regular users (e.g., TreePanel, OverViewPanel, ActorPanel, GraphPanel) 3. Additional GUI objects for facilitators (e.g., FacilitatorFrame, UserPrivPanel) 4. Communication objects (e.g., Client, ClientEvent, ClientAdapter, ClientListener) 5. Administration objects (e.g., AdminFrame, UserList) All the activities related to a process are actually performed by the ProcModel object. Other objects are used for GUI, communication, or administrative control purposes.

4.4.3 Implementation. When a session is generated using administration module, a sub-directory for that session is automatically created on the server. The six processrelated tables are created and stored in that sub-directory. Then, a user can download the Client component through the Internet and log into that session. A protocol based on Java Socket was designed and implemented for communication between the client and the server. Before sending update requests to the server, the client has to request locks on all related data items from the server (row-level locking). If the locking requests are approved, the clients will send an SQL-embedded request to the server. The server is responsible for verifying the user privileges and parsing the incoming request. If the user has the right to update the data and the request is correctly parsed, the corresponding data items in the Paradox database are modified and locks held by clients are released. Finally, the server broadcasts the change to all active clients. Each client will update their local copy of data and refresh the process model on the fly. SPA can also export a report of the generated process model in HTML format by using Delphi Dynamic Link Library (DLL) calls. In order to facilitate the communication among collaborative users, we also implemented a tool called ‘chat window’, which can be activated from the menu bar. It will pop up a small dialog window and the text that is typed by one user can be echoed to others. All the contents in the chat window will be stored in a table on the server. This tool was used in the field study and proved quite helpful in the distributed collaborative environment.

4.5 Observing and evaluating SPA The final stage in the SPA systems development research was to observe and evaluate the system to determine compliance with the stated requirements, assess its impact on users and groups, and identify desired improvements. Results of this evaluation were highly encouraging. Users consistently rated SPA over 4 (of 5) on ease of use. Detailed results are presented in [15].

5. Discussion Development of the initial SPA prototype was an exciting and frustrating process of discovery, solving problems, taking advantages of opportunities, and making compromises. Teamwork was essential, not only for successful development of SPA, but also as the source of synergistic solutions which have made SPA a flexible collaborative tool with application for a much wider variety of problem analysis tasks than originally planned. This section discusses some of these challenges, solutions, and lessons learned during the development process.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7


5.1 Conceptual framework Integration of the scenario concepts of activities/scenarios/actions and the process modeling concepts of processes/sub-processes/tasks into a single generic concept of process had both benefits and risks. The primary benefit was simplicity. Users would not be required to understand the differences between the different levels. Levels of abstraction could easily change as required for a specific process or task, again without the user needing to be concerned with the different concepts. The primary risk was that the process concept would be too general. Users could lose focus on identifying specific scenarios and actions required to accomplish those scenarios. There were also data model implications. The contextual scenario data model recommended capturing some similar and some different information at the scenario and action level. However, the SPA team was able to develop an integrated scenario and process data model which captured all required information. This integrated data model was implemented in the SPA prototype and successfully used during preliminary case studies [15].

5.2 System architecture The architecture is perhaps the biggest factor in determining the long-term success of a software project. The initial SPA architectural concept was simply to build some additional functionality on top of GroupSystems Group Outliner, similar to what had been done for Group Data Modeler. However, the system architect convinced the team that a client-server architecture should be used with the client developed as a Java applet, accessible with any Internet browser, so that SPA could easily support distributed meetings as well as traditional face-to-face meetings. Everyone was excited about the opportunity to add the distributed capability, but they were also somewhat leery about the potential impacts on performance and speed of development. Although some of these concerns proved to be valid, SPA’s web-based architecture is one of its strongest selling points. Observations from the field show that the architecture can meet the needs of scenario and process modeling on distributed computing. The characteristics and advantages of the SPA architecture are: ù Combination of a client (front-end part) that interacts with the user, and a server (back-end part) that interacts with the shared resources ù Hardware and operating system independence ù Multi-user and collaborative distributed computing ù Web-based data access and communication In addition, some potential problems with the SPA prototype architecture were identified. For example, a large number of users run into communication problems

caused by intensive network traffic or poor Internet connectivity. Unexpected complications in choosing a web browser were also experienced due to the incompatibilities in how different browsers support Java. Repeatedly, a specific function would work in Microsoft Internet Explorer, but fail or work differently in Netscape, or vice versa. As a result of these inconsistencies, development and testing of the prototype version of SPA focused on Microsoft Internet Explorer (version 4.01).

5.3 Analysis and design Five core requirements defined the essence of SPA required functionality. Existing systems such as GroupSystems Group Outliner, Activity Modeler, Group Data Modeler, and IDEF3 process modeling tools such as KBSI’s ProSim provided excellent models for how to implement the five core requirements. However, the analysis and design required to transition from the core requirements to a detailed design for SPA was more complicated than anticipated. There were several key reasons for this problem. First, the initial expectations were simply unrealistic. Secondly, not all team members were familiar with the GroupSystems, collaborative modeling, and IDEF3 tools that were guiding SPA development. Others did not have real-world collaborative modeling or systems analysis experience, were not familiar with CSEM, or did not understand the role of scenarios in CSEM. Third, there were some of the features of the source tools that needed improvement. Finally, integration of scenario and process modeling continued to raise questions throughout development. The requirements analysis and design process involved weekly discussion meetings, multiple iterations, and extensive documentation. Perhaps the single greatest success factor during this phase of SPA was the webbased planning and design repository. This resource served as an asynchronous communication aid between group members, allowed each team member to access requirements, design plans, screen prototypes, and even to review intended functionality of SPA on their own time as well as during the regular weekly meetings. The repository also allowed the system builders to begin coding functioning prototypes much earlier in the overall project life cycle by allowing them to refer to the planning and design repository for the necessary system behaviors rather than waiting to have specific implementation questions answered by the project leaders. The value of this approach was magnified further by the various, and sometimes non-overlapping work schedules kept by the team members. The ease of screen design with Visual Basic was also a tremendous benefit since alternative screen interfaces could quickly be developed, placed in the design repository, presented to the project team, evaluated, and refined within extremely short time periods, often less

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8


than one week. These short design cycles proved to be a great asset to the team. The final design of the text entry areas for capturing process details also turned out quite differently from what the project leaders had originally envisioned as a collection of specifically labeled fields on a single form. Using such a collection of fields that were simultaneously visible severely limited the amount of data that could be displayed in each field, as well as limiting its usefulness. The solution to this overcrowding of fields was the implementation of the tabbed panel design which contributed a great deal of unexpected flexibility to SPA, such as allowing it to be customized for different settings by making specific panels visible or not visible to the users, and adding new panels. Thus, while satisfying primary design constraints, this approach also lends tremendous flexibility.

5.4 System building The overall goal of this project is to create a distributed collaborative process modeling tool. The proper architecture led to building the system successfully. Most of the problems associated with the Client/Server architecture were taken into consideration. Some methods for solving the problems featured our building process. 1. Java Socket-based communication technology. A communication mechanism between the Client and the Server program is established using Java Socket. 2. Row-level locking mechanism. Transaction-level integrity is kept in the data on the server, which must first be checked for concurrency control. 3. Java applet. Java applets can be downloaded from a Web server to a client machine, where they execute locally and are integrated into the client’s environment. Java applets can run in either Java-enabled browser or an applet view. 4. Restart and error handling. When a client machine has problems to retrieve data from the server in the middle of a session, users can activate a REFRESH menu function to reload the whole process model from server on-the-fly. Although the SPA prototype supports distributed collaborative characteristics and features a wide variety of functionalities, we have identified some limitations with the current version. First, the socket-based technology faces challenge in large-scale applications. Second, the row-level locking restricts the flexibility of the system because the whole record in the table has to be locked before any update, blocking other users’ access to that record. We also need to enhance some existing functionalities (e.g., the graphical process modeling capabilities) and implement new ones identified during the initial evaluations, as discussed next.

5.5 Observations and evaluations Feedback from the initial field evaluations of SPA were very positive, but also identified several areas needing improvement [15]. For example, while users found the generic text panels easy to use, they did experience some confusion with the fixed panels (e.g., Actors). The fixed panels are being reviewed and modified as necessary to reduce this confusion. The field evaluations also highlighted the need for additional facilitator functionality, especially to support distributed meetings. These capabilities will be added to future versions of SPA.

6. Conclusion and future research The SPA prototype serves as “proof-of-concept” that a web-based tool can be developed to provide support for collaborative process modeling in both face-to-face and distributed settings. Flexibility integrated into the architecture and design of SPA enables it to support a much wider range of process modeling and problem analysis tasks than originally planned, and has, in effect, resulted in creation of a first attempt at a “build-yourown” collaborative tool. Preliminary experiences with SPA have identified a number of improvements and areas for future research. First, to improve performance and scalability, the next version of SPA will integrate Common Object Request Broker Architecture (CORBA) and Java EJB. CORBA is an object-oriented architecture developed by the Object Management Group (OMG) to provide interoperability between objects in a heterogeneous, distributed environment. It is completely platform-independent and is regarded as the next generation of middleware. The communications between clients and server will be based on method calls, thus alleviating network difficulties by reducing the traffic between the client and server. It will also support wrapping of platform-dependent classes in a Java package to reduce problems associated with the inconsistencies between different web browsers. Second, the performance of SPA from the user’s perspective will be improved by employing a finer-grained locking capability (such as a column-level locking) for concurrency control. Finally, research will continue on identifying and evaluating additional functionality that should be incorporated into SPA.

7. References [1] Barker, R., and Longman, C., CASE Method: Function and Process Modeling Addison-Wesley, 1992. [2] Booch, G.; Rumbaugh, J.; and Jacobson, I., The Unified Modeling Language user guide. Reading, MA: Addison-Wesley, 1999. [3] Butler, K.A.; Esposito, C.; and Hebron, R., "Connecting the design of software to the design of work," Communications of the ACM, 42 (1), 1999, 38-46.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

9


[4] Carroll, J.M. ed. Scenario-based design: Envisioning work and technology in system development. , John Wiley & Sons: New York, 1995. [5] Curtis, B.; Kellner, M.I.; and Over, J., "Process modeling," Communications of the ACM, 35 (9), 1992, 75-90. [6] Davenport, T., and Short, J., "The new industrial engineering: information technology and business process redesign," Sloan Management Review, (Summer), 1990, 11-27. [7] Davis, A.M., "A comparison of techniques for the specification of external system behavior," Communications of the ACM, 31 (9), 1988, 1098-1115. [8] Dean, D.L.; Lee, J.D.; Orwig, R.E.; and Vogel, D.R., "Technological support for group process modeling," Journal of Management Information Systems, 11 (3), 1994-95, 43-63. [9] Dean, D.L.; Lee, J.D.; Pendergast, M.O.; Hickey, A.M.; and Nunamaker, J.F., Jr., "Enabling the effective involvement of multiple users: Methods and tools for collaborative software engineering," Journal of Management Information Systems, 14 (3), 1997-98, 179-222. [10] Dean, D.L.; Lee, J.D.; and Vogel, D.R., Group tools and methods to support data model development, standardization, and review. In J.F. Nunamaker, Jr. and Sprague, R.H., Jr., (eds.), Proceedings of the Thirtieth Annual Hawaii International Conference on the System Sciences. Los Alamitos, CA: IEEE Computer Society Press, 1997, 386-420. [11] Dean, D.L.; Orwig, R.E.; and Vogel, D.R., "Meeting methods for use with EMS tools to enable rapid development of quality business process models," Group Decision and Negotiation, Forthcoming. [12] Dean, D.L.; Pendergast, M.O.; and Aytes, K.J., "Computer-supported collaborative modeling : the Enterprise Analysis Project," ACM SIGOIS Bulletin, (April, Special Issue on Enterprise Modeling), 1997. [13] Dennis, A.R.; Nunamaker, J.F., Jr.; and Vogel, D.R., "A comparison of laboratory and field research in the study of electronic meeting systems.," Journal of Management Information Systems, 7 (3), 1990-1991, 107-135. [14] Fowler, M., and Scott, K., UML distilled: Applying the standard object modeling language. Reading, MA: AddisonWesley, 1997. [15] Hickey, A.M., Integrated Scenario And Process Modeling Support For Collaborative Requirements Elicitation. Unpublished Doctoral Dissertation, Management Information Systems Department, Tucson, AZ: University of Arizona, 1999. [16] Hickey, A.M.; Dean, D.L.; and Nunamaker, J.F., Jr., Setting a foundation for collaborative scenario elicitation. In R.H. Sprague, Jr., (ed.), Proceedings of the Thirty-Second Hawaii International Conference on System Sciences [CDROM]. Los Alamitos, CA: IEEE Computer Society, 1999.

[17] Hickey, A.M.; Dean, D.L.; and Nunamaker, J.F., Jr., "Establishing a foundation for collaborative scenario elicitation," DATABASE, Forthcoming. [18] Lee, J.D.; Dean, D.L.; and Vogel, D.R., "Tools and methods for group data modeling: A key enabler of enterprise modeling," SIGGROUP Bulletin, 18 (2), 1997, 59-63. [19] Mayer, R.J.; Cullinane, T.; deWitte, P.s.; Knappenberger, W.B.; Perakath, B.; and Wells, M.S., Information integration for concurrent engineering(IICE): IDEF3 process description capture method report. Wright-Patterson Air Force Base, OH: U.S. Air Force Armstrong Laboratory, 1992. [20] Mayer, R.J.; Menzel, C.P.; Painter, M.K.; deWitte, P.S.; Blinn, T.; and Perakath, B., Information Integration for concurrent engineering (IICE): IDEF3 process description capture method report. Wright-Patterson Air Force Base, OH: U.S. Air Force Armstrong Laboratory, 1995. [21] Nunamaker, J.F., Jr.; Briggs, R.O.; Mittleman, D.D.; Vogel, D.R.; and Balthazard, P.A., "Lessons from a dozen years of group support systems research: A discussion of lab and field findings," Journal of Management Information Systems, 13 (3), 1996-97, 163-207. [22] Nunamaker, J.F., Jr.; Chen, M.; and Purdin, T.D.M., "System development in information systems research," Journal of Management Information Systems, 7 (3), 1991, 89-106. [23] Pendergast, M.; Aytes, K.; and Lee, J.D., "Supporting the group creation of formal and informal graphics during business process modeling," Interacting with Computers, vol.11, no.4 (April), 1999, 355-73. [24] Rational, Unified modeling language standard, Version 1.1. .Rational Software Corporation, 1997, [25] Vogel, D.R., and Nunamaker, J.F., Jr., "Group decision support system impact: Multi-methodological exploration," Information & Management, 18 1990, 15-28. [26] Vreede, G.J. de, "Group modeling for understanding," Journal of Decision Systems, Vol. 6, No. 3 1997, 197-220. [27] Vreede, G.J. de, "Collaborative Support for Design: Animated Electronic Meetings," Journal of Management Information Systems, Vol. 14, No. 3 (Winter), 1997-1998, 141164. [28] Vreede, G.J. de; Euck, D.T.T. van; and Sol, H.G., "Dynamic Modelling for Re-engineering Organizations," Journal of Information Systems and Operational Research (INFOR), Vol. 34, No. 1 (February), 1996, 28-42. [29] Zigurs, I., Methodological and measurement issues in group support systems research. In L.M. Jessup and Valacich, J.S., (eds.), Group support systems: New perspectives. New York: Macmillan, 1993, 112-122. [30] Zurawski, R., and Zhou, M.C., "Petri nets and industrial applications: A tutorial," IEEE Transactions on Industrial Electronics, 41 (6), 1994, 567-583.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

10