A Deviation-tolerant Approach to Software Process Evolution KABBAJ Mohammed
LBATH Redouane
COULETTE Bernard
Université de Toulouse II – IRIT 5, allées Antonio Machado, F-31058 Toulouse Cedex 9, FRANCE Tel +33 (0) 561 50 39 85, Fax +33 (0) 561 50 25 40
[email protected]
[email protected]
[email protected]
The paper is organized as follows. Section 2 deals with problems and concepts of process deviations and evolution. Section 3 outlines the approach we propose to modeling and handling process enactment evolution. Finally conclusions and further works are outlined in Section 4.
ABSTRACT An important problem encountered in Process-centered Software Engineering Environments (PSEE) is that software development processes are subject to permanent dynamic evolution. Without managing process enactment evolution, PSEEs are condemned to fail in being adopted in software development industry. This article presents an original approach to software process enactment evolution based on dynamic adaptation of processes and tolerance of deviations.
2. PROCESS ENACTMENT EVOLUTION 2.1 Consistency of Supported Processes First of all, let us define some of the terms used in the remainder of this paper (see [4] for more detailed definitions): Process model is a static description of the expected software process expressed in a Process Description language. A process model is typically composed of activities (tasks), which represent work items to be executed by a human or automated resource. Actual process is the actual software process as it is performed in the real world. During process model enactment, a PSEE has a partial view of the actual process. This partial view of the actual process owned by the PSEE is called the Observed process. At each instant, it may be described by a history of the activities that users perform under the PSEE control to carry out the process. Figure1 shows the consistency relationships that constantly link process model, actual process, and observed process when the process proceeds as expected.
Keywords Process-centered Software Engineering Environment, Software Process Evolution, Evolutional Enactment of Software processes.
1. INTRODUCTION Researchers and practitioners have realized that a process model being enacted must be flexible enough to allow process changes to face unexpected situations. Processes need to continuously undergo changes and refinements to increase their ability to deal with customer’s requirements, and expectations of the market. Consequently, PSEEs (Process-centered Software Engineering Environment) must accept a permanent evolution of process models, and tolerate and manage inconsistencies and deviations. This requirement reflects the nature of a creative activity such as software development, where consistency is the exception and not the rule [1]. The objectives of the work presented in this paper are to allow a dynamic adaptation of process models so as to support process enactment evolution. Addressed processes are those of organizations where the software process corresponds to « The Defined Level » of maturity according to the Capability Maturity Model [11]. The approach we propose is based on detection and management of process deviations. We propose to make coexist two process models: a preset process model that guides development, and an observed process model that is dynamically constructed by observing visible actions of human actors. The two process models are permanently compared and analyzed in order to detect deviations. Once a deviation is detected, a deviationtolerance model attached to the preset process is used to decide whether to accept or to reject the deviation.
Figure 1 – Software process consistency relationships In ideal situation, the process model guides and supports the actual process, so the actual process must be conform to the process model. The observed process reflects as must as possible the actual process, so by transitivity, the observed process must be conform to the process model. Thus, the actual process is consistent with the process model, i.e., it proceeds as described in the process model, without violating the model. Similarly, the observed process is consistent with the actual process. This means that the PSEE has a correct view of the actual process. Finally, the observed process is consistent with the process model, which means that the PSEE is enacting the process model and it is not violating any of the constraints stated in the model.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWPSE'07, September 3-4, 2007, Dubrovnik, Croatia Copyright 2007 ACM ISBN 978-1-59593-722-3/07/09...$5.00. 75
analyze it and support developers in reconciling the actual process and the observed process with the process model. The PSEE tolerates the deviation.
2.2 Concepts of Deviation and Inconsistency In an ideal world, deviations never occur. Unfortunately, it is not always the case. People behave differently in different situations and, therefore, it is hard to capture in advance in a formal process model all the possible behavior of a complex and dynamic system like a software process development. Unforeseen situations may always occur. Typically, the effect of an unmanaged failure or exception is an action that breaks the consistency relationships shown in Figure 1. This often leads to the impossibility of continuing executing the process under the PSEE’s control. To better clarify possible effects of undesired events not adequately managed by the PSEE, we use the terminology of [4]:
2.4 Related Work To our knowledge, despite the important research work on software process evolution archived so far, there has not been very much work dealing with process enactment evolution. In a previous research work, we developed RHODES [5] that manages dynamic inconsistencies through an exception handling mechanism. However, process deviations are not supported. Other significant works dealing with process enactment evolution are those of SPADE [2][3], and SENTINEL [6]. As the majority of existing PSEEs, SPADE assumes that humans involved in the development process do not change the way they work unless they change the process model. The SPADE approach is not suitable to coping with temporary deviations due to the effort required to modify process models. The problem of supporting users in facing unforeseen situations is solved by providing features for changing process models on-the-fly. This approach has proven to be effective to cope with major deviations from process models that are expected to occur again in the future, but the effort required to change process model makes the approach unsuitable to coping with situations that require minor or temporary deviations. SENTINEL was the result of a preliminary exploration of the problem of improving usability of PSEEs by tolerating deviations from process description. It tolerates deviations while invariants that define the critical requirements of the process are not violated. But it makes no difference between deviations according to their origin, and has no consistency handling policies. However, practical situations of real-world software development require context-dependant tolerance of deviations.
Deviation. It is an action performed that is not described in the predefined process or that violates some of the constraints expressed in the process. Inconsistency. It is a state of software process resulting from a process deviation. Depending on the relationship broken we distinguish among: Actual process deviation. It is an action that break the consistency relation between the actual process and the process model leading to an actual process inconsistency. Usually, actual process deviations are the result of an exception. Observed process deviation. It is an action performed within the PSEE that is not reflected in the process model. These deviations break the consistency relation between the observed process and the process model, leading to an observed process inconsistency. Environment deviation. It is an action that breaks the consistency between the actual process and the observed process. It typically occurs when someone performs an action that is relevant for the process, out of the PSEE control. The PSEE has then an incorrect view, so it cannot correctly support the actual process anymore.
3. PROPOSED APPROACH
A PSEE is said to be coherent [7] if it is capable of tracking all developers’ actions relevant to the process. This property reduces the chances that environment-level deviations may occur.
3.1 General Overview To support software process enactment evolution, we propose to use both Model Relaxing techniques and Model-changing techniques in order to dynamically adapt the process model. We propose to use model relaxing techniques to cope with unexpected events that are assumed to be exceptional and require an immediate answer by the system, and model-changing techniques for unexpected events that assumed to be of a deep impact on the process. Figure 2 shows a synopsis of our approach, which mainly consists of the following elements: Enacting Process Model (EPM), Observed Process Model (OPM), Deviation-Tolerance Model (DTM), Monitoring System (MS), Deviation Management System (DMS).
2.3 Dealing with Process Enactment evolution To face unexpected situations, different solutions are possible [6]: • Nothing is done. The process model is not modified and actions needed to cope with the unexpected situation are performed out of the PSEE control. As a consequence, the PSEE cannot analyze the deviation, nor can it support developers in reconciling the actual process with the process model. • Model-changing. PSEE provides mechanisms to change the process model on-the-fly. Before doing any action, the process model is modified. A description of actions that have to be performed in order to cope with the unexpected situation is added to the model and the PSEE is given the new process model to enact. The result of this approach is that consistency of process relationships is restored.
EPM represents the process model that actually guides the development process. Initially, it is obtained by instantiating a generic process model, which represents the “ideal” process. OPM represents a description of the actual process which reflects visible actions that human actors perform while carrying out the process. DTM consists of deviation-tolerance rules that describe tolerance to process deviations, depending on the context of unexpected events. MS is a module in charge of collecting events related to the performed process in order to build OPM. Collected events may result from visible performed actions. They also may be provided by human actors explicitly. DMS is a module in
• Model-relaxing. The process model is not modified but the PSEE provides mechanisms to explicitly deviate from the model without the need of modifying process model. The PSEE offers the possibility of executing actions necessary to cope with the unexpected situation under its control, by explicitly deviating from the process model The PSEE is aware of the deviation; it can
76
that the process would have if the requested deviation were accepted. For example, if the request is to ignore a precondition of an activity, the corresponding events would indicate that the activity is launched and the precondition is violated.
charge of comparing EPM and OPM in order to detect process deviations, and to decide whether to accept or to reject deviations according to DTM. When an accepted deviation is assumed to be of a deep impact on the process, EPM is adapted according to the deviation (model changing). Otherwise, EPM remains unchanged and thus the deviation is tolerated (model relaxing). Actual Process
Without deviations, OPM indicates at each instant parts of EPM that have been performed and parts of EPM that have to be performed in the next instant. So, in this case, OPM would represent the trace of following EPM without deviation.
perform
When an event indicating deviation occurs, OPM is modified accordingly, unless the deviation is rejected. If the event results from a visible action performed by human actors, OPM will indicate the observed deviation. If the event results from a request of human actors for deviating from the predefined process, then OPM will “simulate” the requested deviation.
Human Actors observes performed actions
inform
guides Deviation Management System
Monitoring System
3.4 Deviation-tolerance Model
adapts
Enacting Process Model
uses
builds
DeviationTolerance Model
Observed Process Model
A deviation corresponds to the non-observance of a property of an element of the process model, e.g. “launching an activity whose precondition is not satisfied”, “not involving a role that should take part in an activity”, “pursuing an activity whose invariant has been violated”, etc. We identified about thirty deviation types up to now, according to violation of process elements’ properties, or broking their relationships.
Figure 2 – Synopsis of our approach
The deviation-tolerance model (DTM) consists of rules that describe tolerance to process deviations for unexpected events. Tolerance to a deviation is expressed as a numeric value ranging from 0 to 1. 0 means that the deviation is unacceptable. 1 means that the deviation is tolerable. Other values mean that the deviation is more or less tolerable. In addition, two threshold values are defined: tolerance threshold (TT) and non-tolerance threshold (NT). So, the interval [0,1] is partitioned into three intervals: zero-tolerance interval, from 0 to NT; uncertainty interval, from NT to TT; and tolerance interval, from TT to 1.
3.2 Modeling the Enacting Process Model Before the process enactment starts, the Enacting Process Model (EPM) is created by instantiating a Generic Process Model (GPM) that describes know-how and policies of software development of a given organization. GPM conforms a UML process meta-model (PMM) described in [8][9], which is an extension of SPEM, the OMG Software Engineering Process Meta-model [10]. PMM formalism is defined as a UML profile that allows specification of activities with associated pre-conditions, post-conditions, and invariants, roles played by actors, tools to be used, artifacts, and guidance for achieving activities. All the elements taken of SPEM/UML, keep the syntax and semantics defined in SPEM (or UML). Tool describes a software tool in the broad sense: source code editor, compiler, etc. ProcessElement is a generalization of WorkDefinition, WorkProduct, Role, and Tool. EPM is created by customizing GPM to a particular software project, by defining specific activities, identifying human actors and tools, assigning roles and resources, and setting correct initial states.
As shown by figure 3, deviation-tolerance rules (DTRs) are associated with process elements (activities, roles, artifacts, tools, …). A rule consists of three parts: deviation, which indicates the nature of deviation; context, which specifies a logical expression that describes the context of tolerating or rejecting the deviation, and deviation-tolerance index (DTI). ProcessElement
1
rules
DTR
Deviation * Context ProcessElement DTI value Figure 4 – UML Model for deviation-tolerance rules
3.3 Monitoring System The Monitoring System (MS) is a module in charge of collecting events related to the performed process in order to build the Observed Process Model (OPM). There are two sources of events: visible actions performed by human actors, and explicit requests of human actors for deviating from the predefined process in order to face unexpected situations. Process elements of EPM are associated with observers, which are event listeners to changes of significant process elements’ properties. For example, each activity of EPM is associated with an observer of its state (launched, finished, validated, etc.). Each change of the activity’s state will produce an event to be collected by the observer and transmitted to the Monitoring System.
Process elements having a DTI value of DTR that belongs to the zero-tolerance interval cannot be subject of deviation. Process elements having a DTI value of DTR that belongs to the tolerance interval are elements for which deviation is tolerated. DTI values of DTR within the uncertainty interval are attached to process elements that tolerance of deviation is context-sensitive. In addition, we allow the project manager to change on-the-fly the deviation politics, thus he/she can impose new politics by adjusting the three intervals of tolerance, i.e. by modifying the threshold values TT and NT. This adjustment strongly depends on the project state on the one hand and the policy of management employed by the project leader.
Explicit human requests actors for deviating from the predefined process are translated into events corresponding to the new state
77
principle discussed in section 2.3).
The process designer specifies DTRs and DTI values on the basis of his/her expertise. He can specify process parts that should never undergo deviations. He can also improve the flexibility of the process model, while authorizing deviations in order to meet specific need, if the context recommends it.
(2) The deviation is qualified as a major deviation. Then, EPM is modified according to the deviation. All consistency relationships discussed in section 2.1 become again satisfied.
4. Conclusion and Current Works
3.5 Deviation Management System
An important problem encountered in PSEEs is that software processes are subject to permanent dynamic evolution. Without managing process enactment evolution, PSEEs are condemned to fail in being adopted in software development industry.
The deviation management system (DMS) is in charge of comparing EPM and OPM in order to detect process deviations, and to decide whether to accept or to reject deviations according to DTM. The process of detecting deviations is launched whenever an event is collected by the monitoring system. For each event, EPM and OPM are compared, in order to detect eventual deviations. The process of using DTR rules is launched for each deviation detected. The event that has lead to the deviation is analyzed in order to determine the related process element. Then, DTR rules attached to the process element are considered. DTR rules that match with the type of deviation and whose context part matches with the current context of the development are selected. And finally, the rule of the weakest DTI is used to set a tolerance value to the deviation.
This article has presented an original approach to allow dynamic adaptation of process models so as to support process enactment evolution. The proposed approach consists of using deviationtolerance rules to allow the observed process model deviate from the preset process model, and thus to allow process enactment evolution. The observed process model is permanently analyzed in order to detect deviations. Once a deviation is detected, deviation-tolerance rules are exploited to decide whether to accept or to reject the deviation. We are currently working on the following points: - Formalization of process models in terms of logical assertions in order to handle deviations as violation of logical constraints. - Elaboration of a prototype that implements our approach. - Validation of our approach by a case study example.
Actions to be envisaged for a deviation depend on two different criteria: (1) the interval that the deviation’s tolerance value belongs to (zero-tolerance interval, tolerance interval, or uncertainty interval); and (2) the qualification of the deviation, minor or major, set by the process manager at the enactment time. A minor deviation is assumed to be exceptional and temporary deviation that requires no change of the process model. A major deviation is assumed to be a deviation of a deep impact on the process that requires changing the process model. So, DMS uses both model changing and model relaxing approaches (discussed in section 2.3). If an accepted deviation is assumed to be of a deep impact on the process, EPM is adapted according to the deviation (model changing). Otherwise, EPM remains unchanged and thus the deviation is tolerated (model relaxing).
5. References [1] Balzer B., “Tolerating inconsistencies,” at Int. Conference on Software Engineering (ICSE 13), Austin (TX), 1991. [2] Bandinelli S., et al. Process Modelling-in-the large with SLANG, Proceedings of the 2nd Int. Conference on the Software Process, Berlin (Allemagne), 1993. [3] Bandinelli S., et al. SPADE: An Environment for Software Process Analysis, Design and Enactment. In Software Process Modelling and Technology, A. Finkelstein, and al, Wiley, London, 1994, pp. 223--244. [4] Casati F. and Cugola G. Error handling in process support systems. In Advances in Exception Handling Techniques, A. Romanovsky et al, Eds. Springer-Verlag, NY, 251-270 2001. [5] Coulette B., et al., RHODES, a Process Component Centered Soft. Eng. Environment, ICEIS, Stafford, 2000. [6] Cugola G. Tolerating Deviations in Process Support Systems VI Flexible Enactment of Process Models, IEEE Transactions on Software Engineering, vol. 24, No 11, 1998. [7] Cugola G., et al. A Framework for formalizing Inconsistencies in Human-Centered Systems, ACM Trans. One Soft. Eng. and Methodology (TOSEM), vol. 5, 1996. [8] Lbath R. A Multi-Agent Approach for Modelling and Enacting Processes of Software Projects Development. Proceed. IEEE ISSPIT'02, p 208-213, Morocco. 2002. [9] Lbath R., Coulette B. et al. A multi-Agent Approach to a SPEM-based Modeling and Enactment of Soft. Develop. Processes. Proceed.SEKE, Taipei, Taiwan, 2005. [10] OMG, SPEM specification, Version 1.0, formal/02-11-14, November 2002. [11] Capability Maturity Model Integration, CMMI-DEV, V1.2. Soft. Engineering Institute, CMU/SEI-2006-TR-008, 2006.
• Dealing with DTI values and tolerance intervals. Three cases are possible for a deviation: (1) The deviation’s DTI value belongs to the tolerance interval [TT,1], i.e. the deviation is acceptable (that could mean for example that the deviation relates to an optional process element). Then, the deviation is automatically tolerated. (2) The deviation’s DTI value belongs to the zero-tolerance interval [0,NT], i.e. the deviation is incompatible or unacceptable with the development. That means that the deviation relates to an essential and obligatory process element. Therefore the deviation is automatically rejected. OPM is then reset to its state previous (3) The deviation’s DTI value belongs to the uncertainty interval [NT,TT]. Human decision is requested to whether accept or reject the deviation. Risks, costs, and reconciliation actions necessary to keep the project coherence should be considered by human actors before making decision. • Dealing with qualifications of tolerated deviation. Two cases are possible for a tolerated deviation: (1) The deviation is qualified as a minor deviation. Then, OPM is modified according to the deviation so that it reflects the actual process, but EPM remains unchanged and continues to be enacted for guiding the development (application of the model relaxing
78
