Méthodes de mesure de la taille fonctionnelle

Il s'agit de la deuxième partie du blog consacrée à un certain nombre de méthodes de mesure de la taille des logiciels populaires et à leur utilité pour l'estimation de projets logiciels.. Dans cette deuxième partie les méthodes de mesure de la taille fonctionnelle IFPUG, NESMA et COSMIC sont couverts. Dans les prochains blogs, je couvrirai les méthodes de mesure de taille non fonctionnelles et les méthodes hybrides.

Il est vivement recommandé aux lecteurs intéressés par ce sujet de lire d'abord le première partie de ce blog, avant de lire cette deuxième partie.

Pour qu'une méthode de mesure de taille de logiciel particulière soit utile pour l'estimation de projet logiciel, les caractéristiques suivantes doivent s'appliquer:

• La méthode de mesure de la taille peut être effectuée dans un objectif (indépendamment de la personne qui le fait), répétables, vérifiable et donc défendable façon;
• La taille en elle-même n'est utile que lorsque données historiques est disponible des projets mesurés dans cette méthode de mesure de taille;
• Les méthodes de mesure de la taille doivent être prises en charge par modèles et / ou outils paramétriques afin de prendre en compte avec précision les caractéristiques spécifiques du projet qui influencent l'estimation, comme par exemple COCOMO II, MINCE, SEER pour le logiciel ou Véritable planification.

Bien sûr, toute méthode de mesure de la taille d'un logiciel non conforme à un ou plusieurs de ces critères peut encore être très utile pour une organisation, à condition qu'ils élaborent une procédure garantissant des mesures de taille répétables, collecter et analyser des données historiques et / ou construire leurs propres modèles d'estimation basés sur les données collectées. Pour ce blog cependant, l'accent est mis sur l'utilité théorique de la méthode de mesure spécifique à des fins d'estimation de projets logiciels dans le contexte d'organisations qui n'ont pas encore de processus d'estimation paramétrique en place. Pour ces organisations, qui sont disposés à mettre en œuvre une méthode de mesure de taille afin d'estimer des projets logiciels, ce blog peut servir de guide pour sélectionner une méthode spécifique.

J'encourage tout le monde à soumettre des commentaires et / ou des commentaires sur ce blog.

Nesma FPA

Nesma FPA est très similaire à IFPUG car il mesure les mêmes composants fonctionnels de base (BFC [24]) (ILF, FEI, NON, C'EST LE, EQ) et il y a très peu de différences maintenant entre les directives de comptage des deux méthodes. De nombreux experts utilisent la taille mesurée dans les points de fonction IFPUG comme égale à la taille dans Nesma FP. Les principaux avantages de Nesma par rapport à l'IFPUG à des fins d'estimation sont la disponibilité d'un certain nombre de méthodes dérivées considérées comme faisant partie de la norme ISO/IEC:

• FPA indicatif - Cette méthode peut être utilisée très tôt dans le cycle de vie du projet lorsque seul le modèle de données est spécifié. La précision n'est pas très élevée (-30% / +50%), mais généralement assez pour être utile à un stade précoce du cycle de vie du projet lorsque seule une estimation de ROM est nécessaire.
• APP de haut niveau (alias. FPA estimé) – Cette méthode est considérée comme la méthode principale de nos jours, car la plupart des documentations fonctionnelles manquent de détails pour pouvoir utiliser le standard Nesma (ou IFPUG) FPA. Le FPA de haut niveau utilise une évaluation de complexité fixe par composant fonctionnel de base: complexité faible pour les fichiers logiques et complexité moyenne pour les fonctions. Cette méthode peut être utilisée lorsque le modèle de données et les fonctions sont connus, mais les détails de quels attributs sont utilisés dans quelles fonctions manquent ou sont incomplets (ce qui est souvent le cas). La précision de cette méthode est d'environ -8% à +15% (voir ce papier).

en outre, Nesma fait la distinction entre taille du projet (le nombre de points de fonction ajoutés à un système existant, plus le nombre de points de fonction modifiés dans le système, plus le nombre de points de fonction supprimés, plus les points de fonction du logiciel nécessaires à réaliser pour mener à bien le projet, par exemple un logiciel de conversion) et taille du produit (la taille fonctionnelle de l'application qui est livrée aux utilisateurs).

Nesma est une communauté très active de bénévoles qui travaillent constamment sur de nouvelles façons d'utiliser la méthode sur de nouveaux types ou des types particuliers de projets logiciels. Bien que ceux-ci ne fassent pas officiellement partie de la norme ISO/IEC, ces méthodes peuvent être très utiles à des fins d'estimation logicielle. Les lignes directrices largement utilisées sont par exemple:

• FPA pour l'amélioration du logiciel
  l'utilisation de cette méthode est en fait obligatoire dans certains pays pour que les entrepreneurs puissent soumissionner sur des projets gouvernementaux.
• FPA dans les environnements SOA (uniquement en néerlandais)
• FPA dans les projets d'entrepôt de données
• FPA dans les premières phases du cycle de vie du projet
• FPA appliqué à Usecase / Documentation UML

le Base d'estimation (BoE) pour les services logiciels tels que publiés par Nesma et le AACE International, l'autorité pour la gestion des coûts totaux, est un moyen très utile de référencer toute estimation de projet logiciel, tout en prouvant que l'estimateur a pris en compte tous les aspects importants dans son estimation. La Nesma (IFPUG) la méthode est prise en charge par la plupart des modèles et outils d'estimation logiciels paramétriques commerciaux et non commerciaux.

Les caractéristiques permettant d'évaluer l'utilité de cette méthode pour l'estimation de projets logiciels sont répertoriées dans le tableau suivant:

Caractéristique	O/N	Remarques
Objectif, répétables, vérifiable et défendable	Oui	ISO / CEI 24570:2004
Données historiques disponibles	Oui	ISBSG R13: 187 projets (5433 lorsqu'il est combiné avec IFPUG)
Soutenu par des modèles / outils	Oui	QSM, SEER-SEM, Véritable planification, COCOMO II, ISBSG

 

IFPUG

La méthode IFPUG est la méthode la plus largement utilisée pour la mesure de la taille fonctionnelle. De toutes les exigences, Il ne mesure que les exigences fonctionnelles de l'utilisateur et il le fait de la même manière que les fichiers logiques internes (ILF), fichiers d'interface externe (FEI), fonctions d'entrée externes (NON), fonctions de sortie externe (C'EST LE) et enquête externe (EQ) les fonctions sont identifiées et classées en complexité. La complexité du logiciel est classée de la manière suivante: Faible, Moyen ou élevé, en fonction d'éléments tels que le nombre d'attributs de données impliqués, le nombre de fichiers référencés ou le nombre de types d'enregistrements faisant partie du fichier logique. Pour un fichier logique interne (ILF) par exemple, le nombre de points de fonction connectés à une ILF de faible complexité est 7 points de fonction (FP), un ILF de complexité moyenne obtient 10 FP et un ILF de haute complexité obtiennent 15 FP. Il y a un nombre minimum de points par fonction et un nombre maximum de points par fonction. Bien que cela simplifie quelque peu le processus d'analyse, il est perçu comme un inconvénient qu'il peut ne pas y avoir suffisamment de nuances entre la taille des différents fichiers logiques et fonctions. Par exemple, la taille d'une fonction d'entrée externe complexe est 6 FP, mais la taille d'un EI très complexe est 6 points également et la taille d'un EI extrêmement complexe est également 6 FP.

La méthode IFPUG est la plus utile comme méthode de dimensionnement pour estimer les projets qui respectent les caractéristiques suivantes (pas limité):

• Le logiciel est orienté données, beaucoup de CRUD (Créer, Lis, Mise à jour, Effacer) les fonctions sont spécifiées
• Le logiciel est orienté administratif
• Une conception fonctionnelle détaillée est disponible dans laquelle le modèle de données est complet et clair et pour toutes les fonctions, il est clair quels attributs de données sont utilisés

Lorsque la taille des exigences fonctionnelles est mesurée, il existe de nombreuses façons de le convertir en estimation. L'utilisation des données historiques de l'organisation qui va réaliser le logiciel est généralement la meilleure voie à suivre, de préférence soutenu par des outils d'estimation professionnels. Si les données historiques ne sont pas disponibles, la base de données ouverte de l'International Software Benchmarking Standards Group peut s'avérer très utile. Il contient plus 6700 projets (Libération 13) et beaucoup d'entre eux ont été mesurés dans IFPUG. La méthode IFPUG est prise en charge par la plupart des modèles et outils d'estimation de logiciels paramétriques commerciaux et non commerciaux.

Les caractéristiques permettant d'évaluer l'utilité de cette méthode pour l'estimation de projets logiciels sont répertoriées dans le tableau suivant:

Caractéristique	O/N	Remarques
Objectif, répétables, vérifiable et défendable	Oui	ISO / CEI 20926:2009
Données historiques disponibles	Oui	ISBSG R13: 5244 projets
Soutenu par des modèles / outils	Oui	QSM, SEER-SEM, Véritable planification, COCOMO II, ISBSG

 

COSMIQUE

Consortium international de mesure commune des logiciels (COSMIQUE) est un volontaire, groupement mondial d'experts en métriques logicielles. Commencé en 1998, COSMIC a développé une méthode de mesure de la taille fonctionnelle des logiciels qui a été conçue pour surmonter certains des défauts perçus de Nesma et IFPUG FPA. Alors que Nesma et IFPUG sont principalement utilisés pour mesurer la taille des logiciels administratifs, COSMIC est également applicable pour mesurer la taille des logiciels temps réel et d'infrastructure. La méthode est entièrement "ouverte"; toute la documentation de la méthode est disponible dans le domaine public en téléchargement gratuit.

L'un des principaux avantages de la méthode COSMIC est le fait qu'elle permet au spécialiste de la mesure de diviser le logiciel en couches logicielles et composants pairs, qui permet de mesurer la taille fonctionnelle du logiciel résidant dans des couches d'architecture séparées ou dans différents composants qui communiquent entre eux. Cela surmonte l'un des inconvénients perçus des méthodes Nesma et IFPUG, qui ne permettent pas au logiciel d'être divisé de telle manière.

Un autre avantage important est le fait que la méthode suit une échelle de rapport. Par conséquent, la taille fonctionnelle par processus fonctionnel peut être n'importe quelle taille entre 2 Points de fonction COSMIC (la valeur minimale par processus fonctionnel) et (théoriquement) infini.

Habituellement, la méthode COSMIC est très bien applicable pour être utilisée dans des projets développés avec une méthodologie agile. Le type de documentation que ces types de projets fournissent souvent (par exemple. Histoires d'utilisateurs, cas d'utilisation, diagrammes d'activité, diagrammes de séquence, diagrammes de classes) sont généralement faciles à mesurer avec COSMIC de manière très précise.

Bien que l'utilisation de COSMIC augmente et que le nombre de praticiens certifiés augmente, encore peu de données d'analyse comparative ouvertes sont disponibles. La version du référentiel des nouveaux développements et améliorations de l'ISBSG 13 (sortie en février 2014) contient environ 500 projets mesurés en COSMIC, tandis que le nombre de projets mesurés en points de fonction IFPUG est bien supérieur 5000 projets.

La méthode COSMIC est généralement particulièrement bien applicable lors de l'utilisation de la taille fonctionnelle pour estimer les types de projets suivants:

• Projets logiciels temps réel;
• Projets de logiciels d'applications mobiles;
• Projets logiciels d'infrastructure;
• Projets logiciels qui fournissent des logiciels dans une architecture en couches;
• Projets logiciels administratifs.

La documentation fonctionnelle doit au moins montrer les processus fonctionnels mis en œuvre par le logiciel et les mouvements de données entre les utilisateurs et le logiciel.

Les caractéristiques permettant d'évaluer l'utilité de cette méthode pour l'estimation de projets logiciels sont répertoriées dans le tableau suivant:

Caractéristique	O/N	Remarques
Objectif, répétables, vérifiable et défendable	Oui	ISO / CEI 19761:2003
Données historiques disponibles	Oui	ISBSG R13: 488
Soutenu par des modèles / outils	Oui	QSM, SEER-SEM, Véritable planification, ISBSG

Il existe deux autres normes ISO/CEI pour la mesure de la taille fonctionnelle, FISMA et Mark II, mais comme ces méthodes ne sont utilisées que dans des communautés locales spécifiques, ils ne sont pas abordés dans cet article.

Toutes les méthodes de mesure de la taille fonctionnelle sont très bien adaptées à l'estimation de projets logiciels. La taille du logiciel n'est cependant qu'une partie de l'estimation. La taille doit être convertie en une estimation en utilisant des données de productivité historiques pertinentes. Lorsque la taille fonctionnelle en points de fonction est connue, il doit être multiplié par le nombre d'heures le plus probable par point de fonction susceptible d'être nécessaire dans le projet. Bien qu'il existe plusieurs outils paramétriques professionnels disponibles, et aussi des bases de données avec des données historiques peuvent être obtenues facilement, de nombreuses organisations estiment qu'il est compliqué et chronophage d'utiliser la mesure de la taille fonctionnelle et qu'elles ont du mal à déterminer un taux de productivité précis pour les projets qu'elles doivent estimer. Ils préfèrent des méthodes moins chronophages ou des méthodes plus faciles à appliquer. Malheureusement, cela signifie également que ces méthodes peuvent ne pas être aussi précises.

Blog suivant

Dans le prochain blog sur ce sujet, Je donnerai mon avis sur l'utilité des principales méthodes de mesure de taille non fonctionnelle pour l'estimation de projet logiciel.

 

A propos de l'auteur

Harold van Heeringen est consultant senior en benchmarking chez Metri. En dehors de son travail pour Metri, il est impliqué dans Nesma (membre d'équipage), le Groupe des normes Benchmarking Software International (ISBSG, président actuel) et le Consortium international Common Software Metrics (COSMIQUE, Conseil consultatif international, représentant les Pays-Bas).

Un article de blog représente l'opinion personnelle de l'auteur
et ne coïncide pas nécessairement avec les politiques officielles de Nesma.