Agl DUT Chaimae Saadi

Ch.
SAADI
Génie logiciel
GÉNIE LOGICIEL
2éme année DUT
EST-Salé
1
Pr.Chaimae SAADI
Email:chaimaesaadi900@gmail.com
VOLUME HORAIRE
Ch.SAADI
Volume
Nature
horaire
Elément 2 : Génie logiciel
Génie logiciel
Cours 20H
TD 0H
TP 20H
Autres (Travaux de
terrain, Projets, 0H
Stages, (préciser))
TOTAL 24H
Travail personnel
(préciser)
3H
Devoirs, exposés,
mini projet (*)
2
OBJECTIF DU COURS
Ch.SAADI
¢ L’objectif spécifique de « Génie Logiciel » est de former des
développeurs de haut niveau dans le domaine du
Génie logiciel
génie logiciel, capables de maîtriser les spécificités des
applications standard, mobiles et aussi les ERP sur les
différentes plateformes.
¢ L’objectif principale est d’assurer et d’améliorer la

qualité d’un produit logiciel et de fournir les méthodes et
techniques nécessaire à tout programmeur pour utiliser
ou réutiliser les applications existantes.
3
OBJECTIFS DÉTAILLER
Ch.SAADI
Génie logiciel
o A l’issu de ce cours l’étudiant aura la capacité d’opter
pour l’architecture logicielle la mieux adéquate et de
réussir la mise en œuvre d’une approche de
développement d’architecture à base de modèles à travers
les métadonnées et les transformations de modèles.
4
COMPÉTENCES SPÉCIFIQUES AU GÉNIE LOGICIEL
¢ Maitriser les techniques et les outils utilisés dans la production

industrielle des logiciels.
Ch.SAADI
¢ Connaitre les différents modèles de processus pour le
développement logiciel
Génie logiciel
¢ Maitriser Les outils d’aide à la prise de décision
¢ Développer une application selon une architecture distribuée
¢ Créer et déployer des services web
¢ Développer des applications sur des terminaux mobiles sur

différentes plates formes
5
¢ Gérer la migration d’une application entre les différentes plates
formes mobiles
PLAN DU COURS
Ch.SAADI
¢ Les Techniques et les Outils lies à une Phase des Cycles de Vie
Génie logiciel
Les différents modèles de cycle de vie
La spécification
La conception
Le codage
6
Ch.SAADI
CHAPITRE1: INTRODUCTION AU GÉNIE
LOGICIEL
Génie logiciel
¢ Qu'est ce que ce génie logiciel
¢ Pour quoi la naissance de GL
¢ Processus du développement logiciel
¢ Cycle de vie des logiciels
7
QU’EST CE QU’UN LOGICIEL?
Système informatique
Logiciels classiques
Ch.SAADI
Propriétés statiques Propriétés
dynamiques
Génie logiciel
Les traitements prennent de plus en plus Systèmes d’Information d’Aide à la
d’importance Décision
Systèmes d’Information (BD)
Les données sont au centre du système :

orientation sujet (entrepôt) Les données sont
Les données sont au centre du système et persistantes Les systèmes procèdent de plus
persistantes en plus à des post-traitements : fouille de
données et aide à la décision
8
Ch.SAADI
Quelles sont les qualités d’un bon logiciel ?
Génie logiciel
Qu’est-ce que le génie logiciel ?
Génie Logiciel= génie + Logiciel (Software engineering)
Quelles sont les activités fondamentales du génie logiciel?
9
QU’EST-CE QUE LE GÉNIE LOGICIEL?
Ch.SAADI
IEEE definition:
Le Génie Logiciel est l’application d’une approche
systématique, disciplinée et quantifiable au développement, à
l’exploitation et à la maintenance du logiciel. C’est-à-dire,
Génie logiciel
l’application de l’ingénierie au logiciel
D’après MC. Gaudel :

Le Génie Logiciel est 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 système
informatique pour résoudre certains problèmes
10
LA CRISE DU LOGICIEL: NAISSANCE
Ch.SAADI
Constat du développement logiciel depuis la fin des années 60 :
Génie logiciel
● délais de livraison non respectés
● budgets non respectés
● ne répond pas aux besoins de l'utilisateur ou du client
● difficile à utiliser, maintenir, et faire évoluer
Q
D C
11
1969
LA CRISE DU LOGICIEL :
Étude du DoD 1995 Étude du Department of Defense des
États-Unis sur les logiciels produits dans le cadre de 9 gros
Ch.SAADI
projets militaires
Génie logiciel
des projets payés mais
jamais livrés 45%
des projets utilisés tels quel

2%
des projets livrés
Utilisés après mais jamais
modification 3% utilisés 30%
des projets Abandonnées

ou refaits 20%
12
Synthèse: 98% des projet ont échoué grâce aux bugs
BUGS
Ch.SAADI
Raisons principales des bugs :
oErreurs humaines
Génie logiciel
oTaille et complexité des logiciels
oManque de méthodes de conception
oNégligence de la phase d'analyse des besoins du client
oNégligence et manque de méthodes et d'outils des phases
de validation/vérification
13
BUGS
Exemple de Bugs :
Ch.SAADI
ØHealthcare.Gov en 2014:
vProgramme lancer par Obama (probléme de
Génie logiciel
saturation de serveur)
ØSonde Mariner 1, 1962…
vDétruite 5 minutes après son lancement; coût : $18,5
millions
vDéfaillance des commandes de guidage due à une
erreur de spécification
vErreur de transcription manuelle d'un symbole
14
mathématique dans la spécification
La crise du logiciel :
ØGL est surtout conçu pour maîtriser le développement des
Ch.SAADI
systèmes complexes
Génie logiciel
15
STANDISH GROUP, CHAOS MANIFESTO 2013 - THINK BIG, ACT SMALL, 2013
MYTHES DU LOGICIEL
Ch.SAADI
vIdée grossière du logiciel suffisante pour commencer à
programmer .
Génie logiciel
vTravail terminé quand programme écrit et fonctionnel
vFacile de gérer spécifications changeantes
vEn cas de retard, solution : ajouter des programmeurs
16
SYNTHÈSE
Pour répondre à cette crise, les chercheurs ont essayé d’appliquer
Ch.SAADI
les méthodes connues de l’ingénieur au domaine du logiciel, pour
établir des méthodes fiables sur lesquelles construire une
Génie logiciel
industrie du logiciel.
Il s’agit de se donner un cadre rigoureux pour :

Ø•Guider le développement du logiciel, de sa conception à sa
livraison;
Ø•Contrôler les coûts, évaluer les risques et respecter les délais;
Ø•Établir des critères d’évaluation de la qualité d’un logiciel.
17
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

Définition:
Ch.SAADI
•Le « processus de développement logiciel» désigne toutes les
étapes du développement d'un logiciel, de sa conception à sa
disparition.
Génie logiciel
•Ce découpage permet la validation du développement logiciel
(conformité du logiciel avec les besoins exprimés), et la
vérification du processus de développement (adéquation des
méthodes mises en oeuvre).
•L'origine de ce découpage provient du constat que les erreurs ont un coût

d'autant plus élevé qu'elles sont détectées tardivement dans le processus
de réalisation.
•Le Processus de développement logiciel permet de détecter les erreurs au

plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
18
Ch.SAADI
Le génie logiciel est une démarche d’ingénierie qui traite
tous les aspects de la production de logiciels.
Génie logiciel
Le développement comprend un ensemble d’activités:
Ø La gestion des exigences // La spécification
Ø La conception
Ø La construction
ØLa validation
ØLe déploiement
ØLa maintenance
19
Description:
Ch.SAADI
La description du processus peut aussi inclure:
ØLes produits, qui sont les résultats des sorties d’une activité
Génie logiciel
d’un processus (les livrables)
ØLes rôles, qui reflètent les responsabilités des personnes

impliquées dans le processus (ex: Scrum-Master and
Product-Owner)
ØLes pré-et post-conditions, qui sont des conditions vraies

avant et après l’activité d’un processus (ex: durée de sprint). 20
Ch.SAADI
Phase : définition des besoins
Génie logiciel
21
Ch.SAADI
Phase : Analyse des besoins / spécification
Génie logiciel
22
Phase : Planification / Gestion de projet
Ch.SAADI
Génie logiciel
23
Phase : Conception
Ch.SAADI
Génie logiciel
24
Phase : Codage et tests unitaires
Ch.SAADI
Génie logiciel
25
Phase : Intégration
Ch.SAADI
Génie logiciel
26
Phase : Qualification
Ch.SAADI
Génie logiciel
27
Phase : Maintenance
Ch.SAADI
Génie logiciel
28
QU’EST CE QU’UN CYCLE DE VIE
Ch.SAADI
Génie logiciel
Ensemble séquentiel de phases, dont le nom et le nombre
sont déterminés en fonction des besoins du projet, permettant
généralement le développement d’un service ou d’un produit.
29
MODÈLE DE CYCLE DE VIE
ØModèle linéaire :
Ch.SAADI
ü Modèle en cascade
ü Modèle en V
Génie logiciel
ØModèle itératif
ü Modèle en spirale
üModèle incrémental
ØModèle avec méthode Agile
ü XP
üScrum
üCrystal
üRAD 30
ü…
MODÈLE LINÉAIRE :
Ch.SAADI
Historiquement, la première tentative pour mettre de la rigueur
Génie logiciel
dans le ‘développement sauvage’ (coder et corriger ou ‘code and
fix’) a consisté à distinguer la phase d’analyse avant la phase
d’implémentation (séparation des questions).
31
MODÈLE EN CASCADE
Ch.SAADI
•Il a été mis au point dès 1966, puis formalisé aux alentours de
1970.
Génie logiciel
•Le modèle de la cascade défini des étapes (ou phases) durant
lesquelles les activités de développement se déroulent.
•Une étape doit se terminer à une date donnée par la

production de certains documents ou logiciels Les résultats
de l'étapes ont soumis à une étude approfondie.
•L'étape suivante n'est abordée que si les résultats sont jugés

satisfaisants.
32
Ch.SAADI Génie logiciel
33
MODÈLE EN CASCADE
MODÈLE EN CASCADE- CARACTÉRISTIQUES
Ch.SAADI
•Hérité des méthodes classiques d'ingénierie;
Génie logiciel
•Découverte d'une erreur entraîne retour à la phase à
l'origine de l'erreur et nouvelle cascade, avec de
nouveaux documents...
•Coût de modification d'une erreur important, donc le

choix en amont cruciaux (typique d'une production
industrielle).
34
MODÈLE EN CASCADE- INCONVÉNIENTS
Ch.SAADI
Génie logiciel
•Le modèle en cascade rend coûteux le développement
itératif puisque la rédaction des documents de validation
de chaque phase demande beaucoup de travail.
•Ce modèle est inadapté au développement de systèmes dont

la spécification est difficile à formuler a priori.
35
36
MODÈLE EN V
MODÈLE EN V
Ch.SAADI
•Modèle de cascade amélioré dans lequel le développement des
tests et du logiciels sont effectués de manière synchrone.
Génie logiciel
•Le principe de ce modèle est qu’avec toute décomposition doit
être décrite la recomposition et que toute description d’un
composant est accompagnée de tests qui permettront de
s’assurer qu’il correspond à sa description.
•Problème de vérification trop tardive du bon

fonctionnement du système. 37
MODÈLE EN V - NIVEAU DE TEST
•Test unitaire : test de chaque unité de programme
(méthode, classe, composant), indépendamment du reste du
Ch.SAADI
système
Génie logiciel
•Test d'intégration : test des interactions entre
composants (interfaces et composants compatibles).
•Test d'acceptation et système : test du système complet par

rapport à son cahier des charges.
•Recette : faite par le client, validation par rapport aux

besoins initiaux (tests, validation des documents, conformité 38
aux normes...).
MODÈLE EN V
Ch.SAADI
Objectifs :
•Validations intermédiaires pour prévenir les erreurs tardives;
Génie logiciel
meilleure planification et gestion.
Principes
•Validation à chaque étape;
•Préparation des protocoles de validation finaux à chaque étape
descendante;
•Validation finale montante et confirmation de la validation
descendante; 39
MODÈLE EN V
Conséquences :
Ch.SAADI
•Obligation de concevoir les jeux de test et leurs résultats;
•Réflexion et retour sur la description en cours;
Génie logiciel
•Meilleure préparation de la branche droite du V.
Les activités de chaque phase peuvent être réparties en 5

catégories
•Assurance qualité;
•Production;
•Contrôle technique;
•Gestion; 40
•Contrôle de qualité.
INTÉRÊT DU MODÈLE EN V
Ch.SAADI
Validations intermédiaires
Génie logiciel
•Bon suivi du projet : avancement éclairé et limitation des risques
en cascade d’erreurs
•Favorise la décomposition fonctionnelle de l’activité
•Génération de documents et outils supports
Modèle très utilisé et éprouvé
41
MODÈLE EN V - LIMITATIONS
Ch.SAADI
Un modèle séquentiel (linéaire)
Génie logiciel
•Manque d’adaptabilité
•Maintenance non intégrée : logiciels à vocation temporaire
•Validations intermédiaires non formelles : aucune garantie sur
la non transmission d’erreurs
•Problème de vérification trop tardive du bon fonctionnement du
système
42
43
MODÈLES ITÉRATIFS:
MODÈLE EN SPIRALE (B. BOËHM )
Ch.SAADI
- met l'accent sur l’évaluation des risques; à chaque étape:
Génie logiciel
•On n’a pas la possibilité de retourner en arrière.
•Le nombre de cycles est variable selon que le

développement est classique ou incrémental.
44
45
MODÈLE EN SPIRALE
46
MODÈLE EN SPIRALE
MODÈLE EN SPIRALE-LIMITATION
Ch.SAADI
-Calendrier et budget irréalistes
-Développement de fonction inapproprié
Génie logiciel
-Problème de performance a besoin de compétences dans
l'évaluation approfondie des incertitudes et des risques
associés au projet et leur réduction.
-
47
MODÈLE EN SPIRALE-LIMITATION
Ch.SAADI
Génie logiciel
48
MODÈLE INCRÉMENTAL
le modèle incrémental a été proposé dans les années 80.
Ch.SAADI
Génie logiciel
Ø Le produit est délivré en plusieurs fois, de manière
incrémentale, c’est-à-dire en le complétant au fur et à mesure et
en profitant de l’expérimentation opérationnelle des incréments
précédents 49
Ch.SAADI
- Le développement est réaliser par suite d’incréments ou
composantes, qui correspondent à des parties des
spécification, et qui viennent intégrer le noyau de logiciel.
Génie logiciel
- L’objectif est d’assurer la meilleur adéquation aux
besoins possibles.
- Le choix d’incrément est un compromis entre la durée de

développement et le niveau de prise en compte des
spécification.
50
Ch.SAADI
•Hiérarchiser les besoins du client;
•Concevoir
et livrer au client un produit implantant un sous
ensemble de fonctionnalités par ordre de priorité.
Génie logiciel
51
MODÈLE INCRÉMENTAL- AVANTAGES
Ch.SAADI
Le système peut être mis en production plus rapidement,
Génie logiciel
-
avec la diffusion ensuite sous forme de version
- Les premiers incréments permettent de renforcer

l’expression de besoin et autorisent la définition des
incrément suivant.
52
MODÈLE INCRÉMENTAL- RISQUES
Ch.SAADI
-Les noyaux, les incréments ainsi que leurs interactions
doivent être spécifiés globalement, au début du projet;
Génie logiciel
-
-Les incréments doivent être aussi indépendants que

possibles.
-
53
SYNTHÈSE
Ch.SAADI
Il n’y a pas de modèle idéal car tout dépend des circonstances.
Le modèle en cascade ou en V est risqué pour les
Génie logiciel
développements innovants car les spécifications et la
conception risquent d’être inadéquats et souvent remis en cause.
Le modèle incrémental est risqué car il ne donne pas beaucoup

de visibilité sur le processus complet.
Souvent, un même projet peut mêler différentes approches,

comme le prototypage pour les sous-systèmes à haut risque et la
cascade pour les sous systèmes bien connus et à faible risque.
54
Ch.SAADI
Génie logiciel
MODÈLE AVEC MÉTHODE AGILE
55
MÉTHODES AGILE (NAISSANCE)
Ch.SAADI
Þ réduire le cycle de développement des projets
informatiques
Þ répondre plus rapidement aux évolutions des
Génie logiciel
demandes de l’utilisateur final.
l intégrer au cours du projet de manière continue le client final

l Gérer les projets informatiques de manière adaptative et
incrémentale.
56
VALEURS DES MÉTHODES AGILES
Ch.SAADI
¢ Des logiciels opérationnels plus qu’une documentation
exhaustive
Génie logiciel
¢ La collaboration entre les développeurs et les clients plus
que la négociation contractuelle
¢ L’adaptation au changement plus que le suivi d’un

planning
57
CARACTÉRISTIQUES DES MÉTHODES
AGILES
Ch.SAADI
¢ Le développement est centré sur le code.
Génie logiciel
¢ Il s'agit de produire rapidement des prototypes exécutables.
¢ Orientées client plutôt que processus
¢ Moins orientés documentation
¢ Méthodes adaptatives
Processus auto-adaptatif : révision du processus à chaque
itération 58
MÉTHODE AGILE
Ch.SAADI
¢ Les méthodes agiles utilisent un principe
de développement itératif => Ces itérations sont en fait
Génie logiciel
des mini-projets définis avec le client en détaillant les
différentes fonctionnalités qui seront développées en
fonction de leur priorité.
¢ Le chef de projet établi alors un macroplanning

correspondant aux tâches nécessaires pour le
développement de ces fonctionnalités.
59
MÉTHODES AGILES
Ch.SAADI
Plusieurs méthodes de type agiles existent
On peut citer :
Génie logiciel
¢ XP (Extreme programming)
¢ Scrum
¢ Crystal
¢ RAD (rapid application development)
¢ ….
60
PROCESSUS DE DÉVELOPPEMENT SCRUM
Ch.SAADI
¢ Développée en 1996, par J.Sutherland et K.Schwaber
Cette méthode de gestion, ou plutôt ce Framework de
Génie logiciel
¢
management de projet, à pour objectif d’améliorer la
productivité de son équipe.
¢ Concentrer l’équipe, de manière itérative, sur un ensemble

de fonctionnalités à réaliser
Durée des itérations
-SCRUM suggère un mois

61
RÔLE : DIRECTEUR DU PRODUIT
Ch.SAADI
Représentant des clients et des utilisateurs
Définit l’ordre de développement des fonctionnalités
Génie logiciel
¢
¢ Décide sur les orientations importantes du projet
¢ choisit la date et le contenu de la release
¢ accepte et rejette les résultats
Product owner 62
ROLE: SCRUM MASTER
Ch.SAADI
Représente le management de projet:
Veille à résoudre les problèmes non techniques
Génie logiciel
¢
¢ Veille à l’application des valeurs de Scrum

¢ Il est garant du cadre méthodologique Scrum
¢ Il est un coach, et non un supérieur
¢ Des compétences humaines indispensables
¢ L’analogie avec le maître du jeu
Scrum Master
63
ROLE : EQUIPE
Ch.SAADI
¢ Se composent de 5 à 10 personnes
Génie logiciel
¢ Auto-gérée
¢ regroupent tous les rôles: architecte, concepteur, analyste,

développeur, testeur
¢ Décisions prises ensemble
¢ se concentrent sur un sprint à la fois (sprint courant)

64
SCRUM- ITÉRATIONS (Sprint)
Ch.SAADI
Le cycle de vie Scrum est rythmé par des itérations de
quelques semaines.
Génie logiciel
¢ Une itération, appelée Sprint, dure 30 jours (2 à 4
semaines)
¢ Chaque Sprint a un but à atteindre
¢ Un Sprint aboutit sur la livraison d’un produit partiel

fonctionnel
¢ La participation du client est déterminante pour le choix

des priorités dans les fonctionnalités du logiciel 65
RÉFÉRENTIEL DES EXIGENCES : LE PRODUCT
BACKLOG
Ch.SAADI
ØLe référentiel des exigences initiales est dressé et
hiérarchisé avec le client.
Génie logiciel
ØIl constitue ce que l’on nomme le product backlog.
ØIl ne doit pas nécessairement contenir toutes les

fonctionnalités attendues dès le début du projet,
Øil va évoluer durant le projet en parallèle des besoins du client.
66
USER STORY
Ch.SAADI
Les fonctionnalités décrites portent le nom de User Stories et sont
décrites en employant la terminologie utilisée par le client.
Génie logiciel
Une User Story ou Story contient généralement les informations
suivantes :
1. ID – un identifiant unique
2. Nom – un nom court (entre 2 et 10 mots), descriptif de la

fonctionnalité attendue par le client.
3. Importance – un entier qui fixe la priorité des Stories. La

priorité d’une story peut être changée en cours de réalisation du
projet.
67
USER STORY
Ch.SAADI
4. Estimation – La quantité de travail nécessaire pour
développer, tester, et valider cette fonctionnalité. L’unité de
mesure peut être un nombre de jours idéaux (jours à 100%
Génie logiciel
dédiés à la fonctionnalité) ou un nombre de points. Les
estimations se font en relatif en comparant les estimations des
stories terminées avec la story à estimer.
5. Demo – Un test relativement simple (ex : exporter un objet en

XML puis l’effacer de la base, l’importer depuis le XML, à la fin
l’objet doit être dans la base). Ce test constitue un test de
validation.
6. Notes – toute autre information : clarifications, références

documentaires… 68
PLANNIFICATON
Ch.SAADI
Planification à trois niveaux :
Génie logiciel
¢ Sprint : itération de 30 jours
¢ Release/projet : regroupement d’itérations
¢ Quotidien : réunion (srcum) de mise au point
69
70
SCRUM BOARD
AN EXAMPLE OF A SPRINT BACKLOG
Ch.SAADI
Génie logiciel
71
72
SCRUM PROCESS
OUTILS POUR SCRUM
Ch.SAADI
Outils libres :
¢ IceScrum (open source)
Génie logiciel
Outils propriétaires :
¢ ScrumWorks
73
METHODE XP
Ch.SAADI
eXtreme Programming (XP) Apparaît en 1999 par
Ken Beck de Chrysler .
Génie logiciel
Nouvelle approche de développement incrémental basée
sur la réalisation rapide, en équipe, d’incréments fonctionnels.
Caractéristiques :
•Emphase sur la satisfaction du client
Øle produit dont il a besoin

Ødes livraisons aux moments où il en a besoin
Øun processus robuste si les exigences sont modifiées
•Emphase sur le travail d'équipe 74

Ømanagers, clients, développeurs : ensemble
VALEURS DE L’EXTREME PROGRAMMING (XP)
Ch.SAADI
Communication: Au sein de l’équipe de développeurs et avec le
Génie logiciel
client
Feedback : Itérations rapides permettant la réactivité, test du

code dès le début
Simplicité : Code simple livrable ne contenant que les

exigences du client avec un design propre et simple
75
PRATIQUE DE L’EXTREME PROGRAMMING (EQUIPE)
Ch.SAADI
Responsabilité collective du code : polyvalence des
développeurs, contribution collective aux nouvelles
fonctionnalités, à la correction de bugs et à la restructurations
Génie logiciel
(pas de droits exclusifs);
Programmation en binôme : partage des compétence,

prévention des erreurs, motivation mutuelle;
Langage commun \ Métaphore : Les mots utilisés pour

désigner les entités techniques doivent être choisis parmi les
métaphores du domaine de projet;
Rythme durable : maintenir un niveau optimal de travail entre

énergie nécessaire pour le développement et le repos réparateur.
76
PRATIQUE DE L’EXTREME PROGRAMMING
(CODE)
Ch.SAADI
Refactoring : Investissement pour le futur, réduction de la
dette technique;
Génie logiciel
Conception simple : facilité des reprises du code, facilité de
l’ajout de fonctionnalité;
Tests unitaires: Test en premier pour une programmation

ultérieure plus facile et plus rapide, fixe la spécification
(ambiguïtés) avant le codage, feedback immédiat lors du
développement, itération du processus pour tout tester;
Intégration continue : Ajout de valeurs chaque jour, évite la

divergences, efforts fragmentés et permet la diffusion rapide
pour la réutilisation;
77
Règles de codage : cohérence globale, code lisible / modifiable
par toute l'équipe.
PRATIQUE DE L’EXTREME PROGRAMMING
(PROJET)
Ch.SAADI
Client sur site : orienter le développement en fonction des
réactions des usagers et des points critiques du domaine
Génie logiciel
d’utilisation
Tests d’acceptation : conformité par rapport aux attentes du

client
Planification itérative et livraison fréquente : Les fiches

sont rédigés tout au long du projet, chaque fiche correspond à une
fonctionnalité (scénario) où figure la description du scénario,
l’ordre de priorité, la durée de réalisation, les noms des
développeurs…
78
LE CYCLE STANDARD XP
Ch.SAADI
v1. Le client écrit ses besoins sous forme de scénario
v2. Les développeurs évaluent le coût de chaque scénario, si le
Génie logiciel
coût est trop élevé pour un scénario ou difficile à estimer, le
client le découpe en plusieurs scénario et les soumet aux
développeurs
v3. Le client choisi, en accord avec les développeur, les

scénario à intégrer à la prochaine livraison
v4. Chaque binôme des développeurs prend la responsabilité

d’une tâche
79
LE CYCLE STANDARD XP
Ch.SAADI
v5. Le binôme écrit les tests unitaires correspondant au
scénario à implémenter
Génie logiciel
v6. Le binôme procède à l’implémentation du programme
v7. Le binôme réorganise le code (refactoring)
v8. Le binôme intègre ses développement à la version

d’intégration, en s’assurant que tous les tests de non
régression passent
80
CRYSTAL
Ch.SAADI
Génie logiciel
Cette méthode a été mise au point par Alistair
Cockburn(signataire du Manifeste) en 1997.
ØPlusieurs principes doivent être partagés par l’ensemble de

l’équipe
81
PRINCIPE DE CRYSTAL
Ch.SAADI
v La communication et la collaboration entre les membres de
l’équipe est omniprésente
Génie logiciel
v Le nombre de membres de l’équipe ne peut pas dépasser 6
personnes
v Toute l’équipe doit travailler dans la même pièce
v Les diagrammes de modélisation doivent être élaborés en

groupe et sur tableau blanc
v Livrer fréquemment des parties exécutables
82
CARACTÉRISTIQUES DE CRYTSAL
Ch.SAADI
Ses caractéristiques principales sont :
Ø Une collaboration étroite entre toutes les parties

prenantes, y compris en dehors de l’équipe (stakeholders)
Génie logiciel
Ø Une bonne communication interpersonnelle
Ø Focus sur l’objectif et disponibilité
Ø Un contact permanent avec les utilisateurs
Ø Une réflexion constante sur ces propriétés
83
CARACTÉRISTIQUES DE CRYTSAL
Ch.SAADI
Ø La spécialisation consiste à observer les utilisateurs dans leur
travail pour mieux connaître leurs besoins
Génie logiciel
Ø Classer par priorité les différents cas d'utilisation.
Ø Elaboration d’une ébauche de conception impliquant les outils

à utiliser.
ØDéveloppement des itérations (d'une longueur de 2 à 3 mois)
84
MÉTHODES CLASSIQUES VS AGILES
Ch.SAADI
Les méthodes classique (prédictives) tentent de
réduire l'incertitude dès le début du projet par une
planification très précise et très détaillée. Cette levée de
Génie logiciel
risque implique que les exigences de l'application soient figées.
Les méthodes Agiles (adaptables) préfèrent, partant

d'une planification initiale, réévaluée régulièrement,
s'adapter aux évolutions du contexte.
=> La réévaluation servira de base à une prise de décision de

type GO ou NO GO à chaque grand changement appliqué au
projet initial.
85
RÉCAPITULATIF MÉTHODE AGILES
Ch.SAADI
Les méthodes agiles seront plus utilisées pour les gros
Génie logiciel
¢
projets car elles offrent une meilleure adaptabilité,
visibilité et gestion des risques.
¢ Elles pourraient tout aussi bien être utilisées pour les

projets où il n’y pas de documentations détaillées
86
RÉCAPITULATIF MÉTHODES CLASSIQUES
Ch.SAADI
¢ Les méthodes classiques seront plus utilisées si vous avez
une idée très précise de votre projet avec un cahier des
Génie logiciel
charges et planning très détaillé où vous avez anticipé
tous les risques possibles.
¢ Le chef de projet se retrouve souvent seul face à lui-même

lors de la prise de décision, de gérer les retours client, devant
l’incertitude afin de satisfaire le client tout en respectant les
3C.
87
88
Ch.SAADI
Génie logiciel
CHAPITRE 2: LA SPÉCIFICATION
89
SPÉCIFIER….?
Ch.SAADI
Préciser
Exprimer
Génie logiciel
Objectif : comprendre les besoins du clients
Définir
Déterminer
Établir une description claire de ce que doit faire le
Indiquer logiciel (fonctionnalités détaillées, exigences de qualité,
interface...)
90
EXIGENCE VS BESOIN
Ch.SAADI
¢ Besoin èobjectif a atteindre
Génie logiciel
¢ Exigenceè comment satisfaire le besoin de ce
client!!!
¢ Exemple:
Besoin d’application :sécurité
Se mettre d’accord sue le type de sécurité : Exigence
(doit apparaitre dans le CDC)
91
SPÉCIFICATION
Ch.SAADI
Déterminer ce que doit faire le système (côté client)
= > Document précis spécifiant les fonctionnalités attendues;
Génie logiciel
Exemple : définition de la frontière du système, description des
fonctionnalités du système, interactions…
À noter : Les spécifications ne sont jamais complètes ni

définitives.
92
L’INGÉNIERIE DES EXIGENCES
Ch.SAADI
Définition :
Génie logiciel
« L’ingénierie de exigences est la branche du génie logiciel qui
concerne les buts réels, les fonctions et les contraintes d’un
système logiciel. Elle concerne aussi la relation que ces facteurs
entretiennent avec les spécifications précises du comportement
logiciel, et avec leur évolution dans le temps et à travers les
familles de logiciels. » Zave 1997
93
L’INGÉNIERIE DES EXIGENCES
Ch.SAADI
La gestion des exigences est une activité méthodique
pluridisciplinaire qui permet:
§ Recueillir, spécifier, affiner et qualifier les exigences d'un
Génie logiciel
système dans son environnement,
§ Définir l'engagement "à faire",
§ Maîtriser les changements de ces exigences dans le temps.
èC’est un ensemble de techniques, consistant à recueillir les

besoins, à les transformer en exigences, et à les spécifier dans
un cahier des charges.
Ø Objectif: la rédaction du CDC selon des étapes précises.

94
LOGICIEL : CARACTÉRISTIQUES
Ch.SAADI
Spécification fonctionnelle :
•Fonctionnalités du logiciel, réponse aux besoins des utilisateurs.
Génie logiciel
Spécification non fonctionnelle :
•Facilité d'utilisation : prise en main et robustesse

•Performance : temps de réponse, débit, fluidité...
•Fiabilité : tolérance aux pannes
•Sécurité : intégrité des données et protection des accès
•Maintenabilité : facilité à corriger et à faire évoluer le logiciel
•Portabilité : adaptabilité à d'autres environnements matériels
ou logiciels
95
SPÉCIFICATION : TYPES DES EXIGENCES
Ch.SAADI
Exigences fonctionnelles
Exemple: ajouter/modifier/supprimer
Génie logiciel
Exigences non-fonctionnelles
Des cas opérationnels exprimer d’une manière
fonctionnelle (norme ISO 9126 / norme ISO 25019 ’version 2011’)
Contraintes
Obligation du client en relation avec: budget, délai,
technologie, modèle,…
96
TYPES DES EXIGENCES : EXERCICE
Ch.SAADI
Identifier le type des exigences suivantes :
- le système doit utiliser des mots de passe
Génie logiciel
- le système doit se déconnecter automatiquement après
2 mn sans utilisation
-Le projet permet d’aider ceux qui souffrent d’Alzheimer.
- système ne peut fonctionner que sur une plate-forme
mobile smartphone avec un système d'exploitation
Android.
- Le système doit permettre un accès direct et précis aux
contacts en cas d’urgence.
97
TYPES DES EXIGENCES : EXERCICE
Ch.SAADI
-Le système doit fournir une interface pour la recherche.
Génie logiciel
-la recherche doit être effectuée dans un délai de 3s.
- Le système doit présenter des objets fréquemment

utilisés.
-La plate-forme mobile doit disposer des ressources

environnementales nécessaires pour faire fonctionner le
système.
98
ELICITATION : RECUEIL DES BESOINS
Ch.SAADI
Les méthodologies de collection de besoins et exigences (non
formelles) :
Génie logiciel
- effectuées en individuel (analyse documentaire,
observation, etc.)
- en groupe (questionnaire, mind-mapping, méthode des

post-it, interviews, storyboards, sondage/questionnaire etc.)
- brainstorming, étude de la documentation existante

(recherche interne), groupes de discussion.
99
Ch.SAADI
Par le biais des méthodes formelles :
Génie logiciel
Ø Utilisation du bachmarking: étude des projets similaires
Ø Utilisation des ontologies des graphes, KAOS, SIG
Ø Utilisation des freamwork : NFR Framework
100
Ch.SAADI
- NFR Framework
Types de Relation : AND OR
Génie logiciel
101
QUELS SONT LES PROBLÈMES LIÉS À CES EXIGENCES?
Exemple de fausse rédaction d’exigence?
Ch.SAADI
§ La régulation sera efficace dans tous les cas.
§ Toutes les informations inutiles ne sont pas affichées.
§ L’interface est simple d’utilisation.
Génie logiciel
§ Les données sont sauvegardées autant que possible.
§ L’application n’a pas de bugs.
§ « Le logiciel calcule la vitesse du missile et sa trajectoire,
en 5 secondes maximum » ….a un sens différent de:
« Le logiciel calcule la vitesse du missile, et sa trajectoire en
5 secondes maximum »
èL’exigence doit être :compréhensible claire et interpréter

102
d’une seul manière par plusieurs lecteur
COMMENT RÉDIGER UN CAHIER DES CHARGES ?
Exemple de Volere
Ch.SAADI
Génie logiciel
103
COMMENT RÉDIGER UN CAHIER DES CHARGES ?
La norme IEEE 830
Ch.SAADI
Génie logiciel
104
Ch.SAADI
CHAPITRE 3:CONCEPTION
Génie logiciel
RAPPEL MERISE
RAPPEL MODÉLISATION OBJET
RAPPEL UML
LES PRINCIPES FONDAMENTAUX EN GL
105
MERISE (RAPPEL)
Ch.SAADI
¢ Les modèles de la méthode Merise :
Génie logiciel
¢ Le modèle de flux
¢ Le modèle conceptuel de données
¢ Le modèle conceptuel de traitements
¢ Le modèle organisationnel de traitements
¢ Le modèle logique de données
¢ Le modèle opérationnel des traitements
¢ Le modèle physique des données
106
POURQUOI L’ORIENTÉ OBJET?
Ch.SAADI
une liste de ‘concepts ’(water, salt water ...) a été donné aux élèves
de primaires.
Résultat => (Harry) a construit un schéma conceptuel
Génie logiciel
Etude [Martin & Odell] [Novak, 1984, Cambridge University Press]
107
MODELISATION OBJET (RAPPEL)
Principaux concepts objet :
Ch.SAADI
¢ Classe
Type d’objet caractérisé par sa structure de données
(attributs) et son comportement (méthodes)
Génie logiciel
¢ Objet
Un objet représente un individu, une entité identifiable
réelle ou conceptuelle avec un rôle bien défini dans le
domaine du problème ou dans un système (instance de
classe)
¢ Attribut
Un attribut est une propriété, une caractéristique, une
qualité inhérente ou distinctive d’un objet (exemples : la 108
couleur ou l’immatriculation d’une voiture)
¢ Méthode
Ch.SAADI
Une méthode est une action qu’un objet effectue de sa
propre initiative ou à la demande (réaction à un
événement ou à un envoi de message). Ces méthodes
Génie logiciel
décrivent les propriétés dynamiques d’un objet.
¢ Quelques méthodes "classiques" :

Un constructeur est une méthode qui permet de
construire et d’initialiser un objet (instanciation d’un
objet)
Par opposition, un destructeur est une méthode qui

permet de détruire un objet instancié
109
Un accesseur est une méthode qui permet de récupérer la
valeur d’un attribut d’un objet (get… et is…)
Ch.SAADI
Un modificateur est une méthode qui permet de modifier
la valeur d’un attribut d’un objet (set…)
Génie logiciel
Un observateur est une méthode qui permet de retrouver
des informations sur l’histoire (l’état) d’un objet
Un itérateur est une méthode qui permet d’appliquer à

chaque partie d’un objet (par exemple dans le cas d’un objet
de type collection) une action déterminée
110
¢ Association
Une association permet de préciser une relation entre
différents objets. Une association possède généralement un
Ch.SAADI
nom qui sert à décrire la nature de la relation
Une association est également caractérisée par le nombre
d’objets pouvant être reliés par l’intermédiaire d’une instance
Génie logiciel
d’association : 0..1, 0..n, 1..n, n..n
¢ Agrégation
Une agrégation est une relation binaire entre deux objets
qui spécifie une inclusion entre une partie et un tout. Une
partie peut appartenir à d’autres agrégations et exister
indépendamment
¢ Composition
Une composition est un type particulier d’agrégation qui
spécifie une inclusion entre une partie et un tout plus forte
que l’agrégation : quand on supprime l’élément composite, il
y a obligatoirement suppression des composants 111
¢ Héritage
Mécanisme permettant à une classe d’objets de
Ch.SAADI
bénéficier de la structure de données et du
comportement d’une classe "mère", tout en lui
permettant de les affiner et ce, afin de prendre en compte les
spécificités de la classe "fille", sans avoir cependant à
Génie logiciel
redéfinir ce que les deux classes ont de commun
¢ Généralisation
Dans le cas d’un héritage, on dit qu’une classe "mère" est
une généralisation des propriétés de ses classes "fille"
¢ Spécialisation
Dans le cas d’un héritage, on dit qu’une classe "fille" est
une spécialisation des propriétés de sa classe "mère"
112
¢ Encapsulation (interface)
Mécanisme permettant de dissimuler les détails du
Ch.SAADI
fonctionnement interne d’une classe aux autres classes
¢ Abstraction (classe abstraite)
Génie logiciel
Mécanisme permettant la dissociation entre la
déclaration d’une classe et son implémentation (interface)
¢ Polymorphisme
Mécanisme permettant d’associer à un comportement, une
implémentation différente en fonction de l’objet auquel on
se réfère (par exemple : dessiner à l’écran un carré ou un
cercle). L’émetteur n’a pas besoin de connaître la classe
du receveur, seulement que la sémantique du message
sera la même pour toutes les classes similaires (par
exemple : la méthode toString en JAVA, les injecteurs en 113
C++)
¢ Message
Mécanisme caractéristique des langages objet. Le message
est l’unique support de communication entre objets.
Ch.SAADI
L’arrivée d’un message provoque l’exécution d’une méthode
de l’objet
Génie logiciel
¢ Type d’accès, portée, visibilité
Public
Private
Protected
¢ Surcharge de méthode
Mécanisme permettant de déclarer plusieurs
constructeurs ou plusieurs fois une même méthode
(même nom) dans une classe, à condition que tous aient
une signature différente (valeur de retour et/ou 114
paramètres différents).
UML (UNIFIED MODELING LANGUAGE) :
¢ Auteurs
James Rumbaugh, Grady Booch et Yvar Jacobson
Ch.SAADI
¢ Objectifs
Faciliter la communication entre les différents acteurs
Génie logiciel
d’un projet
Faciliter la communication avec la machine
Documenter un projet de bout en bout
Spécifier et donc limiter les ambiguïtés
Construire (interpréter les diagrammes pour code)
¢ Définition
Langage de description des objets permettant une
modélisation rigoureuse des systèmes complexes
115
Langage Unifié pour la Modélisation objet
UML
Ch.SAADI
¢ Avantages d’UML :
Formel et normalisé (garantit stabilité et performance
d’un projet, réduit les risques)
Génie logiciel
Support de communication performant et éprouvé
(permet de cadrer l’analyse et de faciliter la
compréhension de représentations abstraites : c’est
« l’esperanto » de l’analyse)
¢ Inconvénients d’UML :
Période d’apprentissage
Processus de production non couvert
116
117
DIAGRAMMES UML
ORDONNANCEMENT DES DIAGRAMMES UML
Ch.SAADI
¢ 1. Découverte des besoins
Génie logiciel
Diagramme de cas d’utilisation : décrit les fonctions du
système (point de vue de ses futurs utilisateurs -
Jacobson)
Diagramme de séquence : représentation des

interactions temporelles entre objets dans la
réalisation d’une IHS
118
2. Analyse
Ch.SAADI
¢
Diagramme de classes : structure des données
Génie logiciel
Diagramme d’objets : illustration
Diagramme collaboratif : représentation des interactions

entre objets
Diagramme d’états : représentation du comportement

des objets d’une classe en terme d’états et de
transitions d’états
119
Diagramme d’activités : structure d’une opération en
actions
Ch.SAADI
¢ 3. Conception
Génie logiciel
Diagramme de séquence : représentation des interactions
temporelles entre objets dans la réalisation d’une
opération
Diagramme de déploiement : description du

déploiement des composants sur les dispositifs
matériels
Diagramme de composants : architecture des

composants physiques d’une application
120
POINT DE DÉPART: DÉCOUVERTE DES BESOINS
(SPÉCIFICATION)
Ch.SAADI
¢ Cette activité met donc en œuvre un mode de représentation
fonctionnel s’appuyant sur :
Génie logiciel
Les diagrammes de cas d’utilisation qui permettent
d’identifier et de formaliser les différents acteurs ainsi
que les services attendus de la future application.
La maquette pour sa part, permet de présenter de

manière concrète ces services via les IHM (Interface
Homme Machine) de l’application.
121
POINT DE DÉPART: SPÉCIFICATION
Ch.SAADI
Génie logiciel
122
EXEMPLE DE USE-CASE
Ch.SAADI
Génie logiciel
123
¢ Exemple de description pour le cas d’utilisation
s’authentifier
Ch.SAADI
Génie logiciel
124
¢ Exemple de maquette
Ch.SAADI
Génie logiciel
125
ANALYSE
¢ Étape intermédiaire entre la spécification des besoins et
la conception du système
èidentifier les classes de conception intervenant dans les
Ch.SAADI
diagrammes d’interaction du modèle conceptuel, deux sous étapes
sont nécessaires :
Génie logiciel
126
L’ANALYSE STATIQUE
Ch.SAADI
Modèle du domaine
¢ Construire le modèle du domaine. Sorte de glossaire
Génie logiciel
formalisé des concepts fondamentaux de l’espace du
problème, ce modèle fournit une partie des classes de
conception : celles correspondant directement aux
concepts métier manipulés par les experts du domaine
et les utilisateurs. Ces concepts, leurs attributs et leurs
relations vont être décrits en UML par des diagrammes de
classes simplifiées.
èC’est une représentation formelle d’un domaine de

connaissance avec plus de précision sur les comportements 127
Exemple :Modèle du domaine
Ch.SAADI
Génie logiciel
128
Ch.SAADI
Diagrammes de classes participants
¢ Construire les diagrammes de classes participants. Afin de
Génie logiciel
prendre en compte également l’IHM et la cinématique
de l’application, les diagrammes de classes participantes font
la jonction entre les cas d’utilisation, le modèle du
domaine, la maquette… et les diagrammes de conception
logicielle. Il s’agit de diagrammes de classes qui décrivent,
par cas d’utilisation, les trois principales classes d’analyse et
leurs relations.
129
¢ Les diagrammes de classes participantes :
Les classes de type dialogue : elles permettent les
Ch.SAADI
interconnections entre l’IHM et ses utilisateurs. Ce sont
typiquement les écrans proposés à l’utilisateur : les
formulaires de saisie, les résultats de recherche… Elles
proviennent directement de l’analyse de la maquette.
Génie logiciel
Les classes de type métier : elles représentent les règles
métier et proviennent directement du modèle du domaine
mais sont confirmées et complétées pour chaque cas
d’utilisation.
Les classes de type contrôle : elles contiennent la

cinématique de l’application et font la transition entre les
dialogues et les classes métier, en permettant aux
écrans de manipuler des informations détenues par un ou
130
plusieurs objets métier.
Ch.SAADI
¢ Exemple de diagramme de classes participantes:
Génie logiciel
131
L’ANALYSE DYNAMIQUE
¢ Le modèle dynamique permet de décrire :
Ch.SAADI
Pour chaque cas d’utilisation, la séquence des
Génie logiciel

interactions entre les acteurs et le système vue
comme une boîte noire, représentée par les diagrammes
de séquence système.
¢ è Ces diagrammes qui feront le lien entre les cas d’utilisation et

les diagrammes d’interaction du niveau conceptuel.
132
¢ Le modèle dynamique permet de décrire :
Ch.SAADI
Une manière formelle l’ensemble des chemins possibles
entre les principaux écrans proposés à l’utilisateur, et à
Génie logiciel
partir des informations fournies par la maquette, il reste à
détailler les diagrammes d’activités de navigation.
Si nécessaire, le cycle de vie commun aux objets d’une

même classe, peut être explicité par les diagrammes
d’états.
133
¢ Exemple de diagramme de séquence système pour le
CU s’authentifier
Ch.SAADI
Génie logiciel
134
¢ Exemple de diagramme d’activités de navigation
pour le CU s’authentifier :
Ch.SAADI
Génie logiciel
135
CONCEPTION DU SYSTÈME
Ch.SAADI
¢ La conception du système Cible Dans les activités de
conception, le modèle correspond aux concepts
Génie logiciel
informatiques utilisés par les outils, les langages ou les
plates-formes de réalisation.
¢ Le modèle sert ici à étudier, documenter,

communiquer et anticiper la solution logicielle.
136
137
CONCEPTION SYSTÈME
LA CONCEPTION DU SYSTÈME
Ch.SAADI
¢ Dans le cadre de systèmes orientés objet, la structure du code
Génie logiciel
est définie par des classes logicielles et leurs regroupements en
ensemble (appelés packages).
¢ La conception représente deux points de vue : la structure

statique et le comportement dynamique, deux
perspectives qui complètent la compréhension du système à
développer.
138
Ch.SAADI
¢ Le modèle statique, qui permet de décrire les différents
Génie logiciel
composants logiciels structurant le système, est représenté à
l’aide de diagrammes de classes de conception.
¢ Le modèle dynamique, permet quant à lui de décrire

l’attribution des bonnes responsabilités (services) aux bonnes
classes. Tout le comportement du système est ainsi réparti
entre les classes de conception. C’est le rôle des diagrammes
d’interaction (diagrammes de séquence ou de
collaboration) de représenter graphiquement ces décisions
d’allocation de responsabilités ainsi que les collaborations
induites.
139
¢ Exemple de diagramme de classes de conception de Struts :
Ch.SAADI
Génie logiciel
140
PRINCIPES FONDAMENTAUX EN GL
Ch.SAADI
• Séparation des problèmes
• Modularité
Génie logiciel
• Abstraction
• Anticipation du changement
• Généricité
• Construction incrémentale
141
SÉPARATION DES PROBLÈMES
Ch.SAADI
En pratique, plusieurs façons de faire :
Génie logiciel
¢ Séparation dans le temps (= ordonnancement)
¢ Séparation dans l’espace (= on se répartit les taches)
¢ Séparation des qualités (= priorités)
142
MODULARITÉ
Ch.SAADI
Génie logiciel
Ø Caractéristique d’un système, matériel ou logiciel, conçu en
séparant les fonctions élémentaires pour qu’elles
puissent être étudiées et réalisées séparément.
Ø Les modules sont des entités cohérentes qui peuvent

éventuellement être sorties du contexte et réutilisées.
143
ABSTRACTION
Ch.SAADI
¢ Opération qui consiste à isoler l’un des caractères de
quelque chose et à le considérer indépendamment des
Génie logiciel
autres caractères de l’objet.
¢ C’est un exemple de séparation des problèmes. On ne

considère à un instant donné que certains aspects du
système que l’on juge importants. On peut souvent
considérer plusieurs niveaux d’abstraction pour un même
système
144
ANTICIPATION DES CHANGEMENT
Ch.SAADI
La caractéristique essentielle du logiciel, par
rapport à d’autres produits, qu’il est presque toujours
soumis à des changements continuels, dus à des
Génie logiciel
corrections d’imperfections et/ou des évolutions en fonction
des besoins. Ceci requiert des efforts pour prévoir, faciliter
et gérer ces évolutions inévitables.
èIl faut :
q Faire attention à la modularité (localisation
des changements)
q Faire attention à la compatibilité entre

différentes versions d’un même module
145
GÉNÉRACITÉ
Ch.SAADI
Caractéristique générale qui permet d’englober une
classe d’objets dont chacun, pris séparément, reçoit une
Génie logiciel
dénomination spécifique.
Exemple: Siège est un terme générique d’une classe

comprenant la chaise, le fauteuil, le tabouret, etc..
Il peut être parfois utile de remplacer la résolution

d’un problème spécifique par la résolution d’un problème
plus général.
Des solutions génériques (paramétrables, adaptables)
sont plus facilement réutilisables. cf classes, héritage, 146
spécialisation
CONSTRUCTION INCRÉMENTALE
Ch.SAADI
Un procédé incrémental atteint son but par étapes,
en s’en approchant progressivement. Chaque résultat
Génie logiciel
intermédiaire est construit en étendant le précédent.
En pratique, on implémente d’abord un noyau

fonctionnel pour chaque module, qui inclut les fonctions de
base. Ce noyau est ensuite incrémenté petit à petit par de
nouvelles fonctionnalités.
147
148
4: CODAGE
CHAPITRE
CODAGE
Ch.SAADI
èL'objectif: transformer la conception d'un système en
Génie logiciel
¢
code avec un langage de haut niveau.
¢ Les programmeurs adhèrent a un style bien défini de codage

qui s’appel « standard de codage ».
149
CODAGE
Ch.SAADI
¢ Pour la mise en œuvre de notre conception en un code, nous
avons besoin d'un bon langage de haut niveau.
Génie logiciel
Une norme de codage assure une uniformité du code écrit
par différents ingénieurs
Il facilite la compréhension du code.
Favorise de bonnes pratiques de programmation
150
CODAGE : STANDARS ET GUIDLINES
Ch.SAADI
¢ 1.Contenu des en-têtes pour différents modules.
Voici quelques-unes (des données d'en-tête) standard :
Génie logiciel
Nom du module.
La date à laquelle le module a été créé.
Le nom de l'auteur.
Historique des modifications.
Différentes fonctions prises en charge, ainsi que leurs
paramètres d'entrée / sortie.
Les variables globales accessibles / modifiées par le module.
151
Ch.SAADI
¢ 2. Conventions de dénomination des variables globales,
variables locales et les identificateurs constants :
Génie logiciel
Une convention de nommage possible peut être que les noms
des variables commencent toujours par une lettre
majuscule, les noms de variables locales sont en
minuscule et noms constants sont toujours des lettres
majuscules.
¢ 3. Conventions de retour d’erreur et les mécanismes de gestion

des exceptions :
La façon dont les erreur sont signalées, par des fonctions
différentes dans un programme, devrait respecter la
norme au sein d'une organisation.
152
Ch.SAADI
¢ Autres directives de codage recommandées par de nombreuses
organisations de développement de logiciels.
Génie logiciel
1.Ne pas utiliser un style de codage trop difficile à
comprendre;
2.Ne pas utiliser un identifiant à des fins multiples (Chaque

variable doit avoir un nom descriptif indiquant son but).
èUtilisation de variables à des fins multiples rend

généralement les futures améliorations (les modifications)
plus difficile.
153
Ch.SAADI
¢ 3. Le code devrait être bien documenté : (usage des
commentaires)
Génie logiciel
¢ 4. La longueur de toute fonction ne doit pas dépasser 10
lignes de source : Une fonction qui est très long est
généralement très difficile à comprendre.
¢ 5. Ne pas utiliser les instructions goto : Utilisation des

instructions goto fait un programme non structuré et très
difficile à comprendre.
154
LA RÉVISION DU CODE
Ch.SAADI
¢ La Révision du Code à pour but d’avoir un module
développé, compilé avec succès on se débarrassant
Génie logiciel
de toutes les erreurs (de syntaxe).
¢ Les examens du code sont des stratégies très rentables

pour la réduction des erreurs de codage et pour produire un
code de haute qualité.
155
Auto-correction
Ch.SAADI
Inspection de code (desk-checking)
Génie logiciel
Technique d’examen du
code
Lecture croisée (author-

reader cycle)
Revue structurée
Code walk-through
156
RÉVISION DU CODE : CODAGE DESK-CHECKING
Ch.SAADI
Génie logiciel
¢ Auto-correction (desk-checking) :
c'est une relecture personnelle avec une efficacité

quasi nulle pour les documents amont, faible pour le code.
157
RÉVISION DU CODE : CODAGE AUTHOR-READER
Ch.SAADI
¢ Lecture croisée (author-reader cycle) :
Génie logiciel
un collègue qui cherche les ambiguïtés, les lacunes, les
incertitudes du code. L'efficacité de cette méthode est faible
pour les documents amont mais plus adapté pour la relecture
du code.
158
RÉVISION DU CODE : REVUE STRUCTURÉE
Ch.SAADI
¢ Revue structurée :
Génie logiciel
c'est la constitution d'une liste de défauts, pendant
un débat dirigé par un responsable, en utilisant une liste de
défauts typiques (checklist) cela a une bonne contribution à
l'assurance qualité
159
RÉVISION DU CODE : INSPECTION
Ch.SAADI
¢ Inspection :
C'est un cadre de relecture plus formel avec
Génie logiciel
recherche des défauts avant les débats et un bon suivi des
décisions et corrections cela a une excellente contribution à
l'assurance qualité
160
RÉVISION DU CODE : CODE WALK-THROUGH
Ch.SAADI
¢ On donne le code à des membres de l'équipe de
développement, quelques jours avant la réunion de
‘walkthrough’. Chaque membre sélectionne certains cas de
Génie logiciel
test et simule l'exécution du code à la main.
¢ Les membres notent leurs remarques à en discuter dans la

réunion où le ‘développeur’ du module est présent.
¢ Les principaux objectifs sont : découvrir les erreurs

algorithmiques et logiques dans le code.
161
RÉVISION DU CODE : CODAGE WALK THROUGH
Ch.SAADI
¢ Même s’elle est une technique d'analyse informelle,
plusieurs directives ont évolué au fil des ans pour faire de
cette technique d'analyse utile et plus efficace:
Génie logiciel
¢ L'équipe effectuant le walkthrough devrait par être ni
trop grand ni trop petit. Idéalement, il devrait être
composé de trois à sept membres.
¢ La discussion devrait se concentrer sur la découverte

d'erreurs et non pas sur la façon de corriger les erreurs
découvertes.
¢ Les Managers ne devraient pas participer à la réunion 162

walkthrough.
DÉFAUTS TYPIQUES
¢ 1. Référence aux données :
Ch.SAADI
Variables non initialisées
Indices de tableaux hors bornes
Génie logiciel
Accès à des structures/records à champs variables ou à des
unions
Confusion entre donnée et pointeur vers la donnée
Déréférence de pointeurs nuls
Pointeurs sur des données désallouées ou pas encore

allouées
Pointeurs sur des données devenues inutiles mais non 163
libérées
DÉFAUTS TYPIQUES
Ch.SAADI
¢ 2. Calculs :
Génie logiciel
Conversions de type (implicites et explicites)
Underflow/overflow (dépassement de capacité du type)
Division par zéro
Précédence des opérateurs
164
DÉFAUTS TYPIQUES
¢ 3. Comparaison :
Ch.SAADI
incohérence des types : mélanges d'entiers et de booléens
Génie logiciel
· inclusion ou non des bornes incorrecte :
< au lieu de <=, >= au lieu de >, …
· inversion du test : == au lieu de !=, > au lieu de <, ...
· confusion en égalité (==) et affectation (=) :

if (x = y) {...} au lieu de if (x == y) {...}:
165
DÉFAUTS TYPIQUES
¢ 4. Contrôle :
Switch : ensemble de case incomplet, cas default
Ch.SAADI
manquant, break oublié
Rattachement du else au if
Génie logiciel
Terminaison du programme : boucles et récusions sans
fin
Boucles : conditions initiales (indices, ...) incorrectes,

itérations en plus ou en moins,
incohérences après une sortie de boucle anticipée,

incohérences après une sortie de boucles emboîtées
Procédures et fonctions : incohérences après une sortie

166
anticipée
Exceptions non rattrapées

Agl DUT Chaimae Saadi

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agl DUT Chaimae Saadi

Transféré par

Droits d'auteur :

Formats disponibles

Ch.

¢ L’objectif principale est d’assurer et d’améliorer la

¢ Maitriser les techniques et les outils utilisés dans la production

¢ Développer une application selon une architecture distribuée

¢ Créer et déployer des services web

¢ Développer des applications sur des terminaux mobiles sur

Systèmes d’Information (BD)

Les données sont au centre du système :

Génie Logiciel= génie + Logiciel (Software engineering)

Quelles sont les activités fondamentales du génie logiciel?

D’après MC. Gaudel :

des projets utilisés tels quel

des projets Abandonnées

vFacile de gérer spécifications changeantes

vEn cas de retard, solution : ajouter des programmeurs

Pour répondre à cette crise, les chercheurs ont essayé d’appliquer

Il s’agit de se donner un cadre rigoureux pour :

PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

•L'origine de ce découpage provient du constat que les erreurs ont un coût

•Le Processus de développement logiciel permet de détecter les erreurs au

ØLes rôles, qui reflètent les responsabilités des personnes

ØLes pré-et post-conditions, qui sont des conditions vraies

•Une étape doit se terminer à une date donnée par la

•L'étape suivante n'est abordée que si les résultats sont jugés

•Coût de modification d'une erreur important, donc le

•Ce modèle est inadapté au développement de systèmes dont

•Problème de vérification trop tardive du bon

•Test d'acceptation et système : test du système complet par

•Recette : faite par le client, validation par rapport aux

Les activités de chaque phase peuvent être réparties en 5

Modèle très utilisé et éprouvé

•Le nombre de cycles est variable selon que le

-Développement de fonction inapproprié

- Le choix d’incrément est un compromis entre la durée de

- Les premiers incréments permettent de renforcer

-Les incréments doivent être aussi indépendants que

Le modèle en cascade ou en V est risqué pour les

Le modèle incrémental est risqué car il ne donne pas beaucoup

Souvent, un même projet peut mêler différentes approches,

l intégrer au cours du projet de manière continue le client final

¢ L’adaptation au changement plus que le suivi d’un

¢ Orientées client plutôt que processus

¢ Moins orientés documentation

¢ Le chef de projet établi alors un macroplanning

Cette méthode de gestion, ou plutôt ce Framework de

¢ Concentrer l’équipe, de manière itérative, sur un ensemble

Durée des itérations

-SCRUM suggère un mois

Définit l’ordre de développement des fonctionnalités

¢ Décide sur les orientations importantes du projet

¢ choisit la date et le contenu de la release

¢ accepte et rejette les résultats

Veille à résoudre les problèmes non techniques

¢ Veille à l’application des valeurs de Scrum

¢ regroupent tous les rôles: architecte, concepteur, analyste,

¢ Décisions prises ensemble

¢ se concentrent sur un sprint à la fois (sprint courant)

¢ Chaque Sprint a un but à atteindre

¢ Un Sprint aboutit sur la livraison d’un produit partiel

¢ La participation du client est déterminante pour le choix

ØIl ne doit pas nécessairement contenir toutes les

Øil va évoluer durant le projet en parallèle des besoins du client.

2. Nom – un nom court (entre 2 et 10 mots), descriptif de la

Par opposition, un destructeur est une méthode qui

Un itérateur est une méthode qui permet d’appliquer à

Diagramme de séquence : représentation des

Diagramme de classes : structure des données

Diagramme collaboratif : représentation des interactions

Diagramme d’états : représentation du comportement

Diagramme de déploiement : description du

Diagramme de composants : architecture des

La maquette pour sa part, permet de présenter de

Les classes de type dialogue : elles permettent les