Notion de méthode d’ingénierie de SI

Selon notre point de vue – partagé par plusieurs auteurs ([Kronlof 93], [Smolander 91], [Wynekoop 93], [Prakash 94], [Brinkkemper 90], [Harmsen 94], [Brinkkemper 96]) – une méthode comporte un ou plusieurs modèles de produit et un ou plusieurs modèles de processus.

Méthode

Modèle de produit

Modèle de processus

basé sur comprend

1 1 1 1 1..* 1..* < produit Méthode Modèle de produit Modèle de processus

basé sur comprend

1 1

1 1

1..* 1..*

< produit

Figure 7. Vue Générale d’une Méthode

La Figure 7 illustre la vue générale d’une méthode, composée de deux parties : une partie produit et une partie processus. La partie produit est représentée par un ou plusieurs modèles de produit et la

partie processus par un ou plusieurs modèles de processus. Chaque modèle de produit est couplé à un modèle de processus. Le modèle de produit représente la structure d’une classe de produits obtenus en appliquant la méthode dans différentes applications, tandis que le modèle de processus représente la démarche à suivre pour obtenir le produit cible.

2.1. Le Modèle de produit

Comme nous l’avons défini dans l’introduction, le produit est le résultat d’application d’une méthode. Le modèle de produit prescrit ce que sont les caractéristiques attendues des produits fabriqués par la méthode, il est le moule de production de ces produits.

Comme l’illustre la Figure 7, une méthode peut comporter plusieurs modèles de produit permettant de modéliser différentes facettes d’un SI (statique, dynamique, fonctionnel) [Olle 92], à différents niveaux de détail (classe, paquetage, sous-système) [Muller 00], [Fowler 97], [UML 03], [PUML] et à différents niveaux d’abstraction, (objet, classe, méta-classe) [Shlaer 92], [Graham 94], [Coad 91], [Booch 91], [MOF 02]. Des modèles pour représenter le contexte organisationnel du SI et les exigences à son égard ont introduit de nouveaux concepts tels que but, acteur, scénario, rôle [Rolland 98a], [Rolland 98c], [Lamsweerde 00], [Yu 94], [Potts 94]. Parallèlement, les modeleurs de besoins ont introduits la distinction entre les besoins fonctionnels et les besoins non-fonctionnels [Robertson 99], [Chung 00]. Ces extensions du champ de modélisation dans l’ingénierie d’un SI ont conduit à une nouvelle typologie des modèles permettant de classer les aspects du SI en fonctionnel, non fonctionnel et intentionnel [Rolland 98b].

La Figure 8 donne l’exemple du modèle de produit de la méthode d’analyse de Coad et Yourdon [Coad 91] présenté comme une liste de cinq éléments types : liste d’objets et de classes, relations

entre classes, groupes de classes, attributs et opérations. Tout produit conforme à ce modèle se

compose d’un ensemble d’éléments des cinq types identifiés par le modèle.

1. Identifier les objets

2. Identifier les structures

3. Identifier les sujets

4. Définir les attributs

5. Définir les services

Modèle de Processus

1. Liste des objets et de classes

2. Relation entre classes

3. Groupe de classe

4. Attributs

5. Opération (service)

Modèle de Produit Figure 8. Exemple des modèles de la méthode Coad et Yourdon

2.2. Le Modèle de processus

Comme nous l’avons défini dans l’introduction le processus est la route à suivre pour atteindre la cible que constitue le produit [Olle 92]. Il décrit à un niveau abstrait et idéalisé la façon d’organiser la

production du produit: les étapes, les activités qu’elles comprennent, leur ordonnancement, et parfois, les critères pour passer d’une étape à une autre. Il joue le rôle de moule des processus d’ingénierie.

La Figure 8 présente le modèle de processus de la méthode Coad et Yourdon qui est le corollaire du modèle de produit introduit dans la même figure. Il se présente sous la forme d’une séquence de cinq activités-types : Identifier les objets, Identifier les structures, Identifier les sujets, Définir les attributs

et Définir les services. Tout processus conforme à ce modèle est une séquence de cinq activités de

chacun des cinq types identifiés par le modèle.

D’une part, le modèle de processus n’a de sens que s’il est explicitement mis en relation avec le (ou les) modèle (s) de produit associé(s) mais d’autre part, la qualité du produit dépend fortement de celle du processus mis en œuvre pour l’obtenir. Les deux aspects sont donc fortement liés.

Dowson [Dowson 88] propose une classification des modèles de processus en trois types : orienté-

activité, orienté-produit et orienté-décision.

Les modèles orientés-activité se concentrent sur les activités exécutées pour produire un produit et sur leur ordonnancement. Les méta-modèles de processus comme Cascade [Royce 70], Spirale [Boehm 90], Hiérarchique en spirale [Iivari 90] ou Fontaine [Henderson-Sellers 90] et plus récemment le RUP [Jacobson 99] font partie de la catégorie. Ces méta-modèles permettent de modéliser le processus par un ensemble de phases de haut niveau organisées en un processus séquentiel. Ils s'adressent donc à des processus tactiques dont l'objectif est de planifier les étapes à suivre.

Les modèles orientés-produit couplent l’état du produit à l’activité qui génère cet état. Ils visualisent le processus comme un diagramme de transitions d‘état. Le modèle d’Humphrey [Humphrey 89], celui des ViewPoints [Finkelstein 90] et le modèle de processus proposé par le projet ESF( European Software Factory) [Franckson 91] appartiennent à cette catégorie.

Les modèles orientés-décision perçoivent les transformations successives du produit comme résultats de décisions. Ces modèles mettent l’accent sur la décision et le contexte de délibération autour de la décision à apprendre (alternatives, arguments PROs et CONs). Les activités ne sont plus au centre du modèle mais apparaissent comme les conséquences des décisions[Jarke 92], [Potts 89].

Deux nouvelles classes de modèle de processus ont été ajoutées récemment : orienté-contexte et

orienté-stratégie.

Les modèles orientés-contexte comme celui de la théorie NATURE [Rolland 95], [Plihon96], [Jarke 99], du projet F3 [Rolland 94] ou de l’environnement PRIME [Pohl 99] sont inspirés du paradigme de planification en Intelligence Artificielle utilisé dans GRAPPLE [Huff 89]. Ils définissent le processus à travers la combinaison de situations observables avec un certain nombre d’intentions (de

décision) spécifiques. Le travail à faire est décrit dans le processus comme étant dépendant à la fois de la situation et de l’intention ; en d’autres termes, il dépend du contexte dans lequel on se trouve au moment de le réaliser.

Le modèle orienté-stratégie [Rolland 99], [Benjamen 99] est une extension des modèles précédents qui vise à représenter plusieurs démarches dans le même modèle de processus. Il est donc multi- démarches et prévoie plusieurs chemins possibles pour élaborer le produit. Il est basé sur les deux notions d’intention d’ingénierie et de stratégie à suivre pour réaliser l’intention. La puissance d’expression de ce modèle et les nombreux avantages qu’il confère nous ont amené à l’utiliser comme modèle central de la définition de la méthode MIME.

2.3. Rôles des méthodes dans le développement des SI

Le rôle d’une méthode d’ingénierie des SI est essentiellement d’aider les ingénieurs d’application à comprendre le domaine du projet en cours (la structure de l’entreprise, ses métiers, ses modes de fonctionnement, ses objectives et stratégies d’évolution, etc.) et à spécifier les besoins que le nouveau SI doit satisfaire effectivement. Elle doit également aider à concevoir et à réaliser une solution informatique adéquate en proposant des modèles permettant de représenter différentes vues et perspectives du SI en construction. Une méthode d’ingénierie de SI est aussi un moyen de communication entre les différentes parties prenantes, les ingénieurs, les futurs utilisateurs et les clients du SI ainsi qu’entre les différentes équipes de développement au sein du projet (les concepteurs, les développeurs, etc.).

L’utilisation de méthodes dans les projets de développement de SI permet d’assurer la cohérence de la solution globale, d’explorer plusieurs solutions possibles, de détecter des erreurs ainsi que de discerner les situations et les facteurs à risque qui pourraient mener le projet à l’échec. Finalement, la méthode est un guide précieux qui doit être suivi tout au long du cycle de développement de SI.

Une multitude de méthodes d’ingénierie de SI, a été proposée ces dernières décennies. Chacune de ces méthodes se distingue des autres par la nature de ses modèles, ses objectifs et son domaine et contexte d’application. Nous avons tenté d’intégré dans un même méta-modèle les différentes propositions existante. La méthode MIME présentée dans ce travail repose entièrement sur ce méta- modèle.