Customizing the Representation Capabilities of Process Models ...

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

VOL. 41, NO. 1,

JANUARY 2015

19

Customizing the Representation Capabilities of Process Models: Understanding the Effects of Perceived Modeling Impediments Binny M. Samuel, Linwood A. Watkins III, Andrew Ehle, and Vijay Khatri, Senior Member, IEEE Abstract—Process modeling is useful during the analysis and design of systems. Prior research acknowledges both impediments to process modeling that limits its use as well as customizations that can be employed to help improve the creation of process models. However, no research to date has provided a rich examination of the linkages between perceived process modeling impediments and process modeling customizations. In order to help address this gap, we first conceptualized perceived impediments to using process models as a “lack of fit” between process modeling and another factor: 1) the role the process model is intended for; and 2) the task at hand. We conducted a case study at two large health insurance carriers to understand why the lack of fit existed and then show different types of process modeling customizations used to address the lack of fit and found a variety of “physical” and “process” customizations employed to overcome the lack of fits. We generalize our findings into propositions for future research that examine the dynamic interaction between process models and their need to be understood by individuals during systems analysis and design. Index Terms— Software process models, requirements/specifications management, requirements/specifications process, requirements/ specification stools, UML, use cases, activity diagrams

Ç 1.

INTRODUCTION

A

recent Gartner survey suggests that improving business processes is the top business priority for CIOs [1]. Process modeling, which employs process models to specify, describe, understand and document processes [2], plays a central role in redesigning organizations’ processes and understanding dependencies within a business process as well as in the overall analysis and design of systems [3]. Several different process models have been reported in prior research, for example, flowcharts for documenting processes to identify weaknesses in internal controls [5], data flow diagrams [6] and UML (Unified Modeling Language) behavior diagrams for documenting processes [7], event-driven process chain (EPC) diagrams for SAP [8], and text-based “informal” diagrams and narratives for gathering information about a domain from end users [9]. During conceptual representation of a process, a process model provides a notation and formalism that can be used to construct a high-level description, referred to as a process schema, of the real world. A process schema includes both the graphical representations of business processes as well as the text-based process requirements for the analysis and design of software [3]. From the perspective of analysis and design of systems, process modeling begins with business process analysis, or, requirements engineering,

B.M. Samuel is with the Ivey Business School, Western University, 1255 Western Road, London, ON N6G0N1, Canada. E-mail: [email protected]. L. Watkins, A. Ehle, and V. Khatri are with the Kelley School of Business, Indiana University 1309 East 10th Street, BU 570, Bloomington, IN 47405-1701. E-mail: [email protected], [email protected], [email protected].

Manuscript received 28 Apr. 2013; revised 5 Aug. 2014; accepted 8 Aug. 2014. Date of publication 14 Sept. 2014; date of current version 14 Jan. 2015. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TSE.2014.2354043

and culminates with the actual software logic that is implemented by software developers [4]. While process modeling is often used for managing business processes [10]–[17], several impediments in its use have been identified [18]. Using focus groups and semi-structured interviews, Rosemann identified several pitfalls of using process modeling [19], [20]: failure of models to link to critical business issues, lack of clear accountability for models, and lack of a well-defined modeling methodology. In a survey of 171 systems analysts, Dobing and Parsons [21], [22] identified why particular UML models were not used: the models were not useful for most projects in the organization, creating and maintaining the process schemas provided insufficient value and outweighed the cost (resources) involved, and the information presented by the various models were redundant. We define an impediment to process modeling as obstacles that hinder the effective management of the lifecycle of process modeling. Prior research suggests that process modeling is often customized in order to be used in practice [23]. For example, prior research has suggested that process modeling methodologies require tailoring for use in a specific project [24], [25]. In the context of UML, Dobing and Parsons, suggest that the use of process models is not standardized in practice and that they must be customized to fit within the context of a project. This is not surprising since UML was designed to be a general purpose language that tries “to be all things for everyone” [24], [26], [27]. Similarly, Indulska et al. [28] also found a lack of standardization for process modeling to be both a current issue and future challenge among academics, vendors, and practioners. Recker et al. [14] suggest that “instead of using ‘vanilla’ specification of a language [model], organizations often follow a set of

0098-5589 ß 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

20


modeling conventions that restricts the set of language constructs to be used and sometimes even apply new meanings to particular constructs.” Prior research has examined specific types of customizations such as enforcing consistent domain terminology for business processes in order to compare/normalize models created by multiple individuals [29], using verb-object naming conventions for activity labeling [30], and even using electronic meeting systems to facilitate creation of process models by multiple individuals simultaneously [31], [32]. We define a process modeling customization to be an intentional alternation of existing constructs—that is, addition,1 change or removal—in a process model; it also includes changes in methodology or processes put in place to help overcome the impediments to using process models. While two streams of prior research have examined perceived impediments to process modeling and process modeling customizations, in this research we seek to understand the relationship between perceived impediments to process modeling and process modeling customization. We propose that process modeling customizations are a direct consequence of perceived impediments to process modeling, and in doing so we bridge two prior streams of research. While we focus on the business process analysis phase of process modeling, we emphasize that business process analysis (i.e., requirements engineering with users) intertwines with the software process logic that is designed for implementation by software developers. We focus on impediments that stem from: 1) different roles that employ process models; and 2) divergent tasks that process models are used for. From the perspective of roles, it appears that process models are not always completely understood by the analysts (i.e., an IT role) who are supposed to create them [21], [22], nor by business roles who are supposed to understand them. From the perspective of tasks, while process models may be useful for several tasks within a project, in general, prior research questions their usefulness to complete certain categories of tasks in projects, for example, traceability of requirements [21], [22]. Previous work has examined modeling impediments from an ontological perspective (i.e., construct deficiency); however we examine impediments from a cognitive perspective and thus address the call for more research on modeling in context [34]. As such the research question we address is: “How do perceived modeling impediments influence process modeling customizations?” To address our research question that emphasizes a rich description of a phenomenon of interest, we conducted three case studies at two large healthcare carriers, referred to as Insurainc and CareCorp. The projects that we examined used different types of process models, e.g., use case diagrams and activity diagrams (behavior diagrams of UML) along with text-based process requirements documentation, and our findings are based on document reviews and interviews. In this research, we adopt a cognitive paradigm of humans as information processors that suggests a person’s ability to process information for a task may be impaired due to the quality of knowledge structures (i.e., process schemas) 1. Prior research has reported that individuals often combine grammars from different models to help represent the system from multiple perspectives [33].

VOL. 41, NO. 1,

JANUARY 2015

employed. In our research, the roles (i.e., persons) are either business or IT, the tasks are ones that occur during systems analysis and design (primarily requirements structuring/ representation, with some design2), and the information representation of interest is process models. The rest of the paper is organized as follows. In the next section, we conceptualize perceived impediments to process modeling in terms of a “lack of fit” between process modeling and one of two factors: 1) the role the model is intended for; and 2) the task at hand. In Section 3, we describe the methodology and present the context of the projects where we collected the data. In presenting findings in Section 4, we outline the underlying perceived impediments that led to customizations and how Insurainc and CareCorp customized process models. We describe the implications of our findings for research, by presenting propositions for future research, and practice in Section 5 and conclude in Section 6.

2

CONCEPTUAL FOUNDATION AND PRIOR RESEARCH

While process modeling is generally viewed as beneficial [36], prior research indicates several differences between the conceptualization of process models and how they are applied in practice. For example, while the object management group (OMG) has proposed several different types of process models—activity, use case, state machine, sequence, communication, interaction and timing [7], [37]—prior research suggests that using process model notations can be quite complex and overly detailed for practitioners [3]. Furthermore, while process models often contain tens of constructs, not all constructs available for modeling are equally important; for example, only 20 percent of UML is needed to specify 80 percent of the aspects of a typical system [38]. From a process perspective, process modeling is also somewhat messier than prescriptions for their use; for example, in practice, process modeling is much more iterative with multiple within-phase reviews (e.g., within the analysis phase) and not just at the end of a phase (e.g., when moving from analysis to design) [39]. Because of the differences between how process modeling is conceptualized and how it is applied in practice, we assert that projects employ process modeling customizations to overcome perceived impediments to process modeling.3 Process modeling customization refers to the purposeful alteration to both process models—that is, by adding and updating constructs— as well as the associated processes employed to overcome the perceived impediments to process modeling. 2. We recognize that the phase of analysis can be treated distinctly from design. However prior research does examine these two phases jointly as there is an overlap in the use of the same representations across these phases [35]. For example, a representation that is created as an output of the analysis phase is an input to the design phase. Furthermore, in our research, the roles in the organizations spanned aspects of both analysis and design. Thus we consider these two phases jointly. 3. Note that process modeling customization differs from both process modeling errors and systematic problems. While errors are inadvertent mistakes that are caused as a result of improper use of process models, systematic problems refer to re-occurring mistakes that continually appear in process schemas [40].

SAMUEL ET AL.: CUSTOMIZING THE REPRESENTATION CAPABILITIES OF PROCESS MODELS: UNDERSTANDING THE EFFECTS OF...

21

Fig. 1. The theory of cognitive fit and dual-domain problem solving.

Framing our research in the context of humans as information processors, we employ the theory of cognitive fit [41]. The theory of cognitive fit has its origins in cognitive science [42], [43] and has been applied to all phases of systems development (see for examples [44]–[51]), including analysis and design. Cognitive fit suggests that congruence (i.e., fit) between the information required by a task and the information emphasized in a problem representation, as integrated in one’s mental representation for the task solution, will facilitate an efficient and effective problem-solving performance with less cognitive effort; see Fig. 1a. To incorporate the significance of understanding both systems and application domains in modeling (see, also Khatri et al. [48]), we extend cognitive fit to propose dual-domain problem solving. Prior research suggests that systems problem solving requires both knowledge of the application domain (that is, the area of business such as accounting, sales) as well as that of the systems domain (that is, representations, methods, techniques and tools for the development of systems) [52]. That is why, our dual-domain problem solving model includes two (cognitive) subtasks, that of understanding the application and systems domains. While we differentiate between internal and external representations of the application domain [47], we view them as two indispensable parts [53] wherein internal representations are the knowledge structures that need to be retrieved from the memory and external representations refer to knowledge structures in the environment. The cognitive fit occurs between the mental representation of the systems task and the mental representation of the application domain, which are integrated during the formation of the mental representation for task solution, and subsequently leads to problem solution. From a cognitive

perspective, one needs to take into account the background and knowledge of the user, both in the application as well as in the system domains. In other words, one needs to examine the fit between representation and the role it was intended for. Second, one needs to examine the fit between a representation and the associated task. Consequently, we conceptualize perceived process modeling impediments to result in a lack of fit between process modeling and one of two factors that impede individuals from using process models. The first factor, the role the process model is intended for, encapsulates a lack of understanding due to divergent skills and backgrounds of individuals who use the process models. The second factor is associated with the task at hand and highlights that process models may not be apt for a given task. Table 1 summarizes prior research that has examined these specific perceived impediments to process modeling and we describe each lack of fit below.

2.1 Lack of Fit between Models and the Role It Was Intended for Prior research suggests that the effective use of models requires users to have certain background and skills thereby implying that models need to be role-specific. For example, Browne and Ramesh [9] and Castro et al. [60] argue that informal models are more appropriate for early stages of information gathering, whereas semi-formal models are more appropriate for the later stage of representation of the gathered requirements. From the perspective of IT-oriented roles, process models such as activity and use case diagrams are not always well understood by the IT analysts who are supposed to be creating them [21], [22]. From the perspective of business-oriented roles, such users of process models do

22


VOL. 41, NO. 1,

JANUARY 2015

TABLE 1 Perceived Impediments to Process Modeling Perceived impediments to the use of process models

Prior research

Lack of fit between models and the role it was intended for

Not well understood by analysts [21], [22], [54]–[56] Excessively complex for end users [57], [58] Not self-explanatory for end users [19] Too technical focused for end users [20] Misinterpretation by end users [2] Lack of one standard confuses end users [20] Too much detail for all users [2], [20]

Lack of fit between models and the task at hand

Not useful for most projects [21], [22] Lack of details [20] Lack of traceability [59] Lack of applicability [20] Limits use of creativity in problem solving [2], [20]

not fare well in their attempts to understand process schemas either. Prior research has identified several reasons why some process models are excessively complex for business roles: excessive number of constructs [57], [58], the tendency to focus on IT solutions [20], and lack of intuition around their intended use [19]. Additional confusion for business roles may occur as there are many competing standards and purposes available for process modeling [20], and that there is a tendency for process schemas to contain too many details about a process [2], [20]. In summary, prior research suggests that different process models may be construed as overly complex for understanding by different roles [63], [64].

2.2

Lack of Fit between Models and the Task at Hand Process models are known to be useful for several tasks such as representing business processes, facilitating communication (e.g., between users and IT analysts), supporting decision-making (e.g., cost analysis, scenario analysis, and simulation), specifying software system requirements, designing exception handling [65], [66], implementing system requirements, and software testing [62], [67]. However, prior research questions the suitability of process models for certain categories of tasks [21], [22]. For example, prior research suggests that process models lack the ability to support tasks that require capturing certain context-specific information such as risk [20]. Additionally, process models may lack sufficient details and traceability that would make them useful for software development [18], [20], [59], [68]; for example, translating a business process to executable software [62]. Furthermore, prior research suggests that the focus on the practice of creating a process schema may divert attention away from the overall task at hand, that is domain understanding for systems development, thereby limiting the ability of an individual to apply other needed skills such as creativity in coming up with a novel solution to a problem [2], [20], [69]. Thus prior research has questioned the usefulness of process models with respect to certain tasks at hand.

3

METHODOLOGY

In order to understand the linkages between perceived impediments to process modeling and its associated

consequence (process modeling customization), a case study research methodology was chosen. This methodology was chosen for three reasons. First, since the notion of (lack of) fit is contextual to the role and the task, a case study allowed us to understand the nuances associated with subsequent customizations. Second, while prior research does identify the significance of roles, tasks, and customizations separately, we are not aware of prior research that has attempted to establish linkages between these factors. Thus a case study methodology would allow the examination of theoretical linkages between the aforementioned factors. Third, prior research in software engineering that seeks to examine the rich context of process modeling has utilized a case study methodology. For example, Bandra et al. [70] used a case study to richly describe the phenomena of success factors and success measures for the use of process models for projects in organizations. Similarly, we wanted to deeply understand the relationship between process modeling impediments and process modeling customizations that might be employed to help realize the benefits of process models for projects in organizations. Our methodological approach allowed analysis of unique case features and opportunities for triangulation [71]. The initial within-case data analysis is descriptive and was reported back to the lead participants. By satisfying the logical tests of construct validity and external validity [72], methodological problems associated with case-based research were avoided [73]. Construct validity was achieved by collection of data from multiple sources of evidence [74]: multiple informants who worked on projects that involved process models, i.e., business and IT, the lead participant’s review of our case study report, and a review of multiple process model documents. Internal validity was established by our selection of credible informants who had worked on projects that utilized process models and who had a good understanding of systems development (see Table 3 “Years of IT experience”). As with all case study research, the goal is to provide a rich description of a phenomenon of interest and this is done at the expense of external validity. However, by having multiple projects and organizations involved in this current study, we temper some concerns that the perceived


23

TABLE 2 Summary of Projects Evaluated Project A Overview

Enhancement of an underwriting system used for quoting Insurainc’s guaranteed-cost client renewals

# analysts/total users (not concurrent)

4 Analysts 200 users

Technology (programming language, etc.)

Web: C# Database: SQL Server 2005 Pricing Engine: Excel, PAGOS 6 months Internal

Timeline/time needed Users (internal/ external) Impact due to federal/ state government regulation

States have specific legislation regarding standards for certain product offerings or for specific benefits

impediments to process modeling and process modeling customizations are unique to just our context. We also have established generalizability [74] as our findings of perceived impediments to process modeling and process modeling customizations support concepts established from prior research. Furthermore, we address external validity via propositions for future research [75]. Our case study methodology embraced a perspective that mixed elements from a neopositivist perspective (i.e., interviewee as knowledge source) and a romantic perspective (i.e., emphasis on having a natural conversation) for the interviews conducted as part of the data collection [76]. We believe that the interviews were sources of information from knowledgeable individuals who were aware of how process models were being used in the organization and why process models were being used in that specific manner. To that point, key interview questions were formulated to be used as part of an interview script [77] (see Appendix, which can be found on the Computer Society Digital Library at http:// doi.ieeecomputersociety.org/10.1109/TSE.2014.2354043, for the Interview Protocol). However, the researchers conducting the interviews actively listened and improvised as needed during the conversation to richly engage the interviewees with respect to the perceived impediments to process modeling as well as the customizations employed [76]. By identifying two organizations, referred to as Insurainc and CareCorp, within the health care industry that currently use process models (in this case UML diagrams), a criterion sampling approach was employed [78]. While there are several purposes for process modeling, process modeling at Insurainc and CareCorp was primarily conducted for systems analysis and design.

3.1 Site Selection The chosen sites, Insurainc and CareCorp, operated in an environment with a high degree of external regulation which in turn made them cognizant of the importance of requirements documentation and assurance via process schemas. Both Insurainc and CareCorp are US-based

Project B

Project C

New system to allow smaller customers to subscribe to Insurainc’s insurance services. 7 Analysts 100,000 users

Middleware enhancement to make electronic transactions compliant for submitting electronic claims 15 Analysts; users were not affected by middleware

Web: C# Database: Oracle

Web: Java, Cþþ Databases: Oracle and DB2.

1.5 years External

2 years Internal/External

States have specific legislation regarding standards for certain product offerings or for specific benefits

Project was a result of new electronic transaction standards required by the federal government

national healthcare carriers with customers ranging from Fortune 500 employers to small companies and even individual customers. Traditionally these companies and the industry have focused on employer-sponsored plans, but as a result of the changing political and business climate both have better positioned themselves in the individual health insurance market. Lead participants at both the chosen sites suggested that their respective organizations were facing not only a changing marketplace, but that they felt like they were also at a disadvantage relative to their competitors from an operating expense perspective. This expense disadvantage is driven at least in part by a systems environment that is dependent on legacy systems which do not have the capabilities to meet marketplace demands. Insurainc and CareCorp have both undertaken a number of projects to improve existing systems and to develop new systems which would enable the marketfacing capabilities required while also reducing labor required for manual workarounds.

3.2 Project Selection Two projects at Insurainc, referred to as Project A and B, and one project at CareCorp, referred to as Project C, were studied to determine how process modeling was customized in the delivery of these projects. These three projects were selected to be indicative of the different types of systems projects at our sites, enhancement and new development, respectively. Table 2 provides a summary of the three projects. To ensure consistency in concepts around process modeling, most Insurainc project employees attended a UML training program held at a local college. This was required even for employees that had many years of IT experience as this helped establish a common framework of knowledge for all participants. Employees who were working on these projects and who were not able to attend the course had the training material available to them for their review. CareCorp had developed several training courses with tracks that were relevant to the various roles in the organization.

24


VOL. 41, NO. 1,

JANUARY 2015

TABLE 3 Interviews Conducted at Insurainc Role SA Lead BA/SA SA/Designer QA Lead SA (BA/SA/Designer) Programmer

Project Project A Project A Project A Project B Project B, Project C Project A and B

Project A was an enhancement of an underwriting system used for quoting Insurainc’s guaranteed-cost client renewals. The guaranteed-cost segment is focused on smallto middle-sized employers and generally follows the traditional insurance model. The client pays a premium to Insurainc that the company will use to pay claims for the client. Insurainc bears the risk in this type of relationship so if claims expenses are greater than the premium collected then Insurainc loses money; however if they are less, Insurainc can pay its operating expenses and earn a profit. Larger companies usually employ a different model where the risk is either shared between Insurainc and the company or where the company itself bears all the risk and Insurainc simply provides its network and claims paying capabilities. The main objective of the enhancement was to allow underwriters to choose between using paid claims or incurred claim experience when rating a renewal. A quote is determined by evaluating a client’s previous claims experience as well as the demographic information in order to predict future claims experience. The choice between paid and incurred claims allowed underwriters to make decisions on whichever claims provided the best information. The enhancement required acquiring the paid claims data from another system and integrating that data throughout the quote processing. The systems analyst working on this project needed to address changes both on the web front-end screens as well as to the back-end database procedures that drove the calculation of the premium. Besides a use case template that was developed, a system process flow was used to describe each step in a particular function. Project B entailed the creation of a new external facing website for individuals and small employers (with less than 50 employees) who may want to subscribe to the insurance services provided by Insurainc. The project also included all account administration functions from quoting to paying claims, because the existing legacy systems could not support clients of this size. Project B was important to the business strategy of Insurainc because of its increased focus on the individual consumer. The project was delivered using a fully outsourced development model. The delivery of the system was managed by Insurainc, but the resources actually developing the system were managed by a third party. This fact drove a need to be very specific in requirements definition, because missed requirements or misinterpretations of requirements could be costly, even more so because the third party was not familiar with Insurainc standard policies and procedures. The areas that were given the most focus were the Insurainc businesspricing logic and claims-paying logic. These areas were documented using a standard template that included

Code (Years of IT Experience) A-SAL(7) A-BA/SA(3) A-SA/Designer(8) B-QAL(14) B-SA1(10);B-SA2(3);C-SA1(14);C-SA2(25) AB-P(11)

standard definitions of business rules and requirements. Despite the apparent differences between the projects, both projects were web-based systems that were being developed for the same division of the company. Additionally, external regulation required adherence to requirements documentation and assurance via process schemas. Insurainc decided not to use any specific process modeling tool such as IBM’s Rational Rose, but instead used supporting tools such as Visio for diagramming and Microsoft Word and Excel for text-based documentation. Project C was a project required by the federal government for providers that wanted to be able to submit claims for reimbursement. It required that all electronic transactions for claims comply with the latest federal standard (hereafter referred to as x7000). For CareCorp, this meant they had to update their electronic data transmission formats to x7000. Each system owner in the organization had to document the flow of data in to and out of the systems they owned, including the different types of claims for which they might process a transaction (e.g., inpatient billing for a hospital, inpatient billing for a doctor, outpatient billing for a clinic, outpatient billing for a doctor, etc.). This project affected several of CareCorp’s systems and several people contributed to this project across multiple systems.

3.3 Interviewee Selection Seventeen retrospective interviews across three projects were conducted after all of the process modeling for the respective projects had been completed. The interviews spanned several roles within the organizations and covered several aspects including participants’ perceptions of impediments of process models used as well as the associated customization of process modeling. Table 3 presents the details of the individuals interviewed including their role, project, and years of IT experience. Each individual was contacted via the lead participant within the organization who helped identify the relevant individuals that should be interviewed about the use of process models within the projects. Each individual participated in an initial interview of 60 minutes; some individuals also participated in a follow-up interview of up to 60 minutes. Both organizations that we examined had a similar structure of roles within the respective projects. We interviewed several different roles: a Systems Analyst (SA) Lead, Systems Analysts, a Quality Assurance (QA) Lead, and a Programmer. A “lead” role referred to an individual (managerial role) who had oversight over several other individuals of the same role. The lead role was responsible for setting the overall direction of work for a


role, as well as all of the output of the tasks completed by individuals in that role. The SA roles spanned the duties of what one would expect from business analyst (BA) and designer job functions. Based on their experience and skill set, some SAs were more business-oriented and are referred to as BA/SA, while others were more technical and were referred to as SA/Designer.4 At times, individuals spanned all three job functions and were referred to as BA/SA/Designer. The QA role, an IT function, was responsible for ensuring that a high quality system–as requested by a customer–was delivered. They did this by creating test cases of actual situations (e.g., system load) and scenarios the production system might undergo. They then ran these tests and ensured that the system would perform as expected under various situations and scenarios. The QA role was the last checkpoint prior to allowing a system release into production. The role of a programmer was to implement not only a brand new designed system but also engage in any design enhancement requests (to an existing system). While the aforementioned roles were employed full time by either Insurainc or CareCorp, the programmers were typically part of a contracted service at both organizations. The specific assignment of a programmer to a specific piece of functionality was based on the priority of the projects as well as the availability of the programmer at the time the implementation was needed.

4

25

FINDINGS

To help structure our results within each lack of fit category, we first explain why the perceived impediments to process modeling existed in the projects (customization goal). We then describe both the physical customizations to the model as well as the processes put in place to help overcome the lack of fit to using process models. While physical customization, or customization of the notations, indicates alterations to process models, process customization refers to the processes that were put in place to address a lack of fit. 5 In presenting the findings in this format, we provide insights to the linkages between perceived process modeling impediments and their consequences (i.e., physical and process customizations). In the following, we describe the first lack of fit (that is, “model to role”) and then present the associated customization goals followed by the different customizations; we follow the same sequence for the second lack of fit, “model to task.” A summary of our results can be seen in Table 4. We assigned an identifier (prefix and sequential number) to customizations goals [CG], physical customizations [PHYS], and process customizations [PROC] that we employ in our subsequent narrative.

4.1 Lack of Fit between Model and the Role It Was Intended for Not all roles at Insurainc and CareCorp understood the process model that were being used during systems analysis and design mainly because the associated schemas: 1) took on too technical of a nature; 2) were overly complex and contained too much detail; and 3) provided little framing to help ease someone into understanding them. In general, this lack of fit was more closely associated with businessoriented roles as opposed to IT-oriented roles. The specific customization goals for this lack of fit included: 1) simplifying process models; and 2) presenting schemas in a manner that made them more understandable. We further describe these aspects below.

3.4 Data Analysis We obtained two types of data for analysis. First, we obtained several process schemas as well as process model templates that included placeholders for process model documentation. Second, we also created audio recordings of the interviews we conducted which were subsequently transcribed for analysis. As we analyzed the case study data, we sought to: 1) identify the specific process modeling customizations that were employed; and 2) understand why customizations were employed thus helping uncover modeling impediments. The case study data was examined by the researchers using NVivo 8 to help manage the analysis process. To better understand modeling impediments, two of the authors first independently sought to understand why customizations were undertaken at Insurainc and CareCorp based on the transcribed interview data using the coding scheme that was based on process modeling lack of fit; see Table 1. After individually coding the data, they met and resolved any differences they had and reached agreement on their findings. To identify process model customizations employed to resolve the modeling impediments, these same two authors again first worked independently to identify process model customizations employed, and then they met to resolve differences in their analysis of the data. Such an approach helped ensure that no customization was omitted [72].

4.1.1 Customization Goals [CG1] With regards to why Insurainc had to simplify process models, Insurainc had walk-throughs of systems development projects at different milestones of project completion. These walk-throughs had different types of participants based on the stage of the walk-through. Using process schemas as the basis for conversation seemed to be rare during these walk-throughs when business users were present; A-SAL noted “I don’t know that I would say that the diagrams [schemas] were heavily used in terms of walking through the process.” A-SA/Designer stated, “We didn’t cover it [process schemas] in as much detail in that meeting or they didn’t pick up on what we were trying to say.” The specific reasons process modeling seemed to be ineffective related to the fact that at times process schemas took on a technical system-oriented nature, thus, the process schemas became

4. A Designer was intended to be a role that could create the high level architectural design of the system based on the elicited requirements, while also specifying how the system would utilize and be connected to the existing technology in the respective organizations.

5. While research has been conducted on the methodologies that can be used during process modeling [79], [80, 81], process models have not fully embraced these methodologies and do not specify a specific process for using the models.

26


VOL. 41, NO. 1,

JANUARY 2015

TABLE 4 Summary of Process Model Perceived Impediments and the Associated Customization Lack of Fit model to role

model to task

Customization Goal

Physical Customization

Simplify models [CG1]

Higher level of abstraction [PHYS1] Fewer constructs used in a process schema [PHYS2] Alternative representation of construct [PHYS3]

Modify how schemas were presented to make them more understandable [CG2]

Increased use of text with diagrams [PHYS4]

Ensure that the elicited requirements are more apparent [CG3]

Requirements all listed in one place, traceability of requirements [PHYS5] Connecting all processes [PHYS6] Use cases tied to the Display Action Response Model [PHYS7] Activity Diagram contained specific data flows [PHYS8]

Connect process models to developed system [CG4]

too detailed for understanding by business users. Additionally, the process models lacked appropriate framing mechanisms that might have helped business users understand them. The challenge of process models taking on too much of a technical systems-oriented nature also hampered the ability of some IT personnel whose roles were less technical in nature, e.g., more dedicated to overall business requirements gathering; A-BA/SA noted “Sometimes there will be sections that will be very systems oriented. . .okay you have to change these stored procedures or that kind of stuff is going to be more difficult for someone to understand exactly what’s happening.” Another reason steps had to be taken to simplify process models was that the schemas could become overly complex and capture too much detail. When a schema was too detailed, users had little desire to wade through them, thus, limiting the potential benefit of creating the schema. B-SA1 commented, “It [process schema] can get very large depending on the complexity, and then once your document [process schema] reaches a certain point, I feel like no one wants to read it anymore. So at that point like the chore [is to] get people to read it and you’re ending up reading it to them in meetings and then, you know, when [they] don’t get a chance to really process it ahead of time, I feel like the quality of the document [process schema] isn’t as great, because you don’t have that collaborative approach [to creating it].” The large scope of systems might explain why specific schemas may have captured too much detail; A-SAL said, “We may have one application [system] that does a wide range of things [so] that each [thing] within [the system] may have a number of functions.” However, at the heart of it, process models fail to provide specific guidelines regarding the scope (coverage) that a schema should provide; B-SA1 commented that if, “scope is not clearly defined in the beginning, it’s hard to argue one way or another so sometimes small projects end up being gigantic.” In the case of CareCorp, the IT roles were actually developing the process schemas while the business roles were present as a way to foster communication as expressed by C-SA2, “What we encourage the teams to do is that they need to

Process Customization Multiple reviews [PROC1] Blended teams with domain and modeling knowledge [PROC2] Recorded online session [PROC3]

Sign-off process [PROC4]

System divided by screens instead of functionality [PROC5]

communicate with each other.” One of the main deliverables from their meetings was process schemas that documented the existing processes as C-SA1 shared, “The sessions really were about creating these documents [process schemas] and validating them.” Having a schema of existing processes could serve as the basis to define the future state of the system along with the requirements for the systems. However, CareCorp recognized that they had a variety of roles involved as well as variance within the roles as C-SA1 commented, “You have a variety of abilities in an organization, you might have someone that’s been called a systems analyst but really they have primarily been engaged in business analysis and have some understanding of the system. They don’t get to that technical acumen level where they understand how to analyze the system and model it.” [CG2] With regards to why Insurainc had to alter how process schemas were presented, process models were also difficult to understand at Insurainc because the schemas failed to provide enough context or framing needed to help users understand them. Specifically all the information was provided via a graphical representation with little written text. A-SAL commented, “Process models [schemas] don’t really help you interpret what requirements are needed, what the business needed, how to interpret what they were saying.” Understanding process schemas was not intuitive and would actually require training, even for those roles that are less focused on the technical nature of systems-oriented concepts; A-SAL noted, “it would be nice to have a class where you bring your business partners whether they be business analysts or end users depending on who you’re working with more closely [on a project], but bring them into the class as well so you are getting the same understanding and kind of that high level knowledge of how we are trying to use the data and what kind of requirement information is helpful and those types of things.” This lack of context of framing (e.g., lack of details) also affected the IT implementation personnel who needed to develop a specific solution based on process schemas that were created. At times the IT personnel undertaking


Fig. 2. Use case project A.

implementation could not fully understand the solution designed by the systems analysts; B-QAL commented, “There were several occasions where we had to go back, question the delivery, question the design.” The process schemas did not provide enough details about framing/context to connect the process schemas to the solution designed. In order to address modeling impediments described above, both organizations implemented physical and process customizations, which we describe next.

4.1.2 Physical Customizations [PHYS1–4] One physical customization to simplify models was to first provide a high-level representation (e.g., use case) of the process. Generally, this representation also used fewer constructs than one might expect to see on a complete use case diagram. Insurainc found this idea especially useful when the ensuing documentation was lengthy or complicated. For example, Fig. 2 shows a high-level version of a use case diagram. As AB-P put it, instead of always distributing a detailed process schema to everyone involved in a project, “they are just a diagram [schema] so that pictorially somebody understands the data flow or the flow of information.” Compared with traditional use case diagrams, note that Fig. 2 does not include constructs such as system boundaries, extension, and inclusion. The cylinder symbol that is representing the “I-Sys” system is an Insurainc customization. Generally, that system would be represented with a large rectangle (the system boundary) and include the relevant uses inside that would be performed by the actor. Additionally, the use case that contains the text “UC 1” would normally contain a brief description of the action being undertaken within the system and there would be more than one use case shown. Instead, Insurainc chose to

Fig. 3. Text-based activity diagram.

27

employ this use case to simply demonstrate that there is a specific actor (the underwriter) who performs some kind of action (UC 1) using a system (I-Sys); hence the use case was presented at a high level of abstraction. These customizations turned the use case into an introduction of a sort of documentation to follow with regards to other process schemas. As we will see, the simplicity and customization of this initial Use Case Diagram served to frame the content of additional schemas, and thus, increased the ease of understandability of additional schemas. The customization in Fig. 2 had a cascading effect as Insurainc changed subsequent process schemas to line up with the way the use cases were presented and simplified. The notion of an actor, a system, and a group of activities that constitute UC 1 were continued in subsequent schemas, thus, explicitly making the connections between different documents. To begin expanding on the action, UC 1, Insurainc provided a sequence of steps that two entities undertook, Actor (Underwriter) and System (I-Sys), in a tabular fashion; see Fig. 3. This type of text-based activity diagram is not normally found in UML; while it does imply some process flow, it is heavily text-based and in tabular form. However, this is a transition into and reference for the schema shown in Fig. 4. Fig. 4 depicts a more traditional activity diagram. All of the information found in Fig. 3 is also available in Fig. 4; thus the schemas were presented in both textual and graphical formats. However, Fig. 4 explicates not only the flow of information but also illustrates the associated decisions that occur within the scope of the schema. Unlike a traditional activity diagram, there are no initiation or termination symbols, likely due to the simplicity of the flow and the ability to clearly tell where the process starts and stops. Thus schemas were also simplified by not using all the constructs of the model. Note how each step in the process, including the decision, is numbered to show how it corresponds to the text-based process schema (Fig. 3) which is a decomposition of UC 1 (Fig. 2). CareCorp similarly simplified their process models by eliminating some of the constructs that were traditionally found in use case diagrams. Fig. 5 shows a replication of a use case diagram from one of their system groups that did

28


VOL. 41, NO. 1,

JANUARY 2015

Fig. 4. Activity diagram.

not contain the inheritance construct to make it easier for all roles involved to understand them. C-SA1 reflected on why they decided not to include this construct even though there was opportunity to use them, “Yeah, it did get a little too technical. And people [business roles] were wondering why we needed to do this even though we tried really hard to explain it.” Arguably the lack of inheritance among the actors might have made the use case model easier to understand to group commonality among actors, but CareCorp recognized this and C-SA1 noted, “Even though we don’t do everything 100 percent the way UML says to do it, we have our conventions and people understand them.” In Fig. 5, we also note that this particular system group had responsibility for several systems at CareCorp and chose to implement the notion of system boundaries via color coding6 as expressed by C-SA1, “What we did is they took different specific use cases, we color coded them by 6. In order to make the customization apparent in black and white reproductions, we have shown Fig. 5 with gradients instead of color coding.

system and it was a way for them to look at the interfaces [. . .] to make sure that all the loose ends were tied up.” The color coding allowed them to still show division of systems as well as how systems might interact with each other. For example, notice how the use cases for one particular system were given a specific color. Then that system could also be an actor to another system which was coded with another color. C-SA2 stated, “The key is do the people who are asking for the system to be built or trying to get the problem solved and the people who are building it: do they have a common understanding of what that UML diagram [schema] is helping to describe? Can I color code something? Well sure if that helps with the understanding.” Ultimately the schema was helpful because it helped the team move the project along as C-SA2 summarized, “So in a view you get a picture of where are my integration points so you can go attack those areas.” A further physical change at Insurainc, still aimed at facilitating process schema understandability via how they were presented, continued the thread of removing the ambiguity associated with schemas that relied on


29

Fig. 5. UC diagram from Project C.

symbols and minimal text, an aspect which can affect interpretation of the system’s requirements. Instead of relying only on the symbols specified in the process model, an additional description of the process was included. B-SA1 described how this customization was put in place, “We get two chances. We get the visual representation of the process within our application [system]. . . and then the words behind it to get really into all the details.” BSA1’s explanation and the accompanying Fig. 6 exemplify how the schema is both explained and expanded

Fig. 6. Detailed system flow (web service logic).

upon by additional text description in plain English. Standard process schemas would not include this amount of text, but would likely substitute it for a few summary words. Insurainc eliminated the possibility of misinterpretation that could occur when only a short textual summary is given; Fig. 6 was more specific by employing a large amount of text to accompany the depiction of the process. CareCorp also enhanced the amount of text in their process models with notes as seen in Fig. 5.

30


4.1.3 Process Customizations [PROC1] An important and frequently used process in place at Insurainc to enable understanding of simplified process models was an increased number of reviews of process schemas. After elicitation of the initial requirements from the business, verification of the accuracy of business requirements was conducted. These reviews would occur within functional roles (e.g., with just systems analysts), across functional roles (e.g., systems analyst and business role), and with key personnel of all roles. Insurainc wanted to ensure that all roles involved with verification shared a common understanding of the processes being modeled. A-SA/Designer explained how, “We go back and validate those things [process schemas]. We have our review session, and sometimes those review sessions are combined, and sometimes they were on an individual [role] basis.” An increased number of reviews were important from understanding perspective because they created reassurance among all roles involved that their understanding of the process was accurate. A-BA/SA summarized this point rather succinctly: “If you’re wrong. . . you’re quickly going to be told that, especially during a review.” [PROC2] Furthermore, Insurainc realized the significance of blended team compositions in enabling understanding of the simplified process schemas. A-SAL saw the value in, “bringing in a combination between [individuals] having the [actual] process [knowledge]” yet at the same time, “definitely [having] people who were familiar with the structure [of process models].” From a process perspective, Insurainc realized that no one role necessarily had both types of knowledge. Insurainc also encouraged active collaboration among project team members for creating useful process schemas as BQAL spoke of an instance when, “everybody had everybody else’s cellphone numbers and I think everybody had a couple calls at midnight to each other.” Insurainc thus also realized the high coordination that was involved in process modeling. [PROC3] CareCorp also had process customizations they believed help simplify models. Similar to Insurainc, CareCorp recognized the benefits of having blended team compositions as well, however their blended teams spanned both IT and business roles as C-SA1 commented, “We got in a room [online] with a bunch of business folks, developers, systems analysts, business analysts, people that really knew these systems and said OK let’s talk about what these systems mean and how they work.. . .we were actually creating them [process schemas] as we went and talking through them.” Blended teams at CareCorp helped simplify models for their internal use because it kept the emphasis on the system requirements instead of creating a process schema that complied with all UML conventions as C-SA1 emphasized, “As long as you get a diagram [schema] that tells the story, and that can be used by someone else, then that’s ok.” Keeping the emphasis on system requirements also had the added benefit of fostering further communication among roles as C-SA2 shared, “And that’s what we’re trying to do with the process is break those silos down. We want people talking to each other, not throwing deliverables over the wall.” CareCorp also utilized recorded online meetings to help involve not only a larger number of individuals while creating process schemas but also those

VOL. 41, NO. 1,

JANUARY 2015

individuals that could not be present during the session to create process schemas. As described by C-SA1 while not everyone with input to the project would have been present during the session, “at a minimum the people who have decision making authority should be in agreement and you would want them in the meeting.” Furthermore, if someone was not available during the actual meeting time, they could simply go back and watch the recorded meetings to not only understand what was missed, but they could also have better insight into how the decisions were reached. They could then provide input to help guide the team during their work based on any insights they wanted to contribute that may have differed from the decisions made while they were not present at the meeting.

4.1.4 Summary of Findings As described in the prior sections, the organizations we examined customized their process models in several ways. From the view of physical customizations, they employed diagrams that represented processes at a higher level of abstraction. Additionally, they employed fewer model constructs in creating process schemas while also utilizing alternative representations of constructs. These customizations helped improve understandability associated with the process schemas. From the view of process customization, an increased number of schema reviews, both within-role (e.g., among SAs) and across-roles (e.g., with all stakeholders in a project) further helped enhance understandability of process schemas for both business and IT roles. The use of blended teams, which included personnel with greater systems knowledge alongside those with deeper knowledge of the application, also helped ensure that process schemas were understandable by all roles. Lastly, recorded online meetings helped keep individuals aware of how decisions were reached while process schemas were created. The use of text-heavy versus text-light schemas was partially influenced by different cognitive styles of individuals. While some individuals preferred a pictorial representation with a separate text representation (e.g., Figs. 3 and 4) others favored rich text that accompanied the visual representation in the same representation (e.g., Fig. 6). Presenting different representations (i.e., text and graphical) of a process gave numerous opportunities to different roles to understand the requirements represented in the process schemas. 4.2 Lack of Fit between the Model and the Task at Hand This lack of fit highlights that individuals felt that process models did not fit with the upstream task of requirements elicitation and the downstream task of systems development, thus suggesting that process models were not completely suitable for all tasks associated with systems analysis and design. The specific aspects of this lack of fit addressed attempts to ensure that models connected to the: 1) upstream task of requirements elicitation7; and 2) downstream task of systems development. 7. Roles of a systems project had to certify the completeness and accuracy of the documentation.


31

Fig. 7. Portion of business requirements traceability.

4.2.1 Customization Goals [CG3] Insurainc found that sometimes process schemas did not provide adequate clarity how the elicited business requirements mapped to the schema that was drawn. BA1 felt that using process models did not provide Insurainc one piece of documentation that would have, “all the requirements listed in one place.” This need for clarity was paramount and Insurainc wanted accountability of the information elicited from the initial requests the users provided through writing systems code by the developers. ASA/Designer indicated that systems analysts needed to, “truly understand the ins and outs” and that process schemas did not provide adequate depth to the rationale behind the system designed based on the requirements. CareCorp shared similar sentiments regarding traceability and accountability of the requirements, particularly as they progressed through the lifecycle of development. CSA2 shared that in particular they wanted to at least have their, “requirements trace to testing or design.” In doing so, they could ensure that none of the requirements were being overlooked during work execution. [CG4] Insurainc also thought that process models did not connect well with systems development, in particular with respect to the work of the developers. If enhancements and changes were needed to be made later to an implemented system, the process schema did not adequately map how specific requirements were implemented into the system; A-SA/ Designer noted, “without knowing what screens were impacted by that process, just by knowing the process it really still does not add a whole lot of value if you are trying to make a change to that screen later.” Thus the mapping between process models and technical requirements was not made apparent in process schemas. CareCorp also believed that process models did not always connect well to some of the actual work that their developers were doing. For Project C, the developers needed to make changes to systems to make sure the appropriate data was being transmitted across systems in a format that was compatible with federal standards. While process models (e.g., activity diagrams) do imply flow of information between different system activities, they needed more explicit information for their developers to complete their tasks. 4.2.2 Physical Customizations [PHYS5] To better connect the process models with the upstream task of requirements elicitation, it was important

to Insurainc to have the ability to trace business requirements to their resulting technical requirements (i.e., traceability [82]). Traceability is likely emphasized due to the fact that in a large corporate environment, while a group of people with disparate backgrounds may be working together to build a system, the accuracy and completeness of the requirements still needs to be ensured. Considering that the issue was so important to Insurainc, B-SA1 remarked how they required, “a business requirements traceability document, just kind of like an excel spreadsheet that has all the requirements listed in one place” to accompany their use cases and simplify this task of being able to trace the business requirements to the technical design. Fig. 7 shows a portion of a business requirements traceability document as employed by Insurainc. Each business requirement is listed on the left of each new row and any associated business process or use case diagram is listed on the right. The numbered columns in the middle reflect the specific technical design components that address the business requirements. CareCorp decided that the best way for them to provide traceability and accountability of requirements was via system developed to manage requirements. They ultimately selected a system (hereafter referred to as ProDoc) created by an external company. This did require some overhead as each requirement had to be entered into ProDoc, along with any supporting process schema which was attached to that entry (e.g., Use Case Diagram, Activity Diagram, etc.), by a SA. C-SA1 shared that the benefits of this extra work allowed them to have better traceability because the requirements, “would trace that to the rest of the [development] process, the test cases, and the code at an abstract level.” Thus the other IT roles could simply update their progress in ProDoc as they accomplished work needed. For example a QA role could upload the specific test case as well as evidence of the completed test case. C-SA2 commented that ultimately, “There is good integration between requirements, testing, and work item management.” [PHYS6] To further facilitate connection between process models and the requirements elicited, Insurainc also wanted a logical mechanism for connecting different processes or activities of the entire system. The customization put in place in the original use case diagram (Fig. 2) had implications for the process model that ended up tying everything together. Recall the scope and the way the use case was customized in Fig. 2, thus, precluding the need for a traditional

32


VOL. 41, NO. 1,

JANUARY 2015

Fig. 8. Connection of use cases

use case diagram that captures all use cases of the system. Generally when several detailed use cases are found at a lower level of abstraction, all of the use cases are combined and represented within a single use case containing all the relevant actors and actions with the appropriate systems. However, the way the system was represented in Fig. 2 did not align with the way they are normally represented in a use case. Therefore, Insurainc needed to find a way to show a logical representation of the entire process being modeled. Fig. 8 shows an example of the schema that Insurainc found most useful for connecting the individual use cases that made up the entire process. [PHYS7] To better connect the process schemas to the developed system, Insurainc had their use case diagrams connect to the actual screens of the system that would be implemented. Prior research refers to these types of screens as Display Action Response Models [83] and they are essentially screen shots of the interface that captures how the user would interact with the “instantiated” system. As shown in Fig. 9, this quasi-DARM customization allowed the use case to connect to the actual requirements

Fig. 9. Project display action response model.

(i.e., the processes that would be implemented in the system itself) for a single screen of the system. As AB-P explained, “basically you have a pictorial representation [schema] of how the screen should look, and then there would be additional rules in the page. That’s basically what matters for a developer here. That’s how we code [implement].” Having this concrete representation of the system made the programmer’s job easier because they did not have to spend time conceptualizing how a screen should look. Instead, they can focus on implementing the processes running behind the scenes. [PHYS8] To better connect the actual work that developers had to do for their project, CareCorp enhanced their activity schemas. Fig. 10 shows a replication of how they enhanced their activity diagrams to assist developers in completing their work. Essentially the activity diagram flows were enhanced with the data from the electronic transmission that needed to be passed between the activities. In explaining the figure C-SA1 shared, “What it does show is that you start with a file and here’s sort of the processes you have to go through. Here’s the little notes we were able to make to the developer so they could see all of the transformations that the file had to go through to get out to the back end tier to accept the file and process it for payment.” C-SA1 continued, “The developers and the analysts were able to say ok I see that now. I need to make sure that the report gets here, this file gets there. . . But it really helped folks understand what exactly needed to be done because if you were to look at the big picture, you’d say ‘Oh my gosh! So what all do we need to change for all of our systems?’ It was too overwhelming! But if we had these kind of diagrams [schemas] for each sort of system people seemed to respond well to that.”

4.2.3 Process Customizations [PROC4] The requirements elicited needed to be connected to process schemas that were developed. To ensure this, Insurainc used requirements accountability by all key roles via requirements signoff as a part of process modeling documentation. All the major roles, i.e., underwriting (users),


33

Fig. 10. Activity diagram with specific file feed information.

pricing (users), helpdesk, tech lead, and QA, involved were included in the sign-off document. When a key role member signed-off on the process schemas, they were indicating that they were acknowledging responsibility that all the key requirements were captured in the process schema and that the documented requirements would be included in the system developed. [PROC5] To help connect process models to the developed system, Insurainc employed a quasi-Display Action Response Models (DARM) (Fig. 9). This physical customization using DARM supported a process Insurainc had for getting the actual systems development completed. Insurainc contracted out some parts of implementation and assigned development tasks to programmers one screen at a time; thus DARM also helped in task allocation. By dividing the workload by DARM schemas, programmers could work independently from one another and separation of the work via screens helped develop chunks that were more suitable for an individual programmer. This way, programmers also did not have to spend time learning about the context of the project and could begin their work rather quickly as they had to comprehend the processes one screen at a time.

4.2.4 Summary of Findings The organizations we examined customized their process models to better connect process schemas with the upstream task of requirements elicitation and downstream task of system development. They did this by listing all of the requirements in one single document known as a business requirements traceability document or using requirements management software. They also provided greater visibility of the processes involved in the system with a diagram that connected all of the individual use cases together (see Fig. 8). These two documents provided clarity that all requirements would be addressed in the system and accountability for this was acknowledged via a sign-off process. To provide a stronger connection between how each requirement would be implemented in the developed system, Insurainc customized their process models to depict the business requirements and process detail for each screen of the system. Basing some of the requirements at the screen level using DARM allowed those involved with verification of design the ability to ensure that all the details for a screen were captured and that they could focus their thinking on ensuring the system would be able to automate or complement the part of the process represented on that screen. This customization had an effect on the physical customization as well as the process

used to facilitate process modeling. CareCorp enabled a stronger connection to actual development work by enhancing the activity diagram flows with specific placeholders and fields in electronic data file feeds.

5

DISCUSSION

5.1 Discussion of the Findings In this research, we sought to understand the relationship between perceived impediments to process modeling and customizations of process models. We refined perceived impediments to process modeling identified in prior literature into a lack of fit between: 1) modeling and the role; and 2) modeling and the task. We summarize our findings with respect to these two ‘lack of fit’ categories and our findings from our current research in Table 5. Table 5 shows that a lack of fit between process models and the role it was intended for primarily affected business roles, but also had an impact on IT roles. The process schemas were not understandable by both roles as they: 1) were too systems design focused; 2) were overly detailed; and 3) provided little framing to help users understand the intention of the process modeling documentation. The lack of fit between process models and the task showed that process models did not fit with the upstream task of requirements elicitation and the downstream task of systems development. Specifically process models may not provide the visibility needed for stakeholders to see how the initial planned requirements of the system will be represented in the final system. Also, process models may not provide a good fit into the existing systems development practices within an organization. By providing rich descriptions of some of the process modeling customizations that exist in organizations as well as the rationale for process modeling customizations, this study seeks to understand the link between perceived impediments to process modeling and process modeling customizations. Specifically, we present evidence to show that process modeling customizations are employed in organizations to address perceived process modeling impediments. We described the specific perceived impediments that needed to be addressed and then identified the customization employed. We thus bridged two disparate research streams. In order to address perceived impediments listed in Table 5, we found that projects employed both “physical” changes to process models as well as the employed methodology that supported overcoming the perceived impediments to process modeling. The specific physical

34


VOL. 41, NO. 1,

JANUARY 2015

TABLE 5 Refined Perceived Impediments to Process Modeling Lack of fit

Sub-Category

Lack of fit between model and role it was intended for

The models were too systems design focused (i.e., took on too much of a technical nature) Too much detail provided made it cumbersome to walk through the models. No framing of the purpose or intention of the documentation

Lack of fit between the model and the task at hand

Documentation did not connect specific business requirements with process models Documentation did not connect to the larger system development process

customizations included: 1) schemas at a higher level of abstraction; 2) schemas that employed fewer constructs of a model; 3) alternative representation of constructs; 4) increased use of text with diagrams in schemas; 5) incorporating models for different purposes (e.g., tracing requirements); 6) connecting the individual diagrams that comprised the requirements for a process in one schema; 7) connecting use cases to the screens of the actual system; and 8) listing specific data flows on activity diagrams. The specific process in place to help address the perceived impediments and support the physical customizations included: 1) having multiple reviews at different levels; 2) having individuals with business process knowledge blended on a team with individuals with systems knowledge; 3) recording model creation sessions for reviewing; 4) a formal sign-off process that included various roles; and 5) dividing work by screens instead of functionality. More details about these customizations and the perceived impediments they helped the organizations overcome can be seen in Table 4.

5.2 Limitations Before we discuss implications for research and practice, we acknowledge limitations to this study. We chose to utilize a case study methodology for our current research as we wanted to understand the relationship between process modeling impediments and process modeling customizations that might be employed to help realize the benefits of process models for projects in organizations, an aspect that has not been covered in prior research. By richly describing the phenomenon of perceived modeling impediments and process model customizations, we have achieved our research goal of understanding how process model customizations are a consequence of perceived impediments to process modeling. Our first limitation is that this research employs a case study with two organizations in the health care industry to better understand how perceived modeling impediments link to process modeling customizations. However, we believe prior research has also established a similar precedent by examining a research question via a case study focus on one industry [84], [85]. We believe the sites selected are appropriate for this research because we have selected organizations that are regulation-driven and would thus place an emphasis on documentation; this allowed us to examine the documentation that may have been absent in another organization. Second, neither organization employed CASE tools for process modeling. Prior research suggests that the lack of use of CASE tools may be the norm in practice [86]. However, lack of CASE tool usage

allowed us to examine process modeling as well as the associated schemas in a transparent manner [71]. If a tool had been used, several process modeling practices would have most likely been “hidden” by the tool. Third, the research focuses on the customized process models for systems analysis and design. While there are several uses and forms of process models, prior research indicates that the use of process models for systems analysis is common [12], and that UML is a popular process modeling formalism during systems analysis and design [21], [26], [57], [87], [88]. Fourth, this research employs a case-based methodology and bears the common case-based research risk that the phenomena are not generalizable with statistical, sample-based criterion. For example, we did not contrast the full possible variance (e.g., high versus low) of all factors prior research has suggested, e.g., the organization’s process modeling maturity, process modeler’s expertise, etc., impacts how process modeling occurs within organizations. Instead we generalize from our case based descriptions to theory via propositions for future research [71], [75]. Furthermore, prior research has called for employing more realistic settings to provide a more detailed understanding of the phenomenon of interest such as perceived impediments to process modeling and their subsequent customizations [73], [89]. We next offer implications for both research and practice.

5.3 Implications for Research We use dual-domain problem solving—an extension of the theory of cognitive fit—as a framework to describe specific propositions that examine the dynamics of the problem task and problem representation interaction during the analysis and design of systems observed from our current case study findings. Propositions 1 through 3 address the task of understanding the two types of information required for systems development by both IT and business roles. Proposition 4 discusses increasing systems knowledge and facilitating requirements validation for business roles. Lastly, proposition 5 discusses the connection between actual impediments (i.e., ontological perspective) and perceived impediments (i.e., human cognitive perspective) for both roles. An overview of the propositions can be seen in Table 6. We found that IT and business roles better collaborated on process schemas when the amount of information presented in process schemas was rationalized. Since process models were being used for systems development (e.g., system requirements), both roles were trying to use process models to create a representation that facilitated understanding of the domain (i.e., problem task) and therefore the system. Although process models


35

TABLE 6 Summary of Propositions for Future Research Proposition # 1 2 3.1 3.2 4 5

External Representation Alteration

Task and/or Role

Initial higher level of abstraction Separate text accompanying diagram Blending text into diagrams Blending text into diagrams Increased traceability Limiting actual impediments to reduce perceived impediments

(i.e., problem representation) can contain several constructs and provide precision in the specification of a domain of interest, specifying schemas with excessive details via the use of all constructs and showing all the end-to-end details of a process may not facilitate understanding of the domain. As discovered by our current research, some customizations employed by organizations include process schemas that were presented at a higher level of abstraction. While others have recognized the importance of simplifying process models by the level of detail utilized (see for example [90]) as well as the notion of initial domain understanding early in the system development life cycle versus system specification later in the system development life cycle [60], we encourage future research to explore the effects of abstraction on domain understanding. Based on the findings of this current research and prior research on preventing information overload [91], we believe this simplification of the amount of information presented should lead to better understanding among the different roles using process models during systems analysis and design. Proposition 1: Use of an initial higher level of abstraction will facilitate greater understanding among the roles involved with process modeling. Next, we found that it was easier for business roles to understand process schemas if the process schemas included text-representations that accompanied diagrammatic representations. Prior research [89], [92] supports our findings that a text-representation accompanying a diagrammatic representation does facilitate better understanding of a domain by individuals with both low systems domain knowledge and low application domain knowledge. Similarly, prior research has found that a source of information that is essential for novices to systems concepts may be redundant for experts with more systems specific knowledge [93]. However, from the perspective of IT roles to accomplish their work, they need both knowledge of systems development concepts as well as knowledge of the application domain in which the system will be built to facilitate business needs [52]. Typically IT roles have higher systems domain knowledge and lower application domain knowledge [9]. Thus one need of process models is to facilitate the transfer of application domain knowledge to IT roles so that they can design and build the system. We believe that altering a problem representation to include both text representations to accompany diagrammatic process schemas should be further explored in future research. Specifically does the use of text representations accompanying diagrammatic representations

Both IT and business IT roles Systems knowledge by business role Application domain knowledge by IT role Requirements validation Understanding of process models

help transfer application domain knowledge to IT roles. Consistent with prior research with business roles [89], [92] on text representations accompanying diagram representations, we suspect this combination will also be beneficial for IT roles. Proposition 2: The use of text representations that accompany diagram representations (i.e., two separate problem representations) will facilitate better understanding of the application domain knowledge to IT roles, thus, enabling IT roles with low application domain knowledge to design and build systems more accurately. We also found evidence that it was easier for both business and IT roles to utilize process schemas when more rich text was embedded within diagrams. As stated above, systems development requires both knowledge of systems development concepts as well as knowledge of the application domain in which the system will be built to facilitate business needs [52]. Business roles need systems knowledge to improve their ability to effectively communicate and verify requirements contained in process schemas [94]. Based on the customizations we observed in our current research, process models had to be customized to help business roles understand the specialized systems knowledge conveyed in them. IT roles, as stated above, primarily garner application domain understanding from process schemas. Prior research has suggested that altering a problem representation via combining text into diagrams may be beneficial to understanding them [95]. Thus, in the case of both roles, we believe that customizing process models via the use of a combined text and diagram representation should be explored with its ability to aid their understanding (i.e., the problem task) of information necessary for their role (i.e., business and IT) during systems development. For this proposition, we first provide a more generalized statement and then refine the propositions with respect to a specific role. Proposition 3: The combination of text embedded in diagrams for systems process models will facilitate greater understanding of specialized knowledge among the roles involved with process modeling. Proposition 3.1: The combination of text embedded in diagrams for systems process models will facilitate better understanding of systems knowledge by business roles, thus, enabling them to communicate and verify requirements more effectively. Proposition 3.2: The combination of text embedded in diagrams for systems process models will facilitate better understanding of application domain knowledge to IT roles, thus, enabling them to design and build systems more accurately.

36


In our current research, we found that design rationale was important for systems development from the perspective of requirements traceability. Design rationale is the reason and justification behind an system design decision and it has been recognized as being important for better system design, maintenance, training, and documentation [96]. Traceability is the ability to easily see a link between system requirements, design, implementation and is challenging to accomplish given the increasing complexity of systems [97]. While prior research has suggested that traceability is important for quality assurance and defect management by IT roles, we found that traceability was important for business roles with respect to their acknowledgement that the proposed system design incorporated the elicited requirements. However, a process model may not contain some types of information, making it next to impossible for business roles to glean some types of information from them for a task without an additional representation. We observed customizations for this issue in the creation of specialized requirements traceability documents and third party software tools. We thus suggest that traceability requires business roles (particularly those with a lack of specialized systems knowledge) to have a mapping between process models (i.e., a problem representation) and the systems requirements (i.e., another problem representation) during the task of requirements validation (i.e., the problem task). Proposition 4: Requirements traceability of process models will lead to improved requirements validation by business roles. This current work explored how the perceived impediments of process modeling are connected to process modeling customizations. While we observed the individuals in the organizations we studied were capable of recognizing perceived impediments in using process models, less is known regarding whether individuals can recognize actual impediments of process modeling that exist while they try to use them. Prior research has referred to actual impediments in process modeling representations using an ontological perspective [13]. From an ontological perspective, there are four general types of impediments that can occur with respect to process modeling: construct deficit, construct redundancy, construct overload, and construct excess (see [34] for an explanation). We believe it would be insightful if future research could determine how actual impediments of process modeling (i.e., from an ontological perspective) lead to perceived impediments of process modeling (from a cognitive perspective) that impair understanding of process models. While some prior research does exist with regards to this question for data modeling [13], we believe more work needs to be done from a process modeling perspective. It would also be insightful to examine the degree to which each of the actual impediments (e.g., construct deficit, construct redundancy, etc.) to process modeling leads to perceived impediments of process models for a given role and task. Given the results from the data modeling stream of research, we believe that actual impediments of process models (i.e., problem representation) do in fact lead to perceived impediments that impair understanding (i.e., problem task) of process models.

VOL. 41, NO. 1,

JANUARY 2015

Proposition 5: Actual impediments of process modeling will lead to perceived impediments of process modeling that impair their understanding.

5.4 Implications for Practice This research has several implications for practice. First, this research explicates different types of perceived impediments to process modeling that may already be implicitly occurring in different systems development projects. Thus our research cautions practitioners about potential impediments they may encounter. Second, by formalizing the perceived impediments, practitioners can be made more aware of them and explicitly address them to improve the benefits of process modeling. Customizations to process models are more than just physical customizations; instead the process by which a process model is used can also be customized. Third, this research is useful to practice as it shows the broad variety of customizations available for process models in order to successfully use them for different roles and tasks on a systems development project. Depending on the perceived impediments that might be occurring on a systems project, practitioners can pick and choose different customizations found in this research to address the perceived impediments (see Table 4).

6

CONCLUSION

While process modeling plays a central role in redesigning an organization’s processes, in understanding dependencies within a business process, and in overall analysis and design of systems, there are several perceived impediments to their use. In this work, we focus on understanding: 1) why process modeling customization is undertaken; and 2) how customization helps address perceived impediments in the use of process models. Our findings affirm that process model customizations are a direct consequence of perceived impediments to process modeling. Process modeling impediments are attributed to one of two lack-of-fits: 1) the role the process model is intended for; and 2) the task at hand. Based on three case studies at two organizations, we found that customizations to process models to resolve these perceived impediments took the form of both “physical” and “process” customizations. The physical customizations highlight constructs that were added/removed from existing process models, including new process models that may have been created. The process customizations highlight how the process models were used during systems development. We emphasize that a person’s (i.e., in the context of a role) ability to process information (e.g., for a task) may be impaired due the quality of knowledge structures (i.e., an information representation) employed during information processing. We presented several propositions that examine the interaction between roles, tasks, and representations during systems analysis and design that future research should examine.

ACKNOWLEDGMENTS The authors are grateful to the IEEE Transactions on Software Engineering editorial team for their thorough feedback on earlier versions of this paper; their comments and


suggestions were of great help. In particular, thanks belongs to Editor-in-Chiefs Bashar Nuseibeh and Matthew Dwyer, Associate Editor Robert Deline, three anonymous reviewers, and Lutz Prechelt who also provided feedback as a reviewer under a Creative Commons Attribution license (CC-BY).

REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

[15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]

R. S. Bittler, “Aligning enterprise architecture with the top business priorities of 2009,” Gartner, Inc., Stamford, CT, USA, 2009. M. Kesari, S. Chang, and P. Seddon, “A content-analytic study of the advantages and disadvantages of process modelling,” in Proc. ACIS , 2003, p. 2. B. Curtis, M. Kellner, and J. Over, “Process modeling,” Commun. ACM, vol. 35, pp. 75–90, 1992. R. Bendraou, J. Jezequel, M. P. Gervais, and X. Blanc, “A comparison of six UML-based languages for software process modeling,” IEEE Trans. Softw. Eng., vol. 36, no. 5, pp. 662–675, Sep./Oct. 2010. B. Cushing, Accouting Information Systems. Reading, MA, USA: Addison-Wesley, 1982. T. DeMarco, Structured Analysis and System Specification. Englewood Cliffs, NJ, USA: Prentice-Hall, 1979. D. Pilone and N. Pitman, UML 2.0 in a Nutshell. Sebastopol, CA, USA: O’Reilly Media, Inc., 2005. M. Rosemann, “Using reference models within the enterprise resource planning lifecycle,” Australian Accounting Rev., vol. 10, pp. 19–30, 2000. G. J. Browne and V. Ramesh, “Improving information requirements determination: A cognitive perspective,” Inform. Manage., vol. 39, pp. 625–645, 2002. J. C. Recker, M. Rosemann, M. Indulska, and P. Green, “Business process modeling: A comparative analysis,” J. Assoc. Inform. Syst., vol. 10, pp. 333–363, 2009. J. Recker, “Opportunities and constraints: The current struggle with BPMN,” Bus. Process Manage. J., vol. 16, pp. 181–201, 2010. J. Recker, “Continued use of process modeling grammars: The impact of individual difference factors,” Eur. J. Inform. Syst., vol. 19, pp. 76–92, 2010. J. Recker, M. Indulska, M. Rosemann, and P. Green, “The ontological deficiencies of process modeling in practice,” Eur. J. Inform. Syst., vol. 19, pp. 501–525, Oct. 2010. J. Recker, M. Rosemann, P. Green, and M. Indulska, “Extending the scope of representation theory: A review and a proposed research model,” in Proc. 3rd Biennial ANU Workshop Inform. Syst. Found., 2007, p. 93. J. Recker, M. Rosemann, P. Green, and M. Indulska, “Do ontological deficiencies in modeling grammars matter?” MIS Quart., vol. 35, pp. 1–24, 2011. J. Recker, N. Safrudin, and M. Rosemann, “How novices design business processes,” Inform. Syst., vol. 37, pp. 557–573, 2012. J. Recker and M. Rosemann, “The measurement of perceived ontological deficiencies of conceptual modeling grammars,” Data Knowl. Eng., vol. 69, pp. 516–532, 2010. L. J. Osterweil, “Software processes are software too, revisited: An invited talk on the most influential paper of ICSE 9,” presented at the 19th Int. Conf. Software Eng., Boston, MA, USA, 1997. M. Rosemann, “Potential pitfalls of process modeling: Part A,” Bus. Process Manage. J., vol. 12, pp. 249–254, 2006. M. Rosemann, “Potential pitfalls of process modeling: Part B,” Bus. Process Manage. J., vol. 12, pp. 377–384, 2006. B. Dobing and J. Parsons, “How UML is used,” Commun. ACM, vol. 49, pp. 109–113, May 2006. B. Dobing and J. Parsons, “Dimensions of UML diagram use: A survey of practitioners,” J. Database Manage., vol. 19, pp. 1–18, Jan.–Mar. 2008. P. Jamart and A. Van Lamsweerde, “A reflective approach to process model customization, enactment and evolution,” in Proc. 3rd Int. Conf. Softw. Process., 1994, pp. 21–32. S. de Cesare, C. Patel, N. Iacovelli, A. Merico, and M. Lycett, “Tailoring software development methodologies in practice: A case study,” J. Comput. Inform. Technol., vol. 16, pp. 157–168, 2008. N. P. Napier, L. Mathiassen, and R. D. Johnson, “Combining perceptions and prescriptions in requirements engineering process assessment: An industrial case study,” IEEE Trans. Softw. Eng., vol. 35, no. 5, pp. 593–606, Sep./Oct. 2009.

37

[26] B. Dobing and J. Parsons, “Understanding the role of use cases in UML: A review and research agenda,” J. Database Manage., vol. 11, pp. 28–36, 2000. [27] M. Cibran, V. Mola, C. Pons, and W. Russo, “Building a bridge between the syntax and semantics of UML collaborations,” in Proc. Eur. Conf. Object-Oriented Program. Workshop Defining Precise Semantics UML, 2000. [28] M. Indulska, J. Recker, M. Rosemann, and P. Green, “Business process modeling: Current issues and future challenges,” in Proc. Adv. Inform. Syst. Eng., 2009, pp. 501–514. [29] P. Delfmann, S. Herwig, L. Lis, and A. Stein, “Supporting distributed conceptual modelling through naming conventions—A toolbased linguistic approach,” Enterprise Model. Inform. Syst. Archit., vol. 4, pp. 3–19, 2009. [30] J. Mendling, H. A. Reijers, and J. Recker, “Activity labeling in process modeling: Empirical insights and recommendations,” Inform. Syst., vol. 35, pp. 467–482, 2010. [31] D. L. Dean, J. D. Lee, R. E. Orwig, and D. R. Vogel, “Technological support for group process modeling,” J. Manage. Inform. Syst., vol. 11, pp. 43–63, 1994. [32] D. Dean, R. Orwig, and D. Vogel, “Facilitation methods for collaborative modeling tools,” Group Decision Negotiation, vol. 9, pp. 109–128, 2000. [33] P. Fettke, “How conceptual modeling is used,” Commun. Assoc. Inf. Syst., vol. 25, p. 43, 2009. [34] Y. Wand and R. Weber, “Research commentary: Information systems and conceptual modeling—A research agenda,” Inform. Syst. Res., vol. 13, pp. 363–376, 2002. [35] G. J. Browne and J. Parsons, “More enduring questions in cognitive IS research,” J. Assoc. Inform. Syst., vol. 13, p. 2, 2012. [36] T. Dingsoyr and N. B. Moe, “The impact of employee participation on the use of an electronic process guide: A longitudinal case study,” IEEE Trans. Softw. Eng., vol. 34, no. 2, pp. 212–225, Mar./ Apr. 2008. [37] R. Miles and K. Hamilton, Learning UML 2.0. Sebastopol, CA, USA: O’Reilly Media, Inc., 2006. [38] C. Kobryn, “Will UML 2.0 be agile or awkward?” Commun. ACM, vol. 45, pp. 107–110, 2002. [39] S. Easterbrook, R. Lutz, R. Covington, J. Kelly, Y. Ampo, and D. Hamilton, “Experiences using lightweight formal methods for requirements modeling,” IEEE Trans. Softw. Eng., vol. 24, no. 1, pp. 4–14, Jan. 1998. [40] J. R. Taylor, An Introduction to Error Analysis: The Study of Uncertainties in Physical Measurements. Sausalito, CA, USA: Univ. Sci. Books, 1999. [41] I. Vessey and D. Galletta, “Cognitive fit: An empirical study of information acquisition,” Inform. Syst. Res., vol. 2, pp. 63–84, 1991. [42] I. Vessey and R. Weber, “Structured tools and conditional logic: An empirical investigation,” Commun. ACM, vol. 29, pp. 48–57, 1986. [43] I. Vessey, “The theory of cognitive fit: One aspect of a general theory of problem solving?” in Human-Computer Interaction and Management Information Systems: Foundations, Advances in Management Information Systems Series, P. Zhang and D. Galletta, Eds. Armonk, NY, USA: ME Sharpe, 2006, pp. 141–183. [44] R. Agarwal, P. De, and A. P. Sinha, “Comprehending object and process models: An empirical study,” IEEE Trans. Softw. Eng., vol. 25, no. 4, pp. 541–556, Jul./Aug. 1999. [45] R. Agarwal, A. P. Sinha, and M. Tanniru, “The role of prior experience and task characteristics in object-oriented modeling: An empirical study,” Int. J. Human-Comput. Studies, vol. 45, pp. 639– 667, 1999. [46] P. L. Bowen, R. A. O’Farrell, and F. H. Rohde, “An empirical investigation of end-user query development: The effects of improved model expressiveness versus complexity,” Inform. Syst. Res., vol. 20, pp. 565–584, Dec. 2009. [47] V. Khatri, I. Vessey, S. Ram, and V. Ramesh, “Cognitive fit between conceptual schemas and internal problem representations: The case of geospatio-temporal conceptual schema comprehension,” IEEE Trans. Prof. Commun., vol. 49, no. 2, pp. 109–127, Jun. 2006. [48] V. Khatri, I. Vessey, V. Ramesh, P. Clay, and S.-J. Park, “Understanding conceptual schemas: Exploring the role of application and is domain knowledge,” Inform. Syst. Res., vol. 17, pp. 81–99, 2006. [49] H. J. Nelson, D. J. Armstrong, and K. M. Nelson, “Patterns of transition: The shift from traditional to object-oriented development,” J. Manage. Inf. Syst., vol. 25, pp. 271–297, Sep. 2009.

38


[50] A. P. Sinha and I. Vessey, “Cognitive fit: An empirical study of recursion and iteration,” IEEE Trans. Softw. Eng., vol. 18, no. 5, pp. 368–379, May 1992. [51] P. Xu and B. Ramesh, “Impact of knowledge support on the performance of software process tailoring,” J. Manage. Inform. Syst., vol. 25, pp. 277–314, 2008. [52] M. Davern, T. Shaft, and D. Te’eni, “Cognition matters: Enduring questions in cognitive is research,” J. Assoc. Inform. Syst., vol. 13, pp. 273–314, 2012. [53] J. Zhang and D. A. Norman, “Representations in distributed cognitive tasks,” Cognitive Sci., vol. 18, pp. 87–122, 1994. [54] K. Siau and Y. Tian, “The complexity of unified modeling language: A GOMS analysis,” in Proc. Int. Conf. Inform. Syst., 2001, pp. 443–447. [55] S. Tilley and S. Huang, “A qualitative assessment of the efficacy of UML diagrams as a form of graphical documentation in aiding program understanding,” in Proc. 21st Annu. Int. Conf. Documentation, 2003, pp. 184–191. [56] M. Peleg and D. Dori, “The model multiplicity problem: Experimenting with real-time specification methods,” IEEE Trans. Softw. Eng., vol. 26, no. 8, pp. 742–759, Aug. 2002. [57] C. Kobryn, “Will UML 2.0 be agile or awkward?” Commun. ACM, vol. 45, pp. 107–110, 2002. [58] D. Dori, “Why significant UML change is unlikely,” Commun. ACM, vol. 45, pp. 82–85, 2002. [59] P. Selonen, K. Koskimies, and M. Sakkinen, “Transformations between UML diagrams,” J. Database Manage., vol. 14, pp. 37–55, 2003. [60] J. Castro, M. Kolp, and J. Mylopoulos, “Towards requirementsdriven information systems engineering: The tropos project,” Inform. Syst., vol. 27, pp. 365–389, 2002. [61] J. Pinggera, P. Soffer, D. Fahland, M. Weidlich, S. Zugal, B. Weber, H. A. Reijers, and J. Mendling, “Styles in business process modeling: An exploration and a model,” Softw. Syst. Model., pp. 1–26, 2013. [62] J. Dehnert and W. M. Van Der Aalst, “Bridging the gap between business models and workflow specifications,” Int. J. Cooperative Inform. Syst., vol. 13, pp. 289–332, 2004. [63] J. Erickson, “A decade and more of UML: An overview of UML semantic and structural issues and UML field use,” J. Database Manage., vol. 19, pp. 1–7, Jul.–Sep. 2008. [64] J. Erickson and K. Siau, “Theoretical and practical complexity of modeling methods,” Commun. ACM, vol. 50, pp. 46–51, 2007. [65] B. S. Lerner, S. Christov, A. Wise, and L. J. Osterweil, “Exception handling patterns for processes,” presented at the 4th Int. Workshop Exception Handling, Atlanta, GA, USA, 2008. [66] T. Murata and A. Borgida, “Handling of irregularities in human centered systems: A unified framework for data and processes,” IEEE Trans. Softw. Eng., vol. 26, no. 10, pp. 959–977, Oct. 2000. [67] C. Ouyang, M. Dumas, W. M. P. V. D. Aalst, A. H. M. T. Hofstede, and J. Mendling, “From business process models to processoriented software systems,” ACM Trans. Softw. Eng. Methodol., vol. 19, pp. 1–37, 2009. [68] P. F. Green, M. Rosemann, M. Indulska, and J. C. Recker, “Complementary use of modeling grammars,” Scandinavian J. Inf. Syst., vol. 23, pp. 59–86, 2011. [69] B. Fitzgerald, N. L. Russo, and T. O’Kane, “Software development method tailoring at Motorola,” Commun. ACM, vol. 46, pp. 64–70, 2003. [70] W. Bandara, G. G. Gable, and M. Rosemann, “Factors and measures of business process modelling: Model building through a multiple case study,” Eur. J. Inform. Syst., vol. 14, pp. 347–360, 2005. [71] K. M. Eisenhardt, “Building theories from case study research,” Acad. Manage. Rev., vol. 14, pp. 532–550, 1989. [72] R. K. Yin, Case Study Research: Design and Methods. Beverly Hills, CA, USA: Sage, 1984. [73] I. Benbasat, D. K. Goldstein, and M. Mead, “The case research strategy in studies of information systems,” MIS Quart., vol. 11, pp. 369–386, 1987. [74] S. Sarker and A. S. Lee, “Using a positivist case research methodology to test three competing theories-in-use of business process redesign,” J. Assoc. Inform. Syst., vol. 2, pp. 1–72, 2001. [75] A. S. Lee and R. L. Baskerville, “Generalizing generalizability in information systems research,” Inform. Syst. Res., vol. 14, pp. 221– 243, 2003.

VOL. 41, NO. 1,

JANUARY 2015

[76] U. Schultze and M. Avital, “Designing interviews to generate rich data for information systems research,” Inform. Org., vol. 21, pp. 1–16, 2011. [77] M. D. Myers and M. Newman, “The qualitative interview in IS research: Examining the craft,” Inform. Org., vol. 17, pp. 2–26, 2007. [78] M. Q. Patton, Qualitative Evaluation and Research Methods. Newbury Park, CA, USA: Sage, 1990. [79] P. Shoval and J. Kabeli, “FOOM: Functional- and object-oriented analysis and design of information systems: An integrated methodology,” J. Database Manage., vol. 12, p. 15, 2001. [80] D. Dori, “Object-process methodology applied to modeling credit card transactions,” J. Database Manage., vol. 12, p. 4, 2001. [81] L. V. Manzoni and R. T. Price, “Identifying extensions required by RUP (rational unified process) to comply with CMM (capability maturity model) levels 2 and 3,” IEEE Trans. Softw. Eng., vol. 29, no. 2, pp. 181–192, Feb. 2003. [82] B. Ramesh and M. Jarke, “Toward reference models for requirements traceability,” IEEE Trans. Softw. Eng., vol. 27, no. 1, pp. 58– 93, Jan. 2001. [83] J. Beatty and M. Alexander, “Display-action-response model for user interface requirements: Case study,” in Proc. 2nd Int. Workshop Requirements Eng. Vis., 2007, p. 10. [84] C. V. Brown, “Horizontal mechanisms under differing is organization contexts,” MIS Quart., vol. 23, pp. 421–454, 1999. [85] B. L. Cooper, H. J. Watson, B. H. Wixom, and D. L. Goodhue, “Data warehousing supports corporate strategy at first American corporation,” MIS Quart., vol. 24, pp. 547–567, 2000. [86] J. Iivari, “Why are CASE tools not used?” Commun. ACM, vol. 39, pp. 94–103, 1996. [87] J. A. Cruz-Lemez, M. Genero, S. Morasca, and M. Piattini, “Using practitioners for assessing the understandability of uml statechart diagrams with composite states,” in Proc. ECR Workshops, 2007, pp. 213–222. [88] M. Grossman, J. E. Aronsonb, and R. V. McCarthy, “Does UML make the grade? Insights from the software development community,” Inform. Softw. Technol., vol. 47, pp. 383–397, 2005. [89] A. Burton-Jones and P. Meso, “The effects of decomposition quality and multiple forms of information on novices’ understanding of a domain from a conceptual model,” J. Assoc. Inform. Syst., vol. 9, p. 1, 2008. [90] A. Cockburn, Writing Effective Use Cases. Reading, MA, USA: Addison-Wesley, 2001. [91] B. Hungerford, A. Hevner, and R. Collins, “Reviewing software diagrams: A cognitive study,” IEEE Trans. Softw. Eng., vol. 30, no. 2, pp. 82–96, Feb. 2004. [92] A. Gemino and D. Parker, “Use case diagrams in support of use case modeling: Deriving understanding from the picture,” J. Database Manage., vol. 20, pp. 1–24, 2009. [93] S. Kalyuga, P. Ayres, P. Chandler, and J. Sweller, “The expertise reversal effect,” Educational Psychologist, vol. 38, pp. 23–31, 2003. [94] G. Shanks, E. Tansley, and R. Weber, “Using ontology to validate conceptual models,” Commun. ACM, vol. 46, pp. 85–89, 2003. [95] J. Sweller and P. Chandler, “Why some material is difficult to learn,” Cognition Instruction, vol. 12, pp. 185–233, 1994. [96] J. Lee, “Design rationale systems: Understanding the issues,” IEEE Expert, vol. 12, no. 3, pp. 78–85, May/ Jun. 1997. [97] G. Regan, F. Mc Caffery, K. McDaid, and D. Flood, “The barriers to traceability and their potential solutions: Towards a reference framework,” presented at the 38th Euromicro Conf. Software Eng. Adv. Appl., Cesme, Turkey, 2012. Binny M. Samuel is an Assistant Professor at the Ivey Business School at Western University. He earned his Ph.D. from the Kelley School of Business at Indiana University. He also holds a Bachelor of Science in Business and M.B.A, both with concentrations in Accounting and Information Systems. Prior to his doctoral education, he worked in IT roles at Ford Motor Company and at Indiana University. His current research interests focus on human factor issues to 1) improve the ways in which the information processing needs of an organization are analyzed, designed, and maintained and 2) understand how cognitions and emotions affect an individual’s decision to adopt and ultimately use systems.


Linwood A. Watkins III is a graduate of the Master of Science in Information Systems program at the Kelley School of Business in Bloomington, Indiana. He also received his Bachelor of Science in Business with a concentration in Information Process Management which he pursued due to his love for computers and deep interest in how technology affects business. Linwood was awarded a Cox Research Scholarship during his undergraduate studies and worked under the direction of Vijay Khatri on research and scholarly activities. He is currently an IT Consultant at Hitachi Consulting in Chicago, IL. Andrew Ehle is an IT professional working at a national healthcare payer in the northeast for the last 9 years. Andrew has a BS in Business from the Indiana University Kelley School of Business. Andrew is married and currently resides in South Windsor, CT.

39

Vijay Khatri joined Indiana University in 2002, where he is an associate professor of information systems in the Operations and Decision Technologies department at Kelley School of Business. He holds a B.E. degree (electronics) from Malaviya National Institute of Technology, a management degree from the University of Bombay, and a PhD degree from the University of Arizona. His research centers on issues related to data semantics, semiotics and conceptual database design, temporal databases, and data governance. More specifically, his research involves developing conceptual design techniques for management of data, especially for applications that need to organize data based on time and space. Vijay has published articles in journals such as IEEE Transactions on Knowledge and Data Engineering, Information Systems, Annals of Mathematics and Artificial Intelligence, Information Systems Research, Journal of Management Information Systems, Decision Sciences Journal, and Communications of the ACM. He serves on the editorial review board of the Journal of Association of Information Systems, and is an associate editor at Information Systems Research and MIS Quarterly. He is a member of ACM and a senior member of IEEE. " For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.

Customizing the Representation Capabilities of Process Models ...

Customizing the Representation Capabilities of Process Models ...

Suggest Documents

Representation Primitives, Process Models and Patient ... - CiteSeerX

Customizing Traceability Links for the Unified Process

Customizing Transaction Models and Mechanisms

Customizing Traceability Links for the Unified Process

The Process of Creating Dynamic Capabilities - CiteSeerX

Event Structures as a Unified Representation of Process Models and ...

On the computational capabilities of several models

On the computational capabilities of several models

Ontology-based Representation and Reasoning on Process Models: A ...

Virtual Machining: Capabilities and Challenges of Process

Prediction Capabilities of Vulnerability Discovery Models

6A5 Prediction Capabilities of Vulnerability Discovery Models

Process Models

the impact of relational capabilities on the internationalization process ...

CUSTOMIZING THE BEHAVIOR OF INTERACTING

Process Models

Customizing the Body

Capabilities and Radical Changes of the Business Models of New ...

A review of representation models of tolerance

The process of developing innovative capabilities in ...

How Can a Structured Representation of Capabilities Help in Planning?

How Can a Structured Representation of Capabilities Help in Planning?

Customizing FrameMaker

Capabilities, Agile, and âProcess Blindnessâ - BPTrends

Customizing the Representation Capabilities of Process Models ...