Remerciez-le!

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

Chapitre 5 (R)UP, XP et Scrum Ce chapitre détaille trois « méthodes » de dévelo

Chapitre 5 (R)UP, XP et Scrum Ce chapitre détaille trois « méthodes » de développement objet qui jouent un rôle majeur aujourd’hui : (Rational) Uniﬁed Process – (R)UP –, eXtreme Programming – XP – et Scrum. Le mot méthode est placé entre guillemets car ces approches n’ont pas tous les attributs d’une méthode complète. XP est plutôt un « cadre technique » et Scrum un « cadre organisationnel » pour le développement agile des applications. 5.1 (RATIONAL) UNIFIED PROCESS – (R)UP James Rumbaugh, Ivar Jacobson et Grady Booch, ont proposé un cadre général de processus itératif pour le développement orienté objet, Uniﬁed Process (UP) [JBR99], étroitement associé au langage UML dont ils sont également les principaux auteurs. La version de la société Rational, Rational Uniﬁed Process (RUP) en est la déclinaison la plus connue [Kru04]. Il en existe plusieurs autres, comme eXtreme UP (XUP), qui intègre XP et UP, Agile UP qui simpliﬁe UP dans une optique d’agilité ou 2TUP (Two Tracks UP) et son modèle en Y déjà discuté au paragraphe 4.1.3., qui peuvent satisfaire différents types de projet. (R)UP met en avant sept « bonnes pratiques » qui sont explicitées dans les paragraphes suivants : (1) le développement itératif et incrémental, (2) le développement guidé par les cas d’utilisation et centré sur l’architecture, (3) le pilotage par les risques, (4) la gestion des exigences, 74 Partie 1. Le développement logiciel (5) la maîtrise des modiﬁcations, (6) l’évaluation continue de la qualité, (7) la modélisation visuelle avec UML. 5.1.1. Le développement itératif et incrémental (R)UP déﬁnit un processus de développement relativement « générique », qui peut être adapté à des contextes particuliers. Dans l’approche (R)UP, le développement d’un logiciel passe par quatre phases, chacune pouvant donner lieu à une série d’itérations : lancement (inception), élaboration, construction et transition. Chaque phase se termine par un jalon d’évaluation et de prise de décision quant au passage à la phase suivante. Toute phase est concernée en proportions diverses par différentes « disciplines » du développement (activités) : modélisation métier, recueil et expression des besoins, analyse et conception de l’application, implantation, tests, déploiement et les activités transversales de gestion de conﬁguration et du changement, gestion de projet (personnes, budgets, contrats, planning), gestion de l’environnement de développement (outils, administration système/réseau/bases de données). Par exemple, lors de la phase de lancement, ce sont les disciplines de modélisation métier et de recueil et expression des besoins qui dominent en proportion. Lors de la phase de construction, ce sont les disciplines d’implantation, de test et de déploiement qui dominent (cf. ﬁgure 5.1). FIGURE 5.1 Phases, itérations et disciplines Les phases sont composées d’itérations. Une itération est une séquence d’activités qui répond à un plan et possède des critères d’évaluation. Une itération se termine par un jalon d’évaluation et de prise de décision. Toute itération peut être considérée comme un mini projet (qui parcourt une ou plusieurs fois le cycle recueil et expression des besoins, analyse, conception, implantation, tests) et qui produit un livrable (cf. ﬁgure 5.2). Le développement se concrétise donc par une série de livrables, par exemple des maquettes ou des prototypes dans les premières itérations et des versions exécutables du logiciel ﬁnal (releases) ultérieurement, comme dans l’exemple de la ﬁgure 5.3. 5 • (R)UP , XP et Scrum 75 FIGURE 5.2 Structure d’une itération FIGURE 5.3 Un exemple de suite de livrables ➤Le lancement Objectifs : C’est une phase très courte, avec souvent une seule itération. Elle explicite la « vision » associée au projet en termes de faisabilité, de risques et de périmètre du projet. Livrables : (tout ou partie de la liste suivante) – Un document de vision présentant les besoins de base, les contraintes et fonctionnalités principales. – Une description courte des principaux cas d’utilisation et une analyse plus poussée des 10 % de cas les plus critiques. – Un glossaire de projet. – Un document de justiﬁcation économique incluant le contexte général de réalisation, les facteurs de succès et la prévision ﬁnancière. – Une évaluation des risques. – Une première planiﬁcation du projet (phases et itérations). – Une maquette. 76 Partie 1. Le développement logiciel ➤L ’élaboration Objectifs : Cette phase comporte quelques itérations courtes et de durée ﬁxe, pilotées par les risques et centrée sur l’architecture. Elle comprend l’identiﬁcation et la stabilisation de la plupart des besoins, la spéciﬁcation de la plupart des cas d’utilisation, la conception de l’architecture de référence, du squelette du système à réaliser, la programmation et le test des éléments d’architecture les plus importants, la réalisation et le test des cas d’utilisation critiques (< 10 % des besoins) et une estimation ﬁable du calendrier et des coûts de construction de l’application. Livrables : – Au moins 80 % des cas d’utilisation sont élaborés à la ﬁn des itérations. – Les exigences et contraintes non fonctionnelles sont identiﬁées. – L’architecture est déﬁnie. – Une version du produit permettant de valider l’architecture du logiciel à travers les fonctionnalités les plus importantes. – Un planning de réalisation réaliste (phases, itérations, critères d’évaluation). ➤La construction Objectifs : C’est la phase la plus longue (plus de 50 % du cycle de développement). La construction se fait par incréments, avec une architecture stable malgré des changements mineurs. À chaque incrément, le produit doit contenir tout ce qui avait été planiﬁé. Par contre, il peut éventuellement rester quelques erreurs non encore traitées. Livrables : – Les versions exécutables du logiciel correspondant à l’enrichissement itération par itération des fonctionnalités. – Les manuels d’utilisation réalisés simultanément à la livraison incrémentale des exécutables. – Une description des versions produites. ➤La transition Objectifs : Le produit est livré (en version béta). Il y a correction du reliquat d’erreurs. Le produit est essayé et amélioré, les utilisateurs sont formés, l’assistance en ligne est élaborée. Livrables : – La version ﬁnale du logiciel. – Les manuels d’utilisation. – L’assistance en ligne. Une telle approche est très ﬂexible. Lors des premières itérations la gestion des risques est fondamentale. Il faut également construire et stabiliser le noyau architectural rapidement. Le feedback régulier des utilisateurs doit permettre une adaptation permanente du système aux besoins réels. Le feedback des développeurs et des testeurs doit permettre d’afﬁner la 5 • (R)UP , XP et Scrum 77 conception et les modèles et de mieux gérer la complexité. Des étapes courtes et pas trop complexes permettent d’éviter la « paralysie par l’analyse ». 5.1.2. Le guidage par les cas et le centrage sur l’architecture Les cas d’utilisation (use cases) décrivent les interactions entre les acteurs et le système. Ils permettent de réﬂéchir en termes d’acteurs et de buts plutôt que directement en termes de fonctionnalités. Il s’agit d’un bon véhicule, compréhensible par tous, pour recueillir et communiquer les besoins métier. C’est également un bon outil pour guider et garantir la cohérence de tout le processus de développement. FIGURE 5.4 Guidage par les cas Dans le cadre d’un développement itératif, chaque itération est centrée sur un sous-ensemble de cas. Il faut traiter en premier les cas d’utilisation « pertinents », c’est-à-dire les plus risqués (critiques), les plus importants pour le client ou les plus représentatifs du système. L’architecture décrit les aspects les plus signiﬁcatifs du système en termes de modèles, selon les 4+1 vues déﬁnies par UML [Kru95] : modèle fonctionnel (cas d’utilisation), modèles statiques (classes, objets, paquets), modèles dynamiques (processus, concurrence, performance), modèle d’implantation (composants logiciels), modèle de déploiement (composants logiciels et matériels). Elle est conçue et stabilisée lors des premières itérations en parallèle avec l’approfondissement des cas d’utilisation. 5.1.3. Les autres bonnes pratiques a) Le pilotage par les risques Un risque est un événement prévisible redouté, car il peut produire des dommages au projet. Ces risques peuvent être techniques, mais aussi liés au client, au domaine applicatif ou à l’organisation du projet. Le pilotage par les risques implique une analyse des risques potentiels le plus tôt possible, dès les premières itérations, et leur hiérarchisation. Cela conduit à travailler prioritairement 78 Partie 1. Le développement logiciel sur les éléments les plus exposés, comme l’architecture de l’application ou la gestion des ressources humaines. b) La gestion des exigences (R)UP recommande de se servir des cas d’utilisation UML pour exprimer les exigences fonctionnelles. (R)UP indique que les exigences doivent être organisées, enregistrées et tracées, si possible avec un outil. On retrouve ce qui est demandé au niveau de maturité 2 du CMMI en matière de gestion des exigences (cf. paragraphe 1.5). Par contre, on ne voit pas d’apport conséquent de (R)UP pour ce qui est demandé au niveau de maturité 3 dans le domaine du développement des exigences. c) La maîtrise des modiﬁcations La multiplication du nombre de versions, liée au nombre d’itérations et à l’évolution des besoins dans le temps, ainsi que la parallélisation des développements impliquent de gérer les modiﬁcations. Les demandes doivent être formalisées sous la forme d’une demande de changement (change request), d’une demande d’extension (feature request) ou d’un rapport d’anomalie (bug report), enregistrées, négociées, validées et tracées. Il faut en parallèle gérer les conﬁgurations du logiciel et les versions de ses composants, mais uploads/Ingenierie_Lourd/ chapitre-v-ingenierie-logiciel.pdf