Notre vision de la collaboration peut ˆetre r´esum´ee par la notation formelle suivante. La collaboration est une fonction d´efinie ainsi :
Collaboration : (P ROCI× P ROCC, CON ) −→ RESU LT
O`u :
P ROCI repr´esente un sous ensemble de processus d’ing´enierie qui sont essentiellement inclus
dans P ROCEIA−632,
P ROCEIA−632 repr´esente les processus de la norme EIA-632,
P ROCC est un sous ensemble de processus de collaboration `a d´efinir,
CON est un ensemble de constraintes pour un processus de collaboration, RESU LT AT est un ensemble de r´esultats de la collaboration.
Cette d´efinition est la base de notre approche. En effet, nous voyons la collaboration dans le domaine de l’ing´enierie comme une fonction utilisant les processus d’ing´enierie avec des r`egles `a respecter et les processus de collaboration qui d´ecrivent les diff´erentes interactions entre les participants et le flot de donn´ees. Ici, P ROCI est un processus de l’EIA-632. Les
conditions (pr´econditions et post-conditions) permettant une collaboration efficace sont d´e- finies en utilisant des contraintes auxquelles les acteurs, les compagnies et les activit´es sont soumis. CON et P ROCC sont des inconnues de la d´efinition ci-dessus. Elles sont d´efinies
3.2.1 Constraintes de la collaboration : CON
Comme tout processus, les processus de collaboration sont soumis `a des contraintes dont nous distinguons trois types : les contraintes relatives aux acteurs, les contraintes relatives aux tˆaches et les contraintes relatives aux ressources utilis´ees. Ces contraintes sont prises en compte dans la d´efinition des r`egles de collaboration. Par exemple, les contraintes li´ees aux acteurs sont la disponibilit´e, les comp´etences, la confidentialit´e, etc. Les activit´es de collabo- ration d´ependent de la structure de contrˆole des processus d’ing´enierie. Des r`egles relatives aux ressources de collaboration sont soumises `a la disponibilit´e, le droit de propri´et´e, etc. Le nombre de contraintes peut s’accroˆıtre exponentiellement si nous ne faisons pas attention aux contraintes que nous souhaitons prendre en compte.
En r´esum´e, nous pouvons identifier les trois types de contraintes : contraintes acteurs, contraintes de tˆaches et contraintes de ressources. Une bonne d´efinition des r`egles de collabo- ration est essentielle parce qu’elle garantit une bonne d´efinition des processus de collaboration tout en n’oubliant pas la sp´ecification des hypoth`eses sur ces processus.
3.2.2 Conception de Processus de Collaboration : P ROCC
Dans notre approche, nous d´efinissons les processus de collaboration en deux parties. D’abord, nous d´efinissons les interactions dans les processus de collaboration et deuxi`eme- ment nous ´etablissons leur structure de contrˆole. Nous d´etaillons ci-apr`es ces deux points.
Interactions
A partir de la description pr´ec´edente, nous pouvons d´eduire le mod`ele suivant qui est un mod`ele pour la collaboration inspir´e de la norme EIA-632. Comme d´ecrit dans la section 1.2.1 `
a la page 7, cette norme distingue trois types d’acteurs : le d´eveloppeur, l’acqu´ereur, et les autres parties prenantes du syst`eme. Ces acteurs vont constituer ce qu’il convient d’appeler les participants aux processus de collaboration dans l’approche de l’Ing´enierie de la Collabo- ration. Ces acteurs peuvent indiquer des individus ou des ´equipes de travail. La figure III.3 pr´esente l’interaction dans notre mod`ele de collaboration. Nous pouvons remarquer que l’in- teraction se fait `a travers et autour d’une liste de tˆaches.
B
A Liste des tâches C
Contraintes de ressources Entrées
Contraintes de tâches Contraintes acteurs
Sorties
Légende
Acteur du process Entrées/Sorties Implication acteurs
Liste des tâches Contrainte ADéveloppeurBAcquereurCAutre partie prenante
Figure III.3 – Mod`ele de collaboration pour l’EIA-632
Le rectangle en pointill´es repr´esente le processus de collaboration en charge des entr´ees et des sorties ; le processus est aussi soumis aux trois types de contraintes de collaboration d´efi- nies. Nous appliquons ce mod`ele au processus d’Ing´enierie des Exigences dans la section 3.4.2. L’autre partie du processus de collaboration qui est la structure de contrˆole est d´efinie dans la section suivante.
Comportement des processus collaboratifs
Cette partie est focalis´ee sur les contraintes de tˆaches. Les interactions et les s´equences de tˆaches sont au centre du mod`ele de collaboration. Dans notre approche, la structure de contrˆole du processus de collaboration n’est pas identique `a celle des processus d’ing´enierie. Cependant, il y a une interd´ependance entre les deux. La structure de contrˆole d´efinit l’ordre d’ex´ecution des tˆaches. Le langage de thinkLet permet d’exprimer cet ordre une fois qu’il est fix´e comme montr´e sur la figure III.4. Cet exemple concerne une session d’´elicitation des exigences commen¸cant par un ensemble d’exigences initiales.
Entrée: Liste initiale des besoins FreeBrainstorm PopcornSort BucketWalk des besoins Vérifier la complétude Y a t−il d’autres besoins rajouter? oui non Légende: Nom du thinkLet Décision Direction du flux ou résultat de la décision Collabaoration Générer Évaluer Organier
Classer les besoins par catégories fonctionnelles Collecter des besoins con− tribués librement par les participants 1 2 3 N 0:10 0:20 0:10 0:00 Patron de Description de l’activité
Figure III.4 – Structure de contrˆole dans les processus de collaboration
Cette session est constitu´ee d’activit´es support´ees par les thinkLets appell´es ’FreeBrains- torm’, ’PopcornSort’ et ’BucketWalk’ [BdV03]. Ces thinkLets sont des variations particuli`eres des patrons de base ’G´en´erer ’, ’Organiser ’ et ’´evaluer ’.
Dans le but de formaliser ce qui pr´ec`ede, nous proposons un mod`ele conceptuel qui est d´ecrit dans la section 3.3.