GNIE LOGICIEL

Quest-ce quun logiciel ?

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

il est complexe et de trs grande taille

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

il fait intervenir plusieurs participants

travail en quipes, organisation, planification

il est long et coteux dvelopper

risques nombreux et important : dlais, cot
2

Dfinition du logiciel

Un logiciel (software) est lensemble des programmes, des procdures et des documentations ncessaires au fonctionnement dun systme informatique

Caractristiques du logiciel
le logiciel est facile reproduire
tout le cot se trouve dans le dveloppement

-1

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
le logiciel ne suse pas, mais il vieillit
Dtrioration suite aux changements :
duplication de code introduction derreurs

-2

Mal conu au dpart :

inflexibilit manque de modularit documentation insuffisante

Evolution du matriel

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)

bug de lan 2000

Problme de format de date (changement de version)

Tout systme comporte des bugs

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

10

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

Les dpassements de dlais sont frquents

11

Naissance dune nouvelle discipline

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

12

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

13

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

14

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 !

15

Dveloppement systmatique et volution

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

16

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

17

Respectant les contraintes

les ressources sont limites (temps, argent, ) le bnfice doit tre suprieur aux cots la productivit doit rester concurrentielle mauvaise estimation chec

18

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

19

Mthodes du Gnie Logiciel

Mthodologies de dveloppement

20

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

21

Activits du dveloppement de logiciel

analyse des besoins spcification

conception
programmation intgration vrification et validation

22

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
23

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
24

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

25

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

26

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

27

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)

28

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

29

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
30

Validation
But : vrifier par rapport aux utilisateurs

Moyen : revues de projet

31

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)

32

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

33

Rpartition des activits

Actuellement, dans un projet logiciel bien conduit :

40 %
20 %

Analyse, Spcification, Conception

Programmation

40 %

Intgration, Vrification, Validation

34

Rsum
analyse des besoins spcification descriptions de plus en plus prcises = raffinements Excutable + Doc.
35

(maquettage)
conception
architecturale dtaille

programmation config. et intgration vrif. et validation maintenance

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
36

Modles de dveloppement logiciel

modle en cascade (fin des annes 1960) modle en V (annes 1980) modle en spirale (Boehm, 1988)

37

Modle en cascade

38

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)

39

Modle en V

40

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
41

Modle en spirale

42

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
43

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

44

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

45

Niveaux de maturit

46

Principes du Gnie Logiciel

Vers une assurance qualit

47

Diffrentes perceptions de la qualit

QUALIT EXTERNE

QUALIT INTERNE
48

Facteurs de qualit
Qualit externe :
compltude fonctionnelle
ralise toutes les tches attendues

-1

ergonomie / convivialit
facile dutilisation
apprentissage ais

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

Facteurs de qualit
Qualit interne :
adaptabilit
facile modifier, faire voluer

-2

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.

50

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
51

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

52

Sparation des proccupations

-1

principe : traiter sparment les aspects dun problme

diviser pour rgner

rsultat : rduit la quantit de complexit contrler

53

Sparation des proccupations

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

-2

vues spares sur le logiciel : modlisation en UML cas dutilisation, structure statique comportement dynamique, architecture sparation de responsabilits : org. en quipes projet
54

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
55

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

56

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

57

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 ?
58

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

59

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

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
61