OMEGA : un formalisme et un système pour le monitoring des processus dans le cadre des environnements de génie logiciel

Transcription

1 THESE présentée à L UNIVERSITE DE SAVOIE ECOLE SUPERIEURE D INGENIEURS D ANNECY (ESIA) par Sorana CÎMPAN pour obtenir le DIPLÔME DE DOCTEUR DE L UNIVERSITE DE SAVOIE (Arrêté ministériel du 30 Mars 1992) spécialité : Informatique OMEGA : un formalisme et un système pour le monitoring des processus dans le cadre des environnements de génie logiciel Soutenue publiquement le 28 janvier 2000 devant le jury composé de : M. Flavio OQUENDO Directeur de thèse Professeur à l Université de Savoie M. Pierre-Yves CUNIN Rapporteur Professeur à l Université Joseph Fourier, Grenoble M. Carlo MONTANGERO Rapporteur Professeur à l Université de Pise, Italie M. Gilles MAURIS Examinateur Maître de Conférence à Université de Savoie M. Christian ROBICHON Examinateur Docteur - Ingénieur à Dassault Systèmes, Paris M. Brian WARBOYS Examinateur Professeur à l Université de Manchester, Royaume-Uni Thèse préparée au sein du LLP/CESALP

2

3 A mes proches

4

5 Abstract During the past years, requirements related to the software quality and the productivity of software organisations have lead towards a process centred software development. Propositions of models for evaluating the software maturity followed on this orientation. Most of them provide a scale containing the following five levels: initial, repeatable, defined, managed and optimised. At the highest levels (managed and optimised) the quantitative control is required. Still the existing software support for this aspect remains limited, the issue of control and its support remaining an open one. We address in this thesis the problem of software process control using a feedback loop: monitoring, decide, change and we focus on the monitoring issue. The monitoring is defined as the process observation and analyse in order to detect deviations with respect to an expected behaviour, the later being represented by a process model instantiation, tolerances specified by the user being taken into account. We propose a formalism for monitoring model definition as well as mechanisms for executing such models. It is thus possible to define the information to be handled by the monitoring as well as the transformations that are to be applied to it. The transformations are grouped into two types: calculus transformations for the analyse and communication transformations for the integration in a given environment. The language allows the definition of models that compute the conformance between an observed process and an expected behaviour of this process. In a reflexive approach, we use monitoring models that have monitoring systems as subject. Thus the latest can be dynamically tuned to their work context using a feedback loop. The use of fuzzy logic in the information acquisition, representation and analyse allows to handle the possible imprecision or uncertainty of the information. Our proposition was developed and validated in the framework of the European long-term research project ESPRIT IV LTR PIE (Process Instance Evolution). Key words: Monitoring, Software Process, Software Engineering Environment and Fuzzy Logic

6

7 TABLE DES MATIERES CHAPITRE I INTRODUCTION... 1 I.1 INTRODUCTION A LA PROBLEMATIQUE... 1 I.2 CADRE DE LA THESE... 3 I.3 ORGANISATION DU DOCUMENT... 3 CHAPITRE II SUPPORT AUX PROCESSUS LOGICIELS : CADRE ET TERMINOLOGIE... 5 II.1 LA MATURITE DES PROCESSUS LOGICIELS... 7 II.1.1 Introduction... 7 II.1.2 Le cadre d évaluation du processus... 8 II Concepts fondamentaux d évolution du processus... 8 II Les niveaux de maturité... 9 II.2 LES PROCESSUS LOGICIEL ET LEURS SUPPORTS II.2.1 Les domaines du processus logiciel II L influence de l exécution sur la mise en œuvre II Le retour d information concernant la mise en œuvre II Interaction entre le domaine d exécution et le domaine de la définition II.2.2 Considérations concernant les interactions entre les différents domaines et le problème de l évolution II Incohérence et déviations II Une vision étendue des domaines du processus logiciel II Quel niveau de maturité? CHAPITRE III L ETAT DE L ART III.1 L EVALUATION DU PROCESSUS III.1.1 CMM III.1.2 Bootstrap III.1.3 SPICE III.1.4 Bilan sur les modèles d évaluation du processus III.2 L AMELIORATION DU PROCESSUS III.2.1 QIP III.2.2 Personal Software Process III.2.3 Amélioration des processus manufacturiers III.2.4 Bilan sur les modèles d amélioration du processus III.3 LES SYSTEMES DE MESURE ET D ANALYSE III.3.1 Critères de l étude III Critères liés aux données et mesures III Critères liés aux analyses III Critères liés aux caractéristiques du système III.3.2 Tame III.3.3 Amadeus III.3.4 Hakoniwa III.3.5 BALBOA III.3.6 Méthode pour l analyse des données historiques III.3.7 Expérimentation de prototypage du monitoring III.3.8 Software Management Environment III.3.9 WebME... 58

8 Chapitre I III.3.10 Tempo III.3.11 Caractéristiques des systèmes tableau récapitulatif III.3.12 Bilan sur les systèmes étudiés III.4 LES EGLCP ET LE PROBLEME DE L INCOHERENCE III.4.1 SPADE III.4.2 SENTINEL III.4.3 PEACE III.4.4 APEL III.4.5 Bilan III.5 CONCLUSION CHAPITRE IV OMEGA/LDM : LE LANGAGE DE DEFINITION DU MONITORING IV.1 L APPROCHE POUR LE MONITORING DANS OMEGA IV.1.1 Le monitoring dans le support de processus logiciel IV.1.2 L environnement OMEGA : un aperçu IV.1.3 La logique floue : un outil théorique pour le monitoring IV La nature des informations IV Les outils IV La représentation de l information en utilisant la théorie des sous-ensembles flous IV Des traitements portant sur des informations imprécises IV Bilan IV.2 LE FORMALISME OMEGA/LDM IV.2.1 Les concepts clés IV Modèle de monitoring IV Les univers IV Les informations IV Les transformations IV.2.2 Les transformations de calcul IV Les expressions IV Les fonctions d appartenance IV Les traitements des informations linguistiques à l aide des règles IV Les formules de comparaison IV.2.3 Les transformations de communication IV Les transformations utilisées dans la gestion des entrées IV Les transformations utilisées dans la gestion des sorties IV.3 CONCLUSION CHAPITRE V... VALIDATION D OMEGA/LDM : ETUDES DE CAS DE MONITORING ET META- MONITORING V.1 L EXECUTION AVEC OMEGA/ME V.2 ETUDES DE CAS : MODELES DE MONITORING V.2.1 Le modèle du progrès V.2.2 Le modèle de la confiance de finir dans le délai V Présentation V Modélisation et exécution V.2.3 Le modèle de concordance structurelle V Présentation V Modélisation et exécution V.2.4 Le modèle de la chance de succès V Présentation V Modélisation et exécution V.3 DOMAINE D APPLICATION ET SCENARIO D UTILISATION V.3.1 Du processus logiciel au processus a fort composant logiciel V.3.2 Un processus dans l industrie automobile V.4 LE META-MONITORING V.4.1 Le contexte du système de contrôle : le méta-contrôle V.4.2 Le méta-monitoring : monitoring du monitoring V.4.3 La fréquence des alarmes : un modèle de méta-monitoring V Présentation V Modélisation V.5 CONCLUSION

9 CHAPITRE VI IMPLEMENTATION DE L ENVIRONNEMENT DE MONITORING OMEGA VI.1 PRESENTATION VI.2 CONSTRUCTION D UN SYSTEME DE MONITORING VI.3 ARCHITECTURE ET FONCTIONNEMENT VI.3.1 Le noyau VI.3.2 Le gestionnaire des communications VI.4 IMPLEMENTATION CHAPITRE VII CONCLUSIONS ET PERSPECTIVES VII.1 BILAN ET REMARQUES SUR L UTILISATION D OMEGA VII.1.1 La modélisation en OMEGA/LDM VII.1.2 L utilisation des modèles VII.1.3 L utilisation des facteurs de concordance dans le modèle d analyse VII.1.4 La composition du modèle d analyse et les fonctionnalités du système de monitoring VII.1.5 Validation d OMEGA VII.2 BILAN ET REMARQUES SUR OMEGA ET L ETAT DE L ART VII.3 PERSPECTIVES VII.3.1 Continuation du travail sur OMEGA VII.3.2 Nouvelles applications VII.3.3 Nouveaux thèmes de recherche REFERENCES BIBLIOGRAPHIQUES ANNEXE A : LA GRAMMAIRE DE OMEGA/LDM ANNEXE B : MODELES DE MONITORING POUR LES ETUDES DE CAS EN OMEGA/LDM ANNEXE C : PUBLICATION DANS LE CADRE DE LA THESE

10

11 LISTE DE FIGURES FIGURE II.1 LES CINQ NIVEAUX DE MATURITE FIGURE II.2 LES TROIS DOMAINES DU PROCESSUS (APRES DOWSON ET FERSTRÖM) FIGURE II.3 LES TROIS DOMAINES DU PROCESSUS LOGICIEL : UNE VISION ELARGIE FIGURE III.1 STRUCTURE DU CMM FIGURE III.2 PHASES COMMUNES A L EVALUATION DU PROCESSUS LOGICIEL ET A L EVALUATION DE LA CAPACITE LOGICIEL FIGURE III.3 LA HIERARCHIE DES ATTRIBUTS LIES A LA QUALITE FIGURE III.4 LA STRUCTURE BASEE ATTRIBUTS DE BOOTSTRAP FIGURE III.5 LES DIMENSIONS PROCESSUS ET PRATIQUES GENERIQUES DU SPICE FIGURE III.6 LES ETAPES DE MISE EN PLACE D'UN SYSTEME D'INDICATEURS A PARTIR DES FACTEURS DE SUCCES ET DE PERFORMANCE DE L'ENTREPRISE FIGURE III.7 LE MODELE DE PROCESSUS ORIENTE AMELIORATION TAME FIGURE III.8 CONCEPTION ARCHITECTURALE DU SYSTEME TAME FIGURE III.9 ARCHITECTURE CONCEPTUELLE DU SYSTEME AMADEUS FIGURE III.10 LE CADRE BALBOA VISION GLOBALE FIGURE III.11 L ARCHITECTURE ET L UTILISATION DE SME FIGURE III.12 ARCHITECTURE DU SYSTEME WEBME FIGURE III.13 L UTILISATIONS DES DEFINITION DES CLASSES ET DES INTERFACES EN WEBME FIGURE III.14 L ARCHITECTURE DE SPADE FIGURE III.15 ARCHITECTURE GENERALE DE L ENVIRONNEMENT PEACE FIGURE III.16 L'ARCHITECTURE D'APEL FIGURE IV.1 UN CONTROLE QUANTITATIF DANS LE DOMAINE DE L EXECUTION FIGURE IV.2 LES DOMAINES SUR LES DEUX NIVEAUX : MONITORING ET PROCESSUS SUJET FIGURE IV.3 SOUS-ENSEMBLE NET ET SOUS-ENSMBLE FLOU FIGURE IV.4 LA CORRESPONDANCE ENTRE L UNIVERS LINGUISTIQUE ET NUMERIQUE POUR LA COMPLETUDE EN UTILISANT DES SIGNIFICATIONS NUMERIQUES ET DESCRIPTION LINGUISTIQUE FLOUES FIGURE IV.5 LES FONCTIONS D APPARTENANCE POUR LES NOMBRES FLOUS [A # B # C], [A # B # B] ET [B # B # C]92 FIGURE IV.6 LES FONCTIONS D APPARTENANCE POUR LES INTERVALLES FLOUS [A # B # C # D], [B # B # C # D] ET [A # B # C # C] FIGURE IV.7 LES FONCTIONS D APPARTENANCE POUR LES INTERVALLES A LIMITES INFINIES FIGURE IV.8 CORRESPONDANCE NUMERIQUE - LINGUISTIQUE POUR LA COMPLETUDE FIGURE IV.9 CONCORDANCE DES INFORMATIONS NUMERIQUES FIGURE V.1 L ESPACE COMPLETUDE-TEMPS ET LES DIFFERENTES ZONES DE RISQUE ASSOCIEES FIGURE V.2 LES FONCTIONS D APPARTENANCE POUR LA CONFIANCE POUR UNE VALEUR DE COMPLETUDE DONNEE FIGURE V.3 CHANGEMENT DES FONCTIONS UTILISEES PAR LE SYSTEME DE MONITORING AVEC AUGMENTATION DE CHARGE DE TRAVAIL SANS AJUSTEMENT DU PLAN FIGURE V.4 LE SCHEMA DES INTERACTIONS CLIENT FOURNISSEUR FIGURE V.5 DEMANDE FIXE ET DEMANDE FLEXIBLE POUR LE DELAIS FIGURE V.6 EXEMPLE DE DEMANDE FLEXIBLE ET LES COURBES DE CONCORDANCE ENGENDREES FIGURE V.7 LE PROCESSUS DE CONCEPTION DE CAPOT POUR LE MODELE SPORT FIGURE V.8 LE MONITORING DU PROCESSUS DE CONCEPTION FIGURE V.9 LES FONCTIONS UTILISEES PAR LE SYSTEME DE MONITORING POUR LE PROCESSUS DE CONCEPTION DU CAPOT

12 FIGURE V.10 LE PROCESSUS DEVIE FIGURE V.11 LE MONITORING ET LE PROCESSUS DEVIE FIGURE V.12 APPEL D OFFRE POUR LA SOUS-TRAITANCE DE LA CONCEPTION DES PHARES DANS LE PROCESSUS DE CONCEPTION DU MODELE SPORT DE VOITURE FIGURE V.13 LE PROCESSUS SUJET, LA RETROACTION ET LA META-RETROACTION FIGURE V.14 LES DOMAINES SUR LES TROIS NIVEAUX : PROCESSUS SUJET, MONITORING ET META-MONITORING 151 FIGURE VI.1 LA CREATION D UN EXECUTABLE DE MONITORING FIGURE VI.2 ARCHITECTURE D OMEGA AVEC INTEGRATION DANS UN CONTEXTE D UTILISATION FIGURE VI.3 DIAGRAMME CONCERNANT LES TYPES D EVENEMENTS FIGURE VI.4 LE PROGRES AU NIVEAU DES ACTIVITES FIGURE VI.5 LE PROGRES AU NIVEAU DU PROCESSUS FIGURE VII.1 PERSPECTIVES DE NOTRE TRAVAIL FIGURE VII.2 L UTILISATION DU MONITORING POUR L ANALYSE DES TRACES FIGURE VII.3 UTILISATION D OMEGA DANS L EVALUATION ET L AMELIORATION DU PROCESSUS FIGURE VII.4 LE MONITORING DES INTERACTIONS

13 LISTE DE TABLEAUX TABLEAU III.1 TACHES ET ETATS CONSIDERES DANS L'EXPERIMENTATION TABLEAU III.2 CARACTERISTIQUES DES SYSTEMES TABLEAU III.3 LES SYSTEMES A TRAVERS LEURS MOTIVATIONS TABLEAU III.4 LES SYSTEMES A TRAVERS DES CRITERES LIES AUX DONNEES ET A LEUR COLLECTION TABLEAU III.5 LES SYSTEMES A TRAVERS LES ANALYSES QU'ILS FOURNISSENT TABLEAU III.6 LES SYSTEMES A TRAVERS LEUR ADAPTABILITE, LEUR FORMALISATION, LEUR INTEGRATION DANS UN EGLCP ET LEUR CARACTERE EVOLUTIF TABLEAU IV.1 LE PROGRES, AGREGATION DE LA COMPLETUDE ET DU MOMENT TABLEAU IV.2 REGLES CONCERNANT LES ACTIONS CORRECTIVES POUR LE PROGRES TABLEAU V.1 UN EXEMPLE DE RELATIONS DE DEPENDANCE TABLEAU V.2 RELATION DE DEPENDANCE AVEC DES VALEURS IMPRECISES ET UNE ACTIVITE DE TERMINAISON 136 TABLEAU VI.1 LE MODELE D EVENEMENT UTILISE EN OMEGA TABLEAU VII.1 OMEGA PAR RAPPORT AUX CRITERES SUR LES SYSTEMES DE MESURE ET D ANALYSE

14

15 Introduction Chapitre I INTRODUCTION I.1 Introduction à la problématique L informatique ne peut pas s appuyer, comme d autres sciences, sur des siècles de recherche, mais elle a le mérite d un développement très rapide et qui a induit un changement très important dans la société actuelle. Les logiciels sont présents partout dans notre vie quotidienne. Ils sont de plus en plus complexes et nombreux, leur production étant de plus en plus assistée et rigoureuse. Le génie logiciel est la discipline qui traite de la production et de la maintenance des logiciels. Il a évolué en même temps que les logiciels, afin de répondre, d une part à des besoins liés à leur complexité, leur qualité et leur fiabilité, et de l autre part à la productivité des entreprises développant des logiciels. Différentes générations d environnements de génie logiciel sont apparues durant ces dernières décennies. Les premiers environnements de génie logiciel ont vu le jour il y a une trentaine d années. Ils n étaient en fait que des «boîtes à outils» supportant uniquement la phase de programmation, sans tenir compte des équipes d utilisateurs. Le terme «programming in the small» était utilisé dans ce cas [Li et Ramanathan 1985]. Les outils n étaient pas ou peu intégrés, le niveau d intégration étant lié à l uniformité des interfaces, communication des données et la complémentarité de leurs fonctions dans le développement du logiciel. Avec la croissance de la taille et de la complexité des logiciels, ce type de développement n était plus adapté. Ainsi, il a été remplacé par «programming in the large», où des équipes et des matériels plus importants sont employés pour la production des logiciels. C est avec cette mouvance que le terme «programmation» est remplacé par «génie logiciel» et «programme» par «logiciel» [Hunke 1981]. Les premiers environnements de génie logiciel intégrés apparaissent dans la même période. Des générations suivantes telles que les générateurs d environnements intégrés de programmation [Borras et al. 1988, Clement et al. 1989] ou des structures d accueil telles que PCTE [Oquendo 1990, PCTE 1993] se sont succédées, jusqu aux Environnements de Génie Logiciels Centrés Processus (EGLCP) [Promoter 1994, Promoter 1999], tels que ALF [Oquendo et al. 1992, Canals et al. 1994], APEL [Estublier et al. 1998a], ItascaFlow [Alloui et Oqunedo 1997, Alloui et Oquendo 1998], OIKOS [Montangero et Ambriola 1994], OPSYS [Avriolinis et al. 1996, Avriolinis et Cunin 1996], PEACE [Arbaoui et Oquendo 1994], ProcessWeb/ProcessWise [Bruynoghe et al. 1991], SCALE [Oquendo 1995], etc. Ces nouveaux environnements mettent en avance le processus de développement de logiciel, qui est reconnu comme un facteur majeur dans la qualité des produits fournis. Toujours liés au processus, des efforts ont été dépensés pour créer des modèles d évaluation des processus logiciels (tels que le Capability Maturity Model [Paulk et al. 1991], le 1

16 Chapitre I Bootstrap [Kuvaja 1994] et SPICE [Rout 1995]) ou encore pour l amélioration des processus logiciels (comme le Quality Improvement Paradigm [Basili et al. 1994a, Basili et al. 1994b]). Ces modèles mettent en valeur l importance du contrôle quantitatif des processus logiciels, qui est exigé dans les hauts niveaux de maturité. La notion de maturité suppose un potentiel de croissance des capacités et constitue un indicateur de qualité du processus logiciel de l entreprise 1 et de la cohérence avec laquelle il est appliqué à l occasion des divers projets menés par celle-ci. Le contrôle quantitatif implique des prises de mesures pour des attributs du processus ainsi que des analyses sur les données collectées. Les modèles proposés sont donnés généralement sous la forme des directives indiquant les bonnes conduites à appliquer. Le manque de support logiciel pour ce type de démarches agit comme un frein dans leur adoption par les sociétés développant des logiciels, car cela implique une surcharge de travail trop importante. Les environnements de génie logiciel centrés processus fournissent des langages pour la définition des modèles des processus ainsi que des mécanismes pour l interprétation de ces modèles. De nombreux langages et environnements ont été proposés, ayant différentes approches [Promoter 1994, Promoter 1999]. Une des caractéristiques communes de ces modèles est leur «exécutabilité», dépendante des mécanismes fournis dans l environnement. Les EGLCP utilisent l exécution de la représentation du processus réel afin d offrir un support à ce dernier. Un problème lié à ce support concerne les incohérences qui peuvent apparaître entre le processus réel et sa représentation dans l environnement. Ces incohérences ont des causes multiples : l incapacité de prévoir toutes les situations possibles à l avance et les intégrer dans les modèles, l inflexibilité des environnements face aux situations inattendues, etc. L apparition des incohérences réduit la pertinence du support offert. Le support offert par ces environnements concerne surtout le modèle du processus qui, d une manière plus ou moins flexible, est imposé au processus réel. Le contrôle quantitatif n est pas présent, les environnements ne fournissent pas d outils pour la mesure et l analyse de processus. Un système de mesure, d analyse et de rétroaction peut à la fois contribuer à la résolution des incohérences et des déviations entre la mise en œuvre des processus réels et le support offert, enrichir un EGLCP avec un système de contrôle et répondre aux besoins de support logiciel liés aux démarches d amélioration. Les travaux proposés dans cette thèse ont pour but de fournir un environnement pour la prise de mesure et l analyse des processus logiciels, avec détection des déviations par rapport à un comportement attendu. Nous appelons cet environnement un environnement de monitoring. Ainsi, par monitoring nous comprendrons une technique de surveillance comprenant des prises de mesures avec détection des déviations par rapport à un comportement attendu. Afin d atteindre ce but, nous avons conçu et réalisé un langage pour la définition des modèles de monitoring ainsi que des mécanismes pour l exécution de ces modèles. I.2 Cadre de la thèse Les travaux de cette thèse ont eu lieu dans le cadre du projet ESPRIT IV LTR PIE (Process Instance Evolution). Les partenaires de ce projet sont l Université Joseph Fourier (Adèle/LSR-IMAG), l Université de Savoie (LLP/CESALP), le Centre de Recherche Européenne de Xerox, Dassault Système (France), The Victoria University of Manchester, Teamware Group Ltd (Royaume Uni), Universitaet Dortmund (Allemagne) et Politecnico di Milano (Italie). 1 Nous utilisons le terme entreprise pour les sociétés ou les organisations développant des logiciels. 2

17 Introduction Le projet aborde le problème de l évolution en-ligne des processus logiciels. L évolution du processus est faite à travers un système de rétroaction, contenant des supports pour le monitoring, la prise de décision, le changement ainsi qu un support pour la stratégie d évolution. Les travaux de cette thèse se placent dans la partie monitoring du système de rétroaction. I.3 Organisation du document Le document est organisé en trois parties. La première partie, contenant les deux chapitres suivant cette introduction, porte sur la problématique abordée dans la thèse et l état de l art. La deuxième partie porte sur notre proposition de solution, l environnement de monitoring OMEGA (On-line Monitoring Environment : General and Adaptable). Elle contient le quatrième chapitre, où le langage de définition du monitoring OMEGA/LDM (OMEGA/Langage de Définition de Monitoring) est défini. La troisième partie contient la validation et l implémentation de notre proposition. Elle contient le cinquième chapitre où le langage OMEGA/LDM est validé en utilisant des études de cas et le sixième qui présente l implémentation de l environnement. La conclusion propose une synthèse et un bilan du travail effectué durant cette thèse et un ensemble de perspectives liées à la continuation du travail, aux nouvelles applications ainsi qu aux nouveaux thèmes de recherche. Trois annexes sont également fournies. Ci-dessous nous donnons une présentation plus détaillée des chapitres : Le deuxième chapitre présente une introduction à notre domaine de recherche, le processus logiciel. Le cadre et la terminologie sont présentés dans ce chapitre. Des aspects liés à la maturité des ces processus logiciels ainsi qu au support existant sont abordés. Les problèmes des déviations qui peuvent apparaître entre le processus logiciel et sa représentation dans l environnement qui le supporte sont identifiés. Le troisième chapitre présente des travaux qui se sont intéressés aux problèmes d évaluation et d amélioration des processus. Des travaux liés à la mesure, à l analyse et à la rétroaction dans les processus sont aussi présentés. Quelques EGLCPs qui abordent le problème des déviations sont exposés en fin de ce chapitre. Dans le quatrième chapitre nous proposons le formalisme OMEGA/LDM, utilisé pour la définition des modèles de monitoring. Le chapitre commence par la présentation de l approche adoptée en OMEGA, l intégration d OMEGA dans un EGLCP ainsi que l outil théorique employé (la logique floue). Le formalisme permet de décrire les informations qui doivent être collectées depuis le processus sujet ainsi que les analyses qui doivent être faites sur ces informations. Il permet également de définir la manière dont le système de monitoring s intègre dans un environnement de génie logiciel centré processus. Plus précisément, il permet de spécifier aussi bien des capteurs pour instrumenter le processus sujet en vue des prises de mesure, que des informations qui doivent être fournies par le système de monitoring à l environnement qui intègre le monitoring. Ce formalisme, avec les mécanismes d exécution fournis par OMEGA, notamment OMEGA/ME (OMEGA/Mécanismes d Exécution), permettent de construire des outils de monitoring spécifiques. La présentation du langage est faite autour des éléments de sa grammaire. Le cinquième chapitre présente des études de cas sur des modèles de monitoring écrits en OMEGA/LDM. Il présente également des exemples d utilisation de ces modèles ainsi que la manière dont ces derniers sont exécutés avec OMEGA/ME. Le niveau méta est 3

18 Chapitre I également abordé dans ce chapitre, la manière dont OMEGA peut être utilisé pour faire du méta-monitoring étant présentée. Cette utilisation offre un support pour le réglage en-ligne du système de monitoring. Le sixième chapitre présente les aspects liés à l architecture et aux implémentations de l environnement OMEGA. Il montre les principes qui sont à la base des ces implémentations, la manière dont les outils de monitoring spécifiques sont obtenus en utilisant le formalisme et les mécanismes d exécution, ainsi que les implémentations réalisées. La conclusion propose une synthèse et un bilan du travail effectué durant cette thèse ainsi que un ensemble de perspectives ouvertes par ce travail. Différentes utilisations d OMEGA sont aussi présenter. L Annexe A présente la grammaire du langage OMEGA/LDM. L Annexe B fournit la modélisation complète en OMEGA/LDM, pour les modèles de monitoring proposés dans la partie validation. L Annexe C présente les publications réalisées dans le cadre de ce travail de thèse. 4

19 Support aux processus logiciel : cadre et terminologie Chapitre II SUPPORT AUX PROCESSUS LOGICIELS : CADRE ET TERMINOLOGIE CHAPITRE II SUPPORT AUX PROCESSUS LOGICIELS : CADRE ET TERMINOLOGIE... 5 II.1 LA MATURITE DES PROCESSUS LOGICIELS... 7 II.1.1 Introduction... 7 II.1.2 Le cadre d évaluation du processus... 8 II Concepts fondamentaux d évolution du processus... 8 II Les niveaux de maturité... 9 II.2 LES PROCESSUS LOGICIEL ET LEURS SUPPORTS II.2.1 Les domaines du processus logiciel II L influence de l exécution sur la mise en œuvre II Le retour d information concernant la mise en œuvre II Interaction entre le domaine d exécution et le domaine de la définition II.2.2 Considérations concernant les interactions entre les différents domaines et le problème de l évolution II Incohérence et déviations II Une vision étendue des domaines du processus logiciel II Quel niveau de maturité?

20 Chapitre II 6

21 Support aux processus logiciel : cadre et terminologie Support aux processus logiciels : cadre et terminologie II.1 La maturité des processus logiciels II.1.1 Introduction De nos jours il est largement accepté que la qualité de n importe quel produit ne puisse pas être assurée en inspectant tout simplement le produit même ou en appliquant des contrôles statistiques de qualité : la qualité n est pas seulement liée au produit, mais à l organisation et au processus de production qui est employé [Derniame et al. 1999]. Cette vision est une des bases pour le paradigme de maîtrise totale de la qualité Total Quality Management (TQM) [Feigenbaum 1991] qui guide les entreprises qui se focalisent sur la qualité. TQM met aussi en avant le fait que la qualité est assurée seulement si toutes les personnes impliquées dans l organisation sont dédiées à leur travail : la qualité représente l excellence dans tous les domaines d une organisation. La manière dont le développement de logiciel est organisé, contrôlé, mesuré, supporté et amélioré (indépendamment du type de support technologique utilisé dans le développement) au sein d une entreprise constitue le processus logiciel de cette dernière. Même si elles exhibent des niveaux différents de sophistication dans la maîtrise de leur processus, toutes les organisations développant du logiciel suivent un processus, qu il soit implicite ou explicite, reproductible, instrumenté, adaptable ou autrement. Cette mouvance autour du processus logiciel est la justification principale de plusieurs initiatives de standardisation, ainsi que des efforts pour la mesure de maturité des processus, comme le Modèle d Evaluation des Capacités Logiciel (en anglais Capability Maturity Model ou CMM) développé par Software Engineering Institute au Carnagie-Mellon University [Paulk et al. 1991] et ses contreparties européennes telles que Bootstrap [Kuvaja 1994] et SPICE [Rout 1995] supportés par European Software Institute, à Bilbao. Ces efforts reflètent une évolution du concept de qualité logiciel vers des environnements centré-processus. Derrière cette évolution se trouve la conviction que l amélioration de la qualité ainsi que la réduction des coûts sont mieux servies en certifiant des processus et en faisant en sorte que ces processus soit suivis. Nous avons choisi le modèle d évolution des capacités logiciel (CMM) pour illustrer notre vue du domaine de génie logiciel, plus précisément du processus logiciel, ainsi que pour positionner nos travaux respectifs dans ce cadre. D autres paradigmes d amélioration seront présentés dans le chapitre dédié à l état de l art. 7

22 Chapitre II II.1.2 Le cadre d évaluation du processus Apres des années durant lesquelles des nouvelles méthodologies et technologies logicielles ont été développées, sans pour autant tenir les promesses quant aux gains de productivité et de qualité, les entreprises et les gouvernements réalisent que leur problème fondamental est leur incapacité à gérer leur processus logiciel. Les avantages des méthodes et des outils améliorés ne peuvent être mis à profit dans un projet chaotique et sans discipline, qui entraînent des retards excessifs et des coûts supérieurs à leur budget. Ces situations sont souvent le fait d un manque d infrastructure et d un soutien insuffisant de la part des organisations. Toutefois même au sein d organisations sans discipline certains projets produisent des bons résultats. Cependant, la réussite dans ce cas est fortement liée à l équipe qui participe au projet, plutôt qu à l application de méthodes éprouvées comme c est le cas dans les organisations utilisant un processus logiciel mature. Nous parlons dans ce contexte des organisations logicielles matures et immatures. Dans une organisation immature les processus logiciel sont généralement improvisés par le personnel et la direction tout au long du projet. La réussite est dépendante de la disponibilité de certaines personnes, et l organisation n établit aucun fondement lui permettant l amélioration généralisée à long terme de la productivité et de la qualité, et non plus de prédire le niveau de qualité des produits. A l inverse, dans une organisation mature nous retrouvons une capacité généralisée de gestion du processus logiciel et de maintenance logiciel. Le processus est communiqué de façon exacte au personnel déjà en place et aux nouveaux employés et les travaux correspondants sont exécutés selon le processus planifié. Les processus mis en place sont opérationnels [Humphrey 1991b] et conformes au déroulement réel des travaux. Ces processus définis sont mis à jour en fonction des besoins. II Concepts fondamentaux d évolution du processus L IEEE définit un processus comme étant une suite d étapes réalisées dans un but donné (en anglais «a sequence of steps performed for a given purpose») [IEEE-STD-610]. Dans le cadre du CMM des définitions sont proposées pour le processus logiciel ainsi que pour d autres concepts liés à l évolution du processus [Paulk et al. 1993], définitions que nous avons adoptées et que nous allons présenter par la suite. Un processus logiciel est vu comme un ensemble d activités, permettant le développement et la maintenance de logiciels et des produits associés (plans de projet, documents de conception, programme, jeux de test et manuels utilisateur, etc.). Par capacité de processus logiciel, nous entendons la gamme des résultats attendus pouvant être obtenus en suivant le processus logiciel. La capacité du processus logiciel d une organisation fournit un moyen de prédire les résultats les plus vraisemblables pouvant être attendus pour le prochain projet logiciel que l organisation entreprendra 2. La performance du processus logiciel désigne les résultats réels obtenus par l application du processus logiciel donné. Par conséquent, la performance du processus logiciel insiste sur les résultats obtenus, tandis que la capacité du processus logiciel s intéresse aux résultats attendus. La performance d un 2 Nous tenons à remarquer que dans le cadre de CMM il est considéré que dans une organisation développant du logiciel il existe un seul processus logiciel, appelé le processus logiciel standard de l'organisation. 8

23 Support aux processus logiciel : cadre et terminologie processus logiciel ne reflète pas toujours la pleine capacité du processus en cause, puisqu un projet peut avoir été affecté par certaines spécifications particulières et par le contexte dans lequel il a dû être réalisé. La maturité du processus logiciel désigne dans quelle mesure un processus est explicitement défini, géré, mesuré, contrôlé et efficace. La notion de maturité suppose un potentiel de croissance des capacités et constitue un indicateur de richesse du processus logiciel de l organisation et de la cohérence avec laquelle il est appliqué à l occasion des divers projets menés par celle-ci. La capacité d un processus logiciel mature est connue. II Les niveaux de maturité Pour que les efforts d amélioration du processus débouchent sur des résultats durables, il est essentiel de suivre un cheminement d évolution qui fait progresser par étapes la maturité du processus logiciel d une organisation, qui passe ainsi de l état immature à l état mature. Dans cette vision, le cadre d évolution du processus logiciel propose cinq étapes ou niveaux de maturité, et organise ces étapes de façon que les améliorations obtenues à une étape donnée permettent d entreprendre les améliorations visées par l étape suivante. La structure à niveaux du CMM repose sur des principes de qualité produit établis depuis soixante ans [Paulk et al. 1993]. En effet, les principes du contrôle statistique de la qualité ont été promulgués dans les années trente par Walter Shewart. Ils ont été ensuite développés et démontrés avec succès dans les travaux de W. Edwards Deming [Deming 1986] et Joseph Juran [Juran 1988, Juran 1989]. Ces principes ont été adaptés par le SEI sous la forme d un cadre d évolution définissant les aspects fondamentaux de gestion de projet et d activités d ingénierie en vue du contrôle quantitatif du processus logiciel, qui constitue les fondements d une amélioration continue de tout processus. Le cadre d évolution dans lequel ces principes de qualité ont été adaptés fut tout d abord inspiré par le livre de Philip Crosby «Quality is Free». La grille d évolution de la gestion de qualité décrit cinq étapes successives d adoption de pratiques dans ce domaine. Ce cadre d évolution a été adapté au processus logiciel par Ron Radice et ses collègues, sous la direction de Watts Humphrey de IBM [Radice et al 1985]. W. Humphrey a présenté ce cadre d évolution au SEI en 1986, y a ajouté le concept de niveaux de maturité et a développé les fondements de son utilisation actuelle dans l industrie du logiciel. En fait, en novembre 1986, le Software Engineering Institute (SEI), en collaboration avec la Mitre Corporation, a entrepris à la demande du gouvernement fédéral le développement d un cadre d évolution des processus logiciel visant à aider les organisations à améliorer leur processus logiciel. En septembre 1987 le SEI publie une description succincte d un cadre d évolution du processus logiciel [Humphrey 1987a] ainsi qu un questionnaire sur la maturité [Humphrey 1997b]. Après quatre ans d utilisation du cadre d évolution du processus logiciel et de la version préliminaire du questionnaire de maturité, le SEI a fait un Modèle d évolution des capacités logiciel 3 (CMM) [Paulk et al. 1991, Weber et al. 1991]. Un niveau de maturité est un palier d évolution bien défini dans le cheminement vers un processus logiciel mature. Chaque niveau comporte l ensemble des objectifs qui, une fois atteints, stabilisent un composant important du processus logiciel. 3 La traduction en français de termes introduit par le CMM a été reprise d une traduction des documents liés au CMM, traduction réalisée par le Centre de génie logiciel appliqué, une division du Centre de recherche informatique de Montréal avec le parrainage du gouvernement de Québec et du gouvernement de Canada. 9

24 Chapitre II La structure sur cinq niveaux du CMM (voir la Figure II.1) établit les priorités des actions d amélioration en vue d accroître la maturité du processus logiciel. Les flèches dans la figure indiquent le type de capacité en cours d institutionnalisation dans l organisation à chaque phase d évolution. Processus en amélioration continue D'optimisation (5) Processus prévisible Maîtrisé (4) Processus standard cohérent Défini (3) Processus structuré Reproductible (2) Niveau initial (1) Figure II.1 Les cinq niveaux de maturité Au niveau initial le processus logiciel est caractérisé par la prédominance d interventions ponctuelles, voire chaotiques. Très peu de processus sont définis et la réussite dépend de l effort individuel. Au niveau reproductible une gestion de projet élémentaire est définie pour assurer le suivi des coûts, des délais et de la fonctionnalité du produit. La discipline nécessaire au processus est en place pour reproduire la réussite des projets d un même domaine d application. Au niveau défini le processus logiciel des activités de gestion et d ingénierie est documenté, normalisé, et intégré dans le processus standard de l organisation. Tout nouveau projet de développement ou de maintenance logiciel fait intervenir une version adaptée et approuvée du processus logiciel standard de l organisation. Au niveau maîtrisé des mesures détaillées sont prises en ce qui concerne le déroulement du processus logiciel et la qualité des produits logiciel. Le processus logiciel et le niveau de qualité des produits sont connus et contrôlés quantitativement. Au niveau d optimisation une amélioration continue du processus logiciel est mise en œuvre par une rétroaction quantitative émanant du processus lui-même et par l application des idées et des technologies innovatrices. 10

25 Support aux processus logiciel : cadre et terminologie A partir du niveau 3 «défini», le processus standard de développement et de maintenance logiciel à travers toute l organisation est documenté, intégrant en un tout cohérent les processus d ingénierie logiciel et de gestion. La suite de ce chapitre traite des organisations arrivant à un niveau de maturité ou le processus est défini ainsi que d une technologie qui s est développée durant ces dernières années autour du processus logiciel. Les caractéristiques ainsi que les limites de cette technologie seront discutées. II.2 Les processus logiciel et leurs supports Les processus établis au niveau 3 sont mis en œuvre (et modifiés au besoin) de façon à rendre plus efficaces les interventions du responsable logiciel et du personnel technique. Un groupe est en charge des activités reliées au processus logiciel de l organisation, le groupe d ingénierie du processus logiciel [Fowler et Rifkin 1990]. Un projet n utilise pas directement le processus logiciel standard de l organisation, mais une adaptation de ce dernier. Le processus logiciel défini du projet 4 est l adaptation du processus standard de l organisation qui prend en compte les caractéristiques spécifiques du projet. Un processus logiciel défini contient un ensemble intégré et cohérent des processus d ingénierie logiciel et de gestion bien définis. Un processus bien défini se reconnaît à la présence de critères de déclenchement, d entrées, de normes et de procédures quant à l exécution des travaux, de mécanismes de vérifications (dont les revues par les pairs), de sorties et de critères d achèvement. Ayant considéré ces caractéristiques du processus bien défini il semble naturel d aller vers la formalisation de ce dernier, démarche permettant d une part d améliorer la compréhension du processus et d autre part de vérifier différentes propriétés. En effet, durant ces dernières années dans le cadre du génie logiciel on a pu observer une orientation significative dans la technologie du processus vers la formalisation du processus de développement de logiciel. Les recherches récentes dans la communauté du génie logiciel ont montré que pour une maîtrise plus grande de la complexité du logiciel, il était nécessaire de formaliser ce dernier afin de pouvoir mieux le comprendre et analyser, le contrôler et l évaluer, assister et guider les développeurs dans leurs activités individuelles et collectives. Une nouvelle technologie a émergé : la technologie du processus logiciel. Les premiers efforts de formalisation des processus ont fourni des modèles de cycle de vie tels que les modèles dits en cascade et en spirale [Boehm 1981, Boehm 1986] ainsi que des méthodes telles que SADT pour l analyse et HOOD pour la conception. Ces modèles abstraits et méthodes ont permis de mettre en évidence l importance de la formalisation du processus logiciel très tôt dans le cycle de vie du logiciel. Cependant la formalisation dans le cas de cycles de vie était insuffisante dans ces «guides méthodologiques», et, la difficulté de la mise en œuvre de ce dernier sans support automatisé et sans assistance fournis par l environnement de génie logiciel aux développeurs, ont conduit à une démarche de formalisation plus poussée du processus logiciel et de son exécution. Ainsi, le but final de cette formalisation poussée, et par ailleurs de la technologie du processus logiciel, est d arriver au point où la définition du processus peut être utilisée pour guider le processus réel de l organisation dans son intégralité. On a vu ainsi l apparition de nouveaux 4 Ceci est une appellation proposée dans CMM 11

26 Chapitre II environnements de génie logiciel qui permettent l intégration des technologies de production et gestion, dans un environnement de travail compréhensif, un Environnement de Génie Logiciel Centré Processus (EGLCP), qui supporte ainsi le processus entier. Dans de tels environnements des formalismes de modélisation sont utilisés pour définir le processus. Un formalisme pour la modélisation de processus logiciel est un langage textuel ou graphique qui permet de décrire des modèles de processus. Une variété de tels langages a vu le jour, chacun ayant des approches différentes quant à la modélisation, mais avec une caractéristique commune: leur «exécutabilité». Dans chaque EGLCP le langage utilisé est exécutable et un mécanisme pour l exécution des modèles est fourni. Deux grandes écoles de modélisation se sont distinguées : la première promouvant une approche prescriptive, connue également sous le nom de «programmation de processus» ayant comme mentor Lee Osterweil [Osterweil 1987] qui considère le processus de développement logiciel comme un programme qu il suffit d exécuter. Un EGLCP représentant cette approche est APPL/A qui a été expérimenté dans le projet Arcadia [Osterweil 1989]. La seconde promouvant une approche proscriptive, connue également sous le nom de «modélisation de processus», a comme mentor Manny Lehman et considère que le processus de développement logiciel n est pas un programme mais il faut le modéliser avec tous ses «ingrédients» et tenir compte des facteurs humains [Lehman 1987]. Cette deuxième école a rapidement pris le pas sur la première, notamment parce qu elle adhère mieux à la réalité de développement de logiciel tel qu il est pratiqué de nos jours. Différents aspects sont impliqués lorsque la définition du processus est utilisée pour supporter le processus réel, indépendamment du langage de modélisation utilisé. Par la suite nous allons discuter ces aspects en identifiant les besoins généraux qu un EGLCP doit remplir quant au mécanisme d exécution. II.2.1 Les domaines du processus logiciel Un certain nombre d EGLCP ont vu le jour, utilisant des langages de modélisation différents. Ayant le même but, à savoir supporter le processus logiciel, ils exhibent des caractéristiques communes. Un travail de conceptualisation a été entrepris pour identifier d une part les concepts génériques liés aux EGLCPs, et d autre part les besoins liés aux mécanismes d exécution de ces environnements. Un des efforts les plus connus dans cette direction est celui de Dowson et Fernstöm qui propose en 1994 [Dowson et Fernström 1994] la structuration du processus logiciel en trois domaines (voir Figure II.2) : le domaine de définition de modèles de processus 5, le domaine d exécution de modèles de processus 6 et le domaine de la mise en œuvre du processus 7. Cette distinction permet de mieux comprendre le processus logiciel en général ainsi que les besoins liés au EGLCP, car comme nous allons le montrer la concordance entre les trois domaines n est pas toujours au rendez-vous. Le domaine de la définition contient des descriptions de processus ou fragments de processus exprimés dans une certaine notation et exprimant ce qui pourrait ou bien devrait être mise en œuvre. Une telle description du processus est appelée modèle du processus. 5 La désignation anglophone utilisée est «Process Definition Domain» 6 La désignation anglophone utilisée est «Process Enactment Domain» 7 La désignation anglophone utilisée est «Process Performance Domain» 12

27 Support aux processus logiciel : cadre et terminologie Domaine de définition définitions et fragments de définition Domaine de mise en œuvre mise en œuvre du processus Créations des modèles exécutables assistance et support pour la mise en œuvre Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution exécution des définitions Retour d information concernant la mise en œuvre Domaine d exécution Figure II.2 Les trois domaines du processus (après Dowson et Ferström) Dans le cas des EGLCPs cette notation est «exécutable», c est-à-dire elle peut être interprétée par un mécanisme d exécution. Le domaine de la mise en œuvre englobe les activités effectives ainsi que les actions prise en charge par tous les participants, concernant aussi bien les activités de développement que celles de gestion. Une partie de ces activités seront conduites utilisant des outils logiciel, d autres seront complètement en dehors du support, comme par exemple des interactions entre les participants au processus. Le domaine d exécution est concerné avec ce qui se passe dans un EGLCP pour supporter le processus mis en œuvre, admettant que ce dernier est gouverné par la définition qui a été donnée ; il interprète le modèle du processus à partir d une représentation exécutable et englobe les mécanismes et les ressources nécessaires de l environnement pour supporter les domaines de définition et de mise en œuvre. Le mécanisme d exécution utilise les définitions afin de déterminer ses interactions avec les agents impliqués dans la mise en œuvre ainsi qu avec d autres composants de l environnement, le but final étant d assurer l aide, le guidage ou bien le contrôle de la mise en œuvre en vue d assurer sa consistance avec la définition qui lui a été donnée. En d autres termes, tandis que le processus est mis en œuvre dans le monde réel (domaine de la mise en œuvre), il est exécuté par la machine dans le monde abstrait du modèle de processus (domaine de l exécution). Avant de discuter les interactions existantes entre ces trois domaines, nous allons présenter les différents rôles que les acteurs humains peuvent avoir dans le processus logiciel, ainsi que le positionnement de ces rôles par rapport aux trois domaines [Arbaoui et al. 1999]. Trois classes d acteurs peuvent être identifiées : le concepteur du processus 8, le manager du processus 9 et l agent du processus La notation anglophone est «process designer» 13

28 Chapitre II Le concepteur du processus agit dans le domaine de la définition ; il est responsable de fournir des modèles génériques ainsi que de gérer leur évolution. Dans le monde réel plusieurs personnes peuvent remplir ce rôle : le créateur d une méthodologie, le stratège technique, etc. Le manager du processus agit dans le domaine de définition ainsi que dans le domaine d exécution ; il adapte les modèles génériques aux projets spécifiques et les instancie. Dans le cadre d une organisation ce rôle peut être rempli par un chef de projet travaillant avec le directeur technique de l organisation. L agent du processus agit dans le domaine de la mise en œuvre, et peut être le chef de projet, un programmeur, un analyste de système, testeur, auditeur de qualité, etc. L exécution du modèle de processus peut se produire d une manière indépendante de la mise en œuvre d un processus réel, afin de fournir à travers des simulations des informations analytiques concernant la définition du processus, permettant l amélioration de cette dernière ou bien prédire des aspects concernant une mise en œuvre qui restera conforme à la définition. Cependant, pour que l exécution d un modèle de processus assure un support pertinent à la mise en œuvre, certains couplages et interactions doivent exister entre les deux domaines. Les interactions se font dans les deux directions, comme nous allons le présenter par la suite. II L influence de l exécution sur la mise en œuvre L exécution du processus est censée influencer la mise en œuvre du processus, car tel est son but, mais le degré de cette influence peut varier à partir de la simple assistance, jusqu à l automatisation de certaines tâches. Quatre manières d influencer la mise en œuvre ont été identifiées [Dowson et Fernström 1994] : l assistance passive, l assistance active, l imposition et l automatisation. L assistance passive fournie aux utilisateurs, sur demande, des informations qui peuvent les aider à décider quelles activités ils devraient entreprendre afin d être conformes à la définition. L assistance est d autant plus pertinente quand le retour d information depuis le domaine de la mise en œuvre est assuré. Cependant une assistance limitée peut être fournie même dans l absence du retour, sous la forme de politiques de conduite ou bien en fournissant la définition du processus en cause. L assistance active est dépendante du retour d information depuis le domaine de la mise en œuvre afin de fournir des informations pertinentes concernant l état courant du processus. Ce type d assistance est fourni sur l initiative du mécanisme d exécution dans les circonstances spécifiées dans la définition du processus. L imposition du processus consiste à forcer l utilisateur à mettre en œuvre le processus ou bien une partie de ce dernier d une manière imposée, conforme à la définition du processus. Une manière d imposer le processus est de contrôler l accès de l utilisateur à différentes données et outils. L automatisation du processus consiste à exécuter une partie du processus sous le contrôle du mécanisme d exécution, sans intervention de l utilisateur. L automatisation du processus est considérée adéquate pour des parties du processus qui consistent à des séquences stéréotype relativement complexes qui peuvent être accomplis par des agents non - humains (des outils logiciels) avec peu ou pas d intervention de la part de l utilisateur. 9 La notation anglophone est «process manager» 10 La notation anglophone est «process agent» 14

29 Support aux processus logiciel : cadre et terminologie Les limites entre ces types d influences ne sont pas définies d une manière irrévocable, certaines interactions pourront être vues de plusieurs façons. L invocation des outils par l environnement et pour l utilisateur peut être vue comme assistance active (si l utilisateur peut renoncer à l utilisation de l outil), imposition ou bien automatisation du processus (si peu ou pas d interaction est nécessaire). Ces types d interactions ont chacun, comme l on vient de voir, leurs caractéristiques mais aussi leur points faibles, et l acceptation du support par les participants à la mise en œuvre en dépend beaucoup. D une part les différentes formes d assistance ne pourront pas assurer la conformité de la mise en œuvre avec la définition. D autre part, l imposition et l automatisation peuvent engendrer des réactions négatives. En effet, il est considéré que le type d interaction ne devrait pas être une propriété fixe du EGLCP, une approche combinée en fonction des aspects sera préférable (assistance pour certains pas du processus, imposition pour d autres) [Arbaoui et al. 1998, Bandinelli et al. 1995]. La dimension humaine du processus logiciel a été étudiée [Arbaoui et al. 1999] et deux types de réactions face aux approches prescriptives (l imposition, voir automatisation) des processus ont été identifiés. La plus évidente réaction des humains face à des EGLCP «autoritaires» est le rejet, pour au moins deux raisons : le premier est politique (attaque à l autonomie) et le deuxième, plus subtil, est lié au fait que même la routine implique des problèmes ouverts et tout ne peut être prévu à l avance. Ainsi, les systèmes prescriptifs courent le risque de l obstruction à l inventivité, que des études ont montrer comme étant la clé du travail efficace. La rébellion est une réaction adverse dirigée contre le EGLCP. Sa contrepartie, la soumission est aussi possible. Dans tel cas les acteurs de la mise en ouvre (les agents de processus) cessent de penser, travaillant tout simplement en «suivant les règles». Le danger de ce deuxième type de réaction est aussi évident, car les possibilités d amélioration du processus sont fortement réduites. II Le retour d information concernant la mise en œuvre L exécution des modèles de processus sans avoir de retour d information ne servira, comme il a été montré, que pour des buts de simulation. Le problème essentiel lié au retour d information consiste à maintenir la cohérence entre la mise en œuvre et l exécution du modèle, autrement dit, maintenir la cohérence entre le monde réel et le monde abstrait afin de pouvoir donner un support pertinent. Le retour d information peut être obtenu à partir de différentes sources et en différentes manières. Si l on considère le cas où le mécanisme d exécution attend un retour concernant la fin d une tâche T 1 (la création d une nouvelle version du module M 1 ), le mécanisme ayant, à travers le modèle qu il exécute, la connaissance qu après la tâche T 1, la tâche T 2 doit être exécutée, voici différentes sources possibles pour ce retour [Dowson et Fernström 1994] : une action explicite de l utilisateur (par exemple en appuyant le bouton «Fin»), le résultat d une requête d information envers l utilisateur («la tâche T 1 est-elle finie?»), un événement généré par un outil (si par exemple la tâche T 1 est une compilation, cet événement pourrait être généré par le compilateur), l interrogation d une base de données passive («existait-il une nouvelle version de M 1?») ou bien la génération d un événement par une base de données active («une nouvelle version de M 1 a été enregistrée»). La génération automatique du retour ne peut pas être créée tout le temps. Comme il a été mentionné, les activités intervenant dans la mise en œuvre peuvent être accomplies avec ou sans le support de l environnement, certaines activités se déroulant totalement en dehors du support automatique. Dans de tels cas le retour d information ne peut passer que par l intervention des agents de processus, la coopération de ces derniers étant très importante. Il peut arriver que les agents trouvent des moyens plus efficaces pour conduire leur travail, ce 15

30 Chapitre II qui peut générer l incohérence entre la mise en œuvre et le domaine d exécution, l incohérence étant vue comme la perte de corrélation [Dowson et Fernström 1994]. Deux types de retour ont été identifiés [Arbaoui et al. 1999]. Le retour de premier niveau consiste à fournir des informations concernant l'état d'avancement de la mise en œuvre, depuis le domaine de la mise en œuvre vers le domaine d exécution. Un exemple d'un tel retour est le fait qu'une tâche soit finie. Le retour de deuxième niveau fait référence à des changements locaux qui ont été faits au processus dans sa mise en œuvre en réponse à des exigences pratiques. Ce dernier type de retour indique que le modèle de processus en exécution a besoin de changements (si on veut avoir la cohérence), étant aussi possible que ces changements doivent être propagés au niveau du domaine de la définition, car le retour peut suggérer des faiblesses au niveau du modèle de processus. Nous allons revenir sur ce problème dans les sections suivantes. II Interaction entre le domaine d exécution et le domaine de la définition L interaction entre le domaine de l exécution et le domaine de la définition se fait dans les deux directions. Partant du domaine de définition vers le domaine d exécution, le modèle de processus doit être mis en contexte pour l utilisation dans le cadre d un certain projet. Revenant au CMM, dans le domaine de définition on retrouve le processus logiciel standard de l organisation, et le passage vers le domaine de l exécution se fait en construisant le processus logiciel défini du projet. Un des avantages potentiel de la définition des processus consiste dans le fait qu elle capture des informations génériques concernant la manière dont les éléments d une famille des processus devraient être mis en œuvre. Ceci permet la rentabilisation de l effort dépensé dans la construction du modèle, à travers ses utilisations répétées dans différents projets. Une partie de la spécialisation du modèle de processus se fait dans le domaine de définition, avant qu une exécution du modèle soit créée, à travers des variables de processus [Dowson et Fernström 1994]. 16 Les variables de processus représentent les aspects génériques dans la définition du processus, donnant lieu à la possibilité de changements statiques ou bien dynamiques de la définition. L instanciation du processus consiste à assigner aux variables de processus des valeurs caractéristiques au projet pour lequel le processus est instancié ; elle fourni le processus instancié, qui est une représentation exécutable du modèle de processus. Ainsi, le processus de l organisation, qui est donnée dans les EGLCP sous la forme de modèle de processus subit une première mise en contexte afin d obtenir le processus défini du projet, (des contraintes spécifiques au projet sont rajoutées), et une deuxième en assignant des valeurs aux variables du processus afin d obtenir le processus instancié. Nous allons par la suite considérer ces deux mises en contexte comme une seule, que l on va appeler instanciation du processus. Cependant, une partie de la mise en contexte va se faire dans le domaine d exécution du modèle de processus, en réponse au retour d information concernant la mise en œuvre du processus. Nous faisons référence ici au retour de deuxième niveau, qui indique des changements locaux ayant était faits au processus dans sa mise en œuvre. Un EGLCP suffisamment flexible devrait permettre de telles évolutions. Un retour impliquant un besoin

31 Support aux processus logiciel : cadre et terminologie de changement est dû normalement au fait que la mise en œuvre n est plus cohérente avec la définition et l exécution du processus. Pour qu un tel retour d information soit possible, fautil encore que l EGLCP le permette. Nous allons par la suite faire une synthèse concernant les besoins liés au mécanisme d'exécution d'un EGLCP et proposer une vision plus détaillée des trois domaines et leurs interactions. Le problème de l incohérence ainsi que celui de la déviation entre les domaines seront aussi abordés. II.2.2 Considérations concernant les interactions entre les différents domaines et le problème de l évolution Dans les sections précédentes plusieures caractéristiques souhaitables d'un EGLCP ont été identifiées. Celle qui revient sous plusieurs aspects est celle de la flexibilité au niveau du mécanisme d'exécution, liée au problème de la cohérence entre les trois niveaux. Un certain niveau de cohérence est nécessaire afin de ne pas perdre la pertinence du support offert. II Incohérence et déviations Des efforts dirigés vers l étude du problème de l incohérence entre les différents domaines du processus logiciel ont été faits à Politecnico di Milano, un cadre conceptuel permettant de mieux comprendre ce problème étant proposé [Cugola et al. 1996, Cugola 1998]. Le problème de la déviation est lié au problème de l incohérence, une déviation étant considérée comme une action qui entraîne une incohérence. Deux types d incohérences ont été identifiés, et par conséquent deux type de déviations : au niveau du domaine et au niveau de l environnement. Une incohérences niveau-domaine se produit quand le processus mis en œuvre ne suit pas le modèle. Une incohérences niveau-environnement se produit quand le processus en exécution ne représente plus le processus mis en œuvre. Il se peut aussi que les deux types d incohérence se manifeste à la fois. Une déviation niveau-domaine est une action qui cause l apparition d une incohérence niveau-domaine. De telles déviations se produisent quand les agents du processus violent les contraintes spécifiées par le modèle de processus afin de faire face à une situation inattendue. Une déviation niveau-environnement apparaît quand un agent du processus effectue une action ne relevant pas du contrôle du EGLCP. Autrement dit, lorsque le support de processus n a pas connaissance des choses qui pourraient changer le support offert, le retour d information du premier niveau ne fonctionne pas correctement. Un EGLCP est dit cohérent [Cugola et al. 1996] s il est capable de capturer (angl. «track») toutes les actions d utilisateur significatives pour processus. Quand cette propriété est présente les chances d apparitions de déviations niveau-environnement sont faibles. Dans un monde idéal le processus mis en œuvre est toujours cohérent avec le modèle de processus, et le processus exécuté reflète souvent le processus mis en œuvre. Les déviations n apparaissent jamais. Malheureusement, ce n est pas toujours le cas. Comme il a été montré dans les sections précédentes des situations inattendues peuvent apparaître. Quand une 17

32 Chapitre II situation inattendue apparaît, le EGLCP peut répondre de trois manières différentes [Cugola 1998]. Première réponse. Le modèle de processus n est pas modifié et les actions nécessaires pour faire face à cette situation inattendue sont faites en dehors du contrôle du EGLCP. Le processus exécuté est toujours cohérent avec le modèle de processus (en fait, le EGLCP n est pas conscient qu une déviation est apparue), cependant il n est plus cohérent avec le processus mis en œuvre. En conséquence, le EGLCP ne peut pas analyser la déviation et ne peut pas supporter l utilisateur afin de réconcilier la mise en œuvre avec son modèle. Deuxième réponse. Avant toute action le modèle de processus est modifié. Une description des actions à mettre en place afin de faire face à la situation inattendue est ajoutée au modèle et dans le nouveau modèle de processus. Le résultat de cette approche est que le processus exécuté continue à être une description fidèle du processus mis en œuvre qui reste cohérente avec son modèle. Troisième réponse. Le modèle de processus n est pas modifié, mais le mécanisme d exécution offre la possibilité de déviation explicite, en exécutant les actions nécessaires à la réconciliation sous son contrôle. Comme dans le cas précédent une déviation niveau-domaine est apparue mais ici l exécution du processus continue à être une image fidèle du processus mis en œuvre. Dans ce cas le EGLCP est conscient du fait qu une déviation est apparue et peut l analyser et fournir un support pour sa réconciliation. Le EGLCP «tolère» la déviation. Même si la deuxième réponse semble être la plus sure et la plus propre, elle n'est souvent pas pratique, surtout dans le cas de déviations qui ne sont pas trop importantes, et qui ne risquent pas de se reproduire dans le futur. Le mécanisme d exécution du EGLCP SPADE [Bandinelli et al. 1993] implante un tel type de réponse, permettant le changement du modèle pendant l exécution. Cette approche c est montré intéressante dans le cas des déviations importantes qui ont une forte vraisemblance de se reproduire dans le futur. La flexibilité requise dans la pratique peut plus facilement être acquise en adoptant la troisième réponse. Malheureusement la plupart des EGLCP disponibles ne supportent pas cette approche. Le prototype de SENTINEL [Cugola et al. 1995] représente une des exceptions. Plus récemment le EGLCP PROSYT (PROcess Support system capable of Tolerating deviations) a été proposé [Cugola 1998]. Il suit les principes de SENTINEL, tout en étant plus performant. Un exemple d amélioration est la possibilité de changement dynamique des politiques de réconciliation. Des améliorations ont aussi été adoptées par rapport aux choix architecturaux. Un autre projet qui aborde le problème du besoin des déviations est le projet PEACE [Arbaoui et al. 1992] qui adopte une approche très flexible dans la modélisation et l exécution des processus, ce qui réduit les besoins de déviations. Une autre solution possible, adoptée souvent par des systèmes de management de workflow est de traiter les situations inattendues comme des exceptions et fournir un mécanisme pour gérer les exceptions [Eder et Liebhart 1995, Alonso et Mohan 1997, Saastamoinen et Savolainen 1992]. Malheureusement, cette solution n est pas suffisamment générale. Elle permet seulement de faire face à un nombre limité de situations, capturées par le mécanisme qui gère les exceptions. Ces situations sont fournies comme parties du modèle. Ceci explique pourquoi elles sont appelées exceptions attendues [Eder et Liebhart 1995]. Nous allons par la suite présenter une vision sur la façon avec laquelle la flexibilité pourrait être acquise, en reprenant la vision des trois domaines du processus logiciel. 18

33 Support aux processus logiciel : cadre et terminologie II Une vision étendue des domaines du processus logiciel Revenant aux trois domaines du processus logiciel, nous rappelons que l exécution des définitions par le mécanisme d exécution n est pas complètement déterministe. Comme il a été montré, le retour d information du domaine de la mise en œuvre vers le domaine d exécution influence la manière dont les définitions sont exécutées. L ensemble d exécutions conformes au processus défini du projet, contient toutes les exécutions conformes qui peuvent être générées et exécutées par le mécanisme d exécution à partir du processus instancié. Dans un système prescriptif la mise en œuvre doit être conforme, et s identifier à une de ces exécutions conformes. Afin de pouvoir prendre l approche de la flexibilité quant aux situations inattendues (correspondant à la troisième réponse identifiée dans la section précédente) une solution possible est de garder au niveau du domaine d exécution une représentation fidèle de la mise en œuvre ainsi que l exécution du modèle la plus proche de cette mise en œuvre, exécution faisant partie de l ensemble d exécution conformes (voir Figure II.3). Domaine de définition Domaine de mise en œuvre définitions et fragments de définition Retour d information concernant l exécution des définitions Processus défini du projet Concordance? assistance et support pour la mise en œuvre mise en œuvre du processus Retour d information concernant la mise en œuvre une exécution conforme la plus proche de la mise en œuvre Processus mis en œuvre Ce qui devrait se passer Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution Domaine d exécution Ce qui se passe réellement Figure II.3 Les trois domaines du processus logiciel : une vision élargie La concordance entre la mise en œuvre et l exécution conforme au processus défini du projet la plus proche peut être calculée par le EGLCP d une manière automatisée. Cette concordance peut être calculée pour différents aspects du processus. Ayant les deux représentations abstraites, celle de la mise en œuvre et celle de l exécution conforme la plus proche, ainsi que la mesure de leur concordance, le EGLCP pourrait permettre la déviation de la première par rapport à la deuxième, sans pour autant perdre le contrôle de cette déviation. Au moment où la déviation est considérée inacceptable, et en tenant compte de la nature de cette déviation, des actions correctives seront apportées à la mise en œuvre ou bien le processus défini du projet sera dynamiquement adapté. Quand le processus défini du projet est changé, l ensemble des 19

34 Chapitre II exécutions conformes change, et implicitement l exécution conforme la plus proche, de manière à ce que la déviation soit à nouveau dans des limites considérées acceptables. L environnement «tolère» ainsi les déviations acceptables. La nouvelle manière d organiser le domaine d exécution offre aussi l avantage que le retour de deuxième niveau depuis le domaine de la mise en œuvre vers le domaine d exécution est automatisé (au moins partiellement), dû au fait que la déviation est possible et qu une image fidèle 11 de la mise en œuvre se trouve au niveau du domaine d exécution. Cependant, nous constatons que le degré d acceptabilité d une déviation n est pas constant. Il change en fonction de la caractéristique pour laquelle la déviation est calculée, telle que le coût, l enchaînement des activités, etc. Ainsi, elle ne constitue pas une caractéristique intrinsèque du mécanisme d exécution. L acceptabilité est plutôt liée au projet dans lequel le modèle de processus est utilisé, et elle peut changer dynamiquement pendant l exécution du processus. Ainsi, le niveau «d acceptabilité» d une déviation devrait être définie dynamiquement. Ceci est en accord avec le fait que la manière dont le domaine d exécution influence le domaine de la mise en œuvre (la paradigme du mécanisme d exécution) ne peut pas constituer une politique commune pour le processus entier [Dowson et Fernström 1994], car même si certains aspects nécessitent l imposition (cf. section II par exemple la gestion de configuration), d autres n ont pas besoin de paradigmes aussi restrictifs. En utilisant un degré d acceptabilité de déviation nul, nous retrouvons l imposition du modèle pour la mise en œuvre du processus. Dans ce cas l image de la mise en œuvre doit s identifier à une des exécutions conformes au processus défini du projet. Revenant aux motivations qui ont abouti à la naissance de la technologie de processus logiciel et des EGLCP nous remarquons que l une des plus importantes était celle d'offrir un support en vue de l'amélioration du processus. L'existence d'un support technologique donne lieu à des améliorations fondées sur le retour d'information concernant la mise en œuvre (on fait ici référence au retour d'information de deuxième niveau) et assure que l'amélioration apportée au modèle peut par la suite être appliquée à un grand nombre de futurs projets. L imposition d une politique stricte rend l amélioration difficile. Nous allons par la suite positionner les efforts faits dans la communauté processus logiciel quant au CMM, ainsi qu une vision pour l amélioration de ce positionnement. II Quel niveau de maturité? Quant à positionner les efforts faits par la communauté de processus logiciel par rapport aux niveaux de maturité fourni dans CMM, nous remarquons que ces efforts se placent surtout au Niveau 3 de maturité. D ailleurs, un des défis que comporte le Niveau 3 est la création des processus qui responsabiliseront chaque intervenant, sans leur imposer un cadre d'exécution trop rigide [Humphrey 1991b], ce qui confirme le choix pour un cadre flexible d exécution. Les EGLCPs offrent le support pour la modélisation du processus constituant ainsi un support pour le Niveau 3 de maturité. Nous retrouvons d'ailleurs dans les EGLCP, comme il a été montré, le processus logiciel standard sous la forme du modèle de processus ainsi que les processus définis des projets sous la forme des instanciations du processus. Nous allons par la suite regarder les caractéristiques du Niveau 4 «maîtrisé» tel que proposé dans la version 1.1 du CMM [Paulk et al. 1993] afin d analyser la manière dont les EGLCP fournissent ou pourront fournir un support. 11 Quant à la fidélité de cette image elle est toujours dépendante en partie des agents de processus et de leur niveau de coopération. 20

35 Support aux processus logiciel : cadre et terminologie Au niveau «maîtrisé» l organisation se fixe des objectifs quantitatifs de qualité à la fois pour les produits et les processus logiciels. La productivité et la qualité sont mesurées pour les tâches importantes de tous les projets dans le cadre d un programme organisationnel de mesure. Une base de données du processus logiciel de l organisation est utilisée pour recueillir et analyser les données disponibles des processus logiciels définis qui sont mis en œuvre dans le cadre de chaque projet. Au cour d un projet, les produits et les processus sont contrôlés par diminutions de variations de processus de façon à ce que ces variations ne dépassent pas des limites quantitatives admissibles. La capacité des processus au niveau 4 peut être définie comme étant prévisible, parce que le processus est mesuré et opère dans des limites mesurables. Ce niveau de capacité de processus permet à l organisation de prévoir les tendances en termes de qualité des processus et des produits à partir des limites quantitatives établies. Lorsque ces limites sont dépassées, une action est entreprise afin de corriger la situation. Les produits logiciel sont de la haute qualité attendue. L organisation des domaines que nous venons de proposer, permet au EGLCP d offrir un support renforcé afin d arriver au niveau quatre de maturité proposé par CMM. Un système de mesure et d analyse portant sur la mise en œuvre du processus peut être mis en place plus facilement grâce à l existence dans le domaine d exécution d une représentation fidèle, bien que partielle, de la mise en œuvre. Des mesures de concordance entre la mise en œuvre et l exécution conforme la plus proche pourraient être faites, permettant de garder le processus sous contrôle. Ceci pourrait être réalisé en englobant au niveau du domaine d exécution une partie contrôle, représentée par une boucle de rétroaction. La boucle de rétroaction est utilisée afin de contrôler et faire évoluer le processus. Elle fournit trois fonctionnalités principales : l observation du processus avec détection des besoins de changement, décision concernant les changements à apporter et implantation des changements dans le processus. La partie contrôle et évolution peut être indépendante du mécanisme même d exécution du processus. Son rôle est dans un premier temps de regarder, à l aide d un système de monitoring, à la fois ce qui se passe (la représentation de la mise en œuvre) et ce qui devrait se passer (l exécution conforme au modèle, la plus proche par rapport à la mise en œuvre). Des analyses concernant le niveau de concordance entre la mise en œuvre et le modèle peuvent se faire de cette manière. Nous remarquons que cette concordance est calculée en supposant l inexistence d une déviation niveau-environnement, c est-à-dire il est considéré que la représentation de la mise en œuvre au niveau du domaine d exécution est fidèle à la mise en œuvre réelle du processus. Si le niveau de concordance (calculé au niveau du monitoring) dépasse le seuil d acceptabilité, un support à la décision est fourni afin de réconcilier les deux processus. Les actions concernant la réconciliation sont implantées au niveaux des processus à l aide d un support au changement. Un des avantages de l adoption de la boucle de rétroaction repose dans la possibilité d automatiser une partie des mesures. Cependant, une partie des mesures ne peut pas être faite d une manière automatique et nécessite l intervention agents de processus. D autres mesures nécessaires pour la maîtrise du processus (support au Niveau 4 de maturité) peuvent être plus facilement intégrées si le système de monitoring est suffisamment flexible. 21

36 Chapitre II 22

37 L état de l art Chapitre III L ETAT DE L ART CHAPITRE III L ETAT DE L ART III.1 L EVALUATION DU PROCESSUS III.1.1 CMM III.1.2 Bootstrap III.1.3 SPICE III.1.4 Bilan sur les modèles d évaluation du processus III.2 L AMELIORATION DU PROCESSUS III.2.1 QIP III.2.2 Personal Software Process III.2.3 Amélioration des processus manufacturiers III.2.4 Bilan sur les modèles d amélioration du processus III.3 LES SYSTEMES DE MESURE ET D ANALYSE III.3.1 Critères de l étude III Critères liés aux données et mesures III Critères liés aux analyses III Critères liés aux caractéristiques du système III.3.2 Tame III.3.3 Amadeus III.3.4 Hakoniwa III.3.5 BALBOA III.3.6 Méthode pour l analyse des données historiques III.3.7 Expérimentation de prototypage du monitoring III.3.8 Software Management Environment III.3.9 WebME III.3.10 Tempo III.3.11 Caractéristiques des systèmes tableau récapitulatif III.3.12 Bilan sur les systèmes étudiés III.4 LES EGLCP ET LE PROBLEME DE L INCOHERENCE III.4.1 SPADE III.4.2 SENTINEL III.4.3 PEACE III.4.4 APEL III.4.5 Bilan III.5 CONCLUSION

38 Chapitre III 24

39 L état de l art L état de l art Le génie logiciel et l amélioration du processus retiennent de plus en plus l attention. Ceci est dû au fait qu ils fournissent des méthodes qui permettent de transférer de bonnes pratiques vers l industrie. Les entreprises utilisent ces méthodes pour s assurer que les cibles de qualité qui leur sont associées ont été atteintes et que le produit logiciel fourni aura la qualité souhaitée. Ce chapitre présente des travaux effectués dans quatre domaines : Définition des méthodes d évaluation : elles fournissent des directives afin d évaluer la maturité d un processus employé dans une entreprise. Définition des méthodes pour supporter l amélioration : elles fournissent des directives afin d améliorer un processus existant. Systèmes pour la mesure, l analyse et la rétroaction. Systèmes qui proposent des mécanismes pour la prise en compte des situations inattendues. Le contexte dans lequel nous nous plaçons est celui du processus logiciel et de son support. Comme il a été souligné dans le chapitre précédent, des incohérences entre le support et le processus supporté peuvent apparaître. Ceci est dû en partie aux situations inattendues avec lesquelles les agents de processus se confrontent. Afin d éviter de telles incohérences ou bien de les garder sous contrôle, le support de processus doit prendre en compte ces aspects. III.1 L évaluation du processus Dans la section précédente nous avons présenté des éléments d un modèle d évaluation du processus des plus connus : le Capability Maturity Model (CMM) [Humphrey 1987a, Humphrey 1987b, Paulk et al. 1991], développé par Software Engineering Institute (SEI) aux Etats-Unis. Nous positionnons notre problématique par rapport à ce modèle, et complétons cette présentation avec des éléments liés aux aspects opérationnels du modèle. D autres modèles d évaluation ont été proposés en Europe, notamment Bootstrap [Kuvaja 1994] et SPICE [Rout 1995]. Ces modèles seront aussi présentés dans cette section. III.1.1 CMM Les motivations de ce modèle ainsi que sa structuration sur cinq niveaux de maturité ont été présentées dans le chapitre précédent. Nous allons dans cette section présenter l aspect opérationnel de ce modèle ainsi que la manière dont il peut être utilisé. 25

40 Chapitre III Définition opérationnelle du CMM Chaque niveau de maturité est décomposé en un certain nombre de parties. A l exception du Niveau 1, chaque niveau de maturité se décompose de façon à présenter en premier lieu un résumé succinct de son contenu et à progresser ensuite jusqu à une définition opérationnelle sous la forme de pratiques clés (voir la Figure III.1). Chaque niveau comporte plusieurs secteurs clés 12. Chacun de ces secteurs comprend cinq parties appelées «caractéristiques communes» 13. Les caractéristiques communes indiquent les pratiques clés 14 qui, traitées collectivement, permettent d atteindre les objectifs du secteur clé. Niveaux de maturité Indiquent Contiennent Capacité du processus Secteurs clés Réalisent Structurés par Objectifs Portent sur Caractéristiques communes Contiennent Mise en oeuvre ou institutionnalisation Pratiques clés Décrivent Infrastructure ou activités Figure III.4 Structure du CMM Les secteurs clés décrivent les points particuliers sur lesquels une entreprise doit se concentrer afin d améliorer son processus logiciel. Ils identifient les questions devant être abordées pour atteindre un niveau de maturité donné. Ainsi, chaque secteur clé correspond à un ensemble d activités associées dont l accomplissement collectif mène à un ensemble d objectifs considérés comme importants pour l amélioration de la capacité logiciel. Ces objectifs synthétisent les pratiques clés d un secteur clé et définissent la portée, les limites et l intention de chaque secteur clé. Les secteurs clés sont définis à l intérieur d un seul et unique niveau de maturité. Lorsque les objectifs 12 La terminologie anglophone est «Key Process Area» 13 La terminologie anglophone est «Common Features» 14 La terminologie anglophone est «Key Practices» 26

41 L état de l art d un secteur clé sont systématiquement atteints d un projet à l autre, l entreprise peut considérer avoir institutionnaliser les capacités du processus décrites par le secteur clé. Nous ne présenterons pas les secteurs clé associés à chaque niveau de maturité, une telle présentation pouvant être trouvée en [Paulk et al. 1991]. Les pratiques clés de chaque secteur clé sont réparties parmi cinq caractéristiques communes. Ces caractéristiques communes sont des attributs indiquant si la mise en œuvre et l institutionnalisation d un secteur clé sont ou non efficaces, reproductibles et durables. Les cinq caractéristiques communes intervenant dans le CMM sont les suivantes : engagement de réalisation : mesures que l entreprise doit considérer afin de veiller à ce que le processus soit mis en œuvre de façon durable (implique en général la mise en place des directives organisationnelles) ; capacité de réalisation : conditions préalables qui doivent être présentes dans le projet ou dans l entreprise pour mettre en œuvre, de façon compétente, le processus logiciel (fait en général intervenir des ressources, des structures organisationnelles et un effort de formation) ; activités réalisées : descriptions des rôles et des procédures nécessaires à la mise en œuvre d un secteur clé (regroupent en général la rédaction des plans et des procédures, la réalisation du travail, le suivi de cette réalisation ainsi que les actions correctives nécessaires) ; mesure et analyse : description du besoin de prendre des mesures sur le processus et d en analyser les résultats (comprend typiquement des exemples de mesures pouvant être utilisés pour déterminer l état ainsi que l efficacité des activités réalisées) ; vérification de mise en œuvre : actions qui permettent d assurer que les activités sont réalisées conformément au processus établi (couvre en général les revues et audits par la direction et l assurance-qualité logiciel). Les pratiques clés décrivent l infrastructure et les activités qui contribuent le plus à la mise en œuvre et à l institutionnalisation du secteur clé. Chaque pratique clé est énoncée sous la forme d une seule phrase, souvent suivie d une description plus détaillée pouvant comprendre des exemples et des renseignements complémentaires. Les pratiques clés décrivent «ce qui est à faire» mais n indiquent pas de manière absolue «comment» ces objectifs devraient être atteints. Utilisation du CMM Le Software Engineering Institute (SEI) a mis au point deux méthodes d évaluation de la maturité des entreprises sur le plan de l exécution des processus logiciels [Paulk et al. 1991]. Ces méthodes couvrent l évaluation du processus logiciel et l évaluation des capacités logicielles : l évaluation du processus logiciel (SPA) 15 : permet de faire le point sur le processus logiciel actuel de l entreprise, de déterminer les questions prioritaires (en termes de processus) auxquelles l entreprise doit faire face et d obtenir le soutien organisationnel voulu pour améliorer le processus logiciel ; l évaluation de la capacité logicielle (SCE) 16 : permet d identifier les sous-traitants qualifiés pour exécuter un travail logiciel. 15 La terminologie anglophone est «Software Process Assessment» 16 La terminologie anglophone est «Software Capability Evaluation» 27

42 Chapitre III Les deux méthodes d utilisation sont basées sur le CMM et les produits qui en résultent. Cependant, chacune vise à atteindre un objectif très différent. L évaluation du processus logiciel est centrée sur l identification des questions prioritaires en matière d amélioration du processus de l entreprise. L évaluation des capacités logicielles est centrée sur l identification des risques associés à un projet ou un contrat particulier de réalisation d un logiciel de haute qualité conformément aux délais et aux budgets spécifiés. Bien qu elles poursuivent des objectifs différents, elles utilisent toutes les deux le CMM comme fondement pour l évaluation. La Figure III.2 décrit sommairement les phases communes à ces deux méthodes. Choix des membres de l'équipe Questionnaire sur la maturité Échantillons représentatifs du CMM Analyse des réponses (1) (2) (3) Profil de secteur clé Constats basés sur le CMM Visite au site Entrevues et revues des documents (6) (5) (4) Figure III.5 Phases communes à l évaluation du processus logiciel et à l évaluation de la capacité logiciel La première phase consiste à rassembler une équipe. L équipe doit être composée de spécialistes qualifiés dans les domaines d ingénierie logicielle et de la gestion, qui ont reçu une formation leur permettant de comprendre les concepts fondamentaux du CMM. La deuxième phase consiste à faire remplir, par les représentants du site évalué, le questionnaire sur la maturité. Une fois cette activité achevée, l équipe d évaluation analyse les réponses (3ème phase) et identifie quels secteurs justifiant une étude plus poussée. Dans la quatrième phase l équipe visite le site en cours d évaluation, mène des entretiens avec des représentants locaux et revoit la documentation afin de mieux comprendre le processus logiciel appliqué. Une fois la période «au site» terminée, l équipe dresse une liste des constats (5ème phase) identifiant les forces et les faiblesses du processus logiciel de l entreprise. Ces constats constituent la base des recommandations afin d améliorer le processus. Enfin, l équipe prépare un profil de secteur clé (6ème phase) indiquant, pour chaque secteur, si l entreprise a ou non atteint les objectifs fixés. L algorithme utilisé dans l évaluation du niveau de maturité est séquentiel [Humphrey 1987b]. Il prend en compte le score au niveau (i+1) seulement si toutes les questions clés du niveau i ont eu la réponse affirmative «oui» (plus précisément 11 sur 12 au niveau 2, 13 sur 28

43 L état de l art 13 au niveau 3 et 11 sur 12 au niveau 4) et si le niveau i est satisfait au minimum à environ 80% pour les niveaux de 2 à 4 et 100% pour le niveau 5. La réponse à une question peut être : «oui», «non», «je ne sais pas» ou «la question ne s applique pas» 17. Le nombre des questions diminue quand le niveau augmente. Ainsi, par exemple, au niveau 2 il y a plus de questions qu au niveau 5. Le questionnaire est basé sur les pourcentages et résulte ainsi des distances équivalentes entre les niveaux de maturité, même si le nombre des questions est différent à chaque niveau de maturité. III.1.2 Bootstrap Le projet Bootstrap, financé par la Communauté Européenne, dans le cadre du Programme ESPRIT 18 a commencé dans l année 1989 et a été conclu en 1993 [Haase et al. 1994, Finkelstein et al. 1999, Kuvaja 1994]. Processus Organisation Système de qualité Gestion de ressources Education et formation Sélection du personnel Introduction de technologie Méthodologie Technologie [pour chaque attribut de méthodologie, il y a un attribut correspondant] Fonctions indépendantes du cycle de vie Gestion du projet Gestion de configuration et de changement Gestion de qualité Gestion du risque Gestion de fournisseurs Fonctions liées au cycle de vie Modèle de développement Processus spéciaux Spécifications Conception Prototypage Conception détaillée Implantation Test d unités Tests d intégration Tests d acceptation Maintenance Figure III.6 La hiérarchie des attributs liés à la qualité Fonctions liées au processus Description/modèle du processus Contrôle du processus Prise de mesure du processus Son but était de développer une méthode pour l évaluation, la mesure quantitative et l amélioration des processus logiciels. Le lancement de Bootstrap vient peu après l apparition aux Etats-Unis du CMM. Bootstrap élargit et raffine ce dernier afin de l adapter à l industrie européenne de logiciels, y compris pour des secteurs tels que les banques, les compagnies d assurance et l administration. Sa mission était de proposer un outil qui facilite l introduction d une technologie logicielle moderne dans l industrie [Kuvaja 1994]. Un autre but était de promouvoir l amélioration du processus. Cette adaptation a fourni une méthode qui peut être appliquée à une variété des unités produisant du logiciel (SPU), des compagnies de petite et 17 Les deux dernières réponses ne figuraient pas dans les premières versions du questionnaire. 18 European Strategic Program for Research in Information Technology 29

44 Chapitre III moyenne taille ou département produisant des logiciels dans des compagnies de grande taille. Le résultat de l application de la méthode d évaluation Bootstrap est un profil de la qualité du processus, qui représente les points faibles et les points forts de l'unité évaluée. Ce profil de qualité sert de fondation pour les décisions d amélioration du processus. Maturité du processus Indique Capacité du processus Dérivé du Maturité du groupement clé du processus Mesuré par Groupement du processus clé Dérivé du Contient Maturité de l attribut clé du processus Mesuré par Attribut du processus clé Questions Spécifie Pratique clé pour le niveau 2 de maturité Contient Questions Spécifie Pratique clé pour le niveau 3 de maturité Questions Spécifie Pratique clé pour le niveau 4 de maturité Questions Spécifie Pratique clé pour le niveau 5 de maturité LEGENDE = concept lié au processus = association = concept lié à la maturité ou capacité Figure III.7 La structure basée attributs de Bootstrap La méthode Bootstrap contient trois éléments majeurs : une hiérarchie détaillée des attributs liés à la qualité du processus, basée sur les attributs indiqués dans le standard pour la qualité du logiciel ISO (fournis par International Organisation for Standardisation [ISO 1991]) et dans le standard de génie logiciel PSS05 développé à l Agence Spatiale Européenne [Mazza et al. 1994] ; un raffinement de l algorithme de calcul développé par le Software Engineering Institute (SEI) dans CMM, utilisé pour calculer le niveau de maturité pour chaque attribut ; une extension du questionnaire du SEI qui peut être utilisé pour déterminer les capacités d une entreprise pour environ 30 attributs de qualité. 30

45 L état de l art Les attributs de qualité sont associés à un but de qualité et à leur tour associent des facteurs de qualité. Dans la méthode Bootstrap cette structure est représentée sous la forme d une hiérarchie des attributs liés à la qualité (voir Figure III.3). La hiérarchie prend en compte les trois dimensions principales d un processus : l entreprise, la méthodologie et la technologie. L algorithme utilisé dans l évaluation est une version étendue de l algorithme utilisé en CMM. Comme en CMM, l algorithme de Bootstrap calcule un niveau de maturité sur une échelle de cinq niveaux possibles. A la différence de CMM, l algorithme de Bootstrap calcule un niveau de maturité non pas pour le processus d une manière globale, mais pour chaque attribut considéré. Le questionnaire contient des listes de contrôle 19 pour chaque objet dans la hiérarchie des attributs de qualité. En fait, il y a un questionnaire pour le processus et un autre pour l entreprise. Le but des questionnaires est d identifier le degré dans lequel les attributs (de l entreprise ou bien du projet) satisfont les critères liés à un certain niveau de maturité, à partir de 2 jusqu au 5 (au niveau 1 on considère qu il n y a pas de processus). Comme le questionnaire est basé sur les indications du ISO , les entreprises peuvent l utiliser aussi pour interpréter le standard ISO 9001 et déterminer si elles sont prêtes pour être certifiées. Une description de ce processus peut être trouvée en [Haase et al. 1994]. La Figure III.4 montre la structure de Bootstrap, basée sur les attributs (une structure similaire pour CMM peut être trouvée dans la Figure III.1). En comparant avec le CMM, les attributs clés en Bootstrap correspondent aux secteurs clés en CMM. Une des différences est que dans CMM les secteurs clés étaient liés à un niveau de maturité, ce qui n est pas le cas en Bootstrap. La méthode Bootstrap est basée sur les attributs, elle évalue pour chaque attribut le niveau de maturité. Cette approche offre une évaluation plus détaillée et donne la possibilité aux entreprises de trouver plus facilement leur points forts et leurs points faibles. Les plans d amélioration peuvent tirer profit de cette évaluation détaillée par attributs. La méthode Bootstrap considère aussi les questions (attributs) à travers des groupements clés, qui doivent être satisfaits à degré plus grand que 50% pour satisfaire le niveau concerné. Ce groupement est fait afin de minimiser les influences des évaluateurs dans le jugement des questions individuelles. Plus précisément, en considérant des groupements de questions plutôt que des questions individuelles, l impact des jugements sur une seule question est réduit. L algorithme de la méthode Bootstrap ne considère pas (comme CMM) les niveaux équidistants. Une distance est définie entre les niveaux, d[i] (i est une valeur entre 2 et 5), en considérant le nombre des questions applicables à un niveau donné. Par exemple la distance d[2] entre les niveaux 1 et 2 est définie par le nombre des questions applicables au niveau 2. Un autre aspect important est que l échelle est dynamique, et peut varier entre deux SPU différentes, ainsi d[i] n est pas une constante, mais une variable. Les réponses possibles aux questions sont plus variées que dans le questionnaire de CMM, afin d obtenir une évaluation plus précise, et prennent des valeurs sur une échelle linguistique : absent/faible, basique/présent, significatif/correct, et extensif/complet. Chaque terme est transformé dans une valeur de pourcentage : absent en 0%, basique en 33%, significatif en 66%, et extensif en 100%. Chaque question représente un pas, qui peut être satisfait de 0, 33, 66 ou bien 100 %. En fonction de la réponse obtenue pour chaque question, on calcule le nombre des pas accumulés pour un certain niveau de maturité, avec d[i] représentant le nombre total des pas qui peuvent être accumulés au niveau i. Une autre différence dans l évaluation par rapport au questionnaire utilisé avec CMM, est la manière dont les questions sont posées. En CMM on 19 La terminologie anglophone est «checklist» 31

46 Chapitre III pose les questions liées à un niveau de maturité. Si le niveau est atteint, on passe au suivant. En Bootstrap on pose la totalité des questions et on calcule le nombre des pas que l unité a accumulé pour chaque niveau i 20. Le nombre total de pas est une première mesure qui est raffinée en tenant compte des règles telles que : si toutes les questions d un niveau i sont satisfaites avec un pourcentage plus grand que 80%, le niveau i est considéré satisfait ; pour atteindre le niveau suivant une entreprise ou un projet doivent satisfaire tous les attributs clés du niveau considéré à au moins 50%. La méthode Bootstrap a été adoptée par le European Software Institute (ESI) comme outil stratégique afin d évaluer, d analyser les processus logiciels et d établir des programmes d amélioration (l ESI est financé par 18 sociétés informatiques européennes). III.1.3 SPICE SPICE (Software Process Improvement and Capability determination) est un standard proposé dans le cadre de l International Committee on Software Engineering Standards. Son but est de construire un standard international pour l évaluation du processus logiciel, incluant le développement, l acquisition, la gestion, le support aux clients et la qualité. Il est basé sur la connaissance acquise à travers des méthodes d évaluation existantes, telles que CMM et Bootstrap. Le résultat du projet est le nouveau standard ISO [ISO 1997]. Il contient un ensemble de neuf documents qui fournissent des besoins et des conseils concernant la manière dont l évaluation d un processus logiciel doit être conduite [ESI 1996]. Ces documents fournissent aussi des conseils concernant l amélioration du processus, la détermination du niveau de la capacité, la formation et la qualification des évaluateurs ainsi que l utilisation des instruments d évaluation. Parmi les neuf documents, trois proposent des standards (des besoins normatifs) tandis que les six autres proposent des conseils. Le premier document (standard), Concepts and Introductory Guide, est un document introductif qui décrit les liens entre les autres documents. Il explique les besoins contenus dans le standard ainsi que leur applicabilité pour conduire des évaluations, pour construire et sélectionner des outils de support. Ces documents sont brièvement présentés par la suite. Model for Process Management (standard) définit les activités fondamentales qui sont considérées essentielles dans le génie logiciel, structurées à travers des niveaux de maturité. Rating Process (standard) définit un cadre pour conduire une évaluation et fixe les bases pour l estimation des capacités du processus. Guide to Conducting Assessment (conseils) fournit des conseils sur la manière dont l évaluation des processus logiciels doit être faite. Ces conseils ont un caractère générique. Construction, Selection and use of assessment instruments and tools (conseils) définit les éléments nécessaires pour construire un outil qui aide l évaluateur 21 dans son travail. Qualification and Training of Assessors (conseils) décrit les compétences, l éducation, la formation et l expérience nécessaires pour un évaluateur et pertinentes pour le processus d évaluation. 20 Cette approche est due en partie au fait que Bootstrap fait une évaluation différente pour chaque aspect du processus ; ainsi une organisation peut être évaluée niveau 2 pour la gestion de processus mais niveau 3 pour la conception. 21 Par évaluateur nous entendons une personne impliquée dans le processus d évaluation. 32

47 L état de l art Guide for Use in Process Improvement (conseils) décrit comment utiliser l évaluation du processus pour l amélioration de ce dernier. Guide for use in determining supplier process capability (conseils) décrit comment utiliser l évaluation du processus afin de déterminer la capacité dans des situations contractuelles. Ces conseils, permettant d établir la capacité du processus, peuvent aussi bien être utilisés à l intérieur d une entreprise que chez un fournisseur. Part vocabulary (conseils) fournit la définition des tous les termes définis par le standard. L architecture de SPICE possède deux dimensions et considère deux types de pratiques. Ces deux dimensions sont processus et pratiques génériques, chacune d elles représente une perspective différente du processus logiciel et la manière dont il est géré [El Emam et al. 1996] (voir Figure III.5). Processus contient Pratiques de base groupés en Catégorie de processus PROCESSUS Pratiques Génériques PRATIQUES GENERIQUES groupées en Caractéristiques Communes groupées en LEGENDE = concept lié à la mise en œuvre du processus Niveau de maturité = concept lié à l évaluation du processus Figure III.8 Les dimensions processus et pratiques génériques du SPICE La dimension processus Chaque processus contient un nombre de pratiques de base. Une pratique de base 22 est définie comme une activité du génie logiciel ou bien de gestion, liée au but d un processus particulier. Pour qu un processus soit considéré comme appliqué, ses pratiques de base doivent être présentes. Ces processus sont groupés en catégories de processus La terminologie anglophone est «base practices» 23 La terminologie anglophone est «Process Category» 33

48 Chapitre III Les catégories de processus proposées dans SPICE sont : client-fournisseur, ingénierie, projet, support et entreprise. La catégorie client-fournisseur 24 regroupe des processus qui impliquent directement le client ; ils supportent le développement ainsi que le transfert du logiciel chez le client. La catégorie ingénierie regroupe les processus qui supportent directement la spécification, l implantation ou la maintenance d un produit logiciel, ainsi que la documentation de ce dernier. La catégorie projet contient les processus qui établissent le projet, coordonnent et gèrent ses ressources afin de fournir un produit ou des services qui satisfont le client. La catégorie support regroupe des processus qui permettent et supportent la mise en œuvre des autres processus dans un projet. La catégorie entreprise contient les processus qui : établissent les objectifs d entreprises ; développent des processus, des produits et des ressources qui vont aider l entreprise à réaliser les objectifs fixés. La dimension pratiques génériques Une pratique générique est une pratique d implantation ou d institutionnalisation qui améliore la capacité de mettre en œuvre un processus. Les pratiques génériques sont groupées dans des caractéristiques communes, qui à leur tour sont groupées dans des niveaux de capacité (voir Figure III.5). En SPICE il y a six niveaux de capacité, numérotés de 0 à 5. Au niveau 0, non mis en œuvre, d une manière générale les pratiques de base ne sont pas mises en œuvre. Les produits et les autres sorties du processus ne sont pas facilement identifiables. Au niveau 1, mise en œuvre informelle, d une manière générale les pratiques de base sont mises en œuvre, mais elles ne sont ni planifiées, ni suivies. La performance dépend des connaissances et des efforts individuels. Les produits du processus sont identifiables. Au niveau 2, planifié et suivi, la mise en œuvre des pratiques de base dans le processus est planifiée et suivie. Les produits sont conformes aux besoins et aux standards spécifiés. Au niveau 3, bien défini, les pratiques de base sont mises en œuvre en suivant un processus bien défini, en utilisant des versions approuvées et adaptées du processus standard documenté. Au niveau 4, quantitativement contrôlé, des mesures sur la mise en œuvre sont collectées et analysées conduisant à une compréhension quantitative de la capacité du processus et à une amélioration de l aptitude de prédiction. La mise en œuvre est gérée objectivement. La qualité des produits est quantitativement connue. Au niveau 5, continuellement amélioré, en se basant sur les objectifs de l entreprise, des objectifs concernant l efficacité et le rendement de la mise en œuvre sont établis. L amélioration continue du processus par rapport à ces objectifs est possible à travers la rétroaction quantitative. 24 La terminologie anglophone est «custumer-supplier» 34

49 L évaluation en utilisant SPICE L état de l art Initialement, chaque pratique de base d un processus est évaluée afin de déterminer si le processus est réellement mis en œuvre. Une fois vérifié, alors le processus existe et sa capacité est évaluée à travers le niveau dont il implante les pratiques génériques. Ainsi, chaque pratique générique est évaluée par rapport à son implantation dans le processus. L échelle d évaluation comporte quatre valeurs avec des poids associés [El Emam et al. 1997] : non adéquate (N) : la pratique est soit non implantée, soit la manière dont elle est implantée ne satisfait à aucun degré son objectif ; poids associé 0 ; partiellement adéquate (P) : l implantation de la pratique contribue un peu à la satisfaction de l objectif ; poids associé 0.25 ; largement adéquate (L) : l implantation satisfait largement l objectif ; poids associé 0.75 ; totalement adéquate (T) : l implantation satisfait totalement l objectif ; poids associé 1. En SPICE, l évaluation est conduite simultanément par deux équipes. Chacune des équipes fait son évaluation. Les évaluations sont par la suite harmonisées. Il est supposé que les équipes soient équilibrées quant à la compétence de leurs membres. De plus, les membres des deux équipes ont à leur disposition le même matériel (tous participent aux mêmes entretiens, avec à leur disposition les mêmes documents). Pendant l harmonisation, la capacité évaluée ainsi que le moment de l évaluation (est que l évaluation a été faite au début ou vers la fin du processus) sont pris en compte afin de calculer un index d harmonisation (proposé par Cohen [Cohen 1960]). Cet index a des valeurs plus petites ou égales à 1. Son interprétation est aussi sur une échelle linguistique (proposée par Landis et Koch [Landis et Koch 1977] et utilisée pour l interprétation de l index dans le domaine du benchmarking). Cette échelle propose les termes : faible, peu, correcte, modéré, substantiel et presque parfait. La méthode SPICE a été testée à travers plusieurs jugements industriels. Les résultats de ces applications peuvent être trouvés dans plusieurs documents, parmi lesquels [El Emam et al. 1996], [El Emam et al. 1997], [ESI 1996], [SPICE 1998]. III.1.4 Bilan sur les modèles d évaluation du processus Chacune des méthodes d évaluation de processus que nous avons présentées propose une évaluation structurée sur des niveaux (5 ou 6). Indépendamment de ces méthodes, les niveaux les plus hauts sont corrélés avec l existence du contrôle et de la rétroaction quantitative. Ainsi, les processus (ou entreprises) évalués comme ayant un haut niveau de maturité sont des processus dans lesquels un contrôle quantitatif a été mis en place (niveau 4) ainsi qu une rétroaction quantitative (niveau 5). Nous déduirons ainsi un besoin de support pour le contrôle quantitatif ainsi que pour la rétroaction quantitative afin que les entreprises (à travers leurs processus) possèdent un bon niveau de maturité. La notion de maturité suppose un potentiel de croissance des capacités et constitue un indicateur de richesse du processus logiciel de l entreprise et de la cohérence avec laquelle il est appliqué à l occasion des divers projets menés par celle-ci. III.2 L amélioration du processus Nous avons vu dans la section précédente quelques méthodes d évaluation des capacités et de la maturité des processus logiciels. Quelques-unes de ces méthodes comportent aussi des 35

50 Chapitre III indications sur la manière dont l évaluation des processus peut être utilisée pour son amélioration. Nous allons présenter dans cette section des méthodes dédiées à l amélioration du processus, notamment la Quality Improvement Paradigm avec ses outils associés : l Experience Factory et le Goal/Question/Metric développés à l Université de Maryland [Basili et al. 1994a, Basili et al. 1994b] ainsi que le Personal Software Process développé à Software Engineering Institute [Humphrey 1995, Humphrey 1996, Humphrey 1997]. Nous allons également présenter une démarche d amélioration dans le cadre des processus manufacturiers [Berrah 1997, Berrah et al. 1995, Berrah et al. 1996]. III.2.1 QIP Le Quality Improvement Paradigm (QIP) [Basili et al. 1994a, Basili et al. 1994b] a été proposée par le Software Engineering Laboratory (SEL) de l Université de Maryland afin d offrir un support pour la mise en œuvre de l amélioration du processus. Le QIP est articulé autours de six pas : 1. caractériser : comprendre l environnement en se basant sur des modèles disponibles, des données, sur l intuition, etc. ; 2. fixer des buts : fixer des buts quantifiables pour la mise en œuvre et l amélioration des projets et de l entreprise en général (en se basant sur la caractérisation de l'environnement et sur les capacités du processus qui ont une pertinence stratégique pour l entreprise) ; 3. choisir un processus : en fonction des pas précédents, choisir un processus d amélioration ainsi que des méthodes et des outils qui lui offrent un support ; 4. exécuter : exécuter le processus logiciel, tout en fournissant de la rétroaction ; celle-ci est basée sur des données collectées concernant la mesure dont les buts sont atteints ; 5. analyser: à la fin de chaque projet, analyser les données collectées afin d évaluer les pratiques en cours, de déterminer des problèmes, de garder les résultats et de faire des recommandations pour les améliorations de projet ; 6. paquetage: consolider l expérience sous la forme de connaissance structurée (modèles, équations, etc.) et stocker cette dernière dans une base d expériences. Le QIP indique comment mettre en place un processus continue d amélioration qui prend en compte les expériences précédentes. En fait, le paradigme contient deux cycles de rétroaction : le cycle de contrôle et le cycle de capitalisation. 36 Le cycle de contrôle se place au niveau d un projet et représente la rétroaction fournie au projet pendant son exécution. Des indicateurs quantitatifs au niveau du projet et des tâches sont utiles pour prévenir et résoudre des problèmes. Le cycle de capitalisation se place au niveau de l entreprise et a un double apport. D un côté, il fournit l information analytique concernant l exécution du projet après sa fin, en comparant les données du projet avec des valeurs de référence dans l entreprise ; des analyses de concordance et de divergence peuvent être faites dans ce contexte. D un autre coté, il permet l accumulation de l expérience réutilisable sous la forme d artefacts logiciels qui sont applicables à d autres projets. Le QIP est ainsi basé sur la supposition suivante : afin d améliorer les produits et les processus logiciels il est nécessaire de faire une accumulation continue des expériences évaluées (apprentissage) dans une forme qui peut être comprise et améliorée d une manière efficace (modèles d expérience) dans un répertoire de modèles d expérience intégrés (base

51 L état de l art d expérience). Ce dernier peut être accédé et modifié afin de faire face aux besoins du projet en cours (réutilisation) [Basili 1989]. Le paradigme implique la séparation logique entre le processus de développement d un côté, et l apprentissage systématique ainsi que le paquetage d expériences réutilisables de l autre. Deux outils sont utilisés par la QIP : le Goal/Question/Metric (GQM) et l Experience Factory (EF). GQM est utilisé pendant la phase de planification englobant les trois premiers pas mentionnés auparavant. Il facilite la définition de buts ainsi que la définition de métriques associées aux buts. Ces métriques sont utilisées dans le cycle de contrôle et guide l exécution du processus. La EF est une structure organisationnelle qui offre un support aux activités de paquetage. Nous allons présenter ces deux outils ci-dessous. Le Goal/Question/Metric GQM est un mécanisme utilisé pour définir des buts mesurables, qui peuvent être utilisés d une manière isolée ou dans le cadre d une démarche d amélioration [Basili et al. 1994b]. Le résultat de l application de GQM est la spécification d un système de mesures visant un ensemble particulier de problèmes ainsi qu un ensemble de règles dédiées à l interprétation des données issues de ces mesures. Ce système de mesure est organisé en trois niveaux : le niveau conceptuel («goal»), le niveau opérationnel («question») et le niveau quantitatif («metric»). Au niveau conceptuel un but est défini pour un objet, pour différentes raisons, par rapport à différents modèles de qualité, depuis différents points de vue et relativement à un environnement particulier. Les objets peuvent être des produits, des processus ou bien des ressources. Au niveau opérationnel un ensemble de questions est défini afin de caractériser la manière dont les buts vont être atteints. Les questions essayent de caractériser l objet de la mesure par rapport à un problème de qualité, ainsi que de déterminer sa qualité depuis un point de vue choisi. Au niveau quantitatif un ensemble de données est associé à chaque question afin d y répondre d une manière quantitative. Les données peuvent être objectives : dépendant seulement de l objet qui est mesuré et non pas d un point de vue (par exemple le numéro des versions d un document) ; ou bien subjectives : dépendant de l objet qui est mesuré ainsi que du point de vue de la mesure (par exemple la lisibilité d un texte, le niveau de satisfaction de l utilisateur). GQM englobe et généralise plusieurs approches de la mesure (pour incorporer des processus, des ressources ainsi que des produits), ce qui le rend adaptable aux différents environnements. Ceci a été confirmé par son application dans plusieurs entreprises, telles que NASA, Hewlet Packard, Motorola, Coopers & Lybrand. Quand le GQM est utilisé dans une démarche d amélioration, le développement des modèles GQM est une tâche exécutée par l Experience Factory qui va prendre comme entrée les buts de l entreprise ainsi que les caractéristiques de l environnement. L Experience Factory L Experience Factory [Basili et al. 1994a] a pour but la capitalisation et la réutilisation de l expérience sur le processus logiciel ainsi que sur les produits fournis par ce dernier. L EF est une entreprise physique et logique et ses activités sont indépendantes de celles de l entreprise de développement. Elle analyse et synthétise diverses expériences, prenant le rôle 37

52 Chapitre III d un répertoire pour celles-ci, et fournit l expérience gardée à la demande de différents projets. Nous pourrions donner comme exemples de réalisations de paquetage de l expérience : des équations qui définissent des relations entre des variables (par exemple effort (en personnes mois) = 1.48*(KLOSC) 0.98, ou KLOSC représente les milliers de lignes dans le code source 25 comme en COCOMO) ; des histogrammes contenant des données brutes ou bien des résultats d analyses (par exemple pourcentage pour chaque classe d erreur) ; des graphes définissant les écarts «normaux» (par exemple pour la croissance de taille dans le temps, avec des degrés de confiance). Quant aux paquetages proprement dits, ils peuvent contenir : des produits stockés ensembles avec l information nécessaire à leur réutilisation ainsi que les leçons apprises (par exemple des programmes, des architectures, des conceptions) ; des processus stockés ensembles avec l information nécessaire à leur exécution ainsi que les leçons apprises (par exemple des modèles de processus, des méthodes) ; des relations ou des ensembles de relations observées entre des caractéristiques d un projet ; des outils spécifiques, constructifs (générateurs de code) ou bien analytiques (analyseurs statiques, vérificateurs). des informations de référence pour la gestion du projet, telles que le guide de management ou bien des modèles de support à la décision ; des données définies et validées qui sont significatives pour un projet logiciel ou des activités d un tel projet (par exemple une base de données du projet ou encore des enregistrements de qualité). L EF offre ainsi une structure organisationnelle qui sépare le développement des produits de l apprentissage et leur réutilisation. III.2.2 Personal Software Process Les propositions que nous avons précédemment présentées, aussi bien pour l évaluation que pour l amélioration, se placent au niveau du projet ou de l entreprise. Il a été constaté que la maturité et la capacité des développeurs étaient un facteur déterminant pour la productivité et la qualité des produits. Ainsi, motivé par le succès de CMM, le SEI a récemment travaillé sur le Personal Software Process (PSP) [Humphrey 1995, Humphrey 1996, Humphrey 1997]. Le but de PSP est d aider les ingénieurs à améliorer leur productivité personnelle, contribuant ainsi à l amélioration du processus dans lequel ils sont impliqués. Les ingénieurs sont introduits au PSP à travers des exercices. Le PSP définit 4 niveaux de maturité et identifie les pas nécessaires pour atteindre le niveau supérieur : PSP0 Prise de mesure personnelle 26, PSP1 Planification personnelle 27, PSP2 Qualité personnelle 28, PSP3 Processus cyclique KLOSC = Kilo Lines Of Source Code [SELS 1995] 26 La terminologie anglophone est «Personal Measurement» 27 La terminologie anglophone est «Personal Planning» 28 La terminologie anglophone est «Personal Quality» 29 La terminologie anglophone est «Cyclic Process» 38

53 L état de l art Une grande partie des considérations de CMM s appliquent au PSP. Afin d améliorer la maturité des développeurs individuels, la manière dont ils travaillent doit être d abord évaluée. Au premier niveau (PSP0) les ingénieurs apprennent à mesurer : leur temps de développement ; les défauts qu ils ont mis dans le produit de leur travail ; les défauts qu ils ont enlevés dans le produit de leur travail. De plus, les standards pour le codage, la mesure de la taille du code ainsi qu une manière pour améliorer leur performance leur sont introduits. Au deuxième niveau (PSP1), les ingénieurs apprennent des techniques pour l estimation de la taille et du temps de développement en se basant sur les données acquises pendant PSP0. De plus, ils apprennent comment planifier des tâches et faire des calendriers. Le niveau PSP2 introduit la gestion des défauts. Les ingénieurs utilisent les données acquises dans les phases précédentes afin de construire des listes de contrôle pour identifier les erreurs qu ils sont susceptibles de faire. Ils apprennent l importance de se focaliser sur la qualité personnelle. En utilisant les listes de contrôle, leurs capacités s améliorent. Au niveau PSP3, le monitoring des défauts introduits et enlevés ainsi que la vérification des listes de contrôle sont faits d une manière constante, ce qui est supposé améliorer davantage la qualité personnelle. Le PSP a été testé d une manière expérimentale sur une population formée par des étudiants, des jeunes ingénieurs et des ingénieurs expérimentés. Il a pu être observé une amélioration de la productivité très importante dans le cas des étudiants (d environ 420%). Par contre dans le cas des ingénieurs expérimentés, la productivité a plutôt baissé à cause de la surcharge de travail. Cependant, dans tous les cas, une amélioration de la qualité des produits développés a été observée. III.2.3 Amélioration des processus manufacturiers Les travaux que nous présentons portent sur la mesure de la performance et sur le pilotage des systèmes de production des entreprises manufacturières, dans une démarche d amélioration de ces systèmes [Berrah et al. 1995, Berrah et al. 1996, Berrah 1997]. Il s agit d un système d indicateurs de performances utilisé pour l évaluation de la performance des processus manufacturiers. La performance est vue au travers de critères multiples (coûts, délais, qualité), pour lesquels des indicateurs de performance sont mis en place. Un indicateur de performance est défini par un triplet (objectif, mesure, variable d action). Les travaux se situent aux niveaux tactiques et opérationnels et sont orientés vers la quête de la performance (en termes simultanés de qualité, délai, ) des processus industriels (opérants). Les indicateurs sont essentiellement physiques (opérationnels, techniques ou industriels), plus précisément ce sont des indicateurs non monétaires issus du processus industriel. Le modèle d indicateur de performance prend en compte des informations imprécises et/ou incertaines. Ainsi, les objectifs et les résultats de mesures sont représentés en utilisant la théorie des ensembles flous. Les informations sont aussi bien numériques que linguistiques. La théorie des possibilités est également utilisée dans le traitement des informations linguistiques. Une démarche d amélioration est proposée, en indiquant les étapes pour la mise en place d un système d indicateurs. La Figure III.6 présente ces étapes. 39

54 Chapitre III Stratégie Détermination des Facteurs Clés Succès Formulation des objectifs globaux Analyse des processus et des activités feedback Déploiement des objectifs globaux sur les processus Traduction Facteurs Clés Succès > Facteurs Clés Performance Diagnostique Identification des activités critiques et de leur facteurs de performance Analyse de l existant Analyse de la performance Choix des facteurs clés de progrès (recherche des causes) Détermination des Plans d action Mise en place du système d indicateurs Affichage d indicateurs Figure III.9 Les étapes de mise en place d'un système d'indicateurs à partir des facteurs de succès et de performance de l'entreprise Le modèle d indicateurs a été validé à travers une application chez Ski Dynastar. Dans ce contexte des indicateurs de performance ont été mis en place pour l évaluation de la qualité des skis et de leur production. Pour la qualité des skis un indicateur avec des mesures linguistiques a été mis en place. A l aide de cet indicateur la propreté des talons de skis est évaluée. Un autre indicateur de performance a été proposé pour l évaluation du coût de fabrication d une paire de skis. L expression de la performance résulte de la comparaison du coût effectif de fabrication des skis au coût fixé par la norme technique. III.2.4 Bilan sur les modèles d amélioration du processus Nous avons présenté dans cette section des approches pour l amélioration des capacités et de la maturité logiciel en passant du niveau organisationnel, par le niveau projets jusqu au niveau des individus impliqués dans les processus. Nous avons également présenté des travaux concernant l amélioration dans les processus manufacturiers. Pour les domaines du processus logiciel, un constat général est qu indépendamment de la position dans les niveaux hiérarchiques d une organisation, la prise des mesures et le contrôle sont nécessaires dans les niveaux les plus hauts de maturité. Le contrôle quantitatif est ainsi une garantie de la qualité. Les méthodes étudiées fournissent des normes concernant la manière dont la prise de mesure ainsi que les analyses et les interprétations doivent être mises en œuvre. Ces approches sont 40

55 L état de l art généralement données dans le langage naturel d une manière informelle, ce qui implique naturellement certaines ambiguïtés et incohérences. La manque de support informatique limite l applicabilité de ces méthodes, car elles sont corrélées avec une surcharge de travail important. Le support logiciel pour le processus de mesure et d analyse, permettant un certain degré d automatisation est indispensable dans ce contexte, car il assure un support pour la meilleure application de ces méthodes. Cela est corrélé avec le besoin de formalisation afin de pouvoir permettre l automatisation (partielle ou totale) de l analyse. Dans le processus manufacturier la démarche adoptée pour l amélioration de la performance fait aussi référence à la rétroaction. Le processus est mesuré à l aide des indicateurs de performance. Un modèle d indicateurs est proposé, fondé sur le triplet (objectif, mesure, variable d action). Ce modèle fournit un cadre mathématique pour le calcul de la performance. Cependant, aucun langage ni méta-modèle pour supporter la définition d autres modèles d évaluation ne sont proposés par ces travaux. III.3 Les systèmes de mesure et d analyse Comme nous l avons vu, les méthodes d amélioration proposées font référence au contrôle et à la rétroaction dans leurs niveaux les plus hauts de maturité. Nous allons dans cette section regarder des systèmes qui ont abordé le problème de la mesure, de l analyse de processus ou de la rétroaction. Nous avons étudié des systèmes très variés, partant des systèmes qui ne font que des prises de mesures, passant par des propositions d analyses des données de processus jusqu aux systèmes plus complexes qui proposent aussi bien des prises de mesures que des analyses. Des critères d étude ont été pris en compte. Dans la suite de cette section, nous commencerons par une présentation des critères que nous avons utilisés dans l étude de ces systèmes, continuerons par les présentations de chacun des systèmes pour finir par un bilan qui compare les systèmes. III.3.1 Critères de l étude Nous classifions les critères de cette étude en trois groupes. Dans le premier groupe, nous retrouvons des critères liés aux données et à leur collection, dans le deuxième des critères liés à l analyse, et dans le troisième des critères portant sur des caractéristiques de systèmes. Nous remarquons que les buts, pour lesquels les systèmes ont été conçus, varient d un système à l autre. Ainsi on retrouve des systèmes qui ont été conçus pour : offrir une base pour la réutilisation ; offrir une image globale du processus en exécution ; découvrir des relations intéressantes entres des données existantes, améliorer un aspect précis du processus ; etc. III Critères liés aux données et mesures Critère 1 : l objet de la mesure Par rapport à ce critère, les systèmes peuvent s orienter soit vers les processus, soit vers les produits en prenant des mesures de propriétés des processus, des produits ou des deux à la 41

56 Chapitre III fois. Ainsi les valeurs associées à ce critère sont bien précisées : produit, processus ou produit et processus. Critère 2 : la nature des données sur lequel le système opère En ce qui concerne la nature des données (valeurs de différents aspects des processus ou produits) nous distinguons deux types de données. Les données historiques portent soit sur des exécutions de processus finies soit sur des produits issus de telles exécutions. Les données actuelles portent soit sur des processus en cours d exécution soit sur des produits en cours de fabrication. De plus, les données historiques sont collectées, soit par le système même, soit avant que le système soit mis en place. Ainsi, nous allons retrouver des systèmes qui traitent seulement des données historiques, des données actuelles qui font référence à un projet en cours d exécution ou les deux à la fois. Trois valeurs sont ainsi associées à ce critère. Critère 3 : la manière dont la collection des données s effectue Par rapport à la collection des données (prise de mesure) nous distinguons la collection automatique, la collection semi-automatique et la collection manuelle [Beydeda et Cîmpan 1999]. Dans le cas de la collection automatique les données sont collectées par le système d une manière automatique, par exemple à travers un mécanisme de publication/souscription des événements. Dans le cas de la collection semi-automatique, les données sont introduites dans le système de mesure par un agent du processus à travers une interface utilisateur. Les données manuellement collectées sont introduites dans le système sur l initiative des agents de processus (elles se trouvent généralement en dehors du système de mesure). Les données manuellement collectées peuvent être introduites ultérieurement dans les bases du système de mesure. Critère 4 : prise en compte des données imprécises A travers ce critère, nous regardons si les systèmes prennent en compte la nature imprécise ou bien incertaine des données concernant le processus. Cette prise en compte peut se faire à plusieurs niveaux, inexistante, partielle ou bien explicite. Dans la représentation explicite, un mécanisme est fourni afin de permettre leur représentation. Dans la prise en compte partielle, la nature imprécise ou incertaine des données est reconnue, mais la représentation des données reste sous la forme des données précises. Par exemple, l espacement des prises de mesure à des intervalles réguliers mène à une certaine imprécision. En effet, dans leur contexte d utilisation les données ne sont pas si précises que dans le cas ou la prise de mesure se ferait à chaque changement de valeur. III Critères liés aux analyses Critère 5 : type d analyses Les analyses qui peuvent se faire sur des données sont très variées. En fait, il y a un lien entre ce critère, le but du système, et les genres de données sur lesquelles le système travaille. Nous 42

57 L état de l art retrouvons des systèmes qui ne font aucune analyse, et des systèmes qui fournissent une forme d analyse, comme par exemple une arithmétique simple, des analyses statistiques, des arbres de classification, etc. La deuxième catégorie n est pas rigide, d autres types d analyses peuvent être retrouvés. Critère 6 : analyse de comparaison avec un modèle A travers ce critère, nous regardons si les analyses font recours à des comparaisons du processus (produit) analysé avec des modèles de références. De tels modèles peuvent être issus des données historiques (par exemple sous la forme des moyennes représentant des valeurs pour les mêmes aspects observés dans des projets précédents), ou bien être des modèles de processus. Critère 7 : les résultats d analyses Ce critère nous donne des indications concernant les moments où les analyses sont faites. Plus précisément, il indique le moment où les résultats des analyses sont disponibles. A travers ce critère nous faisons la distinction entre deux types d analyses : en-ligne et à posteriori. Les analyses à posteriori se font une fois que l exécution du processus est finie (ou que le produit est terminé) ; elles ont un caractère rétrospectif et portent sur des données historiques. De telles analyses peuvent être utilisées comme base pour l apprentissage et fournissent un support à la réutilisation. Les analyses en-ligne se font pendant l exécution du processus, et donne lieu à la possibilité de rétroaction dans le cycle de contrôle ; au moins une partie des données utilisées sont des données actuelles. III Critères liés aux caractéristiques du système Critère 8 : intégration dans un EGLCP A travers ce critère, nous nous intéressons au niveau d intégration des systèmes dans des EGLCPs. Ainsi nous pouvons retrouver des systèmes qui ne permettent pas leur intégration avec des EGLCP, des systèmes qui sont intégrés ou bien intégrables. Nous précisons ainsi qu il y a des systèmes qui sont intégrés ou intégrables dans un EGLCP d une manière qui modifie l EGLCP (en modifiant par exemple le code du processus) ou bien sans nécessiter des modifications. Ainsi, les systèmes peuvent être classifiés comme ayant une intégration inexistante, possible, prévue ou bien existante. Critère 9 : le caractère évolutif du système Ce critère est lié aux mécanismes que les systèmes mettent à disposition afin de faire évoluer leurs capacités, par exemple à travers l ajout de nouvelles mesures ou bien de nouvelles techniques d analyse définies par l utilisateur. Un tel caractère évolutif peut être inexistant, existant automatisé ou bien existant non-automatisé. Critère 10 : niveau de formalisation Nous faisons référence en utilisant ce critère au niveau de formalisation du système. Le niveau de formalisation peut être : nul, correspondant à une formalisation inexistante ; 43

58 Chapitre III moyen, correspondant à une formalisation partielle ; élevée, correspondant à l existence d un langage de modélisation, etc. Critère 11 : niveau d adaptabilité Ce critère fait référence à la capacité du système à s adapter à l environnement dans lequel il est utilisé, plus précisément à l existence de mécanismes permettant le réglage du système. Les valeurs possibles sont non supporté ou bien supporté. Les critères précisés ne s appliquent pas à tous les systèmes que nous avons étudiés, à cause de la nature variée de ces derniers. Ainsi, nous ne pouvons pas appliquer le critère d intégration dans un EGLCP ou le caractère évolutif à une méthode. III.3.2 Tame Le projet Tame (Tailoring a Measurement Environment) [Basili et Rombach 1987, Basili et Rombach 1987] de l Université de Maryland a pour but la construction d un modèle de processus d ingénierie logicielle orienté amélioration ainsi que d un environnement qui instantie ce modèle. Le modèle proposé utilise le paradigme but/question/métrique (GQM) afin d intégrer les aspects constructifs et analytiques du développement de logiciel. Les aspects constructifs font référence à la construction des produits, tandis que les aspects analytiques font référence à l analyse des processus constructifs et des produits qui en résultent. D ailleurs, le projet propose un ensemble de principes dont une partie concernant le génie logiciel (dix principes), et une autre concernant la prise de mesure du logiciel sur des produits ou des processus (quatorze principes). Ces principes englobent l expérience de travail accumulée par les auteurs concernant la mesure et l évaluation des processus de génie logiciel dans différents environnements. Le modèle et le système TAME sont ensuite construits en respectant ces principes. Le modèle est basé sur les paradigmes d amélioration de la qualité (QIP) et GQM. Dans la Figure III.7 nous présentons ce modèle. Ainsi, nous retrouvons dans ce modèle les étapes indiquées par QIP : caractériser l environnement, fixer des objectifs, choisir des modèles (à travers la planification), exécuter, analyser et faire le paquetage de l expérience. En fait, dans TAME ces étapes sont réparties à travers quatre grands composants dédiés à : caractériser, planifier, exécuter le processus et stoker l expérience. L apprentissage ainsi que la rétroaction sont distribués à travers le modèle et ses composants sous la forme des flots d information entre ces derniers. Les trois premiers composants sont vus depuis les deux perspectives : constructive et analytique. Par exemple dans la planification du «quoi» les objectifs sont établis. Dans la perspective constructive, le même composant (planification du «quoi») contient des objectifs pour le projet, tels que : «finir à temps», «avoirs les fonctionnalités nécessaires afin de satisfaire le client», etc. Certains de ces objectifs peuvent être considérés comme des objectifs d amélioration. La perspective analytique fait référence aux procédures d analyse pour le monitoring et le contrôle de la mesure dont les buts constructifs sont atteints. La perspective des buts analytiques doit prescrire aussi les chemins de rétroaction et apprentissage nécessaires. Le modèle fournit la description de chacune des étapes [Basili et Rombach 1987, Basili et Rombach 1988]. 44

59 L état de l art tâche perspectives caractériser quoi planifier comment exécuter constructive caractériser fixer plan pour la construction construit analytique l environnement des objectifs plan pour l analyse analyse boucles de rétroaction pour des futures projets BASE D EXPERIENCE Figure III.10 Le modèle de processus orienté amélioration TAME Le système TAME est une instanciation du modèle TAME en tant qu Environnement de Génie Logiciel Intégré 30 (EGLI). Afin de supporter d une manière effective le modèle précédemment présenté, le EGLI doit offrir un support pour tous les composants du modèle (caractériser, planifier, exécuter et la base d expérience) ainsi que toutes les interactions entre les composants. Une architecture du EGLI TAME a été proposée (voir Figure III.8), et le prototype construit essaye d implanter le plus de composants possibles (une partie des composants ne pouvant pas être implantés à cause de différentes raisons, telles que l indisponibilité des technologies nécessaires, le manque de temps, etc.). Les composants du système TAME sont groupés sur cinq niveaux logiques : l interface utilisateur physique, l interface utilisateur logique, l analyse et la rétroaction, la prise de mesures et le support. Comme il est montré dans la Figure III.8, chacun de ces niveaux contient un ou plusieurs composants. La partie concernant le processus de développement présente dans le modèle TAME (la partie «construit») ne figure pas dans cette architecture, l idée étant de construire une interface avec un environnement qui assure le support du processus constructif (à travers le composant A4). Cette interface n était pas réalisée dans la version du système que nous avons étudiée [Basili et Rombach 1988]. Du point de vue de notre étude, à savoir la mesure, l analyse et la rétroaction, nous remarquons que l architecture du système englobe les trois aspects. L objet de la mesure est aussi bien le processus que les produits qui sont construits. La collection des données devrait se faire à travers des outils de mesure et en utilisant un planificateur. Le planificateur devrait donner une stratégie pour la collection des données, or il n est pas implanté, c est pourquoi la stratégie est indiquée par l utilisateur, en déclenchant d une manière explicite les activités de mesure. 30 La terminologie anglophone est «ISEE Integrated Software Engineering Environment» 45

60 Chapitre III A1 : Gestion de l interface utilisateur NIVEAU INTERFACE UTILISATEUR PHYSIQUE A2 : Sélection du modèle GQM A3 : Génération du modèle GQM NIVEAU INTERFACE UTILISATEUR LOGIQUE (ORIENTEE GQM) A4.1 : Interface de construction A4.2 : A5 : Analyse et rétroaction GQM A6 : Planificateur des prises de mesure A7 : Outils de mesure NIVEAU ANALYSE ET RETROACTION NIVEAU PRISES DE MESURES A10 : La base d expérience TAME A8 : Génération des rapports A9 : Introduction et validation des données NIVEAU SUPPORT Figure III.11 Conception architecturale du système TAME Il existe deux types d analyse : un lié à l interprétation des modèles GQM afin de voir si les buts ont été atteints, et un autre lié à la mesure des attributs complexes (la mesure de tels attributs nécessite des analyses sur des données brutes). En ce qui concerne les analyses liées au GQM, par exemple l interprétation des mesures, elles ne sont pas automatisées, à cause du niveau insuffisant de formalisation de la méthode GQM. L interprétation est laissée à l utilisateur. Quant aux attributs complexes, nous retrouvons des analyses faites à l aide d un outil de liaison des données 31. Ainsi, il a été mesuré (non pas d une manière automatique) la cohérence structurale entre l implantation des systèmes et leur conception [Hutchens et Basili 1985], la relation entres fautes et la structure hiérarchique mesurée par l outil de liaisons des données [Selby et Basili 1987]. Des classes de produits ont été caractérisées en se basant sur leur structure syntaxique [Doubleday 1987]. Dans ces cas les analyses sont orientées produits et portent sur des systèmes codés en Ada. Quant à l intégration dans un EGLCP, nous remarquons le fait que l architecture est construite afin de pouvoir permettre une telle intégration. La partie A4.2 de l interface permet l accès à des librairies externes, cependant la collection automatique n est pas possible. Il en est de même pour la rétroaction automatique dans le processus constructif. Les résultats des analyses sont transmis à l utilisateur à travers des générateurs de rapports. Le système permet l évolution, car il est prévu de mettre en place un générateur de modèles GQM. Celui-ci permet la construction de modèles GQM à partir de rien ou d autres modèles. 31 La terminologie anglophone est «data binding tool» 46

61 L état de l art Il est donné sous la forme de patterns et de directives. L implantation est cependant limitée par l existence d éditeurs pouvant imposer le respect des patterns et des directives. Le système ne fournit pas des mécanismes permettant son réglage. III.3.3 Amadeus Amadeus est un prototype pour l analyse et la rétroaction dans des processus logiciels développé à l Université de California, Irvine [Selby et al. 1991], et il s intègre dans un projet plus grand, Arcadia [Taylor et al. 1988]. Une version commerciale de ce système a été construite par Amadeus Software Research Inc. Le système est guidé par trois principes fondamentaux : avoir une prise de mesure active : intégrer la prise de mesure avec le processus ; fournir des mécanismes : permettre de spécifier l interprétation des événements ; avoir un caractère évolutif : permettre l intégration des nouvelles techniques d analyses. Amadeus fournit un langage de script qui englobe des mécanismes permettant l interprétation statique et dynamique des événements de processus, les changements d état d objets, les événements liés au calendrier (abstractions temporelles). Ces trois types d événement peuvent être combinés afin d obtenir des événements composés (par exemple «chaque fois qu un objet change, mais pas plus d une fois par jour»). Amadeus englobe des mécanismes pour : des techniques d évaluation et d analyse empiriques ; le déclenchement des actions basées sur les trois types d événements spécifiés précédemment ; l interprétation des événements statique ou dynamique ; la séparation entre la spécification des événements et celle des agents qui gèrent les événements ; la collection des données transparente et concurrente ; la réduction des coûts à travers des réutilisations des scripts. L aspect opérationnel. Un ingénieur logiciel active des scripts Amadeus afin de faire le monitoring des événements de processus, des changements d état des objets, et des abstractions temporelles. Les événements déclenchent des agents spécifiés par l utilisateur (englobés en tant que processus) qui analysent l état de l environnement avec ses processus et objets. Ces agents collectionnent, analysent et font l intégration ou l affichage des données. Des programmes de processus ou des utilisateurs humains peuvent faire des requêtes sur les données collectées afin de trouver comment ces dernières affectent l exécution du processus. L information collectée est utilisée afin de guider et adapter le processus. Le système Amadeus sépare la spécification des événements de celle des agents. Ceci permet de différentier ces deux aspects dans le temps. Un utilisateur spécifie les événements qu il veut observer et après il spécifie un agent correspondant, ou bien il laisse l agent non spécifié (l agent nul). Si l agent est spécifié, il peut être interprété d une manière statique et incorporé directement dans le processus. Des agents peuvent aussi être spécifiés après la spécification des événements, notamment avant, pendant ou bien après l exécution du processus. L architecture. L architecture conceptuelle est présentée dans la Figure III.9. L élément central de l architecture est le serveur proactif, qui interprète des scripts et coordonne le 47

62 Chapitre III monitoring des événements ainsi que l activation des agents qui les gèrent. Les données collectées sont persistantes à travers les projets. Des cadres d intégration des données sont définis, représentés sous la forme d arbres ou de réseaux permettant l intégration des diverses données (symboliques et numériques) provenant des différentes sources. Requêtes des scripts générées directement depuis le processus SERVEUR PRO-ACTIF AGENTS ACTIFS PP1 Boîte de dialogue pour l interaction avec les utilisateurs Scripts Programmes de processus annotés statiquement Interpréteur des scripts Dépôt persistent des données historiques Table de coordination Langages de système Interaction dynamique entre les agents UIMS OM EC PP2 UIMS OM Palette des objectifs Spécificateur d analyse empirique Instrumenteur de processus Browseur de taxonomie des métriques TROUSSE A OUTILS DU CLIENT Outils pour la collection Analyseurs d interconectivité Analyseurs de classification Outils statistiques et de visualisation TROUSSE A OUTILS DU SERVEUR EC EC = «evaluation component» OM = «object manager» UIMS = «user interface management system» PP = «process program» Figure III.12 Architecture conceptuelle du système Amadeus Les scripts peuvent être définis et activés par les utilisateurs ou bien peuvent être activés par les processus, à condition que ces derniers soit instrumentés avant leur exécution (ce qui implique l accès au code du processus). Comme le langage utilisé est le même dans les deux cas, notamment celui des scripts, les requêtes sont traitées d une manière uniforme par le serveur, indépendamment de leur provenance. Les trousses à outils du client et du serveur 32 sont des collections extensibles des capacités du système. Les utilisateurs peuvent rajouter à ces trousses à outils des spécifications, collections et analyses des données, ainsi que des outils de rétroaction. La trousse du client contient des mécanismes accessibles aux utilisateurs, dédiés principalement à la définition des scripts et au processus de gestion. La trousse du serveur contient des mécanismes utilisés par le serveur dans l interprétation des scripts. Le serveur délègue la collection des données à des composants d évaluation individuels (ECs). Il est indépendant du langage utilisé dans la programmation du processus (PPL), du gestionnaire d objets (OM) ainsi que du gestionnaire des interfaces utilisateur (UIMS). Les composants d évaluation sont dépendants de PPL, UIMS ainsi que de OM. Les analyses proposées incluent des analyses de classification qui utilisent des arbres de classification. Cette technique permet de classifier les composants logiciels en fonction de leur susceptibilité d avoir des propriétés, telles que certains types d erreur, effort de développement important, etc. Les arbres de classification sont basés sur des métriques. 32 La terminologie anglophone est «client toolkit» et «server toolkit» 48

63 L état de l art Chaque nœud correspond à une décision et contient une métrique. Les sorties d une décision (des branches partant du nœud de décision) correspondent à un intervalle de valeurs que la métrique peut fournir. Les feuilles de l arbre ont les valeurs «+» ou «-» et indiquent si le composant analysé est susceptible («+») ou pas («-») d avoir la propriété considérée. D autres techniques d analyse étudient les relations qui existent entre des composants complexes dans des grands systèmes, permettant aux développeurs d évaluer les changements éventuels. Ainsi, les techniques d analyse proposées sont plutôt orientées produit. Les analyses peuvent se faire en ligne ou à posteriori. Le système offre un support pour la collection automatique des données. Cependant, l instrumentation statique du processus, afin de collecter des données, suppose l accès au code du processus ainsi que des droits de modification. Même si Amadeus est un système de mesure, d analyse et de rétroaction, un de ses principes est sa forte interconnexion avec le support de processus. Ceci est réalisé en instrumentant le processus pour la collection des mesures et permettant un guidage empirique «depuis l intérieur du processus». D ailleurs les futurs développements envisagés vont vers l extension d Amadeus dans un EGLCP. Le système ne permet pas la représentation des données imprécises, mais fournit un mécanisme pour l intégration des différentes données. A notre connaissance, des analyses de comparaison du processus avec des modèles ne sont pas fournies. Le système Amadeus est un des plus complets systèmes de mesure, d analyse et de rétroaction que nous avons étudiées. Ses principes architecturaux nous ont paru aussi très intéressants. Cependant, l interconnexion avec le support de processus est importante, nécessitant la modification du support de processus originaire. Le système est très centré implémentation. Tout est fondé sur la programmation des scripts, et aucun modèle ne décrit le comportement du système, ce qui fait d Amadeus un environnement d implémentation de monitoring, plutôt que de définition de monitoring. III.3.4 Hakoniwa Hakoniwa [Iida et al. 1993] est un prototype d un système pour la navigation et le monitoring dans des environnements de développement coopératif. Hakoniwa est basé sur un modèle qui défini le processus de développement par un ensemble de tâches avec des primitives de communication. Les activités d un seul individu sont représentées à l aide d une grammaire hors contexte, car il est supposé que les activités mises en œuvre par un individu sont séquentielles, cette représentation était utilisée pour la représentation du processus entier dans une version antérieure du système [Iida et al 1991]. Le modèle de processus proposé est composite et consiste en plusieurs modèles simples. Chaque modèle simple représente une vue différente du processus logiciel depuis un certain point. Deux modèles sont ainsi proposés : un pour les activités et un pour les relations entre les produits. Le modèle d activités définit des contraintes concernant l ordre d activités, tandis que le modèle de relations entre les produits définit des relations entre les produits qui apparaissent pendant le développement. Le modèle d activités est basé sur un modèle de processus concurrentiel, le CSP (Communicating Sequential Processes) [Hoare 1985]. Un modèle d activités est composé par plusieurs tâches concurrentes. Une activité primitive représente dans ce modèle l unité atomique de travail, telle que l exécution d un outil. Une tâche est définie comme une séquence d activités primitives qui peuvent être représentées sans utiliser des activités 49

64 Chapitre III concurrentes. Une tâche est représentée en utilisant une grammaire régulière. Dans les expressions régulières des opérateurs représentant des sélections ainsi que des itérations sont utilisés afin de mieux représenter les séquences d activités. Les communications sont représentées par des transferts de messages (chaînes de caractères) asynchrones. La synchronisation des tâches ainsi que le contrôle d autres tâches sont représentés à travers ces communications. Afin d assurer le transfert des données, les mécanismes suivants sont fournis : une tâche peut avoir plusieurs ports pour recevoir et envoyer des données. Pour envoyer des données, la tâche destinataire ainsi que son port doivent être spécifiés. Pour un port d entrée, des opérations sont fournies afin de permettre la lecture des données ainsi que de vérifier si le port est vide. Il y a ainsi trois opérations primitives : send pour envoyer, recv pour lire le premier message du port (reste bloqué si le port est vide) et peek pour inspecter l existence de messages dans un port. Le modèle est implanté par le système Hakoniwa, il offre un support au développement coopératif. Pour un modèle d activités définissant toutes les tâches de développement, il existe un serveur pour la communication et le monitoring des tâches, le Hakoniwa Server, ainsi que des gestionnaires de navigation pour chaque programmeur, nommés task organizers. Un task organizer invoque et contrôle plusieurs moteurs d exécution de tâches (task drivers) instanciées pour chacune d entre elles. Chacun des task drivers contrôle une séquence d activités. Ainsi, les caractéristiques majeures du système sont la navigation, le monitoring et le support à la communication. Navigation. En fonction de la répartition de tâches pour chacun des développeurs (faite par le chef de projet), des task organizers et task drivers sont générés pour chacun des développeurs. Un task driver propose au développeur un menu de sélection pour les prochaines activités. Ces menus sont générés d une manière automatique à partir de la définition de la séquence d activités. Si une des activités implique l utilisation d un outil spécifique, ce dernier va être automatiquement invoqué par le task driver. Monitoring. Chacun des task drivers fournit au Hakoniwa Server des informations liées à l avancement de la tâche à laquelle il est attaché. Ceci est fait en utilisant l historique du menu de sélection. Le chef de projet peut ainsi capturer l état courant du projet entier à travers le Hakoniwa Server. Ce dernier montre l état de chaque tâche, ainsi que l historique des activités pour chacun des développeurs. Support à la communication. Toutes les communications entre les tâches passent à travers Hakoniwa Server. Des primitives simples pour la communication telles que les requêtes d initiation des tâches ou les notifications de fin de tâches sont automatiquement exécutées sans l intervention de l utilisateur. Le système offre ainsi la collection automatique des données et une vision globale du projet. Cette vision est importante dans l environnement pour lequel le système a été conçu, à savoir un environnement coopératif distribué. Aucune analyse n est fournie. Le monitoring reste à l état d observation du processus. L intégration dans un EGLCP est ici totale, le système de monitoring ne peut pas en être dissocié. III.3.5 BALBOA BALBOA a été construit à l Université de Colorado, Boulder [Cook et Wolf 1997, Cook et Wolf 1998b], son but étant de faciliter la collection et la gestion des données ainsi que la construction des outils d analyse. Il constitue un cadre qui fourni aux méthodes de collection des mécanismes flexibles pour l enregistrement des données et fournit aux outils un ensemble cohérent de services de manipulations, de gestion et d accès des données. 50

65 L état de l art Dans leur grande majorité, les données gérées par BALBOA sont contenues dans des événements. Les événements sont définis comme des actions instantanées identifiables, telles que le lancement d un outil [Wolf et Rosemblum 1993]. Nous allons ainsi appeler les données collectées des données événement. BALBOA est un cadre client-serveur (voir la Figure III.10). Processus en exécution Outils de Collection Interface Balboa Outils de Gestion Interface Balboa Données événement Balboa Server Données événement Méta-données événement Interface Balboa Types d événements Attributs Tokens Outils Client Le serveur possède trois canaux d accès : Figure III.13 Le cadre BALBOA vision globale une interface pour la collection des données qui permet aux outils spécifiques aux sites du processus de soumettre des données événements au serveur ; une interface pour la gestion des données qui permet aux outils de gestion de gérer les données ainsi que de créer des méta-données événement qui décrivent les données événement ; une interface aux outils d analyse clients qui permet à ces derniers d accéder d une manière cohérente aux données événement. Ces interfaces sont constituées de messages qui sont échangés entre les clients et le serveur. BALBOA offre un support supplémentaire aux clients afin de permettre l accès aux données, sous la forme de librairies spécifiques. Les outils d analyse n accèdent pas aux données brutes, mais aux données interprétées : des types d événements, d attributs, valeurs ainsi que des tokens (types d événements mis en correspondance avec des entiers). La manière dont se fait l interprétation, est spécifiée par les méta-données que le gestionnaire de données permet de créer. Cette interprétation libère les outils d analyse de la prise en compte des formats spécifiques de données, et permet aux constructeurs d outils d analyse de se concentrer sur les méthodes d analyse plutôt que sur la gestion des données. 51

66 Chapitre III BALBOA contient aussi un ensemble d outils de gestion qui utilisent l interface de gestion afin de fournir des fonctionnalités fondamentales pour la gestion en BALBOA. L interface et les messages. BALBOA utilise des sockets TCP comme couche de communication. Les messages sont bi-directionels. BALBOA offre un support pour deux types de processus et d outils d analyse : des processus qui enregistrent leurs événements afin que ces derniers soient utilisés pour une analyse ultérieure (après que le processus soit terminé) ou bien des processus qui envoient des événements au serveur afin qu ils soient analysés pendant l exécution du processus. Dans le premier cas, une fois le processus terminé, les données forment une collection d événements et les outils d analyse sont des outils à posteriori. En ce qui concerne la deuxième classe de processus, des mécanismes sont fournis pour la collection des événements en ligne. Cependant, aucun outil d analyse pour l analyse de ces événements n est fourni. Spécification de l interprétation d événements. Les événements bruts sont interprétés afin d extraire le type d événement ou des valeurs d attributs. Le mécanisme d interprétation est basé sur des expressions régulières et les valeurs d attributs. Pour un flot d événements, un ensemble ordonné d expressions régulières est spécifié, afin de décrire les événements du flot. Chacun des événements doit correspondre à au moins une expression régulière. L interprétation peut aussi prendre en compte des versions codées des types d événements, nommé tokens (un entier associé à un type). La bibliothèque API pour les clients. Les outils d analyse (clients) n ont pas besoin d accéder à des messages bruts. Des bibliothèques spécifiques aux différents types de clients sont fournies afin de permettre l accès de certains clients aux données. BALBOA fournit des APIs pour des clients écrits en C++ et en TclTk. Dans le cas du C++, par exemple, des objets sont créés du côté client, ils se connectent au serveur afin de sélectionner les données spécifiées. Ainsi, deux types d objets peuvent être crées : EventServer et TokenServer. Le type d objet EventServer possède des méthodes qui permettent de récupérer aussi bien des événements que des patterns d événements. Le type TokenServer est un sous-type de EventServer qui permet d accéder à la forme tokens des types d événements. Les outils de gestion. Quatre outils sont fournis afin de faciliter la gestion des données et des interactions avec l utilisateur en BALBOA : LAUNCHPAD agit comme le point central d exécution pour d autres outils de gestion ou d analyse. Il est un outil orienté-bouton qui permet le lancement des autres outils. Il est extensible : des outils d analyse peuvent être ajoutés. COLLECTIONMANAGER permet aux utilisateurs de créer, de modifier et d effacer des collections d événements dans le serveur. EVENTMAPPER permet la création et la modification des spécifications pour l interprétation d événements. COLLECTIONVIEWER permet la visualisation et la navigation des collections d événements, l interprétation étant optionnelle. BALBOA propose aussi des outils d analyse orientés processus, tels que la découverte du processus et la validation du processus. La découverte du processus [Cook et Wolf 1995] utilise les données d événement afin de générer un modèle formel du processus. Elle analyse des flots d événements collectés depuis des exécutions de processus afin d inférer des machines d état non-déterministes correspondant aux patterns comportementaux. La méthode est fondée sur des travaux liés aux inférences de grammaires et utilise des séquences de tokens. 52

67 L état de l art La validation du processus [Cook et Wolf 1994, Cook et Wolf 1997] mesure la correspondance entre l exécution observée du processus et son modèle formel. Le modèle ainsi que l exécution du processus sont vus comme des flots d événements. Trois métriques ont été développées afin de mesurer cette correspondance. La première est une simple vérification qui retourne «vrai» si les deux flots sont identiques et «faux» dans le cas contraire. La deuxième et la troisième métrique quantifient la déviation, en retournant une valeur numérique correspondant à la «taille» de la déviation. La deuxième, une métrique linéaire de distance, prend en compte le nombre d insertions et de suppressions qui devraient être appliquées aux flots d exécution afin d obtenir le flot modèle. Des poids sont associés aussi bien aux insertions qu aux suppressions, les deux opérations étant considérées comme ayant un impact différent. La troisième est une métrique non-linéaire de distance. Elle étend la métrique linéaire par la prise en compte des groupements des insertions et suppressions. Ainsi, il est considéré que si les insertions ou les suppressions sont groupées, il s agit d une déviation plus importante. De cette manière la taille des groupements est prise en compte. Pour conclure, BALBOA offre un support pour mettre ensemble des outils qui font des collections de données et des outils d analyse. BALBOA permet de spécifier les données qui doivent être collectées ainsi leur interprétation (association d un type à une donnée). Les données sont représentées à travers des événements. La spécification de l interprétation des événements, vue comme des chaînes de caractères, est donnée par l utilisateur sous la forme des expressions régulières. Les données incertaines ne sont pas prises en compte. BALBOA offre des outils d analyse orientés processus. Les techniques d analyse proposées font la comparaison avec un modèle formel (la validation du processus). Les analyses proposées sont à posteriori. Parmi les systèmes étudiés, BALBOA est le seul qui propose des analyses qui font la comparaison avec un modèle de processus. Son architecture est très flexible et permet l intégration de nouveaux outils d analyse. Même si BALBOA offre le support pour faire la collection des données en ligne, aucun outil permettant l analyse des données en ligne n est fourni. III.3.6 Méthode pour l analyse des données historiques Dans le contexte du système Balboa une méthode a été proposée afin d analyser les données historiques des processus pour des cas dans lesquels un système de collection et d analyse ne peut pas être mis en place pour des processus en cours d exécution [Cook et al. 1998]. Cette méthode est issue d une étude de cas menée afin de trouver si les données gardées par des entreprises ne peuvent pas être utilisées pour trouver les facteurs déterminants dans l échec ou le succès des processus utilisés par l'entreprise. En fait, l étude de cas est basée sur la supposition suivante : en analysant ces données, des relations intéressantes entre différents aspects (propriétés) du processus pourront être découvertes permettant ainsi une meilleure compréhension du processus. La méthode propose six étapes : 1. Comprendre l entreprise, les projets et les processus. 2. Identifier les sources de données possibles qui peuvent être très variées. 3. Identifier des métriques pour le succès des projets (et de processus). Cela revient à trouver les aspects du projet ou processus corrélés avec le fait que le projet soit considéré 53

68 Chapitre III comme un succès (par exemple densité des défauts, satisfaction du client, vitesse ou efficacité du projet, etc. ). 4. Identifier des métriques pouvant s appliquer aux sources des données. 5. Extraire les données et faire des analyses. L extraction des données implique normalement l écriture des scripts qui accèdent aux sources de données, qui mettent en forme et intègrent les données. L analyse implique l utilisation des outils d analyse. 6. Interpréter les résultats. Chaque résultat doit être interprété dans le contexte du projet et de l entreprise. La méthode a été appliquée afin d examiner des données historiques concernant un processus de changement de logiciel. Ce processus est répété chaque fois qu il y a une demande de changement de la part d un client. La métrique de succès considérée est l acceptation du changement de la part du client. Les métriques sur les données existantes peuvent être groupées en trois catégories : orientées produit (combien de lignes sources changées, combien de fichiers sources changés), orientées processus (temps total d exécution, délais internes, programmeurs impliqués) et orientées comportement du processus (en quelle mesure l exécution a suivi le modèle 33 ). Deux populations ont été établies : une population contenant les exécutions du changement avec succès, et une autre population contenant les exécutions du processus avec échec. L interprétation des résultats des analyses indique le fait que deux métriques se corrèlent avec des défauts (réjections de la part du client) : le délai entre l apparition du rapport de problème de la part du client et le commencement de l activité de changement ainsi que la personne en charge de changement. Concernant les métriques sur le comportement, une corrélation claire a été établie entre le succès du changement et la mesure dont le modèle de processus a été suivi au moment de l exécution (la validation de processus proposé dans le système Balboa a été utilisée). Dans la population contenant les changements avec succès, les déviations mesurées avec la métrique non-linéaire de distance (qui prend en compte les tailles de blocs de déviation) sont, d une manière significative, moins importantes que dans la population contenant les rejets, où des grands blocs de déviation par rapport au modèle ont été constatés. III.3.7 Expérimentation de prototypage du monitoring Une expérimentation de prototypage 34 a été menée à AT&T Bell Laboratories [Bradac et al. 1994] afin d instrumenter une expérimentation de monitoring ayant pour but la réduction du temps de développement. Le but du prototype est de trouver les variables pertinentes pour la réduction du temps de développement, car le temps, tout comme le coût, est considéré comme un facteur d optimisation dans l amélioration du processus. L étude est très orientée vers ce que les personnes impliquées dans un processus logiciel font réellement, et non pas vers ce qu elles sont sensées faire, ou encore vers ce qu elles aimeraient faire. Le processus étudié concerne l ajout d une nouvelle fonctionnalité à un produit logiciel. La collection des données est faite par le système qui interroge les agents du processus sur la manière dont ils se sont organisés. La collection des données se fait une fois par jour, en début de journée, quand les agents fournissent des informations concernant la manière dont ils se sont organisés pendant la journée précédente. Ce rythme de collection est adopté afin de réduire l impact de l expérimentation sur le processus de développement. 33 Le modèle dans ce cas est représenté par ce que l organisation indique comme «comportement idéal». 34 La terminologie anglophone est «Monitoring Experiment Prototype» 54

69 L état de l art Le processus de collection des données est le suivant : le système présente à l utilisateur un menu de tâches. Dès qu une tâche est sélectionnée, l outil présente un menu d états possibles pour la tâche concernée. L utilisateur sélectionne la plus appropriée. L outil fournit aussi la catégorie «autre», aussi bien pour les tâches que pour les états. Si cette catégorie est choisie, l outil demande une description textuelle afin de clarifier ce qui a été fait ou la manière dont la personne a été bloquée. Ce mécanisme permet d étendre l ensemble des catégories proposées si la catégorie «autre» devient trop importante. Les mécanismes basiques dans l expérimentation sont : le système de courrier électronique pour rappeler aux agents du processus de fournir les tâches de la journée précédente ainsi que l avancement de ces tâches ; un outil basé-menu qui permet de faire l acquisition des données ; une base de données en-ligne qui permet d accumuler les données fournies par les différents utilisateurs et sur laquelle des requêtes peuvent être émises. Les analyses sont statistiques et font référence au temps passé pour les différentes tâches dans les différents états. Les tâches et les états considérés sont présentés dans le Tableau III.1. Tâches Non assignée Estimation et investigation Développement du plan Besoins Conception niveau haut Conception niveau bas Ecriture des plans de tests Codage Inspection Tests de niveau haut Tests de niveau bas Documentation pour les clients Support A posteriori Fin de semaine Etats Travail sur le processus Documentation Retravailler le processus Retravailler la documentation Attente du laboratoire Attente d un expert Attente d une inspection Attente du matériel Attente du logiciel Attente de la documentation Non-travail : Formation Non-travail : autre tâche à faire Non-travail : vacances et jours fériées Non-travail : fin de semaine Autre Tableau III.1 Taches et états considérés dans l'expérimentation Les états considérés sont ainsi groupés en trois catégories : travailler, bloqué ou ne pas travailler. Le temps passé dans chacun de ces états est mesuré pour les tâches et les développeurs considérés. Les analyses statistiques qui ont été faites sur les données acquises portent sur : la distribution des tâches et des états dans le temps, le niveau de blocage pour chaque tâche, la répartition du travail, le «retravail» nécessaire pour chaque tâche, etc. Les résultats de ces analyses statistiques montrent que les agents du processus passent plus de temps en train d être bloqués» qu en train de travailler. Ainsi, plus de 60% du temps a été dépensé en attente plutôt qu en production. Ceci implique qu une manière de réduire le temps de développement est de réduire le temps d attente. Une autre observation est que le blocage apparaît plus souvent au début ainsi qu à la fin du processus. Le milieu du processus (conception niveau bas, planification des tests, codage) n a pas tendance à être dans l état «en attente». Cette expérimentation montre une manière intéressante de faire des analyses statistiques sur les processus après leur exécution. 55

70 Chapitre III III.3.8 Software Management Environment Le Software Management Environment (SME) [Decker et Valett 1989, Hendrick et al 1994] a été développé par le Software Engineering Laboratory (SEL) qui est un organisme sponsorisé par le National Aeronautics and Space Administration/ Goddard Space Flight Center (NASA/GSFC). Le SME utilise l expérience de l entreprise pour des buts de gestion et d analyse. Il contient l expérience (par exemple données, résultats de recherche et connaissances de gestion) obtenue dans des projets de développement précédents. Il est conçu afin d assister les gestionnaires des projets en cours dans leurs activités de planification et gestion. Base de données du SEL données de projets précédents estimations de produit Données courantes caractéristiques du projet données d erreurs du projet SME Estimations taille finale du système taux d erreurs estimé Analyse taux d erreurs plus petit car : test insuffisant, équipe expérimentée, problèmes mois difficiles que attendues Modèles et Mesures profiles des mise en œuvres précédentes définitions des paramètres clés modèles et relations Base des règles Règles liées au développement de logiciel problèmes et caractéristiques de projet règles pour l évaluation de la qualité Evaluation fiabilité en bas du normal, maintenance normale, qualité supérieure Figure III.14 L architecture et l utilisation de SME Le SME fournit des fonctionnalités graphiques permettant aux managers : de prédire certaines caractéristiques telles que le coût ; de tracer des paramètres de projet ; de comparer les valeurs des paramètres avec les valeurs correspondantes dans des projets précédents ; d analyser les différences entre le comportement attendu (donné par les projets précédents) et le comportement réel pour diverses caractéristiques. L architecture ainsi que l utilisation du SME sont données dans la Figure III.11. La collection des données historiques a été faite pendant plus de 20 ans, aussi bien manuellement qu automatiquement. Parmi les données collectées manuellement il y a des données concernant l effort (temps passé par les programmeurs dans diverses tâches codage, test, etc.), les erreurs (ou changements ainsi que l effort pour trouver l erreur, la conception et le codage du changement nécessaire) ainsi que les faits objectifs ou subjectifs sur le projet (date de début, date de fin, objectifs et attributs du projet, le fait que les objectifs ont été atteints, etc.). Les données collectées automatiquement incluent l utilisation des ordinateurs et l analyse statique des programmes (calculs de ligne de code ainsi que des modules). 56

71 L état de l art Les données collectées manuellement sont généralement introduites dans le système, dans un délai de deux à trois semaines après leur collection. La connaissance accumulée est gardée sous la forme de modèles de mesure afin de permettre une analyse plus facile des données collectées. Les données collectées sont en fait utilisées pour la construction de modèles, plus précisément la détermination de patterns d information sous-jacents présents dans la collection de données. La collection de données se fait à des intervalles réguliers. Le temps est décrit en terme de quatre phases majeures dans le développement de logiciel (en utilisant le modèle en cascade [Boehm 1981]) : conception, codage et test de modules, test du système, test d acceptation. Le comportement d une mesure est décrit en fonction des pourcentages de complétude à chaque point de mesure. Les modèles de mesure sont représentés à l aide d un vecteur de 15 points, chaque point contenant un pourcentage de complétude dans le cycle de développement. Dans ce contexte, un pattern de mesure est un vecteur qui contient les valeurs d une mesure relevées dans un projet. Un modèle de mesure 35 est un vecteur qui représente un ensemble de projets (généralement il contient les moyennes des mesures). SME décide du modèle de mesure qui devra être utilisé pour un projet en se basant sur les caractéristiques du projet. Une méthode basée sur des analyses des clusters a été proposée afin de décider du modèle à utiliser [Li et Zelkowitz 1993]. Dans cette méthode les patterns des mesures sont groupés dans des clusters en utilisant une distance euclidienne. Les modèles de mesures sont construits pour chacun des clusters donnés. Un autre changement introduit par cette nouvelle méthode est le fait que les clusters soient formés pour chaque mesure, et non pas pour les projets dans leur globalité (tel est le cas dans le groupement par caractéristiques). Pour chaque mesure une base de connaissance contenant des relations cause-effet est maintenue, ce qui permet d expliquer le comportement inattendu d une certaine mesure. Le SME est ainsi un outil pour l utilisation des données historiques dans la gestion et l analyse des projets. En fait, les efforts du SEL dans le domaine de la prise de mesures sont assez importants, une présentation des principes pour la mise en place des systèmes de mesure étant disponible sous la forme d un guide, notamment le Software Measurement Guidebook [SELS 1995]. Ce guide présente des informations sur l importance ainsi que le but de la prise de mesure dans les processus logiciels. Il présente des procédures et des activités spécifiques dans un programme de mesure ainsi que les rôles des personnes impliquées. Le guide clarifie aussi le rôle qu un programme de mesure peut et doit jouer dans une démarche d amélioration de processus logiciel. III.3.9 WebME WebME (Web Measurement Environment) a été développé à l Université de Maryland [Tesoriero et Zelokowitz 1997] afin de faciliter la compréhension des données collectées dans un environnement distribué. WebME fournit les mêmes fonctionnalités basiques que le SME [Decker et Valett 1989, Hendrick et al 1994] mais il permet l échange d informations dans un environnement distribué coopératif. WebME aide les programmeurs dans l accès à des données de développement situées dans différents endroits. WebME a une architecture avec médiateur (voir Figure III.12), organisée sur trois niveaux : applications utilisateur, serveur médiateur d information et répertoires d information. Les répertoires d information sont les bases de données distribuées contenant des données génie logiciel. 35 Nous utilisons le terme modèle, proposé par les auteurs, mais ces modèles ne sont que des patterns de mesure génériques 57

72 Chapitre III APPLICATION UTILISATEUR Web Browser SERVEUR MEDIATEUR D INFORMATION Processeur des requêtes webme Data REPERTOIRES D INFORMATION Data Wrapper Data Wrapper Data Wrapper Data Data Data Figure III.15 Architecture du système WebME Les data wrappers 36 décrivent l interface entre les répertoires d information et le serveur médiateur (webme). Un navigateur web avec des pages HTML associées forme l application «utilisateur». Le médiateur webme est responsable de l acquisition et de la transformation des données afin de répondre aux requêtes utilisateur. Un langage de scripts a été défini pour la description des architectures possibles (quelles sources de données utiliser) ainsi que pour la spécification des données (quels données considérer). Ce langage permet à des experts de créer des définitions d interfaces et des types de mesures (attributs) à utiliser par le système. Le fichier script est en suite transformé dans des classes de mesures et de définitions d interfaces accessibles par le médiateur WebME. Fichiers des données externes Data Wrapper paires intervalle-valeur requête résultat webme (médiateur) requête Définitions des classes WebME Processeur des requêtes requête réponse Figure III.16 L utilisations des définition des classes et des interfaces en WebME 36 Ce terme pourrait être traduit par «enveloppeur» des données. 58

73 L état de l art Quand l utilisateur du système fait une requête, le médiateur utilise les définitions des classes et des interfaces pour l acquisition et l analyse des données. Ce processus est décrit dans la Figure III.13. Définition des classes. Chaque classe contient des entités qui possèdent des attributs. Les attributs peuvent être directs ou indirects [Kitchenham et al. 1995]. Un attribut direct en WebME est un attribut pour lequel la valeur peut être extraite directement depuis une base de données. Un attribut indirect prend sa valeur depuis des transformations appliquées à d autres attributs. Un attribut a des valeurs et une unité, cette dernière ayant un intervalle associé (par exemple hebdomadaire, mensuel). Un instrument de mesure utilise les unités et les intervalles afin de fournir une valeur correcte pour chacun des attributs. L instrument de mesure est un exécutable pour les attributs directs et une équation pour les attributs indirects. Des opérateurs arithmétiques «+», «-», «*», «/» s appliquent à des attributs compatibles. Deux attributs sont compatibles s ils ont les mêmes unités et intervalles (équivalence au niveau du nom). Nous retrouvons en WebME, comme en SME, les constructions des modèles d information 37. WebME considère des données brutes non-cumulatives, c'est-à-dire des données avec des fortes variations et pour lesquelles il est plus difficile de trouver des tendances. La construction des modèles en WebME est inspirée des modèles utilisés dans des transactions financières, modèles fondés sur la convergence et divergence des moyennes 38 [Appel et Hitschler 1980]. La similarité est que WebME aussi détermine des tendances majeures dans les données, en ignorant les variations mineures. L algorithme a comme but de trouver une courbe caractéristique à partir des données brutes. Il contient trois étapes : utiliser une technique de lissage afin d obtenir le comportement approximatif des données ; déterminer les points extrêmes qui représentent des événements importants dans le processus (les points pivots) ; les autres maximums et minimums locaux sont considérés comme des perturbations mineures et sont ignorées ; connecter les points pivots dans une ligne segmentée qui représente la courbe caractéristique. Tout comme SME, WebME offre la possibilité de comparer les données des projets en cours avec les modèles construits à partir des données des projets précédents, donnant ainsi la possibilité de faire des estimations et des prédictions. III.3.10 Tempo+ Tempo+ [Mihoubi et Belkhatir 1997, Mihoubi 1998] se situe dans le cadre des travaux effectués à l Université de Grenoble (équipe Adele) sur les environnements de génie logiciel. Tempo+ est une extension de l environnement de génie logiciel centré processus Tempo [Melo 1993]. Il offre des mécanismes nécessaires pour permettre l observation des états d un processus et permettre l examen à posteriori des traces qui auront pu être établies. L état du processus est vu comme l image de l état de l exécution du processus. Les traces sont personnalisables, l utilisateur pouvant définir les vues qui lui sont nécessaires. Les vues d observation permettent le suivi des transitions de l état du processus. Elles informent les utilisateurs sur le déroulement de l exécution en partie ou dans sa globalité et 37 A nouveau ce terme correspond à des patterns de comportement. 38 La terminologie anglophone est «Moving Average Convergence/Divergence» ; ce modèle détermine quand les changements de longue duré diffère des changements à courte duré, ce qui indique un décision de vendre ou bien acheter 59

74 Chapitre III constituent un cadre de travail dans lequel un observateur peut surveiller l exécution des processus. Elles n ont aucun effet sur le déroulement de l exécution. Elles sont destinées à fournir une représentation externe de l état courant d un processus. Tempo+ permet de définir dynamiquement des vues d observation sur des processus en exécution à la demande des utilisateurs. La réalisation de ces traces est faite sur la base des données Adèle [Estublier et al. 1992]. L objectif est de faciliter et d automatiser la description des modèles de traces. Tempo+ fournit : Un langage des requêtes qui permet à des utilisateurs de définir en terme d attributs les informations de l état à observer et permet de générer la partie statique des modèles de traces. Des règles génériques qui permettent l instanciation de la partie dynamique des modèles de traces. Des primitives pour la manipulation des vues. Il est ainsi possible d instancier des modèles de traces, d activer des vues, de supprimer des vues, etc. L environnement de la mise en œuvre des vues d observation est composé de deux outils : Le constructeur pour la génération des modèles de traces. La génération d un modèle de trace nécessite une requête de création, le modèle de processus et les règles génériques. Le serveur de suivi pour la mise à jour du processus d observation. Il permet d intégrer dynamiquement des vues d observation dans l environnement Tempo+. Il est basé sur le paradigme d envoi de message et étendu au concept d abonnement. Il capture des messages et notifie les vues d observations. Aucun support n est fourni pour l analyse des traces. La définition des vues repose sur un ensemble prédéfini d événements de suivi, les vues étant définies par un sous-ensemble de l ensemble défini. La syntaxe et la sémantique du langage ne sont pas formalisées. III.3.11 Caractéristiques des systèmes tableau récapitulatif Nous allons dans cette section proposer un tableau qui récapitule le but et les caractéristiques de chacun des systèmes présentés dans cette section. Système 60 But, caractéristiques TAME Construit à l Université de Maryland [Basili et Rombach 1987, Basili et Rombach 1988] but : offrir un support effectif à la modélisation des processus logiciels orientés amélioration ; deux aspects : le modèle de processus TAME et le système TAME qui l implante ; intègre les aspects constructifs et analytiques du processus logiciel ; est basé sur le QIP comme principe de fonctionnement et sur le GQM en tant qu outil d analyse ; contrôle et améliore le projet en s appuyant sur des analyses quantitatives ; utilise une base d expérience comme support pour l apprentissage et la réutilisation des expériences dans des futurs projets ; utilise des données collectées par lui-même ; n intègre pas d autres outils d analyse. Amadeus Un système de monitoring, d analyse et de rétroaction [Selby et al. 1991] développé a l Université de California, Irvine intégré dans le EGLCP Arcadia ; fournit des mécanismes pour la prise de mesure et la rétroaction empiriques ;

75 L état de l art BALBOA Méthode pour l analyse des données historiques Hakoniwa définit des mécanismes liés à l architecture des environnements afin de permettre le guidage empirique des processus logiciels (développement et maintenance) ; fournit un cadre extensible pour l intégration des techniques d analyses empiriques ; le processus peut être instrumenté d une manière statique avec des collections des données et des scripts pour l analyse ; le processus est influencé par les résultats des analyses faites sur des données collectées ; ainsi le guidage et la rétroaction sont implantés ; offre la séparation entre la spécification des données à collecter et celle des agents qui gère les données ; fournit un système pour l'enregistrement des événements de processus ainsi que le déclenchement des actions à l occurrence des événements spécifiés ; fournit un langage de script qui englobe des mécanismes d environnement pour l interprétation statique et dynamique des événements de processus, de changements d état d objets, d événements liés au calendrier (abstractions temporelles) Développé à l Université de Colorado Boulder [Cook et Wolf 1997, Cook et Wolf 1998b] but : faciliter la collection et la gestion des données ainsi que la construction des outils d analyse ; utilise des données basées-événement ; propose une architecture client-serveur ; des outils de collection enregistrent des données concernant des exécutions des processus auprès du serveur sous la forme de collections d événements ; des interprétations spécifiées par l utilisateur sont appliquées aux événements; les outils d analyses peuvent accéder aux collections d événements afin de faire des analyses (des API spécifiques sont mises à disposition) ; offre des outils de gestion pour des données et des interactions avec les utilisateurs ; propose deux outils d analyse de processus : découverte de processus et validation de processus ; permet l intégration d autres outils d analyse. Une méthode proposée par [Cook et al. 1998] pour explorer des données historiques dans des entreprises, pour lesquelles mettre en place une instrumentation n est pas possible et pour lesquelles des données historiques sur les produits ainsi que les processus existent, afin de trouver des relations entre le succès ou l échec des projets et des différents aspects du processus hypothèse : les données existantes contiennent des relations significatives qui révéleront des choses intéressantes sur le processus ; étude de cas : processus de changement d un produit logiciel ; les résultats montrent une corrélation entre le succès d un projet et le degré dont le modèle de processus a été suivi ; une corrélation a été établie entre le succès du projet et deux autres aspects : le délai entre l apparition du rapport de problème de la part du client et le commencement de l activité de changement ainsi que le programmeur qui réalise le changement. Construit au Japon [Iida et al ], donne un modèle pour le développement des logiciels par un groupe de développeurs ainsi qu un système qui l implante but fournir un support pour la communication et le monitoring dans les processus de développement coopératif distribués ; la modélisation est orientée activité ; plusieurs développeurs exécute des tâches en parallèle ; les développeurs sont aidés par des task organizers et des task drivers ; la communication se fait à travers Hakoniwa server, qui assure aussi le monitoring du processus (l avancement des différentes tâches avec différentes 61

76 Chapitre III Expérimentation de prototypage de monitoring 62 données telles que le début et la fin d activités, le nombre de répétitions d une activité, etc.). Menée à AT&T en vue d instrumenter un expérimentation de monitoring ayant pour but la réduction du temps de développement [Bradac et al. 1994] but : trouver les variables pertinentes pour la réduction du temps de développement ; processus étudié : l ajout d une nouvelle fonctionnalité à un produit logiciel ; les données collectées : le temps passé dans différentes tâches du processus et dans différents états (travailler, attendre, ne pas travailler) ; les analyses sont statistiques et font référence à la distribution des tâches et des états dans le temps, au niveau de blocage pour chaque tâche, etc. SME Software Management Environment [Decker et Valett 1989, Hendrick et al 1994, Li et Zelkowitz 1993, SEL 1995] développé par le Software Engineering Laboratory (NASA/GSFC) but : offrir un support pour l utilisation des données historiques des projets précédants dans la gestion et l analyse des projets en cours ; la base contient des données concernant 20 années d expériences dans le développement des logiciels chez NASA/GSFC ; la collection des données se fait aussi bien manuellement qu automatiquement ; à partir des données, des modèles d information sont construits pour chaque mesure (effort, lignes de code) concernant leur évolution dans le temps ; pour un projet un modèle est choisi est utilisé dans la prédiction du comportement du projet pour une certaine mesure ; une base de connaissance contenant des relations cause-effet est liée à chaque mesure permettant l analyse du projet quand les valeurs des mesures sont éloignées des valeurs indiquées par le modèle. WebME Tempo+ Le Web Measurement Environment [Tesoriero et Zelkowitz 1997] a été développé à l Université de Maryland et constitue une extension du SME proposé par le SEL [Decker et Valett 1989, Hendrick et al 1994] pour une utilisation dans des environnements distribués ; fournit le même fonctionnement basique que SME, mais permet le changement des données dans un environnement distribué et coopératif ; possède une architecture avec médiateur ; possède un langage de scripts pour la définition de configuration des architectures (quelles sources de données utiliser) ainsi que la définition des données ; tout comme SME, il permet la construction des modèles sous-jacents aux données collectées ; WebME considère des données non-cumulatives, très variables, ce qui fait que les tendances sont moins évidentes ; l algorithme utilisé dans la construction des modèles est basé sur des modèles financière utilisés pour la gestion des stocks d actions. Tempo+ [Mihoubi et Belkhatir 1997, Mihoubi 1998] a été développé à l Université de Grenoble. Il est une extension de l EGLCP Tempo [Melo 1993]. Il contient une partie dédiée à l observation du processus, qui fournit : un langage de requêtes pour la description des modèles de traces (partie statique) ; des règles génériques permettent pour l instanciation de la partie dynamique des modèles des traces ; des primitives pour manipuler les vues ; un constructeur pour la génération des modèles de traces ; un serveur de suivi pour la mise à jour du processus d observation ; intégré dans un EGLCP ; aucun support pour les analyses. Tableau III.2 Caractéristiques des systèmes

77 III.3.12 Bilan sur les systèmes étudiés L état de l art Nous allons, dans cette section, faire un bilan sur les systèmes étudiés à travers la manière dont ils sont positionnés par rapport aux critères que nous avons énoncés dans la section III.2.1. Nous allons commencer par positionner les systèmes par rapport à leur buts (même si cet aspect n est pas un critère d évaluation) ainsi que l objet de leur mesure (voir le tableau III.3). Système But Objet de la mesure TAME offrir un support effectif à la modélisation des processus logiciels orientés amélioration Amadeus Hakoniwa BALBOA Méthode pour l analyse des données historiques Expérimentation de prototypage de monitoring SME WebME Tempo+ fournir des mécanismes pour la prise de mesure et la rétroaction empiriques fournir un support pour la communication et le monitoring dans les processus de développement coopératif distribués faciliter la collection et la gestion des données ainsi que la construction des outils d analyse explorer des données historiques des entreprises afin de trouver des relations entre le succès ou l échec des projets et les différents aspects du processus trouver les variables pertinentes pour la réduction du temps de développement offrir un support pour l utilisation des données historiques des projets précédants dans la gestion et l analyse des projets en cours fournir les mêmes fonctionnalités que SME, mais dans des environnements distribués à travers Internet fournir des mécanismes pour l observation des processus logiciels dans un EGLCP produit et processus (dans le GQM il existe des questions liées aussi bien aux produits qu aux processus) possibilité pour des mesures sur des produits et des processus, mais elles sont orientées plutôt produit processus métriques : date de début et fin d activités, nombre de répétitions d une activité processus et produit produit et processus métriques : lignes (fichiers) source changées, temps total d exécution, délais internes, programmeurs impliqués processus : temps passé dans différentes tâches et états produit et processus produit et processus produit et processus Tableau III.3 Les systèmes à travers leurs motivations Nous pouvons observer que les motivations qui ont animé la construction de ces systèmes sont très variées. L objet de la mesure est soit le produit, soit le processus, soit les deux à la fois. Le Tableau III.4 propose une comparaison des systèmes par rapport aux critères liés aux données et à la prise de mesure, notamment la nature des données (données actuelles ou bien données historiques), la manière dont la collection s effectue (automatique, semi-automatique ou manuelle) ainsi que l existence de la prise en compte des données imprécises (inexistante, partielle ou bien explicite). 63

78 Chapitre III Système TAME Amadeus 64 Nature des données sur lesquelles le système travaille données actuelles données historiques : à travers la base d expérience, implicitement dans les modèles GQM données actuelles données historiques : implicitement à travers l expérience contenue dans les arbres de classification La collection des données automatique : utilise un planificateur pour la prise de mesure (n est pas implanté, la collection des données est déclenchée par l utilisateur) Automatique : possibilité de spécifier les données qui doivent être collectées Hakoniwa données actuelles automatique : les task drivers envoient l information au Hakoniwa server, où elle est utilisée pour une vision globale du processus BALBOA Méthode pour l analyse des données historiques Expérimentation de prototypage de monitoring SME données actuelles données historiques : gardées sous la forme de collections d événements données historiques uniquement données actuelles données historiques données actuelles données historiques : les données de plusieurs projets sont contenues dans une base automatique : possibilité de spécifier les données qui doivent être collectées automatique : avec des scripts, à partir des sources existantes (fichier, bases des données, etc.) semi-automatique : chaque matin, les agents du processus doivent fournir des données sur leur journée précédente manuellement semi-automatique automatique WebME pareil que SME pareil que SME pour la construction des répertoires de données ; le médiateur récupère en suite automatiquement les données, suite aux spécifications faites par les utilisateurs Tempo+ données actuelles données historiques automatique Prise en compte des données imprécises inexistante inexistante inexistante inexistante inexistante partielle : l espacement de la mesure (données incomplètes) inexistante inexistante inexistante Tableau III.4 Les systèmes à travers des critères liés aux données et à leur collection Nous remarquons que dans la plupart des systèmes, la prise en compte des données imprécises ou incertaines est inexistante. Dans un seul cas nous retrouvons la prise en compte partielle de données imprécises : dans l expérimentation de prototypage de monitoring à travers l espacement des prises de mesure. Aucun système n offre la possibilité de représenter les données incertaines ou imprécises d une manière explicite qui tient compte de leur nature. Nous allons par la suite comparer les systèmes à travers les analyses qu ils fournissent (Tableau III.5). Les critères considérés font référence aux types d analyses employées, au fait que les analyses font référence ou non à un modèle ainsi qu au moment où le résultat des analyses est fourni (en ligne ou bien à posteriori).

79 L état de l art Système Types d analyses Comparaison avec un modèle Résultat en ligne ou à posteriori TAME GQM (dépend des métriques utilisées) ; l interprétation n est pas automatisée, mais les systèmes experts sont envisageables ainsi que les analyses statistiques inexistante devrait être fourni à travers un générateur de rapports (en ligne aussi bien qu à posteriori) qui donnerait des données statistiques (non implanté) Amadeus arbres de classification inexistante en ligne analyses d interconnexion Hakoniwa aucune analyse aucune analyse aucune analyse BALBOA statistiques découverte de processus, validation de processus existante : avec un modèle de processus à posteriori : pour les méthodes proposées en ligne : supporté Méthode pour l analyse des données historiques Expérimentation de prototypage SME WebME de même que Balboa, plus corrélations entre les différents aspects du processus statistiques :distributions des tâches et des états dans le temps, etc. constructions des modèles de métrique en utilisant des moyennes sur des projets précédents (statistiques), comparaisons avec des patterns génériques pour le comportement des mesures de même que SME, mais la construction des patterns se fait en utilisant un autre algorithme de même que BALBOA inexistante existante : comparaison avec le modèle de métrique (patterns générique) de même que SME à posteriori à posteriori à posteriori :construction des patterns génériques en ligne :comparaison des projets en cours avec des patterns de même que SME Tempo+ aucune analyse aucune analyse aucune analyse Tableau III.5 Les systèmes à travers les analyses qu'ils fournissent Nous remarquons que même si les analyses sont très variées, elles sont basées dans leur grande majorité sur des calculs statistiques (ceci est dû en partie à la manière empirique dont les modèles utilisés dans les analyses ont été construits). La comparaison avec un modèle de processus est fournie seulement par BALBOA, qui fait cette comparaison dans la validation de processus (à posteriori). Une dernière comparaison des systèmes donne leur positionnement par rapport à des caractéristiques telles que leur intégration dans un EGLCP (en étant indépendant ou non d un tel environnement), leur caractère évolutif (la possibilité de rajouter des nouvelles techniques d analyse), leur niveau de formalisation (à travers l existence d un langage, par exemple) ou leur niveau d adaptabilité (la possibilité de réglage) (voir Tableau III.6). Système TAME Intégration dans un EGLCP Caractère évolutif Formalisation TAME est un existant mais partielle (il utilise des environnement de génie non automatisé : modèles GQM, mais logiciel intégré ; son des nouveaux ceux-ci ne sont pas intégration avec des modèles GQM suffisamment eglcp est prévue peuvent être formalisés) considérés (des templates et des indications y sont fournies) Mécanismes de réglage non supportés 65

80 Chapitre III Amadeus existante : en Arcadia ; forte interdépendance avec le support de processus (car instrumentation du code de processus) Hakoniwa existante : Hakoniwa est un EGLCP, et son système de monitoring est une partie indivisible BALBOA son intégration est possible sans pour autant qu il y ait des dépendances Méthode pour l analyse des données historiques Expérimentation de prototypage SME WebME Tempo+ ne s applique pas cependant, une communication se fait à travers l extraction des données à l aide des scripts inexistante possible : les données automatiquement collectées peuvent provenir depuis un EGLCP idem que SME pour la construction de répertoires de données Tempo+ est un EGLCP, la partie suivi est intégrée existante automatisé langage de script : instrumente les processus non supportés inexistant inexistante non supportés existante automatisé ne s applique pas partielle à travers les outils de management inexistante non supportés non supportés ne s applique pas inexistante non supportés inexistant aucun non supportés inexistant langage de script : construction des architectures afin de spécifier les données et leur source existante : des nouvelles prises de vues peuvent être définies, mais pas d analyses langage pour la définition des vues non supportés non supportés Tableau III.6 Les systèmes à travers leur adaptabilité, leur formalisation, leur intégration dans un EGLCP et leur caractère évolutif Nous remarquons qu aucun système ne fournit des mécanismes de réglage, alors que de tels mécanismes sont nécessaires afin de maintenir la pertinence du système. La possibilité de rajouter de nouvelles techniques d analyse est fournie par deux systèmes : Amadeus et BALBOA. Ceci est un aspect très important qui permet de faire évoluer le système. Tempo+ permet la définition des vues d observation, mais il n offre aucune analyse. Le niveau de formalisation est faible. Nous retrouvons à deux reprises des langages de script, mais il ne couvre que certains aspects dans leurs systèmes. Dans WebME, il est utilisé pour indiquer les données qui doivent être collectées ainsi que la source de ces données. Amadeus fournit un langage de script qui englobe des mécanismes d environnement pour l interprétation statique et dynamique d événements de processus, des changements d état d objets, d événements liés au calendrier. L intégration d Amadeus avec l EGLCP est cependant très étroite, nécessitant le changement du code de processus. BALBOA offre aussi 66

81 L état de l art un certain niveau de formalisation, à travers ses outils de gestion qui permettent la définition de collections de données par exemple. Ainsi nous remarquons qu aucun des systèmes présentés ne répond à tous les critères proposés, donc aucun ne peut correspondre à la description suivante : utilise un langage afin de permettre la définition des modèles de monitoring ; permet la représentation explicite des données imprécises et gère ce genre des données ; permet de faire des analyses liées à la conformité aux modèles ; est adaptable (fournir des mécanismes pour le réglage) ; est intégrable dans un EGLCP. III.4 Les EGLCP et le problème de l incohérence Dans le chapitre précédent, nous avons introduit le problème de la cohérence ainsi que celui de la déviation entre les trois domaines du processus logiciel : le domaine de la définition, le domaine de l exécution et le domaine de la mise en œuvre. Nous allons présenter dans cette section des EGLCPs qui prennent en compte d une manière ou d une autre ces problèmes. III.4.1 SPADE SPADE (Software Process Analysis, Design and Enactment) est un projet de Politecnico di Milano en association avec le centre de recherche CEFRIEL. SPADE est un EGLCP qui supporte l analyse, la conception, la mise en œuvre et l évolution des processus logiciels [Bandinelli et al. 1992, Bandinelli et al. 1993a, Bandinelli et al. 1994]. L évolution dynamique est assurée par l utilisation d une approche réflexive. SPADE utilise un langage de modélisation de processus nommé SLANG (SPADE Language) [Bandinelli et al. 1991, Bandinelli et al. 1993] basé sur des réseaux ER [Ghezzi et al. 1991], qui sont une extension des réseaux de Pétri permettant de décrire des contraintes sur les «tokens». En SLANG, les artefacts du processus (incluant des modèles de processus) sont modélisés comme des «tokens» dans un réseau ER et sont implantés comme des objets dans une base de données orientée objet. Les transitions des réseaux de Pétri sont associées avec une garde et une action. La garde est une pré-condition qui doit être satisfaite pour permettre le déclenchement de la transition. L action décrit comment le déclenchement de la transition génère des nouvelles valeurs «tokens» dans les places de sortie, en fonction des valeurs des «tokens» trouvés dans les places d entrée. L architecture de SPADE est structurée sur trois niveaux (voir Figure III.14) : le Répertoire 39, l Environnement d Exécution de Processus 40 (PEE), qui incluet le moteur de processus, ainsi qu un Environnement d Interaction avec l Utilisateur (UIE), qui inclut l Interface de Communication de SPADE (SCI). Le Répertoire garde des artefacts du processus aussi bien que des fragments de modèles de processus. Un artefact de processus peut être : tout document ou information créés pendant le processus de développement de logiciel. Le Répertoire est créé sur un système de gestion de bases de données orientées objet, notamment O 2 [O2 1992]. 39 La terminologie anglophone est «Repository» 40 La terminologie anglophone est «Process Enactement Environment» 67

82 Chapitre III ENVIRONNEMENT D INNTERCATION AVEC L UTILISATEUR (UIE) Outil boîte-noire Outil basé-service Outil basé-service Outil boîte-noire Interface de Communication SPADE (SCI) ENVIRONNEMENT D EXECUTION DE PROCESSUS (PEE) Interpréteur SLANG MOTEUR DE PROCESSUS Interpréteur SLANG Interpréteur SLANG Interpréteur SLANG Interpréteur SLANG Interpréteur SLANG REPERTOIRE Figure III.17 L architecture de SPADE Le PEE supporte l exécution des modèles de processus SLANG, qui peuvent être composés par plusieurs activités (c'est-à-dire des fragments de réseaux de Pétri). Pendant l exécution, différentes instances de la même activité, nommées copies actives, peuvent être créés. Les copies actives sont exécutées d une manière concurrente par des différents interpréteurs SLANG, implantés comme des «threads» séparés du moteur de processus. Le UIE est l interface de SPADE avec ses utilisateurs. Il est composé par des outils utilisés par les agents impliqués dans le processus de développement et contrôlés par le PEE. Il y a deux types d outils : «boîte-noire» et «basé-support». Les outils boîte-noire sont vus par le PEE comme un seul appel de fonction qui reçoit des éléments en entrée et fournit des éléments en sortie. SPADE contrôle seulement leur invocation et terminaison. Les outils basésupport offrent une interface à travers laquelle il est possible d invoquer des services individuels. La communication entre SPADE et les outils basés-service est gérée par l interface de communication de SPADE à travers un protocole de communication. L approche réflexive en SPADE permet de manipuler les objets et les activités comme des «tokens» ce qui permet aux transitions de manipuler le processus même s il est en cours d exécution. SPADE est basé sur deux principes : Toutes les opérations mises en œuvre dans un processus logiciel doivent être explicitement décrites par un modèle de processus. Pour qu une activité du processus soit supportée par l environnement, un fragment de processus qui l implante doit être fourni. 68

83 L état de l art Il est possible de gérer les déviations niveau domaine (entre le domaine de la mise en œuvre et le domaine de l exécution), en introduisant de nouveaux fragments de processus qui décrivent les situations inattendues. Les utilisateurs opèrent sous le contrôle de SPADE, c'est-à-dire que chaque opération liée au processus logiciel est mise en œuvre à travers SPADE. Ceci permet à SPADE de mettre à jour, d une manière constante, son image du processus mis en œuvre, en fonction des événements qui se produisent dans ce dernier. Afin de supporter ce principe, SPADE offre des mécanismes pour intégrer des outils (la SCI et son protocole), afin que toutes requêtes faites par un utilisateur vers un outil puissent être détectées et gérées par SPADE. Si ces principes sont violés, une déviation niveau environnement apparaît. Ainsi, nous remarquons que la manière de gérer les situations inattendue (qui peuvent engendrer des déviations entre la mise en œuvre du processus et son modèle) en SPADE se fait à travers une modélisation explicite de ces situations sous la forme de fragments de processus. Dans le cas de déviations mineures ceci implique un effort important de modélisation, effort qui ne sera pas rentabilisé. III.4.2 SENTINEL SENTINEL (Software-engineering Environment for Tolerate INconsistencies Employing Logic) est un EGLCP développé à Politecnico di Milano [Cugola et al. 1995]. Son principal objectif est de trouver des moyens pour concilier la rigidité d un modèle et le besoin de flexibilité et d évolutivité des processus durant le développement. Plus précisément, son but est de fournir un mécanisme permettant d éviter les déviations au niveau de l environnement (entre le processus mis en œuvre et le processus exécuté). SENTINEL ne force pas les agents du processus à suivre rigidement le modèle, leur donnant la possibilité de dévier. L environnement SENTINEL est basé sur un langage de modélisation de processus appelé LATIN (LAnguage for Tolerating INconsistencies). Les processus logiciels sont modélisés en LATIN comme des collections de tâches. Chaque tâche décrit une activité du processus comme une machine d état. Les transitions entre les états sont caractérisées par une précondition, appelée ENTRY, ainsi qu un corps. ENTRY est une proposition logique qui définit la propriété qui doit être satisfaite afin d exécuter la transition en cause. Dans le corps, deux classes différentes d opération peuvent être exécutées : des actions et des assignations des valeurs (clauses EXIT). Les actions produisent des résultats dans le processus. L assignation des valeurs modifie les valeurs des variables d état de la tâche. Les invariants sont des propositions qui représentent des besoins critiques et qui doivent être vérifiées dans tous les états du système. Ils peuvent être locaux (s appliquent à un seul type de tâche) ou globaux (s appliquent au processus entier). L exécution du modèle de processus est représentée comme un ensemble d instances de tâches qui s exécute en concurrence. Les instances de tâches sont dynamiquement instanciées à partir des types de tâches correspondants. Il existe deux types de transitions en LATIN : les transitions normales et les transitions exportées. Une transition normale est exécutée dès que la valeur de sa pré-condition est vérifiée. Si plusieurs pré-conditions de transitions sont vérifiées, une est choisie d une manière non-déterministe. Une transition exportée est exécutée à la demande d un agent du processus et si sa pré-condition est vérifiée. Cependant, les agents du processus peuvent forcer l exécution d une transition exportée même si sa pré-condition n est pas vérifiée. Dans ces conditions, la transition est déclenchée illégalement. 69

84 Chapitre III Quand une transition exportée est déclenchée illégalement une déviation par rapport au modèle est induite. Cette déviation n engendre cependant pas une déviation au niveau environnement, la déviation étant représentée dans l état interne de SENTINEL. Les données produites après la déviation sont marquées comme polluées. Si, à un moment donné un invariant est violé, un processus de réconciliation doit permettre de fixer les données polluées de façon à ce qu aucun invariant ne soit violé. En fait, une analyse de la pollution est automatiquement générée, analyse qui fournit une description de la déviation et des données polluées par cette déviation. Ainsi, SENTINEL permet les déviations tout en les gardant dans des limites définies à travers des invariants. En fait, les ensembles d états et de transitions représentant le processus en exécution sont augmentés de façon à incorporer les transitions exportées déclenchées illégalement ainsi que les états contenant les données polluées. Cette augmentation à lieu même si les transitions et états mentionnés ne sont pas définis dans le modèle de processus. SENTINEL tolère les déviations et les incohérences au niveau domaine. En permettant ce type de déviations, le système acquiert une flexibilité qui réduit les apparitions des déviations niveau environnement (qui ne sont pas sous le contrôle de l environnement). En effet, le système peut représenter plus de situations, ce qui lui permet de garder le contrôle de ces situations. Il est ainsi plus souple que SPADE, où chaque déviation doit être préalablement modélisée sous la forme des fragments de processus. III.4.3 PEACE PEACE (Process-centred Enactable and Adaptable Computer-aided Environment) est un EGLCP développé au Centre de Recherche CRISS à l Université Pierre Mendes France [Arbaoui et al. 1992, Arbaoui 1993, Arbaoui et Oquendo 1993a, Arbaoui et Oquendo 1993b, Arbaoui et Oquendo 1994]. Il propose un langage de modélisation de processus qui adopte une approche orientée-but fondée sur une logique non-monotone. Ainsi, le langage considère les buts à atteindre dans un processus plutôt que les activités (comme dans la pluart des langages de modélisation de processus). La logique employée est la logique de croyances [Moore 1988], ce qui permet de représenter ce qui est crû être vrai dans un processus logiciel. Un modèle de processus est organisé comme un ensemble de fragments de modèles de processus (FMP), chacun de ces fragments étant une description d une étape de processus ainsi que son but associé. Un FMP qui décrit une étape de processus élémentaire, c'est-à-dire qui ne peut plus être décomposé en sous-processus, est appelé un FMP élémentaire. Dans le cas contraire, le FMP décrit une tâche ou bien une activité composée d autres activités, et il est dit complexe. Un FMP est composé par une spécification et plusieurs implantations. Une spécification de FMP décrit l étape de processus associée, en utilisant : des entrées et des sorties : les noms et les types des objets en entrée ou en sortie ; des rôles intrinsèques : expressions logiques qui décrivent les rôles des agents humains responsables de la mise en œuvre de la tâche et les contraintes concernant ces rôles ; des événements en entrée et en sortie, plus précisément les spécifications des événements ; des pré-conditions et post-conditions intrinsèques : des conditions (expressions logiques) nécessaires mais non suffisantes, que la base d objets doit satisfaire avant et respectivement après l exécution du FMP. Lorsqu un FMP est élémentaire, son implantation est composée d outils encapsulés. Dans le cas contraire, il s agit d un FMP complexe qui est implanté par un ensemble de FMP. Dans ce cas, l implantation utilise un ensemble de spécifications de FMP (FMP_S) qui sont 70

85 L état de l art encapsulées par un rôle contextuel, par des pré-conditions contextuelles et par des postconditions contextuelles. L implantation d un FMP complexe consiste également en un ensemble de règles contextuelles et un ensemble de traitements d événements. A travers les éléments contextuels, PEACE/PDL fournit les mécanismes nécessaires à l adaptation d un modèle au contexte spécifique d un projet. Leur contrepartie intrinsèque donne des conditions générales qui doivent être respectées dans tous les projets employant le modèle de processus. En PEACE les expressions logiques utilisent une logique modale non monotone basée sur la logique autoépistémique de Moore [Moore 1988]. Cette logique permet de représenter, en plus de la connaissance «sûre» (une connaissance qui sera toujours vraie), la connaissance incomplète ou incertaine (une connaissance qui peut s avérer fausse) sous la forme de croyances. En effet, à l aide du pouvoir d expression de cette logique, PEACE peut fournir un support à la mise en œuvre même dans la présence de connaissances incertaines ou incomplètes Les croyances peuvent changer dans le temps et le système est capable de retirer les propositions qui ne sont plus valides. UTILISATEURS Ingénieurs des processus UTILISATEURS Gestionnaires des processus UTILISATEURS Exécutants de processus INTERFACE UTILISATEUR Sous-Environnement Spécification Interface de communication Sous-Environnement Implantation Interface de communication Sous-Environnement Exécution GESTIONNAIRE DES LIBREAIRIES LIBRAIRIES Librairies des FMP_S, FMP_Ip Librairies des FMP_I, FMP_L LIBRAIRIE outils de développement de logiciel GESTIONNAIRE DE LA BASE DE CONNAISSANCE BASE DE CONNAISSANCES processus Modèle de processus Base d objets Modèle d objets Figure III.18 Architecture générale de l environnement PEACE Pendant l exécution, un raisonnement logique a lieu afin de choisir les étapes du processus qui doivent être exécutées afin de satisfaire un but donné. En fonction de la connaissance possédée par le moteur de processus concernant l état du processus, plusieurs séquences des 71

86 Chapitre III étapes peuvent être utilisées pour satisfaire un tel but. L utilisateur à la responsabilité d en choisir une qui sera liée dynamiquement à la spécification et ensuite exécutée. L utilisateur peut ajouter des nouvelles croyances ou retirer des croyances existantes afin de décrire des situations nouvelles. L architecture de PEACE est présentée dans la Figure III.15. L approche de modélisation et d exécution adoptée en PEACE augmente la flexibilité de l environnement, réduisant ainsi le besoin de déviations. Un modèle de processus en PEACE peut décrire une large palette d états de processus et de transitions et la plus pertinente est choisie en fonction des croyances du système par rapport au processus mis en œuvre. Ainsi, les exécutions sont divisées entre exécutions admises et exécutions proscrites. Les exécutions admises contiennent toutes les exécutions qui n utilisent pas des états proscrits, même si ces exécutions ne sont pas les plus pertinentes, c est-à-dire certaines déviations existent entre l exécution la plus pertinente et ces exécutions. Deux extensions de PEACE ont été proposées afin d améliorer les aspects liés aux travaux dans des environnement coopératifs [Alloui et al. 1994, Alloui 1996, Alloui et Oquendo 1996a, Alloui et Oquendo 1996b,] ainsi qu à la gestion de l évolution [Latrous et Oquendo 1995, Latrous et Oquendo 1996, Latrous 1997], tous les deux ayant une approche multiagents. III.4.4 APEL APEL (Abstract Process Enactment Language) est un projet de l Université Joseph Fourier, Grenoble, France [Amiour et Estublier 1998, Estublier et al. 1998a, Estublier et al. 1998b]. APEL est un environnement centré processus pour la modélisation et l exécution des processus. APEL n est pas dédié à un domaine d application spécifique. Le méta-modèle utilisé peut être adapté aux différents domaines, en fonction des besoins. Du point de vue de la modélisation, la complétude d un modèle n est pas imposée avant son exécution. Ainsi, les utilisateurs peuvent commencer avec des versions incomplètes ou non-déterministes, et les faire évoluer d une manière dynamique pendant l exécution. Du point de vue architectural, APEL a été conçu afin d avoir un maximum de flexibilité et d ouverture, de manière à ce que des outils externes puissent joindre la fédération à chaque moment et avec des ajustements mineurs. Le travail autour d APEL s est déroulé sur plusieurs années durant lesquelles différentes versions du système ont été implantées. L architecture d APEL v5 [Dami 1999] est présentée dans la Figure III.16. L environnement fournit un éditeur graphique pour la définition des modèles conformes au formalisme sous-jacent. Avec l éditeur graphique, des mécanismes sont fournis afin d assurer le passage depuis la représentation graphique à une représentation dans le langage textuel de modélisation d APEL. Le modèle de processus est réifié dans une base de données orientée objet, sous la forme d objets. Un compilateur fait le passage depuis le modèle réifié à des classes java qui sont ensuite exécutées par le moteur de processus. Le serveur de processus a le rôle de maintenir une représentation commune et cohérente du processus pour chaque composant qui joint la fédération. Il fournit une interface de haut-niveau permettant l accès et la mise à jour aussi bien des modèles que des instances. La communication entre les différents composants de l environnement se fait à travers le serveur de message. Le serveur de message utilisé dans APEL v5 est basé sur des spécifications JMS [Hapner et al. 1998]. 72

87 L état de l art Modèle APEL Réification Compile OS Modèle Model Instances Serveur de Processus Evolution -Monitoring -support à la décision - Exécute Classes Java Moteur de Process Processus Engine Serveur de Messages Gestionnaire des agendas Gestionnaire de ressources Autres EGLCP Figure III.19 L'architecture d'apel Les concepts de base utilisés dans la modélisation utilisant le formalisme d APEL sont les concepts d activité, de produit, et d agent. Chacun de ces concepts peut avoir des états qui changent à travers des transitions qui sont déclenchées par des événements. Une activité est définie comme une opération ou une étape (atomique ou composite) qui fournit une sortie à partir des entrées dans le cadre d un processus. Elle contient une interface qui définit la partie visible de l activité, incluant les entrées et les sorties, l agent ou le rôle impliqué, ainsi que des conditions qui doivent être satisfaites avant, après ou pendant son exécution. Un modèle de processus est composé par un ensemble d activités qui peut être décomposé d une manière récursive en suivant différents niveaux d abstractions. La caractéristique qui nous intéresse en APEL est sa flexibilité concernant l évolution des instances et des modèles. Ainsi, une instance peut évoluer, sans changer le modèle associé. Ceci mène à des incohérences (et des déviations) au niveau domaine, mais permet d éviter les incohérences (et les déviations) au niveau environnement. Cependant il n y a aucun mécanisme de contrôle d incohérences et de déviations au niveau domaine. L utilisateur est libre de faire évoluer ses instances. Ceci est cohérent avec l approche de flexibilité et ouverture d APEL. En fait, l environnement est ouvert pour l intégration des nouveaux outils. De tels outils peuvent prendre en charge la gestion de l évolution, y compris les aspects liés à la gestion de la cohérence. D ailleurs, dans l architecture d APEL de tels outils sont déjà mentionnés (voir Figure III.16, évolution). III.4.5 Bilan Nous avons regardé dans cette section des environnements qui abordent le problème des situations inattendues qui peuvent apparaître pendant la mise en œuvre du processus, qui peuvent engendrer des incohérences ou bien des besoins de déviations par rapport aux modèles que de telles situations impliquent. Le support offert par les environnement présentés est très varié. SPADE fournit des mécanismes permettant la modélisation explicite des déviations nécessaires. SENTINEL tolère les déviations tant que des invariants ne sont pas violés. PEACE prend une approche proscriptive quant à la modélisation et l exécution, ce qui permet de prendre en compte des déviations qui ne contiennent pas des comportements proscrits. APEL permet toutes déviations (sans contrôle). 73

88 Chapitre III III.5 Conclusion Dans ce chapitre, nous avons présentés les travaux effectués sur les problématiques suivantes : l évaluation du processus, l amélioration du processus, les systèmes de mesure, d analyse et de rétroaction ainsi que les EGLCP abordant le problème de l incohérence. Le problème que nous aborderons dans cette thèse est celui de fournir un environnement pour le monitoring des processus logiciels. Par monitoring, nous comprendrons une technique de surveillance comprenant des prises de mesures avec détection des déviations par rapport à un comportement attendu. Nous essayons dans cette thèse de fournir un environnement qui présente les caractéristiques suivantes : fournit un langage pour la définition des modèles de monitoring ainsi que des mécanismes permettant l exécution de tels modèles par rapport à un processus sujet au monitoring ; permet la représentation explicite des données imprécises du processus sujet et gère ce sort des données ; permet de faire des analyses liées à la conformité des processus sujet par rapport à leurs modèles ; est adaptable (fournit des mécanismes pour le réglage) ; est intégrable dans un EGLCP. Un tel environnement répond à plusieurs problèmes ouverts. Comme nous avons pu le constater dans la section dédiée aux systèmes de mesure et d analyse, aucun des systèmes étudiés ne présente ces caractéristiques. Aucun ne fournit un langage de modélisation de monitoring, la majorité des systèmes (mise à part le système Amadeus) étant dédiés à des utilisations spécifiques. L existence d un langage dédié à la définition des modèles de monitoring permet d obtenir un cadre formel qui permet de décrire et faire évoluer les systèmes de monitoring. Elle permet aussi de générer, à travers des modèles et avec les mécanismes d exécution fournis, des systèmes de monitoring à utilisation spécifique. Les données imprécises et/ou incertaines ne sont pas prises en compte d une manière explicite dans aucun des systèmes étudiés. Aucun des systèmes ne propose des mécanismes pour leur réglage pendant l exécution. Sans un tel mécanisme la pertinence des systèmes dans un contexte donné ne peut pas être garantie. Un environnement qui répond à la description précédente trouve l utilisation aussi bien dans les démarches d évaluation et d amélioration que dans le cadre des EGLCPs afin de leur permettre d offrir un support pour les processus arrivés à des hauts niveaux de maturité, où le contrôle quantitatif et la rétroaction quantitative sont imposés. 74

89 Chapitre IV Chapitre IV OMEGA/LDM : LE LANGAGE DE DEFINITION DU MONITORING CHAPITRE IV OMEGA/LDM : LE LANGAGE DE DEFINITION DU MONITORING IV.1 L APPROCHE POUR LE MONITORING DANS OMEGA IV.1.1 Le monitoring dans le support de processus logiciel IV.1.2 L environnement OMEGA : un aperçu IV.1.3 La logique floue : un outil théorique pour le monitoring IV La nature des informations IV Les outils IV La représentation de l information en utilisant la théorie des sous-ensembles flous IV Des traitements portant sur des informations imprécises IV Bilan IV.2 LE FORMALISME OMEGA/LDM IV.2.1 Les concepts clés IV Modèle de monitoring IV Les univers IV Les informations IV Les transformations IV.2.2 Les transformations de calcul IV Les expressions IV Les fonctions d appartenance IV Les traitements des informations linguistiques à l aide des règles IV Les formules de comparaison IV.2.3 Les transformations de communication IV Les transformations utilisées dans la gestion des entrées IV Les transformations utilisées dans la gestion des sorties IV.3 CONCLUSION

90 Chapitre IV 76

91 OMEGA/LDM : Le Langage de Définition du Monitoring OMEGA/LDM : Le Langage de Définition du Monitoring Dans ce chapitre nous allons présenter notre proposition de solution pour le monitoring de processus logiciels : l environnement OMEGA (On-line Monitoring Environment : General and Adaptable). Nous allons nous focaliser sur le langage que cet environnement fournit pour définir des modèles de monitoring : OMEGA/LDM (OMEGA/Langage de Définition de Monitoring). Ce chapitre est structuré en deux parties, dédiées respectivement : à l approche adoptée dans OMEGA ; au formalisme OMEGA/LDM. Dans la partie dédiée à l approche, nous verrons la manière dont l environnement OMEGA s intègre dans un EGLCP par rapport au processus supporté. Toujours dans cette partie nous présenterons l outil théorique que nous employons : la logique floue. La présentation du formalisme proposé dans le système OMEGA pour la définition des modèles de monitoring est structurée de la manière suivante : dans un premier temps, nous allons présenter les concepts sur lesquels repose ce formalisme et que nous illustrerons au fur et à mesure par des extraits de la grammaire du langage de description de monitoring OMEGA/LDM (cf. Annexe A) ; puis, nous nous attarderons sur les éléments du langage spécifiques aux différents modèles, à savoir au modèle d analyse, de capteurs, d affichage, de traçage et de publication. IV.1 L approche pour le monitoring dans OMEGA IV.1.1 Le monitoring dans le support de processus logiciel Dans le Chapitre II (Support aux processus logiciels : cadre et terminologie), nous avons présenté une organisation du processus logiciel en trois domaines : le domaine de définition (contient les modèles de processus), le domaine de la mise en œuvre (englobe les activités effectives, le monde «réel») et le domaine d exécution (englobe l exécution des modèles de processus afin de supporter le processus mis en œuvre). Dans la vision adoptée, au niveau du domaine d exécution, une distinction a été faite entre la représentation du processus mis en œuvre et l exécution la plus proche conforme au modèle. Cette nouvelle vision est considérée comme adaptée afin de gérer les problèmes liés aux incohérences entre les trois domaines. Plus précisément, elle empêche l apparition des incohérences niveau-environnement (entre le processus mis en œuvre et sa représentation). Si 77

92 Chapitre IV un besoin de déviation du processus mis en œuvre par rapport à son modèle apparaît, la déviation ne se passe pas en dehors du support de processus. Une représentation fidèle du processus mis en œuvre se trouve dans le domaine d exécution. Afin de garder la pertinence du support de processus offert par le EGLCP, ces déviations doivent cependant être gardées dans des limites établies. Un certain niveau de concordance entre le processus mis en œuvre et sa représentation dans l EGLCP est requis. En utilisant cette nouvelle vision des domaines du processus, la concordance entre le processus mis en œuvre et son modèle peut être calculée en utilisant leurs représentations dans le domaine d exécution, le but étant d automatiser le plus possible ce calcul de concordance. Des limites peuvent être imposées sur les valeurs de concordance afin de garder les déviations sous contrôle. Un système de contrôle quantitatif qui implante une boucle de rétroaction est utilisé afin de remplir à la fois le rôle de calcul de la concordance ainsi que le contrôle des déviations. Le système de contrôle fournit les trois fonctionnalités de base d une boucle de rétroaction, à savoir : identifier les situations qui impliquent un besoin de changement, décider les changements nécessaires afin de faire face à ces situations et implanter les changements (cf. Figure IV.1). Ce besoin de changement peut se manifester sous la forme d une déviation qui devient ou risque de devenir trop importante. Domaine de définition Processus instantié Retour d information concernant l exécution des définitions Informations Ce qui devrait se passer définitions et fragments de définition une exécution conforme la plus proche de la mise en œuvre détecter un besoin de changement ; décider le changement ; implanter le changement ; CONTROLE QUANTITATIF Changements Informations Processus mis en œuvre Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution Domaine d exécution Domaine de mise en œuvre assistance et support pour la mise en œuvre Changements mise en œuvre du processus Retour d information concernant la mise en œuvre Ce qui se passe réellement Figure IV.20 Un contrôle quantitatif dans le domaine de l exécution Afin de remplir ces trois fonctionnalités, le contrôle quantitatif contient trois systèmes : le monitoring, le support à la décision et le support au changement. Le système de monitoring observe le processus mis en œuvre ainsi que l exécution conforme la plus proche de ce processus, des informations étant collectées. A partir de ces informations, le système de monitoring fait des analyses, dont certaines peuvent concerner le niveau de concordance entre la mise en œuvre et l exécution conforme la plus proche. Si le niveau de 78

93 OMEGA/LDM : Le Langage de Définition du Monitoring concordance est plus bas que les limites considérées acceptables, des alarmes sont émises. Ainsi, ces alarmes mettent en évidence des déviations inacceptables. Le support à la décision réagit aux alarmes. En fonction des résultats des analyses fournis par le système de monitoring, il indique des actions correctives ayant le rôle de concilier les déviations. Ces actions correctives peuvent concerner aussi bien la mise en œuvre que l instanciation du processus. Cette dernière est changée de manière à ce que l ensemble d exécutions conformes contienne au moins une exécution, conforme, dont la concordance avec le processus mis en œuvre se situe dans les limites acceptables. Le support au changement a le rôle d implanter les actions correctives fournies par le support à la décision. L implantation se fait seulement après avoir vérifié des contraintes qui ont le rôle d assurer que les changements sont consistants avec l état du processus. Chacun de ces systèmes peut remplir d autres fonctionnalités. Le système de monitoring peut fournir des analyses autres que celles liées à la concordance. Le système de support à la décision peut fournir par exemple des analyses de risque. Il peut ainsi fournir du support à la décision autrement qu en réaction à des alarmes issues du monitoring. Le support au changement peut être également utilisé par le manager du processus, afin de faire évoluer le processus en réaction à des besoins extérieurs au domaine d exécution, tels que des nouveaux délais imposés par les clients, l indisponibilité d un des agents du processus, etc. Comme il est montré dans la Figure IV.1, le système de contrôle se place dans le domaine d exécution. Ceci ne veut pas dire que l intégration du système de contrôle dans le support de processus est de nature à changer le mécanisme de fonctionnement de ce dernier. Un des principes importants de l approche proposée est l indépendance entre les mécanismes de support de processus fournis par l EGLCP et le système de contrôle. Ainsi le système de contrôle devrait pouvoir s intégrer d une manière naturelle dans un EGLCP existant. IV.1.2 L environnement OMEGA : un aperçu L environnement que nous proposons fournit un langage pour la définition des modèles de monitoring ainsi que des mécanismes pour l exécution de ces modèles. Nous allons revenir dans les chapitres suivants sur les mécanismes d exécution. Un modèle de monitoring contient des éléments concernant les entrées du système, les traitements des entrées et les sorties. Il est formé par plusieurs modèles spécifiques, qui sont dédiés aux analyses que le système doit fournir (le modèle d analyse), ainsi qu à la communication de ce système avec le reste de l environnement qu il intègre. Un modèle d analyse indique les données qui doivent être collectées ainsi que les transformations qui doivent être appliqués à ces données. Les autres types de modèles spécifiques contiennent des modèles qui servent à assurer la communication du système de monitoring avec son environnement. Plus précisément, les modèles de communication gèrent les entrées et les sorties du système. Chacun des modèles de communication est dépendant du modèle d analyse. Un modèle de capteurs indique les sources pour les données qui doivent être collectées (indiquées dans le modèle d analyse). Un tel modèle est utilisé afin de spécifier la provenance des données qui doivent être collectées. En utilisant un modèle de ce type, le système de monitoring construit l instrumentation nécessaire à la collection des données. 79

94 Chapitre IV Les autres types de modèles spécifiques gèrent les sorties du système. Plus précisément ils spécifient les informations (utilisées ou générées par le monitoring à travers ses analyses) qui doivent être communiquées à l environnement d utilisation. En fait, les modèles de monitoring (indépendamment de leur spécificité) contiennent principalement des informations et des transformations. Les informations représentent des attributs du processus. Les transformations sont utilisées pour le traitement des informations. L observation d un processus par le système de monitoring est faite à travers des prises de mesures. Pour ces dernières Fenton propose une définition ainsi que des classifications [Fenton 1991, Fenton 1994] de ces prises de mesure que nous donnons ci-dessous. Le processus de prise de mesure 41 est le processus d assignation des valeurs (numériques ou linguistiques) à des attributs de manière à les décrire en suivant des règles précises. Dans la prise de mesure directe, la valeur d attribut mesuré ne dépend pas des valeurs d autres attributs. Dans la prise de mesure indirecte, la valeur d attribut mesuré dépend des valeurs d autres attributs. Les prises de mesure directes correspondent à des collections des données par le système de monitoring. Les prises de mesures indirectes sont associées aux applications de transformations, qui permettent d obtenir la valeur d une information à partir des valeurs d autres informations. La Figure IV.2 présente une vue plus détaillée de la manière dont le support de processus logiciel et le système de monitoring sont positionnés l un par rapport à l autre. L organisation du monitoring est également divisée en trois domaines. Ceci est dû au fait que le monitoring a une approche similaire à celle du support de processus. OMEGA offre un formalisme pour la définition des modèles de monitoring et un mécanisme pour l exécution de ces modèles. Le domaine de la mise en œuvre contient, en ce qui concerne le monitoring, des processus de gestion et d évolution du processus de développement. Ainsi, l exécution des modèles de monitoring dans le domaine d exécution offre un support au processus de gestion et d évolution qui se trouve dans le domaine de la mise en œuvre. La plupart des informations est collecté par le monitoring depuis le domaine d exécution du processus logiciel. Toute l échange d informations est assuré par des événements. Le retour d information depuis le domaine de la mise en œuvre vers le domaine d exécution du monitoring concerne aussi bien la mise en œuvre du monitoring (par exemple la fixation des valeurs cibles, des seuils, etc.) que la mise en œuvre du processus de logiciel (sous la forme d informations nécessaires à certaines analyses, et qui ne sont pas présentes dans la représentation du processus (dans l EGLCP qui le supporte). Des interactions existent aussi entre les deux niveaux de définition, car le modèle de processus utilisé peut influencer d une part le choix de modèle de monitoring, d autre part la configuration de monitoring choisie. L interaction entre les deux domaines de la mise en œuvre se matérialise dans les interactions normales entre le processus de gestion et le processus de développement. 41 La terminologie anglophone est «measurement». 80

95 OMEGA/LDM : Le Langage de Définition du Monitoring Modèles du monitoring Mise en œuvre du monitoring Exécution du monitoring Domaine de définition Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution Domaine de mise en œuvre Modèles du processus Domaine d exécution Mise en œuvre du processus une exécution conforme la plus proche de la mise en oeuvre Mécanisme Mécanisme Mécanisme Processus mis en œuvre LEGENDE = Collection d informations = Interaction au même niveau (processus sujet ou monitoring) = Interaction entre les niveaux Figure IV.21 Les domaines sur les deux niveaux : monitoring et processus sujet Le système de monitoring utilise pour différents attributs du processus les ensembles des valeurs tolérées pour cet attribut. Ces ensembles contiennent les valeurs souhaitées (données par l exécution conforme la plus proche du processus mis en œuvre) ainsi que des valeurs tolérées, qui sont considérées comme des déviations acceptables. Le monitoring vérifie pour les attributs considérés leur concordance avec la tolérance qui leur est associée, et émet des alarmes si les valeurs de concordance dépassent des seuils établis. IV.1.3 La logique floue : un outil théorique pour le monitoring IV La nature des informations Les connaissances dont nous disposons dans le système de monitoring, tout comme dans un système quelconque, sont en général imparfaites. Les raisons de ces imperfections sont de nature différente, principalement au nombre de trois : les incertitudes, les imprécisions et les incomplétudes [Bouchon 1995]. Les incertitudes concernent un doute sur la validité d une connaissance. Le doute peut provenir d une fiabilité relative de l intermédiaire de l observation, peu sûr de lui ou susceptible de commettre des erreurs, ou encore d une difficulté dans l obtention ou la vérification de la connaissance. Des incertitudes sont également présentes dans les cas des prévisions. 81

96 Chapitre IV Nous pouvons retrouver ces situations dans la phase de la prise de mesures effectuées par le monitoring, où une partie des informations est fournie par les agents de processus. Prenons le cas d un agent qui doit faire une appréciation de l état d avancement de son travail. La pertinence de son appréciation est dépendante de son expérience, l appréciation qu il fournit ayant un certain degré d incertitude. Les imprécisions correspondent à une difficulté dans l énoncé des connaissances, soit parce que des connaissances numériques sont mal connues, soit parce que des termes de langage naturel sont utilisés pour qualifier une caractéristique du système de façon vague. Le premier cas est la conséquence d une insuffisance d instrumentation (le temps dépensé en activité de codage est «entre 20 et 30 heures»), d erreurs de mesure, ou encore des connaissances flexibles (le nombre de pages dans un mémoire de thèse est «environ entre 120 et 220»). Le second provient de l expression spontanée de connaissances (activité «longue», codage «difficile», etc.) ou de l utilisation de catégories à limites mal définies («expert», «débutant»). Les incomplétudes sont des absences de connaissances ou des connaissances partielles sur certaines caractéristiques du système. Elles peuvent être liées à l impossibilité d obtenir certains renseignements, ou à un problème au moment de la capture de l information. Elles peuvent aussi être associées à l existence des connaissances générales sur l état d un système, généralement vraies, soumises à des exceptions que l on ne peut pas énumérer ou prévoir (par exemple «généralement le groupe qui fait l audit est composé de deux ingénieurs et d un gestionnaire»). Ces types de connaissances ne sont pas indépendants les uns des autres. Les incomplétudes entraînent des incertitudes (par exemple il est seulement presque, mais pas absolument, sûr que la commission A d audit va contenir deux ingénieurs et un gestionnaire). Les imprécisions peuvent être associées à des incomplétudes et elles engendrent des incertitudes au cours de leur manipulation. Des données de nature imparfaite sont présentes dans le processus logiciel. Le système de monitoring et chargé de collecter et analyser des informations concernant le processus. Il peut ne pas tenir compte des imperfections et utiliser une représentation qui les élimine, ou bien les conserver en raison des informations qu elles contiennent. La solution la plus satisfaisante réside dans une préservation des imperfections jusqu à un certain point, qui permette de ne pas perdre une information intéressante, et de parvenir à une représentation manipulable de façon automatique. IV Les outils Les incertitudes ont été identifiées depuis fort longtemps par l intermédiaire de la notion de probabilité, introduite dès le XVIIème siècle par Pascal et Fermat et formalisée par Bernouilli. Les scientifiques de l époque ont introduit l idée de degré de croyance, en la confondant avec celle de chance. La notion de probabilité ne semble cependant pas adaptée à la représentation des incertitudes de nature psychologique, telles que celles liées à la fiabilité d un informateur. Une étape a été franchie par l introduction de la théorie de l évidence [Dempster 1967, Shafer 1976] qui permet de manipuler les degrés de «confiance» qu un observateur attribue à la validité de certains faits, en n imposant plus la condition d additivité, fondamentale en théorie des probabilités. La formalisation des imprécisions n a pas suscité autant l intérêt des scientifiques, sauf celle des physiciens, qui utilisent la notion d erreur. Une formalisation est apparue sous la forme d une théorie dite des intervalles [Moore 1966], restreint aux imprécisions de caractère numérique. 82

97 OMEGA/LDM : Le Langage de Définition du Monitoring La forme la plus générale des imprécisions a trouvé un moyen de représentation et de traitement dans l introduction de la théorie des sous-ensembles flous [Zadeh 1965]. La théorie des possibilités a été introduite également par L. Zadeh [Zadeh 1978] afin de parvenir à un raisonnement approximatif qui ait une ressemblance avec le raisonnement humain, plus précisément raisonner à partir des connaissances imprécises. Le cadre conjoint de la théorie des sous-ensembles flous et de la théorie des possibilités constitue la logique floue. La logique floue est un cadre dans lequel peuvent être traitées des imprécisions et des incertitudes, qui autorise également le traitement de certaines incomplétudes, et un cadre dans lequel peuvent être traitées des connaissances numériques et des connaissances exprimées symboliquement par des qualifications du langage naturel [Bouchon 1995]. Nous allons par la suite présenter quelques éléments liés à la théorie des sous-ensembles flous, la théorie des possibilités, ainsi que les utilisations qu OMEGA fait de ces outils. IV La représentation de l information en utilisant la théorie des sousensembles flous Le concept de sous-ensemble flou a été introduit par L.A. Zadeh [Zadeh 1965] pour éviter les passages brusques d une classe à une autre et autoriser des éléments à n appartenir complètement ni à l une ni à l autre, et à appartenir partiellement à chacune. Le caractère graduel des sous-ensembles flous correspond à l idée que, plus on se rapproche de la caractérisation typique d une classe, plus l appartenance à cette classe est forte. Soit X un ensemble de référence. Les éléments de X qui possèdent une certaine propriété constituent un sous-ensemble A de X au sens habituel de la théorie des ensembles. C est un sous-ensemble classique ou ordinaire et la propriété associée est notée Prop(A). Les éléments de X qui ne possèdent pas cette propriété appartiennent au sous-ensemble complémentaire du précédent. Par contre, si certains éléments de X ne possèdent pas la propriété de façon absolue, il est possible de choisir avec quel degré chaque élément la possède. De même que pour un ensemble classique, un sous-ensemble flou A de X [Zadeh 1965] est défini et la propriété associée est notée Prop(A). Tout élément de X appartient au sous-ensemble flou, avec un degré qui vaut 1 en cas d appartenance absolue et qui éventuellement peut être nul. Voici la définition de ces deux types de sous-ensembles : Un sous-ensemble classique A de X est défini par une fonction caractéristique χ A qui prend la valeur 0 pour les éléments de X n appartenant pas à A et la valeur 1 pour ceux qui appartiennent à A : χ A : X {0,1}, x X, χ A (x)=1 si x A, χ A (x)=0 sinon. Un sous-ensemble flou A de X est défini par une fonction d appartenance µ A qui associe à chaque élément x de X, le degré µ A (x), compris entre 0 et 1, avec lequel x appartient à A : µ A : X [0,1] µ A (x)=1 si x appartient totalement A, µ A (x)=0 si x n appartient pas du tout à A. Dans le cas particulier ou µ A ne prend que des valeurs égales à 0 ou 1, le sous-ensemble flou A est un sous-ensemble classique de X. Exemple. La figure IV.3 illustre un exemple d extension d un ensemble «net» à un ensemble flou représentant la durée d une activité de codage. Pour l ensemble net, tant que les durées sont inférieures ou égales à 15 jours, l appartenance à l ensemble est totale ; elle est nulle aussitôt que la durée dépasse 15 jours. Pour l ensemble flou, l appartenance est totale 83

98 Chapitre IV pour des durées inférieures ou égales à 15 jours, elle est graduelle pour des durées comprises entre 15 est 20 jours. fonction caractéristique fonction d appartenance 1 χ A durée strictement < ou = à 15 jours 1 µ A durée environ < ou = à 15 jours durée de l activité de codage (jours) durée de l activité de codage (jours) 84 Figure IV.22 Sous-ensemble net et sous-ensmble flou Voici quelques caractéristiques des sous-ensembles flous qui montrent leur différence par rapport aux ensembles classiques. Le support de A, noté supp(a), est la partie de X pour laquelle la fonction d appartenance de A n est pas nulle : supp(a)={x X/ µ A (x) 0}. La hauteur de A, noté h(a), est la plus grande valeur prise par sa fonction d appartenance : h(a)=sup x X µ A (x). Le sous-ensemble flou A de X est normalisé si sa hauteur h(a) est égale à 1. Le noyau de A, noté noy(a), est l ensemble des éléments de X pour lesquels la fonction d appartenance de A vaut 1 : noy(a)={x X/ µ A (x)=1}. Si A est un sous-ensemble classique de X, sa hauteur est égale à 1, il est normalisé et identique à son support et à son noyau. Deux sous-ensembles flous A et B de X sont égaux si leurs fonctions d appartenance prennent les mêmes valeurs pour tous les éléments de X : x X, µ A (x)=µ B (x). Etant donné deux sous-ensembles flous A et B de X, on dit que A est inclus en B et on note A B, si leurs fonctions d appartenance sont telles que x X, µ A (x) µ B (x). En ce qui concerne les opérations d intersection et union des sous-ensembles flous, les opérateurs proposés tentent de préserver les propriétés des opérateurs utilisés pour les ensembles classiques. Deux familles d opérateurs les t-normes et les t-conormes - regroupent des opérateurs respectivement pour l intersection et pour l union. Ces familles d opérateurs respectent certains propriétés, telles que la commutativité, l associativité, etc. Le couple d opérateurs t-norme et t-conorme qui conserve le plus de propriétés des opérateurs classiques est formé par les opérateurs min et max. Une autre t-norme utilisée est le produit. Pour les t-conormes on retrouve également la somme bornée ( (a,b)=min(a+b,1)) et la somme probabiliste ( (a,b)=a+b-ab) [Dubois et Prade 1985, Yager 1991]. En fonction de la nature de l ensemble de référence X, des sous-ensembles flous numériques et des sous-ensembles flou linguistiques sont obtenus. Les informations numériques constituent des variables numériques floues [Zadeh 1975] et consistent dans l extension d un nombre ou d un intervalle de réels, à savoir les nombres et les intervalles flous [Dubois et Prade 1978]. Leur définition se fait à travers celle de quantité floue.

99 OMEGA/LDM : Le Langage de Définition du Monitoring Une quantité floue est un sous-ensemble flou normalisé Q de 3. Une valeur modale de Q est un élément m de 3 tel que µ Q (m)=1. Un intervalle flou I est une quantité floue convexe. Un intervalle flou décrit un intervalle de réels aux limites imprécises. Nous notons les intervalles flous [a # b # c # d], où l intervalle des nombres réels [a,d] représente le support et l intervalle [b,c] représente le noyau. Les nombres flous sont des intervalles flous caractérisés par une valeur modale unique. Un nombre flou correspond à un nombre réel dont la valeur précise n est pas toujours connue. Nous notons un nombre flou [a # b # c], où l intervalle [a,c] représente le support et b est la valeur modale. Si l ensemble de référence X contient des valeurs linguistiques (c est-à-dire des mots) un ordre est généralement établi entre les éléments de X (X est une échelle ordinale). Un sousensemble flou A de X est représenté par le degré d appartenance au sous-ensemble A pour chaque terme linguistique X. Plus précisément, pour chaque terme linguistique de X il est indiqué à quel point celui-ci est un membre typique du sous-ensemble A. Si X contient les termes linguistiques {T1, T2,, Tn}, ou n est un entier, alors le sous-ensemble flou A de X est noté par convention sous la forme {µ A (T 1 )/T 1, µ A (T 2 )/T 2,, µ A (T n )/T n }. Si pour un univers linguistique L considéré il existe un univers numérique correspondant N, le passage d une représentation à l autre peut se faire à l aide des deux applications : la signification 42 et la description [Zadeh 1971, OFTA 1994]. La signification, notée M, est une application depuis un univers linguistique L vers l ensemble des parties floues d un univers numérique N, noté F(N), qui associe à chaque terme linguistique de L un sous-ensemble flou numérique de N. La description, notée D, est une application depuis un univers numérique N vers l ensemble des parties floues d un univers linguistique L, noté F(L), qui associe à chaque élément de N un sous-ensemble flou linguistique de L. Exemple. Considérons le cas de la complétude d une tâche (ou processus) en tant que travail accompli par rapport au travail total qui doit être réalisé. 1 µ M M(petite) M(moyenne) M(grande) 1 µ D(55) N complétude petite moyenne grande L Complétude Figure IV.23 La correspondance entre l univers linguistique et numérique pour la complétude en utilisant des significations numériques et description linguistique floues Un univers numérique pour cet attribut est l intervalle [0,100], qui représente le pourcentage du travail réalisé. Un univers linguistique pour la complétude contient des termes 42 La terminologie anglophone est «meaning» 85

100 Chapitre IV linguistiques tels que {petite, moyenne, grande}. La figure IV.4 montre la correspondance entre ces deux univers. La signification numérique de chaque terme linguistique est donnée par : M(petite)=[0 # 0 # 25 # 50], M(moyenne)=[25 # 50 # 75] et M(grande)=[50 # 75 # 100 # 100]. La description de la valeur de 55% est D(55)={0/petite, 0.8/moyenne, 0.2/grande}. OMEGA permet aussi bien la représentation et l analyse des informations numériques que des informations linguistiques. Si les valeurs d attributs considérés peuvent être imprécises ou incertaines, elles seront représentées sous la forme de sous-ensembles flous (numériques ou linguistiques). Dans le cas d utilisation des informations linguistiques, le formalisme OMEGA/LDM permet la définition des significations numériques de chaque terme défini dans l univers de représentation (si un univers numérique correspondant existe). Les modèles de monitoring sont construits par des concepteurs de processus de monitoring. Les significations numériques pour les termes linguistiques peuvent être fournies par un expert du domaine (par exemple par un bon manager du processus). Il fournit au concepteur directement les courbes ou le concepteur lui demande sur quelle partie de l univers numérique la propriété décrite par le terme linguistique est absolument satisfaite, ce qui détermine le noyau de sa fonction d appartenance 43, et sur quelle partie elle n est absolument pas satisfaite, ce qui détermine l extérieur du support de la fonction. Ces fonctions sont par la suite ajustées empiriquement, en fonction des performances du système. Notons qu il existe des travaux sur l obtention des fonctions d appartenance dans un contexte de psychologie cognitive, par exemple [Norwich et Turksen 1984]. IV Des traitements portant sur des informations imprécises Les applications de signification numérique et description linguistique que nous avons présentées dans la section précédente constituent déjà une forme d analyse, qui permet de déduire une représentation alternative pour la valeur d une information donnée. En plus de ces analyses, certains mécanismes sont utilisés afin de travailler avec les représentations floues. Traitement des informations numériques Les informations numériques imprécises sont représentées sous la forme des nombres et des intervalles flous (des quantités floues). Il peut s avérer nécessaire lors d analyses faites par le monitoring de faire des calculs avec des informations numériques floues. Des opérations arithmétiques ont été proposées afin de travailler avec des nombres et des intervalles flous [Bouchon 1995]. Ces opérations s appliquent à des quantités floues et ont comme résultats des quantités floues. Les opérations peuvent être unaires ou binaires. Leur résultat est une autre quantité floue. Exemples des opérations sont : l opposé de Q, le produit par un scalaire (opérations unaires), ou encore l addition, le produit, la soustraction, le maximum, le minimum (opérations binaires). Traitement des informations linguistiques La théorie des possibilités a été introduite en 1978, également par L.A. Zadeh [Zadeh 1978a, Zadeh 1878b], pour permettre de manipuler des incertitudes de nature non probabiliste (auxquelles les moyens classiques de la théorie des probabilités n apportent pas de solution), et pour constituer un cadre dans lequel les informations imprécises et incertaines peuvent 43 Nous faisons ici référence à la fonction d appartenance du sous-ensemble flou associé à travers la signification numérique. 86

101 OMEGA/LDM : Le Langage de Définition du Monitoring coexister et être traitées conjointement. La théorie des possibilités repose sur les concepts de mesure de possibilité et mesure de nécessité. Etant donné un ensemble de référence X, on attribue à chaque événement défini sur X, c est-àdire à chaque élément de l ensemble P(X) des sous-ensembles ordinaires de X, un coefficient dans l intervalle [0,1] exprimant à quel point cet événement est possible. A la différence de la mesure de probabilité, la mesure de possibilité élimine la propriété d additivité, qui est remplacée par une propriété de maximité. La mesure de possibilité indique à quel point un événement A est possible. Cependant, cette information n est pas suffisante afin de décrire l incertitude existante sur cet événement, les concepts de degré de certitude est degré de possibilité garantie étant utilisés afin de compléter l information sur A. Ainsi, le degré avec lequel la réalisation de A est certaine est indiqué par l intermédiaire d une mesure de nécessité, grandeur duale d une mesure de possibilité 44. Elle attribue, elle aussi, un coefficient compris entre 0 et 1 à toute partie de X, [Dubois et Prade 1980, OFTA 1994], degré plus petit que celui de possibilité (la mesure dont un événement est possible est plus grande ou égale à la mesure dont il est certain). Afin d illustrer ces concepts, considérons que l événement A se traduit par «x A», où x est une variable sur U. La connaissance sur x est codée par une distribution de possibilité π x qui associé à chaque valeur de U un degré de possibilité 45. Avec ces notations, la mesure de possibilité de A, notée Π(A), la mesure de nécessité notée N(A) et la mesure de possibilité garantie notée (A) sont obtenue en utilisant les suivantes formules : Π(A)=sup u A π(u) ( IV.1 ) N(A)= inf u A 1-π(u) ( IV.2 ) (A)=inf u A π(u) ( IV.3 ) Les informations linguistiques sont analysées en utilisant des propositions et des règles floues. Etant donné un univers linguistique L, une proposition floue élémentaire est définie à partir d une variable V définie dans L par la qualification «V est A», où A L. La valeur de vérité d une proposition élémentaire est définie par la fonction d appartenance µ A de A. Ainsi la valeur de vérité pour la proposition «V est A» est donnée par µ A (V). Une proposition floue générale est obtenue par l utilisation conjointe de propositions floues élémentaires «V est A», «W est B» pour des variables V, W supposés noninteractives. Une règle floue est une proposition floue de la forme «si p alors q» utilisant une implication entre deux propositions floues quelconques p et q. Les règles floue peuvent avoir de plus un degré de confiance, qui représente la confiance que l expert qui fournit la règle a dans la validité de la règle. Dans le système de monitoring, le degré de confiance est généralement un nombre entre réel dans l intervalle [0,1]. Cependant il peut prendre comme valeur un sous-ensemble flou numérique, pour les cas dans lesquels les degrés de confiance ne peuvent pas être exprimés d une manière précise. Le degré de confiance peut être dans ce cas associé à un quantificateur flou. 44 Π(A)=1-N( A), où A est un événement, A son complément, Π la mesure de possibilité et N la mesure de nécessité 45 Cette distribution de possibilité est associé à une fonction d appartenance 87

102 Chapitre IV Le système de monitoring utilise des règles floues avec une seule conclusion (qui est ainsi une proposition floue élémentaire). Les propositions utilisées dans la prémisse forment une conjonction. Nous avons choisi de définir le degré de véracité d une conjonction de prémisses par le produit 46 des degrés de véracité de chacune des propositions élémentaires qui forment la prémisse. Nous utilisons cet opérateur afin de prendre en compte de manière plus sévère que le min toutes les propositions de la prémisse. Dans le modèle d analyse les règles floues sont utilisées pour les attributs linguistiques indirects, c est-à-dire des attributs qui ont une représentation linguistique et dont la valeur dépend de celles d autres attributs. Ainsi, si nous considérons deux attributs A et B qui possèdent des représentations linguistiques dans les univers {A 1, A 2,, A n } et {B 1, B 2,, B m }, la valeur d un troisième attribut C représenté sur l univers {C 1, C 2,, C p } peut être obtenue en utilisant un ensemble de règles de la forme : 88 Si A est A i et B est B j alors C est C k, où i {1,.., n}, j {1,.., m} et k {1,.., p} Plusieurs interprétations peuvent être données aux règles floues [Dubois et Prade 1993]. Celles utilisées par le système de monitoring sont donnée par la suite : vision symbolique conjonctive des règles : plus A est typique de A i (plus le degré d appartenance de A à A i est grand) et plus B est typique de B j, plus C est typique de C k ; possibiliste : plus le degré d appartenance à la prémisse est grand, plus le degré de possibilité de la conclusion est grand. Dans la vision symbolique conjonctive des règles [Foulloy et Galichet 1995] un lien est établi entre la prémisse est la conclusion, qui sont attachées une à l autre à travers une relation. Au moment de l inférence, la conclusion est interprétée en tant qu assertion de la valeur d appartenance de C à C k. Cette vision nous permet dans le monitoring d associer des valeurs d attributs directs avec des valeurs d attributs indirects. Plus les valeurs observées pour les attributs directs sont typiques de éléments de leur domaines qui sont spécifiés dans la prémisse, plus la valeur de l attribut indirect est typique pour l élément de son univers spécifié dans la conclusion. Pour un ensemble de règles comportant les mêmes variables dans la prémisse (A et B) et dans la conclusion (C) la description de C est obtenue à partir des descriptions de A et de B. Plus précisément, µ Ck (C) est calculé en tenant compte des µ Ai (A) et µ Bj (B) (cf. formules IV.4 et IV.5, pg.89) L interprétation possibiliste considère que le degré obtenu à partir de l interprétation de la prémisse représente le degré de possibilité. Dans notre cas nous considérons le degré de possibilité garantie que C soit C k. Cette interprétation est utilisée par le système de monitoring dans un type d analyse spécial qui utilise des règles floues quantifiées : un support basique à la décision. Dans les règles utilisées dans cette analyse, les conclusions font référence à des actions correctives. Ainsi dans la conclusion «C est Ck», C k est une action corrective, et la règle est utilisée afin d inférer à partir d un certain état de faits (décrit par la prémisse), le degré de possibilité garantie que l action corrective qui doit être employée est C k.. En utilisant cette approche, nous obtenons après l inférence une classification des conclusions par rapport à leur possibilité garantie étant donnée la situation observée. L approche possibiliste nous a paru adaptée dans ce contexte, compte tenu du fait que la classification ne doit pas être stricte, et que plusieurs actions correctives peuvent avoir le même de degré de préférence étant donnée une situation observée. Dans le cas de l analyse que nous venons de mentionner, dans le modèle d analyse, nous définissons une information (l action corrective) qui est représentée dans un univers linguistique qui comporte plusieurs actions correctives. Ces dernières peuvent être appliquées afin de modifier (normalement en vue d une amélioration) la valeur d un certain attribut du 46 Nous utilisons dans ce cas le produit comme t-norme.

103 OMEGA/LDM : Le Langage de Définition du Monitoring processus. Généralement, les attributs pour lesquels on considère des actions correctives sont ceux pour lesquels des tolérances, des seuils et des alarmes ont été considérés, car ce sont des aspects du processus qu il est souhaité de garder dans certaines limites. Les actions correctives sont ainsi censées réconcilier les déviations. IV Bilan Nous avons présenté dans cette section la théorie des ensembles flous que nous utilisons pour la représentation des informations imprécise et/ou incertaines. L utilisation de cette théorie nous permet d obtenir une gradualité dans la description d informations, l appartenance d un objet à une classe prenant des valeurs comprises non pas dans l ensemble {0,1}, comme dans la théorie d ensembles classiques, mais dans intervalle [0,1]. Cette gradualité est également utilisée dans la représentation des valeurs de concordances, qui varient ainsi de la concordance totale (correspondant à une valeur égale à 1) jusqu à l inexistence totale de concordance (correspondant à une valeur égale à 0). Ces données peuvent avoir une nature numérique, cas dans lequel elles sont représentées en utilisant des nombres et des intervalles flous, ou alors linguistiques, cas dans lequel elles sont représentées comme des sous-ensembles linguistiques flous. Des représentations équivalentes (numériques et linguistiques) peuvent exister, cas dans lequel le passage d une représentation à l autre peut être réalisé. Des opérations ensemblistes peuvent être utilisées pour les deux types d informations. Pour les informations numériques des opérations arithmétiques existent également. Quant aux informations linguistiques, elles sont analysées au moyen de règles floues afin d obtenir la valeur d un autre attribut, ou bien une action corrective. IV.2 Le formalisme OMEGA/LDM Comme nous l avons mentionné précédemment, un modèle de monitoring est composé de modèles spécifiques. Ces derniers, indépendamment de leur nature (modèles de capteurs, d analyse, etc.), sont construits autour des concepts d information et de transformation. Les informations permettent de représenter les attributs du processus qui sont sujets du monitoring. Les transformations permettent de spécifier les traitements appliqués aux informations. Les informations sont représentées dans des univers de discours. Le langage OMEGA/LDM fournit des univers prédéfinis et offre des mécanismes pour en définir de nouveaux. A l intérieur d un modèle, les informations peuvent avoir des rôles spécifiques. Comme nous l avons mentionné, les modèles d analyse peuvent être utilisés pour mesurer la concordance entre le processus mis en œuvre et le processus instancié. Cette concordance concerne différents attributs du processus, qu ils soient directs ou indirects. La valeur observée de l attribut considéré est comparée à une tolérance donnée. La tolérance associée à un attribut est représentée par un ensemble contenant des valeurs cibles pour l attribut ainsi que des valeurs considérées comme des déviations acceptables. Les valeurs cibles correspondent aux valeurs contenues dans le modèle instancié. Pour un attribut indirect, ces valeurs sont calculées à partir des valeurs d attributs directs. Les déviations acceptables sont des valeurs «proches» des valeurs cibles. La tolérance pour un attribut est établie par le manager de processus, et peut être changée dynamiquement pendant l exécution du processus. A travers la tolérance le manager de processus peut établir dans 89

104 Chapitre IV quelle mesure le processus mis en œuvre doit être cohérent avec le processus instancié, pour l attribut considéré. La valeur observée de l attribut est donc comparée à la tolérance associée afin d établir le niveau de concordance pour l attribut considéré. Pour la valeur de concordance, des seuils et des alarmes peuvent être définis. Lorsqu un seuil est franchi, une alarme est déclenchée, le système de monitoring indiquant ainsi le fait que la valeur de concordance a dépassé les limites acceptables. Dans la suite de cette section, nous allons présenter en détail le langage de définition des modèles de monitoring OMEGA/LDM. La présentation des éléments du langage est faite en utilisant des extraits de la grammaire fournie dans l Annexe A. IV.2.1 Les concepts clés Comme nous l avons déjà présenté au début de ce chapitre, l approche adoptée consiste à utiliser des modèles de monitoring composites. Ainsi, un modèle de monitoring est composé de plusieurs modèles spécifiques. Même si ces modèles ont une partie liée à leur spécificité, le langage utilisé reste le même. Nous allons utiliser l appellation plus courte de modèle (ou modèle de monitoring) pour les modèles de monitoring spécifiques. Nous nous attarderons principalement sur les aspects communs à tous les modèles. La présentation des différents concepts se fera en utilisant des extraits de la grammaire du langage. La notation utilisée est EBNF 47 [ISO/IEC 1996]. IV Modèle de monitoring Un modèle de monitoring est défini par des informations et par des transformations qui sont appliquées à ces informations. Les univers de définition pour les informations sont aussi précisés ainsi que les éventuelles importations depuis d autres modèles. monitoring-model = model-specifier, Model, monitoring-model-name, ; { import, import-pattern, ; }, {universe-declaration }, {information-definition }, {transformation-definition }, EndModel ; La définition d un modèle de monitoring commence par la spécification du type de modèle, à l aide d un spécificateur de modèle model-specifier. Le nom du modèle est un identificateur (cf. Annexe A). Le spécificateur indique si le modèle est un modèle d analyse, de capteurs, d affichage (utilisé pour établir les informations qui doivent être affichées), de traçage (spécifie la partie du processus qui doit être tracée), ou encore de diffusion (indique la publication des événements pour d autres composants de l environnement, auprès d un «middleware»). model-specifier = Analyse Sensor Display Trace Publication ; Un modèle de monitoring contient quatre parties principales comprenant respectivement : les déclarations d importations, les déclarations des univers, les définitions des informations et les définitions des transformations. 47 Cette notation est présentée dans l Annexe A. 90

105 OMEGA/LDM : Le Langage de Définition du Monitoring Les déclarations des importations se font en utilisant des patrons 48 d importations, définis par : import-pattern = monitoring-model-name, [., ( * universes informations universe-name information-name )]; Un patron d importation commence avec le nom du modèle depuis lequel l importation est effectuée. L importation d un modèle peut être totale (on utilise le symbole «.*»), c est-àdire que tous les éléments sont importés : les déclarations des univers, les définitions des informations ainsi que les définitions des transformations. Si le nom du modèle depuis lequel on fait l importation est suivie par «.universes», alors toutes les déclarations des univers sont importées. Ceci signifie que dans le modèle actuel il est possible définir des informations sur les univers importés. Grâce à cette fonctionnalité, l utilisateur peut définir des modèles qui contiennent par exemple des déclarations des univers fréquemment utilisés qui pourront par la suite être utilisés dans différents modèles de monitoring. Si le nom du modèle depuis lequel on fait l importation est suivi de «.informations» alors l importation se fait pour toutes les définitions des informations, ainsi que les déclarations des univers. Cette fonctionnalité peut être utile dans le cas ou plusieurs analyses différentes se font sur les même informations et que l utilisateur souhaite construire des modèles différents pour ces analyses. Cependant l utilisation la plus courante concerne les modèles spécifiques d affichage, de traçage, de capteurs et de diffusion qui effectuent des importations à partir du modèle d analyse afin d utiliser les définitions d informations. Des importations spécifiques d un univers ou une information particulière (avec son univers) peuvent se faire en utilisant les noms qui leur ont été données. Les définitions des informations ne peuvent pas faire référence à des univers autres que ceux déclarés dans le modèle en question, ceux prédéfinis ou bien importés. Les transformations ne peuvent pas faire référence à des informations autres que celles définies dans le modèle ou importées. Nous présenterons dans ce qui suit les déclarations des univers, des informations ainsi que des transformations. IV Les univers Le formalisme fournit des univers prédéfinis et des mécanismes permettant la définition de nouveaux univers. Ainsi, la déclaration d un univers peut faire référence soit à un univers prédéfini (qui pour un besoin est redéfini) soit à une construction d univers. Une unité de mesure peut être éventuellement indiquée. universe-declaration = universe, universe-name, =, ( predefined-universe universe-construction ) {, with, unit, string-value}; La théorie des ensembles flous a été choisie afin de représenter les informations. Le formalisme permet la définition des univers contenant des valeurs nettes (correspondant à des informations précises/certaines) ou floues (correspondant à des informations qui peuvent être imprécises et/ou incertaines). Le formalisme permet la définition des univers contenant des informations numériques et linguistiques. 48 La terminologie anglophone est «pattern» 91

106 Chapitre IV Nous allons commencer par une présentation des éléments de base pour la définition des univers ainsi que la présentation des univers prédéfinis, pour poursuivre avec la présentation de la définition d univers. Les univers prédéfinis et les valeurs Les univers suivants sont fournis en tant qu univers prédéfinis : entier (noté par la suite 9), réel (noté 3), chaîne de caractères, booléen, date (sous la forme jj-mm-aaaa). Leur définition dans le cadre du formalisme sera donnée plus loin dans cette section. La définition des différentes valeurs que nous utilisons est la suivante. digit = ; positive-integer-value = digit, {digit}; integer-value = [ - ], digit, {digit}; real-value = [ - ], digit, {digit},., {digit}; date-value = digit, digit, -,digit, digit, -,digit, digit, digit, digit ; boolean-value = true false ; crisp-value = integer-value real-value boolean-value date-value; En outre, deux valeurs spéciales sont considérées, l infini négatif, noté - infinite et l infini positif, noté +infinite : infinite-values = -infinite +infinite Ces valeurs seront utilisées dans la définition des intervalles, comme nous le verrons par la suite. Les valeurs que nous venons de présenter sont des valeurs nettes. La construction des valeurs floues numériques et linguistiques est définie par : fuzzy-number = [, (real-value additive-expr), #, (real-value additiveexpr), #, (real-value additive-expr), ] ; Nous retrouvons la définition des nombres flous avec la notation que nous avons adoptée, notamment [a # b # c], où a, b et c sont des nombres réels ou des expressions qui sont évaluées à des nombres réels 49 et la relation a b c est vérifiée. [a # b # c] peut être interprété comme «environ b». Les nombres flous sont des sous-ensembles flous et la fonction d appartenance qui définit le nombre flou [a # b # c] est présentée dans la Figure IV.5 (a). Les conventions de notation suivantes sont utilisées : [b # b # b] dénote le nombre réel b ; [a # b # b] a la fonction d appartenance montrée dans Figure IV.5 (b) ; [a # a # b] a la fonction d appartenance montrée dans Figure IV.5 (c). 49 Les expressions additives seront présentées plus loin dans ce chapitre 92

107 OMEGA/LDM : Le Langage de Définition du Monitoring 1 µ [a # b # c] 1 µ [a # b # b] 1 µ [b # b # c] a b c a b b c (a) (b) (c) Figure IV.24 Les fonctions d appartenance pour les nombres flous [a # b # c], [a # b # b] et [b # b # c] Des intervalles peuvent être représentés à l aide du formalisme. La définition des intervalles d entiers, de réels et de dates est donnée ci-dessous. integer-interval = [, integer-value,,, integer-value, ], of, Integer ; real-interval = [,real-value,, real-value ], of, Real ; real-open-interval = (,(real-value infinite-value),,, (real-value infinitevalue), ), of, Real ; real-left-open-interval = (,(real-value infinite-value),,, (real-value infinitevalue), ], of, Real ; real-right-open-interval = [,(real-value infinite-value),,, (real-value infinite-value), ), of, Real ; date-interval = [, date-value,,, date-value ] ; Un intervalle d entiers [a,b] avec a 9, b 9, a b contient tous les nombres entiers compris entre a et b, a et b inclus. Les intervalles de réels font référence aux intervalles fermés et ouverts contenant des nombres réels. Ils peuvent avoir des limites non-précisées, c est-à-dire des valeurs infinies (positives ou négatives). Les intervalles de dates ont la forme [d 1, d 2 ] et contiennent toutes les dates entre d 1 et d 2, d 1 et d 2 comprises. Le formalisme permet aussi la définition des intervalles flous, c est-à-dire des intervalles dont les limites ne sont pas précises. Les intervalles flous sont considérés sur les réels. La règle syntaxique suivante donne la définition des intervalles flous. fuzzy-interval = [,(real-value additive-expr), #, (real-value additiveexpr), #, (real-value additive-expr), #, (real-value additive-expr), ] ; Nous retrouvons dans le cas des intervalles une notation similaire à celle des nombres flous. Un intervalle flou est noté [a # b # c # d], avec a 3, b 3, c 3, d 3, la relation a b c d étant vérifiée. La sémantique d un tel intervalle est «environ [b,c]». La fonction d appartenance de [a # b # c # d] est présentée dans la Figure IV.6 (a). Les notations suivantes sont adoptées par convention : [b # b # c # c] est équivalent à l intervalle fermé de réels [b,c] ; [a # b # b # d] indique que le noyau est formé d une seule valeur (la valeur b), ainsi cet intervalle est équivalent au nombre flou [a # b # d] (cf. Figure IV.5 (a)) ; [b # b # c # d] a la fonction d appartenance présentée dans la Figure IV.6 (b) ; 93

108 Chapitre IV [a # b # c # c] a la fonction d appartenance présentée dans la Figure IV.6 (c). µ [a # b # c # d] µ [b # b # c # d] µ [a # b # c # c] a b c d b c d a b c (a) (b) (c) Figure IV.25 Les fonctions d appartenance pour les intervalles flous [a # b # c # d], [b # b # c # d] et [a # b # c # c] Un cas spécial des intervalles flous est celui des intervalles avec une extrémité non définie (infinie). Ces intervalles sont notés de la manière suivante : [-infinite # -infinite # c # d] qui a la fonction d appartenance donnée dans la Figure IV.7 (a) ; pour toute valeur plus petite que c la fonction d appartenance a la valeur 1 ; [a # b # +infinite # +infinite] qui a la fonction d appartenance donnée dans la Figure IV.7 (b) ; pour toute valeur plus grande que b la fonction d appartenance a la valeur 1. 1 µ [-infinite # -infinite # c # d] 1 µ [a # b # +infinite # +infinite] a b c d (a) a b (b) Figure IV.26 Les fonctions d appartenance pour les intervalles à limites infinies Nous avons présenté jusqu à maintenant la représentation des différentes valeurs numériques. Nous passons à présent à la représentation des informations linguistiques. Les valeurs linguistiques qui peuvent être représentées sont des caractères, des chaînes de caractères, des sous-ensembles linguistiques flous, etc. : 94 letter = A... Z a... z ; char = letter digit _ -., ; string = {char}; symbol-value =,string, ; string-value =,string, ; identifier = letter, {char}; comment = line-comment closed-comment ; line-comment = /, /, string ; closed-comment = /, *, string *, / ;

109 OMEGA/LDM : Le Langage de Définition du Monitoring Les commentaires peuvent être des commentaires sur une ligne (contiennent tous les caractères d une ligne après le groupement «//»), ou encore des commentaires qui ont le début et la fin marqués respectivement par «(*» et «*)». Les univers d énumération ont la forme suivante : enumeration-universe = {,symbol -value, {,, symbol -value }, } ; Les valeurs contenues dans ces univers sont appelées des termes linguistiques et sont énumérées entre des accolades, séparées par des virgules. Les termes linguistiques sont des symboles et sont indiqués entre des guillemets. Les informations linguistiques peuvent être définies soit comme des symboles, cas où elles forment un sous-ensemble classique avec une valeur, soit comme des sous-ensembles flous qui indiquent le degré d appartenance pour chacun des termes linguistiques de l univers. fuzzy-linguistic-subset = {, flit, /, symbol-value, {,, flit, /, symbol-value }, } symbol-value; flit = 0 1 ( 0,., digit, {digit}); Dans les cas où les valeurs d appartenance sont seulement 0 ou 1, le sous-ensemble est un sous-ensemble classique de l univers considéré. Des fonctions sont fournies dans le formalisme pour manipuler les termes linguistiques flous. Nous mentionnons : membership(symbol S, fuzzy-linguistic-subset A) qui retourne le degré d appartenance affecté au symbole S pour le sous-ensemble flou A ; size(enumeration-universe E) retourne le nombre d éléments de l univers E. Les différents univers prédéfinis sont les suivants : predefined-universe = integer-universe real-universe String enumerationuniverse date-universe Boolean ; enumeration-universe = {, symbol-value, {,, symbol-value }, } ; integer-universe = Integer int-interval; real-universe = Real real-interval real-open-interval real-left-openinterval real-right-open-interval; date-universe = Date date-interval; Dans la section suivante nous allons présenter la manière dont des univers peuvent être construits. La construction des univers Les univers dans lesquels les informations sont définies sont soit prédéfinis, soit construits. La construction des univers est réalisée en utilisant la règle syntaxique suivante : universe-construction = (universe-name, { [,[positive-integer-value], ] },) ( fuzzy, real-universe, [ imprecision, real-value]) ( fuzzy, enumeration-universe); Cette règle indique trois alternatives possibles. La première permet la construction des vecteurs avec des éléments dans un univers donné, la deuxième permet de créer des univers numériques acceptant des valeurs floues et la troisième permet de spécifier qu un univers linguistique (énumération) peut accepter des valeurs floues (des sous-ensembles flous). Nous allons examiner ces possibilités. 95

110 Chapitre IV Construction des vecteurs Les vecteurs sont construits sur un univers qui indique le type des éléments du vecteur. Les vecteurs peuvent avoir plusieurs dimensions. La dimensions est indiquée par le nombre de paires de crochets «[]». Entre les crochets il peut être indiqué (ou non) un nombre entier positif. Ce nombre indique la taille du vecteur pour la dimension considérée. Ainsi Real[] représente un vecteur unidimensionnel de nombres réels avec une taille non précisée, et Real[6] représente un vecteur unidimensionnel de nombres réels de taille 6. Si la taille est indiquée, elle ne peut pas changer pendant l exécution, tandis qu une déclaration sans taille précisée peut changer pendant l exécution. De la même manière Real[4][5] représente un vecteur bi-dimensionnel, c est-à-dire une matrice avec 4 lignes et 5 colonnes. La fonction size retourne le nombre des éléments du vecteur. Construction des univers numériques Les univers numériques que nous définissons à travers la règle syntaxique précédemment indiquée sont des univers qui acceptent des sous-ensembles flous. Ils sont définis sous une des formes suivantes : fuzzy Real imprecision k, où k 3. Ceci signifie qu une information définie sous cet univers peut être un nombre flou ou un intervalle flou (sachant que les nombres et les intervalles classiques en font partie). Le facteur k indique le niveau d imprécision toléré, c est à dire dans le cas des nombres flous l écart maximal entre la valeur modale et les extrémités de leur support, et dans le cas des intervalles flous l écart maximal entre une extrémité du noyau (gauche ou droite) et l extrémité correspondante du support. fuzzy [n,m] imprecision k, où k 3 ; ceci signifie que l univers est représenté par des nombres et intervalles flous compris dans l intervalle fermé [n,m] 50. La signification du facteur k est la même que dans le cas précédent. Nous allons indiquer les conditions qui doivent être respectées par n, m et k dans le cas des univers définis sur des intervalles fermés. Le cas des intervalles ouverts est similaire. Les relations suivantes sont vérifiées : n m, k<(m-n)/2. Les valeurs suivantes sont possibles dans cet univers : des nombres réels dans l intervalle [n,m] ; des intervalles réels de la forme [a,b], où n a b m ; des nombres flous de la forme [a # b # c] où les relations suivantes sont vérifiées : a b c ; n a, c m ; b-a k, c-b k ; des intervalles flous de la forme [a # b # c # d], les relations suivantes sont vérifiées : a b c d ; n a, d m ; b-a k, d-c k. 50 Des définitions similaires existent pour les intervalles ouverts (n,m), ouverts à gauche (n,m] ou ouverts à droite [n,m). 96

111 OMEGA/LDM : Le Langage de Définition du Monitoring Si l imprécision k n est pas indiquée, elle peut prendre n importe quelle valeur, à la condition que le support de la quantité floue considérée reste dans l univers précisé. Si l univers est l ensemble de nombres réels, alors la valeur k n a pas une limite définie. Si l univers est un intervalle [n,m], alors la valeur de k peut varier entre 0 et m-n. Exemple. Prenant le cas d un univers défini fuzzy [20,30] imprecision 2, univers dans lequel la durée d une activité (en jours) est indiquée. Nous savons ainsi qu une telle durée varie entre 20 et 30 jours et que le niveau de précision avec lequel la durée doit être indiquée varie jusqu à 2 jours. Cependant les valeurs s éloignant du noyau sont de moins en moins représentatives. La durée de l activité peut être par exemple [21 # 23 # 25]. Le niveau d imprécision k est indiqué par la personne qui définit l univers et qui utilise son expérience et le niveau de précision qu elle veut obtenir. Il permet de garder sous contrôle le niveau d imprécision, car les agents qui doivent fournir des valeurs pour les informations représentées sous ces univers sont obligés à respecter le niveau d imprécision toléré. Construction des univers linguistiques Nous faisons ici référence aux univers linguistiques qui acceptent des sous-ensembles flous. Leur définition a la forme fuzzy enumeration-universe, où enumeration-universe est l univers linguistique. Nous remarquons le fait que ces constructions peuvent être combinées de la manière suivante : il est possible de définir un univers numérique ou bien linguistique, et par la suite définir un vecteur qui prend ses éléments dans cet univers. Par exemple nous pouvons obtenir ainsi un vecteur qui a comme éléments des nombres flous. Exemples. Voici les définitions de deux univers alternatifs pour la complétude d une activité : universe Completude = fuzzy [0,100] imprecision 10 with unit pour-cent ; universe CompletudeLinguistique = fuzzy { tres basse, basse, moyenne, haute, tres haute } ; Dans le premier univers de complétude nous considérons des nombres et intervalles flous dans l intervalle [0,100] représentant la complétude en pourcentage. Dans le deuxième univers, des variables linguistiques floues peuvent être considérées. Bien évidemment une correspondance peut être établie entre les deux univers. Ceci va être présenté dans la section dédiée aux transformations. Des exemples de valeurs de complétude numérique sont : 45 %, [40 # 50 # 60] % (ce qui correspond à «environ 50 %»), ou encore [0 # 0 # 20 # 30] % (ce qui correspond à «environ moins de 20 %»). Concernant la représentation linguistique il existe des valeurs telles que : très basse ou {0/ très basse, 0.4/ basse, 0.6/ moyenne, 0/ haute, 0/ très haute } ce qui correspond à une complétude qui peut être décrite comme étant entre basse et moyenne, mais plus proche de moyenne que de basse. Voici d autres définitions d univers : universe MomentLinguistique = fuzzy { avant, tout debut, debut, milieu, fin, tout au fin }; universe Progres = fuzzy { manque, presque manque, extremement en retard, tres en retard, en retard, legerement en retard, a temps, legerement en avance, en avance, tres en avance, extremement en avance }; Ces deux univers sont des univers linguistiques qui acceptent des sous-ensembles flous. Le premier contient des termes qui font référence à la position en temps par rapport aux délais, 97

112 Chapitre IV plus précisément par rapport à la date de début et la date de fin de l activité ou processus considéré. Le deuxième est utilisé pour représenter le progrès 51 d une activité ou d un processus. Il indique si ces derniers sont en avance, en retard ou bien à temps par rapport aux délais. Les termes manqué et presque manqué indiquent des situations extrêmement négatives. Les univers linguistiques que nous venons de définir sont ordonnés. Ils contiennent un centre sémantique qui correspond à une situation neutre [Bonissone and Decker 1986, Novak 1986, Herrera and Herrera-Viedma 1998]. Dans le cas du progrès le centre sémantique est à temps. Les autres termes sont situés symétriquement par rapport au centre sémantique. Nous retrouvons ainsi à la gauche du centre sémantique des termes avec une connotation négative (être en retard) et à la droite des termes avec une connotation positive (être en avance). IV Les informations Les informations sont modélisées en utilisant les univers de représentation. Comme nous venons de montrer dans la section précédente, l univers indique déjà les types de valeurs que les informations peuvent avoir (par exemple si une représentation imprécise peut être acceptée). La définition des informations se fait en utilisant les règles syntaxiques suivantes : information-definition = [specifier], information, information-name, :, (universe-name universeconstruction predefined-universe ), ; ; information-name = identifier ; specifier = tolerance conformance threshold alarm instantiation ; En fonction de l univers de représentation, l information peut être linguistique ou numérique, et avec ou sans représentation imprécise possible. Chaque information a une source, qui peut être un capteur (humain ou logiciel 52 ) ou bien une transformation pour laquelle l information est une sortie. La notion de source est ici considérée depuis un point de vue interne au modèle. Cependant, les capteurs (humains ou logiciels) font référence à des sources externes au modèle, plus précisément à des attributs du processus qui sont directement mesurables. La définition d une information commence par un spécificateur qui indique le rôle spécifique que l information peut avoir. Les modèles d analyse peuvent contenir des informations qui ont un rôle particulier. Ainsi on retrouve des valeurs tolérées, des valeurs de concordance, des alarmes et des seuils. C est à travers les spécificateurs que les rôles sont indiqués. La présence de telles informations avec rôle spécifique est optionnelle dans le modèle d analyse. La signification de chacun des spécificateurs fournis est présentée ci-après. Le spécificateur tolerance est utilisé afin d indiquer que l information représente une tolerance. Dans le cas ou la tolérance est un sous-ensemble flou, son noyau indique généralement les valeurs cibles, et le reste du support les déviations acceptées (avec le degré d acceptabilité). Ainsi une valeur cible a un degré d appartenance 1. La source de cette information est un capteur humain, car c est l agent du processus (le manager du processus), qui fournit cette information. 51 Nous comprenons dans ce contexte le terme de progrès d une manière similaire à celui de progression, c est-àdire en tant qu avancement, et non pas comme amélioration. 52 Dans le cas des capteurs logiciel l intervention d un agent du processus dans le processus de mesure n est pas nécessaire. 98

113 OMEGA/LDM : Le Langage de Définition du Monitoring Les informations précédées par le spécificateur conformance sont des informations qui représentent des valeurs de concordance entre la valeur d un attribut et la tolérance qui lui est associée. Une valeur de concordance indique dans quelle mesure un attribut est membre de l ensemble des valeurs tolérées qui lui est associé. Les sources des valeurs de concordance sont des transformations qui calculent la concordance entre une information et la tolérance associée. L univers de représentation est en général l intervalle [0,1], mais d autres représentations alternatives peuvent être considérées, numériques ou bien linguistiques. Cependant une correspondance peut être établie entre ces représentations alternatives et l intervalle [0,1]. Un exemple de représentation linguistique alternative peut contenir des valeurs telles que nulle, basse, moyenne, haute, totale. Le spécificateur threshold indique que l information est un seuil pour une autre information (dans la plupart des cas pour une valeur de concordance). La source de cette information est généralement un capteur humain, car ce sont à nouveau les agents de processus qui établissent les valeurs de seuils, en fonction du contexte d utilisation du modèle. Les seuils sont représentés dans les mêmes univers que les informations auxquelles ils sont attachés. En utilisant le spécificateur alarm devant une information, nous indiquons que l information représente une alarme. La source de cette information est toujours une transformation qui compare une information avec un seuil qui lui est associé. Les alarmes nécessitent généralement un traitement spécial. Si un modèle d affichage est utilisé, l activation des alarmes peut par exemple être accompagnée d un message d avertissement. De même, si un modèle de diffusion est utilisé, l événement qui contient la valeur de l alarme peut être émis en priorité. Les valeurs des alarmes peuvent aussi bien être numériques que linguistiques. L univers de l alarme peut contenir deux valeurs : activée et désactivée. Le même univers peut cependant contenir plusieurs valeurs possibles, indiquant différents niveaux d alarme. Une alarme spéciale concerne le niveau de concordance, mais il peut y avoir d autres alarmes, qui concernent d autres valeurs que celle de la concordance. Les spécificateurs que nous venons de présenter sont utilisés dans les modèles d analyse. Le spécificateur instantiation est utilisé afin d indiquer le fait que l information concernée est utilisée dans l instanciation du modèle. La valeur de cette information est établie au moment où le modèle est instancié, et elle ne change pas de valeur pendant l exécution. Les informations qui ne sont pas précédées par un spécificateur sont soit des informations brutes, c est-à-dire des informations qui doivent être collectées, soit des résultats d analyses qui n ont pas de rôle spécifique. Certaines dépendances peuvent être déduites à partir des définitions des différentes informations à rôle spécifique, comme par exemple dans le cas où le modèle a une information représentant une valeur de concordance, il doit contenir une information représentant un attribut ainsi qu une information contenant des valeurs tolérées associées à cet attribut. Exemples. Voici quelques définitions d informations : information completuden : Completude ; information complétudel : CompletudeLinguistique ; information dpd : Date; // représente la date planifiée du début d activité information dpf : Date; // représente la date planifiée de fin d activité information dateactuelle : Date; information moment: MomentLinguistique ; information progresobserve : Progres ; tolerance information toleranceprogres : Progres ; conformance information valeurconcordanceprogres : [0,1] of Real; threshold information seuilprogres : [0,1] of Real; alarm information alarmeprogres : { active, desactive }; 99

114 Chapitre IV Dans ces définitions nous retrouvons des informations (completuden, completudel, moment, progresobserve et toleranceprogres) définies sur des univers précédemment définis (cf. section IV.2.1.2), deux informations dpd et dpf qui sont définies sur un univers prédéfini avec unité de mesure implicite (Date) et une information qui est définie sous un univers prédéfini (Real) en indiquant l unité de mesure. Une partie de ces informations représente des informations spécifiques, telles qu une tolérance définie sur l univers du progrès, une valeur de concordance considérée dans l intervalle [0,1]. Un seuil (seuilprogres) est défini dans l intervalle [0,1], ainsi qu une alarme (alarmeprogres) avec deux valeurs linguistiques possibles, activée et désactivée. IV Les transformations Nous faisons la distinction entre deux classes de transformations : des transformations utilisées pour des calculs ; des transformations utilisées pour la communication. Les transformations utilisées pour des calculs sont, dans la plupart des cas, présentes dans le modèle d analyse. Les transformations utilisées dans la communication sont des transformations que nous trouvons dans les modèles autres que celui d analyse, notamment dans le modèle de capteurs, le modèle d affichage, le modèle de traçage et le modèle de diffusion. La règle syntaxique qui donne la définition des transformations est la suivante : transformation-definition = calculus-transformation-definition communicationtransformation-definition; Dans les sections suivantes, nous présenterons ces deux types de transformations, ainsi que leur utilisation dans des différents modèles. IV.2.2 Les transformations de calcul Les transformations de calcul ont plusieurs entrées, une sortie et une partie statement.. Les entrées et les sorties sont représentées par des informations. Les informations indiquées en entrée ou en sortie doivent être définies dans le modèle d analyse considéré ou bien être le sujet d une importation depuis un autre modèle. calculus-transformation-definition = transformation, transformation-name, {, { input, information-name, {,, information-name} ; }, output, information-name, ;, statement, statement, ;, } ; Les entrées sont indiquées dans la partie input de la transformation. Les transformations de calcul ont une seule sortie, qui est indiquée dans la partie output. La manière dont la sortie peut être obtenue à partir des entrées est indiquée dans la partie statement de la transformation. Différentes transformations peuvent être appliquées aux informations brutes, produisant des informations qui à leur tour peuvent constituer des entrées pour d autres transformations. En fonction de la nature des informations d entrée (linguistique ou numérique) et de celle de 100

115 OMEGA/LDM : Le Langage de Définition du Monitoring l information que l on veut obtenir, la partie statement change. Voici la définition de cette partie dans OMEGA/LDM : statement = modify-expression, ; iterate, (, iterator, ;, iteratorlimit, ;, statement, ) if, (, or-expression 53, ), statement,[ else, statement] ; iterator = identifier ; iteratorlimit = positive-integer identifier La partie statement peut ainsi contenir : une affectation : modify-expression que nous allons détailler par la suite ; une itération : l itération est utilisée pour pouvoir parcourir les vecteurs ; une instruction de choix. Les affectations ont la forme sortie = expression. La valeur de la sortie est donnée par l évaluation de l expression. Nous présenterons les types d expressions qui peuvent être utilisés. Les itérations sont utilisées quand la sortie de la transformation est un vecteur ou quand le calcul de la sortie implique l utilisation d un vecteur. L instruction d itération contient un iterator (entier) qui sera utilisé pour parcourir le vecteur ainsi qu un iteratorlimit qui indique le nombre d itérations. Le pas de l itération ainsi que l initialisation de iterator sont par défaut égaux à 1. A chaque itération, la partie statement de l itération est exécutée. Iterator est local à la transformation. L instruction de choix a la même interprétation que celle connue dans les langages de programmation classiques. Elle a une des formes suivantes : if (condition) statement : si la condition est vérifiée alors la partie statement est exécutée ; if (condition) statement1 else statement2 : si la condition est vérifiée alors la partie statement1 est exécutée, autrement la partie statement2 est exécutée. Nous allons par la suite voir la définition des différentes expressions qui peuvent être utilisées dans les transformations (à partir de modify-expression). IV Les expressions Les règles syntaxiques à travers lesquelles les expressions arithmétiques, relationnelles et logiques sont formées sont présentées ci-après : modify-expression = identifier, =, conditional-expression ; conditional-expression = or-expression or-expression,?, or-expression, :, conditional-expression ; or-expression = and-expression or-expression, OR, and-expression ; and-expression = equality-expression and-expression, AND, equality-expression ; equality-expression = relational-expression equality-expression, ==, relational-expression equality-expression,!=, relational-expression 53 Ces expressions contiennent des disjonctions ainsi que des conjonctions logiques, des relations de comparaison, etc. La section IV détaille la forme de ces expressions. 101

116 Chapitre IV ; relational-expression = additive-expression relational-expression, <, additive-expression relational-expression, <=, additive-expression relational-expression, >, additive-expression relational-expression, >=, additive-expression ; additive-expression = multiplicative-expression additive-expression, +, multiplicative-expression additive-expression, -, multiplicative-expression ; multiplicative-expression = unary-expression multiplicative-expression, *, unary-expression multiplicative-expression, /, unary-expression ; unary-expression = primary-expression unary-operator unary-expression numeric-value size, (, identifier ) day, (, (date-value identifier), ) month, (, (date-value identifier), ) year, (, (date-value identifier), ) identifier, [, expression, ] {, [, expression, ] }(* sélection d un élément dans un vecteur *) membership rule-set conformance-expression ; unary-operator = - not ; primary-expression = identifier (, conditional-expression, ) ; ; Les valeurs numériques numeric-value peuvent aussi bien être des nombres nets que des nombres et intervalles flous. Si ces derniers sont par la suite utilisés dans des expressions multiplicatives, additives et relationnelles, les opérations utilisées seront les opérations floues. La fonction size s applique aussi bien aux vecteurs qu aux univers d énumération. Les fonctions day, month et year sont utilisées pour manipuler des dates et permettent d obtenir respectivement le jour, le mois et l année d une date considérée. Le non-terminal membership fait référence aux manipulations des fonctions d appartenance. Deux autres non-terminaux ont une utilité spéciale : rule-set pour travailler avec des ensembles de règles, et conformance-expression pour faire des calculs de concordance. IV Les fonctions d appartenance Les fonctions d appartenance sont utilisées de deux manières différentes : pour obtenir le degré d appartenance d une information à un certain sous-ensemble flou ; pour faire le passage d une représentation numérique à une représentation linguistique, en utilisant un ensemble de fonctions d appartenance. La règle syntaxique suivante illustre cette situation : membership = membership-expression membership-function-set ; 102

117 L appartenance à un sous-ensemble flou OMEGA/LDM : Le Langage de Définition du Monitoring A l aide de membership-expression, le degré d appartenance à un sous-ensemble flou peut être établi. Deux cas sont distingués : l appartenance d un nombre réel à un sous-ensemble flou numérique (un nombre flou ou un intervalle flou) ; l appartenance d une valeur linguistique à un sous-ensemble flou linguistique. Voici comment cette appartenance s exprime en OMEGA/LDM : membership-expression = membership, (, (((real-value identifier),,,(identifier fuzzy-number fuzzy-interval)) ((symbol-value identifier),,,(fuzzy-linguistic-subset identifier)) ) ; Par exemple : membership (50, [40 # 60 # 70 #80]) retournera la valeur 0.5 ; membership ( basse, { 0/ très basse, 0.8/ basse, 0.2/ moyenne, 0/ haute, 0/ très haute } retournera la valeur 0.8. Les passages numérique - linguistique Comme nous l avons mentionné auparavant, il y a des informations pour lesquelles il existe des représentations numériques et linguistiques équivalentes. Cette équivalence est réalisée à l aide des ensembles de fonctions d appartenance qui, pour chaque terme de l univers linguistique mettent en correspondance un sous-ensemble flou de l univers numérique (un nombre flou ou un intervalle flou). Les règles syntaxiques suivantes donnent la définition des ensembles de fonctions d appartenance. membership-function-set = membershipfunctions, ( membership-function { membership-function } ) ; membership-function = (, symbol-value,,, (fuzzy-value fuzzy-interval), ) ; Ces expressions sont utilisées par des transformations qui font le passage d une représentation numérique à une représentation linguistique et qui : possèdent une ou plusieurs entrées ; possèdent une sortie qui est une information définie comme une variable floue linguistique ; en fonction de la valeur donnée comme entrée, le sous-ensemble linguistique flou correspondant est calculé, en utilisant les fonctions d appartenance indiquées dans la partie statement de la transformation. Dans le cadre de cette transformation, l ordre de spécification des entrées compte. La première entrée représente l information numérique pour laquelle la représentation linguistique équivalente sera calculée. Pour chacun des termes linguistiques, le degré d appartenance de cette première entrée au sous-ensemble flou numérique qui est associé au terme, donne le degré d appartenance de l information en sortie au terme linguistique. Les propriétés suivantes doivent être satisfaites par les éléments de la transformation : les chaînes de caractères qui apparaissent dans l ensemble des fonctions d appartenance doivent être des éléments de l univers linguistique ; pour tous les éléments de l univers linguistique il doit y avoir un nombre flou ou un intervalle flou associé ; 103

118 Chapitre IV les nombres flous et les intervalles flous indiqués doivent être des sous-ensembles de l univers numérique considéré ; si les nombres flous ou les intervalles flous contiennent dans leur définition des expressions additives, les indentificateurs utilisés dans ces expressions doivent figurer comme entrées de la transformation (à partir de la deuxième entrée). Exemple. A titre d exemple nous définissons deux exemples de transformations qui font le passage d un univers numérique à un univers linguistique. La première CompletudeNaL fait le passage depuis la représentation numérique de la complétude completuden à la représentation linguistique completudel. Ces deux informations ont été définies précédemment. transformation CompletudeNaL { input completuden ; output completudel ; statement completudel = membershipfunctions ( ( tres basse, [0 # 0# 20 # 30]) ( basse, [20 # 30# 40 # 45]) ( moyenne, [40 # 45# 55 # 60]) ( haute, [55 # 60# 70 # 80]) ( tres haute, [70 # 80# 100 # 100])); } Nous remarquons qu à chaque terme linguistique est associé un intervalle flou. La Figure IV.8 présente cette correspondance d une manière graphique. µ M(CompletudeLinguistique) 1 M(tres basse) M(basse) M(moyenne) M(haute) M(tres haute) Completude Figure IV.27 Correspondance numérique - linguistique pour la complétude Les fonctions d appartenance pour chacun des termes linguistiques sont données dans le modèle d analyse. Elles constituent un point de départ et sont sujettes à des réglages ultérieurs. Si ces fonctions ne sont pas représentatives pour les termes pour lesquels elle donnent la signification numérique, elles peuvent être changées. Par exemple, les fonctions que nous venons de proposer sont relativement symétriques. Ceci peut être changé si on considère que les pourcentages de la fin sont plus importants, auquel cas on doit déplacer ces fonctions vers la droite. Ainsi nous pourrons par exemple considérer qu une complétude moyenne n a pas comme correspondant numérique l intervalle flou [40 # 45 # 55 # 60] mais plutôt [55 # 60 # 70 # 75]. Voici un autre exemple de passage d'une représentation numérique à une représentation linguistique pour la position en temps par rapport aux délais (date planifiée de début et date planifiée de fin), que nous avons appelée moment. La représentation numérique est dateactuelle la représentation linguistique est moment et la transformation qui effectue le passage entre les deux est MomentNaL. 104

119 OMEGA/LDM : Le Langage de Définition du Monitoring transformation MomentNaL { input dateactuelle ; input dpd ; // date planifiée du début input dpf ; // date planifiée de fin output moment ; statement moment = membershipfunctions ( ( avant, [-infinite)# -infinite # dpd # dpd]) ( tout debut, [dpd # dpd # ((12*dpd+2*dpf)/14)# ((11*dpd+3*dpf)14)]) ( debut, [((12*dpd+2*dpf)/14)# ((11*dpd+3*dpf)/14)# ((9*dpd+5*dpf)/14)# ((8*dpd+6*dpf)/14)) ( milieu, [((9*dpd+5*dpf)/14) # ((8*dpd+6*dpf)/14) # ((6*dpd+8*dpf)/14)# ((5*dpd+9*dpf)/14)) ( vers la fin, [((6*dpd+8*dpf/14) # ((5*dpd+9*dpf/14) # ((3*dpd+11*dpf/14) # ((2*dpd+12*dpf/14)]) ( fin, [((3*dpd+11*dpf/14)# ((2*dpd+12*dpf/14) # dpf# ((15*dpf-dpd)/14)]) ( apres, [dpf # dpf # +infinite # +infinite]) } Cette transformation utilise plusieurs entrées. La première est la date actuelle qui est la représentation numérique du moment. C est pour elle que la transformation détermine la représentation linguistique. Mais la représentation linguistique est faite par rapport aux délais considérés, notamment par rapport à la date planifiée de début et la date planifiée de fin. Les termes avant et après correspondent à des intervalles classiques. Les expressions utilisées dans la définition des intervalles flous rendent uniforme cette définition. Les supports et les noyaux sont égaux en termes de dimensions. Les termes linguistiques ainsi que leurs fonction d appartenance sont équidistants. D autres formules peuvent être utilisées dans la définition des courbes des fonctions d appartenance. L avantage de cette transformation est que les fonctions d appartenance ne sont pas fixes. Comme les dates de début et de fin d activités changent d une activité à l autre, les fonctions d appartenance changent aussi. Mais elles auront toujours la même forme. Plus précisément, la multiplication par un scalaire pourrait faire le passage d un ensemble des fonctions d appartenance à un autre. IV Les traitements des informations linguistiques à l aide des règles Pour combiner les informations linguistiques nous utilisons des règles floues. Comme nous l avons vu dans la section dédiée à la logique floue, deux interprétations possibles sont utilisées par le système de monitoring : une interprétation symbolique conjonctive qui permet d agréger des informations linguistiques afin d obtenir la valeur d autres informations ; une interprétation possibiliste qui permet d obtenir le degré de possibilité attaché à la conclusion d une règle. La règle syntaxique qui donne la définition des règles est la suivante : rule-set = rule-specifier rule set, (, rule {,, rule} ) ; rule-specifier = gradual possibilistic rule = (,symbol-value, {,, symbol-value}, ->, symbol -value, {, confidence, flit,} ) ; 54 L interprétation des règles est indiquée en utilisant un spécificateur au début de la définition ( gradual pour les règles à interprétation symbolique conjonctive et possibilistic pour les 54 Nous rappelons que flit représente les nombres réels dans l intervalle [0,1] 105

120 Chapitre IV règles à interprétation possibiliste). Bien que leur écriture soit identique, les inférences se font d une manière différente. Les ensembles des règles sont formés par plusieurs règles, chacune mise entre parenthèses. La présence des degrés de confiance n est pas obligatoire. Une règle sans degré de confiance et avec deux prémisses aura la forme (a, b -> c), où a et b sont les prémisses et c est la conclusion. Si la même règle est quantifiée, elle aura la forme (a, b -> c confidence q), où q représente le degré de confiance et prend des valeurs dans l intervalle [0,1]. Quand le degré de confiance n est pas précisé nous considérons que la confiance dans la règle est maximale, c est-à-dire que q=1. Nous présentons dans ce qui suit, la manière dont l inférence est faite ainsi que la signification des résultats pour chacune des interprétations fournies. Des exemples d utilisation seront donnés. Règles floues avec vision symbolique conjonctive Nous considérons à ce stade la forme suivante d écriture des règles, ce qui nous permettra de mieux expliquer leur signification ainsi que le processus d inférence : Si Λ i (X i est A i ) alors Y est B, avec Q Dans cette règle, X i (i=1,n) sont des informations linguistiques qui sont agrégées (chacune définie dans un univers U i ) et A i sont des termes de leurs univers de représentation respectifs. Λ représente la conjonction qui est appliquée aux propositions élémentaires «X i est A i». Y est une variable linguistique définie dans un univers U a et représente le résultat de l inférence. Q est le degré de confiance associé à la règle. La vision symbolique conjonctive des règles [Foulloy et Galichet 1995] est utilisée, comme nous l avons précisé, afin de calculer la valeur de l information linguistique Y. En partant des degrés d appartenance µ Ai (X i ) de X i aux termes considérés A i, le degré d appartenance µ B (Y) de Y au terme linguistique B est calculé en utilisant comme t-norme le produit. Ce produit est pondéré par la valeur du degré de confiance associé à la règle. µ B (Y) = Q* i=1,n µ Ai (X i ) ( IV.4 ) Dans l ensemble des règles peuvent exister m règles ayant la conclusion Y est B. Dans ce cas le degré d appartenance de Y à B est calculé à partir des degrés calculés pour chacune de ces règles en utilisant la formule précédente (que nous notons µ jb (Y), j=1,m), en utilisant la somme bornée comme t-conorme : µ B (Y) = min { j=1,m µ jb (Y),1} ( IV.5 ) Dans la plupart des cas, les règles utilisées font l agrégation de deux variables linguistiques floues. Les transformations qu utilisent des ensembles de règles ont un nombre d entrées égal au nombre de prémisses que les règles contiennent et une sortie qui correspond à la conclusion. Les propriétés suivantes doivent être vérifiées par une telle transformation : Les entrées et les sorties sont des informations linguistiques. Pour chaque combinaison des termes contenus dans les univers correspondant aux entrées, une et seulement une règle ayant cette combinaison comme prémisse doit être fournie. L ordre des éléments dans une prémisse correspond à l ordre dont les informations ont été déclarées comme entrées de la transformation. Ainsi, le premier terme d une prémisse appartient à l univers dans lequel la première information déclarée comme entrée est définie, et ainsi de suite. 106

121 OMEGA/LDM : Le Langage de Définition du Monitoring Les règles doivent contenir seulement des termes appartenant aux univers dans lesquels les informations sont définies. Les termes indiqués dans les conclusions doivent faire partie de l univers dans lequel l information considérée comme sortie de la transformation est définie. Exemple. Voici la transformation qui définit l agrégation entre la complétude et le moment, et fournit la valeur observée du progrès. Les règles utilisées dans cet exemple n ont pas de degré de confiance associé. transformation AgregationProgres { input moment ; input completudel ; output progresobserve; statement progresobserve= gradual rule set ( ( avant, tres basse -> en avance ), ( tout debut, tres basse -> a temps ), ( tout debut, tres haute -> extremement en avance ), ( milieu, moyenne -> a temps ), ( apres, tres haute -> presque raté ), } Dans la définition précédente nous n'avons pas indiqué toutes les règles (elles sont au nombre de 35). Ces règles sont indiquées dans le Tableau IV.1. très basse basse moyenne haute très haute avant en avance en avance très en avance très en avance extrêmement en avance tout début à temps légèrement en avance en avance très en avance extrêmement en avance début légèrement en à temps légèrement en en avance très en avance retard avance milieu en retard légèrement en à temps légèrement en en avance retard avance fin très en retard en retard légèrement en retard à temps légèrement en avance tout fin extrêmement très en retard en retard légèrement en à temps en retard retard après raté raté raté raté presque raté Tableau IV.7 Le progrès, agrégation de la complétude et du moment Ce tableau contient sur la première colonne les éléments de l univers du moment par rapport aux délais. La première ligne contient les termes linguistiques de l univers linguistique de complétude. Le reste de la table contient des éléments de l univers du progrès. Chaque élément c ij (i=1..7, j=1..5) correspond à un terme de l univers du progrès et constitue la conclusion d une règle qui contient dans la prémisse le terme a i de l univers du moment et le terme b j de l univers de la complétude. Un exemple de règle contenue dans ce tableau est : Si moment est milieu et complétudelinguistique est très basse alors progrèsobservé est en retard. Cette règle indique que si une activité se situe au milieu de ses échéances et que sa complétude est très basse, alors elle est considérée en retard. L indication du progrès comme 107

122 Chapitre IV étant en retard a une connotation pro-active, car nous nous situons au milieu des délais, et non pas à leur fin. Ainsi la signification du progrès en retard indique le fait que l activité risque de ne pas avoir sa complétude en fin des délais. En adoptant une telle approche, il est possible de réagir avant l arrivée des échéances. Règles floues avec interprétation possibiliste Les règles floues avec interprétation possibiliste sont utilisées dans un type spécial d analyse, dont le but est de fournir des indications concernant des actions correctives. Celles-ci sont considérées comme souhaitables étant donné des valeurs observées par le système de monitoring pour certains aspects du processus. Nous considérons à nouveau la forme suivante d expression des règles : Si Λ i (X i est A i ) alors Y est B, avec Q Dans cette règle, X i (i=1,n) sont des informations linguistiques (définies sous un univers U i ) qui correspondent à un aspect du processus et A i sont des termes de leurs univers de représentation respectifs. Λ représente la conjonction qui est appliquée aux propositions élémentaires «X i est A i». Y est une variable linguistique définie dans un univers U a contenant des termes qui représentent des actions correctives. Y représente le résultat de l inférence. Q est le degré de confiance associé à la règle. Dans l interprétation possibiliste des règles, ces dernières sont utilisées afin de calculer les degrés de possibilité garantie pour chacune des actions correctives considérées. Ce degré indique la valeur minimale pour le degré de possibilité que l action considérée B soit l action pertinente étant donné la situation décrite par la prémisse (les termes A 1, A 2,, A n ). La faisabilité de l action est une condition nécessaire mais pas suffisante pour que une action soit considérée pertinente. Nous notons B (Y) le degré de possibilité garantie que Y soit B. Y correspond au choix d action corrective. Le résultat de l inférence donnera la valeur minimale de son degré de possibilité. Le calcul du degré de possibilité garantie pour chacune des conclusions des règles utilise comme t-norme le minimum, et pondère le résultat par la valeur du degré de confiance (s il est précisé). Autrement dit, la relation suivante est vérifiée : 108 B (Y ) Q*min i=1,n µ Ai (X i ) ( IV.6 ) L interprétation de l inférence est : le degré de possibilité que l action B soit pertinente étant donné la situation décrite dans la prémisse est d au moins Q*min i=1,n µ Ai (X i ). L inégalité B (Y) 0 ne donne aucune information, car le degré de possibilité de tout événement vérifie cette inégalité. Ainsi une règle pour laquelle il existe un i tel que µ Ai (X i ) est égal à zéro est une règle dont l inférence n apporte aucune information. Ces types de règles ne sont pas pris en compte dans le processus d inférence. La manière dont le degré de possibilité garantie est calculé quand plusieurs règles applicables ont la même conclusion change afin de prendre en compte toutes ces règles. Dans ce cas, la t- conorme utilisée est l opérateur max. B (Y) max j=1,m jb (Y) ( IV.7 ) Une transformation qui utilise un tel ensemble de règles doit vérifier les propriétés suivantes : Possède une ou plusieurs entrées correspondant à des informations linguistiques qui représentent divers aspects du processus. La sortie est une information linguistique définie sous un univers dont les termes sont des actions correctives.

123 OMEGA/LDM : Le Langage de Définition du Monitoring L ordre des éléments dans une prémisse correspond à l ordre dont les informations correspondantes ont été déclarées comme entrées. Ainsi, le premier terme d une prémisse appartient à l univers sous lequel la première information déclarée comme entrée est définie, et ainsi de suite. Les règles doivent contenir seulement des termes appartenant aux univers sous lesquels les informations sont définies. Nous remarquons que la propriété qui faisait dans le cas précédent (sur les règles à vision symbolique conjonctive) référence au fait que pour une configuration des termes en prémisse, une seule conclusion est possible n est plus imposée. Dans le cas des règles à interprétation possibiliste, il peut exister plusieurs règles avec les mêmes prémisses, mais des conclusions différentes. Etant donné une situation décrite par une prémisse, plusieurs actions correctives peuvent être appliquées. Exemple. Nous allons considérer le cas d une analyse qui offre un choix d actions correctives liées aux valeurs du progrès. Pour cette analyse nous avons besoin de définir une nouvelle information, que nous appelons actioncorrectiveprogres et qui est définie dans un univers linguistique contenant des actions correctives liées au progrès. Plus précisément, ces actions correctives pourraient être effectuées dans le cas où les valeurs observées du progrès ne font pas partie des valeurs tolérées. Des facteurs sur lesquels il faut agir quand il semble qu un projet ne va pas avoir la complétude à la date prévue de la fin, ont été identifiés [Andersen et al. 1999] : changer les dates prévues de fin ; baisser le niveau d ambition ; ajouter des ressources supplémentaires ; réorganiser la charge de travail. Changer les dates prévues de fin est une solution qui paraît évidente si on veut améliorer la valeur du progrès. Cependant, elle n est pas toujours possible, surtout dans le cas où cette date est imposée depuis l extérieur du projet (par des clients, intégration dans un plus grand projet qui dépend des résultats du projet considéré, etc.). En ce qui concerne l ajout des ressources supplémentaires cela peut se matérialiser par l ajout de personnel par exemple. La réorganisation de la charge de travail peut se réaliser par exemple en mettant des personnes plus compétentes sur les activités les plus critiques du point de vue du temps. Diminuer le niveau d ambition peut être associé par exemple au fait de diminuer les exigences par rapport auxquelles la complétude d une activité est considérée comme atteinte. Prenons l exemple d une activité de codage qui a pour but de rajouter un certain nombre de fonctionnalités à un système. La complétude de cette activité à un moment donné est estimée par rapport au nombre de fonctionnalités ajoutées (sachant que certaines pourront être partiellement ajoutées). Diminuer le niveau d ambition consiste à revoir le but de l activité, dans notre cas diminuer le nombre de fonctionnalités que l activité doit rajouter. Nous considérons aussi les actions inverses pour le cas où le projet est trop en avance : avancer la date prévue de fin, réduire les ressources allouées, augmenter le niveau d ambition. Voici les définitions de l information que contiennent les actions correctives ainsi que celle de la transformation par l ensemble des règles. information actioncorrectiveprogres : { eloignier delais, rapprocher delais, ajouter personnel, diminuer personnel, assigner personnel plus 109

124 Chapitre IV qualifié, assigner personnel moins qualifié, diminuer ambitions, augmenter ambitions } ; transformation CorrectionProgress { input progresobserve ; output actioncorrectiveprogres; statement actioncorrectiveprogres = possibilistic rule set ( ( presque manque -> eloignier delais confidence 1), ( presque manque -> diminuer ambitions confidence 1), ( extrement en retard -> eloigner delais confidence 1), ( extrement en retard -> diminuer ambitions confidence 1), ( tres en retard -> eloigner delais confidence 0.8), ( tres en retard -> diminuer ambitions confidence 1), ( tres en retard -> ajouter personnel confidence 0.3), ( tres en retard -> assigner personnel plus qualifié confidence 0.6), ( en retard -> eloigner delais confidence 0.6), ( en retard -> diminuer ambitions confidence 0.5), ( en retard -> ajouter personnel confidence 0.3), ( en retard -> assigner personnel plus qualifié confidence 0.7), ( en avance -> rapprocher delais confidence 0.2), ( en avance -> augmenter ambitions confidence 0.2), ( en avance -> diminuer personnel confidence 0.3), ( en avance -> assigner personnel moins qualifié confidence 0.2), ( tres en avance -> rapprocher delais confidence 0.7), ( tres en avance -> augmenter ambitions confidence 0.5), ( tres en avance -> diminuer personnel confidence 0.4), ( tres en avance -> assigner personnel moins qualifié confidence 0.2), ( extremement en avance -> rapprocher delais confidence 1), ( extremement en avance -> augmenter ambitions confidence 1), ( extremement en avance -> diminuer personnel confidence 0.4), ( extremement en avance -> assigner personnel moins qualifié confidence 0.2)) ; } Les règles que nous venons de proposer sont présentées dans le Tableau V.2. La première ligne présente le choix des actions correctives. La première colonne présente les différents termes de l univers du progrès. Le reste des cellules contient la valeur q ij (i=1, 11 j=1,..,8) du degré de confiance pour la règle ayant comme prémisse la proposition élémentaire «progresobserve est progress i» et la conclusion «actioncorrectiveprogress est action j». La valeur progress i fait référence au terme d index i dans l univers du progrès, et la valeur action j fait référence à l action corrective qui occupe la position j dans l univers qui contient les actions correctives. Le degré de confiance égal à zéro correspond à l inexistence de la règle en question. Ces règles sont construites par rapport à une tolérance associée aux valeurs observées du progrès qui inclut les valeurs légèrement en retard, à temps et légèrement en avance. Nous observons que pour ces valeurs, il n y pas de règles associées pour les actions correctives. Si la tolérance associée au progrès contient d autres termes que ceux qui viennent d être mentionnés, les règles qui contiennent ces termes en prémisse ne seront pas considérées comme actives, c est-à-dire elles ne seront pas prises en compte dans le processus d inférence. Exemple. Nous considérons par exemple que la tolérance au progrès contient aussi le terme en avance. Pour une valeur observée du progrès égale par exemple à {0/manqué,, 0/à temps, 0.5/légèrement en avance, 0.5/en avance, 0/très en avance, 0/extrêmement en avance} aucune règle n est déclenchée. Ainsi, les règles ayant dans leurs prémisses le terme en avance (en nombre de quatre) ne seront pas déclenchées. 110

125 éloigner délais rapprocher délais ajouter personnel OMEGA/LDM : Le Langage de Définition du Monitoring diminuer personnel assigner pers. plus qualifié assigner pers. moins qualifié augmenter ambitions diminuer ambitions manqué presque manqué extrêmement en retard très en retard en retard légèrement en retard à temps légèrement en avance en avance très en avance extrêmement en avance Tableau IV.8 Règles concernant les actions correctives pour le progrès IV Les formules de comparaison Nous traitons dans cette section les comparaisons entre des informations représentant des attributs du processus et les ensembles de valeurs tolérées qui leur sont associés. Nous traitons également les comparaisons entre les alarmes et les seuils. En utilisant les opérations arithmétiques telles que celles que nous avons proposées (cf. section IV.2.2.1), il est possible de construire des expressions de comparaison. Un exemple d une telle utilisation va être donné plus loin dans cette section. Les expressions de concordance peuvent avoir deux mesures : celle de la concordance (utilise l opérateur de concordance) et celle de distance ou éloignement (utilise l opérateur de distance). L opérateur de concordance a deux interprétations possibles, une pour les entrées numériques et une pour les entrées linguistiques. L opérateur de distance est utilisé seulement pour les informations numériques. La règle syntaxique suivante donne la définition des expressions de concordance : conformance expression = conformance-operator distance-operator conformance-operator = conformance, (,(additive-expression identifier),,, (additive-expression identifier), ) ; distance-operator = distance, (,(additive-expression identifier),,, (additive-expression identifier), ) ; Les transformations qui utilisent ces expressions doivent vérifier les propriétés suivantes : Ont au moins deux entrées et une sortie. Les types des deux paramètres indiqués doivent avoir la même nature (numérique ou linguistique). Les expressions additives ne doivent faire référence qu aux informations indiquées comme entrées. La concordance ou la distance sont calculées pour le premier paramètre (l attribut du processus) par rapport au deuxième (la tolérance). Par exemple, si l expression a la forme conformance(a,b), la transformation calcule la concordance de a par rapport à b. Plus 111

126 Chapitre IV précisément, nous avons choisi de determiner à quel point la relation a b est vérifiée dans les cas ou les quantités à comparer sont des sous-ensembles 55 et a=b dans le cas où les quantités sont des valeurs uniques. Si l expression est distance(a,b), la transformation calcule la distance entre les deux points. La sortie correspond à la valeur issue de la comparaison, donc au niveau de concordance ou bien à la distance. L utilisation la plus courante de l opérateur de concordance est faite pour calculer la concordance entre une information et un ensemble de valeurs tolérées établi pour cette information. La mesure de concordance de A à B que nous avons choisi consiste à considérer le rapport entre les éléments de A qui font partie de B (pour lesquels la propriété est vérifiée) et ceux qui ne le sont pas. Ainsi nous obtiendrons la formule suivante : min( µ A ( x), µ B ( x)) x C( A, B) = ( IV.8 ) µ ( x) x A Cette formule de concordance a la propriété que C(A,B)=0 sitôt que supp(a) supp(b)= 56 ; C(A,B)=1 si A B. Nous remarquons que dans le cas où A est une valeur nette, cette formule revient au calcul du degré d appartenance de cette valeur nette au sous-ensemble B. La valeur de la concordance se situe dans l intervalle [0,1]. Dans le cas où X est un univers numérique, A et B sont des nombres ou des intervalles flous, la concordance est équivalente au rapport entre la surface S dessinée par l intersection des fonctions d appartenance et la surface totale dessinée par la fonction d appartenance de A. S( A B) C( A, B) = ( IV.9 ) S( A) Exemple. Considérons que la concordance doit être calculée entre l information représentée par le nombre flou [50 # 55 # 60] et sa tolérance représentée par l intervalle [50 # 60 # 70 # 80]. La valeur calculée pour la concordance est La figure IV.9 présente cet exemple. intersection information appartenance [50 # 55 # 60] [50 # 60 # 70 # 80] valeurs tolérées Figure IV.28 Concordance des informations numériques 55 Dans le cas de l inclusion, la valeur le concordance est une quantification de la relation d inclusion (l inclusion est relative). 56 Nous rappelons que la notation supp(a) dénote le support de la quantité floue A. 112

127 OMEGA/LDM : Le Langage de Définition du Monitoring Dans le cas où les informations A et B sont linguistiques, la concordance est calculée en utilisant la même formule. Les valeurs x X sont dans ce cas des termes linguistiques. Exemple. Reprenons l exemple du progrès. Nous avons un ensemble de valeurs tolérées pour le progrès ainsi qu une valeur observée du progrès. Cette dernière est calculée comme l agrégation des valeurs pour la complétude et pour la position en temps par rapport aux délais. Voici la transformation qui fait le calcul de la valeur de concordance pour le progrès : transformation ConcordanceProgres { input progresobserve; input toleranceprogres; output valeurconcordanceprogres; statement valeurconcordanceprogres = conformance (progresobserve, toleranceprogres); } Comme les valeurs tolérées ainsi que la valeur observée du progrès sont des informations linguistiques dans l univers du progrès, la formule utilisée dans l interprétation de l opérateur de concordance va avoir la forme : L min( µ i C( A, B) = ( IV.10 ) µ ( L ) Li A ( L ), µ A i i B ( L )) i Le calcul de distance se fait pour les informations numériques. L approche proposé par [Zwick 87], qui consiste a considérer les informations à travers deux dimensions (leur centre de poids et la surface S délimitée par la fonction d appartenance) nous a paru adapté. Un sousensemble flou est ainsi représenté par un point dans un espace bi-dimensionnel, et l éloignement peut être calculé comme une distance euclidienne dans cet espace : D( A, B) A 2 2 = ( BG AG ) + ( S( B) S( )) ( IV.11 ) Dans la formule précédente (cf. IV.11) nous avons noté avec A G et B G les centres de gravité des sous-ensembles flous A et B respectivement. Nous présenterons ci-dessous la transformation qui fait le positionnement de l alarme alarmeprogres liée à la valeur de concordance pour le progrès. Cette transformation est basée sur une comparaison entre la valeur de concordance pour le progrès valeurconcordanceprogres et le seuil qui a été établi seuilprogres. transformation VerificationAlarmeProgress { input valeurconcordanceprogres; input seuilprogres; output alarmeprogres ; statement alarmeprogres = ((seuilprogres >= valeurconcordanceprogres)? activee : desactivee ) } Cette alarme a seulement deux valeurs possibles : activée et désactivée. Si la valeur du seuil est dépassée l alarme est activée. Si la valeur de concordance revient dans les limites considérées admissibles, l alarme est désactivée. L expression utilisée dans cette transformation afin de comparer la valeur de concordance pour le progrès avec le seuil établi pour cette valeur est une expression conditionnelle. 113

128 Chapitre IV IV.2.3 Les transformations de communication Les modèles de communication sont utilisés afin de réaliser l intégration du système de monitoring dans un certain environnement ou contexte d exécution. Ces modèles indiquent au système de monitoring où il va trouver les entrées dont il a besoin et les sorties que le système doit fournir (ainsi que le type de leur destinataire) étant donné le contexte d utilisation. Les modèles de communication utilisent les informations définies dans le modèle d analyse. Ainsi chacun des modèles de communication commence par une déclaration d importation à partir du modèle d analyse, ce qui lui permet d avoir accès à toutes les informations de ce modèle. Ces modèles utilisent aussi des informations locales, qui sont en partie des informations d instanciation. Les modèles de communication utilisent des transformations de communication. Nous distinguons deux types de transformations, respectivement utilisées dans la gestion des entrées et des sorties du système de monitoring. communication-transformation-definition = input-transformation outputtransformation Avant de passer à la présentation de ces deux types de transformations, nous rappelons que toute communication du système passe à travers des événements. Au moment du chargement des modèles de communication, des types d événement sont construits pour chacune des transformations spécifiées. Des événements de ces types sont générés pendant l exécution du système de monitoring. Par défaut les événements sont générés au moment où la valeur de l information indiquée comme entrée de la transformation change (sauf si des conditions spécifiques sont définies). IV Les transformations utilisées dans la gestion des entrées Les entrées du système sont spécifiées dans le modèle de capteurs. Ce modèle indique quelles sont les sources des informations qui sont directement mesurables dans le processus. A l aide de ce modèle il est possible de spécifier les types d événements auxquels le système OMEGA doit souscrire afin de collecter les valeurs des attributs directement mesurables. Ces attributs sont spécifiés dans le modèle d analyse sous la forme d informations. En général, ces informations ne constituent pas des sorties de transformations 57. Comme tous les autres modèles de communication, le modèle de capteurs fait une importation sur le modèle d analyse. Ceci lui permet d accéder à la définition des informations contenue dans ce modèle. Les transformations utilisées dans le modèle de capteurs ont la forme suivante : input-transformation = sensor, transformation, transformation-name, {, output, information-name, ;, statement, sensor-type, ;, [ attribut-name, =, (identifier symbol), ; ], [ attribut-type, =,(identifier symbol), ; ], [ entity-type, ( : = ), (identifier symbol), ; ], [ entity-name, ( : = ), (identifier symbol), ; ], [ process-name, ( : = ), (identifier symbol), ; ], [ source, ( : = ), (identifier symbol), ; ] [ destination, ( : = ), (identifier symbol), ; ] 57 Il existe des cas où une information peut être aussi bien collectée dans l environnement que fournie comme résultat d une analyse. Ces informations correspondent généralement à des attributs fournis par l utilisateurs, et qui peuvent avoir deux représentations possibles. La source peut ainsi soit être un capteur humain, soit la sortie d une transformation qui fait le passage d une représentation à l autre. 114

129 OMEGA/LDM : Le Langage de Définition du Monitoring } ; sensor-type = human-sensor automatic-sensor ; Une telle transformation n a pas d entrées. Sa sortie donne l information pour laquelle la transformation indique le capteur. Cette information est indiquée avec le nom qu elle possède dans le modèle d analyse. Nous rappelons que les événements auxquels le système de monitoring souscrit portent les valeurs des attributs du processus sujet. Ces attributs appartiennent à des entités du processus, qui ont un type et un nom. Les types d entités que peuvent être trouvés dépendent du métamodèle utilisé dans la modélisation du processus sujet. La partie statement indique la manière dont la valeur de l information peut être récupérée depuis l environnement. Elle commence par un spécificateur de capteur qui indique s il s agit d un capteur humain ou bien d un capteur logiciel. La partie statement est utilisée dans la construction des sélecteurs qui permettront de filtrer les événements qui portent les valeurs des attributs que l on veut mesurer. Elle possède plusieurs champs qui sont optionnels. Ces champs correspondent à des champs d événement. Pour la majorité de ces champs (sauf attribute-name and attribute-type) il est possible d indiquer une des deux possibilités suivantes. Une valeur (éventuellement à travers une information) après le signe =. Ceci signifie que ce champ va être utilisé dans le sélecteur qui va être créé afin de récupérer les messages de ce type. Par exemple, si la relation entity-type = activity est mentionnée dans l expression, alors elle sera ajoutée au sélecteur, et seulement les événements concernant les activités passeront ce filtre. Un identificateur après le signe :. Ceci signifie que la valeur du champ en question sera affectée à l information indiquée par l identificateur. Il est possible par exemple de récupérer le nom de l activité pour laquelle le changement de valeur d attribut a eu lieu (ceci est utile dans le cas où le modèle concerne des entités différentes). Le champ attribute-type contient le type de l attribut. Il peut prendre la valeur «Any», qui indique n importe quel type. Le champ entity-type contient le type d entité à laquelle l attribut appartient (par exemple activité). Le champ entity-name permet d indiquer le nom de l entité concernée, c est-à-dire son identificateur dans le processus sujet, processus qui est indiqué en utilisant le champ process-name. Le champ source indique la source de l événement. Nous entendons par ceci le composant de l environnement qui émet l événement en question. Le champ destination contient la destination de l événement. Si des valeurs ne sont pas indiquées pour des champs, il existe deux possibilités : S il s agit du nom d attribut (le champ attribut-name ), ceci est le même que celui que l information correspondante possède dans le modèle d analyse. Autrement dit, dans l environnement d utilisation du modèle, l attribut auquel l information correspond possède le même nom. Tel n est pas toujours le cas. Comme un modèle de monitoring est utilisé dans des contextes différents, le nom de cet attribut peut changer d une représentation de processus à une autre. Par exemple considérons l attribut qui représente la date prévue du début d une activité. Cet attribut peut être nommé PlannedStartingDate, PSD ou encore DatePrevueDebut, mais il reste le même attribut. Si la valeur d un champ autre que le nom d attribut n est pas indiquée dans l expression de la transformation, cela signifie que le champ en question ne constitue ni un critère de sélection, ni une valeur à récupérer. 115

130 Chapitre IV Les valeurs de ces champs peuvent être changées au moment de l instanciation du modèle de capteur. Les informations du modèle d analyse correspondent généralement à des attributs du processus sujet. Pour une telle information, si l attribut correspondant est présent dans la représentation que le support de processus possède, la valeur de l attribut va être collectée en utilisant un capteur logiciel. Nous faisons ici la supposition qu à chaque changement de valeur de l attribut, un événement est généré dans le support de processus, ce qui permet au système de monitoring de récupérer la valeur de l attribut. Si l information ne correspond pas à un attribut (comme c est le cas pour des seuils ou des tolérances) ou si l attribut auquel elle correspond n est pas représenté dans le support du processus, alors ses valeurs ne peuvent pas être collectées d une manière automatique. Elles doivent être fournies par des agents du processus. Nous parlons dans ce cas de capteurs humains et l information est collectée d une manière semi-automatique. Une interface utilisateur est utilisée pour faciliter l acquisition de cette information. Le type de capteurs est indiqué au début de l expression de sélection. Exemple. Prenons l exemple du progrès et des collections d informations qui lui sont nécessaires. Parmi les informations brutes qui doivent être collectées, nous retrouvons la valeur de la complétude. La transformation utilisée dans le modèle de capteurs afin d indiquer la collecte de cette information est donnée par : sensor transformation collectecompletude { output completudelinguistique ; statement human-sensor ; attribut-name = symboliccompleteness ; attribute-type= String ; entity-type = activity ; entity-name = Review ; process-name= ProcessOne ; source = interfaceactivityprogress ; } Cette transformation indique qu il s agit de capteurs humains, c est-à-dire c est un agent de processus qui donnera la valeur de la complétude. Dans l environnement la complétude linguistique est représentée par un attribut qui s appelle «symboliccompleteness», et qui est représenté dans le système comme une chaîne de caractères. Il s agit de la complétude de l activité «Review» du processus «ProcessOne». La source de cette information est l interface «interfaceactivityprogress». Les valeurs des champs peuvent faire référence à des informations définies au niveau du modèle de capteurs, utilisées dans l instanciation. Cette définition permet d alléger l instanciation du modèle de capteurs. Par exemple, admettons qu une partie des attributs pour lesquels les valeurs doivent être collectées soit des attributs qui ont la même source, ou appartiennent à la même entité. Le fait de déclarer des informations d instanciation (qui contiendront les valeurs des champs), permet une instanciation plus facile du modèle de capteurs, car ces valeurs ne doivent être fournies qu une fois (non pas dans chaque transformation du modèle). Exemple. Dans l exemple précédent, l information moment provient de la même interface, interfaceactivityprogress, et porte sur la même activité. Nous pouvons utiliser des définitions d informations dans le modèle de capteurs, et définir les transformations de la manière suivante : instantiation information sourcex : String; instantiation information entitytypex : String; 116

131 OMEGA/LDM : Le Langage de Définition du Monitoring instantiation information entitynamex : String; instantiation information processnamex : String; sensor transformation collectecompletude { output completudelinguistique ; statement human-sensor ; attribut-name = symboliccompleteness ; attribut-type = String ; entity-type = entitytypex; entity-name = entitynamex; process-name = processnamex; source = sourcex; } sensor transformation collectemoment{ output moment ; statement human-sensor ; entity-type = entitytypex; entity-name= entitynamex; source = sourcex; } Au moment de l instanciation de ce modèle les valeurs des informations sourcex, entitytypex, et entitynamex, processnamex sont indiquées une seule fois, et non pas dans chacune des transformations. IV Les transformations utilisées dans la gestion des sorties Les sorties du système de monitoring sont spécifiées par le modèle de diffusion, le modèle d affichage et le modèle de traçage, qui sont liés au modèle d analyse utilisé. Tous ces modèles contiennent des transformations pour spécifier des sorties. Ils ont chacun une déclaration d importation pour le modèle d analyse correspondant, afin d accéder aux définitions d informations. Les transformations de sortie utilisées dans ces modèles permettent d identifier le type d événement avec lequel les informations doivent être publiées. En effet il y a beaucoup de similitudes avec les transformations utilisées dans la gestion des entrées. Nous retrouvons dans la partie statement des transformations presque tous les éléments des transformations utilisées dans la gestion des entrées du système. La définition de ces transformations est la suivante : output-transformation = [transformation-specifier], transformation, transformation-name, {, input, information-pattern, ;, statement, [ attribut-name, :, (identifier ( (, informationname,,, identifier, ) ), ; ], [ attribute-type, :, identifier, ; ], [ entity-type, :, identifier, ; ], [ entity-name, :, identifier, ; ], [ process-name, :, identifier, ; ], [ destination, :, identifier, ; ], [ condition, :, or-expression, ; ], [ periodicity, :, every integer-value ( days hours weeks months )], ;, } ; 117

132 Chapitre IV La définition d une transformation de gestion des sorties commence avec un spécificateur. Ce spécificateur est utilisé afin de déterminer le genre de transformation. Les valeurs possibles pour le spécificateur sont liées au type de modèle : transformation-specifier = display trace publication ; A travers le spécificateur, la transformation est identifiée en tant que transformation servant pour la spécification des sorties pour l affichage (display), le traçage (trace) ou bien la diffusion vers un composant dont le type n est pas identifié (publication). Bien que la construction des messages soit identique pour les différentes destinations, ces spécificateurs sont utilisés au moment de l envoi du message. Il est possible que la communication avec les destinataires passe par différents moyens de communication. Ainsi, il est nécessaire de spécifier dans ce cas le type de destinataires. Par exemple il est possible que la communication avec l interface graphique passe par des «sockets», tandis que la communication avec d autres composants passe par un mécanisme de publication/souscription via un «middleware». Les transformations contenues dans les modèles qui gèrent les sorties du système de monitoring ont des entrées et pas de sorties. Chacune de ces transformations indique à travers ses entrées une information ou bien un groupe d informations qui constituent une sortie du système ainsi que des conditions sur la diffusion des résultats. La première entrée représente l information ou le groupe d informations qui doivent être publiées. D autres entrées supplémentaires peuvent être utilisées, comme nous allons le voir par la suite. Au moment du chargement du modèle, les transformations sont utilisées afin de déterminer pour chacune des informations qui doivent être publiées, le type d événement qui va être utilisé. Pendant l exécution, un tel événement sera généré et il contiendra la valeur de l information. Par défaut la publication d une information se fait à chaque changement de valeur. Chaque fois qu une sortie du système change, par exemple la valeur du progrès, un événement contenant la nouvelle valeur est émis (si le modèle de diffusion utilisé indique le fait que la valeur observée du progrès constitue une sortie du système). Les parties statement dans les transformations de communication La partie statement des transformations contient des champs qui donnent des indications sur la manière dont les types d événements utilisés pour la diffusion des sorties doivent être construits. Les champs mentionnés dans les transformations pour la gestion des entrées sont présents. La différence réside dans le fait que les valeurs de tous les champs doivent être indiquées, afin de pouvoir faire la publication. En effet, il ne s agit plus de construire un filtre pour retrouver les messages, mais de construire le message, ce qui demande que des valeurs pour tous les champs du modèle d événement soient fournies. Le champ indiquant la source de l événement est complété d une manière automatique par le système (contient l identificateur du système de monitoring). Des informations d instanciation peuvent être utilisées également dans les modèles qui gèrent les sorties. Les entrées des transformations peuvent représenter des groupements d informations. Comme nous l expliquerons dans la section suivante, ceci est réalisé en utilisant des patrons d informations. Les informations qui doivent être publiées sont représentées dans la première entrée de la transformation. Si la première entrée de la transformation est une seule information, le nom de l attribut correspondant est indiqué dans le champ «attribute-name». Si cette entrée représente un groupement d informations, il est possible de donner pour chacune des informations 118

133 OMEGA/LDM : Le Langage de Définition du Monitoring contenues dans le groupement le nom de l attribut correspondant. Ceci se fait en utilisant une liste contenant des paires (nom-information, nom-attribut). L absence de valeur pour ce champ a la même signification que dans le cas de transformations de capteurs. Il s agit d utiliser le même nom pour l attribut que celui que l information correspondante possède dans le modèle d analyse. Le champ «attribute-type» est interprété de la même manière. Il est ainsi possible d indiquer le type des attributs en utilisant une liste (nom-information, typeattribut). De plus, comme le type de l attribut peut être le même pour un groupement d informations, il est possible de spécifier le type en utilisant des paires (pattern-information, type-attribut). L absence de ce champ indique le fait que l information est publiée avec le type qu elle possède dans le modèle d analyse. Les groupements d informations sont généralement utilisés pour des informations qui représentent des attributs de la même entité. Ainsi, une seule transformation peut spécifier les valeurs des champs du type d événement utilisé, car toutes ces valeurs sont identiques, sauf le nom qu il est possible d indiquer (comme nous venons de le voir). Mis à part les champs qui concernent la construction du type d événement, nous retrouvons deux champs qui sont optionnels et qui sont utilisés afin de spécifier des conditions concernant la publication des événements. Les valeurs de ces champs ne seront pas utilisées par le mécanisme d exécution dans la définition du type d événement, mais dans la gestion de la publication des événements. A l aide du champ condition il est possible de spécifier des conditions qui doivent être vérifiées afin que l événement soit publié. Ces conditions peuvent porter sur la valeur de l information qui doit être publiée ou sur des valeurs d informations. S il s agit des valeurs d autres informations, celles-ci doivent figurer dans les entrées de la transformation. Exemple. Considérons une transformation qui est utilisée dans le modèle de traçage pour spécifier comme sortie la valeur du progrès observé. Par défaut, un événement est levé à chaque changement de valeur. Une condition pourrait être ajoutée dans cette transformation afin d indiquer le fait que le traçage du progrès doit se faire seulement si la valeur de la concordance est plus petite qu une certaine valeur. Ainsi un changement de valeur pour le progrès ne sera tracé que si la valeur de concordance est plus petite que celle indiquée dans la condition. A l aide du champ periodicity, la périodicité de publication de l information par défaut («au changement de valeur») peut être changée en indiquant le nombres d heures, de jours, de semaines ou de mois. Ainsi, il est possible d indiquer par exemple le fait que la diffusion de l information doit se faire tout les deux jours («periodicity = every 2 days»). La périodicité ainsi que les conditions sont surtout utilisées dans les transformations du modèle de traçage. Elles permettent de réduire la quantité d informations à stocker et de rendre ainsi les traces plus lisibles. Les informations utilisées Nous distinguons deux types d entrées : La première entrée de la transformation, qui est donnée sous la forme d un patron. Elle est obligatoire. Les informations indiquées sont celles qui vont être publiées. Les entrées optionnelles qui suivent la première entrée, qui sont données sous la forme d informations. Celles-ci sont des informations utilisées dans les conditions des transformations (si ces conditions existent). A l aide des patrons d informations, il est possible de faire référence à un groupe d informations. Ces patrons sont définis de la manière suivante : 119

134 Chapitre IV information-pattern = (information-name tolerance conformance threshold alarm all ) [,,, information-pattern]; Un patron peut être une information. Nous retrouvons dans ce cas les entrées des transformations telles que celles utilisées dans les transformations de calcul. La transformation fait dans ce cas référence à une seule information. Les patrons peuvent aussi contenir des mots clés. Le mot clé tolerance indique que la transformation s applique à toutes les informations qui ont été définies en tant qu ensembles de valeurs tolérées (en utilisant le spécificateur tolerance). Les mots clés conformance, threshold et alarm sont utilisés d une manière similaire, et font référence respectivement à des informations définies comme des valeurs de concordance, des seuils ou des alarmes. L utilisation des patrons donne la possibilité de grouper les informations qui doivent être publiées. Ceci réduit la taille des modèles, ce qui est convenable pour des modèles d analyse qui contiennent beaucoup d informations. Exemple. Prenons le cas du progrès. L exemple suivant est celui d une transformation qui indique dans le modèle de traçage que les valeurs de concordance et les alarmes doivent être tracées à chaque changement de valeur, sous le nom qu elles trouvent dans le modèle d analyse : instantiation information destinationx : String; instantiation information entitytypex : String; instantiation information entitynamex : String; instantiation information processnamex : String; instantiation information destinationnamex : String ; trace transformation traceconcordancealarmes { input alarm, conformance ; statement attribute-type : (alarm, String ),(conformance, Real ) ; entity-type : entitytypex; entity-name : entitynamex; process-name : processnamex; destination : destinationnamex ; } Les alarmes et les valeurs de concordance font dans ce cas référence à la même entité, du même processus, indiqués dans la partie de déclaration d informations, avec une destination sous la forme d informations d instanciation. Au moment de l instanciation du modèle, ces informations prennent certaines valeurs. Comme dans le cas des transformations utilisées dans la gestion des entrées, ces informations jouent le rôle d informations d instanciation. Ainsi, par exemple, les informations d instanciation peuvent prendre les valeurs suivantes : «Activity» pour entitytypex ; «Coding» pour entitynamex ; «ProcessOne» pour processnamex ; «TraceSystem» pour destinationnamex. 120

135 OMEGA/LDM : Le Langage de Définition du Monitoring IV.3 Conclusion Nous avons présenté dans ce chapitre notre proposition de système de mesure et d analyse, l environnement de monitoring OMEGA. Nous avons montré la manière dont OMEGA s intègre dans un EGLCP permettant à ce dernier de fournir un support pour le contrôle quantitatif. Afin d avoir un contrôle quantitatif complet, le monitoring doit être secondé par un composant pour l aide à la décision et un autre composant pour l implémentation des changements dans le processus sujet. OMEGA est un outil pour le monitoring des processus logiciels, et a pour but d observer et d analyser ces processus. Il n intervient pas directement dans le processus sujet. L utilisation de la logique floue dans la représentation et l acquisition de l information permet de gérer les informations imprécises et/ou incertaines. La décomposition d un modèle de monitoring en modèles spécifiques permet une réutilisation plus facile de ceux-ci et leur adaptation à de nouveaux contextes d utilisation. Les modèles d analyse fournissent les attributs du processus qui doivent être monitorés de même que les traitements appliqués aux valeurs de ces attributs. L intégration du monitoring dans un environnement d utilisation est donnée à travers les modèles de communication. Dans le chapitre suivant nous allons présenter la validation de notre proposition. 121

136 Chapitre IV 122

137 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Chapitre V VALIDATION D OMEGA/LDM : ETUDES DE CAS DE MONITORING ET META-MONITORING CHAPITRE V... VALIDATION D OMEGA/LDM : ETUDES DE CAS DE MONITORING ET META- MONITORING V.1 L EXECUTION AVEC OMEGA/ME V.2 ETUDES DE CAS : MODELES DE MONITORING V.2.1 Le modèle du progrès V.2.2 Le modèle de la confiance de finir dans le délai V Présentation V Modélisation et exécution V.2.3 Le modèle de concordance structurelle V Présentation V Modélisation et exécution V.2.4 Le modèle de la chance de succès V Présentation V Modélisation et exécution V.3 DOMAINE D APPLICATION ET SCENARIO D UTILISATION V.3.1 Du processus logiciel au processus a fort composant logiciel V.3.2 Un processus dans l industrie automobile V.4 LE META-MONITORING V.4.1 Le contexte du système de contrôle : le méta-contrôle V.4.2 Le méta-monitoring : monitoring du monitoring V.4.3 La fréquence des alarmes : un modèle de méta-monitoring V Présentation V Modélisation V.5 CONCLUSION

138 Chapitre V 124

139 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring VALIDATION D OMEGA/LDM : ETUDES DE CAS DE MONITORING ET META-MONITORING Ce chapitre est dédié à la validation de notre proposition. Cette validation est réalisée en utilisant des études de cas. Nous présenterons des modèles de monitoring ainsi qu un scénario d utilisation de ces modèles. Nous allons valider notre proposition en présentant une utilisation réflexive de notre système. Nous verrons comment, en utilisant le même langage Omega/LDM et les mêmes mécanismes d exécution Omega/ME, nous pouvons faire du métamonitoring, le monitoring du monitoring. La présentation de ce chapitre est organisée de la manière suivante : nous commençons avec une présentation de la manière dont l exécution a lieu en utilisant OMEGA/ME, puis nous continuons avec la présentation des modèles de monitoring, nous présentons ensuite le domaine d application ainsi qu un scénario d utilisation de modèles de monitoring, et nous concluons ce chapitre avec la présentation du méta-monitoring, où un modèle de méta-monitoring sera fourni. V.1 L exécution avec OMEGA/ME Une analogie peut être faite entre l exécution avec OMEGA/ME et l exécution dans un système expert à base de règles de production. Les informations avec leurs valeurs peuvent être associées à la base des faits. Les transformations peuvent être associées aux règles. Les transformations de calcul sont appliquées en réaction à des changements des valeurs des informations. Elles provoquent à leur tour des changements sur les valeurs des informations, ce qui peut engendrer le déclenchement d autres transformations, et ainsi de suite. Les transformations de type capteur provoquent des changements dans les valeurs des informations en réaction à des événements générés dans le processus en cours de monitoring. Les transformations utilisées dans les modèles de dissémination réagissent à des changements dans les valeurs de certaines informations, et publient ces nouvelles valeurs pour le reste de l environnement. L algorithme utilisé dans le choix des transformations de calcul est similaire à celui d un système expert de type en largeur d abord. Etant donné le changement dans l ensemble des informations, un ensemble de transformations applicables est obtenu. Cet ensemble contient toutes les transformations qui possèdent en entrée la ou les informations qui viennent de changer de valeur. Ces transformations sont appliquées et les changements qu'elles engendrent sur les valeurs des informations sont 125

140 Chapitre V implantés. Une fois toutes les informations de cet ensemble appliquées, et les informations changées, l ensemble des transformations applicables est à nouveau calculé, jusqu à ce que l ensemble des transformations applicables généré soit vide. Les transformations de capteurs sont utilisées afin de spécifier les événements auxquels le système doit souscrire. A l arrivée d un événement contenant une nouvelle valeur pour un attribut du processus, la valeur de l information qui représente cet attribut est mise à jour. En réaction, un ensemble des transformations de calcul est généré et le processus d analyse précédemment décrit est appliqué. A partir des transformations indiquées dans les modèles de dissémination (le modèle d affichage, de traçage et de diffusion), le système identifie les informations qui doivent être publiées. A chaque changement de valeur dans l ensemble des informations si les informations sont spécifiées en tant que sortie du système, les événements correspondants sont générés et publiés selon les indications des modèles de dissémination. V.2 Etudes de cas : modèles de monitoring Cette section est dédiée à la présentation des trois modèles de monitoring. A l aide de ces trois modèles nous illustrerons des utilisations différentes du système de monitoring. La première utilisation consiste à surveiller la concordance entre le processus en exécution et le plan de ressources. L exemple que nous avons choisi afin d'illustrer cette utilisation est le modèle de concordance pour le progrès. A travers ce modèle nous regardons la concordance entre le processus en exécution et son plan de ressource pour le temps (vu comme ressource). Ce modèle est utilisé afin de détecter des situations qui pourrait engendrer des retards du processus en exécution par rapport aux délais. Le modèle de confiance de finir dans les délais est une variante plus complexe du modèle de progrès. La deuxième utilisation consiste à mesurer la concordance entre le processus en exécution et son modèle. Nous illustrons cette utilisation avec un modèle de monitoring qui mesure la concordance structurelle du processus en exécution par rapport à son modèle. L utilisation de ce modèle permet la quantification des déviations qui peuvent apparaître entre le processus en exécution et son modèle. La troisième utilisation consiste à décentraliser des informations sur différents processus. Nous regardons comment le monitoring de chacun des processus considérés est fait, ainsi que la décentralisation des informations. L étude de cas est lié à un processus de sous-traitance. Nous regardons les offres de chacun des fournisseurs ainsi que la manière dont ces offres sont étudiées au site du demandeur. Il s agit du modèle de chance de succès. Par la suite nous présenterons les trois modèles. Nous allons insister sur les modèles d analyse, car c est à travers ces modèles spécifiques que les utilisations potentielles du modèle s expriment. V.2.1 Le modèle du progrès Le modèle du progrès a été déjà partiellement présenté dans le chapitre précédent afin d illustrer les différents éléments du langage OMEGA/LDM. Le modèle du progrès est utilisé afin de mesurer la concordance entre le processus en exécution et le plan de ressources en ce qui concerne les aspects liés au temps, qui est vu comme une ressource du processus en exécution. 126

141 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Ce modèle est attaché à une activité pour laquelle le progrès est monitoré. Le modèle d analyse du progrès est un modèle complet. Nous retrouvons des ensembles des valeurs tolérées, des valeurs de concordance ainsi que des seuils et des alarmes. Les attributs qui sont collectés sont les suivants : la date prévue pour le début d activité ; la date prévue pour la fin d activité ; la complétude de l activité. Les dates prévues pour la fin et le début d activités proviennent du plan de ressources. La complétude d une activité provient du processus en exécution et indique le taux d avancement de l activité. Elle peut être vue comme un pourcentage acquis. La date au moment de la prise de mesure est prise en compte dans le calcul du progrès. Lorsque activités sont vues comme des activités atomiques, nous considérons une date prévue du début, une date prévue de la fin et une valeur de complétude. Deux options sont possibles pour les activités composites : elles sont prises en compte comme des activités atomiques ; le progrès de chacune des activités composantes est monitoré et un modèle qui centralise ces données est proposé. La valeur observée du progrès est exprimée dans l univers linguistique qui contient les termes { manque, presque manque, extremement en retard, tres en retard, en retard, legerement en retard», a temps, legerement en avance, en avance, tres en avance, extremement en avance } sous la forme d un sous-ensemble flou. Cette valeur est obtenue par l agrégation du moment et de la complétude, ces informations étant également des sousensembles flous linguistiques. Le Tableau IV.I (chapitre IV) présente les règles utilisées dans cette agrégation. Le modèle d analyse du progrès inclus également un but fixé par l utilisateur. La concordance est calculée par rapport à ce but. Le but contient généralement les valeurs correspondantes au plan des ressources qui est associé au processus en exécution. Le fait de considérer un but plutôt que de considérer directement la valeur associée au plan de ressources ( a temps ) permet d adapter son approche aux conditions particulières liées à la mise en œuvre du processus. Par exemple si les délais ne sont pas la priorité, il peut être envisagé de calculer la concordance par rapport à une tolérance qui inclut aussi des valeurs telles que legerement en retard, legerement en avance ou d autres valeurs. La valeur calculée pour la concordance est un nombre réel dans l intervalle [0,1]. Le seuil est défini aussi dans le même univers. Une alarme à deux valeurs est considérée, l alarme est activée dès que la valeur du seuil est dépassée. La modélisation du modèle d analyse du progrès peut être trouvée dans l Annexe B, ensemble avec des modèles de capteurs, d affichage et de traçage associés. V.2.2 Le modèle de la confiance de finir dans le délai V Présentation Le modèle de la confiance de finir dans les délais, que nous appelons CFD, travaille sur les même données brutes que le modèle de progrès, mais il prend une approche différente. Dans le cadre de ce modèle le rapport complétude position dans le temps est utilisé afin d établir la 127

142 Chapitre V confiance dans le fait que la complétude totale sera accomplie dans le délai prévu. Un des avantages de ce modèle réside dans le fait qu il permet de prendre en compte dans ses analyses des situations inattendues, comme par exemple un blocage. Comme dans le cas du progrès, ce modèle peut être utilisé pour le monitoring de chaque activité. La complétude est mesurée, comme dans le cas du progrès, en pourcentage acquis. Le temps est vu à travers trois valeurs : T N : représente le temps alloué à l activité. Il correspond au temps estimés pour réaliser le travail à ce qu on appelle un rythme normal de travail. Ce rythme correspond à un travail qui n implique pas des risques, car il donne un certain temps pour réagir aux situations inattendues ; T M : représente le temps minimal dans lequel l activité pourrait être réalisée. Ceci correspond à un rythme de travail maximal et engendre des risques élevés, car il ne laisse aucun temps de réaction face aux situations inattendues. Il est appelle aussi temps d alarme ; T A : correspond à un temps d alerte ; il correspond à une valeur de temps intermédiaire entre le T N et le T M. Les risques se situent aussi entre ceux correspondants aux situations précédentes. A partir de ces valeurs, des seuils d alerte et des seuils d alarme sont générés par le système de monitoring pour chaque valeur de complétude considérée. Les valeurs de temps (T N -T M ) et (T N -T A ) correspondent au seuil d alarme et au seuil d alerte pour une valeur de complétude égale à zéro. Pour une valeur de complétude donnée, le seuil d alerte et le seuil d alarme pour le temps sont générés en utilisant les valeurs T N, T M, et T A. Si C est la complétude mesurée pour l activité considérée au moment T, la confiance de finir dans les délais est calculée en fonction de la distance entre T et les seuils d alerte et respectivement d alarme correspondant à la valeur C. La valeur de confiance est représentée sous la forme d une information linguistique floue dans l univers {très haute, haute, normale, basse, très basse}. Le degré d appartenance à chacun des ces termes est calculé pour une paire (C,T) donnée. La confiance basse correspond à une situation où T est proche de la valeur du seuil d alerte attaché au C. La confiance très basse correspond à une situation où T est proche de la valeur du seuil d alarme attaché au C. Pour un degré d appartenance égal à 1 au terme très basse, le système juge impérative une prise de décision et des actions correctives afin de pouvoir tenir le délai. Une alarme est levée par le système. Dans la Figure V.1 il est considéré un espace bidimensionnel où un axe correspond à la valeur de complétude, et l autre à la position dans le temps. Les trois valeurs du temps sont représentées, ainsi que les zones d alerte et d alarme associées. Une évolution de la complétude à l intérieur de la bande blanche (la «bande de normalité») correspond à une exécution de l activité normale et sans risques. Les zones grises du coté droit de la bande blanche représentent des zones avec des risques. Soit le plan n a pas été bien conçu (sousestimation du temps de travail), soit des situations inattendues sont apparues. La ligne qui sépare la zone blanche de la zone gris clair à droite, est la fonction qui donne le lien entre le seuil d alerte et la valeur de la complétude. La ligne qui sépare les deux zones grises du coté droit représente la fonction qui fait le lien entre le seuil d alarme et la complétude. 128

143 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Zone qui indique un plan extrêmement mauvais ; pas de risques associés Complétude Zone qui indique que les estimations de temps sont un peu erronées ; pas de risques associés Zone d alerte ; il y a des risques pour que les délais ne soient pas respectés T N - T A T M T N - T M T A T N Temps exécution qui finit plus vite que prévue par le plan exécution impossible, car elle contient un passage dans la zone d alarme exécution normale sans risques Zone raté. Les délais ne peuvent plus être respectés Figure V.29 L espace complétude-temps et les différentes zones de risque associées Les deux zones grises du coté gauche de la bande blanche correspondent à des situations où le plan n a pas été bien conçu, mais il n y a pas de risques de ne pas finir l activité dans les délais. La confiance a des valeurs hautes dans ces zones. Le système de monitoring considère que des valeurs (C,T) dans ces zones sont le signe des problèmes avec le plan, plus précisément d une surestimation du temps nécessaire pour exécuter l activité. Une correspondance est établie entre l univers de la valeur de CFD est définie et le temps. Les fonctions d appartenance qui sont attachées à chacun des termes linguistiques sont dépendantes de la valeur de complétude observée. A un moment d observation T le système génère les fonctions d appartenance correspondantes à la valeur de complétude C observée, et la valeur de CFD (qui est une variable linguistique floue) est donnée en utilisant ces fonctions d appartenance et la valeur T. La Figure V.2 présente un exemple de génération de fonctions pour la valeur de complétude C. En fonction de la position dans le temps, on obtient des valeurs de confiance différentes. Pour la valeur T 1 la confiance est plutôt normale (entre normale et basse), tandis que pour la valeur T 2 la confiance est entre basse et très basse, ce qui correspond à une zone d alerte. Une alarme à trois positions (inactive, alerte et alarme) est utilisée pour signaler les zones à risque. Comme nous l avons déjà mentionné, les valeurs hautes de confiance sont signes d une planification qui est devenue inadéquate (due par exemple à une surestimation de temps nécessaire pour exécuter l activité). Dans ce cas le manager pourra employer des actions portant soit sur la diminution du temps alloué, soit sur l augmentation des ambitions associées. 129

144 Chapitre V Complétude 100 C 0 T TH T H T N T 1 T B T 2 T TB T N Temps 1 CFD très haute haute normale basse très basse 0 T TH T H T N T 1 T B T 2 T TB T N Temps Figure V.30 Les fonctions d appartenance pour la confiance pour une valeur de complétude donnée Les valeurs basses de confiance sont le signe soit d une mauvaise planification (sousestimation du temps nécessaire), soit d une situation inattendue. Nous allons revenir par la suite sur le problème des situations inattendues, et comment elles sont prises en compte dans le modèle. Les actions correctives qui peuvent améliorer des valeurs basses de confiance sont similaires aux actions correctives indiquées pour des valeurs de progrès en retard. Nous retrouvons ainsi l ajout du temps, les diminutions des ambitions ainsi que l ajout de l effort supplémentaire. Nous allons regarder par la suite le problème des situations inattendues, ainsi que la manière dont le système réagit aux actions correctives. Les situations inattendues Nous considérons qu une situation inattendue peut se manifester dans une des formes suivantes. 1. Découverte d un travail supplémentaire qui doit être fait. Cette situation correspond à un changement dans la compréhension existant au moment de la planification de ce que l activité doit fournir. Ceci se traduit par un changement dans la valeur de complétude. Par exemple si avant que la situation inattendue apparaisse, la complétude de l activité était de 60% de l activité, une découverte d une charge supplémentaire de travail équivalent à un 25% de la charge initiale, fait que la valeur de complétude baisse à 48%. Avec la nouvelle valeur de complétude la valeur de CFD change aussi. Les zones d alerte changent de forme dans ce cas. 130

145 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring 2. Découverte des erreurs qui engendrent des parties du travail qui doivent être refaites. Cette situation correspond à un travail qui doit être fait. La compréhension de ce qui est à faire reste la même, et les fonctions de seuil de changent pas. Cette situation se traduit dans notre modèle par une baisse de la valeur de complétude. Bien évidemment, avec cette baisse, la valeur de la CFD change, ce qui éventuellement peut déclencher l alerte ou l alarme. 3. Blocage de l activité qui nécessite assistance. Cette situation peut être trouvée par exemple dans le cas ou l activité est dépendante du résultat d une autre activité qui ne lui parvient pas. Les motifs peuvent être multiples, et sont liés à la nature de l activité. La Figure V.3 illustre les changements induits dans le système par les deux premières situations identifiées. 100 Complétude (a) C C 0 T N - T A T M T 1 T N - T M T 2 T A T N Temps 125 Complétude 100 (b) C 0 T N - T A T N - T M T 1 T M T 2 T A T N Temps Figure V.31 Changement des fonctions utilisées par le système de monitoring avec augmentation de charge de travail sans ajustement du plan Dans le premier graphique de la Figure V.3, noté (a), la paire (C,T 1 ), (C,T 2 ) illustre deux situations possibles. La première se place dans la bande blanche, donc la confiance que la complétude va être accomplie dans le délai fixé est normale. La deuxième est dans la zone d alerte. Dans le même graphique la valeur C correspond à la valeur de complétude après avoir détecté une situation qui implique de retravailler une partie de l activité (ceci correspond à la deuxième situation identifiée). Nous observons que si nous nous situons dans le moment T 1 la confiance passe de normale à basse. Par contre si le moment où cette situation 131

146 Chapitre V inattendue apparaît est T 2, alors nous passons dans une situation ou la confiance est très basse, et les délais ne peuvent plus être respectés sans que des changements soient apportés au plan. Dans le deuxième graphique de la Figure V.3, noté (b), nous pouvons observer la manière dont les zones d'alerte et d alarme changent avec la charge de travail ajoutée (la complétude maximale passe de 100% à 125%). Pour les valeurs (C,T 1 ), la valeur de la CFD change et on rentre dans une zone d alerte, tandis que pour les valeurs (C,T 2 ) on retrouve une zone d alarme, où le plan doit impérativement être changé. Les changements dans les données utilisées par le système se font seulement après une prise de décision de la part du manager. Par exemple, soit une situation dans laquelle du travail doit être refait a été détectée, car une certaine contrainte est violée. Le manager peut décider d accepter la violation de contrainte, car le travaille à refaire est trop important. Les actions correctives Nous discutons par la suite certains actions correctives et l impact qu elles ont sur le système. Quand des actions correctives sont apportées, les données utilisées par le système changent (par exemple la forme des zones d alerte et d alarme). 1. La diminution de l ambition. Cette action a comme effet le changement de l appréciation du contenu du travail qui doit être fait. Ceci est une situation opposée à celle où du travail supplémentaire doit être fourni. L effet que cette action a sur les zones d alerte et d alarme est opposé à celui de la détection de charge supplémentaire de travail. La bande de normalité s élargit, ce qui permet de passer par exemple d une situation d alerte à une situation de normalité, ou encore d une situation d alarme à une situation d alerte ou de normalité. 2. L ajout du temps. Ceci a un effet similaire à celui de l action corrective précédente. 3. L augmentation du personnel 58. L effet de cette action corrective induit dans notre modèle un changement dans la proportion qui existe entre T N et T M, c est-à-dire entre le temps alloué et le temps minimal. En effet avec l augmentation de l effort alloué, le taux d avancement possible (donnée par la pente de la fonction de seuil d alarme) change, ce qui induit un changement des zones d alerte et d alarme. Comme ce sont les fonctions d alerte et d alarme qui tiennent compte de l effort alloué, les changements qui portent sur ce dernier ne sont pas capturés par le système d une manière automatique. C est le manager de processus qui doit fournir cette information au système, en changeant ces fonctions (à travers des nouvelles valeurs pour T A et T M ) afin qu il puisse la prendre en compte pour une évaluation plus pertinente de la CFD. V Modélisation et exécution Le modèle d analyse pour la confiance de finir dans les délais est présenté par la suite. Les univers Les univers que le modèle utilise sont les suivants : universe Confiance = fuzzy { tres basse, basse, normale, haute, très haute } ; universe Clash = { aucun, retravail, surcharge, blocage } ; universe Alarms = fuzzy { inactive, alerte, alarme }; 58 L ajout du personnel plus qualifié (une autre action corrective présente dans le modèle du progrès) peut être prise en compte de la même manière que l augmentation du personnel. 132

147 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring L univers Confiance est utilisé afin de représenter les valeurs de CFD. L univers Clash indique les différents types de situations inattendues. L univers Alarms indique l utilisation des alarmes linguistique à trois valeurs. Les alarmes définies sur cet univers ont une représentation floue. Ces alarmes peuvent ainsi indiquer un certain degré d alarme ou d alerte. Les informations Le modèle définit les informations d base suivantes : information C : Real ; // completude information T : Real ; // moment considere pour l analyse (le moment actuel) information CFD: Confiance ; // la confiance de finir dans les delais information TN : Real; // le temps alloue a l activite information TM : Real; // le temps minimal a 0 completude information TA : Real; // le temps d alerte a 0 completude Le modèle utilise les informations suivantes afin de représenter les situations inattendues ou de blocage : information clashvalue : Real ; information clashtype : Clash ; information clashcfd : confiance ; L information clashtype indique le type de situation inattendue. L information clashvalue est utilisée pour des situations qui impliquent du travail à refaire ou une surcharge. Dans ces cas elle garde la valeur de complétude représentant la quantité de travail qui doit être refait ou qui doit être ajoutée comme travail supplémentaire. L information clashcfd est la valeur de confiance que le clash induit. A travers cette information le système peut indiquer à l utilisateur qu elle sera la valeur de confiance (et ainsi le risque associé) si la situation de clash est ignorée. Une fois une décision prise, le clash est considéré comme analysé, et le système adapte ses fonctions aux nouvelles valeurs. Deux alarmes sont considérées, une pour des situations critiques observées, et une autre pour des situations critiques que l apparition d un clash peut engendrer. alarm information alarmecfd : Alarms ; alarm information alarmeclashcfd : Alarms; Les transformations La transformation suivante fait le calcul de la valeur de confiance : transformation computeconfiance{ input T; input C, TN, TM, TA; output CFD; statement CFD= membershipfunctions ( ( tres haute, [0 # 0 # (C*TM/100) # (C*TA/100)]), ( haute, [(C*TM/100) # (C*TA/100) # (C*TN/100)]), ( normale, [(C*TA/100) # (C*TN/100) # (TN-TA +C*TA/100)]), ( basse, [(C*TN/100) # (TN-TA +C*TA/100) # (TN-TM +C*TM/100)]), ( tres basse, [(TN-TA +C*TA/100) # (TN-TM +C*TM/100) # TN # TN)]) ) } La valeur de confiance, qui est une information linguistique floue, est mise en correspondance avec la valeur du temps, qui est numérique. Ainsi on utilise un ensemble de fonctions 133

148 Chapitre V d appartenance qui font le lien entre les deux univers. Ces fonctions sont dynamiquement générées en fonction de la valeur de complétude C, du T N, T M et T A. La construction de ces fonctions d appartenance est celle qui est indiquée dans la Figure VI.2. Les fonctions qui donnent les valeurs T TH, T H, T N, T B, T TB sont des fonctions linéaires (comme il est montré dans la figure). Ces fonctions pourront être changées si d autres fonctions plus pertinentes peuvent être établies. Soit T TB une des valeurs mentionnées 59. Elle est obtenue en utilisant la fonction F TB ( c ) qui indique pour toutes les valeurs de complétude c le seuil d alarme associé. Dans notre cas cette fonction est donnée par l équation de la droite qui passe par les points (T N -T M, 0) et (T N, 100), cette représentation ayant lieu dans l espace temps - complétude que nous utilisons. L équation de cette droite (considérant que x = temps, et y = complétude) est la suivante : 100*temps + T M *complétude = 100*(T N -T M ) ( V.12 ) A partir de cette équation la fonction qui pour une valeur de complétude donne la valeur du temps (qui est dans cet exemple T TB ) est la suivante : T TB = F( C ) = T N -T M - C*T M /100 ( V.13 ) Cette valeur nous la retrouvons dans la transformation précédente (computeconfiance). Plus précisément, dans la fonction d appartenance [(TN-TA -C*TA/100) # (TN-TM -C*TM/100) # TN # TN] du dernier terme linguistique (tres basse). Toutes les autres valeurs utilisées dans la construction des fonctions d appartenance sont obtenues d une manière similaire. La transformation qui fournit la valeur de clashcfd est un peu plus complexe car elle tient compte de la valeur du clash. Pour une situation de blocage la valeur de confiance induite est très basse, ce qui correspond au fait que le risque est maximal. Si une action corrective n est pas employée, les délais ne seront pas respectés. Si la valeur du clash correspond à du travail qui doit être refait, un calcul similaire à celui employé pour le calcul du CFD est utilisé, calcul qui considère une valeur de complétude égale à (C-clashValue). Si la valeur du clash correspond à une surcharge de travail, le calcul est fait par rapport à des nouvelles valeurs d alerte et d alarme, car T A et T M sont changées d une manière proportionnelle à l augmentation du travaille. Ainsi, le calcul est fait pour un T A =T A + clashvalue*t A /100, et T M =T M + clashvalue*t M /100. Les alarmes sont activées par des transformations qui utilisent des règles graduelles. Pour l alarme associée à la valeur CFD le modèle utilise la transformation suivante : transformation setalarmecfd { input CFD ; output alarmecfd ; statement alarmecfd = symbolic ruleset ( ( tres basse -> alarme ), ( basse -> alerte ), ( normale -> inactive ), ( haute -> inactive ), ( tres haute -> inactive )) ; } 59 T TB fait référence au terme très basse, il concerne la valeur du seuil d alarme correspondant à une valeur de complétude. 134

149 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring V.2.3 Le modèle de concordance structurelle V Présentation Le modèle de concordance structurelle est utilisé afin de mesurer et d analyser le processus en exécution vis-à-vis de sa concordance structurelle par rapport à son modèle. Le modèle de processus est considéré seulement à travers sa structure. Ainsi un modèle de processus est vu comme un ensemble d activités partiellement ordonnées. L ordre est donné en utilisant une relation de dépendance entre les activités. La relation de dépendance associe à chaque couple d activités (A,B) une valeur de dépendance D(A,B) qui indique la mesure dans laquelle l activité A est dépendante de l activité B. Cette dépendance est interprétée comme le degré de complétude que l activité B doit avoir au moment ou l activité A est démarrée. La complétude est vue en tant que pourcentage accompli. Plus précisément les valeurs de dépendance ont l interprétation suivante : D(A,B)=0 indique le fait que A n est pas dépendante de B. D(A,B) (0,100] indique le fait que A est dépendante de B, c est-à-dire que B devrait avoir un degré de complétude égal à D(A,B) quand A est démarrée. Par exemple si D(A,B)=60, cela signifie que dans le moment où l activité A démarre, l activité B doit avoir un degré de complétude supérieur à 60%. Par convention nous notons D(A,A)=0. Les valeurs de la relation de dépendance peuvent être données dans une matrice carrée D, où chacune des lignes et des colonnes correspond à une activité. Exemple. Considérons un processus qui a cinq activités, notées A, B, C, D, et E. La relation de dépendance pourrait être exprimée dans le Tableau V activités dépendantes A B C D E A B C D E Tableau V.9 Un exemple de relations de dépendance Dans cet exemple l activité A n est dépendante d aucune autre activité. Elle est donc la première qui peut commencer. Quand l activité A atteint une complétude de 60% l activité B peut démarrer. Au 80% de l activité A l activité C peut aussi démarrer, etc. L exemple précédent présente des valeurs nettes pour la relation de dépendance, et cela semble restrictif. Nous considérons ainsi des valeurs plus flexibles en utilisant des nombres ou des intervalles flous. Ainsi on peut par exemple avoir D(B,A)=[50 # 60 # 70], ce qui indique le fait que l activité A doit avoir accompli «environ 60%» afin que l activité B puisse commencer. La relation de dépendance définit un ensemble de contraintes sur les activités du processus. 60 La lecture de ce tableau se fait de la suivante manière : l activité sur la ligne i est dépendante de la activité sur la colonne j, la valeur de dépendance étant égale à D(i,j). 135

150 Chapitre V Une déviation structurelle est vue comme une violation des contraintes, c est-à-dire une violation de la relation de dépendance. Si on reprend l exemple précédent où D(B,A)=60, il est considéré comme déviation le fait de démarrer l activité B avant que l activité A atteint 60% de complétude. La valeur de la déviation est quantifiée comme la différence entre la valeur de dépendance (la complétude que A aurait dû avoir) et la complétude de A quant l activité B est démarrée. Si on note avec Comp(A) la complétude d une activité A et Dev(B,A) la déviation de l activité B par rapport à sa dépendance de l activité A, la relation suivante est vérifiée : Dev(B,A)=max(D(B,A)-Comp(A),0) ( V.14 ) La déviation relative de l activité B par rapport à sa dépendance de l activité A est noté DevR(B,A) la relation suivante est vérifiée : Dev( B, A) si D( B, A) 0 DevR ( B, A) = D( B, A) ( V.15 ) 0 si D( B, A) = 0 Supposons que la complétude de A au moment ou B est démarrée est C(A)=45%. La déviation de B a la valeur 15, et la déviation relative a la valeur Si l activité B avait d autres dépendances, la déviation de B serait calculée comme la somme des déviations par rapport à chacune des dépendances. Si on note Dev(B) la déviation totale de l activité B, la relation suivante est vérifiée : Dev(B) = Σ i=1,n Dev(B, A i ) = Σ i=1,n max(d(b,a i )-Comp(A i ),0) ( V.16 ) La déviation relative totale de l activité B, noté DevR(B), et la déviations relative moyenne de B, noté DevRM(B) vérifient les relations suivantes (n D représente le nombre d activités par rapport auquel B a des dépendances, c est-à-dire pour lesquelles la relation de dépendance a une valeur strictement positive) : DevR(B)= Σ i=1,n DevR(B, A i ) ( V.17 ) i = 1, n DevR( B, Ai ) DevRM ( B) = ( V.18 ) n D Dans ces relations A i, i=1,n représente l ensemble des activités du modèle. La déviation d un processus par rapport à son modèle est calculée comme la somme des déviations de toutes les activités. La déviation relative totale est la somme des déviations relatives de toutes les activités, tandis que la déviation relative moyenne est la moyenne des déviations relatives moyennes des toutes les activités. Si nous notons P le processus en exécution et son modèle M={A1,, A n } la déviation totale du processus P par rapport à son modèle M, notée Dev(P,M) vérifie la relation suivante : Dev(P,M) = Σ i=1,n Dev(A i ) ( V.19 ) Pour le même processus P, la déviation relative totale de P par rapport à son modèle M et la déviation relative moyenne de P par rapport à son modèle M vérifient les relations suivantes : DevR(P,M)= Σ i=1,n DevR(A i ) ( V.20 ) 136

151 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring = DevR( A i n i ) 1, DevRM ( P, M ) = ( V.21 ) n Quand la relation de dépendance ainsi que la complétude sont données comme des nombres ou bien des intervalles flous, cette manière de considérer les déviations permet de prendre en compte la suppression d une activité si d autres activités sont dépendantes de l activité supprimée. Si aucune activité n est dépendante de l activité supprimée, la suppression n est pas vue comme une déviation. Si on veut que toute suppression d activité soit prise en compte dans la déviation, on peut rajouter au processus une activité qui représente la fin du processus, et qui est dépendante de la complétude totale de toutes les autres activités. Ceci permet de prendre en compte non seulement la suppression des activités pour lesquelles il n y a pas de dépendances, mais aussi d assurer que l abandon (ou la non-terminaison) de certaines activités est pris en compte dans le calcul de déviation. Exemple. Nous reprenons l exemple précédemment considéré. Le Tableau V.2 présente une variante plus flexible de la relation de dépendance. Dans cette relations des valeurs imprécises de dépendance sont aussi considérées. A B C D E T A B [50 # 60 # 70] C [70 # 80 # 90] D [90 # 100 # 100] [90 # 100 # 100] E [90 # 100 # 100] [90 # 100 # 100] [90 # 100 # 100] [70 # 80 # 90] 0 0 T Tableau V.10 Relation de dépendance avec des valeurs imprécises et une activité de terminaison L activité T qui représente la terminaison du processus est aussi ajoutée dans l ensemble des activités du processus. Cette activité est totalement dépendante de toutes les autres activités. Ce modèle de monitoring peut être étendu afin de prendre aussi en compte les déviations par rapport aux instanciations du modèle de processus. La relation de dépendance donnée au niveau du modèle peut être renforcée au niveau de l instanciation, dans une relation D, de manière que pour tout couple d activités (A,B), la relation suivante soit vérifiée : D (A,B) D(A,B) ( V.22 ) Le couple d activités (A,B) pour lesquels la relation D (A,B) prend des valeurs strictement plus grandes que celles de la relation D(A,B) correspond à des activités pour lesquelles la relation a été renforcée. Ceci peut être le cas par exemple s il n y a pas de dépendances au niveau du modèle entre A et B, mais au moment de l instantion il est décidé que l activité A doit démarrer seulement après que B ait atteint un certain degré de complétude (éventuellement total). Ainsi si la relation D est vérifiée, c est à dire s il n y a pas de déviations par rapport au processus instancié, la relation D est aussi vérifiée. Il peut y avoir des cas ou il y a des déviations par rapport à D qui ne représentent pas de déviations par rapport à D. Des telles déviations peuvent être le signe de failles dans le processus d instanciation. V Modélisation et exécution La modélisation complète de ce modèle de monitoring est donnée dans l Annexe B, où le modèle d analyse ainsi que des modèles pour les capteurs et pour la publication sont fournis. Nous considérons seulement les déviations du processus en exécution par rapport à son 137

152 Chapitre V modèle, c est à dire nous considérons seulement la relation D. Nous allons par la suite présenter quelques éléments de cette modélisation, aussi bien dans le modèle d analyse, que dans le modèle de capteurs. Le modèle d analyse définit les univers suivants : Analyse Model DeviationStructurelle ; universe EventType = { start, end, abandon, changecompletude } ; universe Completude = fuzzy [0,100] imprecision 10 with unit pour-cent ; universe Deviation = fuzzy Real ; EndModel Les événements considérés, c est-à-dire en réaction auxquels des calculs sont faits sont le début («start»), la fin («end»), l abandon («abandon») d une activité ainsi que le changement dans la complétude des activités. Nous considérons un univers qui correspond à des valeurs de complétude et un univers pour des valeurs de déviation qui acceptent des valeurs imprécises. Les informations utilisées sont les suivantes : instantiation information n : Integer ; //nombre d activités instantiation Information nomsactivites : String[n] ; information etatactivites : String[n] ; information completudeactivites : Completude[n] ; instantiation information dep : Completude [n][n] ; /* la relation de dependance */ information ActTotDev : Deviation[n] ; /* contient les valeurs de deviation totale pour chacune des activites*/ information TotDev : Deviation ; /* la deviation totale du processus*/ information indact: Integer ; /* contient l indice de l activite courante*/ information event :EventType ; L entier n donne le nombre des activités dans le modèle. Les noms des différentes activités (qui agissent comme des identificateurs) sont contenues dans un vecteur. Avec la relation de dépendance ces informations sont des informations d instanciation. Le vecteur etatactivités contient les états des activités. Il prend des valeurs qui ont la signification suivante : inactive : activité non commencé ; active : activité commencée ; finie : activité finie correctement ; abandonnée : activité abandonnée (nous faisons la supposition que si une activité a été abandonnée, le taux de complétude acquis au moment de l abandon reste le même). Les valeurs de complétude pour les différentes activités sont contenues dans le vecteur completudeactivites. Les dépendances sont données dans le vecteur à deux dimensions dep. Les déviations des activités sont gardées dans un vecteur, notamment ActTotDev, tandis que la déviation du processus dans sa totalité est gardée dans TotDev. L information IndAct contient l indice de l activité considérée dans le vecteur des activités. L information event contient le dernier événement reçu. Nous rappelons que les événements sont livrés pour analyse seulement une fois que l analyse de l événement précédent est achevée. 138

153 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Le modèle d analyse contient trois transformations. La première concerne le changement d état des activités, la deuxième le calcul des déviations pour chacune des activités, et la troisième le calcul de déviation pour l ensemble du processus. La transformation statechange gère les changements d état change, elle modifie le vecteur qui contient l état des activités en fonction du type des événement reçus. Un changement du niveau complétude n est pas vu comme un changement d état, et la transformation n a pas d effet dans ce cas, c est-à-dire elle ne sera pas prise en compte par cette transformation (la transformation qui gère les changements de complétude se trouve dans la version complète du modèle, dans l Annexe B). transformation statechange { input indact ; input event ; output etatactivites ; statement etatactivites[indact]= (((etatactivites[indact]== inactive ) AND (event == start ))? active : ((etatactivites[indact]== active ) AND (event== end ))? finie : ((etatactivites[indact]== active ) AND (event== abandon ))? abandonnee : etatactivites[indact] )) } La transformation qui gère le calcul de déviation pour les activités est déclenchée aussi à chaque arrivée d événement, mais elle n aura d effet seulement s il s agit d un démarrage d activité. C est au moment du démarrage que la déviation d une activité est calculée, car c est à ce moment qu on peut vérifier si les dépendances sont vérifiées. transformation calculacttotdeviation { input completudeactivites ; input indact ; input event ; input dep ; output ActTotDev ; statement if (event == start ) iterate (j=1 ; j <= n ; ActTotDev[indAct]= (dep[indact][j] > completudeactivites[j])? ActTotDev[indAct]+ dep[indact][j]- completudeactivites [j] : ActTotDev[indAct])) ; } Le calcul de la déviation totale du processus est déclenché seulement si un changement est apparu dans le vecteur qui contient les déviations pour chacune des activités. Il est calculé comme la somme de toutes déviations. Le modèle d analyse complet se trouve dans l Annexe B. Le modèle de capteurs prend en charge le changement des valeurs de complétude. Le modèle de capteurs contient deux transformations pour la souscription des événements qui indiquent le fait qu il faut souscrire aux événements concernant le changement d états et les changements de valeurs de complétude. A l aide de deux transformations de calcul, la mise à jour du vecteur contenant les valeurs de complétude ainsi que de l indice dans le vecteur d activités sont réalisées. La modélisation du modèle de capteurs ainsi que du modèle de publication peuvent être trouvés dans l Annexe B. 139

154 Chapitre V V.2.4 Le modèle de la chance de succès V Présentation Le modèle de la chance de succès est utilisé dans le cadre d un processus de sous-traitance. Ce processus est un processus décentralisé, car il se passe en partie chez le donneur d ordre, et en partie chez les fournisseurs. Le donneur d ordre veut sous-traiter la construction d un produit chez un fournisseur, ce qui est représenté par un appel d offres. Les fournisseurs répondent avec des offres. L appel d offre aussi bien que les offres sont représentées par des couples (prix, délai). Nous avons ainsi deux contraintes qui doivent être respectées par une offre afin qu elle soit considérée acceptable. Le modèle proposé considère l appel d offres comme un ensemble des valeurs tolérées et calcule la concordance des offres par rapport à cette tolérance. La visibilité que le système de monitoring a sur ces processus est constituée seulement par la demande et les offres. Deux modèles d analyse sont utilisés dans ce contexte. Un premier modèle est utilisé afin d analyser la concordance de chacune des offres, et un deuxième modèle regarde la globalité des offres afin de déterminer la chance de trouver une offre convenable, c est-à-dire une offre concordant à l appel d offres. Le deuxième modèle utilise des informations issues des analyses faites à l aide du premier modèle. La Figure V.4 illustre la manière dont les modèles sont utilisés. Le premier modèle est utilisé dans le monitoring des processus fournisseurs (A et B). Le deuxième modèle est utilisé dans le monitoring du processus client. Monitoring fournisseur A Monitoring fournisseur B concordance offre A Monitoring processus du donneur d ordre concordance offre B Processus du fournisseur A chance de succès Processus du fournisseur B appel d offres offre appel d offres offre Processus du donneur d ordre LEGENDE = Interaction au même niveau (processus ou monitoring) = Interaction entre les processus sujet et leur monitoring Figure V.32 Le schéma des interactions client fournisseur 140

155 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Le prix ainsi que le délai sont des informations numériques. Par exemple on peut avoir des prix souhaités d au plus 100F, d être livré dans un délai d au plus 15 jours. La concordance d une offre est déterminée par la vérification de ces deux contraintes. Par contre, dès que le prix offert dépasse (même d un franc) le prix demandé, la concordance est nulle. En utilisant des nombres et des intervalles flous, la représentation devient plus flexible. La Figure V.5 présente une comparaison entre un appel d offres avec un délai strict, et un appel d offre avec un délai flexible. Les courbes définissent le degré de satisfaction pour les offres que l on peut avoir. Dans le premier cas (Figure V.5 (a)), toute offre qui propose un délai entre 0 et 15 jours a un degré de concordance à la demande égal à 1. Toute offre qui dépasse les 15 jours à un degré de concordance nulle. Dans le deuxième cas (Figure V.5 (b)) les offres proposant un délai entre 15 et 20 jours ont un degré de concordance qui est positif, mais plus petit que 1. Si l offre approche la valeur 15, sa concordance approche la valeur 1 (ce qui correspond à la concordance maximale). 1 Moins de 15 jours 1 Environ moins de 15 jours 15 jours jours ( a ) ( b ) Figure V.33 Demande fixe et demande flexible pour le délais Cette approche permet de considérer les offres qui sont plus proches de la demande. L ensemble des valeurs tolérées est dans le deuxième cas élargie. Des offres de délais entre 15 et 20 jours induisent des déviations par rapport à l appel d offre qui sont tolérées dans un certain degré. La Figure V.6 présente la représentation d une demande flexible aussi bien pour le prix que pour le délai. concordance offre environs moins de 100 francs 1 environs moins de 15 jours delais en jours prix en francs Figure V.34 Exemple de demande flexible et les courbes de concordance engendrées 141

156 Chapitre V Les offres sont représentées d une manière précise. La concordance d une offre O=(PO,DO) à une demande D=(PD,DD) est considérée comme le minimum entre la concordance de l offre de prix à la demande de prix et la concordance de l offre de délai à la demande de délai : concordance(o, D) = min(concordance(po,pd),concordance(do,dd)) ( V.23 ) Afin d obtenir la chance de succès pour une offre faite par un fournisseur A, un autre facteur est pris en compte. Il s agit de la confiance que le donneur d ordre a dans le fournisseur A. Cette confiance est exprimée comme un nombre réel dans l intervalle [0,1], et représente dans quelle mesure le client fait confiance au fournisseur pour honorer son offre dans les conditions spécifiées, c est-à-dire la confiance que le produit sera fournis au prix et dans le délai proposés. Si nous notons la confiance dans le fournisseur A par confiance(a) et son offre par O A =(PO A, DO A ), nous obtenons la chance de succès d un contrat de sous-traitance avec le fournisseur A sous les conditions précisées par la demande D=(PD,DD) en utilisant la suivante formule : chancesuccès(a, O A )= confiance(a)*concordance(o,d) ( V.24 ) Le modèle qui se trouve chez le processus client observe si des offres prometteuses apparaissent, c est-à-dire s il y a des offres dont la chance de succès dépasse un certain seuil fixé par l utilisateur. V Modélisation et exécution La modélisation complète de ces modèles en OMEGA/LDM est présentée dans l Annexe B. Pour le modèle pour le monitoring de la concordance de chacune des offres (le premier modèle) le modèle d analyse et le modèle de publication sont indiqués. Pour le deuxième modèle, qui traite de la chance de sous-traiter la production du produit, le modèle d analyse et les modèle de capteurs et de publication sont fournis. Le modèle de concordance d une offre faite par un fournisseur utilise : des informations concernant la demande et l offre de prix, ainsi que la demande et l offre de délai ; trois transformations : une pour calculer la concordance par rapport aux prix, une pour calculer la concordance par rapport aux délais, et une pour calculer la concordance de l offre dans sa globalité. Le modèle de diffusion attaché (voir l Annexe B) fait la publication de la concordance de l offre. Les valeurs de concordance des différentes offres publiées depuis les sites fournisseurs par le monitoring des concordance d offres sont collectées par le monitoring sur le site du donneur d ordre à travers son modèle de capteurs. Le monitoring du donneur d ordre utilise un modèle qui calcule la chance de conclure un contrat à partir des concordances d offres collectées. Dans ses calculs il prend en compte la valeur de confiance du donneur d ordre en chacun de ses fournisseurs. Cette information est fournie par le donneur d ordre, et est basée sur des contrats précédents. La chance de succès de chacune des offres est la combinaison de la valeur de concordance à l appel d offres et la valeur de confiance du fournisseur. Des alarmes sont considérées dans ce modèle. Une première alarme concerne les offres considérées viables, c est-à-dire les offres dont la chance de succès a une valeur positive. Un seuil de confiance est établi pour la valeur de chance de succès. Ce seuil correspond à une valeur de chance de succès qui est considéré suffisamment grande pour que le processus de sous-traitance aboutisse. Une offre dont la chance de succès dépasse ce seuil est considéré 142

157 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring comme convenable. Tout alternative considérée pour le processus de sous-traitance peut être abandonnée une fois que ce seuil de confiance est franchi. Une alarme est attachée à ce seuil de confiance. Quand une nouvelle offre arrive les analyses suivantes sont faites à l aide des diverses transformations : le calcul de la chance de succès de l offre ; le calcul des offres viables (activation ou désactivation de l alarme des offres viables) ; le calcul de l alarme d offres convenables à la demande. S il n y a pas d offres viables, il est possible de changer les valeurs de la demande, cas dans lequel la concordance des offres existantes change, avec possibilité des offres viables ou convenables. La modélisation en OMEGA/LDM de ces modèles se trouve dans l Annexe B. V.3 Domaine d application et scénario d utilisation Dans cette section nous allons regarder le domaine d application ainsi qu un scénario d utilisation du système OMEGA avec les modèles de monitoring présentés dans la section précédente. V.3.1 Du processus logiciel au processus a fort composant logiciel Notre étude se place dans le domaine du génie logiciel, et plus précisément dans celui du processus logiciel. Le processus logiciel permet de concevoir et développer des artefacts qui sont représentés par des logiciels ou qui sont eux même des logiciel. Comme nous l avons précisé, nos travaux de thèse ont eu lieu dans le cadre du projet ESPRIT PIE [PIE 1998]. Dans ce projet nous avons utilisé deux processus sujets : Un processus d une compagnie d assurance que nous avons appelée PEF [Robertson 1998, Amiour 1998]. Ce processus est un processus réel et concerne la manière dont une compagnie d assurance traite les requêtes pour des polices d assurance. Ce processus a été utilisé dans la première phase du projet. Un processus de l industrie automobile [PIE 1999, Cunin et al. 1999] fourni par Dassault Systèmes. Ce processus traite d une partie de la conception d un modèle sport d une voiture. Les artefacts produits dans ce processus sont des conceptions CAO 61. Par la suite nous allons utiliser le processus de conception des voitures comme étude de cas afin d illustrer les différentes utilisations du système de monitoring. V.3.2 Un processus dans l industrie automobile Le processus que nous utilisons comme étude de cas est lié à une partie du processus de conception d un modèle sport d une voiture [PIE 1999, Cunin et al. 1999]. La partie que nous utilisons dans notre étude concerne la conception du capot. Dans cette partie du processus plusieurs départements sont impliqués. Ces départements sont énumérés par la suite avec leur rôle dans le processus considéré. 61 Conception Assistée par Ordinateur, la terminologie anglophone équivalente est «CAD Computer Aided Design» 143

158 Chapitre V Le département style fournit les spécifications du capot pour le modèle sport. Le bureau d étude (BE) est en charge de la conception de la forme externe d un véhicule à partir des spécifications issues du département style. Dans notre étude il modifie la conception du capot, à partir du document initial de conception (de la voiture plate-forme) et des spécifications de capot fournies par le département style. Le département de paquetage vérifie l intégration du nouveau capot avec le reste des composants de la voiture. Le processus est présenté dans la Figure V.7, où le flot de contrôle ainsi que le flot de données sont présentés : 1. le département style envoie les spécifications (un dessin) du capot pour le modèle sport au département BE ; 2. le département BE développe la conception du nouveau capot, sous la forme d une définition CAO, qui est envoyée au département de paquetage ; 3. le département de paquetage vérifie l intégration ; si l intégration ne pose aucun problème, le département de paquetage envoie son accord au département BE ; 4. le département BE fournit la nouvelle définition approuvée du capot pour le modèle sport de la voiture considérée. Dept. Style Dept. BE Conception nouveau look pour le capot 1 Dessin nouveau capot Produit la définition CAO du nouveau capot 44 Prochaine étape LEGENDE 2 CAO nouveau capot 3 Données d inférence 1 Données Flot de contrôle Flot de données Dept. Paquetage Vérifie l intégration du nouveau capot Figure V.35 Le processus de conception de capot pour le modèle sport Ce processus est sujet au monitoring. Le système de monitoring est intégré dans un système d évolution du processus. Ce système est géré par un composant chargé de la stratégie d évolution et pour lequel nous utilisons l appellation ES 62. Dans le même système d évolution il existe un support à la décision DS 63 ainsi qu un support au changement CS 64. Nous ne présentons que les aspects liés au monitoring. Le monitoring de ce processus est fait en utilisant le modèle de chance de finir dans les délais, modèle que nous avons présenté antérieurement dans ce chapitre. Le manager du processus 62 En PIE ce composant est «Evolution Strategy Support» 63 En PIE ce composant est «Decision Support» 64 EN PIE ce composant est «Change Support» 144

159 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring lance (avec l aide de ES) le système de monitoring avec ce modèle. Le processus est vu dans la globalité, c est-à-dire le modèle de monitoring est attaché au processus. La Figure V.8 montre les interactions entre le monitoring et le processus de conception. Dans le domaine de la mise en œuvre du monitoring nous retrouvons le manager du processus. Les valeurs de temps alloué, temps minimal et temps d alerte sont fournies au système de monitoring par le département de gestion du projet. La complétude des activités qui composent le processus est fournie par les départements impliqués (département de style, bureau d étude, département de paquetage et département de gestion du projet) au support de processus, d où elles sont collectées par le système de monitoring. Le système de monitoring fournit au département de gestion du projet des informations concernant les chances que ce processus finisse dans les délais prévus. Le département de gestion du projet alloue 20 jours pour le processus de conception. Le temps minimal est de 12 jours, ce qui induit un temps d alarme de 8 jours à 0% complétude. Le temps d alerte à 0% complétude est de 5 jours. Domaine de définition Modèle de la chance de finir dans les délais Exécution du monitoring Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution de monitoring Managers des processus Domaine de mise en œuvre Modèles du processus de conception Domaine d exécution Dept. Style, BE, Paquetage, Gestion du Projet Exécution du processus de conception Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution LEGENDE = Interaction au même niveau (processus sujet ou monitoring) = Collection d informations = Interaction entre les niveaux Figure V.36 Le monitoring du processus de conception Il est considéré que les trois activités impliquées n ont pas la même grandeur en termes de complétude, et nous trouvons la répartition suivante : un quart est représenté par l activité de production du dessin (département de style) ; 145

160 Chapitre V la moitié est représentée par l activité de production de la maquette CA0 (bureau d étude) ; un quart est représentée par l activité d intégration (département de paquetage). La Figure V.9 présente le graphique de relation complétude - temps que le système de monitoring utilise pour ce processus. Complétude avant la détection du problème : zone normale après la détection du problème : zone d alarme Temps Figure V.37 Les fonctions utilisées par le système de monitoring pour le processus de conception du capot Dans la même figure l évolution de la complétude du processus est représentée. Au moment T= 14, le processus est dans l activité d intégration. La complétude rapportée par les participants au processus est de 80%. Une situation inattendue est rapportée par l activité d intégration. La conception du capot ne s intègre pas bien avec la partie arrière des phares. Ceci nécessité de retravailler la conception CAO du capot, ce qui induit une chute de la complétude à une valeur de 25% (la valeur de la complétude correspondant à la réalisation des dessins par le département de style). Les valeurs calculées par le monitoring avant le clash correspondent à une confiance qui se situe dans la bande de normalité. Le travail à refaire amène l activité dans une situation d alarme. Plus précisément, pour la valeur de complétude de 80% dans le jour 14, avant la détection du clash, la valeur de confiance était {0/très basse, 0/basse/ 0.5/normale, 0.5 /haute, 0/très haute}. La valeur induite par le clash, telle qu elle est calculée par le système de monitoring, est de {1/très basse, 0/basse/ 0/normale, 0/haute, 0/très haute}. Le chef de projet est informé de la situation détectée et du fait que la confiance de finir dans le délai est très basse, en utilisant les alarmes (définies dans le modèle que le système de monitoring utilise). Une réunion d urgence est convoquée et une décision est prise : sur le processus de conception un processus alternatif est greffé et va se dérouler en parallèle avec la conception du capot. Dans cette réunion le support à la décision est utilisé pour faire des analyses de risque, et le support au changement est utilisé afin d implanter le changement dans le processus. Le processus greffé a pour but d obtenir des phares qui correspondent au capot sportif fourni. La conception de ces phares est sous-traitée. Le département de conception est fortement 146

161 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring impliqué dans le processus de conception du capot. Avec cette nouvelle allocation du personnel, le processus de conception du capot passe de la zone d alarme dans une zone d alerte, dû au fait que la forme des fonctions d alerte et d alarme changent. Le processus dévié implique encore un département, celui des fournisseurs, s occupant des contacts avec les fournisseurs, et de l approvisionnement de différents composants. Ce processus est présenté dans la Figure V.10. Dessins capot 1 Dept. Style Dept. BE Produit la définition CAO d un nouveau capot 2 CAO nouveau capot Données d interférence CAO nouveau capot 3 Dept. Paquetage Vérifie l intégration du capot Fournit des dessins 4 Dept. Gestion Evalue continuellement les alternatives CAO du nouveau capot 1 4 CAO nouveaux phares CAO nouveaux phares Dessins nouveaux phares Dept. Fournisseurs Trouve et sélectionne les fournisseurs 2 appel d offres 3 Offre Fournisseur Fournisseur Fournisseur Analyse Analyse Analyse Fait des Fait offres des Fait offres des offres LEGENDE 1 Flot de contrôle Données Flot de données Figure V.38 Le processus dévié Les deux alternatives se déroulent en parallèle, mais une alternative sera écartée dès que l autre est suffisamment prometteuse. La partie du processus concernée par la conception du capot reprend dans le département BE à partir des même dessins pour le capot du modèle sport. Une autre conception CAO du capot devrait être produite de manière à ne pas avoir des interférences avec les autres éléments de la voiture. Dans la partie du processus concernée par la conception des nouveaux phares nous retrouvons le flot suivant de contrôle et de données : 1'. le département de style envoie le dessin des nouveaux phares au département des fournisseurs ; 2'. le département des fournisseur fait un appel d offres auprès de ses fournisseurs afin de sous-traiter la conception des phares ; 147

162 Chapitre V 3'. les offres arrivent ; une offre est choisie ; 4'. la conception CAO des nouveaux phares sera envoyée au département de gestion. Dans cet enchaînement nous n avons pas montré l envoi de l acceptation vers un des fournisseurs ainsi que le retour proprement dit de la conception des phares depuis le fournisseur vers le département des fournisseurs. Nous nous intéressons dans ce processus à la partie concernant l appel d offre et l établissement du contrat de sous-traitance. Au moment ou le processus de sous-traitance devient suffisamment prometteur, la conception d un nouveau capot sera arrêtée, ce qui engendrera des économies (de temps et d effort dépensé). Modèles de chance de finir dans les délais (CFD), et de chance de succès (CS) Managers des processus Domaine de définition Exécution modèle CFD Exécution modèle CS Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution de monitoring Domaine de mise en œuvre Modèles du processus de conception Domaine d exécution Exécution du processus de conception Dept. Style, BE, Paquetage, Gestion du Projet Fournisseurs Conception capot Conception phares (sous-traitance) Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution LEGENDE = Collection d informations = Interaction au même niveau (processus sujet ou monitoring) = Interaction entre les niveaux Figure V.39 Le monitoring et le processus dévié La Figure V.11 présente la manière dont le monitoring est utilisé avec ce nouveau processus. Pour la partie du nouveau processus concernée avec la conception du capot le monitoring est toujours utilisé avec le modèle de chance de finir dans les délais. La partie concerné avec la sous-traitance de la conception des phares est suivi par le système de monitoring en utilisant le modèle de chance de succès. Le manager décide ainsi de suivre à l aide du monitoring la chance de succès associée à la sous-traitance. L appel d offre concerne la sous-traitance de la conception des phares qui devrait être réalisée dans environ moins de 5 jours, et à un prix d environ moins de 5000 FF. La Figure V.12 présente la représentation de cet appel d offre. 148

163 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring concordance offre environs moins de 5000 francs 1 environs moins de 5 jours delais en jours prix en francs Figure V.40 Appel d offre pour la sous-traitance de la conception des phares dans le processus de conception du modèle sport de voiture Le seuil de confiance pour la chance de succès est fixé à La Figure V.12 montre comment la concordance d une offre à la demande peut être obtenue. La chance de succès est obtenue en pondérant la valeur de concordance avec la valeur de confiance dans le fournisseur. Considérons qu il existe 3 fournisseurs possibles, appelé A, B et C. Les confiances dans ces fournisseurs sont respectivement de 0.8 pour le fournisseur A, de 0.5 pour le fournisseur B et de 1 pour le fournisseur C. Le fournisseur C est celui le plus fiable, mais il travaille d habitude plus cher que les autres. L offre du fournisseur A arrive la première et indique un prix de 5000FF, dans un délai de 6 jours. La valeur de concordance à la demande est de 0.5. La chance de succès est de 0.5*0.8 = 0.4. L alarme d offres viables informe le chef de projet qu une offre viable est apparue. Cependant, le processus de conception du capot n est pas arrêté, car le seuil de confiance de 0.75 n est pas dépassé. L offre du fournisseur B arrive la deuxième. Il propose de fournir la conception des phares en 5 jours, et au prix demandé de 5000 FF. La valeur de concordance de l offre est totale (égale à 1). Mais la confiance dans ce fournisseur est basse, ce qui fait que la chance de succès est évaluée à 0.5. Cette offre est mieux que celle du fournisseur A, mais elle n est toujours pas suffisamment bonne pour que le processus de conception soit arrêté. L offre du fournisseur C arrive en dernier. Il propose de fournir les phares dans 5 jours, mais à un prix de 5600 FF. La valeur de concordance de cette offre est de 0.8. Comme la confiance dans ce fournisseur est totale, alors la chance de succès est aussi évaluée à 0.8. Le système de monitoring informe le chef de projet sur le fait que la chance de succès du processus de sous-traitance est plus grande que le seuil de confiance. Le partie du processus concernée par la conception du capot est arrêté. V.4 Le méta-monitoring Nous présenterons dans cette section la manière dont une utilisation réflexive d OMEGA contribue au réglage du monitoring. 149

164 Chapitre V V.4.1 Le contexte du système de contrôle : le méta-contrôle Nous rappelons qu OMEGA est normalement utilisé dans une boucle de rétroaction contrôlant un processus sujet. OMEGA observe, analyse un processus sujet et détecte des déviations par rapport à un comportement attendu. Si le processus sujet est le système de contrôle, OMEGA est utilisé dans une boucle de métarétroaction. La boucle de méta-rétroaction permet de contrôler et faire évoluer un système de contrôle. La Figure V.13 montre les rôles des deux boucles de rétroaction ainsi que les interactions existantes entre le processus sujet et la boucle de rétroaction (contrôle quantitatif), et entre la boucle de rétroaction et la boucle de méta-rétroaction (méta-contrôle quantitatif). informations META CONTROLE QUANTITATIF changements détecte un besoin de changement décide le changement implante le changement du contrôle quantitatif CONTROLE QUANTITATIF informations PROCESSUS SUJET changements détecte un besoin de changement décide le changement implante le changement du processus sujet Figure V.41 Le processus sujet, la rétroaction et la méta-rétroaction Un niveau méta-méta-contrôle pourrait aussi être considéré, et ainsi de suite. Au niveau du méta-contrôle, on retrouve les même composants qu au niveau contrôle : du monitoring, de la décision et du support au changement. Nous parlons ainsi du méta-monitoring, méta-décision et méta-changement. La Figure V.13 présente le niveau méta-contrôle ayant pour sujet le contrôle quantitatif. Nous considérons pour sujet seulement la partie monitoring du contrôle quantitatif. Nous focalisons notre présentation sur le méta-contrôle du monitoring. Comme notre intérêt porte sur le monitoring, nous allons plus précisément nous focaliser sur le méta-monitoring, vu comme monitoring portant sur le monitoring. Ceci est réalisé à travers une utilisation réflexive d OMEGA, de son langage et de ses mécanismes d exécution. Les transformations utilisent en entrée deux types d informations : correspondant à des attributs du processus, qui peuvent être des attributs directs ou indirects. ne correspondant pas à des attributs du processus. De telles informations sont, par exemple, des tolérances ou des seuils. Ainsi, une manière d ajuster le comportement du monitoring se fait à travers le changement des informations qui ne correspondent pas aux attributs du processus. 150

165 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring V.4.2 Le méta-monitoring : monitoring du monitoring La Figure V.14 présente les niveaux processus sujet, monitoring et méta-monitoring ainsi que leurs interactions à travers les trois domaines proposés par Dowson et Fernström [Dowson et Fernström 1994]. La réflexivité consiste dans le fait que le même formalisme et les mêmes mécanismes d exécution sont utilisés aussi bien au niveau du monitoring qu au niveau du métamonitoring. Le méta-monitoring observe le monitoring et fait des analyses. Il détecte s il y a un besoin de modifier le monitoring, c est-à-dire une déviation pas rapport à un comportement toléré. Un tel besoin de changement résulte d une mauvaise adaptation du monitoring au contexte d utilisation. Par exemple le monitoring est trop sensible aux changements dans le processus sujet et ses alarmes sont trop fréquentes. D autres exemples sont liés aux différentes formes de connaissances qu on retrouve dans les transformations, comme des ensembles de règles ou encore des fonctions d appartenance qui font le lien entre un univers linguistique et un univers numérique. Ces formes de connaissances peuvent perdre dans le temps une partie de leur pertinence, à cause de changements dans le contexte d utilisation. Le méta-monitoring permet cette adaptation continue au contexte d utilisation. Ceci est très important, car la pertinence du support offert par le monitoring est conditionnée par son adaptation au contexte d utilisation. Ses analyses doivent être adaptées et fournir des résultats pertinents. Nous retrouvons les trois domaines, de définition, de mise en œuvre et d exécution dans les trois niveaux. Dans le domaine de l exécution du monitoring nous retrouvons le manager de processus, et dans celui de la définition le concepteur du monitoring. Le méta-monitoring implique les mêmes acteurs, qui à l aide du méta-contrôle du monitoring font le réglage du monitoring Nous allons par la suite présenter un exemple de modèle de méta-monitoring. 151

166 Chapitre V Modèles du méta monitoring Mise en œuvre du méta monitoring Domaine de définition Exécution du méta monitoring Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution Domaine de mise en œuvre Modèles du monitoring Domaine d exécution Mise en œuvre du monitoring Domaine de définition Exécution du monitoring Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution Domaine de mise en œuvre Modèles du processus Domaine d exécution Mise en œuvre du processus Exécution du processus sujet Mécanisme d exécution Mécanisme d exécution Mécanisme d exécution LEGENDE = Collection d informations = Interaction au même niveau (processus sujet ou monitoring) = Interaction entre les niveaux Figure V.42 Les domaines sur les trois niveaux : processus sujet, monitoring et méta-monitoring V.4.3 La fréquence des alarmes : un modèle de méta-monitoring V Présentation Le modèle de méta-monitoring que nous allons présenter est lié aux alarmes émises par un système de monitoring. Il est basé sur le fait que la fréquence des alarmes de doit pas dépasser un certain seuil considéré et fourni par les utilisateurs. Le méta-modèle est attaché à une exécution de monitoring. Le méta-monitoring capture les alarmes émises par l exécution du monitoring et compte le nombre d alarmes émises depuis le 152

167 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring début d exécution du monitoring. La fréquence des alarmes est calculée. Un seuil est attaché à la valeur de la fréquence. Une alarme (au niveau méta-monitoring) est positionnée quand la valeur du seuil est dépassée. Une fréquence trop élevée des alarmes peut avoir des causes multiples. Ces causes peuvent être liées au processus sujet au monitoring, mais aussi au monitoring lui même. La valeur d une alarme résulte de la comparaison d une information à un seuil qui lui est associé. La fréquence d alarmes trop élevée est dû aux valeurs qu une des ces deux informations prend. Ainsi, une cause possible est que la valeur du seuil est trop élevée. Le réglage dans ce cas implique seulement un changement de la valeur du seuil. Une autre cause possible est la valeur de l information à laquelle le seuil est attaché. Dans le cas où l attribut correspondant à cette information est direct, alors la fréquence est dû au processus sujet. Par exemple si l attribut en cause est le coût, il se peut que les seuils attachés soient souvent dépassés à cause des délais très stricts, auquel cas les coûts ne constituent pas une priorité. Si l attribut est indirect, c est-à-dire sa valeur est issue d une analyse faite par le monitoring, alors cette analyse peut être à l origine de la fréquence élevée. Plus précisément, la pertinence des connaissances contenues dans les transformations impliquées peut être remise en cause. Le réglage dans ce cas est plus complexe, car il implique une remise en cause de la pertinence du modèle de monitoring et non pas de l instantiaton de celui-ci, comme c est le cas dans le changement du seuil. V Modélisation Ce modèle illustre l utilisation du méta-monitoring. Analyse Model FrequanceAlarmes ; universe Alarm = { activee, desactivee }; information startdate : Integer ; information nombrealarmes :Integer ; information frequancealarmes :Real ; threshold information seuilfrequence :Real ; alarm information alarmefrequnce : Alarm ; transformation calculefrequance { input momentactuel, startdate, nombrealarmes ; output frequencealarmes ; statement frequencealarmes = (today() startdate+1)/ nombrealarmes ; } transformation calculealarmefrequance { input frequencealarmes, seuilfrequence ; output alarmefrequnce ; statement alarmefrequnce = ( frequencealarmes >= seuilfrequence? activee : desactivee ); } EndModel Ces informations font référence à la date du début du monitoring, au nombre d alarmes reçues, à leur fréquence. Un seuil est défini pour la fréquence, et une alarme est attachée au seuil. 153

168 Chapitre V Deux transformations sont utilisées dans le modèle d analyse, une pour calculer la fréquence et une pour positionner l alarme. Le modèle de capteurs doit détecter la date du début du monitoring, ainsi que les alarmes qui sont émises par ce dernier. Des informations locales au modèle de capteurs sont définies : instantiation information source : String ; information nomalarme: String ; information alarme : String ; information activevalue : String; information eventvalue : String ; information starteventname : String ; information stateinformation : String ; La source contiendra l identificateur de l exécution du monitoring. Le modèle de la fréquence d alarmes est attaché à une alarme particulière. Le nom de cette alarme est donné dans l information nomalarme. Ce modèle est adapté pour les alarmes à deux valeurs. La valeur correspondante à l activation de l alarme est donnée par l information activevalue. L information stateinformation fourni le nom de l attribut renseignant l état du monitoring. Le changement de valeur de cet attribut correspondra au démarrage du monitoring. Il prendra alors la valeur donnée par starteventname. L information eventvalue contient l état du monitoring. Le modèle possède quatre transformations. Deux sont des transformations de capteurs, et sont utilisées afin de collecter l état du monitoring et l apparition d une alarme. Les deux autres transformations sont utilisées pour positionner la date de début de monitoring et pour mettre à jour le nombre d alarmes collectées. Ces transformations sont les suivantes : sensor transformation collectedatedebut { output eventvalue ; statement automatic-sensor ; attribute-name = stateinformation ; } transformation changestartdate { input eventvalue, starteventname ; output startdate ; statement if (eventvalue == starteventname ) startdate = today(); } sensor transformation collectealarmes { output Alarm ; statement automatic-sensor ; attribute-name = nomalarme ; } transformation changenombrealarmes { input alarm ; output nombrealarmes ; statement if (alarm==activevalue) nombrealarmes = nombrealarmes+1 ; } EndModel 154

169 Validation d Omega/LDM : études de cas de monitoring et méta-monitoring Un modèle de publication est utilisé afin d informer l environnement sur la fréquence des alarmes. La modélisation complète est donnée dans l Annexe B. V.5 Conclusion Nous avons présenté dans ce chapitre la validation d OMEGA, à travers des exemples de monitoring et un scénario d utilisation des modèles. La modélisation de systèmes de monitoring très différents en utilisant le même langage montre la puissance des concepts et des mécanismes d exécution associés. Nous avons ainsi vu des modèles concernant la concordance de la mise en œuvre du processus par rapport à son modèle instancié pour des aspects différents tels que le respect des délais et la structure du processus (dépendances entre les activités). La puissance d OMEGA est davantage mise en valeur par son utilisation dans le réglage du monitoring des processus logiciels dans un contexte donné. Le réglage est fait à travers un contrôle au niveau méta (méta-monitoring, méta-décision, méta-changement) où nous nous sommes intéressés au méta-monitoring. 155

170 Chapitre V 156

171 Implémentation de l environnement de monitoring OMEGA Chapitre VI IMPLEMENTATION DE L ENVIRONNEMENT DE MONITORING OMEGA CHAPITRE VI IMPLEMENTATION DE L ENVIRONNEMENT DE MONITORING OMEGA VI.1 PRESENTATION VI.2 CONSTRUCTION D UN SYSTEME DE MONITORING VI.3 ARCHITECTURE ET FONCTIONNEMENT VI.3.1 Le noyau VI.3.2 Le gestionnaire des communications VI.4 IMPLEMENTATION

172 Chapitre VI 158

173 Implémentation de l environnement de monitoring OMEGA Implémentation de l environnement de monitoring Omega Nous présenterons dans ce chapitre l architecture de l environnement OMEGA, ainsi que les implémentations réalisées dans le cadre du projet ESPRIT PIE [Verjus et Cîmpan 1998]. Nous commencerons par présenter les principes qui gouvernent nos choix architecturaux. Ensuite nous allons montrer la manière dont un système de monitoring pour une utilisation spécifique est obtenu, ainsi que l architecture de l environnement. Nous clôturons ce chapitre avec la présentation des implantations de l environnement. VI.1 Présentation Le fonctionnement d un système de monitoring contient deux aspects : un lié aux analyses fournies par le système ; un lié à la communication du système avec son environnement d utilisation. L architecture de l environnement OMEGA prévoit : des outils logiciels : un éditeur pour écrire des modèles en OMEGA/LDM, un compilateur Omega, un compilateur Java ; des modèles de monitoring : une bibliothèque des modèles écrits en OMEGA/LDM ; un exécutif. L exécutif constitue le mécanisme d exécution pour des modèles écrits en OMEGA. La section suivante présente la manière dont un système de monitoring est construit dans l environnement OMEGA. VI.2 Construction d un système de monitoring La Figure VI.1 présente la manière dont un système de monitoring est construit. Plus précisément, elle présente la manière dont on construit et on compile les modèles de monitoring. Elle présente également l exécutif du système. La construction d un système de monitoring a lieu dans le domaine de définition du monitoring. 159

174 Chapitre VI Modèles de Modèles monitoring de Modèles monitoring de monitoring en OMEGA/LDM EDITEUR COMPILATEUR OMEGA Bibliothèque des modèles de monitoring (BMM) Modèles de Modèles de Classes monitoring Java monitoring (modèle) Classes Modèles Javade Modèles de (exécutif) monitoring monitoring JAVAC JAVAC Modèles de Modèles de Byte monitoring code monitoring Java (modèle) Byte Modèles code de Modèles de Java monitoring (exécutif) monitoring EXECUTABLE MONITORING Figure VI.43 La création d un exécutable de monitoring Les modèles de monitoring sont gardés dans une Bibliothèque des Modèles de Monitoring. A l aide d un Editeur l utilisateur (le concepteur de monitoring) définit un modèle de monitoring en OMEGA/LDM. Dans cette définition l utilisateur peut utiliser des modèles déjà existants, qu il récupère dans la bibliothèque des modèles. Le modèle de monitoring est ensuite compilé par le Compilateur OMEGA qui génère une classe java correspondant au modèle d analyse, et des classes java pour les modèles de communication (des fichiers «.java»). La classe attachée au modèle d analyse fournit la représentation que le système possède pour le processus sujet. Les informations du modèle d analyse indiquent les attributs à travers lesquels le processus sujet est vu. Ces classes sont par la suite compilées et des fichiers binaires (bytecode) sont obtenus (fichiers «.class»), contenant le modèle du monitoring. L exécutif du monitoring fait référence, aussi bien aux aspects liés à l analyse qu à la communication. 160

175 VI.3 Architecture et fonctionnement Implémentation de l environnement de monitoring OMEGA La Figure VI.2 présente l architecture d OMEGA avec son intégration dans un contexte d utilisation. Le placement des composants est fait en fonction du domaine où ils agissent, notamment le domaine de définition, d exécution ou de mise en œuvre (aussi bien du processus sujet que du monitoring). CONCEPTEUR DE PROCESSUS Editeur Compilateur OMEGA Système de gestion des traces BMM API (java) Noyau (java) définition du monitoring exécution du monitoring Gestionnaire Communication (JMS) mise en œuvre du monitoring Interface Utilisateur (applets Java) MANAGER DU PROCESSUS Autres Composants du système de Contrôle MIDDLEW ARE mise en œuvre du processus Interface Utilisateur (applets Java) exécution du processus sujet Moteur EGLCP (Processus Sujet) AGENTS DE PROCESSUS LEGENDE = Appelle de méthode = événement Figure VI.44 Architecture d Omega avec intégration dans un contexte d utilisation Dans la partie définition du monitoring nous retrouvons l éditeur de modèles, le compilateur ainsi que la bibliothèque des modèles. Ces éléments ont été détaillés dans la section précédente. L agent qui agit dans ce domaine est le concepteur de monitoring. Dans le domaine d exécution du monitoring nous retrouvons le système de monitoring, qui contient l exécutif avec le modèle compilé et que nous appellerons noyau, un API et un gestionnaire de communication. Ces composants seront détaillés par la suite. 161

176 Chapitre VI Un «middleware» permet la communication entre le système de monitoring et l environnement qu il intègre et qui entre autres contient l EGLCP qui supporte le processus sujet. C est auprès du «middleware» que le monitoring souscrit pour récupérer des informations concernant le processus sujet. Les capteurs humains se trouvent dans le domaine de la mise en œuvre (du monitoring et du processus sujet). Des interfaces sont fournies dans ces domaines afin de permettre la collecte des informations. Dans la mise en œuvre du monitoring nous retrouvons le manager du processus. Dans la mise en œuvre du processus sujet nous retrouvons les agents du processus. En effet, si tous les attributs du processus dont le monitoring a besoin pour ses calculs sont représentés dans l EGLCP, alors les valeurs de ces attributs sont collectées directement depuis le moteur du support de processus. Les agents de processus doivent fournir des informations au système de monitoring seulement dans le cas où il existerait des attributs qui ne sont pas représentés dans l EGLCP. C est auprès du «middleware» que le système de monitoring publie ses résultats. Ces résultats pourront par la suite être utilisés par un système de gestion de trace, une interface ou encore un autre composant du système de contrôle, comme l aide à la décision par exemple. Nous allons par la suite voir comment le noyau ainsi que le gestionnaire de communication fonctionnent. VI.3.1 Le noyau Le noyau contient plusieurs parties : l exécution du modèle d analyse par l exécutif : gère la manière dont le déclenchement des transformations de calcul se fait ; une représentation du processus sujet sur laquelle les transformations agissent. Si nous reprenons l analogie faite entre le système de monitoring et un système expert à base de règles de production, le mécanisme d exécution correspond au moteur du système et la représentation du processus à la base des faits. Les transformations correspondent aux règles de production. L algorithme utilisé par le mécanisme d exécution est associé à un algorithme en largeur d abord. Il utilise les données suivantes : EIM - l ensemble des informations modifiées : il contient les informations qui viennent de changer de valeurs. Ce changement peut être dû soit à un calcul précédent, soit à un événement qui indique un changement dans la valeur d un attribut direct. ETA - l ensemble de transformations applicables : il contient toutes les transformations dont au moins une des entrées fait partie de l ensemble des informations modifiées. EIM - l ensemble des informations dont la valeur change avec l application des transformations. Cet ensemble est un sous-ensemble de l ensemble des sorties des transformations applicables. L algorithme utilisé consiste alors à appliquer les trois étapes suivantes, jusqu à ce que un des ensembles construits soit vide. 1. construire le EIM ; 2. construire ETA ; 3. construire EIM. 162

177 Implémentation de l environnement de monitoring OMEGA L ensemble EIM est aussi modifié par la couche de communication, en réaction à des événements qui indiquent des changements de valeur des attributs dans le processus sujet. VI.3.2 Le gestionnaire des communications Le gestionnaire de communication gère les entrées et les sorties du système de monitoring. Il est constitué par l exécution des modèles de communication par l exécutif. Il gère la publication et la souscription des événements, ainsi que la mise en correspondance entre ces événements et les attributs du processus. A chaque arrivée d événement le gestionnaire de communication change la valeur des informations correspondantes dans la représentation interne du processus sujet. Ceci produit le déclenchement de l algorithme utilisé par l exécutif qui exécute le modèle d analyse. Ceci est dû au fait que l ensemble des informations modifiées change. Le gestionnaire de la communication réagit aussi aux changements de valeurs des informations. Ainsi à chaque changement, le gestionnaire construit l ensemble des informations qui doivent être publiées, à partir des informations qui ont changé, en utilisant les différentes conditions spécifiées dans les modèles qui gèrent les sorties du système (comme la fréquence ou encore les conditions sur la publication des informations). Les événements ont une partie utilisée pour leur identification (l en-tête) et une partie qui contient généralement les informations. L en-tête contient plusieurs champs, dont une partie est prédéfinie et une partie définie par l utilisateur. Les événements reçus et envoyés par le système de monitoring concernent des entités du processus sujet. Les types d entités dépendent du méta-modèle utilisé dans la modélisation du processus sujet. Dans la plupart des cas, les entités sont : les activités (qu elles soient atomiques ou composites), les produits ou les ressources. Les événements sont porteurs des valeurs des attributs de ces entités. Les événements que le système de monitoring reçoit portent des valeurs des attributs directement mesurables du processus. Les événements que le système de monitoring publie concernent : des valeurs des attributs directs (cas dans lequel le monitoring ne fait que collecter l information et la publier) ; des résultats de ces analyses, qui peuvent être vus comme des attributs indirects du processus sujet. Dans les deux cas, les événements font référence à une entité du processus. Cette entité est indiquée dans l en-tête de l événement. Le Tableau VI.1 présente les champs de l événement. La valeur de l attribut constitue le corps de l événement. L état d une activité est aussi vu comme un attribut, ce qui permet de représenter le changement d état en utilisant les événements indiqués. Les valeurs de chacun des champs sont des chaînes de caractères. Des sélecteurs d événements peuvent être créés. Les expressions de sélection contiennent une conjonction des conditions sur la valeur des champs de l en-tête. Les conditions consistent dans des relations d égalité entre le nom d un champ et une valeur. 163

178 Chapitre VI Champ EventID Source Destination Description l identificateur de l événement la source de l événement (qui a envoyé l événement) le destinataire de l événement EntityType l entité sur laquelle l événement est porteur d information ; dépendant du méta-processus utilisé dans le processus sujet EntityName ProcessName AttributName Attribute Type AttributValue le nom de l entité (son identificateur) ; il identifie l entité d une manière unique le nom du processus auquel l entité appartient (son identificateur) le nom de l attribut pour lequel l événement contient la valeur le type de l attribut la valeur de l attribut Tableau VI.11 Le modèle d événement utilisé en OMEGA Par exemple l expression EntityType == «activity» fait référence à tous les événements qui portent sur des attributs d activités. L expression EntityType= «activity» AND EntityName == «Coding» AND ProcessName==«ProcessX» 65 indique les événements qui porte sur l activité de codage du ProcessX.. Le système de monitoring observe la mise en œuvre, à travers des données qu il collecte. Ces données proviennent du domaine d exécution du processus, du domaine de la mise en œuvre (celle du processus sujet et celle du monitoring). Etant donné la distinction entre les différents domaines, il est possible de faire une classification des événements qui sont ou pourraient être générés (voir Figure IV.3). événements concernant le processus instantié événements collectés pour la représentation du processus mis en œuvre événements nécessaires au monitoring événements concernant la mise en œuvre 164 Figure VI.45 Diagramme concernant les types d événements 65 Le nom de l activité est donnée à titre d exemple. La valeur de l indicateur peut être bien plus complexe

179 Implémentation de l environnement de monitoring OMEGA Un premier type contient les événements liés à la mise en œuvre du processus. Un deuxième type contient les événements concernant le processus instancié. Ces événements sont liés au modèle de processus, à son instanciation et aux exécutions conformes. Comme la mise en œuvre du processus peut dévier par rapport au modèle, l ensemble d événements liés au processus instatié n est pas toujours un sous-ensemble de l ensemble concernant les événements liés à la mise en œuvre. Seulement une partie des événements liés à la mise en œuvre sont collectés afin d obtenir la représentation du processus mis en œuvre (qui se trouve dans le domaine d exécution du processus). Le troisième type regroupe les événements qui contiennent les informations nécessaires au monitoring. Ces événements ne forment pas toujours un sous-ensemble des événements collectés pour la représentation du processus mis en œuvre. Le monitoring peut avoir besoin, pour ses analyses, des informations supplémentaires qui ne se trouvent pas dans la représentation du processus mis en œuvre. Une partie des informations supplémentaires nécessaires au monitoring doivent lui être fournis par les agents de processus. Ces informations ne sont pas toujours disponibles dans une forme sûre et/ou précise. Comme il a été déjà précisé dans le chapitre dédié à l état de l art, il est important de pouvoir prendre en compté des données imprécises et/ou incertaines, de les représenter et de les utiliser en tenant compte de leur nature. En partie, ces informations peuvent être subjectives, ainsi leur source (les agents qui les fournissent) joue un rôle sur leur degré de validité. VI.4 Implémentation Le contexte dans lequel l implémentation a été faite est celui du projet ESPRIT PIE. L implémentation a été faite en plusieurs étapes. La majorité des composants de l architecture présentée ont été implantés (sauf le compilateur). Les technologies utilisées sont Java et CORBA [OMG 1991]. Dans la première implémentation nous avons utilisé Java 1.1 et OrbixWeb Cette implémentation a été utilisée avec l environnement APEL comme EGLCP qui supporte le processus sujet. Le serveur de messages d APEL v.4 [Amiour et Estublier 1998, Estublier et al. 1998a, Estublier et al. 1998b] a été utilisé comme «middleware». Ainsi pour la partie mécanisme du gestionnaire de communication nous avons utilisé un client de ce «middleware». Cette première implémentation exécute le modèle du progrès. Les figures VI.4 et VI.5 présente des copies d écran des interfaces du système. Ces interfaces présentent deux visions du progrès : une au niveau des activités, et une au niveau du processus. L implémentation du noyau contient environs 20 classes Java, tandis que l implémentation de la communication contient environ 25 classes Java (dont une partie pour la communication CORBA). Environ 6500 lignes de code ont été écrites dans cette première implantation. Le processus sujet avec lequel la première implémentation a été utilisée est un processus d une compagnie d assurance. Ce processus a été utilisé dans la première phase du projet PIE comme étude de cas. 66 OrbixWeb est une technologie Iona. 165

180 Chapitre VI Figure VI.46 Le progrès au niveau des activités Figure VI.47 Le progrès au niveau du processus 166