|
Etude pour la mise en place d'un système de paiement électronique dans une institution financière.( Télécharger le fichier original )par Patience KIMWESA Institut supérieur de commerce de Kinshasa - Licence en informatique de gestion 2011 |
Chapitre 5EME : ETUDE DES SCENARII5.0. INTRODUCTION Le présent chapitre nous amènera à établir les scénarii possibles pour la mise en place du futur système futur et les évaluations possibles en termes de coût matériel, logiciel et des besoins en ressources humaines. Pour ce faire, une estimation des gains et des risques sera établie en vue de permettre aux utilisateurs du système futur d'opérer un choix sur la base de ces éléments comparatifs. Tout en rappelant les objectifs du futur système à mettre en place, nous allons, au cours de cette phase d'étude, proposer des solutions possibles, satisfaisant les objectifs et contraintes du domaine.
Les objectifs poursuivis par ce système sont: ü permettre aux commerçants d'accéder à la monétique à moindre coût; ü apporter des services nouveaux à la clientèle des commerçants; ü améliorer le service de la clientèle de la Banque ü moderniser les moyens de paiement; ü décongestionner les guichets bancaires et commerciaux; ü utiliser les cartes comme support de consolidation de la clientèle; ü y apporter une valeur ajoutée à la banque grâce au gain sur les transactions; ü permettre le traitement automatique des transactions financières; ü faciliter les transferts de fonds des clients et des commerçants; ü alléger les charges financières par la diminution des GAB
Il sera question dans ce scénario de mettre en place une application web fonctionnant en environnement 3-tiers où les couches de présentation, traitement et d'accès aux données seront séparées et on devra donc respecter le modèle Vue Contrôleur (MVC). Les traitements, la gestion de la persistance (base de données) et des vues seront effectuées côté serveur, un serveur installé dans un cadre (local) sécurisé à la banque. Les tâches effectuées par les différents acteurs à savoir le fournisseur ou le commerçant, le client et l'Administrateur du système seront possibles en fonction des rôles et des droits qui leurs seront attribués par ce dernier. Les acteurs cités plus haut, à partir de leur poste de travail munit d'un client léger (navigateur web), pourront avoir accès en mode sécurisé à l'application hébergée sur le serveur (distant) et effectueront les tâches qui leur incombent. Le fournisseur pourra effectuer toutes les opérations d'administration de gestion des produits et des transactions en interagissant directement avec l'application et éditer des états. Le client, une fois sa commande établie sur le site du fournisseur, est redirigé de manière transparente et automatique sur la page de l'application où il pourra faire le paiement en toute sécurité. Pour une raison de sécurité, la connexion entre les différentes banques se fera grâce à un VPN (Virtual Private Network) avec lPSEC (Internet Protocol Security) est un protocole (couche 1 du modèle OSI) permettant le transport de données sécurisées sur un réseau IP) comme protocole de cryptage. Pour cette première solution (comme dans les autres solutions), nous préconisons entièrement des outils logiciels Open Source pour le serveur (le système d'exploitation, le SGBD, le serveur d'application, etc.) et aussi pour les clients (le client léger: navigateur
Le système à mettre en place doit tenir compte de la configuration du réseau intranet existant pour l'utilisation du matériel.
COCOMO (COnstructive COst Model) II est un modèle qui permet d'estimer le coût, l'effort et le temps nécessaire au développement d'un logiciel47(*). Le modèle original de COCOMO a été édité la première fois par le Dr. Barry Boehm en 1981 et a reflété les pratiques en matière de développement de logiciel de cette époque. Durant les 15 années suivantes les techniques de développement de logiciel ont changé. COCOMO est le modèle le mieux documenté dont les paramètres sont adaptables à l'environnement. A l'origine, il a été construit sur une étude de 63 projets logiciels de 2000 à 100.000 lignes de code dans l'entreprise TRW Inc. (Société Américaine spécialisée dans l'Automobile et le Transport). Ce modèle existe en trois versions: simple, intermédiaire et détaillé. Nous allons présenter les grandes lignes du modèle simple car c'est ce dernier qui est utilisé pour notre cas précis, afin d'introduire la modélisation comme outil d'estimation des coûts et d'illustrer ses avantages en matière de gestion de projet. Le modèle COCOMO simple est destiné à donner des estimations approximatives de coûts. Il s'appuie uniquement sur la taille estimée du logiciel et sur le type de logiciel à développer. Trois types de projets peuvent donc être distingués : ü Projets de mode organique : concerne des petites équipes travaillant dans un environnement qui leur est familier et un domaine d'application bien connu. Ceci étant, le coût de communication est négligeable, bonne maîtrise du travail par chaque membre de l'équipe, rapidité d'exécution du travail. ü Projets de mode semi-détaché : C'est le pont entre le mode organique et le mode embarqué décrit ci-dessous. Dans cette catégorie, l'équipe de projet peut être composée de programmeurs de divers niveaux d'expérience. Les membres de l'équipe ont une expérience limitée dans ce type de système. Ils peuvent être totalement inexpérimentés en ce qui concerne quelques-uns des aspects du système à développer, mais pas tous. ü Projets de mode embarqué : dans cette catégorie, Le système à développer est une partie d'un système complexe et fortement connecté de matériels et de logiciels, de normes et de procédures opérationnelles. Sa principale caractéristique c'est que le système doit fonctionner sous des contraintes particulièrement fortes. Les formules permettant de calculer le coût, ou plus exactement l'effort requis pour le développement du logiciel sont les suivantes : ü Mode organique : HM48(*) = 2.4 (KLSL49(*)) 1.05 ü Mode semi détaché : HM = 3 (KLSL) 1.12 ü Mode embarqué : HM = 3.6 (KLSL) 1.20 Le modèle COCOMO simple permet également d'estimer le temps de développement nécessaire au projet (TDEV). Le temps de développement est le temps requis pour terminer le projet, en supposant que les ressources de personnel requises sont disponibles. Les équations pour les différents modes de projets sont les suivantes: ü Mode organique TDEV = 2.5 (HM)0.38 ü Mode semi détaché TDEV = 2.5 (HM) 0.35 ü Mode embarqué TDEV = 2.5 (HM) 0.32 Le nombre de personnes requises pour réaliser le projet dans cet intervalle de temps est donc : N = HM/TDEV. Le coût total de réalisation dans notre cas sera estimé à HM * ValeurHM. Où ValeurHM représente le salaire moyen d'un informaticien en République Démocratique du Congo. Nous estimons ce salaire à mille dollars américains (1000$).
Les matériels suivants sont indispensables pour la mise en place de ce scénario : ü trois (03) serveurs; ü cinq (05) micro-ordinateurs; ü quatre (04) imprimantes; ü un (01) ondu1eur ; ü un (01) switch ; ü un (0 1) routeur ; ü un (01) modem; ü un (01) Firewall.
Pour les systèmes d'exploitation : ü Windows 7 pour les micro-ordinateurs ; ü Ubuntu 12.04 Server 64 bits pour les serveurs. ü Pour les logiciels de développement WinDev 15 ü Pour le logiciel antivirus Kaspersky 2011
Étant donné que le groupe de développement est assez restreint et est familier avec le cadre d'étude, nous avons choisi la première famille de projet décrite dans le modèle COCOMO, c'est-à-dire un projet en mode organique. Pour déterminer le nombre de ligne de code source de l'application, nous estimons à dix-sept (17) le nombre de processus automatisables et à cinq cent (500) lignes la taille du code source de chacun de ces processus. ValeurHM = 1000$en RDC. Par application nous obtenons: L'effort à consentir : ü HM = 2.4 (500* 17/1000)1.05 ü HM = 22.70 Le temps de développement : ü Tdev = 2.5*(21.3)0.38 ü Tdev = 7.99 mois Nombre de personnes nécessaires pour accomplir le travail dans le délai : ü HM/Tdev = 21.3/7.99 ü HM/Tdev = 2.66 Soit environ 3 personnes. Coût financier de l'application (CF): ü CF = HM*ValeurHM ü CF = 21.3*1000$ ü CF = 21300$
Les utilisateurs de l'application (un administrateur, un agent du Service Système Production et Exploitation et un agent du Service Monétique) devront être formés.
Comme dans le scénario précédent, il sera également question ici de la mise en place d'une application web fonctionnant en environnement 3-tiers. Les procédures de connexion des différents acteurs à l'application restent inchangées toujours avec une sécurité dans l'échange des données. Du moins dans ce scénario, sera mis en place un CTMI (Centre de Traitement Monétique Interbancaire, centre où convergent toutes les banques partenaires). Nous proposerons une connexion VPN (avec IPSEC comme protocole de cryptage) au CTMI afin de s'appuyer sur ce réseau pour se connecter aux autres banques. Cette architecture respecte les contraintes mais nécessite le développement d'un module supplémentaire pour interagir à partir de l'interface de l'application avec les serveurs du CTMI.
Dans ce deuxième scénario, nous avons les mêmes conditions de développement que celles décrites au scénario précédent. Il s'agit donc du cas d'un projet en mode organique. Et pour déterminer le nombre de ligne de code source de l'application, nous estimons à dix-sept (17) le nombre de processus automatisables et à cinq cent (500) lignes la taille du code source de chacun de ces processus. ValeurHM = 1000$ en RDC. Le tableau ci-dessous contient les résultats obtenus par l'application de la méthode COCOMO.
Comme dans le scénario précédent, les utilisateurs de l'application (un administrateur, un agent du Service Système Production et Exploitation et un agent du Service Monétique) devront être formés.
A la différence des deux scénarios vus précédemment, ce troisième scénario que nous allons présenter sera assez complexe dans son architecture réseau, par contre facile à mettre en oeuvre. Il est comparable à l'actuel système d'information comprenant les évolutions devant satisfaire les contraintes. En effet l'architecture permettant le fonctionnement des GAB est comparable à ce scénario. Mais comparable aux scénarii cités précédemment, les échanges d'informations entre les acteurs se feront de manière sécurisée. Nous avons mis en place une Ligne Spécialisée (LS) pour la connexion de manière sécurisée, la Banque à l'une des banques partenaires (BP) que nous avons reliée au CTMI par une connexion VSAT.
.
NB : concernant la liste du matériel requis, nous signalons que seule la gamme des matériels accompagnants l'antenne VSAT s'ajoute aux équipements énumérés dans les deux précédents scénarios. Liste des logiciels requis est la même que pour les deux précédents scénarios, par rapport à l'évaluation des coûts, le coût matériel bouge avec l'ajout du matériel VSAT ; le coût logiciel ainsi que celui de formation des utilisateurs restent les mêmes, ainsi, le coût total de mise en oeuvre sera un peu plus élevé que pour les précédents scénarios.
Avantage : ü échange sécurisé des informations entre la Banque, la banque du client et la banque du fournisseur à travers le VPN IPSEC ; ü utilisation importante des outils logiciels Open Source; ü gain en temps de traitement; ü niveau de sécurité très élevée. Inconvénients: ü difficultés liées à la mise en oeuvre; ü difficultés liées à l'exploitation; ü nécessité de faire une bonne répartition des charges; ü coût de réalisation élevé.
Avantage : ü échange sécurisé des informations entre la Banque et le CTMI à travers le VPN IPSEC; ü utilisation importante des outils logiciels Open Source; ü rapidité de traitement; ü niveau de sécurité élevée; ü répartition optimale des tâches métiers; ü facilité d'exploitation. Inconvénients: ü mise en oeuvre difficile ; ü coût de réalisation élevé; ü mise en place de la politique de sécurité difficile.
Avantage: ü Automatisation des opérations (sans intervention manuelle); ü gain optimal en temps d'exécution des tâches métiers; ü échange sécurisé des informations entre la Banque, la Banque partenaire intermédiaire par cryptage des données à travers la Liaison Spécialisée; ü utilisation importante des outils logiciels Open Source ; ü répartition optimale des tâches métiers; ü facilité de maintenance; ü coût de réalisation acceptable. Inconvénients : ü encombrement lié à l'augmentation du trafic; ü difficulté de mettre en place une politique de sécurité.
Scénario Critères
Avec le scénario retenu on devra mettre en place un logiciel devant répondre à un certain nombre d'objectifs entre autre : ü Permettre le client d'effectuer le paiement de sa commande d'une manière sécurisée; ü Faciliter le commerçant de toucher son argent dans les meilleurs délais lorsqu'il effectue une vente; ü renforcer la confidentialité et la sécurité des données; ü permettre aux utilisateurs l'établissement d'états statistiques; ü améliorer la rapidité de traitement des données bancaires; ü assurer l'intégrité des données; Le choix du comité de pilotage s'est porté sur le troisième scénario qui sera mis en oeuvre. Ce choix se justifie par: ü la prise en compte de tous les objectifs et les contraintes exprimés par les utilisateurs; ü le coût de développement plus abordable; ü fiabilité et rapidité dans les traitements; ü facilité de sa mise en oeuvre.
La mise en oeuvre de la solution proposée se fera comme suit: ü le développement de l'application; ü l'installation de l'application ü la formation des utilisateurs; ü le test du nouveau produit; ü la mise en exploitation de l'application,
Il a été question dans ce chapitre de présenter les solutions envisagées pour améliorer les insuffisances du système en place tenant compte des contraintes. Le coût, avantages et inconvénients des différentes solutions que nous considérons comme éléments de décision présentés nous ont permis de choisir le troisième scénario pour la mise en oeuvre. Cette solution choisie fera l'objet de la rédaction du cahier des charges utilisateur à la prochaine étape de notre analyse. * 47 R.DELCAMBRE, « COCOMO », Mars 2003, page 2 * 48 HM : nombre d'Homme/Mois nécessaire à la réalisation du projet, * 49 KLSL : nombre de kilo-lignes livrées. |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
