PROJET MIGRATION DES DONNÉES AppliFrais
publicité
PROJET MIGRATION DES DONNÉES AppliFrais Propriétés Description Intitulé Réimplantation des données de l’ application de gestion des frais de déplacement (AppliFrais) sur un nouveau SGBD. Présentation Rapide L'application permet d'établir une gestion précise et uniforme entre les entités concernées du laboratoire. Positionnement >>>> Durée estimée en heures 16 heures Savoir-faire SI mobilisés en priorité Les savoir-faire de la phase d'étude du projet, auxquels s'ajoutent : SI3 - Extraire et modifier les données d’une base de données SI3 - Implémenter une base de données à partir d’un schéma existant SI4 - Programmer à l’aide d’un langage de programmation structurée SI4 - Programmer en utilisant des classes d’objet fournies SI4 - Appliquer des normes de développement SI6 - Valider et documenter une application SI6 – Mettre à jour une documentation technique SLAM1 – Modifier un schéma de données et l’implantation de la base de données correspondante SLAM1 – Utiliser un outil de génération et de rétro-conception de base de données SLAM1 – Adapter une application exploitant une base de données à l’évolution de son schéma SLAM2 – Mettre au point un programme Notions EDM Documents joints Cahier des charges, base de données exemple et scripts de génération de contenu de test, application AppliFrais en son état de développement initial. Modalités de réception Production d'un procédé opérationnel, éprouvé et testé - recette Équipes Par équipe de ... 2 3 4 Planning http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 1/3 CAHIER DES CHARGES Définition du besoin Définition de l'objet Le suivi des frais est actuellement géré par le biais de l’application AppliFrais en son état initial de développement. Cette application exploite une base de données relationnelle MySQL. Bien que libre et gratuit, le SGBD MySQL n’entre pas dans la politique actuelle des produits recommandés par le schéma directeur. Le laboratoire Galaxy Swiss Bourdin, par son cœur de métier gros consommateur de données, est lié depuis de nombreuses années avec le fournisseur Oracle Corp, éditeur du SGBD Oracle. Pour cette raison, pour tout développement pérenne où une base de données relationnelle est utilisée la politique interne recommande d’utiliser Oracle comme SGBD support. En effet, une infrastructure de serveurs Oracle dédiés est disponible sur le réseau quelque soit le site. Par ailleurs, les compétences nécessaires à l’administration et à l’exploitation des bases de données Oracle sont aussi présentes au sein de l’entreprise. Sans compter le contrat de support qui permet à l’organisation d’escalader les dysfonctionnements non résolus localement auprès des spécialistes chez le fournisseur lui-même. Forme de l'objet Le module Visiteur de l'application Web Applifrais est en ligne, accessible depuis un ordinateur. Le code source correspondant à ce module ainsi que sa base de données sont fournis en complément de façon à pouvoir mettre au point un procédé de migration éprouvé, testé sur une copie opérante et représentative de l’objet réel. Le module Comptable de cette même application, et dont le développement est encore en cours, est aussi concerné par cette étude du fait qu’il partage la même base de données. Si ce module impacte la structure de la base de données, il sera nécessaire d’en tenir compte. Besoin complémentaire Afin d’améliorer certains traitements mais aussi de permettre un contrôle des données après enregistrement, il est attendu que trois procédures stockées soient développées (ici des fonctions). Pour une fiche de frais donnée, elles auront pour objet respectif de calculer : le montant total des frais hors forfait ; le montant total des frais forfaitisés ; le montant total à rembourser de la fiche. Contraintes Architecture L’architecture applicative demeurera intacte et l’application ne devra être modifiée qu’à la marge afin d’éviter tout effet de bord mal contrôlé et toute remise en cause forte de l’existant. Par modifications à la marge, il faut entendre : Modifications des éléments de configuration qui permettent à l’application d’atteindre la base de données sur le réseau Galaxy Swiss ; Modifications liées à d’éventuelles retouches faites à une structure de base de données jugée déficiente (pertinence à justifier) ; Modifications liées à la centralisation de certains traitements qu’Oracle rendra possible par l’emploi de triggers et/ou procédures stockées (pertinence à justifier). Les spécifications des cas d’utilisations demeureront impérativement inchangées. Jeu de caractères La base de données une fois migrée sous Oracle devra être encodée en UTF-8 pour préserver les capacités à faire évoluer l’ensemble dans la modernité du moment. Les données ne devront subir aucune altération durant le procédé de migration. http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 2/3 Environnement Dans l’environnement Oracle, l’outil à privilégier pour mettre au point puis opérer la migration est SQL Developer, édité par Oracle Corp. Documentation La documentation devra présenter la nouvelle structure de la base de données implantée sous Oracle. Une attention particulière sera portée sur le descriptif détaillé des changements entre l’ancienne base et la nouvelle. L’impact individuel de chacun des changements sera aussi à décrire. Responsabilités Le commanditaire fournira à la demande toute information sur le contexte nécessaire à la production de l'application. Le commanditaire fournira une documentation et des sources exploitables pour la phase de test : base de données exemple, modélisation, etc. Le prestataire est à l'initiative de toute proposition technique complémentaire. Le prestataire fournira : un procédé de migration opérationnel ; un rapport de tests témoignant du caractère opérationnel o de la migration ; o de l’application après migration ; une documentation technique spécifiant les caractéristiques de tous les changements opérés ; Structure de la base de données initiale http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 3/3
