etudes empiriques sur l’evolution de la qualite logicielle

Études empiriques sur l’évolution de la qualité logicielle

Tom Mens, Leandro Doctors {tom.mens | leandro.doctors}@umons.ac.be

Naji Habra, Benoît Vanderose, Flora Kamseu {naji.habra | benoit.vanderose | flora.kamseu}@fundp.ac.be

3èmes Journées du GDR Génie de la Programmation et du Logiciel (GPL) 8–10 juin, 2011, Lille, France

2 / 29 Journées du GDR GPL, 8-10 juin, 2011, Lille, France

Plan

•  Contexte • Méthodologie et framework

de qualité • Questions de recherche •  Résultats préliminaires


Contexte

•  Projet FEDER – portefeuille TIC •  CE-IQS: Centre d’Expertise en Ingénierie et Qualité des

Systèmes –  Thématique: “Méthodologies pour dévéloper et évoluer les

systèmes logiciels”

•  Workpackage QUALGEN –  Modéliser et évoluer la qualité de différents points de

vue –  Utiliser un métamodèle et framework de qualité pour

étudier et controler la qualité des projets logiciels tout au long de leur évolution


Contexte

•  L’évolution logicielle peut affecter plusieurs aspects de la qualité d’un système logiciel –  complétude, cohérence, fiabilité, maintenabilité, etc.

•  Des études empiriques permettent d’étudier cette relation

•  Le but à moyen terme étant d’améliorer les méthodes et outils de contrôle et d’amélioration de qualité


Contexte

•  Difficultés rencontrées lors des études empiriques –  Difficultés de trouver des sujets pour les expériences –  Difficulté d’accès à des données industrielles –  Divergences et incohérences dans les méthodes et les outils

de mesure –  Manque de connaissance sur la relation entre les divers

aspects de la qualité logicielle au sein d’un même projet

•  Solutions possibles –  Se focaliser sur des données « open source » –  Faire des études sur des groupes d’étudiants au sein de

différentes universités –  Utiliser la methodologie MoCQA


Contexte

•  Passer d’une perspective « code » à une perspective projet

•  Étudier, au sein d’un projet, les relations entre plusieurs aspects de qualité et plusieurs artéfacts

•  Intégrer: –  différents artéfacts –  différent points de vues –  différentes notions de qualité –  l’aspect évolutif

Plan de test (acceptation) Design

Code

Exécutable

Analyse de besoins

Plan de test (unitaires)

Projet

Documentation


Contexte

•  Passer d’une perspective projet à une perspective écosystème

•  Étudier, au sein d’un écosystème, la qualité de plusieurs projets, la relation entre eux et la communauté

Projet-1 Projet-2 Projet-n …

Ecosystème


Méthodologie

Framework MoCQA (Model-Centric Quality Assessment)

•  Framework d’assistance à l’évaluation de la qualité au niveau du projet –  Structure la définition des mesures et des artéfacts mesurés –  Intègre et structure les relations entre les artefacts/mesures/indicateurs de

qualité •  Repose sur l’utilisation de modèles MoCQA

= modèles de qualité opérationnel et taillé sur mesure   structure l’information nécessaire pour le processus d’évaluation de qualité

•  Que mesurer? Comment le mesurer? Dans quel but? Pour qui?


Méthodologie

•  Méthodologie d’évaluation de la qualité basée sur un modèle permet de d’expliciter les hypothèse pour les expérimentations

•  Plusieurs niveaux de révision du modèle du processus d’évaluation   permet de réviser les hypothèses des expérimentations


Méthodologie


Méthodologie

Quality-related

Definition or reuse of a hierarchy of quality issues


Méthodologie

Measurement-related

Definition or reuse of measurement method

Associated to the quality factors


Méthodologie

Project-related Project vs product Software ≠ black-box Scope = project


Exemple d’un modèle MoCQA Exemple d’un modèle de qualité (instantiation du métamodèle MoCQA)


Questions de recherche

•  Quelle est la relation entre l’évaluation objective et subjective d’un attribut de qualité d’un artéfact?

Artéfact A (p.e., plan de test)

Attribut X (p.e., complétude) Méthode: objective (mesure) (p.e., test coverage tool)

Attribut X (p.e., complétude) Méthode: subjective (évaluation)

Artéfact A (p.e., plan de test)

But: approximation par une méthode automatisée

•  Avantages –  Gain de temps (automatisation) –  Plus aisément répétable au cours

du cycle d’évolution –  Evite l’évaluation « à la tete du

client »

•  Risque –  Les éléments non pris en compte

par la méthode objective sont-ils pertinents?

estimation



•  Quelle est la relation entre différents attributs de qualité pour un même artefact?

Artéfact A (p.e. code source)

Attribut X (p.e., lisibilité)

Attribut Y (p.e., efficacité / optimisation)

Artéfact A (p.e. code source)

But: construction de modèles prédictifs au cours du cycle

•  Avantages –  Anticiper l’impact de la

maintenance sur un artefact (p.ex. optimisation peut rendre le code moins lisible)



•  Quelle est la relation entre différents attributs de qualité pour un même artefact?

Artéfact A (p.e. design model)

Attribut X (p.e., complétude)

Attribut Y (p.e., taille)



•  Avantages –  Anticiper l’impact de la

maintenance sur un artéfact



•  Quelle est la relation entre le même attribut de qualité pour différents artefacts?


Attribut X (p.e. complétude)

Attribut X (p.e. complétude)

Artéfact B (p.e. code source)


•  Avantages –  Détection des problèmes de

qualité tôt dans le processus –  Tracabilité des défauts au

travers d’artéfacts à différents niveaux d’abstraction

•  Risque –  Dans quelle mesure le facteur

humain influe sur la prédiction de cette relation?


Etude empirique

•  Comment mettre en place des expérimentations permettant d’étudier ces relations ?

Formaliser des hypothèses sur les relations entre attributs de qualité  Garder trace de plusieurs méthodes de mesure d’une manière structurée   Trouver du support statistique pour confirmer les hypothèses

•  Comment garantir la réplication des expérimentations?   Fournir un « replication package » permettant de repeter l’étude   Fournir une structure permettant de rapidement identifier les manques et

variations (artéfacts / méthodes de mesure) d’un contexte à l’autre


Etude empirique

•  Projet de génie logiciel à l’UMONS –  8 groupes de 2 étudiants –  Travail obligatoire pour le cours « génie logiciel » –  Plusieurs artéfacts produits: modèles UML, code Java, tests

JUnit, rapports pdf, Javadoc

•  Évaluation subjective –  Par 4 enseignants sur tous les artéfacts pour différents

attributs de qualité

•  Évaluation objective –  En utilisant des outils automatisés


Etude empirique

•  Évaluation subjective –  Basé sur des questions précises pour chaque artéfact évalué –  En utilisant une échelle Lickert

•  excellent, très bien, bien, suffisant, insuffisant, mauvais, très mauvais, inacceptable

–  Evaluation des modèles UML (cohérence, complétude), code source (style OO, complétude), tests (correctness, complexité, complétude), exécution (convivialité, complétude)

•  Évaluation objective –  En utilisant Junit (test correctness), EclEmma (code et test

coverage), PMD (code quality), …


Résultats Préliminaires Même artéfact, même attribut

Artefact = unit tests Objectives vs. subjectives

•  2 méthodes objectives % Test Coverage # Tests

•  évaluation subjectif

  Mettre en évidence une relation d’approximation

Unit Tests

Attribut: complétude Méthode: objective (mesure) (p.e., test coverage tool, test runs)

Attribut: complétude Méthode: subjective (évaluation)

Unit Tests

estimation



% classes couvertes par les tests vs. évaluation subjective

•  p-value = 0.118 •  corrélation = 0.558

  Corrélation pas statistiquement significative

  Granularité de la méthode de mesure insuffisante



% méthodes couvertes par les tests vs. évaluation subjective


  Forte corrélation, statistiquement significative

  Granularité de la méthode de mesure suffisante pour une approximation



% LoC couvertes par les tests vs. évaluation subjective



  Granularité de la méthode de mesure suffisante pour une approximation



#tests vs. évaluation subjective



  Couverture des méthodes et #tests donnent des résultats similaires


Résultats Préliminaires

Conclusions préliminaires:

Artefact = unit tests Méthode = objective vs.

subjective

•  Mise en évidence d’une relation d’approximation possible dans une majorité de cas

•  Minorité de cas où l’évaluation objective est plus sévère

Étudier les facteurs qui rendent l’évaluation subjective plus efficace dans ses cas


Résultats Préliminaires différents artéfacts, différents attributs

Peut-on aller plus loin?

Évaluation subjective globale du produit final (l’exécutable)

vs. Évaluation objective (couverture de test)


  Essai infructueux

  L’évaluation inclut-elle des éléments parasites qui empêchent la corrélation?


Résultats Préliminaires différents artéfacts, différents attributs

Deuxième version

Évaluation subjective de la stabilité de l’exécutable

vs. Évaluation objective (couverture de test)


  Essai infructueux   Corrélation encore plus

réduite


Résultats Préliminaires

Conclusions préliminaires:

Modèles prédictifs (qualité de test vs. stabilité de

l’exécutable)

•  La qualité de test n’est pas corrélée à la qualité de l’exécutable.

•  L’évaluation objective n’est pas adaptée pour prédire la stabilité de l’exécutable.

Travaux Futurs

•  Répéter l’expérience dans d’autres universités •  Raffiner les questions de recherche •  Trouver davantage de support statistiquement

significatif


etudes empiriques sur l’evolution de la qualite logicielle

Education