Gl Cours Slides

Genie LogicielPrincipes et Techniques

Pierre Gerard

IUT de Villetaneuse - Universite de Paris 13

Licence Pro. FC 2007/2008

LATEX

Pierre Gerard Genie Logiciel

MotivationsCycle de vie dun logiciel

Qualites attendues dun logicielPrincipes du Genie LogicielMaturite du processus de developpement logiciel

Materiel et logiciel

Syste`mes informatiques

80 % de logiciel20 % de materiel

Depuis quelques annees, la fabrication du materiel est assureepar quelques fabricants seulement

Le materiel est relativement fiableLe marche est standardise

Les proble`mes lies a` linformatique sont essentiellement desproble`mes de Logiciel




Specificites du logiciel

Un produit immateriel, dont lexistence est independante dusupport physique

Semblable a` une uvre dart (roman, partition...)

Un objet technique fortement contraint

Fonctionne ou ne fonctionne pasStructure complexeRele`ve des modes de travail du domaine technique

Un cycle de production different

La reproduction pose peu de proble`mes, seule la premie`re copiedun logiciel a un coutProduction a` luniteSemblable au Genie Civil (ponts, routes...)




Un processus de fabrication original

Le logiciel partage des proprietes contradictoires avec lart, lestechnologies et le Genie Civil

Les possibilites de reutiliser les savoir-faire des autrestechnologies sont (tre`s) limitees

Compte tenu du cycle de production, il faut bien faire tout desuite

La qualite du processus de fabrication est garante de laqualite du produit




La Crise du logiciel

Etude sur 8 380 projets (Standish Group, 1995)

Succe`s : 16 %Problematique : 53 % (bujet ou delais non respectes, defaut defonctionnalites)Echec : 31 % (abandonne)

Le taux de succe`s decrot avec la taille des projets et la tailledes entreprises




Le Genie Logiciel

Conference de lOTAN a` Garmish, Allemagne (1968)

Linformatique ne repond pas aux attentes quelle susciteLinformatique coute tre`s cher et desorganise les entreprises ouorganisations

Introduction de lexpression Genie Logiciel (SoftwareEngineering)

Comment faire des logiciels de qualite ?Quattend-on dun logiciel ? Quels sont les crite`res de qualitepour un logiciel ?




Utilite

Adequation entre

Le besoin effectif de lutilisateurLes fonctions offertes par le logiciel

Solutions :

Emphase sur lanalyse des besoinsAmeliorer la communication (langage commun, demarcheparticipative)Travailler avec rigueur




Utilisabilite

Effectivite, efficacite et satisfaction avec laquelle desutilisateurs specifies accomplissent des objectifs specifies dansun environnement particulier

Facilite dapprentissage : comprendre ce que lon peut faireavec le logiciel, et savoir comment le faireFacilite dutilisation : importance de leffort necessaire pourutiliser le logiciel a` des fins donneesSolutions :

Analyse du mode operatoire des utilisateursAdapter lergonomie des logiciels aux utilisateurs




Fiabilite

Correction, justesse, conformite : le logiciel est conforme a` sesspecifications, les resultats sont ceux attendus

Robustesse, surete : le logiciel fonctionne raisonnablement entoutes circonstances, rien de catastrophique ne peut survenir,meme en dehors des conditions dutilisation prevues

Mesures :MTBF : Mean Time Between FailuresDisponibilite (pourcentatge du temps pendant lequel le syste`meest utilisable) et Taux derreur (nombre derreurs par KLOC)

Solutions :Utiliser des methodes formelles, des langages et des methodesde programmation de haut niveauVerifications, testsProgiciels




Interoperabilite, couplabilite

Un logiciel doit pouvoir interagir en synergie avec dautreslogiciels

Solutions :

Bases de donnees (decouplage donnees/traitements) Externaliser certaines fonctions en utilisant des Middleware avec une API (Application Program Interface)bien definieStandardisation des formats de fichiers (XML...) et desprotocoles de communication (CORBA...)Les ERP (Entreprise Resources Planning)




Performance

Les logiciels doivent satisfaire aux contraintes de tempsdexecution

Solutions :

Logiciels plus simplesVeiller a` la complexite des algorithmesMachines plus performantes




Portabilite

Un meme logiciel doit pouvoir fonctionner sur plusieursmachines

Solutions :

Rendre le logiciel independant de son environnementdexecution (voir interoperabilite)Machines virtuelles




Reutilisabilte

On peut esperer des gains considerables car dans la plupartdes logiciels :

80 % du code est du tout venant quon retrouve a` peupre`s partout20 % du code est specifique

Solutions :

Abstraction, genericite (ex : MCD generique de reservation)Construire un logiciel a` partir de composants prets a` lemploi Design Patterns




Facilite de maintenance

Un logiciel ne suse pas

Pourtant, la maintenance absobe un tre`s grosse partie desefforts de developpement

Repartitioneffort dev.

Origine deserreurs

Cout de lamaintenance

Definition desbesoins

6%56% 82%

Conception 5% 27% 13%

Codage 7% 7% 1%

IntegrationTests

15% 10% 4%

Maintenance67%

(Zeltovitz, De Marco)




Maintenance corrective

Corriger les erreurs : defauts dutilite, dutilisabilite, defiabilite...

Identifier la defaillance, le fonctionnementLocaliser la partie du code responsableCorriger et estimer limpact dune modification

Attention

La plupart des corrections introduisent de nouvelles erreursLes couts de correction augmentent exponentiellement avec ledelai de detection

La maintenance corrective donne lieu a` de nouvelles livraisons(release)




Maintenance adaptative

Ajuster le logiciel pour quil continue a` remplir son rolecompte tenu du levolution des

Environnements dexecutionFonctions a` satisfaireConditions dutilisation

Ex : changement de SGBD, de machine, de taux de TVA, an2000, euro...




Maintenance perfective, dextension

Accrotre/ameliorer les possibilites du logiciel

Ex : les services offerts, linterface utilisateur, lesperformances...

Donne lieu a` de nouvelles versions




Facilite de maintenance

Objectifs

Reduire la quantite de maintenance corrective (zero defaut)Rendre moins couteuses les autres maintenances

Enjeux

Les couts de maintenance se jouent tre`s tot dans le processusdelaboration du logicielAu fur et a` mesure de la degradation de la structure, lamaintenance devient de plus en plus difficile

Solutions :

Reutilisabilte, modulariteVerifier, testerStructures de donnees complexes et algorithmes simplesAnticiper les changements a` venirProgiciels




Principes utilises dans le Genie Logiciel

Generalisation : regroupement dun ensemble defonctionnalites semblables en une fonctionnalite parametrable(genericite, heritage)

Structuration : facon de decomposer un logiciel (utilisationdune methode bottom-up ou top-down)

Abstraction : mecanisme qui permet de presenter un contexteen exprimant les elements pertinents et en omettant ceux quine le sont pas




Principes utilises dans le Genie Logiciel

Modularite : decomposition dun logiciel en composantsdiscrets

Documentation : gestion des documents incluant leuridentification, acquisition, production, stockage et distribution

Verification : determination du respect des specificationsetablies sur la base des besoins identifies dans la phaseprecedente du cycle de vie




Objectif CCM 6 !

Le Mode`le de Maturite (CMM) du SEI1 Initial2 Reproductible3 Defini4 Matrise5 Optimise

75% des projets au niveau 1, 25% aux niveaux 2 et 3 selonCurtis

Pour matriser le processus de developpement logiciel etassurer la qualite du logiciel, il faut :

Separer le developpement en plusieurs etapesOrganiser ces etapes et modeliser le processus dedeveloppementControler le processus de developpement




Niveau de maturite 1 : Initial

Chaotique : plans et controles inefficaces

Processus essentiellement non controle, non definiLe succe`s depend des individus




Niveau de maturite 2 : Reproductible

Intuitif : depend encore des individus

Procedures de gestion utilisees, gestion des configurations etassurance qualitePas de mode`le formel de processus




Niveau de maturite 3 : Defini

Qualitatif : institutionnalise

Procedures formelles pour verifier que le processus est utilise




Niveaux de maturite 4 : Matrise

Quantitatif : Processus de mesures

Gestion quantitative de la qualite




Niveaux de maturite 5 : Optimise

Ameliorations retournees dans le processus

Strategies damelioration du processus



Composantes du cycle de vie dun logicielDocuments courantsMode`les de cycle de vie dun logicielMode`les de processus logiciels

Cycle de vie

La qualite du processus de fabrication est garante de la qualitedu produit

Pour obtenir un logiciel de qualite, il faut en matriser leprocessus delaboration

La vie dun logiciel est composee de differentes etapesLa succession de ces etapes forme le cycle de vie du logicielIl faut controler la succession de ces differentes etapes




Etude de faisabilite

Determiner si le developpement propose vaut la peine detremis en uvre, compte tenu de attentes et de la difficulte dedeveloppement

Etude de marche : determiner sil existe un marche potentielpour le produit.




Specification

Determiner les fonctionnalites que doit posseder le logiciel

Collecte des exigences : obtenir de lutilisateur ses exigencespour le logicielAnalyse du domaine : determiner les taches et les structuresqui se repe`tent dans le proble`me




Organisation du projet

Determiner comment on va developper le logiciel

Analyse des couts : etablir une estimation du prix du projetPlanification : etablir un calendrier de developpementAssurance qualite du logiciel : determiner les actions quipermettront de sassurer de la qualite du produit finiRepartition des taches : hierarchiser les taches et sous-tachesnecessaires au developpement du logiciel




Conception

Determiner la facon dont dont le logiciel fournit les differentesfonctionnalites recherchees

Conception generale

Conception architecturale : determiner la structure du syste`meConception des interfaces : determiner la facon dont lesdifferentes parties du syste`me agissent entre elles

Conception detaillee : determiner les algorithmes pour lesdifferentes parties du syste`me




Implementation

Ecrire le logiciel




Tests

Essayer le logiciel sur des donnees dexemple pour sassurerquil fonctionne correctement

Tests unitaires : faire tester les parties du logiciel par leursdeveloppeursTests dintegration : tester pendant lintegrationTests de validation : pour acceptation par lacheteurTests syste`me : tester dans un environnement proche delenvironnement de productionTests Alpha : faire tester par le client sur le site dedeveloppementTests Beta : faire tester par le client sur le site de productionTests de regression : enregistrer les resultats des tests et lescomparer a` ceux des anciennes versions pour verifier si lanouvelle nen a pas degrade dautres




Livraison

Fournir au client une solution logicielle qui fonctionnecorrectement

Installation : rendre le logiciel operationnel sur le site du clientFormation : enseigner aux utilisateurs a` se servir du logicielAssistance : repondre aux questions des utilisateurs




Maintenance

Mettre a` jour et ameliorer le logiciel pour assurer sa perenite

Pour limiter le temps et les couts de maintenance, il fautporter ses efforts sur les etapes anterieures




Cahier des charges

Description initiale des fonctionnalites desirees, generalementecrite par lutilisateur




Specifications

Decrit precisement les conditions que doit remplir le logiciel

Mode`le objet : indique les classes et les documents principauxScenarios des cas dutilisation : indique les differentsenchanements possibles du point de vue de lutilisateur




Calendrier du projet

Ordre des differentes taches

Details et ressources quelles demandent




Plan de test du logiciel

Decrit les procedures de tests appliquees au logiciel pourcontroler son bon fonctionnement

Tests de validation : tests choisis par le client pour determinersil peut accepter le logiciel




Plan dassurance qualite

Decrit les activites mises en uvre pour garantir la qualite dulogiciel




Manuel utilisateur

Mode dempoi pour le logiciel dans sa version finale




Code source

Code complet du produit fini




Rapport des tests

Decrit les tests effectues et les reactions du syste`me




Rapport des defauts

Decrit les comportements du syste`me qui nont pas satisfait leclient

Il sagit le plus souvent de defaillances du logiciel ou derreurs




Documents produits dans le cycle de vie

Document Phase de productionManuel utilisateur final

ImplementationConception architecturale ConceptionPlan dassurance qualite Planification

Code source ImplementationCahier des charges Faisabilite

Plan de test SpecificationManuel utilisateur preliminaire Specification

Conception detaillee ConceptionEstimation des couts PlanificationCalendrier du projet Planification

Rapport des tests TestsDocumentation Implementation





Document Phase de productionManuel utilisateur final Implementation

Conception architecturale ConceptionPlan dassurance qualite Planification










Conception architecturale

ConceptionPlan dassurance qualite Planification










Conception architecturale Conception

Plan dassurance qualite PlanificationCode source Implementation

Cahier des charges FaisabilitePlan de test Specification

Manuel utilisateur preliminaire SpecificationConception detaillee ConceptionEstimation des couts PlanificationCalendrier du projet Planification







Conception architecturale ConceptionPlan dassurance qualite

PlanificationCode source Implementation










Code source

ImplementationCahier des charges Faisabilite










Code source Implementation










Code source ImplementationCahier des charges

FaisabilitePlan de test Specification










Plan de test

SpecificationManuel utilisateur preliminaire Specification










Plan de test Specification










Plan de test SpecificationManuel utilisateur preliminaire

SpecificationConception detaillee ConceptionEstimation des couts PlanificationCalendrier du projet Planification










Conception detaillee

ConceptionEstimation des couts PlanificationCalendrier du projet Planification










Conception detaillee Conception

Estimation des couts PlanificationCalendrier du projet Planification










Conception detaillee ConceptionEstimation des couts

PlanificationCalendrier du projet Planification










Conception detaillee ConceptionEstimation des couts Planification

Calendrier du projet PlanificationRapport des tests TestsDocumentation Implementation









Conception detaillee ConceptionEstimation des couts PlanificationCalendrier du projet

PlanificationRapport des tests TestsDocumentation Implementation










Rapport des tests

TestsDocumentation Implementation










Rapport des tests Tests

Documentation Implementation










Rapport des tests TestsDocumentation

Implementation




Mode`les lineaires et incrementaux

Mode`les lineaires

cascademode`le en V...

Mode`les non lineaires

prototypagemode`les incrementauxmode`le en spirale...




Le cycle de vie en Cascade

Etudedefaisabilit

Conceptiondtaille

Conceptiongnrale

Spcification

Codage

Tests

Maintenance

Adapte pour des projets de petite taille, et dont le domaineest bien matrise




Le cycle de vie en V

Etudedefaisabilit

Conceptiondtaille

Conceptiongnrale

Spcification

Codage

Testsunitaires

Validation

Maintenance

Testsd'intgration

Adapte pour des projets dont le domaine est bien matrise




Le prototypage

Prototype : version dessai du logiciel

Pour tester les differents concepts et exigencesPour montrer aux clients les fonctions que lon veut mettre enuvre

Lorsque le client a donnne son accord, le developpement suitsouvent un cycle de vie lineaire

Avantages : Les efforts consacres au developpement dunprototype sont le plus souvent compenses par ceux gagnes a`ne pas developper de fonctions inutiles




Le mode`le incremental de Parnas

1 Concevoir et livrer au client un sous-ensemble minimal etfonctionnel du syste`me

2 Proceder par ajouts dincrements minimaux jusqua` la fin duprocessus de developpement

3 Avantages : meilleure integration du client dans la boucle,produit conforme a` ses attentes




Le mode`le en Sprirale de Boehm

Un mode`le mixte

A chaque cycle,recommencer :

1 Consultation du client2 Analyse des risques3 Conception4 Implementation5 Tests6 Planification du

prochain cycle

Avantages : meilleure matrise des risques, mais necessite une(tre`s) grande experience




Modelisation des processus logiciels

Les mode`les en V, spirale... sont des archetypes de mode`les

On peut les adapter a` des projets particuliers

On peut vouloir representer le processus de developpement (etses parties) de manie`re plus fine

Une modelisation precise limite les risques dambiguite

Il est necessaire de se doter dun formalisme pour representerle processus de developpement

Pour ordonner les tachesPour determiner les echanges dinformation entre lesdifferentes tachesPour permettre aux jeunes recrues de mieux travailler




Mode`le de processus logiciels

Un mode`le de processus logiciels decrit

Les tachesLes artefacts (fichiers, documents, donnees...)Les auteursLes decisions (facultatif)

Re`gles a` observer

Deux taches doivent etre separees par un artefactUne tache ne peut etre executee tant que ses artefacts dentreenexistent pasIl doit y avoir au moins une tache de debut et une de finIl doit y avoir un trajet depuis chaque tache jusqua` la tache defin




Exemples de processus logiciels




Diagrammes de flots de donnees

Indique la circulation des donnees a` travers un ensemble decomposants qui peuvent etre

des tachesdes composants logiciels...

Re`gles a` observer

Les processus sont representes par des cases qui contiennentdes phrases verbalesLes fle`ches representent des donnees et doivent etreaccompagnees de phrases nominalesUn processus peut etre une activite ponctuelle ou continueDeux fle`ches sortant dune case peuvent indiquer

Soit deux sorties simultaneesSoit deux sorties exclusives




Exemples de diagramme de flots de donnees

pour representer (x + y) (w + z)


Gestion de projetsPlanification de projets

Assurance qualite

Pratiques critiques de la gestion de projetAnalyse de la valeur acquiseSuivi des erreurs

Gestion de projets

Proble`mes souvent humains

Planifier la progressionMotiver et coordonner un groupe de professionnels

Techniques souvent communes a` la gestion de projet engeneral

Proble`me particulier de la visibilite

Un projet logiciel apparatra souvent a` ses developpeurscomme presque acheve alors quil ne lest qua` 90%



Assurance qualite


Pratiques du chef de projet

Opter pour une gestion des risques continue

Prevoir des etapes reparties sur lensemble du cycle de vieconsacrees a` lidentification et a` levaluation des risques, ainsique des taches pour y remedier

Estimer les couts et planifier le projet a` partir de donneesempiriques

Prevoir une etape au debut du cycle de vie pour evaluer le coutdu projet et une serie detapes ulterieures pour raffiner cetteestimation. Au cours de chaque etape, les donnees devront etrearchivees pour les evaluations ulterieures

Utiliser des metriques pour la gestion du projet

Choisir des metriques et prevoir des etapes pour enregistrer lesvaleurs de celles-ci, et dautres pour analyser les progre`s enfonction de ces resultats



Assurance qualite



Suivre levolution de la valeur acquise

Rechercher les defauts en fonction des objectifs de qualite

Determiner des objectifs pour le nombre de rapports derreurset prevoir des etapes pour communiquer ces resultats

Considerer les employes comme la ressource la plusimportante

Controler lensemble du processus logiciel pour estimer sonimpact sur le programmeur

Utiliser un outil de gestion de configuration

Assurer que les modifications du logiciel sont effectuees demanie`re a` minimiser les couts globauxGarder la trace des differences entre les versions pour controlerles nouvelles versions



Assurance qualite



Gerer et suivre levolution des besoins

Prevoir des etapes pour recueillir les besoins des utilisateurs

Orienter la conception en fonction du syste`me vise

Definir et controler les interfaces

Concevoir plusieurs fois pour ne coder quune seule

Prevoir des etapes pour controler la conception

Identifier les elements protentiellement reutilisables

Controler les specifications

Organiser les tests comme un processus continu

Prevoir des etapes de tests dans toutes les phases



Assurance qualite


Mesures de base

CBT : cout budgete du travail

Quantite de travail estimee pour une tache donnee

CBTP : cout budgete du travail prevu

Somme des quantites de travail estimees pour lensemble destaches devant etre achevees a` une date donnee

CBA : cout budgete a` lache`vement

Total des CBTP et donc lestimation de la quantite de travailpour le projet entier

VP : valeur prevue

Proportion de la quantite de travail totale estimee attribuee a`une tache donneeVP = CBT/CBA



Assurance qualite


Mesures de base

CBTE : cout budgete du travail effectue

Somme des quantites de travail estimees pour les tachesachevees a` une date donnee

CRTE : cout reel du travail effectue

Somme des quantites de travail reelles pour lensemble destaches du projet



Assurance qualite


Indicateurs davancement

VA : Valeur acquise

VA = CBTE/CBA= somme des VP pour les taches achevees= PA (pourcentage acheve)

IPT : indicateur de performance temporel

IPT = CBTE/CBTP

VE : variance par rapport a` lecheancier

VE = CBTE CBTPIC : indicateur decart sur les couts

IC = CBTE/CRTE

VC : variance par rapport aux couts

VC = CBTE CRTE



Assurance qualite


Exemple 1

Tache Trav. estime(jh)

Trav. reelaujourdhui

Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

Proble`me : calculer les indicateurs davancement au 01/04



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

CBA : somme des estimations des quantites de travail

CBA = 330jh



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

Au 01/04, les taches 1,2 et 4 sont achevees

Le CBTE est la somme des CBT pour ces taches

CBTE = 70jh



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

VA = 70/330 = 21.2%



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

Les taches 1 et 2 devraient etre achevees pour le 01/04, etpas 1,2 et 4

CBTP = 30



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

IPT = 70/30 = 233%

SV = 70 30 = +40jh



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

La CRTE est la somme des quantites de travail reelles pourles taches 1,2 et 4

CRTE = 80jh



Assurance qualite


Exemple 1



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 80 15/05

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

IC = 70/80 = 87.5%

VC = 70 80 = 10jh



Assurance qualite


Exemple 2

Proble`me : que deviennent ces indicateurs, a` supposer que latache 3 a egalement ete achevee avec 140jh de travail et quenous sommes le 01/07 ?



Assurance qualite


Exemple 2



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 140 15/05 01/07

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09



Assurance qualite


Exemple 2



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 140 15/05 01/07

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

CBTE = 190jh

CBTP = 250jh

CRTE = 220jh



Assurance qualite


Exemple 2



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 140 15/05 01/07

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

VA = 190/330 = 57.5%

IPT = 190/250 = 76%

VE = 190 250 = 60jh



Assurance qualite


Exemple 2



Date dach.estimee

Date dach.effective

1 5 10 25/01 01/02

2 25 20 15/02 15/02

3 120 140 15/05 01/07

4 40 50 15/04 15/04

5 60 50 01/07

6 80 70 01/09

Seules les taches 14 sont realisees, au lieu de 15

IC = 190/220 = 86.6%

VC = 190 220 = 30jh



Assurance qualite


Suivi des erreurs

Conserver une trace des

Erreurs qui se sont produitesDurees entre deux erreurs successives

Permet de

Mieux determiner une date de livraisonMotiver les testeurs et les developpeurs



Assurance qualite


Taux derreur

TE : Inverse du temps qui separe deux erreurs successives

Ex : si une erreur se produit tous les deux jours, TE = 0.5erreurs par jour

Taux derreur instantane : estimation du taux derreur courant

Taux derreur cumule : bonne estimation des taux derreur a`venir

Somme de toutes les erreurs divise par le temps total

Une representation graphique permet destimer les tendancesdes taux derreur par regression lineaire

y : taux derreursx : deux possibilites :

nombre derreurs : donne une estimation du nombre derreursrestantestemps ecoule : donne une estimation du temps avant livraison



Assurance qualite


Exemple

Les durees entre une serie derreurs sont les suivantes : 4, 3, 5,6, 4, 6, 7.



Assurance qualite


Exemple

Les durees entre une serie derreurs sont les suivantes : 4, 3, 5,6, 4, 6, 7.

Duree 4 3 5 6 4 6 7

Taux 0.25 0.33 0.20 0.17 0.25 0.17 0.14



Assurance qualite


Exemple

Duree 4 3 5 6 4 6 7

Taux 0.25 0.33 0.20 0.17 0.25 0.17 0.14



Assurance qualite


Exemple

Si on prolonge cette courbe, on voit quelle coupe laxe desabscisses pour une valeur de 11 erreurs environ

Le taux derreur devrait donc etre nul apre`s le 11e`me erreur

Comme 7 erreurs ont ete trouvees, il ne devrait plus en resterque 4



Assurance qualite

Organigramme techniqueLa methode PERTAutres mode`lesEstimation des couts

Planification

Element indispensable de la conduite de projets

Determiner les taches a` accomplirDeterminer lordre des tachesDecider des ressources allouees a` chaque tache



Assurance qualite


Work Breakdown Structure (WBS)

Objectif : Diviser les taches principales en taches plus petites

Necessite de :

Pouvoir identifier leurs differentes partiesTrouver des livrables et des jalons qui permettront de mesurerlavancement du projet

WBS Work Breakdown Tructure : organigramme technique

Structure arborescenteLe premier niveau de decomposition correspond souvent aumode`le de cycle de vie adopte



Assurance qualite


Re`gles dobtention dun organigramme technique (WBS)

Structure arborescente

Pas de boucleLes actions iteratives apparaissent dans le mode`le de processusou dans le mode`le de cycle de vie

Les descriptions des taches et des livrables doivent etre claireset sans ambiguite

Chaque livrable doit etre associe a` une tache, sans quoi il nesera pas produit

Chaque tache doit avoir un crite`re dache`vement

Le plus souvent un livrable

Lache`vement de toutes les sous-taches doit entranerlache`vement de la tache



Assurance qualite


Exemple

Mode`le de cycle de vie pour la consommation de tartines

Mode`le de processus pour cuisiner du pain



Assurance qualite


Exemple

Choisir la recette

Reunir les ingredients Ingredients reunisCuisiner

Manger

Nettoyer



Assurance qualite


Exemple

Choisir la recette

Choisir les ingredients Liste des ingredientsVerifier leur disponibilite Liste de courses


Manger

Nettoyer



Assurance qualite


Exemple

Choisir la recette


MelangerCuire Pain cuit

Manger

Nettoyer



Assurance qualite


Exemple

Choisir la recette


MelangerAjouter leau Saladier deauAjouter la levure et la farine MelangeFaire la pate PateLaisser lever 1 Pate leveeAjouter le reste de farine et petrir Pate petrieLaisser lever 2 Pate petrie et leveeFormer des miches MichesLaisser lever 3 Miches levees

Cuire Pain cuitManger

Nettoyer



Assurance qualite


Exemple

Choisir la recette


Manger

Decouper en tranches Tranches de painBeurrer Tartines beurreesManger Guout satisfaisant

Nettoyer

Nettoyer ustensiles Ustensiles propresNettoyer cuisine Cuisine propre



Assurance qualite


PERT

Program Evaluation and Review Technique1 Identifier les taches et estimer leur duree2 Ordonner les taches3 Construire le reseau et lexploiter



Assurance qualite


Identification des taches et de leur duree

Tache Duree ReferenceMettre la farine dans un saladier 3 s A

Mettre deux oeuf 30 s BAjouter le lait doucement et melanger 600 s C

Dans une poele mettre du rhum 3 s DCouper les bananes en fines lamelles 300 s E

Les melanger au rhum 30 s FFaire chauffer le melange 120 s G

Faire flamber 10 s HFaire cuire une crepe 10 s I

Verser du melange bananes-rhum sur la crepe 10 s JManger 120 K



Assurance qualite


Ordonnancement des taches

Pour faire Il faut faire

A -

B A

C B

D -

E -

F D-E

G F

H G

I C

J I-H

K J



Assurance qualite


Construction du reseau

Les taches A, D et E peuvent se faire en paralle`le

Il faut quelles soient toutes deux finies pour pouvoir debuterF, dou` les taches fictives de duree nulle de 3 a` 4 et de 2 a` 4.

La crepe doit etre cuite (I) et le melange doit etre flambe (H)pour pouvoir commencer a verser du melange sur la crepe (J)



Assurance qualite


Exploitation dun reseau PERT

1 Calcul des dates au plus tot de chaque etapeQuand se terminera le projet ? Quel est le delai necessaire pouratteindre une etape determinee ?Elles se calculent de gauche a` droite en partant de 0 etrajoutant la duree de la tache a` la date precedente. En cas deconvergence, on prend la valeur la plus elevee

2 Calcul des dates au plus tard de chaque etapeQuand doit demarrer le projet pour etre acheve a` temps ? Aquelle date chaque etape doit-elle etre atteinte pour que leprojet ne prenne pas de retard ?Elles se calculent de droite a` gauche en partant de la date defin au plus tard et en retranchant la duree de la tache a` la dateprecedente. En cas de convergence comme au 7 niveau onprend la valeur la plus faible

3 Calcul des marges et du chemin critique



Assurance qualite


Calcul des dates et des marges

Etape Date au plus tot Date au plus tard Marge

1 0 0 0

2 300 483 183

3 3 483 480

4 300 483 183

5 3 3 0

6 33 33 0

7 330 513 183

8 633 633 0

9 450 633 183

10 643 643 0

11 653 653 0

12 773 773 0



Assurance qualite


Chemin critique

On peut des maintenant repondre a` certaines questions

La crepe sera mangee a la date 773 (soit a peu pre`s 13 mnapre`s le debut de la fabrication)Il faut avoir fini la sauce au plus tard a la date 643 (etape 10)On pourra melanger le rhum et les bananes au plus tot a` ladate 300 (etape 4)

On remarque aussi que certaines etapes ont une marge nulleet que pour dautres on est plus libre

Le chemin critique relie les etapes qui nont aucune marge

Un retard dans une tache sur le chemin critique entranera unretard dans le projet entierLanalyse des temps de batements peut motivier unereaffectation des ressources associees a` chaque tache



Assurance qualite


Extensions des reseaux PERT

PERT Charge pour prendre en compte les ressources affecteesau projet

Ressource : moyen necessaire au deroulement et a`laboutissement dune tacheLes taches sont caracterisees par des durees et des intensitesde ressources

PERT Cost pour gerer les coutsPermet doptimiser lecheancier des paiements en

Jouant sur les surcouts affectant les taches critiquesJouant sur les economies possibles sur les taches non critiques



Assurance qualite


Diagrammes de Gantt

Utilise les dates au plus tot et des dates au plus tard

Permet detablir un planning en fonction des ressources



Assurance qualite


Le mode`le COCOMO de base

COnstructive COst Model

Developpe a` la firme TRW (organisme du DoD, USA) parB.W. Boehm et son equipeFonde sur une base de donnees de plus de 60 projets differents

Mode`le destimation

du cout de developpement dun logiciel en nombre demois-hommes (E : effort)du temps de developpement en mois (TDEV )en fonction du nombre de lignes de codes en milliers (KLOC )



Assurance qualite


Trois types de projets

Mode organique

Petites equipesApplications matrisees et proble`mes bien comprisPas de besoins non fonctionnels difficiles

Mode semi-detache

Experience variee des membres de lequipe de projetPossibilite lavoir des contraintes non fonctionnellesimportantesType lapplication non matrisee par lorganisation

Mode embarque

Contraintes serreesLequipe de projet a, en general, peu lexperience delapplicationProble`mes complexes



Assurance qualite


Calcul de leffort

Formule generale

E = a KLOC ba et b estimes en fonctions de donnees empiriques

Organique

E = 2.4 KLOC 1.05Semi-detache

E = 3.0 KLOC 1.12Embarque

E = 3.6 KLOC 1.20



Assurance qualite


Calcul du temps de developpement

Formule generale

TDEV = a KLOC ba et b estimes en fonctions de donnees empiriques

Organique

TDEV = 2.5 KLOC 0.38Semi-detache

TDEV = 2.5 KLOC 0.35Embarque

TDEV = 2.5 KLOC 0.32



Assurance qualite


Mode`le COCOMO intermediaire

Estimation modifiant lestimation brute fournie par le mode`leCOCOMO de base en se servant des attributs

LogicielMaterielProjetPersonnel



Assurance qualite


Les attributs du logiciel

Besoin en fiabilite

Taille de la Base de Donnees

Complexite du produit



Assurance qualite


Les attributs du materiel

Contraintes sur le temps lexecution

Contraintes sur la memoire

Contraintes sur le stockage

Contraintes du temps de passage entre deux processus(synchronisation)

...



Assurance qualite


Les attributs du projet

Techniques de programmation moderne

Programmation Orientee ObjetProgrammation Evenementielle

Utilisation lAteliers de Genie Logiciel (CASE)

Contraintes de developpement

DelaisBudget...



Assurance qualite


Les attributs du personnel

Competence de lanalyste

Competence du programmeur

Experience dans lutilisation du langage de programmation

Experience dans le domaine de lapplication

Experience dans lutilisation du materiel



Assurance qualite


Calcul de leffort

Organique

E = 3.2 KLOC 1.05Semi-detache

E = 3.0 KLOC 1.12Embarque

E = 2.8 KLOC 1.20Les estimations obtenues par la formule ci-dessus sontmultipliees par les 15 facteurs de cout liees aux attributs dulogiciel, du materiel, du projet et du personnel



Assurance qualite


Mode`le COCOMO expert

Inclue toutes les caracteristiques du mode`le intermediaire

Ajouts :

Limpact de la conduite des couts sur chaque etape du cycle dedeveloppementLe projet est analyse comme une hierarchie : module,sous-syste`me et syste`me

COCOMO expert permet une veritable gestion de projet

Utile pour de grands projetsAjustement des parame`tres possibles en fonction de donneeslocales protant sur les habitudes de developpementProble`me : necessite une estimation de la taille du projet enKLOC



Assurance qualite


Analyse en points de fonction

Plutot que destimer le nombre de lignes de code, il peut etreplus judicieux destimer des points de fonction

Les elements les plus courants a` prendre en compte sont les :

Interrogations : paires requete-reponseEntrees : les champs individuels ne sont generalement pascomptes separement (nom, prenom... comptent pour 1)Sorties (comme les entrees)Fichiers internes : fichiers tels que le client les comprendInterfaces externes : donnees partagees avec dautresprogrammes



Assurance qualite


Comptage des points de fonction

Des coefficients sont attribues aux elements, selon leurcomplexite

Elements Simple Moyens Complexes

Sorties 4 5 7

Interrogations 3 4 6

Entrees 3 4 6

Fichiers 7 10 15

Interfaces 5 7 10

Les coefficients ponde`rent une somme du nombre delementsrecences pour obtenir les points de fonction du logiciel

Manque de standard pour compter les PFEstimation des coefficients a` faire en interneRelation entre points de fonction et cout a` estimer en interne



Assurance qualite

Qualite

Difficile a` definir

ISO 8402 : lensemble des caracteristiques dune entite quilui confe`rent laptitude a` satisfaire des besoins exprimes etimplicites Un logiciel est de qualite lorsquil fonctionne comme il estsuppose le faire

Il est plus facile de mesurer les defauts de qualite

Mecontentement du clientNombre de rapports derreurs



Assurance qualite

Inspections formelles

Activite formelle et planifiee

Un concepteur presente des documents sur un projet a` ungroupe dautres concepteurs qui en evaluent les aspectstechniques avec pour objectif de trouver les erreursContole effectue par des personnes techniquement competentesParticipation active de lauteurPorte sur un produit finiInspection periodique au cours du processus de developpement



Assurance qualite

Roles pour une inspection

Le moderateur :

Il choisit lequipeIl dirige linspection

Le lecteur :

Il nest generalement pas lauteur du produitIl guide lequipe dans la structure du produit

Le secretaire :

Il consigne le deroulement de linspectionIl note toutes les erreurs trouvees

Lauteur :

Il est a` lorigine du produit examineIl repond aux questionsIl corrige les erreurs et fait un rapport au moderateur



Assurance qualite

Etapes de linspection

Presentation generale par lauteur au reste de lequipePreparation

Les membres de lequipe etudient le produit dans la limite duntemps calcule en fonction du nombre de LOCIls peuvent saider dune liste de controles

Reunion pour linspectionOrganisee par le moderateurLe lecteur conduit linspectionLe secretaire consigne les proble`mes dans un rapportEn cas de desaccord, il est possible de produire des rapportindividuels

Integration des remarques : lauteur corrige les erreursSuivi

Le moderateur controle le rapport et les correctionsSi les crite`res sont satisfaits, linspection prend fin


MetriquesAnalyse et gestion des risques

Tests logiciels

Metriques de Mac CabeMetriques de HalsteadMetriques de Henry-KafuraMetriques Objet de Chidamber et KemererMetriques MOOD

Complexite structurelle selon Mc Cabe

Metrique la plus utilisee apre`s les lignes de code

Met en evidence la complexite structurelle du code

On produit un graphe de controle qui represente un codeLe nombre de faces du graphe donne la complexite structurelledu code



Tests logiciels


Nombre cyclomatique de Mc Cabe

C = a n + 2pavec

a = nombre darcs du graphe de controle

n = nombre de nuds du graphe de controle

p = nombre de composantes connexes (1 le plus souvent)

Ici, n = 8, a = 11 et p = 1 donc

C = 11 8 + 2 = 5Pierre Gerard Genie Logiciel


Tests logiciels


Nombre cyclomatique de Mc Cabe

C = a n + 2pavec

a = nombre darcs du graphe de controle

n = nombre de nuds du graphe de controle

p = nombre de composantes connexes (1 le plus souvent)

C = 11 8 + 2 = 5C correspond au nombre de faces (en comptant la faceexterieure)



Tests logiciels


Calcul direct du nombre de Mc Cabe

Produire un graphe de controle et lanalyser peut saverer longdans le cas de programmes complexes

Mc Cabe a introduit une nouvelle manie`re de calculer lacomplexite structurelle

C = pi + 1

avec pi le nombre de decisions du code

Une instruction IF compte pour 1 decision

Une boucle FOR ou WHILE compte pour 1 decision

Une instruction CASE ou tout autre embranchement multiplecompte pour une decision de moins que le nombredalternatives



Tests logiciels


Nombre de faces et formule de Mc Cabe

4 decisions doncC = 5 + 1 = 5

3 decisions doncC = 3 + 1 = 4

Pourtant, meme nombre de faces : la formule de Mc Cabeserait incorrecte ? Non

Le second graphe est invalide parce quil ne posse`de pas denoeud darrivee



Tests logiciels


Science informatique de Halstead

Metriques pour la complexite dun programme

Fondees empiriquementToujours considerees comme valides, contrairement a` sesformules complexes de prediction

Entites de base

Operandes : jetons qui contiennent une valeurOperateurs : tout le reste (virgules, parenthe`ses, operateursarithmetiques...)



Tests logiciels


Mesures de base 1 et 2 (eta)

1 : nombre doperateurs distincts

2 : nombre doperandes distincts

= 1 + 2 : nombre total de jetons distincts

Operandes potentiels ?2Ensemble de valeurs minimal pour nimporte quelleimplementationPour comparer differentes implementations du memealgorithmeSobtient generalement en comptant les valeurs qui ne sont pasinitialisees a` linterieur de lalgorithme

Valeurs lues par le programmeValeurs passees en parame`tresValeurs globales appelees depuis lalgorithme



Tests logiciels


Exemple

z = 0;while x > 0

z = z + y;x = x - 1;

end-whileprint (z);

Operateurs := ; while/end-while > + -print ()1 = 8

Operandes : = z 0 x y 12 = 5



Tests logiciels


Longueur dun programme

N1 : Nombre total doperateurs

N2 : Nombre total doperandes

N = N1 + N2 : Nombre total de jetons



Tests logiciels


Exemple

z = 0;while x > 0

z = z + y;x = x - 1;

end-whileprint (z);

Operandes Operateurs

= 3 z 4; 5 0 2

w/ew 1 x 3> 1 y 2+ 1 1 1- 1

print 1() 1

N1 = 14, N2 = 12 donc N = 12



Tests logiciels


Estimation de la longueur

Estimation de N a` partir de 1 et de 2

Nest = 1 + log2(1) + 2 log2(2)

Dans notre exemple :Nest = 8 log2(8) + 5 log2(5) = 8 3 + 5 2.32 = 35.6

Ici, Nest >> NEn pratique, Si la difference entre N et Nest est superieure a`30%, il vaut mieux renoncer a` utiliser les autres mesures deHalstead



Tests logiciels


Volume

Estimation du nombre de bits necessaires pour coder leprogramme mesure

V = N log2(1 + 2)

Dans notre exemple : V = 26 log2(13) = 26 3.7 = 96, 2



Tests logiciels


Autres mesures de Halstead

Volume potentiel V ?

Taille minimale dune solution au proble`meV ? = (2 + ?2 ) log2(2 + ?2 )

Niveau dimplementation LExprime dans quelle mesure limplementation actuelle estproche de limplementation minimaleL = V ?/V

Mesures presentees pour leur interet historiqueEffort E en emd (elementary mental discrimination)

Mesure de leffort intellectuel necessaire a` limplementationdun algorithmeE = V /L

Temps TTemps necessaire pour implementer un algorithmeT = E/S ou` S est le nombre de Stroud. Halstead avait retenuS = 18



Tests logiciels


Flux dinformations dHenry-Kafura

Mesurer la complexite des modules dun programme enfonction des liens quils entretiennent

On utilise pour chaque module i :

Le nombre de flux dinformation entrant note iniLe nombre de flux dinformation sortant note outiLe poids du module note poidsi calcule en fonction de sonnombre de LOC et de sa complexite

HKi = poidsi (outi ini )2

La mesure totale HK correspond a` la somme des HKi



Tests logiciels


Exemple

A partir des ini et outi ci-dessous, calcul des metriques HK ensupposant que le poids de chaque module vaut 1

Module a b c d e f g h

ini 4 3 1 5 2 5 6 1outi 3 3 4 3 4 4 2 6

HKi 144 81 16 225 64 400 144 36

HK = 1110



Tests logiciels


Metriques Objet de Chidamber

Ensemble de metriques (Metric Suite for Object OrientedDesign)

Evaluation des classes dun syste`meLa plupart des metriques sont calculees classe par classeLe passage au global nest pas clair, une moyenne netant pastre`s satisfaisante



Tests logiciels


M1 : Methodes ponderees par classe

WMC : Weighted Methods per Class

WMC = 1n n

i=0

ci Mi

avec C un ensemble de n classes comportant chacune Mimethodes dont la complexite (le poids) est note ci



Tests logiciels


M2 : Profondeur de larbre dheritage

DIC : Depth of Inheritance Tree

Distance maximale entre un nud et la racine de larbredheritage de la classe concerneeCalculee pour chaque classe



Tests logiciels


M3 : Nombre denfants

NOC : Number Of Children

Nombre de sous-classes dependant immediatement duneclasse donnee, par une relation dheritageCalculee pour chaque classe



Tests logiciels


M4 : Couplage entre classes

Dans un contexte OO, le couplage est lutilisation demethodes ou dattibuts dune autre classe.

Deux classes son

Gl Cours Slides

Documents

Transcript of Gl Cours Slides