Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
Cette étude propose un modèle d'estimation de la taille des logiciels qui intègre des mesures de taille fonctionnelle (UFP et CFP) avec des mesures de complexité fonctionnelle (CC et YC) en utilisant l'analyse de régression, démontrant que la combinaison de ces métriques — particulièrement l'UFP avec les mesures de complexité — réduit significativement l'erreur d'estimation et améliore la précision de la prédiction pour des applications telles que COCOMO II.
Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Construire un logiciel est une entreprise complexe, semblable à la construction d'un bâtiment, mais au lieu de briques et de mortier, les matériaux sont des lignes de code et des exigences fonctionnelles. Pendant des décennies, les chefs de projet se sont appuyés sur le comptage de ces lignes de code pour estimer le temps et l'argent qu'un projet prendra. Cependant, cette méthode est imparfaite car deux programmes peuvent faire exactement la même chose tout en nécessitant des quantités de code très différentes selon la façon dont le programmeur les écrit. Pour résoudre ce problème, l'industrie a développé un moyen de mesurer le logiciel par ce qu'il fait réellement pour l'utilisateur — en comptant les entrées, les sorties et les fichiers de données — plutôt que par la façon dont il est écrit. C'est ce qu'on appelle la taille fonctionnelle. Pourtant, même ce décompte fonctionnel possède un angle mort : il mesure la quantité de fonctionnalités, mais omet souvent la difficulté de les construire. Une fonctionnalité simple peut être facile à construire, tandis qu'une autre, complexe, avec de nombreux embranchements et conditions, pourrait être un cauchemar à coder, même si les deux comptent comme une seule « fonctionnalité » dans le sens traditionnel.
Ce fossé entre la taille d'une fonctionnalité et la complexité de sa construction est l'énigme centrale abordée par une équipe de chercheurs d'Indonésie. Ils ont cherché à voir si la combinaison d'une mesure de la taille fonctionnelle avec une mesure de la complexité structurelle pouvait conduire à des prédictions plus précises de la véritable ampleur d'un projet logiciel. Leurs travaux se concentrent sur l'affinement de la manière dont nous estimons l'effort requis pour construire un logiciel, une tâche critique qui détermine si un projet respecte son budget ou s'il échappe à tout contrôle. En examinant à la fois le « quoi » et le « combien de difficulté », ils ont visé à créer une image plus claire pour les personnes qui planifient et gèrent ces systèmes numériques.
Les chercheurs ont commencé par rassembler des données provenant de deux projets logiciels réels : l'un conçu pour une coopérative d'employés et un autre pour un magasin de détail. Ils n'ont pas utilisé de jeux de données publics car ceux-ci manquent souvent des détails spécifiques nécessaires à leur analyse. Au lieu de cela, ils ont pris les exigences textuelles de ces applications et les ont traduites en diagrammes de flux visuels, connus sous le nom de diagrammes BPMN. Ces diagrammes ont servi de pont, permettant à l'équipe d'extraire deux types de mesures différents pour chaque partie du système. D'abord, ils ont calculé la taille fonctionnelle, qui compte les interactions de l'utilisateur et les fichiers de données. Ils ont utilisé deux méthodes établies pour cela : une qui compte les points de fonction non ajustés basés sur des catégories standards comme les entrées et les sorties, et une autre qui compte les points de fonction cosmiques en suivant comment les données entrent et sortent du système.
Ensuite, ils ont mesuré la complexité structurelle de ces mêmes parties. Cela impliquait d'analyser la logique au sein des diagrammes de flux pour voir combien de points de décision, de boucles et de chemins d'embranchement existaient. Ils ont utilisé deux mesures de complexité différentes pour cela : l'une qui compte le nombre de chemins indépendants à travers le code, et une autre qui pondère la difficulté cognitive des différents types d'embranchements et de boucles. Enfin, ils ont comparé ces mesures combinées au nombre réel de lignes de code écrites pour les projets. Ce décompte final a servi de vérité terrain, la taille réelle du logiciel terminé que les chercheurs essayaient de prédire.
Les résultats ont révélé un modèle distinct selon la méthode de taille fonctionnelle utilisée. Lorsque les chercheurs ont utilisé la première méthode de taille fonctionnelle, l'ajout des mesures de complexité a considérablement amélioré la précision de leurs prédictions. Spécifiquement, le taux d'erreur de leurs estimations est passé de vingt-quatre pour cent à vingt-deux pour cent. Cela suggère que pour ce type de comptage fonctionnel, connaître la complexité de la logique aide à corriger l'estimation, la rapprochant de la réalité. Cependant, l'histoire était différente pour la seconde méthode de taille fonctionnelle. Lorsqu'ils ont utilisé les points de fonction cosmiques, l'ajout des mesures de complexité n'a pas abaissé le taux d'erreur, qui est resté stable à quinze pour cent. Dans ce cas, la mesure de la taille fonctionnelle était déjà si précise que les données de complexité supplémentaires n'ont pas rendu le chiffre final plus précis.
Malgré l'absence d'amélioration des taux d'erreur pour la seconde méthode, les données de complexité se sont avérées utiles. Lorsque les chercheurs ont ajouté les mesures de complexité aux points de fonction cosmiques, la qualité de leurs prédictions s'est améliorée d'une autre manière. Le pourcentage d'estimations tombant dans une marge d'erreur très étroite est passé de soixante-seize pour cent à quatre-vingts pour cent. Cela signifie que, bien que l'erreur moyenne n'ait pas changé, l'équipe est devenue plus fiable pour obtenir une réponse très proche de la vérité. L'étude conclut que l'intégration des mesures de complexité n'est pas une solution universelle ; sa valeur dépend de la méthode de taille fonctionnelle utilisée. Pour une méthode, elle affine la précision, tandis que pour l'autre, elle affine la cohérence. Ces conclusions offrent une façon plus nuancée d'injecter des données dans les modèles d'estimation d'effort établis, aidant potentiellement les équipes de développement logiciel à prendre des décisions plus éclairées concernant le temps et les ressources que leurs projets requerront réellement.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.