2020/2021

Plan

Introduction - Définition
Exigences qualité
PAQ: Plan Assurance Qualité
Gestion des exigences
Gestion des changements
Gestion des tests
Gestion de la configuration
Gestion de la documentation

2
Pourquoi la qualité logiciel?
Les exigences de la qualité sont souvent négligées
Le taux de perte, d’échec ou des difficulté de projet est très élevé.

Projets IT 2004 2006 2008 2010 2010

Succès 29% 35% 32% 37% 39%
Echec 18% 19% 24% 21% 18%
Difficulté 53% 46% 44% 42% 43%

3
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)

4
Postulats pour toute démarché 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
Exigences qualité système

6
Exigences qualité du produit

7
Exigences qualité des données

8
Exigences qualité du
fonctionnement

9
PLAN QUALITÉ LOGICIEL

10
Définition et 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.

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é.

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é

11
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

12
Sommaire type
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

13
 Les normes qualité informatique
Pour l'informatique, trois référentiels de bonnes Outre ces trois référentiels, il en existe d'autres, plus
pratiques sont actuellement à la mode : ou moins spécifiques ou plus moins en vogue:
 COBIT (Control Objectives for Business & PMI (Project Management Institute),
Related Technology), Prince2 (PRojects INControlled
 ITIL (Information Technology Environments),
Infrastructure Library), ISO 17799,
 CMMi (Capability Maturity Model ISO 9000.
intégration).
ISO 38500
Très complémentaires, ils ont chacun un domaine
de prédilection.

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.

14
GESTION DES EXIGENCES

15
 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 maintenanceet 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

16
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.

17
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 la
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.

18
GESTION DES CHANGEMENTS

19
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.

20
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 ?
• La solution réalisée est-elle conforme aux exigences ?
• Comment testera-on cette exigence ?
• Est-ce que le projet est terminé ?
• Quel est l'impact du changement d'une exigence ?

21
GESTION DES TESTS

22
 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é.

23
Définitions
• 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.

• 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.

24
Définitions
• Campagne de test : Activité qui consiste à dérouler un ensemble de scénarii 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énarii, des jeux de
test et leurs exécutions, des anomalies et leur suivi. Le dossier de test est le reflet d’une
campagne de test.
• Jeux de test: Ensemble de test permettant de vérifier un produit logiciel. L’enchainement 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.).

25
Typologie de test
• 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

26
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.

27
 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

28
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'attendpas..

• 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'iloffre.

29
 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 de 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.

30
 Test de performance/ charge
• 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).

31
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.

• 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 defailles.

32
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

33
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 estmodifié.

• 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

34
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.

1. Carte d’identité du plan de test 10. Critères de suspension et critères de reprise

2. Références 11. Tests déjà effectués
3. Introduction 12. Tests à encore effectuer
4. Modules à tester 13. Besoins en matériel
5. Risques 14. Besoins en personnel et formations
6. Fonctions à tester 15. Responsabilités
7. Fonctions à ne pas tester 16. Planning
8. Approche 17. Risques de planning et facteurs extérieurs
9. Critères de Réussite/Echec des tests 18. Approbations
19. Glossaire

35
 Test manuel vs Test automatisé
Test automatisé Test Manuel

Avantages
•Si vous devez exécuter les mêmes tests de manière répétitives
• S’il s’agit d’un projet d’une durée réduite voire jetable
avec des jeux de données différents
•SI vous devez effectuer des tests de compatibilités : mutl-
• Permet aux testeurs de faire des tests plus aléatoires
navigateur, multi-plateforme
•Permet aux testeurs de faire des tests plus proches de la réalité et
• Permet d’effectuer des tests de non-regression de manière rapide
donc de trouver des anomalies plus proche du monde utilisateur
•Permet d’effectuer des tests de non-regression sur du code en
• Coût à court terme réduit
changement fréquent
•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
• Les tests manuels peuvent consommer beaucoup de temps
maintenance
•Tout ne peut pas être automatiser, certaines fonctions nepeuvent •Pour chaque version/release, vous devez refair eles mêmes tests,
être testées que manuellement 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

36
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.

37
GESTION DE CONFIGURATION

38
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,

39
 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
40
Plan de gestion de configuration
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
Planning de la gestion de configuration
 Relation avec le plan de développement
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
Maintenance de la gestion de configuration
 Plan définissant les activités et responsables de la GC pendant toute la durée de vie

41
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 lestests)
• Les jeux d’essais (données, procédure et scénarii de test)

42
Composants
• 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

43
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.

• 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 enseignée, le reste-à-passer
global est connu à chaque instant
.

44
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

45
Intégration continue
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 »

46
 Intégration continue
• 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
 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.

48
Règles d’or
• 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)
49
GESTION DE DOCUMENTATION

50
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

51
Plan de gestion de documentation
Il doit définir les éléments suivants :
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

52
Règles d’or

• 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…).

53