Principes d' Evaluation

La réelle difficulté que rencontre le pilote de projet n’est pas la planification, car cette activité est depuis longtemps prise en charge par de nombreux outils, mais le recensement des composants de l’application et l’évaluation de l’engagement nécessaire à la réalisation.

En matière d’évaluation, la seule démarche réellement comprise par le développeur ou le pilote de projet se fonde sur leur vision naturelle de l’application à un instant donné.

Premièrement, cette vision s’exprime par une métrique calculée à partir d’un recensement des composants à produire (tables, écrans, rapports, interfaces) en prenant en compte leur différence de complexité.

Deuxièmement, l’estimation s’affine par la prise en compte de critères de performance, en fonction de l’environnement méthodologique, technologique et organisationnel ainsi que des ressources affectées au projet.

Pour l’historique du sujet, citons les travaux de Boehm et de Rayleigh qui sont à l’origine des principes actuels de gestion de projet. Leur intégration dans COCOMO (Constructive Cost Model) introduisit la dimension organisationnelle, humaine et technologique. En 1979, Albrecht, alors au service d’IBM, définit les bases d’une approche d’évaluation fondée sur les fonctionnalités à livrer (Points de Fonctions).

En 1994 Jean-Pierre Vickoff à partir de leurs travaux respectifs et de sa propre expérience, mis au point le logiciel Evaluateur qui apportait la gestion aisée des multiples dimensions que doit désormais intégré l’évaluation de projet moderne.

COCOMO ou les P.F. permettent d’estimer mécaniquement la charge d’un projet, mais ils ne prennent pas en compte les nouveaux et nombreux paramètres affectant les conditions de sa réalisation et n'autorisent pas une finesse suffisante pour faciliter des négociations de délais, de budget et de réduction de fonctionnalités. Aussi, de nombreux projets débutent sans qu’une métrique des composants à produire n’ait été préalablement déterminée.

La cause principale de cette prise de risques inutiles se situe certainement dans la complexité, l’inadaptation et surtout le niveau d’abstraction que représentent les techniques d’évaluation actuelles. En effet, COCOMO et les Points de Fonctions restent très éloignés des préoccupations d’un informaticien confronté dès le début du projet à la nécessité d’une estimation relativement précise effectuée sur la base d’une modélisation le plus souvent globale. C’est pour cette raison que je vous propose d’utiliser le logiciel Évaluateur.

Évaluateur est un outil réalisé par RAD.fr, il est offert gratuitement à la communauté professionnelle.

Évaluateur se base sur une évolution des travaux de Albrecht, Ashby, Boehm, Clark, Egyed, Gacek, Hoh, Lehman, Martin, Maxwell, Pareto, Parkinson, Rayleigh, Shannon, réalisée par Jean-PierreVickoff.

Evaluateur : principes généraux

Figure 2. — Table de productivité d'une équipe de projet

Lors d’une analyse, apparaissent en premier les groupes de données (entités), les écrans, les traitements, les rapports et les interfaces avec les autres systèmes. En approfondissant la conception, la complexité de ces éléments se précise. Une métrique pratique doit donc se baser sur ces informations pour estimer d’abord globalement la charge de travail (figure 2).

>

Figure 3. — Évaluateur : équilibre technique de l'équipe

La réalité de l’environnement rend alors la suite de l’évaluation beaucoup plus complexe.

Dans la réalité du développement d’applications, la combinatoire de plus d’une centaine de paramètres interdépendants et parfois d’ordre subjectif doit être considérée afin que l’évaluation s’avère relativement précise. Dans ce contexte, dépourvu d’outils et de repères, l’informaticien considère fréquemment la discipline comme trop empirique pour être vraiment utile.

Parmi les paramètres déterminants en termes de performance de développement, la méthode employée (Merise, RAD, …) a une importance au moins égale à l'expérience d’une équipe de développement dont la productivité peut varier dans un rapport de 1 à 4 en fonction de son équilibre technique (figure 3) ou de sa motivation (figure 4).

Figure 4. — Évaluateur : conditions de motivation du SWAT

Contrairement aux approches utilisant la validation en cascade basée sur la production de documents, le cycle de vie d’une méthode comme le RAD permet, dès la phase initiale, l’évaluation d’éléments concrets. Il en résulte une diminution naturelle du risque lié aux incertitudes de l’évaluation. Pourtant, en admettant que ces deux paramètres (méthode et ressources humaines) soient correctement fixés, l’influence de l’organisation et les choix technologiques conditionnent des variations pouvant atteindre plus de 400%.

Dans les projets stratégiques, particulièrement en ce qui concerne la différenciation concurrentielle, la précision de l’estimation et la possibilité de comparer instantanément des scénarios complexes acquièrent une importance vitale alors que le nombre de paramètres s’accroît.

Pour évaluer précisément un projet, il est donc impératif de disposer d’un modèle de référence propre à chaque organisation et, si possible, à chaque équipe.

Les éléments et les conditions de réalisation des projets précédents sont des paramètres généralement suffisants pour obtenir un calibrage de performance (à condition de les interpréter intelligemment et de les adapter à chaque cas).

Il faut ensuite appliquer le modèle avec rigueur et ne pas tomber dans le piège qui consiste à " jouer "  avec les paramètres d’environnement pour tenter d’adapter l’évaluation à ses désirs ou à son budget.

Il est fréquemment invoqué, pour justifier les retards de fin de projet, qu’ils seraient finalement dus à une sous-évaluation systématique. C’est parfois vrai, mais ce n’est pas l’unique raison. Lorsque les retards se transforment en dérives, il n’est plus question d’accuser l’évaluation initiale.

Dans une réponse pragmatique et outillée, une part importante de l'évaluation peut être prise en charge par un système expert, puisqu'il s'agit bien d'une démarche où il y a " rapprochement permanent entre une base de connaissances (modélisation du savoir) et une base de faits (modélisation du faire) pour obtenir une modélisation de l'état de l'art (savoir-faire) ".

En réponse à cette problématique et pour faciliter la tâche du pilote de projet moderne, un logiciel comme Évaluateur gère près d’une centaine de paramètres. Il s’applique à tout type et toute taille de développement. Il permet de créer des scénarios pour dimensionner les projets en fonction de contraintes de temps, de budget, de fonctionnalités et de visibilité.

Au-delà de l’évaluation classique de charge et de la négociation de fonctionnalités, Évaluateur permet d’estimer la performance de l’organisation en offrant naturellement, à travers le jeu du paramétrage, des réponses pratiques et des questions radicalement embarrassantes.

CMM : La Gestion quantitative de processus vise à contrôler quantitativement la performance du processus appliqué dans le cadre du projet. La performance du processus correspond aux résultats réels obtenus. L'accent est mis sur l'identification des causes spéciales de variation observées dans un projet mesurable et stable. La correction éventuelle des circonstances à l'origine de ces variations transitoires est planifiée. Le secteur clé Gestion quantitative de processus permet d'ajouter un programme complet de mesures aux pratiques des secteurs clés Définition du processus de l'organisation, Gestion logiciel intégrée, Coordination intergroupes et Revues par les pairs.


www.RAD.fr ® © Jean-Pierre Vickoff