Une Perspective Intentionnelle de l Ingénierienierie des Systèmes d Information Colette Rolland Université Paris1 Panthéon Sorbonne Université de Genève
Résumé Capturer les parties pertinentes du réel dans un modèle conceptuel Structures Intentions Vers des Systèmes Objectivés Comprendre le propos du système To-Be Journée IE et Trace 2
L Ingénierie Traditionnelle Objectif: Représenter par de l information certains aspects de la réalité d intérêt pour l organisation Monde Réel Monde de l information {Colette skie vite, Elle porte des pantalons rouges Et un pull bleu} Un objet réel Représentation de l objet réel Journée IE et Trace 3
L Ingénierie Traditionnelle Initiator ValidateUser <<uses>> Participant 7:sendSchedule() initiator :Person 6:prompt() 1:giveDetails() 8:approveSchedule() scheduler :Person ScheduleMtg Withdraw Edit C o nstraints <<extends>> Provide C o nstraints staff :Person 3:acknowledge() 5:sendDetails() 2:inform() 4:remind() 9:inform() participant :Person ScheduledMtg Meeting time place attends Person name 0..* 2..* email 0..* initiates 1 has 0..* has 0..1 1 Timetable initiator RequestedMtg 1 0..* MtgRequirement Journée IE et Trace 4
L Ingénierie Traditionnelle..Mais, est-ce que ce sont les bons modèles? Les résultats d enqête nous poussent à en douter: De nombreux systèmes échouent car ils ne répondent pas aux attentes de leurs usagers: Standish group( 95) Poor requirements are major (> 50%) source of failure 8000 projects, 350 US companies :Success: 16%; failure: 33%; so-so: 51% ESI(96) Most perceived problems are related to requirements specification ( >50%) 3800 organisations in 17 European countries MEGA report (02) Poor requirements capture, specification and management explain more than 60% of failures Journée IE et Trace 5
L Ingénierie des Exigences..Eviter le focus sur le QUOI et introduire le questionnement sur le POURQUOI POURQUOI Pourquoi le sytème doit il être développé? A quelles fins? et pour quel objectif? QOUI Qu est ce que le système doit faire? Quelle est sa fonctionnalité? Journée IE et Trace 6
L Ingénierienierie Dirigée par les Buts POURQUOI? Mission, Objectifs, Buts Le processus d ingénierie est participatif et de nature décisionnelle Operationalisation des buts (stratégiques, tactiques, opérationnels) QOUI? Specification d Exigences Journée IE et Trace 7
L Ingénierienierie Dirigée par les Buts (1993~) L ingénierie dirigée par les buts se focalise sur les early requirements, au moment où les problèmes (les besoins des parties-prenantes) sont identifiés et des solutions alternatives sont explorées et évaluées. L ingénierie dirigée par les buts débute par l identification des buts des parties-prenantes tels que Répondre à chaque demande de livre, ou Planifier une réunion et affine ces buts de manière itérative jusqu à ce qu ils se réduisent à des collections alternatives d exigences ou spécifications fonctionnelles ( late requirements ) chacune d elles permettant d atteindre les buts initiaux. Les buts initiaux ne sont pas nécessairement connus et explicités. Ils peuvent être contradictoires. Journée IE et Trace 8
L Ingénierienierie Dirigée par les Buts Les Buts ont des propriétés intéressantes et utiles Ce sont des expressions optatives (par opposition à déclaratives) (Jackson95), intentionnelles Ex : Transporter les passengers en sécurité Fidéliser les clients Evitent les détails et permettent de se concentrer sur l essentiel Exemple :projet ELEKTRA 175 processuss and 100kgs of modèles 250 buts sur une page A3 Journée IE et Trace 9
L Ingénierienierie Dirigée par les Buts (Functional/hard) Goals Les buts se réduisent grâce aux opérateurs ET/OU Par une personne Collecter emplois du temps Collecter auprès des agents La réduction des buts dirige le processus Par le système Envoyer demande Collecter auprès des utilisateurs Planifier réunion Recevoir réponse (Buts Fonctionnels/hard) Automatiquement Manuellement Générer planning Journée IE et Trace 10
L Ingénierienierie Dirigée par les Buts (Functional/hard) Goals Les feuilles impliquent des exigences (tâches) Tâches Par une personne Collecter emplois du temps Collecter auprès des agents Par le système Collecter auprès des utilisateurs Planifier réunion (Buts Fonctionnels/hard) Automatiquement Manuellement Générer planning Collecter Envoyer demande Recevoir réponse Planifier Journée IE et Trace 11
L Ingénierienierie Dirigée par les Buts Les buts non fonctionnels (soft) permettent la découverte d exigences Eviter erreurs Partager information Utilisabilité Facilité d apprentissage Adaptabilité à l utilisateur Tâches Changer de couleur Change Changer colour de couleur Permettre changements + + + Changer de support Changer Change de support state Changer de langage Changer de langage + Modularité Fléxibilité Programmabilité Journée IE et Trace 12 + + Réutiliser composants + Permettre outil spécifique
Evaluer les alternatives grâce aux buts NF(soft) Minimiser effort Effort collecte - Par la personne Effort de matching + Collecterdes Agents Collecter emplois temps + - Par le système Planning de qualité Conflits minimaux - - + Collecterdes Utilisateurs Bonne participation + + - Manuellement Planifier réunion Générer planning Automati quement Dérangementsl Minimaux - Contraintes Correctes s + Envoyer Request Recevoir Réponse Journée IE et Trace 13
Credits De nombreux chercheurs ont contribué au développement de l ingénierie dirigée par les buts dont: Martin Feather and Steve Fickas; Axel van Lamsweerde et al Colin Potts and Annie Anton; John Mylopoulos et al; Janis Bubenko; Colette Rolland & CRI; Periklis Loucopoulos and Evangelina Kavakli; Journée IE et Trace 14
Allons plus loin: Capturer la Variabilité dans les modèles de buts L ingénierie dirigée par les buts explore des voies alternatives mais fait des choix reflétés dans la spécification des exigences. Une solution intentionnelle est donc figée et le design du système To-Be est confiné aux contours dessinés par cette solution. Ceci est mal adapté à de situations dans lesquelles l environnement du SI et ses parties-prenantes changent constamment. Cette façon de faire est aussi mal adaptée au développement de systèmes qui doivent s adapter à un large panel d usagers ayant des bases culturelles, éducatives et linguistiques différentes ou des usagers ayant des besoins spéciaux. Journée IE et Trace 15
Allons plus loin: Capturer la Variabilité dans les modèles de buts Au lieu de choisir une solution satisfaisant le but de plus haut niveau, on pourrait choisir un ensemble de solutions alternatives. Ceci conduirait à de solutions applicatives qui pourraient être personnalisées de multiples façons en fonction des préférences des parties-prenantes et des paramètres environnementaux. Des logiciels génériques et paramétrables sont présents dans le paysage depuis un moment ERPs Ce qui est nouveau ici est une approche systématique, dirigée par des modèles pour les concevoir. Ces modèles sont des modèles de buts incluant le concept de variabilité pour différencier ce qui est commun de ce qui est variable et permettant d organiser le panel des solutions intentionnelles alternatives de manière compréhensible. Journée IE et Trace 16
Allons plus loin: Capturer la Variabilité dans les modèles de buts Proposition :les Graphes Intentions/Stratégies (Maps/Cartes) La variabilité introduit des buts multi-facettés Stratégie By forecast Purchase Material But By reorder point Le SI peut être considéré comme ayant un propos à multiples facettes Les Cartes permettent de modéliser le multi-facettage des SI adaptables Journée IE et Trace 17
La Modélisation intentionnelle avec MAP La carte Material Management (MM) de haut niveau Manually Start By planning Bill for expenses strategy By reorder point Purchase Material By forecast By Reminder Out-In strategy Reservation strategy Stop Inventory balance strategy Monitor Stock Financial control strategy In-In strategy Quality inspection strategy Valuation strategy Journée IE et Trace 18
Recherche sur la variabilité Les modèles de buts comme MAP permettent de définir la variabilité liée au problème. Des buts aux solutions techniques: une approche supportée par un outil logiciel pour générer les différents produits issus de la même carte; nous nous sommes intéressés au CRI à (a) la génération d un modèle de features à partir d une ligne de produits, (b) des mesures facilitant le matching entre cartes ERP/besoins, (c ) la sélection des variantes coïncidant avec le profil non fonctionnel du produit demandé. Autres formes de variabilité: Les modèles de buts constitue une source de variabilité mais il y a en d autres (e.g., software, processus métier, base de données). Journée IE et Trace 19
Conclusion : Comprendre le comportement organisationnel par la modélisation des buts Le modèle rationnel de Goulder Buts officiels (stratégiques)? Flux de tâches les stratèges fixent les buts officiels leur mise en opération semble couler de source l ordonnancement des ressources et du personnel est la seule chose qui soit vue comme problématique Journée IE et Trace 20
Conclusion : Comprendre le comportement organisationnel par la modélisation des buts et si la transition méritait d être modélisée par un arbre de buts? Buts officiels (stratégiques) Buts opératoires 3 justifications à la modélisation des buts opératoires décisions sur les différentes manières d atteindre les buts officiels définir les priorités Flux de tâches découvrir les buts non officiels des différents groupes d intérêt et éviter les déviations Journée IE et Trace 21
Conclusion : Comprendre le comportement organisationnel par la modélisation des buts Un cadre de référence pour la modélisation des buts opératoires (C. Perrow) : la séquence <tâche, autorité, but opératoire> Autorité & Groupes d influence Tâches assurer le capital légitimer l activité coordonner les activités et relations internes & externes assurer les compétences nécessaires Les buts sont déterminés par le groupe dominant& reflètent les impératifs d une zone critique d activité Buts opératoires Journée IE et Trace 22
Questions & Commentaires Journée IE et Trace 23