Techniques d'estimation en points de fonction

TECHNIQUES D'ESTIMATION EN TI

  • Visiter aussi l'ancienne page sur les PointsdeFonction de Mr. Denel

    1. Les points de fonction, pourquoi les compter?

    Dans les années soixante dix, la compagnie IBM a senti le besoin de développer une méthode d'estimation de l'effort de mise-en-oeuvre qui serait indépendante des languages, méthodes et techniques avec lesquelles les systèmes sont déployés. Le résultat fut la méthode des points de fonction.

    Durant les années quatre vingt, cette technique fut raffinée et un manuel pour le compte des points de fonction fut publié par GUIDE, un groupe appartenant à IBM. Le International Function Point Users Group (IFPUG) fut fondé à la fin des années quatre vingt. Cette organisation produit sont propre manuel de compte des points de fonction. La version 4.0 de ce manuel apparut en 1994. Ces groupes ont apporté des raffinements à la technique originale et ont toujours clamé qu'ils étaient alignés avec la pensée originale d'Albrecht. En verité tout cela est encore très près de la version originale, considérant le temps passé et la publication d'Albrecht.

    Les points de fonction sont une mesure de la taille des applications en TI et des projets qui en accouchent. La taille est mesurée d'un point de vue fonctionnel, dans la perspective de l'utilisateur. Cette mesure est indépendante des languages informatiques, des méthodes de mise-en-oeuvre, ou de la technologie utilisée par l'organisation qui supporte le projet. La raison pour laquelle cette méthode fut utilisée par Albrecht pour mesurer l'effort est simplement que la taille est le paramètre central de l'effort de mise-en-oeuvre. Les points de fonction ne mesurent que la taille.

    C'est important de mentionner ce que les points de fonction ne mesurent pas. Ils ne sont pas une mesure parfaite de l'effort de dépoiement des applications ou encore une mesure de leur valeur intrinsèque, bien que la taille soit le paramètre fondamental dans la mesure de ces quantités. C'est analogue au secteur de la construction. Une maison de trois mille pieds carrés est habituellement moins dispendieuse à construire qu'une de six mille pieds carrés. Cependant, biens des attributs tels que les salles de bains en marbre et des planchers en ardoise pourraient rendre la plus petite des deux maisons plus onéreuse. D'autres facteurs, tels que la localité auront aussi un impact sur la valeur.

    Bill Hufschmidt, un habitué des points de fonction, met l'accent sur le fait qu'en anglais, les trois premières lettres de function points sont: FUN. Cependant, nous avons de plus sérieuses raisons de considérer les points de fonction:

  • Mesurer la productivité: Plusieurs gestionnaires en arrivent à la conclusion que, quelle que soit leur champs d'activité, ils sont quand même très impliqués dans les TI. Le calcul de la productivité en PF par unité de temps leur donne un indicateur important.

  • Estimer la mise-en-oeuvre et l'entretien: Depuis leur début, les points de fonction sont utilisés pour l'estimation de la mise-en-oeuvre. Cette démarche est nécessaire pour l'analyse financière qui permet de déterminer la valeur d'un projet de TI. Même pour les projets stratégiques, qui n'ont souvent pas besoin de justification quantitative, ces estimations sont requises pour déterminer le nombre de ressources humaines à employer.

  • Suivi des contrats de TI: Les organisations qui donnent à contrat des sections de leurs opérations en TI (outsourcing) peuvent utiliser les points de fonction pour faire le suivi de la productivité des contractants. Plusieurs compagnies appliquent cette technique: CSC, IBM, Eastman Kodak, etc.

  • Prise de décision: Toutes les organisations se doivent d'analyser leurs portfolios d'applications et de projets. La taille, en points de fonction, est un attribut requis de chaque système et projet. Parmi d'autres facteurs, ces mesures permettent de décider de la rétention, de la mise à la retraite, et la reingénierie des applications.

  • Normalisation: Comme toute mesure requiert une normalisation par la taille, nous pouvons utiliser les points de fonction à cette fin.
  • Il y a plusieurs questions générales par rapport aux points de fonction. Nous en examinons quelques unes:

    2. Les P.F. dans les applications avec IHM graphiques ?

    Oui. au moment de l'apparition des points de fonction, cette technique n'était pas utilisée pour des applications de TI avec interfaces graphiques. Ces systèmes n'existaient pas! Il n'y a pas si longtemps, on se demandait encore comment faire les comptes de points de fonction pour ces systèmes particuliers.

    Il y a deux ans, le groupe IFPUG complétait sont manuel de compte de points de fonction. On y trouve les règles officielles et des exemples de compte pour les systèmes à interface graphique. Subséquemment, IFPUG produisit un exemple complet d'un tel compte.

    Malheureusement, on trouve encore des spécialistes qui ne se sont pas documentés sur ces nouvelles procédures. C'est à ne pas tolérer. Les spécialistes auxquels vous faites appel se doivent d'être à jour.

    3. Les points de fonction en Client/Serveur ?

    Oui, dans les cas les plus simples, l'utilisateur peut ne pas être conscient du fait que le programme qu'il utilise tourne sur l'ordinateur local ou central. En fait, dans le monde merveilleux des architectures Client/Serveur, une application peut stopper anormalement à cause d'un ordinateur situé à très grande distance. Malgré cela, on constate que de telles applications sont comme les autres par rapport aux points de fonction. Evidemment, une telle architecture complexifie un peu les comptes de points de fonction.

    Les comptes sont souvent compliqués à cause de l'architecture. On y trouve des bases de données, des équipments disparates, et d'autres compsants qui servent aux techniciens. L'installation d'une infrastructure est souvent un projet en soi. Y a-t-il des points de fonction dans un tel projet? Si c'est le cas, est-ce que le compte est fait comme si les techniciens étaient les utilisateurs de cette architecture? D'autres personnes peuvent être impliquées dans ces projets. Cela change-t-il les réponses aux questions précédentes?

    Même en concentrant nos efforts sur les applications de TI, l'identification des frontières de ces programmes dans de telles architectures est parfois assez difficile. Une application de TI peut être partiellement construite sur un ordinateur client et partiellement sur le serveur. Dans ce cas, la portée de cette application inclut les deux plateformes. Cependant, plusieurs projets inclueront l'installation ou la mise en oeuvre d'applications qui interagiront avec des clients et des serveurs déjà en place et cela compliquera les comptes d'autant.

    4. Les points de fonction en orienté Objet ? objet?

    Oui. Comme vous pouvez le constater, c'est toujours oui! En effet, les points de fonction sont utilisés indépendemment des méthodes de mise-en-oeuvre. C'est parce que les points de fonction sont indépendants des technologies et des aspects techniques des application en TI. L'effet du développement orienté objet se fera surtout sentir sur la productivité.

    Au bas mot, l'utilisation des techniques OO permet l'intégration immédiate de larges pans de fonctionnalité sous forme de réutilisation. Une école de pensée considère que toute la fonctionnalité doit être incluse au complet dans les comptes, peu importe la provenance. Si l'utilisateur se rend compte que beaucoup de cette fonctionnalité provient d'un achat ou d'une réutilisation, alors ce n'est pas tout le crédit qui devrait être donné à l'organisation acheteuse. Dans ce cas, les estimés qui utilisent les points de fonction seront faussés lors de l'utilisation de ceux-ci pour la mise-en-oeuvre pure.

    Ces problèmes dépassent la simple utilisation des techniques OO. Mais les utilisateurs de points de fonction doivent standardiser leur approche dans ces cas.

    5. Quand doit-on compter les points de fonction?

    Comptez tôt et souvent! Plus l'on peut quantifier tôt ce qui sera livré par un projet, le plus tôt sera-t-il sous contrôle. Traditionellement, on croyait que le compte de points de fonction ne pouvait avoir lieu avant que le design du produit soit complet. Les membres du groupe IFPUG savent combien il est important de le faire avant la fin du design, dans le cycle chronologique. En fait, il est possible d'effectuer de tels comptes tout de suite après que les besoins sont connus et complètement identifiés. Il est aussi possible de faire usage d'heuristiques afin d'obtenir des estimés encore plus tôt.

    Nous allons maintenant nous concentrer sur les estimations et les comptes qui sont typiquement faits en des endroits divers du cycle de projet. Puisque chaque organisation a son ou ses propres cycles, les phases seront décrites en terme des progrès réalisés sur les produits en question.

    Si le cycle commence par des études de faisabilité, il est alors impossible de faire le compte à ce stage. Par contre, on peut utiliser des analogies. Par exemple, si un projet similaire comptait 2000 points de fonction, alors le meilleur estimé à ce stade est: 2000 points de fonction.

    Pendant la phase de détermination des besoins, les estimés du compte peuvent être successivement affinés. Pour plusieurs projets, un diagramme de flux des données est mis en place. Ce qu'est un diagramme de flux varie d'une organisation à l'autre mais, à partir de lui, on peut identifier quelles entités aurount besoin de traitement automatisé. Si l'équivalent d'un diagramme de contexte de Yourdon est disponible, alors les interactions entre les utilisateurs et les systèmes sont connues. Il est alors possible d'obtenir un compte précis en posant l'hypothèse que chaque type de transaction est de complexité moyenne. Même si tôt dans le projet, on peut prédire les valeurs des facteurs d'ajustement avec précision.

    Au moment où les besoins sont bien identifiés et qu'il y a un modèle logique des donnés qui inclut les entrées et les sorties, nous avons tous les éléments pour un compte précis.

    Comme nous l'avons indiqué après avoir complété le design, le compte est précis. C'est le moment de prendre en compte la volatilité des besoins et son impact sur le projet. Le type le plus simple de volatilité est l'accroissement de la portée (scope creep). Si le premier estimé est de 1000 points de fonction et que l'application de TI en est à 1500 à la fin, c'est qu'il y eu 50% d'accroissement de portée.

    D'autres formes de volatilité sont plus insidieuses. C'est possible de mesurer 1000 points de fonction au début et autant à la fin mais, pour 1000 points de fonction complètement différents de ceux de départ. Il faut pouvoir faire le suivi de cela car il s'agit bien de changements. Comme d'habitude, plus tard cela ce produit dans le projet, plus coûteux cela devient. Cependant, puisque le compte n'a pas changé, on ignore souvent ce type de volatilité. On voit que le points de fonction ne répondent pas à toutes les questions. Ces changements doivent être considérés comme cosmétiques. Leur impacts doivent entrer dans les estimations subséquentes du projet en question.

    En théorie, il ne devrait pas se produire de changement au compte entre la fin du design et la fin des tests d'acceptation. Mais ça, c'est la théorie. En pratique, cela ne se passe pas ainsi. En fait, c'est la période la plus active des demandes, formelles ou non, de changements. C'est aussi à ce point que les changements commencent à devenir dispendieux. Les points de fonctions seront utilisés pour quantifier les négociations entre les parties. Il faut bien se rendre compte que d'échanger 100 points de fonction de mise-en-oeuvre pour 100 points de fonction de changements n'est pas futé. En effet, l'effort imputable aux 100 points de fonction de mise-en-oeuvre est perdu. Mais on voit bien que les points de fonction facilitent ce genre de changements.

    Il est approprié de faire la mise-à-jour des points de fonction à la fin du projet. On révise le projet avec l'idée que les données seront utilisées dans le processus d'estimation des projets futurs. La taille des applications de TI est un facteur qui peut motiver leur entretien. Les utilisateurs doivent décider si la valeur organisationelle de ces applications justifie leur soutien.

    6. Quelles-sont les étapes du compte de points de fonction?

    Le manuel IFPUG est organisé de telle façon que chaque chaptire est une étape chronologique du compte de points de fonction. Nous reproduisons ici ces étapes de façon condensée. Les différences avec la méthode IFPUG sont indiquées.
    1. Planifiez le compte: Cette étape comprend 2 activités IFPUG: déterminer le type de compte et la portée du compte. Il faut aussi inclure la logistique du compte et l'assignation d'un expert.

      A présent, IFPUG identifie trois types de compte: mise-en-oeuvre, entretien et application. Tous ces comptes sont reliés. Par exemple, le compte de mise-en-oeuvre nous donne la première estimation d'une application. Dans tous les cas, trouver à quel type de compte il faut procéder est assez simple.

      Ce qui l'est moins, c'est l'identification de la portée du compte. Des conseils experts seront probablement nécessaires (manuel IFPUG). La formation est aussi imporante ici. Changer la portée du compte peut avoir une influence sur le type de compte qu'il faut effectuer. Par exemple, il se peut qu'un compte de mise-en-oeuvre devienne de plus en plus un compte d'application à mesure que la portée s'accroît.

      Le manuel IFPUG n'en fait pas mention, mais il y a trois sources d'information pour procéder au comptage: L'application en soi, sa documentation et l'expert de l'application, en ordre d'importance. Une documentation complète et utilisable facilite le compte énormément. Mais une telle documentation est plus que rare! Alors, il faut utiliser l'expert comme un guide en terrain inconnu. L'accès à l'application seule rend le processus plus exigeant. Vous devriez avoir l'expert avec vous pour la durée du compte.

      Identifier l'expert de l'application n'est pas chose facile. Cela aussi dépend de la portée du compte. L'expert ne l'est peut-être pas dans toutes les composantes incluses au compte. Cet expert peut avoir participé au design ou bien être un utilisateur expérimenté.

    2. Expliquez le processus: Ceci n'est pas dans le manuel IFPUG. Si vous utilisez un expert de l'application, vous devrez expliquer ce que vous voulez tenter, le pourquoi du compte et l'utilisation que vous ferez de cette information. Si l'organisation a un programme de quantification, ce sera facile. La culture interne vous permettra de procéder directement. Enfin, il est important de terminer rapidement ces explications. Vous devez procéder au compte afin d'obtenir vos résultats. Vous ne pouvez pas non plus être constamment interrompu pour donner des explications.

    3. Calculez les facteurs d'ajustement: D'habitude, cette étape se fait vers la fin du compte. Aussi, on préfère attendre la fin parce qu'il y a nombre de fois où l'expert se plaindra que le compte est injuste. Il suffit alors de mentionner que les facteurs rebalanceront le compte plus justement à la fin. On peut aussi le faire au début, pour estimer la complexité réelle d'une application TI. On peut partager cette information avec l'expert pour la valider. Cela l'intéressera.

    4. Comptez les 5 paramètres: Cela provient directement de la méthode (IFPUG ou bien section 8). Il y a les entrées, les sorties, les requêtes, les fichiers et les interfaces. On fait ce compte en utilisant l'information sur les types de données qui se trouvent dans l'application.

    5. Faire les calculs: Cela est simple et le guide IFPUG (ou la section 8) peuvent être utilisés.

    6. Vérifiez le compte: Ceci n'est pas mentionné dans le document IFPUG. C'est raisonnable de demander à l'expert de réviser le compte. L'expert sera utile pour identifier les omissions, pas les erreurs de méthode. Le plus rapidement cela est fait après le compte le mieux ce sera, même si vous avez l'intention de faire la vérification vous-même plus tard.

    7. Partagez les résultats. Une des raisons pour lesquelles les programmes de quantification échouent est que les gens attendent trop longtemps les résultats. Ils doivent être distribués dès que possible au personnel du projet et au requérant du compte.

    7. Combien de temps le compte prendra?

    On n'aime pas parler de cela. Mais, IBM estime qu'un expert des points de fonction devrait pouvoir en compter 100 à l'heure. La plupart des consultants croient qu'il s'agit d'une valeur plutôt basse. Ils croient qu'on peut en compter plus de 4000 à l'heure. Par contre, si on inclut toute la préparation et la dissémination des résultats, la valeur de 100 à l'heure est probablement plus juste.

    Il y a toujours des tâches qui ont un temps fixe, peu importe la portée du compte. Pour cette raison, on croit que la plupart des applications peuvent être comptées en une seule journée, ou même une demi journée.

    8. La méthode IBM 1984 révisée.

    Voici la méthode complète, révisée par IBM en 1984. La premier tableau indique les facteurs de complexité par paramètre. La méthode est simple. Par exemple, si nous avons deux entrées externes et deux sorites externes, toutes de complexité moyenne, le compte est alors (2*4) + (2*5) = 18.

    La façon dont on fait le compte est cruciale. Par exemple, le nombre d'entrées externes est le nombre d'algorithmes différents qui assument le traitement des entrées externes. Dans ce sens, l'entrée de nouvelles pièces dans un système d'inventaire compte pour une seule entrée externe.

    Les sorties externes sont comptées de façon similaire. C'est encore le nombre d'algorithmes différents qui sont dans l'application et qui assurent les fonctions des sorties externes. Par exemple, la liste d'inventaire compte pour une seule sortie externe.

    Les fichiers logiques sont le nombre d'entités de données que l'application contient. Ce compte exclut les fichiers d'interface ou les fichiers index, etc.

    Les requêtes sont la combinaision d'une entrée et d'une sortie. Par exemple, la fonction d'interrogation de l'inventaire est une requête. Ce compte est donc la somme des différentes sorties provoquées par une entrée de donnée par l'utilisateur.

    Les fichiers d'interface sont ceux que l'application produit aux fins d'exportation vers d'autres systèmes. A ne pas confondre avec une exportation vers un utilisateur. On les compte de la même manière que les fichiers logiques.

    COMPLEXITE
    PARAMETRE FAIBLE MOYENNE ELEVEE
    Entrée Externe 3 4 6
    Sortie Externe 4 5 7
    Fichier Logique 7 10 15
    Fichier d'Interface 5 7 10
    Requête 3 4 6

    8.1. Tables d'ajustement

    Pour chaque type de paramètre, nous déterminons son niveau de complexité. Nous le faisons en utilisant les tables suivantes. On détermine le nombre de types de fichiers référencés, et le nombres d'éléments de données utilisés. On le fait pour l'ensemble des fonctions d'entrée, l'ensemble des fonctions de sortie, etc.

    ENTREES EXTERNES
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-4 5-15 plus de 15
    0-1 FAIBLE FAIBLE MOYENNE
    2 FAIBLE MOYENNE HAUTE
    plus de 3 MOYENNE HAUTE HAUTE

    SORTIES EXTERNES
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-5 6-19 plus de 19
    0-1 FAIBLE FAIBLE MOYENNE
    2-3 FAIBLE MOYENNE HAUTE
    plus de 3 MOYENNE HAUTE HAUTE

    FICHIERS LOGIQUES
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-19 20-50 plus de 50
    0-1 FAIBLE FAIBLE MOYENNE
    2-5 FAIBLE MOYENNE HAUTE
    plus de 5 MOYENNE HAUTE HAUTE

    FICHIERS D'INTERFACE
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-19 20-50 plus de 50
    0-1 FAIBLE FAIBLE MOYENNE
    2-5 FAIBLE MOYENNE HAUTE
    plus de 5 MOYENNE HAUTE HAUTE

    REQUETES PARTIE ENTREES
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-4 5-15 plus de 15
    0-1 FAIBLE FAIBLE MOYENNE
    2 FAIBLE MOYENNE HAUTE
    plus de 2 MOYENNE HAUTE HAUTE

    REQUETES PARTIE SORTIES
    Types de Fichiers Types d'Eléments de Données
    Utilisés 1-5 6-19 plus de 19
    0-1 FAIBLE FAIBLE MOYENNE
    2-3 FAIBLE MOYENNE HAUTE
    plus de 3 MOYENNE HAUTE HAUTE

    8.2. Ajsutement du compte final

    La dernière étape est celle de déterminer l'importance relative des 14 facteurs qui se trouvent à la table suivante. La somme des réponses (de 0 à 5) est utilisée dans le calcul final donné plus bas.

    FACTEUR INFLUENCE
    Comm. 0 1 2 3 4 5
    Syt. Dist. 0 1 2 3 4 5
    Obj. Perf. 0 1 2 3 4 5
    Uti. Elev. 0 1 2 3 4 5
    Trx. 0 1 2 3 4 5
    En Ligne. 0 1 2 3 4 5
    Ef. Util. 0 1 2 3 4 5
    MAJ Lig. 0 1 2 3 4 5
    Cplx. 0 1 2 3 4 5
    Réusabili. 0 1 2 3 4 5
    Fac. Inst. 0 1 2 3 4 5
    Fac. Opr. 0 1 2 3 4 5
    Mul. Site. 0 1 2 3 4 5
    Fac. Chng. 0 1 2 3 4 5

    8.3. Calcul du compte final

    Après avoir fait la somme de ces réponses, nous l'utilisons comme coefficient. La formule est simple: coefficient = somme_facteurs*0.01 + 0.65. Le compte final est obtenu par AFPC = UFPC*coefficient, où AFPC est Adjusted Function Point Count et UFPC est Unadjusted Function Point Count.

    © Dr S. S. Beauchemin, tous droits réservés

  •  Carte mondiale des journaux