Intro Genie Logiciel by Efrem UNH Nov2022

GÉNIE LOGICIEL
(SOFTWARE ENGINEERING)
Efrem MBAKI LUZAYISU

Docteur en Sciences de l’Ingénieur
Business-Intelligence Analyst
contact@efremmbaki.com
PRÉLIMINAIRES
GÉNIE INDUSTRIEL (GI)
Le Génie Industriel est la science de

la conception, de la gestion, de
l’amélioration et l’installation de
systèmes complexes (intégrés)
DOMAINE D’ACTIVITÉS (GI)
A l’origine, le génie industriel

concerne : la conception et la gestion
des processus et des systèmes qui
améliorent la qualité et la
productivité de la chaîne logistique
des entreprises.
MISSION DE GENIE INDUSTRIEL
La mission principale est d'éliminer les

pertes de temps, d'argent, de
matériels, d'énergie et d'autres
matières premières des organisations.
Pour rationaliser et améliorer la
productivité et l'efficacité
EXEMPLES DE GENIE INDUS (1/3)
Rationaliser le fonctionnement d'une

salle d'opération;
Planifier des activités de distribution
de produits (vaccins, masques,…)
Améliorer et rationaliser le
fonctionnement d'une salle
d'opération;
Planifier des activités de distribution
de produits et l'organisation de
services dans le monde entier;
Organiser et gérer des équipes de

travail réparties sur plusieurs
continents pour la réalisation d'un
projet technologique
DÉFINITION – GÉNIE LOGICIEL (1/2)
Ensemble des méthodes, des

techniques et des outils dédiés à la
conception, au développement et à la
maintenance des systèmes
informatiques
DÉFINITION – GÉNIE LOGICIEL (1/2)
Le Génie logiciel est une science de

Génie industriel qui étudie les
méthodes de travail et les bonnes
pratiques.
Le génie logiciel s’intéresse en
particulier aux procédures qui
permettent de produire des logiciels
SYNONYMES
L’ingénierie logicielle
Ingénierie du logiciel
Software Engineering
BUT (1/2)
Présenter et utiliser des : Concepts,

Méthodes, Pratiques et Outils
permettant de maximiser les chances
de réussite d'un projet logiciel.
BUT (2/2)
Avoir des procédures systématiques

pour des logiciels de grande taille afin
que (sans être exhaustif) :
 la spécification corresponde aux besoins réels du
client
 le logiciel respecte sa spécification
 les délais et les coûts alloués à la réalisation
soient respectés.
ORIGINE
Science récente 1970

Augmentation de la puissance
matérielle a permis de réaliser des
logiciels plus complexes MAIS
souffrant de nouveaux DÉFAUTS :
délais non respectés, coûts de production et
d'entretien élevés, manque de fiabilité et de
performances
BUGS
 Démarrage de Site de Prise de RDV Vaccins

 VPN au démarrage de télétravail grande
entreprise
 Mission Vega : échec du lancement du satellite
français Taranis (Erreur de Trajectoire)
 Boeing 737 s'est crashé en Éthiopie 03/2019.
Les sondes qui détectent la vitesse du vent
seraient en cause, de même que les logiciels
utilisés par l'avion.
ENJEUX
Rationaliser et à Optimiser le Processus

de Production d’un Logiciel
 Adéquation aux besoins du client
 Respect des délais de réalisation prévus
 Maximisation des performances et de la fiabilité
 Facilitation de la maintenance et des évolutions
ultérieures
TRIANGLE D’EQUILIBRE
La réalisation
d'un logiciel est
soumise à des
exigences
contradictoires
et difficilement
conciliables
QUALITÉ (1/2)
Excellent Soin apporté à la réalisation

fonctionnelle et technique du projet.
Excellente spécification pour couvrir les
besoins présents et futurs identifiables
Excellente ergonomie adaptée
QUALITÉ (2/2)
Des performances homogènes

Une évolutivité étudiée
Une documentation complète (à chaque
release).
COÛT (1/2)
Un client dépense une certaine somme

pour son projet
 La valeur du projet peut éventuellement
s’adapter à un certain nombre de critères
 Mais il y a forcément un seuil au-delà
duquel il est impossible de le rentabiliser.
COÛT (2/2)
Le coût englobe aussi :

Les Frais d’Etude
Les Frais de Réalisation
Les Frais d’Exploitation
DÉLAI
Pas facile de déterminer le temps que dure

la réalisation d’un projet
Certains projets ne sont pas urgents, ni
même importants, mais ils comportent
forcément une deadline à partir de laquelle
ils deviennent caducs.
SOMMETS INTERDÉPENDANTS
Rapide et pas cher (Pressé et moins cher)

→ Mauvaise qualité
Rapide et de bonne qualité (Express)
→ Cher
Bonne qualité et pas cher (Pas prioritaire)
→ Lent
SOYONS RÉALISTE…
Ce qui n’existe pas, ou ne devrait pas

exister:
Rapide, de bonne qualité et pas cher
Lent, de mauvaise qualité et cher
OPTIMISER SURFACE
Sans être une solution miracle, le Génie

Logiciel a pour objectif de optmiser la
surface du triangle en tenant compte des
priorités du client.
RECTANGLE D’EQUILIBRE
CQFD est un sigle de Coûts,

Qualités, Fonctionnalités et Délais
Coûts Qualités
Délais Fonctionnalités
EQUILIBRE ERGONOMIQUE
Utilité : Ensemble des

Fonctionnalités/Services (Complétude)
Utilisabilité : Facilité dans exploitation
des fonctionnalités (Par ex. Application
Interactive User Friendly)
DIMENSIONS (1/3)
Le génie logiciel couvre l'ensemble du

cycle de vie d'un logiciel.
Il étudie toutes les activités qui
mènent d'un besoin à la livraison du
logiciel,
Y compris dans ses versions
successives, jusqu'à sa fin de vie.
DIMENSIONS (2/3)
Les dimensions du génie logiciel sont

donc multiples :
Analyse des besoins du client.
Définition de l'architecture du logiciel.
Choix de conception.
Règles et méthodes de production du
code source...
DIMENSIONS (3/3)
Gestion des versions.

Test du logiciel.
Documentation.
Organisation de l'équipe et
interactions avec le client.
...
OBJECTIFS
A la fin du cours l’étudiant doit être

capable de :
Définir les concepts de base
Identifier et pratiquer les étapes de
Développement d’un logiciel
 Comparer et appliquer les méthodes
de Génie Logiciel
PARADIGME PÉDAGOGIQUE
Learning by Doing
OUTILS PÉDAGOGIQUES
Exposés virtuels
Multiples Notes et Articles
Logiciels de conception et de
développement
Vidéos Explicatives
Web Campus
RÉFÉRENCES BIBLIOGRAPHIQUES
 Rédiger des cas d'utilisation efficaces, Alistair Cockburn,

Eyrolles, 27/07/2001
 Précis de génie logiciel Bruno Marre, Françoise Schlienger
et Gilles Bernot, Précis de Génie Logiciel, Dunod,
24/04/1996
 Culture agile: Manifeste pour une transformation
porteuse de sens et cohérente de l'entreprise, Jean-
Claude Grosjean, Publishroom, 8 novembre 2018
EVALUATION
Tests en Ligne
Interrogations
Travail en groupe
Examen écrit ?
EXERCICES
Qu’est-ce qu’un Système

d’information?
Qu’entendez-vous par l’imbrication
des Systèmes d’information?
Quel est le meilleur langage de
Programmation?
PROJETS(1/3)
Considérer les 3 projets suivants :

1. Implémenter un logiciel de gestion
pharmaceutique dans un hôpital
 2. Proposer une solution informatique intégrée
de gestion de taux de change dans une banque
 3. Gérer la prise des rendez-vous dans un
cabinet médical
PROJETS(2/3)
 Décrivez ces projets en précisant :

 L’objectif du projet
 Quelle utilité et quelle utilisabilité
 Quelle Qualité?
 Quel Coût?
 Quel Délai?
PROJET (3/3)
Une équipe de 5 personnes max

1 Client (+ Test)
1 Chef de Projet (+ Architecture)
1 Directeur Informatique (+ Maintenance)
1 Directeur Financier (+ IT, Soft+Hard)
1 Directeur de Help Desk (+Documentation)
100%
QUESTIONS
CYCLE DE VIE
CYCLE DE VIE
Désigne toutes les étapes du

développement d’un logiciel
De sa conception à sa disparition
Ces étapes incluent également les
potentielles mises à jour du logiciel,
une fois une version publiée
ETAPES(1/4)
 Définition des besoins:

→ Dans le langage du client
 Spécifications
→Traduction des besoins dans un langage plus
informatique, Ce que doit faire le logiciel (et non
comment il le fait)
ETAPES(2/4)
 Conception
→Traduction des spécifications en termes de
concepts logiciels
 Codage
 →Traduction de la conception en code
ETAPES(3/4)
 Tests unitaires
→Test de chaque module individuellement)
 Test d’intégration
→ Test de la composition de plusieurs modules)
 Test de Régression
→S’assurer que les modifications n’impactent
pas l’existant
ETAPES(4/4)
 Validation
 → Vérification bon logiciel ou pas
 Livraison / Diffusion
 Support, formation, Consultance
 Maintenance
 Evolution
→nouvelles versions, ....)
MODÈLES
Décrivent les liens, les relations

entre les différentes étapes du cycle
de vie du logiciel.
MÉTHODES
Permettent de mettre en œuvre un

développement logiciel selon un
modèle en organisant les différentes
étapes du cycle de vie du logiciel.
ANALYSE DE BESOIN
OBJECTIF
Analyser la situation pour tenir

compte des contraintes, des risques
et de tout autre élément pertinent
et assurer un ouvrage ou un
processus répondant aux besoins du
client.
POURQUOI ?
Eviter de développer un logiciel non

adéquat
Un produit avec une utilité et/ou une
utilisabilité non appropriée aux
besoins de l’utilisateur
COMMENT ?
Etudier le domaine d’application

Etudier l’état actuel de
l’environnement du futur logiciel
afin d’en déterminer : les frontières,
le rôle, les ressources disponibles et
requises, les contraintes d’utilisation
et de performance
PARTICULARITÉS (1/2)
Les données/ Informations sont

fournies par :
→ les experts du domaine d’application
→ les futurs utilisateurs
L’équipe du développement doit établir
le dialogue avec ces « spécialistes »
(souvent non-informaticiens)
PARTICULARITÉS (2/2)
Les méthodes utilisées ne relèvent pas

directement de l’informatique mais
des sciences cognitives :
Entretiens,
questionnaires,
observations de l’existant,
études de situations similaires, …
QUAND?
Au début du processus (mais aussi durant tout

le processus car des questions relatives aux besoins et à
l’environnement peuvent apparaître à tout moment
durant le cycle de vie)
En liaison avec :
 →les études de faisabilité et
 →la planification
ACTIVITÉS
Connaître le contexte
Déterminer les besoins et les
contraintes;
Déterminer les paramètres de
conception;
Préparer le cahier des charges.
CONTEXTE (1/2)
Comprendre le contexte du moment et

d’obtenir de l’information
supplémentaire permettant d’en élargir
les horizons ou de tenir compte des
considérations futures..
CONTEXTE (2/2)
Poser des questions

Prendre des mesures
Chercher information supplémentaire
en se documentant sur le sujet
Si possible, Visiter le site et/ou tester
l’existant
BESOINS ET CONTRAINTES (1/4)
Une fois mis en perspective avec le

contexte, les besoins réels du client
permettent de redéfinir ou de valider
les attentes
L’informaticien devrait structurer les

besoins par degré d’importance ou
par thèmes, afin de mieux cerner à
quelle étape de la conception ces
besoins doivent être pris en compte.
Collaborer avec le client pour établir

les contraintes susceptibles de nuire
à l’atteinte des objectifs
Il ne faut pas se limiter aux

contraintes physiques, techniques et
économiques.
Elargir sa vision et tenir compte des
contraintes environnementales,
humaines, sociales, légales et de tout
autre élément pertinent.
LES PARAMÈTRES (1/3)
Déterminer les paramètres de

conception à partir des mesures prises :
→sur le site et/ou l’existant,
→de l’information technique disponible
→de son expérience.
Il faut être réaliste quant au nombre

de paramètres
Il faut parfois regrouper les
paramètres par types ou par besoins
Il faudrait également considérer le

développement durable comme un
critère de conception en soi, tant au
stade de l’ingénierie préliminaire
qu’à celui de l’ingénierie détaillée.
LE CAHIER DES CHARGES (1/3)
Les étapes précédentes permettent

de proposer au client un cahier des
charges réaliste et convenant à ses
besoins, dans lequel il décrit de façon
claire et précise les tâches à effectuer
et une évaluation du temps pour les
accomplir.
De plus, cet exercice permet à

l’informaticien d’évaluer
adéquatement l’envergure du
mandat de conception et de vérifier
s’il a toutes les compétences pour le
réaliser ou s’il devra recourir à des
ressources externes, en accord avec
son client.
TO DO
Réaliser le cahier des charges du projet

d’e-Sandwicherie Universitaire
100%
QUESTIONS
SPÉCIFICATION GLOBALE
DÉFINITION
Spécification = ce que doit faire le

logiciel, ensemble de critères que
doivent satisfaire son fonctionnement
interne et ses interactions avec son
environnement.
DÉFINITION
Les spécifications (fonctionnelles) sont

une section du cahier des charges ou
un document à part entière qui
spécifie, décrit, précise les
fonctionnalités du site, de l'application
ou du logiciel en question.
BUT
Etablir une première description du

futur système
Cette activité est corrélée avec
l’analyse des besoins
ATTENTION
Décrire ce que doit faire le logiciel

(sans se soucier de comment le faire).
Eviter de faire des choix prématurés /
d’anticiper concernant
l’implémentation
TYPES (1/4)
Les spécifications informelles, par

exemple un texte en français.

TYPES (1/4)
Les spécifications informelles, par

exemple un texte en français.
•
TYPES (2/4)
Les spécifications semi-formelles

avec une syntaxe plus précise
TYPES (3/4)
Les spécifications formelles qui

présentent une syntaxe et une
sémantique (Langage B).
TYPES (4/4)
La notation « ad-hoc » : un schéma

selon les conventions établies
seulement par le rédacteur du
document.
Par exemple, UML ou ERA
PECHES (1/7)
Le bruit: information non nécessaire

au moment où elle est donnée
Eléments qui n'apportent rien d'utile
à la description du problème
PECHES (2/7)
Le silence: notions introduites sans

définition (un peu comme une non-
déclaration de variable)
« Pêché d'omission », lorsque des
éléments du problème ne sont pas
évoqués
PECHES (3/7)
La contradiction: des parties de texte

peuvent entrer en conflit avec ce qui a
été énoncé auparavant.
PECHES (4/7)
La sur-spécification : en dire trop.

Quand la description du problème
contient des éléments de la solution
 Par exemple, Traiter d'implémentation
alors qu'on n'a pas spécifié la fonction
que l'on veut implémenter
PECHES (5/7)
L'ambiguïté : c'est-à-dire un énoncé à

interprétations multiples
La contradiction : des parties de texte
peuvent entrer en conflit avec ce qui a
été énoncé auparavant
PECHES (6/7)
La référence en avant :

(n'est pas forcément mauvaise !), on
mentionne des concepts dont la
définition sera fournie plus loin.
 Description du problème contient des
éléments qui n'ont pas encore été
définis
PECHES (7/7)
La repentance :
Certains éléments du problème sont
décrits top tardivement, ou sont
simplement rapidement évoqués en fin
de spécification.
COMPLÉTUDE
Lister de manière aussi exhaustive que

possible les fonctionnalités dont vos
utilisateurs auront besoin pour se servir
du logiciel
COMPLÉTUDE
Lister de manière aussi exhaustive que

possible les fonctionnalités dont vos
utilisateurs auront besoin pour se servir
du logiciel
MÉTHODES
Impact Mapping
Diagrammes UML
Diagramme ERA
IMPACT MAPPING - DÉFINITION
Se poser une succession de bonnes

questions préétablies :
IMPACT MAPPING - QUESTIONS
Quel est l'objectif de mon logiciel ?

Quels sont les profils des utilisateurs ?
Quelles actions cherchent-ils
respectivement à faire?
Quelles fonctionnalités ont-ils besoin ?
IMPACT MAPPING - RÉPONSES
En répondant à ces questions de

manière systématique, on aboutit à
une cartographie des usages supposés
du site
IMPACT MAPPING - EXEMPLE
UML – USE CASE
TO DO
Appliquer l’Impact Mapping au projet

d’e-Sandwicherie Universitaire
Proposer la hiérarchie de votre
application
Construire tous les cas d’utilisations
%
QUESTIONS
SATISFACTION DU CLIENT
SLOGAN
Les clients satisfaits sont des clients

heureux!
ATTENTE POSITIVE
La satisfaction survient toujours lorsqu’une

attente positive se concrétise
 Si les attentes sont même dépassées, la
satisfaction augmente encore plus
Mais si les souhaits et les espoirs ne se
réalisent pas, on est inévitablement
insatisfait
QU’IMPORTE LE DOMAINE
Cela vaut aussi dans le contexte de la vente

et du commerce, la production, …
 Pour cela, le client doit avoir le plus
d’expériences positives tout au long du
parcours client (Customer Journey)
PSYCHOLOGIE DU CONSOMMATEUR
La satisfaction client est une question de

lien entre les entreprises et les personnes,
et fait donc partie intégrante de la
psychologie du consommateur
BUT
Améliorer l’expérience du client et envoyer

de nombreux signaux positifs que ce soit
avant, pendant ou après l’achat
COMMENT ? (1/2)
Plusieurs facteurs sont importants:

des bons produits et services
des prix raisonnables jouent un rôle central
 le conseil, le service clientèle efficace
COMMENT ? (2/2)
Conception de la boutique en ligne

Click & Collect
Show Room
…
COMMENT ? (2/2)
Conception de la boutique en ligne

Click & Collect
Show Room
…
ENQUÊTE
Afin de mesurer la satisfaction client, des

enquêtes régulières sont alors nécessaires.
 Ce n’est en effet qu’à partir des réponses et
des avis des clients que l’on peut estimer le
niveau de satisfaction et quels points
doivent être améliorés ou réétudiés.
ENQUÊTES RÉGULIÈRES
Afin de mesurer la satisfaction client, des

enquêtes régulières sont alors nécessaires.
 Ce n’est en effet qu’à partir des réponses et
des avis des clients que l’on peut estimer le
niveau de satisfaction et quels points
doivent être améliorés ou réétudiés.
PARADIGME DE CONFIRMATION (1/2)
La satisfaction client peut s’expliquer par le

phénomène ou paradigme de
confirmation/disconfirmation également
nommé paradigme de confirmation des
attentes.
PARADIGME DE CONFIRMATION (2/2)
Ce phénomène implique la comparaison

entre la qualité perçue et la qualité
attendue
QUALITÉ ATTENDUE
La qualité attendue est déterminée par les

souhaits et les attentes (dont les désirs
émotionnels) du client
QUALITÉ PERÇUE
La qualité perçue est constituée de l’état

actuel du produit, du service et de
l’entreprise.
ECART
Le désir du client (qualité attendue) est

comparé au niveau de performance
(qualité perçue).
La satisfaction du client va alors résulter de
l’écart
ECART NÉGATIF
Qualité perçue < qualité attendue

Si les attentes des clients ne sont pas
satisfaites, il en résulte de l’insatisfaction et
on parle de « disconfirmation » négative.
ECART NEUTRE
Qualité perçue = qualité attendue

Dans le cas de la correspondance entre les
deux, quand les attentes du client
correspondent exactement à l’état du
produit (la performance). Il en résulte la
satisfaction du client.
ECART POSITIF
Qualité attendue < qualité perçue

 Si la performance de l’entreprise dépasse
les attentes du client.
On parle alors d’une «disconfirmation »
positive, d’une satisfaction client forte
QUELLE IMPORTANCE ? (1/4)
Chaque entreprise vise le profit,

c‘est-à-dire qu'elle souhaite générer le
chiffre d’affaires le plus élevé possible au
coût le plus bas possible.
QUELLE IMPORTANCE? (2/4)
Cela n’est évidemment pas possible sans

des clients qui achètent des produits et
utilisent des services
C’est pourquoi il est important de susciter

l’intérêt des clients pour votre offre (rôle
du marketing classique) et de le conserver
même après le premier achat.
Si le client est satisfait de son achat et

globalement de l’entreprise, il envisagera
alors un nouvel achat.
Et devient un des ambassadeurs de la
marque
EFFETS POSITIFS ? (1/4)
Loyauté client : un client satisfait

exprimera un certain degré de loyauté
envers votre entreprise et se tournera à
nouveau vers l’un de vos produits lors de sa
prochaine décision d’achat. Et cela
également pour une gamme de produits
différente.
Fidélité client : si un client est

constamment satisfait, il s’engage alors
volontairement et achète vos produits ou
services sans tenir compte d’autres acteurs
du marché
Peu de sensibilité au prix : le client satisfait

ne se détourne pas du produit ou du service
même si les prix augmentent légèrement.
Recommandable : un niveau de
satisfaction élevé de la clientèle garantit le
fait que les clients recommandent vos
offres et produits à leur famille et amis ou
même sur les réseaux sociaux.
EFFETS NÉGATIFS ? (1/3)
Plainte : un client insatisfait peut vous

adresser son mécontentement directement
et avoir besoin d’une attention
supplémentaire pour changer à nouveau
d’avis.
Perte : si l’insatisfaction est trop grande,

votre entreprise ne joue alors plus aucun
rôle dans les décisions d’achat.
Communication négative : les expériences

négatives sont partagées.
Les clients insatisfaits utilisent de plus en
plus Internet et les réseaux sociaux pour
noter, avertir ou exprimer un
mécontentement fort dans le but de faire
fuir de nouveaux clients.
NET PROMOTER SCORE (NPS) (1/3)
NPS est Un indicateur de mesure de fidélité

de la clientèle qui est fortement liée à la
satisfaction client,
Une seule question est posée au client :

« quelle est la probabilité que vous
recommandiez
l’entreprise/marque/produit à un
ami/collègue/membre de la famille ? ».
Le client peut évaluer la probabilité de :

 0 (très peu probable)
 à 10 (très probable)
La balance est divisée en deux parties :
tous les répondants qui ont choisi 9 ou 10
sont considérés comme des « promoteurs »
ou des ambassadeurs de marque.
Les clients qui ont obtenu 7 ou 8 points

sont estimés comme des « passifs », c’est-
à-dire qu’ils sont indifférents
Enfin, tous les autres sont considérés
comme des « détracteurs » (des critiques).
CUSTOMER SATISFACTION SCORE
(CSAT) (1/3)
CSAT un indicateur qui reflète la

satisfaction globale.
Dans un sondage comportant des questions
normalisées, on demande aux clients
d’évaluer leur satisfaction en fonction de
certains facteurs
(CSAT) (2/3)
Par exemple, allant de

 1 (très insatisfait)
 à 5 (très satisfait).
Pour calculer le Customer Satisfaction Score,
seules les deux valeurs les plus élevées (4 ou
5) sont remises en question
(CSAT) (3/3)
Toutes les réponses des clients satisfaits.

Le montant de ces réponses est divisé par
le nombre de questionnaires remplis, puis
multiplié par 100.
Le résultat indique quel pourcentage de
vos clients est satisfait des services reçus.
GESTION DES EXIGENCES
SYNONIMES
La gestion des exigences, également

appelée :
 REQUIREMENTS ENGINEERING
 REQUIREMENTS MANAGEMENT
DEUX PARTIES
La discipline inclut :

1. la définition des exigences
(l’analyse, la documentation et la
validation des exigences)
2. la gestion des exigences (gestion
des risques, des modifications et de
la mise en œuvre).
OBJECTIF
Veiller à satisfaire les exigences des

clients, mais aussi des parties
prenantes internes et externes pour le
produit à élaborer.
SOUVENT PRESSÉ
Une fois le budget fixé, l’objectif décrit

et le délai défini, les entreprises se
dépêchent souvent de passer
directement à la mise en œuvre du
logiciel
PRENDRE LE TEMPS
Prendre un peu de temps pour

rassembler de façon systématique les
exigences de toutes les parties
prenantes pour le produit souhaité et
en gérer les spécifications.
PRISE EN COMPTE TARDIVE
Les exigences définies initialement

sont uniquement intégrées au produit
final dans la majorité des projets
informatiques.
OPTIMISER
Une perte de temps et de budget qui

peut être évitée avec une gestion des
exigences structurée
PAS UNE TACHE UNIQUE
Il ne s’agit donc pas d’une tâche unique

que l’on réaliserait au début d’un projet
 Mais bien d’une suite de processus
récurrents qui s’étendent sur toute la
durée du projet
A QUI LA RESPONSABILITÉ?
L’Ingénieur de gestion des exigences

(Requirements Engineer)
 Surveille la mise en œuvre et
l’intégration des exigences et des
modifications ainsi que le cours du
projet qui en découle
NÉGLIGENCE ?
La gestion des exigences informatiques

est relativement bien établie dans le
secteur (Industrie) des technologies
Mais un peu négligée dans le
développement des logiciels où
l’accent est mis sur les outils et les
techniques
PERTINENCE
Si l’on ne définit pas clairement

d’entrée de jeu ce que le logiciel à
développer doit être en mesure de
réaliser et quels processus il doit
supporter, on peut s’attendre à des
problèmes dans la suite du processus
EFFETS SUR LA DURÉE
Toute planification du temps et des

ressources effectuée sans tenir
compte des exigences ne saurait être
réaliste et il y a alors fort à parier que le
projet s’éternisera
EFFETS SUR LE BUDGET
sans tenir compte des exigences, le

budget sera certainement dépassé
En effet, une mauvaise gestion des
modifications souhaitées entraîne
davantage de dépenses.
SOURCE D’EFFICACITÉ
Dans les projets d’envergure portant

en particulier sur des produits
complexes, elle permet de maintenir
l’efficacité à un niveau élevé tout au
long du projet et d’éviter les erreurs et
les désaccords entre les partenaires du
projet
ANTICIPATION CONTROLÉE
Les problèmes provenant d’un

changement dans les souhaits du client
ou d’un autre partenaire peuvent être
gérés de façon anticipée par un
ingénieur de gestion des exigences qui
définira des mesures afin d’en atténuer
les effets négatifs.
DÉRANGER LE CLIENT
Aider le client a consacré des efforts

plus importants pour spécifier plus en
détail les exigences, une gestion des
exigences structurée favorise la
satisfaction du client.
AVANTAGES (1/3)
1. une plus grande efficacité du projet

2. moins de modifications au cours du
projet
3. moins d’erreurs et de désaccords
AVANTAGES (2/3)
4. une identification précoce des

problèmes et des modifications
nécessaires
5. des coûts de projet plus faibles, les
coûts dus aux erreurs pouvant être
évités
AVANTAGES (3/3)
6. un projet achevé dans les temps et

en respectant le budget
7. une plus grande satisfaction du client
TO DO
Rappeler les méthodes/techniques de

capture des exigences du client.
Comment pensez-vous organiser la
gestion des exigences dans le cadre du
projet d’e-Sandwicherie Universitaire
Expliquer clairement vos
stratégies/démarches
%
QUESTIONS
RÉUSSIR SA CONCEPTION
BUT
Enrichir la description du logiciel de

détails d’implémentation afin
d’aboutir à une description très proche
d’un programme
Une étape particulièrement cruciale du
développement logiciel
FRONTIÈRE FLOUE
La frontière entre la spécification et la

conception est floue
Dans des nombreux contextes, il existe
des contraintes de réalisation qui
amènent à anticiper sur la conception
au moment de la spécification
COMMENT?
Le modèle d'architecture ne décrit pas

ce que doit réaliser un système
informatique mais plutôt comment il
doit être conçu de manière à répondre
aux spécifications.
COMMENT FAIRE
L'analyse fonctionnelle décrit le « quoi

faire » alors que l’architecture décrit le
« comment le faire »

FAISABILITÉ
Le fait que la conception soit possible

démontre la faisabilité
De cette phase, va dépendre la
stabilité, la robustesse ou encore la
scalabilité d'une application.
DEUX PHASES
Elle se déroule souvent en deux phases

1. Conception architecturale
2. Conception Détaillée
CONCEPTION ARCHITECTURALE
Décomposer le logiciel en composants

plus simples
Préciser les interfaces et les fonctions
de chaque composant
ARCHITECTURE (1/2)
Liens logiques et fonctionnels entre

les composants
 un ensemble de spécifications pour
chaque composants
ARCHITECTURE (2/2)
La manière dont le logiciel est conçu,

autrement dit la manière dont les
différents éléments qui le composent
et qui lui permettent de fonctionner
sont agencés
CONCEPTION ARCHITECTURALE
Décomposer le logiciel en composants

plus simples
Préciser les interfaces et les fonctions
de chaque composant
ENJEUX
Compte tenu des enjeux techniques et

financiers qui pèsent sur les logiciels
utilisés par les professionnels, il est plus
que conseillé de les choisir
soigneusement
ENSEMBLE FONCTIONNEL
Tout comme l’architecture d’un

bâtiment ou d’un système mécanique ,
il est essentiel que chaque pièce soit à
sa place et puisse remplir son rôle afin
que tout l’ensemble soit parfaitement
fonctionnel et performants
VARIETE
L’architecture des logiciels varie en

fonction de leur usage
En plus des performances du logiciel,
plusieurs autres éléments sont à
prendre en compte dans la conception
de l’architecture
MANIABLE ET SIMPLE
Le produit final devra être maniable et

simple à prendre en mains et être assez
souple et évolutif pour permettre la
réalisation des futures releases.
FIABLE ET COMPATIBLE
Il doit aussi être fiable et compatible

avec d’autres outils potentiellement
plus anciens ou plus récents.
FAIBLE COÛT
Les coûts de réalisation et

d’exploitations devront également
être abordables
SOURCE DE QUALITÉ
La qualité d’un système IT ou d’un

logiciel est tributaire de celle de
l’architecture de l’application
La qualité du code peut être évaluée
par un certain nombre de mesures
appelées métriques de code : indice de
maintenabilité, complexité
cyclomatique, etc.
PEUT ENTRAINER L’INSTABILITÉ
Une application mal structurée est

sujette à une instabilité et à une
défaillance permanente même dans le
cas où il serait possible de la mettre à
jour en vue d’éventuelles corrections.
IL FAUT AUSSI TENIR COMPTE DE
De performance
De sécurité
Mais également les contraintes
d’exécution et d’exploitation.
CONTRAINTES D’EXÉCUTION (1/4)
Les plates-formes visées côté client et

serveur.
L’hébergement attendu : Cloud privé
et/ou public, OnPremise ou alors SaaS (
un hébergement hybride, qui est
aujourd’hui plus populaire)
les systèmes d’exploitation.

le choix des technologies : certains
choix architecturaux sont couplés à
leur environnement d’exécution
comme cela peut-être le cas avec le
Serverless.
A l’inverse, une architecture

Microservices se veut agnostique
quant aux technologies utilisées
(Agnosticisme informatique)
le besoin de résilience du système.
La typologie matérielle des écrans. En

particulier, la taille des écrans pour
utiliser l’application – encore appelé
« Form Factor » – impacte la
conception de l’IHM.
MAIS ENCORE… (1/2)
Est-ce que le logiciel doit répondre

rapidement ?
Quel volume de données doit-il traiter ?
 Mais permet également se savoir si ces
données doivent-elles être centralisées
ou réparties ?
MAIS ENCORE… (2/2)
Comment les utilisateurs doivent-il

accéder à l’application du point de vue
du réseau ?
Sur quel type de matériel ?
En quelle langue ou avec quel type de
clavier ?
UNE BONNE ARCHITECTURE
EVOLUTIVITÉ
 Prendre en compte des évolutions

futures du logiciel en fonction du
besoin métier.
Anticiper les évolutions en étant assez
souple pour qu’elles soient possibles,
sans tomber dans le piège de vouloir
prévoir démesurément le futur.
SIMPLICITÉ (1/3)
Une architecture complexe est souvent

source de défaillance et peut créer de
la dette technique, impacter les
performances ou l’évolutivité d’une
application.
SIMPLICITÉ (2/3)
Elle est due à une mauvaise

conception, une sur-ingénierie initiale
ou à l’inverse un manque de conception
global qui induit une complexification
progressive du logiciel dans le temps.
SIMPLICITÉ (3/3)
De plus, le logiciel doit avoir une

architecture « compréhensible » pour
faciliter sa prise en main. Pour cela, il
est nécessaire de :
respecter les standards afin qu’il soit
possible pour une personne ne
MAINTENABILITÉ
Une bonne architecture intègre aussi

l’outillage nécessaire à sa
maintenance.
Cela permet notamment de récupérer
de l’information de manière centralisée
lorsqu’il y a une erreur afin de pouvoir
la traiter efficacement et d’agir en
conséquence.
COMPATIBILITÉ :
L’architecture doit définir le

compatibilité du logiciel avec les
différentes plates-formes matérielles,
systèmes d’exploitation, navigateur
ou taille d’écran qui conviennent à la
cible d’utilisation..
INTERCONNECTIVITÉ (1/2)
Puisque le logiciel évolue dans un

certain environnement, son
architecture doit permettre son
interconnectivité avec d’autres
systèmes d’information.
INTERCONNECTIVITÉ (2/2)
Il est de plus en plus rare de trouver un

logiciel totalement isolé des autres
applications et ne nécessitant pas des
interfaces de données ou a minima des
exports...
TYPES D’ARCHITECTURE
TYPES (2/2)
Il existe de nombreux types

d'architectures d'applications
différents, au sein desquelles les
relations entre les services sont plus ou
moins couplées :
TYPES (2/2)
Les architectures monolithiques et

multiniveaux (étroitement couplées),
les architectures de microservices
(découplées) et les architectures
orientées événements ou services
(faiblement couplées).
STAND-ALONE (1/3)
Un système entier (application,

ordinateur, matériel, réseau), qui n'a
pas de lien avec l'extérieur et qui est
auto-suffisant
Qui n'a pas besoin d'un acte ou d'une
information extérieur pour
fonctionner.
Ni un plug-in ni un add-on
STAND-ALONE (2/3)
Un ordinateur stand-alone signifie qu'il

n'est pas relié à un réseau ou à Internet
Un réseau est standalone lorsqu'il n'est
pas possible de communiquer vers
l'extérieur.
ARCHITECTURE N-TIER (1/11)
Tier : étage, niveau

 Ou Multi-tier
 Est une architecture client-serveur
dans laquelle une application est
exécutée par plusieurs composants
logiciels distincts.
Exemple d’architecture 3-tier

Tier de présentation : interfaces
utilisateurs sur un PC, poste de travail,
qui s’adressent à des applications
serveur

Tier des règles de gestion :
applications serveur qui contiennent la
logique de gestion et accèdent aux
données stockées dans des bases de
données

Tier de base de données : serveurs de
bases de données
Avantages :
Le lien entre les niveaux est défini et
limité à des interfaces
Les interfaces assurent la modularité
et l’indépendance technologique et
topologique de chaque niveau

Les couches d’une architecture 4-tier :

La couche de présentation contient les
différents types de clients, léger (ASP,
JSP) ou lourd (Applet)
La couche applicative contient les
traitements représentant les règles
métier (créer un compte de facturation,
calculer un amortissement ... )

La couche d'objets métier est
représentée par les objets du domaine,
c'est à dire l'ensemble des entités
persistantes de l'application (Facture,
Client ... )

La couche d'accès aux données
contient les usines d'objets métier, c'est
à dire les classes chargées de créer des
objets métier de manière totalement
transparente, indépendamment de leur
mode de stockage (SGBDR, Objet,
Fichiers, ...)
La valeur ajoutée des architectures N-

Tier :
Cette séparation par couches de
responsabilités sert à découpler au
maximum une couche de l'autre afin
d'éviter l'impact d'évolutions futures de
l'application.
La valeur ajoutée des architectures N-

Tier :
Par exemple : si l’on est amené à devoir
changer de base de données relationnelle, seule
la couche d'accès aux données sera impactée, la
couche de service et la couche de présentation ne
seront pas concernées car elles auront été
découplées des autres
EN COUCHES OU MULTINIVEAUX (2/2)
Une architecture en couches ou

multiniveau est une architecture
classique, souvent utilisée pour créer
des applications d'entreprise ou sur
site. Elle est fréquemment associée aux
applications d'anciennes générations.
Une architecture en couches est

constituée de plusieurs couches ou
niveaux (souvent trois, parfois plus) qui
forment l'application.
Chaque couche a des responsabilités
distinctes.
Les couches permettent de gérer les

dépendances et d'exécuter des
fonctions logiques.
Elles sont disposées horizontalement,
de sorte qu'elles ne peuvent faire appel
qu'aux couches inférieures.
Ainsi, chaque couche peut faire appel

soit à la couche directement au-
dessous d'elle, soit à n'importe quelle
autre couche inférieure.
MONOLITHIQUES (1/6)
L'architecture monolithique est

également associée aux systèmes
d'anciennes générations.
Il s'agit d'une unique pile d'application
qui rassemble toutes les
fonctionnalités au sein d'une seule
application.
MONOLITHIQUES (2/6)
Elle est étroitement couplée, tant au

niveau des interactions entre les
services qu'au niveau des processus de
développement et de déploiement.
MONOLITHIQUES (3/6)
La mise à jour ou la mise à l'échelle d'un

seul composant d'une application
monolithique peut avoir des effets sur
toute l'application, ainsi que sur son
infrastructure sous-jacente.
MONOLITHIQUES (4/6)
Après chaque changement apporté au

code de l'application, il faut publier à
nouveau l'application tout entière.
MONOLITHIQUES (5/6)
Les mises à jour et les nouvelles

versions ne peuvent être publiées
qu'une à deux fois par an et elles
n'incluent souvent que de la
maintenance générale, à défaut de
nouvelles fonctions.
MONOLITHIQUES (6/6)
Au contraire, les architectures

modernes essaient de décomposer les
services en fonctionnalités ou en
capacités métier, pour fournir
davantage d'agilité
MICROSERVICES (1/6)
Les Microservices désignent à la fois

une architecture et une approche de
développement logiciel, qui consiste à
décomposer les applications en
éléments les plus simples,
indépendants les uns des autres.
MICROSERVICES (2/6)
Chacun de ces composants ou

processus est un microservice.
Les microservices sont distribués et
faiblement couplés, ils n'ont donc pas
d'incidence les uns sur les autres.
MICROSERVICES (3/6)
Ces caractéristiques offrent des

avantages au niveau de l'évolutivité
dynamique et de la tolérance aux
pannes : il est possible de mettre à
l'échelle des services individuels sans
nécessiter une infrastructure lourde, et
d'effectuer leur basculement sans
affecter les autres services.
MICROSERVICES (4/6)
De plus, puisque les services sont

déployés indépendamment, vous
n'avez pas à recréer ou redéployer
toute l'application après chaque
modification.
MICROSERVICES (5/6)
Plusieurs développeurs peuvent ainsi

travailler sur leurs services individuels
en même temps, sans qu'il y ait besoin
de mettre à jour toute l'application.
Cela permet de réduire la durée du
développement et de publier de
nouvelles fonctions plus souvent
MICROSERVICES (6/6)
Avec les API et les pratiques DevOps,

les microservices conteneurisés
constituent la base des applications
cloud-native.
ORIENTÉES ÉVÉNEMENTS (1/10)
Dans un système orienté événements,

la structure centrale de la solution
repose sur la capture, la
communication, le traitement et la
persistance des événements. C'est ce
qui différencie ce type de système du
modèle traditionnel orienté requêtes
Un événement désigne tout

phénomène ou changement d'état
significatif au niveau du matériel ou
d'un logiciel système. Les événements
peuvent être causés par des actions
internes ou externes.
Une architecture orientée événements

est faiblement couplée.
Elle est donc adaptée aux architectures
d'applications modernes distribuées.
Ce type d'architecture implique des

producteurs et des consommateurs
d'événements.
Un producteur d'événements détecte
ou reconnaît un événement et le
représente sous forme de message.
Il ignore quels seront les

consommateurs et les conséquences
de chaque événement
Lorsqu'un événement a été détecté, il

est transmis du producteur
d'événements au consommateur via
des canaux d'événement, où une
plateforme de traitement les prend en
charge de façon asynchrone.
Une architecture orientée événements

peut être basée sur un modèle de
publication/abonnement ou sur un
modèle de flux d'événements.
Le modèle de
publication/abonnement repose sur
l'abonnement à un flux d'événements.
Lorsqu'il est utilisé, chaque fois qu'un
événement se produit ou est publié, il
est envoyé aux abonnés qui doivent en
être informés.
Dans le modèle de flux d'événements,

les consommateurs d'événements ne
s'abonnent pas à un flux spécifique.
Ils peuvent accéder à n'importe quelle
partie du flux et le rejoindre à tout
moment.
Les événements sont capturés

régulièrement à partir de sources
d'événements telles que des
périphériques IoT, des applications et
des réseaux. Les producteurs et les
consommateurs d'événements peuvent
ainsi partager en temps réel les
informations d'état et de réponse.
ORIENTÉES SERVICES (1/15)
L'architecture orientée services (SOA,

Service Oriented Architecture) est un
modèle de conception largement
utilisé, similaire au modèle
d'architecture de microservices.
L'architecture orientée services

structure les applications en services
individuels et réutilisables qui
communiquent via un ESB
(l’Enterprise Service Bus).
Rappelons que L’entreprise service bus

(ESB) est une technique informatique
intergicielle. Son but est avant tout de
permettre la communication des
applications qui n'ont pas été conçues
pour fonctionner ensemble (par exemple
deux progiciels de gestion intégrés provenant d'éditeurs
différents)
Un bus de services d'entreprise (ESB,

Enterprise Service Bus) est un outil
middleware qui sert à répartir le travail
entre les composants connectés d'une
application
 Le middleware est un terme générique pour qualifier
toute application servant à rapprocher ou à mettre en
relation (comme un médiateur) deux applications
séparées
Les ESB sont conçus pour offrir une

méthode cohérente de répartition du
travail, donnant aux applications la
possibilité de se connecter au bus et de
s'abonner aux messages en fonction de
règles structurelles et métier simples.
Les ESB sont utiles à la fois dans

l'informatique distribuée et dans
l'intégration de composants.
Pour bien comprendre leur rôle, il faut les

considérer comme des ensembles de
commutateurs, capables d'acheminer un
message selon un itinéraire spécifique
entre les composants de l'application, en
fonction de l'implémentation et du
contenu du message, ou de règles métier.
Au sein de cette architecture, chacun

des services individuels (organisés
autour d'un processus métier
spécifique) suit un protocole de
communication (tel que SOAP,
ActiveMQ ou Apache Thrift) pour «
s'exposer » via la plateforme d'un ESB.
L'entreprise ou le client se sert d'une

application front-end pour utiliser
cette suite de services, intégrés au
moyen d'un ESB.
Comparaison entre ESB et microservices

Les ESB ont souvent été présentés comme
un moyen de mettre en oeuvre et de gérer
efficacement des architectures SOAP
(comme une architecture orientée
services traditionnelle, par exemple).

Mais ils représentent une stratégie de
workflow bien différente de celle
qu'apportent les approches plus découplées
associées aux microservices.

Contrairement aux microservices (ou aux
stratégies similaires qui arbitrent les
connexions entre l'interface de
programmation d'application et les
composants sans mettre en place de
workflow)

un ESB se trouve au coeur même du
workflow applicatif.
Il constitue une file d'attente de messages
qui régit les échanges d'information dans
toute l'application.

Un ESB ne cherche pas à savoir si les
composants qui utilisent le bus sont locaux
ou distants, ni à imposer d'obligations
particulières quant aux langages de
programmation

Au lieu de cela, il permet d'unifier les
différents moyens qu'ont les composants
de recevoir ou d'envoyer des informations
en provenance ou en direction d'autres
éléments applicatifs
TO DO
Quelle est la différence entre ESB et

microservices?
Proposer deux architectures pour
l’application e-Sandwicherie
%
QUESTIONS
PROCESSUS DE DÉVELOPPEMENT
DE LOGICIEL
RAPPELS : ACTIVITÉS (OU LES ÉTAPES)
 Analyse des besoins, spécification globale,

conceptions architecturale et détaillée,
programmation, gestion de configurations
et intégration, validation et vérification,
maquettage ou prototypage rapide
PROCESSUS
Comme tout produit manufacturé

complexe, un logiciel est produit en suivant
un certain Processus
 On pourrait aussi utiliser le terme
« Procédé de production »
L'expression « processus de
développement du logiciel » semble
maintenant consacré
PARTICULARITÉ
Le domaine du logiciel présente des

particularités. Par exemple, il n'y a pas de
problèmes de fabrication en série
Une fois qu'une version du logiciel est
réalisée, sa reproduction se fait par simple
copie
CARACTÉRISTIQUES (1/3)
Le processus de développement fonctionne

comme l'établissement d'une suite de
descriptions de plus en plus précises et de
plus en plus proches d’un programme
exécutable et de sa documentation.
Les passages d'une description à une autre
sont souvent appelés des raffinements
successifs
Le processus de développement est de

nature itérative, certaines étapes
déclenchant la révision du résultat des
étapes précédentes.
 Par exemple, la détection d'erreurs au moment
du test va provoquer un retour sur la
programmation ou la conception.
 De même, la conception peut faire apparaître des
problèmes de spécification
Le processus de développement se

caractérise aussi par son invisibilité
Il est difficile d'observer un logiciel en cours
de développement et de se persuader que
le processus se déroule correctement
EXPLOITATION
Une fois développé, un logiciel est mis en

exploitation. Se posent alors des
problèmes de maintenance, qu’il s'agisse
de corriger des défauts, d'améliorer
certaines caractéristiques, ou de suivre les
évolutions des besoins ou de
l'environnement.
CYCLE DE VIE
La maintenance peut remettre en cause

d'une manière significative les fonctions
du système et implique de ce fait un
processus de redéveloppement.
C'est pourquoi on parle de cycle de vie du
logiciel quand on considère l'exploitation et
la maintenance en plus du développement.
NE RIEN NÉGLIGER
Comme dans les autres domaines, le choix

d'un processus de développement est
fonction des caractéristiques du futur
produit ainsi que du contexte du
développement
Il faut prendre en compte des aspects
techniques, des aspects liés à
l'organisation et des aspects humains.
PLUS QUE NÉCESSAIRE
Il est plus que nécessaire de disposer de

modèles de développement généraux, qui
décrivent les enchaînements et les
interactions entre activités
UN MODÈLE
Un modèle permet de définir un processus

de développement pour un projet donné en
précisant les méthodes, outils, et autres
modalités associés à chacune des
activités.
LE DÉBUT
Les premiers modèles de développement

de logiciel ont été conçus dans un contexte
où le savoir-faire se résumait à
programmer et traquer les erreurs
MODÈLE EN CASCADE
VERS LES ANNÉES 60
le concept de développement en étapes (ou

phases) est apparu vers la fin des années 60
Une étape se termine par la production de
documents qui sont vérifiés et validés
avant de passer à l'étape suivante.
 Cela permet de contrôler l'avancement des
activités en cours et la validité des résultats
intermédiaires.
ACTIVITÉ VS ÉTAPE
Il est intéressant de noter que les notions

d'étapes et d'activités sont différentes
Activité = analyse des besoins, spécification globale,
conceptions architecturale et détaillée, programmation, gestion
de configurations et intégration, validation et vérification,
maquettage ou prototypage rapide
Une étape peut faire intervenir plusieurs

activités
EXEMPLES
Une étape de conception du produit peut

faire intervenir une activité de spécification
globale, une activité de maquettage et une
activité de validation.
De plus, une activité peut se dérouler
pendant plusieurs étapes ou même
pendant tout le processus (par exemple,
l'activité de documentation).
WATERFALL MODEL
Le principe du modèle de la (en) cascade

(ou modèle de la chute d’eau ou waterfall
model) est très simple : on convient d'avoir
un certain nombre d'étapes (ou phases).
Une étape doit se terminer à une certaine
date, par la production de certains
documents ou logiciels.
MODÈLE LINÉAIRE
Un modèle de gestion linéaire qui divise les

processus de développement en phases de
projet successives
Chaque phase est effectuée une seule fois.
Les sorties de chaque phase antérieure
sont intégrées comme entrées de la phase
suivante.
LES HYPOTHÈSES CHANGENT PEU
Le modèle en cascade est principalement

utilisé dans les projets pour lesquels les
besoins et les processus peuvent être
définis de façon précise dès la phase de
planification et pour lesquels on peut
supposer que les hypothèses changeront
peu tout au long du déroulement du projet.
VERSION COMPLÈTE
PLUSIEURS VERSIONS
Les résultats de l'étape sont soumis à une

revue approfondie, et on ne passe à l'étape
suivante que quand ils sont jugés
satisfaisants
En pratique, plusieurs versions du modèle
en cascade sont utilisées. Les modèles les
plus courants divisent les processus de
développement en cinq phases
VERSION LA PLUS CONNUE
POUR LES PETITS PROJETS
Les modèles de gestion strictement

linéaires conviennent ainsi principalement
aux projets logiciels plus petits, simples et
clairement structurés.
AVANTAGES ET INCONVÉNIENTS
LES FLÈCHES ASCENDANTES
Dans sa première version, le modèle ne

comportait que les flèches descendantes,
qui matérialisent l'enchaînement des
étapes, et ne prévoyait pas d'itération.
Les flèches ascendantes ont été ajoutées
par la suite et expriment le principe qu'une
étape ne remet en cause que l'étape
précédente.
VALIDATION - VÉRIFICATION
Dans les faits, ce principe reste souvent un

vœu pieux et il y a toujours des problèmes
qui se propagent de bas en haut.
Les versions actuelles de ce modèle font
apparaître la validation-vérification dans
chaque étape
RÉFÉRENCES
Il existe de nombreux documents, normes

ou recommandations, qui décrivent très
précisément des étapes et leurs
caractéristiques pour ce type de modèle
(IEEE, AFNOR).
.
VERS UN NOUVEAU MODÈLE
Cependant ce modèle, séduisant par sa

simplicité, est souvent abandonné au profit
du modèle en V, plus récent, qui présente
une approche plus réaliste de l'articulation
entre les activités de réalisation et celles de
validation-vérification
TO DO
%
QUESTIONS
MÉTHODE EN V
VERS LES ANNÉES 80
Mise au point dans les années 80, la

méthode cycle en V reste à ce jour un
modèle incontournable que de
nombreuses entreprises emploient pour le
management de certains projets.
Cette méthode d'organisation du travail
s'utilise dans différents domaines, et plus
particulièrement le développement de
logiciels.
PREMIÈRES & DERNIÈRES ÉTAPES
Ce modèle rend explicite le fait que les

premières étapes du développement, qui
ont trait surtout à la construction du
logiciel, doivent préparer les dernières
étapes, qui font intervenir essentiellement
les activités de validation et de
vérification.
VERSION COMPLÈTE
• La particularité de ce
modèle de gestion de
projet est de combiner
une phase de
validation pour
chaque phase de
développement.
• Le point de jonction, le
bas du V, correspond
quant à elle à l'étape
de réalisation
ENCHAINEMENTS
Il y a deux sortes de dépendances entre

étapes :
1. celles matérialisées par des traits gras
obliques, qui correspondent à
l'enchaînement et à l'itération éventuelle
du modèle de la cascade ; les étapes se
déroulent donc séquentiellement en suivant
le V de gauche à droite
DÉPENDANCES
Il y a deux sortes de dépendances entre

étapes :
2. celles matérialisées par les flèches
ombrées, qui représentent le fait qu'une
partie des résultats de l'étape de départ
est utilisée directement par l'étape
d'arrivée ;
CONCEPTION VS ASS. QUALITE
La partie descendante du « V » correspond

aux quatre actions de conception et de
développement du système, tandis que la
partie ascendante reprend les quatre
phases d'assurance qualité qui lui sont
associées
EXEMPLE
Par exemple, à l'issue de la conception

architecturale, le protocole d'intégration et
les jeux de test d'intégration doivent être
complètement décrits.
PRINCIPE DE V (1/3)
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 des tests
qui permettront de s'assurer qu’il
correspond à sa description
PRINCIPE DE V (2/3)
Ce principe évite un écueil bien connu de la

spécification de logiciel : on énonce une
propriété qu'il est impossible de vérifier
objectivement une fois le logiciel réalisé.
De plus, l'obligation de concevoir les jeux
de test et leurs résultats oblige à une
réflexion et à des retours sur la description
en cours.
PRINCIPE DE V (3/3)
Enfin, les étapes de la branche droite du V

peuvent être mieux préparées et planifiées.
EN RÉSUMÉ
La méthode du cycle en V implique toutes

les étapes du cycle de mise en œuvre d'un
produit ou d'un logiciel.
Elle permet de définir le processus d'un
projet en neuf étapes regroupées en trois
phases : la conception, la réalisation et la
validation
AVANTAGES (1/3)
Optimisation de la communication entre

les parties prenantes grâce à des modalités
et des responsabilités clairement définies.
Risques maîtrisés et meilleure
planification grâce à des fonctions, des
structures et des résultats bien définis en
amont.
AVANTAGES (2/3)
Amélioration de la qualité du produit

grâce à l’intégration de mesures liées à
l’assurance qualité.
Réduction des coûts grâce à un processus
transparent de l’ensemble du cycle de vie du
produit.
AVANTAGES (3/3)
Dans l’ensemble, ce modèle peut permettre

d’éviter les malentendus ainsi que les
tâches inutiles.
De plus, il permet de s’assurer que toutes
les tâches soient exécutées en temps voulu,
dans le bon ordre en réduisant les temps
morts au maximum.
DÉSAVANTAGES (1/2)
Du point de vue des développeurs, cette

démarche s’avère souvent trop simpliste,
car elle ne reflète pas intégralement le
processus de développement.
La gestion de projet occupe une place de
plus en plus importante.
DÉSAVANTAGES (2/2)
En outre, la rigidité relative de la structure

ne permet guère de réagir avec souplesse
aux modifications en cours de
développement et favorise donc un
déroulement relativement linéaire du
projet.
CASCADE VS V
La différence clé entre le modèle en

cascade et le modèle V est que dans le
modèle en cascade, le logiciel est testé après
la fin de la phase de développement,
tandis que dans le modèle V, chaque phase
du cycle de développement est associée à une
phase de test.
TO DO
%
QUESTIONS
MÉTHODE(S) AGILE(S)
PLUSIEURS
 Vous tous tous déjà entendu parler des

méthodes agiles, ou bien de la méthode
agile (parce que, oui, il y en a plusieurs !)
ORIGINE
 La méthode Agile de gestion de projet est

née à partir de méthodes de
développement utilisées par des
entreprises japonaises innovantes des
années 70 et 80 (comme Toyota, Fuji et
Honda)
A LA MODE
 Par certains considérée comme une

nouvelle méthodologie « à la mode »,
d’autres y voient un futur managérial
proche, spécialement dans le management
des projets IT pour lesquels la méthode est
déjà souvent utilisée.
UNE RÉVOLUTION CULTURELLE
 Bien plus qu’une remise en question des

modèles organisationnels d’aujourd’hui,
c’est surtout une révolution culturelle qui
s’opère au sein de l’entreprise, impliquant
un changement d’attitude profond
DÉFINITION
 Une méthode agile est une approche

itérative et incrémentale, qui est menée
dans un esprit collaboratif avec juste ce
qu’il faut de formalisme.
Elle génère un produit de haute qualité
tout en prenant en compte l’évolution des
besoins des clients
COLLECTIF ET SOLIDAIRE
Vers un engagement collectif et solidaire

qui casse les cloisons hiérarchiques et ouvre
donc à la communication et au partage
d’expériences.
S’auto-organiser, se faire confiance.
POLYVALENCE ET AUTONOMIE
Offrir à ses employés de la polyvalence et

de l’autonomie.
Prendre plaisir à travailler en équipe dans
une ambiance plus détendue, sans perdre
en performance ou efficacité.
PRATIQUES DISRUPTIVES
Mettre en place des

pratiques
disruptives,
notamment dans la
relation avec son
client qui se veut
plus collaborative.
MANIFESTE DE L’AGILE (1/2)
• L’idée est de découvrir, par la pratique

quotidienne de la méthode et l’entre-aide
entre employés, comment mieux imaginer,
expérimenter et proposer des dispositifs
(structures, règles, attitudes,
produit/service, ressources humaines, outils,
procédures…) pour faciliter la conduite d’un
projet.
MANIFESTE DE L’AGILE (2/2)
DÉFINITION
Vers un engagement collectif et solidaire

qui casse les cloisons hiérarchiques et ouvre
donc à la communication et au partage
d’expériences.
S’auto-organiser, se faire confiance.
Offrir à ses employés de la polyvalence et
de l’autonomie.
Prendre plaisir à travailler en équipe dans
AGILE EN IMAGE
LES ACTEURS
DIFFÉRENTS OUTILS UTILISÉS (1/3)
Product backlog (ou backlog produit) : Il

s’agit de la liste des fonctionnalités/des
actions qui devront être mises en œuvre par
le produit ou le service.
Sprint backlog (ou backlog d’itération) : Il

s’agit de la liste des tâches à accomplir
pendant un sprint/ une itération. Elles
correspondent à la réalisation des éléments
du backlog produit, affectés à l’itération.
Graphiques burndown/up : Le burndown

est un graphique qui représente le reste à
faire jour après jour, ou itération après
itération.
Le burnup, lui, représente le suivi de l’effort
livré sur les tâches du backlog d’itération.
Prendre plaisir à travailler en équipe dans
une ambiance plus détendue, sans perdre
en performance ou efficacité.
LES DIFFÉRENTES ÉTAPES D’UN
SPRINT (OU ITÉRATION) (1/4)
Le sprint planning meeting (ou planning

d’itération) : Durant cette réunion, l’équipe
doit décider des éléments du carnet du
produit qu’elle traitera, dans le cadre de la
prochaine itération.
Elle déterminera également la manière de
s’organiser pour y parvenir.
Le daily scrum meeting (ou stand-up

meeting) : C’est une réunion quotidienne de
15 minutes environ, permettant à chacun
des membres de l’équipe de dire ce qu’il a
fait, ce qu’il va faire, et les freins qu’il a
rencontrés.
La revue de sprint (ou revue d’itération) :

Cette réunion permet de valider l’incrément
de produit qui a été réalisé pendant
l’itération.
La rétrospective de sprint : Durant cette

réunion, on va chercher à s’adapter aux
changements qui surviennent au cours du
projet, et proposer des améliorations de
manière continue en ce qui concerne le
processus de réalisation
SCRUM
(FRAMEWORK AGILE)
PLUS DE TECHNIQUES
 Plus que de méthodes, nous parlerions

davantage de techniques, de pratiques…
 XP
 SCRUM
 DSDM
 ASD
 AUP
 KANBAN
LE PLUS APPRÉCIÉ
 Le Scrum : cadre (Framework en anglais)

de gestion de projet qui est utilisé pour
implémenter la méthode Agile. C’est le
“cadre” le plus apprécié.
 Scrum est devenu incontestablement la méthode
la plus populaire
MÉTHODES CLAIRES
 Elle s'appuie sur des tâches claires, classées

par ordre de priorité, puis réalisées lors de
phases opérationnelles récurrentes.
L'expertise et les retours de l'équipe sont
essentiels pour améliorer progressivement le
projet en cours autant que sa productivité.
L’EXPERTISE
 Les bases du cadre Scrum, “mêlée” en anglais,

ont été introduites en 1986 par Hirotaka
Takeuchi et Ikujiro Nonaka dans un article
publié par The Harvard Business Review.
 L'expertise et les retours de l'équipe sont
MÉTAPHORES SPORTIVES (1/3)
 Les auteurs ont utilisé des métaphores

sportives pour décrire deux approches
différentes de la gestion du développement de
produits.
 Selon eux, certaines équipes sont comme des

coureurs dans un relai, se passant le témoin
en ligne droite.
 D’autres équipes sont des joueurs de rugby
jouant ensemble la même partie, évoluant en
va-et-vient selon les besoins.
 Ils ont conclu que l’approche de course à relais

était obsolète alors celle du rugby donnerait
les clés pour faire face à un contexte de plus
en plus concurrentiel. Le Scrum était né.
L’EXPERTISE
 L'expertise et les retours de l'équipe sont

 Principes:
 1. Transparence
 2. Inspection
 3. Adaptation
PRINCIPES – TRANSPARENCE (1/2)
La transparence signifie que toute

information doit être accessible et
compréhensible pour n'importe quel
membre du projet.
PRINCIPES – TRANSPARENCE (2/2)
Dans l'optique d'une bonne

communication et d'une collaboration
optimisée, chacun doit savoir de quoi il
est question, et rapidement.
PRINCIPES – INSPECTION
L’Inspection intervient à un rythme

régulier et raisonnable, par exemple à
la fin d'une phase opérationnelle, pour
vérifier que le livrable attendu est
conforme aux objectifs définis en
début de période.
PRINCIPES – ADAPTATION (1/2)
L'adaptation est inscrite dans l'ADN de

la méthode agile Scrum. Si l'inspection
révèle un problème sur l'ensemble des
tâches réalisées, le fonctionnement
doit être ajusté.
La méthode offre plusieurs occasions

d'opérer cet ajustement
KANBAN
(FRAMEWORK AGILE)
UN PRODUIT DE TOYOTA
 Kanban a été initialement développé par

Taiichi Ohno, ingénieur industriel chez
Toyota, pour créer un processus de
fabrication plus efficace.
UTILISÉ DANS LE DVPT DE PRODUITS
Il a ensuite été appliqué au développement

de produits par David J. Anderson dans son
livre de 2010 Kanban: Successful
Evolutionary Change for YourTechnology
Business.
COMME SCRUM
Comme Scrum, Kanban encourage le travail

à être décomposé en petites tâches.
COMME SCRUM
Mais plutôt que de planifier le travail dans

une itération ou un Sprint, les membres de
l’équipe récupèrent la tâche la plus
prioritaire dans le backlog qui est prête à
être développée
TÂCHE PRIORITAIRE
Mais plutôt que de planifier le travail dans

une itération ou un Sprint, les membres de
l’équipe récupèrent la tâche la plus
prioritaire dans le backlog qui est prête à
être développée
TABLEAU KANBAN
Les équipes vont utiliser un tableau Kanban

pour visualiser ce travail à mesure qu’il
progresse dans le flux de travail.
Il permet d’illustrer à la fois un processus et
chaque fonctionnalité passant par ce
processus.
LES GOULOTS
L’objectif principal de la mise en œuvre de

Kanban est d’identifier les goulots
d’étranglement potentiel dans le processus
et de les corriger.
LES GOULOTS
Les équipes mettent en place KANBAN

pour que le flux de travail se déroule sans
problème à une vitesse optimale
LIMITATION
Dans ce tableau, le cadre Kanban limite la

quantité de tâches autorisée dans chaque
colonne.
OBLIGATION
 Imaginons que seulement trois tâches

peuvent être dans la colonne “en cours” et une
dans la catégorie “à tester.”
 Généralement, les développeurs sont connus
pour préférer développer que tester, ici,
Kanban les oblige à tester les tâches dans la
catégorie “à tester” avant de démarrer un
nouveau développement.
PRINCIPE 1/4
Visualisez le travail
 En créant un modèle visuel pour observer les
tâches se déplaçant à travers les colonnes du
tableau Kanban.
PRINCIPE 2/4
Limiter le travail en cours

Cela permet de réduire le temps que met une
tâche à traverser entièrement le tableau en
partant de la première colonne jusqu’à la
colonne “terminé”..
PRINCIPE 3/4
Se concentrer sur le flux

En utilisant des limites de travail en cours et en
développant des politiques axées sur l’équipe,
vous pouvez optimiser le système Kanban pour
améliorer la fluidité du travail.
PRINCIPE 4/4
S’Améliorer en continue
Lorsque le système Kanban est en place, il sert
de base à une amélioration continue. Il aide les
équipes à mesurer leur efficacité en analysant
le flux de suivi, les délais de qualification, etc.
SCRUM VS KANBAN
LES RÔLES (1/3)
Dans Scrum il y a un ensemble de rôles à

implémenter. Voici les trois principaux:
Le Product Owner qui est en charge du backlog
et oriente l’équipe;
Le Scrum Master qui dicte les délais;
Les développeurs qui traitent le travail
convenu lors de la planification du Sprint.
LES RÔLES (2/3)
Kanban, quant à lui, vous permet de conserver

votre structure actuelle sans apporter de
changements drastiques.
Il est conseillé de les implémenter mais ils ne
sont en aucun cas obligatoires :
LES RÔLES (3/3)
Le gestionnaire de prestation de services qui

est chargé de veiller à ce que le flux soit en
continu et qu’il n’y ait pas d’embouteillage
parmi les tâches;
Le gestionnaire de demande de service qui a le
rôle du chef d’équipe.
LES ENGAGEMENTS (1/2)
Dans Scrum et Kanban

Les équipes Scrum doivent s’engager sur une
quantité spécifique de travail.
Il est important d’identifier toutes les tâches,
de les hiérarchiser et de les estimer selon la
valeur qu’elles apportent au produit.
LES ENGAGEMENTS (2/2)
L’engagement est facultatif pour les équipes

suivant le cadre Kanban.
Ainsi, les équipes travaillent à leur vitesse.
Parfois, elles peuvent livrer plus tandis que
d’autres fois, elles peuvent livrer moins dans la
même durée.
LES CADENCES (1/2)
Les cadences sont des éléments importants de

Scrum et Kanban. Pourtant, la façon dont elles
sont mises en œuvre est différente.
Dans Scrum, elles sont définies par la
longueur de chaque Sprint. Un Sprint typique
dure deux semaines. Si chaque élément intégré
dans le sprint est terminé, le sprint est
considéré comme réussi.
LES CADENCES (2/2)
Une fois l’itération terminée, le cycle redémarre

immédiatement.
Dans Kanban, les cadences sont
principalement liées aux réunions et sont
facultatives.
Comme votre objectif est de maintenir un flux
de travail continu, les cadences sont suggérées
par des échanges entre les membres de
l’organisation
LES ITÉRATIONS (1/2)
 Étant donné que Scrum met fortement

l’accent sur l’engagement de l’équipe, de
nouveaux éléments ne peuvent pas être
ajoutés en cours d’itérations.
 Ce n’est que lorsque le sprint en cours est
terminé que les tâches peuvent être
intégrées dans le nouveau sprint.
LES ITÉRATIONS (2/2)
 Avec Kanban, de nouvelles tâches peuvent

être ajoutées en permanence.
 Lorsqu’une tâche passe du stade «en cours»
au stade «terminée», une nouvelle tâche peut
prendre immédiatement sa place.
BACKLOG
 Un backlog de sprint n’appartient qu’à une

seule équipe à la fois.
 Scrum encourage les équipes multi-
fonctionnelles. Chaque équipe possède toutes
les compétences nécessaires pour réussir
toutes les tâches pendant le sprint.
 En comparaison, les tableaux Kanban
peuvent être partagés par plusieurs équipes.
Chacun est dédié à ses propres tâches.
CONCLUSION (1/3)
 Lequel de ces deux cadres doit-on choisir pour

un produit?
 Il n’y a pas de réponse exacte à cette
question…
CONCLUSION (2/3)
 Chaque produit est différent ainsi que chaque

entreprise.
 Certains choisiront KANBAN pour sa
flexibilité (si leurs priorités changent souvent
par exemple) et d’autres SCRUM pour sa
priorisation et sa cadence.
CONCLUSION (3/3)
 Et si la meilleure solution était de fonctionner

en SCRUMBAN ?
 Faire du SCRUMBAN c’est combiner le
meilleur des avantages des deux cadres
 Pensez aussi à JIRA L'outil de développement

logiciel n° 1 pour les équipes Agile
TO DO
 Quel Framework choisiriez-vous le projet d’e-

Sandwicherie
 Lister le contenu de votre backlog
 Proposer le tableau KANBAN de votre
progression actuelle
%
QUESTIONS

Intro Genie Logiciel by Efrem UNH Nov2022

Transféré par

Droits d'auteur :

Formats disponibles

Intro Genie Logiciel by Efrem UNH Nov2022

Transféré par

Informations du document

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

Intro Genie Logiciel by Efrem UNH Nov2022

Transféré par

Droits d'auteur :

Formats disponibles

GÉNIE LOGICIEL

Efrem MBAKI LUZAYISU

Le Génie Industriel est la science de

A l’origine, le génie industriel

La mission principale est d'éliminer les

Rationaliser le fonctionnement d'une

Organiser et gérer des équipes de

Ensemble des méthodes, des

Le Génie logiciel est une science de

Présenter et utiliser des : Concepts,

Avoir des procédures systématiques

Science récente 1970

 Démarrage de Site de Prise de RDV Vaccins

Rationaliser et à Optimiser le Processus

Excellent Soin apporté à la réalisation

Des performances homogènes

Un client dépense une certaine somme

Le coût englobe aussi :

Pas facile de déterminer le temps que dure

Rapide et pas cher (Pressé et moins cher)

Ce qui n’existe pas, ou ne devrait pas

Sans être une solution miracle, le Génie

CQFD est un sigle de Coûts,

Utilité : Ensemble des

Le génie logiciel couvre l'ensemble du

Les dimensions du génie logiciel sont

Gestion des versions.

A la fin du cours l’étudiant doit être

 Rédiger des cas d'utilisation efficaces, Alistair Cockburn,

Qu’est-ce qu’un Système

Considérer les 3 projets suivants :

 Décrivez ces projets en précisant :

Une équipe de 5 personnes max

Désigne toutes les étapes du

 Définition des besoins:

Décrivent les liens, les relations

Permettent de mettre en œuvre un

Analyser la situation pour tenir

Eviter de développer un logiciel non

Etudier le domaine d’application

Les données/ Informations sont

Les méthodes utilisées ne relèvent pas

Au début du processus (mais aussi durant tout

Comprendre le contexte du moment et

Poser des questions

Une fois mis en perspective avec le

L’informaticien devrait structurer les

Collaborer avec le client pour établir

Il ne faut pas se limiter aux

Déterminer les paramètres de

Il faut être réaliste quant au nombre

Il faudrait également considérer le

Les étapes précédentes permettent

De plus, cet exercice permet à

Réaliser le cahier des charges du projet

Spécification = ce que doit faire le

Les spécifications (fonctionnelles) sont

Etablir une première description du

Décrire ce que doit faire le logiciel

Les spécifications informelles, par