Avertissement

Si vous arrivez directement sur cette page, sachez que ce travail est un rapport d'étudiants et doit être pris comme tel. Il peut donc comporter des imperfections ou des imprécisions que le lecteur doit admettre et donc supporter. Il a été réalisé pendant la période de formation et constitue avant-tout un travail de compilation bibliographique, d'initiation et d'analyse sur des thématiques associées aux concepts, méthodes, outils et expériences sur les démarches qualité dans les organisations. Nous ne faisons aucun usage commercial et la duplication est libre. Si vous avez des raisons de contester ce droit d'usage, merci de nous en faire part . L'objectif de la présentation sur le Web est de permettre l'accès à l'information et d'augmenter ainsi les échanges professionnels. En cas d'usage du document, n'oubliez pas de le citer comme source bibliographique. Bonne lecture...

Application d'une démarche CMMI pour la réalisation d'un daschboard automatisé

Imen ABBES

Référence bibliographique à rappeler pour tout usage : Application d'une démarche CMMI pour la réalisation d'un dashboard automatisé, Imen ABBES, Stage professionnel de fin d'études, MASTER Management de la Qualité (MQ), UTC, 2006-2007, URL : https://www.utc.fr/mastermq ; Université de Technologie de Compiègne

RESUME La mission de mon stage à Reuters Financial Software est de suivre une démarche selon le modèle CMMI pour la  Réalisation d’un système de Dashboard automatisé de métriques Qualité KPI (Key Performance Indicator). Pour ce faire, j’ai réalisé les étapes suivantes :    Mettre en place une démarche d’amélioration de la qualité selon CMMI via le processus « Mesure et Analyse » Collecter les besoins et spécifier les métriques à partir du PSM (Practical Software and System Measurement) Concevoir la base de données de stockage (Datamarts Qualité)  Extraire les données via l’ETL à partir des sources des données initiales Implémenter les métriques Qualité sur Business Objects et publier les rapports dans InfoView Mots clés : CMMI, Processus  mesure et analyse , KPIs, PSM,ETL,Business Object

ABSTRACT The mission of my training in Reuters Financial Software is to follow steps according to CMMI model to realize an automated Dashboard system of KPI (Key Performance Indicator). During my training course, I carried out the following stages: Application of the CMMI model to the project using the “Measurement and analyzes” process area To collect data and specify the metric from the PSM (Practical Software and System Measurement). To conceive the data base of storage (Datamarts Quality) To Extract data from the initial sources with the ETL To Implement metric Quality on Objects Business and publish the reports in InfoView Key word: CMMI, Process Measurements and analyzes, KPIs, PSM, ETL, Business Object

Remerciements

Je  remercie  Mr Thierry Duchamp Directeur d’équipes du département « Assurance et Qualité »  pour m’avoir permis de réaliser ce stage de fin d’études au sein de Reuters Financial Software.

Mes plus sincères remerciements à mon maître de stage, Mr Hervé Kurfurst, auprès duquel j’ai beaucoup appris, tant du point de vue professionnel qu’au niveau relationnel.

Je remercie aussi Mr Tuan Nguyen Manh, pour son aide et les discussions enrichissantes que nous avons eues.  

Merci également à toutes les personnes de Reuters Financial Software avec qui j’ai eu l’occasion de travailler pendant cette période.  

Je remercie également tous mes enseignants à l’Université de Technologie de Compiègne, mon Tuteur Mr Gilbert FARGES et Mr Jean-Pierre CALISTE pour la qualité de la formation dont j’ai bénéficié durant cette année universitaire.  

Sommaire

Introduction

Mon stage à Reuters Financial Software s’est déroulé entre Janvier et Juin 2007 dans le département Assurance Qualité. La mission du stage consiste en la réalisation d’un tableau de bord automatisé à base d’indicateurs qualité (KPIs).
Tout en suivant une démarche de préparation à une évaluation de maturité du niveau 2 CMMI, les actions à réaliser sont
   - Adapter le référentiel CMMI aux besoins du projet.
  - Identifier et formuler les indicateurs répondants aux objectifs.
  - Rechercher, interpréter, extraire et traiter les paramètres formulant les indicateurs.
 - Concevoir les bases de stockage.
 - Concevoir et implémenter le tableau de bord.
    Ainsi, nous commencerons par étudier le contexte, les enjeux et la problématique du stage. Ensuite, nous nous intéresserons à la résolution et l’application des actions. Finalement, nous présenterons les résultats et les perspectives.


1Contexte et enjeux du stage

1.1    PRESENTATION DE LA SOCIETE


                                Figure 1 : Le building de Reuters


Reuters, fondé à Londres en 1851, est un groupe mondial d’information fournissant des données pour les médias, les services et les marchés financiers.
Le groupe compte 17 000 collaborateurs, répartis dans 89 pays, et son chiffre d’affaires est de 3,5 milliards d’euros.
Reuters est souvent cité comme première agence de presse internationale au monde, et bien que sa rédaction comprenne 2300 journalistes répartis dans 197 bureaux (130 pays), ce domaine ne représente que 5% de son chiffre d’affaires.
En effet, 90% des revenus du groupe proviennent de services financiers, dont l’offre est basée sur la distribution d’information financière, et la mise à disposition d’outils d’analyse, de trading et de messagerie aux professionnels de la finance. Ses informations financières proviennent de 244 marchés et sont actualisées 8 000 fois par seconde.
Reuters joue un rôle essentiel dans le fonctionnement des marchés financiers et des médias, et ce sont au total 30 000 dépêches - 8 millions de mots - qui sont publiées quotidiennement et traduites dans 24 langues. Pour plus de détaille  (Annexe 1)

1.1.1    Les métiers Reuters

                
                                Figure 2: Revenus du Groupe Reuters par segment


La figure 2 montre que le groupe est divisé en quatre segments reflétant les principaux métiers de ses clients, chacun étant doté de produits et de services adaptés aux secteurs visés. Les trois premiers concernent les marchés financiers, alors que le dernier utilise les données Reuters dans un contexte plus général : [1]

• 50% : Sales and Trading –plus grand marché du groupe Reuters – regroupe les produits destinés à la gestion de devises, de revenus et d’actions.
• 10% : Research and Asset Management – concerne les produits d’aide à la décision pour les managers de portefeuille d’actions, les investisseurs et les analystes.
• 20% : Enterprise – vise l’entreprise dans sa totalité et non un utilisateur unique, et s’attache à fournir aux organisations des données en temps réel du marché et de leur environnement industriel. Ce segment regroupe aussi les produits d’analyse et de gestion des risques.
• 6% : Medias – activités des médias servant les besoins des journaux, des réseaux de télévisions, des stations radio et des sites Internet.
• 14%: autres revenues

1.1.2    La filiale Reuters Financial Software

Créé en 1987, la société Reuters Financial Software (RFS), anciennement nommée EFFIX et filiale à 100% du groupe Reuters (voir Annexe 1).

1.1.3    Activité
Reuters Financial Software est un éditeur de progiciels pour les salles de marchés. Située à Paris La Défense, c’est l’un des principaux centres de développement d’applications et de solutions financières de Reuters dans le monde.

1.1.4    Place au marché et concurrents
Reuters, Thomson et Bloomberg étaient concurrents sur le lucratif marché de l'information financière, fournissant des données aux plus grandes banques et sociétés de courtage. Reuters fut numéro un du marché pendant plusieurs années avant de perdre du terrain au profit de Bloomberg, qui détient 33 % de parts de marché.
Le mardi 15 mai, le groupe d'information financière britannique Reuters a accepté d'être racheté par son concurrent Thomson pour 8,7 milliards de livres (environ 12,8 milliards d'euros), pour créer le numéro un mondial du secteur devant l'américain Bloomberg.

Ce rachat permet à Thomson-Reuters de passer, avec 34 % de parts de marché, d'une courte tête, devant son concurrent Bloomberg. [2]

retour sommaire

1.2    CONTEXTE DU STAGE
 
1.2.1    Contexte générale : Rôle du département Assurance Qualité (QA)

Mon stage au sein de Reuters Financial Software s’est déroulé entre janvier et juin 2007 dans le département QA (assurance  qualité). L’équipe QA est composée de 25 personnes ayant pour rôle de mettre l’accent autant sur le contrôle des produits que sur celui des activités, de manière à assurer que RFS développe bien le produit, et qu’elle développe le bon produit selon la bonne méthode.

1.2.2    Contexte Spécifique  
Deux contextes spécifiques sont à l origine de mon stage:

• Contexte1 : Assistance qualité du processus: Reuters Proposition Delivery (RPD)
• Contexte2 : Préparation à une certification CMMI

Dans une première partie : nous décrivons le processus RPD et sa relation avec le stage.
Dans une deuxième partie : nous présentons l’approche qualité du département QA. Ensuite, nous décrivons le modèle CMMI ainsi que les raisons de son choix parmi d’autres. Finalement, nous présentons le contexte du stage par rapport à l’approche CMMI.
Contexte 1 : Assistance qualité du processus (RPD)
Le processus RPD :
La réalisation de tout progiciel suit un processus défini au sein de Reuters Financial Software se nommant : le Reuters Proposition Delivery (RPD)
Le RPD est une structure permettant la gestion de propositions sur leur cycle de vie complet – de l’idée naissante à la phase d’obsolescence (Annexe3) : voir ci-dessous une illustration de ce cycle.

   
Le contexte de stage est lié aux trois phases du cycle de vie: la phase « Definition », la phase « Delivery »  et la phase « Deployment ». (Annexe 2)

Contexte du stage vis-à-vis du RPD
L’Assistance qualité des trois phases entourées en rouge figure 3 est composée de plusieurs activités  dont l’activité  «réalisation de KPIs » se répète dans chaque phase (voir Figure 4).
Cette activité consiste en la fourniture des indicateurs de performance (KPIs : Key performance Indicator) permettant de suivre l’évolution de chaque phase et d’évaluer la performance globale.

retour sommaire

        
             Figure 4 : Activités des phases « Definition », « Delivery »,  « Deployment ». [3]

C’est dans le contexte de l’assistance qualité du RPD via la réalisation des KPIs que se place la mission de stage.
Contexte 2 : Préparation à la certification CMMI
Le département Assurance qualité (QA) a pour objectifs de :

• Améliorer la qualité du produit livré et la productivité du projet.
• S’assurer que les déviations et les non-conformités sont suivies jusqu'à leur résolution.
• Augmenter la satisfaction du client en répondant mieux à ses exigences
• Donner une meilleure visibilité au management et permettre une meilleure gestion des risques.

Pour mieux réaliser ses objectifs, RFS suit un référentiel qualité adapté à son type d’activité d’éditions de logiciels. Ce référentiel est le modèle CMMI (Capability Maturity Model Integration).

Raisons du choix du CMMI parmi les autres modèles

• Les principaux référentiels de bonnes pratiques, adaptés aux activités informatiques et actuellement en vogue, sont : [4]
• COBIT (Control Objectives for Business & Related Technology) : Le COBIT (Control Objectives for Business & Related Technology), est utilisé pour la gouvernance et l'audit des systèmes d'information
• ITIL (Information Technology Infrastructure Library) : L'ITIL s'intéresse à la production, qu'il s'agisse de fourniture de services informatiques ou d'exploitation interne. C'est donc une voie pour s'assurer de la satisfaction des utilisateurs et/ou des clients (internes ou externes) des services informatiques
• CMMi (Capability Maturity Model intégration) : Le CMMi est le référentiel dédié au développement de systèmes et logiciels
• Outre ces trois référentiels, il en existe d'autres, plus ou moins spécifiques (voir Annexe 3).

Parmi tous ces modèles, La société Reuters Financial Software a choisi le modèle CMMI pour deux raisons :

• D’une part, le CMMI est le plus adapté à son type d’activité d’édition de logiciel : Le CMMI est un modèle d'évaluation du niveau de maturité d'une organisation concernant le développement de systèmes, de produit et/ou de logiciels. Il a pour objectif la maîtrise des processus d'ingénierie et par conséquent celle de la qualité des produits et des services issus de ces processus.
• D’autre part, le CMMI est adapté à son secteur d’activité en finance : La démarche de certification s'intensifie dans le domaine de l'informatique bancaire et plus particulièrement dans les marchés financiers (voir Annexe)

retour sommaire

Architecture du modèle CMMI:
Les bonnes pratiques préconisées par le modèle sont regroupées en 5 niveaux de maturité/capacité et sont rassemblées en 25 processus clés (Process Area), voir Figure 5.


                                 Figure 5 : Niveaux du modèle CMMI. [5]

Le modèle se présente sous forme d’une pyramide à  5 niveaux, chaque niveau est composé d’un ensemble de « Process areas ». Pour passer d’un niveau à un autre il suffit de maitriser les « process areas »  du niveau. Dans le tableau 2, nous présentons l’objectif de chaque niveau ainsi que ses « process  areas » correspondants (voir Annexe 4).

Contexte du stage par rapport à l’approche de préparation à la certification CMMI
Comme toute entreprise désirant évaluer sa maturité selon CMMI, RFS cherche à monter dans l’échelle des niveaux en validant les ‘’process areas ‘’ de chaque niveau.
Actuellement RFS est au début de la procédure d’applications du modèle CMMI. Or, selon CMMI, toute organisation a par défaut le niveau 1. Donc, le premier niveau à évaluer est dans son cas le niveau de maturité 2.
L’objectif du niveau 2 est de s’assurer que les pratiques basiques de gestion de projet sont toujours mises en œuvre (gestion des exigences, estimations de charge argumentées, suivi de projet, mesure d’indicateurs, contrôle qualité, …).
Comme pour le premier contexte, l’objectif CMMI « mesure d’indicateurs »  du niveau 2 fait partie de la mission de mon stage.

retour sommaire

1.2.3    Mission, Actions Mesurables
Mission:
Toute en suivant une démarche qualité selon le modèle CMMI, la mission de stage consiste en la création d’un portail intranet offrant aux chefs de projets et aux responsables de produit des tableaux de bord construits à base des (KPIs). Ces tableau de bord présenteront des métriques qualités sur :

• Exigences Clients ”Customer requirements
• Jalons et risques  ”Milestones and risks”
• Planning et temps alloués “Planning and spent time”
• Plan de test et  test des résultats  “Test plan and test results”
• Modification du code source "Source code modification"
• Défauts ”Defects”

Enjeux d’application une démarche CMMI pour la réalisation du tableau de bord

• Augmentation de la production et diminution des coûts
• Anticipation des risques

Actions :

• Appliquer une démarche qualité selon le référentiel CMMI pour la réalisation du projet.
• Identifier et formuler les indicateurs répondants aux objectifs
• Rechercher, interpréter, extraire et traiter les paramètres formulant les indicateurs.
• Concevoir les bases de stockage.
• Concevoir et implémenter le tableau de bord.

retour sommaire

Objectifs :
La figure 6 illustre ces actions en donnant les objectifs mesurables par rapport à chaque action.

             

2 Applications et résolution

2.1    APPLICATION DU MODELE CMMI AU PROJET

2.1.1    Le processus mesure et analyse  
Le processus « Mesure et Analyse » est un « process area » du niveau 2 du modèle CMMI. Ce processus propose l’implémentation des métriques qualités. Une métrique qualité est un indicateur de performance appliquée à la production logicielle. Nous avons bien remarqué que ce « process area » est le plus adapté à la mission de stage grâce a ses bonnes pratiques proposées pour la réalisation des tableaux de bord adaptés à l’activité d’édition des logiciels.
Le processus « Mesure et Analyse » se présente sous la forme de deux pratiques spécifiques : voir Figure 7.
SG1: Align measurement and analysis Activities : Définir les mesures et les activités d’analyses

SG2 : Provide measurement results : fournir les résultats

   Figure 7 : les pratiques spécifiques de processus « Mesure et Analyse » [3,6]

Le modèle CMMI indique sommairement les éléments essentiels pour l'activité de mesure et d’analyse. C’est à nous d’adapter ce modèle à nos besoins.
En outre, le CMMI propose des pratiques génériques (GG) applicables à tous les « process area » ayant pour objectif la gestion et le suivi du projet tels que : la gestion de la configuration, la planification du projet, l’étude des risques, le suivi, la répartition des taches etc

retour sommaire

2.1.2    Application du modèle au projet
A partir du descriptif du domaine de processus ‘ « Mesure et Analyse » et des pratiques génériques, nous avons réalisé un diagramme décrivant le déroulement du projet qui répond aux exigences CMMI et qui est bien adapté à la réalisation du projet : voir Figure 8.

                Figure 8 : Diagramme de réalisation du projet selon CMMI
La réalisation du diagramme précédent nous a aidé à comprendre les étapes de réalisation du projet. Ces étapes s’articulent autour de quatre phases :
La première phase est la phase de gestion de projet (gestion de configuration, planification, études des risques, fourniture des ressources ainsi que la formation du personnel et suivi du projet).
La deuxième phase est celle de la spécification fonctionnelle des métriques (spécification du besoin, proposition des métriques, formulations des métriques).
La troisième phase  concerne la spécification technique (la procédure de collecte et de stockage des données).
La quatrième phase est la phase d’implémentations technique (extraction et traitement des données par l ETL, réalisation du tableau de bord par Business Object).
Après chaque phase, une révision « Review » est effectuée pour vérifier les résultats et proposer des actions correctives. Dans ce qui suit, nous traiterons chaque phase en détails en indiquant à chaque fois les résultats trouvés.


2.2 REALISATION DU PROJET

2.2.1    Gestion de projet
Gestion de la configuration
Template pour  la spécification des indicateurs
Le Template de la spécification des métriques   est un document comportant les parties suivantes :
Une spécification fonctionnelle de la métrique : Cette spécification comporte :
-    La définition de l’objectif de la métrique
-    La formule pour le calcul de l’indicateur
-    Les résultats acceptables et les actions correctives.
Une spécification technique de la métrique : dans cette partie, nous spécifions :
-    l’implémentation de la métrique sur l’outil d’extraction des donnés (l’ETL)
-    La publication des données grâce à Business Object pour la construction du tableau de bord.
Fiche de notes pour la collecte des paramètres des métriques
Ce document servira pour la collecte des données. C’est une fiche de note regroupant la formule de la métrique, ses paramètres, le nom de la source de données ainsi que la table contenant chaque paramètre.
Le tableau 3 résume la collecte : soit la métrique  M= A/B

retour sommaire

                                        Tableau 1 : Fiche de collecte des paramètres


Planification du projet  
A ce niveau du projet, nous n'avons toujours pas la liste des métriques mais nous savons les étapes de leur réalisation. Donc, nous avons mis en place un planning selon un prototype de métrique (voir Figure 9).
 
                                      Figure 9 : Planning du prototype métrique

Ce planning montre le déroulement du diagramme (figure 9) en fonction du temps. En effet, pour traiter une métrique, il nous faut 12 jours en moyenne. Cette durée est variable et sera mise à jour en fonction de la complexité de la métrique.
Etude des risques projets
Maîtriser les risques est une préoccupation majeure dans la gestion du projet. Les risques sont définis comme la possibilité qu'un projet ne s'exécute pas conformément aux prévisions des dates, de coût ou d'expression des besoins. Ces dérives sont considérées comme difficilement acceptables, voire inacceptables.
Pour maîtriser les risques, plusieurs activités sont à mettre en œuvre et ce, de manière itérative pendant toute la durée du projet : l'analyse des risques du projet, la réduction des risques et leur suivi. Les résultats de ces activités doivent être capitalisés au sein de l'organisme afin de faire profiter les futurs projets de l'expérience acquise.
Il existe 5 temps forts pour l'analyse des risques : voir Figure 10.
- Etablir l'inventaire des risques
Type de risques potentiels: Financiers, organisationnels, techniques, humains.
Sources d'information: Consultation, archives, mémoires projets.
- Valoriser les risques
Gravité: Evaluer la criticité de chacun des risques en termes d'impact.
Probabilité: Evaluer la criticité de chacun des risques en termes de probabilité.
- Définir les parades
Eliminer le risque : Le coût est le paramètre de jugement.
Limiter les effets : La solution est souvent du côté de la gestion des ressources
Réviser le projet : Une précaution à prendre au cas par cas.
- Identifier les points critiques
Lieux et/ou moments ou la probabilité et/ou la gravité sont les plus importants.
- Réviser la table des risques
Suivre l'évolution en cours de projet de la criticité.

retour sommaire

        
 
                            Figure 10: Schéma de la maîtrise des risques

Le tableau 2 résume les risques qui peuvent influencer le déroulement du projet.


                                         
Tableau 2 : Risques projet

retour sommaire

Fournir les ressources et former les acteurs
Pour la réalisation du projet, certaines ressources ont étés mises a notre disposition, ces ressources sont des personnes, des locaux, des ouvrages, des guides et des outils techniques :
Personnes et locaux : nous formons une équipe de quatre personnes : Responsable de qualité, expert qualité, ingénieur technique, et moi-même. Nous avons planifié des réunions hebdomadaires pour faire le suivi du projet et proposer des améliorations continues des résultats.
La responsabilité de chaque personne n’est pas définie. Après chaque réunion, le chef de projet prépare un compte rendu dans lequel il assigne les responsabilités et les taches de chaque membre de l'équipe projet.
Guides et Ouvrages : nous avons utilisé le référentiel CMMI pour l'approche qualité, le guide des bonnes pratiques PSM (practical software and measurement) ainsi que l'ouvrage  « METRICS AND MODELS IN SOFTWARE QUALITY ENGINEERING » pour la définition et la formulation des métriques.

Outils techniques : deux outils sont nécessaires pour l implémentation technique des métriques
         - Un outil d’extraction et de stockage des données : pour extraire les données et les stocker, nous avons utilisé un outil de TIBCO qui est l'ETL Dataexchange  
         - Un outil pour l’implémentation du Dashboard et publication des métriques : nous avons mis à disposition Business Object.
Ainsi, pour bien mener ce projet et maîtriser ces outils, nous avons reçu une formation tant sur l'ETL que sur Business Object.


2.2.2    Spécification fonctionnelle des métriques  
 
                 Figure 11 : Etapes de la Spécification fonctionnelle des métriques

Comme le montre la figure 11, la phase de spécification des métriques est la phase la plus délicate du projet. Son but est de déterminer la mesure utile qui répond aux besoins, et de mettre une infrastructure de mesure. Dans un premier temps, nous déterminerons les besoins. Ensuite nous identifierons les métriques. Finalement nous les formulerons.
Collecte des besoins
Les besoins sont collectés à partir de l’expérience du chef du projet ainsi que celle de l’expert qualité. Le résultat de la collecte des besoins est présenté par le tableau suivant : voir Tableau 3. (voir Annexe5 pour plus d’informations concernant les objectif).

retour sommaire

 Tableau 3: Tableau de collecte des besoins

Proposition des métriques qualités
Utilisation du PSM , Réunions, Expériences
Nous avons réussi à identifier les indicateurs répondants aux différents besoins à partir de :
- PSM (Practical Software Measurement) qui est guide des bonnes pratiques, présentant des méthodes intéressantes pour l'activité de mesure et d'analyse dans le domaine d’édition de logiciel  (Annexe 3).
-  L’expérience du responsable qualité, de chef de l équipe et de l'expert qualité.
- Des réunions avec les responsables projets  permettant de mieux comprendre leurs besoins.

Etablir les objectifs de mesures
Nous avons réussi à trouver les mesures répondant aux besoins exprimés ainsi que les indicateurs adéquats : voir Tableau 4 (voir annexe 4 pour plus de détails).


                                                Tableau 4: Les 42 métriques  proposées

retour sommaire

Après avoir défini les métriques répondant aux besoins exprimés dans la partie précédente, l’étape suivante est de mettre à jour le planning selon les priorités des besoins.
Mis a jour du planning selon les priorités
Après avoir définir les métriques, nous nous sommes informés auprès des chefs de projets pour les classer selon leur priorité respective. Ainsi, nous avons mis à jour le planning de départ avec les métriques ordonnées qui sont à notre possession (voir Figure 12).
 
                                   Figure 12 : Planning mis a jour selon les priorités  


Formulation des métriques
Dans cette partie, nous cherchons à formuler les métriques. Donc, pour chaque métrique et selon la description donnée par le PSM, nous identifions les paramètres et nous donnons une équation mathématique adéquate.
Exemple 1 : Métrique  Customer satisfaction survey
- Paramètres:
Question identification (Question_ID)
Number of Very Satisfied (N_Very_Satisfied)
Number of Satisfied (N_Satisfied)
Number of Neutral (N_Neutral)
Number of Dissatisfied ( N_ Dissatisfied)
Number of Very Dissatisfied ( N_ Very_Dissatisfied)
Count of Response ( C_Response)  
Total Number of returned answers ( N_total_answer)
- Formule
Customer satisfaction = ((N_Very_Satisfied + N_Satisfied) / (C_Response)) * 100
- Résultats acceptables
Target 80% Satisfied and / or Very Satisfied
M.A.L 50% Satisfied and / or Very Satisfied

Exemple 2: Métrique QA sing-Off milestone schedule
-Paramètres
Initial Forecast Date (Initial_Forecast_Date)
Real Archieved Date (Real_Archieved_Date)
Duration of each QA-Sign-Off ( plan_Duration)
-Formule
Count of Business days after Ex-Dev
-Résultats acceptables
Target QA Sign-Off Achieved < 10 Business Days
M.A.L QA Sign-Off Achieved = 10 Business Days

Exemple 3 : Métrique Action item Status
-Paramètres
action items opened (action_item_opnedd)
action items closed (action_items_closed)
action items unresolved (action_items_unresolved)
load (load)
-Formule
NumberOf ( action_items_opened) this period
NumberOf (action_items_closed) this period
NumberOf (action_items_unresolved) this period
Period Each Load
 -Résultats acceptables
Target No Action Items Opened Status at the end of development phase (Measure for each load)
M.A.L 10% of Action Items Opened Status at the end of the development phase

2.2.3    Spécification technique des métriques


 
                            Figure 13 : procédure d’automatisation des métriques

retour sommaire

La figure 13 illustre les trois étapes de la procédure d’automatisation des métriques :
- La première étape est l’extraction et le traitement  des données des différentes sources (ETL TIBCO).
- La deuxième étape est celle du stockage dans le DATAMART.
- La troisième étape est la création des rapports et la publication des résultats (Business Object).
Après la spécification fonctionnelle et avant de se lancer dans la phase d’automatisation, le processus « mesure et analyse » propose de faire une spécification technique : spécification de la procédure de collecte et de stockage des paramètres formulant les métriques (voir Figure 14).
 


Figure 14 : les étapes de la spécification techniques des métriques

Spécification de la procédure de collecte des données
À partir des paramètres formulant la métrique, c’est à nous de chercher leurs emplacements dans les différentes sources de données. La complexité augmente lorsque le paramètre se trouve sous forme composée. (Voir tableau 3). Pour bien mener cette tache, nous avons procédé à une analyse des sources de données pour comprendre la structure ainsi que les types de données stockées.
Les sources  de données sont :
- Des bases de données : base ( QC) Quality Center, Lotus notes.
- Des fichiers XML, fichiers à plat.
- Réseaux Intranet de Reuters : reuters Devnet
Nous travaillons particulièrement avec les bases de données et les fichiers XML.
Exemple 1 : structure de la source de données Mercury Quality Center
La source Mercury quality center est composée d’un ensemble de bases de données. Chaque base de données concerne un produit (voir figure 14). C’est la source la plus utilisée vu sa richesse en informations.

            
    Figure 14 : Structure de la base Mercury Quality Center
Exemple : La figure montre que nous avons une base pour le produit KondorPlus. La base Kondor comporte plusieurs tableaux dont le nom indique le type d'informations  stockées : Le tableau BUG comporte les résultats des tests après détection de BUG et le tableau REQ comporte les req des clients etc..

retour sommaire 

Exemple 2 : structure des fichiers XML
Un fichier XML (Extensible Markup Language) est un fichier contenant des informations sous forme de balises structurées en arbre (voir Figure 15).
 
                                     Figure 15 : Structure d un fichier XML
Pour comprendre les informations d'un fichier XML, nous avons déterminé pour chaque fichier son schéma explicatif qui nous permet d’extraire et d’interpréter les données (voir Figure 16).


 
                                Figure 16 : Image d’un schéma XML sur l'ETL

retour sommaire

La figure montre une structure en arbre ou la racine est « Cruisecontrol » , jusqu’à l’arrivée au bout de l'arbre qui présente les champs « error »  et « time » etc..Ces derniers correspondent bien à certains paramètres formulant certaines métriques.
Une fois que nous nous sommes familiariser avec les sources de données, il est plus facile de trouver le paramètres de chaque métrique et de remplir la fiche de note de collecte des paramètres du tableau 1.

Spécification de la procédure de stockage des données
Le Datamart :
Un datamart est une base de données structurée et formatée en fonction d'un métier précis ou d'un usage particulier (datamart commercial, datamart financier, ...). Dans notre cas, nous avons conçu un datamart qualité.
Pour chaque métrique nous avons conçue une base de données spécifique.
Exemple : la base 'KPI_MilestoneDate'  est la base de stockages comportant les résultats de la métrique QA Sign off milestone schedule.(voir Figure 17).
 


 Figure 17 : Spécification de la table Milestone dans le datamart


3 Résultats obtenus

3.1    IMPLEMENTATION DES INDICATEURS
 
          Figure 18 : Etapes de la procédure d implémentation des métriques.

retour sommaire

Après avoir choisi la métrique à implémenter, la procédure "fourniture des résultats" consiste en deux étapes : extraction et stockage des données via l’ ETL. Ensuite vient la fourniture des rapports construisant le tableau de bord.

3.1.1    Extraction et stockage des données
L’extraction se fait à l’aide du logiciel ETL TIBCO DataExchange :ETL « Extract-Transform-Load » est une technologie informatique permettant d'effectuer des synchronisations massives d'information d'une base de données vers une autre. Selon le contexte, on traduira par « alimentation », « extraction », « transformation », « constitution » ou « conversion », souvent combinés.
A l'origine, les solutions d'ETL sont apparues pour le chargement régulier de données agrégées dans les entrepôts de données (ou datawarehouse), avant de se diversifier vers les autres domaines logiciels. Ces solutions sont largement utilisées dans le monde bancaire et financier, ainsi que dans l'industrie, vu la multiplication des nombreuses interfaces. [9]
Exemple : Traitement ETL de la métrique QA Sign off milestone schedule (Figure 19).

Figure 19: Tache d’extraction  et de stockage des données pour la métrique QA Sign off milestone schedule


Pour traiter la métrique QA Sign off milestone schedule, l'ETL se connecte  à la base de données source, extracte le tableau Milestone (2) et le traite pour avoir en sortie un tableau Milestone (12) qui sera stocké dans le Datamart .

3.1.2    Fournir les résultats en utilisant Business Object

BusinessObjects Enterprise est une solution fiable, flexible et évolutive permettant de fournir des rapports interactifs puissants aux utilisateurs finaux via n'importe quelle application Web, qu'il s'agisse d'un intranet, extranet, portail d'entreprise ou d'Internet. Qu'il soit utilisé pour diffuser des rapports de ventes hebdomadaires, fournir aux clients des services personnalisés ou intégrer des informations importantes dans des portails d'entreprise, BusinessObjects Enterprise offre des avantages concrets qui dépassent le simple cadre de l'entreprise. Suite intégrée spécialisée dans le reporting, l'analyse et la diffusion d'informations, BusinessObjects Enterprise permet aux utilisateurs finaux d'augmenter leur productivité tout en réduisant les taches administratives. [10]
Pour la réalisation d’un rapport, le BO permet, au départ, de créer un univers comportant des tableaux traitant une certaine métrique, ensuite, de les traiter afin de fournir un rapport personnalisé.
Exemple1 : voir Figure 20.
Exemple 2 : voir Figure 21

retour sommaire

 

           Figure 20 : Graphe relative au rapport sur les « Cost and Activity »
 
                                Figure 21 : Graphe relative au rapport sur les « Charts for QA Sing-OFF)

retour sommaire

4 Améliorations proposées

Jusqu'à fin Avril, mon stage se déroulait très bien et j'étais bien encadrée par mon responsable. Durant cette période, j'ai appris beaucoup de choses et j'ai réussi à faire toutes les parties du stage sans aucune déviation. J'ai travaillé sur la CMMI, la collecte des données, la gestion de projet, les réunions, l'ETL ainsi que la rédaction des rapports sur infoview. L'équipe, formée de l’expert qualité, de l’ingénieur technique et de moi-même, était très motivée par le sujet.
À partir du 15 mai, nous avons commencé à avoir des retards sur la livraison des indicateurs. Ces retards sont dus aux problèmes d’extraction des paramètres des sources de données (étape 3 figure 6) pour deux raisons :
-    Soit les paramètres n’existent pas dans les sources de données.
-    Soit les paramètres existent mais nous n’y avons pas accès.
Ce point est à améliorer dans les prochains projets par le calcul d’incertitude de la réalisation des métriques. C'est-à-dire, lors de la formulation des métriques, il est intéressant de savoir l’incertitude qu’on peut affecter à chaque paramètre de la formule.
Cela nous permet d’anticiper les risques de retard, de résoudre les problèmes avant qu’ils arrivent, et de mieux respecter les délais et les engagements.

retour sommaire

Conclusion

Le stage s’est déroulé au sein du département Assurance qualité. Le département joue un rôle important dans Reuters Financial Software pour s’assurer que la société développe bien le bon produit selon la bonne méthode.
Intégrée dans une équipe de quatre personnes (responsable qualité, expert qualité, ingénieur technique et moi) et dans un contexte d’assistance des phases « Definition », « Delivery »  et  « Deployment » du processus « Reuters Proposition Delivery (RPD) » dans la réalisation des indicateurs (KPI), ma mission de stage était de suivre une démarche CMMI permettant de créer un portail intranet, offrant aux chefs de projets et aux responsables des tableaux de bord construits à base des métriques qualités (KPIs).
La réalisation de la mission de stage s’est déroulée en de 4 phases :
Dans la première phase, nous avons adopté le processus « Mesure et Analyse »  du niveau 2 du référentiel CMMI (Capability Maturity Model Integration). Ce processus est pertinent pour la réalisation du projet puisqu’il propose des bonnes pratiques de conception des tableaux de bord adaptées à l’activité d’édition des logiciels. Pour nous aider à déterminer les étapes du projet, nous avons conçu un diagramme décrivant ces étapes tout en respectant les exigences CMMI.
La deuxième phase concerne la  gestion du projet. Nous avons commencé par la gestion de la configuration (rédaction des documents de spécification et de collecte des données relatives aux métriques). Ensuite, nous avons planifié le projet et étudié les risques (perte des données, absence des données, difficulté d’interprétation, etc..).
Durant la troisième phase, nous avons procédé à une spécification fonctionnelle des métriques. Ainsi, nous avons collecté les besoins à partir des réunions d’informations et de retour d’expérience des chefs des projets. Ensuite, nous avons formulé 42 métriques en utilisant le PSM (Practical Software Measurement).

La quatrième phase concerne la spécification technique. C’est une phase préparatoire avant l’implémentation. D'abord, nous avons spécifié la procédure de collecte des donnés en déterminant l’emplacement de chaque paramètre formulant la métrique dans la source de donnés correspondante. Ensuite, nous avons conçu les bases de stockage dans le datamart.
Finalement, nous avons implémenté les solutions en utilisant l’ETL pour l'extraction et le traitement des formules et le Business Object pour la rédaction et la capitalisation des rapports dans le tableau de bord.

retour sommaire

Bibliographie

[2] Site de Reuters financial Software :
URL : http://www.ime.reuters.com/dailybriefing/
[2] : Site le Monde.fr  
Article : Reuters accepte son rachat par Thomson pour 12,8 milliards d'euros
Référence : LEMONDE.FR avec AP, AFP et Reuters | 15.05.07 | 09h37  •  Mis à jour le 15.05.07 | 09h48
Lien direct : http://www.lemonde.fr/web/sequence/0,2-3234,1-0,0.html?NAV1=ACC&NAV2=NONE
URL : http://www.lemonde.fr/web/article/0,1-0@2-3234,36-910080@51-628863,0.html
[3] : Intranet Reuters
URL :http://sharepoint.emea.ime.reuters.com/sites/TradeAndRiskManagement/Teams/QA/Web%20Pages/StandardsAndMeasures.aspx
[4] : Site des référentiels CMMI, COBI, ITIL : comparaison entre les différents référentiels  
URL : http://www.bonneaud.net
[5] : image du modèle CMMI.
URL : http://www.geocities.com/jgabdian_2004/CMMI_Representations_2.jpg
[6] : Rapport Imen Abbes. Reuters Financial software 2007
[7] : CMMI, Un itinéraire fléché vers la Capability Maturity Model Integration, Richard Basque, Dunod 11/ 2006
[8] : PSM,Practical software measurment, Objective Information for decision mekers, John McGanny, David card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Deam, Fied Hall
Edition 0201715163 , Wesley Professional  2001
[9] : Site de TIBCO ,ETL
URL :  http://www.tibco.com
[10] : Business Object
URL : http://www.businessobjects.com/thirdparty

retour sommaire

Annexes                                                     
                                                         
 Annexe 1
Chiffre d affaire
Reuters Financial Software a connu 18 ans de croissance continue et maîtrisée, comme en témoigne l’évolution du chiffre d’affaires et du personnel (voir figure ). Cette évolution est due à l’élargissement du panel de produits et de services proposés.
L’entreprise réalise 96% de son chiffre d’affaires à l’étranger, équipant plus de 9000 salles de marchés dans 71 pays (200 000 utilisateurs). Figure1




Figure1 : chiffre d’affaire et profit net de Reuters Financial Software

Rôle du personnelles
Le succès de Reuters Financial Software ne fait pas oublier que les hommes et les femmes sont la source essentielle de la richesse que Reuters crée pour ses clients.
La croissance exceptionnelle de Reuters Financial Software présente un défi majeur à relever en termes d'organisation et de politique Ressources Humaines.
Un effectif de plus de 450 personnes, doublé sur ces dernières années avec une croissance externe réussie, une moyenne d'âge de 32 ans, 26 nationalités représentées, des lignes hiérarchiques souples et une culture de l'autonomie et de la convivialité : c'est dans ce contexte dynamique que 20 ans de croissance et de succès ont forgé l'esprit unique de Reuters Financial Software.  Figure 2
      
                          
   Figure2 : Evolution du personnel 1988-2006

Reuters est un employeur équitable. Toutes les candidatures seront étudiées sans aucune discrimination  fondée sur la race, la couleur de la peau, la religion, l’origine nationale, le handicap, le sexe, l’âge, l’état matrimonial ou parental  ainsi que sur l’orientation, l’expression ou l’identité sexuelle.
Les métiers de Reuters Financial Software
Product Management, Conception/Développement, Ingénierie Financière, Qualité, Rédaction Technique, Support, Consulting,  les différents métiers de Reuters Financial Software se fédèrent autour de valeurs partagées : innovation, expertise, rigueur, mais également convivialité.

• L'équipe Product Management Assure la définition et l’implémentation de la stratégie des produits développés par Reuters Financial Software depuis la définition d'une version jusqu'au suivi des sites clients. En intégrant les demandes de ces derniers, elle contribue également au contenu des nouvelles versions de nos produits. Nos ingénieurs financiers ont pour mission d'appréhender les nombreuses fonctionnalités requises pour la diversité des différentes places financières et de concevoir les modèles mathématiques qui les caractérisent. Ils assurent également le suivi, la validation et l'intégration de ces modèles dans nos logiciels.
• L'équipe Ingénierie Financière les ingénieurs financiers ont pour mission d'appréhender les nombreuses fonctionnalités requises pour la diversité des différentes places financières et de concevoir les modèles mathématiques qui les caractérisent. Ils assurent également la rédaction de spécifications fonctionnelles, le suivi, la validation et l'intégration des modèles développés dans nos logicie
• L'équipe de Développement assure la conception, le développement et la validation des produits. Elle est également responsable des spécifications techniques détaillées. Certains ingénieurs de développement disposent d'une double compétence informatique/finance. 
• Les équipes Qualité et Rédaction Technique sont en charge de l’exécution des campagnes de tests autour de nos produits. Elles identifient les bugs et les corrigent afin d’assurer la livraison des versions aux clients.Les rédacteurs techniques, de langue maternelle anglaise, sont responsables quant à eux de la documentation technique et fonctionnelle qui accompagne les produits implémentés chez nos clients.
• L'équipe Project Management assure le suivi et la livraison de nos logiciels en respectant les contraintes de temps et de budget. Elle est chargée d’impliquer tous les acteurs (développement, QA, ingénieurs financiers) afin d’atteindre les objectifs de livraiso
• Les ingénieurs des équipes Support et Consulting analysent et résolvent les problèmes clients. Ils mènent des activités de tests, de validations ou d'études techniques. En contact direct avec les utilisateurs du monde entier, les consultants analysent leurs besoins, puis proposent et développent des solutions spécifiques autour de l'offre de produits existants. Ils mettent également leur expertise fonctionnelle ou technique au service des filiales du Groupe Reuters
• Différentes autres fonctions (dites transversales) contribuent au succès de notre entreprise. Ainsi nous recrutons régulièrement des Ingénieurs Systèmes et Réseaux, des Rédacteurs Techniques etc…
  

retour sommaire

Annexe 2

Cycle de vie d’Un projet d Edition de logiciel (RPD)
Le cycle de vie de réalisation de tout progiciel  suit un processus défini au sein de Reuters Financial Software appelant : le Reuters Proposition Delivery (RPD)
Le RPD est une structure permettant la gestion de propositions sur leur cycle de vie complet – de l’idée naissante à la phase d’obsolescence. Voici en ci-dessous  (figure) une illustration de ce cycle.

 
                            Figure 3: Cycle de vie de tout projet chez reute

Génération d’idée – Idea Generation
-    Recensement des idées de la division Business
-    « Business plan » sont acceptés ou refusés selon la pertinence de leur « Business Case » par la Division.

A la fin de chaque phase, a été mis en place un point de contrôle marquant le passage d’une phase à l’autre.
Checking – Incpetion
-    CePl point de control a été mis en place pour filtrer les idées selon des caractères bien précis:

• son axe stratégique
• sa valeur business
• les risques liés à sa réalisation
  

Plan Business – Business Planning
-    Présentation du business plan : La présentation  donne des détails sur la partie business, des objectifs à atteindre, des coûts financiers du projet, des ressources nécessaires, enfin elle définit les responsabilités du projet (la PLT – Proposition Leadership Team-)
-    La proposition est étudiée pendant cette phase, une décision « go/no-go » est à prendre.


Checkpoint – Initiation  
-    Ce point de contrôle a pour but de confirmer plusieurs points essentiels :

• La proposition business est bien viable.
• L’appui de la division stratégique
• D’assurer la disponibilité des ressources pendant la phase de définition

Definition phase
-    L’architecture du projet est produite, elle doit être ratifiée par la Technical Governance (comité en charge de cette validation)
-    Une décomposition fonctionnelle du produit est fournie durant cette phase. La notion de « Requirement » est ainsi introduite. Le produit est donc décomposé en plusieurs « Requirements ».
-    L’effort (en jour/homme) doit être estimé pour chaque « Requirements ».
-    Un planning détaillé pour la livraison du projet est aussi défini dans cette phase.
-    Le project management a ici la charge de fournir le planning des livrables, le détail des itérations qui sont prévus pour toute la durée de la proposition

Checkpoint Commitment Review
-    Ce point de contrôle a pour but :

• De confirmer la viabilité de la proposition business et celle du soutien de la division stratégique.
• S’assurer que le projet est défini et coté pour livrer le projet.
• S’engager sur le contenu de livrables et sur les dates de livraisons de ceux-ci.

Delevry phase
-    Les livrables du projet sont produit et la qualité du produit est assuré en préparation à la livraison du projet au service des ventes dans les régions (Global Sales and Service Operations)
-    Ces livrables incluent : le produit, l’infrastructure, les systèmes d’administration et processus associés.
-    Pendant cette phase le project management s’assure du respect des délais des livrables, il est aussi garant de la qualité de la proposition livrée.

Checkpoint – Fitness For Launch
-    Ce point de contrôle a pour but de :

• Confirmer que la proposition correspond aux attentes sur le point fonctionnel, performance, stabilité et évolutivité
• Si la proposition est prête pour passer en phase béta

Deployment phase
-    La phase de déploiement est caractérisée par un transfert de connaissances des développeurs et testeurs de la proposition vers les groupes ayant la tache de supporter, administrer et vendre la proposition.
Checkpoint – Ready for Revenue Generation
-    Ce point de contrôle est marqué par la confirmation que la proposition peut être vendue, administrée, supportée efficacement dans les différentes régions.
Support and Measure phase
-    Evaluation de la réalisation des objectifs clients en se basant sur le support et les autres retours clients.
Checkpoint – Ready for Rationalisation
-    Les objectifs fixés sont atteints.
Obsolescence phase
-    Le produit est en fin de vie, les équipes de support sont progressivement désengagées et les infrastructures retirées.

retour sommaire

Annexe 3
Outre les trois référentiels (COBIT, ITIL, CMMI), il en existe d'autres, plus ou moins spécifiques ou plus moins à la mode  
PMI (Project Management Institute), Prince2 (PRojects INControlled Environments), Spice (ISO 15504), ISO 17799, ISO 9000, CEI/ISO 20000
Même si chaque système a plus ou moins été étendu aux différentes facettes de l'activité informatique, chaque référentiel trouve son efficacité dans un domaine particulier. Il n'est pas donc pas trop difficile de se tourner vers celui qui sera pertinent dans le cadre spécifique qui préoccupe l'entrepris
ePMI
Le PMI propose une certification en management de projet correspondante, le PMP (Project Management Professionals).
Prince, Prince2
Prince (PRojects INControlled Environments) est un guide des meilleures pratiques en direction de projet, utilisé par l'administration britannique.
Chaque processus est défini avec ses entrées et sorties caractéristiques ainsi qu'avec les objectifs spécifiques à remplir et les tâches à accomplir.
La méthode Prince est dans le domaine public
Spice, ISO 15504
Spice est une norme créée par l’ISO (International Organization for Standardization) pour standardiser l'évaluation des processus logiciels (Norme ISO/CEI 15504).
Spice est moins une méthodologie de travail qu’un outil d'évaluation du niveau de maîtrise du processus de conduite du projet

ISO 9000
Les certifications de la famille ISO 9000 constituent désormais un ensemble de références de qualité, incontestées sur le plan mondial.
Très généralistes, ces spécifications ne sont pas forcément les plus productives pour l'informatique
ISO 17799
Catalogue de bonnes pratiques assurant un client que ses informations sont gérées de manière sécurisée par son fournisseur.
Elle est présentée dans cette liste comme complément de réponse aux obligations de sécurité des systèmes d'informationI
SO 20000
Conçue dès le début comme un complément d'ITIL, le norme CEI/ISO 20000 a été élaborée par British Standards Institute. C'est la première norme de gestion des services informatiques

retour sommaire

Annexe4

      
DAR - Decision Analysis and Resolution
IPM - Integrated Project Management
OPD - Organizational Process Definition
OPF - Organizational Process Focus
OT - Organizational Training
PI - Product Integration
RD - Requirements Development
RSKM - Risk Management
TS - Technical Solution
VAL - Validation
VER - Verification
IT - Integrated Teaming
ISM - Integrated Supplier Management
OEI - Organization Environment for Integration

              Tableau : Objectifs et « Process areas »  des niveaux CMMI

retour sommaire

Le modèle se présente sous forme d une pyramide 5 niveaux, chaque niveau est composé d un ensemble de « Process areas », pour passer d’un niveau a un autres il suffit de maitriser les « process areas »  du niveau, dans le tableau xx nous présentons l’objectif de chaque niveau ainsi que ses « process  areas »

Annexe 5



                           


     
 TAbleau 2: collecte des données

retour sommaire