=Paper=
{{Paper
|id=Vol-1294/paper12
|storemode=property
|title=Dealing with Deviations on Software Process Enactment: Comparison Framework
|pdfUrl=https://ceur-ws.org/Vol-1294/paper12.pdf
|volume=Vol-1294
|dblpUrl=https://dblp.org/rec/conf/icaase/SmattiN14
}}
==Dealing with Deviations on Software Process Enactment: Comparison Framework==
https://ceur-ws.org/Vol-1294/paper12.pdf
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Dealing with Deviations on Software Process
Enactment : Comparison Framework
Manel Smatti Mohamed Ahmed Nacer
LSI-USTHB LSI-USTHB
Algiers, Algeria Algiers, Algeria
msmatti@usthb.dz anacer@mail.cerist.dz
Abstract – Software development is a collective and complex task carried out through the cooperation of
human agents and automated tools, this interaction defines the software process. PSEE (Process-centered
Software Engineering Environment) are environments designed to support the creation and exploitation of
software process models that define the expected behaviors of process agents. However, human agents may
deviate from the process model; therefore, the PSEE should be flexible enough to cope with these
unexpected actions. This paper deals with the problem of deviation during software process enactment; it
gives an overview of significant research works that have been proposed to support deviations in the
context of software process execution.
Keywords – Software Process (SP), Software Process Enactment, Process-centered Software Engineering
Environments (PSEE), Deviation
centered on a PML interpreter that includes
1. INTRODUCTION mechanisms to enact the process model.
Software development is defined as a collection Despite their great support for software
of procedures accomplished through the development, PSEEs have not acquired an
cooperation and interaction of human agents and industrial success. This is mainly due to their
automated tools. Therefore, the quality of the rigidity and their lack of agility that is known to
final product depends always on the quality of be inescapable in every software product.
the software process used to deliver it. However,
the complexity of software products and the Moreover, software products have become
involvement of human in these processes made increasingly complex; their development
them more complex and difficult to manage.
Furthermore, software development is a processes are extending over several months or
recurrent process; thus, pursuing a defined even several years, which lead them to deviate
model in such case has become more than from their initial model. Deviations are known to
crucial. A software process model is an abstract be actions performed by process agents and
representation of the software process; it is a which are not described or allowed in the
description of the process expressed in a process model. As a result of these actions, the
suitable Process Modeling Language (PML) [15] quality of software products, delivery time and
whose main objective is to provide required
costs are affected. Finding solutions to cope with
means to enact the process.
such problem has become more than important
Process-Centered Software Engineering in order to guide software development.
Environments (PSEEs) [11] are meant to
support the creation and the exploitation of Several research works have attempted to
software processes; they are based on the address this issue by classifying these
explicit representation of the process and are deviations, proposing mechanisms to detect
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 108
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
them and finding out solutions to cope with this
problem. In this context, we will give in this
paper an insight about the relevant approaches
that have been proposed in this field.
The paper is organized as follows. Section 2
gives an overview of software process
enactment domain, dedicated environments,
and some related problems. Section 3 deals with
the deviation problem during software process
enactment by introducing the deviation concept
and giving an illustrative example. Section 4
highlights some relevant works proposed to
support deviations during software process
execution, these approaches are discussed with
respect to some criteria we have defined. The
paper is concluded in section 5.
Figure 1: Consistency relationship in Software
Process [12]
2. SOFTWARE PROCESS ENACTMENT
Despite the large number of prototypes that
Software Engineering Environments (SEEs) are have been proposed in order to provide an
meant to support software development. Most of environment that could be adopted by the
them are based on a predefined software business community, these attempts are
process model [11]. Process-centered Software remained and operated in the field of
Engineering Environments (PSEEs) give up the academia. This failure is due, particularly, to the
notion of a predefined process model, they rigidity of PSEEs which tend to provide more
support variety of processes. A PSEE is details to allow process execution.
basically centered on a Process Modeling
Language (PML) [15] and it provides tools to Many research works have focused on solving
validate process models and enact them. problems related to software process
enactment. For instance, the problem of
Using different PMLs, each of these heterogeneous formalisms used to describe
environments is based on a different syntax. software processes, the problem of geographic
Though, they are all designed around the distribution and the problem of deviations. The
following three parts defined in [6] and taken present paper focuses on the latter category; we
back by recent approaches: introduce in the following sections the concept of
deviation and most important contributions to
i. Process model: a static description of
solve this problem.
the process using a PML.
ii. Actual process: the process as it is
performed in real world. 3. DEVIATION CONCEPT
iii. Observed process: a reflected view of
the actual process in the PSEE. 3.1. Definition
In [12], these different views of a software A deviation is known as a performed action that
process are related through a consistency is not described in the predefined process model
relationship that determines the ideal execution or that violates some of the constraints
of a software process. Based on this expressed in the process [12]. For example,
consistency relationship, many problems, launching an activity of which preconditions are
related to software process enactment, may be false, assigning an activity to a person other
defined. than the authorized ones or an invalid number of
consumed or generated resources ...etc. A more
detailed example taken from [1] is given below.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 109
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
We have noticed that the definition given above corresponding to those described in the
can refer to the term inconsistency in some process model.
approaches. For instance, in [14] a deviation is iii. At its end: the PSEE verifies if the
defined as an inconsistency that may occur artifacts delivered by the activity are
during process enactment. On the other hand, in those expected according the process
[12] an inconsistency is known as the state of model.
software process resulting from a process
In this contribution, authors have focused on
deviation and it is the difference between the
artifacts consumed and delivered by the
actual value of a system variable and the software process activities to detect deviations.
expected value in [13]. However, experiences have shown that the
problem of deviation is not related just to
3.2. Example of deviation
artifacts, but also to agents and resources
Lots of approaches have been proposed to involved. More details will be discussed bellow.
support deviations during software process
enactment. These approaches differ in their 4. COMPARISON FRAMEWORK
procedures when detecting deviations and in
supports they offer to correct the resulting The deviation problem during process
inconsistencies. enactment is not a recent one. In 90s, many
research works have attempted to find out some
As an example, we take back the following solutions and propose prototypes to solve this
simple software process proposed by Da Silva problem.
et al. [1] and we explain how authors proceed to
detect deviations. For instance, The SPADE environment [3] [2],
which is based on a process modeling language
called SLANG (SPADE LANGuage), is a high-
level Petri nets based formalism that uses an O2
object-oriented database for the storage of
process data. Although it offers an extended
support to process evolution through the
reflectivity features of the SLANG, SPADE
assumes that humans involved in the
development process do not change the way
they work unless they change the process
model.
SENTINEL [9] is a PSEE prototype based on
LATIN activity-based language, it adopts Client-
Server architecture and records the relevant
events occurred during enactment in a
knowledge base. In SENTINEL, a history of the
entire process execution is stored and analyzed
Figure 2: Software Process Example [1].
off-line to discover deviations.
According to the authors, a deviation occurs PROSYT [8], which is, especially, conceived to
when one of these three verifications performed support any kind of distributed business
by the PSEE fails. These verifications are processes, adopts an artifact-based language
performed for each activity as follows: called PLAN. One of the key features of
i. When it is launched: the PSEE verifies if PROSYT is its ability to modify the level of
the required artifacts for its beginning, enforcement adopted and the consistency
according to the process model, are handling policy at enactment-time. Table 1
available. summarizes some relevant approaches that
ii. During its execution: the PSEE verifies have been proposed in the 90s to deal with
that the execution steps are deviations during software process enactment.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 110
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Table 1: Former Approaches dealing with deviations during SP Enactment.
Year Prototype Authors Description
1993 SPADE [3] [2] Bandinelli et al. Defined using a fully reflective language (SLANG) that is built
over a high-level extension of Petri nets. SPADE includes
mechanisms to integrate the definition of the process of
changing as well as the development process (meta-process).
1995 SENTINEL [9] Cugola et al. Based on the LATIN language, a knowledge base is used to
record relevant events occurred during enactment to perform a
pollution analysis, using a temporal-logic based approach, to
detect and tolerate some deviations.
1996 Endeavors [4] Bolcer and Taylor An open, extensible, Internet-based PSEE. It supports an
object-oriented definition of SP and both distribution of people
and artifacts. To support on the fly deviations handling, it allows
dynamic modification of object fields, methods and behaviors at
runtime.
1998 APEL [10] Dami et al. A framework that aims to support heterogeneous PSEE and to
support process evolution. Thanks to the process server, each
component (PSEE) can change the current process as well as
the process model.
1999 PROSYT [8] Cugola and Ghezzi Built around the PLAN language, it adopts an artifact-based
approach and it supports geographical distributed workgroups. It
allows process managers to define a deviation handling and a
consistency checking policies.
4.1. Criteria software process enactment, but also to
provide a reconciliation mechanism
In the remainder of this section, we will be between the process being enacted and
interested to recent contributions proposed to the model initially adopted. This
solve the deviation problem during software reconciliation can be automatic, semi-
process enactment. These approaches are automatic or ad-hoc.
based on former ones. Six solutions are
discussed and compared with respect to a set of 4.2. Discussions
criteria we have defined, including:
4.2.1. Classification and considered deviations
i. Proposed classification: to better
support deviations, some authors Many deviation classifications have been
propose to classify them with respect to proposed in the literature. In [6], deviations have
constraints they are violating or been classified into: (1) actual process deviation
consistency relationships are breaking which is an action that breaks the consistency
down, others based their solutions on relationship between the actual process and the
what has been already proposed. So, in process model, (2) observed process deviation:
a classification, more than one type is an action performed within the PSEE and that is
identified. not reflected in the process model, and (3)
ii. Type of deviations covered: based on environment deviation that breaks the
the classification adopted, more than
consistency relationship between the actual
one type of deviation can be considered
process and the observed process. This
by the proposed approach.
iii. Support type: the goal of most solutions, classification is taken back by the approach
considered in this paper, is not just to proposed in [12].
detect deviations that may arise during
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 111
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
In [14], a deviation can be either environment- ii. Activity invariant rules: define behavioral
level or domain-level. Environment-level constraints over a sequence of praxis
deviation refers to an inconsistency between the actions.
software performance and the process
enactment whereas a domain-level deviation is Deviation rules are associated with the process
the violation of a property defined in the model as logical formulas in the approach
performance model. According to the definitions proposed by Da Silva et al. [1]. To detect
given in this paper, software performance, deviation, the PSEE performs three kinds of
process enactment and performance model verification for each activity: 1) when it is
refer to actual process, observed process and launched, 2) during its execution and 3) when it
process model, respectively. Notice that this finishes. The failure of one of these verifications
classification has been proposed in [7]. means that the agent is deviating from the
process model.
A more detailed classification has been
proposed by Bendraou et al. in [5]. A deviation Logical formulas are also used by Kabbaj et al.
may be organizational, behavioral or structural. [12]. Each activity is associated with a set of pre
An organizational deviation occurs when an and post conditions and a set of invariants. The
activity’s deadline is not respected or because of transformation of the process model, defined as
a misallocation of roles...etc. Behavioral a UML profile, to logical formulas is obtained
deviation may be micro or macro one. The micro automatically using XMI. An action is considered
behavioral one appears when violating as a deviation if it is not deductible from the
methodological guidelines or business state that preceded its execution.
constraints while macro one arises when In [13], a list of deviation types is integrated into
developers change activities’ order. Finally, a the process model. Rule-sets that define pre and
structural deviation is gotten when post conditions are associated with each activity.
inconsistencies are found in a delivered model. Activity conditions are made up of N number of
rule sets. For a condition to pass, at least one
4.2.2. How to detect deviations and when?
rule set defined in the condition must pass.
Deviations can be detected either on the fly i.e. Otherwise, a deviation is generated.
during process enactment, or at the end of the
execution by analyzing data gathered during the An algebraic approach based on the polyadic
process enactment. To do that, PSEE performs has been proposed in [14] to detect
a set of comparisons between the process environment-level and domain-level deviations.
model and the process as it is performed which To not be faced to the complexity of the
allows to measure the distance between the , a visualization support, TRISO/ML
actual process state and the expected one. (TRidimensional Integrated Software
development model/Modeling Languages) has
To treat structural and micro behavioral been used, and a set of rules has been
deviations in the context of multi-viewpoint proposed for mapping software processes
development processes [5], each modeling modeled in TRISO/ML onto
action is represented using Praxis that has been
processes. The model checking
extended to represent the viewpoint in which it
allows detecting inconsistencies; also, some
has been performed. Praxis rules is the rule-
properties are used to detect enduring
based language that is used by the PSEE to
inconsistencies as control flow, data
detect deviations. To do that, the PSEE
dependency ...etc.
compares each rule with the praxis trace
captured from the process execution. Praxis The solution proposed in [16] is based on
rules can be: software visualization techniques. It is a set of
steps that are performed in parallel with SP
i. Activity post-condition rules: define
structural constraints over a sequence enactment. The approach identifies a partial set
of praxis actions. of nonconformities that are initially used by the
PSEE. The approach is artifact-based, i.e. to
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 112
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
detect deviations, it does not take into account Notice that approaches which report the
the activity performed, but just the outputs. So, detection of deviations until the end of the
the approach can only be applied when results process, by analyzing data collected and stored
are available. during enactment, or those which do not give
any support to correct deviations while
4.2.3. Dealing with deviations enactment, even if they are able to detect them
The increasing complexity of software products as they occur, do not offer great advantage
has made the issue of their creation complex because solutions they propose are either
and difficult to manage. Therefore, the goal is no pieces of advice to prevent future deviations or
longer to define the problems that may arise to change the model. More detailed are given
during software development but rather to find forward.
solutions to address these issues in order to
The approach proposed in [12] applies both
have high quality products.
solutions mentioned above. Each deviation type,
Most of the solutions mentioned above aimed to among the thirties identified, is associated with a
propose mechanisms that facilitate the detection tolerance value interval and a qualification,
of deviations that may occur during software minor or major. So, when detected, a deviation
development, but also to find out some solutions is analyzed, with respect to these criteria, and
to reconcile the process with its initial model, either tolerated or not. If not, changing the model
which defines the expected process. is adopted.
When a deviation is detected, two policies are A function generator is used in [1] to define a
widely adopted [6]: mapping between the observed process and
deviation causes to generate correction plans
i. Change the initial model, so it can that are proposed to the process agent. To do
support the carried out process. that, the PSEE continuously displays the set of
ii. Tolerate this deviation as much as it detected deviations with their associated risks.
does not affect the expected process; So, at each moment, the process agent may ask
i.e. its execution does not have great
the PSEE to guide him to fix detected deviations
impact on the process.
by generating a correction plan.
Table 2: Comparison framework of new approaches dealing with deviations during SP enactment.
Approaches
Creteria Thompson et Yang et al. Kabbaj et al. Zazworka et al. Almeida Da Bendraou et al.
al. [13] [14] [12] [16] silva et al. [1] [5]
Deviation None Adopted: Adopted: None None Proposed:
Classification
-environment -actual process -organizational
level -observed -micro behavioral
-domain level process -structural
environment -macro
behavioral
Type of A predefined Domain-level Observed Predefined set of Not specified Structural & micro
deviations list of 7 deviations process nonconformities (3 verifications behavioral
treated deviations deviations are scheduled) deviations
How to Comparison model Deduction Visualization Deduction a set of 7 rules/On
detect approach /On checking /At system/ On the approach/At the system/At the the fly
deviations the fly the end fly/ end of each step end
and when
Type of Ad-hoc Semi- Semi-automatic Ad-hoc automatic Semi-automatic
support automatic
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 113
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
No automatic guidelines have been given to Some relevant research works have been briefly
correct a deviation when it is logged in [13]. The presented and discussed. Three major criteria
detection engine compares data collected by the have been considered when discussing these
monitoring engine with the properties defined in approaches: (1) deviation types treated by the
the process model. If any deviation is logged, an approach; (2) how to proceed to detect these
alert appears. deviations and (3) what mechanisms have been
adopted to deal with detected deviations.
A model checking approach is applied to detect
deviations in software processes modeled with Almost all solutions have been validated through
the [14]. Processes are defined as prototypes with small executed examples.
a combination of activities and roles to which a However, software processes are, usually, very
set of rules is applied. complex and extended over several years. So,
validating these solutions on real software
Zazworka et al. [16] use a conformance projects may help integrating these
approach to detect deviations during software environments into industrial fields.
process enactment. It is a set of steps that
accompany the enacting process. A partial set of
nonconformities is defined to estimate the REFERENCES
conformance between the enacting process and
[1] M.A. Almeida da Silva, R. Bendraou, J.
the expected one. The approach is not applied Robin, and X. Blanc. Flexible deviation
on activities themselves but to artefacts that handling during software process
result from them. enactment. In Enterprise Distributed Object
Computing Conference Workshops
(EDOCW), 2011 15th IEEE International,
Table 2 summarizes what has been discussed pages 34–41, Aug 2011.
above. [2] S. Bandinelli, E. Di Nitto, and A. Fuggetta.
Supporting cooperation in the spade-1
5. CONCLUSION environment. IEEE Transactions on
Developing high quality software products Software Engineering, 22(12):841–865,
requires the cooperation of several factors. 1996.
Although new technologies have brought a lot of [3] S. Bandinelli, C. Ghezzi, A. Fuggetta, and L
facilities and improvement in these development Lavazza. SPADE: An environment for
software process analysis, design, and
processes, the human factor still plays a major enactment. In Software Process Modeling
role in their success. and Technology, pages 223–248. Wiley,
1994.
Supporting human actors to achieve the [4] G. A. Bolcer and R. N. Taylor, “Endeavors:
required quality products has led to propose A Process System Integration
Infrastructure”. In Proceedings of the Fourth
dedicated environments called Process- International Conference on Software
centered Software Engineering Environments Process (ICSP4), Brighton, UK, December
(PSEEs). Having a description of the process 1996.
model to enact, the PSEE is supposed to guide [5] R. Bendraou, M. A. Almeida da Silva, M. P.
human agents to achieve the required quality of Gervais, and X Blanc. Support for deviation
detections in the context of multi-viewpoint-
a software product. based development processes. In CAiSE
Forum, pages 23–31, 2012.
The trend of PSEEs towards modeling software [6] G. Cugola. Tolerating deviations in process
processes details has made them inflexible and support systems via flexible enactment of
rigid. People often need to deviate from the process models. IEEE Transactions on
Software Engineering, 24(11):982–1001,
process model to cope with unexpected events 1998.
that may occur during software process
[7] G. Cugola, E. Di Nitto, A. Fuggetta, and C.
enactment. Thus, providing mechanisms to deal Ghezzi. A framework for formalizing
with these deviations has become crucial. inconsistencies and deviations in human-
centered systems. ACM Trans. Softw. Eng.
In this paper, we have given an overview of Methodol., 5(3):191–230, July 1996.
deviation problem during software process [8] G. Cugola and C. Ghezzi. Design and
enactment through an illustrative example [1]. implementation of prosyt: a distributed
process support system. In Enabling
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 114
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Technologies: Infrastructure for
Collaborative Enterprises, 1999. (WET ICE
’99) Proceedings. IEEE 8th International
Workshops on, pages 32–39, 1999.
[9] G. Cugola, E.Di Nitto, C. Ghezzi, and M.
Mantione. How to deal with deviations
during process model enactment. 17th
International Conference on Software
Engineering, pages 265–265, 1995.
[10] S. Dami, J. Estubler, and M. Amiour. Apel: A
graphical yet executable formalism for
process modeling. In E. Nitto and A.
Fuggetta, editors, Process Technology,
pages 61–96. Springer US, 1998.
[11] V. Gruhn. Process-centered software
engineering environments, a brief history
and future challenges. Annals of Software
Engineering, 14(1-4):363–382, December
2002.
[12] M. Kabbaj, R. Lbath, and B. Coulette. A
deviation-tolerant approach to software
process evolution. In Ninth international
workshop on Principles of software
evolution: in conjunction with the 6th
ESEC/FSE joint meeting, IWPSE ’07, pages
75–78. ACM, July 2007.
[13] S. Thompson, T. Torabi, and P. Joshi. A
framework to detect deviations during
process enactment. In Computer and
Information Science, 2007. ICIS 2007. 6th
IEEE/ACIS International Conference on,
pages 1066–1073, July 2007.
[14] Q. Yang, M. Li, Q. Wang, G. Yang, J. Zhai,
J. Li, L. Hou, and Y. Yang. An algebraic
approach for managing inconsistencies in
software processes. In Software Process
Dynamics and Agility, pages 121–133, 2007.
[15] K. Z. Zamli and P. A. Lee. Taxonomy of
process modeling languages. In Computer
Systems and Applications, ACS/IEEE
International Conference on. 2001, pages
435 – 437, June 25-29 2001.
[16] N. Zazworka, V.R. Basili, and F. Shull. Tool
supported detection and judgment of
nonconformance in process execution. In
Empirical Software Engineering and
Measurement, 2009. ESEM 2009. 3rd
International Symposium on, pages 312–
323, Oct 2009.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 115