Activité :
|
Objet Développer un plan détaillé pour une seule itération, comprenant :
|
|
Rôle : Chef de projet | |
Fréquence : Une fois par itération | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement des activités : |
Une itération est un ensemble de tâches à exécuter dans un délai donné, visant à obtenir un exécutable défini. Pour toutes les itérations, sauf la dernière (phase de transition), il s'agit de livrer un produit intermédiaire destiné à limiter les risques et à assurer la réussite du projet. Le fait de se concentrer sur un livrable exécutable suppose un effort d'intégration quasi continu et permet de traiter les risques techniques très tôt dans le projet, et donc de les limiter.
L'intégration suppose un certain degré de remaniement des artefacts existants, ainsi qu'une évolution de l'attitude par rapport au concept de remaniement. En bref, pour livrer un produit de qualité, il est nécessaire de retravailler les différents éléments : en développant des produits intermédiaires et en évaluant l'adéquation de l'architecture du produit très tôt et souvent, vous obtenez un produit final de qualité et les changements sont moins coûteux et plus faciles à mettre en place.
Objet | Choisir les cas d'utilisation ou les scénarios à utiliser dans le cadre de l'itération. Choisir les exigences non fonctionnelles à traiter dans le cadre de l'itération. |
Principes et conseils : Plan d'itération |
La portée d'une itération dépend de quatre facteurs :
Lors de la planification initiale d'une itération, une quantité de travail suffisante est définie pour utiliser le temps prévu pour l'itération , mais le chef de projet dispose d'une certaine marge de manoeuvre pour prendre en compte les contraintes liées aux ressources et d'autres considérations techniques lors du développement du plan d'itération. Bien évidemment, les tâches planifiées pour l'itération précédente et qui n'ont pas été effectuées (par exemple parce que la portée de l'itération précédente a été réduite pour des raisons de délai) bénéficient d'une priorité élevée.
La portée du travail planifié doit également tenir compte du personnel qu'il est possible d'affecter pendant la durée de l'itération. Par exemple, il n'est généralement pas possible de doubler le travail réalisé dans le cadre d'une itération en doublant le personnel affecté, même si ces ressources sont disponibles. Le nombre de ressources qu'il est possible d'affecter tout en restant efficace est déterminé par l'envergure et l'architecture du logiciel. Des modèles d'estimation comme COCOMO II (voir [BOE00]) peuvent vous aider à déterminer ce nombre de ressources.
L'exécution d'une itération est ensuite gérée par jalonnement : il s'agit de gérer la portée et la qualité (en termes de défauts identifiés et non résolus) tout en respectant le délai final.
Vous devez prendre en compte trois éléments essentiels lors de la définition des objectifs d'une itération de la phase d'élaboration :
Les risques constituent l'aspect le plus important. Vous devez limiter ou éliminer les risques aussi tôt que possible. Cela concerne principalement la phase d'élaboration, à l'issue de laquelle la plupart des risques doivent être limités, mais cela peut se poursuivre dans la phase de construction, car certains risques peuvent rester élevés et de nouveaux risques peuvent être identifiés. Toutefois, l'objectif de la phase d'élaboration étant de fournir une architecture de référence, d'autres considérations doivent également être prises en compte : vous devez par exemple vous assurer que l'architecture choisie répond bien à tous les critères du logiciel à développer (couverture). Cet aspect est primordial car cette architecture sera utilisée pour les planifications à venir : organisation de l'équipe, estimation du code à développer, etc.
Enfin, si l'évaluation des risques est importante, il ne faut pas perdre de vue les principales missions du système : la résolution des problèmes ne doit pas se faire au détriment des fonctionnalités vitales. Assurez-vous que les fonctions et services de base du système sont couverts (importance), même si aucun risque ne semble leur être lié.
Pour les risques les plus lourds de conséquences de la liste, identifiez un scénario au sein d'un cas d'utilisation, au cours duquel l'équipe de développement se trouvera "confrontée" au risque en question.
Exemples
- Si vous avez un risque d'intégration de type "base de données D fonctionnant correctement avec le système d'exploitation Y", vous devez inclure un scénario qui implique une interaction avec la base de données, même si elle est limitée.
- Si vous avez un risque de performance de type "temps nécessaire au calcul de la trajectoire de l'avion", vous devez avoir au moins un scénario qui inclut ce calcul, au moins pour le cas le plus évident et fréquent.
Du point de vue de l'importance, assurez-vous que les fonctions et services principaux fournis par le système sont inclus. Sélectionnez un scénario issu du cas d'utilisation qui représente la forme la plus courante et fréquente du service ou de la fonctionnalité offert par le système. Le document Artefact : Document d'architecture logicielle vous aidera dans cette tâche, car il contient une liste hiérarchisée des cas d'utilisation et de leurs enchaînements d'activités, sélectionnés par le Rôle : Architecte logiciel pour refléter les cas d'utilisation et les scénarios importants du point de vue de l'architecture.
Exemple
- Pour un commutateur téléphonique, l'appel classique de poste à poste est un élément incontournable pour une itération de début de projet. Il est beaucoup plus important de réussir ce point, plutôt que de chercher des modes d'échec compliqués dans le sous-système de gestion des erreurs.
Concernant la couverture, vers la fin de la phase d'élaboration, pensez à inclure des scénarios qui touchent certains domaines qui seront à développer, bien qu'ils ne soient ni cruciaux ni risqués.
Il est souvent plus judicieux de créer des scénarios longs et complets qui traitent plusieurs problèmes en même temps.
Toutefois, le danger est de développer des scénarios trop "touffus", qui essaient de couvrir trop d'aspects, de variantes et de cas d'erreur différents (Voir Principes et conseils : Plan d'itération)
En outre, lors de la phase d'élaboration, n'oubliez pas que certains risques sont surtout liés à l'homme ou au programme : culture, formation, choix des outils, nouvelles techniques, etc. Dans ce cas, un examen minutieux de l'itération suffit à limiter les risques.
Exemples
- Créer un enregistrement abonné sur une station de travail cliente, à stocker dans la base de données du serveur (comprenant les interactions avec l'utilisateur, mais ne comprenant pas tous les champs, et en supposant qu'aucune erreur n'a été détectée).
Combine un certain nombre de fonctions critiques, avec des risques d'intégration (base de données et logiciel de communication) et des problèmes d'intégration (utilisation de 2 plates-formes différentes). Les concepteurs doivent se familiariser avec de nouveaux outils de conception d'interfaces utilisateur. Permet d'obtenir un prototype qui peut être présenté aux utilisateurs finaux afin de recueillir leurs commentaires.- S'assurer qu'il est possible de créer jusqu'à 20 000 abonnés et que l'accès à un abonné se fait en moins de 200 millisecondes.
Met en jeu un certain nombre de problèmes de performance (volume ou données, temps de réponse), susceptibles d'avoir des conséquences significatives sur l'architecture s'ils ne sont pas résolus.- Annuler le changement d'adresse d'un abonné.
Fonctionnalité simple qui force les concepteurs à élaborer une conception pour toutes les fonctions d'"annulation". Cela peut permettre de signaler aux utilisateurs finaux les fonctions qui peuvent être annulées moyennant un coût raisonnable.- Effectuer tous les cas d'utilisation liés à la gestion de la chaîne logistique.
La phase d'élaboration a également pour objectif de terminer le recueil des exigences, éventuellement ensemble par ensemble.
Lorsque le projet entre dans la phase de construction, les risques restent un élément important, car de nouveaux risques peuvent être identifiés. Toutefois, le degré d'achèvement du cas d'utilisation commence également à revêtir une certaine importance. Les itérations peuvent être planifiées fonctionnalité par fonctionnalité, en achevant les plus importantes aussi tôt que possible, afin qu'elles puissent être testées de manière approfondie dans le cadre de plusieurs itérations. Vers la fin de la construction, on cherche à obtenir des cas d'utilisation terminés et robustes.
Exemple
- Implémenter toutes les variantes du transfert d'appel, y compris celles qui sont erronées.
Il s'agit d'un ensemble de fonctionnalités associées. Une d'entre elles peut avoir été implémentée lors de la phase d'élaboration, auquel cas elle servira de prototype pour le reste du développement.- Assurer toutes les fonctionnalités de l'opérateur, sauf le service de nuit.
Il s'agit d'un autre ensemble de fonctionnalités.- Assurer 5 000 transactions par heure avec 2 ordinateurs.
Cela peut impliquer une augmentation des performances requises, par rapport à ce qui avait été réalisé lors de l'itération précédente (seulement 2 357/heure)- Intégrer une nouvelle version du Système d'information géographique.
Cela constitue un changement architectural mineur, qui peut être nécessaire suite à certains problèmes identifiés plus tôt.- Eliminer tous les défauts de niveau 1 et de niveau 2
Il s'agit de résoudre les défauts identifiés lors des tests exécutés dans le cadre de l'itération précédente, qui n'ont pas été résolus immédiatement et ont été différés.
L'objectif principal est de finaliser cette génération du produit. Les objectifs d'une itération sont exprimés en termes de problèmes à résoudre, d'améliorations à apporter ou de niveau de convivialité à atteindre. Si certaines fonctionnalités ont été laissées de côté ou désactivées pour terminer la phase de construction dans les temps (jalon IOC ou version "bêta"), elles peuvent maintenant être finalisées, ou activées, à condition qu'elles ne mettent pas en péril ce qui a été construit jusqu'à présent.
Exemples
- Résoudre tous les problèmes de niveau 1 identifiés sur les sites client bêta.
Il s'agit d'un objectif de qualité, qui peut avoir une incidence sur la crédibilité sur le marché.- Eliminer tous les plantages au démarrage dus à des données incorrectes.
Il s'agit également d'un objectif de qualité.- Assurer 2 000 transactions par minute.
Il s'agit d'un ajustement des performances qui implique une certaine optimisation : changement de la structure des données, mise en mémoire cache et algorithme plus performant.- Réduire de 30 % le nombre de boîtes de dialogue.
Il s'agit d'améliorer la convivialité en limitant la surcharge visuelle.- Produire des versions en allemand et en japonais.
La version bêta a été produite uniquement en anglais, par manque de temps et pour limiter la quantité de remaniements.
Chaque itération conduit à la production d'une version exécutable. Cette version n'est généralement de qualité finale (sauf pour la dernière phase de transition), mais elle peut malgré tout être évaluée.
L'itération de création a pour but de justifier le concept du produit et de rassembler les éléments nécessaires à l'obtention du financement pour le projet. Par conséquent, la version de création est généralement un prototype fonctionnel axé sur le concept, qui ne contient pas réellement de code d'implémentation et se limite plutôt à une interface utilisateur simple. Les critères d'évaluation sont donc axés sur la validation par l'utilisateur et sur des mesures qualitatives.
Dans certains cas, des obstacles techniques majeurs doivent être levés lors de la phase de création afin d'obtenir le financement nécessaire : les critères d'évaluation doivent alors refléter cela.
Voir les critères d'évaluation pour la phase de création.
Les itérations d'élaboration visent à créer une architecture stable. Par conséquent, les critères d'évaluation sont axés sur une estimation de la stabilité de l'architecture. Vous pouvez par exemple utiliser les mesures suivantes :
L'objectif est de s'assurer que les changements apportés lors de la phase de construction ne se répercutent pas en cascade sur tout le système, entraînant la reprise de nombreux éléments.
Voir les critères d'évaluation pour la phase d'élaboration.
Les itérations de construction et de transition sont évaluées selon les critères classiques de test de logiciels et de gestion des changements, comme la fragilité, le nombre de défauts et le taux d'identification des erreurs. Pour ces itérations, le but est d'identifier les erreurs afin de les réparer.
Les erreurs peuvent être identifiées de différentes manières : inspections et revues de code, tests fonctionnels, tests de performance et tests de chargement. Chacune de ses techniques vise à identifier un certain type de défaut et chacune a donc sa place dans le projet. Ces techniques sont présentées en détails dans la discipline consacrée au test Rational Unified Process.
Voir les critères d'évaluation pour la phase de construction et les critères d'évaluation pour la phase de transition.
En fonction des objectifs de l'itération, vous devez définir les activités à exécuter dans le cadre de cette itération. Généralement, chaque itération exécute en partie toutes les activités comprises dans le cycle de vie du logiciel :
En fonction de l'itération et de la phase du projet, ces activités sont réalisées de façon plus ou moins approfondie. Les différentes disciplines (Exigences, Analyse et conception, Test, etc.) définissent les activités génériques, qui sont ensuite adaptées à l'organisation lors de la configuration des processus.
Une fois que les scénarios ou les cas d'utilisation complets à développer (avec les défauts à corriger) ont été sélectionnés et brièvement décrits, vous devez identifier les artefacts qui seront affectés :
Vous devez ensuite extraire des disciplines du processus les activités concernées, et les inclure dans votre plan. Certaines activités sont réalisées une fois par itération (exemple ici), d'autres doivent être exécutées une fois pour chaque classe, chaque cas d'utilisation ou chaque sous-système (exemple). Associez à chaque activité les dépendances les plus évidentes et allouez un effort estimé. La plupart des activités décrites pour le processus peuvent être accomplies par une seule personne, ou par une équipe restreinte, en quelques heures ou en quelques jours.
Vous constaterez souvent que toutes les activités ne peuvent pas être exécutées dans les délais impartis à l'itération. Dans ce cas, plutôt que de repousser le délai de l'itération (entraînant ainsi le report de la livraison finale ou la réduction du nombre d'itérations), limitez les objectifs de l'itération. En fonction de la phase concernée, vous pouvez simplifier les scénarios, ou bien éliminer ou désactiver des fonctionnalités.
Une fois que l'ensemble d'activités de l'itération a été défini, chaque activité doit être affectée à un ou plusieurs membres de l'équipe projet. En fonction des ressources disponibles et de la portée de l'itération, ces activités peuvent être exécutées par une seule personne ou par une équipe. Les revues et les inspections sont bien entendu des activités à réaliser en équipe. D'autres activités, comme la rédaction de cas d'utilisation ou la conception et l'implémentation de classes, sont généralement exécutées par une seule personne (sauf dans le cas où un débutant est guidé par un membre de l'équipe plus expérimenté).
En général, chaque tâche doit avoir un seul responsable identifié, même si elle a été exécutée par une équipe :
En l'absence d'un point de contact unique, il est quasiment impossible d'assurer la cohérence.
RUP (Rational Unified Process)
|