Génie Logiciel

Embed Size (px)

Citation preview

71659560.doc ______________________________________________________________________________

COURS DE GENIE LOGICIELCycle Probatoire

CNAM BORDEAUX 1999-2000 ___________________________________________________________________DI GALLO Frdric Page 1 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL..................................................7I. FONDEMENT DU TEST....................................................................................................7 1.1) Cycle de dveloppement de test...................................................................................8 1.2) Mise au point Inductive...............................................................................................9 1.2) Mise au point Dductive..............................................................................................9 II. TECHNIQUE DE TEST...................................................................................................10 2.1) Test Boite blanche ...............................................................................................10 2.2) Test Boite noire ....................................................................................................13 III. TD: TEST, VRIFICATION ET VALIDATION...............................................................................15 Exercice 1: Test Bote Blanche..........................................................................................15 Exercice 2: Test statistique................................................................................................16

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

GESTION DE PROJET.............................................26I. RAPPELS...........................................................................................................................26 1.1) Dfinitions.................................................................................................................26 1.2) Dfinitions des types de Gestion................................................................................27 1.3) Activits de Gestion...................................................................................................27 II. ESTIMATION DE CHARGE..........................................................................................28 2.1) Dfinitions.................................................................................................................28 2.2) Diffrentes mthodes d'estimation de charge............................................................28 III. PLANIFICATION DE PROJET.....................................................................................31 3.1) Dfinition ..................................................................................................................31 3.2) Rseau PERT (Profit Evaluation and Review Technique)........................................31 3.3) Diagramme de GANTT..............................................................................................37 3.4) TD PLANIFICATION..............................................................................................38 IV. PILOTAGE DE PROJET................................................................................................41 4.1) Suivi individuel :........................................................................................................41 4.2) Suivi du projet............................................................................................................42

MAINTENANCE DE LOGICIEL............................46I. TYPES DE MAINTENANCE...........................................................................................46 1.1) Maintenance perfective (volutive)...........................................................................46 1.2) Maintenance adaptative............................................................................................46

___________________________________________________________________DI GALLO Frdric Page 2 13/10/2011

71659560.doc ______________________________________________________________________________ 1.3) Maintenance corrective.............................................................................................46 1.4) Distribution de l'effort................................................................................................46 II. PROCESSUS DE LA MAINTENANCE.........................................................................47 2.1) Informations ncessaires pour la maintenance.........................................................47 2.2) Cycles de dveloppement dune correction................................................................47 2.3) EXERCICES :.............................................................................................................48 III. ESTIMATION DU COUT DE LA MAINTENANCE...................................................48 3.1) Formules....................................................................................................................48 3.2) Quatre facteurs multiplicatifs....................................................................................49 IV. LES EFFETS DE LA MAINTENANCE........................................................................49 V. MAINTENANCE DU CODE ETRANGER....................................................................50 VI. RE-INGENIERIE............................................................................................................50 VII. MAINTENANCE EVOLUTIVE...................................................................................50 7.1) Techniques de restructuration :.................................................................................52 7.2) Exercice sur les techniques de restructuration..........................................................53

GESTION DE LA QUALIT...................................59I. DEFINITION.....................................................................................................................59 II. NORMALISATION.........................................................................................................59 III. MANUEL QUALITE......................................................................................................59

___________________________________________________________________DI GALLO Frdric Page 3 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL

___________________________________________________________________DI GALLO Frdric Page 4 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL 7I. FONDEMENT DU TEST 7 1.1) Cycle de dveloppement de test 8 1.2) Mise au point Inductive 9 1.2) Mise au point Dductive 9 II. TECHNIQUE DE TEST 10 2.1) Test Boite blanche 10 2.2) Test Boite noire 13 III. TD: TEST, VRIFICATION ET VALIDATION 15 Exercice 1: Test Bote Blanche 15 Exercice 2: Test statistique 16

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

GESTION DE PROJET 26I. RAPPELS 26 1.1) Dfinitions 26 1.2) Dfinitions des types de Gestion 27 1.3) Activits de Gestion 27 II. ESTIMATION DE CHARGE 28 2.1) Dfinitions 28 2.2) Diffrentes mthodes d'estimation de charge 28 III. PLANIFICATION DE PROJET 31 3.1) Dfinition 31 3.2) Rseau PERT (Profit Evaluation and Review Technique) 31 3.3) Diagramme de GANTT 37 3.4) TD PLANIFICATION 38 IV. PILOTAGE DE PROJET 41 4.1) Suivi individuel : 41 4.2) Suivi du projet 42

MAINTENANCE DE LOGICIEL 46I. TYPES DE MAINTENANCE 46 1.1) Maintenance perfective (volutive) 46 1.2) Maintenance adaptative 46 1.3) Maintenance corrective 46

___________________________________________________________________DI GALLO Frdric Page 5 13/10/2011

71659560.doc ______________________________________________________________________________ 1.4) Distribution de l'effort 46 II. PROCESSUS DE LA MAINTENANCE 47 2.1) Informations ncessaires pour la maintenance 47 2.2) Cycles de dveloppement dune correction 47 2.3) EXERCICES : 48 III. ESTIMATION DU COUT DE LA MAINTENANCE 48 3.1) Formules 48 3.2) Quatre facteurs multiplicatifs 49 IV. LES EFFETS DE LA MAINTENANCE 49 V. MAINTENANCE DU CODE ETRANGER 50 VI. RE-INGENIERIE 50 VII. MAINTENANCE EVOLUTIVE 50 7.1) Techniques de restructuration : 52 7.2) Exercice sur les techniques de restructuration 53

GESTION DE LA QUALIT 59I. DEFINITION 59 II. NORMALISATION 59 III. MANUEL QUALITE. 59

___________________________________________________________________DI GALLO Frdric Page 6 13/10/2011

71659560.doc ______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

TEST DE LOGICIELIntroduction :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 7 13/10/2011

71659560.doc ______________________________________________________________________________

1.1) Cycle de dveloppement de testLorsqu'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 programme

Spcification du test Scnario de test rsultat attendu

Chargement du prog. et de son environnement

Excution du test

Comparaison de rsultats correct incorrecton met une hypothse qui expliquerait lanomalie

Induction Archivage du test + rsultats Analyse de rsultats Dduction Biblio. Modification Induite dans le testOn limine les cas jusqu tomber sur la problmatique

dans le prog.Gestion de configuration

___________________________________________________________________DI GALLO Frdric Page 8 13/10/2011

71659560.doc ______________________________________________________________________________

1.2) Mise au point InductiveOn met une hypothse sur lensemble.Localiser toutes les donnes pertinentes Organiser les donnes (classes dquivalence) Etudier les relations et dpendances fonctionnelles Formuler (mettre) une hypothse Inconsistance Prouver lhypothse (Est-elle pertinente ?) Corriger lerreur

Donnes insuffisantes

1.2) Mise au point DductiveOn traite chaque cause sparment.Enumrer toutes les causes possibles Elimination progressive de toutes les causes sauf une Emettre, amliorer, raffiner lhypothse Inconsistance Prouver lhypothse (Est-elle pertinente ?) Corriger lerreur Rassembler plus de donnes

___________________________________________________________________DI GALLO Frdric Page 9 13/10/2011

71659560.doc ______________________________________________________________________________

II. TECHNIQUE DE TESTPlusieurs 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 Espace cas possibles gnrateur

Cela revient chantillonner de faon reprsentative.

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 dynamiquePVIS Instrument de visualisation Composante donnes Elments entrs DE code Suivi du chemin dexcution Trace DS Domaine de rsultat

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 10 13/10/2011

71659560.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 :

Remarque :

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

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

23

46

8 911 DI GALLO Frdric

7 10

5

___________________________________________________________________Page 11 13/10/2011

71659560.doc ______________________________________________________________________________ On en dduit le graphe de flot suivant : 1 R4 2 3 6 8 11 R3 9 10 7 R2 4 5 R1

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 cle) g=m+1; else d=m-1; } } Calculer le nombre cyclomatique de cette procdure.

___________________________________________________________________DI GALLO Frdric Page 12 13/10/2011

71659560.doc ______________________________________________________________________________

2.2) Test Boite noire On ignore la structure de codage du logicielPrincipe : 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 : = 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 13 13/10/2011

71659560.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 vrifieladquation 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 14 13/10/2011

71659560.doc ______________________________________________________________________________

III. TD: Test, Vrification et ValidationExercice 1: Test Bote BlancheTrouver 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 3 5 6 7 8 For i < n 9 10 While k inf 4 While incr > 1

14

11 13 12 On a donc 14 noeuds et 18 arcs diffrentes ce qui donne Nb Cycl = 18 14 + 2 = 6

___________________________________________________________________DI GALLO Frdric Page 15 13/10/2011

71659560.doc ______________________________________________________________________________ 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 statistique1. 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 16 13/10/2011

71659560.doc ______________________________________________________________________________

FIABILITE DU LOGICIEL

___________________________________________________________________DI GALLO Frdric Page 17 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL..................................................7I. FONDEMENT DU TEST....................................................................................................7 1.1) Cycle de dveloppement de test...................................................................................8 1.2) Mise au point Inductive...............................................................................................9 1.2) Mise au point Dductive..............................................................................................9 II. TECHNIQUE DE TEST...................................................................................................10 2.1) Test Boite blanche ...............................................................................................10 2.2) Test Boite noire ....................................................................................................13 III. TD: TEST, VRIFICATION ET VALIDATION...............................................................................15 Exercice 1: Test Bote Blanche..........................................................................................15 Exercice 2: Test statistique................................................................................................16

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

GESTION DE PROJET.............................................26I. RAPPELS...........................................................................................................................26 1.1) Dfinitions.................................................................................................................26 1.2) Dfinitions des types de Gestion................................................................................27 1.3) Activits de Gestion...................................................................................................27 II. ESTIMATION DE CHARGE..........................................................................................28 2.1) Dfinitions.................................................................................................................28 2.2) Diffrentes mthodes d'estimation de charge............................................................28 III. PLANIFICATION DE PROJET.....................................................................................31 3.1) Dfinition ..................................................................................................................31 3.2) Rseau PERT (Profit Evaluation and Review Technique)........................................31 3.3) Diagramme de GANTT..............................................................................................37 3.4) TD PLANIFICATION..............................................................................................38 IV. PILOTAGE DE PROJET................................................................................................41 4.1) Suivi individuel :........................................................................................................41 4.2) Suivi du projet............................................................................................................42

MAINTENANCE DE LOGICIEL............................46I. TYPES DE MAINTENANCE...........................................................................................46 1.1) Maintenance perfective (volutive)...........................................................................46 1.2) Maintenance adaptative............................................................................................46 1.3) Maintenance corrective.............................................................................................46

___________________________________________________________________DI GALLO Frdric Page 18 13/10/2011

71659560.doc ______________________________________________________________________________ 1.4) Distribution de l'effort................................................................................................46 II. PROCESSUS DE LA MAINTENANCE.........................................................................47 2.1) Informations ncessaires pour la maintenance.........................................................47 2.2) Cycles de dveloppement dune correction................................................................47 2.3) EXERCICES :.............................................................................................................48 III. ESTIMATION DU COUT DE LA MAINTENANCE...................................................48 3.1) Formules....................................................................................................................48 3.2) Quatre facteurs multiplicatifs....................................................................................49 IV. LES EFFETS DE LA MAINTENANCE........................................................................49 V. MAINTENANCE DU CODE ETRANGER....................................................................50 VI. RE-INGENIERIE............................................................................................................50 VII. MAINTENANCE EVOLUTIVE...................................................................................50 7.1) Techniques de restructuration :.................................................................................52 7.2) Exercice sur les techniques de restructuration..........................................................53

GESTION DE LA QUALIT...................................59I. DEFINITION.....................................................................................................................59 II. NORMALISATION.........................................................................................................59 III. MANUEL QUALITE......................................................................................................59

___________________________________________________________________DI GALLO Frdric Page 19 13/10/2011

71659560.doc ______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

FIABILITE DU LOGICIELCest 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 & FAUTEUn 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. O e Sorties possibles

PROGRAMME

II. AMELIORATION DE LA FIAIBILITEEst-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 20 13/10/2011

71659560.doc ______________________________________________________________________________

III. METRIQUE DE LA FIABILITE3.1) Probabilit dune panneCest 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 panneCest 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 pannesCest 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) DisponibilitCest 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 DEFAUTClasse 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 21 13/10/2011

71659560.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 Permanente et non corruptrice Transitoire et non corruptrice Transitoire et corruptrice Mtrique

Le systme nest plus oprationnel quelque soit la Dispo : 1 par 1000 jours carte Les donnes sur la bande magntique ne peuvent tre lue sur certaines cartes (non endommages) Le montant nest pas correctement report sur le compte. Taux de panne Inqualifiable (ne devrait jamais arriver).

___________________________________________________________________DI GALLO Frdric Page 22 13/10/2011

71659560.doc ______________________________________________________________________________

GESTION DE PROJET

___________________________________________________________________DI GALLO Frdric Page 23 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL..................................................7I. FONDEMENT DU TEST....................................................................................................7 1.1) Cycle de dveloppement de test...................................................................................8 1.2) Mise au point Inductive...............................................................................................9 1.2) Mise au point Dductive..............................................................................................9 II. TECHNIQUE DE TEST...................................................................................................10 2.1) Test Boite blanche ...............................................................................................10 2.2) Test Boite noire ....................................................................................................13 III. TD: TEST, VRIFICATION ET VALIDATION...............................................................................15 Exercice 1: Test Bote Blanche..........................................................................................15 Exercice 2: Test statistique................................................................................................16

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

GESTION DE PROJET.............................................26I. RAPPELS...........................................................................................................................26 1.1) Dfinitions.................................................................................................................26 1.2) Dfinitions des types de Gestion................................................................................27 1.3) Activits de Gestion...................................................................................................27 II. ESTIMATION DE CHARGE..........................................................................................28 2.1) Dfinitions.................................................................................................................28 2.2) Diffrentes mthodes d'estimation de charge............................................................28 III. PLANIFICATION DE PROJET.....................................................................................31 3.1) Dfinition ..................................................................................................................31 3.2) Rseau PERT (Profit Evaluation and Review Technique)........................................31 3.3) Diagramme de GANTT..............................................................................................37 3.4) TD PLANIFICATION..............................................................................................38 IV. PILOTAGE DE PROJET................................................................................................41 4.1) Suivi individuel :........................................................................................................41 4.2) Suivi du projet............................................................................................................42

MAINTENANCE DE LOGICIEL............................46I. TYPES DE MAINTENANCE...........................................................................................46 1.1) Maintenance perfective (volutive)...........................................................................46 1.2) Maintenance adaptative............................................................................................46

___________________________________________________________________DI GALLO Frdric Page 24 13/10/2011

71659560.doc ______________________________________________________________________________ 1.3) Maintenance corrective.............................................................................................46 1.4) Distribution de l'effort................................................................................................46 II. PROCESSUS DE LA MAINTENANCE.........................................................................47 2.1) Informations ncessaires pour la maintenance.........................................................47 2.2) Cycles de dveloppement dune correction................................................................47 2.3) EXERCICES :.............................................................................................................48 III. ESTIMATION DU COUT DE LA MAINTENANCE...................................................48 3.1) Formules....................................................................................................................48 3.2) Quatre facteurs multiplicatifs....................................................................................49 IV. LES EFFETS DE LA MAINTENANCE........................................................................49 V. MAINTENANCE DU CODE ETRANGER....................................................................50 VI. RE-INGENIERIE............................................................................................................50 VII. MAINTENANCE EVOLUTIVE...................................................................................50 7.1) Techniques de restructuration :.................................................................................52 7.2) Exercice sur les techniques de restructuration..........................................................53

GESTION DE LA QUALIT...................................59I. DEFINITION.....................................................................................................................59 II. NORMALISATION.........................................................................................................59 III. MANUEL QUALITE......................................................................................................59

___________________________________________________________________DI GALLO Frdric Page 25 13/10/2011

71659560.doc ______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

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

1.1) DfinitionsDu 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 Gestion des Ressources

Dlai 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 26 13/10/2011

71659560.doc ______________________________________________________________________________

1.2) Dfinitions des types de GestionGestion de dlai: elle consiste dterminer un parcours qu'on va suivre, un calendrier deralisation et une matrise d'enveloppe temps.

Gestion de ressources: le moyen constitu du budget du projet donc il s'agit de transformerle budget en travail, locaux, matriels, dplacements dans ce but.

Gestion des productions: l'objectif d'un projet doit son terme tre concrtise par une ouplusieurs 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 27 13/10/2011

71659560.doc ______________________________________________________________________________

II. ESTIMATION DE CHARGE2.1) DfinitionsDfinition: 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 charge1) La non mthodeExemple: 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 28 13/10/2011

71659560.doc ______________________________________________________________________________

3) Mthode de rpartitions proportionnelleElle 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 / DlaiAvec: 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 projetSimple Moyen Complexe

Charge en M/h Dlai en Ma = 3.2 b = 1.05 a=3 b = 1.12 a = 2.8 b = 1.2 c = 2.5 d = 0.38 c = 2.5 d = 0.35 c = 2.5 d = 0.32

___________________________________________________________________DI GALLO Frdric Page 29 13/10/2011

71659560.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)

EXERCICESExercice 1: Estimer la taille moyenne de l'quipe qui faudrait prvoir pour dvelopper unlogiciel 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 del'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 30 13/10/2011

71659560.doc ______________________________________________________________________________

III. PLANIFICATION DE PROJET3.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: Dbu t A 3 C 2 E 4 B 7 D 3 Fin

3.2.1) Les types de liensIl 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 da Exemple: B db I dlai (en jour)

A

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

BDI GALLO Frdric

___________________________________________________________________Page 31 13/10/2011

71659560.doc ______________________________________________________________________________

___________________________________________________________________DI GALLO Frdric Page 32 13/10/2011

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

A

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

B

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

A

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

Bd) Fin Fin:

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

A

A : stage B : encadrement

B

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

___________________________________________________________________DI GALLO Frdric Page 33 13/10/2011

71659560.doc ______________________________________________________________________________

3.2.2) Paramtres Clsa) 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: 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 N.B. Valables pour les liens de type Fin Dbut.

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:

A3

20,23 22,25

A3

20,23 22,25

A3

20,23 22,25

X,20 X,22

BX

20,20+X 22,22+X

BX

23-x,23 25-X,25

BX

2022-

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,

___________________________________________________________________DI GALLO Frdric Page 34 13/10/2011

71659560.doc ______________________________________________________________________________ Modifier la date de fin.

___________________________________________________________________DI GALLO Frdric Page 35 13/10/2011

71659560.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. A 0,3 3 13,16 B 0,12 12 0,12 0 0 C 12,13 1 16,17 D 12,18 6 12,18 0 13,20 17,24 21,24 21,24

Tf=24 Dbut

E 7 3

Fin G 3

Diffrence (marge):

F 18,21 3 18,21 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: A 0,3 Tf=25 3 14,17 B 0,12 12 0,12 0 0 C 12,13 1 17,18 D 12,18 6 12,18 0 E 7 3 18,25 18,25 21,24 22,25 Fin G 3

Dbut

Diffrence (marge):

F 18,21 3 18,22 1

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 36 13/10/2011

71659560.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 B C D E F G

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 R3 R2 A A C ELa tche A peut tre dcale pour ne pas avoir attendre avant denchaner sur les tches C et E.

1

3 B

9

12 D

18

21

24 25

F G

a) Supposons que lon a 2 ressources R1 et R2.Diagramme au plus tard: on commence par la fin et lon remonte. R1 R2 idem A 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 37 13/10/2011

71659560.doc ______________________________________________________________________________

3.4) TD PLANIFICATIONTECHNIQUES PERT ET GRANTT :Soit le projet reprsent dans le tableau suivant: Tche t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 Dure en semaine 5 15 10 8 10 25 4 10 2 1 15 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 38 13/10/2011

71659560.doc ______________________________________________________________________________

dbutt1=5 0,5 8 8,13 t3=10 5,15 8 13,23 t8=10 15,25 23 38,48 t4=8 15,23 0 15,23 t6=25 23,48 0 23,48 t2=15 0,15 0 0,15 t5=10 15,25 10 33,48 t7=4 25,29 13 44,48

t9=2 25,27 49 74,76

t10=1 25,26 50 75,76

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

t12=10 48,58 0 48,58

t13=12 63,75 13 76,88

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 39 13/10/2011

71659560.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 40 13/10/2011

71659560.doc ______________________________________________________________________________

IV. PILOTAGE DE PROJETSuivre 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) T 1 3 Semaine 3 R A 0 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 41 13/10/2011

71659560.doc ______________________________________________________________________________

4.2) Suivi du projetCela 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 mois courant

Tche T A B C

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

Evolution de charge

Total Temps pass

Evolution globale

Avancement

Evolution de charge restant : T (n) A (n) Evolution globale :

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

. T (n) + R (n) Charge initiale .

___________________________________________________________________DI GALLO Frdric Page 42 13/10/2011

71659560.doc ______________________________________________________________________________

MAINTENANCE DE LOGICIEL

___________________________________________________________________DI GALLO Frdric Page 43 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL..................................................7I. FONDEMENT DU TEST....................................................................................................7 1.1) Cycle de dveloppement de test...................................................................................8 1.2) Mise au point Inductive...............................................................................................9 1.2) Mise au point Dductive..............................................................................................9 II. TECHNIQUE DE TEST...................................................................................................10 2.1) Test Boite blanche ...............................................................................................10 2.2) Test Boite noire ....................................................................................................13 III. TD: TEST, VRIFICATION ET VALIDATION...............................................................................15 Exercice 1: Test Bote Blanche..........................................................................................15 Exercice 2: Test statistique................................................................................................16

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

GESTION DE PROJET.............................................26I. RAPPELS...........................................................................................................................26 1.1) Dfinitions.................................................................................................................26 1.2) Dfinitions des types de Gestion................................................................................27 1.3) Activits de Gestion...................................................................................................27 II. ESTIMATION DE CHARGE..........................................................................................28 2.1) Dfinitions.................................................................................................................28 2.2) Diffrentes mthodes d'estimation de charge............................................................28 III. PLANIFICATION DE PROJET.....................................................................................31 3.1) Dfinition ..................................................................................................................31 3.2) Rseau PERT (Profit Evaluation and Review Technique)........................................31 3.3) Diagramme de GANTT..............................................................................................37 3.4) TD PLANIFICATION..............................................................................................38 IV. PILOTAGE DE PROJET................................................................................................41 4.1) Suivi individuel :........................................................................................................41 4.2) Suivi du projet............................................................................................................42

MAINTENANCE DE LOGICIEL............................46I. TYPES DE MAINTENANCE...........................................................................................46 1.1) Maintenance perfective (volutive)...........................................................................46 1.2) Maintenance adaptative............................................................................................46

___________________________________________________________________DI GALLO Frdric Page 44 13/10/2011

71659560.doc ______________________________________________________________________________ 1.3) Maintenance corrective.............................................................................................46 1.4) Distribution de l'effort................................................................................................46 II. PROCESSUS DE LA MAINTENANCE.........................................................................47 2.1) Informations ncessaires pour la maintenance.........................................................47 2.2) Cycles de dveloppement dune correction................................................................47 2.3) EXERCICES :.............................................................................................................48 III. ESTIMATION DU COUT DE LA MAINTENANCE...................................................48 3.1) Formules....................................................................................................................48 3.2) Quatre facteurs multiplicatifs....................................................................................49 IV. LES EFFETS DE LA MAINTENANCE........................................................................49 V. MAINTENANCE DU CODE ETRANGER....................................................................50 VI. RE-INGENIERIE............................................................................................................50 VII. MAINTENANCE EVOLUTIVE...................................................................................50 7.1) Techniques de restructuration :.................................................................................52 7.2) Exercice sur les techniques de restructuration..........................................................53

GESTION DE LA QUALIT...................................59I. DEFINITION.....................................................................................................................59 II. NORMALISATION.........................................................................................................59 III. MANUEL QUALITE......................................................................................................59

___________________________________________________________________DI GALLO Frdric Page 45 13/10/2011

71659560.doc ______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

MAINTENANCE DE LOGICIELObjectif 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 MAINTENANCE1.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 adaptativeAjout de petites fonctionnalits qui ne modifie pas l'architecture. Exemple : 1) Mise leuro. 2) Passage de donnes par fichiers

1.3) Maintenance correctiveCritre 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'effortMaintenance corrective Maintenance adaptative Maintenance perfective

18%

17%

65%

___________________________________________________________________DI GALLO Frdric Page 46 13/10/2011

71659560.doc ______________________________________________________________________________

II. PROCESSUS DE LA MAINTENANCE

Changement demand

Analyse dimpact

Planification de modif.

Implmentation de changements

Edition d1 nouvelle version

Perfective

Adaptative

Corrective

2.1) Informations ncessaires pour la maintenanceDe 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 correctiondbut 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 47 13/10/2011

71659560.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 MAINTENANCE3.1) FormulesMr 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 500$ 50% de plus au dpart au final 10% de plus 600$

100$ S1 = 150 000 $ 500 000 $ S2 = 100 000 $ 600 000 $

___________________________________________________________________DI GALLO Frdric Page 48 13/10/2011

71659560.doc ______________________________________________________________________________

3.2) Quatre facteurs multiplicatifsCes 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 MAINTENANCEOn 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 49 13/10/2011

71659560.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-INGENIERIEDans 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 EVOLUTIVEConsidrons 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.

___________________________________________________________________DI GALLO Frdric Page 50 13/10/2011

71659560.doc ______________________________________________________________________________

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 51 13/10/2011

71659560.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 : C dbut C

RB

A B

V

A

WB B

Y

Z

X

fin

___________________________________________________________________DI GALLO Frdric Page 52 13/10/2011

71659560.doc ______________________________________________________________________________

7.2) Exercice sur les techniques de restructuration0.1 SimplificationSoit 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: A dbut A

1B B

B

2

B

6 4 3 5C C

7D D

8

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 2 3 4 X X X X 5 6 7 8

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

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

X

___________________________________________________________________DI GALLO Frdric Page 53 13/10/2011

71659560.doc ______________________________________________________________________________ 2. 1=A; 6 = AB ; Simplifier les actions 2=A; 7 = ABC ; 3 = AB ; 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 A

1B B

B

2

B

6 4 3 52 51C D C

7

D

8 10

fin

___________________________________________________________________DI GALLO Frdric Page 54 13/10/2011

71659560.doc ______________________________________________________________________________

0.2

Traduction

1. Trouver la spcification du programme (crit en pseudo FORTRAN) suivant : Start: 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

off: on: Cntrld:

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

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 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 55 13/10/2011

71659560.doc ______________________________________________________________________________

GESTION DE LA QUALITE

___________________________________________________________________DI GALLO Frdric Page 56 13/10/2011

71659560.doc ______________________________________________________________________________

TEST DE LOGICIEL 7I. FONDEMENT DU TEST 7 1.1) Cycle de dveloppement de test 8 1.2) Mise au point Inductive 9 1.2) Mise au point Dductive 9 II. TECHNIQUE DE TEST 10 2.1) Test Boite blanche 10 2.2) Test Boite noire 13 III. TD: TEST, VRIFICATION ET VALIDATION 15 Exercice 1: Test Bote Blanche 15 Exercice 2: Test statistique 16

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

GESTION DE PROJET 26I. RAPPELS 26 1.1) Dfinitions 26 1.2) Dfinitions des types de Gestion 27 1.3) Activits de Gestion 27 II. ESTIMATION DE CHARGE 28 2.1) Dfinitions 28 2.2) Diffrentes mthodes d'estimation de charge 28 III. PLANIFICATION DE PROJET 31 3.1) Dfinition 31 3.2) Rseau PERT (Profit Evaluation and Review Technique) 31 3.3) Diagramme de GANTT 37 3.4) TD PLANIFICATION 38 IV. PILOTAGE DE PROJET 41 4.1) Suivi individuel : 41 4.2) Suivi du projet 42

MAINTENANCE DE LOGICIEL 46I. TYPES DE MAINTENANCE 46 1.1) Maintenance perfective (volutive) 46 1.2) Maintenance adaptative 46 1.3) Maintenance corrective 46

___________________________________________________________________DI GALLO Frdric Page 57 13/10/2011

71659560.doc ______________________________________________________________________________ 1.4) Distribution de l'effort 46 II. PROCESSUS DE LA MAINTENANCE 47 2.1) Informations ncessaires pour la maintenance 47 2.2) Cycles de dveloppement dune correction 47 2.3) EXERCICES : 48 III. ESTIMATION DU COUT DE LA MAINTENANCE 48 3.1) Formules 48 3.2) Quatre facteurs multiplicatifs 49 IV. LES EFFETS DE LA MAINTENANCE 49 V. MAINTENANCE DU CODE ETRANGER 50 VI. RE-INGENIERIE 50 VII. MAINTENANCE EVOLUTIVE 50 7.1) Techniques de restructuration : 52 7.2) Exercice sur les techniques de restructuration 53

GESTION DE LA QUALIT 59I. DEFINITION 59 II. NORMALISATION 59 III. MANUEL QUALITE. 59

___________________________________________________________________DI GALLO Frdric Page 58 13/10/2011

71659560.doc ______________________________________________________________________________

GENIE LOGICIEL CNAM BORDEAUX 1999-2000

GESTION DE LA QUALITI. 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. NORMALISATIONLa 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.

___________________________________________________________________DI GALLO Frdric Page 59 13/10/2011

71659560.doc ______________________________________________________________________________ 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 60 13/10/2011