Gnie Logiciel.

doc
______________________________________________________________________________

DI GALLO Frdric

COURS DE
GENIE LOGICIEL
Cycle Probatoire

CNAM BORDEAUX 1999-2000

___________________________________________________________________
DI GALLO Frdric

Page 1

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

TEST DE LOGICIEL
I.

FONDEMENT DU TEST ................................................................................................6

1.1) Cycle de dveloppement de test ...................................................................................7
1.2) Mise au point Inductive ...............................................................................................8
1.2) Mise au point Dductive ..............................................................................................8
II. TECHNIQUE DE TEST ..................................................................................................9
2.1) Test Boite blanche .................................................................................................9
2.2) Test Boite noire ....................................................................................................12
III. TD: TEST, VERIFICATION ET VALIDATION ......................................................................14
Exercice 1: Test Bote Blanche ..........................................................................................14
Exercice 2: Test statistique ................................................................................................15

FIABILITE DU LOGICIEL
I. DEFAUT & FAUTE ......................................................................................................18
II. AMELIORATION DE LA FIAIBILITE .......................................................................18
III. METRIQUE DE LA FIABILITE...................................................................................19
3.1) Probabilit dune panne ............................................................................................19
3.2) Taux de panne............................................................................................................19
3.3) Temps moyen entre deux pannes ...............................................................................19
3.4) Disponibilit ..............................................................................................................19
IV. CLASSIFICATION DE DEFAUT.................................................................................19

GESTION DE PROJET
I.

RAPPELS .......................................................................................................................23
1.1) Dfinitions .................................................................................................................23
1.2) Dfinitions des types de Gestion................................................................................24
1.3) Activits de Gestion ...................................................................................................24
II. ESTIMATION DE CHARGE ........................................................................................25
2.1) Dfinitions .................................................................................................................25
2.2) Diffrentes mthodes d'estimation de charge ............................................................25
III. PLANIFICATION DE PROJET ....................................................................................28
3.1) Dfinition ...................................................................................................................28
3.2) Rseau PERT (Profit Evaluation and Review Technique) .............................28
3.3) Diagramme de GANTT..............................................................................................32
3.4) TD PLANIFICATION ..............................................................................................33
IV. PILOTAGE DE PROJET ...............................................................................................36
4.1) Suivi individuel :........................................................................................................36
4.2) Suivi du projet............................................................................................................37

___________________________________________________________________
DI GALLO Frdric

Page 2

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

MAINTENANCE DE LOGICIEL
I.

TYPES DE MAINTENANCE .......................................................................................40

1.1) Maintenance perfective (volutive) ...........................................................................40
1.2) Maintenance adaptative ............................................................................................40
1.3) Maintenance corrective .............................................................................................40
1.4) Distribution de l'effort ................................................................................................40
II. PROCESSUS DE LA MAINTENANCE.......................................................................41
2.1) Informations ncessaires pour la maintenance .........................................................41
2.2) Cycles de dveloppement dune correction ................................................................41
2.3) EXERCICES : .............................................................................................................42
III. ESTIMATION DU COUT DE LA MAINTENANCE ..................................................42
3.1) Formules ....................................................................................................................42
3.2) Quatre facteurs multiplicatifs....................................................................................43
IV. LES EFFETS DE LA MAINTENANCE .......................................................................43
V. MAINTENANCE DU CODE ETRANGER ..................................................................44
VI. RE-INGENIERIE ...........................................................................................................44
VII. MAINTENANCE EVOLUTIVE ...................................................................................44
7.1) Techniques de restructuration :.................................................................................45
7.2) Exercice sur les techniques de restructuration..........................................................46

GESTION DE LA QUALITE
I. DEFINITION..................................................................................................................51
II. NORMALISATION .......................................................................................................51
III. MANUEL QUALITE.....................................................................................................51

___________________________________________________________________
DI GALLO Frdric

Page 3

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

TEST
DE
LOGICIEL

___________________________________________________________________
DI GALLO Frdric

Page 4

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

TEST DE LOGICIEL
I.

FONDEMENT DU TEST ............................................................................................... 6

1.1) Cycle de dveloppement de test ................................................................................ 7
1.2) Mise au point Inductive .............................................................................................. 8
1.2) Mise au point Dductive ............................................................................................. 8
II. TECHNIQUE DE TEST ................................................................................................. 9
2.1) Test Boite blanche ................................................................................................ 9
2.2) Test Boite noire ................................................................................................... 12
III. TD: TEST, VERIFICATION ET VALIDATION ..................................................................... 14
Exercice 1: Test Bote Blanche ......................................................................................... 14
Exercice 2: Test statistique ............................................................................................... 15

___________________________________________________________________
DI GALLO Frdric

Page 5

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

TEST DE LOGICIEL
Introduction :
Le test est une activit importante dont le but est darriver un produit zro dfaut .
C'est la limite idaliste vers laquelle on tend pour la qualit du logiciel. Gnralement 40% du
budget global est consacre leffort de test.

I.

FONDEMENT DU TEST

Le test est une recherche d'anomalie dans le comportement de logiciel. Cest une activit
paradoxale : il vaut mieux que ce ne soit pas la mme personne qui dveloppe et qui teste le
soft. Do le fait quun bon test est celui qui met jour une erreur (non encore rencontre).
Remarque (difficult) : il faut arriver grer une suite de test la plus complte possible
un coup minimal.
Un test ne peut pas dire il n'y a pas d'erreur car il teste le logiciel de faon poussive,
plus que dans l'utilisation relle.

___________________________________________________________________
DI GALLO Frdric

Page 6

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

1.1) Cycle de dveloppement de test

Lorsqu'une erreur est dtecte alors que commence le dbogage, la correction d'une erreur
dont la diffrence avec rsultat en du juif est de l'ordre de 0,01% peut prendre En fait, ce
nest pas fonction de l'importance de l'erreur. Ce qui induit une difficult concernant la
planification du dbogage.

Objectif du test

Spcification
du test

Spcification
programme

Scnario de test
Chargement du
prog. et de son
environnement

rsultat attendu

Excution
du test

Comparaison
de rsultats
correct

incorrect
on met une hypothse
qui expliquerait lanomalie

Induction
Archivage du
test + rsultats

Analyse de
rsultats
Dduction

Biblio.

Modification
Induite
dans le test

On limine les cas jusqu

tomber sur la problmatique

dans le prog.
Gestion de
configuration

___________________________________________________________________
DI GALLO Frdric

Page 7

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

1.2) Mise au point Inductive

On met une hypothse sur lensemble.
Localiser toutes les
donnes pertinentes
Organiser les donnes
(classes dquivalence)

Donnes
insuffisantes

Etudier les relations et

dpendances fonctionnelles
Formuler (mettre)
une hypothse

Inconsistance
Prouver lhypothse
(Est-elle pertinente ?)
Corriger lerreur

1.2) Mise au point Dductive

On traite chaque cause sparment.
Enumrer toutes les
causes possibles
Elimination progressive de
toutes les causes sauf une

Rassembler plus
de donnes

Emettre, amliorer,
raffiner lhypothse
Inconsistance
Prouver lhypothse
(Est-elle pertinente ?)
Corriger lerreur

___________________________________________________________________
DI GALLO Frdric

Page 8

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

II. TECHNIQUE DE TEST

Plusieurs techniques qui dpendent de lobjectif du test. Mais aucune technique ne sera
jamais complte. Le problme est de savoir quelle technique nous assure la compltude, car
en fait, aucune ne peut le garantir.

Espace de cas possibles

Cela revient chantillonner de faon reprsentative.

Espace
gnrateur

Proprits recherches : Si lespace gnrateur est couvert alors la probabilit d'une

dfaillance dans l'espace de cas possible est trs faible (infrieure une limite fixe
l'avance). La difficult et de faire que l'espace gnrateur soit consistant et complet.

Les Diffrentes techniques de test

Test dynamique
PVIS

Instrument de
visualisation

DS
Domaine
de rsultat

Composante
donnes

code

Elments entrs

Suivi du chemin dexcution

DE

Trace

2.1) Test Boite blanche

Ce test consiste analyser la structure interne du programme en dterminant les chemins
minimaux. Afin d'assurer que:
Toutes les conditions d'arrt de boucle ont t vrifies.
Toutes les branches d'une instruction conditionnelle ont t tests.
Les structures de donne interne ont t testes (pour assurer la validit).

___________________________________________________________________
DI GALLO Frdric

Page 9

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

Structures de la reprsentation de la bote blanche.

La structures de contrle se prsente sous la forme d'un graphe dit graphe de flot. On
reprsente les instructions comme cela :
Suite linaire :

Case :

If :

Until :

While (for) :

Else :

If A & B & C If A then if B then if C then

Remarque :

Mesure de complexit de Mac Cabr.

Cette mesure donne le nombre de chemins minimaux. Elle est donne par la formule
suivante qui correspond au nombre de rgions du graphe de flot :
Nb.Arcs Nb.Nuds + 2

Nombre cyclomatique

Exemple : Supposons un programme reprsent par l'organigramme suivant:

dbut
1

2
3

4
6

7
9

11

5
10

___________________________________________________________________
DI GALLO Frdric

Page 10

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
On en dduit le graphe de flot suivant :
1
R4

R1
2
3

6
8
11

R3

R2
7

4
5

9
10

Donc le nombre cyclomatique est : Nb.Arcs Nb.Nuds + 2 = 13 11 + 2 = 4

Pour vrifier, on regarde les chemins minimaux (un test par chemin pour tester toutes les
possibilits du programme) :
1. 1.11
2. 1.2.3.4.5.10.1.11
3. 1.2.3.6.7.9.10.1.11
4. 1.2.3.6.8.9.10.1.11

Exercice : soit le programme recherche dichotomique en langage C:

void recherche_dico (elem cle, elem t[], int taille, boolean &trouv, int &A)
{ int d, g, m;
g=0; d=taille -1;
A (d+g) /2;
if (t[A]= =cle) trouv=true;
else trouv=false;
while (g <=d && !trouv)
{ m= (d+g) /2;
if (t[m]= =cle)
{ trouv=true;
A=m;
}
else if (t[m]> cle) g=m+1;
else d=m-1;
}
}
Calculer le nombre cyclomatique de cette procdure.

___________________________________________________________________
DI GALLO Frdric

Page 11

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

2.2) Test Boite noire

On ignore la structure de codage du logiciel
Principe :
1. On considre le programme dans son aspect fonctionnel et non plus structurel.
2. On partitionne le domaine (DE) en classes.
3. On gnre des cas de test aux limites de classe.
Exemple : Soit P un programme. Supposons que les donnes de P soient des nombre de
cinq chiffres. Alors les classes de nombre cinq chiffres s'obtiennent de la manire suivante:
1. x < 10 000
2. 10000 x 99 999
3. X 100 000
Les cas de test aux limites de classes sont donc 00 000 et 09 999 pour la premire classe,
10 000 et 99 999 pour la deuxime classe et 100 000 pour la troisime.
On a donc tester les nombres suivants :
<10 000

10 000

50 000

99 999

99 999 <

Exercice : programme recherche dichotomique en langage C:

void recherche_dico (elem cle, elem t[], int taille, boolean &trouv, int &A)
{ int d, g, m;
g=0; d=taille -1;
A (d+g) /2;
if (t[A]= =cle) trouv=true;
else trouv=false;
while (g <=d && !trouv)
{ m= (d+g) /2;
if (t[m]= =cle)
{ trouv=true;
A=m;
}
else if (t[m]> cle) g=m+1;
else d=m-1;
}
}
Pr-condition :
Taille >= 1 ;
Quelquesoit i : 0 i taille 1
T[i] t[i+1]

Post-condition :
( vrai et t(i)=cl ) ou
( faux et 0 i taille t(i)=cl )

___________________________________________________________________
DI GALLO Frdric

Page 12

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
4. Proposer un partitionnement de D.E.
D'aprs la pr-condition, on en dduit que le programme manipule les tableaux tris non
vides (ils contiennent au moins un lment).
1re classe: tableau de taille = 1 ;
2me classe: tableau de taille > 1.
5. Proposer un jeu de test
Tableau
Elment
1 seule valeur
Dans le tableau
1 seule valeur
Pas dans le tableau
Plus dune valeur 1er lment dans le tableau

dernier lment dans le tableau

mdian dans le tableau

non prsent dans le tableau

Table
[17]
[17]
[3,17,33,42,58]

Cl Sortie (trouv, A)
17
(true, 0)
27
(false, ???)
3
(true, 0)
58
(true, 4)
33
(true, 2)
1
(false, ???)

6. Donner un exemple, bas sur votre exprience, qui montre lincompltude du test B. Noir
par rapport au test B. Blanche.
Par exemple, un pointeur non initialis ne sera pas dtect par le test B. Noire alors qu'il est
par le test B. Blanche.
Typedef struct cplx
{ int reel,
int img ; } cplx ;

nombre complexe (partie relle + imaginaire)

CPLX * add-cpl (cplx a, cplx b)

addition de nombres complexes
{ resultat = malloc (sizeof (*cplx)) ;
resultat.reel = a.reel + b.reel ;
resultat.img = a.img + b.img ;
return resultat ; }
Ici, il est possible que se pose un problme dallocation mmoire. La B. Noire ne le verra
pas contrairement la B. Blanche. Certains disent que lincompltude est rciproque, dautres
disent quil ny a pas de raison puisque les DE sont les mmes.
Logiciel
Spcification
Conception
Codage

L
S
D
C
U
I
V
T

Test unitaire (bote blanche)

Test dintgration (ici, on sintresse larchitecture dun module, on vrifie
ladquation entre les fonctions appeles et les fonctions appelantes : Bote Noire).
Test de validation (vrifier est-ce que le systme construit correspond bien aux
besoins exprims par le client ? Les moyens mis en uvre sont des notions
mathmatiques : preuves formelles du programme).
Test du logiciel (environnement rel du logiciel, avec les donnes du client, sa
plate-forme, etc. : test de fiabilit).

___________________________________________________________________
DI GALLO Frdric

Page 13

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

III. TD: Test, Vrification et Validation

Exercice 1: Test Bote Blanche
Trouver le nombre cyclomatique du graphe de contrle associ au programme suivant et
donner un ensemble de tests:
void tri_shell (tableau t ;int n) {
element inf= t [0];
int incr=n;
element L;
int i, k;
while (incr > 1) {
if (incr < 5)
incr=1;
else incr = (5 * incr-1)/11;
for ( i = inf; i < n ; i+incr) {
k = i - incr;
while( k >= inf) {
if (L < t [k]) {
t [k+incr] = t [k];
k= k - incr; }
else exit; }
t [k+incr]=L;
}
}
}
On en dduit le graphe de flot :

1
2
While incr > 1

3
4

5
6
7

14

8
For i < n 9
10
13

While k inf
11

12

___________________________________________________________________
DI GALLO Frdric

Page 14

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
On a donc 14 noeuds et 18 arcs diffrentes ce qui donne Nb Cycl = 18 14 + 2 = 6
Aprs avoir trouv le nombre cyclomatique, il suffit de donner six tableaux correspondants
chaque chemin minimal:
1.
un tableau ayant un seul lment
2.
un tableau tri avant moins de 5 lments
3.
un tableau non tri ayant moins de 5 lments
4.
un tableau tri ayant plus de 4 lments
5.
un tableau non tri ayant plus de 4 lments
6.
un tableau partiellement tri ayant plus de 4 lments

Exercice 2: Test statistique

1. Certaines classes de systme sont conues pour supporter une certaine charge. Par
exemple, un systme de gestion du contrle arien, peut tre conu pour traiter cent
transactions par seconde. Il a fallu imaginer des tests pour s'assurer que le systme
supportait bien la charge pour laquelle il tait conu. Ces tests sont appels tests de
surcharge et consistent aller au del de la charge maximale du systme. Le principe:
on prvoit une srie de tests o la charge augmente progressivement jusqu' ce que le
systme tombe en panne. Donner et expliquer deux intrts du test du surcharge.
a) On teste le comportement du systme en cas de panne.
En effet, i1 se peut que dans des circonstances extraordinaire, le systme soit plus charg
que prvu. Dans de telles circonstances, il vaut mieux tomber en panne "doucement" plutt
que "brutalement". Ces test permettent de vrifier que le systme surcharg n'occasionne
pas de dgts irrparables.
b) En surchargeant le systme, on peut faire apparatre des dfauts qui ne se seraient pas
manifests autrement. Bien que l'on puisse rpondre que de tels dfaut ont bien peu de
chances de causer des pannes en fonctionnement normal, ils peuvent correspondre des
combinaisons peu habituelles qui sont, par concidence, semblables aux tests de charge.
c) On peut aussi se servir du test de surcharge pour dterminer une mesure de fiabilit.
2. Dcrire comment on peut utiliser un analyseur dynamique pour le test structurel d'un
programme. Rappel: les analyseurs dynamique sont des programmes que l'on utilise
pour recueillir des informations sur la frquence d'excution de chacune des instructions
d'un programme.
D'abord, il faut identifier toutes les instructions de test et d'itration, et ensuite
instrumenter chaque instruction du programme.
Via un pr-processeur, on ajoute ces instructions au langage de haut niveau dans
lequel est crit le programme.
On compile le langage avec un compilateur standard.
Lors de l'excution, les instructions rajoutes viennent stocker les donnes sur le
comportement du programme dans un fichier jouant le rle d'historique.
L'analyse de ce fichier permet d'identifier les parties du programme qu'il faut optimiser
et surtout celles qui n'ont pas t excutes. On en dduit de nouveaux tests qui
excuterons ces parties. D'autre part, on peut aussi utiliser le rsultat pour vrifier
l'adquation du jeu de test avec le programme test.

___________________________________________________________________
DI GALLO Frdric

Page 15

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

FIABILITE
DU
LOGICIEL

___________________________________________________________________
DI GALLO Frdric

Page 16

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

FIABILITE DU LOGICIEL
I. DEFAUT & FAUTE ......................................................................................................18
II. AMELIORATION DE LA FIAIBILITE........................................................................18
III. METRIQUE DE LA FIABILITE...................................................................................19
3.1) Probabilit dune panne ............................................................................................19
3.2) Taux de panne............................................................................................................19
3.3) Temps moyen entre deux pannes ...............................................................................19
3.4) Disponibilit ..............................................................................................................19
IV. CLASSIFICATION DE DEFAUT.................................................................................19

___________________________________________________________________
DI GALLO Frdric

Page 17

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

FIABILITE DU LOGICIEL
Cest la probabilit de faire une opration sans panne sur une dure fixe et pour un
contexte donn. La fiabilit est subjective : elle dpend de lutilisateur et du contexte
dutilisation. Elle donne une mesure du degr de confiance et elle mesure les consquences
dune faute.

I.

DEFAUT & FAUTE

Un dfaut est due la prsence dune faute. Il a une caractristique essentiellement

dynamique. Une faute est une caractristique statique du logiciel qui provoque un dfaut
lexcution. Exemple : pour un log. de saisie, une faute serait de ne pas vrifier la mauvaise
saisie. Un dfaut serait que le logiciel plante suite la mauvaise saisie.
Entres possibles
Ie

Il est clair que toute faute ne provoque

pas ncessairement un dfaut, cest
possible si et seulement si la donne est
prise dans la partie fautive.

PROGRAMME

Oe
Sorties possibles

II. AMELIORATION DE LA FIAIBILITE

Est-ce que la fiabilit est fonction de la correction de faute logicielle ?
Non !!! Mais il faut quand mme corriger les fautes, surtout les fautes graves.
Paradoxe : Plus on augmente la fiabilit, plus on rduit lefficacit . Pour assurer la
fiabilit, on fait des test, on rajoute du code (redondance, vrification). Ceci entrane le fait
que le logiciel sera plus lourd, plus lent donc moins efficace. En gnral, on privilgie la
fiabilit car lefficacit devient de moins en moins ncessaire vu les prix des machines
actuelles. Cela est plus facile amliorer.

___________________________________________________________________
DI GALLO Frdric

Page 18

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

III. METRIQUE DE LA FIABILITE

3.1) Probabilit dune panne
Cest la probabilit que le systme se comporte de manire non prvue (non souhaite)
lorsquune requte est effectue.
Exemple : Systme non stop : P.F.=0,001 sur 1000 requte, on a une proba. d1 dfaut.

3.2) Taux de panne

Cest la frquence dapparition dun dfaut.
Exemple : Systme dexploitation ou transactionnel
T.F.=0.02 sur 100 units de temps, on a 2 dfauts.

3.3) Temps moyen entre deux pannes

Cest la mesure de temps entre deux apparitions de dfauts.
Exemple : Rseau (essentiellement change de gros fichiers)
T.M.P.=500 le temps moyen entre deux dfauts est de 500 unit de temps.

3.4) Disponibilit
Cest la probabilit que le systme soit oprationnel. Elle prend en compte le temps de
rparation ventuel.
Exemple : Centrale nuclaire, commande de refroidissement du noyau. Deux mtriques
principales : disponibilit et probabilit. On peut avoir aussi les transmission par un rseau
concernant le temps moyen de panne, systmes de communication
Dispo = 0,998 sur 1000 units de temps, le systme est disponible et
utilisable pendant 998 units de temps.

Unit de temps :
Elle dpend du systme utilis
Horloge interne pour le systme non-stop
Temps calendaire pour le systme activit rgulire
Nombre de transaction pour le systme fonctionnant la demande.

IV. CLASSIFICATION DE DEFAUT

Classe de panne
Transitoire
Permanente
Rparable
Irrparable
Non corruptrice
Corruptrice

Description
Ne se produit quavec certaines entres.
Se produit avec toutes les entres.
Ne ncessite pas dintervention humaine.
Ncessite une intervention de loprateur.
Ne dtruit, ni corrompt les donnes.
Corrompt les donnes. ( INACCEPTABLE !!! )

___________________________________________________________________
DI GALLO Frdric

Page 19

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

Exercice : Distributeurs automatique de billets.






Chaque distributeur est utilis 300 fois par jour,

Une banque possde 1000 distributeurs,
La vie dune version de distributeur est de deux ans,
Chaque distributeur traite environ 10 000 transactions par jour.
Classer les pannes et proposer les mtriques qui vont avec.

Classe du dfaut Exemple

Mtrique

Permanente et
non corruptrice

Le systme nest plus oprationnel quelque soit la Dispo : 1 par 1000 jours
carte

Transitoire et
non corruptrice

Les donnes sur la bande magntique ne peuvent

tre lue sur certaines cartes (non endommages)

Taux de panne

Transitoire et
corruptrice

Le montant nest pas correctement report sur le

compte.

Inqualifiable (ne devrait

jamais arriver).

___________________________________________________________________
DI GALLO Frdric

Page 20

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GESTION
DE
PROJET

___________________________________________________________________
DI GALLO Frdric

Page 21

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GESTION DE PROJET
I.

RAPPELS .......................................................................................................................23
1.1) Dfinitions .................................................................................................................23
1.2) Dfinitions des types de Gestion................................................................................24
1.3) Activits de Gestion ...................................................................................................24
II. ESTIMATION DE CHARGE ........................................................................................25
2.1) Dfinitions .................................................................................................................25
2.2) Diffrentes mthodes d'estimation de charge ............................................................25
III. PLANIFICATION DE PROJET ....................................................................................28
3.1) Dfinition ...................................................................................................................28
3.2) Rseau PERT (Profit Evaluation and Review Technique) .............................28
3.3) Diagramme de GANTT..............................................................................................32
3.4) TD PLANIFICATION ..............................................................................................33
IV. PILOTAGE DE PROJET ...............................................................................................36
4.1) Suivi individuel :........................................................................................................36
4.2) Suivi du projet............................................................................................................37

___________________________________________________________________
DI GALLO Frdric

Page 22

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

GESTION DE PROJET
I.

RAPPELS
"Qu'est-ce qu'un projet ?"
C'est une intention, plus ou moins floue, dont la ralisation est (peut-tre) lointaine.

1.1) Dfinitions
Du point de vue scientifique: l'image d'un futur, qu'on espre atteindre.
Du point de vue du gnie logiciel, c'est triangle contraint:
Objectif

Moyen

Dlai

La gestion du projet logiciel a pour but de le mener son terme, en tenant compte de
contraintes qui lient chacun des aspects du triangle projet.
Gestion des Productions
Objectif

Moyen

Dlai

Gestion des Ressources

Gestion du Temps

La gestion de projet logiciel s'intresse aux activits qui assurent que le projet command
sera livr dans les temps en accord avec les contraintes des organismes commanditaires et
ralisateurs. Il se dgage donc quatre activits principales: la structuration, l'estimation, la
planification, et le suivi.

___________________________________________________________________
DI GALLO Frdric

Page 23

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

1.2) Dfinitions des types de Gestion

Gestion de dlai: elle consiste dterminer un parcours qu'on va suivre, un calendrier de
ralisation et une matrise d'enveloppe temps.

Gestion de ressources: le moyen constitu du budget du projet donc il s'agit de transformer

le budget en travail, locaux, matriels, dplacements dans ce but.

Gestion des productions: l'objectif d'un projet doit son terme tre concrtise par une ou
plusieurs fournitures. Il faut s'assurer que ce qui est produit se rapproche du but final.

Remarque: la solidarit entre les sommets du triangle de gestion doit tre permanente.

1.3) Activits de Gestion

"A chaque stade du dveloppement ou tape de la production."

ANALYSER

ORGANISER

PRODUCTION

PILOTER

___________________________________________________________________
DI GALLO Frdric

Page 24

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

II. ESTIMATION DE CHARGE

2.1) Dfinitions
Dfinition: c'est la quantit de travail qu'une personne peut raliser.
Unit: en jour / homme, mois / homme, anne / homme.
Remarques: mois / homme (charge sur un mois): en gnral 20 jours.
Taille du projet: la taille du projet se mesure sa charge.
Ordre de grandeur: selon les normes ISO:
Charge < 6 M/h
6 M/h charge 12 M/h
12 M/h charge 30 M/h
30 M/h charge 100 M/h
100 M/h charge

trs petit projet

petit projet
projet moyen
grand projet
trs grand projet

Dure: dpend de la charge et du nombre de personnes infectes.

Exemple: 60 M/h peut tre 1 personne pendant 5 ans ou
10 personnes pendant 6 mois ou
60 personnes pendant 1 mois.

2.2) Diffrentes mthodes d'estimation de charge

1) La non mthode
Exemple: rpondre une offre avec un prix bas pour tre sur de l'avoir, mais sans tre sr
d'y gagner quelque chose en dfinitive (au point de vue financier).

2) Mthode Delphi "Base sur l'exprience des experts du domaine."

Principe:

Chaque expert propose une estimation base sur son exprience.

On publie le rsultat (anonyme).
Les experts sont invits modifier ou maintenir leurs estimations.
On publie les rsultats nominaux.
Les experts refont la troisime tape.
On analyse les disparits, on calcule la moyenne.

___________________________________________________________________
DI GALLO Frdric

Page 25

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

3) Mthode de rpartitions proportionnelle

Elle s'appuie sur le dcoupage du projet en diffrentes phases. On commence par faire
l'estimation de la charge globale. Ensuite, on dtermine la charge pour chaque phase du cycle
de vie.
Etape
Ratio
Etude pralable
10 % de la charge totale
Etude dtaille
20 30 % de la charge totale
Etude technique
5 15 % de la charge "ralisation"
Ralisation
2 fois la charge "tude dtaill"
Mise en uvre
30 40 % de la charge "ralisation"

4) Mthode COCOMO
"Propose par B.W. Boehm en 1981 (Construct Cost Model)"
En fonction des hypothses:
Il est facile un informaticien d'estim le nombre de lignes source.
La complexit d'criture d'un programme est la mme quelquesoit le langage de
programmation.
Il propose une mthode base sur la corrlation entre la taille d'un projet et sa charge.

Formule:

Charge = a . (K isl)b
Dlai = c . (Charge)d
Taille moyenne d'quipe = Charge / Dlai

Avec: K isl nombre de milliers de lignes sources.

Et les paramtres a, b, c et d qui dpendent de la catgorie du projet.

Classification:
Projet simple:
Projet moyen:
Projet complexe:

< 50 000 lignes

50 000 lignes 300 000
> 300 000 lignes

Type de projet

Charge en M/h Dlai en M

Simple

a = 3.2
b = 1.05
a=3
b = 1.12
a = 2.8
b = 1.2

Moyen
Complexe

c = 2.5
d = 0.38
c = 2.5
d = 0.35
c = 2.5
d = 0.32

___________________________________________________________________
DI GALLO Frdric

Page 26

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

Facteurs: pris en compte pour calculer la "charge nette".

Fiabilit, complexit, taille de la mmoire, temps d'excution...
Tous ces paramtres dpendent de l'entreprise dans laquelle est dvelopp le logiciel.

Charge net = Produit (facteurs) x Charge (brute)

EXERCICES
Exercice 1: Estimer la taille moyenne de l'quipe qui faudrait prvoir pour dvelopper un
logiciel estim environ 40 000 instructions sources.
Nous appliquons la mthode COCOMO et nous nous apercevons que c'est un projet simple.
Nous avons donc pour le calcul de la charge et et du dlai, les coefficients suivant:
a = 3.2 et b = 1.05
c = 2.5 et d = 0.38
Donc selon la formule de la charge: charge = 3.2 (40)1.05 154 M/h
dlai = 2.5 (154)0.38 17 Mois
Ce qui nous donne: Taille quipe = charge / dlai = 154/17 = 9 personnes.

Exercice 2: Sachant que la phase d'observation reprsente environ un tiers de la charge de

l'tude pralable, calculer la charge du projet en M/h et sa rpartition dans le cycle de
dveloppement. Nous supposons que la charge de la phase d'observation a t estim 7,5 J/h.
Charge tude pralable = 3 x phase observation 22 J/H
Charge totale = 10 x charge tude pralable 22x10 220 J/h
11 M/h

___________________________________________________________________
DI GALLO Frdric

Page 27

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

III. PLANIFICATION DE PROJET

3.1) Dfinition
partir des rsultats de la structuration et de l'estimation, la planification consiste :
Constater les deux listes diffrentes tches et leur dure,
Dterminer les relations de dpendance entre les tches,
Dterminer les tages critiques,
Ordonnance ces les tches dans le temps,
Proposer profil partage,
De tenir compte d'ventuelles intolrables.
Pour cela, le chef de projet a deux principales techniques (complmentaires) sa disposition.

3.2) Rseau PERT (Profit Evaluation and Review Technique)

Elle est base sur les contraintes d'enchanement avec pour chaque tche les dates de dbut
et de fin. C'est un graphe acyclique (oriente et sans cycle) qui permet de reprsenter
l'enchanement de tche. Chaque noeud du graphe est un couple (Ti, di).
Exemple:

D
7

Dbut

Fin

3
C

E
2

3.2.1) Les types de liens

Il existe quatre types de liens pour l'enchanement des tches.
a) Fin dbut:
C'est une relation de type "Fin dbut" car des que l'tape A est finie, l'tape B commence.
A

B
da

I dlai (en jour)

db

Exemple:

A : programmation
dlai : -15 jours
B : tests
Les tests peuvent commencer quinze jours avant
la fin de la programmation.

___________________________________________________________________
DI GALLO Frdric

Page 28

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
b) Dbut Fin:
La tche B ne peut se terminer que quand A commence.
Exemple:

A : Gestion d'une version d'un systme.

dlai : +30 jours
B : Arrt de la gestion de l'ancienne version.
On arrte la gestion de l'ancienne version que 15
jours aprs le dbut de la nouvelle version
(exemple: le temps de former le personnel).

c) Dbut dbut:
La tche B doit commencer en mme temps que la tche A.

+/- dlai
L'tape B doit commencer en mme temps que l'tape A.

d) Fin Fin:
La tche B doit se finir en mme temps que la tche A.
Exemple:

A : stage
B : encadrement

L'activit d'encadrement ne se termine qu' la fin du stage.

___________________________________________________________________
DI GALLO Frdric

Page 29

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

3.2.2) Paramtres Cls

a) Dfinition:
Pour dterminer le temps de fin de projet, on utilise des paramtres cls (associs chaque
tche) qui sont les dates au plus tt (D_tt et F_tt) et les dates au plus tard (D_tard et F_tard)
ainsi que la marge qui en dcoule logiquement.
b) Calcul des paramtres:
N.B. Valables pour les liens de type Fin Dbut.

Dates au plus tt:

Si la tche Ti est en dbut du projet (to)
Alors
D_tt (Ti) = to
F_tt (Ti) = D_tt (Ti) + di
Sinon
D_tt (Ti) = max {F_tt (prdcesseur (Ti))}
F_tt (Ti) = D_tt (Ti) + di

Dates au plus tard:

De mme si Ti est en fin de projet (tf)
Alors
F_tard (Ti) = tf
D_tard (Ti) = F_tard (Ti) - di
Sinon
F_tard (Ti) = min { D_tard (successeur (Ti))}
D_tard (Ti) = F_tard (Ti) - di

Marges: c'est la "latitude" dont on dispose pour le temps de ralisation d'une tche. Elle
s'obtient en faisant la diffrence entre le temps au plus tard et le temps au plus tt.
( D_tard D_tt ; F_tard - F_tt )
N.B. Pour les autres types de liens:
20,23
22,25

20,20+X

B
X

22,22+X

23-x,23

B
X

20,23
22,25

X,20

20,23
22,25

25-X,25

20-

B
X

22-

X,22

Chemin critique: c'est le chemin du graphe ayant les plus petites marges ( ou marge nulle
au minimum).
Remarque: la marge ne doit jamais tre ngative!

Si l'on trouve une marge nulle, alors il faut:

Dcomposer certaines tches pour le paralllisme,
Lever certaines contraintes,
Modifier la date de fin.

___________________________________________________________________
DI GALLO Frdric

Page 30

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

EXERCICE : CHEMINS CRITIQUES.

Aprs dcoupage du projet, on obtient les contraintes suivantes:
(A,3) C
(E,7)

(B,12) C,D
(F,3) G

(C,1) E,F
(G,3)

(D,6) E

1) Construire le graphe associ.

Tf=24

A 0,3
3

C 12,13
1

13,16

Dbut
B
12
Diffrence (marge):

0,12
0,12
0

E
7

16,17

D
6

12,18
12,18
0

13,20
17,24

F
3

Fin

18,21

G
3

18,21
0

21,24
21,24
0

2) Dterminer le chemin critique (la plus petite marge).

Ici le chemin B, D, F, G donne 24 jours (avec des marges respective de 0, 0, 0 et 0).
3) Supposons qu'on ajoute une nouvelle dpendance entre F et E (de type dbut vers dbut).
Que devient le chemin critique?
La nouvelle dpendance induit donc ce nouveau graphe:

Dbut

A 0,3
3Tf=25
14,17

B
12
Diffrence (marge):

0,12
0,12
0

C 12,13
1
17,18

D
6

12,18
12,18
0

E
7

F
3

18,25
18,25
18,21
18,22
1

Fin
G
3

21,24
22,25
0

E et F doivent commencer en mme temps (donc dpart 18 pour tous les deux).
Le chemin critique est toujours B,D,F,G mais avec un temps de fin de 25 jours.

___________________________________________________________________
DI GALLO Frdric

Page 31

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

3.3) Diagramme de GANTT

partir de rsultats obtenus du rseau PERT, plus les hypothses sur la ressource
disponible, on construit un planning (calendrier) sous forme de diagramme dont laxe des
abscisses reprsente le temps et laxe des ordonnes reprsente les tches.
Exemple:
A

Remarques :
Selon quon charge le diagramme suivant le temps au plus tt ou le temps au plus
tard: on obtient un diagramme au plus tt ou au plus tard.
On commence toujours par charger le chemin critique.
Priode
Ressource
R1

12

18

24 25

D
F

R3
R2

21

G
A

A
C
E

La tche A peut tre dcale pour ne pas avoir attendre avant denchaner sur les tches C et E.

a) Supposons que lon a 2 ressources R1 et R2.

Diagramme au plus tard: on commence par la fin et lon remonte.
R1

idem
A

R2

C
E

b) Sil y a un fort dsquilibre sur les charges, on peut proposer un autre calendrier en
ajoutant une troisime ressource R3.
NB : Il faut quune tche soit dj une charge dau moins une semaine pour apparatre ici.

___________________________________________________________________
DI GALLO Frdric

Page 32

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

3.4) TD PLANIFICATION
TECHNIQUES PERT ET GRANTT :
Soit le projet reprsent dans le tableau suivant:
Tche
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11

Dure en semaine
5
15
10
8
10
25
4
10
2
1
15

t12
t13
t14

10
12
30

Lien
fin t1 - dbut t3
fin t2 - dbut t4, t5
fin t3 - dbut t6, t8
fin t4- dbut t6
fin t5- dbut t7
fin t6- dbut t11
fin t7- dbut t11
fin t8- dbut t9, t10, t11
fin t9 - dbut t13
fin t10 - dbut t13
dbut t11 dbut t12
fin t11 - dbut t13
fin t12 - dbut t14
fin t13 - fin
fin t14 - fin

Table 1: Enonc de l'exercice Pert et Grantt

1. Calculer les paramtres cls et faites-les figurer sur le rseau Pert.
2. Pour chaque tche, indiquez les dates de dbut au plus-tt, de dbut au plus-tard, de fin
au plus-tt et de fin au plus-tard, ainsi que les marges.

___________________________________________________________________
DI GALLO Frdric

Page 33

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

dbut
t1=5
0,5 8
8,13

t2=15
0,15 0
0,15

t3=10
5,15 8
13,23

t8=10
15,25 23
38,48

t9=2
25,27 49
74,76

t10=1
25,26 50
75,76

t4=8
15,23 0
15,23

t5=10
15,25 10
33,48

t6=25
23,48 0
23,48

t7=4
25,29 13
44,48

t11=15
48,63 0,13
48,76

t13=12
63,75 13
76,88

t12=10
48,58 0
48,58

t14=30
58,88 0
58,88

fin

tf = 88

3. Dterminer le chemin critique. Que devient celui-ci avec l'ajout de la contrainte

suivante : t9 ne peut pas commencer avant t=80 ?
Soit le chemin critique.
Si t9 ne peut pas commencer avant t=80, alors le chemin
critique change et passe par t13 (tf=94).

___________________________________________________________________
DI GALLO Frdric

Page 34

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
4. Proposer deux plannings correspondant au Pert sans date impose, d'abord en
chargeant au plus tt, ensuite au plus tard. Vous les reprsenterez sur un diagramme Grantt.
Au plus tt : on charge dabord le chemin critique que lon affecte R1 soit t1, t3, t6, t12,
t14. Ensuite pour R2, on rpond au dbut et on place le plus tt possible les autres tches.
Au plus tard : on commence par affecter R1 jusqu son dpart
5.

Sachant qu'on dispose des ressources Rl,R2 et R3, ayant les contraintes suivantes:
R1 est absent entre les priodes 26 et 50
R2 ne peut pas commencer avant la priode 8
R3 travaille mi-temps (50 %).
Etablissez un diagramme Grantt.
On commence par affecter R1 jusqu son dpart. La suite du chemin critique passe R2,
qui on confie dabord t4. A R3, on affecte les tches dont les marges sont le double de la
dure. Comme t11 pose problme, on va la partager entre R3 et R1 qui prend la suite son
retour.

___________________________________________________________________
DI GALLO Frdric

Page 35

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

IV. PILOTAGE DE PROJET

Suivre un projet, cest un ensemble dactions faire :
1. Mesurer ltat davancement,
2. Mesurer ce qui a t consomm,
3. Comparer les carts entre les ralisations et les prvisionnels,
4. Expliquer les carts,
5. Proposer les actions correctives.
Tableau de bord :
Les informations codifis sont deux niveaux : le suivi individuel et le suivi du projet.

4.1) Suivi individuel :

Il permet de dtecter les difficults ventuelles dun intervenant partir du rapport
hebdomadaire quil doit fournir.
Nom
xxx
xxx

Tche
Ralisation module 1
Reprsentation syndicale
Runion de coordination
Programmation de test
Maladie
Cong

Temps estim
10
8

Temps pass
3
1

4
1
2

Reste faire
6
5

Rcapitulatif mensuel :
Temps pass : T
Reste faire :
R
Avancement :
A = calcul comme la diffrence entre le R(n-1) et R(n).
Mois
xxx
xxx

Tche
Semaine 1
Semaine 2
A(12) T
R
A T
R
A
4
8
4 5
3
5
B(10)
C(12)

Semaine 3
T
R
A
1
0
3
3
7
3

Total du mois
T
R
A
10
0
12

Coefficient du temps pass sur le projet :

T (n) x 100
nbre de jour (n)
Coefficient de productivit :
A (n) x 100
nbre de jour (n)

___________________________________________________________________
DI GALLO Frdric

Page 36

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

4.2) Suivi du projet

Cela regroupe les informations globales sur le projet qui servent de base un point
d'avancement priodique. Ici, on sintresse aux tches (en dehors des intervenants) mme
celles qui nont pas encore commenc.
mois prcdent

Tche
T

mois courant

Mois (n-1)
Mois (n)
R
A T
R
A

Evolution
de charge

Total
Temps pass

Evolution
globale

Avancement

A
B
C

Evolution de charge restant :

T (n) A (n)

. T (n) R (n-1) + R (n) .

Evolution globale :
. T (n) + R (n) Charge initiale .

___________________________________________________________________
DI GALLO Frdric

Page 37

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

MAINTENANCE
DE
LOGICIEL

___________________________________________________________________
DI GALLO Frdric

Page 38

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

MAINTENANCE DE LOGICIEL
I.

TYPES DE MAINTENANCE .......................................................................................40

1.1) Maintenance perfective (volutive) ...........................................................................40
1.2) Maintenance adaptative ............................................................................................40
1.3) Maintenance corrective .............................................................................................40
1.4) Distribution de l'effort ................................................................................................40
II. PROCESSUS DE LA MAINTENANCE.......................................................................41
2.1) Informations ncessaires pour la maintenance .........................................................41
2.2) Cycles de dveloppement dune correction ................................................................41
2.3) EXERCICES : .............................................................................................................42
III. ESTIMATION DU COUT DE LA MAINTENANCE ..................................................42
3.1) Formules ....................................................................................................................42
3.2) Quatre facteurs multiplicatifs....................................................................................43
IV. LES EFFETS DE LA MAINTENANCE .......................................................................43
V. MAINTENANCE DU CODE ETRANGER ..................................................................44
VI. RE-INGENIERIE ...........................................................................................................44
VII. MAINTENANCE EVOLUTIVE ...................................................................................44
7.1) Techniques de restructuration :.................................................................................45
7.2) Exercice sur les techniques de restructuration..........................................................46

___________________________________________________________________
DI GALLO Frdric

Page 39

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

MAINTENANCE DE LOGICIEL
Objectif de la maintenance :
Grer un processus de modification pour viter que des corrections partielles soient
faites en dehors du processus ditrations.
Fidliser le client.

I.

TYPES DE MAINTENANCE
1.1) Maintenance perfective (volutive)

Elle consiste maintenir les fonctionnalits antrieures tout en ajoutant des nouvelles
fonctionnalits qui modifient profondment l'architecture.
Exemple : 1) changement de OS.
2) changement de SGBD

1.2) Maintenance adaptative

Ajout de petites fonctionnalits qui ne modifie pas l'architecture.
Exemple : 1) Mise leuro.
2) Passage de donnes par fichiers

1.3) Maintenance corrective

Critre important de la qualit qui corrige les anomalies ou erreurs mises jour par le
client et non pas lors des tests de vrification et de validation.

1.4) Distribution de l'effort

Maintenance
corrective

18%

Maintenance
adaptative
Maintenance
perfective

65%

17%

___________________________________________________________________
DI GALLO Frdric

Page 40

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

II. PROCESSUS DE LA MAINTENANCE

Changement
demand

Analyse
dimpact

Planification
de modif.

Perfective

Adaptative

Implmentation
de changements

Edition d1
nouvelle
version

Corrective

2.1) Informations ncessaires pour la maintenance

De lquipe de dveloppement :







Si elle est encore en place,

Analyse : spcifications fonctionnelles,
Listing de sources,
Dossier de test
Algorithmes et les rfrences
Options de compilations, standard utiliss

De lutilisateur :





Anomalie ou erreur (description prcise), ou nouvelle fonctionnalit,

Contexte de lerreur ou fonction,
Donnes du client,
Environnement technique

2.2) Cycles de dveloppement dune correction

dbut

Reconstruction
du contexte de
lerreur

Simplification
du contexte

Analyse
dductive /
Inductive

Intgration de
la solution
Validation de
la correction
non rgressive
Distribution
correction
fin

___________________________________________________________________
DI GALLO Frdric

Page 41

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

2.3) EXERCICES :
1. Quelles sont les difficults induites par l'activit de maintenance ?
Si lquipe de dveloppement est aussi lquipe de maintenance, il faut revenir un travail
ancien sinon il faut comprendre la logique du systme, lge du logiciel , la saturation de
l'architecture
2. Quels sont les facteurs qui influencent le cot de la maintenance ?






Age du logiciel,
Importance de la modification,
Stabilit de lquipe,
Qualit de la documentation technique,
Document de la maintenance

III. ESTIMATION DU COUT DE LA MAINTENANCE

3.1) Formules
Mr Barry W. BOEHM a mesur que les cots annuels de maintenance sont trois quatre
fois ceux du dveloppement d'applications nouvelles. Il proposa en 1982, une formule
destimation du cot de la maintenance. Pour lui, le Taux Annuel de Modification (TAM) est
base sur le pourcentage de ligne source du logiciel corriger dans une anne.
On le dduit de leffort de dveloppement (qui est en fait le cot initial de
dveloppement) :
EAM = TAM x TDL
On obtient un cot de maintenance grossier (exprim en Homme-mois). Pour obtenir le
cot net, on applique des facteurs multiplicatifs. Le bnfice sur le cot total de maintenance
dun systme est proportionnel au pourcentage dinvestissement sur le dveloppement.

Exemple :
Ressource
S1
S2

B
A

S1 = 150 000 $
S2 = 100 000 $

100$
500 000 $
600 000 $

500$

600$

50% de plus au dpart

au final 10% de plus

___________________________________________________________________
DI GALLO Frdric

Page 42

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

3.2) Quatre facteurs multiplicatifs

Ces facteurs prennent une valeur comprise dans [0.7 ; 1.4].
FIAB : (fiabilit) plus on vise la qualit, plus la valeur est grande
EXPA : (exprience application)
EXPL : (exprience logiciel)
inversement
PROM : (langage / environnement)

Exemple :
On a un logiciel qui a cot 236 H-M et on estime le TAM = 15%. On a fix les facteurs
multiplicateurs FIAB = 1.10, EXPA=0.91, EXPL=0.95 et PROM=0.72 (suivant le cot annuel
de la maintenance). La direction dcide d'utiliser une quipe moins d'exprimente par
conomie d'argent (en sachant quun programmeur inexpriment vaut 7 000$ alors quun
expert vaut quand mme 9 000$). Calculer lestimation et la diffrence suppose gagne.

IV. LES EFFETS DE LA MAINTENANCE

On distingue trois catgories deffets :
1. Effet de bord du codage.
Modification ou suppression dun sous programme
Modification ou suppression dun identifiant
Oprations logiques
Test de condition de sortie de boucle
2. Effet de bord de donnes. Il est induit gnralement par une modification dune
structure de donnes ou dun champ.
Rduction ou augmentation de la taille dun tableau ou structure complexe.
Redfinition de format de fichier
Redfinition de constante locale ou globale
Rinitialisation dun pointeur
3. Effet de bord de la documentation. Essentiellement l'adquation entre le code source
et les autres documents.
Remarque : Toute modification du code doit tre reflte dans les documents de maintenance,
le manuel de lutilisateur et le document de conception.

___________________________________________________________________
DI GALLO Frdric

Page 43

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

V.

MAINTENANCE DU CODE ETRANGER

Dfinition :
Un code tranger est un programme (qui date de plus de 15 ans gnralement) auquel
aucun membre de lquipe de maintenance na particip son dveloppement. Aucune
mthodologie du gnie logiciel na t appliqu (pas structur, documentation pauvre et
incomplte et pas de sauvegarde de modification). Que faire dans ce cas l ? ? ?
1. Etudier le programme avant d'apporter une modification.
2. Se familiariser avec le programme en essayant de tracer un graphe de flot.
3. Evaluer l'adquation de la documentation.
4. Insrer vos propres commentaires si vous jugez cela utile la comprhension.
5. Ne jamais liminer du code avant de s'assurer qu'il nest pas utilis ailleurs sinon
avec beaucoup de prcautions.
6. Indiquer absolument toute instruction que vous avez chang sur le listing.
7. Eviter de partager les variables (locales), dclarer les votre pour viter des collisions.

VI. RE-INGENIERIE
Dans le domaine du gnie logiciel, cela signifie processus qui ne consiste pas seulement
redcouvrir la conception des logiciels existants mais aussi utiliser cette information pour
reconstruire le systme existant dans le but d'amliorer toutes ses qualits.

Quand dcider la poursuite ou non de la maintenance?

Cela dpend du cot dun nouveau produit (analyse) par rapport celui de la maintenance.
Si ce dernier est trop lev, il est alors temps d'arrter sa maintenance.

Est-il raisonnable quune entreprise envisage la ringnierie de tous ses logiciels?

Non, il a des logiciel qui n'auront pas voluer, les besoins nvoluant pas. Dautres au
contraire auront besoin d'voluer rapidement.

VII. MAINTENANCE EVOLUTIVE

Considrons un programme spaghettis (prog. non structur). Que faire pour le maintenir?
1. On peut le refaire compltement en utilisant l'atelier de gnie logiciel et les principes
du gnie du logiciel.
2. On peut travailler dessus jusqu' arriver, modification aprs modification, au
changement ncessaire (en introduisant les principales de gnie logiciel).
3. On peut attendre de comprendre le fonctionnement et la structure interne avant toute
modification.
4. On peut refaire une conception, implmenter et tester les parties du logiciel qui exigent
une modification.

Quelle est la meilleure solution?

Cela dpend de ce que l'on veut raliser, l'importance du logiciel et de l'entreprise. A priori,
la deuxime solution est la moins bonne (modification aprs modification).

___________________________________________________________________
DI GALLO Frdric

Page 44

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

7.1) Techniques de restructuration :

Il s'agit de produire la mme fonction que le programme original mais avec une haute qualit.
Exemple : Considrons un programme P qui manipule des donnes A, B, C, D et accomplit
les actions V, W, X, Y, Z et R dfinies par sa table de vrit.
A
B
C
D
V
W
X
Y
Z
R
0
0
0
0
X
0
0
0
1
X
0
0
1
0
X
X
0
0
1
1
X
X
0
1
0
0
X
0
1
0
1
X
0
1
1
0
X
X
0
1
1
1
X
X
1
0
0
0
X
1
0
0
1
X
1
0
1
0
X
X
X
1
0
1
1
X
X
X
1
1
0
0
X
1
1
0
1
X
1
1
1
0
X
X
1
1
1
1
X
X
On en dduit les relations suivantes :
V= ABCD+ABCD+ABCD+ABCD+ABCD+ABCD+ABCD+ABCD
= ABC(D+D)+ABC(D+D)+ABC(D+D)+ABC(D+D) = AC(B+B)+AC(B+B) = (A+A)C
=C
W = CA ;
X = CAB ;
Y = ABC ;
Z = ABC ;
et R = C
On en dduit le graphe de flot :
dbut

A
B

W
B

fin

___________________________________________________________________
DI GALLO Frdric

Page 45

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

7.2) Exercice sur les techniques de restructuration

0.1

Simplification

Soit un programme utilisant les donnes A, B, C, D et ralisant les actions 1, 2, 3 4, 5, 6,

7, 8 dcrit par son graphe de flot suivant:
dbut

6
4

7
5

fin
1. Donner sa table de vrit
A
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1

B
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1

C
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1

D
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1

1
X
X
X
X
X
X
X
X

X
X
X
X
X
X
X
X
X
X
X
X

4
X
X
X
X

X
X
X
X

X
X

X
X
X
X

X
X
X
X

___________________________________________________________________
DI GALLO Frdric

Page 46

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________
2.

Simplifier les actions

1=A;

2=A;

3 = AB ;

6 = AB ;

7 = ABC ;

8 = ABCD.

4 = AB ;

5 = AB+AB = B ;

Pour laction 8, D nest en fait execut quune seule fois. Pour simplifier, on va considrer
une action 10 = ABCD.
3.

Driver un graphe simplifi

Pour simplifier le graphe, il est ncessaire de dissocier laction en deux actions distinctes
51 = AB et 52 = AB pour viter les regroupements.
On en dduit le graphe de flot :
A

dbut

1
B

6
4

3
52

51

C
D

8
10

fin

___________________________________________________________________
DI GALLO Frdric

Page 47

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

0.2
1.

Traduction
Trouver la spcification du programme (crit en pseudo FORTRAN) suivant :
Start:

off:
on:
Cntrld:

Sw-off:
Sw-on:
Switch:
loop:

Get (Time-on, Time-off, Time, Setting, Temp, Switch)

if Switch off goto off
if Switch on goto on
goto Cntrld
if Heating-status on goto Sw-off
goto loop
if Heating-status off goto Sw-on
goto loop
if Time = Time-on goto on
if Time = Time-off goto off
if Time < Time-on goto Start
if Time> Time-off goto Start
if Temp> Setting then goto off
if Temp < Setting then goto on
Heating-status := off
goto Switch
Heating-status := on
Switch-heating
goto Start

C'est un programme qui est un contrleur de systme de chauffage. La valeur Switch peut
prendre trois valeurs : si le systme est sous contrle, alors il peut-tre soit allum, soit teint,
soit dpendant de la minuterie et du thermostat. Si le chauffage est ON, linterrupteur du
chauffage passe OFF et inversement.
2.

Le traduire en un programme quivalent structur (en Ada on en C)

While (true)
{ Get (Time-on, Time-off, Time, Setting, Temp, Switch)
Case Switch of
When OFF if Heating-status = = ON then { Heating-status := OFF;
Switch-heating;
}
When ON if Heating-status = = OFF then { Heating-status := ON;
Switch-heating;
}
When Controled if { Time >= Time-on and Time <= Time-off }
Then { if Temp > Setting and Heating-status = = ON
Then { Heating-status := OFF;
Switch-heating;
} }
Else { if Temp < Setting and Heating-status = = OFF
Then { Heating-status := ON;
Switch-heating;
} }
}

___________________________________________________________________
DI GALLO Frdric

Page 48

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GESTION
DE LA
QUALITE

___________________________________________________________________
DI GALLO Frdric

Page 49

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GESTION DE LA QUALITE
I. DEFINITION................................................................................................................. 51
II. NORMALISATION ...................................................................................................... 51
III. MANUEL QUALITE.................................................................................................... 51

___________________________________________________________________
DI GALLO Frdric

Page 50

01/04/01

Gnie Logiciel.doc
______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

GESTION DE LA QUALITE
I.

DEFINITION

La gestion de la qualit est l'activit qui a pour but de donner confiance au client pour
certifier que le produit livr a une certaine qualit fixe par entreprise. La notion de qualit est
relative et vise promouvoir le produit ou d'entreprise. La gestion de la qualit implique la
dfinition de procds, le choix de standards et procdures, et surtout le contrle de lquipe
de dveloppement qui doit suivre les dispositifs mis en place pour les objectifs qualit.
Remarques : La gestion s'articule autour de trois activits :
 Assurance qualit: concerne la dfinition de la manire dont lentreprise
comptait atteindre la qualit.
 Planification qualit: slection de procdures et standards appropries pour un
projet bien dtermin.
 Contrle qualit: implique l'observation du processus de dveloppement pour
assurer que les procdures d'assurance qualit ont t suivies.

II. NORMALISATION
La normalisation rpond au souci dinterchangeabilit (ou interoprabilit). Dans le
domaine du logiciel, on distingue trois niveaux:
1er niveau : caractristiques,
2ime niveau : modle (Merise),
3ime niveau : la qualit (ISO 9001).
a)

Classe ISO : 9001 (concerne toute la vie du logiciel), 9002 (ne concerne pas la
conception), 9003 (ne concerne que la mise en service et la maintenance).
b) Classe ISO 9004 : concerne le contrle qualit (audit).
En fait, elle dfinit les principes de base pour mettre en uvre le contrle qualit les
principaux concepts : politique qualit, gestion qualit, assurance qualit, contrle qualit.

III. MANUEL QUALITE.

Le manuel qualit est le document qui contient le systme mis en uvre pour assurer la
qualit. Cest un engagement de la direction. On distingue deux types d'informations:
Informations techniques: standards, procdures...
Informations mthodologiques: mthodes de spcification, conception, dveloppement.
La certification et valable trois ans en France (dlivr par lAFNOR). Cet organisme
dfinit la qualit ainsi: cest l'ensemble des proprits et caractristiques d'un produit ou
d'un service qui lui confre l'aptitude satisfaire des besoins exprims ou implicite .

___________________________________________________________________
DI GALLO Frdric

Page 51

01/04/01