Soutenance mémoire
CONNAISSANCES THEORIQUES
Ce chapitre est consacré à l’explication de la théorie des différents aspects techniques abordés dans ce rapport. Ces éléments permettront de discuter les choix effectués.
EAI
Pour l’échange des données entre le serveur SAS et le serveur ROSTAM, l’OI (Organisation de l’Information) a proposé d’utiliser EAI. Ne connaissant pas ce principe , j’ai réalisé une recherche à ce sujet.
Objectifs
La définition de EAI extraite de Wikipédia est la suivante :
« L’intégration d’applications d’entreprise ou IAE (en anglais enterprise application integration, EAI) est une architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges. On la place dans la catégorie des technologies informatiques d’intégration métier (business integration) et d’urbanisation. Sa particularité est d’échanger les données en pseudo temps réel. »
EAI est un des moyens de répondre au besoin de communication entre différentes applications hétérogènes du Système d’Information qui a plusieurs objectifs [1]:
– Présenter à l’utilisateur final une vision unifiée de l’information gérée par les différentes applications ;
– Masquer la complexité du système d’information et donc faciliter la prise de décision ;
– Résoudre le problème de la cohérence entre des systèmes qui s’entrecroisent.
Lorsqu’il y a peu d’applications à intégrer, une approche simple à mettre en place est celle de la connexion point à point. Pour un nombre n d’applications à connecter entre elles, il est nécessaire de mettre en place n (n-1)/2 tuyaux de communication [2].
Mais dès qu’il y a un plus grand nombre d’applications, alors ce mode devient complexe.
Pour 5 applications, il faut alors 20 tuyaux de communication. La comparaison avec le « syndrome du plat de spaghettis » évoquée par John Rusby est alors appropriée : « A badly structured program is likened to a plateful of spaghetti : if one strand is pulled, then the ramifications can be seen at the other side of the plate where there is a mysterious turbulence and upheaval ».
Si une application évolue alors un grand nombre d’applications sont concernées.
L’illustration ci-dessous (cf. Figure 7, extrait de [3]) montre la différence de complexité de lecture et de compréhension entre une communication entre chaque application et une communication centralisée avec EAI.
Le moteur d’intégration
Le moteur d’intégration désigne le message broker qui transforme et transmet les messages entre les applications. Les données en sortie d’une application et en entrée d’une autre peuvent avoir des formats différents. Par exemple la date peut être de multiples formats.
Elle peut s’écrire de façon « mm/yyyy » dans une application et « dd/mm/yyyy » dans une autre. Le message broker gère ces transformations. L’étape de « mapping des données » permet alors d’établir ces règles. Ce mapping reçoit donc un OMS et le transforme en OM (Objets de métier).
Un des intérêts techniques à réaliser les transformations dans le message broker est de les centraliser dans un outil dédié. Il est possible de réaliser des enrichissements d’informations comme des agrégations, ajouts de champs, de l’ordonnancement de tâches exécutées sur des applications avec des plateformes différentes, de la gestion de processus de rythme différent (exemple : mettre une base de données à jour uniquement lorsqu’un ou plusieurs processus seront terminés) …
Le routage peut être :
– Statique, soit défini par le type du flux ;
– Dynamique, soit défini par le contenu du flux.
Dans les deux cas il peut être un :
– One-to-one, soit une communication d’une application A vers une application B ;
– Many-to-many, soit une communication d’une ou plusieurs applications (fusion d’informations, calcul, agrégation…) vers une ou plusieurs autres applications .
Les règles de transformation et de routage peuvent être contenues dans un référentiel de métadonnées qui dictera les règles à appliquer lors de l’arrivée d’un message.
La gestion du routage peut également être réalisée en fonction des processus métier. On parle alors de BPM (Business Process Management).
Les différentes architectures
Architecture Hub and Spoke
L’architecture Hub and Spoke (cf. Figure 8, extrait de [3]) centralise l’ensemble des communications avec un hub unique. Le référentiel des règles de routage et de transformation est donc également centralisé. L’administration de la plateforme en est alors simplifiée. Un des inconvénients majeurs est que si, le hub n’est plus disponible, alors aucune intégration ne sera possible. De plus la gestion de charge est complexe à gérer au vu de la centralisation.
Intégration au niveau des applications
L’intégration au niveau des applications permet de récupérer les règles métiers des applications en passant par des API métiers. L’EAI a donc le rôle de communication avec les API (cf. Figure 13, extrait de [6])
Intégration au niveau des processus métier
À la différence des deux précédentes intégrations qui sont « techniques », cette dernière est fonctionnelle. L’intégration des processus métier est dirigée par ces derniers. On l’appelle aussi BPI (Business Process Integration). L’EAI aura pour rôle d’orchestrer l’intégration des données et de suivre l’intégration (bonne création du client, délai de validation…) (cf. Figure 14, extrait de [6]).
LA CHAINE DECISIONNELLE
Une décision ne peut être prise sans information, sans donnée, sauf à le faire au hasard.
Tout au long de sa vie le cerveau humain enregistre des informations que nous utilisons chaque jour pour prendre des décisions : « Il fait 30°, est-ce que je prends mon manteau ? ».
Pour prendre cette décision banale nous sélectionnons uniquement certaines informations face à la multitude dont nous disposons. Paul Valéry a écrit : « Que de choses il faut ignorer pour agir ». Je prendrai cette citation dans le sens « décisionnel ». En effet, pour prendre une décision, il faut ignorer toutes les informations inutiles. C’est le cas des entreprises qui doivent, elles aussi, avoir des informations pertinentes sur lesquelles se baser afin d’être compétitives, augmenter le profit, trouver un cœur de cible , analyser les changements climatiques…Le nombre de données augmentent sans cesse (internet, réseaux sociaux, internet des objets…) et l’informatique décisionnelle a pour objectif de les utiliser pour en extraire de l’information utile.
Les données sources
Les données sources (ou les données de production) sont extraites afin que le « travail décisionnel » ne se réalise pas directement dessus. En effet, les traitements d’analyses peuvent être lourds et donc ralentirent ceux de production et peut être les mettre en péril.
Les données utiles à l’entreprise pour fonctionner, également appelées données transactionnelles, servent dans les systèmes opérationnels ou OLTP (On-Line Transaction Processing). Ces données sont dédiées aux métiers opérationnels de l’entreprise. Par exemple, les données des commandes reçues le jour-même, et dirigées vers la personne vérifiant leur contenu. Elles n’ont pas vocation à être historisées, mais bien uniquement à faire fonctionner l’entreprise quotidiennement. C’est par ailleurs l’une des raisons d’extraire et de stocker ces informations dans un autre système plus décisionnel.
Ces systèmes décisionnels ou OLAP (On-Line Analytical Processing) sont orientés pour les décideurs de l’entreprise, pour les études, etc. En reprenant l’exemple de la commande du jour, les données seraient l’ensemble des commandes reçues et non uniquement celle du jour.
De par leur nature de fonctionnement et d’objectif, il existe plusieurs différences entre ces deux systèmes qui sont récapitulées dans le tableau ci-dessous (cf. Tableau 1, extrait de [8]).
Les métadonnées
Les métadonnées, soit les données sur les données, permettent de mieux comprendre les données. Une métadonnée peut être, par exemple, une coordonnée GPS sur une photo permettant de savoir exactement où elle a été prise ou une étiquette sur une boîte de conserve pour connaître son contenu, etc. Les métadonnées données sont dites l’ADN de l’entrepôt de données qui définissent tous les élé ments et comment ils fonctionnent ensemble [9].
Dans le décisionnel, les métadonnées doivent pouvoir décrire le processus d’alimentation et le contenu du Data Warehouse. Dans [10], Bill Inmon les décrit comme « un index du contenu de l’entrepôt de données ». Elles permettent, en les interrogeant, de retrouver les données plus rapidement, de savoir lesquelles seront utiles, de connaître les transformations opérées…
La figure ci-dessous (cf. Figure 16, extrait de [10]) montre l’importance des métadonnées pour le mapping entre les données du système opérationnel et celles de l’entrepôt de données. En effet, une donnée peut changer de nom, subir des transformations, etc. Sans cette « description », il est alors plus difficile de retrouver l’origine d’une donnée et donc de bien la comprendre.
L’entrepôt de données : Data Warehouse
Bill Inmon définit l’entrepôt de données de la façon suivante :
« Un entrepôt de données est une collection de données thématiques, intégrées, non volatiles et historisées, organisées pour le support à la prise de décision. »
L’entrepôt de données est thématique soit orienté vers les sujets majeurs de l’entreprise, à la différence des données opérationnelles qui sont, elles, autour des applications fonctionnelles de l’entreprise.
L’entrepôt de données est intégré. Comme vu dans le chapitre « 5.2.5 L’intégration » l’entrepôt a de multiples sources. Une même donnée peut alors avoir différentes notations, différents formats, etc. Des données peuvent être incohérentes, des conversions ou des agrégats sont sans doute également nécessaires. En ce sens, l’entrepôt doit être intégré.
L’entrepôt de données est non-volatile. Une donnée dans un entrepôt de données n’est jamais « mise à jour » directement. Dans ce cas on procède à un nouvel enregistrement afin de conserver la trace de sa valeur initiale. Ce qui est différent du système opérationnel, où une donnée peut être modifiée directement, voire même supprimée par exemple quand unecommande est terminée (cf. Figure 21, extrait de [10]).
Diverses architectures possibles
Architecture à magasins matérialisés et entrepôt virtuel
Précédemment, nous avons vu que le datamart se source depuis le data warehouse. Les approches de Ralph Kimball et Bill Inmon s’opposent sur ce sujet. Pour Ralph Kimball, le data warehouse est « logique », il n’existe que virtuellement. Il se compose de l’intégralité des datamarts qui eux sont « physiques ». Pour Bill Inmon le data warehouse est physique et les datamarts, physiques eux aussi, se sourcent de ce dernier. Il peut donc y avoir plusieurs conceptions sur le « data warehouse ».
Architecture par médiateur
L’architecture par médiateur est une intégration virtuelle des données [14]. L’entrepôt de données est virtuel. Il n’est pas stocké physiquement. Les données restent dans les sources et sont requêtées par l’intermédiaire de médiateurs et d’adaptateurs (ou wrappers).
L’utilisateur requête le médiateur qui aura pour tâche de trouver l’information avec l’aide des adaptateurs (cf. Figure 22, extrait de [15]). Cette architecture permet d’interroger des données toujours à jour, même si les mises à jour sont très fréquentes.
Le médiateur définit ce que l’on appelle un schéma global. Il contiendra alors des vues abstraites sur les sources de données. Les utilisateurs interrogent ce schéma global. Les adaptateurs traduisent les requêtes dans le langage des sources afin de pouvoir extraire l’information de ce que l’on appelle schéma local.
MOLAP
Le MOLAP (Multidimensional OLAP) est une implémentation multidimensionnelle du cube.
Les données sont stockées dans une base de données multidimensionnelle. L’ensemble des combinaisons des dimensions sont pré-calculées dans le cube. Le temps de réponse pour une consultation du cube est donc instantané. Le langage d’interrogation du cube est le MDX (Multidimensional Expressions).
ROLAP
Le ROLAP (Relational OLAP) est une implémentation relationnelle du cube. C’est donc un système de base de données « classique » avec des relations entre tables. Les données ne sont donc pas pré-calculées. Elles seront à calculer à chaque interrogation de la base de données avec le langage SQL (Structured Query Language).
Une des principales modélisations est le modèle en étoile (cf. Figure 27, extrait de [19]). Il y a deux types de tables qui sont la table de FAIT et les tables de DIMENSION.
Le type de fait
Un fait peut être de trois types différents selon la manière dont on désire le mesurer.
Le type transaction décrit la transaction, ou l’événement, ou une action. Cela peut être l’action de vente d’un téléphone, une température à un instant donné , une entrée dans un cinéma, etc. Il est donc important que cette mesure soit horodatée (heure ou minute ou seconde ou microseconde ou plus fin selon les besoins). Dans la table de fait, il y aura donc une ligne par événement.
Le type instantané périodique décrit l’activité ou la performance sur une période de temps répétée régulièrement. Cela peut être le nombre de téléphones vendus par jour, le nombre d’entrée au cinéma par semaine, le temps d’ensoleillement sur la journée, etc. L’horodatage est généralement la fin de période. Dans la table de fait, il y aura donc une ligne par période de temps.
Le type instantané récapitulatif décrit des processus qui ont un début et une fin définis mais pas nécessairement en terme de date. Il est adapté à la mesure d’un flux d’activité ou de travail. Cela peut être la conception d’un téléphone, le traitement d’une quelconque demande, etc. L’horodatage sera souvent multiple afin de connaître les dates de passage à chaque étape du processus. Dans la table de fait, il y aura une ligne par activité mise à jour tout au long de son processus.
Analyse des évolutions SAS
L’analyse des impacts SAS est simplifiée car aucune modification fonctionnelle n’est réalisée.
Les étapes à modifier/créer sont alors celles d’extraction des données, d’envoi des données à ROSTAM et de la nouvelle IHM de lancement de chaîne.
Les extractions de données de ROSTAM
J’ai échangé avec la MOE pour définir la meilleure méthode (i.e. la plus rapide en temps d’exécution) pour extraire les données. Afin de limiter les impacts sur la chaîne SAS, je conserve le même format des tables résultats d’extraction. Au besoin, je réalise alors des opérations de transformation pour obtenir un format identique. Ainsi, la suite de la chaîne de traitement n’est pas impactée.
Lors de cette analyse (mais également lors de la conception et de l’implémentation), j’ai demandé à connaître les optimisations positionnées sur les tables ROSTAM (principalement index et partition). Je n’ai jamais obtenu cette information. Ayant uniquement un accès via SAS à la base, je ne peux donc pas connaître cette information. Cela est bien entendu pénalisant pour définir les méthodes d’extraction. La MOE m’a transmis que si les temps d’extractions étaient trop longs, elle en analyserait les raisons et optimiserait le modèle. SAS n’extrait pas les données directement des tables ROSTAM de production. ROSTAM met en place des vues qui sont des « copies conformes » des tables de production. C’est la politique menée à la Banque de France pour l’accès aux bases de données externes.
L’identification de la catégorie d’usure de crédit
J’ai découvert que les catégories du taux d’usure sont identifiées avec des caractéristiques des lignes de crédit (durée du crédit, montant du crédit, etc.) écrites directement dans les programmes SAS. Cette solution ne permet pas d’obtenir un suivi des évolutions des catégories (par décret de la Loi). La seule chose que l’on puisse réaliser dans ce cadre est, soit de versionner les programmes, soit de conserver les anciennes versions avec des commentaires. Dans ces deux cas, obtenir les évolutions des catégories sur une période doit être fait en recherche textuelle. Pour exécuter une chaîne sur une échéance passée, il faut donc retrouver le bon code de cette échéance. A mon avis, ce n’est pas la bonne méthode.
J’ai alors proposé de réaliser cette identification dans une table de paramètre avec des périodes de validité. Il sera ainsi possible de tracer les évolutions mais également de pouvoir lancer une chaîne sur n’importe quelle échéance sans avoir à modifier le code SAS . Cette proposition a été validée par le métier car elle n’est pas coûteuse à mettre en place et offre un réel intérêt de maintenance et de suivi. Dans l’idéal, il aurait été préférable de définir une nouvelle table de dimension dans le modèle en étoile ROSTAM. Mais cette solution a été refusée par la MOE.
Nouveau mode de lancement de la chaîne SAS de l’usure
Le lancement de la chaîne SAS sur l’ancien système se faisait via une IHM JAVA. Afin d’éviter d’être dépendant d’une autre technologie, mon analyse propose une solution complète SAS avec un lancement de la chaîne par une procédure stockée SAS. Cette dernière reprendra exactement les mêmes paramètres et fonctionnalités que l’IHM JAVA. Au niveau des procédures stockées de SAS, une gestion « d’invité » permet rapidement de créer une IHM.
Le coût de création est finalement minime et la maintenance est simple. Ce choix a donc été validé. Sur l’ancien système, le lancement de la chaîne de l’usure se fait obligatoirement sur une unique échéance. J’ai proposé de pouvoir saisir de multiples échéances. Cette proposition a été rejetée par le métier car jugée non-nécessaire.
Envoi des données résultats à ROSTAM
Une fois les données de l’usure validée par le métier (relance effectuée auprès des remettants), les données sont transmises à ROSTAM pour diffusion. Pour stocker les données résultats dans la base de données ROSTAM, je conseille d’utiliser la possibilité de SAS à alimenter des bases de données externes. En effet, SAS est un ETL. Il a donc la capacité à charger des données en base de données externe. En créant un compte technique sur une table de la base ROSTAM en « lecture-écriture », SAS peut alimenter directement la table de résultat à l’aide du compte. La MOE a une nouvelle fois refusé ma proposition au profit de l’EAI. La raison principale est que la MOE souhaite contrôler les données avant chargement.
Toutefois cela aurait été possible, en donnant un accès en écriture dans une table « temporaire » de ROSTAM. Une fois les données chargées dans cette table, la MOE pouvait contrôler les données avant de les charger dans la table finale par exemple avec la mise en place d’un trigger. Ce choix n’a pourtant pas été décidé. Afin d’éviter aux utilisateurs des manipulations successives, je propose de mettre en place une procédure stockée SAS qui générera le ficher en entrée de ligne EAI. Une fois le fichier déposé par la procédure stockée, EAI effectuera le transfert et ROSTAM intégrera les données.
Conception de l’extraction des données de collecte
Cette étape extrait les lignes de crédit de M_CONTRAN par échéance
Extraction des données de collecte
L’extraction des données de collecte nécessite trois informations. L’identifiant de la collecte, l’échéance et la liste des remises. Avec ces informations, je peux extraire les données souhaitées de la table des faits V_FCT_FAIT.
Dans la base de données ROSTAM, chaque collecte de données est identifiée par un numéro unique. Il est stocké dans la table de dimension V_DIM_SOURCE (cf. Figure 32). L’usure (source = MCO) correspond à l’identifiant 216.
De façon analogue, chaque échéance a un identifiant unique défini dans la table de dimension V_DIM_ECHEANCE (cf. Figure 33). Cette table ne contient pas de variable date mais deux variables numériques (mois et année). L’identifiant de l’échéance est alors la « concaténation » de ces deux variables. Ce choix sera discuté dans le chapitre « 6.8.2 La mise en œuvre du modèle étoile de la base de données ROSTAM ». Dans ma conception, j’opte pour extraire l’identifiant de l’échéance et le stocker dans une macro variable SAS.
Ainsi je n’ai pas besoin dans mes requêtes SQL de faire appel à la table V_DIM_ECHEANCE. Il n’y a donc plus besoin de réaliser une jointure avec cette table. Il suffira uniquement de position une clause « where ». Cela optimise le traitement.
La variable booléenne VERSION permet de savoir si la ligne est une remise active (i.e. la dernière du remettant). En effet, un remettant (CIB) peut déposer plusieurs fois un fichier pour une même échéance afin de corriger des erreurs. Sa remise est toujours en mode « annulée/remplacée ». Dans ce cas, pour la dernière remise, la variable VERSION sera égale à 1 et pour les autres elle vaudra 0. C’est le mode pris pour l’ensemble des tables ROSTAM pour lesquelles une notion de remise est présente. On remarque que cette variable est caractère (un « A » au niveau de la colonne). Il aurait été plus judicieux de la mettre en format numérique d’un bit.
En réalisant un filtre sur l’échéance (ECHEANCE_TAB) et sur la source (SRC_ID), on extrait les données d’une collecte sur une échéance précise.
La table V_FCT_FAIT (cf. Figure 35) stocke les données des collectes de la DGS utiles pour réaliser ses chaînes statistiques. C’est « la table de fait » du modèle en étoile de la base ROSTAM. Par contre, selon les collectes, ce ne sont pas, ni les mêmes périodes, ni le même niveau de granularité, ni les mêmes indicateurs. Il est donc difficile d’identifier clairement le fait que stocke cette table. Nous pouvons dire qu’elle stocke le fait de déposer une remise sur une échéance donnée. Ce choix de stockage unique sera discuté dans le chapitre.
La mise en œuvre du modèle étoile de la base de données ROSTAM ». Pour le traitement de l’usure, « le fait » est d’accorder un crédit. Il y a donc une ligne par crédit. Les indicateurs remontés sont, par exemple, le revenu annuel de la personne (ou foyer) ayant contracté le crédit et le montant du crédit.
Identification de la catégorie d’usure du crédit
Comme dit précédemment dans le chapitre « 6.3 Analyse », l’identification des catégories de crédit de l’usure étant réalisée en ligne de programmation, j’ai décidé de la réaliser dans une table SAS de paramètres (cf. Figure 45) afin d’améliorer le suivi et le lancement de période passée. Cette table SAS contiendra l’ensemble des caractéristiques qui identifie les catégories de crédit de l’usure avec une notion de date de validité. Une catégorie, à un instant donné, est définie par une unique ligne dans la table. Chaque caractéristique d’un crédit est stockée dans une colonne. Si le contenu de la table doit évoluer (par un décret de Loi), un programme ad-hoc sera alors développé pour la mettre à jour. Il n’a pas été choisi de réaliser un programme de mise à jour automatique au vu de la faible fréquence de modification.
Conception de l’envoi des données résultats à ROSTAM
Une fois les données résultats de l’usure validées par le métier, les données sont transmises à ROSTAM via EAI. L’EAI mis en place prend un fichier ZIP en entrée. J’ai choisi de créer ce fichier avec une procédure stockée SAS.
L’utilisateur renseigne uniquement le processus de calcul sur lequel se baser. En effet, plusieurs étapes de calcul peuvent être lancées. Il faut donc en choisir une. La mise en place de EAI est sous la responsabilité de l’OI, j’ai celle de déposer un fichier ZIP (dont le contenu est formalisé) dans un endroit précis.
Conception du modèle en étoile ROSTAM
Je ne participe pas à la conception de ce modèle en étoile. Je participe uniquement à son analyse. Mais afin de comprendre sa structure, j’ai reconstitué un extrait simplifié du modèle de données des principales tables qui sont utilisées dans les traitements SAS (cf. Figure 37).
|
Table des matières
1 INTRODUCTION
2 PRÉSENTATION DE L’ENTREPRISE
2.1 LA BANQUE DE FRANCE
2.2 LA DIRECTION GENERALE DES STATISTIQUES
2.3 LA DIRECTION DE L’INGENIERIE ET MAITRISE D’OUVRAGE STATISTIQUES
2.4 LE SERVICE DES PROJETS ET MAINTENANCES STATISTIQUES
2.5 ENVIRONNEMENT INFORMATIQUE DE TRAVAIL
2.5.1 LE LOGICIEL SAS
2.5.2 LE LANGAGE R
3 PROBLEMATIQUE
3.1 MIGRATION DE LA CHAINE DECISIONNELLE DU CALCUL DES TAUX D’USURE
3.2 PROPOSITION DE METHODOLOGIE DE MIGRATION DE SAS VERS R
4 PRESENTATION DU TAUX D’USURE
4.1 DEFINITION
4.2 LA COLLECTE DES DONNEES
4.2.1 LE PORTAIL ONEGATE
4.2.2 LE FICHIER DE COLLECTE M_CONTRAN
4.3 ORGANISATION DE LA CHAINE SAS DU CALCUL DU TAUX D’USURE
5 CONNAISSANCES THEORIQUES
5.1 EAI
5.1.1 OBJECTIFS
5.1.2 LE TRANSPORT
5.1.3 LES CONNECTEURS APPLICATIFS
5.1.4 LE MOTEUR D’INTEGRATION
5.1.5 LES DIFFERENTES ARCHITECTURES
5.1.6 LES DIFFERENTES INTEGRATIONS
5.2 LA CHAINE DECISIONNELLE
5.2.1 LE SCHEMA DECISIONNEL
5.2.2 LES DONNEES SOURCES
5.2.3 LES METADONNEES
5.2.4 L’EXTRACTION
5.2.5 L’INTEGRATION
5.2.6 L’ENTREPOT DE DONNEES : DATA WAREHOUSE
5.2.7 LE MAGASIN DE DONNEES : DATAMART
5.2.8 DIVERSES ARCHITECTURES POSSIBLES
5.2.9 MODELE OLAP
6 MIGRATION DE LA CHAÎNE DECISIONNELLE DU CALCUL DU TAUX D’USURE
6.1 CAHIER DES CHARGES
6.2 PLANNING DU PROJET
6.3 ANALYSE
6.3.1 ANALYSE DU MODELE DE DONNEES ROSTAM
6.3.2 ANALYSE DES EVOLUTIONS SAS
6.3.3 CHAINE DECISIONNELLE PROPOSEE
6.4 CONCEPTION
6.4.1 CONCEPTION DE L’EXTRACTION DES DONNEES DE COLLECTE
6.4.2 CONCEPTION DU NOUVEAU MODE DE LANCEMENT DE LA CHAINE SAS DE L’USURE
6.4.3 CONCEPTION DE L’ENVOI DES DONNEES RESULTATS A ROSTAM
6.4.4 CONCEPTION DU MODELE EN ETOILE ROSTAM
6.5 IMPLEMENTATION
6.5.1 LES DIFFERENTS ENVIRONNEMENTS
6.5.2 STOCKAGE DES DONNEES SAS INTERMEDIAIRES ET RESULTATS
6.5.3 NOUVEAU MODE DE LANCEMENT DE LA CHAINE DE CALCUL DES TAUX D’USURE
6.5.4 ADAPTATION DE L’ETAPE DE CHARGEMENT
6.5.5 ADAPTATION DE L’ETAPE DE CONTROLE
6.5.6 L’ETAPE D’ECRETAGE
6.5.7 L’ETAPE DE CALCUL
6.5.8 ENVOI DES RESULTATS A ROSTAM
6.6 VALIDATION DES RESULTATS
6.7 CHARGE POUR LES EVOLUTIONS SAS
6.8 DISCUSSION DES CHOIX
6.8.1 LE CHOIX DE L’EAI POUR LE TRANSFERT DES DONNEES DE SAS A ROSTAM
6.8.2 LA MISE EN ŒUVRE DU MODELE ETOILE DE LA BASE DE DONNEES ROSTAM
6.8.3 DES DEFINITIONS DE VARIABLES NON ADAPTEES DANS LA BASE DE DONNEES ROSTAM
6.8.4 LES CONTROLES SAS D’ENVOI DES DONNEES A ROSTAM
7 PROPOSITION DE METHODOLOGIE DE MIGRATION DE SAS VERS R
7.1 CONCEPTION D’UN OUTIL D’ESTIMATION DE CHARGE DE MIGRATION
7.1.1 LE CONCEPT GENERAL
7.1.2 DEFINIR LES INDICATEURS POUR REALISER L’ESTIMATION DE CHARGE
7.1.3 ÉTABLIR LA NOTE DE COMPLEXITE ET L’ESTIMATION DE CHARGE
7.1.4 CHOIX TECHNIQUE
7.2 IMPLEMENTATION DE L’OUTIL D’ESTIMATION
7.2.1 IDENTIFICATION DES PROGRAMMES A ANALYSER
7.2.2 ANALYSE DU CONTENU DES FICHIERS
7.2.3 IMPORTATION DES RESULTATS D’ANALYSE ET CALCUL DE L’ESTIMATION
7.2.4 MISE EN FORME DES RESULTATS D’ESTIMATION
7.3 LES LIMITES DE L’OUTIL D’ESTIMATION
7.4 IDENTIFICATION DU PARC DE MIGRATION
7.5 LA CONDUITE DU CHANGEMENT 120
8 CONCLUSION
BIBLIOGRAPHIE
ANNEXE
RÉSUMÉ
MOTS CLÉS
ABSTRACT
KEY WORDS
