Upload
joel-doucet
View
112
Download
0
Embed Size (px)
Citation preview
Le Développement itératif
Développement itératif, évolutif et agile
Le développement itératif est au cœur des meilleures pratiques de l’A/COO.
Contrairement au cycle de vie séquentiel « en cascade », le développement itératif et évolutif implique de programmer et de tester précocement un système partiel selon des cycles répétitifs.
Développement itératif, évolutif et agile Le développement itératif suppose que
le développement commence avant que tous les besoins n’aient été définis en détail : c’est le feed-back qui permettra de clarifier, d’améliorer et de faire évoluer les spécifications.
Il s’appuie sur des étapes de développement courtes et rapides, le feed-back et l’adaptation pour préciser et affiner la conception.
Développement itératif, évolutif et agile
En revanche, l’approche en cascade favorisait une réflexion exhaustive sur les besoins et la conception, préliminaire à tout codage.
Des études ont montré un fort taux d’échecs des projets ayant suivi cette méthode.
Développement itératif, évolutif et agile
Le développement itératif de base sur des itérations de courtes durées : De 1 semaine à 4 semaines
Chaque itération donne lieu à un livrable, souvent une ébauche de l’application qui se complète au fil des itérations.
Développement itératif, évolutif et agile : Historique A la fin des années 50, une approche itérative et incrémentale
fut préférée à la méthode en cascade dans le projet spatial Mercury.
Au début des années 60, dans le projet du sous-marin Trident ainsi que pour de nombreux grands systèmes.
Le premier article prônant la supériorité du développement itératif sur l’approche en cascade fut publié en 1968 au centre de recherche T.J. Watson d’IBM.
Dans les années 70, des méthodes itératives furent utilisées dans de nombreux projets touchant la défense et l’industrie aérospatiale, notamment aux Etats-Unis pour le logiciel de contrôle de la navette spatiale (construit en 17 itérations durant en moyenne 4 semaines).
Au début des années 90, l’approche itérative était largement reconnue comme le successeur de l’approche en cascade, et on assista à une floraison de méthodes itératives et évolutives, dont le Processus Unifié, Scrum, XP et de nombreuses autres.
Le Processus Unifié (UP)
Introduction Le processus unifié est un processus de
développement logiciel itératif, centré sur l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques.
C'est un patron de processus pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d'application, à différents types d'entreprises, à différents niveaux de compétences et à différentes tailles de l'entreprise.
UP est itératif L'itération est une répétition d'une
séquence d'instructions ou d'une partie de programme un nombre de fois fixé à l'avance ou tant qu'une condition définie n'est pas remplie, dans le but de reprendre un traitement sur des données différentes.
Elle qualifie un traitement ou une procédure qui exécute un groupe d'opérations de façon répétitive jusqu'à ce qu'une condition bien définie soit remplie
UP est itératif
Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité les risques majeurs.
UP est centré sur l'architecture Kruchten propose différentes perspectives,
indépendantes et complémentaires, qui permettent de définir un modèle d'architecture (publication IEEE, 1995).
Vueutilisateur
Vuelogique
Vuecomportement
Vuedéploiement
Vueimplémentation
UP est piloté par les cas d'utilisation d'UML Le but principal d'un système
informatique est de satisfaire les besoins du client.
Le processus de développement sera donc accès sur l'utilisateur.
Les cas d'utilisation permettent d'illustrer ces besoins.
Ils détectent puis décrivent les besoins fonctionnels (du point de vue de l'utilisateur), et leur ensemble constitue le modèle de cas d'utilisation qui dicte les fonctionnalités complètes du système.
Vie du processus unifié L'objectif d'un processus unifié est de
maîtriser la complexité des projets informatiques en diminuant les risques.
UP est un ensemble de principes génériques adapté en fonctions des spécificités des projets. UP répond aux préoccupations suivantes : QUI participe au projet ? QUOI, qu'est-ce qui est produit durant le
projet ? COMMENT doit-il être réalisé ? QUAND est réalisé chaque livrable ?
Vie du processus unifié UP gère le processus de développement
par deux axes : L'axe vertical représente les principaux
enchaînements d'activités, qui regroupent les activités selon leur nature.
L'axe horizontal représente le temps et montre le déroulement du cycle de vie du processus; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de cycles, de phases, d'itérations, de jalons.
Vie du processus unifié
UP répète un certain nombre de fois une série de cycles qui s'articule autours de 4 phases : Analyse des besoins (ou inception); Élaboration; Construction; Transition.
Vie du processus unifié
Vie du processus unifié
Cycle de développement
itération phase
Analyse
Élaboration Construction Transition
jalon
Point final d’une itération faisant l’objet d’une évaluation ou d’une décision significative
livrable
Sous-ensemble exécutable et stable du produit final.La fin de chaque itération est une livraison mineure
Livraison finalen production
Le système est livré et utilisé en production
Vie du processus unifié Pour mener efficacement un tel cycle, les développeurs
ont besoins de toutes les représentations du produit logiciel
un modèle de cas d'utilisation un modèle d'analyse : détailler les cas d'utilisation et
procéder à une première répartition du comportement un modèle de conception : finissant la structure statique
du système sous forme de sous-systèmes, de classes et interfaces.
un modèle d'implémentation : intégrant les composants un modèle de déploiement : définissant les nœuds
physiques des ordinateurs un modèle de test : décrivant les cas de test vérifiant les
cas d'utilisation une représentation de l'architecture
Les activités : expression des besoins
Les activités : expression des besoins L'expression des besoins comme son nom
l'indique, permet de définir les différents besoins :
inventorier les besoins principaux et fournir une liste de leurs fonctions;
comprendre le contexte du système en produisant un modèle du métier ou du domaine;
recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des modèles de cas d'utilisation;
appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences.
Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous forme de cas d'utilisation et d'acteurs, les besoins du client.
Les types et les catégories de besoins : FURPS+ Dans le processus unifié, les besoins sont
classés selon le modèle FURPS+ : Fonctionnalité (Functionality). Fonctions, capacités
et sécurité. Aptitude d’utilisation (Utilisability). Facteurs
humains, aide et documentation. Fiabilité (Reliability). Fréquence des pannes,
possibilités de récupération. Performance (Performance). Temps de réponse,
débit, exactitude, disponibilité et utilisation des ressources.
Possibilités de prise en charge (Supportability). Adaptabilité, facilité de maintenance, internationalisation et « configurabilité ».
Les types et les catégories de besoins : FURPS+ Le « + » de FURPS+ reprend :
Implémentation. Limitation des ressources, langage et outils, matériel, etc.
Interface. Contraintes d’interfaçage avec des systèmes externes.
Exploitation. Gestion du système dans l’environnement de production.
Conditionnement. Aspects juridiques. Attribution des
licences, etc.
Les artefacts pour les besoins Le Processus Unifié propose plusieurs artefacts pour
organiser les besoins : Modèle de cas d’utilisation. Spécifications supplémentaires.
Elles contiennent tout ce qui ne se trouve pas dans les cas d’utilisation et concernent surtout les besoins non fonctionnels.
Glossaire. Il définit les termes les plus importants. Il englobe également
le concept de dictionnaire de données, qui contient les spécifications liées aux données, telles que les règles de validation, les plages de valeurs acceptables, etc.
Vision. Brève vue d’ensemble qui permet aux décisionnaires de
découvrir rapidement les grandes idées d’un projet. Règles métier.
Règles du domaine qui dérivent les besoins ou politiques qui ne s’appliquent pas qu’à un seul projet (mais plutôt à un domaine/métier).
Spécifications supplémentaires : Exemple
Fonctionnalité Journalisation et traitements des
erreurs Journalisation de toutes les erreurs en
mémoire persistante Sécurité
Toute utilisation implique une authentification.
Spécifications supplémentaires : Exemple
Ergonomie Le client doit voir le système de vente
sur grand écran. En conséquence : Le texte doit être lisible à un mètre de
distance. Les couleurs associées aux formes
courantes de daltonisme doivent être évitées.
Spécifications supplémentaires : Exemple
Fiabilité Robustesse
En cas d’indisponibilité des systèmes connectés (autorisation bancaire, système comptable, ..), il faut une solution locale (par exemple stockage provisoire) qui permette de réaliser quand même la vente.
Spécifications supplémentaires : Exemple
Performance Les acheteurs supportent mal
l’attente. L’un des goulets d’étranglement possibles est la durée de l’autorisation bancaire. Notre objectif sera donc que le délai séparant le demande de la réponse soit inférieur à une minute dans 90% des cas.
Etc.
Glossaire : Exemple
Terme Définitions et informations
Format
Règles de validation
Alias
Article Produit ou service en vente
Autorisation de paiement
Validation par un organisme externe avec garantie de paiement
UPC Code numérique identifiant le produit. Généralement symbolisé à l’aide d’un code-barres.
Code à 12 chiffres
Le 12ème chiffre set à la vérification
Univeral Product Code
Règles métiers : exemple Règle 1 : Signature obligatoire pour les
paiements à crédits. Changement : La « signature » de l’acheteur
continuera à être exigée mais la plupart des clients voudront d’ici 2 ans utiliser un appareil de saisie numérique des signatures.
Règle 2 : Règle de taxation des ventes. Voir les différentes législations. Changement : Les dispositions fiscales sont
révisables tous les ans.
Les activités : expression des besoins
Analyste
Architecte
Spécificateurde cas d'utilisation
Designerd'interface
Trouver acteurs et
cas d'utilisation
Donner une prioritéaux cas
d'utilisation
Détailler lescas
d'utilisation
Prototyperl'interface-utilisateur
Structurer le modèle
de cas d'utilisation
Les activités : analyse
Les activités : analyse L'objectif de l'analyse est d'accéder à une
compréhension des besoins et des exigences du client.
Il s'agit de livrer des spécifications plus précises des besoins pour permettre de choisir la conception de la solution.
Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la modification et la maintenance du futur système.
Les activités : analyse
Les produits sont : Diagrammes de classe Diagrammes d'interaction
Les activités : analyse
Architecte
Ingénieurde cas d'utilisation
Ingénieurcomposante
Analyserl'architectur
e
Analyser lescas
d'utilisation
Analyserles
classes
Analyserles
packages
Les activités : conception
Les activités : conception La conception permet d'acquérir une
compréhension approfondie des contraintes liées au langage de programmation, à l'utilisation des composants et au système d'exploitation.
Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune.
Elle constitue un point de départ à l'implémentation :
elle décompose le travail d'implémentation en sous-système;
elle crée une abstraction transparente de l'implémentation.
Les activités : conception
Les produits sont : Architecture de design Diagrammes de classe
d'implémentation organisés en sous-système
Diagrammes d'interaction Modèle de déploiement
Les activités : conception
Architecte
Ingénieurde cas d'utilisation
Ingénieurcomposante
Définirl'architectur
e
Valider lescas
d'utilisation
Définirles
classes
Définir lessous-
systèmes
Les activités : implémentation
Les activités : implémentation L'implémentation est le résultat de la
conception pour implémenter le système sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type.
Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes sources.
Les activités : implémentation
Les produits sont : Architecture d'implémentation Composantes organisées en sous-
systèmes Plan d'intégration
Les activités : implémentation
Architecte
Intégrateursystème
Ingénieurcomposante
Architectured'implémentatio
n
Intégrationde
système
Implémenterles sous-systèmes
Implémenter
les classes
Faire les tests
unitaires
Les activités : test
Les activités : test
Les tests permettent de vérifier des résultats de l'implémentation en testant la construction.
Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.
Les activités : test
Testeur d'intégration
Testeur de système
Plande test
Exécution destest
d'intégration
Implémenter
les tests
Exécution des
tests système
Évaluation
des testsIngénieur de test
Ingénieurcomposante
Designdes tests
Les activités
Il existe d’autres découpes des activités … Tests Déploiement Gestion de projet Environnement …
Les activités
Les phases : Analyse des besoins L'analyse des besoins donne une vue du
projet sous forme de produit fini. Cette phase porte essentiellement sur les
besoins principaux (du point de vue de l'utilisateur), l'architecture générale du système, les risques majeurs, les délais et les coûts.
On met en place le projet. Elle répond aux questions suivantes :
que va faire le système ? par rapport aux utilisateurs principaux, quels services va-t-il rendre?
quelle va être l'architecture générale (cible) de ce système ?
quels vont être : les délais, les coûts, les ressources, les moyens à déployer?
Les phases : Analyse des besoins Délimiter la portée du système
proposé : définir les frontières et identifier les interfaces
Décrire et esquisser l'architecture candidate
Identifier les risques les plus sérieux Démontrer que le système proposé est
en mesure de résoudre les problèmes ou de prendre en charge les objectifs fixés
Les phases : Élaboration
Les phases : Élaboration L'élaboration reprend les éléments de la phase
d'analyse des besoins et les précise pour arriver à une spécification détaillée de la solution à mettre en œuvre.
L'élaboration permet de préciser la plupart des cas d’utilisation, de concevoir l’architecture du système et surtout de déterminer l'architecture de référence.
Au terme de cette phase, les chefs de projet doivent être en mesure de prévoir les activités et d’estimer les ressources nécessaires à l’achèvement du projet.
Les phases : Élaboration Les taches à effectuer dans la phase
d’élaboration sont les suivantes : créer une architecture de référence identifier les risques, ceux qui sont de
nature à bouleverser le plan, le coût et le calendrier
définir les niveaux de qualité à atteindre formuler les cas d'utilisation pour couvrir les
besoins fonctionnels et planifier la phase de construction
élaborer une offre abordant les questions de calendrier, de personnel et de budget
Les phases : Construction
Les phases : Construction La construction est le moment où
l’on construit le produit. L’architecture de référence se
métamorphose en produit complet. Le produit contient tous les cas
d’utilisation que les chefs de projet, en accord avec les utilisateurs, ont décidé de mettre au point pour cette version.
Les phases : Construction
Finalisation de l'analyse, de la conception de l'implémentation et des tests.
Surveillance des risques critiques et significatifs identifiés dans les deux premières phases et réduction des risques.
Les phases : Transition
Les phases : Transition Le produit est en version bêta. Un groupe d’utilisateurs essaye le
produit et détecte les anomalies et défauts.
Cette phase suppose des activités comme la formation des utilisateurs clients; l’élaboration des manuels et de la
documentation concernant la version du produit;
la mise en œuvre d’un service d’assistance; et la correction des anomalies constatées.
Architecture du système
Vueutilisateur
Vuelogique
Vuecomportement
Vuedéploiement
Vueimplémentation
Architecture du système
L’architecture du système se base sur cinq vues différentes de la solution : Vue Utilisateur Vue Logique Vue Comportement Vue Implémentation Vue Déploiement
Vue Utilisateur La vue utilisateur présente le
système du point de vue du propriétaire et de l'utilisateur final.
La vue présente les buts et objectifs du système.
La vue présente les requis et fonctionnalités du système. diagrammes de cas d’utilisation
Vue Logique
La vue logique présente les aspects statiques et structuraux du problème et de la solution : diagrammes de classes; diagrammes d'objets.
Vue Comportement La vue comportement présente les
aspects dynamiques du problème et de la solution.
La vue comportement présente les interactions et collaborations entre les éléments du système : diagrammes d'états; diagrammes d'activités; diagrammes de séquence; diagrammes de collaboration.
Vue Implémentation
La vue implémentation présente les aspects statiques, structuraux et dynamiques de la réalisation de la solution.
La vue implémentation présente l'organisation du code de la solution : diagrammes des composants.
Vue Déploiement
La vue déploiement présente les aspects statiques et dynamiques de l'exécution de la solution.
La vue déploiement présente les éléments physiques de la solution (processeurs, périphériques, ...) : diagrammes de déploiement;