1) Spécification des BESOINS:

Problématique de l’analyse des besoins: causes

Le client ne sait pas toujours ce qu’il veut et n’exprime pas toujours ces besoins clairement. •
L’informaticien ne comprend pas le client (et vice versa !) • Ce que le client demande n’est
pas forcement ce dont il a besoin. • Le client exprime souvent la solution à laquelle il pense
et non son besoin réel (que vous ne connaîtrez peut-être jamais). • Le client ne connaît pas
toujours l’informatique : il ne sait pas ce qui est possible et ce qui ne l’est pas.
Problèmes potentiels :
• Difficultés de communiquer – difficulté d’être précis, cohérent, complet,… – différences de
culture : • les utilisateurs ne sont pas des informaticiens… • les informaticiens ne
connaissent pas le domaine … • Complexité du problème – problème non formalisé –
problème complexe • Evolutivité
Différents types de besoins:
Besoins fonctionnels
– À quoi sert le système ? – Ce que doit faire le système, les fonctions utiles – Description
des données manipulées •
Besoins non fonctionnels : une restriction ou une contrainte qui pèse sur un service du
système – description des contraintes, – Pour chaque fonction et pour le système global, il
est possible d’exprimer différents types de contraintes •
Besoins du domaine – Requis qui proviennent du domaine d’application du système et qui
reflètent les caractéristiques de ce domaine (industriel, académique, médical, ….
Définition et types de spécification:
• La spécification décrit les caractéristiques attendues (le quoi?) d’une implantation (le
comment?)
On distingue 3 types de spécification :
– La Spécification des besoins : Utilisateur final Analyseur/ Concepteur Exigences
fonctionnelles et non fonctionnelles
– La Spécification d’une architecture du système
– La Spécification technique d’un module
Styles de spécification :
Formalité:
Spécification informelle (Langue naturelle)
Spécification formelle (Langage Z)
Spécification semi – formelle (Modèles graphiques)
Caractère : Déclaratif (Description des propriétés désirées)
Opérationnel (Description du comportement désiré)
Différents outils de spécification
1. Les Enoncés informels :
- Spécification en langage naturel qui varie selon l’entreprise, le projet et l’inspiration. - Elle
présente beaucoup de limites : 10 Différents outils de spécification ➢ le bruit : information
non pertinente, voire inutile ; ➢ le remords : forme de bruit qui modifie le texte a posteriori ;
➢ le silence ou la sous-spécification : absence d’information ou de notions non explicitées ;
➢ la sur-spécification : en dire trop sur la solution (dérive vers la conception) ; ➢
l’incohérence : contradiction interne ou exigences incompatibles ; ➢ l’ambiguïté : termes
imprécis avec plusieurs interprétations possibles ; ➢ l’exigence invérifiable : vœu pieux ; ➢
la redondance, le non-respect du standard, les exigences absentes…
2. Les Présentations formatées
Les présentations formatées ont aidé la transition vers la spécification semi-formelle. On
peut citer : - Dictionnaire de données : (vu dans le cours BD) permet de définir la structure
de données - Table de décision : ( vu dans les cours « logique formelle » et « systèmes
logiques » avec les tables de vérité) adaptée à la spécification des systèmes dont les sorties
sont , à tout moment, uniquement définies par les entrées. - Table état/transition : (vu dans
le cours BD) adaptée à la spécification des systèmes dont les sorties sont déterminées par
les entrées et l’historique des états antérieurs.
3. Les outils graphiques ou semi-formels
Les outils de spécification semi-formelle se basent sur un formalise graphique complété par
du texte (langage naturel) La syntaxe est précise par le formalise graphique mais la
sémantique est non précise.
3. Les outils graphiques ou semi-formels
On peut citer : - Modèle entité/association (E/A) (pour les données) - Diagramme de Flots de
données (DFD) certains l’appellent Diagramme de flux de données (pour les activités) -
Diagramme de structure (pour le comportement ) - Diagramme état/transition (pour le
comportement ) - Réseaux de Petri (RdP) (pour le comportement )
Outil de spécification : DFD
Une technique semi-formelle et opérationnelle
• La représentation graphique distingue :

La première étape pour la modélisation avec les DFD consiste à élaborer le diagramme de
contexte qui délimite les entités externes qui interagissent avec le système à modéliser. •
Puis on détaille la fonctionnalité globale du système par un DFD niveau 1
• On peut détailler encre plus par d’autres niveaux de DFD
Outil de spécification semi-formelle Les réseaux de Petri (RdP)
Un réseau de Petri est un moyen de: • modélisation du comportement des systèmes
dynamiques à événements discrets. • description des relations existantes entre des
conditions et des évènements. Un RdP est composé de places, de transitions et d'arcs

Marquage : • Chaque place contient un nombre entier positif ou nul de marques ou jetons. •
Le marquage M définit l'état du système décrit par le réseau à un instant donné. C'est un
vecteur colonne de dimension le nombre de places dans le réseau. Le ième élément du
vecteur correspond au nombre de jetons contenus dans la place Pi . • Si la place modélise
un état du système, le marquage précise si le système est dans cet état ou pas. • Si la place
modélise une ressource, le marquage précise le nombre disponible de cette ressource à un
instant donné.
Franchissement d'une transition • Une transition est franchissable lorsque toutes les places
qui lui sont en amont (ou toutes les places d'entrée de la transition) contiennent au moins un
jeton. • Le franchissement consiste à retirer un jeton de chacune des places d'entrée et à
rajouter un jeton à chacune des places de sortie de la même transition.
Une transition sans place d'entrée est toujours franchissable : c'est une transition source.
2)Les tests
Qui teste ?
➡L'utilisateur ➡Les collègues en charge du test (s'il y en a) ➡Le développeur : il a le devoir
de fournir un code le plus clair et le mieux testé possible.... ➡ La machine
Qu’est-ce qu’on teste?
Le Quoi ? • Fonctionnalité • Sécurité / intégrité • Utilisabilité • Cohérence • Maintenabilité •
Efficacité • Robustesse • Sûreté de fonctionnement
Comment on teste?
• Test statique : -relecture / revue de code -analyse automatique (vérification de propriétés,
règles de codage …
• Test dynamique : -exécution du programme, et observation du comportement en fonction
des valeurs en entrée
Types de tests
. Tests de fonctionnalités
1. Tests système/fonctionnels et Tests structurels
2. Tests d’acceptation Avec le client
3. Tests de (non) régression (après modifications) Correction et évolution ne créent pas
d’anomalies nouvelles
4. Tests de robustesse Cas de tests correspondant à des entrées non valides
5. Tests de performance (application intégrée dans son environnement) - load testing :
résistance à la montée en charge - stress testing : résistance aux demandes de
ressources anormales (montée en charge au-delà du maximum attendu)

Les tests de Fonctionnalités

➡ Tests en boîte noire: Tests système/fonctionnels - Utilise la description des fonctionnalités
du programme - Provenant des spécifications (scenarii, uses cases)
➡ Tests en boîte blanche: Tests structurels - Utilise la structure interne du programme
Tests boites noires
• Principe : On ne prend en compte que de (donnée entrée) et ds (donnée sortie) •
Validation – Analyse de la structuration de de et ds – Analyse des correspondances entre
DE et DS (i.e. On valide complètement la sémantique de la transformation) •
Limites des tests boites noires
• La détermination des domaines est problématique • Rendement de l'effort de tests
potentiellement très mauvais
Tests boites blanches
• Principe : On prend en compte de ds et la structure interne de l’élément • Vérification •
Niveau de granularité de l'observation – Instructions élémentaires – Séquences linéaires
d'instructions – Blocs de code regroupant plusieurs séquences apparentées (Régions
fortement connexes ) – Fonctions et/ou procédures du langage • Environnement d'exécution
– Aspects temporels, gestion des ressources, etc.
• Limites des tests boites blanches • Effectués par les ingénieurs et développeurs et pas par
les testeurs d’assurance qualité (exigence de compétences techniques • Coïncidence et
recouvrement non garantis entre vérification et validation (vérification que de l’existant,
aspect structurel et non sémantique)
 Tests boites blanches:
• Fondés sur l’aspect structurel (i.e. syntaxique) du composant à tester au moyen du graphe
de contrôle – On s’intéresse à l’agencement des instructions, et non à leur signification •
Exp. :
DO WHILE ((a>5) & (a<5)) DO; bloc d’instructions;
END DO;
• Graphes de contrôle et nombre cyclomatique ignorent l’aspect sémantique
– La sémantique prend en compte la nature de la transformation Ds = Prog(De ), c.a.d. aux
domaines de valeurs et au sens des opérateurs
• Exp. : la condition ((a>5) & (a<5)) est toujours FAUSSE, donc le bloc d’instructions n’est
jamais exécuté
Une des méthodes de tests structurels boites blanche :
Dérivation de jeux de tests à partir du graphe de contrôle :
– Suit l’enchaînement des opérations qui sont représentées par un graphe
– Cherche à couvrir toutes les instructions, tous les chemins
Une autre méthode: Dérivation de jeux de tests à partir du flot de données
– Suit la vie des variables au cours de l’exécution du programme : définition, utilisation,
destruction (exécution pas à pas )
– Cherche à couvrir toutes les affectations, toutes les utilisations

On s’intéresse ici à la 1ère méthode : dérivation de jeux de tests à partir du graphe de

contrôle.
• On se base sur le nombre cyclomatique qui représente :
– Le nombre de chemins linéairement indépendants dans un graphe fortement connexe
• Rappel : Un graphe est fortement connexe si : – ni et nj, deux nœuds du graphe, un
chemin reliant ni et nj
Un graphe de contrôle est constitué d’arcs et de sommets
• Chaque arc représente une ou plusieurs instructions
• Chaque sommet représente : Soit un départ conditionnel (sur 2 branches ou plus) Soit la
jonction de branches incidentes
• Un graphe de contrôle permet de construire les chemins
• Un chemin est une suite d’arcs reliant un point d’entrée du programme à un point de sortie
• Il y peut y avoir beaucoup de chemins possibles et certains chemins impossibles
À partir du graphe de programme on peut calculer le nombre cyclomatique (NC) (Mc
Cabe-1976)
V(g) tel que : NC= V(g) = e – n + 2 (e : edge [arc] ; n : node [nœud])
On définit plusieurs niveaux (objectifs) de couverture
• C0 : tester toutes les instructions (noeuds « fonction ») au moins une fois
• C1 : tester toutes les décisions possibles au moins une fois (ou toutes les branches)
• C-i : tester toutes les branches (C1) mais en passant i fois dans chaque boucle : (i-
chemins)
• C∞ : tester tous les chemins possibles
• C∞ est virtuellement impossible
• C1 et C0 sont différents • En pratique, le test d’un programme consiste à satisfaire C0 et
C1