Un logiciel (software) est l’ensemble des programmes,

des procédures et des documentations nécessaires au

fonctionnement d’un système informatique

1
 le logiciel est facile à reproduire
 tout le coût se trouve dans le développement

 le logiciel est immatériel et invisible

 on ne peut l’observer qu’en l’utilisant
 la qualité n’est pas vraiment apparente
 difficile d’estimer l’effort de développement

 développement difficile à automatiser

 beaucoup de main-d’œuvre nécessaire …

2
 le logiciel ne s’use pas, mais il vieillit

Détérioration suite aux changements :

 complexification indue
 duplication de code
 introduction d’erreurs

Mal conçu au départ :

 inflexibilité
 manque de modularité
 documentation insuffisante

Evolution du matériel

3
 sur mesure : pour un client spécifique

 générique : vendu sur un marché

4
 système d’information et d’aide à la décision

 logiciel temps-réel

 logiciel embarqué

 logiciel distribué

5
 Le GL est apparu dans les années 70 pour répondre à la ‘crise du
logiciel’
 Cette crise est apparue lorsque l’on a pris conscience que le coût
du logiciel dépassait le coût du matériel.
 la non qualité des systèmes produits:

 arrêt de Transpac pour 7.000 entreprises et 1.000.000 d'abonnés : surcharge

du réseau.

 TAURUS, un projet d'informatisation de la bourse londonienne :

définitivement
abandonné après 4 années de travail et 100 millions de £ de pertes,

 mission VENUS : passage à 500.000 km au lieu de 5.000 km à cause du

remplacement d'une virgule par un point,

 avion C17 de McDonnell Douglas livré avec un dépassement de 500 millions 6

Délais et exigences non satisfait

OS 360 d’IBM
en retard, dépassement mémoire et prix, erreurs

aéroport de Denver (système de livraison des bagages)

1 an de retard

SNCF (système socrate)

 difficultés importantes

7
abandon
EDF (contrôle-commande centrales 1400 MWatts)

renonce après plusieurs années d’efforts

bourse de Londres (projet d’informatisation)

abandon : 4 années de travail + 100 ML perdus

Etats unis (système de trafic aérien)

 abandon
 La non rencontre des exigences et les dépassements de
délais sont fréquents : 300 à 400 %
8
 L'absence d’un cadre méthodologique standard de développement. Les méthodes de
développement de logiciel existantes, si elles sont utilisées,n'étaient pas suffisamment
bonnes et adaptées.

9
 L'absence d'outils de gestion du développement. Les méthodes
d'estimation des coûts et des délais sont inexistantes, les
techniques de planification et de suivi de projets n'étaient pas
utilisées.
 L'absence de métrologie de la qualité des processus et des
produits logiciels. Il n'y avait pas de moyens pour mesurer la
qualité d'un logiciel telles que la fiabilité et aussi la qualité de la
démarche méthodologique utilisée.

Remarque:
la crise du logiciel persiste toujours, on parle ainsi de maladie chronique. Cette
persistance est dû principalement à la complexité croissante et à la maintenance
toujours difficile et coûteuse du logiciel.
10
Naissance d’une nouvelle discipline
 Problématique apparue dès les années 1960
 Conférence parrainée par l’OTAN (1968)
 Naissance du « Génie Logiciel » (software engineering)

11
Objectif

 Démarche de développement ingénierique

 Principes, méthodes, outils
 Techniques de fabrication assurant :

 respect des exigences

 respect de la qualité
 respect des délais et des coûts

12
Introduction d’une discipline appelée « génie logiciel » qui a pour
but de rationaliser l'activité de construction de logiciels.

le génie logiciel considère la construction de logiciels comme un

procédé industriel qui:
 Se base sur les principes d’ingénierie: utilisation de schémas, modèles, lois
mathématiques pour décrire et représenter le logiciel

 Prend en compte, dans l’étude globale, les aspects techniques, économiques,

financières et sociaux.

 Utilise des outils logiciels pour accompagner les différents activités du

procédé.
13
 Le Génie Logiciel est né, sous le nom anglais de software
engineering, en octobre1968 à Garmisch-Partenkirchen lors d'un
colloque parrainé par l'OTAN.
 Le Génie Logiciel a été défini, lors de ce colloque, par un groupe
de scientifiques pour répondre à un problème qui devenait de plus
en plus évident. Ce problème s'énonçait en deux constatations:
 le logiciel n'était pas fiable

 il était incroyablement difficile de réaliser dans des délais prévus des

logiciels satisfaisant leurs cahiers des charges.

14
 Le Génie Logiciel considère donc le logiciel comme un objet
manufacturé complexe, dont le développement nécessite la mise
en œuvre de techniques de fabrication justifiées soit par la théorie,
soit par la pratique.
 Le Génie Logiciel est donc l'art de spécifier, de concevoir, de
réaliser et de faire évoluer, avec des moyens et dans des délais
raisonnables, des programmes, des documentations et des
procédures de qualité en vue d'utiliser un ordinateur pour résoudre
certains problèmes définis.

15
Facteurs de qualité:
 Correction:
La correction est la capacité que possède un produit logiciel de
mener à bien sa tâche, telle qu’elle a été définie par sa
spécification
 Robustesse:
La robustesse est la capacité qu’offrent des systèmes logiciels à
réagir de manière appropriée à la présence de conditions
anormales.
 Extensibilité:
L’extensibilité est la facilité d’adaptation des produits logiciels
aux changements de Spécifications 16
Réutilisabilité:
La réutilisabilité est la capacité des éléments logiciels à servir à
la construction de plusieurs applications différentes
 Compatibilité:
La compatibilité est la facilité avec laquelle des éléments
logiciels peuvent être combinés à d’autres.
 Efficacité:
L’efficacité est la capacité d’un système logiciel à utiliser le
minimum de ressources matérielles, que ce soit le temps
machine, l’espace occupé en mémoire externe et interne, ou la
bande passante des moyens de communication.
17
Portabilité:
La portabilité est la facilité avec laquelle des produits logiciels
peuvent être transférés d’un environnement logiciel ou matériel à
l’autre.
 Facilité d’utilisation:
La facilité d’utilisation est la facilité avec laquelle des personnes
présentant des formations et des compétences différentes peuvent
apprendre à utiliser les produits logiciels et s’en servir pour
résoudre des problèmes. Elle recouvre également la facilité
d’installation, d’opération et de contrôle.
Ponctualité:
La ponctualité est la capacité d’un système logiciel à être livré au
moment désiré par ses utilisateurs, ou avant.
18
 la Rigueur: c'est un principe qui constitue le chemin vers la formalité. Il s’appuie sur des
notations, des modèles, des schémas et des lois mathématiques.

 la Séparation : c’est une règle de bons sens qui consiste à considérer séparément
différents aspects d’un problème afin d’en maîtriser la complexité. C’est un aspect de la
stratégie générale du « diviser pour régner ». Elle prend une multitude de formes :

•Séparation dans le temps (les différents aspects sont abordés

successivement),Cas du cycle de vie.
•Séparation du système en parties (architecture).

 la Modularité: c'est le principe qui consiste à découper le logiciel en plusieurs modules

simples. Ce principe considère séparément le contenu du module et les relations entre
modules (ce qui rejoint l’idée de séparation des questions). Un bon découpage modulaire se
caractérise par une forte cohésion interne des modules et un faible couplage entre les
modules (relations inter modulaires en nombre limité et clairement décrites).

19
 Généricité : c'est le principe qui permet de ramener la résolution
d'un problème à celle d'un problème plus général. Il s'agit de
regroupe les entités semblables (structure ou comportement) par des
solutions paramétrables ou adaptables. C'est le cas des applications
paramétrables.
 la Construction incrémental: c'est un principe qui consiste à
procéder progressivement dans la construction d’un produit logiciel.
C'est à dire aller de l’essentiel vers le secondaire, cela revient à
construire un noyau avec les fonctions essentiels, puis ajouter
progressivement les fonctions secondaires.

20
21
 Qualité externe:
complétude fonctionnelle

 réalise toutes les tâches attendues

ergonomie / convivialité

 facile d’utilisation
 apprentissage aisé

fiabilité / robustesse

 tâches effectuées sans problème

 fonctionne même dans des cas atypiques
22
Qualité interne:
 adaptabilité

 facile à modifier, à faire évoluer

réutilisabilité

 des parties peuvent être réutilisées facilement

traçabilité / compréhension

 le fonctionnement du logiciel est facile à comprendre

23
efficacité / performance

 bonne utilisation des ressources (mémoire, cpu, …)

portabilité

 capacité à marcher dans un autre contexte ou env.

24
Ensemble d'activités successives, organisées en vue de la production
d'un logiciel
En pratique:
•Pas de processus idéal

•Choix du processus en fonction des contraintes (taille des

équipes, temps, qualité...).

•Adaptation de « processus types » aux besoins réels

25
Activités du développement logiciel

•Analyse des besoins

•Spécification
•Conception
•Programmation
•Validation et vérification
•Livraison
•Maintenance

Pour chaque activité : Utilisation et production de documents

26
 Analyse des besoin:

Objectif : Comprendre les besoins du client

•Objectifs généraux, environnement du futur système, ressources

disponibles, contraintes de performance...

Entrée : Fournies par le client

•Expert du domaine d'application, futur utilisateur

Document produit : Cahier des charges (+ manuel d'utilisation préliminaire)

27
Spécifications

Objectifs
•Établir une description claire de ce que doit faire le logiciel
(fonctionnalités détaillées, exigences de qualité, interface...)

•Clarifier le cahier des charges (ambiguïtés, contradictions)

Entrée : Cahier des charges + considérations de faisabilité ?

Document produit : Cahier des charges fonctionnel

28
Conception:

Objectif : Élaborer
une solution concrète réalisant la spécification
• Description architecturale en composants (avec interface et
fonctionnalités)
• Réalisation des fonctionnalités par les composants (algorithmes,
organisation des données)
• Réalisation des exigences non-fonctionnelles (performance,
sécurité...)
Entrée : Cahier des charges fonctionnel
Document produit : Dossier de conception

29
 programmation

Objectif : Implantation de la solution conçue

•Choix de l'environnement de développement, du/des langage(s)

de programmation, de normes de développement...

Entrée : Dossier de conception

Document produit : Code documenté + manuel d'utilisation

30
Validation et vérification

Objectifs :

•Validation : assurer que les besoins du client sont satisfaits (au

niveau de la spécification, du produit fini...)

•Vérification : assurer que le logiciel satisfait sa spécification

31
Maintenance:
Types de maintenance:

•Correction : identifier et corriger des erreurs trouvées après la

livraison.

•Adaptation : adapter le logiciel aux changements dans

l'environnement (format des données, environnement d'exécution...)

•Perfection : améliorer la performance, ajouter des fonctionnalités,

améliorer la maintenabilité du logiciel

32
Faisabilité:
Déterminer si le développement proposé vaut la peine d’etre mise en œuvre.
étude de marché: déterminer s’il existe un marché potentiel pour le produit.
Spécifications:
déterminer les fonctionnalités que doit posséder le logiciel.
collecte des exigences: obtenir de l’utilisateurs ses exigences pour le logiciel.
analyse du domaine: déterminer les taches et les structures qui se répètent dans le
problème.
Organisation du projet:

déterminer la manière dont développer le logiciel.

analyse des couts: établir une estimation du prix du projet.
planification: établir un calendrier pour le développement.

Assurance qualité du logiciel: déterminer les actions qui permettront de s’assurer de

la qualité du produit fini.
33
Conception:
Déterminer la façon dont le logiciel fournit les différentes fonctionnalités
recherchées:
Conception architecturale: déterminer la structure du système.
Conception des interfaces: déterminer la façon dont les différentes parties du système
agissent entre elles.
Conception détaillée: déterminer les algorithmes pour les différentes parties du systèmes
Implémentation:
écrire le logiciel.
Essayer le logiciel sur des données d’exemple pour s’asssurer qu’il fonctionne
correctement.
 Tests unitaires: faire tester le logiciel par ses développeurs
 Test d’intégration: tester pendant l’intégration du logiciel
 Tests système: tester le logiciel dans un environnement similaire à l’environnement
de production.
34
Tests alpha: faire tester le logiciel par le client sur le site de
développement.
Tests beta :faire tester le logiciel par le client sur son propre site
Tests d’acceptation : faire tester le produit par l’acheteur pour savoir
s’il le satisfait.
Tests de régression : enregistrer les résultats des tests et les comparer
avec ceux des anciennes versions pour déterminer si la nouvelle n’a pas
apporté de dégradation des performances.
Livraison:
Fournir au client une solution logicielle qui fonctionne correctement.
Installation: rendre le logiciel opérationnel sur le site du client.
Formation: enseigner aux utilisateurs à se servir du logiciel.
Assistance : répondre aux questions des utilisateurs.
35
Maintenance:
Mettre à jour et améliorer le logiciel pour assurer sa pérennité .

36
Cahier des charges:
Description initiale des fonctionnalités désirées, généralement écrite
par l’utilisateur.
Spécifications:
Décrit précisément les conditions que doit remplir le logiciel.
Modèle objet: indique les classes et objets principaux.
Scénarios des cas d’utilisation : indique les différents enchainements
possible du point de vue de l’utilisateur.
Calendrier du projet:
Décrit l’ordre des différentes taches ainsi que les délais et les
ressources qu’elles demandent.
Plan de test du logiciel:
Décrit les procédures de test appliquées au logiciel pour assurer son
bon fonctionnement.
Test d’acceptation : tests choisis par le client pour déterminer s’il 37
Conception du logiciel:
Décrit la structure du logiciel.
Conception architecturale: décrit la structure de haut niveau .
Conception détaillée : décrit la conception des modules de bas niveau et des objets
Plan d’assurances qualité du logiciel:
Décrit les activités mises en œuvre pour garantir la qualité du logiciel.
Manuel utilisateur:
Mode d’emploi pour le logiciel dans sa version finale.
Code source:
Code complet du produit fini

Rapport des tests:

Décrit les tests effectués et les réactions du système.

Rapport des défauts

Décrit les comportements du système qui n’ont pas satisfait le client , il s’agit le plus
souvent de défaillances du logiciel ou d’erreurs.

38
 modèle en cascade (fin des années 1960)

 modèle en V (années 1980)

 modèle en spirale (Boehm, 1988)

39
Modèle en cascade

40
 Modèle en cascade:

 principe : le développement se divise en étapes

 une étape se termine à une certaine date

 des docs ou prog. sont produits à la fin de chaque étape
 on passe à l’étape suivante ssi l’examen est satisfaisant
 une étape ne remet en cause que la précédente

 remarque :

 modèle séduisant car simple

 moyennement réaliste (trop séquentiel)

41
Modèle en V

42
 Modèle en V

 principe : les premières étapes préparent les dernières

 interprétation : 2 sortes de dépendances entre étapes

 en V, enchaînement séquentiel (modèle en cascade)

 de gauche à droite, les résultats des étapes de départ
sont utilisés par les étapes d’arrivée
 remarque :
 vérification objective des spécifications
 modèle plus élaboré et réaliste
 éprouvé pour de grands projets, le plus utilisé
43
Le prototypage:

 Ce modèle consiste à produire une version d’essai du logiciel (un

prototype).
 ce prototype est utilisé pour tester les différents concepts et
exigences.
 il sert à montrer aux clients les fonctionnements que l’on se
propose de mettre en œuvre.
 après que le client a donné son accord, le développement du
logiciel suit généralement les phases du modèle en cascade.
 les efforts consacrés à la réalisation du prototype sont le plus
souvent compensés par ceux gagnés à ne pas développer de
fonctions inutiles. 44
Le modèle incrémental:

 Son principe est de concevoir et de livrer au client un sous-

ensemble minimal du système global qui soit fonctionnel.
 le processus se répète durant l’ensemble du cycle de vie par
l’ajout d’incréments minimaux.
 ce système présente l’avantage de fournir rapidement au client
un système utilisable.

45
Modèle en spirale

46
 principe : développement itératif (prototypes)

 interprétation : chaque mini-cycle se déroule en 4 phases

1. Analyse des besoins, Spécification

2. Analyse des risques, Alternatives, Maquettage
3. Conception et Implémentation de la solution retenue
4. Vérification, Validation, Planification du cycle suivant
 commentaire :

 nouveau : analyse de risques, maquettes, prototypage

 modèle complet, complexe et général
 effort important de mise en œuvre
 utilisé pour projets innovants ou à risques
47
résumé
 modèles : enchaînements et interactions entre étapes

 passage d’une étape à la suivante :

 documents, tests
 vérifiés et validés

 3 modèles : cascade, V, spirale (séquentiels et itératif)

 cascade : simple mais pas très réaliste

 spirale : nouvelles notions, très complet mais lourd

 V : assez réaliste, le plus éprouvé et utilisé

48
 En quoi un modèle de cycle de vie divisé en phase aide-t-à la gestion du
développement d’un projet logiciel?

Quelles sont les deux caractéristiques obligatoires d’un jalons?

Indiquez la ou les phases du cycle de vie d’un logiciel où est produit chacun des
documents suivants: manuel utilisateur final, conception architecturale, plan d’assurance
qualité,spécifications des modules,code source,cahier de charges,plan de test,manuel
utilisateur préliminaire,conception détaillée,estimation des couts,calendrier du
projet,rapport des tests,documentation.

Classez les taches suivantes selon le modèle en cascade:tests d’acceptation,organisation

du projet,test unitaires,synthèse des éxigences,estimation des couts,conception de haut
niveau,étude de marché,conception de bas niveau,test système,synthèse sur la
conception,iplémentation,spécification des exigences.

49