Partie 6: Qualité du Logiciel — Programmation orientée objet en C++

Programmation Orientée Objet en C++
6ème Partie: Qualité du Logiciel

Fabio Hernandez
Fabio.Hernandez@in2p3.fr

Vue d'Ensemble
Notions de base
Types, variables, opérateurs
Contrôle d'exécution
Fonctions
Mémoire dynamique
Qualité du logiciel
Evolution du modèle objet
Objets et classes
Fonctions membres
Classes génériques
Héritage
Polymorphisme
Héritage multiple
Entrée/sortie

POO en C++:Qualité du Logiciel 152 © 1997-2003 Fabio HERNANDEZ

Table des Matières

Qualité du logiciel
Facteurs de qualité
Apport de la technologie orientée objet
Maintenance du logiciel
Résumé


Qualité du Logiciel

Le génie logiciel s'intéresse à la production du logiciel de
qualité
Les techniques orientées objet aident à produire des logiciels
de bonne qualité
La qualité du logiciel est le résultat de la combinaison de
plusieurs facteurs internes et externes
Les facteurs internes sont perceptibles uniquement par les
personnes ayant accès aux sources du logiciel (développeurs)
modularité
lisibilité
facilité de modification
...


Qualité du Logiciel (suite)

Les facteurs externes sont perceptibles par les utilisateurs du
produit logiciel
Le but est d'améliorer la qualité des facteurs externes
Les techniques orientées objet aident à améliorer la qualité
interne comme un moyen d'atteindre la qualité externe


Facteurs de Qualité

Correction
capacité d'un produit logiciel à accomplir sa tâche exacte, telle que
définie dans la spécification
c'est une qualité indispensable
suppose d'avoir écrit une spécification précise des besoins du système à
construire, ce qui est en soi une tâche difficile
c'est une qualité conditionnée: le logiciel étant construit en couches, il
s'agit de garantir que chaque couche est correcte, en supposant que les
couches inférieures le sont aussi
Application
Bibliothèques de l'Application
Bibliothèques Standard
Compilateur
Système d'exploitation
Matériel


Facteurs de Qualité (suite)

Robustesse
capacité des systèmes de réagir correctement aux conditions anormales
la correction fait référence au comportement du système dans les cas
prévus dans la spécification
la robustesse caractérise le comportement dans des situations en
dehors de la spécification
la notion de normalité ou anormalité est relative à la spécification
un cas anormal est un cas qui n'est pas traité dans la spécification
normal ne veut pas dire souhaitable, mais prévu lors de la conception du
système
il y a toujours des cas que la spécification ne traite pas explicitement
si ces cas arrivent, le système ne doit pas provoquer des effets
catastrophiques (produire des messages d'erreur, travailler en mode
dégradé, terminer l'exécution de façon appropriée)



Extensibilité
degré de facilité d'adaptation des produits logiciels aux modifications à
la spécification
relative la taille du système: plus le système est grand, plus l'adaptation
aux changements est difficile
à la base de chaque système logiciel il y a un besoin humain: les
modifications sont donc inévitables (par exemple changements de la loi)
le changement est une constante dans le développement des produits
logiciel: changements de besoins, de notre compréhension des besoins,
des algorithmes, de la représentation des données, des techniques
d'implémentation
supporter les changements est un des objectifs principaux de la
technologie objet



Extensibilité (suite)
deux principes essentiels pour améliorer l'extensibilité:
simplicité de conception: une architecture simple est plus facile à adapter
décentralisation: plus les modules sont autonomes, plus il y a de chance que
les modifications affectent un seul ou un nombre limité de modules
Réutilisabilité
capacité des composants logiciel de servir pour la construction de
plusieurs applications différentes
les solutions logiciel suivent certains patrons: il devrait être possible
d'exploiter ces éléments communs pour éviter de réinventer des
solutions à chaque fois
en conséquence, moins de logiciel à écrire et à tester
plus de temps à consacrer pour améliorer les autres facteurs de qualité



Compatibilité
facilité de combiner des éléments logiciels avec d'autres
chaque élément logiciel a besoin d'interagir avec d'autres
chacun fait des suppositions différentes sur l'environnement
exemple: format des fichiers sur les différents systèmes d'exploitation
Efficacité
capacité de demander peu de ressources machine (processeur, espace
mémoire interne et externe, bande passante des dispositifs de
communications, ...) pour accomplir la tâche
en rapport avec l'extensibilité et la réutilisabilité: les optimisations trop
agressives peuvent rendre le logiciel tellement spécialisé qu'il devient
difficile de le modifier et de le réutiliser
la capacité de calcul est en constante croissance: pas besoin de gagner
une micro-seconde si cela compromet les autres facteurs de qualité



Efficacité (suite)
dans certains situations l'efficacité a des effets sur la correction
(météo, temps réel,...)
Portabilité
facilité de transférer les produits logiciel sur plusieurs plate-formes
l'expression plate-forme englobe la combinaison matériel et logiciel
(processeur, système d'exploitation, système de fenêtrage,...)
Facilité d'utilisation
degré de facilité avec laquelle des personnes de qualifications
différentes peuvent apprendre à utiliser les produits logiciels pour
résoudre des problèmes
facilité d'installation, de desintallation, d'opération, de surveillance, ...
ce facteur prend en compte les différents niveaux d'expertise des
utilisateurs potentiels (novice, intermédiaire, expert,...)



Facilité d'utilisation (suite)
un système bien conçu autour d'une structure claire a tendance à être
plus facile à comprendre et à utiliser
le concepteur du système doit faire un effort pour comprendre la
spécificité de la communauté des utilisateurs ciblés
les systèmes à succès vont toujours au delà de l'audience initiale prévue
par le concepteur (FORTRAN, UNIX,...)
un système conçu pour un groupe spécifique d'utilisateurs se base sur
des suppositions qui ne sont pas forcement vraies pour une audience plus
vaste
les concepteurs des interfaces homme-machine font des suppositions
aussi limitées que possible à propos des utilisateurs



Fonctionnalité
ensemble de possibilités offertes par un système
jusqu'où aller? Combien est-il suffisant?
l'introduction de nouvelles fonctionnalités peut induire une perte de
cohérence du système, et donc impacter sa facilité d'utilisation
Opportunité (Timeliness)
qualité d'un produit logiciel d'être disponible au moment où les
utilisateurs le désirent
Verifiabilité
facilité de préparation de procédures d'acceptation, des données de
test et des procédures pour détecter les problèmes



Intégrité
capacité d'un produit logiciel de protéger ses composants (programmes,
données,...) contre les accès et les modifications non autorisés
Réparabilité
degré de difficulté de détection et réparation des défauts
Economie
qualité d'un produit logiciel d'être terminé dans le budget affecté
Documentation
ce n'est pas un facteur de qualité en soi, mais plutôt une conséquence
d'autres facteurs
la documentation externe, qui permet aux utilisateurs d'un système de
le comprendre et de l'utiliser correctement, est une conséquence de la
facilité d'utilisation



Documentation (suite)
la documentation interne, qui permet aux développeurs de comprendre la
structure et l'implémentation du système, est une conséquence de la
nécessité d'être extensible
la documentation des composants, permettant aux développeurs de
comprendre ses fonctionnalités sans comprendre son implémentation,
est une conséquence de la nécessité de réutilisation


Apport de la technologie objet

comment la technologie OO améliore-t-elle ces facteurs de
qualité?
la méthode OO encourage un style de conception commun et des
interfaces entre modules standardisés (compatibilité)
la méthode encourage l'abstraction et l'encapsulation en
séparant spécification et implémentation (portabilité)
des mécanismes comme le polymorphisme et la résolution
dynamique aident à écrire des systèmes capables de s'adapter
automatiquement à la plate-forme (par exemple systèmes de
fenêtrage)
la réutilisation de composants de qualité industrielle résulte en
des gains considérables en performance


Apport de la technologie objet (suite)

les techniques OO permettent de construire systèmes plus
rapidement et à un coût inférieur et facilitent l'ajout des
nouvelles fonctionnalités


Maintenance du Logiciel

Maintenance c'est ce qui arrive quand un produit est délivré
pour son utilisation
Le coût de la maintenance du logiciel est estimé à 70% du coût
total du produit
Qu'est-ce qu'on entend par maintenance?
Au fur et à mesure que la spécification du logiciel change
comme conséquence des changements dans le monde externe, le
logiciel doit aussi évoluer
La correction des défauts fait aussi partie de la maintenance


Maintenance du Logiciel (suite)

Changements dans la spécification

Changements du format des données

41,80 %
17,60 % Correction d'urgence des défauts

Corrections de routine

Modifications du matériel
12,40 %
Documentation

3,40 % Améliorations de performance

4,00 % 9,00 %
5,50 % 6,20 % Autres

Source: OOSC [B. Meyer 1997]


Résumé

La qualité du logiciel est un compromis entre un ensemble
d'objectifs différents
Les facteurs externes, perceptibles par les utilisateurs du
système, doivent être différenciés des facteurs internes,
perceptibles par les développeurs et concepteurs
Ce qui importe ce sont les facteurs externes, dont la qualité est
conditionnée par la qualité des facteurs internes
La technologie OO peut aider à améliorer la qualité
Le coût du logiciel est impacté par le coût de la maintenance,
principalement dû à la difficulté d'implémenter des
modifications et par la forte dépendance des logiciels sur le
format physique des données


Partie 6: Qualité du Logiciel — Programmation orientée objet en C++

Contenu connexe

Tendances (20)

En vedette (10)

Similaire à Partie 6: Qualité du Logiciel — Programmation orientée objet en C++ (20)

Partie 6: Qualité du Logiciel — Programmation orientée objet en C++