Gnie Logiciel.

Plan du cours

I. II.

Introduction, gnralits Mthodes danalyse (panorama)

III. Mthodes SADT, PETRI, MERISE IV. Mthodes objets, introduction UML V. Etude de cas en UML

VI. Tests
1/1

Ch1.doc

28/04/04

Bibliographie :
P.Andr et A.Vailly Gnie Logiciel T1 et T2 Ellipses 2001 P.Jaulent Gnie logiciel : les mthodes Colin 1992 MC Gaudel B. Marre Prcis de gnie logiciel Masson 1996. B. Meyer Conception et programmation par objet, pour du logiciel de qualit Inter ditions 1990. J.RUMBAUCH et al Modlisation et conception objet Masson 1997 Coad et Yourdon Analyse oriente objet Prentice Hall Masson 1992. P. Desfray Modlisation par objets Inter Editions 1997. P.A.Muller Modlisation objet avec UML Eyrolles 1998 www.cui.unige.ch/ScDep/Cours/GenieLogiciel/index.html http://www.gpa.etsmtl.ca/cours/gpa77 http://cui.unige.ch/ScDep/Cours/GenieLogiciel/ http://www.cours.polymtl.ca/inf2300 2/2

Ch1.doc

28/04/04

Ch I : Introduction
A : Gnralits
Dfinitions :
Gnie logiciel : expression ne en Europe Garmisch-Partenkirchen (software engineering) sous le parrainage de lOTAN (1968) Ensemble des techniques et des mthodes permettant de produire du logiciel, de AZ
http://www.laria.u-picardie.fr/docs/www.linux-france.org/prj/jargonf/G/geacutenie_logiciel.html

Le gnie logiciel dsigne lensemble des activits de conception et de mise en uvre des produits et des procdures pour rationaliser la production logiciel et son suivi (maintenance). Il se proccupe de la ralisation, de la gestion, de la maintenance, de la qualit et de lutilisation dun produit de programmation par un nombre important de personnes et pour une dure longue (multiples versions). La ncessit sest faite sentir tant donn le peu de fiabilit du logiciel et des difficults rendre dans les dlais prvus, des logiciels satisfaisant un cahier des charges.
Ch1.doc

3/3

28/04/04

Dfinitions (3)
le gnie logiciel sintresse aux diffrentes thories aux mthodologies : ( techniques, mthodes ) aux outils lorganisation gnrale la gestion de projets

Ch1.doc

4/4

28/04/04

Constat :
linformatique reprsente une part significative du PNB Les logiciels deviennent de plus en plus importants en taille et en complexit : (ex : volution des S.E) La diminution des cots du matriel (hardware) a conduit associer lordinateur de plus en plus de produits. Les cots des logiciels connaissent une trs forte croissance, dominant maintenant le cot du matriel et peuvent reprsenter plus de 80 % du cot total dun systme informatique. (ex cot de la mmoire conomise).

Ch1.doc

5/5

28/04/04

Constat (2)
Fiabilit souvent plus importante quefficacit : (activits militaires, bancaires, gestion des transports, distribution des ressources ) les cots de maintenance dpassent ceux du dveloppement Le cot dune erreur peut dpasser largement le cot du systme les pannes causes par des problmes de logiciel ont cot en 2000 aux entreprises du monde entier environ 175 milliards de dollars, soit au moins deux fois plus qu'il y a deux ans. Le Monde 23 oct. 2001. Paradoxe : on estime que 80 % du dveloppement du logiciel existe dj. Rem : il est plus facile dacclrer un programme qui fonctionne que de faire fonctionner un programme cens tre rapide. [Dijkstra]
Ch1.doc

6/6

28/04/04

Existant
La taille des programmes augmente considrablement : Chez Thomson, les programmes sont passs en 5 ans de 20.000 lignes assembleur en moyenne 150.000 lignes ADA. La gestion dun central tlphonique comporte 1 million de lignes. La navette spatiale en demande 50 millions, soit plusieurs milliers dhommes annes . Par ailleurs les domaines traits deviennent de plus en plus sensibles : nuclaire, systmes bancaires, tlcommunications, fichiers de personnes etc. (SoftWar)

Ch1.doc

7/7

28/04/04

Bilan :
Semi chec : tude sur 487 sites de toutes sortes de dveloppement de logiciels o 70% du cot du logiciel est consacr sa maintenance. o 42% des modifications sont dues des demandes de lutilisateur o 30% des exigences de spcification changent entre la 1re dition dune documentation et la premire sortie du produit o 17% des changements de format des donnes (an 2000, 2a 2b ) o 12% problmes durgence rsolus la hte. o 9% dboguages de programmes o 6% des changements de matriel o 6% problmes de documentation. o 4% amliorations de lefficacit o 3% autres Certaines organisations de production de logiciel consacrent la quasi totalit de leurs efforts la maintenance des produits livrs. 8/8

Ch1.doc

28/04/04

Quelques exemples
Mission Vnus : passage 500 000 km au lieu de 5000 (remplacement dune virgule par un point) Perte dune sonde (Mariner) pour cause derreur en Fortran avion F16 dclar sur le dos au passage de lquateur. faux dpart de la premire navette spatiale (pb de synchro entre 2 calculateurs) guerre des malouines : non reconnaissance de lExocet fuse russe pointant Hambourg au lieu du ple Nord (erreur de signe do erreur de 180 ) 72 ballons dtruits par un satellite mtorologique. Fuse tombant dans leau (mauvaises units dans les donnes) le dveloppement du compilateur PL1 de Control Data (jamais abouti) dcs dans un hpital (erreur de monitoring)

Ch1.doc

9/9

28/04/04

quelques exemples (2)

dclenchement du systme de dtection amricain des missiles stratgiques (la lune montante lhorizon confondue avec un OVNI) inondation en 83 de la rivire du Colorado (mauvaise modlisation du temps douverture du barrage) nombreux retards pour le dpart de la navette. abonns privs dappels longue distance ATT. Socrate (S.N.C.F.) retards importants, abandons de fonctionnalits Apoge (Universits) L'explosion d'Ariane 5, le 4 juin 1996 mauvaise actualisation dun soft Ariane4 Passage lan 2000. Erreurs dans les S.E., passage lan 2000. Crash de la sonde martienne (2000) Guerre du Soft devenant une arme 10/10

Ch1.doc

28/04/04

Principes du gnie logiciel

Lide est de considrer un logiciel comme un objet manufactur complexe et de dfinir des techniques de fabrication justifies par la thorie et par la pratique. Cest donc lart de spcifier, concevoir, raliser et faire voluer des programmes, des documentations et des procdures de qualit, avec des moyens plausibles et dans des dlais raisonnables.

Ch1.doc

11/11

28/04/04

Principes (2)
rle de linformaticien : o modliser et utiliser ce modle comme rfrence o traduire un cahier de charges vagues en spcifications prcises o communiquer avec tous les intervenants. o transmettre les informations lutilisateur en terme dapplication et non de problme dordinateur o matriser les diffrents niveaux dabstraction o Spcifier o Programmer o Faire les preuves de programmes et vrifications o Soccuper de la maintenance
Ch1.doc

12/12

28/04/04

Principes (3)
le gnie logiciel propose des mthodes et des outils pour Faciliter la communication Organiser des projets (planification et communication pour le travail en quipe). Documenter, dfinir et respecter des normes Estimer les cots et les dlais Organiser les ressources (humaines, matrielles, logicielles) Suivre lvolution du logiciel (maintenance, cycle de vie) Mesurer la qualit des logiciels utiliss

Ch1.doc

13/13

28/04/04

Objectifs externes :
point de vue de lutilisateur Diminuer les cots augmenter la productivit amliorer la qualit des produits faciliter le travail des programmeurs Diminuer terme la part laisse aux spcialistes (analystes, programmeurs, experts )

De plus en plus dentreprises sont conscientes de laide ainsi apporte.

Ch1.doc

14/14

28/04/04

Objectifs internes
point de vue du programmeur Aide lanalyse Rutilisation, gnralisation Dcomposition, modularit Portabilit Modifiabilit Testabilit Qualit-Fiabilit Ergonomie Efficacit Edition de documents
Ch1.doc

15/15

28/04/04

Qualits externes significatives

Fonctionnalit Correction: satisfait sa spcification (fonction attendue) de manire absolue Fiabilit: notion relative par rapport aux utilisateurs dpendants de ce logiciel Robustesse: comportement raisonnable mme en cas non prvu, (trs fortement li la correction (complmentaire).) Performance valuation par mesure, analyse et simulation. Ergonomie

Ch1.doc

16/16

28/04/04

Qualits internes significatives

Vrifiabilit lie la modularit et aux langages choisis. Maintenabilit (~60% du cot) = une volution du logiciel. maintenance corrective: liminer les erreurs maintenance adaptative: changement dans lenvironnement Rutilisation (priori ou posteriori) Portabilit (produit indpendant du genre denvironnement) Interoprabilit: capacit inter agir avec dautres systmes; qualit rare pour le logiciel mais courante dans dautres domaines;

Ch1.doc

17/17

28/04/04

Exemple 1
Rgles de gestion valables pour toute lapplication Tous les crans ont la mme ergonomie. Tous les crans doivent proposer d'enregistrer les modifications lors de leur fermeture lorsqu'ils ont t modifis. La mme fonction est toujours reprsente par la mme icne. Le libell d'une donne est toujours le mme. Chaque fonction accessible par une icne est systmatiquement double par une occurrence dans un menu. Chaque icne spcifique l'application doit avoir une bulle explicative. Pour chaque critre de recherche, une liste d'aide est disponible en slectionnant la flche positionne en bout du champ. etc.
Ch1.doc

18/18

28/04/04

Exemple 2

Ch1.doc

19/19

28/04/04

Exemple 3
Elaboration dun module e-miage.

VII.

Ch1.doc

20/20

28/04/04

Cycle de vie dun systme

Un systme est une ensemble dquipements, de savoir faire et de techniques capable de jouer un rle oprationnel ou dapporter un soutien logistique [P.Jaulent]

Ch1.doc

21/21

28/04/04

Qualification dun logiciel :

5 niveaux ont t dfinis pour classer les tats densembles de projets Initial : tat chaotique, cots, dlais qualit imprvisibles, mise en place de la gestion du projet, de sa configuration et des soucis de qualit. Reproductible : rsultat artisanal, dlais fiables, cots variables, mthodes mal dfinies Dfini : cots fiables qualit variable, mthodes dfinies Gr : processus contrl et mesur, qualit fiable Optimis : analyse pour lamlioration des cots dlais et qualit.

Ch1.doc

22/22

28/04/04

Cycle de vie
Spcifications Analyse des besoins Etude de la faisabilit du systme. Planification Conception prliminaire du systme Conception dtaille du systme Conception prliminaire du logiciel Conception dtaille du logiciel Codage Tests unitaires du logiciel Intgration et tests dintgration Validation du logiciel Intgration matriel-logiciel production Validation du systme Maintenance du systme 23/23

Productions

Contrles

vente utilisation Entretien

Ch1.doc

28/04/04

Mthodes de conception statique

base contractuelle entre le demandeur et le ralisateur Prciser ce que doit faire le systme (le QUOI) // et non le COMMENT Les documents doivent permettre de justifier le projet matriser le dveloppement par des estimations et des planifications fournir un support de travail.

Ch1.doc

24/24

28/04/04

Mthodes de conception dynamique (maquettes)

Construire des maquettes jetables provisoires rapides avec peu de rigueur modlisant les cas gnraux ou les plus difficiles avec peu ou pas de protection ne respectant pas lensemble des normes permettant un dialogue plus efficace avec les utilisateurs vitant leffet tunnel
Ch1.doc

25/25

28/04/04

Mthodes de conception dynamique (2)

Construire des maquettes incrmentales

rigoureuses ds le dpart modlisant les cas gnraux puis les cas difficiles ou particuliers prparant la flexibilit mieux adaptes la maintenance Exemple : noyau dun langage, dun systme dexploitation

Ch1.doc

26/26

28/04/04

Spcification : Analyse et dfinition des besoins.

laide denqutes, dinterviews permet de dfinir un contrat entre les utilisateurs et les analystes vite de dvelopper un logiciel non adapt doit tre prpare avec beaucoup de soins.

Ch1.doc

27/27

28/04/04

Spcification : tude de faisabilit.

On tudie le domaine dapplication, ltat actuel de lenvironnement du futur systme, le rle, les ressources disponibles et requises, les contraintes dutilisation de performance etc. Activit en commun entre les experts du domaine, les futurs utilisateurs et lquipe de dveloppement. Les mthodes utilises relvent parfois plus des sciences cognitives ou sociologiques que de linformatique. Cette tape peut se poursuivre durant tout le cycle de vie.

Ch1.doc

28/28

28/04/04

Spcifications : tablissement du cahier des charges

description des diffrentes manires dutiliser un systme, dfinition des comportements requis du systme, (limitant ltendue du systme). Les objectifs de lutilisateur rsument les fonctions du systme en termes dutilisation que les utilisateurs, dcideurs et dveloppeurs peuvent apprhender et valider par rapport leur point de vue. on dit ce que lon veut sans dire comment. Pas encore de choix dimplmentation. Cette phase peut reprsenter jusqu 40% du dveloppement de lensemble du logiciel. 29/29

Ch1.doc

28/04/04

Productions : conception du systme et du logiciel :

Production dun modle du systme final

Enrichissement :
De la description du logiciel jusqu une description proche du programme proprement dit

Conception architecturale :
prcision de linterface et de la fonction de chaque composant.

Conception dtaille :
pour chaque composant, description des algos et de la reprsentation des donnes traites. Rem : la conception peut remettre en cause la spcification (pb de faisabilit)

Ch1.doc

30/30

28/04/04

Productions : ralisation (implantation) :

cest la programmation proprement dite. Elle est de plus en plus souvent automatise. Elle reprsente souvent moins de 20% du dveloppement. Elle comprend galement lactivit dintgration de lensemble des productions (mises jour des documents, modes demploi, annexes et des programmes dune manire homogne. Un systme denvironnement adapt peut grandement aider cette tche.

Ch1.doc

31/31

28/04/04

Contrles
Vrification de ladquation entre la description des besoins (cahier des charges) et les proprits du systme

Correction :
A-t-on crit le bon systme (rpondant lattente utilisateur et aux contraintes de lenvironnement ? Cest la validation qui rpond cette question.

Vrification :
sassurer que le logiciel satisfait la spcification globale. Les preuves sont tablies pour des spcifications dtailles, parties de programmes et sont contrls par des tests.
Ch1.doc

32/32

28/04/04

Les tests :
Les tests peuvent tre faits en statique (par examen ou analyse du code) en dynamique (en utilisant lexcution un sous ensemble de donnes).

Ch1.doc

33/33

28/04/04

Dtails des tests :

tests unitaires
(sur des modules spars)

les tests dintgration

(destins vrifier le comportement dun ensemble de composants)

les tests systmes

vrifiant lintgration du logiciel dans le futur site dexploitation en tenant compte des conditions oprationnelles, problmes de surcharge, de dfaillance, de versions etc.

Exploitation et maintenance.
volution du systme rparation des erreurs

Ch1.doc

34/34

28/04/04

Reprsentations des modles de dveloppement :

I. Exploratoire II. En cascade III. IV. En V En spirale

V. Incrmental

Ch1.doc

35/35

28/04/04

Exploratoire
Spcification informelle

Codage tests Mise au Point

Ch1.doc

36/36

28/04/04

En cascade :
Reprend lenchanement des tapes dcrites plus haut. Les flches symbolisent le principe itratif tout en conservant le principe quune modification dans une tape ne remet en cause que ltape prcdente. Analyse Spcification Programmation Tests

Ch1.doc

37/37

28/04/04

Schma dvelopp du modle en cascade

Faisabilit Analyse des besoins spcification / cahier des charges Conception du produit plan de tests Conception Dtaille documents de fonctionnement rsultats des tests Codage Intgration Installation Exploitation et maintenance

Ch1.doc

38/38

28/04/04

Analyse des besoins Faisabilit Spcifications

Schma du modle en V
Conformit/compltion/Correction

Installation et test du systme Acceptation

Conception Architecturale Conception Dtaille Programmation Codage

Intgration et tests Tests unitaires

Ch1.doc

39/39

28/04/04

Modle En V (2) :
Le principe de ce modle est qu'avec toute dcomposition doit tre dcrite la recomposition, et que toute description d'un composant est accompagne de tests qui permettront de s'assurer qu'il correspond sa description On retrouve lenchanement du modle en cascade. Les tapes de droite utilisent directement les rsultats des tapes de gauche et doivent tre raliss dans la foule. On insiste sur la partie test, ralis chaque tape, permettant de sassurer que le composant correspond la description. Par ailleurs on sassure de la recomposition (intgration) de chaque composant. obligation de concevoir les jeux de test et leurs rsultats ; rflexion et retour sur la description en cours ; meilleure prparation de la branche droite du V.

Ch1.doc

40/40

28/04/04

Phases, activits et production de documents

Phase Spcification selon le modle en V. Activit Documents Traduction des besoins en Entre : cahier des charges Sortie : fonctionnalits Dossier de Spcifications du interfaces Logiciel performances Manuels (installation/utilisation contraintes exigence qualit Entre : Dossier de Spcifications architecture globale : Sortie : dcoupage en modules Dossier de Conception Gnrale communication interDossier provisoire de module tests/validation change de donnes contrle (qui appelle qui) 41/41

Conception gnrale

Ch1.doc

28/04/04

Conception dtaille

Conception de chaque module et dcomposition en fonctions simples facilement testables Traduction des traitements en code Test de chaque composant

Codage

Tests unitaires

Entre : DCG Sortie : Dossier de Conception Dtaille Dossier provisoire de Tests Unitaires Entre : DCD Sortie : listings et dossier des tests unitaires Entre : DCD, DTU Sortie : listage des composants tests Dossier des Tests d'Intgration

Ch1.doc

42/42

28/04/04

Intgration

Assemblage progressif des composants

Validation

Test du logiciel complet en fonctionnement oprationnel, tests faits par le commanditaire Vrification et gestion des modifications dossier dfinitif de livraison

Entre : DCG, DTI Sortie : DTI complet listings des composants tests Dossier des Tests de Validation Entre : DSL, DTV, cahier des recettes Sortie : DTV complet, manuel d'utilisation et d'installation dossier de livraison

[M. Alissali 98]

Ch1.doc

43/43

28/04/04

En spirale :
Propos par B.Boehem en 88, gnralise les 2 prcdents. o Le quadrant 1 dtermine les objectifs du cycle, les alternatives, les contraintes en sappuyant sur les cycles prcdents, ou sur une analyse primaire. o Le quadrant 2 analyse les risques, value les alternatives, propose un maquettage. o Le quadrant 3 soccupe du dveloppement et de la vrification de la solution retenue en cours. o Le quadrant 4 passe en revue les rsultats du cycle prcdent et planifie le cycle suivant.

Ch1.doc

44/44

28/04/04

Ch1.doc

45/45

28/04/04

Modle incrmental :
Identification des incrments Spcification des incrments Codage des incrments Evaluation des incrments

Ch1.doc

46/46

28/04/04

Modle incrmental :
Un logiciel noyau est dabord dvelopp, puis des incrments sont dvelopps puis intgrs. Approche suivie pour de grands projets, permettant de mieux rpartir les efforts, traiter en parallle, de grer harmonieusement diffrentes comptences. Par contre ils sont plus sensibles aux modifications et aux problmes dintgration. Il ncessite une spcification rigoureuse et une bonne planification ainsi que la plus grande indpendance possible au niveau fonctionnel comme au niveau du calendrier.

Ch1.doc

47/47

28/04/04

Risques
Risques majeurs encourus lors du dveloppement dun logiciel : o Dfaillance de personnel o Irralisme du calendrier ou des budgets o Dveloppement inappropri o Produits trop luxueux o Volatilit (changements brusques avec de nombreuses rpercutions) o Composants manquants (tches externes, mesures, essais, analyses ) o Performances o Faisabilit (en rapport avec les techniques ou connaissances actuelles) o Formalisation excessive entranant une augmentation inopportune de documents points de dcision niveaux de dcisions ou de coordinations 48/48

Ch1.doc

28/04/04

Humeurs

Ch1.doc

49/49

28/04/04