- Ce sujet a 18 réponses, 9 voix, et a été mis à jour pour la dernière fois 6 ans, 3 mois depuis par
.
-
Des postes
-
Bonjour à tous,
Je ne savais pas dans quel sujet je devais poster ma question, donc je le mets ici. Je pense que les points de fonction sont un excellent moyen d'attacher une sorte de mesure de taille à un morceau de code, mais c'est tellement compliqué de les compter. Je dois passer en revue toutes les exigences d'E/S et les structures de données pour obtenir un nombre raisonnablement bon. J'ai trouvé des outils qui peuvent compter automatiquement, mais ils sont assez chers et je cherchais une certaine expérience avec ce genre d'outils. Y a-t-il quelqu'un dans cette communauté qui a de l'expérience avec le comptage FPA automatisé?
Ian
cher Monsieur,
En répondant à ta question: J'ai de l'expérience dans le comptage automatisé FPA.
Le dernier 5 ans, J'ai passé beaucoup de temps à développer un outil de comptage automatisé de FPA. Cet outil est basé sur le traitement automatique du langage naturel et peut lire du texte en anglais et en néerlandais. Donc, si vous avez des documents comme une conception fonctionnelle, Exigences, Cas d'utilisation, etc., cet outil peut donner une estimation du nombre de FPA. Il peut traiter plusieurs documents en même temps. Il peut également donner une estimation du nombre de documents de conception SAP tels que Blue Prints, etc.. Le compte est basé sur Nesma 2.2 version.
Si vous voulez plus d'informations, m'a envoyé un email.
Les salutations
Pierre Bellen
Pays-Bas
pwhbellen@hotmail.comIan,
Basé sur (IFPUG) FPA, l'Object Management Group a publié le Spécifications FPA automatisées au début 2014. je sais que Logiciel CAST dispose d'un outil de travail qui compte les points de fonction, basé sur les spécifications OMG. Cet outil est assez cher.
Je sais qu'au sein de la communauté COSMIC, il y a beaucoup de travail en cours pour automatiser le processus de comptage. Renault a un outil de travail en marche, mais ce n'est pas disponible pour un usage commercial. Je sais que Dutchsoft dispose d'un outil semi-automatisé pour les points d'écoute des fonctions SAP, mais ce n'est disponible que comme service. Des articles de Renault et de Dutchsoft ont été présentés au 2014 Conférence IWSM Mensura à Rotterdam. Les papiers sont disponibles auprès de 2014.iwsm-mensura.org.
Peter,
Y a-t-il beaucoup de différence entre Nesma 2.2 (semble être uniquement en néerlandais) et le 2.1 version? Et entre Nesma et IFPUG?
Franc,
Avez-vous des références à COSMIC qui sont accessibles au public? Le lien IWSM m'envoie vers un site IEEE où je dois payer les documents.
Salut Ian,
Je viens de CAST. Depuis que tu l'as mentionné, Je ne nie pas qu'il y ait un certain prix associé à notre logiciel ;-).
L'une des raisons pour lesquelles CAST est en mesure de compter automatiquement les APF est l'investissement de 120 M USD qui a été investi dans R&D afin de proposer un produit capable de déterminer avec suffisamment de précision la structure interne d'applications multicouches complexes et de fournir une analyse précise, répétables, et au fil du temps, comptage automatisé assez rentable des AFP et EFP (Points de fonction d'amélioration).À votre question sur le partage d'expérience sur les APF, il y a eu une adoption importante des AFP CAST dans un certain nombre de comptes et chez plusieurs grands intégrateurs de systèmes au cours de la dernière année environ. Si vous m'écrivez, Je peux vous orienter vers des contacts pertinents pour votre intérêt. Juste dans la première page de la liste des comptes des membres Nesma, je pourrais repérer 2 les principaux SI qui ont des CAST COE avec une expérience significative sur le sujet.
Cordialement
Gérard
g.karsenti@castsoftware.comIan,
Si vous allez à dimensionnement cosmique.org vous trouverez des articles sur le sujet téléchargeables gratuitement. L'investissement dans certains des papiers est très faible par rapport à l'investissement de CAST ;-). Vous pouvez également poster votre question dans le Groupe d'utilisateurs COSMIC sur Linkedin. Je sais qu'un certain nombre de personnes impliquées dans le développement automatisé de COSMIC sont membres de ce groupe.
Je peux également répondre aux questions que vous avez posées à Peter. Nesma 2.2 est la version néerlandaise de l'anglais 2.1 la norme. Puisque la version anglaise est compatible avec l'ISO/IEC 24570 standard, il a un chapitre supplémentaire 1 avec les trucs ISO, mais à part ça ils sont identiques. En ce qui concerne les différences entre Nesma et IFPUG, il existe un document dans le Section de téléchargement d'articles de ce site Web qui explique les différences.
Actuellement, l'ISO/CEI 24570 est sous Revue systématique et la Nesma Comité des pratiques de comptage a publié une liste de maintenance avec des améliorations. Lorsque ces améliorations seront acceptées, cela conduira à une nouvelle version des directives de comptage. Nous ferons en sorte que les versions anglaise et néerlandaise soient identiques alors, pour éviter les confusions.
Cordialement, Franc
Une question adressée aux fournisseurs de logiciels de comptage automatique de points de fonction: envisagez-vous de proposer votre logiciel en tant que service tel qu'un modèle de paiement à l'utilisation?
Aussi, Je n'ai pas encore rencontré d'évaluations de l'AFPC qui répondent à toutes les questions suivantes sur l'échantillon sur lequel l'évaluation est basée:
– Distance moyenne (taux d'erreur) du comptage automatisé du comptage expert (+ratio médian si la distribution est asymétrique)
– Ecart type de la distance moyenne
– taille de l'échantillon (N)
– Classe de taille des dénombrements de l'échantillon (par example 100-500 FP, 500-1500 FP, etc. — si l'échantillon est mélangé, fournir les mesures ci-dessus par classe de taille)
– Type de comptage (comme le système, Renforcement,… — si l'échantillon est mélangé, fournir les mesures ci-dessus par type de comptage)
– Idem pour le type de système (embarqué, affaires, interactif, grouper,…)Jusqu'à présent j'ai toujours eu l'impression qu'il manquait l'un ou l'autre aspect pour pouvoir passer un appel. Par exemple, si l'erreur moyenne est donnée comme 5%, mais aucune indication sur la classe de taille de comptage n'est donnée, Je ne peux pas juger si la mesure serait adaptée aux comptages de systèmes individuels. Pour ce que ça vaut, il ne pourrait convenir qu'aux comptes de portefeuille d'une taille supérieure à 50,000 FP (loi des grands nombres). Connaissez-vous des articles qui évaluent les logiciels de points de fonction et sont suffisamment complets pour couvrir tous ces aspects?
Bonjour,
J'ai fait quelques articles sur la norme OMG et ce qu'il faut pour qu'un logiciel SCA compte l'AFP sur le Blog Qualilogie.
Jean-Pierre,
Ceci est un article de blog intéressant. je peux conseiller à tout le monde de le lire. Pour le bien de cette discussion, j'ai copié certaines de vos observations:
Comme on peut le voir, le document de la norme OMG précise les exigences pour l'utilisation des points de fonction automatisés, ainsi que ses limites. Les points que je pense les plus importants à retenir sont les suivants.
Périmètre
La norme ne traite pas du dimensionnement des améliorations apportées à une application ou des fonctionnalités maintenues (souvent appelés points de fonction d'amélioration) » et ne s'appliquerait donc qu'aux nouveaux développements. Si c'est le cas, cela limite beaucoup son utilisation et son intérêt.AFP et IFPUG
La norme AFP ne revendique pas un strict respect d'un comptage manuel des points de fonction: « Le nombre de points de fonction automatisés peut différer des décomptes manuels produits par les compteurs de points de fonction certifiés IFPUG ». Cela me semble un premier point important: Les points de fonction automatisés ne sont pas des points de fonction IFPUG. C'est une autre mesure, qui a l'avantage d'être calculable automatiquement par un outil, et donc avec moins d'effort qu'un comptage manuel, mais aussi avec un résultat différent.Configuration
Comptage AFP nécessite d'identifier et d'assembler en composants fonctionnels toutes les structures de données et les transactions, et décider lesquels sont internes ou externes, et dont il faut tenir compte ou non lors de la mise en place de l'outil et du paramétrage de l'analyse. Cela suppose que vous ayez des personnes disponibles ayant une bonne connaissance de:- La candidature par une PME ou un expert du projet.
- Le processus de comptage des points de fonction automatisés pour déterminer la portée de l'analyse et les facteurs à prendre en compte.
- L'outil et ses paramètres pour configurer l'analyse, vérifier les faux positifs et valider les résultats, conformément aux deux points précédents.
- Cette phase de configuration est évidemment critique si l'on veut atteindre un résultat plus objectif, et donc le plus crédible possible lorsqu'il s'agit de mesurer la productivité d'une équipe.
Analyse et validation
Compter les points de fonction automatisés avec un outil suppose que cet outil est capable de:- Analyser tout type de composant.
- Identifier tout lien entre ces composants.
- Assemblez tous ces liens en transactions avec le moins de faux positifs possible.
Mais il est rare qu'un outil d'analyse de code dispose d'un parseur capable de reconnaître et d'analyser tout type de fichier sur une technologie donnée, et moins sur différentes technologies. Un outil peut être capable de reconnaître des opérations telles que « lecture » ou « écriture » sur un fichier plat dans une application Batch, d'identifier les différents types de liens entre les fichiers xml d'un framework Java et de ne pas pouvoir analyser un rapport Html ou Excel. Une fonctionnalité importante de notre application Timesheet dans notre exemple sera de produire des feuilles d'activité pour validation avant facturation, généralement sous différents formats: Exceller, PDF, etc. Je ne connais aucun outil d'analyse de code qui gère ce type de fichier.
Trouver tous les liens entre les composants peut être difficile voire impossible pour certaines technologies. L'utilisation de cadres (Printemps, Hiberner, etc.) complique l'analyse, et cela implique un travail important pour valider les résultats afin d'éviter au maximum les faux positifs, puis vérifier les transactions identifiées et le comptage des Points de Fonction pour chacune d'entre elles.Conclusion
En conclusion, Je pense que les points de fonction automatisés sont une mesure différente, qui produit des résultats différents d'une estimation manuelle réalisée par un consultant IFPUG. Dans une situation idéale, ce serait formidable d'avoir un tel consultant pour participer à la définition du périmètre d'analyse, les réglages de l'outil, la validation des résultats. Ceci en supposant que l'outil est capable d'identifier tous les composants, les liens entre eux, structures de données, transactions, etc.Même dans un cas aussi idéal, Je pense que la différence entre une estimation manuelle et des points de fonction automatisés est d'au moins 10% à 20%, plus souvent entre 40% et 50%. Au minimum. Cela pourrait aussi être 200% ou 300% différent, par exemple pour une application Cobol Batch (de nombreux fichiers plats), un logiciel intégré (ERP) avec différents modules, dans le cas d'un cadre qui ne permet pas d'identifier clairement les transactions, etc.
Vous posez des difficultés pratiques. Maintenant, je peux comprendre pourquoi CAST a investi 120 millions de dollars pour le faire fonctionner.
À vous tous,
Grand débat. Nous allons repenser si nous allons commencer par un comptage automatisé. J'ai vu des approches rapides dans les documents Nesma qui pourraient être utiles. Je reviendrai peut-être avec quelques questions à ce sujet.
A Jean-Pierre,
Dommage que la discussion sur votre article de blog Qualilogy soit fermée, donc je vais mettre mes points ici. L'une des objections que vous soulevez dans le blog et que Frank n'a pas copiée est que l'AFP ne travaille pas sur les améliorations.. Je pense que c'est un commentaire injuste, puisque changer de logiciel est une activité. Vous pouvez le décrire dans un document de changement, vous pouvez l'imaginer dans votre tête et ensuite vous changez le code. L'AFP mesure le code, qui est modifié ou non. Le changement n'est pas dans le code, donc un parseur ne pourra jamais le capturer. Ce n'est pas un défaut de l'AFP, c'est techniquement impossible. Vous pourrez peut-être capturer une partie du changement en comparant un nombre avant et après le changement, mais cela sera très difficile lorsque des améliorations seront apportées aux fonctions existantes.
Il y avait quelques choses dans votre blog et la réaction que je voudrais commenter. Comme je ne peux pas le faire sur Qualilogy, Je pourrais le faire ici dans un post séparé.
Ian,
Les commentaires sur mon blog ont été fermés 30 jours après la poste, afin de m'éviter d'avoir à gérer tous ces spammeurs qui essaient de vendre des pilules et toutes sortes de produits qui n'ont rien à voir avec mon blog. Je viens de le rouvrir pour que vous puissiez laisser un commentaire et que tout le monde puisse participer à une discussion, après modération.
Je ne comprends pas très bien votre point sur les changements. Frank a mentionné ci-dessus la partie sur les améliorations (voir “Périmètre”).
Et oui, Les outils SCA peuvent analyser les changements, basé sur la différence entre différentes analyses, dans le code existant ou non. Ça peut (ou devrait) dire combien de composants ont été ajoutés, supprimé, modifié, et si modifié, le changement des métriques habituelles comme LOC, CC, … et aussi sur l'AFP.Comme mentionné dans le post, c'est obligatoire pour ce que les gens veulent surtout quand il s'agit de l'AFP: estimation de la productivité. Si vous confiez la maintenance d'une application à un sous-traitant, vous devez savoir combien AFP il a ajouté, supprimé, modifié en fonction de ces changements afin de mesurer sa productivité, et le comparer avec d'autres sous-traitants ou sur différentes technologies.
Un nouvel outsourceur est-il responsable des défauts déjà présents dans le code qu'il doit maintenir? Non. Idem pour l'AFP, tu comptes ce qu'il a changé, pas ce qu'il y a dans le code que tu lui livre.Comme vous le savez tous, 90% des activités de programmation sont en maintenance, il n'y a pas tellement de nouveautés. Donc, avoir la norme OMG disant que l'AFP ne s'applique qu'aux nouveaux développements m'a vraiment surpris, car elle diminue sérieusement l'intérêt de cette mesure pour 90% des projets.
Jean-Pierre,
Désolé si je n'ai pas été assez clair. Je vais essayer de nouveau. Vous écrivez que vous avez été surpris par la déclaration OMG.
Tout d'abord. L'OMG précise que l'AFP ne s'applique pas aux améliorations. Ce n'est pas exactement la même chose que de dire que cela ne s'applique qu'aux nouveaux développements. je vais essayer d'expliquer pourquoi.
Les outils AFP fonctionnent sur du code statique, ils mesurent donc la taille du code tel qu'il est. C'est avant ou après l'entretien. Le changement de logiciel est une activité que vous pouvez décrire dans un document de changement, mais pas dans le code. Le code est soit changé, ou pas. Afin de mesurer la taille d'un projet de maintenance, vous auriez besoin de deux instances statiques du code, un avant et un après, puis analyser les différences. Je ne sais pas si c'est techniquement possible. Je ne jugerais donc pas négativement sur le fait que OMG ne réalise pas ce miracle.
Ian,
J'ai posté des réponses à vos commentaires sur mon blog http://qualilogy.com/en/do-developers-dream-of-automated-function-points-2/#comment-2312.
Prochainement:
. Oui, il faudra au moins analyser 2 versions et mémoriser les différences. C'est ce que font généralement les outils SCA.
. Il est souvent possible avec ces outils de faire une analyse incrémentielle uniquement sur (ajoutée, supprimé, modifié) Composants, mais cela ne fonctionnera pas pour l'AFP car vous devez analyser chaque transaction et les structures de données sur toutes les couches de l'application.
. Si les outils SCA peuvent le faire, pourquoi cette limitation des spécifications OMG? ce n'est pas précisé.Je serais heureux de savoir pourquoi parce que je ne peux pas comprendre, et si cette norme est limitée aux nouveaux projets uniquement, J'aimerais le savoir avant que les entreprises ne commencent à mesurer l'AFP sur l'ensemble de leur portefeuille d'applications, à qui 90% sont des applications en maintenance.
Jean-Pierre,
Merci pour vos réponses. Si les outils SCA peuvent stocker les différences, que les outils de comptage devraient être capables de faire la même chose. Peut-être que Gérard peut répondre à cette question. Je ne peux pas imaginer qu'ils n'aient pas pensé à cela comme faisant partie d'un 120 M$ d'investissement.
Chers tous,
voici ma contribution au (très stimulant) discussion.En mai 17, chez WETSOM 2015, J'ai présenté une évaluation critique de l'AFP. Vous pouvez récupérer le papier de
http://conferences.computer.org/icse/2015/content/papers/7103a035.pdf#page=1.
Si un nom d'utilisateur et un mot de passe sont demandés, envoyez moi un email et je vous les enverrai.Concernant les questions sur l'amélioration, Ian a parfaitement raison: Code de mesure AFP pouvant être le résultat d'une maintenance ou le résultat d'un nouveau développement. pourtant, à WETSOM, Bill Curtis a mentionné que le CISQ travaille sur la spécification de point de fonction d'amélioration automatisée (voir également http://it-cisq.org/cisq-to-start-work-on-automated-enhancement-function-point-specification/).
Pour terminer, il existe une activité de recherche portant sur la mesure automatisée des points de fonction basée sur l'exécution du code. L'idée est qu'en regardant les traces d'exécution, il est possible de voir quels processus ont été invoqués par les utilisateurs, quelles données ont été utilisées dans chaque processus, et quelles données ont été échangées entre les utilisateurs et le système. En pratique, par la trace d'exécution contient les informations nécessaires au calcul des points de fonction. Ces initiatives sont prometteuses, mais le code à mesurer doit être instrumenté, et actuellement il n'y a pas d'outil de support, sauf prototypes académiques et preuves de concept.
- Vous devez être connecté pour répondre à ce sujet.