Interface OPERA-CHRONEO 

Définition de ma mission

En juillet 2008, plusieurs missions m’ont été confiées. Il s’agit de la maintenance corrective et évolutive de l’application OPERA, ainsi que du projet d’adaptation de l’application OPERA analytique à l’arrivée de CHRONEO V2, s’inscrivant dans le cadre de la reprise du module OPERA administratif par CHRONEO V2. Ce projet est piloté par les délais et les coûts, dont la mise en service devait aboutir en septembre 2010, et qui, finalement, sera mis en service en février2011.

Le projet d’adaptation à CHRONEO V2

L’application OPERA analytique s’appuyant sur les données du module OPERA administratif pour fonctionner, et ce module disparaissant, plusieurs interfaces doivent être mises en place, afin que l’application OPERA analytique puisse récupérer les données administratives dont elle a besoin pour fonctionner. Les contraintes relevées au départ sont les suivantes :
• le module analytique doit conserver les fonctionnalités existantes,
• l’évolution doit être transparente pour l’utilisateur final,
• l’adaptation d’OPERA ne doit pas impacter en terme de délai le projet CHRONEO V2,
• les spécifications techniques sont inexistantes,
• les spécifications fonctionnelles ne sont pas à jour,
• les modules administratif et analytique ont été initialement conçus et réalisés comme une seule application et dépendants fonctionnellement et techniquement l’un de l’autre,
• la programmation du client en Visual Basic n’est pas structurée en objet ou en module logique,
• la programmation sous Oracle n’est pas sous forme de package organisé mais de fonctions éparses,
• la MOA analytique est récemment nommée sur l’application OPERA et ne maîtrise donc pas toutes les règles fonctionnelles de l’application.

La maintenance courante

Dans un soucis de gestion de coût, de ressources, et de délai, il a été décidé, en accord avec la maîtrise d’ouvrage, que les trois trains de maintenance par an prévus dans le PAQM seraient annulés pour les années 2009 et 2010, sauf dans le cas d’anomalies bloquantes ou d’adaptation technique imposée par l’entreprise. Les maintenances indispensables identifiées au départ, en parallèle du projet, sont les suivantes :
• Création d’un package d’installation du client Visual Basic pour Windows Seven en début d’année 2010, ainsi que les tests de fonctionnement de l’application sur ce nouveau système d’exploitation,
• Une estimation de charge pour une migration de version de base ORACLE pour septembre 2010. Ceci implique que des tests techniques soient effectués pour vérifier que la connexion à ORACLE 10 est possible en Visual Basic,
• L’application POINTAGE et la gestion du serveur BULL doivent être externalisées, ce qui implique la mise en place d’une sécurité au niveau des transferts FTP. Cette sécurité serait assurée par le fichier HOST, surle serveur BULL, dans lequel seraient répertoriées toutes les adresses IP ayant le droit de se connecter. Or, les transferts se font du poste client OPERA vers le serveur BULL, ce qui fait 600 adresses IP, car il y a 600 clients OPERA déployés. De plus, la liste des postes change régulièrement. Il est donc demandé de faire une maquette pour vérifier la faisabilité du transfert via le serveur OPERA, ce qui, dans ce cas là, permettrait de ne plus avoir qu’une seule adresse dans le fichier HOST,
• Projet ORION : Ce projet va impacter l’entrepôt de données SERFECO, et donc, l’application OPERA.

Gestion de la configuration logicielle des environnements

Pour la GCL des environnements, j’utilise un document Excel qui comprend un onglet par environnement. Dans chaque onglet, la version de chaque brique côté client, et côté serveur est référencée. La version générale de l’application évolue lorsque la version de la brique applicative côté client ou serveur évolue. La brique applicative pour le client est l’exécutable, et pour le serveur c’est l’ensemble des composants tels que les Shells, les procédures stockées, la structure de la base de données… Pour chaque évolution de version, il y a l’identification des fiches d’évolution ou de correction associées. La figure ci-dessous est un exemple pour l’environnement de production.

Utilisation de Visual Source Safe (VSS)

Visual Source Safe est un gestionnaire de fichier qui permet le contrôle d’accès aux fichiers sources lors du développement, la sauvegarde, la gestion de version, et la hiérarchisation de ces fichiers.
Dans le cadre d’OPERA, cet outil est utilisé pour les composants serveurs etclients nécessaires au bon fonctionnement de l’application.
Afin de gérer les versions des composants OPERA, toute livraison est suivie d’un archivage avec étiquetage des sources de la nouvelle version.

Les fonctionnalités de VSS

Cet outil permet de créer plusieurs arborescences, et, ainsi, de pouvoir développer plusieurs projets en parallèle.
Il permet d’obtenir la dernière version d’un fichier ou d’une arborescence, ou d’obtenir une ancienne version à partir d’une étiquette.
Il permet l’extraction de fichiers sources par un développeur qui est alors le seul à pouvoir modifier les fichiers qu’il a extraits.
Lorsque le développeur a réalisé des modifications, il peut vérifier les différences apportées à son fichier avec n’importe quelle version archivée du fichier. Il peut enfin décider d’archiver le fichier extrait.
Lorsque les développements sont terminés et validés pour être installés en production, une étiquette est créée au niveau arborescence. Ainsi, tous les fichiers de l’arborescence sont sauvegardés sous cette étiquette.

Arborescence utilisée

Pendant le projet d’adaptation d’OPERA à CHRONEO V2, deux arborescences identiques ont été utilisées. La première, nommée OPERA_3, contient les codes sources de la maintenance courante. La deuxième, nommée OPERA_5, contient les codes sources de l’adaptation d’OPERA à CHRONEO V2, ainsi que la reprise des développements de la maintenance courante.

Analyse d’impact

But de cette analyse d’impact

Le périmètre du projet CHRONEO V2 reprenant le module administratif de l’application OPERA, une analyse d’impact sur l’application existante a dû être effectuée.
Cette analyse a pour but de répertorier toutes les données administratives utilisées par le module analytique. Ensuite, à partir de cette liste de données, il sera possible de faire des ateliers de spécifications fonctionnelles avec la MOA, pour étudier quelle sera la nouvelle source pour récupérer les données administratives disparaissant avec le module administratif.
Cette analyse permettra aussi de découper l’application analytique en cas d’utilisation, qui, jusqu’à présent, n’étaient pas décrits. Chaque cas d’utilisation sera décrit et numéroté, chaque action décrite du cas sera aussi numérotée, les requêtes associées à chaque action seront répertoriées et seront numérotées avec le même numéro que l’action décrite.
Chaque donnée utilisée par un cas d’utilisation sera définie et regroupée dans sa table physique Oracle, il sera aussi indiqué si c’est une donnée qui dépend du module administratif. 111 cas d’utilisation analytique répertoriés sont à décrire. L’analyse permettra de déterminer ceux qui seront impactés par la suppression du module analytique. Le découpage en cas d’utilisation permettra une meilleure gestion de l’estimation des charges de développement et de la réalisation du planning détaillé. Cette phase est donc très importante, car cette étude sera la base de tous les travaux suivants.
Cette phase a été longue et difficile car pour générer les cas d’utilisation analytique, il a fallu étudier le code source, celui-ci n’étant pas structuré et peu commenté. De plus, les requêtes, ainsi que les appels de connexion à la base de données, ne sont pas centralisés.
Cette phase a été réalisée avec l’aide d’un prestataire. Elle a eu une durée de 85 jours, comme indiquée dans l’extrait du planning ci-dessous.

Assistance à maîtrise d’ouvrage (AMOA)

Réunions de spécifications fonctionnelles

La maîtrise d’ouvrage OPERA analytique est partie à la retraite en juin 2008, et la personne reprenant cette fonction a été nommée en janvier 2009. Il n’y a donc pas eu de recouvrement et de passation de connaissance. La MOA avait donc peu de connaissance de l’application. La conséquence est qu’il a été décidé qu’il y aurait de ma part (MOE) une forte assistance à la MOA.
La conception détaillée a été réalisée en deux phases. Une première phase a permis de définir la nouvelle architecture fonctionnelle, en s’appuyant sur le document d’analyse d’impact généré précédemment. La deuxième phase a permis de spécifier le besoin d’interface entre OPERA et CHRONEO V2.
Pour la première phase, il y a eu un premier atelier où j’ai présenté à la MOA les impacts de l’arrivée de CHRONEO V2 en m’aidant de l’étude de la phase précédente. A la fin de cette présentation, il a été décidé de faire un atelier dans lequel serait étudiée la nouvelle source des données administratives disparaissant. Une fois les sources de données définies, il a été mis en place un atelier par source de données, pour définir les règles de gestion de récupération des données dans OPERA. En sortie de ces ateliers, j’ai rédigé les spécifications fonctionnelles qui comprennent :
• La nouvelle architecture fonctionnelle cible, avec les trois nouvelles interfaces SERFRH, SERFECO et CHRONEO,
• La description de chaque flux de données à récupérer pour les trois interfaces,
• Les règles de gestion de la récupération de chaque flux pour les trois interfaces,
• La description des enchaînements entre chaque flux pour les trois interfaces.
Les applications SERFRH et SERFECO, des entrepôts de données, sont déjà existant, il n’y a donc que l’interface côté OPERA à définir et réaliser. Par contre, pour l’application CHRONEO V2, il n’existe aucune interface. Lors de la deuxième phase, j’ai rédigé un document qui spécifie les règles fonctionnelles et techniques communes aux deux applications (CHRONEO V2 et OPERA) pour que l’interface fonctionne. L’implémentation de l’interface doit faire l’objet d’une conception détaillée pour chaque application.
L’implémentation dans chaque application peut évoluer indépendamment tant que les spécifications d’interface décrites ne sont pas remises en cause.
La spécification d’interface sera mise à jour en cas de modification fonctionnelle ou technique impactant les deux applications.
L’interface du côté CHRONEO sera réalisée par un prestataire de service, et côté OPERA, la réalisation sera faite en interne.

Création des scénarios de recette fonctionnelle

Comme la maîtrise d’ouvrage avait une connaissance récente de l’application, j’ai décidé, en accord avec ma hiérarchie, d’apporter une forte assistance à la recette fonctionnelle.
Cette assistance a consisté à la rédaction de scénarios de tests fonctionnels qui permettaient de tester tous les cas d’utilisation de l’application OPERA analytique. Ces tests ont été rédigés en parallèle des développements. Après le développement de chaque cas d’utilisation, les scénarios de tests étaient rédigés et développés. Iln’y a pas eu de rédaction de tests unitaires par la MOE, du fait de la prise en charge des scénarios de tests fonctionnels.
Ce choix s’est fondé aussi sur le fait qu’il n’y avait pas de scénarios de tests de l’application et que lors des maintenances de l’application, les tests étaient recréés pour le cas traité et qu’ils n’étaient pas conçus pour être réutilisables. Cela avait pour conséquences de générer de fortes charges de tests à chaque maintenance, et les tests de non régression n’étaient pas réalisés.
J’ai donc décidé que ce projet devait permettre de mettre en place une stratégie de tests fonctionnels qui seraient réutilisables sur n’importe quel environnement (hors production), et qui seraient automatisés quand cela serait possible.
Le détail des tests automatisés est au chapitre VIII.5.

Exécution des scénarios de recette fonctionnelle

Phase d’installation

La MOE doit créer les environnements de recette sous UNIX, ce qui comprend la création de l’arborescence, la création des comptes, le positionnement des droitssur les répertoires et les fichiers, tout ceci étant normalisé et rédigé dans les procédures d’exploitation.
La MOE doit installer les 8 bases de données Oracle, ce qui comprend le paramétrage du fichier init.ora, la création des tablesspaces, des roll back segment…
La MOE demande à l’exploitation un export full de la base de données Oracle, puis exécute l’import des données de production dans la base de recette.
La MOE exécute le patch qui installe la version cible de l’application sur le serveur UNIX. Ce patch met à jour les scripts sous UNIX et met à jour les objets sous Oracle.
La MOE exécute le script d’installation des tables bouchon, des tables de références et des packages de tests.
La MOE installe manuellement le client cible de version 5.0 sur les postes de la MOA et des personnes habilitées à tester.

Phase d’exécution des scénarios de tests

Les scénarios de tests ont été joués par la MOA avec l’aide de la MOE. Lors de cette phase, quelques anomalies mineuressont ressorties, elles ont été tracées dans l’outil Mantis, l’outil de gestion de faits techniques utilisé sur le projet. Dans le document des scénarios de tests, il y a un récapitulatif des scénarios avec le résumé de chacun,la validité du scénario, et pour ceux qui ne sont pas valides, les numéros de fiche Mantis associés.

Assistance aux tests d’interopérabilité

Création des scénarios de tests d’interopérabilité

Les tests d’interopérabilité permettent de tester le système d’information. Ce sont des tests dits de « bout en bout » qui permettent de valider les interfaces entre les applications testées, ainsi que l’automatisation des batchsde nuit.
Ces tests sont réalisés avec des données et une volumétrie à l’identique de la production, ce qui permet, pour les cas où les règles de gestion du système d’information n’ont pas évolué, de comparer les résultats des tests aux résultats du système d’information en production.
Lors de cette phase, l’assistance à la maîtrise d’ouvrage OPERA, que j’ai apportée, a consisté à la proposition des scénarios, à la structuration et la rédaction du document des scénarios de tests, à l’aide de l’analyse des résultats des tests.
Les scénarios de tests d’interopérabilité doivent être décrits en accord entre les MOA des différentes applications ayant des interfaces communes. OPERA cible a des interfaces entrantes avec les applications CHRONEO, SERFRH, SERFECO et plusieurs GMAO. OPERA cible a des interfaces sortantes avec les applications TEMPO2 et plusieurs GMAO.
Les scénarios de tests de l’interface entre OPERA et CHRONEO, que j’ai rédigés, ont été validés par les MOA respectives des deux applications, puis, ensuite, exécutés sur les environnements de TIO des deux applications.
Pour les autres interfaces entrantes que sont les entrepôts de données SERFRH et SERFECO, ces applications étant déjà en production, l’environnement de TIO OPERA a été connecté à ces deux applications avec l’aval des MOA respectives. Dans ce cas-là, les scénarios de tests utilisent les données de production en entrée et consistent à vérifier que l’application OPERA cible donne les mêmes résultats que OPERA de production, car les règles de gestion n’ont pas changé. Il n’y a pas besoin d’un accord sur les scénarios de tests
pas besoin de faire de test du côté des applications recevant les données d’OPERA. Les transferts de données se feront sur des environnements bouchonnés. Les scénarios de tests consisteront à vérifier que les résultats des transferts sont identiques à ceux réalisés en production. Il n’y a pas besoin d’un accord sur les scénarios de tests entre les MOA.
Au final, les scénarios de tests d’interopérabilité seront rédigés dans deux documents.
Le premier document permet de tester l’interface OPERA-CHRONEO, et demande une coordination des acteurs MOA, MOE, recetteurs des deux parties. La numérotation des tests n’a pas utilisé la numérotation des cas d’utilisation OPERA car c’est un document commun aux deux applications. Chaque test a été numéroté de la manière suivante : T-« type de flux » -« numéro du scénario ». Le type de flux est codifié, par exemple « abs » pour absence. Un résumé de chaque scénario, une description détaillée pour qu’il soit rejouable, etles résultats attendu et obtenu sont décrits.
Le second document permet de tester les autres interfaces, et de tester les cas d’utilisation principaux par rapport aux résultats de la production. Ce second document demandant un effort de coordination entre les acteurs moindre, mais demandant un effort d’outillage pour réaliser les comparaisons. Chaque test a été numéroté de la manière suivante : T-« numéro du scénario ». Les scénarios sont moins détaillés car il s’agit de comparaison en masse de données par rapport à la production. Par exemple, vérifier que toutes les affectations comptables des agents de l’environnement de TIO sont identiques aux affectations comptables de la production. Ces comparaisons seront effectuées parrequêtes SQL.

Table des matières
Remerciements
Liste des abréviations
Glossaire
Table des matières
Introduction 
I PRESENTATION DE LA RATP 
I.1 ENVIRONNEMENT DU PROJET
I.1.1 Le département des systèmes d’information et de télécommunications (SIT)
I.1.2 Unité Conception et Production des Systèmes (CPS)
I.1.3 Gestion des Temps et des Activités (GTA)
II ORIGINE ET CADRE DU PROJET 
II.1 ORIGINE DU PROJET
II.2 ARCHITECTURE FONCTIONNELLE
II.3 INTERACTIONS ENTRE OPERA ADMINISTRATIF ET OPERA ANALYTIQUE
II.4 ARCHITECTURE TECHNIQUE DE L’APPLICATION OPERA
II.4.1 Architecture globale
II.4.2 Architecture de l’application
II.4.3 Communication entre le client et le serveur
II.5 TAILLE DE L’APPLICATION
II.6 CHOIX ENTRE REFONTE ET ADAPTATION
IV PRESENTATION DE LA DEMARCHE 
IV.1 DEMARCHE CHRONOLOGIQUE
IV.2 OUTILS UTILISES
IV.2.1 Plan d’assurance qualité maintenance (PAQM)
IV.2.1.1 Gestion des documents
IV.2.2 Gestion des environnements de développement
IV.2.3 Gestion de la configuration logicielle (PGCL)
IV.2.3.1 Gestion de la configuration logicielle des environnements
IV.2.3.2 Gestion de la configuration logicielle des composants applicatifs
IV.2.3.2.1 Composition de la configuration
IV.2.3.2.2 Utilisation de Visual Source Safe (VSS)
V ANALYSE D’IMPACT 
V.1 BUT DE CETTE ANALYSE D’IMPACT
V.2 CONSTAT DE L’ANALYSE D’IMPACT
VI ASSISTANCE A MAITRISED’OUVRAGE (AMOA) 
VI.1 REUNIONS DE SPECIFICATIONS FONCTIONNELLES
VI.2 ARCHITECTURE FONCTIONNELLE DU SITE PILOTE
VI.3 ARCHITECTURE FONCTIONNELLE CIBLE
VI.3.1 Processus général
VI.3.2 Interface OPERA-CHRONEO
VI.3.3 Interface OPERA-SERFRH
VI.3.4 Interface OPERA-SERFECO
VI.3.5 Mise à jour de la nomenclature
VI.4 ASSISTANCE A LA RECETTE FONCTIONNELLE
VI.4.1 Création des scénarios de recette fonctionnelle
VI.4.2 Exécution des scénarios de recette fonctionnelle
VI.4.2.1 Phase d’installation
VI.4.2.2 Phase d’exécution des scénarios de tests
VI.4.2.3 Phase de correction et re-livraison
VI.4.2.4 Génération du PV de VAF
VI.5 ASSISTANCE AUX TESTS D’INTEROPERABILITE
VI.5.1 Création des scénarios de tests d’interopérabilité
VI.5.2 Exécution des scénarios de tests d’interopérabilité
VI.5.2.1 Phase d’installation
VI.5.2.2 Phase d’exécution des scénarios de tests
VI.5.2.2.1 Interface OPERA-CHRONEO
VI.5.2.2.2 Les autres interfaces
VI.5.2.3 Phase de correction et re-livraison
VI.5.2.4 Génération du PV de TIO
VII GESTION DE PROJET 
VII.1 GENERATION DU PLANNING
VII.1.1 Découpage du planning en phases et activités
VII.1.1.1 Conception détaillée
VII.1.1.2 Spécifications techniques
VII.1.1.3 Développement
VII.1.1.4 Recette technique
VII.1.1.5 Recette fonctionnelle
VII.1.1.6 Package d’installation
VII.1.1.7 Tests d’interopérabilité
VII.1.1.8 Déploiement
VII.1.2 Définition de l’équipe de développement
VII.1.2.1 Les besoins en compétence
VII.1.2.2 Le choix de l’équipe
VII.2 SUIVI DU PLANNING
VII.2.1 Prise en compte des aléas
VII.2.2 Indicateurs de suivi de projet
VII.3 GESTION DES FICHES D’ANOMALIE
VII.4 MANAGEMENT DES RISQUES
VII.4.1 Démarche
VII.4.2 Exemples
VII.5 PILOTAGE DU DEPLOIEMENT
VII.5.1 Revue des conditions de mise en service de l’application
VII.5.1.1 Les conditions techniques
VII.5.1.2 Les conditions fonctionnelles
VII.5.1.3 Les conditions organisationnelles
VII.5.2 Rédaction de la stratégie de déploiement de l’application
VII.5.2.1 Tâche à réaliser avant le déploiement
VII.5.2.1.1 Reprise de données
VII.5.2.1.2 Tâches dans OPERA et dans le POINTAGE
VII.5.2.2 Déploiement du site pilote
VII.5.2.2.1 Serveur
VII.5.2.2.2 Client
VII.5.2.2.3 Temps de déploiement
VII.5.2.3 Accompagnement des utilisateurs du site pilote
VII.5.2.4 Test de bon fonctionnement du site pilote
VII.5.2.4.1 Vérifications techniques (à la charge du MOE)
VII.5.2.4.2 Vérifications fonctionnelles (à la charge de la MOA)
VII.5.2.4.3 Retour arrière du site pilote
VII.5.3 Intégration dans le plan de bascule de CHRONEO
VIII CONCEPTION ET REALISATION 
VIII.1 SPECIFICATIONS TECHNIQUES
VIII.1.1 Type 1 : adaptation du code existant
VIII.1.2 Type 2 : remplacement du code existant
VIII.1.3 Type 3 : création de nouveau cas d’utilisation
VIII.2 ARCHITECTURE TECHNIQUE CIBLE
VIII.3 CONCEPTION ET DEVELOPPEMENT DE PACKAGE ORACLE
VIII.3.1 Package de gestion des log et des erreurs
VIII.3.1.1 Package PKG_PILOTE
VIII.3.1.2 Package PKG_ERR
VIII.3.2 Exemple pour le cas d’utilisation « Gestion des affectations automatiques»
VIII.3.2.1 Traitement sur le frontal
VIII.3.2.1.1 Spécification technique du Shell script
VIII.3.2.1.2 Spécification technique du traitement des affectations comptables
VIII.3.2.2 Traitement sur les instances
VIII.3.2.2.1 Spécification technique du Shell script
VIII.3.2.2.2 Spécification technique du traitement
VIII.3.3 Exemple pour le cas d’utilisation « Ventilation centre journalier»
VIII.4 CONCEPTION ET REALISATION DE L’AUTOMATISATION DES BATCHS
VIII.4.1 Automatisation des traitements de nuit
VIII.4.2 Conception des Shell scripts
VIII.5 CONCEPTION ET REALISATION DE TESTS AUTOMATISES
VIII.5.1 Tests automatisés
VIII.5.1.1 Exemple avec le cas d’utilisation « Mise à jour de la nomenclature » (Cas n°3)
VIII.5.1.1.1 Conception technique
VIII.5.1.1.2 Exemple de scénario
VIII.5.1.1.3 Extrait de résultat de tests
VIII.5.2 Tests semi automatisés
VIII.5.2.1 Conception technique
VIII.5.2.2 Exemple de scénario
VIII.6 CALCUL DE VOLUMETRIE
VIII.6.1 Estimation de l’espace requis pour une table
VIII.6.2 Estimation de l’espace requis pour un index
VIII.7 OPTIMISATION DE REQUETE
Conclusion 
Bibliographie 
Table des annexes
Annexe 1 Liste des cas d’utilisation
Annexe 2 Extrait du résultat des scénarios de tests automatisés pour le cas d’utilisation 3
Annexe 3 Extrait du récapitulatif du résultat des scénarios de tests de l’interface OPERACHRONEO
Liste des figures

Lire le rapport complet