Voici quelques unes des missions que j'ai effectuées depuis que je suis consultant indépendant.
La société l'Oréal souhaitait
une application
d'analyse budgétaire sous Oracle Express Objects. Le cahier
des
charges faisait apparaître de telles contraintes techniques
que
plusieurs personnes avaient déclaré le projet
irréalisable. Ces contraintes étaient
principalement :
Ma mission consiste à développer cette application dans le temps imparti.
Une première étude a été réalisée pour compléter le cahier des charges, définir avec les utilisateurs les fonctionnalités prioritaires, bien estimer les contraintes techniques et établir une structure optimum de base.
Ensuite le développement s'est effectué en deux temps :
Malgré de nombreuses contraintes techniques et des délais impératifs, l'application a été mise en production en temps et en heure.
Elle a entièrement satisfait les utilisateurs puisque j'ai reçu plusieurs mails de félicitations.
Suite à cette réalisation, la société l'Oréal m'a confié de nouvelles missions.
Retour à la liste des exemples
La société NOOS utilisait une
application OFA
développée deux ans auparavant par une
société tierce. La base était devenue
tellement
volumineuse et les traitements tellement longs que les utilisateurs
demandaient l'abandon d'OFA malgré l'importance des
investissements réalisés.
Ma première mission a été de réaliser un audit pour déterminer la cause de ces dysfonctionnements.
Un premier audit de quelques jours a permis de montrer que les causes étaient multiples mais que la cause principale venait de la structure de la base. Or changer radicalement la structure d'une base nécessite de redévelopper entièrement l'application qui s'appuie dessus.
Suite à cet audit, pour améliorer le quotidien des utilisateurs, toutes les optimisations rapides à mettre en place ont été utilisées.
Ma deuxième mission a été de redéfinir la base de données et donc de redévelopper intégralement l'application.
Ce redéveloppement a été effectué en 60 jours et a permis d'intégrer de nouveaux besoins utilisateurs. A titre de comparaison, le développement initial avait nécessité la présence de trois personnes pendant quelques mois.
Le redéveloppement complet a permis :
Retour
à la liste des exemples
La société Sanofi-Aventis utilise une
application
Express. La base est chargée une à deux
fois par
mois. Les programmes de chargement alimentent la base et effectuent de
nombreux calculs (agrégations). Ils durent 30 heures, ce qui
est
trop long.
Ma mission est d'optimiser ces programmes.
Grâce à des outils de traces Express (trackreport d'abord et monitor ensuite) j'ai démontré que la partie agrégation des variables (rollup) représente, à elle seule, 85 % du temps de chargement.
J'ai donc focalisé ma recherche d'optimisations sur cette partie de l'application.
L'étude du code des différents
programmes qui
agrègent les variables a montré que les rollup ne
sont
pas écrits suivant les préconisations d'Oracle.
Par contre, réécrire toute cette partie du
chargement
pour tenir compte des préconisations d'Oracle
représente
plusieurs mois de travail.
Avant de se lancer dans cette réécriture, il faut donc mesurer si le gain qu'elle apporte en vaut la peine. Pour cela, un jeu de tests représentatif a été monté en reprenant certaines des variables de la base et en les agrégeant. Ce jeu de tests contient tous les types de variables présents dans la base et les variables qui le constituent consomment, à elles seules, 50% du temps d'agrégation.
Le jeu de tests a alors montré qu'en
agrégeant ces
variables suivant les préconisations d'Oracle on obtenait,
suivant les types de variables, des temps de traitements de 2
à 5 fois plus rapides qu'avec l'écriture
utilisée.
Face à une telle opportunité de gain, le client a décidé de revoir la logique de ses programmes d'agrégation.
En même temps, il a rajouté de nouvelles fonctionnalités qui ont entraîné de nouveaux traitements et un doublement du volume des données.
Grâce à l'optimisation effectuée, au lieu des 60-80 heures attendues suite aux traitements supplémentaires et au doublement du volume, le chargement dure moins de 20 heures.
Retour à la liste des exemples
La société Michelin utilise OFA 6.2 sous
UNIX. Le
service qui exploite la machine ne désire pas
acquérir de
compétences poussées sous Express mais souhaite
assurer
des sauvegardes sûres. Les utilisateurs quant à
eux,
veulent une disponibilité des bases Express 24 heures sur 24
et,
bien qu'Oracle affirme le contraire, un consultant Express leur a
certifié que les backup online des bases Express
fonctionnent.
Ma mission consiste à mettre en place une stratégie de backup / restore tout en respectant les souhaits des utilisateurs.
Un backup effectué online n'est pas garanti par Oracle. En conséquence, il est nécessaire d'arrêter les instances Express et donc de convaincre les utilisateurs qu'un backup online est trop dangereux pour leurs données.
La mission a débuté par la mise en place d'un jeu de tests pour démontrer aux utilisateurs qu'une sauvegarde online peut être dangereuse pour leurs données. Malgré la robustesse du moteur Express qui permet à un bon nombre de sauvegardes online d'être valides, le jeu de tests a permis de prouver que ce type de sauvegardes n'est pas sûr. Il a même mis en évidence des cas où l'échec de la sauvegarde est systématique.
Grâce à ces résultats, il a été possible de définir avec les utilisateurs une plage d'arrêt des bases la nuit.
Ensuite, la mission s'est attachée à
écrire les
scripts d'arrêt / redémarrage d'Express ainsi que
les
procédures de restaurations de bases. Bien sûr,
ces
procédures prennent en compte le fait qu'une application OFA
est
constituée d'un ensemble de bases Express qui communiquent
entre
elles et qu'elles peuvent être
désynchronisées
à la suite de la restauration d'une seule base.
Ce client est aujourd'hui en production, plusieurs restaurations de bases isolées ont déjà eu lieu sans aucun problème.
Retour à la liste des exemples
Une SSII avait obtenu le développement d'un projet OFA important mais était confrontée aux problèmes suivants:
Ma mission était d'assister l'équipe durant tout le cycle de vie du projet.
Dès le début du projet, j'ai mis en évidence les deux points qui poseraient problèmes:
Après l'analyse précise des besoins utilisateurs et quelques essais, j'ai pu proposer une structure physique de base qui permettait de répondre aux demandes des utilisateurs avec des temps acceptables.
J'ai aussi permis à l'équipe de la SSII,
de réaliser un développement dans les
règles de l'art, ce qui s'est
révélé très utile par la
suite quand des évolutions ont été
demandées.
Malgré de fortes contraintes techniques, le projet a été réalisé et tourne aujourd'hui en production.
Au fil du temps, les évolutions demandées par les utilisateurs ont pu être intégrées facilement, car la structure physique choisie au départ était évolutive.
Retour à la liste des exemples
La société Dalkia utilisait OFA avec un lien GL Link. C'est à dire que le progiciel OFA était alimenté directement par les données provenant de Oracle GL.
Or, la clé comptable GL, fondation de l'application GL, devait être modifiée.
Cap Gemini prenait en charge cette modification et les impacts fonctionnels sur OFA.
Théoriquement, une clé comptable GL n'est jamais modifiée. Oracle, en dévelopant le GL Link d'OFA n'a donc rien prévu pour prendre en charge cette modification. Enfin, les informations décrivant la clé comptable sont dans des catalogues systèmes OFA, générées à l'installation et non documentées.
Ma mission était de modifier les catalogues systèmes OFA pour prendre en compte le changement de clé comptable GL.
J'ai monté un environnement de test
qui m'a permis à travers plusieurs essais de comprendre
précisément le fonctionnement des
mécanismes
internes du GL Link. Ensuite, j'ai écrit des
procédures automatiques permettant de basculer les
catalogues systèmes de l'application OFA de l'ancienne vers
la nouvelle clé.
La bascule a été réalisée et aujourd'hui, l'application tourne correctement avec la nouvelle clé comptable.
Retour à la liste des exemples
Le client utilise une machine HP-UX et souhaite installer OFA 6.2 sur sa machine. A l'époque, OFA et Express Server 6.2 viennent juste d'apparaître et peu de gens les connaissent.
D'autre part, la machine du client doit être
particulièrement sécurisée, elle est
donc configurée avec les normes de
sécurité C2. Or, cette première
version 6.2.0.0 d'Express Server sous HP-UX contient un bogue qui
apparaît en configurant la machine en
sécurité C2 et en utilisant des passwords de plus
de huit caractères.
Ce bogue, inconnu à l'époque, sera découvert au cours de la mission.
Le but de la mission est d'installer Express Server et OFA 6.2 sur la machine HP-UX version 11 pour permettre au projet OFA de commencer dès le lendemain.
L'installation se passe sans encombre, le moteur Express démarre mais s'arrête au bout de quelques secondes. Le message d'erreur issu des log Express Server donne relativement peu d'informations (OES_REQUEST - read fails, error 11).
Néanmoins, en étudiant plus précisément les log, je remarque que le moteur s'arrête brutalement 10 à 11 secondes après la fin de son démarrage. Cela est très important car sous Express une tâche périodique s'exécute toutes les dix secondes. La périodicité de cette tâche peut être modifiée et en la positionnant à cinq minutes j'ai constaté un arrêt brutal du serveur cinq minutes après le démarrage.
Grâce à ces informations, j'ai pu agir dans deux directions :
Malgré la présence d'un bogue générant un arrêt brutal du serveur, le client disposait le soir même d'une installation utilisable et son problème était pris en compte par le développement Oracle.