1 partie: Aperçu général sur le

ère

Génie Logiciel

Prof. Dr. Saint-Jean DJUNGU

Saintjean.djungu@unikin.cd
sdjungu@yahoo.fr
 Plan
1. Introduction au Génie
Logiciel
2. Vue d’ensemble du processus
3. Développement itératif
4. Modélisation
5. Systèmes patrimoniaux
 La nature du logiciel
• Le logiciel est facile à reproduire
– Tout le coût se trouve dans son développement
• Pour d’autres produits, la fabrication est souvent le processus le plus coûteux

• Le logiciel est intangible

– Il est difficile d'estimer l’effort de développement

• Le processus de développement est difficile à

automatiser
– L’industrie du logiciel exige beaucoup de main d'œuvre
 La nature du logiciel
• Même des informaticiens peu qualifiés peuvent arriver à
bricoler quelque chose qui semble fonctionner
– La qualité d’un logiciel n’est pas apparente

• Un logiciel semble facile à modifier

– La tentation est forte d’effectuer des changements rapides sans
vraiment en mesurer la portée

• Un logiciel ne s’use pas

– Il se détériore à mesure que des changements sont effectués
• en raison de l’introduction d’erreurs
• ou par une complexification indue
 Définition : "Logiciel"
• Erreur courante : logiciel = code source

• Pas uniquement le code source !

– binaires, librairies, manuel utilisateurs, etc.
– spécifications, dossier de conception, test, etc.

• Savoir programmer n'est qu'un "détail" !

 Vieillissement de logiciel
• Raisons pour lesquelles le logiciel vieillit
– maintenance (e.g., bug fixes)
– érosion architecturale
– inflexibilité dès le début
– documentation insuffisante ou inconsistante
– deadline précis
– duplication de code
– manque de modularité
– complexité croissante
– ...
 Observations
• Beaucoup de logiciels sont mal conçus et
se détériorent rapidement
• La demande pour le logiciel est toujours
croissante
• Le logiciel se trouve en perpétuel "état de
crise"
• L’ingénierie du logiciel est une nécessité
- processus systématique au lieu de bricolage
 Les différentes catégories de logiciel
• Sur mesure (custom)
– Pour un client spécifique

• Générique (generic)
– Vendu sur le marché : un tableur (Excel), un outil de base de
données (Access), un outil de traitement de texte (Word)
• Embarqués (embedded)
– exécutent dans du matériel électronique isolé: machine à laver,
téléviseur, lecteur DVD, téléphone mobile, magnétoscope, four à
micro-ondes, réfrigérateur, joueur MP3, …

– Difficile à modifier
 Les différentes catégories de logiciel

• Logiciel à temps réel (real-time)

– e.g. systèmes de contrôle et de surveillance
– manipulent et contrôlent le matériel technique
– Réaction immédiate requise
– Environnement souvent très contraignant

• Logiciel de traitement de données (data processing)

– Ils stockent, recherchent, transforment et présentent l'information aux utilisateurs
– Grandes quantités de données avec des corrélations complexes, enregistrées dans les bases de
données
– Largement utilisés en administration des affaires
– Fiabilité des résultats
– Sécurité dans l’accès aux données

• Quelques fois les 2 aspects sont présents dans un logiciel

 Les différentes catégories de logiciel

• Les systèmes distribués

– synchronisent la transmission, assurent l’intégrité des données et la
sécurité, ...
– Technologies utilisées
• CORBA, DOM/DCOM, SOAP, …
• Les systèmes de matériel
– Systèmes d'exploitation, exécutions de matériel de bas niveau
• Les systèmes d'entreprise
– décrivent les buts, les ressources, les règles et le travail réel dans une
entreprise
 La préhistoire du logiciel
• Années 50 et 60 : programmation empirique
– production "artisanale" de logiciels scientifiques
– royaume des "codeurs" et les "grands gourous »

• Fin des années 60 : la "crise du logiciel"

– difficulté d'écrire de grands programmes
– difficulté de les utiliser, difficulté de les faire évoluer
– de nombreux projets échouent
 La "crise du logiciel"
Etude du gouvernement américain en 1979

• Payés mais jamais livrés $3.2M 47%

• Livrés mais jamais utilisés $2.0M 30%
• Abandonnés ou refaits $1.3M 18%
• Utilisés après modification $0.2M 3%
• Utilisés tel quel $0.1M 2%
Origine du terme "Génie Logiciel"
1968 : "1st Conference on Software Engineering"
• Génie Logiciel = Ingénierie + Logiciel
• idée : la production de logiciel doit être organisée
• contrôle des coûts, contrôle de la qualité, etc.
Idée séduisante
• changement de terminologie
– 1950 : codeur
– 1970 : programmeur
– 1990 : ingénieur logiciel
• correspond réellement à une discipline d’ingénierie ?
 Définition : "Ingénierie"
• ressources limitées (e.g. temps, argent, ...)
• solution utile résolvant un problème
concret
• le problème n'est pas inventé par
l'ingénieur
• rigueur dans la résolution du problème
• prédictibilité du résultat
 Pratique de l'ingénierie
• pas besoin d'être un génie pour être un
ingénieur !
• résolution de problèmes complexes
• résolution de problèmes récurrents
• catalogue de solutions pour un type de
problèmes
• solutions sûres et éprouvées
 Ingénierie et société
• Exemple : montrer qu'un pont ne va pas
s'écrouler
• contraintes de sécurité imposées par la société
• n'importe qui ne peut pas faire n'importe quoi
• association, droit d'exercer la profession, etc.
Qu’est-ce que le Génie logiciel?
• Définition
- Le processus visant la résolution de
problèmes posés par un client par le
développement systématique et l’évolution
de systèmes logiciels de grande taille et de
haute qualité en respectant les contraintes
de coûts, de temps, et autres.
Qu’est-ce que le Génie logiciel?
• …la résolution de problèmes posés par un
client…

– Voilà le but essentiel du génie logiciel

– Dans certains cas, la solution peut être de ne rien développer,
si un produit satisfaisant existe déjà
• logiciel générique
– Ajouter des options non requises par le client ne solutionne en
rien le problème
– L’ingénieur logiciel doit établir une bonne communication
afin de bien identifier et comprendre le problème à résoudre
Qu’est-ce que le Génie logiciel?
• …par le développement systématique et
l’évolution…

– Tout processus d'ingénierie implique l’application de

techniques bien maîtrisées de façon organisée et disciplinée
– Plusieurs pratiques reconnues ont maintenant été standardisées
• e.g. IEEE ou ISO
– La plupart des projets logiciels consiste à faire évoluer un
logiciel existant
Qu’est-ce que le Génie logiciel?
• …systèmes logiciels de grande taille et de haute
qualité…
– Un logiciel de grande taille est un logiciel qui ne peut être
compris par une seule personne
– Le travail en équipe et une bonne coordination sont essentiels
– Un des défis principaux est d’arriver à subdiviser le travail à
accomplir tout en s’assurant que chacune de ces parties
fonctionneront harmonieusement ensemble
– Le produit final doit rencontrer des critères de qualité bien
établis
Qu’est-ce que le Génie logiciel?
• …en respectant les contraintes de coûts, de temps,
et autres.

– Les ressources sont limitées

– Le bénéfice résultant doit être supérieur aux coûts
– La productivité de l’équipe doit demeurer concurrentielle
– Une mauvaise estimation des coûts et de la durée du
projet peut mener à l’échec du projet
Les quatre P du génie logiciel
– Personnel
• Qui produit le logiciel?
– Processus
• Comment le logiciel est-il produit?
– Projet
• La production réelle du logiciel
– Produit
• Tous les objets fabriqués pendant la production
• code source, exécutables, documentation, modèles de conception,
cahier de charges, résultats de tests, mesures de productivité, …
 Quid de la qualité logicielle?
• La qualité correspond au contrat de service initial
• La qualité du logiciel est une notion multiforme qui recouvre:
- la validité: aptitude d’un logiciel à réaliser exactement les tâches définies
par sa spécification,
- la fiabilité: aptitude d’un logiciel à assurer de manière continue le service
attendu,
- la robustesse: aptitude d’un logiciel à fonctionner même dans des
conditions anormales,
- l ’extensibilité: facile d’adaptation d’un logiciel aux changements de
spécification,
- la réutilisabilité: aptitude d’un logiciel à être réutilisé en tout ou en partie,
 Quid de la qualité logicielle?
- la compatibilité: aptitude des logiciels à pouvoir être combinés les uns aux
autres,
- l’efficacité: aptitude d’un logiciel à bien utiliser les ressources matérielles
telles la mémoire, la puissance de l’unité centrale, etc
- la portabilité: facile à être porté sur de nouveaux environnements matériels
et/ou logiciels,
- la traçabilité: capacité à identifier et/ou suivre un élément du cahier des
charges lié à un composant d’un logiciel,
- la vérifiabilité: facilité de préparation des procédures de recette et de
certification,
- l’intégrité: aptitude d’un logiciel à protéger ses différents composants contre
des accès ou des modifications non autorisés,

- la facilité d’utilisation, d’entretien, etc

Risques et difficultés en Génie logiciel

• Complexité et quantité des éléments à tenir en

compte
• Incertitude concernant la technologie
• Incertitude concernant les exigences
• Incertitude concernant les compétences
• Adaptation face aux changements
• Détérioration du produit
• Risques politiques
 Les parties prenantes dans le
Génie logiciel
1. Utilisateurs (users)
– Ceux qui se servent du logiciel
2. Clients (customers)
– Ceux qui paient pour le logiciel
3. Développeurs (developers)
– Ceux qui conçoivent le logiciel
4. Gestionnaires (managers)
– Ceux qui supervisent la production du logiciel

Tous ces rôles peuvent être remplis par la même personne

 Plan

1. Introduction au Génie Logiciel

2. Vue d’ensemble du processus
3. Développement itératif
4. Modélisation
5. Systèmes patrimoniaux
 Introduction
• Un processus de développement logiciel
fournit une base - une collection de
techniques et de notations prédéfinies - pour
la production organisée de logiciels
 Stades du développement
• Spécification initiale du système
- Définir une application et formuler des exigences provisoires

• Analyse
- Comprendre les exigences en profondeur en construisant des modèles. Le but de
l’analyse est de spécifier le quoi - ce qui doit être réalisé - et non le comment - la
façon de le réaliser
Vous devez comprendre le problème avant d’essayer de lui trouver une solution

• Conception du système
- Mettre au point une stratégie de haut niveau - l’architecture - pour résoudre le
problème de l’application. Instaurer des politiques pour guider la conception des
classes
 Stades du développement
• Conception des classes
- Augmenter et ajuster les modèles du monde réel obtenus par l’analyse pour
qu’ils soient compatibles avec une implémentation informatique. Déterminer
les algorithmes pour réaliser les opérations

• Implémentation
- Traduire la conception en code et en structures de bases de données

• Tests
- Vérifier que l’application est réellement utilisable et qu’elle correspond
vraiment aux exigences
 Stades du développement
• Formation
- Permettre aux utilisateurs de maîtriser la nouvelle application

• Déploiement
- Mettre l’application en production et remplacer élégamment les applications
existantes

• Maintenance
- Préserver la pérennité de l’application
Cycle de vie du développement
• Développement en cascade
- exige que les différents stades du développement logiciel suivent une
séquence linéaire et rigide qui n’admet pas de retours en arrière

• Développement itératif
- offre plus de souplesse. On commence par développer le noyau du système
en suivant les stades habituels - analyse, conception, implémentation, tests - et
vous livrez du code opérationnel. Puis on élargit le périmètre du système en
ajoutant des propriétés et des comportements aux objets existants ainsi que de
nouveaux types d ’objets. Plusieurs itérations ont lieu à mesure que le système
évolue pour déboucher sur le livrable final
 Plan

1. Introduction au Génie Logiciel

2. Vue d’ensemble du processus
3. Développement itératif
4. Modélisation
5. Systèmes patrimoniaux
 Développement itératif
• Le développement logique est par nature itératif, car
nous manquons d’un discernement parfait
- Il faut donc revenir en arrière pour corriger les erreurs et apporter des
améliorations

• Le développement itératif est le développement d’un

système selon un processus divisé en plusieurs étapes,
ou itérations, chaque étape proposant une meilleure
approximation du système désiré que l’itération
précédente
 Développement itératif vs développement
en cascade
• Dans les années 1980 et au début des années 1990, l ’approche en
cascade représentait le paradigme dominant du cycle de vie

Analyse
Conception
Implémentation
Test
• L’approche en cascade est rigide et ne convient pas à la plupart des
développements d’applications
• Ce développement convient aux applications intelligibles dont les
résultats sont prévisibles de l’analyse à la conception
 Développement itératif vs développement
en cascade
• La plupart des applications comportent une part substantielle
d’incertitude quant à leurs exigences

• En outre, une approche en cascade n’aboutit pas à un système utilisable

tant que le développement n’est pas achevé. Il devient alors difficile
d ’évaluer la progression et de corriger un projet qui est parti de travers

• A l’opposé, le développement itératif est jalonné de nombreuses étapes

et permet de découvrir les écueils dès les toutes premières étapes du
développement.
- Il est ainsi plus aisé de modifier un système; les révisions sont plus simples et moins coûteuses
que si elles sont différées
 Développement itératif vs prototypage
rapide
• Le prototypage rapide permet de développer rapidement une portion de
logiciel, de l’utiliser et de l’évaluer.
• Vous incorporez ensuite le résultat de votre travail et recommencez ce cycle.
• Enfin, vous livrez le prototype final comme s ’il s ’agissait de l’application
finie ou alors, après quelques prototypes, vous optez pour une autre approche

Ecouter le client Développer rapidement un prototype

• Le prototypage rapide présente des avantages similaires au développement
itératif. La différenceFaire
est qu’il élimine fréquemment
évaluer le prototypedu par
codele
tandis que le
client
développent itératif cherche à l’accumuler
 Développement itératif vs prototypage
rapide

• La force du prototypage rapide est qu’il met

en avant la communication avec le client et
lui permet d’exprimer ses exigences
• Exploitable pour démontrer la faisabilité
technique en cas de technologie complexe
• En revanche, il peut être difficile par un
prototype rapide de se débarrasser du code
 Développement itératif vs prototypage
rapide
• Le développement itératif présente le même
avantage tant que les itérations demeurent réduites
et qu’elles sont régulièrement présentées au client
• Le prototypage rapide et le développement itératif
offrent tous deux des points de contrôle fréquents
permettant de garantir aux clients une bonne
avancée du développement. Ils offrent également
aux développeurs un moyen de résoudre des
problèmes ennuyeux dès le début du
développement
 Portée des itérations
• Le développement est composé d ’une série d ’itérations
dont le nombre et la durée dépendent de la taille du projet
- deux à quatre semaines pour un projet court (de six mois ou moins)
- trois à quatre mois pour un projet s ’étendant sur plusieurs années

• Si les itérations sont trop courtes, le coût des itérations est

trop élevé. Si elles sont trop longues, il n ’y aura pas
suffisamment de points de contrôle pour évaluer la
progression d’une application et effectuer des corrections à
mi-chemin
 Portée des itérations
• Définissez la portée d’une itération - la
quantité de travail minimum pour une
progression pertinente est un bon objectif
– Construisez dès le départ des parties vitales
ainsi que les fragments de code de base
fréquemment exécutés par l’application
– Assurez-vous également que vous équilibrez les
fonctionnalités du système
 Portée des itérations
• Chaque itération doit proposer au minimum:
- un retour sur investissement,
- une fonctionnalité ajoutée,
- une interaction utilisateur améliorée,
- une meilleure efficacité,
- une plus haute fiabilité ou une infrastructure renforcée (pour la
maintenance et les itérations futures)
• Il faut éviter le syndrome selon lequel « tout est d’importance
égale »
• Il est inutile de rendre compte du résultat de chaque itération au
client
 Portée des itérations
• Du point de vue du développement, il est important de:
– conserver l’impulsion,
– rester dans les délais et
– assurer que les différents composants d’une application concordent bien
• Du point de vue du client, l’installation de chaque
itération suppose un effort trop important
• Pour simplifier la logistique, une entreprise peut
combiner plusieurs incréments avant le déploiement
 Réalisation d’une itération
• 1ère règle
Chaque itération doit commencer à partir d’un référentiel
commun et se terminer avec un nouveau référentiel
commun
– Une équipe doit structurer son travail sur une itération pour
pouvoir aller jusqu’au bout, la vérifier, la tester et l ’intégrer au reste du
système. Cela suppose un peu de planification mais s ’avère rentable à long
terme
• 2ème règle
Chaque itération doit générer une version exécutable
 Planification de l’itération suivante

• Après chaque itération, vous devez évaluer

votre progression et revoir la planification de
l’itération suivante
Questions
• L’itération réalisée a-t-elle pris plus ou moins
de temps que prévu?
• Disposez-vous des compétences adéquates
parmi vos développeurs?
 Planification de l’itération suivante

• Le client est-il satisfait de l’avancée du

travail?
• La prochaine itération soulève-t-elle des
problèmes ou des questions spécifiques?
• Le logiciel est-il stable ou devez-vous prévoir
du travail supplémentaire ou un remaniement
lors de la prochaine itération?
 Planification de l ’itération suivante

• Bien entendu, si l’itération précédente a réussi,

vous pouvez poursuivre votre planification. Dans le
cas contraire, n’hésitez pas à écarter les mauvaises
décisions et à effectuer des corrections à mi-chemin

• L’extensibilité, la maintenance, et la viabilité de

votre application ne s’obtiendront qu’au prix d’un
développement robuste
 Planification de l’itération suivante

• Vous devez recevoir un retour précoce et

fréquent des utilisateurs - ils doivent
intérioriser votre travail et réfléchir à ses
implications quotidiennes dans leur travail

• En outre, ils peuvent vous aider à détecter

tout écart par rapport au périmètre du
logiciel ou au déroulement des itérations
 Plan

1. Introduction au Génie Logiciel

2. Vue d’ensemble du processus
3. Développement itératif
4. Modélisation
5. Systèmes patrimoniaux
 Définition
• Un modèle est une représentation simplifiée
d’une partie de la réalité avec un but spécifique

– Une simplification parce que le monde réel est

trop complexe
– Le mécanisme d’abstraction (simplification)
nous permet de contrôler la complexité intrinsèque
du monde réel
 Modélisation
• Un modèle est une représentation simplifiée d’une
partie de la réalité avec un but spécifique
– Visualiser le système
– Mieux comprendre le système
– Spécifier la structure et le comportement du
système
– Permettre l’analyse, simulation et vérification du
système
– Documenter les décisions importantes
 Modèle du système logiciel
• Le modèle est une représentation de
quelque chose qui n’existe pas encore

• Le but de la modélisation est de faciliter la

conception et la construction du système
 Avantages de la modélisation
• Facilite la révision et l’évolution du
système
• Réduit le risque d’erreurs, permet de
détecter les erreurs tôt dans le cycle de
vie
• Diminue les coûts de développement
 Avantages de la modélisation
• Contrôle la complexité par le
mécanisme d’abstraction
• Permet l'exploration de
l'expérience avec des solutions
alternatives
 La modélisation

• Un bon modèle devrait

– utiliser une notation standardisée
– être compréhensible pour les clients et
utilisateurs
– permettre aux ingénieurs logiciel de bien saisir
le système
– procurer une vue abstraite du système
– être visuelle
 Modélisation visuelle
• Pourquoi utiliser la modélisation visuelle?
– On doit enregistrer nos pensées et
communiquer en utilisant des langages visuels
et schématiques (p.e., UML) parce que
• On estime qu’au moins 50% de notre cerveau est
impliqué dans le processus visuel
• Les langages visuels sont naturels et faciles pour notre
cerveau
 Modélisation et développement itératif
• La modélisation est un complément naturel du
développement itératif
• L’un des objectifs du développement itératif est
de découvrir très tôt les problèmes du logiciel et
il en va de même pour la modélisation
• Une modélisation soigneuse peut vous aider à
découvrir des problèmes dans les modèles et à
réduire le nombre d’itérations - le résultat net est
un développement plus rapide et plus efficace
Modélisation et développement itératif

La modélisation peut et doit se faire

rapidement de sorte à ne pas ralentir le
calendrier du projet

Modèle 1 Itération 1 Modèle 2 Itération 2

Itération 4 Modèle 4 Itération 3 Modèle 3

 Pièges de la modélisation
• Paralysie de l’analyse
– Certaines personnes (analystes non
développeurs, débutants) se focalisent
tellement sur la modélisation qu’elles n’en
finissent jamais

– Résolution: Un plan de projet peut vous éviter

la paralysie en allouant du temps aux tâches
 Pièges de la modélisation
• Modélisation en parallèle
– Les équipes orientées objet et les experts en bases de
données possèdent leur propre style et leur propre
jargon, et rares sont les personnes capables d’évoluer
dans les deux camps

– Résolution: Laissez aux développeurs le soin de

construire les modèles à la fois pour la programmation
et pour les bases de données s’ils le jugent utiles. Dans
le cas de plusieurs modèles, insistez pour que les
équipes dialoguent et s’entendent fréquemment entre
elles
 Pièges de la modélisation
• Impossibilité de raisonner de manière
abstraite
– De nombreuses personnes sont incapables de raisonner de
manière abstraite et ne parviennent pas à apprendre à
modéliser. Elles basculent rapidement en mode
programmation et éprouvent des difficultés à prendre du
recul par rapport à un problème

– Résolution: L’expérience est le seul remède. Les

modélisateurs inexpérimentés doivent s’exercer
 Pièges de la modélisation
• Périmètre trop vaste
– La modélisation a pour objet de représenter le monde
réel, mais uniquement la portion pertinente pour les
objectifs de votre entreprise. Certaines personnes
perdent de vue ce but et modélisent des informations
superflues

– Résolution: Il faut disposer d’un plan de projet et faire

des revues régulières. Le travail de modélisation doit
être compris par les experts métier.
 Pièges de la modélisation
• Absence de documentation
– Il est beaucoup trop fréquent de rencontrer des modèles
non documentés. Les diagrammes ne suffisent pas et
doivent être accompagnés d’explications

– Résolution: Insistez pour disposer d’une

documentation, comme texte descriptif du modèle ou
un dictionnaire de données, et lisez-la attentivement
 Pièges de la modélisation
• Absence de revues techniques
– Il est également fréquent de constater l’absence de revues
techniques. Chaque personne ou chaque petit groupe
travaille dans son coin sur sa propre application sans
partager ses expériences, ses connaissances et son talent

– Résolution: Tous les projets doivent être soumis au moins à

une revue technique formelle, l’idéal étant d’en avoir
plusieurs. Les revues entre pairs permettent de détecter
60% des défauts d’un logiciel.
 Plan

1. Introduction au Génie Logiciel

2. Vue d’ensemble du processus
3. Développement itératif
4. Gestion de la modélisation
5. Systèmes patrimoniaux
 Introduction
• La plupart des développements ne concernent
pas de nouvelles applications mais plutôt
l’évolution d’applications existantes

• Même lorsque vous avez à construire une

nouvelle application, vous aurez besoin de
collecter des informations à partir d’applications
existantes et de les intégrer à la nouvelle
 Introduction
• Il difficile de modifier une application si
vous ne comprenez pas sa conception

• En cas d’absence ou de perte des

modèles, commencez par construire un
modèle de l’existant
 Rétro-ingénierie
• Définition
La rétro-ingénierie ou réingénierie est le processus qui
consiste à examiner les artefacts de l’implémentation
et qui en déduit la logique sous-jacente

• La rétro-ingénierie ne vise pas à perpétuer les erreurs

précédentes. Elle doit déterminer ce qu’il faut
conserver et ce qu’il faut écarter
 Rétro-ingénierie
• La personne chargée de la rétro-ingénierie
doit surmonter au moins deux problèmes
relatifs au code du programme:

– l’extraction d’information obscures ou

perdues et
– la découverte de comportements implicites
 Entrées de la rétro-ingénierie
• Avec la rétro-ingénierie, vous devez vous
montrer ingénieux et examiner toutes les
entrées:
– Code des programmes
– Structure des bases de données
– Données
– Formulaires et rapports
– Documentation
– Compréhension de l’application
– Cas de test
 Sorties de la rétro-ingénierie
• La rétro-ingénierie comprend plusieurs
sorties utiles:

– Modèles
• Le modèle véhicule le périmètre et la finalité du logiciel
• Il sert de base pour comprendre le logiciel d’origine et pour
construire son successeur
Sorties de la rétro-ingénierie
– Correspondances
• Vous pouvez lier des attributs du modèle à des
variables. Plus généralement, vous devez lier du
code de programmation à des modèles d’états et
d’interactions

– Journaux
• Les rétro-ingénieurs devraient enregistrer leurs
observations et les questions en suspens. Un journal
documente les décisions et la logique