Instructions: Plan de développement logiciel
Ces instructions fournissent une assistance pour la création d'un Plan de développement logiciel dans le cadre d'un cycle de développement itératif. Elles expliquent également comment une séquence de revues en cascade classique peut être adaptée pour une approche itérative.
Relations
Description principale

Choix de la durée de chaque itération

Nous avons défini l'itération comme un mini-projet complet, impliquant toutes les disciplines et ayant généralement pour résultat un système exécutable incomplet, appelé une édition. Bien que le cycle (éditer, compiler, tester et déboguer) ressemble à une itération, ce n'est pas le sens que nous lui donnons ici. Les constructions quotidiennes ou hebdomadaires qui intègrent et testent de façon incrémentale de nouveaux éléments du système, peuvent également s'apparenter à des itérations. Toutefois, une construction ne représente qu'une partie d'une itération au sens où nous l'entendons ici.

Une itération commence par une planification et une définition des exigences, et s'achève par la création d'une édition, interne ou externe.

La durée d'une itération dépend principalement de la taille de l'organisation de développement.

Par exemple :

  • Cinq personnes peuvent effectuer la planification le lundi matin, déjeuner ensemble tous les jours pour évaluer l'avancement, réattribuer les tâches, commencer à générer une construction le jeudi et terminer l'itération le vendredi soir.
  • Mais ce processus serait difficilement réalisable avec une équipe de 20 personnes. En effet, il faudra compter davantage de temps pour répartir le travail, assurer la synchronisation entre les sous-groupes, intégrer, etc. Dans ce cas, une itération prendra plutôt trois ou quatre semaines.
  • Avec 40 personnes, il faudra déjà compter une semaine pour que "l'influx nerveux aille du cerveau jusqu'aux extrémités". En effet, si vous avez des niveaux de management intermédiaires, la définition des objectifs visés nécessitera une documentation plus formelle. Il est probable alors qu'une itération dure en moyenne trois mois.

D'autres facteurs entrent en jeu : le degré de familiarité de l'organisation avec l'approche itérative, la stabilité et la maturité de l'organisation, le niveau d'automatisation pour la gestion du code (par exemple, gestion des changements distribuée), la distribution des informations (par exemple, site Web interne), l'automatisation du test, etc.

Vous devez également savoir qu'une itération implique inévitablement la mobilisation de ressources pour la planification, l'analyse des résultats, la synchronisation, etc.

Ainsi, si les nombreux avantages de l'approche itérative vous poussent à multiplier les itérations, les limites humaines de votre organisation vous freineront bien vite dans vos ardeurs.

Quelques données empiriques :

Lignes de code source (SLOC) Nombre de développeurs Durée d'une itération
10 000 5 1 semaine
50 000 15 1 mois
500 000 45 6 mois
1 000 000 100 1 an

  • Pour les itérations de plus de 6 mois, il est préférable d'ajouter des jalons intermédiaires afin d'assurer le suivi du projet. Vous pouvez également essayer de limiter la portée de l'itération afin de réduire sa durée et de garantir la clarté des objectifs.
  • Les itérations de plus de 12 mois génèrent des risques supplémentaires, car elles excèdent le cycle de financement annuel. Un projet qui n'a produit aucun résultat tangible sur les 12 derniers mois risque de perdre son financement.
  • Les itérations de moins d'un mois doivent avoir une portée clairement définie. Généralement, les itérations courtes conviennent davantage à la phase Construction, pour laquelle les nouvelles fonctionnalités à ajouter sont peu nombreuses. Dans le cadre d'une itération courte, les activités formelles d'analyse et de conception sont limitées voire inexistantes. Il s'agit souvent d'améliorer une fonctionnalité déjà mise en place.
  • Toutes les itérations ne doivent pas nécessairement être de la même durée : leur durée peut varier en fonction des objectifs. Généralement, les itérations d'élaboration sont plus longues que les itérations de construction. En revanche, au sein d'une même phase, les différentes itérations sont souvent de même longueur : cela facilite la planification.

Après avoir évalué le nombre total d'itérations dans votre plan général, vous devez définir le contenu de chacune de ces itérations. Il peut être utile de trouver un nom ou un titre pour qualifier le produit obtenu à la fin de chaque itération, afin que l'objectif soit plus clair.

Exemples d'itérations pour un commutateur téléphonique privé

  • Itération 1 : appels locaux.
  • Itération 2 : ajouter les appels extérieurs et la gestion des abonnés.
  • Itération 3 : ajouter la messagerie vocale et les conférences téléphoniques.

Choix du nombre d'itérations

Un projet simple peut comporter une seule itération par phase :

  • Une itération pour la phase de création, dont le produit serait par exemple un prototype justifiant le concept ou une maquette de l'interface utilisateur. Il est également possible de n'avoir aucune itération pour cette phase, par exemple dans le cas d'un cycle d'évolution.
  • Une itération pour la phase d'élaboration, afin de produire un prototype architectural.
  • Une itération pour la phase de construction, pour générer le produit (par exemple, une édition "bêta").
  • Une itération pour la phase de transition, pour achever le produit (édition complète).

Pour un projet de plus grande envergure, le cycle de développement initial peut se présenter de la manière suivante :

  • Une itération pour la phase de création, dont le produit pourrait être un prototype.
  • Deux itérations pour la phase d'élaboration : une pour le prototype architectural, l'autre pour la référence architecturale.
  • Deux itérations pour la phase de construction pour exposer un système partiel, puis l'améliorer.
  • Une itération pour la phase de transition, pour transformer les capacités opérationnelles initiales en une édition complète.

Pour un projet encore plus vaste, comportant de nombreux impondérables, on aurait certainement :

  • une itération supplémentaire pour la phase de création, afin de passer davantage de temps sur le prototype.
  • une itération supplémentaire pour la phase d'élaboration, afin d'explorer différentes technologies.
  • une itération supplémentaire pour la phase de construction, en raison de l'envergure du produit.
  • une itération supplémentaire pour la phase de transition, afin d'avoir un retour sur l'aspect opérationnel.

Un cycle de développement peut donc comporter :

  • Au minimum : 3 itérations [0,1,1,1]
  • Généralement : 6 itérations [1, 2, 2, 1]
  • En cas de projet plus vaste : 9 itérations [1, 3, 3, 2]
  • Au maximum : 10 itérations [2, 3, 3, 2]

Ainsi, vous pouvez considérer que vous aurez entre trois et dix itérations. Toutefois, les extrémités de cette fourchette représentent des cas exceptionnels et il faut savoir que la plupart des projets de développement se déroulent en six à huit itérations.

De nombreuses variations sont possibles en fonction des risques, de la taille et de la complexité :

  • Si le produit concerne un domaine entièrement nouveau, vous devrez peut-être rajouter quelques itérations dans la phase de création afin de consolider les concepts, présenter des maquettes à des représentants des clients ou des utilisateurs ou élaborer une réponse solide à une demande de proposition.
  • Si une nouvelle architecture doit être développée, ou si des activités poussées de modélisation de cas d'utilisation doivent être exécutées, ou encore si vous constatez que les risques semblent importants, vous devez prévoir deux ou trois itérations pour la phase d'élaboration.
  • Si le produit est important et complexe et développé sur une longue période de temps, vous devez prévoir au moins trois itérations pour la phase de construction.
  • Enfin, vous devez prévoir plusieurs itérations dans la phase de transition si vous devez livrer le produit avec des fonctionnalités minimales afin de réduire le délai de commercialisation, ou si vous pensez que vous devrez apporter un certain nombre de changements mineurs à la base utilisateur après un certain temps d'utilisation.

Correspondance entre la séquence de revues en cascade classique et l'approche itérative

La séquence de revues par défaut pour un projet à cycle de vie en cascade comporte une seule revue majeure à l'achèvement des produits importants, par exemple :

  • Revue des exigences du système (SRR), à l'issue de la spécification du système ;
  • Revue de spécification logicielle (SSR), à l'issue de la spécification des exigences logicielles ;
  • Revue de conception préliminaire (PDR), suite à la rédaction des sections concernant la conception architecturale dans la description de la conception logicielle ;
  • Revue critique de la conception (CDR), suite à la rédaction des sections concernant la conception détaillée dans la description de la conception logicielle.

Dans le Rational Unified Process (RUP), des portions des produits équivalents sont révisées au fur et à mesure de leur avancement au sein de chaque itération, mais les principaux jalons (et par conséquent les principales revues) correspondent à l'achèvement de chaque phase : création, élaboration, construction et transition. Un responsable de projet qui souhaite adopter le RUP doit résoudre ce conflit apparent, pour des raisons d'obligations contractuelles. Idéalement, le responsable de projet doit convaincre le client qu'une approche basée sur des phases et des itérations offre une meilleure visibilité sur l'avancement du projet et réduit les risques, ce qui rend inutiles la revue des exigences du système (SRR), la revue de spécification logicielle (SSR), etc. Toutefois, cela n'est pas toujours possible et dans ce cas, le responsable de projet devra planifier ces revues aux moments appropriés. Dans le RUP, il est possible d'identifier les moments auxquels ces produits importants (ou plus exactement, leurs équivalents dans le RUP) sont globalement terminés, bien que cela ne corresponde pas toujours exactement à la fin d'une phase ou d'une itération.

Cette correspondance est définie ici en supposant que les efforts consacrés aux exigences, à la conception, etc. seront à peu de chose près identiques dans le RUP et dans le cycle de vie en cascade idéal, mais que ces efforts seront répartis différemment. Le résultat obtenu est le suivant :

  • La revue des exigences du système (SSR, correspondant globalement au document Vision) peut être planifiée à la fin de la phase de création ;
  • La revue de spécification logicielle (SSR, correspondant globalement à la Spécification des exigences logicielles) peut être planifiée environ après qu'un tiers de la phase d'élaboration a été effectué ;
  • La revue de conception préliminaire (PDR, correspondant globalement au Document d'architecture logicielle) peut être planifiée à la fin de la phase d'élaboration ;
  • La revue critique de la conception (CDR, correspondant globalement au Modèle de conception) peut être planifiée environ après qu'un tiers de la phase de construction a été effectué.

Toutefois, pour une plus grande efficacité, le responsable de projet doit essayer, en accord avec le client, de combiner ces revues avec les revues RUP prévues. Cela est possible pour la revue de spécification logicielle (SRR) et la revue de conception préliminaire (PDR), qui peuvent être regroupées respectivement avec la revue du Jalon des objectifs de cycle de vie et la revue Architecture de cycle de vie.

Organisation du projet

Tout comme le processus logiciel, l'organisation du projet est également influencée par les caractéristiques du projet. La structure par défaut présentée ici (voir la figure ci-dessous) doit être adaptée pour refléter les effets des facteurs suivants :

  • Le contexte métier
  • L'ampleur de l'effort de développement logiciel
  • Le degré de nouveauté
  • Le type d'application
  • Le processus de développement actuel
  • Les facteurs liés à l'organisation
  • La complexité technique et de gestion

Il s'agit de facteurs clés pour l'analyse de la manière dont l'organisation doit adopter un nouveau processus de développement. Nous examinerons ici leur impact sur le choix de la structure du projet. La figure ci-dessous présente une organisation de projet par défaut, montrant comment les responsabilités sont affectées à la structure de l'équipe.

Diagramme contextuel montrant comment les responsabilités sont affectées aux membres de l'équipe.

Figure illustrant l'organisation de projet par défaut. Notez qu'aucune considération d'ancienneté ni de hiérarchie n'intervient dans l'ordre des rôles.

Cette figure constitue un point de départ pour indiquer comment les rôles et les responsabilités au niveau du projet doivent être mappés avec la structure des équipes. Cette figure montre également que les rôles (dans les cadres jaunes) ne correspondent pas à des personnes, mais à des "casquettes" qu'une personne (ou une équipe) peut porter dans le cadre du projet. C'est la raison pour laquelle certains rôles (comme celui de responsable de projet) apparaissent plusieurs fois. Cela signifie qu'à un moment donné, le comportement de responsable de projet tel qu'il a été défini dans le RUP peut apparaître dans plusieurs équipes. Par exemple, pour un projet d'une certaine envergure, la préparation d'un rapport d'état basé sur une structure de répartition du travail peut être confiée à une personne de l'équipe Administration. Toutefois, il s'agit d'une responsabilité que le RUP affecte au rôle appelé Responsable de projet.

En revanche, pour un projet plus petit, il est probable que la personne nommée responsable de projet effectuera toutes les tâches affectées au rôle appelé responsable de projet, auquel cas l'équipe Administration coïncide avec l'équipe Gestion logicielle. Le choix de la structure des équipes dépend de la nature et de l'ampleur du projet, mais doit également respecter quelques règles de bon sens :

  • Les petites équipes sont généralement plus productives ; toutefois, dans le cas d'un gros projet, il faut également tenir compte des interactions entre les équipes.
  • Il convient d'éviter les hiérarchies trop complexes.
  • Un manager ou un responsable d'équipe doit contrôler entre 5 et 9 personnes.
  • La structure des équipes de développement logiciel doit être élaborée en fonction de l'architecture logicielle : une bonne architecture, avec une cohésion élevée et un faible couplage entre les sous-systèmes, permet aux équipes de travailler plus efficacement en parallèle.
  • A l'exception du test d'unité, il est préférable que le test soit pris en charge par une équipe autre que l'équipe de développement. Toutefois, pour un tout petit projet, cela peut ne pas être judicieux d'un point de vue économique.
  • La structure doit donner à chaque équipe et à chaque personne des responsabilités clairement définies. Cela est particulièrement important si la hiérarchie comporte plus de trois niveaux. En effet, les managers et les responsables d'équipe qui se situent au milieu de telles structures doivent comprendre ce que l'on attend d'eux en termes de tâches techniques et d'encadrement.
  • La structure doit être adaptée aux capacités, à l'expérience et aux motivations de l'équipe : par exemple, si une même équipe est censée assurer l'analyse, la conception et l'implémentation sans aucune aide extérieure, ses membres devront présenter toutes les compétences nécessaires. Un analyste confirmé ne fait pas forcément un bon implémenteur.
  • La structure des équipes ne doit pas être rigide. Certaines personnes peuvent passer d'une équipe à une autre en cours de projet, et les responsabilités des équipes peuvent évoluer de phase en phase.

Le raisonnement qui a conduit à l'élaboration de l'organisation par défaut est expliqué en détail dans [ROY98]. Notamment, l'attribution des responsabilités de déploiement à l'équipe chargée de l'évaluation du logiciel suppose que, parmi toutes les équipes du projet de développement, cette équipe est celle qui est capable de mieux appréhender le logiciel tel que l'utilisateur le percevra.

Au cours du déroulement du projet, l'organisation est amenée à évoluer pour s'adapter à la structure de répartition du travail indiquée dans le planning de projet. Cela est illustré dans la figure ci-dessous, tirée de [ROY98].

Diagramme montrant l'évolution de l'équipe sur le cycle de vie du projet.

Cette évolution montre que chaque phase s'intéresse plus particulièrement à un ensemble de tâches différent :

  • L'équipe de création : une organisation qui se concentre sur la planification, avec l'aide des autres équipes pour s'assurer que les plans représentent bien tous les points de vue ;
  • L'équipe d'élaboration : une organisation qui se concentre sur l'architecture, dont le coeur est constitué de l'équipe d'architecture logicielle, assistée des équipes de développement logiciel et d'évaluation du logiciel afin d'obtenir une référence d'architecture stable ;
  • L'équipe de construction : une organisation équilibrée, dont la plupart des tâches incombe aux équipes de développement logiciel et d'évaluation du logiciel ;
  • L'équipe de transition : une organisation centrée sur le client, dont les tâches de déploiement sont étroitement liées aux retours des utilisateurs.

Le passage de certains intervenants d'une équipe à une autre au fil de l'évolution du projet garantit la pérennité des connaissances et des compétences. Par exemple, une fois l'élaboration terminée, certains membres de l'équipe d'architecture peuvent rejoindre les équipes de développement, éventuellement en tant que responsables d'équipe, ou afin de veiller à ce que la 'vision' architecturale soit respectée au cours du développement. Ensuite, vers la fin de la phase de construction, l'équipe d'évaluation entre en scène, et une partie de l'équipe de développement passe dans l'équipe d'évaluation. A ce stade, il est important de ne pas perdre de vue l'intégrité architecturale dans le feu du développement, et que l'influence de l'équipe d'architecture ne décline pas au fur et à mesure que le projet évolue. Le passage de certains membres de l'équipe d'architecture dans l'équipe d'évaluation peut permettre de répondre à cette exigence.