L’évaluation de la charge d’un projet : utilisation d’un abaque

Evaluation de la charge d'un projet

Evaluation de la charge d’un projet

Exemple d’abaque pour un projet de développement informatique : Abaque

Pour évaluer la charge d’un projet, on peut utiliser beaucoup de méthodes différentes plus ou moins normalisées. Parmi ces méthodes, on trouve l’utilisation d’un abaque.

Mais qu’est-ce qu’un abaque et comment l’utiliser ?

Dans le cadre de cet article, je vais me baser baser sur l’exemple d’un abaque générique utilisable pour un projet de développement d’un logiciel informatique standard pour vous expliquer comment s’utilise un abaque.

Cet abaque d’évaluation de charges est composé de deux parties :

  • Une partie permettant d’évaluer les charges directement liées aux développements,
  • Une partie permettant d’évaluer l’ensemble des charges liées à la gestion des développements (analyse, documentation, tests, etc.).

Au niveau de l’évaluation des charges, celle-ci se fait en suivant une approche fonctionnelle métier. Chaque application est découpée en fonctions métier et chaque fonction métier est évaluée suivant une grille d’évaluation des charges qui est élaborée en commun entre l’équipe projet et le client. Les fonctions techniques, qui servent de support aux fonctions métier comme, par exemple, une fonction de mise en page avant impression, sont aussi évaluées à l’aide de la même grille.

La grille (l’abaque) d’évaluation des charges utilise une répartition des développements dans 5 catégories :

CatégorieDescription
IHMReprésente l’ensemble des développements associés aux interfaces homme-machine et plus précisément à la partie présentation (les écrans généralement).
Correspond à la partie « Vue » dans un modèle classique de type « MVC » (Modèle – Vue – Contrôleur).
ServicesReprésente l’ensemble des développements associés au traitement des interactions au niveau des IHM.
Correspond à la partie « Contrôleur » dans un modèle classique de type « MVC » (Modèle – Vue – Contrôleur).
BatchReprésente l’ensemble des développements associés à des traitements s’effectuant sans interaction avec l’utilisateur comme, par exemple, un calcul journalier de valorisation du contenu d’un entrepôt.
DonnéesReprésente l’ensemble des développements associés à l’accès et à la manipulation des données. Cette catégorie comprend aussi l’ensemble des développements associés aux objets métiers qui peuvent être développés dans le cadre d’une application.
MessagesReprésente l’ensemble des développements associés aux échanges de messages, d’informations, avec d’autres applications et/ou d’autres systèmes externes (imprimantes, fax, etc.).

A chaque catégorie, on associe une charge standard (en jours/homme) qui est définie en fonction de trois niveaux de complexité : simple, moyen et complexe. Si possible, celle-ci doit aussi tenir compte des compétences et du niveau des personnes composant l’équipe projet. Ceci permet de définir des coefficients de charges globaux qui seront appliqués à l’ensemble des développements.

Par défaut, les charges standards sont définies comme suit :

Coefficients à appliquer pour l’évaluation des charges SimpleMoyenComplexe
IHM0,51,02,0
Services0,51,02,0
Batch0,51,02,0
Données0,51,02,0
Messages0,51,02,0

Les différentes charges définies dans ce tableau reprennent, de manière globale, l’ensemble des tâches élémentaires suivantes :

  • Développement : correspond au codage de la fonction.
  • Tests unitaires : réalisation des tests unitaires associés à l’ensemble des développements effectués.
  • Documentation technique : Réalisation de la documentation technique associée aux développements effectués.
  • Documentation fonctionnelle / utilisateur : réalisation de la documentation fonctionnelle ou utilisateur associé aux développements effectués.
  • Administration de données : ensemble de tâches associées à l’accès et à la gestion des données nécessaires à la réalisation des développements.

Pour chaque catégorie, les critères utilisés pour différencier les différents niveaux de complexité sont les suivants :

NiveauCritères
Simple• Affichage de moins de 10 composants d’IHM à l’écran (y compris des images).
• Pas de tableau
• Pas de zone graphique.
• Que des contrôles standards.
• Pas de procédures de validation intégrées dans l’IHM.
Moyen• Affichage d’un maximum de 20 composants d’IHM à l’écran (y compris des images).
• Possède au maximum 1 tableau.
• Pas de zone graphique.
• Que des contrôles standards.
• Existence éventuelle de procédures de validation simples intégrées dans l’IHM
Complexe• Possède éventuellement des contrôles non standards.
• Existence éventuelle de procédures de validation complexes intégrées dans l’IHM
NiveauCritères
Simple• Traitement avec un maximum de 2 structures conditionnelles.
• Règles de traitement simples.
• Moins de 10 « opérations élémentaires » différentes.
Moyen• Traitement un maximum de 4 structures conditionnelles.
• Règles de traitement simples.
• Moins de « 20 opérations élémentaires » différentes.
Complexe• Traitement avec plus de 4 structures conditionnelles.
• Règles de traitement complexes.
NiveauCritères
Simple• Traitement avec un maximum de 2 structures conditionnelles.
• Règles de traitement simples.
• Moins de 10 « opérations élémentaires » différentes.
Moyen• Traitement un maximum de 4 structures conditionnelles.
• Règles de traitement simples.
• Moins de « 20 opérations élémentaires » différentes.
Complexe• Traitement avec plus de 4 structures conditionnelles.
• Règles de traitement complexes.
NiveauCritères
Simple• Accès à une seule table de données ou à une seule vue avec, au maximum, une douzaine d’attributs.
• Pas de gestion de transaction.
Moyen• Accès à plusieurs tables de données en lecture seule avec utilisation de clés étrangères.
• Pas de gestion de transaction.
Complexe• Accès à plusieurs tables de données en ajout, modification ou suppression avec utilisation de clés étrangères et gestion de l’intégrité référentielle.
• Utilisation possible de triggers.
• Utilisation de procédures stockées.
• Gestion de transactions.
NiveauCritères
Simple• Envoi/création d’un message au format Text ou Mail.
• Envoi/création d’un message au format XML sans mise en forme préalable.
• Envoi/création d’un rapport du type liste avec des restrictions simples et un ou deux champs cumulés.
• Pas de gestion d’accusé de réception.
Moyen• Envoi/création d’un message au format XML avec mise en forme préalable.
• Envoi/création d’un message avec formatage des données.
• Envoi/création d’un rapport avec plusieurs niveaux de rupture et utilisation de jointures.
• Pas de gestion d’accusé de réception.
Complexe• Envoi/création d’un message au format PDF.
• Envoi/création d’un rapport avec de multiples ruptures, jointures, restrictions et calculs.
• Gestion d’un accusé de réception.

Une fois les coefficients définis, l’évaluation des charges de chaque fonction métier se fait à l’aide d’un tableau global d’évaluation des charges qui est spécifique à chaque type d’application et à chaque application.

Evaluation des fonctions d'une application à l'aide de l'abaque

Evaluation des fonctions d’une application à l’aide de l’abaque

Dans ce tableau, chaque application est découpée jusqu’à obtenir des fonctions élémentaires qui seront regroupées, par la suite, en ensembles logiques du point de vue fonctionnel. Ceci permet d’obtenir, pour chaque fonction, l’effort total nécessaire pour le développement de la fonction.

Une fois l’estimation de la charge de développement effectuée, celle-ci est reportée dans un tableau global d’estimation des charges totales associées à la réalisation du projet comprenant l’ensemble des tâches du projet.

Dans ce tableau, un projet est découpé en 6 phases distinctes comportant chacune un ensemble de tâches.

PhaseDescription
Gestion de projetComprend l’ensemble des tâches de management associées à la coordination du projet (réunions, suivi des plannings, etc.).
Ces tâches sont principalement réalisées par le directeur de projet et/ou le chef de projet.
Phase 1 :
Initialisation du projet
Correspond à la phase d’initialisation du projet. Dans cette phase, l’équipe projet réalise l’ensemble des activités nécessaires à la bonne réalisation technique du projet (installation des postes de développement, installation des serveurs, etc.).
Phase 2 :
Conception et
Maquettage
Correspond à l’ensemble des tâches associées à la conception globale de l’application : réalisation des cahiers des charges et modélisation. Comprend aussi l’ensemble des tâches associées à la création des plans de test ainsi que les tâches associées au maquettage des IHM.
Phase 3 :
Développement
Correspond à l’ensemble des tâches associées au développement de l’application et qui ont été évaluée à l’aide du tableau présenté précédemment.
Phase 4 :
Tests d’intégration
Correspond à l’ensemble des tâches associées à l’intégration de l’ensemble des développements ainsi qu’à l’intégration du projet dans l’environnement applicatif existant.
Phase 5 :
Formation et recette
Correspond à l’ensemble des tâches associées à la recette applicative de l’application par les utilisateurs ainsi qu’à la formation des utilisateurs avant mise en production de l’application.
Phase 6 :
Mise en production
Correspond à l’ensemble des tâches associées à la mise en production et en exploitation de l’application.

Un exemple d’utilisation de ce tableau, pour un projet, est donné ci-dessous.

Evaluation de la charge d'un projet dans l'abaque

Evaluation de la charge d’un projet dans l’abaque

Dans le tableau d’évaluation globale des charges du projet, tous les calculs s’effectuent automatiquement en prenant comme base l’évaluation des charges de développement définie au niveau de chaque fonction.

Dans le cadre d’une prestation de type projet au forfait, la répartition des différentes charges affectées à chaque tâche devra, généralement, être validée entre l’équipe projet et le client.

La rubrique provisions/réserves permet de prendre en compte, de manière simplifiée, les incertitudes qui peuvent être associées à la réalisation du projet. Ainsi, si vous êtes sûr et certain de votre évaluation, la valeur de cette rubrique pourra être égale à 0 %. Si par contre, vous manquez de certitudes, cette valeur ne devra pas être laissée à zéro mais représenter votre niveau d’incertitude. De manière standard, je vous conseille, dans vos premiers projets, de prendre une marge d’incertitude autour de 20 %.

Chaque typologie de projet pouvant avoir des contraintes différentes, il sera aussi possible d’établir des répartitions de charges différentes en fonction de chaque typologie de projet (application lourde, application web, maintenance évolutive, etc.) :

Exemples d'adaptations de l'abaque suivant la nature du projet

Exemples d’adaptations de l’abaque suivant la nature du projet

Ce contenu a été publié dans Evaluation, avec comme mot(s)-clé(s) , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *