!"#$"!%&!

% %(
)&#*"!+*(!)" ,%+ -&).%(+
!"/)&0*(!12%+
!" $%&'%(()
*
+,-
.//0- 1&23)4
Gnie Logiciel
Introduction
Systme informatique
3
! Un systme informatique est un systme complexe qui
doit rpondre :

" Aux besoins du monde rel

" Et non pas des contraintes lies aux ordinateurs sur lequel il
sera ralis

! Il y a donc ncessit de modliser le monde rel pour
qu'il soit compatible avec le support matriel utilis :
par l'intermdiaire d'un langage de programmation
Introduction
Le logiciel
4
! Les caractristiques du Logiciel

" Il est impalpable, incorporel : ce qui rend difficile
l'valuation et le suivi des efforts de dveloppement
" Il est facile reproduire. Les cots de fabrication/
reproduction sont pratiquement nuls
" L'industrie du logiciel est une industrie de main-
d'uvre. Il y a peu de possibilits d'automatisation.
Introduction
Le logiciel
5
! N'importe qui peut facilement bidouiller n'importe quoi

! Modifier un logiciel est relativement facile

" Au point que l'on peut faire une modification sans en comprendre
pleinement les consquences

! Un logiciel ne s'use pas

" Il se dgrade suite des modifications
# Cration d'erreurs
# Augmentation de la complexit
Introduction
Logiciel : dfinition
6
! Logiciel
" Ensemble des programmes, procds et rgles et de
la documentation, relatifs au fonctionnement d'un
ensemble de traitement de donnes.

" Written programs or procedures or rules and
associated documentation pertaining to the
operation of a computer system and that are stored
in read/write memory
Introduction
Les catgories de logiciel
7
! Logiciel spcifique
" Dvelopp pour un client unique, pour une utilisation prcise

! Logiciel gnrique ou progiciel
" Dvelopp pour un type d'application donn et non adapt un
utilisateur particulier
" Appel aussi Logiciel sur tagre (COTS : Commercial Off The
Shelf)

! Logiciel embarqu ou intgr
" Intgr et adapt un quipement donn. Une modification peut
ncessiter ou tre la consquence d'une modification de
l'quipement
Introduction
Les catgories de logiciel
8
! Ces trois catgories de logiciel peuvent tre
" Temps rel
# Grant et contrlant des systmes lectroniques
# Pouvant mettre en jeu la scurit des personnes et des biens
(safety)

" Traitement de donnes
# Orients process tertiaires
# Importance de la fiabilit et scurit des donnes (security)

" Parfois les deux aspects
Introduction
Consquences
9
! Matriser ces diffrentes caractristiques reprsente une
difficult majeure et se traduit par :
" Des projets qui ne respectent pas les dlais et/ou qui cotent
beaucoup plus cher que prvu ;

" Des projets qui sont arrts et ne dbouchent jamais ;

" Des logiciels ne satisfaisant pas les besoins des utilisateurs ;

" Des logiciels contenant un nombre inacceptable d'erreurs ;

" Des quipes projet perptuellement au bord de la crise de nerf.
Introduction
Gnie logiciel
10
! Le gnie logiciel est n de la ncessit d'attnuer ces
difficults et de faire le pont
" entre un monde rel plus ou moins organis, plus ou moins
prvisible, plus ou moins matris et
" un monde informatique trs largement algorithmique.

! Le gnie logiciel peut tre dfini :
procdures, mthodes, langages, ateliers, organisation lis des
normes adaptes l'environnement d'utilisation afin de favoriser
la production et la maintenance de composants logiciels de
qualit et cots matriss.
Introduction
Les rsultats attendus
11
! Matriser les nouveaux dveloppements quels
que soient leur taille
! Matriser les volutions successives des logiciels
existants
! Matriser les cots et les dlais
! Permettre le fonctionnement d'quipes de taille
importante
! Dvelopper des standards et des normes
Introduction
Les moyens
12
! Obtenir de tels rsultats implique :
" Mettre en uvre des techniques bien comprises dans le
cadre d'une dmarche organise et discipline
" Travailler en quipe : coordination, gestion des interfaces
organisationnelles et produit
" Dfinir, construire et valuer la qualit de la dmarche et
du produit

# Rappel : qualit=Aptitude dun ensemble de caractristiques
intrinsques satisfaire des exigences
Introduction
Le champ couvert par le
gnie logiciel
13
! Les mthodes et outils de spcification des fonctionnalits
d'un logiciel (y compris les spcifications formelles) ;

! Les mthodes et outils de conception de logiciel :
mthodes et langages de conception, atelier logiciel,
environnement de dveloppement, ... ;

! La gnration automatique de code d'aprs une
spcification formelle ;
Introduction
Le champ couvert par le
gnie logiciel
14
! Les outils de prototypage

! Les mthodes et outils de vrification/validation
de logiciel

! Les mthodes et outils de gestion de projet

! Les mthodes et outils de gestion de la
documentation et de la configuration
Introduction
Gnie Logiciel
Un bref historique
L're des pionniers :
de 1945 1965
16
! Des machines normes

! Des programmes spcifiques chaque machine

! Des interfaces hommes machines inexistantes ou trs
limites (cartes et rubans perfors, tltypes,
imprimantes texte)

! Des machines ddies un type de tche
Un bref
historique
L're des pionniers :
de 1945 1965
17
! Initialement le codage est effectu directement en binaire

! Puis apparaisse les 1 assembleurs (propres une machine
donne) qui permettent d'associer chaque commande binaire
une commande littrale traduisible automatiquement en binaire

! Enfin cette priode voit apparatre les 1 langages de
programmation universel (cd indpendants de l'ordinateur) :
" FORTRAN : FORmula TRANslator (1954-1956)
" COBOL : COmmon Business Oriented Language (1959)
" ALGOL : ALGOrithmic Language (1959)
Un bref
historique
La crise du logiciel :
de 1965 1985
18
! L'augmentation du nombre des systmes programms et
l'augmentation de la taille des programmes entrainent
une difficult croissante de matrise
" Dveloppements qui prennent du retard (dlais multiplis par
2 ou 3)
" Projets qui n'aboutissent pas
" Qualit des programmes de plus en plus faible

! Le comit scientifique de l'OTAN organise 2 confrences
en 1968 et 1969 o apparait pour la 1 fois le terme
de Software Engineering
Un bref
historique
La crise du logiciel :
de 1965 1985
19
! Dveloppement de langages de plus en plus volu
" Pascal : 1970
" C : 1972
" C++ : 1983-1985
" ADA : 1983

! 1 essais de formalisation des dmarches de dveloppement :
standards MIL et IEEE (relays en France par le MFQ, l'AFNOR
et les militaires)

! Apparition de la notion de CASE : Computer Aided Software
Engineering (Atelier Logiciel)
Un bref
historique
Les 1 essais d'industrialisation :
de 1985 2000
20
! Monte en puissance de la normalisation
" Normalisation des dmarches : DOD2167 (1985), DO178 (1985),
Capability Maturity Model du SEI (1987)
" Normalisation des activits : NORMES ANSI et ISO
" Normalisation des langages : C (1989), C++ (1998)

! Dveloppement d'ateliers de dveloppement
! Nouveaux langages : JAVA (1994), UML (Unified
Modeling Language)(1995)
! Monte en puissance d'Internet
! Dveloppement des interfaces Homme-Machine
Un bref
historique
Depuis 2000 : les grandes
tendances
21
! Mthodes orientes objet

! La formalisation des processus de dveloppement
(CMMI, DO178C)

! Mthodes de Dveloppement Agiles (Extreme
Programming)

! Prototypage

! Rutilisation
Un bref
historique
Gnie Logiciel
Les diffrents types de logiciel
et le contexte de leur dveloppement
Les catgories de logiciel
23
! Divers paramtres sont utilisables pour
caractriser un logiciel :
" La taille : notion relative et dpendant de
l'entreprise ;
" La complexit : souvent lie la taille, mais dpend
essentiellement des algorithmes employs et des
rgles de programmation employes ;
" La criticit : se mesure aux consquences des pannes
dues au logiciel ;
" Le niveau de rutilisation envisag.
Type de
logiciel
Les catgories de logiciel
24
! Divers paramtres sont utilisables pour caractriser un
logiciel :
" L'architecture utilise : mainframe, client serveur, web, poste de
travail autonome, microprocesseur embarqu ;
" L'importance et la qualit de l'interface homme-machine
(IHM) exige ;
" Le degr de dpendance l'existant ;
" Le domaine d'application : gestion, scientifique, technique,
bureautique, pilotage de processus, pilotage d'quipement, ...

Type de
logiciel
Le contexte
25
! De plus il faut tenir compte de l'environnement
dans lequel va se drouler le dveloppement :

" Niveau de compltude et de stabilit de l'expression
du besoin ;
" Niveau d'urgence de la ralisation (dlais) ;
" Qualit des relations entre les acteurs ;
" Degr d'industrialisation des processus de
dveloppement et des outils associs.

Type de
logiciel
Le contexte
26
! Le choix de la dmarche mettre en uvre va
dpendre de ces diffrents paramtres avec des
consquences en terme :

" D'organisation ;
" D'estimation des cots et des dlais ;
" De planification ;
" De mthodes ;
" D'outils utiliser.
Type de
logiciel
Le contexte
27
! Si scurit et suret de fonctionnement sont
prioritaires :
" Aronautique, spatial, ferroviaire : la formalisation
de la dmarche (CMMI, DO178C, normes ESA) va
tre impose, ainsi que la rutilisation

! Si la disponibilit (dlai) est prioritaire :
" Mthodes agiles, prototypage
Type de
logiciel
Gnie Logiciel
Les activits de bases
Gnie logiciel
29
! Les exigences (ou spcifications)
! La conception
! La ralisation
! Les tests
! La qualit
! L'exploitation
! La maintenance
! La gestion de la configuration et de la
documentation
! La gestion de projet : WBS, GANTT et PERT
Les activits
de base
Gnie logiciel
30
! Ces activits sont gnriques et indpendantes des
langages, mthodes et techniques utiliss

! Ces activits peuvent se combiner de diffrentes
faons : notion de cycle de vie

! Ces activits devront tre modules selon le type de
logiciel dvelopp

! Ces activits peuvent tre modlises sous forme de
processus (CMMI)
Les activits
de base
Gnie Logiciel
Les exigences
Les exigences
32
! Il s'agit de la prise en compte des besoins
explicites et implicites du client et de leur mise en
forme en vue de leur informatisation.

Cela inclut :
" Des prrequis
" L'analyse des exigences
" La spcification des exigences
" La validation des exigences
" La gestion des exigences
Les activits
de base
Les exigences
33
! Prrequis
Il s'agit de notions qui doivent tre comprises de faon
identique par le MOA et le MOE
" Exigences produit et processus
# Exigences produit : ce qui est raliser (gnralement formules par le
MOA)
# Exigences processus : portent sur les moyens, les techniques, les mthodes.
Sont gnralement formules par le MOE
" Exigences fonctionnelles et non-fonctionnelles
# Exigences fonctionnelles : fonctions que doit excuter le logiciel
# Exigences non-fonctionnelles : contraintes associes performances,
maintenabilit, fiabilit.
" Exigences quantifiables
# crire : la connexion doit se faire en moins de 2s et non la connexion doit se
faire rapidement
Les activits
de base
Les exigences
34
! Prrequis :
Les exigences sont gnralement rassembles dans un
cahier des charges
" C'est un document tabli par le MOA pour exprimer ses besoins

" Il est analys, complt par le MOE dans le cadre de description de
sa solution

" Il est utilis par le MOA pour recetter le produit labor par le MOE
Les activits
de base
Les exigences
35
$ Plan type d'un cahier des charges

! Introduction
! Description globale
! Fonctionnalits
! Interfaces externes
! Exigences non fonctionnelles
! Exigences complmentaires
! Annexes
Les activits
de base
Les exigences
36
! La valeur M/m spcifie si la fonctionnalit est dune importance Majeure (M)
ou mineure (m) (autrement dit indispensable ou pas).
DESCRIPTION n
GENERALITES LIEES A LINTERFACE
1 M
2 M
3 M
Par dfaut, la langue de linterface doit tre le franais 4 M
5 m
6 M
7 M
8 M
FONCTIONNALITE
ATTENDUE
M
/
m
Rponse
(Oui/Non
/P/ ND)
Commentaire
(inclus / optionnel / dveloppement
Complmentaire, Surcot ventuel)
ACCES A
LINTERFACE
GENERALE
Linterface de la solution pour tous les utilisateurs
quelques soient leurs droits (administrateur ou simple
utilisateur) est une interface full web, cest--dire
accessible via un navigateur Internet.
La solution doit tre supporte par les navigateurs web
Mozilla Firefox, Internet Explorer et Safari.
GESTION
MULTILINGUE
Linterface doit tre disponible en langues franaise et
anglaise au minimum
Le choix de la langue de linterface est dtermin la
connexion selon les prfrences associes au compte
utilisateur (stocks sur un serveur LDAP)
STRUCTURE ET
ARBORESCENCE
GENERALE
Il doit tre possible de crer un nombre illimit de bases
documentaires correspondant aux projets des diffrentes
quipes de lIPGP (ajout possible sans restriction).
Il doit tre possible de crer un nombre illimit de
dossiers et documents lintrieur de chaque base
documentaire.
Larborescence du portail documentaire doit tre comme
suit (Cf. schma Annexe)
Les activits
de base
Les exigences
37
! Quelques rgles incontournables :
" Une fois le contrat sign, le non respect d'une exigence du
CdC est considr comme une anomalie
# que ce soit une absence
# un plus non demand
# une rponse diffrente.
Le niveau de l'anomalie peut tre modul en fonction de l'importance
de l'exigence (M ou m)

" Toute modification du CdC en cours de projet doit tre crite
et valide par le MOA et le MOE

" Toute modification du CdC en cours de projet prsente un
risque
Les activits
de base
Les exigences
38
! Quelques rgles incontournables :

" Les contraintes sont des exigences qui peuvent tre
contre productives :
# Imposer une solution informatique en voie d'obsolescence
# Imposer l'utilisation d'une technologie qui restreint fortement le
nombre de ralisateurs possibles
" Il en est de mme pour les exigences non-fonctionnelles :
le mieux est souvent l'ennemi du bien
Les activits
de base
Les exigences
39
! Analyse des exigences :
Pour dtecter et rsoudre les conflits entre exigences et
identifier les limites du logiciel et ses interactions avec
l'environnent

" Classement des exigences
# fonctionnelle/non-fonctionnelle, primaire/dpendante, produit/
process, priorit (obligatoire/trs souhaitable/souhaitable/
optionnelle), porte (globale/limite), stable/volutive
" Modlisation
# Dpend de la nature du logiciel dvelopper, du client, des outils
disponibles. L'usage d'UML est le plus frquent. Permet d'affiner les
exigences
Les activits
de base
Les exigences
40
! Analyse des exigences

" tablissement de l'architecture et allocation des
exigences
# Est une anticipation de la conception. Parfois ncessaire
(rpartition du logiciel sur diffrents composants
hardware).
" Ngociation des exigences
# En cas de contradiction, de non-faisabilit, de contraintes
non fondes, etc.
Les activits
de base
Les exigences
41
! Spcifications des exigences
Il s'agit de la mise en forme et des adjonctions
ncessaires l'informatisation
" Spcifications des exigences systme
# Sont hors cadre mais lorsqu'elles existent, elles prcdent
les exigences logiciel
" Spcifications des exigences logiciel
# Le plus souvent crites en langage naturel, mais peuvent
tre compltes par des descriptions formelles.
Elles doivent tre le plus prcises possible.
Les activits
de base
Les exigences
42
! Validation des exigences

L'objectif est de s'assurer que les exigences sont
comprhensibles, faisables, cohrentes et compltes
" Revue des exigences
# Voir Qualit
" Prototypage
# Permet de rendre visible rapidement la comprhension des exigences
par l'quipe de ralisation. Mais a un cot !
" Tests de recette
# Les exigences doivent pouvoir tre testes. Voir Tests
Les activits
de base
Les exigences
43
! Gestion des exigences

La gestion des exigences est un processus itratif :
dualit logiciel dvelopper / logiciel tel que
dvelopp
" Gestion des modifications (changements)
# Voir Gestion de la Configuration Logiciel
" Traabilit des exigences
Matrice de traabilit
# Traabilit amont : vers spcifications systme
# Traabilit aval : vers conception, codage, tests
" Mesures des exigences
# Voir Gestion de projet
Les activits
de base
Les exigences
44
! En rsum

" Analyse : recueil, classement, ngociation

" Spcifications : formalisation d'exigences identifies
individuellement, faisables, quantifiables, testables.
C'est le point de dpart de la matrice de traabilit

" Validation : revue, prototypage
Les activits
de base
Les exigences
45
Les activits
de base
Gnie Logiciel
La conception
La conception
47
! Objectif de la conception :
" Analyser les exigences pour produire une description de la
structure interne du logiciel permettant sa ralisation

" Choisir parmi les diffrentes solutions possibles la plus
efficace et la plus adapte

! Elle se dcompose en deux niveaux :
" Conception architecturale (ou prliminaire)
" Conception dtaille : contenu des composants (en gnral
fait lors de ralisation)
Les activits
de base
La conception
48
! Les activits de conception dpendent fortement des
mthodes et langages utiliss.

! Nanmoins on retrouve systmatiquement les
lments suivants :
" Problmes cls
" Les techniques d'analyse et d'valuation de la qualit de la
conception
" Les stratgies et mthodes mettre en uvre
Les activits
de base
La conception
49
! Problmes cl de la conception logiciel
" Paralllisme
# Dcomposer le logiciel en processus, tches et composants en traitant
des problmes d'efficacit, granularit, synchronisation et
squencement
" Gestion des vnements
# Organiser les donnes et les flux en optimisant les vnements
associs
" Rpartition des composants logiciels sur le systme
# Distribuer le logiciel sur les composants matriels, grer les
communications entre eux et avec le systme
" Gestion des erreurs et exceptions : tolrance aux dfauts
# Prvenir et tolrer les dfauts et traiter les exceptions
" Conservation des donnes
# Dterminer la durer de vie des donnes
Les activits
de base
La conception
50
! Analyse et valuation de la qualit de la
conception logiciel
" Techniques d'analyse et d'valuation de la qualit
# Revues (Voir Qualit)
# Analyse statique (Voir Qualit)
# Simulation et/ou prototypage
" Mesures
Elles sont classes en deux catgories
# Orientes fonctions
# Orientes objet
Les activits
de base
La conception
51
! Stratgies et mthodes de la conception logiciel :
" Stratgies gnrales
# Raffinage pas pas, top-down, bottom-up, modlisation,
approche incrmentale
" Conception oriente fonctions
# En partant des fonctions identifies lors des spcifications et en
procdant un raffinage top-down
" Conception oriente objet
# La plus utilise
Les activits
de base
La conception
52
! Stratgies et mthodes de la conception logiciel :
" Conception centre sur la structure des donnes
# Utilise dans le cas o les donnes sont prdominantes (base de
donnes)
" Conception base sur les composants
# Lorsque l'indpendance du composant est primordiale
(rutilisation, composant commun plusieurs utilisateurs)
Les activits
de base
La conception
53
! En rsum : concevoir c'est dfinir :

" Une architecture, en tenant compte des contraintes
% Conception prliminaire

" Des algorithmes simples, efficaces et documents
% Conception dtaille

" Tout en construisant la traabilit, la testabilit
Les activits
de base
La conception
54
Les activits
de base
Gnie Logiciel
La ralisation
La ralisation
56
! Gnralits
" La ralisation inclut souvent la conception dtaille (CD), le
codage et les tests unitaires. Elle peut comporter de plus un
premier niveau de tests d'intgration (groupe de composants)
" De ce fait la ralisation est trs fortement lie aux activits
de conception et aux activits de tests
" La ralisation est l'activit qui gnre le plus grand nombre
d'items (documents de conception dtaille, fichiers sources,
cas de tests, etc.).
Lien trs fort avec la gestion de configuration
Les activits
de base
La ralisation
57
! La ralisation s'appuie sur
" Des fondamentaux

" Des activits type
Les activits
de base
La ralisation
58
! Fondamentaux
" Diminution de la complexit
# Au niveau de la conception dtaille et du codage. Facilite la
comprhension, la vrification, les tests
" Anticipation des changements
# Mthodes de communication internes et externes l'quipe,
standardisation des interfaces
" Construction de la vrification
# Privilgier la simplicit, la comprhensibilit, la facilit de tests
" Utilisation de standards
# L'utilisation de standards diminue la complexit, facilite la
communication et permet de privilgier des solutions prouves
Les activits
de base
La ralisation
59
! Activits type
" Conception dtaille
# Il s'agit de la conception interne chaque composant.
!! Peut entrainer des modifications dans la conception de
plus haut niveau !!
" Choix des langages
# Il est souvent conditionn par les choix faits lors des
activits prcdentes et par les contraintes associes au
logiciel.
Peut tre impos par le client
Les activits
de base
La ralisation
60
! Activits type
" Codage
# Peut tre en partie automatis (dpend des langages
utiliss lors de la conception).
# Les rgles respecter
& Crer un code comprhensible : standards de nommage,
mise en page, utilisation de classes,
& Manipulation des erreurs (prvisibles et exceptions)
& Documentation du code
& Organisation du code source (modules, sous-
programmes, classes, ...)
Les activits
de base
La ralisation
61
! Activits types
" Tests
# Inclut les tests unitaires et le premier niveau de tests
d'intgration. (voir Tests)
" Rutilisation
# Implique les tches suivantes
& Slection des items potentiellement rutilisables : modules de
codes, bases de donnes, procdures de tests, donnes de tests
& valuation de la rutilisabilit : nulle, partielle, totale
" Intgration
# Planification du squencement de l'intgration, suivi de la
configuration, tests de non rgression
Les activits
de base
La ralisation
62
! Raliser

" Souvent plusieurs acteurs en parallle
"Planification

" Gestion des interfaces techniques et
organisationnelles
"Modifications non contrles
Les activits
de base
!
!
La ralisation
63
Les activits
de base
Intgration
Gnie Logiciel
Les tests
Les tests
65
! Une anomalie est identifie si le rsultat obtenu n'est pas le
rsultat attendu.
L'anomalie est la manifestation d'un dfaut (dans le code, la
conception, les exigences, le jeu de tests, etc.) ou d'une erreur
de manipulation.

! Les tests mettent en vidence des anomalies. L'ingnieur
logiciel doit identifier le dfaut (les dfauts) cause de cette
anomalie pour pouvoir le corriger.

Les activits
de base
Les tests
66
! Aucun tests ne peut tre exhaustif. (Les tests
permettent de dtecter des anomalies mais ne
peuvent pas prouver l'absence de dfauts).

! Les deux questions qui se posent :
" Comment slectionner le jeu de tests le plus efficace (qui dtecte le maximum
d'anomalies) ?
" Comment dterminer que l'on peut arrter de tester (la probabilit de dfauts
rsiduels pouvant tre considre comme ngligeable) ?
Les activits
de base
Les tests
67
! Niveaux de tests
" Nature des tests
# 3 natures de tests sont gnralement reconnues
& Tests unitaires
& Test d'intgration
& Tests systme

" Objectifs des tests
Il est gnralement plus efficace de cibler une campagne de tests
sur des objectifs prcis.
# Tests de conformit, fonctionnels (tous tests)
par rapport au rfrentiel adquat
# Tests de recette/qualification (tests systme)
conformit aux exigences
Les activits
de base
Les tests
68
! Niveaux de tests
" Objectifs des tests
# Tests d'installation ou de prproduction (tests systme)
capacit fonctionner dans l'environnement
oprationnel
# Alpha et Beta tests (tests systme)
tests par les utilisateurs dans l'environnement
oprationnel
# Tests de fiabilit (tests systme)
jeux de tests alatoires
# Tests de non rgression (tous tests)
consiste r-excuter aprs modification des tests
dj raliss
Les activits
de base
Les tests
69
! Niveaux de tests
" Objectifs des tests
# Tests de performance (tests unitaires et systme)
capacit, temps de rponse, temps d'excution
# Stress tests (tests systme)
en allant au del des limites
# Tests aprs remise en service (tests systme)
vrification d'intgrit

En fonction de l'objectif les jeux de test peuvent tre
diffrents.
Les activits
de base
Les tests
70
! Techniques de tests

" Bases sur l'intuition et l'exprience des testeurs (tous tests)
# Les plus largement utilises. L'absence de formalisation permet
difficilement d'en valuer l'efficacit " monkey test !

" Bases sur les spcifications (tous tests)
# Tests de domaines
les donnes d'entre sont regroupes en classes (par exemple : donnes
valides, valeurs limites, valeurs hors limite).
& Tests unitaires : constituer des ensembles de valeurs appartenant chacune
des classes prcdentes et raliser les tests pour chacun de ces ensembles
& Tests d'intgration et systme : pratiquer de mme pour chacune des
fonctions du logiciel

Les activits
de base
Les tests
71
! Techniques de tests

" Bases sur les spcifications (tous tests)
# Tables de dcision
une table de dcision va tablir les liens entre les entres (conditions)
et les sorties (rsultats des actions) : les cas de tests sont tablis
partir de toutes les combinaisons possibles d'entres et de sorties
# Tests alatoires : en introduisant des valeurs d'entre gnres
alatoirement

Les activits
de base
Les tests
72
! Tests bass sur les spcifications

Appels aussi boite noire
" Le testeur n'a aucune visibilit sur le contenu du produit test
" Il n'a accs qu' l'IHM et certains fichiers utiliss par le logiciel
" La stratgie de tests peut tre :
# Tester toutes les valeurs d'entre possibles : le temps ncessaire tend vers
l'infini
# Regrouper les valeurs d'entre en classe d'quivalence. Cela ncessite
une comprhension du logiciel test
Les activits
de base
Les tests
73
! Tests bass sur les spcifications
Appels aussi boite noire
" Quelques exemples :
# Entre est un n de mois 1-12
Il y a 3 classes d'quivalences : [-!..0], [1..12], [13..!]
# Entre est vrai ou faux
Il y a 3 classes d'quivalences : [vrai], [faux], [xxx]
# Entre est un nombre entier >0 :
Il y a 4 classes d'quivalences : [Nb <0], [0], [Nb entier >0], [Nb non
entier >0]
# Etc.
Les activits
de base
Les tests
74
! Techniques de tests
" Bases sur le code
# Ils ont pour but de parcourir l'ensemble des instructions composant un
module (tests unitaires) ou l'ensemble des appels entre modules (tests
d'intgration et de recette) (notion de branches)
# Des outils permettent (pour certains langages) de d'aider la
gnration des jeux de tests associs
Les activits
de base
Les tests
75
! Tests bass sur le code
Appels aussi boite blanche
" Le testeur a accs au code source
" Le testeur peut savoir quelles parties du programme ont t
excutes
" On identifie ainsi :
# Des branches : squence continue d'instruction ( l'intrieur d'un module) ou
squence continue de modules
# Des nuds : toute rupture de branche (condition, boucle, appel sous-
programme, ...)
# Des chemins : succession de branches et de nuds permettant d'aller d'un
point d'entre un point de sortie
Les activits
de base
Les tests
76
! Tests bass sur le code
Appels aussi boite blanche
" La stratgie de tests peut tre :
# Parcourir l'ensemble des chemins (gnralement impossible)
# Parcourir l'ensemble des branches (le plus efficace)
# Parcourir l'ensemble des nuds (le plus simple)
# En gnral on choisira de parcourir les chemins qui permettent de
parcourir au moins une fois l'ensemble des branches et des nuds
Les activits
de base
Les tests
77
! Techniques de tests
" Bases sur les dfauts (tous tests)
# Soit en recherchant des dfauts spcifiques (les plus courants, par
exemple)
# Soit en en gnrant des dfauts volontaires et en vrifiant qu'ils
sont dtects par les jeux de tests.
A manipuler avec prcaution

Les activits
de base
Les tests
78
! Tests bass sur les dfauts
" Dfaut : conditions logiques (boucles, If-then-else)
Stratgie de tests : considrer comme une entre chaque variable
utilise dans une rgle ou une condition logique et partitionner ses
diffrentes valeurs en classes
ex. une boucle 0..4 : excuter pour n=0, n=1, n=4 n<0, n>4,
n=3,5
Vrifier que le nombre de boucles excutes est correct
" Dfaut : un algorithme ne doit s'excuter que si une prcondition
est vrifie.
Stratgie de test : tester les cas o la prcondition n'est pas
satisfaite
Les activits
de base
Les tests
79
! Tests bass sur les dfauts
" Dfaut : condition =0 qui logiquement ne doit pas exister
ex. traitement d'un tableau, cas du tableau vide
Stratgie de tests : faire un brain storming (remue mninges)
pour dterminer les occurrences possibles et faire les tests
appropris

" Dfaut : calculs numriques errons : parenthse mal place,
nombres de chiffres aprs la virgule suprieurs aux tailles
prvues, nombre trop grand
Stratgie de tests : faire des calculs impliquant ce type de
cas de figure et vrifier les rsultats

Normalement cela doit donner lieu une exception
Les activits
de base
Les tests
80
! Techniques de tests
" Bases sur la nature de l'application
# Certains type d'application (temps rel, programmes simultans,
logiciels critiques) ncessitent des tests complmentaires
" Bases sur un mlange des techniques
# Le plus souvent les jeux de tests sont tablis en combinant plusieurs
techniques ci-dessus
Les activits
de base
Les tests
81
! Techniques et objectifs de tests
" Les jeux de tests vont tre tablis en slectionnant les techniques
adquates et les objectifs recherchs.

L'exprience prouve que 20 40% du code n'est jamais test :
# Utilisation de la matrice de traabilit

Spec!Conception!Codage!Tests unitaires!Tests
d'intgration!Tests de recette

# Utilisation d'analyseurs dynamiques
Les activits
de base
Les tests
82
! Droulement des tests
" Excuter les cas de tests prvus
" Si anomalie
# tablir un rapport d'anomalie
# Dfinir une priorit
# Rechercher les causes (le dfaut). Par le testeur (tests unitaires) ou par
une personne indpendante de l'quipe de tests (autres tests)
# Corriger le dfaut
# Gnrer priodiquement une nouvelle version (tous les n jours ou tous
les x dfauts corrigs)
" Identifier et effectuer les tests de non rgression appropris
Les activits
de base
Les tests
83
! Liens entre nature des tests et techniques de tests

" Tests unitaires
Il est souvent prfrable d'effectuer une lecture croise des cas de tests
avant de commencer les tests

Faire ensuite des tests de domaine, complts par des tests de chemin +
ventuellement des tests bass sur les dfauts

" Test dIntgration
Il est souvent prfrable d'effectuer une lecture croise des cas de tests
avant de commencer les tests

Faire ensuite des tests de domaine, complts par des tests de branches
(vrification des interfaces) + ventuellement des tests alatoires
Les activits
de base
Les tests
84
! Liens entre nature des tests et techniques de tests

" Validation :
Des tests de domaine (fonctionnels) complts par des tests alatoires.
La vrification du Manuel utilisateur.
Des stress tests

" Tests d'installation ou de prproduction :
Un sous ensemble des tests de validation orient interfaces avec le
systme d'exploitation et les autres logiciels, le cas chant
Les activits
de base
Les tests
85
! Mesures associes aux tests
" valuation des tests effectus
# Taux d'erreurs (bloquantes, majeures, mineures) trouv par
campagne de tests
# Taux d'erreurs pour 1000 lignes
# Taux de couverture
# Modles de croissance de la fiabilit
" valuation du programme test
A partir
# De l'volution du taux d'erreurs par campagne
# Du taux de couverture
# Du niveau de fiabilit atteint
Les activits
de base
Les tests
86
! Les activits de tests reprsentent 40 60% de la charge d'un projet.
Elles doivent donc tre soigneusement planifies et suivies.
! Les documents cl de cette activit :
" Spcification de l'environnement et des outils de tests
" Spcification des cas de tests
" Critres d'arrt des tests
" Plan de tests (incluant l'organisation)
" Rapports de tests
! Voir Plan de Projet
Les activits
de base
Les tests
87
Les activits
de base
Gnie Logiciel
La qualit
La qualit
89
! Diverses dfinition de la qualit ont t
donnes

" Conformit aux exigences de l'utilisateur (Crosby)
" Satisfaction des utilisateurs (Baldrige)
" Aptitude d'un ensemble de caractristiques intrinsques satisfaire des
exigences (ISO 9001)
Les activits
de base
La qualit
90
! La qualit est un attribut du produit

! Il sagit dun objectif a atteindre

! La dmarche qualit, les plans qualit, le systme qualit sont
des moyens pour atteindre cet objectif.

! Les indicateurs, tableaux de bord, enqutes de satisfaction sont
des moyens de mesure
Les activits
de base
La qualit
91
! LA QUALIT RSULTE TOUJOURS D'UN COMPROMIS ENTRE :
Ce qu'il est possible de faire

et

Ce qu'il est souhaitable de faire
Ce que le Ralisateur peut faire

et
Ce que le Client est prt payer
Les activits
de base
Les activits
de base
EXIGENCES
FONCTIONNELLES
COTS
EXIGENCES
NON FONCTIONNELLES
Produit
Service
DLAIS
Les Quatre lments
La qualit
92
- respecter les rgles de scurit
- raliser la documentation en
anglais
- assurer une fiabilit permettant
une garantie de 3 ans
- respecter les standards
rglementaires
- Comporter 5 places assises
- Rouler plus de 100 km/h
- Avoir un moteur, 4 roues,

93
DEFINITION :

& Cest la somme des
diffrences entre le service
attendu par lutilisateur et le
service rendu par le produit
(ou le service) fourni
Qualit externe

& C'est la diffrence entre ce
qui a t fait et ce qui aurait
d tre fait
Qualit interne
Tel un Iceberg :
Cots
visibles
Cots
cachs
Erreurs, bugs,
pannes, retards,
rclamations clients
Travaux inutiles,
manque de rigueur,
renseignements errons,
validation en retard,
rendez vous annuls au dernier moment,
choix initiaux remis en cause,
lourdeur du circuit de validation des
demandes d'achat,
manque de disponibilit,
perfectionnisme
Plus une anomalie est
dcouverte tardivement, plus
elle cote cher
Les activits
de base
La qualit
La qualit
94
! L'exprience industrielle montre que tout organisme cherchant a
obtenir un produit de qualit dans des conditions de cots et de
dlais matrisables passe par les cinq phases suivantes :
! INCERTITUDE
! VEIL
! RECTIFICATION (PRISE DE CONSCIENCE)
! PRVENTION (SAGESSE)
! CERTITUDE
Les activits
de base
La qualit
95
! INCERTITUDE
! Nous avons des problmes avec la qualit mais nous ne cherchons pas savoir
pourquoi.

! VEIL
! Nous savons que nous ne faisons pas ce qu'il faut mais nous n'avons pas trouv
quoi faire d'autre.

! RECTIFICATION (Prise de conscience)
! Nous entreprenons des actions systmatiques de correction (a posteriori).
Les activits
de base
La qualit
96
! PRVENTION (Sagesse)
& Nous entreprenons des actions systmatiques de prvention (a priori)




! CERTITUDE
& Nous n'avons pas de problmes avec la qualit et nous savons pourquoi
Les activits
de base
La qualit
97
! Fondamentaux
" Caractristiques qualit

Afin de donner des critres d'apprciation partags,
une norme internationale a t publie dfinissant
six caractristiques majeures qui peuvent tre
attribues un logiciel
Les activits
de base
La qualit
98
Le plan de Projet
PORTABILIT
RENDEMENT
(DISPONIBILIT)
FACILIT
D'UTILISATION
FIABILIT
(INTEGRITE)
MAINTENA-
BILIT
CONFORMITE
FONCTION-
NELLE
" Caractristiques qualit
La qualit
99
Le plan de Projet
Maintenabilit
facilit
d'analyse
facilit de
modification
stabilit
facilit de
test
Facilit
d'utilisation
facilit de
comprhension
facilit
d'apprentissage
facilit
d'exploitation
par les
utilisateurs
Fiabilit
(Intgrit)
maturit
tolrance aux
dfauts
possibilits de
rcupration
Conformit
fonctionnelle
aptitude
conformit
aux
besoins de
l'utilisateur

interoprabilit
conformit
rglementaire
Confidentialit
scurit
(d'accs)
Rendement
(Disponibilit)
comportement
vis vis du
temps
comportement
vis vis des
ressources
Portabilit
facilit
d'adaptation
facilit
l'installation
conformit
aux rgles
de portabilit
interchan-
geabilit
" Caractristiques qualit
La qualit
100
" Caractristiques qualit
# Pour chacune, valuation si son importance est majeure ou
mineure.

# Lien avec le SLA ventuel

# Identification des actions spcifiques mener pour
respecter les exigences correspondantes (Cf. plan de
projet)

# Identification des moyens permettant de vrifier que ces
caractristiques seront satisfaites
Le plan de Projet
La qualit
101
! Fondamentaux
" Amlioration de la qualit
La dmarche damlioration continue est applicable
chaque activit. Elle est illustre par la roue de DEMING



80Le PDCA
8 0Plan (prvoir)
8 0Do (faire)
8 0Check (vrifier)
8 0Act (agir, amliorer)
Les activits
de base
Amlioration SMQ
S
M
Q

La qualit
102
" Cette dmarche constitue l'ossature de :

# ISO 9001 : norme gnraliste

# ISO 9100 : variante de l'ISO 9001 pour l'aronautique

# TS 16949 : variante de l'ISO 9001 pour l'automobile

" La notion de recherche des causes racines lors de la mise en
uvre des actions correctives et prventives est fondamentale
Le plan de Projet
La qualit
103
! Processus de gestion de la qualit du logiciel
" Vrification et validation (V&V)
Vrification :
le produit rsultat de l'activit (document, code excutable,
etc.) est conforme aux exigences
Validation :
le produit rsultat de l'activit correspond aux besoins de
l'utilisateur

# Dans un monde idal, les deux sont confondues
Les activits
de base
La qualit
104
! Processus de gestion de la qualit du logiciel
" Vrification et validation (V&V)
# La technique utilise peut tre la mme, c'est le rfrentiel qui est
diffrent

# Les tests sont une des techniques de V&V

# La relecture et l'analyse documentaire en est une autre
Les activits
de base
Les activits de
vrification/validation
105
! Les activits de vrification :
" Lectures croises et inspections
" Tests unitaires, d'intgration
" Certaines revues de projet

! Les activits de validation
" Le maquettage/prototypage
" Les tests de validation (recette)
" Certaines revues de projet
Les activits de
base
Lectures croises et
inspections
106
! Elles sont bases sur le cycle auteur-lecteur
Les activits de
base
Commentaires
Lecteur
Auteur
Document
Corrections mineures
Remarques et questions
Lectures croises et
inspections
107
! Bien que similaires elles diffrent sur plusieurs points majeurs
" Lecture croise : interne l'quipe (utilise les comptences de l'quipe),
n'implique pas forcment une runion,

" Inspection : fait intervenir des personnes extrieures l'quipe
(comptences non prsentes ou ncessit d'un regard extrieur), se
droule gnralement sous forme de runion

! Dans tous les cas le document examin doit tre termin et
considr comme dfinitif par son auteur

Il s'agit d'une vrification et non d'une aide l'laboration
Les activits de
base
Les lectures croises
108
! Objectifs :
" Trouver les dfauts
" Amliorer le logiciel
" Envisager des solutions alternatives
" valuer la conformit aux standards et aux spcifications
Les activits de
base
109
! Exemples de points rechercher dans du code
" commentaires utiles ?
i := i + 1 (* incrmentation du compteur i *)
" le code a-t-il des points et utilitaires de traabilit
" le nommage des identificateurs est-il comprhensible ?
" code lisible (structur) ?
" grand nombre de littraux dans le code ?
if (choices = 2) then answer := a ;

Le jour o on veut remplacer 2 par 3 il faut parcourir
l ensemble du code pour dtecter les apparitions de 2, puis
se demander si il est bien la valeur d une variable que lon
veut modifier : nb de jours ?de mois ?
Les activits de
base
Les lectures croises
110
! Droulement
Les activits de
base
ETAPE Quand ?
1 Auteur fournit document au lecteur T0-2j
2
3 T0
4 T0+1j
Lecteur lit document
*corrige les dfauts mineurs
*crit ses remarques et questions sur le document
ou remplit une Fiche de Fait Technique (FFT)
T0-2j

T0
Lecteur retourne document l'auteur (avec FFT le
cas chant) ou runion avec l'auteur
Auteur effectue corrections et/ou envoie
commentaires au lecteur
Les lectures croises
111
! Conditions de droulement

" Respecter la dure des 3 jours (taille du document limite)
" Lecteur et auteur appartiennent la mme quipe
" Le lecteur ne doit pas tre systmatiquement le chef de projet
" Les remarques doivent concerner le document et non l'auteur
" Les remarques doivent tre justifies
" La recherche de dfauts n'est pas limite une catgorie donne
" Ces actions doivent tre planifies et prvues au budget (~2h pour 40
pages ou 500 lignes de code + temps ventuel de la runion)
Les activits de
base
Les lectures croises
Inspections
112
! Objectifs
" Identifier des dfauts

! Conditions de mise en uvre
" Fait intervenir des spcialistes externes l'quipe
" Tout un document, mais sur un point particulier (interfaces, par
exemple)
" Un sous-ensemble, tous azimuts
" Des checks lists de dfauts lis l'objectif peuvent tre
utilises
Les activits de
base
Inspections
113
! Droulement
Les activits de
base
Auteur fournit document aux inspecteurs T0-7j
T0
T0
T0+3j
T0+5j
Chaque inspecteur lit document et note les dfauts
identifis
T0-7j

T0
Runion entre l'auteur, les inspecteurs et un lecteur :
Le lecteur lit le document voix haute
Inspecteurs indiquent les dfauts, ce qui peut amener
une discussion avec l'auteur
Ils peuvent proposer une solution
Auteur effectue corrections sous la supervision d'un
des inspecteurs
Le deuxime inspecteur effectue la vrification des
corrections
Inspections
114
! Conditions de droulement

" Dure infrieure 2 semaines
" Souvent associ la recherche de dfaut cibl (portabilit, sret de
fonctionnement, maintenabilit, respect des normes, ...)
" Inspecteurs externes l'quipe projet et spcialistes du domaine
" L'inspection peut porter sur l'ensemble d'un document ou sur un
chantillonnage
" La correction des dfauts est pilote par les inspecteurs qui vrifient
ensuite le document corrig
" Inspections doivent tre planifies et prvues au budget (10 pages de
texte par heure ou 200 lignes de code par heure lors de la runion +
temps de prparation)
Les activits de
base
Inspections
115
! Rappel sur les participants
" Au moins 2 inspecteurs, spcialistes dans le domaine concern
par les documents inspecter
" L'auteur
" Un animateur de la runion (chef de projet, resp. qualit, )
qui est responsable du bon droulement de la runion et qui
va noter les dfauts identifis et les ventuelles solutions
proposes.
" Le lecteur qui lira le document lors de la runion, qui peut
tre l'auteur
Les activits de
base
Inspections
116
! Documents inspecter
" Si possible le plan de tests, quel que soit le logiciel
" Pour des logiciels critiques
# Les spcifications + matrice de traabilit (au dbut du projet et
ventuellement avant la validation finale)
# La conception et le code des parties critiques
# Le plan de tests
! Choisir les inspecteurs en fonction de leurs comptences
et s'assurer de leur disponibilit
Les activits de
base
Inspections
117
! viter les discussions sur la nature de la correction, si celle-ci n'est
pas vidente

! viter les discussions sur la forme, se concentrer sur le fond

! Respecter les rgles concernant les runions (dure, )

! Conserver le compte rendu de la runion

! Refaire une inspection aprs correction si celles-ci sont
importantes
Les activits de
base
Inspections
118
! Comme pour les Lectures Croises
" Les inspecteurs ne sont pas l pour porter un
jugement

" L'objectif est de travailler ensemble pour amliorer
le document

Les activits de
base
Lectures croises et
inspections
119
! Mise en uvre












(1) sur un sous ensemble des dossiers de tests
Les activits de
base
Niveau des exigences
Fort Moyen Faible
Spcification LC multiples LC LC
Conception LC multiples LC //
Code
//
LC
LC multiples LC LC
LC LC LC
LC multiples
ou
Inspection
LC ou
Inspection
Dossiers
de tests
LC ou
Inspection LC
(1)
Cahier de
recette
Manuel
utilisateur
La qualit
120
! Processus de gestion de la qualit du logiciel
" Revues
# Une revue comporte gnralement 2 volets
& Un volet technique : validation des produits examins
& Un volet de gestion : validation du processus projet mis
en uvre
# Se reporter au module gestion de projet
Les activits
de base
La qualit
121
! Processus de gestion de la qualit du logiciel
" Audits
# Le but d'un audit est de fournir une valuation
indpendante de la conformit des produits et processus
mis en uvre aux rgles, normes, standards, plans et
procdures applicables

# Les auditeurs sont extrieurs l'quipe projet

# Les auditeurs fournissent un rapport indiquant les points
forts, les points amliorer et les points corriger
Les activits
de base
La qualit
122
! Mise en uvre
" Caractrisation des dfauts
Afin de limiter les incomprhensions les dfinitions
suivantes sont gnralement admises
# Anomalie : diffrence entre le rsultat obtenu et le
rsultat attendu
# Dfaut : une portion de programme, un process, une
dfinition de donne incorrecte identifie dans un logiciel.
Le dfaut produit gnralement une anomalie
# Erreur : une action humaine produisant un rsultat erron
(anomalie ou dfaut)
Les activits
de base
La qualit
123
! Mise en uvre
" Techniques de V&V
# Techniques statiques : examen de la documentation du
projet et du code source. Elles se prsentent sous deux
formes :
& Runion plus ou moins formelle permettant un examen
contradictoire d'un document au moins 2 participants). Peut
s'appuyer sur des check lists et/ou sur le rsultats de techniques
analytiques (LC : auteur + lecteur, ou inspection).
& Techniques analytiques : s'appuient sur des outils
' Analyseurs de complexit
' Analyseurs d'algorithmes
' Analyseurs de flux
Les activits
de base
La qualit
124
! Mise en uvre
" Techniques de V&V
# Techniques dynamiques : s'appuient aussi sur des outils:
simulateurs, outil d'excution symbolique.
Toutefois un ingnieur expriment peut, en lisant un code
source, drouler les instructions en simulant intellectuellement
leur excution.
# Tests : Cf. chapitre correspondant
Les activits
de base
La qualit
125
! Mesures
# Elles ont pour but :
& Aide la dcision (par ex. arrt des tests)
& Identification de problmes potentiels
& valuation objective des rsultats obtenus
# Elles consistent :
& Mesures directes : nb de dfauts (identifis lors des LC-
Inspections, des tests, en exploitation), le pourcentage de code
rutilis, le nombre de questions poses par les utilisateurs
& Statistiques : Pareto
& Analyses de tendance : courbe en S
& Prdiction : modle de croissance de la fiabilit
Les activits
de base
Complmentarit des
actions de vrification
126
! Les actions de vrification doivent tre planifies globalement
car elles sont fortement lies.

! D'une part les tests dpendent fortement des actions de
vrification faites en amont (LC, Inspections, Revues) ;
" Un mme dfaut peut tre identifi lors d'une inspection (ou LC) ou par un
tests
" Certain dfauts ne peuvent tre dtects que par une inspection ou une
LC

! D'autre part chaque type de tests est partiellement redondant
avec les autres types
Les activits de
base
Complmentarit des
actions de vrification
127
! Redondance des tests

" Chaque test se traduit par une excution du logiciel

Il est donc important de savoir quelle partie du logiciel n'a
pas t excute lors des tests
A l'aveugle des enqutes ont montr que 40 60 % des
instructions n'avaient pas t excutes lors des tests
Les activits de
base
Complmentarit des
actions de vrification
128
! Complmentarit entre les tests et les LC,
inspections et Revues

" Les tests sont d'autant plus efficaces et prennent
d'autant moins de temps que le nombre d'erreurs est
faible
Les activits de
base
Complmentarit des
actions de vrification
129
! En effet la dmarche de test est la suivante :
# ( Dfinition des jeux de tests
# ) Excution des jeux de tests
# * Identification des anomalies
# + Recherche de la cause de l'anomalie
# , Correction
# - R-excution du jeu de test (non-rgression)
# . Si anomalie, repartir en *.
" Les tapes 3 7 prennent de 2 3 fois le temps pass en 1 et
2. Plus il y a de dfauts plus cela prend de temps
! D'o la ncessit des contrles en amont
Les activits de
base
Complmentarit des
actions de vrification
130
! Une tude avait donn les rsultats suivants :
Les activits de
base
Type d'action Temps pass (en %)
17% 45%
8% 45%
Tests
75% 10%
Nbre de dfauts
Dtect (en %)
LC sur
document de
conception
LC sur
listing de
code
Complmentarit des
actions de vrification
131
! Actions de vrification possibles selon les activits
Les activits de
base
Inspections Mtriques
X X
X X X
X X X X X X X
Codage X X X X X
Tests unitaires X X
Intgration X
Validation
Analyse
du flot
de
contrle
Analyse
du flot de
donnes
Analyse
statique
Check
lists
Excution
symbolique
Lectures
croises
Analyse des
exigences
Spcifications
Conception
Prliminaire
Conception
dtaille
Complmentarit des
actions de vrification
132
! Actions de vrification possibles selon les activits
Les activits de
base
Revues Simulation
X
X
Codage
Tests unitaires X X X
Intgration X X X X
Validation X X X X
Stress
tests
Tests
alatoires
Tests
bass
sur le
code
Tests de
domaine
Tests de
performance
Tests
fonctionnels
Analyse des
exigences
Spcifications
Conception
Prliminaire
Conception
dtaille
Gnie Logiciel
La gestion de configuration
La gestion de configuration
134
! On appelle configuration l'ensemble des produits labors
par l'quipe projet. Les outils utiliss peuvent parfois tre
inclus dans la configuration.

! En font partie :
" Les documents techniques : spcifications, conception, dossiers de tests
" Le code source et objet, les paramtres (pour un progiciel), les instructions de contrle
" Les diffrents plans
" Les CR de lectures croises, d'inspections, de Revue, d'audit
" Les compilateurs, outils d'aide aux tests, la conception, etc
" Le matriel

Les activits
de base
La gestion de configuration
135
! Prparation de la gestion de configuration

La GCL comporte deux volets :
# En cours de dveloppement du logiciel (dans le cadre de la gestion du projet)

# Lors de l'exploitation du logiciel (dans le cadre de la maintenance et de la
gestion des problmes) : gestion des configurations installes (Voir
Exploitation)
Les activits
de base
La gestion de configuration
136
! Prparation de la gestion de configuration
" Contexte organisationnel
# Nomination d'un responsable de la GCL
# tablissement de liens avec la GC matriel dans le cas d'un logiciel intgr
dans un quipement
# tablissement de liens avec la Gestion des Configurations Installes
(Exploitation) si logiciel sur serveur ou Mainframe
# Prise en compte de la criticit du logiciel
# tablissement de liens avec la gestion des changements en cours de projet et
en exploitation
" Planification de la GCL
# Elle est intgre la planification du projet ou de la maintenance et dpend
de la dmarche mise en uvre. Elle comprend
& L'organisation mise en place
& L'identification des tches et leurs liens
avec les tches du projet
Les activits
de base
La gestion de configuration
137
! Prparation de la gestion de configuration
" Plan de GCL
# Introduction (objectifs, terminologie utilise)
# Organisation de la GCL
# Tches de la GCL
# Planning de la GCL, incluant les liens au planning projet ou de
maintenance
# Ressources : outils, moyens matriels, ressources humaines
# Procdure de mise jour du plan
Les activits
de base
La gestion de configuration
138
! Identification de la configuration grer
" Identification des composants grer
# Un composant de la configuration logiciel est le plus petit lment
gr. Son contenu peut tre trs variable d'un projet l'autre
# Un composant peut tre un document (ou une partie de document), du
code source, du code objet, des jeux de tests, tout ou partie des outils
utiliss
# L'identification des composants s'accompagne de l'identification des
liens entre composants
# Chaque volution d'un composant donne lieu une nouvelle version
de ce composant :
& Une rvision est une version qui annule et remplace la
prcdente
& Une variante est une version qui va vivre en parallle avec la
prcdente

Les activits
de base
La gestion de configuration
139
! Identification de la configuration grer
" Identification des composants grer
# Un rfrentiel de configuration est constitu par un ensemble cohrent de
composants :
& Rfrentiel fonctionnel : l'issue de la Revue des exigences systme
& Rfrentiel de base : l'issue de la Revue des exigences logiciel
& Rfrentiel de dveloppement : les diffrentes versions de la configuration
au cours du projet
& Rfrentiel produit : versions livres ou en exploitation
Chaque rfrentiel est formellement valid (Revues)
" Bibliothque de logiciels
# Contient les diffrents rfrentiels et les composants du rfrentiel en cours
de dveloppement
Les activits
de base
La gestion de configuration
140
! Matrise du statut de la configuration
" Centralisation, valuation et approbation des changements
# Rception d'une demande de changement
# Analyse de sa recevabilit : cohrence avec l'existant, absence de
risque (en cas de rutilisation, d'interfaces avec d'autres appli, )
# Validation ou rejet
" Ralisation de la modification
# Rception du composant modifi
# Vrification
# Mise jour de la configuration
Les activits
de base
La gestion de configuration
141
! Matrise du statut de la configuration
" Statut de la configuration
# Peut tre gnr automatiquement. Dpend de l'outil utilis

# Ce statut comporte au moins les informations suivantes
& Liste des composants constituant chaque rfrentiel
& tat de chaque composant : intgr un rfrentiel, valid, en cours
de modification
Les activits
de base
La gestion de configuration
142
! Suivi de la mise en uvre de la GCL
" Audits fonctionnels de la configuration
# Vrification de la cohrence des composants avec les spcifications
des exigences et vrification de la matrice de traabilit.
A faire en cours de projet et en maintenance aprs chaque volution
majeure des rfrentiels
" Audits physiques de la configuration
# Vrification de la cohrence entre le rfrentiel produit et le logiciel
install.
A faire chaque livraison
" Audits au fil de l'eau du rfrentiel
# Ce sont des audits fonctionnels effectus en cas de doute
" Mesures
# Nombre de modifications, de dfauts ou erreurs dtects
Les activits
de base
La gestion de configuration
143
! Gestion des versions et des livraisons
" Construction d'une version livrer
# Construire une version consiste runir les diffrents composants
cohrents de cette version pour produire le logiciel excutable
correspondant aux besoins (tests, maintenance, livraison client, ...)
" Gestion des versions livres
# Une version livre n'est pas forcment constitue de composants la
dernire version.
# La question est de savoir quand il devient ncessaire de regnrer
une nouvelle version
Les activits
de base
La gestion de configuration
144
Les activits
de base
Gnie Logiciel
L'exploitation
L'exploitation
146
! Les activits d'exploitation comportent deux
groupes d'activits

" La fourniture de services

" Le soutien aux utilisateurs
Les activits
de base
L'exploitation
147
! Fourniture des services
" Gestion des niveaux de service
# Mise en place de SLA (Service Level Agreement)
& Services concerns
& Heures des services
& Disponibilit
& Support
& Capacit, temps de rponse
& Continuit de service
& Mesures associes
& Pnalits
" Gestion de la disponibilit
# Lie : maintenance prventive, fiabilit des matriels et des
logiciels, architecture du systme (redondances)
Les activits
de base
L'exploitation
148
! Fourniture des services
" Gestion de la continuit de service
# Est ncessaire si disponibilit 100% est une ncessit
# Restauration suite plantage, possibilit de back up sur autre
systme, mise en uvre de modes de fonctionnement dgrad
" Gestion de la capacit
# Suivi des performances, de la taille des flux, des volumes de donnes,
du nombre d'utilisateurs, etc.
# Analyse des tendances
# Optimisation, recherche d'organisation plus efficace, augmentation
des capacits existantes
Les activits
de base
L'exploitation
149
! Soutien aux utilisateurs
" Gestion des incidents
# Incident : tout vnement qui ne fait pas partie du fonctionnement standard dun
service et qui cause, ou peut causer,
une interruption ou une diminution de la qualit de ce service
# Activits de la Gestion des Incidents :
& Dtection et enregistrement des Incidents
& Support initial et classification
& Investigation et diagnostic
& Suivi global des Incidents
& Rsolution et rtablissement
& Fermeture des Incidents

Les activits
de base
L'exploitation
150
! Soutien aux utilisateurs
" Gestion des incidents
Le mcanisme d'escalade
# Escalade fonctionnelle
Transfert dun Incident dun niveau au niveau suprieur :
& par manque de connaissance ou dexpertise
& par dpassement dun dlai
# Escalade hirarchique
Intervient nimporte quel moment dans le cycle :
& Quand il est vident que la rsolution interviendra hors-dlai ou sera
insatisfaisante
& Dans lidal : avant la fin du dlai pour que la hirarchie
ait le temps de ragir

Les activits
de base
L'exploitation
151
! Soutien aux utilisateurs
" Gestion des incidents
# Mtriques couramment utilises :
& nombre total dIncidents
& temps moyen de rsolution par code dimpact
& pourcentage dIncidents rsolus dans les temps
contractuels
& cot moyen de traitement dun Incident
& nombre et pourcentage dIncidents rsolus sans
dplacement sur site
Les activits
de base
L'exploitation
152
! Soutien aux utilisateurs
" Gestion des problmes
est complmentaire de la gestion des incidents et est lie la
maintenance
# Gestion des incidents : traitement des consquences (aspect curatif)
# Gestion des problmes : recherche et traitement des causes (aspect prventif et
correctif)
Les activits
de base
Gestion de la
capacit
Gestion de la
disponibilit
Gestion des
incidents
Modification
prventive
Modification
corrective
Demande de
changements
Gestion des
Problmes
L'exploitation
153
! Soutien aux utilisateurs
" Gestion des changements
Voir aussi les activits de maintenance
# Concerne
& Les matriels
& Les quipements et logiciels rseaux
& Les logiciels systme
& Les applications en production
& Toutes les documentations et procdures relatives l'exploitation, au
support, la maintenance

Les activits
de base
L'exploitation
154
! Soutien aux utilisateurs
" Gestion des changements
# Les activits
& Rception des demandes de changement
& Analyse et tude d'impact
& Validation/refus de la demande
& Transfert Gestion des configurations installes et Gestion des mises en
production

" Gestion des configurations installes
# Identification des composants installs
# Prise en compte des volutions des configurations installes
# Contrle de ces lments (par vrification et audits)
# Sauvegarde, archivage et maintenance de la Base de donnes de la
Gestion des configurations installes
Les activits
de base
L'exploitation
155
! Soutien aux utilisateurs
" Gestion des mises en production
# Tests des scripts et paramtrages avant Homologation
# Vrification du bon tat de fonctionnement de linfrastructure de Dploiement
avant une opration
# Vrification de la bonne installation/activation du logiciel aprs lopration
# Ncessit d'un plan de retour arrire chaque implmentation dun
changement
Les activits
de base
L'exploitation
156
Les activits
de base
Nature du
dploiement
Livr par Accept par
Livr la
production par
Accept en
production par
Nouveau logiciel
externe
Chef de projet
tudes
Responsable
MOA
Responsable
Changement
Responsable
exploitation
Nouvelle
application
Chef de projet
tudes
Responsable
MOA
Responsable
Changement
Responsable
exploitation
Modification de la
base de donnes
Chef de projet
tudes
Gestionnaire de la
Base de Donnes
Responsable
Changement
Gestionnaire de la
Base de Donnes
Serveur,
Mainframe
Ingnieur
systme
Responsable quipe
systme
Responsable
Changement
Responsable quipe
systme
Application sur
poste de travail
Chef de projet
tudes micro
Responsable
support micro
Resp.
support micro
Resp.
Changement
Responsable
support micro
Poste de travail Logistique
Responsable
support micro
Responsable
Changement
Responsable
support micro
! Exemple d'organisation dans le cadre d'un dploiement
L'exploitation
157
! Les activits d'exploitation sont modulables en
fonction de la configuration informatique
installe
" Micro ordinateur individuel : rien
" Processeurs embarqus : tout ou partie des activits de soutien du service
" Serveurs, mainframe : la totalit des activits
Les activits
de base
L'exploitation
158
Les activits
de base
Gnie Logiciel
La maintenance
La maintenance
160
! Contrairement au matriel, la maintenance logiciel n'est
pas lie aux phnomnes d'usure

! Elle dmarre en amont de la livraison (prparation,
vrification de la maintenabilit : Cf. Caractristiques)
et se poursuit pendant toute la priode d'exploitation.
Les activits
de base
La maintenance
161
! Fondamentaux
" Types de maintenance
# Maintenance Corrective (MC)
# Maintenance Evolutive (ME)
# Maintenance Amliorative (MA)
" Besoins de maintenance
# Correction des dfauts (MC)
# Modifications fonctionnelles (ME ou MA)
# Mise en uvre d'amlioration (ME)
# Interfaage avec de nouveaux systmes (ME)
# Adaptation aux volutions du systme d'exploitation (ME)
# Prise en compte des volutions rglementaires (ME)
Les activits
de base
La maintenance
162
! Fondamentaux
" Principaux cots de maintenance
La maintenance reprsente prs de 80% du cot d'un logiciel
(soit 4 fois son cot de dveloppement)
# Certaines organisations n'incluent pas dans la maintenance les
activits d'amlioration et de modifications fonctionnelles (notion de
seuil)

" Gestion des changements
# Toute opration de maintenance dbouche sur une demande de
changement
& Mini projet (volution importante ou plusieurs petites volutions)
& Modification ponctuelle (petite volution). Dconseille
Les activits
de base
La maintenance
163
! Techniques de maintenance
" Comprhension du logiciel maintenir
# Primordiale si quipe de maintenance n'a pas particip
l'laboration du logiciel. Facilite par la lisibilit et compltude de la
documentation
" R-ingnierie
# Parfois ncessaire dans le cas de grosses modifications. Cette activit
est considre comme un projet part entire
" Reverse engineering
# Ncessaire en l'absence ou en cas d'insuffisance de documentation
Les activits
de base
La maintenance
164
! Les problmes cl
" Le processus de maintenance (Voir Cycles de vie, voir la
gestion des changements en exploitation)
Les activits
de base
La maintenance
165
! Les problmes cl
" Comprhension limite de l'existant
" Identification des tests effectuer
" Analyses d'impact
" Maintien jour de la documentation
" Externalisation
Les activits
de base
La maintenance
166
Les activits
de base