M1 STIC

CG2
Gestion de
lInnovation et
de la Qualit -

GNIE LOGICIEL
ET APPLICATION A LA
QUALITE LOGICIEL

Cours distribu sous licence Creative Commons,

selon les conditions suivantes :
1

Au commencement, il y avait
Ce que vous connaissez : le programme informatique
Vos comptences :
programmation individuelle sur de petits problmes
algo, langages, structures de donnes
(parfois) un peu de mthodologie : analyse descendante

Votre vision ? La programmation est excitante et ludique

Quest-ce quun logiciel ?

il est fait pour des utilisateurs
dialoguer mtier, produire des documents

il est complexe et de trs grande taille

homme-mois
nb instructions

1/2 M Inst.
exp. physique des particules CERN
1 M Inst.
central tlphonique
50 M Inst.
contrle sol + vol navette spatiale

il fait intervenir plusieurs participants

travail en quipe(s), organisation, planification

il est long et coteux dvelopper

risques nombreux et important : dlais, cot
3

Dfinition du logiciel

Un logiciel (software) est lensemble des programmes,

des procdures et des documentations ncessaires au
fonctionnement dun systme informatique

Caractristiques du logiciel

-1

le logiciel est facile reproduire

tout le cot se trouve dans le dveloppement

le logiciel est immatriel et invisible

on ne peut lobserver quen lutilisant
la qualit nest pas vraiment apparente
difficile destimer leffort de dveloppement

dveloppement difficile automatiser

beaucoup de main-duvre ncessaire

Caractristiques du logiciel

-2

le logiciel ne suse pas, mais il vieillit

Dtrioration suite aux changements :
complexification indue
duplication de code
introduction derreurs

Mal conu au dpart :

inflexibilit
manque de modularit
documentation insuffisante

Evolution du matriel
6

Diffrentes catgories de logiciels

sur mesure : pour un client spcifique

gnrique

: vendu sur un march

Diffrents types de logiciels

systme dinformation et daide la dcision

logiciel temps-rel
logiciel embarqu
logiciel distribu

Problmatique historique du logiciel

Dune part le logiciel nest pas fiable,

dautre part il est incroyablement difficile de
raliser dans les dlais prvus des logiciels
satisfaisant leur cahier des charges

Le logiciel nest pas fiable

Quelques exemples clbres :
1re sonde Mariner vers Vnus
perdue dans lespace (erreur Fortran)

navette spatiale
lancement retard (problme logiciel)

ATT
appels longue distance suspendus (changement de version)

avion F16
retourn lquateur (non prise en compte hmisphre sud)

bug de lan 2000

Tout systme comporte des bugs

10

Dlais et exigences non satisfaits

Quelques exemples clbres :

OS 360 dIBM
en retard, dpassement mmoire et prix, erreurs

aroport de Denver (systme de livraison des bagages)

1 an de retard

SNCF (systme Socrate)

difficults importantes

11

Abandons
Quelques exemples clbres :
EDF (contrle-commande centrales 1400 MWatts)
renonce aprs plusieurs annes defforts

bourse de Londres (projet dinformatisation)

abandon : 4 annes de travail + 100 ML perdus

Etats-Unis (systme de trafic arien)

abandon

La non rencontre des exigences et les dpassements

de dlais sont frquents : 300 400 %
12

Naissance dune nouvelle discipline

Historique
Problmatique apparue ds les annes 1960
Confrence parraine par lOTAN (1968)
Naissance du Gnie Logiciel (software engineering)

P. Naur, B. Randall (Eds)

Software Engineering : A Report on a Conference
Sponsored by the NATO Science Committee
NATO, 1969

13

Naissance dune nouvelle discipline

Objectif
Dmarche de dveloppement ingnierique
Principes, mthodes, outils
Techniques de fabrication assurant :
respect des exigences
respect de la qualit
respect des dlais et des cots

14

Dfinition du Gnie Logiciel

Processus visant :
la rsolution de problmes poss par un client
par le dveloppement systmatique et lvolution
de systmes logiciels de grande taille et de haute qualit
en respectant les contraintes de cots, de temps, et autres

15

Rsolution de problmes poss par un client

identifier et comprendre le problme rsoudre

solution utile rsolvant un problme concret
la solution peut tre de ne rien dvelopper !

16

Dveloppement systmatique et volution

techniques matrises, organisation, rigueur

bonnes pratiques standardises (IEEE, ISO)
la plupart des projets consistent en une volution

17

Systmes de grande taille et haute qualit

travail en quipe(s)
bonne coordination essentielle
principal dfi : subdiviser et recomposer harmonieusement
produit final : critres de qualits bien tablis

18

Respectant les contraintes

les ressources sont limites (temps, argent, )

le bnfice doit tre suprieur aux cots
la productivit doit rester concurrentielle
mauvaise estimation chec

19

Transition
Risques majeurs du dveloppement de logiciels :

ne pas remplir les exigences du client

produire un logiciel non fiable
dpasser les dlais, les cots et autres contraintes

20

Mthodes du Gnie Logiciel

Mthodologies de dveloppement

21

Introduction
Comme pour tout produit manufactur complexe :
on dcompose la production en phases
lensemble des phases constitue un cycle de vie
les phases font apparatre des activits cls

22

Activits du dveloppement de logiciel

analyse des besoins

spcification
conception
programmation
intgration
vrification et validation

23

Analyse des besoins

But :
dterminer ce que doit faire (et ne pas faire) le logiciel
dterminer les ressources, les contraintes

Caractristiques :
parler mtier et non info
entretiens, questionnaires
observation de lexistant, tude de situations similaires

Rsultat : ensemble de documents

rle du systme
future utilisation
aspects de lenvironnement
(parfois) un manuel dutilisation prliminaire
24

Spcification
But :
tablir une 1re description du futur systme
consigner dans un document qui fait rfrence

Donnes :
rsultats de lanalyse des besoins + faisabilit informatique

Rsultat : Spcification Technique de Besoin (STB)

ce que fait le logiciel, mais pas comment

Remarques :
pas de choix dimplmentation
(parfois) un manuel de rfrence prliminaire
25

Conception
But :
dcrire comment le logiciel est construit
dcider comment utiliser la techno. pour rpondre aux besoins

Travail :
enrichir la description de dtails dimplmentation
pour aboutir une description trs proche dun programme

2 tapes :
conception architecturale
conception dtaille

26

Conception architecturale
But : dcomposer le logiciel en composants
mettre au point larchitecture du systme
dfinir les sous-systmes et leurs interactions
concevoir les interfaces entre composants

Rsultat :
description de larchitecture globale du logiciel
spcification des divers composants

27

Conception dtaille
But : laborer les lments internes de chaque sous-syst.

Rsultat :
pour chaque composant, description des
structures de donnes, algorithmes

Remarque :
si la conception est possible, la faisabilit est dmontre
sinon, la spcification est remise en cause

28

Programmation
But :
passer des structures de donnes et algorithmes
un ensemble de programmes

Rsultat :
ensemble de programmes
ensemble de bibliothques / modules
documents (commentaires)

Remarque :
activit la mieux matrise et outille (parfois automatise)

29

Gestion de configurations et Intgration

Gestion de configurations :
grer les composants logiciels (programmes, bibliothques, )
matriser leur volution et leurs mises jour

Intgration :
assembler les composants
pour obtenir un systme excutable

30

Vrification
But : vrifier par rapport aux spcifications
vrifier que les descriptions successives
(et in fine le logiciel) satisfont la STB

Moyens : revues de projet, tests

test = chercher des erreurs dans un programme
excution sur un sous-ensemble fini de donnes

4 types de tests :
test
test
test
test

unitaire : composants isols

dintgration : composants assembls
systme : systme install sur site
dacceptation : test par lutilisateur
31

Validation
But : vrifier par rapport aux utilisateurs

Moyen : revues de projet

32

Maintenance
But :
corriger des dfauts
amliorer certaines caractristiques
suivre les volutions (besoin, environnement)

Remarque :
peut remettre en cause les fonctions du systme
peut impliquer un re-dveloppement (re-ingeneering)

33

Maquettage / Prototypage
But :
prciser les besoins et les souhaits des utilisateurs
dvelopper rapidement une bauche du systme

2 types de maquettes :
maquette exploratoire : spcification
maquette exprimentale : conception

34

Rpartition des activits

Actuellement, dans un projet logiciel bien conduit :

40 %

Analyse, Spcification, Conception

20 %

Programmation

40 %

Intgration, Vrification, Validation

35

Rsum
analyse des besoins
spcification
(maquettage)

descriptions
de plus en plus
prcises

conception
architecturale

dtaille

programmation
config. et intgration
vrif. et validation

raffinements

Excutable + Doc.

maintenance
36

Introduction
Modle de dveloppement ?
enchanements et interactions entre les activits

But pour le projet : ne pas sapercevoir des pbs qu la fin

contrler lavancement des activits en cours
vrifier / valider les rsultats intermdiaires

Objectif gnral : obtenir des processus de dveloppement

rationnels
contrlables
reproductibles
37

Modles de dveloppement logiciel

modle en cascade (fin des annes 1960)

modle en V (annes 1980)
modle en spirale (Boehm, 1988)

38

Modle en cascade

39

Modle en cascade
principe : le dveloppement se divise en tapes
une tape se termine une certaine date
des docs ou prog. sont produits la fin de chaque tape
les rsultats dtapes sont soumis revue
on passe ltape suivante ssi lexamen est satisfaisant
une tape ne remet en cause que la prcdente

commentaire :
modle sduisant car simple
moyennement raliste (trop squentiel)

40

Modle en V

41

Modle en V
principe : les premires tapes prparent les dernires
interprtation : 2 sortes de dpendances entre tapes
en V, enchanement squentiel (modle en cascade)
de gauche droite, les rsultats des tapes de dpart
sont utiliss par les tapes darrive

commentaire :
avec la dcomposition est crite la recomposition
vrification objective des spcifications
modle plus labor et raliste
prouv pour de grands projets, le plus utilis

42

Modle en spirale

43

Modle en spirale
principe : dveloppement itratif (prototypes)
interprtation : chaque mini-cycle se droule en 4 phases
1. Analyse des besoins, Spcification
2. Analyse des risques, Alternatives, Maquettage
3. Conception et Implmentation de la solution retenue
4. Vrification, Validation, Planification du cycle suivant

commentaire :
nouveau : analyse de risques, maquettes, prototypage
modle complet, complexe et gnral
effort important de mise en uvre
utilis pour projets innovants ou risques
44

Rsum
modles : enchanements et interactions entre tapes
passage dune tape la suivante :
documents, tests
vrifis et valids

3 modles : cascade, V, spirale (squentiels et itratif)

cascade : simple mais pas trs raliste
spirale : nouvelles notions, trs complet mais lourd
V : assez raliste, le plus prouv et utilis

45

Maturit du processus de dveloppement

notion dfinie par le SEI (Software Engineering Institute)
Capacity Maturity Model (CMM)
5 niveaux de maturit :
Initial
Reproductible
Dfini
Gr
Optimis

46

Niveaux de maturit

47

Etude amricaine (1991)

Etude SEI
Organisations amricaines

48

Etude amricaine (1999)

Etude SEI
Organisations amricaines

49

Principes du Gnie Logiciel

Vers lAssurance Qualit

50

Diffrentes perceptions de la qualit

QUALIT
EXTERNE

QUALIT
INTERNE
51

Facteurs de qualit

-1

Qualit externe :
compltude fonctionnelle
ralise toutes les tches attendues

ergonomie / convivialit
facile dutilisation
apprentissage ais

fiabilit / robustesse
tches effectues sans problme
fonctionne mme dans des cas atypiques
52

Facteurs de qualit

-2

Qualit interne :
adaptabilit
facile modifier, faire voluer

rutilisabilit
des parties peuvent tre rutilises facilement

traabilit / comprhension
le fonctionnement du logiciel est facile comprendre

efficacit / performance
bonne utilisation des ressources (mmoire, cpu, )

portabilit
capacit marcher dans un autre contexte ou env.
53

Comment agir sur la qualit logicielle ?

La qualit est atteinte ou amliore en appliquant
certains principes :
rigueur et formalisme
sparation des proccupations
modularit
gnralit / abstraction
incrmentalit
anticipation des changements
54

Rigueur et formalisme
rigueur = prcision, exactitude (confiance en la fiabilit)

formalisme = le plus haut degr de rigueur (mathmatiques)

ncessaire pour les parties critiques (haut risque)
peut tre utilis dans chaque phase
spcification formelle
vrification formelle (preuve)
analyse de complexit dalgorithmes

55

Sparation des proccupations

-1

principe : traiter sparment les aspects dun problme

diviser pour rgner

rsultat : rduit la quantit de complexit contrler

56

Sparation des proccupations

-2

diffrentes sortes de sparations :

sparation de domaine
domaine de problme : quoi rsoudre ?
domaine de solution : comment rsoudre ?
sparation de temps : phases du cycle de vie
sparation de qualit
maquettes, prototypes
conception globale, dtaille
vues spares sur le logiciel : modlisation en UML
cas dutilisation, structure statique
comportement dynamique, architecture
sparation de responsabilits : org. en quipes projet
57

Modularit

principe : sparer le systme en composants logiques

modules

avantages :
rduction de complexit
les modules peuvent tre
conus et construits sparment
rutiliss
systme modifi en changeant un nombre limit de modules
58

Gnralit / Abstraction
principe :
gnraliser un problme particulier
le rendre rutilisable dans dautres contextes

exemple :
logiciel gnrique vs logiciel sur mesure
design patterns : des solutions gnralises pour des
problmes typiques de conception

59

Incrmentalit
principe :
dvelopper le logiciel en une srie dincrments
se rapprocher de la solution par raffinements successifs

exemple :
phase de conception
cycle de vie en spirale

60

Anticipation des changements

le logiciel volue constamment pour diffrentes raisons :
rparation des erreurs dtectes
adaptation de nouveaux environnements
traitement de nouvelles exigences
changements dans les exigences
changement des formats de donnes
changement dexigences non-fonctionnelles

avant de dvelopper, poser les questions :

quels changements, o ?
comment les rendre plus faciles appliquer ?
61

Rsum
la qualit du logiciel est fondamentale
elle est perue diffremment selon les points de vue :
qualit externe : client, utilisateurs
qualit interne : dveloppeurs, gestionnaires

pour latteindre, on adopte des principes

participation des activits et modles de dveloppement
lutilisation de lapproche OO participe aussi beaucoup
remplir ces objectifs

62

Rsum gnral
logiciel programme
problmes :

pas fiable
dpassements (dlais, cots)
non conforme au cahier des charges

gnie logiciel :

dmarche ingnierique
mthodes, principes, outils

mthodes :

processus de dveloppement
activits et modles (cascade, V, spirale)

principes : pour atteindre des objectifs de qualit

outils : Ateliers de Gnie Logiciel (AGL)
63

Conclusion
situation en progrs :

logiciel plus fiable

plus facilement modifiable
satisfait mieux les utilisateurs

en contrepartie, les problmes sont plus critiques,

centr. tlph., centrales nuclaires
avions, spatial, ferroviaire
banque, bourse,

plus complexes,
de plus en plus de fonctionnalits
systmes distribus
mutations technologiques rapides

et les exigences plus fortes (fiabilit, permanence du service)

la matrise du logiciel reste un dfi scientifique et
technologique majeur

64

BIBLIOGRAPHIE

Normes ISO 2000 V2000- V2008

Normes ISO 14001
norme IEEE, 2004 SWEBOK: Software Engeneering
Body Of Knowledge,.
L'assurance qualit logicielle : Tome 1, Concepts de
base de Alain April et Claude Laporte
L'assurance qualit logicielle : Tome 2, Processus de
support de Claude Laporte et Alain April
Strohmeier A., Buchs D., Gnie logiciel : principes,
mthodes et techniques, Lausanne, Presses
polytechniques et universitaires romandes, 1996.
Cours EPITA Stphanie CARON
65
Cours Polytech Nice, Michel KOENIG