Le document présente un modèle de tests de vérification et de validation, notamment à travers l'exemple du logiciel 'Payment Manager 1.0', pour améliorer les pratiques de développement logiciel en République Démocratique du Congo. Il souligne l'absence de formalisation des tests logiciels chez les professionnels locaux et propose des éléments adaptés pour élaborer un modèle simplifié basé sur les besoins des utilisateurs et les processus existants. Enfin, l'étude s'inscrit dans une démarche d'amélioration des pratiques TI via des ateliers de formation pour les étudiants en informatique.

1. Les cahiers de BSD Congo n°4, mai 2011
ELEMENTS D’ELABORATION D’UN MODELE DE TESTS DE VERIFICATION ET DE
VALIDATION DANS UN PROJET DE DEVELOPPEMENT MIXTE : L’EXEMPLE DE
PAYMENT MANAGER 1.0.
Contribution de MBUTA IKOKO Dodi Alphonse1
Spécialiste MIS et Chargé de Projet Ident et ITS à l’UEPN-DDR
Conseiller TI et Responsable de la cellule Recherche et Développement de BSD Congo,
Assistant d’enseignement et de recherche en informatique et MIS
Département d’Informatique de Gestion, Université Libre de Kinshasa, RD Congo &
Section Informatique, Institut Supérieur de Commerce de Kinshasa, RD Congo
Email: dodi.mbuta@bsdcongo.org / mbutaikoko@hotmail.fr
Mai 2011
Contact, « Les cahiers de BSD Congo »
Téléphone : +243(0)819-993-160 / +243(0)998-399-386
Email : info@bsdcongo.org
Site Internet : http://www.bsdcongo.org
Dans le cadre de sa politique de vulgarisation des méthodes et outils TI et pour un meilleur
partage du savoir libre en RD Congo, l’Association BSD Congo a créé depuis 2009, via la cellule
« recherche et développement » qui œuvre au sein de son équipe technique, une note de
communication et de partage d’expérience dans le domaine des TI, appelée « Les cahiers de BSD
Congo », documents de travail ou de pré - publications n'excédant pas quarante pages. Ils sont
diffusés et mis à la disposition des membres/partenaires de BSD Congo et du public, via Internet,
dans une perspective d’échanges et de partage du savoir TI. Ces échanges se réalisent dans un
souci de réciprocité et de libre circulation de préoccupations professionnelles ou scientifiques.
Leur contenu n'est pas définitif et peut être sujet à discussion. Ils ne constituent donc qu'une étape
dans la démarche scientifique.
Résumé
Les tests logiciels restent une approche incontournable dans le développement logiciel, surtout
avant la mise en production du produit – logiciel développé.
En RD Congo, la pratique de tests semble n’est pas encore du tout formalisée dans la personne
des professionnels TI congolais. Ceux qui s’aventurent la réalisent sans le respect des référentiels
normatifs applicables. C’est pourquoi, avec notre retour d’expérience de chef de projet Ident –
ITS à l’UEPN – DDR, dans le cadre d’un développement en impartition, avec la firme BIO – ID
Technologies SA, du logiciel « Payment Manager », nous avons jugé bon de fournir à notre
communauté des éléments adaptés aidant à l’élaboration d’un modèle de tests logiciels sous la
forme d’une ébauche unifiée et simpliste. Elle est produite à partir à partir de l’expression de
besoins des utilisateurs, des processus et/ou règles métiers de l’UEPN – DDR, etc. qui ont été, par
la suite, formalisés en modèle d’exigences fonctionnelles. Utilisant une démarche de
modélisation empruntée à l’IDM, cette ébauche a donc pour but de faciliter la réalisation et
l’exécution de tests logiciels de niveau supérieur (système et validation) par une équipe de
développement logiciel suivant les conditions contractuelles et environnementales. C’est donc un
élément d’entrée de jeux à produire par les acteurs impliqués dans un projet de développement lors
de la remise en question ou pas du produit – logiciel attendu des utilisateurs.
1
L’auteur de cette contribution remercie les lecteurs pour leurs judicieuses remarques et suggestions. Il tient aussi à
les signifier qu’une partie de ce texte a fait l’objet d’une présentation lors d’un « atelier de BSD Congo » sur le
développement informatique avec un groupe d’étudiants du Département des Mathématiques et Informatique de
l’Université de Kinshasa, au mois de Juin 2010.

2. 2
Mots clés : Projet de développement logiciel mixte – Tests logiciels – Méthodes et outils de gestion
de tests – Exigences pour la vérification et la validation – Modèle de tests système.
I. INTRODUCTION
Dans le domaine de développement et/ou de construction des logiciels (intangibilité), appelé
« Génie logiciel », mais aussi celui de conception des systèmes d’information (complexité),
classiquement, une fois les premières phases de développement terminées (l’analyse des besoins,
la spécification globale, la conception détaillée et la programmation), les activités les plus
visibles et les plus décisives qui permettent à l’équipe de développement et/ou de projet TI de
pouvoir autoriser la phase d’installation ou de déploiement du produit – logiciel développé
(déterminisme) sont celles de tests logiciels. Ces activités visibles de vérification mais aussi de
validation, orientées mode projet, sont menées dans le seul but de s’assurer que le produit –
logiciel développé est correct et répond aux exigences formulées ou convenues au départ par le
maître d’ouvrage et le maître d’œuvre. Elles offrent donc, ces activités de tests, une approche
expérimentale de résolution de problèmes de conception logicielle par des méthodes et des outils
de génie logiciel (Luc Lavoie, 2007). Elles font donc partie des gages de succès, surtout pour des
projets informatiques de développement logiciel exécutés en impartition et/ou en partenariat
(mixte).
En RD Congo, la plupart des développements informatiques sont actuellement réalisés en
impartition et/ou en partenariat, mais toujours de manière brute, et n’admet presque pas la
nécessité de tester (vérifier) et/ou de valider un produit - logiciel développé de façon
systématique. Dans pas mal d’entreprises, les activités requises pour tester et valider un logiciel
ne sont parfois admises que pour des logiciels standards acquis et sûrs de fonctionnement (Ivinza
Lepapa A. C. et Mbuta Ikoko D. A., 2006). Or logiquement, un logiciel développé ne peut pas
être mis en service si la démonstration de sa fiabilité (qualité et sécurité) n’est pas effectuée par le
maître d’ouvrage ou son délégué. La fiabilité est alors une part cruciale dans le développement
logiciel.2
Dans la littérature, plusieurs études ont déjà rapporté que près de 40 % des projets de
développement des logiciels et/ou d’intégration des modules progiciels dans les entreprises
n’atteignent pas les objectifs fixés au départ soit en termes de manque de qualité d'exigences, de
faible implication des utilisateurs, de budget, d’échéancier ou de résultats à livrer (Songini M.,
2005, Vital Roy et alii, 2007). D’autres ont mentionné voire que 15 % des projets de
développement des logiciels informatiques sont annulés avant leur fin avec des effets souvent
désastreux pour l’entreprise et pour les ressources affectées par manque de leur maturité, etc.
(Iacovou C.L. et Dexter A.S., 2005, cité par Vital Roy et alii, 2007). Ces taux d’échecs, selon
moi, risquent d’être trop élevés en RD Congo suite à certaines pratiques malgré la tentative d’une
professionnalisation sans un corpus de connaissances clair (manque d’études ou recherches
locales en matière de conduite des activités de développement logiciel mais aussi les dangers que
pourraient présenter cette conduite pour nos entreprises, etc.). Nous imaginons à propos que la
réponse critique aux différents éléments évoqués se trouve donc situer dans l’adoption d’un
management plus large, qui couple les valeurs agiles aux techniques de l’amélioration continue3
de la qualité et/ou à celles basées sur le processus ou la maîtrise documentaire.
2
Lors de la phase de réalisation, en rapport avec le domaine auquel le logiciel en développement sera exploité
(gestion, télécommunications, etc.), plusieurs complexités apparaissent. Elles sont parfois simples, difficiles ou très
difficiles selon qu’il s’agit des structures organisationnelles différentes. La notion de tests mais aussi de la qualité
logiciels sont alors très essentielles pour que le produit logiciel à implémenter puisse contribuer à la réalisation de la
mission même de l’organisation face à l’adéquation aux objectifs Q, C, D, P (Qualité, Coûts, Délais et Prestations).
3
Les techniques de l’amélioration continue sont basées sur le cycle « PDCA : Plan, Do, Check and Act », dit modèle
de Deming (1986), qui s’applique presqu’à tout système de management de la qualité. Dans un projet informatique
de développement logiciel, le référentiel CMMI – DEV (2006) de Humphrey W. de Carnegie Mellon, dédié à la

3. 3
Cette résolution associée est d’autant plus exigée qu’elle devrait être recommandée aux équipes
formelles de développement logiciel en RD Congo pour pouvoir leur permettre de livrer un bon
produit, qui respecterait voire les règles de l’art ou métier, et qui leur éviterait de dénaturer les
procédures et les procédés qui sont en principe connus et définis, à partir des besoins initiaux ou
quotidiens (exprimés par le maître d’ouvrage ou par les utilisateurs). Cet aspect hypothétique
d’améliorer les pratiques TI congolaises dans l’accomplissement, avec succès, de certains projets
informatiques de développement logiciel rend alors intéressant la compréhension et l’importance
de disposer, avant chaque activité de vérification et de validation, un modèle de tests logiciels (de
niveau de supérieur) produit sur base des référentiels existants.
Cette contribution, qui rentre dans la perspective d’amélioration des pratiques TI congolaises
poursuivie par la structure BSD Congo, particulièrement en matière de développement logiciels,
s’inscrit dans le cadre des ateliers pratiques que sa cellule « Recherche et Développement » a
organisé et continuerait à organiser avec certains étudiants informaticiens sur la modélisation de
tests logiciels dans les milieux universitaires congolais (UNIKIN, ULK, ISTA, etc.). Elle
s’organise alors comme suit : Au point II, nous présenterons l’état de l’art et les grandes lignes
sur lesquels cette contribution s’appuie. Il résume donc, dans une première phase, quelques
prérequis pour la gestion d’un projet informatique de développement logiciel. Dans une seconde
phase seront présentés de façon globale les concepts de programmation et de tests logiciels. Cette
deuxième phase passera aussi en revue les niveaux, méthodes et outils de tests qui seront
complétés à leur tour des lignes essentielles (exigences dans les activités de vérification et de
validation, modélisation comportementale des exigences dans l’UML pour les tests, efficacité de
tests, etc.) aidant à l’élaboration de notre modèle de tests. Le point III présentera notre démarche
d’élaboration du modèle de tests qui, sur base des processus et règles métiers décrits (processus
de paiement dans le cadre de DDR), va produire et détailler l’ensemble des exigences à aligner
dans les activités de tests logiciels. Ces exigences, seront donc vus, ensemble avec les cas et les
résultats de tests à concevoir, comme base de notre ébauche de modèle de tests dans le cadre de
vérification et de validation du produit – logiciel « Payment Manager ». Une conclusion et
quelques perspectives terminent cette contribution.
II. APPROCHES SUR LE DEVELOPPEMENT INFORMATIQUE
Section I. L’univers de développement informatique dans les entreprises : contour managérial
et organisationnel
a) Le développement informatique dans les entreprises : Considérations générales
Le développement informatique est une activité intensément collaborative. Il consiste à analyser
ou étudier les besoins de gestion optimisée d’une organisation, à concevoir des solutions sur la
base de ces besoins, à modéliser informatiquement ces solutions, c’est-à-dire les transcrire dans
un langage informatique, les implémenter sur une machine ou un système et les maintenir ou les
faire évoluer. Pour ce faire, le génie logiciel »4
, qui s’occupe de la fabrication des systèmes
informatisés, c.à.d. des logiciels dans notre cas, traite cette réalisation informatique dans le but
d’atteindre un objectif spécifique. C’est donc le domaine de l’informatique qui allie les capacités
d'analyse et d’adaptation à un esprit de synthèse, tout en mettant en œuvre les techniques (outils
conception et au développement des logiciels, s’associe à ce modèle de Deming pour tenter d’aider les organismes
d’ingénierie à améliorer la capacité de leurs processus à travers 5 niveaux dit de maturité (initial, reproductible,
défini, géré et optimisé).
4
Selon la norme IEEE 610.12, le génie logiciel est l’application d’une approche systématique, disciplinée et
quantifiable au développement, à l’exploitation et à la maintenance du logiciel. C’est-à-dire, l’application de
l’ingénierie au logiciel.

4. 4
et méthodes) et le sens de créativité. Orienté vers le management de projet, il est défini comme un
ensemble d’activités informatiques à effectuer pour atteindre un but unique défini de façon
spécifique. Cette spécificité de but unique à atteindre est très importante dans les faits, car elle
délimite voire le champ d’action des acteurs clés, dans un projet, qui utilisent ces techniques dites
d’ingénierie des exigences (une des parties du génie logiciel qui permet de déterminer quel
système sera développé, sa sécurité et sa durabilité), et un management plus large, qui couple à
leur tour les valeurs des techniques agiles de l’amélioration continue de la qualité.5
Pour avancer dans ce raisonnement, il conviendrait de rappeler quelques considérations. En effet,
dans une entreprise, le sommet stratégique vise globalement deux finalités : (1) satisfaire les
besoins et les attentes des utilisateurs de ses produits et/ou de ses services et (2) contribuer au
bien être, au développement et à l’épanouissement de tous ceux qui y travaillent. Cet ensemble
des caractéristiques intrinsèques à satisfaire des exigences est une aptitude de la qualité repris
dans un système d’information6
manuel qualité d’une entreprise. Elle est ainsi managée, cette
aptitude, par un système de management axé sur la définition des objectifs qualité et sur la
spécification des processus opérationnels et des ressources afférentes, nécessaires pour atteindre
les objectifs qualité (NF EN ISO 9000 : 2000). Ce système est donc le système de management
de la qualité. Comme c'est une activité qui exige une vision et un engagement à long terme, les
risques et les limites associées à l'amélioration des processus définis sont donc à prendre en
compte et/ou à considérer. Il est alors très difficile de retrouver la dynamique nécessaire pour le
succès d’une telle opération dans une entreprise sans avoir une équipe dédiée, un budget alloué et
un plan avec des objectifs raisonnables. Cette méthodologie mais aussi les méthodes et outils,
destinés à soutenir l’évolution des systèmes d’information dans l’entreprise, peut se démarquer
des autres domaines stratégiques, mais ne peut et ne doit en aucun cas en être dissocié, puisque
leurs rôles sont parfaitement identifiés par les différents processus d'une organisation et s’appuie
sur des moyens de développement, d’intégration et de production dédiés. Ils impactent donc de
manière déterminante l’implémentation de la stratégie de l’entreprise.
Le génie logiciel, comme dit au début, n’échappe donc pas à cette règle, car son problème
fondamental est celui de construire, pour un système d’information existant dans une entreprise,
des logiciels7
qui soient ergonomiques, fiables, évolutifs et économiques c.à.d. garantissant le
contrat de service requis par les usagers (ISO IEC 9126) et satisfaisant aux critères coûts et
qualité. Il est donc possible de distinguer les référentiels « produit » qui permettent de fixer les
caractéristiques que doivent avoir les composants d’un système d’information (matériel,
logiciel,...) et les référentiels « management » qui introduisent à un niveau organisationnel les
aspects techniques déjà̀ pris en compte. Ici, le système logiciel à développer devient une variété
du système d’information dans lequel l’ordinateur est au centre de son traitement de l’information
(système informatique) et soutient voire son évolution, l’implémenter, c’est donc se poser des
questions relatives sur son rôle dans l’organisation et les hommes qui l’utilisent (Dupuy et Alii,
1993, cité par Ivinza Lepapa A. C., 2007). Cette approche systémique le fait apparaître, de
manière récursive et dynamique lors de son implémentation dans l’organisation, à la fois comme
un moyen essentiel et un objet principal du management au-delà de l’ordinateur et de la
5
La qualité, dans le domaine de développement et de conception, est vue comme le but ou l’exigence ultime à
atteindre car elle se retrouve étroitement liée à la réalisation au point qu’il est très difficile de partager distinctement
les activités de développement des celles de qualité.
6
Le système d’information, abrégé SI, est une représentation systémique de l’entreprise et de ses activités. En grande
partie immatériel, il est donc complexe (Lemoigne, 1994) et est organisé autour des ressources, sous diverses
dimensions (organisationnelle, managériale et technologique) (Reix R., 2004 et Laudon et Alii, 2006).
7
Actuellement, trois types de logiciels existent. Il s’agit des logiciels constructeurs, qui sont très dépendants du matériel ;
des progiciels, développés par les éditeurs de logiciel, des boîtes noires, généralement paramétrables, assurant telles ou
telles fonctions précise ; et des logiciels propriétaires, développés pour les besoins spécifiques de l’entreprise ou de
l’organisation, soit par elle même ou soit par l’intermédiaire de sociétés de services.

5. 5
technologie. Ce résultat provenant d’une organisation et/ou d’une modélisation permet au
système d’information de l’entreprise de fournir et de disposer des outils permettant « … de
garder en mémoire une représentation de l’activité du système opérant au sein de
l’environnement afin de le mettre à la disposition des acteurs de décision pour qu’ils puissent
piloter, coordonner et finaliser le comportement du système opérant ».8
C’est donc une
implémentation, sous forme de processus en interaction et non de services, qui implique de la
compétence aux acteurs de l’équipe du projet tout en prenant en compte les aspects dynamique et
l’adoption des méthodes et outils pour minimiser ou maîtriser les facteurs susceptibles de
compromettre un projet de développement. Ici, l’on devra par exemple tenir compte de la qualité
des spécifications produites en amont (spécifications des besoins et spécifications des exigences
qui doivent être adéquates, non-ambiguës, cohérentes, vérifiables, modifiables, traçables, etc.), et
en aval, des erreurs sur les artefacts produits durant l’implémentation, qui ne reflètent toujours
pas les besoins réels et ne satisfont presque pas in fine les exigences fournies, pour ne pas
connaître un échec.
Dans ce contexte, le sommet stratégique de l’entreprise ou le maître d’ouvrage (MOA) qui met
sur pied une organisation, sous forme de projet, et des moyens sûrs pour le pilotage des processus
ou des activités liées, va alors confier à sa fonction systèmes d'information (maître d’œuvre,
MOE, qui apporte alors ses connaissances de l'environnement technique et financière puis son
expérience sur des solutions technologiques au sein de l’entreprise), la mission d’élaboration en
amont d’un document qui spécifie les besoins fonctionnels du produit – logiciel à acquérir et/ou à
développer et, en aval, de développement et/ou d’acquisition, soit partiellement ou totalement, de
ce produit – logiciel sur la base d’un mode de gestion choisi et/ou décidé. Néanmoins, « au regard
de la politique de rationalisation des coûts mis en place, la fonction financière et la fonction des
approvisionnements de l’entreprise, auront aussi leur mot à dire sur les budgets à allouer »
(Antoine Crochet D., 2011).
On se retrouve alors face à un projet informatique de développement ou un projet système
d’information dont les ressources humaines, techniques, procédurales et méthodologiques à
mettre en œuvre doivent être orientées vers l’amélioration continue et vers la livraison d’un
produit logiciel fiable.
Cette vision commune de gestion des systèmes d’information et de gestion de la qualité dans un
développement informatique s’appuie sur la vision globale de l’entreprise, mais aussi à la nature
de l’activité de l’entreprise, sur la décomposition par processus, à la taille de l’entreprise et aux
méthodes de gestion que les dirigeants veulent mettre en œuvre.
b) Les projets informatiques ou TI : composants et limites
Ø Types et modes d’approvisionnement de projets informatiques
Les projets informatiques construisent des logiciels mais aussi gèrent les matériels et tout type de
dispositif de communication numérique, qui ne représentant que la partie technologique du SI, les
TI.9
Ils soutiennent alors l’évolution du système d’information dans une entreprise et font partie,
de manière générale, des projets « systèmes d’information ». Leurs objectifs ne sont pas
seulement ceux qui sont rattachés à la gestion des difficultés (pas seulement techniques) de
conception et de réalisation des logiciels mais aussi celles de la mise en œuvre, exploitation et au
8
TARDIEU Hubert, NANCI D., PASCOT Daniel, Conception d’un système d’information : Construction de la Base
des données, Edition d’organisation, Gaëtan Morin Editeur, Paris, Québec, 1980 pages 30-31.
9
Les TI (Technologies de l’information), en anglais Information Technology, sont des composantes de nature
technique que les organisations ou les entreprises achètent, développent ou combinent pour constituer l’infrastructure
technologique qui permet, par la suite, à leur SI de fonctionner.

6. 6
maintien des services du système d'information d'une entreprise en s’appuyant sur les
architectures informatiques et les réseaux de communications. Ils sont alors complétés, ces
objectifs, des plusieurs propriétés telles que la sécurité des données (protection, confidentialité,
intégrité), la sécurité des traitements (disponibilité, sûreté) et la qualité de service (disponibilité
des services, pérennité, relation avec les utilisateurs).
Généralement, il existe deux types de projets informatiques, à savoir : « les projets d’exploitation
informatique » et « les projets de développement et/ou de maintenance logiciels ». Ces deux types
de projets informatiques tournent autour de cinq dimensions fondamentales, à savoir : (1) sa
mission, (2) ses activités critiques, (3) les compétences et connaissances de ses membres10
, (4) sa
relation avec le reste des unités d’affaires de l’organisation où il s’exécute et (5) sa gouvernance.
Ainsi, les projets de développement, qui concernent l’évolution et l’entretien des plateformes
technologiques, sont souvent réalisés à l’externe d’une organisation pour des raisons de
productivité et de performance (approche « outsourcing »). En faisant l’objet de développement
d’un système logiciel à intégrer au sein d’un système d’information existant, les acteurs de
l’organisation partenaire auront à partager par exemple les responsabilités, les risques et les
bénéfices éventuels du projet avec les acteurs de l’organisation interne en plus de l’obligation de
transfert d’expertises.
Vital Roy et alii (2007) alignent, selon la disponibilité de acteurs compétents et la valeur
stratégique de l’informatique dans une entreprise, quatre modes d’approvisionnement distincts
pour répondre aux besoins de développement logiciels. Il s’agit des modes d’approvisionnement
à l’interne, en partenariat, en impartition11
et en récupération ». Ces modes sont constitués selon
qu’il s’agisse d’une vision informatique de développement à forte ou à faible transformation
organisationnelle. Les modes en partenariat et en impartition constituent tous deux un projet
informatique de développement de type mixte. C’est une structure organisationnelle temporaire
orientée vers l’accomplissement d’un objectif, le développement du système logiciel, par le
partenaire technologique interne de l’organisation, c.à.d. sa fonction système d’information
(maître d’œuvre technologique de l’organisation), et un sous – traitant (partenaire externe). Ici,
les acteurs impliqués, experts métier et informaticiens de différentes spécialités (concepteurs,
développeurs, designers, testeurs, administrateurs de bases de données, etc.), qui unissent et
harmonisent leurs efforts pour faire aboutir ces projets logiciels, ne doivent pas seulement se
préoccuper des différents processus et procédés12
qui s’y rattachent [procédés prédictifs (V, W,
cascade, …) ou procédés synthétiques ou agiles (RAD, XP, Scrum, …)], mais aussi de la gestion
des coûts, des délais, du temps, des ressources et des communications suivant les cahier des
charges définis.
Ø Organisation et moyens de pilotage d’un projet de développement logiciel mixte
En cherchant d’élaborer des dispositifs pour conduire un projet de développement logiciel mixte,
basés sur le concept de contrôle et de la régulation qui guide son fonctionnement et son évolution,
on aboutit alors à la définition et au dimensionnement des moyens à mettre en œuvre. Dans cette
10
Celles - ci sont vues à la fois sous l’angle d’un savoir tacite (compétences des acteurs TI dans l’utilisation des TI
ou dans la gestion des projets TI mais aussi leur vision à retirer du rôle des TI dans les processus à gérer) et d’un
savoir explicite (connaissances technologique des acteurs et sur les applications et le développement des SI mais
aussi sur leur gestion).
11
Ce mode d’approvisionnement est parfois appelé mixte dans le cas des entreprises de taille moyenne ayant une
valeur stratégique et pour lesquels les ressources et les compétences requises sont en partie disponibles à l’interne. Il
associe alors, dans ses activités de conception, de réalisation et d’implémentation, le transfert, l’acquisition et
l’échange d’expertises entre les ressources du projet.
12
Un procédé est cet ensemble des moyens et des méthodes permettant d’accomplir une activité. En fixant les
procédés (quand ceci est nécessaire), on prescrit le comment faire. Ne confondons jamais les mots procédé et
processus qui se disent tous deux en anglais « process ».

7. 7
foulée mais aussi avec la logique évoquée dans le point précédant, le chef de projet à qui on
confie la destinée d’un projet informatique devra avoir besoin des variables essentielles, par
exemple un tableau de bord, pour pouvoir de détecter le plus rapidement possible d’éventuels
problèmes et éviter ainsi des situations irrémédiables, et des variables d’actions. Ceux - ci vont
lui permettre de pouvoir disposer d’un style de gestion comparable à celui de leader
transactionnel, orienté vers le contrôle dans un objectif de maximisation des résultats et de
stabilité des processus, ou à celui de leader transformationnel, orienté vers la flexibilité dans un
objectif d’adaptation au changement et de partage des connaissances. Pour le profil de leader
transactionnel, Vital Roy et alii (2007) en exploitant les travaux de Aaron J. Shenhar (2001) et de
Gottschalk Peter et Karlsen Jan T. (2005), qui utilisent la typologie des six rôles de gestion de
Mintzberg H. (1994), et de Quinn Robert E. (1988), sur les divers rôles de gestion pour la
recherche de performance dans des contextes organisationnels spécifiques, recommandent aux
chefs de projet les rôles de producteur, de directeur, de coordonnateur et de contrôleur. Par
contre, pour le profil de leadership transformationnel, ils alignent les rôles d’agent de liaison,
d’innovateur, de mentor et de facilitateur.
Toutefois, lorsqu’on se retrouve face à une impartition (développement mixte), le chef de projet
client devra ajouter le rôle de « spokesman » tandis que celui de l’impartiteur, le rôle de
« resources allocator ». Dans ce mode d’approvisionnement, c’est donc la communication13
, le
suivi et la coordination, qui constituent voire le gage de succès du projet piloté.
Ainsi, manager un projet informatique de développement mixte est une opération complexe car il
comporte une part importante d’incertitude, et la nature du système d’information de l’entreprise
en accroît les risques.14 Ici, plusieurs référentiels sont mis en place dont le corpus de
formalisation est en cours pour certains [des méthodes et des outils (CMMI, COBIT, ITIL,
EBIOS, PMI, ...), au niveau inférieur, et des normes de management (ISO 9001, ISO 10006, ISO
27001, ISO 25000, …), au niveau supérieur]. D’ailleurs, pour Frederick P. Brooks (2001), les
projets informatiques de développement logiciel sont incomparables aux autres en raison de
l’importance qu’occupent voire le produit – logiciel et ses processus. Ils sont et restent toujours
difficiles à conduire. Néanmoins, les référentiels classiques de niveau inférieur mis en place, qui
prônent un enchaînement séquentiel (parfois lourd) des processus, depuis l’étude de faisabilité
jusqu’à la mise en œuvre complète du système ou du produit – logiciel, et les pratiques
complémentaires, dites « agiles » – une contribution professionnelle évolutionniste –, permettent
actuellement aux équipes de projets de produire, dans un contexte de réactivité, de réduction des
délais et de livraison, un système logiciel dont l’utilisateur participe totalement à sa conception
(Valtech, 2008, Véronique Messager Rota, 2009, …). Notons que l’adoption de ces pratiques
complémentaires (développement dirigé par les tests, programmation itérative, réunions
quotidiennes, etc.), dans une approche d’amélioration continue, est une conséquence positive
pour le management de projets informatiques dans son ensemble. Elles ont pour principal
objectif, sans pour autant rejeter les valeurs clés de l’approche classique qui doivent encore rester
omniprésentes, l’implication au quotidien du client au sein de l’équipe du projet afin d’éviter des
incohérences entre le besoin initial et le produit à livrer. Pour cela, elles valorisent « les individus
et les interactions plutôt que les processus et les outils méthodologiques, les logiciels
13
Le manque d’une communication dans un projet de développement logiciel peut amener à une différence de
compréhension entre les différents acteurs. En gérant l’ensemble de la communication du projet, le chef de projet TI
devra ainsi informer de manière régulière et efficace les différents acteurs des évolutions fonctionnelles (rendre
compte de la performance par exemple) sur chaque processus défini dans le cadre du projet et pouvoir réfléchir sur
une option à prendre.
14
Ici, le profil de la fonction SI est très important et devra être connu d’avance. Guy Paré et Guillemette Manon
(2007) en propose cinq, à savoir : le partenaire, le fournisseur de systèmes, le concepteur d'infrastructures, le leader
technologique et coordonnateur de projets TI dans une entreprise.

8. 8
opérationnels plutôt que les documentations exhaustives, la collaboration avec les clients plutôt
que la négociation contractuelle et l’adaptation au changement plutôt que le suivi d’un plan ».
Ø Les processus et les activités dans un projet informatique de développement logiciel
Un processus, de manière générale, représente un ensemble d’activités effectué par une ou
plusieurs personnes dans le but de créer un produit, avec un coût et des moyens matériels. Il est
souvent constitué de sous processus, ou tâches, selon une décomposition hiérarchique dont
l’activité est l’élément du plus bas niveau. L’activité est donc un processus qui tente de
transformer des entrées en sortie.
Les activités se définissent alors comme un ensemble homogènes d’actions, concourant à un
même objectif, et nécessitant les mêmes compétences, et analysant les types de travaux et les
responsabilités opérationnelles. En les décrivant, on définit le quoi faire. Elles possèdent alors des
points d’ancrage ou d’interaction entre eux qui renvoient à l’articulation des phases dans un
projet. Ainsi, dans une gestion globale de développement logiciel, plusieurs processus peuvent
exister [processus de vérification et de validation (tests, contrôles, preuves, etc.), processus de
gestion des anomalies, etc.] et peuvent s’interférer avec celui de gestion de projet suivant une
approche d’amélioration continue (figure 1). Ici, la notion d’activités suit donc les mêmes
principes que les processus dans le cycle de développement, et leur maîtrise, comme nous avons
dit précédemment concernant les procédés, est très essentielle dans l’exécution du projet. Elles
englobent ainsi des phases d’analyse, de conception, de programmation, de tests logiciels,
d’installation, etc. et permettent une prise en compte des exigences du MOA par le MOE pour la
réalisation d’un produit – logiciel.
2013-01-17GP000:Introduction(v240b)L.Lavoie(UdeS)
24
INTRODUCTION
UN CVL DE DÉVELOPPEMENT LOGICIEL INSPIRÉ DE L’IEEE
Fig.1. Cycle de vie du logiciel inspiré de l’IEEE intégrant le cycle de développement du logiciel (source : Luc Lavoie, 2007).
En somme, la réalisation de toutes ces activités ou de différents processus dans un cycle de vie du
logiciel matérialisent le plan qualité, qui essaie de donner à son tour une vision globale et complète
du projet en permettant des effets zoom sur le développement du logiciel mais aussi sur la manière
dont la qualité devra être assurée tout au long de la réalisation du logiciel.
Quant à une procédure, elle est définie par la norme NF EN ISO 9000 : 2000 comme une manière
d’accomplir une activité et traite de son aspect organisationnel en répondant aux questions de qui
fait? Et quand le fait-il?

9. 9
c) Autres éléments à considérer dans un projet informatique de développement logiciel.
Ø Plan et clauses qualité dans le développement logiciel
Dans un projet informatique de développement logiciel, le plan qualité logiciel, ou plan d’assurance
qualité (PAQ), définit les mesures d’assurance de la qualité du logiciel pris en s’inscrivant dans la
politique globale du MOA en matière de qualité. Il fait donc le suivi de la mise en œuvre de
l’assurance qualité et la gestion des risques devant être appliquée tout au long du projet. Les
recommandations sur le produit – logiciel souhaité marque alors une problématique sur sa
fiabilité.15
Il s’agit en fait d’une priorité pour un projet donné de développement informatique et
constitue son outil de communication de référence, pour le management de la qualité, validé par les
parties, où chaque intervenant trouve exposer sa place et son rôle, tout en spécifiant quelles
procédures doivent être appliquées pour réaliser une tâche ou un processus ? Le PAQ fait mention
aux caractéristiques logicielles au sein duquel s’instancie la stratégie de test en rapport avec la
qualité. Ces caractéristiques forment donc des exigences qualité logicielle et peuvent se mesurer à
l'aide des indicateurs ou métriques ci – après :
- la maniabilité (communicabilité, exploitabilité et facilité d’apprentissage),
- la fiabilité (complexité, tolérance aux fautes ou pannes et auditabilité),
- l’efficience (consommation en place mémoire, taille des périphériques et leur
vitesse d’accès et temps d’exécution des programmes),
- la confidentialité (protection du code et des données et mémorisation des accès),
- la couplabilité (standardisation des données et standardisation des interfaces),
- la maintenabilité (lisibilité, modularité, traçabilité et adaptabilité),
- l’adaptabilité (évolution facile du logiciel),
- la portabilité (banalité d’emploi, indépendance et qualité de documentation), et
- l’efficacité (coûts et gains dus au logiciel).
Ce sont donc des clauses qualité (contractuelles ou non). Dans cette perspective, la version 1.2 du
référentiel CMMI – DEV de Humphrey W., développé par Software Engineering Institute de
l’université de Carnegie Mellon, ira même à déterminer que la qualité d’un logiciel devra être en
relation directe avec la qualité du processus utilisé pour son développement. Ainsi, actuellement,
pour développer par exemple un logiciel de qualité, un programmeur procède par la création de
composants16
qui permet de construire par la suite le logiciel. Pour cela, il explore des bibliothèques
logicielles antérieures pour trouver et constituer des composants logiciels appropriés pour une
nouvelle bibliothèque. Cette réutilisation de composants ou des briques logicielles est une des
approches de maturité ou d’amélioration dans le domaine de développement dite framework (COM
et ses dérivés), issu de OLE (Object Linking & Embedding) de Microsoft car on n’écrit presque plus
des logiciels à partir du néant. Avec cette approche amélioration continue, le programmeur a
seulement l’obligation de proposer une architecture logicielle harmonieuse aidant voire à palier plus
tard à une dégradation logicielle [cfr. modèle d’architecture des 4+1 vues (Philippe Kruchten, 2000)
15
Un logiciel est un produit immatériel, reproductible, maintenable et subjectif dont les seules représentations
observables sont le code source, l'interface utilisateur et la documentation (spécification d’exigences de système,
documents de tests, manuels utilisateur, etc.). Pour être considéré comme un produit de qualité, le logiciel doit donc
répondre aux besoins exprimés explicitement par l'utilisateur aussi bien qu'aux besoins implicites ou non exprimés.
16
L’usage de cette approche modulaire, par une équipe de développement informatique, permet d'assurer au logiciel une
meilleure lisibilité et une meilleure maintenance. Cette approche est voire en phase d’émergence et porte le nom de la
programmation orientée composant. L’on doit noter que dans cette approche de développement par et pour la réutilisation
logicielle, un cycle de production - réutilisation perpétuel (intégration continue) et une architecture logicielle normalisée
est imposé.

10. 10
et modèle d’architecture de 4 niveaux de MDA – Model Driven Architecture ou architecture basée
sur les modèles en français (Xavier Blanc, 2005)].
Ø Gestion des risques
Un projet informatique de développement logiciel, comme dit au début de notre document, présente
des risques que l’on doit maîtriser lors de son exécution. Pour Chantal Morley (2004), cette maîtrise
ou gestion des risques « consiste à réduire l’incertitude par une analyse approfondie des
caractéristiques internes et environnementales du projet et à élaborer des stratégies pour faire face
aux risques plus graves et/ou plus probables ». Pour ce faire, il faudra alors utiliser la démarche
générale qui comprend (1) l’identification des risques, (2) l’évaluation de leur impact possible sur les
coûts, le délai et la qualité, (3) la définition des actions ou la prise des dispositions aptes à réduire les
risques jugés inacceptables, (4) le suivi de ces actions et (5) la capitalisation de l’expérience.
Ainsi, lors des activités de tests par exemple, l’identification des risques sera réalisée voire à partir
des différents éléments analytique du logiciel ou système sous test (cas d’utilisation, processus
métiers, caractéristiques qualité, etc.), en anglais System Under Test (SUT).
Ø Plan de développement logiciel
C’est un document qui décrit, pour une réalisation logicielle, la décomposition en produits
(l’architecture du logiciel, les choix technologiques, les modules ou les composants logiciels -
entrées, sorties et traitement -, la conception des interfaces du logiciel avec l’extérieur -
description des données échangées, de leur organisation en messages, des protocoles d’échanges -
et la conception des bases de données) et en fournitures, les moyens à mettre en œuvre, les tâches
nécessaires et les délais à respecter. Le plan de développement logiciel (PDL), suivant les
recommandations de la norme NF EN ISO 9000-3 qu’on fait appliquer aux activités informatiques
de la norme NF EN ISO 9001, inclut la définition et les objectifs d’un projet, l’organisation d’un
projet et les moyens en personnel, la méthodologie et les phases d’un projet, la gestion d’un
projet et la vérification logiciel.
Section II. La réalisation de logiciels et les exigences de vérification et de validation
a) Activités clés et leurs considérations
Ø La programmation ou l’écriture des codes dans un cycle de développement du logiciel
La programmation constitue l’activité la plus connue et cruciale dans la phase de réalisation. Elle
est appelée voire par certains développeurs ou ingénieurs logiciels « la phase de
développement ». Le Professeur Printz Jacques (2002), en définissant la programmation, parle
voire de l’âme du système informatique ou du logiciel en développement. C’est donc une activité
qui, dans le cycle de développement, incorpore d’autres autres activités qui sont essentielles pour
l’implantation du produit – logiciel à configurer et/ou à installer. Elle est bâtie sur des éléments ci
– après :
- une documentation, basée sur l’expression des besoins, l’exigence des utilisateurs et
la conception détaillée aidant au déploiement et à la maintenance du logiciel ;
- un programme ou module de programme, contenant une suite d’instructions
(algorithmes, structure des données en entrée et en sortie, codes, etc.) exécutables
par la machine ;
- des tests et résultats de série des tests ; et enfin
- un environnement intégré d’exécution ou de développement (IDE17
),
17
Environnement de Développement Intégré, ensemble d'outils intégrés (éditeur de texte, compilateur et débogueur)
dédiés aux langages de programmation pour augmenter la productivité des programmeurs qui développent des logiciels.

11. 11
Modifications
induites
Archivage du scénario et
des résultats
Analyse / Comparaison
des résultats
Analyse et explication
des différences
Spécification du test
Exécution et mise au
point du test
et permet, soit de façon récursive ou itérative, les tests des programmes informatiques qui, une
fois déployé, assureraient au sein d’un système d’information les fonctions nécessaires face au
traitement et au stockage de l’information.
Les différents programmes informatiques sont écrits avec l’aide des L4G (Visual Basic, C#, Java,
Delphi, Python, Turbo Pascal, etc.) et font parfois apparaître des erreurs, dues essentiellement au
caractère humain et à la nature profonde du logiciel lui – même. Ils sont souvent payants ou
gratuits/libres après compilation. Ici, le seul effort à fournir par les acteurs clés du projet, pour
pouvoir obtenir un produit – logiciel fiable et de meilleure qualité, serait de pouvoir corriger ces
erreurs par la mise sur pied d’une série d’activités de vérification et de validation bien ficelées.18
Ces
activités doivent être au service d’une stratégie qui, dans un environnement de développement
logiciel, constitue voire la base d’un processus de tests, c.à.d. la façon dont ses activités de tests
devront être mises en œuvre (figure 2). Le manque de ces activités dans un projet, surtout de type
mixte, peuvent s’avérer coûteux et parfois même dangereux. Il risque même au bout du compte
d’accroître le niveau d’incertitude dans le développement, surtout si l’on décide encore de se lancer
dans les tests sans pouvoir élaborer un modèle de tests.
Fig.2 : Exemple d’un processus simple des tests logiciels incluant certaines procédures (source : Printz Jacques, 2002).
L’implémentation de ces activités de vérification et de validation, depuis l’expression des exigences
jusqu'à la mise en œuvre d’un référentiel normatif de tests, permet d’assurer à la fois la productibilité
des scénarios de test, de mesurer leur qualité et de mieux maîtriser leurs coûts. Elle rentre donc dans
18
La vérification logicielle est formelle ou semi formelle, c.à.d. mathématique ou « exhaustive ». On cherche donc à
prouver au sens mathématique que le logiciel (vue comme un modèle logique) satisfait à sa spécification (vue
comme un ensemble de formules logiques). Cette activité complexe se matérialise soit par des sous approximations
(tests) ou soit par des sur approximations (abstractions). Actuellement, les preuves assistées l’accompagnent aussi.
Objectifs
Scénario Résultats et
comportements attendus
Incorrecte
Dans le test Dans le programme
Résultats et comportements
observés lors de l’exécution
Correcte
Gestion de configuration
(sources, tests et documentation)
Etat d’avancement
des scénarios de tests

12. 12
le cadre des bonnes pratiques dans le développement logiciel. Elle semble être couteuse, cette
implémentation, « … et ce d’autant plus que la combinatoire induite par la structure des données
d’entrée, les modes de fonctionnement autorisés, les différents paramétrages, est totalement
explosive ».19
Ø Le test logiciel : Elément visible et dynamique lors des activités de vérification et de
validation d’un produit – logiciel en développement
Le test logiciel 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 obtenus (IEEE 610.12, 1990).20
Il a pour objectif de faire assurer au MOA (client) que le logiciel développé par le MOE, en
rendant visible sa qualité et/ou sa fiabilité, est correct et fournit, dans le temps imparti, les
résultats sur les entrées sélectionnées. Il fait donc partie intégrante de la vérification21
d’un
produit – logiciel à déployer et/ou à configurer et se clôturent par un bilan. Sa maitrise
s’apparente ainsi à celle du développement logiciel. Dans ce cas, les activités qui sont menées
sont alors inséparables des celles de programmation dont elles constituent une forme de dualité.
Ainsi, le procédé agile XP (eXtreme Programming), par exemple, qui met en avant une pratique
de tests tout au long d’un processus de développement [développement dirigé par les tests (Test
Driven Development)], associe aussi « … les activités de validation qui, à leur tour, essaient de
détecter des fautes ou des inadéquations dans le logiciel en développement » (Gaudel M.C., 1996)
mais aussi obtenir, au final, la confiance nécessaire de l’utilisateur [test d’acceptation par la
clientèle (Users Acceptance Tests, UAT)] avant sa mise en production (sinon un autre Ariane 501
peut se reproduire).22
Ces activités, dites de « contrôle technique » et qui sont à réaliser sont ainsi des
confirmations par des preuves logicielles que les exigences spécifiées au début du développement
logiciel sont satisfaites ou non, suite à leur prise en compte par les acteurs clés du projet. A ce stade,
une procédure connexe de gestion des tests, qui prend en charge la majorité d’aspects de gestion, les
mesures des indicateurs ou des métriques de test et les résultats des campagnes de test, sera voire
planifiée, et devra permettre aux acteurs impliqués à ces activités de mettre en évidence les
dérives éventuelles par rapport aux objectifs de qualité.23
Dans ce contexte, le terme « validé »
désignerait alors l’état correspondant et « valider », la réponse à la question : « est – ce que l’équipe
de développement a fait ou fait le bon produit ? ». Le terme « vérifié », quant à lui, désigne l’état
correspondant et « vérifier », la réponse à la question de savoir si l’équipe de développement a fait
ou fait le produit correctement ?
La vérification, composée des activités de tests (partie prédominante pour les logiciels de faible
taille) et des activités de revues et d’analyses statiques, aura alors pour but « …de démontrer que les
produits logiciels issus d’une phase de cycle de développement sont conformes aux spécifications
(incluant les exigences légales et réglementaires) établies lors des phases précédentes ».
19
PRINTZ Jacques, Op.cit., Page 106.
20
Lors de la réalisation des activités d’agrément, qui intègrent aussi l’exécution des cas de tests, l’on ne tente pas
seulement de démontrer que le logiciel testé ne contient plus d’erreurs mais aussi de corriger les défauts trouvés au moyen
de revue de conception, d’inspection de code, de preuves, etc. Dans ce contexte, le test logiciel ne fait qu’augmenter la
confiance de l’utilisateur sur le bon fonctionnement du logiciel mais ne prouve pas au sens formel sa validité.
21
La vérification, composée des activités de tests (partie prédominante) et des activités de revues et d’analyses statiques,
a pour but « …de démontrer que le produit – logiciel est conforme aux spécifications (incluant les exigences légales et
réglementaires) établies lors des phases précédentes » (Charpentier P., 2000).
22
Cette règle de production ou cette façon d’articuler les nombreux processus nécessaires au développement d’un
produit – logiciel nécessite une certaine maîtrise de référentiels applicables de la part des acteurs.
23
La démarche qualité, comme l’explicite Dominique VAUQUIER (2003), attache une importance particulière aux
activités de vérification et de validation. Sa mise en œuvre est basée sur les principes de symétrie, de séparation, de
spécification et de clôture. Toutefois, lorsque l’on tente d’agréger ses activités à celles de la vérification et de la
validation, la qualité risque de perdre sa spécificité.

13. 13
En somme, les activités de validation et de vérification visent le même but, à savoir l’évaluation de
la qualité des spécifications produites tout au long du développement logiciel (logiciel compris). Les
tests logiciels, qui en font partie, même s’ils représentent 30 à 40 % des coûts de développement
suivant son niveau de criticité, restent la seule technique visible et la plus couramment utilisée pour
s’assurer que le logiciel réalisé est correct et répond aux exigences formulées ou convenues au
départ. Ils tiennent donc un rôle central dans la politique d’assurance qualité d’un produit - logiciel.
La confiance apportée à ses activités dépend en grande partie de la pertinence des entrées
sélectionnées et de la multiplicité de méthodes et d’outils actuellement disponibles sur le marché.
b) Eléments aidant à la vérification et à la validation d’un produit logiciel
Ø Les différents niveaux de tests logiciels
La recherche des défauts ou la détection des erreurs dans un logiciel, comme nous l’avons dit, se fait
préventivement au niveau de chaque phase de son cycle développement. Ainsi, en observant le
modèle de développement du logiciel en V (voir figure 3 ci – dessous), nous observons que les
différentes phases de développement du logiciel, qui sont décrites de manière séquentielle, et par
domaine, sont accompagnées parallèlement des séries de tests.
Fig.3. Les niveaux de tests dans le modèle en V (source : GAUDEL M.C, 1996).
Au fait, quatre niveaux de tests y figurent et sont exécutés tous comme un processus de test au fur
et à mesure que l’on avance dans le développement (programmation de composants, intégration
de composants, conformité avec les exigences, etc.). Ces quatre niveaux définissent voire des
jalons intermédiaires de validation, aidant à s’assurer de la fiabilité du produit - logiciel face aux
besoins exprimés par le maître d’ouvrage dans chaque phase de développement concernée. Ci –
dessous, les explications détaillées de ces niveaux de tests :
- les tests unitaires ou de composants : ils concernent la vérification de chaque
module du logiciel en isolation. Ils ont pour principaux objectifs de vérifier la
mécanique, l’ergonomie et la présentation des programmes, de s’assurer que toutes
les règles sont implantées et de s’assurer du bon fonctionnement des interfaces,
rapports et traitements ;
- les tests d’intégration : Ils concernent la vérification du comportement relatif des
modules entre eux. Les activités principales sont les enchaînements entre modules,
la circulation des données, les aspects dynamiques, les séquences d’événements
prévus (probabiliste) et les reprises en cas d’interruption. Son but est d’activer les
Analyse des besoins
et faisabilité
Spécifications
Conception
architecturale
Conception
détaillée
Tests unitaires
Tests d’intégration
Tests d’acceptation
Installation et tests
système
Programmation

14. 14
fonctionnalités liées à la partie concernée du logiciel partiellement intégrée sur base
des processus opérationnels (du côté utilisateur). Ils sont attachés à la phase de
conception architecturale ;
- les tests de validation ou d’acceptation des fonctionnalités du logiciel : ils
concernent la vérification des fonctionnalités réelles du produit – logiciel décrites
lors de la phase de spécification des exigences. « Ils vérifient plus particulièrement
les fonctions générales, les interfaces matériel / logiciel, le fonctionnement temps
réel, les performances, l'utilisation et l'allocation des ressources » (Charpentier P.,
2000) ; et
- les tests système ou de conformité : Ils consistent à tester le logiciel dans un
environnement similaire à l’environnement de production (vision du concepteur lors
de la phase d’analyse des besoins et de faisabilité). Ici, les revues et les analyses
qu’on fait permettent alors de répondre à la question de correspondance (portée)
avec le logiciel à livrer, ce qui dépasse par moment l'étude des tests du logiciel.
Ces quatre niveaux décrits constituent des groupes d'activités de tests qui sont gérés ensemble, en
rapport direct avec les responsabilités telles que définies dans les différentes phases du projet. Ils
sont souvent exécutés suivant les caractéristiques et les modalités logicielles fixées (performance,
ergonomique, installation, fonctionnelle, robustesse, vulnérabilité, etc.).
Ø Les méthodes et les outils dans les tests logiciels
Les méthodes et les outils, comme nous l’avons mentionné à la section I de la présente
contribution, sont des référentiels de niveau inférieur, classés par secteurs d’activités (logiciels,
production, sécurité, projets, etc.) et qui, au niveau supérieur, deviennent un ensemble de
normes.24
Ils sont choisies spécifiquement en fonction du contexte de projet (développement en
partenariat, en impartition, en interne, etc.) et introduisent la notion de la qualité tout en
contribuant au progrès des pratiques scientifiques soit par une approche de management basée sur
l’amélioration ou sur les processus ou encore la maîtrise documentaire.
Pour les tests logiciels, deux méthodes ou techniques de vérification et de validation existent
actuellement. Elles déterminent le degré de rigueur exigé dans un projet de développement afin
d’éviter les fautes dont le logiciel peut être la cause. Ces sont donc des protocoles expérimentaux qui
provoquent un ensemble de réponses (résidu d'erreurs) qui montrent que la transformation à opérer
par le programme est correcte ou non et sont complémentaires. Il s’agit en fait de :
- méthodes d’analyses statiques : ce sont des techniques qui se réfèrent à l’analyse
d’anomalies, aux lectures croisées, à l’inspection, à l’approximation, etc. qui sont
opérées au moment de la compilation. Elles traitent les tests du logiciel sans
exécuter ce logiciel sur des données réelles et se rapprochent de l’ensemble des
valeurs ou des comportements qui découlent dynamiquement à l’exécution du
programme. Appelées parfois tests statiques, ces techniques sont utilisées pour
vérifier des programmes, dans le but de découvrir des bugs car elles opèrent sur les
codes.
Ces techniques sont aussi particulièrement importantes pour les cas de tests qui
mettent en jeu le parallélisme. Ici, les techniques dynamiques de tests sont parfois
peu applicables en raison du non déterminisme des résultats à obtenir, etc. Le
débogueur de l’IDE Visual Studio est parmi les outils dédié ; et
24
Comme l’énonce Jacqueline Sidi (2003), les normes sont donc des outils plutôt que des exigences inestimables
pour les entreprises. Elles sont utilisables au quotidien dans un contexte opérationnel, mais aussi pour la formation
du personnel qui devra s’approprier le produit – logiciel en développement.

15. 15
- méthodes dynamiques de tests : ces méthodes ou techniques sont souvent appliquées
à des tests de spécifications fonctionnelles ou d’exigences de qualité (robustesse,
performance, etc.) du système. Cette série de tests sont donc des tests fonctionnels
(boite noire), qui ont à charge de vérifier, à partir des certaines valeurs d’entrée, que
les différents comportements du système sont conformes à ses spécifications
(résultats attendus basés sur des valeurs de sortie). Elles reposent aussi sur
l’exécution effective du logiciel, c.à.d. de sa structure interne (boite blanche ou tests
structurels), dans un des ses sous ensemble (codes, description du programme, etc.),
qui est bien choisi du domaine de ses entrées possibles. Ici, les techniques de tests
disposent des quatre activités principales qui sont la sélection (d’un sous ensemble
des entrées possibles du logiciel, appelé jeu de tests), la soumission du jeu de tests,
le dépouillement des résultats et l’évaluation de la qualité des tests effectués. Ces
deux types de tests, fonctionnels et structurels, sont donc complémentaires.
Toutefois, les tests structurels s’accompagnent toujours de tests dits de non
régression qui interviennent toujours après une correction ou une modification de
codes dans un programme et/ou dans un module de programme.
Quant aux outils de tests, qui rentrent dans le même cadre et qui permettent également à l’équipe
de tests de bénéficier en temps réel des indicateurs de pilotage et d’analyse du processus de tests
déclenché, donnant ainsi une image claire et immédiate de la matérialisation des niveaux de tests,
deux catégories existent. Il s’agit des outils de gestion de tests et des outils d’automatisation de tests.
Les outils de gestion de tests sont des exigences et aident les membres d’une équipe de
développement de s’assurer de l’atteinte des objectifs V, V, T (Validation, Vérification et Test) sur
le comportement attendu du produit – logiciel. Ils donnent, suivant les règles de l’art, la possibilité
de produire des livrables observables (documents types ou résultats de tests sous forme
documentaire). Le plan de tests, qui correspond à une description détaillée de cas de tests (sur base
des exigences métiers), de stratégies arrêtées et de certains documents enregistrant les événements
lors de tests et les décisions prises25
, font partie de ces outils de gestion de tests. Les modèles de tests
logiciels que ces outils accompagnent sous souvent effectués manuellement. Par contre, les outils
d’automatisation de tests, considérés hors du périmètre des outils de gestion de tests, effectuent des
types de tests qui sont impossibles à effectuer manuellement. Ils améliorent, eux, la productivité et le
rendement attendus sur les tests, principalement les tests unitaires, les tests d’intégration et les tests
de non régression. HP QuickTest Professional, Silk Test de Borland, Visual Studio Unit Testing
Framework (MSTest.exe), Pex (Microsoft), Test partner, Refertest, etc. sont comptés parmi les outils
dits d’automatisation de tests et remédient au principal facteur d’échec par une maintenabilité des
scripts (un bout de code qui teste un autre code automatiquement).26
Toutefois, d’une manière générale mais aussi professionnelle, pour utiliser ces outils aidant à la
vérification mais aussi à la validation d’un produit – logiciel en développement, l’on doit évoquer
d’abord la problématique d’exigences qui devra décrire, au fait, les liens de causalité relatifs à une
action du logiciel. C’est ainsi qu’avec l’esprit d’agilité recommandé actuellement dans l’exécution
de projets informatiques de développement logiciel (réduction de coût et de délai, performance et
25
La décision est souvent déclenchée dans un projet par les problèmes d’ordre organisationnel que les managers
rencontrent. Elle est donc prise, selon Simon H.A. (1980), grâce au processus dit IMC (Intelligence – Modélisation –
Choix).
26
Un script de test reste l’approche de succession d’opérations manuelles la plus naturelle pour l’exécution par
exemple d’un cas de test sur un logiciel simple car une fois lancé, on clique partout et on regarde s’il fonctionne.
Cette approche est essentielle « …pour détecter des erreurs et améliorer la confiance dans l'aptitude du système à
accomplir sa mission, mais insuffisante pour qualifier le comportement d'un système » (Charpentier P., 2000). On
trouve à ses côtés des bancs de test pour des systèmes plus complexes.

16. 16
réactivité puis qualité), les équipes expérimentées de développement logiciel, qui utilisent les
procédés agiles (XP, RUF, SCRUM, etc.), commencent aussi à utiliser dès la phase de spécification
ces outils de tests cités, en se basant sur des exigences évoluant27
ou changeant durant tout le long du
cycle de vie du logiciel (Lydie du Bousquet, 2010). Ainsi, les cas de test à générer manuellement ou
automatiquement, qui matérialisent la cohérence et/ou la traçabilité entre les éléments des différents
artefacts produits par les différentes activités d’un processus de développement, constituent alors un
modèle28
comportemental de logiciels sous test, ou tout simplement un modèle d’exigences (Jean-
Marc Jézéquel, 2006, Xavier Blanc, 2005, etc.). Ces modèles comportementaux de logiciels sont
construits à partir des exigences ou des spécifications textuelles qui peuvent être fonctionnelles
(fonctions spécifiées pour le logiciel, point d’entrée ou de sortie de la phase de spécification) ou
structurelles (fonctions codées dans le logiciel).
Ø Les exigences fonctionnelles, des outils normatifs non négligeables lors de l’élaboration
d’un modèle de tests de logiciels
Les exigences ou les spécifications constituent, dans une modélisation, des contraintes que le
MOE devra respecter lors des tests dans le but de faire disposer réellement au MOA le produit
qu’il souhaite et/ou qu’il souhaitait. Elles sont produites, ces exigences, à partir des activités de
collecte, rédaction, compréhension et évaluation en amont de besoins métiers des utilisateurs.
Cette série d’activités indépendantes, liées à l’ingénierie des exigences mais aussi à l’ingénierie
des modèles, est donc vue comme un processus de raffinement itératif mais aussi de
modélisation, à l’aide de langages munis d’une sémantique formelle (UML par exemple car il
permet la modélisation de systèmes indépendamment de toute démarche ou de plate – forme). Au
fait, ce processus se termine lorsque les exigences sont suffisamment précises ou reformulées par
le MOE pour ainsi appliquer les techniques de vérification et de validation dans un système sous
test. Cette matérialisation de l’IDM va produire un modèle qui sera utilisé pour répondre à des
questions sur le système modélisé. Il ressort de cette logique de substitution que ces exigences
reformulées, à vérifier sur un produit – logiciel visant la qualité, expriment un modèle dynamique
d’exigences (Computation Independent Model, CIM) et directement opérationnel pour d’autres
phases de développement du logiciel. Ainsi, ce modèle d’exigences va à son tour donner corps à
un modèle de tests système et à un modèle d’analyse ou à des modèles extra – fonctionnels
(Platform-Independent Model – PIM). Cette transformation de premier niveau, qui garantit les
liens de traçabilité entre les modèles et les besoins exprimés par le client, est essentielle suivant
l’approche MDA (architecture à 4 niveaux) à la pérennité des modèles. Ainsi, les techniques de
vérification et de validation, comme explicité dans les points précédant, qui sont basées sur les
stratégies de tests, vont s’appuyer sur le modèle d’exigences pour définir les algorithmes et les
critères de sélection des cas de test à réaliser sur un système sous test.
Derrière cette approche formelle ou semi formelle (MDA), dite aussi « de transformation de
modèles » (figure 4), le modèle d’analyse et/ou les modèles extra – fonctionnels (Platform-
Independent Model – PIM), qui sont des captures de plusieurs informations relatives au domaine
métier, initialement dispersées dans une collection de données d’entrée (besoins des utilisateurs,
processus métiers, etc.), donneront corps à leur tour à un modèle de conception (Platform-
Independent Model – PIM et Platform Specific Model – PSM) mais aussi à un codage du système
(Platform Specific Model – PSM). Cette étape est voire nécessaire pour démarrer avec les tests de
27
On ne peut éviter l’évolution des exigences. La seule chose à faire c’est de chercher à maintenir leur traçabilité.
28
Un modèle est une représentation ou une description d’un logiciel ou d’une partie d’un logiciel dans un langage
bien défini mais à des différents niveaux d’abstraction. L’Ingénierie Dirigé par les Modèles (IDM), Model – Driven
Engineering (MDE), en anglais, qui est son paradigme de modélisation plaçant les modèles au cœur du processus de
développement pour en faire les éléments clés par lesquels les logiciels sont générés, décrit un logiciel avec un haut
niveau d'abstraction indépendamment de la plate – forme utilisée, d'un point de vue utilisateur. Il s’appuie sur
l’initiative MDA (Model – Driven Architecture), menée par l’OMG (Object Management Group).

17. 17
niveau inférieur (unitaires et d’intégration) permettant d’affiner la structure et l’état interne du
système sous tests. Ici, on peut alors se servir des techniques MBT (Model-Based Testing (MBT),
qui se situent pour la plupart de cas au niveau des activités inférieurs de tests (tests unitaires et tests
d’intégration), pour générer et exécuter, au moyen des algorithmes, soit par génération aléatoire de
codes ou soit par prédicat de chemin, ou encore par exécution symbolique des chemins ou par
exécution concolique, les cas de tests d’un logiciel sous test mais aussi améliorer la détection des
bugs, la qualité logicielle, la traçabilité et l’évolution des exigences reformulées.
Fig.4. les transformations de modèles dans un cycle de développement (source : Jézéquel J.M, 2006)
Quant au modèle de tests systèmes, qui exprime une vision externe des gestionnaires ou des
utilisateurs sur les actions réalisables ou les comportements attendus d’un logiciel sous test, c’est
un modèle pérenne et productif (PIM) qui est donc constitué par une abstraction des informations
relatives aux interactions de l’utilisateur sur le système (cas d’utilisation, scénarios d’utilisation,
etc.) dans le but de prouver manuellement ou automatiquement la qualité du logiciel sous test.
Toutefois, dans l’ensemble, plusieurs méthodologies dites formelles ou semi formelles, suivant la
taille et le type de projet, permettent l’élaboration de modèles de tests, que ça soit au niveau
supérieur ou au niveau inférieur. Ces méthodologies servent donc des modèles d’entrée aux outils
d’analyse (choix de critères de sélection de test) une fois exempt d’incohérences statiques ou
dynamiques afin de pouvoir générer les cas de tests et permettre leurs exécutions dans un logiciel
sous test. Ainsi, la méthodologie UML29
, qui transforme certains modèles avec l’aide de ses
diagrammes et du langage d’expression de contrainte OCL, permet la simulation au niveau de
conception de codes, rendant le système beaucoup plus sûre puisque des tests de débogage (tests
unitaires et d’intégration) auront été́ faits avant la compilation de codes. Cette même
méthodologie permet aussi de tester les comportements d’un système sous test (tests de niveau
29
A proprement parler, le formalisme UML intègre le langage OCL (Object Constraint Language) qui est un langage
d’expression ou de haut niveau d’abstraction permettant de décrire des contraintes sur des modèles objet. Une
contrainte est une restriction sur une ou plusieurs valeurs d’un modèle non représentable en UML. OCL donne ainsi
des descriptions précises et non ambiguës du comportement du logiciel en complétant les diagrammes UML et en
définissant des pré-conditions, des post-conditions ou des invariants pour une opération. Ainsi, pour élaborer un
modèle de test ou de niveau supérieur, l’on ne devra pas reprendre toutes les phases conceptuelles de développement
mais certains diagrammes UML (cas d’utilisation, de séquence et d’activité) dont les éléments servent de support de
matérialisation des relations d’instanciation avec les éléments de modèle d’exigences.

18. 18
supérieur) mais aussi permettre son déploiement et sa configuration complète. Ceci se fera bien
sûr indépendamment du langage30
et de la plate-forme cible puis séparera le contenu logique de la
présentation physique.
Ø Efficacité de tests logiciels dans un projet informatique de développement logiciel
L’efficacité est un concept très complexe, floue, instable, polymorphe et polysémique qui est
souvent souhaitée lors des activités de vérification et de validation qui sont les deux approches
utilisées pour les tests logiciels. Ainsi, dans notre contexte, l’efficacité souhaitée pour une série de
tests logiciels dépend crucialement de la qualité des cas de tests et des données de tests générés
manuellement ou automatiquement mais aussi de la démarche de tests qui se doit donc de respecter
plusieurs impératifs : la définition des politiques définissant les modalités d’applications de ces tests
(planification dans les différentes phases du cycle de vie du logiciel, fréquence et conditions
d’exécution, rôle de chaque membre de l’équipe), le déploiement de l’infrastructure (matérielle et
logicielle) permettant la mise en œuvre de ces politiques ainsi que les processus assurant le contrôle
du respect des politiques, l’environnement matériel et de développement pour l’intégration
fonctionnelle et la mise en œuvre de tests et ensuite l’expertise nécessaire de l’équipe pour la gestion
du plan de tests, la création de données fonctionnelles et de tests.
L’efficacité de tests, c’est aussi le modèle de tests lui – même, généré à partir d’un modèle
d’exigences, qui doit se conformer aux procédures et aux conditions préalablement définies au
début d’un processus de développement (omniprésence ou pas) dans le but de pouvoir disposer
d’un logiciel fiable.
c) Quelques autres définitions clés relatives aux tests.
La stratégie de tests
C’est un préalable nécessaire pour la mise en place des objectifs de tests. Elle témoigne donc
d’une réflexion sur la pratique réelle des tests (conception de cas de test, écriture de scripts de
test, fourniture de données de test, observation et analyse résultats de test et rédaction d’une
documentation associée pour le test, etc.), visant à augmenter la fiabilité du produit – logiciel et à
diminuer les défauts dus à sa programmation (objectif qualité). Son absence, comme dit
Charpentier P. (2000), indique un risque d’improvisation pour les tests mais aussi pour les autres
phases du développement logiciel.
L’obligation de test
C’est une spécification partielle de test qui décrit une propriété jugée importante dans un contexte
donné.
Le cas de test
C’est le chemin fonctionnel à mettre en œuvre pour atteindre un objectif de test. Il spécifie donc la
manière dont une fonction ou une combinaison de fonctions (scénario de test) doit être testée ou dont
il convient qu’elle le soit.
Le scénario de test
C’est un ensemble autonome et cohérent d’interactions avec le logiciel regroupant un ou plusieurs
tests élémentaires, et les éventuelles phases préparatoire et finale de ces tests élémentaires. Ici, le
cycle de vie pour ces tests logiciels va se fabriquer en fonction des objectifs qui résultent de la
stratégie de vérification et de validation adoptée et des informations disponibles pour exécuter des
scénarios de cas d’utilisation, mais aussi les différentes exigences qui y sont rattachés.
30
Notons qu’en dehors de l’UML, l’IDM utilise aussi d’autres langages de modélisation qui sont dédiés à un domaine
particulier. Le DSL (Domain Specific Language – DSL) par exemple offre aux utilisateurs des concepts propres à leur
métier (le métier dont ils ont la maîtrise).

19. 19
Les preuves logicielles
La preuve démontre et/ou établit la vérité de quelque chose. C’est donc une opération mathématique
par laquelle on contrôle l’exactitude d’un calcul ou la justesse de la solution d’un problème. Dans le
domaine de développement logiciel, la preuve s’utilise à des différentes fins basées sur les méthodes
formelles car un système ou un logiciel à vérifier et/ou à prouver doit être soit formel ou semi-
formel.31
Malgré cela, lorsqu’on procède à ces preuves logicielles, au moyen des outils assistés, le
test défini sert seulement à démontrer sur une spécification ou une exigence qu’une certaine situation
se produira toujours ou ne se produira jamais. Ainsi, avec le regain actuel des pratiques de
génération automatiques de tests structurels, les solutions MBT, qui génèrent et prouvent
automatiquement des spécification ou des exigences, risquent de faire retrouver la communauté
scientifique face à un problème d’indécidabilité (à ce jour, il n’y a pas encore de script capable de
prouver automatiquement la correction de tout logiciel, Ivinza Lepapa A. C. et Mbuta Ikoko D. A.,
2006).
Parmi les types de preuves existants, nous pouvons citer les preuves de conception, de
programmation et en pratique.
III. ELABORATION D’UN MODELE DE TESTS POUR LE PAYMENT MANAGER
Section I. Démarche pour l’élaboration du modèle de tests
a) Objet et démarche d’élaboration de l’ébauche
Nous comprenons, tel que décrit dans l’introduction, que l’objet de notre contribution concerne
l’incitation d’usage, par les professionnels TI congolais, des méthodes, outils et techniques
d’ingénierie logicielle et d’exigences, classiques ou agiles, pour la vérification et la validation d’un
produit – logiciel. Au cours des points précédents, nous avons essayé de présenter globalement les
éléments qui rentrent dans les caractéristiques d’un projet informatique de développement logiciel en
général et mixte en particulier, pour pouvoir produire efficacement un bien livrable (produit –
logiciel) respectant les critères de qualité mais aussi ceux de réactivité et de performance contraints
par les budget et délai imposés. Ces éléments concernaient particulièrement les tests logiciels, ses
méthodes et outils, mais aussi les exigences aidant à élaborer des modèles de tests. A ce niveau, une
présentation cavalière des exigences fonctionnelles ou structurelles dans le contexte d’ingénierie
dirigée par les modèles, suivant l’approche MDA (support indispensable de génération de code, de
documentation, de tests etc. directement depuis les modèles), a été effectuée où nous avons listé les
différentes phases de transformation de modèles permettant d’aboutir à un modèle de tests de niveau
supérieur ou de niveau inférieur. Le modèle de tests de niveau supérieur nécessite généralement
l’intervention d’un expert pour effectuer certaines étapes de la transformation tandis que le modèle
de tests de niveau inférieur fait l’objet d’outils de tests automatiques qui se servent des processus
stochastiques pour générer de façon automatique les cas de tests mais aussi améliorer la détection
des bugs, la qualité logicielle, la traçabilité et l’évolution des exigences. UML, en y ajoutant les
contraintes OCL, est présenté comme une approche favorite pour sa matérialisation.
Maintenant, nous allons essayer de produire l’ébauche d’un modèle de tests de niveau supérieur sur
base de notre retour d’expérience comme chef de projet « IDENT - ITS », un projet mixte conduit
suivant les procédés agiles combinés, XP et Scrum, pour produire un logiciel de qualité dans le délai
exigé, 5 mois environs. Cette ébauche est donc produite grâce à un ensemble de questionnements
d’ordre managérial et organisationnel suivant une démarche de concrétisation manuelle nécessitant
31
Dans un système à configurer et/ou à installer, la preuve d’une formule est une dérivation, c’est - à – dire une suite de
formules qui se termine par la formule à prouver, et telle que la première formule est un axiome. Toute autre formule est
soit un axiome, soit la conclusion d’une règle d’inférence dont les prémisses apparaissent avant elle dans la suite.

20. 20
notre expertise tant au niveau de la connaissance de l’architecture interne du système que celui de la
connaissance des interfaces réelles du système. Cette démarche est en partie la réponse aux efforts de
membres de l’équipe du projet lors du processus de développement du logiciel « Payment
Manager ». Elle intègre et détaille ainsi l’ensemble des règles métiers de paiement décrits dans le
cadre de DDR (règles de gestion, cas et scénarios d’utilisation) et les exigences spécifiées pour les
tests logiciels et certains éléments de stratégie de tests qui, formellement, devraient se retrouver dans
un plan de tests.
Les tests logiciels étant une activité créatrice qui exige une moyenne des compétences de la part des
acteurs impliqués, il existe donc plusieurs aspects à considérer. D’abord l’aspect qui s’attache à la
structure du système sous test (SUT), telles que ses structures de données, son code, etc. et ensuite,
celui de la dynamique du système sous test (tests système et de validation via l’approche dite « boite
noire »), représenté généralement par le biais d’interfaces implémentées. C’est sur ce deuxième
aspect que nous nous focalisons. La méthodologie UML, utilisée dans la formalisation de besoins
des utilisateurs, de processus et de règles métiers mais aussi d’identification de cas d’utilisation en
exigences de tests puis en cas de tests, a été plus qu’une phase de conception pour produire notre
ébauche de modèle de tests. C’est pourquoi elle ne sera pas détaillée dans sa totalité. Toutefois, nous
illustrons partiellement quelques éléments et quelques interfaces de l’applicatif renforçant les
résultats attendus sur des cas de tests conçus.
Les lignes qui suivent exposent donc quelques points essentiels de ce modèle, qui donnent corps aux
notions abstraites décrites aux points II.
b) Référentiels normatifs utilisés
Ø Documents normatifs
Les documents normatifs clés ci – dessous ont été d’une grande utilité lors de l’élaboration de notre
modèle de tests car certaines de ses lignes avaient servi lors des activités menées tout au long du
processus.
AFNOR, 1995
[12207] NF ISO/CEI 12207:1995 (F)
Traitement de l’information – Ingénierie du logiciel – Processus du cycle de vie du logiciel
AFNOR, 1996
[NF X 50-164] NF X 50-164
Relations clients – fournisseurs – Guide pour l’établissement d’un plan d’assurance qualité.
AFNOR, 1999
[9000-3] NF EN ISO 9000-3:1999 (F)
Normes pour le management de la qualité – Partie 3 : Lignes directrices pour l’application de l’ISO
9001 au développement, à la mise à disposition et à la maintenance du logiciel
AFNOR, 2000
[8402] ISO/CEI FDIS 8402 (E)
Software Quality Metrics Methodology
ISO/CEI, 1998
[15288] NF ISO/CEI 15288 :2002 (F)
Traitement de l’information – Ingénierie du logiciel – Processus du cycle de vie des systèmes
ISO/CEI, 1998
[15846] NF ISO/CEI 15846:1998 (F)
Gestion de configuration du logiciel
ISO/CEI, 1999
[NF LOG] NF LOGICIEL
Règlement de la marque NF Logiciel – Exigences pour le dossier de test du logiciel – Annexe 1.2

21. 21
ISO/CEI, 1999
[9126] NF ISO/CEI 9126:2000 (F)
Technologies de l'information – Qualité des produits logiciels – Partie 1: Modèle de qualité
IEEE, 1990
[IEEE 610.12] IEEE 610.12 :1990
Standard Glossary of Software Engineering Terminology
IEEE, 1998
[IEEE 1233a] IEEE 1233a :1998
Guide de l'IEEE pour la Spécification d’Exigences de Système
[ANSI/EIA 632] ANSI/EIA 632: 1999
Processes for Engineering a System
IEEE, 1999
[IEEE 1220] IEEE 1220 : 1999
Standard for application and Management of the Systems Engineering Process
IEEE, 2008
[IEEE 829] IEEE 829 : 2008
Standard for Software and System Test Documentation
Ø Documents produits
Les documents ci - dessous, produits par le projet, ont servi tout au long du processus de
développement de ce logiciel. Dans le cadre d’élaboration de notre modèle de tests, ils ont eu aussi
un regard critique.
[CCEB] Cahier des Charges et de l’expression des besoins
[PDL] Plan de Développement Logiciel
[PGT] Plan Global de Travail
[MP] Macro Processus des différentes phases d’IVO (Identification, Vérification et Orientation)
[DSFT] Document de Spécifications Fonctionnelles et Techniques
[LRI] Liste des Risques Inhérents
[DALM] Document d’Architecture Logicielle et de Maintenance
[DCL] Document de Conception Logiciel
[MU] Manuel de l’Utilisateur
[PFD] Plan de Finalisation de Développement (sur les amendements)
Dans certains cas de figure (clauses contractuelles ou autres), ces documents constituent aussi une
conditionnalité avant la mise en exploitation du logiciel.
c) L’équipe de tests : responsabilités et rôles
Le tableau ci – dessous indique les tâches requises et/ou définies pour les tests de « Payment
Manager ». Il indique aussi les différentes fonctions allouées initialement pour chacune de tâches à
couvrir.
Fonctions Tâches Noms des entités impliquées
Responsables métiers Observation sur les tests CELPAY, BIO – ID et UEPN –
DDR
Responsable de tests Garant de tout le processus d’exécution et de suivi
de tests, définition de la méthodologie et de la
stratégie de tests
UEPN - DDR
Architecte de tests Réalisation de l’architecture de tests, critique des
scénarii des tests et rédaction de dossiers et
rapports sur les tests
CELPAY, BIO – ID et UEPN –
DDR
Concepteurs de tests Rédaction des exigences de tests, spécification et CELPAY, BIO – ID et UEPN –

22. 22
fourniture des cas de tests, … DDR
Programmeurs ou
Testeurs
Codage, réalisation de chaque niveau et type de
tests et consignation de résultats de tests
CELPAY, BIO – ID et UEPN –
DDR
Section II. Eléments d’élaboration du modèle des tests pour le « Payment Manager ».
a) Considérations générales
Ø Le maître d’ouvrage du projet TI assurant le développement de « Payment Manager »
Le Désarmement, la Démobilisation et la Réinsertion, en sigle DDR, a un caractère multisectoriel et
exige une grande capacité de coordination politique, stratégique, opérationnelle et technique.
Le cadre institutionnel de cette structure au niveau de la RDC, connu sous le nom du Programme
National de Désarmement, Démobilisation et Réinsertion (PNDDR), est défini par le décret
n°04/092 du 16 octobre 2004 puis, bien avant, par les décrets n°03/041, 03/042 et 03/043 du 18
décembre 2003, portant création du Comité Interministériel chargé de la conception et de
l’orientation en matière de DDR (CI-DDR), de la Commission Nationale de DDR (CONADER) et
du Comité de Gestion des Fonds de DDR (CGFDR). Le CI-DDR assure aussi le suivi et la
coordination des activités du comité technique de planification et de coordination du DDR
(CTPC/DDR).
Au mois de juin 2007, le décret portant création, organisation et mise en place de la CONADER a
été abrogé et remplacé par un nouveau décret n°07/057 du 14 juillet 2007. Ce nouveau décret créant
et organisant l’Unité d’Exécution du Programme National de Désarmement, Démobilisation et
Réinsertion, UEPN-DDR en sigle, marque la fin de la première phase (2003 à 2007) et le début de la
seconde phase du PNDDR. Cette structure a donc remplacé la CONADER et a pour mission le
parachèvement du processus DDR en RDC. La portée stratégique de l’UEPN-DDR est celle (1)
d’Elaborer les critères de désarmement, démobilisation et proposer les mécanismes de Réinsertion ;
(2) de Planifier les activités en rapport avec les processus de Désarmement, Démobilisation et
Réinsertion et (3) d’Exécuter et parachever le PN-DDR. Maître d’ouvrage (délégué) du
gouvernement congolais en la matière, elle est donc rattachée au Ministère de la défense nationale et
des anciens combattants mais travaille étroitement avec les autres services compétents de l'État, de la
société civile (Institutions nationales, ONG locales, etc.) et les partenaires extérieurs (Agences du
système des Nations Unies, ONG internationales, Agences de coopération bilatérale, etc.).
L’UEPN-DDR est dirigée par un Administrateur Général, assisté des experts et spécialistes recrutés
selon les règles et les procédures de la Banque Mondiale et de la Banque Africaine de
Développement. La gestion fiduciaire est assurée par KPMG / RDC. Cette combinaison de rôles fait
disposer à l’UEPN – DDR d’une culture d’entreprise, non traditionnelle, influencée par les pratiques
institutionnalisées congolaises.
Ø Le système d’information du maître d’ouvrage, les différents processus métiers et le profil de
l’équipe TI assurant le développement de « Payment Manager »
Le système d’information de l’UEPN – DDR, issu des cendres de la CONADER, est resté organisé
autour des plusieurs processus métiers dont trois en représentent le cœur. Il s’agit au fait :
- du processus d’enregistrement ou identification des ex combattants désarmés
(identification avec capture de l’iris sur l’applicatif « Ident – Congo ») ;
- du processus de paiement des ex combattants désarmés et démobilisés (indemnité
transitoire de substance à donner à l’ex combattant via la technologie de paiement
électronique par mobile) ; et
- du processus de réinsertion socio économique des ex combattants désarmés et
démobilisés (Allocations des bénéfices pour une réinsertion viable avec l’aide d’un
applicatif de suivi de réinsertion, « ASR »).

23. 23
Ces trois processus métiers bénéficient d’une gestion intégrée informatisée, par le biais d’une
infrastructure technologique (Data center) implémentée par la fonction « système d’information »
de l’UEPN – DDR, aidant à la centralisation, synchronisation et traitement des données issues des
activités d’identification, de paiement et de réinsertion. Quant aux autres processus de gestion liée
aux fonctions horizontales du programme (administrative, financière, budgétaire et logistique), ils
sont opérationnalisés au sein de l’infrastructure technologique grâce aux applicatifs et outils
standards tels que le Tom pro, l’Office intégrale de Microsoft, l’ISA Server, le Rancid, le Request
Tracker / Trac, l’IPcop, etc. tournant sous environnement Microsoft et/ou Linux.
Le département MIS : Management Information System, qui sert de maître d’œuvre technologique
de l’UEPN – DDR, assure la gestion de cette fonction « système d’information » mis en place et
intègre trois de cinq rôles de Guy Paré et de Guillemette Manon (2005) sur la fonction TI, à savoir la
fourniture des systèmes, la conception d’infrastructure technologique et la coordination de projets
TI. Les ressources faisant partie de cette fonction organisent ses activités avec l’aide de deux
partenaires clés : BIO-ID Technologies SA (impartiteur proposé par les bailleurs de fonds pour son
expertise comme intégrateur de la technologie iris dans les différentes solutions informatiques mises
en place par le département MIS) et CELPAY RDC Inc. (partenaire proposé par les bailleurs de
fonds pour la paie des ex – combattants démobilisés).
Ø Règles clés de gestion en rapport avec le processus de paiement
Lors de la première phase du programme DDR (2004 – 2007), le processus de paiement au niveau
d’un site d’enregistrement ou de paiement reprenait les entités et/ou acteurs suivants : Bio – ID
Technologies (Gestionnaire de base de données et Opérateurs de saisie), CELPAY (Agents
payeurs) et UEPN – DDR (Superviseur). Ce processus a été modélisé avec l’aide d’un
diagramme d’activité. Les règles clés de gestion sur ce processus de paiement renfermaient les
bases suivantes :
- « Un ex combattant ayant choisi la démobilisation, après son identification
biométrique avec capture iris dans un centre d’orientation, reçoit en numéraire une
et une seule fois un montant de 110 $ USD » ; et
- « Après son installation effective dans la communauté qu’il aurait choisi, l’ex
combattant démobilisé va être accompagné dans sa réinsertion par l’octroi de 300 $
USD en douze tranches de 25 $ USD et de certaines autres bénéfices (formation,
outils, etc.) ».
La formalisation de ces règles clés de gestion sur le processus avait produit des procédures (cas
d’utilisation) aidant à son opérationnalisation effective. Nous citons ici la constitution et la
validation de listes de paiements, générées à partir données biométriques d’identification
synchronisées au niveau du Datacenter, la transmission de ces listes par centre d’orientation à
l’agent payeur, la présentation de la carte de démobilisation sur le site d’identification ou de
réinsertion par le démobilisé pour être payé, les réponses aux questions types pour s’assurer de
l’authenticité du démobilisé bénéficiaire, etc. La paie aux ex – combattants de ces Indemnités
Transitoires de Subsistance, dits « ITS », est donc assurée avec l’aide d’un applicatif de CELPAY
via mobile.
Ø Contexte de développement et exigences textuelles de « Payment Manager »
A la fin de la première phase du programme, suite aux critiques du maître d’ouvrage sur la non
performance de l’applicatif de paiement de CELPAY (manque de couverture téléphonique dans
certains coins du pays, etc.) mais aussi les recommandations de ses partenaires et l’audit d’Ernst &

24. 24
Young France de 2006, en rapport avec le dysfonctionnement de l’applicatif de CELPAY dans
l’environnement congolais causant un léger écart avec la cible définie dans le document initial du
programme, un besoin d’amélioration du processus de paiement était est né. En tant que Spécialiste
MIS et chef de projet d’intégration informatique, (« IDENT – ITS » : identification, paiement et
réinsertion), de l’UEPN – DDR, nous avons soumis, ensemble avec les chargés de projet de
l’impartiteur (Bio – ID Technologies SA) et de l’agent payeur (CELPAY RDC Inc.), sur base de
notre retour d’expérience dans cette première phase du PNDDR, une proposition en rapport avec les
nouvelles procédures envisagées et les besoins visant l’amélioration de l’ensemble du processus de
paiement. Après la décision du maître d’ouvrage, les règles clés de gestion devenaient alors :
- le paiement de 140 $ USD à l’ex – combattant lors de la démobilisation, au lieu de
110 $ USD ;
- le paiement de 300 $ USD d’accompagnement en deux tranches de 150 $ USD sur
une période de 2 mois, au lieu de 25 USD sur une période de 12 mois. La première
tranche de paiement de 150 $ USD est payée à l’ex combattant démobilisé un mois
après le paiement de 140 $ USD, et après son enregistrement et son référencement
dans une de nos agences de liaison en provinces. La deuxième tranche 2 mois après
Dans cette redéfinition de l’ensemble du processus de paiement des ex – combattants démobilisés, il
est donc question :
- de disposer un système logiciel qui va permettre au PNDDR de pouvoir garantir le
paiement des ex – combattants démobilisés sans tentative de fraude ;
- que ce système logiciel de paiement, y compris les équipements qui
l’accompagnent, soit opérationnel et capable de satisfaire aux différentes règles de
gestion établies par le PNDDR ; et
- que les règles définies le long du processus de développement soient respectées.
En effet, ce système logiciel, nommé « Payment Manager », remplace donc l’applicatif de paiement
électronique avec mobile de CELPAY RDC Inc. Il est développé par l’impartiteur BIO – ID
Technologies SA et la fonction TI de l’UEPN – DDR sous Visual Basic.Net 2005, opérationnalisé
sous Microsoft XP Professionnel /SP2 que ça soit en simulation ou en production, et intègre un
module de contrôle et/ou d’authentification par capture et/ou contrôle iris. Son but principal reste le
paiement des ex combattants démobilisés dans le cadre du PNDDR en RD Congo.
Il est utilisé par l’entreprise CELPAY RDC Inc., qui a reçu mandat des bailleurs, depuis la première
phase du PNDDR, de payer les ex – combattants éligibles. Son architecture logicielle est composée
des fichiers de modules, modules de classes, fonctions, macros intégrés (threads ou processus),
tables, requêtes, formulaires (voir figure 5). Le Crystal Report, avec l’aide de ses composants,
matérialise son côté rapportage. Notons que certaines lignes codées, pour ce système logiciel, sont
des anciennes briques de code conservées dans les bibliothèques de développement de BIO ID et de
MIS CONADER.
Fig.5. Architecture logicielle de « Payment Manager ».
Laptop or desktop
DataUser
Interface
Remote Object
Remote
Business
Object
Business
Object
handler
Remote
Scan Object
Scan
Object
handler

25. 25
Ici, l’agent payeur (agent de CELPAY), qui sera l’utilisateur de ce système, devra disposer de
l’argent dans sa caisse avant de démarrer une campagne donnée de paiement (il devra au moins
avoir un montant pour une journée de paie selon le cas). Il ne procède au paiement de l’ex –
combattant démobilisé que via le système. Si sa caisse devient vide, la campagne de paiement
amorcée devra être reportée. Un paiement effectué par l’utilisateur du système et confirmé dans
ce dernier n’est plus révocable. En plus, tout agent payeur impliqué dans le processus de paiement
devra être inscrit comme utilisateur dans le système, par l’installateur du système (Agent BIO – ID
ou MIS), par une capture de son iris puis formé à son utilisation. Les enregistrements (données
biographiques et iris) de démobilisés sensés être payés, qui se trouveraient dans la base de données
de l’applicatif d’identification « Ident – Congo » devraient se retrouver dans le système de paiement,
soit par synchronisation en temps réel avec le système d’identification au niveau du site
d’identification ou soit par importation au niveau de site de paiement se trouvant au sein de la
communauté de réinsertion. Les enregistrements d’un agent payeur inscrit dans le système par
l’installateur sont synchronisés dans tous les systèmes disponibles et opérationnels pendant les
campagnes de paiement.
L’installateur du système, qui inscrit et donne accès aux autres utilisateurs (ici l’agent payeur) dans
le système, est inscrit lui – même lors de son installation. A chaque fois qu’un agent inscrit dans le
système devra le manipuler, une authentification avec son iris sera requise. Toutefois, en cas de
problème d’iris survenant lors de son authentification, un mode dégradé sera disponible (cf. plan de
contingence). Il s’agirait en effet à l’utilisateur d’accéder et/ou de s’authentifier via l’IDcode généré
lors de son inscription dans le système par l’administrateur. L’installateur a, lui aussi, son IDcode,
généré lors de l’installation et de son inscription comme super utilisateur dans le système. Quant à
l’ex – combattant démobilisé, qui devra percevoir son ITS, son IDcode est repris sur la carte
imprimée puis lui délivrée lors de son enregistrement dans le système « Ident – Congo » au niveau
du site de son identification. Il devra répondre au besoin à des questions de précision posées par
l’agent payeur mais aussi signer toujours un document attestant le paiement (140$ ou 150$) qu’il a
reçu.
Certains éléments repris ci – dessus constituent les bases servant pour identifier les acteurs clés et
leurs différentes interactions dans le système à développer. Ils ont été en partie repris, sous forme
d’une modélisation détaillée dans la phase conceptuelle avec l’aide des diagrammes UML de
contexte, de cas d’utilisation, de séquence, de classes et d’objets non repris ici schématiquement.32
Toutefois, ci – dessous, nous présentons les éléments clés de notre diagramme d’utilisation :
- Pour l’administrateur (agent installateur), (1) installer le système ; (2) s’inscrire et
inscrire les autres utilisateurs du système tout en définissant leurs profils et enfin (3)
maintenir en état le système ;
- Pour l’utilisateur (agent payeur), (1) démarrer ou ouvrir le système ; (2) s’authentifier
avec son iris ou avec la saisie de son IDcode dans le système pour procéder aux
opérations de paiement ; (3) mettre à jour ou synchroniser les données des ex –
combattants démobilisés provenant de l’applicatif d’identification (Ident – Congo)
et/ou importer à partir du site ftp (Internet) les différentes données cryptées de
paiements réalisés venant des autres sites ; (4) faire authentifier dans le système le
bénéficiaire, par contrôle iris ou par saisie de l’IDcode, avant son paiement ; (5)
consulter ou rechercher dans le système les informations biographiques et de paiement
du démobilisé ; (6) effectuer ou procéder au paiement du démobilisé dans le système ;
32
Nous avons intentionnellement refusé de présenter les différents diagrammes UML car notre modèle de tests se
situe au niveau supérieur, c.à.d. au niveau de tests système et de tests de validation. Le modèle d’exigences à
élaborer, qui se limitent à l’amélioration de cas de tests fonctionnels, est directement à mesure de matérialiser et/ou
de générer les différents cas de tests systèmes, qui constitue notre modèle de tests.

26. 26
(7) imprimer dans le système le reçu de paiement du démobilisé qui devra sortir en en
trois exemplaires mais aussi les rapports journaliers/hebdomadaires/mensuels de
paiement ; (8) exporter via ftp (Internet) les données
journalières/hebdomadaires/mensuelles de paiement vers le Data center pour
consolidation et rapprochement et (9) enfin arrêter ou fermer le système ;
- Pour le bénéficiaire (démobilisé), (1) faire valider son identité avant tout paiement par
authentification (contrôle de son iris) dans le système.
Ces opérations, à réaliser par les trois acteurs identifiés (agent payeur, installateur et démobilisé) sur
le système à développer et/ou développé, sont des cas d’utilisation qui ont été décrites nominalement
sous forme de scénarios et d’enchainements puis détaillées dans des diagrammes de séquence liés
(diagramme de séquence système de cas d’utilisation « inscription des utilisateurs », diagramme de
séquence système de cas d’utilisation « authentification des utilisateurs ou des ex –combattants »,
etc.) non repris aussi schématiquement ici. Ces cas d’utilisation, après raffinement, génèrent les
exigences génériques et spécifiques ci – dessous :
Exigences génériques du système sous test
- [EX-G-01] : le logiciel à développer et/ou développé doit posséder une série d’interfaces génériques
(menus, message d’erreur, etc.) en français et en anglais;
- [EX-G-02] : l’intégration des données provenant d’un module logiciel vers un autre module, à
l’intérieur du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier
source ou de destination grâce à un ODBC disponible ;
- [EX-G-03] : le menu général du logiciel à développer et/ou développé devra permettre aux
utilisateurs de naviguer, sous un profil défini, aux différentes sections ou sous – menus de
l’applicatif ;
- [EX-G-04] : les composants logiciels utilisés doivent être cités dans la rubrique « A propos », ainsi
que les informations de la version associée ;
- [EX-G-05] : le logiciel à développer et/ou développé doit pouvoir être porté sur une version à jour
d’un système d’exploitation similaire à celui de son développement (Windows XP SP2 vers
Windows XP SP3 ou vers une version postérieure, Vista par exemple) sans changer la procédure
d’installation ni écrire dans le registre du système d’exploitation où le logiciel est porté ;
- [EX-G-06] : le logiciel à développer et/ou développé doit être fourni sous forme d’un fichier
compressé exécutable qu’on peut lancer directement. L’on devra avoir un et un seul fichier
exécutable ;
- [EX-G-07] : le logiciel à développer et/ou développé doit disposer des interfaces conviviales pour sa
manipulation ;
- [EX-G-18] : le logiciel à développer et/ou développé doit se lancer en moins de 3 secondes et doivent
fonctionner avec les configurations matérielles acceptées.
Exigences spécifiques du système sous test
- [EX-S-01] : seul l’installateur peut enregistrer les utilisateurs et définir leurs profils ;
- [EX-S-02] : l’accès au logiciel à développer et/ou développé, suivant les règles métiers, devra se faire
par authentification de l’utilisateur via son iris en mode normal ou via la saisie de son IDcode en
mode dégradé ;
- [EX-S-03] : le logiciel à développer et/ou développé doit posséder un menu « Paramètres ou
Administration » permettant à l’administrateur de paramétrer ou de configurer les différents profils et
accès administratifs des utilisateurs, les chemins d’accès à l’information, la gestion des accès et des
habilitations et les mécanismes d’authentification ;
- [EX-S-04] : le logiciel à développer et/ou développé doit posséder un menu « Aide », avec une
rubrique « à propos » dans laquelle apparaît le nom du logiciel, le numéro de la version, l’année de sa
distribution, les noms des entités associées au développement et d’autres éléments de copyright. Il
doit aussi, en outre, posséder la rubrique documentation utilisateur au sein du même menu « Aide »;
- [EX-S-05] : tous les utilisateurs enregistrés dans le logiciel à développer et/ou développé peuvent
effectuer des opérations et/ou des actions existantes suivant les profils et les règles de gestion définis
(paiement de 140$, de 150$X2, impression de reçu de paiement, synchronisation, etc.). Toutefois,
ces dernières devraient être tracées en indiquant quel utilisateur a effectué telle ou telle autre action?;

27. 27
- [EX-S-06] : le logiciel à développer et/ou développé doit être à mesure de procéder au paiement d’un
démobilisé, en mode normal ou en mode dégradé, selon les règles définies ;
- [EX-S-07] : le logiciel à développer et/ou développé doit être à mesure d’imprimer les rapports sur
les opérations de paiement et/ou sur les actions effectuées d’une manière chronologique. Il s’agirait
des détails sur les opérations et/ou les actions de paiement journalières, mensuelles, trimestrielles,
etc. effectuées sur le logiciel. L’on pourra toutefois l’étendre à des impressions statistiques sous
forme graphique ou des tableaux;
- [EX-S-08] : le logiciel à développer et/ou développé devra être à mesure de trouver et d’imprimer les
différents rapports des opérations et/ou des actions de paiements antérieurs qui ont été stockées dans
sa base de données ;
- [EX-S-09] : le logiciel à développer et/ou développé devra être à mesure d’exporter et d’importer les
fichiers de la base de données au format ci – après défini par l’utilisateur (.txt, .csv, .xls, .mdb, .ldf et
.pdf) ;
- [EX-S-10] : Le logiciel à développer et/ou développé doit être à mesure de créer, de sauvegarder et
d’imprimer une activité journalière de paiement à enregistrement vide créée par l’utilisateur ;
- [EX-S-11] : le logiciel à développer et/ou développé devra être à mesure de prendre en charge les
différents périphériques servant à son optimisation (lecteur iris, imprimante, etc.) ;
- [EX-S-12] : le logiciel à développer et/ou développé devra être à mesure de sauvegarder
automatiquement l’enregistrement en cours, en cas de d’arrêt brusque de l’applicatif (coupure du
courant, plantage système, etc.) ou à défaut, offrir la possibilité de pouvoir récupérer tous les
enregistrements sauvegardés automatiquement avant et/ou à l’arrêt brusque de l’applicatif.
- [EX-S-13] : le logiciel à développer et/ou développé devra être à mesure de synchroniser
automatiquement les enregistrements et/ou les données, provenant d’un module applicatif ouvert vers
son module applicatif intégré ouvert ou non. Toutefois, lors d’une synchronisation, si un champ est
manquant, incohérent ou incorrect, un message d’erreur est affiché à l’écran ;
- [EX-S-14] : le logiciel à développer et/ou développé devra, lors de la fermeture, enregistrer et arrêter
toutes les opérations et/ou actions effectuées lors d’un processus activé ou ouvert.
Ces exigences génériques ou spécifiques, à implémenter dans le cadre de notre système sous test,
sont considérées comme notre « modèle d’exigences de tests » (CIM). Elles sont donc en lien direct
(traçabilité) avec les autres modèles (PIM et PSM) qui ont suivis dans le cycle de développement
(les différents diagrammes de conception) et génèrent les différents cas de tests ci – dessous
s’accompagnent des résultats attendus. C’est donc notre modèle de tests système et de validation, qui
a trois niveaux. Le premier niveau reprend les exigences génériques ou spécifiques de tests. Le
second niveau aligne les cas de tests tandis que le troisième reprend les résultats attendus (oracles).
Ces différents cas et résultats de tests concernent tous les tests système et les tests d’acceptation par
la clientèle (Users Acceptance Tests, UAT). Ainsi, les caractéristiques et les modalités qui sont
fixées sont celles de recette fonctionnelle et d’exploitabilité mais aussi de performance, de sécurité,
de maintenance, d’installation, de compatibilité et de gestion des exceptions (mode dégradé).
« A titre indicatif, nous illustrons seulement une série d’éléments de notre modèle de tests. Il s’agit
des éléments pour les tests de recette fonctionnelle et d’exploitabilité ».
Identificateur FONCTIONNEL ET EXPLOITABLE
Technique de tests Tests de système et d’acceptation (boite noire)
Exigences de tests retenues
[EX-S-02] L’accès au logiciel à développer et/ou développé, suivant les règles métiers, devra se faire par
authentification de l’utilisateur via son iris en mode normal ou via la saisie de son IDcode en
mode dégradé
[EX-G-02] L’intégration des données provenant d’un module logiciel vers un autre module, à l’intérieur
du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier
source ou de destination grâce à un ODBC disponible
[EX-S-03] Le logiciel à développer et/ou développé doit posséder un menu « Administration »
permettant à l’administrateur de paramétrer ou de configurer les différents profils et accès
administratifs des utilisateurs, les chemins d’accès à l’information, la gestion des accès et
des habilitations et les mécanismes d’authentification
[EX-G-03] Le menu général du logiciel à développer et/ou développé devra permettre aux utilisateurs

28. 28
de naviguer, sous un profil défini, aux différentes sections ou sous – menus de
l’applicatif
[EX-S-04] Le logiciel à développer et/ou développé doit posséder un menu « Aide », avec une
rubrique « à propos » dans laquelle apparaît le nom du logiciel, le numéro de la version,
l’année de sa distribution, les noms des entités associées au développement et d’autres
éléments de copyright. Il doit aussi, en outre, posséder la rubrique documentation
utilisateur au sein du même menu « Aide »
[EX-S-05] Tous les utilisateurs enregistrés dans le logiciel à développer et/ou développé peuvent
effectuer des opérations et/ou des actions existantes suivant les profils et les règles de
gestion définis (paiement de 140$, de 150$X2, impression de reçu de paiement,
synchronisation, etc.). Toutefois, ces dernières devraient être tracées en indiquant quel
utilisateur a effectué telle ou telle autre action?
[EX-S-06] Le logiciel à développer et/ou développé doit être à mesure de procéder au paiement d’un
démobilisé, en mode normal ou en mode dégradé, selon les règles définies
[EX-S-07] Le logiciel à développer et/ou développé doit être à mesure d’imprimer les rapports sur
les opérations de paiement et/ou sur les actions effectuées d’une manière chronologique.
Il s’agirait des détails sur les opérations et/ou les actions de paiement journalières,
mensuelles, trimestrielles, etc. effectuées sur le logiciel. L’on pourra toutefois l’étendre à
des impressions statistiques sous forme graphique ou des tableaux
[EX-S-08] Le logiciel à développer et/ou développé devra être à mesure de trouver des
enregistrements et d’imprimer les différents rapports des opérations et/ou des actions de
paiements antérieurs qui ont été stockées dans sa base de données
[EX-S-09] Le logiciel à développer et/ou développé devra être à mesure d’exporter et d’importer les
fichiers de la base de données au format ci – après défini par l’utilisateur (.txt, .csv, .xls,
.mdb, .ldf et .pdf)
[EX-S-10] Le logiciel à développer et/ou développé doit être à mesure de créer, de sauvegarder et
d’imprimer une activité journalière de paiement à enregistrement vide créée par
l’utilisateur
[EX-S-11] Le logiciel à développer et/ou développé devra être à mesure de prendre en charge les
différents périphériques servant à son optimisation (lecteur iris, imprimante, etc.)
[EX-S-12] Le logiciel à développer et/ou développé devra être à mesure de sauvegarder
automatiquement l’enregistrement en cours, en cas de d’arrêt brusque de l’applicatif
(coupure du courant, plantage système, etc.) ou à défaut, offrir la possibilité de pouvoir
récupérer tous les enregistrements sauvegardés automatiquement avant et/ou à l’arrêt
brusque de l’applicatif
[EX-S-13] Le logiciel à développer et/ou développé devra être à mesure de synchroniser
automatiquement les enregistrements et/ou les données, provenant d’un module applicatif
ouvert vers son module applicatif intégré ouvert ou non. Toutefois, lors d’une
synchronisation, si un champ est manquant, incohérent ou incorrect, un message d’erreur
est affiché à l’écran
[EX-S-14] Le logiciel à développer et/ou développé devra, lors de la fermeture, enregistrer et arrêter
toutes les opérations et/ou actions effectuées lors d’un processus activé ou ouvert
Informations sous tests
Démarche
Cas de tests [(CT-F-01)→(EX-S-02)] Fenêtre de connexion: Cliquez sur le bouton « avec iris ». Une
fenêtre de capture iris vous permettant de vous faire authentifier va apparaître. En bas du
bouton « avec iris », nous avons le bouton « help » qui vous permet d’afficher la fenêtre
« aide » qui a à son sein l’onglet « à propos », « contact » et « manuel utilisateur ».
[(CT-F-02)→(EX-S-02)] Fenêtre de capture iris: En cliquant sur capturer l’œil droit et/ou
sur capturer l’œil gauche, si votre iris est déjà stocké dans la base de données iris, vous
devez accéder au menu général.
[(CT-F-03)→(EX-S-03)] Fenêtre d’inscription de l’utilisateur: Si le système est lancé
pour la première fois, le premier utilisateur qui fait capturer son iris sera enregistré
comme administrateur. Dans ce cas, il aura lui l’obligation d’inscrire plus tard les autres
utilisateurs du système (les agents payeurs) puis enregistrer leurs profils. Ici, la fenêtre
capture apparaît et après capture des iris droit et gauche, on clic sur approuver puis
continuer.
[(CT-F-04)→(EX-G-03)] Menu général ou principal: Elle apparaît, cette fenêtre, lorsque
l’utilisateur ou l’administrateur se connecte sur le système en cliquant sur « avec iris » et
se fait par la suite authentifier via son iris (mode normal) ou via son IDcode (dans le cas

29. 29
d’une connexion en mode dégradé).
[(CT-F-05)→(EX-S-02)→(EX-G-03)] Menu général ou principal: En faisant un tour
d’horizon dans cette fenêtre, vous trouverez l’existence d’une liste déroulante de choix de
langues en français et/ou en anglais. La langue par défaut est le français. Le choix de
l’anglais changerait automatiquement les interfaces du logiciel en anglais.
[(CT-F-06)→(EX-S-08)] Fenêtre rechercher: Cette fenêtre vous permet de trouver tout
enregistrement de paiement stocker dans le système. C’est aussi au niveau de cette fenêtre
qu’on procède à l’authentification de l’ex – combattant bénéficiaire par iris ou via la
saisie de son IDcode.
[(CT-F-07)→(EX-S-05)→(EX-S-06)→( EX-S-07)→(EX-S-10)] Fenêtre détails de
paiements: Saisissez et/ou choisissez les informations sur un paiement (1ière
tranche, 2ième
tranche ou 3ième
tranche) puis validez avec le bouton « effectuer le paiement » d’un
démobilisé. Le reçu de paiement devra apparaître en visualisation et vous pouvez cliquez
sur imprimer. Clôturez l’opération afin de permettre le paiement suivant.
[(CT-F-08)→(EX-S-09)] Fenêtre d’exportation: Cliquez sur le bouton Exporter, et sur la
fenêtre « exporter » qui va apparaître, sélectionnez « exportation quotidienne » ou
« exporte par date » puis cliquez sur « exporter » et en plus sur « exporter pour
CELPAY ».
[(CT-F-09)→(EX-G-02)→(EX-S-09)→(EX-S-15)] Fenêtre d’importation de données
d’identification : Cliquez sur le bouton Importer et sur la fenêtre « importer » qui va
apparaître, sélectionnez « importer les données du site » puis cliquez sur « importer ». Le
dernier fichier crypté d’identification à date, créé à l'aide de l’applicatif « Ident – Congo »
puis déposé sur le site FTP UEPN – DDR, va être importé dans le système de paiement.
A ce niveau, une autre opération de synchronisation des données d’identification dans le
système de paiement a lieu automatiquement dans le cas où celui – ci est connecté via un
réseau LAN avec le système d’identification dans un site d’enregistrement.
[(CT-F-10)→(EX-S-09)] Fenêtre d’importation de données de paiement : Cliquez sur le
bouton Importer et sur la fenêtre « importer » qui va apparaître, sélectionnez « importer
les données de paiement » puis cliquez sur « importer ». Le dernier fichier crypté de
paiement à date, créé à l'aide de l’applicatif « Payment Manager » puis déposé sur le site
FTP UEPN – DDR, va être importé dans le système de paiement.
[(CT-F-11)→(EX-S-05)→(EX-S-07)→(EX-S-08)→(EX-S-10)] Fenêtre de rapports:
Cliquez sur le bouton rapports. Sélectionnez « rapport quotidien » ou une période donnée
sur la liste déroulante et cliquez sur Afficher.
Résultats de cas de
tests
[RCT-F-01]→[(CT-F-01)→(EX-S-02)] Fenêtre de connexion: Une
fenêtre de connexion devra apparaître et vous donnant la possibilité
de procéder via le bouton « avec iris » à votre authentification
Oui, avec succès
[RCT-F-02]→[(CT-F-01)→(EX-S-02)] Fenêtre de capture iris: Une
fenêtre de capture iris ou saisie de l’IDcode, vous permettant de vous
faire authentifier, va apparaître.
Oui, avec succès
[RCT-F-03]→[(CT-F-02)→(EX-S-02)]→[(CT-F-03)→(EX-S-03)]
Fenêtre d’inscription de l’utilisateur: La fenêtre « Enregistrement de
l’administrateur ou de l’utilisateur » devra apparaître. A ce niveau,
on procédera à l’enregistrement de l’iris gauche et de l’iris droit de
l’utilisateur. Après validation, un Idcode devra être généré puis lié à
l’utilisateur inscrit. L’administrateur devra ajouter d’autres
informations le concernant (nom, prénom, date de naissance, etc.).
La procédure se termine avec le message « Administrateur ou
utilisateur inscrit avec succès ».
Oui, avec succès.
Prière de modifier
« administrateur »
par
« administration ».
[RCT-F-04]→[(CT-F-04)→(EX-G-03)]→[(CT-F-05)→(EX-G-03)]
Menu général ou principal: Cette fenêtre apparaît et devra vous
permettre d’accéder aux différents sous – menus du système, à
savoir : administration, paiement, rechercher, importer, exporter,
rapport et quitter. Ici, seul l’administrateur ou l’utilisateur inscrit qui
devra voir ces sous menus activés. Il y a aussi l’option de se
déconnecter du système au milieu de la fenêtre.
Oui, avec succès
[RCT-F-05]→[(CT-F-06)→(EX-S-08)] Fenêtre rechercher: Cette
fenêtre apparaît et devra vous permettre de trouver tout
Oui, avec succès

30. 30
enregistrement de paiement stocker dans le système.
L’enregistrement retrouvé affiche aussi sur une carte virtuelle
l’image du démobilisé, avec d’autres informations utiles. La
recherche est multicritère (IDcode, nom, prenom, et date
d’enregistrement).
[RCT-F-06]→[(CT-F-07)→(EX-S-05)→(EX-S-06)→(EX-S-
07)→(EX-S-10)] Fenêtre détails de paiements: Les détails sur les
dates et les montants reçus et restants d’un démobilisé mais aussi sur
les opérateurs ayant effectué ces paiements seront affichés. Ensuite,
après avoir cliquer sur « effectuer le paiement », une fenêtre
affichant le reçu de paiement en trois exemplaires sur un format A4
devra s’afficher avec possibilité d’impression ou d’enregistrement
dans les formats .pdf, .word, .xls et .jpeg.
Oui, avec succès
[RCT-F-07]→[(CT-F-08)→(EX-S-09)] Fenêtre d’exportation : deux
fichiers avec de données exportées seront créés et cryptés. L’un pour
CELPAY et l’autre pour UEPN – DDR et BIO – ID. Ils devront par
la suite être déposés sur le site FTP UEPN – DDR.
Oui, avec succès
[RCT-F-08]→[(CT-F-09)→(EX-G-02)→(EX-S-09)→(EX-S-15)]
Fenêtre d’importation de données d’identification: Les données seront
importées. Procéder à la recherche du dernier IDcode existant dans le
système pour s’assurer que les autres données d’identification sont
importées.
Oui, avec succès
[RCT-F-09]→[(CT-F-10)→(EX-S-09)] Fenêtre d’importation de
données de paiement: Les données seront importées. Procéder à la
recherche du dernier IDcode existant dans le système pour s’assurer
que les autres données d’identification sont importées.
[RCT-F-10]→[(CT-F-11)→(EX-S-05)→(EX-S-07)→(EX-S-
08)→(EX-S-10)] Fenêtre rapports: Une fenêtre affichant le rapport
devra s’afficher avec possibilité d’impression ou d’enregistrement
dans les formats .pdf, .word, .xls et .jpeg.
Oui, avec succès
Niveau de complétude Atteindre au moins les 100% d’exigences des cas de tests retenus sur l’ensemble de
critères d’installation de l’applicatif
Succès /échec Voir commentaires sur les résultats de tests d’installation
b) Résultats et discussion sur l’ébauche du modèle (analyse du modèle en mettant un avis
sur le logiciel)
Les résultats de notre contribution permettent de mieux comprendre la démarche d’élaboration d’un
modèle de tests de vérification et de validation mais aussi de faciliter son déploiement. Ils ont été
matérialisés en se servant des référentiels normatifs en la matière (type de gouvernance à mettre en
place, respect de meilleures pratiques et mise en œuvre d’une gestion de cycle de vie du logiciel dans
laquelle les tests logiciels constituent l’élément visible pour la qualité) et des principes généraux de
l’IDM suivant l’approche MDA (méta – modélisation et transformation de modèles). Avec l’aide de
la modélisation UML, comme profil du méta – modèle, et sans y ajouter de façon claire les
contraintes OCL, nous avons pu élaborer un modèle d’exigences fiable (CIM) qui nous a permis par
la suite de rédiger manuellement des cas et des résultats des tests aboutissant au modèle complet de
tests système et de validation. Ce dernier, qui se résume dans notre cas à des diagrammes de cas
d’utilisation, d’activité et de séquence, a matérialisé l’exécution de tests système et la validation du
logiciel « Payment Manager ».
En effet, la méthodologie UML a été choisi par nous à la place des autres méta-modèles (MOF,
XMI, OCL) car elle a permis de décrire séparément les modèles pour les différentes phases du cycle
de développement d’un logiciel (Bézevin et Blanc Xavier, 2002). C’est une approche qui se veut
aujourd’hui généraliste (Combemale, 2008). Ainsi, sans détailler sa sémantique d’exécution, grâce
au modèle d’exigences (CIM) généré à partir des exigences textuelles (processus et règles métiers
pour le paiement, besoins des utilisateurs, etc.), notre ébauche de modèle de tests qui ne se situe
qu’au niveau supérieur (tests système et de validation) a concrétisé manuellement les cas de tests

31. 31
abstraits générés par des tests concrets sur des données réelles ou de tests (erronées). Les résultats
obtenus sont voire sans équivoque car ils démontrent la traçabilité les cas de tests générés avec
d’exigences techniques produites mais aussi avec les résultats abstraits de tests. Quelques résultats
concrets de cette suite de tests sont présentés dans les figures 6, 7, 8, 9 et 10 ci - dessous.
Fig.6. [RCT-F-01]→[(CT-F-01)→(EX-S-02)] Fenêtre de connexion, avec iris, dans le « Payment Manager ». Nous remarquons aussi en haut le choix de
langues et du site de paiement. Les exigences et cas de tests liés ici sont [EX-S-02] et [(CT-F-01)→(EX-S-02)].
Fig.7. [RCT-F-04]→[(CT-F-04)→(EX-G-03)]→[(CT-F-05)→(EX-G-03)] Menu général ou principal. Ce dernier permet à l’utilisateur de naviguer sur
l’ensemble des ressources du système. Il est en lien avec les exigences et les cas de tests ci - après [EX-G-03], [(CT-F-04)→(EX-G-03)] et [(CT-F-
05)→(EX-S-02)→(EX-G-03)]

32. 32
Fig.8. [RCT-F-02]→[(CT-F-02)→(EX-S-02)]→[(CT-F-03)→(EX-S-03)] Fenêtre d’inscription de l’utilisateur. Ce dernier dépend de l’écran « Capture
des iris ». Ici, l’on observe l’enregistrement de l’œil gauche de l’administrateur. Cette opération est identique pour l’inscription des autres utilisateurs du
système. Il est associé aux exigences et cas de tests suivants [EX-S-03] et [(CT-F-03)→(EX-S-03)].
Fig.9. [RCT-F-06]→[(CT-F-07)→(EX-S-05)→(EX-S-06)→(EX-S-07)→(EX-S-10)] Fenêtre détails de paiements d’un ex – combattant (TEST GUY
TEST BANDA dans notre cas). Ici, l’on voit aussi le nom de l’utilisateur effectuant la transaction est rattaché en lien automatique (TESTER) et les
bénéfices déjà obtenus. Les exigences et cas de tests liés ici sont [EX-S-05], [EX-S-06], [EX-S-07], [EX-S-10] et [(CT-F-07)→(EX-S-05)→(EX-S-
06)→( EX-S-07)→(EX-S-10)].
Fig.10. [RCT-F-05]→[(CT-F-06)→(EX-S-08)] Fenêtre rechercher. Ici, la recherche d’un ex – combattant est multicritère. Elle peut être effectuée soit par
iris, IDcode, Nom, etc. Cette opération permet, une fois l’enregistrement trouvé, de pouvoir accéder au détail des informations sur le paiement de l’ex –

33. 33
combattant et/ou procéder à un nouveau paiement (2ième ou 3ième tranche). Les exigences, cas et résultats de tests liés ici sont [EX-S-08] et [(CT-F-
06)→(EX-S-08)].
Ici, les méthodes ou techniques de tests décidées étaient toutes dynamiques et se sont exécutées
suivant l’approche boite noire, à partir des directives pratiques ci - après :
- les jeux de données d’entrée à appliquer sont décrits sur les valeurs critiques de
paiement qui sont valides ou erronées ;
- les cas de tests (scénarios) constituent le mode opératoire retenu ;
- la description les comportements attendus du programme ou du logiciel sont décrits
sur les types et les valeurs de sortie ; et
- les critères d’acceptation des résultats de tests et de clôture sont basés sur la
prévention, la tolérance et l’élimination des fautes constatées.
A ce niveau, l’équipe de test a déterminé les données de test (DT) fournies aux CT (concrétisation)
alignés et a indiqué les résultats qu’elle attendaient pour ces CT (prédiction de l’Oracle). Ensuite,
elle a exécuté des scripts testant ces CT sur les DT. Après comparera des résultats obtenus avec les
prédictions de l’Oracle (verdict), un rapport sur les résultats de tests (succès ou échec) a été élaboré.
La durée globale de ces activités de tests système et de validation a été de 4 jours. Ici, l’effort fourni
par chaque membre du projet affecté à l’équipe de tests était sur le nombre cas de tests à concevoir,
les défauts à découvrir et sur les stratégies de résolution à définir dans le souci d’éviter des tests
inutiles, qui étaient de toute façon rejoués.
Ainsi, pour la première journée de tests, considérée comme journée de démarrage des activités de
tests, les actions suivantes ont été menées : (a) la préparation des matériels de la plate forme retenue,
(b) l’inter connectivité des matériels retenus pour la plate forme, (c) l’optimisation et le test d’inter
connectivité des matériels de la plate forme retenue pour les tests (d) la conception des types et des
cas de tests, (e) la validation des différentes techniques, types et cas de tests retenus et enfin (f)
l’harmonisation des actions sur les résultats et/ou livrables de chaque type des cas de tests retenus.
Cette harmonisation a été établie via une relation de conformité entre le système sous test et le
modèle de test obtenu qui le représente. De même, elle a été rendue possible grâce aux résultats de
tests de niveau inférieur (tests unitaires et d’intégration) sur les codes sources inspectés et corrigés.
La deuxième et la troisième journée, considérée comme les journées de vérification définitive de
« Payment Manager », ont connu les actions suivantes : (a) l’exécution des différents types et cas de
tests retenus, (b) le Suivi, l’observation minutieuse et la correction des différents types et cas de tests
exécutés, (c) l’intégration des différents résultats de tests exécutés dans un rapport journalier de tests
et enfin (d) la validation de ce rapport intermédiaire par les différents acteurs ayant participé aux
activités de tests. Les autres actions menées par l’équipe de tests étaient basées sur les résultats de
chaque cas de tests. Ces résultats étaient repris sur une liste, annexée au rapport journalier de tests, et
qui indiquaient en dehors de cas de tests les différents acteurs concernés pour chaque cas réussi, ainsi
que le délai qui était accordé pour la finalisation ou la correction de chaque cas échoué. Quant à la
dernière journée, considérée comme la journée de clôture (validation) en vue du déploiement et/ou
de la mise en exploitation de « Payment Manager », les actions menées ont été : (a) la production des
différents résultats de tests exécutés depuis le début du processus (première phase jusqu’à la
deuxième phase de tests), (b) l’intégration de ces résultats dans le rapport final de tests et
d’acceptation par les utilisateurs (UAT final) et enfin (c) la validation du rapport final par les
signatures des différents acteurs ayant participé aux activités de tests. Ces activités ont donc marqué
la clôture de la phase de tests et le démarrage de la phase de déploiement (installation), associée à la
formation des utilisateurs et la configuration du produit - logiciel au sein du système d’information
de gestion intégrée en production de l’UEPN – DDR.
Nous comprenons ainsi que la mise production du logiciel « Payment Manager » a alors marqué la
fin de sa vérification et de sa validation et que notre ébauche du modèle de tests, proposé dans cette

34. 34
contribution, jette les bases d’un démarrage de pratique de tests systématiques par les professionnels
TI congolais, même si plusieurs limites sont mentionnées et/ou pourront être mentionnées.
Toutefois, il serait important de souligner la nécessité d’effectuer une validation plus complète de
cette ébauche en ajoutant les cas de tests de niveau inférieur de tests qui ont matérialisés, dans le
cadre de notre projet, les tests unitaires et d’intégration. La méthodologie UML, qui possède une
syntaxe très proche de la syntaxe de certains langages puis utilisée pour les tests de niveau supérieur
dans cette contribution, devra permettre de dériver les tests de type boîte blanche et renforcer les
tests systèmes généralement produits. Des travaux futurs sont donc nécessaires afin de pouvoir
formaliser ces techniques et pouvoir ainsi valider et vérifier les transformations présentées et/ou qui
pourront être présentées dans d’autres contributions afin de pouvoir produire, avec des technologies
MBT et des outils d’automatisation de tests par exemple, des cas de tests généralement automatisés
et confiés à des algorithmes de génération solides permettant de s’affranchir de l’erreur humaine et
d’obtenir des résultats de tests de meilleure qualité.
IV. CONCLUSION
Cette contribution tente de se greffer sur les travaux récents portant sur la génération de tests dans
une approche d’ingénierie dirigée par les modèles. Pour ce faire, nous avons été dans l’obligation de
proposer une ébauche de modèle de tests dont la mise à l’épreuve, sur le plan pratique, pourra
s’adapter et s’étendre à un plus grand nombre de projets cherchant à dégager les bénéfices d’usage
des bonnes pratiques de développement logiciels et, sur le plan théorique, va la permettre de
continuer de s’affiner sur la base des travaux s’intéressant à l’évolution des outils de tests car la
problématique générale de tests logiciels reste encore largement ouverte.
D’ailleurs, pour la RD Congo, lors d’une discussion en atelier avec quelques membres de BSD
Congo, nous avons conclu que si les activités de vérification et de validation de façon systématique,
au niveau d’un projet de développement informatique, reste un défi majeur, alors qu’elles constituent
une étape critique dans la pratique de développement logiciels, c’est parce qu’elles semblent ne pas
avoir été vulgarisées par ceux qui sont sensées apporter de l’aide à la société.
Ainsi, l'ensemble des éléments présentés, intégrés dans une démarche simplifiée, suggère aux
professionnels TI congolais de mieux adapter leur façon faire les tests logiciels et/ou de procéder aux
activités de tests dans des projets de développement qu’ils ont à diriger et, aux universitaires, de faire
évoluer leurs enseignements et leur recherche dans la quête des meilleures pratiques menant au
succès de développements logiciels dans notre pays. Confiant de la communauté « BSD Congo »,
qui est déjà rodée avec la modélisation UML et avec certaines bonnes pratiques de développements
logiciels, nous pensons qu’elle pourra aussi s’impliquer dans cette vision.
BIBLIOGRAPHIE
I.OUVRAGES
- BERSINI Hugues, La programmation orientée objet, 2ième
tirage, Eyrolles, Paris, 2009.
- BLANC Xavier, avec la contribution de SALVATORI Olivier, MDA en action : ingénierie
logicielle guidée par les modèles, collection architecte logiciel, EYROLLES, 2005.
- CHARTIER – KASTLER Cyrille, Précis de conduite de projet informatique, Editions
d’organisation, Paris, 1997.
- GAUDEL Marie – Claude et Ali, Précis de génie logiciel, Préface de LEMOINE Michel,
Edition Masson, Collection Enseignement de l’informatique, Paris, 1996.
- GUSTAFSON David, Génie logiciel, Dunod, Série Schaum’s – EdiScience, Paris, 2003.
- IVINZA LEPAPA A. C., Analyse de l’introduction de l’EDI dans les entreprises
congolaises : Une contribution à l’impact organisationnel des Technologies de
l’Information, Tome I: concepts de base et cadre d'analyse théorique, Editions
universitaires européennes, Saarbrüken - Germany, 2010.

35. 35
- LE MOIGNE Jean – Louis, La théorie du système général. Théorie de la modélisation,
Presses universitaires de France, Paris, 1994.
- MESSAGER ROTA V., Gestion de projet – Vers les méthodes agiles, Eyrolles, Paris,
2007.
- MOREAU René, L’approche objets : Concepts et techniques, Edition Masson, Paris,
1995.
- MOREJON J. et RAMES J.R., Conduite de projets informatiques : principes et
techniques s’appuyant sur la méthode Merise, Inter éditions, Paris, 1992.
- MORLEY Chantal, Management d’un projet système d’information : principes, techniques,
mise en œuvre et outils, 4ième
édition, Collection InfoPro, Dunod – Informatique, Paris, 2004
- PRINTZ Jacques, Le génie logiciel, Presses universitaires de France, Collection Que sais-
je ?, Paris, 1995.
- ROQUES Pascal, UML par la pratique, 5ième
édition, Eyrolles, Paris, 2009.
- SIMON H.A., Le Nouveau management : La décision par les ordinateurs, Economica,
Paris, 1980.
- TARDIEU H., NANCY Dominique et PASCOT Daniel, Conception d’un système
d’information : construction de la base des données, Les éditions d’organisation, Paris,
Gaëtan Morin Editeur, Québec, 1980.
- VAUQUIER Dominique, Plan qualité du logiciel et des services Internet, AFNOR, Saint-
Denis-La-Plaine Cedex, 2003.
- VICKOFF J.P., Méthode Agile : « les meilleures pratiques, compréhension et mise en
œuvre », RAD Sarl, 2009.
II. COURS ACADEMIQUES
- IVINZA LEPAPA A. C. et MBUTA IKOKO D. A., Génie logiciel et construction des
programmes, Université Libre de Kinshasa, Faculté des Sciences Economiques et
Gestion, Département d’Informatique de Gestion, L1 INFOGEST, Cours inédit, Année
académique 2006 – 2007.
- IVINZA LEPAPA A. C., Projets d’automatisation, Université Libre de Kinshasa, Faculté
des Sciences Economiques et Gestion, Département d’Informatique de Gestion, L1
INFOGEST, Cours inédit, Année académique 2001 – 2002.
- LAVOIE Luc, Gestion de projet, Université de Sherbrooke, Faculté des Sciences, Centre
de formation en technologies de l’information, INF 754, Cours inédit, Hiver 2007.
- MVIBIDULU KALUYIKIT A., Conception des systèmes d’information, Université Libre
de Kinshasa, Faculté des Sciences Economiques et Gestion, Département d’Informatique
de Gestion, L1 INFOGEST, Cours inédit, Année académique 2001 – 2002.
III. TRAVAUX, ARTICLES, REVUES ET AUTRES
- ABRAHAMSSON P., WARSTA J., SIPONEN M.T. and RONKAINEN J. « New
directions on agile methods : A comparative analysis », IEEE Computer Society, 2003,
pp. 244 – 254.
- AFNOR, Ingénierie et qualité du logiciel et des systèmes. Tome 1 : Définitions des
processus et qualité des produits, AFNOR, 2002.
- ALLARD POESI F. et PERRET V., Rôles et conflits de rôles du responsable de projet,
Revue Française de Gestion, 31(4), 2005, pp. 193-202
- BEZEVIN J. et BLANC X., Promesses et Interrogations de l’Approche MDA,
Développeur Référence, http://www.weblmi.com/devreference, septembre 2002, v2.17,
pp. 8-12.

36. 36
- CFTL/ISTQB, Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels, Erik van
Veenendaal Editeur, Décembre 2007.
- CHARPENTIER P., Comment construire les tests d’un logiciel, INRS, Collection
Méthodologie, Cahiers de notes documentaires – Hygiène et sécurité du travail, 4ième
trimestre, n° 181 – ND 2140 – 181 - 00, pp. 63-77, 2000.
- CHOKRON Michel, DUFOUR E. et DES ROCHERS M., Connaissances et formation
spécifiques aux gestionnaires des TI, Cahier du GReSI, n°05-02, HEC Montréal, Juin
2005.
- CMMI PRODUCT TEAM, CMMI® for Development, Version 1.2, Software Engineering
Institute, Carnegie – Mellon, August 2006.
- COMBEMALE Benoît, Ingénierie Dirigée par les Modèles (IDM) : État de l’art, Institut
de Recherche en Informatique de Toulouse, Août 2008
- CROCHET DAMAIS Antoine, Gestion de projet informatique : décryptage, Journal du net,
Paris, Avril 2011.
- ERICKSON J., LYYTINEN K. and SIAU, K. « Agile modeling, agile software
development, and extreme programming: The state of research », Journal of Database
Management, 16(4), 2005, pp. 88 – 100.
- GOWAN J.A. and MATHIEU R.G., The Importance of Management Practices in IS
Project Performance: An Empirical Study, Journal of Enterprise Information Management,
18(1), 2005, pp. 235 – 255.
- GUILLEMETTE M. G. et PARE Guy, Vers une meilleure compréhension de la
transformation de la fonction TI dans les organisations, Cahier du GReSI, n°07-08, HEC
Montréal, Décembre 2007.
- IEEE 610.12, Standard Glossary of Software Engineering Terminology, Edition 1990.
- IEEE 1233, Guide de l'IEEE pour la Spécification d’Exigences de Système, Edition 1998.
- JEZEQUEL J. M., GERARD S., BAUDRY B., « L'ingénierie dirigée par les modèles »,
chapitre « Le génie logiciel et l'IDM : une approche unificatrice par les modèles »,
Lavoisier, Hermes- science, 2006.
- MBUTA IKOKO D. A., Fonction Technologie de l’Information de l’UEPN – DDR :
Approche pour la relance des activités du PNDDR, Document interne, UEPN – DDR, Août
2008.
- MBUTA IKOKO D. A. et Alii, Résultats du déroulement de tests du logiciel Payment
Manager, Fonction TI, Document interne, UEPN – DDR, Mars 2009.
- MBUTA IKOKO D. A. et Alii., Rapport de tests sur l’ouverture de la clé de paiement de
150$ USD en 2 dans Payment Manager, Document interne, UEPN – DDR, Juillet 2009.
- MONGIN Philippe et Ali, Evaluation de la solution de gestion du système des paiements des
ex – combattants en réinsertion : Elaboration de proposition en vue d’en améliorer la sécurité
et la performance, ERNST YOUNG – France, Juillet 2006.
- MOTTU J. M. et alii. Génération automatique de test pour les transformations de
modèles. In IDM05 (Ingénierie Dirigée par les Modèles), Paris, France, 2005.
- PIERRE MAJORIQUE Léger, LUC Cassivi et MICHAEL Wybo, Gestion de projet TI :
Amener une équipe à utiliser les technologies de communication appropriées, HEC
Montréal, Cahier du GReSI, n° 07-02, Janvier 2007.
- SIDI Jacqueline, Les normes : des outils plutôt que des exigences, La lettre d’ADELI
n°50, Janvier 2003, pp. 35 - 37.
- VITAL Roy, CARMEN Bernier et MARTIN Danis, Leadership, modes
d’approvisionnement et gestion de projets TI, HEC Montréal, Cahier du GReSI, n° 07-06,
Mai 2007.