Introduction au Génie Logiciel

BENTACHFINE Ilyas
E-mail : bentachfine.ilyas.profc@emsi-edu.ma
 MATÉRIEL ET LOGICIEL
• Systèmes informatiques
- 80 % de logiciel
- 20 % de matériel

• Depuis quelques années, la fabrication du matériel

est assurée par quelques fabricants seulement
- Le matériel est relativement fiable
- Le marché est standardisé

Les problèmes liés à l'informatique sont

essentiellement des problèmes de logiciel

2
 LA CRISE DU LOGICIEL
• Étude sur 8380 projets (Standish Group, 1995) :
- Succès : 16 %

- Problématique : 53 %
- Dépassement du budget : Difficulté de maîtrise des coûts
(200 millions de dollars pour fabriquer OS-360)
-défaut de fonctionnalités : Perte de la première sonde Mariner
vers Venus suite à une erreur de programmation dans un
programme Fortran
- délais non respectés : 2 ans de retard pour les premiers
compilateurs PL/1, Algol 68, ADA

- Échec : 31 % (abandonné)
-Abandon du projet d’informatisation de la bourse
londonienne après 4 ans de travail et 100 M£ de pertes

3
 LA CRISE DU LOGICIEL
• Rapport au congrès Américain sur les logiciels

Le taux de succès décroît avec la taille des projets

et la taille des entreprises
4
 SOLUTION
• En octobre 1968 lors d’une conférence de l’OTAN à
Garmisch-Partenkirchen en Allemagne

•Génie Logiciel
(Software Engineering) :
- Comment faire des
logiciels de qualité ?
-Qu'attend-on d'un
logiciel ?
-Quels sont les critères de
qualité ?

5
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL
• Utilité :
- Adéquation entre le logiciel et les besoins des utilisateurs
- Emphase sur l'analyse des besoins, Améliorer la
communication (langage commun, démarche
participative) , Travailler avec rigueur

• Utilisabilité :
-Facilité d'apprentissage et d’utilisation : Comprendre ce
que l'on peut faire avec le logiciel, et savoir comment le
faire
- Analyse du mode opératoire des utilisateurs
- Adapter l'ergonomie des logiciels aux utilisateurs

6
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL

• Fiabilité :
-Logiciel est conforme à ses spécifications (les résultats
sont ceux attendus) et fonctionne raisonnablement en
toutes circonstances.
-Utiliser des méthodes formelles, des langages et des
méthodes de programmation de haut niveau
- Vérifications, tests
- Progiciels

7
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL
• Interopérabilité :
- Interactions en synergie avec d'autres logiciels
- Découplage données/traitements (SGBD),
-Standardisation des formats de fichiers (XML...) et des
protocoles de communication (CORBA...),

• Performance
- Les logiciels doivent satisfaire aux contraintes de temps
d'exécution
- Logiciels plus simples, veiller à la complexité des
algorithmes, machines plus performantes

8
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL
• Portabilité
-Un même logiciel doit pouvoir fonctionner sur plusieurs
machines
-Rendre le logiciel indépendant de son environnement
d'exécution

• Réutilisabilité
-On peut espérer des gains considérables car dans la
plupart des logiciels : 80 % du code se retrouve à peu près
partout et 20 % du code est spécifique
-Abstraction, généricité, construire un logiciel à partir
de composants prêts à l'emploi, Design Patterns

9
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL
• Facilité de maintenance :
- Un logiciel ne s'use pas
- La maintenance absorbe une très grosse partie des efforts
de développement

10
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL
• Maintenance corrective
-Corriger les erreurs : défauts d'utilité, d'utilisabilité, de
fiabilité
- Identifier la défaillance, le fonctionnement
- Localiser la partie du code responsable
- Corriger et estimer l'impact d'une modification

• Maintenance adaptative
- Ajuster le logiciel pour qu'il continue a remplir son rôle
compte tenu du l‘évolution des :
- Environnements d'exécution,
- Fonctions à satisfaire, Conditions d'utilisation,..
- Ex : changement de SGBD, de machine, de TVA, …
11
 CRITÈRES DE QUALITÉ D'UN
LOGICIEL

• Maintenance perfective, d'extension

- Accroître/améliorer les possibilités du logiciel
- Donne lieu à de nouvelles versions
- Ex : les services offerts, l'interface utilisateur, les
performances...

12
 CYCLE DE VIE DU LOGICIEL

Pour obtenir un logiciel de qualité, il faut en

maîtriser le processus d'élaboration
- La vie d'un logiciel est composée de différentes étapes

- La succession de ces étapes forme le cycle de vie du

logiciel

- Il faut contrôler la succession de ces différentes étapes

13
 CYCLE DE VIE DU LOGICIEL

• Analyse des besoins et des risques (Étude de

faisabilité) :

Déterminer si le développement propose vaut la pein d‘être

mis en œuvre, compte tenu des attentes et de la difficulté
de développement

• Etude de marché : déterminer s'il existe un marché

potentiel pour le produit

14
 CYCLE DE VIE DU LOGICIEL

• Spécification (conception générale) : Déterminer les

fonctionnalités du logiciel, déterminer l'architecture
générale

-Collecte des exigences : obtenir de l'utilisateur ses

exigences pour le logiciel

-Analyse du domaine : déterminer les tâches et les

structures répétitives dans le problème

15
 CYCLE DE VIE DU LOGICIEL

• Conception : Déterminer la façon dont le logiciel fournit

les différentes fonctionnalités recherchées

- Conception générale
§ 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ème

16
 CYCLE DE VIE DU LOGICIEL

• Codage : Traduction du modèle dans un langage de

programmation

- Ecrire le logiciel : l’implémentation du logiciel

17
 CYCLE DE VIE DU LOGICIEL

• Tests : Essayer le logiciel sur des données d'exemple pour

s'assurer qu'il fonctionne correctement

-Tests unitaires : faire tester les parties du logiciel par

leurs développeurs

- Tests d'intégration : tester pendant l'intégration

- Tests de validation : pour acceptation par l'acheteur

18
 CYCLE DE VIE DU LOGICIEL

• 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

19
 CYCLE DE VIE DU LOGICIEL

• Maintenance : Mettre à jour et améliorer le logiciel pour

assurer sa pérennité
- limiter le temps et les coûts de maintenance,

- porter les efforts sur les étapes antérieures

20
 DOCUMENTS PRODUITS DANS
LE CYCLE DE VIE
• Cahier des charges : Description initiale des
fonctionnalités désirées, généralement écrite par
l'utilisateur

• Calendrier du projet : Ordre des différentes tâches et

les détails et les ressources qu'elles demandent

• Plan de test du logiciel : Décrit les procédures de tests

appliquées au logiciel pour contrôler son bon
fonctionnement , et les tests de validation choisis par le
client pour déterminer s'il peut accepter le logiciel

21
 DOCUMENTS PRODUITS DANS
LE CYCLE DE VIE
• Plan d'assurance qualité : 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 finale

• 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

22
 DOCUMENTS PRODUITS DANS
LE CYCLE DE VIE
Document Phase de production
Manuel utilisateur final Implémentation
Conception architecturale Conception
Plan d'assurance qualité Planification
Code source implémentation
Cahier des charges Faisabilité
Manuel utilisateur préliminaire Spécification
Conception détaillée Conception
Estimation des coûts Planification
Calendrier du projet Planification
Rapport des tests Tests
Documentation Implémentation

23
 MODÈLES DE CYCLE DE VIE

• Modèles linéaires
- cascade
- modèle en V
- ...

• Modèles non linéaires

- prototypage
- modèles incrémentaux
- modèle en spirale
- ...

24
 MODÈLES DE CYCLE DE VIE
• Modèle Cascade : le développement logiciel est considéré
comme une succession d’étapes réalisées de façon
strictement séquentielle

25
 MODÈLES DE CYCLE DE VIE

• Modèle Cascade

- Chaque étape correspond à une activité de

base
- Chaque étape est validée

- Il n’y a pas (ou peu) de retours en arrière

- Adapté pour des projets de petite taille, et

don’t le domaine est bien maîtrisé

26
 MODÈLES DE CYCLE DE VIE
• Modèle V
- Force la documentation : une phase ne peut se terminer
avant qu’un document soit validé
- Les tests sont définis à l’issue de chaque phase

27
 MODÈLES DE CYCLE DE VIE
• Modèle V
- Simple et facile à comprendre
- Populaire et utilisé dans d’autres disciplines
- Les progrès sont tangibles (pour l’équipe de
développement)
- Conditions d’utilisation : les exigences sont bien connues
et non sujettes à modification
§ Fonctionnalités / Attentes utilisateurs
§ Technologies utilisées

- Adapté pour des projets dont le domaine est bien maîtrisé

28
 MODÈLES DE CYCLE DE VIE
• Prototypage
- Construire un prototype jetable pour mieux comprendre
les points durs (exigences, technologies)

29
 MODÈLES DE CYCLE DE VIE

• Prototypage
- Version d'essai du logiciel
- Tester les différents concepts et exigences
- Montrer aux clients les fonctions que l'on veut mettre en œuvre
- Impliquer l’utilisateur et éclaircir les zones troubles
- Les efforts consacrés au développement d'un prototype sont le
plus souvent récompensés par ceux gagnés à ne pas développer
de fonctions inutiles
- Le développement suit souvent un cycle de vie linéaire, lorsque
le client donne son accord

30
 MODÈLES DE CYCLE DE VIE
• Modèle incrémental
- Concevoir et livrer au client un
sous-ensemble minimal et
fonctionnel du système

-Procéder par ajouts d'incréments

minimaux jusqu‘à la fin du
processus de développement

-La première version constitue le

noyau, les versions suivantes
s’appuient sur l’existant et
étendent le système

31
 MODÈLES DE CYCLE DE VIE
• Modèle incrémental
- Diviser le projet en incréments
-Un incrément = une sous partie fonctionnelle cohérente
du produit final
- Chaque incrément ajoute de nouvelles fonctions
- Chaque incrément est testé comme un produit final
- Les incréments sont définis à priori (classification des
exigences – par le client si possible)
- Meilleure intégration du client dans la boucle, produit
conforme à ses attentes

32
 MODÈLES DE CYCLE DE VIE
• Modèle en spirale (Boehm, 1988)
- Le cycle de vie est représenté à l’aide d’une spirale
- Chaque boucle représente une phase du développement
-La boucle la plus interne traite les premières phases
(faisabilité). La plus externe traite de la livraison

33
 MODÈLES DE CYCLE DE VIE

• Modèle en spirale (Boehm, 1988)

- Chaque boucle traverse quatre sections :
§ Définition des objectifs de la phase (la boucle)
§ Evaluation des risques et plan de gestion
§ Développement et validation
§ Planification de la phase suivante

- Nombre de cycles variable

- Meilleure maîtrise des risques, mais nécessite une (très)

grande expérience

34
 MODÉLISATION
• un modèle est une abstraction permettant de
mieux comprendre un objet complexe (bâtiment,
économie, atmosphère, cellule, logiciel, …)

35
 MODÉLISATION
• Un modèle est une représentation abstraite de la
réalité qui exclut certains détails du monde réel
- Il permet de réduire la complexité d'un phénomène en
éliminant les détails qui n'influencent pas son
comportement de manière significative

- Il reflète ce que le concepteur croit important pour la

compréhension et la prédiction du phénomène
modélisé, les limites du phénomène modélisé
dépendent des objectifs du modèle

- Un petit dessin vaut mieux qu'un long discours. Les

modèles sont donc souvent graphiques, même si l'objet
a créer n'est pas matériel

36
 MODÉLISATION
• Modélisation des processus logiciels
- Les modèles en V, spirale... sont des archétypes de
modèles : On peut les adapter à des projets particuliers
-On peut vouloir représenter le processus de
développement (et ses parties) de manière plus fine :
limiter les risques d'ambiguïté

-Il est nécessaire de se doter d'un formalisme pour

représenter le processus de développement
§ Pour ordonner les tâches
§ Pour déterminer les échanges d'information entre les
différentes tâches
§ Pour permettre aux jeunes recrues de mieux travailler

37
 MODÉLISATION
• Modélisation des processus logiciels
- Un modèle de processus logiciels décrit
§ Les tâches
§ Les artefacts (fichiers, documents, données, ...)
§ Les auteurs
§ Les décisions (facultatif)

- Règles à observer
§ Deux tâches doivent être séparées par un artefact
§ Une tâche ne peut être exécutée tant que ses artefacts d'entrée
n'existent pas
§ Il doit y avoir au moins une tâche de début et une de fin
§ Il doit y avoir un trajet depuis chaque tâche jusqu‘à la tâche de
fin

38
 MODÉLISATION
• Modélisation des processus logiciels
Exemple 1 : Modèle pour la consommation de tartines

Exemple 2 : Modèle de processus pour cuisiner du pain

39
 MODÉLISATION
• Modélisation en informatique
- la construction d'un système d'information, d'un réseau,
d'un logiciel complexe, de taille importante et par de
nombreuses personnes oblige à modéliser

• Modèle d'un système informatique sert :

- de document d'échange entre les clients et les
développeurs
- d'outil de conception
- de référence pour le développement
- de référence pour la maintenance et l'évolution

40
 MODÉLISATION
• Modélisation en ingénierie logicielle

- Langage de modélisation : une syntaxe commune,

graphique, pour modéliser (OMT, UML, …)

- Méthode de modélisation : procédé permettant de

construire un modèle aussi correct que possible et aussi
efficacement que possible (MERISE, UP, …)

- Ateliers Génie Logiciel (AGL) : primordial pour

l'utilisabilité en pratique des langages de modélisation.

41
 MODÉLISATION
• Modélisation par décomposition fonctionnelle

Décomposer la fonction globale jusqu'à obtenir des

fonctions simples à appréhender et donc à
programmer (approche descendante).

C'est la fonction qui donne la forme du système

42
 MODÉLISATION
• Modélisation orientée objets

- Des architectures logicielles fondées sur les

objets du système, plutôt que sur une
décomposition fonctionnelles
- On peut partir des objets du domaine (briques
de base) et remonter vers le système global
(approche ascendante)

C'est la structure du système lui donne sa forme

43