SEG 3501 Module 6 Intgration de lingnierie des

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

Dilbert et les processus… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 2

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 Stars” «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 3

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: «SEG 3 501» D. Am u. Otta yot wa ― artefacts, rôles, disciplines et activités ― processus piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental Module 6 : IE et processus 4

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/ «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 5

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. «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 6

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. «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 7

Aperçu des phases de RUP «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 8

Disciplines, phases et itérations Identify most of Detail the use cases Identify and detail Track and capture the (80% of the remaining use cases requirements use cases to requirements) changes define scope, detail critical use cases (10%) «SEG 3 501» D. Am u. Otta yot wa 9

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 «SEG 3 501» D. Am u. Otta • 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. yot wa Module 6 : IE et processus 10

Modélisation de l’entreprise: artefacts «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 11

Modélisation de l’entreprise: rôles et activités «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 12

Discipline: Exigences «SEG 3 501» D. Am u. Otta • É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 yot wa Module 6 : IE et processus 13

Exigences: artefacts «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 14

Exigences: rôles et activités «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 15

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 nonfonctionnelles ― Reliées aux cas d’usages, ou en général • Valider les exigences «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 16

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) «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 17

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 «SEG 3 501» ― Valeurs de base, rapports d'incident, requêtes de changement… D. Am u. Otta yot wa Module 6 : IE et processus 18

Normes et outils pour l’ingénierie des processus • Eclipse Process Framework Project (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 «SEG 3 501» D. Am u. Otta yot wa – OMG standard: Software & Systems Process Engineering Metamodel specification (SPEM), Version 2. 0, avril 2008 – http: //www. omg. org/spec/SPEM/2. 0/ Module 6 : IE et processus 19

Outils disponibles pour EPF • EPF Composer (plug-in Eclipse gratuit) • IBM Rational Method Composer ($$$) «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 20

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 «SEG 3 501» ― http: //epf. eclipse. org/wikis/openup/ ― http: //en. wikipedia. org/wiki/Open. UP D. Am u. Otta yot wa Module 6 : IE et processus 21

Dilbert et la programmation agile… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 22

http: //agilemanifesto. org «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 23

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 «SEG 3 501» D. Am u. Otta yot wa ― 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. Module 6 : IE et processus 24

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 «SEG 3 501» ― 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. D. Am u. Otta yot wa Module 6 : IE et processus 25

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. «SEG 3 501» • La méthode la plus efficace de transmettre l'information est une conversation face à face. D. Am u. Otta yot wa Module 6 : IE et processus 26

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. «SEG 3 [Wikipedia] 501» D. Am u. Otta yot wa Module 6 : IE et processus 27

Quelques approches agiles connues (Wikipedia) «SEG 3 501» D. Am u. Otta yot wa • • • • • Extreme Programming (XP) Scrum Lean software development Open Unified Process (Open. UP) Adaptive Software Development (ASD) Crystal Clear Dynamic Systems Development Method (DSDM) Feature Driven Development Kanban Microsoft Solutions Framework (MSF) Agile Data Agile Modeling Agile Unified Process (AUP) Essential Unified Process (Ess. UP) Microsoft Solutions Framework (MSF) Getting Real Velocity tracking Module 6 : IE et processus 28

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 à «SEG 3 501» ― ― Grands projets (>20 développeurs) Équipes réparties Applications critiques (entreprise, vie humaines…) Cultures rigides/militaires « Command-control » D. Am u. Otta yot wa Module 6 : IE et processus 29

Agilité… Float like a butterfly, Sting like a bee Muhammad Ali «SEG 3 501» D. Am u. Otta yot wa www. youtube. com/watch? v=HXz. Qqqn-r. Vc

Est-ce que l’agilité fonctionne? «SEG 3 501» D. Am u. Otta yot wa

« Software is Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something. » Kent. Beck, auteur de Extreme. Programming. Explained Listen –Test Design – Code – Test Design «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 32

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: «SEG 3 501» ― 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 ! D. Am u. Otta yot wa Module 6 : IE et processus 33

13 pratiques de XP «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 34

É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 «SEG 3 501» D. Am u. Otta yot wa ― ― ― É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… Module 6 : IE et processus 35

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 «SEG 3 501» D. Am u. Otta • 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. yot wa Module 6 : IE et processus 36

Histoires d’utilisateurs… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 37

Le cycle de vie en XP, et fréquences «SEG 3 501» D. Am u. Otta yot wa 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 Module 6 : IE et processus 38

Architecture, “spike”, et métaphores • Besoin d’une compréhension mutuelle de l’architecture • XP ne fait pas de Big. Design. Up. Front ― Pas de phase d’architecture • Spike architectural «SEG 3 501» ― 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… D. Am u. Otta yot wa Module 6 : IE et processus 39

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… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 40

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 «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 41

Processus XP - Aperçu «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 42

Processus XP - Itération «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 43

Processus XP – Développement «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 44

Processus XP - Possession collective du code «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 45

Les pratiques agiles ont-elles des bénéfices et passent-elles à l’échelle? • 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. ― SAP a formé 4000 développeurs sur les pratiques agiles ― Sondage de 190 personnes, dans 74 équipes, sur 5 pays «SEG 3 501» • 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 » D. Am u. Otta yot wa Module 6 : IE et processus 46

Résultats de cette étude «SEG 3 501» D. Am u. Otta yot wa High adopters: >74% of their development time in pairs, >75% code coverage Low adopters: <16% of their development time in pairs, <33% code coverage Module 6 : IE et processus 47

Approche de développement “Lean” • 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!) «SEG 3 501» • La plupart sont liés à des principes de l’I. E. aussi! D. Am u. Otta yot wa Module 6 : IE et processus 48

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) • Scrum offre un gabarit de processus qui contient des pratiques et des rôles prédéfinis: ― Facilitateur/Scrum. Master: 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… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 49

Directeur de produit (Scrum Product Owner) • 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 ― ― Gestion de projet Communication Connaissance du domaine Ingénierie des exigences • Capacités «SEG 3 501» D. Am u. Otta yot wa • M. & Mme. Incroyable! [Susanne Muehlbauer, HOOD Group , RE 2011] Module 6 : IE et processus 50

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! «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 51

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)! «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 52

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ésbuts, et d’exigences non-fonctionnelles (ENF) «SEG 3 501» ― Quelques ENF sont au niveau du système entier, et non seulement pour une histoire en particulier ― Quelques ENF peuvent être conflictuelles… D. Am u. Otta yot wa Module 6 : IE et processus 53

Comparaison (exigences) • Exigences RUP ― Cas d’utilisation ― Documents d’exigences (incluant les exigences nonfonctionnelles) • 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: «SEG 3 501» ― 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? D. Am u. Otta yot wa Module 6 : IE et processus 54

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 «SEG 3 501» D. Am u. Otta – Les histoires difficiles à estimer sont risquées yot wa Module 6 : IE et processus 55

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 «SEG 3 501» ― 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. D. Am u. Otta yot wa Module 6 : IE et processus 56

À regarder et à lire… • Agile Requirements Management - When User Stories Are Not Enough ― https: //www. youtube. com/watch? v=v. HNram. ZDs. U • International Requirements Engineering Board (2014): Requirements Engineering and Agile Development: collaborative, just enough, just in time, sustainable. «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 57

Améliorations suggérées pour XP • e. Xtreme Requirements (Leite) ― http: //www-di. inf. puc-rio. br/~julio/Slct-pub/XR. pdf • e. Xtreme Requirements amélioré (Leite et Leonardi) ― http: //www. mm. di. uoa. gr/~rouvas/ssi/caise 2002/23480420. pdf • XP modifié (Nawrocki et al. ) ― http: //www. cs. put. poznan. pl/jnawrocki/publica/re 02 -essen. doc • Easy. Win (Grünbacher et Hofer) ― http: //cf. agilealliance. org/articles/system/article/file/909/file. pdf «SEG 3 501» • … D. Am u. Otta yot wa Module 6 : IE et processus 58

Exemples de changements à XP • e. Xtreme 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é: «SEG 3 501» ― Documentation écrite pour les exigences. ― Plusieurs représentants du client. ― Phase d’ingénierie des exigences. D. Am u. Otta yot wa Module 6 : IE et processus 59

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/isoiecdir 2%7 Bed 6. 0%7 Den. pdf pour la version 2011 en anglais «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 60

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. «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 61

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: «SEG 3 501» D. Am u. Otta ― 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 » . yot wa Module 6 : IE et processus 62

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). • Vers une norme de l’OMG: • http: //www. omg. org/spec/Essence/1. 0/Beta 2/ • Ivar Jacobson: The Essence of Software Engineering: the SEMAT Approach. Google Zürich Tech Talk, July 17, 2014 «SEG 3 501» https: //www. youtube. com/watch? v=WNl. ERr. Vx. Yjs D. Am u. Otta yot wa Module 6 : IE et processus 63

SEMAT: Processus et statuts «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 64

SEMAT “Essence” et exigences «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 65

SEMAT: Statuts des exigences «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 66

SEMAT: Statuts d’exigences individuelles «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 67

SEMAT: Liste d’inspection pour exigences «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 68

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 «SEG 3 501» D. Am u. Otta yot wa • Mais, le succès de cette approche reste encore à voir! Module 6 : IE et processus 69

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? «SEG 3 501» D. Am u. Otta yot wa • Vous devriez maintenant être en mesure de pouvoir prendre des décisions plus éclairées! ― Apprenez à personnaliser vos processus! Module 6 : IE et processus 70

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. , j. UCMNav) ou grand (p. ex. Apache)? ― Dans un jeu vidéo complexe (Call of Duty 15)? «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 71

Dernière pensée sur l’ingénierie des exigences… «SEG 3 501» D. Am u. Otta yot wa Module 6 : IE et processus 72

Références • http: //www. dilbert. com/ • http: //www 306. ibm. com/software/awdtools/rup/ «SEG 3 501» • http: //www. agilemanifesto. org/ • http: //www. xprogramming. com/ • http: //www. extremeprogramming. org/ • http: //semat. org D. Am u. Otta yot wa Module 6 : IE et processus 73