Rappel Genie Logiciel

Chapitre 1 Principes du génie logiciel DSI4 & MDW4
Chapitre 1
Principes du génie logiciel
1. Crise du logiciel
Durant les années 70, on a constaté la naissance d’une crise de l'industrie du logiciel dont les
principaux symptômes sont :
 Le coût de développement d'un logiciel est presque impossible à prévoir et le délai de
livraison n'est que rarement respecté. On cite ainsi dans la littérature des dépassements
moyens du coût budgeté et du délai prévu respectivement de 70% et 50%.
 La qualité du logiciel livré est souvent déficiente. Le produit ne satisfait pas les
besoins de l'utilisateur, il consomme plus de ressources que prévu et il est à l'origine
de pannes.
 La maintenance du logiciel est difficile, coûteuse et souvent à l'origine de nouvelles
erreurs. Mais en pratique, il est indispensable d'adapter les logiciels car leurs
environnements d'utilisation changent et les besoins des utilisateurs évoluent.
 Il est rare qu'on puisse réutiliser un logiciel existant ou un de ses composants pour
confectionner un nouveau système, même si celui ci comporte des fonctions
similaires. Tout amortissement sur plusieurs projets est ainsi rendu impossible.
Les facteurs de cette crise (d’après une étude de Standish group) :
Facteurs d’échec Pourcentage

1. Manque d’application de l’utilisateur 12.8%
2. Exigences et spécifications incomplètes 12.3%
3. Changements aux exigences et spécifications 11.8%
4. Manque de soutien de la direction 7.5%
5. Incompétence technologique 7.0%
6. Manque de ressources 6.4%
7. Attentes irréalistes 5.9%
8. Objectifs mal définis 5.3%
9. Calendrier irréaliste 4.3%
10. Nouvelle technologie 3.7%
11. Autres 23.0%
Page 1
L’écart entre les souhaits et les réalisations :
1. Ce que la direction demande
2. Ce que demande le chef de projet
3. Ce qui est conçu
4. Ce qui est programmé
5. Ce qui est installé
6. Ce que l’utilisateur souhaitait
Pour maîtriser la complexité des systèmes logiciels et s’assurer que le logiciel produit répond
réellement aux besoins des utilisateurs, il convient de procéder selon une démarche bien
définie, de se baser sur des principes et méthodes, et d'utiliser des outils performants.
Le génie logiciel (software ingineering) cherche donc à établir et à utiliser des principes dans
le but de développer économiquement du logiciel qui est fiable et qui fonctionne efficacement
sur les machines.
Page 2
2. Le génie logiciel
2.1. Génie
Le mot génie, utilisé en général accompagné d'un adjectif, comme dans génie civil, génie
chimique ou génie atomique, désigne, d'après le Petit Robert, les connaissances et techniques
de l'ingénieur.
Ce terme est synonyme de science de l'ingénieur (engineering) qui peut être définie comme
l'application des sciences et mathématiques par laquelle les propriétés de la matière et les
sources d'énergie de la nature sont rendues utiles à l'homme dans des constructions, machines,
produits, systèmes et procédés.
2.2. Logiciel
L'Organisation internationale de normalisation, appelée brièvement ISO, a défini en 1981 le
logiciel (software) comme une création intellectuelle rassemblant des programmes, des
procédures, des règles et de la documentation utilisés pour faire fonctionner un système
informatique.
2.3. Génie logiciel

D’après la Norme IEEE 610.12:
« Le Génie Logiciel est l’application d’une approche systématique, disciplinée et
quantifiable au développement, à l’exploitation et à la maintenance du logiciel. C’est-à-dire,
l’application de l’ingénierie au logiciel ».
D’après Classical and Object-Oriented Software Engineering with UML and Java de Schach:
« Le Génie Logiciel est une discipline qui a pour but la fabrication du logiciel sans faute,
livré dans le délai et le budget prévus à l’avance, et qui satisfait aux besoins du client ».
En résumé, nous dirons que :

- La motivation première du Génie Logiciel est la réduction des coûts de
développement du logiciel.
- Le Génie Logiciel est un ensemble de moyens (techniques et
méthodologiques) permettant la construction de systèmes informatiques
répondant à des critères de qualité préalablement définis.
Le génie logiciel est l’art de bien faire de bons

programmes
Page 3
3. Qu’est ce qu’un bon programme ?

Un bon programme doit satisfaire différents points de vues :
Point de vue
utilisateur
Ce que ça fait
Un bon
Comment ça le fait programme Combien ça coûte
Point de vue Point de vue

programmeur fournisseur
On parle alors de critères de qualité de logiciel.
Un bon programme pour l’utilisateur :
Facilité d'installation / utilisation / mise à jour :

– intuitif / convivial / ergonomique
– standard de présentation, d'interaction
– qualité de la documentation : documents papier, aide en ligne, messages d'erreur
Fiabilité, sûreté, résistance aux pannes :
– pas de plantage
– si erreur, rattrapage / poursuite de l'exécution
– si plantage, rattrapage des données
– si plantage local, pas d'arrêt global (réseau)
Robustesse, passage à l'échelle :
– capacité à traiter de grandes quantités
– résistance aux cas limites (pics de comportement)
Page 4
Sécurité :
– intégrité
– confidentialité, authentification
Interopérabilité
– Programme : disponibilité/compatibilité sur divers environnements, OS, ...
– Données : standards, formats d'échange
– Programme + données : protocoles
Un bon programme pour le programmeur :
– facile à comprendre : structuration, commentaires, documentation, ...

– facile à vérifier / valider : hypothèses explicites, autotest, accès interne en debug, ...
– facile à modifier : corrections, extensions, ...
– facile à réutiliser : généricité, encapsulation, ...
– facile à porter : structuration en couches,…
Un bon programme pour le fournisseur :
- Coût réduit de développement + maintenance

- Délai tenu : contrat
- Production avec des risques maîtrisés
- Qualité conforme aux exigences
- Succès de vente
Page 5
Chapitre 2 Modélisation, cycles de vie et méthodes DSI4 & MDW4
Chapitre 2
Modélisation, cycles de vie et méthodes
1. Pourquoi et comment modéliser ?
1.1. Qu’est-ce qu’un modèle ?

Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une
entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation
pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant les
détails qui n’influencent pas son comportement de manière significative. Il reflète ce que le
concepteur croit important pour la compréhension et la prédiction du phénomène modélisé.
Les limites du phénomène modélisé dépendant des objectifs du modèle.
Voici quelques exemples de modèles :
Modèle météorologique
à partir de données d’observation (satellite, …), il permet de prévoir les conditions
climatiques pour les jours à venir.
Modèle économique
peut par exemple permettre de simuler l’évolution de cours boursiers en fonction
d’hypothèses macro-économiques (évolution du chômage, taux de croissance, …).
Modèle démographique
définit la composition d’un panel d’une population et son comportement, dans le but de
fiabiliser des études statistiques, d’augmenter l’impact de démarches commerciales, etc.
Plans
Les plans sont des modèles qui donnent une vue d’ensemble du système concerné. Par
exemple, dans le bâtiment, pour la construction d’un immeuble, il faut préalablement élaborer
de nombreux plans :
 plans d’implantation du bâtiment dans son environnement ;
 plans généraux du bâtiment et de sa structure ;
 plans détaillées des différents locaux, bureaux, appartements, …
 plans des câblages électriques ;
 plans d’écoulements des eaux, etc
Les trois premiers exemples sont des modèles que l’on qualifie de prédictifs. Le dernier, plus
conceptuel, possède différents niveaux de vues comme la pluspart des modèles en génie
logiciel.
1.2. Pourquoi modéliser ?
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.
Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et
il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est
essentielle pour aboutir à une compréhension commune aux différentes parties prenantes
(notamment entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un
problème donné.
Page 6
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des
délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles
pour faire de la génération de code (au moins au niveau du squelette) voire des allers-retours
entre le code et le modèle sans perte d’information. Le modèle est enfin indispensable pour
assurer un bon niveau de qualité et une maintenance efficace. En effet, une fois mise en
production, l’application va devoir être maintenue, probablement par une autre équipe et, qui
plus est, pas nécessairement de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes
non-triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les
modèles employés, la démarche de modélisation n’est pas la même.
1.3. Qui doit modéliser ?
La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE). C’est
malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme
informatique et non dans les processus de l’entreprise.
Il est préférable que la modélisation soit réalisée par la maîtrise d’ouvrage (MOA) de sorte
que le métier soit maître de ses propres concepts. La MOE doit intervenir dans le modèle
lorsque, après avoir défini les concepts du métier, on doit introduire les contraintes propres à
la plate-forme informatique.
Il est vrai que certains métiers, dont les priorités sont opérationnelles, ne disposent pas
toujours de la capacité d’abstraction et de la rigueur conceptuelle nécessaires à la
formalisation. La professionnalisation de la MOA a pour but de les doter de ces compétences.
Cette professionnalisation réside essentiellement dans l’aptitude à modéliser le système
d’information du métier : le maître mot est modélisation. Lorsque le modèle du système
d’information est de bonne qualité, sobre, clair, stable, la maîtrise d’œuvre peut travailler dans
de bonnes conditions. Lorsque cette professionnalisation a lieu, elle modifie les rapports avec
l’informatique et déplace la frontière des responsabilités, ce qui contrarie parfois les
informaticiens dans un premier temps, avant qu’ils n’en voient apparaître les bénéfices.
1.4. Maîtrise d’ouvrage et maîtrise d’œuvre
Maître d’ouvrage (MOA) :
Le MOA est une personne morale (entreprise, direction etc.), une entité de l’organisation. Ce
n’est jamais une personne.
Maître d’œuvre (MOE) :
Le MOE est une personne morale (entreprise, direction etc.) garante de la bonne réalisation
technique des solutions. Il a, lors de la conception du SI, un devoir de conseil vis-à-vis du
MOA, car le SI doit tirer le meilleur parti des possibilités techniques.
Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.
Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou
plusieurs fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.
Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs
fournisseurs. Le MOE assure leur coordination ; il veille à la cohérence des fournitures et à
leur compatibilité. Il coordonne l’action des fournisseurs en contrôlant la qualité technique, en
assurant le respect des délais fixés par le MOA et en minimisant les risques.
Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au
MOA, procéder aux vérifications nécessaires (« recette usine »).
Page 7
2. Le cycle de vie d’un logiciel

Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes du
développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage
est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises en
œuvre.
L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé
qu’elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
Définition des objectifs
Cet étape consiste à définir la finalité du projet et son inscription dans une stratégie globale.
Analyse des besoins et faisabilité
C’est-à-dire l’expression, le recueil et la formalisation des besoins du demandeur (le client) et
de l’ensemble des contraintes, puis l’estimation de la faisabilité de ces besoins.
Spécifications ou conception générale
Il s’agit de l’élaboration des spécifications de l’architecture générale du logiciel.
Conception détaillée
Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.
Codage (Implémentation ou programmation)
C’est la traduction dans un langage de programmation des fonctionnalités définies lors de
phases de conception.
Tests unitaires
Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est
implémenté conformément aux spécifications.
Intégration
L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du logiciel. Elle
fait l’objet de tests d’intégration consignés dans un document.
Qualification (ou recette)
C’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales.
Documentation
Elle vise à produire les informations nécessaires pour l’utilisation du logiciel et pour des
développements ultérieurs.
Mise en production
C’est le déploiement sur site du logiciel.
Maintenance
Elle comprend toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix
d’un modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie
permet de prendre en compte, en plus des aspects techniques, l’organisation et les aspects
humains.
Page 8
3. Modèles de cycles de vie d’un logiciel

3.1. Modèle de cycle de vie en cascade
Figure 1.1 : Modèle du cycle de vie en cascade
Le modèle de cycle de vie en cascade (cf. figure 1.1) a été mis au point dès 1966, puis
formalisé aux alentours de 1970.
Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la
production de certains documents ou logiciels. Les résultats sont définis sur la base des
interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase
suivante que s’ils sont jugés satisfaisants.
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée
ultérieurement sur la base qu’une étape ne remet en cause que l’étape précédente, ce qui, dans
la pratique, s’avère insuffisant.
L’inconvénient majeur du modèle de cycle de vie en cascade est que la vérification du bon
fonctionnement du système est réalisée trop tardivement: lors de la phase d’intégration, ou
pire, lors de la mise en production.
Page 9
3.2. Modèle de cycle de vie en V
Figure 1.2: Modèle du cycle de vie en V
Le modèle en V (cf. figure 1.2) demeure actuellement le cycle de vie le plus connu et
certainement le plus utilisé. Il s’agit d’un modèle en cascade dans lequel le développement
des tests et du logiciel sont effectués de manière synchrone.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition et
que toute description d’un composant est accompagnée de tests qui permettront de s’assurer
qu’il correspond à sa description.
Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la
spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier objectivement
après la réalisation.
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon
fonctionnement du système.
3.3. Modèle de cycle de vie en spirale
Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met
l’accent sur l’activité d’analyse des risques : chaque cycle de la spirale se déroule en quatre
phases :
1. détermination, à partir des résultats des cycles précédents, ou de l’analyse préliminaire
des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;
2. analyse des risques, évaluation des alternatives et, éventuellement maquettage ;
3. développement et vérification de la solution retenue, un modèle « classique » (cascade
ou en V) peut être utilisé ici ;
4. revue des résultats et vérification du cycle suivant.
L’analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des
maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle
se termine par un processus de développement classique.
Page 10
Figure 1.3: Modèle du cycle de vie en Spirale
3.4. Modèle par incrément

Dans les modèles précédents un logiciel est décomposé en composants développés
séparément et intégrés à la fin du processus.
Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des
incréments viennent s’intégrer à un noyau de logiciel développé au préalable. Chaque
incrément est développé selon l’un des modèles précédents.
Les avantages de ce type de modèle sont les suivants :
 chaque développement est moins complexe ;
 les intégrations sont progressives ;
 il est ainsi possible de livrer et de mettre en service chaque incrément ;
 il permet un meilleur lissage du temps et de l’effort de développement grâce à la
possibilité de recouvrement (parallélisation) des différentes phases.
Les risques de ce type de modèle sont les suivants :
 remettre en cause les incréments précédents ou pire le noyau ;
 ne pas pouvoir intégrer de nouveaux incréments.
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés
globalement, au début du projet. Les incréments doivent être aussi indépendants que
possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.
Page 11
Figure 1.4: Modèle du cycle de vie par incrément
4. Méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations
standards qui aident à concevoir des logiciels de qualité. Il existe différentes manières pour
classer ces méthodes, dont :
La distinction entre composition et décomposition :

Elle met en opposition d’une part les méthodes ascendantes qui consistent à construire un
logiciel par composition à partir de modules existants et, d’autre part, les méthodes
Page 12
descendantes qui décomposent récursivement le système jusqu’à arriver à des modules

programmables simplement.
La distinction entre fonctionnel (dirigée par le traitement) et orientée objet :
Dans la stratégie fonctionnelle (également qualifiée de structurée) un système est vu comme
un ensemble hiérarchique d’unités en interaction, ayant chacune une fonction clairement
définie. Les fonctions disposent d’un état local, mais le système a un état partagé, qui est
centralisé et accessible par l’ensemble des fonctions. Les stratégies orientées objet considèrent
qu’un système est un ensemble d’objets interagissant. Chaque objet dispose d’un ensemble
d’attributs décrivant son état et l’état du système est décrit (de façon décentralisée) par l’état
de l’ensemble.
Page 13
Chapitre 3 Spécification des besoins DSI4 & MDW4
Chapitre 3
Spécification des besoins
Le produit de la phase de définition/spécification des besoins est le cahier des

charges du logiciel en anglais software requierement document. Le cahier des
charges constituera le contrat entre le client et le développeur du logiciel. Selon la
taille du projet, le cahier des charges peut consister en quelques pages ou s'étendre
sur plusieurs volumes.
1. Spécification des besoins

L'étude faite durant la phase de pré-analyse sert généralement de point de départ
pour écrire le cahier des charges. A défaut de pré-analyse, le point de départ de la
phase de définition est constitué par les besoins du client. Il est important de
réaliser que l'énoncé d'un besoin ne constitue pas un cahier des charges. Voici un
exemple d'énoncé des besoins [Wiener 84. p 19]:
Réaliser un logiciel de détection de fautes de frappes (spelling checker), à utiliser

pour des textes créés par un éditeur. Le logiciel doit être capable, en consultant un
dictionnaire, de signaler à l'utilisateur les mots susceptibles d'être mal écrits, et
permettre à l'utilisateur de corriger immédiatement ces mots dans le texte. Le
logiciel doit également permettre d'ajouter de nouveaux mots au dictionnaire. Il
devra s'exécuter sur un micro-ordinateur avec 128K octects de mémoire principale
et disposant soit de deux lecteurs de disquettes, soit d'un lecteur de disquettes et
d'un disque dur.
Il n'est pas réaliste de se lancer dans la conception d'un logiciel uniquement sur la
base d'un tel énoncé.
Le cahier des charges peut être exprimé en langue naturelle. Cette solution présente
l'avantage d'être facilement compréhensible par le client, mais conduit
inévitablement à certaines ambiguïtés liées à l'utilisation de la langue naturelle.
L'utilisation d'une langue naturelle rend également difficilement envisageable une
vérification automatique de consistance (c'est-à-dire de non-contradiction) des
spécifications. Pour cette raison des recherches ont amené à proposer des langages
spécialisés permettant d'exprimer les spécifications d'un cahier des charges.
Toutefois, pour comprendre l'importance d'une formulation rigoureuse du cahier
des charges il suffit de considérer les faits suivants [Alford 77]:
Page 14
 dans presque tous les projets logiciels qui échouent, le cahier des charges
s'est trouvé avoir du retard, être incomplet, trop contraignant ou simplement
incorrect;
 une erreur introduite dans le cahier des charges, donc tôt dans le cycle de vie
du logiciel, est extrêmement coûteuse à corriger (ces erreurs sont
généralement découvertes tard dans le développement du logiciel nécessitent
souvent l'adjonction de code, remettent en cause la conception du logiciel et
nécessitent de retester certaines parties du logiciel)
Un bon cahier des charges peut être caractérisé par les 7 qualificatifs suivants
[IEEE 830]:
1. non ambigu
2. complet
3. vérifiable
4. consistant
5. modifiable
6. traçable
7. utilisable durant la maintenance.
Ces qualificatifs sont intéressants surtout parce qu'ils sont révélateurs de problèmes
pouvant résulter d'un cahier des charges mal élaboré. Commentons brièvement ces
qualificatifs:
non ambigu : La non ambiguïté exige notamment une grande précision dans
l'utilisation des termes introduits (si possible définir les termes dans un glossaire
faisant partie du cahier des charges);
complet : On oublie facilement de préciser dans un cahier des charges le

comportement d'un logiciel lors d'événements non désirés (panne du matériel,
erreur dans les données introduites par l'utilisateur, etc.). Ce n'est pas au
programmeur d'inventer lors de l'implémentation ce que devra faire le programme
dans de telles situations;
vérifiable : Une spécification non vérifiable est par exemple: "le logiciel doit être
facile à utiliser";
consistant : Un cahier des charges n'est pas consistant si deux spécifications sont
contradictoires. Le problème devient sensible à partir d'une certaine taille du cahier
des charges;
Page 15
modifiable : Les spécifications peuvent changer soit durant le développement du

logiciel, soit durant la phase de maintenance. Ces modifications doivent pouvoir
être reportées facilement dans le cahier des charges;
traçable : Le traçage est la possibilité d'avoir des références croisées entre les
spécifications de plusieurs versions du cahier des charges (parfois entre les
spécifications du cahier des charges et la conception du logiciel). Le traçage arrière
consiste à pouvoir, à partir d'une spécification, retrouver la spécification dont elle
découle (dans la version précédente du cahier des charges). Le traçage avant
consiste, à partir d'une spécification, à trouver les spécifications auxquelles elle a
donné naissance (dans la version suivante);
utilisable durant la maintenance : Le cahier des charges devrait tenter de prévoir

certaines évolutions du logiciel.
Voici pour finir un énoncé des objectifs d'un cahier des charges [Heninger 80]. Un
cahier des charges devrait:
 spécifier uniquement le comportement externe du logiciel, sans faire

référence à aucune implémentation. Une spécification exprimée en terme
d'implémentation réduit inutilement la liberté de l'implémenteur;
 spécifier les contraintes d'implémentation (système d'exploitation sur lequel
doit tourner le logiciel, interfaces imposées au logiciel dans le cas de
logiciels temps réel, etc.);
 être facile à modifier (qualificatif "modifiable" ci-dessus);
 servir de document de référence. Toute réponse à une question précise
concernant le logiciel devrait pouvoir être trouvée dans le cahier des charges;
 contenir des prévisions sur l'évolution future du logiciel: quelles sont les
modifications susceptibles de survenir, quelles fonctions devraient être
faciles à ajouter ou supprimer ?
 définir les réponses acceptables à des événements non désirés (qualificatif
"complet" ci-dessus).
2. Modèle conceptuel du logiciel
Le modèle conceptuel donne une première vue d'ensemble du logiciel à réaliser

(rappel: M est un modèle de A si M peut être utilisé pour répondre à des questions
concernant A). Le modèle conceptuel du logiciel est avantageusement présenté
grâce à un diagramme de flot de données (DFD). Un DFD se compose des éléments
suivants [DeMarco 78, p 40]:
 des flèches, qui représentent le chemin des données;
Page 16
 des cercles, généralement appelés bulles, représentant les endroits ou les

données sont transformées: les processus;
 des doubles traits qui représentent des fichiers ou des bases de données:
les magasins ou dépôts;
 des rectangles qui représentent soit des sources de données (origine des
données), soit des puits de données (destination finale des données).
La symbolique SA proposée par DeMarco, augmentée par Hatley et Pirbhai

(Diagrammes de flots de contrôle) a été utilisée comme base par Ward & Mellor
pour . Les modifications et compléments apportés par Ward & Mellor en 1984
permettant la modélisation des systèmes temps réel sont:
 Spécialisation des flots de données:
Flot continu de données : données continuellement présentes dans un

intervalle de temps donné
Flot discret de données : données présentes à des instants spécifiques
 Les Processus sont considérés en tant que Transformation de données ou

transformation d'évènements
 Ajouts:
des flots d'évènements : Équivalent à un signal: pas d'information

intrinsèque.
déclanchement sur demande : avec déclencher (Trigger) et autoriser-
inhiber (Enable-Disable)
Processus de contrôle = Transformation des évènements modélisé par des

AFD
Dépôts d'évènements : agissant comme un sémaphore (Dijktra)
La présentation du modèle conceptuel ne se limite pas forcément uniquement à une

description du flot de données. Dans les logiciels où les données manipulées sont
structurées, il est nécessaire de modéliser ces données, en utilisant par exemple le
modèle entité-association, ou le modèle relationnel. D'autre part, il peut être
certaines fois judicieux de modéliser le logiciel à l'aide d'un automate d'états finis,
ou de tout autre notation qui peut se révéler adaptée au logiciel particulier à
concevoir.
Page 17
3. Spécifications fonctionnelles
Lors de l'écriture du cahier des charges, il est recommandé de séparer les

spécifications fonctionnelles des spécifications non-fonctionnelles.
Les spécifications fonctionnelles décrivent les fonctions (ou les opérations, ou

encore les transformations) que le logiciel doit réaliser. Chaque fonction sera
décrite en détail, en spécifiant ses entrées et ses sorties. Il est important ici de ne
pas oublier de spécifier les valeurs légales pour les entrées, ainsi que le
comportement du programme pour les entrées illégales. Ne pas oublier non plus de
spécifier le comportement du logiciel en cas de problèmes avec le matériel (par
exemple, panne de périphérique, panne du processeur qui peut avoir des
conséquences sur la cohérence d'informations stockées sur un fichier, etc.).
Toutes ces spécifications ne doivent décrire que le comportement externe du

logiciel.
4. Spécifications non fonctionnelles
Les spécifications non-fonctionnelles sont toutes les spécifications qui n'expriment

pas une fonction du logiciel. Ces spécifications, qui expriment des contraintes, sont
essentiellement de deux types:
 les contraintes d'interface. On peut distinguer ici les contraintes imposées par
l'environnement logiciel (par exemple: le programme doit s'exécuter sur tel
système d'exploitation), par l'environnement matériel (par exemple: le
programme doit utiliser les caractéristiques de tel terminal) ou par
l'environnement humain (par exemple: les commandes mises à disposition
doivent satisfaire telle ou telle contrainte);
 les contraintes de performance. Il s'agit par exemple de contraintes de
mémoire (mémoire principale ou disque), de temps de réponse, des
contraintes de sécurité, etc.
5. Formulation des spécifications
Les spécifications s'énoncent habituellement en langue naturelle, dans des

paragraphes numérotés (ce qui permet d'y faire référence). La langue naturelle
présente bien entendu des risques d'ambiguïté et ne permet pas de faire des
vérifications de consistance. Ces risques ne sont toutefois pas trop graves dans le
cas d'un projet modeste. Remarquons également que dans le cas d'un
développement dans un domaine neuf, il est souvent impossible d'énoncer les
spécifications (qui sont inévitablement imprécises) autrement qu'en langue
naturelle.
Page 18
Voici à titre d'exemple, quelques spécifications tirées du cahier des charges pour
l'environnement de programmation de Ada (cahier des charges baptisé
STONEMAN);
4.C.1 Une interface virtuelle, indépendante de toute machine hôte, doit être fournie
pour communiquer avec l'APSE (Ada Programming Support Environment).
4.C.2 L'interface virtuelle doit être basée sur des concepts simples, évidents à
comprendre et à utiliser, et peu nombreux.
...
4.C.8 Toutes les communications entre l'utilisateur et l'APSE doivent pouvoir

s'exprimer en utilisant le jeu de caractères standard de Ada.
Ces spécifications appellent les remarques suivantes [Sommerville 82, p 16]:
 la spécification 4.C.1 est une spécification fonctionnelle. Elle décrit de

manière imprécise (la portabilité est souvent difficile à exprimer de façon
formelle) une fonction, à savoir une interface virtuelle, qui doit être fournie
par le logiciel;
 la spécification 4.C.8 est une spécification non-fonctionnelle;
 la spécification 4.C.2 est une spécification non vérifiable (cf. section 2.1),
difficile à classer (fonctionnelle, non-fonctionnelle ?), qui n'apporte pas
grand chose;
 les spécifications fonctionnelles et non-fonctionnelles ne sont pas clairement
séparées.
Suivent quelques spécifications fonctionnelles et non-fonctionnelles pour le

programme de vérification de fautes de frappe [Wiener 84, p 20]:
Spécifications fonctionnelles
1. Lorsqu'un mot non identifié est rencontré dans le texte, l'utilisateur doit avoir le
choix entre remplacer le mot par un mot de substitution, insérer le mot dans le
dictionnaire, rechercher des mots similaires dans le dictionnaire afin d'en
déterminer l'orthographe correcte, ou sortir du programme.
2. Toute la ligne contenant l'éventuel mot mal écrit doit être affichée au terminal.
3. L'utilisateur doit avoir la possibilité d'afficher les mots du dictionnaire qui

débutent par une chaîne de caractères indiquée.
...
Page 19
6. Le programme ne doit pas s'arrêter lorsque le dictionnaire est plein.
...
10. Chaque fois que c'est possible, les données entrées par l'utilisateur doivent être
vérifiées, et en cas d'erreur, le programme affichera un message approprié.
Spécifications non-fonctionnelles
11. Le dictionnaire doit être capable de contenir au moins 40'000 mots. Des
techniques de compression sont acceptables.
12. Le logiciel doit être capable de traiter 250 mots à la minute.
13. Un mot est une chaîne d'un ou plusieurs caractères délimités par des caractères
ne faisant pas partie d'un mot. Les caractères qui font partie d'un mot sont les lettres
majuscules et minuscules (sans distinction entre elles) et les apostrophes.
14. Les méthodes internes de tri et de recherches ne sont pas critiques dans la
définition du système. Les méthodes doivent être efficaces du point de vue du
temps de calcul et utiliser un minimum de mémoire.
...
16. Le dictionnaire doit pouvoir être contenu sur une disquette de 5 1/4 pouces
double-face, d'une capacité de 400'000 octets.
17. Les mots jusqu'à au moins 13 caractères doivent être analysés pour vérifier s'ils
sont écrits correctement. Les mots plus longs doivent pouvoir être affichés au
terminal, afin de permettre à l'utilisateur d'en vérifier l'écriture.
...
20. Les commandes du programme doivent être présentées sous forme de menu
clair et concis.
Ces spécifications appellent également quelques remarques.
 la spécification no. 10 est vague. Une information plus précise peut toute
fois éventuellement être trouvée dans le manuel de l'utilisateur préliminaire
joint au cahier des charges;
 la remarque concernant la compression du dictionnaire (spécification no. 11
) ne semble pas à sa place: la décision de compression doit être un choix
d'implémentation;
Page 20
 la première partie de la spécification no. 14 n'est pas claire: la deuxième

partie n'est pas vérifiable;
 les adjectifs "clair" et "concis" de la spécification no. 20 en font une
spécification non vérifiable;
 la spécification no. 11 apporte-t-elle vraiment quelque chose par rapport à la
spécification no. 16 ? Que faire si une disquette de 400'000 octets est pleine,
alors que le dictionnaire contient moins de 40'000 mots ?
6. Plan pour un cahier des charges
Le cahier des charges, qui est souvent un document volumineux, se doit de

respecter une certaine structure. Voici celle proposée par A. Schiper (voir
également I. Sommerville, Le génie logiciel 1992 ch 3 p 48):
1. Introduction : L'introduction présente le logiciel à réaliser en terme de besoins

(à quoi va servir le logiciel), et décrit brièvement ses fonctions principales.
L'introduction permet également de présenter les éventuelles notations utilisées
dans la suite du document ainsi que le plan de ce même document.
2. Matériel : Cette section permet de décrire le matériel particulier utilisé (par

exemple certains périphériques), ainsi que les interfaces.
3. Modèle conceptuel : Le modèle conceptuel donne une vue d'ensemble du

logiciel à réaliser.
4. Besoins fonctionnels : functional requirements.
Les spécifications fonctionnelles décrivent les fonctions (ou les opérations, ou

encore les transformations) que le logiciel doit réaliser.
5. Besoins non fonctionnels : non functional requirements.
Les spécifications non fonctionnelles sont toutes les spécifications qui n'expriment
pas une fonction du logiciel. Ces spécifications expriment des contraintes.
6. Sous ensemble et priorités d'implémentation : Cette section permet de définir

d'éventuelles versions particulières du logiciel, versions correspondant à des sous-
ensembles des spécifications décrites aux points 3, 4 et 5. Avoir rapidement
certaines parties du logiciel opérationnelles peut être utile. Cette section permet,
entre autre, de préciser un ordre de réalisation.
Page 21
7. Information de maintenance : Il se peut que, une fois le logiciel opérationnel,

certaines parties soient davantage susceptibles d'évoluer que d'autres (évolution du
matériel, changement des besoins des utilisateurs, etc). L'indiquer dans le cahier
des charges permet de construire le logiciel de manière à faciliter son évolution.
8. Glossaire : Le glossaire contient la définition des termes techniques utilisés dans

le cahier des charges. Il ne faut supposer aucune connaissance technique
particulière de la part du client auquel est destiné le cahier des charges.
9. Index : L'index doit permettre une utilisation facile du cahier des charges. Il est
judicieux de faire ressortir graphiquement (par exemple par une mise en caractères
gras) les références importantes à un terme, sa définition par exemple.
Il est en plus conseillé de joindre au cahier des charges une version préliminaire du
manuel de l'utilisateur. Le manuel de l'utilisateur permet souvent au client de
vérifier que le produit qui va être construit correspond à l'idée qui était faite. Le
mode d'emploi permet également de régler dans le détail le comportement du
logiciel dans le cas de l'entrée de données ou de commandes non correctes.
Page 22
Chapitre 4 Concevoir un logiciel DSI4 & MDW4
Chapitre 4
Concevoir un logiciel
La conception est un processus créatif qui nécessite de l'expérience que l'on

acquiert essentiellement par la pratique ainsi que par l'étude de systèmes existants.
La clef d'une démarche ingénierie réussie, c'est une bonne conception, mais il est
impossible de formaliser le processus de conception, quelle qu'en soit, d’ailleurs, la
discipline.
Ce document présente une introduction à la conception du logiciel traitant du

processus, des stratégies et de la qualité de la démarche de conception.
1. Concevoir un logiciel
Concevoir un logiciel est un processus créatif qui demande du savoir faire ainsi que
de la perspicacité. Une conception finale est généralement obtenue par un processus
itératif à partir de conceptions préliminaires. Concevoir un logiciel ne s'apprend pas
dans un livre, mais par la pratique et l'étude de systèmes existants ainsi que par
l'expérience. Une bonne conception est la clé d'un développement de logiciel
efficace. Un système bien conçu est facile à réaliser et à maintenir, facile à
comprendre et fiable, il est de qualité. Bien qu'il puisse fonctionner correctement,
un système mal conçu sera souvent coûteux à maintenir, difficile à tester et peu
fiable. La phase de conception est donc la phase la plus cruciale du processus de
développement d'un logiciel.
La conception d'un logiciel peut être divisée en plusieurs étapes :
1. Étude et compréhension du problème. Sans cette compréhension, il est

impossible de faire une conception efficace du système. On doit examiner le
problème sous différents points de vue, car ces derniers donnent différents
éclairages quant aux besoins de la conception.
2. Identifier les principales caractéristiques d'au moins une solution possible. Il

est souvent utile d'examiner et d'évaluer plusieurs solutions différentes. Le
choix de la solution dépend de l'expérience du concepteur (un concepteur a
tendance à choisir une solution qui lui est familière et bien comprise, dès lors
qu'il en existe une). Il dépend aussi de la disponibilité de composants
réutilisables, et de la simplicité des solutions qui en découleront. Une bonne
heuristique consiste à choisir la solution la plus simple lorsque tous les
facteurs sont égaux.
Page 23
3. Décrire toutes les abstractions utilisées dans la solution. Toutefois, avant de

créer une documentation formelle, le concepteur peut éprouver la nécessité
de créer une description informelle de la conception, et de mettre cette
dernière au point en la développant plus en détail. On peut ainsi corriger
avant même que la conception soit documentée, les erreurs et les oublis de
haut niveau découverts lors de la conception de bas nivOn répète ce
processus de résolution de problème pour chacune des abstractions
identifiées lors de la conception initiale, et le processus d'affinement
continue jusqu'à ce que l'on soit en mesure de préparer une spécification de
la conception de chacune de ces abstractions. Le problème est de savoir
quand arrêter ce processus de décomposition. On dit souvent qu'il faut
arrêter lorsque la conception d'un composant tient sur une seule feuille de
papier.
La phase de conception logicielle peut être décomposée en conception

architecturale et conception détaillée.
La conception architecturale a pour objectif de définir la structure interne du

logiciel, c'est à dire de le décomposer en composants de taille maîtrisable par un
individu et de définir les interfaces ainsi que les interactions entre composants.
La conception détaillée définit de manière précise le rôle de chacun des composants

du logiciel pour en permettre l'implémentation ultérieure sans ambiguïté.
2. Démarche de conception
Le concepteur part d'une analyse préalable des besoins pour établir un système qui
satisfasse à ces dits besoins. Cette dérivation s'accomplit généralement en suivant
les étapes suivantes et est dite conception descendante:
 identification des sous-systèmes constituant le logiciel

 décomposition de chaque sous-système en un certain nombre de composants,
la spécification de ces sous-systèmes consistant en la définition les
opérations des dits composants.
 chaque unité exécutable est alors conçue en termes de composants en
interaction.
 décomposition de chaque composant dans une hiérarchie de sous-
composants.
Page 24
 à un certain stade de ce processus, les algorithmes utilisés dans chaque

composant sont détaillés.
De plus, l'ingénieur logiciel sera très souvent amené à concevoir des mécanismes
de communication entre les divers processus du système, des structures de fichiers
et des structures de données manipulées par ces programmes.
Dans une démarche de conception ascendante, les composants de niveaux

inférieurs sont d'abord définis, puis ces composants sont utilisés pour réaliser ceux
du niveaux au dessus jusqu'à arriver au niveau supérieur ou ce trouve le composant
principal.
Il est important de considérer ces deux démarches de conception (ascendante et

descendante) en rapport avec les modèles de développement. Par exemple le
modèle de développement par incrément va plutôt utiliser une démarche de
conception ascendante alors que le modèle en V mettra en oeuvre typiquement une
approche descendante.
3. Cohésion
La cohésion d'un composant permet de mesurer la qualité de sa structuration. De

façon idéale, un composant devrait implémenter une seule fonction logique ou une
seule entité logique sachant que toutes les parties du composant doivent contribuer
à cette implémentation. Si un composant comporte des parties qui ne sont pas
directement relatives à sa fonction logique (par exemple si c'est un groupe
d'opérations n'ayant rien à voir, mais qui sont effectuées en même temps), ce
composant n'a qu'un faible degré de cohésion.
Constantine et Yourdon identifient en 1979 sept niveaux de cohésion présentés ci-

après du plus fort au plus faible:
1. la cohésion fonctionnelle où chaque élément est nécessaire à une seule fonction.

C'est ce type de cohérion qui doit être recherché;
2. la cohésion séquentielle dans laquelle la sortie d'un élément est utilisée en entrée
d'un autre;
3. la cohésion de communication pour laquelle tous les éléments d'un composant

travaillent sur les mêmes données en entrée et produisent les même données en
sortie;
4. la cohésion procédurale où les éléments d'un composant constituent une seule

séquence de contrôle;
Page 25
5. la cohésion temporelle regroupant dans un même composant tous les éléments

activés au même moment comme par exemple à l'initialisation d'un programme ou
encore en fin d'exécution;
6. la cohésion logique pour laquelle tous les éléments du composant effectuent des
opérations semblables comme la prise en compte ou le traitement d'erreurs;
7. la cohésion par coïncidence où il n'y a pas de relation entre les éléments du

composant qui sont simplement rassemblés là.
Ces classes de cohésion ne sont pas définies de manière stricte et Constantine et

Yourdon illustrent chacune d'entre elles par un exemple. Il n'est pas toujours facile
de décider à quelle catégorie de cohésion appartient une unité.
La méthode de Constantine et Yourdon est, de part sa nature, fonctionnelle. Et il est

évident que l'unité de plus grande cohésion est la fonction. Toutefois, les systèmes
orientés objet se caractérisent eux aussi par un haut degré de cohésion. En effet,
l'un des principaux avantages de cette approche de la conception provient du fait
que les objets qui constituent le système sont naturellement cohésifs.
Dans un objet cohésif, on représente une seule entité, et toutes les opérations
associées à cette entité font partie de cet objet. Par exemple, un objet représentant la
table des symboles d'un compilateur est cohésif si toutes les fonctions telles
que Ajouter un symbole, Chercher dans la table, etc., font partie de l'objet table des symboles.
Ainsi, on peut définir une classe supplémentaire de cohésion de la manière

suivante:
Cohésion d’objet. Chaque opération offre une fonctionnalité basée sur la

modification, l'inspection ou l'utilisation des attributs de l'objet.
La cohésion est une caractéristique hautement désirable. Elle signifie que chaque
composant ne représente qu'une partie de la résolution du problème. S'il s'avérait
nécessaire de modifier le système, alors cette partie étant très localisée et tout ce
qui çi rapporte étant encapsulé dans une seule unité, il n'y a pas besoin de modifier
les autres composants.
Si l'on implémente une fonctionnalité à l'aide d'un système à objets basé sur
l'héritage, on diminue fortement la cohésion d'un objet héritant d'attributs et
opérations de ses super classes. Il n'est, dès lors, plus possible de considérer un
objet comme une entité séparée et l'on doit aborder tout l'héritage pour comprendre
réellement ses fonctionnalités.
Page 26
4. Couplage
Le couplage est relatif à la cohésion. C'est une indication de la force

d'interconnexion des différents composants d'un système. Les systèmes fortement
couplés ont des interconnexions fortes, avec des unités de programme dépendant
les unes des autres. Les systèmes faiblement couplés sont constitués d'unités
indépendantes ou presque indépendantes
En règle générale, les composants sont fortement couplés lorsqu'ils utilisent des
variables partagées ou lorqu'ils échangent des informations de contrôle.
La conception par objets à, peut-être pour principal avantage d'obtenir des systèmes
faiblement couplés. Dans une conception objet, il est fondamental que la
représentation d'un objet soit dissimulée à l'intérieur et donc ne soit pas visible de
l'extérieur. Il n'y a pas partage de l'état du système et n'importe quel objet peut être
remplacé par un autre ayant la même interface.
Néanmoins, dans les systèmes à objets, l'héritage entraîne d'autres formes de

couplage. En effet, les objets qui héritent d'attributs et d'opérations sont fortement
couplés avec leurs parents (super classes). Ceci implique qu'il être prudent lorsque
l'on modifie une super classe, du fait que ces changements sont partagés par toutes
les classes héritant de ses caractéristiques. En fait ici, on est ramené à un problème
classique de cohésion de communication.
5. Qualité d'une conception
Il n'existe pas de critère définitif permettant de définir une bonne conception.

Suivant le type d'application et les besoins spécifiques du projet, le critère décisif
peut être l'efficacité du code produit, sa compacité ou la maintenabilité du produit.
Ce denier critère est celui que nous adopterons ici. Une bonne conception facilite la
maintenance et le coût des changements à apporter au système est minimal. Cela
signifie, en particulier, que la conception initiale doit être facile à comprendre et
que l'effet des changements doit rester localisé. Il est possible d'atteindre ces
objectifs lorsque la conception apporte à la fois un haut degré de cohésion et
un couplage faible.
On dit qu'un composant fait preuve d'un haut degré de cohésion si les éléments le
constituant remplissent des fonctions très proches. Cela signifie que chaque
élément de cette unité doit être essentiel pour que cette unité remplisse son rôle.
Des éléments qui sont regroupés dans une même unité pour quelque autre raison,
par exemple parce qu'ils s'exécutent en même temps, ont un faible degré de
cohésion.
Page 27
Le couplage est lié à la cohésion. C'est une indication de la force des connexions
entre unités. Des systèmes à couplage fort ont des connexions fortes entre des
unités qui dépendent les unes des autres, alors que des systèmes à couplage faible
sont constitués d'unités qui sont indépendantes ou presque.
L'avantage des systèmes à forte cohésion et à couplage faible est qu'il est possible
de remplacer un composant quelconque par un composant équivalent avec peu ou
pas de changement dans les autres parties du système. Ceci est également important
pendant le processus de conception. Avec un système à couplage faible, le
concepteur a l'option de changer d'avis en ce qui concerne un composant sans
provoquer des conséquences désastreuses pour le reste du logiciel.
6. Stratégie de conception
Jusqu'à une date relativement récente, on concevait la plupart des systèmes

informatiques en se basant sur une stratégie de division de la conception en
composants fonctionnels partageant une zone de données commune dans laquelle
se trouvaient toutes les informations concernant l'état du système. Bien que Parnas
(1972) est proposé une autre stratégie au début des années 70 et qu'il existait déjà
des versions de Smalltalk, ce n'est que depuis le milieu des années 80, que cette
autre approche, la conception/programmation par objets, à été largement adoptée.
Il est possible de résumer les deux stratégies de conception de la façon suivante:
La conception fonctionnelle
(Approche par les traitements) Le système est conçu d'un point de vue
fonctionnel, en partant d'une vue de haut niveau, affinée successivement afin
d'obtenir une conception plus détaillée. L'état du système est centralisé et
partagé par les fonctions qui agissent sur cet état. On trouve des exemples de
cette stratégie dans la conception structurée (Constantine et Yourdon, 1979)
et «l'affinement à pas prudents» (Wirth, 1971, 1976). Les méthodes telles
que la programmation structurée Jackson (Jackson, 1975) ou la méthode
Warnier-Orr (Warnier, 1977) sont des techniques de décomposition
fonctionnelle où l'on se base sur les structures de données pour déterminer
les structures fonctionnelles qui traiteront ces données.
La conception orientée objet
Le système est vu comme un ensemble d'objets, plutôt que comme un

ensemble de fonctions. L'état du système est décentralisé, et chaque objet
gère l'information concernant son propre état. Les objets disposent d'un
ensemble d'attributs définissant leur état, et d'opérations permettant d'agir sur
Page 28
ces attributs. La plupart du temps, les objets sont membres d'une classe
d'objets dont la définition détermine les opérations et les attributs dont
disposeront les membres de la classe. Ceux-ci peuvent être hérités d'une ou
de plusieurs super-classes si bien que la définition d'une classe revient à
définir les différences entre cette classe et ses super-classes. D'un point de
vue conceptuel, les objets communiquent en échangeant des messages. En
pratique, la communication entre objet est réalisée par l'appel, depuis un
objet, d'une procédure associée à un autre objet.
La conception orientée objet est basée sur l'idée de dissimulation de l'information

(Parnas, 1972), elle a été décrite par Meyer (1988) et Booch (1991). La méthode
JSD (Jackson, 1983) se situe quelque part entre la conception orientée fonction et la
conception orientée objet.
La décomposition fonctionnelle du haut vers le bas a été largement utilisée aussi

bien dans de petits projets que dans de très grands, et dans divers domaines
d'application.
La méthode orientée objet a eu un développement plus récent. Elle encourage la

production de systèmes divisés en composants indépendants, en interaction.
On peut également mentionner les conceptions guidées par les données. Ces
dernières s'appliquent essentiellement à certains problèmes d'utilisation de grandes
bases de données.
Page 29

Rappel Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Rappel Genie Logiciel

Transféré par

Informations du document

Description originale:

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

Rappel Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 1 Principes du génie logiciel DSI4 & MDW4

Principes du génie logiciel

Les facteurs de cette crise (d’après une étude de Standish group) :

Facteurs d’échec Pourcentage

L’écart entre les souhaits et les réalisations :

1. Ce que la direction demande

2. Ce que demande le chef de projet

3. Ce qui est conçu

4. Ce qui est programmé

5. Ce qui est installé

6. Ce que l’utilisateur souhaitait

2.3. Génie logiciel

En résumé, nous dirons que :

Le génie logiciel est l’art de bien faire de bons

3. Qu’est ce qu’un bon programme ?

Point de vue Point de vue

On parle alors de critères de qualité de logiciel.

Un bon programme pour l’utilisateur :

Facilité d'installation / utilisation / mise à jour :

Un bon programme pour le programmeur :

– facile à comprendre : structuration, commentaires, documentation, ...

Un bon programme pour le fournisseur :

- Coût réduit de développement + maintenance

Modélisation, cycles de vie et méthodes

1. Pourquoi et comment modéliser ?

1.1. Qu’est-ce qu’un modèle ?

2. Le cycle de vie d’un logiciel

3. Modèles de cycles de vie d’un logiciel

Figure 1.1 : Modèle du cycle de vie en cascade

3.2. Modèle de cycle de vie en V

Figure 1.2: Modèle du cycle de vie en V

Figure 1.3: Modèle du cycle de vie en Spirale

3.4. Modèle par incrément

Figure 1.4: Modèle du cycle de vie par incrément

4. Méthodes d’analyse et de conception

La distinction entre composition et décomposition :

descendantes qui décomposent récursivement le système jusqu’à arriver à des modules

Spécification des besoins

Le produit de la phase de définition/spécification des besoins est le cahier des

1. Spécification des besoins

Réaliser un logiciel de détection de fautes de frappes (spelling checker), à utiliser

complet : On oublie facilement de préciser dans un cahier des charges le

modifiable : Les spécifications peuvent changer soit durant le développement du

utilisable durant la maintenance : Le cahier des charges devrait tenter de prévoir

 spécifier uniquement le comportement externe du logiciel, sans faire

2. Modèle conceptuel du logiciel

Le modèle conceptuel donne une première vue d'ensemble du logiciel à réaliser

 des flèches, qui représentent le chemin des données;

 des cercles, généralement appelés bulles, représentant les endroits ou les

La symbolique SA proposée par DeMarco, augmentée par Hatley et Pirbhai

 Spécialisation des flots de données:

Flot continu de données : données continuellement présentes dans un

 Les Processus sont considérés en tant que Transformation de données ou

des flots d'évènements : Équivalent à un signal: pas d'information

Processus de contrôle = Transformation des évènements modélisé par des

Dépôts d'évènements : agissant comme un sémaphore (Dijktra)

La présentation du modèle conceptuel ne se limite pas forcément uniquement à une

Lors de l'écriture du cahier des charges, il est recommandé de séparer les

Les spécifications fonctionnelles décrivent les fonctions (ou les opérations, ou