Le Processus Rational Unified Process

Transcription

1 Le Processus Rational Unified Process Hafedh Mili Copyright 2004 Plan Qu est ce un cycle de vie? Quelques cycles de vie Le cycle de vie Rational Unified Process 1

2 Un cycle de vie Un cycle de vie est un modèle pour l organisation, la planification, et le contrôle des activités associées avec le développement et la maintenance de logiciels [Peters, 1998] Un cycle de vie est un outil de gestion. Il: 1) prescrit une division du travail, 2) identifie et standardise les livrables intermédiaires, et 3) il identifie et standardise des critères pour la revue et l évaluation de ces livrables Un cycle de vie dépend principalement sur, 1) la taille de l application, 2) les risques techniques associés, et 3) le contexte d affaires Les cycles de vie sont aussi influencés par la méthodologie de développement et la technologie d implantation Cycle de vie en cascade Ingénierie du système Analyse Conception Codage Test Maintenance 2

3 Le modèle en spirale [Boehm, 1987] Conçu pour les applications comportant d importants risques Conception Niveau décroissant de risques Implémentation Analyse Test Le modèle cluster Prévu pour le développement de composants réutilisables Réduit le temps de mise à marché, mais pas le coût! Système Analyse Conception Intégration Sous-systèmes Analyse Conception Intégration Fonctions Services Structures de données Implémentation Implémentation Implémentation time 3

4 Le modèle cluster Système Sous-système 1 Sous-système 2 Sous-système 3 Fn 1.1 Fn 1.2 Fn 2.1 Fn 2.2 Fn 3.1 Fn 3.2 Srv 1 Srv 2 Srv 3 Srv 4 DS 1 DS 2 DS 3 Le Rational Unified Process Le Rational Unified Process est: Itératif et incrémental: Tous les livrables sont produits en incréments, y compris le système lui-même On itère sur les différentes phases pour améliorer les livrables Piloté par les cas d utilisation: Les cas d utilisation représentent des segments cohésifs de fonctionnalité Les cas d utilisation représentent des unités de développement par rapport aux incréments Architecture centric : met l emphase sur la conception d une architecture stable qui servira de base pour la livraison des incréments de fonctionnalité 4

5 Le Rational Unified Process RUP consiste en quatre phases: Inception: la phase durant laquelle on définit la portée du produit, et on prouve l opportunité du projet (business case) Élaboration: choisir une architecture et dresser un plan de projet. L emphase est sur l analyse et la conception architecturale. Construction: l emphase est sur la conception détaillée et sur l implantation Transition: le déploiement du logiciel vers la communauté d usagers Le Rational Unified Process Durant les quatres phases, neuf tâches (process workflows ou disciplines) sont effectuées: Modélisation d affaires (business modeling) Élicitation des exigences (use cases) Analyse et conception Implémentation: codage, test unitaire, et intégration Test : cas de tests, procédures, defect-tracking Deploiement Gestion de configuration Gestion de projets Environnement: conception de l infrastructure nécessaire au développement 5

6 Le Rational Unified Process Tâches (process workflows) Inception Elaboration Construction Transition Business modeling Requirements Analysis & design Implementation Test Deployment Config Management Project management Environment Iterations Iter 1 Iter2 Iter3 It4 It5 It6 It7 It8 Les artéfacts et livrables RUP Deux types d artéfacts: gestion (plans de projets, cédules, etc.) et techniques Artéfacts techniques consistent principalement en des modèles: Modèle de l organisation Modèle du domaine (une abstraction du domaine d affaires) Modèle de cas d utilisation: ce sont les exigences fonctionnelles du système Modèle d analyse Modèle de conception Modèle de processus (optionnel:pour les systèmes concurrents) Modèle de deploiment: topologie du matériel et configuration Modèle d implémentation: composants utilisés pour assembler et livrer le système (physique) Modèle de test: décrit les cas de tests utilisés pour valider le système (par rapport aux exigences) et le vérifier (par rapport aux spécifications). 6

7 Les livrables RUP Quatre ensembles de livrables: Ensemble des exigences: ce que le système est supposé faire. Modèle du domaine, modèle de cas d utilisation, modèle d analyse, modèle d exigences non-fonctionnelles, et d autres artéfacts, don t les interfaces usagers, les contraintes règlementaires, etc. Ensemble de conception: comment le système va être construit. Modèles de conception, modèles de test, prototypes, architecture exécutable, etc. The RUP deliverables (2/2) Ensemble d implémentation: information sur les composants/éléments du logiciel. Code source, fichiers de configuration, fichiers de données, composants logiciels, scripts pour la compilation, le build, etc. Ensemble de déploiement: comment le logiciel est déployé. Scripts d installation pour le code et les données, configuration, logs, etc. 7

8 Développement vs. maintenance En principe, la maintenance peut être interprétée comme des incréments de développement: Comprendre la demande de maintenance (exigences usager) L analyser (spécifier les changes, analyser leur impact) Concevoir le changement (trouver comme réaliser le changement de comportement désiré) L implémenter Le tester (lui et ses effets de bord sur le système existant) Le déployert En pratique, les tâches de maintenance sont plus contraintes que le développement initial: Pas le choix de solution Backward compatibility versus migration Mise à jour live Les incréments Loi de Parkinson: Work expands so as to fill the time available for its completion Les incréments doivent être courts: Moins de temps perdu au début de chaque incrément (la date de livraison est à l horizon) Force une priorisation et des prises de décision Sentiment d accomplissement Mise en confiance des usagers/clients Deux à six semaines Pas plus de six mois pour les projets gagantuesques Si débordement, réduire la livraison plutôt que reculer l échéance 8

9 Autres bonnes pratiques Développer le test, et après le programme Extreme programming Junit Réunion de 15 minutes par jour ( 15-minute stand-up SCRUM meeting): Accomplissments depuis la veille Obstacles rencontrés Informations intéressantes à partager Intégration continue Faire des builds réguliers (e.g. toutes les 24 heures), voire même continus. 9