Software process validation

Abstract

To a great extent, the usefulness of a formal model of a software process lies in its ability to accurately predict the behavior of the executing process. Similarly, the usefulness of an executing process lies largely in its ability to fulfill the requirements embodied in a formal model of the process. When process models and process executions diverge, something significant is happening.We have developed techniques for uncovering and measuring the discrepancies between models and executions, which we call process validation. Process validation takes a process execution and a process model, and measures the level of correspondence between the two. Our metrics are tailorable and give process engineers control over determining the severity of different types of discrepancies. The techniques provide detailed information once a high-level measurement indicates the presence of a problem. We have applied our process validation methods in an industrial case study, of which a portion is described in this paper. Report Documentation PageForm Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

Conformance checking based on multi-perspective declarative process models

“…3 In particular, the plug-in receives as input an event log and a model and evaluates the conformance of the log with respect to the model. It is interesting to note that, in the current implementation, the processing of each trace is independent from all the others.…”

“…Early works in conformance checking (e.g., [3,4,5]) mainly focused on the control-flow perspective in the context of imperative models, i.e., on the functional dependencies among performed activities/tasks in the process, while abstracting from time constraints, data dependencies, and resource assignments. These works were mainly based on replaying the log on the model to compute, according to the proposed approach, the fraction of events or traces in the log that can be replayed by the model.…”

Measuring precision of modeled behavior

“…Many existing precision metrics (e.g., [25,30,34]) do not explicitly take into account possible deviations between the behavior observed in the event log with the behavior modeled in the models, while many case studies show that such deviations often occur in practice (e.g., [11,16,19,20,23,31,35,36]). Thus, these metrics might be biased due to unfitting logs and models.…”

Process Cubes: Slicing, Dicing, Rolling Up and Drilling Down Event Data for Process Mining

“…Definition 6 provides the interface to existing process discovery [1,11,12,16,30,18,24,25,28,31,41,54,60,61] and conformance checking [6,13,14,15,22,29,31,42,43,51,59] techniques. M EB,PCV defines how to compute an event log (called sublog) per cell.…”