IGL115 : INITIATION AU GENIE LOGICIEL

INTRODUCTION AU GENIE LOGICIEL

Filière : GENIE INFORMATIQUE

Spécialité : GENIE LOGICIEL II

Enseignant : M. GHOMSI GHOMSI Emmanuel

Année académique 2020 - 2021

CHAPITRE 1. Définitions et principes de bases

I. Définitions
Le Génie Logiciel (anglais software engineering) est une science de génie industriel qui étudie les
méthodes de travail et les bonnes pratiques des ingénieurs qui développent des logiciels.

C’est l'ensemble des activités de conception et de mise en œuvre des produits et des procédures
tendant à rationaliser la production du logiciel et son suivi.

Le logiciel est un objet immatériel, très malléable au sens de facile à modifier.

Ses caractéristiques attendues sont difficiles à figer au départ et souvent remises en cause en cours
de développement. Les défaillances et erreurs ne proviennent ni de défauts dans les matériaux ni de
phénomènes d’usure dont on connaît les lois mais d’erreurs humaines, inhérentes à l’activité de
développement.

Le logiciel ne s’use pas, il devient obsolète.

II. Principes de bases

Carlo Ghezzi liste sept principes fondamentaux :

❖ Rigueur
❖ Séparation des problèmes
❖ Modularité
❖ Abstraction
❖ Anticipation du changement
❖ Généricité
❖ Construction incrémentale

1. Rigueur
La production de logiciel est une activité créative, mais qui doit se conduire avec une certaine rigueur.
Le niveau maximum de rigueur est la formalité (c’est à dire le cas où les descriptions et les validations
s’appuient sur des notations et lois mathématiques).
 2. Séparation des problèmes
Stratégie générale du « diviser pour régner » :

❖ Séparation dans le temps avec la notion de cycle de vie du logiciel.

❖ Séparation des qualités que l’on cherche à optimiser à un stade donné.
❖ Séparation des vues que l’on peut avoir d’un système.
❖ Séparation du système en parties.

Exemple : Comment créer dynamiquement une page Internet pour visualiser et modifier le contenu
d’une BDD sans la corrompre ?

Solution : Décomposition en trois composants :

❖ Modèle : son rôle est de gérer le stockage des données

❖ Vue : son rôle est de formater les données.
❖ Contrôleur : son rôle est de n’autoriser que les modifications correctes.

3. Modularité
Un système est modulaire s’il est composé de sous-systèmes plus simples, ou modules.

La modularité permet de considérer séparément le contenu du module et les relations entre

modules. Elle facilite la réutilisation de composants.

Un bon découpage modulaire se caractérise par :

❖ Une forte cohésion interne des modules

❖ Un faible couplage entre les modules

4. Abstraction
L’abstraction consiste à ne considérer que les aspects jugés importants d’un système à un moment
donné, en faisant abstraction des autres aspects. L’abstraction permet une meilleure maîtrise de la
complexité.

5. Anticipation du changement
La caractéristique essentielle du logiciel, par rapport à d’autres produits, est qu’il est presque
toujours soumis à des changements continuels :
 ❖ Corrections d'imperfections
❖ Evolutions en fonctions des besoins

Il faut par exemple :

❖ Faire en sorte que les changements soient les plus localisés possibles (bonne modularité)
❖ Être capable de gérer les multiples versions des modules et configurations des versions.

6. Généricité
Il est parfois avantageux de remplacer la résolution d’un problème spécifique par la résolution d’un
problème plus général. Cette solution générique (paramétrable ou adaptable) pourra être réutilisée
plus facilement.

Exemple : cas d’une Template web : plutôt que de définir un style spécifique pour un moyen de
visualisation particulier, écrire (ou réutiliser) une feuille de styles.

7. Construction incrémentale
Un procédé incrémental atteint son but par étapes en s’en approchant de plus en plus. Chaque
résultat est construit en étendant le précédent.

Par exemple :

❖ Réaliser d’abord un noyau des fonctions essentielles et ajouter progressivement les aspects
plus secondaires.
❖ Construire une série de prototypes simulant plus ou moins complètement le système
envisagé
Chapitre 2. Processus et Cycles de vie
Le cycle de vie d'un logiciel désigne l'ensemble des étapes de développement d'un logiciel, du début
de son développement jusqu'à la fin de vie. Ces étapes incluent également les potentielles mises à
jour du logiciel, une fois une version publiée.

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.

I. Terminologie
1. Les acteurs dans la vie du logiciel
❖ Maître d’ouvrage (MO) : il commande le logiciel et assure la relation entre les usagers et les
développeurs. Communément appelé les Utilisateurs.
❖ Maître d’œuvre (ME) : responsable du suivi et développement logiciel. Communément
appelé les Programmeurs.

2. Projet
Ensemble d’activités organisées permettant de créer un produit ou un service avec une qualité
définie dans le cadre d’un budget fixé.

3. Processus
Savoir-faire associé à une discipline. Un processus est un ensemble structuré :

❖ D’acteurs
❖ D’activités pour chaque acteur (code, planification, …)
❖ D’artefacts pour chaque activité (exécutable, planning…)
❖ De workflows (un workflow = un ensemble d’activités)

Un processus peut lui-même englober des sous-processus

II. Processus de développement de logiciel
1. Présentation
Permet d’assurer le cycle de vie du logiciel depuis sa création jusqu’à son retrait en passant par sa
distribution sur un marché.

Ensemble séquentiel de phases : déterminées en fonction des besoins du projet. Un processus

regroupe un ensemble d’étapes (dites activités, phases) :

❖ Séquentielles :
• Etude de faisabilité
• Définition des besoins
• Analyse / Conception
• Implémentation
• Validation et tests
• Déploiement et maintenance
❖ Permanentes (horizontales) :
• Produits intermédiaires
• Plan d’assurance qualité et documentation
• Gestion de projet des ressources

Exemple de processus de développement :

Dans la vie d’un logiciel, la programmation ne représente que 8% de l’effort total. 67% du coût total
d’un logiciel reviens à la maintenance (dont 48% à réparer des défauts). 60% des défauts
correspondent à des erreurs de spécification et de conception.

2. Les étapes du cycle de vie

a. Etude de faisabilité
Déterminer si le développement proposé vaut la peine 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.

b. Analyses des besoins et du système

L’objectif est d’avoir un schéma directeur pour le développement du système.

Les besoins sont :

❖ Définition d’un Cahier des charges (CDC)

❖ Consultation des intervenants du projet

i. Spécification
❖ Déterminer les fonctionnalités que doit posséder le logiciel.
 ❖ Collecte des exigences des utilisateurs pour le logiciel.
❖ Analyse du domaine (déterminer les tâches et les structures qui se répètent dans le problème)

ii. Organisation du projet

❖ Déterminer comment on va développer le logiciel.
❖ Analyse des coûts (établir une estimation du prix du projet)
❖ Analyse des contraintes.

iii. Planification
❖ Découper les tâches puis les ordonnancer.
❖ Etablir un calendrier de développement
❖ Assurance qualité du logiciel : déterminer les actions qui permettront de s’assurer de la
qualité du produit fini
❖ Répartition des tâches : hiérarchiser les tâches et sous-tâches nécessaires au développement
du logiciel

c. Conception
❖ Déterminer la façon dont le logiciel fournit les différentes fonctionnalités recherchées
❖ Conception architecturale : choix d’une architecture pour le système
❖ Modèles conceptuels :
• Méthodes graphiques :
▪ Merise (MCD, MCT)
▪ UML (diagrammes de classes, d’états, …)
▪ Réseaux de Petri
▪ Méthodes formelles : automates (langage VDM, Z, Larch, Eiffel)
• Dossier de conception, plan d'intégration des modules, plans de tests

d. Implémentation
Implémentation + documentation :

❖ Environnements de développement
❖ Outils de génération de code
❖ Réutilisation de composants existants (Design Patterns)
 e. Test
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
❖ Tests système : tester dans un environnement proche de l’environnement de production
❖ Tests Alpha : faire tester par le client sur le site de développement
❖ Tests Bêta : faire tester par le client sur le site de production
❖ Tests de régression : enregistrer les résultats des tests et les comparer à ceux des anciennes
versions pour vérifier si la nouvelle n’en a pas dégradé d’autres

f. Livraison ou Intégration
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

g. Maintenance et évolution
Mettre à jour et améliorer le logiciel pour assurer sa pérennité.

Pour limiter le temps et les coûts de maintenance, il faut porter ses efforts sur les étapes antérieures.

3. 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é
Plan de test Spécification
Manuel utilisateur préliminaire Spécification
Conception détaillée Conception
 Estimation des coûts Planification
Calendrier du projet Planification
Rapports des tests Tests
Documentation Implémentation

III. Modèles de cycles de vie

Ils sont de deux types :

❖ Modèles linéaires :
• Modèle en cascade
• Modèle en V
❖ Modèles non linéaires :
• Prototypages
• Modèles incrémentaux
• Modèle en spirale

1. Modèle en cascade

❖ Problèmes du modèle en cascade :

 - Les vrais projets suivent rarement un développement séquentiel
- Établir tous les besoins au début d’un projet est difficile
- Applicable pour les projets bien compris et maîtrisés
- Pas de frontière claire entre conception et développement
- Cadre de développement rigide et non transparent au client
- Le produit apparaît très tard
- Risques élevés et non contrôlés

2. Modèles en V

❖ Avantages :
- Permet une meilleure anticipation, validation intermédiaire
- Evite les retours en arrière
❖ Inconvénients :
- Le cadre de développement reste rigide
- La durée est souvent trop longue
- Le produit apparaît toujours très tard

3. Modèle itératif
Chaque nouvel incrément :

- Processus graduel d’élimination des risques

- A pour objectif la maîtrise d'une partie des risques
- Apporte une preuve de faisabilité ou d'adéquation avec les clients

4. RAD (Rapid Application Development)

Basé sur les maquettes et prototypes.

❖ Avantages :
- Client : acteur dans le processus et reçoit des résultats rapidement
- Temps de développement très court
❖ Inconvénients :
- Prototyper n’est pas spécifier
- Qualité du produit développé souvent faible
- Pour des petits projets ou à courte durée de vie
- Approprié pour les systèmes dont la modularité est évidente
5. Modèle incrémental

6. Modèle en spirale
7. eXtreme Programming (XP)