1 LE GENIE LOGICIEL 1

Software Engineering

1. INTRODUCTION
1) GENERALITES
Historique
Réunion du comité scientifique de l'Organisation du Traité de l'Atlantique Nord (à Garmich, RF A 1968)
avec quelques-uns des plus grands spécialistes mondiaux de la programmation. L'objectif est d'étudier
les causes de ce que l'on commençait à appeler la crise du logiciel.
Les symptômes de la crise
- Problème d'Adéquation: les systèmes informatisés ne correspondent pas souvent aux besoins des
utilisateurs.
- Problème de Fiabilité : les systèmes tombent souvent en panne.
- Problème de Modifiabilité : la maintenance est souvent complexe et coûteuse. Il était difficile d'adapter
les logiciels pour prendre en considération l'évolution des environnements et des besoins des utilisateurs.
-Coût et délai : budgets dépassés, projets en retard. Le coût du logiciel est devenu supérieur à celui du
matériel: 500/0-50% en 1965, 700/0-30% en 1975, 800/0-20% en 1985. Les coûts résultent généralement des
frais de maintenance qui découlent de la qualité déficiente du logiciel au moment de sa livraison ou après
son évolution.
- Interface utilisateur inappropriée.

Enfin les causes sont nombreuses et parmi les plus importantes: le caractère rudimentaire des méthodes et
outils utilisés dans le développement de logiciels.
Moralité
Faire de la production de logiciel une discipline d'ingénieur à part entière, avec une solide base
scientifique ( comme dans les autres disciplines telles que le génie civil ou le génie chimique etc ...). D'où
le titre : génie logiciel.
Défmition du Génie logiciel
Ensemble de méthodes, techniques et outils nécessaires à la production de logiciels de qualité.
=:}Plus précisément, le génie logiciel vise à satisfaire:
- Les utilisateurs : en produisant des logiciels adaptés aux besoins.
- Les gestionnaires : en réduisant le coût de production et de maintenance.
- Les chefs de projet : en rendant les logiciels productifs dans un délai
raisonnable.

Comment y parvenir
~ Améliorer la démarche de développement: Appliquer et faites appliquer les méthodes d'analyse,
de conception (SADT, JACKSON, RaaD, MERlSE, ...), dans le développement de logiciels.
~ Améliorer les langages : On peut programmer mal dans un bon langage , et assez bien dans un
mauvais, Mais il est plus facile de bien programmer avec un bon langage. Il est important de
connaître les nouveaux concepts des langages modernes (modularité, abstraction, généricité,
héritage ..) même si l'on ne peut pas toujours les employer en pratique.
~ Utiliser des outils d'aide au développement:
Les environnements de programmation: éditeur syntaxique, outils de tests, ...

1 /GL: lntro+cycle de vie A.KOUKAM

 Les ateliers de génie logiciel: outils d'aide au spécification, gestionnaire de configuration,
gestionnaire de projets, .....
~ Décomposer le développement en plusieurs étapes: Suivre le cycle de vie du logiciel (c'est la
suite du cours ).

2) LE CYCLE DE VIE DU LOGICIEL

Qu'appelle t'on logiciel?-
L'organisation internationale de normalisation (ISO) a défini en 1981 le logiciel (software) comme une
création intellectuelle rassemblant:
~ des programmes permettant de faire fonctionner un ordinateur et de l'utiliser pour résoudre des
problèmes,
~ la documentation servant à concevoir, réaliser, utiliser et modifier ces programmes.
Cycle de vie du logiciel
Il défmit l'ensemble des étapes qui composent le processus de développement et d'utilisation du logiciel.
Modèle du cycle de vie
Modélisation conventionnelle de la succession d'étapes qui préside à la mise en oeuvre d'un produit
logiciel. Il s'agit de décrire et de représenter les étapes du cycle de vie et leurs relations. Ainsi plusieurs
modèles ont été proposés: la cascade (Waterfall model), cycle en V, modèle en spiral, Ces modèles
partagent pratiquement les mêmes étapes mais diffèrent sur la mnière des les organiser, d'integrer les
autres facteurs du développement (les risques, les utilisateurs, .... )
Nous présentons ci-dessous le modèle en V. Les étapes seront décrites dans le paragraphe suivant.

BESOINS
REELS

\
\ \ / /
SPECIFICATION •• • VALIDATION

G \\ \ CONCEPTION
GENERALE •• •
IIITESTS
D'INTEGRATION

G \\\ / 1/
CONCEPTION TESTS

G
DETAILLEE •• • UNITAIRES

\R~:/
\'----------'/

2 /GL: Intro+cycle de vie A.KOUKAM

En correspondance de chaque étape de la construction est associé une phase de
contrôle de conformité. Par exemple: spécification<---------------->validation.

Pourquoi de tels modèles?

Un modèle est une référence pour les personnes impliquées dans le développement d'un logiciel. En effet,
un modèle:

- Permet de représenter le processus de développement de manière graphique et physique,

- Donne une structure autour de laquelle les activités d'assurance qualité peuvent être construites de
manière utile et disciplinée,
- Fournit un repère pour les acteurs d'un projet logiciel

II. LES ETAPES DU CYCLE DE VIE

Dans cette partie, nous précisons les objectifs de chaque étape du cycle de vie.

1. L'ETUDE PREALABLE
1.1 Définition
BUTS:
- Préciser l'objet du système: Comprendre les besoins et les enjeux,
- Dialoguer avec les différents types d'utilisateurs
- Esquisser des solutions
- Estimer les coûts et délais
- Préparer un dossier en vue de décision
Peut se faire avec l'assistance d'une société de conseil ou d'ingénierie

RESULTATS:
- Décision de développement.
- 1ère version du contrat de développement, 1ère estimation du coût de développement.
- Cahier des charges, Mode de fonctionnement grossier du système.
- Plan général du projet.
MOYENS:
- Plan d'entretien avec le client (techniques d'entretien).
- Certaines méthodes MERISE, AXIAL ....
- Revue pour valider et approuver les propositions exhibées.

1.2 Cahier des charges

- Résultat des études préalables menées, directement ou indirectement par le maître d'ouvrage.
- Bases de l'appel d'offre ou de la consultation.
- Doit donner tous les éléments nécessaires pour permettre au maître d'oeuvre d'élaborer et chiffrer
des solutions.
- Doit rester strictement au niveau de l'expression du besoin et des exigences fonctionnelles, sans
imposer le choix de conception:
- permettre aux soumissionnaires de faire dans leur contexte la meilleure offre
- bénéficier de leurs éventuelles solutions innovantes.

1.3. Organisation du cahier des charges

- Les clauses techniques
-> Fonctionnalités du logiciel à réaliser: exprime le besoin de l'utilisateur en décrivant de manière
complète et non ambiguë les fonctionnalités du logiciel à réaliser.

3 /GL: Intro+cycle de vie A.KOUKAM

 -> Contraintes à prendre en compte.
- Les clauses de qualité
Obligations du fournisseur en assurance & contrôle qualité pendant le déroulement du projet.
- Les ela uses générales
Dispositions: juridiques, financières, commerciales auxquelles la proposition du fournisseur
devra se conformer

2. LA SPECIFICATION (Requirements phase, analysis phase)

BUTS: Définir le "quoi"

-> Obtenir une description précise et sans ambiguïté du système logiciel - Support pour la validation
-> Défmir la portée et les objectifs du projet de manière précise.

- Pour le Produit logiciel, définir: les performarces requises, les fonctions du logiciel, les objets du
monde réel manipulés, les interfaces du logiciel avec son environnement, lesentrées et sorties.
- Pour le Projet, définir: les ressources, les contraintes de réalisation.

RESULTATS:
Manuel d'utilisation, Document de spécification (spécification détaillée des besoins).
Plan détaillé du reste du projet, Raffmage de l'estimation des coûts.

MOYENS:
Méthodes, outils, langages de spécification Exemple: SADr, SREM, OOA..
Revues de spécification. Techniques de planification.

Qualités d'une Spécification

1. Fidélité: reflète correctement le besoin
2. Complétude: couvre complètement et exclusivement l'ensemble des besoins
3. Cohérence (non contradiction) : les compromis doivent être mis en évidence
4. Lisibilité : sert de vecteur de communication
5. Indépendance: par rapport aux choix d'implémentation

3. LA CONCEPTION GENERALE (Preliminary design or architectural design)

BUTS: Décrire l'architecture du logiciel
- Obtenir une décomposition du système en un ensemble de modules
- Obtenir une description précise du rôle de chaque module.
- Vérifier la faisabilité et la traceabilité vers les spécification :trace (lien) entre les fonctions du
système et les modules logiciels.
RESULTATS
-> Document de conception: description de la structure modulaire du système - Définition des
modules et des interfaces. Il faut conserver une trace entre les fonctions du système et le ou
les modules introduits.
-> Mise à jour du manuel d'utilisation
MOYENS
-> Méthodes, langages, outils de conception: RIPO, STRUCTURED DESIG ,JACKSON, ROOD.
-> Revues de conception.

4 /GL: Intro+cycle de vie A. KOUKAM

4. LA CONCEPTION DETAILLEE (Detailed design)
BUTS:
Obtenir une description détaillée des Modules, des traitements et des structures de données
permettant un codage immédiat.
RESULTATS:
Dossier de conception détaillée. Planification des tests unitaires.
Mise à jour: DS, MU
MOYENS:
"Pseudo-codes", outils (PDL).
Langages de programmation?
Revues de conception.
NOTE: Conception Detaillée = Programmation Abstraite.

5. LE CODAGE

BUTS:
Obtenir les programmes : traduire la conception détaillée dans un langage de programmation
en respectant les standards définis.
RESULTATS:
Programmes.
Documentation technique.
MOYENS:
Langages de programmation. Editeur s syntaxiques, ....
Revues de codes ("inspections").

6. LES TESTS UNITAIRES (Unit test phase)

BUTS:
Tester chaque module séparément: exécuter le corps du module et comparer son
comportement à un comportement de référence. Il faut élaborer un jeu de données de tests
pour chaque module.
(attention le test n'est pas une preuve).
RESULTATS:
Résultats des tests (+ rapport d'erreur).
MOYENS: Analyseurs statiques, tests dynamiques, outils de test.

7. INTEGRATION (Integration phase)

BUTS:
Recomposer le logiciel en modules à partir de ses composants.
Vérification des fonctionnalités et des performances du système complet.
Vérification du respect des normes de programmation.
Vérification de la documentation.
RESULTATS:
Système logiciel intégré.
Documentations internes et externes.

MOYENS:

5 /GL: Intro+cycle de vie A.KOUKAM

 Utilisation de jeux de tests.
Outils d'évaluation de performances.

8. VALIDATION
BUT:
Tester le logiciel dans des conditions représentatives de son utilisation opérationnelle. Valider le
logiciel par rapport à la spécification des besoins
RESULTATS:
Documents de validation. PV de qualification, rapport qualité- fiabilité
Programme certifié et installé.
MOYENS:
Utilisation de jeux de tests. Contrôle qualité

9. EXPLOITATION ET MAINTENANCE
Cette phase ne fait pas partie du projet proprement dit, mais à l'issue d'un développement, il
s'avère toujours que des modifications doivent être apportées au produit:

1Correction d'erreurs décelées au cours de l'exploitation,

1Modification du logiciel pour satisfaire de nouveaux besoins,
1Optimisation de certaines fonctions.

III. AUTRES MODELES DU CYCLE DE VIE

1. Modèle par prototypage (PROTOTYPING)

o Principe:

Produire rapidement une réalisation partielle du système avant de définir la spécification

complète des besoins
. Les utilisateurs éprouvent des difficultés à imaginer l'utilisation du système à partir des
spécifications seules
. Une fonction telle qu'elle est décrite dans une spécification risque d'apparaître sous un
nouveau jour lorsqu'on l'utilisera réellement en conjonction avec d'autres fonctionnalités.

o Objectifs :

Aider le client et les utilisateurs à définir de manière claire et precise les besoins en
expérimentant le prototype : Cas des systèmes complexes, nouveaux

o Approches:

- Prototype évolutif: Le prototype est conçu pour évoluer vers le système final.

Specincanon Réalisation du Evaluationdu Acceptation

~ ~ ~
partielle prototype prototype du système

• 1

6 /GL: Intro+cycJe de vie A.KOUKAM

 - Prototype "jetable" : Le prototype est abandonné une fois que l'analyse et la spécification
des besoins sont terminées.

o Etapes:

- Etablir les objectifs du prototype, par exemple:

- le prototype concerne principalement l'interface utilisateur.
- ou la validation dès besoins fonctionnels.
- ou la faisabilité du système.
- Développer une analyse préliminaire pour produire une spécification partielle des besoins
- ne choisir que les besoins les plus importants,
- négliger les problèmes du traitement des erreurs, de fiabilité et de qualité.
- Réaliser le prototype
- suivre le cycle de vie en minimisant les efforts :
documentation simplifiée (pas de document de conception, pas de plan, de test ..) ;
- utiliser des langages interprétés et interactifs: LISP, APL, Langage de spécification
exécutable ...
- Faire expérimenter le prototype par les utilisateurs et compléter l'analyse des besoins
: évaluation du prototype.
- Produire la spécification finale
- Développer le système

o Avantages

- L'expérimentation du prototype permet aux clients/utilisateurs de mieux comprendre leurs

besoins: une bonne base pour le dialogue clients + utilisateurs/Analyste.
- Le prototype peut aider à montrer la faisabilité et l'utilité de l'application (surtout pour les
dirigeants de l'entreprise).
- Possibilité de réutiliser l'expérience acquise par le développeur du prototype dans les autres
phases du développement.
- Le prototype sert de base pour spécifier le système [mal.

o Quelques difficultés
- Manque d'expérience en matière de planification et d'estimation de coût d'un projet
de prototypage.
- Le coût du prototypage peut représenter une fraction importante du coût total du
système! (c'est ce qu'on dit !)

2. Modèle transformationnel
Partant d'une spécification formelle (exprimée dans un langage fondée sur une théorie bien
définie), il s'agit d'appliquer un certain nombre de règles de transformation correcte pour dériver un
programme exécutable. Le programme est donc conforme à la spécification initiale. Ce modèle
reste encore très peu utilisé car il nécessite des connaissances sur les langages formels et pose aussi
le problème de l'élaboration de règles de transformation correctes.

3. Modèle de la spirale

Il s'agit d'une approche hautement itérative du développement. Au lieu de représenter les phases
du cycle chronologique séquentiellement, ce modèle représente le cycle de vie comme une spirale.
On commence par une phase de planification (au centre de la figure) pour recueillir assez

7 fGL: Intro+cycle de vie A.KOUKAM

d'information en vue de développer le premier prototype. Pour chaque prototype, le processus de
développement suit un chemin séquentiel: analyse, conception, la réalisation, les tests,
l'intégration aux composants existants du prototype et la planification du prototype suivant.

ème
Construction 3 prototype

Construction 1'" prototype

Planifier la
1ère itération

. Encore quelques définitions :

Méthodologie: fournit des lignes directrices pour la réalisation de chacune des activités du cycle
de vie, dont des modèles, outils et techniques spécifiques.

Modèle: est une représentation d'un aspect quelconque de la réalité ou d'un système. Il s'agit
d'une représentation abstraite pouvant être utilisée pour étudier un aspect d'un système donné. Par
exemple, un modèle de donnée d'un système représente uniquement les données du systèmes et
leurs relations. Il ne représente pas le comportement du système ni les traitements qu'il réalise. Ces
deux aspects peuvent être représentés par d'autres modèles.

Outils: support logiciel permettant d'aider à créer et exploiter les modèles et composantes
nécessaires au développement de logiciels. Par exemple, les éditeurs graphiques permettant de
créer des modèles objets, des modèles de traitement, ou des générateurs de codes.

8 /GL: Intro+cycJe de vie A.KOUKAM

 Les modèles de cycle de vie
~ Le modèle de développement par
prototypage :
• Consiste à explorer rapidement et à moindre frais
les fonctions, l'architecture et la convivialité d'un
logiciel.
• Efficace dans les projets où les besoins sont mal
définis.
• L'intérêt réside dans sa capacité à clarifier et à
compléter les spécifications et à déterminer les
caractéristiques souhaitées.
~ Possibilité d'essayer les Interface homme/machine
 ;-
A. koukam, Professeur des Universités à l'U1BM

ANALYSE ET SPECIFICATION
DES BESOINS
1ère Etape du cycle de vie

1. DEFINITION
C'est le processus visant à établir quelles fonctionnalités le système doit fournir et les contraintes
auxquelles il sera soumis. Repondre au quoi et non au comment?

2. OBJECTIFS
1 Comprendre la nature exacte du problème. Par l'analyste et par le client
1 Fournir un document compréhensible par le client et les concepteurs du système: Le fondement du
contrat
! Définir la base pour la validation des étapes ultérieures. La validation utilise la spécification comme
base pour répondre à la question principale suivante: A t'on conçu ce qui a été demandé?
1 Préciser les contraintes de réalisation.
1 Prendre des décision: Développer? Acheter? Louer? Sous -traiter?
1 Réduire les coûts de développement du système.

Une spécification rigoureuse des besoins permet d'éviter les oublis pouvant apparaître tardivement
dans le cycle de vie. En effet de tels oublis nécessitent des retours en arrière, ce qui augmente les coûts
de développement: Eviter l'oubli, les allers retours dans le cycle de vie

3. LES ETAPES
1 Analyse des besoins (Requirement Analysis) : Rassembler toutes les informations nécessaires à

la compréhension du problème
1 Spécification des besoins (Requirement Specification) : Spécifier de manière claire et précise le

résultat de l'analyse en utilisant des méthodes de modélisation (voire étape de spécification).

Nous allons d'abord préciser ce que nous qualifions de besoins en les classons en deux catégories.
Ensuite, nous donnons quelques éléments permettant d'aborder l'analyse puis la spécification.

Les éléments clés de l'analyse est de la spécification sont donc les besoins que l'on peut classer en
deux catégories :
» Besoins fonctionnels (exigences fonctionnelles): les services que l'utilisateur attend du
système. Il s'agit des activités que le système doit exécuter. Dans premier temps, ces besoins
peuvent être exprimés en langage naturel accompagné éventuellement de diagrammes
graphiques.
Exemple: le système de distribution automatique de billets de banque (DAB).
1 Le système doit vérifier la validité de la carte.
1 Le système doit mettre à jour le compte du client après un retrait ou un dépôt.
» Besoins non fonctionnels (spécifications techniques)
Les contraintes sous lesquelles le système doit rester opérationnel et les standards auxquels il
doit se conformer. Par exemple:
1 Les besoins en performance

Exemple: le_système doit répondre à un client au bout de 2 secondes après l'insertion de la

carte.
1 Les contraintes de développement (processus de développement)
Exemple: le système doit être implanté sur une machine supportant le système d'exploitation
UNIX.

h
 A. koukam, Professeur des Universités à l'UTBM

4. ANALYSE DES BESOINS

Acteurs : regroupent tous les intervenants qui constituent la source d'information pour l'élaboration
des besoins. Un intervenant peut appartenir à l'une des 4 catégories suivantes : 1) les utilisateurs qui
vont exploiter le système et utiliser ses fonctionnalités 2) les clients qui investissent dans le
développement du système et qui en sont propriétaires 3) le personnel technique qui est responsable du
bon fonctionnement du système dans l'environnement de l'organisation 4) éventuellement les entités
extérieures, tels les clients de l'organisation.
La première tâche de l'analyste est d'identifier chacun des types d'intervenants concernés par le
système à construire.
Procédé:
1 Séries de questions posées aux intervenants (clients, utilisateurs, .... )

1 Eventuellement, les documents foumis par le client

1 Analyse de la tâche, généralement quand il s'agit d'automatiser une activité manuelle.
1 Création de modèles pour représenter et communiquer les besoins. Par exemple, la modélisation des
besoins fonctionnels par des cas d'utilisation (UML) et des données par une première ébauche d'un
diagramme de classes.
Problèmes rencontrés: divers et en particulier:
1 Comment organiser et structurer les informations obtenues?
1 Comment résoudre les contradictions pouvant exister entre les différents interlocuteurs?

Eléments de solution:
1 Utiliser les méthodes d'analyse: SA, SADT, Merise, OOA (UML) ...
1 Qualités de l'analyste en matière de communication
1 Appliquer les trois principes suivants :

1 Décomposition: Appréhender le problème en le décomposant en plusieurs parties.

Cas d'un système d'exploitation: difficulté d'appréhender tout le système dans sa globalité.
=> Le décrire à travers ces composants :
- système de gestion de fichiers
- système de gestion de la mémoire
-système de gestion de processus.
Après la décomposition, on peut étudier chaque partie séparément.
1 Abstraction: Appréhender le problème à un bon niveau d'abstraction. Eviter les détails.
Par exemple, pour le système de gestion des fichiers d'un système d'exploitation, décrire les
fonctions de haut niveau sans se sorcier dans un premier temps de l'organisation des fichiers en
mémoire secondaire :
- création et destruction de fichier
- ouverture et fermeture de fichier
- gestion des répertoires
- interface utilisateur
1 Proj ection : Etudier le système à partir de plusieurs points de vue.
Cas d'un système d'exploitation. Analyser selon:
- le point de vue de l'utilisateur
- le point de vue du programmeur
- le point de vue de l'administrateur
Pour chaque point de vue, identifier les besoins qui lui sont associés.

5- Spécification des besoins

Il s'agit de décrire de manière précise et à travers des modèles les besoins du système: rendre plus
formalisés les résultats de l'étape d'analyse. Le document qui en résulte est le document de
spécification. .

2
 A. koukam, Professeur des Universités à ]'UfBM

Caractéristiques d'un bon document de spécification.

~ Doit spécifier uniquement le comportement externe du système et les réponses aux événements
non désirables.
~ Doit spécifier les contraintes de réalisation.
~ Doit être facile à mettre à jour.
~ Doit contenir des indications concernant les étapes ultérieures.
~ Doit servir d'outil de référence pour la validation et la maintenance.
~ Doit être complet et cohérent.
Les principaux composants d'une spécification
Peuvent être classés en 3 catégories : les besoins fonctionnels, les besoins non fonctionnels et les
interfaces externes. Nous allons les décrire séparément.

5.1 Les besoins fonctionnels

Définition: Les services ou les fonctionnalités que l'utilisateur attend du système. Pour chaque service :
- les données nécessaires à l'exécution du service
- les résultats qu'il produit
- une description générale de son rôle
- le traitement des erreurs

L'expression des besoins fonctionnels peut prendre plusieurs formes selon la méthode et le langage de
spécification choisis et le niveau de détail à atteindre. Nous allons explorer les différentes formes
d'expression possibles tout en soulignant leurs avantages et leurs inconvénients. Il s'agit ici d'une
présentation synthétique: nous consacrerons une bonne partie des cours suivants à l'étude détaillée des
deux dernières méthodes et langages de spécification (méthodes semi-formels très utilisées: UML,
SA, SADI et méthodes formelles: spécifications algébriques, langage Z et B). Les deux premiers
langages que nous présentons ci-dessous (langage naturel, langage structuré) sont simples à
comprendre et constituent deux moyens d'expressions pouvant être utilisés pour documenter les
spécifications construite à l'aide de méthodes formelle ou semi- formelles.

Méthodes et Langages d'expression des besoins fonctionnels

5.1.1. Spécification en Langage naturel

Dans ce cas, les fonctions (ou services) du système sont défmies en utilisant le langage naturel
éventuellement en introduisant des schémas et des tableaux.
Exemple de quelques fonctions du système IPE (développement d'un terminal de paiement
électronique)
Fonction: «Fournir un ticket»
- Fournir une preuve d'achat au client
- Fournir une preuve de la transaction (cas paiement accepté)
Fonction: «Communiquer avec le système de paiement»
- permettre au TPE de dialoguer avec le système de paiement par carte.

lAvantages de ce mode d'expression:

- plus expressif.
- compréhensible à la fois par les clients et les développeurs.
1 Inconvénients :

- besoins forctionnels imprécis à cause de l'ambiguité inhérente au langage naturel.

- mélange des besoins fonctionnels et non fonctionnels.
- la spécification est beaucoup trop flexible : le risque d'exprimer des besoins voisins dans des termes
totalement différents.

3
 A. koukam, Professeur des Universités à l'umM

- les besoins ne sont pas cloisonnés : les conséquences d'un changement ne peuvent être évaluées
qu'après un examen de chaque besoin, et non d'un groupe de besoins voisins.

5.1.2. Spécification en Langage structuré

Utilisation contrôlée du langage naturel et de formulaires standards de spécification. Les formulaires
peuvent être structurés autour :
- des objets manipulés par le système.
- des fonctions qu'il remplit (ce mode de structuration est le plus utilisé lorsqu'on se base sur un
langage structuré).
- des évènements qu'il doit traiter.

Exemple:
Fonction: Vérifier validité carte
Description: Cette fonction vérifie que la carte introduite par un utilisateur
provient d'une banque reconnue, qu'elle est à jour, et qu'elle contient des informations appropriées
ainsi que des détails sur les dates et les montants des précédents retraits.
Entrées: identification de la banque, numéro de compte, date d'expiration, date et nature de la
dernière transaction.
Sorties: Etat de la carte = (OK, invalide)
Besoins: Liste des banques, format du compte, date du jour
Pré-condition: carte introduite et bande magnétique lue
Post-condition: Identification de la banque dans la liste des banques et Numéro de compte au bon
format et date d'expiration >= date d'aujourd'hui et Etat de la carte = OK
ou (si l'un de ces tests est raux) Etat de la carte = invalide

Cette spécification utilise les pré et post conditions pour décrire le rôle de la fonction. Les objets
utilisés (Liste des banques, ....) doivent être définis dans un dictionnaire de données. Notons que cette
spécification n'introduit pas d'information sur le séquencement dans la définition des pré et post
conditions.
1 Avantages de ce mode d'expression:

- évite un certain nombre de problèmes de structurations.

- peut être supporté par des outils.
1 Inconvénients: demeure le problème de l'ambiguïté dû à l'utilisation en partie du langage naturel.

5.1.3. Spécifications semi-formelles

Généralement associées à des méthodologies (SA, SADT, UML, ... ), ces spécifications sont exprimées
dans des langages graphiques. Elles sont très couramment utilisées et bénéficient d'environnements
logiciels d'aide à la spécification. Nous consacrerons une bonne partie du cours à ces méthodes. A titre
d'exemple, voici une spécification exprimée en SADT (Structured Analysis and Design Techniques).
Carte illisible
Lire
carte
Carte non valide
Lecteur Vérifier
cie cart.e validit.é

Cod
Mettre àjour
le compte
Montant

4
 A. koukam, Professeur des Universités à l'umM

SADT est une méthode qui analyse un systèmes en mettant l'accent sur les fonctions qu'il doit réaliser.
Chaque fonction peut être décomposée en plusieurs autres fonctions (décomposition fonctionnelle d'un
système). Un rectangle (appelé actigramme) représente une fonction du système. Les flèches entrantes
(respectivement sortantes) représentent les données (respectivement les résultats). La flèche en
dessous de la fonctiormalité «Lire carte» précise le support physique nécessaire à l'exécution de cette
fonction.

5.1.4 . Spécifications formelles

se sont des spécifications exprimées dans des langages possédant une sémantique formelle permettant
de raisormer sur la spécification pour faire des preuves de propriétés. Proche des mathématiques, ces
langages sont généralement fondés sur la logique du premier ordre, la théorie des ensembles ou les
systèmes formels. Nous dormons ci-dessous un exemple de tels langages: la spécification algébrique
des types abstraits de dormées.
Exemple: Spécification algébrique du type Pile
type Pile (ELT)
opérations: décrit l'interface du type en donnant ses opérations et leurs interfaces
creer : ---> Pile, chaque opération est définie par son domaine de départ et son domaine d'arrivée
empiler : Pile * ELT ---> Pile
depiler : Pile ---> Pile
vide : Pile ---> Booléen
sommet : Pile ---> ELT
Axiomes: décrivent les propriétés des opérations ou services proposés.
depiler (créerO) = créert)
depiler (empiler (p, e» = P
vide (créer) = vrai
vide (empiler (p , e» = faux
sommet (empiler (p, e) = e
sommet (créerO) = indéfini
fin type

Avantages:
- spécification précise et sans ambiguïté
- possibilité de faire des preuves de complétude et de consistance
- peut être traitée de manière automatique grâce à des outils
- possibilité d'avoir des spécifications exécutables
Inconvénients :
- nécessite un grand effort de formation
- non compréhensible généralement par les clients

Conclusion sur les méthodes de spécification:

Nous venons d'examiner les différentes classes de méthodes et d'expression des spécifications. Mais
alors laquelle choisir ?
Il n'y a pas de réponse unique et valable pour tous les systèmes. Disons que dans la pratique et pour de
nombreux systèmes, on utilise les méthodes semi-formelles que l'on documente à l'aide du langage
naturel et du langage structuré (vous ferez l'expérience à travers le projet que vous allez réaliser). Bien
qu'elles soient très peu utilisées, les méthodes formelles ont montré dans l'industrie leur efficacité
dans la spécification de certains systèmes critiques (une parme peut provoquer une catastrophe). Grâce
à la possibilité de prouver formellement les propriétés d'un système avant sa mise en œuvre, ces
méthodes constituent un pas vers la certification formelle de logiciels.

5
 A. koukam, Professeur des Universités à l'UTBM

5.2 Les besoins non fonctionnels

Ils constituent les buts opérationnels liés à l'environnement au matériel et aux logiciels de
l'organisation. Ils décrivent aussi les restrictions ou les contraintes qui pèsent sur le système et en
particulier sur ses services. On peut les subdiviser en plusieurs parties que nous présentons ci-dessous.
Besoins en performances
- Temps de réponse exigé (à une requête par exemple)
- Taille des informations manipulées et espace mémoire nécessaire
- Restrictions sur la représentation des données
- Nombre moyen de transactions par seconde
- Nombre de terminaux connectés au système

Voici un tableau de métrique qui résume et donne d'autres éléments liés aux performances.

Propriété Métrique
Vitesse Nombre de transactions par seconde
Temps de réponse à l'utilisateur/à un événement
Temps de rafraîchissement de l'écran
Taille K octets, nombre de puces de RAM
Facilité d'utilisation Durée de formation, nombre d'écran d'aides
Fiabilité Temps moyen entre deux pannes, probabilité de non disponibilité,
Taux d'apparition des pannes
Robustesse Temps de redémarrage après une panne,
Pourcentage d'événements causant des pannes,
Probabilité de corruption de données sur une faute
Portabilité Pourcentage d'instructions dépendant de la cible

Les contraintes de conception

expriment les contraintes sur le processus de développement
- utilisation de méthodes standards
- langage de programmation
- système d'exploitation
- matériels
- structure de la documentation (format de rapports)

Exemple de contrainte de conception:

"Le processus de développement du système et les documents devront être conformes à la norme DEF-
STAN 00-65"

5.3 Les interfaces externes

expriment les relations entre le système et :
- Les utilisateurs du système: les messages d'erreurs (clarté, longueur), la description des formes et
éditions sur papier et écrans
- Le matériel : lorsque le système à développer interagit avec un système matériel, il faut décrire
l'interface entre les deux
- Le logiciel : liaison avec une base de données, des bibliothèques mathématiques, graphiques, les
procédures d'échange de messages.

6
 A. koukam, Professeur des Universités à l'UTBM

6. Structure d'un document de spécification

Sommaire: plan du document
1 - Introduction
:: · Buts et destinataires du document
- Défmir en quelques lignes s'il s'agit de développer ou d'améliorer un système
- La manière dont le système s'insère dans les objectifs commerciaux et stratégiques de
l'organisme commanditaire.
· Définitions - Abréviations
- Les termes techniques utilisés
- Les abréviations
· Présentation générale du document ( comment il est organisé)
2 - Description générale
· Environnement ou contexte du système
Décrit les relations du système avec d'autres systèmes et les principales interfaces avec ceux-ci.
- Donner un diagramme , faisant apparaître le système et les acteurs avec lesquels, il interagit. Le
,
système est vu comme un grand cas d'utilisation. (d; ~ cQ..r'TIN... 4t. (...0 ri \.u.k. ') }6JfL

- Commenter en langage naturel, les acteurs et leurs interaction avec le système. /

· Modèle conceptuel .
Une description de haut niveau des principales fonctions du système , les relations entre elles et les
entités qui interviennent à ce niveau.
· Caractéristiques des utilisateurs
Identifie les différents types d'utilisateur du système en ,précisant leurs caractéristiques.
- Expérience et connaissances dans l'utilisation des systèmes informatiques.
- Utilisateurs réguliers ou occasionnels
· Les contraintes principales de développement
Précisent les procédures, les normes et les standards à utiliser dans le développement.
· Hypothèses de travail
Décrivent tous les facteurs susceptibles de remettre en cause tout ou une partie de la réalisation des
spécifications ainsi que d'éventuelles solutions de repli.
3 - Besoins fonctionnels
. ~ -Décrire les cas d'utilisation du système, en les regroupant par acteur, ou par grande fonctionnalité.
,·l
-c / -Commenter les cas d'utilisation en utilisant des formulaires tels que:
;- nom du cas d'utilisation
· Description (Rôle, présentation générale)
· les acteurs concernés
· Les entrées et leurs provenances
· Le traitement
· Les sorties (messages d'erreurs éventuellement)
4- Spécification des structures de données
Donner un modèle décrivant les entités du systèmes et leurs relations.
(ce chapitre comprend une section par entité)
- Nom de l'entité
- But et essence
- Eventuellement les relations avec les autres entités, leurs cardinalités
5- Spécifications des interfaces externes
· Interface matériel/logiciel
- Configuration minimale et optimale sur laquelle le système peut s'éxécuter
- Les caractéristiques des interfaces entre le système et les dispositifs particuliers :
- Capteurs, actionneurs, périphériques (lecteur de chèques, de code à barres, ...)
- Protocole d'échange (réseau local, ...)

7
 A. koukam, Professeur des Universités à !'UTBM

- Le type de liaison (série, parallèle, ...)

. Interface logicielllogiciel
Pour chaque logiciel utilisé explicitement par exemple système de gestion de bases de données,
bibliothèque de fonctions mathématiques, services du système d'exploitation, il faut préciser: le nom,
son numéro de version, -sa provenance, le but de son utilisation, et définir l'interface, éventuellement en
renvoyant à une annexe ou un autre document.
. Interface Hommellogiciel
- Spécification des ~forrnes des éditions sur papiers et sur écrans
- Spécification des menus, des messages d'erreur
- Défmition d'un manuel d'utilisateur (préliminaire)
6- Les besoins en performance ev
oir cours précédent)
- Nombre maximum de terminaux
- Nombre maximum de transactions simultanées
- Nombre de fichiers et leurs tailles
- Temps de réponse souhaité
- Les contraintes liées à l'environnement (temps réel)
7 - Les contraintes de développement (Voir cours précédent)
- Fiabilité et tolérance aux fautes
- Le comportement du système dans des situations anormales (les exceptions critiques)
- Sécurité
· Restriction sur l'utilisation de certaines commandes
· Contrôle des accès aux données
· Utilisation de mot de passe
-Utilisation de standards en ce qui concerne les méthodes, outils et langages de développement.
8 - Références
Décrit:
- les références bibliographiques
- les sources d'obtention des documents
Il faut donner les références de tous les documents utilisés dans l'élaboration de la spécification.
9 - Index
- Index alphabéti~ue, . Ii J.. m û- ~
- Index des fonctions -l {l·h~C ~ .vW40~aJ;:€J1v.:>
10 - Annexes /
- Description rapide des méthodes utilisées
- Description rapide des systèmes , outils externes au système et qui sont utilisés dans les
paragraphes précédents.

7. Bibliographie
-1. Sommerville. "Software Engineering", 3rd edn. Wokingham : Addison-Wesley, 1989
.j Satzinger, R.B. Jackson, S. Burd. "Analyse et conception des systèmes d'information", Editions
Rynold Goulet, 2002.
-1. Jacobson, G. Booch, J. Rumbaugh, "The Unified Software DevelopementProcess", Addison-
Wesley, 1999.
-A. Koukam. "Software Engineering", Course Introduction to Software Engineering, University of
Qatar, Doha, 2002.

r:
8