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

Plan

•  Contexte
•  Méthodologie et framework
de qualité
•  Questions de recherche
•  Résultats préliminaires

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

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
Projet •  Passer d’une perspective
Analyse
« code » à une perspective
de besoins projet

Plan de test
•  Étudier, au sein d’un projet,
Design (acceptation) les relations entre plusieurs
aspects de qualité et
plusieurs artéfacts
Plan de test
Code (unitaires)
•  Intégrer:
–  différents artéfacts
–  différent points de vues
Exécutable Documentation
–  différentes notions de qualité
–  l’aspect évolutif


Contexte
•  Passer d’une perspective
Ecosystème projet à une perspective
écosystème
Projet-1 Projet-2 … Projet-n

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


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?
But: approximation par une méthode
Artéfact A
(p.e., plan de test) automatisée
Attribut X (p.e., complétude) •  Avantages
Méthode: objective (mesure) –  Gain de temps (automatisation)
(p.e., test coverage tool)
–  Plus aisément répétable au cours
du cycle d’évolution
–  Evite l’évaluation « à la tete du
estimation
client »
Artéfact A
(p.e., plan de test) •  Risque
Attribut X (p.e., complétude) –  Les éléments non pris en compte
Méthode: subjective (évaluation) par la méthode objective sont-ils
pertinents?


•  Quelle est la relation entre différents attributs de
qualité pour un même artefact?
But: construction de modèles
Artéfact A
(p.e. code source) prédictifs au cours du cycle
Attribut X (p.e., lisibilité)
•  Avantages
–  Anticiper l’impact de la
maintenance sur un artefact
(p.ex. optimisation peut rendre
le code moins lisible)
Artéfact A
(p.e. code source)

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


•  Quelle est la relation entre différents attributs de
qualité pour un même artefact?
Artéfact A
(p.e. design model) prédictifs au cours du cycle
Attribut X (p.e., complétude)
•  Avantages
–  Anticiper l’impact de la
maintenance sur un artéfact

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

Attribut Y (p.e., taille)


•  Quelle est la relation entre le même attribut de
qualité pour différents artefacts?
Artéfact A
(p.e. design model) prédictifs au cours du cycle
Attribut X (p.e. complétude)
•  Avantages
–  Détection des problèmes de
qualité tôt dans le processus
–  Tracabilité des défauts au
Artéfact B travers d’artéfacts à différents
(p.e. code source) niveaux d’abstraction
Attribut X (p.e. complétude) •  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
Unit Tests
Objectives vs. subjectives
Attribut: complétude
Méthode: objective (mesure)
•  2 méthodes objectives
(p.e., test coverage tool, test runs)
% Test Coverage
# Tests

estimation
Unit Tests
•  évaluation subjectif

  Mettre en évidence une
Attribut: complétude relation d’approximation
Méthode: subjective (évaluation)



% 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

•  p-value = 0.024

  Forte corrélation,
  Granularité de la méthode de
mesure suffisante pour une
approximation



% LoC couvertes par les tests

•  p-value = 0.014

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



#tests

•  p-value = 0.0177

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


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


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)

•  p-value = 0.585

  Essai infructueux

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


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)

•  p-value = 0.647

  Essai infructueux
  Corrélation encore plus
réduite


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Etudes empiriques sur l’evolution de la qualite logicielle

Ähnlich wie Etudes empiriques sur l’evolution de la qualite logicielle (20)

Mehr von Tom Mens

Mehr von Tom Mens (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (18)

Etudes empiriques sur l’evolution de la qualite logicielle