Le thème principal de cette thèse est le support au développement collaboratif à l’aide des processus logiciels. Nous nous sommes intéressés particulièrement à la collaboration ad hoc, dont l’étude de la littérature a montré la prépondérance en génie logiciel.
8.1.1 Conceptualisation du support au développement collaboratif
La réflexion a été construite autour d’une analyse préliminaire du support au développe-ment collaboratif, en dehors du cadre des processus. Nous avons étudié les systèmes de gestion de versions et ceux de gestion de défauts logiciels, deux des outils de support à la collabora-tion les plus utilisés. Cette étude a permis d’identifier des éléments structurant la concepcollabora-tion de ces systèmes, éléments que nous avons consolidés dans un modèle conceptuel du support au développement collaboratif.
Le modèle conceptuel définit un outil de support au développement collaboratif comme un produit logiciel résolvant un problème de développement collaboratif. Un tel problème met en
jeu un ensemble de préoccupations de développement collaboratif, qui sont des aspects de dé-veloppement pouvant être décrits et suivis de manière indépendante. La description et le suivi d’une préoccupation est implémentée par un gestionnaire de préoccupation. Le gestionnaire offre un langage de requêtes pour consulter les données de la préoccupation, et des éditeurs natifs pour les manipuler. De plus, le gestionnaire permet à tout outil de développement d’ob-server l’évolution de la préoccupation, en exposant les événements clés qui rendent compte de cette évolution, et en permettant aux outils d’observer ces événements et d’y réagir.
Plusieurs réalités du développement collaboratif sont mises en relief par le modèle concep-tuel. D’une part, la collaboration est un ensemble de préoccupations corrélées, qui, même si elles peuvent être traitées séparément quand il s’agit de stocker des données et de les modifier, doivent être interconnectées quand il s’agit d’être exploitées par un utilisateur final. En effet, un développeur logiciel ne passe pas d’une tâche de gestion de version à une tâche de gestion de défauts logiciels, puis à une tâche de gestion de processus logiciel. Un développeur a plu-tôt des tâches définies selon les besoins métier, dont chacune met en jeu différents aspects. La gestion séparée d’une préoccupation de développement collaboratif, qui se justifie par le principe de “séparation des préoccupations”, doit donc être complétée par des mécanismes permettant de lier les préoccupations entre elles.
Une première nécessité pour lier des préoccupations de développement entre elles est que chaque préoccupation soit structurée par des concepts pouvant être simplement rattachés aux concepts des autres préoccupations. Par exemple, des liens peuvent être établis entre l’auteur d’une modification dans un système de gestion de versions, et les intervenants sur un bug dans un système de gestion de défauts logiciels. Une préoccupation dont le vocabulaire est à peine lié à celui des autres préoccupations va se retrouver naturellement isolée, dans la mesure où un changement significatif de contexte est nécessaire pour la prendre en compte. Autrement dit, la conceptualisation d’une préoccupation doit utiliser une sémantique proche de celle des discussions entre participants au projet. En complément de cette contrainte sur le choix des concepts, nous avons identifié deux mécanismes, qui sont centraux dans les gestionnaires de préoccupation étudiés, et qui permettent de lier les préoccupations entre elles.
D’une part, un gestionnaire de préoccupation doit permettre d’associer à chaque donnée de la préoccupation, susceptible d’être utilisée par d’autres outils, une adresse qui peut être stockée et transmise en dehors de la préoccupation. Ceci permet à des systèmes externes de référencer ces données ou de les utiliser à tout moment en déréférençant l’adresse associée. Cette approche permet de remplacer des instructions sur “comment retrouver une informa-tion” à l’intérieur d’une préoccupation, par une notation, comprise par le gestionnaire de la préoccupation, et facile à transmettre, qui représente l’information. Au delà d’une économie de notation, ceci permet de faire référence à des informations externes sans changement per-turbateur de contexte, ce qui facilite la construction d’une connaissance partagée globale sur la collaboration.
D’autre part, le gestionnaire de préoccupation doit permettre de suivre l’évolution de la préoccupation “de l’extérieur”, en exposant les événements significatifs qui structurent l’évo-lution des données de la préoccupation, et en permettant de réagir à ces événements. En effet, la collaboration ad hoc faisant l’objet de perpétuels changements, le support de la collabora-tion peut être vu comme une réaccollabora-tion à ces changements. Cette approche permet d’avoir un
intérêt sélectif dans une préoccupation de collaboration, sans avoir besoin de la suivre dans sa globalité. Il est de la responsabilité du gestionnaire de préoccupation de faciliter ce suivi, en définissant un catalogue d’événements et en permettant de souscrire aux événements et d’y réagir avec des “crochets”.
8.1.2 Modélisation de processus logiciels ad hoc
Afin d’appliquer notre modèle conceptuel de support au développement collaboratif aux processus logiciels, nous avons défini le méta-modèle CMSPEM, qui étend la norme SPEM.
En effet, d’une part, nous nous sommes interrogés sur la pertinence des concepts existants de modélisation de processus pour décrire la collaboration ad hoc en génie logiciel. Nous avons noté comment la focalisation sur les problématiques de planification prive les approches exis-tantes, dont le standard SPEM en particulier, de la capacité à fournir les concepts nécessaires pour comprendre et représenter les interactions intrinsèques à la collaboration ad hoc. Afin de remédier à ce manque, nous avons proposé des extensions à la norme SPEM, avec un double but.
Nous avons introduit en premier lieu le concept de participant au projet, ainsi que les concepts liés de tâche spécifique à un acteur, et d’artéfact spécifique à un acteur. Ces concepts répondent au besoin de rapprocher le vocabulaire des processus de celui utilisé dans les pré-occupations courantes de collaboration. De plus, ces concepts sont liés par des relations qui précisent les rapports de collaboration entre participants, entre leurs tâches, ou encore entre les artéfacts qu’ils modifient dans leur travail.
D’autre part, nous avons noté que les instances des nouveaux concepts introduits dans CMSPEM et leurs relations peuvent changer fréquemment, et que ce changement rend compte des dynamiques de collaboration au sein d’un projet. Afin de suivre ces changements, nous avons proposé de représenter l’évolution de la configuration d’un projet par des événements, avec un mécanisme associé de réaction à ces événements. Nous avons équipé ce mécanisme de concepts de parenté d’élément de modèle et de remontée d’événement, afin de faciliter l’utilisation pratique des événements de processus par des outils tiers.
8.1.3 Apport des processus logiciels dans le support du développement colla-boratif
En conformité avec le modèle conceptuel de support au développement collaboratif pro-posé, nous avons développé un ensemble d’outils de manipulation de processus logiciels CM-SPEM, formant un gestionnaire de la préoccupation des processus logiciels.
En effet, d’une part, nous avons développé divers moyens de consulter les modèles de processus CMSPEM et d’en extraire de l’information. Il s’agit, premièrement, d’un éditeur graphique et d’un éditeur textuel équipé de vues graphiques dynamiques et personnalisables. Deuxièmement, un serveur de processus a été développé, dont les différentes URLs exposées (liens profonds) forment un langage de requêtes sur le modèle de processus.
D’autre part, les éditeurs graphique et textuel développés permettent de modifier globa-lement un modèle de processus CMSPEM. De plus, le serveur CMSPEM permet de faire des
mises à jour du processus, à un niveau de granularité extrêmement fin, afin de s’assurer qu’il reflète constamment la réalité du développement.
Enfin, le serveur CMSPEM implémente un mécanisme de souscription aux événements de processus, basé sur les web-hooks. Ce mécanisme permet à tout outil de support au dévelop-pement collaboratif d’écouter des événements de processus et d’y réagir. Ainsi, nous réduisons les barrières à l’intégration des processus logiciels dans les préoccupations courantes des dé-veloppeurs.