Tâche: Développer un plan d'itération
Cette tâche décrit comment établir un plan d'itération en définissant la portée, les critères d'évaluation, les activités et en attribuant des responsabilités pour l'itération.
Objet

Développer un plan d'itération qui comprenne les éléments suivants :

  • une structure détaillée de la répartition du travail concernant les tâches et les responsabilités
  • les jalons et les livrables pour chaque itération
  • les critères d'évaluation pour l'itération
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Description principale

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'itération suppose une certaine charge de retravail (de produits existants) et une évolution de l'attitude par rapport au concept de retravail. En bref, pour livrer un produit de qualité, il est nécessaire de retravailler un minimum : en développant des produits intermédiaires et en évaluant l'adéquation de l'architecture du produit tôt et souvent, vous obtenez un produit final de meilleure qualité et les changements sont moins coûteux et plus faciles à mettre en place.

Etapes
Détermination de la portée de l'itération
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. 
Instructions :  Plan d'itération 

La portée d'une itération dépend de quatre facteurs :

  • Les principaux risques liés au projet
  • Les fonctionnalités souhaitées pour le système
  • Le temps alloué à l'itération dans le plan de projet
  • La phase et ses objectifs spécifiques (voir Concept : Phase)

Lors de la planification initiale d'une itération, le travail est sélectionné en quantité suffisante par rapport au temps planifié pour l'itération - bien que le responsable 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.

Dans la phase d'élaboration  :

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 :

  • Risque
  • Importance
  • Couverture

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.

Tout en vous concentrant sur l'importance des risques, vous devez garder à l'esprit quelles sont les missions principales du système ; c'est très bien de résoudre les questions difficiles mais cela ne doit pas être fait au détriment de la fonctionnalité centrale : assurez-vous que les fonctions critiques ou les services du système sont en effet couverts (criticité), même si aucun risque associé n'est perçu.

Pour les risques les plus lourds de la liste de risques, 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", assurez-vous d'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 d'architecture logicielle sert à mener ces efforts, fournissant un ensemble prioritaire de cas d'utilisation ou de sous-flux de cas d'utilisation sélectionnés par l'architecte du logiciel pour refléter les cas d'utilisation ou 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.

Le danger est souvent 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 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

  1. 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 finalement d'obtenir un prototype qui peut être présenté aux utilisateurs finaux afin de recueillir leurs commentaires.
  2. 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.
    Traite quelques problèmes clés de performance (volume ou données et temps de réponse) susceptibles d'avoir des conséquences significatives sur l'architecture s'ils ne sont pas résolus.
  3. 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.
  4. 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.

Dans la phase de construction  :

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

  1. 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.
  2. Assurer toutes les fonctionnalités de l'opérateur, sauf le service de nuit.
    Il s'agit d'un autre ensemble de fonctionnalités.
  3. 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)
  4. 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.
  5. 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..

Dans la phase de transition  :

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

  1. 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é.
  2. Eliminer tous les plantages au démarrage dus à des données incorrectes.
    Il s'agit également d'un objectif de qualité.
  3. 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.
  4. Réduire de 30 % le nombre de boîtes de dialogue.
    Il s'agit d'améliorer la convivialité en limitant la surcharge visuelle.
  5. 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.
Définition des critères d'évaluation d'une itération

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.

Evaluation des itérations de création

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.

Evaluation des itérations d'élaboration

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 :

  • Stabilité (ou fragilité) de l'interface
  • Taux de changement de l'architecture (par rapport à une architecture de référence)
  • Performance des principales fonctionnalités

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.

Evaluation des itérations de construction et de transition

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.



Définition des activités d'une itération

En fonction des objectifs de l'itération, vous devez sélectionner l'ensemble des tâches à réaliser 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 :

  • Les cas d'utilisation et les scénarios qui permettent d'obtenir les fonctionnalités souhaitées sont retenus
  • Le comportement de chaque cas d'utilisation ou scénario est étudié et documenté
  • Le comportement est analysé et distribué entre un certain nombre de sous-systèmes et de classes qui fournissent le comportement nécessaire
  • Les classes et les sous-systèmes sont conçus, implémentés et testés
  • Le système est intégré et testé dans son intégralité
  • Pour les versions destinées à l'extérieur (alpha, bêta et version finale), le produit est livré sous la forme d'un package acceptable et placé dans l'environnement utilisateur.

Ces tâches sont réalisées de façon plus ou moins approfondie, en fonction de l'itération et de la phase du projet. Les différentes disciplines (Recueil des exigences, Analyse et conception, Test, etc.) définissent les tâches génériques, qui sont ensuite personnalisées par rapport à l'organisation lors de la configuration des processus.

Identifiez les produits affectés et les tâches concernées

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 produits qui seront affectés :

  • Quelles sont les classes qui devront être revues ?
  • Quels sont les sous-systèmes affectés, ou même à créer ?
  • Quelles interfaces seront probablement modifiées ?
  • Quels documents devront être mis à jour ?

Vous devez ensuite extraire des disciplines du processus les activités concernées et les inclure dans votre plan. Certaines tâches 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 tâche les dépendances les plus évidentes et attribuez un effort estimé. La plupart des tâches décrites pour le processus sont assez courtes pour ê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.

Attribution des responsabilités

Une fois que l'ensemble de tâches de l'itération a été défini, chaque tâche doit être affectée à un ou plusieurs membres de l'équipe projet. En fonction des ressources du personnel disponibles et de la portée de l'itération, ces tâches peuvent être exécutées par une seule personne ou par une équipe. Les revues et les inspections sont bien entendu des tâches à réaliser en équipe. D'autres tâches, 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é qui lui sert de mentor).

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 :

  • Cas d'utilisation
  • Sous-systèmes
  • Classes
  • Tests et plans de test
  • etc.

En l'absence d'un point de contact unique, il est quasiment impossible d'assurer la cohérence.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Considérations clés

La planification du projet est l'étape où le responsable de projet instancie (et par la suite gère l'exécution de) un processus de livraison spécifique (voir Produit : Processus de développement) pour le projet. On appelle souvent cela promulgation de processus.

Un processus "instancié" est un plan de projet/itération/activité applicable (il inclut les activités réelles et les produits d'un projet en cours). Un processus de livraison peut être instancié en important un processus de livraison à partir de Rational Method Composer dans Rational Portfolio Manager (RPM) puis en exécutant un travail d'instanciation en copiant les activités et les tâches qui sont paramétrées comme isRepeatable ou hasMultipleOccurences, en créant des produits réels, en attribuant des ressources réels à des rôles, etc. 

Plus d'informations