rapport de stage
Transcription
rapport de stage
Institut des Sciences et Techniques de l'Ingénieur d'Angers - Département QUASSI 62 Avenue Notre-Dame du Lac 49000 Angers Tel : +33-2-41 22 65 00 Fax : +33-2-41 22 65 01 Reuters Financial Software - Groupe Reuters 6 rue Godefroy F-92821 Puteaux cedex, France Tél. : +33 1 47 62 64 66 Fax : +33 1 47 62 64 99 01 /09 /2006 Portail D’Assurance Qualité Rapport de stage Master2 QUASSI Steeve Ferrand (Master QUASSI) Promotion 2005-2006 Reuters Financial Software 6 rue Godefroy - Puteaux Copyright ©2006 Reuters Limited – All rights reserved. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 2 of 36 Copyright ©2006 Reuters Limited – All rights reserved. REMERCIEMENTS Avant tout, je tiens à remercier toutes les personnes qui sont intervenues au cours de ma première lancée professionnelle, en particulier Stéphane Nanot pour tout le savoir faire qu’il m’a apporté, Thierry Duchamp pour m’avoir accueilli durant ces 6 mois et pour sa disponibilité, Olivier Idarreta pour ses conseils, et à tous mes parrains de l’Assurance Qualité: Cécile Ortiz, Svetlana Tchernomorskaia, Chamseddine Abbassi, Pierre Coppet, Renald Thibaut, Hicham Ouldali, Jérôme Lacube, Thierry Nouza, Sui Wah Truong, Herve Kurfurst, Et Nada Essaadi, ainsi que tous les enseignants et professionnels de l’ISTIA pour toutes les connaissances qu’ils m’ont transmises durant cette année. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 3 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Sommaire Remerciements .............................................................................................................................. 3 Introduction ................................................................................................................................... 5 English Introduction ..................................................................................................................... 5 1. Présentation de Reuters ......................................................................................................... 6 1.1. La naissance du groupe REUTERS .............................................................................................. 6 1.2. Le groupe ....................................................................................................................................... 7 1.3. Reuters Financial Software............................................................................................................ 9 Organisation et Direction ........................................................................................................................ 10 1.4. Les différents Produits RFS ......................................................................................................... 11 1.5. RFS c’est aussi…......................................................................................................................... 11 2. Présentation du sujet ............................................................................................................ 12 2.1. Contexte de l’Assurance Qualité chez RFS................................................................................ 12 2.2. Contexte de la gestion projet et de développement chez RFS .................................................. 14 2.3. Contexte de la qualité transversale............................................................................................. 15 2.4. Problématique .............................................................................................................................. 16 2.5. Description du Projet.................................................................................................................... 16 3. Activités – Travaux realisés ................................................................................................. 17 3.1. Organisation du stage.................................................................................................................. 17 3.2. Activités du QA............................................................................................................................. 18 3.3. KPQP’s des Tests de non-régression et CMMi ........................................................................... 19 3.3.1 Expliciter les mesures ; Etablir les objectifs de mesure ....................................................... 21 3.3.2 Expliciter la collecte et la sauvegarde des données ; Expliciter les procédures d’analyses 23 3.3.3 Collecter les données de mesure ......................................................................................... 23 3.3.4 Analyse des données de mesure ........................................................................................ 24 3.3.5 Sauvegarder les données et les mesures ; Communiquer les résultats .............................. 26 3.4. Indicateurs orientés Clients.......................................................................................................... 27 3.5. Projet Portail Qualité .................................................................................................................... 29 3.5.1 Objectifs ................................................................................................................................ 29 3.5.2 Collecte des données : ETL.................................................................................................. 29 3.5.3 BusinessObjects ................................................................................................................... 32 4. Conclusion ............................................................................................................................. 33 5. Bibliographie – Webographie.............................................................................................. 34 6. Table des illustrations .......................................................................................................... 35 7. Annexes.................................................................................................................................. 36 Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 4 of 36 Copyright ©2006 Reuters Limited – All rights reserved. INTRODUCTION Dans le cadre du Master2 QUAlité et Sureté de fonctionnement des Systèmes Informatique j’ ai été amené à effectuer un stage d’ une durée effective de six mois dans le domaine de la Qualité. J’ ai été attiré par l’ offre de Reuters Financial Software, basé à Paris-La Défense, en premier par la renommée et l’ importance du groupe Reuters et, si j’ ai également choisi leur proposition c’ est essentiellement pour intégrer un département Qualité suffisamment développé dans lequel il m’ était possible d’ engranger un nombre conséquent de connaissances, et surtout pour travailler sur les problématiques Qualité orientés processus. Dans un premier temps, je présenterai l’ entreprise Reuters et sa filiale Reuters Financial Software, ainsi que le contexte, très riche, dans lequel j’ ai évolué. Puis, j’ aborderai naturellement la description du projet en décrivant les actions, leur justification et les méthodes qui ont été employées. La dernière partie traite du travail effectué pour finir sur un bilan de ce stage. En conclusion, je préciserai en quoi ce stage a été bénéfique et complémentaire à ma formation. ENGLISH INTRODUCTION In the framework of the QUASSI Master2, I was brought to carry out a six month’ s duration training course in the field of Quality. I was attracted by the Reuters Financial Software offer, based in “ Paris la Défense” , manly by the fame and the value of the Reuters group. And if I chose their proposal, this is primarily to join a Quality department enough developed in which it was possible for me to garner a consequent quantity of knowledge, and especially to work on Quality improvement process. Initially, I will present the Reuters Company and his subsidiary Reuters Financial Software, as well as the context, very rich, in which I evolved. Then, I will approach the project description by describing the actions, their justification and methods which were employed. The last part will deal with the realized work to end on an assessment of this training course. In conclusion, I will specify in what this training course was useful and complementary to my formation. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 5 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 1. PRESENTATION DE REUTERS 1.1. La naissance du groupe REUTERS En octobre 1851 Paul Julius Reuter, un immigré allemand, ouvrit un bureau dans la City de Londres, pour transmettre les cotations des marchés financiers entre Londres et Paris via le nouveau câble reliant Calais à Douvres. Deux ans auparavant, il utilisait des pigeons voyageurs pour envoyer ces mêmes informations entre Aachen et Bruxelles. Ce service fonctionna pendant une année, jusqu'à ce que la liaison télégraphique fût établie. Comme l’ agence devenait rapidement célèbre, Reuters a finalement étendu ses services à toute la presse britannique ainsi qu'à celle d'autres pays européens. Reuters a également élargi le contenu des informations traitées aux nouvelles d'ordre général et économiques du monde entier. La réputation de l'agence a brusquement décollé grâce à une succession de « scoops » retentissants. Par exemple, en 1865 Reuters était premier en Europe à annoncer l'assassinat du Président Lincoln aux États-Unis. À mesure que le réseau du télégraphe et des câbles sous-marins se développait en Europe, l'activité de Reuters se répandit hors des frontières européennes incluant l'ExtrêmeOrient en 1872 et l'Amérique du Sud en 1874. En 1883, Reuters se mit à utiliser un « column printer » pour transmettre les messages de façon électrique aux journaux de Londres et fut la première à utiliser la radio pour transmettre des nouvelles dans le monde entier. En 1927, elle introduisit le téléimprimeur pour diffuser les nouvelles aux journaux londoniens. En 1925, la « Press Association », l’ agence de presse du Royaume-Uni détenait la majorité de Reuters Ltd. et en 1939 la société transféra son siège social au 85 Fleet Street à Londres, où il est toujours basé aujourd'hui. Durant les deux guerres mondiales, Reuters, sous la pression du gouvernement britannique, était contraint de servir les intérêts britanniques. En 1941, Reuters se défait de cette charge en devenant une société anonyme. Les nouveaux dirigeants de la société, la presse britannique nationale et provinciale forment le « Reuters Trust », préservant indépendance et neutralité. Les principes du Trust furent maintenus et le pouvoir de les faire respecter fut renforcé quand Reuters devint une société publique en 1984. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 6 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 1.2. Le groupe Reuters est la plus grande agence de presse mondiale, avec une rédaction comprenant 2.300 journalistes et photographes répartis dans 196 bureaux desservant 130 pays. Reuters publie chaque jour environ 30 000 articles et plus de 8 millions de mots dans 26 langues sur la presse, la radio, la télévision, Internet et les assistants personnels (PDA). Leader mondial de l'information financière et des applications logicielles pour les institutions financières, plus de 330 000 professionnels des marchés financiers utilisent chaque jour les services d'information de Reuters dans le monde. Reuters diffuse des données sur plus de 5,5 millions d’ instruments financiers (actions, obligations, etc.), sur plus de 35 000 groupes dans le monde et sur 300 marchés internationaux. Le groupe est très attaché aux valeurs qui permettent son développement et sa solidité : l'indépendance et la fiabilité de l'information et l'éthique dans les relations avec ses partenaires. Reuters c'est plus de 15.000 collaborateurs répartis dans 91 pays, avec un chiffre d'affaires de 4,2 milliards d’ Euros. Les divisions principales de l'organisation sont : Figure 1 Répartition du CA et positionnement de RFS Sales and Trading La division « Sales and Trading » représente le marché le plus important de Reuters. Elle couvre toute la gamme de ses produits financiers. Elle fournit à ses utilisateurs négociant en changes étrangers des informations sur les «Fixed incomes», les actions, les matières Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 7 of 36 Copyright ©2006 Reuters Limited – All rights reserved. premières, l’ énergie et des analyses financières sur des marchés très interdépendants, et tout en temps en réel. Les services transactionnels proposés sont sans frais de courtage, ce qui permet aux acheteurs et aux vendeurs de réaliser leurs transactions aux meilleurs prix. Enterprise L’ objectif de la division « Enterprise » vise la réalisation d’ affaires avec des sociétés, plutôt que de cibler les utilisateurs. Elle fournit des systèmes permettant à ses clients de récupérer des données temps réel du marché (entre autres) pour leurs applications propriétaires et pour leur organisation. Elle fournit aussi des applications spécifiques leur permettant de contrôler et de gérer leurs risques. Research & Asset Management La partie « Research & Asset » Management se concentre sur le support des utilisateurs finaux que sont les courtiers, les managers de portefeuilles, les banquiers d'investissement et les analystes, qui procèdent à des décisions financières complexes à l'extérieur de l'environnement « Sales and Trading ». Media La division média, incluant la traditionnelle et très connue agence de presse Reuters, répond aux besoins des journaux internationaux, de la télévision, des opérateurs câblés, des stations radios, des sites internet, et des consommateurs. Les 3 premières divisions sont, entre autres, les distributeurs de logiciels financiers, développés par Reuters Financial Software, société présentée ci-après. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 8 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 1.3. Reuters Financial Software Le métier de Reuters Financial Software (RFS), éditeur de progiciels pour les salles de marché, le conduit à concevoir, développer, documenter, valider et maintenir ses logiciels. Créé en 1987, RFS, acronyme de Reuters Financial Software, est un leader mondial de l’ industrie logicielle pour la finance de marché. RFS réalise 96% de son chiffre d'affaires hors de son pays d'origine, avec près de 9 000 salles de marché équipées de ses produits, réparties à travers plus de 71 pays. Reuters Financial Software est l'un des principaux centres de développement d'applications et de solutions financières de Figure 2 : Historique du CA Reuters dans le monde. Depuis sa création, l’ entreprise est en constante évolution, en raison de l'élargissement de son offre de produits et de services, de son effectif en croissance continue (plus de 500 collaborateurs aujourd'hui) et de son fort positionnement au sein du Groupe Reuters. Son offre s'adresse aux opérateurs sur les marchés financiers, notamment pour la gestion des informations financières, des positions et des risques, la gestion des ordres d'achat et de vente d'instruments financiers. Le développement des produits génère par ailleurs des besoins de service croissants. Reuters Financial Software propose une offre complète de solutions Front to Back Office à travers des produits distribués dans le monde entier par Reuters. Véritable clé de succès dans son développement, ce système de distribution permet à Reuters Financial Software de se concentrer sur son métier de base, le développement des logiciels, faisant ainsi bénéficier les marchés d'une réelle avancée technologique. A l'écoute de ses clients, en anticipation constante sur leurs besoins, Reuters Financial Software a toujours eu une interactivité exceptionnelle avec le marché. Figure 3: Présentation des solutions Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 9 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Organisation et Direction RFS, est divisé en deux « Business Unit » distinctes (cf §1.2 Le groupe). Nous trouvons d’ un coté la BU « Sales and Trading » et de l’ autre la BU « Risk », où j’ ai effectué mon stage. C’ est cette dernière qui est présentée. La structure se présente en forme de râteau, où l’ on retrouve les différentes parties impliquées dans la conception des logiciels c'est-à-dire : le développement, la gestion de projet, le support Client, les responsables produits, l’ Assurance Qualité où j’ étais en poste, l’ ingénierie financière, et les responsables Off-shore . Eric Rumfels Head of Paris Development Amadou Konfe Head of Front to Back Development Stephane Vincent TRM Service Owner Andrew Hafemeister Head of Product Delivery Management Nicolas Liochon Jean-Francois Metzger Christine Voisin Franck Amiot F2B Architecture Kondor+ Trade Processing Kondor+ Front Kondor+ GUI Christophe Debarre Laurent Hallakou Daniel Vincent Kondor+ Studio Kondor Trade Processing Kondor+ Domain Steve Faye 3rd Level Support All Products Mike Thompson Documentation All products Carole Nakach Head of Product Delivery Management Back Office Didier Guber Didier Asseline Central Risk lab. Premium service Packaging, All products Andy Hafemeister Head Of Product Delivery Management Front Office Thierry Duchamp Quality Assurance Pascal Roy Financial Engineering Caroline Laurent Back Office Pascal Roy Front Office Bruno Joanides Product Delivery Manager Off-shore and Acquisition Figure 4: Organigramme de la société Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 10 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 1.4. Les différents Produits RFS Kondor Global Risk réunit les informations sur les limites de crédit et gère les données en temps réel sur tous les types d'instruments. Kondor Trade Processing a été conçu pour offrir au back office une série complète d'outils applicables à tous les instruments. Kondor Value at Risk est la solution permettant d'effectuer des analyses approfondies sur le risque de marché et le risque de crédit. Le système prend en charge une gamme complète de méthodes d'analyse du risque et comporte des outils d'analyse détaillée qui permettent d'identifier et de déterminer l'origine des risques. Reuters 3000 Xtra est un service d'informations à grande vitesse, destiné aux professionnels de la finance. Kondor+ est le produit phare de la gamme FA. Ce produit répond aux besoins des salles de marché en terme de gestion de front et middle office. Sa couverture fonctionnelle, comprenant la saisie des transactions, la gestion des positions, la valorisation de nombreux instruments financiers ainsi que l’ évaluation du risque lié à ces diverses activités, en fait un logiciel apprécié sur le marché. 1.5. RFS c’est aussi… Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 11 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 2. PRESENTATION DU SUJET 2.1. Contexte de l’Assurance Qualité chez RFS Le département Qualité existe chez RFS depuis 1999. L’ approche de cette époque, était de prévoir et vérifier le bon fonctionnement de leurs produits chez leurs Clients. Il s’ agissait de concentrer l’ effort sur les tests de charge et de performance pour valider l’ application dans un environnement utilisateur ‘ virtuel’ où un logiciel simulait la présence de nombreux utilisateurs simultanés sur l’ application à tester (AAT). La démarche consistait donc á vérifier que le logiciel soit bien fonctionnel dans cet environnement, plus spécifiquement que le temps de réponse des différentes actions jouées entre bien dans les spécifications de l’ AAT. La mise en place d’ une telle démarche sous entend le bon fonctionnement des produits. En 2002, suite à une modification à la tête de la Direction, et aux problèmes rencontrés après un changement d’ architecture, les objectifs du département QA ont radicalement changés. Les tests de performance sont mis de coté pour se focaliser sur l’ amélioration de la qualité des fonctions du produit, c’ est á dire vérifier que les résultats fournis sont corrects. Pour cela, une plateforme de tests off-shore réunissant une centaine de testeurs en Russie a été créée dans ce but. Le rôle de ces personnes possédant une formation conséquente en finance (équivalent Bac+5), était de vérifier, « à la main », les différentes fonctions des produits (Tests Fonctionnels). En 2005, de nouveaux changements ont lieu à la tête de RFS. Notamment la promotion d’ Eric Rumfels, une personne plus sensibilisée à la Qualité, qui est aujourd’ hui nouvellement promu à la tête de la business Unit Risk : « Head of Risk ». Un département d’ Assurance Qualité est un centre de coûts. A cette période, il était impossible de justifier le moindre euro investi, et la satisfaction des Clients ne décollait pas. Il fallait une nouvelle fois redéfinir la mission du QA, dimensionner de manière objective les ressources mises en œuvre, de manière à pouvoir obtenir rapidement un retour sur investissement. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 12 of 36 Copyright ©2006 Reuters Limited – All rights reserved. C’ est dans ce but que fut nommé Thierry Duchamp, en tant que manager du département QA. Il reprendra les acquis, les « best practices », abandonnés par ces différents prédécesseurs, et réduira les équipes en place pour opérer dans de meilleures conditions. Le QA possède donc depuis cette date un petit groupe de testeurs financiers, des testeurs de techniques, de performances, de charges ainsi qu’ un sénior de la Qualité Process, Stéphane Nanot, mon maître de stage. En plus des activités de validation, un des nouveaux objectifs du QA est l’ amélioration des process critiques. Démarche compliquée, nécessitant l’ appui des dirigeants pour disposer d’ un soutient suffisant afin d’ obtenir la coopération des employés ciblés. Pour justifier une telle activité, il a fallu définir et employer une méthode impliquant l’ équipe dirigeante. Elle se résume en 6 points : Identifier les critères de mesures de satisfaction Client Sélectionner les indicateurs pertinents en vue de l’ objectif défini Relever les données Analyser les bons ou mauvais résultats Identifier les acteurs impliqués Rapporter les études à la direction Une fois le process accompli, la direction est informée des dérives et des risques encourus par les projets. Il est alors possible d’ obtenir de leur part le feu vert pour les améliorations, et la détermination d’ objectifs futurs. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 13 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 2.2. Contexte de la gestion projet et de développement chez RFS Les différents produits de RFS sont tous complémentaires. La plupart communiquent entre eux (application front, back et middle office) ou utilisent souvent le même noyau. Le développement se fait selon un cycle en V itératif, où chaque lot d’ exigences Client est inclus dans une nouvelle itération, nouvelle sous-version (ex : v3.2.0.5) : Figure 5: Cycle de développement de RFS Chaque itération a lieu idéalement tous les 6 mois, pour limiter le risque de dérapage. A chaque itération, il est donc nécessaire de tester le produit. Ces tests englobent les nouvelles fonctionnalités, mais aussi les anciennes, car elles aussi peuvent être impactées par les changements. De la même façon, la découverte d’ un bug sur une certaine version d’ un produit entrainera le test des autres versions du même produit qui pourraient contenir ce même défaut. La correction du bug devra elle aussi être testée sur toutes les versions ! La fréquence assez soutenue des sorties, et donc des tests (Testing (System / Functional) sur la figure5), a amené le QA à préférer l’ utilisation des tests automatiques aux tests manuels off-shore (pas d’ imposition, pas de droit du travail, …). L’ analyse du déroulement des campagnes de tests ainsi que de leurs résultats représentent une partie importante du travail de l’ équipe Qualité transversale. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 14 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 2.3. Contexte de la qualité transversale Présentées précédemment, les activités de validation ne sont pas les seules préoccupations du département Qualité. Il y a, comme pour la majorité des entreprises éditrices de logiciels, beaucoup de points de dysfonctionnement, compromettant le bon déroulement des projets. Il s’ agit donc d’ identifier ces points d’ amélioration toujours en respectant cette directive : Définir les différents impacts de l’ amélioration Estimer le coût de l’ amélioration Pouvoir mesurer l’ impact de cette amélioration pour : RFS les Clients afin de pouvoir justifier l’ action menée. Ces points sont très importants. Il faut toujours avoir en tête que la Qualité est perçue dans une entreprise comme étant un centre de non-profit, voire de perte pour les financiers. Il faut tout de même rappeler que la Qualité a pour but final la mise en œuvre : d’ un processus de développement documenté, reproductible et efficace diminution des coûts de maintenance d’ une industrialisation des méthodes de travail réduction des coûts de développement d’ améliorer la crédibilité de l’ entreprise vis á vis de ses Clients et de la concurrence La Gagner des parts de marché problématique est que la mise en place d’ une telle démarche Qualité est longue et coûteuse, et qu’ il est très difficile de pouvoir avancer des chiffres sur les gains engendrés et même de s’ engager sur des résultats positifs. C’ est pour cela qu’ il faut s’ atteler en priorité sur des activités à courte durée, à retour sur investissement élevé. C’ est dans ce contexte que prend place ce stage. L’ objectif est de concrétiser les démarches nouvellement engagées en apportant une plus grande maturité aux activités de mesures. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 15 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 2.4. Problématique Pour un éditeur de logiciel, la problématique est de sortir le logiciel demandé à temps, et qu’ il comporte le moins de défauts possibles. Comme avec tout projet informatique, Reuters Financial Software est confronté à divers problèmes, dus principalement à l’ absence de processus contrôlés et prédictibles. Il a été mis en place, chez RFS, un bon nombre de pratiques (des exemples concrets seront présentés dans les prochains chapitres) visant à dénicher les points et les process à améliorer. Mais ces pratiques sont à l’ heure actuelle assez rudimentaires, pas très matures, et nécessitent un effort important pour les mettre en œuvre. L’ extension de leur utilisation à tous les produits est actuellement impossible au vu des ressources humaines disponibles. 2.5. Description du Projet Le projet est né de la volonté à résoudre le problème présenté ci-dessus. Ses exigences sont : • L’ industrialisation des méthodes déjà présentes • Leur amélioration • Apport d’ une plus grande valeur ajoutée (afin de susciter un plus grand intérêt) Une des réponses à ces exigences est l’ emploi d’ outils permettant d’ automatiser les méthodes. Nous verrons par la suite le détail de ces méthodes actuelles, et les moyens utilisés pour leur industrialisation. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 16 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3. ACTIVITES – TRAVAUX REALISES 3.1. Organisation du stage De part la nature du projet, le stage s’ est organisé autour de plusieurs étapes clefs. Il était primordial au début de s’ accoutumer à l’ environnement des projets et méthodes RFS et donc de travailler selon les process actuellement utilisés avec mon maitre de stage. La principale contrainte permettant le début du projet « Portail QA » était l’ acquisition du produit Business Objects. Une fois que la version d’ évaluation fut disponible, il était enfin possible de débuter la phase d’ évaluation du produit et de faisabilité. De même que l’ acquisition finale du produit, conditionnait la création des tableaux de bords sous BO. Figure 6: Ordonnancement des taches Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 17 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.2. Activités du QA Le domaine de la Qualité intervient majoritairement dans la gestion projet (valeur ajoutée importante). Il est très courant de remarquer le rapprochement physique des deux équipes. Le rôle du Chef de projet est capital, il est le garant de la bonne conduite des opérations. Pour se faire, il devra entre autre sonder et recueillir les états d’ avancement des différentes parties prenantes du projet pour identifier les risques éventuels, afin de mener des actions correctives, le cas échéant, le plus en amont possible. Le meilleur moyen pour s’assurer une Qualité minimum du management, pour tous les projets, indépendamment des compétences et de l’expérience du chef de projet, est d’institutionnaliser un process spécifique guidant la réalisation de certaines tâches, qui sera supporté par les personnes de l’Assurance Qualité. Ces personnes étant justement au contact de tous les projets, (caractéristique courante des équipes Qualité), il leur est d’ autant plus facile de recueillir les bonnes pratiques pour en faire profiter les autres et garantir ainsi le meilleur niveau de qualité possible. Le process, nommé « KPQP’ s » (Key Product Quality Parameters), devra être garant du suivi des activités de : Assurance Qualité Logicielle Gestion de projet Planning et progression Adéquation des spécifications Test Logiciel Déploiement du produit Documentation du produit Gestion des bugs Chaque Exigence représente un domaine particulier dont il faudra vérifier le bon fonctionnement par la mise en place de points de contrôle. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 18 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.3. KPQP’s des Tests de non-régression et CMMi Dans cette partie sera présentée la méthode de contrôle des activités. Il sera pris comme exemple le domaine du test, en particulier la Validation du produit. Pour ce faire, l’ utilisation d’ un modèle déjà éprouvé semble tout indiquée : le CMMi ! Ce modèle, dit de maturité, donne les grandes lignes à respecter pour construire des process robustes pour une organisation. Nous allons donc nous intéresser au domaine de processus (Process Area) appelé « Mesures et Analyses », se situant dans le niveau 2 de maturité. Figure 7: Niveaux du CMMi (source : Cours CMMi Quassi) Son but est, traduit de l’ anglais, de développer et maintenir une capacité de mesure qui sera utilisée afin de soutenir les besoins en gestion d’ informations. Nous identifions deux objectifs particuliers (Specific Goals) à atteindre, divisés en pratiques spécifiques (Specific Practices) : Aligner les activités de mesures et d’ analyses Expliciter la Etablir les objectifs Expliciter les collecte et la mesures sauvegarde de mesure Expliciter les procédures des données d’analyses Fournir les résultats de mesures. Collecter les Analyses les Sauvegarder données de données de les données et mesure mesure les mesures Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. Communiquer les résultats | Page 19 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Grace à ce modèle, nous disposons donc de toutes les étapes nécessaires pour mener à bien le processus des KPQP’ s. Cependant, il ne s’ agit pas de coller parfaitement à toutes les pratiques du CMMi, le but n’ est pas de se préparer à une évaluation officielle mais de profiter de ce vivier conçu autour des meilleurs retours d’ expériences. Revenons à l’ activité que nous souhaitons mesurer : les campagnes de tests de non- régression. Le but d’ une telle campagne est d’ identifier les défauts d’ un produit qui se sont déjà manifestés dans des versions antérieures ou supérieures. Le résultat d’ une campagne se compose des statuts de chaque vérification effectuée (test script : success ou failed). Voici un graphique présentant les différentes phases de déroulement d’ un projet chez RFS : Figure 8: Déroulement temporel d’ un projet Chaque Load représente l’ implémentation d’ un certain nombre d’ exigences. La phase Ex-Dev représente la correction des bugs et la validation finale de l’ application. F4L correspond au moment de décision de sortie ou de report du produit sur le marché. RRG signifie que le produit est prêt à être vendu. Comme expliqué dans la partie contexte, les nouvelles versions de produits sont l’ ajout de nouvelles fonctionnalités. A chaque fin de Load est exécutée une campagne de tests pour vérifier que ces ajouts n’ ont pas créé de problèmes à l’ ensemble du produit. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 20 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.3.1 L’ Expliciter les mesures ; Etablir les objectifs de mesure enjeu est de découvrir l’ état dans lequel se trouve actuellement l’ application pour que le chef de projet puisse immédiatement prendre des actions correctives le cas échéant. La validation porte sur les aspects techniques et fonctionnels (domaine de la finance) du produit. Il faudra donc définir les objectifs des : Tests Logiciel o Tests de non-régression de bugs fonctionnels o Tests de non-régression de bugs techniques o Création de scripts de tests pour les bugs importants rencontrés par les Clients. (Un script de test correspond à la vérification d’ une fonctionnalité du produit. Il n’ est malheureusement pas possible (trop coûteux) de couvrir toutes les fonctionnalités) La définition de ces objectifs ne peut se faire qu’ avec les parties impliquées, c’ est à dire avec l’ ingénierie financière, le développement et le QA. Le QA a donc la tâche d’ organiser des réunions avec les responsables des équipes et de proposer des estimations, à partir d’ informations recueillies sur le projet d’ une version antérieure, si elle existe, ou sur un autre projet similaire de l’ organisation. Il serait peu judicieux de laisser, par exemple, le Développement définir seul ses propres objectifs. Mais avant de récupérer nos cibles, il est préférable d’ o o Tests de non-régression de bugs fonctionnels : Bugs identifiés Evolution de la correction La densité des bugs Couverture de test de l’ application Tests de non-régression de bugs techniques o expliciter ce que l’ on va mesurer : Vérification de l’ installation / mise à jour Création de scripts de test Création de scripts couvrant la découverte (Client) de bugs importants. (Les bugs Clients correspondent aux autres versions du produit actuellement sur le marché). Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 21 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Quoi mesurer ? Comment on été trouvés ces critères ? Il ne s’ agit pas de réinventer la roue ! Il existe aujourd’ hui des études et des livres suffisamment complets sur le domaine permettant d’ identifier les indicateurs associés au besoin. J’ encourage à consulter notamment “ Metrics And Models In Software Quality Engineering” ainsi que le PSM (voir bibliographie) collant au plus près aux exigences du CMMi. Le résultat de ce travail a conduit à l’ élaboration d’ une feuille Excel regroupant tous les besoins : KPQP Dimension Software Testing Category Nonregression testing Measurement Definition Target Minimum Acceptable Level (Showstopper if not met prior to launch) Missions Non regression functional testing xx% of the application covered No bug open at the end of test campaign Bug density <= 2 for 1000 test results Provide sign-off for each load (20% of the application covered) All bugs corrected Mission 4: Non regression Testing Test Script Creation for sev1/2 Bugs 10% of the current regression testing scope for sev1/2 bugs 10% of the current regression testing scope for sev1/2 bugs Mission 4: Non regression Testing Non regression technical testing No bug for Install and upgrade No bug in standard configuration No bug for Install and upgrade Mission 4: Non regression Testing Figure 9: Extrait des KPQP’ s Excel Cet (extrait) de feuille de travail est suivi de la création d’ un document de communication sous Lotus Notes permettant à l’ ensemble des employés concernés d’ y accéder : Figure 10: Extrait des KPQP’ s sous Lotus Notes Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 22 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Expliciter la collecte et la sauvegarde des données ; Expliciter les procédures d’analyses 3.3.2 Ici, le CMMi exige la rédaction de documents informant sur les processus de collecte de données, de sauvegarde et d’ analyse. Ces documents sont surtout utiles pour prouver que l’ on a effectivement accompli ces tâches lors des évaluations. Ils peuvent aussi servir comme documents de formation aux nouveaux arrivants. Ils n’ existent pas et je n’ ai pas rédigé de tels documents, pour la simple raison que ces méthodes de collecte et sauvegarde vont justement être changées, révolutionnées, par le projet de portail Qualité. Nous en avons donc fini avec la première partie mettant en place le processus des KPQP’ s Il s’ agit maintenant d’ expliciter sa mise en œuvre! Collecter les données de mesure 3.3.3 Les résultats des campagnes de tests sont stockés dans la base de données de l’ outil utilisé : Mercury Quality Center. Pour collecter ces données, nous utilisons un produit spécifique : Business Object. Grâce à l’ utilisation de requêtes SQL interrogeant la base nous DONNEES pouvons récupérer les données des Lotus Notes Bug Tools Test Management Push Notes Requirements Specifications Sybase Microsoft SQL Server Test Performance K+ Repository Changes Test Performance campagnes à chaque instant ! Les résultats de ces extractions se récupèrent sous la forme d’ un fichier Excel. Outil à partir duquel il COMMUNICATION TRANSFORMATION est très efficace de traiter des informations numériques. traitement Nb : La version de BO utiliséw est Traitement traitement très ancienne (v5.1). Quand il est question de l’ acquisition de BO, il s’ agit bien sur de la dernière Lotus Notes version (vXI r2) Presentation des tableaux de bord et diffusion ATR (Automated Test Reports) Figure 11: Process de construction de tableau de bord (source document RFS) ` Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 23 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Analyse des données de mesure 3.3.4 L’ analyse des données de mesure se fait conformément à la description des indicateurs choisis. Tests de non-régression de bugs fonctionnels et Création de scripts Number of Test Cases (the higher the better) Bug De nsity Comparaison by Load - Kondor Plus 3.0 - Bug Density - Minimum Acceptance Level Bug Density (the low er the better) 10000 16 Bug Density - Target to aim 15.02 9000 9395 8302 7000 14 12 7990 7484 10 6000 6115 5000 8 7.91 4784 4000 6 3653 3000 4.47 3.97 3160 3.74 3.31 2000 1000 3620 3.13 4 3.00 2.45 1598 Bug density Number of Test Cases 8000 2 1.37 0 0 3.0.0.L8 3.0.0.L9 3.0.0.L10 3.0.0.L11 3.0.0.L12 3.0.1.L1 3.0.2.L2 3.0.2.L3 3.0.2.L4 3.0.2.L5 Loads Figure 12: Mesure de la densité de bugs du produit Kondor+ 3.0 Ici, en un seul graphique on arrive à répondre à la majorité des besoins. Il est inutile d’ assommer le lecteur avec de nombreux graphiques incompréhensibles. On peut visualiser le nombre de cas de tests (qui ont fonctionné durant la campagne), ici toujours en augmentation, ce qui signifie que la couverture de tests de l’ application est grandissante. Après investigation (voir 3eme graphe), la baisse effective en 3.0.2.L4 est due à des échecs techniques du robot de tests. Des cas de tests n’ ont donc pas pu se lancer. La « Bug Density » est le rapport du nombre de bugs trouvés sur le nombre de cas de tests. Plus le cas de tests est important, plus les indicateurs s’ avèrent justes ! On peut ainsi se représenter la qualité de l’ application. Le but de cette partie n’ est pas d’ expliquer les métriques, mais il m’ a paru néanmoins très intéressant de le /faire, car cette métrique en particulier s’ avère très représentatif de la qualité d’ un logiciel et de l’ activité de validation ! Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 24 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Tests de non-régression de bugs techniques Kondor Plus 3.0 - Bug Status for Upgrade Tests by Loads 18 16 16 Number of Bugs 14 12 10 9 8 7 6 4 3 3 2 2 1 1 0 0 3.0.0.L8 3.0.0.L9 3.0.0.L10 3.0.0.L11 3.0.0.L12 3.0.1.L1 3.0.2.L2 3.0.2.L3 0 3.0.2.L4 3.0.2.L5 Figure 13: Historique de bugs des mises à jour Ici il s’ agit simplement de rapporter le nombre de problèmes rencontrés lors de la mise á jour du produit. Figure 14: Historique des résultats des tests scripts Là, c’ est la présentation du fonctionnement de l’ activité de tests. On voit que le nombre de scripts de tests (réussis) d’ une campagne est dépendant du nombre de scripts en général, et à la qualité du process de tests ! On peut ainsi prendre des décisions d’ amélioration en connaissance de cause. Par exemple la nécessité d’ améliorer le Framework de test (a été nécessaire jusqu’ à la Load12) ou Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 25 of 36 Copyright ©2006 Reuters Limited – All rights reserved. d’ augmenter les ressources pour les tests (serveurs), pour faire diminuer le nombre de Tests Scripts incomplets. Aujourd’ hui il est possible de faire passer 8000 cas de tests en 3 heures sur Kondor+ 3.0 ! 3.3.5 Sauvegarder les données et les mesures ; Communiquer les résultats La sauvegarde s’ effectue simplement par le stockage des fichiers Excel bruts et retravaillés (graphiques) dans un référentiel contrôlé par la gestion de version. La communication de tous les résultats d’ analyse d’ une Load se réalise sous Lotus Notes, dans un document appelé Dashboard, où sont aussi jointes les feuilles de données Excel. Dans ce cas particuliers (résultat des campagnes de tests) où les informations sont plus abondantes, on rédige un document spécifique, appelé ATR, pour Automated Test Result. Figure 15: Extrait du résumé d’ un ATR du produit Kondor+ 3.0 Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 26 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.4. Indicateurs orientés Clients Les indicateurs présentés ainsi que ceux définis dans les KPQP’ s n’ ont pour but que d’ améliorer la qualité du produit. Comment considérer l’ impact réel de ces améliorations au bout de la chaine, chez le Client ? N’ ayant aucun contact direct avec les Clients, il a fallu utiliser la seule ressource à notre disposition, la base de données du Support, où sont enregistrés tous les appels clients. Ainsi nous avons à notre disposition tous les problèmes rencontrés par les clients ainsi que leurs évolutions. A partir des données mises à notre disposition, il a fallu sélectionner les métriques les plus pertinentes (Cf Annexe « Risk Corporate Metrics ») : Backlog Management Index FIXED BUG SRs Backlog and Management Index OPEN SRs conduct to BUG BM I 700 BM I Control 600 BM I M inim al Acce ptance Le ve600 l 700 500 500 400 400 300 300 200 200 100 100 0 0 Jan05 Feb05 Mar05 A pr05 May05 Jun- Jul-05 A ug05 05 Sep05 Oct05 Nov05 Dec05 Jan06 Feb06 Mar06 A pr06 May06 Percent - Open/Closed problems Number of SRs - KTP - Jun- Jul-06 06 Date Figure 16: Historique de l’ efficacité de la correction de bugs Qui rend compte de l’ arriéré en bugs d’ un produit et la tendance actuel ; c’ est à dire le ratio entre le nombre de nouveau bug découvert / bugs corrigés. Si le BMI > 100, l’ application a un nombre de bugs total en diminution. La particularité de cette métrique est de tenir compte de la correction de bug, ce qui la rend particulièrement complémentaire à l’ ATR, qui ne rend compte que des bug trouvé. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 27 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Fix Quality Ope n SRs le ading to Re gre s s ion Bugs Fix Quality Clos e d Srs le ading to Bugs Fi x Qua l i ty M AL - Kondor+ - Fix Quality Fi x Qua l i ty Ta rget 12 10 200 8 150 6 Fix Quality Number of Service Requests (SRs) 250 100 4 50 2 0 0 Jan05 Feb05 Mar05 A pr- May05 05 Jun- Jul-05 A ug- Sep05 05 05 Oct- Nov- Dec05 05 05 Jan06 Feb06 Mar06 A pr- May06 06 Jun- Jul-06 06 Date Figure 17: Qualité des corrections dans le temps Rend compte de la qualité ou de la défaillance de la correction des bugs : Nombre de bugs qui ont été ré-ouvert. Ce type de métriques est extrêmement important car elles permettent de donner une vision globale et réels de la situation, ainsi que les impacts des changements engendrés par les actions Qualités et autres. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 28 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.5. Projet Portail Qualité 3.5.1 Objectifs Comme expliqué dans la description du projet §2.5, il s’ agit d’ automatiser le process de collecte, sauvegarde et présentation de données, pour les appliquer à l’ ensemble des produits de RFS. Seule la partie analyse, c’ est à dire les commentaires des graphiques et les investigations, devront être exécutées manuellement. Dans le paragraphe §2.7, il a été présenté seulement une partie des mesures effectuées au niveau de la Validation. Il existe bien d’ autres mesures réalisées, notamment concernant la Gestion de Projet, le Développement, le Support,… etc. (cf Objectifs KPQP’ s §2.7.1) qui nécessite l’ exécution d’ opérations radicalement différentes sur d’ autres outils et bases de données. 3.5.2 Collecte des données : ETL Pour répondre au besoin de la collecte d’ informations, il existe des applications spécialisées appelées ETL (Extract, Transform and Load), faisant partie d’ une famille d’ outils appelés « Business Intelligence ». Elles permettent la manipulation de données hétérogènes en provenance de différentes applications, fichiers, bases de données, bases de métadonnées, pour les stocker dans un référentiel. Notons qu’ ici nous répondons à une exigence du CMMi, SP1.4 du Domaine de Process « Organizational Process Definition », qui est d’ établir un référentiel de mesure. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 29 of 36 Copyright ©2006 Reuters Limited – All rights reserved. EXTRACTION TRANSFORMATION Transformation ENREGISTREMENT Entrepot de données Nettoyage Applications (CRM, ERP) Extraction Chargement Systemes propriétaires Source de données transitoires “Data Mart” Applications internet Le process convertit les données extraites depuis sa forme originale en format correspondant á la base de données cible. La Transformation s’effectue par l’utilisation de regles, de tables de correspondance ou par la jointure de données. Process de lecture de données á partir de sources d’information. Process d’enregistrement des données dans la base cible. Figure 18: Principes d’ un ETL L’ intérêt d’ utiliser un tel outil, est bien sur la rapidité de la collecte de données, mais aussi de leur apporter une valeur ajoutée non négligeable. C’ est à dire la possibilité de créer des jointures entre les différentes sources de données. Par exemple entre la base de report horaire d’ activité et les activités elles-mêmes, ce qui offre une nouvelle vision au chef de projet : les coûts ! Voici la marche à suivre qui a été établie pour la mise en œuvre : Recenser toutes les bases utiles de l’ organisation Concevoir la base de données servant de référentiel de mesures Etablir un cahier des charges pour l’ ETL Evaluer les solutions logicielles Achat Mise en œuvre du projet Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 30 of 36 Copyright ©2006 Reuters Limited – All rights reserved. Le recensement de toutes les bases utiles effectué, il faudra s’ assurer qu’ il n’ existe pas d’ incompatibilité entre l’ ETL et celles-ci. La figure 18 représente les relations entre le référentiel de mesure et toutes ses bases sources. La sélection des produits s’ est faite parmi les licences dont dispose RFS. Il s’ agit des produits : BusinessObjects Data Integrator Compuware File Aid TIBCO Data Exchange L’ évaluation (cf Annexe AN 1) de ces Figure 19: Workflow de création de tableau de bord produits a consisté en l’ extraction de données types à partir de chacune de ces bases. L’ étude approfondie de Data Integrator, qui m’ a permis de découvrir le fonctionnement et l’ utilisation d’ un ETL, a débouché sur la rédaction d’ un document (cd Annexe AN2) décrivant tous les problèmes rencontrés avec le logiciel et une communication active avec le support pour leurs résolutions. Malheureusement un bug bloquant m’ a empêché de retenir ce produit. C’ est finalement Tibco Data Exchange qui est sorti vainqueur de cette confrontation ! Présentation Opération de jointure des donnés rapide de l’ application : Permet le ‘ reverse- engineering’ des bases de Lecture de 2 tables de 2 sources différentes Enregistrement des résultats dans la base de mesure et dans un fichier pour test données pour les visualiser graphiquement. Visualisation graphique des tables à manipuler ainsi que des opérations Serveur de tâches isolé Duplication des donnés permettant d’ effectuer les transformations Figure 20: Capture d’ écran du logiciel Data Exchange sur une machine spécifique avec des possibilités de planification. Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 31 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 3.5.3 Une BusinessObjects fois les données collectées quotidiennement par l’ ETL, il va falloir les exploiter pour créer les tableaux de bords. Grace à Business Object XI et son module Dashboard, il est possible d’ automatiser ce process, par la création de modèle de document, où les graphiques sont mis à jour en temps réel. Figure 21:Exemple de Tableau de bord (Source plaquette BO) Le travail sur cette partie n’ a pu encore débuter, à cause de problèmes survenus lors du process d’ acquisition. J’ ai pu néanmoins découvrir le logiciel à partir de la version d’ évaluation. J’ ai aussi participé aux réunions avec les commerciaux de Business Objects, à la démonstration de l’ avant vente, ainsi qu’ à l’ étude de la proposition commerciale. Le second grand intérêt d’ obtenir des tableaux de bords en temps réel est d’ augmenter le pouvoir décisionnel du QA face aux autres parties pendant la réunion du Fitness For Launch, où est décidé la sortie ou le report du produit. Car actuellement, il faut 5 jours-homme pour réaliser un tableau de bord, les données présentées lors de ces réunions ne sont donc pas sans faille. Figure 22: Déroulement temporel d’ un projet Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 32 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 4. CONCLUSION Pour conclure, ce stage à Reuters Financial Software a été une vraie réussite pour moi – même et pour l’ entreprise. J’ ai pu acquérir les méthodes Qualité propres à un grand groupe réputé dans l’ édition logicielle, et les mettre en œuvre pour aider au maintient et à l’ amélioration de la qualité sur plusieurs produits. On m’ a laissé l’ opportunité de participer à la mise en place d’ indicateurs, la collecte et l’ analyse de données, ainsi que le « reporting » d’ informations. J’ ai eu aussi la chance de vivre le démarrage d’ un projet, KGR3.2, de préparer et participer aux réunions définissant ses KPQP’ s. J’ ai pu aussi découvrir le monde de la Business Intelligence et de ses outils, améliorer mon anglais, dans un univers entièrement anglophone, et par la rédaction de nombreux documents dans la langue de Shakespeare. Mais par dessus tout, c’ est essentiellement les retours d’ expériences qui m’ ont le plus enchanté. J’ ai pu grâce à eux intégrer dans mes méthodes les dimensions prévisionnelles, de résultat, de justification, de remise en question, de renonciation et de cout. Du côté vie en entreprise, j’ ai pu vivre d’ importants changements au sommet, des réorganisations, le rachat d’ une compagnie. J’ ai pu percevoir l’ importance des relations humaines, cruciales dans le domaine de la qualité, où l’ on est constamment en relation avec toute l’ organisation, et la difficulté de manager les collaborateurs. Mais j’ ai pu néanmoins profiter de ma situation de stagiaire, qui m’ a apporté une grande liberté de communication ! C’ est donc avec ces 6 mois d’ expériences, qui m’ ont beaucoup apporté en maturité, que je vais pouvoir aborder sans appréhension de nouveaux challenges ! Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 33 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 5. BIBLIOGRAPHIE – WEBOGRAPHIE Bibliographie: Capability Maturity Model, Software Engineering Institute, March 2002 Practical Software Measurement: Measuring for Process Management and Improvement, Software Engineering Institute, April 1997 Metrics and Models in Software Quality Engineering, Second Edition, Addison Wesley, ISBN: 0-201-72915-6 Webographie : The Data & Analysis Center for Software (08/2006) http://www.thedacs.com/ Goal Question Metric approach (08/2006) http://www.goldpractices.com/practices/gqm/index.php Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 34 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 6. TABLE DES ILLUSTRATIONS Figure 1 Répartition du CA et positionnement de RFS ___________________________________________ 7 Figure 2 : Historique du CA___________________________________________________________________ 9 Figure 3: Présentation des solutions ___________________________________________________________ 9 Figure 4: Organigramme de la société ________________________________________________________ 10 Figure 5: Cycle de développement de RFS ____________________________________________________ 14 Figure 6: Ordonnancement des taches ________________________________________________________ 17 Figure 7: Niveaux du CMMi (source : Cours CMMi Quassi) ______________________________________ 19 Figure 8: Déroulement temporel d’ un projet __________________________________________________ 20 Figure 9: Extrait des KPQP’ s Excel _________________________________________________________ 22 Figure 10: Extrait des KPQP’ s sous Lotus Notes ______________________________________________ 22 Figure 11: Process de construction de tableau de bord (source document RFS) ____________________ 23 Figure 12: Mesure de la densité de bugs du produit Kondor+ 3.0 _________________________________ 24 Figure 13: Historique de bugs des mises à jour ________________________________________________ 25 Figure 14: Historique des résultats des tests scripts ____________________________________________ 25 Figure 15: Extrait du résumé d’ un ATR du produit Kondor+ 3.0 _________________________________ 26 Figure 16: Historique de l’ efficacité de la correction de bugs ____________________________________ 27 Figure 17: Qualité des corrections dans le temps _______________________________________________ 28 Figure 18: Principes d’ un ETL ______________________________________________________________ 30 Figure 19: Workflow de création de tableau de bord ____________________________________________ 31 Figure 20: Capture d’ écran du logiciel Data Exchange _________________________________________ 31 Figure 21:Exemple de Tableau de bord (Source plaquette BO) ___________________________________ 32 Figure 22: Déroulement temporel d’ un projet _________________________________________________ 32 Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 35 of 36 Copyright ©2006 Reuters Limited – All rights reserved. 7. ANNEXES KGR3.2 KPQP’ s – Feuille Excel I Risk Corporate Metrics II Business Objects Product Evaluation III Study : Business Objects – Data Integrator IV Ferrand Steeve – Rapport de stage Copyright ©2006 Reuters Limited – All rights reserved. | Page 36 of 36