Estimation des charges des projets informatique (2/3)

(Voir le premier chapitre de cet Article)

Avant de présenter ma méthode d’estimation des charges, et pour ceux qui ne sont pas familier du tout avec ces techniques vous pouvez lire ce résumé intéressant en préambule. Il présente les différents principes et types de méthodes :

http://bertrand.guerard.free.fr/....


Trois principes importants sont à prendre en compte pour construire une méthode d’estimation des charges agile et mature:

     -La précision de l’estimation est évidement directement liée à la
     connaissance des éléments du projet (Exigences, Architecture,
     spécifications fonctionnelles,..)

     -Les charges du projet sont directement liées au cycle
     de vie choisie qui comprend des activités très différentes.

     -Il ne pourra y avoir de bonnes estimations sans capitalisation.


Premier principe : Précision de l’estimation.

Ci-dessous un graphique présentant un ordre de grandeur de la précision des estimations en fonction du moment où elles sont faites durant le projet.
Dans ce graphique je fais volontairement ressortir trois moments clefs.


(cliquer pour voir en grand)


1) La fin de l’analyse de faisabilité « La pré-estimation »:

     Evidemment, moment stratégique puisque que l’estimation sera l’élément principal dans la décision de lancer effectivement le projet ou pas. Mais moment très en amont du projet ou les techniques d’estimation basées sur une connaissance fine de la solution seront difficilement applicable.

     Parlons, pour illustrer ce point de la méthode certainement la plus connue (Qui fera l’objet d’un article à part pour la présenter) : Les points de fonctions. Elle est très intéressante mais comment l’utiliser à ce moment t du projet puisque qu’elle nécessite de connaître assez finement l’architecture des données (Tables, fichiers) et des traitements (Entrée, sortie, interrogation).

2) La finalisation de l’architecture fonctionnelle et technique « L’estimation Initiale ».

     Moment important et où l’on peut grâce à vue cohérente de l’ensemble de la solution ajuster la « pré estimation » et le planning. A partir de ce moment l’utilisation de méthodes comme les « points de fonctions » sera possible.

3) La réalisation des spécifications détaillées « L’estimation détaillée ».

     C’est le moment où l’on connait le mieux ce que l’on va faire en terme de production (Configuration, paramétrage, développement) sans avoir encore engagé une bonne partie de la dépense (Retenons l’ordre de grandeur très approximatif que la partie développement représente environ 50% de la charge totale).

     De plus c’est un moment idéal dans le cas de travail en mode centre de service / Centre de développement / Near shore / Offshore , pour cadrer au forfait le budget et les délais des demandes de travaux.
En conclusion de ce principe, il faut donc construire une méthode d’estimation suffisamment agile pour être utilisée dès l’analyse de faisabilité sur des données encore très générales.

     Cela sera rendu possible dans la méthode que je propose pour la création d’une base de modèles analytique(Templates).


Second principe : Cycle de vie et activités d’un projet

     Le pré requis de l’estimation est un découpage du projet en une liste de tâches part types, qui vient d’une déclinaison du cycle de vie du projet.

     La liste de tâche est souvent appelé SDP (Structure découpage projet) ou WBS (Work Breakdown structure) , ci-dessous deux liens pour une brève présentation de ce concept.

http://en.wikipedia.org/wiki/Work_breakdown_structure

http://www.management-projet.org/projet1/spip.php?article59

     On trouvera dans une SDP/WBS les activités d’architecture, de spécification, de suivi de projet et bien sûr le développement (Paramétrage/ Configuration).

     L’idéal pourrait être alors de définir pour chaque type de tâches des paramètres et une méthode particulière mais cela serait évidemment trop complexe à gérer.

     La méthode des points de fonctions part de l’hypothèse que la charge globale des activités autre que le développement est proportionnelle et donc que le facteur de productivité qui calcule la charge (Charge=Taille*Productivité) à partir de la taille (Nbre de Pts de fonctions, Nbre de lignes de codes,…) englobe toutes les charges des autres activités.

     Cela présente pour moi l’inconvénient de masquer dans une charge globale des profils (donc des coûts) très différents (Gestion de projet, Testeurs,…) et il faudra bien tôt ou tard éclater cette charge pour faire un planning par ressources.

     Gardons donc l’idée de la proportionnalité mais en pouvant différencier des coefficients en fonction du type d’activité dans le cycle de vie.


Troisième principe : La capitalisation

     La valeur d’un coefficient de productivité, d’un coefficient de proportionnalité (Par exemple : Développement / Tests) pourra bien sûr être initialisé à des valeurs très moyennes au départ mais en étant rigoureux dans le suivi des charges réelles il sera facile en fin de projet de calculer des valeurs réelles de ces coefficients.

     Ces valeurs serviront aux projets suivants et refléteront mieux les caractéristiques de sa propre équipe projet.
Il faut donc suffisamment outiller la méthode d’estimation pour pouvoir comparer facilement l’estimation et la réalité et pouvoir facilement affiner successivement les modèles, la productivité et les coefficients (Développement/Autres activités).


(cliquer pour voir en grand)


     Pour terminer ce deuxième article sur l’estimation je vais insister à nouveau sur l’importance du « cycle de vie ». En effet si vous n’êtes pas capable au sein de votre équipe/organisation de formaliser un ou des cycles de vie standards qui se répètent, il vous sera difficile de poser des jalons stables pour la mise ne place d’une gestion de projet agile et mature.

     Ci-dessous une représentation que je propose pour les systèmes d’informations qui peut servir à la création de cycles de vie standards, un projet étant alors la suite d’activités faisant passer d’un état A à un état B le système d’information.

(cliquer pour voir en grand)


     Cette représentation étant aussi la base de la méthode d’estimation que je continuerais à présenter dans le dernier article de ce sujet.
L’élément central de cette représentation est appelé UP : « Unité de processus », c’est le plus petit élément indépendant du processus utilisateur. L’indépendance étant caractérisée par le fait qu’il peut s’exécuter de manière autonome. Une UP étant réalisé par le développement/Paramétrage/Configuration de composants (CP).

Exemple : Dans un système de gestion d’une base client, des « Unité de processus » seraient :

     -Création d’un client.
     -Modification d’un client.
     -Archivage d’un client...