Rubriques

Formes d'itérations Haut de la page

Itérations de création Haut de la page

Durant la création, les risques majeurs sont souvent d'ordre économique ou technique. Le risque économique dominant est généralement lié au financement du projet. Le prototype du concept résulte souvent de la phase de création. Le prototype du concept démontre la fonctionnalité clé ou une certaine technologie de base.

La première itération d'un nouveau produit est généralement la plus difficile. Une première itération doit réaliser plusieurs aspects, outre la production de logiciels ; par exemple, la mise en place du processus, la création de l'équipe, la compréhension d'un nouveau domaine, l'adaptation à de nouveaux outils et ainsi de suite. Soyez prudents dans vos estimations de la quantité d'architecture ou encore du degré de fonctionnalité que vous pouvez atteindre. Si vous visez trop haut, vous risquez de retarder la réalisation de la première itération, ce qui réduira le nombre total d'itérations, et par conséquent le bénéfice d'une approche itérative. Vous devez axer les premières itérations sur une conception cohérente de l'architecture. Vous devez donc impliquer les architectes logiciels dans le processus de planification des premières itérations.

Itérations d'élaboration Haut de la page

Durant la phase d'élaboration, les itérations mettent l'accent sur la définition d'une architecture stable, sur la conception et l'implémentation du comportement essentiel du système et sur l'examination des points techniques d'architecture à travers une série de prototypes architecturaux. Les scénarios "significatifs sur la plan architectural" sont des sous-flots qui entraînent l'architecture du système à la définition de méthodes.

Itérations de construction et de transition Haut de la  page

A la fin de la phase d'élaboration et durant les phases de construction et de transition, les demandes de changements (connues également sous le nom de SCO (Ordres de Changement du Logiciel)) déclenchent le processus d'itération. Les Ordres SCO proviennent :

  • des demandes d'améliorations
  • des demandes de changements dont la portée va au-delà du package ou de la classe individuelle.
  • des changements dans la portée et les objectifs de l'itération.
  • des changements de conditions, soit en demandant un changement de la ligne de base des conditions, soit en adaptant un changement à la ligne de base des conditions.

Ces ordres de changements du logiciel doivent être comparées au plan de projet existant, aux plans d'itérations et à la liste actuelle des risques. Les ordres de changement du logiciel peuvent entraîner la ré-évaluation des configurations ou conduire à redéfinir les priorités en termes de risques. Les ordres de changement du logiciel doivent être gérés avec soin, par crainte de perdre le contrôle du projet.

Durant les phases de construction et de transition, l'accent est mis sur le développement de l'architecture et sur l'implémentation des configurations restantes.

Stratégies d'itérations Haut de la page

Contrairement au modèle en cascade, dans lequel le système entier est instantanément pris en considération, nous ne prendrons ici en compte qu'une seule partie de la fonctionnalité du système dans chaque itération. Durant chaque itération, un sous-ensemble du système intégral est analysé, conçu et implémenté. Le choix du sous-système et le degré d'exploration de celui-ci sont des critères essentiels pour la réduction des risques dans les itérations suivantes. Il existe deux stratégies de base : Large/Peu profond et Etroit/Profond.

Large et peu profond Haut de la  page

Dans la stratégie Large/Peu profond, on analyse tout le domaine du problème, en ne prenant en compte que les détails en surface. Les cas d'utilisation sont tous définis, la plupart de façon très détaillée afin de bien assimiler le problème traité. L'architecture est aussi largement définie et les mécanismes et services clés pourvus par les composants architecturaux sont spécifiés ; les interfaces des sous-systèmes sont définies, mais leurs détails internes ne sont indiqués que si une incertitude ou un risque majeurs apparaissent. Peu d'éléments sont implémentés jusqu'à la phase de construction, où se produit la majeure partie de l'itération.

La stratégie Large/Peu profond est adaptée si :

  • L'équipe est inexpérimentée, dans le domaine du problème ou dans le secteur technologique (y compris la méthodologie ou le processus).
  • Une architecture solide est une condition clé par rapport aux futures possibilités et l'architecture est sans précédent.

La stratégie présente certains pièges potentiels, néanmoins :

  • L'équipe peut se trouver piégée dans une paralysie d'analyse (le sentiment illogique qu'on ne peut rien implémenter à moins que la conception ne soit parfaite).
  • Les premiers résultats sont souvent nécessaires à l'établissement de la confiance et de la crédibilité ; plus l'équipe du projet met du temps à produire une application exécutable, moins elle a confiance en sa capacité à réussir.
  • Il n'y a pas suffisamment de détails techniques et de défis relatifs à l'architecture pour connaître les vrais risques techniques

Etroit et profond Haut de la  page

Dans la stratégie Etroite/Profonde, un segment du domaine du problème est analysé en totalité. Les cas d'utilisation liés à ce segment étroit sont définis et décrits dans les moindres détails, pour assurer une bonne compréhension du problème traité. L'architecture requise pour prendre en charge le comportement désiré est définie et le système est conçu et implémenté. Les itérations suivantes ciblent l'analyse, la conception et l'implémentation de segments verticaux supplémentaires.

La stratégie Etroite/Profonde est adaptée si :

  • Les premiers résultats doivent être présentés afin de surmonter un risque dominant, recueillir un soutien et prouver la viabilité.
  • Les exigences évoluent continuellement, ce qui complique la définition de l'ensemble des exigences avant de débuter les travaux détaillés de conception et d'implémentation.
  • L'échéance est un élément obligatoire, pour cela, commencer très tôt le développement contribue à une livraison réussie.
  • Un niveau élevé de ré-utilisation est possible ce qui permet un meilleur niveau de livraison incrémentielle.

La stratégie n'est pas sans inconvénients :

  • Avec cette stratégie, chaque itération tend à développer un logiciel intégré verticalement mais incompatible horizontalement. On appelle parfois cela le syndrome du tuyau de poêle et cela rend le système difficile à intégrer.
  • Cela n'est pas adapté au développement de systèmes dans le cadre d'un tout nouveau domaine de problème ou sur la base d'une architecture sans précédent, du fait qu'une grande partie des fonctionnalités du système doit être échantillonnée afin de réaliser une architecture équilibrée.

Enseignements tirés de l'expérience Haut de la page

En général, chaque itération aura un aspect davantage Large/Peu profond, alors que les itérations suivantes (où une architecture stable a été développée) ont tendance à se conformer à la stratégie Etroit/Profond.

La première itération est généralement la plus difficile car elle requiert tout l'environnement de développement et sollicite une grande partie de l'équipe du projet. L'intégration des outils et les questions liées à la formation des équipes compliquent un peu plus l'approche de la première itération. Le fait de se concentrer sur les questions architecturales peut aider l'équipe à rester focalisée et à éviter d'être submergée par les détails, dès le début des opérations.

Stratégies hybrides Haut de la page

  • Stratégie Etroit/Profond utilisée durant la phase de création

    Lorsque l'utilisation d'une nouvelle technologie est essentielle à la viabilité fondamentale du projet.  De nombreux projets de commerce électronique exigent d'examiner les nouvelles technologies plus en détails que ce qui est pratiqué traditionnellement.  Le prototype de démonstration du bien fondé de la conception est encore considéré comme un élément "jetable", et examine seulement la viabilité du concept du projet.

  • La stratégie Large/Peu profond est utilisée dans la phase de création

    Cette stratégie est maintenue afin d'optimiser la compréhension de la portée du système, et d'échantillonner l'ampleur des fonctionnalités du système pour s'assurer que l'architecture est en mesure de livrer les capacités requises.

  • La stratégie Large/Peu profond est utilisée dans la phase d'élaboration

    Cette approche peut vous aider à développer une architecture solide, en s'axant sur une stratégie Etroit/Profond sélective qui permet de gérer les risques techniques spécifiques. Durant la phase de construction et lorsque une architecture solide est établie, on peut à nouveau s'orienter vers la stratégie Etroit/Profond, où les fonctionnalités sont développées et livrées avec une série d'incréments intégrés.

  • La stratégie Etroit/Profond est utilisée dans la phase de construction

    Les itérations de construction sont toujours du type Etroit/Profond, et elles impliquent toujours des équipes travaillant en parallèle pour développer et livrer les fonctionnalités requises. 

Considérations particulières pour les nouvelles équipes Haut de la page

Les nouvelles équipes sont généralement trop optimistes par rapport à ce qu'elles sont capables de réaliser. Pour parer cette attitude et éviter les problèmes potentiels sur le plan moral, survenant lorsque la réalité ne rejoint pas les attentes optimistes, soyez modeste quant au volume de fonctionnalités susceptibles d'être réalisées dans la première itération. Essayez de bâtir une expérience tout en créant une notion de réussite et en donnant un dynamisme au projet.

Si l'environnement de développement et/ou les méthodes sont nouveaux pour l'équipe, réduisez les fonctionnalités de la première itération à un minimum. Mettez l'accent sur l'intégration et l'adaptation de l'environnement et sur l'acquisition des compétences dans l'utilisation des outils ; intégrez ensuite graduellement les fonctionnalités dans les itérations suivantes.

Remodelage prévue Haut de la page

Il est bon de remodeler, mais jusqu'à un certain point. Un des principaux avantages du développement itératif est précisément de permettre des erreurs ainsi que l'expérimentation, mais assez tôt de manière à pouvoir effectuer des corrections. Cependant, les personnes à profil technique en particulier ont tendance à "peaufiner" et à reprendre leur travail jusqu'à la perfection, entre une itération et la suivante.

A la fin de chaque itération, durant l'évaluation de l'itération, l'équipe doit définir la partie de la version en cours à retravailler. Notez les pourcentages suivants calculés par rapport au système dans son ensemble, concernant le remodelagedans les différentes phases :

  • Création, 40%-100% - c'est là où vous pouvez développer des prototypes jetables et exploratoires
  • Elaboration, 25%-60% dans les premières itérations ; moins de 25% dans les itérations suivantes, ou dans un cycle d'évolution.
  • Construction, après la ligne de base de l'architecture, 10% ou moins par itération et 25% au total.
  • Transition, moins de 5%.

Le remodelage est inévitable. Nous vous recommandons d'être méfiant si personne n'estime qu'un remodelage est nécessaire. Cela peut s'expliquer par :

  • Une planification excessivement serrée.
  • Un manque de tests ou d'évaluation véritable.
  • Un manque de motivation ou de concentration.
  • Une perception négative du remodelage comme quelque chose de mauvais, un gaspillage des ressources, ou encore l'acceptation d'une incompétence ou d'une anomalie.

Un remodelage trop importante est alarmante. Cela peut s'expliquer par le fait de toujours vouloir parfaire jusqu'à un niveau de changement des exigences inacceptable. Un cas métier doit être réalisé pour évaluer la nécessité de reprendre les travaux.

Notez que nous n'incluons pas les tâches reportées de l'itération précédente (en raison de l'approche jalonnée de la gestion des itérations) dans la catégorie "remodelage". Le chef de projet doit inclure ce travail reporté dans le groupe de fonctionnalités utilisé pour définir le contenu de l'itération suivante. Evidemment, un travail de ce type a normalement une priorité élevée. Le chef de projet doit également découvrir et analyser scrupuleusement les raisons des anomalies survenues dans l'itération précédente qui l'ont empêchée d'atteindre ses objectifs. Par exemple, bien que nous conseillons pas de recruter arbitrairement du personnel supplémentaire pour répondre à une planification très serrée, il n'est pas non plus logique de mener un projet en sous-effectif chronique - tout en élaborant des plans ambitieux pour chaque itération. Cela conduit généralement à démoraliser les équipes et à irriter les clients. Il faut trouver un juste équilibre et les modèles d'estimation tels que COCOMO II (voir[BOE00]) peuvent vous aider. Pour chaque itération, un projet conçoit un historique en terme de réussite - la productivité et la qualité. Lorsqu'il planifie la prochaine itération, le chef de projet se réfère tout particulièrement à ce qui a été réalisé dans la précédente.

Niveau de planification Haut de la page

Lorsque la première version du plan d'itération est complet, les responsables de l'équipe, éventuellement accompagnés du chef de projet peuvent le faire évoluer vers un plan de travail au niveau de l'activité. Les ../../prjtmpl/msproject.htm -- This hyperlink in not present in this generated websiteModèles Microsoft Project inclus (au niveau de l'activité) illustrent comment cela peut se produire. Notez tout de même que ces plans de travail proviennent du plan d'itération ; ce ne sont pas des artefacts indépendants, produits séparément. Si le chef de projet doit garder le contrôle, il est important d'adapter les plans de travail pour visualiser l'état du plan d'itérations du chef de projet.



RUP (Rational Unified Process)   2003.06.15