Notes personnelles IFT3913.doc - igt.net

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. |Matrice des|Utilisateur|Vendeur |Gestionnair|Programmeur|Professeur |
|importances| | |e de projet| |d'universit|
| | | | | |é |
|Facilité |X | | | | |
|d'utilisati| | | | | |
|on | | | | | |
|Compatibili|X | | | | |
|té / | | | | | |
|Portabilité| | | | | |
|Multiples |X |X | |X | |
|fonctions | | | | | |
|Haute |X |X | | | |
|Performance| | | | | |
|0 défaut |X | |X | | |
|Rapidité de|X |X |X | | |
|développeme| | | | | |
|nt | | | | | |
|Faible coût| | |X | | |
|de | | | | | |
|développeme| | | | | |
|nt | | | | | |
|Code | | | |X |X |
|élégant | | | | | |
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.
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