Memoire création d'un simulateur de charge

Résumé :
Création d’un
simulateur de
charge pour le
logiciel IPTAX
Sujet : Amélioration et
développement des outils de test
d’Evistel
Gilles Lefebvre
EI.CESI
Promotion FIFC 10-12
Evistel
7, rue de Sainte Hélène
75 013 Paris
France
www.evistel.com
Tél : +33 (0)1 53 62 95 51
Fax : +33 (0)1 53 62 95 53
Tuteur : Omar Ait-amrane
Ei.cesi
93, boulevard de la Seine
BP 602
92 006 Nanterre Cedex
France
www.cesi.fr
Tél : +33 (0)1 55 17 80 00
Fax : +33 (0)1 55 17 80 01
Tuteur : Tahsin Evirgen
Résumé :
Ce document est un mémoire de stage de fin
d’étude effectué dans le cadre d’une formation
d’ingénieur généraliste de l’ei.CESI. Il décrit la
réalisation d’un simulateur de charge
développé dans le cadre du projet
d’amélioration des outils de tests de
l’entreprise Evistel.

Création d’un simulateur de charge pour le logiciel IPTAX
Sujet : Amélioration et développement des outils de test d’Evistel
Page 1
Table des matières
Remerciements..................................................................................................................................................4
Avant - propos....................................................................................................................................................5
Introduction .......................................................................................................................................................6
Glossaire & Acronymes......................................................................................................................................7
1. Evistel, une PME atypique..........................................................................................................................8
1.1 Historique de la société.......................................................................................................................8
1.2 L’organisation de l’entreprise .............................................................................................................8
1.3 Un positionnement marketing différent.............................................................................................9
1.3.1 Les produits................................................................................................................................10
1.3.2 Les clients...................................................................................................................................12
1.4 Les valeurs de l’entreprise ................................................................................................................12
1.5 La qualité, le parent pauvre? ............................................................................................................13
2. Améliorer la qualité des produits.............................................................................................................14
2.1 Le contexte........................................................................................................................................14
2.1.1 Le produit IPTAX........................................................................................................................14
2.1.2 Les clients...................................................................................................................................15
2.1.3 Le service Intégration & support ...............................................................................................15
2.2 La problématique ..............................................................................................................................15
2.3 Le projet : Création d’un simulateur de charge pour le produit IPTAX ............................................16
2.3.1 Les objectifs ...............................................................................................................................16
2.3.2 Les enjeux...................................................................................................................................16
2.3.3 Les contraintes...........................................................................................................................17
2.3.4 Les difficultés pressenties..........................................................................................................17
2.3.5 Les livrables................................................................................................................................17
2.3.6 Les limites du projet...................................................................................................................18
3. L’organisation du projet ...........................................................................................................................19
3.1 La méthodologie utilisée...................................................................................................................19
3.2 La préparation du projet ...................................................................................................................20
3.2.1 Les phases du projet ..................................................................................................................20
3.2.2 Le WBS .......................................................................................................................................22
3.3 Le macro planning.............................................................................................................................25
3.4 L’analyse des risques initiaux............................................................................................................26
3.5 Les indicateurs de suivi .....................................................................................................................27
3.6 Le système d’information .................................................................................................................29
3.6.1 Le référentiel documentaire du projet......................................................................................29
3.6.2 La gestion de configuration pour le simulateur de charge........................................................30
3.6.3 La communication sur le projet.................................................................................................30
3.7 Les moyens........................................................................................................................................31
3.8 Les intervenants................................................................................................................................32

Page 2
3.9 Le budget prévisionnel......................................................................................................................32
4. Le déroulement du projet : de la théorie à la pratique............................................................................34
4.1 Une activité transversale : le management du projet ......................................................................34
4.1.1 Rédiger la note de clarification, le plan de management et créer le planning initial ...............35
4.1.2 Piloter le projet ..........................................................................................................................35
4.1.3 Gérer les réunions et rédiger les comptes rendus afférents.....................................................35
4.2 L’étude préalable ..............................................................................................................................36
4.2.1 Familiarisation avec l’environnement .......................................................................................36
4.2.2 Formation à l’environnement technique...................................................................................37
4.2.3 État des lieux..............................................................................................................................37
4.2.4 Définition du cahier des charges ...............................................................................................39
4.2.5 Prototypage et maquettage.......................................................................................................40
4.2.6 Validation de la phase................................................................................................................46
4.3 La phase de conception.....................................................................................................................47
4.3.1 Définition de l’architecture du simulateur ................................................................................47
4.3.2 Rédaction du plan de tests du simulateur.................................................................................50
4.3.3 Rédaction des spécifications fonctionnelles détaillées .............................................................50
4.3.4 Validation de la phase................................................................................................................53
4.4 La réalisation du simulateur..............................................................................................................54
4.4.1 Développement .........................................................................................................................54
4.4.2 Passage des tests .......................................................................................................................54
4.4.3 Réalisation de la documentation...............................................................................................54
4.4.4 Recette.......................................................................................................................................55
4.5 La mise en œuvre..............................................................................................................................56
4.5.1 Déploiement ..............................................................................................................................56
4.5.2 Formation des ingénieurs à l’outil .............................................................................................56
4.5.3 Le bilan provisoire du projet......................................................................................................56
4.6 Exploitation et Maintenance.............................................................................................................58
4.6.1 Exploitation, Assistance et Maintenance corrective et évolutive .............................................58
4.6.2 Participation aux campagnes de tests .......................................................................................58
5. Conclusion ................................................................................................................................................60
6. Annexes ....................................................................................................................................................61
6.1 Références.........................................................................................................................................61
6.2 Planning détaillé................................................................................................................................62
6.3 Fiches de lot de travaux ....................................................................................................................63
6.4 Les solutions Open sources étudiées................................................................................................67
6.4.1 Les solutions logicielles..............................................................................................................67
6.5 Les solutions matérielles...................................................................................................................70
6.6 Un exemple de fiche de tests............................................................................................................71
6.7 Modèle de fichier de synthèse d’une campagne de test..................................................................73

Page 3
Liste des tableaux
Tableau 1 : Liste des documents du projet......................................................................................................18
Tableau 2 : Matrice des risques projet ............................................................................................................26
Tableau 3 : Types de documents générés par le projet et sigles associés ......................................................29
Tableau 4 : Liste des acteurs du projet............................................................................................................32
Tableau 5 : Matrice des responsabilités (RACI) ...............................................................................................32
Tableau 6 : Le coût du projet LOADTT .............................................................................................................57
Liste des figures
Figure 1 : Organigramme de la société..............................................................................................................9
Figure 2 : Architecture de réseau GSM-GPRS..................................................................................................10
Figure 3 : Références des clients d’Evistel à travers le monde........................................................................12
Figure 4 : Position du logiciel IPTAX dans un réseau de télécommunication..................................................14
Figure 5 : Structure de découpage de projet...................................................................................................23
Figure 6 : Structure de découpage de projet (suite).......................................................................................24
Figure 7 : Le macro planning des taches du projet..........................................................................................25
Figure 8 : Format des Indicateurs d'avancement des tâches et livrables........................................................27
Figure 9 : Instantané du tableau de bord projet le 01/06/12..........................................................................28
Figure 10 : Architecture de l’outil de test fonctionnel initial...........................................................................38
Figure 11 : Bête à corne du simulateur de charge...........................................................................................39
Figure 12 : Diagramme pieuvre du simulateur................................................................................................40
Figure 13 : Analyse multicritères des outils de charge....................................................................................41
Figure 14 : architecture matérielle de la plate-forme de tests de charge.......................................................42
Figure 15 : architecture fonctionnelle du simulateur......................................................................................49
Figure 16 : Modélisation de la plate-forme de tests .......................................................................................51
Figure 17 : Un test de charge modélisé ...........................................................................................................52
Figure 18 : Objets génériques de l’application ................................................................................................52
Figure 19 : Diagramme d’état du programme.................................................................................................53
Figure 20 : Le simulateur LoadTT en action.....................................................................................................55
Figure 21 : LOADTT la configuration minimale requise pour effectuer les tests de charge............................57

Page 4
Remerciements
Je tiens tout d’abord à remercier la société Evistel pour m’avoir accueilli au sein de ses locaux. Je tiens à
remercier plus particulièrement mon tuteur de stage Omar Ait-amrane pour m’avoir accueilli dans son
équipe et Thierry Lafue pour m’avoir proposé ce stage dans son service. Enfin je souhaite remercier toutes
les personnes qui m’ont apporté leur aide et leurs conseils durant cette période, et tout particulièrement
mes collègues :
Pablo Garcia pour son aide lors du passage des tests;
Benoît Crapart pour son esprit zen qui m’a permis de garder mon calme dans les moments difficiles;
Philippe Verdier pour sa disponibilité.
Je remercie aussi mon ingénieur formateur, Monsieur Tashin Evirgen, pour ses conseils avisés et son
soutien moral.
Enfin, je remercie l’état français pour avoir financé ma formation par l’intermédiaire du FONGECIF Île-
de-France, effort financier important que je n’aurais pu assumer seul.

Page 5
Avant - propos
A l’ei-CESI, le Projet de Formation en Entreprise (PFE) a pour but de confronter les élèves en fin de
cycle de formation au métier de l’ingénieur. Pour démontrer leur capacité à tenir un poste d’ingénieur, ils
doivent trouver un stage permettant de :
 S'entraîner à leur future fonction en se confrontant aux difficultés rencontrées dans leur milieu
professionnel,
 Prouver leur capacité à exercer une fonction d'ingénieur en entreprise,
 Mettre en pratique les connaissances, les conseils et outils méthodologiques reçus pendant la
formation,
 Enfin, permettre leur réflexion et compléter leur information sur la fonction envisagée dans le cadre
de leur projet professionnel.
La durée du Projet de Formation en Entreprise de 5 mois et demi, du 16/01/2012 au 29/06/2012,
permet de se confronter à de multiples situations professionnelles. Les choix du secteur et du sujet sont
quant à eux, libres.
Pour ma part, j’ai choisi de rester dans le secteur Hi-Tech (Informatique & Télécom) où j’ai réalisé toute
ma carrière et de compléter mon expérience en intégrant une petite structure spécialisée dans l’édition de
logiciel, afin de découvrir un univers différent de celui des sociétés de service en ingénierie informatique.
Ce projet s’inscrit dans le cadre de mon projet professionnel individuel. Celui-ci se déroule en 3 phases :
 Phase une, le court terme : faire reconnaître mon expérience d’ingénieur intégration
 Phase deux, à moyen terme : prendre la responsabilité d’une équipe de test
 Phase trois, le long terme : intégrer une société de conseil comme expert des tests logiciel
J’ai donc choisi de réaliser mon stage au sein de la société Evistel qui m’a proposé un projet consacré à
l’amélioration de leurs outils de tests. Ce projet a pour but de réaliser un simulateur de tests de charge
destiné à valider les performances du logiciel IPTAX, un logiciel de taxation des communications vers les
réseaux IP développé par l’entreprise. Ce projet me permettra d’étudier les solutions existantes du marché
en matière de tests de charge, plus particulièrement de connaître leurs tarifs, et de mettre en œuvre un
projet informatique intégralement du début à la fin, validant ainsi mes compétences en gestion de projet.

Page 6
Introduction
La société Evistel est une PME éditrice de logiciel de télécommunication ayant pour particularité
d’avoir des clients à travers le monde entier : Afrique, Amérique du sud, Asie et Europe. Elle développe
notamment une solution de taxation des services de communications sur réseau GSM, le logiciel IPTAX,
qu’elle a vendu à la filiale chilienne de l’opérateur de télécommunication MoviStar1
. Le management de
l’entreprise a donc décidé de valider les performances théoriques du logiciel IPTAX en matière de trafic et
nombre d’utilisateurs supporté, afin de s’assurer que la qualité de la solution vendue correspond aux
attentes du client.
La société a commencé par chercher une solution permettant de réaliser des tests de charge. Une
première phase, terminée en fin d’année dernière, a consisté à réaliser une analyse du marché des outils
de tests de charge. Elle a permis au management de l’entreprise de réaliser que l’achat d’une de ces
solutions commerciales était inenvisageable, l’investissement étant prohibitif pour une PME. Le
management d’Evistel a finalement décidé de s’orienter vers une solution alternative, soit du monde Open
Source, à déterminer et à personnaliser pour s’adapter aux besoins de l’entreprise, soit un développement
interne à réaliser ou toute autre solution viable économiquement.
Mon stage consiste donc à déterminer la solution la plus adaptée aux besoins de l’entreprise et à
réaliser les développements nécessaires à la création d’un simulateur de charge, puis de réaliser les tests
de l’application afin de valider les performances du logiciel.
Ce document a donc pour objectif de présenter le déroulement de mon stage, que j’ai réalisé en me
positionnant comme ingénieur intégration. Il se découpe en cinq parties.
 La première partie donnera une présentation de la société incluant un historique, quelques chiffres
essentiels, ses différents domaines d’activité et ses valeurs.
 La seconde partie décrira mon projet en cernant son contexte, ses objectifs et son périmètre.
 Dans la troisième partie, je présenterai l’organisation du projet et la méthodologie choisie.
 Enfin, la quatrième partie sera consacrée à la mise en œuvre du projet et aux résultats obtenus.
 Une conclusion viendra terminer ce document, où j’exposerai les résultats obtenus, expliquerai les
évolutions possibles du projet et je donnerai en tout dernier lieu mes conclusions personnelles.
1
Voir http://en.wikipedia.org/wiki/Movistar

Page 7
Glossaire & Acronymes
Cahier des charges : Document contractuel décrivant les produits attendus.
DASP : DAta Service Platform. Plateforme logicielle et matérielle permettant la création d’application de
taxation.
IP Charging : Taxation du trafic des réseaux IP
Maitrise d'œuvre : Instance chargée de réaliser les travaux qui lui sont confiés par la maitrise d'ouvrage.
Maitrise d'ouvrage : Instance ayant autorité pour définir ce qu’il y a à faire, charger quelqu'un de le faire et
de coordonner les travaux.
Planification : Action d'ordonnancer des taches dans le temps en intégrant les contraintes et paramètres
dégagés lors de la phase d'analyse.
PMP : Plan de management de projet. Document ayant pour objectif d'expliciter les choix en matière de
gestion du projet
Socket : Interface logicielle avec les services du système d’exploitation permettant la communication inter
processus à travers un réseau TCP/IP.
WBS ou SDP : Works Break-down Structure (organigramme des taches) ou Structure De Découpage du
Projet. Découpage du projet en tache afin de permettre sa réalisation.
OTA configuration : Over The Air configuration. Configuration des mobiles à distance à partir réseau de
l’opérateur
DMAIC : Define Measure Analyze Improve Control. Méthodologie de résolution de problème issue du 6-σ
DMADV : Define Measure Analyze Design Verify. Méthodologie de résolution de problème issue du 6-σ
EIR : Equipment Identity Register
GSM : Global System for Mobile communication
GPRS : General Packet Radio Service
HTTP : HyperText Transfer Protocol
IP : Internet Protocol
IPTAX : Logiciel de taxation sur réseau IP
MMS : Multimedia Messaging Service
SMS : Short Message system
SMS-MO : Short Message system Mobile Originated
SMS-MT : Short Message system Mobile Terminated
SUT : System Under Test
STP : Signal Transfer Point
TCP : Transmission Control Protocol
USSD : Unstructured Supplementary Service Data
WiFi : Wireless Fidelity
WAP : Wireless Access Protocol

Page 8
1. Evistel, une PME atypique
Ce premier chapitre est donc consacré à l’entreprise. La
première partie retracera l’histoire de cette jeune société. La
seconde s’intéressera à son portefeuille de produits et à ses clients
introduisant ce qui fait une de ses originalités : sa grande ouverture
à l’international. Enfin nous parlerons de ses valeurs, celles qui lui
permettent de séduire de nouveaux clients tout en conservant son
parc de clients existants.
1.1 Historique de la société
La société Evistel est une société dont le cœur de métier est
l'édition de logiciels de télécommunications. Cette société française,
constituée avec des capitaux privés, dont le siège social est situé à
Paris a été créée en 2000 par une équipe d’ingénieurs évoluant dans
le secteur des télécommunications depuis plus de 15 années.
La société en quelques chiffres clés
6 : Le nombre de nationalités différentes au sein de l’entreprise
18 : Le nombre d’employés en mai 2012
19 : Les pays où l’entreprise a vendu ses solutions à des clients
2000 : L’année de sa création
3000002
: Le Capital Social en €
1.2 L’organisation de l’entreprise
Comme beaucoup de PME l’organisation adoptée, de type
entrepreneuriale ou simple3
, se reflète dans l’organigramme de
l’entreprise présenté en page suivante qui révèle une structure
fonctionnelle où le service technique tient une place prépondérante.
2
Voir http://www.verif.com/societe/EVISTEL-431563105
3
Voir http://foad.refer.org/IMG/pdf/INTRODUCTION_ANALYSE_ORGANISATIONNELLE_M2.pdf p46

Page 9
Figure 1 : Organigramme de la société
On notera dans cet organigramme la présence de salariés sur trois continents : l’Europe, l’Amérique du sud
et l’Afrique. C’est une des caractéristiques de l’entreprise, son ouverture à l’international. On peut aussi
remarquer les multiples rôles joués par le PDG de l’entreprise : en charge du développement commerciale
de l’entreprise et de sa gestion.
Le service Intégration et support m’accueillera en son sein durant toute la durée du projet.
Une autre des caractéristiques de l’entreprise est son positionnement marketing, que nous allons
découvrir dans le paragraphe suivant.
1.3 Un positionnement marketing différent
Le marché des télécommunications est connu grâce à plusieurs des géants le constituant :
 Alcatel-Lucent, le franco-américain, 78000 employés, 15 696M€ de revenu en 2011
 Huawei, le chinois, 110 000 employés, 185 176M CNY (~22 266M€) de revenu en 2010
 Nokia-Siemens Networks, l’européen, 73 700 employés ,14 041M€ de revenu en 2011
respectivement numéro un, deux et trois mondial du marché des infrastructures de réseau de
télécommunication. Ces dernières années ce marché a connu une complète restructuration suite aux
fusions entre différents acteurs le composant entraînant la création d’entreprises internationales
implantées sur tous les continents. Quelle place existe-t-il pour un petit éditeur de logiciel au pays des
géants ? Intéressons-nous à ses produits, ses clients et ses valeurs pour apporter une réponse.
Source : Evistel

Page 10
1.3.1 Les produits
Une infrastructure de réseau GSM-GPRS (ou 2G-2,5G) typique est donnée dans la figure ci-dessous :
Figure 2 : Architecture de réseau GSM-GPRS
Les entreprises majeures du secteur se concentrent sur les éléments clés des réseaux GSM-GPRS :
 Les Base Transmission Stations et Base Station Controllers pour la partie hertzienne du réseau,
parfois appelée Radio Access Network4
, gérant le signal radio et permettant la mobilité
 Les Mobile Station Controller, Network Management Controller, Serving GPRS Support Node (resp
Gateway GSN) éléments majeurs du cœur de réseau permettant d’accéder aux différents réseaux
de communications Voix (PSDN ou ISDN) ou données (internet, PLMN)
 Les Operational Maintenance Center(-Radio) , Human Location Ressources ,Vehicle Location
Ressources qui sont des éléments de gestion du réseau
Un certain nombre d’éléments du réseau, considérés comme mineurs, ne sont pas développés en interne
par ces grands groupes (Equipment Identity Register, SMSCenter) ou sont sujets à la concurrence de
4
Ce terme est surtout utilisé dans les réseaux 3G et 4G

Page 11
petites sociétés5
développant des solutions adaptés aux besoins des opérateurs de télécommunication.
Evistel s’est positionné sur ce créneau.
L’entreprise fournit ainsi aux opérateurs de téléphonie mobile et fixe des solutions globales, évolutives,
pour une rentabilité optimale, dans les domaines suivants :
 Taxation en temps réel en environnements prépayé et post-payé des services suivants : SMS-MO,
Push & Pull SMS-MT, SMS+, MMS, GPRS, WAP, IP, WiFi, ainsi que pour les voyageurs itinérants,…
 Messagerie : SMSC fixe et mobile, Router SMS, intelligent STP, passerelle pour les services de
messagerie à valeur ajoutée, portails SMS & USSD,...
 Gestion des terminaux mobiles : EIR, OTA configuration
 Centre d’itinérance : Accès aux services du client à partir des réseaux des opérateurs étrangers
visités et offre de nouveaux services propres au réseau visité.
 Supervision et anti-fraude : supervision du trafic, anti-spam, interception, anti-fraude,…
Si le positionnement marketing en matière de produit permet à Evistel d’avoir une place sur ce marché, il
se traduit aussi par des clients atypiques lui permettant de se différencier de la concurrence.
5
http://www.intersec.com/solutions/messaging-solutions_11.php ou http://www.halys.fr/fr/produits/ sont notamment des
concurrents d’Evistel
Ci-contre et ci-dessous un exemple de baie en phase de tests juste
avant livraison à un des clients de l’entreprise, l’opérateur de
téléphonie mobile irakien Asiacell (http://www.asiacell.com)
On pourra noter l’utilisation de matériel standard du marché adapté aux
besoins des clients. Cette utilisation de produits standards s’applique
aussi aux systèmes d’exploitation, logiciels et outils de développement
de l’entreprise. La généralisation de l’utilisation des logiciels Open
source se fait progressivement, la base de données postgresql
remplaçant progressivement Oracle, par exemple.
Les produits développés se caractérisent par trois qualités essentielles :
- Leur prix,
- Leur simplicité,
- Leur robustesse.

Page 12
1.3.2 Les clients
Evistel vend ses solutions dans le monde entier. Ces dernières années la société a étoffé son
portefeuille de clients aussi bien en France qu’à l’étranger : Afrique, Moyen-Orient ou Asie. La plupart des
clients sont des opérateurs de téléphonie mobile et fixe créés récemment ou installés de longue date. Voici
quelques références clients localisés sur une carte du monde. Parmi les principales nous citerons :
 SFR (France);
 Maroc Telecom;
 SONATEL (Sénégal);
 Movistar chili;
Figure 3 : Références des clients d’Evistel à travers le monde
Les clients sont repartis sur la surface du globe obligeant ainsi l’entreprise à être présente sur tous les
continents afin de répondre le plus rapidement possible à leurs besoins.
Afin de répondre à ces besoins, Evistel a aussi choisi un positionnement différent au niveau de ses valeurs,
lui permettant de se démarquer de ses concurrents.
1.4 Les valeurs de l’entreprise
Pour survivre dans un monde de géants, l’entreprise a dû développer des valeurs lui permettant de
rester attractive aux yeux des clients existants et potentiels. On peut citer :
 La Flexibilité : L’entreprise doit s’adapter aux besoins et exigences spécifiques de ses clients. Son
objectif est d'offrir des solutions qui répondent parfaitement à leurs souhaits et d'avoir des
solutions qui s’intègrent de manière transparente sur l'infrastructure existante.
 La Réactivité : le déploiement des solutions a lieu en quelques semaines et toutes les demandes de
changement sont mises en œuvre rapidement.
Source : Evistel

Page 13
 La Satisfaction du client : l’entreprise considère que l'écoute et le soutien de ses clients est le cœur
de son travail. Ses solutions sont motivées par les besoins des clients qu’elle accompagne durant
tout le cycle de vie des produits. Ainsi un service de support technique mondial accessible 24
heures sur 24 et 7 jours sur 7 a été mis en place et un support personnalisé sur site est fourni, en
collaboration avec des partenaires présents dans le pays d’origine du client.
 L’Innovation : l’équipe Recherche & Développement est en constante recherche de solutions de
pointe qui sont compatibles avec les dernières technologies et les normes en constante évolution.
 La Qualité de service : Les solutions sont constamment testées et améliorés pour garantir leurs
performances et s’assurer de la qualité du service livré.
Une entreprise doit sans cesse trouver un équilibre entre Coût, Qualité et Délai afin de satisfaire ses
clients. Le coût et les délais sont privilégiés par Evistel, au détriment de la qualité ?
1.5 La qualité, le parent pauvre?
De toutes ces valeurs celles qui sont les plus appréciées des clients sont celles relatives à la souplesse
de l’entreprise. Mais si les coûts et les délais doivent être respectés pour garder les clients, il faut éviter de
le faire au détriment de la qualité. C’est donc dans le cadre de l’amélioration continue des outils de tests
d’Evistel et en finalité de la qualité des produits de la société que Thierry Lafue m’a proposé ce stage.
Cette première partie, traditionnellement consacrée à l’entreprise, a aussi permis de découvrir
l’architecture d’un réseau de télécommunications à la norme GSM ce qui a été utile pour présenter
les produits développés par Evistel et ainsi comprendre son positionnement. La présentation de ses
clients nous a permis d’appréhender la spécificité de l’entreprise : sa forte ouverture à
l’internationale. Enfin l’énoncé de ses valeurs a mis en avant ses forces, sa faculté à respecter les
coûts et les délais tout en introduisant sa faiblesse : la qualité.
Le chapitre suivant va cadrer le projet.

Page 14
2. Améliorer la qualité des produits
Ce chapitre a pour but de donner une image globale du projet. Il se découpe en trois parties
principales :
 La définition du contexte : cette première partie présente les raisons qui sont à l’origine du projet
 La problématique : dans un second temps la problématique et les solutions trouvées pour y
répondre sont traitées
 La présentation du projet : pour conclure ce chapitre le périmètre du projet est défini, des objectifs
aux livrables.
2.1 Le contexte
Cette partie a pour objet de présenter le logiciel IPTAX qui est le produit devant être testé, puis
d’introduire les différentes causes ayant données vie à ce projet.
2.1.1 Le produit IPTAX
Le logiciel IPTAX est un logiciel de taxation des appels réalisés à partir d’un périphérique connecté à un
réseau de télécommunications et communicant vers des réseaux de données de type IP. Il a pour fonction
de générer les enregistrements permettant la facturation des clients finaux. Ces enregistrements seront
exploités par un logiciel de facturation afin de produire la facture envoyée au client. Le logiciel peut ainsi
générer les enregistrements permettant de facturer un client utilisant son téléphone portable, de type
GSM, pour accéder à l’internet. Le schéma suivant, complément utile de la figure 2, présente la position du
logiciel dans un réseau GSM-GPRS.
Figure 4 : Position du logiciel IPTAX dans un réseau de télécommunication
Source : Evistel

Page 15
D’un point de vue technique, le logiciel est placé en coupure de ligne : il intercepte les appels du GGSN, les
analyse et génère les informations de facturation, puis les renvoie vers internet si le compte est crédité.
2.1.2 Les clients
Ce logiciel est notamment utilisé par la filiale chilienne de l’opérateur de télécommunication espagnole
Movistar. Les performances vendues à l’opérateur sont de 200 000 connexions simultanées.
2.1.3 Le service Intégration & support
Afin de tester les logiciels produits en interne avant livraison aux clients, le service intégration-
validation de l'entreprise utilise des outils de tests et des simulateurs pour valider leur fonctionnement. Les
outils créés pour tester IPTAX ne sont plus maintenus actuellement suite au départ de la société de
l’ingénieur en charge de leur développement. De plus les plates-formes de tests utilisées ont besoin
d'évoluer afin d'être adaptés aux besoins des ingénieurs en charge de l'exécution des tests, notamment
ceux réalisant les tests de charge.
2.2 La problématique
Pour valider la solution vendue à Movistar il est donc nécessaire d’avoir un outil simulant des
utilisateurs de mobiles générant un nombre de connexions au réseau internet suffisamment important
pour certifier les performances du logiciel : un simulateur de charge. Mais la durée de passage de ces tests
est en moyenne de quatre semaines par an. La problématique à laquelle s’est donc trouvé confronté le
management d’Evistel est d’ordre économique et technique :
Comment trouver une solution qui soit économiquement viable pour l’entreprise tout en étant
suffisamment performante pour générer la charge requise afin de valider les performances du logiciel
IPTAX ?
En effet les tests de charge nécessitent des outils performants et souvent coûteux, qu’une PME ne peut
s’offrir. Une première phase d’analyse du marché des outils de tests de charge réalisée en fin d’année 2011
a permis d’évaluer diverses solutions commerciales tel le produit IxLoad d’Ixia6
. Ce produit s’il est
performant nécessite un investissement initial de plusieurs dizaines de millier d’euros impossible à réaliser.
Le management de l’entreprise a donc décidé d’évaluer d’autres solutions :
 L’utilisation de solution Open source
 Des développements internes à l’entreprise
 Des logiciels du commerce, solutions alternatives à celles déjà étudiés
 Tout autre type de solution satisfaisante d’un point de vue économique, comme la location de
matériel, par exemple
Le projet que m’a confié Thierry Lafue en début d’année a donc été de réaliser cet outil de charge afin
de valider les performances du logiciel IPTAX. LOADTT, abréviation de LOAD Test Tool, sera le nom de
l’outil développé afin de simuler du trafic réseau pour tester IPTAX.
6
Voir http://www.ixiacom.com/products/ixload/index.php

Page 16
2.3 Le projet : Création d’un simulateur de charge pour le produit IPTAX
Après avoir cadré le projet lors des deux premières parties du chapitre, cette partie va terminer sa
définition en établissant son périmètre initial. Commençons par les objectifs.
2.3.1 Les objectifs
Les objectifs existent à la fois au niveau du produit à développer et du projet.
2.3.1.1 Objectifs du projet
Ces objectifs sont de différents ordres :
Techniques
 Améliorer les plates-formes de tests en introduisant des outils nouveaux via des développements
interne, l’utilisation d’outils Open Source ou l’achat d’outils standard du commerce
 Améliorer la qualité des logiciels développés par Evistel en participant à des compagnes de tests.
L’utilisation des nouveaux outils devra permettre de répondre aux exigences des clients relatives
aux performances du logiciel IPTAX.
Organisationnels
 Référencer les logiciels du monde du libre permettant les tests de charge
 Permettre à l'équipe d'intégration/validation de réaliser les tests de charge de manière autonome
Économiques
 Trouver une solution économiquement viable pour la société : le coût moyen d’une solution
matérielle ou logicielle permettant de simuler un nombre illimité d’utilisateurs permettant les tests
de charge varie autour 50K€. La fréquence estimée des tests de charge étant de deux périodes de
deux semaines par an en moyenne, ce coût d’investissement est prohibitif pour une PME.
 Minimiser les investissements en logiciel et matériel par l’utilisation des logiciels open source par
exemple
Humains
 Former les ingénieurs d’intégration aux outils de tests open source
2.3.1.2 Objectifs du produit
 Permettre les tests de charge sur le logiciel de facturation IPTAX en créant un outil suffisamment
performant pour émettre le nombre de paquets requis et simuler le nombre d’utilisateurs prévu
dans les spécifications du produit.
 Être suffisamment simple pour permettre des évolutions rapides en facilitant sa prise en main et en
documentant les développements.
2.3.2 Les enjeux
Afin de conserver ses clients une entreprise a besoin d’améliorer ses logiciels, notamment leur qualité.
Un des axes d’amélioration retenu par Evistel est l’optimisation des performances des logiciels suite à des

Page 17
demandes issues de plusieurs clients, principalement Movistar. L’enjeu principal est l’amélioration de la
satisfaction des clients afin de :
 Conserver les clients actuels,
 Gagner de nouveaux clients : pouvoir répondre aux demandes des clients potentiels en matière
de performances des logiciels est important dans un marché fortement concurrentiel comme
celui des télécommunications, les performances étant de plus en plus un critère préférentiel de
choix lors de leur sélection.
2.3.3 Les contraintes
Les contraintes à respecter sont de quatre types différents : temporels, économiques, techniques et de
performances.
 Contraintes de délais
o Le projet devra être terminé le 28 Juin au plus tard.
 Contraintes économiques
o Utilisation des logiciels libres si possible afin de minimiser les coûts
 Contraintes techniques
o Utilisation des plates-formes matérielles et logicielles en place dans l'entreprise
o Utilisation du système d'exploitation LINUX
o Être évolutif afin d’accompagner la montée en charge des produits
 Contraintes de performances
o Le simulateur de charge devra permettre :
 Dans une première phase : de simuler 100 000 téléphones mobiles connectés et
70 000 communications réseau simultanées (HTTP ou autres)
 À terme : de simuler 200000 utilisateurs, performance vendue à Movistar
2.3.4 Les difficultés pressenties
Les difficultés sont les suivantes :
 Phase d’appropriation de l’environnement longue en raison de la perte des connaissances et du
savoir-faire suite au départ du développeur des outils de tests existants
 Programmes existants insuffisamment documentés nécessitant un travail de documentation
important
 Ressources matérielles insuffisantes pour réaliser des tests de charges réalistes
2.3.5 Les livrables
Ce chapitre dresse la liste des livrables attendus en fin de projet. Ces livrables sont de deux types :
documentaires et logiciels.
2.3.5.1 Les documents à fournir
La liste des documents à fournir en fin de projet est donnée dans le tableau suivant.

Page 18
Document à fournir Gilles Lefebvre Format
Note de clarification X Word 2007 (.doc)
Plan de management de projet X Word 2007 (.doc)
Planning projet X MsProject (.mpp)
Étude comparative X Word 2007 (.doc)
Benchmark des solutions Open
Source retenues
X Word 2007 (.doc)
Présentation technique X PowerPoint(.ppt)
Cahier des charges fonctionnel
du simulateur
X Word 2007 (.doc)
Document d’architecture X Word 2007 (.doc)
Manuel d’utilisation du
simulateur
X Word 2007 (.doc)
Présentation du simulateur X Word 2007 (.doc)
Résultats des campagnes de
tests
X Word 2007 (.doc)
Tableau 1 : Liste des documents du projet
2.3.5.2 Les logiciels à réaliser
Outre les documents, divers logiciels seront à rendre en fin de projet :
 Le prototype qui aura servi à valider les solutions évalués
 Le simulateur qui servira pour les tests de charge du logiciel IPTAX
Enfin, une formation à l’outil développé devra être réalisée durant le stage afin de permettre son
utilisation par le personnel d’Evistel et transférer les compétences acquises pendant le PFE en matière de
tests de charge.
2.3.6 Les limites du projet
 La maintenance du simulateur ne sera pas prise en compte au-delà de la date butoir du 29 juin
2012.
 Les anomalies de fonctionnement du simulateur seront référencées hors du système de gestion des
anomalies de l’entreprise.
 La période de maintenance corrective se terminera le 22 Juin 2012 afin de pouvoir valider les
corrections entreprises jusqu'à cette date. Les anomalies constatées ultérieurement à cette date
seront uniquement référencées pour traitement par la MOA.
Toute cette partie consacrée au projet s’est traduite concrètement par la rédaction d’un Plan de
Management de Projet, outil indispensable à la gestion d’un projet. Réalisé en tout début de stage il
m’a permis de structurer le projet et a constitué un fil rouge durant toute sa durée. Le PMP contient
aussi les différentes phases du projet, qui correspondent à une démarche pour aboutir à un
résultat : la réalisation du simulateur de charge.
Je vais maintenant expliquer la démarche suivie pour réaliser le projet.

Page 19
3. L’organisation du projet
Ce troisième chapitre est consacré à l’organisation du projet. En tout premier lieu est présentée la
méthodologie utilisée pour le réaliser. Puis, dans une seconde partie, les phases découlant des choix
méthodologiques seront exposés, débouchant sur le macro planning. La quatrième partie sera dédiée à
l’analyse des risques relatifs au projet. En dernier lieu, les indicateurs du projet, outils permettant de suivre
l’avancement de celui-ci, seront décrits.
3.1 La méthodologie utilisée
Dans le monde industriel plusieurs méthodologies existantes permettent de mettre en œuvre des
projets. La méthode 6-Sigma propose ainsi deux méthodologies adaptées à différents types de projets :
 DMAIC : pour les processus existants défectueux
 DMADV : pour développer un nouveau produit ou service
Le PDCA, rendu populaire par Edwards Deming, est une démarche qui est souvent utilisé par les
services qualités pour résoudre les problèmes dans le cadre de l’amélioration continue d’un service ou
d’un processus.
L’industrie du logiciel, bien que récente, dispose aussi de ses propres méthodes, développées au cours
de ses trente dernières années. Le génie logiciel propose plusieurs modèles de cycle de vie du logiciel :
linéaire, non linéaire, incrémentaux, méthodes agiles, etc... J’ai choisi de mettre en œuvre un cycle de
développement hybride combinant le cycle de vie en V du logiciel, qui permet des phases de
recouvrement permettant les retours sur une phase et des tests à chaque phases, et une phase initiale de
prototypage permettant de m’assurer de la faisabilité du projet et de mieux cerner les besoins des
ingénieurs en charge des tests.
Le Prototype est une version d'essai du logiciel réalisé pour tester les différents concepts et exigences
et montrer au client les fonctions que l'on veut mettre en œuvre. Lorsque le client a donné son accord, le
développement suit un cycle de vie en V. Le principal avantage est que les efforts consacrés au
développement d'un prototype sont le plus souvent compensées par ceux gagnés à ne pas développer de
fonctions inutiles.
Le cycle de vie du logiciel propose 6 phases principales7
pour distinguer les différentes étapes de
développements.
 Analyse-étude préalable : Analyse de l’existant, définition des besoins du système d’information
et du logiciel sont les principales actions de cette phase
 Conception : La conception du Système d’information et du logiciel sont mises en œuvre
 Réalisation : Le codage consiste à traduire les algorithmes précédemment définis en un
programme compréhensible par l’ordinateur
 Tests : Vérification du bon fonctionnement du programme
 Exploitation : Utilisation du logiciel installé
 Maintenance : La correction des erreurs trouvées et l’amélioration des fonctions existantes
sont réalisées durant cette phase.
7
Voir Reference [4] en annexe 6.1

Page 20
Le génie logiciel propose aussi des phases et des documents standards pour la réalisation d’un logiciel
définissant le cycle de vie du logiciel. J’ai donc utilisé ces phases et documents que j’ai adaptés au projet
qui m’était confié. Les Livrables sont issus des demandes initiales de Thierry Lafue et Omar Ait-amrane et
des exigences projets. Les jalons correspondent soit à des demandes du management d’Evistel, soit à des
dates butoirs permettant la réalisation du projet dans son intégralité.
La partie suivante est consacrée à l’analyse des phases du projet et présente la structure de découpage du
projet qui en résulte.
3.2 La préparation du projet
Le cycle de vie du logiciel choisi entraîne ainsi le découpage en phase suivant.
3.2.1 Les phases du projet
Expliquons brièvement les tâches et activités liés à chaque phase avant de présenter le WBS qui en résulte
1-Étude préalable : Cette phase permet d’étudier l’environnement du projet afin de vérifier sa faisabilité et
de se former aux produits existant ainsi qu’aux méthodes de travail de l’entreprise.
1.1 Recueil de l'existant – État des lieux
1.1.1 Familiarisation avec l’organisation : Étape de prise en compte de l’environnement du projet :
humain, matériel, organisationnel.
1.1.2 Formation à l’environnement technique : Formation aux outils existants et à l’environnement
de tests (plate-forme, fiches de tests, stratégie de tests)
1.1.3 État des lieux : Réalisation d’un document décrivant l’état des outils de simulation sur la
plate-forme de tests.
1.2 Définition du cahier des charges : Cette étape permet de définir les besoins du client.
1.2.1 Recueil des besoins : Cette étape permet de recueillir les besoins des acteurs du projet en
matière de
1.2.2 Rédaction du cahier des charges : Cette étape consiste à formaliser les besoins recueillis dans
l’étape d’interview afin de créer un document initial de travail.
1.2.3 Mise à jour : Cette activité consiste à mettre à jour le CDC en fonction des retours de la MOA
afin de satisfaire à ses besoins
1.3 Prototypage et Maquettage : Cette phase permet d’explorer des solutions techniques variées et de
valider ces choix.
Amélioration des outils de tests
Création d'un simulateur de charge
1-Étude préalable 2-Conception 3-Réalisation 4- Mise en œuvre 5-Exploitation
6-Management de
projet

Page 21
1.3.1 Prototypage : Réalisation d’un simulateur fonctionnant avec des fonctionnalités réduites afin
de valider les choix techniques. Cette étape a débuté en même temps que l’étape 1.1.2 à des fins
de formation à l’environnement. Cette étape recense les outils de tests de charge existants du
marché et comprend le benchmark des solutions.
1.3.2 Maquettage : Cette étape (optionnelle) permet d’avoir une idée de l’IHM du simulateur.
1.4 Validation de la phase : Cette étape s’effectue avec le responsable R&D et le directeur technique
afin de valider les choix techniques et décider du passage à la phase suivante.
2-Conception : Cette phase permet de définir l’architecture technique du simulateur
2.1 Conception générale : Cette étape permet de concevoir théoriquement le simulateur
2.1.1 Définition de l’architecture du simulateur : On s’occupe dans cette étape de l’architecture du
simulateur. On définit par exemple les besoins en équipements (éléments de réseaux, ordinateurs,
cartes de communication, câblage,..) et en logiciel (Base de données, système d’exploitation,
langage de programmation, outils de développement, Gestion de configuration) ainsi que
l’organisation de celui-ci. Les paquetages sont, par exemple, définit dans cette phase.
2.1.2 Rédaction du plan de tests : Il permet la validation du logiciel
2.2 Conception détaillée : Cette étape permet de détailler les procédures, fonctions, objets, packages
nécessaire à la réalisation du simulateur
2.2.1 Spécifications détaillées des paquetages : la description détaillée des paquetages du
simulateur, en vue de sa réalisation
2.2.2 Définition de l’IHM : Les écrans, leurs enchaînements et l’ergonomie du logiciel seront
définies dans cette partie.
2.3 Validation de la phase : Cette étape permet la validation des choix réalisés et permettra de débuter
la phase de réalisation.
3-Réalisation : Cette phase consiste à réaliser le simulateur
3.1 Développement : Codage
3.2 Tests : Cette étape permet de valider le simulateur
3.3 Documentation : Rédaction des divers documents constituant le simulateur
3.3.1 Rédaction du manuel utilisateur : Document permettant la prise en main du logiciel
3.3.2 Rédaction faq : Document répondant à des questions d’ordre générale permettant de faciliter
l’assistance technique
3.3.3 Rédaction HowTo : Document de prise en main rapide du simulateur
3.4 Recette : Cette étape valide le produit
4-Mise en œuvre : Cette phase permet de mettre à disposition le simulateur aux utilisateurs.
4.1 Déploiement du logiciel : Cette étape peut être réduite à une installation sur les PC de la plate-
forme de tests.
4.2 Formations des ingénieurs à l’outil : Cette étape permet la formation des ingénieurs à l’outil de
simulation.

Page 22
4.2.1 Création d’un document de formation : Cette étape permet de laisser des documents
permettant une prise en main rapide de l’outil.
4.2.2 Session de formation : Elle dure une journée et sera constituée d’une session théorique et
d’une session pratique afin de prendre en main le simulateur.
4.3 Bilan de fin de projet : Cette étape permet, d’une part, de comparer les dispositions initialement
prévues avec le déroulement réel du projet et, d’autre part, de porter un regard critique sur tous les
aspects du projet pour en tirer des voies d’amélioration pour les futurs projets.
5-Exploitation et Maintenance : Cette phase démarre dès la formation des ingénieurs d’intégration et
s’effectue en parallèle avec l’étape de participation aux campagnes de tests. Elle a pour but d’apporter un
support technique aux utilisateurs.
5.1 Assistance technique : Cette activité se traduit par une assistance aux utilisateurs afin de les
accompagner dans leur utilisation quotidienne et de répondre à leurs questions
5.2 Maintenance corrective et évolutive : Elle permet de réaliser des corrections d’anomalies dans
l’outil après sa mise en œuvre et de recenser les demandes d’évolutions de la part des utilisateurs. Ne
seront traités que les évolutions mineures pouvant être développées avant la fin du projet.
5.3 Participation aux campagnes de tests : Cette étape permet les tests de l’application IPTAX.
6-Management de projet : Cette phase se déroule pendant toute la durée du projet et elle est constituée
d’activités récurrentes ou de tâches servant à l’initialiser comme l’écriture du PMP.
6.1 Rédaction du PMP et des documents Projets : Ce document contractuel de communication servira
de référence durant le pilotage du Projet. Il permet de structurer, d'assurer et d'optimiser le bon
déroulement du Projet. Il est rédigé par le chef de Projet et validé par la Maîtrise d'Ouvrage. Il est diffusé à
l'ensemble des acteurs du Projet pour que tous aient le même niveau d'information. Ce document pourra
subir des réajustements et des modifications en fonction des aléas rencontrés pendant la durée du projet.
Tout changement et remaniement du document doit être réalisé par le Chef de projet. Une fois les mises à
jour effectuées, il est impératif de faire valider celui-ci par la Maîtrise d'Ouvrage et de communiquer les
éventuels changements à l'ensemble de l'équipe Projet. Une note de clarification sera rédigée au tout
début du projet.
6.2 Planification : Cette activité permet de PRÉVOIR un programme d’action en début de projet puis de
CONTRÔLER le déroulement de celui-ci, d'ADAPTER le plan aux nouvelles exigences enfin de DÉCIDER en
continu, jusqu’à la fin du projet.
6.3 Pilotage du projet : Le pilotage de projet permet de valider le bon déroulement du projet. Il est
effectué par le responsable de projet et il est réalisé durant toute la durée du projet.
6.4 Réunions et comptes rendus : Ils permettent de communiquer avec la MOA
6.4.1 Réunions d’avancement projet : permettant le suivi du projet par la MOA
6.4.2 Réunions techniques ponctuelles : Cette activité permet la validation des choix techniques
effectués.
6.4.3 Rédaction des comptes rendus : Permettant de communiquer avec la MOA et de tracer les
événements durant la vie du projet.
3.2.2 Le WBS
Le WBS, résultant du découpage en tâche précédent, est donné dans les figures suivantes. Il est aussi
un des points d’entrées du macro planning donné dans la partie suivante.

Page 23
Figure 5 : Structure de découpage de projet
1-Étude préalable
1.1 Recueil de
l'existant – État
des lieux
1.1.1
Familiarisation
avec
l’organisation
1.1.2 Formation
à l'
environnement
technique
1.1.3 État des
lieux
1.2 Définition
du cahier des
charges
1.2.1 Recueil
des besoins
1.2.2 Rédaction
du cahier des
charges
1.2.3 Suivi du
CDC
1.3 Prototypage
et Maquettage
1.3.1
Prototypage
1.3.2
Maquettage
1.4 Validation
de la phase
2-Conception
2.1 Conception
générale
2.1.1 Définition de
l’architecture du
simulateur
2.2.2 Rédaction du plan de
tests
2.2 Conception
détaillée
2.2.1 Spécifications
détaillées des
paquetages
2.2.2 Définition de IHM
2.3 Validation
de la phase -
Présentation
3-Réalisation
3.1
Développement
3.2 Tests
3.3
Documentation
3.4 Recette
4- Mise en
œuvre
4.1
Déploiement
4.2 Formations
des ingénieurs à
l’outil
4.3 Bilan projet
5-Exploitation
5.1 Assistance
5.2
Maintenance
corrective et
évolutive
5.3
Participation
aux campagnes
de tests
6-Management
de projet
6.1 Rédaction
du PMP
6.2 Planification
6.3 Pilotage du
projet
6.4 Réunions et
comptes rendus

Page 24
Figure 6 : Structure de découpage de projet (suite)
3.3 Documentation
3.3.1 Rédaction du manuel
utilisateur
3.3.2 Rédaction faq 3.3.3 Rédaction HowTo
4.2 Formations des
ingénieurs à l’outil
4.2.1 Création d’un document
de formation
4.2.2 Session de formation
6.4 Réunions et comptes
rendus
6.4.1 Réunions d’avancement
projet
6.4.2 Réunions techniques
ponctuelles
6.4.3 Rédaction des CR

Page 25
3.3 Le macro planning
Figure 7 : Le macro planning des taches du projet

Page 26
3.4 L’analyse des risques initiaux
Les différents risques ainsi que les actions prévues pour les prévenir ou les corriger sont définis dans le
tableau suivant.
N° Description du Risque Proba
bilité
Gravité Criticité Actions Préventives / Actions correctives
1 Cahier des charges
fonctionnel du simulateur
de charge mal défini
4 2 8 - Revue du cahier des charges
- Développement incrémental si
nécessaire
2 Mauvaise compréhension
du problème
2 4 8 - Rencontre d'utilisateurs
- Réunions techniques
3 Perfectionnisme 4 3 12 - Examen critique des spécifications
- Maquettage
- Analyse de la valeur (enjeux des
fonctions)
4 Ajout de spécifications
durant le projet
4 2 8 - Seuil d'acceptation des changements
- Développement incrémental, gestion
de lots
- Report des modifications en fin de
projet, gestion de versions
5 Simulateur inadapté aux
besoins de la MOA
2 4 8 - Rédaction anticipée des tests de recette
6 Complexité du problème
mal estimée entraînant un
dépassement des délais
3 4 12 - Suivi hebdomadaire de l'avancement
- Remise en cause des demandes
- Développement incrémental
- Réutilisation de code existant
7 Disponibilité réduite des
ressources matérielles car
en nombre limitée et
partagées entre les
différentes équipes.
exemple : plate-forme de
tests.
3 4 12 - Planning d’utilisation des plates-formes
- Respect des délais
8 Disponibilité des
ingénieurs
3 4 12 - Anticipation des problèmes
- Auto formation
Tableau 2 : Matrice des risques projet
C= Px G avec P, G et C définis dans les tableaux ci-après.

Page 27
NIVEAU DE CRITICITÉ (C)
C <10 Risques mineurs – Acceptables Management du projet
10 <= C <=12 Risques majeurs – Sous surveillance Plan d’action suivi régulièrement
15 <= C <=16
Risques critiques – Action d'urgence
à mettre en œuvre
Communication au client
Plan d’action suivi à la semaine
C >=20
Risques Inacceptables – Actions
Préventives
Arrêt du projet
Communication au client
Renforcement de l’équipe et/ou des
compétences
Plan d’action suivi à la semaine ou à la
journée
3.5 Les indicateurs de suivi
Pour assurer le suivi de projet, il est nécessaire de piloter l’ensemble des tâches dans le temps et de
pouvoir les suivre en temps réel. Il faut donc mettre en place des indicateurs de suivis pertinents pour le
projet. Les indicateurs retenus sont les suivant :
 Indicateur de suivi des tâches : Il permet de suivre l’état d’avancement de chaque tâche.
 Indicateur de suivi des livrables : Il permet de connaître le statut d’un livrable (non commencé, en
création, …)
Ces indicateurs prendront la forme d’un diagramme en bâton :
Figure 8 : Format des Indicateurs d'avancement des tâches et livrables
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Tâche 1 Tâche 2 Tâche 3 Tâche 4
% Restant à faire
% Réalisé
PROBABILITÉ (P)
1 Impossible ou improbable
2 très peu probable
3 Peu probable Décennie
4 probable Annuelle, semestrielle
5 Très probable à certain
mensuelle, hebdomadaire,
quotidien
GRAVITÉ (G)
1 Détail
2 Alerte
3 Mineur
4 Majeur
5 Critique

Page 28
Afin de simplifier la gestion de projet les taches ont été regroupées en lots8
qui servent essentiellement au
suivi de projet. Les indicateurs de réalisation des lots synthétisant l’avancement du projet sont regroupés
dans une feuille Excel qui fera office de tableau de bord du projet. Un exemple du tableau de bord est
donné ci-dessous.
Figure 9 : Instantané du tableau de bord projet le 01/06/12
8
Voir annexe 6.2 pour une description des lots de travaux

Page 29
3.6 Le système d’information
Le système d’information permet de faciliter la communication sur le projet. Celui mis en œuvre sur le
projet concerne la communication écrite et orale et formalise le format des documents, des réunions et
des échanges d’informations.
3.6.1 Le référentiel documentaire du projet
Les règles de nommage choisies pour les documents générées pendant la durée du projet sont les
suivantes :
<Nom_Document>_AméliorationOutilsDeTestsEvistel_Ed<xx>_Pr<yy>.<ext>
Avec :
NOM_DOCUMENT : Sigle représentant le type du document
Sigle Type de Document
BEN Benchmark
CR Compte Rendu de réunion
CDC Cahier des charges
DCG Dossier de conception générale
DCD Dossier de conception détaillée
NDC Note de clarification
PMP Plan de Management de projet
DDT Dossier de tests
MU Manuel Utilisateur
PRES Présentation
FAQ Frequently Asked Questions
SYN Synthèse
PLAN Planning
HOWTO Livre de recette
DOC Documents divers
Tableau 3 : Types de documents générés par le projet et sigles associés
Edxx : Version majeure du document. Ce nombre correspond à une version validée par
l’approbateur du document.
[Pr]yy : Version mineur du document. Ce nombre correspond à une version de travail dans
l’édition courante n’ayant pas encore été approuvée (Pryy) ou à une version mineure.
ext : Le type du fichier (.pdf, .doc, .docx, .xls, .ppt, …)
Les fichiers Word sont au format Word 2007 pour pouvoir être utilisés avec open office.
Une charte graphique sera utilisée tout au long du projet, un modèle de référence servant de base aux
divers documents générés. Ce fichier suit par conséquent la charte graphique.
Pour les fichiers Word, on utilisera une page de garde constitué des deux cadres suivants pour mettre en
évidences les différents ajouts et les corrections apportées.

Page 30
Le cadre gestion des évolutions
Gestion des évolutions
Mise à jour Prénom Nom jj/mm/aa EdXXPrYY
Document initial Gilles Lefebvre 20/01/12 Ed01Pr01
Historique Nom Date Révisions
Le cadre des responsabilités
3.6.2 La gestion de configuration pour le simulateur de charge
Un logiciel de gestion de configuration est prévu sur le projet afin de faciliter le référencement et le
suivi des versions des livrables. Le logiciel utilisé est CVS.
3.6.3 La communication sur le projet
Pour assurer une bonne communication entre les différents acteurs du projet il est nécessaire de
mettre en place des étapes de communication planifiées, efficaces et adaptées au contexte. Dans cette
partie, il est fait mention de l'ensemble des moyens et techniques (réunions diverses, système
d’information) qui sont mise en place afin de communiquer à tous les membres de l'équipe projet l'état
d'avancement des différentes phases et étapes de celui-ci.
3.6.3.1 La liste des intervenants
La liste des intervenants est la même que celle des acteurs à laquelle on peut rajouter des ingénieurs
d’intégration ou des chefs de projets en fonction des besoins ou des problèmes rencontrés.
3.6.3.2 Les réunions
Durant le Projet un certain nombre de réunions sont organisées. La nature de ces réunions varie
suivant leurs objectifs, on peut néanmoins citer les réunions suivantes :
 Les réunions de recadrage : Prévues en fin de phase elles permettent de gérer les écarts entre
prévu et réalisé.
 Les réunions bimensuelles : ces réunions sont des outils de coordination entre les différents acteurs
du Projet. Leur rôle est d'informer les membres du Projet sur le déroulement de celui-ci, d'échanger
les connaissances donc de favoriser l'expertise et de critiquer certaines démarches ou solutions
Rédacteur Approbation Autorisation de diffusion
Nom Gilles Lefebvre Omar Ait-amrane Thierry Lafue
Responsabilité Responsable de projet Responsable R&D Directeur Technique
Date 20/01/12 20/02/12 20/02/12
Visa

Page 31
pour donner une nouvelle orientation, enfin de mettre en place des axes d'amélioration. Ces
réunions auront une durée de 30 minutes maximum.
 Réunions contractuels avec le CESI : ces réunions influent sur le cours du projet et son calendrier et
sont données ci-après :
Mardi 6 mars 2012 1er
retour obligatoire en centre pour une présentation PowerPoint de
l’élève ingénieur sur son stage
Lundi 14 mai 2012 2ième
retour obligatoire en centre pour une présentation Powerpoint
version 1 de la soutenance orale finale
Entre le lundi 11 juin et le
vendredi 15 juin 2012
Prévoir 2 demi-journées pour les soutenances blanches
Mercredi 20 juin 2012 Soutenances
Vendredi 29 juin 2012 AM Réunion de bilan de la formation à Nanterre
3.6.3.3 Les échanges d’informations
L’échange des informations entre les différents acteurs du projet se fait par mails afin de laisser des
traces perdurables.
Les réunions font l’objet de comptes rendus diffusés aux acteurs du projet auxquels on rajoute les
intervenants ponctuels nécessaires à l’avancement du projet.
Les livrables sont diffusés et stockés sur les espaces partagés mis à disposition pour le projet par
Evistel. Des sauvegardes périodiques sont réalisées pour archivage.
3.7 Les moyens
Les moyens mis à ma disposition pendant la durée du projet ont été de deux types : matériels et
humains. J’ai disposé d’un bureau, d’un ordinateur et d’un accès à l’internet pour réaliser le projet. J’ai
aussi eu accès aux ressources suivantes :
 à la messagerie de l’entreprise pour communiquer avec les sociétés extérieures
 à la documentation relative aux produits développés par Evistel
 aux équipements de la plate-forme de tests afin d’installer les logiciels et les outils développés et
tester les produits Evistel
Outre les moyens matériels, j’ai aussi eu besoin d’aide et de support de la part des ingénieurs d’Evistel
pour réaliser le projet.

Page 32
3.8 Les intervenants
Pour terminer cette phase de préparation du projet je vais citer les principaux intervenants du projet et
donner leurs rôles respectifs dans les deux tableaux suivants:
Nom Fonction E-mail Téléphone
Gilles Lefebvre Responsable du
projet
gilles.lefebvre@evistel.com 01 53 62 40 69
Philippe Verdier Ingénieur
responsable du
produit IPTAX
philippe.verdier@evistel.com
Omar Ait-amrane responsable R&D omar.aitamrane@evistel.com
Thierry Lafue Directeur technique thierry.lafue@evistel.com
Tableau 4 : Liste des acteurs du projet
Acteurs
Phases /
Tâches
Responsable de
projet
Gilles Lefebvre
Ingénieur responsable
du produit IPTAX
Philippe Verdier
Responsable R&D
Omar Ait-amrane
Directeur technique
Thierry Lafue
1 R C A I
2 R C A I
3 R A I
4 R A I
5 R A I
6 R A I
Tableau 5 : Matrice des responsabilités (RACI)
Liste des responsabilités associées aux phases du projet :
 R : Responsible
 A : Accountable
 C : Consulted
 I : Informed
J’ai eu besoin des connaissances techniques de Philippe Verdier pour comprendre le logiciel IPTAX et
pour passer les tests, et de celles plus organisationnelles de Thierry Lafue et Omar Ait-amrane pour la
partie gestion de projet afin de de valider mes décisions.
Ce chapitre va se clore sur le budget alloué au projet.
3.9 Le budget prévisionnel
Aucun budget initial n’avait été prévu à l’origine par l’entreprise pour l’achat de logiciel ou de matériel.
Néanmoins un ordinateur DELL Précision T3500 d’une valeur de 750€ HT (897 € TTC) suffisamment
puissant pour tester le logiciel IPTAX a été acheté pour les besoins du projet.
En outre, hormis le recours à un stagiaire pour réaliser le projet, seules les ressources humaines
précédemment cités, ont été utilisé pour le calcul. Le projet est chiffré en « charge de travail » et non en

Page 33
«coût» dans cette partie du projet. Concrètement, la charge de travail comptabilise l’estimation des heures
de main-d’œuvre sur les ressources utilisées pour la réalisation du projet. Le nombre d’heures estimé est
directement issu des jours prévus dans le planning détaillé donné en annexe.
Acteurs Type de l’inducteur de coût Quantité de travail en jour
(h)
Gilles Lefebvre Pilotage du projet, actions à réaliser,
réunions
115 (805)
Omar Ait-Amrane Réunions, Relecture de documents 1 (7)
Thierry Lafue Réunions, Relecture de documents 2 (14)
Philippe Verdier Formation, Réunion, Tests, Relecture 4 (28)
Total (h) 122 (854)
Une journée de travail équivaut à 7 heures travaillés
Les trois premières parties ont présentés l’entreprise, le projet, et son organisation théorique. Avant
de passer à la suivante, plus pratique, Citons Jan van de Sneptscheut :
« La différence entre la théorie et la pratique, c’est qu’en théorie, il n’y a pas de différence entre la
théorie et la pratique, mais qu’en pratique, il y en a une. »
De la théorie à la pratique, que s’est-il passé sur le projet? Car hélas, tout projet subi des aléas qui
l’amène à prendre des retards voir à échouer dans le pire des cas et rare sont les projets
informatiques totalement réussi (Voir l’annexe 6.1 référence 5).

Page 34
4. Le déroulement du projet : de la théorie à la pratique
Ce chapitre décrit le travail réalisé sur le projet en détaillant chacune de ses phases. Pour chaque phase
un point est réalisé, permettant de distinguer les tâches réalisées des tâches en cours et de celles restant à
faire ou annulé. Pour réaliser cela, le WBS est utilisé, chaque case étant colorée en fonction de son
avancement. Le code couleur utilisé est le suivant :
 Vert : réalisée
 orange : en cours de réalisation
 Rouge : non réalisée
Commençons par la gestion de projet, activité qui a débutée avec le projet et qui a permis de le structurer.
4.1 Une activité transversale : le management du projet
Cette activité qui couvre toute la durée du stage a permis de démarrer le projet en le structurant. Elle a
permis de définir et délimiter le projet dans un premier temps puis à consister à assurer son suivi durant la
période du stage. Elle se découpe en cinq tâches élémentaires :
 Rédiger la note de clarification
 Rédiger le plan de management
 Créer le planning initial
 Piloter le projet
 Gérer les réunions et rédiger les comptes rendus afférents
6-Management de
projet
6.1 Rédaction du
PMP
6.2 Planification
6.3 Pilotage du
projet
6.4 Réunions et
comptes rendus
6.4.1 Réunions
d’avancement
projet
6.4.2 Réunions
techniques
ponctuelles
6.4.3 Rédaction
des CR

Page 35
4.1.1 Rédiger la note de clarification, le plan de management et créer le planning initial
La rédaction de la note de clarification m’a permis de lancer le projet en synthétisant les données
obtenues lors des différents entretiens précédant le début du projet.
Elle s’est enchaînée immédiatement avec la réalisation du plan de management constituant mon
second livrable. Cette tâche s’est déroulée en parallèle avec d’autres tâches initiales du projet me
permettant d’assimiler le fonctionnement de l’entreprise et les demandes du management. Je l’ai réalisé
en me servant des compétences acquises au cours de ma carrière en matière de génie logiciel et de celles
nouvellement acquises en matière de gestion de projet.
La rédaction du PMP a découlé de ces choix initiaux et de mes compétences nouvellement acquises
dans le domaine de la gestion de projet.
Le PMP a été le fil rouge du projet et a aussi servi de contrat entre mon responsable de projet et moi
en définissant les grandes lignes du projet. Il a été validé par mon responsable de stage avant d’être
envoyé au CESI.
Le planning initial à quant à lui résulté du WBS réalisé pour le PMP. Il m’a permis d’avoir une idée
précise du futur avancement du projet.
4.1.2 Piloter le projet
Cette activité m’a permis de suivre mon projet et notamment son avancement. Pour ce faire, j’ai utilisé
certaines des données de mon plan de management ainsi que les outils suivants :
 Le planning,
 Les fiches de lots9
,
 L’analyse des risques
La fréquence du pilotage (2 fois par mois en début de projet puis 1 fois par semaine dans la seconde moitié
du stage) m’a permis d’avoir une vue d’avancement de mon projet en temps réel et d’obtenir les résultats
suivants :
 Suivi de l’avancement des tâches,
 Mise à jour La liste des risques qui bloquent l’avancement du projet,
 Archivage des documents projet,
 Surveillance et mise à jour de mon Plan de management.
4.1.3 Gérer les réunions et rédiger les comptes rendus afférents
Les réunions ont été moins nombreuses que prévu, une fois par mois, et donc moins chronophage. La
communication par e-mail a permis de transmettre les informations essentielles sur l’avancement du
projet.
La phase d’initialisation du projet terminée, j’ai commencé la phase la plus importante du projet :
l’étude préalable.
9
Voir en annexe 6.3 pour une description détaillée

Page 36
4.2 L’étude préalable
L’étude préalable a permis de vérifier la faisabilité du projet grâce à la réalisation du prototype tout en
le structurant par la rédaction d’un cahier des charges. Mais le premier livrable que j’ai rédigé a été l’état
des lieux initial qui a permis de référencer l’existant. Ce document a été réalisé à l’issue des taches de
familiarisation avec l’environnement et de formation à l’environnement technique ayant pour but de
m’intégrer à l’entreprise.
4.2.1 Familiarisation avec l’environnement
Cette première étape de prise en compte de l’environnement du projet, m’a permis de me familiariser
avec l’entreprise. D’un point de vue humain elle m’a permis de découvrir mes collègues, apprendre quelles
étaient leurs positions respectives dans l’entreprise et leur travail afin de savoir à qui m’adresser en cas de
problèmes et enfin, de découvrir les caractères de chacun.
Du point de vue organisationnel elle m’a permis de découvrir le fonctionnement de l’entreprise et de
comprendre les circuits d’information. Par exemple, Evistel n’a pas de services transverses réalisant les
tâches de support classiques comme dans les grandes entreprises. Il est donc important de comprendre
l’organisation de l’entreprise afin de déterminer le niveau d’autonomie requis pour réaliser une tâche. En
outre cette étape m’a permis de cerner le type de comportement à adopter afin de mener à bien le projet
et de déterminer les marges de manœuvres laissées à chacun dans l’exécution de son travail. Enfin elle
m’a permis d’obtenir les informations nécessaires au démarrage du projet. Savoir où sont stockés les
divers documents projet (fiches de tests, stratégie de tests, document de références, présentations…) est
important accomplir le projet. Cette étape initiale de recherche d’information a été complétée par une
activité de recherche d’informations qui a duré durant toute la durée du projet.
1-Étude préalable
1.1 Recueil de
l'existant – État des
lieux
1.1.1
Familiarisation avec
l’organisation
1.1.2 Formation à l'
environnement
technique
1.1.3 État des lieux
1.2 Définition du
cahier des charges
1.2.1 Recueil des
besoins
1.2.2 Rédaction du
cahier des charges
1.2.3 Suivi du CDC
1.3 Prototypage et
Maquettage
1.3.1 Prototypage
1.3.2 Maquettage
1.4 Validation de
la phase

Page 37
Comprendre le fonctionnement de l’entreprise est important, mais le secteur Hi-Tech est très
technique, il est donc important de comprendre quelles sont les outils et méthodes utilisés et de se
familiariser avec l’environnement de travail.
4.2.2 Formation à l’environnement technique
Cette formation s’est faite en lisant les documents recueillis lors de l’étape précédente et en discutant
avec les ingénieurs testant les produits. Elle m’a permis de me familiariser aux outils et à l’environnement
de tests existant. Par exemple, savoir comment accéder aux serveurs, connaître leur emplacement en
plate-forme de tests, récupérer les mots de passes sont des prérequis au démarrage du projet. J’ai ainsi
appris que l’entreprise utilise uniquement le système d’exploitation LINUX mais plusieurs distributions,
principalement Debian et Red Hat, et les logiciels Open Source pour ses produits: PostgreSql comme base
de données, CVS comme logiciel de gestion des configurations, les langages C, Perl et Python pour le
développement. Pour être utilisé le simulateur créé devait donc s’intégrer les plus possible dans
l’environnement existant sans remette en cause les choix technique déjà réalisé. J’ai donc décidé d’utiliser
LINUX comme système d’exploitation et le langage Perl associé à des SHELL scripts pour la programmation.
Le langage de scripting Perl est utilisé pour sa polyvalence et sa base de paquetages importante.
Je me suis plus particulièrement intéressé aux outils de tests existants. Les ingénieurs les utilisent pour
les tests fonctionnels du produit IPTAX. Ma première idée a été de les utiliser et de les adapter pour
réaliser mon projet. Pour cela il était nécessaire de réaliser un état des lieux.
4.2.3 État des lieux
Si les deux tâches précédentes étaient nécessaires afin de pouvoir accéder au serveur où étaient
stockés les outils de tests existants, l’état des lieux initial qui s’est concrétisé par un document, premier
livrable du projet, m’a permis de déterminer la charge de travail à réaliser.
L’entreprise utilisait en interne des outils de tests fonctionnels afin de valider les logiciels qu’elle
développe. Il existait notamment des outils pour tester IPTAX. Un ingénieur ayant quitté l’entreprise avait
ainsi déjà réalisé un embryon d’outil permettant de générer du trafic WEB. Connaître les limites de cet
outil et savoir quelles parties réutiliser m’a permis de minimiser les développements. J’ai ainsi récupéré
des informations précieuses sur l’existant et réalisé qu’il était impossible de continuer dans la voie choisie,
débouchant sur une impasse en raisons des performances limités de l’outil créé et de l’impossibilité à
l’améliorer dû à l’architecture matérielle et logicielle employée comme le montre le schéma ci-dessous.

Page 38
Figure 10 : Architecture de l’outil de test fonctionnel initial
Les points faibles de l’architecture sont indiqués en rouge dans le schéma précédent. Détaillons-les en
les traitant par ordre d’importance:
 La puissance de la configuration simulant le GGSN est le plus gênant pour les tests de charge. La
comparaison entre le serveur IPTAX et le simulateur tourne clairement à l’avantage d’IPTAX ! Afin
d’y remédier il faut impérativement plus de mémoire vive, 512 Mo étant suffisant pour générer le
trafic nécessaire pour les tests fonctionnels mais insuffisant pour de la charge. De plus le
processeur est vieillissant et ses performances sont insuffisantes pour stresser un processeur de
nouvelle génération.
 Le processus émetteur de requêtes utilise Perl qui est un langage interprété ayant des
performances limitées.
 Le processus gérant les réponses est un programme Python : Le support de nouveaux protocoles
nécessite des développements importants et les performances sont limitées.
 Le réseau IP utilise Ethernet 100Mbits/s : Utiliser un réseau Gigabit permet d’augmenter la charge.
 L’architecture client-serveur choisie ne permet pas un dimensionnement de la plate-forme en
fonction de la charge : un client émet vers un serveur, plus de charge signifie une duplication des
environnements.
 Le serveur d’authentification Radius est localisé sur la même machine que le serveur générant la
charge.
On peut remarquer une double difficulté dans le choix des outils :
 Le client doit être performant : L’injecteur de charge doit être capable de générer un trafic
important
 Le serveur doit être performant : Le bouchon doit être capable de tenir la charge générée par
l’injecteur

Page 39
La recherche de nouvelles voies s’avérait donc nécessaires. Mais pour réaliser un simulateur de charge
adapté aux besoins il était nécessaire de les formaliser sous la forme d’un cahier des charges.
4.2.4 Définition du cahier des charges
Le cahier des charges a été écrit à partir des besoins exprimés oralement par T. Lafue et P.Verdier lors
de discussion informels sur le projet. Il en est ressorti les besoins suivants :
 Avoir une solution simple à mette en œuvre et facile à utiliser. Les tests doivent pouvoir être
exécutés rapidement.
 Avoir une solution peu coûteuse, et donc favoriser la piste des logiciels open Source. Un
document recensant les solutions possibles et plus s’intéressant plus particulièrement aux
solutions Open source valable pour la charge requise a d’ailleurs été demandé par T Lafue. Ce
document a été rédigé pendant la phase de prototypage.
 Être évolutive et pouvoir s’adapter à des besoins changeant.
 Supporter les protocoles HTTP et HTTPS
 Être capable de mesurer le temps de latence du logiciel IPTAX
 Être capable de générer une charge de 200 000 utilisateurs pour valider la solution vendue à
Movistar.
Ce recueil des besoins a été complété par une analyse fonctionnelle réalisée à l’aide de la méthode
APTE m’ayant permis de valider les besoins auprès des utilisateurs. Les diagrammes de type bête à corne
et pieuvre issus de cette phase de réflexion sont donnés ci-dessous.
à qui rend il service? Sur quoi agit-il ?
Dans quel but le système existe-il?
Figure 11 : Bête à corne du simulateur de charge
Simulateur de tests de
charge
Aux
développeurs
Le logiciel IPTAX
Exécuter les tests,
Réaliser des mesures
Conserver les résultats de tests

Page 40
Figure 12 : Diagramme pieuvre du simulateur
Les besoins m’ont conforté dans le choix de l’open source, la contrainte liée au coût de la solution
étant la plus importante pour le management. La solution devant être la moins chère possible, la
programmation d’un outil « maison » s’est avérée impossible dans le temps imparti.
La partie la plus importante du projet a alors débuté : trouver une solution Open Source capable de
générer un trafic HTTP important.
4.2.5 Prototypage et maquettage
La réalisation du prototype s’est faite en suivant les étapes suivantes:
 Collecte d’informations relatives aux outils de charge Open Source sur le WEB : injecteur et
bouchon
 Rédaction du livrable relatif aux outils de charge existants en insistant sur les solutions Open Source
 Choix des injecteurs et bouchons possibles en fonction des performances théoriques des outils
 Réalisation d’un benchmark des outils sélectionnés afin de sélectionner les outils appropriés dans la
configuration le plus performante
 Réalisation du prototype afin de valider les choix et s’assurer de la faisabilité du projet
Par rapport au plan de management de projet initial, j’ai jugé le maquettage inutile, une interface
graphique ne s’avérant pas nécessaire.
Détaillons maintenant chacun des points précédents.
FP1 : Stresser le logiciel IPTAX
FP2 : Gérer les tests
FC1 : Gérer l’environnement de tests
FC2 : Conserver les résultats de tests
FC3 : Permettre les Campagnes de tests
FC4 : S’adapter aux tests existants
Simulateur de tests
de charge
IPTAX
Plate-forme de
tests
Résultats de
tests
Campagnes de
tests
Fiches de tests
Utilisateur
FP1
FC3
FC1
FC2
FP2
FC4

Page 41
Evistel n’ayant pas une culture des outils de tests Open Source, il était impossible de trouver les
ressources dans l’entreprise pour m’orienter dans mes recherches. La collecte d’informations s’est donc
faite essentiellement à partir de l’internet. Les cours relatifs à la veille technologique m’ont permis d’être
plus performant dans le domaine de la recherche d’informations. J’ai principalement utilisé les outils
suivants :
 Moteurs de recherches : Exalead, Bing et bien sur Google
 Sites spécialisés dans l’open Source : http://www.opensourcetesting.org/performance.php ,
http://www.smile.fr/Livres-blancs/Culture-du-web/Guide-de-l-open-source
 Sites spécialisés dans les tests : http://www.aptest.com/resources.html ,
http://performance-testing.org/ ,
http://www.automatedtestinginstitute.com/home/index.php?option=com_alphacontent&view
=alphacontent&Itemid=114 ,
http://www.loadtestingtools.org/?opensource
 Sites pour les professionnels de l’informatique : http://pro.01net.com/editorial/402397/les-
outils-de-test-en-route-vers-lindustrialisation/
 Sites de passionnés : http://www.jayphilips.com/2010/01/07/50-open-source-performance-
testing-tools/ , http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-
server-to-use/
Parallèlement à la recherche d’information j’ai rédigé un document recensant les solutions disponibles
sur le web en matière d’outils de tests de charge dont des extraits sont donnés en annexe 6.4. Ces
différents sites m’ont permis d’obtenir des informations et de faire des recoupements entre ces
informations afin de réaliser une analyse multicritères dans le but de sélectionner les outils les plus
adaptés au projet.
Figure 13 : Analyse multicritères des outils de charge

Page 42
La méthode utilisée pour déterminer l’outil le plus performant est la Weight Sum Method qui utilise une
pondération pour chaque critère retenu. Les deux injecteurs les plus performants pour les tests de charge
massifs sont, suivant cette méthode :
 Curl-loader10
: pour les tests de montée en charge
 Tsung11
: pour les tests de charge
De même il m’a fallu trouver une solution pour le bouchon, le serveur WEB Apache étant trop lent pour
les tests de charge, je me suis orienté vers deux solutions parmi les plus performantes du moment: Nginx
et G-WAN.
Pour valider les solutions retenues j’ai réalisé un benchmark. Pour établir la plate-forme matérielle
nécessaire pour les tests je suis parti de l’architecture client/serveur de l’outil de test fonctionnel existant
que j’ai généralisé afin de satisfaire aux besoins des tests de charges comme le montre la figure suivante :
Figure 14 : architecture matérielle de la plate-forme de tests de charge
10
Voir en annexe 6.4.1 pour une présentation rapide du logiciel et le site web associé pour une présentation détaillée
11
Voir en annexe 6.4.1 pour une présentation rapide du logiciel et le site web associé pour une présentation détaillée

Page 43
Les tests retenus dans le cadre du benchmark concernent uniquement la capacité à transmettre des
fichiers de différentes tailles afin de pouvoir générer un trafic minimal. Ces tests permettent la mesure du
nombre de sockets ouverts en parallèle lors d’un téléchargement. Ils sont donnés pour informations :
 Test M1 – mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
1Ko
 Test M2 - mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
taille 10Ko
taille 50Ko
taille 100Ko
Enfin, pour les tests du prototype il a fallu trouver du matériel suffisamment puissant pour tenir la
charge. Un PC a été acheté à cet effet en début de stage, pour être utilisé comme injecteur. Le 15 mars
une station de travail, prêtée par SUN-ORACLE pour une durée d’un mois dans le cadre d’un partenariat,
est arrivée d’Allemagne pour être évaluée. Elle a notamment été utilisée pour jouer le rôle du bouchon,
permettant le début des tests de benchmark. L’installation des différents logiciels n’a posé aucun problème
et les tests ont pu démarrer rapidement.
Les résultats suivants ont été obtenus en utilisant Tsung et Nginx. En abscisse la coordonnée est le
temps exprimé en seconde alors qu’en ordonnée se trouve le nombre de sockets créés et utilisés.
Transfert d’un fichier de 10KOctets

Page 44
Transfert d’un fichier de 100Kctets

Page 45
Les fichiers de résultats montrent une réelle dégradation des performances à partir d’un fichier de taille
100ko, aussi bien en nombre de sockets ouverts que de durée du test.
Le résultat suivant a été obtenu en utilisant Tsung et G-WAN.
La comparaison avec le graphe équivalent dans la configuration précédente, en page 43, fait apparaître
deux résultats défavorables à G-WAN :
 Un nombre moyen de socket crées inferieur, en moyenne 50 000 vs 60 000
 Un nombre de socket utilisés inferieur 5000 vs 10 000
De plus, un bug trouvé au cours du benchmark obligeant l’arrêt systématique de G-WAN après un test pour
détruire des sockets encore ouvert alors qu’ils sont inutilisés, associé à son mode de distribution, gratuit
mais non Open Source, a permis à NGINX d’être retenu pour devenir le futur serveur WEB de la plate-
forme de tests.
Les résultats des tests de montée en charge avec Curl-loader ont conclu qu’il était possible d’atteindre
la limite de 60000 utilisateurs en utilisant des paliers de 7500 utilisateurs avant d’épuiser les 4Gb de
mémoire vive disponibles sur l’injecteur, 8 Montées en charge étant nécessaires pour atteindre cette
limite.
Cette étude a aussi permis le dimensionnement matériel de la plate-forme de tests. Tsung et NGINX
permettent de réaliser les tests avec une configuration réduite à 4 injecteurs (machines DELL Precision
T3500 équipées d’un processeur P6 à 2 cœurs et de 4 Go de mémoire) pour simuler la charge requise de
200 000 sockets ouvertes en moyenne. Un bouchon s’avérant suffisant (Machine SUN Fire X4170 24 cœurs
et 4 Go de mémoire).

Memoire création d'un simulateur de charge

Memoire création d'un simulateur de charge

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Memoire création d'un simulateur de charge

Ähnlich wie Memoire création d'un simulateur de charge (20)

Memoire création d'un simulateur de charge