Samalikova et al. have provided a model that software development teams and organizations can use to extract actual processes; compare them to official, documented processes; and identify gaps that they can then feed back into the system to make the necessary process improvements.
The authors used the control flow of a change control board (CCB) process to demonstrate the inner workings of their process mining technique. Using the process mining (ProM) framework, a heuristic mining tool that provides various process mining algorithms to uncover “the underlying processes of the available data and construct automatically explicit process models,” the authors used the event log of a software change management (SCM) process “to discover the [actual] process model that reflects the order in which the activities are executed.” After uncovering the actual process and comparing it with the documented process, they hold a discussion with the development team about the differences in the findings to ascertain what to conclude from the findings.
Though the process mining technique that the authors propose is doable, the practicality may be limited, since the authors note that “in many real-life development situations, event logs with process information” are often not directly available. They did point out, however, that it “is possible to combine information from different sources to construct useful event logs,” especially in organizations that have attained at least Capability Maturity Model Integration (CMMI) Level 3. The problem is in the amount of time it takes to prepare the data necessary to conduct the process mining. The authors acknowledged that in order to construct useful event logs, the transformation and cleaning process involved to achieve quality data can take up to 60 to 80 percent of the total mining process time spent.
In embarking on this project to investigate process mining, the authors encountered what some other researchers have found in the past: if software developers perceive software process improvement to be useful, and the same software developers perceive an ease of use of the software best practices (processes), they are more likely to use those best practices. If they perceive the processes to be burdensome, however, even though they know that software process improvement is useful, they will tend not to use the processes. Rather, they will find other ways to circumvent the documented official process. That is exactly what the development teams in the organization in the case study were doing (skipping certain tasks of the official process).
What we don’t know is why the development teams were skipping those tasks. Was it because they perceived the tasks to be burdensome, or was it just a natural evolution based on their actual experiences? The authors did not address these questions, because they were probably outside the scope of the research.
There is no question that the presented process mining technique can be an effective method for software development practitioners to use to implement real software process improvements based on actual practice. The technique could be time consuming if used for every project; therefore, software process improvement teams in every software development organization should use it at least once or twice per year to make improvements in their development processes.
