Domaine de la modélisation des processus pour le génie logiciel. Noureddine Kerzazi noureddine.kerzazi@polymtl.ca DSL4SPM Domain-Specific-Language for Software Process Modeling Il s agit d un nouveau cadre automatisé dédié à la modélisation des processus 1 de génie logiciel et supporté par un outil nommée DSL4SPM 2. Le cadre implémente la spécification du standard Software & Systems Process Engineering Meta-model (SPEM2.0) 3 et se caractérise par : 1) une approche conceptuelle graphique opérant sur différents niveaux d abstraction, 2) une modélisation, orientée sur plusieurs vues, qui reconnait l importance d une multitude de préoccupations dans un modèle de processus (MP). Le cadre conceptuel est basé sur la syntaxe fournie par SPEM. L orientation multi-vue définit de nouvelles sémantiques en mettant l accent sur les types de relation entre les éléments SPEM qui structurent un MP. L utilité scientifique de l approche est illustrée par trois perspectives, à savoir : la modélisation des connaissances dans un MP, la simulation stochastique avec la méthode Monte-Carlo et l évaluation de la maturité des MP en les alignant avec un corpus des bonnes pratiques, tel que CMMI. I. La perspective de modélisation orientée activités Cette perspective constitue la couche de base de notre cadre de modélisation. Elle est dédiée à la modélisation des Workflows, liste d activités à réalisées pour mener un projet de développement ou de maintenance logiciel. Nous avons fait le choix à ce niveau d être conforme au standard SPEM conforté par une portée universelle des concepts et des structures qu il véhicule. Essentiellement, cette perspective se base sur le modèle Rôle-Activité-Artéfact définie par SPEM. La Figure 1 représente l interface de notre outil, nommé DSL4SPM, qui implémente le cadre de modélisation qu on propose. Elle est organisée principalement autour de six composants : (a) une boite à outil; (b) une scène de modélisation qui peut contenir des instances des éléments de la boite à outil; (c) un explorateur des éléments présents dans la scène organisés par phase; (d) la 1 Le mot processus est préféré à celui de méthodologie parce qu il reflète l aspect dynamique lié à la conduite des projets. 2 L outil peut être téléchargé librement à l adresse : http://www.dsl4spm.adilou.com 3 SPEM est le standard de l OMG pour la modélisation des processus de développement. Noureddine Kerzazi Page 1 sur 8
fenêtre de propriétés (attributs) pour chaque élément de la scène; (f) des formulaires personnalisés, qui serviront plus pour les autres perspectives (connaissance, simulation, CMMI, etc.); et finalement (e) une vue qui affiche les erreurs du modèle détectées par le système. (a) (b) (c) (f) (d) (e) Figure 1 : Interface de modélisation des processus Sur la base de cette perspective, orientée activités, nous avons érigé trois autres dédiée à la représentation des connaissances, la simulation et l intégration des bonnes pratiques. Les sections suivantes présentent un aperçu des trois perspectives. II. La perspective orientée gestion des connaissances La complexité des projets de développement logiciel peut nous amener à les appréhender comme des projets d apprentissage du début à la fin (de la compréhension des besoins des clients jusqu à la compréhension des mécanismes de validation du logiciel produit). Dans ce sens, nous avons proposé une extension du standard SPEM pour pouvoir représenter les éléments de connaissance, et éventuellement des mécanismes de raisonnement. L extension se présente sous forme d une couche qui complémente la perspective orientée activités. Une des motivations serait la consolidation d un cadre intégré à partir duquel on peut voir les vecteurs de Noureddine Kerzazi Page 2 sur 8
connaissance comme complément de la description des activités et leurs buts. La Figure 2 illustre l architecture de l approche. Linked Knowledge-Bases Visualization Display Ontologies Knowledge Reasoning Internal Knowledge Representation Accessors C C C XML Oriented-Activity Process Modeling Framework Figure 2 : Vue architecturale partiale de la perspective de gestion des connaissances dans les MPs Concrètement, nous proposons de lier le MP à une base de connaissance, en format XML libre ou avec un format plus formel (p. ex. standard ontologique RDF). Les bases encapsulent la connaissance liée à un ou plusieurs domaines en un ensemble structuré de concepts 4. Ensuite, lors de la modélisation, on identifie pour chaque élément du processus le vecteur des concepts qu il véhicule. La Figure 3 montre l extension du formulaire personnalisé des éléments SPEM pour représenter les vecteurs de concepts. Un des intérêts directs de l approche serait la mesure de l écart entre le vecteur de concepts nécessaire pour la réalisation d une activité et ceux fournis par le rôle responsable de son achèvement. Nous pouvons aussi penser à une meilleure assignation (rôle vs personnes physiques) des tâches connaissant les connaissances requises par les activités. Force est de signaler que les bases de connaissances sont externes à notre cadre pour plus de flexibilité. À titre d exemple, on peut assurer le lien vers une base de compétences ou d habiletés si elles sont représentées dans un format particulier. En fait, il s agit de définir la granularité de la représentation des connaissances. Notre système est capable d adapter de nouvelles structures à notre représentation interne 5 des connaissances. 4 Le concept serait l unité. Élémentaire de représentation d une base de connaissance comme proposé par les théories cognitives, l intelligence artificielle, approche ontologique, et bien d autres. 5 La représentation interne est basée sur un espace n-dimensionnel de concepts. Noureddine Kerzazi Page 3 sur 8
Figure 3 : Représentation des éléments de connaissance dans un Modèle de processus Ainsi, il est possible d extraire la liste des concepts en vue de les analyser, les comparer. L écart entre les concepts représente le manque (ou le surplus) de connaissance pour chaque activité du processus. L objectif étant la génération de tableaux de bord qui facilitent l analyse des MP. Ainsi, les gestionnaires de projet peuvent se baser sur les indicateurs fournis pour prendre des décisions éclairées. La Figure 4 présente deux tableaux de bord avec des finalités différentes : celui de gauche montre les indicateurs de mappage pour chaque activité du processus en précisant s il est satisfait (icône verte), partiellement satisfaite (jaune) ou pas (rouge). La notion de satisfaction consiste à comparer les exigences en termes de concepts de connaissance de pour la tâche avec ceux fournis par les éléments autour de la tâche (rôle, artefacts, guides, etc.). Quant au tableau de bord représenté à droite de la Figure 4, il met en évidence le degré (non binaire) de divergence de chaque tâche du processus par rapport à une situation définie comme idéale. Ce dernier permet d identifier clairement et rapidement les tâches problématiques dans le processus. Les gestionnaires de processus 6 pourraient se concentrer sur les tâches potentiellement problématiques et ainsi identifier des pistes de solutions efficaces. Chaque flèche représente une tâche du processus. L angle de la flèche représente le degré de satisfaction en termes de connaissance pour la réalisation de la tâche donnée. 6 Gestionnaires de processus ou de projet puisqu on souhaite être dans un niveau opérationnel. Noureddine Kerzazi Page 4 sur 8
Figure 4: Tableaux de bord du mappage des concepts tels que générés par le système Force est de signaler que la dimension de ces zones est paramétrable, le modélisateur indique le seuil d acceptation pour les déviations : non acceptable (rouge); acceptable (jaune), mais avec analyse et acceptable (vert). III. La perspective orientée simulation Monte-Carlo Il s agit en premier lieu d une vue opérationnelle d un MP. La gestion des risques pour les projets de développement logiciel est destinée à préserver le contrôle sur le temps et la qualité de tous les livrables prévus. Les principes clés de gestion des risques sont pris en charge lors de la modélisation du processus qui supporte le projet. L estimation de la durée de chaque tâche est calculée de façon déterministe en se basant sur des données empiriques. Toutefois, la spécificité du travail créatif des organisations de développement de logiciel a démontré les limites des modèles paramétriques existants pour prédire l'effort et la durée de chaque tâche du processus. De nouvelles approches probabilistes proposent des alternatives afin de surpasser ces limites. Cette recherche présente une nouvelle perspective de simulation stochastique intégrée à un environnement de modélisation des processus. Cette perspective de simulation automatisée, basée sur la méthode Monte-Carlo, cible l amélioration de la gestion du risque lié au temps de réalisation. Elle permet de rendre compte de l'incertitude dans l'estimation d'une durée en utilisant, en entrée, des distributions 7 de données variées. Les résultats préliminaires démontrent le potentiel d une telle approche probabiliste, notamment pour l analyse de la sensibilité et la criticaillé de chaque tâche du processus. 7 La spécificité des projets de développement implique souvent l absence de données empiriques, libres de contexte, pour faire une bonne estimation. D où la génération automatique de ses données selon des distributions paramétrables. Noureddine Kerzazi Page 5 sur 8
Figure 5: Aperçu sur les résultats de la simulation avec l outil DSL4SPM IV. Alignement avec CMMI La motivation derrière cette perspective est l intégration, explicite et formelle, du corpus des bonnes 8 pratiques CMMI dans la modélisation des processus. Aligner les activités du processus avec les composants CMMI (domaine de processus, objectifs génériques, pratique générique et pratiques spécifiques) permet non seulement d évaluer le niveau de maturité des modèles de processus (MP), mais aussi d expliciter l intention de chaque activité. Au meilleur de nos connaissances, il n existe pas de travaux de recherche dans le domaine de la modélisation des processus qui proposent cette intégration. Nous pensons que cette intégration est bénéfique notamment pour : (i) une meilleure évaluation des capacités du processus; (ii) un meilleur alignement des activités du processus avec les lignes directrices de CMMI, et ce, pour des initiatives d amélioration des MP; (iii) la maximisation de la synergie entre les deux cadre : SPEM et CMMI. 8 Beaucoup d études, impliquant l industrie du logiciel, ont été réalisées pour définir les bonnes pratiques de développement (ex. spécification, conception, test, etc.) qui permettent de produire un logiciel de qualité. Aussi, le ministère de la défense américaine DOD était intéressé par la classification des compagnies produisant du logiciel avant de leur attribuer des contrats. Il s agit d une échelle de mesurer de la maturité selon les pratiques utilisées. Noureddine Kerzazi Page 6 sur 8
Cette perspective est particulièrement utile pour les organisations de petite à moyenne taille qui souhaitent améliorer leurs pratiques et leur efficacité organisationnelle afin d atteindre leurs objectifs stratégiques 9. Néanmoins, elle est aussi intéressante pour prendre en considération les préoccupations liées à la capacité et à la maturité d une organisation. La Figure 6 montre l approche d intégration du corpus des bonnes pratiques CMMI, et ce, en trois niveaux. Au niveau méta modèle (M 2 ), l intégration consiste à identifier le point d ancrage dans le standard SPEM pour connecter les composants de CMMI. Au second niveau (M 1 ), il s agit de voir comment représenter les buts CMMI, les pratiques et leurs descriptions selon un format compact qui faciliterait la navigation au sein des 24 domaines de processus et 460 pratiques spécifiques (voir la Figure 7 ). En fin, au niveau de l utilisation (M 0 ), comment représenter des indicateurs pertinemment de satisfaction d un niveau de maturité ou les pratiques manquantes pour atteindre un niveau de performance (voir la Figure 8). Figure 6 L approche d intégration les bonnes pratiques CMMI Sur le plan de la modélisation des processus, et partant du principe que SPEM s intéresse avant tout à la structure des processus et non à leurs contenus, nous proposons une approche ascendante «bottom-up» de modélisation. Comment organiser des pratiques éprouvées de CMMI dans le but de bâtir un processus cohérent et efficace (au sens organisationnel). Les pratiques sont universelles, mais leur mise en œuvre ne l est pas. Sur le plan de l évaluation, nous proposons une approche de mesure de la maturité et de la capacité des MP selon l échelle CMMI. À chaque modification du MP (adaptation, correction, ou 9 Un exemple des objectifs stratégiques pourrait être l amélioration de la productivité ou de la qualité du produit final. Noureddine Kerzazi Page 7 sur 8
évolution), nous pouvons évaluer dynamiquement la maturité du processus. La Figure 8 présente la liste des pratiques CMMI incarnées par chaque tâche du processus. Figure 7 Navigation dans le contenu des bonnes pratiques CMMI Figure 8 Tableau de bord des indicateurs qui connectent une tâche à un ensemble de pratiques CMMI. Noureddine Kerzazi Page 8 sur 8