A Deviation Management System For Handling ...

A Deviation Management System For Handling Software Process Enactment Evolution Ph.D. Thesis Mohammed Issam KABBAJ

Supervised by Dr. Redouane LBATH, Pr. Bernard COULETTE IRIT UNIVERSITY OF TOULOUSE - FRANCE

Introduction - Problem Description - Proposed Approach – Detecting Deviation System - Deviation Management System - Conclusion

Introduction • Context : • Enactment of software process models in Processcentered Software Engineering Environments (PSEE). • Problem : permanent evolution of software processes • material failure, • technological change, • No respect of deadlines, ….

• Difficulty : Incapacity to be completely defined in advance and to follow a model. => Deviations inevitably occur and have to be managed University of Toulouse

Mohammed Issam KABBAJ

2


Introduction • Existent PSEEs : • Most of them are rigid i.e. prescriptive. • Some Works/PSEE endeavor to resolve the problem but in the best case, deviations are partially controlled.

University of Toulouse


3


Introduction • Objectives : • Deviation Management during process enactment (more flexibility). • Take into account specific and context-dependent aspects of actual processes. • Refuse or tolerate deviations. • Dynamic adaptation of software process models.



4

Introduction - Problem Description - Proposed Approach Detecting Deviation System - Deviation Management System - Conclusion

Illustrating Process Example • Student Project : It is a simplistic process favored by our students in developing small‐size software within a few weeks.

Université de Toulouse


5


Deviation Problem Example (Student Project) : Launch « Coding » without « Design »

G

ui d

es

Deviation

Always True (Working Hypothisis)

s m or f n o C

Re fl e ct

s

Conforms



6


Assumptions • Absence of deviation is the exception, not the rule. • Process models are needed to guide humans, not to be enforced prescriptively. • Process models should not be an obstacle. • Humans must always be allowed to decide whether to follow process models or not whenever they need to face unexpected situations or to improve process models.



7


Basic Idea Real Process

Generic Process Model

Monitoring

Instantiating Enacting Process Model (EPM)

Based on

Observed Process Model (OPM)

Comparing + Analyzing => - Detecting deviations - Making decision (Accept/refuse deviations ) University of Toulouse


8

9In Deviation-Tolerance Model consists Monitoring System (MS) : used to- Proposed Approach 9 case of deviation, DMS Introduction - Problem Description of DT Rules collect events relating to the(DDS) actualis 9 Detecting Deviation system selects applicable rule from Detecting Deviation System Deviation 9 DT Rules can be interpreted as Management System - Conclusion process (visible performed informed by MS of changes of the Deviation-Tolerance Model actions) directives for deviations. 9actual OPM elements associated with process arethe 9 Refuses/accepts 9 DT Rules and DTIlisteners values are specified observers (event changes 9 Following changeover, DMStocompares deviation according to the by the Process Designer on the basis of OPM elements’ proprieties) EPM & OPM looking for deviation rule of his/her expertise.

Architecture

Perform

Actual Process

Human Actors informs

Deviation-tolerance

request

observes

Model

deviations

actions

uses

Deviation

Process

Management

Enactment Engine

uses / uses

informs

Detecting

Monitoring

Deviation

System

System

informs

System uses

adapts uses

builds

uses / rectifies

Enacting

Observed

Process Model


inform

Process Model


9


Nominal Behavior • The Process Enactment Engine (PEE) is a module in charge of enacting process models. • It is based on : – structure of process models. – behavior of process elements (expressed as state machines that describe their nominal life cycles, i.e. without deviations.)

Université de Toulouse


10


Logical Formalization • Let M be the union of the sets of formulas that describe : – The structure of process model (e.g. the Student Project (SP)) { activity(Design); activity(Coding); artifact(Specifications); input(Specifications, Design) ; validated(Design) → precedence(Coding) ;}

– The behavior of an enacting process model (extract) { ∀w (initial(w) ∧ activity(w) → enactable(w)) ; ∀w ((precondition(w) ∧ precedence(w) ∧ enactable(w)) → activatable(w)) ; ∀w∀r ((activatable(w)∧responsibleForWork(r, w))→ operation(launch, w,r)) ;} . – The observed process model (e.g. SP) operation(launch, Design, Designer); enacting(Design); • Let o be an operation executed by human actors (e.g. SP). operation(launch, Design, Designer);

o is not a deviation ⇔ M |⎯ o . Université de Toulouse


11


Example of Logical Formalization o = operation(launch, Coding, Developer) . M = { responsibleForWork(Developer, Coding); validated(Design) → precedence(Coding) ; ∀w∀r ((activatable(w) ∧ responsibleForWork(r, w)) → operation(launch, w, r)) ; ∀w (enactable(W) ∧ precedence(W) → activatable(w)); enacting(Design) ; enactable(Coding) ; … } . M |‐⎯/⎯ o . Thus, o constitutes a deviation. Université de Toulouse


12


Deviation-Tolerance Model • The deviation‐tolerance model helps process designers – Clarify parts of the process that should never endure deviations. – authorize deviations in order to meet specific needs, and thus improve process models’ flexibility.

• It consists of deviation‐tolerance rules rules ProcessElement



13


Example of Deviation-Tolerance Model • Description : “In case of violation of precedence of an activity w, then if all input of w is in the state Draftβ with at least a 90% degree of achievement, the deviation is to be qualified as minor and is to be tolerated (with DTI=0.9)”. • Deviation : ∃ r (operation(launch, w, r) ∧ ¬precedence(w))

• Context : ∀ P (input(P,W) → (Draftβ(P) ∧ GreaterThan(achievement(P), 90%))) • Qualification : minor University of Toulouse

Deviation Tolerance Index : 0.9


14


Intervals of Deviation-Tolerance values

Tolerance deviation Indicators (DTI) associated to process elements : DTI Є[0 , 1].

0

zero-tolerance interval The deviation is incompatible with the development

NT

uncertainty = interval A human intervention is needed

TT

tolerance interval

1

The deviation is Acceptable

The threshold values may be adjusted dynamically



15


Handling Deviations • When a deviation occurs select the applicable rule

Adding rules ∈ Uncertainty Interval

∈Tolerance

Index

Interval


Accept deviation Type

∈ Zero-tolerance Interval

Human Decision

Deviation Tolerance Rules

major

Reject deviation

Model Changing


minor

Model Relaxing 16


Conclusion & perspectives

Deviations always occur during development Software process => unexpected situation To cope with process deviation

• Two models :

1. Enacting process model (EPM); 2. Observed process model (OPM).

• Tolerance deviation Indicator. = Dynamic Adaptation of Software Process Current investigations 9 Validation of our approach by a industrial processes. 9 Ensuring that Model-changing approach do not generate new

inconsistencies in case of major deviation.



17

Thank you • Any Questions ? • Any Suggestions ?

University of Mirail Toulouse


18