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.

http://www.evistel.com/

http://www.cesi.fr/

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

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

http://www.verif.com/societe/EVISTEL-431563105

http://foad.refer.org/IMG/pdf/INTRODUCTION_ANALYSE_ORGANISATIONNELLE_M2.pdf


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.

http://www.intersec.com/solutions/messaging-solutions_11.php

http://www.halys.fr/fr/produits/

http://www.asiacell.com/


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

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

[email protected] 01 53 62 40 69

Philippe Verdier Ingénieur responsable du produit IPTAX

[email protected]

Omar Ait-amrane responsable R&D [email protected]

Thierry Lafue Directeur technique [email protected]

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

mailto:[email protected]





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.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.


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

http://www.opensourcetesting.org/performance.php

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.automatedtestinginstitute.com/home/index.php?option=com_alphacontent&view=alphacontent&Itemid=114

http://www.loadtestingtools.org/?opensource

http://pro.01net.com/editorial/402397/les-outils-de-test-en-route-vers-lindustrialisation/

http://pro.01net.com/editorial/402397/les-outils-de-test-en-route-vers-lindustrialisation/

http://www.jayphilips.com/2010/01/07/50-open-source-performance-testing-tools/

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/

http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/


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).


Page 46

Cette étape m’a permis de prouver la faisabilité du projet et de déterminer la configuration matérielle

et logicielle du simulateur. La suivante a consisté à intégrer les logiciels Tsung et NGINX dans l’outil de tests

fonctionnels afin d’obtenir une première version du simulateur permettant de tester le logiciel IPTAX.

Cette opération a été réalisée en trois jours permettant de débuter des tests de charge du logiciel IPTAX

avec l’ingénieur en charge de son développement.

4.2.6 Validation de la phase

La validation de la phase s’est faite en deux étapes. La première a consisté à réaliser un document au

format Powerpoint décrivant les choix réalisés et les résultats obtenus. Ce document a été transmis aux

acteurs du projet pour approbation. La seconde a consisté en une utilisation pendant quatre jours du

simulateur afin de commencer à stresser le logiciel IPTAX, permettant de voir quelques problèmes

spécifiques au logiciel, notamment des problèmes de pertes de paquets, rapidement réglés par P. Verdier

l’ingénieur en charge du développement d’IPTAX.

Intéressons-nous un instant au planning. Cette phase devait se terminer fin semaine 9. Elle a

commencé fin semaine 11 pour se terminer en fin de semaine 15. Ce décalage temporel, fréquent

dans les projets informatiques ou télécom, nécessite des capacités spécifiques au métier d’ingénieur

intégration/validation:

Être capable de travailler en avance de phase, en démarrant les tâches pouvant l’être. La

conception a donc débutée avant la validation du prototype.

Savoir gérer les délais et les priorités.

Adapter son planning en fonction des aléas ou des opportunités : Les tests du produit

IPTAX ont ainsi commencé mi-avril permettant à P. Verdier d’anticiper la résolution des

problèmes.


Page 47

4.3 La phase de conception

La phase de conception a permis de modéliser le simulateur. Durant cette phase j’ai défini son

architecture logicielle et finalisé l’architecture matérielle. Cette phase a surtout consisté en la rédaction de

documents permettant sa réalisation. L’interface homme machine a été réduite à sa plus simple

expression : une fenêtre s’ouvrant afin de visualiser l’exécution du programme.

4.3.1 Définition de l’architecture du simulateur

Cette étape a permis la rédaction du Dossier de Conception Générale. Ce document définissant

l’architecture matérielle et logicielle du simulateur utilise le langage UML. UML est un langage de

modélisation graphique à base de pictogrammes permettant la conception de système informatique. Afin

de faciliter la tâche de conception j’ai choisi d’utiliser un outil de modélisation. Mon choix s’est tourné vers

un logiciel Open source, StarUML12, permettant le développement objet sous UML. Les raisons du choix de

ce logiciel sont les suivantes :

Ce logiciel est Open Source sous licence GPL

Il supporte UML 2.0

Tous les types de diagrammes UML 2.0 sont disponibles

Le défaut principal de cet outil par rapport à MODELIO ou BOUML, est le système d’exploitation nécessaire

pour l’utiliser : Windows. Si les deux derniers outils sont multi plate-forme, LINUX et Windows, ils sont soit

restreint dans le choix de diagrammes UML dans le cas de MODELIO, soit payant dans le cas de BOUML.

12

Voir http://staruml.sourceforge.net/en/


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

http://staruml.sourceforge.net/en/


Page 48

Néanmoins, ce défaut peut être contourné en installant une machine virtuelle Windows de type QEMU13

sur un système LINUX. Le document de conception générale contient les informations suivantes :

Une définition de l'architecture générale du simulateur de charge,

Un découpage des actions à réaliser en tâches,

Un regroupement des fonctionnalités en paquetages,

Des classes modélisant les principaux objets du système,

Une définition des interfaces de communication entre les paquetages

Intéressons-nous maintenant à la conception du système proprement dite.

L'architecture matérielle du projet est une architecture distribuée (voir la figure 14) qui a été définie

durant la phase de prototypage. L'application à développer peut être répartie sur cinq types de stations en

fonction des performances des stations de travail utilisées :

L’ordinateur maître dont le rôle est de superviser les tests

Un agent de communication de type injecteur qui va générer les requêtes HTTP vers

Un agent de communication de type bouchon qui va, en réponse aux requêtes de l’injecteur,

générer du trafic de données

Le SUT qui va contenir une partie supervision permettant de valider le fonctionnement de

l’application IPTAX.

Les sondes permettant des mesures de performances

De plus l’injecteur et le bouchon peuvent être situés sur plusieurs machines différentes pour générer la

charge appropriée. Le schéma suivant résume l’architecture choisie pour réaliser la plate-forme et définit

l’architecture fonctionnelle du simulateur.

13

Voir http://en.wikibooks.org/wiki/QEMU/Windows_XP

http://en.wikibooks.org/wiki/QEMU/Windows_XP


Page 49

Figure 15 : architecture fonctionnelle du simulateur

Les différents modules sont : Des logiciels comme Tsung ou Nginx permettant de gérer le trafic Des scripts lancés par l’ordinateur maître pour superviser le SUT lors du tests Des programmes optionnels démarrés pour réaliser des mesures ou superviser le réseau

Les fonctionnalités sont regroupées selon des «paquetages de gestion» qui ont des interfaces de communications entre eux. L'architecture comprend :

Le paquetage de gestion des tests de charge: ce bloc comprend l'interface utilisateur. Il a une interface avec le paquetage de gestion du trafic et le paquetage de gestion de supervision des mesures.

Le paquetage de gestion du trafic qui a une interface de communication avec le paquetage de génération du trafic sur l’injecteur et du trafic sur le bouchon.

Le paquetage de supervision des mesures : partie du système chargée d'analyser le trafic et le comportement de l’application testée. Le gestionnaire d'analyse du trafic, optionnelle, est une application observatrice du trafic et doit être installée sur une station externe dans un souci de percevoir tous les messages. Le SUT est supervisé par différents paquetages : système qui s’occupe de l’OS, applicatif qui s’occupe du logiciel IPTAX et réseau qui mesure les performances réseau du SUT.

Le Paquetage de gestion des résultats de tests : les méthodes de sauvegarde des résultats des tests ainsi que les méthodes de traitement des résultats a posteriori y sont définies.

Le paquetage de service générique fourni les objets et services de base à l’application


Page 50

L’architecture logicielle est très simple. Le simulateur est composé de quatre programmes perl ayant

les rôles suivants :

MakeAliases : programme permettant d’initialiser l’environnement de tests CheckPlatformConfig : programme permettant de vérifier l’état des principaux agents et services

constituant la plate-forme. RunLoadTests : programme permettant de

o générer du trafic sur le réseau afin de tester le logiciel IPTAX o démarrer la supervision du SUT et des agents remontant des informations utile au test o sauvegarder les résultats de tests

ConfigurePlatformConfig : programme permettant de mettre à jour la configuration de la plate-forme. Ce programme aura un GUI permettant de mettre à jour facilement l’ensemble des fichiers de configuration de la plate-forme.

Ces quatre programmes sont indépendants et peuvent être utilisé en mode commande à partir d’un shell

LINUX. L’application ConfigurePlatformConfig avec une GUI sera développée en fin de projet pour

compléter ces programmes si nécessaire.

4.3.2 Rédaction du plan de tests du simulateur

Cette étape de rédaction des documents de conceptions s’est poursuivie par la rédaction du plan de

test du simulateur qui m’a permis de définir les procédure d’intégration et validation du logiciel. Le logiciel

développé étant relativement simple j’ai choisi de fusionner les tests d’intégration et validation en un

unique document. Ce plan de test, court, comporte trois parties :

Des tests de documentation : Afin de vérifier la livraison de tous les livrables attendus

Des tests d’installation : Pour vérifier la capacité à installer le simulateur sur une autre machine

Des tests fonctionnels : Afin de vérifier la capacité à réaliser un test de charge

Ces trois parties permettent de valider le déploiement du logiciel à chaque livraison. La phase s’est ensuite

achevée par la conception détaillée permettant de préciser certains points de conception nécessitant

d’être approfondie.

4.3.3 Rédaction des spécifications fonctionnelles détaillées

Cette étape, prolongement naturel de l’étape de conception générale, s’est traduite par la rédaction

d’un nouveau document : le dossier de conception détaillée.

Pour réaliser cette partie j’ai utilisé StarUML afin de détailler, pour chacune des classes définies dans le

DCG, leurs attributs et méthodes. Ainsi la modélisation de l’outil de tests de charge donne les trois

résultats principaux suivants.

La plate-forme de test est constituée des objets suivants :

o Un ou plusieurs injecteurs, objet Send, qui envoient les messages

o Un ou plusieurs bouchons, objet Resp, qui répondent à l’injecteur

o Un SUT, qui modélise la configuration testée

o Des sondes optionnelles, objet Probe, qui réalisent des mesures

o Un serveur Radius qui donne les autorisations et identifie les accès au réseau internet

o Une base de données des utilisateurs référencés sur le réseau, objet UserMsIsdnDataBase


Page 51

Figure 16 : Modélisation de la plate-forme de tests

Un test est composé des objets suivants :

o D’un scenario de tests : utilisant les outils TSUNG ou CURL-loader il décrit le test à réaliser.

o D’une plate-forme de test qui décrit la plate-forme utilisée

o D’un objet résultat de test, optionnel, permettant de générer les résultats du test et de les

stocker.

Le schéma ci-dessous résume ce modèle :


Page 52

Figure 17 : Un test de charge modélisé

Enfin les éléments de la plate-forme sont issus d’un objet générique modélisant un élément d’un

réseau :

Figure 18 : Objets génériques de l’application


Page 53

Les diagrammes de classes précédents montrent la structure interne du programme. Ils permettent de

fournir une représentation abstraite des objets du système qui vont interagir ensemble lors de l’exécution

du programme. Le diagramme d’états-transitions suivant décrit le comportement interne des objets à

l’aide d’un automate à états finis. Il présente les séquences possibles d’états et d’actions que le

programme peut traiter au cours de son cycle de vie en réaction à des événements discrets (de type

signaux, invocations de méthode).

Figure 19 : Diagramme d’état du programme

Cette étape m’a permis de définir les objets constituant le simulateur ainsi que son comportement. J’ai

réalisé une conception suffisamment détaillée pour commencer le développement. Malheureusement, je

n’ai pu utiliser une des fonctionnalités majeures de ce genre d’outil, la génération de squelette de code, le

langage de développement choisi, Perl, n’étant pas supporté par cet outil. Il a fallu donc fallu coder le

logiciel en intégrant certaines parties du prototype.

4.3.4 Validation de la phase

La validation de la phase a consisté à soumettre les documents générés pour approbation afin de

démarrer le codage, la présentation technique ayant été livré dès la fin du benchmark.


Page 54

4.4 La réalisation du simulateur

La réalisation d’un logiciel consiste principalement à l’écrire et à le tester afin de s’assurer de son bon

fonctionnement. La documentation permet à l’utilisateur de prendre en main le logiciel. Cette phase se

conclut par la recette, qui entraîne le passage en production : la vie du logiciel débute alors réellement.

4.4.1 Développement

Le début du développement s’est effectué alors que le travail de rédaction des spécifications détaillées

se terminait, afin d’affiner le modèle lors d’une période de recouvrement. L’écriture des programmes en

perl s’est fait directement sur la machine de tests, des backups étant réalisés périodiquement sur mon

ordinateur afin d’assurer la sauvegarde des programmes générés. L’utilisation de CVS sur la machine de

développement afin de pouvoir gérer les évolutions du simulateur, s’est avérée inutile, le logiciel n’étant

pas supposée être livré et donc n’ayant pas besoin de se voir attribué une version. De la documentation en

ligne utilisant le format PERLPOD a été généré dans le code afin d’aider à son utilisation ultérieure.

4.4.2 Passage des tests

Des tests unitaires ont été réalisés durant la phase de développement afin de s’assurer du bon

fonctionnement du code généré, notamment pour les objets génériques.

4.4.3 Réalisation de la documentation

La documentation comporte trois livrables principaux : un manuel utilisateur, un FAQ et HowTo

J’ai tout d’abord rédigé un manuel utilisateur afin de permettre l’utilisation du simulateur par les

ingénieurs. Ce court document à l’usage des débutants décrit comment utiliser le simulateur.


3-Réalisation

3.1 Développement

3.2 Tests 3.3

Documentation

3.3.1 Rédaction du manuel utilisateur

3.3.2 Rédaction faq

3.3.3 Rédaction HowTo

3.4 Recette


Page 55

La rédaction d’un document de type Frequently Asked Question a permis de regrouper les réponses

aux questions les plus souvent posés. Ce type de document fréquent sur internet, permet de répondre aux

questions usuelles posées par les utilisateurs ayant plus d’exprience dans l’utilisation d’un logiciel.

Enfin la rédaction d’un HowTo a permis de regrouper des informations diverses et utiles à l’usage des

utilisateurs : Ce livre de cuisine, contient quelques trucs et astuces sur l’utilisation du simulateur.

4.4.4 Recette

En fin de phase le plan de tests généré en 4.3.2 a permis de valider la livraison des principaux éléments

du simulateur, permettant ainsi sa recette. La recette a permis de décider la mise en production du logiciel,

dans notre cas son utilisation pour des campagnes de tests comme dans la figure ci-dessous où le logiciel

est utilisé pour un test d’endurance d’une semaine.

Figure 20 : Le simulateur LoadTT en action


Page 56

4.5 La mise en œuvre

La mise en œuvre est une phase d’installation du simulateur sur un autre environnement de test afin

d’avoir deux plates-formes pour exécuter des campagnes de tests en parallèle suivi d’une période de

formation afin de permettre aux ingénieurs d’utiliser l’outil.

4.5.1 Déploiement

Cette phase qui aurait dû être très courte a été supprimée car il n’y avait pas d’ordinateur disponible à

sa réalisation. J’utiliserai donc la plate-forme de développement pour réaliser les sessions de formation et

les tests à venir.

4.5.2 Formation des ingénieurs à l’outil

Cette étape sera réalisée en une heure et complétée par une aide au quotidien des ingénieurs en

charge des tests. Une session de formation doit être réalisée avant la fin du stage afin de transférer les

compétences aux ingénieurs d’Evistel.

4.5.3 Le bilan provisoire du projet

Le logiciel permet de réaliser des tests de performances et d’endurance conformément aux besoins

initiaux. Il peut aussi être dimensionné en fonction des besoins permettant de générer une charge variable

en fonction de la configuration vendue au client. Enfin il est simple à utiliser, permettant une prise en main

rapide.

La configuration matérielle et logicielle minimale requise pour la réalisation des tests de charge et

d’endurance est la suivante :


4- Mise en œuvre

4.1 Déploiement 4.2 Formations des ingénieurs à l’outil

4.2.1 Création d’un document de

formation

4.2.2 Session de formation

4.3 Bilan projet


Page 57

Figure 21 : LOADTT la configuration minimale requise pour effectuer les tests de charge

Le coût théorique du projet est détaillé dans le tableau ci-dessous :

Matériel Prix unitaire TTC

Nombre Durée Prix total

Commentaires

Ordinateurs DELL 897 € 5 4485

Logiciels 0 € 4 0

Main d’oeuvre

Ingénieurs Intégration en charge du développement

600€ 1 95 57000 Ce coût est celui d’une ressource chez Evistel. Il inclut les frais fixes.

Aide extérieure 600€ 1 4 2400

Total 63885€

Tableau 6 : Le coût du projet LOADTT

Ce coût est celui du développement du simulateur. Il n’inclut pas le coût de passage des tests.

L’aide extérieure a été évaluée à 4 jours sur la durée du stage.

Les 95 jours de développement incluent 89 jours de développement réalisés au 23/06/12 et 6 jours de

maintenance à réaliser d’ici la fin du projet.


Page 58

4.6 Exploitation et Maintenance

La phase d’exploitation et maintenance consiste principalement à réaliser de l’assistance aux

utilisateurs et à la participation à des campagnes de tests.

4.6.1 Exploitation, Assistance et Maintenance corrective et évolutive

Cette étape est en cours à l’heure actuelle.

Des améliorations peuvent notamment être envisagées dans les domaines suivants :

Surveillance de l’application via une MIB : des données pourraient être collectées afin de

générer des statistiques plus fines sur les tests réalisés

Évolution vers un Système d’exploitation 64 bits afin de pouvoir gérer une taille de RAM

supérieure à 4Mo. La création de 200 000 adresses IP entraîne l’utilisation de 400Mo de

RAM et limite donc la taille de la mémoire vive utilisable à 3 Go, ce qui est pénalisant pour

les tests de charge où la RAM est une ressource critique. Les systèmes 32 bits étant limités

à 4Go (=232 octets) de mémoire, l’utilisation d’un SE 64 bits permettrait de gérer plus de

mémoire et d’utiliser moins de machines.

4.6.2 Participation aux campagnes de tests

Cette phase est la plus importante pour le management puisqu’elle permet de mesurer les

performances et la stabilité du logiciel. J’ai commencé par rédiger un plan de tests permettant de valider

les principaux tests à réaliser. Ces tests peuvent être divisés en plusieurs catégories :

Tests de montée en charge : Simuler un nombre croissant d’utilisateurs pour déterminer les

limites


5-Exploitation

5.1 Assistance

5.2 Maintenance corrective et évolutive

5.3 Participation aux campagnes de tests


Page 59

Tests de charge : Simuler un nombre prédéfini d’utilisateurs pour valider le comportement de

l’application (temps de réponse, utilisation des ressources, remontée des informations)

Test de stress : Tester le comportement du logiciel au-delà des limites

Test d’endurance : Tester le comportement de l’application dans le temps

Tests aux limites : Déterminer que le logiciel atteint les limites définis dans le cahier des charges

Ce plan de tests a été validé par les ingénieurs en charge du développement et ceux en charge de

l’avant-vente, qui souhaitaient obtenir des informations sur les performances d’IPTAX.

Des fiches de tests ont été rédigées pour permettre le passage des tests et une feuille Excel créée

pour synthétiser les résultats obtenus14.

J’utilise notamment le simulateur pour tester la version 1.46 d’IPTAX, version qui corrige certains

problèmes liés à la performance du logiciel. Je détaillerai cette phase lors de la soutenance de fin de stage

en insistant sur les possibles améliorations du processus de tests dans sa globalité.

Plusieurs problèmes de stabilité ont été trouvés durant les deux semaines de tests réalisées entre le

21/05/12 et le 01/06/12 (principalement des tests d’endurance) conduisant à des livraisons de correctifs

afin de les résoudre. Parmi ceux-ci on notera :

L’utilisation d’une nouvelle librairie GctLoad en version 32 bit

Un nouveau paramétrage de la pile de protocole TCP/IP afin d’absorber la charge

14

Une fiche de test et une feuille Excel type sont données en annexe 6.6 et 6.7

L’outil développé a déjà permis de trouver plusieurs problèmes, démontrant ainsi son efficacité. Sa

souplesse lui permet de s’adapter aux ressources disponibles pour le passage des tests.

Le plan de tests créé pour tester IPTAX contient des tests couvrant tout le périmètre des tests de

charge permettant ainsi de valider les performances globales d’IPTAX.


Page 60

5. Conclusion En tout premier lieu ce stage m'a permis de renouer avec le secteur de l'informatique et des télécoms

après quatorze mois passés à l'Ei.CESI sur le site de Nanterre. Les débuts ont été difficiles, car il a fallu que

je me réapproprie certaines connaissances propres au secteur de l'informatique, moins utilisées pendant

plusieurs mois passés à acquérir de nouvelles compétences. Ensuite ce stage m'a permis de mettre en

application une partie de ces nouvelles compétences. Ce sont principalement celles relatives à la gestion

de projet, pour le mener à bien, de résolution de problème afin de trouver des solutions aux problèmes

rencontrés et la veille technologique afin de trouver les informations nécessaires à la réalisation du

simulateur.

J’avais choisi une PME éditrice de logiciels afin de découvrir une autre structure organisationnelle,

différente de celles des multinationales du secteur Hi-Tech que j’avais connu avant d’entamer ma

formation au CESI. Les moyens financiers limités des petites sociétés entraînent des choix différents en

matière de gestion de l’entreprise, par exemple en privilégiant le développement d’outils basé sur les

logiciels libres à l’achat de solution standard du marché. Cela m’a permis de découvrir de nouveaux outils

de tests et d’obtenir des informations sur les prix des différentes solutions, complétant mes connaissances,

jusque-là purement technique. Mais le manque de moyens entraîne aussi des tests limités en temps et en

nombre. Il faut alors sélectionner les tests à réaliser précisément pour répondre aux besoins des clients.

Un travail en équipe permet de définir précisément ces besoins et de les valider.

Ce stage me sera utile pour la suite de ma carrière. Il m’a permis de valider un niveau ingénieur

d’intégration-validation, poste vers lequel je souhaite m’orienter lors du retour dans mon entreprise HP.

D’un point de vue personnel, il m’a apporté une certitude la gestion de projet m’intéresse maintenant

beaucoup plus que la technique. Je chercherai à l’avenir des postes à fonction élargie ou la gestion de

projet tient une part importante.


Page 61

6. Annexes

6.1 Références [1] Alcatel - http://www.alcatel-lucent.com/aboutus/companyoverview_fr.html (Dernière consultation le

14/04/12)

[2] Nokia-Siemens - http://www.nokia.com/global/about-nokia/investors/financials/reports/results---

reports/ (Dernière consultation le 14/04/12)

[3] Huawei - http://fr.wikipedia.org/wiki/Huawei_Technologies (Dernière consultation le 14/04/12)

[4] Cours d’analyse et conception des systèmes d’information, Olivier Guibert -

www.labri.fr/perso/guibert/DocumentsEnseignement/ACSI_v2.pdf (Dernière consultation le 14/04/12)

[5] Quelles sont les causes d’échec des projets informatiques? - http://www.portail-

management.ch/praxistipp_view.cfm?nr=3291 (Dernière consultation le 14/04/12)

http://www.alcatel-lucent.com/aboutus/companyoverview_fr.html

http://www.nokia.com/global/about-nokia/investors/financials/reports/results---reports/

http://www.nokia.com/global/about-nokia/investors/financials/reports/results---reports/

http://fr.wikipedia.org/wiki/Huawei_Technologies

http://www.labri.fr/perso/guibert/DocumentsEnseignement/ACSI_v2.pdf

http://www.portail-management.ch/praxistipp_view.cfm?nr=3291

http://www.portail-management.ch/praxistipp_view.cfm?nr=3291


Page 62

6.2 Planning détaillé


Page 63

6.3 Fiches de lot de travaux

Réalisation d’un simulateur de charge pour le produit IPTAX

Identifiant de fiche : FDL_01 Date de mise à jour : 12/02/12

Intitulé de la fiche de lot : Initialisation du projet

Responsable : Gilles Lefebvre Phase du projet : Management de projet

Objectifs : Initier le projet

Description de la fiche de lot : Ce lot consiste à rédiger les principaux documents projet permettant son démarrage.

Éléments d’entrées (Documents, Matériels, Informations, …) : Description orale du projet

Éléments de sorties/Livrables : Note de clarification, Plan de management projet, Planning

Durée de la tâche : 6J (4J réels) Date de Début : 24/01/12 Date de fin : 31/01/12

Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Suite bureautique (MS Office / Open Office)

Risques liés à la tâche : Perfectionnisme, Mauvaise compréhension du problème

Commentaires : La tâche de rédaction du PMP se fait en parallèle avec la phase recueil des besoins et nécessite un effort à hauteur de 70 % du temps

Visa / date : 15/02/12

Chef de Projet Responsable de lot Responsable de service

Gilles Lefebvre Gilles Lefebvre Omar ait-amrane


Page 64



Intitulé de la fiche de lot : Etude de la faisabilité technique du simulateur

Responsable : Gilles Lefebvre Phase du projet : Étude préalable

Objectifs : Prouver la faisabilité théorique et pratique du simulateur. Définir différentes approches du problème. Choisir une solution adaptée au problème

Description de la fiche de lot : Ce lot consiste à rédiger le CDC puis à l’exploiter pour réaliser un prototype et une maquette de l’Interface Homme-Machine.

Éléments d’entrées (Documents, Matériels, Informations, …) : Description orale du projet, PMP

Éléments de sorties/Livrables : Cahier des charges, Prototype, Maquette de l’IHM, Étude comparative des outils de charge du marché

Durée de la tâche : 29J Date de Début : 24/01/12 Date de fin : 02/03/12

Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Outils de développement open source, Système d’exploitation Linux

Risques liés à la tâche : Perfectionnisme, Mauvaise compréhension du problème

Commentaires : L’environnement de développement est laissé au libre choix du développeur en charge du prototype et de la maquette tant que des logiciels open source sont utilisés. La cible est une machine Linux.

Visa / date : 15/02/12




Page 65



Intitulé de la fiche de lot : Réalisation du simulateur

Responsable : Gilles Lefebvre Phases du projet : Conception / Réalisation

Objectifs : Implémenter le simulateur.

Description de la fiche de lot : Ce lot consiste à réaliser les études techniques du simulateur puis de le réaliser.

Éléments d’entrées (Documents, Matériels, Informations, …) : Cahier des charges, prototype, maquette de l’IHM

Éléments de sorties/Livrables : Document d’architecture, Présentation technique du simulateur, Simulateur, Manuel utilisateur

Durée de la tâche : 45J Date de Début : 05/03/12 Date de fin : 09/05/12

Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Outils de développement open source, Système d’exploitation Linux

Risques liés à la tâche : Cahier des charges fonctionnel du simulateur de charge mal défini, Ajout de spécifications durant le projet, Simulateur inadapté aux besoins de la MOA, Complexité du problème mal estimée entraînant un dépassement des délais

Commentaires : Une recette valide cette phase permettant le déploiement du simulateur sur les plateformes de tests et son utilisation pour réaliser les tests de performances du logiciel IPTAX. Des documents de type faq et HowTo devront être livrés si nécessaires. La décision sera prise au moment de la recette et pourra reculer la signature du PV de recette.

Visa / date : 15/02/12




Page 66



Intitulé de la fiche de lot : Déploiement et maintenance du simulateur

Responsable : Gilles Lefebvre Phases du projet : Mise en Œuvre, Exploitation et maintenance

Objectifs : Formation, Support aux utilisateurs, Maintenance corrective et évolutive

Description de la fiche de lot : Ce lot est une prestation de support technique auprès des utilisateurs

Éléments d’entrées (Documents, Matériels, Informations, …) : Simulateurs, Plate formes de tests, Logiciel IPTAX

Éléments de sorties/Livrables : Présentation powerpoint du simulateur, Session de formation, Liste des anomalies résiduelles, Résultats des campagnes de tests

Durée de la tâche : 35 Date de Début : 10/05/12 Date de fin : 29/06/12

Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Simulateur, Plate-forme de tests, Logiciel IPTAX

Risques liés à la tâche : Disponibilité réduite des ressources matérielles car limitées en nombre et partagées entre les différentes équipes. exemple : plate-forme de tests.

Commentaires : Cette partie inclura la réalisation de campagnes de tests afin de mesurer les performances du logiciel IPTAX. La phase de maintenance se terminera le 22/06/12 afin de rédiger un document des anomalies résiduelles du simulateur et transmettre le simulateur à l’équipe d’intégration.

Visa / date : 15/02/12




Page 67

6.4 Les solutions Open sources étudiées Cette annexe est un extrait du document de synthèse relatif à l’étude des solutions Open Source

6.4.1 Les solutions logicielles

Les solutions logicielles ont pour principales caractéristiques de nécessiter à la fois un injecteur pour

simuler la charge et un outil complémentaire pour simuler les réponses aux requêtes générées par

l’injecteur de charge : le bouchon. L’étude des outils permettant ces réponses n’entre pas dans la cadre de

cette étude mais peuvent influencer les choix des injecteurs en fonction de critères fonctionnels ou de

performances. Les outils Open Source sont étudiés dans la première partie de cette section, la seconde

partie traitant des solutions commerciales.

6.4.1.1 Open Source

Les solutions étudiées sont toutes les dernières solutions stables livrées par les auteurs du logiciel.

6.4.1.1.1 Siege

Siege

Version étudiée : 2.70 (stable)

Site Internet de la solution : http://www.joedog.org/siege-home/

l’application est supportée par Jeff Fulmer

Siege permet de faire des tests de montée en charge en simulant un grand nombre de connexions simultanées sur une ou plusieurs URLs données. Le logiciel supporte les protocoles HTTP et HTTPS 1.0 et 1.1, les méthodes GET & POST, les cookies et l’authentification basique. L’affichage ne se fait pas en temps réels lors du passage des tests comme avec les solutions matériels de Spirent ou Ixia mais le programme indique en sortie le nombre total de hits enregistrés, de bytes transférés, le temps de réponse, les accès concurrents et le statut du serveur. Des statistiques minimalistes sont disponibles à la fin du test : Transactions, Elapsed time( secs), Data transferred (bytes), Response time(secs), Transaction rate(trans/sec), Throughput(bytes/sec), Status code 200, Successful transactions, Failed transactions

http://www.joedog.org/siege-home/


Page 68

6.4.1.1.2 Jmeter

Jmeter


Site Internet de la solution : http://jmeter.apache.org/

l’application est supportée par la fondation apache

Jmeter est un outil d'injection de trafic édité par la fondation Apache. Il est utilisé pour réaliser des tests de charge sur plusieurs types de serveurs : Web, LDAP, Bases de données, etc… JMeter est distribuée sous licence Apache. Il est réalisé en Java. Son développement a commencé en 2001. Il dispose d'une interface graphique, ce qui rend la création de scenarios d'utilisation plus facile. Les scénarios en eux-mêmes peuvent être d'une grande complexité, avec des boucles, conditions, extraction et réutilisation de variables, chargement de variables depuis un fichier externe, et de nombreux types de graphes et de statistiques. À la fin de tests des logs sont générés qui doivent être analysée avec l’outil « Graph Results » ou à l’aide de plugin à installer comme StatAggVisualizer.zip . Enfin, des outils extérieurs peuvent être utilisés comme dans l’exemple suivant : http://blog.zenika.com/index.php?post/2009/09/16/Analyser-vos-donn%C3%A9es-JMeter-lors-de-stress-tests Une synthèse est accessible à http://www.methodsandtools.com/tools/tools.php?jmeter

6.4.1.1.3 Tsung

Tsung

Version étudiée : 1.4.2 (stable)

Site Internet de la solution : http://tsung.erlang-projects.org/

l’application est supportée par une communauté : https://lists.process-one.net/mailman/listinfo/tsung-users

Tsung est un outil d'injection de trafic, utilisé pour les tests de charge de différents types de serveurs. Initialement crée par la société française Idealx, en 2006, il est désormais développé par une communauté indépendante. Le produit évolue régulièrement grâce à une communauté active. Il est disponible sous licence GPL. Il supporte HTTP(S) et quelques dérivés (SOAP, WebDAV), les bases MySQL et PostgreSQL, ainsi que XMPP. Réalisé en ERLANG, un langage spécialisé dans les applications hautes performances, il ne souffre pas des limites traditionnelles de ce type d'outils, et peut donc simuler un trafic très important. Les scénarios sont écrits en XML. De nombreux exemples ainsi qu’une documentation importante existent sur le site. Il ne propose pas de statistique en temps réel durant l’exécution du test, mais dispose d'un générateur automatique de statistiques permettant d’obtenir des graphes à son terme.

http://jmeter.apache.org/

http://rubenlaguna.com/wp/wp-content/uploads/2007/01/stataggvisualizer.zip

http://blog.zenika.com/index.php?post/2009/09/16/Analyser-vos-donn%C3%A9es-JMeter-lors-de-stress-tests

http://blog.zenika.com/index.php?post/2009/09/16/Analyser-vos-donn%C3%A9es-JMeter-lors-de-stress-tests

http://www.methodsandtools.com/tools/tools.php?jmeter

http://tsung.erlang-projects.org/

https://lists.process-one.net/mailman/listinfo/tsung-users

https://lists.process-one.net/mailman/listinfo/tsung-users


Page 69

6.4.1.1.4 Curl-loader

Curl-loader


Site Internet de la solution : http://curl-loader.sourceforge.net/

l’application est supportée par Robert Iakobashvili et Michael Moser

Curl-loader (également connu sous le nom "omes-nik" et "davilka") est un outil open-source écrit en langage C, qui permet de tester une application en charge en simulant le comportement de dizaines de milliers de clients HTTP/HTTPS et FTP/FTPS chacun ayant sa propre adresse IP. Contrairement à d'autres outils curl-loader utilise des piles de protocoles écrites en C, à savoir, les piles HTTP et FTP de libcurl et TLS/SSL de openssl, et supporte les connexions et authentification des utilisateurs. Cet outil permet principalement des tests de montée en charge. L'objectif du projet est d'offrir une solution de test open-source puissante et flexible qui soit une réelle alternative aux produits Spirent Avalanche et IXIA IxLoad. L’application est supportée par deux programmeurs indépendants. Curl-loader est distribuée sous License GPL v2

6.4.1.1.5 Conclusion

Les solutions Tsung pour générer de la charge et Curl-loader pour générer des tests de montée en

charge sont les solutions open source les plus performantes, les deux autres solutions ont l’avantage de la

simplicité mais sont limités au niveau de la charge. Elles peuvent être utiles pour générer du trafic.

http://curl-loader.sourceforge.net/


Page 70

6.5 Les solutions matérielles


Page 71

6.6 Un exemple de fiche de tests


Page 72


Page 73

6.7 Modèle de fichier de synthèse d’une campagne de test

IPTAX PERFORMANCE TEST REPORT

IPTAX Performance test Results

CLIENT : Movistar ORIGINATOR : INTEGRATION & SUPPORT

PLATFORM: TESTER : Gilles Lefebvre

SOFTWARE: 1-46 DATE :

Approvals Function IPTAX Validation Manager

Name

TEST CAMPAIGN SUMMARY Number of Test

total

Numb. of Test performed Number of

Test OK

Number of

Test NOK

Number of Test

POK

Compliance

%(Nb test OK /Nb test

performed)

0 0 0 0 0 not started

LIST OF PROBLEMS

Problem reference System impacted Gravity Problem description

CLIENT

Reference

Evistel reference (IPTAX or NETWORK) (G0 > G4)

IPTAX G3


Page 74

TEST CAMPAIGN DETAILED RESULTS

Priority P0=Urgent

P1=Normal

P2=BckGrd

NIS=NotInScope

Result OK=Pass,

NOK=Fail (G0,G1,G2),

POK=Fail (G3,G4),

INC=Inconclusive, NP=Not Performed,NA=Not applicable

Section Test Title Priority Result Comments

Test type 1 Scalability tests

1.1 PT1-MC1 : Simulate 200 000 mobile users - Increase of 7500 users between two thresholds

P0 NP

Test type 2 Load tests

2.1 PT2-C1 : Check the performances deterioration is regular (no sharp changes in

performances) when packet size increases. P0 NP

2.2 PT8-C2 : Simulate 40000 mobile users performing HTTP and HTTPS connections P0 NP

2.3 PT9-C3 : Check the ability to filter IP addresses during a load tests P0 NP

Test type 3 Soak tests

3.1 PT3-E1 : Simulate a background activity of 10000 users during 7 days. P0 NP

Test type 4 Stress tests

4.1 PT4-S1 : Burst test to simulate a peak activity type end of year 25/12-26/12 or 31/12-01/01 around midnight (11h30 - 12h30)

P0 NP

Test type 5 Limit tests

5.1 PT5-L1 : Check the maximum number of radius connections opened P0 NP

5.2 PT6-L2 : Check the ability to open new radius sessions as long as IPTAX limits are not reached and while opened sessions are used to send HTTP packets

P0 NP

5.3 PT7-L3 : Check the maximal number HTTPS opened connections P0 NP

memoire création d'un simulateur de charge

Technology