Chapitre 1-GL2

Université Hassiba BenBouali- Chlef
Département Informatique
Introduction au Génie logiciel

Niveau: 3ème année licence Systèmes Informatiques
Module: Génie logiciel 2
Année Universitaire: 2019/2020

Génie logiciel: Défintions
➢ Ensemble des méthodes, des techniques et des outils dédiés à la

conception, au développement et à la maintenance des systèmes
informatiques de qualité avec maîtrise des coûts et délais.
Génie logiciel: Enjeux
Logiciel: Définitions
➢Ensemble d'entités nécessaires au fonctionnement d'un processus

de traitement automatique de l'information
Programmes, données, documentation...
➢Ensemble de programmes qui permet à un système informatique

d’assurer une tâche ou une fonction en particulier
Logiciel = programme + utilisation
Catégories des logiciels
Catégories des logiciels
Qualité d'un logiciel
Critères de qualité
● Validité : réponse aux besoins des utilisateurs
● Facilité d'utilisation : prise en main
● Performance : temps de réponse, débit...
● Fiabilité : tolérance aux pannes
● Sécurité : intégrité des données et protection des accès
● Maintenabilité : facilité à corriger ou transformer le logiciel
● Portabilité : changement d'environnement matériel ou logiciel
Critères de qualité d'un logiciel
Un logiciel bien fait est alors un logiciel:
• Correct(valide) • Facile à utiliser

• Fiable(robuste) • Maintenable
• Avec un code réutilisable • Ponctuel et Extensible
• Efficace
• Portable
Processus de développement d'un logiciel
Activités du développement logiciel
➢ Etude de faisabilité
➢ Spécification
➢ Organisation du projet
➢ Conception
➢ Programmation
➢ Test
➢ Livraison
➢ Maintenance
Pour chaque activité : Utilisation et production de documents
Étude de faisabilité
Comprendre les besoins du client
➢ Définition globale du problème

➢ Evaluation des stratégies possibles
➢ Evaluation des ressources, coûts et délais
􀂅 Documents: rapport d'analyse

Spécification
➢ Établir une description claire de ce que doit faire le logiciel
(fonctionnalités détaillées, exigences de qualité, interface…)
➢ Clarifier le cahier des charges en listant les exigences fonctionnelles

(opérations, etc) et non fonctionnelles (performance, portabilité,etc.
Organisation du projet
Déterminer comment on va développer le logiciel
➢Analyse des coûts: établir une estimation du prix du projet.

➢Planification: établir 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
Conception
1. Conception architecturale: décomposition et organisation de l'application
en composants plus simples (modules) définis par leurs interfaces
(fonctions et services offerts).
2. Conception détaillée: pour chaque module, description de la manière dont
les services et fonctions sont réalisés:
􀂅 algorithmes essentiels
􀂅 structures de données utilisées, etc.
Programmation
➢ Implantation de la solution conçue
Choix de l'environnement de développement, du/des langage(s)
de programmation, de normes de développement...
➢ Traduction de la conception dans un langage de programmation

Test
➢ Tests unitaires:
Tests avec les jeux d'essais par module selon le plan de test.
➢ Tests d'intégration:
Composition progressive des modules
Tests des regroupement de modules
➢ Test du système:
Test en vraie grandeur du système complet selon le plan de test global.
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.
Maintenance
Correction : identifier et corriger des erreurs trouvées après la livraison
Adaptation : adapter le logiciel aux changements dans l'environnement
(format des données, environnement d'exécution...)
Perfection : améliorer la performance, ajouter des fonctionnalités,
améliorer la maintenabilité du logiciel
Modèles de développement d'un logiciel
➢ La plupart des modèles des processus reprennent les activités fondamentales

mais les organisent différemment
➢ De nombreux modèles ont été définis:
❑ Modèles séquentiels
❑ Modèles itératifs
❑ Modèles séquentiels
Modèle en Cascade:
Considérer le développement logiciel comme une succession d’étapes réalisées

de façon strictement séquentielle
➢ Simple et facile à comprendre

➢ Chaque activité est validée par un document
Modèle
en
Cascade
Modèle en V:
Le cycle en V est un cycle de vie orienté test :

➢ A chaque activité créative (spécification, conception et codage)
correspond une activité de vérification (validation, intégration, tests
unitaires).
➢ Chaque phase en amont prépare la phase correspondante de vérification
(la vérification est prise en compte au moment même de la création).
Modèle en V
Modèle en V:
➢ La préparation des dernières phases par les premières (construction du

logiciel), permet d’éviter d’énoncer une propriété qu’il est impossible de
vérifier objectivement après la réalisation.
Problèmes des modèles séquentiels

Problèmes des modèles séquentiels

Coût des changements

Modèles itératifs
􀂅 Le développement itératif implique de découper un projet en un certain
nombre de cycles, ou itérations, au cours desquelles on prévoit de répéter
les mêmes activités.
􀂅 Le système s’agrandit progressivement,itération par itération
􀂅 A la fin de chaque itération, le résultat est testé comme un produit final
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
➢ 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
Modèle en spirale
Modèle en spirale
Attention centrée sur l’évaluation des risques
􀂅 RISQUE = ce qui met en péril processus et qualité.
➢ La défaillance de personnel : embauche de haut niveau, formation mutuelle
adéquation profil/fonction, ...
➢ Le calendrier et budgets irréalistes : estimation détaillée, réutilisation, ...
➢ Le développement de fonctions inappropriées : revues d’utilisateurs, manuel
d’utilisation précoce,...
➢ Les exigences démesurées par rapport à la technologie : analyses techniques de
faisabilité
Processus unifié rationnel (RUP)

➢ Le processus unifié rationnel (RUP) est également une combinaison de
cadres linéaires et itératifs.
➢ Le modèle divise le processus de développement logiciel en 4 phases:
création, élaboration, construction et transition.
➢ Chaque phase mais la création se fait généralement en plusieurs
itérations.
➢ Toutes les activités de base (exigences, conception, etc.) du processus de
développement sont effectuées en parallèle au cours de ces 4 phases
RUP, mais avec une intensité différente


➢ RUP est une démarche de développement qui est souvent utilisé
conjointement au langage UML
Il est :
❑ Piloté par les cas d'utilisation
❑ Centré sur l'architecture
❑ Itératif et incrémental
➢ RUP est itératif et incrémental:
❑ Chaque itération prend en compte un certain nombre de cas d'utilisation

❑ Les risques majeurs sont traités en priorité
❑ Chaque itération donne lieu à un incrément et produit une nouvelle
version exécutable
➢ RUP est centré sur l'architecture:

➢ RUP est piloté par les cas d'utilisation:
❑ La principale qualité d'un logiciel est son utilité (Adéquation du service

rendu par le logiciel avec les besoins des utilisateurs)
❑ Le développement d'un logiciel doit être centré sur l'utilisateur
❑ Les cas d'utilisation permettent d'exprimer ces besoins
1ère Phase: Création
Au cours de cette phase, l’équipe se réunit régulièrement pour déterminer

la nécessité du projet, mais aussi sa viabilité et sa pertinence. La viabilité et
l’adéquation incluent également les coûts prévus et les moyens nécessaires
pour mener à bien le projet

2ème Phase: Elaboration
Les objectifs de la phase d’élaboration sont:
➢ Analyser le problème
➢ Etablir une base architecturale solide
➢ Affiner le plan de projet
➢ Eliminer les éléments les plus risqués du projet.
3ème Phase: Construction
Au cours de la phase de construction, vous développez de manière itérative

et incrémentale un produit complet prêt à être transféré vers sa
communauté d'utilisateurs.
Cela implique de décrire les exigences restantes et les critères

d'acceptation, d'étoffer la conception et d'achever la mise en œuvre et les
tests du logiciel.
4ème Phase: Transition
L’objectif de la phase de transition est de transférer le produit vers son

nouvel utilisateur.
La transition vise à implémenter le système dans un environement de

production . Peut inclure des tests additionnels.

RUP aide à construire des solutions stables et flexibles, mais ce modèle n’est
pas aussi rapide et adaptable quand il s’agit d’un projet avec un délai limité où
il faut ajouter des fonctionnalités ou un complément de façon très rapide.
Le degré d'implication du client, l'intensité de la documentation et la durée des

itérations peuvent varier en fonction des besoins du projet.
Mais chaque étape n’est pas développée par une très grande quantité de
documentation comme les étapes de la méthode en cascade. Chaque phase est
plutôt développée par des représentations graphiques et des cas d’utilisation.
Groupe Agile
➢ Une méthode Agile est une approche itérative et collaborative, capable
de prendre en compte les besoins initiaux du client et ceux liés aux
évolutions.
➢ L'apparition des méthodes agiles est liée au fait que le client est souvent
dans l'incapacité de définir ses besoins de manière exhaustive dès le
début du projet. Le terme « agile » fait ainsi référence à la capacité
d'adaptation aux changements de contexte et aux modifications de
spécifications intervenant pendant le processus de développement.
Les objectifs des modèles agiles
❑ L’amélioration de la satisfaction du client

❑ La capacité à s’adapter et à accepter le changement
❑ La coopération au sein des équipes de développement
❑ La création efficace de logiciels opérationnels
❑ La simplification du processus de développement
❑ Une sortie plus rapide des produits et des mises à jour
Origine et valeurs des méthodes agiles

➢ Le mouvement des méthodes agiles est né en 2001 aux États-Unis. Devant
l’observation faite du taux important d’échec des projets, dix-sept
experts en développement logiciel, qui avaient chacun déjà mis au point
et expérimenté de nouvelles méthodes, se sont réunis afin d’échanger et
de trouver un socle commun de valeurs et de bonnes pratiques.
➢ Le résultat de cette réflexion a abouti au Manifeste pour le

développement logiciel agile et la création de l’Agile Alliance, chargée de
promouvoir l’agilité dans les organisations et d’apporter du soutien aux
équipes qui veulent démarrer un projet agile.
Les valeurs du Manifeste Agile

La méthode agile nommée Manifeste Agile repose sur quatre grandes valeurs:
➢ Les individus et leurs interactions plus que les processus et les outils
➢ Des logiciels opérationnels plus qu’une documentation exhaustive
➢ La collaboration avec les clients plus que la négociation contractuelle
➢ L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Les Principes Agiles

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement
et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le
projet.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques
semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble quotidiennement tout au long du projet.

5. Réalisez les projets avec des personnes motivées. Fournissez-leur
l’environnement et le soutien dont elles ont besoin et faites-leur confiance
pour atteindre les objectifs fixés.
6. Privilégiez la co-location de toutes les personnes travaillant ensemble et le
dialogue en face à face comme méthode de communication.
7. Un logiciel opérationnel est la principale mesure de progression d’un projet.
8. Les processus agiles encouragent un rythme de développement soutenable.

9. Une attention continue à l’excellence technique et à un bon design.
10.La simplicité – c’est-à-dire l’art de minimiser la quantité de travail
inutile – est essentielle.
11.Les meilleures architectures, spécifications et conceptions émergent
d’équipes auto-organisées.
12.À intervalles réguliers, l’équipe réfléchit aux moyens possibles pour
devenir plus efficace. Puis elle s’adapte et modifie son mode de
fonctionnement en conséquence.
Scrum
Scrum est une méthode de développement agile orientée projet

informatique. Elle tire son nom du monde du rugby, scrum = mêlée. Le
principe de base étant d'être toujours prêt à réorienter le projet au fil de son
avancement.
Scrum
Les projets qui suivent la méthode agile SCRUM sont divisés en plusieurs
cycles de travail relativement courts que l’on appelle « sprints ».
Les sprints peuvent durer de deux à quatre semaines. Ils permettent

également de réajuster ou réorienter la direction prise par le projet si
besoin.
Les projets qui utilisent la méthode SCRUM se forment autour d’une équipe
auto-organisée et multifonctionnelle.
Scrum
• L’équipe est auto organisée dans la mesure où il n’y a pas de chef d’équipe
qui décide des rôles de chacun, ou de la manière dont un problème est
résolu, puisque ces problématiques sont traitées par l’équipe dans son
ensemble ;
• L’équipe est multifonctionnelle car chaque membre de l’équipe est partie

prenante dans le développement de chaque fonctionnalité, de l’idée à
l’implémentation finale.
Scrum définit 3 rôles :

Le « Product Owner » qui porte
la vision du produit à réaliser
(représentant généralement le
client).
Le « Scrum Master » garant de
l'application de la méthodologie
Scrum.
L'équipe de développement qui
réalise le produit.
Planification du Sprint
-L'équipe de développement sélectionne les éléments prioritaires du «Product

Backlog » qu'elle pense pouvoir réaliser au cours du sprint (en accord avec le
« Product Owner »).
Une deuxième phase de planification permettra à la Scrum Team de décomposer

les items choisis en tâches formant la « Sprint backlog »
Execution du Sprint
Durant cette exécution, une Scrum (réunion) à lieu quotidiennement pour

contrôler le bon déroulement.
Durant le Sprint, le client est entièrement intégré et peut en tout temps modifier
le product backlog mais il ne peut pas modifier ce qui est en cours de
développement.
Un membre de l’équipe appelé le Scrum master s’assure que durant un Sprint

l’équipe de développement ne soit pas touchée par les perturbations extérieures.
Revue de Sprint :
A la fin du sprint, l'équipe de développement présente les fonctionnalités

terminées au cours du sprint et recueille les feedbacks du Product Owner et des
utilisateurs finaux.
C'est également le moment d'anticiper le périmètre des prochains sprints et

d'ajuster au besoin la planification de release (nombre de sprints restants).
La rétrospective qui a généralement lieu après la revue de sprint est l'occasion de

s'améliorer (productivité, qualité, efficacité, conditions de travail, etc).
Extreme Programming (XP)
➢ C'est la méthodologie agile la plus connue. Elle regroupe un ensemble de

bonnes pratiques de développement découlant des principes de l’agilité et
les poussent à l’extrême.
Par exemple: les tests sont utiles donc

Les tests seront effectués chaque jour
Les tests seront développés avant de coder
XP utilise un modèle de développement itératif avec itérations très courtes

( 1 à 3 semaines )
Pratiques de XP
➢Client membre de l'équipe

➢Jeu de planification/histroires d'utilisateurs
➢Programmation en paires
➢Développement piloté par les tests
➢Réusinage fréquent
➢Propriété collective du code
➢Intégration continue
Client membre de l'équipe

Le client est considéré comme un membre de l'équipe à part entière
➢ Le client est ultimement la personne qui devra utiliser le système,

➢ Un représentant du client devrait etre disponible en tout temps pour répondre
aux questions
Rôles du client
➢ Ecrire les histoires d'utilisateurs

➢ Ecrire les tests d'acceptation
➢ Choisir les histoires lors du jeu de la planification
Histroires d'utilisateurs
XP exprime les besoins sous d'histoires d'utilisateurs
▪ Les histoires ne contiennent que suffisamment d'information pour pouvoir estimer

l'effort requis pour développer une fonctionnalité
▪ L'estimé est produit rapidement pour permettre à l'équipe de prendre des

décisions
Les histoires sont généralement inscrites sur des cartes qui peuvent etre manipulées et
placés sur un mur ou tableau
Jeu de planification
Pour une itération

▪ Choisir les histoires à implémenter , planifier et allouer les tâches
▪ Le client choisit les cartes pour la prochaine itération, les
développeurs créent les tâches
▪ Une tâche qui estimée à >2 jours est divisée à nouveau
Programmation en paires
➢Tout code est écrit par une paire de programmeurs travaillant ensemble sur
une même machine
➢Les paires sont redistribuées fréquemment (Ex: une fois par jour)
Développement piloté par les tests
Le code de production est écrit de façon à faire réussir des tests unitaires
▪ Avant d'implémenter une fonctionnalité, un test est ajouté
▪ Un jeu de tests unitaires très complet est développé pour le système

entier
Réusinage fréquent
Améliorer le code sans changer sa fonctionnalité
➢ Idéalement effectué à l'aide d'outils automatisés
➢ Les tests existants permettent de vérifier que le comportement observable

demeure inchangé.
Intégration continue
Tous les changement doivent etre testés et intégrés fréquemment

Propriété collective du code
Une paire de programmeurs peut travailler sur n'importe quelle partie du code
et l'améliorer
➢ Les développeurs ne sont pas responsables d'un ou plusieurs modules en

particulier
➢ Si une partie du code est défectueuse, elle devrait être corrigée le plus tôt
possible.
Développement dirigé par test (Test Driven Developpement TDD)
La méthode traditionnelle de la rédaction des tests unitaires consiste à rédiger les

tests d'une portion d'un programme (appelé unité ou module ) afin de vérifier la
validité de l'unité implémentée.
➢ Quand les tests sont écrits après

codage, les choix d'implémentation
contraignent l'écriture des tests : les
tests sont écrits en fonction du code.
Développement dirigé par test (Test Driven Developpement TDD)

La méthode TDD quand à elle consiste à rédiger les tests unitaires avant de procéder à la phase de
codage
Ici, le développeur écrit un peu de code de test et

ensuite implémente le métier.
Le code métier est soumis aux tests puis il est
corrigé jusqu'a que ses tests soient validés. Le
développeur procède éventuellement ensuite à
un refractor du code permettant d'améliorer la
qualité interne du code.
Cycle TDD
Développement dirigé par comportement (Behavioral driven developpement

BDD)
BDD consiste à étendre le TDD en écrivant non plus du code compréhensible uniquement par des
développeurs, mais sous forme de scénario compréhensible par toutes les personnes impliquées
dans le projet.
Il s’agit d’écrire des tests qui décrivent le comportement attendu du système et que tout le
monde peux comprendre.
Ces scénarios sont écrits et définis avant que l’implémentation ne commence. Ils servent à la fois
à définir le besoin mais également vont guider le développement. Dans l’absolu, on continue à
faire du TDD mais on ajoute en plus l’expression du besoin en langage naturel.

BDD)
Un test en BDD consiste à décrire une fonctionnalité selon un formalisme « Given / When / Then ».
Chaque mot clé a une signification bien précise :
Given : La description, il permet généralement de décrire l'état initial

When : L'action, il s'agit des actions éffectuées(appel d'une méthode,...)
Then : La vérification, elle est présente pour vérifier que le résultat attendu(par exemple que le
message affiché contient bien tel message
Il y a également les autres mots clés And et But qui reprennent le mot clé de la ligne précédente et
ont donc pour but de clarifier le scénario

BDD)
Voici un exemple de scénario :

Chapitre 1-GL2

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

Chapitre 1-GL2

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassiba BenBouali- Chlef

Introduction au Génie logiciel

Année Universitaire: 2019/2020

➢ Ensemble des méthodes, des techniques et des outils dédiés à la

➢Ensemble d'entités nécessaires au fonctionnement d'un processus

➢Ensemble de programmes qui permet à un système informatique

Un logiciel bien fait est alors un logiciel:

• Correct(valide) • Facile à utiliser

Activités du développement logiciel

Comprendre les besoins du client

➢ Définition globale du problème

􀂅 Documents: rapport d'analyse

➢ Clarifier le cahier des charges en listant les exigences fonctionnelles

Déterminer comment on va développer le logiciel

➢Analyse des coûts: établir une estimation du prix du projet.

➢ Traduction de la conception dans un langage de programmation

Fournir au client une solution logicielle qui fonctionne correctement

❑ Installation : rendre le logiciel opérationnel sur le site du client.

➢ La plupart des modèles des processus reprennent les activités fondamentales

Considérer le développement logiciel comme une succession d’étapes réalisées

➢ Simple et facile à comprendre

Le cycle en V est un cycle de vie orienté test :

➢ La préparation des dernières phases par les premières (construction du

Problèmes des modèles séquentiels

Problèmes des modèles séquentiels

Coût des changements

Modèle en spirale (Boehm, 1988)

Processus unifié rationnel (RUP)

Processus unifié rationnel (RUP)

Processus unifié rationnel (RUP)

Processus unifié rationnel (RUP)

➢ RUP est itératif et incrémental:

❑ Chaque itération prend en compte un certain nombre de cas d'utilisation

Processus unifié rationnel (RUP)

➢ RUP est centré sur l'architecture:

Processus unifié rationnel (RUP)

➢ RUP est piloté par les cas d'utilisation:

❑ La principale qualité d'un logiciel est son utilité (Adéquation du service

1ère Phase: Création

Au cours de cette phase, l’équipe se réunit régulièrement pour déterminer

Processus unifié rationnel (RUP)

2ème Phase: Elaboration

Les objectifs de la phase d’élaboration sont:

3ème Phase: Construction

Au cours de la phase de construction, vous développez de manière itérative

Cela implique de décrire les exigences restantes et les critères

4ème Phase: Transition

L’objectif de la phase de transition est de transférer le produit vers son

La transition vise à implémenter le système dans un environement de

Processus unifié rationnel (RUP)

Le degré d'implication du client, l'intensité de la documentation et la durée des

Les objectifs des modèles agiles

❑ L’amélioration de la satisfaction du client

Origine et valeurs des méthodes agiles

➢ Le résultat de cette réflexion a abouti au Manifeste pour le

Les valeurs du Manifeste Agile

Les Principes Agiles

Les Principes Agiles

Les Principes Agiles

Scrum est une méthode de développement agile orientée projet

Les sprints peuvent durer de deux à quatre semaines. Ils permettent

• L’équipe est multifonctionnelle car chaque membre de l’équipe est partie

Scrum définit 3 rôles :