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’
 Cettecrise 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,

 non différenciation entre avion civil et avion militaire : guerre du Golfe -

Airbus iranien abattu : 280 morts

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
bourse de Londres (projet d’informatisation)

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

 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.

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
 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.

13
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
 14
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.
15
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.
16
17
 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
18
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

19
efficacité / performance

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

portabilité

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

20
 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).

21
 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 regrouper 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.

22
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,

23
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

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

25
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

26
Conception:

Objectifs : É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
27
 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

28
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

29
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

30
Faisabilité.
Spécifications.
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.
Conception
Implémentation
 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.

31
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.

32
Maintenance:
Mettre à jour et améliorer le logiciel pour assurer sa pérennité .

33
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 peut accepter le
logiciel.
34
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.

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

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

 modèle en spirale (Boehm, 1988)

36
Modèle en cascade

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

38
Modèle en V

39
 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é
40
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.

41
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.

42
Modèle en spirale

43
 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
44
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é

45
 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.

46