Les cahiers de BSD Congo n°4, mai 2011

ELEMENTS D’ELABORATION D’UN MODELE DE TESTS DE VERIFICATION ET DE VALIDATION DANS UN PROJET DE DEVELOPPEMENT MIXTE : L’EXEMPLE DE PAYMENT MANAGER 1.0.

Contribution de MBUTA IKOKO Dodi Alphonse1 Spécialiste MIS et Chargé de Projet Ident et ITS à l’UEPN-DDR Conseiller TI et Responsable de la cellule Recherche et Développement de BSD Congo, Assistant d’enseignement et de recherche en informatique et MIS Département d’Informatique de Gestion, Université Libre de Kinshasa, RD Congo & Section Informatique, Institut Supérieur de Commerce de Kinshasa, RD Congo Email: dodi.mbuta@bsdcongo.org / mbutaikoko@hotmail.fr Mai 2011

Contact, « Les cahiers de BSD Congo » Téléphone : +243(0)819-993-160 / +243(0)998-399-386 Email : info@bsdcongo.org Site Internet : http://www.bsdcongo.org

Dans le cadre de sa politique de vulgarisation des méthodes et outils TI et pour un meilleur partage du savoir libre en RD Congo, l’Association BSD Congo a créé depuis 2009, via la cellule « recherche et développement » qui œuvre au sein de son équipe technique, une note de communication et de partage d’expérience dans le domaine des TI, appelée « Les cahiers de BSD Congo », documents de travail ou de pré - publications n'excédant pas quarante pages. Ils sont diffusés et mis à la disposition des membres/partenaires de BSD Congo et du public, via Internet, dans une perspective d’échanges et de partage du savoir TI. Ces échanges se réalisent dans un souci de réciprocité et de libre circulation de préoccupations professionnelles ou scientifiques. Leur contenu n'est pas définitif et peut être sujet à discussion. Ils ne constituent donc qu'une étape dans la démarche scientifique.

Résumé

Les tests logiciels restent une approche incontournable dans le développement logiciel, surtout avant la mise en production du produit – logiciel développé. En RD Congo, la pratique de tests semble n’est pas encore du tout formalisée dans la personne des professionnels TI congolais. Ceux qui s’aventurent la réalisent sans le respect des référentiels normatifs applicables. C’est pourquoi, avec notre retour d’expérience de chef de projet Ident – ITS à l’UEPN – DDR, dans le cadre d’un développement en impartition, avec la firme BIO – ID Technologies SA, du logiciel « Payment Manager », nous avons jugé bon de fournir à notre communauté des éléments adaptés aidant à l’élaboration d’un modèle de tests logiciels sous la forme d’une ébauche unifiée et simpliste. Elle est produite à partir à partir de l’expression de besoins des utilisateurs, des processus et/ou règles métiers de l’UEPN – DDR, etc. qui ont été, par la suite, formalisés en modèle d’exigences fonctionnelles. Utilisant une démarche de modélisation empruntée à l’IDM, cette ébauche a donc pour but de faciliter la réalisation et l’exécution de tests logiciels de niveau supérieur (système et validation) par une équipe de développement logiciel suivant les conditions contractuelles et environnementales. C’est donc un élément d’entrée de jeux à produire par les acteurs impliqués dans un projet de développement lors de la remise en question ou pas du produit – logiciel attendu des utilisateurs. 1 L’auteur de cette contribution remercie les lecteurs pour leurs judicieuses remarques et suggestions. Il tient aussi à les signifier qu’une partie de ce texte a fait l’objet d’une présentation lors d’un « atelier de BSD Congo » sur le développement informatique avec un groupe d’étudiants du Département des Mathématiques et Informatique de l’Université de Kinshasa, au mois de Juin 2010.

2

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

3

Cette résolution associée est d’autant plus exigée qu’elle devrait être recommandée aux équipes formelles de développement logiciel en RD Congo pour pouvoir leur permettre de livrer un bon produit, qui respecterait voire les règles de l’art ou métier, et qui leur éviterait de dénaturer les procédures et les procédés qui sont en principe connus et définis, à partir des besoins initiaux ou quotidiens (exprimés par le maître d’ouvrage ou par les utilisateurs). Cet aspect hypothétique d’améliorer les pratiques TI congolaises dans l’accomplissement, avec succès, de certains projets informatiques de développement logiciel rend alors intéressant la compréhension et l’importance de disposer, avant chaque activité de vérification et de validation, un modèle de tests logiciels (de niveau de supérieur) produit sur base des référentiels existants. Cette contribution, qui rentre dans la perspective d’amélioration des pratiques TI congolaises poursuivie par la structure BSD Congo, particulièrement en matière de développement logiciels, s’inscrit dans le cadre des ateliers pratiques que sa cellule « Recherche et Développement » a organisé et continuerait à organiser avec certains étudiants informaticiens sur la modélisation de tests logiciels dans les milieux universitaires congolais (UNIKIN, ULK, ISTA, etc.). Elle s’organise alors comme suit : Au point II, nous présenterons l’état de l’art et les grandes lignes sur lesquels cette contribution s’appuie. Il résume donc, dans une première phase, quelques prérequis pour la gestion d’un projet informatique de développement logiciel. Dans une seconde phase seront présentés de façon globale les concepts de programmation et de tests logiciels. Cette deuxième phase passera aussi en revue les niveaux, méthodes et outils de tests qui seront complétés à leur tour des lignes essentielles (exigences dans les activités de vérification et de validation, modélisation comportementale des exigences dans l’UML pour les tests, efficacité de tests, etc.) aidant à l’élaboration de notre modèle de tests. Le point III présentera notre démarche d’élaboration du modèle de tests qui, sur base des processus et règles métiers décrits (processus de paiement dans le cadre de DDR), va produire et détailler l’ensemble des exigences à aligner dans les activités de tests logiciels. Ces exigences, seront donc vus, ensemble avec les cas et les résultats de tests à concevoir, comme base de notre ébauche de modèle de tests dans le cadre de vérification et de validation du produit – logiciel « Payment Manager ». Une conclusion et quelques perspectives terminent cette contribution. II. APPROCHES SUR LE DEVELOPPEMENT INFORMATIQUE Section I. L’univers de développement informatique dans les entreprises : contour managérial et organisationnel

a) Le développement informatique dans les entreprises : Considérations générales Le développement informatique est une activité intensément collaborative. Il consiste à analyser ou étudier les besoins de gestion optimisée d’une organisation, à concevoir des solutions sur la base de ces besoins, à modéliser informatiquement ces solutions, c’est-à-dire les transcrire dans un langage informatique, les implémenter sur une machine ou un système et les maintenir ou les faire évoluer. Pour ce faire, le génie logiciel »4, qui s’occupe de la fabrication des systèmes informatisés, c.à.d. des logiciels dans notre cas, traite cette réalisation informatique dans le but d’atteindre un objectif spécifique. C’est donc le domaine de l’informatique qui allie les capacités d'analyse et d’adaptation à un esprit de synthèse, tout en mettant en œuvre les techniques (outils

conception et au développement des logiciels, s’associe à ce modèle de Deming pour tenter d’aider les organismes d’ingénierie à améliorer la capacité de leurs processus à travers 5 niveaux dit de maturité (initial, reproductible, défini, géré et optimisé). 4 Selon la norme IEEE 610.12, le génie logiciel est l’application d’une approche systématique, disciplinée et quantifiable au développement, à l’exploitation et à la maintenance du logiciel. C’est-à-dire, l’application de l’ingénierie au logiciel.

4

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

5 La qualité, dans le domaine de développement et de conception, est vue comme le but ou l’exigence ultime à atteindre car elle se retrouve étroitement liée à la réalisation au point qu’il est très difficile de partager distinctement les activités de développement des celles de qualité. 6 Le système d’information, abrégé SI, est une représentation systémique de l’entreprise et de ses activités. En grande partie immatériel, il est donc complexe (Lemoigne, 1994) et est organisé autour des ressources, sous diverses dimensions (organisationnelle, managériale et technologique) (Reix R., 2004 et Laudon et Alii, 2006). 7 Actuellement, trois types de logiciels existent. Il s’agit des logiciels constructeurs, qui sont très dépendants du matériel ; des progiciels, développés par les éditeurs de logiciel, des boîtes noires, généralement paramétrables, assurant telles ou telles fonctions précise ; et des logiciels propriétaires, développés pour les besoins spécifiques de l’entreprise ou de l’organisation, soit par elle même ou soit par l’intermédiaire de sociétés de services.

5

technologie. Ce résultat provenant d’une organisation et/ou d’une modélisation permet au système d’information de l’entreprise de fournir et de disposer des outils permettant « … de garder en mémoire une représentation de l’activité du système opérant au sein de l’environnement afin de le mettre à la disposition des acteurs de décision pour qu’ils puissent piloter, coordonner et finaliser le comportement du système opérant ».8 C’est donc une implémentation, sous forme de processus en interaction et non de services, qui implique de la compétence aux acteurs de l’équipe du projet tout en prenant en compte les aspects dynamique et l’adoption des méthodes et outils pour minimiser ou maîtriser les facteurs susceptibles de compromettre un projet de développement. Ici, l’on devra par exemple tenir compte de la qualité des spécifications produites en amont (spécifications des besoins et spécifications des exigences qui doivent être adéquates, non-ambiguës, cohérentes, vérifiables, modifiables, traçables, etc.), et en aval, des erreurs sur les artefacts produits durant l’implémentation, qui ne reflètent toujours pas les besoins réels et ne satisfont presque pas in fine les exigences fournies, pour ne pas connaître un échec. Dans ce contexte, le sommet stratégique de l’entreprise ou le maître d’ouvrage (MOA) qui met sur pied une organisation, sous forme de projet, et des moyens sûrs pour le pilotage des processus ou des activités liées, va alors confier à sa fonction systèmes d'information (maître d’œuvre, MOE, qui apporte alors ses connaissances de l'environnement technique et financière puis son expérience sur des solutions technologiques au sein de l’entreprise), la mission d’élaboration en amont d’un document qui spécifie les besoins fonctionnels du produit – logiciel à acquérir et/ou à développer et, en aval, de développement et/ou d’acquisition, soit partiellement ou totalement, de ce produit – logiciel sur la base d’un mode de gestion choisi et/ou décidé. Néanmoins, « au regard de la politique de rationalisation des coûts mis en place, la fonction financière et la fonction des approvisionnements de l’entreprise, auront aussi leur mot à dire sur les budgets à allouer » (Antoine Crochet D., 2011). On se retrouve alors face à un projet informatique de développement ou un projet système d’information dont les ressources humaines, techniques, procédurales et méthodologiques à mettre en œuvre doivent être orientées vers l’amélioration continue et vers la livraison d’un produit logiciel fiable. Cette vision commune de gestion des systèmes d’information et de gestion de la qualité dans un développement informatique s’appuie sur la vision globale de l’entreprise, mais aussi à la nature de l’activité de l’entreprise, sur la décomposition par processus, à la taille de l’entreprise et aux méthodes de gestion que les dirigeants veulent mettre en œuvre.

b) Les projets informatiques ou TI : composants et limites

Ø Types et modes d’approvisionnement de projets informatiques Les projets informatiques construisent des logiciels mais aussi gèrent les matériels et tout type de dispositif de communication numérique, qui ne représentant que la partie technologique du SI, les TI.9 Ils soutiennent alors l’évolution du système d’information dans une entreprise et font partie, de manière générale, des projets « systèmes d’information ». Leurs objectifs ne sont pas seulement ceux qui sont rattachés à la gestion des difficultés (pas seulement techniques) de conception et de réalisation des logiciels mais aussi celles de la mise en œuvre, exploitation et au

8 TARDIEU Hubert, NANCI D., PASCOT Daniel, Conception d’un système d’information : Construction de la Base des données, Edition d’organisation, Gaëtan Morin Editeur, Paris, Québec, 1980 pages 30-31. 9 Les TI (Technologies de l’information), en anglais Information Technology, sont des composantes de nature technique que les organisations ou les entreprises achètent, développent ou combinent pour constituer l’infrastructure technologique qui permet, par la suite, à leur SI de fonctionner.

6

maintien des services du système d'information d'une entreprise en s’appuyant sur les architectures informatiques et les réseaux de communications. Ils sont alors complétés, ces objectifs, des plusieurs propriétés telles que la sécurité des données (protection, confidentialité, intégrité), la sécurité des traitements (disponibilité, sûreté) et la qualité de service (disponibilité des services, pérennité, relation avec les utilisateurs). Généralement, il existe deux types de projets informatiques, à savoir : « les projets d’exploitation informatique » et « les projets de développement et/ou de maintenance logiciels ». Ces deux types de projets informatiques tournent autour de cinq dimensions fondamentales, à savoir : (1) sa mission, (2) ses activités critiques, (3) les compétences et connaissances de ses membres10, (4) sa relation avec le reste des unités d’affaires de l’organisation où il s’exécute et (5) sa gouvernance. Ainsi, les projets de développement, qui concernent l’évolution et l’entretien des plateformes technologiques, sont souvent réalisés à l’externe d’une organisation pour des raisons de productivité et de performance (approche « outsourcing »). En faisant l’objet de développement d’un système logiciel à intégrer au sein d’un système d’information existant, les acteurs de l’organisation partenaire auront à partager par exemple les responsabilités, les risques et les bénéfices éventuels du projet avec les acteurs de l’organisation interne en plus de l’obligation de transfert d’expertises. Vital Roy et alii (2007) alignent, selon la disponibilité de acteurs compétents et la valeur stratégique de l’informatique dans une entreprise, quatre modes d’approvisionnement distincts pour répondre aux besoins de développement logiciels. Il s’agit des modes d’approvisionnement à l’interne, en partenariat, en impartition11 et en récupération ». Ces modes sont constitués selon qu’il s’agisse d’une vision informatique de développement à forte ou à faible transformation organisationnelle. Les modes en partenariat et en impartition constituent tous deux un projet informatique de développement de type mixte. C’est une structure organisationnelle temporaire orientée vers l’accomplissement d’un objectif, le développement du système logiciel, par le partenaire technologique interne de l’organisation, c.à.d. sa fonction système d’information (maître d’œuvre technologique de l’organisation), et un sous – traitant (partenaire externe). Ici, les acteurs impliqués, experts métier et informaticiens de différentes spécialités (concepteurs, développeurs, designers, testeurs, administrateurs de bases de données, etc.), qui unissent et harmonisent leurs efforts pour faire aboutir ces projets logiciels, ne doivent pas seulement se préoccuper des différents processus et procédés12 qui s’y rattachent [procédés prédictifs (V, W, cascade, …) ou procédés synthétiques ou agiles (RAD, XP, Scrum, …)], mais aussi de la gestion des coûts, des délais, du temps, des ressources et des communications suivant les cahier des charges définis.

Ø Organisation et moyens de pilotage d’un projet de développement logiciel mixte En cherchant d’élaborer des dispositifs pour conduire un projet de développement logiciel mixte, basés sur le concept de contrôle et de la régulation qui guide son fonctionnement et son évolution, on aboutit alors à la définition et au dimensionnement des moyens à mettre en œuvre. Dans cette

10 Celles - ci sont vues à la fois sous l’angle d’un savoir tacite (compétences des acteurs TI dans l’utilisation des TI ou dans la gestion des projets TI mais aussi leur vision à retirer du rôle des TI dans les processus à gérer) et d’un savoir explicite (connaissances technologique des acteurs et sur les applications et le développement des SI mais aussi sur leur gestion). 11 Ce mode d’approvisionnement est parfois appelé mixte dans le cas des entreprises de taille moyenne ayant une valeur stratégique et pour lesquels les ressources et les compétences requises sont en partie disponibles à l’interne. Il associe alors, dans ses activités de conception, de réalisation et d’implémentation, le transfert, l’acquisition et l’échange d’expertises entre les ressources du projet. 12 Un procédé est cet ensemble des moyens et des méthodes permettant d’accomplir une activité. En fixant les procédés (quand ceci est nécessaire), on prescrit le comment faire. Ne confondons jamais les mots procédé et processus qui se disent tous deux en anglais « process ».

7

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

13 Le manque d’une communication dans un projet de développement logiciel peut amener à une différence de compréhension entre les différents acteurs. En gérant l’ensemble de la communication du projet, le chef de projet TI devra ainsi informer de manière régulière et efficace les différents acteurs des évolutions fonctionnelles (rendre compte de la performance par exemple) sur chaque processus défini dans le cadre du projet et pouvoir réfléchir sur une option à prendre. 14 Ici, le profil de la fonction SI est très important et devra être connu d’avance. Guy Paré et Guillemette Manon (2007) en propose cinq, à savoir : le partenaire, le fournisseur de systèmes, le concepteur d'infrastructures, le leader technologique et coordonnateur de projets TI dans une entreprise.

8

opérationnels plutôt que les documentations exhaustives, la collaboration avec les clients plutôt que la négociation contractuelle et l’adaptation au changement plutôt que le suivi d’un plan ».

Ø Les processus et les activités dans un projet informatique de développement logiciel Un processus, de manière générale, représente un ensemble d’activités effectué par une ou plusieurs personnes dans le but de créer un produit, avec un coût et des moyens matériels. Il est souvent constitué de sous processus, ou tâches, selon une décomposition hiérarchique dont l’activité est l’élément du plus bas niveau. L’activité est donc un processus qui tente de transformer des entrées en sortie. Les activités se définissent alors comme un ensemble homogènes d’actions, concourant à un même objectif, et nécessitant les mêmes compétences, et analysant les types de travaux et les responsabilités opérationnelles. En les décrivant, on définit le quoi faire. Elles possèdent alors des points d’ancrage ou d’interaction entre eux qui renvoient à l’articulation des phases dans un projet. Ainsi, dans une gestion globale de développement logiciel, plusieurs processus peuvent exister [processus de vérification et de validation (tests, contrôles, preuves, etc.), processus de gestion des anomalies, etc.] et peuvent s’interférer avec celui de gestion de projet suivant une approche d’amélioration continue (figure 1). Ici, la notion d’activités suit donc les mêmes principes que les processus dans le cycle de développement, et leur maîtrise, comme nous avons dit précédemment concernant les procédés, est très essentielle dans l’exécution du projet. Elles englobent ainsi des phases d’analyse, de conception, de programmation, de tests logiciels, d’installation, etc. et permettent une prise en compte des exigences du MOA par le MOE pour la réalisation d’un produit – logiciel.

2013-01-17 G

P000 : Introduction (v240b) � L. Lavoie (UdeS)

24

INTRODUCTION UN CVL DE DÉVELOPPEMENT LOGICIEL INSPIRÉ DE L’IEEE

� ����� ����)� )������

���� ��)��)� �!�)� )������

�������)��)� ���$

�$!����������)��)� )��� ���� ����

���� ����

�������)��)� )������ � ����

�$����� ����)��)! ��� ����

�! � ����

�$� ���(����

�� �#������������

����$���� �������

���� �� ����

�! ��(������ �$!�����������"����� ����)��)� ����� ��� ��%� ��

�������)��)������

����!��$�)������� ��

�#���)��)�$!����������)� )��������

�#���)��)!��)� )��������

�$� �� ��)� )������

�� ��)��$ � ��� � ����� ���)

��) ����� ���

� � � � � �

�����������)���)

���� ���)& ����! ��'

Fig.1. Cycle de vie du logiciel inspiré de l’IEEE intégrant le cycle de développement du logiciel (source : Luc Lavoie, 2007).

En somme, la réalisation de toutes ces activités ou de différents processus dans un cycle de vie du logiciel matérialisent le plan qualité, qui essaie de donner à son tour une vision globale et complète du projet en permettant des effets zoom sur le développement du logiciel mais aussi sur la manière dont la qualité devra être assurée tout au long de la réalisation du logiciel. Quant à une procédure, elle est définie par la norme NF EN ISO 9000 : 2000 comme une manière d’accomplir une activité et traite de son aspect organisationnel en répondant aux questions de qui fait? Et quand le fait-il?

9

c) Autres éléments à considérer dans un projet informatique de développement logiciel.

Ø Plan et clauses qualité dans le développement logiciel Dans un projet informatique de développement logiciel, le plan qualité logiciel, ou plan d’assurance qualité (PAQ), définit les mesures d’assurance de la qualité du logiciel pris en s’inscrivant dans la politique globale du MOA en matière de qualité. Il fait donc le suivi de la mise en œuvre de l’assurance qualité et la gestion des risques devant être appliquée tout au long du projet. Les recommandations sur le produit – logiciel souhaité marque alors une problématique sur sa fiabilité.15 Il s’agit en fait d’une priorité pour un projet donné de développement informatique et constitue son outil de communication de référence, pour le management de la qualité, validé par les parties, où chaque intervenant trouve exposer sa place et son rôle, tout en spécifiant quelles procédures doivent être appliquées pour réaliser une tâche ou un processus ? Le PAQ fait mention aux caractéristiques logicielles au sein duquel s’instancie la stratégie de test en rapport avec la qualité. Ces caractéristiques forment donc des exigences qualité logicielle et peuvent se mesurer à l'aide des indicateurs ou métriques ci – après :

- la maniabilité (communicabilité, exploitabilité et facilité d’apprentissage), - la fiabilité (complexité, tolérance aux fautes ou pannes et auditabilité), - l’efficience (consommation en place mémoire, taille des périphériques et leur

vitesse d’accès et temps d’exécution des programmes), - la confidentialité (protection du code et des données et mémorisation des accès), - la couplabilité (standardisation des données et standardisation des interfaces), - la maintenabilité (lisibilité, modularité, traçabilité et adaptabilité), - l’adaptabilité (évolution facile du logiciel), - la portabilité (banalité d’emploi, indépendance et qualité de documentation), et - l’efficacité (coûts et gains dus au logiciel).

Ce sont donc des clauses qualité (contractuelles ou non). Dans cette perspective, la version 1.2 du référentiel CMMI – DEV de Humphrey W., développé par Software Engineering Institute de l’université de Carnegie Mellon, ira même à déterminer que la qualité d’un logiciel devra être en relation directe avec la qualité du processus utilisé pour son développement. Ainsi, actuellement, pour développer par exemple un logiciel de qualité, un programmeur procède par la création de composants16 qui permet de construire par la suite le logiciel. Pour cela, il explore des bibliothèques logicielles antérieures pour trouver et constituer des composants logiciels appropriés pour une nouvelle bibliothèque. Cette réutilisation de composants ou des briques logicielles est une des approches de maturité ou d’amélioration dans le domaine de développement dite framework (COM et ses dérivés), issu de OLE (Object Linking & Embedding) de Microsoft car on n’écrit presque plus des logiciels à partir du néant. Avec cette approche amélioration continue, le programmeur a seulement l’obligation de proposer une architecture logicielle harmonieuse aidant voire à palier plus tard à une dégradation logicielle [cfr. modèle d’architecture des 4+1 vues (Philippe Kruchten, 2000)

15 Un logiciel est un produit immatériel, reproductible, maintenable et subjectif dont les seules représentations observables sont le code source, l'interface utilisateur et la documentation (spécification d’exigences de système, documents de tests, manuels utilisateur, etc.). Pour être considéré comme un produit de qualité, le logiciel doit donc répondre aux besoins exprimés explicitement par l'utilisateur aussi bien qu'aux besoins implicites ou non exprimés. 16 L’usage de cette approche modulaire, par une équipe de développement informatique, permet d'assurer au logiciel une meilleure lisibilité et une meilleure maintenance. Cette approche est voire en phase d’émergence et porte le nom de la programmation orientée composant. L’on doit noter que dans cette approche de développement par et pour la réutilisation logicielle, un cycle de production - réutilisation perpétuel (intégration continue) et une architecture logicielle normalisée est imposé.

10

et modèle d’architecture de 4 niveaux de MDA – Model Driven Architecture ou architecture basée sur les modèles en français (Xavier Blanc, 2005)].

Ø Gestion des risques Un projet informatique de développement logiciel, comme dit au début de notre document, présente des risques que l’on doit maîtriser lors de son exécution. Pour Chantal Morley (2004), cette maîtrise ou gestion des risques « consiste à réduire l’incertitude par une analyse approfondie des caractéristiques internes et environnementales du projet et à élaborer des stratégies pour faire face aux risques plus graves et/ou plus probables ». Pour ce faire, il faudra alors utiliser la démarche générale qui comprend (1) l’identification des risques, (2) l’évaluation de leur impact possible sur les coûts, le délai et la qualité, (3) la définition des actions ou la prise des dispositions aptes à réduire les risques jugés inacceptables, (4) le suivi de ces actions et (5) la capitalisation de l’expérience. Ainsi, lors des activités de tests par exemple, l’identification des risques sera réalisée voire à partir des différents éléments analytique du logiciel ou système sous test (cas d’utilisation, processus métiers, caractéristiques qualité, etc.), en anglais System Under Test (SUT).

Ø Plan de développement logiciel C’est un document qui décrit, pour une réalisation logicielle, la décomposition en produits (l’architecture du logiciel, les choix technologiques, les modules ou les composants logiciels - entrées, sorties et traitement -, la conception des interfaces du logiciel avec l’extérieur - description des données échangées, de leur organisation en messages, des protocoles d’échanges - et la conception des bases de données) et en fournitures, les moyens à mettre en œuvre, les tâches nécessaires et les délais à respecter. Le plan de développement logiciel (PDL), suivant les recommandations de la norme NF EN ISO 9000-3 qu’on fait appliquer aux activités informatiques de la norme NF EN ISO 9001, inclut la définition et les objectifs d’un projet, l’organisation d’un projet et les moyens en personnel, la méthodologie et les phases d’un projet, la gestion d’un projet et la vérification logiciel. Section II. La réalisation de logiciels et les exigences de vérification et de validation

a) Activités clés et leurs considérations

Ø La programmation ou l’écriture des codes dans un cycle de développement du logiciel La programmation constitue l’activité la plus connue et cruciale dans la phase de réalisation. Elle est appelée voire par certains développeurs ou ingénieurs logiciels « la phase de développement ». Le Professeur Printz Jacques (2002), en définissant la programmation, parle voire de l’âme du système informatique ou du logiciel en développement. C’est donc une activité qui, dans le cycle de développement, incorpore d’autres autres activités qui sont essentielles pour l’implantation du produit – logiciel à configurer et/ou à installer. Elle est bâtie sur des éléments ci – après :

- une documentation, basée sur l’expression des besoins, l’exigence des utilisateurs et la conception détaillée aidant au déploiement et à la maintenance du logiciel ;

- un programme ou module de programme, contenant une suite d’instructions (algorithmes, structure des données en entrée et en sortie, codes, etc.) exécutables par la machine ;

- des tests et résultats de série des tests ; et enfin - un environnement intégré d’exécution ou de développement (IDE17),

17 Environnement de Développement Intégré, ensemble d'outils intégrés (éditeur de texte, compilateur et débogueur) dédiés aux langages de programmation pour augmenter la productivité des programmeurs qui développent des logiciels.

11

Modifications induites

Archivage du scénario et des résultats

Analyse / Comparaison des résultats

Analyse et explication des différences

Spécification du test

Exécution et mise au point du test

et permet, soit de façon récursive ou itérative, les tests des programmes informatiques qui, une fois déployé, assureraient au sein d’un système d’information les fonctions nécessaires face au traitement et au stockage de l’information. Les différents programmes informatiques sont écrits avec l’aide des L4G (Visual Basic, C#, Java, Delphi, Python, Turbo Pascal, etc.) et font parfois apparaître des erreurs, dues essentiellement au caractère humain et à la nature profonde du logiciel lui – même. Ils sont souvent payants ou gratuits/libres après compilation. Ici, le seul effort à fournir par les acteurs clés du projet, pour pouvoir obtenir un produit – logiciel fiable et de meilleure qualité, serait de pouvoir corriger ces erreurs par la mise sur pied d’une série d’activités de vérification et de validation bien ficelées.18 Ces activités doivent être au service d’une stratégie qui, dans un environnement de développement logiciel, constitue voire la base d’un processus de tests, c.à.d. la façon dont ses activités de tests devront être mises en œuvre (figure 2). Le manque de ces activités dans un projet, surtout de type mixte, peuvent s’avérer coûteux et parfois même dangereux. Il risque même au bout du compte d’accroître le niveau d’incertitude dans le développement, surtout si l’on décide encore de se lancer dans les tests sans pouvoir élaborer un modèle de tests.

Fig.2 : Exemple d’un processus simple des tests logiciels incluant certaines procédures (source : Printz Jacques, 2002).

L’implémentation de ces activités de vérification et de validation, depuis l’expression des exigences jusqu'à la mise en œuvre d’un référentiel normatif de tests, permet d’assurer à la fois la productibilité des scénarios de test, de mesurer leur qualité et de mieux maîtriser leurs coûts. Elle rentre donc dans

18 La vérification logicielle est formelle ou semi formelle, c.à.d. mathématique ou « exhaustive ». On cherche donc à prouver au sens mathématique que le logiciel (vue comme un modèle logique) satisfait à sa spécification (vue comme un ensemble de formules logiques). Cette activité complexe se matérialise soit par des sous approximations (tests) ou soit par des sur approximations (abstractions). Actuellement, les preuves assistées l’accompagnent aussi.

Objectifs

Scénario Résultats et comportements attendus

Incorrecte

Dans le test Dans le programme

Résultats et comportements observés lors de l’exécution

Correcte

Gestion de configuration (sources, tests et documentation)

Etat d’avancement des scénarios de tests

12

le cadre des bonnes pratiques dans le développement logiciel. Elle semble être couteuse, cette implémentation, « … et ce d’autant plus que la combinatoire induite par la structure des données d’entrée, les modes de fonctionnement autorisés, les différents paramétrages, est totalement explosive ».19

Ø Le test logiciel : Elément visible et dynamique lors des activités de vérification et de validation d’un produit – logiciel en développement

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

13

En somme, les activités de validation et de vérification visent le même but, à savoir l’évaluation de la qualité des spécifications produites tout au long du développement logiciel (logiciel compris). Les tests logiciels, qui en font partie, même s’ils représentent 30 à 40 % des coûts de développement suivant son niveau de criticité, restent la seule technique visible et la plus couramment utilisée pour s’assurer que le logiciel réalisé est correct et répond aux exigences formulées ou convenues au départ. Ils tiennent donc un rôle central dans la politique d’assurance qualité d’un produit - logiciel. La confiance apportée à ses activités dépend en grande partie de la pertinence des entrées sélectionnées et de la multiplicité de méthodes et d’outils actuellement disponibles sur le marché.

b) Eléments aidant à la vérification et à la validation d’un produit logiciel

Ø Les différents niveaux de tests logiciels La recherche des défauts ou la détection des erreurs dans un logiciel, comme nous l’avons dit, se fait préventivement au niveau de chaque phase de son cycle développement. Ainsi, en observant le modèle de développement du logiciel en V (voir figure 3 ci – dessous), nous observons que les différentes phases de développement du logiciel, qui sont décrites de manière séquentielle, et par domaine, sont accompagnées parallèlement des séries de tests.

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

Au fait, quatre niveaux de tests y figurent et sont exécutés tous comme un processus de test au fur et à mesure que l’on avance dans le développement (programmation de composants, intégration de composants, conformité avec les exigences, etc.). Ces quatre niveaux définissent voire des jalons intermédiaires de validation, aidant à s’assurer de la fiabilité du produit - logiciel face aux besoins exprimés par le maître d’ouvrage dans chaque phase de développement concernée. Ci – dessous, les explications détaillées de ces niveaux de tests :

- les tests unitaires ou de composants : ils concernent la vérification de chaque module du logiciel en isolation. Ils ont pour principaux objectifs de vérifier la mécanique, l’ergonomie et la présentation des programmes, de s’assurer que toutes les règles sont implantées et de s’assurer du bon fonctionnement des interfaces, rapports et traitements ;

- les tests d’intégration : Ils concernent la vérification du comportement relatif des modules entre eux. Les activités principales sont les enchaînements entre modules, la circulation des données, les aspects dynamiques, les séquences d’événements prévus (probabiliste) et les reprises en cas d’interruption. Son but est d’activer les

Analyse des besoins et faisabilité

Spécifications

Conception architecturale

Conception détaillée Tests unitaires

Tests d’intégration

Tests d’acceptation

Installation et tests système

Programmation

14

fonctionnalités liées à la partie concernée du logiciel partiellement intégrée sur base des processus opérationnels (du côté utilisateur). Ils sont attachés à la phase de conception architecturale ;

- les tests de validation ou d’acceptation des fonctionnalités du logiciel : ils concernent la vérification des fonctionnalités réelles du produit – logiciel décrites lors de la phase de spécification des exigences. « Ils vérifient plus particulièrement les fonctions générales, les interfaces matériel / logiciel, le fonctionnement temps réel, les performances, l'utilisation et l'allocation des ressources » (Charpentier P., 2000) ; et

- les tests système ou de conformité : Ils consistent à tester le logiciel dans un environnement similaire à l’environnement de production (vision du concepteur lors de la phase d’analyse des besoins et de faisabilité). Ici, les revues et les analyses qu’on fait permettent alors de répondre à la question de correspondance (portée) avec le logiciel à livrer, ce qui dépasse par moment l'étude des tests du logiciel.

Ces quatre niveaux décrits constituent des groupes d'activités de tests qui sont gérés ensemble, en rapport direct avec les responsabilités telles que définies dans les différentes phases du projet. Ils sont souvent exécutés suivant les caractéristiques et les modalités logicielles fixées (performance, ergonomique, installation, fonctionnelle, robustesse, vulnérabilité, etc.).

Ø Les méthodes et les outils dans les tests logiciels Les méthodes et les outils, comme nous l’avons mentionné à la section I de la présente contribution, sont des référentiels de niveau inférieur, classés par secteurs d’activités (logiciels, production, sécurité, projets, etc.) et qui, au niveau supérieur, deviennent un ensemble de normes.24 Ils sont choisies spécifiquement en fonction du contexte de projet (développement en partenariat, en impartition, en interne, etc.) et introduisent la notion de la qualité tout en contribuant au progrès des pratiques scientifiques soit par une approche de management basée sur l’amélioration ou sur les processus ou encore la maîtrise documentaire. Pour les tests logiciels, deux méthodes ou techniques de vérification et de validation existent actuellement. Elles déterminent le degré de rigueur exigé dans un projet de développement afin d’éviter les fautes dont le logiciel peut être la cause. Ces sont donc des protocoles expérimentaux qui provoquent un ensemble de réponses (résidu d'erreurs) qui montrent que la transformation à opérer par le programme est correcte ou non et sont complémentaires. Il s’agit en fait de :

- méthodes d’analyses statiques : ce sont des techniques qui se réfèrent à l’analyse d’anomalies, aux lectures croisées, à l’inspection, à l’approximation, etc. qui sont opérées au moment de la compilation. Elles traitent les tests du logiciel sans exécuter ce logiciel sur des données réelles et se rapprochent de l’ensemble des valeurs ou des comportements qui découlent dynamiquement à l’exécution du programme. Appelées parfois tests statiques, ces techniques sont utilisées pour vérifier des programmes, dans le but de découvrir des bugs car elles opèrent sur les codes. Ces techniques sont aussi particulièrement importantes pour les cas de tests qui mettent en jeu le parallélisme. Ici, les techniques dynamiques de tests sont parfois peu applicables en raison du non déterminisme des résultats à obtenir, etc. Le débogueur de l’IDE Visual Studio est parmi les outils dédié ; et

24 Comme l’énonce Jacqueline Sidi (2003), les normes sont donc des outils plutôt que des exigences inestimables pour les entreprises. Elles sont utilisables au quotidien dans un contexte opérationnel, mais aussi pour la formation du personnel qui devra s’approprier le produit – logiciel en développement.

15

- méthodes dynamiques de tests : ces méthodes ou techniques sont souvent appliquées à des tests de spécifications fonctionnelles ou d’exigences de qualité (robustesse, performance, etc.) du système. Cette série de tests sont donc des tests fonctionnels (boite noire), qui ont à charge de vérifier, à partir des certaines valeurs d’entrée, que les différents comportements du système sont conformes à ses spécifications (résultats attendus basés sur des valeurs de sortie). Elles reposent aussi sur l’exécution effective du logiciel, c.à.d. de sa structure interne (boite blanche ou tests structurels), dans un des ses sous ensemble (codes, description du programme, etc.), qui est bien choisi du domaine de ses entrées possibles. Ici, les techniques de tests disposent des quatre activités principales qui sont la sélection (d’un sous ensemble des entrées possibles du logiciel, appelé jeu de tests), la soumission du jeu de tests, le dépouillement des résultats et l’évaluation de la qualité des tests effectués. Ces deux types de tests, fonctionnels et structurels, sont donc complémentaires. Toutefois, les tests structurels s’accompagnent toujours de tests dits de non régression qui interviennent toujours après une correction ou une modification de codes dans un programme et/ou dans un module de programme.

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

16

réactivité puis qualité), les équipes expérimentées de développement logiciel, qui utilisent les procédés agiles (XP, RUF, SCRUM, etc.), commencent aussi à utiliser dès la phase de spécification ces outils de tests cités, en se basant sur des exigences évoluant27 ou changeant durant tout le long du cycle de vie du logiciel (Lydie du Bousquet, 2010). Ainsi, les cas de test à générer manuellement ou automatiquement, qui matérialisent la cohérence et/ou la traçabilité entre les éléments des différents artefacts produits par les différentes activités d’un processus de développement, constituent alors un modèle28 comportemental de logiciels sous test, ou tout simplement un modèle d’exigences (Jean-Marc Jézéquel, 2006, Xavier Blanc, 2005, etc.). Ces modèles comportementaux de logiciels sont construits à partir des exigences ou des spécifications textuelles qui peuvent être fonctionnelles (fonctions spécifiées pour le logiciel, point d’entrée ou de sortie de la phase de spécification) ou structurelles (fonctions codées dans le logiciel).

Ø Les exigences fonctionnelles, des outils normatifs non négligeables lors de l’élaboration d’un modèle de tests de logiciels

Les exigences ou les spécifications constituent, dans une modélisation, des contraintes que le MOE devra respecter lors des tests dans le but de faire disposer réellement au MOA le produit qu’il souhaite et/ou qu’il souhaitait. Elles sont produites, ces exigences, à partir des activités de collecte, rédaction, compréhension et évaluation en amont de besoins métiers des utilisateurs. Cette série d’activités indépendantes, liées à l’ingénierie des exigences mais aussi à l’ingénierie des modèles, est donc vue comme un processus de raffinement itératif mais aussi de modélisation, à l’aide de langages munis d’une sémantique formelle (UML par exemple car il permet la modélisation de systèmes indépendamment de toute démarche ou de plate – forme). Au fait, ce processus se termine lorsque les exigences sont suffisamment précises ou reformulées par le MOE pour ainsi appliquer les techniques de vérification et de validation dans un système sous test. Cette matérialisation de l’IDM va produire un modèle qui sera utilisé pour répondre à des questions sur le système modélisé. Il ressort de cette logique de substitution que ces exigences reformulées, à vérifier sur un produit – logiciel visant la qualité, expriment un modèle dynamique d’exigences (Computation Independent Model, CIM) et directement opérationnel pour d’autres phases de développement du logiciel. Ainsi, ce modèle d’exigences va à son tour donner corps à un modèle de tests système et à un modèle d’analyse ou à des modèles extra – fonctionnels (Platform-Independent Model – PIM). Cette transformation de premier niveau, qui garantit les liens de traçabilité entre les modèles et les besoins exprimés par le client, est essentielle suivant l’approche MDA (architecture à 4 niveaux) à la pérennité des modèles. Ainsi, les techniques de vérification et de validation, comme explicité dans les points précédant, qui sont basées sur les stratégies de tests, vont s’appuyer sur le modèle d’exigences pour définir les algorithmes et les critères de sélection des cas de test à réaliser sur un système sous test. Derrière cette approche formelle ou semi formelle (MDA), dite aussi « de transformation de modèles » (figure 4), le modèle d’analyse et/ou les modèles extra – fonctionnels (Platform-Independent Model – PIM), qui sont des captures de plusieurs informations relatives au domaine métier, initialement dispersées dans une collection de données d’entrée (besoins des utilisateurs, processus métiers, etc.), donneront corps à leur tour à un modèle de conception (Platform-Independent Model – PIM et Platform Specific Model – PSM) mais aussi à un codage du système (Platform Specific Model – PSM). Cette étape est voire nécessaire pour démarrer avec les tests de

27 On ne peut éviter l’évolution des exigences. La seule chose à faire c’est de chercher à maintenir leur traçabilité. 28 Un modèle est une représentation ou une description d’un logiciel ou d’une partie d’un logiciel dans un langage bien défini mais à des différents niveaux d’abstraction. L’Ingénierie Dirigé par les Modèles (IDM), Model – Driven Engineering (MDE), en anglais, qui est son paradigme de modélisation plaçant les modèles au cœur du processus de développement pour en faire les éléments clés par lesquels les logiciels sont générés, décrit un logiciel avec un haut niveau d'abstraction indépendamment de la plate – forme utilisée, d'un point de vue utilisateur. Il s’appuie sur l’initiative MDA (Model – Driven Architecture), menée par l’OMG (Object Management Group).

17

niveau inférieur (unitaires et d’intégration) permettant d’affiner la structure et l’état interne du système sous tests. Ici, on peut alors se servir des techniques MBT (Model-Based Testing (MBT), qui se situent pour la plupart de cas au niveau des activités inférieurs de tests (tests unitaires et tests d’intégration), pour générer et exécuter, au moyen des algorithmes, soit par génération aléatoire de codes ou soit par prédicat de chemin, ou encore par exécution symbolique des chemins ou par exécution concolique, les cas de tests d’un logiciel sous test mais aussi améliorer la détection des bugs, la qualité logicielle, la traçabilité et l’évolution des exigences reformulées.

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

18

supérieur) mais aussi permettre son déploiement et sa configuration complète. Ceci se fera bien sûr indépendamment du langage30 et de la plate-forme cible puis séparera le contenu logique de la présentation physique.

Ø Efficacité de tests logiciels dans un projet informatique de développement logiciel L’efficacité est un concept très complexe, floue, instable, polymorphe et polysémique qui est souvent souhaitée lors des activités de vérification et de validation qui sont les deux approches utilisées pour les tests logiciels. Ainsi, dans notre contexte, l’efficacité souhaitée pour une série de tests logiciels dépend crucialement de la qualité des cas de tests et des données de tests générés manuellement ou automatiquement mais aussi de la démarche de tests qui se doit donc de respecter plusieurs impératifs : la définition des politiques définissant les modalités d’applications de ces tests (planification dans les différentes phases du cycle de vie du logiciel, fréquence et conditions d’exécution, rôle de chaque membre de l’équipe), le déploiement de l’infrastructure (matérielle et logicielle) permettant la mise en œuvre de ces politiques ainsi que les processus assurant le contrôle du respect des politiques, l’environnement matériel et de développement pour l’intégration fonctionnelle et la mise en œuvre de tests et ensuite l’expertise nécessaire de l’équipe pour la gestion du plan de tests, la création de données fonctionnelles et de tests. L’efficacité de tests, c’est aussi le modèle de tests lui – même, généré à partir d’un modèle d’exigences, qui doit se conformer aux procédures et aux conditions préalablement définies au début d’un processus de développement (omniprésence ou pas) dans le but de pouvoir disposer d’un logiciel fiable.

c) Quelques autres définitions clés relatives aux tests. La stratégie de tests C’est un préalable nécessaire pour la mise en place des objectifs de tests. Elle témoigne donc d’une réflexion sur la pratique réelle des tests (conception de cas de test, écriture de scripts de test, fourniture de données de test, observation et analyse résultats de test et rédaction d’une documentation associée pour le test, etc.), visant à augmenter la fiabilité du produit – logiciel et à diminuer les défauts dus à sa programmation (objectif qualité). Son absence, comme dit Charpentier P. (2000), indique un risque d’improvisation pour les tests mais aussi pour les autres phases du développement logiciel. L’obligation de test C’est une spécification partielle de test qui décrit une propriété jugée importante dans un contexte donné. Le cas de test C’est le chemin fonctionnel à mettre en œuvre pour atteindre un objectif de test. Il spécifie donc la manière dont une fonction ou une combinaison de fonctions (scénario de test) doit être testée ou dont il convient qu’elle le soit. Le scénario de test C’est un ensemble autonome et cohérent d’interactions avec le logiciel regroupant un ou plusieurs tests élémentaires, et les éventuelles phases préparatoire et finale de ces tests élémentaires. Ici, le cycle de vie pour ces tests logiciels va se fabriquer en fonction des objectifs qui résultent de la stratégie de vérification et de validation adoptée et des informations disponibles pour exécuter des scénarios de cas d’utilisation, mais aussi les différentes exigences qui y sont rattachés.

30 Notons qu’en dehors de l’UML, l’IDM utilise aussi d’autres langages de modélisation qui sont dédiés à un domaine particulier. Le DSL (Domain Specific Language – DSL) par exemple offre aux utilisateurs des concepts propres à leur métier (le métier dont ils ont la maîtrise).

19

Les preuves logicielles La preuve démontre et/ou établit la vérité de quelque chose. C’est donc une opération mathématique par laquelle on contrôle l’exactitude d’un calcul ou la justesse de la solution d’un problème. Dans le domaine de développement logiciel, la preuve s’utilise à des différentes fins basées sur les méthodes formelles car un système ou un logiciel à vérifier et/ou à prouver doit être soit formel ou semi-formel.31 Malgré cela, lorsqu’on procède à ces preuves logicielles, au moyen des outils assistés, le test défini sert seulement à démontrer sur une spécification ou une exigence qu’une certaine situation se produira toujours ou ne se produira jamais. Ainsi, avec le regain actuel des pratiques de génération automatiques de tests structurels, les solutions MBT, qui génèrent et prouvent automatiquement des spécification ou des exigences, risquent de faire retrouver la communauté scientifique face à un problème d’indécidabilité (à ce jour, il n’y a pas encore de script capable de prouver automatiquement la correction de tout logiciel, Ivinza Lepapa A. C. et Mbuta Ikoko D. A., 2006). Parmi les types de preuves existants, nous pouvons citer les preuves de conception, de programmation et en pratique. III. ELABORATION D’UN MODELE DE TESTS POUR LE PAYMENT MANAGER Section I. Démarche pour l’élaboration du modèle de tests

a) Objet et démarche d’élaboration de l’ébauche Nous comprenons, tel que décrit dans l’introduction, que l’objet de notre contribution concerne l’incitation d’usage, par les professionnels TI congolais, des méthodes, outils et techniques d’ingénierie logicielle et d’exigences, classiques ou agiles, pour la vérification et la validation d’un produit – logiciel. Au cours des points précédents, nous avons essayé de présenter globalement les éléments qui rentrent dans les caractéristiques d’un projet informatique de développement logiciel en général et mixte en particulier, pour pouvoir produire efficacement un bien livrable (produit – logiciel) respectant les critères de qualité mais aussi ceux de réactivité et de performance contraints par les budget et délai imposés. Ces éléments concernaient particulièrement les tests logiciels, ses méthodes et outils, mais aussi les exigences aidant à élaborer des modèles de tests. A ce niveau, une présentation cavalière des exigences fonctionnelles ou structurelles dans le contexte d’ingénierie dirigée par les modèles, suivant l’approche MDA (support indispensable de génération de code, de documentation, de tests etc. directement depuis les modèles), a été effectuée où nous avons listé les différentes phases de transformation de modèles permettant d’aboutir à un modèle de tests de niveau supérieur ou de niveau inférieur. Le modèle de tests de niveau supérieur nécessite généralement l’intervention d’un expert pour effectuer certaines étapes de la transformation tandis que le modèle de tests de niveau inférieur fait l’objet d’outils de tests automatiques qui se servent des processus stochastiques pour générer de façon automatique les cas de tests mais aussi améliorer la détection des bugs, la qualité logicielle, la traçabilité et l’évolution des exigences. UML, en y ajoutant les contraintes OCL, est présenté comme une approche favorite pour sa matérialisation. Maintenant, nous allons essayer de produire l’ébauche d’un modèle de tests de niveau supérieur sur base de notre retour d’expérience comme chef de projet « IDENT - ITS », un projet mixte conduit suivant les procédés agiles combinés, XP et Scrum, pour produire un logiciel de qualité dans le délai exigé, 5 mois environs. Cette ébauche est donc produite grâce à un ensemble de questionnements d’ordre managérial et organisationnel suivant une démarche de concrétisation manuelle nécessitant

31 Dans un système à configurer et/ou à installer, la preuve d’une formule est une dérivation, c’est - à – dire une suite de formules qui se termine par la formule à prouver, et telle que la première formule est un axiome. Toute autre formule est soit un axiome, soit la conclusion d’une règle d’inférence dont les prémisses apparaissent avant elle dans la suite.

20

notre expertise tant au niveau de la connaissance de l’architecture interne du système que celui de la connaissance des interfaces réelles du système. Cette démarche est en partie la réponse aux efforts de membres de l’équipe du projet lors du processus de développement du logiciel « Payment Manager ». Elle intègre et détaille ainsi l’ensemble des règles métiers de paiement décrits dans le cadre de DDR (règles de gestion, cas et scénarios d’utilisation) et les exigences spécifiées pour les tests logiciels et certains éléments de stratégie de tests qui, formellement, devraient se retrouver dans un plan de tests. Les tests logiciels étant une activité créatrice qui exige une moyenne des compétences de la part des acteurs impliqués, il existe donc plusieurs aspects à considérer. D’abord l’aspect qui s’attache à la structure du système sous test (SUT), telles que ses structures de données, son code, etc. et ensuite, celui de la dynamique du système sous test (tests système et de validation via l’approche dite « boite noire »), représenté généralement par le biais d’interfaces implémentées. C’est sur ce deuxième aspect que nous nous focalisons. La méthodologie UML, utilisée dans la formalisation de besoins des utilisateurs, de processus et de règles métiers mais aussi d’identification de cas d’utilisation en exigences de tests puis en cas de tests, a été plus qu’une phase de conception pour produire notre ébauche de modèle de tests. C’est pourquoi elle ne sera pas détaillée dans sa totalité. Toutefois, nous illustrons partiellement quelques éléments et quelques interfaces de l’applicatif renforçant les résultats attendus sur des cas de tests conçus. Les lignes qui suivent exposent donc quelques points essentiels de ce modèle, qui donnent corps aux notions abstraites décrites aux points II.

b) Référentiels normatifs utilisés

Ø Documents normatifs Les documents normatifs clés ci – dessous ont été d’une grande utilité lors de l’élaboration de notre modèle de tests car certaines de ses lignes avaient servi lors des activités menées tout au long du processus. AFNOR, 1995 [12207] NF ISO/CEI 12207:1995 (F) Traitement de l’information – Ingénierie du logiciel – Processus du cycle de vie du logiciel AFNOR, 1996 [NF X 50-164] NF X 50-164 Relations clients – fournisseurs – Guide pour l’établissement d’un plan d’assurance qualité. AFNOR, 1999 [9000-3] NF EN ISO 9000-3:1999 (F) Normes pour le management de la qualité – Partie 3 : Lignes directrices pour l’application de l’ISO 9001 au développement, à la mise à disposition et à la maintenance du logiciel AFNOR, 2000 [8402] ISO/CEI FDIS 8402 (E) Software Quality Metrics Methodology ISO/CEI, 1998 [15288] NF ISO/CEI 15288 :2002 (F) Traitement de l’information – Ingénierie du logiciel – Processus du cycle de vie des systèmes ISO/CEI, 1998 [15846] NF ISO/CEI 15846:1998 (F) Gestion de configuration du logiciel ISO/CEI, 1999 [NF LOG] NF LOGICIEL Règlement de la marque NF Logiciel – Exigences pour le dossier de test du logiciel – Annexe 1.2

21

ISO/CEI, 1999 [9126] NF ISO/CEI 9126:2000 (F) Technologies de l'information – Qualité des produits logiciels – Partie 1: Modèle de qualité IEEE, 1990 [IEEE 610.12] IEEE 610.12 :1990 Standard Glossary of Software Engineering Terminology IEEE, 1998 [IEEE 1233a] IEEE 1233a :1998 Guide de l'IEEE pour la Spécification d’Exigences de Système [ANSI/EIA 632] ANSI/EIA 632: 1999 Processes for Engineering a System IEEE, 1999 [IEEE 1220] IEEE 1220 : 1999 Standard for application and Management of the Systems Engineering Process IEEE, 2008 [IEEE 829] IEEE 829 : 2008 Standard for Software and System Test Documentation

Ø Documents produits Les documents ci - dessous, produits par le projet, ont servi tout au long du processus de développement de ce logiciel. Dans le cadre d’élaboration de notre modèle de tests, ils ont eu aussi un regard critique.

[CCEB] Cahier des Charges et de l’expression des besoins [PDL] Plan de Développement Logiciel [PGT] Plan Global de Travail [MP] Macro Processus des différentes phases d’IVO (Identification, Vérification et Orientation) [DSFT] Document de Spécifications Fonctionnelles et Techniques [LRI] Liste des Risques Inhérents [DALM] Document d’Architecture Logicielle et de Maintenance [DCL] Document de Conception Logiciel [MU] Manuel de l’Utilisateur [PFD] Plan de Finalisation de Développement (sur les amendements)

Dans certains cas de figure (clauses contractuelles ou autres), ces documents constituent aussi une conditionnalité avant la mise en exploitation du logiciel.

c) L’équipe de tests : responsabilités et rôles Le tableau ci – dessous indique les tâches requises et/ou définies pour les tests de « Payment Manager ». Il indique aussi les différentes fonctions allouées initialement pour chacune de tâches à couvrir.

Fonctions Tâches Noms des entités impliquées Responsables métiers Observation sur les tests CELPAY, BIO – ID et UEPN –

DDR Responsable de tests Garant de tout le processus d’exécution et de suivi

de tests, définition de la méthodologie et de la stratégie de tests

UEPN - DDR

Architecte de tests Réalisation de l’architecture de tests, critique des scénarii des tests et rédaction de dossiers et rapports sur les tests

CELPAY, BIO – ID et UEPN – DDR

Concepteurs de tests Rédaction des exigences de tests, spécification et CELPAY, BIO – ID et UEPN –

22

fourniture des cas de tests, … DDR Programmeurs ou Testeurs

Codage, réalisation de chaque niveau et type de tests et consignation de résultats de tests

CELPAY, BIO – ID et UEPN – DDR

Section II. Eléments d’élaboration du modèle des tests pour le « Payment Manager ».

a) Considérations générales

Ø Le maître d’ouvrage du projet TI assurant le développement de « Payment Manager » Le Désarmement, la Démobilisation et la Réinsertion, en sigle DDR, a un caractère multisectoriel et exige une grande capacité de coordination politique, stratégique, opérationnelle et technique. Le cadre institutionnel de cette structure au niveau de la RDC, connu sous le nom du Programme National de Désarmement, Démobilisation et Réinsertion (PNDDR), est défini par le décret n°04/092 du 16 octobre 2004 puis, bien avant, par les décrets n°03/041, 03/042 et 03/043 du 18 décembre 2003, portant création du Comité Interministériel chargé de la conception et de l’orientation en matière de DDR (CI-DDR), de la Commission Nationale de DDR (CONADER) et du Comité de Gestion des Fonds de DDR (CGFDR). Le CI-DDR assure aussi le suivi et la coordination des activités du comité technique de planification et de coordination du DDR (CTPC/DDR). Au mois de juin 2007, le décret portant création, organisation et mise en place de la CONADER a été abrogé et remplacé par un nouveau décret n°07/057 du 14 juillet 2007. Ce nouveau décret créant et organisant l’Unité d’Exécution du Programme National de Désarmement, Démobilisation et Réinsertion, UEPN-DDR en sigle, marque la fin de la première phase (2003 à 2007) et le début de la seconde phase du PNDDR. Cette structure a donc remplacé la CONADER et a pour mission le parachèvement du processus DDR en RDC. La portée stratégique de l’UEPN-DDR est celle (1) d’Elaborer les critères de désarmement, démobilisation et proposer les mécanismes de Réinsertion ; (2) de Planifier les activités en rapport avec les processus de Désarmement, Démobilisation et Réinsertion et (3) d’Exécuter et parachever le PN-DDR. Maître d’ouvrage (délégué) du gouvernement congolais en la matière, elle est donc rattachée au Ministère de la défense nationale et des anciens combattants mais travaille étroitement avec les autres services compétents de l'État, de la société civile (Institutions nationales, ONG locales, etc.) et les partenaires extérieurs (Agences du système des Nations Unies, ONG internationales, Agences de coopération bilatérale, etc.). L’UEPN-DDR est dirigée par un Administrateur Général, assisté des experts et spécialistes recrutés selon les règles et les procédures de la Banque Mondiale et de la Banque Africaine de Développement. La gestion fiduciaire est assurée par KPMG / RDC. Cette combinaison de rôles fait disposer à l’UEPN – DDR d’une culture d’entreprise, non traditionnelle, influencée par les pratiques institutionnalisées congolaises.

Ø Le système d’information du maître d’ouvrage, les différents processus métiers et le profil de l’équipe TI assurant le développement de « Payment Manager »

Le système d’information de l’UEPN – DDR, issu des cendres de la CONADER, est resté organisé autour des plusieurs processus métiers dont trois en représentent le cœur. Il s’agit au fait :

- du processus d’enregistrement ou identification des ex combattants désarmés (identification avec capture de l’iris sur l’applicatif « Ident – Congo ») ;

- du processus de paiement des ex combattants désarmés et démobilisés (indemnité transitoire de substance à donner à l’ex combattant via la technologie de paiement électronique par mobile) ; et

- du processus de réinsertion socio économique des ex combattants désarmés et démobilisés (Allocations des bénéfices pour une réinsertion viable avec l’aide d’un applicatif de suivi de réinsertion, « ASR »).

23

Ces trois processus métiers bénéficient d’une gestion intégrée informatisée, par le biais d’une infrastructure technologique (Data center) implémentée par la fonction « système d’information » de l’UEPN – DDR, aidant à la centralisation, synchronisation et traitement des données issues des activités d’identification, de paiement et de réinsertion. Quant aux autres processus de gestion liée aux fonctions horizontales du programme (administrative, financière, budgétaire et logistique), ils sont opérationnalisés au sein de l’infrastructure technologique grâce aux applicatifs et outils standards tels que le Tom pro, l’Office intégrale de Microsoft, l’ISA Server, le Rancid, le Request Tracker / Trac, l’IPcop, etc. tournant sous environnement Microsoft et/ou Linux. Le département MIS : Management Information System, qui sert de maître d’œuvre technologique de l’UEPN – DDR, assure la gestion de cette fonction « système d’information » mis en place et intègre trois de cinq rôles de Guy Paré et de Guillemette Manon (2005) sur la fonction TI, à savoir la fourniture des systèmes, la conception d’infrastructure technologique et la coordination de projets TI. Les ressources faisant partie de cette fonction organisent ses activités avec l’aide de deux partenaires clés : BIO-ID Technologies SA (impartiteur proposé par les bailleurs de fonds pour son expertise comme intégrateur de la technologie iris dans les différentes solutions informatiques mises en place par le département MIS) et CELPAY RDC Inc. (partenaire proposé par les bailleurs de fonds pour la paie des ex – combattants démobilisés).

Ø Règles clés de gestion en rapport avec le processus de paiement Lors de la première phase du programme DDR (2004 – 2007), le processus de paiement au niveau d’un site d’enregistrement ou de paiement reprenait les entités et/ou acteurs suivants : Bio – ID Technologies (Gestionnaire de base de données et Opérateurs de saisie), CELPAY (Agents payeurs) et UEPN – DDR (Superviseur). Ce processus a été modélisé avec l’aide d’un diagramme d’activité. Les règles clés de gestion sur ce processus de paiement renfermaient les bases suivantes :

- « Un ex combattant ayant choisi la démobilisation, après son identification biométrique avec capture iris dans un centre d’orientation, reçoit en numéraire une et une seule fois un montant de 110 $ USD » ; et

- « Après son installation effective dans la communauté qu’il aurait choisi, l’ex combattant démobilisé va être accompagné dans sa réinsertion par l’octroi de 300 $ USD en douze tranches de 25 $ USD et de certaines autres bénéfices (formation, outils, etc.) ».

La formalisation de ces règles clés de gestion sur le processus avait produit des procédures (cas d’utilisation) aidant à son opérationnalisation effective. Nous citons ici la constitution et la validation de listes de paiements, générées à partir données biométriques d’identification synchronisées au niveau du Datacenter, la transmission de ces listes par centre d’orientation à l’agent payeur, la présentation de la carte de démobilisation sur le site d’identification ou de réinsertion par le démobilisé pour être payé, les réponses aux questions types pour s’assurer de l’authenticité du démobilisé bénéficiaire, etc. La paie aux ex – combattants de ces Indemnités Transitoires de Subsistance, dits « ITS », est donc assurée avec l’aide d’un applicatif de CELPAY via mobile.

Ø Contexte de développement et exigences textuelles de « Payment Manager » A la fin de la première phase du programme, suite aux critiques du maître d’ouvrage sur la non performance de l’applicatif de paiement de CELPAY (manque de couverture téléphonique dans certains coins du pays, etc.) mais aussi les recommandations de ses partenaires et l’audit d’Ernst &

24

Young France de 2006, en rapport avec le dysfonctionnement de l’applicatif de CELPAY dans l’environnement congolais causant un léger écart avec la cible définie dans le document initial du programme, un besoin d’amélioration du processus de paiement était est né. En tant que Spécialiste MIS et chef de projet d’intégration informatique, (« IDENT – ITS » : identification, paiement et réinsertion), de l’UEPN – DDR, nous avons soumis, ensemble avec les chargés de projet de l’impartiteur (Bio – ID Technologies SA) et de l’agent payeur (CELPAY RDC Inc.), sur base de notre retour d’expérience dans cette première phase du PNDDR, une proposition en rapport avec les nouvelles procédures envisagées et les besoins visant l’amélioration de l’ensemble du processus de paiement. Après la décision du maître d’ouvrage, les règles clés de gestion devenaient alors :

- le paiement de 140 $ USD à l’ex – combattant lors de la démobilisation, au lieu de 110 $ USD ;

- le paiement de 300 $ USD d’accompagnement en deux tranches de 150 $ USD sur une période de 2 mois, au lieu de 25 USD sur une période de 12 mois. La première tranche de paiement de 150 $ USD est payée à l’ex combattant démobilisé un mois après le paiement de 140 $ USD, et après son enregistrement et son référencement dans une de nos agences de liaison en provinces. La deuxième tranche 2 mois après

Dans cette redéfinition de l’ensemble du processus de paiement des ex – combattants démobilisés, il est donc question :

- de disposer un système logiciel qui va permettre au PNDDR de pouvoir garantir le paiement des ex – combattants démobilisés sans tentative de fraude ;

- que ce système logiciel de paiement, y compris les équipements qui l’accompagnent, soit opérationnel et capable de satisfaire aux différentes règles de gestion établies par le PNDDR ; et

- que les règles définies le long du processus de développement soient respectées. En effet, ce système logiciel, nommé « Payment Manager », remplace donc l’applicatif de paiement électronique avec mobile de CELPAY RDC Inc. Il est développé par l’impartiteur BIO – ID Technologies SA et la fonction TI de l’UEPN – DDR sous Visual Basic.Net 2005, opérationnalisé sous Microsoft XP Professionnel /SP2 que ça soit en simulation ou en production, et intègre un module de contrôle et/ou d’authentification par capture et/ou contrôle iris. Son but principal reste le paiement des ex combattants démobilisés dans le cadre du PNDDR en RD Congo. Il est utilisé par l’entreprise CELPAY RDC Inc., qui a reçu mandat des bailleurs, depuis la première phase du PNDDR, de payer les ex – combattants éligibles. Son architecture logicielle est composée des fichiers de modules, modules de classes, fonctions, macros intégrés (threads ou processus), tables, requêtes, formulaires (voir figure 5). Le Crystal Report, avec l’aide de ses composants, matérialise son côté rapportage. Notons que certaines lignes codées, pour ce système logiciel, sont des anciennes briques de code conservées dans les bibliothèques de développement de BIO ID et de MIS CONADER.

Fig.5. Architecture logicielle de « Payment Manager ».

Laptop or desktop

Data User Interface

Remote Object

Remote Business Object

Business Object handler

Remote Scan Object

Scan Object handler

25

Ici, l’agent payeur (agent de CELPAY), qui sera l’utilisateur de ce système, devra disposer de l’argent dans sa caisse avant de démarrer une campagne donnée de paiement (il devra au moins avoir un montant pour une journée de paie selon le cas). Il ne procède au paiement de l’ex – combattant démobilisé que via le système. Si sa caisse devient vide, la campagne de paiement amorcée devra être reportée. Un paiement effectué par l’utilisateur du système et confirmé dans ce dernier n’est plus révocable. En plus, tout agent payeur impliqué dans le processus de paiement devra être inscrit comme utilisateur dans le système, par l’installateur du système (Agent BIO – ID ou MIS), par une capture de son iris puis formé à son utilisation. Les enregistrements (données biographiques et iris) de démobilisés sensés être payés, qui se trouveraient dans la base de données de l’applicatif d’identification « Ident – Congo » devraient se retrouver dans le système de paiement, soit par synchronisation en temps réel avec le système d’identification au niveau du site d’identification ou soit par importation au niveau de site de paiement se trouvant au sein de la communauté de réinsertion. Les enregistrements d’un agent payeur inscrit dans le système par l’installateur sont synchronisés dans tous les systèmes disponibles et opérationnels pendant les campagnes de paiement. L’installateur du système, qui inscrit et donne accès aux autres utilisateurs (ici l’agent payeur) dans le système, est inscrit lui – même lors de son installation. A chaque fois qu’un agent inscrit dans le système devra le manipuler, une authentification avec son iris sera requise. Toutefois, en cas de problème d’iris survenant lors de son authentification, un mode dégradé sera disponible (cf. plan de contingence). Il s’agirait en effet à l’utilisateur d’accéder et/ou de s’authentifier via l’IDcode généré lors de son inscription dans le système par l’administrateur. L’installateur a, lui aussi, son IDcode, généré lors de l’installation et de son inscription comme super utilisateur dans le système. Quant à l’ex – combattant démobilisé, qui devra percevoir son ITS, son IDcode est repris sur la carte imprimée puis lui délivrée lors de son enregistrement dans le système « Ident – Congo » au niveau du site de son identification. Il devra répondre au besoin à des questions de précision posées par l’agent payeur mais aussi signer toujours un document attestant le paiement (140$ ou 150$) qu’il a reçu. Certains éléments repris ci – dessus constituent les bases servant pour identifier les acteurs clés et leurs différentes interactions dans le système à développer. Ils ont été en partie repris, sous forme d’une modélisation détaillée dans la phase conceptuelle avec l’aide des diagrammes UML de contexte, de cas d’utilisation, de séquence, de classes et d’objets non repris ici schématiquement.32 Toutefois, ci – dessous, nous présentons les éléments clés de notre diagramme d’utilisation :

- Pour l’administrateur (agent installateur), (1) installer le système ; (2) s’inscrire et inscrire les autres utilisateurs du système tout en définissant leurs profils et enfin (3) maintenir en état le système ;

- Pour l’utilisateur (agent payeur), (1) démarrer ou ouvrir le système ; (2) s’authentifier avec son iris ou avec la saisie de son IDcode dans le système pour procéder aux opérations de paiement ; (3) mettre à jour ou synchroniser les données des ex – combattants démobilisés provenant de l’applicatif d’identification (Ident – Congo) et/ou importer à partir du site ftp (Internet) les différentes données cryptées de paiements réalisés venant des autres sites ; (4) faire authentifier dans le système le bénéficiaire, par contrôle iris ou par saisie de l’IDcode, avant son paiement ; (5) consulter ou rechercher dans le système les informations biographiques et de paiement du démobilisé ; (6) effectuer ou procéder au paiement du démobilisé dans le système ;

32 Nous avons intentionnellement refusé de présenter les différents diagrammes UML car notre modèle de tests se situe au niveau supérieur, c.à.d. au niveau de tests système et de tests de validation. Le modèle d’exigences à élaborer, qui se limitent à l’amélioration de cas de tests fonctionnels, est directement à mesure de matérialiser et/ou de générer les différents cas de tests systèmes, qui constitue notre modèle de tests.

26

(7) imprimer dans le système le reçu de paiement du démobilisé qui devra sortir en en trois exemplaires mais aussi les rapports journaliers/hebdomadaires/mensuels de paiement ; (8) exporter via ftp (Internet) les données journalières/hebdomadaires/mensuelles de paiement vers le Data center pour consolidation et rapprochement et (9) enfin arrêter ou fermer le système ;

- Pour le bénéficiaire (démobilisé), (1) faire valider son identité avant tout paiement par authentification (contrôle de son iris) dans le système.

Ces opérations, à réaliser par les trois acteurs identifiés (agent payeur, installateur et démobilisé) sur le système à développer et/ou développé, sont des cas d’utilisation qui ont été décrites nominalement sous forme de scénarios et d’enchainements puis détaillées dans des diagrammes de séquence liés (diagramme de séquence système de cas d’utilisation « inscription des utilisateurs », diagramme de séquence système de cas d’utilisation « authentification des utilisateurs ou des ex –combattants », etc.) non repris aussi schématiquement ici. Ces cas d’utilisation, après raffinement, génèrent les exigences génériques et spécifiques ci – dessous : Exigences génériques du système sous test

- [EX-G-01] : le logiciel à développer et/ou développé doit posséder une série d’interfaces génériques (menus, message d’erreur, etc.) en français et en anglais;

- [EX-G-02] : l’intégration des données provenant d’un module logiciel vers un autre module, à l’intérieur du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier source ou de destination grâce à un ODBC disponible ;

- [EX-G-03] : le menu général du logiciel à développer et/ou développé devra permettre aux utilisateurs de naviguer, sous un profil défini, aux différentes sections ou sous – menus de l’applicatif ;

- [EX-G-04] : les composants logiciels utilisés doivent être cités dans la rubrique « A propos », ainsi que les informations de la version associée ;

- [EX-G-05] : le logiciel à développer et/ou développé doit pouvoir être porté sur une version à jour d’un système d’exploitation similaire à celui de son développement (Windows XP SP2 vers Windows XP SP3 ou vers une version postérieure, Vista par exemple) sans changer la procédure d’installation ni écrire dans le registre du système d’exploitation où le logiciel est porté ;

- [EX-G-06] : le logiciel à développer et/ou développé doit être fourni sous forme d’un fichier compressé exécutable qu’on peut lancer directement. L’on devra avoir un et un seul fichier exécutable ;

- [EX-G-07] : le logiciel à développer et/ou développé doit disposer des interfaces conviviales pour sa manipulation ;

- [EX-G-18] : le logiciel à développer et/ou développé doit se lancer en moins de 3 secondes et doivent fonctionner avec les configurations matérielles acceptées.

Exigences spécifiques du système sous test

- [EX-S-01] : seul l’installateur peut enregistrer les utilisateurs et définir leurs profils ; - [EX-S-02] : l’accès au logiciel à développer et/ou développé, suivant les règles métiers, devra se faire

par authentification de l’utilisateur via son iris en mode normal ou via la saisie de son IDcode en mode dégradé ;

- [EX-S-03] : le logiciel à développer et/ou développé doit posséder un menu « Paramètres ou Administration » permettant à l’administrateur de paramétrer ou de configurer les différents profils et accès administratifs des utilisateurs, les chemins d’accès à l’information, la gestion des accès et des habilitations et les mécanismes d’authentification ;

- [EX-S-04] : le logiciel à développer et/ou développé doit posséder un menu « Aide », avec une rubrique « à propos » dans laquelle apparaît le nom du logiciel, le numéro de la version, l’année de sa distribution, les noms des entités associées au développement et d’autres éléments de copyright. Il doit aussi, en outre, posséder la rubrique documentation utilisateur au sein du même menu « Aide »;

- [EX-S-05] : tous les utilisateurs enregistrés dans le logiciel à développer et/ou développé peuvent effectuer des opérations et/ou des actions existantes suivant les profils et les règles de gestion définis (paiement de 140$, de 150$X2, impression de reçu de paiement, synchronisation, etc.). Toutefois, ces dernières devraient être tracées en indiquant quel utilisateur a effectué telle ou telle autre action?;

27

- [EX-S-06] : le logiciel à développer et/ou développé doit être à mesure de procéder au paiement d’un démobilisé, en mode normal ou en mode dégradé, selon les règles définies ;

- [EX-S-07] : le logiciel à développer et/ou développé doit être à mesure d’imprimer les rapports sur les opérations de paiement et/ou sur les actions effectuées d’une manière chronologique. Il s’agirait des détails sur les opérations et/ou les actions de paiement journalières, mensuelles, trimestrielles, etc. effectuées sur le logiciel. L’on pourra toutefois l’étendre à des impressions statistiques sous forme graphique ou des tableaux;

- [EX-S-08] : le logiciel à développer et/ou développé devra être à mesure de trouver et d’imprimer les différents rapports des opérations et/ou des actions de paiements antérieurs qui ont été stockées dans sa base de données ;

- [EX-S-09] : le logiciel à développer et/ou développé devra être à mesure d’exporter et d’importer les fichiers de la base de données au format ci – après défini par l’utilisateur (.txt, .csv, .xls, .mdb, .ldf et .pdf) ;

- [EX-S-10] : Le logiciel à développer et/ou développé doit être à mesure de créer, de sauvegarder et d’imprimer une activité journalière de paiement à enregistrement vide créée par l’utilisateur ;

- [EX-S-11] : le logiciel à développer et/ou développé devra être à mesure de prendre en charge les différents périphériques servant à son optimisation (lecteur iris, imprimante, etc.) ;

- [EX-S-12] : le logiciel à développer et/ou développé devra être à mesure de sauvegarder automatiquement l’enregistrement en cours, en cas de d’arrêt brusque de l’applicatif (coupure du courant, plantage système, etc.) ou à défaut, offrir la possibilité de pouvoir récupérer tous les enregistrements sauvegardés automatiquement avant et/ou à l’arrêt brusque de l’applicatif.

- [EX-S-13] : le logiciel à développer et/ou développé devra être à mesure de synchroniser automatiquement les enregistrements et/ou les données, provenant d’un module applicatif ouvert vers son module applicatif intégré ouvert ou non. Toutefois, lors d’une synchronisation, si un champ est manquant, incohérent ou incorrect, un message d’erreur est affiché à l’écran ;

- [EX-S-14] : le logiciel à développer et/ou développé devra, lors de la fermeture, enregistrer et arrêter toutes les opérations et/ou actions effectuées lors d’un processus activé ou ouvert.

Ces exigences génériques ou spécifiques, à implémenter dans le cadre de notre système sous test, sont considérées comme notre « modèle d’exigences de tests » (CIM). Elles sont donc en lien direct (traçabilité) avec les autres modèles (PIM et PSM) qui ont suivis dans le cycle de développement (les différents diagrammes de conception) et génèrent les différents cas de tests ci – dessous s’accompagnent des résultats attendus. C’est donc notre modèle de tests système et de validation, qui a trois niveaux. Le premier niveau reprend les exigences génériques ou spécifiques de tests. Le second niveau aligne les cas de tests tandis que le troisième reprend les résultats attendus (oracles). Ces différents cas et résultats de tests concernent tous les tests système et les tests d’acceptation par la clientèle (Users Acceptance Tests, UAT). Ainsi, les caractéristiques et les modalités qui sont fixées sont celles de recette fonctionnelle et d’exploitabilité mais aussi de performance, de sécurité, de maintenance, d’installation, de compatibilité et de gestion des exceptions (mode dégradé). « A titre indicatif, nous illustrons seulement une série d’éléments de notre modèle de tests. Il s’agit des éléments pour les tests de recette fonctionnelle et d’exploitabilité ». Identificateur FONCTIONNEL ET EXPLOITABLE Technique de tests Tests de système et d’acceptation (boite noire)

Exigences de tests retenues [EX-S-02] L’accès au logiciel à développer et/ou développé, suivant les règles métiers, devra se faire par

authentification de l’utilisateur via son iris en mode normal ou via la saisie de son IDcode en mode dégradé

[EX-G-02] L’intégration des données provenant d’un module logiciel vers un autre module, à l’intérieur du logiciel, devra pouvoir se faire sans recompilation, uniquement en indiquant le fichier source ou de destination grâce à un ODBC disponible

[EX-S-03] Le logiciel à développer et/ou développé doit posséder un menu « Administration » permettant à l’administrateur de paramétrer ou de configurer les différents profils et accès administratifs des utilisateurs, les chemins d’accès à l’information, la gestion des accès et des habilitations et les mécanismes d’authentification

[EX-G-03] Le menu général du logiciel à développer et/ou développé devra permettre aux utilisateurs

28

de naviguer, sous un profil défini, aux différentes sections ou sous – menus de l’applicatif

[EX-S-04] Le logiciel à développer et/ou développé doit posséder un menu « Aide », avec une rubrique « à propos » dans laquelle apparaît le nom du logiciel, le numéro de la version, l’année de sa distribution, les noms des entités associées au développement et d’autres éléments de copyright. Il doit aussi, en outre, posséder la rubrique documentation utilisateur au sein du même menu « Aide »

[EX-S-05] Tous les utilisateurs enregistrés dans le logiciel à développer et/ou développé peuvent effectuer des opérations et/ou des actions existantes suivant les profils et les règles de gestion définis (paiement de 140$, de 150$X2, impression de reçu de paiement, synchronisation, etc.). Toutefois, ces dernières devraient être tracées en indiquant quel utilisateur a effectué telle ou telle autre action?

[EX-S-06] Le logiciel à développer et/ou développé doit être à mesure de procéder au paiement d’un démobilisé, en mode normal ou en mode dégradé, selon les règles définies

[EX-S-07] Le logiciel à développer et/ou développé doit être à mesure d’imprimer les rapports sur les opérations de paiement et/ou sur les actions effectuées d’une manière chronologique. Il s’agirait des détails sur les opérations et/ou les actions de paiement journalières, mensuelles, trimestrielles, etc. effectuées sur le logiciel. L’on pourra toutefois l’étendre à des impressions statistiques sous forme graphique ou des tableaux

[EX-S-08] Le logiciel à développer et/ou développé devra être à mesure de trouver des enregistrements et d’imprimer les différents rapports des opérations et/ou des actions de paiements antérieurs qui ont été stockées dans sa base de données

[EX-S-09] Le logiciel à développer et/ou développé devra être à mesure d’exporter et d’importer les fichiers de la base de données au format ci – après défini par l’utilisateur (.txt, .csv, .xls, .mdb, .ldf et .pdf)

[EX-S-10] Le logiciel à développer et/ou développé doit être à mesure de créer, de sauvegarder et d’imprimer une activité journalière de paiement à enregistrement vide créée par l’utilisateur

[EX-S-11] Le logiciel à développer et/ou développé devra être à mesure de prendre en charge les différents périphériques servant à son optimisation (lecteur iris, imprimante, etc.)

[EX-S-12] Le logiciel à développer et/ou développé devra être à mesure de sauvegarder automatiquement l’enregistrement en cours, en cas de d’arrêt brusque de l’applicatif (coupure du courant, plantage système, etc.) ou à défaut, offrir la possibilité de pouvoir récupérer tous les enregistrements sauvegardés automatiquement avant et/ou à l’arrêt brusque de l’applicatif

[EX-S-13] Le logiciel à développer et/ou développé devra être à mesure de synchroniser automatiquement les enregistrements et/ou les données, provenant d’un module applicatif ouvert vers son module applicatif intégré ouvert ou non. Toutefois, lors d’une synchronisation, si un champ est manquant, incohérent ou incorrect, un message d’erreur est affiché à l’écran

[EX-S-14] Le logiciel à développer et/ou développé devra, lors de la fermeture, enregistrer et arrêter toutes les opérations et/ou actions effectuées lors d’un processus activé ou ouvert

Informations sous tests Démarche Cas de tests [(CT-F-01)→(EX-S-02)] Fenêtre de connexion: Cliquez sur le bouton « avec iris ». Une

fenêtre de capture iris vous permettant de vous faire authentifier va apparaître. En bas du bouton « avec iris », nous avons le bouton « help » qui vous permet d’afficher la fenêtre « aide » qui a à son sein l’onglet « à propos », « contact » et « manuel utilisateur ». [(CT-F-02)→(EX-S-02)] Fenêtre de capture iris: En cliquant sur capturer l’œil droit et/ou sur capturer l’œil gauche, si votre iris est déjà stocké dans la base de données iris, vous devez accéder au menu général. [(CT-F-03)→(EX-S-03)] Fenêtre d’inscription de l’utilisateur: Si le système est lancé pour la première fois, le premier utilisateur qui fait capturer son iris sera enregistré comme administrateur. Dans ce cas, il aura lui l’obligation d’inscrire plus tard les autres utilisateurs du système (les agents payeurs) puis enregistrer leurs profils. Ici, la fenêtre capture apparaît et après capture des iris droit et gauche, on clic sur approuver puis continuer. [(CT-F-04)→(EX-G-03)] Menu général ou principal: Elle apparaît, cette fenêtre, lorsque l’utilisateur ou l’administrateur se connecte sur le système en cliquant sur « avec iris » et se fait par la suite authentifier via son iris (mode normal) ou via son IDcode (dans le cas

29

d’une connexion en mode dégradé). [(CT-F-05)→(EX-S-02)→(EX-G-03)] Menu général ou principal: En faisant un tour d’horizon dans cette fenêtre, vous trouverez l’existence d’une liste déroulante de choix de langues en français et/ou en anglais. La langue par défaut est le français. Le choix de l’anglais changerait automatiquement les interfaces du logiciel en anglais. [(CT-F-06)→(EX-S-08)] Fenêtre rechercher: Cette fenêtre vous permet de trouver tout enregistrement de paiement stocker dans le système. C’est aussi au niveau de cette fenêtre qu’on procède à l’authentification de l’ex – combattant bénéficiaire par iris ou via la saisie de son IDcode. [(CT-F-07)→(EX-S-05)→(EX-S-06)→( EX-S-07)→(EX-S-10)] Fenêtre détails de paiements: Saisissez et/ou choisissez les informations sur un paiement (1ière tranche, 2ième tranche ou 3ième tranche) puis validez avec le bouton « effectuer le paiement » d’un démobilisé. Le reçu de paiement devra apparaître en visualisation et vous pouvez cliquez sur imprimer. Clôturez l’opération afin de permettre le paiement suivant. [(CT-F-08)→(EX-S-09)] Fenêtre d’exportation: Cliquez sur le bouton Exporter, et sur la fenêtre « exporter » qui va apparaître, sélectionnez « exportation quotidienne » ou « exporte par date » puis cliquez sur « exporter » et en plus sur « exporter pour CELPAY ». [(CT-F-09)→(EX-G-02)→(EX-S-09)→(EX-S-15)] Fenêtre d’importation de données d’identification : Cliquez sur le bouton Importer et sur la fenêtre « importer » qui va apparaître, sélectionnez « importer les données du site » puis cliquez sur « importer ». Le dernier fichier crypté d’identification à date, créé à l'aide de l’applicatif « Ident – Congo » puis déposé sur le site FTP UEPN – DDR, va être importé dans le système de paiement. A ce niveau, une autre opération de synchronisation des données d’identification dans le système de paiement a lieu automatiquement dans le cas où celui – ci est connecté via un réseau LAN avec le système d’identification dans un site d’enregistrement. [(CT-F-10)→(EX-S-09)] Fenêtre d’importation de données de paiement : Cliquez sur le bouton Importer et sur la fenêtre « importer » qui va apparaître, sélectionnez « importer les données de paiement » puis cliquez sur « importer ». Le dernier fichier crypté de paiement à date, créé à l'aide de l’applicatif « Payment Manager » puis déposé sur le site FTP UEPN – DDR, va être importé dans le système de paiement. [(CT-F-11)→(EX-S-05)→(EX-S-07)→(EX-S-08)→(EX-S-10)] Fenêtre de rapports: Cliquez sur le bouton rapports. Sélectionnez « rapport quotidien » ou une période donnée sur la liste déroulante et cliquez sur Afficher.

Résultats de cas de tests

[RCT-F-01]→[(CT-F-01)→(EX-S-02)] Fenêtre de connexion: Une fenêtre de connexion devra apparaître et vous donnant la possibilité de procéder via le bouton « avec iris » à votre authentification

Oui, avec succès

[RCT-F-02]→[(CT-F-01)→(EX-S-02)] Fenêtre de capture iris: Une fenêtre de capture iris ou saisie de l’IDcode, vous permettant de vous faire authentifier, va apparaître.

Oui, avec succès

[RCT-F-03]→[(CT-F-02)→(EX-S-02)]→[(CT-F-03)→(EX-S-03)] Fenêtre d’inscription de l’utilisateur: La fenêtre « Enregistrement de l’administrateur ou de l’utilisateur » devra apparaître. A ce niveau, on procédera à l’enregistrement de l’iris gauche et de l’iris droit de l’utilisateur. Après validation, un Idcode devra être généré puis lié à l’utilisateur inscrit. L’administrateur devra ajouter d’autres informations le concernant (nom, prénom, date de naissance, etc.). La procédure se termine avec le message « Administrateur ou utilisateur inscrit avec succès ».

Oui, avec succès. Prière de modifier « administrateur » par « administration ».

[RCT-F-04]→[(CT-F-04)→(EX-G-03)]→[(CT-F-05)→(EX-G-03)] Menu général ou principal: Cette fenêtre apparaît et devra vous permettre d’accéder aux différents sous – menus du système, à savoir : administration, paiement, rechercher, importer, exporter, rapport et quitter. Ici, seul l’administrateur ou l’utilisateur inscrit qui devra voir ces sous menus activés. Il y a aussi l’option de se déconnecter du système au milieu de la fenêtre.

Oui, avec succès

[RCT-F-05]→[(CT-F-06)→(EX-S-08)] Fenêtre rechercher: Cette fenêtre apparaît et devra vous permettre de trouver tout

Oui, avec succès

30

enregistrement de paiement stocker dans le système. L’enregistrement retrouvé affiche aussi sur une carte virtuelle l’image du démobilisé, avec d’autres informations utiles. La recherche est multicritère (IDcode, nom, prenom, et date d’enregistrement). [RCT-F-06]→[(CT-F-07)→(EX-S-05)→(EX-S-06)→(EX-S-07)→(EX-S-10)] Fenêtre détails de paiements: Les détails sur les dates et les montants reçus et restants d’un démobilisé mais aussi sur les opérateurs ayant effectué ces paiements seront affichés. Ensuite, après avoir cliquer sur « effectuer le paiement », une fenêtre affichant le reçu de paiement en trois exemplaires sur un format A4 devra s’afficher avec possibilité d’impression ou d’enregistrement dans les formats .pdf, .word, .xls et .jpeg.

Oui, avec succès

[RCT-F-07]→[(CT-F-08)→(EX-S-09)] Fenêtre d’exportation : deux fichiers avec de données exportées seront créés et cryptés. L’un pour CELPAY et l’autre pour UEPN – DDR et BIO – ID. Ils devront par la suite être déposés sur le site FTP UEPN – DDR.

Oui, avec succès

[RCT-F-08]→[(CT-F-09)→(EX-G-02)→(EX-S-09)→(EX-S-15)] Fenêtre d’importation de données d’identification: Les données seront importées. Procéder à la recherche du dernier IDcode existant dans le système pour s’assurer que les autres données d’identification sont importées.

Oui, avec succès

[RCT-F-09]→[(CT-F-10)→(EX-S-09)] Fenêtre d’importation de données de paiement: Les données seront importées. Procéder à la recherche du dernier IDcode existant dans le système pour s’assurer que les autres données d’identification sont importées.

[RCT-F-10]→[(CT-F-11)→(EX-S-05)→(EX-S-07)→(EX-S-08)→(EX-S-10)] Fenêtre rapports: Une fenêtre affichant le rapport devra s’afficher avec possibilité d’impression ou d’enregistrement dans les formats .pdf, .word, .xls et .jpeg.

Oui, avec succès

Niveau de complétude Atteindre au moins les 100% d’exigences des cas de tests retenus sur l’ensemble de critères d’installation de l’applicatif

Succès /échec Voir commentaires sur les résultats de tests d’installation

b) Résultats et discussion sur l’ébauche du modèle (analyse du modèle en mettant un avis sur le logiciel)

Les résultats de notre contribution permettent de mieux comprendre la démarche d’élaboration d’un modèle de tests de vérification et de validation mais aussi de faciliter son déploiement. Ils ont été matérialisés en se servant des référentiels normatifs en la matière (type de gouvernance à mettre en place, respect de meilleures pratiques et mise en œuvre d’une gestion de cycle de vie du logiciel dans laquelle les tests logiciels constituent l’élément visible pour la qualité) et des principes généraux de l’IDM suivant l’approche MDA (méta – modélisation et transformation de modèles). Avec l’aide de la modélisation UML, comme profil du méta – modèle, et sans y ajouter de façon claire les contraintes OCL, nous avons pu élaborer un modèle d’exigences fiable (CIM) qui nous a permis par la suite de rédiger manuellement des cas et des résultats des tests aboutissant au modèle complet de tests système et de validation. Ce dernier, qui se résume dans notre cas à des diagrammes de cas d’utilisation, d’activité et de séquence, a matérialisé l’exécution de tests système et la validation du logiciel « Payment Manager ». En effet, la méthodologie UML a été choisi par nous à la place des autres méta-modèles (MOF, XMI, OCL) car elle a permis de décrire séparément les modèles pour les différentes phases du cycle de développement d’un logiciel (Bézevin et Blanc Xavier, 2002). C’est une approche qui se veut aujourd’hui généraliste (Combemale, 2008). Ainsi, sans détailler sa sémantique d’exécution, grâce au modèle d’exigences (CIM) généré à partir des exigences textuelles (processus et règles métiers pour le paiement, besoins des utilisateurs, etc.), notre ébauche de modèle de tests qui ne se situe qu’au niveau supérieur (tests système et de validation) a concrétisé manuellement les cas de tests

31

abstraits générés par des tests concrets sur des données réelles ou de tests (erronées). Les résultats obtenus sont voire sans équivoque car ils démontrent la traçabilité les cas de tests générés avec d’exigences techniques produites mais aussi avec les résultats abstraits de tests. Quelques résultats concrets de cette suite de tests sont présentés dans les figures 6, 7, 8, 9 et 10 ci - dessous.

Fig.6. [RCT-F-01]→[(CT-F-01)→(EX-S-02)] Fenêtre de connexion, avec iris, dans le « Payment Manager ». Nous remarquons aussi en haut le choix de langues et du site de paiement. Les exigences et cas de tests liés ici sont [EX-S-02] et [(CT-F-01)→(EX-S-02)].

Fig.7. [RCT-F-04]→[(CT-F-04)→(EX-G-03)]→[(CT-F-05)→(EX-G-03)] Menu général ou principal. Ce dernier permet à l’utilisateur de naviguer sur l’ensemble des ressources du système. Il est en lien avec les exigences et les cas de tests ci - après [EX-G-03], [(CT-F-04)→(EX-G-03)] et [(CT-F-

05)→(EX-S-02)→(EX-G-03)]

32

Fig.8. [RCT-F-02]→[(CT-F-02)→(EX-S-02)]→[(CT-F-03)→(EX-S-03)] Fenêtre d’inscription de l’utilisateur. Ce dernier dépend de l’écran « Capture des iris ». Ici, l’on observe l’enregistrement de l’œil gauche de l’administrateur. Cette opération est identique pour l’inscription des autres utilisateurs du

système. Il est associé aux exigences et cas de tests suivants [EX-S-03] et [(CT-F-03)→(EX-S-03)].

Fig.9. [RCT-F-06]→[(CT-F-07)→(EX-S-05)→(EX-S-06)→(EX-S-07)→(EX-S-10)] Fenêtre détails de paiements d’un ex – combattant (TEST GUY TEST BANDA dans notre cas). Ici, l’on voit aussi le nom de l’utilisateur effectuant la transaction est rattaché en lien automatique (TESTER) et les bénéfices déjà obtenus. Les exigences et cas de tests liés ici sont [EX-S-05], [EX-S-06], [EX-S-07], [EX-S-10] et [(CT-F-07)→(EX-S-05)→(EX-S-

06)→( EX-S-07)→(EX-S-10)].

Fig.10. [RCT-F-05]→[(CT-F-06)→(EX-S-08)] Fenêtre rechercher. Ici, la recherche d’un ex – combattant est multicritère. Elle peut être effectuée soit par iris, IDcode, Nom, etc. Cette opération permet, une fois l’enregistrement trouvé, de pouvoir accéder au détail des informations sur le paiement de l’ex –

33

combattant et/ou procéder à un nouveau paiement (2ième ou 3ième tranche). Les exigences, cas et résultats de tests liés ici sont [EX-S-08] et [(CT-F-06)→(EX-S-08)].

Ici, les méthodes ou techniques de tests décidées étaient toutes dynamiques et se sont exécutées suivant l’approche boite noire, à partir des directives pratiques ci - après :

- les jeux de données d’entrée à appliquer sont décrits sur les valeurs critiques de paiement qui sont valides ou erronées ;

- les cas de tests (scénarios) constituent le mode opératoire retenu ; - la description les comportements attendus du programme ou du logiciel sont décrits

sur les types et les valeurs de sortie ; et - les critères d’acceptation des résultats de tests et de clôture sont basés sur la

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

34

contribution, jette les bases d’un démarrage de pratique de tests systématiques par les professionnels TI congolais, même si plusieurs limites sont mentionnées et/ou pourront être mentionnées. Toutefois, il serait important de souligner la nécessité d’effectuer une validation plus complète de cette ébauche en ajoutant les cas de tests de niveau inférieur de tests qui ont matérialisés, dans le cadre de notre projet, les tests unitaires et d’intégration. La méthodologie UML, qui possède une syntaxe très proche de la syntaxe de certains langages puis utilisée pour les tests de niveau supérieur dans cette contribution, devra permettre de dériver les tests de type boîte blanche et renforcer les tests systèmes généralement produits. Des travaux futurs sont donc nécessaires afin de pouvoir formaliser ces techniques et pouvoir ainsi valider et vérifier les transformations présentées et/ou qui pourront être présentées dans d’autres contributions afin de pouvoir produire, avec des technologies MBT et des outils d’automatisation de tests par exemple, des cas de tests généralement automatisés et confiés à des algorithmes de génération solides permettant de s’affranchir de l’erreur humaine et d’obtenir des résultats de tests de meilleure qualité. IV. CONCLUSION Cette contribution tente de se greffer sur les travaux récents portant sur la génération de tests dans une approche d’ingénierie dirigée par les modèles. Pour ce faire, nous avons été dans l’obligation de proposer une ébauche de modèle de tests dont la mise à l’épreuve, sur le plan pratique, pourra s’adapter et s’étendre à un plus grand nombre de projets cherchant à dégager les bénéfices d’usage des bonnes pratiques de développement logiciels et, sur le plan théorique, va la permettre de continuer de s’affiner sur la base des travaux s’intéressant à l’évolution des outils de tests car la problématique générale de tests logiciels reste encore largement ouverte. D’ailleurs, pour la RD Congo, lors d’une discussion en atelier avec quelques membres de BSD Congo, nous avons conclu que si les activités de vérification et de validation de façon systématique, au niveau d’un projet de développement informatique, reste un défi majeur, alors qu’elles constituent une étape critique dans la pratique de développement logiciels, c’est parce qu’elles semblent ne pas avoir été vulgarisées par ceux qui sont sensées apporter de l’aide à la société. Ainsi, l'ensemble des éléments présentés, intégrés dans une démarche simplifiée, suggère aux professionnels TI congolais de mieux adapter leur façon faire les tests logiciels et/ou de procéder aux activités de tests dans des projets de développement qu’ils ont à diriger et, aux universitaires, de faire évoluer leurs enseignements et leur recherche dans la quête des meilleures pratiques menant au succès de développements logiciels dans notre pays. Confiant de la communauté « BSD Congo », qui est déjà rodée avec la modélisation UML et avec certaines bonnes pratiques de développements logiciels, nous pensons qu’elle pourra aussi s’impliquer dans cette vision.

BIBLIOGRAPHIE I.OUVRAGES

- BERSINI Hugues, La programmation orientée objet, 2ième tirage, Eyrolles, Paris, 2009. - BLANC Xavier, avec la contribution de SALVATORI Olivier, MDA en action : ingénierie

logicielle guidée par les modèles, collection architecte logiciel, EYROLLES, 2005. - CHARTIER – KASTLER Cyrille, Précis de conduite de projet informatique, Editions

d’organisation, Paris, 1997. - GAUDEL Marie – Claude et Ali, Précis de génie logiciel, Préface de LEMOINE Michel,

Edition Masson, Collection Enseignement de l’informatique, Paris, 1996. - GUSTAFSON David, Génie logiciel, Dunod, Série Schaum’s – EdiScience, Paris, 2003. - IVINZA LEPAPA A. C., Analyse de l’introduction de l’EDI dans les entreprises

congolaises : Une contribution à l’impact organisationnel des Technologies de l’Information, Tome I: concepts de base et cadre d'analyse théorique, Editions universitaires européennes, Saarbrüken - Germany, 2010.

35

- LE MOIGNE Jean – Louis, La théorie du système général. Théorie de la modélisation, Presses universitaires de France, Paris, 1994.

- MESSAGER ROTA V., Gestion de projet – Vers les méthodes agiles, Eyrolles, Paris, 2007.

- MOREAU René, L’approche objets : Concepts et techniques, Edition Masson, Paris, 1995.

- MOREJON J. et RAMES J.R., Conduite de projets informatiques : principes et techniques s’appuyant sur la méthode Merise, Inter éditions, Paris, 1992.

- MORLEY Chantal, Management d’un projet système d’information : principes, techniques, mise en œuvre et outils, 4ième édition, Collection InfoPro, Dunod – Informatique, Paris, 2004

- PRINTZ Jacques, Le génie logiciel, Presses universitaires de France, Collection Que sais-je ?, Paris, 1995.

- ROQUES Pascal, UML par la pratique, 5ième édition, Eyrolles, Paris, 2009. - SIMON H.A., Le Nouveau management : La décision par les ordinateurs, Economica,

Paris, 1980. - TARDIEU H., NANCY Dominique et PASCOT Daniel, Conception d’un système

d’information : construction de la base des données, Les éditions d’organisation, Paris, Gaëtan Morin Editeur, Québec, 1980.

- VAUQUIER Dominique, Plan qualité du logiciel et des services Internet, AFNOR, Saint-Denis-La-Plaine Cedex, 2003.

- VICKOFF J.P., Méthode Agile : « les meilleures pratiques, compréhension et mise en œuvre », RAD Sarl, 2009.

II. COURS ACADEMIQUES

- IVINZA LEPAPA A. C. et MBUTA IKOKO D. A., Génie logiciel et construction des programmes, Université Libre de Kinshasa, Faculté des Sciences Economiques et Gestion, Département d’Informatique de Gestion, L1 INFOGEST, Cours inédit, Année académique 2006 – 2007.

- IVINZA LEPAPA A. C., Projets d’automatisation, Université Libre de Kinshasa, Faculté des Sciences Economiques et Gestion, Département d’Informatique de Gestion, L1 INFOGEST, Cours inédit, Année académique 2001 – 2002.

- LAVOIE Luc, Gestion de projet, Université de Sherbrooke, Faculté des Sciences, Centre de formation en technologies de l’information, INF 754, Cours inédit, Hiver 2007.

- MVIBIDULU KALUYIKIT A., Conception des systèmes d’information, Université Libre de Kinshasa, Faculté des Sciences Economiques et Gestion, Département d’Informatique de Gestion, L1 INFOGEST, Cours inédit, Année académique 2001 – 2002.

III. TRAVAUX, ARTICLES, REVUES ET AUTRES

- ABRAHAMSSON P., WARSTA J., SIPONEN M.T. and RONKAINEN J. « New directions on agile methods : A comparative analysis », IEEE Computer Society, 2003, pp. 244 – 254.

- AFNOR, Ingénierie et qualité du logiciel et des systèmes. Tome 1 : Définitions des processus et qualité des produits, AFNOR, 2002.

- ALLARD POESI F. et PERRET V., Rôles et conflits de rôles du responsable de projet, Revue Française de Gestion, 31(4), 2005, pp. 193-202

- BEZEVIN J. et BLANC X., Promesses et Interrogations de l’Approche MDA, Développeur Référence, http://www.weblmi.com/devreference, septembre 2002, v2.17, pp. 8-12.

36

- CFTL/ISTQB, Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels, Erik van Veenendaal Editeur, Décembre 2007.

- CHARPENTIER P., Comment construire les tests d’un logiciel, INRS, Collection Méthodologie, Cahiers de notes documentaires – Hygiène et sécurité du travail, 4ième trimestre, n° 181 – ND 2140 – 181 - 00, pp. 63-77, 2000.

- CHOKRON Michel, DUFOUR E. et DES ROCHERS M., Connaissances et formation spécifiques aux gestionnaires des TI, Cahier du GReSI, n°05-02, HEC Montréal, Juin 2005.

- CMMI PRODUCT TEAM, CMMI® for Development, Version 1.2, Software Engineering Institute, Carnegie – Mellon, August 2006.

- COMBEMALE Benoît, Ingénierie Dirigée par les Modèles (IDM) : État de l’art, Institut de Recherche en Informatique de Toulouse, Août 2008

- CROCHET DAMAIS Antoine, Gestion de projet informatique : décryptage, Journal du net, Paris, Avril 2011.

- ERICKSON J., LYYTINEN K. and SIAU, K. « Agile modeling, agile software development, and extreme programming: The state of research », Journal of Database Management, 16(4), 2005, pp. 88 – 100.

- GOWAN J.A. and MATHIEU R.G., The Importance of Management Practices in IS Project Performance: An Empirical Study, Journal of Enterprise Information Management, 18(1), 2005, pp. 235 – 255.

- GUILLEMETTE M. G. et PARE Guy, Vers une meilleure compréhension de la transformation de la fonction TI dans les organisations, Cahier du GReSI, n°07-08, HEC Montréal, Décembre 2007.

- IEEE 610.12, Standard Glossary of Software Engineering Terminology, Edition 1990. - IEEE 1233, Guide de l'IEEE pour la Spécification d’Exigences de Système, Edition 1998. - JEZEQUEL J. M., GERARD S., BAUDRY B., « L'ingénierie dirigée par les modèles »,

chapitre « Le génie logiciel et l'IDM : une approche unificatrice par les modèles », Lavoisier, Hermes- science, 2006.

- MBUTA IKOKO D. A., Fonction Technologie de l’Information de l’UEPN – DDR : Approche pour la relance des activités du PNDDR, Document interne, UEPN – DDR, Août 2008.

- MBUTA IKOKO D. A. et Alii, Résultats du déroulement de tests du logiciel Payment Manager, Fonction TI, Document interne, UEPN – DDR, Mars 2009.

- MBUTA IKOKO D. A. et Alii., Rapport de tests sur l’ouverture de la clé de paiement de 150$ USD en 2 dans Payment Manager, Document interne, UEPN – DDR, Juillet 2009.

- MONGIN Philippe et Ali, Evaluation de la solution de gestion du système des paiements des ex – combattants en réinsertion : Elaboration de proposition en vue d’en améliorer la sécurité et la performance, ERNST YOUNG – France, Juillet 2006.

- MOTTU J. M. et alii. Génération automatique de test pour les transformations de modèles. In IDM05 (Ingénierie Dirigée par les Modèles), Paris, France, 2005.

- PIERRE MAJORIQUE Léger, LUC Cassivi et MICHAEL Wybo, Gestion de projet TI : Amener une équipe à utiliser les technologies de communication appropriées, HEC Montréal, Cahier du GReSI, n° 07-02, Janvier 2007.

- SIDI Jacqueline, Les normes : des outils plutôt que des exigences, La lettre d’ADELI n°50, Janvier 2003, pp. 35 - 37.

- VITAL Roy, CARMEN Bernier et MARTIN Danis, Leadership, modes d’approvisionnement et gestion de projets TI, HEC Montréal, Cahier du GReSI, n° 07-06, Mai 2007.