CV/Mission d'Ingénieur decforms freelance

Exemple de missions d'Olivier,
Ingénieur decforms habitant le Val-de-Marne (94)

• Oracle PL/SQL ClearCase DCL Cobol

  (OCSI) Mission HSBC France DMTC/ BACK OFFICE
  2007 - 2008

  MOE/MOA sur une Application VMS/Cobol : SGS.
  Mission en tant que Ingénieur d’études sur l’application BACK OFFICE qui permet de traiter l’ensemble des Swaps de Taux du DMTC HSBC provenant du FRONT OFFICE (Summit)
  SGS permet ainsi de processer l’ensemble des Deals Swaps pour l’envoi des Annonces, des Confirmations et des Paiements(sous forme de Format Pseudo Swift)& In Fine la Comptabilité avec la génération des CROS & des CRIS en destination de RDJ.
  
  MOE/MOA sur une Application VMS/Cobol : SGT.
  Mission en tant que Ingénieur d’études sur l’application BACK OFFICE qui permet de traiter l’ensemble des Dépôts Emprunts du DMTC HSBC provenant du FRONT OFFICE (FTC application maison)
  SGT permet ainsi de processer l’ensemble des Deals de Prêt Emprunt pour l’envoi des Annonces, des Confirmations et des Paiements(sous forme de Format Pseudo Swift)& In Fine la Comptabilité avec la génération des CROS & des CRIS en destination de RDJ.
  
  Gestion de Projet sur une Mise en place d’un Portail Swift : GSW.
  Mission en tant que Chef de Projet sur l’étude de faisabilité et du besoin Client concernant l’implémentation d’un Portail Swift générique permettant de transcoder n’importe quelle source en Entrée sous la forme d’un Swift paramétré. GSW a pour objectif d’éliminer la granularité des Process DMTC qui ont pour but la génération d’un Swift en fonction du périmètre considéré (Quatre Applications seront décomissionnées par GSW).
  • Etude de faisabilité, Etude des besoins utilisateurs et du Back Office.
  • Création de la Base de Données GSW SGBDR Oracle 10G
  • Maintenance de l’IHM & Traitements SGS/SGT sous Cobol DecForms.
  • Développement de l’ensemble des procédures Stockées (Oracle 9) servant à la Génération des Cris SGS & SGT.
  • Support MOA/Production.
  • Mise en Place des Procédures de Suivi et de Support Client.
  • Refonte complète des Environnements de Développements et de Tests.
  • Développement de Batchs en DCL (Vax VMS) afin d’établir des Reportings d’Audit sur les référentiels des Contreparties & des Circuits de Règlement.
  • Etude de Faisabilité, puis mise en Place de l’architecture Process
  GSW Portail Gate Swift.
  • Mise en Place de l’Interface de communication entre SGT et le Front Office Prêt Emprunt FTC.
  • Amélioration des Performances Oracle (Tuning), sur les Reportings Clients et les procédures stockées. Portage des traitements de transcodifications Clients vers des traitements traités par le serveur uniquement.
  • Rédaction de la documentation Utilisateurs. Documentation pour Déploiement du Client & pré requis sur Postes Clients 2000 IMAGE, Mise en Place d’une FAQ SGS/SGT.
  • Utilisation de ClearCase afin de gérer le versioning du code et la compilation et le Link des exécutables Cobol.

• Aura Group) Mission BNP/PARIBAS Arbitrage BACK OFFICE
  2001 - 2006

  Visual Fox Pro6, MSQL Server 2000, Businees Objects, IntelliJ Idea, Java
  Gestion de Projet sur une Application Client/Server : AGORA.
  Mission en tant que Ingénieur d’études, puis Chef de Projet sur l’application BACK OFFICE qui permet d’intégrer tous les flux typés Marchés Organisés (Deals & Positions) provenant du FRONT OFFICE (EAI) ainsi que de toutes les sources Brokers de BNP PARIBAS Arbitrage.
  Agora permet également de mettre à jour ces différents flux au travers des modules de transcodifications génériques s’appuyant sur l’ensemble des référentiels du Back OFFICE.
  L’application est également un Outil de réconciliation entre les flux de même périmètre, un gestionnaire de suivi des Ecarts.
  Les flux, une fois alignés sur le référentiel BACK OFFICE, rapprochés et validés, seront transférés vers les Outils BACK OFFICE : CALYPSO & UBIX.
  La dernière fonctionnalité d’AGORA est un Module de suivi des Ecarts de Positions entre le BACK OFFICE et le FRONT OFFICE. L’outil va permettre de réconcilier des écarts grâce à un moteur de critères de rapprochement moins restrictifs, de typer ces mêmes écarts. Le reporting résultant d’AGORA sert à communiquer aux MIDDLE OFFICE les Risques Business issus des Ecarts Fonctionnels/structurels entre le BACK & le FRONT.
  • Etude de faisabilité, Etude des besoins utilisateurs et du Back Office : Mise en Place d’une Architecture Composant/Objet où chacune des entités fonctionnent indépendamment des autres existantes : l’objet Alimentation, Correspondance, Contrôles, Mise A Disposition & Rapprochement. Choix de la souplesse d’utilisation de chacun des composants :
   l’Objet Alimentation a la particularité de pouvoir effectuer des filtres internes sur son propre périmètre.
  Une première étape de transcodification peut déjà avoir lieu au sein même de l’alimentation évitant ainsi la surcharge de composants Correspondance liés à cette même alimentation. Cet objet intègre n’import quel flux de type fichier (flat files), SQL (SQL Server, Oracle….), tables FOX PRO, Fichiers XLS.
  l’Objet Correspondance est caractérisé par deux fonctionnalités distincte : la correspondance de valeurs permettant de transformer une valeur A en une valeur B en pivotant via le référentiel source, et la correspondance de champs permettant d’enrichir le flux d’entrée issu de l’alimentation via les référentiels Back Office. Le référentiel propre au Processus Agora est auto-feedé par des alimentations paramétrées en conséquence.
  l’Objet Contrôle est le composant qui verifiera la qualité des informations présentes dans le flux considéré via à un gestionnaire de règles (également entièrement indépendant)
  l’Objet Mise A Disposition est le composant qui permettra le transfert d’un flux de données nettoyé et cohérent vers le système cible voulu (soit l’outil Back Office interne, soit vers CALYPSO, soit vers UBIX).
  l’Objet Rapprochement est le composant qui définira l’ensemble des Flux à matcher avec un autre ensemble de flux. Le choix de la granularité du périmètre de rapprochement est totalement ouvert : soit le rapprochement concernera des flux de même nature métier/activités, soit des flux partiellement compatibles, soit n’importe quel type de flux
  L’étude s’est focalisé sur la mise en place d’un système au maximum générique & paramétrable nécessitant aucune intervention de la part de la MOE.
  • Création via POWER AMC de la Base de Données SGBDR MS SQL SERVER 2000
  • Développement de l’IHM & Traitements du Client (Alimentations/Transcodifications) sous Visual FOX PRO 6 : Utilisation de la couche Objet/Classe de VFP avec notion d’héritage et de polymorphisme.
  • Développement de l’ensemble des procédures Stockées (SQL SERVER) servant au module de Réconciliation : toute la partie exécution des réconciliations de l’objet Rapprochement s’effectue via des procédures stockées. Elles connaissent toutes le même squelette, seuls les critères et le netting évoluent pour chacune d’elles. L’application gère via l’IHM le choix ainsi que l’appel du modèle désiré : le paramétrage permet ainsi de choisir sa réconciliation en fonction des besoins fonctionnels. Chaque objet Rapprochement peut contenir X objets Procédures Stockées.
  • Développement de l’ensemble des Reportings Crystal Report permettant d’imprimer les hypothétiques Rejets/Ecarts lors de l’exécution des objets Rapprochements/ Correspondances/ Contrôles. Avec la même logique de construction du Process, un objet Report, indépendant, permet de lancer le Build du reporting. De même, via l’IHM et par essence via le paramétrage, l’utilisateur choisit le reporting qui lui semble adéquat à n’importe quel endroit de la chaîne du process.
  • Mise en place d’un référentiel interne au process lui-même afin de pouvoir nettoyer les flux entrant de système externe (Clearers, Brokers, Middle office) : Titres, Agents négociateurs, Dépositaires, Portefeuilles, Contrats Dérivés…..La tenue à jour du référentiel se fait via le process lui-même en utilisant les objets Alimentations qui vont nourrir les Master Data fonctionnelles du process.
  • Développement d’automates Intégration & Réconciliation en VFP6 : les automates tournent 22 heures / 24. Chacun des traitements à lancer (Fichiers & SQL pour la partie Intégration-Transcodification et Rapprochements pour la partie Réconciliation) connaît des bornes horaires dans lesquels il est susceptible d’être exécuté si l’ensemble des pré-requis est respecté. En cas d’échec de l’exécution d’un des traitements, un message est envoyé via des trappes SNMP à l’Exploitation IT afin d’avertir la MOE/MOA d’un hypothétique problème. Les automates passent aux traitements suivant et réessaieront d’exécuter à nouveau le traitement défectueux lors du cycle suivant.
  • Support MOA/Production : Conseil & Paramétrages effectués au niveau des Equipes MOA & Assistance Utilisateurs. Mise en place de WorkShop/Formations des différents intervenants sur le Process Agora.
  • Développement de Batchs en VFP6 d’Extraction de Données Statistiques puis Mise en Place de Documentations fonctionnelles/Pré Requis pour la prise en Charge des Chaînes par DOLLAR Universe en corrélation avec les jobs/batchs de BackUP à froid de la Database et des Jobs d’extractions de Données Statistiques à Destination des Responsables d’Equipes Back Office & Middle Office.
  • Etude de Faisabilité, puis mise en Place de l’architecture Process de Communication entre AGORA et l’EAI FRONT OFFICE : l’interface choisie a été une table SQL Server faisant parti de notre schéma de Base. Ecriture de l’ensemble de procédures stockées Insertion, Suppression, Modification d’évènements/Messages STP provenant de l’EAI. Mise en place des process de purge et Recalcul d’index, entretien de la table avec les équipes DBA/IT.
  • Mise en Place de l’architecture de communication entre AGORA et les nouveaux systèmes BACK OFFICE UBIX (dérivés) & CALYPSO (actions & Warrants). Workshops organisés au travers des différentes équipes BAPI, EAI, UBIX, CALYPSO, Gestionnaires Back Office Marchés ..