Notes de Cours INF 23299 GENIE LOGICIEL PDF

Notes de cours
INF-23299 – GÉNIE LOGICIEL II
Par
Martin Lesage
Recueil de notes de cours produit pour le cours

INF-23299 – Génie Logiciel II
Basé sur : Pressman, R. S. (2001). Software engineering: A

practitioner's approach (5th ed.). McGraw Hill.
Université du Québec à Rimouski (UQÀR)

Janvier 2002
DÉPARTEMENT DE MATHÉMATIQUES, D'INFORMATIQUE ET DE GÉNIE
PLAN DE COURS
SESSION: HIVER 2002
SIGLE: INF-232-99
TITRE: Génie Logiciel II
GROUPE : 05
HORAIRE COURS : Jeudi 19H15 à 22H05 LOCAL: K-410
DÉBUT : 10 janvier 2002
CHARGÉ DE COURS :
Martin Lesage
Bureau : K-113
Téléphone(UQAR) : 724-1986 Poste :1277
Téléphone(CÉGEP de Rivière-du-Loup) : (418) 862-6903 Poste : 561
Télécopieur : 724-1879
Courriel : marles@cegep-rdl.qc.ca
Site internet du cours : http://www3.uqar.uquebec.ca/coursroy/inf23299
DESCRIPTION DU COURS SELON L'ANNUAIRE
Comprendre les principes et la problématique de la conception, de la mise en œuvre et de la

maintenance de logiciels.
Principes d’architecture, de conception et de réalisation d’un logiciel. Rôle de la conception dans

le cycle de vie du logiciel. Modèles d’architectures : à niveaux, en couches, distribuée.
Apprentissage et évaluation de méthodes de conception. Outils de conception. Cadres
d’application et patrons de conception. Prototypage. Assurance qualité : méthodes de preuve de
code, d’inspection de programmes, essais unitaires, fonctionnels et de système. Gestion de la
maintenance. Réutilisation et rétro-ingénierie des logiciels.
INSERTION DU COURS DANS LE PROGRAMME
Obligatoire dans le programme de baccalauréat en informatique

Préalables : INF-23199 et INF-25199
OBJECTIFS DU COURS
Initier les étudiantes et étudiants à la discipline du génie logiciel mais plus spécifiquement à
l'architecture et à la conception des logiciels, ainsi qu'au contrôle de la qualité des logiciels tant
dans la phase de conception que dans la phase de réalisation technique.
CONTENU DU COURS
Le cours s’appuie essentiellement sur l’ouvrage de référence obligatoire suivant :

Pressman, Roger S.
th
Software engineering: A practitioner’s approach, 5 edition
New York, N.Y.: McGraw-Hill, 2000.
FORMULES PÉDAGOGIQUES
Une rencontre de trois (3) heures chaque semaine avec le professeur pour couvrir les aspect
théoriques, faire des études de cas et des exercices dirigés. Des lectures personnelles dans
l’ouvrage de référence obligatoire devront être effectuées par l'étudiant(e) avant chaque
rencontre avec le professeur. Quatre travaux pratiques sont aussi prévus.
LECTURES OBLIGATOIRES
Pressman, Roger S.
th
Software engineering: A practitioner’s approach, 5 edition
New York, N.Y.: McGraw-Hill, 2000.
Cet ouvrage est un classique en matière de génie logiciel. Il sera aussi utilisé dans les
cours Génie logiciel I et Génie logiciel III. Dans le cadre de Génie logiciel II, 14 chapitres
de l'ouvrage seront couverts.
ÉVALUATION
Type d’épreuve Pondération

Travail Pratique 1 10% Remise le 7 février
Travail Pratique 2 10% Remise le 7 mars
Travail Pratique 3 10% Remise le 28 mars
Travail Pratique 4 10% Remise le 18 avril
Examen Intra 30% Date de l’épreuve : 21 février
Examen Final 30% Date de l’épreuve : 25 avril
Modes d’évaluation :
Examens : Les examens sont des épreuves écrites.

Travaux pratiques : Les travaux sont faits individuellement.
Politique du français : Jusqu'à 10% des points peut être accordé à la qualité du français écrit
dans les travaux et les examens.
Notation proposée (correspondance de la note chiffrée à la note littérale, s'il y a lieu)

L’établissement de la cote finale est basé sur le barème des cotes fixes suivant :
Cote Note
A+ 93%
A 90%
A- 87%
B+ 83%
B 80%
B- 77%
C+ 73%
C 70%
C- 67%
D+ 63%
D 60%
E <60%
CALENDRIER DES RENCONTRES
Sem Date
1 10 janvier Généralités et modèles de conception des systèmes
Lectures : Livre de Pressman, chapitre 1 et 2
2 17 janvier Assurance de la qualité du logiciel
Lectures : Livre de Pressman, chapitre 8
Remise de l’énoncé du travail pratique 1
3 24 janvier Principes de conception des systèmes
4 31 janvier Concepts et principes d’analyse des systèmes
5 7 février Technique d’analyse des systèmes (Modèle entité-relation, DFD)
Remise du travail pratique 1/ Remise de l’énoncé du travail pratique 2
6 14 février Généralités et principes de la conception du logiciel
7 21 février Examen Intra
8 28 février Semaine de Lecture
9 7 mars Méthodes de conception du logiciel
10 14 mars Méthodes de conception des interfaces-usager
11 21 mars Principes et méthodes d’évaluation du logiciel
12 28 mars Stratégies d’évaluation des systèmes
13 4 avril Techniques quantitatives d’évaluation de la performance des systèmes
14 11 avril Ingénierie du logiciel basée sur les composantes
15 18 avril Ré-ingénierie et rétro- ingénierie du logiciel
Remise du travail pratique 4
16 25 avril Examen Final
ÉCHÉANCIER DE REMISE DES TRAVAUX ET EXAMENS
Travaux
Type d’épreuve Pondération Date de Remise
Travail Pratique 1 10% 7 février
Travail Pratique 2 10% 7 mars
Travail Pratique 3 10% 28 mars
Travail Pratique 4 10% 18 avril
Examens
Examen Pondération Date de l’épreuve

Examen Intra 30% 21 février
Examen Final 30% 25 avril
MODALITÉS PARTICULIÈRES
Pénalité pour retard des travaux : Tout retard dans la remise d’un travail expose l’étudiant(e) à
perdre 1 point par jour de retard.
Plagiat : Tout élève qui aura copié ou essayé de copier, de quelque façon que ce soit sera
aussitôt renvoyé de la salle d’examen, aura son travail annulé et son cas soumis à l’autorité
compétente qui appliquera des sanctions proportionnées à la faute.
RÉFÉRENCES BIBLIOGRAPHIQUES
Sur le génie logiciel:
Jalote, Pankaj
ième
An integrated approach to software engineering, 2 édition
New York : Springer, c1997.
Pfleeger, Shari Lawrence

Software engineering : theory and practice
Upper Saddle River, N.J. : Prentice Hall, c1998.
Sommerville, Ian
ième
Software engineering, 5 édition
Addison-Wesley, c1996.
Sur l'analyse et la conception:

En français
Booch, Grady, Analyse et conception orientées objets, Addison-Wesley (FR) 1994

Boulet, Marie-Michèle, L'analyse informatique: concepts, principes et règles, Presses de l'Université Laval,
1994
Coad, Peter; Yourdon, Edward, Analyse Orientée objets, Masson/Prentice-Hall, 1993
Coad, Peter; Yourdon, Edward, Conception Orientée objets, Masson/Prentice-Hall, 1993
Coleman, Derek, Fusion: la méthode orientée-objet de 2e génération, Masson, 1996
Desfray, Philippe, Modélisation par objets : la fin de la programmation, Masson 1996
Jacobson, I. et al., Le génie logiciel orienté objet, Addison-Wesley 1993
Moreau, René, L'approche objets : concepts et techniques, Masson 1995
Rumbaugh, James et al. OMT: modélisation et conception orientées objet, Masson, 1996
Rumbaugh, James et al. Solution des exercices, Masson, 1996
En anglais
Booch, Grady, Object-Oriented Analysis and Design with Applications, Benjamin/Cumming,1994

Brown, David, An Introduction to Object-Oriented Analysis, Wiley 1997
Coad, Peter, Object Models, Strategies, Patterns, & Applications, Yourdon Press, 1997
DeMarco, Tom, Structured Analysis and System Specification. Prentice-Hall, 1978
Embley, David et al. Object-Oriented Systems Analysis: A Model-Driven Approach, Yourdon Press, 1992
Jacobson, Ivar et al., Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-
Wesley, 1992
Larman, Craig , Applying UML and patterns : an introduction to object-oriented analysis and design, Prentice
Hall, 1998.
Lockheed Martin advanced concepts center, Succeeding with the Booch and OMT Methods, Addison-
Wesley, 1996
Sanders, G. Lawrence, Data Modeling, Boyd and Fraser, 1995
Shlaer, Sally; Mellor, Stephen J., Object-Oriented Systems Analysis, Modeling the World in Data, Prentice-
Hall, 1988
Shlaer, Sally; Mellor, Stephen J., Object Lifecycles, Modeling the World in States, Prentice-Hall, 1992
COURS 01
Livre de Pressman, chapitres 1 & 2
Chapitre 1 : Le produit
“Bug” de l’an 2000
- ignoré durant des années. Les compagnies ne voulaient pas

investir de l’argent pour un logiciel qui fonctionnait bien
- beaucoup d’ordinateurs et de logiciels n’avaient pas la

représentation de l’an 2000 dans leurs spécifications. L’année
était codée sur deux chiffres : de 00 à 99
- quelque temps avant le passage à l’an 2000, une soudaine

panique s’est emparée des dirigeants d’entreprise, des médias,
des informaticiens et de la population en général envers une
panne mondiale des systèmes informatiques qui pourrait tout
paralyser
- quelles seront les répercussions de pannes de logiciel dans les

cas suivants :
o système de défense et de lancement de missile,

o systèmes d’alarme et de surveillance,
o systèmes de contrôle de bateaux et d’avions,
o systèmes de gestion bancaire,
o perte du jour et de la date pour certains anciens systèmes
informatique,
o etc.
- les compagnies ont investi des sommes d’argent considérables

afin de rendre tous leurs logiciels compatible à l’an 2000
Bien qu’inexistant avant les années 1950, les logiciels sont
maintenant rendus essentiels à la vie moderne en raison de
l’omniprésence des ordinateurs dans la vie moderne. Les logiciels
sont essentiels dans les domaines suivants :
- science
- génie
- transport
- médical
- télécommunications
- militaire
- industriel
- éducation
- jeux
- bureautique
- etc.
L’industrie du logiciel possède un marché de 500 milliards de dollars.
Phénomène des compagnies « dot-com » :
- Yahoo, Amazon, E-Bay

- Rapport: Actifs de la compagnie/Évaluation du marché
- Un logiciel ou une base de données peut avoir une très grande
valeur
Les gouvernements commencent à légiférer les compagnies voulant

prendre le monopole du logiciel (Microsoft).
Les compagnies de logiciels sont en train de développer des

techniques pouvant produire des logiciels plus facilement, rapidement
et de meilleure qualité.
1.1 L’évolution du rôle du logiciel
Présentement le logiciel jour deux rôles principaux :
1) C’est un produit/Programme
Le logiciel permet d’utiliser et de faire fonctionner le matériel

ou des réseaux d’ordinateurs. Son but est de transporter ou
de transformer l’information. Exemples : logiciel permettant
de faire fonctionner un téléphone cellulaire, des freins ABS
ou de faire un rapport d’impôt.
2) Moyen d’obtenir un produit/Programme servant à faire

fonctionner d’autres programmes :
o Système d’exploitation
o Logiciels de gestion de réseaux(Ex : Novell)
o Logiciels de création et de contrôle de programmes(Ex :
compilateurs)
Le logiciel fait la gestion/le transport/la transformation du produit le

plus important de notre ère : l’information
Le logiciel fait la gestion de l’information personnelle(ex : transactions

bancaires), de l’information du monde des affaires et donne un accès
internet (réseau mondial d’information) qui permet d’acquérir de
l’information sur toute ses formes.
Le rôle du logiciel a changé beaucoup au cours des 50 dernières

années. Des changements radicaux dans la performance des
ordinateurs, des systèmes d’exploitation et des réseaux on fait que
l’humanité est passée à l’ère de l’information.
Le fait d’avoir des ordinateurs puissants permet de développer des
applications impressionnantes lorsqu’elles fonctionnent bien. Le fait
de développer de gros logiciels peut poser des problèmes majeurs
aux développeurs et aux concepteurs de logiciels.
Le programmeur solitaire des décennies passées a été remplacé par

des équipes multidisciplinaires de spécialistes de développement du
logiciel, chacun se spécialisant dans un domaine de la technologie
nécessaire à la réalisation d’une application complexe.
Malgré l’augmentation du nombre de programmeurs et de l’ajout de

spécialistes dans les équipes de développement de logiciels,
certaines problématiques persistent :
- quantité de temps nécessaire pour terminer un logiciel
- coûts de développement élevés
- il existe encore des erreurs dans le logiciel même lorsque celui-

ci est livré au client
- les gestionnaires de projets ont de la misère à évaluer le taux

de réalisation et la date de finition lors du développement du
logiciel
Cette problématique est étudiée dans la discipline du génie logiciel

1.2 Le logiciel
Le logiciel est :
- un ensemble d’instructions(programme d’ordinateur) qui

lorsqu’il est exécuté, produit les bonnes fonctions et résultats
- des structures de données permettant aux programmes de

manipuler adéquatement l’information
- la documentation expliquant les opérations et l’utilisation des

programmes
1.2.1 Caractéristiques du logiciel
Le logiciel est une composante logique(algorithmique) plutôt que

physique. C’est pour cela que le logiciel a des caractéristiques
différentes du matériel :
1) Le logiciel est développé, il n’est pas manufacturé au sens

propre du terme
Ressemblances avec la production des composantes :
o une haute qualité est obtenue par l’entremise d’une

bonne conception
o la qualité du produit dépend de la compétence du
personnel
o les erreurs peuvent se corriger
o obtention d’un résultat final
Différences :
o le matériel peut être difficilement corrigé ou arrangé

o relations entre le personnel
o type de travail
Un projet de conception de logiciel ne peut pas être géré

comme la conception du matériel
2) Le logiciel ne s’use pas
Graphique du taux de panne du matériel en fonction du temps
Taux de panne
Temps de vie du matériel
- le matériel est sujet à tomber en panne au début de sa vie

principalement à cause des défauts de fabrication
- les défauts sont corrigés et le matériel a un taux de panne

relativement bas durant sa période de vie active
- vers la fin de la vie du matériel, il y a une recrudescence des

pannes due à la poussière, la température, les vibrations, et le
vieillissement des composante. Le matériel est donc sujet à
l’usure.
Graphique du taux d’erreurs du logiciel en fonction du temps
- les erreurs non découvertes vont causer un taux élevé d’erreurs

lors du début de la vie d’un programme
- au cours de la vie du programme, les erreurs sont corrigées, le

programme devient plus robuste et la courbe va en s’atténuant
- bien que le logiciel ne puisse pas s’user, il peut se détériorer à

la suite de modifications ou de l’entretien
- toute modification ou transformation du logiciel peut engendrer

de nouvelles erreurs (effet de bord)
- l’entretien du logiciel est plus complexe que l’entretien du

matériel en raison que l’erreur a été produite par le processus
de conception du logiciel. Les composantes matérielles ont
seulement à être remplacées par des pièces de rechange
3) Bien que l’industrie produisant du matériel informatique
s’oriente vers l’assemblage de composantes préfabriquées,
la plupart des logiciels sont fabriquée sur mesure
o Les composantes réutilisables ont été crées afin que

l’ingénieur puisse se concentrer sur les éléments
innovateurs d’un produit, c’est à dire la partie de la
conception qui fait quelque chose de nouveau
o Au niveau du matériel, l’utilisation de composantes

préfabriquées est une partie naturelle de la conception
o Au niveau du logiciel, l’utilisation de modules réutilisables

(librairies de routines scientifiques, graphiques, structures
de données, fenêtres, boutons, etc.) est une nouvelle
technique qui va beaucoup être utilisée dans le futur
1.2.2 Applications du logiciel
Un logiciel peut modéliser toute situation pour laquelle un ensemble

de procédures (algorithme) ont été définies. Quelques exceptions à
cette règles sont les logiciels de systèmes experts, réseaux
neuroniques et autres applications de l’intelligence artificielle.
Les domaines suivants du logiciel résument les tendances actuelles

du développement d’applications :
- Logiciels de système : Un logiciel de système est un ensemble

de programmes servant à faire fonctionner ou à générer
d’autres programmes. Exemples : système d’exploitation,
compilateur, éditeur de texte, pilote de logiciel (driver)
- Systèmes/logiciels en temps réel : Un logiciel qui surveille,

contrôle et analyse des événements du monde extérieur
lorsqu’ils se produisent sont définis comme étant en temps réel.
Exemples : pilote automatique d’un avion
- Systèmes/logiciels de gestion : Le traitement de l’information
relatif aux application de gestion est le plus vaste domaine des
applications de gestion. Exemples : systèmes de comptabilité,
systèmes de paye, gestion des inventaires, systèmes
d’enregistrement des transactions, systèmes d’aide à la
décision
- Systèmes/logiciels d’applications scientifiques : les logiciels

scientifiques effectuent généralement beaucoup de calculs.
Exemple : logiciels d’analyse numérique, conception par
ordinateur(CAD), programmes de simulation des systèmes
- Logiciel imbriqués. Ces logiciels sont souvent en mémoire

morte (ROM) et fonctionnent sans système d’exploitation.
Exemples : système de contrôle de four micro-ondes, freins
ABS, injection électronique
- Logiciel d’ordinateur personnel. Ce marché du logiciel a évolué

énormément lors des deux dernières décennies. Exemples :
logiciels de traitement de texte, chiffriers électronique, bases de
données, jeux, multimédia, réseaux, internet
- Logiciel/application basée sur le Web : les pages Web

visualisées sur un navigateur sont des logiciels comprenant des
instructions exécutables (HTML, CGI. Perl ou Java), et des
données(liens, fichiers audio et vidéo). En général, le
réseau(l’internet) devient une sorte d’ordinateur ayant accès à
des quantités illimitées de ressources pouvant être accédées
par un modem ou une passerelle-réseau.
- Logiciel/application d’intelligence artificielle : Un logiciel

d’intelligence artificielle a pour but d’émuler le raisonnement
humain afin de résoudre des problèmes complexes. Ces
logiciels n’utilisent pas les techniques de programmation
classique(algorithmique), Exemples : systèmes-experts,
réseaux neuroniques, preuves de théorèmes, jeux
1.3 La crise du logiciel
Beaucoup d’informaticiens travaillant dans le domaine du

développement de logiciels ont caractérisé les problèmes rencontrés
dans le développement du logiciel comme étant la « Crise du
Logiciel » . Ce terme est né lors de la constatation de pannes de
logiciels ayant en lieu dans le courant de la dernière décennie.
Certaines grandes réussites de l’industrie du logiciel (Linux)

soulèvent la question à savoir si le concept de crise du logiciel est
encore approprié. Les réalisations pratiques du développement du
logiciel font en sorte que les développeurs de logiciels produisent du
code correct plus souvent que du code comportant des erreurs
majeures.
In est également vrai que la crise du logiciel prédite il y a 30 ans n’est

jamais arrivée. Cette crise du logiciel prédite était basée sur les faits
suivants :
- atteinte d’une limite quant à la qualité du logiciel
- atteinte d’une limite quant à la vitesse de développement du

logiciel
- méthode de développement des logiciels
- entretien et correction des erreurs d’un nombre toujours plus

grand de lignes de code
- comment faire face à une demande toujours grandissante de

production de logiciels
1.4 Mythes
Depuis l’avènement des ordinateurs, certains mythes concernant le

développement des logiciels font en sorte qu’ils paraissent très
logiques et ont été parfois appliqués ou énoncés par des
développeurs de logiciels et des gestionnaires.
Aujourd’hui, ces mythes ont été reconnus à leur vraie valeur : des
attitudes et des méthodes qui ont causé beaucoup de problèmes aux
gestionnaires et aux développeurs de logiciels.
Les habitudes, préjugés et comportements étant difficiles à modifier,

certains travailleurs dans le développent du logiciel croient encore à
ces vieux mythes.
Mythes de gestion. Les gestionnaires ayant la responsabilité du

développement du logiciel doivent faire en sorte d’économiser le
budget, de veiller au respect des échéances et d’améliorer la qualité
de la production. Ils peuvent parfois adopter les politiques ou prendre
les actions suivantes :
- Se référer au livre comportant les standards et les procédures

de développement de logiciels de la compagnie
- Achat d’ordinateurs plus puissants
- Affecter plus de programmeurs à un projet en retard
- Transférer des projets informatiques à des consultants

Mythes des clients. Un client ayant besoin d’embaucher un
développeur de logiciel peut être pratiquement n’importe qui. Ce
client n’a peut-être pas de grandes connaissances et peut se fier aux
affirmations suivantes :
- Une idée générales des objectifs à réaliser est suffisante pour

commencer à programmer.
- Les objectifs, les résultats et les fonctions du programmes

peuvent changer constamment, car le code est facile à
modifier.
Mythes des développeurs et des programmeurs. Certains
programmeurs et des développeurs de système croient encore à ces
affirmations qui datent des débuts de la programmation :
- Une fois que le programme est fini et qu’il s’exécute, notre

travail est fini
- Tant q’un programme ne s’est pas exécuté, il n’y a aucun

moyen d’évaluer sa qualité
- Le seul élément livrable d’un projet informatique réussi est le

programme
- Le fait d’appliquer des techniques d’analyse et de génie logiciel

vont nous faire produire des documents inutiles et tout ceci va
ralentir inévitablement le projet.
Chapitre 2 : Le processus de développement du logiciel
Processus de développement du logiciel : Structure pour les tâches

nécessaires au développement du logiciel
2.1 Le génie logiciel : Une technologie stratifiée
Définition de l’IEEE :
Le génie logiciel est :
(1) l’application d’une approche quantifiable, systématique

et disciplinée au développement, à l’opération et à
l’entretien du logiciel; qui est, l’application de
l’ingénierie au logiciel.
(2) l’étude de cette approche.

2.1.1 Processus, méthodes et outils
Le génie logiciel est une technologie stratifiée.
- Qualité : Sa base fondamentale est la qualité car le but

fondamental de cette discipline est de fournir un logiciel de
qualité
- Processus : Élément rassemblant les strates ensemble et qui

permet un développement rationnel et synchronisé du logiciel. Il
est divisé en sous-processus effectuant le contrôle et la gestion
des projets de développement du logiciel et définit le contexte
dans lequel les méthodes techniques sont appliquées, les
livrables sont produits, les échéances sont définies, le
changement est géré et que la qualité est atteinte
- Méthodes : fournissent les connaissances techniques

nécessaires à la construction du logiciel. Les méthodes
englobent un large éventail de tâches comprenant l’analyse des
besoins, la conception, le développement des programmes, les
essais et le support
- Outils : fournissent du support automatisé ou semi automatisé

afin d’aider la le fonctionnement des processus et des
méthodes (Computer-Aided Software Engineering).
2.1.2 Vue générique du génie logiciel
Le processus de réalisation du génie logiciel peut être catégorisé en

trois phases génériques, indépendantes du champ d’application, de
la dimension du projet ou de sa complexité :
- phase de définition(Quoi) : information, fonctions, performance,

comportement, interfaces, contraintes et critères de validation
- phase de développement(Comment) : structure des données,

implantations des fonctions, caractéristiques des interfaces,
génération de code et méthodes de test.
- phase de support (changements)
o Correction : l’entretien correctif modifie le logiciel afin de

corriger les erreurs
o Adaptation : l’entretien adaptatif modifie le logiciel afin

qu’il s’adapte aux changements de son environnement
externe(CPU, système d’exploitation, politiques de
l’entreprise, etc.)
o Amélioration : l’entretien perfectif modifie le logiciel afin

qu’il dépasse ses exigences fonctionnelles originales
o Prévention (Ré-ingénierie du logiciel); la ré-ingénierie

modifie le logiciel afin qu’il soit plus facilement
corrigeable, adaptable et améliorable
- les phases de support comportent les activités concomitantes
suivantes (umbrella activities) :
o contrôle et surveillance des projets
o révisions techniques formelles
o assurance de la qualité du logiciel
o gestion de la configuration du logiciel
o préparation et production de documentation de système
o gestion de la ré-utilisation
o évaluation
o gestion du risque
2.2 Processus de conception du logiciel
- cadre des processus communs : est établi en définissant un

petit nombre d’activités du cadre qui sont applicables à tous les
projets de logiciel sans tenir compte de leur taille ou de leur
complexité
- ensemble des tâches : ensemble de travaux relatifs au génie

logiciel, échéances de projet, produits livrables et facteurs
d’assurance de qualité permettant aux activités de cadre d’être
adaptées aux caractéristiques du projet et aux exigences de
l’équipe du projet
- activités concomitantes (umbrella activities) : sont

indépendantes de toutes les activités de cadre et s’exécutent
tout au long du projet.
2.3 Modèles de conception du logiciel
Un modèle de conception de logiciel est basé sur la nature du projet

et de l’application, les méthodes et les outils à utiliser, le contrôle et
les livrables nécessaires.
Tous les modèles de développement peuvent être caractérisés par

un cycle de solution des problèmes comportant quatre états :
(1) statut quo : l’état actuel du système

(2) définition du problème : le problème spécifique à
résoudre
(3) développement technique : résoudre la problème à
l’aide de l’application d’une technologie
(4) intégration d’une solution : fournir les résultats à ceux
qui ont initialement demandé une solution
Ce cycle est récursif et chaque étape du cycle de solution du

problème peut contenir un cycle identique.
2.4 Modèle linéaire séquentiel
Parfois appelé cycle de vie classique ou modèle de la chute d’eau, le

modèle linéaire séquentiel suggère une approche systématique et
séquentielle au développement du logiciel débutant au niveau du
système et qui progresse vers les phases d’analyse, de conception,
de la programmation, des tests et du support. Le modèle linéaire
séquentiel comprend les phases suivantes :
- modélisation et ingénierie des systèmes et de l’information
- analyse des besoins du logiciel
- conception(structure de données, architecture du logiciel,

représentation de l’interface et spécifications des routines)
- génération de code
- vérification(tests/détection des erreurs)
- support
2.5 Le prototypage
Souvent, un client définit un ensemble d’objectifs généraux pour un

logiciel mais ne définit pas en détails les entrées, les sorties et les
traitements du programme. Dans d’autres cas, un développeur de
logiciel doute de l’efficacité d’un algorithme, des capacités
adaptatives d’un système d’exploitation ou de l’aspect qu’une
interface personne-machine pourrait avoir. Dans ces cas et plusieurs
autres situations, l’approche par prototypage pourrait-être la
meilleure.
L’approche par prototypage débute par la collecte des spécifications.

L’analyste de systèmes et le client se rencontrent et définissent les
objectifs globaux du logiciel, ses besoins et contraintes et soulignent
les domaines nécessitant d’être définis ultérieurement dans le projet.
Un prototype représentant les aspects visible à l’usager est alors

crée.
2.6 Le modèle RAD
Le modèle RAD (Rapid Application Development) est un processus

évolutif servant à développer une application rapidement. Ce modèle
se caractérise par un très court cycle de développement des
applications.
Le modèle RAD est une version plus rapide du modèle linéaire

séquentiel dans lequel le développement rapide est réalisé par une
construction modulaire.
Si les besoins sont bien compris et que la portée du projet est

restreinte, le processus RAD permettra à l’équipe de développement
de réaliser un système parfaitement opérationnel dans des périodes
de temps très courtes(60 à 90 jours). Le modèle RAD comprend les
phases suivantes :
- Modélisation du processus de gestion

- Modélisation des données
- Modélisation des processus
- Génération de l’application
- Essais et livraison du module
2.7 Modèles évolutifs
Il est maintenant reconnu que le logiciel, comme tous les systèmes

complexes, évolue sur une période de temps. Les besoins des
opérations et des livrables changent même lors des phases du
développement, rendant ainsi le produit fini non viable.
Les exigences du marché font parfois en sorte qu’il est impossible de

terminer un logiciel complexe, mais une version abrégée peut être
introduite pour faire face aux logiciels concurrents.
Un ensemble de produits de base ou des spécifications de systèmes

peuvent être bien définies mais les détails de production ou certaines
modifications ou ajouts peuvent rester à définir.
Dans ce genre de situations, les développeurs de logiciel ont besoin

de modèles de développement pouvant tenir compte que les
spécifications d’un produit peuvent toujours évoluer.
Les modèles évolutifs sont itératifs et permettent aux développeurs

de logiciels de développer des versions plus complètes des logiciels.
2.7.1 Modèle incrémentiel
Le modèle incrémentiel combine les caractéristiques du modèle

linéaire séquentiel appliqué répétitivement avec l’approche par
prototypage
2.7.2 Modèle en spirale
Le modèle en spirale est un modèle évolutif de développement du

logiciel joignant la nature itérative du prototypage avec les aspects
contrôlés et systématique du modèle linéaire séquentiel. Il permet le
développement de versions incrémentielles du logiciel.
Lors de l’utilisation du modèle en spirale, le logiciel est développé en

une série de versions incrémentielles. Lors des premières itérations,
la version peut être un prototype ou simplement des plans de
système. Les dernières itérations produisent des versions améliorées
du logiciel.
Le modèle en spirale est divisé en six régions de tâches :
- Contact avec le client
- Planification du projet
- Analyse du risque
- Ingénierie(programmation et réalisation du logiciel)
- Livraison et implantation du support à l’usager
- Évaluation du client(feedback)
2.7.3 Modèle en spirale WINWIN(Gagnant-Gagnant)
Le modèle en spirale comporte une étape de son processus qui est

l’interaction avec le client. Le but de cette étape set de faire énoncer
par le client les exigences du projet. Dans un contexte idéal,
l’analyste de système demande simplement au client quels sont ses
besoins et le client est en mesure de fournir suffisamment
d’informations et de spécifications pour en arriver à débuter le projet.
Dans la pratique, cette situation n’arrive pas souvent. Le client et

l’analyste entrent dans un processus de négociation où le client doit
trouver un équilibre entre les coûts et le temps de réalisation du
système par rapport à la fonctionnalité, la performance et les autres
exigences rattachées à ce système.
Les deux parties négocient afin d’en arriver à une situation

« Gagnant-Gagnant » (WIN-WIN). Cette situation se définit comme
étant que le client gagne en obtenant un produit ou un système
satisfaisant la majorité de ses exigences et que le développeur gagne
en ayant un budget et des échéances convenables à la réalisation du
projet.
Le modèle en spirale définit un ensemble d’activités de négociation

au début de chaque itération dans la spirale. Au lieu d’une seule
étape d’interaction avec le client, les étapes suivantes sont définies :
1) Identification des responsables en charge du développement

du système ou du sous-système du côté du client
2) Détermination des exigences du client(WIN Conditions)
3) Négociation avec le client afin de concilier ses exigences
avec celles de l’équipe de développement du logiciel
L’achèvement avec succès de ces étapes initiales résulte en une

situation « Gagnant-Gagnant » (Win-Win), cette situation devient un
élément essentiel pour débuter l’analyse du système et de ses
logiciels.
En plus de mettre l’accent sur la négociation dans les premières
étapes du projet, ce modèle définit trois balises, appelées points
d’ancrages, qui aident à l’accomplissement d’une révolution dans la
spirale et définissent des étapes de décision avant de débuter le
projet. Ces points d’ancrages servent également à déterminer les
différents aspects du progrès au cours de son évolution dans la
spirale :
1) LCO - Objectifs du cycle de vie – Life cycle objectives :

définit un ensemble d’objectifs pour chaque activité
importante de l’ingénierie du logiciel. Exemple : définition du
système, définitions des spécifications du produit
2) LCA – Architecture du cycle de vie – Life cycle architecture :

definit des objectifs qui doivent être rencontrés tout au long
de la définition du système et de l’architecture du logiciel.
Exemple : l’équipe de développement du projet doit
démontrer qu’elle a évalué les capacités de ré-utilisation des
composantes du logiciel et considéré leur impact au niveau
de l’architecture du logiciel
3) IOC – Capacité opérationnelle initiale – Initial operational

capability : représente un ensemble d’objectifs associé avec
la préparation du logiciel pour l’installation et la distribution
ainsi que l’assistance nécessaire de tous les intervenants
utilisant ou supportant le logiciel.
2.7.4 Modèle de développement concurrent (Ingénierie concurrente)
Le modèle de développement concurrent peut être représenté

schématiquement par une série d’activités techniques majeures, de
tâches et de leurs états associés.
Toutes les activités existent concurremment mais sont dans différents

états.
Le modèle de développement concurrent définit une série

d’événements qui vont déclencher des transitions d’un état à un autre
pour chacune des activités de l’ingénierie du logiciel. Exemple :
durant les premières étapes de la conception, une inconsistance
dans le modèle d’analyse est découverte. Ceci génère l’événement
« Effectuer des corrections au modèle d’analyse » qui va faire passer
l’activité d’analyse de l’état « accompli » à l’état « en attente de
changements ».
Le modèle de développement concurrent est applicable à tous les

types de développement de logiciels et donne une image précise de
l’état courrant d’un projet. Au lieu de reléguer les activités de
l’ingénierie du logiciel à une séquence d’événements, ce processus
est plutôt défini comme étant un réseau d’activités concurrentes. Les
événements générés par les activités déclenchent des changements
au niveau des états des activités.
2.8 Développement orienté vers les composantes
L’approche orientée-objet fournit le cadre technique d’un modèle

basé sur les composantes de l’ingénierie du logiciel. Le paradigme de
l’approche orientée-objet met l’accent sur la création de classes
englobant les données et les algorithmes effectuant des opérations
sur ces données.
Les classes orientées-objet adéquatement conçues et implantées

sont réutilisables par différentes applications et systèmes
informatiques.
Le modèle de développement orientée sur les composantes inclut

plusieurs des caractéristiques du modèle en spirale de par sa nature
évolutive consistant en une approche itérative du développement du
logiciel.
Cependant, le modèle de développement orienté sur les

composantes développe des applications à base de composantes
logicielles modulaires appelées classes.
2.9 Méthodes formelles
Les méthodes formelles englobent un ensemble d’activités basées

sur la spécification mathématique formelle du logiciel.
Les méthodes formelles rendent la discipline du génie logiciel de

spécifier, développer et de vérifier des systèmes informatiques en
appliquant une notation mathématique rigoureuse.
Lorsque des méthodes formelles sont utilisées durant le

développement du logiciel, elles fournissent un mécanisme
d’élimination de problèmes difficiles à résoudre en utilisant d’autres
techniques de l’ingénierie du logiciel.
L’ambiguïté, l’incomplétude et l’inconsistance peuvent être

découverte et corrigées plus adéquatement avec l’application de
l’analyse mathématique.
Lorsque des méthodes formelles sont utilisées lors de la conception,

elles constituent une base à la vérification du code et permettent au
développeurs de logiciel de découvrir et de corriger certaines erreurs
ne pouvant pas être détectées autrement.
2.10 Techniques de quatrième génération
Le terme « Technique de quatrième génération » englobe un vaste

éventail d’outils de conception de logiciel : chacun permet au
développeur de spécifier les caractéristiques et les fonctionnalités du
logiciel à un haut niveau.
L’outil de quatrième génération génère alors automatiquement le

code source de l’application basé sur les spécifications du
développeur.
Le paradigme de l’ingénierie du logiciel à l’aide des outils de

quatrième génération se concentre sur les capacités d’effectuer des
spécifications du logiciel en utilisant des langages spécialisés ou une
notation graphique décrivant le problème à résoudre dans une
notation qu’un utilisateur pourrait facilement comprendre.
L’utilisation des outils de quatrième génération est une approche

viable pour différents domaines d’applications. Combiné avec des
générateurs de code et des outils de conception de logiciel assistée
par ordinateur, les outils de quatrième génération offrent une solution
crédible à plusieurs applications de développement de logiciel.
Des informations venant du domaine de la pratique indiquent que les

langages de quatrième génération réduisent le temps d’analyse, de
conception et de développement pour des petites et moyennes
applications.
Dans le cas d’applications majeures, le temps de développement

d’applications à l’aide de langages de quatrième génération est
similaire ou supérieur aux méthodes de développement classiques.
2.11 Technologie du processus(outils d’analyse des processus)
Les modèles de développement du logiciel doivent être adaptés aux

besoins des équipes de développement de logiciels. Afin de réaliser
cette adaptation, des outils d’analyse des processus ont été
développés pour aider les développeurs de logiciels à analyser les
processus courants, organiser les tâches, contrôler et évaluer le
développement et de gérer la qualité du produit.
Les outils d’analyse des processus permettent aux développeurs de

logiciels de modéliser les processus, tâches et activités
concomitantes.
Le modèle, normalement représenté comme un graphe, peut-être

analysé pour déterminer l’ordonnancement des processus et afin de
générer des solutions permettant de réduire les coûts et le temps de
développement.
2.12 Le produit et le processus
A environ tous les dix ans, la communauté du logiciel redéfinit la

problématique comme reposant sur le produit à la problématique
reposant sur le processus.
La problématique orientée sur le produit et la problématique orientée

sur le processus ne forment pas une dichotomie, mais une dualité.
COURS 02
Livre de Pressman, chapitre 8
L’assurance de qualité du logiciel
Le but de l’ingénierie du logiciel : produire des logiciels de haute

qualité.
L’assurance de la qualité du logiciel est une activité concomitante qui

est appliquée tout au long du processus de développement du
logiciel.
L’assurance de qualité du logiciel englobe :
(1) une approche de management de qualité
(2) une technologie efficace de l’ingénierie du logiciel (méthodes

et outils)
(3) des révisions techniques formelles appliquées tout au long

du développement
(4) des stratégies de test du logiciel
(5) mises à jour de la documentation du logiciel
(6) des procédures compatibles avec les normes de

développement
(7) mécanismes d’évaluation et de production de rapports

8.1 Généralités concernant la qualité
Toutes les composantes manufacturées sont différentes.
Un manufacturier veut minimiser les différences entre les

exemplaires d’un même modèle.
Au niveau du logiciel :
- minimiser les différences entre les ressources

évaluées et les ressources nécessaires pour compléter
un projet
- le programme de test doit être en mesure d’évaluer le

logiciel d’une version à une autre
- minimiser le nombre d’erreurs d’une version à une

autre
- minimiser le support au client
8.1.1 Qualité
La qualité d’un logiciel s’évalue par rapport à des normes définies

telles que :
- complexité
- cohésion
- nombre de points de fonctions
- lignes de code
Lorsque nous examinons un item basé sur ses caractéristiques
mesurables, nous pouvons retrouver deux types de qualité :
- qualité de la conception : caractéristiques spécifiées

par les concepteurs pour un item telles que la qualité
des composantes, les tolérances et les spécifications
de performance.
- qualité de conformisme : degré auquel les

spécifications de conception ont été respectées durant
la production
8.1.2 Contrôle de qualité
Le contrôle de la qualité implique les séries d’inspections, de

révisions et de tests utilisés tout au long du processus de
développement du logiciel afin de s’assurer que chaque composante
rencontre les spécifications définies dans l’analyse.
Le contrôle de la qualité comprend une boucle de rétroaction (feed-

back) au niveau du processus ayant crée le produit.
8.1.3 Assurance de qualité
L’assurance de la qualité consiste à la vérification et à la production

de rapports de gestion. Le but de l’assurance de la qualité est de
fournir les informations nécessaires aux gestionnaires afin de les
informer du niveau de la qualité du produit. Les gestionnaires
pourront ainsi évaluer et s’assurer que le produit rencontre les
exigences déterminées.
8.1.4 Coût de la qualité
Les coûts de la qualité incluent le budget investi dans l’ajout de la

qualité au produit ou dans toutes les actions d’évaluation de la
qualité. Ces coûts peuvent être divisés en :
- coûts de prévention (planification de la qualité,

révisions techniques formelles, équipement de test,
formation)
- coûts d’évaluation : comprend des activités pour

déterminer l’état du produit lors de la première
réalisation de chaque processus. (test, calibration et
entretien de l’équipement inspection des processus et
inspection interprocessus)
- coûts de bris interne : coûts des défauts détectés

avant la livraison du produit (reconstruction,
réparations)
- coûts de bris externe : coûts des défauts détectés

après que le produit ait été livré au client(réparations
de garantie, support à l’usager, retour et
remplacement du produit, réponse et solutions aux
plaintes du client)
8.2 La recherche de la qualité
La recherche de la qualité débute dans les années 1940 avec les

travaux de W. Edwards Deming et a été vérifiée pour la première fois
au Japon. Utilisant les concepts définis par Deming, l’industrie
Japonaise a développé une approche systématique qui sert à
éliminer à la base les défauts des produits.
Cette approche a maintenant le nom de gestion de la « qualité

totale » et comporte quatre étapes d’évolution :
(1) kaizen - amélioration continue des processus :

développement d’un processus de développement de
logiciel visible, répétable et mesurable
(2) atarimae hinshitsu – cette étape examine les éléments

intangibles affectant les processus et vise à optimiser leur
impact sur le processus. Exemple : réduire le changement
d’affectation du personnel
(3) kansei – étudie l’utilisation que le client fait du produit –

conduit à l’amélioration du produit et des processus qui le
crée
(4) miryokuteki hinshitsu – observation de l’utilisation du produit

dans le marché – découverte de nouvelles extensions ou
d’applications qui seraient une extension d’un système
informatique existant
8.3 L’Assurance de qualité du logiciel
La qualité du logiciel est définie comme étant :
La conformité aux exigences fonctionnelles et de performance

explicitement définies, aux exigences de développement
explicitement documentées et des caractéristiques implicites qui sont
attendues de tout logiciel professionnellement développé.
8.3.1 Historique
Assurance de la qualité des objets manufacturés
- avant 1900 : professionnalisme de l’ouvrier
- 1916 – Bell Labs – modèle formel d’assurance et de

contrôle de la qualité
- 1940 – avènement d’autres approches formelles

basées l’évaluation et l’amélioration continue des
processus
Assurance de la qualité du logiciel
- 1950-1960 – la qualité est la responsabilité du

programmeur
- 1970 – des normes d’assurances de qualité ont été

stipulées dans des contrats de développement de
logiciels pour la défense. Ces normes ont été
rapidement reprises par les organismes et les
compagnies de développement de logiciel civiles.
8.3.2 Activités visant à assurer l’assurance de qualité
Les activités suivantes sont effectuées par une équipe indépendante

d’évaluateur de qualité du logiciel :
- Préparation d’un plan d’assurance de qualité pour un

projet. Ce plan contient :
i.évaluation à être effectuées

ii.vérifications et révisions
iii.normes (standards) applicables aux projets
iv. procédures de détection et de signalisation des
erreurs
v. rapports à être produits par l’équipe d’évaluation du
logiciel
vi. quantité de rétroaction (feedback) à être fournie par
l’équipe de développement du projet
- Participation au développement de la description des

processus et des fonctionnalités du logiciel
- Révision des activités de l’ingénierie du logiciel afin de

vérifier si elles sont en accord avec les processus et
les fonctionnalités définies
- Vérification de certaines parties du logiciel afin de

vérifier si leurs résultats sont en accord avec ceux
définis dans le processus de développement du
logiciel
- S’assurer que les écarts entre les résultats de

certaines parties du logiciel et leurs spécifications sont
documentées et traitées en accord avec les
procédures administratives spécifiées dans la
documentation
- Noter tous les écarts des résultats du logiciel par

rapport à ses spécifications et en référer à la direction
8.4 Révision du logiciel
Les révisions du logiciel agissent comme un filtre au niveau du

processus de développement du logiciel. Les révisions sont
effectuées à différentes étapes du développement du logiciel et
servent à découvrir les erreurs et les défauts pouvant être corrigés.
Les révisions du logiciel « purifient » les activités du génie logiciel au

niveau de l’analyse, de la conception et de la programmation.
8.4.1 Impact des coûts des défauts du logiciel
L’objectif primaire des révisions techniques formelles est de découvrir

les erreurs dans les phases de développement pour qu’elles ne
deviennent pas des défauts après la livraison du logiciel. Le principal
avantage de ces révisions est la découverte rapide des erreurs afin
qu’elles ne se propagent pas dans le processus de développement
du logiciel.
Un nombre de rapports de l’industrie indiquent que les activités de

conception introduisent entre 50 et 65% de toutes les erreurs durant
le processus de développement du logiciel. Par ailleurs, les révisions
techniques formelles sont effectives à 75% dans la découverte
d’erreurs de conception.
En prenant pour acquis qu’une erreur non découverte durant les

phases de conception va coûter 1.0 unité monétaire à corriger, voici
les coûts de correction des erreurs lors des phases de
développement suivantes :
Phase Coût
Conception 1.0
Avant les tests fonctionnels 6.5
Durant les tests fonctionnels 15
Après la livraison entre 60 et 100
8.4.2 Amplification des défauts et correction des erreurs
Le modèle d’amplification des défauts peut être utilisé pour illustrer la

génération et la détection des erreurs durant les phases de
conception préliminaire, de conception détaillée et de programmation
de l’ingénierie du logiciel.
Exemple hypothétique d’amplification des défauts dans un processus
de développement de logiciel dans lequel aucune révision n’est
effectuée.
Exemple hypothétique d’amplification des défauts dans un processus
de développement de logiciel dans lequel des révisions de la
conception et du code sont effectuées à chaque étape du processus
de développement
8.5 Révisions techniques formelles
Une révision technique formelle (Formal Technical Review – FTR) est

une opération de l’assurance de qualité effectuée par les ingénieurs
du logiciel et tout autre personne concernée.
Les objectifs de la révision technique formelle sont :
(1) de découvrir les erreurs dans les fonctions, la logique ou

l’implantation du logiciel
(2) de vérifier que le logiciel révisé rencontre ses spécifications
(3) de s’assurer que le logiciel a été réalisé selon des normes

prédéfinies
(4) la réalisation de logiciels développés de manière uniforme
(5) faire en sorte que les projets de développement du logiciel

soient plus faciles à gérer
8.5.1 Les réunions comité de révision
Les réunions du comité de révision devront respecter les contraintes

suivantes :
- la révision devrait impliquer entre trois et cinq

personnes
- la réunion devra exiger de la préparation mais ne

devrait pas exiger plus de deux heures de chaque
participant
- la durée de la réunion devrait être de moins de deux

heures
A la fin du processus, tous les participants aux réunions doivent
décider :
- d’approuver le produit sans modifications
- de rejeter le produit à cause d’erreurs majeures
- approuver le produit conditionnellement à la correction

des erreurs
8.5.2 Rapports de révision et archivage des données
Lors du processus de révision technique formelle, l’un des réviseurs

enregistre toutes les questions soulevées. Ces items sont résumés à
la fin des réunions et une liste est produite. Un rapport de révision
technique formelle est également complété et répondra aux
questions suivantes :
- Quel élément a été révisé?
- Qui l’a révisé?
- Que sont les résultats de la révision et la conclusion?
Une liste des recommandations de révision est incluse dans le

rapport et possède deux utilités :
(1) identifier les problèmes du produit
(2) établir une liste de vérifications des corrections

8.5.3 Lignes directrices de la révision
Les items suivants représentent un ensemble de règles minimales

concernant la révision technique formelle :
- effectuer la révision du produit et non du producteur
- établir une cédule et la respecter
- limiter les débats et les objections
- énoncez les problèmes, mais n’essayez pas de tous

les résoudre
- prise de notes
- limiter le nombre de participants et insister sur leur

préparation
- développer une liste de vérifications pour chaque

produit à réviser
- allocation des ressources et établissement d’une

cédule pour la révision technique formelle
- donner de la formation pertinente à tous les réviseurs
- réviser les anciens rapports

8.6 Approches formelles de l’assurance de qualité
Un programme (algorithme) peut être défini comme étant un objet

mathématique. Une syntaxe et une sémantique rigoureuse peuvent
être définies pour chaque langage de programmation et une
approche similaire est en cours au niveau des spécifications des
fonctionnalités du logiciel.
Si les spécifications et le langages de programmation peuvent être

représentés de façon rigoureuse, il devrait être possible d’appliquer
des preuves mathématiques démontrant qu’un logiciel rencontre
exactement ses spécifications.
8.7 Approches statistiques de l’assurance de qualité
L’approche statistique de l’assurance de qualité reflète une tendance

de plus en plus populaire au niveau de l’industrie quant à l’évaluation
quantitative de la qualité. Au niveau du logiciel, l’assurance
statistique de la qualité implique les étapes suivantes :
(1) l’information concernant les défauts est recueillie et

catégorisée
(2) des tentatives sont effectuées afin de déterminer les causes

des erreurs(déviation des spécifications et de normes,
erreurs de conception et mauvaise communication avec le
client)
(3) utilisation du principe de Pareto (80% des défauts sont reliés

à 20% des causes possibles) pour isoler les causes
principales de pannes du logiciel
(4) une fois les causes principales des pannes identifiées,

effectuer la correction des erreurs ayant causé les pannes
En concurrence avec l’obtention d’informations sur les erreurs, les
développeurs de logiciels peuvent calculer un indice d’erreurs pour
chaque étape principale du processus de développement du logiciel.
Après les phases d’analyse, de conception, de programmation, de

tests et de livraison, les donnés suivantes sont rassemblées :
Ei = le nombre total d’erreurs découvertes durant la ième étape du

processus du développement du logiciel
Si = le nombre d’erreurs majeures
Mi = le nombre d’erreurs modérées
Ti = le nombre d’erreurs mineures
PS = la grosseur du produit à la ième étape
ws, wm, wt = facteurs de pondération pour des erreurs majeures,

modérées et mineures
A chaque étape, un index de phase, PIi est calculé :
PIi = ws(Si/Ei) + wm(Mi/Ei) + wt(Ti/Ei)
L’indice d’erreur est calculé en évaluant l’effet cumulatif de chaque

PIi, pondérant les erreurs rencontrées durant les phases finales du
développement du logiciel plus lourdement que les erreurs
rencontrées au début :
EI = (i x PIi)/PS
8.8 Fiabilité du logiciel
La fiabilité d’un logiciel est un facteur important de sa qualité
La fiabilité du logiciel est définie en termes statistiques comme étant

la probabilité d’une opération sans erreurs d’un programme
d’ordinateur dans un environnement et un espace de temps défini.
8.8.1 Quantification de la fiabilité et de la disponibilité
Temps moyen entre les pannes = Temps moyen pour tomber en

panne + Temps moyen de réparation
La disponibilité du logiciel est la probabilité qu’un programme

fonctionne conformément à ses spécifications à un temps défini.
Disponibilité du logiciel = [Temps moyen pour tomber en

panne/(Temps moyen pour tomber en panne + Temps moyen de
réparation)] X 100%
8.8.2 Sécurité des systèmes
Activité de l’assurance de qualité du logiciel qui se concentre sur

l’identification et l’évaluation d’incidents potentiels pouvant affecter le
logiciel et causer une panne du système entier.
Ci ces incidents probables sont identifiée dans les premières étapes

du processus de l’ingénierie du logiciel, des ajouts et des
améliorations pourront être spécifiées afin d’éliminer ou de contrôler
ces incidents.
8.9 Dispositifs de prévention des erreurs dans le logiciel
Dans les années 1960, un ingénieur industriel japonais, Shigeo

Shingo, travaillant chez Toyota, a développé une technique
d’assurance de qualité conduisant à la prévention et/ou la correction
rapide d’erreurs dans les processus manufacturiers. Ces techniques
peuvent également s’adapter au processus de développement du
logiciel.
Appelés « poka-yoke », ce concept conduit à la construction de

mécanismes ayant pour but :
(1) la prévention de problèmes de qualité avant qu’ils ne se

déclarent
(2) la détection rapide de problème de qualité
Exemples : générateurs de programmes, programmes de vérification

(code, menus, etc.)
8.10 Les normes de qualité ISO 9000
La norme ISO 9000 décrit l’assurance de qualité des éléments en

termes génériques pouvant être appliqués à tout type d’organisation
indépendamment des produits ou des services offerts.
Après avoir adopté le standard ISO, une nation permet uniquement

aux organismes certifiés ISO de fournir des biens et des services aux
organismes de services publics et aux agences gouvernementales.
Les normes ISO s’étendent également aux compagnies privées.
Pour obtenir une certification ISO, une firme d’évaluateurs analysent

les processus de vérification de la qualité et les différentes opérations
d’une entreprise candidate.
8.10.1 L’approche ISO de l’assurance de la

qualité des systèmes
La norme ISO 900 décrit les éléments de l’assurance de qualité en

termes généraux tels que :
- la structure organisationnelle
- les procédures administratives
- les processus
- planification de la qualité
- contrôle de la qualité,
- assurance de la qualité
- amélioration de la qualité
8.10.2 La norme ISO 9001
La norme ISO 9001 est la norme de l’assurance de qualité

s’appliquant à l’ingénierie du logiciel. Elle se base sur les éléments
suivants :
- responsabilités de gestion
- système de qualité
- révision des contrats
- évaluation de la conception
- sécurité des documents et des données
- contrôle des processus
- vérification interne
8.11 Planification de l’assurance de la qualité des systèmes
Le plan de l’assurance de la qualité des systèmes fournit des lignes

directrices pour l’implantation de l’assurance de la qualité du logiciel.
Développé par l’équipe de contrôle de l’assurance de la qualité du
logiciel, ce plan sert de référence pour toutes les activités du contrôle
de l’assurance de qualité du logiciel implantées dans chaque projet
de développement du logiciel.
Ce plan inclut :
- documentation
- procédures à suivre pour l’obtention d’une haute

qualité
- normes
- conventions
- méthodes d’évaluation
- méthodes de report des erreurs
- méthodes de détection des erreurs
- contrôle du changement
- gestion du risque
COURS 03
Livre de Pressman, chapitre 10 - Ingénierie des systèmes
L’ingénierie du logiciel est le résultat des conséquences d’un

processus appelé « ingénierie des systèmes ».
L’ingénierie des systèmes ne se concentre pas uniquement sur le

logiciel, mais également sur des éléments tels que l’analyse, la
conception et l’organisation de ces éléments en un système pouvant
être :
- un produit
- un service
- une technologie de transformation de l’information
- une technologie de contrôle de l’information
Le processus de l’ingénierie des systèmes est appelée « ingénierie

des processus d’affaires» lorsque le contexte de l’ingénierie se
concentre sur une entreprise commerciale. Lorsqu’un produit (dans
ce contexte, un produit pouvant être n’importe quoi : appareils
ménagers, téléphone cellulaire, système de contrôle des vols
d’avions, etc.) est pour être fabriqué, le processus est appelé
« ingénierie des produits ».
L’ingénierie des processus d’affaires et l’ingénierie des

produits tentent d’influencer le développement des systèmes
informatique. Bien que ces deux type d’ingénierie sont appliqués
dans différents domaines d’application, ils ont tous les deux besoin
de logiciels, ils travaillent également pour déterminer le rôle du
logiciel dans leur organisation et d’établir les liens entre le logiciel et
les autres éléments de leur système informatique.
10.1 SYSTÈMES INFORMATISÉS
Le mot « système » est un mot très employé dans la littérature

scientifique. Dans le cas que nous intéresse, nous définirons le terme
« système informatisé » comme étant :
Un ensemble ou une combinaison d’éléments qui sont

organisés pour accomplir des buts prédéfinis par le traitement
de l’information.
La fonction du système peut être le support de certaines fonctions de

gestion ou de développer un produit pouvant être vendu pour
augmenter le chiffre d’affaires. Pour accomplir ce but, un système
informatisé utilise les éléments suivants :
- logiciel : programmes, structure de données et la

documentation relative à la description des méthodes logiques,
procédures et méthodes de contrôle utilisées lors du
développement du système.
- matériel : composantes électroniques fournissant la capacité de

calcul et d’interconnexion (commutateurs, appareils de
télécommunication) permettant le transfert d’information et de
composantes électromécaniques (senseurs, moteurs, pompes,
caméras) pouvant interagir avec le monde extérieur.
- personnel : les usagers, concepteurs et programmeurs du

logiciel.
- base de données : un important dépôt d’information accédé par

le logiciel.
- documentation : information descriptive (livres, informations

d’aide en ligne, sites internet) faisant la description de
l’utilisation et du fonctionnement du système.
- Procédures : étapes définissant l’utilisation spécifique de

chaque élément de système ou le contexte procédural dans
lequel le système réside.
Les éléments du système sont combinés de plusieurs façons afin de
transformer l’information. Exemples :
- le département du marketing transforme des statistiques sur les

ventes en profil typique de l’acheteur d’un produit donné
- un robot transforme un fichier de commandes contenant des
instructions spécifiques en un ensemble de signaux de contrôle
générant des mouvements spécifiques.
10.2 HIÉRARCHIE DE L’INGÉNIÉRIE DES SYSTÈMES
Sans tenir compte du domaine, l’ingénierie des systèmes repose sur

une série de méthodes « top-down » (du haut vers le bas) et
« bottom-up » (du bas vers le haut) permettant la navigation dans la
hiérarchie des systèmes :
- monde extérieur (WV): le domaine d’affaires ou le marché du

produit examiné en entier afin d’établir le type d’affaires ou le
domaine exact du produit. Exemple : Système comptables
WV = {D1, D2, D3, …, Dn}
- domaine(D) : la vue du monde extérieur est ensuite subdivisée

afin de se concentrer sur un domaine d’intérêt spécifique.
Exemple : Système comptables : calcul des bilans financiers,
calcul de l’impôt, calcul de la paye.
Dj = {E1, E2, E3, …, Em}
- élément(E) : à l’intérieur d’un domaine spécifique, le besoin

d’étudier certains éléments spécifiques du système est analysé
(données, logiciel, matériel, personnel). Exemple : Calcul de la
paye : calcul des déductions
Ej = {C1, C2, C3, …, Ck}
- détails/composantes techniques(C) : analyse, conception et

construction d’une composante d’un élément. Exemple : Calcul
des déductions : Calcul des déductions relatives à la Régie des
Rentes du Québec (Pension de vieillesse). Une composante
peut être un programme d’ordinateur, une sous-routine
réutilisable, un module, une classe, un objet ou une ligne de
code
10.2.1 MODÉLISATION DES SYSTÈMES
L’ingénierie des systèmes est un processus de modélisation. Peu

importe si l’objet à modéliser est au niveau monde extérieur ou est
une composante technique, le concepteur de systèmes crée un
modèle ayant les exigences suivantes :
- définit les processus répondant aux besoins de la taille du

système à l’étude (monde, domaine, élément, composante)
- reproduit les comportements/fonction du processus basé sur

les hypothèses sur lesquelles ces comportements sont établis.
- définit explicitement les entrées exogènes (lier une constituante

d’un niveau donné avec des constituantes du même niveau ou
d’autres niveaux) et endogènes(relie des constituantes d’un
même niveau) du modèle.
- représente tous les liens (incluant les sorties) permettant aux

concepteurs de systèmes d’avoir une meilleure compréhension
du modèle.
Afin de modéliser les systèmes, le concepteur de systèmes devra
considérer les contraintes suivantes :
(1) hypothèses : les hypothèses doivent réduire le nombre de

variations possible d’un modèle afin qu’il puisse représenter
le problème d’une manière raisonnable.
(2) simplifications : les simplifications permettent au modèle

d’être crée selon des délais respectables.
(3) limites : les limites définissent le domaine du système.
(4) contraintes : les contraintes vont définir la façon de créer le

modèle et l’approche utilisée pour l’implanter.
(5) préférences : les préférences indiquent le type d’architecture

favorisée par le concepteur du système pour toutes les
données, fonctions et technologies. L’approche choisie peut
parfois entrer en conflit avec certaines contraintes. La
satisfaction du client peut influencer de beaucoup le choix
d’une approche.
SIMULATION DES SYSTÈMES
Dans bien des cas, la façon de construire des systèmes informatique

est de les programmer pour ensuite les faire fonctionner sans faire de
tests ou d’anticiper les résultats produits. Ces méthodes s’appliquent
encore aujourd’hui dans le cas des systèmes réactifs.
Il existe une multitude de systèmes informatiques interagissant avec

le monde réel d’une façon réactive. C’est le cas d’événements du
monde extérieur détectés et surveillés par le matériel et le logiciel
constituant un système informatique capable de contrôler des
machines, processus et même des individus interagissant avec
l’environnement extérieur. Les systèmes en temps réel et les
systèmes intégrés sont souvent inclus dans la catégorie des
systèmes réactifs.
Malheureusement, les concepteurs de systèmes réactifs ont parfois

de la difficulté à les faire fonctionner correctement. Jusqu’à tout
récemment, il était très difficile de prédire la performance, l’efficience
et le comportement de ses systèmes avant leur réalisation.
Les résultats de l’implantation de plusieurs systèmes en temps réel

était aléatoire et les erreurs, anticipées ou non, étaient découvertes
seulement lors du fonctionnement du système. La plupart de ces
systèmes étant affectés au contrôle de machineries ou de processus
devant opérer avec un très haut degré de fiabilité. Une erreur de ces
systèmes pouvait résulter par des pertes d’argent ou de vies
humaines.
Maintenant, les outils de développement du logiciel basés sur la

modélisation et la simulation sont utilisés pour éliminer les erreurs à
l’exécution des systèmes réactifs informatisés. Ces outils sont utilisés
durant le processus de l’ingénierie du logiciel lors des spécifications
des fonctions du matériel, du logiciel, des bases de données et du
personnel.
Les outils de modélisation permettent au concepteur du système de

construire un modèle simulant la réalisation du système à partir de
ses spécifications.
10.3 VISION GLOBALE DE L’INGÉNIERIE DES PROCESSUS
D’AFFAIRES(DE GESTION)
Le but de l’ingénierie des processus d’affaires (Business Process

Engineering/BPE) est de définir une architecture permettant à un
organisme de gérer l’information efficacement.
L’environnement informatique actuel consiste en une puissance de

calcul distribuée à la grandeur de l’entreprise, d’unités de traitement
différentes effectuant un large éventail de tâches telles que des
applications client-serveur, traitement distribués et implantation de
réseaux d’ordinateurs. Ces nouveaux environnements de travail
fournissent aux entreprises la fonctionnalité et la flexibilité
nécessaires à l’accomplissement des tâches de gestion.
Ceci a donné naissance aux organisations de gestion des

technologies de l’information (Information Technology/IT) qui doivent
supporter ces différents traitements.
Chaque organisation de gestion des technologies de l’information doit

faire de l’architecture et de l’intégration de systèmes. Cette
organisation doit également faire la conception, l’implantation et le
support de sa configuration de ressources informatiques. Ces
ressources étant hétérogènes, réparties géographiquement et
logiquement partout dans l’entreprise tout en étant inter-reliées par
un réseau local à l’entreprise.
Cette configuration peut également changer continuellement, mais

inégalement dans l’entreprise, en raison des changements dans les
besoins de gestion et des changements technologiques.
Ces divers changements évolutifs doivent être coordonnés dans un

environnement distribué constitué de matériel et de logiciel fournis
par une multitude de compagnies et de vendeurs. Les gestionnaires
de la compagnie veulent également que ces changements soient
implantés sans déranger les opérations. Le système doit de plus
avoir des mises à jour et des améliorations pouvant s’implanter
facilement au fur et à mesure de l’augmentation des besoins
informatiques de l’entreprise.
En considérant une vue globale des besoins d’une entreprise en
technologies de l’information, il est évident que de l’ingénierie des
systèmes soit nécessaire. En effet, l’ingénierie des systèmes permet
de définir l’architecture et les spécifications composant la
configuration des logiciels hétérogènes.
L’ingénierie des processus d’affaires est une approche permettant la

création d’un plan global de développement de l’architecture du
logiciel.
Trois différents types d’architecture doivent être analysée et générés

dans le cadre de la réalisation des objectifs et des buts de la gestion :
(1) architecture des données
L’architecture des données fournit le cadre nécessaire aux

besoins d’information requis par une entreprise ou une fonction
de la gestion.
Les composantes principales de l’architecture sont les entités

(data objects) utilisés par l’entreprise.
Une entité contient un ensemble d’attributs qui définissent des

aspects, qualités, caractéristiques ou descriptions des données
analysées.
Par exemple, un analyste de système pourra définir l’entité

client. Afin de mieux définir l’entité client, les attributs suivants
sont définis :
o numéro de client
o nom
o prénom
o adresse
o numéro de téléphone
Une fois l’ensemble des entités identifié, les relations entre les
entités sont définies. Une relation indique comment les entités
interagissent ensemble. Comme exemple, considérons les
entités : client et produit A. Ces deux entités peuvent être
reliées par la relation achète qui définit qu’un client achète le
produit A ou que le produit A est acheté par le client.
Les entités sont l’objet de fonctions de la gestion. Elles sont

organisées en bases de données et sont transformées afin de
fournir de l’information répondant aux besoins de la gestion.
Client Produit A
numéro de client 1,n 0,n Numéro

nom Achète Description
prénom Couleur
adresse
numéro de téléphone
(2) architecture des applications
L’architecture des applications englobe les éléments d’un

système qui transforme les entités à l’intérieur de l’architecture
des données afin de répondre à des besoins de gestion.
Dans le contexte de l’ingénierie du logiciel, nous considérons

l’architecture des applications comme étant un système de
programmes (logiciels) effectuant cette transformation.
Cependant, dans un plus large contexte, l’architecture des

applications peut inclure le rôle du personnel (qui sont des
utilisateurs et des modificateurs de l’information) ainsi que des
procédures administratives n’ayant pas été informatisées.
(3) infrastructure technologique
L’infrastructure technologique fournit les éléments de base à

l’architecture des données et des applications. Cette
infrastructure englobe le matériel et le logiciel qui sont utilisés
pour supporter les applications et les données. Ceci comprend
les ordinateurs, les systèmes d’exploitation, les réseaux, les
liens de télécommunication, les technologies d’entreposage des
données et l’architecture (client/serveur) générée pour
implanter ces technologies.
Afin de modéliser l’architecture de système, une hiérarchie d’activités

de l’ingénierie des processus d’affaires (Business Process
Engineering/BPE) est définie :
- Planification stratégique de l’information (vision globale)
Information Strategy Planning(ISP) – La planification

stratégique de l’information visualise l’entreprise comme une
entité et en isole les domaines (ingénierie, processus
manufacturiers, marketing, finance, ventes, etc.) qui sont
importants pour l’entreprise en général.
La planification stratégique de l’information définit les entités

visibles au niveau de l’entreprise, leurs relations et comment
elles interagissent avec les domaines de la gestion.
- Analyse des domaines de gestion(vision du domaine)
Business Area Analysis (BAA) – L’analyse du domaine de

gestion se concentre sur l’identification des entités et des
processus des domaines de gestion spécifiques identifiés
durant la phase de planification stratégique et vérifiant leurs
interactions. Cette étape se concentre uniquement par
l’énumération de spécifications des besoins d’un domaine de la
gestion.
Lorsque l’analyste des systèmes débute l’analyse des

domaines de gestion, il se concentre sur un domaine spécifique
de la gestion. Cette analyse visionne les domaines de la
gestion comme des entités et isole les fonctions et processus
de gestion permettant au domaine de gestion de rencontrer ses
buts et ses objectifs.
L’analyse des domaines de gestion, comme la planification des

stratégies de l’information définit les entités, les relations et les
flux d’informations. À ce niveau, ces caractéristiques sont
limitées par les domaines de gestion analysés.
Le but de l’analyse des domaines de gestion est d’isoler des

domaines dans lesquels les systèmes d’information pourraient
supporter les domaines de gestion.
- Conception des systèmes de gestion (vision des éléments)
Business System Design(BSD) – Lorsqu’un domaine d’un

système d’information a été isolé dans le but du
développement, l’ingénierie des processus de gestion passe à
une autre étape de l’ingénierie du logiciel qui est la conception
des systèmes de gestion.
Lors de cette étape, les spécifications élémentaires d’un

système d’information sont modélisées et sont traduites en
architecture des données et des applications. L’infrastructure
de la technologie est également spécifiée.
- Construction et intégration (vision détaillée)
La construction et l’intégration se concentrent sur l’implantation

des détails. L’architecture et l’infrastructure sont implantées par
la construction d’une base de données et de structures de
données internes. Les applications sont construites en utilisant
des composantes logicielles et en sélectionnant des éléments
appropriés de l’infrastructure de la technologie générée durant
la conception des systèmes de gestion.
Chacune des composantes du système doit être intégrée afin

de former une application ou un système d’information complet.
L’activité d’intégration place également le nouveau système

d’information dans le contexte du domaine de gestion en
effectuant le soutien logistique et le support à l’usager
nécessaire à la transition.
10.4 VISION GLOBALE DE L’INGÉNIERIE DES PRODUITS
Le but de l’étape d’ingénierie des produits est de traduire les besoins

du client en un produit fini.
Pour en arriver à ce but, l’ingénierie des produits – comme

l’ingénierie des processus de gestion – doit produire des
architectures de systèmes et des infrastructures.
L’architecture englobe quatre composantes distinctes :
(1) logiciel
(2) matériel
(3) données et bases de données
(4) personnel
Une infrastructure de support est établie et comprend la technologie

nécessaire à regrouper les composantes ensemble ainsi que
l’information (documents, CD-ROM, vidéo, etc.) nécessaire au
support de ces composantes.
Le modèle de l’ingénierie des produits comprend les étapes
suivantes :
- ingénierie des besoins (vision globale)
requirements engineering – les besoins globaux du produit sont

énoncés par le client. Ces besoins englobent l’information, le
contrôle, les fonctions, le comportement, la performance, les
contraintes de conception et d’interfaces, etc.
Une fois les besoins connus, l’ingénierie des besoins donne les
spécifications du logiciel, du matériel, des données et des
interactions du personnel constituant le nouveau logiciel.
- ingénierie des composantes (vision du domaine)
component engineering – l’ingénierie des composantes de

système est un ensemble d’activités concurrentes de
l’ingénierie telles que : logiciel, matériel, bases de données et
du personnel.
Chacune de ces activités de l’ingénierie doit établir et maintenir

une communication active avec les autres.
- analyse et modélisation (vision des éléments)
analysis & design modeling – appliquer la discipline de

l’ingénierie du logiciel au composantes du système.
La phase d’analyse transforme les spécifications en : modèles

des données, fonctions et comportements.
- construction et intégration (vision détaillée)
Comprend la génération du code, la vérification et le support.

10.5 INGÉNIERIE DES BESOINS
L’ingénierie des besoins fournit les mécanismes appropriés à la

compréhension de ce que le client veut, l’analyse des besoins,
l’étude de la faisabilité, la négociation d’une solution raisonnable,
l’élimination des spécifications ambiguës, la validation des
spécifications et la gestion des besoins au fur et à mesure qu’ils sont
transformée en un système opérationnel.
L’ingénierie des besoins peur être décrite en six étapes différentes :
(1) ÉNUMÉRATION DES BESOINS
(2) ANALYSE ET NÉGOCIATION DES BESOINS
(3) SPÉCIFICATION DES BESOINS
(4) MODÉLISATION DES SYSTÈMES
(5) VALIDATION DES BESOINS
(6) GESTION DES BESOINS

10.5.1 ÉNUMÉRATION DES BESOINS
Bien qu’il semble très simple de poser au client, aux usagers et les
autres intervenant des questions telles que :
- Quels sont les objectifs visés par le produit?
- Quels sont les objectifs du système?
- Quelles tâches doivent être accomplies?
- Comment le système ou le produit va satisfaire les objectifs de

la gestion?
- Comment le système sera utilisé sur une base journalière?
Les réponses à ces questions peuvent être dans la pratique plus

vague qu’attendu. Voici quelques problèmes faisant en sorte que
l’énumération des besoins est parfois difficile :
- problèmes de limites : les limites du système sont mal définies

ou le client/l’usager énonce trop de détails techniques qui
portent à la confusion
- problèmes de compréhension :
o Les clients/usagers ne sont pas complètement sûr de

leurs besoins
o Les clients/usager sont une compréhension limitée des

capacités et du domaine de leur environnement
informatique
o Les clients/usagers n’ont pas une bonne compréhension

du problème
o Les clients/usagers ont des problèmes à énoncer leurs

besoins aux concepteurs de système
o Les clients/usagers ne sont pas en mesure de donner

l’information essentielle
o Les clients/usagers spécifient des besoins qui sont en

conflit avec ceux d’autres clients/usagers
o Les clients/usagers spécifient des besoins ambigus
- problèmes de volatilité : Les besoins/spécifications changent

avec le temps
Afin de résoudre ces problèmes, les analystes de système doivent
considérer l’énumération des besoins d’une manière organisée
suivant les étapes suivantes :
- Évaluer la faisabilité du système proposé
- Identifier les personnes pouvant aider à définir les

spécifications et comprendre leur culture organisationnelle
- Définir l’environnement technique (type d’ordinateurs, système

d’exploitation, réseaux, télécommunications) dans lequel le
système ou le produit sera implanté
- Identifier les contraintes du domaine (caractéristiques de

l’environnement spécifique au domaine d’application) pouvant
limiter la fonctionnalité ou les performances du système à
implanter ou du produit à construire
- Définir une ou plusieurs méthodes d’énumération des besoins

(entrevues, rencontres de groupe, questionnaires, sondages,
etc.)
- Solliciter la participation de beaucoup d’intervenants afin que

les besoins soient définis sous différents points de vue
- Identifier les besoins imprécis comme candidats à une

approche par prototypage
- Créer des scénarios d’utilisation afin d’aider les clients/usagers

à mieux identifier leurs besoins principaux
La grosseur du rapport de l’étude des besoins produit à partir de
l’activité d’énumération des besoins va varier en fonction de la
grosseur du système à être réalisé. Dans la plupart des cas, ce
rapport va comprendre :
- l’énumération des besoins et une étude de faisabilité
- les limites du domaine d’application du système ou du produit
- une liste des clients, usagers et des responsables du

développement qui ont participé à l’énumération des besoins
- une description de l’environnement technique du système
- une liste des besoins (de préférence définis en fonctions) et les

contraintes de leur domaine d’application
- un ensemble de scénarios d’utilisation pouvant donner un

aperçu de l’utilisation du système ou du produit sous différentes
conditions d’utilisation
- les prototypes développés afin de mieux définir les besoins

10.5.2 ANALYSE ET NÉGOCIATION DES BESOINS
Le rapport spécifiant l’énumération des besoins forme la base de

l’analyse des besoins. L’analyse catégorise les besoins en sous-
ensembles, étudie chaque besoin en relation avec les autres;
détermine leur consistance et leur validité pour finalement les classer
selon les exigences des clients/usagers.
L’analyse des besoins doit répondre aux questions suivantes :
- Est-ce que chaque besoin est pertinent à la réalisation du

système/produit?
- Est-ce que tous les besoins ont été définis au bon niveau
d’abstraction?
- Est-ce que le besoin est valide?
- Qui a énoncé le besoin? (client, gestionnaire, analyste de

système)
- Est-ce que certains besoins entrent en conflit avec d’autres?
- Est-ce que le besoin est réalisable dans l’environnement

technique qui va supporter le système/produit?
- Pouvons nous vérifier/tester le besoin/spécification lorsqu’elle

sera implantée?
Les clients ont toujours tendance à spécifier plus de besoins que ce

qui pourra être implanté dans le nouveau système ou dans les
modifications d’un produit/système déjà en place.
Certains clients ou analystes peuvent énoncer des besoins spéciaux

pour leur service/département pouvant entrer en conflit avec
certaines spécifications du système.
Les analystes de système devront concilier ces demandes à travers

un processus de négociation.
10.5.3 SPÉCIFICATION DES BESOINS
Dans le contexte du logiciel et des systèmes informatisés, la

définition des spécifications prend un sens large. Une spécification
peut être :
- un document écrit
- un modèle graphique
- un modèle mathématique formel
- un ensemble de scénarios d’utilisation
- un prototype
- toute combinaison de ces éléments
Certains analystes suggèrent de développer un gabarit standard pour

la définition et l’énumération de spécifications. Il est cependant
nécessaire de demeurer flexible dans la définition de spécifications.
Les spécifications du système sont le rapport final produit par les

analystes de systèmes et des besoins. Il sert de fondement à
l’ingénierie du matériel, du logiciel, des bases de données et du
personnel. Il comprend :
- les entrées et les sorties du système
- les fonctions et les performances du système informatique
- les contraintes du développement
- les spécifications des éléments du système

10.5.4 MODÉLISATION DES SYSTÈMES
Établissement des plans du système :
- détermination de la circulation des flux de données
- modélisation des entités (composantes) du système et de leurs

relations
- détermination de l’interface usager
10.5.5 VALIDATION DES BESOINS
La qualité du rapport résultant de l’analyse des besoins

(spécifications des systèmes) est évaluée durant l’étape de
validation.
Le processus de validation des besoins examine les spécifications de

système afin de s’assurer que tous les besoins ont été clairement
définis, que les omissions, inconsistances et les erreurs ont été
détectées et corrigées. Ce processus vérifie également que les
spécifications rencontrent les normes établies au niveau des
processus, du projet et du produit. Il débute généralement par une
révision technique formelle.
La validation des besoins peut être effectuée de différentes façons en
autant qu’elle effectue la détection d’erreurs. Il est utile d’utiliser une
liste de vérifications comprenant les questions suivantes :
- Est-ce que les besoins sont énoncés correctement?
- Est-ce la source d’un besoin est identifiée? (individu, document,

règlement)
- Est-ce que le besoin est limité quantitativement
- Quels sont les autres besoins reliés à ce besoin?
- Est-ce que ce besoin entre en conflit avec des contraintes du

domaine?
- Est-ce que ce besoin/cette spécification est vérifiable?
- Est-ce que ce besoin se retrouve dans un modèle déjà crée?
- Est-ce que ce besoin rencontre les objectifs généraux du

système?
- Est-ce que ces spécifications vont fournir des données

pertinentes aux autres phases de l’analyse?
- Est-ce que les besoins ont été enregistrés/catalogués dans la

documentation de l’analyse?
- Est-ce que les besoins associés avec la performance, le

comportement et les caractéristiques opérationnelles du
système ont été clairement définies?
10.5.6 GESTION DES BESOINS
La gestion des besoins/spécifications est un ensemble d’activités qui

aide l’équipe du projet à identifier et contrôler les besoins ainsi que
leurs changements tout au long du projet.
Une fois les besoins identifiés, des tables de suivi sont développées.
Chaque table de suivi établit une relation entre les besoins et un ou
plusieurs aspects du système ou de son environnement. Les tables
de suivi peuvent être de type :
- Table de suivi des options : indique la relation entre les besoins

et les options observables du système/produit
- Table de suivi de la source : identifie la source de chaque

besoin
- Table de suivi des spécifications : identifie les relations entre

les spécifications
- Table suivi des sous-systèmes : catégorise les besoins par les

fonctions qu’ils contrôlent
- Table de suivi des interfaces : identifie comment des besoins

sont en relations avec les interfaces internes et externes.
10.6 MODÉLISATION DES SYSTÈMES
Tous les systèmes informatiques peuvent être modélisés comme

étant un élément de transformation de l’information à l’aide d’un
gabarit (entrées – traitement- sorties).
En utilisant une représentation des entrées, des traitements des

sorties, des interfaces et des éléments de vérification, un concepteur
de systèmes peut créer un modèle servant de base aux prochaines
étapes de l’analyse.
Un gabarit de modélisation des systèmes est utilisé. Il comprend cinq
régions de traitement :
(1) interface usager
(2) entrées
(3) fonctions et contrôle du système
(4) sorties
(5) entretien et vérifications

DIAGRAMME DE CONTEXTE DU SYSTÈME
SYSTEM CONTEXT DIAGRAM(SCD) – Le diagramme de contexte

du système est au plus haut niveau de la hiérarchie de l’analyse. Il
définit les limites de l’information entre le système implanté et son
environnement d’opération. Il identifie :
- toutes les sources externes d’information utilisées par le

système
- tous les récepteurs/consommateurs de l’information produite

par le système
- toutes les entités communiquant par les interfaces
- toutes les entités effectuant de l’entretien et des vérifications
Afin d’illustrer l’utilisation d’un diagramme de contexte de système,

considérons de système du tri de matériel sur un convoyeur. Voici
les spécifications de ce système, tel que présenté au concepteur de
système :
Le système du tri de matériel sur un convoyeur doit être

développé de telle façon que les boites se déplaçant sur le
convoyeur doivent être identifiées et triées dans l’un des six
contenants à la sortie du convoyeur. Les boites vont traverser
une station de tri où elles vont être identifiées. A partir d’un
numéro d’identification imprimé sur le côté de la boite (code à
barres), les boites seront aiguillées dans le contenant
approprié. Les boites sont également espacées et se déplacent
lentement.
Diagramme de contexte de système (tri de matériel sur un
convoyeur)
Entité externe:
Système/Processus
Producteur ou
Flux d’information
consommateur
de l’information
produits par le
système
SYSTEM FLOW DIAGRAM (SFD)
L’éclatement des processus/systèmes du diagramme de contexte de

système sont définis dans un diagramme de flux de système (System
Flow Diagram/SFD)
Diagramme de flux de système (Système de tri du convoyeur)
Le diagramme de flux de système peut devenir le niveau supérieur

d’une hiérarchie de diagrammes de flux de systèmes. En effet
chaque processus du diagramme de flux de système initial peut être
éclaté en une série diagramme de flux de système de niveau
inférieur.
Éclatement de diagrammes de flux de systèmes
COURS 04

Concepts et principes d’analyse des systèmes
L’ingénierie des besoins du logiciel est un processus de découverte,

raffinement, modélisation et spécification. Le rôle et les besoins du
système attribué au logiciel – initialement établis par l’analyste /
l’ingénieur des systèmes – sont raffinés en détails.
Des modèles des données requises, des flux et du contrôle de

l’information et des comportements opérationnels sont crées. Des
solutions alternatives sont analysées et un modèle complet d’analyse
est généré.
L’ingénieur de systèmes et le client ont un rôle actif à jouer dans

l’ingénierie de l’analyse des besoins – un ensemble d’activités
communément appelé analyse.
Dans ce processus, le client tente de reformuler des descriptions des

données, des fonctions et des comportements parfois imprécis en
détails clairs.
L’analyste joue le rôle d’interrogateur, de consultant, de solutionneur

de problèmes et de négociateur.
L’analyse des besoins et des spécifications peut sembler facile, mais

les apparences sont trompeuses. Le contenu de la communication
client/analyste étant assez chargé, une certaine ambiguïté peut naître
de problèmes d’interprétations des besoins.
11.1 ANALYSE DES BESOINS
L’analyse des besoins est une fonction de l’ingénierie du logiciel

faisant le lien entre l’ingénierie des besoins des systèmes à un
niveau donné et la conception du logiciel.
Les activités de l’ingénierie des besoins produisent :
- les spécifications des caractéristiques opérationnelles du

logiciel (fonctions, données et comportements)
- définissent les interfaces du logiciel avec d’autres éléments
du système
- établissent les contraintes que le logiciel doit rencontrer
L’analyse des besoins permet à l’ingénieur du logiciel (également
appelé analyste) de raffiner le logiciel et de construire les modèles
des données, les modèles fonctionnels et les domaines de traitement
du logiciel.
L’analyse des besoins fournit au concepteur du logiciel une

représentation de l’information, des fonctions et des comportements
pouvant être modélisée en données, architecture, interfaces et plans
de composantes.
La spécification des besoins permet à l’analyste et au client de

déterminer des moyens d’évaluer la qualité du logiciel, une fois sa
conception terminée.
L’analyse des besoins du logiciel est divisée en cinq domaines :
(1) détermination du problème : étude des spécifications du

système, plan de projet du logiciel.
(2) évaluation et synthèse : l’analyste doit définir touts les

entités externes, fonctions, interfaces et évaluer les flux
d’information.
(3) modélisation : l’analyste crée un modèle du système afin de

mieux visualiser les flux de données, le traitement
fonctionnel, le comportement opérationnel et les dépôts
d’information. Le modèle sert de fondation à la conception
du logiciel.
(4) spécification : Le modèle du système sert de base à la

définition des spécifications
(5) révision : La vérification des fonctionnalités du logiciel est

basée sur les spécifications.
11.2 ÉNUMÉRATION DES BESOINS DU LOGICIEL
Avant que les spécifications puissent être analysées, modélisées ou

formulées, les besoins doivent être énoncés à l’aide d’un processus
de collection/d’énumération.
11.2.1 DÉBUT DU PROCESSUS
Une des techniques utilisée le plus souvent permettant à l’analyste

de connaître et de définir les besoins du client est par l’entremise
d’une rencontre, d’une entrevue ou d’une réunion.
La première rencontre entre l’analyste de systèmes et le client peut

être assez difficile pour les deux parties car aucune d’elles ne veut
faire des erreurs d’interprétations tout en voulant que cette première
rencontre soit un succès.
Le dialogue peut être débuté par des questions indépendantes du

contexte. Ces questions servant à :
- définir une compréhension élémentaire du problème
- le personnel de l’organisation voulant la solution
- la nature de la solution désirée
- le degré de réussite de la première rencontre

La première série de questions indépendantes du contexte focalisera
sur le client, les objectifs généraux et les bénéfices :
- Quel service ou quel gestionnaire a demandé cette fonction /

modification?
- Qui va utiliser cette fonction / modification?
- Quels seront les bénéfices d’une implantation réussie de

cette fonction / modification?
- Connaissez-vous d’autres services/personnes ayant besoin

de cette solution?
Ces questions vont aider à identifier tout le personnel de

l’organisation visés par la construction/ la modification du logiciel.
Ces questions identifient également les bénéfices mesurables d’une
implantation réussie avec succès.
La prochaine série de questions permet à l’analyste d’avoir une

meilleure compréhension du problème. Avec ces questions, le client
peut énoncer ses visions d’une solution :
- Comment pourriez-vous définir une sortie valide générée par

une application réalisée avec succès?
- Quel(s) problèmes cette implantation va régler?
- Pouvez-vous me montrer(ou me décrire) l’environnement

dans lequel cette solution sera implantée?
- Quelles contraintes peuvent affecter le développement de

l’application?
La série finale de questions se concentre sur l’efficacité de la réunion.
Ces questions sont considérées comme étant des méta-questions :
- Êtes-vous la bonne personne pouvant répondre à ces

questions?
- Est-ce que vos réponses sont officielles?
- Est-ce que mes questions sont pertinentes en fonction du

problème à solutionner?
- Est-ce que je pose trop de questions?
- Est-ce que d’autres membres de votre organisation

pourraient me donner de l’information additionnelle?
- Pensez-vous que je vous ai posé toutes les questions

pertinentes en rapport avec votre problème?
11.2.2 TECHNIQUES DE SIMPLIFICATION D’APPLICATION

DES SPÉCIFICATIONS
Afin d’éliminer l’isolement respectif des clients et des équipes

d’ingénierie du logiciel qui nuit à l’établissement de relations de travail
productives, une méthode orientée sur la dynamique des équipes a
été développée afin d’identifier les besoins du client durant les étapes
d’analyse et de spécification.
Appelée « technique de simplification d’application des
spécifications » {Facilitated application specification techniques
(FAST)}, cette approche encourage la formation d’équipes
composées de clients et d’analystes travaillant ensemble dans le
but :
- d’identifier les besoins/le problème
- proposer des éléments de solution
- négocier différentes approches de solution
- spécifier un ensemble préliminaire de spécifications de

solution
La méthode de « technique de simplification d’application des

spécifications » {Facilitated application specification techniques
(FAST)} suit les lignes directrices suivantes :
- Une réunion est faite dans un endroit neutre. Les clients et

les concepteurs de logiciel y participent
- Des règles de participation et de préparation sont établies
- Un ordre du jour est soumis. Il doit être assez formel pour

couvrir tous les sujets importants, mais assez informel pour
encourager les membres à énoncer leurs idées librement
- Un modérateur / directeur (client, analyste ou consultant

externe) contrôle la réunion
- Des aides à la visualisation / conception (feuilles de papier,

tableaux, bloc-notes, salle de vidéo-conférence) sont utilisés
- Le but est :
o Identifier les besoins/problèmes
o Formuler des éléments de solution
o Négocier différentes approche de résolution
o Spécifier un ensemble préliminaire d’éléments de solution

dans une atmosphère propice à l’accomplissement de la
tâche.
Afin d’avoir une meilleure compréhension du déroulement d’une
réunion FAST, nous allons présenter un bref scénario permettant de
décrire la séquence des événements :
- permettant d’obtenir une réunion FAST
o rencontres entre le client et le développeur de système

définissant :
 le domaine du problème
 aperçu de la solution
 formulation de la demande de service
o date, heure et endroit de la réunion
o le nom du directeur/modérateur de la réunion
o envoi des avis de convocation à la réunion
o distribution de la demande de service aux membres de la

réunion
o chaque membre doit faire :
 liste des entités (objets) du système(internes et

externes)
 liste des services (processus et fonctions) qui

manipulent ou interagissent avec les entités
 liste des contraintes (coûts, grosseur, règles

administratives)
 établissement de critères de performance (vitesse,

précision)
- se produisant durant une réunion FAST
o justification du nouveau produit/système (la justification

doit être acceptée à l’unanimité)
o chaque participant soumet ses listes au comité pour

discussion
o une liste combinée est alors produite
o discussion contrôlée par le modérateur/directeur
o modification de la liste suite aux résultats de la discussion
o une liste finale (liste de consensus) est alors produite

pour chaque sujet (entités, fonctionnalités, contraintes et
performances)
o les membres de la réunion sont divisés en groupes afin

de développer les mini-spécifications des items des listes.
Chaque mini-spécification est une élaboration d’un mot
ou d’une phrase d’une liste
o présentation des mini-spécifications à tous les membres

de la réunion pour discussion
o chaque membre de la réunion établit une liste de critères

de validation pour le produit/système et la soumet aux
autres membres de la réunion
o une liste de validation finale est crée

- se produisant après une réunion FAST
o un ou plusieurs participants ont la tâche d’écrire les

spécifications du système en utilisant toutes les données
produites par la réunion FAST. Ces spécifications
peuvent être également produites par un consultant
externe.
La méthode FAST ne solutionne pas tous les problèmes rencontrés

dans l’énumération des besoins. L’approche par l’entremise d’une
équipe combinée de clients et d’analyste fait en sorte que la
discussion et le raffinement des besoins font évoluer de beaucoup le
développement des spécifications.
Prenons comme exemple que l’équipe de « technique de

simplification d’application des spécifications » {Facilitated application
specification techniques (FAST)} travaillant pour une entreprise de
produits de consommation doit étudier la description suivante d’un
produit :
Notre département de recherche indique que le marché pour les

systèmes de sécurité résidentiels augmente de 40% par année.
Nous voudrions prendre une part de ce marché en concevant un
système de sécurité à domicile à base de microprocesseur
pouvant protéger ou détecter un ensemble de situations
indésirables telles que :
o intrusion illégale,
o feu,
o inondations; et
o autres situations à être implantées ultérieurement.
Le produit, pour l’instant appelé Maison-Sécuritaire, va utiliser

des capteurs appropriés pour détecter chaque situation.
Le système Maison-Sécuritaire va pouvoir être programmé par

les propriétaires/habitants de la résidence et le système va
pouvoir envoyer un signal téléphonique au département de la
surveillance lorsqu’une situation anormale est détectée.
L’équipe FAST est composée de représentants des départements du
marketing, de la fabrication, de l’ingénierie du matériel et du logiciel.
Un modérateur externe sert à diriger la réunion.
Chaque membre de l’équipe FAST étudie l’énoncé du problème. Les

composantes nécessaires au système Maison-Sécuritaire pourraient
inclure :
- détecteurs de fumée,
- détecteurs de fenêtre ouverte/cassée,
- détecteurs de porte ouverte/fermée/barrée,
- détecteurs de mouvements,
- sirènes d’alarme,
- système de traitement des événements (traite le cas où un

senseur est déclenché),
- un panneau de contrôle (comprenant des boutons),
- un écran,
- une liste de numéros de téléphone,
- un système permettant de signaler des numéros de

téléphone; et
- d’autres éléments à déterminer.

La liste des fonctions (basé sur les entités) du système Maison-
Sécuritaire pourraient comprendre :
- programmation de l’alarme
- interrogation / surveillance des capteurs
- signaler des numéros de téléphone
- programmation du panneau de contrôle
- lecture de l’écran
Chaque membre de l’équipe FAST va développer une liste de

contraintes :
- coût du système inférieur à $80.00
- le système doit être convivial (user-friendly)
- doit s’interfacer à une ligne téléphonique conventionnelle
- critères de performance :
o un événement devra être reconnu dans la seconde
o une liste de priorité des événements devra être établie

Les mini-spécifications du panneau de contrôle système Maison-
Sécuritaire pourraient comprendre:
- le panneau de contrôle sera fixé sur un mur
- dimensions de 25cm X 15cm
- possède un clavier de 12 touches et des touches spéciales
- écran à chiffres numériques(LCD)
- toutes les interactions se font par les touches
- sert à activer et désactiver le système
- le logiciel peut fournir de l’information à l’usager (directives,

informations. aide)
- le système relie tous les capteurs
11.2.3 QUALITY FUNCTION DEPLOYMENT(QFD) /

DÉVELOPPEMENT DE FONCTIONS DE QUALITÉ
Le développement de fonctions de qualité est une technique de

gestion de la qualité traduisant les besoins du client en spécifications
techniques du logiciel. Cette technique a été originalement
développée au Japon et utilisée initialement dans les années 1970
aux chantiers navals de Kobe appartenant aux industries Mitsubishi.
Le développement de fonctions de qualité se concentre sur la

maximisation de la satisfaction du client découlant du processus de
l’ingénierie du logiciel.
Afin d’accomplir ceci, le développement de fonctions de qualité met

l’accent sur la compréhension de ce que est important pour le client
et répartit ensuite ces valeurs tout au long de l’ingénierie du logiciel.
Le développement de fonctions de qualité identifie trois types de
besoins :
(1) besoins normaux : les objectifs et buts définis pour un produit

ou un système durant les entrevues avec le client. Si ces
exigences sont présentes, le client est satisfait. Des exemples
de besoins normaux sont le type d’interface graphique
demandée, des fonctions spécifiques du système et des
niveaux de performance définis
(2) besoins attendus : ces besoins sont implicites au produit ou au

système et sont si fondamentaux que le client n’a pas besoin
de les mentionner. Leur omission va causer l’insatisfaction du
client. Exemples : facilité d’utilisation de l’interface personne-
machine, facilité d’installation, exactitude et fiabilité du logiciel.
(3) besoins surprenants/excitants/supplémentaires : ces

caractéristiques dépassent les exigences du client et sont très
accrocheuses lorsque présentes. Exemple : un logiciel de
traitement de texte est demandé par le client. Le produit livré
comprend une interface graphique couleur permettant d’inclure
des photos et des graphiques dans le texte.
Le développement de fonctions de qualité s’étend sur tout le
processus de l’ingénierie du logiciel. Bien des concepts du
développement des fonctions de qualité sont applicables à l’activité
d’énumération des besoins :
- déploiement des fonctions : détermination de l’importance de

chaque fonction nécessaire au développement du système
- déploiement de l’information (fonctionnalités) : identifie les

entités et les événements que le système doit consommer et
produire
- déploiement des tâches : examine le comportement du

système ou du produit dans le contexte de son
environnement
- analyse de la valeur : effectuée afin de déterminer la priorité

relative des besoins déterminée durant chacun des trois
déploiements
Le développement de fonctions de qualité se base sur des entrevues

avec le client, des observations, des enquêtes et d’examens de
données historiques (Ex : rapports de défectuosités) comme données
de base à l’activité d’énumération des besoins.
Ces données sont regroupées sous la forme d’un tableau des

besoins – appelé la table de la voix du client – qui est révisé avec le
client. Un ensemble de diagrammes, matrices et de méthode
d’évaluation sont alors utilisés pour identifier les besoins attendus et
pour essayer de trouver quelques besoins surprenants.
11.2.4 USE-CASES / SCÉNARIOS D’UTILISATION
Tout au long du processus de l’identification des besoins découlant

de réunions informelles, FAST ou de développement de fonctions de
qualité(QFD), l’analyste de systèmes peut créer un ensemble de
scénarios d’utilisation démontrant l’utilisation d’une fonction du
système analysé. Les scénarios d’utilisation donnent une description
de l’utilisation future d’une partie du système.
Pour créer un scénario d’utilisation, l’analyste doit :
- déterminer les différents types d’individus ou d’appareils

interagissant avec le système ou le produit. Ces acteurs
identifient le rôle que ces individus ou appareils jouent lors
du fonctionnement du système. Défini plus formellement, un
acteur est toute entité externe communiquant avec le
système.
- Une fois les acteurs identifiés, le scénario peut être

développé. Le scénario décrit la manière dont l’acteur
interagit avec le système. Un scénario doit répondre à un
certain nombre de questions :
o Quelles tâches ou fonctions sont effectuées par l’acteur?
o Quelle information du système l’acteur va utiliser, produire

ou changer?
o Est-ce que l’acteur devra informer le système des

changements dans l’environnement externe?
o Quelle information l’acteur veut obtenir du système?
o Est-ce que l’acteur veut être informé des changements

imprévus?
À l’aide de l’exemple du système Maison-Sécuritaire, nous pouvons
identifier trois acteurs :
(1) le propriétaire de la maison (l’usager du système)
(2) les capteurs (appareils reliés au système)
(3) le bureau à lequel est relié le système Maison-Sécuritaire
Dans cet exemple, nous allons seulement considérer le propriétaire

de la maison comme acteur. Le propriétaire de la maison agit avec le
système Maison-Sécuritaire de différentes façons :
- L’entrée d’un mot de passe pour lui permettre d’accéder au

système
- Interroge le système sur le statut d’une zone surveillée par le

système
- Interroge le système sur le statut/l’état d’un capteur
- Actionne le bouton de panique en cas d’urgence
- Active/désactive le système de sécurité

Un scénario de l’activité du système est alors défini :
(1) Le propriétaire observe le panneau de contrôle du système

d’alarme Maison-Sécuritaire afin de déterminer si le système
est prêt à être programmé. Si le système n’est pas prêt, le
propriétaire doit fermer toutes les portes et fenêtres pour
faire en sorte que le système entre dans l’état « prêt ». [Le
système est dans l’état « non prêt » lorsqu’un capteur est
activé, Exemple : une porte ou une fenêtre est ouverte]
(2) Le propriétaire entre au clavier code de mot de passe à

quatre chiffres. Le mot de passe entré par le propriétaire est
comparé avec le mot de passe valide du système. Si le mot
de passe entré est invalide, le système va émettre un « bip »
et retourner à l’état de demande du mot de passe. Si le mot
de passe est correct, le système attend les commandes de
l’utilisateur.
(3) Le propriétaire entre les commandes « stay » ou « away »

afin d’activer le système. L’état « stay » (ici) active
seulement les capteurs extérieurs(les détecteurs de
mouvements intérieurs sont désactivés). L’état « away »
(parti) active tous les capteurs.
(4) Lorsque le système est activé, un voyant rouge peut être

observé
11.3 PRINCIPES DE L’ANALYSE
Toutes les méthodes d’analyse ont en commun un ensemble de

principes opérationnels :
(1) le domaine des données d’un problème doit être défini et

compris
(2) les fonctions exécutées par le logiciel doivent être définies
(3) le comportement du logiciel en réponse aux événements

externes doit être défini
(4) les modèles décrivant l’information, les fonctions et les

comportements doivent être séparés d’une manière
découvrant les détails dans une architecture hiérarchique ou
stratifiée
(5) le processus d’analyse évolue du traitement de l’information

essentielle à l’implantation des détails
Par l’application de ces principes, l’analyse étudie les problèmes

systématiquement. Le domaine des données est étudié afin que les
fonctions soient comprises plus complètement. Des modèles sont
utilisés pour que les caractéristiques des fonctions et des
comportements soient modélisés de façon concise. La décomposition
sous la forme de modules est appliquée afin de réduire la complexité.
Une vision de l’implantation du logiciel est nécessaire afin
d’accommoder les contraintes logiques imposées par les besoins de
traitement et les contraintes physiques imposées par les autres
éléments de système.
Les principes suivants orientent le processus de l’ingénierie des
besoins :
- comprendre problème avant de faire les modèles d’analyse
- développer des prototypes permettant à l’usager de

comprendre le fonctionnement de l’interface personne-
machine
- prendre en note l’origine et la raison de chaque besoin
- utiliser différentes modélisation des besoins
- classer les besoins en ordre de priorité
- travailler afin d’éliminer l’ambiguïté
11.3.1 LE DOMAINE DE L’INFORMATION
Toutes les applications du logiciel peuvent s’appeler « traitement des

données ». Ce terme nous aide à définir les besoins du logiciel. Le
logiciel est construit pour traiter et transformer les données. Le
logiciel accepte les données en entrée, effectue les traitements et
produit des données en sortie.
Le logiciel produit également des événements. Un événement

représente un aspect d’un système de contrôle ayant un état
booléen.
Les données (nombres, texte, images, sons, vidéo, etc.) et les

événements (contrôle des états) définissent le domaine d’information
d’un système.
Le premier principe opérationnel de l’analyse exige un examen du

domaine de l’information et la création d’un modèle de données.
Le domaine de l’information contient trois représentations différentes
des données traitées par un programme et du contrôle des états:
(1) modèle des données : description des composantes de

l’information et de leurs relations
(2) flux d’informations
(3) structure de l’information (structure des données)
11.3.2 MODÉLISATION
Les modèles fonctionnels sont crées afin d’obtenir une meilleure

compréhension du système à construire. Lorsque le système est un
objet physique (immeuble, avion, machine), nous pouvons construire
un modèle réduit de cet objet. Lorsque le système est un logiciel,
notre modèle doit avoir une représentation différente. Le modèle doit
être capable de représenter l’information que le logiciel transforme,
les fonctions permettant aux transformations de se produire et aux
comportements du système tout au long de la transformation de
l’information.
Le second et le troisième principe d’analyse exigent la construction
de modèles fonctionnels et comportementaux :
- modèles fonctionnels : le logiciel transforme l’information en

accomplissant trois fonctions génériques :
o entrées
o traitements
o sorties
- modèles comportementaux : la plupart des logiciels

fournissent une réponse à des événements du monde
extérieur. La base des modèles comportementaux repose
sur la dynamique stimulus/réponse. Un programme
d’ordinateur est dans un état donné qui est changé lorsqu’un
événement se produit. Ce modèle crée une représentation
des états du logiciel et des événements causant des
transitions.
Les modèles crées durant l’analyse des besoins ont de nombreuses

fonctions importantes :
- le modèle aide l’analyste dans la compréhension de

l’information, des fonctions et du comportement du système
pour faire en sorte que la tâche de l’analyse des besoins soit
plus facile et systématique
- le modèle soit l’objet principal de la révision et qu’il

détermine l’exactitude, la consistance et le degré de
réalisation des spécifications
- le modèle soit la fondation de la conception, fournissant au

concepteur une représentation essentielle du logiciel
pouvant déterminer le contexte de l’implantation
11.3.3 PARTITION
Certains problèmes sont trop complexes pour être compris en entier.

Pour cette raison, nous divisons ces problèmes en parties qui sont
facilement compréhensibles et nous effectuons des liens entre ces
parties afin que la totalité du système soit réalisée.
La partition subdivise un problème en ses parties constituantes.

Conceptuellement, nous établissons une représentation hiérarchique
des fonctions ou de l’information pour ensuite effectuer une partition
des éléments supérieurs par :
(1) La représentation des détails en ordre de croissance en se

déplaçant verticalement dans la hiérarchie
(2) La décomposition fonctionnelle du problème en se déplaçant

horizontalement dans la hiérarchie.
Afin d’illustrer le concept de la partition, considérons la description du
logiciel du système d’alarme « Maison-Sécuritaire » :
Le logiciel du système d’alarme « Maison-Sécuritaire » permet

au propriétaire de configurer le système de sécurité lorsque
celui-ci est installé, de surveiller tous les capteurs connectés au
système de sécurité, et d’interagir avec le propriétaire par
l’entremise d’un clavier et de touches de fonctions contenues
dans le panneau de contrôle du système d’alarme.
Durant l’installation, le panneau de contrôle est utilisé pour

programmer et configurer le système. Chaque capteur possède
un numéro et une description, un mot de passe principal est
programmé afin d’autoriser l’armement et le désarmement du
système. Lorsque les capteurs détectent des événements tels
qu’un feu ou une intrusion, le système d’alarme décide de
téléphoner à un bureau de contrôle pour signaler l’alarme.
Lorsqu’un capteur détecte un événement, le logiciel déclenche

une alarme audible reliée au système. Après un délai spécifié
par le propriétaire lors de la configuration du système, le logiciel
signale le numéro de téléphone du bureau de contrôle, fournit
l’adresse de la maison et signale l’événement qui a déclenché
l’alarme (feu, intrusion, etc.). Le numéro de téléphone sera
signalé à toutes les 20 secondes jusqu’à ce que la
communication téléphonique soit obtenue.
Toutes les interactions de l’usager avec le système d’alarme

« Maison-Sécuritaire » est géré par une sous-routine lisant les
entrées du clavier et les touches de fonctions, cette sous-
routine affiche des courts messages sur l ‘écran LCD.
L’interaction avec le clavier prend la forme suivante …
Les besoins du système d’alarme « Maison-Sécuritaire » peuvent
être analysés par la partition de l’information, des fonctions et des
domaines de comportement du produit. Pour illustrer le domaine
fonctionnel, le problème est divisé en représentant les fonctions
composant le système d’alarme par un déplacement horizontal dans
la hiérarchie fonctionnelle. Les fonctions principales sont énumérées
au premier niveau de la hiérarchie.
Les sous-routines subdivisant les fonctions principales du système

d’alarme peuvent être énumérées en détails verticalement dans la
hiérarchie.
11.3.4 VISIONS ESSENTIELLES ET D’IMPLANTATION
Une vision essentielle des besoins du logiciel définit les fonctions à

accomplir et l’information à être traitée sans considération de détails
d’implantation. En focalisant l’attention sur l’essence du problème lors
des premières étapes de l’ingénierie des besoins, nous reportons la
spécification des détails de l’implantation lors des dernières étapes
de la spécification des besoins et de la conception du logiciel.
Une vision d’implantation des besoins du logiciel représente la

construction des fonctions de traitement et des structures de données
dans l’environnement réel de l’implantation. Dans certains cas, une
représentation physique est développée dans les premières étapes
de la conception du logiciel. Cependant, la spécification des
contraintes d’implantation est incluse dans l’analyse de la plupart des
systèmes informatiques.
11.4 PROTOTYPAGE DU LOGICIEL
L’analyse devrait être effectuée sans tenir compte de la technique de

l’ingénierie du logiciel appliquée. Cependant, la forme que l’analyse
peut prendre peut varier. Dans certains cas, il est possible
d’appliquer certains principes d’analyse opérationnels et de dériver
un modèle de logiciel dans lequel une application peut être
développée.
Dans d’autres situations où la collecte des besoins est effectuée et

l’analyse effectuée, un modèle du logiciel, appelé prototype, peut être
implanté afin d’être évalué par le client et les concepteurs du logiciel.
Dans certains cas, la construction d’un prototype est nécessaire dès

le début de l’analyse car c’est l’unique moyen d’en arriver à trouver
les spécifications du logiciel à produire. Le modèle évolue ensuite
pour devenir le produit fini.
11.4.1 SÉLECTION DE L’APPROCHE DE PROTOTYPAGE
L’approche par prototypage peut être :
- Ouverte (prototype évolutif) : le prototype est utilisé pour la

première partie de l’activité d’analyse et va continuer son
évolution dans les phases de conception et d’implantation.
Le prototype est la première version du système final.
- Fermée (prototype jetable) : en utilisant cette approche, un

prototype sert uniquement à exprimer les besoins et les
spécifications. Il est ensuite jeté et le logiciel est crée selon
les méthodes de développement traditionnelles
11.4.2 MÉTHODES ET OUTILS DE PROTOTYPAGE
Afin qu’un prototype de logiciel soit efficace, celui-ci doit être

développé rapidement pour que le client visualise rapidement les
résultats et indique des changements. Pour construire rapidement
des prototypes, trois classes génériques de méthodes et d’outils sont
disponibles :
(1) outils de quatrième génération : bases de données(SQL) et

générateurs de code
(2) composantes réutilisables : librairies de fonctions, classes

(langages orientés objet)
(3) spécification formelles et environnements de prototypage :

environnements de programmation permettant de :
a. formuler des spécifications d’un système informatique à

partir d’un langage de formulation de spécifications
b. utiliser traducteurs de langages orientés sur les

spécifications en code exécutable
c. permettre au client d’utiliser les spécifications du code

exécutable du prototype pour raffiner ses spécifications
formelles
11.5 SPÉCIFICATIONS
L’exactitude des spécifications influence la qualité du logiciel/de la

solution.
11.5.1 PRINCIPES DES SPÉCIFICATIONS
(1) Séparation des fonctionnalités de l’implantation
(2) Développement d’un modèle du comportement désiré d’un

système englobant les données et les réponses aux divers
événements de l’environnement.
(3) Établir le contente d’opération du logiciel en spécifiant la

manière dont les autres composantes du système
interagissent avec ce logiciel
(4) Définir l’environnement dans lequel le système fonctionne en

précisant la réaction de l’environnement aux actions de ces
agents
(5) Création d’un modèle cognitif au lieu d’un modèle de

conception ou d’implantation. Le modèle cognitif décrit la
perception d’un système par des utilisateurs
(6) Prendre pour acquis que les spécifications doivent avoir un

certain seuil de tolérance et peuvent être incomplètes
(7) Créer le contenu et la structure des spécifications de façon à

ce que ces entités soient modifiables
11.5.2 MÉTHODES DE REPRÉSENTATION DES
SPÉCIFICATIONS
- Le format de la représentation et le contenu d’une

spécification doit être adapté à la nature du problème
- Les informations contenues dans les spécifications devraient

avoir une organisation hiérarchique et différents niveaux
d’abstractions
- Les diagrammes, modèles et plans de système doivent être

en nombre limité et bien définir le système/problème
- Les diagrammes, modèles et plans de système sont sujets à

des révisions
11.5.3 RAPPORT DE SPÉCIFICATION DES BESOINS DU

LOGICIEL
Le rapport de spécification des besoins du logiciel est produit au point

culminant de tâches d’analyse. Les fonctions et les performances du
logiciel comme étant une partie de l’ingénierie des systèmes sont
précisées par :
- une description complète de l’information
- une description détaillée des fonctionnalités
- une modélisation des comportements du système
- exigences de performance
- contraintes de conception
- critères de validation
Le rapport de spécification des besoins du logiciel a généralement le
format suivant :
(1) introduction
(2) description de l’information
(3) description fonctionnelle
(4) description des comportements
(5) critères de validation
(6) bibliographie
(7) appendices
11.6 VALIDATION DES SPÉCIFICATIONS
Une validation des spécifications des besoins du logiciel ou du

prototype est effectuée conjointement par le client et le concepteur du
logiciel.
Une fois la révision complète, le document contenant les

spécifications des besoins du logiciel est approuvé et signé par les
deux parties.
Le document des spécifications devient un contrat de développement

du logiciel.
Toute révision concernant les besoins ou les spécifications sera

considéré comme une extension des fonctionnalités du logiciel et
augmentera les coûts de production
COURS 05

Techniques d’analyse des systèmes
D’un point de vue technique, l’ingénierie du logiciel débute par une

série de tâches de modélisation conduisant à une spécification
complète des besoins et à des modèles (plans) compréhensibles des
logiciels à construire.
Le modèle d’analyse, qui est un ensemble de modèles, est la

première représentation technique d’un système.
Deux méthodes d’analyse sont actuellement en vigueur :
(1) analyse structurée : méthode d’analyse classique des

traitements séquentiels. Ensemble de méthodes qui évoluent
depuis plus de 30 années.
(2) analyse orientée objet : méthode consistant analyser un

problème et de le représenter sous forme d’objet, classes et
méthodes
Nous allons maintenant étudier l’analyse structurée.
L’analyse structurée est un processus de construction de modèles et

de plans de systèmes. Cette méthode englobe les opérations
suivantes :
- analyse/catégorisation des données/de l’information

- création de modèles fonctionnels
- création de modèles comportementaux
Ces méthodes représentent les fondements du système à construire.

12.1 HISTORIQUE
Comme la plupart des contributions à l’ingénierie du logiciel, la

discipline de l’analyse structurée des systèmes s’est développée au
fil du temps. Des recherches préliminaires en modélisation des
systèmes a débuté vers la fin des années 1960 et au début des
années 1970.
La première apparence de l’analyse structurée a découlé de la

conception structurée. Les chercheurs avaient en effet besoin de
notations graphiques pour représenter les données ainsi que les
processus transformant les données. Ces processus étant
représentés dans un diagramme (modèle).
Le terme « analyse structurée », originalement formulé par Douglas

Ross, a été popularisé par De Marco ayant publié un livre sur le sujet.
Dans son livre, De Marco a introduit et définit les symboles
graphiques essentiels et les modèles servant à effectuer l’analyse
structurée.
Dans les années qui ont suivi, des variations de l’approche de

l’analyse structurée ont été suggérées par Page-Jones, Gane et
Sarson ainsi que plusieurs autres chercheurs dans le domaine.
Dans chacun des cas, les méthode se concentraient sur des

applications des systèmes d’information et ne fournissaient pas une
notation adéquate pour modéliser les aspects du comportement et le
contrôle des systèmes en temps réel.
Vers le milieu des années 1980, des compléments aux méthodes de

l’analyse structurée sont introduits par Ward et Mellor et ensuite par
Hatley et Pirbhai. Ces extensions ont amené des méthodes d’analyse
plus robustes pouvant être appliquées efficacement aux problèmes
de l’ingénierie.
Des notations formelles ainsi que des traitements modernisés ont été
développés afin de favoriser les outils de conception de logiciels
assistés par ordinateur.
12.2 LES ÉLÉMENTS DU MODÈLE D’ANALYSE
Le modèle d’analyse doit réaliser trois objectifs principaux :
(1) la description des besoins du client
(2) l’établissement de données de base servant à créer des

plans de système
(3) définir un ensemble de spécifications pouvant être validées

une fois le logiciel réalisé
Le modèle d’analyse comprend les éléments suivants :
- dictionnaire des données : fichier ou répertoire contenant

tous les éléments d’information consommés ou produits par
le logiciel
- modèle entité-relation : décrit les relations entre les éléments

d’information. Ce modèle est utilisé afin d’effectuer la
modélisation conceptuelle des données. Les attributs de
chaque entité notés dans le modèle peuvent être décrits
selon un type déterminé (entier, réel, chaîne de caractères,
etc.)
- diagramme de flux de données :
o fournit la description des processus de transformation des

données tout au long de leur parcours dans le système
o fournir la description des processus et des sous-

processus transformant les flux d’information
- spécification des processus : une description de chaque

processus présent dans le DFD
- diagramme de transition : modélise les comportements du
système en fonction des influences des événements
externes. Le diagramme de transition représente les modes
variés de comportements (appelés états) du système et la
façon dont laquelle des transitions sont effectuées d’un état
à l’autre. Le diagramme de transition est à la base de la
modélisation des comportements.
- spécifications de contrôle : informations supplémentaires

décrivant les aspects de contrôle du logiciel.
12.3 MODÉLISATION DES DONNÉES
Le modèle entité-relation permet à l’analyste d’identifier les entités et

les relations d’un système en utilisant une notation graphique.
Dans le contexte de l’analyse structurée, le modèle entité-relation

définit toutes les données fournies, entreposées, transformées et
produites à l’intérieur d’une application.
Le modèle entité-relation se concentre seulement sur les données,

établissant un réseau des données existant pour un système donné.
Ce modèle est très utile dans le cas des applications ou les données
et les relations entre les données sont complexes.
Contrairement au diagramme de flux de données, la modélisation des

données considère les données indépendamment des processus les
transformant.
12.3.1 ENTITÉS, ATTRIBUTS ET RELATIONS
Le modèle conceptuel de données (entité-relation) consiste en trois

parties inter-reliées :
(1) les entités,
(2) les attributs décrivant les entités; et
(3) les relations reliant les entités les unes aux autres
ENTITÉS
Une entité est une représentation de n’importe quel élément

d’information composé devant être traité par le logiciel. Par élément
d’information composée, nous définissons une entité ayant un
différent nombre de propriétés ou d’attributs.
Une entité peut être :
- une entité externe : élément d’information produisant ou

consommant de l’information (ex. : client)
- un objet (ex. : un rapport, un écran)
- une occurrence (ex. : un appel téléphonique)
- un événement (ex. : signal d’alarme)
- un rôle (ex. : un vendeur)
- un département (ex. : ventes, comptabilité)
- un lieu (ex. : un entrepôt)
- une structure (ex. : un fichier)
Une entité ne fait seulement que regrouper des propriétés. Aucune

référence n’est faite sur les opérations utilisant ces données.
ATTRIBUTS
Les attributs définissent les propriétés des entités et peuvent avoir

l’une des trois caractéristiques suivantes :
(1) nommer une instance d’une entité
(2) décrire une instance d’une entité
(3) lier l’instance à une instance d’une autre table

L’un des attributs est la clef de l’entité. La valeur de la clef est
généralement unique et sert à distinguer une entité d’une autre entité.
Elle doit être obligatoirement mentionnée dans la définition et la
symbolisation de l’entité.
Exemple :
- numéro de série
- numéro d’assurance sociale
- numéro d’assurance maladie
- numéro de compte
RELATIONS
Les entités sont inter-reliées entre-elles de différentes façons.
Considérons deux entités : livre et magasin de livre. Un lien est établi

entre livre et magasin de livres parce que ces deux entités sont
reliées.
Nous pouvons définir différentes relations entre ces deux entités tout
dépendant du contexte du problème.
Exemples :
- Un magasin de livre commande des livres
- Un magasin de livre place des livres sur des étalages

(expose)
- Un magasin de livre entrepose des livres
- Un magasin de livres vend des livres
- Un magasin de livre retourne des livres aux fournisseurs
Il est important de noter que ces relations sont bidirectionnelles

12.3.2 CARDINALITÉS ET MODALITÉS
Les éléments de la modélisation conceptuelle de données fournissent

la base pour la compréhension du domaine d’information d’un
problème. Cependant, de l’information additionnelle relative à ces
éléments doit être ajoutée.
Le modèle définit un ensemble d’objets et les liens objet/relation les

reliant. La relation d’un objet X avec un objet Y ne fournit pas assez
d’information aux fins de l’ingénierie du logiciel. Le modèle doit définir
combien d’occurrences de l’objet X sont en relation avec des
occurrences de l’objet Y. La détermination du nombre d’occurrences
d’une entité en relation avec le nombre d’occurrences d’une autre
entité est définie dans le concept de cardinalités.
CARDINALITÉS
Les cardinalités sont la spécification du nombre d’occurrences d’une

entité pouvant êtres reliées au nombre d’occurrences d’une autre
entité. Les cardinalités sont normalement exprimées simplement
comme : ‘un’ ou ‘plusieurs’.
Exemples :
- un mari peut avoir seulement une femme
- un parent peut avoir plusieurs enfants
En prenant en considération toutes les combinaisons possibles, les

cardinalités entre les objets peuvent être définies comme étant :
- Un-à-un (1,1) – Une occurrence de l’objet ‘A’ est en relation

avec une et seulement une occurrence de l’objet ‘B’ et une
occurrence de l’objet ‘B’ est en relation uniquement avec une
occurrence de l’objet ‘A’
Mari 1,1 Épouse

1,1 Avoir
Exemple : Un mari ne peut seulement avoir qu’une épouse

- Un-à-plusieurs (1,N) – Une occurrence de l’objet ‘A’ est en
relation avec une ou plusieurs occurrences de l’objet ‘B’,
mais une occurrence de l’objet ‘B’ peut uniquement être en
relation avec une occurrence de l’objet ‘A’.
Mère 1,1 Enfant

1,n Avoir
Exemple : Une mère peut avoir plusieurs enfants, mais un

enfant n’a qu’une seule mère
- Plusieurs-à-plusieurs (M,N) – Une occurrence de l’objet ‘A’

est en relation avec une ou plusieurs occurrences de l’objet
‘B’, et une occurrence de l’objet ‘B’ peut être en relation avec
une ou plusieurs occurrence de l’objet ‘A’.
Oncle 1,n Neveu

1,n Avoir
Exemple : Un oncle peut avoir plusieurs neveux et les

neveux peuvent avoir plusieurs oncles
Les cardinalités définissent le nombre maximal d’occurrences d’une

entité pouvant participer à une relation. Les cardinalités n’indiquent
pas cependant si une occurrence particulière d’une entité participe à
la relation.
Afin de définir cette information, le modèle de données doit définir les

modalités de la relation entre deux entités.
MODALITÉS
La modalité d’une relation est 0 si la relation peut être optionnelle

entre deux entités.
La modalité est 1 si une occurrence d’une entité est obligatoire à

l’établissement de la relation.
Cardinalite/Modalité Signification
0 (0,n)
|| (1,1)
0< (0, n)
|< (1, n)
12.3.3 MODÈLE CONCEPTUEL DES DONNÉES(MCD)
MODÈLE/DIAGRAMME ENTITÉ/RELATION
Des paires d’entités reliées par des relations sont la base des
modèles de donnés. Un ensemble de paires d’entités reliées par des
relations peuvent être représentées graphiquement sous la forme
d’un diagramme entité/relation.
Le diagramme entité/relation a été développé par Peter Chen pour la

conception des bases de données relationnelles et l’application de ce
modèle s’est étendu à d’autres problèmes de l’analyse informatique.
Un ensemble de composantes élémentaires font partie du

diagramme entité/relation :
- Entités
- Attributs
- Relations
- Cardinalités
Le but principal du diagramme entité/relation est de représenter les

entités et leurs relations.
La modélisation des données et les diagrammes entité/relation

fournissant à l’analyste une représentation efficace des données
dans le cadre de la conception de logiciel.
Dans la plupart des cas, la modélisation des données constitue une

partie de l’analyse d’un système, mais ces techniques peuvent
également être utilisées dans la conception de bases de données
ainsi que pour supporter diverses tâches d’analyse des besoins.
Manufacturier 1,n Automobile
1,1 Fabrique
HIÉRARCHIE DES ENTITÉS
Dans plusieurs cas, l’analyste peut représenter les entités sous forme
hiérarchique. Une entité peut parfois représenter une classe ou une
catégorie d’informations
ASSOCIATION DES ENTITÉS
12.4 MODÈLE FONCTIONNEL ET FLUX D ‘INFORMATION
L’information est transformée lors de sa circulation dans les systèmes

informatisés.
Le système accepte les entrées sous forme variée, utilise des

éléments matériels, logiciels et humains afin de les transformer.
Le système génère des sorties sous différentes formes également.
L’analyse structurée débute par les techniques de modélisation des

flux d’informations.
ELÉMENTS COMPOSANT LES DIAGRAMMES DE FLUX DE
DONNÉES :
- ENTITÉ EXTERNE
Client
Élément d’un système(composante, personne, autre programme)

ou un autre système produisant de l’information en vue de la
transformation par le logiciel ou qui reçoit de l’information produite
par ce logiciel
- PROCESSUS
ou
Processus ou fonction appliqué aux données afin de les transformer
- FLUX D’INFORMATION
Représente le mouvement de un ou plusieurs éléments d’information
- DÉPÔT D’INFORMATION
Enregistrement d’information utilisé par le logiciel

12.4.1 DIAGRAMME DE FLUX DE DONNÉES(DFD)
Durant le parcours de l’information dans le logiciel, celle-ci est

modifiée par une série de transformations. Un diagramme de flux de
données est une représentation graphique décrivant les mouvements
(flux) d’informations ainsi que les transformations appliquées aux
données lors de leur passage de l’entrée vers la sortie
Un DFD de niveau 0 est appelé « Modèle fondamental de système »

ou « Modèle de contexte ». Ce modèle représente le système
complet comme un simple processus avec ses entités externes et
ses flux de données.
Chacun des processus peuvent être éclatés
SPÉCIFICATION DES PROCESSUS
Pour plus de précision, la notation graphique du diagramme des flux

de données doit être précisée avec du texte descriptif.
La spécification du processus décrit :
- les entrées d’une fonction
- l’algorithme de transformation des entrées
- les sorties produites
- restrictions et limites imposées
- caractéristiques de la performance (spécifications)
- contraintes de conception
12.4.2 EXTENSIONS POUR LES SYSTÈMES EN TEMPS

RÉELS
Un grand nombre d’applications logicielles sont dépendantes du

temps et traitent des informations de contrôle comme données.
Un système en temps réel doit interagir avec les contraintes

imposées par l’environnement réel.
Pour adapter les méthodes de conception aux systèmes en temps

réel, un nombre d’extensions aux notions élémentaires de l’analyse
structurée ont été définies.
12.4.3 EXTENSIONS WARD ET MELLOR
Les extensions de Ward et Mellor adaptent les techniques de base

de l’analyse structurée aux exigences imposées par les systèmes en
temps réel :
- les flux d’information sont saisis ou produits continuellement

dans le temps
- traitement des informations de contrôle et circulation des

informations de contrôle à travers le système
- plusieurs instances d’une même transformation sont

rencontrées lors des traitements multi-tâches
- les systèmes ont des états et un mécanisme cause les

transitions entre les états
REPRÉSENTATION DES TRAITEMENTS EN TEMPS CONTINU
Les flèches à pointe double représentent des flux d’information en

temps continu
FLUX DE CONTRÔLE
- Flèche solide : flux de données (d’information)
- Flèche pointillée : flux de contrôle
- Cercle pointillé : processus/traitement de contrôle

12.4.4 EXTENSIONS HATLEY ET PIRBAHI
Les extensions Hatley et Pirbhai à l’analyse structurée des systèmes

se concentrent principalement sur la représentation et les
spécifications des aspects de contrôle du logiciel plutôt que sur la
création de symboles graphiques additionnels.
Spécification des processus(PSPEC) : Spécifications du processus

de traitement
Spécifications de contrôle(CSPEC) : contrôlent les processus en

fonctions des événements. Elles définissent :
- le comportement du logiciel lorsqu’un événement ou un

signal de contrôle est détecté
- quel processus est activé lors du déclenchement d’un

événement
Les diagrammes de flux de données sont utilisés afin de représenter

les données et les processus
Les diagrammes de flux de contrôle représentent les processus et les

flux d’événements et illustrent les événements externes activant les
processus
INTER-RELATION ENTRE LES PROCESSUS DE CONTRÔLE
DIAGRAMME DE FLUX DE DONNÉES ET DIAGRAMME DE FLUX
DE CONTRÔLE
Une condition d’information se présente lorsque les données d’entrée

à un processus génèrent un flux de contrôle en sortie
12.5 MODÉLISATION DES COMPORTEMENTS(ÉTATS)
La modélisation des comportements est un principe opérationnel

applicable dans toutes les méthodes d’analyse des besoins.
DIAGRAMME D’ÉTATS/STATE TRANSITION DIAGRAM(STD)
Le diagramme d’états représente le comportement d’un système en

identifiant ses différents états et les événements causant des
transitions entre les états. Ce diagramme indique également quelles
actions (réactions) sont prises à la suite de l’arrivée d’un événement
particulier.
DIAGRAMME DE FLUX DE CONTRÔLE

DIAGRAMME D’ÉTATS
12.6 TECHNIQUES DE L’ANALYSE STRUCTURÉE
La notation et les symboles graphiques utilisés dans l’analyse

structurée doivent être combinés avec un ensemble d’heuristiques
permettant à l’analyste de créer un modèle d’analyse adéquat.
12.6.1 CRÉATION DU MODÈLE CONCEPTUEL DE
DONNÉES(MCD)
DIAGRAMME/MODÈLE ENTITÉ/RELATION
Le modèle entité/relation permet à l’analyste de système de définir

complètement les entités qui sont les entrées et les sorties du
système, les relations les reliant et les attributs définissant les
propriétés des objets.
Le modèle conceptuel de données est construit d’une manière

itérative et comprend les étapes suivantes :
(1) Lors de la définition des besoins du client, l’analyste

demande au client d’énumérer les éléments d’information
traités par l’application ou le processus de gestion. Ces
éléments d’information se regroupent en entités internes et
externes
(2) Le client détermine si des liens existent entre les entités
(3) L’analyste et le client définissent une relation pour chaque

lien
(4) Détermination des cardinalités et des modalités pour chaque

relation
(5) Répéter les étapes de (2) à (4) jusqu’à ce que toutes les
relations soient définies
(6) Identifier les attributs de chaque entité
(7) Un diagramme entité/relation formel est crée et révisé
(8) Les étapes de (1) à (7) sont répétées jusqu’à ce que le

modèle soit complet
Liste des éléments d’informations composés majeurs du système
« MaisonSécuritaire »
IDENTIFICATION DES RELATIONS

12.6.2 CRÉATION D’UN DIAGRAMME DE FLUX DE
DONNÉES(DFD)
Le diagramme de flux de données permet à l’analyste de systèmes

de développer des modèles du domaine de l’information et des
modèles du domaine fonctionnel.
Lorsque le diagramme de flux de données est raffiné à des plus

grands niveaux de détails, l’analyste effectue une décomposition
implicite fonctionnelle du système.
Le raffinement (éclatement) du diagramme de flux de données

résulte en un raffinement correspondant des données.
Le diagramme de flux de données est construit d’une manière

itérative et comprend les étapes suivantes :
(1) le niveau 0 du diagramme de flux de données (modèle

contextuel ou modèle fondamental de système) devrait
représenter le logiciel/système sous la forme d’un processus
unique
(2) les entrées et sorties primaires du système sont identifiées
(3) le raffinement constitue en l’isolement d’un processus pour

être décomposé au prochain niveau
(4) Les processus et les flux d’informations devraient avoir des

noms significatifs
(5) La continuité des flux d’information devrait être conservée

d’un niveau à l’autre
(6) L’éclatement se fait pour seulement un processus à la fois

DIAGRAMME DE NIVEAU 0 (Modèle contextuel/Modèle fondamental
de système)
DIAGRAMME DE NIVEAU 1 (Éclatement du processus « SafeHome
Software »)
DIAGRAMME DE NIVEAU 2 (Éclatement du processus « Monitor
Sensors »
12.6.3 CRÉATION D’UN DIAGRAMME DE CONTRÔLE DES
FLUX
12.6.4 SPÉCIFICATIONS DE CONTRÔLE
Les spécifications de contrôle (CSPEC) représentent le

comportement du système de deux manières différentes :
(1) Les spécifications de contrôle contiennent un diagramme

d’états spécifiant le comportement du système
(2) Les spécifications de contrôle peuvent également avoir une

table d’activation des processus (spécification combinatoire
des comportements)
DIAGRAMME DE CONTRÔLE DU NIVEAU 1 DU SYSTÈME

« MAISON SÉCURITAIRE »
SPÉCIFICATIONS DES PROCESSUS
La spécification des processus (PSPEC) est utilisée pour décrire tous

les processus apparaissant au niveau final de l’analyse. Le contenu
des spécifications des processus peut contenir :
- un texte
- pseudocode de l’algorithme du processus
- équations mathématiques
- tables
- diagrammes
La spécification de chaque processus des diagrammes de flux de

données permettent de créer les mini-spécifications des
spécifications des besoins du logiciel et servent de guide à la
conception des composantes logicielles du processus.
Exemple : spécification du processus de validation du mot de passe

du système « MaisonSécuritaire » :
PSPEC : processus « mot de passe »
Le processus « mot de passe » effectue toutes les validations du

système « MaisonSécuritaire ». Le processus « mot de passe » reçoit
en entrée un mot de passe de quatre chiffres du processus
« interaction avec l’usager ». Le mot de passe est comparé au mot
de passe du système. Si le mot de passe est correct, <valid id
message = true> est fourni en entrée à la fonction « visionnement
des messages et du statut ». Si le mot de passe n’est pas bon, les
quatre chiffres seront comparés à une table de mots de passe
secondaire (ces mots de passe peuvent être donnés aux invités ou
aux travailleurs ayant besoin d’entrer dans la maison lorsque le
propriétaire n’est pas présent). Si le mot de passe est validé, <valid id
message = true> est fourni en entrée à la fonction « visionnement
des messages et du statut ». Si le mot de passe est invalide, <valid id
message = false> est fourni en entrée à la fonction « visionnement
des messages et du statut ».
12.7 DICTIONNAIRE DE DONNÉES
Le modèle d’analyse englobe la représentation des entités, des

fonctions et des éléments de contrôle. Dans chaque représentation
les entités et/ou les éléments de contrôle jouent un rôle. Cependant,
il est nécessaire de fournir une approche organisée pour représenter
les caractéristiques de chaque élément d’information (attribut) et de
chaque item de contrôle. Ceci est accompli avec le dictionnaire de
données.
Le dictionnaire de données a été défini comme étant une grammaire

quasi formelle décrivant le contenu des objets (entités, items de
contrôle) définis durant l’analyse structurée.
Le dictionnaire de données est une liste organisée de tous les

éléments d’information qui sont pertinents pour le système. Ces
éléments d’information sont définis rigoureusement et avec précision
pour que l’usager et l’analyste aient la même compréhension des
entrées, des sorties, du contenu de fichiers et des calculs
intermédiaires.
Actuellement, le dictionnaire de données peut être généré par les

outils informatisés d’aide à la conception de logiciels. Bien que le
format des dictionnaires crée puisse varier d’un outil à l’autre, la
plupart contiennent les informations suivantes :
- Nom : le nom de l’élément d’information, de l’item de

contrôle, du dépôt de données ou de l’entité externe
- Alias : autre noms désignant une donnée
- Endroit de l’utilisation/Modalités d’utilisation : liste des

processus utilisant l’élément d’information, des éléments de
contrôle interagissant avec l’élément d’information et
comment celui-ci est utilisé (Ex. : fourni en entrée à un
processus, crée à la sortie d’un processus, résidant dans un
dépôt de données et agissant comme une entité externe)
- Description du contenu de la donnée : description de la
structure de la donnée ou de son type (entier, réel, etc.)
- Information supplémentaire : information supplémentaire

concernant les types de données, les valeurs par défaut,
restrictions, limites, etc.
Exemple : Définition de l’élément d’information (attribut) Numéro de

téléphone
Nom : Numéro de téléphone
Alias : Aucun
Endroit d’utilisation
Modalités d’utilisation : Comparer avec la configuration initiale (sortie)
Signaler le numéro (entrée)
Description :
Numéro de téléphone = [numéro local][numéro longue distance]
Numéro local = préfixe + numéro d’accès

Numéro longue distance = 1 + code régional + numéro local
Code régional = [800 | 888 | 561]
Préfixe = * un nombre de trois chiffres ne débutant

jamais par 0 ou 1*
Numéro d’accès = * toute chaîne de quatre nombres *
Dans le cas de très gros systèmes informatiques, le dictionnaire de

données augmente très rapidement en fait de dimensions et de
complexité.
Il est ainsi très difficile de tenir manuellement un tel dictionnaire à

jour. Le dictionnaire de données est donc généralement tenu à jour
par les outils informatisés d’aide à la conception de logiciels
12.8 AUTRES MÉTHODES CLASSIQUES D’ANALYSE
Avec les années, une multitude de méthodes pertinentes d’analyse

des besoins du logiciel on été utilisées dans l’industrie.
Bien que toutes ces méthodes suivent les principes d’analyse

opérationnelle, chacune d’elles utilise des notations différentes et un
ensemble unique d’heuristiques afin de produire un modèle
d’analyse.
En voici quelques unes des plus utilisées :
- Méthode de développement des systèmes à base de

données structurées
- Système de développement de Jackson
- Techniques d’analyse et de conception structurée

COURS 06

Généralités et Principes de la Conception du Logiciel
Le but du concepteur est de produire un modèle ou une

représentation d’une entité à construire.
Il y a deux phases principales à n’importe quel processus de

conception :
(1) Diversification : l’acquisition d’un ensemble d’éléments à la

base de la conception :
a. composantes,
b. composantes de solutions; et
c. connaissances
Ces éléments étant contenus dans les catalogues, les écrits

et la pensée.
(2) Convergence : lors de cette étape, le concepteur choisit et

agence les éléments appropriés afin de rencontrer les
objectifs de la conception, tel que spécifié dans le rapport de
spécification des besoins du logiciel.
Cette phase est l’élimination graduelle des configurations

particulières des composantes pour n’en garder qu’une. La
configuration sélectionnée sert finalement à créer le produit
final.
Les phases de diversification et de convergence combinent :
- l’intuition et le jugement basé sur l’expérience de la

conception d’entités similaires
- un ensemble de critères permettant l’évaluation de la qualité
- un processus itératif conduisant à une réalisation finale des

plans du système
La conception du logiciel, comme les approches de conception de

l’ingénierie des autres disciplines, évolue continuellement en fonction
des nouvelles méthodes, de l’évolution des techniques d’analyse et
d’une meilleure compréhension du problème à résoudre.
Les méthodologies de conception du logiciel souffrent d’un manque

de profondeur, de flexibilité et de description quantitative qui sont
normalement associées aux disciplines de conception classiques de
l’ingénierie.
Cependant, des méthodes de conception de logiciel existent, des

critères d’évaluation de la qualité de la conception sont définis ainsi
qu’un certain formalisme de notation.
13.1 LA CONCEPTION DU LOGICIEL ET L’INGÉNIERIE DU
LOGICIEL
La conception du logiciel se situe à l’étape technique de la

conception du logiciel et ses méthodes sont appliquées
indépendamment du processus de conception du logiciel en
application.
La conception du logiciel débute après l’analyse des besoins et la

formulation des spécifications.
La conception du logiciel est la première des trois phases techniques

(conception, programmation et vérification) requises pour la
construction et la vérification du logiciel. Chaque activité transforme
l’information afin de produire un logiciel validé.
Chacun des éléments du modèle d’analyse fournit de l’information

nécessaire à la création des quatre modèles de conception
nécessaires à la spécification complète de la conception.
Les spécifications du logiciel, définies par le modèle des données, le

modèle fonctionnel et le modèle comportemental servent de données
d’entrée au modèle de conception.
Les tâches de conception utilisent une méthode de conception pour
produire :
- la conception des structures de données
constitué à partie du modèle entité-relation et du dictionnaire

de données
- la conception de l’architecture du logiciel
définit les relations et la structure entre les fonctions

principales du logiciel. L’architecture du logiciel peut être
dérivée des spécifications du système, du modèle d’analyse
et de l’interaction entre les composantes définies à l’intérieur
du modèle d’analyse
- conception de l’interface
décrit le déplacement de l’information à l’intérieur du logiciel,

les systèmes communiquant avec le logiciel ainsi que les
interfaces de communication avec les être humains.
une interface implique un flux d’information (flux de données

ou flux de contrôle) et un type de comportement spécifique.
L’information nécessaire à la conception de l’interface est

fournie par les diagrammes des flux de données et les
diagrammes des flux de contrôle.
- conception des niveaux des processus
transforme la structure des éléments de l’architecture du

logiciel en une description procédurale des composantes du
logiciel.
l’information nécessaire à la conception des composantes

est fournie par les spécifications des processus(PSPEC), les
spécifications de contrôle(CSPEC) et les diagrammes
d’états(STD)
Le processus de conception du logiciel est le seul moyen de traduire

les besoins du client en un logiciel ou un système informatique fini.
Les étapes de conception vont influencer le succès de la réalisation

du logiciel, sa qualité, sa stabilité et sa facilité d’entretien.
13.2 LE PROCESSUS DE CONCEPTION
La conception du logiciel est un processus itératif par lequel les

besoins sont traduits en plans de système. Initialement, les plans de
système représentent une vue globale du système.
A la suite de la progression des itérations du processus de

conception, des raffinements successifs conduisent à des
représentations du système à des plus bas niveaux d’abstraction.
13.2.1 FACTEURS DE QUALITÉ DE LA CONCEPTION DU

LOGICIEL ET QUALITÉ DU LOGICIEL
Tout au long du processus de conception, la qualité de l’évolution des

plans de système est évaluée formellement. Les trois caractéristiques
suivantes peuvent servir de guide à l’évaluation d’une bonne
conception :
- la conception doit implanter tous les besoins explicites

contenus dans le modèle d’analyse et doit satisfaire
également tous les besoins implicites désirés par le client
- les plans de système doivent être un guide lisible et

compréhensible pour les programmeurs, pour ceux qui
vérifient le système et ceux qui vont faire l’entretien et le
support du logiciel
- la conception devra fournir une représentation complète du

logiciel, de l’emplacement des données, de la fonctionnalité
et de ses différents états
Dans le but d’évaluer la qualité des plans de système, les critères
techniques suivants visent à l’assurance d’une bonne conception :
- les plans de système devraient générer une architecture du

logiciel :
o crée selon des modèles reconnaissables
o composée de modules démontrant de bonnes
caractéristiques de conception
o pouvant être implantées d’une manière évolutive facilitant
l’implantation et la vérification
- la conception doit être modulaire (le logiciel devrait être

logiquement décomposé en éléments effectuant des
fonctions et des sous-fonctions spécifiques
- les plans de système devraient contenir des représentations

distinctes des données, de l’architecture, des interfaces et
des composantes (modules)
- la conception devra générer des structures de données

appropriées aux modules à implanter et qui découlent de
structures de données identifiables (vecteur, matrice, file,
pile, liste, arbre, graphe, fichier, base de données
relationnelle, etc.)
- la conception devra générer des composantes ayant des

caractéristiques fonctionnelles indépendantes (routine de
lecture, routine d’écriture et non routine de lecture-écriture)
- la conception devra générer des interfaces réduisant la

complexité des connections entre les modules et
l’environnement externe
- les plans de systèmes devront être générés par des

méthodes reproductibles et en fonction des informations
obtenues lors de l’analyse des besoins
13.2.2 L’ÉVOLUTION DES TECHNIQUES DE CONCEPTION
DU LOGICIEL
- Processus qui a évolué continuellement durant les 40

dernières années
- Les premiers travaux étudiant la conception du logiciel se

sont concentrés sur des critères visant le développement de
programmes modulaires et des méthodes de raffinement des
structures du logiciel selon l’approche « Top-Down »
- Les aspects procéduraux de la conception ont abouti au

concept de programmation structurée
- Conversion des flux de données et des structures de

données en plans de système
- Approche orientée-objet
- Modèles de conception d’architecture du logiciel
- La plupart des méthodes ont des caractéristiques

communes :
o Mécanismes de conversion d’un modèle d’analyse en

plans de système
o Symbolisme de représentation des composantes

fonctionnelles ainsi que leurs interfaces
o Heuristique de raffinement et de partition
o Lignes directrices pour l’évaluation de la qualité
Peu importe la méthode de conception utilisée, l’analyste doit

appliquer un ensemble de principes fondamentaux et de concepts de
base aux données, à l’architecture du logiciel à l’interface et à la
hiérarchie des composantes
13.3 LES PRINCIPES DE LA CONCEPTION
La conception du logiciel est simultanément un processus et un

modèle :
- le processus de conception du logiciel est une suite d’étapes

permettant à l’analyste de décrire tous les aspects du logiciel
à construire
- le modèle de conception se définit comme étant les plans de

système. Les plans de système représentent premièrement
l’ensemble du système à construire et raffine le modèle afin
de spécifier la construction de chaque détail.
Les principes de base de la conception sont appliqués par l’analyste
tout au long du processus de conception. Les principaux principes de
base de la conception sont les suivants :
- le processus de conception ne devrait pas souffrir de la

« vision en tunnel ».Le concepteur devra considérer des
approches alternatives
- la conception devrait respecter le modèle d’analyse
- le processus de conception devra étudier le fait de ré-utiliser

certains modules ou fragments de code
- la structure des plans de système devra être en fonction de

la structure du domaine du problème
- une certaine uniformité et intégration devra être respectée

dans les plans de système
- la conception devra être structurée en fonction de

l’adaptation aux changements
- le logiciel devra être tolérant aux fautes et aux erreurs
- la conception n’est pas la programmation – la

programmation n’est pas la conception
- la qualité de la conception devrait être évaluée tout au long

du processus de conception
- la conception devrait être évaluée afin de minimiser les

erreurs conceptuelles (sémantiques)
Lorsque ces principes de conception sont appliqués

rigoureusement, l’analyste du logiciel génère une conception
démontrant des facteurs de qualité interne et externe.
13.4 LES CONCEPTS DE LA CONCEPTION
L’ensemble des concepts fondamentaux des concepts de la

conception du logiciel ont considérablement évolué durant les quatre
dernières années.
Bien que le degré d’intérêt au niveau de chaque concept ait évolué

au fil des années, chacun des concepts a survécu et fournit à
l’analyste une base à partir de laquelle des méthodes plus
perfectionnées de conception puissent être appliquées.
Chacun de ces concepts aide l’analyste à répondre aux questions

suivantes :
- Quels critères peuvent être utilisés afin de diviser le logiciel

en composantes individuelles?
- Comment les détails des fonctions ou des structures de

données sont séparées de la représentation conceptuelle du
logiciel?
- Quels critères uniformes déterminent la qualité technique de

la conception du logiciel?
13.4.1 L’ABSTRACTION
La notion de l’abstraction permet de se concentrer sur un problème à

différents niveaux de généralisation sans considérer les détails de
bas niveaux.
L’utilisation de l’abstraction permet de travailler avec des concepts et

des termes familiers du domaine du problème sans avoir à
considérer de notation particulière.
Chaque étape du processus de conception du logiciel est un niveau

de l’abstraction du logiciel final.
La conception du logiciel utilise trois formes d’abstraction :
(1) abstraction procédurale (méthodes)
séquence d’instructions ayant des fonctions spécifiques et

limitées (ex. aller ouvrir la porte)
(2) abstraction des données (types abstraits/objets)
ensemble de données décrivant une entité. Exemples :
objet : porte
attributs (type, direction d’ouverture, poids, couleur, etc.)
méthode : ouvrir
(3) abstraction de contrôle
spécifie un mécanisme de contrôle interne d’un logiciel sans

définir sa représentation interne. Exemple : sémaphore de
synchronisation
13.4.2 LE RAFFINEMENT
Le raffinement est un processus d’élaboration. Ce processus débute

par l’énonciation d’une fonction(ou d’une description de l’information)
qui est définie à un haut niveau d’abstraction.
L’énoncé décrit la fonction ou l’information conceptuellement mais ne

fournit aucune information sur les mécanismes internes de la fonction
ou de la structure interne de l’information.
Le raffinement fait en sorte que l’analyste élabore l’énoncé original de

la fonction en fournissant de plus en plus de détails à chaque fois
qu’un raffinement successif (élaboration) se produit.
L’abstraction et le raffinement sont deux concepts complémentaires.
L’abstraction permet à l’analyste de spécifier des procédures et des

données en évitant de fournir des détails de bas niveau.
Le raffinement aide le concepteur à définir les détails de bas niveau

tout au long de l’évolution du processus de la conception.
Les deux concepts aident l’analyste à compléter un modèle lors de

l’évolution du processus de conception.
13.4.3 LA MODULARITÉ
Le concept de modularité dans le domaine du logiciel est appliqué

depuis plus de 50 ans. L’architecture du logiciel utilise la modularité
par le fait que le logiciel est divisé en composantes séparées et
adressables, souvent appelées modules, qui sont intégrés pour
satisfaire les spécifications d’un problème.
La modularité fait en sorte qu’un large programme soit

compréhensible. Les programmes monolithiques (un large
programme composé d’un seul module) sont difficiles à comprendre
par une personne humaine.
Critères de détermination de la taille des modules en fonction de
l’obtention d’une modularité optimale :
- critères de décomposition modulaire
si une méthode de conception possède un mécanisme

systématique de décomposition des problèmes en sous-
problèmes, la complexité du problème sera réduite et la
solution sera modulaire
- critères de composition modulaire
si une méthode de conception permet l’utilisation de

composantes logicielles ou de modules déjà existants
- critères de compréhension modulaire
si une méthode de conception permet la compréhension

d’un module sans faire référence aux autres
- critères de continuité modulaire
lorsque des modifications au système résultent au niveau de

changements à des modules individuels, les effets de bord
seront diminués (limités à un module)
- critères de protection modulaire
lorsqu’une erreur contenue dans un module se répercute

seulement dans les résultats des sorties de ce module, les
impacts d’erreurs des effets de bord seront réduits
13.4.4 L’ARCHITECTURE DU LOGICIEL
L’architecture du logiciel est définie comme étant la structure globale

du logiciel et les façons dans lesquelles cette structure fournit
l’intégrité conceptuelle d’un système.
Dans sa forme la plus simple, l’architecture du logiciel est la structure

hiérarchique des composantes d’un programme (modules), la
manière dont ces composantes interagissent et les structures de
données utilisées par ces composantes. Par extension, les
composantes peuvent être généralisées comme étant des éléments
principaux du système ainsi que leurs interactions.
L’un des buts de la conception du logiciel est de générer un plan de

l’architecture du système. Ce plan servira ensuite de cadre à partir
duquel des activités de conception plus détaillées seront effectuées.
L’ensemble de propriétés suivant devra être spécifié comme faisant

partie de la conception de l’architecture :
- propriétés structurelles – définit les composantes d’un

système (modules, objets, filtres) et la manière dans lequel
ces composantes sont regroupées et interagissent ensemble
- propriétés extra-fonctionnelles – comment l’architecture du

logiciel rencontre les exigences de performance, capacité,
fiabilité, sécurité, etc.
- familles de systèmes connexes – le système doit pouvoir

utiliser des modules préfabriqués ou des fonctions ou de
modules déjà existants
Les plans de système peuvent être représentés en utilisant un ou
plusieurs des modèles suivants :
- modèle structurel – représente l’architecture comme un

regroupement organisé de programmes et de composantes
- modèle des cadres (framework) – augmentent le degré

d’abstraction de la conception par l’identification de cadres
architecturaux(patterns) rencontrés dans des applications
similaires
- modèle dynamique – étudient les aspects du comportement

de l’architecture du programme en indiquant comment la
structure ou la configuration du système change en fonction
des événements externes
- modèle des processus – se concentre sur la conception des

processus d’affaires ou scientifiques que le système doit
réaliser
- modèle fonctionnel – représente la hiérarchie des fonctions

du système
13.4.5 HIÉRARCHIE DE CONTRÔLE
La hiérarchie de contrôle, également appelée structure du

programme, représente l’organisation des composantes du
programme (modules) et implique une hiérarchie de contrôle.
La hiérarchie de contrôle ne représente pas les aspects procéduraux

du logiciel tels que la séquence des processus.
La profondeur et la largeur fournissent une indication du nombre de

niveaux de contrôle et de l’étendue totale du contrôle.
Le déploiement « Fan-Out » est une mesure du nombre de modules

directement contrôlés par un module.
Le « Fan-In » indique combien de modules contrôlent directement un

module donné.
La visibilité indique l’ensemble de programmes pouvant être utilisés

directement ou indirectement par un autre programme.
La connectivité indique l’ensemble de programmes pouvant être

utilisés directement par un autre programme.
13.4.6 PARTITION STRUCTURÉE
Si le type d’architecture d’un système est hiérarchique, la structure

des programmes peut être séparée horizontalement et
verticalement :
- partition horizontale
la partition horizontale définit des branches séparées de la

hiérarchie modulaire pour chaque fonction majeure du
programme. Les modules de contrôle sont utilisés pour la
coordination de la communication entre l’exécution et durant
l’exécution des fonctions
- partition verticale (factorisation) – définit que les modules de

contrôle(prise de décision) et que les modules de travail
devraient être distribués de haut en bas dans la structure du
programme. Les modules de haut niveau devraient effectuer
les fonctions de contrôle et un traitement minimal. Les
modules situés au bas de la structure devraient effectuer les
tâches de travail telles que les opérations de calcul et les
entrées/sorties.
13.4.7 STRUCTURE DES DONNÉES
Une structure de données est une représentation logique des

relations entre les éléments individuels de données.
La structure de l’information ayant une influence directe sur la

conception des modules, les structures de données sont aussi
importantes que les structures des programmes dans l’établissement
de la structure du logiciel.
13.4.8 PROCÉDURE DU LOGICIEL
La structure du programme définit la hiérarchie de contrôle sans tenir

compte de la séquence des traitements et des décisions. Les
procédures logicielles se concentrent sur les détails de traitement de
chaque module individuellement.
Les procédures doivent fournir des spécifications précises de

traitement :
- séquence des événements
- les points exacts de décision
- les opérations répétitives
- l’organisation des données
- les structures des données
Il y a une relation entre les structures et les procédures. Le traitement

spécifié pour chaque module doit inclure une référence à tous les
modules subordonnée au module analysé.
13.4.9 DISSIMULATION DE L’INFORMATION
Le principe de dissimulation de l’information définit que les modules

soient caractérisés par des décisions de conception les dissimulant
les uns par rapport aux autres. Les modules doivent être spécifiés et
construits de façon à ce que les informations (procédures et
données) contenues dans un module soient inaccessibles aux autres
modules n’ayant pas besoin de cette information.
La dissimulation implique que la modularité effective puisse être

réalisée par la définition d’un ensemble de modules indépendants
pouvant communiquer ensemble seulement par l’échange de
l’information nécessaire à l’accomplissement de leurs fonctions
logicielles.
L’abstraction aide à la définition des entités procédurales (ou

d’information) constituant le logiciel. La dissimulation définit et
renforce les contraintes d’accès aux détails procéduraux et aux
structures de données locales de ce module.
L’utilisation de la dissimulation de l’information comme critère de

conception des systèmes modulaires améliore l’implantation des
modifications lors des vérifications et de l’entretien du logiciel.
La majeure partie des données et des procédures étant dissimulées

des autres parties du logiciel, les erreurs introduites durant les
modifications sont moins sujettes à se propager à d’autre parties du
logiciel.
13.5 CONCEPTION MODULAIRE EFFICACE
Tous les concepts fondamentaux de la conception servent à produire

des logiciels modulaires.
La modularité est une approche mise en application dans toutes les

disciplines de l’ingénierie.
Une conception modulaire réduit la complexité, facilite les

changements et résulte en une implantation plus facile en favorisant
le développement concurrent de différentes parties d’un système.
13.5.1 INDÉPENDANCE FONCTIONNELLE
L’indépendance fonctionnelle est réalisée par le développement de

modules comportant peu de fonctions et d’interaction avec les autres
modules
L’indépendance fonctionnelle est évaluée à l’aide de deux critères

qualitatifs :
- la cohésion : mesure de l’étendue fonctionnelle relative d’un

module(le nombre de fonctions qu’il accomplit)
- le couplage : mesure de l’interdépendance relative entre les

modules
13.5.2 COHÉSION
La cohésion est une extension logique du concept de la dissimulation

de l’information.
L’application du concept de la cohésion à un module fait en sorte que

celui-ci accomplit une seule tâche à l’intérieur d’une procédure
logicielle et ayant très peu d’interactions avec des procédures
s’exécutant dans d’autres parties du programme.
13.5.3 COUPLAGE
Le couplage est une mesure de l’interconnexion entre les modules

faisant partie d’une structure de logiciel.
Le couplage dépend de la complexité de l’interface entre les

modules, les points d’entrée ou de référence à un module et le type
des données traversant l’interface.
Lors de la conception du logiciel, l’analyste doit s’efforcer d’avoir un

taux de couplage le plus bas possible.
Une simple connexion entre les modules fait en sorte que le logiciel
est plus facile de compréhension et diminue la propagation des
erreurs.
13.6 HEURISTIQUES DE LA CONCEPTION MODULAIRE
EFFICACE
Une fois la structure du programme développée, une modularité

efficace peut être réalisée en appliquant les concepts de la
conception. La structure du programme peut être modifiée en
respectant les heuristiques suivantes :
- Évaluer la première itération de la structure du programme

afin de réduire le couplage et d’améliorer la cohésion
- Réduire les structures ayant un « fan-Out » élevé et

s’efforcer d’augmenter le « Fan-In » lorsque la profondeur
augmente
- Conserver la portée effective d’un module à l’intérieur de la
portée de contrôle de ce module
- Évaluer l’interface du module pour améliorer la consistance

afin de réduire la complexité et la redondance
- Définir des modules dont les fonctions sont prévisibles et

éviter les modules trop restrictifs
- Favoriser la conception de modules dont les entrées sont

contrôlées par l’évitement des connexions pathologiques
13.7 LE MODÈLE DE CONCEPTION
Le modèle de conception est représenté comme étant une pyramide.
Les étapes de conception doivent respecter le modèle de cette

pyramide :
- la fondation est basée sur la conception de données
- son milieu est constitué avec l’architecture du logiciel et la

conception de l’interface personne-machine
- la conception des composantes du logiciel à son sommet.
Les étapes ne doivent pas être effectuées en ordre inverse, car la

pyramide pourrait tomber.
13.8 PRODUCTION DE DOCUMENTATION DE SYSTÈME
Les spécifications de conception traitent de différents aspects du

modèle de conception et sont complétées lorsque l’analyste raffine
son modèle de représentation du logiciel. Cette documentation peut
comprendre les parties suivantes :
- Ampleur de la conception (dérivée des spécifications du

système et de la documentation du rapport de spécification
des besoins du logiciel)
- Structure des données
- Architecture du logiciel
- Interface personne-machine
- Composantes du logiciel (fonctions, procédures, sous-

routines)
- Spécification de la conception (détermination de capacité du

logiciel à rencontrer les besoins des clients)
- Documentation de validation
- Contraintes de conception
- Instructions de l’implantation de l’application sur le système

du client
- Données supplémentaires (Algorithmes, procédures, etc.)

COURS 07
Méthodes de Conception de l’Architecture du Logiciel
La conception du logiciel est décrite comme un processus composé

de plusieurs étapes dans lesquelles l’architecture des données, la
structure du programme et les détails procéduraux sont générés à
partir des besoins d’informatisation.
Tel qu’étudié précédemment, les plans de systèmes sont crées à

partir des données. Les plans de système sont crées à partir de :
- La modélisation des données
- l’analyse fonctionnelle
- l’analyse comportementale
14.1 ARCHITECTURE DU LOGICIEL
Depuis la division des programmes en modules, nous pouvons dire

que les logiciels ont une architecture. Les programmeurs sont
responsables des interactions entre les modules et des propriétés
globales du logiciel.
Historiquement, l’architecture du logiciel était reliée aux contraintes

de l’implantation ou de la version précédente du système.
Les bons concepteurs de logiciels ont souvent adopté un ou plusieurs

modèles d’architecture du logiciel comme stratégie de l’organisation
des systèmes. Ils utilisent cependant ces modèles intuitivement et ne
peuvent pas expliquer formellement la génération du système
résultant.
14.1.1 DÉFINITION DE L’ARCHITECTURE DU LOGICIEL
L’architecture d’un programme ou d’un système d’information est la

structure de l’ensemble des structures du système comprenant les
composantes logicielles, les propriétés visibles externes et les
relations entre ces composantes.
L’architecture du logiciel n’est pas son code, il s’agit plutôt d’une

représentation permettant à l’analyste de :
(1) effectuer l’analyse de l’efficacité de la conception en rapport

aux spécifications
(2) le changement à un autre modèle d’architecture à une étape

ou le changement n’est pas coûteux
(3) réduire les risques d’erreurs inhérents à la conception du

logiciel
14.1.2 IMPORTANCE DE L’ARCHITECTURE
- la représentation de l’architecture du logiciel est l’un des

sujets principaux entre les intervenants du développement
du logiciel
- la représentation de l’architecture du logiciel va servir à

appuyer certaines décisions de conception qui vont avoir un
impact profond sur le développement du logiciel et sur le
succès final de la réalisation du système comme étant une
entité opérationnelle
- la représentation de l’architecture du logiciel constitue un

modèle tangible de la structure du système et de l’interaction
entre ses composantes
14.2 CONCEPTION DE L’ARCHITECTURE DES DONNÉES
Comme toutes les activités de l’ingénierie du logiciel, la conception

de l’architecture des données (conception des données) génère un
modèle des données où de l’information du système représenté à un
haut niveau d’abstraction (compréhensible pour le client ou l’usager).
Ce modèle de données est ensuite raffiné en représentations

progressivement plus spécifiques pouvant être traitées par des
systèmes informatiques.
Dans plusieurs applications logicielles, l’architecture (la structure) des

données va avoir une profonde influence sur l’architecture du logiciel
traitant les données.
Les structures de données ont toujours été une partie importante de

la conception du logiciel. Au niveau des composantes du logiciel, la
conception des structures de données et des algorithmes associés
requis pour la manipulation de ces données est essentielle à la
création d’applications de haute qualité.
Au niveau de l’application, la conversion d’un modèle de données

(généré à partir des spécifications) en une base de données est
essentielle au bon fonctionnement du système.
Lors de la création d’applications de gestion, le regroupement des

informations entreposées dans différentes bases de données et
réorganisés dans des « entrepôts de données » permet la recherche
de données ou la découverte de connaissances pouvant avoir un
impact sur le succès de l’entreprise.
14.2.1 MODÉLISATION DES DONNÉES, STRUCTURES DE
DONNÉES, BASES DE DONNÉES ET LES ENTREPÔTS DE
DONNÉES
MODÉLISATION DES DONNÉES
Les entités définies durant l’analyse des besoins sont modélisés en

utilisant les diagrammes entité-relation et le dictionnaire de données.
STRUCTURES DE DONNÉES
La modélisation de données effectue la conversion des éléments de

l’analyse des besoins du logiciel en structures de données au niveau
des composantes du logiciel et, lorsque nécessaire, une architecture
de la base de données au niveau de l’application.
ENTREPÔTS DE DONNÉES
Un défi majeur des organisations est d’extraire de l’information

pertinente de ses systèmes d’information, particulièrement si celle-ci
peut être obtenue par des requêtes sur des jointures de tables de
bases de données.
Afin de résoudre ce problème, la communauté des technologies de

l’information a développé des techniques de recherche de
l’information appelées « Techniques de découverte de connaissance
dans les bases de données » (KDD : Knowledge Discovery in
Databases).
Ces techniques de recherche de l’information naviguent dans les

bases de données existantes en fonction de l’extraction d’information
pertinente. Cependant, l’existence de bases de données multiples,
les différentes structures de données, le degré de détail et d’autres
facteurs font en sorte que la recherche de données est difficile.
Une solution alternative, appelée « entrepôts de données » ajoute un

niveau supplémentaire à l’architecture des données.
Un entrepôt de données est un environnement de données séparé
qui n’est pas relié directement aux applications journalières et qui
englobe toutes les données utilisées par une entreprise. L’entrepôt
de données est une base de données étendue qui regroupe une
partie des données entreposées dans les différentes bases de
données servant aux applications courantes du système
d’information.
Plusieurs caractéristiques différencient un entrepôt de données d’une

base de données :
- domaine. Un entrepôt de données est classé par domaine

d’affaires plutôt que par des processus ou des fonctions.
Ceci peut exclure des données nécessaires pour accomplir
des fonctions particulières mais qui sont non requises pour
la recherche d’informations générales
- intégration. Sans tenir compte de la source, les données ont

des conventions de dénomination consistantes, des unités et
des mesures, des structures d’encodage et des attributs
physiques même si l’inconsistance existe au niveau des
bases de données orientées application
- persistance dans le temps. Dans le cas d’un environnement

d’applications orientées sur les transactions, les données
sont valides lors de l’accès durant un intervalle de temps
assez court (60 à 90 jours) avant l’accès. Dans le cas d’un
entrepôt de données, cependant, les données peuvent être
accédées à un moment précis dans le temps. L’intervalle de
temps dans le cas d’un entrepôt de données est de 5 à 10
ans
- non-volatilité. Contrairement aux applications de bases de

données typiques de la gestion qui subissent des
changements constants (insertion, effacement et mises à
jour), les données sont placées dans l’entrepôt de données
et ne changent pas après leur transfert original.
14.2.2 LA MODÉLISATION DES DONNÉES AU NIVEAU DES
COMPOSANTES
La modélisation des données au niveau des composantes se

concentre sur la représentation des structures de données qui sont
accédées directement par une ou plusieurs composantes logicielles.
Sachant que l’analyse des besoins et la conception se chevauchent,

nous considérons l’ensemble des principes suivants nous permettant
la spécification des données :
(1) Les principes systématiques de l’analyse appliqués aux

fonctions et aux comportements devraient également être
appliqués aux données
(2) Toutes les structures de données et les opérations

effectuées sur ces structures devraient être identifiées
(3) Un dictionnaire de données devrait être crée et utilisé pour

définir les données et les plans de système
(4) La conception de structures de données de bas niveau

devrait être retardée le plus tard possible dans le processus
de conception
(5) La représentation interne de la structure de données devrait

être connue seulement des modules devant faire un usage
direct des données à l’intérieur de cette structure
(6) Une librairie de structures de données utiles et d’opérations

utilisant ces structures devrait être développée
(7) La conception du logiciel ainsi que les langages de

programmation devraient supporter les spécifications et la
réalisation des types abstraits
14.3 TYPES ARCHITECTURAUX
Le logiciel construit pour les systèmes informatiques est catégorisé

par un des types architecturaux du logiciel. Chaque type décrit une
catégorie de systèmes informatiques qui comprend :
(1) un ensemble de composantes (base de données, modules

de calcul) exécutant une fonction requise par le système
(2) un ensemble de connecteurs permettant la communication,

la coordination et la coopération entre les composantes
(3) des contraintes définissant comment les composantes

peuvent être intégrées afin de composer le système
(4) des modèles schématiques permettant à l’analyste de

comprendre les propriétés d’ensemble du système par
l’analyse des propriétés connues de ses parties
constituantes
14.3.1 CLASSIFICATION DES TYPES ET DES MODÈLES
Bien qu’une multitude de systèmes informatiques ont été crées

durant les cinquante dernières années, la grande majorité peut être
catégorisée dans l’un des types d’architecture suivants :
- architectures orientées sur les données. Un dépôt de

données (fichier ou base de données) réside au centre de
cette architecture et est accédé fréquemment par les autres
composantes qui vont modifier, ajouter ou détruire des
données dans le dépôt.
- architectures orientées sur les flux de données « data-flow
architectures »
Cette architecture est utilisée lorsque les données d’entrée vont

être transformées à travers une série de modules de calculs ou de
manipulation pour produire les données de sortie.
Un modèle de représentation comportant des canaux (« pipes »)

et des filtres (« filters »). Les filtres sont reliés par des canaux.
Chaque filtre travaille indépendamment des autres.
Si le traitement des flux de données devient linéaire, ce traitement
s’intitule : séquentiel en lot (« batch sequential »)
- architectures d’appel de procédures « call and return

architectures »
Ce type d’architecture permet à l’analyste de réaliser une structure de

programme qui est relativement facile à modifier et à évaluer. Des
variantes existent dans cette catégorie :
 Architecture Programme principal/Sous-programme.

Cette structure classique des modules décompose les
fonctions en hiérarchie de contrôle où un programme
principal appelle un nombre de composantes de
programmes qui, à leur tour peuvent appeler d’autres
programmes
 Architecture d’appel de programme lointain. Les
composantes de l’architecture Programme principal/Sous-
programme sont distribuées sur un réseau et dans
plusieurs ordinateurs.
- architectures orientées-objet. Les composantes du système

encapsulent les données et les opérations manipulant ces
données. La communication et la coordination entre les
composantes est réalisée sous la forme de transfert de
messages
- architectures stratifiées (par couches). Un nombre de

différentes couches sont définies, chacune accomplissant
des opérations qui se rapprochent progressivement du
langage d’assemblage du processeur
14.3.2 ORGANISATION ET RAFFINEMENT
Le processus de conception du logiciel fait en sorte que l’analyste

doit choisir un type d’architecture du logiciel. Il est important d’établir
des critères de conception pouvant être utilisés pour évaluer un type
d’architecture envisagé. Les questions suivantes peuvent aider
l’analyste dans le choix d’une architecture :
 Contrôle
o Comment le contrôle est géré à l’intérieur de

l’architecture?
o Est-ce qu’une hiérarchie de contrôle distincte existe? Et si

oui, quels sont les rôles des composants à l’intérieur de
cette hiérarchie de contrôle?
o Comment les composantes transfèrent le contrôle à

l’intérieur du système?
o Comment le contrôle est-il partagé entre les

composantes?
o Quelle est la topologie du contrôle?
o Est-ce que le contrôle est synchronisé ou les

composantes opèrent dans un mode asynchrone?
 Données
o Structure de données/structure de messages transférant

les données entre les composantes?
o Est-ce que le flux des données est continu ou des

éléments de données traversent le système
sporadiquement?
o Quel est le mode de transfert des données (est-ce que

les données sont véhiculées d’un module à l’autre ou est-
ce que les données sont disponibles globalement et
partagées entre les composantes du système)?
o Est-ce que des composantes de données existent

(entités)?, et si oui, quels sont leur rôle?
o Comment les composantes fonctionnelles interagissent

avec les composantes des données?
o Est-ce que les composantes de données sont passives

ou actives (est-ce que les composantes de données
interagissent activement avec les autres composantes du
système)?
o Comment les données et les structures de contrôle

interagissent avec le système?
14.4 ANALYSE D’ARCHITECTURES ALTERNATIVES
14.4.1 MÉTHODE D’ANALYSE DES CHANGEMENTS

D’ARCHITECTURE
L’Institut d’Ingénierie du Logiciel [Software Engineering Institute(SEI)]

a développé une méthode d’analyse des changements d’architecture
[Architecture trade-off analysis method (ATAM)] qui établit un
processus d’évaluation itératif des architectures du logiciel. Les
activités d’analyse de la conception suivantes sont effectuées
itérativement :
(1) Rassembler les scénarios. Un ensemble de scénarios

d’utilisation est développé afin de visualiser le système du
point de vue de l’usager
(2) Énoncer la description des besoins, des contraintes et de

l’environnement. Cette information est nécessaire à l’analyse
des besoins et est utilisée pour s’assurer que toutes les
demandes des clients, usagers et des personnes ressources
ont été prises en considération.
(3) Décrire le type/les modèles d’architecture ayant été choisis

pour énoncer les scénarios et les besoins. Le type
d’architecture devrait être décrit en utilisant les aspects
architecturaux suivants:
a. Aspect des modules qui permet de faire l’analyse des

tâches de travail afin de connaître la dimension des
composantes et le degré de masquage de l’information
b. Aspect des processus qui permet de faire l’analyse des

performances du système
c. Aspect des flux de données qui permet d’analyser le

degré avec lequel l’architecture du logiciel rencontre les
besoins fonctionnels
(4) Évaluer les facteurs de qualité en évaluant chaque facteur
séparément. Le nombre de facteurs de qualité choisis pour
l’analyse varie en fonction du temps disponible pour
l’évaluation et du degré auquel l’étude de ces facteurs de
qualité est pertinente au système étudié. Les facteurs de
qualité pour l’évaluation des types d’architecture sont :
a. fiabilité
b. performance
c. sécurité
d. facilité d’entretien
e. flexibilité
f. vérification/test
g. portabilité
h. réutilisation
i. interopérabilité
(5) Évaluer l’influence des facteurs de qualité sur différentes

contraintes d’architecture pour un modèle d’architecture
spécifique. Cette évaluation peut être accomplie en faisant
des changements mineurs dans l’architecture et en étudiant
les répercussions des changements au niveau de facteurs
de qualité. Chaque facteur de qualité influencé
significativement par les variations de l’architecture est
désigné comme faisant partie des points sensibles.
(6) Évaluer les architectures candidates par les résultats de
l’analyse des facteurs de qualité (de l’étape 5). Une fois les
points sensibles de l’architecture trouvés, la détermination
des facteurs de changement d’architecture est simplement
l’identification d’éléments d’architecture pouvant influencer
plusieurs facteurs de qualité et de contraintes d’architecture.
14.4.2 LIGNES DIRECTRICE QUANTITATIVES DE

CONCEPTION D’ARCHITECTURE
L’un des problèmes principaux rencontrés par les analystes durant le

processus de la conception du logiciel est un manque de méthodes
quantitatives permettant l’évaluation des plans de systèmes
proposés.
Analyse du spectre
L’analyse du spectre évalue l’architecture du logiciel sur une échelle

de qualité (« goodness ») de la meilleure conception à la moins
bonne. Une fois que l’architecture du logiciel a été proposée, celle-ci
est évaluée à l’aide de notes pour chacun des volets de la
conception. Ces notes sont additionnées afin de déterminer la note
totale (S) de la conception. Des évaluations du pire cas sont
attribuées à une conception hypothétique, et une évaluation totale
(Sw) d’une architecture la moins bonne est calculée. Une évaluation
du meilleur cas (Sb) est calculée dans le cas d’une conception
optimale.
INDICE DU SPECTRE
Nous calculons l’indice du spectre (Is) en utilisant l’équation :
Is = [(S-Sw)/(Sb-Sw)] X 100
L’indice du spectre indique le degré auquel une architecture

proposée se compare à un système optimal à l’intérieur d’un domaine
d’options de conception.
Si des modifications sont faites aux plans de système ou si une

nouvelle conception est proposée, les indices de spectre des deux
options peuvent être comparés et un index d’amélioration (Imp) peut
être calculé :
Imp = Is1 – Is2
Cet indice fournit au concepteur des indications relatives de

l’amélioration associée aux changements de l’architecture ou à une
nouvelle architecture proposée. Si Imp est positif, nous pouvons
conclure que le système 1 a été amélioré relativement au système 2.
ANALYSE DES CHOIX DE LA CONCEPTION
L’analyse des choix de la conception est un autre modèle nécessitant

des critères d’évaluation. L’architecture proposée est évaluée afin de
déterminer le nombre de critères d’évaluation à satisfaire en
comparaison avec un système idéal.
Nous calculons l’indice de sélection de la conception (d) par la

formule suivante :
d = (Ns/Na) X 100
où Ns est le nombre de critères satisfaits par l’architecture proposée

et Na le nombre total de critères à satisfaire. Plus l’indice d est élevé,
plus l’architecture proposée se rapproche d’un système idéal.
14.4.3 COMPLEXITÉ DE L’ARCHITECTURE
Une technique utile permettant l’évaluation de la complexité d’une

architecture proposée est la considération des dépendances entre les
composantes de l’architecture. Ces dépendances résultent des
trajets des flux d’information et de contrôle à l’intérieur du système.
Ces dépendances peuvent se diviser en trois catégories :
(1) dépendances du partage de ressources. Représentent les

relations de dépendances entre des consommateurs qui
utilisent les mêmes ressources ou des producteurs de
ressources qui produisent pour les mêmes consommateurs.
(2) dépendances de flux d’information. Représentent des relations

de dépendances entre des producteurs et des consommateurs
de ressources.
(3) dépendances de contrainte (exclusion mutuelle). Représentent

des contraintes sur le contrôle relatif des flux de contrôle
durant un ensemble de processus.
14.5 CONVERSION DES SPÉCIFICATIONS EN ARCHITECTURE
DU LOGICIEL
Les spécifications du logiciel peuvent être modélisées sous

différentes formes de diagrammes.
La conversion exacte effectuant la transition des spécifications et de

modèles de données en différents types d’architecture n’existe pas.
La conception structurée découle de l’architecture d’appel de

procédures et s’effectue à partir des diagrammes des flux de
données. Elle est souvent caractérisée comme une méthode de
conception orientée sur les flux de données parce qu’elle fournit une
transition des diagrammes de flux de données en architecture du
logiciel.
La transition des flux d’information (représentée par les DFD) en

structure de programme est accomplie en six étapes :
(1) le type des flux de données est déterminé
(2) les limites des flux sont indiquées
(3) le DFD est converti en structure de programme
(4) la hiérarchie de contrôle est définie
(5) la structure résultante est raffinée par le processus de

conception
(6) la description de l’architecture est raffinée et élaborée

14.5.1 FLUX DE TRANSFORMATION
Les données fournies en entrée au système provenant des entités

externes doivent être convertie dans un format spécifique pour le
traitement.
L’information entre dans le système par des flux de données qui

transforment les données externes en format interne. Ces flux sont
identifiés comme étant des flux entrants.
Dans le noyau du système, des opérations se produisent. Les

données entrantes circulent à travers un centre de transformations
pour se diriger vers la sortie du système. Les données circulant dans
ces flux de données sont appelées flux sortants.
14.5.2 FLUX DE TRANSACTIONS
Le modèle fondamental du système comprend les flux de

transformations. Il est cependant possible d’inclure tous les flux de
données dans cette catégorie.
Les flux d’informations sont souvent constitués d’un simple élément

de données, soit une transaction, qui déclenche d’autres flux de
données sur un ou plusieurs chemins.
Les flux de transactions sont caractérisés par un déplacement des

données d’un chemin entrant effectuant la conversion de données
externes en transactions.
La transaction est évaluée et un déplacement sur l’un des chemins

d’action est effectué en fonction de sa valeur. Le centre de
convergence de l’information d’où sortent beaucoup de flux
d’information est appelé le centre des transactions.
Des flux de transactions et des flux de transformations se retrouvent

dans les diagrammes des flux de données des systèmes
informatiques d’envergure.
14.6 MODÉLISATION DES TRANSFORMATIONS
La modélisation des transformations est un ensemble d’étapes de la

conception permettant à un diagramme de flux de données
comportant des flux de transformations d’être converti en un type
spécifique d’architecture du logiciel.
14.6.1 EXEMPLE
Le système d’alarme « MaisonSécuritaire » est représentatif de

plusieurs systèmes informatiques utilisés actuellement.
Ce système d’alarme contrôle des événements du monde réel et

réagit aux changements de l’environnement.
Le système interagit avec un utilisateur (le propriétaire de la maison)

par l’entremise d’une série de touches et d’un clavier
alphanumérique.
Lors de l’analyse des besoins, des diagrammes de flux de donnés

seraient crées. De plus, des spécifications de contrôle, des définitions
de processus, un dictionnaire de donnés et différents modèles
comportementaux seraient également produits.
14.6.2 ÉTAPES DE CONCEPTION
ÉTAPE 1 – RÉVISION DU MODÈLE FONDAMENTAL DU SYSTÈME

ÉTAPE 2 – RÉVISION ET RAFFINEMENT DES DIAGRAMMES DE FLUX DE DONNÉES DU
LOGICIEL
ÉTAPE 3 - DÉTERMINER SI LE DIAGRAMME DE FLUX DE DONNÉES A DES CARACTÉRISTIQUES
DE FLUX DE TRANSFORMATION OU DE TRANSACTIONS
ÉTAPE 4 - ISOLER LE CENTRE DE TRANSFORMATION EN SPÉCIFIANT LES LIMITES DES FLUX
DE DONNÉES ENTRANTS OU SORTANTS
ÉTAPE 5 - FACTORISATION DU PREMIER NIVEAU
ÉTAPE 6 - FACTORISATION DU SECOND NIVEAU
ÉTAPE 7 - RAFFINEMENT DE L’ARCHITECTURE PAR DES MÉTHODE D’AMÉLIORATION DE
QUALITÉ
14.7 MODÉLISATION DES TRANSACTIONS
Dans plusieurs applications logicielles, un simple élément de

données déclenche un ou plusieurs mouvements d’information
résultant de l’activation d’un processus. Cet élément de données est
appelé une transaction.
14.7.1 EXEMPLE
La modélisation des transactions sera réalisée en étudiant le système

de l’interaction avec l’usager du système d’alarme
« MaisonSécuritaire ».
14.7.2 ÉTAPES DE CONCEPTION
ÉTAPE 1 – RÉVISION DU MODÈLE FONDAMENTAL DU SYSTÈME
Identique à la modélisation des transformations
ÉTAPE 2 – RÉVISION ET RAFFINEMENT DES DIAGRAMMES DE

FLUX DE DONNÉES DU LOGICIEL

ÉTAPE 3 - DÉTERMINER SI LE DIAGRAMME DE FLUX DE DONNÉES A DES CARACTÉRISTIQUES
DE FLUX DE TRANSFORMATION OU DE TRANSACTIONS
ÉTAPE 4 - IDENTIFICATION DU CENTRE DE TRANSACTIONS ET DES CARACTÉRISTIQUES DU
FLUX DES DONNÉES SUR CHACUN DES TRAJETS D’ACTION
ÉTAPE 5 - CONVERSION DU DFD EN UNE STRUCTURE DE PROGRAMME REPRÉSENTANT LE
TRAITEMENT DES TRANSACTIONS
ÉTAPE 6 - FACTORISATION ET RAFFINEMENT DE CHAQUE CHEMIN D’ACTION ET DE LA
STRUCTURE DES TRANSACTIONS
ÉTAPE 7 - RAFFINEMENT DE L’ARCHITECTURE PAR DES
MÉTHODE D’AMÉLIORATION DE QUALITÉ
14.8 RAFFINEMENT DE L’ARCHITECTURE DU LOGICIEL
La modélisation des transformations ou des transactions est précisée

par de la documentation additionnelle faisant obligatoirement partie
de l’architecture du système.
Après que la structure du programme ait été développée et raffinée,

les tâches suivantes doivent être complétées :
- une description écrite des traitements doit être produite pour

chaque module
- une description de l’interface doit être produite pour chaque

module
- les structures de données locales et globales doivent être

définies
- les limites et les restrictions de la conception doivent être

mentionnées
- un ensemble de révisions de la conception doit être effectué
- étapes supplémentaires de raffinement

COURS 08
Méthodes de Conception des Interfaces-usager
La conception de l’interface se concentre sur les trois domaines

suivants :
(1) conception de l’interface entre les composantes logicielles
(2) la conception des interfaces entre le logiciel et des

producteurs/consommateurs d’information qui sont des
entités (externes) non humaines
(3) la conception des interfaces entre des usagers (humains) et

l’ordinateur
Dans ce chapitre, nous allons exclusivement nous concentrer sur

la conception des interfaces entre des usagers (humains) et
l’ordinateur communément appelée : conception de l’interface-
usager ou conception de l’interface personne-machine.
La frustration et l’anxiété font partie de la vie quotidienne de

plusieurs usagers de systèmes d’information informatisés. Ces
usagers entrent dans une lutte permanente avec le système dans
le but d’exécuter des commandes ou pour trouver des items de
menus qui seraient supposés de les aider à accomplir leur travail.
Certains usagers sont victimes de phénomènes tels que : la

résistance au changement, la technophobie, la peur de l’ordinateur
et la panique des réseaux. Ces psychoses du monde moderne
font en sorte que certains individus ne veulent pas utiliser des
systèmes informatisés.
Les systèmes à base d’interfaces graphiques, les fenêtres, les icônes
et la souris ont rendus les systèmes informatiques plus faciles
d’utilisation et facilité aux usagers la compréhension des interfaces.
Même dans un environnement graphique, certains utilisateurs ont

rencontré des applications difficiles à apprendre, difficiles à utiliser,
portant à la confusion, ne pardonnant pas les erreurs ou tout
simplement frustrantes.
Il faut cependant affirmer, que dans bien des cas, le concepteur n’a
pas fait la conception de ces applications dans le but de déplaire à
l’utilisateur.
La conception de l’interface-usager doit se concentrer autant sur

l’étude des préférences des usagers que sur l’aspect technologique
de l’application.
Voici certains aspects concernant l’usager devant être pris en

considération par l’analyste :
- Qui est l’usager?
- Comment fait l’usager pour apprendre à interagir avec un

nouveau système informatique?
- Comment l’usager peut interpréter les données fournies par

le système?
Ces questions sont quelques aspects à prendre en considération lors

de la conception de l’interface-usager.
15.1 Les règles d’or de la conception des interfaces-usager
(1) Donner le contrôle à l’usager
(2) Réduire l’effort de mémorisation des commandes
(3) Rendre l’interface consistante
Ces règles d’or forment la base d’un ensemble de principes guidant

la conception des interfaces-usager.
15.1.1 Donner le contrôle à l’usager
- Définir des modes d’interaction ne faisant pas faire à

l’usager des actions inutiles ou non désirées
- Flexibilité d’interaction. Commandes entrées au clavier ou à

la souris.
- Les commandes de l’usager doivent être interruptibles ou

réversibles (annulables)
- Simplifier et automatiser les modes d’interaction en fonction

du niveau de l’usager. Utiliser des raccourcis ou des
« macros ».
- Isoler l’utilisateur du niveau et des détails techniques.
- Planifier une interaction directe avec des objets (icônes)

apparaissant à l’écran. Le modèle de l’objet représenté doit
se rapprocher de la réalité (chaîne stéréo, calculatrice).
15.1.2 Réduction de l’effort de mémorisation de commandes
pour l’usager
Plus l’usager aura à mémoriser des commandes ou des

combinaisons de touches, plus il sera susceptible de faire des erreurs
en utilisant le système. C’est pour cela qu’une interface-usager bien
conçue fera en sorte d’utiliser le moins possible la mémoire de
l’utilisateur.
Autant que possible, le système devra se souvenir de l’information

pertinente entrée par l’utilisateur et assister l’utilisateur par un mode
d’interaction fournissant de l’aide et un rappel des commandes
préalablement entrées (commande « undo »).
Les principes de conception suivant peuvent faire en sorte qu’un

utilisateur puisse utiliser une interface sans avoir à mémoriser
beaucoup de commandes :
- créer une interface réduisant l’utilisation de la mémoire à

court terme de l’utilisateur
- les commandes/la configuration par défaut doit être

significative
- définir des raccourcis (mnémoniques) significatifs.

Sauver/Enregistrer : CTRL-S
- l’aspect visuel de l’interface graphique doit être basé sur son

équivalent dans le monde réel
- fournir de l’information/de l’aide de façon progressive

15.1.3 Consistance de l’interface
L’interface devrait présenter et saisir l’information d’une façon

consistante. Ceci implique que :
(1) toute l’information visuelle est organisée en fonction des

normes de conception qui sont maintenues dans tous les
écrans
(2) Les mécanismes de saisie de données sont restreints à un

ensemble limité de processus qui sont utilisés avec
constance dans toute l’application
(3) Les modes de navigation d’une tâche à l’autre sont définis et

appliqués avec constance
Les principes suivants augmentent la consistance de l’interface :
- L’usager doit pouvoir situer la tâche dans un contexte

significatif
- Maintenir la consistance dans une famille d’applications.

Exemple : Microsoft Office.
- Si les versions précédentes ou des fonctions des interfaces-

utilisateur sont appréciées, ne pas les changer à moins de
raison majeures.
15.2 La conception des interfaces-usager
Le processus global de la conception d’une interface-usager débute

avec la création de différents modèles de fonctions du système
(pouvant être définies par des agents externes).
Les tâches accomplies par l’humain et l’ordinateur requises au

fonctionnement du système sont alors définies.
Des outils de conception sont utilisés pour produire le prototype et

finalement faire les plans de système. La qualité du produit est
ensuite évaluée.
15.2.1 Représentation conceptuelle de l’interface
Quatre modèles de conception sont utilisés dans la réalisation d’une

interface-usager :
(1) l’analyste crée un modèle de conception
(2) le concepteur des interfaces crée le modèle des usagers
(3) l’utilisateur développe une image mentale du système

appelée perception du système
(4) le développeur du système crée une image du système
- modèle de conception. Le modèle de conception d’un

système entier comprend :
o les données
o l’architecture de système
o l’interface
o les représentations procédurales du logiciel
o certaines contraintes spécifiques

- modèle des usagers. Établit le profil des usagers du système
o Novices (usagers naïfs)
o Initiés (connaissants). Sont classifiés en deux groupes :

les usagers intermittents et fréquents (« power-user »)
- perception du système. Perception/représentation mentale

qu’ont les usagers d’un système informatique.
- image du système. Combine la représentation graphique de

l’interface avec la documentation de support (livres, manuels
techniques, bandes vidéo et fichiers d’aide). Lorsque l’image
du système coïncide avec sa perception par les usagers, les
usagers sont généralement à l’aise avec le système et
l’utilisent efficacement.
Le but des modèles de conception est de permettre à l’analyste de

bien comprendre les tâches que doit effectuer l’usager sur le
système informatique.
15.2.2 Processus de conception de l’interface-usager
Le processus de conception des interfaces-usager est itératif et peut

être représenté par un modèle en spirale. Ce processus comprend
quatre activités principales :
(1) Analyse et modélisation des tâches, de l’environnement et

du profil des usagers
(2) Conception de l’interface
(3) Réalisation de l’interface
(4) Validation de l’interface
Dans la plupart des cas, la phase d’implantation nécessite du

prototypage, ce qui est pratiquement la seule façon de valider la
conception.
Le but de la conception de l’interface est de définir un ensemble
d’objets et d’actions permettant à l’usager d’accomplir toutes les
tâches définies dans l’analyse.
L’activité d’implantation débute par la création d’un prototype

permettant d’évaluer les scénarios d’utilisation.
Le processus de validation se concentre sur :
(1) la capacité de l’interface à réaliser toutes les fonctions

définies dans l’analyse
(2) la facilité d’utilisation de l’interface et la facilité de

l’apprentissage de son utilisation
(3) l’acceptation de l’interface par l’usager afin qu’il en fasse son

outil de travail
15.3 Modélisation et analyse des tâches de conception des
interfaces-usager
L’analyse des tâches appliquée à la conception des interfaces utilise

soit l’approche évolutive ou l’approche orientée objet et applique ces
approches à l’interaction entre l’usager et le système informatique.
Un système informatique interactif est souvent utilisé pour remplacer

des traitements manuels ou semi manuels.
Afin de comprendre les tâches devant être réalisées pour réaliser les
objectifs du système, le concepteur d’interfaces doit comprendre les
tâches que les utilisateurs exécutent présentement (lors des
traitements manuels) pour ensuite modéliser ces tâches en un
ensemble de tâches similaires étant implantées dans le contexte de
l’interface-usager.
Le concepteur d’interfaces peut étudier des spécifications existantes

pour une solution informatisée et formuler un ensemble de tâches
orientées sur l’usager pouvant s’appliquer au modèle de l’utilisateur,
au modèle de conception et à la perception du système par les
usagers.
Indépendamment de l’approche utilisée pour faire l’analyse des
tâches, le concepteur d’interface doit tout d’abord définir et classifier
les tâches.
- Approche évolutive (par raffinement successif)
o Identifier les fonctions majeures du système
o Identifier les tâches nécessitant une interaction avec

l’utilisateur
o Raffiner ces tâches et concevoir leur interface graphique

jusqu’à temps que le modèle de l’interface-utilisateur soit
en accord avec le modèle de l’usager et la perception du
système
- Approche orientée objet. Le concepteur d’interface observe

les objets physiques utilisés par l’usager lors des traitements
et les actions appliquées sur chaque objet. Exemple :
mouvements du « Pac-Man » ou de « Super-Mario » dans
un jeu vidéo.
15.4 Processus de conception des interfaces-usager
Une fois l’analyse des tâches complétée, toutes les tâches (ou les
objets et les actions) requises par l’utilisateur ont été identifiées en
détails et le processus de conception de l’interface débute. Les
premières étapes de la conception de l’interface peuvent être
effectuées en utilisant l’approche suivante :
(1) Établissement des buts et des spécifications de chaque

tâche
(2) Traduction des buts et des spécifications en séquences

d’actions spécifiques
(3) Spécification de la séquence d’actions de chaque tâche et

sous-tâche, appelé également scénario de l’utilisateur tel
qu’elle sera exécutée au niveau de l’interface
(4) Indication de l’état du système (vision de l’interface au temps

d’exécution du scénario de l’utilisateur)
(5) Définition des mécanismes de contrôle (objets et actions

disponibles à l’usager permettant de modifier l’état du
système)
(6) Démonstration de l’influence des mécanismes de contrôle

sur l’état du système
(7) Indiquer le degré de compréhension de l’état du système par

l’usager à partir de l’information fournie par l’interface-usager
15.4.1 Conception des entités et des fonctions de l’interface
Une étape importante dans la conception des interfaces est la

définition des objets et des actions appliquées sur ces objets.
Une description d’un scénario de l’usager est décrite. Les noms

(objets) et les verbes (actions) sont isolés pour créer une liste
d’objets et d’actions. Les objets suivants sont alors identifiés :
- Objet source : Objet qui est déplacé et posé sur un objet

cible
- Objet cible : Récepteur d’un objet source
- Objet d’application : représente un ensemble de données

spécifiques à une application qui n’est pas directement
manipulée à partir de l’interface graphique
Une fois que le concepteur d’interface a terminé la définition de tous

les objets et les actions importantes, le plan de l’interface graphique
est réalisé.
Exemple : Scénario de l’utilisateur de l’interface du système « Maison
Sécuritaire »
Le propriétaire voudrait accéder à distance au système d’alarme

« Maison Sécuritaire» installé dans sa maison. Par l’utilisation de
logiciels de communication installés sur un ordinateur à l’extérieur de
la maison (ordinateur portatif du propriétaire en voyage ou au travail),
le propriétaire voudrait :
- visualiser le statut du système d’alarme
- activer ou désactiver le système d’alarme
- reconfigurer des zones de sécurité
- visionner ce qui se passe dans les différentes pièces de la

maison en pouvant contrôler les caméras installées dans la
maison
Pour pouvoir accéder au système d’alarme à l’extérieur de la maison,

le propriétaire connecte son ordinateur portatif à une ligne
téléphonique et exécute le logiciel de communication. Pour entrer
dans le système, l’utilisateur fournit un nom d’identification et un mot
de passe. Les noms d’identification et les mots de passe définissent
les niveaux d’accès et les privilèges des utilisateurs dans le système.
Une fois le processus d’accès terminé et l’identification validée, le
super-utilisateur (ayant tous les privilèges) vérifie l’état du système et
peut modifier le statut du système en l’armant ou le désarmant. Le
super-usager peut reconfigurer le système par :
- l’affichage des plans des étages
- le contrôle de chacun des senseurs/capteurs
- la vision et la modification de la configuration des zones

L’interface graphique comporte des fenêtres représentant la vision
des caméras. L’utilisateur peut donc voir à l’intérieur de sa maison
par l’entremise des caméras. Des curseurs permettent à l’utilisateur
de faire pivoter les caméras en plus de contrôler l’agrandissement
(zoom).
Les tâches de l’utilisateur
- accéder au système « Maison Sécuritaire »
- entrer le code d’accès et le mot de passe pour accéder à

distance au système
- vérifier le statut du système
- activer ou désactiver le système
- afficher le plan des étages et la location des

capteurs/senseurs
- afficher les zones du plan des étages
- modifier les zones du plan des étages
- afficher la location des caméras vidéo sur le plan des étages
- sélectionner une caméra vidéo pour visualiser une zone

particulière
- visualiser des images vidéo
- pivoter ou focaliser (zoom) une caméra vidéo

Objets Actions
identification accéder
mot de passe traitement du code d’accès
statut du système vérification du statut du système
plan des étages activer
location des capteurs/senseurs désactiver
zones afficher
location des caméras vidéo modifier
caméra vidéo sélectionner
images vidéo visionner
pivoter
focaliser (zoom)
15.4.2 Facteurs ayant une influence sur la conception
Au cours de l’évolution de la conception du système, la considération

des quatre facteurs suivant ayant une influence sur la conception
revient fréquemment :
(1) temps de réponse du système (en retour à une action de

contrôle de l’usager). Le temps de réponse possède deux
caractéristiques :
a. longueur
b. variation
(2) système d’aide à l’usager. Il en existe deux différents types :
a. intégrée
b. non intégrée (« add-on »)
Les facteurs suivants sont à considérer lors de l’implantation

d’un système d’aide :
o disponibilité pour toutes les fonctions en tout temps
o comment l’usager va appeler la fonction d’aide
o comment les informations vont être affichées
o comment l’utilisateur va retourner au mode normal

d’utilisation
o comment l’information d’aide va être structurée

(3) traitement des erreurs. En général, les messages d’erreur
peuvent être de deux types :
a. abrégés
b. explicatifs et pouvant être reliés à un système d’aide
En général, les messages d’erreur devraient avoir les

caractéristiques suivantes :
i. compréhensibles par l’utilisateur
ii. fournir des informations permettant

d’identifier/trouver/corriger l’erreur
iii. indiquer les conséquences négatives de l’erreur

(Ex. : effacement d’un fichier)
iv. être accompagné d’un signal audible ou d’une

indication visuelle
v. ne devraient pas juger l’action de l’utilisateur

(4) formulation des commandes. Le concepteur doit décider si
une commande :
a. s’exécute seulement par une icône
b. s’exécute seulement par une saisie au clavier (textuelle)
c. peut s’exécuter par une icône et par l’entrée d’une

commande au clavier
d. Les facteurs suivants doivent être considérés lors de

l’implantation de commandes entrées au clavier
(textuelles) :
i. Est-ce que chaque commande du menu va avoir

son équivalent comme commande textuelle
ii. Quelle forme va avoir la commande
iii. Quelle sera sa difficulté d’apprentissage
iv. Est-ce que cette commande sera

adaptable/modifiable par l’usager.
15.5 Outils d’implantation
Une fois un modèle de conception crée, celui-ci est implanté sous la

forme de prototype. Ce modèle est ensuite soumis aux usagers
(clients). Le prototype est ensuite modifié selon les exigences des
utilisateurs (du client).
Afin de faciliter cette approche itérative de conception, une vaste

gamme d’outils de prototypage et de conception d’interface s’est
développée.
Appelés « Outils de développement des interfaces-usager » {User-

Interface Development Systems (UIDS)}, ces outils fournissent des
composantes ou des objets facilitant :
- la création de fenêtres,
- la création et la gestion de menus,
- l’interaction avec des périphériques,
- la gestion des messages d’erreur
- l’interprétation et l’exécution de commandes

Les outils de développement des interfaces-usager utilisent des
modules préfabriqués de composantes logicielles pouvant aider au
développement des parties suivantes des interfaces graphiques :
- gestion des périphériques d’entrée (tels que la souris et le

clavier)
- validation des données d’entrée de l’usager
- gestion des erreurs et des messages d’erreur
- fournir de la rétroaction (« feedback »)
- fournir de l’aide à l’usager
- gestion du déplacement du curseur dans les fenêtres
- personnalisation de l’interface au goût de l’usager
15.6 Évaluation et vérification de la conception
Lorsqu’un prototype opérationnel est réalisé, celui-ci doit être évalué

afin de déterminer si le prototype satisfait les besoins de l’usager.
L’évaluation peut prendre différentes formes variant d’un examen
informel à des études formelles utilisant des méthodes statistiques
pour compiler des rapports d’évaluations effectués par un groupe
d’usagers.
Les critères d’évaluation suivants permettent d’évaluer le modèle de
conception afin de réduire les itérations dans le cycle d’évaluation :
- La longueur et la complexité des spécifications écrites du

système et de ses interfaces donne une indication de l’effort
d’apprentissage à être fourni par les utilisateurs du système
- Le nombre de tâches spécifiées et le nombre moyen

d’actions par tâche fournit une indication du temps
d’interaction et de l’efficacité globale du système
- Le nombre d’actions, de tâches et d’états du système

influence directement la mémoire à court terme des usagers
- Le style de l’interface, les fonctions d’aide et les protocoles

de gestion des erreurs donnent une indication générale de la
complexité de l’interface et de sa capacité à se faire
accepter des usagers
Afin d’évaluer l’interface, nous pouvons soumettre des

questionnaires aux usagers pouvant contenir les questions
suivantes :
- Est-ce que les icônes étaient auto-explicatives? Dans le cas

négatif, quelles icônes étaient imprécises?
- Est-ce que les commandes étaient faciles à retenir et à

exécuter?
- Comment de commandes et de fonctions différentes avez-

vous utilisé?
- Est-ce que le logiciel et ses commandes/fonctions étaient

faciles d’apprentissage (Échelle de 1 à 5)?
- Sur une échelle de 100%, quelle note pourriez-vous attribuer

à ce système en rapport à vos attentes et à la satisfaction de
vos besoins?
COURS 09
Livre de Maurice Rozenberg, Test Logiciel, chapitres 2 & 12
(remplacement/équivalent à Pressman, chapitres 17, 18 &
19)
Catégories de Tests
Livre de Maurice Rozenberg, Test Logiciel, chapitres 2 (équivalent à
Pressman, chapitres 17 & 18)
Au cours du développement, le test est permanent. Aussi peut-on se

demander si tous les tests se ressemblent ou si on peut en dégager
les grandes familles applicables systématiquement à de futurs
projets. Ce chapitre présente la place du test dans le contexte
général du développement ainsi que les types les plus utilisés. Un
objectif supplémentaire de ce chapitre est de familiariser le lecteur
avec les termes techniques les plus couramment utilisés dans le
domaine du test. Nous étudierons aussi les trois catégories
principales de test, caractérisées par une couleur :
1. L'analyse du code - tests boîte blanche réalisés dans les

phases de développement et de validation de performances.
2. L'utilisation de l'application une fois terminée - tests boîte noire

effectués lors des recettes d'application.
3. Les tests boîte grise adaptés aux conversions an 2000 et euro.

Évidemment, ces trois approches se complètent. Les tests boîte
blanche seront exécutés par des informaticiens, car ils nécessitent
d'entrer dans le code de l'application, et les tests boîte noire seront
exécutés par des utilisateurs, assistés par des informaticiens si
nécessaire, puisque leur objectif est de trouver les endroits où
l'application est défectueuse et ne répond pas aux exigences. Les
tests boîte grise combinent les deux catégories précédentes lors des
tests an 2000 et euro.
Pour faciliter la compréhension des concepts exposés dans ce

chapitre, nous présentons un tableau mettant en relation les
catégories de tests par rapport aux phases de développement.
Phases de Développement
Développement Intégration Validation
Composants
Boîte blanche Tests de chemin Tests de chemin
Tests de fuite mémoire
Tests aux limites
Boîte noire Tests unitaires Tests d’intégration Tests de régression
Tests fonctionnels Tests de performance
Boîte grise Tests an 2000 Tests de régression
Tests euro
Tests boîte blanche
Les tests boite blanche consistent à créer des jeux d'essais validant
le code de l'application. On peut ainsi vérifier si :
 tous les chemins ont été parcourus au moins une fois,
 les conditions vrai/faux ont été validées,
 les boucles sont exécutées correctement,
 les valeurs limites sont correctement définies,
 les structures de données internes sont valides,
 il n'y a pas de fuite mémoire, etc.
Tests de chemin
Ces tests ont pour but de vérifier que tous les chemins prévus sont
parcourus au moins une fois pendant les tests. On définit ainsi des
graphiques de flux dans lesquels les nœuds représentent des
modules, les bordures décrivent les contrôles de flux (une bordure
doit terminer un nœud même s'il ne contient pas d'information).
On définit aussi des régions qui sont des zones fonctionnelles

bordées par des nœuds et des bordures ainsi que des nœuds à
prédicats qui contiennent une condition.
Complexité cyclomatique
On utilise pour ces graphes une métrique appelée complexité

cyclomatique qui mesure la complexité logique d'un programme.
Cette mesure définit le nombre de chemins indépendants de

l'ensemble de base et fournit une valeur maximale aux tests qui
doivent être effectués.
La complexité cyclomatique V(G) d'un graphe G est définie par les

formules suivantes:
1. G = le nombre de régions dans le graphe de flux,
2. V(G) = E - N où E est le nombre de bordures et N le nombre de

nœuds,
3. V(G) = P + 1 où P est le nombre de nœuds à prédicats.
Ensemble de base
Un chemin indépendant est un chemin passant par au moins une

bordure. Comme il existe plusieurs possibilités de passer par chaque
bordure, on calcule l'ensemble de base du programme qui
comptabilise toutes les possibilités de parcours.
Cet ensemble de base sert de balise pour les tests de type boîte
blanche.
A partir de ces formules, il est possible de définir des jeux d'essais

qui valideront les branches de l'ensemble de base.
Tests de boucles
Les tests de boucle valident les conditions d'exécution des boucles.

Quatre classes de boucles sont ainsi définies :
 boucles simples,
 boucles imbriquées,
 boucles concaténées (boucles utilisant le même compteur),
 boucles non structurées (sortie de la boucle par l'instruction

GOTO).
Les jeux d'essais mis en œuvre pour ces tests sont basés sur les
valeurs limites de la boucle.
On testera ainsi:
 le cas où la boucle n'est pas du tout exécutée,
 le cas où elle n'est exécutée qu'une seule fois,
 le cas où elle est exécutée plusieurs fois.
Tests boîte noire et de régression

Les tests boîte noire, exécutés surtout dans les phases de recette,
sont exécutés par des testeurs ayant une connaissance du métier,
aidés par des programmeurs si des outils de tests automatiques sont
utilisés.
Les tests boîte noire sont des tests fonctionnels (au sens large) mis
en œuvre dans les phases de recette. Ils ont pour objectif de
rechercher ou de valider:
 le respect des exigences,
 les fonctions incorrectes ou manquantes,
 les incohérences au niveau de l'interface,
 les erreurs d'accès aux données,
 les problèmes de performance de l'application,
 les conditions initiales ou finales d'une fonction.
On constate que ces tests s'attaquent à des problèmes de nature

différente que ceux abordés dans la phase de tests boîte blanche.
Comme on ne connaît pas le fonctionnement interne de l'application,

on doit définir un comportement supposé, et vérifier si l'application est
conforme à ce comportement. Ces tests, et les anomalies
constatées, sont donc directement liés aux spécifications.
L'intérêt principal des tests boîte noire est qu'ils valident les
fonctionnalités du logiciel plus que la qualité du développement. Ils
sont donc plus proches des préoccupations quotidiennes des
utilisateurs.
La régression
La régression joue un rôle essentiel dans les tests boîte noire -- toute
personne ayant programmé a été confrontée à ce problème car elle
fait partie de la nature même des logiciels. En voici le principe:
Supposons que vous deviez tester une application composée de sept

modules. Vous démarrez les tests et vous trouvez une anomalie dans
le module 2. Vous signalez cette anomalie au développeur qui la
corrige. Vous testez une nouvelle fois ce module, et vous continuez
vos tests. L'application vous semble correcte car vous ne détectez
pas d'anomalie; elle en contient cependant une que n'avez pas
trouvée.
En effet, la correction de l'anomalie du module 2 a créé une nouvelle

anomalie dans le module 1 car les modules 1 et 2 sont reliés par des
parties de code communes. Il y a donc eu régression dans
l'application, c'est-à-dire que l'application contient des anomalies
cachées. Le seul moyen de les détecter est de tester à nouveau
l'ensemble de l'application après chaque correction. Cela n'est
réalisable efficacement qu'en utilisant des outils de tests
automatiques.
La régression est l'un des problèmes les plus complexes à résoudre

car elle peut apparaître à tout moment, et sous des formes diverses.
Tests boîte grise

Cette catégorie de test est la combinaison des tests boîte blanche et
boîte noire. Elle s'applique particulièrement aux applications faisant
l'objet de tests an 2000 ou conversion vers l'euro.
Les tests boîte grise sont définis en deux étapes distinctes:
1. Phase d'analyse - type boîte blanche.
2. Phase de réalisation - type boîte noire.

Prenons un exemple simple lié aux tests an 2000. La conversion an
2000 s'effectue par l'analyse de chaque module de l'application, et la
conversion des dates en fonction de la méthode que l'on aura
choisie. Les tests que l'on va utiliser seront de type boîte noire,
puisqu'on va vouloir valider l'impact de la conversion sur le
fonctionnement de l'application.
Contrairement aux tests boîte noire classiques qui sont guidés par les
exigences de l'application et les types d'anomalie que l'on cherche à
débusquer, ces tests sont définis à partir des résultats de l'analyse du
code. On n'exécutera pas les mêmes tests si la date est utilisée dans
le calcul d'une prime d'ancienneté, que si elle est exploitée comme
date de dépôt d'un chèque.
Afin d'assurer efficacement les tests boîte grise, on créera un tableau

de correspondance entre les dates et les types de test à réaliser
comme le montre le tableau suivant sur un exemple de comptabilité:
TYPES DE TEST
Type 1 Type 2 Type 3
Étiquette date Module
D1 Comptabilité X X
D2 Comptabilité X X
D3 Ventes X X
D4 Achat X
D5 Suivi Commercial X X
D6 Facturation X X X
D7 Relances clients X
L'étiquette date sert à repérer les différentes dates d'un module
donné alors que les types de test définissent les tests qui seront
exécutés sur chacune de ces dates. Chaque fois qu'une date sera
affichée à l'écran, on l'identifiera par son étiquette et on lui appliquera
les types de test prévus dans la matrice de correspondance.
Tests unitaires et tests d’intégration

Les tests unitaires consistent à tester les composants individuels de
l'application. Ils seront exécutés différemment suivant le langage de
développement. Les applications écrites en C++ ou en ADA seront
basées sur les objets et les paquetages, alors que les tests écrits
dans des langages «graphiques» tels que Visual Basic, Delphi ou
Powerbuilder se référeront, en plus, aux procédures et aux fonctions.
Les tests unitaires font appel à deux concepts spécifiques: les drivers
de test et les bouchons (stub en anglais).
Un driver de test est un logiciel spécifique définissant le cadre du

test. Dans ces drivers, on définit les paramètres d'entrée, les
scénarios de test ainsi que la lecture des paramètres de sortie.
Le bouchon est un module remplaçant les modules dépendant de

l'unité qui doit être testée.
Pour mener à bien les tests unitaires, on peut choisir l'une de ces
trois approches:
1. l'approche descendante ou top/down,
2. l'approche ascendante ou bottom/up,
3. l'approche modules isolés.
Ces trois approches peuvent évidemment être combinées.
Approche descendante – top/down
L'approche top/down consiste à tester chaque unité indépendamment

de chaque unité appelante, en partant du haut de la hiérarchie.
Chaque module appelé est remplacé par un bouchon.
Pour faciliter ces tests, on dessine un diagramme hiérarchique de

l'application, et on remplace les modules inférieurs par des bouchons
(stubs) pour chacun des modules appelés, ceci afin de valider
chaque module indépendamment des modules qui en dépendent.
Les avantages de cette approche sont les suivants:
1. On effectue simultanément des tests unitaires et des tests

d'intégration.
2. On valide dès le début les fonctions les plus importantes de

l'application, car ces tests sont basés sur les besoins
fonctionnels.
3. La structure de ces tests pourra être réutilisée dans les tests de

régression.
L'inconvénient majeur de cette approche réside dans l'utilisation des
stubs. En effet, chaque modification de fonctionnalités dans un
module d'un étage inférieur devra être répercuté dans la mise au
point des stubs.
De plus, la création des stubs nécessite un travail non négligeable.
Cette approche est cependant très utile car on garde un contrôle

important sur les tests, et on reste proche des objectifs fonctionnels
de l'application, en particulier dans les tests d'intégration.
Approche ascendante – bottom/up
Les tests bottom/up sont basés sur l'approche inverse. On

commence à tester les modules élémentaires, et on remonte dans la
hiérarchie.
On utilise pour cette méthode les drivers de test, et non plus les
bouchons.
Les avantages de cette approche sont liés à l'utilisation des

fonctionnalités détaillées de l'application et à l'utilisation des résultats
des tests dans les niveaux supérieurs.
Parmi les inconvénients, on notera que:
 les modules unitaires sont souvent développés plus tard que

les niveaux supérieurs;
 le contrôle sur les tests devient plus complexe;
 les relations entre les modules peuvent devenir complexes

dans des applications graphiques ou web.
Approche modules isolés
Comme son nom l'indique, dans cette approche, le module est testé
indépendamment des autres, et on combine les deux approches
top/down et bottom/up. On remplacera ainsi chaque module appelant
par un driver de test, et chaque module appelé par un stub.
Il est ainsi facile de tester chaque module, quelle que soit la
complexité de l'application et son impact sur les autres modules. En
revanche, on perd la dynamique de l'application, et les tests
d'intégration devront être conçus et réalisés indépendamment des
tests unitaires.
Tests de performance
Les tests de performance ne seront abordés que brièvement dans cet
ouvrage. En effet, bien que leur importance soit très grande, ils font
appel à des technologies radicalement différentes, fondées sur des
technologies de paramétrage de requêtes SQL échangées entre les
postes clients et les serveurs.
Le but principal des tests de performance est de valider la capacité

qu'ont les serveurs et les réseaux à supporter des charges d'accès
importantes. On cherche surtout dans ce cas à valider la
configuration matérielle et la structure de la base de données
installée sur le serveur. Afin d'effectuer les tests de performance, on
doit vérifier que le temps de réponse obtenu par le serveur reste dans
des limites raisonnables lorsqu'un nombre important d'utilisateurs est
connecté. Pour être représentatifs des conditions d'exploitation
réelles, ces tests doivent être exécutés en deux phases. On validera
les résultats dans les conditions normales, puis on les répétera dans
des conditions extrêmes.
Volume
L'objectif est de vérifier qu'il n'y a pas de dégradation de temps de

réponse lorsqu'un volume important de données doit être traité par le
serveur.
Par exemple, on vérifiera les performances si l'application doit

imprimer toutes les fiches de paie d'une entreprise multinationale, ou
calculer des ratios statistiques dans le cadre d'un sondage national.
Le fait de gérer un nombre très important de données peut faire
apparaître des goulets d'étranglement dans les requêtes.
Stress
Ici, l'objectif est de valider le comportement de l'application dans des

conditions extrêmes d'exploitation. On vérifiera ainsi si l'application
fonctionne correctement avec une quantité de mémoire donnée, ou
bien si un débit faible du réseau local ne perturbe pas l'application.
Ces tests doivent permettre de définir un environnement matériel
minimal pour que l'application, et le serveur, puissent fonctionner
correctement.
Comme il est impossible de relier physiquement l'ensemble des

utilisateurs pour effectuer ces tests - car les machines ne sont pas
disponibles - on fait appel à une technologie de simulation
d'utilisateurs virtuels, comme décrit ci-dessous.
La solution : simuler des utilisateurs virtuels
La simulation d'utilisateurs virtuels consiste à exécuter l'application

avec un nombre important d'utilisateurs à partir d'une seule machine.
Comme ces utilisateurs ne sont pas physiquement connectés, on
simulera le trafic généré soit à la sortie du PC si on exploite les APl
avec les protocoles réseau, soit à l'entrée du serveur si on utilise des
protocoles standard.
La simulation d'utilisateurs s'exécute en deux phases distinctes:
 Enregistrement des scripts de simulation
Il consiste à faire fonctionner l'application et à enregistrer le

trafic circulant sur le réseau. Ce trafic représente les requêtes
SQL si c'est une application client/serveur, ou des trames
HTTP dans le cadre d'une application web, ou encore d'autres
protocoles comme le trafic généré par des moniteurs
transactionnels. Ce trafic est ensuite traduit dans un script
comportant les requêtes, et le temps écoulé entre ces requêtes
(think lime).
 Exécution des scénarios de simulation des utilisateurs
La machine qui a servi pour l'enregistrement devient injecteur

d'utilisateurs simulés.
Les scripts de simulation sont alors simultanément renvoyés

vers le serveur à tester. On les injecte autant de fois qu'il y a
d'utilisateurs virtuels à simuler. Il faudra veiller à éviter des
accès problématiques à la base de données (doublons) et
reproduire les think time adéquats pour chacun des profils
d'utilisateurs simulés.
On mesure les temps de réponse du serveur pour valider les

performances de la base de données applicative.
Il est nécessaire d'utiliser un environnement d'exploitation

adapté - soit Unix soit Windows NT- pour être en mesure
d'exécuter correctement ces tests.
Ordonnancement des tests
Comme nous l'avons indiqué, on teste en permanence. Les tests

démarrent, en principe, dès la fin des spécifications pour se terminer
avant le déploiement. Les catégories de test que nous venons de
présenter confirment leur grande variété et peut créer une certaine
confusion; il est donc important de résumer l'ordonnancement des
tests par rapport aux phases principales du développement.
Planification des tests
Dès que les spécifications fonctionnelles sont disponibles, on peut

commencer à planifier les tests. C'est la première tâche que les
testeurs devront accomplir.
Estimation des ressources
Dans cette phase, on essaie d'évaluer la charge totale des tests, en

fonction de tests préliminaires. L'objectif n'est pas de chercher des
anomalies, mais d'affirmer que l'application est suffisamment stable
pour être testée. Dans cette phase, on définira les types de test à
réaliser ainsi que les aspects de navigation. A la fin de cette phase,
on sera en mesure d'évaluer l'ensemble des ressources nécessaire à
la bonne conduite des tests.
Tests unitaires
Ces tests seront effectués par les développeurs sous la supervision

du chef de projet. Ils ont pour but premier la validation de la qualité
du code et les performances de chacun des modules développés.
Tests d’intégration
Ces tests seront effectués par les développeurs et les testeurs

d'intégration. Ils ont pour but premier la validation de l'intégration des
modules, d'abord entre eux puis dans leur environnement
d'exploitation définitif.
Tests système et tests fonctionnels
Cette phase correspond aux tests validant les spécifications

techniques détaillées et les exigences fonctionnelles. On utilisera des
outils de tests pour faciliter les phases de régression. On effectuera
d'abord les tests de stabilité pour vérifier les performances globales
de l'application. On pourra ainsi se prononcer sur la validité de
continuer les tests fonctionnels.
Tests d’installation
Une fois l'application validée fonctionnellement, il est nécessaire de

contrôler les aspects liés à la documentation et à l'installation.
Comme on trouve de plus en plus de documentations basées sur le
Web, l'application devra être testée à l'aide des différents navigateurs
disponibles. Le programme d'installation doit être testé intégralement
car il garantit la fiabilité dans la phase de démarrage. Les logiciels
d'installation deviennent très sophistiqués parce qu'ils gèrent des
environnements hétérogènes, ainsi que des plates-formes souvent
sécurisées. Il faudra également vérifier que les supports d'installation
ne contiennent pas de virus.
Tests de recette
Ces tests sont exécutés par une équipe dédiée représentant la

maîtrise d'ouvrage. Il s'agit de répéter les tests système et
d'installation afin de se prononcer sur la qualité du développement. Ils
sont réalisés en général par la maîtrise d'ouvrage si le
développement a été confié à une SSII.
Tests bêta
Cette phase de tests est très familière à tous les utilisateurs de

logiciels. Elle correspond à une phase où l'on considère que
l'application est suffisamment stable pour être diffusée, mais pas
assez pour être déployée à grande échelle. Il manque un retour
d'utilisateurs validant l'application dans un environnement réel
d'exploitation.
Métriques de Test
Livre de Maurice Rozenberg, Test Logiciel, chapitres 12

(remplacement de Pressman, chapitre 19)
Une métrique est un algorithme ou une formule qui sert à quantifier

un produit ou un processus. Elle produit une mesure que l'on utilisera
pour évaluer ce produit ou ce processus. Les métriques sont utiles
car elles apportent une méthode objective d'évaluation. Dans ce
chapitre, nous étudierons les métriques utilisées dans les tests et
nous proposerons quelques exemples pratiques.
Une métrique de test doit posséder les qualités suivantes:
 l’utilité,
 la simplicité,
 l'objectivité,
 la facilité de calcul,
 la robustesse.
Nous avons déjà évoqué dans les chapitres précédents quelques

métriques, comme la complexité cyclomatique. Nous nous
intéresserons ici aux métriques liées aux anomalies, car elles sont
essentielles à une conduite efficace des tests.
Unités de référence
Une des questions qui revient le plus souvent au début de la phase
d'exécution des tests concerne le temps nécessaire à cette
exécution. Nous avons vu qu'il est possible de définir un temps
moyen d'exécution basé sur les types de test.
Nous présenterons ici une autre vision de cette estimation, fondée

sur des critères liés au contenu interne de l'application. Une
interrogation supplémentaire qui revient régulièrement est liée à la
qualité de l'application que l'on teste.
Les métriques que nous allons présenter font référence à deux

éléments récurrents que l'on retrouve dans toutes les applications: le
KLOC et le WOA.
KLOC = Kilo Lines of Code
Cette unité mesure le nombre de milliers de lignes de code de

l'application. Cette unité est pertinente pour les applications de type
Cobol, C++, etc. où on effectue la majorité des développements sous
forme de code procédural.
WOA = Windows of Application
Cette unité de mesure est basée sur le nombre d'écrans - ou

d'onglets - de l'application. L'unité WOA est souvent plus pertinente
dans des environnements graphiques de type Visual Basic,
Powerbuilder ou web, car ils incluent des applets Java et des
contrôles ActiveX. Le WOA intègre également le code associé aux
éléments de l'écran.
Intéressons-nous maintenant à quelques métriques utiles à
l'exécution des tests.
MÉTRIQUES DE BASE
Métrique Unité de Description
mesure
Nombre de jeux VP/WOA Le nombre de jeux d’essais est
d’essais mesuré en fonction du nombre de
points de contrôle (Verification
Points – VP) par fenêtre (WOA).
L’expérience montre que l’on

effectue en moyenne 50PV par
écran. En fonction des ressources
humaines et matérielles, on pourra
en déduire le nombre d’heures
d’exécution des jeux d’essais
Anomalies Anomalies/KLOC La qualité globale sera mesurée en
Ou comptabilisant le nombre total
Anomalies/WOA d’anomalies détectées par rapport
au nombre de lignes de code ou de
fenêtres. On trouve en moyenne 10
anomalies par écran
Rythme de détection Anomalies/Heure On cherche ici à compter le nombre
d’anomalies détectées en fonction
du temps. Cette mesure validera la
méthode de test appliquée.
Coût de correction Heure/Anomalie Pour chaque anomalie détectée, on
indiquera le temps de correction
Ces mesures sont précieuses pour les chefs de projet et les testeurs.
Contrairement aux tests de régression qui sont exclusivement de
type boîte noire, les métriques de test font également appel aux tests
de types boîte blanche ou grise, et nécessitent d'avoir une
connaissance de l'architecture interne de l'application et des modules
mis en œuvre. Comme ces informations ne sont pas toujours
disponibles aux testeurs, ces métriques seront surtout utilisées par
les chefs de projet. Pour les étudier efficacement, référons-nous à
des concepts liés au contenu de l'application comme:
 Kloc - milliers de lignes de code,
 module -unité clairement identifiée par ses entrées-sorties,
 écran - fenêtre de l'application,
 objet - unité de base contenant des attributs et des méthodes.
Le lecteur pourra extrapoler les métriques proposées et les adapter à

son environnement particulier.
Affichage des résultats
L'affichage des résultats générés par les métriques de test se fera
sous la forme de:
1. diagrammes en pointe ou d'histogrammes détaillant chaque

paramètre,
2. diagrammes de Pareto affichant les informations par ordre

décroissant, et non par ordre chronologique, permettant ainsi
de se concentrer sur les informations les plus importantes
(règle des 80/20).
Prenons un exemple simple. Nous voulons visualiser le nombre

d'anomalies détectées durant chaque phase de test. On désire
uniquement afficher les valeurs sans prendre en compte leur degré
de sévérité ou leur priorité.
Les valeurs trouvées sont les suivantes:
PARAMÉTRAGE DES ANOMALIES PAR SÉVÉRITÉ

Phase Nombre d’anomalies
Analyse des besoins 5
Conception 4
Réalisation 6
Recette 15
Bêta 9
Voici le diagramme en pointe affichant ces données :
Le diagramme de Pareto met lui en évidence le fait que la phase la

plus importante est la phase de recette, parce que c'est celle qui
permet de découvrir le plus grand nombre d'anomalies.
Les outils de test intègrent généralement des modules d'affichage

adaptés aux métriques.
Propriétés des métriques
Afin de pouvoir étudier efficacement les métriques, nous définirons
pour chaque anomalie, les « propriétés » suivantes:
Objet/module Nature Processus Phase de Sévérité

lié à des test
l’anomalie anomalies
interface besoins de définition des unitaire majeure
graphique l’application besoins
objet métier conception conception intégration normale
middleware calcul réalisation recette mineure
base de données interface déploiement déploiement
module de code
communication
Détaillons maintenant les métriques les plus utilisées dans les tests.
Pour chacune d'elles, nous examinerons son objectif, sa formule et
son interprétation.
Métriques principales
Densité d’anomalies (DA)
Objectif: Mesurer la moyenne pondérée des anomalies par

rapport à la taille de l'application.
Paramètres: Q = Nombre total d'anomalies
S = Taille de l'application (kloc)
On pondérera les anomalies détectées par un facteur de sévérité

suivant le tableau ci-dessous:
Paramétrage des anomalies par sévérité

Sévérité Quantité Facteur de
pondération
majeure Q(j) 10
normale Q(r) 3
mineure Q(n) 1
La quantité indique le nombre d'anomalies d'une sévérité donnée.

Le facteur de pondération a pour objectif d'intégrer dans les formules
les anomalies suivant leur degré de sévérité.
Formule: DA = [[Q(j) x 10 + Q(r) x 3 + Q(n) x 1 ] / Q x (10+3+1)] / S
Interprétation: La densité d'anomalies sert principalement à comparer

le nombre d'anomalies effectivement détectées par rapport au
nombre prévisible. Elle est utile pour déterminer si on a suffisamment
testé l'application et pour établir une norme de comparaison pour les
autres mesures.
On pourra calculer la densité d'anomalies dans les différentes phases

de test pour analyser la productivité des tests.
Age des anomalies
Objectif: Mesurer le temps de correction des anomalies.
Méthode: Pour chaque anomalie, nous allons indiquer la durée de

la correction. Cette durée est mesurée en périodes
calendaires (jours, semaines, mois). Plusieurs variantes
sont possibles, comme l'âge des anomalies par priorité,
par module ou par développeur.
Formule: Pour chaque anomalie: T( correction) -T(Introduction)
Exemple:
Efficacité de la détection (EffDétect)
Objectif: Estimer le nombre d'anomalies restant dans l'application

après le test, et en déduire la productivité des tests. Cette
métrique est connue sous le sigle Defect Removal
Effectiveness (DRE) dans la littérature anglo-saxonne.
Formules: Nous allons nous intéresser à deux chiffres :
Q(test) Nombre d'anomalies détectées pendant les tests
Q(déploiement) Nombre d'anomalies détectées après les tests
Définissons les deux valeurs qui nous serviront de métriques de test:
Q(total) = Q(test) + Q(déploiement) [1]
Nombre total d'anomalies à détecter
EffDétect = Q(test) / Q(total) [2]
Coefficient d'efficacité des tests

Le nombre Q(total) est évidemment impossible à définir, mais on peut
le prédire à partir d'analyses des anomalies détectées durant chaque
phase de test. Pour cela nous allons modifier la formule [2] par la
formule suivante:
EffDétect = Q(détectées) / Q(présentes) [3]
Coefficient d'efficacité des tests (par phase)
où:
Q(détectées) = nombre d'anomalies détectées dans une phase

donnée,
Q(présentes) = nombre d'anomalies détectées dans les phases

ultérieures, mais déjà présentes - et non détectées -
dans la phase donnée.
Pour effectuer ce calcul, nous allons créer un tableau contenant le

nombre d'anomalies détectées durant chaque phase de test, en ne
tenant pas compte des anomalies de régression. Nous supposerons
aussi que les tests sont effectués en parallèle avec le
développement.
RÉPARTITION DES ÂGES DES ANOMALIES

Phase Nombre d’anomalies EffDétect
détectées
Analyse des besoins 5 5 / (5 + 4 + 6 + 15 + 9) = 0.12
Conception 4 4 / (4 + 6 + 15 + 9) = 0.11
Réalisation 6 6 / (6 + 15 + 9) = 0.2
Recette 15 15 / (15 + 9) = 0.62
Bêta 9
Interprétation: Le coefficient d'efficacité de la détection des anomalies

est un outil très utile pour mesurer la productivité des tests et pour
essayer d'estimer le nombre d'anomalies restant dans l'application
après le déploiement.
Si on a accès à des statistiques sur des projets antérieurs, il est
possible d'utiliser, par comparaison, les coefficients d'efficacité de
ces autres projets pour estimer le nombre d'anomalies restantes.
IBM a effectué des études poussées sur l'usage des coefficients

d'efficacité de détection d'anomalies. D'après IBM, la valeur la plus
courante dans les applications est de 65 à 70 %. Il est donc utile de
calculer ce coefficient à chaque étape des tests et de vérifier si on
atteint au moins la valeur de 60 %. Si les valeurs obtenues sont trop
basses, on ne teste pas correctement.
Nombre d’anomalies par écran
Comme les tests ne sont pas une science exacte, on peut définir des
métriques heuristiques liées à l'expérience et au bon sens. Bien
qu'elles ne soient pas supportées par des formules mathématiques,
elles seront très utiles pour les chefs de projets car elles reflètent la
réalité quotidienne du développement des applications à base
d'interfaces graphiques et web.
La métrique la plus courante est liée au nombre d'anomalies par

écran. On constate en effet que le nombre d'anomalies détectées,
toutes phases confondues, est linéairement proportionnel au nombre
d'écrans de l'application. Ceci est plus visible sur des applications
importantes, car les statistiques sont plus faciles à effectuer.
Le chiffre le plus courant pour une application client-serveur avec un

poste client Windows est de dix anomalies par écran. Il ne s'agit pas
de dix anomalies sur chaque écran, mais du résultat de la division du
nombre total d'anomalies par le nombre total d'écrans de
l'application. Cette valeur est utile car elle permet d'estimer le nombre
d'anomalies total de l'application et de prédire le temps de test
restant. Ce nombre diminuera fortement lors des tests de régression.
Les métriques de test sont très utiles car elles permettent de

quantifier l'activité, et de prédire le nombre d'anomalies à détecter.
Elles doivent être tenues en jour en permanence, et les outils de test
contribuent efficacement à leur exploitation.
COURS 10
Ingénierie du logiciel basée sur les composantes
Pressman, chapitre 27
Dans le contexte de l’ingénierie du logiciel, la réutilisation est un

concept à la fois ancien et nouveau. Les programmeurs ont réutilisé
des idées, des abstractions et des processus depuis les débuts de
l’ère de l’informatique, mais les premières approches de la
réutilisation relevaient de l’improvisation.
Maintenant, des systèmes informatiques complexes et de haute

qualité doivent être développés sur des courts intervalles de temps.
Ceci fait en sorte que les développeurs de logiciels ont tendance à
utiliser une approche plus organisée de la réutilisation des
composantes logicielles.
L’ingénierie du logiciel basée sur les composantes [Component-

Based Software Engineering (CBSE)] est un processus qui se
concentre sur la conception et la construction de systèmes
informatiques utilisant des composantes logicielles réutilisables.
Clements décrit l’ingénierie du logiciel basée sur les composantes de
la façon suivante :
« L’ingénierie du logiciel basée sur les composantes est en

train de changer la façon dont les systèmes informatiques
complexes sont développés. Cette discipline suit le courant
philosophique « Acheter et ne pas développer » adopté par
Fred Brooks et d’autres spécialistes de cette discipline.
De la même façon que l’introduction du concept des sous-

routines a libéré les programmeurs à penser aux détails de la
programmation, l’ingénierie du logiciel basée sur les
composantes change la problématique de la programmation du
logiciel à la composition du logiciel.
L’implantation a donc cédé la place à l’intégration des systèmes

comme activité principale du développement des systèmes.
L’intégration des systèmes trouve son fondement en prenant
pour acquis qu’il y a suffisamment de similitudes dans plusieurs
gros systèmes informatiques pouvant justifier le développement
de composantes informatiques réutilisables tirant profit et
satisfaisant ces similitudes. »
Un nombre de questions sont maintenant soulevées vis-à-vis cette
problématique :
 Est-il possible de développer des systèmes informatiques

complexes par l’assemblage de composantes logicielles
réutilisables provenant d’un catalogue?
 Est-ce que cette nouvelle méthode du développement de

logiciels peut-être accomplie d’une façon pouvant optimiser les
coûts et le temps de développement?
 Est-ce que des mesures administratives seront prises afin

d’inciter les analystes à réutiliser plutôt que de réinventer?
 Est-ce que les gestionnaires sont prêts à défrayer les coûts

additionnels engendrés par la création de composantes
logicielles réutilisables?
 Est-ce que les librairies de composantes nécessaires à la

réutilisation seront développées pour être accessibles aux
développeurs qui en auront besoin?
 Est-ce que les librairies de composantes existantes sont

accessibles aux développeurs qui en auront besoin?
Ces questions ainsi que plusieurs autres sont à la base du domaine

de recherche d’une communauté de scientifiques et de
professionnels de l’industrie concentrant leurs efforts à faire de la
réutilisation des composantes logicielles un aspect principal de
l’ingénierie du logiciel.
27.1 INGÉNIERIE DES SYSTÈMES À BASE DE COMPOSANTES
À première vue, l’ingénierie du logiciel basée sur les composantes

semble similaire à l’approche conventionnelle ou l’approche orientée
objet. Le processus débute lorsque qu’une équipe de développement
du logiciel définit les besoins du système à développer en utilisant les
techniques conventionnelles d’énumération des spécifications.
Une architecture de système est alors définie, mais au lieu de passer

immédiatement aux étapes subséquentes de la conception, l’équipe
de développement étudie les spécifications afin de déterminer
quelles parties du système peuvent être constituées de composantes
réutilisables au lieu d’être développées.
L’équipe de développement doit envisager les aspects suivants pour

chaque composante du système :
 Est-ce que des composantes commerciales préfabriquées

[commercial off-the-shelf (COTS)] sont disponible afin
d’implanter certaines parties du système?
 Est-ce que des composantes réutilisables développées à

l’interne sont disponible afin d’implanter certaines parties du
système?
 Est-ce que les interfaces des composantes disponibles sont

compatibles avec l’architecture du système à construire?
L’équipe de développement essaie de modifier ou d’enlever les

composantes du système à construire ne pouvant pas être
implantées avec des composantes préfabriquées.
Si les spécifications ou les composantes logicielles ne peuvent être

changées ou détruites, les méthodes de développement
conventionnelles ou les méthodes de développement orientées objet
sont appliquées à ces nouvelles composantes afin qu’elles
satisfassent les spécifications.
Pour les parties du système pouvant être développées à partir de
composantes logicielles disponibles, une suite différente d’activités
du génie logiciel débute :
 Qualification des composantes logicielles
 Adaptation des composantes logicielles
 Composition des composantes logicielles
 Mise à jour des composantes logicielles
Le terme « composante » peut être défini de différente façons :
 Composante : partie non triviale, approximativement

indépendante et remplaçable d’un système ayant une fonction
précise dans le contexte d’une architecture bien définie
 Librairie : un ensemble dynamique de un ou plusieurs

programmes identifié comme un module unitaire et accédé par
des interfaces lors de l’exécution
 Composante logicielle : un ensemble unitaire ou une

composition de programmes ayant seulement des
dépendances explicites spécifiées
 Composante d’affaires : l’implantation logicielle d’un

concept ou d’un processus d’affaires autonome
27.2 LE PROCESSUS DE L’INGÉNIERIE DU LOGICIEL À BASE
DE COMPOSANTES
Le modèle des traitements pour l’ingénierie du logiciel basée sur les

composantes est effectué en parallèle avec l’ingénierie du domaine.
L’ingénierie du domaine effectue les tâches requises afin d’établir un

ensemble de composantes logicielles pouvant être réutilisées par les
analystes.
Ces composantes logicielles traversent alors une frontière séparant

l’ingénierie du domaine et du développement des systèmes basés
sur les composantes.
27.3 INGÉNIERIE DU DOMAINE
Le but de l’ingénierie du domaine est d’identifier, construire,

cataloguer et disséminer un ensemble de composantes logicielles
pouvant êtres incluses dans les logiciels des applications existantes
et futures dans un domaine particulier d’application.
Le but final est l’établissement de mécanismes permettant aux

analystes de partager ces composantes logicielles afin de pouvoir les
réutiliser lors de la conception de nouveaux systèmes ou de
systèmes existants.
L’ingénierie du domaine comprend trois activités principales :
1) L’analyse
2) La construction
3) La dissémination
27.3.1 LE PROCESSUS D’ANALYSE DU DOMAINE
Étapes du processus d’analyse du domaine dans le contexte de

l’analyse orientée-objet :
1) Définition du domaine à analyser
2) Classification des items extraits du domaine
3) Constituer un exemple représentatif d’application du domaine
4) Analyser chaque application de l’exemple
5) Développer un modèle d’analyse pour les objets
Il est important de noter que l’analyse du domaine est applicable à

n’importe quel paradigme du génie logiciel et peut être appliquée
pour le développement conventionnel de logiciels ou dans le cas du
développement d’applications orientées-objet.
Prieto-Diaz développe la seconde étape du processus d’analyse et
suggère une approche en huit étapes à l’identification et à la
catégorisation des composantes réutilisables :
1) Sélectionner des fonctions ou des objets spécifiques
2) Modéliser un type abstrait de ces fonctions ou objets
3) Définir une taxonomie de ces fonctions ou de ces objets
4) Identifier les caractéristiques communes de ces fonctions ou de

ces objets
5) Identifier des relations spécifiques entre des fonctions ou ces

objets
6) Modéliser un type abstrait de ces relations
7) Dériver un modèle fonctionnel
8) Définir un langage du domaine
Un langage du domaine permet la spécification et la construction

future d’applications à l’intérieur du domaine.
Bien que les étapes énumérées fournissent un modèle utile pour
l’analyse du domaine, ils ne fournissent aucune indication aidant à la
sélection des composantes logicielles candidates à la réutilisation.
Hutchinson et Hindley suggèrent la série suivante de questions

pragmatiques comme guide à la détermination des composantes
logicielles réutilisables :
 Est-ce que la fonctionnalité des composantes logicielle est

requise pour des implantations futures?
 Quelles sont les fréquences des fonctions des composantes à
l’intérieur du domaine?
 Est-ce que les fonctions des composantes sont dupliquées à
l’intérieur du domaine?
 Est-ce que les composantes logicielles sont dépendantes du
matériel?
 Est-ce que le matériel reste inchangé entre les implantations
logicielles?
 Est-ce que les caractéristiques du matériel peuvent être
appliquées à une autre composante logicielle?
 Est-ce que les plans de système sont assez optimisés pour
supporter la prochaine implantation?
 Pouvons-nous paramétrer une composante logicielle non
réutilisable afin qu’elle devienne réutilisable?
 Est-ce que la composante logicielle est réutilisable dans
plusieurs implantations avec seulement des changements
mineurs?
 Est-ce que la réutilisation par la modification est faisable?
 Est-ce qu’une composante non réutilisable peut être
décomposée afin de créer des composantes réutilisables?
 Quelle est la validité de la décomposition des composantes
logicielles en vue de la réutilisation?
27.3.2 FONCTIONS DE CATACTÉRISATION
Il est parfois difficile de déterminer si une composante logicielle

potentiellement réutilisable est en fait applicable dans une situation
particulière. Afin de prendre une décision, il est nécessaire de définir
un ensemble de caractéristiques du domaine étant partagé par tout le
logiciel composant le domaine.
Une caractéristique du domaine définit des attributs génériques à

tous les produits logiciels qui existent à l’intérieur du domaine. Nous
pouvons donner comme exemples les caractéristiques génériques
suivantes :
 Importance de la sécurité des systèmes
 Importance de la fiabilité des systèmes
 Langages de programmation
 Traitements concurrents
Un ensemble de caractéristiques du domaine pour les composantes
logicielles réutilisables peut être représenté comme étant {Dp}, où
chaque item, Dpi, de l’ensemble représente une caractéristique du
domaine spécifique. La valeur attribuée à Dpi représente une échelle
ordinale qui est une indication de la pertinence de la caractéristique
pour la composante p. Une échelle typique pourrait être :
1. non significatif quant à ce que la réutilisation soit appropriée

2. significatif seulement dans le cas de circonstances
exceptionnelles
3. significatif – la composante peut être modifiée pour être utilisée,
malgré les différences
4. très significatif, et si le nouveau logiciel ne possède pas cette
caractéristique, la réutilisation sera inefficace mais possible
5. très significatif, et si le nouveau logiciel ne possède pas cette
caractéristique, la réutilisation sera inefficace et non
recommandée
Le tableau 27.1 énumère des types de caractéristiques du domaine

ayant un impact sur la réutilisation du logiciel. Ces caractéristiques du
domaine doivent êtres prises en considération afin de réutiliser
efficacement les composantes logicielles
TABLEAU 27.1 – Caractéristiques du domaine affectant la réutilisation

Produit Processus Personnel
Stabilité des besoins Plans de système Motivation
Logiciels des concurrents Conformisme Éducation
Contraintes de mémoire Environnement Expérience/Connaissances
Grosseur de l’application Contraintes  Domaine
d’horaire d’application
Complexité de l’interface- Contraintes de  Processus
usager budget  Plateforme
Langages de programmation Productivité  Langage
Sécurité/fiabilité
Exigences de la durée de vie Équipe de développement
Qualité du produit Productivité
Fiabilité du produit
27.3.3 MODÉLISATION STRUCTURELLE ET POINTS DE
STRUCTURE
Lorsque l’analyse du domaine est effectuée, l’analyste recherche des

modèles se répétant dans les applications résidant à l’intérieur d’un
domaine donné.
La modélisation structurelle est une approche basée sur les modèles

de l’ingénierie reposant sur le principe que chaque application du
domaine possède des modèles (patrons) répétitifs (de fonctions, de
données et de comportements) pouvant avoir un potentiel de
réutilisation.
Pollack et Rissamn décrivent les modèles structuraux de la façon

suivante :
Les modèles structuraux consistent en un petit nombre d’éléments

structuraux démontrant des structures d’interaction définies. Les
architectures des systèmes utilisant des modèles structuraux sont
caractérisées par de multiples ensembles étant composés par les
éléments du modèle. Plusieurs unités architecturales émergent de
simples modèles d’interaction entre ce petit nombre d’éléments.
McMahon décrit un point de structure comme étant « une

construction distincte à l’intérieur d’un modèle structurel ». Les points
de structure ont trois caractéristiques distinctes :
1. Un point de structure est une abstraction devant avoir un

nombre limité d’instances
2. Les règles dirigeant l’utilisation des points de structure
devraient être faciles à comprendre. De plus, l’interface des
points de structure devrait être relativement simple
3. Les points de structure devraient implanter les types abstraits
par l’isolation de toute la complexité définissant le point de
structure. Ceci réduit la complexité perçue du système en
général.
27.4 DÉVELOPPEMENT BASÉ SUR LES COMPOSANTES
Le développement basé sur les composantes est une activité de

l’ingénierie du logiciel basée sur les composantes se produisant en
parallèle avec l’ingénierie du domaine. En utilisant les méthodes
d’analyse et de conception d’architecture du logiciel, l’équipe de
développement du logiciel définit un style architectural étant
approprié au modèle d’analyse crée pour l’application en
développement.
Une fois l’architecture du logiciel définie, le logiciel doit être composé

de modules:
1) Provenant de librairies de composantes réutilisables et/ou
2) Fabriqués pour satisfaire des besoins particuliers

Le flux des tâches pour le développement basé sur les composantes
suit deux chemins parallèles. Lorsque l’emploi des composantes
réutilisables est envisagé dans le but d’intégrations potentielles dans
une architecture, elles doivent être choisies (se qualifier) et être
adaptées pour une éventuelle inclusion dans l’architecture du logiciel.
Lorsque de nouvelles composantes sont requises, elles doivent être

soumises au processus de conception. Les composantes résultantes
doivent être intégrées dans le modèle d’architecture et vérifiées
intégralement.
27.4.1 QUALIFICATION, ADAPTATION ET COMPOSITION

DES COMPOSANTES
L’ingénierie du domaine fournit une librairie de composante

réutilisable requise pour le processus d’ingénierie du logiciel basé sur
les composantes. Quelques unes de ces composantes réutilisables
sont développées à l’intérieur de l’entreprise tandis que les autres
peuvent provenir d’applications existantes ou d’autres organismes.
Malheureusement, l’existence de composantes réutilisables ne

garantit pas que ces composantes soient intégrées facilement ou
efficacement dans l’architecture choisie pour une nouvelle
application. C’est pour cette raison qu’une séquence d’activités de
développement basé sur les composantes est effectuée lorsqu’une
composante est proposée pour être intégrée au logiciel.
Ces activités sont :
 Qualification de la composante :
o s’assurer qu’une composante à l’étude va effectuer les
fonctions requises
o vérifier que la composante va bien s’intégrer au style
d’architecture spécifié pour le système
o vérifier que la composante va satisfaire les exigences de
qualité requises pour l’application (performance, fiabilité,
facilité d’utilisation)
 Adaptation de la composante
Dans le cas idéal, l’ingénierie du domaine génère des librairies

de composantes pouvant être facilement intégrées dans
l’architecture de l’application.
La facilité de l’intégration se définit comme étant :
(1) des méthodes consistantes de gestion des ressources

ayant été implantées pour toutes les composantes de
la librairie
(2) des activités communes telles que la gestion des
données existent pour toutes les composantes
(3) les interfaces régissant les éléments internes de
l’architecture et les interfaces communiquant avec
l’environnement externe ont été implantées d’une
manière consistante
 Réalisation/composition de la composante
Les tâches de réalisation (développement/composition) des

composantes logicielles consistent en l’assemblage de
composantes qualifiées, développées et adaptées qui
s’intègrent dans l’architecture de l’application.
Afin d’accomplir ces tâches, une infrastructure doit être établie

afin de relier ces composantes en un système opérationnel.
27.4.2 INGÉNIERIE DES COMPOSANTES
Le processus d’ingénierie du logiciel basée sur les composantes

favorise l’utilisation de composantes logicielles existantes.
Cependant, dans certains cas, les composantes logicielles doivent
être développées.
Dans ce cas, les nouvelles composantes logicielles doivent être

intégrées avec des composantes commerciales préfabriquées et
d’autres composantes développées par les services informatiques de
l’organisation.
Les nouvelles composantes devenant membre de la librairie des

composantes réutilisable de l’organisation, ces composantes
devraient être développées pour être réutilisables.
27.4.3 ANALYSE ET CONCEPTION POUR LA RÉUTILISATION
Des modèles des données, des modèles fonctionnels et des modèles

comportementaux peuvent être crées afin de définir ce qu’une
application particulière pourrait accomplir. Des spécifications écrites
sont alors utilisées pour décrire ces modèles. Une description
complète des spécifications en est le résultat.
Idéalement, le modèle d’analyse est étudié afin de déterminer les

éléments du modèle pouvant être implantés à l’aide de composantes
réutilisables. La problématique constitue en un processus d’extraction
de l’information des modèles d’analyse afin d’identifier les
spécifications pouvant être implantées par des composantes
réutilisables. Des outils informatisés peuvent être utilisés pour aider
les analystes dans l’accomplissement de ces tâches.
Si une concordance dans les spécifications permet l’utilisation de

composantes réutilisables, l’analyste peut trouver ces composantes
dans une librairie de composantes réutilisables et les utiliser au
développement de nouveaux systèmes.
Si l’analyste ne peut pas trouver de composantes réutilisables pour

implanter une certaine fonction/spécification, il devra appliquer les
méthodes de développement de systèmes conventionnelles afin de
développer ces fonctions/spécifications.
Lors du développement de ces fonctions/spécifications, l’analyste

devra appliquer les techniques de conception pour la réutilisation
[Design for reuse (DFR)]. Ces techniques exigent de l’analyste
d’appliquer des principes et des concepts spécifiques de
développement des systèmes se basant sur les principes suivants :
 Utilisation de structures de données standardisées
 Protocoles de conception d’interfaces standardisés
 Gabarits/structures de programmes (program templates)

27.5 CLASSIFICATION ET ACCÈS AUX COMPOSANTES
Considérons maintenant une volumineuse librairie de composantes

réutilisables pouvant contenir des dizaines de milliers d’items. Il faut
donc trouver des méthodes permettant à l’analyste de pouvoir
accéder aux composantes dont il a de besoin afin de développer des
logiciels.
Il faut donc trouver un moyen de classifier les composantes

réutilisables en termes précis et classifiables.
27.5.1 DESCRIPTION DES COMPOSANTES RÉUTILISABLES
Les composantes logicielles réutilisables peuvent être décrites de

plusieurs façons, mais une description idéale est donnée par le
« modèle des 3C » - concept, contenu et contexte :
 Concept : Le concept d’une composante logicielle est défini

comme étant la description de ses fonctions. L’interface de la
composante est définie ainsi que la sémantique de ses pré-
conditions et post-conditions.
 Contenu : Description de son type abstrait : code, langage de

programmation, paramètres d’entrée-sortie. Cette information
n’est pas transparente aux usagers et est accessible aux
programmeurs et aux analystes.
 Contexte : Le contexte place une composante logicielle

réutilisable dans son domaine d’application par la spécification
de ses caractéristiques conceptuelles, opérationnelles et
d’implantation.
La figure suivante présente une taxonomie des méthodes
d’indexation des sujets scientifiques en usage dans les bibliothèques
La majorité des méthodes de classification des composantes
logicielles réutilisables divisent les classifications en trois catégories :
1) Classification énumérée : Les composantes sont décrites

par une structure hiérarchique dans laquelle des niveaux de
classes et de sous-classes sont définies.
La figure suivante décrit une hiérarchie de classes pour des

opérations de manipulation de fenêtres.
2) Classification par facettes : Un champ du domaine est analysé
et un ensemble de caractéristiques descriptives est déterminé.
Ces caractéristiques appelées facettes, sont classées par
importance et attribuées aux composantes logicielles
réutilisables.
Une facette peut décrire la fonction accomplie et les données

traitées par la composante, le contexte d’application ou tout
autre caractéristique. L’ensemble des facettes décrivant une
composante logicielle est appelé le descripteur de facettes.
Généralement, la description par facettes est limitée à sept ou

huit facettes.
3) Classification par attribut-valeur : Un ensemble d’attributs est

défini pour toutes les composantes logicielles réutilisables d’un
domaine défini.
27.5.2 L’ENVIRONNEMENT DE RÉUTILISATION
La réutilisation des composantes logicielles doit être supportée par

un environnement fournissant les éléments suivants :
 Une base de données pouvant entreposer les composantes

logicielles et les informations nécessaires à leur localisation
 Un système de gestion de librairies fournissant un accès à la
base de données
 Un système de requêtes permettant à une application-client
d’accéder aux composantes et aux services de la librairie de
composantes réutilisables
 Des outils de l’ingénierie du logiciel basée sur les composantes
supportant l’intégration des composantes réutilisables en une
nouvelle conception ou implantation
27.6 ASPECTS ÉCONOMIQUES DE L’INGÉNIERIE DU LOGICIEL
À BASE DE COMPOSANTES
En théorie, le développement de logiciels à base de composantes

devrait faire profiter les services informatiques d’une organisation
d’une augmentation de la qualité et de la durée de vie du logiciel. Ce
qui devrait résulter en une économie de budget.
27.6.1 IMPACT SUR LA QUALITÉ, LA PRODUCTIVITÉ ET LES

COÛTS
Plusieurs analyses indiquent que des profits peuvent être générés

par des stratégies agressives de réutilisation des composantes
logicielles.
La qualité du produit, la productivité du développement des logiciels

et l’économie de budget sont grandement améliorés de la façon
suivante :
 Qualité : Idéalement, une composante logicielle développée

dans le but de la réutilisation sera vérifiée pour qu’elle soit sans
erreurs et qu’elle ne contienne pas de défauts. En réalité, des
vérifications formelles ne sont pas effectuées fréquemment et
des erreurs peuvent se produire. Cependant, à chaque
réutilisation, des défauts sont trouvés et éliminés, ce qui
augmente la qualité du logiciel pour qu’éventuellement il
devienne sans défauts.
 Productivité : Lorsque l’utilisation des composantes
logicielles réutilisables est appliquée tout au long du processus
de développement du logiciel, moins de temps est consacré au
développement des plans de système, des modèles, des
documents, du code et des données nécessaires à l’élaboration
d’un système informatique livrable. Une augmentation de la
productivité provient du fait que les mêmes fonctionnalités des
systèmes sont livrées aux clients avec moins d’efforts de
développement. Dans certains cas, une variation du taux de
réutilisation des composantes de 30% à 50% peut augmenter la
productivité de 25% à 40%.
 Coûts : Le bénéfice net de la réutilisation des composantes

logicielles est estimé par la projection du coût de projet si
développé sans réutilisation de composantes logicielles (Cs) et
ensuite en soustrayant la somme des coûts associés à la
réutilisation des composantes logicielles (Cr) et le coût actuel
du logiciel lors de sa livraison (Cd).
Bénefice Net = Cs – (Cr + Cd)

COURS 11
Ré-ingénierie et rétro-ingénierie du logiciel
Pressman, chapitre 30
Michael Hammer établit les fondations d’une révolution dans l’aspect

théorique de l’informatisation et de la gestion des processus
d’affaires :
[Il est temps d’arrêter de paver les ruelles. Au lieu d’intégrer les
processus devenus désuets dans le matériel et le logiciel, nous
devrions les mettre de côté et repartir à neuf.
Nous devrions « ré-ingénier » nos processus d’affaires : utiliser

les possibilités des technologies de l’information modernes pour
redéfinir nos processus d’affaires afin de réaliser des
améliorations significatives dans leurs performances.
Les opérations de plusieurs compagnies se déroulent selon

plusieurs règles désarticulées… Les processus de ré-ingénierie
tentent de s’éloigner des vieux principes de la gestion dictant
les façons d’organiser et d’exécuter les processus d’affaires]
Comme toutes les révolutions, la théorie de Hammer a résulté en des

changements positifs et négatifs.
Durant les années 1990, certaines compagnies ont fait des efforts
légitimes de ré-ingénierie et les résultats ont augmenté la
compétitivité de ces entreprises.
D’autres entreprises ont axé leur stratégie sur la réduction de
personnel et l’engagement de contractuels (au lieu de la ré-
ingénierie) afin de renforcir leur structure. Les résultats de ces
réorganisations ont souvent été la création d’organisations
puissantes avec un potentiel limité de croissance future.
Durant cette première décade du 21è Siècle, l’intérêt initial accordé à

la ré-ingénierie a diminué, mais ce processus est toujours en action
dans les petites et grandes organisations.
La différence entre la ré-ingénierie des processus d’affaires et

l’ingénierie du logiciel réside en une vue de système.
Le développement du logiciel est souvent la réalisation des

processus d’affaires critiquée par Hammer. Lorsque ces règles
changent, le logiciel doit également changer.
Aujourd’hui, les organisations importantes ont des milliers de

programmes informatiques supportant les anciens processus
d’affaires. Au fur et à mesure que les gestionnaires travaillent à
actualiser ces processus d’affaires pour obtenir une plus grande
efficience et une meilleure compétitivité, les logiciels devront
également s’adapter à ces changements. Dans certains cas, ceci
entraînera la création de nouveaux systèmes informatiques.
Autrement, ceci occasionnera la modification ou la reconstruction
d’applications existantes.
30.1 RÉ-INGÉNIERIE DES PROCESSUS D’AFFAIRES
Les limites du domaine de la ré-ingénierie des processus d’affaires

[Business process reengineering (BPR)] s’étendent beaucoup plus
loin que celles des technologies de l’information et de l’ingénierie du
logiciel.
Parmi les multiples définitions ayant été suggérées pour la ré-

ingénierie des processus d’affaires, une que nous trouvons très
pertinente a été publiée dans le magazine Fortune :
« la recherche et l’implantation de changements radicaux dans

les processus de gestion afin de réaliser des améliorations
significatives »
Le fait de considérer la discipline de la ré-ingénierie des processus

d’affaires nous amène la problématique suivante :
 Comment la recherche est effectuée?
 Comment l’implantation est réalisée?
 Comment les gestionnaires de l’entreprise peuvent prouver que

les changements radicaux suggérés par les services des
technologies de l’information vont résulter en des améliorations
radicales au lieu d’un désordre organisationnel?
30.1.1 LE PROCESSUS D’AFFAIRES
Un processus d’affaires est un ensemble de tâches logiquement

reliées, effectuées afin de réaliser une fonction particulière de la
gestion.
À l’intérieur du processus de gestion, le personnel, l’équipement, les

ressources matérielles et les procédures administratives sont
combinées afin de produire un résultat spécifique.
Des exemples de processus de gestion peuvent comprendre :
 La conception d’un nouveau produit
 L’achat de services et d’équipements
 L’engagement d’un nouvel employé
 Le paiement des fournisseurs
Chaque processus de gestion exige l’accomplissement d’une série

de tâches et consomme diverses ressources de l’entreprise.
Chaque processus de gestion a un client défini (une personne ou un

groupe) recevant le produit fini :
 Une idée
 Un rapport
 Des plans de systèmes
 Un produit
De plus, les processus de gestion s’étendent au-delà des frontières

organisationnelles. La réalisation des processus de gestion nécessite
que des équipes de travail provenant d’organisations différentes
accomplissent des tâches logiquement reliées.
Chaque système est une hiérarchie de sous-systèmes. Une
entreprise ne fait pas exception à cette règle. Les entreprises sont en
général segmentées de la façon suivante :
Entreprise
Systèmes de
gestion
Processus de
gestion
Sous-processus
de gestion
Chaque système de gestion (également appelé fonction de gestion)

est composé de un ou plusieurs processus de gestion qui sont à leur
tour constitués de sous-processus de gestion.
La ré-ingénierie des processus d’affaires peut être effectuée à

n’importe quel niveau de la gestion. Plus l’ampleur du processus
augmente par l’étude des niveaux élevés de gestion, plus les risques
associés à la ré-ingénierie des processus d’affaires augmentent.
C’est pour cela que la ré-ingénierie des processus d’affaires

s’applique à des processus isolés ou des sous-processus.
30.1.2 PRINCIPES DE RÉ-INGÉNIERIE DES PROCESSUS
D’AFFAIRES
La ré-ingénierie des processus d’affaires possède le même domaine

et la même vision que l’ingénierie des processus de gestion. Dans un
cadre idéal, la ré-ingénierie des processus d’affaires devrait
s’accomplir d’une façon descendante selon l’approche « top-down »,
en commençant l’identification des buts et des processus majeurs de
la gestion et en finissant par des spécifications détaillées des tâches
et des processus définissant un processus de gestion spécifique.
Hammer suggère un nombre de principes guidant les activités de la
ré-ingénierie des processus d’affaires lorsque ce processus débute
au plus haut niveau :
 Organiser les activités de développement dans le but de

réaliser les objectifs de gestion et non les tâches
 Laisser à ceux qui utilisent les sorties d’un processus

l’exécution de ce processus
 Inclure le processus de traitement des données informatisées

dans le processus de traitement des données brutes
 Considérer des ressources dispersées géographiquement

comme si elles étaient centralisées
 Lier les activités de développement parallèles plutôt que

d’intégrer leurs résultats
 Placer les processus de décision où les traitements sont

accomplis et établir des structures de contrôle du processus
 Effectuer la saisie des données seulement qu’une fois et à la

source
Chacun de ces principes constitue une vision globale de la ré-

ingénierie des processus d’affaires. En utilisant ces principes comme
lignes directrices, les gestionnaires et les analystes peuvent débuter
la ré-ingénierie des processus.
30.1.3 UN MODÈLE DE RÉ-INGÉNIERIE DES PROCESSUS
D’AFFAIRES
Comme la plupart des activités de l’ingénierie, la ré-ingénierie des

processus d’affaires est itérative. Les objectifs de gestion et les
processus les réalisant doivent être adaptés aux environnements
changeants du monde des affaires. Pour cette raison, il n’y a pas de
début ni de fin à la ré-ingénierie des processus d’affaires parce que
ce processus est évolutif. Un modèle de la ré-ingénierie des
processus d’affaires est décrit à la figure suivante. Ce modèle
comprend six activités :
 DÉFINITION DU DOMAINE D’AFFAIRES

 IDENTIFICATION DES PROCESSUS
 ÉVALUATION DES PROCESSUS
 SPÉCIFICATION ET CONCEPTION DES PROCESSUS
 PROTOTYPAGE
 RAFFINEMENT ET INSTANCIATION
Ces activités de la ré-ingénierie des processus d’affaires sont
effectuées à l’aide d’outils d’analyse de l’ordonnancement des
tâches. Le but de l’utilisation de ces outils est de construire un
modèle des traitements existants afin de mieux les analyser.
De plus, les techniques de modélisation associées avec l’ingénierie

des processus d’affaires telles que la planification stratégique de
l’information et l’analyse des domaines de gestion peuvent être
utilisées pour implanter les quatre premières activités du modèle de
ré-ingénierie des processus d’affaires.
30.1.4 CONSIGNES D’AVERTISSEMENT
Il est assez fréquent que des nouvelles approches de gestion telles

que la ré-ingénierie des processus d’affaires sont tout d’abord prises
pour des solutions miracles pour ensuite être critiquées si
sévèrement que ces approches sont ensuite reléguées à l’écart.
Au fil des années, un débat s’est effectué afin de statuer sur

l’efficacité de la ré-ingénierie des processus d’affaires. Dans une
excellente discussion sur le pour et le contre de la ré-ingénierie des
processus d’affaires, Weisz fait le sommaire de l’argumentation de la
façon suivante :
Il est tentant d’inclure la ré-ingénierie des processus d’affaires

comme une solution miracle. En considérant différents points
de vue (conception des systèmes, logiciels du domaine
publique, aspect historique de la conception des systèmes), il
aurait fallu prédire un haut taux d’échec du concept, ce taux
provenant de résultats observés. Pour plusieurs compagnies, la
ré-ingénierie des processus d’affaires a été un échec, alors que
l’effort de ré-ingénierie fut un succès pour d’autres
organisations.
La ré-ingénierie des processus d’affaires fonctionne si elle est
appliquée par du personnel motivé et bien formé reconnaissant que
la ré-ingénierie des processus d’affaires est une activité continue. Si
la ré-ingénierie des processus d’affaires est effectuée efficacement,
les systèmes d’information seront mieux intégrés aux processus
d’affaires.
La ré-ingénierie de vieilles applications peut être envisagée dans un

contexte de stratégies de gestion à grande échelle et les priorités de
la ré-ingénierie des logiciels pourrontêtre évaluées intelligemment.
Même si la ré-ingénierie des processus d’affaires est une stratégie

étant rejetée par une compagnie, la ré-ingénierie des logiciels est une
activité qui doit être faite. Des centaines de logiciels essentiels au
bon fonctionnement des organisations ont en théorie besoin d’être
reconstruits.
30.2 RÉ-INGÉNIERIE DU LOGICIEL
Considérons le cas suivant qui est commun dans la pratique de

l’informatique :
Une application logicielle a servi les besoins de gestion d’une

compagnie durant une quinzaine d’années. Durant ce temps,
cette application a été corrigée, modifiée et adaptée plusieurs
fois.
Les informaticiens ayant fait ce travail ont eu les meilleures

intentions, mais les pratiques de l’ingénierie du logiciel ont été
abrégées ou ignorées en raison de l’économie de temps et
d’argent.
Maintenant, cette application est rendue instable. Elle

fonctionne encore mais à chaque tentative de modification, des
erreurs inattendues se produisent, rendant son fonctionnement
aléatoire.
Malgré cela, l’application doit continuer à évoluer. Qu’est-ce que

l’organisation doit faire?
30.2.1 ENTRETIEN DU LOGICIEL
Les coûts d’entretien des logiciels existants peuvent représenter plus

de 60% de tous les efforts fournis par un département des systèmes
informatiques.
Ce pourcentage augmente continuellement en raison de

l’augmentation constante de la production de logiciels.
30.2.2 UN MODÈLE DE PROCESSUS DE RÉ-INGÉNIERIE DU
LOGICIEL
La ré-ingénierie du logiciel est un processus demandant beaucoup de

temps, de budget et de ressources pouvant autrement être occupés à
des buts plus urgents. Pour toutes ces raisons, la ré-ingénierie n’est
pas accomplie en quelque mois ou même en quelques années.
La ré-ingénierie des systèmes d’information est une activité qui va

demander une participation du département des technologies de
l’information pour plusieurs années. C’est pourquoi chaque
organisation a besoin d’une stratégie de ré-ingénierie orientée sur la
qualité des logiciels.
Afin d’implanter cette stratégie, nous allons définir un processus de

ré-ingénierie du logiciel comportant six étapes. Dans certains cas,
ces étapes s’exécutent en séquence linéaire, mais ce n’est pas
toujours le cas. Le processus est un modèle cyclique impliquant que
chacune de ses activités peut être répétée et que le processus peut
se terminer à n’importe quelle de ces étapes.
 ANALYSE DE L’INVENTAIRE DES APPLICATIONS
 RESTRUCTURATION DE LA DOCUMENTATION
o Ne pas modifier la documentation existante
o Modifier la documentation existante
o Refaire la documentation
 RÉTRO-INGÉNIERIE
 RESTRUCTURATION DU CODE
 RESTRUCTURATION DES DONNÉES
 INGÉNIERIE DE MODERNISATION
30.3 RÉTRO-INGÉNIERIE (REVERSE INGÉNIEERING)
En théorie, le processus de rétro-ingénierie prend en entrée du code

source non structuré et sans documentation et donne en sortie les
spécifications et la documentation complète de ce programme.
En pratique, cette théorie est difficile à réaliser. La rétro-ingénierie

peut extraire des informations de conception du code source, mais le
degré de réalisation du niveau d’abstraction, les spécifications,
l’exactitude de la documentation, la coordination entre les analystes
et les outils de conception et l’orientation des processus est très
variable :
 Niveau d’abstraction : Le niveau d’abstraction d’un processus

de rétro-ingénierie et les outils d’analyse utilisés pour le
supporter sont liés au degré de sophistication de l’information
de conception pouvant être dérivé du code source.
 Degré de réalisation : Le degré de réalisation d’un processus

de rétro-ingénierie est lié au niveau de détails généré par un
certain niveau d’abstraction. L’augmentation du degré de
réalisation est directement proportionnelle à la quantité
d’analyse effectuée par la personne affectée au processus de
rétro-ingénierie.
 Interactivité : degré par lequel l’analyste utilise des outils

automatisés afin de créer un processus de rétro-ingénierie
valide. Dans la plupart des cas, lorsque le niveau d’abstraction
augmente, l’interactivité doit augmenter ou sinon le degré de
réalisation va diminuer.
 Orientation : Si l’orientation du processus de rétro-ingénierie est

à sens unique, toute l’information extraite du code source est
fournie à l’analyste pouvant alors l’utiliser pour toutes les
activités de l’entretien du logiciel. Si l’orientation est
bidirectionnelle, l’information est donnée en entrée à un outil de
ré-ingénierie qui tente de restructurer ou de recréer l’ancien
programme
Le processus de la rétro-ingénierie est présenté à la figure suivante :
30.3.1 LA RÉTRO-INGÉNIERIE PERMETTANT DE
DÉTERMINER LES TRAITEMENTS
La première activité réelle de la rétro-ingénierie débute avec une

tentative de compréhension et d’extraction des abstractions
procédurales incluses dans le code source.
Afin de comprendre les abstractions procédurales, le code est

analysé à des niveaux variés d’abstraction :
 Système
 Programme
 Composantes
 Patrons
 Instructions
Pour de larges systèmes, la rétro-ingénierie est généralement

effectuée par une approche semi-automatisée. Des outils de
conception automatisée sont utilisés afin de décomposer la
sémantique du code déjà existant.
La sortie du processus est ensuite fournie en entrée aux outils de

restructuration et de modernisation afin de compléter le processus de
ré-ingénierie.
30.3.2 LA RÉTRO-INGÉNIERIE PERMETTANT DE
DÉTERMINER LES STRUCTURES DE DONNÉES
La rétro-ingénierie des données s’effectue à différents niveaux

d’abstraction. Au niveau du code, les structures de données internes
des programmes doivent souvent subir le processus de ré-ingénierie
faisant partie de la politique globale de la ré-ingénierie des
organisations.
Au niveau des systèmes, les structures de données globales

(exemple : fichiers et bases de données) subissent généralement le
processus de ré-ingénierie afin d’implanter de nouvelles méthode de
gestions des bases de données (exemple : passage des fichiers
séquentiels aux bases de données relationnelles). La rétro-ingénierie
de la structure de données globale actuelle est une étape préalable à
l’implantation d’une nouvelle base de données globale au système.
 Structures de données internes : Les techniques de rétro-

ingénierie pour les données internes des programmes se
concentrent sur la définition de classes d’objets. Cette
opération est effectuée en étudiant le code du programme dans
le but de regrouper des variables du programme ayant un lien
entre-elles.
Dans plusieurs cas, l’organisation des données à l’intérieur du

code contribue à l’identification des types abstraits :
o Structures d’enregistrement de fichiers

o Fichiers
o Listes
o Piles
o Files
 Structure de la base de données : Une base de données
permet la définition de ses entités indépendamment de son
organisation logique et de sa structure physique et supporte
des méthodes de définition de relations entre les objets. La ré-
ingénierie des bases de données implique donc une
compréhension des entités et des relations constituant ces
bases de données.
30.3.3 LA RÉTRO-INGÉNIERIE DES INTERFACES-USAGER
Les interfaces-usagers graphiques complexes sont rendues

courantes pour les applications et les systèmes informatiques de tous
les genres. C’est pourquoi la reconstruction des interfaces usagers
est devenue l’une des activités les plus courante de la ré-ingénierie.
Avant qu’une interface usager soit reconstruite, la rétro-ingénierie de

l’interface doit être effectuée. Afin d’analyser complètement une
interface usager existante, la structure et le comportement de
l’interface doivent être spécifiés. Merlo et ses collègues suggèrent
trois interrogations de base devant trouver une réponse avant que le
processus de rétro-ingénierie de l’interface-usager débute :
 Quelles sont les actions de base (combinaisons de touches et

clics de souris) devant être traitées par l’interface?
 Quelle serait une description compacte de la réponse

comportementale du système à ces actions?
 Quel concept d’interface de remplacement ou d’interface

équivalente serait approprié pour le cas étudié?
30.4 RESTRUCTURATION
La restructuration du logiciel modifie le code source et/ou les

données dans le but de les rendre compatibles aux changements
futurs.
En général, la restructuration ne modifie pas l’architecture générale

du logiciel. La restructuration a tendance à se concentrer sur les
détails de conception des modules individuels et sur les structures de
données locales définies dans les modules ou les sous-routines.
Si la restructuration dépasse les limites des modules individuels et

englobe l’architecture du logiciel, la restructuration devient alors de
l’ingénierie de modernisation (forward engineering).
Arnold définit un nombre de bénéfices pouvant être réalisés lorsque

le logiciel est restructuré :
 Les programmes ont une meilleure qualité, une meilleure

documentation, une diminution de complexité et un meilleur
conformisme aux applications et aux normes de l’ingénierie du
logiciel moderne
 Une réduction de la frustration parmi les analystes travaillant

sur les logiciels, ce qui améliore les capacités d’analyse et la
productivité des équipes de développement
 Une réduction de l’effort requis pour accomplir les activités

d’entretien du logiciel
 Le logiciel est plus facile à tester et à déverminer
La restructuration se produit lorsque l’architecture de base et les

parties principales du logiciel sont bonnes même si quelques détails
internes sont à modifier et que seulement quelques modules et
quelques structures de données ont besoin de modifications
majeures.
30.4.1 RESTRUCTURATION DU CODE
La restructuration du code est effectuée afin de produire un logiciel

ayant les mêmes fonctions, mais avec une meilleure qualité que le
logiciel original. En général, les techniques de restructuration du code
modélisent la logique du programme pour ensuite appliquer une série
de règles de transformations.
30.4.2 RESTRUCTURATION DES DONNÉES
 Analyse du code source/Analyse des données
 Révision de la structure des données
o Standardisation des enregistrements
o Rationalisation des noms des

données/structures/variables
 Modification physique des structures de données

30.5 INGÉNIERIE DE MODERNISATION (FORWARD
ENGINEERING)
Le processus de l’ingénierie de modernisation (forward engineering)

applique les principes, les concepts et les méthodes de l’ingénierie
du logiciel afin de recréer des applications existantes.
Dans la plupart des cas, l’ingénierie de modernisation ne crée pas

simplement une version moderne d’un vieux logiciel, mais plutôt une
intégration des nouvelles spécifications des usagers et de la
technologie dans un nouveau programme dont les capacités
dépassent la version précédente.
30.5.1 INGÉNIERIE DE MODERNISATION DES

ARCHITECTURES CLIENT/SERVEUR
Durant la dernière décade, plusieurs applications tournant sur des

ordinateurs centraux ont subi le processus de ré-ingénierie afin de
s’adapter aux architectures client/serveur. Cette architecture se
résume par la centralisation des ressources de traitement (incluant le
logiciel) qui sont distribuées parmi les plateformes des clients. Bien
qu’il existe une variété de différents environnements distribués,
l’application tournant sur un ordinateur central et qui subit le
processus de ré-ingénierie pour la conversion en une architecture
client/serveur subit les opérations suivantes :
 Les fonctionnalités de l’application migrent sur chaque

ordinateur client
 De nouvelles interfaces usager graphiques sont implantées sur
les ordinateurs des clients
 Les opérations de base de données s’effectuent en général sur
le serveur
 Des fonctionnalités/opérations spéciales peuvent rester sur le
serveur
 Des fonctionnalités nouvelles de sécurité, d’archivage et de
contrôle doivent être implantées sur les sites des clients et du
serveur
30.5.2 INGÉNIERIE DE MODERNISATION DES
ARCHITECTURES ORIENTÉES-OBJET
L’ingénierie de conception des applications orientées-objet est

devenu un choix pour beaucoup d’organismes de conception de
logiciel.
Il existe deux options possibles lorsqu’il s’agit de convertir une

application classique en application orientée-objet :
 la laisser telle quelle sans aucune modification
 appliquer le processus de ré-ingénierie à l’application afin

qu’elle puisse être intégrée à des systèmes informatique
développés en langages orientés-objet
30.5.3 INGÉNIERIE DE MODERNISATION DES INTERFACES-
USAGER
Merlo et ses collègues suggèrent les étapes suivantes afin d’effectuer

la ré-ingénierie des interfaces-usager :
1. Comprendre l’interface originale et les mouvements de

données entre l’interface et le reste de l’application
2. Refaire la modélisation du comportement de l’interface

existante en une série d’abstractions ayant une signification
dans le contexte d’une interface-usager graphique
3. Introduire des améliorations rendant le mode d’interaction plus

efficient
4. Construire et intégrer la nouvelle interface-usager graphique

30.6 ASPECTS ÉCONOMIQUES DE LA RÉ-INGÉNIERIE
Si les budgets étaient illimités, chaque application logicielle devenue

désuète ou difficile d’entretien serait immédiatement remplacée par
des applications de haute qualité dont le code a été révisé par des
techniques moderne de ré-ingénierie du logiciel.
Malheureusement, les ressources sont limitées et en particulier le

budget et le personnel. La ré-ingénierie du logiciel étant un processus
demandant beaucoup de temps, de budget et de ressources pouvant
autrement être occupée à des buts plus urgents, il faudra donc
effectuer une analyse coût/bénéfice avant de décider de réviser une
application existante.
Université du Québec à Rimouski
SESSION: HIVER 2002

TRAVAIL PRATIQUE 02
(Livre de Pressman Chapitres 11, 12 et 13)
SIGLE: INF-232-99
TITRE: Génie logiciel II
CHARGÉ DE COURS : Martin Lesage
DATE DE REMISE : Jeudi 7 mars 2002 au cours
PONDÉRATION : 10%
Système de détection et de réparation des trous et ornières basé sur

l’internet
Suite à des plaintes de la population, le département des travaux publics et de la voirie
de la ville de Rimouski a décidé de développer un système de détection et de réparation
des trous et ornières basé sur l’internet. Le fait de détecter les trous et les ornières
rapidement fait en sorte de minimiser les dommages occasionnés aux véhicules et de
réduire les coûts d’assurance pour le dédommagement des propriétaires de véhicules.
Une description de ce système est:
Les citoyens peuvent accéder au site internet du système de détection et de réparation

des trous et ornières afin de signaler la location et la dimension des trous et des
ornières. Tout au long du processus de rapport des trous et des ornières, les trous et les
ornières sont soumis à un processus de saisie afin de les soumettre en entrée au
« Système d’information des réparations du département de la voirie et des travaux
publics ».
Lors de la saisie, les trous et les ornières sont quantifiés pa :
- un numéro d’identification(clef primaire)

- nom de la rue
- description
- grosseur (de 1 à 10)
- situation(près du fossé, sur le côté de la route, au milieu de la route)
- district (déterminé à partir des adresses)
- priorité de réparation(déterminé d’après la grosseur du trou et de l’ornière)
Une demande de réparation(work order) est associée à chaque trou ou ornière et
comprend :
- numéro de la demande de réparation

- location
- grosseur
- numéro d’identification de l’équipe de réparation
- nombre de personnes constituant l’équipe
- l’équipement utilisé
- heures travaillées à accomplir la tâche
- statut(réparation en cours, réparation terminée, réparation temporaire, non
réparé)
- quantité de matériel de remplissage utilisé(concassé, gravier, sable, etc.)
- coût de la réparation(calculé à partir des heures travaillées, du nombre de
personnes ayant travaillé à la réparation, le matériel et l’équipement utilisé)
Finalement, un fichier des dommages est mis à jour afin de conserver des informations
sur l’ensemble des dommages causés par un trou ou une ornière déterminé. Ce fichier
contient également des informations sur des personnes ayant subi des dommages
causés par des trous et des ornières (nom, l’adresse, le numéro de téléphone, le type de
dommage et le montant des réparations)
Le système de détection et de réparation des trous et ornières fonctionne uniquement à

partir de l’internet. Toutes les signalisations des incidents se font donc à partir de
l’internet et non par téléphone.
 Question 1 :
Référence : section 11.3.1
Analysez le domaine d’information du système de détection et de réparation des trous et

ornières basé sur l’internet. Représentez (en utilisant toute notation vous semblant
appropriée) :
- les processus, les flux d’informations, les entités externes et les dépôts
d’information
- les entités, et les attributs de ce système
 Question 2 :
Effectuez la partition du système de détection et de réparation des trous et ornières.

Effectuez premièrement la partition horizontale et ensuite la partition verticale.
 Question 3 :
Effectuez la modélisation conceptuelle des données (diagramme entité/relation) du

système de détection et de réparation des trous et ornières. N’oubliez pas de spécifier
les cardinalités et les modalités
 Chapitre 12, problème
Effectuez les diagramme de flux de données suivants du système de détection et de

réparation des trous et ornières :
- niveau 0 (modèle fondamental du système/modèle contextuel)
- niveau 1
- niveau 2 (faites deux diagrammes de niveau 2 résultant de l’éclatement de

deux processus de votre choix)
 Chapitre 13, problème 13.1
Faites-vous de la conception de logiciel lorsque vous faites un programme?

Quelle est la différence entre la conception de logiciel et la programmation?
 Chapitre 13, problème 13.13
Expliquez, dans vos mots, comment le concept de partition structurée peut

faciliter l’entretien du logiciel?
Université du Québec à Rimouski
SESSION: HIVER 2002

TRAVAIL PRATIQUE 03
(Livre de Pressman Chapitres 14, 15 et 17)
SIGLE: INF-232-99
TITRE: Génie logiciel II
CHARGÉ DE COURS : Martin Lesage
DATE DE REMISE : Jeudi 28 mars 2002 au cours
PONDÉRATION : 10%
Système de détection et de réparation des trous et ornières basé sur

l’internet
Suite à des plaintes de la population, le département des travaux publics et de la voirie
de la ville de Rimouski a décidé de développer un système de détection et de réparation
des trous et ornières basé sur l’internet. Le fait de détecter les trous et les ornières
rapidement fait en sorte de minimiser les dommages occasionnés aux véhicules et de
réduire les coûts d’assurance pour le dédommagement des propriétaires de véhicules.
Une description de ce système est :
Les citoyens peuvent accéder au site internet du système de détection et de réparation

des trous et ornières afin de signaler la location et la dimension des trous et des
ornières. Tout au long du processus de rapport des trous et des ornières, les trous et les
ornières sont soumis à un processus de saisie afin de les soumettre en entrée au
« Système d’information des réparations du département de la voirie et des travaux
publics ».
Lors de la saisie, les trous et les ornières sont quantifiés par :
- un numéro d’identification(clef primaire)

- nom de la rue
- description
- grosseur (de 1 à 10)
- situation(près du fossé, sur le côté de la route, au milieu de la route)
- district (déterminé à partir des adresses)
- priorité de réparation(déterminé d’après la grosseur du trou et de l’ornière)
Une demande de reparation (work order) est associée à chaque trou ou ornière et
comprend :
- numéro de la demande de réparation

- location
- grosseur
- numéro d’identification de l’équipe de réparation
- nombre de personnes constituant l’équipe
- l’équipement utilisé
- heures travaillées à accomplir la tâche
- statut(réparation en cours, réparation terminée, réparation temporaire, non
réparé)
- quantité de matériel de remplissage utilisé(concassé, gravier, sable, etc.)
- coût de la réparation(calculé à partir des heures travaillées, du nombre de
personnes ayant travaillé à la réparation, le matériel et l’équipement utilisé)
Finalement, un fichier des dommages est mis à jour afin de conserver des informations
sur l’ensemble des dommages causés par un trou ou une ornière déterminé. Ce fichier
contient également des informations sur des personnes ayant subi des dommages
causés par des trous et des ornières (nom, l’adresse, le numéro de téléphone, le type de
dommage et le montant des réparations)
Le système de détection et de réparation des trous et ornières fonctionne uniquement à

partir de l’internet. Toutes les signalisations des incidents se font donc à partir de
l’Internet et non par téléphone.
 Question 1 :
Référence : problème 14.12
Développez l’architecture du logiciel du « Système de détection et de réparation des

trous et ornières basé sur l’Internet » tel que démontré au chapitre 14 du livre de
Pressman.
Utilisez la méthode des flux de transformation expliquée dans votre livre à la section
14.6. Effectuez les sept étapes de cette méthode expliquées aux pages 381 à 389.
Appliquez cette méthode aux diagrammes de flux de données de niveaux 0 et 1 de ce

système ainsi qu’à l’un des diagrammes de flux de données de niveau 2 que vous avez
effectué dans le travail pratique 2.
 Question 2 :
 Partie 1
Décrivez la plus mauvaise interface-usager que vous avez utilisé et critiquez-la

en fonction des concepts introduits dans le chapitre 15.
 Partie 2
Décrivez la plus mauvaise interface-usager que vous avez utilisé et analysez-la

en fonction des concepts introduits dans le chapitre 15.
 Question 3 :
À l’aide des concepts introduits dans le chapitre 15, concevez l’interface-usager du

« Système de détection et de réparation des trous et ornières basé sur l’Internet »
 Question 4 :
En utilisant l’analyse des cas limites, concevez une série de tests pouvant s’appliquer au
« Système de détection et de réparation des trous et ornières basé sur l’Internet »
 Question 5
Choisissez un programme comportant une interface-usager graphique (GUI) que

vous connaissez bien et concevez une série de tests pouvant s’appliquer sur
cette interface.

Notes de Cours INF 23299 GENIE LOGICIEL PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Notes de Cours INF 23299 GENIE LOGICIEL PDF

Transféré par

Droits d'auteur :

Formats disponibles

Notes de cours

INF-23299 – GÉNIE LOGICIEL II

Recueil de notes de cours produit pour le cours

Basé sur : Pressman, R. S. (2001). Software engineering: A

Université du Québec à Rimouski (UQÀR)

DESCRIPTION DU COURS SELON L'ANNUAIRE

Comprendre les principes et la problématique de la conception, de la mise en œuvre et de la

Principes d’architecture, de conception et de réalisation d’un logiciel. Rôle de la conception dans

INSERTION DU COURS DANS LE PROGRAMME

Obligatoire dans le programme de baccalauréat en informatique

Le cours s’appuie essentiellement sur l’ouvrage de référence obligatoire suivant :

Type d’épreuve Pondération

Examens : Les examens sont des épreuves écrites.

Notation proposée (correspondance de la note chiffrée à la note littérale, s'il y a lieu)

ÉCHÉANCIER DE REMISE DES TRAVAUX ET EXAMENS

Examen Pondération Date de l’épreuve

Pfleeger, Shari Lawrence

Sur l'analyse et la conception:

Booch, Grady, Analyse et conception orientées objets, Addison-Wesley (FR) 1994

Booch, Grady, Object-Oriented Analysis and Design with Applications, Benjamin/Cumming,1994

Livre de Pressman, chapitres 1 & 2

“Bug” de l’an 2000

- ignoré durant des années. Les compagnies ne voulaient pas

- beaucoup d’ordinateurs et de logiciels n’avaient pas la

- quelque temps avant le passage à l’an 2000, une soudaine

- quelles seront les répercussions de pannes de logiciel dans les

o système de défense et de lancement de missile,

- les compagnies ont investi des sommes d’argent considérables

L’industrie du logiciel possède un marché de 500 milliards de dollars.

Phénomène des compagnies « dot-com » :

- Yahoo, Amazon, E-Bay

Les gouvernements commencent à légiférer les compagnies voulant

Les compagnies de logiciels sont en train de développer des

Présentement le logiciel jour deux rôles principaux :

Le logiciel permet d’utiliser et de faire fonctionner le matériel

2) Moyen d’obtenir un produit/Programme servant à faire

Le logiciel fait la gestion/le transport/la transformation du produit le

Le logiciel fait la gestion de l’information personnelle(ex : transactions

Le rôle du logiciel a changé beaucoup au cours des 50 dernières

Le programmeur solitaire des décennies passées a été remplacé par

Malgré l’augmentation du nombre de programmeurs et de l’ajout de

- quantité de temps nécessaire pour terminer un logiciel

- coûts de développement élevés

- il existe encore des erreurs dans le logiciel même lorsque celui-

- les gestionnaires de projets ont de la misère à évaluer le taux

Cette problématique est étudiée dans la discipline du génie logiciel

- un ensemble d’instructions(programme d’ordinateur) qui

- des structures de données permettant aux programmes de

- la documentation expliquant les opérations et l’utilisation des

Le logiciel est une composante logique(algorithmique) plutôt que

1) Le logiciel est développé, il n’est pas manufacturé au sens

Ressemblances avec la production des composantes :

o une haute qualité est obtenue par l’entremise d’une

o le matériel peut être difficilement corrigé ou arrangé

Un projet de conception de logiciel ne peut pas être géré

Graphique du taux de panne du matériel en fonction du temps

Temps de vie du matériel

- le matériel est sujet à tomber en panne au début de sa vie

- les défauts sont corrigés et le matériel a un taux de panne

- vers la fin de la vie du matériel, il y a une recrudescence des

- les erreurs non découvertes vont causer un taux élevé d’erreurs

- au cours de la vie du programme, les erreurs sont corrigées, le

- bien que le logiciel ne puisse pas s’user, il peut se détériorer à