Qualité logiciel - Generalités

Qualité
Logiciel
1
Généralités
@crochefolle
Juin 2009

@crochefolle 2
Présentation
 Qui suis-je ?
 Qualité logiciel
 Plan Qualité
 Gestion Processus de développement
 Gestion des exigences
 Gestion de configuration
 Gestion des tests
 Gestion des anomalies
 Gestion de la documentation

@crochefolle 3
Qui suis-je ?
Porteur d’organisations, méthodes et outils pour
améliorer la qualité des projets et produits, du
recueil des besoin à la mise en production, le tout
avec passion & plaisir depuis 10 ans !
10 ans
5 entreprises < 100 personnes
#editeurLogiciel #startup #testLogiciel #qualité #offshore

@crochefolle 4
Qualité Logiciel : définitions
 Qualité : « l’ensemble des caractéristiques d'une entité qui lui
contèrent l'aptitude à satisfaire des besoins exprimés et implicites »
(source : norme NF EN ISO 9000:2000)
 Entité : tout ce « qui peut être décrit et considérée
individuellement » : produit, processus, organisme ou combinaison
des 3 (source : norme NF EN ISO 9000:2000)
 Qualité du logiciel : « ensemble des traits et caractéristiques d’un
produit logiciel portant sur son aptitude à satisfaire des besoins
exprimés et implicites » (source : norme ISO/CEI 9126:1991)

@crochefolle
Postulats préalables à toute
démarche qualité
1. Définir les exigences qualité :
Les attentes du client/utilisateur en matière de qualité sont
clairement définis. Au-delà des spécifications fonctionnelles, le
cahier des exigences doit prendre en compte les besoins en
termes de caractéristiques de la qualité.
2. Mesurer la qualité :
Les caractéristiques qualité doivent être mesurables pour
permettre de vérifier le niveau de la qualité.
3. Maîtriser les processus :
La qualité du produit peut être maîtriser par la maîtrise du
processus qui le crée, de la conception à la livraison.
5

@crochefolle
Normes
Norme Titre Description
NF EN ISO 9000 Management de la qualité et
assurance qualité - Vocabulaire
Norme généraliste de base
de tout processus qualité
NF ISO/CEI 12207 Processus du cycle de vie du
logiciel
Cadre pour un démarche
projet
Z 67-130 Système de traitement de
l’information – Recommandation
de plan qualité logiciel
Rédaction des plansAFCIQ-PDL Recommandation de plan de
développement logiciel
AFCIQ-PAQL Recommandation de plan
d’assurance qualité logiciel
NF ISO/CEI 9126-1 Technologies de l’information –
Qualité des produits logiciels
Définition caractéristiques
qualité
6

@crochefolle
Norme ISO/CEI 9126-1
 La norme ISO 9126, "Technologies de l’Information : Qualités des produits logiciels", définit et décrit une série de
caractéristiques qualité d’un produit logiciel (caractéristiques internes et externes, caractéristiques à l’utilisation)
qui peuvent être utilisées pour spécifier les exigences fonctionnelles et non fonctionnelles des clients et des
utilisateurs. Chaque caractéristique est détaillée en sous-caractéristique, et pour chacune d’elle, la norme propose
une série de mesures à mettre en place pour évaluer la conformité du produit développé par rapport aux
exigences formulées.
 Caractéristiques
 CAPACITE FONCTIONNELLE
Ensemble d'attributs portant sur l'existence d'un ensemble de fonctions et leurs propriétés données. Les
fonctions sont celles qui satisfont aux besoins exprimés ou implicites.
 FIABILITE
Ensemble d'attributs portant sur l'aptitude du logiciel à maintenir son niveau de service dans des conditions
précises et pendant une période déterminée.
 FACILITE D UTILISATION
Ensemble d'attributs portant sur l'effort nécessaire pour l'utilisation et sur l'évaluation individuelle de cette
utilisation par un ensemble défini ou implicite d'utilisateurs.
 RENDEMENT
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.
 MAINTENABILITE
Ensemble d'attributs portant sur l'effort nécessaire pour faire des modifications données.
 PORTABILITE
Ensemble d'attributs portant sur l'aptitude de logiciel à être transféré d'un environnement à l'autre.
7

@crochefolle
Norme ISO/CEI 9126-1
8

@crochefolle
Norme NF ISO/CEI 12207
Processus du cycle de vie du logiciel
5. Processus de base 6. Processus de support
5.1 Acquisition 6.1 Documentation
5.2 Fourniture 6.2 Gestion de la configuration
5.3
Développement
5.4 Exploitation 6.3 Assurance de la qualité
6.4 Vérification
6.5 Validation
5.5 Maintenance 6.6 Revue Conjointe
6.7 Audit
6.8 Résolution de problème
7. Processus organisationnels
7.1 Management 7.2 Infrastructure
7.3 Amélioration de processus 7.4 Formation
9

@crochefolle
Norme NF ISO/CEI 12207
Processus de support
 Processus de documentation :
1. Mise en œuvre du processus de
gestions des informations produites
2. Conception et développement
3. Production
4. Maintenance
 Processus de gestion de configuration
1. Mise en œuvre du processus
2. Identification de la configuration
3. Maîtrise de la configuration
4. Rapport d’état de la configuration
5. Evaluation de la configuration
6. Gestion de la livraison et de distribution
 Processus d’assurance qualité
2. Assurance du produit
3. Assurance du processus
4. Assurance des systèmes qualité
 Processus de vérification
2. Vérification
 Processus de validation
2. Validation
 Processus de revue conjointe
2. Revues de gestion de projets
3. Revues techniques
 Processus d’audit
2. Audit
 Processus de résolution de problème
2. Résolution de problème
10

@crochefolle
Missions
 Gestion Qualité logiciel
 Gestion du processus de développement
 Gestion de la documentation
11

@crochefolle
Documents de référence de la
démarche qualité
 Gestion Qualité du logiciel
 Plan qualité logiciel
 Gestion du processus de
développement
 Plan développement logiciel
 Planning
 Budget
 Dossier de conception
 Spécification Fonctionnelle
 Spécification Technique
 Cahier des
charges/exigences
 Plan de gestion de
configuration
 Plan de test
 Plan de gestion des
anomalies
 Gestion de la
documentation
 Plan de gestion de la
documentation
12

@crochefolle
PLAN QUALITÉ LOGICIEL
13

@crochefolle
Définition &Objectifs
Plan Qualité
« Document énonçant les modes opératoires, les ressources et la séquence
des activités liées à la qualité, se rapportant à un produit, un service ou un
projet particulier.»
Source : Z 67-801-1:1995
Plan qualité logiciel
« Document décrivant les dispositions spécifiques prises par une entreprise
pour obtenir la qualité du produit ou du service considéré.»
Source : Z 67-130:1987
 Objectifs :
 Lister les plans et procédures nécessaires aux différentes
missions de l’équipe qualité : c’est le point d’entrée de la
démarche qualité
 Recenser l’ensembles des ressources nécessaires : humaines,
matériels et logiciels
 Définir les rôles et responsabilité
14

@crochefolle
Sommaire type
1. Introduction
1. But, domaine d’application du plan
qualité et responsabilité
2. Documents applicables et
documents de référence
3. Terminologie
2. Description du projet
1. Présentation générale du projet,
2. Organigramme fonctionnel et
technique
3. Champ d’intervention
3. Démarche de développement
1. Cycle de développement
2. Processus de développement
4. Moyens et ressources
1. Rôles et responsabilité
2. Matériel
3. Logiciel
5. Planification du projet
1. Techniques d’estimation des
charges
2. Charges prévisionnelles
3. Planning prévisionnel
4. Suivi de projet
6. Description des activités
1. Gestion de documentation
2. Gestion de configuration
3. Gestion des tests
4. Gestion des anomalies
7. Suivi de projet
1. Suivi des adaptations du projet
2. Audit
3. Bilan de projet
4. Proposition d’amélioration
15
Référence : Norme Z 67-130

@crochefolle
PROCESSUS DE
DÉVELOPPEMENT
16

@crochefolle
Introduction
 Cycle de vie logiciel
 Référentiel de bonnes pratiques
 Méthodes de développement
17

@crochefolle
Cycle de vie logiciel
Un logiciel est un ensemble complexe et son
développement nécessite une diversité d’activités. La
modélisation de l’enchainement de ses activités
constitue le cycle de vie du logiciel.
Les différents cycles de vie répertoriés sont les suivant:
 En cascade
 En V
 Par prototypage
 Itératif
 En spirale
18

@crochefolle
Modèle en cascade
Spécification
du logiciel
Conception
préliminaire
Conception
détaillée
Codage
Tests
Unitaires
Intégration
Validation
Exploitation
19
• Dossier Spécifications
• Plan Qualité Logiciel
• Dossier Conception préliminaire
• Dossier Conception détaillée
• Programme de référence
• Produit logiciel
(programme et documentation)
Caractéristiques principales:
• chaque phase se termine par une
vérification pour éliminer le plus possible
d’anomalies
• les retours en arrière sur les phases se
limitent à un retour sur les phase
immédiatement antérieure
Inconvénient :
• Si chaque phase n’est pas maitrisée,
des erreurs en avalanche peuvent
apparaître.
Revue Revue Revue Audit
fonctionnel
et technique
Recette

@crochefolle
Modèle en V
Analyse du
besoin
Spécification
fonctionnelle
Spécification
Technique
Codage
Tests
Unitaires
Test
d’intégration
Test
fonctionnel
Recette
Exploitation
20
Le modèle du cycle en V a été imaginé pour
pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du
modèle en cascade qui permet en cas
d'anomalie, de limiter un retour aux étapes
précédentes. Les phases de la partie
montante, doivent renvoyer de l'information sur
les phases en vis-à-vis lorsque des défauts
sont détectés afin d'améliorer le logiciel.
De plus le cycle en V met en évidence la
nécessité d'anticiper et de préparer dans les
étapes descendantes les « attendus » des
futures étapes montantes : ainsi les attendus
des tests de validation sont définis lors des
spécifications, les attendus des tests unitaires
sont définis lors de la conception, etc.
Le cycle en V est devenu un standard de
l'industrie du développement de logiciel et de
la gestion de projet depuis les années 1980.

@crochefolle
Modèle par prototypage
21
Concevoir
prototype
Implément. Installation Maintenance
prototype prototype
Construire TesterConcevoir
prototype
Concevoir
prototype prototype
Concevoir
prototype prototype
Concevoir
prototype
Tester
prototype
Concevoir
prototype prototype
Tester
prototype
Concevoir
prototype prototype
Tester
prototype
Concevoir
prototype prototype
Tester
prototype
Concevoir
prototype prototype
Tester
prototype
Concevoir
prototype
TesterConcevoir
prototypeBesoins
prototype
Concevoir
prototype
Construire
prototype
Tester
Conception
Spécif.
besoins
Spécif.
besoins
Avantages:
- Éliminer les mésententes avec les utilisateurs en
montrant tôt la fonctionnalité du système.
- Permet d’identifier les besoins manquants.
- Permet d’identifier les problèmes reliés aux interfaces.
- Permet de vérifier la faisabilité et l’utilité du système.
Inconvénients:
- Coût du prototype peut être non apprécié par les
utilisateurs.
- Le prototype peut mettre l’accent sur les interfaces et
négliger la fonctionnalité du système.
- Exige beaucoup l’implication de l’utilisateur.

@crochefolle
Modèle itératif
 Les avantages de cette approche itérative du développement sont :
 Réduction des risques: Permet d’avoir une visibilité de ce qui est achevé à un moment précis du projet.
 Augmentation de la valeur : livrer rapidement à des avantages, être en mesure de livrer le produit quand il
est considéré comme assez bon, plutôt que de devoir attendre tous les éléments destinés à être livrés,
 Plus de souplesse / agilité: on peut choisir de changer de direction ou d'adapter les prochaines itérations
sur la base ce qui a été développé et sur l’utilisation du logiciel.
 Une meilleure gestion des coûts: si, comme tous les trop nombreux projets de développement de
logiciels, vous courez après le budget, une certaine économie peut-être apportée par la méthode Agile.
 Pour cette approche et pour être pratique, chaque fonction/caractéristique doit être pleinement développé,
dans la mesure où elle est doit être livré, avant de passer à la suite.
22

@crochefolle
Modèle en spirale
23
Le modèle en spirale (spiral model)
est un modèle de cycle de
développement logiciel qui reprend
les différentes étapes du cycle en V.
Par l'implémentation de versions
successives, le cycle recommence en
proposant un produit de plus en plus
complet et dur. Le cycle en spirale
met cependant plus l'accent sur la
gestion des risques que le cycle en V.
On distingue quatre phases dans le
déroulement du cycle en spirale :
1. détermination des objectifs, des
alternatives et des contraintes ;
2. analyse des risques, évaluation
des alternatives ;
3. développement et vérification de
la solution retenue ;
4. revue des résultats et vérification
du cycle suivant.

@crochefolle
Référentiel de bonnes pratiques 1/3
A quoi sert un référentiel de bonnes pratiques en
informatique
 A priori, un système d'information en bonne santé
peut fort bien se passer de la mise en place d'un
référentiel de bonnes pratiques. Toutefois, il doit
faire face à de nombreux impératifs :
 satisfaire les utilisateurs,
 faire la preuve de son optimisation
financière,
 rassurer la direction générale sur sa fiabilité
et sa pérennité,
 rassurer les investisseurs sur la sécurité de
leurs investissements,
 savoir s'organiser pour évoluer et s'adapter
en permanence.
 Faire appel aux bonnes pratiques est à la fois un
guide méthodologique efficace et également une
sorte de label que le décideur informatique pourra
mettre en avant pour démontrer qu'il a pris les
meilleures dispositions possibles.
Protéger l'informatique s'impose désormais à la
direction générale : La direction générale a
désormais la responsabilité impérieuse de protéger
son informatique sur 2 niveaux :
 patrimonial : l'informatique est un enjeu
économique fondamental, aussi bien directement
(budget informatique), qu'indirectement (risque
d'arrêt de la production en cas d'incident). Ces
différents aspects patrimoniaux sont désormais
surveillés par les investisseurs.
 légal : conscient de la nécessité d'obliger
l'entreprise à protéger la valeur du capital investi
et à garantir la sincérité des rapports annuels, de
nombreuses législations imposent désormais aux
entreprises de prendre des dispositions de
protection du système d'information (Sarbanes-
Oxley, LSF, NRE, IAS/IFRS, Bâle II...)
24

@crochefolle
Même si chaque système a
plus ou moins été étendu aux
différentes facettes de
l'activité informatique, chaque
référentiel trouve son efficacité
dans un domaine particulier. Il
n'est pas donc pas trop
difficile de se tourner vers
celui qui sera pertinent.
25
Pour l'informatique, trois référentiels de bonnes
pratiques sont actuellement à la mode :
 COBIT (Control Objectives for Business &
Related Technology),
 ITIL (Information Technology
Infrastructure Library),
 CMMi (Capability Maturity Model
intégration).
Très complémentaires, ils ont chacun un domaine
de prédilection.
Outre ces trois référentiels, il en existe d'autres,
plus ou moins spécifiques ou plus moins en vogue
:
 PMI (Project Management Institute),
 Prince2 (PRojects INControlled
Environments),
 Spice (ISO 15504),
 ISO 17799,
 ISO 9000.

@crochefolle
 COBIT
Le COBIT (Control Objectives for Business & Related Technology), est
utilisé pour la gouvernance et l'audit des systèmes d'information.
Il analyse le système informatique suivant 4 domaines :
 planning et organisation,
 acquisition et mise en place,
 fourniture du service et support,
 surveillance.
 ITIL
ITIL (Information Technology Infrastructure Library), s'intéresse à la
production, qu'il s'agisse de fourniture de services informatiques ou
d'exploitation interne.
C'est donc une voie pour s'assurer de la satisfaction des utilisateurs ou
clients de services.
 CMMi
CMMi (Capability Maturity Model intégration) est le référentiel dédié au
développement de systèmes et logiciels.
CMMi permet d'évaluer la maturité de l'entreprise sur 5 niveaux :
 initial,
 reproductible,
 défini,
 maîtrisé,
 optimisé.
 Prince, Prince2
Prince (PRojects INControlled Environments) est un guide des meilleures
pratiques en direction de projet, utilisé par l'administration britannique.
Chaque processus est défini avec ses entrées et sorties caractéristiques
ainsi qu'avec les objectifs spécifiques à remplir et les tâches à accomplir.
La méthode Prince est dans le domaine public.
 PMI
Le PMI (Project Management Institute) a développé le standard PMBOK
(Project Management Body of Knowledge, élaboré sur la base des
meilleures pratiques du management de projet.
Il est organisé suivant 9 domaines :
 intégration du projet,
 contenu du projet,
 délais du projet,
 communication du projet,
 risques du projet
 approvisionnements du projet.
 Spice, ISO 15504
Spice est une norme créée par l’ISO (International Organization for
Standardization) pour standardiser l'évaluation des processus logiciels
(Norme ISO/CEI 15504).
Spice est moins une méthodologie de travail qu’un outil d'évaluation du
niveau de maîtrise du processus de conduite du projet.
 ISO 9000
Les certifications de la famille ISO 9000 constituent désormais un
ensemble de références de qualité incontestées sur le plan mondial.
Très généralistes, ces spécifications ne sont pas forcément les plus
productives pour l'informatique.
 ISO 17799
Catalogue de bonnes pratiques assurant un client que ses informations
sont gérées de manière sécurisée par son fournisseur.
Elle est présentée dans cette liste comme complément de réponse aux
obligations de sécurité des systèmes d'information.
26

@crochefolle
CMM (CAPABILITY MATURITY MODEL), CMMI (CAPABILITY MATURITY MODEL INTEGRATION)
La famille CMM est un ensemble de normes américaines du SEI (Software Engineering Institute)
définissant le niveau de qualité des pratiques de développement logiciel.
Le modèle CMMI définit une échelle de mesure de la maturité à 5 niveaux, ainsi que les indicateurs
nécessaires pour évaluer les activités menées par une équipe par rapport à cette échelle - l'équipe
peut être un groupe de travail, un ou plusieurs projets, une société voire une institution d'Etat.
Le modèle CMMI est majoritairement utilisé dans des sociétés d'informatique, toutefois les principes
de CMMI s'appliquent à n'importe quelle activité d'ingénierie : architecture, mécanique, électronique,...
La notion introduite est celle de maturité.
 D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel celle-ci a déployé
explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et
continuellement améliorés.
 Un niveau de maturité (Maturity Level) correspond à l'atteinte d'un niveau de capabilité uniforme pour un groupe
de processus. Un niveau de capabilité (Capability Level) mesure l'atteinte des objectifs d'un processus pour le
niveau donné.
27

@crochefolle
CMMi – les niveaux
Les bonnes pratiques préconisées par le modèle (version 1.2) sont rassemblées en 22 domaines de processus eux-
mêmes regroupés en 5 niveaux de maturité. Les domaines de processus rattachés à un niveau de maturité M ne
peuvent être stabilisés et efficaces que si les domaines de processus des niveaux inférieurs ( < M ) sont déjà stabilisés
et efficaces (principe d'empilement).
Les 5 niveaux sont :
 Initial (niveau de maturité 1) :
Il n'y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés),
tout doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne
sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se
font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés
par un individu. Les compétences et les ressources propres de cet individu sont la raison du succès ou de l'échec du projet (par dérision, ce niveau
est aussi nommé héroïque ou chaotique). Il n'y a pas de description du niveau de maturité 1 dans le modèle.
 « managed », soit discipliné en français (niveau de maturité 2) :
Une discipline est établie pour chaque projet et se matérialise essentiellement par des plans de projet (plan de développement, d'assurance
qualité, de gestion de configuration ...). Le chef de projet a une forte responsabilité dans le niveau 2 : il doit définir, documenter, appliquer et
maintenir à jour ses plans. D'un projet à l'autre, il capitalise et améliore ses pratiques de gestion de projet et d'ingénierie.
 « Defined », soit ajusté en français (niveau de maturité 3) :
Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées
dans les projets) et une maîtrise du référentiel interne (ou Système Qualité). Il existe des lignes directrices, un plan stratégique et une planification
de l'amélioration de processus pour le futur, en ligne avec les objectifs d'affaire de l'organisation. Les employés sont formés et conscients de leurs
responsabilités ainsi que de leurs devoirs.
 « Quantitatively managed », soit géré quantitativement en français (niveau de maturité 4) :
Les projets sont pilotés sur la base d'objectifs quantitatifs de qualité produit et processus. La capacité des activités (ou sous-processus) critiques
est déterminée par l'organisation, ainsi que les modèles de performance et de prévision associés. L'expression de la qualité demandée par le
client est prise en compte pour quantifier les objectifs du projet et établir des plans selon la capacité des processus de l'organisation.
 « Optimizing », soit en optimisation en français (niveau de maturité 5) en français :
Les processus qui sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en optimisation constante afin d'anticiper les
évolutions prévues (besoins clients, nouvelles technologies...).
28

@crochefolle
CMMi – Niveau 2
 Pour le niveau 2, les activités et produits (techniques et de gestion, intermédiaires et finaux) sont maîtrisés par le
projet. Les processus projet sont disciplinés, ce qui se caractérise par :
 les activités sont planifiées et exécutées conformément à une politique (ou directive) d'organisation,
 les rôles, responsabilités et acteurs sont définis et connus,
 les acteurs disposent des compétences et des ressources adéquates pour réaliser les produits,
 les produits sont contrôlés,
 la mise en œuvre du processus fait l'objet d'un suivi, de vérifications et d'ajustement si nécessaire.
 Le niveau 2 se compose de sept domaines de processus traitant de :
 la gestion des exigences,
 la planification de projet,
 le suivi de projet,
 la gestion des fournisseurs,
 l'utilisation des métriques,
 l'assurance qualité
 et la gestion de configuration.
 Chacun de ces sept domaines de processus contribue à donner à l'organisation une bonne visibilité sur ses
développements : visibilité sur le contenu, les coûts, les délais, la qualité des produits développés et des
processus utilisés. Typiquement, les membres d'une équipe de développement, comme le management,
connaissent l'état d'avancement de leur projet et des évolutions en cours, ainsi que ce qu'il reste à faire.
29

@crochefolle
SPICE (Software Process Improvement and Capability dEtermination)
SPICE est une norme créée par l’ISO (International Organization for
Standardization) pour standardiser l'évaluation des processus logiciels
(Norme ISO/CEI 15504).
SPICE est cohérent avec CMMi, mais aussi ISO 9000 et ISO 12207.
C’est moins une méthodologie de travail qu’un outil d'évaluation de la
maîtrise de conduite du projet. C'est un référentiel des pratiques clés
destiné à tout projet de développement ou de maintenance du logiciel.
Il établit deux grands axes d’étude :
 le processus évalué sur 5 thèmes :
1. relations client-fournisseur relations avec le client,
2. ingénierie développement du logiciel,
3. support interface avec les autres processus,
4. gestion administration du développement,
5. organisation environnement d'exploitation.
 la maturité, évaluée en cinq niveaux :
0. incomplet, le processus n'est pas réalisé, ou bien il
n'atteint son objectif que partiellement ou bien le
résultat n’est pas facilement identifiable. Répétabilité
des processus,
1. effectué, les objectifs du processus sont atteints, les
pratiques de base sont employées, les produits en
fournissent la preuve. Le processus est géré au
niveau de l'individu. Pertinence par rapport aux
objectifs de l'entreprise.
2. géré, les produits sont vérifiés et conformes aux
standards. La planification s'effectue au niveau projet
et est respectée, aussi bien au niveau du processus
lui-même que des produits issus du processus,
3. établi, les activités s'effectuent suivant un processus
standard défini au niveau de l'organisation. Le
processus est basé sur des pratiques documentées
standards adaptées aux besoins de chacun.
Comparaison face à un référentiel.,
4 prévisible, le déroulement du processus et de la
qualité des produits sont quantifiés et les
performances sont prévisibles. Obtention d’un niveau
de qualité prédéfini,
5 optimisé, l'organisation est capable d'améliorer de
façon continue ses processus pour les adapter suivant
les objectifs. Soutien de l’amélioration de la
productivité.
 Il se décrit en neuf documents :
1. les concepts fondamentaux,
2. l'ingénierie des processus,
3. l'évaluation du niveau d'aptitude,
4. la conduite de l'évaluation,
5. les outils, le guide des indicateurs d’évaluation,
6. la qualification des évaluateurs,
7. l'amélioration des processus,
8. les aptitudes des fournisseurs,
9. la terminologie (référentiel).
30

@crochefolle
Les méthodes Agile 1/3
Valeurs
Elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du
manifeste) :
 L'équipe (« Personnes et interaction plutôt que processus et outils ») :
Dans l'optique agile, l'équipe est bien plus importante que les moyens
matériels ou les procédures. Il est préférable d'avoir une équipe
soudée et qui communique composée de développeurs moyens plutôt
qu'une équipe composée d'individualistes, même brillants. La
communication est une notion fondamentale.
 L'application (« Logiciel fonctionnel plutôt que documentation complète
») : Il est vital que l'application fonctionne. Le reste, et notamment la
documentation technique, est secondaire, même si une documentation
succincte et précise est utile comme moyen de communication. La
documentation représente une charge de travail importante, mais peut
pourtant être néfaste si elle n'est pas à jour. Il est préférable de
commenter abondamment le code lui-même, et surtout de transférer
les compétences au sein de l'équipe (on en revient à l'importance de la
communication).
 La collaboration (« Collaboration avec le client plutôt que négociation
de contrat ») : Le client doit être impliqué dans le développement. On
ne peut se contenter de négocier un contrat au début du projet, puis de
négliger les demandes du client. Le client doit collaborer avec l'équipe
et fournir un feed-back continu sur l'adaptation du logiciel à ses
attentes.
 L'acceptation du changement (« Réagir au changement plutôt que
suivre un plan ») : La planification initiale et la structure du logiciel
doivent être flexibles afin de permettre l'évolution de la demande du
client tout au long du projet. Les premières releases du logiciel vont
souvent provoquer des demandes d'évolution.
Principes
Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les
méthodes agiles :
 « Notre première priorité est de satisfaire le client en livrant tôt et
régulièrement des logiciels utiles ».
 « Le changement est bienvenu, même tardivement dans le
développement. Les processus agiles exploitent le changement
comme avantage compétitif pour le client ».
 « Livrer fréquemment une application fonctionnelle, toutes les deux
semaines à deux mois, avec une tendance pour la période la plus
courte ».
 « Les gens de l'art et les développeurs doivent collaborer
quotidiennement au projet ».
 « Bâtissez le projet autour de personnes motivées. Donnez leur
l'environnement et le soutien dont elles ont besoin, et croyez en leur
capacité à faire le travail ».
 « La méthode la plus efficace pour transmettre l'information est une
conversation en face à face ».
 « Un logiciel fonctionnel est la meilleure unité de mesure de la
progression du projet ».
 « Les processus agiles promeuvent un rythme de développement
soutenable. Commanditaires, développeurs et utilisateurs devraient
pouvoir maintenir le rythme indéfiniment ».
 « Une attention continue à l'excellence technique et à la qualité de la
conception améliore l'agilité ».
 « La simplicité - l'art de maximiser la quantité de travail à ne pas faire -
est essentielle ».
 « Les meilleures architectures, spécifications et conceptions sont
issues d'équipes qui s'auto-organisent ».
 « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus
efficace, puis accorde et ajuste son comportement dans ce sens ».
31
Les méthodes Agiles sont des procédures de conception de logiciel qui se veulent plus pragmatiques que les méthodes traditionnelles. En
impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du
besoin du client, et non des termes du contrat de développement. La notion de méthode agile a été officialisée en 2001 par un document
Manifeste Agile (Agile Manifesto) signé par 17 personnalités impliquées dans l'évolution du génie logiciel et généralement auteurs de leur propre
méthode.

@crochefolle
Tronc des pratiques communes à l'ensemble des méthodes
Agiles
 Les pratiques communes liées aux ressources humaines
 Participation de l’utilisateur final aux groupes de travail.
 Groupes de travail disposant du pouvoir de décision.
 Autonomie et organisation centralisée de l’équipe (motivation).
 Spécification et validation permanente des Exigences.
 Les pratiques communes liées au pilotage du projet
 Niveau méthodologique variable en fonction des enjeux du
projet.
 Pilotage par les enjeux et les risques.
 Planification stratégique globale basée sur des itérations
rapides.
 Réalisation en jalons par prototypage actif itératif et
incrémental.
 Recherche continue d’amélioration des pratiques.
 Les pratiques communes liées à la qualité de la production
 Recherche d’excellence technique de la conception.
 Vision graphique d’une modélisation nécessaire et suffisante.
 Vision de la documentation nécessaire et suffisante.
 Normes et techniques raisonnables de qualité du code
(métrique).
 Architecture à base de composants.
 Gestion des changements automatisée.
Méthodes Agiles publiées
 Rapid Application Development (RAD)
 Dynamic systems development method (DSDM)
 Extreme programming (XP)
 Adaptive software development (ASD)
 Feature Driven Development(FDD)
 Scrum
 Crystal clear
 Processus Urbanisant les Méthodes Agiles (PUMA)
32

@crochefolle
Seules quelques techniques complémentaires entre elles, ou mieux
adaptées à des typologies et à des tailles de projets spécifiques,
différencient les méthodes Agiles (y compris ASD ou Crystal Clear).
 La méthode DSDM se particularise par la spécialisation des
acteurs du projet dans une notion de « rôles ». Ainsi, l'on trouvera
dans les réunions DSDM des sponsors exécutifs, des
ambassadeurs, des utilisateurs visionnaires, des utilisateurs
conseillers, sans oublier l'animateur-facilitateur et des rapporteurs.
 La méthode Scrum affirme sa différence dans des pratiques de
courtes réunions quotidiennes (Stand-Up meeting). Ces temps de
travail commun ont pour objectifs d'améliorer la motivation des
participants, de synchroniser les tâches, de débloquer les
situations difficiles et d'accroître le partage de la connaissance.
 Pour FDD, la particularité nommée Mission focused réside dans
une forte orientation vers un but immédiat mesurable guidé par la
notion de valeur métier. C'est en fait l'ambition globale d'une
itération qui se trouve ainsi renforcée. Cet aspect se retrouve aussi
dans la méthode RAD sous la forme des objectifs de Focus ou
dans Scrum dans la notion de Sprint. FDD préconise aussi le
Features Driven Development. Cette technique se caractérise par
des notions de Feature et de Features set (fonctionnalités et
groupes de fonctionnalités). La priorité est donnée aux
fonctionnalités porteuses de valeur. Le RAD propose des
techniques proches : livraison en fonctionnalité réduite ou livraison
par thèmes.
 XP (extreme programming) est très axé sur la partie Construction
de l'application. Une de ses originalités réside dans l’approche de
planification qui se matérialise sous la forme d’un jeu intitulé
Planning game et qui implique simultanément les utilisateurs et les
développeurs. On notera aussi des techniques particulières liées à
la production du code comme la programmation en binôme (Pair
programming), l'appropriation collective du code, la Refactorisation
(refactoring) et l' Intégration continue. La méthode RAD préconise
dans ce sens des revues de code personnelles, puis collectives et
l'intégration avant chaque Focus (ou Show). Par contre, le RAD
limite la programmation en binôme aux parties les plus
stratégiques.
 2TUP (2 track unified process, prononcez "toutiyoupi") préconise
un cycle de vie en Y qui dissocie la résolution des questions
fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente
à un cycle de développement en cascade mais introduit une forme
itérative interne à certaines tâches. Il n'est pas certain que ce cycle
s'apparente réellement à une approche Agile. Par contre, 2TUP
préconise des formes de recherche de qualité et de performance
intéressantes telles que les services réutilisables et la conception
générique (Framework et Patron de conception Design pattern)
proches des mécanismes architecturaux de RUP.
 UP se caractérise par une approche globale nommée « Vue 4+1 ».
Les 5 composants de cette vue sont : la vue des Cas d'utilisation,
la vue Logique, la vue d'Implémentation, la vue du Processus, la
vue du Déploiement. RUP offre aussi, à l'identique du RAD 2, un
Processus guide formel et adaptable comme guide d'activité. Dans
le cas de RUP, il est malheureusement propriétaire et orienté outil.
33

@crochefolle
Et alors?
 Des cycles de vies,
 Des référentiels de bonnes pratiques,
 Des méthodes de développement
34
Règles d’or :
 Ne pas appliquer une norme, un modèle pour lui-même ou
pour une certification, mais se poser la question à chaque
étape :
« Qu’est-ce que cela va m’apporter ? »
 Mieux vaux un modèle imparfait appliqué par tous et qu’on
améliore progressivement qu’un modèle parfait jamais
appliqué.

@crochefolle
GESTION DES EXIGENCES
35

@crochefolle
Définitions
 La gestion des exigences consiste à gérer les exigences hiérarchisées d'un projet, à détecter
les incohérences entre elles et à assurer leur traçabilité.
 Dans l'ingénierie logiciel, une exigence peut être la description de ce qu'un logiciel doit faire. Ce
type d'exigence spécifie quelque chose que le logiciel livré doit être capable de faire. Un autre
type d'exigence spécifie quelque chose sur le logiciel lui-même, et de quelle manière il exécute
ses fonctions. De telles exigences s'appellent souvent «exigences non fonctionnelles»,
«exigences de performance» ou «qualité des exigences de service». Exemples de ce type
d'exigences : la disponibilité, la testabilité, la facilité de maintenance et la facilité d'utilisation.
 Un ensemble d'exigences définit les caractéristiques ou propriétés du logiciel désiré (exigé). Une
«bonne» liste d'exigences évite de spécifier la manière pour le logiciel de mettre en œuvre ces
exigences, laissant ce genre de décision pour les activités de conception. Un élément parmi les
exigences qui décrit comment mettre en œuvre le logiciel s'appelle un biais de mise en œuvre.
 Le CMMi décrit les activités liées à la gestion des exigences dans la conception logicielle :
 Comprendre et intégrer les exigences au projet
 Valider les exigences
 Gérer le changement d'exigences
 Maintenir la traçabilité des exigences
36

@crochefolle
Comprendre et intégrer les exigences au projet
Les parties prenantes du projet expriment des besoins, qui sont formulés sous forme
d'exigences. Les responsables du projet, après avoir compris les exigences et en
avoir vérifié la cohérence, les intègrent au projet.
 Cela peut impliquer :
 De maintenir une liste des acteurs habilités à exprimer les exigences.
 De maintenir des critères pour accepter ou non les exigences.
 D'analyser des exigences vis à vis des critères.
 De formaliser l'acceptation d'une exigence.
 Gérer les incohérences entre le projet et les exigences.
37

@crochefolle
Valider les exigences
Pour garantir l'engagement des parties prenantes du projet, en ce qui concerne les
impacts sur le projet d'une nouvelle exigence ou d'un changement, on évalue les
conséquences sur le projet et on demande validation de l'exigence par les parties.
Cette activité peut donner lieu à :
 Une analyse d'impact d'une exigence ou d'un changement d'exigence
 Un document formalisant l'engagement des parties sur les exigences et leurs
impacts.
38

@crochefolle
Gérer le changement
Au cours d'un projet les exigences évoluent pour diverses raisons. Il est important de
gérer efficacement les changements et les ajouts. Pour pouvoir évaluer correctement
les impacts il est important que l'origine et la justification de tous les changements
soient documentées. On peut en outre vouloir mesurer la volatilité des changements.
Cela peut impliquer de produire :
 Un état des exigences
 Une base de données des exigences
 Une base de données des décisions concernant les exigences.
39

@crochefolle
Maintenir la traçabilité des exigences
La traçabilité est la possibilité de lire facilement ce qu'il est advenu et ce qu'il est censé advenir
de quelque chose.
La traçabilité des exigences est le fait de pouvoir à tout instant connaitre facilement l'origine et les
liens entre les exigences, ainsi qu'entre les exigences et le reste du projet ou le contexte
(notamment les besoins utilisateur, réalisation et tests).
Elle aide à répondre aux questions du type :
 D'où vient une exigence ? (Quel besoin cette exigence couvre-t-elle ? Pourquoi a-t-on conçu
la solution de cette manière et quelles étaient les autres possibilités ?)
 Cette exigence est-elle nécessaire ?
 Où met-on en œuvre cette exigence ?
 Comment interpréter cette exigence ?
 Quelle décision de conception affecte la mise en œuvre de l'exigence ?
 Cet élément de conception est-il nécessaire ?
 La solution réalisée est-elle conforme aux exigences ?
 Comment testera-on cette exigence ?
 Toutes les exigences sont-elles prises en compte ?
 Est-ce que le projet est terminé ?
 Quel est l'impact du changement d'une exigence ?
40

@crochefolle
GESTION DE
CONFIGURATION
41

@crochefolle
Définitions
 Les activités de gestion de configuration permettent de contrôler les évolutions durant le cycle de vie du logiciel,
d’archiver chacun des états successifs et de vérifier que chacun de ces états est complet et cohérent.
 On rassemble sous la dénomination « gestion de la configuration » l’ensemble des règles et des moyens destinés
à gérer la cohérence des différents logiciels, sous-ensembles logiciels, modules, composants et documents.
 D’après la norme NF Z 61-102, la gestion de configuration correspond à l’ensemble des activités (manuelles ou
automatisées) qui permettent d’identifier et de définir les éléments de configuration et toutes leurs relations.
 La gestion de configuration correspond à un problème de fond: connaître ,à tout moment, certaines informations
liées à un système installé sur un site donné, par exemple:
 Les matériels installés (y compris les périphériques et les cartes montées),
 Les programmes d’application avec leur version
 Les outils de conception et de développement utilisés,
 Les logiciels de tests utilisés,
 Les logiciels d’exploitation et les logiciels de base avec leur version,
 Les interfaces,
 Les logiciels associés,
 La documentation technique et la documentation d’utilisation correspondantes,
 L’état des dernières corrections,
 L’état des dernières demandes d’évolution,
 La liste des utilisateurs,
 …
42

@crochefolle
Plan de gestion de configuration
1. Introduction
 Objectifs
 Domaine couvert
 Relations avec les matériels associés
 Relations avec les documents associés
2. Organisation de la gestion de configuration (GC)
 Relations entre la GC et les services concernés
 Autorisations d’accès
 Autorisations de modifications
 Rappel des responsabilités des intervenants
 Rôle des responsables de la GC
 Principes
 Méthodes
 Procédures appliquées
3. Activités de la gestion de configuration
 Définition et identification des éléments
 Contrôle des éléments au fur et à mesure des
évolutions
 Suivi des demandes d’évolution
 Mise sous GC aux points d’arrêts prévus
 Contrôle des interfaces
 Suivi des différentes versions du produit au cours
de l’avancement
4. Vérifications de l’état du produit
 Contrôle par rapport aux spécifications
 Définition de la version de référence lors des
livraisons successives
5. Planning de la gestion de configuration
 Relation avec le plan de développement
6. Définition de la configuration
 Définition du matériel utilisé
 Définition du logiciel utilisé
 Définition du personnel responsable des actions
 Définition de la formation nécessaire
 Définition des informations en entrée
 Définition des informations en sortie
 Définition de l’archivage
7. Maintenance de la gestion de configuration
 Plan définissant les activités et responsables de
la GC pendant toute la durée de vie
43

@crochefolle
Composants
 Les élément de configuration d’un logiciel vont comprendre:
 Les documents de conception
 Les documents de réalisation
 Les documents d’utilisation
 Les documents d’exploitation
 Les programmes
 Les données des tables et paramètres
 Les procédures
 L’environnement de développement (tous les produits matériels et logiciels utilisés pour la
réalisation, la vérification et la modification du logiciel)
 L’environnement de recette (tous les produits logiciels utilisés pour les tests)
 Les jeux d’essais (données, procédure et scénarii de test)
 Les éléments à gérer sont au minimum :
 Le dossier de spécification du logiciel
 Le dossier de conception préliminaire
 Les programmes en langage source et les moyens permettant de reproduire ces mêmes
programmes en langage machine
 Les manuels d’utilisation
 Les manuels d’exploitation
44

@crochefolle
Gestion de version vs configuration
 La différence essentielle entre un logiciel de gestion de version et un logiciel de gestion de
configuration est que ce dernier propose des outils permettant :
 de gérer les demandes de modification du système à faire évoluer
 de mettre en correspondance les demandes de modifications avec les changements apportés
au système.
 PVCS parle de tâche, Perforce de jobs pour désigner ces demandes de modifications.
Autant CVS, SVN, SourceSafe et consorts ne sont que des gestionnaires de versions (CVS
signifie « Concurrent Versionning System » !) tandis que les premiers sont des gestionnaires de
configuration.
 Au début du projet, les tâches sont les spécifications du projet, puis on trouvera les demandes de
corrections ou d’évolutions.
 Grâce à cette association,
l’entropie du système reste sous contrôle,
la matrice de conformité est alors automatiquement renseignée,
le reste-à-passer global est connu à chaque instant.
45

@crochefolle
Etapes du processus de compilation et
assemblage
 Compilation
 Génération des librairies, exécutables, application web
Tests Unitaires
 Documentation du code (Javadoc,...)
 Mesure qualité (complexité cyclomatique, nb lignes de
code)
 Vérification des règles de codage
 Génération documentation utilisateur
 Tests fonctionnels/intégration
 Déploiement en espace de tests, pré-production,
production
46

@crochefolle
Intégration continue
Pour appliquer cette technique, il faut d'abord que :
 le code source soit partagé ;
 les développeurs intègrent (commit) quotidiennement
(au moins) leurs modifications ;
 des tests d'intégration soient développés pour valider
l'application
 un outil d'intégration continue
 Les principaux avantages d'une telle technique sont :
 les problèmes d'intégration sont détectés et réparés de
façon continue, évitant les problèmes de dernière
minute ;
 prévient rapidement en cas de code incompatible ou
manquant ;
 test immédiat des unités modifiées ;
 une version est toujours disponible pour test,
démonstration ou distribution.
 Les pratiques sont les suivantes :
 maintenir un dépôt unique de code source versionné ;
 automatiser les compilations ;
 rendre les compilations auto-testantes ;
 tout le monde committe tous les jours ;
 tout commit doit compiler le tronc sur une machine
d'intégration ;
 maintenir une compilation courte ;
 tester dans un environnement de production cloné ;
 rendre disponible facilement le dernier exécutable ;
 tout le monde doit voir ce qui se passe ;
 automatiser le déploiement.
47
L'intégration continue est un ensemble de pratiques utilisées en génie logiciel.
Elles consistent à vérifier à chaque modification de code source que le résultat des
modifications ne produit pas de régression de l'application en cours de
développement. Bien que le concept existait auparavant, l'"intégration continue" se
réfère généralement à la pratique XP :
« Daily build, nightly test »

@crochefolle
 Séparation des espaces
 Développement
 Build
 Test
 (Pré-production)
 Production
 Un système de GC unique pour un projet, voire pour
l’entreprise
 Un système de build commun au projet (voire à
l’entreprise) intégrant les tests (au minimum les tests
unitaires)
48
Règles d’or

@crochefolle
GESTION DES TESTS
49

@crochefolle
Définitions
 Un test est un ensemble de cas à tester (état de l'objet
à tester avant exécution du test, actions ou données
en entrée, valeurs ou observations attendues, et état
de l'objet après exécution), éventuellement
accompagné d'une procédure d'exécution (séquence
d'actions à exécuter). Il est lié à un objectif.
 La définition d'un test revient donc à définir cet
ensemble. Différents types de test permettent de
détecter différents types de défaut.
 Un test vise à mettre en évidence des défauts de
l'objet testé. Cependant il n'a pas pour objectif :
 de diagnostiquer la cause des erreurs,
 de les corriger,
 de prouver la correction de l'objet testé.
 La définition d'un cas à tester précise les exigences
s'appliquant à une spécification. Un objet ne peut être
testé que si on peut déterminer précisément le
comportement attendu en fonction des conditions
auxquelles il est soumis. Si la spécification ne permet
pas cette détermination, la propriété du logiciel qu'elle
définit ne peut être testée.
 Soumettre la spécification à cette contrainte de
« testabilité » permet d'en améliorer la précision
puisqu'elle oblige à expliciter les caractéristiques de
l'objet. Ceci permet, en retour, de trouver plutôt les
erreurs de spécification (incohérence, etc). Cette
contrainte est renforcée par certaines méthodes de
développement comme le Test-Driven Development.
 L'activité de test d'un logiciel utilise différents types et
techniques de test pour vérifier que le logiciel est
conforme à son cahier des charges (vérification du
produit) et aux attentes du client (validation du
produit). Elle est un des processus du développement
de logiciel.
 Vérification: Est-ce que nous livrons un logiciel
correct, c-à-d conforme aux spécifications.
 Validation: Est-ce que nous livrons le logiciel
attendue, c-à-d conforme aux attentes du client.
50

@crochefolle
Définitions complémentaires
 Campagne de Test
Activité qui consiste à dérouler un ensemble de scénarios de test. Un dossier de test est produit à l'issue d'une
campagne de tests.
 Cas de test (exigence)
" Point " particulier des spécifications du logiciel nécessitant un test
(règle de traitement, de calcul, de gestion, …)
 Dossier de Test
Ensemble documentaire qui contient la description des scénarios, des jeux de test et leurs exécutions, des
anomalies et leur suivi. Le dossier de test est le reflet d'une campagne de tests.
 Jeux de Test
Ensemble de cas de test permettant de vérifier un produit logiciel. L'enchaînement des jeux de test est relatif à
une stratégie de test précisée dans le plan de test et les spécifications.
 Plan de Test
Document décrivant la démarche générale de test associée au développement d'un logiciel : la stratégie de test, le
périmètre (la couverture), les critères d'arrêt, les moyens à mettre en œuvre, la planification. Sa rédaction
intervient durant la phase de définition du projet, il est ensuite mis à jour au cours de l'évolution du projet et du
développement du produit logiciel.
 Rapport de Test
Partie du Dossier de Test rapportant le résultat et l'analyse du passage de chaque jeu de test plan de test et les
spécifications.
 Scénarios de Test
Ensemble des jeux de test cohérents permettant de vérifier un objectif particulier (fonctionnel, performance, etc.).
51

@crochefolle
Typologie des tests
 Test unitaire
 Test fonctionnel
 Test d'intégration
 Test de performance
 Test de charge
 Test de
vulnérabilité/sécurité
 Test d'acceptation/Recette
 Test de non-régression
52

@crochefolle
Test unitaire
 le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un
logiciel ou d'une portion d'un programme (appelée « unité »).
 Il s'agit pour le programmeur de tester un module, indépendamment du reste du programme, ceci afin de s'assurer
qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette
vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne
couramment d'une vérification de la couverture de code, qui consiste à s'assurer que le test conduit à exécuter
l'ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester.
 L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de
régressions (l'apparition de nouveaux dysfonctionnements).
 Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche
secondaire. Cependant, la méthode Extreme programming (XP) a remis les tests unitaires, appelés « tests du
programmeur », au centre de l'activité de programmation.
 La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester (Test Driven
Development). Ceci permet de définir précisément l'interface du module à développer. En cas de découverte d'un
bogue, on écrit la procédure de test qui reproduit le bogue. Après correction on relance le test, qui ne doit indiquer
aucune erreur.
53

@crochefolle
Test d’intégration
Un test d'intégration est un test qui se déroule dans une phase d'un projet informatique suivant les
tests unitaires. Il consiste, une fois que les développeurs ont chacun validé leurs développements
ou leurs correctifs, à regrouper leurs modifications ensemble dans le cadre d'une livraison.
 Pour
 Valider le fait que toutes les parties développées indépendamment fonctionnent bien
ensemble de façon cohérente.
 Résultat
 Mise en évidence des problèmes d’interfaces entre composants
 Comment ?
 Vérifier pour chaque intégration que les résultats sont conformes au document de conception
détaillée
 Tester tous les appels entre composants
54

@crochefolle
Test fonctionnel
 Le test fonctionnel est le processus qui vise à trouver des erreurs dans le comportement d'un
logiciel ou d'un composant logiciel. On attend de ce type de test qu'il montre non seulement qu'un
logiciel fait ce qu'on attend de lui, mais aussi qu'il ne fait pas ce qu'on en n'attend pas..
 En soit, le test fonctionnel pourrait être simple: il suffirait de tester exhaustivement tous les
comportements d'un programme et de vérifier que chaque comportement satisfait la spécification.
Malheureusement, procéder à un test exhaustif est généralement hors de question: le nombre de
cas est souvent trop grand, voire infini, pour qu'on puisse tous les tester dans un temps
raisonnable. Le problème du test est donc un problème d'échantillonnage ou de couverture: il faut
sélectionner parmi les comportements possibles ceux qui assurent une meilleure couverture du
programme, c'est à dire qui sont représentatifs du comportement général du programme, sans
oublier les cas particuliers (les tests aux bornes), susceptibles de révéler des erreurs. La qualité
d'un ensemble de tests se mesure donc à la qualité de la couverture qu'il offre.
 Pour
 Vérifier la conformité de l'application développée avec les spécifications
 Comment ?
 En se fondant sur les spécifications fonctionnelles
 Scénarios, décomposition fonctionnelle
55

@crochefolle
Test de performance/ charge
 Test de Charge : il s'agit d'un test au cours duquel on va simuler
un nombre d'utilisateurs prédéfinis, afin de valider l'application
pour une charge attendue d'utilisateurs. Ce type de test permet
de mettre en évidence les points sensibles et critiques de
l’architecture technique. Il permet en outre de mesurer le
dimensionnement des serveurs, de la bande passante nécessaire
sur le réseau, etc.
 Test de Performance : proche du Test de Charge, il s'agit d'un
test au cours duquel on va mesurer les performances de
l'application soumise à une charge d'utilisateurs. Les informations
recueillies concernent les temps de réponse utilisateurs, les
temps de réponse réseau et les temps de traitement d’une
requête sur le(s) serveur(s). La nuance avec le type précédent
réside dans le fait qu'on ne cherche pas ici à valider les
performances pour la charge attendue en production, mais plutôt
vérifier les performances à différents niveaux de charge
d'utilisateurs.
 Test de stress : il s'agit d'un test au cours duquel on va simuler
l'activité maximale attendue tous scénarios fonctionnels
confondus en heures de pointe de l'application, pour voir
comment le système réagit au maximum de l'activité attendue
des utilisateurs. La durée du palier en pleine charge, en général
de 2 heures, doit tenir compte du remplissage des différents
caches applicatifs et clients, ainsi que de la stabilisation de la
plateforme de test suite à l'éventuel effet de pic-rebond consécutif
à la montée en charge. Dans le cadre de ces tests, il est possible
de pousser le stress jusqu'à simuler des défaillances systèmes
ou applicatives afin d'effectuer des tests de récupération sur
incident (Fail-over) ou pour vérifier le niveau de service en cas de
défaillance.
 Test de Robustesse, d'endurance, de fiabilité: il s'agit de tests
au cours duquel on va simuler une charge importante
d'utilisateurs sur une durée relativement longue, pour voir si le
système testé est capable de supporter une activité intense sur
une longue période sans dégradations des performances et des
ressources applicatives ou système. Le résultat est satisfaisant
lorsque l'application a supporté une charge supérieure à la moitié
de la capacité maximale du système, ou lorsque l'application a
supporté l'activité d'une journée ou plusieurs jours/mois/années,
pendant 8 à 10 heures, sans dégradation de performance (temps,
erreurs), ni perte de ressources systèmes.
 Test de capacité, Test de montée en charge : il s'agit d'un test
au cours duquel on va simuler un nombre d'utilisateurs sans
cesse croissant de manière à déterminer quelle charge limite le
système est capable de supporter. Éventuellement, des
paramétrages peuvent être effectués, dans la même logique que
lors des tests de dégradation, l'objectif du test étant néanmoins ici
de déterminer la capacité maximale de l'ensemble système-
applicatif dans une optique prévisionnelle
 Test aux limites : il s'agit d'un test au cours duquel on va simuler
en général une activité bien supérieure à l'activité normale, pour
voir comment le système réagit aux limites du modèle d'usage de
l'application. Proche du test de capacité, il ne recouvre pas
seulement l'augmentation d'un nombre d'utilisateurs simultanés
qui se limite ici à un pourcentage en principe prédéfini, mais aussi
les possibilités d'augmentation du nombre de processus métier
réalisés dans une plage de temps ou en simultané, en jouant sur
les cadences d'exécutions, les temps d'attente, mais aussi les
configurations de la plateforme de test dans le cadre
d'architectures redondées (Crash Tests).
56

@crochefolle
Test de vulnérabilité/sécurité
 Il s'agit avant tout d'effectuer un diagnostic des failles du système d'information. Pour cela, tous
les éléments de l'architecture en place sont concernés, que ce soient les éléments réseau
(routeurs, pare-feu), les services applicatifs (services Web, serveurs de messagerie) ou les
applications elles-mêmes. Le spectre peut parfois être encore plus large et concerner par
exemple les PABX installés dans l'entreprise.
 Les tests de vulnérabilité se contentent de détecter les failles d'un système sans toutefois les
exploiter. Un test d'intrusion consistera à identifier une faille et à s'y introduire, dans une
démarche de démonstration de ladite faille, et de mesurer les conséquences qu'elle peut
engendrer.
 Les tests de vulnérabilité sont en principe effectués de manière automatique et périodique par une
solution logicielle dont l'objectif est de scanner l'intégralité du système à la recherche de nouvelles
failles. On peut programmer cette recherche aussi souvent que souhaité (une fois par jour, par
semaine, par mois, par an...). Bien entendu, les analyses peuvent se faire manuellement, par des
ingénieurs sécurité, mais ces derniers utiliseront de toutes les façons des solutions spécialisées -
soit développées en interne, soit achetées. La différence se situe donc dans la présence ou non
d'un être humain derrière le processus de recherche de failles.
57

@crochefolle
Test d’acceptation / Recette
 Servent à la réception du logiciel par le client
 Basés sur :
 Des tests fonctionnels : «business»
 Des tests non-fonctionnels : robustesse, rapidité, etc.
 Fondés sur les critères d’acceptation définis dans le cahier des charges
58

@crochefolle
Test de non-regression
 Test de régression : tests d’un programme préalablement testé, après une modification, pour
s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non modifiées
du logiciel, comme suites des modifications effectuées.
 Ces tests sont effectués quand le logiciel ou son environnement est modifié.
 L'intérêt principal de ces tests est de limiter les anomalies relevées lors de la recette de
l'application. Ils viennent compléter les tests unitaires et les tests d'intégration en amont des tests
de recette.
 Pour
 Vérifier que le logiciel n’a pas été dégradé lors d’une modification (correction d’une anomalie
par exemple)
 Comment ?
 En rejouant les scénarios de tests déjà passés et dont les résultats étaient ceux attendus
59

@crochefolle
Référentiel de test
Un référentiel de tests doit pouvoir :
 Gérer les exigences de tests :
 Aide à la création
 Multi-utilisateurs : Partage aisé entre tous
les acteurs du projet
 Modification aisé
 Lien facile entre exigences > Fiches de
tests > Anomalies
 Génération d’une matrice de couverture
exigences ==> campagne / scénarios
 Analyse du taux de couverture
 Impression facile des listes
 Gestion des versions des exigences
 Gérer les fiches et cas de tests :
 Aide à la création
 Modification aisé
 Possibilité de joindre des documents
 Multi-utilisateurs
 Gestion des versions
 Gérer les cahiers / dossiers / plan de tests :
 Aide à la création des scénarios
 Gestion des versions
 Aide au pilotage des tests :
 Etat d’avancement de la conception des
tests
 Etat d’avancement de l’exécution des
tests
 Etat d’avancement global d’une campagne
de test
 Impression de rapport déjà renseigné et
formaté
 Interfaçage et pilotage directs des :
 Automates de tests fonctionnels
 Automates de tests techniques
(performance)
 Anomalies
60

@crochefolle
Plan de test
Un projet de plan de test est un document qui décrit les objectifs, la portée, l’approche et est orienté sur l’effort
nécessaire pour tester un programme. Le processus de préparation d’un plan de test est une méthode pratique
pour définir les efforts qui seront nécessaire pour valider l’assurance qualité d’un produit. Le document complété
peut aussi aider les personnes extérieures à l’équipe de test à comprendre « pourquoi » et « comment » le produit
sera validé.
Un plan de test défini quelles seront les fonctions qui seront testées et à quel niveau, dans quel ordre elles seront
testés et quelle sera la stratégie de test de chaque fonction et l’environnement de test utilisé.
L’objectif de chaque plan de test est de définir un schéma de vérification, et par les tests, s’assurer que le produit
satisfera à toutes les normes de qualité en vigueur. Dans le cas de test de validation, il s’agit souvent de tester
que les fonctionnalités se comportent comme prévu par le cahier des charges initial et produisent les résultats
escomptés.
61
1. Carte d’identité du plan de test
2. Références
3. Introduction
4. Modules à tester
5. Risques
6. Fonctions à tester
7. Fonctions à ne pas tester
8. Approche
9. Critères de Réussite/Echec des tests
10. Critères de suspension et critères de reprise
11. Tests déjà effectués
12. Tests à encore effectuer
13. Besoins en matériel
14. Besoins en personnel et formations
15. Responsabilités
16. Planning
17. Risques de planning et facteurs extérieurs
18. Approbations
19. Glossaire

@crochefolle
Test manuel vs Test automatisé
62
Test automatisé Test Manuel
Avantages
• Si vous devez exécuter les mêmes tests de manière répétitives
avec des jeux de données différents
• S’il s’agit d’un projet d’une durée réduite voire jetable
• SI vous devez effectuer des tests de compatibilités : mutl-
navigateur, multi-plateforme
• Permet aux testeurs de faire des tests plus aléatoires
• Permet d’effectuer des tests de non-regression de manière rapide
• Permet aux testeurs de faire des tests plus proches de la réalité et
donc de trouver des anomalies plus proche du monde utilisateur
• Permet d’effectuer des tests de non-regression sur du code en
changement fréquent
• Coût à court terme réduit
• Peux être effectuer en parallèle sur plusieurs machines pour
diminuer le temps de test
• Coût à long terme réduit
Inconvénients
• Il est très couteux d’automatiser, temps en mis en place qu’en
maintenance
• Les tests manuels peuvent consommer beaucoup de temps
• Tout ne peut pas être automatiser, certaines fonctions ne peuvent
être testées que manuellement
• Pour chaque version/release, vous devez refair eles mêmes tests,
ce qui devient très démotivant pour les équipes de test
Autres facteurs
• Performance des outils de test
• Le niveau de connaissance de votre équipe de test
• L’évolution du volume de fonctionnalité à tester
• Nombre de régression à tester

@crochefolle
Indicateurs et couverture de tests
Bilan de test
Document présentant le bilan quantitatif (nombre de tests rédigés, passés, en erreur, nombre et état des
anomalies, ...) et qualitatif (points forts, points à améliorer) de la mission de test, ainsi que le résultat fournis par
les indicateurs qualité mis en place. Il fournit enfin des préconisations afin de palier les points faibles sur les futurs
projets.
Indicateurs de suivi des tests :
 Nombre de tests effectués / totaux
 Nombre de tests passés avec succès/ échecs
 Couverture de tests
 Nombre d’anomalies ouvertes / fermées par campagne de test
 Charge consommée / charge prévisionnelle
Couverture de tests
 Pour mesurer l’efficacité des tests, il est nécessaire de vérifier les différents cas d'utilisation possible. Pour
résoudre ce problème, on utilisera des logiciels de couverture de code qui mettra en évidence les parties du code
source exécutées lorsque la suite de test est passée.
 Une bonne couverture de code par les tests est primordiale. Cependant, un taux de couverture élevé ne signifie
pas pour autant que le logiciel est bien testé. La fragilité des tests est un élément très important.
Par exemple : Ca n’est pas parce qu’un test couvre une partie de mon code que cette partie est testée. Imaginer
un test sans assert. Ce test participe à la couverture des tests mais pas à leur qualité. En effet, s’il n’y a pas
d’assert, le test a toutes les chances de toujours passer. Un test pour être efficace doit être plutôt fragile. C’est à
dire qu’il doit casser à la moindre modification du fonctionnel.
01/09/2018
63

@crochefolle
GESTION D’ANOMALIES
64

@crochefolle
Définitions
 Un bug/bogue/anomalie peut être :
 soit un non-respect de la spécification du système
(c’est-à-dire de la définition de ce que le système
est censé faire),
 soit un comportement inattendu non couvert par la
spécification (par exemple, cas non prévu de deux
actions contradictoires à traiter simultanément).
65

@crochefolle
Processus de gestion d’anomalie
Le cycle de vie d’une anomalie représente l'ensemble des états dans lequel les bugs doivent se trouver. Il est
généralement modélisé sous la forme d'une machine d'état qui énonce également les conditions de passage d'un
état à un autre.
66
•Avant de soumettre une nouvelle anomalie, il faut s'assurer de la confirmation de
l'anomalie (non respect du cahier des charge, crash de l'application, pas de fausse
manœuvre de l'opérateur, ...) et de sa reproductibilité (on sait assez facilement le
reproduire ou non).
•Parfois, l’anomalie n'est plus jamais reproduite par la suite sur base du même
environnement (les causes ne sont donc pas connues ou ciblées). Dans ce cas, on
préconise néanmoins de le rentrer en tant que "UNCONFIRMED". En agissant de cette
façon, on en garde toujours une trace.
•Une fois l’anomalie confirmée et reproductible, elle passe en "NEW" et commence son
cycle de vie. Le chemin le plus classique est le suivant : l’anomalie est assignée à un
développeur particulier (état "ASSIGNED").
•Cette assignation peut se faire automatiquement lors de l'insertion de l’anomalie (mais
elle reste dans l'état "NEW"). Dans ce cas, le développeur peut l'accepter (passage en
"ASSIGNED" ou l'assigner à une autre personne).
•Une fois assigné à un développeur, la mission de celui-ci est de le corriger dans les délais
requis.
•Une fois corrigé, l’anomalie passe en "RESOLVED".
•Ensuite, le contrôle qualité (les testeurs) vérifie que l’anomalie est effectivement corrigée
comme prétendu par le développeur. Si c'est le cas, l’anomalie est passée en "VERIFIED".
Si les différents cas de test démontrent que le problème persiste encore, elle est passée
en "REOPEN" en n'oubliant d'y ajouter des commentaires supplémentaires décrivant les
cas de test dans lesquels elle peut encore être reproduite.
•Une anomalie réouverte est généralement assigné de nouveau au développeur (état
"ASSIGNED") et suit une seconde fois le chemin présenté ci-dessus.
•Lors de la release finale du produit, une campagne de test est mise en œuvre et on vérifie
de nouveau que les anomalies corrigés en cours du développement ("VERIFIED") le sont
toujours. Dès lors, elles sont fermées définitivement (passés en "CLOSED") et les cas de
test rajoutés aux tests de non-régression.

@crochefolle
Sévérité, criticité
Matrice Sévérité
Importance
1 - Critique 2 - Majeur 3 - Mineur 4 - Accessoire
Occurrence
1 - Fonction principale très utilisée 1 1 2 3
2 - Fonction secondaire, peu utilisée 1 2 3 4
3 - Exceptionnellement, une seule fois 3 4 4 4
Définition
Importance Niveau 1 - Critique : Crash
Niveau 2 - Majeur : Fonction non réalisée sans contournement
Niveau 3 - Mineur : Fonction non réalisée avec contournement
NIveau 4 - Accessoire : Tout le reste
Occurrence
Niveau 1 : Fonction principale très utilisée ou anomalie sur l'ensemble des plateformes
supportées
Niveau 2 : Fonction secondaire, peu utilisée ou anomalie sur les principales plateformes
supportées
Niveau 3 : Anomalie constatée exceptionnellement ou une seule fois, ou anomalie sur une
des plateformes supportées
67

@crochefolle
Indicateurs
 Nombre de tickets ouverts par semaine
 Nombre de tickets fermés par semaine
 Nombre de tickets actifs/en cours par semaine
 Temps moyen de prise en compte d'une anomalie
 Temps moyen de résolution d'une anomalie
 Temps moyen de fermeture d'une anomalie
68

@crochefolle
 Une anomalie qui n’est pas référencée dans le référentiel
d’anomalies n’existe pas.
 Une anomalie non-reproduite doit être référencée pour
mémoire.
 Le contenu d’une anomalie doit être définit pour chaque
projet, système / sous-système afin d’être pertinente.
69
Règles d’or

@crochefolle
GESTION DE
DOCUMENTATION
70

@crochefolle
Définitions
 La maîtrise des documents, préoccupation permanente de la qualité se retrouve dans toutes les étapes du cycle
de vie. Le rôle de la documentation est essentiel, car c’est elle qui :
 Matérialise l’avancement des travaux,
 Constitue le moyen de communication privilégié entre les différents intervenants,
 Fait partie de la fourniture du produit
 Est le support de base indispensable pour les étapes suivantes,
 Constitue une partie de la mémoire de l’entreprise.
 Il est indispensable de structurer la documentation pour pouvoir la faire vivre, la diffuser, l’exploiter et la
sauvegarder efficacement.
 La maîtrise des documents est la capacité à concevoir, rédiger, diffuser et retirer de la circulation si nécessaire,
les documents adaptés à l’usage pour lequel ils sont prévus. Cette maîtrise doit couvrir toutes les étapes du cycle
de vie du logiciel que nous avons étudié : la conception, le paramétrage, le développement, la recette,
l’installation, l’exploitation et la maintenance, sans oublier tous les documents relatifs au système qualité.
 De plus il faut ajouter :
 Tous les documents d’organisation liés au projet, tels que contrat, planning, organisation du projet, plan de
développement, plan d’intégration, plan de validation, procédures d’acceptation, … ;
 Tous les documents de type d’exploitation, tels que les manuels d’installation, d’utilisation, de maintenance,
…
71

@crochefolle
Plan de gestion de documentation
Il doit définir les éléments suivant :
1. L’identification des documents
2. Les normes de présentation
3. Les états d’un document
4. Les révision et les règles de gestion des versions
5. La circulation des documents
 L’identification
 La création
 La validation
 La diffusion
 Les modifications
 La suppression
6. La procédure d’approbation et de diffusion
7. La procédure de modifications des documents
8. La mise en place de l’organisation administrative
72

@crochefolle
 Attribuer une référence (numéro) à un document afin de pouvoir
l’identifier sans équivoque. En corollaire, à une référence donnée doit
correspondre un document et un seul.
 Gérer la documentation par sous-ensembles, les références d’un
même sous ensemble étant répertoriées dans une nomenclature de
gestion. La description des liens se fait par un schéma
d’arborescence.
 Identifier les documents en fonction de leur nature ou de leur
utilisation. (Dossier de spécification, dossier de conception, dossier
d’exploitation, etc…).
73
Règles d’or

Qualité logiciel - Generalités

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Qualité logiciel - Generalités

Similaire à Qualité logiciel - Generalités (20)

Plus de Christophe Rochefolle

Plus de Christophe Rochefolle (14)

Qualité logiciel - Generalités