Vous êtes sur la page 1sur 140

République Démocratique du Congo

Ministère de l’enseignement supérieur et universitaire

1ère Licence en informatique

QUESTIONS SPÉCIALES DE PROGRAMMATION


AVANCÉE (QSPA)
GESTION DE LA QUALITÉ DU LOGICIEL : PROCESSUS,
ASSURANCE QUALITÉ ET TESTS LOGICIELS

Par

Prof. Jean-Pierre Booto Ekionea, Ph.D.

CT Hervé Kabamba Mbikayi

Octobre 2017
TABLE DES MATIÈRES

CHAPITRE I : INTRODUCTION

CHAPITRE II : BESOINS DES UTILISATEURS ET PROCESSUS LOGICIELS

CHAPITRE III : GESTION DE LA QUALITÉ

CHAPITRE IV : GESTION DES TESTS LOGICIELS

CHAPITRE V : AUTOMATISATION DES TESTS LOGICIELS

CHAPITRE VI : EXERCICES : ETUDE DE CAS


Annexes I : Étude de cas
Annexe A : Cas du Super Club Vidéotron - Achat et location des films à distance
Annexe B : Cas de RÉFAEC – PHP Extranet
Annexe C : Le cas de la Boulangerie Lépine ltée
Annexe D : Le cas d’Info Web Santé – Solution de type e-Communauté
Annexe E : Le cas du Système de Réservation de Voyage Campus (SyRVoC)
Annexes II : Plans qualité et de tests
Annexe A : Plan qualité logiciel
Annexe B : Plan des tests logiciels

2
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
CHAPITRE I : INTRODUCTION
Nos objectifs d’apprentissage pour chaque étudiant(e) sont les suivants
1. Comprendre les notions de base du génie logiciel;
2. Comprendre le processus de mis en place d’un système de qualité logicielle dans un cycle de vie logiciel et
pour les différents domaines d’application;
3. Appliquer un contrôle effectif de qualité logicielle en parallèle à une méthodologie de développement
d’applications;
4. Définir le rôle d’une équipe d’assurance qualité effective;
5. Comprendre l’utilisation et développer un plan d’assurance qualité (PAQ);
6. Implanter et maintenir un plan et une cellule d’assurance qualité en utilisant une approche spécifique;
7. Développer les habiletés et la conscience d’une éthique de l’analyste qualité;
8. Rédiger le rapport de qualité logiciel;
9. Comprendre et être à mesure de rédiger les plans de tests et les cas de tests logiciels à partir d’un plan de
qualité logiciel;
10. Gérer et coordonner les tests logiciels;
11. Effectuer l’automatisation des tests logiciel;
12. Rédiger le rapport des tests logiciel.

Objectifs d’apprentissage:
► Donner à l’étudiant(e) les compétences nécessaires sur le génie logiciel, l’assurance qualité et les tests
logiciels;
► Initier l’étudiant(e) aux méthodes d’assurance qualité, de vérification et de validation des tests;
► Initier l’étudiant(e) à la rédaction du plan et de rapport de qualité logiciel;
► Initier l’étudiant(e) à la rédaction du plan et de rapport de tests logiciels.
Contenu :
► Bref aperçu de l’analyse des besoins des utilisateurs;
► Introduction au génie logiciel;
► Le cycle de vie du processus de développement logiciel;
► Les exigences du logiciel et l’assurance qualité du logiciel
► Code de déontologie, culture et comportement de l’ingénieur qualité
► Fondements de la qualité logicielle;
► Le contrôle et la maîtrise de la qualité;
► La gestion des tests logiciels.

1.1. Introduction au génie logiciel

Du "codeur"
... au "programmeur"
… à "l'ingénieur logiciel"

a. Génie logiciel: "The engineer is expected to demonstrate


that the design satisfies the specifications."
◊ Méthodes formelles existantes mais encore peu utilisées
◊ Génie logiciel: "A highly developed sense of responsability
toward his clients and the public"
◊ "X-Software Ltd. does not guarantee the accuracy, adequacy, or completeness of any information and
is not responsible for any errors or omissions or the results obtained from use of this software... "

b. Génie logiciel: " Engineering practice enables ordinary practitioners so they can create sophisticated systems
that work - unspectacularly, perhaps, but reliably“
◊ Etude récente effectuée aux états unis [Standish Group 1995]
3
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• 31% des projets non achevés ou abandonnés à la livraison
• 53% des projets dépassent les ressources allouées
• 16% des projets se déroulent comme prévu

1.1.1. La préhistoire du génie logiciel


◊ Années 50 et 60 : programmation empirique
– Production "artisanale" de logiciels scientifiques
– Royaume des "codeurs" et les "grands gourous"
– Fin des années 60 : la "crise du logiciel"
– Difficulté d'écrire de grands programmes
– difficulté de les utiliser, difficulté de les faire évoluer
– De nombreux projets échouent

1.1.1.1. La préhistoire du génie logiciel: la crise du logiciel


◊ Étude du gouvernement américain en 1979
– Payés mais jamais livrés $3.2M 47%
– Livrés mais jamais utilisés $2.0M 30%
– Abandonnés ou refaits $1.3M 20%
– Utilisés après modification $0.2M 3%
– Utilisés tel quel $0.1M 2%

a. Échecs logiciels:
◊ AT&T, 1992: interruption du service téléphonie pendant 5 heures à l'est des états unis.
◊ Aéroport de Denver, 1994: logiciel de suivi des bagages, coût 3 milliard de $, retard de 18 mois.
◊ Oslo, Sept. 1993: erreur dans le système de contages des votes du parlement => nouvelles élections.
◊ etc.

b. Échec du premier lancement d'Ariane V :


◊ Celle ci a explosé en vol.
◊ La cause : logiciel de plate forme inertielle repris tel quel d'Ariane IV sans nouvelle validation.
◊ Ariane V ayant des moteurs plus puissants s'incline plus rapidement que Ariane IV, pour récupérer
l'accélération due à la rotation de la Terre.
◊ Les capteurs ont bien détecté cette inclinaison d'Ariane V, mais le logiciel l'a jugée non conforme au
plan de tir (d'Ariane IV), et a provoqué l'ordre d'auto destruction.

4
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ En fait tout se passait bien... Coût du programme d'étude d'Ariane V : $370 000 000.

c. Les ordinateurs menacent la productivité :


◊ Des milliers d'heures de travail sont perdues à essayer de faire faire à l'ordinateur ce qu'il devrait faire,
ou de comprendre des messages d'erreur incompréhensibles.

d. Le logiciel est la clé de différenciation des produits industriels.

e. Nous utilisons du logiciel tout le temps, de plus en plus volumineux :

5
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
90% des nouvelles fonctionnalités des automobiles sont apportées par l'électronique et l'informatique
embarquées.
"Il y a plus d'informatique dans la Volvo S80 que dans le chasseur F15" déclarait en janvier 2000 le Président
d'Audi.

Il y aura du logiciel partout : ampoules électriques, four à micro ondes, tissus des vêtements, stylos, livres, etc.

f. Est-ce l’échec du génie logiciel


◊ Échec du Génie Logiciel ? Non !
• de très nombreuses avancées
• les logiciels sont de plus en plus demandés et utilisés
• des logiciels construits sont de plus en plus complexes
◊ Des progrès restent à faire... Un sujet essentiel !
• Recherche
• Pratique industrielle
• Enseignement

g. Est-ce l’échec du génie logiciel


◊ Échec du Génie Logiciel ? Non !
• de très nombreuses avancées
• les logiciels sont de plus en plus demandés et utilisés
• des logiciels construits sont de plus en plus complexes

6
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ Des progrès restent à faire... Un sujet essentiel !
• Recherche
• Pratique industrielle
• Enseignement

7
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.1.1.2. La préhistoire : origine du terme « génie logiciel »
◊ 1968 : "1st Conference on Software Engineering"
– Génie Logiciel = Ingénierie + Logiciel
– idée : la production de logiciel doit être organisée
– contrôle des coûts, contrôle de la qualité, etc
◊ Idée séduisante : changement de terminologie
– 1950 : codeur
– 1970 : programmeur
– 1990 : ingénieur logiciel
◊ Correspond réellement à une discipline d’ingénierie ?

1.1.1.3. Définition de « ingénierie »: "Creating cost-effective solutions - to practical problems - by applying scientific
knowledge" [Shaw90]
◊ Ressources limitées (e.g. temps, argent, ...)
◊ Solution utile résolvant un problème concret
◊ Le problème n'est pas inventé par l'ingénieur
◊ Rigueur dans la résolution du problème
◊ Prédictibilité du résultat

1.1.1.4. Pratiques de l’ingénierie: " Engineering practice enables ordinary practitioners so they can create sophisticated
systems that work - unspectacularly, perhaps, but reliably"
◊ Pas besoin d'être un génie pour être un ingénieur !
◊ Résolution de problèmes complexes
◊ Résolution de problèmes récurrents
◊ Catalogue de solutions pour un type de problèmes
◊ Solutions sûres et éprouvées

1.1.1.5. Ingénierie et société: "The engineer is expected to demonstrate


that the design satisfies the specifications."
◊ Exemple : montrer qu'un pont ne va pas s'écrouler
◊ Contraintes de sécurité imposée par la société

1.1.1.6. Ingénierie et société: "A highly developed sense of responsability


toward his clients and the public"
◊ N'importe qui ne peut pas faire n'importe quoi
◊ Association, droit d'exercer la profession, etc.

1.1.1.7. Modèle d’évolution des disciplines d’ingénierie


◊ L'émergence d'une discipline d'ingénierie est un processus lent
◊ Ingénierie = production de produits industriels basée sur des connaissances scientifiques

8
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.1.1.8. Exemple de génie chimique: production industrielle de produits chimique comme fertilisants, solvants, papier,
dérivés du pétrole, etc.

1.1.1.9. Statut du génie logiciel: près de 40 ans (seulement) d'expérience et de recherche dans le domaine

» Trop souvent resté dans l'artisanat


» Souvent atteint un niveau commercial
» Ingénierie dans certains cas isolés

1.1.2. Importance grandissante du logiciel

9
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Une amélioration de rendement même faible peut avoir des répercutions très importantes

1.1.2.1. L'explosion du logiciel continue :


De 1965 à 1995, en 30 ans, le volume de chaque logiciel a été multiplié par 100, alors que la productivité des
développeurs n'augmentait que d'un facteur 3. C'est la crise du logiciel.

10
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.1.2.2. Définition du logiciel: " Engineering practice enables ordinary practitioners so they can create sophisticated
systems that work - unspectacularly, perhaps, but reliably“
◊ Étude effectuée aux États-Unis [Standish Group 1995]
– 31% des projets non achevés ou abandonnés à la livraison
– 53% des projets dépassent les ressources allouées
– 16% des projets se déroulent comme prévu

On maîtrise mal le développement des logiciels


"90% des projets informatiques sortent en retard" (Aberdeen)
◊ Un nombre important de projets informatiques n’aboutit pas aux logiciels répondant aux besoins des
utilisateurs en respectant les contraintes de budget et de délai...
◊ De nombreux projets informatiques n'ont jamais abouti :
– Système de réservation de places de United Airlines
– Système d'exploitation Rhapsody
– Avis Europe abandonne le déploiement de l'ERP Peoplesoft mené par Atos : 45M€ (LMI
octobre 2004)
– "30% des projets informatiques sont annulés avant la mise en production" (Aberdeen)
"90% des projets informatiques sortent en retard" (Aberdeen)
◊ De nombreux projets informatiques n'ont jamais abouti ou n'ont pas réalisé les fonctionnalités
attendues :
– Windows 3
– Windows ME grand public
– "50% des projets informatiques ne répondent pas au cahier des charges business" (Gartner)
◊ De nombreux projets ou ont été des catastrophes économiques ou n'ont pas réalisé les fonctionnalités
attendues :
– Informatisation des caisses de sécurité sociale, carte Vitale
– Milieu 1999, le système d'information de la Bibliothèque Nationale de France avait pris 22
mois de retard, le budget initial (280MF) était dépassé de 40
– « 50% des projets informatiques dépassent le budget prévu" (Gartner) »

1.1.2.3. Génie logiciel: "Engineering practice enables ordinary practitioners so they can create sophisticated systems
that work - unspectacularly, perhaps, but reliably "
◊ Erreur courante : logiciel = code source
◊ Pas uniquement le code source !

11
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
– binaires, librairies, manuel utilisateurs, etc.
– spécifications, dossier de conception, test, etc.
◊ Savoir programmer n'est qu'un "détail" !

1.1.2.4. Les propriétés du logiciel


– il est visible mais intangible
– il vieillit mais ne s'use pas
– il ne se détériore pas sous l'effet des tests
– il est encore et toujours fabriqué artisanalement
– il est (trop ?) facilement reproductible
– il est (trop ?) facile à modifier
– il est d'une grande complexité : coût très (trop ?) élevé
– ...

16 % des projets informatiques aboutissent (The Standish Group International (2002))


Source http://www.01net.com/article/212560.html
...contrairement au génie civil (ponts, autoroutes, tunnels, ...)...

◊ Viaduc de Millau (en France), décembre 2004, livré à temps, 310 M€


◊ Les caractéristiques des projets informatiques diffèrent de celle des projets de génie civil : diversité des
applications - objectifs exacts non connus avant l'achèvement - niveau d'abstraction - invisibilité - taille -
12
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
complexité - coût élevé - évolutivité des besoins - répartition - parallèlisme -etc.

◊ Chaque projet informatique est un cas nouveau, il y a peu de références standards. Développer un logiciel
s'apparente plus à une activité de recherche qu'à la routine.

◊ Le cahier des charges n'est presque jamais complet et figé : il s'élabore et s'adapte à mesure de l'avancement du
projet parce que les systèmes informatiques sont trop complexes pour être maîtrisés par des êtres humains, et
parce que l'informatique est méconnue des décideurs et politiques.

◊ Il ne suffit pas de mettre de l'argent et de la technique, plus qu'ailleurs la qualité et la motivation des hommes
sont prépondérants. Un logiel est un produit industriel atypique, relevant de l'artisanat !

1.1.2.5. Les logiciels industriels


◊ Taille : des millions de lignes de code, milliers de modules, ...
◊ Durée de vie: 5 à 20 ans ... à 50 ans
◊ Taille des équipes:
– 3 à 50 ... à 1000 ingénieurs logiciels
– équipes réparties autour de la planète.
◊ Coût de développement et de maintenance de centaines de milliers de $ ... à des milliards

1.1.2.6. Les approches


◊ Gestion du produit et des ressources :
– Gestion de projet, estimation des coûts,...
– Assurance qualité, standardisation, ...
◊ Méthodes :
– Méthodes formelles, semi-formelles, informelles.
◊ Outils :
– Outil de modélisation, génération de code, ...
– Gestionnaire de configuration, outil de communication...

1.2. Quelques chiffres

◊ Répartition des coûts de développement


– spécification : 6%
– conception : 5%
– codage : 7%
– tests et validation : 15%
– maintenance : 67%
◊ Coûts de correction des erreurs provenant
◊ exigences et spécification : 56%
◊ conception : 24%
◊ codage : 10%
◊ autres :

 Les caractéristiques des projets informatiques diffèrent de celle des projets de génie civil : diversité des
applications - objectifs exacts non connus avant l'achèvement - niveau d'abstraction - invisibilité - taille -
complexité - coût élevé - évolutivité des besoins - répartition - parallèlisme -etc.

 Chaque projet informatique est un cas nouveau, il y a peu de références standards. Développer un logiciel
s'apparente plus à une activité de recherche qu'à la routine.

13
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
 Le cahier des charges n'est presque jamais complet et figé : il s'élabore et s'adapte à mesure de l'avancement
du projet parce que les systèmes informatiques sont trop complexes pour être maîtrisés par des êtres
humains, et parce que l'informatique est méconnue des décideurs et politiques.

 Il ne suffit pas de mettre de l'argent et de la technique, plus qu'ailleurs la qualité et la motivation des
hommes sont prépondérants. Un logiel est un produit industriel atypique, relevant de l'artisanat !

...bien que tous les grands projets doivent avouer des fautes cachées de jeunesse.

 Les premiers exemplaires (15?) du char Leclerc n'ont jamais roulé, malgré la masse de l'investissement
(35GF, un char coûtant 40MF). Un officier responsable expliquait « dans un programme technologiquement
sophistiqué, les premiers exemplaires ne sont jamais opérationnels d'emblée... ».
 De façon similaire, dans d'autres grands programmes technologiquement innovants les premiers exemplaires
n'ont pas fonctionné correctement :
o les premiers processeurs, ou ordinateurs, d'une série,
o les premiers PDA (Newton, d'Apple)
o les premiers Airbus,
o les premières fusées, Europa, Ariane, Saturne, etc.
o le porte avion Charles de Gaulle
o le Pentium, dont les premières versions pouvaient faire des erreurs de calcul, malgré les 5 G$
investis.
 Développer un logiciel s'apparente à chaque fois à un processus d'innovation. Considérons donc chaque
logiciel comme étant le premier exemplaire produit par un grand projet complexe. Il n'est alors pas étonnant
que ce premier exemplaire subisse des pannes graves de jeunesse. Le problème de l'industrie du logiciel est
qu'il n'y a pas de deuxième ou de troisième exemplaire !

1.3. Risques et difficultés en génie logiciel


◊ Complexité et quantité des éléments à tenir en compte
◊ Incertitude concernant la technologie
◊ Incertitude concernant les exigences
◊ Incertitude concernant les compétences
◊ Adaptation face aux changements
◊ Détérioration du produit
◊ Risques politiques

• Résumé: "Le génie logiciel n'est pas encore une discipline d'ingénierie très mûre mais elle doit le devenir"
◊ Les logiciels sont de plus en plus complexes
◊ Le rôle du logiciel dans la société est essentiel
◊ La programmation empirique mène à l'échec
◊ La programmation est un « détail » en informatique
◊ De nombreuses techniques de GL sont disponibles
◊ L'enseignement du Génie Logiciel est fondamental

• Qualités (externes/internes) du logiciel:


◊ Validité/conformité : aptitude du logiciel à réaliser exactement les tâches définies par sa spécification
◊ Robustesse : aptitude du logiciel à fonctionner (partiellement) même dans des conditions anormales
◊ Extensibilité/flexibilité : facilité d'adaptation du logiciel à des changements de spécification
◊ Réutilisabilité : aptitude du logiciel à être réutilisé en tout ou partie pour de nouvelles applications

• Qualités (externes/internes) du logiciel (suite):

14
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ Compatibilité : aptitude du logiciel à pouvoir être combiné à d'autres logiciels
◊ Efficacité : aptitude du logiciel à bien utiliser les ressources matérielles (mémoire, CPU, devices, ...)
◊ Portabilité : facilité à être porté sur de nouveaux environnements matériel et/ou logiciel
◊ Traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges avec un composant
logiciel

• Qualités (externes/internes) du logiciel (fin):


◊ Vérifiabilité/testabilité : facilité de préparation des procédures de recette et de certification
◊ Intégrité : aptitude du logiciel à protéger ses différents composants contre des accès ou des
modifications non autorisés
◊ Maintenabilité : aptitude du logiciel à être facilement modifié
◊ Facilité d'utilisation : ...
◊ ...

• Et si on parlait de vos logiciels?


◊ Quelle(s) qualité(s) accordez-vous à vos logiciels ?
◊ Iriez-vous jusqu'à garantir leur fiabilité (validité + robustesse ) ?
◊ Sauriez-vous le démontrer ?
◊ Quels sont, selon vous, les logiciels fiables dont vous disposez?
◊ Quels sont, selon vous, les logiciels peu fiables dont vous disposez?
◊ Pourquoi douteriez-vous de la qualité de vos logiciels maison ?

– Un BESOIN ressenti par un CLIENT


– Une EQUIPE dirigée par un MANAGER
– Un OBJECTIF de satisfaction du BESOIN
• Respecter la Qualité, les Délais et les Coûts :
• Mission Impossible ?
• Quelle méthode employer pour réussir ?
– Avez-vous un référentiel pour aider le Manager ?
– Est-il utilisé et respecté par tous ? Pourquoi ?
– Comment sont définis les autres rôles du projet ?

• La qualité totale
◊ Introduction d'un cycle de vie
– Choix d'un processus de développement
– Application de méthodes et de notations adaptées
– Utilisation d'outils intégrés dans un environnement
◊ Organisation rigoureuse des développements
– Définition d'un projet
– Mise en place d'une équipe de développement
– Définition et suivi d'un Plan Qualité

• Les enjeux de la qualité:


◊ Enjeu commercial
◊ Enjeux technologique et culturel
◊ Enjeu pour les directions
◊ Enjeu organisationnel
◊ Enjeu économique

• Définition de la qualité:
◊ Qualité = l'ensemble des caractéristiques d'une entité qui lui confèrent l'aptitude à satisfaire des
besoins exprimés et implicites (NF ISO 8402)

15
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ Qualité = l'ensemble des activités préétablies et systématiques nécessaires pour donner la confiance
appropriée en ce qu'un produit ou un service satisfera aux exigences données relatives à la qualité (NF
X 50-120)
◊ Discipline consistant à étudier, planifier et mettre en oeuvre des activités destinées à garantir que la
conception, la maîtrise, les méthodes et les techniques d’un projet aboutissent à un produit de niveau
de qualité satisfaisante.
◊ Règles :
− Écrivez ce que vous faites
− Faites ce qui est écrit
− Prouvez que vous le faites.
◊ Règles :
− Écrivez ce que vous faites
− Faites ce qui est écrit
− Prouvez que vous le faites.

1.4. Politique versus système qualité

1.5. Environnement de la qualité

16
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.6. Exigences du logiciel et de la qualité: où se situe la qualité?

17
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
18
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
19
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
20
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
CHAPITRE II : BESOINS DES UTILISATEURS ET PROCESSUS LOGICIELS

Ce chapitre présente, définit et décrit brièvement les techniques de récolte des données ainsi que la modélisation des
besoins en cas d’utilisation.
1.1. Analyse des besoins et la problématique dans les projets en systèmes d’information.

Analyse des besoins Que veut dire Rothschild


Problématique “There are three ways to lose money:
Capture des besoins Women, gambling and engineers.
Définition des besoins The two former are the more comfortable ones,
(Spécification des besoins) The later the most certain.”
Problématique
- Beaucoup de systèmes informatiques ne
sont jamais utilisés car ils ne correspondent
pas aux besoins du client !
- « Ce n’est pas ce que je voulais … »
- « Ça ne sert à rien … »
- « Comment je fais ça ? »
- « Ce n’est pas le bon résultat ! »
- « Je vous avais dit que je voulais ça ! »
- …
Problématique Comment faciliter la définition des besoins des utilisateurs?
- Difficulté à définir clairement et rapidement - Une réalité limite presque toutes les méthodes
les besoins des utilisateurs recensées:
• Possibilités inconnues ou nouvelles - On ne peut pas fixer les besoins des utilisateurs avant de
débuter le développement. Ils sont susceptibles
• Technologie n’est pas connue et maîtrisée
d’évoluer tout au long du projet.
par les utilisateurs
• Solution proposée a un impact sur les - Les méthodes dites AGILE ont la particularité de
processus et méthodes de travail en place considérer cette limite dans leur application

• Attentes hétérogènes entre les utilisateurs • L’analyse n’est plus une phase finie dans le temps
pour un même projet • L’analyse et le développement se font
conjointement
• L développement se fait progressivement, selon les
besoins connus à chaque itération ou livrable

21
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.2. Les risques et les difficultés de la récolte des besoins

Quelques chiffres
- Répartition des coûts de développement
• Spécification : 6%
• Conception : 5%
• Codage : 7%
• Tests et validation : 15%
• Maintenance : 67%
- Coûts de correction des erreurs provenant
• Exigences et spécification : 56%
• Conception : 24%
• Codage : 10%
• Autres : 10%

22
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.3.Les causes des difficultés à récolter les besoins

Causes Des difficultés réelles


 Le client ne sait pas ce qu’il veut  Difficultés de communiquer
 Le client ne sait pas exprimer ce qu’il veut - Difficulté d’être précis, cohérent, complet
 L’informaticien ne comprend pas le client - Différence de culture :
 Le client ne comprend pas l’informaticien o Les utilisateurs ne sont pas informaticiens
 Ce que le client veut n’est pas ce qu’il voulait …
o Les informaticiens ne connaissent pas le
domaine …
 Complexité du problème
- Problème non formalisé
- Problème complexe
 Évolutivité

Conception Centrée Utilisateur Conception participative et centrée utilisateur


- Norme ISO 13407 - 5 règles [Bruillard et al 2000]
- Les 5 principes de la conception centrée utilisateur  Partir d’un besoin réel
• Une analyse des besoins des utilisateurs, de  Travailler au sein d’une équipe pluridisciplinaire
leurs tâches et de leur contexte de travail
 Construire des maquettes et des prototypes
• La participation active des utilisateurs à la
 Évaluer (formative) très tôt auprès des
conception
utilisateurs
• Une répartition appropriée des fonctions entre
 Décideurs
les utilisateurs et la technologie
 Gestionnaires
• Une démarche itérative de conception
 Professionnels ou employé(e)s
• L’intervention d’une équipe de conception
multidisciplinaire  Centrer la conception sur les besoins réels des
utilisateurs

Satisfaction des attentes des utilisateurs - Cela suppose également, tout au long du processus de
conception, une approche centrée sur l'utilisateur
- Une des mesures de qualité privilégiée lorsque
cible, par:
l'on parle des interfaces Web est leur utilisabilité.
• Une attention immédiate et continue aux
- L'utilisabilité englobe plusieurs qualités :
utilisateurs,
• L'utilité par rapport à la tâche et aux services
• Une conception intégrée (conception de
rendus,
l'interface, du manuel, de la formation et de
• L'accessibilité des informations pour les l'information des utilisateurs, de
utilisateurs, l'accompagnement du changement (conception
d'intranet) par exemple))
• La facilité d'apprentissage et la facilité
d'utilisation, • Une évaluation immédiate et continue auprès des
utilisateurs,
• L'attrait visuel de l'interface.
• Une conception itérative.
- Si les principes précédents sont respectés, alors
l'utilisateur a toutes les chances d'être satisfait. - Si les principes précédents sont respectés, alors
l'utilisateur a toutes les chances d'être satisfait.

23
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.4. Analyse et définition des besoins
L’analyse des besoins est centrée sur l’utilisateur qui est au centre du développement de l’application. Cela suppose
également, tout au long du processus de conception, une approche centrée sur l'utilisateur cible, par:
• Une attention immédiate et continue aux utilisateurs,
• Une conception intégrée (conception de l'interface, du manuel, de la formation et de l'information des
utilisateurs, de l'accompagnement du changement (conception d'intranet) par exemple))
• Une évaluation immédiate et continue auprès des utilisateurs,
• Une conception itérative.
- Si les principes précédents sont respectés, alors l'utilisateur a toutes les chances d'être satisfait.

Analyse des besoins Différents rôles


 L’une des étapes les plus importantes  Identifier les différents intervenants :
- Étape déterminante pour la suite - Le(s) client(s)
- Aspects contractuels - Les utilisateurs
 L’une des étapes les plus difficiles - Le maintre d’œuvre
- Différents intervenants : le client, les - Les développeurs
utilisateurs, le développeurs, … - …
- Le problème n’est pas encore formalisé  Identifier le rôle de chacun
 Éventuellement associer les priorités
 Les informaticiens sont au service du client,
pas l’inverse
 Le client est roi (mais quand même)
Différentes étapes Capture des besoins : collecter
 Capture des besoins Objectifs
- Collecte des informations : interviews,
- Comprendre le domaine
lecture de documentation
- Comprendre le problème
- Chercher à comprendre : (1) le domaine
(1) Collecter le maximum d’informations
(2) le problème
- Lecture des documents fournis
 Définition des besoins
- Interviews du client, des utilisateurs, …
- Restitution dans un langage
- Réunions de travail
compréhensible par le client
- Identification, structuration, définition
- Collecter des exemples pour valider
d’un dictionnnaire - Étudier les systèmes existants le cas
 Spécification des besoins
échéant
- Spécification détaillée des besoins, plus
formel
- Utile pour le client, mais aussi pour le
développeurs

24
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Capture des besoins : interagir Définition des besoins
(2) Réagir et être actif !  Restituer les informations sous formes
 Établir la liste des documents consultes, les synthétique
classer  Ce qui n’est pas écrit n’existe pas
 Élaborer une liste de questions précises  Préciser les besoins, pas la solution
- Les numéroter, les dater, ...  Préciser ce que doit faire le système
- Faire référence aux documents concernés - Et aussi ce qu’il n’est pas censé faire
 Écrire un ou plusieurs documents et les
- Mais surtout pas comment il doit le faire
 Établir des priorités
diffuser
 Arriver à un consensus avec le client
 Provoquer les réunions et les mener
- Établir l'ordre du jour
- Prendre des notes
- Faire systématiquement des comptes
rendus écrits

Différents types de besoins Quelques conseils


 Besoins fonctionnels  Les besoins doivent être compris par tous
- À quoi sert le système - Utiliser la langue naturelle
- Ce que doit faire le système, les fonctions - Utiliser des schémas si nécessaires
utiles o Tout schéma doit être commenté
 Besoins non fonctionnels o Tout schéma doit toujours comporter une
- Performance, sûreté, confidentialité, légende
portabilité, etc.  Structurer le document
- Chercher les critères mesurables - Suivre un plan standard si disponible
- Numéroter les sections, références, index,

Langue naturelle … mais technique Élaboration d’un dictionnaire


 Faire des phrases courtes  Indispensable d’avoir un langage commun
 Éviter le conditionnel, futur - Définition d’un vocabulaire précis
 Éviter les termes ambigus et subjectifs, … - Client, équipes de développement,
 Parler en terme de rôles plutôt que de utilisateurs
personnes  Utilisations dans les documents et aussi le
 Numéroter les paragraphes si nécessaire logiciel
 Utilisations des références précises - Analyse des besoins (clients)
 Élaborer un dictionnaire - Base pour le développement du logiciel
(développeurs)
- Base pour l’interface du logiciel
(utilisateurs)
 Technique simple mais efficace!

25
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Format du dictionnaire Intérêt du dictionnaire
 Outil de dialogue
 Informel, facile à réaliser, facile à faire évoluer
 Permet de décrire la terminologie du domaine
- Réutilisable dans un autre projet
- Permet de décteter les ambiguités
 Montre l’essentiel du domaine d’application
 Permet d’assurer la traçabilité

Construction d’un dictionnaire Spécification des besoins


 Partir de la description du problème  Interface entre le client et le développeurs
 Repérer les groupes nominaux –> notion - Doit être compris par les deux
 Repérer les groupes verbaux -> action ou - Défini dans le détail ce qui doit être réalisé
notion - Doit être précis car contractuel
 Éliminer les synonymes  Utilisations des techniques semi-formelles
 Éliminer les termes inutiles - e.g. diagrammes de cas d’utilisation UML
 Donner des définitions simples - e.g. diagrammes de classees UML
 Permet de se concentrer sur l’essentiel
 Doit être complété et mis à jour !

Résumé Autres sources


 L’analyse des besoins est une étape essentielle Les spécifications des besoins
 Origine de toute activité de développement Besoins
La spécification des besoins doit décrire sans ambiguïté
 Problème de communication client /
le logiciel à développer. Elle est constituée d’un
informaticiens
ensemble de documents et de modèles.
Toutes personnes impliquées dans le projet doivent
 Capture des besoins : collecter l’information avoir accès à la spécification des besoins (disponible,
 Définir des besoins : restituer les besoins par exemple, à travers un serveur web sur l’intranet de
 Spécifications des besoins : définir l’organisation)
L’énoncé d’un besoin exprime un comportement ou
précisément
une propriété que le système doit respecter.
Chaque énoncé doit traduire la présence d’un
 Des techniques informelles mais utiles ! comportement très spécifique
 Besoin également des techniques plus précises

26
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Besoins fonctionnels Besoins fonctionnels
Les besoins fonctionnels expriment une action que  Besoin d’utilisabilité
doit effectuer le système en réponse à une  Besoins de performance
demande (sorties qui sont produites pour un
 Besoins de disponibilité / fiabilité
ensemble donné d’entrées) :
Ex : le système doit produire automatiquement un  Besoins de sécurité
rapport de synthèse des ventes hebdomadaires.  Besoins matériels
 Besoins de déploiement

Besoins fonctionnels Besoins de disponibilité / fiabilité


Besoins d’utilisabilité (Usability) Concernent le niveau de disponibilité qui doit être
 Font références aux aspects généraux de explicitement défnini pour les applications critiques
l’interface utilisateur Ex : exigence de disponibilité 24/24, 7/7 sauf périod de
 Ex : standard utilisé maintenance (à spécifier … )
Besoins de sécurité
 Définition de la configuration minimale du
- Peuvent définir les niveaux d’accès possibles au
navigateur (application web)
système pour les utilisateurs du système et les
systèmes externes.
- Ex : Toute information confidentielle fournie par les
clients via internet sera cryptée avec le système
XYZ ou par l’algorithme , la méthode … ABC.

Besoins matériels
- Définissent les configurations matérielles
minimales nécessaires au fonctionnement du
système
- Ex : Pentium 4, 2G, carte graphique, …
résolution …

Besoins de déploiement
- Décrivent la façon dont l’application sera
livrée à l’utilisateur final.
- Ex : Tous les logiciels du côté client vont être
téléchargés et installés à partir du navigateur,
sans que le poste du client ne soit redémarré
ou configuré manuellement.

27
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.5. Les types d'exigences

Un certain nombre de différents types d'exigences doivent être prises en compte dans le processus de validation des
besoins des utilisateurs (la norme ISO 19761: COSMIC-FF).
Tableau 1: Types d'exigences dans ECSS- E-40 Partie 1-B

Software Requirements Specification (Spécification des exigences logicielles)

1. Functional requirements (exigences 10. Software reliability requirements (exigences de


fonctionnelles) fiabilité du logiciel)
2. Performance requirements (exigences de 11. Software maintainability requirements (exigences
performance) de maintenabilité du logiciel)
3. Interface requirements (exigences d’interface) 12. Software safety requirements (exigences
sécuritaires du logiciel)
4. Operational requirements (exigences 13. Software configuration and delivery requirements
opérationnelles) (exigences de configuration et de livraison du
logiciel)
5. Resource requirements (exigences des ressources) 14. Data definition and database requirements
(exigences de définition des données et de la base
de données)
6. Design requirements and implementation 15. Human factor -related requirements (exigences
constraints (exigences conceptuelles et contraintes liés aux facteurs humains)
d’implémentation)
7. Security and privacy requirements (exigences 16. Adaptation and installation requirements
sécuritaires et de confidentialité) (exigences d’adaptation et d’installation)
8. Portability requirements (exigences de portabilité) 17. Other requirements (autres exigences)
9. Software quality requirements (exigences de
qualité du logiciel)

D’autres types d’exigences sont les techniques telles que les exigences d'interface qui comprennent l'objet interfaces
externes logiciel, les interfaces entre ces éléments logiciels et autres éléments logiciels, les interfaces entre les éléments
logiciels et produits matériels et les exigences d'interface relatives à l'interaction homme-machine (le cas échéant).
Il existe d’autres conventions de dénomination applicables à la communication de données et interface doit également
être identifié ;
 ISO/IEC 14143: parts 1-6 (framework suite)
 ISO conformant FSM Methods
o ISO/IEC 19761:2002 COSMIC-FFP
o ISO/IEC 20926:2002 IFPUG 4.1 Unadjusted
o ISO/IEC 20968:2002 Mk II Function Point Analysis
o ISO/IEC 24570:2004 NESMA functional size measurement method version 2.1

Tous comptent sur les besoins fonctionnels des utilisateurs.

28
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.6. Les techniques de récolte des besoins
Techniques de Définition et objectifs
récoltes
 La
Carte Une carte d’acteurs est une analyse visant à identifier les principaux acteurs impliqués par et dans un
projet de développement informatique.
d’acteurs  Les objectifs poursuivis à travers l’élaboration d’une carte des acteurs sont multiples et varient en
fonction du contexte dans lequel on y a recours.
 Lors de l’analyse, l’élaboration d’une carte des acteurs permet de dresser le « périmètre social et
politique » du futur système informatique à travers l’identification des acteurs directement ou
indirectement concernés par ce développement. Disposer d’une carte d’acteurs est très utile :
o Pour identifier les personnes qu’il convient de rencontrer pour réaliser des interviews ou des
observations ou les personnes à qui l’on envoie des questionnaires, notamment dans le cadre de
l’ingénierie des exigences;
o Pour contribuer à établir la liste des utilisateurs représentatifs à recruter pour un test d’utilisabilité
ou pour le prototypage;
o Pour identifier les participants à un brainstorming, à un focus groupe, à une analyse experte, à une
conférence de consensus, à une méthode participative de développement, etc.

Observations  Avant même d’être une méthode scientifique, observer est une pratique habituelle pour tout un chacun.
L’observation semble donc à priori une méthode évidente à mettre en œuvre.
 Différents professionnels utilisent l’observation dans le cadre de leur travail, avec des méthodes et des
finalités diverses (récit, vérification, exploration) : le journaliste, le laborantin, l’anthropologue, etc.
 L’observation directe en tant que méthode scientifique se différencie de la pratique habituelle par une
certaine systématisation de l’observation et une attention particulière à des situations circonscrites, à un
ensemble de faits, d’objets et de pratiques examinés de façon intensive.

Questionnaires  Le questionnaire est une liste de questions écrites adressées aux utilisateurs d’un logiciel ou d’un site
web par courrier traditionnel, par courrier électronique ou sur une page web.
 Son caractère écrit le différencie de l’interview et demande de la part des utilisateurs davantage d’efforts
pour y répondre et pour le renvoyer.
 On peut essentiellement utiliser le questionnaire à deux fins : soit pour obtenir une validation statistique
ou qualitative d’hypothèses émises, soit pour rassembler des opinions ou des suggestions.

Interviews ou L’interview (ou « entretien ») est une technique d’évaluation très répandue durant laquelle une ou plusieurs
personnes posent des questions à un ou plusieurs utilisateurs et/ou experts afin de rassembler de l’information
l’entretien et des connaissances sur un sujet particulier.
Cette méthode se distingue principalement par son caractère direct et relativement informel. L’interviewé
apporte en effet sa contribution à un projet par des réponses orales à des questions énoncées par un
interlocuteur présent face à lui (à l’exception de l’entretien téléphonique). Il s’agit donc d’un procédé de
restitution d’information assez simple et naturel.
Tri par cartes  Le tri par cartes est une méthode permettant d’observer la manière dont les utilisateurs classent et
regroupent des contenus qui leur sont présentés sur des cartes, afin de développer la structure en apparence
la plus logique possible. Cette méthode est particulièrement appropriée pour définir la structure d’un site
web.

 Plusieurs cartes, sur lesquelles sont écrits des thèmes relatifs au site web (libellé des rubriques, catégories
d’informations, etc.), sont présentées à quelques utilisateurs représentatifs du public cible. On demande à
ces utilisateurs de regrouper les cartes qui présentent les contenus liés entre eux en plusieurs tas distincts.

 Le tri par cartes permet d’identifier des regroupements possibles de contenu, en fonction des occurrences
constatées dans l’organisation des cartes par les concurrents. Cette méthode peut également indiquer la
perception par les utilisateurs des libellés des différentes rubriques du site et donc les éventuelles
ambiguïtés qui y seraient liées.

récolte des données est déterminante pour la suite et surtout la réussite d’un projet informatique. L’utilisation des
techniques appropriées aide à aller chercher les informations qu’on pourrait obtenir autrement. Nous avons identifié 15
techniques de récolte des besoins que nous regroupons en quatre catégories : 1- Les techniques de récoltes des besoins

29
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Techniques de Définition et objectifs
récoltes
Brainstorming  Le brainstorming (ou remue-méninges) consiste à rassembler un groupe de personnes choisies à qui l’on
demande d’exprimer librement leurs idées, pensées et intuitions sur un ou plusieurs thèmes. Un animateur
gère la rencontre et prend note des idées émises, qui seront, par la suite, analysées, classées et éventuellement
approfondies. Le brainstorming est facile à mettre en place et à réaliser, et ne demande qu’un minimum de
moyens matériels et humains.
 La technique entend provoquer deux choses. Premièrement, lever les inhibitions de chacun des participants.
Deuxièmement, réussir à créer une dynamique de groupe, c’est-à-dire amener chacun à ressentir les idées
émises comme étant celles du groupe et non d’une personne en particulier, et à s’appuyer sur les idées des
autres pour en formuler de nouvelles.
 Par-là, le but du brainstorming est qu’un maximum d’idées, de suggestions, de propositions de solutions,
soient générées sur un sujet donné. L’hypothèse de base est qu’il sera plus facile de rendre applicable une
idée (trop) créative que de générer une solution créative à partir d’une idée « banale ». Aussi, le
brainstorming entend faire émerger un maximum d’idées et cet impératif doit primer sur la qualité
intrinsèque des idées formulées.

Focus Group  Un focus group (on parle également de « groupe de convergence ») désigne une discussion de groupe
structurée en plusieurs phases et selon un script assez précis, défini par un modérateur en collaboration avec
l’équipe responsable du développement de l’application (un site web, un logiciel, etc.).
 Un focus groupe rassemble différentes personnes sélectionnées selon des critères établis par l’équipe de
projet. Ces participants sont invités à faire part de leurs réflexions à propos d’un sujet précis, sur base de
leur opinion et expérience personnelle.
 Généralement, plusieurs focus groupes (le plus souvent entre 3 et 10) sont menés jusqu’à ce que l’on atteigne
un point où l’information récoltée s’avère redondante, c’est-à-dire qu’elle ne livre plus rien de
substantiellement nouveau par rapport à ce qui a déjà été dit.
 Par rapport à des interviews, la mise en place des focus groupes donne la possibilité de dégager une grande
multiplicité de points de vue et de sentiments. Les focus groupes sont donc utiles pour :
o Prendre connaissance et évaluer la diversité des vues et opinions sur un sujet ;
o Donner aux participants la possibilité d’exposer et d’expliquer leurs demandes et leurs attentes ;
o Déterminer le degré de consensus existant sur un sujet donné.
 Le sujet abordé peut toucher aux attitudes et aux opinions de divers acteurs ou groupes d’acteurs quant à un
projet donné, à l’image ou au rôle d’une institution, etc.
 L’essence du focus groupe est d’amener chaque participant à se situer et à réagir par rapport aux opinions
et aux affirmations des autres. Cela permet d’aller plus en profondeur qu’avec des interviews. En effet, c’est
grâce à l’interaction propre aux focus groupes que chacun peut expliciter sa vision et son opinion selon son
propre langage. Les spécificités de vocabulaire propres à un groupe d’acteurs peuvent d’ailleurs avoir une
utilité propre et méritent parfois d’être recueillies.

Analyse  La méthode DELPHI est une méthode visant à organiser la consultation d’experts sur un sujet précis,
souvent avec un caractère prospectif important.
Experte /  Le terme « expert » ne doit pas faire croire que cette méthode est réservée à la consultation d’autorités
DELPHI scientifiques de haut rang.
 Il faut entendre par « expert » toute personne ayant une bonne connaissance pratique, politique, légale ou
administrative d’un sujet précis et ayant une légitimité suffisante pour exprimer un avis représentatif du
groupe d’acteurs auquel elle appartient. Dresser la carte des acteurs peut aider à identifier ces experts.
 Très utile dans la phase d’analyse et d’étude d’opportunité d’un projet (par exemple, d’un projet de
réalisation d’un site web ou d’un logiciel), la méthode DELPHI permet d’affiner le projet de départ via un
questionnement sur son opportunité, sur sa faisabilité et sur les différentes contraintes auxquelles le projet
sera confronté.
 Dans certains cas, des variantes de la technique peuvent également être appliquées lors des phases
ultérieures du développement du projet :
o lors de la conception de l’application, la méthode DELPHI permet d’organiser les consultations
nécessaires pour rassembler des avis et générer des consensus sur les orientations prises par le projet ;
o lors de l’évaluation de l’application, la méthode DELPHI permet de lever certaines incertitudes révélées
par les tests d’utilisabilité en questionnant les « testeurs » sur leurs divergences et en essayant, à travers
des questionnements successifs d’arriver à un consensus.

Conférences de  La conférence de consensus est issue d’un concept danois né au milieu des années 1980. S’inspirant
d’expériences américaines où des experts étaient invités à rendre un travail destiné à éclairer la prise de
consensus décision, la commission parlementaire danoise des technologies a fait appel, en plus de ces experts, à un
panel de citoyens.
 Dans la conférence de consensus, c’est in fine ce panel qui remet un avis. La méthode a donc une nature
mixte, faite d’éléments scientifiques, de touches participatives et d’une structure para-institutionnelle.
 La méthode des conférences de consensus a connu un certain succès au Danemark, mais un succès aléatoire
ailleurs. Il semble que sa réussite soit essentiellement liée à l’existence d’une certaine culture participative.
 Il ne faut pas confondre une conférence de consensus avec un système de prévention ou de résolution des
conflits comme un comité de concertation, une réunion d’information publique, une consultation, etc. Ceux-
30
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
ci n’impliquent que des citoyens directement concernés et ne visent qu’à apporter une solution à un
problème ponctuel et le plus souvent local.
 La conférence de consensus est une méthode assez novatrice qui vise à changer le rapport entre
l’administration ou le pouvoir politique, les citoyens et les experts. Elle se pose en alternative au dialogue
classique entre experts et politique, dans lequel les citoyens ne sont pas réellement impliqués et où aucune
vulgarisation n’est prévue.
 Le contexte de crise de confiance du citoyen dans la politique et les institutions explique sans doute en
partie la percée de la méthode des conférences de consensus. Sous le couvert des concepts de « société
civile » ou de « bonne gouvernance », on met en place beaucoup d’expérimentations, mais elles visent
souvent plus à la médiatisation qu’à une véritable participation démocratique.
 La conférence de consensus est une tentative plus sérieuse et plus formalisée.
 L’idée n’est pas de créer un mode de partage direct de la prise de décision avec le citoyen. D’ailleurs, afin
de ne pas dénaturer la technique de la conférence de consensus, il importe de ne pas lui donner des ambitions
au-dessus de ses possibilités : la démarche ne peut prétendre à la même valeur qu’un vote démocratique et
il ne s’agit pas davantage d’un sondage d’opinion ou d’un référendum officiel qui donnerait les lignes de
conduite d’une politique.
 Le but de la mise sur pied d’une conférence de consensus doit être de fournir au Parlement (ou à l’autorité
qui a le pouvoir de décision) une information nuancée sur des sujets controversés en tenant compte de l’avis
et des questions que se posent les citoyens, dans le but d’aider le pouvoir responsable dans sa prise de
décision. C’est précisément dans cet objectif que la méthode s’est développée au Danemark.
 Les conférences de consensus sont beaucoup utilisées (généralement à une plus petite échelle) dans le
domaine de la santé publique, où les controverses sont fréquentes et où les considérations sociales ou
éthiques sont incontournables.

Méthode  La méthode participative consiste à associer activement les utilisateurs au développement d’un projet
(par exemple, à la réalisation d’un site web ou d’un logiciel). Un des points clefs de cette méthode est
participative d’établir un protocole formel de participation qui dépasse la simple consultation des utilisateurs. Cette
méthode repose sur une double hypothèse :
o les utilisateurs sont les meilleurs experts des changements qui les concernent. Ils possèdent un savoir et
un savoir-faire sur les procédures dont ne disposent généralement pas les concepteurs et les
développeurs de projet. Par exemple, personne ne connaît mieux une procédure administrative, ses
détails ou ses exceptions que les agents de l’administration qui l’accomplissent quotidiennement ;
o la motivation et la satisfaction des utilisateurs d’un projet augmentent si on les fait participer activement
au développement et si on considère les facteurs sociaux, organisationnels et éthiques dont ils peuvent
être porteurs comme des contraintes tout aussi importantes que celles liées à la technique. Ainsi, on
s’efforcera par exemple de montrer aux agents de l’administration que les valeurs sociales ou éthiques
dont ils sont garants dans le cadre de leur travail quotidien sont aussi importantes que les aspects liés au
progrès technique.
 La méthode participative consiste donc à associer de manière formelle et légitime les utilisateurs dans
la conception et le développement d’une application qui les concerne.
 Il importe de noter ici que ces objectifs ne peuvent se réaliser que si et seulement si le projet n’a pas de
prétention rationalisante, c’est-à-dire que la méthode est totalement incompatible avec toutes les
démarches menées dans l’optique d’une restructuration et se traduisant par des pertes d’emplois. En effet,
la participation n’est dans ce cas ni socialement souhaitable ni éthiquement acceptable.
 De très nombreuses variantes des méthodes participatives ont été développées, particulièrement en Europe
du Nord, dans des pays où la tradition de la co-gestion et du consensus gouverne les rapports sociaux de
production. Cette culture de la participation est un facteur important pour éviter certaines réticences des
travailleurs ou des organisations syndicales qui les représentent et contribuer au succès de la démarche.
 La méthode participative expliquée dans ce qui suit est une méthode d’origine anglaise appelée ETHICS
(« Effective Technical & Human Implémentation of Computer-based Systems »). Cette méthode est une des
plus anciennes et une des plus validées. Elle a été développée par Enid Mumford et structure sa démarche
autour du concept de « job satisfaction ». En d’autres termes, les réflexions des participants quant au projet

auprès d’un individu ; 2- Les techniques de récoltes des besoins auprès d’un groupe d’individus ; 3- Les techniques de
récoltes des besoins à l’aide des logiciels développés et 4- La technique de récoltes des besoins à l’aide de la rédaction
du cahier des charges des exigences logicielles à développer.

1.6.1. Les techniques de récoltes des besoins auprès d’un groupe d’individus
Cinq techniques disponibles :

31
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
1.6.2. Les techniques de récoltes des besoins à l’aide des logiciels développés
Quatre techniques disponibles :

Techniques Définition et objectifs


de récoltes
Prototypage  Un prototype est une version simplifiée d’une partie de l’application finale (par exemple un site web ou un
logiciel). La méthode du prototypage consiste à effectuer un test « grandeur nature » sur cette version
partielle et toujours inachevée du système en cours de développement pour obtenir rapidement et à moindre
coût une idée du bon ou du mauvais fonctionnement de l’application.
 Il existe une très grande variété de prototypes, du prototype très simple, rapide et économique à réaliser, au
prototype « haute-fidélité », beaucoup plus proche de l’application finale mais également beaucoup plus
coûteux en temps et en ressources. En général, on considère que le prototype se définit selon trois grands
critères (mais la terminologie employée peut varier).
 Une première distinction peut être effectuée entre :
o Le prototype « à jeter », qui est uniquement utilisé pour les tests de l’application mais ne sert pas de
base à l’application finale ;
o Le prototype évolutif (ou « itératif »), qui consiste à réutiliser certaines (ou toutes les) parties du
prototype pour servir de base à l’application finale. Par exemple, plusieurs versions intermédiaires
successives d’un site web peuvent mener au site web final, en fonction des remarques émises lors des
différentes simulations ;
o Le prototypage incrémental, qui consiste à ajouter au prototype de nouvelles fonctionnalités au fur et à
mesure du développement de l’application.
 Ensuite, un prototype peut être :
o Horizontal ou « statique », c’est-à-dire qu’il passe en revue les différents composants de l’interface
homme-machine sans véritable interactivité (les commandes ne fonctionnent pas) ;
o Vertical ou « dynamique », c’est-à-dire qu’il propose un ensemble de fonctionnalités de la future
application et permet à un utilisateur de dérouler un scénario d’utilisation typique lors d’un test
d’utilisabilité intermédiaire.
 Enfin, le prototype est soit « basse-fidélité », soit « haute-fidélité » :
o Le prototype « basse-fidélité » (« low-fidelity prototyping ») est généralement réalisé rapidement et à
moindre coût. Il n’offre pas de caractère interactif et ne présente pas nécessairement de ressemblance
visuelle avec l’application finale ;
o Le prototype « haute-fidélité » (« high-fidelity prototyping »), beaucoup plus lourd et coûteux à
développer, généralement interactif et ressemblant aussi fidèlement que possible à l’application finale.
 Ainsi, un prototype papier (ou réalisé sur base de transparents PowerPoint) constitue un prototype « à jeter »
(il n’est pas repris pour servir de base au développement de l’application finale), horizontal (il s’intéresse
essentiellement à l’interface homme-machine) et « basse-fidélité ».
 A l’inverse, une partie d’un site web testée par quelques utilisateurs (par exemple une seule rubrique du site
web) est un prototype évolutif (il sera repris, une fois validé, dans la version finale du site), vertical et
« haute-fidélité ».
 Les différentes techniques de prototypage servent en général de base de travail à d’autres méthodes
d’implication des utilisateurs. A titre d’exemple, la méthode du prototypage peut être complétée par :
o un focus groupe ou une séance de brainstorming, par exemple lorsque les concepteurs présentent aux
autres membres du groupe de développement de l’application une maquette ou un « prototype papier »
du site web ou du logiciel en les invitant à réagir et donner leur avis à propos de la structure, de
l’interface ou du graphisme du site ;
o une évaluation experte, par exemple lorsqu’un prototype horizontal présentant l’interface de
l’application sert de base à l’inspection des critères d’ergonomie et d’utilisabilité par un expert ;
o un test d’utilisabilité, dans le cas d’un prototype vertical « dynamique » testé par un ou plusieurs
utilisateurs représentatifs. Dans ce cas, plus le développement est avancé et plus le prototype est
proche de l’application finale, plus la méthode du prototypage se rapprochera du test d’utilisabilité.
L’utilisation d’un prototype papier animé par un membre de l’équipe de développement et testé par
des utilisateurs représentatifs se rapproche également du principe du test d’utilisabilité.
 Le principal objectif du prototypage est de pouvoir pré-tester l’application avant même qu’elle ne soit prête
et de déceler et corriger les erreurs de conception au fur et à mesure du développement. Selon le type de
prototype choisi, la méthode du prototypage est complétée par d’autres méthodes d’implication des
utilisateurs (observation, brainstorming, focus groupe, test d’utilisabilité, évaluation experte, etc.).
 Un avantage du prototypage est aussi de pouvoir tester une partie du site web ou du logiciel développé
(interface homme-machine, structure, une seule rubrique du site, etc.) indépendamment des autres éléments
de l’application.

32
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Test  L’évaluation experte (également appelée « évaluation heuristique » ou « inspection ergonomique ») est une
méthode qui permet de repérer rapidement et à moindre coût les problèmes d’ergonomie ou d’utilisabilité
d’utilisabilité d’un logiciel ou d’un site web.
 Par « utilisabilité », on désigne la qualité d’une application qui est facile et agréable à utiliser et à
comprendre. L’utilisabilité d’une application se mesure à trois grands critères objectifs :
o L’efficacité, c’est-à-dire l’atteinte des objectifs par l’utilisateur ;
o L’efficience, c’est-à-dire l’économie des ressources nécessaires pour atteindre ces objectifs ;
o La satisfaction, c’est-à-dire le sentiment d’agrément ou le contentement procuré à l’utilisateur lors de
l’utilisation de l’application.
 Un site, un logiciel ou une application sera donc utilisable si l’utilisateur peut réaliser sa tâche (efficacité),
qu’il consomme un minimum de ressources pour le faire (efficience) et que le système est agréable à utiliser
(satisfaction).
 D’autres aspects peuvent entrer en ligne de compte pour évaluer l’utilisabilité générale de l’application,
comme la sécurité ou maîtrise (le nombre d’erreurs commises par l’utilisateur et la rapidité de corrections
de ces erreurs) et la facilité d’apprentissage (la compréhension correcte et l’assimilation rapide du mode de
fonctionnement).
 Le principe de l’évaluation experte est de demander à un ou plusieurs experts en utilisabilité de passer en
revue les différentes composantes de l’application (l’interface homme-machine, la structure du système, la
navigation, les fonctionnalités disponibles, etc.) et de vérifier si ces composantes respectent certains critères
d’ergonomie et d’utilisabilité établis et listés dans une grille de critères.
 Recourir à une grille de critères pour fournir un cadre de travail objectif permet de limiter les risques de voir
l’évaluation biaisée par la subjectivité et les goûts personnels des évaluateurs.
 De nombreuses grilles de critères générales existent et sont disponibles sur le web ou dans des ouvrages
spécialisés, mais il peut être utile de construire sa propre grille, en tenant compte de certaines particularités
du site ou du logiciel que l’on désire évaluer. Une méthode efficace pour construire sa propre grille de
critères est de passer en revue plusieurs applications concurrentes, en faisant un relevé détaillé des bons et
des mauvais choix ergonomiques.

Données  Une fois qu’un système informatique (un logiciel, un site web, etc.) est mis en service, il est très souvent
possible de recueillir de nombreuses données à propos des utilisateurs, soit en enregistrant les traces laissées
d’usage par les utilisateurs lors de leur « passage » sur l’application, soit en récoltant et en analysant les informations
(utilisabilité) que les utilisateurs eux-mêmes prennent l’initiative d’adresser aux gestionnaires de l’application
(notamment par courrier électronique).
 L’ensemble de ces informations (« passives » et « actives ») présentent l’avantage de refléter les
préoccupations réelles des utilisateurs à propos de l’application sans demander d’efforts trop considérables
de la part des gestionnaires du logiciel ou du site web. Elles peuvent donc grandement contribuer à améliorer
le système, par exemple en mettant en évidence les sections qui sont les plus utilisées et celles qui ne le sont
pas ou en attirant l’attention sur des problèmes d’ergonomie ou d’utilisabilité, sur des liens inactifs, sur des
informations ou des fonctionnalités supplémentaires que l’application pourrait proposer, etc.
 Dans le cadre d’une démarche de prise en compte des besoins et attentes des utilisateurs dans un souci
d’amélioration continuelle de l’application, il est évidemment important de tenir compte de ces données
(parfois très hétérogènes) fournies de manière active ou passive par les utilisateurs. Il convient donc de
développer certaines méthodes pour en systématiser le traitement et en tirer un réel bénéfice.
 Toutefois, l’analyse et le traitement de ces informations d’usage ne peuvent se substituer à d’autres
méthodes d’évaluation d’une application impliquant les utilisateurs comme les questionnaires ou les
interviews qui analysent plus en détail les attentes et besoins des utilisateurs, ou comme les tests
d’utilisabilité ou l’évaluation experte, qui s’intéressent de manière plus approfondie et plus détaillée à
l’ergonomie et à l’utilisabilité du système

Évaluation  L’évaluation experte (également appelée « évaluation heuristique » ou « inspection ergonomique ») est une
méthode qui permet de repérer rapidement et à moindre coût les problèmes d’ergonomie ou
experte d’utilisabilité d’un logiciel ou d’un site web.
 Par « utilisabilité », on désigne la qualité d’une application qui est facile et agréable à utiliser et à
comprendre. L’utilisabilité d’une application se mesure à trois grands critères objectifs :
o L’efficacité, c’est-à-dire l’atteinte des objectifs par l’utilisateur ;
o L’efficience, c’est-à-dire l’économie des ressources nécessaires pour atteindre ces objectifs ;
o La satisfaction, c’est-à-dire le sentiment d’agrément ou le contentement procuré à l’utilisateur lors de
l’utilisation de l’application.
o Un site, un logiciel ou une application sera donc utilisable si l’utilisateur peut réaliser sa tâche
(efficacité), qu’il consomme un minimum de ressources pour le faire (efficience) et que le système est
agréable à utiliser (satisfaction).
 D’autres aspects peuvent entrer en ligne de compte pour évaluer l’utilisabilité générale de l’application,
comme la sécurité ou maîtrise (le nombre d’erreurs commises par l’utilisateur et la rapidité de corrections
de ces erreurs) et la facilité d’apprentissage (la compréhension correcte et l’assimilation rapide du mode
de fonctionnement).

33
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
 Le principe de l’évaluation experte est de demander à un ou plusieurs experts en utilisabilité de passer en
revue les différentes composantes de l’application (l’interface homme-machine, la structure du système, la
navigation, les fonctionnalités disponibles, etc.) et de vérifier si ces composantes respectent certains critères
d’ergonomie et d’utilisabilité établis et listés dans une grille de critères.
 Recourir à une grille de critères pour fournir un cadre de travail objectif permet de limiter les risques de voir
l’évaluation biaisée par la subjectivité et les goûts personnels des évaluateurs.
 De nombreuses grilles de critères générales existent et sont disponibles sur le web ou dans des ouvrages
spécialisés, mais il peut être utile de construire sa propre grille, en tenant compte de certaines particularités
du site ou du logiciel que l’on désire évaluer. Une méthode efficace pour construire sa propre grille de
critères est de passer en revue plusieurs applications concurrentes, en faisant un relevé détaillé des bons et
des mauvais choix ergonomiques.

1.6.3. La technique de récoltes des besoins à l’aide de la rédaction du cahier des charges des exigences
logicielles à développer
Une technique disponible :

Ingénierie des  L’ingénierie des exigences (ou « analyse des exigences ») désigne la première étape du développement
d’une application informatique (par exemple, un site web ou un logiciel) qui consiste à définir clairement
exigences les exigences imposées à l’application avant de la concevoir. Par « exigences », on entend les différentes
caractéristiques attendues de l’application telles que ses fonctionnalités, ses performances, son efficacité,
son coût, sa disponibilité, sa sécurité, etc.
 Pour découvrir ces exigences, de nombreuses méthodes d’implication des utilisateurs sont appliquées :
carte des acteurs, questionnaires, interviews, observation, brainstorming, etc.
 L’ingénierie des exigences débouche sur l’élaboration d’un document appelé cahier de charges dans
lequel les exigences sont décrites. Ce cahier des charges sert notamment de base :
o À la conception et au développement proprement dit de l’application ;
o À l’évaluation de l’adéquation entre l’application et les exigences auxquelles elle est supposée
répondre (les « besoins » des utilisateurs).

1.7. Cycles de vie du 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 les activités suivantes :
- Définition des objectifs, consistant à 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.
- 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, consistant à définir précisément chaque sous-ensemble du logiciel.
- Codage (Implémentation ou programmation), soit la traduction dans un langage de programmation des
fonctionnalités définies lors de phases de conception.
- Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté
conformément aux spécifications.

34
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
- Intégration, dont 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, visant à produire les informations nécessaires pour l'utilisation du logiciel et pour des
développements ultérieurs.
- Mise en production,
- Maintenance, comprenant 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.
Cycle de développement et cycle de vie du logiciel : les phases

- Analyse de l'existant et définition des besoins, du système d'information et du logiciel


- Conception du système d'information et du logiciel
- Réalisation (ou codage, programmation): traduction des algorithmes dans un langage compréhensible par un
ordinateur
- Tests :
 Vérification du logiciel (i.e. système informatique)
 Validation du logiciel
 Vérification du système d'information
 Validation du système d'information Vérification : le produit en cours d’élaboration répond-il à la définition des
besoins ? (est-ce bien le produit ?)
Validation : le produit en cours d’élaboration remplit-il les fonctionnalités désirées par l'utilisateur? (est-ce le bon produit
?)
- Exploitation : utilisation du logiciel une fois installé (et dont on fait la recette)
- Maintenance
 Correction des erreurs
 Amélioration des fonctions existantes
 Ajout de nouvelles fonctionnalités

1.7.1. Cycles de vie en cascade (ou en chute d’eau)

35
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Critiques :
- Recouvrement de phases
- Avancées et retours d’une seule phase du cycle de développement à la fois
- Impact de la maintenance sur toutes les phases du développement
- Contacts avec l’utilisateur restreints à la phase d’analyse

1.7.2. Cycles de développement en V

- Système signifie ici système d'information (manuel et informatisé)


- Modèle de l'AFCIQ (Association Française pour le Contrôle Industriel de Qualité) avec le vocabulaire suivant :
Spécification fonctionnelle \Conception préliminaire \ Conception détaillée \ Codage / Tests unitaires /Tests
d'intégration / Recette

1.7.3. Cycles de développement en M

3 activités interviennent durant toute la durée du développement en V

36
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
- Gestion de projet : pilotage du projet
- Gestion des configurations : gestion des différentes versions du produit
- Assurance qualité : contrôle systématiquement que le produit en cours est cohérent et complet, en le confrontant à
des normes préétablies si elles existent

1.7.4. Cycles de développement en W

- Maquette : défilement d'écrans donnant une idée de ce que sera la future application (sans accès aux données)
- Les maquettes sont élaborées par les informaticiens et validées par les utilisateurs
- Avantages du maquettage
 Gain de temps sur les phases en aval (2nd V)
 Limitation des erreurs lors de la recette

1.7.5. Cycles de développement en spirale

- Prototype : application en réduction (avec accès aux données)


- Expérimentation : tests de la part des utilisateurs du produit dans sa version actuelle (éventuellement définitive)
- Bilan : critique de l’expérimentation
- Généralisation de l’approche par itération
- Ex. : conception d’outils de pilotage (car une forte réactivité aux besoins non stables des utilisateurs est nécessaire)

1.7.6. Cycles de développement composite


37
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Démonstration : présentation du produit aux utilisateurs

2.8.7. Cycles de vie de l’ISO

2.7.8. Cycles de vie d’EuroMethode

Chiffres : coût moyen relatif de chaque phase (du cycle de développement du logiciel) pour une application de gestion

38
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
- Analyse et Conception : 44 %
- Réalisation : 28 %
- Tests : 28 %

Chiffres: coût relatif de correction d'une erreur selon la phase (du cycle de vie du logiciel) au cours de laquelle elle a été
détectée
Analyse : 1
Conception: 2
Réalisation: 5
Tests: 10
Exploitation et Maintenance : plus de 100
- Remarque : plus de 80 % des erreurs sont introduites durant les phases d'analyse et de conception
- Les coûts de la maintenance corrective (ni adaptative, ni évolutive) peuvent aller jusqu'à deux fois ceux du
développement Exemple pathologique (système avionique) : coût de développement de 30$ par instruction mais
coût de maintenance de 4000$ par instruction

39
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
CHAPITRE III : GESTION DE LA QUALITÉ

Fondements, contrôle des coûts, méthodologie, mesures, outils et déploiement d’un système d’assurance qualité du
logiciel

3.1. aîtrise de la qualité – modèles de maturité

• CMM: Capability Maturity Model for software


• SPICE: référentiel dédié à l’amélioration des processus logiciels
• TRILLIUM: de Bell Canada pour les Télécommunications
• BOOTSTRAP: méthode issue d’un programme de recherche européen

• Le modèle CMM: Capability Maturity Model for software


◊ Motif de création du modèle
− Impossibilité de savoir ce qui est le plus important à améliorer lors du processus de
développement d’un logiciel
◊ À quoi sert ce modèle?
− Améliorer le processus de développement
− Mesurer le niveau de maturité d’une organisation

• Le modèle CMM: Capability Maturity Model for software


◊ Utilisé comme norme pour évaluer l’état du processus dans une organisation particulier
◊ Utilisé comme guide pour identifier et mettre en priorité les actions de l’effort d’amélioration du
processus
◊ Inclut 5 niveaux, et 18 «régions clés du processus» (key process areas (KPA))
◊ On peut utiliser un questionnaire basé sur le modèle pour évaluer le maturité de capacité d’une
organisation particulier.

40
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le processus initial du CMM
Pas de mécanisme pour planifier et traquer le travail du personnel
Si on a des procédures définies, on les abandonne quand les crises viennent (et ils viennent souvent)

Pour améliorer le processus initial du CMM


Il faut comprendre la différence entre le progrès et la vitesse
Il faut comprendre la différence entre les régions clefs du processus:
Gestion du projet ----- estimation
Supervision active ----- revue du progrès périodique (chaque 3 mois par exemple)
Assurance de la qualité ----- établissement d’une organisation de l’AQ ( 5-6 % de l’organisation totale)
Contrôle des changements.

Le processus répétitif du CMM


Il faut comprendre la différence entre le progrès et la vitesse
Il faut comprendre la différence entre les régions clefs du processus:

41
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Gestion du projet ----- estimation
Supervision active ----- revue du progrès périodique (chaque 3 mois par exemple)
Assurance de la qualité ----- établissement d’une organisation de l’AQ ( 5-6 % de l’organisation totale)
Contrôle des changements.

Pour arriver au niveau défini du CMM


Établissez un groupe de processus
 1-3 % d’organisation d’élaboration
Établissez une architecture pour le processus d’élaboration
Qui inclut les activités techniques et de gestion pour l’exécution effective du processus d’élaboration
Introduisez une famille de méthodes et de technologies pour faire:
L’inspection du conception et du code
Les méthodes de conception formel ou semi-formel
Un système de control des bibliothèques de programmes
Les méthodes de testage exhaustives.

Le processus défini du CMM


Les processus pour l’élaboration du logiciel sont normalisé partout dans l’organisation
Le génie logiciel est intégré dans les processus de gestion de genre plus grand qu’un projet en particulier
Essai à l’acide :
Quand une crise arrive, le personnel continuent a utilisé le processus
Ce niveau est plus ou moins qualitatif :
42
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Pas beaucoup de donnés pour évaluer l’efficacité du processus

Le processus défini du CMM - KPA


Les inspections formelles
La coordination entre les groupes
Le génie logiciel concentré sur les produits
Gestion du logiciel intégré
Programme de formation
Définition du processus du logiciel
Responsable du processus du logiciel

Pour arriver au niveau « gestion intégré » du CMM


Établissez les mesures du processus pour identifier la qualité et le coût de chaque étape dans le processus
L’analyse des coûts et des avantages
Établissez une base de données du processus et fournissez les ressources pour le maintenir, y compris le ramassant
des données
Évalue la qualité du produit à chaque étape et le rapporte aux gestionnaires.

Le processus de « gestion intégré » du CMM


On mesure la productivité et la qualité partout dans l’organisation
On trouve des mesures pour les processus du logiciel clefs
On utilise les techniques statistiques pour le contrôle de la qualité
La clé est la définition des donnés
Seulement les mesures essentielles ($)
On n’utilise jamais les donnés de processus pour comparaisons entre les projets et les individus

La gestion de la qualité
La gestion quantitative du processus.
43
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le processus « optimisé » du CMM
Pour arriver au niveau « optimisé » du CMM
Le ramassage automatique des données du processus
Utilise les données pour analyser et modifier le processus

On se concentre sur l’amélioration continuel du processus Utilise les données pour analyser et modifier le processus
Supporté par l’analyse quantitative des tendances du processus par rapport aux faiblesses et succès du processus
On introduit les nouveau technologies et les améliorations au processus quand on a des donnés qui indique que les
changements va vraiment aider
On a des donnés qui nous aident a ajuster le processus
On a la capacité de utilisé les ressource ou ils aideront le mieux
La gestion du changement du processus
La gestion du changement de la technologie
La prévention des défauts

Défaut et avenir du CMM


Le CMM n’est pas une arme fatale (silver bullet)
Un processus mature ne garantie pas un produit de qualité (mais il indique…)
Ça ne marche pas tres biens pour les projets plus petit
le Personal Software Process (PSP) et le Team Software Process (TSP) essaient d’aider aux besoin
L’échelle est un peu brute
Si on échoue un des KPA, on échoue le niveau
Il y a des CMM pour le logiciel, les systèmes, le gestion du personnel, l’acquisition, l’élaboration des produits avec
un équipe intégré…
Initiative récente: CMM Integration (CMMI)

De CMM à CMMI vs ISO 9001


CMM d’abord orienté logiciel, puis généralisé
ISO 9001 orienté sur la qualité des processus et pas sur la qualité des produits
On peut être certifié ISO 9001 et développer de très mauvais produits
On peut être certifié ISO 9001 et développer des produits qui ne servent à personne

Les évolutions d’ISO 9000 vers ISO 9001:2000:


Plus de flexibilité : prise en compte du caractère itératif et fluctuant du logiciel

44
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Réduit l’obligation de documentation, si on peut prouver que le processus fonctionne
Amélioration continue
Satisfaction client
Audit plus tourné vers l’efficacité de l’organisation.

Domaines de processus CMMi

Niveau 2 de CMMi:
10 pratiques génériques
Plusieurs objectifs spécifiques pour chacun des processus
Plusieurs pratiques spécifiques pour chaque objectif

Bénéfices du niveau 2 de CMMi:


Compréhension des besoins clients
Bonne préparation des projets
Bon suivi
Réduction des coûts de développement
Réduction des délais de livraison
Amélioration de la qualité du produit

Niveau 3 de CMMi:
Capitalisation des connaissances
Généralisation de l’expérience du niveau2 à tous les projets
Suite de la mise en place de processus de développement:
45
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Développement des exigences
Solution technique (conception)
Intégration produit
Gestion du risque
Vérification
Validation
Organisation généralisée, gestion de l’équipe, des fournisseurs
Difficilement mesurables
(Re-)Penser son organisation
Donner un cadre qui permet la créativité
Evite les pertes de temps, d’argent et d’énergie inutiles

• Le SPICE:
◊ Motif de création du modèle
− Nécessité de bâtir un référentiel dédié à l’amélioration des processus logiciels
◊ À quoi sert ce modèle?
− Recouvrir le processus logiciel de la démarche ISO en ciblant sur le développement, la
maintenance et la sous-traitance
− Évaluer le processus de développement
◊ Quelles sont les principales actions
− Planifier, manager, suivre, contrôler et
− Améliorer le développement, l’exploitation, l’évolution et le support de logiciels.

Principe et structure du modèle

46
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
3.2. Maîtrise de la qualité ISO 15504 ou CMM – qualité du produit et performance du projet
• Qualité s’applique toujours au projet et correspond à un document décrivant le protocole du projet en incluant
les points suivants :
◊ la formalisation des Exigences et des contraintes du projet,
◊ l’organisation de la communication,
◊ la précision de la méthodes et du processus de production,
◊ la description des livrables et des conditions de recette à chaque étape,
◊ la planification de contrôles systématiques de qualité appliqués aux livrables
• Ces informations se répartissent en deux parties majeures ou font l’objet de deux documents distincts :
◊ le Plan d’Assurance Qualité du logiciel,
◊ le Plan d’Assurance Performance du projet

• Le niveau de besoin ou la notion de « niveaux de services » recouvre entre autres :


◊ le niveau de conduite de projet,
◊ le niveau de levée des risques,
◊ le niveau de levée des risques,
◊ le niveau de qualité documentaire,
◊ le niveau de qualité documentaire,
◊ le niveau de qualité applicative.

• Qualité applicative et qualité techniques :


◊ La qualité applicative se mesure par le degré de satisfaction de l’utilisateur à l'égard :
◊ de la couverture fonctionnelle de ses besoins réels,

47
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ de l’ergonomie générale et des facilités d’appropriation,
◊ des temps de réponse de l’application,
◊ de divers autres facteurs d’appréciation.
◊ La qualité technique est un ensemble de critères qui couvre :
◊ le nombre de « bugs » résiduels,
◊ la lisibilité du code et sa documentation,
◊ la concision des modules programmés,
◊ l’unicité et la hiérarchisation des fonctions internes,
◊ la non-redondance des appels de fonctions,
◊ la réduction des parties d’interfaces similaires,
◊ la généralisation et la sécurité des procédures d’erreur

48
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
49
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
50
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
3.3. Définition de la qualité: le certificat ISO 9000
◊ Il s’agit de :
− Que l'entreprise a mis en place les règles, procédures, ... aptes à la maîtrise de la qualité
− Que ces règles, procédures, ... sont effectivement appliquées et que la preuve en est disponible
− Que l'entreprise peut en conséquence garantir avec une bonne probabilité que les produits,
services, ... qu'elle fournit sont conformes aux termes du contrat ...
◊ 4 textes de base :
− ISO 9000: principes essentiels et référence
− ISO 9001: exigences
− ISO 9004: lignes directrices
− ISO 9011: audit qualité et environnemental

◊ L’assurance produit a pour objectif: de garantir que les produits permettent d’atteindre les objectifs de
mission définis et, plus spécifiquement, que ces produits soient :
– Sûrs
– Disponibles
– Fiables
◊ L’assurance produit intervient lors de toute activité entraînant la réalisation d’un produit.
◊ Le management de l’assurance produit consiste à garantir et à réaliser une mise en oeuvre et une coordination
adaptées, effectives et efficaces des activités de l’assurance produit (AP) par :
– une intégration appropriée de la discipline de l’AP en fonction du projet
– intégration de l ’AP dans toute les activités du management et de l’ingénierie.

◊ Ainsi, l’assurance qualité a pour objectif: de donner au client l’assurance voulue que le produit ou le service
final répond aux exigences
◊ Par ailleurs, l’objectif de l’Assurance Produit des Logiciels est de garantir que les logiciels développés ou
réutilisés ainsi que les logiciels de service satisfont aux exigences.
◊ Plus particulièrement, les logiciels doivent fonctionner de manière sûre et fiable dans l’environnement
opérationnel.
◊ Ainsi, la gestion de la configuration désigne la méthodologie employée pour gérer le produit et ses évolutions:
− Partir du concept à la réalisation matérielle: les caractéristiques du produit évoluent tout au long de
son cycle de vie.
− Ainsi, la cohérence au sein d’un projet nécessite que ces évolutions soient contrôlées et
systématiquement restituées au travers d’une documentation validée.

• Politique qualité et système qualité:


◊ Politique Qualité d'une entreprise = toutes les dispositions et les actions conduites dans l'entreprise
relatives à l'obtention de la qualité de l'offre
◊ Système Qualité (ISO 9000) = ensemble de la structure organisationnelle, des responsabilités, des
procédures, des procédés, des ressources mises en oeuvre pour gérer la qualité

51
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
3.4. Normes et standards de la qualité

3.4.1. LA NORME ISO 9001 : DEFINITION


Système qualité - Modèle pour l'assurance de la qualité en conception, développement, production, installation et
prestations associées.

3.4.2. LA NORME ISO 9001 : EXIGENCES DES NORMES ISO 9000

3.4.3. LA NORME ISO 9001 : QUALITÉ ET ASSURANCE QUALITÉ


52
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
3.4.4. LA NORME ISO 9001 : PRINCIPE DE L'ASSURANCE QUALITE

53
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Définition: maîtrise de la Qualité = instanciation d'un processus standard de développement connu et mesurable
• Moyens: contrôle de la qualité pendant le processus de conception du produit i.e. maîtrise à priori des risques
induits
• Conséquence: estimation (assez) précise des coûts et délais ainsi que de la qualité des produits

◊ Mise en place de la démarche qualité:


– Utilisation de techniques: génie logiciel, contrôle
– Mise en place de méthodes: prototypage, …
– Utilisation d’outils: spécification, simulation, gestion de projets
– Établir, mettre à jour, diffuser des références
– Formaliser la chaîne de production
– Définir des métriques adaptées à chaque activité ou produit
– Essayer la démarche sur des projets
– Contrôler la qualité et comparer
– Évaluer la démarche.

◊ Définition:
– A pour objectif la mise en place d'une politique de gestion de la qualité appropriée aux besoins d'une
entreprise
◊ Principe:
– Décrire les moyens à mettre en oeuvre et les étapes pour la lise en place d'un système qualité ou pour
l'amélioration d'un système existant

54
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Méthodes qualité pour le développeur d'aujourd'hui et de demain:
◊ Formation à un processus de développement dédié à l'entreprise
◊ Mise en place de standards de documentation
◊ Mise en place de revues et d'inspection
◊ Participation active de chaque développeur soit en tant qu'inspecté, soit en tant qu'inspecteur
◊ Échange fréquent des rôles : développeur vs gestionnaire

◊ Facteur qualité: caractéristique du logiciel qui contribue à sa qualité et possède les propriétés suivantes:
– Orienté utilisateur
– Être relié à un coût par l’intermédiaire des activités qu’il engendre
– Maintenabilité: effort pour localiser et corriger une anomalie.
◊ Critère qualité: attribut du logiciel par l’intermédiaire duquel un facteur peut être évalué:
– Il est orienté réalisateur
– Et peut affecter plusieurs facteurs.

3.4.5. Facteurs McCall (1977)


Correctness Conformité
Reliability Robustesse
Efficiency Efficacité
Usability Maniabilité
Integrity Sécurité
Maintainability Maintenabilité
Flexibility Adaptabilité
Testability Testabilité

55
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Portability Portabilité
Reusability Réutilisabilité
Interoperability Inerorapérabilité

56
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
3.5. Facteurs versus Critères

57
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
◊ Conformité: traçabilité, consistance, complétude
◊ Robustesse: tolérance aux fautes, consistance, précision, simplicité
◊ Efficacité: efficacité d’exécution, de stockage
◊ Maniabilité: opérabilité, formation, communicativité, volume et taux d’entrées/sorties
◊ Sécurité: contrôle des accès, audit des accès
◊ Maintenabilité: consistance, simplicité, concision, modularité, auto-desciptivité

◊ Adaptabilité: modularité, généralité, «expandability», auto-desciptivité


◊ Testabilité: simplicité, modularité, instrumentation, auto-desciptivité
◊ Portabilité: modularité, auto-desciptivité, indépendance matérielle et logiciel
◊ Réutilisabilité: généralité, modularité, auto-desciptivité, indépendance matérielle et logiciel
◊ Interopérabilité: modularité, «commonalty» des communications et des données

3.6. Éléments de mesures


◊ Mesures directes et objectives:
◊ Comptage de nombre de ligne de code source
◊ Comptage de nombre d’homme-jours
◊ Comptage de nombre d’abort système
◊ Métriques obtenues par la réponse OUI/NON (liste de contrôle):
− Cohérence de la présentation des écrans
− Respect de la procédure de la signalisation des incidents
− Capacité de raccordement suffisante
◊ Métriques obtenues par enquête (note de 0 à 5):
− Clarté de la présentation des résultats
− Apport de l’assurance qualité
− Disponibilité du système aux heures de pointe

◊ Métriques du code:
− Lignes de codes, nombre d’opérandes, d’opérateurs
− Complexité cyclomatique
− Taux de commentaire
◊ Métriques de la spécification:
− Cohésion et couplage de modules
− Taille et fréquence de communication de données

◊ Métriques du processus de gestion:


− Mesures de la capacité à estimer
− Mesures liées à la documentation (taille, modularité, etc.)
◊ Métriques du processus qualité:

58
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
− Nombre de revues, d’inspection

3.7. Activité de contrôle

3.8. Contrôle technique


Portée:
Document de spécification
Code source
Modalité:
Lecture simple/croisée, inspection
Test
Contrôle de fond:
Contradiction, silence, omission, ambiguïté, ajout fonctionnel
Contrôle de forme:
Redondance, bruit, sur-détail, normes non respectées

3.9. Contrôle de processus


Portée:
Procédure de gestion
Démarche technique
Modalité:
Revue, audit
Contrôle de fond:
Existence des processus, respect de la procédure, pertinence des tests
59
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Contrôle de forme:
Conformité des contenus, conformité des circuits de validation

3.10. Code de déontologie, culture et comportement de l’ingénieur qualité

Code de déontologie de l’ingénieur qualité


Culture de l’ingénieur qualité

Comportement de l’ingénieur qualité

◊ Huit principes du code de déontologie de l’ingénieur qualité :


– Le public: : les ingénieurs logiciels doivent agir dans l’intérêt public en tout temps
– Le client et l’employeur : les ingénieurs logiciels doivent agir d’une manière qui sert le mieux possible
les intérêts de leurs clients et de leur employeur, toujours en fonction de l’intérêt public.
– Le produit : les ingénieurs logiciels doivent s’assurer que leurs produits et les modifications connexes
sont conformes aux normes professionnelles les plus élevées possible.
– Le jugement : les ingénieurs logiciels doivent maintenir leur intégrité et leur indépendance dans leur
jugement professionnel.
– La gestion : les gestionnaires et les responsables de génie logiciel doivent souscrire à une approche
éthique de la gestion du développement et de la maintenance des logiciels et s’employer à en faire la
promotion.

◊ Huit principes du code de déontologie de l’ingénieur qualité (suite):


– La profession : les ingénieurs logiciels doivent s’assurer de l’intégrité et de la réputation de la
profession en tenant compte de l’intérêt public.
– Les collègues : les ingénieurs logiciels doivent être justes et appuyer leurs collègues.
– Soi-même : les ingénieurs logiciels doivent être en situation d’apprentissage continu et promouvoir une
approche éthique à la pratique de leur profession.

◊ Culture du génie logiciel :


– Permet de s'assurer une communication efficace avec le client par l'intermédiaire d'un seul contact
qui s'implique à tous les niveaux du projet.
– Il faut faire preuve de transparence lors du cycle de vie du logiciel: il faut rendre disponibles les plans,
les procédures, les standards, les politiques de qualités, les standards aux personnes concernées
(développeurs, testeurs, analystes, concepteurs).
– De plus, il ne faut pas cacher l'état du projet à nos patrons ou au client.
– Les échéanciers doivent être respectés et s'il ne le sont pas, le client doit connaître l'état du projet et
les raisons d'un non-respect des plans. Cela ajoute de la crédibilité et du professionnalisme au génie
logiciel.

◊ Culture du génie logiciel (suite):


– Il faut établir un climat de confiance entre les développeurs et les clients ainsi qu'entre les
gestionnaires et les développeurs [analyse, testeur, concepteur, programmeur].
– Il ne faut pas "couper les coins ronds" pour respecter les coûts, les échéanciers ou toutes autres
contraintes en n'indiquant pas pourquoi la mesure a été décidée.
– L'intégrité et l'intelligence doivent être présentes dans les relations avec les clients et le gestionnaire.
– Les employés doivent toujours essayer d'améliorer la culture, le savoir, le savoir-faire de l'entreprise
en suivant des formations, testant des nouvelles techniques, ...

◊ Comportements avec impact positif sur la qualité des produits et services :

60
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
– Penser de façon unique et indépendante.
– Aider les autres à évoluer et à se développer.
– Prévoir et planifier.
– Coopérer avec les autres.
– Faire les choses parfaitement.
– Utiliser l'autorité reliée à sa position.

◊ Comportements avec impact positif sur la qualité des produits et services (suite):
– Surpasser ses pairs.
– S'opposer aux idées nouvelles.
– Suivre les autres (suivre le courant).
– Obéir aux ordres, même lorsqu'ils sont erronés.
– Accepter le statu quo.
– Attendre que les autres agissent avant d'agir.

Fondements de la qualité

◊ La méthodologie « modal » définit :


− Les objectifs principaux de la méthodologie
− Le domaine d’application
− Les principes de base
− Et détaille le déroulement de chacune des grandes activités :
− De la production
◊ Et de la maintenance du logiciel

◊ La méthodologie « modal » vise à:
− Garantir l’obtention de la qualité requise,
− Maîtriser la complexité, les coûts et les délais de développement et de maintenance des logiciels
produits,
− Capitaliser et réutiliser le savoir-faire de l’Organisation,
− Favoriser la synergie en utilisant des moyens de production communs (améliorer la productivité).

◊ Objectifs de la méthodologie « modal » :


− Augmenter la capacité des équipes à s’organiser pour maîtriser les projets, au travers d’une présentation
homogène des développements et d’un langage commun,
− Obtenir une bonne visibilité de l’avancement des projets,
− Procéder à des évaluations économiques précises des projets (charges, délais, risques),
− Acquérir une vision industrielle (concept de produit logiciel), favorisant la réutilisation systématique
des composants logiciels,
− Maîtriser la qualité du logiciel par la définition de ses différentes caractéristiques,
− Aider à la réalisation du logiciel et des documents associés,
Former les différentes personnes intervenant sur et autour des développements.

◊ La méthodologie « modal » se concrétise par un ensemble de documents qui :


− Définit la trame de tout développement de logiciel,
− Identifie les activités à réaliser,
− Identifie les éléments à produire,
61
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
− Identifie les responsabilités et les vérifications associées aux activités et produits,
− Indique les moyens disponible (méthodes, techniques) pour mener à bien le développement, ainsi que
les règles de bonne utilisation de ces outils.

◊ La méthodologie « modal » s’applique à tous les logiciels :


− Pour tenir compte des particularités de chaque développement (Modal définit de manière précise les
critères d’application des moyens et règles de production à chaque cas particulier),
− Modal définit les rôles et les responsabilités associées aux activités et produits à réaliser lors du
développement (sans exiger de répartition précise de ces rôles et sans préjuger de l’organisation de la
production du logiciel propre à chaque Organisation, ni des relations liées à cette production).

Méthodologie modal : les principes de base


◊ Pour mener à bien un projet logiciel, les principes retenus par Modal consistent à :
− Identifier et définir les grandes activités essentielles et complémentaires de la production du logiciel:
> Développement (réalisation et vérification - validation),
> Assurance (et suivi) qualité
> Gestion de projet, gestion des configuration, et gestion des sous-traitants
− Découper le processus de production du logiciel en phases successives (cycle de vie):
> Les activités à réaliser,
> Les produits d’entrée et les produits de sortie,
> Les responsabilités et les vérifications associées aux activités et produits.

◊ Pour mener à bien un projet logiciel, les principes retenus par Modal consistent à :
− Formaliser chaque activité par un produit qui constitue un élément très important pour la vérification et
l’obtention de la qualité,
− Contrôle rigoureusement chacun des produits d’une phase, ainsi que le déroulement des activités de la
phase « vérification »,
− Se doter de moyens (méthodes, techniques, règles) permettant de réaliser les différentes activités du
processus de production,
− Se doter d’une Documentation méthodologique qui représente le savoir – faire de l’Organisation
(ALSTOM) en matière de production du logiciel,
− Former et assister les équipes de développement aux activités, produits et moyens définis dans la
Documentation Méthodologique.

Méthodologie modal : contexte de la production du logiciel par Modal

62
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
4. Méthodologie modal : Phases du cycle de vie définies par MODAL

63
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
64
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
65
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
CHAPITRE IV : GESTION DES TESTS LOGICIELS

5.1. Introduction et contexte


 Les logiciels doivent être testés pour vérifier qu’ils fonctionnent comme on le souhaite dans l’environnement
cible
 L’objectif principal de l’automatisation des tests est de réduire leur coût
 Les tests automatiques sont répétables à volonté
– Certitude d’utiliser les mêmes données d’entrée chaque fois

Différents niveaux de tests


 Contrôle du source
 Détection des bugs, défectuosités
 Tests fonctionnels
 Tests d’UIs
 Tests d’installations
 Tests des béta-versions par les clients
 Tests de conformité par rapport à des standards
 etc.

Tester
 Pour tout logiciel : presque impossible de tout tester
 Travail principal : déterminer les tests les plus importants
– Sélection aléatoire : mauvais choix !
– Un test à effectuer = un « test case »
– Sélection à partir des spécifications
Ingrédients du test
 Programme exécutable
 Jeux de tests
– vecteurs d’entrées et de sorties
 Oracle
 Moyen pour observer les sorties
 Moyen pour comparer les résultats attendus des résultats observés

Test case
 Un bon test case ?
– Efficacité dans la détection des erreurs
– Capacité à tester plusieurs « choses »
• Réduction du nombre de tests
– Coûts nécessaires à sa création et son exécution
– Evolutivité
 Généralement, ces points s’opposent les uns aux autres…

Manuel ou automatique ?
 Dans les 2 cas : aussi efficaces et de couvertures identiques
 Automatique : une fois implémenté, plus économique mais… pb de création et de maintenance !
 Manuel : intelligence humaine et auto-adaptation mais… répétition plus difficile (fiabilité, temps…)

66
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Quand tester ?
 Activités de tests > tester
– On ne peut tester que si le logiciel existe
– Mais on pense aux tests dès le début de la conception
 Une phase de tests existe pour chaque étape du développement
– Modèle de développement en V

Modèle en V

67
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Activités de test

Qu’est-ce qui doit être testé et comment ?

68
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Différents tests fonctionnels
 Test unitaire : chaque module
 Test d’intégration : ensemble de modules
 Test de recette (fournisseur) : le logiciel
 Test de système (client) : le logiciel
 Test de validation (client) : environnement opérationnel

Types de tests / outils

 Test design tools


– Aide à déterminer les données et les entrées critiques
– Logical design tool : à partir des spécifications
– Physical design tool : analyse les données existantes, génére les données de tests…
• Exemple : a < x < b (nombres entiers)
– valeurs extrêmes : a+1, b-1
– valeurs non extrêmes : a+2, a+3, …, b-2
– valeurs spéciales : 
69
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
– valeurs non valides : a, b

Tests utilisateurs
Nos prestations de test sont souvent comparées aux « Focus group » et autres études
proposées par les principaux instituts ou cabinets de conseil qui font intervenir des utilisateurs
en groupe.
En qualité de spécialistes en ergonomie dans l’évaluation de la qualité de l’expérience
utilisateur, nous employons une méthodologie adaptée à l’analyse de l’utilisabilité d’un service
en ligne.
Nous vous proposons ci-dessous l’analyse d’une étude à laquelle nous avons assistée qui décrit
des problèmes méthodologiques et leurs conséquences sur la qualité de l’évaluation réalisée.

Tests en groupe : présentation d’un cas pratique


--------------------------
Nous avons récemment assisté à une matinée de test en groupe organisée par un acteur
généraliste du conseil : pendant 3 heures, 10 participants ont évalué la maquette html
fonctionnelle d’un service en ligne.

Deux groupes de cinq participants ont été conviés successivement aux deux phases
d’évaluation de ce test.
Ils avaient au préalable participé aux groupes de travail préliminaires du projet, dont l’objectif
était la définition et la validation des fonctionnalités et contenus mis à disposition dans le
service en ligne.

Phase 1 : les participants étaient placés autour d’une table et devaient effectuer en une heure,
cinq tâches précises en naviguant dans le site. Les tâches étaient définies selon les principales
fonctionnalités proposées dans le service en ligne. Chaque participant était assisté par une
personne, appelée l’observateur, qui l’aidait à comprendre la tache et évaluait le succès ou
l’échec à chacune d’elles.
Dans cette étude, les observateurs étaient les responsables du projet de service en ligne.
Phase 2 : il s’agissait d’une séance de travail animée par un consultant. Au cours de cette
séance, les participants étaient invités à choisir différents types de graphiques ou de couleurs
pour le service en ligne et devaient proposer des solutions permettant de résoudre les
difficultés qu’ils avaient rencontrées lors de l’accomplissement des tâches qui leur avaient été
assignées.

Analyse
--------------------------
Si le nombre d’utilisateurs consultés en si peu de temps (et donc à un moindre coût) peut
paraître séduisant, la qualité et la pertinence des données recueillies ne nous semble pas
permettre d’évaluer réellement la qualité de l’expérience des utilisateurs de ce service en ligne.
Les évaluateurs et la méthodologie employée au cours des différentes étapes d’une évaluation
sont déterminants de la qualité de l’analyse de l’utilisabilité du service en ligne.

Or, nous avons identifié, dans cette étude, différents problèmes méthodologiques :

1 - Non objectivité des participants et du mode de passation


-> Recrutement des participants
-> Mode de passation des tests

70
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
2 - Non pertinence des données recueillies
-> Qualification des évaluateurs
-> Recueil et analyse des données

3 - Manque de réalisme des sessions de test


-> Construction des scénarios
-> Matériel utilisé

Ces différents points sont présentés dans les paragraphes suivants.

1 - Non objectivité des participants et du mode de passation


--------------------------

a- Recrutement des participants :


Les utilisateurs recrutés avaient déjà participé antérieurement aux focus group au cours
desquels les principales fonctionnalités et contenus ont été définis.
Ils connaissaient donc le projet et ses principales caractéristiques, et ne pouvaient donc avoir
une vision neutre des informations et services proposés et de l’architecture du site.

-> La connaissance préalable de l’objectif du service en ligne n’a pas permis l’évaluation de sa
capacité à répondre aux besoins de ses utilisateurs, plus particulièrement au niveau de la
cohérence et de la facilité d’accès aux informations présentées.

b- Passation individuelle vs. collective


La situation de test est une situation stressante lorsque l’utilisateur ne parvient pas à effectuer
la tâche qui lui est demandée. Les participants ont souvent l’impression d’effectuer un test
d’aptitude, ou se sentent pressés par l’observateur.
Pour le vivre et l’avoir observé au quotidien, nous savons que les utilisateurs ont tendance à
culpabiliser et à se dévaloriser. Notre présence à leur coté et notre soutien permettent aux
utilisateurs de ne pas se culpabiliser en cas d’échec dans l’accomplissement d’une tâche, en
leur expliquant qu’ils ne sont pas responsables de cet échec, mais que c’est le service en ligne
qui ne leur permet pas d’accomplir la tâche qu’ils souhaitaient effectuer.
Ainsi, d’une part, les utilisateurs ne sont pas stressés et démoralisés de l’expérience qu’ils
viennent de vivre, et d’autre part, nous recueillons des données franches et sincères.

La passation collective génère un stress supplémentaire : la comparaison inter-individuelle : «


pourquoi lui y arrive et pas moi ».

-> Ce type de passation n’est bonne ni en terme de données recueillies ni en terme de confort
des utilisateurs.

2 - Non compétence des évaluateurs


---------------------------------
La qualité de l’analyse de l’utilisabilité d’un service en ligne est très largement liée à la
méthodologie de recueil et de traitement des données mises en œuvre.
Celle-ci est dépendante :
- de la qualification des évaluateurs qui élaborent et emploient cette méthodologie au long des
différentes phase de l’évaluation du service en ligne
- de la pertinence du recueil et de l’analyse des données.

71
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
a - Qualification des évaluateurs
Seuls des experts de l’Interaction Homme/ Machine peuvent évaluer l’utilisabilité d’un site,
c’est à dire la capacité de ce service en ligne à être facilement compris et utilisable par ses
clients et prospects.
Il appartient bien à des psychologues cogniticiens formés à l’analyse fonctionnelle des
systèmes informatiques plutôt qu’à des spécialistes du marketing et de la sémiologie, de
répondre et d’évaluer la qualité de l’expérience utilisateur d’un service en ligne.

Enfin, l’expertise dans la conduite de l’évaluation (facilitation du test et entretien) permet ne


pas influencer ou induire des réponses spécifiques des utilisateurs.

Analyse :
Les observateurs étaient les responsables du projet, et ils ne voyait chacun qu’un seul
utilisateur. Les données recueillies étaient ainsi liées aux différents observateurs, ceux-ci ne
s’étant pas coordonnés auparavant.
Or, pour avoir un recueil de données homogène et une vision transversale des difficultés
rencontrées par les utilisateurs, il est important que tous les participants soient évaluées par
la(es) même(s) personne(s).

-> Il en résulte :
- un manque d’homogénéité des données qui pénalisera la qualité de l’analyse, et
- une absence de vision d’ensemble du comportement des utilisateurs de ce service en ligne.

b - Recueil et analyse des données


La connaissance de l’interface web et du fonctionnement humain permettent de focaliser le
recueil sur des données issues de l’observation du comportement et des verbalisations des
participants.

La connaissance du fonctionnement cognitif de l’Homme, de ses caractéristiques et limites,


permet d’optimiser le recueil des données issues de l’observation de l’interaction entre un
utilisateur et un service en ligne, tant au niveau de la pertinence des données recueillies qu’au
niveau de la qualité de ce recueil.

Les verbalisations ne permettent pas seules de rendre compte de l’ensemble de l’expérience


utilisateur.
Par exemple, les informations traitées de manière « automatique », sans s’en rendre compte,
sont difficilement verbalisables (e.g. qui est capable de décrire sans oubli et sans erreur les
différentes opérations à effectuer pour démarrer une voiture, alors que la plupart d’entre nous
le faisons automatiquement ?).
De plus, la capacité et les stratégies de mémorisation ne permettent pas de retracer de
manière fiable et complète l’ensemble des actions effectuées pour compléter une tache.

Quant aux données comportementales recueillies, elles doivent concerner essentiellement les
interactions des utilisateurs avec les éléments de l’interface supportant les principales fonctions
cognitives.

L’analyse de ces données est ensuite orientée vers l’identification et la compréhension des
éléments et évènements perturbateurs qui pénalisent l’expérience de l’utilisateur du service en
ligne.

72
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Analyse :
Les observateurs posaient des questions assez vagues sur des aspects superficiels de
l’interface (couleur, style, graphisme) ce qui ne permet pas de recueillir des informations sur
les problèmes d’utilisation de l’interface rencontrés par les utilisateurs.
De même, l’attention des observateurs était portée essentiellement sur les verbalisations de
l’utilisateur et non sur ses actes.
Les données recueillies risquent alors de refléter :
- ce que l’utilisateur aimerait entendre
ou ce qu’il pense que l’on voudrait entendre de lui
- ce dont il se souvient avoir fait
(mais il ne souvient pas toujours ce qu’il a fait)
- ce qu’il pense avoir fait
et non sur ce qu’il a réellement fait.

-> Ainsi, l’identification des difficultés et des stratégies réelles d’utilisation du service en ligne
nécessitent la mise en œuvre d’une méthodologie de recueil et d’analyse de données prenant
en compte le comportement et les verbalisations des utilisateurs.
La mise en œuvre d’une méthodologie adaptée à l’évaluation de l’expérience utilisateur
nécessite la connaissance :
- du fonctionnement habituel d’un utilisateur lors d’une tâche de résolution de problème (par
exemple recherche d’information),
- de l’interface web et de ses éléments déterminants tant au niveau de leur signification que de
leur utilisation, et,
- du fonctionnement cognitif humain.

3 - Manque de réalisme des sessions de test


--------------------------
La méthodologie d’évaluation doit permettre de reproduire le comportement le plus naturel
possible, tant au niveau du réalisme des scénarios qu’au niveau du matériel utilisé afin de
recueillir des données les plus réalistes possibles.

a- Construction des scénarios


Le comportement des utilisateurs est différent lorsque la mission qu’ils doivent accomplir n’est
pas celle qu’ils se sont fixés eux-mêmes : les données recueillies peuvent alors refléter un
comportement artificiel parfois très différent du comportement réel.
De même, l’ordre de présentation des différents éléments et le temps passé sur les différentes
pages du site doivent refléter le plus possible une navigation « naturelle ».

Analyse :
les scénarios et tâches données aux participants étaient préalablement définies et ne prenaient
pas en compte leurs attentes. Ils sont restés très longtemps sur la page d’accueil, car de
nombreuses questions y faisaient référence, alors qu’en réalité, les utilisateurs n’y passent pas
plus de 15-20 secondes avant de cliquer sur un lien.

-> La navigation naturelle doit être privilégiée : le fait qu’un utilisateur n’effectue pas de
commentaires ou n’utilise pas certains éléments du site, est un résultat en soi : l’utilisateur ne
l’a pas vu ou n’en a pas eu besoin pour l’accomplissement de sa mission.

b -Matériel utilisé
Le matériel utilisé doit refléter le matériel réel des utilisateurs finaux du service en ligne.

73
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Analyse :
Les divers ordinateurs mis à la disposition des utilisateurs ne correspondaient pas à
l’équipement moyen de la cible visée (ordinateur portable, sans souris, petit clavier, écran
réglé en 1024 pixels, connectés au réseau interne de l’entreprise).

Conclusion
------------------------------
Ainsi, l’évaluation d’un service en ligne doit être effectuée par des spécialistes du domaine, et
selon une méthodologie rodée et pertinente pour les données à recueillir.

Au final, tout le monde risque d’être pénalisé :


- l’utilisateur final ne sera pas satisfait par le produit réalisé,
- le propriétaire du service en ligne ne rentabilisera pas son investissement,
- le prestataire du test ne renouvellera pas sa prestation.

A quel moment clé faut-il réaliser un test utilisateur pour un site existant ?

Cette question nous est posée périodiquement, dans le cadre de nos contrats d'accompagnement et suivi de nos principaux clients : en
réponse, nous proposons de réaliser un test à partir du moment où les utilisateurs ont rencontré des difficultés majeurs pour accomplir le
but qu'ils s'étaient donné.

De courts tests permettent en effet d'identifier les freins majeurs à l'utilisation, et de choisir la meilleure méthode d'évaluation en réponse
à chaque problème :
- s'il s'agit de difficultés de navigation dans le site, un tri de carte sera proposé pour identifier l'organisation de l'information qui suit la
logique des utilisateurs,
- s'il s'agit de non attractivité de la page d'accueil, un test de perception (avec comparatif de pages concurrentes) sera conseillé pour
mettre en évidence les points forts et points faibles des différentes mise en page, et contenu.
- s'il y a de nombreuses difficultés d'utilisation, seul le test utilisateur permettra de connaître les véritables freins.

Chacun de ces diagnostics est réalisé par nos soins périodiquement dans le cadre du contrat de suivi (contrat optiweb) dont le but est de
garantir à tout moment le meilleur niveau d'acceptabilité du service en ligne considéré.

Complémentarité "focus group" et test utilisateur

Nos récents articles sur les études qualitatives ont suscité de nombreuses réactions de la part des directions marketing qui ont l'habitude
de réaliser des réunions de consommateurs pour évaluer la pertinence d'un produit.

Devant la confusion qui règne bien souvent dans certains esprits, nous rappelons ci-après les vraies différences entre le test utilisateur et
le "focus group" :
axance.com étant spécialiste du test utilisateur, certains d'entre vous ont pensé que nous opposions complètement les deux techniques,
en réalité nous les utilisons conjointement à différents stades du développement d'un projet web: la consultation des consommateurs
dans le cadre d'interviews (collectifs ou individuels) étant une aide efficace pour la définition des objectifs, et la segmentation du marché,
alors que le test utilisateur permet d'évaluer un site existant, ou des maquettes non fonctionnelles voire semi-fonctionnelles (Powerpoint,
html).

Le "focus group" est également un moyen efficace pour connaître le vocabulaire utilisé, et les concepts recherchés par les futurs
utilisateurs, alors que le test utilisateur n'a pas son pareil pour évaluer la manière dont les utilisateurs découvrent effectivement
l'interface et interagissent avec (ce qui est impossible à apprendre par l'exploration ou l'interview)

74
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Il est toutefois nécessaire de réaliser des focus avec plusieurs groupes pour éliminer les risques de biais engendrés par certains
intervenants qui peuvent influencer le groupe entier, et lorsque le matériel est déjà disponible, le test est un complément précieux pour
mieux comprendre le sens réel des intentions relevées dans les interviews.

Efficacité des tests avec 5 participants (J.Nielsen)

Nous avons souvent des difficultés à convaincre nos clients de réaliser des tests avec seulement 5 participants, car leur premier réflexe
est de prendre un échantillon plus important (10 ou 15 personnes, en suivant les pratiques des études qualitatives traditionnelles)

Pourtant au-delà de 5 participants, nous observons souvent les mêmes difficultés, et il est souvent préférable d'explorer une nouvelle
piste avec un nouveau test de 5 participants plutôt que de réaliser dès le départ un test avec une dizaine de personnes.

Pour en savoir plus, n'hésitez pas à lire l'article de Jakob Nielsen : il y démontre comment un test avec 5 participants permet d'identifier
près de 85% des difficultés d'utilisation.
http://www.useit.com/alertbox/20000319.html

Centres d'intérêts des participants et scénario du test

Le choix du profil des participants est un sujet que nous avons déjà traité dans notre lettre, car il s'agit d'une préoccupation importante
de nos clients lorsque nous préparons ensemble le test.
Toutefois, le contexte actuel d'ultra spécialisation des sites nous conduit à revoir la conduite du scénario de test (notamment pour
l'évaluation de sites existants)

Le centre d'intérêt des participants :


Au-delà du profil - type de chaque utilisateur (âge, profession, sexe, pratique de l'Internet…) nous attachons une grande importance aux
centres d'intérêts de chaque participant : nous recherchons des internautes (novices ou avertis) qui ont un but précis en rapport direct
avec le site testé, et qui vont chercher une réponse adéquate à l'intérieur du site.

Le scénario du test :
Nous préparons un ou plusieurs scénarios d'utilisation avec notre client, de manière à explorer toutes les parties critiques du site : chaque
scénario traduit un parcours différent de la visite et ne dépasse pas une durée de 45 minutes (au-delà, les participants n'ont plus la
même concentration pour arriver au résultat)

La visite libre :
Pendant le test, nous laissons toute liberté du participant d'aller là où il le souhaite en suivant sa propre logique, car à chaque fois que
nous intervenons pour attirer son attention sur un point spécifique, son parcours s'en trouve perturbé, et le test biaisé !
Nous compensons ce manque de direction dans la visite par l'interrogation de l'utilisateur quant à sa perception du site, afin de restituer
au mieux ce qui se passe dans sa tête !
De plus, nous consacrons le dernier tiers de la visite pour reprendre en détail les parties du site non visitées afin de répondre à toutes les
questions du scénario qui n'ont pas été abordée naturellement par le participant.

Ainsi, contrairement aux tests de maquettes de sites en développement (où nous dirigeons totalement la visite) dans le cas d'un site
existant, nous utilisons les scénarios comme fil rouge de la visite !

Quelles sont les 4 catégories de freins recensés pendant nos tests ?

Lorsque nous restituons nos observations, nous avons pour habitude de présenter les résultats suivant la logique de perception des
utilisateurs.
Pour ce faire, nous avons identifié 4 types de freins qui sont présentés ci-dessus suivant leur ordre d'importance.

a - Compréhension

Le premier frein porte sur l'intelligibilité du contenu présenté !


Il s'agit du premier obstacle, qui a pour conséquence la non compréhension de l'offre proposée : le visiteur ne comprend pas à quoi sert
le site ! ou alors il ne sait pas comment y aller !
L'incompréhension peut être partielle, et concerner seulement certaines parties ou pages d'un site (contenu principal ou navigation)

75
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Mais il s'agit souvent d'une situation frustrante pour l'utilisateur qui a envie d'accéder au contenu : il ne comprend pas comment faire !
Souvent, il perd patience et quitte le site…

b - Utilité

Le deuxième frein porte sur l'adéquation de l'offre aux attentes des utilisateurs !
Il met en évidence la pertinence du contenu proposé (en rapport avec ce que l'utilisateur attendait ou recherchait !)
Si la réponse proposée au visiteur tombe à côté de ses véritables attentes, cela a pour effet de faire perdre la confiance de l'utilisateur
dans le site qu'il visite !
De plus, nous observons qu'une succession de tels freins provoque souvent le départ des visiteurs…

Cette inadéquation du contenu peut porter sur l'offre globale, ou tout simplement sur certains produits ou services.

La cause étant souvent due à une mauvaise stratégie marketing

c - Logique

Le troisième frein est basé sur le respect de la logique de l'utilisateur.


Car celle du concepteur en est souvent bien éloignée !
Ce frein apparaît lorsque l'utilisateur n'obtient pas immédiatement ce qu'il cherche.
Il est certes difficile de s'adapter à la logique de chacun, mais il est nécessaire de pouvoir répondre au plus grand nombre.
Cet obstacle de l'accessibilité à l'information est souvent dû à une mauvaise organisation du contenu (tant au niveau global, qu'au niveau
de la navigation)
Il peut également être dû à une mauvaise dénomination des titres ou rubriques

d - Pratique

Le dernier frein est basé sur l'absence d'aide et la difficulté d'accès au contenu.
C'est un problème similaire à celui des utilisateurs de logiciels : lorsque les utilisateurs visitent souvent le même site à la recherche
d'information, ils n'oublient pas les difficultés qu'ils ont pu rencontré jours après jours ! et ils finissent par se lasser et aller voir ailleurs !
Ainsi dans une perspective de fidélisation, il est important de penser à tous les aspects pratiques de l'interface (une aide efficace, les
moyens de savoir où l'on se trouve à chaque moment, une bonne visibilité des commandes, une mise en valeur efficace des pages…)

Un guidage soigné fera toujours la différence !

Ces 4 freins n'ont donc pas la même importance,


et même à l'intérieur de leur catégorie,
nous avons identifié 3 niveaux d'alerte pour chacun d'eux !

a - niveau 1
---------------
Problème mineur qui a été rencontré par quelques utilisateurs,
et ne remet pas en cause la visite
-> pas indispensable de le corriger

b - niveau 2
---------------
Problème majeur qui a été rencontré par la majorité des utilisateurs,
et a conduit certains d'entre eux à interrompre leur expérience
-> important de le corriger

c - niveau 3
---------------
Catastrophe qui rompt immédiatement l'expérience de l'utilisateur
-> impératif de corriger

5 étapes à passer avant de faire tester régulièrement son site


76
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Nous constatons depuis de nombreux mois que les propriétaires de sites web (mais également les concepteurs) suivent les mêmes étapes
avant de se décider à recourir systématiquement à nos tests utilisateur.

Nous avons recensé 5 étape-clés qui correspondent à des comportements et niveaux de maturités différents de la part des acteurs du
web français :

1 - "L'utilisabilité n'a pas d'importance !"


(…) mon site génère déjà un traffic régulier (…) l'ergonomie a déjà été étudié par nos développeurs !"
-> traduction : il s'agit d'un faux problème, nous maîtrisons tout !

2 - " L'utilisabilité est un facteur important de la réussite d'un site !


(…) "mais de bonnes interfaces peuvent être réalisées par les professionnels de l'Internet qui ont l'habitude de travailler toute la journée
dessus ! "
-> traduction : nous connaissons le problème, et nous savons y remédier !

3 - "Nous souhaiterions vous faire intervenir sur notre site !


(…) il sera mis en ligne dans quelques jours (…) il s'agit de vérifier qu'il fonctionne bien (…) tant au niveau du concept et qu'au niveau de
l'ergonomie !"
-> traduction : on va le mettre en ligne, mais nous ne sommes pas certains qu'il marche !

4 - "Nous souhaiterions vous faire intervenir dès la phase de définition des tâches
(…) avant l'habillage des pages (…) afin de comprendre le fonctionnement de l'interface html"
-> traduction : nous savons qu'il faut intervenir dès en amont de la conception pour réaliser un site vraiment utilisable !

5 - "Nous souhaiterions vous faire intervenir sur l'ensemble de nos projet dès leur phase de conception !"
-> traduction : nous avons compris que plus les groupes de projet sont importants, plus il faut faire valider leur utilisabilité par un
intervenant extérieur !

Il s'agit bien sur de stéréotypes,


mais tout acteur du web français doit pouvoir se reconnaître dans l'un d'eux, surtout depuis quelques mois, avec l'enjeu du commerce en
ligne qui implique enfin pour les concepteurs de prendre en compte les intérêts et attentes des utilisateurs !

Quel est le scénario idéal pour observer les internautes ?

Nous réalisons de nombreux tests-observation d'utilisateurs, et nous avons opté depuis quelque temps pour la mise en place d'un
scénario le plus proche possible des centres d'intérêts du principal intéressé !

Au risque de surprendre nos clients (lorsque ceux-ci nous demandent de construire un scénario type, avec des questions précises) nous
leur proposons le plus souvent un modèle de scénario minimum en soulignant que celui-ci sera complété en fonction de missions propre à
l'utilisateur.

En effet, pendant le recrutement de chaque utilisateur, nous essayons de sélectionner ceux qui ont un réel besoin à venir visiter le site
testé, et pour le mettre en situation idéale de recherche, nous l'interviewons afin d'identifier au mieux ses besoins, et nous lui demandons
d'utiliser le site pour y répondre…

2 raisons d'utiliser les tâches propre à chaque utilisateur :

Complexité de la recherche :
- les véritables tâches de l'utilisateur sont plus complexes, et plus proches de la réalité que les questions standard (elles nécessitent
souvent une réponse plus précise, voire personnalisée)
- il est difficile pour un utilisateur de faire une telle recherche, si elle ne le concerne pas totalement (il risque d'être dérouté par la
complexité du test)
- seul l'utilisateur est capable de dire à partir de quel moment il a obtenu une réponse efficace

Implication et motivation de l'utilisateur :


- lorsque l'utilisateur effectue une recherche personnelle, il n'hésite pas à franchir nombre d'obstacles sans se décourager

Nous sommes convaincus qu'il s'agit aujourd'hui du meilleur moyen pour recueillir des informations qualitatives sur la véritable
utilisabilité d'un site !

77
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Comment adapter les résultats des tests à la demande des clients ?

Notre expérience dans la conduite de tests d'utilisabilité nous permet de dire que l'une des difficultés majeures de cette activité est de
convaincre les clients de la validité des résultats obtenus, et de la nécessité de corriger au plus vite les problèmes constatés (ou en
intégrant les corrections dans le site en développement)

Ainsi pour parer à ces freins, il est conseillé à tout membre d'un groupe de projet web de participer à l'ensemble des sessions de tests.
Mais cela n'est pas suffisant, il faut aussi que le test réponde aux préoccupations de chacun, et pour ce faire, nous avons isolé 3 types
d'attentes correspondant à 3 profils - type d'interlocuteur :

a - Le responsable marketing :
il a besoin d'être certain de la validité du "concept", et de l'adéquation de l'offre avec les attentes du "cœur de cible"
b - Le chef de projet web :
il veut s'assurer de la facilité de navigation à l'intérieur du site, et de la bonne compréhension du contenu
c - Le responsable du développement informatique :
il veut connaître les dysfonctionnements techniques et toute difficulté rencontrée par les utilisateurs (notamment les contraintes
techniques d'utilisation)

Ainsi, c'est un peu comme s'il était nécessaire de réaliser 3 tests en 1 seul !
et pour mieux répondre aux attentes de chacun le rapport de test doit intégrer :

a - une synthèse générale :


dont une partie sera destinée à rendre compte de l'intérêt pour le concept proposé (adéquation offre-demande)
b - l'évaluation complète de l'utilisabilité :
présentée au niveau global avec pour chaque page-écran, un tableau synthétique qui suit l'ordre de la perception de l'utilisateur.
Le tout pouvant être complété par le résultat des grilles d'évaluation (remplies par chaque utilisateur à l'issu du test)
c – listing de tous les problèmes majeurs et importants :
de manière à faciliter les corrections (suggestions ou pistes de solution peuvant être proposées dans certains cas)

D'une manière générale, le test doit être orienté vers les parties sensibles identifiées par chaque membre du groupe de projet

De plus, pour s'assurer de la qualité du matériel testé, il est important pour tout membre de ce groupe de participer dès le départ :
la validation du scénario, le choix des questions, la sélection du profil des participants…
mais également en participant aux tests en qualité d'observateur passif, car il n'existe rien de plus efficace que de voir les utilisateurs en
situation réelle !
(il devient alors difficile pour quiconque a assisté aux sessions de tests de nier l'évidence, ou de mettre en cause l'interprétation des
observations !)

Chacun aura vu les mêmes choses, c'est pourquoi le rapport de test n'aura pour fonction que de transmettre à chacun une synthèse
opérationnelle des principaux dysfonctionnements qui auront été identifiés.

En fait le test a plus de chance de réussir lorsque les connaissances et le savoir de chacun sont mis en commun à chacune des étapes -
clé !

Préférence de l'observation directe par rapport à l'interview et Focus group

Nous avons déjà abordé ce sujet à plusieurs reprises, mais certaines réactions et attentes de la part de nombreux acteurs français du web
que nous rencontrons chaque semaine, nous incitent à revenir sur le sujet.

Quel est l'intérêt de réaliser des interviews et focus group avec des utilisateurs du web ?

Nous pensons que le plus important est de savoir ce que les utilisateurs font plutôt que ce qu'ils disent qu'ils ont fait, ou aimeraient faire…

Nous préférons en effet nous intéresser aux actes et non aux sentiments exprimés (qui n'ont parfois qu'une parenté lointaine avec la
réalité).
Ainsi, il nous apparaît plus utile d'évaluer la vitesse à laquelle les utilisateurs vont trouver ce qu'ils sont venu chercher, plutôt que leur
demander si ils préfèrent telle présentation des résultats ou telle autre… (et notamment dans le cadre de "focus group" où les résultats
sont parfois aléatoires)

A l'issue de chacun de nos tests (observations), nous posons aux participants des questions relatives à la perception qu'ils ont eu de
l'environnement et de l'expérience qu'ils viennent de vivre pendant ces quelques minutes.
Et nous sommes souvent très surpris : car dans près d'un quart des cas, les réponses des participants sont en contradiction avec ce que

78
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
nous venons d'observer à leur cote :
- certains individus ont souvent l'habitude de chercher une réponse rationnelle ou raisonnable et non pas spontanée !
Les participants à nos tests remplissent également une fiche d'évaluation à l'issue de leur visite, et il n'est pas rare que certains d'entre
eux évaluent positivement la navigation d'un site pour lequel ils ont eu de grandes difficultés à trouver ce qu'ils cherchaient.

Explication :
Les observations de sites web et de services en ligne en situation d'utilisation, nous ont amené à conclure que de nombreux internautes
ont pris l'habitude de rencontrer tellement de difficultés dans leur navigation, qu'ils n'y portent plus d'attention, ils restent focalisés sur le
contenu : à la recherche constante du lien qui va répondre à leur attente, et dès qu'ils ont la moindre intuition d'être sur la bonne piste,
ils poursuivent leur chemin, (même si ils ne savent pas réellement où ils se trouvent, ni comment revenir d'où ils viennent)

Et ce n'est donc qu'à partir du moment où l'utilisateur revient régulièrement sur un site web qu'il devient exigeant quant à la qualité de la
navigation (et là d'une certaine manière, ses attentes sont proches de celles d'un possesseur de logiciel) il devient plus critique, le
contenu n'étant plus le facteur déterminant de sa satisfaction, mais la facilité d'accès étant toute aussi importante.

Ce sont nos différentes méthodes d'évaluation utilisées chaque semaine qui nous ont permis d'arriver à ce constat : l'observation est la
source d'information la plus objective !

Mais cela ne nous empêchent pas de prendre en considération certains résultats d'études (comme celui présenté ci-après)

Principaux facteurs de fidélisation des internautes (Forrester Research)

Certaines études quantitatives apportent parfois des informations intéressantes, ainsi une récente étude menée par la société "Forrester
Research" place la facilité d'utilisation au 2ème rang des facteurs de retour des visiteurs dans un site web (après la qualité du contenu).

Facteurs qui suscitent le retour des visiteurs :


(1) qualité du contenu : 75%
(2) facilité d'utilisation : 66 %
(3) rapidité de téléchargement : 58 %
(4) fréquence de mise a jour : 54 %

(5) promotions et remises : 14 %, (6) marque : 13 %, (7) technologie : 12 %, (8) jeux : 11 %, (9) options d'achat : 11 %, (10)
personnalisation du contenu : 10 %, (11) chat & BBS : 10 %, (12) autres : 6%

quelques compléments d'information sont accessibles à :


http://clipwebzine.com/article.cfm?storyid=163
http://www.forrester.com

Combien faut-il observer d'utilisateurs pour avoir des résultats efficaces ?

Les acteurs du web intéressés par le test nous demandent souvent combien nous observons de participants avant d'être sûr de ne pas
nous tromper, et bien nous pensons qu'il s'agit là d'une fausse question !
Car dans toute étude qualitative, la quantité n'a qu'un lien très lointain avec la pertinence des résultats !
Et si nous leur répondons que nous observons 6 a 10 personnes, ils nous répondent parfois que notre démarche n'est pas scientifique, ce
sur quoi nous sommes d'accord !

Mais là n'est pas le problème essentiel ! le plus important est de recruter des utilisateurs qui vont s'exprimer instantanément pendant la
réalisation des tâches pour lequel le site est prévu, et qui vont donner leur avis spontané sur leur expérience immédiate, à mesure qu'ils
progressent dans leur visite (ou dans le processus d'achat en ligne…)

Ainsi lorsqu'on observe de tels utilisateurs, les principaux freins sont identifiés en moyenne à partir du 5ème participant, ensuite il s'agit
essentiellement de vérifier des fonctions spécifiques du service…

En l'absence de mesures statistiques, notre méthodologie n'a aucune prétention scientifique, et pourtant cela ne nous empêche nullement
d'évaluer les chances qu'un événement à de se reproduire dans le temps…

Quelques pas de faits en direction des utilisateurs !

79
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Depuis le début de cette année, nous testons chaque semaine des sites de commerce électronique et cela fait 6-8 mois que les
propriétaires et concepteurs français de sites commerciaux se soucient enfin véritablement de ce qu'arrivent à comprendre et à faire les
internautes sur leur site.

• Pendant longtemps, tout le monde s'est contenté de l'analyse des fichiers logs :
on pouvait identifier les pages que les internautes avaient vues, ainsi que les liens qu'ils avaient utilisés.
Mais il restait une énigme de taille : les données qualitatives !
Nos futurs clients se demandaient alors :
- "pourquoi les utilisateurs n'ont-ils pas vu le lien ?"
- "pourquoi sont-ils repartis avant de cliquer ?"…

• Le principal intérêt des utilisateurs avait été laissé de côté par tous les spécialistes du marketing et de la communication :
- qu'est-ce que les utilisateurs sont venus chercher ?
- ont-ils trouvé ce qu'ils cherchaient ?
- est-ce qu'ils se sont rendus compte qu'ils avaient trouvé ce qu'ils cherchaient au moment d'abandonner leur recherche ?
- …Autant de questions auxquelles nous avons essayé d'apporter des réponses à l'aide d'observations des internautes pendant les tests
que nous avons réalisés sur notre plate forme.

• Aujourd'hui, on peut dire qu'il y a un mieux dans l'accès à l'information de certains sites, et notamment au niveau de la page d'accueil :
en effet nous constatons que les internautes sont de moins en moins freinés par la page d'entrée, ils comprennent souvent de quoi il
s'agit et ou ça se trouve :
- avec les rubriques simplifiées, les extraits du catalogue mis en avant, et les liens-services qui permettent d'accéder directement au
niveau 2 de l'arborescence…

Il faut dire que d'un côte comme de l'autre, quelques habitudes se sont installées, et de véritables "standards" de l'interface web sont
apparus.
Les utilisateurs ayant eux-mêmes parfois pris l'habitude de se "mettre dans la peau" des concepteurs pour mieux comprendre la logique
de fonctionnement.
Nous tenons compte de cela dans nos tests, et c'est pourquoi nous recrutons de
de nombreux novices, dont certains n'ont jamais tenu une souris dans la main…

• Par contre il y a encore beaucoup à faire dès que l'utilisateur parcourt les pages du site à la recherche d'un produit et surtout lorsqu'il se
décide à l'acheter (en admettant qu'il ait trouvé exactement ce qu'il était venu chercher) il lui faut alors traverser un vrai parcours du
combattant :

- a/ présentation et mise en valeur du contenu :


l'information proposée (images et textes) ne permet pas toujours à l'utilisateur de prendre une décision qu'il juge rationnelle

- b/ sélection :
il est souvent difficile pour l'internaute de comparer efficacement les produits (d'une manière identique à ce qu'il pourrait faire dans un
magasin)

- c/ bon de commande :
la clarté du bon de commande ne permet pas toujours à l'utilisateur de vérifier son contenu, et de le modifier facilement, de plus
certaines informations annexes à la commande n'apparaissent qu'à ce moment là et cela peut conduire l'utilisateur à interrompre le
processus d'achat (port, délais, échange, disponibilité…)

- d/ formulaire d'identification et de paiement : c'est la dernière étape à accomplir, mais ce n'est pas la plus simple, notamment dans le
cas où l'utilisateur à besoin de le remplir à plusieurs reprises (le retour en arrière n'ayant pas conservé en mémoire le contenu déjà
rempli) il faut également éviter d'aborder tout ce qui touche à sa vie privée en lui laissant penser que si l'on obtient son e-mail, on pourra
à tout moment le reconnaître lorsqu'il y reviendra.
D'une manière générale, les utilisateurs préfèrent les formulaires simples et rapides (donc courts) et apprécient également de pouvoir
accéder aux conditions générales de vente pendant qu'ils remplissent le formulaire, ou appeler au téléphone un conseiller qui aura sa
commande sous les yeux et pourra le rassurer sur un point spécifique.
La notion de paiement sécurisé est également très importante, car si l'utilisateur choisit de régler par chèque, le risque qu'il change d'avis
une fois qu'il a quitté son ordinateur est élevé.

- e/ fin de la commande : les utilisateurs apprécient de recevoir instantanément par e-mail une confirmation du contenu de leur
commande, afin de pouvoir rectifier immédiatement en cas d'erreur

- f/ attente de réception : les internautes souhaitent également être informés du cheminement de leur commande (savoir quand elle est
partie, et quand elle doit arriver…)

Nous venons de survoler rapidement un ensemble de point-cles qui demandent encore de l'attention de la part des concepteurs de sites
Et c'est pour cela que nous collaborons de plus en plus fréquemment
dès les premiers stades de maquettes d'interface

Comment sélectionnons-nous les participants à nos tests ?

80
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Voici à nouveau une question qui nous est souvent posée, par les participants eux-mêmes, ou bien par nos clients qui se demandent (à
juste titre) comment nous pouvons être sûr de recruter les bons utilisateurs ?

Les spécialistes des études (et les responsables marketing) conseillent de selectionner les participants sur un profil basé sur :
- l’âge,
- le sexe,
- la profession,
- l'expérience,
- les diplomes,
- les habitudes de consommation,
-…

Pour notre part, nous suivons les enseignements du spécialiste Jared SPOOL (UIE)
Nous ne plaçons pas les données démographiques au premier plan pour choisir les participants, mais nous nous intéressons en priorité à
certaines qualifications requises :

a- l'expérience : pour le web, ou la réalisation de certaines tâches spécifiques

b- les centres d'intérêt : la connaissance du sujet traité, des produits vendus…

c- la capacité à communiquer : la facilité à exprimer et échanger ses impressions…

Car il ne s'agit pas de "coller" nécessairement au coeur de cible, mais plutot de recueillir le maximum d'informations sur la manière dont
les utilisateurs vivent cette experience.
Ainsi on préfèrera un candidat qui ne remplit pas la totalité des critères du coeur de cible, mais qui décrit avec précision ce qu'il ressent à
chaque instant (ce qu'il comprend ou croit comprendre, ce qu'il attendait, ce qu'il a l'habitude de faire…)

Nous nous dirigeons de plus en plus vers les utilisateurs novices, non expérimentés, car ce sont eux qui doivent arriver sur le marché de
l'internet et leur manque d'expérience avec le web n'est pas déterminant pour la réussite d'un test, car le "facilitateur" (test facilitator) a
la tâche d'aider le participant à utiliser l'interface.

Seule exception à la règle :


Pour vérifier que les utilisateurs d'un site n'ont pas d'appréhension à passer de l'ancienne à la nouvelle version (exemple :dans le cas de
services réservés aux abonnés)

Mais le plus important, c'est la volonté des candidats de se mettre dans la peau de véritables utilisateurs :
En mettant le maximum d'énergie à accomplir les tâches et en jugeant les résultats obtenus comme s'il s'agissait d'une situation réelle.

La suite sur notre méthode de recrutement (au prochain numero)

Le site User Interface Engineering


http://world.std.com/~uieweb

Choix des questions posées aux participants des tests

- comment sont choisies les questions que nous vous posons pendant les test ?
- à quoi servent les questions ?
- combien de participants sont-ils nécessaires pour obtenir des résultats concrets ?

• Pour mieux restituer le contexte, il faut savoir que nos tests se déroulent en 2 étapes :

a- le pré-test :
- détermine les principaux problèmes rencontres par les utilisateurs,
- permet de savoir ou les problèmes sont situés,

b- le test véritable :
- évalue les causes de ces problèmes,
- permet de valider des solutions

• Ainsi les questions posées permettent de diriger les participants


vers les points critiques de l'interface
Ces questions correspondent en général à ce que les visiteurs recherchent en majorité.
Elles permettent enfin de vérifier si oui ou non les utilisateurs surmontent leurs difficultés et lorsqu'ils ne sont pas sur le bon chemin,
notre tâche principale est alors d'évaluer le temps qu'il leur est nécessaire pour identifier le mauvais bouton…
Et dès que nous pensons avoir localisé la cause de ces erreurs, nous corrigeons rapidement l'interface, et vérifions avec les utilisateurs
suivants que la nouvelle solution est bien meilleure que l'ancienne.

81
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• On nous demande également souvent combien d'utilisateurs nous "testons"
afin d'être sur de ne pas nous tromper : en réalité, nous n'avons pas de nombre prédéfini, nous nous arrêtons lorsque les nouvelles
sessions ne nous apprennent rien de nouveau :
en général, 3-5 utilisateurs suffisent ! mais parfois le premier test est le plus riche et il permet déjà d'identifier les freins majeurs qui
seront corrigés par la suite.
Tout réside dans la qualité de l'observation, et la capacité de participer, à exprimer ce qu'il ressent (ce qu'il comprend, ou croit
comprendre, et ce qu'il ne comprend pas !)

• En réalité, la méthodologie du test est un processus sans fin d'évaluation :


a- poser une question
b- cerner les difficultés à répondre à cette question
c- corriger
…et recommencer

Nous n'atteignons jamais la perfection, mais nous avons toujours à l'esprit cet adage bien connu de Voltaire : "le mieux est l'ennemi du
bien" (sachant que le résultat des 5 premiers tests, permet d'identifier les principaux freins à l'utilisation)

bonne semaine à tous…


à bientôt sur notre plate-forme de test !

attention, exceptionnellement pas de lettre la semaine prochaine !


la prochaine lettre vous sera envoyée le 28 juin,
(mais les tests continuent la semaine prochaine)

Les tests les plus simples sont les meilleurs

Nombreux sont nos clients qui sont habitués à de longues études portant sur un grand nombre d'individus, aussi lorsque nous leur
proposons d'évaluer leur site
à partir de l'observation de seulement 5-8 individus, ils émettent souvent des réserves quant à l'efficacité d'une telle méthode.

Pourtant sur le terrain il apparaît que 8 utilisateurs (ce que nous proposons le plus souvent), c'est déjà souvent 2 à 3 individus de trop,
car au delà du 5ème, ce que nous observons de nouveau est souvent marginal.
De plus, lorsqu'il s'agit d'évaluer un site existant, il n'est pas possible de changer en profondeur l'interface ou la navigation (cela prendrait
trop de temps en développement)
Et ce sont donc seulement de simples corrections, mises en oeuvre immediatement qui vont permettre d'améliorer sensiblement
l'efficacité générale d'un site.

Nous avons recours à des panels plus larges d'individus dans le cas de sites de taille conséquente (avec plus de 80-100 écrans) et nous
réalisons alors plusieurs modules d'évaluation qui portent sur des parties différentes du site :
- franchissement de page d'accueil + consultation du catalogue,
- prise de commande en ligne,
- inscription à service spécifique,
- reconstitution du cycle des visites…

Ainsi, contrairement aux études traditionnelles qui font l'objet de longs rapports
(que personne ne lit jamais !), nous avons pour habitude de rédiger un document synthetique, accompagné de nombreux exemples
concrets, qui sont autant de pistes testées et évaluées permettant de rendre le site immédiatement plus compréhensible, plus pratique,
et plus utile pour les internautes
Et c'est pour cela qu'ils y reviendront !

Au final, le client est ravi, il a payé 2 fois moins cher pour une étude concrète,
(si l'on compare avec les études traditionnelles proposées sur le marché)
et il possède déjà des éléments concrets pour améliorer son site dans un delai très court.
C'est certainement ce qui fait une partie de notre réussite aujourd'hui, car nous sommes la seule sociéte en France spécialisée dans
l'évaluation de sites web.
C'est aussi un peu pour cela que nos conditions générales de vente stipulent la mention :
satisfait ou remboursé !

82
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
5.2. Organisation d’une cellule de test

5.2.1. Processus de mise en œuvre

 Décision d’initialiser un processus de test

• « Toutes les applications doivent faire l’objet d’un test de performances avant leur mise en production »

 Création d’une cellule de test

• Si possible, indépendante

 Définition de la méthode et des processus

• Qui / Quoi / Où / Comment

 Communication avec l’ensemble de l’entreprise

• En particulier avec la direction des Etudes et la direction de Production

Décision d’initialiser un processus de test

 Améliorer la qualité des applications livrées en production

• Faire en sorte que les architectures tiennent la charge

• Faire en sorte que les serveurs soient correctement dimensionnés

• Faire en sorte que les applicatifs soient robustes et fiables

• Si possible que les temps de réponse sont bons

 Diminuer la charge de travail pour l’équipe de production

• Ils sont plus confiant sur l’application réceptionnée

• Certainement moins d’interventions en production

 Diminuer les allers/retours entre les directions

Pourquoi créer une cellule de test

 Pilote/Responsable du processus

83
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Obligatoirement composée de 1 à x personnes INTERNE à l’entreprise

• Peut être constituée de membres permanents et de membres temporaires (organisation projet)

• A le pouvoir de renvoyer une application si celle-ci n’atteint pas le niveau de qualité souhaité .

5.2.2. Création d’une cellule de test – Qui

5.2.3. Composition de la cellule de test - Qui


 Management
• Diplomatie
• Bonnes notions dans l’organisation, méthodologie
• Connaissances très étendues de l’informatique
• Rigueur et flexibilité

 Collaborateurs
• Diplomatie
• Pratique du développement et/ou de l’exploitation de logiciel
• Rigueur dans l’exécution des tâches

Rôles de la cellule de test - Qui


 Chefs de projet de test
• Coordonner les campagnes de tests
• Promouvoir et faire évoluer la méthode de test
 Spécialistes des outils de tests
• Maintenir le(s) outil(s) de gestion des campagnes de test
• Maintenir les scripts d’automatisation
 Spécialistes techniques
• Maintenir l’infrastructure technique des tests
• Concevoir des cas de tests techniques (scripts composant par composant)

84
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Méthode et processus de test - les environnements – Où

Méthode et processus – Comment

 Aide à la spécification des tests

 Pour chaque phase de test, définir :

• Exigences et limitations du cycle test

• Éléments à tester et à ne pas tester

• Approche de test

• Critères de succès et d’échec

• Critères d’arrêt

• Environnement(s) de test

• Activités de test

• Rôle et responsabilités

• Planning

• Risques

 Mettre en place des indicateurs qualitatifs et quantitatifs


85
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Communication avec l’ensemble de l’entreprise

 Vendre le processus de test au sein de l’entreprise

 Soutien de la Direction Informatique

 Impliquer tous les interlocuteurs

• Sensibilisation sur les capacités de l’outil LoadRunner

 Adopter un discours différent en fonction des interlocuteurs

 MOA -> Niveau de qualité de l’application

 Techniciens -> qualité du choix de l’architecture technique

 Développeurs -> qualité du choix de développement

Plan d’actions

 Décision d’initialiser un processus de test

 Création d’une cellule de test

 Définition de la méthode et des processus

 Communication avec l’ensemble de l’entreprise

 Mise en œuvre de la méthode de test et d’outillage

Techniques de test

86
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
CHAPITRE V : AUTOMATISATION DES TESTS LOGICIELS

Génération automatique de procédures de test


 Analyse du code
– Code = liste de branchements (déterministe)
– Points de décision (if…, switch…, ) : détermination automatique des « valeurs » adéquates pour
explorer les « branches »
– Mais… ne peut analyser le code manquant !
 Analyse de l’interface utilisateur (UI)
– Dresse la liste des menus, boutons etc.
– Différentes combinaisons d’actions
– Ex :
 Est-ce que l’aide fonctionne pour tous les outils ?
 Vérificateur d’orthographe des labels
 Vérification des liens hypertext
 Fonctionnalités toutes implémentées ?
– … ne peut déterminer si le résultat est correct ou non !
 Analyse des spécifications
– Langage de spécification
 Exploitation d’UML ou de descriptions en pseudo langage naturel ou de graphes
« causes/effets »
 Utilisation de diagrammes d’états et de transitions
 Utilisation des cardinalités
 Détection d’ambiguïtés ou d’omissions (cf. CheckModel dans Rational Rose)

Avantages des tests automatiques


 Exécution sur différentes version d’un logiciel
 Tester plus et plus souvent
– Fiabilité et rigueur !
– Mêmes tests sur différentes plates-formes
 Faire des tests impossibles à réaliser manuellement
– ex. simuler 2000 utilisateurs, vérifier que tous les évènements et exceptions sont récupérés
 Exécution sur différentes version d’un logiciel
 Tester plus et plus souvent
– Fiabilité et rigueur !
– Mêmes tests sur différentes plates-formes
 Faire des tests impossibles à réaliser manuellement
– ex. simuler 2000 utilisateurs, vérifier que tous les évènements et exceptions sont récupérés
 Réutilisation des tests pour d’autres projets
 …livraison plus rapide du logiciel
 …plus grande confiance

Inconvénients des tests automatiques


 Excès d’optimisme dans la création des tests
 Difficulté pour trouver les bons tests
 Le plus souvent : erreur trouvée lors de la première exécution du test (manuelle…)
 Ce n’est pas parce qu’aucun problème n’a été trouvé qu’il n’y en a pas…
 Propagation de bugs au fil des versions si les données attendues (référentiel) sont fausses…

 Difficultés de maintenance
 Apprentissage des logiciels de tests

87
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
– Ils ont eux-mêmes parfois des bugs…
– Ils ont dû eux-mêmes être testés…
 Interopérabilité du logiciel de test avec le logiciel à tester
 Problèmes d’organisation
 Tests manuels = 85 % des erreurs
 Tests automatiques = 15 % des erreurs

Conclusion
 Automatisation des tests ≠ tester
 Les activités de tests ont lieu tout au long du processus de développement
 L’automatisation ne peut être complète
– Les tests automatiques ne remplacent pas les tests manuels
 Bénéfices de l’automatisation
– Rapidité, reproductibilité, fiabilité
 Les outils automatiques n’ont pas d’imagination

Choix d’un logiciel de test


Où démarrer ?
 Etablir la liste des problèmes actuels
 Etablir la liste des besoins
 Explorer les outils commerciaux
 Comparer les outils commerciaux aux coûts relatifs à la création d’outils spécifiques

Exemples de problèmes à résoudre


 Tests manuels trop longs à réaliser
 Impossibilité de refaire tous les tests à chaque nouvelle version du logiciel
 Tests mal documentés
 Couverture actuelle de test inconnue
 …les tests actuels sont inefficaces…

Quelques questions…
 Tests manuels trop longs ?
– Embaucher de nouveaux testeurs ?
– Donner plusieurs machines à un testeur… ?!
 Pb quand changement de version ?
– Peut-être trop de différences entre 2 versions !
– Pb d’intégration ?
 Travail de création des tests répétitif ?
– Pourquoi le faire alors à chaque fois ?!
– Nécessité d’organisation (tests génériques…)

Estimation du temps gagné


 Exemple :
– Manuel = 4 personnes-semaine
– Après 3 mois : 50-60% automatisés = 2-2,5 personnes-semaine
– Après 1 an : 80% automatisés = 4 personnes-jour
Questions à poser
 What does this tool do?
– What are the benefits of using this tool?
 How can this tool solve my problems?
– Which of my current problems can and can't this tool help with?
– (You need to know what your own problems are.)
 Will you demonstrate your tool using our tests on our site?
– What environment is needed to run this tool?
88
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
– (version numbers of operating systems, RAM, network configuration, etc.)
– How much disk space does it use?
 What does this tool not do?
– What future enhancements are planned for the tool?
– (Note that this also indicates current limitations of the tool.)
– What influence do tool users have on future development of the tool?
 Can tests be re-run in debug mode within the tool?
– Can the tests be run as a background task, so I can do other work while it is running the tests?

 What is the market share of this tool?


– How do you define market share?
– (Every vendor will have a different definition, which makes their tool look best.)
 Why is this tool better than other similar tools?
 What proportion of tools sold are providing real benefits to the organisations which bought them?
– For those which have not succeeded, why haven't they?
– What will I have to do to be sure to succeed with this tool?
 What support is available?
– Training, consultancy, help desk, Service Level Agreement for resolution of problems, technical
expertise in our area?
– What effort is needed in-house by us to support the tool?
 What test planning standards need to be in place to gain real benefits from using this tool?
– (Ask if the vendor has read this book.)
 What features are included to ease the learning curve for the tool?
 How do other sites usually work with the tool?
 Is there a user group, and can I attend the next meeting?
 Can you give me the names of reference sites
– Can I meet with at least two users who are achieving real benefits using this tool?
 How many versions have been released in the past year?
– How is release management handled?
– Do you release a defect list with the product?
 How many known defects are there in the tool currently?
– (If they say none, be wary!)
 What are your QA and test processes?
– What testing is done on the tool itself?
– (What does the vendor know about testing in general?)
– Is the tool used to test itself? (This doesn’t necessary mean a lot.)
 What kind of tailoring / customisation is possible for this tool?
– What extensions / add-ons / in-house routines have other users built?
– (May indicate tool drawbacks or additional work that you will need to do to achieve the best benefit
from the tool.)
 How does this tool integrate with other tools?
– Ask specifically about tools you already have.
 How long will it take to achieve real payback from this tool?
– Can you give me case histories of financial benefits from other users?
– (This is surprisingly difficult - not many users actually track it - make sure you plan to!)
– Can you help me estimate how much effort will be involved in implementing this tool in my
organisation?

• Un test sur les tests


• Ce que n’est pas le test
• Définitions
• Les limites du test

Un test sur les tests


89
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Lire 3 valeurs entières. Ces trois valeurs sont interprétées comme représentant les longueurs des côtés d’un
triangle. Le programme imprime un message qui établit que le triangle est isocèle, équilatéral ou scalène.
• Programmation procédurale
• 33 cas de tests
• Programmation objet
• 58 cas de tests (26 sont les mêmes que ci-dessus, 32 sont dûs à la programmation objet)

Ce que n’est pas le test


• Préciser l’expression des besoins au moyen d’un prototype
• Vérifier une analyse ou un modèle de conception à l’aide d’un analyseur syntaxique ou par simulation
• Peaufiner une interface utilisateur
• Faire des inspections, des revues de code ou de documentation

• Effectuer une analyse statique du code (avec lint par exemple)


• Avoir une compilation sans erreurs ni warnings
• Utiliser des analyseurs dynamiques pour identifier des problèmes de mémoire
• Debugguer

Définitions
• Le test
• Les niveaux de tests
• Les types de tests

90
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Les cas de tests

Le test (IEEE)
IEEE-STD 610.12-1990
"Le test est l'exécution ou l'évaluation d'un système ou d'un composant par des moyens automatiques ou manuels,
pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les
résultats observés"

Le test (AFCIQ)
5. "Technique de contrôle consistant à s'assurer, au moyen de l'exécution d'un programme que son comportement est
conforme à des données préétablies"

• Les niveaux de tests Tests système


• Tests d’intégration
• Tests unitaires
• Tests de non-regression

Les types de tests


• Tests dirigés par les fautes
• Tests de conformité (fonctionnels)
• Tests structurels
• Tests de robustesse
• Tests de performance

Cas (jeu) de Test


• Un cas (jeu) de test spécifie
– L’état de l’implantation sous test (IUT) et de son environnement avant le test
– Le vecteur des entrées et/ou les conditions
– Le résultat attendu
• messages, exceptions
• valeurs retournées
• état résultant de l’IUT et de son environnement

Les limites du test


• L’espace des entrées
• Les séquences d’exécution
• Sensibilité aux fautes

Les séquences d’exécution

91
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
92
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Sensibilité aux fautes
6. int scale(short j) {
7. j = j -1; // devrait être j = j+1
8. j = j/30000;
9. return j;
10. }

Autres limitations
• Tester un programme permet de montrer la présence de fautes mais en aucun cas leur absence

93
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Les tests basés sur une implémentation ne peut révéler des omissions car le code manquant ne peut pas être testé
• On ne peut jamais être sûr qu’un système de test est correct

Tester, pourquoi?
• Fonctionnalités manquantes
• Fonctionnalités incorrectes
• Effets de bord, interactions indésirables
• Mauvaises performances, pbs temps réel, deadlock…
• Sorties incorrectes

Techniques de test
• Classes d’équivalence (éviter l’explosion combinatoire)
• Graphe de cause à effet (identifier et analyser les relations devant être modélisées dans une table de décision)
• Tables de décision (concevoir des cas de test)

Classes d’équivalence
• 8 Classes valides
– triangle scalèle
– triangle isocèle (4)
– équilatéral (2)
• 25 Classes invalides
– 1 valeur = 0
– 3 valeurs = 0
– 1 valeur négative
– triangle isocèle plat

– 3 valeurs telles que la somme de 2 d’entre elles < à la 3ème (6)


– 1 valeur non numérique (3)
– 1 valeur manquante (3)
– triangle scalène plat
– 1 valeur max

Graphe de cause à effet


• Principe : représenter la spécification sous forme d’un graphe
– On définit les états d’entrées et les états de sorties
– On construit le graphe à l’aide de “connecteurs” logiques (et, ou, négation)
• Exemple : soit la spécification suivante:
– Tout identificateur de voiture doit commencer par les lettres A, B ou C et avoir comme 2ème caractère
la lettre X. Les messages M1 et M2 sont émis respectivement en cas d’erreur sur le premier ou le second
caractère. Si l’identificateur est correct, il est inséré dans la base de données.

94
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Diagramme d’activité

Le test en orienté objet


• Niveau application (Uses cases)

95
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le test en orienté objet
• Au niveau sous-système
– test des associations, des agrégations (diagramme de classes)
• multiplicité
• création, destruction
– test de séquences (diagramme de séquence)
• construction d’un graphe de flot
– test des exceptions controlées

Diagramme de classes

Niveau Sous-Système

Le test en orienté objet


• Tests d’intégration (diagramme de classes => arbre des dépendances)

96
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
• Techniques
– big-bang
– bottom-up
– top-down

Diagramme de séquence

Graphe de flot

Test de séquences d ’activation des méthodes

97
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Figure: Diagramme de transition d'états de la classe Client

Le test en orienté objet


• Au niveau de la classe
– test des méthodes
• “concevoir pour tester”
• graphe de contrôle
• graphe de flot de données
– test des séquences d’activation des méthodes
• diagramme de transition d’états
– test des méthodes héritées
• diagramme de classes

Concevoir pour Tester


lire I,J;
débutCas
cas I = 5 et J < 4
alors M = 23;
cas I = 5 et J >= 4
alors M = J + 16;
cas (J + 1) < I et I<0
alors M = 4I +J;
cas (J + 1) < I et I >= 0 et I /= 5
alors M = 5I + 2
cas (J + 1) >= I et J < 2
alors M = 2I + 3J - 4;
cas (J + 1) >= I et J>= 2 et I /= 5
alors M = 3I +2J –2;
finCas
écrire M;
lire I,J;
si I <= J + 1
alors K = I + J -1
sinon K = 2I + 1
finsi
si K >= I+1
alors L = I + 1
sinon L = J - 1
finsi
98
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
si I = 5
alors M = 2L + K
sinon M = L + 2K - 1
finsi
écrire M;

Graphe de Contrôle

Le test en orienté objet


• L’interaction de méthodes (individuellement correctes) de classes et sous-classes peuvent générer des erreurs.
• => Ces interactions doivent être systématiquement exercées.

• Omettre la surcharge d’une méthode d’une superclasse située très loin (haut) dans la hierarchie est facile.
• => Les suites de tests conçus pour les superclasses doivent être réexécutées sur les sous-classes et conçues de
façon à pouvoir être réutilisés pour tester n’importe quelle sous-classe
• La difficulté et la complexité d’implémentation des contraintes de multiplicité peut facilement conduire à des
erreurs quand un élément est ajouté, mis à jour, supprimé.
• => L’implémentation de la multiplicité doit être systématiquement exercée.
• Des classes avec des contraintes séquencielles sur l’activation des méthodes et leurs clients peuvent avoir des
erreurs de séquencement.
• => Le comportement requis doit être testé en utilisant un modèle de machine à états.

Framework Junit

TestFailure
#fFailedTest
0..1

AssertionFailedError Assert <<interface>>


Test *

+fFailures * +fTests
+run(Inout p0:TestResult)
+countTestCases():integer

TestResult TestCase
TestSuite
-fName : string
-fName : string
+runBare()
#runTest() +run(Inout result:TestResult)
* +fListeners #setUp()
<<interface>> #tearDown()
setUp();
TestListener +run(Inout result:TestResult)
runTest();
tearDown();

99
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
100
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Bibliographie

1. Abran, A. ; Desharnais, JM.; Oligny, S.; St-Pierre, D.; Symons, C.; Measurement Manual COSMICFFP 2.2,
The COSMIC Implementation Guide for ISO/IEC 19761, École de technologie supérieure, Université du
Québec, Montréal, Canada, 2003.
2. Castellani, Xavier (1985), « Méthode générale d’analyse d’une application informatique: Tome 1 – Étapes et
points fondamentaux de l’analyse fonctionnelle », 6ème édition, Masson, Paris.
3. ECSS E- 10 Part 1B. System engineering – Part 1: Requirements and process. 18 November, 2004.
4. ECSS E- 40 Part 1B. Software – Part 1: Principles and requirements. November 28, 2003.
5. ECSS E- 40 Part 2B. Software – Part 2: Document requirements definitions (DRDs). March 31, 2005.
6. ECSS Q-80B Software product assurance. October 10, 2003.
7. Rivard, Suzanne et Jean Talbot (2001), « Le développement de systèmes d’information », 3 ème édition, Presses
de l’Université du Québec & Presses HEC, Montral.
8. Rocques, Pascal et Franck Vallée (2004), « UML 2 en action : de l’analyse des besoins à la conception
J2EE », 3ème édition, Eyrolles, Paris.

101
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Annexes I : Étude de cas
Annexe A : Cas du Super Club Vidéotron - Achat et location des films à distance

Le Super Club Vidéotron


Gérante: Monique Tremblay
965, boul. D'Auteuil
Duvernay, Laval
H7E 5J7
Tel (450) 661-0676
1. Présentation
Le SuperClub Vidéotron existe depuis 1989, aujourd’hui la plus grande chaîne de clubs vidéo au Québec. Le SuperClub Vidéotron
occupe 30% du marché de la vidéo loisir au Québec. Le vaste réseau de magasins dessert quelque 1,3 millions de membres actifs
qui effectuent annuellement plus de 22 millions de locations. En plus d’y trouver des vidéocassettes et des disques vidéo numériques
(DVD) à vendre et à louer, on peut s’y procurer la plupart des produits de Groupe Vidéotron dont le décodeur Explorer pour la
télévision numérique, le terminal Vidéoway ou encore des téléavertisseurs et des trousses d’accès Internet. Cent quarante-neuf
magasins, franchisés ou corporatifs, desservent aujourd'hui les principaux centres urbains de la province. Ils appartiennent tous à
Vidéotron, donc à Québécor. Le Super Club à Duvernay que nous avons choisi est enregistré comme une corporative. Le nombre
de clients actifs à Duvernay est de 4000 environ. On voudrait effectuer une expérience d’application d’un système informatique
pour Le Super Club Vidéotron à Duvernay afin de permettre aux clients de se procurer les produits et les services par la livraison:
 Locations et achats de magnétoscopes;
 Locations et achats de lecteurs DVD;
 Locations et d'appareils pour jeux électroniques;
 Service de laminage;
 Service de réparation d'appareils;
 Service de transfert vidéo;
 Service de développement photo.
Services Vidéotron par Internet:
 Abonnement au câble;
 Abonnement à la télé numérique;
 Abonnement à Vidéoway;
 Vente de télé avertisseurs Vidéotron;
 Vente de trousses d'accès Internet.

2. Structure organisationnelle de l’entreprise/organisation

Superviseur National

Superviseur Régional

GÉRANT

Assistant Gérant

14 com mis

3. Présentation de l’application
Le but du présent du travail est de combiner une nouvelle application interactive et conviviale aux employés et aux clients en ligne
de la filiale Super Club Vidéotron inc. de Duvernay (Laval) avec celle actuelle. L’application, d’une part, devra offrir un site Web
disponible au public pouvant montrer les atouts et caractéristiques du Super Club Vidéotron inc. Elle devra offrir un site de
commande en ligne tant pour les produits loués que les produits vendus. D’autre part, le site devra remplacer l’application actuelle
dans les locations de films vidéo en succursale et en innovant dans la réalisation des commandes, ainsi que la gestion comptable des
factures et des règlements.
102
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
4. Problématiques :
Nous avons relevé les différents points problématiques auxquelles fait face le Superclub Vidéotron :
 Une baisse de volume de vente de l’entreprise
 La compétitivité féroce des entreprises des clubs vidéos
 Une difficulté de rentabilités des succursales
 Autres façons alternatives des procurer des films
Vu que les possibilités de rendre le service plus harmonieux à la clientèle du Superclub Vidéotron sont réalisables, nous allons à
partir de cette optique proposer une solution informatique qui couvrira l’acquisition en ligne de l’ensemble de ses produits et services
à savoir : - Location et achat de films tant de type DVD que VHS.

Si l’application s’avère fructueuse, l’entreprise généralisera la vente de l’ensemble des produits vendus des succursales du Superclub
Vidéotron à savoir :
 Locations et achats de magnétoscopes;
 Locations et achats de lecteurs DVD;
 Locations d'appareils pour jeux électroniques;
 Service de laminage;
 Service de réparation d'appareils;
 Service de transfert vidéo;
 Service de développement photos;
 Abonnement au câble;
 Abonnement à la télé numérique;
 Abonnement à Vidéoway;
 Vente de téléavertisseurs Vidéotron;
 Vente de trousses d'accès Internet.

5. Objectifs :
L’application, devra offrir un site Web disponible au public pouvant montrer les atouts et caractéristiques du Super Club Vidéotron
inc. Elle devra offrir un site de commande en ligne tant pour les produits loués que les produits vendus.

6. Principales solutions proposées :


- Achat et location de produits et services via Internet;
- Achat et location de produits et services par téléphone;
- Achat et location de produits et services par une tierce personne.
La solution retenue qui est l’achat et la location de produits et services via Internet permet au Superclub Vidéotron de mieux servir
sa clientèle en toute sécurité. Elle permet, en outre, de consolider la vision stratégique à long terme de l’entreprise Vidéotron qui
désire promouvoir pratiquement à l’exclusivité une offre de service à caractère électronique (B to B et B to C) à moyen terme.

7. Délimitation dans le temps et dans l’espace :


Dans l’air des technologies avancées, notamment le domaine de l’informatique, on a tendance à vivre des changements en un
record de temps jamais connu, pour cela il est envisageable d’admettre que notre application pourra changer de conception en
allant de la location et l’achat de films via Internet vers leur visualisation sur place à partir de l’écran. Notre application couvrira
en terme d’espace une partie de l’Île Jésus avec les délimitations suivantes :
- Au nord, le boulevard Saint-Martin Est;
- À l’ouest, le boulevard Papineau;
- À l’est, l’autoroute 25;
- Au sud, la rivière des Mille-Îles.

8. Importance de l’application :
Comme déjà cité, la vision stratégique de l’entreprise est, en bout de ligne, d’orienter au maximum l’utilisation maximale des actifs
présents en déployant une technologie favorisant les contacts de type B To B et B To C. L’exemple d’Illico, une technologie
favorisant la personnalisation des choix des chaînes de télévision, est aspect convainquant de l’orientation voulue.

103
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Dans le cas du Super Club Vidéotron, l’entreprise désire dépasser la capacité de ses concurrents à offrir un marché fort personnalisé
et une garantie de disponibilités des produits visuels. En outre, il existe plusieurs moyens technologiques et pratiques afin que le
consommateur puisse visualiser le produit vendu dans un délai restreint: chaîne câblé onéreuse, chaîne câblé avec équipement, dont
seulement le quart est actuellement exploité, ou maximisation du nombre d’établissements.
Dans le cas du dernier cas cité, cette vision est partiellement utilisée. En fait, en acceptant de partager le risque avec un autre acteur
(investisseur), la possibilité de dégager une création valeur semble possible. Par contre, de plus en plus, le marché devient saturé et
risque de tomber dans un déclin compte tenu des deux autres éventualités exprimées au préalable.
Il faut donc, rapprocher au maximum la succursale au client. Le moyen actuel, étant le plus économique, est l’établissement d’un
site web. En fait, la clientèle visée par l’entreprise est un segment de la population qui se situe dans l’intervalle de 25 à 40 ans. Ce
sont soit des jeunes familles ou encore des célibataires. On dénote présentement, dans les études stratégiques de l’entreprise, une
propension fort importante du chiffre d’affaire en vigueur.
Pour le moment, pour faciliter la conception de l’application, le mode de paiement utilisé sera par carte de crédit. Il sera effectué
de façon électronique par un commis-vendeur à la succursale. Dans le but d’authentifier la validité de l’opération, l’implantation se
fera à partir d’une succursale et déployer, par la suite, dans d’autres succursales du même district.
En finalité, l’application voulue est une prémisse à un centre de location virtuel qui permettra de diffuser carrément à même le site
la location désirée supprimant carrément la possibilité et l’éventualité de produits non disponible.

9. Capture initiale des besoins


9.1. Acteurs du système, ont pour tâche :
Commis-vendeur
 Réquisitionner, traiter, préparer la commande et confirmer avec le client jusqu’au moment où le livreur viendra chercher la
commande en question.
Client
 Le client doit procéder à l’adhésion au service soit par demande électronique et ou à la succursale Super Club Vidéotron inc. de
Duvernay (Laval);
 Consulter, Sélectionner et procéder aux achats et ou locations désirées;
 Obtenir la confirmation de sa sélection de la part du commis-vendeur par téléphone et courrier électronique.
Livreur
 Transporter les items sélectionnés par le client;
 Confirme l’authenticité du client et lui délivre les items sélectionnés;
 Procède à la signature du client sur le bon de livraison;
 Donne une copie de la facture des items sélectionnés.
Administrateur de système
 Procéder à la mise à jour du système et de la page Web de la succursale Super Club Vidéotron inc. de Duvernay (Laval);
 Procéder à la gestion des utilisations et de leurs composantes.
Responsable
 Possède l’accès à l’ensemble du système afin de procéder à la gestion de cas et de la comptabilité.

Capture des besoins techniques


Configuration matérielle
Nous avons pu observer que tous les outils nécessaires sont déjà présentement en place afin de mettre à terme notre application. En
somme, aucun achat n’est nécessaire à être compléter en vue de notre implémentation.
Le SuperClub Vidéotron de Duvernay possède présentement comme équipements informatiques les éléments suivants :
 2 PC, avec processeur « 486 » ayant les utilitaires normaux (clavier, écran, souris et carte réseau de type Ethernet);
 1 PC, avec processeur « pentium II » ayant les utilitaires normaux (clavier, écran, souris et carte réseau de type Ethernet);
 1 serveur central (qui est en fait un PC sans ses utilitaires);
 1 connecteur de type câble coaxial (pour Internet et Intranet);
 1 Pont filtrant (Firewall);
 Câblage pour réseau;
 2 imprimantes matricielles;
 1 imprimante laser.

En vulgarisant, les plates-formes nationales nécessaires à l’implémentation de notre système sont :


 1 PC, avec processeur « pentium II » ayant les utilitaires normaux (clavier, écran, souris et carte réseau de type Ethernet);
 1 serveur central, où sera contenu notre application;
 1 serveur web, où est déjà diffusé la page WWW de l’entreprise
 1 Pont filtrant (Firewall);
 Câblage pour réseau.
104
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
TRAVAIL À FAIRE :
Élaborer un plan de qualité logicielle.

Élaborer un plan de tests avec les cas de tests.

Merci de vous inspirer et de vous conformer au cahier des charges et aux normes ISO9001, 9002, 9003 et 9004.

Bonne chance!

Annexe B : Cas de RÉFAEC – PHP Extranet

1. Présentation de l’entreprise / Organisation


L’entreprise pour laquelle le site Web doit être conçu et analysé est le regroupement des étudiants des facultés d’administration de
l’est du Canada, mieux connue sous l’appellation abrégée REFAEC. La mission de cette dernière est de représenter les besoins
spécifiques que partagent les étudiant(e)s des facultés universitaires d’administration du Québec, ainsi que celles de Moncton et
d’Ottawa dans leur volonté commune d’intervenir au sein de la société pour en influencer l’édification.
Aussi, elle se doit de permettre l'accomplissement académique, social et professionnel des étudiants en administration de l'Est du
Canada qui sont membres du regroupement. En effet, les membres doivent être étudiants de premier cycle, d’un cycle supérieur
ou de l’éducation permanente.
La REFAEC fut fondée en 1987 par l’Université du Québec à Montréal. À cette époque, celle-ci regroupait seulement des étudiants
de l’Université du Québec à Montréal et visait seulement à faire valoir les droits des étudiants tout en étant un lieu d’échanges
intéressants. Progressivement, d’autres universités se sont jointes au regroupement et aujourd’hui en 2002 la REFAEC est fière
d’accueillir une nouvelle université membre soit celle de Hull.
2. Activités principales de la REFAEC
Les activités principales de la REFAEC consistent à :
 Favoriser la communication entre les associations étudiantes des facultés d'administration de l'Est du Canada
 D’être la référence en gestion d'événement inter universitaire
 De représenter les intérêts des étudiants en administration sur la scène publique, académique et politique afin d'améliorer
les conditions des étudiants et pouvoir augmenter la valeur des diplômes
 De développer des relations avec les organismes publiques, paragouvernementaux et les entreprises et associations du
monde des affaires dans la même optique de pouvoir rapprocher les étudiants de la réalité et de leur permettre d'avoir de
meilleurs outils pour arriver sur le marché du travail.
La REFAEC chapeaute aussi toutes les associations étudiantes de chaque université membre, également cette dernière voit à la
coordination de 3 grands événements : symposium (grh), happening marketing et jeux du commerce.
3. Quelques données chiffrées
En ce qui a trait au chiffre d’affaires de la REFAEC, il faut savoir que la cotisation est de 0,375$ par étudiant par session, soit 0,75$
par étudiant par année. La cotisation est calculée selon le nombre d’étudiants représentés par chaque association étudiante membre
de la REFEAC. Pour l’année 2002-03, le chiffre d’affaires prévisionnel sera d’environ 29 000$.
Les clients de la REFAEC sont avant tout, les associations membres provenant de différentes universités. En autres, il y a l’École
des Sciences de la gestion, le HEC, les universités Concordia, Mcgill, Bishop, Laval, d’Ottawa, de Chicoutimi (UQAC), de Rimouski
(UQAR), de Trois-Rivières (UQAT) et finalement celle de Hull. De même, on compte les recteurs et doyens des facultés des diverses
universités. En tout, on peut compter environ 35 000 clients.
La REFAEC compte une vingtaine d’employés, soit les membres siégeant sur le conseil exécutif et ceux qui sont recrutés par ce
dernier. Le volume d’information traitée est assez important puisqu’il englobe les échanges qui sont faites avec les étudiants et
associations membres. Ces échanges sont faits en grande majorité par courriels, et deviendront encore plus important à la suite de la
construction du nouveau site Web. La particularité des opérations est telle que le processus de transmission de l’information et la
communication auront plus lieu par le réseau Internet mais aussi par Intranet.
Au niveau de la complexité des traitements, nous qualifions de moyenne puisqu’il faudra, entre autres, envoyer des courriels à des
groupes distincts, diffuser les informations et faire en sorte que certaines informations soient de nature publique alors que d’autres
ne serait qu’accessible par certains membres.

4. Structure organisationnelle de l’entreprise / organisation

105
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
La structure organisationnelle de la REFAEC se compose d’un président, d’un vice-président aux finances et commandites, d’un
vice-président aux affaires internes, d’un vice-président aux affaires interuniversitaires, d’un vice-président aux affaires
académiques et d’un vice-président aux communications. Voici un bref aperçu des rôles de chacun :
4.1. Président:
 Représentant officiel de la corporation
 Coordonne le travail des autres officiers
 Préside les réunions du Comité exécutif
 Rend officiel tout document officiel par sa signature
 Développe les orientations stratégiques de la corporation
 Responsable des événements sous le RÉFAEC
4.2. Vice-présidence aux finances et aux commandites :
 Assiste le président dans ses fonctions
 Établit les budgets et en fait le suivi,
 Gère les mouvements de trésorerie
 Prépare les états financiers et s’assure qu’ils sont exacts
 Assure les bonnes relations avec les commanditaires
 Développe de nouveaux partenariats et trouve de nouveaux moyens de financement
 Est responsable du suivi du nombre d’étudiants par faculté et de la perception de la cotisation
4.3. Vice-présidence aux affaires internes:
 Assure le suivi des activités qui relèvent du REFAEC
 Venir en aide aux comités organisateurs des activités si cela est nécessaire et pertinent
 Assure un lien continu entre le REFAEC et les activités
4.4. Vice-présidence aux affaires interuniversitaires :
 Responsable des communications interuniversitaires
 Responsable de la convocation des instances de la corporation
 Responsable de la transmission des documents au sein de la corporation
 Responsable des procès-verbaux et documents officiels
 Offre du support aux associations étudiantes
 Assure le lien avec les autres regroupements étudiants
4.5. Vice-présidence aux affaires académiques :
 Assure le développement de dossiers académiques.
 Assure la représentation étudiante pour tous les dossiers d’ordre académique.
 Assure le lien avec les directions des universités et le gouvernement dans le cas de la défense de questions d’ordre général
et de revendications.
 Est un point de référence pour les universités en ce qui a trait aux dossiers académiques et s’assure de donner des outils
pertinents aux universités dans le besoin.
4.6. Vice-présidence aux communications:
 Élabore une stratégie promotionnelle
 Développement de relations avec les médias étudiants et à grande échelle
 Supervision des dossiers publics
 Gestion et développement de l’image de marque du RÉFAEC
 Développement et suivi du Site Web
4.7. Organigramme
Conseil exécutif

Président

V-P finances et commadites

V-P affaires internes

V-P affaires inter-universitaires

V-P affaires académiques

V-P communications

5. Présentation de l’application
L’application sera subdivisée en menus dans lesquels les utilisateurs vont pouvoir accéder aux informations pertinentes leur
demande. L’interface sera beaucoup plus conviviale de sorte que les informations seront plus enclines à être consultées tant que par
les étudiants, les associations et les membres du conseil exécutif.
106
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
L’application sera aussi dotée d’un système de mailing-List par lequel les membres inscrits seront en mesure de recevoir les
informations par voie de courriers électroniques. Ceci étant un outil de promotion important des rencontres organisées par la
REFAEC mais aussi par les différentes associations étudiantes.
Aussi, l’application aura une base de données dans laquelle les informations des membres seront faciles d’accès pour le conseil
exécutif et protégées pour les utilisateurs externes du conseil.
6. La problématique
La problématique est telle que le site web est inadéquat parce qu’il y a une mauvaise circulation de l’information entre les différents
membres de l’exécutif, le conseil d’administration et les membres. En effet, le site n’est plus efficient compte tenu de
l’augmentation de la clientèle et de sa diversification.
Les besoins de notre client sont de donner une image plus professionnelle de l’organisation, de pouvoir améliorer la communication
entre les membres (étudiants, conseil d’administration et conseil exécutif), de mieux répartir la charge de travail entre les membres
du conseil exécutif et le conseil d’administration, de regrouper l’ensemble des contacts et coordonnées et d’assurer un meilleur suivi
des projets.
7. L’objectif
L’objectif de la présente application est d’optimiser le site Web de la REFAEC pour qu’il puisse répondre efficacement aux besoins
de la clientèle étudiante ou associative. Les principales solutions préconisées sont, dans un premier temps, de rendre le site plus
convivial, ensuite mettre en fonction un mailing list pour que les étudiants et associations membres soient tenus au courant des
derniers développements de l’organisation. Il est aussi proposé l’installation d’une base de données, contenant diverses informations
au sujet des étudiants et associations, dont certaines parties seraient publiques et d’autres privées.
La réalisation de cette application web devrait prendre environ 6 mois, durant lesquels il sera mis en place les solutions
d’amélioration à proposer à la REFAEC.
8. Importance de l’application
Cette application est d’une importance significative puisqu’avec le site Web, la REFAEC sera en mesure de rejoindre un nombre
plus grand de clients et ce, d’une façon plus simple. De plus, l’organisation sera en mesure d’assurer un meilleur service à la clientèle
aux membres en permettant la communication par voie de courriers électroniques et aura un outil promotionnel intéressant en
diffusant de l’information sur les événements organisés par ses associations par la mailing list. De plus, avec la mise en place de la
base de données, la gestion des membres en sera simplifiée de sorte que le conseil exécutif pourra se pencher sur des sujets plus
importants. Notre application sera donc en mesure de diminuer les coûts et d’augmenter le nombre de clients abonnés.
9. Capture initiale des besoins
Cette section a pour but de définir ce que le système devra réaliser. Il y a lieu d’identifier les acteurs du système et mettre tous les
éléments identifier en contexte pour définir les frontières du système. En plus d’identifier les acteurs de ce système il faut définir
quel seront les messages qui seront échangés entres eux. Le schéma de circulation des informations, les diagrammes de contexte
statique et dynamique sont nécessaires pour schématiser les données recueillies et la circulation des informations.

10. Acteurs du système


Il y a différents acteurs qui vont interagir avec le système. Notamment, il y aura le président qui consultera, modifiera et créera des
listes d’étudiants membres tout ayant une main mise sur la modification de toute autre information. Viens ensuite, le vice-président
des finances qui aura pour but de saisir et modifier les données relatives au budget, en plus d’assurer la communication avec les
autres associations. Ensuite, il y a le vice-président des affaires internes qui consultera et modifiera la liste des associations qui
utiliseront le mailing list. Le vice-président des affaires interuniversitaires qui saisira le compte-rendu des procès-verbaux sur le site,
en plus de communiquer avec les différents partenaires universitaires. Le vice-président des affaires académiques qui créera,
modifiera et consultera les dossiers étudiants de la base de données, en plus d’apporter des changements à la mailing list pour les
étudiants inscrits à ce service. Le vice-président aux communications va gérer l’ensemble du site Web et agira comme administrateur
de ce dernier, notamment au niveau des niveaux d’accès. Les représentants des régions de l’Est et de l’Ouest vont consulter surtout
les informations relatives aux universités membres de leurs divisions. Pour terminer, il y a aussi les clients de l’application qui sont
les étudiants.

TRAVAIL À FAIRE :
Élaborer un plan de qualité logicielle.

Élaborer un plan de tests avec les cas de tests.

Merci de vous inspirer et de vous conformer au cahier des charges et aux normes ISO9001, 9002, 9003 et 9004.

Bonne chance!

Annexe C : Le cas de la Boulangerie Lépine ltée

107
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le cas de la Boulangerie Lépine ltée nous permet d’exposer ici un type d’étude de cas. Le processus utilisé est identique à celui qui
a été vu précédemment. Toutefois, il est important de souligner que cette approche n’est pas la seule possible. L’étudiant ne doit pas
se sentir obligé d’adopter intégralement le modèle ou la présentation que l’on trouve dans l’exemple suivant, sauf s’il croit que cette
approche s’adapte assez bien au cas particulier qu’il analyse.

L’étudiant verra que l’approche utilisé e ci-dessous perme t une analyse relativement complète et satisfaisante en même temps
qu’elle donne l’occasion de voir comment un problème peut être abordé. Dans certains cas, il n ’est pas nécessaire de faire une ana
lyse aussi exhaustive; toutefois, dans d’autres cas, il sera nécessaire de pousser davantage l’analyse. Le principal objectif de la
présentation suivante est de montrer comment il est possible d’évaluer une situation en se basant sur des informations et des données
assez sommaires.

La présentation du cas Boulangerie Lépine ltée comportera d’abord une page récapitulative ou un sommaire, puis les étapes
suivantes:
1. la définition du problème à la suite de l’évaluation de la situation ;
2. la détermination des options possibles ;
3. l’analyse des faits pertinents (analyse des deux options possibles) ;
4. le choix et la recommandation.

108
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
HISTOIRE DU CAS
Vers la fin de 2005, Georges Lépine, P.-D. G. de la Boulangerie Lépine ltée, a étudié la possibilité d’investir la somme de 5 M$
dans la construction d’une usine de fabrication. Il projetait de distribuer les produits par l’intermédiaire d’une chaîne de magasins
d’alimentation et d’une multitude d’entreprises vendant des produits de boulangerie au détail.
À cette époque, la Boulangerie Lépine ltée ne s’occupait que de la commercialisation de ses produits, lesquels étaient vendus par
des grossistes et des détaillants, et ne s’intéressait pas à leur fabrication: elle achetait les produits d’un fabricant. M. Lépine avait
créé son entreprise en 1999 et, depuis l’ouverture de celle-ci, les ventes avaient fortement et constamment augmenté. Le succès
remarquable de la firme était dû principalement à l’effort et au dynamisme de M. Lépine dans le domaine de la commercialisation:
publicité, promotion et service à la clientèle.
L’entrepreneur jouissait d’une excellente réputation dans l’industrie. Dès la première année, le chiffre d’affaires
de sa société s’est élevé à 1,5 M$. À la suite de soudaines augmentations des ventes, la société a embauché 10 vendeurs et, en 2005,
les ventes se sont chiffrées à 14 M$. Depuis son ouverture, la Boulangerie Lépine ltée achetait tous ses produits d’un fabricant de la
région réputé dans le domaine de la boulangerie : la société Produits Croteau
inc. Les produits vendus par la Boulangerie Lépine portaient souvent la marque de commerce de ses clients les plus importants. En
2005, le chiffre d’affaires de la société Produits Croteau s’élevait à 58 M$.
En juillet 2005, Georges Lépine avait rencontré à plusieurs reprises Oscar Coderre, président et principal Actionnaire de la société
Produits Croteau. Ces entretiens avaient pour but de discuter de la fusion des deux entreprises. Au cours de ces réunions, M. Lépine
avait fait part à M. Coderre de son plan de commercialisation pour les cinq prochaines années et lui a dit qu’il prévoyait une
croissance plus rapide que celle de l’ensemble du secteur de l’alimentation et de la pâtisserie.
Jusqu’en 2005, la Boulangerie Lépine possédait environ 6,5 % du marché du secteur et, selon le plan de commercialisation de son
propriétaire, le taux de croissance annuelle des ventes était supérieur à celui de l ’ensemble du secteur. Pour 2010, M. Lépine
prévoyait détenir 10,1 % du marché et atteindre un chiffre d’affaires de 26 M$.
Les principaux facteurs contribuant à une telle augmentation des ventes étaient les suivants :
1. l’extension du territoire de la distribution des produits ;
2. la commercialisation de nouveaux produits (couramment vendus dans d’autres régions du pays) ;
3. l’amélioration de la qualité des produits déjà existants ;
4. l’amélioration du service à la clientèle ;
5. la commercialisation plus dynamique (techniques marchandes plus poussées, programmes de promotion).
Cependant, pour permettre à M. Lépine de réaliser les objectifs visés, la société Produits Croteau devait modifier ses usines de
fabrication et transformer certaines de ses activités, comme l’exigeait la fabrication des nouveaux produits proposés par Georges
Lépine.
Oscar Coderre était tout à fait en faveur de cette idée et a été impressionné par l’innovation proposée par M. Lépine en matière de
politique de vente. Toutefois, en homme d’affaires conservateur, il en visage ait plutôt un plan d’action comportant plusieurs étapes.
Il a fait les observations suivantes à ce sujet : « Notre société existe depuis un quart de siècle. La politique de l’entreprise est de
progresser graduellement et de financer les programmes d’expansion en recourant aux sources de financement internes (bénéfices
non répartis). Nous n’avons pas l’intention de risquer ce que nous avons acquis jusqu’à ce jour en collaborant à un projet
d’investissement aussi coûteux, basé seulement sur un programme de vente qui n’a pas encore été soumis à des tests. » Georges
Lépine était pour sa part convaincu du potentiel et de la pertinence de ses plans et il a insisté pour moderniser l’usine dès la première
année, sachant que celle de M. Coderre ne fonctionnerait pas à plein rendement durant les trois premières années. Il était persuadé
que si les investissements étaient faits en un seul temps, les économies atteindraient 25 %.
Après plusieurs rencontres, les deux hommes d’affaires n’ont pu arriver à une entente satisfaisante. M. Lé pine a menacé de cesser
de faire des affaires avec la société Produits Croteau et de commencer à fabriquer ses propres produits, et ce, en construisant son
usine dans la ville où se trouvait l’usine de M. Coderre.
Au cours des mois suivants, Georges Lépine, à la recherche d’actionnaires, a tenté de réunir auprès d’entrepreneurs de la région
suffisamment de capital-actions pour financer son projet. Il a rencontré aussi le directeur de la banque et les dirigeants de quelques
institutions en vue d’obtenir le financement de son projet à court et à long terme. L’entrepreneur n’a pu toutefois obtenir le
financement requis, en raison de ses faibles ressources en capital-actions, et, malgré d’autres tentatives, sa requête est demeurée
vaine.
Fac e à cette situation, M. Lépine a décidé de construire son usine dans une autre ville où il croyait pouvoir rassembler un plus grand
nombre d’actionnaires.

109
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Après avoir discuté de son projet avec plusieurs entrepreneurs de la région et obtenu l’adhésion de 12 d’entre eux, il a pu réunir
suffisamment de fonds en capital-actions. Les sommes fournie s par les actionnaires et les bailleurs de fonds n’étaient cependant pas
suffisantes pour construire une usine aussi grande qu’il avait prévu, le capital disponible ne permettant de réaliser que les trois quarts
des plans originaux. M. Lépine avait néanmoins reçu l’approbation de ses b ailleurs de fonds pour le financement (à court et à long
terme) des bâtiments, l’achat d’équipement et la constitution de son fonds de roulement.
Notre entrepreneur avait alors à prendre une décision importante, soit aller de l’avant selon ses plans, soit continuer à entretenir des
relations d’affaires avec la société Produits Croteau.

TRAVAIL À FAIRE :
Élaborer un plan de qualité logicielle.

Élaborer un plan de tests avec les cas de tests.

Merci de vous inspirer et de vous conformer au cahier des charges et aux normes ISO9001, 9002, 9003 et 9004.

Bonne chance!

Annexe D : Le cas d’Info Web Santé – Solution de type e-Communauté

1. Présentation de l’organisation et de l’application


Comme sujet pour le projet de session, le CLSC de Côte-des-Neiges a été retenu. Le CLSC Côte-des-Neiges est un établissement
public et sans but lucratif qui fait partie du réseau de la santé et des services sociaux.
Depuis près de 30 ans, le CLSC Côte-des-Neiges existe, voici un bref aperçu des principaux changements survenus depuis 1975 ;
2. Activités principales
Le CLSC Côte-des-Neiges offre, entre autres, des services de consultations médicales, des soins et services à domicile aux personnes
en perte d'autonomie, le dépistage du SIDA et des MTS, des cliniques de vaccination et de prélèvement, des services postopératoires
et post-hospitaliers à domicile et des programmes en périnatalité et en santé mentale.
Le CLSC dispense ses services soit dans ses installations, soit dans le milieu de vie, à l'école, au travail ou à domicile.
Le CLSC Côte-des-Neiges entretient des liens de partenariat avec les hôpitaux, les cliniques privées, les centres hospitaliers de soins
de longue durée, les services de police, les écoles, les universités, les centres de la petite enfance (CPE), les services d’immigrations,
le centre local 40 d’emploi, etc.
"La mission d'un centre local de services communautaires est d'offrir en première ligne à la population du territoire qu'il dessert
des services de santé et des services sociaux courants, de nature préventive ou curative, de réadaptation ou de réinsertion.
À cette fin, l'établissement qui exploite un tel centre s'assure que les personnes qui requièrent de tels services pour elles-mêmes ou
pour leurs familles soient rejointes, que leurs besoins soient évalués et que les services requis leur soient offerts à l'intérieur de ses
installations ou dans leur milieu de vie, à l'école, au travail ou à domicile ou, si nécessaire, s'assure qu'elles soient dirigées vers les
centres, les organismes ou les personnes les plus aptes à leur venir en aide." 1
3. Quelques données chiffrées
3.1. Ressources financières
Le CLSC Côte-des-Neiges a reçu pour l’année 2004-2005 un budget de 25 498 354$.
3.2. Clientèle
Le CLSC Côte-des-Neiges et ses points de service desservent une population de plus de 125 000 habitants (126 665) répartis dans
les territoires de Côte-des-Neiges, Snowdon, Outremont et Ville Mont-Royal
 Deux environnements regroupent cette population: un premier (Côte-des-Neiges et Snowdon: 84 125 habitants) davantage
marqué par la pluriethnicité et la pauvreté, un second (Outremont et Ville Mont-Royal: 42 540 habitants) caractérisé par un
niveau économique plus élevé.

1
(Loi sur les services de santé et les services sociaux, L. Q. 1991, chapitre 42, art. 80)

110
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
 Au sein de la région de Montréal, les secteurs Snowdon et Côte-des-Neiges se démarquent fortement avec des pourcentages
élevés d’immigrants, soit respectivement 39,5% et 40,9%.
 La population a augmenté dans le territoire du CLSC Côte-des-Neiges entre 1991 et 1996 (de 122 160 à 126 665 individus).
 Les familles monoparentales constituent 31,9% des familles avec enfant(s) dans le secteur Côte-des-Neiges.
 Chez les hommes, dans les secteurs Côte-des-Neiges et Snowdon, ce taux est respectivement de 18,9% et de 18,7% tandis qu’il
est de 7,1% dans Outremont/Ville Mont-Royal.
 Quant à la population «pauvre», elle représente 38,4% et 42,3% des secteurs Côte-des-Neiges et Snowdon.
3.3. Ressources humaines
Au 31 mars 2004, le CLSC comptait 481 employés et cadres.

Effectifs par catégorie d’emploi :


 Sage-femme (11 personnes);
 Personnel psychosocial (86 personnes);
 Personnel infirmier (116 personnes);
 Personnel de bureau et administratif (116 personnes);
 Personnel auxiliaire familial et social (76 personnes);
 Personnel du secteur santé (autres) (51 personnes);
 Chercheure boursière (2 personnes);
 Personnel cadre (23 personnes).
3.4. Structure organisationnelle de l’organisation
Direction générale

Direction générale
Suzanne Walsh

Responsables professionnels:
Clinique Soins infirmiers: A. Bourgon
Santé -Accueil Travail social: K. Vitez
Sage-femme: M. Dehertog
4 équipes de Chef de médecine
mé decine familiale Vania Jimenez

Services intégrés pour


femme enceinte
Gestion de programme
Accueil et Info-Santé Direction Ressources
(vacant) financières et matérielles
Julie d’Entremont
Gestion de programme
Aide aux réfugiés Direction Soins
Claudette Forest et services cliniques
Diane Inkell
Coordination
Maison de naissance
Marleen Dehertog
Gestion de programme
équipe multi A
Direction
Conseiller à
Françoise McDonald Gestion de programme Ressources humaines la direction R.H.
Réce ption/soutie n Céline Dépelteau (vacant)
Diane Desjardins
Coordination du
Gestion de programme programme
équipe multi B Santé au travail
Annick Simard Hélène Cyr
Gestion de programme Coordination de
Équipes Sud et l’enseignement
Gestion de programme Plamondon Kristine Vitez
équipe multi C France Leclerc
Diane Gorton
Direction Services
Direction professionnels et Gestion de programme
Gestion de programme Enfance-Famille, activités d’enseignement Service d’archives
Gestion de programme Équipes Centre e t Jeunesse, Adulte Suzanne Walsh Chantal Cloutier
équipe multi D Mountain Sights Réjeanne Laroche
Nathalie Richard Patricia Riano
Conseillère à
la direction S.P.
Gestion de programme Gestion de programme Josée Peat
équipe multi E Équipe Outremont/
Amina Talib Mont-Royal Direction
Lyne Soucy-Labranche
Direction Centre de recherche
Gestion de programme Maintien à domicile et de formation
équipe multi F (Multiclientèle) Spyridoula Xenocostas
Manon Laroche Nicole Huneault

Conseillère à la
direction du MAD CLSC Côte-des-Neiges, sept. 2004
Lorraine Bouvier

4. Présentation de l’application
Présentation du projet
Le CLSC Côte-des-Neiges est un établissement public et sans but lucratif. Une partie de sa mission est d’offrir des soins et services
de santé, préventif et curatif, à la population du territoire qu’elle désert.

Le CLSC Côte-des-Neiges souhaite se doter d’un système e-communauté permettant d’offrir des services, tel les services Info-
Santé, accessible par le biais d’Internet. Ce système informatique performant permettra d’offrir :
 Aux clients la possibilité de communiquer avec une infirmière en ligne ;
 Aux infirmières la possibilité de communiquer avec divers spécialistes ;
 À la clientèle la possibilité de consulter une bibliothèque virtuelle;
 À la clientèle la possibilité d’assister à des conférences virtuelles de spécialistes;
La durée de vie du nouveau système, appelé Info-Web-Santé (IWS), est estimée à 5 ans.
4.1. Grands choix techniques

111
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Afin de maîtriser les risques, le CLSC Côte-des-Neiges souhaite utiliser une approche itérative et incrémentale, fondée sur le
processus en Y (2TUP : Two Track Unified Process).
Après une première étude, un certain nombre de choix technique ont été officialisés.
Ces technologies clés sont principalement :
 La modélisation objet avec UML ;
 Architecture en 3-Tier;
 Accès client via Internet ;
 Plateforme Java ;
o Jakarta Struts (cadre standard de développement d'applications web)
o JSP - JavaServer Pages (contenu web dynamique)
o EJB - Entreprise Java Beans (applications distribué, transactionnels, sécure et portable en JAVA) avec CORBA pour les
o JDBC - Java Database Connectivity
o Swing (Interfaces Graphique)
o SGBD (Oracle SQL)
 Plateforme PHP (pour logiciel de forum Vbulletin
http://www.vbulletin.com/features.php)
o SGBD – (MySQL)
Autre point crucial, le CLSC Côte-des-Neiges souhaite intégrer au maximum le nouveau système avec le système d’information sur
la clientèle (I-CLSC).
Le positionnement respectif de tous ces éléments techniques est illustré à la figure suivante :
4.2. Architecture logicielle préliminaire

Soutien

Client

Internet SAN
WIS
Avis de
naissance
SQL

Proxy

SQL iCLSC

S IWS
TP
HT
SQL

SQ
L

Apache
(serveur web)
Bibliothèque
BD Protocoles
Serveur video Info-Santé

5. Problématique
Avec l’émergence de l’utilisation d’Internet dans les foyers québécois, il devient de plus en plus évident que cette utilisation doit
aider aux CLSC à offrir des services de première ligne à la population.
En effet, selon une étude menée au Québec, en 2004 presque 3,6 millions de Québécois âgés de 18 ans et plus utilisent le réseau
Internet. Les liens haute vitesse font aussi de plus en plus partie intégrante de l’utilisation d’Internet, à raison de 38,1% des ménages
québécois en 2005.
D’autre part, les infirmières répondant aux nombreux appels Info-Santé sont de plus en plus submergées d’appels et les délais
d’attente des clients s’allongent sans cesse.
Le défi auquel fait face le CLSC Côte-des-Neiges est de savoir comment les technologies de l’information peuvent l’aider à offrir
son service de première ligne de façon plus efficiente.
6. Objectif
Mettre en place un système d’information afin d’aider au CLSC à assurer son service de première ligne.
7. Principales solutions proposées
La mise en place d’une application de type e-communauté permettrait d’assurer des services par Internet. En effet, les clients seraient
en mesure de consulter en ligne des infirmières. Ces dernières pourraient accéder à des personnes-ressources plus spécialisées dans
différentes sphères : nutritionnistes, pédiatres, psychologues, oto-rhino-laryngologistes, cardiologues, endocrinologues, etc. De
plus, les clients auraient la possibilité de participer à des conférences virtuelles et accéder à des ressources documentaires.

112
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
La résultante de ce nouveau service permettrait de soulager les systèmes téléphoniques d’un certain nombre d’appels. L’achalandage
au CLSC même s’en verrait diminué par la même occasion.
Délimitation dans le temps et dans l’espace
Nous estimons la durée de conception du projet à six mois. Cette application sera développée pour le CLSC Côte-des-Neiges et
pourra éventuellement être adoptée par l’ensemble des CLSC. L’hébergement de cette application sera à même les locaux du CLSC.
Nous considérons que la durée de vie du système Info-Web-Santé s’estime à cinq ans. Il est certain que des mises à jour, des
corrections, des modifications de l’application sont à prévoir.
8. Importance de l’application
8.1. Désengorgement des lignes téléphoniques
Les clients, en accédant aux services en ligne, appelleraient moins sur les lignes téléphoniques Info-Santé, ce qui diminuerait le
nombre d’appels. Le délai d’attente s’en verrait ainsi diminué.
Toutefois, la clientèle cible de ce nouveau service se situerait dans les groupes d’âge les plus jeunes, alors que la clientèle plus âgée
continuerait d’utiliser les services traditionnels.
8.2. Diminution de l’achalandage à la clinique
Puisque certaines réponses aux questions les plus courantes se retrouveraient sur le site d’Info-Web-Santé, l’achalandage à la
clinique pour ce type d’intervention s’en verrait diminué, ce qui aurait une résultante sur l’achalandage total.
La prémisse selon laquelle les infirmières pourraient avoir accès au bout des doigts aux spécialistes diminuerait le besoin de consulter
des spécialistes au CLSC, dans le cas de problèmes mineurs de santé.
8.3. Recueil des besoins fonctionnels
Un premier tour d’horizon des besoins exprimés par les employés de l’établissement a permis d’établir le cahier des charges
préliminaire suivant :
 Communication avec une infirmière
Le client accède à partir du portail Web au module « Infirmière en ligne ».
Si le client est déjà connu par le CLSC, c’est-à-dire qu’il a déjà un dossier dans le système d’information clientèle I-CLSC,
l’infirmière doit consulter l’information dont elle dispose au sujet du client en question.
Si le client n’est pas connu, il doit fournir les informations obligatoires pour l’ouverture de son dossier dans le système
d’information I-CLSC.
Le client questionne l’infirmière au sujet de sa problématique. L’infirmière lui répond et les deux interlocuteurs peuvent
continuer les interactions tant que la problématique n’est pas réglée.
Cette communication est enregistrée dans le système Intégration-CLSC et sera facilement récupérable si le client à besoin de
poursuivre sa demande d’information.
 Communication avec des spécialistes
Lorsque l’infirmière le désire, elle peut communiquer « en ligne » avec un spécialiste (ex : pédiatre, pharmacien, diététiste, etc.)
afin de l’aider dans sa demande d’information avec le client. L’infirmière doit alors rédiger une « demande d’information –
spécialiste ».
Le spécialiste peut alors lire la communication qu’il y a eu entre le client et l’infirmière et la « demande d’information –
spécialiste » que l’infirmière lui adresse. Le spécialiste émet alors sa recommandation et elle est disponible pour l’infirmière.
L’infirmière peut alors vulgariser au client la recommandation du spécialiste. Cette recommandation sera aussi conservée dans
le système I-CLSC à l’intérieur de la demande d’information.
 Consultation de la bibliothèque virtuelle
Le client accède à partir du portail Web au module « Bibliothèque virtuelle ».
La consultation de cette bibliothèque virtuelle est possible grâce a un outil de recherche. Cet outil de recherche permet au client
d’effectuer sa recherche par titre, thème, auteur, année de publication, maison d’édition et numéro de demande d’information.
Le client peut aussi préciser s’il s’agit d’une recherche de vidéos, livres, articles, recherches, conférences, etc.
Lorsque le client a d’abord consulté une infirmière en ligne et qu’elle lui a donné une référence particulière pour sa
problématique, l’usager peut effectuer sa recherche par numéro de demande d’information et le système lui indique
automatiquement les liens pour les références suggérées.
La bibliothécaire effectue la mise à jour de la bibliothèque virtuelle.
 Participation à une conférence virtuelle
Une liste des conférences à venir avec les thèmes, le nom des conférenciers, les dates, les heures et le nombre de places
disponibles est accessible dans le portail Web à partir du module « Conférence virtuelle ». Les sujets sont rendus disponible
lorsque le spécialiste complète une fiche d’inscription de conférence.
Le client consulte les diverses conférences à venir et peut s’inscrire à l’une ou l’autre des conférences. Pour se faire, le client
doit s’authentifier.
Le client soumet sa demande d’inscription et aura au même moment la confirmation ou encore le refus d’inscription. Si la
demande est acceptée il aura un numéro de présence attribué.
Avant le début de la conférence, le client doit enregistrer sa présence avec l’aide de son numéro de présence.
Le client peut alors consulter la conférence en direct.
 Authentification des clients
Lorsque le client désire accéder au portail Info-Web-Santé, il doit s’être inscrit au préalable.
113
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Lorsque le client accède pour la première fois à l’application et qu’il désire faire appel à l’un de ses services il doit créer une
fiche client. L’inscription se fait à partir du numéro d’assurance maladie et de sa date d’expiration.
Lors de ce premier accès, le client reçoit un code d’utilisateur et doit choisir un mot de passe.
8.4. Recueil des besoins opérationnels
 Sécurité
Lors de sa connexion, chaque infirmière, spécialiste et conférencier doivent être reconnu par le système par un code d’utilisateur
et un mot de passe.
Le client connecté via Internet doit également être identifié par son code d’utilisateur ainsi qu’un mot de passe.
Un administrateur système est responsable de définir les profils des utilisateurs.
 Volume de données
La solution proposée décrit 3 types de données : soient les données du forum, les divers documents de la bibliothèque et les
documents vidéos.
8.4.1. Évaluation du volume de données pour les forums

POIDS
CONNEXION AU POIDS FICHIER TAILLE IMAGES ENCODEUR
FORMAT VIDEO DEBIT FICHIER
SITE (5 MINUTES) IMAGE PAR SEC. VIDEO
1 HR.

Sorenson
QuickTime 28.8 kbps 2.4 kbps 704 Ko 160x120 5 ips 8.44 Mo
MPEG-4

Sorenson
56 kbps 4.6 kbps 1.3 Mo 192x144 7.5 ips 16.17 Mo
MPEG-4

Sorenson
Haute vitesse 23.5 kbps 16.7 Mo 240x180 15 ips 82.62 Mo
MPEG-4
Nous avons arrêté notre choix sur trois qualités de diffusion vidéo avec l’encodeur vidéo MPEG-4 Sorenson. L’estimation du volume
de données vidéos peut seulement se faire par des hypothèses et au moyen du calcul de la règle de trois car le nombre de documents
vidéos, ainsi que le nombre de minutes de chaque vidéo, n’est pas encore connu.
Un exemple de calcul avec l’aide des valeurs de référence du tableau ci haut :
Ficher pour modem 28.8 Kbps de 15 minutes aurait une taille de : 2.1 Mo.
Donc, si on pose comme hypothèse que le serveur vidéo comportera 200 documents de 5 minutes, 100 documents de 15 minutes, et
50 documents de 1 heure, dans la première année d’utilisation du service, nous aurions besoin de près 15 Téraoctets d’espace disque.
8.4.2. Évaluation du volume de donnés pour les forums :
NOMBRE DE
SUJETS MESSAGES MESSAGES PRIVES ATTACHEMENTS GROSSEUR BD MYSQL
MEMBRES
5800 40000 662000 70000 8000 940 Mo
Ces données sont un exemple du fournisseur du logiciel Vbulletin, Jelsoft Enterprises Limited. Étant donné que chaque e-
communauté est différent, la taille peut varier. Ce que le fournisseur Jelsoft donne comme moyenne, dans les implantations qu’ils
ont vues, est à peu près 140Mo pour 100 000 messages.
8.4.3. Évaluation du volume de données pour la bibliothèque :
L’estimation du volume de données/documents de la bibliothèque peut seulement se faire par des hypothèses et par le calcul de la
règle de trois car le nombre de documents bibliographiques ainsi que la taille de chaque document n’est pas connue à ce moment-
ci. Pour des aspects de contrôle de documents et de standards de présentation, le choix pour la diffusion des documents sera le format
PDF.
Donc, si on pose comme hypothèse que le serveur de bibliothèque aura 500 documents ayant une taille moyenne de 500Ko, la
première année d’utilisation du service, nous aurions besoin de près 250 Mégaoctets d’espace disque.
9. Capture initiale des besoins
Dans ce présent chapitre, nous poserons les bases de la capture des besoins du système. Cette première étape de la conception permet
de déterminer les besoins fonctionnels du système dans le système plus global du CLSC Côte-des-Neiges. Plus précisément, elle
permet un premier recueil des besoins fonctionnels et opérationnels du système et la modélisation du contexte du système Info-Web-
Santé.
10. Acteurs du système
 Client
Le client peut consulter et interagir avec une infirmière en ligne, regarder de la documentation dans la bibliothèque virtuelle et
s’inscrire à des conférences en ligne.
 Infirmière
L’infirmière peut interagir avec un client, effectuer des recherches et proposer au client des documents dans la bibliothèque
virtuelle et consulter des spécialistes en ligne.
 Spécialiste

114
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le spécialiste répond à la demande d’information de l’infirmière en prenant connaissance de l’échange qu’il y a eu entre cette
dernière et le client. Il effectue des conférences virtuelles sur des sujets précis et inscrit les conférences à venir en ce qui le
concerne.
11. Système d’information sur la clientèle I-CLSC
Le système transmet les informations sociodémographiques d’un client lorsqu’il a un dossier ouvert au CLSC afin qu’elles soient
validées par ce dernier. Les demandes d’information sont conservées dans le système I-CLSC.
 Bibliothécaire
La bibliothécaire met à jour la bibliothèque virtuelle.
 Administrateur système
L’administrateur gère la sécurité, les profils des utilisateurs et les mots de passe.
11.1. Messages
 Le système Info-Santé-Web émet :
Au client : Les réponses pour les demandes d’informations, les documents demandés, les confirmations ou les refus d’inscription
aux conférences et la visualisation des conférenciers.
À l’infirmière : Les demandes d’informations des clients, les réponses des spécialistes, les liens pour la documentation pertinente
à proposer aux clients.
Au spécialiste : Les demandes d’informations de l’infirmière.
Au système d’information I-CLSC : Les demandes de recherches dans la banque de données, les demandes d’informations à
conserver.
 Le système Info-Santé-Web reçoit :
Du client : Les demandes d’informations, les recherches dans la bibliothèque virtuelle et les demandes d’inscriptions aux
conférences virtuelles du client.
De l’infirmière : Les réponses aux demandes d’information des clients, les demandes d’information aux spécialistes et les
recherches dans la bibliothèque virtuelle.
Du spécialiste : Les réponses aux demandes d’informations des infirmières.
De la bibliothécaire : Les mises à jour de la bibliothèque virtuelle.
De l’administrateur réseau : Les créations et les modifications aux profils des utilisateurs.
Du système d’information I-CLSC : La transmission d’information suite à la recherche dans la banque de données.
Les messages émis et reçus par chaque acteur
 Client
Le client émet sa demande d’information à l’infirmière, demande une recherche dans la bibliothèque et s’inscrit et assiste à une
conférence.
Le client reçoit la réponse de l’infirmière concernant sa demande d’information, la documentation réquisitionnée et la
conférence à laquelle il s’est inscrit.
 Infirmière
L’infirmière émet la réponse au client en ce qui attrait à sa demande d’information, interroge le spécialiste au sujet d’une
demande d’information et demande une recherche dans la bibliothèque.
L’infirmière reçoit la demande d’information du client, la réponse du spécialiste à ses questions et la documentation
réquisitionnée.
 Spécialiste
Le spécialiste émet la réponse à l’infirmière à ce qui attrait à sa demande, inscrit une conférence dans le système et fait une
conférence aux clients.
Le spécialiste reçoit l’interrogation de l’infirmière au sujet d’une demande.
 Bibliothécaire
Le bibliothécaire émet une mise à jour de la documentation en ligne en effectuant des ajouts, des mises à jour et des retraits.
 Administrateur système
L’administrateur système émet des créations et des modifications des profils d’accès consentis aux utilisateurs.
 Système d’information Intégration-CLSC
Le système d’information I-CLSC émet la transmission d’information réquisitionnée par Info-Web-Santé.
Le système d’information I-CLSC reçoit des demandes de recherche d’Info-Web-Santé et les demandes d’information qui
devant être conservées.

TRAVAIL À FAIRE :
Élaborer un plan de qualité logicielle.

Élaborer un plan de tests avec les cas de tests.

Merci de vous inspirer et de vous conformer au cahier des charges et aux normes ISO9001, 9002, 9003 et 9004.

Bonne chance!

115
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Annexe E : Le cas du Système de Réservation de Voyage Campus (SyRVoC)

1. Présentation de l’entreprise et de l’application


Le rôle de Voyages Campus/Travel CUTS est simple. Cette agence est l'experte en voyage étudiant, jeunesse et à petits
budgets. Ses conseillers en voyages sont passés là où vous allez et savent comment voyager avec un minimum de ressources
tout en jouissant au maximum d'un voyage. Et ils sont très fiers d'appartenir à une compagnie qui aide les gens à faire de
leurs rêves de voyage une réalité depuis plus de 30 ans.
2. Aperçu historique
Voyage Campus est dans le portrait depuis plus de 30 ans. Le premier bureau de la compagnie qui allait un jour devenir ce
qu'est aujourd'hui Voyages Campus/Travel CUTS ouvrit ses portes sur le campus de l'Université de Toronto en 1969.
Depuis le commencement, elle est la propriété d'organismes étudiants, d'abord de l'Association of Ontario Student Councils
(AOSC) et puis, en 1981, de la Fédération canadienne des étudiantes et étudiants-services (FCEE-S).
Leur statut d'entreprise étudiante contribue à assurer que les intérêts étudiants ont priorité à la fois dans le cadre des activités
quotidiennes et lors de la planification à long terme. Une portion de leurs profits est remise à la FCEE. Cette dernière utilise
ces sommes pour financer les programmes et services qui viennent en aide à la population étudiante du pays. Cette aide
permet aux étudiants d'avoir accès à diverses ressources, du régime d'assurance pour soins médicaux adapté sur mesure au
travail d'intervention fait au nom des intérêts étudiants.
En plus de leurs relations étroites avec la FCEE, elle est aussi membre de l'organisme International Student Travel
Confederation (ISTC). Leur appartenance à l'ISTC permet à leur clientèle d'avoir accès à toutes sortes de programmes
branchés de travail et d'études à l'étranger, à des billets à tarif réduit pour étudiants et à un réseau d'aide international pour
les voyageurs en détresse.
Depuis leurs modestes débuts en 1969, elle agrandi et aujourd’hui elle est experte canadien en voyage étudiant et pour
petits budgets, avec plus de 70 agences détentrices de permis situées près des ou sur les campus universitaires au Canada,
aux Etats-Unis et au Royaume-Uni.
3. Activités principales
Voyage Campus offre de nombreux choix de vols, d'hébergement, de circuits et de passes de train …
3.1. Le transport
Chaque année, Voyages Campus aide des milliers d'étudiants et de voyageurs à petit budget à explorer le monde. Elle
offre deux types de transports :
1- Au sol
Autobus - Location de voiture – Train
2- Dans les aires
Avions – plusieurs compagnies aériennes telles (Air Canada, US Air, Continental, etc.)
3.2. L’hébergement
Voyages Campus propose quelque chose de bien et de pas cher, que ce soit dans une auberge ou un petit hôtel bon
marché.
3.3. Assurance
Trois plans disponibles :
Le plan A couvre dans le cas de l'annulation ou de l'interruption de votre voyage.
Le plan B offre la même couverture de soins médicaux, couverture individuelle contre les accidents et couverture
en cas d'annulation de voyage que le plan A, mais la perte de bagages et d'effets personnels n'est pas couverte.
Le plan C couvre en cas d'annulation de voyage y compris interruption de voyage et séjour écourté.
De plus, chaque plan vous donne accès à un service d'assistance en cas d'urgence, disponible 24 heures sur 24 à travers
le monde.
4. Quelques données chiffrées
Le chiffre d'affaire de l’agence est d'environ 25 Millions. Le nombre d'employé est 42. L'an dernier seulement, Voyage
Campus a envoyé plus de 400 000 Canadiens en voyage au Canada, aux États-Unis et à travers le monde.
L’agence conçoit et favorise l'essor de produits exclusifs destinés à la population étudiante. Elle est la seule agence de
voyage au pays à offrir des tarifs Classe étudiante à l'intérieur du Canada et vers l'étranger, le Programme Vacances --
Travail (PVT, ou "SWAP") et la Carte d'étudiant internationale (ISIC), pour ne nommer que quelques-unes de nos
spécialités.
Elle offre leurs produits hautement flexibles et de grande qualité au tarif le plus bas possible. Elle négocie avec les
compagnies aériennes et autres fournisseurs pour des rabais et tarifs spéciaux étudiants. Ensuite, elle fait profiter de ses
clients de ces économies.

116
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
L’agence a présentement 65 bureaux au Canada et ça continue! Elle a 3 bureaux à Londres, au Royaume-Uni et deux postes
isolés en Californie : un à San Francisco et un autre à Stanford University.
5. Structure organisationnelle de l’Entreprise/Organisation

DIRECTEUR

ASSIST
DIRECTEUR DE ADMINIS
L'AGENCE

COMPATA DIR
DIR R-H
BLE MARKET

CONSEILLERES AGENTS
EN VENTE DE
VOYAGES

5.1. Les taches :


Responsabilités générales du directeur
Le Directeur est le principal dirigeant des opérations de la compagnie dans son ensemble, le directeur d'agence est
responsable de plusieurs tâches variées. Chaque directeur est soigneusement choisi selon l'étendue des aptitudes qu'il
est en mesure de contribuer durant l'exercice de ses fonctions et selon sa capacité de voir à ce que TOUS les aspects
de gestion de l'agence seront menés efficacement.
Responsabilités du conseiller en vente
Le conseiller en ventes de voyages aide le voyageur à chaque étape du processus entier de préparation et d'achat des
éléments d'un voyage. Un conseiller fera appel à son savoir-faire en matière de destinations et de produits afin de tenir
compte des besoins particuliers du client et ainsi lui assurer la meilleure expérience possible.
Responsabilités d’agent de voyages
L’agent de voyages suit les politiques et procédures émises par l’entreprise, répond à la demande de voyages du client
dans un délai raisonnable et faire un suivi sur son dossier et l’informer de sa progression, s’il y a des délais d’attente
du au fournisseur de service. L’agent suit les directives émises par l’entreprise que ce soit par l’entremise du Directeur
Régional ou par la Directrice ou le Directeur de l’agence. L’agent se doit de bien représenter l’entreprise que ce soit à
l’intérieur où à l’extérieur de l’agence et lors de présentation de l’industrie.
Responsabilités du directeur de marketing
Assurer une gestion saine des produits exclusifs et orienter les efforts de promotion quant à ces programmes de façon à ce
qu'ils soient efficaces. Dans le cas des agences situées sur les campus, entretenir de bonnes relations avec l'association
étudiante de l'endroit, afin de promouvoir les circuits et forfaits spéciaux et de venir en aide aux efforts de promotion et de
publicité des agences. Lorsque la situation l'exige, embaucher des représentants et s'assurer qu'ils accomplissent
adéquatement leurs tâches.
Responsabilités du comptable
Établir des budgets pour l'agence, avec l'aide du directeur régional. Évaluer (sur une base continue) les performances
de l'agence vis-à-vis les prévisions budgétaires. S'assurer que tous les rapports et documents sont soumis tel que requis
(consulter la section sur les besoins du bureau). S'occuper des comptes payables et recevables dans des délais
raisonnables.
Responsabilités du directeur des ressources humaines
Avoir une quantité adéquate de personnel afin d'assurer les meilleurs niveaux de productivité possible. Évaluations
annuelles du rendement du personnel ayant lieu en temps opportun. S'assurer que les besoins en matière de formation
sont satisfaits en prévoyant et en favorisant entre autres une formation continue à la fois en milieu de travail et ailleurs.
Offrir conseils et support au personnel lorsque surviennent des situations problématiques reliées à leur milieu de travail et
à l'industrie du voyage. S'assurer que le personnel de l'agence travaille en équipe et maintenir les niveaux de motivation
nécessaires au bon fonctionnement de l'agence.
6. Présentation de l’application
Voyage Campus souhaite se doter d’un système informatique performant afin de :
117
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
 Permettre à leur clientèle de faire leur réservation sans avoir recours au personnel de l’entreprise ;
 Avoir la tarification des destinations désirées ;
 Via-Rails qui couvre les destinations de certaines villes canadiennes, et Amtrak qui couvre les États-Unis pour un
voyage d’affaires et autres, sont deux compagnies qui leur fournissent les billets avec des tarifs compétitifs pour les
étudiants inscrits à temps plein, personnes âgées de moins de 26 ans sans être aux études et les enseignants
(professeurs). L’implantation de ce système est valable seulement pour les clients qui désirent voyager au Canada
et/ ou aux États-Unis par exemple pour une destination comme Toronto et / ou New York en partance de Montréal.
 Offrir aux clients la possibilité de se réserver un billet via une connexion Internet même après les heures d’ouvertures
de l’agence ;
 La durée de vie du nouveau système, appelé SyRVoC (Système de Réservation de Voyage Campus), est estimée à
5 ans.
Les technologies qui seront utilisé pour réaliser ce projet sont :
 UML (Rational Rose),
 Les architectures 3-tiers,
 Internet (Serveur supportant PHP),
 Programmation en HTML (MS Frontpage),
 Java-script (NotePad),
 SGBD (SQL sous Oracle, PhpMyAdmin),
 PHP (Zend Development Environment).
7. Problématique
Quoi de plus banal pour une agence de voyages que de vendre à des clients un aller simple ou aller-retour pour une
destination comme Toronto ou Québec en partance de Montréal par voies ferroviaires. Leur marge de profit entre vendre
un forfait tout inclus pour la République Dominicaine et un voyage d’affaires aux Etats-Unis est plus intéressante dans le
premier cas que dans le second, puisqu’il leur est possible d’ajouter des extras donc plus de profits. Le temps de services
étant le même pour les deux types de clientèle, ils désireraient passer plus de temps à desservir la clientèle la plus sujette à
rapporter davantage de bénéfices.
8. Objectifs
Augmenter la disponibilité des employés et mieux servir la clientèle cible.
9. Principales solutions proposées
Traiter les transactions de moindre importance sur les voyages ferroviaires par l’implantation d’une plate-forme Internet
(commerce électronique), implanter un système interactif c’est à une base de données interne permettant à l’utilisateur du
système (client) d’avoir la confirmation de réservation, la description souhaitée et le tarif du billet.
10. Délimitation dans le temps et dans l’espace
La durée de vie du nouveau système, appelé SyRVoC (Système de Réservation de Voyage Campus), est estimée à 5 ans.
11. Importance de votre application
Augmenter la disponibilité des employés et mieux servir la clientèle cible. Accroissement des profits et possibilité d’offrir de
meilleurs prix. Utilisé pour décrire un processus d’achat, de vente ou d’échange de produits, de services, de paiements et
d’informations via un réseau d’ordinateurs incluant entre autres l’Internet. Il permet à l’entreprise de réaliser des activités
commerciales avec ses partenaires.
12. Recueil des besoins fonctionnels
Traitement des réservations
Les réservations sont faites par les clients eux-mêmes. Pendant qu’ils sont sur le réseau Internet de l’agence, ils pourront
accéder à SysVoC. Une fois que le client aura rentré les informations nécessaires, il aura un estimé des coûts selon ses
destinations, ainsi qu’une confirmation de sa réservation. Avec son numéro de réservation et d’un mot de passe le client
pourra consulter son dossier pour modifier ou annuler une réservation.
Une réservation en cours est donc maintenue à jour par le système. Les agents et les conseillers en ventes pourront
apporter des modifications, des annulations des réservations déjà fait par le client sur le système SysVoC et s’assurer
des fermetures du dossier.
Puisque l’application est prévue pour répondre au besoin du client de réserver à distance via le e-commerce. Donc, quand
la réservation doit être faite par l’agent ou un conseiller, ils vont procéder comme ils faisaient avant l’application par leur
système disponible hors connexion. Mais notre application peut en tenir compte et prévoir cet usage par l’agent pour
usage futur, selon le besoin des gestionnaires.
Administration
Une fois qu’une réservation, est modifiée, annulée ou confirmée dans le système, les données sont transmises au logiciel
de comptabilité pour facturation et la tenue des livres. Le comptable valide les informations, sort les factures en tenant
compte des paiements faites en différé lors des réservations, et prépare des reçus.
Le système envoie aussi un signal à un progiciel de comptabilité qui se charge d’informer les différents intervenants du
traitement en cours, par un message dédié à leur boîte de réception ou directement sur l’imprimante réservée à cet effet.

118
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Une fois les agents informés, ils peuvent préparés les billets, pour envoyer directement aux clients quand c’est déjà payé
en totalité par différé. Sinon, ils devront passer les chercher à l’agence et effectuer le paiement final sur place.
Suivi des réservations
La plupart des acteurs peuvent accéder au système pour consultation et analyse. Grâce au logiciel de cueillette de données
automatique, les données sont recueillies et stockées pour utilisation immédiate ou ultérieure. Cette base de données
permettra une meilleure gestion, tant au niveau Marketing que planification financière. Une fois le dernier paiement
effectué et que la réservation définitivement confirmée, un agent ou un conseiller doit rentrer dans le système pour la
fermeture du dossier.
13. Recueil des besoins opérationnels
13.1. Sécurité
Lors de sa connexion au système, chaque employé doit être reconnu du système, par un nom, un Logon ID, un mot de
passe et la fonction qu’il occupe dans l’agence. L’administrateur du système est chargé de définir les profils des
utilisateurs.
Le client connecté Via Internet doit aussi être identifié par un numéro ID qui est le numéro de sa réservation et un mot
de passe pour pouvoir apporter les modifications à la réservation initiale.
13.2. Le traitement des données
Chaque réservation doit être traitée en temps réel, ainsi que les modifications, les annulations et les confirmations.
La liste des réservations confirmées et en cours peuvent être sorties sur demande par le comptable. Il en est de même
pour les requêtes sur la base de données automatique fait par les différents acteurs humains.

14. Capture initiale des besoins


14.1. Acteurs du système
14.1.1. Humains
Client, le comptable, les agents de voyages, les conseillers en voyage, le directeur générale, responsable du Marketing,
responsable des ressources humaines, département de services et administrateur système.
Client
Le client entre les informations requises pour sa réservation sur le site Web à travers un formulaire électronique, le
système lui alloue un numéro de réservation.
Comptable
Le comptable fait le point régulièrement sur les commandes, valide les factures établies en lignes aux clients et s’assure
du recouvrement des factures et les reçus. En fin de chaque journée, il peut aussi sortir une liste de toutes les ventes
effectuées et des paiements reçus.
Agent de voyages
Il peut modifier ou annuler une réservation. Avant de remettre ou d’acheminer les billets aux clients, va consulter les
listes de réservations, procède à la vérification et comparaison avec la facture. Il peut, une fois le paiement total
confirmé, rentrer une confirmation pour la fermeture du dossier.
Conseiller en vente
La consultation des banques de données de réservations du système, pour mieux conseiller les clients quand au choix
les plus fréquents, les plus appréciés, etc.
Le directeur général
Pour consultation de données qui serviront à l’évaluation et la gestion administrative du système en terme de rentabilité
et d’investissement.
Responsable Marketing :
Consultation de la banque pour fin statistique pouvant aider à la création de nouvelle clientèle cible, à l’amélioration
des forfaits et les campagnes publicitaires sur le site web.
Responsable des ressources humaines
Utilisation du système pour fin de formation des nouveaux employés utilisateurs du système.
Département de services :
Traite la commande et s’assure de la faire parvenir au client dans les délais prévus.
Administrateur du système :
L’administrateur du système gère les profits des utilisateurs et les mots de passe. Il crée le profil du client et son panier
ainsi que son compte on line. Il s’occupe de la mise à jour du système et la gestion de la banque de données.
14.1.2. Non humains
Progiciel comptable, logiciel de cueillette de données et progiciel de messagerie.
Progiciel de comptabilité
Le progiciel de la comptabilité récupère les données de facturation par numéro de réservation. Il assure le lien entre
les compagnies ferroviaires; la réservation et l’achat de billet de train suivant la convention entre l’agence et la
compagnie.
Logiciel de cueillette de données
119
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
La création d’une banque de données à mesure que les réservations rentrent pour fin de statistique et de gestions. Sur
l’âge, sexe, ville, destination, forfaits, durée des voyages, etc.
Progiciel de messagerie
Il récupère un signal suite à une réservation, une modification ou une annulation et se charge d’acheminer le message
à la boîte de réception des agents de la comptabilité ou directement sur une imprimante réservée uniquement aux
réservations pour permettre la suivie des réservations.
15. Messages
15.1. Le système émet
 La confirmation de la commande de réservation;
 La description textuelle du trajet;
 Les données transmises au progiciel comptable pour la préparation de la facture et du reçu de paiement;
 Les données de confirmations transmises de modification ou d’annulation par le client au progiciel de messagerie
pour les agents et la comptabilité;
 Acheminement de la commande;
 Les statistiques pour le directeur générale, le responsable du marketing et des conseillers en vente.
15.2. Le système reçoit
 Le formulaire de réservation du client;
 La création, l’annulation, modification de réservation par le client;
 Modification ou annulation de réservation par les agents de voyages;
 La fermeture du dossier par l’agent lors d’un règlement complet de facture;
 Interrogation de la banque de données par le directeur, le responsable Marketing et conseiller en vente;
 Les données reçues du SGBD principale, lors de changement de forfaits de prix et des modifications aux informations
disponibles dans le système.
15.3. Description des messages
Factures : À la fin de chaque réservation, une estimées des coûts et des acomptes versés est envoyée au progiciel
comptable avec numéro de réservation pour la préparation des factures. Un message est aussi envoyé au progiciel
comptable, lors du dernier paiement, par la confirmation d’un agent, pour aider le comptable dans la suivie des
comptes.
Création de banque : Transmission automatique dans la banque lors des requêtes des données aux fins de statistiques
pour les utilisateurs autorisés. Exemple : liste des destinations choisies, les durées des séjours, les forfaits les plus en
demande, les endroits les plus visités, etc.
Condition de réservation : Transmission systématiquement par messagerie, suite à une réservation, modification,
annulation par client, aux agents et comptables. Et seulement au comptable quand modification et annulation ne fait
pas agent.

TRAVAIL À FAIRE :
Élaborer un plan de qualité logicielle.

Élaborer un plan de tests avec les cas de tests.

Merci de vous inspirer et de vous conformer au cahier des charges et aux normes ISO9001, 9002, 9003 et 9004.

Bonne chance!

120
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Annexes II : Plans qualité et de tests
Annexe A : Plan qualité logiciel
Plan d'Assurance Qualité Logicielle

Fournisseur/développeur du logiciel : xxxxxxxxx

Plan Qualité du logiciel xxxxxxxxxx

I – But, domaine d’application et responsabilités

Ce document a pour but d’exposer les règles et actions à mettre en œuvre pour la réalisation des logiciels
demandés par le contrat de réalisation avec les qualités souhaitées.
Les logiciels concernés sont donc ceux issus de la réalisation des tâches suivantes :
- xxxxxxx
- xxxxxxxx
Les logiciels standards TOMSTOCK et TOMPRO ont déjà été acquis par FPI et devront s’intégrer facilement avec le
progiciel intégré de gestion des projets, portefeuille et taxe.
Les critères d’évaluation du logiciel repris dans le cahier des charges du projet

II – Documents applicables et document de référence


Les documents suivants sont pris en compte dans le cadre du plan qualité pour le PGI

Description du document Exigence

Contrat de réalisation qualité imposé

Dossier d’analyse fonctionnelle imposé

Contrat imposé

Offre définitive imposé

Manuel utilisateur imposé

Documentation des codes sources imposé

Manuel d’administrateur imposé

Structure de la base des données et dictionnaire des données imposé

Manuel d’installation et de paramétrage du logiciel imposé

Manuel de formation sur le langage de programmation recommandé

Documentation des librairies des modules standards et leurs imposé


paramètres d’appel

121
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
III – Terminologie
Les concepts, termes et abréviations utilisés dans le document sont repris ci-dessous; la liste n’étant pas
exhaustive il faudra se référer aux termes spécifiques qui seront utilisés documents cités plus haut.
- BDDT : Base de Données de Données Technique Générale.
- RDB : mécanisme de sauvegarde de donnée
- SGBD : système de gestion de base de données (relationnelle)
- BDDT : Base de Données de Données Techniques
- SNCC : Système Numérique de Contrôle Commande
- S.I. : système d’information
- RUP : Rational Unified Process
- UML : Unified modelisation language : outil de modélisation du system d’information
- PQL : plan qualité logiciel
- DCG : dossier de conception générale
- DCD : dossier de conception détaillée

IV – Démarche de développement
4.1. Maîtrise d'ouvrage
4.1.1. MOA La maîtrise d'ouvrage est l'équipe de Développement à qui l’on a responsabilisé le projet.
4.1.2. MOAd
La maîtrise d'ouvrage déléguée est représentée par xxxxxxxxx, de l'équipe de Développement . Son rôle est de don
ner les objectifs de travail et de valider les résultats obtenus.

4.2. Maîtrise d'œuvre


4.2.1. MOE La maîtrise d'oeuvre est le titre du diplôme et l’école et sont représentant : xxxxxxxxx.
4.2.2. MOEd
La maîtrise d'oeuvre déléguée est l'équipe de développement : xxxxxxxx et xxxxxxx. Leur rôle est de proposer une
solution logicielle permettant au logiciel « xxxxxxx » d'évoluer pour satisfaire les nouveaux besoins du MOA et pal
ier aux problèmes de la version précédente, ainsi que de s’assurer de la bonne conduite du projet.
Pour cela, ils doivent faire en sorte que :
◊ ➢ Tous les documents demandés soient fournis,
◊ ➢ Le planning soit observé et réajusté d’un commun accord si besoin,
◊ ➢ Les normes de qualité soient définies et respectées,
◊ ➢ La validation des documents soit conforme au PAQL,
◊ ➢ La validation du code produit soit conforme au PAQL.

4.3.Chef de projet
Le chef de projet sera xxxxxxxxxx pour la période de xxxxxxxx à xxxxxxxx, puis xxxxxxxxxd pour la période de x
xxxxxxx à xxxxxxxxx.
Le chef de projet est responsable :
◊ ✔ de la planification du projet,
◊ ✔ du contrôle de l'avancement du projet,
◊ ✔ de la mobilisation des moyens nécessaires de la coordination des travaux de chacun.

4.4. Responsable qualité


Le responsable qualité sera xxxxxxxxxxxx pour la période de xxxxxxx à xxxxxxxxxxx, puis xxxxxxxxx pour la pér
iode de xxxxxxxxxx à xxxxxxxxxxx. Le responsable qualité a pour mission de : ✔
définir les règles de retour arrière et les procédures de modification,
◊ ✔ veiller à la diffusion et au respect des règles particulières au projet,
◊ ✔ gérer l'évolution du PAQL.
122
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le fournisseur du logiciel doit faire référence à la méthode de conduite de projet utilisé en décrivant les phases, les
étapes avec, pour chacune d'elles, les documents nécessaires pour la commencer, les tâches et activités spécifiques,
les documents produits en sortie, les règles de vérification, de validation et de décision permettant de passer à
l'étape suivante. Elle est relative au cycle de vie de la réalisation des logiciels. Le modèle proposé pour la
démarche est repris dans le tableau de la page suivante.

Critère de passage
Étape Objets Produits en entrée Produit en sortie
à l’étape suivante

- Document de
conception
générale
- Identification
des
fonctionnalités
- Architecture
- Contrat de - Interfaces
élaboration de Revue de projet 
Conception réalisation - Données
l’architecture de la - Analyse - Amorce de plan adéquation aux
générale
mission fonctionnelle de test mission spécifications
- PQL - Amorce du
manuel
d’utilisateur
- Amorce du
cahier de
recette
- planification de
l’étape suivante
- Document de
conception
détails sur les détaillée
Conception algorithmes et - Pal de test - Revue de
- DCG
détaillée structures de - Manuel projet
- PQL
données utilisateur - lecture croisées
provisoire
- Cahier de
recette
Traduction du - Lecture
résultat de la croisées
Codage et
conception détaillée - - Listes - Pas d’erreur en
tests DCD
programmes compilation
unitaires en programmes - PQL
- binaires - pas d’erreur
sur test
procédural
assemblage - Binaire mission
progressif des - Binaires
- pgs. Listes au - Test OK selon
Intégration - Plan de test
différents point le plan de tests
mission
programmes - Jeux de test - qualités OK
- PQL
composant la - Résultats

123
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
mission - Manuel
d’intégration des utilisateur
logiciels définitif
- cahier de
recette définitif
Assemblage des
missions et - Résultats OK
vérification de - Plan de validation
- Observateur selon le plan de
Validation ou cahier de
l’utilité des logiciels - résultats de la validation
recette global
fournis validation - Exploitation
- PQL
étape suivante

V- Organisation

5.1. Motivation du choix


Chaque attente du client peut être atteinte indépendamment des autres. L'utilisation d'un cycle de
vie permettant de développer chacun des modules de bout en bout séparément est donc appropriée.
Le produit final sera donc livré par lots successifs. Le cycle de vie choisi est un cycle xxxxxxxxxxxxx

5.2. Description des étapes du cycle de vie


◊ Analyse des besoins : Cette étape permet de prendre en compte les besoins du client, choisir le cycle de vie à
adopter, définir le planning et préparer l'acquisition des outils de programmation.
◊ Spécifications externes : Cette étape permet de définir précisément l'ensemble des fonctionnalités, d'étudier l'i
nterface homme-machine du système, de se former aux outils utilisés et de préparer les tests système.
◊ Conception : Cette étape permet de définir l'architecture interne du logiciel, d'acquérir et d'installer les outils
de programmation et de préparer les tests d'intégration.
◊ Codage : Cette étape regroupe la phase de conception détaillée et de codage. Elle permet de détailler précisém
ent la conception globale par module afin de pouvoir les développer et préparer les tests unitaires. Le codage
permet de traduire la conception détaillée en un programme.
◊ Tests : Cette étape permet, à l'aide des plans de tests, de tester le logiciel développé dans l'ordre suivant : tests
d'intégration, tests système, tests d'acceptation. L'observation et la comparaison avec les résultats attendus per
mettront de modifier si nécessaire le logiciel.
◊ Livraison : Livraison d'une version logiciel ou du logiciel final.

5.3. Les acteurs et leurs rôles dans le projet sont repris ci-dessous
Chef de mission et chef de projet : xxxxxxxxxxxxxx
Analyste qualité : xxxxxxxxxxxxxx
Equipe de réalisation : xxxxxxxxxxxxxxxx
Client (toutes les directions-métiers)
Consultants recrutes pour accompagner le le client : s’il y a lieu
Responsable technique et
Responsable de coordination : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

124
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
5.4. Phase du cycle de vie
Voici pour chaque étape du cycle de vie « en V » les documents requis et produits, ainsi que les conditions de passag
e d’une étape à une autre.

Activités Documents Condition


Requis Produits
Analyse des Étude de l'existant, définition d ● CdC Validation du
besoins es besoins, analyse des risques ● PDL Cdc par le
et de la faisabilité, préparation ● PAQL MOAd
des tests d'acceptation, établis ● Plan de tests
sement des procédures et plans d'acceptation
qualité, choix du CV, planificati
on, estimation des ressource
Spécification Étude détaillée du logiciel à ● CdC ● DES Validation des
s externe réaliser, préparation des tests ● Manuel documents
système, mise à jour des utilisateur par le MOAd
documents établis dans l'étape ● Plan de tests
précédente système
Conception Définition de l’architecture inte ● DSE ● DCG Validation des
rne du logiciel, définition des c ● DCD documents
omposants, préparation des tes ● Plan de tests par le MOAd
ts d'intégration et des tests uni d'intégration
taires, mise à jour des docume et de tests
nts établis dans l'étape précéd système
ente
Codage Codage, documentation des co ● DCG
mposants, mise à jour des docu ● DCD
ments établis dans l'étape préc
édente
Tests Réalisation des jeux de tests, co ● Ensemble ● Rapports de ● Jeux de tests
rrection du code si besoin, mise des plans de tests concluant
à jour des documents établis d tests
ans l'étape précédent
Livraison Réalisation des tests d'acceptat ● Jeux de
ion par le client tests
d'acceptatio
n

VI – Documentation

A l'issue de ce projet, plusieurs documents auront été produits. Certains devront être livrés avec le produit fini,
certains seront disponibles si le client les souhaite et certains ne serviront qu'à l'équipe de développement. Le tableau
suivant précise pour chaque document son statut.

125
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
● Description des différents statuts :
– Livrable : Doit être fournit au client
– Consultable : Peut être consulté par le client
– Privé : Destiné à l'équipe du projet uniquement

Les documents importants et leur présentation (structure) sont repris ci-dessous.

1. Structure de la documentation
Pour chaque mission il faudra ressortir:

- Les spécifications détaillées ou manuel d’utilisateur provisoire


- Les documents de conception générale et détaillée
- Le manuel utilisateur définitif
De manière globale les deux manuels suivants ne doivent pas manquer:

- Le manuel d’opérateur (administrateur)


- Le cahier de recette globale
Le support de cette documentation peut être:

- Le traitement de textes : manuels utilisateur et cahier de recette


- Ou automatiquement (LDP, Graphe) : documents de conception

2. Plan type de ces documents


a) Manuels utilisateurs et opérateur
i. Objectifs
ii. Présentation du matériel
iii. Fonctionnement général
iv. Présentation générale des dialogues
1. Principe
2. Saisie
3. Corrections
4. Abandon
126
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
5. Validation
6. Enchaînement
7. Erreurs générales
v. Dialogue
vi. Démarrage
vii. Traitement des incidents
viii. Glossaire

b) Documents de conception
i. Objectifs
ii. Présentation des modules
iii. Description des modules (LDP)
iv. Organisation des modules (chemins d’appels…)

c) Cahier de recette (exemple)


i. Objectifs
ii. Protocole de recette
1. Condition de présentation
2. Condition de mise à disposition
3. Environnement des opérations
4. Conditions d’exécution des essais
5. Procédure d’analyse des anomalies et leur correction
6. Conditions d’acceptations
7. Conditions de suspension, d’ajournement et de reprise
iii. Suivi de recette
1. Exemplaire de fiche de test
2. Liste des jeux d’essais et fiches de tests préparées

VII – Gestion de la configuration

La configuration est l'ensemble des éléments suivants : code source exécutable, outils de développement et de test
utilisés, documents et données.

7.1. Outils de travail collaboratif

Voici les outils que nous utiliserons pour gérer le travail collaboratif :

➢ CVS (Concurrent Versions System)

Cet outil permet de partager le code source d'un logiciel et d'intégrer facilement les modifications de fichiers d’un
développeur avant de les mettre à disposition des autres utilisateurs.

Il permet également de disposer d'un historique de toutes les modifications et des différentes versions du projet.
Le retour à une version précédente en cas de problème est facilité.

➢ BullForge

Bull possède un site qui permet aux équipes de développement de collaborer efficacement grâce a des outils comme
les forums et les mailings list. Bullforge fournit aussi des outils de travail collaboratif comme CVS ou Subversion.

127
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
➢ Mailing list

L'inscription aux mailing list des projets associés est essentiel pour prendre en main les outils et être au courant des
nouvelles versions et des corrections d'erreurs.

7.2. Environnement technique

Le développement sera effectué sous environnement Linux (Debian). Le plugin pour Eclipse sera développé sur la
version 3.3 de l'IDE. La JDK 1.5 sera utilisée pour le développement JAVA.

VIII – Gestion des évolutions

8.1. Procédure de modification


Les modifications peuvent avoir deux origines :
➢ Détection d'une anomalie
➢ Demande d'évolution
Dans le cas d'une détection d'anomalie, il faut en trouver la source puis la corriger dans les plus bref délais.
Dans le cas d'une demande d'évolution du logiciel par le client, il faut dans un premier temps réaliser une étude de
faisabilité, pour ensuite modifier le logiciel en conséquence si cela s'avère réalisable dans les délais impartis.
Les membres du MOEd sont responsables de la mise en oeuvre de ces modifications.

8.2. Règles d’évolution des numéros de version


Documents et applications sont identifiés par un numéro de version, un numéro de révision et un numéro de corre
ction comme suit : « NuméroVersion.NuméroRévision.NuméroCorrection ».
Trois cas peuvent nécessiter un changement de version.
➢ Une nouvelle livraison de l'application ou du document :
✔ On incrémente le numéro de version. Les numéros de révision et de correction reviennent à zéro. ➢
Une évolution :
✔ On incrémente le numéro de révision. Le numéro de correction revient à zéro.
➢ Une correction d'anomalie(s) :
✔ On incrémente le numéro de correction

8.3. Règles d'évolution du statut Pour chaque document, un statut doit être mentionné. Celui­ci peut­être :
➢ Initial : Le document est en cours de rédaction, il n'est pas diffusable, même en interne.
➢ Diffusable : Le document est rédigé, il peut être diffusé en interne mais il n'a pas encore été validé.
➢ Final : Le document à été validé. Il peut être consulter ou livrer.

IX – Méthodes, outils, règles, normes

9.1. Méthodes
La méthodologie UML sera utilisée pour toutes les phases d'analyse de ce projet. Les tests seront préparés penda
nt les premières étapes du projet, à savoir :
➢ Analyse des besoins : Préparation des tests d'acceptation

128
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
➢ Spécifications externes : Préparation des tests systèmes
➢ Conception globale : Préparation des tests d'intégration
➢ Conception détaillée : Préparation des tests unitaires
Ces tests devront être préparés au fur et à mesure de l'avancement du projet. Ainsi, à chaque étape,
ils devront être répertoriés dans le document « PlanDeTests*.odt ».

9.2. Outils
Le tableau suivant récapitule les outils qui seront utilisés dans le cadre de ce projet.

9.3. Règles et normes à respecter


9.3.1. Règles de présentation Tous les documents liés à ce projet devront respecter un même modèle :
➢ page de garde
✔ Nom du projet

✔ Nom du document
✔ Date de dernière modification
✔ Numéro de version
✔ Auteur(s)
✔ Cartouche d'entête : Logo Bull, nom du document, logo du projet
➢ page suivantes

✔ Cartouche d'entête : Logo Bull, nom du document, logo du projet


✔ Numéro de page
✔ Nombre de pages

9.3.2. Règles de programmation


Le système sera développé en langage Java. Nous adopterons donc les règles qui s’y appliquent, notamment :
➢ En entête de classe
129
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
✔ Date de création de la classe
✔ Auteur
✔ Historique des modifications
➢ Pour chaque méthode
✔ Description succincte de la méthode

✔ Description des paramètres utilisés


✔ Description de la valeur de retour
➢ Convention de nommage
✔ Le nom d'une classe commence par une majuscule. Si ce nom est lui-même
composé de plusieurs noms, chacun d'entre eux commence par une majuscule. Les autres lettres sont en minusc
ules.
➔ Exemple :
• public class Composant{}
• public class TypeComposant{}
✔ Le nom d'une méthode ou d'une variable commence par une minuscule. Si ce nom est lui-même composé
de plusieurs noms, chacun d'entre eux commence par une majuscule. Les autres lettres sont en minuscules.
➔ Exemple :
• public void init(){}
• public void doPost{}
✔ Le nom des variables doit être significatif pour une meilleure compréhension du code.
Le respect de ces règles de programmation devra être vérifié à l'aide de CheckStyle (plugin Eclipse). Un mini
mum d'avertissements devra être présent. Aucun seuil n'est fixé car certaines erreurs de CheckStyle n'ont pas un
grand impact sur le style de programmation mais nécessite par contre un grand investissement en temps.
Il s'agira donc de réduire au maximum le nombre d'avertissements en perdant un minimum de temps.

9.3.3. Normes sur les comptes-rendus de réunions


Chaque audit donnera lieu à la rédaction d'un compte-rendu. Celui-ci se compose de la manière suivante : « nom
_date ».
✔ nom : nom de la réunion (audit1, audit2 ou audit3)

✔ jj : le numéro du jour sur 2 chiffres


✔ mois : le numéro du mois sur 2 chiffres
✔ aa : le numéro de l'année sur 2 chiffre
Par exemple, le compte-rendu de l'audit du 15 mars 2007 serait nommé : « audit1_150307 ».

130
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
9.3.4. Normes sur les documents livrables Chaque document possède un numéro de version de la forme x.y.
Tout incrément du premier indice (x) implique un changement notoire du document. Tout
incrément du second indice (y) implique une modification minime du document.

9.3.5. Normes sur les fiches de relecture


Chaque diffusion d'un document donne lieu à une relecture et au remplissage d'un fiche de relecture. Celle-ci se
compose de la manière suivante : «nomDocAssocié_Relecteur_Date».
✔ nomDocAssocié : Le nom du document abrégé associé à la fiche de relecture
✔ Relecteur : Le nom du relecteur
✔ Date : La date de création de la fiche
Par exemple, la fiche de relecture associée au Plan d'Assurance Qualité (PAQL) créer par xxxxxxxx le xx fxxxxxxx 2
017 sera nommée : « PAQL_Camilleri_06022007 ». Un modèle de fiche est fourni : « Modele_fiche_relecture » ai
nsi qu'une fiche explicative annexe : « PAQL_Fiche_relecture ».

X – Assurance et contrôle qualité (Exigences et évaluation de la qualité)

10.1. Facteurs
Les facteurs de qualité suivant ont été identifié comme important pour ce projet et devront être
validés :
➢ Maintenabilité : Aptitude du logiciel à pouvoir être corrigé facilement.
➢ Portabilité : Aptitude du logiciel à être transféré d'un matériel et/ou d'un environnement logiciel à
un autre.

10.2. Critères

Chaque facteur est lié à des critères précis. Parmi ceux-ci, un minimum de 4 critères par facteur devra
être assuré.

131
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
10.2.1. Motivation des choix
Les critères tracabilité, instrumentation, consistance et communicabilité ont été écartés. Seul les
critères les plus importants pour ce projet ont été conservés.

10.3. Évaluation

La partie suivante présente les mesures qui seront effectuées pour quantifier le respect de chaque crit
ère sélectionné. Les conditions de validation de chaque critère seront également précisées.

10.3.1. Modularité
La modularité est l'aptitude d'un logiciel à être composé de modules indépendants. Comme par
exemple le langage de programmation utilisé dans ce projet est JAVA, la modularité sera calculée
en fonction du nombre de lignes de code (LOC) composant chaque classe.

La taille maximale recommandée d'une classe JAVA est de 500 lignes de code. Au delà, le code devi
ent trop complexe.

Une classe sera considérée « valide » si elle respecte l'expression suivante :

ClasseValide = NombreDeLignesDeCode < 500

Le critère « modularité » sera donc mesuré par l'expression suivante : Modularité = 10*( No
mbreDeClassesValides /NombreTotalDeClasses)

Condition de validation de ce critère : La note sur 10 obtenue devra être supérieure à 8.5.

10.3.2. Auto-description
L'auto-description est l'aptitude d'un logiciel à fournir la description de chacune de ses fonctions.
Comme le langage de programmation utilisé dans ce projet est JAVA, il sera possible de rédiger
de la javadoc ainsi que des commentaires avant chaque fonction pour spécifier son rôle, ses attri
buts, sa valeur de retour, ... De la même façon, le corps des fonctions devra être commenté afin d
e rester compréhensible.

Une classe sera considérée « valide » si elle respecte l'expression suivante : ClasseValide = Nombre
DeLignesDeCommentaires/NombreDeLignesDeCode > 30%

Le critère « auto-description » sera donc mesuré par l'expression suivante : Auto-Description = 10*(
NombreDeClassesValides /NombreTotalDeClasses)

Condition de validation de ce critère : La note sur 10 obtenue devra être supérieure à 8.5.

10.3.3. Indépendance logicielle

L'indépendance logicielle est l'aptitude d'un logiciel à ne pas être lié, de par son fonctionnement, à u
n environnement logiciel particulier. Pour respecter ce critère, le logiciel issu de ce projet devra fonc
tionner pareillement sous Windows 7 et sous Linux (XXXXXXX).

132
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Le critère « indépendance logicielle » sera donc mesuré par l'expression suivante : Indépenda
nce logicielle = 10*(FonctionneIndependamentDeL'OS)

Condition de validation de ce critère : La note sur 10 obtenue devra être égale à 10.

10.3.4. Indépendance matérielle


L'indépendance matérielle est l'aptitude d'un logiciel à ne pas être lié, de par son fonctionnement,
à un environnement matériel particulier. Pour respecter ce critère, le logiciel issu de ce projet de
vra fonctionner pareillement (sans prendre en compte la performance) sur différentes configurati
ons de machines.

Le critère « indépendance matérielle » sera donc mesuré par l'expression suivante : Indépendan
ce matérielle = 10*(FonctionneSurPlusieursConfigurationsDeMachines)

Condition de validation de ce critère : La note sur 10 obtenue devra être égale à 10. 10.3.5.

10.3.5. Simplicité

La simplicité est l'aptitude d'un logiciel à avoir un fonctionnement interne compréhensible facilemen
t. Pour cela, des règles de programmation ont été prises (voir chapitre IX.3.B).

Une fonction sera considérée « valide » si elle respecte l'expression suivante : FonctionValide = Nor
mesDeProgrammationRespectées (vrai ou faux)

Le critère « simplicité » sera donc mesuré par l'expression suivante : Simplicité = 10*( NombreDeFo
nctionsValides /NombreTotalDeFonctions)
Condition de validation de ce critère : La note sur 10 obtenue devra être supérieure à 8.5.

11. Reproduction, protection, livraison

11.1. Procédure de reproduction Aucun procédure de reproduction particulière n'est prévu.

11.2. Protection du logiciel Aucune protection du logiciel n'est prévu.

11.3. Livraison et installation Le logiciel final sera remis à l'équipe


BSOA. Il contiendra le code source de l’application, ainsi que le plugin développés.

Les documents livrables seront fournis dans un répertoire « XXXXXXXX ». Les règles de nommag
e de ces fichiers sont explicitées dans le chapitre 9.4. Ce plugin sera installé dans l'IDE eclipse sur u
ne machine de l'entreprise Bull. Un autre exemplaire sera utilisé pour la soutenance de stage de l'équ
ipe de développement (XXXXXXX 2017).
Lors de la livraison du produit à Bull, une procédure complète d'installation sera fournie (dans le ma
nuel utilisateur) afin de permettre à des personnes étrangères à l'équipe de développement d'installer
et d'utiliser le produit sans difficultés.

133
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
12. Suivi de l'application du PAQL
12.1. Validation des documents
Tous les documents rédigés seront relus par le responsable qualité et modifiés en cas de nonconformi
té avec le présent Plan d'Assurance Qualité Logicielle. De la même façon, les documents de type « li
vrables » seront relus et devront être validés par le MOEd (Jérôme Camilleri). Les trois audits prévu
s permettront également de vérifier le bon respect du PAQL. En effet, pendant ces réunions, la situat
ion du produit et l'avancement du projet seront examinés méthodiquement.

12.2.Relecture
La lecture croisée sera effectuée au minimum par les 2 membres de l'équipe de développement (l'un
rédige, l'autre relit) et par le MOEd. L'auteur d'un document assure la réalisation des corrections pro
posés par les relecteurs et gère le changement des numéros de versions.
L'enchaînement des tâches est le suivant :
➢ Création du document
➢ Diffusion aux relecteurs potentiels avec la fiche de relecture1 associée
➢ Intégration des modifications par l'auteur et modification éventuelle du numéro de version
en fonction des modifications effectuées
➢ Validation finale, après plusieurs cycles de diffusion correction, effectuée par le
MOEd XXXXXXXXXX

Exemple de plan qualité pour un PGI


1. Principe
Le rôle de l’assurance qualité est de mettre en œuvre les moyens nécessaires à la fabrication des qualités
demandées. Le rôle du contrôle de qualité est de mettre en œuvre les moyens nécessaires à la vérification de
l’obtention des qualités conformément à la demande.
2. Planification des actions qualité
La planification des actions qualités se présente via la formule suivante :
Action qualité = assurance + contrôle
Les revues de projet ou réunions périodiques entre le fournisseur et le client sanctionnées par la rédaction d’un
compte rendu d’avancement permettra de recadre le projet tant au niveau de son avancement général qu’au
niveau de sa qualité.
Ce processus couvre les points suivants :
(A) Revues de projet internes (au moins une par mois)
(B) Utilisation de méthodes et d’outils d’assurance qualité
(C) Utilisation d’outils de contrôle qualité
Pour chaque mission, ces actions se répartissent de la manière suivante :
Conception générale (A1) Conception détaillée (A2)  codage(A3)  intégration
Les actions (A1 : conception générale) et (A2 : conception détaillée) portent sur la vérification de la spécification
écrite en pseudocode. Cette vérification vise à s’assurer de :
- l’adéquation aux objectifs visés,
- la cohérence des spécifications de conception générale ou détaillée ;
- la complétude des spécifications.
L’action (A3 : écriture des programmes ou codage) porte sur :
134
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
-L’examen du code produit :
a) cohérence avec les documents de conception ;
b) clarté et lisibilité du code avec les commentaires ;
c) cohérence dans la logique de traitement.
- L’examen de la stratégie de validation envisagée :
a) spécification du test de validation ;
b) stratégie de démonstration du produit qui sera poursuivie
Les revues de projet devront faire l’objet :
- d’une réunion entre les acteurs intervenants dans la mise en place du PGI,
- d’un compte rendu qui sanctionne la réunion.
Des revues moins formelles seront faites en interne sur le pseudo­code puis sur le code pour effectuer les lectures
croisées. Leur fréquence et leur planification est laissée à l’appréciation des parties prenantes.
3. Objectifs de qualité recherchée et moyens
Les qualités « importantes » demandées et retenues dans le Contrat de Réalisation sont :
 Pour le lot 1 des tests fonctionnels la portée sera l’ensemble du PGI. Il portera sur les éléments
suivants :
i. la célérité
ii. l’intégrité
iii. la surveillance
iv. la fiabilité
v. la précision
vi. la robustesse
vii. la conformité
viii. l’efficacité
ix. la maniabilité
x. la sécurité
xi. la maintenabilité
xii. l’adaptabilité
xiii. la testabilité
xiv. la portabilité
xv. la réutilisabilité
xvi. l’interopérabilité

 Pour le lot 2 des tests unitaires, d’intégration et de validation, les éléments d’analyse seront:
i. l’ergonomie
ii. la célérité
iii. l’intégrité
iv. la fiabilité
v. la lisibilité
vi. l’extensibilité

Les moyens mis en œuvre pour atteindre les critères de qualité énumérés ci­haut peuvent s’expliquer de la manière
suivante :
- la célérité : pour le matériel les processeurs les plus performants du marché seront utilisés. Le FPI devra
s’assurer que le test soit fait sur du matériel ayant les performances minimales acceptables selon les
exigences du fournisseur du logiciel ;

135
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
- l’intégrité, la sécurité et la surveillance: on utilisera les outils de sécurité et de monitoring du réseau et du
système (firewall, antivirus, vpn, etc) les plus performants de manière à assurer l’intégrité du système. Les
données devront être sécurisées contre les accès non autorisés et les modifications intempestives. Le logiciel
devra gérer un système de journalisation des opérations pour les besoins d’audit de non répudiation des
transactions;
- la fiabilité et la précision: les algorithmes et toutes les règles de gestion seront implémentés par des
professionnels de manière à garantir la fiabilité des résultats. Ils seront par conséquents optimaux (temps
de calcul, précision machine …) et produiront les mêmes résultats dans les mêmes conditions;
- l’ergonomie : logiciel devra avoir une présentation des menus, écrans, boutons de commandes et couleur
qui permettent que l’utilisateur ait une interface facile d’utilisation et répondant clairement à ses besoins
de manière à garantir un bon rendement dans le travail.
- La robustesse et maniabilité : Le progiciel devra être capable de prendre en charge les traitements actuels
et ceux qui seront occasionnés par les besoins futurs. La base des données doit être en mesure de prendre
en charge le nombre important des transactions simultanées qui peuvent s’opérer sans défaillir. En ce qui
concerne la maniabilité, le progiciel devra être manipulé aisément par un utilisateur qui doit à tout moment
retrouver sans trop de peines la fonction qu’il veut utiliser. Cela voudra simplement dire que le logiciel doit
être bien structuré dans sa présentation vis­à­vis de l’utilisateur en regroupant les traitements selon un
contexte homogène.
- La maintenabilité, la conformité et l’adaptabilité: le progiciel étant au cœur du métier du FPI, les
informaticiens­maison doivent être en mesure d’intervenir au premier et deuxième niveau sans recourir au
fournisseur. La mise à disposition des codes sources, bibliothèques des programmes, structure de la base
des données ainsi que la formation adéquate devra garantir que le produit soit facilement maintenable. Il
va sans dire que les programmes sources doivent été écrits dans les règles de l’art avec des commentaires
qui permettent de saisir la portée de chaque module. Le progiciel doit être conforme aux besoins explicites
et implicites exprimés dans le cahier des charges et aux règles et exigences exprimées dans les manuels des
procédures des différentes fonctions­métiers du FPI. Il doit être en mesure de s’adapter à l’évolution des
stratégies de gestion du FPI et a tout changement des règles de gestion et d’organisation.
- La portabilité, la réutilisabilité et l’interopérabilité : le progiciel devra être conçu de manière à pouvoir
être utilisée de manière centralisée ou décentralisée ; en réseau ou en monoposte avec un minimum
d’efforts selon les besoins du FPI. Dans sa structure fonctionnelle interne, il doit avoir des bibliothèques qui
peuvent être réutilisables par d’autres programmes. Il doit assurer une bonne intégration avec toutes les
autres fonctions de l’entreprise de manière à garantir une réelle circulation d’informations cohérentes,
fiables et efficaces entre les différents utilisateurs.
- La lisibilité et l’extensibilité : tous les menus, écrans, textes et autre informations produites ou affichées
par le progiciel doivent être clairement lisibles. En cas d’utilisation d’un langage codé ou les abréviations,
les explications devront être fournies dans une aide intuitive sur la code ou abréviation. Par extension, le
progiciel métier du FPI devra être en mesure de prendre en charge les autres métiers qui ne sont pas encore
couvert par le PGI.

4 – Contrôle du fournisseur
Au cas où le fournisseur recourrait aux tiers pour la réalisation d’une partie du logiciel ou ses
composants, il doit s’assurer que les mécanismes de contrôle sont en place pour le contrôle de qualité.
Dispositions relatives au fournisseur :
- Documentation échangées :
a) Contrat de réalisation et plan qualité logiciel
b) Analyse fonctionnelle
- Actions de suivi qualité :
a) Revues de projet
b) Réunions mensuelles
136
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
- Règles d’acceptation des logiciels sous-traités :
a) Revue de projet OK
b) Suivi de test OK
c) Mesure de qualité OK
d) Emploi des règles PQL
e) Remise des éléments suivants :
(A) Listings
(B) Documents de conception
(C) Codes sources
(D) Chaîne de production de programmes
(E) Procédure d’intégration
(F) Cahier préparatoire au cahier de recette

5 – Reproduction, protection, livraison


Les procédures ci­dessous seront appliquées pour reproduire le logiciel et vérifier la conformité de la copie (par
rapport à l'étalon), les précautions prises pour assurer la protection (physique, juridique, propriété intellectuelle,...)
du logiciel ainsi que les modalités de livraison de la fourniture finale.
1. Reproduction
La procédure de reproduction des logiciels sera décrite dans le document « manuel de production ».
Ce manuel a pour but un usage uniquement interne.
2. Protection et archivage
Des archivages réguliers seront effectués par sécurité. On pourra même les doubler et les stocker en
des lieux distincts.
3. Livraison
Support de livraison : les logiciels seront livrés dans des boîtiers prévus à cet effet. Le transport sera
effectué par avion ou par camion dans des cartons ultra protégés.

6 – Assistance au client et suivit de l’application


 L’équipe de réalisation du fournisseur fournira au client tous les renseignements dont il aurait besoin pour la
mise en œuvre de l’exploitation des logiciels livrés, et assurera dans un premier temps le suivi de l’application.
 Le client (FPI) s’assurera que toutes les informations utiles (documents de procédures, règles de gestion,
structures des bases des données et fonctionnement des applications du système existant, les différents états
en sortie ou résultats, etc.) soient mises à la disposition de l’équipe de réalisation.
 Les deux parties doivent collaborer efficacement et de manière transparente pour la mise en place de ce
nouveau système de gestion intégré.

137
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Annexe B : Plan des tests logiciels

Plan de test
Nom du projet
Les informations d’identification du document Les éléments de vérification du document

Référence du
D7 Validé par : David Janiszek
document :

Version du
1.01 Validé le : 12/06/2019
document :

Date du document : 12 juin 2019 Soumis le : 12/06/2019

Document
Auteur(s) : David Janiszek Type de diffusion :
électronique (.odt)

Confidentialité :

Mots clés : modèle de plan de test, exemple à adapter, …

Sommaire ...............................................................................................................................
1. Introduction (ou préambule) ...............................................................................................
1.1. Objectifs et méthodes ......................................................................................................
1.2. Documents de référence ..................................................................................................
2. Guide de lecture ..................................................................................................................
2.1. Maîtrise d’œuvre ..............................................................................................................
2.2. Maîtrise d’ouvrage ...........................................................................................................
3. Concepts de base .................................................................................................................
4. Tests fonctionnels ...............................................................................................................
4.1. Pour chaque scenario : .....................................................................................................
4.1.1. Identification .................................................................................................................
4.1.2. Description ....................................................................................................................
4.1.3. Contraintes ....................................................................................................................
4.1.4. Dépendances .................................................................................................................
4.1.5. Procédure de test ...........................................................................................................
5. Tests d’intégration ...............................................................................................................
5.1. Pour chaque test d’intégration : .......................................................................................
5.1.1. Identification .................................................................................................................
5.1.2. Description ....................................................................................................................
5.1.3. Contraintes ....................................................................................................................
5.1.4. Dépendances .................................................................................................................
5.1.5. Procédure de test ...........................................................................................................
138
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
6. Tests unitaires .....................................................................................................................
6.1. Pour chaque test unitaire :................................................................................................
6.1.1. Identification .................................................................................................................
6.1.2. Description ....................................................................................................................
6.1.3. Contraintes ....................................................................................................................
6.1.4. Dépendances .................................................................................................................
6.1.5. Procédure de test ...........................................................................................................
7. Vérification de la documentation ........................................................................................
8. Annexes...............................................................................................................................
9. Glossaire .............................................................................................................................
10. Références.........................................................................................................................
11. Index .................................................................................................................................

1. Introduction (ou préambule)


Précise l’objectif du document et en résume le contenu
1.1. Objectifs et méthodes
Présenter le développement du logiciel dans son ensemble
1.2. Documents de référence
Lister tous les documents du projet servant à l’élaboration du présent document
2. Guide de lecture
Précise, pour chaque type de lecteur, comment utiliser efficacement le document
2.1. Maîtrise d’œuvre
2.2. Maîtrise d’ouvrage
3. Concepts de base
Précise les concepts de base nécessaires à la compréhension du document
4. Tests fonctionnels
Décrire les scenarii (ainsi que leur enchainement) permettant de vérifier que l’application recouvrira bien
le périmètre fonctionnel qui a été définit lors de la phase de spécification. Le périmètre fonctionnel est défini
dans le cahier des charges (expression fonctionnelle du besoin)
4.1. Pour chaque scenario :
4.1.1. Identification
Donner un identifiant unique à chaque scenario
4.1.2. Description
Décrire le but du test, les caractéristiques de l’environnement de test et le principe de réalisation
du test.
4.1.3. Contraintes
Décrire les contraintes liées à ce scénario : environnement de test particulier, installation
particulière, intervention humaine spécifique, etc …
Indiquer les éléments de documentation faisant référence (spécifications, éléments de conception,
etc …)
4.1.4. Dépendances
Lister et expliciter les tests à mener préalablement à la réalisation du scénario.
4.1.5. Procédure de test
Décrire les données en entrée, les résultats attendus, et les critères de validation
5. Tests d’intégration
Décrire les tests (ainsi que leur enchainement) permettant de vérifier que les différents modules,
paquetages, … de l’application s’interfacent correctement. On distinguera les interfaces internes des interfaces
externes à l’application.
5.1. Pour chaque test d’intégration :
5.1.1. Identification
139
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA
Donner un identifiant unique à chaque test d’intégration
5.1.2. Description
Décrire le but du test, les caractéristiques de l’environnement de test et le principe de réalisation
du test.
5.1.3. Contraintes
Décrire les contraintes liées à ce test : environnement de test particulier, installation particulière,
intervention humaine spécifique, etc …
Indiquer les éléments de documentation faisant référence (spécifications, éléments de conception,
etc …)
5.1.4. Dépendances
Lister et expliciter les tests à mener préalablement à la réalisation du test.
5.1.5. Procédure de test
Décrire les données en entrée, les résultats attendus, et les critères de validation
6. Tests unitaires
Décrire les tests (ainsi que leur enchainement) permettant de vérifier que le comportement de chaque
fonction, méthode, etc… de l’application corresponde de manière satisfaisante à ce qui a été défini lors de la
phase de conception détaillée.
6.1. Pour chaque test unitaire :
6.1.1. Identification
Donner un identifiant unique à chaque test unitaire
6.1.2. Description
Décrire le but du test, les caractéristiques de l’environnement de test et le principe de réalisation
du test.
6.1.3. Contraintes
Décrire les contraintes liées à ce test : environnement de test particulier, installation particulière,
intervention humaine spécifique, etc …
Indiquer les éléments de documentation faisant référence (spécifications, éléments de conception,
etc …)
6.1.4. Dépendances
Lister et expliciter les tests à mener préalablement à la réalisation du test.
6.1.5. Procédure de test
Décrire les données en entrée, les résultats attendus, et les critères de validation
7. Vérification de la documentation
Vérifier la concordance entre les différentes procédures décrites dans la documentation et leur mise en
œuvre réelle.
8. Annexes
9. Glossaire
Définit l’ensemble des termes spécialisés du document
10. Références
Indique les références bibliographiques vers d’autres documents apportant des informations complémentaires
11. Index
Liste les mots-clés du document et où les trouver dans celui-ci

140
© Prof. Jean-Pierre Booto Ekionea, Ph.D. QSPA