«SEG 3501» D. Amyot uOttawa SEG 3501- Module 6 Intégration de l'ingénierie des exigences au processus logiciel Objectifs: ―Ingénierie des exigences dans.

Présentation au sujet: "«SEG 3501» D. Amyot uOttawa SEG 3501- Module 6 Intégration de l'ingénierie des exigences au processus logiciel Objectifs: ―Ingénierie des exigences dans."— Transcription de la présentation:

1 «SEG 3501» D. Amyot uOttawa SEG 3501- Module 6 Intégration de l'ingénierie des exigences au processus logiciel Objectifs: ―Ingénierie des exigences dans le RUP ―Ingénierie des exigences dans les méthodes agiles ―XP, Lean, Scrum ―Comparaison, intégration ―SEMAT

2 «SEG 3501» D. Amyot uOttawa Dilbert et les processus… Module 6 : IE et processus2

3 «SEG 3501» D. Amyot uOttawa La perfection est atteinte non pas quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever Antoine de Saint-Exupéry (1900 - 1944), “Wind, Sand and Stars” Module 6 : IE et processus3

4 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus4 Rational Unified Process (RUP) Unique implémentation commerciale du processus de développement unifié (UP): ―par Jacobson, Booch, Rumbaugh (1996-2003) ―évolution d'Objectory (1992) et précédemment de l’approche Ericsson ―Produit d’IBM Vocabulaire et concepts: ―artefacts, rôles, disciplines et activités ―processus piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental

5 «SEG 3501» D. Amyot uOttawa Nature de RUP RUP est un cadre de développement de processus ―Pas un processus en lui-même Besoin de l’adapter aux besoins du projet http://www.ibm.com/developerworks/downloads/r/rup/ Module 6 : IE et processus5

6 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus6 Vocabulaire RUP (1) Artefact ―Élément d'information produit pendant le développement (document, diagramme, compte rendu, code source, modèle, etc.) Rôle ―Ensemble de compétences et de responsabilités. ―RUP définit ~30 rôles à distribuer chez les participants (leur nécessité varie avec les projets). ―4 catégories: analystes, développeurs, testeurs, gestionnaires. Activité ―Tâche simple, définissable et réutilisable qui peut être affectée à un rôle.

7 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus7 Vocabulaire RUP Discipline ―Agrégat d'activités produisant un ensemble déterminé d'artefacts. ―9 disciplines dans RUP: ingénierie (modélisation de l’entreprise, exigences, analyse & conception, implémentation, déploiement, test), et support (gestion de projet, gestion du changement et des configurations, environnement). ―Des lignes directrices pour chaque discipline sont offertes sous forme de flux de travaux.

8 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus8 Aperçu des phases de RUP

9 «SEG 3501» D. Amyot uOttawa Disciplines, phases et itérations Identify most of the use cases to define scope, detail critical use cases (10%) Detail the use cases (80% of the requirements) Identify and detail remaining use cases Track and capture requirements changes 9

10 «SEG 3501» D. Amyot uOttawa Discipline: Modélisation de l’entreprise Objectifs ―Comprendre la structure et la dynamique de l’entreprise où sera déployée l’application ―Comprendre les problèmes de l’organisation ciblée et identifier des améliorations potentielles ―S’assurer que les clients, utilisateurs et développeurs ont une compréhension commune de l’organisation Explique comment décrire une vision de l’organisation où sera déployé le système et comment utiliser cette vision comme base pour tirer les grandes lignes du processus, des rôles, et des responsabilités. Module 6 : IE et processus10

11 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus11 Modélisation de l’entreprise: artefacts

12 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus12 Modélisation de l’entreprise: rôles et activités

13 «SEG 3501» D. Amyot uOttawa Discipline: Exigences Établit et maintient l’entente avec les clients et autres parties prenantes sur ce que le système doit accomplir. Offre aux développeurs une compréhension accrue des exigences du système Définit les limites du système Offre une base de planification du contenu technique des itérations Offre une base d’estimation des coûts et du temps de développement du système Module 6 : IE et processus13

14 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus14 Exigences: artefacts

15 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus15 Exigences: rôles et activités

16 «SEG 3501» D. Amyot uOttawa Exigences: tâches Lister les exigences potentielles Comprendre le contexte du système ―Modèle du domaine, glossaire… Documenter les exigences fonctionnelles ―Scénarios d’usage et interface utilisateur Documenter les exigences non- fonctionnelles ―Reliées aux cas d’usages, ou en général Valider les exigences Module 6 : IE et processus16

17 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus17 Mais attention! RUP n’est pas un processus! ―C’est un cadre permettant de définir votre processus. RUP est un ensemble de bonnes pratiques ―Règles pour faire de bons documents, de bons modèles, de bonnes conceptions… ―Voir page suivante Caractéristiques de RUP ―Itératif et orienté vers la gestion des risques ―Basé sur les cas d’utilisation ―Centré sur l’architecture (autres modèles) ―Avoir le bon processus (ni trop lourd, ni insuffisant)

18 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus18 RUP et ses « bonnes pratiques » Développer itérativement en considérant à chaque itération les 9 disciplines ―Possiblement à des degrés différents Gérer les exigences pour établir une compréhension client/projet ―Description des cas d'utilisations et autres exigences ―Processus et outil de gestion des exigences Utiliser une architecture orientée composants ―Pour favoriser la réutilisabilité, les tests individuels, et l'évolutivité Modéliser visuellement (avec UML) Vérifier continuellement la qualité ―Indicateurs, inspections, métriques… Gérer les changements ―Valeurs de base, rapports d'incident, requêtes de changement…

19 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus19 Normes et outils pour l’ingénierie des processus Eclipse Process Framework Project (EPF) ―http://www.eclipse.org/epf/http://www.eclipse.org/epf/ ―Cadre de développement évolutif pour créer des processus de développement de logiciels ―Rôles, tâches, styles de développement prédéfinis et extensibles ―Intégration d’outils ―Basé sur un méta-modèle inspiré de SPEM – OMG standard: Software & Systems Process Engineering Metamodel specification (SPEM), Version 2.0, avril 2008 – http://www.omg.org/spec/SPEM/2.0/ http://www.omg.org/spec/SPEM/2.0/

20 «SEG 3501» D. Amyot uOttawa Outils disponibles pour EPF EPF Composer (plug-in Eclipse gratuit)EPF Composer IBM Rational Method Composer ($$$)IBM Rational Method Composer Module 6 : IE et processus20

21 «SEG 3501» D. Amyot uOttawa Et l’agilité dans tout ça? Une définition de processus agile peut mener à un processus lourd… Une définition de processus riche peut mener à un processus agile… Pas nécessairement de contradiction entre RUP et l’Agilité! En fait, IBM a créé un processus agile à partir d’un sous-ensemble de RUP ―http://epf.eclipse.org/wikis/openup/http://epf.eclipse.org/wikis/openup/ ―http://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/OpenUP Module 6 : IE et processus21

22 «SEG 3501» D. Amyot uOttawa Dilbert et la programmation agile… Module 6 : IE et processus22

23 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus23 http://agilemanifesto.org

24 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus24 Valeurs des approches agiles (I) Individus et interactions vs. Processus et outils ―Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. ―Sans l’artisan, les meilleurs outils ne servent à rien. Logiciel qui fonctionne vs. Documentation exhaustive ―Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambigüité du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. ―Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. ―La documentation n'est qu'un support concret qui aide à produire le logiciel.

25 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus25 Valeurs des approches agiles (II) Collaboration avec le client vs. Négociation de contrat ―Si la négociation protège plus ou moins des risques financiers, elle peut provoquer l’échec des projets et engendrer d'interminables procès où tout le monde y perd au bout du compte. ―Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun : réussir le projet. Réponse au changement vs. Suivi d'un plan prédéfini ―Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant le projet. ―Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique précis et adaptatif.

26 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus26 Principes dérivés de ces valeurs (I) Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte. Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet. Bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. La méthode la plus efficace de transmettre l'information est une conversation face à face.

27 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus27 Principes dérivés de ces valeurs (II) Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. [Wikipedia]Wikipedia

28 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus28 Quelques approches agiles connues (Wikipedia)Wikipedia Extreme Programming (XP)Extreme Programming Scrum Lean software development Open Unified Process (OpenUP)Open Unified Process Adaptive Software Development (ASD)Adaptive Software Development Crystal Clear Dynamic Systems Development Method (DSDM)Dynamic Systems Development Method Feature Driven Development Kanban Microsoft Solutions Framework (MSF)Microsoft Solutions Framework Agile Data Agile Modeling Agile Unified Process (AUP)Agile Unified Process Essential Unified Process (EssUP)Essential Unified Process Microsoft Solutions Framework (MSF)Microsoft Solutions Framework Getting Real Velocity tracking

29 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus29 Quand les utiliser en général? Culture qui supporte la négociation et où règnent la confiance et la communication rapide Projets de moins de 10 personnes (compétentes) situées près les unes des autres. Bonnes pour exigences difficiles à prévoir ou qui changent beaucoup ―Et où le prototypage est requis Plus difficilement applicables à ―Grands projets (>20 développeurs) ―Équipes réparties ―Applications critiques (entreprise, vie humaines…) ―Cultures rigides/militaires « Command-and-control »

30 «SEG 3501» D. Amyot uOttawa Agilité… Float like a butterfly, Sting like a bee Muhammad Ali www.youtube.com/watch?v=HXzQqqn-rVc

31 «SEG 3501» D. Amyot uOttawa Est-ce que l’agilité fonctionne?

32 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus32 « Software is Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something. » KentBeckKentBeck, auteur de ExtremeProgrammingExplainedExtremeProgrammingExplained Listen – Test Design – Code – Test Test Design

33 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus33 Programmation extrême (XP) Méthode de développement logiciel (de K. Beck, W. Cunningham et R. Jeffries, ~2000) destinée aux projets de taille moyenne devant être livrés rapidement et se voulant flexible tout en gardant une qualité irréprochable. Une méthode extrême dans sa vision du projet: ―Toute tâche autre que la production du projet est superflue ―Combinaison originale de pratiques ―Documentation technique = code source commenté ―Les diagrammes UML deviennent une perte de temps !

34 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus34 13 pratiques de XP

35 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus35 Éléments du processus XP Rôles ―Clients (et testeur), développeur, patron Artefacts ―Métaphores ―Histoires d’utilisateurs (priorisées) ―Tâches, tests unitaires, tests fonctionnels, code Activités ―Écriture d’histoires ―Jeu de la planification ―Livraisons fréquentes ―Rencontres debout ―Écriture et exécution des tests ―Possession du code ―Normes de codage ―Remaniement du code (refactoring) ―Intégration continue ―Développement pilotés par les tests ―Semaines de 40 heures! ―Programmation par paires…

36 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus36 Les exigences dans XP Histoires d’utilisateurs (user stories) ―Courtes descriptions du comportement du système du point de vue de l ’utilisateur (et écrites par ce dernier) Conversation et cartes (simples, efficaces… et jetables!) Histoires écrites par le client, pas le développeur Valeur fournie par le client Les développeurs estiment l’effort (en personnes-semaines) et le risque (haut, bas, moyen). Permettent de budgéter le temps nécessaire à l’implémentation (jeu de la planification). ~50-100 histoires pour quelques mois. Le client choisit suffisamment d’histoires pour remplir les itérations.

37 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus37 Histoires d’utilisateurs…

38 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus38 Le cycle de vie en XP, et fréquences XP  Cycles courts durant lesquels les quatre phases se déroulent en parallèle. XP  Système fonctionnel à la fin de chaque cycle. Quelques histoires par itération courtes, avec rétroaction du client

39 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus39 Architecture, “spike”, et métaphores Besoin d’une compréhension mutuelle de l’architecture XP ne fait pas de BigDesignUpFrontBigDesignUpFront ―Pas de phase d’architecture Spike architectural ―On exécute le code pour clarifier l’architecture ―Le résultat peut produire une métaphore – L’ordinateur est comme un bureau – La sélection des items se fait comme avec un panier d’épicerie ―Si la métaphore est bien choisie, elle mène à des approches de conception, des noms de classes, une meilleure communication…

40 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus40 Programmation par paires en XP (I) Les paires changent continuellement ―Quelques fois par jour! ―Tous les programmeurs connaissent tous les aspects du système ―Un programmeur peut facilement être remplacé au milieu du projet…

41 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus41 Programmation par paires en XP (II) Coût peut être plus élevé de 10—15% comparé à un seul programmeur Code est plus simple (moins de LOC) et avec moins de défectuosités (15%) Assure une inspection du code continuelle

42 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus42 Processus XP - Aperçu

43 «SEG 3501» D. Amyot uOttawa Processus XP - Itération Module 6 : IE et processus43

44 «SEG 3501» D. Amyot uOttawa Processus XP – Développement Module 6 : IE et processus44

45 «SEG 3501» D. Amyot uOttawa Processus XP - Possession collective du code Module 6 : IE et processus45

46 «SEG 3501» D. Amyot uOttawa Les pratiques agiles ont-elles des bénéfices et passent-elles à l’échelle? Module 6 : IE et processus46 C.T. Schmidt, S. Gv and J. Heymann: Empirical Insights into the Perceived Benefits of Agile Software Engineering Practices: A Case Study from SAP. ICSE 2014, IEEE CS.Empirical Insights into the Perceived Benefits of Agile Software Engineering Practices: A Case Study from SAP ―SAP a formé 4000 développeurs sur les pratiques agiles ―Sondage de 190 personnes, dans 74 équipes, sur 5 pays Focus sur SCRUM (groupes de ~10 personnes), la programmation par paire, et le développement par tests Ces pratiques mènent effectivement à un logiciel de meilleure qualité, sans même demander plus de temps! De plus, les « high adopters » sont plus fiers de leurs contributions, ont un meilleur apprentissage d’équipe, et se sentent plus motivés et moins stressés « Pair programming develops code and people »

47 «SEG 3501» D. Amyot uOttawa Résultats de cette étude Module 6 : IE et processus47 High adopters: >74% of their development time in pairs, >75% code coverage Low adopters: <16% of their development time in pairs, <33% code coverage

48 «SEG 3501» D. Amyot uOttawa Approche de développement “Lean” Module 6 : IE et processus48 Approche agile, adaptée du système de production de Toyota Plusieurs principes ―Éliminer les déchets (ce qui ne génère pas de valeur) – Par exemple, du code ou des documents inutiles, de mauvaises exigences, des répétitions évitables, la bureaucratie... ―Optimiser/Voir l'ensemble (pas seulement les parties, et pas seulement le logiciel) ―Qualité/Intégrité par construction (fonctionne tel que prévu, les défauts sont détectés tôt) ―Apprentissage constant (via la rétroaction des clients et de l'équipe) ―Livrer rapidement (et régulièrement) ―Respecter les gens (et leur donner du pouvoir) ―Reporter les décisions (décider le plus tard possible, afin de rassembler les connaissances nécessaires) ―S’améliorer en permanence (et vous mesurer vous-mêmes!) La plupart sont liés à des principes de l’I.E. aussi!

49 «SEG 3501» D. Amyot uOttawa Scrum Scrum est un cadre de développement de gestion de projets (pour processus agiles) qui est itératif et incrémental http://en.wikipedia.org/wiki/Scrum_(development) http://en.wikipedia.org/wiki/Scrum_(development) Scrum offre un gabarit de processus qui contient des pratiques et des rôles prédéfinis: ―Facilitateur/ScrumMaster: s’occupe du processus (~ gestionnaire) ―Directeur de produit: représentant des clients et utilisateurs ―Équipe: fait l’analyse, la conception, l’implémentation, les tests… Module 6 : IE et processus49

50 «SEG 3501» D. Amyot uOttawa Responsable de: ―Backlog de produit ―Clarification des items du backlog ―Analyse des intervenants ―Retour sur investissement (valeur) ―Priorisation du backlog ―Inspection des incréments du produit Capacités ―Gestion de projet ―Communication ―Connaissance du domaine ―Ingénierie des exigences M. & Mme. Incroyable! [Susanne Muehlbauer, HOOD Group, RE 2011] Module 6 : IE et processus50 Directeur de produit (Scrum Product Owner)

51 «SEG 3501» D. Amyot uOttawa Principes de l’I.E. en Scrum Estimations, vélocité et “Time boxing” ―Réduction du travail à faire à un sprint (2-4 semaines) Communication face-à-face Décisions reportées ―Développer les exigences de façon évolutive, aussi tardivement que possible Aimer le changement! Module 6 : IE et processus51

52 «SEG 3501» D. Amyot uOttawa Où retrouve-t-on l’I.E. dans Scrum? Vision du produit, exigences d’affaires ou utilisateurs ―Dans le backlog du produit Exigences du système/d’implémentation ―Dans le backlog du sprint Réduire le risque, emphase sur la valeur (et tôt)! Module 6 : IE et processus52

53 «SEG 3501» D. Amyot uOttawa Scrum et les exigences non-fonctionnelles Les histoires d’utilisation sont souvent fonctionnelles. Où sont les: ―Règles d’affaires? ―Qualités? ―Critères de satisfaction mesurables? ―Justifications? Et leur gestion? Encore besoin de buts, de modèles orientés- buts, et d’exigences non-fonctionnelles (ENF) ―Quelques ENF sont au niveau du système entier, et non seulement pour une histoire en particulier ―Quelques ENF peuvent être conflictuelles… Module 6 : IE et processus53

54 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus54 Comparaison (exigences) Exigences RUP ―Cas d’utilisation ―Documents d’exigences (incluant les exigences non- fonctionnelles) Exigences XP ―Histoires sur cartes ―Forte participation du client, sur place Risques pour RUP ―Gestion de projet basée sur les scénarios d’usage (Ambler) Risques pour XP: ―Difficile d’avoir un client qui ait une vue complète de l’entreprise et qui soit en mesure de formuler histoires et tests… ―Exigences non-fonctionnelles non couvertes? ―Traçabilité absente?

55 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus55 Comparaison (risques) Risques importants ―mauvaises exigences, exigences changeantes, échéances et coûts Gestion du risque RUP ―Itérations, architecture pour risques connus, priorisation des cas d’utilisation Gestion du risque XP ―Itérations (courtes), simplicité extrême, histoires sélectionnées par le client, estimations faites par le développeur – Les histoires difficiles à estimer sont risquées

56 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus56 Autres différences Risque: les dernières itérations peuvent nécessiter des conceptions plus sophistiquées que les premières ―RUP: (prédictif) la phase d’élaboration devrait considérer tous les cas d’utilisation et sélectionner ceux qui sont risqués ―XP: (adaptatif) garder la conception simple, et remanier lorsque nécessaire (extreme refactoring) Risque: les développeurs actuels quittent et de nouveaux développeurs arrivent ―RUP: Documente l’architecture et les scénarios clés ―XP: Utilisation de la programmation par pairs pour enseigner aux nouveaux développeurs et pour s’assurer que le savoir du système est bien réparti.

57 «SEG 3501» D. Amyot uOttawa À regarder et à lire… Agile Requirements Management - When User Stories Are Not Enough ―https://www.youtube.com/watch?v=vHNr- amZDsUhttps://www.youtube.com/watch?v=vHNr- amZDsU International Requirements Engineering Board (2014): Requirements Engineering and Agile Development: collaborative, just enough, just in time, sustainable.Requirements Engineering and Agile Development: collaborative, just enough, just in time, sustainable. Module 6 : IE et processus57

58 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus58 Améliorations suggérées pour XP eXtreme Requirements ( Leite ) ―http://www-di.inf.puc-rio.br/~julio/Slct-pub/XR.pdfhttp://www-di.inf.puc-rio.br/~julio/Slct-pub/XR.pdf eXtreme Requirements amélioré ( Leite et Leonardi ) ―http://www.mm.di.uoa.gr/~rouvas/ssi/caise2002/23480420.pdfhttp://www.mm.di.uoa.gr/~rouvas/ssi/caise2002/23480420.pdf XP modifié ( Nawrocki et al.) ―http://www.cs.put.poznan.pl/jnawrocki/publica/re02-essen.dochttp://www.cs.put.poznan.pl/jnawrocki/publica/re02-essen.doc EasyWinWin ( Grünbacher et Hofer ) ―http://cf.agilealliance.org/articles/system/article/file/909/file.pdfhttp://cf.agilealliance.org/articles/system/article/file/909/file.pdf …

59 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus59 Exemples de changements à XP eXtreme Requirements (XR) ―Notion de scénario et de processus ―Exigences non-fonctionnelles (contraintes) ―Traçabilité (lexique) ―Dérivation de situations à partir d’un scénario ―Formalisation de l’écriture des scénarios XR amélioré: ―Concept de règle d’affaires ―Entrevues, ateliers XP modifié: ―Documentation écrite pour les exigences. ―Plusieurs représentants du client. ―Phase d’ingénierie des exigences.

60 «SEG 3501» D. Amyot uOttawa Et les normes? ISO/IEC/IEEE 29148:2011 Ingénierie des systèmes et du logiciel — Processus du cycle de vie — Ingénierie des exigences CENELEC, Règlement Intérieur Partie 3: Règles de structure et de rédaction des publications CEN/CENELEC (Directives ISO/CEI – Partie 2, modifiée), 2009-08 ―Voir aussi http://www.iec.ch/members_experts/refdocs/iec/isoiec- dir2%7Bed6.0%7Den.pdf pour la version 2011 en anglais http://www.iec.ch/members_experts/refdocs/iec/isoiec- dir2%7Bed6.0%7Den.pdf Module 6 : IE et processus60

61 «SEG 3501» D. Amyot uOttawa Effort récent: SEMAT (semat.org) Software Engineering Method and Theory ―Mené par I. Jacobson et autres. Le génie logiciel est «gravement entravé aujourd'hui par des pratiques immatures ». On retrouve ces problèmes spécifiques : ―La prévalence de manies plus typiques de l'industrie de la mode que d'une discipline d'ingénierie. ―L'absence d'une base théorique solide et largement acceptée. ―Un grand nombre de méthodes et de variantes, avec des différences peu comprises et artificiellement grossies. ―L'absence d'évaluation expérimentale crédible et de validation. ―L’écart entre les pratiques de l'industrie et la recherche académique. Module 6 : IE et processus61

62 «SEG 3501» D. Amyot uOttawa SEMAT «Nous soutenons un processus visant à renouveler le génie logiciel selon une théorie solide, des principes éprouvés et de meilleures pratiques qui: ―Incluent un noyau d'éléments largement reconnus, extensible pour des utilisations spécifiques ―Traitent à la fois des préoccupations technologiques et humaines ―Sont appuyés par l'industrie, les universités, les chercheurs et les utilisateurs ―Supportent des extensions face à l'évolution des besoins et de la technologie ». Module 6 : IE et processus62

63 «SEG 3501» D. Amyot uOttawa SEMAT: Ressources Ivar Jacobson, Ian Spence and Pan-Wei Ng: Agile and SEMAT — Perfect Partners. CACM, Vol. 56, No. 11, pages 53-59, Nov. 2013 (disponible ici).ici Vers une norme de l’OMG: http://www.omg.org/spec/Essence/1.0/Beta2/ Ivar Jacobson: The Essence of Software Engineering: the SEMAT Approach. Google Zürich Tech Talk, July 17, 2014 https://www.youtube.com/watch?v=WNlERrVxYjs https://www.youtube.com/watch?v=WNlERrVxYjs Module 6 : IE et processus63

64 «SEG 3501» D. Amyot uOttawa SEMAT: Processus et statuts Module 6 : IE et processus64

65 «SEG 3501» D. Amyot uOttawa SEMAT “Essence” et exigences Module 6 : IE et processus65

66 «SEG 3501» D. Amyot uOttawa SEMAT: Statuts des exigences Module 6 : IE et processus66

67 «SEG 3501» D. Amyot uOttawa SEMAT: Statuts d’exigences individuelles Module 6 : IE et processus67

68 «SEG 3501» D. Amyot uOttawa SEMAT: Liste d’inspection pour exigences Module 6 : IE et processus68

69 «SEG 3501» D. Amyot uOttawa Observations sur SEMAT SEMAT partage plusieurs objectifs de RUP et EPF dans sa forme ―Cadre pour rôles, activités, et artefacts ―Promeut les pratiques réutilisables … Tout en reconnaissant les bonne pratiques observées chez les processus agiles … Et en reconnaissant le besoin de surveiller les statuts de plusieurs choses ―Pour mesurer progrès et santé des projets Mais, le succès de cette approche reste encore à voir! Module 6 : IE et processus69

70 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus70 Conclusion Après avoir vu un processus lourd (à la RUP) et un léger (à la XP), la décision n’est toujours pas binaire… et est-ce la bonne question à poser? Dans votre contexte, pour le projet où vous êtes impliqué(e): ―Quels sont vos besoins? ―Quels sont les artefacts (documents, modèles, …) appropriés? Les tâches et rôles nécessaires? ―Quels sont les outils appropriés? ―Quels sont les éléments de processus adéquats et comment les assembler? Vous devriez maintenant être en mesure de pouvoir prendre des décisions plus éclairées! ―Apprenez à personnaliser vos processus!

71 «SEG 3501» D. Amyot uOttawa Exercice Qu’utiliseriez-vous comme éléments de processus d’ingénierie d’exigence: ―Dans un projet de fin d’études sur une application Web à 5 personnes, 1 client, et d’une durée de 8 mois à temps partiel? ―Dans un projet open source, petit (p.ex., jUCMNav) ou grand (p.ex. Apache)? ―Dans un jeu vidéo complexe (Call of Duty 15)? Module 6 : IE et processus71

72 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus72 Dernière pensée sur l’ingénierie des exigences…

73 «SEG 3501» D. Amyot uOttawa Module 6 : IE et processus73 Références http://www.dilbert.com/ http://www- 306.ibm.com/software/awdtools/rup/http://www- 306.ibm.com/software/awdtools/rup/ http://www.agilemanifesto.org/ http://www.xprogramming.com/ http://www.extremeprogramming.org/ http://semat.org