Gnie Logiciel Avanc

Cours 1 : Introduction
Yann Rgis-Gianas
yrg@pps.jussieu.fr
PPS - Universit Denis Diderot Paris 7

29 janvier 2010

Quest-ce que le gnie logiciel ?

Le gnie logiciel est un domaine des sciences de lingnieur dont lobjet

dtude est la conception, la fabrication et la maintenance des
systmes informatiques complexes.

Quest-ce quun systme ?

Un systme est un ensemble dlments intragissant entre eux suivant un

certains nombres de principes et de rgles dans le but de raliser un objectif.

La frontire dun systme est le critre dappartenance au systme.

Lenvironnement est la partie du monde extrieure au systme.

Un systme est souvent hirarchis laide de sous-systmes.

Un systme complexe se caractrise par :

I
I

sa dimension qui ncessite la collaboration de plusieurs personnes ;

son volutivit.

Exemples : une fourmilire, lconomie mondiale, le noyau linux, . . .

Quest-ce quun logiciel ?

Un logiciel est un ensemble dentits ncessaires au fonctionnement dun

processus de traitement automatique de linformation.
Parmi ces entits, on trouve par exemple :
I
I
I

des programmes excutables ;

des documentations dutilisation ;
des informations de configuration.

Quest-ce quun logiciel ?

I
I

Un logiciel est en gnral un sous-systme dun systme englobant.

Il peut interagir avec des clients, qui peuvent tre :
I
I
I

des oprateurs humains (des utilisateurs, des administrateurs, . . . ) ;

dautres logiciels ;
des contrleurs matriels.

Il ralise une spcification : son comportement vrifie un ensemble de critres

qui rgissent ses interactions avec son environnement.

Le gnie logiciel vise garantir que :

1.
2.
3.
4.

la spcification rpond aux besoins rels de ses clients ;

le logiciel respecte sa spcification ;
les cots allous pour sa ralisation sont respects ;
les dlais de ralisation sont respects.

Comment spcifier un logiciel ?

Que doit faire le logiciel ?

La spcification dun logiciel peut prendre de nombreuses formes.

La complexit et les dimensions de la spcification peuvent varier

normment en fonction de lenvironnement dutilisation du logiciel et des
objectifs auxquels il rpond.

Quelques exemples de spcifications

I, Precondition(I) = O, Postcondition(I, O)

Un algorithme de tri :
I
I
I
I

Entre : un tableau t.
Prcondition : il existe une relation dordre sur les lments du tableau.
Sortie : un tableau u.
Postcondition : u est tri et contient exactement les mmes lments que t.

La partie arrire dun compilateur :

I
I
I
I

Entre : un arbre de syntaxe abstraite P.

Prcondition : le programme est bien typ.
Sortie : un fichier excutable E .
Postcondition : la smantique de E est la mme que celle de P.

Ce sont des spcifications simples dont la conformit aux objectifs de leurs

clients ne fait aucun doute. (Cela ne rend pas aise pour autant leur
ralisation.)

Quelques exemples de spcifications plus complexes

Une interface graphique : Le modle dinteraction avec le client est non

dterministe. Doit-on spcifier toutes les traces dexcution possibles ?

Un traducteur automatique : Quest-ce quun texte anglais bien crit ?

Un logiciel boursicoteur (effectuant des achats et des ventes en bourse) :

Comment tablir une spcification sans y inclure un modle du systme
financier ?

Un jeu vido : Comment spcifier ce qui est amusant ?

Comment concevoir un logiciel de qualit ?

En plus du respect (essentiel) de sa spcification, la qualit dun logiciel

dpend des 4 critres suivants :
1.
2.
3.
4.

Maintenabilit : Peut-on faire voluer le logiciel ? 1

Robustesse : Le logiciel est-il sujet des dysfonctionnements ?
Efficacit : Le logiciel fait-il bon usage de ses ressources ?
Utilisabilit : Est-il facile utiliser ?

1 Un logiciel ne suse pas. La correction dune erreur nest pas volution mais un chec du concepteur.

Comment fabriquer un logiciel de qualit ?

I

Historiquement, il y a eu une prise de conscience dans les annes 70, appele

la crise du logiciel, d un tournant dcisif : cest cette poque que le
cot de construction du logiciel est devenu plus important que celui de la
construction du matriel.
The major cause of the software crisis is that the machines have
become several orders of magnitude more powerful ! To put it quite
bluntly : as long as there were no machines, programming was no
problem at all ; when we had a few weak computers, programming
became a mild problem, and now we have gigantic computers,
programming has become an equally gigantic problem.
Edsger Dkstra, The Humble Programmer (EWD340)
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html

Comment fabriquer un logiciel de qualit ?

Pour rpondre cette crise, on a essay dappliquer les mthodes connues de

lingnieur au domaine du logiciel, pour tablir des mthodes fiables sur
lesquelles construire une industrie du logiciel.
Il sagit de se donner un cadre rigoureux pour :
I
I
I

Guider le dveloppement du logiciel, de sa conception sa livraison.

Contrler les cots, valuer les risques et respecter les dlais.
tablir des critres dvaluation de la qualit dun logiciel.

Les spcificits du logiciel

Cependant, la construction dun logiciel diffre de celle dun pont car :

I
I
I
I
I
I
I
I

une modification infime peut avoir des consquences critiques ;

les progrs technologiques trs rapides peuvent rendre un logiciel caduque ;
il est difficile de raisonner sur des programmes ;
les domaines des entres des logiciels sont trop grands pour le test exhaustif ;
les dfaillances des programmes sont en gnral dues des erreurs humaines ;
on ne sait pas trs bien rutiliser les programmes existants ;
chaque logiciel a son organisation et sa logique propre ;
...

Comment fabriquer un logiciel de qualit ?

Le gnie logiciel est un domaine en pleine volution qui offre une grande
palette doutils et de mthodes pour parvenir construire du logiciel de
qualit.

Aucune de ses mthodes ne sest impose ce jour : il faut donc prendre du

recul sur les concepts et les conseils quelles prconisent et utiliser son bon
sens pour les adapter chaque situation.
Ces mthodes se distinguent principalement par :

I
I
I

leur degr de formalisme ;

leur champ dapplication ;
les contraintes de qualit quelles ambitionnent.

Comment fabriquer un logiciel de qualit ?

Les approches formelles utilisent des outils mathmatiques et des mthodes

de preuve pour construire un logiciel correct par construction dont la
vrification est automatise ou assiste.
Mthodes : mthode B, Model-checking, Logique de Hoare . . .

Outils et notations : Coq, Z, VHDL, Atelier B, CASL, Why, Frama-C, . . .

Ces mthodes sont utilises pour dvelopper des logiciels critiques.

Elles correspondent au niveau le plus lv de certification.

Comment fabriquer un logiciel de qualit ?

Les approches semi-formelles visent introduire un langage normalis pour

dcrire le logiciel et sa spcification.

Cependant, la smantique du langage de spcification nest pas

formalise.

Bien que ces approches prcisent le discours du concepteur si on le compare

celui dcrit laide du langage naturel, elles contiennent certaines
ambiguts et noffrent aucune garantie sur la qualit des rsultats.

Mthodes : Rationale Unified Process, Merise, . . .

Outils et notations : UML, AnalyseSI, . . .

Ces mthodes sont utilises aujourdhui par lindustrie du logiciel.

Comment fabriquer un logiciel de qualit ?

Les approches empiriques mettent en avant un ensemble de bonnes

pratiques qui ont fait leur preuve par lexprience.

Mthodes : relecture de code, extreme programming, programmation

dfensive, . . .
Outils : gestionnaire de versions, outil de documentation automatique, . . .

Les grands principes du gnie logiciel

Un certain nombre de grands principes (de bon sens) se retrouvent dans

toutes ces mthodes. En voici une liste propose par C. Ghezzi :
1.
2.
3.
4.
5.
6.
7.

La rigueur.
La dcomposition des problmes en sous-problmes indpendants.
La modularit.
Labstraction.
Lanticipation des volutions.
La gnricit.
La construction incrmentale.

La rigueur

Les principales sources de dfaillances dun logiciel sont dorigine humaine.

tout moment, il faut se questionner sur la validit de son action.

Des outils de vrification accompagnant le dveloppement peuvent aider
rduire les erreurs. Cette famille doutils sappelle CASE (Computer Aided
Software Engineering).

Exemples : typeurs, assistants de preuves, gnrateurs de code, gnrateurs

de tests. . .

La dcomposition des problmes en sous-problmes

Separation of concerns en anglais.

Il sagit de :
I
I

Dcorrler les problmes pour nen traiter quun seul la fois.

Simplifier les problmes (temporairement) pour aborder leur complexit
progressivement.

La dcomposition des problmes en sous-problmes

Let me try to explain to you, what to my taste is characteristic for all
intelligent thinking. It is, that one is willing to study in depth an aspect of
ones subject matter in isolation for the sake of its own consistency, all the
time knowing that one is occupying oneself only with one of the aspects.
We know that a program must be correct and we can study it from that
viewpoint only ; we also know that it should be efficient and we can study
its efficiency on another day, so to speak. In another mood we may ask
ourselves whether, and if so : why, the program is desirable. But nothing is
gained on the contrary ! by tackling these various aspects simultaneously.
It is what I sometimes have called "the separation of concerns", which, even
if not perfectly possible, is yet the only available technique for effective
ordering of ones thoughts, that I know of. This is what I mean by "focusing
ones attention upon some aspect" : it does not mean ignoring the other
aspects, it is just doing justice to the fact that from this aspects point
of view, the other is irrelevant. It is being one- and multiple-track minded
simultaneously.

Edsger Dkstra, On the role of scientific thought

La dcomposition des problmes en sous-problmes

Exemple 1 :
Comment acheminer un email de faon sr travers un rseau ?
Dcomposition en couches utilise sur Internet :
I

STMP : protocole de la couche application qui suppose une couche de

transport de paquet sr.
TCP : protocole de la couche transport permettant de sassurer que tous les
paquets arrivent, mme si le rseau peut perdre des paquets.

Exemple 2 :
Comment crer dynamiquement une page internet pour visualiser et modifier
le contenu dune base donne sans la corrompre ?
Dcomposition en trois composants :
I

I
I
I

Modle : son rle est grer le stockage des donnes.

Vue : son rle est formatter les donnes.
Contrleur : son rle est de nautoriser que les modifications correctes.

La modularit

I
I

Cest une instance cruciale du principe de dcomposition des problmes.

Il sagit de partitionner le logiciel en modules qui :
I
I

ont une cohrence interne (des invariants) ;

possdent une interface ne divulgant sur le contenu du module que ce qui est
strictement ncessaire aux modules clients.

Lvolution de linterface est indpendante de celle de limplmentation du

module.

Les choix dimplmentation sont indpendants de lutilisation du module.

Ce mcanisme sappelle le camouflage de linformation (information

hiding).

Labstraction

Cest encore une instance du principe de dcomposition des problmes.

Il sagit dexhiber des concepts gnraux regroupant un certain nombre de

cas particuliers et de raisonner sur ces concepts gnraux plutt que sur
chacun des cas particuliers.
Le fait de fixer la bonne granularit de dtails permet :

I
I

de raisonner plus efficacement ;

de factoriser le travail en instanciant le raisonnement gnral sur chaque cas
particulier.

Exemples en programmation : les classes abstraites dans les langages

objets, le polymorphisme de Caml, les fonctions dordre suprieur.

Lanticipation des volutions

Un logiciel a un cycle de vie plus complexe que lhabituel cycle

commande-spcification-production-livraison .

La maintenance est la gestion des volutions du logiciel.

Il est primordial de prvoir les volutions possibles dun logiciel pour que la
maintenance soit la plus efficace possible. Pour cela, il faut sassurer que les
modifications effectuer soient le plus locales possibles.

Ces modifications ne devraient pas tre intrusives car les modifications du

produit existant remettent en cause ses prcdentes validations.

Concevoir un systme suffisamment riche pour que lon puisse le modifier

incrmentalement est lidal.

La gnricit

Un logiciel rutilisable a beaucoup plus de valeur quun composant ddi.

Un composant est gnrique lorsquil est adaptable.

La construction incrmentale

Un dveloppement logiciel a plus de chances daboutir si il suit une

cheminement incrmental (baby-steps).

Exemple :
Laquelle de ses deux mthodes de programmation est la plus efficace ?
1. crire lensemble du code source dun programme et compiler.
2. crire le code source dune fonction, le compiler et passer la suivante.

 propos des principes

Vous devez avoir en tte ces principes : ils se retrouvent dans toutes les
mthodes et outils que nous allons aborder.

Les processus de dveloppement logiciel

Quest-ce quun processus ?

Un processus de dveloppement logiciel est un ensemble (structur)

dactivits que conduisent la production dun logiciel.

Il nexiste pas de processus idal.

La plupart des entreprises adapte les processus existants leurs besoins.

Ces besoins varient en fonction du domaine, des contraintes de qualit, des

personnes impliques.

Ce qui est essentiel, cest de comprendre quel est son rle dans ce processus
et den saisir les rouages.
Ltude et la pratique de processus existants doit vous permettre de vous
forger un regard affut (et mme critique) sur ces processus.

Activits du dveloppement logiciel

Les activits des processus de dveloppement logiciels se regroupent en 4

grandes catgories :

1. La spcification du logiciel dfinit ses fonctionnalits et leurs contraintes.

2. La conception et limplmentation sont charges de raliser le logiciel, en
conformit avec sa spcification.
3. La validation sassure effectivement du respect de la spcification par le
logiciel produit.
4. Lvolution adapte le logiciel aux besoins futurs de ses clients.

Schma gnral dun processus de dveloppement

Il est trs rare dappliquer un processus comme une unique squence des
4 activits prcdentes.

En effet, ce serait lencontre du principe dincrmentalit.

En gnral, un logiciel complet est le fruit de plusieurs itrations.

Chaque itration contient les 4 activits de spcification, conception,

validation et volution.

Il existe diffrents modles de processus qui organisent de faon diffrentes

ces activits : le modle en cascade, le modle de dveloppement volutif et
le modle de dveloppement par composants.

Modle en cascade
Dfinition des besoins

Conception

Implmentation et tests unitaires

Intgration et test du systme

Livraison et maintenance
I

Chaque phase doit se terminer pour commencer la suivante.

Des documents sont produits pour concrtiser la ralisation de chaque phase.

Le modle en cascade
I

Le modle en cascade est hrit des mthodes classiques dingnierie.

Il sadapte donc bien dans un contexte o le logiciel fait partie dun systme
complexe englobant.
I

La production de documents entre chaque phase amliore le suivi du projet.

Lorsquune erreur a t commise dans une phase et quelle est dtecte dans
une phase suivante, il faut faire remonter cette information dans la phase
incrimine et recommencer le processus partir de celle-ci. On doit alors
reproduire de nouveaux documents . . .

Ce modle de processus impose donc une importante rflexion sur les choix
faits en amont car le cot de la correction dune erreur est important.

Typique dun dveloppement industriel pour lequel les cots de la

construction du produit sont trop importants pour se permettre une erreur
de choix de conception.

Critique du modle en cascade

Le modle en cascade rend coteux le dveloppement itratif puisque la

rdaction des documents de validation de chaque phase demande beaucoup
de travail.

Ce modle est inadapt au dveloppement de systmes dont la spcification

est difficile formuler a priori.

Modle de dveloppement volutif

Spcification

Dveloppement

Validation
I

Ces trois activits sont entrelaces.

Un prototype est crit rapidement et est confront lutilisateur.

En fonction du rsultat, on raffine la spcification.

On reprend le prototype ou on le rcrit jusqu lobtention du systme final.

Le modle de dveloppement volutif

Ce modle augmente les chances de rpondre aux besoins de lutilisateur car

il permet de les comprendre plus rapidement. (Are we building the right
product ?)

Il remplit le critre dincrmentalit.

Ce modle ne dispense dcrire la spcification du systme car il faut

sassurer que limplmentation est correct. (Are we building the product
right ?)

Cest un processus particulirement adapt aux projets de taille moyenne ou

importante (infrieur 100 000 lignes de code) comme par exemple les
applications WEB ou encore les solutions intgres pour les petites
entreprises.

Critique du modle de dveloppement volutif

I

Il est plus difficile de grer un projet utilisant ce modle car la visibilit de

lavancement du dveloppement est peu clair.

Dans ce cadre, encore plus que dans un autre, un chef de projet doit aussi
tre un bon programmeur puisquil doit tre capable de se faire une ide de
ltat du systme en observant le dveloppement (possiblement chaotique)
des prototypes.
I

Il est difficile de structurer correctement le logiciel (dfinir de bonnes

abstractions, modulariser efficacement) car les prototypes sont par dfinition
des produits bricols.

Le cot en termes de tests et de validation du produit final peuvent tre trs

importants.

Des approches mixtes intgrant modle de dveloppement volutif pour

produire un premier prototype valid et un modle en cascade pour
reconstruire correctement un produit final constituent en gnral de bons
compromis.

Modle de dveloppement livraison incrmentale

Une approche mi-chemin entre le modle en cascade et le modle de

dveloppement volutif sappuie sur une livraison incrmentale du produit.

On hirarchise les besoins du client en termes de priorit.

Chaque itration du modle vise obtenir un ensemble de fonctionnalits par

ordre de priorit.

Traiter les parties les plus critiques du systme en premier permet de

minimiser les risques dinadquation avec le produit final.

Cependant, il se peut que les choix pris en amont, trop focaliss sur ce noyau
de fonctionnalits, compromettent le dveloppement des fonctionnalits
secondaires.

Modle de dveloppement par composants

Dfinition des besoins

Analyse des composants

Modification des besoins

Conception par rutilisation

Dveloppement et intgration

Validation du systme

Modle de dveloppement par composants

Ce modle vise dvelopper un logiciel en grande partie laide dune base

de composants gnriques pr-existants.

Llaboration de la spcification est dirige par cette base : une

fonctionnalit est propose lutilisateur en fonction de sa facilit lobtenir
laide dun composant existant.

Situation typique chez les socits de services (hbergement de serveurs,

dploiement automatique de site web, etc . . . ).
I

Ce modle permet dobtenir rapidement des produits de bonne qualit

puisquils sont construits partir de composants qui ont fait leur preuve.

Le travail dintgration peut sappuyer sur des outils dirigs par des
descriptions de haut-niveau du systme qui gnrent le code de glue par
exemple.

Critique du modle de dveloppement par composants

Le principal dfaut de ce modle est de ne pas construire un produit adapt

aux besoins du client.

Un travail complexe de configuration et dadaptation peut tre ncessaire.

La gestion de projet

Quel est le rle dun chef de projet ?

Les activits de gestion dun projet informatique sont trs similaires celles
des autres domaines :
I
I
I
I
I
I

criture de proposition de projet

Plannification du projet
valuation des cots
Surveillance du projet et criture de rapport dtapes
Slection du personnel et valuation
criture de rapport et de prsentation

crire une proposition de projet

partir dun appel doffre, un chef de projet doit crire une proposition de
projet dcrivant les objectifs du projet (en gnral, ses dlivrables) et les
grandes lignes de sa ralisation.

Une proposition doit aussi contenir une valuation des risques et des cots.

La plupart du temps, cette proposition doit servir dargumentaire pour

justifier la mise en route du projet.

Cest une activit qui requiert une importante exprience et comprhension

du domaine dactivit. Le chef de projet engage sa responsabilit.

Plannifier un projet

Le chef de projet doit tablir un jalonnement, cest--dire une rpartition des

activits dans le temps en fonction de leurs dpendances et des ressources
disponibles et dune valuation des risques lis leur ralisation.

Il sagit dun travail dordonnancement qui ncessite encore une connaissance

trs prcise du domaine, des quipes de dveloppement, etc . . .

Veiller sur un projet

De faon continue, le chef de projet sassure du progrs des tches et du

respect des dlais.

En cas de retard, il doit rvaluer la plannification et ventuellement

rengocier les ressources et les contraintes du projet.

La visibilit de la progression des activits est ici essentielle. Un chef de

projet doit donc savoir se doter dindicateurs rvlateurs sur ltat du
dveloppement.

Slectionner le personnel

En cohrence avec la politique de gestion du personnel (projet de carrire,

formation continue, sous-traitement, . . . ), le chef de projet doit affecter des
activits et des rles aux diffrentes personnes impliques dans le projet.

Des qualits relationnelles semblent donc utiles. . .

crire un rapport

Le chef de projet doit pouvoir communiquer une vue synthtique du projet

diffrents publics (autres chefs de projet, clients, responsables, etc . . . ).

Synthse de cette introduction

Objectifs du cours

Ce cours a pour but de vous familiariser avec les futures structures de votre
vie professionnelle et de vous donner les outils de vous adapter la situation,
ncessairement singulire, dans laquelle vous serez acteurs.

Il a aussi pour objectif de dvelopper vos capacits danalyse de problmes

de conception logiciel.

Organisation du cours

Le cours se droule le vendredi en amphi 6C de 8h30 10h30 et sera

prsent par Mihaela Sighireanu et Yann Rgis-Gianas.
Les travaux dirigs se droulent le vendredi de 10h30 12h30 en salle 473F
et sont encadrs par Constantin Enea et Mihaela Sighireanu.

La page du cours : http://www.pps.jussieu.fr/~yrg/gl/index.php

Inscrivez-vous sur la mailing-list ! (voir le site).

Validation

Le cours est valid par un projet et par un examen.

Le projet consiste dvelopper un logiciel en quipe, en utilisant les

mthodes et outils de gnie logiciel que nous dcouvrirons.

Bibliographie

Software Engineering 8me dition

Sommerville Addison Wesley

Gnie logiciel
J. Longchamp Cours de CNAM

QCM : Question 1

Le gnie logiciel fournit des outils et des mthodes pour :

 analyser les besoins dun client.
 crer des besoins chez un potentiel client.
 sassurer que les contraintes budgtaires dun projet sont respectes.
 raliser correctement une spcification.
 construire des composants logiciels rutilisables.

QCM : Question 2

Le produit appel logiciel peut tre compos :

 de programmes excutables.
 de tests.
 de manuels dutilisation.
 de scripts de configuration automatique.

QCM : Question 3

La spcification dun logiciel peut :

 tre dfinie aprs son implmentation.
 tre issue de ltape de validation.
 ne pas exister.
 tre inapproprie.
 tre incohrente.

QCM : Question 4

La robustesse dun programme est :

 caractrise par sa rsistance aux chocs.
 proportionnelle sa stabilit.
 une consquence de sa correction vis--vis de sa spcification.
 une condition ncessaire sa correction vis--vis de sa spcification.

QCM : Question 5

La crise du logiciel tait cause par :

 une crise de linvestissement dans le domaine informatique ;
 un inversement du rapport entre les cots du logiciel et du matriel ;
 un dficit en informaticiens sur le march du travail.

QCM : Question 6

Une mthode de dveloppement formelle :

 prouve mathmatiquement la correction dun logiciel vis--vis de sa
spcification.
 nest pas trs coteuse.
 rend inutile les phases de tests.
 est toujours applicable.
 peut sappuyer sur le langage UML.

QCM : Question 7

Quels sont les bons principes de dveloppement dans la liste suivante :

 la modularit ;
 le code spaghetti ;
 la rinvention de la roue ;
 le code est la spcification ;
 la dcomposition des problmes.

(C.f. les anti-patterns )

QCM : Question 8

Cacher les dtails dimplmentation :

 est une erreur de conception puisquil faut que le client dun module ait un
maximum dinformation sur ce module pour lutiliser au mieux.
 permet de faire rendre indpendant limplmentation dun module de ses
utilisations.
 introduit une forme dabstraction.
 est impossible lorsque lon programme vraiment.

QCM : Question 9

Un processus de dveloppement :
 fixe un cadre rigoureux pour le dveloppement de projets de taille
importante.
 est une perte de temps !
 doit sappliquer la lettre.
 peut tre itr.
 peut sappuyer sur plusieurs modles de processus.

QCM : Question 10

Cest le rle dun chef de projet :

 de programmer les composants dun logiciel.
 de vrifier le bon droulement des tches.
 dorganiser lenchanement des tches.
 de fournir une visibilit globale sur un projet.
 dcrire la spcification du logiciel.