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
| Page 2 of 36
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.
| Page 3 of 36
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
| Page 4 of 36
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.
| Page 5 of 36
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.
| Page 6 of 36
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
| Page 7 of 36
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.
| Page 8 of 36
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
| Page 9 of 36
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é
| Page 10 of 36
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…
| Page 11 of 36
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.
| Page 12 of 36
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.
| Page 13 of 36
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.
| Page 14 of 36
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.
| Page 15 of 36
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.
| Page 16 of 36
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
| Page 17 of 36
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.
| Page 18 of 36
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
Communiquer
les résultats
| Page 19 of 36
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.
| Page 20 of 36
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

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é).
| Page 21 of 36
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
| Page 22 of 36
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)
`
| Page 23 of 36
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 !
| Page 24 of 36
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
| Page 25 of 36
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
| Page 26 of 36
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é.
| Page 27 of 36
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.
| Page 28 of 36
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.
| Page 29 of 36
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
| Page 30 of 36
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.
| Page 31 of 36
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
| Page 32 of 36
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 !
| Page 33 of 36
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
| Page 34 of 36
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
| Page 35 of 36
7.
ANNEXES
KGR3.2 KPQP’ s – Feuille Excel
I
Risk Corporate Metrics
II
Business Objects Product Evaluation
III
Study : Business Objects – Data Integrator
IV
| Page 36 of 36