L’état des lieux

L’évaluation de la charge d’un projet peut être confiée à l’analyste du métier, dans le cadre de son rôle d’assistant à la maîtrise d’ouvrage.

La question est de savoir si l’utilisation d’UML pour analyser et spécifier un produit a un impact sur la charge de travail et s’il existe des méthodes particulières d’évaluation des charges d’un tel projet.

Le sujet n’est pas de traiter globalement de l’évaluation des charges d’un projet, mais d’examiner en quoi l’évaluation des charges d’un projet conçu sous UML est spécifique.

Ainsi, après avoir présenté très succinctement différentes méthodes d’évaluation des charges, sera étudiée particulièrement la méthode Karner qui semble la plus adaptée à un projet UML.

Comment évaluer les charges

Il existe, indépendamment des méthodes d’analyse et de conception, plusieurs méthodes d’évaluation des charges. Les principales sont :

les méthodes dites « à dire d’expert », ou encore méthodes Delphi, qui formalisent l’intervention de plusieurs experts pour rendre un chiffrage global du projet ;
les méthodes de répartition proportionnelle, qui affectent des durées aux tâches du projet selon des proportionnalités issues de retours d’expérience ;
les méthodes basées sur les unités d’œuvre, qui consistent à appliquer la même loi de proportionnalité en fonction de la charge de travail (COCOMO, méthode analytique, points de fonction).

Les méthodes dites des points de fonction sont utilisables dans le cadre d’un projet UML.

Exemple de méthode de répartition proportionnelle

Il s’agit de répartir la charge globale du projet entre chaque phase. Le Rational Unified Process propose les ratios suivants (d’après Chantal Morley, Management d’un projet système d’information, Éditions Dunod) :

Étape	Charge
Opportunité	5 %
Élaboration	20 %
Construction	65 %
Transition	10 %

Tableau 1 : Répartition proportionnelle entre les phases du cycle RUP

Des cycles classiques en V possèdent également des abaques de proportionnalité :

Études préliminaires	3 %
Études préalables (analyse des besoins)	12 %
Conception générale (modélisation logique)	20 %
Conception détaillée (modélisation technique)	10 %
Réalisation, mise en œuvre	40 %
Tests et recettes	15 %

Tableau 2 : Répartitions proportionnelles entre les phases d’un cycle en V

Ces ratios ont été établis à partir de retours de projets, positifs ou négatifs, et représentent donc des valeurs statistiques relativement fiables qui en font de bonnes recommandations. On peut en tirer une première indication : si le cycle du projet est en V, la charge générée par la rédaction du CdCf (analyse des besoins) est quatre fois celle générée par la rédaction...

Le modèle COCOMO

Barry Boehm, chercheur en ingénierie logicielle (auteur en particulier du modèle de développement en spirale), a proposé le modèle COCOMO (COnstructive COst MOdel).

Boehm a dégagé des coefficients qui relient la charge consommée par la construction du logiciel à sa taille. La charge vaut :

C = a (KISL)^b

Où C est la charge en mois-homme, KISL (Kilo Instructions Source Livrées) le nombre de lignes de code livrées et testées (en milliers), a et b des paramètres dont la valeur dépend de la nature du projet.

Les formules qui en découlent sont (d’après Chantal Morley, op. cit.) :

Complexité du projet	Charge (mois-homme)	Délai
Simple	C = 2,4 (KISL) ^1,05	D = 2,5 C ^0,38
Moyen	C = 3 (KISL) ^1,12	D = 2,5 C ^0,35
Complexe	C = 3,6 (KISL) ^1,2	D = 2,5 C ^0,32

Tableau 3 : Formules de calcul de la charge et du délai selon COCOMO

Les délais sont exprimés en mois.

Ce modèle peut-il s’appliquer aux projets UML ? Cela paraît difficile dans la mesure où il faut auparavant évaluer le nombre de lignes de code du projet. Néanmoins, un croisement de ce modèle avec les chiffres réellement obtenus en fin de projet permet d’établir des abaques internes à l’entreprise qui pourront être réinvestis sur les projets futurs....

La méthode d’évaluation analytique

Les SSII sont fréquemment utilisatrices de cette méthode qui s’appuie sur la catégorisation des projets. Cette catégorisation est fonction de deux grandeurs : la complexité du projet, le type de composants à réaliser.

Chaque SSII a ses propres coefficients issus des projets qu’elle a menés.

La grille suivante est issue d’un projet exemple (le poids est issu d’une analyse de la difficulté à construire des composants, analyse fondée sur des projets antérieurs) :

Complexité	Facile			Moyen			Difficile
Composants	Nombre	Poids	Charge	Nombre	Poids	Charge	Nombre	Poids	Charge
IHM	4	0,25	2	12	0,5	6	5	1	5
Accès aux données	9	0,1	0,9	4	0,25	2	8	0,5	4
Modules PHP	8	0,5	4	16	2,5	40	7	3	21
TOTAUX			6,9			48			30
TOTAL POIDS DE CHARGE									84,9

Tableau 4 : Calcul du poids de la charge d’un projet, composant par composant

Le poids total de la charge est ensuite converti en J/H.

Ce travail d’évaluation ne peut être mené que lorsque l’analyse du projet a déjà bien avancé. On peut relativement facilement transférer cette méthode d’évaluation de la charge à un projet utilisant UML. Les composants seront les composants de conception logiques et techniques identifiés au sens UML.

Il n’est pas du ressort de cet ouvrage...

La méthode des points de fonction

Il s’agit de mesurer la taille fonctionnelle, c’est-à-dire la richesse des fonctions à réaliser. L’intérêt de cette méthode réside dans le fait qu’elle reflète bien la richesse fonctionnelle du produit attendu. Elle traduit bien en charge de réalisation les services rendus à l’utilisateur.

Les services peuvent être (d’après Jacques Printz et al., Coûts et durée des projets informatiques, Hermès-Lavoisier) :

l’entrée et la mise à jour de données par l’application ;
la restitution de données issues de traitements ;
l’interrogation des données maintenues par l’application ;
l’importation ou l’exportation de données en dehors du périmètre de l’application (son interfaçage).

Il en existe plusieurs versions. La première fut mise en œuvre par un ingénieur d’IBM, Allan Albrecht, en 1979.

La méthode des points de fonction a été transférée dans le monde UML : c’est dans le cadre de l’estimation des charges d’un projet UML qu’elle va être étudiée plus en détail.

L’évaluation de la charge d’un projet UML : la méthode Karner

Gustav Karner (1993) s’est inspiré de la méthode des points de fonction pour évaluer la taille d’un produit logiciel, et donc sa charge de réalisation, en s’appuyant sur la spécification des cas d’utilisation. Cette méthode est également connue sous le nom de use case points (UCP).

Cette méthode comprend les étapes de calcul :

détermination du poids non ajusté des acteurs ;
déterminiation du poids non ajusté des cas d’utilisation ;
calcul du nombre de points brut des cas d’utilisation ;
calcul du nombre de points ajusté des cas d’utilisation ;
évaluation et ventilation de la charge.

1. La détermination du poids non ajusté des acteurs

La méthode reconnaît trois types d’acteurs ayant chacun leur poids brut. Cette classification reflète la manière dont ils interagissent avec le système :

Classification	Caractéristiques intrinsèques des acteurs	Poids
Simple	Interaction via une API (acteur = autre système)	1
Moyen	Interaction via un protocole (TCP/IP, http, FTP)	2
Complexe	Interaction via une interface graphique (acteur = humain)	3

Tableau 5 : Évaluation du poids brut (non ajusté) de l’acteur d’un CU

La méthode ne précise pas comment ce poids chiffré a été établi.

2. La détermination du poids non ajusté des cas d’utilisation

La classification des CU repose sur le nombre d’interactions qu’ils supportent, tous scénarios confondus (nominal, exceptions, extensions). On n’inclut pas les transactions des CU inclus, étendus, dérivés.

On retrouve trois catégories :

Classification	Nombre d’interactions exécutées au cours du CU	Poids
Simple	Nombre de transactions inférieur ou égal à 3	5
Moyen	Nombre de transactions compris entre 4 et 7	10
Complexe	Nombre de transactions supérieur ou égal à 8	15

Tableau 6 : Détermination du poids non ajusté des cas d’utilisation

Une interaction est un échange entre l’acteur et le système. C’est une ligne de traitement décrite dans la spécification...

Pour aller plus loin

Les ouvrages récents traitant de l’évaluation des charges des projets UML sont rares. Cette tâche se veut décorrélée de la technique et des choix faits par la maîtrise d’œuvre. L’intérêt d’UML réside (cela a déjà été décrit) aussi en la définition d’unités de pilotage : les cas d’utilisation. De fait, ce sont des unités d’œuvre. Évaluer la charge de construction en évaluant la charge CU après CU est un excellent moyen de mettre à profit cette modularité des services offerts par le futur applicatif.

On pourra se reporter au didacticiel de Sparx, à l’article « Use Case Points » de Cristian Remon et Pablo Javier Thomas (2010) accessible sur le portail ResearchGate (https://www.researchgate.net/publication/220018983).

Conclusion

L’évaluation de la charge d’un projet est délicate et risquée :

délicate car elle implique fortement l’expérience personnelle de l’évaluateur ;
risquée car les résultats effraient souvent le management, qui préfère des plannings rassurants, quitte à ce qu’ils ne soient pas tenus.

Elle concerne l’analyste du métier, dans la mesure où il assiste la maîtrise d’ouvrage. Le fait qu’il ait un outil permettant, de concert avec l’équipe technique, d’évaluer les impacts sur le projet de ses spécifications est un facteur important de cohésion et de compréhension.

On peut comparer les facteurs de réussite des projets (voir chapitre Ingenierie de l’analyse du métier, section Pourquoi l’analyse du métier ? - Les facteurs de réussite des projets) avec les facteurs de complexité et d’environnement selon Karner ; par exemple, l’implication des utilisateurs (citée dans 16 % des cas comme facteur de réussite) est un facteur de risque environnemental (utilisateurs non impliqués) réparti entre l’implication de la hiérarchie (poids 1) et la confiance des utilisateurs en la bonne fin du projet (poids 0,5).

À l’inverse, il semblerait que Karner cite davantage de risques techniques...

Évaluation des charges d'un projet spécifié en UML