Recherche
2.2- Bâle II et le financement des P.M.E
Le passage de la réglementation Bâle I à la réglementation Bâle II réduirait l’aversion des banques au risque des créances P.M.E et améliorerait l’environnement institutionnel dans lequel va s’inscrire la relation financière entre banques commerciales et P.M.E. Ainsi, en nous alignant sur les conclusions de AUBIER (2007), nous pouvons prévoir que la réglementation de Bâle […]
CONCLUSION GENERALE
Le développement du secteur privé, dans des économies d’endettement comme le Gabon, s’effectue sous la contrainte d’une activité d’intermédiation financière des banques commerciales. Or, faute de projets bancables et face à un secteur privé a priori risqué, les banques secondaires gabonaises montrent une aversion au risque de crédit. Cette aversion se révèle, dans le portefeuille […]
ANNEXE I : DOCUMENT
Formule de trimestrialisation des données Pour chaque variable Z annuellement observée, nous associons la quantité q telle que : q = [4* Z t (0,5* Z t-1 + 3* Z t + 0,5* Z t+1)] 1/2 Z t est la valeur de l’année courante Z t-1 est la valeur de l’année antérieure Z t+1 est […]
ANNEXE II : TABLEAUX
TABLEAU 1 : Résultat des tests de normalité des séries Valeurs de références SKEWNESS : 0 KURTOSIS : 1.96 PROBABILITE : 0.05 TABLEAU 2 : Tests de stationnarité des séries et des erreurs Ho : Les donnés contiennent une racine unitaire. *(** (***)) On rejette l’hypothèse Ho au seuil de 10%(5%(1%)). TABLEAU 3 : Critère […]
BIBLIOGRAPHIE
· AGGARWAL R., JACQUES K., (2001): « The impact of FDICIA and prompt corrective action on bank capital and risk: Estimates using simultaneous equations model », journal of banking and finance, vol.25, pp.1139-1160. · AGLIETTA M., MOULOT., 1993, « Le risque de système et sa prévention », Cahiers Economiques et Monétaires de la Banque de […]
COMPORTEMENTS FACE AUX RISQUES ET DEVELOPPEMENT DU SECTEUR PRIVE
COMPORTEMENT FACE AUX RISQUES ET DEVELOPPEMENT DU SECTEUR PRIVE
Auteur : ASSOUMOU ONDO
Année de publication : 2009
UNIVERSITE OMAR BONGO
Discipline : Sciences Économiques
Directeur de mémoire :
Monsieur Albert ONDO OSSA, Professeur titulaire à l’Université OMAR BONGO
Membres du Jury
Monsieur Jean-Jacques EKOMIE, Professeur agrégé, à l’Université OMAR BONGO
Monsieur Symphorien ENGONE MVE, Professeur agrégé, à l’Université OMAR BONGO
Monsieur Jean Sylvain NDO NDONG, Maître assistant, à l’Université OMAR BONGO
Acronymes
ADM : Architecture Driven Modernization (Modernisation dirigée par les modèles) ANT : Architecture N Tiers API : Application Programming Interface (Interface de programmation) ASTM : Abstract Syntax Tree Metamodel (métamodèle d’arbre de syntaxe abstrait) BU : Business Unit (Unité d’affaires) CDO : Connected Data Objects (Objets de données connectés) CIM : Computation Independent Model (Modèle […]
Remerciements
Tout d’abord, je tiens à remercier MM. Faia et Breton, instigateurs puis promoteurs de l’idée de ce cursus d’ingénieur au CNAM en parallèle à mon activité professionnelle au sein de Sodifrance. Je remercie aussi toute l’équipe d’évolution d’architecture de Sodifrance dans laquelle j’évolue actuellement pour son soutien et son aide, aussi bien morale que technique. […]
Avertissement
De nombreux termes de ce mémoire sont mentionnés en langue anglaise. Bien que, dans la plupart des cas, une traduction en français soit possible, les termes anglais peuvent être tout de même utilisés si la traduction (par une expression courte) dénature le concept désigné. Les mots ou expressions en langue anglaise sont écrits en italique. […]
1 INTRODUCTION
Le sujet de ce mémoire, « Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance », a été défini d’un commun accord entre mes responsables et moi-même. Il comprend deux thèmes principaux qui sont la cartographie des tests d’une part, et l’automatisation des tests d’autre part. Ce sujet n’a pas été choisi sans […]
2 L’ENVIRONNEMENT
Avant d’entrer dans le vif du sujet, je vais présenter dans ce chapitre successivement l’entreprise Sodifrance, puis le processus « classique » d’évolution d’architecture utilisé lors des migrations d’applications. Page suivante : 2.1 Présentation de l’entrepriseRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
2.1 Présentation de l’entreprise
Sodifrance a été fondée en 1986 par M. Francis Mazin. Partenaire historique du secteur bancaire, l’entreprise s’est orientée en 1992 vers la transformation automatisée de systèmes d’information. L’année 1999 marque un tournant au niveau organisationnel, en effet cette année survient le décès du fondateur, et l’entrée en bourse sur le second marché. L’équipe dirigeante s’organise […]
2.2 Le processus d’évolution d’architecture
Avant de présenter la problématique proprement dite de ce mémoire, il convient de définir le contexte dans lequel il s’est déroulé. Comme indiqué précédemment, j’appartiens à l’équipe d’évolution d’architecture de Sodifrance. Je devais donc réussir à intégrer mes travaux dans le processus de migration existant. Page suivante : 2.2.1 Présentation générale du processus de migrationRetour […]
2.2.1 Présentation générale du processus de migration
Le processus global de migration est divisé en deux grandes parties : La phase de cadrage, qui permet de définir précisément ce qui va être fait : · étude de la, ou des applications sources · étude de l’architecture cible · définition des lots de migration · adaptation de l’outillage (MIA Transformation(1), MIA Generation(2)) · […]
2.2.2 Présentation du processus de migration industrielle
Afin de définir la phase de migration industrielle, il convient d’approfondir quelques notions. Commençons par l’architecture dirigée par les modèles (Model Driven Architecture, MDA). Selon M. Villemin (Villemin 2011) « L’initiative d’architecture dirigée par les modèles de l’OMG(3) “Model Driven Architecture” (MDA) est motivée par le besoin de réduire les tâches de reconception des applications […]
2.2.3 Les tests dans le processus de migration
Dans le cadre de ces projets d’évolution d’architecture, le résultat de la migration est validé en vérifiant l’iso-fonctionnalité entre l’application d’origine et l’application migrée. Pour cela, on contrôle que les tests sur les applications sources et cibles donnent les mêmes résultats. La charge consacrée à ces tests est donc loin d’être négligeable, et ce d’autant […]
3 LE TRAVAIL REALISE
Après un échange avec mon tuteur et notre hiérarchie, il a été convenu de traiter les problématiques de cartographie et d’automatisation des tests. En effet, c’est à ce niveau que se trouve le plus gros effort manuel et qu’il y a le plus d’incompréhension entre la vision fonctionnelle des clients et la nôtre qui est […]
3.1 Etat de l’art
Page suivante : 3.1.1 Model Driven Engineering, Model Driven ArchitectureRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
3.1.1 Model Driven Engineering, Model Driven Architecture
L’architecture dirigée par les modèles (Model-Driven Architecture, MDA), présentée au § 2.2.2, est « une variante particulière d’une tendance plus générale nommée ingénierie des modèles » (Model- Driven Engineering, MDE). Tout comme un des principes de base de la technologie objet est « tout est objet » (cf. Figure 8), le principe de base du […]
3.1.2 Cartographie d’application
Dans le cadre de la cartographie applicative, on peut trouver plusieurs objectifs : avoir une vision de haut niveau de ses applications, ou au contraire, avoir une connaissance très fine de celles-ci en descendant jusqu’aux lignes de codes qui les composent. Le groupe de travail modernisation d’architecture dirigée par les modèles (Architecture-Driven Modernization task force, […]
3.1.3 Test
Page suivante : 3.1.3.1 GénéralitésRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
3.1.3.1 Généralités
M. Félix donne une définition très claire de ce qu’est un test (FELIX 2011) : « Toute fabrication de produit suit les étapes suivantes : conception, réalisation et test. Avec le test, on s’assure que le produit final correspond à ce qui a été demandé… ». Selon l’institut des ingénieurs électriciens et électroniciens (The Institute […]
3.1.3.2 Tests basés sur les modèles (Model Based Testing)
De même que les modèles tendent à s’imposer dans le monde du développement, la part que représentent les tests basés sur les modèles commence à se faire de plus en plus visible. Assez longtemps délaissée, cette discipline fait désormais l’objet d’études sérieuses et approfondies. Bien que de nombreux documents traitent de ce sujet, ils sont […]
3.2 Plate-forme de migration (« Migration Platform »)
La Figure 15 représente les principaux cas d’utilisation du système « Migration Platform ». Ils sont répartis de la manière suivante : · La cartographie de l’application représente la base de l’ensemble et contiendra tous les composants applicatifs du projet (fenêtres, composants graphiques, classes, fonctions). · La cartographie des tests intègre les différentes données propres […]
3.2.1 La cartographie des applications
Avant d’approfondir les deux principaux objectifs de ce mémoire, se pose le problème essentiel de la cartographie des applications. En effet, pour pouvoir indiquer quels composants sont utilisés par un scénario de test, il faut déjà pouvoir lister de manière exhaustive l’ensemble des composants de l’application et les identifier de manière unique. Comme indiqué dans […]
3.2.2 Objectif 1 : cartographie des tests
L’instrumentation du code source, détaillé au § 4.2, doit fournir, à la suite du passage des tests de références, deux types de flux XML. Dans le premier, on va chercher à ajouter du code pour chaque méthode, juste après l’entrée et juste avant chaque instruction de sortie. On obtient ainsi une arborescence des appels de […]
3.2.2.1 Vision statique et dynamique de la cartographie
Avant l’insertion des tests, la base de donnée ne contient que ce que l’analyseur syntaxique a pu lui fournir. Pour garder le langage Visual Basic en exemple, l’instruction : Public Function getCustomer() as clsCustomer sera interprétée comme une fonction renvoyant une instance de la classe « clsCustomer ». Dans le modèle, il en résulte la […]
3.2.2.2 Représentation graphique de la cartographie des tests
J’ai étudié et maquetté sous forme de services Java plusieurs types de représentations graphiques. A partir des données de la cartographie d’application, j’ai produit un modèle UML qui exporté au format XMI puis importé dans MagicDraw, permet d’obtenir un diagramme de classe et de visualiser les relations entre les opérations (cf. Figure 22). Figure 23 […]
3.2.3 Objectif 2 : automatisation des tests
Les tests sur les applications cibles se font à l’aide d’outils de rejeu de test, comme FlexMonkey(22) pour une application Flash par exemple. Habituellement, il faut jouer les scénarios de test sur l’application à tester afin que l’outil enregistre les actions qui sont effectuées sur l’interface graphique. L’idée de l’automatisation des tests, c’est de mettre […]
3.2.3.1 Génération des scripts de test
La génération des scripts de test se fait alors en parcourant les enregistrements de test, qui pointent sur des composants sources, et pour chaque composant, en cherchant le composant cible qui lui est associé. Pour chaque événement en base, on retrouvera trois actions de génération : · Positionner les propriétés qui n’auront pas été changées […]