Daniel Amyot, Université d’Ottawa Basé sur du materiel de:

Slides:



Advertisements
Présentations similaires
Developpement Process « Coding party !! » Tony Carnal Altran.
Advertisements

Les processus.
UML EPITECH 2009 UML1 - Introduction UML – Définition – Historique – UML en entreprise – Couverture Concepts – Objet – Classe –
Les systèmes d'information 1- Une pratique quotidienne 2- Les données 3- Approche conceptuelle 4- Notion de serveur 5- Conception d'un système d'information.
UML2 : Panorama de la notation Laurent Henocque Enseignant Chercheur ESIL/INFO France
Projet de formation en conduite de changement Laurent GIROD-ROUX / mars 2016.
IP Multicast Text available on
DIFFERENTIATION NO ONE CAN COMPEL A STUDENT TO LEARN. (MEIRIEU)
Les rprésentation des signaux dans le cadre décisionnel de Bayes Jorge F. Silva Shrikanth S. Narayanan.
1. Introduction.
Initiation à la conception des systèmes d'informations
Bruxelles, 6 décembre 2012 Health sector days
Evaluer par compétences
Ch.1 : Modélisation des systèmes par SysML
Ingénierie des besoins - Février 05
Initiation aux bases de données et à la programmation événementielle
Qualité de Web Services (QoS ou QdS)
Cours MGL 847 Amélioration des processus
PORTEFEUILLE DE COMPETENCES
OWL-S.
Informatique et Sciences du Numérique
Work: ISA8895 Implementation Section: Interoperability Chapter: B2O
Les bases de données et le modèle relationnel
L’exposé 3- 4 mins long - 4 minutes is a maximum, not a target.
Pile IGMPv3 de Host.
Technologies de l’intelligence d’affaires
User Requirements Notation (Partie II) – Use Case Maps
Lignes de produits logiciels et modèles de caractéristiques
Daniel Amyot, Université d’Ottawa Basé sur du materiel de:
Technologies de l’intelligence d’affaires Séance 14
Samples for evaluation from All Charts & Templates Packs for PowerPoint © All-PPT-Templates.comPersonal Use Only – not for distribution. All Rights Reserved.
Les processus métiers : concepts, modèles et systèmes Claude Godart Université de lorraine. Esstin
Hotel Divisions & Departments. Departments in Rooms Division Front Office is responsible for guest registration and check-out. It includes mail and information.
CMMI Capability Maturity Model Integration « Importance de CMMI dans la gouvernance IT basée sur COBIT »
1 La gestion par activités (ABM) pour mieux gérer les coûts et les processus dans l’organisation. S o l u t i o n s `
- 20/02/ TTM key success factor 1 : Work in a project team …. So we must work in a team ! Mark & sales Technology NTW, IT & Device Implementation.
Modélisation avec UML 2.0 Partie II Diagramme de classes.
La stratégie pédagogique en
Vuibert Systèmes d’information et management des organisations 6 e édition R. Reix – B. Fallery – M. Kalika – F. Rowe Chapitre 1 : La notion de système.
1. Introduction.
Qu'est-ce que l'évaluation ? L’évaluation est une démarche qui vise à donner de la valeur, prendre du recul, émettre un constat sur une situation, et prendre.
1 ISO/TC 176/SC 2/N1219 ISO 9001:2015 Revision overview - General users July 2014.
GOUVERNANCE DES SYSTEMES D’INFORMATION IS governance.
Introduction to Computational Journalism: Thinking Computationally JOUR479V/779V – Computational Journalism University of Maryland, College Park Nick Diakopoulos,
SYSTEME DE MANAGEMENT DE LA QUALITE : LA NOUVELLE NORME ISO 9001 version 2015.
Chapitre2: SGBD et Datawarehouse. On pourrait se demander pourquoi ne pas utiliser un SGBD pour réaliser cette structure d'informatique décisionnelle.
Auto-évaluation des besoins en matière de facilitation des échanges dans le cadre de l'OMC – (le PAYS) (VILLE) (DATE) 2014.
Education & Sensibilisation dans les Sanctuaires PASA
© Robert Godin. Tous droits réservés.
Analyse Fonctionnelle Structurelle Comportement des systèmes Mécanique
Les cas d’utilisation 420-KE2-LG.
Ecran 1 de 14 Techniques de collaboration et de plaidoyer Techniques pour améliorer le travail en collaboration Objectifs d’apprentissage Comprendre les.
1-1 Introduction to ArcGIS Introductions Who are you? Any GIS background? What do you want to get out of the class?
La collecte d’informations Présenté par: Boudries. S.
Génie Logiciel DÉFINITION DES BESOINS. Cahier de charges: définition  Le Cahier des Charges (CDC) est un document par lequel la maîtrise d'ouvrage exprime.
LES AXES TRAITÉS : DÉFINITION D’ÉVALUATION L’ÉVALUATION PEDAGOGIQUE FONCTION DE L’ÉVALUATION CARACTERISTIQUES DE L’ÉVALUATION TYPES D’ÉVALUATION CONCLUSION.
Initiation à la conception des systèmes d'informations. Cours N°1 : introduction. Souheib Baarir Université Paris Ouest Nanterre.
LA CONCEPTION ET L ’AMÉLIORATIOND’UN SYSTÈME DE PRODUCTION SÉANCE 2 GOP.
Panorama of Recommender Systems to Support Learning
Tableau de bord d’un système de recommandation
Concepts et étapes Ateliers de formation à la mise en œuvre
1 Théorie générale des systèmes Présenté Par Monsieur Nzukam Nguiffo Guillaume Ingénieur statisticien.
Utilisation des arts visuels à des fins d’enseignement scolaire
PAF Guillaume Martin - Fabrice Cizeron - Xavier Roulot
Soutenance de thèse: Okba Taouali 1 02/08/2019 Fathia AZZOUZI, Adam BOURAS, Nizar JEBLI Conceptual specifications of a cooperative inter- machines dialogue.
Non-conformités Des non-conformités Pourquoi? Rev.3 (2015/06/01)
Modélisation fonctionnelle : ETUDE DE CAS. 01 Modélisation fonctionnelle :étude de cas Ce chapitre va nous permettre d’illustrer pas à pas, sur une première.
IMPROVING PF’s M&E APPROACH AND LEARNING STRATEGY Sylvain N’CHO M&E Manager IPA-Cote d’Ivoire.
Transcription de la présentation:

User Requirements Notation (URN) Partie 1: Goal-oriented Requirement Language (GRL) Daniel Amyot, Université d’Ottawa Basé sur du materiel de: Mussbacher et Amyot 2009-2018

GRL UCM URN en un coup d’œil éléments intentionnels + acteurs + liens + indicateurs + stratégies Liens URN UCM responsabilités + causalité + composantes + scénarios

Contenu Introduction à User Requirements Notation (URN) Buts et justifications Goal-oriented Requirement Language (GRL) Concepts de GRL Évaluations Exemples Outils Indicateurs Tous les modèles sont faux, mais quelques modèles sont utiles.1 [1] George Edward Pelham Box (1919-)

Aperçu d’URN (1) URN est un langage graphique simple et semi-formel permettant de modéliser et analyser des exigences sous formes de buts et de scénarios, de même que leurs relations Combines deux notations existantes Goal-oriented Requirement Language (GRL) (basé sur i* & NFR Framework) Use Case Maps (UCMs) Support pour l’élicitation, l’analyse, la spécification, et la validation d’exigences Permets aux ingénieurs système/logiciel/en exigences de découvrir et de spécifier des exigences pour des systèmes proposés ou en évolution, et d’analyser ces exigences en termes de rectitude et de complétude. 80 50 -10 40 60 Regular Bus Express Bus Take own car Hitch a ride -90 -20 20 OR 45 -40 -30 Commuter Work during commute Take public transport Take private transport Minimize travel time Minimize time lost by commute Minimize cost for commute Minimize infrastructure cost Share ongoing cost Car transport X drive car Hitch a Ride hitch a ride in car Express Bus commuter work email deal with take #100 Regular Bus take #96 take #97 take #95 elevator take secure home ready to leave cubicle in commute stay Take Elevator call select floor stairs arrived Secure Home lock door arm system out2 out1 use alternative alarm system Arm System accept code check armed [matched] matched] [not not armed [quit] Commuting URN: www.usecasemaps.org/urn jUCMNav: www.softwareengineering.ca/jucmnav Virtual Library: www.usecasemaps.org/pub

Aperçu d’URN (2) Les modèles URN peuvent être utilisés pour spécifier et analyser divers types de systèmes réactifs, de processus d’affaires, et de services en télécommunications jUCMNav Éditeur et analyseur URN Plug-in Eclipse Projet open source

Aperçu d’URN (2) vision Model business goals, stakeholders’ priorities, alternative solutions, rationale, and decisions GRL called strategies, compared with GRL evaluation mechanism traceability with URN links extensible with metadata with UCM traversal mechanism based on UCM scenario definitions Model & test use cases; investigate high level architecture; transform to more detailed models UCM more detailed models A GRL / UCM model visually communicates business objectives and constraints / high-level functional requirements to all stakeholders

ITU-T Z.151: URN - Language Definition Première et seule norme internationale à supporter de façon explicite, graphique et intégrée les notions de buts et de scénarios, et les liens qui les unissent. Membre de la famille de langages de l’UIT-T Union internationale des télécommunications Organisme des Nations Unies: 193 pays + compagnies membres ITU-T Z.150 (02/03, revised 02/11): User Requirements Notation (URN) - Language requirements and framework ITU-T Z.151 (11/08, corrigendum 2011, revised 2012): User requirements notation (URN) - Language definition Méta-modèle, syntaxes abstraite/concrète, sémantique, analyse, exemples… Version 2018 soumise, avec syntaxe textuelle pour GRL/UCM

Langages de l’UIT-T SDL: Specification and Description Language Pour définir et exécuter des systèmes réactifs complets MSC: Message Sequence Charts Pour définir des scénarios orientés-messages ASN.1: Abstract Syntax Notation One Pour définir des types de données TTCN-3: Testing and Test Control Notation Pour définir des cas et des environnements de test URN: User Requirements Notation Goal-oriented Requirement Language (GRL) Notation Use Case Map (UCM) Pour définir des buts, des scénarios, et des exigences Profiles UML 2.x pour certains de ces langages (e.g., SDL)…

Buts et justifications

Qu’est-ce qu’une justification (rationale)? Une justification (ou raison-d’être) représente le raisonnement qui mène au système. Les justifications incluent: Les problèmes adressés Les alternatives qui ont été considérées Les décisions prises afin de résoudre les problèmes Les critères qui ont guidé les décisions Les débats que les participants ont eu lors de la prise de décision. [Bruegge et Dutoit, chapitre 12]

Utilisation de justifications en génie logiciel Amélioration du support de conception Évite l’évaluation dupliquée d’alternatives faibles Produit des compromis explicites et cohérents. Amélioration de la documentation Facilite la revue de la conception par les non-développeurs (gestionnaires, avocats, scribes…) Amélioration du support de maintenance Offre un contexte de conception aux gens qui font l’entretien du logiciel Amélioration de l’apprentissage Les nouveaux employés peuvent apprendre et comprendre la conception en étudiant les décisions qui l’ont produite.

Exemple: Guichet automatique (Tableau) Question: Mécanismes d’authentification alternatifs? Service: Authentification Décision: Carte à puce + NIP Critère 1: Coût unitaire Critère 2: Vie privée Option 1: Numéro de compte + – Option 2: Empreintes digitales + – Option 3: Carte à puce + NIP + Version qualitative…

Exemple: Guichet automatique (Tableau) Question: Mécanismes d’authentification alternatifs? Service: Authentification Décision: Carte à puce + NIP Critère 1: Coût unitaire Critère 2: Vie privée Option 1: Numéro de compte 1 20 Option 2: Empreintes digitales 30 4 Option 3: Carte à puce + NIP 2 40 Version quantitative… Questions: Relations entre critères? Passage à l’échelle? Et les partie prenantes?... Peut-on faire mieux qu’un simple tableau?

Qu’est-ce qu’un but en général? Un but (goal) représente un objectif d’affaires, d’organisation ou de système. Une exigence spécifie de quelle façon un but devrait être atteint par un système proposé. Opérationnalisation Le processus de définition d’un but avec suffisamment de détails pour permettre que ses sous-buts aient une définition opérationnelle Décomposition Le processus de subdivision d’un ensemble de buts en sous-groupes logiques afin de les exigences du système soient plus facilement comprises, définies et spécifiées Obstacles Comportements ou autres buts qui préviennent ou bloquent l’atteinte d’un but donné. En identifiant des obstacles aux buts abstraits nous pouvons considérer les façons de faire échouer les buts et anticiper les cas exceptionnels.

Rôles joués par les buts en I.E. [van Lamsveerde, 2009] Décrire la justification des exigences Aider à identifier les exigences qui les satisferont Fournir une structure pour l’argumentation Offrir une base pour démontrer l’alignement du système futur avec les objectifs stratégiques de l’entreprise Offrir un critère précis pour la complétude des exigences Offrir un critère précis pour la pertinence des exigences Offrir une façon naturelle de structurer une spécification d’exigences, de même que les raffinements d’exigences Offrir une base pour l’analyse de risques Offrir un environnement pour gérer les conflits entre exigences Offrir un critère pour délimiter la portée du système Supporter l’analyse de dépendances entre composantes du système Supporter le raisonnement sur les diverses alternatives possibles Faciliter la gestion de la traçabilité Offrir un contexte pour supporter l’évolution …

Goal-oriented Requirement Language (GRL)

Aperçu de GRL Goal-oriented Requirement Language Notation graphique (syntaxe textuelle en cours de normalisation) Basé sur i* et le NFR Framework (U. de Toronto) Relie les exigences aux objectifs d’affaires Permet de raisonner sur les exigences (surtout les non-fonctionnelles) et les compromis Indicateurs, stratégies, et mécanismes d’extension GRL modélise le « pourquoi » Objectifs, alternatives, et raisonnements (justifications!) Peu de détails opérationnels Supporte l’analyse de buts et l’évaluation d’alternatives et de compromis Quels acteurs seront heureux des décisions? Il n’y a rien de comparable dans UML, SysML, ou BPMN… The Goal-oriented Requirement Language (GRL) addresses most of URN’s additional objectives. Goal-oriented modeling has been proposed in the requirements engineering community for a number of years and several approaches have been published. GRL is a rather new addition to this growing list of techniques but builds on the well-established NFR framework (for non-functional requirements), and the agent-oriented language i* (for the modeling, analysis, and reengineering of organisations and business processes. GRL captures business or system goals, alternative means of achieving goals (either objectively or subjectively), and the rationale for goals and alternatives. The notation may be applied to non-functional as well as functional requirements.

Notation GRL . + . + Exemple GRL : Petit Magasin en Ligne Ressource + Business Owner Increase Sales Online Shopper Payment Offer Online Shopping + + Contribution Have System Security Dépendance Bux-doux Acteur Minimize Cost of Terminal + + . Corrélation Have Security of Terminal Have Security of Host _ + Décomposition . + . + Access Authorization Biometrics is no regular, off-the-shelf technology Encryption Ensure Authentication AND OR Tâche Provide Identification Opinion Use Fingerprint Use Password Use Cardkey But

Notation GRL de base: Éléments intentionnels But (Goal) Quantifiable (souvent fonctionnel) But-doux (Softgoal) Qualifiable mais non-mesurable (souvent non-fonctionnel) Tâche (Task) Solution ou activité qui atteint un but ou qui contribue partiellement à l’atteinte d’un but-doux Opinion (Belief) Décrit le raisonnement, la justification Ressource (Resource) Produit, objet ou autre ressource

Notation GRL de base: Liens Contribution Liens pour éléments intentionnels Peuvent être qualifiés Ind+ : on hésite entre Réalise (suffisant) et Aide (insuffisant) Ind- : on hésite entre Brise (suffisant) et Nuit (insuffisant) Corrélation Comme une contribution, mais indique un effet de bord Décomposition (AND, OR, XOR) Définit ce dont un élément intentionnel a besoin pour être satisfait. Dépendances Entre acteurs (et leurs éléments intentionnels), avec un sujet de dépendance ? Brise Nuit Ind- Inconnu Réalise Aide Ind+ Égal

Acteurs et dépendances GRL Les éléments intentionnels GRL peuvent être places dans des acteurs Des dépendances entre acteurs peuvent être définies Point de vue stratégique

Pourquoi GRL? Les buts auront une influence importante sur l’élaboration des exigences. Cependant, les buts et objectifs des parties prenantes sont complexes et vont entrer en conflit. GRL permet d’exprimer et de clarifier les exigences ambiguës, provisoires, et mal définies Supporte la prise de décision, les argumentations, la négociation, et la détection & résolution de conflits Documente les critères de décision et les justifications GRL identifie les exigences alternatives et diverses frontières possibles pour le système GRL offre un retraçage entre les objectifs stratégiques et les exigences techniques GRL permet la réutilisation de buts abstraits et stables lorsque le système évolue

Récits utilisateur et modèles orientés-buts As a [Actor] I want to [Task] in order to [Contribution] achieve [Goal] En tant que [Acteur] je veux que [Tâche] afin de [Contribution] à [But] Ce récit utilisateur identifie la tâche d’un acteur et une contribution de la tâche au but (dans ou hors de l’acteur) As a professor, I want to use Brightspace in order to help minimize the number of lost assignments.

GRL – Stratégies d’évaluation #1 GRL Example: Tiny Online Business 25 Business Owner Business Owner 42 Increase Sales Increase Sales * 100 * 100 33 Online Shopper Online Shopper Payment Payment Offer Online Shopping Offer Online Shopping + high + 44 high System Security System Security Importance 75 medium Cost of Terminal Cost of Terminal + 25 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + -75 * 100 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology 100 Authentication Authentication AND OR * -75 * 100 Identification Identification Niveau de satisfaction initial Fingerprint Fingerprint Password Password Cardkey Cardkey

Évaluations avec GRL L’évaluation d’un graphe GRL montre l’impact de décisions qualitatives sur les buts de haut-niveau La propagation est habituellement de bas vers le haut Évaluation qualitative ou quantitative du niveau de satisfaction Prend en considération divers contributeurs: Degré de satisfaction (satisfait, insatisfait, …) Opérateurs de composition (ET, OU) Contributions et corrélations (+/-, suffisant ou non) Dépendances entre éléments intentionnels Plus complet qu’avec de simples tableaux d’avantages et inconvénients (exemple du guichet automatique)

Stratégies GRL Une stratégie GRL définit les valeurs de satisfaction initiales pour un ensemble d’éléments intentionnels du modèle Décrit une solution globale Peuvent être comparées les unes avec les autres lors de l’analyse de compromis L’analyse peut se faire de façon quantitative ou qualitative, et plusieurs algorithmes peuvent être définis

GRL – Approche qualitative ou quantitative Qualitative Approach Contribution types: from Make to Break Importance: High, Medium, Low, or None Qualitative satisfaction levels Quantitative Approach Contribution types: [-100, 100] Importance: [0, 100] Quantitative satisfaction levels: [-100, 100] Hybrid Approach is also possible Qualitative contribution types Quantitative importance Quantitative satisfaction levels GRL Satisfaction Levels: (qualitative) Satisfied Weakly Satisfied Unknown Weakly Denied Denied Conflict None

GRL – Stratégies d’évaluation #2 GRL Example: Tiny Online Business -34 Business Owner Business Owner -17 Increase Sales Increase Sales * 100 * 100 Online Shopper Online Shopper -23 Payment Payment Offer Online Shopping Offer Online Shopping + high + -31 high System Security System Security -75 medium Cost of Terminal Cost of Terminal + -75 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + -75 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology 100 Authentication Authentication AND OR * -75 * 100 Identification Identification Fingerprint Fingerprint Password Password Cardkey Cardkey

GRL – Stratégies d’évaluation #3 GRL Example: Tiny Online Business 52 51 Business Owner Business Owner Increase Sales Increase Sales * 100 * 100 68 Online Shopper Online Shopper Payment Payment Offer Online Shopping Offer Online Shopping + high + 90 high System Security System Security medium Cost of Terminal Cost of Terminal + 100 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + * 100 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology Authentication Authentication AND OR Identification Identification Fingerprint Fingerprint Password Password Cardkey Cardkey

Échelle de satisfaction [0..100], plus intuitive On peut passer de [0..100] à [-100..100] (bouton de droite sur URNspec). La satisfaction 25 n’est plus “bonne” (orange)! Option de visualisation avec [0..100] pour évaluations Une échelle de satisfaction [0..100] est plus intuitive que [-100..100] pour bien des personnes (surtout quand elle est combinée à des contributions négatives)

Outil jUCMNav 7, pour Eclipse

Métamodèle abstrait de URN (I)

Métamodèle abstrait de URN / GRL (II)

Stratégies dans jUCMNav Étoile (*) ou forme au contour pointillé indique une valeur initiale d’une stratégie donnée. Si la ligne pointillée est rouge alors cette valeur aurait pu être calculée (overridden) Toutes les autres valeurs sont évaluées à l’aide d’un algorithme de propagation.

Stratégies GRL

Algorithmes de propagation sous jUCMNav 7 algorithmes de propagation inclus (incluant Quantitatif et Qualitatif) Supporte la résolution automatique de conflits Utilise les liens pour l’évaluation (dans cet ordre): 1) Décompositions, 2) Contributions, 3) Dépendances « Tolérance » utilisée par les contributions de poids autres que 100 et -100 (mettre à 0 svp!) - Automatic conflict resolution does not involve user

Propagation quantitative (1)

Propagation quantitative (2): Règles arithmétiques

Propagation quantitative (3): Exemples Minimum pour AND, maximum pour OR/IOR Les contributions sont additives, mais elles sont aussi normalisées

Propagation quantitative (3): Évaluation d’acteurs Évaluation pour gérer les négociations entre parties prenantes. Aide à analyser et à comparer les niveaux de satisfaction globaux de chaque acteur pour une stratégie donnée Calculée à partie des attributs importance (Wx) des éléments intentionnels liés à l’acteur Criticality and priority is high, medium or low

Propagation quantitative (5): Exemples On ne peut pas être plus satisfait que ce de quoi on dépend. Telecom Provider (44) Low Cost (29) 100 Reliability (100) High Perf (60) - 75 Weight 25 La satisfaction d’acteur (A) aide à comprendre les compromis de stratégies à ce niveau. Calculée selon l’importance (Wx) et la satisfaction des éléments contenus.

Propagation qualitative: Décomposition ET/OU

Motif (pattern) récurrent en GRL

GRL Exemple I – Contexte Nouveau service pour réseau sans-fil Où mettre l’intelligence (la logique du service)? Où mettre les données du service?

GRL Example I – Intentional Elements and Actors

GRL Example I – Links

GRL Example I – Contribution Types Qualitative or quantitative

GRL Example I – Qualitative Model Evaluation

GRL Example I – Quantitative Model Evaluation

Exemple GRL #2 – Contexte Modèle GRL qui se préoccupe de la protection de la vie privée dans un environnement hospitalier Researchers want access to patient data but the Health Information Custodian (HIC – i.e., the hospital) needs to protect patient privacy, as required by law (PHIPA in Ontario). The process of accessing databases must ensure privacy. As required by law, a Research Ethics Board (REB) is usually involved in assessing privacy risks for the research protocol proposed by a researcher. DB administrators also want to ensure that DB users are accountable for their acts.

Exemple GRL #2 – Modèle

Un modèle, plusieurs diagrammes

Exemple GRL #2– Évaluation quantitative Échelle: [-100, 100]

Outil – SanDriLa (Plug-in pour Visio)

Outil – OpenOME, avec plug-in Eclipse http://www.cs.toronto.edu/km/openome/

Outil Web – Creative Leaf En ligne: http://semvm02.city.ac.uk/cgm/ Vidéos: https://www.youtube.com/channel/UCjU8aqp-93qP8DnbDKXQpMQ

Outil commercial: Objectiver (pour KAOS) http://www.objectiver.com/

jUCMNav (plug-in Eclipse) Features for GRL 7 GRL evaluation algorithms, with color highlight One model, multiple diagrams References to actors and intentional elements Drag&drop from outline or via properties Auto-layout Catalogues For exporting/importing/reusing common models Export graphics (.bmp, .gif, .jpg) Export strategy evaluations (.csv) URN links (for integration with UCMs) Export to DOORS Navigator view Outline view Editor Scenarios and Strategies view Properties view Toolbar Palette

Inclusion de mesures dans les modèles GRL GRL inclut une notion de satisfaction de buts, avec des échelles qualitative et quantitative ([-100..100], et maintenant [0..100]). Cependant, nous avons souvent besoin de mieux relier les observations sur le monde réel au modèle orienté-buts, avec des unités spécifiques au domaine telles que: Devises (p.ex., revenus en $) Durées (p.ex., temps d’attente à l’hôpital, en heures) Nombres (p.ex., nombre d’étudiants admis en SEG) GRL permet de définir ce genre d’information et de l’intégrer au reste du modèle Indicateur (Key Performance Indicator ― KPI) Les KPI aident à mesurer les buts et les ENF avec des métriques quantifiables. Les KPI en GRL peuvent être fournies par des sources externes d’informations, transformant ainsi un modèle GRL en un outil de surveillance (p.ex.: un tableau de bord ― dashboard). Average Work Time (in min)

Indicateurs GRL (KPI) En GRL, un KPI est défini comme étant un élément intentionnel, mais avec des caractéristiques supplémentaires: Attributs (pour une stratégie GRL donnée) Une valeur d’évaluation (evaluation), observée de l’extérieur ou simulée dans une stratégie (what-if) Une valeur cible (target); le KPI est entièrement satisfait si la valeur d’évaluation l’atteint Une pire valeur (worst); le KPI est entièrement insatisfait si la valeur d’évaluation l’atteint Une valeur de seuil (threshold); le KPI est neutre si la valeur d’évaluation l’atteint. Une unité (unit), par exemple $ Associations (pour un modèle GRL donné) Peut faire partie de contributions ou de décompositions

Sub-process Performance Model Link KPI Information Element (Dimension) KPI Value sets Strategies

Indicateurs: De Current à Satisfaction Gestionnaire $1300 ??? ??? Coûts des employés Profits maximisés 50 Attribute Value GRL Satisfaction Target $1000 100 Threshold $1500 Worst-case $2500 -100 Current $1300 ???

Indicateurs: De Current à Satisfaction Gestionnaire $1300 40(*) 20 Coûts des employés Profits maximisés 50 Attribute Value GRL Satisfaction Target $1000 100 Threshold $1500 Worst-case $2500 -100 Current $1300 40

Des KPI aux niveaux de satisfaction GRL Note: Une interpolation linéaire est présentement utilisée pour calculer la satisfaction, qui est fonction des valeurs evaluation, target, threshold, and worst.

Conversion dans les indicateurs GRL [0..100]

Extensions de jUCMNav pour KPI et monitoring Business Process Compliance with URN p. 66

KPI: Exemple de transport (de G. Mussbacher) Commuter Minimize time lost by commute Minimize cost for commute 40 50 50 60 Work during commute Minimize travel time Minimize infrastructure cost Share ongoing cost -10 100 80 100 -30 80 45 -40 100 100 Average Travel Time (in min) Commuting Monthly Infrastructure Cost (in $) Average Work Time (in min) OR Average Ongoing Cost (in $) Take public transport Take private transport OR OR Key Performance Indicator (KPI) Regular Bus Express Bus Take own car Hitch a ride

KPI: Valeurs réelles vers valeurs de satisfaction Model Value (Satisfaction Value) Real World Value Regular Bus Express Bus Take own car Hitch a ride Average Work Time (in min) 80  49 45  29.75 -10  4.5 -10  4.5 Target Value (60) Threshold Value (5) Worst Value (0) Average Travel Time (in min) -40  56 -30  52 80  24 80  24 Target Value (20) Threshold Value (40) Worst Value (80) Monthly Infrastructure Cost (in $) 80  10 80  10 -90  455 -20  140 Target Value (0) Threshold Value (50) Worst Value (500) Average Ongoing Cost (in $) 80  68 60  76 -20  120 20  92 Target Value (60) Threshold Value (100) Worst Value (200)

Exécution de stratégies avec indicateurs (1/2) Strategy “Regular Bus”: Regular Bus = 100 Example: Commuting 40 Commuter Commuter 20 80 Minimize time lost by commute (100) Minimize time lost by commute Minimize time lost by commute Minimize cost for commute (50) Minimize cost for commute Minimize cost for commute 40 50 50 60 80 -40 80 80 Work during commute Work during commute Minimize travel time Minimize travel time Minimize infrastructure cost Minimize infrastructure cost Share ongoing cost Share ongoing cost 100 100 -40* 100 100 100 Average Travel Time (in min) Average Travel Time (in min) Average Travel Time (in min) Commuting Commuting 80* 80* Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Average Work Time (in min) Average Work Time (in min) Average Work Time (in min) OR 80* 100 Average Ongoing Cost (in $) Average Ongoing Cost (in $) Average Ongoing Cost (in $) Take public transport Take public transport Take private transport Take private transport KPI “Regular Bus”: Av. Work Time = 4980 Av. Travel Time = 56-40 Mo. Infrast. Cost = 1080 Av. Ongoing Cost = 6880 OR OR 100* Regular Bus Regular Bus Regular Bus Express Bus Express Bus Take own car Take own car Hitch a ride Hitch a ride

Exécution de stratégies avec indicateurs (2/2) Strategy “Hitch a ride”: Hitch a ride = 100 Example: Commuting 22 Commuter Commuter 35 -4 Minimize time lost by commute Minimize time lost by commute Minimize time lost by commute (100) Minimize cost for commute Minimize cost for commute Minimize cost for commute (50) 40 50 50 60 -10 80 -20 20 Work during commute Work during commute Minimize travel time Minimize travel time Minimize infrastructure cost Minimize infrastructure cost Share ongoing cost Share ongoing cost 100 100 80* 100 100 100 Average Travel Time (in min) Average Travel Time (in min) Average Travel Time (in min) Commuting Commuting -20* -10* Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Average Work Time (in min) Average Work Time (in min) Average Work Time (in min) OR 20* 100 Average Ongoing Cost (in $) Average Ongoing Cost (in $) Average Ongoing Cost (in $) Take public transport Take public transport Take private transport Take private transport KPI “Hitch a ride”: Av. Work Time = 4.5-10 Av. Travel Time = 2480 Mo. Infrast. Cost = 140-20 Av. Ongoing Cost = 9220 OR OR 100* Regular Bus Regular Bus Express Bus Express Bus Take own car Take own car Hitch a ride Hitch a ride Hitch a ride

Agrégation de KPI Dans jUCMNav, les valeurs d’évaluation KPI peuvent aussi être calculées (agrégées) à partir d’autres KPI, un peu à la manière d’Excel Algorithme d’évaluation GRL avec formules pour KPI

Autres langages orientée-buts NFR Framework, par Mylopoulos et al., Toronto: Analyse qualitative par propagation i* Framework, par Yu et al., Toronto: Modélisation d’organisation et de dépendances entre acteurs KAOS (Keep All Objectives Satisfied), par van Lamsweerde et al., Louvain & Oregon Analyse d’obstacles, logique temporelle et vérification de modèles GBRAM (Goal-Based Requirements Analysis Method), par Antón et al., Atlanta Tropos, par Fuxman, Giorgini , Mylopoulos et al., Trento & Toronto Pour conception de systèmes multi-agents, sécurité. Formal Tropos: logique temporelle et vérification SMILE (Structural Modeling, Inference, and Learning Engine) et GeNie, par Druzdzel et al., Pittsburgh Aide à la décision, approches avec probabilités, théorie de la décision, et réseaux de Bayes BIM (Business Intelligence Model), par Mylopoulos, Amyot et al., Toronto & Ottawa Buts, situations et indicateurs GRL est le premier à être standardisé Bon aperçu: http://www.cs.utoronto.ca/~alexei/pub/Lapouchnian-Depth.pdf Liste d’outils: http://istarwiki.org (i* Wiki) iStar 2.0: https://sites.google.com/site/istarlanguage/home

Applications industrielles? Yu, E., Amyot, D., Mussbacher, G., Franch, X., Castro, J.: Practical Applications of i* in Industry: The State of the Art. Mini-tutorial, 21th IEEE International Requirements Engineering Conference (RE 2013), Rio de Janeiro, Brazil, July 18, 2013. IEEE CS, 366-367 Alistair Mavin, Philip Wilkinson, Sabine Teufl, Henning Femmer, Jonas Eckhardt, Jakob Mund: Does Goal-Oriented Requirements Engineering Achieve Its Goal? 25th IEEE International Requirements Engineering Conference (RE 2017), Lisbon, Portugal, September 2017. IEEE CS, 174-183 Discute de l’écart entre la recherche et la pratique

Dilbert et les buts

Métamodèle concret (pour diagrammes)

Sommaire de la notation GRL (a) GRL Elements Belief Goal Softgoal Resource Task Actor with Boundary Collapsed Actor Satisfied Weakly Satisfied Unknown Denied Weakly Denied Conflict None Make Help Some Positive Break Hurt Some Negative (d) GRL Contributions Types (c) GRL Satisfaction Levels (b) GRL Links Contribution Correlation Dependency Decomposition Means-End Indicator Exceeds +

Quiz! Pourquoi les justifications sont-elles importantes? Comment les modèles orientés-buts (p.ex. en GRL) peuvent-ils être supérieurs à l'utilisation des tableaux de comparaisons? GRL est-il plus approprié pour répondre à des questions «pourquoi» ou à des questions «quand»? Comment peut-on définir un obstacle avec GRL? Qu'est-ce qu'une stratégie GRL? Quelle est la différence entre une évaluation quantitative et une évaluation qualitative? Quels sont les trois types de poids que l’on peut spécifier dans un modèle GRL? Si un modèle GRL évalué retourne 48 comme évaluation d'un acteur, est- ce bon ou mauvais? Pourquoi les indicateurs sont-ils importants? Les contributions « 100 » et la décomposition AND sont-elles semblables?