IFT3913 – Qualité du logiciel et métriques

IFT3913 – Qualité du logiciel et métriques

Cours 1, mercredi 10 janvier 2007 Chapîtres du cours:

I- Introduction

II- Modèles de processus de développement de logiciel III- Théorie de la mesure

IV- Mesure de la qualité du logiciel (du produit) V- Qualité du logiciel

VI- Études empiriques

VII- Mesure du produit logiciel (exemples de métriques) VIII- Collecte et analyse des métriques

Évaluation:

Intra: 30%

Final: 40%

TPs(3): 30%

Page web: www.iro.umontreal.ca/~sahraouh/cours/ift3913/ (hiv2007 / iftgenlog)

Chapître 1: Introduction

La perception de la qualité est subjective. Comment évaluer «numériquement» ou par un algorithme afin de déterminer «le meilleur» est très complexe. (Politique? Sports?)

La qualité (définitions diverses):

- La qualité, c'est la conformité avec les besoins.

- La qualité, c'est l'adéquation avec l'usage attendu. (La distance entre l'usage permi par le produit et ce qui est nécessaire)

- La qualité, c'est ce qui fait de quelque chose ce qu'elle est.

- La qualité, c'est le degré d'excellence.

- La qualité, c'est la valeur de quelque chose pour quelqu'un.

ISO: la qualité, c'est un ensemble de traits et de caractéristiques d'un produit logiciel portant sur son aptitude à satisfaire des besoins exprimés ou implicites.

IEEE: la qualité correspond au degré selon lequel un logiciel possède une combinaison d'attributs désirés.

Crosby: la qualité du logiciel correspond au degré selon lequel un client perçoit qu'un logiciel répond aux multiples attentes.

Pressman: la qualité c'est la conformité aux exigences explicites à la fois fonctionnelles et de performance aux standards de développement explicitement documentés et aux caractéristiques implicites qui sont attendues de tout logiciel professionnellement développés.

Ceci dit, on n'a pas de théorie forte qui permettent de l'évaluer. C'est pas facile de mesurer ou de mesurer à priori:

ex.: Maintenabilité (combien d'argent ça nous coûte pour faire l'entretient?) bug: l'argent est déjà dépensé!

Toutefois on peut faire des mesures sur les attrbuts internes... (Couplage, grandeur, etc.)

Mais on doit cependant essayer de voir comment prédire... alors on se sert des attrbuts internes pour essayer d'évaluer la qualité future du logiciel... on essaie de créer des liens.

La mesure:

À la limite, une distance peut s'estimer. Mais l'intelligence, par exemple, n'a pas de système de mesure fiable. Un autre exemple classique est la combinaison pondérée (...) des 10 épreuves d'un décathlon.

La signification du «zéro» peut représenter une valeur comme une autre ou l'absence de ce que l'on mesure.

Cours 2, jeudi 11 janvier 2006

Chapître 2: Modèles de processus de développement du logiciel

Les notions de mesure et de qualité du logiciel sont reliées au processus de développement.

Prévention:

- Détection et correction de faute/d'erreur (le plus tôt possible) o Erreurs fonctionnelles (écarts par rapport à la spécification)

ou erreurs [écarts] de style (règles de l'art)

-

Élimination des causes (sources) d'erreurs. (ex.: superclasse dépandante d'une sous-classe [Anti-patron])

-

Assurance qualité dans les activités. (au fur et à mesure)

- Évaluation quantitative. (ex.: règles de compagnie, conventions de codage) Durée de vie:

La plupart des logiciels sont en réalité «immortels». (ils dureront beaucoup plus longtemps que prévu) Modèle de développement en cascade: (le plus connu parce que le premier)

Étude de faisabilité

Analyse des besoins (et planification) Conception générale

Conception détaillée

Implantation et tests (unitaires) Intégration et tests

Installation et tests

Exploitation et maintenance

Chaque étape doit se terminer à une date donnée par la production de «livrable» (documents, code, etc.) Les résultats sont soumis à une étude approfondie.

Matrice des importances

Utilisateur Vendeur Gestionnaire de projet

Programmeur Professeur d'université Facilité

d'utilisation X

Compatibilité /

Portabilité X

Multiples

fonctions X X X

Haute

Performance X X

0 défaut X X

Rapidité de

développement X X X

Faible coût de

développement X

Code élégant X X

On ne passe à l'étape suivante que si les résultats sont satisfaisants.



Faisabilité: (pourquoi?)

- y a-t-il de meilleures alternatives?

- Satisfaction des utilisateurs?

- Y a-t-il un marché?

- Budget, personnel, matériel?



Analyse des besoins: (quoi?)

- définition précise des fonctions

 Conception: (comment?)

- Définir la structure du logiciel

- Résultats (architecture / interfaces entre les modules) - Définition des algorithmes de chaque module

- Effectuer les tests unitaires

Note: Avant, ces étapes était très délimitées. Depuis l'avèment des nouveaux modèles (objet), la distance entre la programmation et les étapes est réduite et conséquemment, lorsqu'on fait par exemple l'analyse, on est

déjà rendu très loin.

Note [types de logiciels]:

o Logiciels tablette (en magasin, généraux, pour tous)

o Sur mesure (pour une compagnie qui a un besoin spécifique)

o Familles de produits (développé pour une occasion, mais qu'on va tenter de faire de façon générique pour le revendre ensuite à différents clients.)

Cours 3, mercredi 17 janvier 2007

 Conception: (comment?) -- suite -- - Implémentation et test

> Implémenter les algos pour chaque module

> Effectuer les tests unitaires (tests par programmeur) - Intégration et tests (tests par testeurs)

> Intégrer les différents modules

> Valider/vérifier l'adéquation de l'implantationm de la conception et de l'architecture avec le cachier de charge. (acceptation) [validertests  vérifierconformité aux propriétés]

- Installation et test

> Déploiement chez le client (ou version beta pour logiciels tablette)

> Test fait par un sous-ensemble d'utilisateurs - Exploitation et maintenance

> Corrective, Perfective, Adaptative  50% à 80% des sommes dépensées en moyenne !!!

Modèle de développement en V:

Similaire à en cascade, mais avec tests à chaque étape...

(des tas de variantes)

Modèle par prototypage:

 Besoins pas clairement définis

 Besoins changeants Deux types:

- Prototypes jetables (versions baties sur un autre outil, afin de déterminer clairement la spécification, puis on on bati un produit complètement à part).

(développement «laid»)

- Prototypes évolutif (version qu'on améliore... la dernière version sera le produit final) (développement dans les règles de l'art)

Collecte et analyse des besoins

Conception prototype

Rafinement du prototype Implantation d'un prototype

(des besoins)

Évaluation du client

Production

Note: "extrem programming" vient du smalltalk (interprété, non-type, réflexif, etc.) est un genre de légalisation de la programmation par prototypage du genre smalltalk...

Modèle de développement en spirale:

1- Détermination des objectifs du cycle, 2- Analyse des risques, évaluation des alternatives des alternatives pour les atteindre et et éventuellement prototypage

des contraintes à partir des résultats des cycles précédents (ou de l'analyse des besoins pour le premier cycle).

4- Revue des résultats et planification 3- Développement et vérification de

du cycle suivant. la solution retenue.

(peut être vu comme étape par étape du développement ou alors comme avancement une fonction à la fois, un module à la fois, etc.)

Risques majeurs du développement logiciel:

 Défaillance du personnel (gestion de personnel)

 Calendrier et/ou budget irréaliste

- Pression de la compétition  resserement exagéré - On n'a pas de modèle de prédiction fiable

 Développement de fonctions inappropriées - Pas le même langage? (Communication)

 Développement d'interfaces inappropriées

 Produits "plaqués or"

- Joli en apparence, mais mauvaise logique

 Validité des besoins - Problèmes contractuels

 Composants externes manquants - Logiciel délégués inexistant

- Composants matériels inexistents ou bloqués par des contrats, etc.

 Tâches externes défaillantes - Sous-contractuel?...

 Problèmes de performance

- Trop lent ou trop forte consommation

 Exigences démesurées par rapport à la technologie

Mises en œuvre des processus:

Le degré de mise en œuvre va varier d'une organisation à une autre (ou d'un projet à un autre) Il y a une relation entre les chances de succès d'un projet et ce degré de mise en œuvre.

Il existe des modèles et des standards pour évaluer le degré de mise en œuvre:

Modèles et standards: (... d'évaluation de la qualité de la mise en œuvre) CMM (Capapibility maturity model):

Jusqu'à quel point le processus de développement est-il mature?

Développé en '89 par le SEI.

o Ce modèle est évolutionniste... il permet d'améliorer le processus de développement d'une fois à l'autre vers des processus disciplinés à partir de processus indéfinis ou ad hoc.

o Échelle de niveaux

 Niveau 1 (initial): Caractérisation:

 processus cahotique et changeant

 calendrier, budget, fonctionnalité et qualité imprévus et imprévisibles

 performance dépend avant tout des individus Atteinte:

 On y est déjà!

 Niveau 2 (répétable):Caractérisation:

 processus intuitif et ad hoc (ad hoc, mais le même)

 coût et qualité très variables

 calendriers raisonnablement maîtrisés Points clés pour atteindre le niveau:

 Gestion des besoins (trace des changements, etc.)

 Planification des projets

 Suivi des projets (responsable, réunions, livrables, etc.)

 Gestion des sous-contractants

 Assurance qualité (procédures pour vérifier la qualité)

 Gestion des configurations (pouvoir tourner sur différentes plateformes, etc.)

Cours 4, jeudi 18 janvier 2007

 Niveau 3 (défini): Caractérisation:

 processus documenté, normalisé et intégré.

 tous les projets suivent une version approuvée du processus de développement.

Points clés pour atteindre le niveau:

 Définition du processus

 Amélioration du processus (mécanisme pour)

 Programme de formation (sur le processus et les outils)

 Gestion de projets intégrée

 Ingénérie des logiciels

 Coordination inter-groupes et évaluation par les pairs (par gens hors du projet par exemple)

 Niveau 4 (géré): Caractérisation:

 Mesures de la qualité du processus et du produit

 Le processus est géré quantitativement Points clés pour atteindre le niveau:

 Définir mesures et analyse du processus

 Gestion de la qualité

 Niveau 5 (optimisé): Caractérisation:

 Amélioration continue du processus à partir des mesures et des données collectées précédemment.

 Intégration des idées et technologies novatrices. (R&D, ...) Points clés pour atteindre le niveau:

 La prévention des erreurs

 Intégration des innovations technologiques

 Gestion des changements - L'évaluation se fait par un questionnaire (questions binaires).

- Chaque question est associée à un niveau. Il y a des questions clés et des question ordinaires.

- Pour atteindre un niveau, il faut 90% de «oui» aux questions clés et 80% de «oui» à toutes les questions du niveau.

- Il faut le niveau i pour passer à i+1

[Le niveau 3 est tout à fait acceptable pour une PME... les niveaux supérieurs étant "réservés" aux entreprises pouvant se permettre l'investissement...]

SPR (Software Productivity Research):

o Défini par Capers Jones o Similaire à CMM

o Touche des aspets plus tactiques et stratigiques (attaque d'un nouveau marché, etc.) o Questionnaire de 400 questions (échelle de Lickert – Un peu, bcoup, neutre, etc.) o Plusieurs niveaux (de mise en œuvre): Excellent, Bon, Moyen, Marginal, Faible

ISO9000:

Note: n'est pas directement conçu pour les logiciels...

o Ensemble de standards et de lignes directrices pour gérer la qualité (des processus).

 ISO9001: Secteur de fabrication et de transformation (donc logiciel) [ISO9002 = services]

 ISO9000-3: Adaptation de ISO9001 pour le logiciel

 Lignes directrices:

1. Responsabilité de la gestion (de l'équipe de gestion).

2. Exigences du système de qualité. (développer un plan, un manuel?) 3. Revues des contrats (procédure pour définir les contrats)

4. Exigences pour la conception du produit (contrôle de la conception)

Cours 5, mercredi 24 janvier 2007

5. Contrôle de la documentation 6. Exigences pour les achats 7. Produits fournis par le client

8. Identification et la traçabilité des produits (identification des versions, etc.) 9. Exigences pour le contrôle du processus

10. Inspection et test des produits (inspection du code, des diagrammes, etc.)

11. Contrôle et inspection des équipements (les outils utilisés doivent être certifiés)

12. État des inspections et tests

13. Contrôle des produits non-conformes (quoi on en fait) 14. Actions correctives et préventives (Comment on va

corriger/prévenir les non- conformités)

15. Manutention, stockage, conditionnement et livraison des produits. (règles de qualité à ce sujet).

16. Enregistrement de qualité

17. Audits internes de qualité (groupe interne qui va vérifier la conformité périodiquement).

18. Formation (sur les outils autant que sur le processus en tant que tel)

19. Service après vente.

20. Techniques statistiques (Sélectionner les techniques pour analyser les données collectées régulièrement. Doit être documenté, prévu, etc.)

 Certification:

1. Avant de faire la demande, s'assurer que le processus fonctionne bien.

2. Utilisation des services d'un consultant externe en assurance qualité pour le suivi, le soutien et la formation.

3. Demande auprès d'un organisme de certification 4. Examen et analyse de la documentation

5. Contrôle in situ, comparaison du processus réel avec la documentation 6. Description détaillée des écarts et discussions.

 Contrôle et suivi:

1. Deux visites sans préavi par année.

2. Retrait de la certification si les écarts signalés n'ont pas été corrigés ou qu'il y a trop d'écarts.

Chapître 3: Qualité du produit logiciel

 Introduction.

Pourquoi évaluer la qualité d'un produit?

o Achat d'un logiciel (alternatives) o En cours d'utilisation

o Contrôle de qualité durant le développement

o Questions: Est-ce qu'il fait ce qu'on veut / Dans quelle mesure le fait-il?

 Dimensions

Il est nécessaire de définir les caractéristiques (quoi?)

Il est nécessaire de décider quelles techniques utiliser pour évaluer chacune d'elle. (Comment?) Le «Quoi» ou la définition des caractéristiques de qualité. ISO/IEC 9126  6 caractéristiques de qualité.

1. Capacité fonctionnelle [functionality]

Ensemble d'attributs portant sur l'existence d'un ensemble de fonctions et leurs propriétés.

Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites.

Sous-caractéristiques:

- Aptitude: la présence et l'adéquation d'une série de fonctions pour des tâches données - Exactitude: fourniture de résultats ou d'effets justes ou convenus

- Interopérabilité:la capacité à interagir avec des systèmes

- Sécurité: la capacité à empêcher totu accès non-autorisé (accidentel ou délibéré) au programme et aux données.

2. Fiabilité [reliability]

Ensemble d'attributs portant sur l'aptitude à maintenir son niveau de service dans des conditions précises et pendant une période déterminée.

Sous-caractéristiques:

- Maturité: fréquence des défaillances dues à des défauts du logiciel

- Tolérance aux fautes: aptitude à maintenir un niveau de service en cas de défaut du logiciel ou de violation de son interface.

- Possibilité de récupération: aptitude à récupérer après une panne sans perdre le fil des opérations...

3. Facilité d'utilisation [usability]

Ensemble d'attributs portant sur l'effort nécessaire pour l'utilisation et l'évaluation individuelle de cette utilisation par un ensemble défini ou implicite d'utilisateurs.

Sous-caractéristiques:

- Facilité de compréhension: qu'est-ce que ça fait et comment s'en servir.

- Facilité d'apprentissage: effort nécessaire pour apprendre comment se servir du logiciel.

(dépendant entre autre des utilisateurs cibles.)

(faire attention d'éviter le rejet pour cause de "surdifficultés") - Facilité d'exploitation: effort nécessaire pour utiliser le logiciel (122 clics...)

4. Rendement [efficiency]

Ensemble d'attributs portant sur le rapport existant entre le niveau de service d'un logiciel et la quantité de ressources utilisées dans des conditions déterminées.

Sous-caractéristiques:

- Comportement vis-à-vis le temps: Temps de traitement, de réponse, débit...

- Comportement vis-à-vis les ressources: Mémoire, etc. Quantité de ressources utilisées, durée d'utilisation, etc.

Cours 6, jeudi 25 janvier 2007

5. Maintenabilité [maintanibility]

Ensemble d'attributs portant sur l'effort nécessaire pour faire des modifications données.

[ Coût réel d'un logiciel = Coût développement + Coût de maintenance ] Sous-caractéristiques:

- Facilité d'analyse: effort nécessaire pour diagnostiquer ou pour identifier les parties à modifier

- Facilité de modification:effort nécessaire pour modifier le code, modifier l'environnement, ...

- Stabilité: risque encourru par une modification (effets de bord) - Facilité de test:

6. Portabilité [portability]

Ensemble d'attributs portant sur l'aptitude du logiciel à être transféré d'un environnement à un autre.

(plateforme (OS ou processeur), mais aussi langue, ...) Sous-caractéristiques:

- Facilité d'adaptation: capacité d'adapter le logiciel sans faire d'autres changements que ceux défénis ou convenus.

- Facilité d'installation: nombre d'étapes à suivre, ...

- Conformité aux règles de portabilité: fichier des messages, classes d'interfaces, etc.

- Interchangeabilité: modules remplaçables (mêmes interfaces), logiciels lui-même, programmation par composante, ...

Il faut se souvenir que ces critères ne sont pas forcément disposés en arbre, mais plus dans une forme de réseau multi-liés...

Le «Comment» ou la définition du processus d'évaluation.

 ISO9126 propose les grandes lignes d'un processus.



ISO/IEC 14598 propose un cadre un peu plus précis.

 SCOPE projet Européen pour l'évaluation de la qualité.

ISO9126: 3 étapes:

1. Définition des exigences de qualité

 Caractéristiques 2. Préparation de l'évaluation

 Sélection des métriques

 Définition des taux de satisfaction

 Critères d'appréciation (conséquences selon les niveaux) – Interprétation des résultats

Cours 7, mercredi 31 janvier 2007 absent

Cours 8, jeudi 1^er février 2007 Mesure:

Associée à un modèle

Le modèle détermine  associer les attributs du monde réel aux éléments du système numérique.

Permet d'effectuer des prédictions exemple (pas réaliste): LOC (Lines of codes)

Effort = a x Loc

me permettrait de prédire (ici linéairement) l'effort qui sera nécessaire pour créer un logiciel.

ex.: Voyager MontréalToronto

coût = distance x coût_essence / consommation

note: métrique == définition de ce qu'on veut mesurer.

III- Échelles de mesures:

Définition: Ensemble constitué d'une méthode de mesure M et les sytèmes de relations empiriques.

Quoi utiliser?

Utiliser les nombres réeles quand c'est possible.

Une échelle A est plus riche qu'une échelle B si tout ce qu'on peut faire avec B peut être fait avec la première.

Types d'échelles: (Stevens) [5]

Échelle nominale (aucun ordre, même si représentés par des chiffres)

ex.: sexes [1:F, 2:H], couleurs[...], religions[...], processus de développement (cascade, proto), langages de programmation.

propriétés: exclusion mutuelle et exhaustivité =  Échelle ordinale (ordonné)

ex.: niveaux CMM, taille [petit moyen grand]

propriétés: transitivité, complétude =  < >

Échelle intervalle Échelle ratio Échelle absolue

Démo 3, jeudi 1^er février 2007

TP1: Rapport: Intro, Conclusion (sujet fermé sujet ouvert (améliorations)), Driagramme de classes, But, Discussion sur problèmes, Choix, philosophie.

Identifiant du Star = ID du Fact_table lignes de compilation

ligne de commande

Cours 9, mercredi 7 février 2007 absent

Cours 10, jeudi 8 février 2007

En général, une mesure indirecte n'est jamais plus riche que n'importe quelle mesure qui la compose.

ex.: T = D/E (T:efficacité du test D:nombre de fautes trouvées E:effort)

Comme E est de niveau ratio, on aura un résultat de qualité ratio même si D est absolue.

Donc, il faut s'assurer que chaque composant du calcul est au moins du niveau voulu.

Comment vérifier si ma mesure est valable, si elle mesure bien ce qu'on veut mesurer?

1-

Validation intuitive.

On peut de visu déterminer si notre mesure est réaliste.

2- Validation théorique

Le plus on a des axiomes qu'on peut définir et qui se vérifierons, le plus la mesure capture bien l'information ex.: |M(x)-M(x)| ≤ |M(x)-M(y)| transitivité etc.

3-

Validation empirique

On ne cherche pas à s'assurer si la mesure est bien liée à ce qu'on mesure, mais plutôt un bon outil prédictif (par exemple statistique) pour un attribut de notre projet.

Méthodes pour faire des systèmes de prédiction:

- Expérimentation - Utilisation effective Outils de base:

o Statistiques o Probabilités

o Réseaux bayésiens  Probabilités (tables/arbre de décision)

Cours 11, mercredi 14 février 2007 Chapitre 5: Mesure et qualité

I – Introduction:

Objectif  Mesures  Données  Faits & tendances  Décisions  Actions II- Aspects mesurables:

 Attributs internes: se mesure sur l'activité sans considérer autre choses

 Attributs externes: se mesure sur les liens avec l'environnement o Processus (son utilisation, pas sa définition)

Série d'activités reliées au développement du logiciel

Attributs internes: durée d'une activité, effort pour une activité/le processus o Produits

Objets produits à partir du processus (livrables, documents, ensemble tests, cahier de charges, etc.) Attributs internes: taille, complexité, couplage, cohésion

Attributs externes: portabilité, maintenabilité, etc.

o Ressources

Entités exigées par une activité du processus

Attributs internes: ressources, matériel (au sens large), méthodes Remarques:

- Les attributs internes sont souvent utilisés pour prédire les attributs externes.

- Les systèmes de prédiction qui fonctionnent ont tout juste quelques entrées, pas 10-15 (trop!)

Comment choisir les mesures:

III- GQM: (Goal Question Metric) [Basili]

1ere étape: Définir/Énumérer les objectifs principaux d'un projet (général ou de développement, de maintenance ou d'expérience)

2em étape: Pour chaque objectif, on va dériver les questions dont les réponses permettent de savoir si on a atteint l'objectif.

3em étape: Décider de ce qui doit être mesuré pour répondre convenablement aux questions.

but/objectif questions

mesures

Composants de l'approche:

 Paradigme: principes à suivre pour appliquer l'approche - Mesure guidée par l'objectif

- Programme de mesure explicitement documenté

. Permet de définir des mesures de manière systématiques et appropriées et permet d'interpréter les résultats de la mesure

. Permet d'évaluer la validité des conclusions et éviter ainsi le phénomène de rejet.

- Tâche d'analyse à exécuter . Spécifier avec précision . De manière explicite - chaque métrique

. Justifié (explicitement documenté)

 expliquer la collecte (guider l'analyse et l'interprétation)

 Plan: ce qu'on doit produire (en gros, l'arbre ci-haut: but/objectifs, questions, mesures) - Niveau conceptuel

. Un objectif est défini pour une entité, en fonction d'un modèle de qualité, par rapport à un point de vue, dans un environnement donné.

« Analyser <objet> dans le but de <but> par rapport à <facteur de qualité>

du point de vue de <perspective> dans le contexte <contexte>. » ex.: "Analyser l'inspection du code dans le but d'évaluer par rapport à l'efficacité

du point de vue du développeur dans le contexte .. xyz."

- Niveau opérationnel

. Un ensemble de questions est utilisé pour définir quantitativement l'objectif et son interprétation.

. Deux types de question: modèles de qualité / facteurs d'influence - Niveau quantitatif

. Un ensemble de données est associé à chaque question permettant d'y répondre quantitativement.

 Méthodes: guides pour appliquer le plan (et remonter dans l'arbre à la fin)

Exemple:

Objectif: Identifier très tôt les modules générateurs d'erreurs Questions: Qu'est-ce qu'un module générateur d'erreurs? (1)

Est-ce que la complexité influence la génération d'erreurs? (2) (complexité) Combien de tests seront effectués par module? (3)

Mesures: (1) et (2) Données sur les fautes par module Nombre de fautes par phase de test Nombre d'échecs attribués à un module (1) et (2) Données sur la taille et la complexité des modules

Loc (nombre de lignes de code) WMC (mesure de complexité) (2) et (3) Effort de test par module

Cours 12, jeudi 15 février 2007

absent Remarque intra: jusqu'au chapître 5.

Cours 13, mercredi 21 février 2007 Chapître 6: Études empiriques

I- Introduction

On veut se servir des attributs internes pour estimer les attributs externes. Le problème est qu'on n'a pas de théorie forte qui sera valable dans tous les cas pour modéliser les estimations. On a donc beosin d'une méthode pour valider, adapter ou construire de nouveux modèles. On aura donc besoin de faire des études empiriques [collecter les données, voir l'historique, etc.]

II- Éléments d'une étude empirique 1- Objectif de l'étude

a. Choisir le type de l'étude

i. Étude d'ensemble (sondage): général, par questionnaire, opinions, etc.

- Étude rétrospective d'une situation

- Comparaison avec des situations semblables ii. Étude de cas:

- Identifier les facteurs principaux qui peuvent affecter les sorties d'une activité - Documentation de l'activité [entrées, sorties, contraintes, ressources]

Note: Objet [objectif final] vs Sujets [média employé] d'une étude.

iii. Expérience: étude rigoureuse et controllée

-

Identifier les facteurs principaux qui peuvent affecter les résultats d'une activité.

- Manipulation des facteurs pour étudier leur impact sur les sorties

(démarche scientifique)

* Contrôlée: où on utilise un groupe de contrôle, un groupe qui est dans la même situation de base, sauf pour l'élément testé.

* Naturelle: où c'est la nature qui change les paramètres...

on a plusieurs objets, comme dans contrôlée,mais pas étude de cas

* Quasi-expériences: Soit il est impossible de tester réellement

Soit il est impossible de trouver un ensemble de test parfait alors on teste directement (moins rigoureux)

b. Définir et énoncer les hypothèses

i. L'objectif doit être clairement énoncé, donc à travers une ou plusieurs hypothèses.

- Une hypothèse, c'est o une prédiction

o une affirmation provisoire qui décrit ou explique un phénomène o une explication anticipée (pas prouvée encore)

- Une hypothèse, ça provient de

o d'une analogie (on inspire d'une phénomène semblable tiré d'ailleurs) o d'une observation / de l'expérience

o de données existantes (analyse de statistiques) - Les hypothèses doivent être

o quantitatives (non ambigües)

Note: Hypothèse nulle [Prouver que le contraire est faux.]

ii. Signification statistique  Confiance (v) où p = 1-v

Si p < seuil, alors on accepte la valeur de l'hypothèse (pas sa véracité)

ex.: Si mon niveau de confiance est 95% souhaitée, alors on doit avoir p < 5%

c.

Définir et étudier les variables

i. Quelles sont les variables qui vont affecter la véracité de l'hypothèse ii. Évaluer le degré de contrôle sur ces variables

- Variables d'état  indépendantes

manipulables, caractérisent l'objet de l'étude et influence le résultat - Variable dépendante

elles représentent le résultat et sont affectées par la manipulation des variables indépendantes

- Variables parasites / source de bruit elles sont inconnues ou incontrolables d. Interpréter et généraliser les résultats

2- Conception

3- Techniques de collecte des données 4- Considérations pratiques

5- Techniques d'analyse de données 6- Application des résultats

Cours 14, mercredi 14 mars 2007 Conception

Préparation Dénombrement Analyse

Diffusion et prise de décision Commenter et interpréter

Permettre à des tiers de reproduire l'expérience Mettre en œuvre les changements suggérés Application des changements à grande échelle Conduire des expériences plus précises ...

Information complémentaire:

 Échantillonnage

o Aléatoire simple

o Systématique (1^er aléatoire, n suivants)

o Stratifié aléatoire (on fait un échantillonage particulier par strate...) [±méthode des quotas]

o de Commodité (on fait avec ce qu'on a)

o Méthode des quotas (on prend les sujets ds différentes catégories de la population) [sondages]

 Critères:

 Taille

 Domaine

 Nature

 Open source / non

 Marge d'erreur difficile à calculer

 Format des données

o On préfère généralement un format textuel simple à un format binaire (csv, arff, voire xml)

 CVS (Coma Separated Value)  standard - ASCII (représentation d'une matrice) ...

 ARFF (Attribute Relation File Format)

@RELATION Metrics-Roles

@ATTRIBUTE CBO REAL

@ATTRIBUTE DIT READ ...

@ATTRIBUTE Roles {0,1}

@DATA

(ici comme CSV)

 XML

- arbre de représentation - DTD (... pour le format ...)

 Binaires...

- Généralement propriétaire - Illisible pour l'humain

- Nécessite une définition du format - Généralement compact

 Considérations pratiques o Types d'erreurs

 Erreurs d'expérimentations (mauvaise techniques, mauvais échantillons)

 Erreurs d'observation (mauvaises informations (préiméees?))

 Erreurs de mesure (...)

 Variation des ressources expérimentales (CPU/RAM libre, etc...)

 Effet combiné des variables non prises en compte (bruit)

 Remède? Répéter l'expérience plutôt que la mesure.

 Utiliser autant que possible l'aléatoire. (effets de fatigue et/ou d'apprentissage)

Cours 15, jeudi 15 mars 2007 absent

Cours 16, mercredi 21 mars 2007

Chapître 6: Étude empirique (un exemple) ... (suite) ...

Collecte des données:

Choix des objets (échant. de commodité) Choix les sujets (échant. de commodité) Préparation

Déroulement

- Hors du contexte scolaire habituel - Ordre aléatoire

- On élimine les paires sujet/élément lorsqu'il y a erreur Technique

- modèle plus flexible (Classificateur bayésien)

(traitement en régression, par exemple avec un arbre bayésien...) Split:

[Modèle de recherche avec des techniques d'I.A., ex.: 66% pour bâtir, 33% pour tester le modèle]

V-fold cross validation:

On découpe en v groupes (on bâti avec v-1 groupes et on teste sur le dernier groupe) on prendra alors l'erreur moyenne...

Cas particulier: Leave-one-out (on laisse un suel élément à l'extérieur et on fait toutes les combinaisons)

note: Régression s'applique à un espace continu.

Classification s'applique à un nombre de valeurs limité et petit.

Dans le cas binaire, on obtient une matrice de confusion:

(la diagonale représente les bonne prédiction, bien sûr)

ii ij

Exactitude n

  n



Chapître 7: Mesure du produit logiciel

I- Introduction: Il y a de nombreuses études qui montrent que les attributs internes du logiciel influencent la qualité (attributs externes) du logiciel. Par exemple, une obnne structure entrainera, en général, une bonne qualité. Ce qui veut dire qu'influencer sur la structure aura un impact sur la qualité (...) Comme les attributs internes sont mesurés tôt, on peut s'en servir pour prédir les attributs externes qui eux seront mesurés tardivement.

Produit: pas seulement le code!

Produit Exemple d'attributs internes

Spécification Taille, Réutilisation (déjà existentes ou neuves?), Modularité, Fonctionnalité, Redondance, Cohérence, ...

Conception Taille, Réutilisation, Modularité, Couplage, Cohésion, Fonctionnalité, ...

Code Taille, Modularité, Couplage, Cohésion, Fonctionnalité, Complexité algorithmique, Structure du flot de contrôle, Héritage, ...

Données de test Taille, Couverture, Réutilisation, ...

II- Taille: Historiquement, ce fut un des premiers aspect mesuré.

(Similaire au concept de taille humaine) Trois types de taille (du logiciel):

- Physique Code:

Nombre de lignes de code (LOC) ex.: cat * | wc –l

Ambigü: Commentaires? Déclarations? Lignes multi-instructions?

Définition la plus répendue: Une ligne est comptée si elle n'est pas

un commentaire ou vide, peu importe le nombre d'instructions.

NCLOC

Le nombre de lignes de commentaire: CLOC Densité des commentaires: CLOC/LOC

Nombre d'octets: CHAR ex.: cat * | wc –c

Généralement, on aura LOC = CHAR /  où  est le #caract./ligne moy.

DSI: Nombre d'instructions livrées (relativement facile en java ou smalltalk:

bytecode)

Conception: (Textes, diagrammes...) Nombre de pages

Approche de DeMarco: 3 vues

Fonctionnelle [flot de données (ellipses) et dictionnaire de données (items)]

Données [modèle entité/relation]

États [modèle entité/transition]

... en ajoutant ces mesures à celle du texte qui est triviale, on a une mesure.

 Comme il est important de prédire la taille du code très tôt.

Technique simple: Ratio d'enpension  où  = taille code / taille conception

1 n

i i

LOC  S



 

où S est la taille de la conception...

Autre technique:

49 1,01

D L où L, lignes de code et D la taille de la documentation

Cours 17, jeudi 22 avril 2007

- Fonctionnelle (Le nombre de fonctionalités fournies par un logiciel)

~ excellent pour prédire coûts et efforts

Points de fonction (Albrecht)

L'objectif est de mesurer la quantité de fonctionnalité offerte par un logiciel à partir de sa spécification.

Le FP sont calculés à partir des points de fonction non-ajustés (UFC).

UFC: spec  représentation  élément

> Entrées externes (intrants): Éléments de données fournies par l'utilisateur.

> Sorties externes (extrants): Éléments de données fournies à l'utilisateur.

(Étant, messages, etc.)

> Requêtes externes: Entrées interactives

> Fichiers externes: Toute interface compréhensible par le logiciel avec

d'autres systèmes

> Fichiers internes: Les fichiers principaux logiques dans le logiciel. (.ini, .lang,...)

ex.: Vérificateur d'orthographe Spécification:

o VO accepte en entrée un document et optionnellement un dictionnaire personnel.

o VO affiche tous les mots qui ne sont pas dans les dictionnaires (princ+perso)

o L'utilisateur peut demander à tout moment le nombre de mots traités et le nombre d'erreurs

 #EE = 2 (noms fichiers)

 #SE = 3 (nombres en sortie)

 #R = 2 (requêtes d'infos)

 #FE = 2 (doc, dic)

 #FI = 1 (dic normal)

Complexité subjective:

Échelle ordinale (simple, moyen, complexe) Facteur de pondération

Donc, en

résumé, ¹⁵

   

1

_ _ ( ) ( )

i

UFC Nb elem type i pond i



 

[dans notre exemple]: Si on suppose tout de difficulté moyenne: UFC= 2x4 + 3x5 + 2x4 + 2x10 + 1x7 FP = UFC x TFC où 0,65 ≤ TFC ≤ 1,35 selon la difficulté technique du domaine.

Facteurs d'influence de la complexité technique:

Backups? Fonctions distribuées? Configuration très utilisée? Facilité d'opération?

Saisie de donnée? Facilité de changement? etc. (14 facteurs de complexité) Chaque facteur est noté de 0 à 5.

14

1

0,65 0, 01 ( )

i

TFC note i



  

Cours 18, mercredi 28 mars 2007 Métriques BANG (DeMarco)

Bang fonction = nombre de processus de bas niveau du diagramme de flux de données (bas bas niveau) pondération en fonction de la nature/complexité

Type d'élément Facteur de pondération Simple Moyen Complexe

EE 3 4 6

SE 4 5 7

R 3 4 6

FE 7 10 15

FI 5 7 10

Bang données = Nombre d'entités du diagramme Entité-Relation pondération par le nombre de relations

Complexité:

Structure de flot de contrôle

* Graphe de flot de contrôle: GFC Graphe orienté

Noeud = instruction

Arc = Flot de contrôle entre instructions Autres concepts

(DE) Degré d'entré: nombre d'arcs incidents (entrants) (DS) Degré de sortie: ...

Noeud procédure  DS=1 (degré de sortie de 1) Noeud prédicat  DS>1 (case, if, …)

Chemin: séquence d'arcs consécutifs Chemin simple: chemin sans répétition

ex.: 10 lire p 20 lire e 30 cal :=1 40 si e~=0 alors 50 tant que e>0 faire 60 cal:=cal*p

70 e:=e-1 80 fin_faire 90 fin_si 100 ecrire cal 110 fin

Séquences:

P0: P2: Pn:

D0: if a then A D2: while a do A

D1: if a then A else B D3: repeat a until A

Cn: case a of …

Complexité cyclomatique de McCabe: V(F)

GFC F

n noeuds et e arcs

V(F) = e-n+2 #arcs - #noeuds + 2

V(F) = 1+d d sont des noeuds prédicats(dans un case on comptera n-1) V(F) = r (nombre de régions dans F) où région est un espace limité par des arcs (+ l'univers) ex.: le pseudocode à numéros plus haut donne 3.

III- Couplage:

Définition: Degré d'interdépendance entre les éléments du logiciel Types:

R0: Pas de couplage (modules indépendants)

R1: Couplage de données (x et y communiquent avec des paramètres) R2: Couplage de signature (x et y acceptent les mêmes types de paramètres)

R3: Couplage de contrôle (x passe un paramètre à y, qui influence le contrôle [la réaction  if par ex]) R4: Couplage par variable globale commune(x et y accèdent à une même donnée globale)

R5: Couplage de ocntenu (x modifie des données ou des instructions dans y)

Graphe de couplage: (2,2) signifie R2 deux fois

(type, nombre d'occurrences)

couplage(x,y) = i + n/(n+1) où i = pire type de couplage et n = nombre total d'occurrences ex.: couplage(M2, M4) = 5 + ¾ = 5,75

couplage(M1, M3) = 3 + 2/3 = 3,66

Soit S un système comportant des modules M1, M2, ..., Mn. Le couplage de S (au complet) est:

C(S) = mediane{C(Mi,Mj) : 1≤i≤n et 1≤j≤n et ij}

Cours 19, jeudi 29 mars 2007 IV- Cohésion:

Définition: Degré de participation des composants du module à une même tâche.

Types: (de la plus à la moins désirable)

- Fonctionnelle: un module = une fonction bien définie

- Séquentielle: un module = plusieurs fonctions dans l'ordre de la spécification

- Communicationnelle: un module correspond à plusieurs fonctions, mais toutes sur le même ensemble de données

- Procédurale: un module = plusieurs fonctions, mais toutes appartenant au même processus - Temporelle: un module = plusieurs fonctions intervenant dans le même laps de temps.

- Logique: un module = plusieurs fonctions liées logiquement.

- Coincidence: un module = plusieurs fonctions sans aucun lien.

o Un module peut avoir plusieurs types de cohésion.

o Dans ce cas, on notera la cohésion la moins désirable.

o L'héritage a été ajouté à ces types depuis l'arrivée des objets.

Ratio de cohésion = #modules fonctionnelle / #modules total

V- Métriques orientés objets: [Chidamber & Kamerer]

- DIT (Depth of Inheritence Tree):

Si DIT est grand: héritage de beaucoup de méthodes ce qui peut en rendre le comportement imprévisible.

Arbre profond  conception complexe

DIT grand  réutilisation des méthodes héritées

- NOC (Number Of Children):

Nombre de descendants immédiats.

Plus NOC est grand, plus la réutilisation est effective.

Plus NOC est élevé, plus il y a de risques d'utilisation erronnée de l'héritage (exceptions, etc.) - WMC (Weighted Method per Class): [taille]

Somme pondérée de la complexité des classes.

1

( )

ⁿ

( )

_i

i

WMC c Complexité m



 

par exemple, si toutes les méthodes ont une complexité de 1, WMC=nombre de méthodes cp(mi) peut être V(mi) complexité... déjà vu plus haut.

Plus WMC est grand, plus les classes héritées vont être affectées.

Plus WMC grend, plus la classe est spécifique à l'application  moins réutillisation.

Démo 9, jeudi 29 mars 2007 S-PLUS:

Intéressant: Statistiques / Data summary / Summary | Correlation

Statistiques / Compare / One sample / t / Mean = 5 ... \_ vérifier pour p-value < 0,05 ! Statistiques / Compare / Two samples / t ... /

Statistiques / Regression / Linear  "values"

Cours 20, mercredi 4 avril 2007

Chapître 8: Collecte et analyse des métriques II- Techniques d'analyse d'une variable

> Diagramme de boîte: (box plot) m = 54

l = 31 l et u sont définis comme u = 83 le groupe des 2^e et 3^e quart d = u-l = 52 de la distribution...

s = u+1,5d = 161

i = l – 1,5d = -47 (mais limité à 0 dans ce cas)

Donc, si j'analyse une variable dont une valeur dépasse 161, on en dira qu'il est un point extrème et on ne le considèreront pas.

> Diagramme de nuage de points:

Pour se donner une idée... permet de voir certain effets de seuil.

> Test de Kolmogorov-Smirnov

Pour déterminer si la distribution suit une loi normale. Ce qui permettra ensuite d'utiliser ensuite des tests comme le t-test (Student).

III- Techniques d'analyse de deux variables

> Diagramme de nuage de points

Généralement la variable indépendante est en x et la dépendante en y.

> Mesure d'association

Coefficient de corrélation de Pearson (r): -1 ≤ r ≤ 1  1 = forte corrélation positive 0 = pas de corrélation

-1 = forte corrélation négative

~ .5 est la limite

~ .6 corrélation de base

~ .8 forte corrélation

degré de liberté, nombre de paires -2

1

2 2

1 1

( )( )

( ) ( )

n

i i

i

n n

i i

i i

x x y y r

x x y y



 

 



  



 

dans notre exemple:

11282, 29

0,894 542, 24 23, 26 



 Fortement

> Corrélation robuste: (ne fait pas l'hypothèse de la normalité) Coefficient de corrélation de rang de Spearman (p):

On va utiliser le rang de chaque valeur (ce qui sera forcément distribué normalement) En attribuant les rang, si on a une égalité, on attribue le rang moyen à chacune des valeurs.

On pourra ensuite (au choix) utiliser Pearson.

2

1 1

2

2 2

1 1

( )( ) 6

1 ( 1)

( ) ( )

i i

i i

n n

x x y y i

i i

n n

x x y y

i i

r r r r d

r r r r n n



^{ }

 

 

  

   

 

 

^{où di=rxi-ryi}

Cours 21, jeudi 5 avril 2007

Régression linéaire: minimiser les distances à la droite, en fait les erreurs. (le carré des résidus) S-PLUS: Stat/Compare/2/t-test ou rank (normal ou pas)

var1 = ce sur quoi on veut voir si c'est significatif var2 = pour distinguer les groupes (+ case à cocher) confidence = 0,95

alternative = less (par exemple) OK

... wilkokson avec le reste pareil

en gros, si la p-value < 0,05, c ok, i.e. on rejete l'hypothèse nulle Maintenant, on veut savoir si réutilisabilité est impactée par autres facteurs.

Stat/Regression/linear Dependent = réutil

Indep = les autres vars ? utile  PLOT / sqrt abs resid

...

intéressant: les "values" et probs... si value grand = grande influence, prob = prob d'erreur de conclu.

F-stats (p-value) nous donne encore la probabilité qu'on se trompe de conclusion

Corellation:

...

tableau des paires (matrice triangulaire)

Démo 10, jeudi 5 avril 2007 Fin de démo7.doc (

H04difff1 etc

)

CBO: coupling between objects (nombre de classes qui utilisent ou sont utilisées par une classe de données) 9

LCOM: Lack of Cohesion in method (qui n'utilise pas / qui utilise)

méthode utilisant les mêmes attributs de la classe moins les méthodes n'utilisant pas les mêmes attributs.

5 attributs ds scribbe

init: clearbutton et color-c mousedown: last_x last_y

mousedrag: init, x, y 1-2=-1 = 0

pour les autres aussi 0

RFC: Response for class (combien de méthodes qui vont répondre aux requêtes extér. de cette classe toutes les méthodes pairs de cette class... ttes les méthodes publiques) rfc grande  classe importante

init=15 +0 +17 +27

=58

WMC: Somme de la complexité des méthodes (complexité indéterminée, ici c le NCLOC) Donc ici le nombre (total) de ligne de code à l'intérieur des méthodes

... en précisant si on compte ou pas les lignes avec juste { ou } ou la ligne de nom de la méthode 14+6+16=36 (en ne comptant pas les { et } )

démo8.doc

A interne B externe

4 53,96

13 59,04

21 57,41

21 56,43 Q1

23 54,56 boite 39

31 59,27 l -37,5

39 59,14 s 118,5

42 57,79

44 59,97

49 58,84

58 45,38

60 56,32 Q3

69 56,27

81 56,11

120 51,78

42 médiane Fin du cours