Une des questions qui tracasse régulièrement les responsables d'équipe informatique concerne l'évaluation juste des délais, des charges et des couts d'un projet ou d'une maintenance.

C’est une question importante car elle conditionne la réalisation ou non d’un besoin exprimé par les utilisateurs à un instant T. Ainsi, les méthodes d’évaluation des charges aident à apprécier non seulement la charge, mais aussi le temps nécessaire à la réalisation du projet avec la taille de l’équipe à affecter.

En effet pour pouvoir répondre aux questions la fin du projet c’est pour quand? Combien çà va couter? Il faut pouvoir déterminer le plus précisément possible la charge nécessaire pour réaliser les développements.

Les estimations de charges sont demandés par :

• le chef de projet à ses développeurs sur leur périmètre respectifs,
• le directeur de projet à son chef de projet qui a, au préalable consolidé les différentes charges transmises par les développeurs
• Le chef de projet ou le directeur de projet vont défendre cette charge  auprès soit de la DSI soit de la direction opérationnelle.

Si la charge est acceptée alors les développements peuvent être planifiés, sinon il faut revoir sa copie en proposant plusieurs hypothèses.

Alors comment estimer la charge d’un développement ?

Il faut s’appuyer sur un abaque qui permet d’établir selon la complexité du développement à faire le temps nécessaire à sa réalisation.

La méthodologie que j’ai souvent utilisée sur les projets  est la suivante :

Étape 1 : Je fais établir une cartographie des applications, l’objectif étant d’établir une hiérarchie selon la complexité des traitements.  La cartographie doit aboutir à une valorisation du tableau ci-dessous :

 

Application

Description du traitement

Niveau stratégique(1)

Fréquence d’utilisation(2)

Complexité fonctionnelle ou technique (3)

Documentation (6)

Caractère évolutif (4)

Sensibilité

 

Application1

Éteint les PC des collaborateurs chaque nuit

1

3

1

2

1

1

 

 

 

 

 

 

 

 

3 : Élevé    2 : Moyen  1 : faible

 

Étape 2 : J’établis une typologie des programmes que je classe par difficultés croissantes, de simple à complexe voir hors normes. En m’appuyant sur l’expertise des développeurs qui est indispensable, je décris précisément ce qui est considéré comme un traitement simple, moyen et complexe.

Exemple concret ci-dessous :

 

 

Type

Batch

TP

Nature

Simple

►  1 programme :
►  1 fichier en entrée
►  1 fichier en sortie
►   mise à jour données (0 à 2 tables)

►  1 écran d'affichage
Nb de composant <=20
Nb de relations (influences) entre composant <=10
Complexité du menu : nb fonctions, nb shells à appeler <= 5
Nb de shells inclus/impactés (via menu, etc.) <= 1
►  Sans MAJ
►  1 ou 2 évenements par contrôle

Moyen

►          1 programme
►  Plus d’1 fichier/table en E/S
►  Contrôles « croisés » multi-tables
►  Mise à jour de plus de 2 Tables

►          1 écran avec interaction (entre les contrôles) sans MAJ ou n écrans sans MAJ
Nb de composant de 21 à 50.
Nb de relations (influences) entre composant de 11 à 30
Complexité du menu : nb fonctions, nb shells à appeler de 6 à 9
Nb de shells inclus/impactés (via menu, etc.)  < 5

Complexe

►  1 programme  moyen
►  Cas fonctionnels multiples
►  Plus d’2 fichiers/tables en E/S
►  Mise à jour de plus de 5 Tables

  ►  1 écran avec MAJ (Affichage et tables) ou n écrans avec MAJ
Nb de composant  > 51
Nb de relations (influences) entre composant  > 31
Complexité du menu : nb fonctions, nb shells à appeler  > 10
Nb de shells inclus/impactés (via menu, etc.)  > 5

  ►  2 à m

Etape 3 : Ensuite, pour chaque typologie de programme, toujours avec l’aide des développeurs expérimentés, il faut déterminer le temps nécessaire pour réaliser les différents programmes avec les tests unitaires.  L’unité de mesure étant la journée de travail => 0,5 j pour une ½ journée. Ci-dessous un exemple.

 

 

 

 

Complexité
de
la demande

 

Modification de
programmes

Nombre de programmes

Création / réécriture
 de programmes

Nombre de
programmes

Charge
cumulée

Facteur **
correcteur

Charge
Estimée

simple

0,50

 1

0,75

1 

0

 

1,25

moyen

1,00

 

1,50

 

0

 

0

Complexe

3,25

 

4,88

 

0

 

0

Hors Normes*

 

 

 

 

 

 

 

simple

1,00

 

1,00

 

0

 

0

moyen

2,00

 

3,50

 

0

 

0

Complexe

6,00

 

11,00

 

0

 

0

Hors Normes*

 

 

 

 

 

 

 

simple

0,50

 

0,50

 

0

 

0

moyen

2,0

 

2,50

 

0

 

0

Complexe

3,5

 

6,00

 

0

 

0

Hors Normes*

 

 

 

 

 

 

 

L’avant dernière colonne désigne le facteur correcteur ** = [ajustement de la valeur calculée, à justifier dans les commentaires (valeur 1 par défaut)]. Peut concerner la réutilisabilité des développements ;  la valeur par défaut est 1, une valeur inférieure indique un gain de productivité. Une valeur supérieure traduit une complexité particulière.

 

Étape 4 : Chaque activité pour la réalisation complète du projet est ensuite estimée avec une règle de calcul qui est soit basé sur le ratio du temps de développement et TU, soit sur une charge fixe.

Ci-dessous un exemple :

  

Ensemble des activités  Formule de calcul Charge Calcul         * Développement et tests unitaires (TU) jour/homme (X) 100% 2 Etablissement de la proposition % charge de dév + TU* 10,00% 0,2 Encadrement équipe % charge de dév + TU 15,00% 0,3 Analyse technique détaillée % charge de dév + TU 15,00% 0,3 Documentation % charge de dév + TU 10,00% 0,2 Test de vérification et de non régression % charge de dév + TU 50,00% 1 Livraison et assistance sur recette % charge de dév + TU 15,00% 0,3 Livraison et mise en production % charge de dév + TU 10,00% 0,2 Total   225,00% 4,5   * TU = tests unitaires   Quelques règles à retenir

• Pour faire une bonne estimation de charge d’un projet, il est nécessaire d’y consacrer le temps nécessaire pour bien passer en revu les différentes hypothèses.  Votre projet à tout à y gagner.

• Il faut capitaliser sur les estimations réalisées sur les projets passés. Elles vous serviront pour les projets à venir.

• Il est important de s’appuyer sur l’expérience des développeurs expérimentés.

• A la fin du projet faite la comparaison entre les charges estimés pour la réalisation du projet et  les charges réelles.

• Après 1 an d’expérience, réajuster les abaques si besoin.

 

 

Annexe :

 

(1) Niveau stratégique :

·       élevé : si utilisateur bloqué en cas d’incident

·       moyen : si incident majeur

·       faible : si incident mineur, possibilité de contournement

(2) Fréquence d’utilisation :

·       élevé : [minimum hebdomadaire [

·       moyen : [hebdomadaire - mensuel[

·       faible : [mensuel et au delà [

(3) Complexité fonctionnelle ou technique :

·       élevé : si temps nécessaire à sa compréhension très important (>4 heures)

·       moyen : si temps nécessaire à sa compréhension important (>2 heures)

·       faible : si temps nécessaire à sa compréhension peut important (<2 heures)

 

(6)  Documentation

·       Bien documenté

·       Moyennement documenté

·       Peu documenté

(4) Caractère évolutif :

·       élevé : si le traitement évolue plus d’une fois par an

·       moyen : si le traitement évolue une fois par an

·       faible : si le traitement évolue moins d’une fois par an