III. Recommandations pour mener un comptage en points de fonction

1.Contexte

L'informatique est aujourd'hui pour les entreprises une source d'innovation commerciale et de différenciation concurrentielle. De nombreuses études ont montrer des résultats intéressants et surprenants. L'expérience de programmation est certes importante mais comme il sera préciser le langage utilisé n'est pas déterminant. Les langages utilisés, le niveau de connaissance des utilisateurs et les relations avec les utilisateurs sont des facteurs positifs. Des faiblesses de gestion de projets et de mauvaises relations au niveau des équipes de développement entraînement le plus souvent une baisse de productivité. Le développement de logiciels doit satisfaire simultanément plusieurs objectifs :
> Réalisation des fonctionnalités
> Respect de la qualité
> Programme flexible
> Respect des délais
> Respect du budget
Dans ce contexte la mesure de la performance ne peut s'apprécier qu'a partir de plusieurs indicateurs.

2. Problématique

Comment mesurer la performance de développement et la complexité de l'application ? Mieux estimer les délais, mieux gérer les modifications et mieux communiquer avec les utilisateurs pour assurer une livraison dans les temps et ne pas dépasser le budget. Pour les différents départements informatiques, il s'agit de s'appuyer sur une base de données de leur expérience pour améliorer leur performance et de choisir les indicateurs les plus pertinents pour prendre les mesures nécessaires afin d'atteindre les objectifs visés. Pour cela les échantillons doivent se constituer rétrospectivement à partir de l'analyse du temps passé, des efforts consentis, de la charge, de l'ampleur du projet en lignes de code ou de sa complexité en nombre de points de fonction.
On peut apprécier à partir de ces indicateurs quantitatifs certains aspects de performance d'une équipe ou d'un département informatique pour affiner le planification de nouveaux projets et pour prendre les meilleures décisions stratégiques. Ces performances peuvent être évaluées à partir de :
> Efficacité (en points de fonction par mois.homme)
> Délai de livraison (en mois)
> Respect du budget
> Respect du calendrier
> Qualité technique (absence d'erreurs en phase de test)
> Fiabilité
Un certain nombre de statistiques ont été établies sur plusieurs milliers de projets concernant des centaines d'entreprises. Ce qui permets de garantir avec certaines précautions les logiques de raisonnements fondés sur l'étude de résultats fournis par des Cabinets de Conseil ou s'appuyer sur des préconisations fournies par des outils utilisant d'aussi larges échantillons. Il faut cependant restituer les contextes propres au projet et à l'entreprise.
Les deux principaux facteurs qui influent généralement sur le niveau de productivité d'un projet sont :
> L'ampleur ou la complexité du projet en points de fonction
> Le nombre de personnes constituant l'équipe projet

3. L'analyse en points de fonction

L'analyse en points de fonction apparaît comme la méthodologie la mieux adaptée pour évaluer le poids fonctionnel ou la complexité d'une application. Cette méthodologie s'appuie sur la conception logique de l'application et est donc indépendante du langage utilisé.

3.1 Qualité, nombre net de points de fonction

Pour un utilisateur la qualité d'un système dépasse le strict contenu fonctionnel. La valeur ajouté provient de facteur comme la facilité de traitement des données ou les performance de l'exploitation. Ces facteurs entraînent un effort supplémentaire de l'effort de développement et de la valeur perçue par l'utilisateur que l'on peut faire transparaître par le Coefficient d'Ajustement en nombre net de points de fonction.
Une analyse d'un cabinet de conseil menée sur 95 entreprises concernant près de 2000 projets a révélé de fortes disparités. A tailles comparables, les projets les plus efficaces ont été cent fois plus productifs que les moins efficaces. Certains projets ont donc nécessité une charge de travail cent fois plus importante que d'autres pour aboutir à des fonctionnalités comparables. L'écart entre les entreprises les plus efficaces et les moins est encore plus important. D'un certain point de vue, ces différences ne se manifestent que dans coût. C'est à dire que des entreprises dépensent plus que d'autres pour mettre en place des applications comparables.

3.2 Obstacles

La mise en place d'un système de mesure peut se voir confrontée à un certain nombre d'obstacles dans l'entreprise. Suivant l'utilisation qui sera faite de ces résultats, l'effet sur l'entreprise sera plus ou moins positif. La mesure peut être mal perçue, s'en suivent alors des réactions diverses de la part des utilisateurs.
> Peur des individus que les données qu'ils fournissent soient utilisées à leur détriment.
> Peur d'une mauvaise interprétation des résultats.
> Crainte que la mesure de productivité puisse altérer l'esprit de collaboration en esprit de compétition
> Evaluations coûteuses et longues Interrogations sur la réelle fiabilité des résultats et la pertinence de la méthode

3.3 Recommandations

> Pour contourner ces obstacles, il faut impliquer les équipes dans ce système de mesure et ne pas détourner les résultats de leur but premier.
> Se concerter avec les différents collaborateurs pour la définition des différents indicateurs
> Communiquer les résultats aux collaborateurs et établir en communs les résultats et les recommandations
> Placer la mesure au niveau de l'équipe et non à un niveau individuel
> Collecter les données sur les projets les plus importants puis encourager à placer ces mesures dans le travail de développement
> Relativiser sur la précision des résultats, analyser les tendances et examiner les raisons d'échec de la méthode
> Vouloir imposer un seul indicateur de mesure ne peut que nuire au processus de développement. De même ne se concentrer que sur un seul ne peut que déséquilibrer une vision globale du projet.

4. Indicateurs de suivi de projet

4.1 Exemples d'indicateurs

Il est préférable de choisir plusieurs indicateurs plutôt que vouloir mesurer la performance en ne s'appuyant que sur un seul indicateur.
Exemple d'entreprises :
Entreprise A
> Productivité en points de fonction par jour.homme
> Coût direct (CA par jour.homme, cas de projets réalisés pour clients extérieurs)
> Taux de non erreurs (% de lignes de codes inchangées après une durée à fixer depuis le début du projet)
> Respect des délais
Entreprise B
> Satisfaction des clients
> Productivité
> Qualité
> Délais
> Maturité des processus
> Maturité des technologies
Ces indicateurs répondent aux buts spécifiques de chaque entreprise. Ils visent à l'amélioration du développement d'application et l'optimisation de la performance. Une fois les buts fixés, l'entreprise identifie les indicateurs et posent les questions dont les réponses lui permettront de les atteindre.

4.2 Indicateurs comme outils de communication

La mise en place d'indicateurs de mesure peut apparaître comme une nouvelle culture dans le développement d'application. Par ce processus de mesure, l'équipe de développement se responsabilise, et s'appuie sur ces résultats pour enrichir ses connaissances et argumenter les discussions.
Enfin ces outils doivent être utilisés comme aide à la communication et non comme moyen de contrôle et de pression. Afin de favoriser le dialogue ces indicateurs doivent être simples et parlant pour l'utilisateur tout en répondant à ses priorités (qualité, coûts et délais).
De même pour l'équipe de développement ces indicateurs doivent être suffisamment détaillés pour éclairer un dysfonctionnement ou de mauvaise performances. D'un projet à un autre conserver ces mêmes indicateurs favorisera la communication et permettra de transmettre les meilleures pratiques sans les utiliser comme outil de comparaison.

5. Mesurer l'ampleur d'un projet

La productivité d'un projet ne peut être suivi que s'il existe une mesure fiable de sa taille. Son ampleur est souvent appréciée en charge, durée ou coût. Cependant cela représente les ressources nécessaires à la réalisation et non une ampleur du système.
Il s'agit de deux types de paramètre qu'il faut distinguer qui servent à mesurer la productivité. En phase préalable d'un projet le budget est calculé en fonction de l'estimation de l'ampleur et de la productivité. Deux méthodes peuvent servir à mesurer l'ampleur d'un projet :
> La méthode des points de fonction pour évaluer la complexité du projet
> Le nombre de lignes de code pour en donner la taille
Suivant les entreprises, l'une de ces deux méthodes est utilisée, voire même les deux. Dans certaines circonstances, il peut paraître intéressant d'associer les deux méthodes :
> Lorsqu'une partie du code est réutilisé
La taille en points de fonction ne change pas que l'on parte de rien ou que l'on réutilise une partie de code déjà écrit. Cette réutilisation viendrait fausser une mesure de la productivité si celle ci était mesurée en points de fonction par mois.homme. Dans ce genre de situation la mesurer du nombre de lignes de code montre l'intérêt de la réutilisation du code en terme de productivité et d'efficacité des équipes de développement. La mesure en points de fonction doit permettre de suivre ma productivité réelle.
> Pour évaluer la productivité d'un processus de développement Les efforts de développement sont plus directement proportionnelles au nombre de lignes de code qu'aux fonctionnalités.
Les nombre de lignes de code par mois.homme ne varie pas trop d'un langage à un autre. A l'inverse l'effort pour réaliser un point fonctionnel varie considérablement suivant le langage choisi. La mesure en points de fonction ne fournit qu'une information sur la complexité de l'application.

5.1 Comptage du nombre de lignes de codes

5.1.1 Avantages

> Le nombre de lignes de code représente mieux l'effort à fournir ou la quantité de travail effectuée
> Les mesure de productivité fondée sur le nombre de lignes de code ne varie pas en fonction du langage utilisé
> Le taux d'erreur étant généralement proportionnel au nombre de lignes de code, sa connaissance améliore la planification de la phase de test
> Pour les langages de troisième génération et orientés objet, le comptage du nombre de ligne de code est très facile et peut se voir automatisé

5.1.2 Inconvénients

> Le nombre de lignes de code ne permet pas d'évaluer le coût prévisionnel d'un projet car il est difficile de les compter avant qu'elles ne soient écrites
> Le nombre de lignes de code peut être gonflé par le développeur suivant l'interprétation qui en sera faite
Elles sont pratiquement impossibles à compter dans de nouveaux environnements de développement de systèmes.

5.2 Comptage en points de fonction

5.2.1 Avantages

> La méthode des points de fonction est normalisée
> Elle utilisée dans de nombreuse entreprises pour mesurer la complexité ou la taille d'une application
> Elle peut être réalisée très en amont dans le cycle de développement de l'application
> Cette méthode est indépendante du langage et de la technologie utilisée
> Elle permet de décomposer un grand projet en plusieurs sous phases de tailles plus raisonnables pour être développées par des équipes plus réduites

5.2.2 Inconvénients

> L'utilisation de cette méthode demande encore un travail important, la présence d'un spécialiste de cette méthode et ne peut pas encore être automatisée
> Le comptage d'une personne à une autre peut varier de 10% contrairement à ce que la méthode présente théoriquement
> Cette méthode est conçue pour des applications de gestion et non pour des applications industrielles, techniques ou d'ingénierie. En effet, dans ces cas précis la méthode des points de fonction ne permet pas d'apprécier la complexité de développement d'algorithmes ou l'utilisation d'outils statistiques. Pour ce genre d'applications, le nombre de lignes de code reste le mieux approprié.

6. Mesure de la productivité

6.1 Facteurs d'influence sur la productivité

Lorsqu'on cherche a estimer la productivité de développement en étude de projet, ou lorsqu'on la calcule une productivité d'une équipe en cours ou en fin de projet, différents facteurs sont à prendre en compte pour affiner ou commenter ces mesures.

Taille du projet
La taille du projet est une des premières caractéristiques du projet que l'on va chercher à mesurer afin de pouvoir estimer la charge puis le délai de réalisation. Les premières études qui ont tente de lier la taille du projet à la productivité de développement ont montré que plus la taille était élevée, plus la productivité diminuait. Ceci pourrait s'expliquer par la lourdeur des charges administratives et de coordination et le renchérissement d'échelle liés au gros projets. De récentes études ont à l'inverse, dégagé une tendance selon laquelle la productivité augmenterait avec la taille du projet. Plusieurs explications peuvent confirmer cette tendance. Ces études s'appuient sur de larges échantillons d'entreprises et de projets. Cette volonté de vouloir étudier la productivité a permis de recueillir plus d'informations sur un grand nombre de projets récents. Ces projets ont d'avantage été marqué par des économies d'échelle. L'expérience de grands projet a permis d'améliorer la productivité tant par le management que par les techniques de développement. Il est possible de toutefois retenir qu'il existe un optimum de la productivité pour chaque entreprise. Cette productivité croîtrait donc avec la taille du projet dans un certaine limite.

Expérience des équipes de développement
Toujours en s'appuyant sur de larges statistiques, il est possible d'observer une relation entre la productivité et l'expérience.
Ainsi, les observations suivantes ont pu être faites :
L'expérience en méthodologie n'augmente pas pour autant la productivité. Il est même intéressant de préciser à ce sujet qu'il est souhaitable d'adapter la méthodologie à l'outil de mesure de complexité ou de taille du projet. Ainsi une méthode Merisienne apparaît particulièrement appropriée à une mesure en points de fonction. Une expérience globale en informatique favorise la productivité. L'expérience en programmation favorise d'avantage la productivité qu'une connaissance particulière d'un langage de programmation. Une plus grande expérience en matière de langage porte parfois sur un langage d'une ancienne génération, ce qui peut entraîner une baisse de productivité pour le développement utilisant les langages de dernière génération. Cela marque aussi la tendance des programmeur à vouloir changer de langage pour ne pas rester tributaire d'un langage obsolescent.


Tableau 5 : Productivité selon le langage

Délai de livraison
Les délais sont de plus en plus tendus, pour les respecter l'équipe de développement est parfois obligée d'augmenter sa rapidité de production. Cette rapidité a des répercutions tant sur le budget que sur la production. Les deux graphiques suivant illustrent d'une part l'influence d'une réduction du délai sur la charge de travail et sur les effectifs et d'autre part l'influence d'une réduction des effectif sur la charge de travail et le délai. Ainsi une augmentation des effectifs raccourcira les délais dans des proportions moindres tout en affectant la productivité. De même une diminution des effectifs n'augmentera pas les délais de livraison dans les mêmes proportions.


Tableau 6 : Influence du délai


Tableau 7 : Influence des effectifs

Qualité
On a coutume de dire : " plus on trouve d'erreurs, plus les utilisateurs sont susceptibles d'en trouver aussi ". Gérer la qualité tout au long du projet, ne peut que favoriser la productivité. Une telle démarche peut réduire le nombre d'erreurs qui seront révélées en phase de tests. Concernant les erreurs, l'expérience montrent que : Le nombre d'erreurs augmente avec la taille du projet mais en proportion plus réduite. Plus le projet mobilise de ressources humaines, plus le nombre d'erreurs détectées est élevé. Il n'existe pas de règles arithmétiques liant les effectifs au délai.

Technologie utilisée
Le langage de programmation est un des facteurs le plus influent sur la productivité. En plaçant la moyenne aux langages de troisième génération, on constate que les langages de quatrième génération et les générateurs de code sont plus productifs. Les langages orientés objet ne présentent une productivité élevé car les modules ne sont pas encore réutilisés dans les premiers temps d'utilisation, ce qui normalement entraîne des gains de productivité. Des langages comme Lotus, Access sont sans doute plus productifs, mais ces langages évolués ont des domaines d'application plus réduits.

6.2 Facteurs engendrant des baisses de productivité

L'observation d'une baisse de productivité est liée à différents facteurs, dont l'origine est souvent due à de mauvaises relations entre développeurs et utilisateurs. Des baisses de productivité sont constatées lors de :
> Difficultés de gestion de projet
> Mauvaises relations au sein de l'équipe de développement
> Difficulté d'interface avec d'autres applications

Recommandations :
Favoriser les relations entre utilisateurs et développeurs. Les échanges permettent de mieux cerner les besoins et améliorent la compréhension du projet et des aspects liés aux performances. Il s'agit toutefois d'une recommandation qui s'avère parfois difficile à mettre en œuvre. Les comptages en points de fonction peuvent y contribuer dans leur réalisation, en effet ils nécessitent une discussion et une compréhension du projet afin d'identifier les différents composants.