De l Ingénierie des Besoins à l Ingénierie des Exigences : Vers une Démarche Méthodologique d Ingénierie de Systèmes Complexes et de Vérification Formelle Appliquée pour l Informatisation de PMEs/PMIs Nawel Amokrane Vincent Chapurlat, Anne-Lise Courbis et Thomas Lambolais Début de la thèse 03/2013 Journée des doctorants, 23/06/2013 Dans cette présentation Contexte et Objectifs de la thèse. Approche. Comparaison de langages: RDM, KAOS, GRL, UCM. Réflexions conclusion et perspectives. RDM : RquirementDefinitionmodel KAOS : Keep All Objectives Satisfied GRL : Goal-Oriented Requirement Language UCM : Use Case Maps 2 1
Contexte: Ingénierie des exigences L ingénierie des exigences est la phase la plus en amont de tout projet de développement Couvre multiples activités Analyse du domaine et élicitation: contexte organisationnel, partenaires, étendu du système Evaluation et négociation: résolution conflits, choix, priorités.. Documentation: structuration, formalisation validation: évaluation qualité 3 Contexte: Ingénierie des exigences Succès ou échec d un projet Les erreurs les plus couteuses à réparer: coût d une correction tardive = 200 fois coût d une correction initiale [Boehm & Papaccio, 1988] Les plus fréquentes et les plus tenaces Plusieurs parties prenantes : cultures et vocabulaires différents Conflits de points de vue Communication entre clients et développeurs --> incompréhensions Clients pas toujours conscients de leurs besoins Développeurs n ont pas la connaissance du domaine d application 4 2
Contexte : Ingénierie des exigences «Des exigences inadéquates, inconsistantes ou ambigües ont un impact critique sur la qualité des applications»[bell& Thayer, 1976] Travail important mais non systématique. Lourd pour les PMEs/PMIs Moyens Temps Compétences 5 Objectifs de la thèse Posséder une méthode et un outil qui favorisent une coopération optimale entre les clients, la MOA et la MOE lors des projets d informatisation des processus de gestion d une organisation de type PME/PMI Outiller l étape en amont du projet de développement d applications, qui s inscrit dans le domaine de la modélisation d entrepriseet de l ingénierie des exigences Répondre à la question de l autonomie de l utilisateur final pour l expression des besoins : l impliquer, le responsabiliser et l amener à «s organiser» Outiller le recueil des besoins et de modélisation, enrichi de moyens de vérification et d une méthode favorisant la validation «précoce» des besoins. 6 3
Objectifs de la thèse??? MOA : maitrise d ouvrage MOE : maitrise d oeuvre 7 Contexte : Modélisation d entreprise Comprendre et analyser la structure et le fonctionnement de l entreprise pour définir, vérifier et valider les besoins en développement Activité conceptuelle cruciale, complexe, efforts importants de mise en œuvre Nécessité d une méthode structurante «Un modèle d entreprise a pour objectif de formaliser tout ou une partie de l entreprise dans le but de comprendre ou d expliquer une situation existante ou pour réaliser puis valider unprojetconçu»[braesch etal,1995] 8 4
La modélisation d entreprise Lever le verrou de la complexité du système d information cible (multi vues, multi paradigmes) S appuyer sur une modélisation d entreprise «guidée» à travers des modèles de références : les cadres d architectures, les normes et standards. Une étape vers la vérification et la validation, pour éviter certaines erreurs et garantir une structuration. [Présentation Chapurlat] 9 Construits ISO 19440 Modèle d un langage de modélisation d entreprise Fonctionnelle Organisationnelle informationnelle Des ressources [ISO/DIS, 2004] 10 5
L architecture GERA - cadre de modélisation ISO 19439 Modèle Partiel = solution réutilisable pour un type de problème [Bernus& Nemes, 1997] Partial models may be prototypes or models of classes of enterprises which must be specialisedand ultimately instantiated in order to obtain the model of a particular enterprise [Bernus& Nemes, 1997] GERA : Generic Enterprise Reference Architecture 11 Carde de normalisation: étape vers la vérification formelle End User/ Business Expert Organisation view Resource view Information view Function view NLP Ideal Patterns Glossary Requirements and Business Modeling As-is / As-wished Formal Definition : Metamodel Workstations Might-be Might-be Business procedures Meta-model instantiation Meta-model instantiation Enterprise particular model To-be Verification Verification Generic level Constructs (ISO19440, UEML..) Partial level Particular level Informational objects Scenarios Business processes Model transformation Model transformation Validation Validation Public void do() {.} 12 6
Autonomie de l utilisateur? End User/ Business Expert? Organisation view Resource view Information view Function view NLP Ideal Patterns Glossary Requirements and Business Modeling As-is / As-wished Formal Definition : Metamodel Workstations Might-be Might-be Business procedures Meta-model instantiation Meta-model instantiation Enterprise particular model To-be Verification Verification Generic level Constructs (ISO19440, UEML..) Partial level Particular level Informational objects Scenarios Business processes Model transformation Model transformation Validation Validation Public void do() {.} 12 Critères du langage de modélisation des exigences 13 7
RDM, KAOS RDM [Zelm et al, 1995] KAOS [Van Lamsweerde, 2009] Concept de baseet Orientation Typed approche Niveaude détail Le Processus (activité d entreprise) Analyse préliminaire et modélisation orientées processus en vue d une conception détaillée de la solution Le But Définition du problème, raffinement des buts, gestions des risques, résolution d obstacles, Approches systématiquesplutôt top-down mais qui permettent des itérations (retours en arrière moins clair dans RDM), indépendante de l implémentation. Analyse détailléedu fonctionnement et de l organisation Recensement détaillé des exigences à réaliser par des composants potentiels de la solution Utilisateurs Analystes / ingénieurs Experts métier assistés par consultants MOA, analystes Vues couvertes Dufonctionnement Comment Informationnelle Quoi Domaine, processus,activité, opération, règles, Objectifs Object d entreprise et vu d objet De l organisation Qui Unité et cellule organisationnelle / Des ressources Où et Qui Composants+ entités fonctionnelles Opérations, événements, entrés et sorties Objets Agents(machine, humain, applicatif) Des exigences Pourquoi / Buts, exigences, hypothèse, obstacle Mécanisme de validation Revue (examendétaillé) des modèles Exécutionet simulation des processus Révisionde modèles, critères de complétudes, raisonnement formel sur la base des buts. Livrables Modèles de:domaines, processus métiers, objets.. (template détaillant les attributs) -Modèlesde : buts, objets, opérations, responsabilités, du comportement. Glossaire. -Un cahier des charge 14 UCM, GRL UCM [ITU T Z.151, 2008] GRL [ITU T Z.151, 2008] Concept de base et Orientation Le scénario Un chemin qui lie les responsabilités (les causes aux effets) sans préciser les messages échangés Typed approche Niveaude détail Utilisateurs Vues couvertes Dufonctionnement Comment Informationnelle Quoi Top-down, scénarios opérationnels et exigences fonctionnels, deux dimensions : comportement et structure Décisions de haut niveau sur la conception et le comportement/ fonctionnement du système. Consultant MOA, (requirements engineers and designers ) Fonctionnement : chemin tracé entres les responsabilités localisées dans le système Le composant objet / De l organisation Qui Acteur / Des ressources Où et Qui Des exigences Pourquoi LeBut Condition, état que l on veut que le système atteigne. Approche top-downd élicitation d exigences non fonctionnelles. Analyse stratégique et opérationnalisation des buts par des tâches (solutions) de haut niveau ConsultantMOA, analystes Tâches qui opérationnalisent les buts à décrire en terme d opération, processus, donnée utilisées et agents intervenants. / Ressources ( entités physiques ou informationnelles) / Buts, conflits, contributions.. Mécanisme de validation Lemécanisme : scenario pathtraversal Mécanisme d évaluation duniveau de satisfaction des buts. Livrables Cartesde la structure et du fonctionnement du système. Modèles de buts, alternatives de solutions. 15 8
Les concepts manipulés RDM KAOS UCM GRL Domaine Zone fonctionnelle:type de métier / / / Processus Activité / opération Processus métier opérationnelqui produit de la valeur ajouté Étapes du processus métier, lieu d utilisationet de création de l information Ressource Entités fonctionnelles(humaines, applicatives) accomplissent les opérations + composants Objet informationnel informationnels ou physiques produits et utilisés par les activités Opérationsdéclenchées par des événements et manipulant des objets réaliser exigence Opérationnalisation des exigences issues du raffinement de buts Agent (machine, humain, applicatif) responsable de la satisfaction d exigences Passifs: des entités Actifs : des agents Chemin reliantles responsabilités dans les composants Responsabilité : opération, fonction réalisée par une entité / Tâche: façon de faire, solution potentielle / Ressources ( entité physique ou informationnelle) composant / Evénement Déclenche les processuset activités Déclenche les opérations startpoint / But / objectif Attribut associéau domaine, processus, et activité devant être respecté Propriété désirée du système. Concept de base à partir du quel les reste est dérivé endpoint Buts avec évaluation du niveau de satisfaction et liens de contributions Obstacle / Situation oùle but, l exigence ou l hypothèse ne sont pas satisfaits Comportement Unité organisationnelle Séquencement des étapes (whene[..] do [..] ) Structureorganisationnelle et distributions des responsabilité Transition d états des objets par l applicationd opérations Exigence / Issue du raffinement de buts, opérationnalisablepar 1 agent du système Hypothèse / Issue du raffinement de buts, opérationnalisablepar 1 agent de l environnement / Conflitentre buts, contribution négative Chemin / / / / / / / / 16 Comparaison - Conclusion Les langages comparés Ne couvrent pas toutes les vues de la modélisation d entreprise Ne formalisent pas l écriture de règles métiers de gestion d une manière compréhensible par les gens du métier. Notations destinées aux experts : analystes, concepteurs langages orientés faits tels que SBVR [OMG, 2008] Notation textuelle, utilisation de langage naturel structuré. Modélisation formelle des règles métiers de gestion. Modélisation de la vue informationnelle et d une partie de la vue du fonctionnement. Relativement simple pour un utilisateur final. Possibilité de transformation vers des langages de niveau plus bas (UML, OCL,, SQL). 17 9
Conclusion Réflexions Existence de travaux NL --> SVBR, [Bajwaet al. 2011] SVBR < --> UML [Nemuraite et al. 2010], [cabot et al. 2010] UML --> Code [Smialek et al. 2012] Mais! SBVR, UML ne sont pas conçus pour des utilisateurs finaux. Les langages de haut niveau, comme SBVR, ne couvrent pas complètement la vue du fonctionnement ni la vue de l organisation. NL : Natural Language SBVR : Semantics of Business Vocabulary and Rules UML : Unified Modelling Language 18 Conclusion Réflexions S inspirer de la base formelle des langages étudiés Etendre leur méta-modèle pour gérer les autres vues (processus métiers, organisation ) + proposer une méthode! Langue Française Trouver un point d entrée intuitif à l utilisateur final, s inspirer du domaine de l organisation et des outils de recueil des besoins : interview, chaine de valeur, description de poste SBVR, ORM...? UCM, GRL UML, BPMN, TTCN Clients/ utilisateurs Java, VB 19 10
Conclusion Perspectives Réalisés Identification d un cadre de normalisation pour une modélisation d entreprise guidée. Etude et comparaison de langages d expression des exigences fonctionnelles et non fonctionnelles. Futurs (court terme) Etudier les possibilités du traitement automatique du langage naturel (Français) Définir des concepts génériques pour un formalisme accessible (simple et formel) Identifier et «peupler»les cellules du cadre Zachmanet identifier des règles de cohérence inter-cellules 20 Références [Bajwaet al. 2011] Bajwa, I., Lee, M., & Bordbar, B. (2011). Sbvrbusiness rules generation fromnaturallanguage specification. AAAI SpringSymposium. [Nemuraiteet al. 2010] Nemuraite, L., & Skersys, T. (2010). VETIS tool for editing and transforming SBVR business vocabularies and business rules into UML&OCL models. on Information and.. [OMG, 2008] Object Modeling Group (OMG). 2008 Semantics of Business Vocabulary and Business Rules Specification, Version 1.0. Available at http://www.omg.org/spec/sbvr/1.0/ [Van Lamsweerde, 2009] Van Lamsweerde, A. : Requirements Engineering: From System Goals to UML Models to Software, Specifications.Wiley (2009). [ISO/DIS, 2004] ISO/DIS 19440: Enterprise integration -Constructs for enterprise modelling(2004). [Zachman, 1987] Zachman, J.:A framework for information systems architecture. IBM Systems Journal, volume 26, (1987). [Zelmet al, 1995] Zelm, M., Vernadat, F., & Kosanke, K. (1995). The CIMOSA business modelling process. Computers in Industry. 22 11
Références [ITU T Z.151, 2008] ITU T, Recommendation Z.151 (11/2008): User Requirements Notation (URN) Language Definition, Geneva, Switzerland, approved November (2008). [Bell & Thayer, 1976] Bell, T.E., Thayer, T.A.: Software requirements: Are they really a problem?. ProceedingICSE '76 Proceedings of the 2nd international conference on Software engineering (1976). [Boehm & Papaccio, 1988] Boehm, B.W, Papaccio, C.: Understanding and controlling software costs, IEEE Transactions on Software Engineering (1988). [Nemuraiteet al. 2010] Nemuraite, L., Skersys, T.: VETIS tool for editing and transforming SBVR business vocabularies and business rules into UML&OCL models (2010). [Smialeket al. 2012] Smialek, M., Jarzebowski, N., Nowakowski, W.: Translation of Use case scenarios to java code. Computer Science (2012). [Braeschet al. 1995] Ch. Braesch, A. Hauratet J.M. Beving, L entreprise-système. La modélisation systémique en entreprise, Paris : Hermès, (1995). [Bernus& Nemes, 1997] Bernus, P., & Nemes, L. The contribution of the generalised enterprise reference architecture to consensus in the area of enterprise integration. Proceedings of ICEIMT97, (1997). 23 12