La taille du logiciel est le principal facteur d'estimation des coûts d'un projet

De loin la plupart des modèles d'estimation des coûts pour le développement de logiciels, les projets d'amélioration ou de maintenance utilisent la taille du logiciel comme principal paramètre d'entrée. La taille du logiciel est largement reconnue comme un facteur de coût important pour l'effort et le coût nécessaires aux projets logiciels. Contrairement à de nombreux objets physiques cependant, il n'y a pas de normes de mesure universelles pour mesurer la taille du logiciel. Alors qu'un peintre qui a besoin d'estimer le coût de la peinture d'un mur mesurerait généralement la taille de ce mur en pieds carrés ou en mètres carrés comme entrée pour son estimation, la mesure de la taille du logiciel est difficile du fait qu'il n'a pas de forme physique réelle. pourtant, il existe un certain nombre de méthodes disponibles dans l'industrie qui peuvent être utilisées pour mesurer la taille du logiciel. Cependant, pour les estimateurs de coûts qui ne sont pas des experts en dimensionnement de logiciels, il peut être difficile de comprendre les avantages et les inconvénients des méthodes disponibles et, par conséquent, ils peuvent avoir du mal à sélectionner la meilleure méthode pour leur objectif. Dans ce blog, un aperçu est donné des méthodes les plus largement utilisées pour le dimensionnement des logiciels disponibles dans l'industrie. Les avantages et les inconvénients de ces méthodes ainsi que des recommandations sur les méthodes à utiliser pour quels types d'estimations de projets logiciels sont également donnés.. Dans le tableau suivant, les méthodes de mesure de la taille du logiciel sont affichées et couvertes dans ce blog.

Mesure de la taille du logiciel	Portée de la mesure	Taille
SLOC	Objet logiciel physique	Taille technique dans les SLOC
IFPUG	Exigences fonctionnelles de l'utilisateur	Taille fonctionnelle en FP
Nesma	Exigences fonctionnelles de l'utilisateur	Taille fonctionnelle en FP
COSMIQUE	Exigences fonctionnelles de l'utilisateur	Taille fonctionnelle dans CFP
CASSER	Une partie des besoins utilisateurs non fonctionnels	Taille non fonctionnelle en points SNAP
Utilisez des points de cas	Cas d'utilisation, caractéristiques techniques du projet, caractéristiques environnementales du projet	‘Combinaison effort/taille’ en points Usecase
Points de fonction rapide	Exigences fonctionnelles des utilisateurs et taille de la configuration	FFP de Gartner
Points Histoire	Éléments de l'arriéré, fonctionnel et non fonctionnel	« Combinaison effort/complexité » dans les points de récit

Estimation des coûts du projet logiciel

Dans l'estimation des coûts d'un projet logiciel, l'accent est généralement mis sur l'estimation des heures d'effort des membres de l'équipe. La raison en est que les heures d'effort déterminent généralement les coûts totaux du projet. Bien sûr, il y a d'autres coûts impliqués, par exemple. licences, lieux de travail, Infrastructure, etc, mais ces coûts ne dépendent pas de la taille du logiciel et peuvent également être calculés plus facilement.

UN (simplifié) modèle d'estimation est affiché dans la figure suivante.

La taille du logiciel à développer est le principal paramètre d'entrée pour le devis du projet. Il est crucial pour l'exactitude de l'estimation que la taille soit mesurée avec précision. Choisir un taux de productivité réaliste est également une étape très importante. Cela devrait être fait sur la base de données historiques ou à l'aide d'outils paramétriques professionnels basés sur des données pertinentes de l'industrie. L'utilisation des données de l'entreprise est généralement préférée, car cela montre les capacités réelles de l'organisation qui peuvent être (beaucoup) mieux ou (beaucoup) pire que la moyenne de l'industrie. Les caractéristiques spécifiques au projet peuvent également être importantes à prendre en compte, par exemple. pression du calendrier, taille de l'équipe, contraintes de qualité, etc. Par conséquent, les outils paramétriques sont généralement très utiles dans cette étape d'un devis de projet.

Multiplier la taille par la productivité, les heures d'effort brut sont calculées. Habituellement, certains ajustements sont nécessaires sur la base d'une analyse des risques. Si l'on a besoin d'être 99% sûr qu'il n'y aura pas de dépassement de coûts par exemple, les heures d'effort seront probablement ajustées pour créer une éventualité.

Classification des méthodes de mesure de la taille des logiciels

Il existe une distinction importante entre les méthodes de mesure de la taille fonctionnelle et les autres (méthodes de mesure de taille non fonctionnelles ou méthodes hybrides). Les méthodes de mesure de la taille fonctionnelle mesurent la fonctionnalité ('que fait le logiciel') que le logiciel offre à ses utilisateurs et quantifie cela d'une certaine manière. Plus l'utilisateur peut utiliser de fonctionnalités, cela augmente la taille du logiciel. L'un des principaux avantages de ce type de méthodes est que la taille est indépendante de la technologie utilisée (par exemple. Java, .Rapporter, Oracle) et méthode de mise en œuvre utilisée (CITS, développement de la cascade, développement agile, etc.).

Les méthodes de mesure de la taille non fonctionnelle mesurent les artefacts techniques du logiciel, généralement le code logiciel qui est construit. Il existe également des méthodes hybrides disponibles qui mesurent les aspects fonctionnels, les aspects techniques et parfois aussi environnementaux du projet logiciel afin d'aboutir à un dimensionnement, par exemple. Utilisez des points de cas. pourtant, la plupart des méthodes mesurent soit la taille fonctionnelle, soit la taille technique du logiciel.

Méthodes de mesure de la taille fonctionnelle - avantages et inconvénients

En général, les principaux avantages de toutes les normes ISO/CEI pour la mesure de la taille fonctionnelle sont:

• La mesure de la taille est effectuée de manière objective. Deux mesureurs certifiés doivent proposer la même taille lors de la mesure des mêmes exigences fonctionnelles de l'utilisateur;
• La mesure de la taille est reproductible et vérifiable. Si des hypothèses ont été faites par le spécialiste de la mesure, ceux-ci doivent être documentés dans le cadre de la mesure de la taille;
• La mesure de la taille est défendable. Ceci est très important car la taille fonctionnelle est souvent utilisée dans les contrats à prix unitaire entre fournisseurs et clients. Les contrats à prix par point de fonction ne sont possibles que lorsque la taille fonctionnelle peut être déterminée sans contestation;
• Certaines des méthodes offrent des méthodes dérivées qui permettent aux estimateurs de coûts de mesurer assez précisément la taille fonctionnelle assez tôt dans le cycle de vie du projet. Par exemple le Méthode indicative Nesma peut être utilisé après la phase d'analyse des besoins et offre un moyen rapide d'obtenir une indication de la taille fonctionnelle (+50% / -30% précision).
• La taille fonctionnelle peut être reconnue comme une « valeur » pour les utilisateurs et les clients du système logiciel. Plus de fonctionnalité signifie plus de valeur et donc des coûts plus élevés. Ceci par exemple par rapport à la taille technique comme les lignes de code source (slocs) où il n'est pas clair si plus de slocs signifient plus de valeur pour l'utilisateur et/ou l'entreprise.
• En raison de la standardisation, l'avantage le plus important est qu'il devient possible de stocker les données des projets achevés afin de les utiliser dans les estimations de nouveaux projets. Tout comme le peintre qui a des données sur sa productivité en heures par pied carré pour des types de murs spécifiques, les organisations peuvent avoir un aperçu de leur productivité en termes d'heures par point de fonction. Cela permet le benchmarking, par exemple par rapport à la base de données ouverte de l'industrie de l'International Software Benchmarking Standards Group (ISBSG).

Certains des inconvénients de l'utilisation de méthodes de mesure de la taille fonctionnelle pour le dimensionnement et l'estimation des logiciels sont:

• La mesure de la taille fonctionnelle nécessite des personnes ayant l'expertise pour mener à bien cette activité. Comme il s'agit d'une activité si importante, il est vraiment recommandé de n'avoir que des mesureurs certifiés pour le dimensionnement et même dans ce cas, d'avoir un processus d'examen approprié en place. Il existe quelques initiatives pour mesurer automatiquement la taille fonctionnelle des logiciels mais jusqu'à présent elles ne sont pas très précises;
• La mesure de la taille fonctionnelle prend du temps et coûte des efforts. En général, c'est moins que 1% du budget du projet et de loin la plupart des projets peuvent être mesurés dans 1 semaine de durée. Habituellement, les avantages d'effectuer une mesure de taille fonctionnelle l'emportent plusieurs fois sur le coût, car cela permet aux parties prenantes d'établir des plans plus réalistes et d'éviter les dépassements et les éventuelles humiliations;
• Les méthodes de mesure de la taille fonctionnelle mesurent les exigences fonctionnelles de l'utilisateur qui sont spécifiées dans la documentation fonctionnelle. Il y a certaines exigences à cette documentation pour que les mesureurs puissent la mesurer. pourtant, si ces conditions ne sont pas remplies, le projet est probablement voué à l'échec de toute façon, car les programmeurs ne pourront pas coder et les testeurs ne pourront pas tester en utilisant ces documents. Une mesure de taille fonctionnelle est en fait un test statique puissant sur les exigences, dans de nombreux cas, de graves défauts et omissions sont détectés, permettant un ajustement précoce des spécifications et évitant ainsi les coûts de détection et de correction ultérieures des défauts.

La taille fonctionnelle des projets logiciels peut être utilisée dans les outils et modèles d'estimation paramétrique les plus largement utilisés, par exemple. QSM SLIM, VOYANT Galorath, Systèmes de prix Trueplanning et COCOMO II.

Blog suivant

Dans le prochain blog sur ce sujet, Je donnerai mon avis sur les avantages et les inconvénients en matière d'estimation du coût d'un projet logiciel des méthodes listées dans le tableau.

 

 

A propos de l'auteur

Harold van Heeringen est consultant senior en métrique logicielle / ingénieur principal des coûts logiciels pour Sogeti Nederland B.V.. A part son travail pour le département Sizing, Estimation & Contrôle de Sogeti, 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.