Historique des mesures en Génie Logiciel

Historique des mesures en Génie Logiciel

La méthode des points de fonction IFPUG 1.4.2.1 Principes

Dans les années 70, Allan Albrecht a introduit une méthode de mesure de la taille fonctionnelle des logiciels appelée Analyse des Points de Fonction. Au fil du temps, l’utilisation de cette méthode a augmenté et a été le sujet de plusieurs recherches. En 1986, l’International Function Point Users Group (IFPUG, 2012) a été créé et a normalisé la méthode originale d’Albrecht pour la mesure fonctionnelle des logiciels. Par la suite, la méthode FPA a franchi la normalisation ISO (International Organization for Standardization) en 2003, c’est la norme ISO 20926. Qu’est-ce qu’un point de fonction ? C’est la première interrogation qu’un non connaisseur du domaine de mesure peut se poser.

Souvent, on définit les points de fonction comme étant une unité de mesure standard qui représente la taille fonctionnelle d’une application logicielle. “A way of measuring the function value derived to our customer”. C’est de cette manière qu’a défini Albercht au années 70 la méthode FPA (Lavazza et al., 2010). Evidemment, c’est à ce point-là que réside la nouveauté de la méthode FPA car en effet, on ne mesure plus le programme par son aspect technique (par exemple en calculant le nombre de lignes de code) mais plutôt par son aspect fonctionnel, plus précisément en calculant la taille fonctionnelle, exprimée en points de fonction, et indépendamment du langage utilisé ou du degré d’expérimentation du programmeur. En effet, la méthode FPA permet de mesurer la taille du logiciel en quantifiant les fonctionnalités fournies à l’utilisateur à partir des spécifications fonctionnelles. Notons bien que sur la base des points de fonction nous pouvons déterminer entre autres les points suivants:

Productivité-performances du projet : nombre de jours/ hommes dépensés.

Coût : nombre de jours/ hommes en termes de coût.

Réactivité : durée du projet.

Qualité : nombre d’anomalies en production

Avantages et inconvénients

La méthode des points de fonction présente plusieurs avantages. En effet, elle a franchi la normalisation internationale, pas comme d’autres méthodes de mesure (LOC par exemple). Elle permet également d’effectuer les mesures indépendamment des technologies et des méthodologies employées lors du processus de développement, ce qui n’est pas le cas de la méthode du nombre de lignes de codes par exemple. FPA peut être employée pour déterminer le degré de productivité d’un outil, un environnement ou un langage de programmation par rapport à d’autres dans une même organisation ou d’autres organisations (Khelifi, 2005). D’un autre côté, la méthode des points de fonction peut être vue insatisfaisante par rapport à d’autres points. Effectivement, la méthode présente une faiblesse en ce qui concerne la procédure de comptage, car elle nécessite un comptage manuel ce qui rend son automatisation chose difficile. De plus, elle exige de l’expérience pour avoir des mesures précises (Khelifi, 2005). Enfin, la méthode d’analyse des points de fonction n’est pas applicable à tous les domaines tels que le domaine des logiciels en temps réel, le domaine des applications web, le domaine des systèmes embarqué, etc. Elle n’est disponible que dans le domaine d’informatique de gestion et elle permet de calculer les fonctionnalités des systèmes d’information.

Plusieurs tentatives d’utilisation de la méthode FPA ont été effectuées sur les logiciels à temps réel mais elles ont donné des résultats insatisfaisants. Assurément, pour ce type de logiciels, FPA n’est pas capable d’effectuer un nombre très élevé de calculs internes et/ou des fonctions de contrôle (Maya et al., 1998), ce qui génère des mesures non convenables. Selon les auteurs (Maya et al., 1998), la méthode FPA ne prend pas en compte les caractéristiques spécifiques aux applications de types temps réel. En effet, les applications de type temps réel produisent un grand nombre de sous-processus alors que la méthode ne prend pas en compte ces sous-processus ce qui cause la génération des petites tailles de points de fonction dans ces types d’environnements. Donc, il a été indispensable de proposer une extension pour la méthode afin de remédier ce problème.

La méthode COSMIC

Principes Plusieurs chercheurs dans le domaine de logiciels ainsi que différentes organisations en industrie ont constaté que les premières générations des méthodes de mesure de la taille fonctionnelle, basées sur les points de fonction, n’offrent pas une mesure conforme aux fonctionnalités des systèmes embarqués et à temps réel. De plus, plusieurs auteurs ont convenu que la structure de la méthode des points de fonction n’été pas adéquate pour mesurer des logiciels de traitement intensif avec un grand nombre de fonctions de contrôle et des calculs internes (Desharnais et al., 1998) et c’est à partir de ces raisons qu’est survenue l’idée de COSMIC. En effet, le prototype conçu pour la nouvelle génération de mesure de la taille fonctionnelle COSMIC a gardé les critères de qualité de la méthode IFPUG tels que la pertinence. La méthode COSMIC prend en compte les sous-processus intégrés au sein d’un processus de contrôle unique, elle permet évidemment d’identifier les différents groupes de données reçus, envoyés, lus et écrits et donc de générer plus de points de fonction.

De plus, partant du fait que le degré de granularité est important pour les logiciels à temps réel, la méthode COSMIC considère un degré de granularité très fin, celui des sous processus. COSMIC est une méthode de mesure de la taille fonctionnelle des logiciels maintenue par le groupe COSMIC regroupant un ensemble d’experts du domaine des métriques à travers le monde et dirigé par le Professeur Alain Abran (École de Technologie Supérieure,) et Charles Symons (Software Measurement Services Ltd, UK). Elle est devenue depuis mars 2003, un standard ISO pour la mesure de la taille fonctionnelle des logiciels: c’est la norme ISO 19761. La méthode de mesure COSMIC applique un ensemble de procédures, modèles et règles pour un logiciel donné à travers ses fonctionnalités utilisateurs requises. Selon la perspective proposée par COSMIC, le logiciel est une partie d’un produit ou service dédiée pour satisfaire les exigences fonctionnelles des utilisateurs (Abran, 2010). Les FUR peuvent être allouées pour la partie matérielle ou logicielle ou les deux en même temps comme le montre la figure ci-dessous.

Aperçu de l’approche MDA

L’architecture dirigée par les modèles est une approche proposée par l’OMG (OMG, 2012) pour la conception et la modélisation des systèmes logiciels. L’objectif de MDA est l’élaboration des modèles indépendants des plates-formes d’exécution. L’idée est donc de séparer l’aspect logique (business) de l’aspect technique (code) en utilisant les modèles. On expose un peu plus bas la figure qui décrit le principe de MDA. Cette architecture est composée de 4 couches. Nous remarquons que les standards de l’OMG à savoir UML, MOF (Meta Object Facility) et CWM (Common Warehouse Metamodel) sont au coeur de MDA. Dans la couche qui suit, se trouve le standard XMI (XML Metadata Interchange) qui permet la communication entre les plates-formes supportées par MDA (JAVA, .Net, CORBA et web Services). Dans la couche suivante, on trouve les différents services couverts (événements, sécurité, transactions, répertoires). Enfin, dans la dernière couche, résident les différents domaines métiers (finance, transport, santé, ets.).

Cette architecture est structurée en quatre couches. Nous remarquons que les standards de l’OMG à savoir UML, MOF et CWM sont au coeur de MDA. Dans la couche qui suit, se trouve le standard XMI qui permet la communication entre les plates-formes supportées par MDA (JAVA, .Net, CORBA et web Services). Dans la couche suivante, on trouve les différents services couverts (événements, sécurité, transactions, répertoires). Enfin, dans la dernière couche, résident les différents domaines métiers (finance, transport, santé, etc.). Le principe général de MDA est la transformation de modèles, à savoir les transformations CIM vers PIM et PIM vers PSM. Dans un premier niveau, l’approche MDA définit les modèles d’exigences ou CIM (Computation Independent Model) qui sont des modèles construits indépendamment de la programmation. Dans un deuxième plan, MDA définit les modèles d’analyse et de conception PIM (Platform Independent Model) qui sont indépendants de la plate-forme utilisée. Enfin, les modèles définis dans le troisième niveau sont les modèles de code liés à une plate-forme d’exécution et appelés PSM (Platform Specific Model). La transformation entre les différents modèles est décrite dans la figure 2.2.

Table des matières

INTRODUCTION
CHAPITRE 1 LA MESURE DE LA TAILLE FONCTIONNELLE
1.1 Introduction
1.2 La mesure en génie logiciel
1.3 Historique des mesures en Génie Logiciel
1.4 Les mesures de la taille fonctionnelle
1.4.1 Évolution des méthodes de mesure de la taille fonctionnelle
1.4.2 La méthode des points de fonction IFPUG
1.4.3 La méthode COSMIC
1.4.4 Comparaison entre les méthodes COSMIC et IFPUG
1.5 Processus de mesure COSMIC
1.5.1 Définir la stratégie de mesure
1.5.2 La phase d’arrimage (Mapping en anglais)
1.5.3 La phase de mesure
1.5.4 Application de la fonction de mesure
1.6 Conclusion
CHAPITRE 2 L’APPROCHE DIRIGÉE PAR LES MODÈLES ET LES PROFILS UML
2.1 Introduction
2.2 Aperçu de l’approche MDA
2.3 Unified Modeling Language (UML)
2.4 La méta-modélisation en UML
2.5 Les profils UML
2.5.1 Stéréotypes
2.5.2 Valeur marquée (Tagged Value)
2.5.3 Contraintes
2.6 Exemples de profils UML
CHAPITRE 3 REVUE DE LITTÉRATURE
3.1 Introduction
3.2 Les approches proposées pour mesurer les FUR documentés avec les diagrammes UML
3.2.1 Mapping entre les concepts UML et COSMIC (Bévo et al.)
3.2.2 Usage du diagramme de séquence pour adresser le problème de granularité des cas d’utilisation (Jenner)
3.2.3 RUP pour l’automatisation de la mesure de la taille fonctionnelle avec COSMIC (Azzouz et al.)
3.2.4 Extraction des concepts UML pour des fins d’automatisation de la taille fonctionnelle (Pourquoi mesurer en génie logiciel (Vilus et al.)
3.2.5 Mesure basée sur le modèle des cas d’utilisation (Habela et al.)
3.2.6 Utiliser les modèles UML pour la mesure en prenant en considération les manipulations de données (Levesque et al.)
3.2.7 Mesure de la taille fonctionnelle des diagrammes de cas d’utilisation (Sellami et al.)
3.2.8 Un espace d’exigences pour montrer comment UML peut supporter la mesure de la taille fonctionnelle (Van den Berg et al.)
3.2.9 Utilisation d’UML pour supporter la mesure de la taille fonctionnelle avec COSMIC (Lavazza et al.)
3.3 Comparaison des travaux de recherche
3.4 Autres travaux reliés
3.4.1 Un méta-modèle pour la méthode COSMIC proposé par Condori- Fernandèz et al. (2007)
3.4.2 Estimation automatisée de la taille des composants logiciels embarqués proposée par Lind.K et al (Lind.K et Rogardt.H, 2011)
3.5 Conclusion
CHAPITRE 4 PROFIL UML POUR LA METHODE COSMIC
4.1 Introduction
4.2 Modèle du domaine : Métamodèle COSMIC
4.3 Règles liées au domaine
4.4 Architecture du profil P-COSMIC
4.5 Description du profil P-COSMIC
4.5.1 Mapping du méta-modèle vers UML : Liste des stéréotypes
4.6 Implémentation du profil P-COSMIC
4.6.1 Choix technologique
4.6.2 Résultats de l’implémentation
4.7 Conclusion
CHAPITRE 5 EXPÉRIMENTATION ET RÉSULTATS
5.1 Introduction
5.2 Application de P-COSMIC
5.3 Discussion des résultats et travaux futurs
5.4 Conclusion
CONCLUSION GÉNÉRALE
RÉFÉRENCES BIBLIOGRAPHIQUES

Télécharger le rapport complet