RAPPORT DE STAGE :ADONIS   : Une application intranet   de suivi des demandes d’évolution

http://www.math-info.univ-paris5.fr/ISASH/insertion/insertion_stage/insertion_stages.htm

REMERCIEMENTS

RESUME

SOMMAIRE

INTRODUCTION

Le présent document se rapporte au stage de formation professionnelle effectué du 05 Avril au 11 Juin 2004 à ORANGE FRANCE. Il entre dans le cadre de ma formation au DUT Informatique à l’IUT d’Orsay. Ce stage s’est déroulé au sein du service CRM GP - FORS, situé dans les Bureaux d’ORANGE à Issy les Moulineaux. Je l’ai effectué en binôme avec Samy DOUILLARD, un autre étudiant de l’IUT.Ce stage est sous la responsabilité de Jean RIVOALLAM, Directeur projet dans ce service. Nos tuteurs de Stage sont Sylvain GOLDBERG pour les questions Fonctionnelles et Dominique POITEVIN pour la partie technique.

Ce rapport présente dans une première partie la société ORANGE et le service CRM GP – FORS. Une seconde partie décrit le sujet de ce stage, les objectifs et le matériel utilisé. Et, enfin, la dernière partie explique en détail et de manière technique le travail effectué au cours du stage.

Présentation du stage dans le cadre de la formation à l’iut Présentation succincte de l’entreprise : cadre spatio-temporel Ou je me situais dans cette société (très brièvement) Le projet confié : Adonis, le définir en quelques lignes

- 1 -

I – PRESENTATION DE L’ENTREPRISE

1. La Société Orange   :

France Télécom est aujourd'hui un des principaux opérateurs mondiaux de télécommunications.

Présent principalement dans le domaine de la téléphonie fixe, France Télécom avec ses 150 000 collaborateurs, a réussi le pari de s'ouvrir à l'international et à de nouveaux usages de télécommunication : mobile, internet et services de données.

Il est au deuxième rang dans le domaine de l'internet (Wanadoo, freeserve, Oléane...) et figure parmi les leaders de services de télécommunications aux entreprises (Equant).

C’est avec l’acquisition d’Orange que France Télécom est devenu le troisième opérateur mobile mondial.

Voici un Historique de l’évolution de la société Orange   :

Avril 1994 : Orange est lancé au Royaume-Uni et devient ainsi le quatrième opérateur de téléphonie mobile sur le marché britannique.

Mai 2000 : France Telecom rachète Orange, une entreprise et une marque synonymes de réussite et de dynamisme.

Août 2000 : Création de la holding Orange, société française qui siège à Londres.

Février 2001 : Introduction en bourse d'Orange.

Printemps 2001 : France Telecom décide de regrouper sous la marque Orange l'ensemble de ses activités mobiles implantées en France et dans le monde.

Juin 2001 : Lancement de la marque Orange en France : Itinéris, OLA et Mobicarte deviennent Orange.

- 2 -

Décembre 2002 : Pour reprendre en main son destin, France Télécom lance Ambition FT 2005, à l'issue d'une revue complète de l'activité et des aspects financiers du groupe présenté lors du Conseil d'Administration du 4 décembre 2002.

Aujourd’hui, le Groupe Orange c’est   :

500 millions de personnes couvertes dans plus de 20 pays.Le numéro 2 en EuropeLe numéro 3  mondialPlus de 43 millions de clients.30000 salariés.Un parc de 36,5 millions de clientsUn marché potentiel de 490 millions d’utilisateurs

Aujourd’hui, Orange France c’est   :

Le 1er opérateur de téléphonie mobile français (48 % de parts de marché)7500 salariés dont 4500 en unités opérationnelles répartis sur 20 villes et

plus de 30 sites 68 % de part de marché mobile "entreprises" en France7000 collaborateurs 13 centres de service clients 8 unités nationales réseau + 2 unités nationales service 4 directions des ventes régionales Le meilleur réseau selon l’ART en terme de qualité (vocale, trafic..) et de

couverture Un chiffre d’affaires de 5,7 milliards d’euros en 2000

Les principes fondamentaux d’Orange sont basés sur cinq piliers : un réseau de haute qualité, des services faciles à utiliser, un bon rapport qualité et prix, un service de qualité exceptionnelle procuré à la clientèle, et les personnes qu’il faut pour faire bénéficier le client de tous ces avantages.

Forte de sa capacité à innover, Orange s’engage dans le futur avec le développement du multimédia mobile, du GPRS et bientôt l’apparition de l’UMTS. Le groupe Orange à la conviction que le terminal mobile deviendra très vite un outil personnel de communication qui, au-delà des communications vocales, permettra

- 3 -

l’accès aux services multimédia comme la visiophonie, l’Internet, le commerce électronique …

Demain, le groupe Orange vise une implantation dans plus de 50 pays.

2. Le service CRM GP - FORS   : Moe, Moa, logitiels développés …

Orange France peut se diviser en 13 services :

Direction FinancièreDirection du ManagementDirection de la Stratégie et de la MarqueDirection Technique Réseau et Services (DTRS)Direction Relations ClientsDirection Marchés Grand Public et ProfessionnelsOrange DistributionDirection Marché EntreprisesDomaine Radio Access NetworkMobile et PermissionOrange Business Management TeamOrange RéunionOrange Office

- 4 -

Organigramme pour nous situer dans la société au sein du CRM GP :

- 5 -

Q ualitéLuccas Biscroma

(Partage CRM /Com)

Budget / Reporting

Patrick Agnès (1/2)

Concepteur Fonctionnel

F ré d éric B on

Concepteur Fonctionnel

P a sca l D e la ig ue

Concepteur Fonctionnel

S e rva n e D ug ue

Expert Fonctionnel

F a bie n S a m son

Concepteur FonctionnelE . K ara s inska -> 1 /6

Concepteur Technique

L a ure n t G iova nn e lli

Cohérence Fonctionnelleet Technique

Coaching

C h ris tia n P IN V IL LE

RealeasesJé rôm e G a nd o lph e -

Je a n -F ra n ço is M o u ra -M ich a ë l N a vo n -

CRM

Sylvain Goldberg

ORANGE FRANCE

Direction Technique Réseau et Services, René LE GAL

Front Office Relation Services, Denis PALAZO

Direction du développement et des services, Lucien DUCORNEY

Customer Relationship Management – Grand Public, Jean RIVOALLAM

Stagiaires

Guillaume MIGEON

Samy DOUILLARD

Le service Informatique d’Orange a plusieurs taches :

Activer les comptes de nos clients, assurer une facturation sans failleFournir aux conseillers l’ensemble des informations qui permettent

d’apporter un service de qualité à nos clientsAccompagner les fonctions de l’entreprise dans l’optimisation de leur gestion

Ce service est

3. Ma position au sein de ce service, mon poste

4. La manière de mener un projet chez Orange

- 6 -

II – PRESENTATION DU PROJET : ADONIS

1. Présentation de l’application ADONIS   :

Les services clients Orange sont disponibles 7 jours sur 7, 24 h/ 24. Les conseillers clients ont à leur disposition de logiciels leur permettant de présenter et valoriser les offres et services, apporter des conseils et accompagner les clients aux usages de leur mobile.

Ces logiciels, développés par Orange, sont donc utilisés des milliers de fois chaque jour. Afin d’adapter ces logiciels à cette utilisation intensive, les centres de services « Client » transmettent aux centres de développement des « demandes d’évolution ». C’est à dire qu’ils précisent, dans des cahiers des charges, toutes les modifications à apporter pour que le logiciel corresponde le mieux aux besoins des conseillers.

Toutes ces « demandes d’évolution » n’ont pas la même importance et sont ainsi incorporées dans les futures « releases » (versions) des logiciels selon la priorité qui leur est accordée.

A chaque demande d’évolution correspond un ensemble de documents, aussi bien produits par la maîtrise d’œuvre, la maîtrise d’ouvrage ou l’intégrateur. Un même document peut être rattaché à plusieurs demandes d’évolution.

Une demande d’évolution peut reprendre plusieurs anciennes demandes et ainsi les regrouper en une seule.

Dans le service CRM GP, toutes ces demandes d’évolution nécessitent d’être enregistrées dans une base de donnée afin d’assurer leur suivi.

Il y a peu encore, elles étaient centralisées dans une application Access intranet. Possédant une centaine de tables, elle regroupait aussi toute une partie consacrée au Budget du service. Cette application est qualifiée de « client lourd ». Constituée d’une suite de formulaires Access, elle est assez peu ergonomique et parfois jugée trop complexe par les utilisateurs.

Le but d’ADONIS est de supplanter cette application Access peu adaptée au profit d’un « client léger ». Se basant sur un modèle de données simplifié, une ergonomie plus adaptée et des traitements plus légers, ADONIS ne se charge uniquement de la partie « Demandes d’évolution » de l’ancienne application Access.

- 7 -

ADONIS est accessible directement à partir d’un navigateur internet à travers le réseau intranet d’Orange. Cette application est particulièrement adaptée à Explorer v 5.0 ou ultérieur.

Voici quelques captures d’écran de l’ancienne application Access :

Menu principal :

formulaire de recherche d’une demande d’évolution :

- 8 -

formulaire de saisie et d’affichage d’une demande d’évolution :

formulaire d’affichage des documents (ici les documents MOA) :

- 9 -

Formulaire de saisie des documents (ici les documents MOE) :

2. Le travail demandé   :

Le projet ADONIS a déjà été débuté par deux stagiaires au début de l’année scolaire 2003. A la fin de leur stage, la première version d’ADONIS avait vu le jour.Cependant, elle comportait des bugs, des soucis d’optimisation et ne correspondait pas tout à fait aux attentes des utilisateurs.

Les utilisateurs de cette première version d’ADONIS ont rassemblé les anomalies rencontrées et les demandes d’évolution souhaitées. La majorité d’entre elles touchait à l’ergonomie de l’application.

L’optique de notre stage était donc de procéder le plus rapidement possible à la « mise en production » d’ADONIS afin d’être présents lors des tests de celle-ci par les utilisateurs. Nous étions ainsi à même d’écouter leurs attentes et de procéder aux modifications nécessaires. Cette phase de production s’effectuerait en « double saisie » à la fois dans l’application Access et ADONIS afin de ne risquer aucune perte de données.

Il fallait par la suite réécrire certaines méthodes dans le cadre de la phase de « Fiabilisation et d’Optimisation » d’ADONIS. Enfin, si le temps le permettait, nous

- 10 -

devions implémenter une interface entre ADONIS et PHP Project, un outil de gestion de projet utilisé par le CRM GP.

Nous devions donc procéder à ces différents points :

La migration de la BD Access vers la BD MySql d’ADONISL’implémentation des évolutions attenduesLes tests sur le serveur de recettesLa mise en production en « double saisie »Fiabilisation et Optimisation d’ADONISInterface entre ADONIS et PHP Project

3. L’environnement Technique   :

3.1.La technologie Utilisée pour ADONIS :

Comme dans bon nombre d’applications intranet Orange, la technologie JAVA est utilisée. ADONIS est donc basée sur la technologie « Servlets - JavaBeans – Jsps ».L’utilisation du PHP aurait pu être tout aussi profitable mais nous n’avions pas le choix de la technologie : l’application était déjà éxistante.

Voici une description simplifiée de cette technologie :

Les Jsps sont des pages web contenant du code JAVA et HTML et qui, une fois compilées, permettent d’être lues par les différents navigateurs comme du code HTML.

Les JavaBeans sont des classes JAVA utilisées pour encapsuler les données sous forme d’objets. Elles peuvent être appelées à partir des Jsps ou à partir d’autres classes JAVA.

Les Servlets sont des classes JAVA étant capables de récupérer les données transmises par le navigateur aux pages Jsps. Elles peuvent ensuite traiter ces informations, les insérer dans une base de données ou renvoyer d’autres informations au navigateur.

- 11 -

3.2. Installation et outils :

Comme toute application Orange, ADONIS était basée sur deux serveurs distincts :

Le serveur de recettes qui est le serveur permettant de tester et de débuguer une application. Les modifications peuvent se faire directement sur ce serveur.

Le serveur de production qui est le serveur contenant une version de l’application destinée à l’intranet Orange et ses utilisateurs respectifs. Aucune retouche directe n’est effectuée. Seules les versions d’applications déjà testées et qui fonctionnent sont mises en place.

Ces machines tournent sous Linux et hébergent chacun un serveur Apache (Jakarta TOMCAT). Les données sont stockées dans une base de donnée Mysql qui a l’avantage d’être un SGBD « open-source » performant. Nous utilisions la base de données en mode ligne de commande.

Nous travaillions sur deux postes Windows NT reliés à l’intranet Orange. Nous nous connections au serveur de recettes via une connexion SSH lancée à partir d’un émulateur de console Linux (Putty).

Un serveur CVS était implanté sur le serveur de recettes pour nous permettre de travailler en parallèle sur deux copies d’ADONIS, tout en étant sûrs de les garder constamment à jour.

Les éditeurs utilisés étaient « Vi » pour les sources de l’application et « Word » pour les documents de celle-ci.

Nous compilions directement sur le serveur avec « Ants » , un outil de compilation des sources java servlets et jsp.

- 12 -

Schéma de l’installation technique :

Tous les utilisateurs de l’intranet Orange pouvaient se connecter en http sur les serveurs et ainsi accéder à la page d’accueil d’ADONIS. Cependant, Adonis nécéssite la possession d’un compte utilisateur pour être utilisé.

Nous pouvions nous logger en tant que root sur le serveur de recettes afin d’accéder au cvs, à la base de données MySql et au système pour faire la relance du serveur Apache … Cependant, nous ne pouvions pas accéder au serveur de production autrement que par http.

- 13 -

SSHHTTP

HTTP

SSHSSH

Poste NT Poste NT

INTRANET ORANGE

Hi SamSam !

Login : AdonisPass : *****> wrong pass !

Hi Guillom !

Login : AdonisPass : ******> Connecting..

Serveur de Production Serveur de

Recettes

ADONISADONIS

CVS

… MySql

UTILISATEURS

MySql

…

…

INTERNET

III – DEROULEMENT DU STAGE

Le stage a connu un tournant imprévu : les objectifs à remplir ont changé suite à des problèmes majeurs rencontrés lors de la double saisie fin Avril. Notre stage s’articule donc autour de deux grandes étapes.

Lors de la première phase, la relance de l’application, nous devions remettre ADONIS en production dans les plus brefs délais. Nous devions traiter les demandes d’évolution (DE) suivant leurs importances respectives. Ne pouvant pas avancer sur plusieurs pôles simultanément, nous avons décidé, avec Samy de travailler en binôme lors de l’implémentation des évolutions et des tests.

C’est lors de la deuxième phase, la refonte totale d’ADONIS, que nous avons avancé chacun sur des pôles différents. Il fallait avancer rapidement en restant cohérents avec notre analyse. Le fait de connaître réciproquement nos méthodes de travail nous a fait gagner du temps.

1. Première phase   : Relancer une application existante   :

1.1. Etude préalable

Tout d’abord, il a fallu que je me familiarise davantage avec la technologie Servlets-Jsp JAVA que nous avions déjà étudiée brièvement à l’IUT.

La première approche de l’application fut la consultation du manuel utilisateur et administrateur de celle-ci. Ces manuels m’ont appris qu’elles étaient précisément les fonctions d’ADONIS ainsi que leurs modes de fonctionnement. Le manuel administrateur expliquait aussi comment relancer le serveur et compiler les sources à l’aide d’Ants.

Puis, j’ai étudié les codes source d’ADONIS, essayant de comprendre les algorithmes principaux et de retrouver les différents liens entre les classes. Ce n’était pas évident de m’y retrouver dans leur méthode de coder bien différente de la mienne.

- 14 -

N’ayant pas les documents de leur analyse, j’ai reconstitué le modèle de relation entre leurs 11 classes pour clarifier les différents appels s’effectuant entre elles.

Description succincte des 11 classes :

Admin : classe servlet qui récupère les informations renvoyées par les différentes pages jsp administrateur et qui appelle les méthodes de RelationBaseIhmAdmin correspondantes.

Authentification : classe servlet qui récupère les informations de la page jsp de connexion à ADONIS et qui appelle la méthode de vérification des mots de passe de RelationBaseIhm.

CreationModification : classe servlet qui récupère les informations des pages jsp de création et modification des DE. Selon les traitements désirés par l’utilisateur, elle appelle les méthodes correspondantes de RelationBaseIhm.

- 15 -

Authentification

Recherche

Impression

Deconnexion

Admin

CreationModification

Requeteur

Documents RelationBaseIhm

MoteurBDD

RelationBaseIhmAdmin

Extend HttpServlet

Deconnexion : classe servlet qui déconnecte l’utilisateur d’ADONIS.

Document : classe qui gère la récupération des documents de la BD en mémoire, l’ajout , la modification, la suppression et l’affichage de ceux-ci.

Impression : classe servlet qui récupère les informations des DE à partir des pages de consultation ou de suivis des DE selon certains critères. Elle les met en forme au format PDF afin de permettre leur enregistrement ou impression.

MoteurBDD : classe d’interface entre la Base de donnée et l’application ADONIS.

Recherche : classe servlet qui récupère les critères de recherche des DE sur la page jsp de recherche et qui les transmet à la méthode de recherche de RelationBaseIhm.

RelationBaseIhm : classe contrôle de l’application ; elle fait le lien entre les Servlets - Jsp et les classes d’accès à la base de donnée : MoteurBDD et Requeteur.

RelationBaseIhmAdmin : classe contrôle de l’application qui a les mêmes fonctions que RelationBaseIhm mais pour la partie Administrateur d’ADONIS.

Requeteur : classe qui répertorie toutes leurs requêtes (en dur)

Nous avons pu constater que leurs classes JAVA étaient pour la majorité trop longues (entre 2000 et 6000 lignes). Elles comportaient en grande partie des méthodes aux traitements similaires qui ne se différenciaient que par une initialisation des paramètres de la méthode « en dur ». Par exemple, ils avaient une méthode pour récupérer les documents MOA et une autre pour les documents MOA, ne changeant ainsi dans la méthode que le nom de la table où le « moteur de base de donnée » (classe permettant d’écrire et de récupérer des données dans la BD) devait aller chercher les données. Il aurait été plus judicieux de faire une méthode plus générique de récupération de documents avec un paramètre entrant « nom de table ».

- 16 -

Certains algorithmes n’étaient pas optimisés et procédaient à des traitements supplémentaires que l’on aurait pu simplement éviter. Pour exemple leur algorithme de gestion des documents associés à une DE :

Récupération des documents associés à une DE dans un tableau de taille nAffichage du tableau de documentsSi insertion d’un document,

> Allouer un tableau de taille n+1> Recopier tous les documents existants dans ce nouveau tableau> Ajouter le document à insérer dans le tableau> Supprimer de la BD tous les enregistrements> Insérer dans la BD tous les documents du tableau

Si modification d’un document,> Modifier les informations du document dans le tableau> Supprimer de la BD tous les enregistrements> Insérer dans la BD tous les documents du tableau

Si suppression d’un document,> Allouer un tableau de taille n-1> Recopier tous les documents sauf celui a supprimer> Supprimer de la BD tous les enregistrements> Insérer dans la BD tous les documents du tableau

Sur cet exemple, nous pouvons voir que les conteneurs utilisés n’étaient pas des plus adaptés. L’utilisation d’une liste pour cette gestion des documents semblait bien plus appropriée que la création d’un nouveau tableau et la recopie des documents dans celui-ci. De même, il était possible d’éviter ces multiples requêtes à la BD en limitant celles-ci aux seules requêtes d’insertion, modification, suppression directement sur les documents concernés.

Lors de cette étude des codes source, je réfléchissais aux possibles optimisations des méthodes qui seraient traitées durant la partie « fiabilisation » d’ADONIS.

- 17 -

1.2. La migration de la base de données (initialement 23 requetes) -> 26 requetes

ADONIS n’ayant pas le même modèle de BD que l’application Access, il ne suffisait pas d’exporter les tables d’Access vers ADONIS. La méthode était de créer des tables de même structure que celles d’ADONIS dans Access et de les remplir avec les données de la BD access. Il fallait ensuite les exporter en fichiers texte sur ADONIS.Les deux stagiaires précédents avaient déjà effectué cette migration. Pour celle-ci, ils avaient crée des requêtes qui récupéraient les informations dans les tables Access pour les regrouper dans les tables de la BD d’ADONIS.J’ai procédé à de nombreux tests pour vérifier l’intégrité des données chargées dans les nouvelles tables.Lors de ces tests, je me suis aperçu de plusieurs erreurs :

Certaines DE qui possédaient le même numéro de DE dans la base Access étaient simplement supprimées lors du passage à la BD ADONIS.

La mauvaise récupération des noms des auteurs de la DE et des documents. La requête n’allait pas chercher les Noms dans les bonnes tables.

L’inexactitude des données de certains documents ; les requêtes attribuaient, pour certains attributs des documents portant sur une même DE, la même valeur.

Aucune récupération du nom du 2e porteur de la DE s’il en existait un.

En premier lieu, j’ai fait parvenir a Sylvain GOLDBERG la liste de toutes les DE posant problème au niveau de leur identification. Celles-ci se sont vues attribuer un nouveau numéro afin d’être reprises correctement sur ADONIS.

Puis, j’ai du réécrire les requêtes visant les porteurs de DE, en incluant la récupération d’un 2e porteur lorsqu’il était présent.

De plus, il m’a fallu attribuer à chaque document un identifiant provisoire afin de récupérer correctement toutes les données associées à chacun d’eux. Cet identifiant ne servant plus sur Adonis, les champs furent supprimés avant la migration.

L’export des différentes tables s’est ensuite déroulé sans incident sur Adonis et toutes les données furent retrouvées par les utilisateurs qui vérifièrent la bonne récupération des données.

- 18 -

1.3. Traitement des Evolutions et tests sur le serveur de recettes :

Il y avait 4 évolutions à traiter avant la mise en production d’ADONIS ; il fallait :

Supprimer la partie budget de l’application Etablir un tri des documents par ordre chronologique Travailler l’ergonomie d’ADONIS en réfléchissant à de nouvelles redirections Supprimer le champ « Auteur » des documents Intégrateur

Ces évolutions entraînant des modifications dans de nombreuses classes java et pages jsp, nous avons travaillé en commun sur chacune d’entre elles, nous répartissant les différentes classes.

A chaque nouvelle implémentation, nous testions celle-ci sur le serveur de recettes. Nous nous répartissions toutes les erreurs à corriger en fonction des classes modifiées par l’un ou l’autre.

La suppression de la partie budget d’ADONIS fut assez délicate compte tenu des modifications à effectuer dans la grande majorité des classes et des pages jsp. Il ne fallait en aucun cas laisser du code « mort » dans les sources d’ADONIS. De plus, il nous a fallut aussi modifier la BD d’ADONIS en ce sens.

Le tri des documents par ordre chronologique entraîna des modifications dans la classe Requeteur essentiellement : il fallait changer les requêtes pour chaque type de requêtes SELECT traitant des documents.

Pour les nouvelles redirections, nous nous sommes mis à la place d’un utilisateur et avons réfléchis aux choix les plus profitables. Au lieu d’être redirigés tout le temps sur la page d’accueil, ce qui représentait une perte de temps non négligeable, nous étions maintenant redirigés vers la page de recherche ou de consultation. Nous avons aussi penser à placer les paramètres de la recherche en paramètres de session afin de les récupérer aisément lors d’une redirection sur celle-ci.

Enfin, la suppression de l’auteur pour les documents a été traitée en supprimant ce champs dans la BD et en modifiant toutes les méthodes s’y reportant, aussi bien en insertion, qu’en modification et affichage.

- 19 -

1.4. Mise en Production – Double Saisie :

Une fois toutes les évolutions traitées et les bugs corrigés, avec le feu vert de Sylvain GOLDBERG, Dominique POITEVIN a mis ADONIS en production. Tous les utilisateurs étaient avertis du passage à la double saisie.

Les sources et la BD d’ADONIS ont été portés sur le serveur de production. Seul Dominique y avait accès.

Durant cette phase de double saisie, tous les utilisateurs devaient reporter tous leurs ajouts, modifications ou suppression à la fois sur la base Access et la base ADONIS afin de ne pas perdre de données durant ces tests.

Au fur et à mesure de l’avancement de cette double saisie, nous avons du traiter bon nombre de petites anomalies et évolutions rapportées par les utilisateurs sur deux fichiers prévus à ces effets (Voir Feuille d’anomalie et de demandes d’évolution en annexe).

Cependant, fin Avril, nous avons rencontré une anomalie « bloquante » : Lors de la reprise de certaines DE, comportant certains attributs différents de ceux redéfinis dans ADONIS, les documents disparaissaient complètement de la base de données.

Nous avons décidé rapidement d’arrêter la double saisie puisque ce problème venait des mauvais algorithmes de gestion des documents énoncés plus haut. En effet, lorsque l’on supprime tous les documents de la BD pour les réinsérer, il peut se produire une erreur durant l’insertion. Ceci peut arriver avec des caractères tels que les guillemets ; on perd alors tous les documents supprimés plus tôt.

Ce problème touchant une partie très importante de l’application, nous avons décidé de changer le cours du projet et de procéder directement à la refonte totale de l’application. Cela signifiait refaire une analyse complète et développer à nouveau ADONIS.

- 20 -

2. Deuxième phase   : Refonte totale de l’application   :

2.1. Nouvelle Base de donnée ADONIS

Profitant de cette refonte d’ADONIS, nous avons décidé de refaire le modèle des données en indexant toutes les tables. Ceci permet d’effectuer des modifications sur une table sans avoir a mettre à jour toutes les autres tables dépendantes de celle-ci. Les modifications sont répercutées automatiquement dans la BD.

Cette nouvelle BD est donc constituée de 21 tables :

de : représente une demande d’évolutiontype_de : le type de la DEpriorité : la priorité de cette DEapplication : l’application sur laquelle porte cette DErelease : la release dans laquelle va être incorporée cette DEentite_responsable : l’entité (ou service) responsable de cette DEstatut : le statut de la DE (Implémentée, annulée, en attente …)jalon : le jalon attribué à la DE dans la classification « Equipage »description : contient la description et la remarque de la DEhistorique : contient l’historique des changements de statut ou jalon des DEreprise_de : contient les numéros des DE reprises par une DEutilisateur : représente un profil utilisateur de l’applicationdroit_acces : représente un droit d’accès d’un utilisateurdocument_integrateur : représente un doc Intégrateurdocument_moa : représente un doc Moa (maîtrise d’ouvrage)document_moe : représente un doc Moe (maîtrise d’œuvre)type_document_integrateur : représente un type d’un doc Intégrateurtype_document_moa : représente un type d’un doc Moa (maîtrise d’ouvrage)type_document_moe : représente un type d’un doc Moe (maîtrise d’œuvre)validation : représente la validation d’un documentinformation_administrateur : représente le message d’accueil d’ADONIS

Toutes ces tables sont reliées entre elles par leurs index : voir ci-dessous.

- 21 -

de

type_de

statut

application

entite_responsable

release

historique

jalon

type_document_moe

type_document_moa

document_moe

document_moa

document_integrateur

validation

description

droit_acces utilisateur

Information_administrateur

NuméroTypeJalonStatutLibelléPrioritéApplicationReleaseDate_réceptionDate_généralisation_souhaitéeDate_dernière_modifEntité_responsablePorteur_1Porteur_2

Idlibellé

NumReleaseLibelléLotAnnéerelease

NumHistoriqueNuméro_deJalonStatutDroits_utilisateurDate_de_modificationDescriptionRemarque

Numéro_deDescriptionRemarque

NumDocNuméro_deTypeRéférenceDate_de_réceptionVersionValidation

NumDocNuméro_deNuméro_EBFTypeRéférenceDate_de_réceptionVersionAuteurValidation

NumDocNuméro_deTypeRéférenceDate_de_réceptionVersionAuteurValidation

NumUtilisateurLoginMdpNomPrénomTéléphonePortableEmailDroitsAuteurPorteur

NumDroitLibelleDroitDe_creationDe_modificationDe_consultationDe_suiviDe_rechercheadministration

texteAdmin

Idlibellé

Idlibellé

Idlibellé

Idlibellé

Idlibellé

Idlibellé

Idlibellé

priorite

Idlibellé

reprise_de

IdNuméro_DE_reprenantNuméro_DE_reprise

type_document_integrateur

Idlibellé

- 22 -

Avec ce nouveau modèle de données, la migration entre la BD Access et celle d’ADONIS va devoir être changée.

Nouvelle méthode de migration de la BD : 51 requêtes

2.2. Refonte des classes d’ADONIS2.3. Assemblage et tests de la version 2.0 d’ADONIS2.4. Mise en Production future

Refonte du modèle de classe de l’application : une programmation plus axée

objet / généricité Assemblage de cette nouvelle version sur le serveur de recettes et tests Mise en production à venir

CONCLUSION

Où en sont les objectifs ? Les problèmes rencontrés Les Apports du stage

- 23 -

Notes   :

-une migration de la BD Access vers la BD Mysql

La première partie de mon travail consistait en une migration de l’ancienne Base de données Access, comprenant une centaine de tables, à la nouvelle Base de données Mysql d’ADONIS de 21 tables. Bien sur, toutes les tables d’Access n’étaient pas seulement liées à la gestion des évolutions.Les deux précédents stagiaires ayant déjà travaillé sur ce point, je devais reprendre leur méthode et m’assurer de la bonne récupération des données sur la base ADONIS.Aucune perte de données étant tolérée par les utilisateurs, il fallait vérifier les enregistrements minutieusement.

- 24 -

- Reprise d’un code déjà existant avec débugage de l’application, traitement des

évolutions souhaitées et optimisation de l’application.

La deuxième partie consistait en la reprise intégrale des codes sources afin de relancer l’application le plus rapidement possible. ADONIS ayant été débuguée par Mr POITEVIN à la suite du précédent stage, l’application nous a été présentée comme fonctionnant. Notre tache était de reprendre cette première version et de procéder à des modifications. Ces évolutions avaient été définies par les utilisateurs lors de la mise en production de la première version d’ADONIS.Le but était de relancer le plus rapidement possible ADONIS afin de mettre l’application en production et tester son fonctionnement. Nous devions procéder ensuite à une « fiabilisation » de celle-ci en optimisant le code et les traitements avec la BD.

- 25 -

- 26 -

Stagiaires

MIGEON Guillaume

DOUILLARDSamy