Présentation Cours ACQL

Assurance et Contrôle Qualité du
Logiciel
Cours pour Master 1 (ISI et CPI) /2019-2020
Chargée du Module
Pr Farida Dahmani-Bouarab
Département Informatique,
FGEI, UMMTO, Tizi ouzou
Plan
1ere Partie
Concepts fondamentaux du génie logiciel
 Introduction
 Développement d’un logiciel
 Etapes de développement
 «Cycles de vie» du logiciel
 Les différentes phases du cycle de vie
 Les différentes types de cycle de vie
 Guide du corpus de connaissances en génie logiciel:
SWEBOK (Software Engineering Body of Knowledge)
24/03/202 Pr F. Bouarab-Dahmani 2
0 département informatique UMMTO
Plan
1ere Partie(suite)
Concepts fondamentaux du génie logiciel
 Approche de développement de logiciel Agile

 Autour du management de projet
 Constitution d’équipe de développement logiciel
 Ethique en génie logiciel
 Validation du logiciel
 Comparaison des moyens de validation
 Généralités sur les Tests de validation
département informatique UMMTO
Plan
2ieme Partie
Assurance et Contrôle Qualité du Logiciel
 La crise du logiciel et nécessité de gestion de la

qualité
 La qualité en génie logiciel
 Assurance & Contrôle Qualité
 Normes générales de qualité
 Sécurité des logiciels
 Gestion des configurations
Plan
3ieme Partie
Mini projet
 Une situation problème authentique

 Développement d’application en respectant la
démarche ACQL (utilisation outils de tests, de
production de documentation, cycle incrémental …)
 Evaluation itérative de la proposition avec une
grille d’évaluation critériée
Introduction : Caractéristiques du logiciel
 Produit unique: conçu et fabriqué une seule fois

 Inusable : défauts non dus à l'usure mais proviennent
de sa conception et évolution des besoins
 Complexe : le logiciel est fabriqué pour soulager
l'humain d'un problème complexe  il est donc par
nature complexe
 Invisible : Fabrication du logiciel = activité purement
intellectuelle  difficulté de perception de la notion de
qualité du logiciel
 Technique de développement non mature : encore
artisanal malgré les progrès de l’informatique
Introduction : Constats
 Le coût du développement du logiciel dépasse souvent

celui du matériel,
 Les coûts dans le développement du logiciel :
 20% pour le codage et la mise au point individuelle,
 30% pour la conception,
 50% pour les tests d'intégration,
 Durée de vie d'un logiciel de 7 à 15 ans,
 Le coût de la maintenance évolutive et corrective
constitue la part prépondérante du coût total
 Plus de la moitié des erreurs découvertes en phases
de tests proviennent d'erreurs introduites dans les
premières étapes,
 La récupération d'une erreur est d'autant plus
coûteuse que sa découverte est tardive.
Introduction : Les plaintes classiques des
clients
 Non respect du cahier des charges,

 Délais et coûts dépassant les prévisions,
 Maintenance corrective et évolutive difficiles,
 Non respect des performances,
 Documentations absentes ou peu claires,
 Manque d’agilité dans le processus de développement :
la solution arrive quand les besoins sont « périmés »
 Fiabilité discutable.
 QUALITE du logiciel doit faire partie du Génie logiciel
Introduction : Le Prix de la non Qualité
 « Si vous trouvez que l'éducation coûte

chère, essayez l'ignorance »
Abraham Lincoln, 16ème président des Etats-Unis de 1861 à
1865.
 La qualité logicielle est une notion difficile à caractériser

de manière exhaustive. En revanche, la non-qualité est
généralement perceptible de manière très concrète
Introduction : Le Prix de la non Qualité
 un message d'erreur signalant un plantage ou un

comportement inattendu
 Le bug d'Ariane 5 : La portion de code à l'origine du déboire avait

en fait été repris d'un ancien système (en l’occurrence Ariane 4), et
n'était malheureusement pas adapté à son successeur. En plus, le
système de guidage était doublé d'un deuxième système, dit de
secours. Or ce second système était la réplique exacte du premier :
quand il a pris la relève, il a réitéré les erreurs du premier. une perte
totale d'environ 370 millions de dollars et mission non accomplie !
 Le bug de la sécurité sociale : Un bug informatique faussant les

calculs de cotisation retraite (gestion des arrondis pour le calcul du
nombre de trimestres cotisés) a été découvert dans les systèmes de
l'Assurance sociale française en 2009
Introduction : Génie logiciel
 Ensemble des activités de conception et de mise en

œuvre des produits et des procédures tendant à
rationaliser la production du logiciel et son suivi.
Arrêté ministériel Français du 30/12/1983
 Procédures, méthodes, langages, ateliers, imposés ou

préconisés par les normes, adaptés à l'environnement
d'utilisation afin de favoriser la production et la
maintenance de composants logiciels de qualité.
P. Jaulent
Introduction : Génie logiciel
 Les principes et techniques de GL s’appliquent mieux aux

projets de grande taille Regroupant plusieurs personnes
Devant fournir plusieurs versions.
 Généralement de longue durée
 Ceci met en évidence les différences entre
 La programmation : une activité personnelle
 Le génie logiciel : une activité d’équipe au sein d’un projet
 En fonction de leur nature, les projets ont des
 besoins très différents :
 Logiciel commercial : lien avec les clients
 Logiciel exploratoire : souplesse
 Logiciel gros et complexe : spécifications stables
Développement d’un logiciel
 Caractéristiques souhaitées :
– Adéquation avec les besoins
– Maintenance aisée
– Bon marché
– Rapidement développé
 Comment ?
Le génie logiciel = outils + méthodes
Pour la conception et la programmation de logiciels
Etapes de développement
 Analyse et spécification(du problème)

comprendre et recenser les besoins et Spécification (par
exemple cahier des charges)
 Conception (du logiciel)

 Préliminaire :
- Eclater le logiciel en sous-parties (approche modulaire)
- définir les interfaces entre ces sous-parties
 architecture du logiciel (composants et liens)
 Détaillée : préciser l’architecture des sous-parties
 Implantation : Codage (programmation)
Activités de développement d’un logiciel
Valider le
logiciel
Assembler les
composants
Développer un à un
les composants
Définir comment
il sera développé
Définir ce qui
sera développé
L’organisation de ces activités et leur enchaînement définit le cycle de

développement du logiciel
Les « cycles de vie » des logiciels
(software lifecycles)
 Notion de cycle de vie
Description d'un processus couvrant les phases de:
- Création d'un produit,
- Distribution sur un marché,
- Disparition.
 But du découpage
- Maîtriser les risques,
- Maîtriser au mieux les délais et les coûts,
- Obtenir une qualité conforme aux exigences.
 Deux types de cycle de vie

-Cycle de vie des produits : s'applique à tous les types de produits
-Cycle de développement de logiciels s'insère dans le précédent,
on l'appelle souvent abusivement cycle de vie des logiciel
Le « cycles de vie » d’un logiciel
 Intérêt d’un cycle de vie
- Cycle de vie et assurance qualité sont fortement liés
- S’ assurer en permanence en cours de développement par :
* validation : sommes nous en train de faire le bon produit ?
* vérification : est ce que nous faisons le produit correctement?
24/03/2020 Pr F. Bouarab-Dahmani département informatique UMMTO 17

LES DIFFERENTES PHASES DU CYCLE
DE VIE
 Définition des Objectifs
 Le management étudie la stratégie et décide de la nécessité de

fabriquer ou acheter un nouveau produit. On s'intéresse aux
produits contenant du logiciel.
 C'est pendant cette phase qu'est défini un schéma directeur

dans le cas de la création ou de la rénovation d'un système
d'information complet d'une entreprise prenant en compte la
stratégie de l'entreprise (voir méthode Merise par exemple).
LES DIFFERENTES PHASES DU CYCLE DE VIE
 Définition des Besoins

 Un cahier des charges est établi par le client après
consultation des divers intervenants du projet ( utilisateurs,
encadrement...), un appel d'offres est éventuellement lancé.
 Le cahier des charges décrit, en langage naturel, les
fonctionnalités attendues du produit ainsi que les contraintes
non fonctionnelles (temps de réponse, contraintes
mémoire...).
 Dans le cas de la refonte d'un système complet on peut
avoir un cahier des charges par sous domaine.
 Le produit intermédiaire obtenu à l'issue de cette phase est le
cahier des charges.
 On peut décrire le produit à partir de différents scénarii
d'utilisation (Use Case).
 Définition du Produit
 Les spécifications précises du produit sont décrites ainsi que les
contraintes de réalisation.
 A l'issue de cette phase, les fournitures intermédiaires sont le
dossier de spécifications fonctionnelles et une première version du
manuel utilisateur.
 On peut également désigner cette phase par le terme analyse
des besoins. A l'issue de cette phase, le client et le fournisseur
sont d'accord sur le produit à réaliser et les contraintes auxquelles
il doit obéir ainsi que sur la façon de l'utiliser et en particulier sur
l'interface utilisateur qu'il s'agisse d'une interface homme-machine
ou d'une API.
 Les produits intermédiaires à l'issue de cette phase sont : le
dossier d'analyse comprenant les spécifications fonctionnelles et
non fonctionnelles du produit, une ébauche du manuel utilisateur,
une première version du glossaire contenant les termes du projet
 Il existe différentes méthodes et formalismes qui peuvent être
utilisés pendant cette phase
LES DIFFERENTES PHASES DU CYCLE
DE VIE
 Planification et gestion de projet
 Client et développeur doivent être d'accord sur les coûts et la
durée du projet.
 La phase de planification permet de découper le projet en
tâches, de décrire leur enchaînement dans le temps, d'affecter
à chacune une durée et un effort calculé en homme*mois.
 Définir les normes qualité qui seront appliquées comme la
méthode de conception choisie ou les règles qui régiront les
tests.
 Les produits intermédiaires à l'issue de cette phase sont : le
plan qualité, le plan projet destiné aux développeurs, une
estimation des coûts réels (utile pour le management), un devis
destiné au client précisant le prix à payer, les délais et les
fournitures, une liste des dépendances extérieures
 En cas de réalisation du produit par un sous-traitant le dossier
de spécifications fonctionnelles ainsi que le plan projet et le
plan qualité terminent cette phase et sont contractuels
 Conception globale
 L'architecture du logiciel est définie ainsi que les
interfaces entre les différents modules. On veillera
tout particulièrement à rendre les différents
constituants du produits aussi indépendants que
possible de manière à faciliter à la fois le
développement parallèle et la maintenance future. Il
existe différentes méthodes de conception (Merise,
SADT, …
 A l'issue de cette phase les produits intermédiaires
sont : le dossier de conception, le plan d'intégration,
les plans de tests, le planning mis à jour
 Codage et tests unitaires

 Chaque module est codé et testé indépendamment des
autres. Il existe différentes méthodes de tests.
 A l'issue de cette phase les produits intermédiaires sont
- les modules codés et testés
- la documentation de chaque module
- les résultats des tests unitaires.
- le planning mis à jour
 Intégration
 Chaque module testé est intégré avec les autres suivant le

plan d'intégration et l'ensemble est testé conformément au
plan de tests. Il existe des méthodes d'intégration
 A l'issue de cette phase, les produits intermédiaires sont :
- le logiciel testé
- les tests de régression
- le manuel d'installation
- la version finale du manuel utilisateur
 Qualification
Lorsque le logiciel est terminé et les phases d'intégration
matériel/logiciel achevées, le produit est qualifié, c'est à
dire testé en vraie grandeur dans des conditions normales
d'utilisation. Cette phase termine le développement. A
l'issue de cette phase le logiciel est prêt à la mise en
exploitation
 Maintenance
Lorsque le produit a été accepté, il passe en phase de
maintenance jusqu'à son retrait. C'est pendant cette phase
que tous les efforts de documentation faits pendant le
développement seront particulièrement appréciés de même
que la transparence de l'architecture et du code.
 Remarques
 La durée d'un cycle de vie est très variable d'un projet à

l'autre.
 Facteurs d'instabilité : Le modèle de cycle de vie ne

garanti pas le bon déroulement du projet : en effet, malgré
les précautions prises, des facteurs d'instabilité subsistent
notamment :
Facteurs externes : l'utilisateur évolue, l'environnement évolue
- Environnement modifié par le logiciel,
- Evolution de la législation, Evolution de la technologie,
- Evolution du marché et de la concurrence.
Facteurs internes: l'équipe de développement évolue
- Individus membres de l'équipe, Qualification de ces individus,
- Organisation qui gère le projet.
 Remarques
 Un cycle de vie apporte stabilité, contrôle et organisation à

une activité qui peut vite devenir ingérable. Il permet une
meilleure : „
 estimation des coûts et besoins„

 coordination„
 productivité„
 visibilité et compréhension
„
 Adopter et appliquer un cycle de vie est un signe de
maturité pour une entreprise
MODELES DE CYCLE DE VIE D'UN LOGICIEL
 Modèles linéaires
 En cascade
 Cycle en V, …
 Modèles non linéaires
 Prototypage
 modèles incrémentaux
 modèle en spirale
 Cycles de méthodes agiles
Le choix du type de cycle dépend de l’approche

adoptée pour le développent du logiciel.
APPROCHE DE DEVELOP. D'UN LOGICIEL
 Modèle en en cascade
 hérité de l'industrie du BTP
 Les phases traditionnelles de développement sont
effectuées simplement les unes après les autres
 Modèle en V
 imaginé pour pallier le problème de réactivité du
modèle en cascade
 met en évidence la nécessité d'anticiper et de
préparer dans les étapes descendantes les
« attendus » des futures étapes montantes Cycles de
méthodes agiles
 Modèle en spirale (de Bohem)
 Le développement reprend les différentes étapes du

cycle en V
 le début de chaque itération comprend une phase
d'analyse des risques
 Par l'implémentation de versions successives, le cycle
recommence en proposant un produit de plus en plus
complet et robuste
 Modèle semi-itératif
 a pour origine les travaux de James Martin publiés à
partir de 1989 dans diverses revues Nord
Américaines.
 fut totalement formalisé en 1991 dans le livre RAD4
(Développement rapide d'applications).
 Son adoption par RUP (Rational Unified Process)
d’IBM consacra l’apogée de ce cycle toujours en
vigueur dans les projets conséquents.
 les deux premières phases classiques : Analyse des
besoins et conception de la solution sont
classiquement conduites.
 la troisième et dernière grande phase (codage) se fait

en itérations courtes.
 2001 : apparition de plusieurs méthodes dont ASD,
FDD, Crystal, Scrum ou l'extreme programming …
uniformisée dans le cadre du Manifeste Agile (Agile
Manifesto) et de l'Agile Alliance et , avec le cycle
semi-itératif.
 Toutes les méthodes Agiles débutent par des phases
séquentielles, courtes mais bien réelles,
d'exploration, d'architecture et de planning.
 Un usage totalement itératif de ces méthodes n'est
cependant pas exclu mais ne peut s'appliquer qu'à de
très petits projets
 Modèle itératifs
 On sépare les activités des artefacts,
 un artefact étant le produit issu d'une activité.
 On applique un cycle de type roue de Deming sur
la production d'une documentation, d'un composant,
d'un test, etc.
 la roue de Deming (de l'anglais Deming wheel) est
une transposition graphique de la méthode de
gestion de la qualité dite PDCA (plan-do-check-act).
 Le cycle PDCA sert à transformer une idée en action
et l'action en connaissance. Utiliser le cycle de façon
correcte nécessite discipline et effort.
ROUE DE DEMING
 Rapportée à une activité de type gestion de projet,

les phases sont :
 la faisabilité : l'acceptation d'un nouveau besoin
 l'élaboration : on imagine comment on va le réaliser
 la fabrication : construction
 la transition : tout est mis en œuvre pour livrer au
client
 L'idée est de livrer au plus tôt quelque chose qui
puisse être testé par le client.
 Sachant que chaque itération ne dépasse jamais

huit semaines[
 a différence entre un PDCA et une itération est la
durée : elle doit être courte et régulière alors
qu'une roue de Deming appliquée à une
organisation de 300 personnes prend plusieurs
mois, voire plusieurs années.
LE GUIDE SWEBOK
 LE Guide du corpus de connaissances en génie logiciel:
SWEBOK (Software Engineering Body of Knowledge)
 Le guide de SWEBOK décrit l’ensemble de la
connaissance en génie logiciel généralement acceptée est
subdivisé en 10 domaines de connaissance dont les
descriptions sont conçues de telle manière qu’ils permettent
aux lecteurs de trouver rapidement les sujets d’intérêt
parmi les concepts importants
 Les dix domaines de connaissance sont les suivants :
1) exigences de logiciel,
2) conception de logiciel,
3) construction de logiciel,
LE GUIDE SWEBOK
4) Essai de logiciel,
5) Entretien de logiciel,
6) Gestion de configuration de logiciel,
7) Gestion de technologie de la programmation,
8) Processus de génie logiciel,
9) Outils et méthodes de génie logiciel
10) Qualité du logiciel.
Validation du logiciel
 Définition
 assurer la cohérence entre les besoins et le logiciel obtenu
 garantir au mieux l’absence d’erreur
 Moyens
 prototyper : développer et « essayer » une partie du logiciel
 tester : effectuer des essais de fonctionnement et
vérifier le résultat obtenu par rapport au
résultat attendu
 prouver : vérifier mathématiquement la cohérence de la
conception/du code par rapport à la
spécification (qui doit être formelle)
Comparaison des moyens de
validation
Ce qui est vérifié Cible Avantage Inconvénient
Prototyper La bonne Développ Intervient Aucune

compréhension du eurs très tôt garantie
problème sur résultat
Tester Un comportement Program Facilité de Intervient à
correct dans des cas me mise en la fin pas
bien précis exécuté œuvre exhaustif
Nombreux
outils
Prouver La correction par Code Garantie Lourd à
rapport aux et/ou obtenue mettre
Propriétés spécifiées concepti en place
formellement on
Conséquence : - Preuve réservée aux « systèmes critiques »
- Tests et prototypes toujours utilisés
LES TESTS DE VALIDATION
 Permet de détecter la présence d’erreurs dans un logiciel
(par l’observation des défaillances qu’elles induisent)
 Doit produire les mêmes résultats lorsque répété avec

les mêmes données et dans le même environnement
(attention aux variables et paramètres non initialisés :
leur valeur initiale (non définie) peut varier d’une
exécution à l’autre
 Doit être exact et précis. Une spécification formelle peut

contribuer à la réalisation de tests précis
 Peut parfois contribuer à identifier la localisation précise

des erreurs dans le logiciel
Types de tests
 Tests Unitaires : testent le codage
 Dans le cas d'un logiciel à objets
– Vérifier que chaque classe, chaque package
répond bien aux spécifications
– Tester chaque méthode Avec des valeurs
cohérentes et Avec des valeurs incohérentes
 Dans le cas d'un logiciel du genre C
– Tester toutes les fonctions : Avec des valeurs
cohérentes et Avec des valeurs incohérentes
Types de tests
 Tests Unitaires : Deux modes de test
 Tests en boîtes blanches :Faits Par le développeur

● On connaît la structure de la classe / méthode /fonction
– On teste en fonction de cette structure interne
● On essaye de passer par tous les chemins
– On prépare des jeux d'essais qui testent toutes les branches
 Tests en boîtes noires : Réalisés par quelqu'un de différent du

développeur. Pas obligatoirement, mais c'est mieux
● On teste la classe / méthode / fonction sans connaître
l'organisation interne, Uniquement en se basant sur les
spécifications
● On teste pour : L'exactitude & La robustesse
Types de tests
 Tests Fonctionnels : On teste une fonction
de bout en bout
● Les tests fonctionnels sont toujours des tests
en boîtes noires
– On ne prend pas en compte l'organisation interne
des classes / méthodes / fonctions
● Ces tests sont menés à bien pour un sous-
système bien précis
– Package par exemple
– Les autres sous-systèmes sont simulés
Tests Fonctionnels
● Les fonctions ne sont pas isolées les unes des autres, donc
===> Nécessité d'utiliser Bouchons & Maquettes ===>
développements et spécifications supplémentaires
Types de tests
 Tests d’Intégration : On intègre les éléments
- Consiste à remplacer progressivement les bouchons et

maquettes par des objets réels
- Il faut spécifier lors de la phase d'analyse l'ordre dans
lequel se feront les remplacements
-Plusieurs approches
* Contamination par fonction: On « suit » une fonction
et on remplace les maquettes et bouchons au fur et à
mesure
* Contamination par couche : On remplace les
maquettes et bouchons couche par couche
Types de tests
 Tests de Recette : On teste l'application
comme l'utilisateur
- Les spécifications du logiciel ont du aussi spécifier les tests
de recette
– Que doit faire le logiciel dans les cas de données conformes
– Que doit faire le logiciel dans les cas de données non
conformes
– Quelles sont les performances attendues du logiciel Ou, plus
exactement, est-ce que le logiciel va avoir les
performances que le client attend ===>Tests de
performances
Types de tests
 Tests de performances
● Temps de réponse
● Nombre d'utilisateurs simultanés
● Nombre de transactions par seconde
● Nombre d'accès aux bases de données par seconde
Plusieurs techniques
– La pire : l'épreuve du feu :Mettre le site en ligne et attendre
–  Catastrophe probable !
– Incomplète mais utilisée : Mettre le site en ligne pour un
petit nombre d'utilisateurs avertis, ensuite extrapoler les
mesures
– La meilleure : Simulation de charge : On programme des
processus pour réaliser des requêtes réalistes sur le
serveur
Types de tests
 Test de régression:
Test visant à détecter les erreurs introduites
après chaque changement apporté dans les
programmes d'un système
Outils logiciels de tests
- CLIF framework java dédié aux tests de performance pour tout type de
système accessible depuis une JVM
- TAO, PathCrawler, GATel, FAUST, Junit, SIMPROC, Conformiq, …
- OpenSTA solution d’injection de charge HTTP/HTTPS qui permet de tester
les performances d’une application Web développée en J2EE, .NET,
PHP, etc.
 Le modèle en V
A/s des Jeux de tests
 Exemple 1. Si le jeu de test est généré au hasard pour le
programme ci-dessous :
– Read(x); Read(y);
– If x = y then z:=2; /* erreur: on voulait z:=22 */
– Else z:=0
– End if
 Peu de chance de tomber au hasard sur un cas qui vérifie la

condition x=y et qui permette de révéler une défaillance (et
donc l’erreur)
A/s des Jeux de tests
 « Sélectionner un jeu de test T tel que lorsqu’on exécute P sur
les d ∈ T, chaque instruction de P est exécutée au moins une
fois. »
Exemple:
Trouver un jeu de test qui permet de
Algorithme d’Euclide
couvrir toutes les instructions du
begin
programme.
read(x); read(y)
•Pour constituer les jeux de test, on va
while x <> y do
tenter de grouper dans des classes Di
If x>y then x:= x-y;
les éléments du domaine d’entrée D
else y:= y-x;
qui activent les mêmes instructions
end if
dans P:
end while
D1={(x,y) | x>y}; D2={(x,y) | x<y};
pgcd := x;
D3={(x,y) | x=y}
End.
•Jeu de test: {(4,2), (2,4), (3,3)}
Autour du management de projet
Extraits du site : http://www.projetsinformatiques.com/
 Qu'est ce qu'un projet ?

Une opération ponctuelle ayant un début et une fin,
nécessitant la mise en oeuvre de moyens matériels et
humains dans un délai donné et pour un coût déterminé.
 La finalité de tout projet informatique est de répondre à

un besoin exprimé par les clients. Le "besoin" tient donc une
place primordiale au sein du projet.
 La réussite du projet, c’est bien de couvrir le bon besoin,

et de fournir ce service aux bonnes personnes, au bon
moment.
 Que faut-il faire pour réussir un projet informatique ?

Une conjonction de plusieurs actions conjuguées ensemble.
• Respecter les rôles maîtrise d'ouvrage / maîtrise d'œuvre

• Rester réaliste et pragmatique
• Clarifier les responsabilités de chacun
• S'impliquer dans le projet
• Réfléchir aux fonctionnalités, et savoir les expliquer
• Disposer d'une maîtrise d'œuvre compétente
• Faire les bons choix technologiques
• Faire de vrais tests
• Accompagner les utilisateurs
• Penser au futur , …
24/03/2020
Pr F. Bouarab-Dahmani 54
 Le chiffrage d’un projet informatique

N'est que la détermination d'une charge et d'un coût. Cette
information doit être intégrée dans une réponse plus large
qui indique le mode de lecture (hypothèses retenues pour le
chiffrage, ...).
 En termes de gestion de projet, le triptyque « coût / délai /
qualité » est sans équivoque : le projet n’est une réussite que si ces
trois points sont respectés. Autrement dit, si le projet est livré dans
les temps (délai), dans le budget financier défini initialement (coût),
et avec toutes les fonctionnalités spécifiées initialement, et
fonctionnant bien (qualité).
 Projet en cycle en V ou projet agile, le chiffrage général n’est pas
identique
 S’il s’agit d’un projet agile, le chiffrage complet est

difficile à évaluer; le projet doit être réalisé par morceaux
(sprint dans le cas de la méthode SCRUM), et il est difficile
d’évaluer le coût de chaque morceau puisque par définition
de l’agilité, les détails ne sont pas connus d’avance.
 La difficulté est que si le client n’a pas une grande maîtrise

du concept de l’agilité, et il demande à son fournisseur un
engagement ferme de chiffrage en mode agile de l’ensemble
du projet avant le début du projet.
 Pour la conduite de projet informatique avec la méthode agile

SCRUM par exemple, on peut faire le chiffrage par SPRINT
 But de l'exercice du chiffrage

Est de fournir la charge en jours homme prévue pour
réaliser le projet. Il « suffit » de chiffrer une prestation
informatique, c'est-à-dire annoncer le coût financier de
réalisation d’un projet informatique. Ce coût doit être
complet, sans surprise. Il intègrera toutes les « charges »
nécessaires pour le réaliser.
 On appelle « charge », le nombre de jours de travail

nécessaires pour le réaliser. On parle alors de « jours
homme », autrement dit, le nombre de jours qu’il faudrait
pour un homme pour le réaliser (exemple : un projet de
100 j-h).
24/03/2020
Pr F. Bouarab-Dahmani 57
 Taux Journalier Moyen (TJM)

Plusieurs personnes travaillent sur le projet : chef de projet,
concepteur, architecture, développeur, etc. Chaque profil a
un TJM différent : au niveau salaire, le chef de projet de 20
ans d’expérience n’a pas le même coût par jour qu’un
développeur débutant. Les TJM peuvent aller de 350 euros /
jour, à plus de 1500 euros / jour pour des experts.
 le planning est une autre opération à faire en corrélation

avec le chiffrage (pour rester cohérent avec les chiffres) mais
qui répond à une autre question « quand ? » alors que le
chiffrage répond plutôt à la question « combien ? ».
(1 pers en 1 mois mais 5 pers en 10 jours.)
 Le but de l’exercice est donc de déterminer le nombre

de jours qui sera travaillé par chacun de ces profils
pour réaliser le projet, sans oublier les éventuels coûts
complémentaires aux charges humaines, tels que les
coûts en matériel et en licences.
La 2ieme Partie du cours
Assurance et Contrôle Qualité du Logiciel
I-La qualité en génie logiciel ?
I-1-Définitions
 Selon l'IEEE : La qualité logicielle est :
(1) Le degré avec lequel un système, un composant ou un processus
satisfait à ses exigences spécifiées.
(2) Le degré avec lequel un système, un composant ou un processus
satisfait aux besoins ou attentes de ses clients/usagers.
 En Génie Logiciel : La qualité d’un logiciel est son aptitude à

satisfaire les besoins (exprimés ou potentiels) des utilisateurs. La
mesure de la qualité dépend des caractéristiques du logiciel
réalisé, des besoins des utilisateurs et des normes et paramètres
de mesure de la qualité utilisés comme références
I-La qualité en génie logiciel
 Sens le plus commun de la qualité d’un logiciel
–absence de bugs,
–bas ratio de défauts (nb-défauts/unité de taille),
–haute fiabilité (nb-pannes par nb-heures d'opération),
- temps Moyen entre Pannes,
- probabilité d'opération sans panne dans un temps
spécifié
- Répond au besoins des utilisateurs finaux!
I-2- Besoins des utilisateurs
 Fonctions à réaliser : Calcul de paie, commande

d’avion, comptabilité générale, ...
 Caractéristiques d’utilisation : Exploitation,

Evolutions, Environnement d’exécution, ...
 L’analyse des besoins fait sortir les exigences
 Une exigence est une description d’une capacité

du logiciel (un service offert ) ou d’une contrainte
(sous laquelle il doit opérer ou doit être développé)
I-2- Les caractéristiques d’un logiciel
Diffèrent selon qu’il s’agit :

 d’un logiciel (prototype) jetable
 d’un logiciel dont la durée de vie est de
plusieurs années
 d’un logiciel dont les pannes ont une
importance relative
 d’un logiciel dont la moindre erreur peut
avoir des conséquences graves
I-3- Conditions de réalisation d’un logiciel
de qualité
Le processus de réalisation d’un logiciel doit obéir aux

conditions suivantes:
 Ne pas faire seulement un contrôle de qualité en fin

de processus
 Assurer une production échelonnée de documentation
 Prendre en compte les coûts de maintenance
I-4- Caractérisation de la qualité d’un logiciel
Barry. W. Boehm a proposé au milieu des années 70
qu’un logiciel doit être:
 Utilisable en l’Etat
 Maintenable
 Portable
I-4- Caractérisation de la qualité d’un logiciel
J. McCall de la General Electric, a introduit ensuite (1978)

deux éléments:
 Une typologie de facteurs de qualité selon différents

points de vue
 Des niveaux d’expression de la qualité allant du

quantitatif au qualitatif
D’où les trois niveaux de description de la qualité suivant :
Niveaux de description de la qualité selon McCall
 Les facteurs qui sont relatifs à un besoin

 Les critères sont les caractéristiques du logiciel associés aux
facteurs
 Les métriques sont des variables permettant de mesurer
l’atteinte d’un critère
Qualité
Facteur
Facteur1 …
n
Critère 1 Critère k1
Facteurs de qualité d’un logiciel
 Fonctionnels
 Pertinence : capacité de répondre au pb posé par l’utilisateur
 Adéquation: du logiciel à l’organisation et procédures de
l’utilisateur
 Généralité : capacité de généralisation à un contexte
 D’utilisation : liés à l’environnement d’exploitation

 Confidentialité
 Couplabilité
 Efficience
 Maniabilité
 Fiabilité
Facteurs de qualité d’un logiciel
 De Maintenance
(liés à l’environnement de maintenance et de suivi)
 Maintenabilité
 Adaptabilité ,
 Portabilité
 Economique : liés au processus de développement

 Efficacité
Critères par Facteur de qualité
 Maniabilité : communicabilité, exploitation, facilité

d’apprentissage
 Fiabilité : complexité, tolérance aux fautes, auditabilité
 Efficience : consommation en place mémoire, tailles des
périphériques et leurs vitesses d’accès, temps d’execution des
programmes
 Confidentialité : protection des codes et des données,
mémorisation des accès
 Couplabilité : standardisation des données, standardisation
des interfaces
 Maintenabilité : la lisibilité, modularité, traçabilité,
adaptabilité
 Portabilité : banalité d’emploi, indépendance, qualité de la
documentation
Critères de qualité d’un logiciel
 Banalité d’emploi: indépendance par rapport à une application

 Communicabilité: facilité de communication entre l ’homme et la
machine
 Efficacité mémoire: consommation minimale de l ’espace mémoire
 Efficacité périphérique: vitesse et capacité optimale des périphériques
 Efficacité en temps d’exécution: consommation minimale en temps
machine
 Expansibilité : possibilité d ’accroissement des zones de données et de
la taille programme
 Exploitabilité: facilité de mise en œuvre et d ’exploitation
Critères (suite)
 Historique des accès : mémorisation des accès

 Indép./ env. logiciel : absence de liens structurels avec E.L.
 Indép. / env. matériel : absence de liens structurels avec
E.M.
 Lisibilité : possibilité de compréhension d ’un document ou
d ’un code par simple lecture
 Modularité : décomposition d’un logiciel en éléments de
taille réduite
 Observabilité : facilité de localisation des non conformités
 Précision : exactitude des résultats obtenus
Critères (suite)
 Protection du code et des données en

exploitation: protection contre les accès par des
personnes non autorisées, le logiciel étant en
exploitation
 Protection du code et des données hors
exploitation: protection contre des accès par des
personnes non autorisées, le logiciel étant hors
exploitation
 Simplicité: facilité de compréhension liée à
l ’absence d ’éléments superflus
Critères (suite)
 Standardisation des données : compatibilité
des données avec des standards externes
 Standardisation des interfaces: compatibilité
des interfaces avec des standards externes
 Tolérance aux fautes: possibilité de limiter ou
supprimer les effets d ’une perturbation, que
celle-ci ait une cause interne ou externe au
logiciel
 Traçabilité: existence de liens entre les
différentes représentations textuelles ou
graphiques
I-9- Les Métriques
De la théorie de la Mesure : Eléments de mesure
De la théorie de la Mesure : Métriques techniques
De la théorie de la Mesure : Autres Métriques
Exemples de Métriques
- une méthode de calcul : ex : calcul de la complexité
– une valeur optimale : Taux de couverture de tests,

proportion de commentaires par rapport aux lignes de
code
– un intervalle dont il ne faut pas sortir : intervalle de

tolérance d’erreurs
-…
Différentes métriques sont proposées pour certains

critères (ou des fois appelé facteur si la référence n’est
pas la proposition de McCALL). Voici quelques exemples.
Mesure de la complexité
Complexité cyclomatique de McCabe
Pour un graphe de flot de contrôle F, comportant

n nœuds (dont d nœuds prédicats) et e arcs,
Il existe trois façons de la mesurer :
• V(F) = e – n + 2
• V(F) = 1 + d
• V(F) = r (r est le nombre de régions de F)
Exemple de Mesure de la complexité
Exemple de mesure de complexité
La qualité dans la conduite de projet
Conduite de Projet
Développement Planification Assurance Gestion Gestion

de SI et Suivi & Contrôle de la de la
Qualité configuration documentation
Assurance & Contrôle Qualité
 Assurance Qualité: Mise en œuvre d’une

approche préventive de la qualité.
L’AQ consiste en un ensemble d’actions de prévention
des défauts qui accompagnent le processus de dvt des
logiciels.
 Contrôle Qualité: Mise en œuvre d’une approche

curative de la qualité.
Le CQ suppose que bien que le processus de production
est satisfaisant, il présente des dysfonctionnements
dont les effets doivent être éliminés.
Activité d’assurance qualité : Définition
 Ensemble des actions préétablies et systématiques

nécessaires pour donner la confiance appropriée
en ce qu’un produit ou un service satisfera aux
exigences données relatives à la qualité
 Passe par l’élaboration d’un MANUEL QUALITE

(Ensemble des méthodes, règles et procédures
mises en œuvre pour développer du logiciel )
Assurance Qualité :
Liens entre les différentes activités
Assurance Normes, Procédures,

Qualité Métrologie
Production Produit fini

Technologies logiciel
Production
Gestion
Maintenance Contrôle
Qualité Vérifie, Mesure, Corrige
Assurance Qualité : Manuel Qualité
 Le manuel qualité est un document décrivant les

dispositions générales prises par l’entreprise pour
obtenir la qualité de ses produits ou services
 Organisé en 6 parties:
 Organisation de l’entreprise
 Activités de production et de contrôle technique
 Activité de gestion
 Activité de contrôle de la qualité
 Plan type du PLAN QUALITE
 Lignes directrices permettant d’établir le plan
qualité
Assurance Qualité : Rôle du Manuel Qualité
Usage interne et externe
Maîtrisé par tous Démonstration
Formation : technique, méthode et outils
Assurance Qualité : Plan Qualité
Plan Qualité: Document décrivant les

dispositions spécifiques prises par
l’entreprise
Assurance Qualité : Plan type du Plan Qualité
1) But, Domaine d’application et responsabilité:

Portée du plan qualité et dispositions pour en
assurer son application
2) Documents applicables et documents de

références:
Documents appelés dans le plan qualité
3) Terminologie

14) Organisation:
Personnes intervenant dans le projet

 Pour chaque personne: sa place dans la
structure de l’entreprise, son rôle et ses
responsabilités dans le projet
 Liens hiérarchiques et fonctionnels entre les
intervenants
Assurance Qualité :Plan type du Plan Qualité
5) Démarche de développement
 Liste des phases de développement
 Pour chaque phase:
 contenu de ses activités,
 ses documents ou ses produits en entrée,
 documents ou produits qu’elle réalise,
 conditions de passage à la phase suivante et
points clés
6) Documentation
 Liste des documents produits dans chaque phase
 Références aux plans types de chaque document
 Son statut: livrable, consultable, privée
 Documents classés en:

 documents de gestion de projet
 documents techniques de réalisation
 manuels d’utilisation et d’exploitation
7) Gestion des configurations

Éléments de configuration y compris les moyens de
développement et de tests
8) Gestion des modifications

 le responsable de leur mise en œuvre
 les règles d’évolution de l’identification des
éléments modifiés et de la nomenclature
9) Méthodes, outils et règles

10) Contrôle des fournisseurs
11) Reproduction, protection, livraison
12) Suivi de l’application du plan qualité (plan de
contrôle): Dispositions prises pour maîtriser la qualité
 Interventions du responsable qualité sur la démarche de
développement
 Interventions du responsable qualité dans les procédures
de gestion des configurations, de gestion des modifications,
la vérification des exigences de qualité envers les
fournisseurs
 modalités de recette et qualification
Assurance Qualité : Synthèse
 Le plan qualité doit déterminer les

caractéristiques de qualité les plus significatives
pour le produit en projet
+
respect des normes et standards (comme
références de qualité) s’il en existe.
 L’AQ est un outil de clarification de la relation

client/fournisseur pour avoir un échange de bon
procédés où le fournisseur conseille le client.
Assurance Qualité : Synthèse
 Pour tout produit avec chaîne de fabrication :

Qualité du processus de fabrication  Qualité du produit
POUR LES LOGICIELS : NON !!

Car le processus de développement n’est pas encore
maitrisé.
CEPENDANT LA QUALITE DU PROCESSUS FAIT PARTIE
DE L’AQL.
 Le plan qualité Est Inclus dans le plan de management

du projet. Il ne contient que ce qui est propre au projet.
Assurance Qualité & le V&V
 L’AQ est étroitement liée aux activités de vérification et

validation mise en place à chaque étape du cycle de vie
d’un logiciel
MAIS
l’AQ est une ACTIVITE DE GESTION alors que le V&V est
une ACTIVITÉ TECHNIQUE du développement du
logiciel
EN PLUS : Equipe d’AQ <> Equipe du projet logiciel
 Le V&V consiste à détecter des fautes de l’étape en

question  Vérifier la FIABILITE de l’étape
ALORS QUE
L’AQ est plus vaste puisqu’elle se soucie des autres
facteurs de qualité comme la portabilité, la
maintenabilité, …

Assurance Qualité & le V&V
 Par conséquent, nous avons en GL deux types de

métriques :
o METRIQUE DE CONTRÖLE : utilisées par l’équipe du

projet en V&V
o METRIQUE PREDICTIVES : utilisées par l’équipe d’AQ

pour mesurer un critère de
qualité

Activité de Contrôle de qualité
 D’un environnement concurrentiel nait la nécessité

d'être certifié, le besoin de traçabilité des produits
pour produire mieux, toutes ces raisons rendent
l'objectif ZERO DEFAUT indispensable pour fidéliser et
sécuriser ses clients, et conquérir de nouveaux
marchés.
 Fait partie de l’assurance qualité. Il s’applique au

produit élaboré à chaque étape du projet.
 Deux éléments à contrôler :

o la documentation,
o et le logiciel

Contrôle de la Documentation
 Vérifier les critères de qualité relatives

 à la FORME (redondances, mise en forme, …)
 et au FOND (ambigüité, contradiction, silence).
 Le plan type prévoit différents types de contrôles :
o Inspection: faire lire le document par autrui
o Lectures croisées: ex.entre resp.de s/projets

Contrôle de la Documentation
o La revue : évaluation collective d’un document (pour

l’améliorer)
 Chaque revue à :
- présentateur : auteur du doc (ou chef de projet)
- coordinateur : organisateur de la revue,
responsable qualité
- rapporteur : chargé du compte rendu de la
revue (resp Q)
- lecteur(s) : lecture critique du doc
 Chaque revue se termine par un compte rendu où

sont notés les pbs soulevés, les décisions prises et
le calendrier de prise en compte des décisions
Contrôle du Logiciel (ctle des pgrammes)
 Dresser un plan des tests : Calendrier et

modalités de préparation et exécution des tests sur
tous les programmes réalisés durant l’étape testée.
 Types de tests
o Tests unitaires (white or black box)
o Tests fonctionnels (black box avec utilisation
éventuelle de « doublures »)
o Tests d’intégration
o Tests de performance et de recettes quand on
teste le produit fini

Audit de qualité et Certification
 L’audit qualité de projet est un moyen

d’évaluer la qualité du processus de
développement.
 En systèmes d’information, l’audit qualité porte
sur le respect des dispositions du plan
assurance
 Autres audit : internes à la demande du chef
de projet et externes à la demande d’un tiers
(tutelle, client, …)
 Certains audits sont fait lors d’une procédure
de certification relativement à des normes de
qualité comme ISO 9000 par exemple.

Audit de qualité et Certification
 Une certification est attribuée à une entreprise

donnée au terme d’un audit de qualité de
l’entreprise qui consiste (selon l’AFNOR,
organisme de normalisation Français) en
« un examen méthodique et indépendant en

vue de déterminer si les activités et les
résultats relatifs à la qualité satisfont aux
dispositions préétablies et si ces dispositions
sont mises en œuvre de façon efficace et
aptes à atteindre les objectifs »

Normes générales de qualité
- Normes ISO et standards
- Evaluation maturité des processus: CMM,

SPICE, … :
• ne prescrivent pas des méthodes précises
• proposent un ensemble d‘activités requises pour
produire des biens de qualité
• l’organisation détermine comment implanter l’activité

Référentiels de Qualité en Génie Logiciel
 Un référentiel
 est un ensemble d’éléments auxquels on se
compare; il répond à un besoin de
standardisation autour d’un vocabulaire
commun. Il peut s’agir de standards ou de
normes encore appelées standard de jure
 Une norme est un document de référence,

obtenu par consensus et approuvé par un
organisme de normalisation local, régional ou
international (via l’ISO)
 Les organismes de normalisation sont présents au niveau de

chaque pays comme : IANOR Institut Algérien de
Normalisation, AFNOR en France (norme NF), … Au niveau
régional comme le Comité Européen de Normalisation (norme
CEN) et au niveau international avec la norme ISO
 Les normes donnent des spécifications techniques ou autres
critères précis destinés à: être utilisés systématiquement en
tant que règles, lignes directrices ou définitions de
caractéristiques.
 Par exemple, le format des cartes de crédit que l'on retrouve
partout est dérivé d'une Norme internationale ISO. Le fait
d'adhérer à la norme qui définit des caractéristiques telles que
l'épaisseur optimale (0,76 mm) signifie que les cartes pourront
être utilisées dans le monde entier.

 Les Normes internationales contribuent
 à nous simplifier la vie et à accroître la fiabilité et l'efficacité des

biens et services que nous utilisons.
 À favoriser l’internationalisation de la commercialisation de biens
et services.
 Fin 2006, près de 16 000 normes actives étaient recensées par

l’ISO. Beaucoup sont intégrées à la vie courante comme la
norme relative aux formats de papier (ISO 216).
 En informatique, citons l’ISO 9660 pour le système de fichiers

sur CD-ROM, l’ISO 9899 pour le langage C ou encore le modèle
OSI en 7 couches (ISO 7498).

 Les Standards
 Référentiels destinés à créer rapidement des spécifications
communes en réponse à la lenteur des processus de
normalisation. Ce sont des standards publiés par des
organisations privés ou des consortiums .
 Un consortium (du latin signifiant «partenariat» ou

«association») est une collaboration temporaire entre
plusieurs acteurs à un projet ou programme dans le but
d'obtenir un résultat.
 Les consortiums sont très présents en informatique
comme l’ISOC (Internet Society) qui gère les orientations
générales de l’Internet et le W3C ou le consortium de
développement Open Source OW2

 ISO ET NORMES ISO

 L'ISO (L’International Organization for Standardization) est
une organisation non gouvernementale, créée en 1947.
L'organisation internationale de normalisation (ISO) est
une fédération mondiale d'organismes nationaux de
normalisation de quelques 130 pays, à raison d'un
organisme par pays.
 Le fonctionnement de l'ISO est basé sur une approche

démocratique : 1 membre = 1 vote, tous les pays sont
placés sur un pied d'égalité. De 12 à 15 réunions d'organes
techniques d'ISO ont lieu quotidiennement dans le monde.
Ces organes sont presque au nombre de 3000 avec près de
30000 experts

 Les Normes ISO et l’Assurance Qualité de logiciel
 Selon la définition de l'ISO : la qualité est l'aptitude

d'un produit ou d'un service à satisfaire les exigences
spécifiées.
 Deux volets interviennent dans l'assurance qualité :

- le produit fabriqué.
- l'organisation et le management.

 Les Normes ISO et l’Assurance Qualité de logiciel
 L'assurance qualité permet de garantir au

client que ses exigences sont respectées à
tous les stades de la fabrication du produit.
 Elle permet également de s'assurer que

l'organisation de l'entreprise est conforme à
une politique qualité clairement définie.

 ISO 9000 : Ensemble de normes de

gestion de la qualité
 Applicable à plusieurs domaines (manufacturier,

service,...)
 satisfaire la norme ISO 9000 démontre la capacité
d’une organisation à produire des biens et services
 certification par un organisme indépendant (ex:
Underwriter Lab.)

Les Normes ISO 9000
 Principe : « Dîtes ce que vous faîtes,

faîtes ce que vous dites, et montrez
que vous l’avez fait »
 Norme ISO 9000 constitue un document

décrivant les lignes directrices pour la
sélection et l’utilisations des normes

Normes ISO 9000
 Normes Composantes
 ISO 9001 fournit un modèle pour l’assurance
qualité dans le cadre de la conception, de la
réalisation, de l’installation et du service après
vente.
 ISO 9002 fournit un modèle pour l’assurance
qualité dans le cadre de la production et de
l’installation.
 Norme ISO 9003 constitue un modèle pour l’AQ
dans le cadre des contrôles et essais finaux.

Normes ISO 9000
 ISO 9004 complète à l’aide de directives
communes à toutes les entreprises, les trois
normes précédentes qui concernent l’assurance
externe de la qualité dans des situations
contractuelles.
 ISO 9001 est la plus pertinente pour le logiciel

 ISO 9000-3: guide d’interprétation de ISO 9001
pour le logiciel
 20 articles dans la norme

Article 1: Responsabilité de la direction
 la direction doit définir et consigner par

écrit sa politique de gestion de la qualité
 la direction doit assurer la compréhension,

la mise en œuvre et la pérennité de la
politique à tous les niveaux de l’organisme

Article 2: Système qualité
 Manuel qualité
 Plans de qualité
 objectifs de la qualité (en termes mesurables)
 critères d’entrée et de sorties de chaque phase
 identification des activités
 planification des activités
 responsabilité (qui fait quoi)

18 autres articles de ISO 9001
3) Revues de contrat
4) Maîtrise de la conception
5) Maîtrise des documents
6) Achats
7) Produit fourni par l’acheteur
8) Identification et traçabilité du produit
9) Maîtrise des processus
10) Contrôles et essais (C&E)
11) Maîtrise des équipements de C&E
18 autres articles de ISO 9001
12) États des contrôles et essais
13) Maîtrise du produit non conforme
14) Actions correctives
15) Manutention, Stockage, Conditionnement et
Livraison
16) Enregistrements relatifs à la qualité
17) Audits internes de la qualité
18) Formation
19) Soutien après vente
20) Techniques statistiques
département informatique UMMTO 3
Normes ISO/IEC 9126
 La qualité des logiciels a fait l’objet d’une longue série
de normes élaborées sous l’égide de l’organisation
internationale pour la normalisation (ISO) depuis le
début des années 1990.
 Certaines normes ont connu plusieurs versions, et

l’ensemble a subi une importante réorganisation sous le
nom de SQuaRE (Software Quality Requirements and
Evaluation) donc (spécification et évaluation de la
qualité des logiciels)
 au début des 2000, toutes les normes prévues n’étant

pas encore achevées
Normes ISO/IEC 9126
 La série de normes ISO/IEC 9126 est ainsi divisée en
cinq groupes :
• le groupe 9126-1n (n = 0, 1) offre une perspective
d’ensemble sur les notions et les processus liés à la
qualité;
• 9126-20 normalise la notion de modèle de qualité;
• 9126-3n (n = 0 à 5) s’intéresse aux métriques de
qualité des logiciels et à leur documentation;
• 9126-40, principale nouveauté de la série, concerne
la spécification des qualités requises;
• 9126-5n (n = 0 à 3) décrit le processus d’évaluation
de divers points de vue, reprenant ainsi le contenu de
la série ISO/IEC 14598-1 à 6 déjà publiée.
Normes ISO/IEC 9126
 L’approche ISO distingue trois types de caractéristiques
de qualité : internes, externes et à l’usage :
• Les qualités internes mesurées sans exécution du
logiciel – évaluations dites « en boîte de verre »
• les qualités externes mesurées en faisant fonctionner le

logiciel – évaluations dites « en boîte noire » où l’on
s’intéresse aux résultats produits.
• la qualité à l’usage mesurée en plaçant le système dans

un contexte d’utilisation, expérimental ou final, et en
observant dans quelle mesure le système aide ses
utilisateurs à accomplir leurs tâches.

Normes ISO/IEC 9126
 Les caractéristiques de qualité internes influencent
naturellement sur les caractéristiques de qualité
externes, mais cette influence est souvent difficile à
représenter.
 Les caractéristiques de qualité internes et externes d’un

système qui peuvent être vu comme le modèle ISO de
qualité sont regroupées en six catégories :

Normes ISO/IEC 9126
• 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
• Fiabilité (Reliability)
• Facilité d'utilisation (Usability)
• Rendement (Efficiency)
• Maintenabilité (Maintainability)
• Portabilité (Portability)

Normes ISO/IEC 9126
 Ces catégories peuvent elles-mêmes se subdiviser
en sous-catégories en fonction du type de
système évalué et de sa tâche.
 Dans cette hiérarchie, les éléments dont on peut
mesurer directement la qualité sont les
subdivisions terminales, appelées attributs.
 Pour chaque attribut on utilise une métrique qui
assigne à cet attribut, par le biais d’un processus
de mesure, un niveau de qualité sur une échelle
associée à la métrique.
 Évaluer un système, c’est donc mesurer sa qualité
en utilisant une décomposition fondée dans le
contexte d’utilisation prévu.

Evolution des Normes ISO pour la
Qualité Logiciel
 ISO 25000 est le résultat de l’évolution de
plusieurs autres normes; l’ISO 9126, qui définit un
modèle de qualité pour l’évaluation d’un produit
logiciel, et l’ISO 14598, qui définit le processus
d’évaluation du produit logiciel.
 La série de normes ISO 25000 se divise en cinq

divisions : - Besoin en qualité
- modèle de qualité
- Mangement de la qualité
- mesure de qualité
- Evaluation qualité

Qualité Logiciel : ISO 25010
 Définit , premièrement, un modèle de qualité
d’utilisation composé de cinq caractéristiques
(dont certaines sont subdivisées en sous-
caractéristiques) qui concernent le résultat de
l’interaction du produit quand il est utilisé dans un
contexte particulier. Ce modèle est applicable au
système personne-machine complet, y compris les
systèmes informatiques et les logiciels.
 Deuxièmement, elle définit un modèle de qualité
du produit composé de huit caractéristiques (qui
sont subdivisées en sous-caractéristiques) qui
concernent les propriétés statiques de logiciels et
les propriétés dynamiques du système.

Qualité Logiciel



Qualité Logiciel : ISO 29119-2

La Série de modèle de maturité
CMMI
 Proposé par le Software Engineering Institute
 Financé par le DoD, associé à l’Université
Carnegie Mellon
 Sa mission est de promouvoir le transfert de
technologie en matière de logiciel,
particulièrement pour les entreprises travaillant
pour le DoD
 Le modèle de maturité proposé fin des années
1980, raffiné en 1993
 Grande influence dans l’amélioration des
processus

Le Modèle de Maturité (CMM) du SEI
 Initial  ~75% des projets au

niveau 1
 Reproductible  ~25% des projets au
niveau 2 ou 3
 Défini
 Maîtrisé Dans une étude menée en
 Optimisé 1995:
 seulement 2 projets ont
atteint le niveau 5:
 projet de Motorola
 projet Loral (le vol habité de
la navette spatiale)

Niveaux de maturité -1-Initial
Chaotique: plans et contrôles inefficaces

 Processus essentiellement non contrôlé,
non défini
 le succès dépend des individus
 Domaine du problème:
 Gestion de projet
 Gestion de la configuration
 Assurance qualité du logiciel

Niveaux de maturité-2- Reproductible-Répétable
Intuitif: dépend encore des individus

 Procédures de gestion utilisées, gestion des
configurations et assurance qualité
 Pas de modèle formel de processus
 Perfectionnement
 Pratiques techniques
 Vise la définition formelle du processus

Niveaux de maturité -3 : Défini
Qualitatif: institutionnalisé
 Définition formelle du processus

 Procédures formelles pour vérifier que le
processus est utilisé
 Procédures de mesure
 Processus d’analyse
 Plans de qualité quantitatif

Niveaux de maturité-4 Maîtrisé
Quantitatif : Processus de mesures
 Gestion quantitative de la qualité
 Domaine du problème:
 Technologie changeante
 Analyse des problèmes
 Prévention des problèmes

Niveaux de maturité 5:Optimisé
Améliorations retournées dans le processus
 Stratégies d’amélioration du processus
 Domaine du problème
 Automatisation

Secteurs clés
 Niveau 1: Aucun
 Niveau 2: Répétable
 Gestion de la spécification et des changements
 Planification, suivi et contrôle de projet
 Gestion de la sous-traitance
 Assurance de la qualité
 Gestion des configurations

Secteurs clés
 Niveau 3- Défini
 focalisation organisationnelle sur le processus
 définition du processus
 programme de formation
 gestion logicielle intégrée
 ingénierie de produits logiciels
 coordination inter-groupes: autres groupes
d’ingénierie (électrique, mécanique,...)
 revues par les pairs

Secteurs clés
 Niveau 4: Maîtrisé
 Gestion quantitative du processus
 Gestion de la qualité logicielle
 Niveau 5 - Optimisé
 Prévention des défauts
 Gestion des changements technologiques
 Gestion des changements du processus

NORMES POUR SI - ISO_SPICE
L'ISO/SPICE (ISO 15504)
 SPICE : Software Process Improvement and

Capability Determination.
 Le référentiel ISO/SPICE pour le management

des processus d'ingénierie logiciel et de la
qualité de ces processus. Cette méthode pose
le principe que la qualité des produits logiciels
est une conséquence de la qualité des
processus de réalisation de ces mêmes
logiciels.

NORMES POUR SI - ISO_SPICE
L'ISO/SPICE (ISO 15504)
 Mais l'utilisation principale de ce référentiel est

d'établir une méthode d'évaluation pour les
démarches de progrès. Le référentiel ISO 15504
conduit au modèle de maturité avec les niveaux
associés (initial, reproductible, défini, maîtrisé et
optimisé).
 SPICE : Software Process Improvement and

Capability Determination.

Sécurité des logiciels
 Sécurité des logiciels: Protection des

ressources d’un système informatique
contre les événements à caractère
accidentel ou intentionnel
 Modification ou destruction des ressources
 Observation (non autorisée) des ressources

 Indisponibilité des ressources ou services
Traitements induits
 Contrôle d’accès
 Contrôles de validité, cohérence de
l’information saisie
 Redondances
 Audits d’intégrité
 Pistes d’audits
 Alertes sur seuils
 Cryptage

Gestion des configurations : DEFINITION
 On appelle « configuration », l’ensemble

des caractéristiques fonctionnelles et
physique du matériel et du logiciel telles que
décrites dans la documentation technique
et obtenues pour le produit concerné
 Ex: le poids, la taille, consommation
d’énergie, le niveau de qualité, le degré de
fiabilité, etc.

Gestion des configurations:Définition
 Gestion de la configuration
Ensemble de processus techniques et administratifs visant

 à identifier,
 documenter,
 contrôler,
 communiquer
 et valider les caractéristiques fonctionnelles et
techniques d’un produit tout au long de son cycle de
vie.

Gestion des configurations:Définition
 L’objectif est de s’assurer que le produit

rencontre les exigences (3F: fit, form, function)
attendues tout au long de son cycle de
développement :
 Fit : taille, caractéristiques de montage, etc.

 Form : caractéristiques physiques du produit
 Function : opérations exécutées par le produit

Gestion des configurations :Tâches
 Spécification de configuration : La tâche

d’identification des configurations consiste à
identifier chacune des parties d’un système et
d’en définir les caractéristiques complètes
 qui devront être obtenues en développement et

en production,
 puis tenues à jour au fur et à mesure de leurs

évolutions tout au long de leur cycle de vie

Gestion des configurations :Tâches
 Gestion de la configuration : À certains moments

du cycle de vie d’un système, les caractéristiques
représentées par les spécifications d’exigences
doivent être approuvées
 et deviennent alors des références.
 Le but de ces références est de ne permettre des

modifications de spécifications que par rapport à
ces références et selon une procédure précise.

Gestion des configurations : Tâches
 Audit de configuration : Il faut s’assurer en fin de

développement que les produits et la documentation ont,
lors des tests et essais de qualification, bien été déclarés
conformes aux références complétées des modifications
approuvées
 Suivi de configuration : Les évolutions des spécifications et
des produits correspondants doivent être suivies et «
comptabilisées » soigneusement. On peut en effet se
trouver face à plusieurs versions d’un même produit en
même temps et devoir, par exemple, faire des remises à
niveau, ce qui nécessite de connaître à tout moment
l’historique des diverses configurations.

BIBLIOGRAPHIE

Constitution d’équipe de développement
logiciel

Ethique en génie logiciel


Présentation Cours ACQL

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Présentation Cours ACQL

Transféré par

Droits d'auteur :

Formats disponibles

Assurance et Contrôle Qualité du

 Approche de développement de logiciel Agile

 La crise du logiciel et nécessité de gestion de la

 Une situation problème authentique

 Produit unique: conçu et fabriqué une seule fois

 Le coût du développement du logiciel dépasse souvent

 Non respect du cahier des charges,

 QUALITE du logiciel doit faire partie du Génie logiciel

 « Si vous trouvez que l'éducation coûte

 La qualité logicielle est une notion difficile à caractériser

 un message d'erreur signalant un plantage ou un

 Le bug d'Ariane 5 : La portion de code à l'origine du déboire avait

 Le bug de la sécurité sociale : Un bug informatique faussant les

 Ensemble des activités de conception et de mise en

 Procédures, méthodes, langages, ateliers, imposés ou

 Les principes et techniques de GL s’appliquent mieux aux

Le génie logiciel = outils + méthodes

Pour la conception et la programmation de logiciels

 Analyse et spécification(du problème)

 Conception (du logiciel)

 Implantation : Codage (programmation)

L’organisation de ces activités et leur enchaînement définit le cycle de

 Deux types de cycle de vie

 Intérêt d’un cycle de vie

- Cycle de vie et assurance qualité sont fortement liés

- S’ assurer en permanence en cours de développement par :

* validation : sommes nous en train de faire le bon produit ?

* vérification : est ce que nous faisons le produit correctement?

24/03/2020 Pr F. Bouarab-Dahmani département informatique UMMTO 17

 Définition des Objectifs

 Le management étudie la stratégie et décide de la nécessité de

 C'est pendant cette phase qu'est défini un schéma directeur

 Définition des Besoins

 Codage et tests unitaires

 A l'issue de cette phase les produits intermédiaires sont

- les modules codés et testés

- la documentation de chaque module

- les résultats des tests unitaires.

- le planning mis à jour

 Chaque module testé est intégré avec les autres suivant le

 A l'issue de cette phase, les produits intermédiaires sont :

 La durée d'un cycle de vie est très variable d'un projet à

 Facteurs d'instabilité : Le modèle de cycle de vie ne

 Un cycle de vie apporte stabilité, contrôle et organisation à

 estimation des coûts et besoins„

Le choix du type de cycle dépend de l’approche

 Modèle en spirale (de Bohem)

 Le développement reprend les différentes étapes du

 la troisième et dernière grande phase (codage) se fait

 Rapportée à une activité de type gestion de projet,

 Sachant que chaque itération ne dépasse jamais

Ce qui est vérifié Cible Avantage Inconvénient

Prototyper La bonne Développ Intervient Aucune

 Doit produire les mêmes résultats lorsque répété avec

 Doit être exact et précis. Une spécification formelle peut

 Peut parfois contribuer à identifier la localisation précise

 Tests en boîtes blanches :Faits Par le développeur

 Tests en boîtes noires : Réalisés par quelqu'un de différent du

- Consiste à remplacer progressivement les bouchons et

 Peu de chance de tomber au hasard sur un cas qui vérifie la

Extraits du site : http://www.projetsinformatiques.com/

 Qu'est ce qu'un projet ?

 La finalité de tout projet informatique est de répondre à

 La réussite du projet, c’est bien de couvrir le bon besoin,