Mining Project-Oriented Business Processes

ePubWU Institutional Repository Saimir Bala and Cristina Cabanillas Macias and Andreas Solti and Jan Mendling and Axel Polleres Mining ProjectOriented Business Processes Book Section (Draft) (Refereed) Original Citation: Bala, Saimir and Cabanillas Macias, Cristina and Solti, Andreas and Mendling, Jan and Polleres, Axel ORCID: https://orcid.org/0000-0001-5670-1146 (2015) Mining ProjectOriented Business Processes. In: Business Process Management. BPM 2016. Lecture Notes in Computer Science, vol 9253. Springer, Cham. pp. 425-440. ISBN 1611-3349 This version is available at: https://epub.wu.ac.at/7203/ Available in ePubWU: October 2019 ePubWU, the institutional repository of the WU Vienna University of Economics and Business, is provided by the University Library and the IT-Services. The aim is to enable open access to the scholarly output of the WU. This document is an early version circulated as work in progress. There are minor differences between this and the publisher version which could however affect a citation. http://epub.wu.ac.at/ Mining Project-Oriented Business Processes? Saimir Bala, Cristina Cabanillas, Jan Mendling, Andreas Rogge-Solti, and Axel Polleres Vienna University of Economics and Business, Austria {firstname.lastname}@wu.ac.at Abstract. Large engineering processes need to be monitored in detail regarding when what was done in order to prove compliance with rules and regulations. A typical problem of these processes is the lack of control that a central process engine provides, such that it is difficult to track the actual course of work even if data is stored in version control systems (VCS). In this paper, we address this problem by defining a mining technique that helps to generate models that visualize the work history as GANTT charts. To this end, we formally define the notion of a project-oriented business process and a corresponding mining algorithm. Our evaluation based on a prototypical implementation demonstrates the benefits in comparison to existing process mining approaches for this specific class of processes. Keywords: process mining, projects, project mining, version control systems 1 Introduction Business process management plays an important role for improving the performance and compliance of various types of processes. In practice, many processes are executed with clear guidelines and regulatory rules, but without an explicit centralized control imposed by a process engine. In particular, it is often important to exactly know when which work was done. This is, for instance, the case for complex engineering processes in which different parties are involved. We refer to this class of processes as project-oriented business processes. Such project-oriented business processes are difficult to control due to the lack of a centralized process engine. However, there are various unstructured pieces of information available to analyze and monitor their progress. One type of data that are often available these processes is event data from version control systems (VCS). While process mining techniques provide a useful perspective on how such event data can be analyzed, they do not produce output that is readily organized according to the project orientation of these processes. ?This work has been funded by the Austrian Research Promotion Agency (FFG) under grant 845638 (SHAPE) and the European Union’s Seventh Framework Programme under grant 612052 (SERAMIS). 2 S. Bala et al. In this paper, we define formal concepts for capturing project-oriented processes. These concepts provide the foundation for us to develop an automatic discovery technique which we refer to as project mining. The output of our project mining algorithm is organized according to the specific structure typically encountered in project-oriented business processes. With this work, we extend the field of process mining towards the coverage of this specific type of business process. The paper is structured as follows. Section 2 describes the research problem and summarizes insights from prior research upon which our project mining approach is built. Section 3 defines the preliminaries of our work and presents an algorithm to mine project-oriented business processes. Section 4 describes the implementation of this algorithm and discusses the results from its application to VCS logs from a real-world engineering project. Section 5 highlights the implications of this work before Section 6 concludes. 2 Background Here, we describe the addressed problem and related work. 2.1 Problem Description The class of processes that we discuss in this paper are long-term engineering projects. These processes have specific requirements for monitoring. First, they are executed only once according to the specific needs of a particular project, and only partially according to recurring process descriptions. Second, they involve various actors that typically document their work in a semi-structured way using text and tables. Third, work in the project is usually subject to constraints regarding the start and end and the temporal order. Fourth, there is typically no process engine controlling the execution. Fifth, even though these limitations in terms of traceability exist, there are usually strong requirements in terms of tracking when which work was conducted. In line with these observations, a project-oriented business process can be defined as an ad-hoc plan that specifies the tasks to be performed within a limited period of time and with a limited set of resources for achieving a specific goal. Unlike repetitive business processes for which notations such as BPMN [12] or EPC [1] are commonly used, project-oriented business processes may be properly represented with PERT or GANTT models. The concept is illustrated in Fig. 1. Documentation is required not only explicitly as part of some activities but also to comply with norms and regulations that may require some evidence of the actions being performed in the organization. Documents are usually free of format or contain tables, at best. The unstructuredness of data makes it difficult to monitor processes and check rules on them. A starting point for analysis of project-oriented processes can be data logs that are stored in Software Configuration Management (SCM) systems that help tracking the evolution of data and restore information if needed [19]. However, hundreds of versions of Mining Project-Oriented Business Processes 3 P1 RESOURCES P1P2 P2 t1t2 DATA PROJECT ACTIVITY 1 ACTIVITY 2 t {P1,P2} {P2} ... tn ... ACTIVITY n {Pn} PROJECT MINING Fig. 1. Problem illustration thousands of files are common in a single project [20], which makes it impractical to browse this data manually. Let us see an example inspired by a real scenario of a process to write a project proposal that uses a Version Control System (VCS) to store the data. The project history, and hence, the data produced, starts when people begin to work on the proposal, which involves a description of the project goals and milestones, a division of tasks into work packages, an estimation of cost and resources required, etcetera. This information is spread in the repository over several folders containing different documents, which are later merged into a single file. If the proposal is accepted, the first step is to organize a kickoff meeting and assign specific resources to the work packages. A hierarchical set of folders is then created in the repository in order to store the information generated for each work package. As the project evolves over time, resources contribute by adding, removing or modifying information to the VCS repository. Project evolution is guided by specific norms that impose the execution of predefined steps. For instance, the European norm EN5016 requires a preliminary Reliability, Availability and Maintainability (RAM) analysis to support targets. Table 1 depicts an excerpt of the log data generated, where the first column (on the left hand side) indicates the commit identifier, the second column indicates the person who committed changes, the third column indicates the commit date, and the fourth column indicates the files affected and the type of action performed among added (A), modified (M) and deleted (D). For the sake of simplicity, the table shows the log data of a specific time period and the actions related to a specific task, namely, Define example. That task was assigned to resource X and was supervised by resource Y and, later on, also by resource Z. Existing frameworks, such as Subversion or Git, allow to access their logs in different ways. However, the covered information is limited to (roughly) that 4 S. Bala et al. Table 1. Excerpt from VCS log data for the referenced time period CID Resource Date List of changes 1 Y 2014-11-12 11:57:46 A /example A /example/SHAPE/ToyStationExample.docx . . . . . . . . . . . . 3 X 2014-11-14 16:34:07 M /example/ToyStation.bpmn M /example/ToyStation.png 4 W 2014-12-15 13:49:11 D /example/Download 5 W 2015-01-08 16:06:41 A /example/Download2 6 X 2015-01-13 11:47:09 M /example/ToyStation 0Loop.bpmn M /example/ToyStation nLoop.bpmn 7 Z 2015-01-16 16:50:29 A /example/ToyStation 0Loop.pdf A /example/ToyStation-feedbackZ.pdf depicted in Table 1. Especially for big projects that are frequently updated over a large period of time, these logs are complex to analyze. Therefore, the problem to address is how to analyze and visualize the information produced in project-oriented business processes such that it can be represented in an understandable and manageable way by project experts and enable, a.o., the automation of mechanisms for compliance checking. The following properties of project-oriented process logs must be taken into account to achieve this goal: (i) VCS repositories consist of a hierarchy of folders and files which are logically organized such that work is grouped in a specific way; (ii) process activities are not registered in VCS log entries. Therefore, such information must be inferred by reasoning on the repository structure and/or the content of the log entries; (iii) the granularity of the events is unknown a priori and it needs to be defined before analyzing the data. 2.2 Related Work The problem described has been addressed in the literature from different perspectives. The first category of related work tackles the problem by transforming it into a process mining problem. Consequently, approaches have been developed to preprocess VCS data such that process mining techniques can be applied, and hence, a business process can be derived from the log data. In this group, Kindler et al. [9,10] developed an algorithm for extracting software processes that are mapped to Petri Nets. Activities, which are not explicit in the logs, are discovered from their input and output artifacts. However, strong assumptions are made on the filenames as well as on the software process lifecycle. Rubin et al. in [15] addressed the problem of engineering processes that are not well documented and are usually unstructured. They provided a bridge from Kindler et al.’s approach to ProM [5] in order to mine different process perspectives, such as performance social network analyses. Rubin et al. [16] applied process mining to the touristic Mining Project-Oriented Business Processes 5 industry and obtained user processes from web client logs pursuing the goal of improving the software system by analyzing the underlying process. Poncin et al. [14] developed the FRASR framework for preprocessing software repositories to transform the VCS data to logs that conform to the process mining event log meta model [4] as utilized in ProM [5]. However, these approaches disregard the single-instance nature of project-oriented business processes and treat them as procedures that can be repeated over time. The second category of related work focuses on the visualization of VCS data for different purposes. Several approaches study the interaction among developers over time from a visualization point of view. For instance, Ogawa and Ma [11] drew storyline pathways to show the story of each developer’s contribution. Other approaches analyze and visualize VCS data at file level in order to discover file version evolution. Voinea and Telea [20] introduced an interactive navigation method to surf file version evolution as well as two methods to cluster versions of the same file in an abstraction layer. Wu et al. [22] also visualized the evolutions of entire projects at file level, emphasizing the evolution moments. Finally, several approaches study change prediction with the aim of discovering prediction patterns that can help in the process of software development [24,23]. The approaches mentioned in this category as well as others that apply similar techniques [6,8,3] focus on studying software evolution from different standpoints. However, the goal pursued differs in all cases from our goal in that they are not interested in discovering projects tasks out of the log data, and hence, they lack an explicit notion of work structure that we need to consider for our purpose. Our approach combines ideas from both areas, as we aim at identifying tasks like in the approaches that rely on process mining, but we must cluster the data in an appropriate way, for which techniques developed in the approaches that pursue visualization may be adapted or extended. 3 Mining VCS Event Data Here, we first formalize the notions encountered in the project mining setting. Then we develop an approach to acquire a hierarchical overview on the project from a repository perspective. 3.1 Preliminaries Version control systems (VCSs) are used in projects to ensure reliable collaboration. We build our approach on VCS. Typically, the workflow in VCS is that people work on files (e.g., text, source code, spread sheets) and commit them to the central repository. Project participants comment on their commits so that other participants can better understand the nature of the changes to the files. Let Fbe the universe of files. Files are organized in a file tree. Therefore, each file f∈Fhas one parent file. The only file without a parent file is the root file. We capture this information in the parent relation Parent :F×F. For example, let fp∈Fbe the parent of file fc∈F, then (fp, fc)∈Parent. The 6 S. Bala et al. transitive closure on the parent files is given by the function ancestor :F→2F that returns the set of files along the path to the root. When project members did a certain amount of work and want to save their current progress, they commit the changes to the VCS. We define changes on files as the events of interest on the lowest granularity. Definition 1 (Event). Let E be the set of events. An event e ∈E is a fourtuple (f, o, ts,k), where –f∈Fis the affected file of the event. –o∈O={added, modified, deleted}is the change operation on the file with obvious meaning. –ts ∈TS =N0represents a unix time stamp marking the time of the event occurrence. –k∈Σ∗is a comment in natural language text. For events e= (f, o, ts,k) we overload f, o, ts, and kto be used as accessor functions. For example, fis the function f:E→Fmapping an event to its affected file. Project participants can commit a number of changes to different files at one step. Therefore, we define the notion of commits as follows. Definition 2 (Commit). A commit Cis a set of events sharing the same time stamp and comment, i.e., ∀e,e0∈ C :ts(e) = ts(e0)∧k(e) = k(e0). Additionally, each event in a commit affects different files, i.e., ∀e,e0∈ C :e6=e0→f(e)6= f(e0). Usually, it is in the hands of project participants, when they decide to commit changes to the VCS. In the extreme case, there could be only a single commit made in a project that adds all files to the repository. Note that this extreme practice would render the use of a VCS obsolete. On the contrary, it is common practice to regularly perform commits in order to securely store work progress and to reduce the chance of conflicts [13,7]. Conflicts occur, when another participant committed changes to a file that is being committed and can cause extra work. Based on these insights, we make the assumption that commits are regularly made during work. Projects are decomposed into work packages. We assume a hierarchical work package structure of a project, such that a work package can have sub work packages. Further, the amount of work in a single work package need not be done in one single time span, but it can be split into several activities. Activities have a start and end time, and subsequent activities can have idle periods in between. Thus, we define projects as follows. Definition 3 (Project). A project Pis a tuple (W, S, A, α, ω, β), where –Wis the set of work packages in the project. –S⊆W×Wis the relation that hierarchically decomposes work packages into a tree structure. –A is the set of activities that are conducted in the work packages. Mining Project-Oriented Business Processes 7 –α:A→TS is the function that assigns a start time to activities. Activities are ordered by their start times. –ω:A→TS is the function that assigns an end time to activities. –β:A→Wis the mapping function that maps activities to their corresponding work packages. Note that this definition reflects an activity centric view on projects. The definition deliberately omits further dimensions, e.g., costs, resources, risks. The idea is not to capture projects in every detail, but to focus on the work packages of a project to obtain an overview of the work that is being done. We are interested in when work has been started in a work package, and when work packages have been done. This information can be derived from the activities associated to the workpackages. An obvious assumption is that the work package starts with its first activity, and ends when its last activity is completed. Based on these notions, we can define the task of project discovery as reconstructing the project Pfrom a set of low level event data E. In the following, we present an approach to this problem. 3.2 Project Discovery Technique For project discovery from the VCS commit history, we need to identify activities that are performed, associate the activities to work packages and recreate the work package structure of the project. Our aim is to create a hierarchical model that provides an overview of the project work. Therefore, we have to identify the start and end times of activities and of work packages before we can visualize the project work. The input to the technique is the log that is stored in the VCS. The challenge is that the raw log only records commits on the file system level and information on activity level is missing. However, we can deduce activity information from events based on the following assumptions. A1: Meaningful file tree structure. The file tree structure in a project represents its work package structure. That is, the knowledge workers organize their work in a file hierarchy that reflects the project structure. A2: Local changes. Activities in a work package affect only files of the work package folder, or in the corresponding sub-tree in the file tree structure. A3: Frequent commits. Commits to the VCS are regularly performed, when conducting work in an activity. discovery started Preprocess log into a set of events VCS log events E Aggregate events to activities activities A Identify work packages for activities work packages W Aggregate work packages work package structure S Compute work package characteristics project P Fig. 2. Project discovery technique overview as BPMN process model. 8 S. Bala et al. Note that assumption A1 can be seen as a strong assumption on the file tree structure. Nevertheless, we argue that even if A1 is not entirely met, the aggregation of work information on the file tree hierarchy provides a valuable view on the project. Figure 2 shows the different steps of the technique. We describe each of them in detail. Step 1: Preprocessing. The first step is to transform raw logs of version control systems (which might be grouped by commits) into a list of events as specified in Definition 1. This step is easily done by replicating the information on commit level to be contained in the events. The output is a set of events E. Step 2: Aggregating events to activities. Given the set of events Ethat we gathered from a version control system, the next step is to identify the activities to which the events belong. Note that we do not know the activities of the project in advance, but need to infer them based on the events. Each event affects a single file in the file hierarchy. time c1c2c4 tc2 tc3 ? a3 observed active time a3' adjusted active time c3 tc4 tc tc1 Fig. 3. Adjustment of activity start time α. Based on assumption A2, we are interested in activities conducted in a work package, that is, we filter for the events that are contained in the given file or its children. For every file fof interest, we select the set of events affecting the file or its children as Ef={e∈E|f=f(e)∨f∈ancestor(f(e))}. The task is then to find the activities which emitted the set of events Ef. We rely on assumption A3, which states that during an activity, we expect multiple commits. Assumption A3 allows us to conclude that if we do not observe commits for a longer period of time, there is no activity being performed in the work package. To this end, we adopt the abstraction technique by Baier et al. [2] and allow the domain expert to formulate rules for aggregating events to activities based on boundary conditions. Assuming that people frequently commit their progress (A3), we can specify a boundary condition based on the temporal distance to previous events. For example, we can specify that a time period of seven days without a commit is a boundary condition. As the result, we obtain the mapping from events to these activities, which we call γf:Ef→Afin the remainder of the paper. The set of discovered activities identified for the work package based on given boundary conditions is then Af={a|e∈Ef, γf(e) = a}. We also Mining Project-Oriented Business Processes 15 Fig. 6. Dotted chart from ProM Fig. 7. Chart from Disco plotting the events over time. 6 Conclusion In this paper we addressed the problem of mining and visualizing projectoriented business processes in a way that is informative to managers. We define an approach that takes VCS logs as input to generate Gantt charts. Our algorithm works under the assumptions that repositories reflect the hierarchical structure of the project, each work package is contained in a corresponding directory and project members commit their work regularly during active working times. The approach was implemented as a prototype and evaluated based on real-world data from open source projects. In future work, we aim to extract further details of the VCS logs in order to calculate metrics that approximate the work effort. We plan to investigate on how the project mining approach is affected by project characteristics. Furthermore, we want to utilize statistical methods to better estimate the boundaries of the activities and work packages. Finally, we have already incorporated feedback from managers and plan to extend these to full user studies. References 1. van der Aalst, W.: Formalization and verification of event-driven process chains. Information and Software Technology 41(10), 639–650 (1999) 2. Baier, T., Mendling, J., Weske, M.: Bridging abstraction layers in process mining. Information Systems 46, 123–139 (2014) 16 S. Bala et al. 3. D’Ambros, M., Lanza, M.: A Flexible Framework to Support Collaborative Software Evolution Analysis. In: Software Maintenance and Reengineering. pp. 3–12 (2008) 4. van Dongen, B.F., Van der Aalst, W.M.: A Meta Model for Process Mining Data. EMOI-INTEROP 160, 30 (2005) 5. van Dongen, B.F., de Medeiros, A.K.A., Verbeek, H., Weijters, A., Van Der Aalst, W.M.: The ProM framework: A new era in process mining tool support. In: Applications and Theory of Petri Nets 2005, pp. 444–454. Springer (2005) 6. Feldt, R., Staron, M., Hult, E., Liljegren, T.: Supporting software decision meetings: Heatmaps for visualising test and code measurements. In: 39th Conf. on Software Engineering and Advanced Applications, pp. 62–69. IEEE (2013) 7. Hou, Q., Ma, Y., Chen, J., Xu, Y.: An Empirical Study on Inter-Commit Times in SVN. In: Int. Conf. on Software Eng. and Knowledge Eng., pp. 132–137. (2014) 8. Kagdi, H., Yusuf, S., Maletic, J.I.: Mining Sequences of Changed-files from Version Histories. In: Workshop on Mining Software Repositories. pp. 47–53. ACM (2006) 9. Kindler, E., Rubin, V., Sch¨afer, W.: Activity Mining for Discovering Software Process Models. Software Engineering 79, 175–180 (2006) 10. Kindler, E., Rubin, V., Sch¨afer, W.: Incremental Workflow Mining Based on Document Versioning Information. In: Li, M., Boehm, B., Osterweil, L. (eds.) Unifying the Software Process Spectrum, LNCS 3840, pp. 287–301. Springer (2006) 11. Ogawa, M., Ma, K.L.: Software evolution storylines. In: Proceedings of the 5th international symposium on Software visualization. pp. 35–42. ACM (2010) 12. OMG: BPMN 2.0. Recommendation, OMG (2011) 13. Pilato, C.M., Collins-Sussman, B., Fitzpatrick, B.W.: Version control with subversion. O’Reilly Media, Inc. (2008) 14. Poncin, W., Serebrenik, A., van den Brand, M.: Process mining software repositories. In: Software Maintenance and Reengineering (CSMR), 2011 15th European Conference on. pp. 5–14. IEEE (2011) 15. Rubin, V., G¨unther, C.W., Van Der Aalst, W.M., Kindler, E., Van Dongen, B.F., Sch¨afer, W.: Process mining framework for software processes. In: Software Process Dynamics and Agility, pp. 169–181. Springer (2007) 16. Rubin, V., Lomazova, I., van der Aalst, W.M.: Agile development with software process mining. In: Int. Conf. on Softw. and System Process. pp. 70–74. (2014) 17. Torvalds, L., Hamano, J.: Git: Fast version control system. http://git-scm.com (2010) 18. Verbeek, H., Buijs, J.C., Van Dongen, B.F., Van Der Aalst, W.M.: Xes, xesame, and prom 6. In: Information Systems Evolution, pp. 60–75. Springer (2011) 19. Voinea, L., Telea, A.: An Open Framework for CVS Repository Querying, Analysis and Visualization. In: International Workshop on Mining Software Repositories (MSR ’06). pp. 33–39. ACM (2006) 20. Voinea, L., Telea, A.: Multiscale and Multivariate Visualizations of Software Evolution. In: Symposium on Software Visualization. pp. 115–124. ACM (2006) 21. Wilson, J.M.: Gantt charts: A centenary appreciation. European Journal of Operational Research 149(2), 430–437 (2003) 22. Wu, J., Spitzer, C., Hassan, A., Holt, R.: Evolution Spectrographs: visualizing punctuated change in software evolution. In: Workshop on Principles of Software Evolution. pp. 57–66 (Sept 2004) 23. Ying, A., Murphy, G., Ng, R., Chu-Carroll, M.: Predicting Source Code Changes by Mining Change History. IEEE Trans. Softw. Eng. 30(9), 574–586 (2004) 24. Zimmermann, T., Weisgerber, P., Diehl, S., Zeller, A.: Mining Version Histories to Guide Software Changes. In: Int. Conf. Software Engineering. pp. 563–572. (2004)