- Estimation des charges de codage -

Les phases suivantes du développement (codage et intégration) représentent un gros travail qui va mettre en œuvre des ressources humaines importantes. Il est utile à ce stade de la démarche de réaliser une estimation quantitative de la masse de travail qu'elles représentent afin d'une part de prévoir les ressources humaines nécessaires, d'autre part de réajuster éventuellement le planning prévisionnel défini dans le plan de développement lors de la conception globale.

La masse de travail pour le codage et l'intégration d'un prototype augmente en fonction :

• du nombre et de la complexité des fenêtres ou des pages Web,
• de la complexité des méthodes,
• du nombre et de la structure des classes persistantes,
• du nombre et de la complexité des états imprimés à produire,
• de la variété des états des objets.

Elle diminue en fonction :

• de la qualité des informations recueillies lors de l'enquête auprès des utilisateurs,
• du respect de la méthode de conception,
• du soin avec lequel les modèles ont été construits,
• de l'existence de composants logiciels réutilisables pouvant être mis en œuvre,
• du degré d'adéquation de ces composants aux besoins.

La plupart de ces éléments sont difficile voire impossible à estimer. Par exemple, comment juger du degré de précision des informations recueillies auprès des utilisateurs ? De façon générale on peut estimer qu'il n'est jamais suffisant compte tenu de la durée presque toujours réduite des enquêtes réalisées.

De la même façon il est souvent impossible de savoir si un composant logiciel va bien cibler les besoins avant de l'avoir réellement mis en œuvre. De plus, chaque composant peut nécessiter une phase supplémentaire d'intégration.

Traitements interactifs

De façon très générale, nous pouvons estimer que 50% de la durée de développement d'un logiciel interactif est consacrée au codage de son IHM. Par voie de conséquence nous allons estimer la durée de codage de l'IHM et obtenir le temps de codage global en doublant simplement cette durée.

L'estimation du temps de codage de l'IHM se fera en utilisant le SEF ou le SEP qui, s'il a été construit dans les règles, contient toutes les fenêtres ou pages Web à mettre en œuvre dans le projet. Nous allons prendre ici l'exemple du SEF sachant que le raisonnement développé sera identique dans le cas d'une IHM de type Web. Nous devons estimer quel est le degré de complexité de chaque fenêtre du SEF. Pour simplifier nous retiendrons trois catégories de fenêtres :

• les fenêtres simples : fenêtres primaires (sans région client), boîtes de message et boîtes de dialogue simples (sans dessin)
• les fenêtres de complexité moyenne : boîtes de dialogue avec dessin comportant environ une vingtaine de contrôles actifs.
• Les fenêtres complexes : boîtes de dialogue avec dessin comportant plus de 20 contrôles actifs, fenêtres primaires et secondaires avec une région client graphique.

Les durées moyennes estimées pour le codage de chacune de ces fenêtres sont les suivantes :

• Fenêtres simples : une demi-journée/homme
• Fenêtres moyennes : de deux à trois journées/homme
• Fenêtres complexes : 4 à 10 journées/homme

Il faudra également estimer les charges de programmation des états imprimés en fonction de la complexité de l'état (de 1 à 10 journées/homme).

A la valeur obtenue nous rajouterons environ 50% pour le codage du premier prototype qui est toujours plus long à développer car il permet d'essuyer les plâtres c'est-à-dire de découvrir la plupart des problèmes.

En appliquant ces critères nous pouvons estimer la charge de codage de chaque prototype du cas d'école Assurance-Auto.

Prototype 1

• Fenêtres simples : FP-AssurAuto, BD-Catégories, BD-TypesContrats, BD-Paiement (1/2 journée pour chacune)
• Fenêtres moyennes : BD-Contrats (2j), BD-DétailContrat (3j), BD DétailVéhicule (2j)
• Fenêtres complexes : Aucune

Total IHM : 2j + 7j = 9 jours .

Total pour le prototype 1 : 9 x 2 = 18j + 9j (premier prototype) = 27 jours

Prototype 2

• Fenêtres simples : BD-Compagnies, BD-VéhiculesImpliqués, BD-Remb, BD Dégats, BD-PartResp
• Fenêtres moyennes : BD-DétailCompagnie (2j), BD-DossiersAccidents (2j), BD-DétailTiersExt (2j)
• Fenêtres complexes : BD-DétailDossier (4j), BD-SaisieDossier(4j)
• Etats imprimés : StatsAccidents (2j), LettreChèqueExpert (2j), LettreChèqueAssuré (2j)

Total IHM : 2,5 + 6 + 8 + 6 = 22,5 jours

Total pour le prototype 2 : 22,5 j x 2 = 45 jours

Remarque : Cette estimation peut sembler bien large lorsqu'on est habitué à coder à l'aide d'outils de développement intégrés (Visual Editor, Visual Basic…) avec lesquels on peut réaliser une maquette en quelques heures. Les temps indiqués ici intègrent aussi le respect des normes de programmation en vigueur, les tests unitaires et d'intégration et la documentation (DRP, GIP, MUP).

Chaînes batch

Pour les chaînes batch, l'estimation de la durée de développement dépend du nombre et de la complexité des ULT à réaliser. Une ULT sera d'autant plus complexe qu'elle mettra en jeu beaucoup de fichiers et qu'elle produira des documents imprimés élaborés. Ici aussi, la maîtrise d'outils tels que des générateurs d'états de type Cristal Report peut diminuer sensiblement cette estimation.