Les cahiers de BSD Congo n4, mai 2011

ELEMENTS DELABORATION DUN MODELE DE TESTS DE VERIFICATION ET DE

VALIDATION DANS UN PROJET DE DEVELOPPEMENT MIXTE : LEXEMPLE DE
PAYMENT MANAGER 1.0.
Contribution de MBUTA IKOKO Dodi Alphonse1
Spcialiste MIS et Charg de Projet Ident et ITS lUEPN-DDR
Conseiller TI et Responsable de la cellule Recherche et Dveloppement de BSD Congo,
Assistant denseignement et de recherche en informatique et MIS
Dpartement dInformatique de Gestion, Universit Libre de Kinshasa, RD Congo &
Section Informatique, Institut Suprieur de Commerce de Kinshasa, RD Congo
Email: dodi.mbuta@bsdcongo.org / mbutaikoko@hotmail.fr
Mai 2011

Contact, Les cahiers de BSD Congo

Tlphone : +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 mthodes et outils TI et pour un meilleur
partage du savoir libre en RD Congo, lAssociation BSD Congo a cr depuis 2009, via la cellule
recherche et dveloppement qui uvre au sein de son quipe technique, une note de
communication et de partage dexprience dans le domaine des TI, appele Les cahiers de BSD
Congo , documents de travail ou de pr - publications n'excdant pas quarante pages. Ils sont
diffuss et mis la disposition des membres/partenaires de BSD Congo et du public, via Internet,
dans une perspective dchanges et de partage du savoir TI. Ces changes se ralisent dans un
souci de rciprocit et de libre circulation de proccupations professionnelles ou scientifiques.
Leur contenu n'est pas dfinitif et peut tre sujet discussion. Ils ne constituent donc qu'une tape
dans la dmarche scientifique.
Rsum
Les tests logiciels restent une approche incontournable dans le dveloppement logiciel, surtout
avant la mise en production du produit logiciel dvelopp.
En RD Congo, la pratique de tests semble nest pas encore du tout formalise dans la personne
des professionnels TI congolais. Ceux qui saventurent la ralisent sans le respect des rfrentiels
normatifs applicables. Cest pourquoi, avec notre retour dexprience de chef de projet Ident
ITS lUEPN DDR, dans le cadre dun dveloppement en impartition, avec la firme BIO ID
Technologies SA, du logiciel Payment Manager , nous avons jug bon de fournir notre
communaut des lments adapts aidant llaboration dun modle de tests logiciels sous la
forme dune bauche unifie et simpliste. Elle est produite partir partir de lexpression de
besoins des utilisateurs, des processus et/ou rgles mtiers de lUEPN DDR, etc. qui ont t, par
la suite, formaliss en modle dexigences fonctionnelles. Utilisant une dmarche de
modlisation emprunte lIDM, cette bauche a donc pour but de faciliter la ralisation et
lexcution de tests logiciels de niveau suprieur (systme et validation) par une quipe de
dveloppement logiciel suivant les conditions contractuelles et environnementales. Cest donc un
lment dentre de jeux produire par les acteurs impliqus dans un projet de dveloppement lors
de la remise en question ou pas du produit logiciel attendu des utilisateurs.
1

Lauteur de cette contribution remercie les lecteurs pour leurs judicieuses remarques et suggestions. Il tient aussi
les signifier quune partie de ce texte a fait lobjet dune prsentation lors dun atelier de BSD Congo sur le
dveloppement informatique avec un groupe dtudiants du Dpartement des Mathmatiques et Informatique de
lUniversit de Kinshasa, au mois de Juin 2010.

Mots cls : Projet de dveloppement logiciel mixte Tests logiciels Mthodes et outils de gestion
de tests Exigences pour la vrification et la validation Modle de tests systme.
I. INTRODUCTION
Dans le domaine de dveloppement et/ou de construction des logiciels (intangibilit), appel
Gnie logiciel , mais aussi celui de conception des systmes dinformation (complexit),
classiquement, une fois les premires phases de dveloppement termines (lanalyse des besoins,
la spcification globale, la conception dtaille et la programmation), les activits les plus
visibles et les plus dcisives qui permettent lquipe de dveloppement et/ou de projet TI de
pouvoir autoriser la phase dinstallation ou de dploiement du produit logiciel dvelopp
(dterminisme) sont celles de tests logiciels. Ces activits visibles de vrification mais aussi de
validation, orientes mode projet, sont menes dans le seul but de sassurer que le produit
logiciel dvelopp est correct et rpond aux exigences formules ou convenues au dpart par le
matre douvrage et le matre duvre. Elles offrent donc, ces activits de tests, une approche
exprimentale de rsolution de problmes de conception logicielle par des mthodes et des outils
de gnie logiciel (Luc Lavoie, 2007). Elles font donc partie des gages de succs, surtout pour des
projets informatiques de dveloppement logiciel excuts en impartition et/ou en partenariat
(mixte).
En RD Congo, la plupart des dveloppements informatiques sont actuellement raliss en
impartition et/ou en partenariat, mais toujours de manire brute, et nadmet presque pas la
ncessit de tester (vrifier) et/ou de valider un produit - logiciel dvelopp de faon
systmatique. Dans pas mal dentreprises, les activits requises pour tester et valider un logiciel
ne sont parfois admises que pour des logiciels standards acquis et srs de fonctionnement (Ivinza
Lepapa A. C. et Mbuta Ikoko D. A., 2006). Or logiquement, un logiciel dvelopp ne peut pas
tre mis en service si la dmonstration de sa fiabilit (qualit et scurit) nest pas effectue par le
matre douvrage ou son dlgu. La fiabilit est alors une part cruciale dans le dveloppement
logiciel.2
Dans la littrature, plusieurs tudes ont dj rapport que prs de 40 % des projets de
dveloppement des logiciels et/ou dintgration des modules progiciels dans les entreprises
natteignent pas les objectifs fixs au dpart soit en termes de manque de qualit d'exigences, de
faible implication des utilisateurs, de budget, dchancier ou de rsultats livrer (Songini M.,
2005, Vital Roy et alii, 2007). Dautres ont mentionn voire que 15 % des projets de
dveloppement des logiciels informatiques sont annuls avant leur fin avec des effets souvent
dsastreux pour lentreprise et pour les ressources affectes par manque de leur maturit, etc.
(Iacovou C.L. et Dexter A.S., 2005, cit par Vital Roy et alii, 2007). Ces taux dchecs, selon
moi, risquent dtre trop levs en RD Congo suite certaines pratiques malgr la tentative dune
professionnalisation sans un corpus de connaissances clair (manque dtudes ou recherches
locales en matire de conduite des activits de dveloppement logiciel mais aussi les dangers que
pourraient prsenter cette conduite pour nos entreprises, etc.). Nous imaginons propos que la
rponse critique aux diffrents lments voqus se trouve donc situer dans ladoption dun
management plus large, qui couple les valeurs agiles aux techniques de lamlioration continue3
de la qualit et/ou celles bases sur le processus ou la matrise documentaire.
2

Lors de la phase de ralisation, en rapport avec le domaine auquel le logiciel en dveloppement sera exploit
(gestion, tlcommunications, etc.), plusieurs complexits apparaissent. Elles sont parfois simples, difficiles ou trs
difficiles selon quil sagit des structures organisationnelles diffrentes. La notion de tests mais aussi de la qualit
logiciels sont alors trs essentielles pour que le produit logiciel implmenter puisse contribuer la ralisation de la
mission mme de lorganisation face ladquation aux objectifs Q, C, D, P (Qualit, Cots, Dlais et Prestations).
3
Les techniques de lamlioration continue sont bases sur le cycle PDCA : Plan, Do, Check and Act , dit modle
de Deming (1986), qui sapplique presqu tout systme de management de la qualit. Dans un projet informatique
de dveloppement logiciel, le rfrentiel CMMI DEV (2006) de Humphrey W. de Carnegie Mellon, ddi la

Cette rsolution associe est dautant plus exige quelle devrait tre recommande aux quipes
formelles de dveloppement logiciel en RD Congo pour pouvoir leur permettre de livrer un bon
produit, qui respecterait voire les rgles de lart ou mtier, et qui leur viterait de dnaturer les
procdures et les procds qui sont en principe connus et dfinis, partir des besoins initiaux ou
quotidiens (exprims par le matre douvrage ou par les utilisateurs). Cet aspect hypothtique
damliorer les pratiques TI congolaises dans laccomplissement, avec succs, de certains projets
informatiques de dveloppement logiciel rend alors intressant la comprhension et limportance
de disposer, avant chaque activit de vrification et de validation, un modle de tests logiciels (de
niveau de suprieur) produit sur base des rfrentiels existants.
Cette contribution, qui rentre dans la perspective damlioration des pratiques TI congolaises
poursuivie par la structure BSD Congo, particulirement en matire de dveloppement logiciels,
sinscrit dans le cadre des ateliers pratiques que sa cellule Recherche et Dveloppement a
organis et continuerait organiser avec certains tudiants informaticiens sur la modlisation de
tests logiciels dans les milieux universitaires congolais (UNIKIN, ULK, ISTA, etc.). Elle
sorganise alors comme suit : Au point II, nous prsenterons ltat de lart et les grandes lignes
sur lesquels cette contribution sappuie. Il rsume donc, dans une premire phase, quelques
prrequis pour la gestion dun projet informatique de dveloppement logiciel. Dans une seconde
phase seront prsents de faon globale les concepts de programmation et de tests logiciels. Cette
deuxime phase passera aussi en revue les niveaux, mthodes et outils de tests qui seront
complts leur tour des lignes essentielles (exigences dans les activits de vrification et de
validation, modlisation comportementale des exigences dans lUML pour les tests, efficacit de
tests, etc.) aidant llaboration de notre modle de tests. Le point III prsentera notre dmarche
dlaboration du modle de tests qui, sur base des processus et rgles mtiers dcrits (processus
de paiement dans le cadre de DDR), va produire et dtailler lensemble des exigences aligner
dans les activits de tests logiciels. Ces exigences, seront donc vus, ensemble avec les cas et les
rsultats de tests concevoir, comme base de notre bauche de modle de tests dans le cadre de
vrification et de validation du produit logiciel Payment Manager . Une conclusion et
quelques perspectives terminent cette contribution.
II. APPROCHES SUR LE DEVELOPPEMENT INFORMATIQUE
Section I. Lunivers de dveloppement informatique dans les entreprises : contour managrial
et organisationnel
a) Le dveloppement informatique dans les entreprises : Considrations gnrales
Le dveloppement informatique est une activit intensment collaborative. Il consiste analyser
ou tudier les besoins de gestion optimise dune organisation, concevoir des solutions sur la
base de ces besoins, modliser informatiquement ces solutions, cest--dire les transcrire dans
un langage informatique, les implmenter sur une machine ou un systme et les maintenir ou les
faire voluer. Pour ce faire, le gnie logiciel 4, qui soccupe de la fabrication des systmes
informatiss, c..d. des logiciels dans notre cas, traite cette ralisation informatique dans le but
datteindre un objectif spcifique. Cest donc le domaine de linformatique qui allie les capacits
d'analyse et dadaptation un esprit de synthse, tout en mettant en uvre les techniques (outils
conception et au dveloppement des logiciels, sassocie ce modle de Deming pour tenter daider les organismes
dingnierie amliorer la capacit de leurs processus travers 5 niveaux dit de maturit (initial, reproductible,
dfini, gr et optimis).
4
Selon la norme IEEE 610.12, le gnie logiciel est lapplication dune approche systmatique, discipline et
quantifiable au dveloppement, lexploitation et la maintenance du logiciel. Cest--dire, lapplication de
lingnierie au logiciel.

et mthodes) et le sens de crativit. Orient vers le management de projet, il est dfini comme un
ensemble dactivits informatiques effectuer pour atteindre un but unique dfini de faon
spcifique. Cette spcificit de but unique atteindre est trs importante dans les faits, car elle
dlimite voire le champ daction des acteurs cls, dans un projet, qui utilisent ces techniques dites
dingnierie des exigences (une des parties du gnie logiciel qui permet de dterminer quel
systme sera dvelopp, sa scurit et sa durabilit), et un management plus large, qui couple
leur tour les valeurs des techniques agiles de lamlioration continue de la qualit.5
Pour avancer dans ce raisonnement, il conviendrait de rappeler quelques considrations. En effet,
dans une entreprise, le sommet stratgique vise globalement deux finalits : (1) satisfaire les
besoins et les attentes des utilisateurs de ses produits et/ou de ses services et (2) contribuer au
bien tre, au dveloppement et lpanouissement de tous ceux qui y travaillent. Cet ensemble
des caractristiques intrinsques satisfaire des exigences est une aptitude de la qualit repris
dans un systme dinformation6 manuel qualit dune entreprise. Elle est ainsi manage, cette
aptitude, par un systme de management ax sur la dfinition des objectifs qualit et sur la
spcification des processus oprationnels et des ressources affrentes, ncessaires pour atteindre
les objectifs qualit (NF EN ISO 9000 : 2000). Ce systme est donc le systme de management
de la qualit. Comme c'est une activit qui exige une vision et un engagement long terme, les
risques et les limites associes l'amlioration des processus dfinis sont donc prendre en
compte et/ou considrer. Il est alors trs difficile de retrouver la dynamique ncessaire pour le
succs dune telle opration dans une entreprise sans avoir une quipe ddie, un budget allou et
un plan avec des objectifs raisonnables. Cette mthodologie mais aussi les mthodes et outils,
destins soutenir lvolution des systmes dinformation dans lentreprise, peut se dmarquer
des autres domaines stratgiques, mais ne peut et ne doit en aucun cas en tre dissoci, puisque
leurs rles sont parfaitement identifis par les diffrents processus d'une organisation et sappuie
sur des moyens de dveloppement, dintgration et de production ddis. Ils impactent donc de
manire dterminante limplmentation de la stratgie de lentreprise.
Le gnie logiciel, comme dit au dbut, nchappe donc pas cette rgle, car son problme
fondamental est celui de construire, pour un systme dinformation 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 critres cots et
qualit. Il est donc possible de distinguer les rfrentiels produit qui permettent de fixer les
caractristiques que doivent avoir les composants dun systme dinformation (matriel,
logiciel,...) et les rfrentiels management qui introduisent un niveau organisationnel les
aspects techniques dj pris en compte. Ici, le systme logiciel dvelopper devient une varit
du systme dinformation dans lequel lordinateur est au centre de son traitement de linformation
(systme informatique) et soutient voire son volution, limplmenter, cest donc se poser des
questions relatives sur son rle dans lorganisation et les hommes qui lutilisent (Dupuy et Alii,
1993, cit par Ivinza Lepapa A. C., 2007). Cette approche systmique le fait apparatre, de
manire rcursive et dynamique lors de son implmentation dans lorganisation, la fois comme
un moyen essentiel et un objet principal du management au-del de lordinateur et de la
5

La qualit, dans le domaine de dveloppement et de conception, est vue comme le but ou lexigence ultime
atteindre car elle se retrouve troitement lie la ralisation au point quil est trs difficile de partager distinctement
les activits de dveloppement des celles de qualit.
6
Le systme dinformation, abrg SI, est une reprsentation systmique de lentreprise et de ses activits. En grande
partie immatriel, il est donc complexe (Lemoigne, 1994) et est organis autour des ressources, sous diverses
dimensions (organisationnelle, managriale et technologique) (Reix R., 2004 et Laudon et Alii, 2006).
7
Actuellement, trois types de logiciels existent. Il sagit des logiciels constructeurs, qui sont trs dpendants du matriel ;
des progiciels, dvelopps par les diteurs de logiciel, des botes noires, gnralement paramtrables, assurant telles ou
telles fonctions prcise ; et des logiciels propritaires, dvelopps pour les besoins spcifiques de lentreprise ou de
lorganisation, soit par elle mme ou soit par lintermdiaire de socits de services.

technologie. Ce rsultat provenant dune organisation et/ou dune modlisation permet au

systme dinformation de lentreprise de fournir et de disposer des outils permettant de
garder en mmoire une reprsentation de lactivit du systme oprant au sein de
lenvironnement afin de le mettre la disposition des acteurs de dcision pour quils puissent
piloter, coordonner et finaliser le comportement du systme oprant .8 Cest donc une
implmentation, sous forme de processus en interaction et non de services, qui implique de la
comptence aux acteurs de lquipe du projet tout en prenant en compte les aspects dynamique et
ladoption des mthodes et outils pour minimiser ou matriser les facteurs susceptibles de
compromettre un projet de dveloppement. Ici, lon devra par exemple tenir compte de la qualit
des spcifications produites en amont (spcifications des besoins et spcifications des exigences
qui doivent tre adquates, non-ambigus, cohrentes, vrifiables, modifiables, traables, etc.), et
en aval, des erreurs sur les artefacts produits durant limplmentation, qui ne refltent toujours
pas les besoins rels et ne satisfont presque pas in fine les exigences fournies, pour ne pas
connatre un chec.
Dans ce contexte, le sommet stratgique de lentreprise ou le matre douvrage (MOA) qui met
sur pied une organisation, sous forme de projet, et des moyens srs pour le pilotage des processus
ou des activits lies, va alors confier sa fonction systmes d'information (matre duvre,
MOE, qui apporte alors ses connaissances de l'environnement technique et financire puis son
exprience sur des solutions technologiques au sein de lentreprise), la mission dlaboration en
amont dun document qui spcifie les besoins fonctionnels du produit logiciel acqurir et/ou
dvelopper et, en aval, de dveloppement et/ou dacquisition, soit partiellement ou totalement, de
ce produit logiciel sur la base dun mode de gestion choisi et/ou dcid. Nanmoins, au regard
de la politique de rationalisation des cots mis en place, la fonction financire et la fonction des
approvisionnements de lentreprise, auront aussi leur mot dire sur les budgets allouer
(Antoine Crochet D., 2011).
On se retrouve alors face un projet informatique de dveloppement ou un projet systme
dinformation dont les ressources humaines, techniques, procdurales et mthodologiques
mettre en uvre doivent tre orientes vers lamlioration continue et vers la livraison dun
produit logiciel fiable.
Cette vision commune de gestion des systmes dinformation et de gestion de la qualit dans un
dveloppement informatique sappuie sur la vision globale de lentreprise, mais aussi la nature
de lactivit de lentreprise, sur la dcomposition par processus, la taille de lentreprise et aux
mthodes de gestion que les dirigeants veulent mettre en uvre.
b) Les projets informatiques ou TI : composants et limites
Types et modes dapprovisionnement de projets informatiques
Les projets informatiques construisent des logiciels mais aussi grent les matriels et tout type de
dispositif de communication numrique, qui ne reprsentant que la partie technologique du SI, les
TI.9 Ils soutiennent alors lvolution du systme dinformation dans une entreprise et font partie,
de manire gnrale, des projets systmes dinformation . Leurs objectifs ne sont pas
seulement ceux qui sont rattachs la gestion des difficults (pas seulement techniques) de
conception et de ralisation des logiciels mais aussi celles de la mise en uvre, exploitation et au
8

TARDIEU Hubert, NANCI D., PASCOT Daniel, Conception dun systme dinformation : Construction de la Base
des donnes, Edition dorganisation, Gatan Morin Editeur, Paris, Qubec, 1980 pages 30-31.
9
Les TI (Technologies de linformation), en anglais Information Technology, sont des composantes de nature
technique que les organisations ou les entreprises achtent, dveloppent ou combinent pour constituer linfrastructure
technologique qui permet, par la suite, leur SI de fonctionner.

maintien des services du systme d'information d'une entreprise en sappuyant sur les
architectures informatiques et les rseaux de communications. Ils sont alors complts, ces
objectifs, des plusieurs proprits telles que la scurit des donnes (protection, confidentialit,
intgrit), la scurit des traitements (disponibilit, sret) et la qualit de service (disponibilit
des services, prennit, relation avec les utilisateurs).
Gnralement, il existe deux types de projets informatiques, savoir : les projets dexploitation
informatique et les projets de dveloppement et/ou de maintenance logiciels . Ces deux types
de projets informatiques tournent autour de cinq dimensions fondamentales, savoir : (1) sa
mission, (2) ses activits critiques, (3) les comptences et connaissances de ses membres10, (4) sa
relation avec le reste des units daffaires de lorganisation o il sexcute et (5) sa gouvernance.
Ainsi, les projets de dveloppement, qui concernent lvolution et lentretien des plateformes
technologiques, sont souvent raliss lexterne dune organisation pour des raisons de
productivit et de performance (approche outsourcing ). En faisant lobjet de dveloppement
dun systme logiciel intgrer au sein dun systme dinformation existant, les acteurs de
lorganisation partenaire auront partager par exemple les responsabilits, les risques et les
bnfices ventuels du projet avec les acteurs de lorganisation interne en plus de lobligation de
transfert dexpertises.
Vital Roy et alii (2007) alignent, selon la disponibilit de acteurs comptents et la valeur
stratgique de linformatique dans une entreprise, quatre modes dapprovisionnement distincts
pour rpondre aux besoins de dveloppement logiciels. Il sagit des modes dapprovisionnement
linterne, en partenariat, en impartition11 et en rcupration . Ces modes sont constitus selon
quil sagisse dune vision informatique de dveloppement forte ou faible transformation
organisationnelle. Les modes en partenariat et en impartition constituent tous deux un projet
informatique de dveloppement de type mixte. Cest une structure organisationnelle temporaire
oriente vers laccomplissement dun objectif, le dveloppement du systme logiciel, par le
partenaire technologique interne de lorganisation, c..d. sa fonction systme dinformation
(matre duvre technologique de lorganisation), et un sous traitant (partenaire externe). Ici,
les acteurs impliqus, experts mtier et informaticiens de diffrentes spcialits (concepteurs,
dveloppeurs, designers, testeurs, administrateurs de bases de donnes, etc.), qui unissent et
harmonisent leurs efforts pour faire aboutir ces projets logiciels, ne doivent pas seulement se
proccuper des diffrents processus et procds12 qui sy rattachent [procds prdictifs (V, W,
cascade, ) ou procds synthtiques ou agiles (RAD, XP, Scrum, )], mais aussi de la gestion
des cots, des dlais, du temps, des ressources et des communications suivant les cahier des
charges dfinis.
Organisation et moyens de pilotage dun projet de dveloppement logiciel mixte
En cherchant dlaborer des dispositifs pour conduire un projet de dveloppement logiciel mixte,
bass sur le concept de contrle et de la rgulation qui guide son fonctionnement et son volution,
on aboutit alors la dfinition et au dimensionnement des moyens mettre en uvre. Dans cette
10

Celles - ci sont vues la fois sous langle dun savoir tacite (comptences des acteurs TI dans lutilisation des TI
ou dans la gestion des projets TI mais aussi leur vision retirer du rle des TI dans les processus grer) et dun
savoir explicite (connaissances technologique des acteurs et sur les applications et le dveloppement des SI mais
aussi sur leur gestion).
11
Ce mode dapprovisionnement est parfois appel mixte dans le cas des entreprises de taille moyenne ayant une
valeur stratgique et pour lesquels les ressources et les comptences requises sont en partie disponibles linterne. Il
associe alors, dans ses activits de conception, de ralisation et dimplmentation, le transfert, lacquisition et
lchange dexpertises entre les ressources du projet.
12
Un procd est cet ensemble des moyens et des mthodes permettant daccomplir une activit. En fixant les
procds (quand ceci est ncessaire), on prescrit le comment faire. Ne confondons jamais les mots procd et
processus qui se disent tous deux en anglais process .

foule mais aussi avec la logique voque dans le point prcdant, le chef de projet qui on
confie la destine dun projet informatique devra avoir besoin des variables essentielles, par
exemple un tableau de bord, pour pouvoir de dtecter le plus rapidement possible dventuels
problmes et viter ainsi des situations irrmdiables, et des variables dactions. Ceux - ci vont
lui permettre de pouvoir disposer dun style de gestion comparable celui de leader
transactionnel, orient vers le contrle dans un objectif de maximisation des rsultats et de
stabilit des processus, ou celui de leader transformationnel, orient vers la flexibilit dans un
objectif dadaptation 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 rles de gestion de
Mintzberg H. (1994), et de Quinn Robert E. (1988), sur les divers rles de gestion pour la
recherche de performance dans des contextes organisationnels spcifiques, recommandent aux
chefs de projet les rles de producteur, de directeur, de coordonnateur et de contrleur. Par
contre, pour le profil de leadership transformationnel, ils alignent les rles dagent de liaison,
dinnovateur, de mentor et de facilitateur.
Toutefois, lorsquon se retrouve face une impartition (dveloppement mixte), le chef de projet
client devra ajouter le rle de spokesman tandis que celui de limpartiteur, le rle de
resources allocator . Dans ce mode dapprovisionnement, cest donc la communication13, le
suivi et la coordination, qui constituent voire le gage de succs du projet pilot.
Ainsi, manager un projet informatique de dveloppement mixte est une opration complexe car il
comporte une part importante dincertitude, et la nature du systme dinformation de lentreprise
en accrot les risques.14 Ici, plusieurs rfrentiels sont mis en place dont le corpus de
formalisation est en cours pour certains [des mthodes et des outils (CMMI, COBIT, ITIL,
EBIOS, PMI, ...), au niveau infrieur, et des normes de management (ISO 9001, ISO 10006, ISO
27001, ISO 25000, ), au niveau suprieur]. Dailleurs, pour Frederick P. Brooks (2001), les
projets informatiques de dveloppement logiciel sont incomparables aux autres en raison de
limportance quoccupent voire le produit logiciel et ses processus. Ils sont et restent toujours
difficiles conduire. Nanmoins, les rfrentiels classiques de niveau infrieur mis en place, qui
prnent un enchanement squentiel (parfois lourd) des processus, depuis ltude de faisabilit
jusqu la mise en uvre complte du systme ou du produit logiciel, et les pratiques
complmentaires, dites agiles une contribution professionnelle volutionniste , permettent
actuellement aux quipes de projets de produire, dans un contexte de ractivit, de rduction des
dlais et de livraison, un systme logiciel dont lutilisateur participe totalement sa conception
(Valtech, 2008, Vronique Messager Rota, 2009, ). Notons que ladoption de ces pratiques
complmentaires (dveloppement dirig par les tests, programmation itrative, runions
quotidiennes, etc.), dans une approche damlioration continue, est une consquence positive
pour le management de projets informatiques dans son ensemble. Elles ont pour principal
objectif, sans pour autant rejeter les valeurs cls de lapproche classique qui doivent encore rester
omniprsentes, limplication au quotidien du client au sein de lquipe du projet afin dviter des
incohrences entre le besoin initial et le produit livrer. Pour cela, elles valorisent les individus
et les interactions plutt que les processus et les outils mthodologiques, les logiciels
13

Le manque dune communication dans un projet de dveloppement logiciel peut amener une diffrence de
comprhension entre les diffrents acteurs. En grant lensemble de la communication du projet, le chef de projet TI
devra ainsi informer de manire rgulire et efficace les diffrents acteurs des volutions fonctionnelles (rendre
compte de la performance par exemple) sur chaque processus dfini dans le cadre du projet et pouvoir rflchir sur
une option prendre.
14
Ici, le profil de la fonction SI est trs important et devra tre connu davance. Guy Par et Guillemette Manon
(2007) en propose cinq, savoir : le partenaire, le fournisseur de systmes, le concepteur d'infrastructures, le leader
technologique et coordonnateur de projets TI dans une entreprise.

oprationnels plutt que les documentations exhaustives, la collaboration avec les clients plutt
que la ngociation contractuelle et ladaptation au changement plutt que le suivi dun plan .
Les processus et les activits dans un projet informatique de dveloppement logiciel
Un processus, de manire gnrale, reprsente un ensemble dactivits effectu par une ou
plusieurs personnes dans le but de crer un produit, avec un cot et des moyens matriels. Il est
souvent constitu de sous processus, ou tches, selon une dcomposition hirarchique dont
lactivit est llment du plus bas niveau. Lactivit est donc un processus qui tente de
transformer des entres en sortie.

2013-01-17

Les activits se dfinissent alors comme un ensemble homognes dactions, concourant un

mme objectif, et ncessitant les mmes comptences, et analysant les types de travaux et les
responsabilits oprationnelles. En les dcrivant, on dfinit le quoi faire. Elles possdent alors des
points dancrage ou dinteraction entre eux qui renvoient larticulation des phases dans un
projet. Ainsi, dans une gestion globale de dveloppement logiciel, plusieurs processus peuvent
exister [processus de vrification et de validation (tests, contrles, preuves, etc.), processus de
gestion des anomalies, etc.] et peuvent sinterfrer avec celui de gestion de projet suivant une
approche damlioration continue (figure 1). Ici, la notion dactivits suit donc les mmes
principes que les processus dans le cycle de dveloppement, et leur matrise, comme nous avons
dit prcdemment concernant les procds, est trs essentielle dans lexcution du projet. Elles
INTRODUCTION
englobent
ainsi des phases danalyse, de conception, de programmation, de tests logiciels,
dinstallation,U
etc.
et permettent
une prise en compte des
exigences duINSPIR
MOA par DE
le MOE
pour la
N CVL
DE DVELOPPEMENT
LOGICIEL
LIEEE
ralisation dun produit logiciel.

GP000 : Introduction (v240b)

L. Lavoie (UdeS)
24

Fig.1. Cycle de vie du logiciel inspir de lIEEE intgrant le cycle de dveloppement du logiciel (source : Luc Lavoie, 2007).

En somme, la ralisation de toutes ces activits ou de diffrents processus dans un cycle de vie du
logiciel matrialisent le plan qualit, qui essaie de donner son tour une vision globale et complte
du projet en permettant des effets zoom sur le dveloppement du logiciel mais aussi sur la manire
dont la qualit devra tre assure tout au long de la ralisation du logiciel.
Quant une procdure, elle est dfinie par la norme NF EN ISO 9000 : 2000 comme une manire
daccomplir une activit et traite de son aspect organisationnel en rpondant aux questions de qui
fait? Et quand le fait-il?
8

c) Autres lments considrer dans un projet informatique de dveloppement logiciel.

Plan et clauses qualit dans le dveloppement logiciel
Dans un projet informatique de dveloppement logiciel, le plan qualit logiciel, ou plan dassurance
qualit (PAQ), dfinit les mesures dassurance de la qualit du logiciel pris en sinscrivant dans la
politique globale du MOA en matire de qualit. Il fait donc le suivi de la mise en uvre de
lassurance qualit et la gestion des risques devant tre applique tout au long du projet. Les
recommandations sur le produit logiciel souhait marque alors une problmatique sur sa
fiabilit.15 Il sagit en fait dune priorit pour un projet donn de dveloppement informatique et
constitue son outil de communication de rfrence, pour le management de la qualit, valid par les
parties, o chaque intervenant trouve exposer sa place et son rle, tout en spcifiant quelles
procdures doivent tre appliques pour raliser une tche ou un processus ? Le PAQ fait mention
aux caractristiques logicielles au sein duquel sinstancie la stratgie de test en rapport avec la
qualit. Ces caractristiques forment donc des exigences qualit logicielle et peuvent se mesurer
l'aide des indicateurs ou mtriques ci aprs :
- la maniabilit (communicabilit, exploitabilit et facilit dapprentissage),
- la fiabilit (complexit, tolrance aux fautes ou pannes et auditabilit),
- lefficience (consommation en place mmoire, taille des priphriques et leur
vitesse daccs et temps dexcution des programmes),
- la confidentialit (protection du code et des donnes et mmorisation des accs),
- la couplabilit (standardisation des donnes et standardisation des interfaces),
- la maintenabilit (lisibilit, modularit, traabilit et adaptabilit),
- ladaptabilit (volution facile du logiciel),
- la portabilit (banalit demploi, indpendance et qualit de documentation), et
- lefficacit (cots et gains dus au logiciel).
Ce sont donc des clauses qualit (contractuelles ou non). Dans cette perspective, la version 1.2 du
rfrentiel CMMI DEV de Humphrey W., dvelopp par Software Engineering Institute de
luniversit de Carnegie Mellon, ira mme dterminer que la qualit dun logiciel devra tre en
relation directe avec la qualit du processus utilis pour son dveloppement. Ainsi, actuellement,
pour dvelopper par exemple un logiciel de qualit, un programmeur procde par la cration de
composants16 qui permet de construire par la suite le logiciel. Pour cela, il explore des bibliothques
logicielles antrieures pour trouver et constituer des composants logiciels appropris pour une
nouvelle bibliothque. Cette rutilisation de composants ou des briques logicielles est une des
approches de maturit ou damlioration dans le domaine de dveloppement dite framework (COM
et ses drivs), issu de OLE (Object Linking & Embedding) de Microsoft car on ncrit presque plus
des logiciels partir du nant. Avec cette approche amlioration continue, le programmeur a
seulement lobligation de proposer une architecture logicielle harmonieuse aidant voire palier plus
tard une dgradation logicielle [cfr. modle darchitecture des 4+1 vues (Philippe Kruchten, 2000)

15

Un logiciel est un produit immatriel, reproductible, maintenable et subjectif dont les seules reprsentations
observables sont le code source, l'interface utilisateur et la documentation (spcification dexigences de systme,
documents de tests, manuels utilisateur, etc.). Pour tre considr comme un produit de qualit, le logiciel doit donc
rpondre aux besoins exprims explicitement par l'utilisateur aussi bien qu'aux besoins implicites ou non exprims.
16
Lusage de cette approche modulaire, par une quipe de dveloppement informatique, permet d'assurer au logiciel une
meilleure lisibilit et une meilleure maintenance. Cette approche est voire en phase dmergence et porte le nom de la
programmation oriente composant. Lon doit noter que dans cette approche de dveloppement par et pour la rutilisation
logicielle, un cycle de production - rutilisation perptuel (intgration continue) et une architecture logicielle normalise
est impos.

et modle darchitecture de 4 niveaux de MDA Model Driven Architecture ou architecture base

sur les modles en franais (Xavier Blanc, 2005)].
Gestion des risques
Un projet informatique de dveloppement logiciel, comme dit au dbut de notre document, prsente
des risques que lon doit matriser lors de son excution. Pour Chantal Morley (2004), cette matrise
ou gestion des risques consiste rduire lincertitude par une analyse approfondie des
caractristiques internes et environnementales du projet et laborer des stratgies pour faire face
aux risques plus graves et/ou plus probables . Pour ce faire, il faudra alors utiliser la dmarche
gnrale qui comprend (1) lidentification des risques, (2) lvaluation de leur impact possible sur les
cots, le dlai et la qualit, (3) la dfinition des actions ou la prise des dispositions aptes rduire les
risques jugs inacceptables, (4) le suivi de ces actions et (5) la capitalisation de lexprience.
Ainsi, lors des activits de tests par exemple, lidentification des risques sera ralise voire partir
des diffrents lments analytique du logiciel ou systme sous test (cas dutilisation, processus
mtiers, caractristiques qualit, etc.), en anglais System Under Test (SUT).
Plan de dveloppement logiciel
Cest un document qui dcrit, pour une ralisation logicielle, la dcomposition en produits
(larchitecture du logiciel, les choix technologiques, les modules ou les composants logiciels entres, sorties et traitement -, la conception des interfaces du logiciel avec lextrieur description des donnes changes, de leur organisation en messages, des protocoles dchanges et la conception des bases de donnes) et en fournitures, les moyens mettre en uvre, les tches
ncessaires et les dlais respecter. Le plan de dveloppement logiciel (PDL), suivant les
recommandations de la norme NF EN ISO 9000-3 quon fait appliquer aux activits informatiques
de la norme NF EN ISO 9001, inclut la dfinition et les objectifs dun projet, lorganisation dun
projet et les moyens en personnel, la mthodologie et les phases dun projet, la gestion dun
projet et la vrification logiciel.
Section II. La ralisation de logiciels et les exigences de vrification et de validation
a) Activits cls et leurs considrations
La programmation ou lcriture des codes dans un cycle de dveloppement du logiciel
La programmation constitue lactivit la plus connue et cruciale dans la phase de ralisation. Elle
est appele voire par certains dveloppeurs ou ingnieurs logiciels la phase de
dveloppement . Le Professeur Printz Jacques (2002), en dfinissant la programmation, parle
voire de lme du systme informatique ou du logiciel en dveloppement. Cest donc une activit
qui, dans le cycle de dveloppement, incorpore dautres autres activits qui sont essentielles pour
limplantation du produit logiciel configurer et/ou installer. Elle est btie sur des lments ci
aprs :
- une documentation, base sur lexpression des besoins, lexigence des utilisateurs et
la conception dtaille aidant au dploiement et la maintenance du logiciel ;
- un programme ou module de programme, contenant une suite dinstructions
(algorithmes, structure des donnes en entre et en sortie, codes, etc.) excutables
par la machine ;
- des tests et rsultats de srie des tests ; et enfin
- un environnement intgr dexcution ou de dveloppement (IDE17),
17

Environnement de Dveloppement Intgr, ensemble d'outils intgrs (diteur de texte, compilateur et dbogueur)
ddis aux langages de programmation pour augmenter la productivit des programmeurs qui dveloppent des logiciels.

10

et permet, soit de faon rcursive ou itrative, les tests des programmes informatiques qui, une
fois dploy, assureraient au sein dun systme dinformation les fonctions ncessaires face au
traitement et au stockage de linformation.
Les diffrents programmes informatiques sont crits avec laide des L4G (Visual Basic, C#, Java,
Delphi, Python, Turbo Pascal, etc.) et font parfois apparatre des erreurs, dues essentiellement au
caractre humain et la nature profonde du logiciel lui mme. Ils sont souvent payants ou
gratuits/libres aprs compilation. Ici, le seul effort fournir par les acteurs cls du projet, pour
pouvoir obtenir un produit logiciel fiable et de meilleure qualit, serait de pouvoir corriger ces
erreurs par la mise sur pied dune srie dactivits de vrification et de validation bien ficeles.18 Ces
activits doivent tre au service dune stratgie qui, dans un environnement de dveloppement
logiciel, constitue voire la base dun processus de tests, c..d. la faon dont ses activits de tests
devront tre mises en uvre (figure 2). Le manque de ces activits dans un projet, surtout de type
mixte, peuvent savrer coteux et parfois mme dangereux. Il risque mme au bout du compte
daccrotre le niveau dincertitude dans le dveloppement, surtout si lon dcide encore de se lancer
dans les tests sans pouvoir laborer un modle de tests.
Objectifs

Spcification du test

Scnario

Rsultats et
comportements attendus

Excution et mise au
point du test
Rsultats et comportements
observs lors de lexcution
Analyse / Comparaison
des rsultats

Incorrecte

Analyse et explication
des diffrences

Correcte
Modifications
induites

Archivage du scnario et
des rsultats
Etat davancement
des scnarios de tests

Dans le test

Dans le programme

Gestion de configuration
(sources, tests et documentation)
Fig.2 : Exemple dun processus simple des tests logiciels incluant certaines procdures (source : Printz Jacques, 2002).

Limplmentation de ces activits de vrification et de validation, depuis lexpression des exigences

jusqu' la mise en uvre dun rfrentiel normatif de tests, permet dassurer la fois la productibilit
des scnarios de test, de mesurer leur qualit et de mieux matriser leurs cots. Elle rentre donc dans
18

La vrification logicielle est formelle ou semi formelle, c..d. mathmatique ou exhaustive . On cherche donc
prouver au sens mathmatique que le logiciel (vue comme un modle logique) satisfait sa spcification (vue
comme un ensemble de formules logiques). Cette activit complexe se matrialise soit par des sous approximations
(tests) ou soit par des sur approximations (abstractions). Actuellement, les preuves assistes laccompagnent aussi.

11

le cadre des bonnes pratiques dans le dveloppement logiciel. Elle semble tre couteuse, cette
implmentation, et ce dautant plus que la combinatoire induite par la structure des donnes
dentre, les modes de fonctionnement autoriss, les diffrents paramtrages, est totalement
explosive .19
Le test logiciel : Elment visible et dynamique lors des activits de vrification et de
validation dun produit logiciel en dveloppement
Le test logiciel est lexcution ou lvaluation dun systme ou dun composant par des moyens
automatiques ou manuels, pour vrifier quil rpond ses spcifications ou identifier les
diffrences entre les rsultats attendus et les rsultats obtenus (IEEE 610.12, 1990).20
Il a pour objectif de faire assurer au MOA (client) que le logiciel dvelopp par le MOE, en
rendant visible sa qualit et/ou sa fiabilit, est correct et fournit, dans le temps imparti, les
rsultats sur les entres slectionnes. Il fait donc partie intgrante de la vrification21 dun
produit logiciel dployer et/ou configurer et se clturent par un bilan. Sa maitrise
sapparente ainsi celle du dveloppement logiciel. Dans ce cas, les activits qui sont menes
sont alors insparables des celles de programmation dont elles constituent une forme de dualit.
Ainsi, le procd agile XP (eXtreme Programming), par exemple, qui met en avant une pratique
de tests tout au long dun processus de dveloppement [dveloppement dirig par les tests (Test
Driven Development)], associe aussi les activits de validation qui, leur tour, essaient de
dtecter des fautes ou des inadquations dans le logiciel en dveloppement (Gaudel M.C., 1996)
mais aussi obtenir, au final, la confiance ncessaire de lutilisateur [test dacceptation par la
clientle (Users Acceptance Tests, UAT)] avant sa mise en production (sinon un autre Ariane 501
peut se reproduire).22 Ces activits, dites de contrle technique et qui sont raliser sont ainsi des
confirmations par des preuves logicielles que les exigences spcifies au dbut du dveloppement
logiciel sont satisfaites ou non, suite leur prise en compte par les acteurs cls du projet. A ce stade,
une procdure connexe de gestion des tests, qui prend en charge la majorit daspects de gestion, les
mesures des indicateurs ou des mtriques de test et les rsultats des campagnes de test, sera voire
planifie, et devra permettre aux acteurs impliqus ces activits de mettre en vidence les
drives ventuelles par rapport aux objectifs de qualit.23 Dans ce contexte, le terme valid
dsignerait alors ltat correspondant et valider , la rponse la question : est ce que lquipe
de dveloppement a fait ou fait le bon produit ? . Le terme vrifi , quant lui, dsigne ltat
correspondant et vrifier , la rponse la question de savoir si lquipe de dveloppement a fait
ou fait le produit correctement ?
La vrification, compose des activits de tests (partie prdominante pour les logiciels de faible
taille) et des activits de revues et danalyses statiques, aura alors pour but de dmontrer que les
produits logiciels issus dune phase de cycle de dveloppement sont conformes aux spcifications
(incluant les exigences lgales et rglementaires) tablies lors des phases prcdentes .
19

PRINTZ Jacques, Op.cit., Page 106.

Lors de la ralisation des activits dagrment, qui intgrent aussi lexcution des cas de tests, lon ne tente pas
seulement de dmontrer que le logiciel test ne contient plus derreurs mais aussi de corriger les dfauts trouvs au moyen
de revue de conception, dinspection de code, de preuves, etc. Dans ce contexte, le test logiciel ne fait quaugmenter la
confiance de lutilisateur sur le bon fonctionnement du logiciel mais ne prouve pas au sens formel sa validit.
21
La vrification, compose des activits de tests (partie prdominante) et des activits de revues et danalyses statiques,
a pour but de dmontrer que le produit logiciel est conforme aux spcifications (incluant les exigences lgales et
rglementaires) tablies lors des phases prcdentes (Charpentier P., 2000).
22
Cette rgle de production ou cette faon darticuler les nombreux processus ncessaires au dveloppement dun
produit logiciel ncessite une certaine matrise de rfrentiels applicables de la part des acteurs.
23
La dmarche qualit, comme lexplicite Dominique VAUQUIER (2003), attache une importance particulire aux
activits de vrification et de validation. Sa mise en uvre est base sur les principes de symtrie, de sparation, de
spcification et de clture. Toutefois, lorsque lon tente dagrger ses activits celles de la vrification et de la
validation, la qualit risque de perdre sa spcificit.
20

12

En somme, les activits de validation et de vrification visent le mme but, savoir lvaluation de
la qualit des spcifications produites tout au long du dveloppement logiciel (logiciel compris). Les
tests logiciels, qui en font partie, mme sils reprsentent 30 40 % des cots de dveloppement
suivant son niveau de criticit, restent la seule technique visible et la plus couramment utilise pour
sassurer que le logiciel ralis est correct et rpond aux exigences formules ou convenues au
dpart. Ils tiennent donc un rle central dans la politique dassurance qualit dun produit - logiciel.
La confiance apporte ses activits dpend en grande partie de la pertinence des entres
slectionnes et de la multiplicit de mthodes et doutils actuellement disponibles sur le march.
b) Elments aidant la vrification et la validation dun produit logiciel
Les diffrents niveaux de tests logiciels
La recherche des dfauts ou la dtection des erreurs dans un logiciel, comme nous lavons dit, se fait
prventivement au niveau de chaque phase de son cycle dveloppement. Ainsi, en observant le
modle de dveloppement du logiciel en V (voir figure 3 ci dessous), nous observons que les
diffrentes phases de dveloppement du logiciel, qui sont dcrites de manire squentielle, et par
domaine, sont accompagnes paralllement des sries de tests.
Analyse des besoins
et faisabilit

Installation et tests
systme

Spcifications

Tests dacceptation

Conception
architecturale

Tests dintgration

Conception
dtaille

Tests unitaires

Programmation

Fig.3. Les niveaux de tests dans le modle en V (source : GAUDEL M.C, 1996).

Au fait, quatre niveaux de tests y figurent et sont excuts tous comme un processus de test au fur
et mesure que lon avance dans le dveloppement (programmation de composants, intgration
de composants, conformit avec les exigences, etc.). Ces quatre niveaux dfinissent voire des
jalons intermdiaires de validation, aidant sassurer de la fiabilit du produit - logiciel face aux
besoins exprims par le matre douvrage dans chaque phase de dveloppement concerne. Ci
dessous, les explications dtailles de ces niveaux de tests :
- les tests unitaires ou de composants : ils concernent la vrification de chaque
module du logiciel en isolation. Ils ont pour principaux objectifs de vrifier la
mcanique, lergonomie et la prsentation des programmes, de sassurer que toutes
les rgles sont implantes et de sassurer du bon fonctionnement des interfaces,
rapports et traitements ;
- les tests dintgration : Ils concernent la vrification du comportement relatif des
modules entre eux. Les activits principales sont les enchanements entre modules,
la circulation des donnes, les aspects dynamiques, les squences dvnements
prvus (probabiliste) et les reprises en cas dinterruption. Son but est dactiver les
13

fonctionnalits lies la partie concerne du logiciel partiellement intgre sur base

des processus oprationnels (du ct utilisateur). Ils sont attachs la phase de
conception architecturale ;
- les tests de validation ou dacceptation des fonctionnalits du logiciel : ils
concernent la vrification des fonctionnalits relles du produit logiciel dcrites
lors de la phase de spcification des exigences. Ils vrifient plus particulirement
les fonctions gnrales, les interfaces matriel / logiciel, le fonctionnement temps
rel, les performances, l'utilisation et l'allocation des ressources (Charpentier P.,
2000) ; et
- les tests systme ou de conformit : Ils consistent tester le logiciel dans un
environnement similaire lenvironnement de production (vision du concepteur lors
de la phase danalyse des besoins et de faisabilit). Ici, les revues et les analyses
quon fait permettent alors de rpondre la question de correspondance (porte)
avec le logiciel livrer, ce qui dpasse par moment l'tude des tests du logiciel.
Ces quatre niveaux dcrits constituent des groupes d'activits de tests qui sont grs ensemble, en
rapport direct avec les responsabilits telles que dfinies dans les diffrentes phases du projet. Ils
sont souvent excuts suivant les caractristiques et les modalits logicielles fixes (performance,
ergonomique, installation, fonctionnelle, robustesse, vulnrabilit, etc.).
Les mthodes et les outils dans les tests logiciels
Les mthodes et les outils, comme nous lavons mentionn la section I de la prsente
contribution, sont des rfrentiels de niveau infrieur, classs par secteurs dactivits (logiciels,
production, scurit, projets, etc.) et qui, au niveau suprieur, deviennent un ensemble de
normes.24 Ils sont choisies spcifiquement en fonction du contexte de projet (dveloppement en
partenariat, en impartition, en interne, etc.) et introduisent la notion de la qualit tout en
contribuant au progrs des pratiques scientifiques soit par une approche de management base sur
lamlioration ou sur les processus ou encore la matrise documentaire.
Pour les tests logiciels, deux mthodes ou techniques de vrification et de validation existent
actuellement. Elles dterminent le degr de rigueur exig dans un projet de dveloppement afin
dviter les fautes dont le logiciel peut tre la cause. Ces sont donc des protocoles exprimentaux qui
provoquent un ensemble de rponses (rsidu d'erreurs) qui montrent que la transformation oprer
par le programme est correcte ou non et sont complmentaires. Il sagit en fait de :
- mthodes danalyses statiques : ce sont des techniques qui se rfrent lanalyse
danomalies, aux lectures croises, linspection, lapproximation, etc. qui sont
opres au moment de la compilation. Elles traitent les tests du logiciel sans
excuter ce logiciel sur des donnes relles et se rapprochent de lensemble des
valeurs ou des comportements qui dcoulent dynamiquement lexcution du
programme. Appeles parfois tests statiques, ces techniques sont utilises pour
vrifier des programmes, dans le but de dcouvrir des bugs car elles oprent sur les
codes.
Ces techniques sont aussi particulirement importantes pour les cas de tests qui
mettent en jeu le paralllisme. Ici, les techniques dynamiques de tests sont parfois
peu applicables en raison du non dterminisme des rsultats obtenir, etc. Le
dbogueur de lIDE Visual Studio est parmi les outils ddi ; et

24

Comme lnonce Jacqueline Sidi (2003), les normes sont donc des outils plutt que des exigences inestimables
pour les entreprises. Elles sont utilisables au quotidien dans un contexte oprationnel, mais aussi pour la formation
du personnel qui devra sapproprier le produit logiciel en dveloppement.

14

- mthodes dynamiques de tests : ces mthodes ou techniques sont souvent appliques

des tests de spcifications fonctionnelles ou dexigences de qualit (robustesse,
performance, etc.) du systme. Cette srie de tests sont donc des tests fonctionnels
(boite noire), qui ont charge de vrifier, partir des certaines valeurs dentre, que
les diffrents comportements du systme sont conformes ses spcifications
(rsultats attendus bass sur des valeurs de sortie). Elles reposent aussi sur
lexcution 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 entres possibles. Ici, les techniques de tests
disposent des quatre activits principales qui sont la slection (dun sous ensemble
des entres possibles du logiciel, appel jeu de tests), la soumission du jeu de tests,
le dpouillement des rsultats et lvaluation de la qualit des tests effectus. Ces
deux types de tests, fonctionnels et structurels, sont donc complmentaires.
Toutefois, les tests structurels saccompagnent toujours de tests dits de non
rgression qui interviennent toujours aprs 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 mme cadre et qui permettent galement lquipe
de tests de bnficier en temps rel des indicateurs de pilotage et danalyse du processus de tests
dclench, donnant ainsi une image claire et immdiate de la matrialisation des niveaux de tests,
deux catgories existent. Il sagit des outils de gestion de tests et des outils dautomatisation de tests.
Les outils de gestion de tests sont des exigences et aident les membres dune quipe de
dveloppement de sassurer de latteinte des objectifs V, V, T (Validation, Vrification et Test) sur
le comportement attendu du produit logiciel. Ils donnent, suivant les rgles de lart, la possibilit
de produire des livrables observables (documents types ou rsultats de tests sous forme
documentaire). Le plan de tests, qui correspond une description dtaille de cas de tests (sur base
des exigences mtiers), de stratgies arrtes et de certains documents enregistrant les vnements
lors de tests et les dcisions prises25, font partie de ces outils de gestion de tests. Les modles de tests
logiciels que ces outils accompagnent sous souvent effectus manuellement. Par contre, les outils
dautomatisation de tests, considrs hors du primtre des outils de gestion de tests, effectuent des
types de tests qui sont impossibles effectuer manuellement. Ils amliorent, eux, la productivit et le
rendement attendus sur les tests, principalement les tests unitaires, les tests dintgration et les tests
de non rgression. HP QuickTest Professional, Silk Test de Borland, Visual Studio Unit Testing
Framework (MSTest.exe), Pex (Microsoft), Test partner, Refertest, etc. sont compts parmi les outils
dits dautomatisation de tests et remdient au principal facteur dchec par une maintenabilit des
scripts (un bout de code qui teste un autre code automatiquement).26
Toutefois, dune manire gnrale mais aussi professionnelle, pour utiliser ces outils aidant la
vrification mais aussi la validation dun produit logiciel en dveloppement, lon doit voquer
dabord la problmatique dexigences qui devra dcrire, au fait, les liens de causalit relatifs une
action du logiciel. Cest ainsi quavec lesprit dagilit recommand actuellement dans lexcution
de projets informatiques de dveloppement logiciel (rduction de cot et de dlai, performance et
25

La dcision est souvent dclenche dans un projet par les problmes dordre organisationnel que les managers
rencontrent. Elle est donc prise, selon Simon H.A. (1980), grce au processus dit IMC (Intelligence Modlisation
Choix).
26
Un script de test reste lapproche de succession doprations manuelles la plus naturelle pour lexcution par
exemple dun cas de test sur un logiciel simple car une fois lanc, on clique partout et on regarde sil fonctionne.
Cette approche est essentielle pour dtecter des erreurs et amliorer la confiance dans l'aptitude du systme
accomplir sa mission, mais insuffisante pour qualifier le comportement d'un systme (Charpentier P., 2000). On
trouve ses cts des bancs de test pour des systmes plus complexes.

15

ractivit puis qualit), les quipes exprimentes de dveloppement logiciel, qui utilisent les
procds agiles (XP, RUF, SCRUM, etc.), commencent aussi utiliser ds la phase de spcification
ces outils de tests cits, 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 gnrer manuellement ou
automatiquement, qui matrialisent la cohrence et/ou la traabilit entre les lments des diffrents
artefacts produits par les diffrentes activits dun processus de dveloppement, constituent alors un
modle28 comportemental de logiciels sous test, ou tout simplement un modle dexigences (JeanMarc Jzquel, 2006, Xavier Blanc, 2005, etc.). Ces modles comportementaux de logiciels sont
construits partir des exigences ou des spcifications textuelles qui peuvent tre fonctionnelles
(fonctions spcifies pour le logiciel, point dentre ou de sortie de la phase de spcification) ou
structurelles (fonctions codes dans le logiciel).
Les exigences fonctionnelles, des outils normatifs non ngligeables lors de llaboration
dun modle de tests de logiciels
Les exigences ou les spcifications constituent, dans une modlisation, des contraintes que le
MOE devra respecter lors des tests dans le but de faire disposer rellement au MOA le produit
quil souhaite et/ou quil souhaitait. Elles sont produites, ces exigences, partir des activits de
collecte, rdaction, comprhension et valuation en amont de besoins mtiers des utilisateurs.
Cette srie dactivits indpendantes, lies lingnierie des exigences mais aussi lingnierie
des modles, est donc vue comme un processus de raffinement itratif mais aussi de
modlisation, laide de langages munis dune smantique formelle (UML par exemple car il
permet la modlisation de systmes indpendamment de toute dmarche ou de plate forme). Au
fait, ce processus se termine lorsque les exigences sont suffisamment prcises ou reformules par
le MOE pour ainsi appliquer les techniques de vrification et de validation dans un systme sous
test. Cette matrialisation de lIDM va produire un modle qui sera utilis pour rpondre des
questions sur le systme modlis. Il ressort de cette logique de substitution que ces exigences
reformules, vrifier sur un produit logiciel visant la qualit, expriment un modle dynamique
dexigences (Computation Independent Model, CIM) et directement oprationnel pour dautres
phases de dveloppement du logiciel. Ainsi, ce modle dexigences va son tour donner corps
un modle de tests systme et un modle danalyse ou des modles extra fonctionnels
(Platform-Independent Model PIM). Cette transformation de premier niveau, qui garantit les
liens de traabilit entre les modles et les besoins exprims par le client, est essentielle suivant
lapproche MDA (architecture 4 niveaux) la prennit des modles. Ainsi, les techniques de
vrification et de validation, comme explicit dans les points prcdant, qui sont bases sur les
stratgies de tests, vont sappuyer sur le modle dexigences pour dfinir les algorithmes et les
critres de slection des cas de test raliser sur un systme sous test.
Derrire cette approche formelle ou semi formelle (MDA), dite aussi de transformation de
modles (figure 4), le modle danalyse et/ou les modles extra fonctionnels (PlatformIndependent Model PIM), qui sont des captures de plusieurs informations relatives au domaine
mtier, initialement disperses dans une collection de donnes dentre (besoins des utilisateurs,
processus mtiers, etc.), donneront corps leur tour un modle de conception (PlatformIndependent Model PIM et Platform Specific Model PSM) mais aussi un codage du systme
(Platform Specific Model PSM). Cette tape est voire ncessaire pour dmarrer avec les tests de
27

On ne peut viter lvolution des exigences. La seule chose faire cest de chercher maintenir leur traabilit.
Un modle est une reprsentation ou une description dun logiciel ou dune partie dun logiciel dans un langage
bien dfini mais des diffrents niveaux dabstraction. LIngnierie Dirig par les Modles (IDM), Model Driven
Engineering (MDE), en anglais, qui est son paradigme de modlisation plaant les modles au cur du processus de
dveloppement pour en faire les lments cls par lesquels les logiciels sont gnrs, dcrit un logiciel avec un haut
niveau d'abstraction indpendamment de la plate forme utilise, d'un point de vue utilisateur. Il sappuie sur
linitiative MDA (Model Driven Architecture), mene par lOMG (Object Management Group).
28

16

niveau infrieur (unitaires et dintgration) permettant daffiner la structure et ltat interne du

systme 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 activits infrieurs de tests (tests unitaires et tests
dintgration), pour gnrer et excuter, au moyen des algorithmes, soit par gnration alatoire de
codes ou soit par prdicat de chemin, ou encore par excution symbolique des chemins ou par
excution concolique, les cas de tests dun logiciel sous test mais aussi amliorer la dtection des
bugs, la qualit logicielle, la traabilit et lvolution des exigences reformules.

Fig.4. les transformations de modles dans un cycle de dveloppement (source : Jzquel J.M, 2006)

Quant au modle de tests systmes, qui exprime une vision externe des gestionnaires ou des
utilisateurs sur les actions ralisables ou les comportements attendus dun logiciel sous test, cest
un modle prenne et productif (PIM) qui est donc constitu par une abstraction des informations
relatives aux interactions de lutilisateur sur le systme (cas dutilisation, scnarios dutilisation,
etc.) dans le but de prouver manuellement ou automatiquement la qualit du logiciel sous test.
Toutefois, dans lensemble, plusieurs mthodologies dites formelles ou semi formelles, suivant la
taille et le type de projet, permettent llaboration de modles de tests, que a soit au niveau
suprieur ou au niveau infrieur. Ces mthodologies servent donc des modles dentre aux outils
danalyse (choix de critres de slection de test) une fois exempt dincohrences statiques ou
dynamiques afin de pouvoir gnrer les cas de tests et permettre leurs excutions dans un logiciel
sous test. Ainsi, la mthodologie UML29, qui transforme certains modles avec laide de ses
diagrammes et du langage dexpression de contrainte OCL, permet la simulation au niveau de
conception de codes, rendant le systme beaucoup plus sre puisque des tests de dbogage (tests
unitaires et dintgration) auront t faits avant la compilation de codes. Cette mme
mthodologie permet aussi de tester les comportements dun systme sous test (tests de niveau
29

A proprement parler, le formalisme UML intgre le langage OCL (Object Constraint Language) qui est un langage
dexpression ou de haut niveau dabstraction permettant de dcrire des contraintes sur des modles objet. Une
contrainte est une restriction sur une ou plusieurs valeurs dun modle non reprsentable en UML. OCL donne ainsi
des descriptions prcises et non ambigus du comportement du logiciel en compltant les diagrammes UML et en
dfinissant des pr-conditions, des post-conditions ou des invariants pour une opration. Ainsi, pour laborer un
modle de test ou de niveau suprieur, lon ne devra pas reprendre toutes les phases conceptuelles de dveloppement
mais certains diagrammes UML (cas dutilisation, de squence et dactivit) dont les lments servent de support de
matrialisation des relations dinstanciation avec les lments de modle dexigences.

17

suprieur) mais aussi permettre son dploiement et sa configuration complte. Ceci se fera bien
sr indpendamment du langage30 et de la plate-forme cible puis sparera le contenu logique de la
prsentation physique.
Efficacit de tests logiciels dans un projet informatique de dveloppement logiciel
Lefficacit est un concept trs complexe, floue, instable, polymorphe et polysmique qui est
souvent souhaite lors des activits de vrification et de validation qui sont les deux approches
utilises pour les tests logiciels. Ainsi, dans notre contexte, lefficacit souhaite pour une srie de
tests logiciels dpend crucialement de la qualit des cas de tests et des donnes de tests gnrs
manuellement ou automatiquement mais aussi de la dmarche de tests qui se doit donc de respecter
plusieurs impratifs : la dfinition des politiques dfinissant les modalits dapplications de ces tests
(planification dans les diffrentes phases du cycle de vie du logiciel, frquence et conditions
dexcution, rle de chaque membre de lquipe), le dploiement de linfrastructure (matrielle et
logicielle) permettant la mise en uvre de ces politiques ainsi que les processus assurant le contrle
du respect des politiques, lenvironnement matriel et de dveloppement pour lintgration
fonctionnelle et la mise en uvre de tests et ensuite lexpertise ncessaire de lquipe pour la gestion
du plan de tests, la cration de donnes fonctionnelles et de tests.
Lefficacit de tests, cest aussi le modle de tests lui mme, gnr partir dun modle
dexigences, qui doit se conformer aux procdures et aux conditions pralablement dfinies au
dbut dun processus de dveloppement (omniprsence ou pas) dans le but de pouvoir disposer
dun logiciel fiable.
c) Quelques autres dfinitions cls relatives aux tests.
La stratgie de tests
Cest un pralable ncessaire pour la mise en place des objectifs de tests. Elle tmoigne donc
dune rflexion sur la pratique relle des tests (conception de cas de test, criture de scripts de
test, fourniture de donnes de test, observation et analyse rsultats de test et rdaction dune
documentation associe pour le test, etc.), visant augmenter la fiabilit du produit logiciel et
diminuer les dfauts dus sa programmation (objectif qualit). Son absence, comme dit
Charpentier P. (2000), indique un risque dimprovisation pour les tests mais aussi pour les autres
phases du dveloppement logiciel.
Lobligation de test
Cest une spcification partielle de test qui dcrit une proprit juge importante dans un contexte
donn.
Le cas de test
Cest le chemin fonctionnel mettre en uvre pour atteindre un objectif de test. Il spcifie donc la
manire dont une fonction ou une combinaison de fonctions (scnario de test) doit tre teste ou dont
il convient quelle le soit.
Le scnario de test
Cest un ensemble autonome et cohrent dinteractions avec le logiciel regroupant un ou plusieurs
tests lmentaires, et les ventuelles phases prparatoire et finale de ces tests lmentaires. Ici, le
cycle de vie pour ces tests logiciels va se fabriquer en fonction des objectifs qui rsultent de la
stratgie de vrification et de validation adopte et des informations disponibles pour excuter des
scnarios de cas dutilisation, mais aussi les diffrentes exigences qui y sont rattachs.
30

Notons quen dehors de lUML, lIDM utilise aussi dautres langages de modlisation qui sont ddis un domaine
particulier. Le DSL (Domain Specific Language DSL) par exemple offre aux utilisateurs des concepts propres leur
mtier (le mtier dont ils ont la matrise).

18

Les preuves logicielles

La preuve dmontre et/ou tablit la vrit de quelque chose. Cest donc une opration mathmatique
par laquelle on contrle lexactitude dun calcul ou la justesse de la solution dun problme. Dans le
domaine de dveloppement logiciel, la preuve sutilise des diffrentes fins bases sur les mthodes
formelles car un systme ou un logiciel vrifier et/ou prouver doit tre soit formel ou semiformel.31 Malgr cela, lorsquon procde ces preuves logicielles, au moyen des outils assists, le
test dfini sert seulement dmontrer sur une spcification ou une exigence quune certaine situation
se produira toujours ou ne se produira jamais. Ainsi, avec le regain actuel des pratiques de
gnration automatiques de tests structurels, les solutions MBT, qui gnrent et prouvent
automatiquement des spcification ou des exigences, risquent de faire retrouver la communaut
scientifique face un problme dindcidabilit ( ce jour, il ny 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 DUN MODELE DE TESTS POUR LE PAYMENT MANAGER
Section I. Dmarche pour llaboration du modle de tests
a) Objet et dmarche dlaboration de lbauche
Nous comprenons, tel que dcrit dans lintroduction, que lobjet de notre contribution concerne
lincitation dusage, par les professionnels TI congolais, des mthodes, outils et techniques
dingnierie logicielle et dexigences, classiques ou agiles, pour la vrification et la validation dun
produit logiciel. Au cours des points prcdents, nous avons essay de prsenter globalement les
lments qui rentrent dans les caractristiques dun projet informatique de dveloppement logiciel en
gnral et mixte en particulier, pour pouvoir produire efficacement un bien livrable (produit
logiciel) respectant les critres de qualit mais aussi ceux de ractivit et de performance contraints
par les budget et dlai imposs. Ces lments concernaient particulirement les tests logiciels, ses
mthodes et outils, mais aussi les exigences aidant laborer des modles de tests. A ce niveau, une
prsentation cavalire des exigences fonctionnelles ou structurelles dans le contexte dingnierie
dirige par les modles, suivant lapproche MDA (support indispensable de gnration de code, de
documentation, de tests etc. directement depuis les modles), a t effectue o nous avons list les
diffrentes phases de transformation de modles permettant daboutir un modle de tests de niveau
suprieur ou de niveau infrieur. Le modle de tests de niveau suprieur ncessite gnralement
lintervention dun expert pour effectuer certaines tapes de la transformation tandis que le modle
de tests de niveau infrieur fait lobjet doutils de tests automatiques qui se servent des processus
stochastiques pour gnrer de faon automatique les cas de tests mais aussi amliorer la dtection
des bugs, la qualit logicielle, la traabilit et lvolution des exigences. UML, en y ajoutant les
contraintes OCL, est prsent comme une approche favorite pour sa matrialisation.
Maintenant, nous allons essayer de produire lbauche dun modle de tests de niveau suprieur sur
base de notre retour dexprience comme chef de projet IDENT - ITS , un projet mixte conduit
suivant les procds agiles combins, XP et Scrum, pour produire un logiciel de qualit dans le dlai
exig, 5 mois environs. Cette bauche est donc produite grce un ensemble de questionnements
dordre managrial et organisationnel suivant une dmarche de concrtisation manuelle ncessitant
31

Dans un systme configurer et/ou installer, la preuve dune formule est une drivation, cest - dire une suite de
formules qui se termine par la formule prouver, et telle que la premire formule est un axiome. Toute autre formule est
soit un axiome, soit la conclusion dune rgle dinfrence dont les prmisses apparaissent avant elle dans la suite.

19

notre expertise tant au niveau de la connaissance de larchitecture interne du systme que celui de la
connaissance des interfaces relles du systme. Cette dmarche est en partie la rponse aux efforts de
membres de lquipe du projet lors du processus de dveloppement du logiciel Payment
Manager . Elle intgre et dtaille ainsi lensemble des rgles mtiers de paiement dcrits dans le
cadre de DDR (rgles de gestion, cas et scnarios dutilisation) et les exigences spcifies pour les
tests logiciels et certains lments de stratgie de tests qui, formellement, devraient se retrouver dans
un plan de tests.
Les tests logiciels tant une activit cratrice qui exige une moyenne des comptences de la part des
acteurs impliqus, il existe donc plusieurs aspects considrer. Dabord laspect qui sattache la
structure du systme sous test (SUT), telles que ses structures de donnes, son code, etc. et ensuite,
celui de la dynamique du systme sous test (tests systme et de validation via lapproche dite boite
noire ), reprsent gnralement par le biais dinterfaces implmentes. Cest sur ce deuxime
aspect que nous nous focalisons. La mthodologie UML, utilise dans la formalisation de besoins
des utilisateurs, de processus et de rgles mtiers mais aussi didentification de cas dutilisation en
exigences de tests puis en cas de tests, a t plus quune phase de conception pour produire notre
bauche de modle de tests. Cest pourquoi elle ne sera pas dtaille dans sa totalit. Toutefois, nous
illustrons partiellement quelques lments et quelques interfaces de lapplicatif renforant les
rsultats attendus sur des cas de tests conus.
Les lignes qui suivent exposent donc quelques points essentiels de ce modle, qui donnent corps aux
notions abstraites dcrites aux points II.
b) Rfrentiels normatifs utiliss
Documents normatifs
Les documents normatifs cls ci dessous ont t dune grande utilit lors de llaboration de notre
modle de tests car certaines de ses lignes avaient servi lors des activits menes tout au long du
processus.
AFNOR, 1995
[12207] NF ISO/CEI 12207:1995 (F)
Traitement de linformation Ingnierie du logiciel Processus du cycle de vie du logiciel
AFNOR, 1996
[NF X 50-164] NF X 50-164
Relations clients fournisseurs Guide pour ltablissement dun plan dassurance qualit.
AFNOR, 1999
[9000-3] NF EN ISO 9000-3:1999 (F)
Normes pour le management de la qualit Partie 3 : Lignes directrices pour lapplication de lISO
9001 au dveloppement, 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 linformation Ingnierie du logiciel Processus du cycle de vie des systmes
ISO/CEI, 1998
[15846] NF ISO/CEI 15846:1998 (F)
Gestion de configuration du logiciel
ISO/CEI, 1999
[NF LOG] NF LOGICIEL
Rglement de la marque NF Logiciel Exigences pour le dossier de test du logiciel Annexe 1.2
20

ISO/CEI, 1999
[9126] NF ISO/CEI 9126:2000 (F)
Technologies de l'information Qualit des produits logiciels Partie 1: Modle 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 Spcification dExigences de Systme
[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
dveloppement de ce logiciel. Dans le cadre dlaboration de notre modle de tests, ils ont eu aussi
un regard critique.
[CCEB]
[PDL]
[PGT]
[MP]
[DSFT]
[LRI]
[DALM]
[DCL]
[MU]
[PFD]

Cahier des Charges et de lexpression des besoins

Plan de Dveloppement Logiciel
Plan Global de Travail
Macro Processus des diffrentes phases dIVO (Identification, Vrification et Orientation)
Document de Spcifications Fonctionnelles et Techniques
Liste des Risques Inhrents
Document dArchitecture Logicielle et de Maintenance
Document de Conception Logiciel
Manuel de lUtilisateur
Plan de Finalisation de Dveloppement (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) Lquipe de tests : responsabilits et rles
Le tableau ci dessous indique les tches requises et/ou dfinies pour les tests de Payment
Manager . Il indique aussi les diffrentes fonctions alloues initialement pour chacune de tches
couvrir.
Fonctions
Responsables mtiers

Tches
Observation sur les tests

Responsable de tests

Garant de tout le processus dexcution et de suivi

de tests, dfinition de la mthodologie et de la
stratgie de tests
Ralisation de larchitecture de tests, critique des
scnarii des tests et rdaction de dossiers et
rapports sur les tests
Rdaction des exigences de tests, spcification et

Architecte de tests
Concepteurs de tests

Noms des entits impliques

CELPAY, BIO ID et UEPN
DDR
UEPN - DDR
CELPAY, BIO ID et UEPN
DDR
CELPAY, BIO ID et UEPN

21

Programmeurs
Testeurs

ou

fourniture des cas de tests,

Codage, ralisation de chaque niveau et type de
tests et consignation de rsultats de tests

DDR
CELPAY, BIO ID et UEPN
DDR

Section II. Elments dlaboration du modle des tests pour le Payment Manager .
a) Considrations gnrales
Le matre douvrage du projet TI assurant le dveloppement de Payment Manager
Le Dsarmement, la Dmobilisation et la Rinsertion, en sigle DDR, a un caractre multisectoriel et
exige une grande capacit de coordination politique, stratgique, oprationnelle et technique.
Le cadre institutionnel de cette structure au niveau de la RDC, connu sous le nom du Programme
National de Dsarmement, Dmobilisation et Rinsertion (PNDDR), est dfini par le dcret
n04/092 du 16 octobre 2004 puis, bien avant, par les dcrets n03/041, 03/042 et 03/043 du 18
dcembre 2003, portant cration du Comit Interministriel charg de la conception et de
lorientation en matire 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 activits du comit technique de planification et de coordination du DDR
(CTPC/DDR).
Au mois de juin 2007, le dcret portant cration, organisation et mise en place de la CONADER a
t abrog et remplac par un nouveau dcret n07/057 du 14 juillet 2007. Ce nouveau dcret crant
et organisant lUnit dExcution du Programme National de Dsarmement, Dmobilisation et
Rinsertion, UEPN-DDR en sigle, marque la fin de la premire phase (2003 2007) et le dbut de la
seconde phase du PNDDR. Cette structure a donc remplac la CONADER et a pour mission le
parachvement du processus DDR en RDC. La porte stratgique de lUEPN-DDR est celle (1)
dElaborer les critres de dsarmement, dmobilisation et proposer les mcanismes de Rinsertion ;
(2) de Planifier les activits en rapport avec les processus de Dsarmement, Dmobilisation et
Rinsertion et (3) dExcuter et parachever le PN-DDR. Matre douvrage (dlgu) du
gouvernement congolais en la matire, elle est donc rattache au Ministre de la dfense nationale et
des anciens combattants mais travaille troitement avec les autres services comptents de l'tat, de la
socit civile (Institutions nationales, ONG locales, etc.) et les partenaires extrieurs (Agences du
systme des Nations Unies, ONG internationales, Agences de coopration bilatrale, etc.).
LUEPN-DDR est dirige par un Administrateur Gnral, assist des experts et spcialistes recruts
selon les rgles et les procdures de la Banque Mondiale et de la Banque Africaine de
Dveloppement. La gestion fiduciaire est assure par KPMG / RDC. Cette combinaison de rles fait
disposer lUEPN DDR dune culture dentreprise, non traditionnelle, influence par les pratiques
institutionnalises congolaises.
Le systme dinformation du matre douvrage, les diffrents processus mtiers et le profil de
lquipe TI assurant le dveloppement de Payment Manager
Le systme dinformation de lUEPN DDR, issu des cendres de la CONADER, est rest organis
autour des plusieurs processus mtiers dont trois en reprsentent le cur. Il sagit au fait :
- du processus denregistrement ou identification des ex combattants dsarms
(identification avec capture de liris sur lapplicatif Ident Congo ) ;
- du processus de paiement des ex combattants dsarms et dmobiliss (indemnit
transitoire de substance donner lex combattant via la technologie de paiement
lectronique par mobile) ; et
- du processus de rinsertion socio conomique des ex combattants dsarms et
dmobiliss (Allocations des bnfices pour une rinsertion viable avec laide dun
applicatif de suivi de rinsertion, ASR ).
22

Ces trois processus mtiers bnficient dune gestion intgre informatise, par le biais dune
infrastructure technologique (Data center) implmente par la fonction systme dinformation
de lUEPN DDR, aidant la centralisation, synchronisation et traitement des donnes issues des
activits didentification, de paiement et de rinsertion. Quant aux autres processus de gestion lie
aux fonctions horizontales du programme (administrative, financire, budgtaire et logistique), ils
sont oprationnaliss au sein de linfrastructure technologique grce aux applicatifs et outils
standards tels que le Tom pro, lOffice intgrale de Microsoft, lISA Server, le Rancid, le Request
Tracker / Trac, lIPcop, etc. tournant sous environnement Microsoft et/ou Linux.
Le dpartement MIS : Management Information System, qui sert de matre duvre technologique
de lUEPN DDR, assure la gestion de cette fonction systme dinformation mis en place et
intgre trois de cinq rles de Guy Par et de Guillemette Manon (2005) sur la fonction TI, savoir la
fourniture des systmes, la conception dinfrastructure technologique et la coordination de projets
TI. Les ressources faisant partie de cette fonction organisent ses activits avec laide de deux
partenaires cls : BIO-ID Technologies SA (impartiteur propos par les bailleurs de fonds pour son
expertise comme intgrateur de la technologie iris dans les diffrentes solutions informatiques mises
en place par le dpartement MIS) et CELPAY RDC Inc. (partenaire propos par les bailleurs de
fonds pour la paie des ex combattants dmobiliss).
Rgles cls de gestion en rapport avec le processus de paiement
Lors de la premire phase du programme DDR (2004 2007), le processus de paiement au niveau
dun site denregistrement ou de paiement reprenait les entits et/ou acteurs suivants : Bio ID
Technologies (Gestionnaire de base de donnes et Oprateurs de saisie), CELPAY (Agents
payeurs) et UEPN DDR (Superviseur). Ce processus a t modlis avec laide dun
diagramme dactivit. Les rgles cls de gestion sur ce processus de paiement renfermaient les
bases suivantes :
- Un ex combattant ayant choisi la dmobilisation, aprs son identification
biomtrique avec capture iris dans un centre dorientation, reoit en numraire une
et une seule fois un montant de 110 $ USD ; et
- Aprs son installation effective dans la communaut quil aurait choisi, lex
combattant dmobilis va tre accompagn dans sa rinsertion par loctroi de 300 $
USD en douze tranches de 25 $ USD et de certaines autres bnfices (formation,
outils, etc.) .
La formalisation de ces rgles cls de gestion sur le processus avait produit des procdures (cas
dutilisation) aidant son oprationnalisation effective. Nous citons ici la constitution et la
validation de listes de paiements, gnres partir donnes biomtriques didentification
synchronises au niveau du Datacenter, la transmission de ces listes par centre dorientation
lagent payeur, la prsentation de la carte de dmobilisation sur le site didentification ou de
rinsertion par le dmobilis pour tre pay, les rponses aux questions types pour sassurer de
lauthenticit du dmobilis bnficiaire, etc. La paie aux ex combattants de ces Indemnits
Transitoires de Subsistance, dits ITS , est donc assure avec laide dun applicatif de CELPAY
via mobile.
Contexte de dveloppement et exigences textuelles de Payment Manager
A la fin de la premire phase du programme, suite aux critiques du matre douvrage sur la non
performance de lapplicatif de paiement de CELPAY (manque de couverture tlphonique dans
certains coins du pays, etc.) mais aussi les recommandations de ses partenaires et laudit dErnst &
23

Young France de 2006, en rapport avec le dysfonctionnement de lapplicatif de CELPAY dans

lenvironnement congolais causant un lger cart avec la cible dfinie dans le document initial du
programme, un besoin damlioration du processus de paiement tait est n. En tant que Spcialiste
MIS et chef de projet dintgration informatique, ( IDENT ITS : identification, paiement et
rinsertion), de lUEPN DDR, nous avons soumis, ensemble avec les chargs de projet de
limpartiteur (Bio ID Technologies SA) et de lagent payeur (CELPAY RDC Inc.), sur base de
notre retour dexprience dans cette premire phase du PNDDR, une proposition en rapport avec les
nouvelles procdures envisages et les besoins visant lamlioration de lensemble du processus de
paiement. Aprs la dcision du matre douvrage, les rgles cls de gestion devenaient alors :
- le paiement de 140 $ USD lex combattant lors de la dmobilisation, au lieu de
110 $ USD ;
- le paiement de 300 $ USD daccompagnement en deux tranches de 150 $ USD sur
une priode de 2 mois, au lieu de 25 USD sur une priode de 12 mois. La premire
tranche de paiement de 150 $ USD est paye lex combattant dmobilis un mois
aprs le paiement de 140 $ USD, et aprs son enregistrement et son rfrencement
dans une de nos agences de liaison en provinces. La deuxime tranche 2 mois aprs
Dans cette redfinition de lensemble du processus de paiement des ex combattants dmobiliss, il
est donc question :
- de disposer un systme logiciel qui va permettre au PNDDR de pouvoir garantir le
paiement des ex combattants dmobiliss sans tentative de fraude ;
- que ce systme logiciel de paiement, y compris les quipements qui
laccompagnent, soit oprationnel et capable de satisfaire aux diffrentes rgles de
gestion tablies par le PNDDR ; et
- que les rgles dfinies le long du processus de dveloppement soient respectes.
En effet, ce systme logiciel, nomm Payment Manager , remplace donc lapplicatif de paiement
lectronique avec mobile de CELPAY RDC Inc. Il est dvelopp par limpartiteur BIO ID
Technologies SA et la fonction TI de lUEPN DDR sous Visual Basic.Net 2005, oprationnalis
sous Microsoft XP Professionnel /SP2 que a soit en simulation ou en production, et intgre un
module de contrle et/ou dauthentification par capture et/ou contrle iris. Son but principal reste le
paiement des ex combattants dmobiliss dans le cadre du PNDDR en RD Congo.
Il est utilis par lentreprise CELPAY RDC Inc., qui a reu mandat des bailleurs, depuis la premire
phase du PNDDR, de payer les ex combattants ligibles. Son architecture logicielle est compose
des fichiers de modules, modules de classes, fonctions, macros intgrs (threads ou processus),
tables, requtes, formulaires (voir figure 5). Le Crystal Report, avec laide de ses composants,
matrialise son ct rapportage. Notons que certaines lignes codes, pour ce systme logiciel, sont
des anciennes briques de code conserves dans les bibliothques de dveloppement de BIO ID et de
MIS CONADER.
Laptop or desktop

Remote Object

Remote
Business
Object
User
Interface

Remote
Scan Object

Business
Object
handler
Data
Scan
Object
handler

Fig.5. Architecture logicielle de Payment Manager .

24

Ici, lagent payeur (agent de CELPAY), qui sera lutilisateur de ce systme, devra disposer de
largent dans sa caisse avant de dmarrer une campagne donne de paiement (il devra au moins
avoir un montant pour une journe de paie selon le cas). Il ne procde au paiement de lex
combattant dmobilis que via le systme. Si sa caisse devient vide, la campagne de paiement
amorce devra tre reporte. Un paiement effectu par lutilisateur du systme et confirm dans
ce dernier nest plus rvocable. En plus, tout agent payeur impliqu dans le processus de paiement
devra tre inscrit comme utilisateur dans le systme, par linstallateur du systme (Agent BIO ID
ou MIS), par une capture de son iris puis form son utilisation. Les enregistrements (donnes
biographiques et iris) de dmobiliss senss tre pays, qui se trouveraient dans la base de donnes
de lapplicatif didentification Ident Congo devraient se retrouver dans le systme de paiement,
soit par synchronisation en temps rel avec le systme didentification au niveau du site
didentification ou soit par importation au niveau de site de paiement se trouvant au sein de la
communaut de rinsertion. Les enregistrements dun agent payeur inscrit dans le systme par
linstallateur sont synchroniss dans tous les systmes disponibles et oprationnels pendant les
campagnes de paiement.
Linstallateur du systme, qui inscrit et donne accs aux autres utilisateurs (ici lagent payeur) dans
le systme, est inscrit lui mme lors de son installation. A chaque fois quun agent inscrit dans le
systme devra le manipuler, une authentification avec son iris sera requise. Toutefois, en cas de
problme diris survenant lors de son authentification, un mode dgrad sera disponible (cf. plan de
contingence). Il sagirait en effet lutilisateur daccder et/ou de sauthentifier via lIDcode gnr
lors de son inscription dans le systme par ladministrateur. Linstallateur a, lui aussi, son IDcode,
gnr lors de linstallation et de son inscription comme super utilisateur dans le systme. Quant
lex combattant dmobilis, qui devra percevoir son ITS, son IDcode est repris sur la carte
imprime puis lui dlivre lors de son enregistrement dans le systme Ident Congo au niveau
du site de son identification. Il devra rpondre au besoin des questions de prcision poses par
lagent payeur mais aussi signer toujours un document attestant le paiement (140$ ou 150$) quil a
reu.
Certains lments repris ci dessus constituent les bases servant pour identifier les acteurs cls et
leurs diffrentes interactions dans le systme dvelopper. Ils ont t en partie repris, sous forme
dune modlisation dtaille dans la phase conceptuelle avec laide des diagrammes UML de
contexte, de cas dutilisation, de squence, de classes et dobjets non repris ici schmatiquement.32
Toutefois, ci dessous, nous prsentons les lments cls de notre diagramme dutilisation :
- Pour ladministrateur (agent installateur), (1) installer le systme ; (2) sinscrire et
inscrire les autres utilisateurs du systme tout en dfinissant leurs profils et enfin (3)
maintenir en tat le systme ;
- Pour lutilisateur (agent payeur), (1) dmarrer ou ouvrir le systme ; (2) sauthentifier
avec son iris ou avec la saisie de son IDcode dans le systme pour procder aux
oprations de paiement ; (3) mettre jour ou synchroniser les donnes des ex
combattants dmobiliss provenant de lapplicatif didentification (Ident Congo)
et/ou importer partir du site ftp (Internet) les diffrentes donnes cryptes de
paiements raliss venant des autres sites ; (4) faire authentifier dans le systme le
bnficiaire, par contrle iris ou par saisie de lIDcode, avant son paiement ; (5)
consulter ou rechercher dans le systme les informations biographiques et de paiement
du dmobilis ; (6) effectuer ou procder au paiement du dmobilis dans le systme ;
32

Nous avons intentionnellement refus de prsenter les diffrents diagrammes UML car notre modle de tests se
situe au niveau suprieur, c..d. au niveau de tests systme et de tests de validation. Le modle dexigences
laborer, qui se limitent lamlioration de cas de tests fonctionnels, est directement mesure de matrialiser et/ou
de gnrer les diffrents cas de tests systmes, qui constitue notre modle de tests.

25

(7) imprimer dans le systme le reu de paiement du dmobilis qui devra sortir en en
trois exemplaires mais aussi les rapports journaliers/hebdomadaires/mensuels de
paiement
;
(8)
exporter
via
ftp
(Internet)
les
donnes
journalires/hebdomadaires/mensuelles de paiement vers le Data center pour
consolidation et rapprochement et (9) enfin arrter ou fermer le systme ;
- Pour le bnficiaire (dmobilis), (1) faire valider son identit avant tout paiement par
authentification (contrle de son iris) dans le systme.
Ces oprations, raliser par les trois acteurs identifis (agent payeur, installateur et dmobilis) sur
le systme dvelopper et/ou dvelopp, sont des cas dutilisation qui ont t dcrites nominalement
sous forme de scnarios et denchainements puis dtailles dans des diagrammes de squence lis
(diagramme de squence systme de cas dutilisation inscription des utilisateurs , diagramme de
squence systme de cas dutilisation authentification des utilisateurs ou des ex combattants ,
etc.) non repris aussi schmatiquement ici. Ces cas dutilisation, aprs raffinement, gnrent les
exigences gnriques et spcifiques ci dessous :
Exigences gnriques du systme sous test
-

[EX-G-01] : le logiciel dvelopper et/ou dvelopp doit possder une srie dinterfaces gnriques
(menus, message derreur, etc.) en franais et en anglais;
[EX-G-02] : lintgration des donnes provenant dun module logiciel vers un autre module,
lintrieur du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier
source ou de destination grce un ODBC disponible ;
[EX-G-03] : le menu gnral du logiciel dvelopper et/ou dvelopp devra permettre aux
utilisateurs de naviguer, sous un profil dfini, aux diffrentes sections ou sous menus de
lapplicatif ;
[EX-G-04] : les composants logiciels utiliss doivent tre cits dans la rubrique A propos , ainsi
que les informations de la version associe ;
[EX-G-05] : le logiciel dvelopper et/ou dvelopp doit pouvoir tre port sur une version jour
dun systme dexploitation similaire celui de son dveloppement (Windows XP SP2 vers
Windows XP SP3 ou vers une version postrieure, Vista par exemple) sans changer la procdure
dinstallation ni crire dans le registre du systme dexploitation o le logiciel est port ;
[EX-G-06] : le logiciel dvelopper et/ou dvelopp doit tre fourni sous forme dun fichier
compress excutable quon peut lancer directement. Lon devra avoir un et un seul fichier
excutable ;
[EX-G-07] : le logiciel dvelopper et/ou dvelopp doit disposer des interfaces conviviales pour sa
manipulation ;
[EX-G-18] : le logiciel dvelopper et/ou dvelopp doit se lancer en moins de 3 secondes et doivent
fonctionner avec les configurations matrielles acceptes.

Exigences spcifiques du systme sous test

-

[EX-S-01] : seul linstallateur peut enregistrer les utilisateurs et dfinir leurs profils ;
[EX-S-02] : laccs au logiciel dvelopper et/ou dvelopp, suivant les rgles mtiers, devra se faire
par authentification de lutilisateur via son iris en mode normal ou via la saisie de son IDcode en
mode dgrad ;
[EX-S-03] : le logiciel dvelopper et/ou dvelopp doit possder un menu Paramtres ou
Administration permettant ladministrateur de paramtrer ou de configurer les diffrents profils et
accs administratifs des utilisateurs, les chemins daccs linformation, la gestion des accs et des
habilitations et les mcanismes dauthentification ;
[EX-S-04] : le logiciel dvelopper et/ou dvelopp doit possder un menu Aide , avec une
rubrique propos dans laquelle apparat le nom du logiciel, le numro de la version, lanne de sa
distribution, les noms des entits associes au dveloppement et dautres lments de copyright. Il
doit aussi, en outre, possder la rubrique documentation utilisateur au sein du mme menu Aide ;
[EX-S-05] : tous les utilisateurs enregistrs dans le logiciel dvelopper et/ou dvelopp peuvent
effectuer des oprations et/ou des actions existantes suivant les profils et les rgles de gestion dfinis
(paiement de 140$, de 150$X2, impression de reu de paiement, synchronisation, etc.). Toutefois,
ces dernires devraient tre traces en indiquant quel utilisateur a effectu telle ou telle autre action?;

26

[EX-S-06] : le logiciel dvelopper et/ou dvelopp doit tre mesure de procder au paiement dun
dmobilis, en mode normal ou en mode dgrad, selon les rgles dfinies ;
[EX-S-07] : le logiciel dvelopper et/ou dvelopp doit tre mesure dimprimer les rapports sur
les oprations de paiement et/ou sur les actions effectues dune manire chronologique. Il sagirait
des dtails sur les oprations et/ou les actions de paiement journalires, mensuelles, trimestrielles,
etc. effectues sur le logiciel. Lon pourra toutefois ltendre des impressions statistiques sous
forme graphique ou des tableaux;
[EX-S-08] : le logiciel dvelopper et/ou dvelopp devra tre mesure de trouver et dimprimer les
diffrents rapports des oprations et/ou des actions de paiements antrieurs qui ont t stockes dans
sa base de donnes ;
[EX-S-09] : le logiciel dvelopper et/ou dvelopp devra tre mesure dexporter et dimporter les
fichiers de la base de donnes au format ci aprs dfini par lutilisateur (.txt, .csv, .xls, .mdb, .ldf et
.pdf) ;
[EX-S-10] : Le logiciel dvelopper et/ou dvelopp doit tre mesure de crer, de sauvegarder et
dimprimer une activit journalire de paiement enregistrement vide cre par lutilisateur ;
[EX-S-11] : le logiciel dvelopper et/ou dvelopp devra tre mesure de prendre en charge les
diffrents priphriques servant son optimisation (lecteur iris, imprimante, etc.) ;
[EX-S-12] : le logiciel dvelopper et/ou dvelopp devra tre mesure de sauvegarder
automatiquement lenregistrement en cours, en cas de darrt brusque de lapplicatif (coupure du
courant, plantage systme, etc.) ou dfaut, offrir la possibilit de pouvoir rcuprer tous les
enregistrements sauvegards automatiquement avant et/ou larrt brusque de lapplicatif.
[EX-S-13] : le logiciel dvelopper et/ou dvelopp devra tre mesure de synchroniser
automatiquement les enregistrements et/ou les donnes, provenant dun module applicatif ouvert vers
son module applicatif intgr ouvert ou non. Toutefois, lors dune synchronisation, si un champ est
manquant, incohrent ou incorrect, un message derreur est affich lcran ;
[EX-S-14] : le logiciel dvelopper et/ou dvelopp devra, lors de la fermeture, enregistrer et arrter
toutes les oprations et/ou actions effectues lors dun processus activ ou ouvert.

Ces exigences gnriques ou spcifiques, implmenter dans le cadre de notre systme sous test,
sont considres comme notre modle dexigences de tests (CIM). Elles sont donc en lien direct
(traabilit) avec les autres modles (PIM et PSM) qui ont suivis dans le cycle de dveloppement
(les diffrents diagrammes de conception) et gnrent les diffrents cas de tests ci dessous
saccompagnent des rsultats attendus. Cest donc notre modle de tests systme et de validation, qui
a trois niveaux. Le premier niveau reprend les exigences gnriques ou spcifiques de tests. Le
second niveau aligne les cas de tests tandis que le troisime reprend les rsultats attendus (oracles).
Ces diffrents cas et rsultats de tests concernent tous les tests systme et les tests dacceptation par
la clientle (Users Acceptance Tests, UAT). Ainsi, les caractristiques et les modalits qui sont
fixes sont celles de recette fonctionnelle et dexploitabilit mais aussi de performance, de scurit,
de maintenance, dinstallation, de compatibilit et de gestion des exceptions (mode dgrad).
A titre indicatif, nous illustrons seulement une srie dlments de notre modle de tests. Il sagit
des lments pour les tests de recette fonctionnelle et dexploitabilit .
Identificateur
Technique de tests
[EX-S-02]
[EX-G-02]
[EX-S-03]

[EX-G-03]

FONCTIONNEL ET EXPLOITABLE
Tests de systme et dacceptation (boite noire)
Exigences de tests retenues
Laccs au logiciel dvelopper et/ou dvelopp, suivant les rgles mtiers, devra se faire par
authentification de lutilisateur via son iris en mode normal ou via la saisie de son IDcode en
mode dgrad
Lintgration des donnes provenant dun module logiciel vers un autre module, lintrieur
du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier
source ou de destination grce un ODBC disponible
Le logiciel dvelopper et/ou dvelopp doit possder un menu Administration
permettant ladministrateur de paramtrer ou de configurer les diffrents profils et accs
administratifs des utilisateurs, les chemins daccs linformation, la gestion des accs et
des habilitations et les mcanismes dauthentification
Le menu gnral du logiciel dvelopper et/ou dvelopp devra permettre aux utilisateurs

27

[EX-S-04]

[EX-S-05]

[EX-S-06]
[EX-S-07]

[EX-S-08]
[EX-S-09]
[EX-S-10]
[EX-S-11]
[EX-S-12]

[EX-S-13]

[EX-S-14]

Dmarche
Cas de tests

de naviguer, sous un profil dfini, aux diffrentes sections ou sous menus de

lapplicatif
Le logiciel dvelopper et/ou dvelopp doit possder un menu Aide , avec une
rubrique propos dans laquelle apparat le nom du logiciel, le numro de la version,
lanne de sa distribution, les noms des entits associes au dveloppement et dautres
lments de copyright. Il doit aussi, en outre, possder la rubrique documentation
utilisateur au sein du mme menu Aide
Tous les utilisateurs enregistrs dans le logiciel dvelopper et/ou dvelopp peuvent
effectuer des oprations et/ou des actions existantes suivant les profils et les rgles de
gestion dfinis (paiement de 140$, de 150$X2, impression de reu de paiement,
synchronisation, etc.). Toutefois, ces dernires devraient tre traces en indiquant quel
utilisateur a effectu telle ou telle autre action?
Le logiciel dvelopper et/ou dvelopp doit tre mesure de procder au paiement dun
dmobilis, en mode normal ou en mode dgrad, selon les rgles dfinies
Le logiciel dvelopper et/ou dvelopp doit tre mesure dimprimer les rapports sur
les oprations de paiement et/ou sur les actions effectues dune manire chronologique.
Il sagirait des dtails sur les oprations et/ou les actions de paiement journalires,
mensuelles, trimestrielles, etc. effectues sur le logiciel. Lon pourra toutefois ltendre
des impressions statistiques sous forme graphique ou des tableaux
Le logiciel dvelopper et/ou dvelopp devra tre mesure de trouver des
enregistrements et dimprimer les diffrents rapports des oprations et/ou des actions de
paiements antrieurs qui ont t stockes dans sa base de donnes
Le logiciel dvelopper et/ou dvelopp devra tre mesure dexporter et dimporter les
fichiers de la base de donnes au format ci aprs dfini par lutilisateur (.txt, .csv, .xls,
.mdb, .ldf et .pdf)
Le logiciel dvelopper et/ou dvelopp doit tre mesure de crer, de sauvegarder et
dimprimer une activit journalire de paiement enregistrement vide cre par
lutilisateur
Le logiciel dvelopper et/ou dvelopp devra tre mesure de prendre en charge les
diffrents priphriques servant son optimisation (lecteur iris, imprimante, etc.)
Le logiciel dvelopper et/ou dvelopp devra tre mesure de sauvegarder
automatiquement lenregistrement en cours, en cas de darrt brusque de lapplicatif
(coupure du courant, plantage systme, etc.) ou dfaut, offrir la possibilit de pouvoir
rcuprer tous les enregistrements sauvegards automatiquement avant et/ou larrt
brusque de lapplicatif
Le logiciel dvelopper et/ou dvelopp devra tre mesure de synchroniser
automatiquement les enregistrements et/ou les donnes, provenant dun module applicatif
ouvert vers son module applicatif intgr ouvert ou non. Toutefois, lors dune
synchronisation, si un champ est manquant, incohrent ou incorrect, un message derreur
est affich lcran
Le logiciel dvelopper et/ou dvelopp devra, lors de la fermeture, enregistrer et arrter
toutes les oprations et/ou actions effectues lors dun processus activ ou ouvert
Informations sous tests
[(CT-F-01)(EX-S-02)] Fentre de connexion: Cliquez sur le bouton avec iris . Une
fentre de capture iris vous permettant de vous faire authentifier va apparatre. En bas du
bouton avec iris , nous avons le bouton help qui vous permet dafficher la fentre
aide qui a son sein longlet propos , contact et manuel utilisateur .
[(CT-F-02)(EX-S-02)] Fentre de capture iris: En cliquant sur capturer lil droit et/ou
sur capturer lil gauche, si votre iris est dj stock dans la base de donnes iris, vous
devez accder au menu gnral.
[(CT-F-03)(EX-S-03)] Fentre dinscription de lutilisateur: Si le systme est lanc
pour la premire fois, le premier utilisateur qui fait capturer son iris sera enregistr
comme administrateur. Dans ce cas, il aura lui lobligation dinscrire plus tard les autres
utilisateurs du systme (les agents payeurs) puis enregistrer leurs profils. Ici, la fentre
capture apparat et aprs capture des iris droit et gauche, on clic sur approuver puis
continuer.
[(CT-F-04)(EX-G-03)] Menu gnral ou principal: Elle apparat, cette fentre, lorsque
lutilisateur ou ladministrateur se connecte sur le systme en cliquant sur avec iris et
se fait par la suite authentifier via son iris (mode normal) ou via son IDcode (dans le cas

28

Rsultats de cas de
tests

dune connexion en mode dgrad).

[(CT-F-05)(EX-S-02)(EX-G-03)] Menu gnral ou principal: En faisant un tour
dhorizon dans cette fentre, vous trouverez lexistence dune liste droulante de choix de
langues en franais et/ou en anglais. La langue par dfaut est le franais. Le choix de
langlais changerait automatiquement les interfaces du logiciel en anglais.
[(CT-F-06)(EX-S-08)] Fentre rechercher: Cette fentre vous permet de trouver tout
enregistrement de paiement stocker dans le systme. Cest aussi au niveau de cette fentre
quon procde lauthentification de lex combattant bnficiaire par iris ou via la
saisie de son IDcode.
[(CT-F-07)(EX-S-05)(EX-S-06)( EX-S-07)(EX-S-10)] Fentre dtails de
paiements: Saisissez et/ou choisissez les informations sur un paiement (1ire tranche, 2ime
tranche ou 3ime tranche) puis validez avec le bouton effectuer le paiement dun
dmobilis. Le reu de paiement devra apparatre en visualisation et vous pouvez cliquez
sur imprimer. Clturez lopration afin de permettre le paiement suivant.
[(CT-F-08)(EX-S-09)] Fentre dexportation: Cliquez sur le bouton Exporter, et sur la
fentre exporter qui va apparatre, slectionnez 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)] Fentre dimportation de donnes
didentification : Cliquez sur le bouton Importer et sur la fentre importer qui va
apparatre, slectionnez importer les donnes du site puis cliquez sur importer . Le
dernier fichier crypt didentification date, cr l'aide de lapplicatif Ident Congo
puis dpos sur le site FTP UEPN DDR, va tre import dans le systme de paiement.
A ce niveau, une autre opration de synchronisation des donnes didentification dans le
systme de paiement a lieu automatiquement dans le cas o celui ci est connect via un
rseau LAN avec le systme didentification dans un site denregistrement.
[(CT-F-10)(EX-S-09)] Fentre dimportation de donnes de paiement : Cliquez sur le
bouton Importer et sur la fentre importer qui va apparatre, slectionnez importer
les donnes de paiement puis cliquez sur importer . Le dernier fichier crypt de
paiement date, cr l'aide de lapplicatif Payment Manager puis dpos sur le site
FTP UEPN DDR, va tre import dans le systme de paiement.
[(CT-F-11)(EX-S-05)(EX-S-07)(EX-S-08)(EX-S-10)] Fentre de rapports:
Cliquez sur le bouton rapports. Slectionnez rapport quotidien ou une priode donne
sur la liste droulante et cliquez sur Afficher.
[RCT-F-01][(CT-F-01)(EX-S-02)] Fentre de connexion: Une Oui, avec succs
fentre de connexion devra apparatre et vous donnant la possibilit
de procder via le bouton avec iris votre authentification
[RCT-F-02][(CT-F-01)(EX-S-02)] Fentre de capture iris: Une Oui, avec succs
fentre de capture iris ou saisie de lIDcode, vous permettant de vous
faire authentifier, va apparatre.
Oui, avec succs.
[RCT-F-03][(CT-F-02)(EX-S-02)][(CT-F-03)(EX-S-03)]
Fentre dinscription de lutilisateur: La fentre Enregistrement de Prire de modifier
ladministrateur ou de lutilisateur devra apparatre. A ce niveau, administrateur
on procdera lenregistrement de liris gauche et de liris droit de par
lutilisateur. Aprs validation, un Idcode devra tre gnr puis li administration .
lutilisateur inscrit. Ladministrateur devra ajouter dautres
informations le concernant (nom, prnom, date de naissance, etc.).
La procdure se termine avec le message Administrateur ou
utilisateur inscrit avec succs .
Oui, avec succs
[RCT-F-04][(CT-F-04)(EX-G-03)][(CT-F-05)(EX-G-03)]
Menu gnral ou principal: Cette fentre apparat et devra vous
permettre daccder aux diffrents sous menus du systme,
savoir : administration, paiement, rechercher, importer, exporter,
rapport et quitter. Ici, seul ladministrateur ou lutilisateur inscrit qui
devra voir ces sous menus activs. Il y a aussi loption de se
dconnecter du systme au milieu de la fentre.
[RCT-F-05][(CT-F-06)(EX-S-08)] Fentre rechercher: Cette Oui, avec succs
fentre apparat et devra vous permettre de trouver tout

29

Niveau de compltude
Succs /chec

enregistrement de paiement stocker dans le systme.

Lenregistrement retrouv affiche aussi sur une carte virtuelle
limage du dmobilis, avec dautres informations utiles. La
recherche est multicritre (IDcode, nom, prenom, et date
denregistrement).
[RCT-F-06][(CT-F-07)(EX-S-05)(EX-S-06)(EX-S07)(EX-S-10)] Fentre dtails de paiements: Les dtails sur les
dates et les montants reus et restants dun dmobilis mais aussi sur
les oprateurs ayant effectu ces paiements seront affichs. Ensuite,
aprs avoir cliquer sur effectuer le paiement , une fentre
affichant le reu de paiement en trois exemplaires sur un format A4
devra safficher avec possibilit dimpression ou denregistrement
dans les formats .pdf, .word, .xls et .jpeg.
[RCT-F-07][(CT-F-08)(EX-S-09)] Fentre dexportation : deux
fichiers avec de donnes exportes seront crs et crypts. Lun pour
CELPAY et lautre pour UEPN DDR et BIO ID. Ils devront par
la suite tre dposs sur le site FTP UEPN DDR.
[RCT-F-08][(CT-F-09)(EX-G-02)(EX-S-09)(EX-S-15)]
Fentre dimportation de donnes didentification: Les donnes seront
importes. Procder la recherche du dernier IDcode existant dans le
systme pour sassurer que les autres donnes didentification sont
importes.
[RCT-F-09][(CT-F-10)(EX-S-09)] Fentre dimportation de
donnes de paiement: Les donnes seront importes. Procder la
recherche du dernier IDcode existant dans le systme pour sassurer
que les autres donnes didentification sont importes.
[RCT-F-10][(CT-F-11)(EX-S-05)(EX-S-07)(EX-S08)(EX-S-10)] Fentre rapports: Une fentre affichant le rapport
devra safficher avec possibilit dimpression ou denregistrement
dans les formats .pdf, .word, .xls et .jpeg.
Atteindre au moins les 100% dexigences des cas de tests retenus
critres dinstallation de lapplicatif
Voir commentaires sur les rsultats de tests dinstallation

Oui, avec succs

Oui, avec succs

Oui, avec succs

Oui, avec succs

sur lensemble de

b) Rsultats et discussion sur lbauche du modle (analyse du modle en mettant un avis

sur le logiciel)
Les rsultats de notre contribution permettent de mieux comprendre la dmarche dlaboration dun
modle de tests de vrification et de validation mais aussi de faciliter son dploiement. Ils ont t
matrialiss en se servant des rfrentiels normatifs en la matire (type de gouvernance mettre en
place, respect de meilleures pratiques et mise en uvre dune gestion de cycle de vie du logiciel dans
laquelle les tests logiciels constituent llment visible pour la qualit) et des principes gnraux de
lIDM suivant lapproche MDA (mta modlisation et transformation de modles). Avec laide de
la modlisation UML, comme profil du mta modle, et sans y ajouter de faon claire les
contraintes OCL, nous avons pu laborer un modle dexigences fiable (CIM) qui nous a permis par
la suite de rdiger manuellement des cas et des rsultats des tests aboutissant au modle complet de
tests systme et de validation. Ce dernier, qui se rsume dans notre cas des diagrammes de cas
dutilisation, dactivit et de squence, a matrialis lexcution de tests systme et la validation du
logiciel Payment Manager .
En effet, la mthodologie UML a t choisi par nous la place des autres mta-modles (MOF,
XMI, OCL) car elle a permis de dcrire sparment les modles pour les diffrentes phases du cycle
de dveloppement dun logiciel (Bzevin et Blanc Xavier, 2002). Cest une approche qui se veut
aujourdhui gnraliste (Combemale, 2008). Ainsi, sans dtailler sa smantique dexcution, grce
au modle dexigences (CIM) gnr partir des exigences textuelles (processus et rgles mtiers
pour le paiement, besoins des utilisateurs, etc.), notre bauche de modle de tests qui ne se situe
quau niveau suprieur (tests systme et de validation) a concrtis manuellement les cas de tests
30

abstraits gnrs par des tests concrets sur des donnes relles ou de tests (errones). Les rsultats
obtenus sont voire sans quivoque car ils dmontrent la traabilit les cas de tests gnrs avec
dexigences techniques produites mais aussi avec les rsultats abstraits de tests. Quelques rsultats
concrets de cette suite de tests sont prsents dans les figures 6, 7, 8, 9 et 10 ci - dessous.

Fig.6. [RCT-F-01][(CT-F-01)(EX-S-02)] Fentre 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 lis 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 gnral ou principal. Ce dernier permet lutilisateur de naviguer sur
lensemble des ressources du systme. Il est en lien avec les exigences et les cas de tests ci - aprs [EX-G-03], [(CT-F-04)(EX-G-03)] et [(CT-F05)(EX-S-02)(EX-G-03)]

31

Fig.8. [RCT-F-02][(CT-F-02)(EX-S-02)][(CT-F-03)(EX-S-03)] Fentre dinscription de lutilisateur. Ce dernier dpend de lcran Capture

des iris . Ici, lon observe lenregistrement de lil gauche de ladministrateur. Cette opration est identique pour linscription des autres utilisateurs du
systme. 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)] Fentre dtails de paiements dun ex combattant (TEST GUY

TEST BANDA dans notre cas). Ici, lon voit aussi le nom de lutilisateur effectuant la transaction est rattach en lien automatique (TESTER) et les
bnfices dj obtenus. Les exigences et cas de tests lis ici sont [EX-S-05], [EX-S-06], [EX-S-07], [EX-S-10] et [(CT-F-07)(EX-S-05)(EX-S06)( EX-S-07)(EX-S-10)].

Fig.10. [RCT-F-05][(CT-F-06)(EX-S-08)] Fentre rechercher. Ici, la recherche dun ex combattant est multicritre. Elle peut tre effectue soit par
iris, IDcode, Nom, etc. Cette opration permet, une fois lenregistrement trouv, de pouvoir accder au dtail des informations sur le paiement de lex

32

combattant et/ou procder un nouveau paiement (2ime ou 3ime tranche). Les exigences, cas et rsultats de tests lis ici sont [EX-S-08] et [(CT-F06)(EX-S-08)].

Ici, les mthodes ou techniques de tests dcides taient toutes dynamiques et se sont excutes
suivant lapproche boite noire, partir des directives pratiques ci - aprs :
- les jeux de donnes dentre appliquer sont dcrits sur les valeurs critiques de
paiement qui sont valides ou errones ;
- les cas de tests (scnarios) constituent le mode opratoire retenu ;
- la description les comportements attendus du programme ou du logiciel sont dcrits
sur les types et les valeurs de sortie ; et
- les critres dacceptation des rsultats de tests et de clture sont bass sur la
prvention, la tolrance et llimination des fautes constates.
A ce niveau, lquipe de test a dtermin les donnes de test (DT) fournies aux CT (concrtisation)
aligns et a indiqu les rsultats quelle attendaient pour ces CT (prdiction de lOracle). Ensuite,
elle a excut des scripts testant ces CT sur les DT. Aprs comparera des rsultats obtenus avec les
prdictions de lOracle (verdict), un rapport sur les rsultats de tests (succs ou chec) a t labor.
La dure globale de ces activits de tests systme et de validation a t de 4 jours. Ici, leffort fourni
par chaque membre du projet affect lquipe de tests tait sur le nombre cas de tests concevoir,
les dfauts dcouvrir et sur les stratgies de rsolution dfinir dans le souci dviter des tests
inutiles, qui taient de toute faon rejous.
Ainsi, pour la premire journe de tests, considre comme journe de dmarrage des activits de
tests, les actions suivantes ont t menes : (a) la prparation des matriels de la plate forme retenue,
(b) linter connectivit des matriels retenus pour la plate forme, (c) loptimisation et le test dinter
connectivit des matriels de la plate forme retenue pour les tests (d) la conception des types et des
cas de tests, (e) la validation des diffrentes techniques, types et cas de tests retenus et enfin (f)
lharmonisation des actions sur les rsultats et/ou livrables de chaque type des cas de tests retenus.
Cette harmonisation a t tablie via une relation de conformit entre le systme sous test et le
modle de test obtenu qui le reprsente. De mme, elle a t rendue possible grce aux rsultats de
tests de niveau infrieur (tests unitaires et dintgration) sur les codes sources inspects et corrigs.
La deuxime et la troisime journe, considre comme les journes de vrification dfinitive de
Payment Manager , ont connu les actions suivantes : (a) lexcution des diffrents types et cas de
tests retenus, (b) le Suivi, lobservation minutieuse et la correction des diffrents types et cas de tests
excuts, (c) lintgration des diffrents rsultats de tests excuts dans un rapport journalier de tests
et enfin (d) la validation de ce rapport intermdiaire par les diffrents acteurs ayant particip aux
activits de tests. Les autres actions menes par lquipe de tests taient bases sur les rsultats de
chaque cas de tests. Ces rsultats taient repris sur une liste, annexe au rapport journalier de tests, et
qui indiquaient en dehors de cas de tests les diffrents acteurs concerns pour chaque cas russi, ainsi
que le dlai qui tait accord pour la finalisation ou la correction de chaque cas chou. Quant la
dernire journe, considre comme la journe de clture (validation) en vue du dploiement et/ou
de la mise en exploitation de Payment Manager , les actions menes ont t : (a) la production des
diffrents rsultats de tests excuts depuis le dbut du processus (premire phase jusqu la
deuxime phase de tests), (b) lintgration de ces rsultats dans le rapport final de tests et
dacceptation par les utilisateurs (UAT final) et enfin (c) la validation du rapport final par les
signatures des diffrents acteurs ayant particip aux activits de tests. Ces activits ont donc marqu
la clture de la phase de tests et le dmarrage de la phase de dploiement (installation), associe la
formation des utilisateurs et la configuration du produit - logiciel au sein du systme dinformation
de gestion intgre en production de lUEPN DDR.
Nous comprenons ainsi que la mise production du logiciel Payment Manager a alors marqu la
fin de sa vrification et de sa validation et que notre bauche du modle de tests, propos dans cette
33

contribution, jette les bases dun dmarrage de pratique de tests systmatiques par les professionnels
TI congolais, mme si plusieurs limites sont mentionnes et/ou pourront tre mentionnes.
Toutefois, il serait important de souligner la ncessit deffectuer une validation plus complte de
cette bauche en ajoutant les cas de tests de niveau infrieur de tests qui ont matrialiss, dans le
cadre de notre projet, les tests unitaires et dintgration. La mthodologie UML, qui possde une
syntaxe trs proche de la syntaxe de certains langages puis utilise pour les tests de niveau suprieur
dans cette contribution, devra permettre de driver les tests de type bote blanche et renforcer les
tests systmes gnralement produits. Des travaux futurs sont donc ncessaires afin de pouvoir
formaliser ces techniques et pouvoir ainsi valider et vrifier les transformations prsentes et/ou qui
pourront tre prsentes dans dautres contributions afin de pouvoir produire, avec des technologies
MBT et des outils dautomatisation de tests par exemple, des cas de tests gnralement automatiss
et confis des algorithmes de gnration solides permettant de saffranchir de lerreur humaine et
dobtenir des rsultats de tests de meilleure qualit.
IV. CONCLUSION
Cette contribution tente de se greffer sur les travaux rcents portant sur la gnration de tests dans
une approche dingnierie dirige par les modles. Pour ce faire, nous avons t dans lobligation de
proposer une bauche de modle de tests dont la mise lpreuve, sur le plan pratique, pourra
sadapter et stendre un plus grand nombre de projets cherchant dgager les bnfices dusage
des bonnes pratiques de dveloppement logiciels et, sur le plan thorique, va la permettre de
continuer de saffiner sur la base des travaux sintressant lvolution des outils de tests car la
problmatique gnrale de tests logiciels reste encore largement ouverte.
Dailleurs, pour la RD Congo, lors dune discussion en atelier avec quelques membres de BSD
Congo, nous avons conclu que si les activits de vrification et de validation de faon systmatique,
au niveau dun projet de dveloppement informatique, reste un dfi majeur, alors quelles constituent
une tape critique dans la pratique de dveloppement logiciels, cest parce quelles semblent ne pas
avoir t vulgarises par ceux qui sont senses apporter de laide la socit.
Ainsi, l'ensemble des lments prsents, intgrs dans une dmarche simplifie, suggre aux
professionnels TI congolais de mieux adapter leur faon faire les tests logiciels et/ou de procder aux
activits de tests dans des projets de dveloppement quils ont diriger et, aux universitaires, de faire
voluer leurs enseignements et leur recherche dans la qute des meilleures pratiques menant au
succs de dveloppements logiciels dans notre pays. Confiant de la communaut BSD Congo ,
qui est dj rode avec la modlisation UML et avec certaines bonnes pratiques de dveloppements
logiciels, nous pensons quelle pourra aussi simpliquer dans cette vision.

BIBLIOGRAPHIE
I.OUVRAGES
-

BERSINI Hugues, La programmation oriente objet, 2ime tirage, Eyrolles, Paris, 2009.
BLANC Xavier, avec la contribution de SALVATORI Olivier, MDA en action : ingnierie
logicielle guide par les modles, collection architecte logiciel, EYROLLES, 2005.
CHARTIER KASTLER Cyrille, Prcis de conduite de projet informatique, Editions
dorganisation, Paris, 1997.
GAUDEL Marie Claude et Ali, Prcis de gnie logiciel, Prface de LEMOINE Michel,
Edition Masson, Collection Enseignement de linformatique, Paris, 1996.
GUSTAFSON David, Gnie logiciel, Dunod, Srie Schaums EdiScience, Paris, 2003.
IVINZA LEPAPA A. C., Analyse de lintroduction de lEDI dans les entreprises
congolaises : Une contribution limpact organisationnel des Technologies de
lInformation, Tome I: concepts de base et cadre d'analyse thorique, Editions
universitaires europennes, Saarbrken - Germany, 2010.
34

LE MOIGNE Jean Louis, La thorie du systme gnral. Thorie de la modlisation,

Presses universitaires de France, Paris, 1994.
MESSAGER ROTA V., Gestion de projet Vers les mthodes agiles, Eyrolles, Paris,
2007.
MOREAU Ren, Lapproche objets : Concepts et techniques, Edition Masson, Paris,
1995.
MOREJON J. et RAMES J.R., Conduite de projets informatiques : principes et
techniques sappuyant sur la mthode Merise, Inter ditions, Paris, 1992.
MORLEY Chantal, Management dun projet systme dinformation : principes, techniques,
mise en uvre et outils, 4ime dition, Collection InfoPro, Dunod Informatique, Paris, 2004
PRINTZ Jacques, Le gnie logiciel, Presses universitaires de France, Collection Que saisje ?, Paris, 1995.
ROQUES Pascal, UML par la pratique, 5ime dition, Eyrolles, Paris, 2009.
SIMON H.A., Le Nouveau management : La dcision par les ordinateurs, Economica,
Paris, 1980.
TARDIEU H., NANCY Dominique et PASCOT Daniel, Conception dun systme
dinformation : construction de la base des donnes, Les ditions dorganisation, Paris,
Gatan Morin Editeur, Qubec, 1980.
VAUQUIER Dominique, Plan qualit du logiciel et des services Internet, AFNOR, SaintDenis-La-Plaine Cedex, 2003.
VICKOFF J.P., Mthode Agile : les meilleures pratiques, comprhension et mise en
uvre , RAD Sarl, 2009.

II. COURS ACADEMIQUES

-

IVINZA LEPAPA A. C. et MBUTA IKOKO D. A., Gnie logiciel et construction des

programmes, Universit Libre de Kinshasa, Facult des Sciences Economiques et
Gestion, Dpartement dInformatique de Gestion, L1 INFOGEST, Cours indit, Anne
acadmique 2006 2007.
IVINZA LEPAPA A. C., Projets dautomatisation, Universit Libre de Kinshasa, Facult
des Sciences Economiques et Gestion, Dpartement dInformatique de Gestion, L1
INFOGEST, Cours indit, Anne acadmique 2001 2002.
LAVOIE Luc, Gestion de projet, Universit de Sherbrooke, Facult des Sciences, Centre
de formation en technologies de linformation, INF 754, Cours indit, Hiver 2007.
MVIBIDULU KALUYIKIT A., Conception des systmes dinformation, Universit Libre
de Kinshasa, Facult des Sciences Economiques et Gestion, Dpartement dInformatique
de Gestion, L1 INFOGEST, Cours indit, Anne acadmique 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, Ingnierie et qualit du logiciel et des systmes. Tome 1 : Dfinitions des
processus et qualit des produits, AFNOR, 2002.
ALLARD POESI F. et PERRET V., Rles et conflits de rles du responsable de projet,
Revue Franaise de Gestion, 31(4), 2005, pp. 193-202
BEZEVIN J. et BLANC X., Promesses et Interrogations de lApproche MDA,
Dveloppeur Rfrence, http://www.weblmi.com/devreference, septembre 2002, v2.17,
pp. 8-12.
35

CFTL/ISTQB, Glossaire CFTL/ISTQB des termes utiliss en tests de logiciels, Erik van
Veenendaal Editeur, Dcembre 2007.
CHARPENTIER P., Comment construire les tests dun logiciel, INRS, Collection
Mthodologie, Cahiers de notes documentaires Hygine et scurit du travail, 4ime
trimestre, n 181 ND 2140 181 - 00, pp. 63-77, 2000.
CHOKRON Michel, DUFOUR E. et DES ROCHERS M., Connaissances et formation
spcifiques aux gestionnaires des TI, Cahier du GReSI, n05-02, HEC Montral, Juin
2005.
CMMI PRODUCT TEAM, CMMI for Development, Version 1.2, Software Engineering
Institute, Carnegie Mellon, August 2006.
COMBEMALE Benot, Ingnierie Dirige par les Modles (IDM) : tat de lart, Institut
de Recherche en Informatique de Toulouse, Aot 2008
CROCHET DAMAIS Antoine, Gestion de projet informatique : dcryptage, 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 comprhension de la
transformation de la fonction TI dans les organisations, Cahier du GReSI, n07-08, HEC
Montral, Dcembre 2007.
IEEE 610.12, Standard Glossary of Software Engineering Terminology, Edition 1990.
IEEE 1233, Guide de l'IEEE pour la Spcification dExigences de Systme, Edition 1998.
JEZEQUEL J. M., GERARD S., BAUDRY B., L'ingnierie dirige par les modles ,
chapitre Le gnie logiciel et l'IDM : une approche unificatrice par les modles ,
Lavoisier, Hermes- science, 2006.
MBUTA IKOKO D. A., Fonction Technologie de lInformation de lUEPN DDR :
Approche pour la relance des activits du PNDDR, Document interne, UEPN DDR, Aot
2008.
MBUTA IKOKO D. A. et Alii, Rsultats du droulement de tests du logiciel Payment
Manager, Fonction TI, Document interne, UEPN DDR, Mars 2009.
MBUTA IKOKO D. A. et Alii., Rapport de tests sur louverture 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 systme des paiements des
ex combattants en rinsertion : Elaboration de proposition en vue den amliorer la scurit
et la performance, ERNST YOUNG France, Juillet 2006.
MOTTU J. M. et alii. Gnration automatique de test pour les transformations de
modles. In IDM05 (Ingnierie Dirige par les Modles), Paris, France, 2005.
PIERRE MAJORIQUE Lger, LUC Cassivi et MICHAEL Wybo, Gestion de projet TI :
Amener une quipe utiliser les technologies de communication appropries, HEC
Montral, Cahier du GReSI, n 07-02, Janvier 2007.
SIDI Jacqueline, Les normes : des outils plutt que des exigences, La lettre dADELI
n50, Janvier 2003, pp. 35 - 37.
VITAL Roy, CARMEN Bernier et MARTIN Danis, Leadership, modes
dapprovisionnement et gestion de projets TI, HEC Montral, Cahier du GReSI, n 07-06,
Mai 2007.

36