II. Recommandations pour mener un comptage en points de fonction

1. Objectifs

La partie précédente présentait la méthode de points de fonctions et s'arrêtait au comptage en nombre brut tel qu'il est pratiqué à la SNCF. La deuxième étape consiste au passage à un nombre net de points de fonction. La présentation de cette deuxième étape va permettre d'en voir les limites suivant le type d'entreprise ou de projet. Bien souvent pour chaque comptage, l'application évaluée présente des cas particuliers qui ne sont pas explicitement détaillés dans les recommandations de l'IFPUG. Sont présentés dans cette partie des conseils de comptages pour quelques cas qui sont assez souvent rencontrés mais qui présentent des difficultés dans leur interprétation.

2. Pour aller plus loin et en savoir plus sur les comptages en points de fonction

Les règles de l'IFPUG recommandent après le comptage en nombre brut de points fonction, l'établissement d'un ratio pour un passage en nombre net de points de fonction. Au vue de l'expérience de la SNCF en matière de comptage, les évaluations de charges ont été calculées à partir d'un nombre brut de points de fonction. Le ratio utilisé pour un passage à la charge depuis le nombre brut de points de fonction. Ce ratio dépend des équipes de développement et est propre à chaque entreprise et plus particulièrement dans cette étude à chaque Domaine de la SNCF. Considérant le nombre net de points de fonction comme établi à partir de considérations subjectives, il paraît justifié de s'arrêter à un nombre brut. L'établissement du nombre net va être présenter à titre d'information, ce qui permet également d'appréhender d'autres aspects liés au développement d'une application informatique. Les comptages en points de fonction doivent conduire à des résultats proches d'une personne à une autre. Le facteur humain entrant en jeu peut certes introduire des différences lorsqu'on examine les estimations en détail (comme celle des DE ou SLD), mais le passage à la complexité vient lisser toute divergence, puis le comptage final brut en points de fonction étant mathématique, les résultats convergent vers le même résultat.

Figure 3 : Evaluation de la charge

2.1 Calcul du nombre net de points de fonction

Le passage du nombre brut au nombre net, se fait par la multiplication par le Facteur d’Ajustement. Le Facteur d’Ajustement ajuste le nombre brut de points de fonction de +/-35%. Le responsable du comptage va apprécier l’application suivant 14 Caractéristiques Générales du Système et les évalue sur une échelle de zéro à cinq en donnant un Degré d’Influence. Les 14 Degrés d’Influence sont ensuite sommés pour donner les Degrés d’Influence Total de l’application DIT. Le Facteur d’Ajustement est ensuite calculé de la façon suivante : FA = (DIT * 0,01) + 0,65

2.2 Degrés d’influence du système

>Transmission des données
>Système distribué
>Contrainte de performance
>Configuration à utilisation intensive
>Taux de transaction
>Saisie interactive
>Convivialité
>Mise à jour en temps réel
>Complexité des traitements
>Réutilisation
>Facilité d’exploitation
>Portabilité de l’application
>Flexibilité de modification

2.3 Echelle de 0 à 5 des degrés d’influence

0 inexistante ou sans influence
1 influence secondaire
2 influence restreinte
3 influence moyenne
4 influence importante
5 influence intensive partout

On pourra se reporte à la méthode de l’IFPUG pour les définitions des Degrés d’Influence Des comptages d’une même application par des personnes expertes de la méthode des points de fonction doivent aboutir au même poids en nombre brut. Pour le facteur d’ajustement, les évaluations de Degré d’Influence peuvent diverger d’un point pour chaque Caractéristique Générale et donc conduire à une erreur de plus de 10% sur l’estimation finale du nombre net de points de fonction.

3. Notion d'application pour la mesure en points de fonction

Cette notion peut varier d'une entreprise à une autre ce qui peut influer sur la détermination des " frontières " ou des " limites " de l'application à mesurer.

3.1 Rappel des règles de l'IFPUG

La frontière est déterminée sur le base du point de vue utilisateur. L'important est des se concentrer sur ce que l'utilisateur peut comprendre et décrire. La frontière entre des applications qui sont liées entre elles ne doit pas être basée sur des considérations technologiques mais sur la séparation des fonctions de gestion telles qu'elles sont vues par l'utilisateur.

3.2 Recommandation pour la mesure en points de fonction, définition de la notion d'application

Une application correspond :

>D'un point de vue utilisateur au plus petit ensemble cohérent de fonctionnalités, utilisable indépendamment des autres application

>A un ensemble cohérent dans une entreprise étant donnés son métier et ses groupes d'utilisateurs

Le périmètre de l'application définit le plus petit ensemble de fonctionnalités qui doivent être gérées conjointement pour répondre aux besoins des utilisateurs Aucune considération technologique, ou considération liée à l'organisation des équipes de développement et de maintenance, n'est déterminante pour fixer les frontières de l'application.

4. Etablissement des limites de l'application 

On se reportera à la définition de la limite de l'application. Lorsque cette définition est assimilée, il faut la mettre en pratique avant de réaliser les comptages. Le détermination de la limite s'effectue en trois étapes

1/ Circonscrire l'application destinée au comptage
Suivant les objectifs du comptage, on tiendra compte ou pas des découpages du projet en sous projet. Pour cette étape, il faudra bien délimiter l'application en s'appuyant sur la cohérence fonctionnelle générale et sur la vue utilisateur. Il faudra tenir compte de la multiplication des interfaces qui risque d'être comptabilisées plusieurs fois à l'échelle de l'entreprise. La méthode des points de fonction est d'autant plus performante pour des applications d'une certaine taille. On risque en effet de rencontrer un manque de fiabilité pour de petits projets.

2/ Identifier les interactions aux limites
Cette identification consiste à recenser tous les échanges de données en Entrée ou en Sotie de l'application en indiquant le sens du flux. Pour cette étape il faut confondre le niveau logique avec le niveau physique ainsi que Entrées et Sorties avec le Groupe de Données Externes.

3/ Décomposition fonctionnelle
Pour cette décomposition, si l'information est présente, on peut représenter la structure arborescente. A défaut, on pourra établir une liste des fonctionnalités sans omettre celles liées à des utilisateurs spécifiques.

5. La notion de vue utilisateur

La notion de vue utilisateur correspond à une vision fonctionnelle des processus élémentaires et données susceptibles d'être pris en compte dans un mesure en points de fonction. Cette notion vise plus à s'opposer à une vision à une vision technique des choses plutôt qu'à opposer la vision de l'utilisateur à celle de l'informaticien. Les quelques règles qui suivent permettent de mieux comprendre la notion de vue utilisateur utilisée dans différents contextes de comptage en points de fonction.

5.1 Rappel des règles de l'IFPUG

Le terme identifiable par l'utilisateur dans les définitions des GDE et des GDI désigne un ensemble de données liées à un niveau tel qu'un utilisateur expérimenté puisse identifier ces données comme répondant à un besoin d'un utilisateur de l'application. Un processus élémentaire est la plus petite activité qui soit significative au niveau de l'organisation pour l'utilisateur final. La logique de traitement est définie les besoins spécifiquement demandés par l'utilisateur pour réaliser un processus élémentaire.

5.2 Recommandations concernant cette notion de vue utilisateur

Cependant, il ne faut pas prendre cette expression de vue utilisateur au pied de la lettre. Ainsi peut on retenir ces quelques recommandations : Si plusieurs utilisateurs d'un même applicatif ont des perceptions différentes des fonctionnalités de cet applicatif, cet applicatif ne doit avoir qu'une seule mesure en points de fonction. Même si un utilisateur a des difficultés à comprendre la méthode de comptage en points de fonction ou à distinguer ce qui relève d'un besoin fonctionnel et ce qui relève d'un besoin technique ou de qualité, cela ne doit pas altérer la mesure en points de fonction Si plusieurs types d'utilisateurs ont des besoins correspondant à des fonctions similaires sur le plan des règles de comptage en points de fonction (dans le cadre de la même application) chacune de ces fonctions ne peut être comptabilisée qu'une seule fois.

6. Mesure d'un projet portant sur plusieurs applications

La notion de projet correspond souvent à une enveloppe budgétaire et/ou à découpage technologique. Souvent les projets sont découpés en étapes temporelles de développement. Ces mesures se fondent toujours sur un point de vue utilisateur.

6.1 Rappel des règles de l'IFPUG

La frontière entre des application qui sont liées entre elles doit être basées sur la séparation des fonctions de gestion telles qu'elles sont vues par l'utilisateur. Pour des projets d'évolution fonctionnelle, les frontières initiales doivent se conformer aux frontières déjà établies pour les applications mesurées.

6.2 Quelques recommandations

Pour un projet portant sur plusieurs applications, chaque application impactée est successivement étudiée, mais pour la mesure finale du projet, les composant redondant sont éliminés. Si cela est possible, il est préférable de ne pas mélanger dans une même mesure, les points de fonction correspondant au développement d'une nouvelle application à des points de fonction correspondant à une évolution d'une application existante. Il s'agit de deux types de comptage différents. La mise à jour de la taille, en points de fonction d'une application n'est pas toujours réalisable à partir de la taille du projet. Si le projet porte sur plusieurs applications, alors seule une mesure sur chacune de ces applications, ne portant que sur les évolution subies, peut contribuer à une mesure en points de fonction dès la mise à jour fonctionnelle. De plus chaque composant n'est comptabilisé qu'une seule fois.

7. Comptage concernant un ensemble de données mis à jour par l'équipe de développement ou par l'équipe assurant la maintenance de l'applicatif

Il est parfois défini qu'un ensemble de données soit mis à jour sans que cela n'entraîne d'autres modifications de l'application à mesurer. Pour ce cas on se reportera aux définitions des GDE et GDI. On peut comptabiliser l'ensemble de données comme un GDE. Le langage utilisé peut être perçu comme un système externe, non mesuré, permettant la mise à jour du Groupe de Données considéré. Le processus de mise à jour n'est comptabilisé nulle part. Il n'est réalisé qu'en fonction des besoins et n'est identifiable dans aucune application comme un processus standard accessible dans le cadre d'une identification normale de cette application.

8. Comment comptabiliser les GDI et le GDE dans un projet d'évolution

Un projet d'évolution peut entraîner une modification sur le plan fonctionnel de la structure d'un Groupe de Données. Dans un tel cas ce Groupe de Données devra être comptabilisé dans la mesure de ce projet d'évolution. Les cas présentées ci dessous et leur comptage peuvent servir de référence pour des comptages de projets d'évolution.

8.1 Cas1 : A l'issue d'un projet, un Groupe de Données est utilisé par un processus élémentaire alors qu'il n'était pas utilisé précédemment par l'application modifiéE

Il s'agit d'un nouveau GD référencé. Si le groupe de données est mis à jour par l'application modifiée, celui-ci sera comptabilisé comme un GDI ajouté dans la mesure du projet d'évolution ayant permis cette modification. Si ce Groupe de Données n'est pas mis à jour, il sera comptabilisé comme un GDE ajouté dans la mesure de ce projet d'évolution.

8.2 Cas 2 : A l'issue du projet, un Groupe de Données déjà utilisé en tant que GDE par l'application s'avère être mis à jour par cette application

Il s'agit d'un ancien GDE mis à jour. Si un GD est mis à jour par l'application modifiée, celui ci sera comptabilisé comme un GDE modifié avant et un GDI modifié après, dans la mesure du projet ayant permis cette modification.

8.3 Cas 3 : A l'issue du projet, un Groupe de Données ne sera plus mis à jour par l'application modifiée mais restera utilisé par cette application

Il s'agit d'un ancien GDI qui n'est plus mis à jour . Si le GD n'est plus mis à jour par l'application modifiées, celui-ci sera comptabilisé comme un GDI modifié avant et un GDE modifié après dans la mesure du projet d'évolution ayant permis cette modification

8.4 Cas 4 : A l'issue du projet, tous les projets élémentaires qui utilisaient ou mettaient à jour un groupe de Données seront supprimés de l'application modifiée

Il s'agit d'un GD dont on n'a plus besoin. Si le GD n'est plus utilisé par l'application modifiée, on comptabilisera dans la mesure du projet d'évolution un GDI supprimé ou un GDE supprimé selon le rôle qu'il avait précédemment dans l'application modifiée.

8.5 Recommandations pour la mesure

Seuls les composants " modifiés après " sont comptabilités dans la taille d'un projet d'évolution. La notion de composants " modifiés avant " est utilisée pour mettre à jour la taille de l'application concerne par un projet d'évolution.

   Taille initiale de l'application
    -  Composant modifiés avant
   +  Composant modifiés après
    -  Composants supprimés
   +  Composant ajoutés
                                                
   = Taille finale de l'application

Seule la partie de la mesure qui porte l'application dont la taille est mise à jour, est comptabilisée. Si le projet porte sur plusieurs Groupe de Données, ce Groupe de Données ne sera comptabilisé qu'une seule fois dans la mesure totale du projet, pour son poids le plus fort en points de fonction.