Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Recueil et spécification, démarches itératives et agiles Analyse des besoins po

Recueil et spécification, démarches itératives et agiles Analyse des besoins pour le développement logiciel Jacques Lonchamp Professeur des universités © Dunod, 2015 5 rue Laromiguière, 75005 Paris www.dunod.com ISBN 978-2-10-072 4- Illustration de couverture : Grey abstract communication © iStock.com/nnnnae Toutes les marques citées dans cet ouvrage sont des marques déposées par leurs propriétaires respectifs. 99 4 Table des matières AVANT-PROPOS VIII CHAPITRE 1 • INTRODUCTION 1.1 Le logiciel 1 1.2 Le développement logiciel 3 1.3 La qualité du logiciel 4 1.4 La « crise du logiciel » 5 1.5 La maturité des organisations 8 PARTIE 1 LE DÉVELOPPEMENT LOGICIEL CHAPITRE 2 • LES ACTIVITÉS DU DÉVELOPPEMENT 2.1 Le recueil des besoins 18 2.2 L ’analyse et la spéciﬁcation des besoins 22 2.3 La conception architecturale et détaillée 26 2.4 L ’implantation 28 2.5 Le déploiement 28 2.6 La maintenance 29 2.7 La vériﬁcation et la validation (V&V) 30 2.8 La documentation 33 2.9 Les activités de gestion 33 2.10 La distribution efforts/erreurs/coûts 41 CHAPITRE 3 • LA MODÉLISATION – UML 3.1 La notion de modèle 45 3.2 La modélisation visuelle 47 3.3 Fonctions et objets 47 3.4 Le langage UML 49 3.5 Les principaux diagrammes UML 51 IV Table des matières CHAPITRE 4 • LES MODÈLES DE DÉVELOPPEMENT 4.1 Les modèles linéaires 57 4.2 Les modèles centrés sur des prototypes 60 4.3 Les modèles itératifs et incrémentaux 61 4.4 Les modèles agiles 63 4.5 Les autres modèles de développement 67 CHAPITRE 5 • (R)UP, XP ET SCRUM 5.1 (Rational) Uniﬁed Process – (R)UP 73 5.2 EXtreme Programming (XP) 79 5.3 Scrum 84 5.4 Le développement dirigé par les tests 92 5.5 Les outils du développement agile 97 PARTIE 2 LA MODÉLISATION MÉTIER CHAPITRE 6 • INTRODUCTION À LA MODÉLISATION MÉTIER 6.1 Déﬁnition 105 6.2 La modélisation métier avec UML 106 6.3 Une ébauche de démarche 109 CHAPITRE 7 • LA MODÉLISATION DES PROCESSUS MÉTIER 7.1 Les acteurs et intervenants métier 113 7.2 Les processus métier 114 7.3 Un exemple de processus métier 114 7.4 Les diagrammes UML associés 116 7.5 Vers les spéciﬁcations logicielles 121 CHAPITRE 8 • LA MODÉLISATION DU DOMAINE 8.1 Déﬁnition 125 8.2 Éléments du modèle du domaine 125 8.3 L ’identiﬁcation des classes du domaine 127 8.4 L ’identiﬁcation des associations du domaine 130 8.5 Un exemple 131 Table des matières V CHAPITRE 9 • LES SPÉCIFICATIONS FORMELLES AVEC OCL 9.1 Présentation du langage OCL 137 9.2 Caractéristiques du langage OCL 139 9.3 Syntaxe de base des contraintes OCL 140 9.4 Écriture d’expressions OCL complexes 142 9.5 Des conseils d’utilisation 146 PARTIE 3 LA MODÉLISATION DES BESOINS CHAPITRE 10 • LES USER STORIES 10.1 Déﬁnition 151 10.2 Des éléments de méthodologie 152 10.3 Un exemple 154 CHAPITRE 11 • LES CAS D’UTILISATION 11.1 Déﬁnition 159 11.2 La description textuelle du cas 160 11.3 Le diagramme de cas d’utilisation 161 11.4 Des éléments de méthodologie 163 11.5 User stories vs cas d’utilisation 164 11.6 Un exemple 165 CHAPITRE 12 • LES AUTRES MODÈLES UML 12.1 Les diagrammes de séquences « système » 169 12.2 Les diagrammes d’activités des cas 170 PARTIE 4 LA MODÉLISATION DE L’APPLICATION CHAPITRE 13 • LE MODÈLE DES CLASSES D’ANALYSE 13.1 Déﬁnition 177 13.2 Des éléments de méthodologie 178 13.3 Un exemple 179 CHAPITRE 14 • LES MODÈLES UML COMPLÉMENTAIRES 14.1 Les diagrammes de séquences 183 14.2 Les diagrammes d’états 183 VI Table des matières CHAPITRE 15 • LE MODÈLE DE NAVIGATION 15.1 Déﬁnition 187 15.2 Les composants du modèle de navigation 188 15.3 Un exemple 188 PARTIE 5 LES ÉTUDES DE CAS CHAPITRE 16 • ÉTUDE DE CAS 1 – LA PHASE D’INITIALISATION 16.1 Les acteurs 195 16.2 Les cas d’utilisation 196 16.3 Les exigences non fonctionnelles 198 16.4 Une ébauche d’architecture fonctionnelle 198 16.5 La prioritisation des cas 200 16.6 Une première ébauche du modèle de classes 201 16.7 Les maquettes des principaux écrans 203 CHAPITRE 17 • ÉTUDE DE CAS 1 – LA PHASE D’ÉLABORATION 17.1 La spéciﬁcation détaillée des cas 209 17.2 Les diagrammes de séquences système 212 17.3 Les diagrammes d’activités des cas 213 17.4 La structuration du diagramme des cas 213 17.5 Les modèles des classes d’analyse 214 17.6 La dynamique des classes d’analyse 215 17.7 Le prototypage 215 CHAPITRE 18 • ÉTUDE DE CAS 2 – LES USER STORIES 18.1 Le rappel des règles du jeu 217 18.2 L ’analyse du jeu 220 18.3 Le dévelopement du jeu 224 CHAPITRE 19 • ÉTUDE DE CAS 2 – LES CAS D’UTILISATION 19.1 Les cas d’utilisation du jeu 233 19.2 Le diagramme des cas d’utilisation 243 CHAPITRE 20 • ÉTUDE DE CAS 2 – LES CLASSES DU DOMAINE 20.1 L ’analyse textuelle 247 20.2 Le modèle des classes du domaine 248 Table des matières VII 20.3 L ’analyse des entités complexes du domaine 251 CONCLUSION 253 CORRIGÉS DES EXERCICES 255 BIBLIOGRAPHIE 301 INDEX 305 Avant-propos POURQUOI CET OUVRAGE ? Le présent ouvrage est l’aboutissement d’une longue pratique de l’enseignement du développement logiciel à divers publics universitaires et de formation continue. Plus précisément, ce sont les insatisfactions éprouvées à la lecture des documents pédagogiques existants, à l’occasion d’une réﬂexion nationale sur la formation des informaticiens, qui ont constitué l’élément déclencheur de sa rédaction. Sa première moitié est consacrée aux styles et processus de développement des applications informatiques. Sa seconde moitié détaille les techniques utilisables lors de toutes les activités en amont de la conception, qui vont du recueil des besoins à la spéciﬁcation de l’application. Dans la suite du volume, cet ensemble d’activités sera désigné par l’expression « analyse des besoins » ou, encore plus simplement, par le terme « analyse ». Cet ouvrage reprend les principes d’un premier volume paru dans la même collection et consacré de manière complémentaire à la conception des applications (Conception d’applications en Java/JEE. Principes, patterns et architectures. Jacques Lonchamp, Dunod, 2014). Les principes communs qui sous-tendent ces deux volumes sont résumés au paragraphe suivant. Alors qu’il est possible de parler de la conception de manière assez indépendante des styles et processus de développement logiciel, ce n’est pas du tout le cas pour l’analyse : on ne la pratique pas de la même manière dans un développement « agile », fondé sur l’adaptation continue aux évolutions des besoins grâce à un dialogue permanent avec le client et des itérations courtes, et dans un développement « classique », fondé sur le recueil initial exhaustif des besoins et la planiﬁcation rigide de toutes les activités de production. C’est ce qui justiﬁe le regroupement au sein d’un même volume de la description des styles et X Avant-propos processus de développement avant la présentation des connaissances théoriques et pratiques relatives à l’analyse. LA CONCEPTION DE L’OUVRAGE Le positionnement dans le cursus Un cursus de formation à l’informatique ressemble à une fusée à trois étages. L’étage disciplinaire vise l’acquisition des savoirs conceptuels et techniques de base, grâce à des enseignements ciblés vers des domaines bien délimités. L’étage intégratif doit permettre de tisser des liens entre les savoirs disciplinaires, de les approfondir en conséquence, et de prendre conscience des enjeux réels dans le monde professionnel. L’étage professionnalisant, qui s’appuie sur la compréhension globale des grandes thématiques que procure l’étage précédent, vise l’approfondissement de thèmes techniques spécialisés permettant de passer de la compréhension à la maîtrise effective de certaines facettes du métier. Les deux ouvrages proposés, sur la conception d’une part et sur les processus et l’analyse d’autre part, relèvent clairement de la phase « intégrative », pour laquelle le manque de documents pédagogiques est criant. Une progression logique des apprentissages Dans le volume sur la conception, les savoirs en conception ont été ancrés dans les connaissances préalables en programmation. En effet, tout programmeur Java utilise au sein du JDK, sans en être nécessairement conscient, les patrons (patterns) de conception les plus connus et les plus utiles. Leur compréhension et leur mémorisation se trouvent grandement facilités quand cet ancrage est rendu explicite. Dans ce second volume consacré aux concepts et méthodes de l’analyse, l’importance de la connaissance préalable des styles et processus de développement a déjà été évoquée. Par ailleurs, beaucoup de concepts de l’analyse prennent du sens à travers la compréhension de ce que peut être une conception et une réalisation de qualité, comme la modélisation de l’application en termes de classes frontières, de classes de contrôle et de classes entité. Une progression logique des apprentissages en développement des applications peut donc se schématiser par : programmation − →conception − →styles et processus de développement − →analyse. Pour une « culture générale » de l’analyse Le côté très parcellaire de beaucoup de documents existants est aux antipodes de ce qu’on peut attendre pour la phase « intégrative » du cursus : l’analyse ne se réduit pas aux seuls besoins fonctionnels, la modélisation au seul langage UML et les processus aux seules approches agiles. Avant-propos XI Sans tomber dans le travers encyclopédique des énormes « bibles » du génie logiciel (comme [Pre09] ou [Som04]), cet ouvrage cherche à donner une présentation synthétique large des thèmes abordés, une forme de « uploads/Management/ analyse-des-besoins-pour-le-developpement-logiciel-2.pdf