Professional Documents
Culture Documents
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.
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
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
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.
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).
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
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
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
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
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
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]
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
Architecte de tests
Concepteurs de tests
21
Programmeurs
Testeurs
ou
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
Remote Object
Remote
Business
Object
User
Interface
Remote
Scan Object
Business
Object
handler
Data
Scan
Object
handler
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.
[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
28
Rsultats de cas de
tests
29
Niveau de compltude
Succs /chec
sur lensemble de
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.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
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