Lycée: lissane eddine laayoune

Filière: BTS DSI

Atelier de génie logiciel

Pr H.LAARAJ
hasLaaraj@gmail.com
http://lewebpedagogique.com/laarajbts
2015/2016

1
Plan du cours
I. Introduction
II. Principes de génie logiciel
III. Modèles , processus
IV. Spécification
V. Atelier de génie logiciel(outils CASE)

2
 I.1- activité:
La différence entre un programme et un logiciel?
Programme Logiciel
 créer par un individu  la fabrication collective
unique  difficile
 facile  concrétisée par les
 peut être produit sans documents , conception,
conception programmes et de jeux
de tests
 multiples versions 4
 I.2- definition:

Le génie logiciel est un domaine des

sciences de l’ingénieur dont l’objet
d’étude est la conception, la fabrication
et la maintenance des systèmes
informatiques complexes

5
 I.3- objectifs:
Activité:
 Seulement 15 % des applications écrites

sont mises en place et fonctionnent !

(selon des enquêtes réalisées aux USA)

Pourquoi ?

6
 Pourquoi?
 Retards de livraisons
 Dépassements de budgets
 Technologies en mutation
 Complexité des applications
 Evolution des spécifications en cours de
développement

7
 Objectifs de GL
assurer que les 4 critères suivants soient satisfaits

 Fonctionnalités Le système qui est fabriqué répond aux

besoins des utilisateurs
 La qualité correspond au contrat de service initial
 Les coûts restent dans les limites prévues au départ.
 Les délais restent dans les limites prévues au départ.

Règle du CQFD : Coût Qualité Fonctionnalités Délai.

8
II- Principes de génie logiciel

10
 II.1- sept principes fondamentaux
Cette partie liste sept principes fondamentaux
(proposés par Carlo Ghezzi):
 rigueur

 séparation des problèmes

 modularité
 abstraction

 anticipation du changement

 généricité
 construction incrémentale

11
rigueur
le résultat d'une activité de création d’un
logiciel peut être évalué rigoureusement,
avec des critères précis, exact.
En pratique:
 Utilisation au maximum de lois
mathématiques précises
 Suivi à la lettre de techniques formelles

(MCD, UML,…)
12
séparation des problèmes
 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é

diviser pour régner

13
 séparation des problèmes
 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.

14
séparation des problèmes
Exemple: Comment créer dynamiquement une page
internet pour visualiser et modifier le contenu d’une BD
sans la bloquer?
Solution:
Décomposition en trois composants:
Modèle: son rôle est gérer le stockage des données.
Vue: son rôle est visualiser les données.
Contrôleur: son rôle est de n’autoriser que les
modifications correctes.

15
 modularité

Un système est modulaire s’il est composé

de sous-systèmes plus simples(modules)

système Module 2

Module 1 Module3

16
abstraction
 L'abstraction se réfère à la distinction entre les
propriétés externes d'un système et les détails de sa
composition interne
 L'abstraction permet de gérer des systèmes très
complexes en connaissant seulement les choses qui
nous intéressent à un moment donné

Abstraction

17
 anticipation du changement
 Un logiciel est presque toujours soumis à
des changements continuels
 Ceci requiert des efforts particuliers pour
prévoir, faciliter et gérer ces évolutions
inévitables.

18
 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 pourra être réutilisée
plus facilement
 Des solutions génériques (paramétrables,
adaptables) sont plus facilement réutilisables.
Classes génériques<>, héritage,…
19
 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 : pour les logiciels plus
complexes on réalise d’abord un noyau des
fonctions essentielles et on ajoute
progressivement les aspects plus secondaires.
20
III modèles

21
III.1 exemple des modèles
 Modèles en cascade
 Modèles en V
 Modèle en spirale
 Modèles incrémentaux
 …

22
 III.2 le cycle de vie d'un logiciel :
 Analyse des besoins (Expression des besoins du produit)
 Spécification globale (Conception préliminaire, au niveau
système)
 Conception architecturale et détaillée
 Implémentation (Programmation ou Phase de codage)
 Gestion de Configuration et Intégration
 Validation et Vérification
 Maintenance et Assistance

23
III.3 Répartition de l’effort

24
Analyse des besoins
 La première étape du cycle de
développement d'un logiciel consiste à
produire un document qui décrit les
utilisateurs visés et leurs objectifs.

« Que doit-on faire et qui utilisera le

produit ? ».

25
 Analyse des besoins

 Mise du logiciel dans son contexte :

type de produit , les objectifs des
clients.
 Etude de l’existant :
 Etude des produits similaires dans le
marché
 Critiquer les produits concurrents
 Etude du processus/logiciels existants à
l’entreprise
26
Spécification Globale
(Conception préliminaire)
 C'est une description de haut niveau du
produit, en termes de « modules » et
de leurs interactions.

« ce que doit faire le logiciel »

27
 Conception Architecturale et
Détaillée:
 C'est au niveau de la conception détaillée que
chacun des modules énumérés dans le dossier
de conception préliminaire est décrit en détail
 Deux choses doivent émerger lors de cette
étape : un diagramme de PERT ou de GANTT,
montrant comment le travail doit être fait et dans
quel ordre, ainsi qu'une estimation plus précise de
la charge de travail induite par la réalisation de
chacun des modules.
28
Implémentation
(Programmation):
 Chacun des modules décrits dans le
document de spécification détaillé doit
être réalisé(programmé).

31
 Gestion des Configurations et
Intégration:
Appelée aussi phase de déploiement.
Quand tous les modules sont terminés,
l'intégration, au niveau du système, peut
être réalisée. C'est là que tous les modules
sont réunis en un seul ensemble de code
source, compilés et liés pour former un
paquetage qui constitue le système.

32
 Validation et Vérification:

 La validation est basée sur les besoins que le

produit doit satisfaire, et permet de mettre en
évidence de défauts.
Valider c'est répondre à la question : "Faisons
nous le bon produit?"
 La vérification a pour fonction la mise en

évidence d'erreurs.
Vérifier c'est répondre à la question "Faisons
nous le produit correctement?"
33
 Maintenance et assistance:

 Les défauts du logiciel rencontrés, soit pendant la

phase de test soit après sa diffusion, doivent être
enregistrés dans un système de suivi.
 Il faudra affecter un ingénieur logiciel pour la
prise en charge de ces défauts, qui proposera de
modifier soit la documentation du système, soit la
définition d'un module ou la réalisation de ce
module.

34
III.4 Le Modèle en Cascade:
 consiste en une succession de phases dont
chacune est méthodiquement vérifiée avant
de passer à l'étape suivante :
 Le principe de modèle en cascade est de
découper le projet en phases distinctes sur le
principe du non-retour. Lorsque une phase
est achevée, son résultat sert de point
d'entrée à la phase suivante.

35
 schéma Modèle en cascade
Etude préliminaire

Projets de petite taille

Analyse des besoins

Analyse du système

Conception du système

Développement

Tests

Installation

Maintenance 36
 Modèles en Cascade
Avantages
 Simple et facile à comprendre
 Force la documentation : une phase ne

peut se terminer avant qu’un document

soit validé
 Les progrès sont tangibles (pour

l’équipe de développement)

37
 Modèles en cascade
Limites
 Le produit final est la première chose que
voit le client
 Ne marche que si les besoins sont stables
et le problème connu
 ne traite pas les évolutions
 Problèmes découverts en phase de
validation

38
 III .5 Modèle en « V »

(variante du modèle en cascade)

L'assurance qualité est le processus qui permet de vérifier en continu
la qualité du produit à fur et à mesure de sa fabrication.

Le modèle en V met l'accent sur ce processus. Il confronte les

différents niveaux de test avec les phases de projet de même niveau.
Ceci permet à chaque étape de définir non seulement les fonctions,
mais également les critères de validation.

La cohérence entre les deux éléments permet de vérifier en continu

que le projet progresse vers un produit répondant aux besoins
initiaux.

Ce modèle est adapté aux projets de taille et de complexité moyenne.

39
Le modèle en «V»

40
III.6 Modèles incrémentaux
 L’environnement technique et économique
évolue
 Les besoins et les souhaits des clients
changent
 Les priorités du management aussi
 les méthodes en cascade ne marchent pas
 On ne peut pas attendre de tout savoir pour
commencer

41
 Principes des modèles
incrémentaux
 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 a priori

42
 Modèles incrémentaux

 La première version constitue le noyau

 Les versions suivantes s’appuient sur l’existant et
étendent l’architecture
 Chaque version donne lieu à un cycle de vie complet

cycle de cycle de
vie vie
complet complet

Version 1 43
Version 2 Version 3
 Modèles incrémentaux
Avantages
 Une première version du système est fournie
rapidement
 Réduit le stress du management !
 Les risques d’échec sont diminués
 Découverte des problèmes assez tôt
 Les parties importantes sont fournies en premier
et seront donc testées plus longuement
 Les clients peuvent ajouter des besoins à tous
moments
44
Modèles incrémentaux
Limites
 Difficile à définir les incréments:
 Difficile de concevoir une architecture
stable dès le début ou facilement
évolutive
 Ne traite pas toutes les évolutions,
notamment celles qui remettent en
cause l’architecture

45
 Synthèse:

Un cycle de vie apporte stabilité, contrôle et

organisation des activités
 meilleure estimation des coûts et besoins

 meilleure coordination

 meilleure productivité

 meilleure visibilité et compréhension

49
IV- spécification

50
IV.1- définition (spécification)

 Tout produit complexe à construire doit

d’abord être spécifié ; par exemple un pont
de 30 mètres de long, supportant au moins
1000 tonnes, construit en béton, etc. Ces
spécifications peuvent être considérées
comme un contrat entre un client et un
producteur
 De manière générale une spécification décrit
les caractéristiques attendues (le quoi) d’une
implantation (le comment).
51
IV.2 Les techniques de spécification pour
les phases d’analyse

 Les spécifications en langue naturelle: elles

manquent de structuration, de précision et sont
difficiles à analyser.
 Les spécifications semi formels: pour spécifier
des systèmes par des langages spécialisés(ADA, UML,
DFD,…).
 Formelle : quand la syntaxe et la sémantiques sont
définies formellement par des outils mathématiques

52
IV.3 Les diagrammes de flots de données
(DFD)

 Il s’agit d’une technique semi-formelle

et opérationnelle. Les DFD décrivent
des collections de données manipulées
par des fonctions.
 Les données peuvent être persistantes
(dans des stockages) ou circulantes
(flots de données).

53
 Diagramme DFD
La représentation graphique classique distingue :
 les fonctions par des cercles

 les stockages par des boîtes ouvertes

 les flots par des flèches

 les entités externes par des rectangles

54
 Exemple: DFD d’un guichet bancaire

Vérifier les Clients

carte informations du
+passwd client

Les infos
correctes
Client Somme à tirer Comptes
Choisir la
somme

Solde Argents
argent
suffisant
sortir
l’argent
55
IV.4 diagramme de contexte

 Au niveau le plus abstrait, on peut se

contenter des entités à l’interface
(‘acteurs’) et des flots qu’ils
s’échangent, sans décomposition en
fonctions. On parle alors de ‘diagramme
de contexte’

56
 Exemple : diagramme de contexte d’un
guichet bancaire

carte
passwd
Client
Somme à tirer
Guichet
argent

57
 Exercice: On s'intéresse au processus des emprunts des
livres dans une bibliothèque.

 Un étudiant se présente au guichet pour emprunter un livre, donne à

l'employé de la bibliothèque la référence du livre voulu.
 l'employé demande à l'étudiant sa carte qui sera saisie à l’aide d’un
lecteur optique (lecture du code à barres).
 Il vérifie ensuite si le livre est déjà emprunté ou non.
 Si le livre est présent dans la bibliothèque, il le donne à l'étudiant et
met à jour la base de données.
 Si le livre est emprunté, il retourne à l'étudiant la date à laquelle il
pourra avoir le livre. Il met à jour ensuite le statut du livre dans la
base de données.
1- Donner le DFD?
2- Donner le diagramme de contexte?

58
 Correction:
1-Diagramme DFD

Date de retour Mise à jour

emprunté
existe

Ref livre Vérifier

Etudiant l’existence du Livres
carte
livre

Date de Non existe

réservé
disponibilité

Mise à jour

59
 Correction:
2- diagramme de contexte

carte

Ref livre
Etudiant
Date de retour
Bibliothèque
Date de
disponibilité

60
V- Atelier de génie logiciel
AGL ou bien (outils CASE)

61
 V.1 – AGL (outils CASE)
 Un logiciel (Outils CASE Computer Aided
Software Engineering) aidant à la réalisation de
logiciels
 Il est basé sur des méthodologies qui formalisent

le processus logiciel
 Il contribue à l'amélioration de la productivité et

de la qualité du logiciel
Exemple : Windev , visual studio, netbeans, …

62
 V.2- les composantes de AGL

Exploitation
Analyse Conception Codage Test et
Maintenance

Debuggers
Editeur de Compilateur Outils de
Editeur de Logiciel de
texte et de Générateurs génération
texte et de gestion de
diagrammes d'interfaces de tests
diagrammes configuration

63