AUTOMATISATION DES PROCÉDURES DE MESURE POUR DES LOGICIELS EN ‘NOUVEAUX DÉVELOPPEMENTS’ 

AUTOMATISATION DES PROCÉDURES DE MESURE POUR DES LOGICIELS EN ‘NOUVEAUX DÉVELOPPEMENTS’ 

La mesure du logiciel en général

La mesure du logiciel est un sujet de recherche dont les premiers travaux datent des années 1960s. Depuis cette époque, plusieurs modèles d’estimation ont été proposés en se basant sur la mesure de différentes caractéristiques du logiciel : lignes de codes, complexité, taille fonctionnelle, etc.
La mesure du logiciel peut être faite pour divers buts comme le soulignent McGarry et al. dans : l’estimation, l’analyse de la faisabilité, l’analyse de la performance, etc.
Le processus de mesure du logiciel est décrit dans le standard international ISO 15939  en termes d’activités et de tâches : l’engagement et le support de la mesure, la planification du processus de mesure, l’exécution du processus et l’évaluation de la mesure. Le standard ISO 15939 présente aussi un modèle d’information de la mesure (‘measurement information model’), qui montre que la mesure doit répondre à des demandes d’information bien précises (buts de la mesure).
Dans le contexte du projet industriel dans lequel cette thèse s’inscrit, Renault SA cherche à utiliser les résultats des mesures principalement pour construire les modèles de simulation de productivité qui seront utilisés dans son processus d’estimation.

Modèles d’estimations

Plusieurs modèles d’estimation ont été proposés dans la littérature. Dans son livre , Marvin V. Zelkowitz classe les modèles de la façon suivante : modèles empiriques paramétriques, modèles empiriques non-paramétriques, modèles analogiques, modèles  théoriques et des modèles heuristiques. Dans la section 5 de son livre, Zelkowitz présente plusieurs modèles et montre les détails de certains modèles.
On se limitera à ce niveau de détails quant aux modèles d’estimation, et on exposera plus en détail les moyens, les méthodes ainsi que les éléments des modèles de productivité, bases des modèles d’estimation.
Pour pouvoir faire un modèle de productivité pour un type de développement donné, on doit avoir «mesuré » les produits déjà développés (on choisissant une des caractéristiques mesurables).

Mesure fonctionnelle

Une des caractéristiques mesurables/mesurées est la fonctionnalité du logiciel: cette caractéristique a été le sujet d’une étude par Allan Albrecht en 1979 . Cette étude est la racine de la mesure de la taille fonctionnelle des logiciels, le cœur de ce projet de recherche.
Il existe actuellement cinq méthodes de mesure de la taille fonctionnelle du logiciel approuvées par l’Organisation internationale de normalisation (ISO):
• COSMIC – ISO/IEC 19761: 2011 Software Engineering – COSMIC – A Functional Size Measurement Method .
• IFPUG – ISO/IEC 20926: 2009 Software Engineering – Function Point Counting Practices Manual.
• MKII – ISO/IEC 20968: 2002 Information Technology – Software Engineering – Mk Ii Function Pont Analysis – Counting Practices Manual:2002 .
• NESMA – ISO/IEC 24570: 2005 Information Technology – Definitions And Counting Guidelines For The Application Of Function Point Analysis .
• FISMA – ISO/IEC 29881:2008 Information technology – Software and systems engineering – FiSMA 1.1 functional size measurement method .

Automatisation de la mesure fonctionnelle

Coman et al. présentent dans  une étude de cas sur l’adoption et l’utilisation à long terme, plus précisément de neuf mois de planification, suivi de deux ans d’utilisation, d’un système AISEMA (Automated Inprocess Software Engineering Measurement and Analysis) dans le département logiciel d’une grande entreprise italienne (son nom n’est pas cité) : les systèmes AISEMA visent à collecter automatiquement les données et également à fournir des analyses sur mesure pour l’aide à la décision. AISEMA réduirait le coût de la collecte des données en n’ajoutant aucune charge de travail supplémentaire. Ils peuvent collecter une large variété de données.
Les résultats de Coman et al.  tiennent en compte les caractéristiques de l’entreprise dans laquelle la recherche s’est déroulée et du système étudié. En offrant un aperçu des avantages et défis de l’adoption et l’utilisation d’un système AISEMA dans l’industrie, leur article a comme but d’aider d’autres entreprises à envisager l’adoption d’un système de mesure. Les enseignements tirés peuvent aussi guider l’amélioration des systèmes AISEMA car ils identifient à l’aide d’un cas des défis actuels dans l’utilisation et de proposer des solutions.
Leur cas d’étude montre que l’entreprise qui envisage d’adopter un système AISEMA devrait être prête à accepter un long délai initial. À la fin de ce délai, le système commencera à offrir des bénéfices à l’entreprise. Les auteurs soulignent aussi que la présentation des données et des analyses est aussi importante que leur exactitude et leur intégrité.

Évaluation des outils d’automatisation de la mesure fonctionnelle

IFPUG a établi un programme de certification pour les outils de comptage de points de fonction (FP) qui reconnaît trois types d’outils:
Les outils de type 1 : c’est à l’utilisateur d’effectuer l’identification des fonctions et l’outil est utilisé seulement pour le calcul.
Dans les outils du type 2 : le comptage est déterminé d’une façon interactive : le système pose des questions à l’utilisateur et fait le calcul sur la base des réponses fournies.
Dans les outils du type 3 : le système effectue le comptage de façon autonome sur la base d’une description stockée dans l’application.
En 2006, il existait cinq outils reconnus comme type 1 et un seul outil de type 2. Aucun outil de type 3 n’avait réussi à obtenir une certification officielle.
Dans , Mendes présente un protocole d’évaluation pour les outils informatisés de comptage automatique de points de fonction. La méthode de calcul de taille fonctionnelle utilisée dans le cadre ce projet est la méthode IFPUG. L’objectif principal du projet de Mendes est de bâtir ce protocole en identifiant les enjeux de l’automatisation de calcul des PF, les moyens d’évaluation de l’exactitude des résultats du calcul par les outils, la démarche d’évaluation des outils, les composants internes aux outils responsables – s’ils ont lieu – des écarts entre résultats (manuels/automatisés). Un des buts du projet  est de déterminer les cas où les résultats de(s) l’outil(s) de mesurage peuvent être considérés comme corrects.

Outils d’automatisation de la méthode IFPUG

Quelques chercheurs ont travaillé sur le sujet de l’automatisation de la mesure de taille fonctionnelle avec la méthode IFPUG.
Dans [30], Lamma et al. présentent un outil de mesure des points de fonction (FP) du logiciel à partir de sa spécification exprimée sous la forme d’une combinaison d’un diagramme d’entité-relation (ER) et d’un diagramme de flux de données (DFD).
La première étape de [30] consiste à traduire les règles informelles de comptage et générale FP – selon les auteurs – en règles rigoureuses exprimant des propriétés de l’ER-DFD. Cette étape a un double but : le premier est de réduire la divergence des résultats de comptages d’une même application faits par des personnes différentes. Le deuxième but est de fournir un système pour l’automatisation de la mesure des points de fonction.
Ensuite, les règles sont converties en Prolog. Et finalement les auteurs déclarent qu’ils ont mesuré six applications avec leur outil. Bien que les chiffres de la comparaison ne figurent pas dans l’article, les résultats obtenus par l’outil se rapprochent, selon les auteurs, à ceux des experts humains. Toutefois, vu que les résultats des mesures manuelles effectuées par les experts humain est absente dans l’article, l’affirmation des auteurs ne peut pas être vérifiée.
Les auteurs  annoncent de futurs travaux pour tester l’outil avec plusieurs cas d’application et comparer les résultats à ceux d’un expert humain.

Estimation des points de fonction

Face aux procédures de calculs ou de comptage de PF basées sur les méthodes de PF standards, il existe des méthodes d’estimation (non pas un calcul précis et complet) de PF du logiciel.
Dans [42] Meli et al. présentent les caractéristiques de certaines méthodes proposées dans la littérature et ils présentent aussi un modèle d’analyse comparative générale utile pour l’évaluation de toute méthode supplémentaire.
Les auteurs argumentent qu’il y a au moins deux situations dans lesquelles avoir une méthode d’estimation compatible, mais alternative aux règles standard pour le comptage des PF (suivant la méthode IFPUG, dans leur étude), pourrait être décisive :
Le premier cas se produit lorsqu’un projet de nouveau développement ou d’évolution est dans une phase très précoce qu’il n’est tout simplement pas possible d’effectuer un comptage de FP selon les normes IFPUG.
Le deuxième cas se produit quand une évaluation des logiciels existants est nécessaire, mais la documentation nécessaire ou le temps et les ressources nécessaires pour effectuer un calcul détaillé FP ne sont pas disponibles.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE DE LA LITTÉRATURE 
1.1 Introduction
1.2 La mesure du logiciel en général
1.3 Modèles d’estimations
1.4 Mesure fonctionnelle
1.5 Automatisation de la mesure fonctionnelle
1.5.1 Généralités
1.5.2 Études sur les outils et/ou prototypes qui automatisent la mesure de la taille fonctionnelle
1.5.3 Évaluation des outils d’automatisation de la mesure fonctionnelle
1.5.4 Outils d’automatisation de la méthode IFPUG
1.5.5 Outils d’automatisation basés sur la méthode COSMIC
1.5.6 Études basées sur l’ingénierie inversée
1.6 Estimation des points de fonction
1.7 Méthodes de mesure avec extension
1.8 Synthèse
CHAPITRE 2 BUT, OBJECTIFS ET MÉTHODOLOGIE DE RECHERCHE
2.1 Introduction
2.2 But et objectifs de la recherche
2.3 Méthodologie de recherche
2.3.1 Méthodologie de recherche
2.3.2 Originalité des travaux proposés
CHAPITRE 3 OUTILS DE MODÉLISATION ÉTUDIÉS ET FAISABILITÉ DE L’APPLICATION DE LA MÉTHODE COSMIC AUX MODÈLES DE CES OUTILS 
3.1 Introduction
3.2 Aperçu de l’outil Simulink et faisabilité de l’application de la méthode COSMIC au modèle Simulink
3.3 Aperçu de l’outil Simulink et faisabilité de l’application de la méthode COSMIC au modèle Statemate
CHAPITRE 4 PROCÉDURE DE MESURAGE DE LA TAILLE FONCTIONNELLE POUR LES LOGICIELS CONÇUS AVEC L’OUTIL DE MODÉLISATION SIMULINK 
4.1 Introduction
4.2 Une procédure de mesurage pour les systèmes temps-réels conçus avec Simulink
4.2.1 La phase de stratégie de mesure
4.2.2 La phase de mapping
4.2.3 La phase de mesurage : Mesurage de la taille fonctionnelle d’un « nouveau » logiciel
4.3 Application de la procédure à l’exemple du système d’Équations
CHAPITRE 5 PROCÉDURE DE MESURAGE DE LA TAILLE FONCTIONNELLE POUR LES LOGICIELS CONÇUS AVEC L’OUTIL DE MODÉLISATION STATEMATE 
5.1 Introduction
5.2 Une procédure de mesurage pour les systèmes temps-réels conçus avec Statemate
5.2.1 La phase de stratégie de mesure
5.2.2 La phase de mapping .
5.2.3 La phase de mesurage : Mesurage de la taille fonctionnelle d’un « nouveau » logiciel
5.3 Application de la procédure à l’exemple de l’horloge
CHAPITRE 6 AUTOMATISATION DES PROCÉDURES DE MESURE POUR DES LOGICIELS EN ‘NOUVEAUX DÉVELOPPEMENTS’ 
6.1 Introduction
6.2 La représentation semi-formelle
6.2.1 Éléments nécessaires pour le mesurage
6.2.2 Éléments correspondants dans la représentation
6.3 Le prototype d’automatisation de la mesure de la taille fonctionnelle des logiciels conçus avec Simulink
6.3.1 Module 1 du prototype 1 : le filtre de données
6.3.2 Le sous-module ‘parseur’
6.3.3 Le sous-module ‘Générateur d’entrées’
6.3.4 Les objets du module 1 du prototype 1
6.3.5 Module 2 du prototype 1 : Unité de mesurage
6.3.6 Module 3 du prototype 1 : Interface Graphique – GUI
6.3.7 Les éléments COSMIC identifiés et couverts par le prototype
6.3.8 Algorithme du prototype 1
6.3.9 Représentation semi-formelle et taille fonctionnelle du prototype 1
CHAPITRE 7 UN PROTOCOLE D’ÉVALUATION DES OUTILS DE MESURAGE AUTOMATIQUE DE LA TAILLE FONCTIONNELLE SUIVANT LA MÉTHODE DE MESURE COSMIC 
7.1 Introduction
7.2 Utilisation de la représentation semi-formelle pour les combinaisons de test
7.2.1 Cas d’un processus isolé
7.2.2 Cas de plusieurs processus : extension de la représentation
7.3 Test théorique de couverture
7.4 Technique de tests pratiques par « Analyseur de spectre »
7.4.1 1ère phase : comparaison des résultats numériques finaux
7.4.2 2ème phase : Comparaison détaillée
7.4.3 3ème phase : l’inspection du prototype et de la spécification
7.5 Application du protocole d’évaluation sur la spécification fonctionnelle du prototype 1
CHAPITRE 8 APPLICATION DU PROTOCOLE SUR LA BATTERIE DE SPÉCIFICATIONS RENAULT
8.1 Introduction
8.2 Résultats et analyse
8.2.1 1ère phase de tests
8.2.2 2ème phase de tests
8.2.3 3ème phase de tests
8.2.4 4ème phase de tests
8.3 Vérification des spécifications qui ne présentaient pas d’écart dans le résultat final
8.4 Conclusion générale sur les tests
CONCLUSION

Télécharger le rapport complet