{"id":2443,"date":"2015-04-13T08:14:45","date_gmt":"2015-04-13T07:14:45","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2443"},"modified":"2015-04-14T11:52:41","modified_gmt":"2015-04-14T10:52:41","slug":"les-developpeurs-revent-ils-de-points-de-fonction-automatises-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/les-developpeurs-revent-ils-de-points-de-fonction-automatises-2\/","title":{"rendered":"Les d\u00e9veloppeurs r\u00eavent-ils de points de fonction automatis\u00e9s ? (II)"},"content":{"rendered":"

\"Qualilogy<\/a>Nous nous sommes demand\u00e9, dans le post pr\u00e9c\u00e9dent<\/a>, pourquoi les d\u00e9veloppeurs ne connaissaient g\u00e9n\u00e9ralement pas les Points de Fonction, et si cette m\u00e9trique pouvait leur \u00eatre utile.<\/p>\n

Notre r\u00e9ponse est plut\u00f4t n\u00e9gative, surtout si l\u2019on consid\u00e8re qu\u2019une telle estimation est r\u00e9alis\u00e9e manuellement, par des consultants qui s\u2019appuient sur une d\u00e9marche assez complexe. Il existe d\u2019ailleurs nombre de certifications dont l\u2019objet est de valider qu\u2019un consultant ma\u00eetrise ces concepts et sache les mettre en \u0153uvre de mani\u00e8re op\u00e9rationnelle. <\/p>\n

Pas vraiment de quoi attirer des d\u00e9veloppeurs qui, selon moi, vont plut\u00f4t pr\u00e9f\u00e9rer s\u2019investir dans une nouvelle technologie, un nouveau langage, le dernier framework \u00e0 la mode, un d\u00e9veloppement Open Source, etc.<\/p>\n

Imaginons maintenant que le calcul des Points de Fonction puisse \u00eatre automatis\u00e9 : cela suffirait-il pour que les d\u00e9veloppeurs utilisent cette mesure ?<\/p>\n

Automated Function Points (AFP)<\/h2>\n

L\u2019OMG a r\u00e9alis\u00e9 une norme de sp\u00e9cifications<\/a> d\u00e9crivant les conditions \u00e0 remplir par un logiciel afin d\u2019automatiser la mesure des Points de Fonction.<\/p>\n

Limitations<\/h3>\n

Ce document \u00e9nonce certaines diff\u00e9rences avec une estimation manuelle des Points de Fonction. Par exemple, le paragraphe \u00ab 1.3 Limitations \u00bb explique que cette norme ne s\u2019applique pas \u00e0 \u00ab la mesure des \u00e9volutions d\u2019une application ou de la maintenance de fonctionnalit\u00e9s [existantes], encore appel\u00e9s Enhancement Function Points \u00bb.<\/p>\n

Si c\u2019est bien le cas, ce serait alors une divergence assez importante puisque les Points de Fonctions automatis\u00e9s ne concerneraient d\u00e9s lors que des d\u00e9veloppements nouveaux, et non pas des versions successives d\u2019une application. Or nous savons bien que 80% ou 90% des projets portent sur de la maintenance applicative et que les projets nouveaux sont assez largement minoritaires.<\/p>\n

D\u2019ailleurs, ces sp\u00e9cifications ne pr\u00e9tendent pas (paragraphe \u00ab 2.1 Conformance \u00bb) \u00e0 une stricte conformit\u00e9 avec la mesure manuelle des Points de Fonction, ne serait-ce que par les difficult\u00e9s soulev\u00e9es pour compl\u00e8tement automatiser … un processus manuel. Le paragraphe \u00ab 2.3 Consistency with IFPUG CPM \u00bb explique ainsi que \u00ab cette norme effectue des choix explicites \u00bb lorsque, dans certaines situations, les r\u00e8gles \u00e9dict\u00e9s par l\u2019FPUG (1) peuvent se r\u00e9v\u00e9ler assez vagues.<\/p>\n

Ce m\u00eame paragraphe explique qu\u2019un consultant IFPUG sera amen\u00e9 \u00e0 effectuer certaines interpr\u00e9tations en mati\u00e8re de conception et de d\u00e9veloppement d\u2019\u00e9l\u00e9ments fonctionnels, ce qui est \u00e9videmment impossible pour un outil logiciel, qui ne peut d\u00e9cider de lui m\u00eame si telle structure de donn\u00e9es ou telle transaction est importante ou non pour l\u2019application : \u00ab il [le logiciel] ne peut capturer aucune des intentions du concepteur qui ne laisse une empreinte dans le code source \u00bb.<\/p>\n

Donc la norme elle-m\u00eame explique clairement que \u00ab le comptage des Automated Function Points … peut diff\u00e9rer des comptages manuels produits par un consultant IFPUG certifi\u00e9 \u00bb.<\/p>\n

Mise en \u0153uvre de la norme<\/h3>\n

Le reste du document liste les diff\u00e9rentes \u00e9tapes de calcul des AFP. Je ne vais pas d\u00e9tailler ces op\u00e9rations mais simplement lister ce qui, sur la base de mon exp\u00e9rience en mati\u00e8re d\u2019outils d\u2019analyse de code, risque de provoquer des \u00e9carts avec un comptage manuel ou d\u2019avoir des cons\u00e9quences pour la mise en \u0153uvre de cette norme dans le cadre d\u2019un cycle de vie de projet.<\/p>\n

Fronti\u00e8res<\/h3>\n

La premi\u00e8re \u00e9tape consiste \u00e0 d\u00e9finir les fronti\u00e8res (\u2018boundaries\u2019) fonctionnelles de l\u2019application, du point de vue de l\u2019utilisateur, afin de d\u00e9terminer ce qui est dans l\u2019application, et donc le code correspondant \u00e0 analyser, et ce qui est externe \u00e0 l\u2019application et donc hors de l\u2019analyse automatis\u00e9e des Points de Fonction.<\/p>\n

Prenons comme exemple une application toute simple de Gestion des feuilles d\u2019activit\u00e9s (Timesheets) pour une SSII, dans laquelle un prestataire va saisir les t\u00e2ches et temps pass\u00e9s pour un client, \u00e0 fin de facturation. Cette application ne va pas g\u00e9rer elle-m\u00eame les employ\u00e9s de la soci\u00e9t\u00e9 de services, mais r\u00e9cup\u00e9rer ces informations depuis le syst\u00e8me de gestion des Ressources Humaines. De m\u00eame, les diff\u00e9rents types d\u2019activit\u00e9, facturables ou non, et leur code, sont habituellement g\u00e9r\u00e9s par le syst\u00e8me comptable. Et les informations concernant le client et la prestation \u00e0 r\u00e9aliser devraient se retrouver dans le syst\u00e8me commercial.<\/p>\n

Si notre application de Gestion des Timesheets effectue elle-m\u00eame les traitements d\u2019acc\u00e8s aux donn\u00e9es de ces autres syst\u00e8mes, alors ceux-ci sont internes \u00e0 l\u2019application et donc doivent \u00eatre pris en compte dans notre \u00e9valuation de Points de Fonction automatis\u00e9s. Si au contraire, il est fait appel \u00e0 des composants de ces autres syst\u00e8mes afin d\u2019obtenir les donn\u00e9es n\u00e9cessaires, alors ces traitements sont externes et ne sont pas dans le p\u00e9rim\u00e8tre d\u2019analyse.<\/p>\n

Parfois, pour ne pas dire souvent, le choix sera difficile voire impossible. Si vous avez des web-services entre vos applications, o\u00f9 les rattacher ? A quelle application ? Doivent-ils \u00eatre pris en compte ? Vous avez des Copybooks, \u00e9quivalents \u00e0 des \u2018includes\u2019 pour une application Mainframe-Cobol, qui d\u00e9crivent les tables DB2, et sont r\u00e9utilisables par toutes les applications acc\u00e9dant \u00e0 ces tables. Si 15 applications utilisent une m\u00eame table, elles travailleront toutes avec un m\u00eame Copybook. A quelle application rattacher celui-ci ? Comment faire lorsque nous sommes en face d\u2019un ERP ou autre progiciel compos\u00e9 de diff\u00e9rents modules fortement int\u00e9gr\u00e9s et imbriqu\u00e9s ?<\/p>\n

D\u00e9coupage du code applicatif<\/h3>\n

Evidemment, vous devez vous poser ces m\u00eames questions chaque fois que vous configurez une nouvelle analyse de code, que ce soit pour compter des Points de Fonction ou non. Mais si vous vous int\u00e9ressez uniquement \u00e0 la qualit\u00e9 du code, savoir si tel composant appartient ou non \u00e0 telle application n\u2019est pas critique : vous souhaitez seulement contr\u00f4ler si ce composant pr\u00e9sente ou non des violations aux bonnes pratiques de programmation. C\u2019est ce qui se passe g\u00e9n\u00e9ralement, par exemple pour des applications Mainframe Cobol, m\u00eame si l\u2019on va souvent tenter de d\u00e9couper celles-ci selon certains crit\u00e8res utiles pour notre \u00e9valuation de la qualit\u00e9, par exemple selon leur nature Batch ou Transactionnelle, parce qu\u2019un d\u00e9faut en mati\u00e8re de performance sera plus grave pour une application TP avec un utilisateur devant son \u00e9cran que pour une application Batch sans utilisateur et qui s\u2019ex\u00e9cute durant la nuit.<\/p>\n

Lorsque les fronti\u00e8res applicatives ne sont pas pr\u00e9cises, le second crit\u00e8re le plus utilis\u00e9 en mati\u00e8re de d\u00e9coupage du code et de configuration des analyses sera organisationnel : rassembler tous les composants g\u00e9r\u00e9s par une m\u00eame \u00e9quipe, et localis\u00e9 g\u00e9n\u00e9ralement dans un espace (r\u00e9pertoire r\u00e9seau, biblioth\u00e8que mainframe, outil de gestion de configuration, etc.) administr\u00e9 par cette \u00e9quipe. Ce d\u00e9coupage s\u2019av\u00e8re critique dans certains Use Cases, par exemple pour une Quality Gate ou un benchmarking sur la qualit\u00e9 de code entre vos outsourceurs ou vos \u00e9quipes internes. Dans ces cas l\u00e0, vous vous int\u00e9ressez aux d\u00e9fauts ajout\u00e9s ou corrig\u00e9s dans les versions successives de l\u2019application, afin de d\u00e9cider de l\u2019acceptation ou du rejet d\u2019une nouvelle version ou si votre outsourceur travaille correctement ou non, s\u2019il fait ou non les efforts n\u00e9cessaires pour s\u2019am\u00e9liorer et comment il se compare avec vos autres fournisseurs.<\/p>\n

C\u2019est \u00e9galement ce crit\u00e8re organisationnel \u2013 qui g\u00e8re quel composant – que nous devons privil\u00e9gier si l’on souhaite mesurer la productivit\u00e9 des d\u00e9veloppeurs. Mais je vois poindre quelques difficult\u00e9s suppl\u00e9mentaires. D\u2019abord, la n\u00e9cessit\u00e9 de pr\u00e9cision et de rigueur est bien plus importante. Si vous dites \u00e0 un d\u00e9veloppeur que vous avez trouv\u00e9 la m\u00eame violation aux bonnes pratiques de programmation dans 10 composants qu\u2019il a modifi\u00e9s, et qu\u2019en fait l\u2019un d\u2019entre eux ne rel\u00e8ve pas de sa responsabilit\u00e9, il n\u2019en reste pas moins qu\u2019il a r\u00e9p\u00e9t\u00e9 cette malpractice dans 9 composants sur 10, et donc qu\u2019il doit s\u2019am\u00e9liorer. En fait, dans le cas d\u2019une Quality Gate, une seule occurrence suffit, si elle est bloquante. Mais si vous dites \u00e0 un d\u00e9veloppeur ou un outsourcer qu\u2019il ne travaille pas assez, et que vous omettez un seul composant dans votre analyse automatis\u00e9e des Points de Fonction, votre conclusion sera forc\u00e9ment contest\u00e9e. Un d\u00e9veloppeur peut passer plusieurs heures ou plusieurs jours sur une simple m\u00e9thode ou une unique fonction. Omettre un seul objet parmi plusieurs milliers peut fausser les r\u00e9sultats, et donc une rigueur extr\u00eame est n\u00e9cessaire dans le cadre de ce Use Case particulier des Points de Fonction automatis\u00e9s.<\/p>\n

Autre probl\u00e8me : vous ne vous int\u00e9ressez qu\u2019au code modifi\u00e9 par l\u2019\u00e9quipe de projet, car de m\u00eame que vous ne pouvez pas tenir un outsourceur responsable des d\u00e9fauts d\u00e9j\u00e0 pr\u00e9sents dans le code qu\u2019il a re\u00e7u pour maintenance, de m\u00eame vous n\u2019allez pas mesurer sa productivit\u00e9 sur du code qu\u2019il n\u2019a pas r\u00e9alis\u00e9. Or vous ne pouvez pas mesurer les Points de Fonction uniquement sur du code modifi\u00e9 : vous devez identifier des structures fonctionnelles et les transactions rattach\u00e9es \u00e0 celles-ci, depuis la couche de pr\u00e9sentation jusqu\u2019\u00e0 la couche de donn\u00e9es. Ce n\u2019est possible qu\u2019en r\u00e9-analysant toute l\u2019application et en calculant la diff\u00e9rence en nombre de Points de Fonction avec une version pr\u00e9c\u00e9dente, en admettant que cette norme s\u2019applique \u00e0 des versions nouvelles (cf. la limitation \u00e9voqu\u00e9e ci-dessus).<\/p>\n

C\u2019est donc plus compliqu\u00e9 mais \u00e9galement plus d\u00e9licat \u00e0 interpr\u00e9ter. Imaginons deux \u00e9quipes qui ont produit toutes deux 100 Points de Fonction, la premi\u00e8re dans une application qui mesure 1 000 FP, la seconde dans une application qui en compte 10 000. J\u2019imagine que l\u2019effort n\u2019est pas le m\u00eame, de la m\u00eame mani\u00e8re qu\u2019on ne peut comparer le travail d\u2019ajout de 1 000 lignes de code (LOC) dans une application selon qu\u2019elle en compte 10 000 ou 100 000. D\u2019ailleurs, certains experts consid\u00e8rent que le comptage des Points de Fonction doit \u00eatre effectu\u00e9 diff\u00e9remment pour des tailles d\u2019application tr\u00e8s petites ou tr\u00e8s \u00e9lev\u00e9es.<\/p>\n

Derni\u00e8re chose : vous devez exclure de votre analyse les librairies, frameworks, composants r\u00e9utilisables et autres d\u00e9pendances externes \u00e0 votre application, mais \u00e9galement toutes les tables ou fichiers qui ne rel\u00e8vent pas de l\u2019application. Cependant, il faudra analyser ces objets afin de trouver les transactions entre les diff\u00e9rentes couches de l\u2019application, et donc prendre en compte ceux-ci dans l\u2019analyse mais \u00ab les identifier clairement comme externe \u00bb \u00e0 celle-ci, comme indiqu\u00e9 dans les sp\u00e9cifications de la norme OMG.<\/p>\n

Ce document souligne l\u2019importance de cette \u00e9tape de d\u00e9finition du p\u00e9rim\u00e8tre d\u2019analyse, et requiert pour ce faire la pr\u00e9sence d\u2019un Subject Matter Expert (SME), voire d\u2019un \u00ab application owner \u00bb.<\/p>\n

Analyse<\/h3>\n

Le reste du document recense et pr\u00e9cise les diff\u00e9rentes \u00e9tapes du processus de comptage. Retenons la n\u00e9cessit\u00e9 :<\/p>\n

    \n
  • d\u2019identifier toutes les fonctions dans le code et de les classer en Data functions et Transactional functions,<\/li>\n
  • tout en prenant en compte le caract\u00e8re externe ou interne des structures de donn\u00e9es de l\u2019application,<\/li>\n
  • avant de proc\u00e9der \u00e0 l\u2019estimation des Points de Fonctions pour chacune d\u2019entre elles.<\/li>\n<\/ul>\n

    Ces requirements n\u00e9cessitent que le logiciel d\u2019analyse de code soit en mesure de prendre en compte les bases de donn\u00e9es relationnelles ou non \u2013 certaines applications Cobol utilisent des bases de donn\u00e9es hi\u00e9rarchiques \u2013 mais aussi toutes sortes de fichiers, ce qui n\u2019est pas le plus naturel pour un tel outil qui s\u2019int\u00e9resse avant tout au code.<\/p>\n

    Il faut \u00e9galement pouvoir identifier chaque structure logique de donn\u00e9es afin de pouvoir \u2018mapper\u2019 celles-ci avec les transactions. Or ces structures peuvent \u00eatre r\u00e9parties sur plusieurs tables, et le document pr\u00e9cise les contraintes \u00e0 respecter pour identifier les structures de type \u2018master-detail\u2019. Dans notre exemple de Gestion des Timesheets, un m\u00eame prestataire remplit plusieurs timesheets, \u00e9ventuellement pour diff\u00e9rents clients. Chaque timesheet sera compos\u00e9 de plusieurs activit\u00e9s, ce qui signifie que la table \u2018Timesheet\u2019 sera de nature \u2018detail\u2019 pour les entit\u00e9s \u2018Prestataire\u2019 ou \u2018Client\u2019, et \u2018master\u2019 pour les \u2018Activit\u00e9s\u2019.<\/p>\n

    La norme OMG recommande de s\u2019appuyer sur les conventions de nommage afin de reconna\u00eetre les tables, vues, index, cl\u00e9s, etc. qui permettent d\u2019identifier ces structures de donn\u00e9es et leurs relations.
    \nCela suppose que :<\/p>\n

      \n
    • ces conventions de nommage existent,<\/li>\n
    • qu\u2019elles soient appliqu\u00e9es par l\u2019\u00e9quipe de projet,<\/li>\n
    • que le logiciel d\u2019analyse soit configur\u00e9 afin de reconna\u00eetre ces r\u00e8gles.<\/li>\n<\/ul>\n

      Il faut \u00e9galement pouvoir analyser tout type de fichier et leur structure interne \u2013 tabulaire (flat-files, fichiers CSV, etc.) ou arborescente (xml, html, etc.). Sauf que dans ce cas, nous ne disposons pas de cl\u00e9s ou indexs pour identifier les structures de donn\u00e9es logiques, et que le software de calcul des AFP devra effectuer un choix \u2013 le plus souvent consid\u00e9rer ce fichier comme une entit\u00e9 logique unique \u2013 qui ne sera pas forc\u00e9ment celui effectu\u00e9 par un consultant IFPUG.<\/p>\n

      Il faut aussi pouvoir d\u00e9finir si un fichier est temporaire ou non, et si les donn\u00e9es qu\u2019il contient sont ou non g\u00e9r\u00e9es par l\u2019utilisateur. Par exemple, un fichier log ou d\u2019erreurs, utilisable uniquement par le programmeur, doit \u00eatre exclu du p\u00e9rim\u00e8tre d\u2019analyse.<\/p>\n

      Une fois les structures de donn\u00e9es identifi\u00e9es, il faut pouvoir faire de m\u00eame avec les transactions qui g\u00e8rent ces donn\u00e9es \u00e0 travers les couches de l\u2019application, et identifier celles en entr\u00e9e (inputs) de celles en sortie (outputs), \u00e0 travers les op\u00e9rations r\u00e9alis\u00e9es selon qu\u2019il s\u2019agit de lire ou d\u2019\u00e9crire ou de modifier\/supprimer ces donn\u00e9es. Ceci suppose, selon la norme, de :<\/p>\n

        \n
      • \u00ab capturer les transactions depuis l\u2019interface utilisateur \u00bb,<\/li>\n
      • \u00ab d\u2019identifier les \u00e9v\u00e9nements utilisateur qui interagissent avec la couche de donn\u00e9es \u00bb et<\/li>\n
      • \u00ab les outputs utilisateur cr\u00e9\u00e9s depuis ces fonctions de [manipulation de] donn\u00e9es.<\/li>\n<\/ul>\n

        Toujours selon le document, identifier ces transactions n\u00e9cessite de :<\/p>\n

          \n
        • pouvoir trouver tous les liens entre les diff\u00e9rents objets, qui constituent un chemin depuis le d\u00e9but et jusqu\u2019\u00e1 la fin de la transaction ;<\/li>\n
        • pouvoir prendre en compte les multiples chemins existants, afin d\u2019y rattacher toutes les op\u00e9rations sur les structures de donn\u00e9es, en une unique transaction ;<\/li>\n
        • pouvoir d\u00e9clarer dans l\u2019outil des \u00e9l\u00e9ments de code externe et non analys\u00e9s, afin de pouvoir reconstituer ces transactions, ou tout au moins, lister les \u00e9l\u00e9ments manquants. Afin de pouvoir reconstituer une transaction compl\u00e8te, il faut parfois analyser des \u00e9l\u00e9ments externes \u00e0 l\u2019application, donc inclure ceux-ci dans le p\u00e9rim\u00e8tre d\u2019analyse tout en les excluant du comptage.<\/li>\n<\/ul>\n

          Automated Function Points : quelle mesure ?<\/h2>\n

          Comme nous pouvons le voir, le document de la norme OMG pr\u00e9cise les conditions n\u00e9cessaires \u00e0 l\u2019utilisation des Points de Fonction Automatis\u00e9s, ainsi que ses limites. Les points qui me paraissent plus importants \u00e0 retenir sont les suivants.<\/p>\n

          P\u00e9rim\u00e8tre<\/h3>\n

          La norme ne s\u2019applique pas \u00e0 \u00ab la mesure des \u00e9volutions d\u2019une application ou de la maintenance de fonctionnalit\u00e9s \u00bb, et donc ne concernerait que les nouveaux d\u00e9veloppements. Si c\u2019est bien le cas, cela limite fortement son usage et son int\u00e9r\u00eat.<\/p>\n

          Mesures AFP et IFPUG<\/h3>\n

          La norme ne pr\u00e9tend pas \u00e0 une stricte conformit\u00e9 avec un comptage manuel des Points de Fonction, puisque \u00ab le comptage des Automated Function Points … peut diff\u00e9rer des comptages manuels produits par un consultant IFPUG certifi\u00e9 \u00bb.<\/p>\n

          Ceci me para\u00eet un premier point important \u00e0 souligner : les Points de Fonction Automatis\u00e9s ne sont pas les Points de Fonction IFPUG. Il s\u2019agit d\u2019une autre mesure, qui pr\u00e9sente l\u2019avantage d\u2019\u00eatre calculable de mani\u00e8re automatique par un outil, et donc avec moins d\u2019efforts qu\u2019un comptage manuel, mais pour un r\u00e9sultat diff\u00e9rent \u00e9galement.<\/p>\n

          Param\u00e9trage<\/h3>\n

          Le comptage de Points de Fonction automatis\u00e9s n\u00e9cessite d\u2019identifier et d\u2019assembler en composants fonctionnels toutes les structures de donn\u00e9es et les transactions, et de d\u00e9cider lesquelles sont internes ou externes, et \u00e0 prendre ou non en compte lors du param\u00e9trage de l\u2019outil et de l\u2019analyse. Ceci suppose de ma\u00eetriser :<\/p>\n

            \n
          • La connaissance de l\u2019application par un SME ou expert du projet.<\/li>\n
          • La connaissance du comptage automatis\u00e9 des Points de Fonction, afin de d\u00e9terminer le p\u00e9rim\u00e8tre d\u2019analyse et les \u00e9l\u00e9ments \u00e0 prendre en compte.<\/li>\n
          • La connaissance de l\u2019outil et de son param\u00e9trage afin de configurer l\u2019analyse, en accord avec les deux points pr\u00e9c\u00e9dents.<\/li>\n<\/ul>\n

            Cette phase de param\u00e9trage est \u00e9videmment critique si l\u2019on souhaite parvenir \u00e0 un r\u00e9sultat le plus objectif et donc le plus cr\u00e9dible possible lorsqu\u2019il s\u2019agit de mesurer la productivit\u00e9 d\u2019une \u00e9quipe.<\/p>\n

            Analyse et validation<\/h3>\n

            Le comptage de Points de Fonction automatis\u00e9s par un outil suppose que celui-ci soit capable :<\/p>\n

              \n
            • D\u2019analyser tout type de composant.<\/li>\n
            • D\u2019identifier tous les liens entre ces composants.<\/li>\n
            • D\u2019assembler tous ces liens en transactions avec le moins de false-positives possible.<\/li>\n<\/ul>\n

              Or il est bien rare qu\u2019un outil d\u2019analyse de code soit capable de reconna\u00eetre et d\u2019analyser tout type de fichier. Une fonctionnalit\u00e9 importante d\u2019une application de Gestion des Timesheets comme celle de notre exemple sera la production de rapports \u2013 les feuilles d\u2019activit\u00e9 \u2013 pour validation avant facturation, g\u00e9n\u00e9ralement sous diff\u00e9rents formats : Excel, PDF, etc. Je ne connais aucun outil d\u2019analyse de code qui g\u00e8re ce type de fichiers.<\/p>\n

              Trouver tous les liens entre composants peut s\u2019av\u00e9rer difficile, voire impossible pour certaines technologies. L\u2019utilisation de frameworks (Spring, Hibernate, etc.) rend complexe ce type d\u2019analyse et suppose un travail important de validation des r\u00e9sultats afin d\u2019\u00e9viter le plus possible les false-positives, puis de v\u00e9rifier les transactions identifi\u00e9es et le comptage des Points de Fonction pour celles-ci.<\/p>\n

              Conclusion<\/h3>\n

              En conclusion, je pense que les Automated Function Points sont une mesure diff\u00e9rente, qui produira des r\u00e9sultats diff\u00e9rents d\u2019une estimation manuelle conduite par un consultant IFPUG. Dans une situation id\u00e9ale, il faudrait la pr\u00e9sence d\u2019un tel consultant afin de participer \u00e0 la d\u00e9finition du p\u00e9rim\u00e8tre d\u2019analyse, le param\u00e9trage de l\u2019outil, la validation des r\u00e9sultats, ceci en supposant que l\u2019outil soit capable d\u2019identifier tous les composants, les liens entre ceux-ci, les structures de donn\u00e9es, les transactions, etc.<\/p>\n

              M\u00eame dans un tel cas id\u00e9al, je pense que la diff\u00e9rence entre une estimation manuelle et une mesure des AFP sera au minimum de 10% \u00e0 20%, et plus souvent entre 40% et 50%. Cela me para\u00eet un minimum sur certaines applications ou technologies, et l\u2019\u00e9cart pourrait s\u2019av\u00e9rer plus important, par exemple pour une application Cobol Batch (beaucoup de fichiers), un logiciel int\u00e9gr\u00e9 avec diff\u00e9rents modules (type ERP), en cas d\u2019utilisation de frameworks, etc.<\/p>\n

              Automated Function Points : pour qui ?<\/h2>\n

              La mise en oeuvre des AFP suppose un effort important, qui doit \u00eatre r\u00e9p\u00e9t\u00e9 chaque fois que l\u2019application subira des \u00e9volutions importantes dans ses fonctionnalit\u00e9s (en admettant que cette norme s\u2019applique \u00e9galement aux nouvelles versions).<\/p>\n

              Ceci \u00e9carte d\u2019embl\u00e9e l\u2019utilisation des AFP dans un cycle d\u2019int\u00e9gration continue, lorsque l\u2019analyse de code vise \u00e0 identifier des violations critiques ou bloquantes aux bonnes pratiques de programmation, afin par exemple de corriger celles-ci avant une Quality Gate ou pour \u00e9viter l\u2019inflation de la Dette Technique. Je ne vois donc pas comment les d\u00e9veloppeurs pourraient s\u2019int\u00e9resser aux AFP et les int\u00e9grer dans un cycle de d\u00e9veloppement logiciel.<\/p>\n

              Cela ne signifie pas que les AFP ne pr\u00e9sentent pas d\u2019int\u00e9r\u00eat. Deux consultants IFPUG proc\u00e9dant \u00e0 une estimation manuelle de Points de Fonction parviendront assez souvent \u00e0 des r\u00e9sultats diff\u00e9rents, alors qu\u2019une mesure automatis\u00e9e produira un m\u00eame r\u00e9sultat, de mani\u00e8re r\u00e9p\u00e9table. L\u2019effort de mise en \u0153uvre, m\u00eame s\u2019il est important, sera n\u00e9anmoins inf\u00e9rieur \u00e0 l\u2019investissement requis pour une estimation manuelle, notamment pour des applications volumineuses.<\/p>\n

              Simplement, il s\u2019agit d\u2019une autre mesure qui n\u00e9cessite une validation importante des \u00e9l\u00e9ments d\u2019analyse \u2013 inputs\/outputs, internes\/externes, structures de donn\u00e9es et transactions, false positives, etc \u2013 pour \u00eatre utilis\u00e9e en tant que mesure de la taille fonctionnelle d\u2019une application.
              \nJe pense qu\u2019elle est r\u00e9serv\u00e9e \u00e0 des experts en mati\u00e8re d\u2019analyse de code, mais aussi avec une bonne connaissance des Points de Fonction, si l\u2019on souhaite l\u2019utiliser pour effectuer des benchmarkings entre diff\u00e9rentes applications ou technologies.<\/p>\n

              Elle me para\u00eet dangereuse \u00e0 utiliser telle quelle pour des mesures de la productivit\u00e9 d\u2019\u00e9quipes ou d\u2019outsourceurs : il sera tr\u00e8s facile de contester les r\u00e9sultats produits dans un tel cadre.<\/p>\n

              Je pense qu\u2019elle peut \u00eatre utile dans le cadre d\u2019une r\u00e9tro-documentation, avant une reprise de l\u2019application, un refactoring ou un re-engineering (portage de l\u2019application dans une autre technologie). Dans ces cas, tout ce qui peut faciliter la compr\u00e9hension fonctionnelle de l\u2019application, l\u2019estimation de la couverture de tests et le chiffrage de la charge de travail sera le bienvenu, m\u00eame si la mesure manque de pr\u00e9cision.<\/p>\n

              Voyez-vous d\u2019autres cas d\u2019utilisation pour une telle mesure ?<\/p>\n

               <\/p>\n

              (1) IFPUG : International Function Points User Group, qui produit le Function Point Counting Practices Manual (FP CPM).<\/p>\n","protected":false},"excerpt":{"rendered":"

              Nous nous sommes demand\u00e9, dans le post pr\u00e9c\u00e9dent, pourquoi les d\u00e9veloppeurs ne connaissaient g\u00e9n\u00e9ralement pas les Points de Fonction, et si cette m\u00e9trique pouvait leur \u00eatre utile. Notre r\u00e9ponse est plut\u00f4t n\u00e9gative, surtout si l\u2019on consid\u00e8re qu\u2019une telle estimation est r\u00e9alis\u00e9e manuellement, par des consultants qui s\u2019appuient sur une d\u00e9marche assez complexe. Il existe d\u2019ailleurs […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2443","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2443"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=2443"}],"version-history":[{"count":15,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2443\/revisions"}],"predecessor-version":[{"id":2460,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2443\/revisions\/2460"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=2443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=2443"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=2443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}