SlideShare une entreprise Scribd logo
TABLE DES MATIÈRES
Liste des figures .................................................................................................................................................................... i
Liste des tableaux.................................................................................................................................................................ii
Introduction Générale .......................................................................................................................................................... 1
Chapitre 1 Présentation du cadre de travail et du sujet....................................................................................................... 2
Introduction.......................................................................................................................................................................... 3
1 Cadre du projet........................................................................................................................................................... 3
1.1 Présentation de l’entreprise............................................................................................................................... 3
1.2 Rôle de la Division Supervision ....................................................................................................................... 4
1.3 Le concept « Incident »..................................................................................................................................... 5
2 Présentation de sujet :................................................................................................................................................. 6
3 Conduite du projet...................................................................................................................................................... 6
3.1 Processus de développement............................................................................................................................. 6
3.2 Méthodologie Agile.......................................................................................................................................... 7
3.3 Scrum................................................................................................................................................................ 8
Conclusion ......................................................................................................................................................................... 13
Chapitre 2 Etat de l'Art des Réseaux Cellulaires............................................................................................................... 14
Introduction........................................................................................................................................................................ 15
1 Concept Cellulaire.................................................................................................................................................... 15
2 Evolution des réseaux cellulaires.............................................................................................................................. 16
2.1 Norme GSM ................................................................................................................................................... 16
2.2 Le standard GPRS........................................................................................................................................... 19
2.3 Téléphonie à mode paquet à haut débit : UMTS............................................................................................. 21
2.4 HSPDA........................................................................................................................................................... 23
2.5 HSUPA........................................................................................................................................................... 23
3 Concept de la qualité de service ............................................................................................................................... 23
3.1 Définition........................................................................................................................................................ 23
3.2 Critères de performances des réseaux 2G/3G ................................................................................................. 23
Conclusion ......................................................................................................................................................................... 25
Chapitre 3 Analyse des Besoins et Spécifications .............................................................................................................. 26
Introduction........................................................................................................................................................................ 27
1 Objectifs ................................................................................................................................................................... 27
2 Spécification des exigences...................................................................................................................................... 27
2.1 Les acteurs système ........................................................................................................................................ 27
2.2 Le Backlog du produit :.................................................................................................................................. 28
2.3 Diagramme des cas d’utilisation globale : ...................................................................................................... 29
2.4 Sprint .............................................................................................................................................................. 29
2.5 Besoins Non Fonctionnels .............................................................................................................................. 39
Conclusion ......................................................................................................................................................................... 39
Chapitre 4 Conception....................................................................................................................................................... 40
Introduction........................................................................................................................................................................ 41
3 Architecture du système : Modèle multi couches ..................................................................................................... 41
4 Conception ............................................................................................................................................................... 42
4.1 Conception détaillé......................................................................................................................................... 42
4.2 Sprint 1 ........................................................................................................................................................... 42
4.3 Sprint 2 ........................................................................................................................................................... 44
4.4 Sprint 3 ........................................................................................................................................................... 46
4.5 Sprint 4 ........................................................................................................................................................... 49
4.6 Diagramme de classes..................................................................................................................................... 50
Conclusion ......................................................................................................................................................................... 51
Chapitre 5 Réalisation ....................................................................................................................................................... 52
Introduction........................................................................................................................................................................ 53
1 Environnement de travail ......................................................................................................................................... 53
1.1 Environnement matériel.................................................................................................................................. 53
1.2 Environnement logiciel................................................................................................................................... 53
2 Choix techniques...................................................................................................................................................... 53
2.1 Choix du standard de développement ............................................................................................................. 53
2.2 Choix du Framework pour la couche de présentation..................................................................................... 54
2.3 EJB3.1 ............................................................................................................................................................ 55
2.4 Choix du conteneur de la couche de persistance de données .......................................................................... 56
2.5 Choix du SGBD MySQL................................................................................................................................ 57
2.6 Choix du serveur d’application JBOSS AS 7.1 : ............................................................................................ 57
3 Phase d’implémentation ........................................................................................................................................... 57
3.1 Géolocalisation site 2G................................................................................................................................... 58
3.2 Géolocalisation site 3G................................................................................................................................... 58
3.3 Géolocalisation des Site HS............................................................................................................................ 60
3.4 Affichage des sites en voisinage d’un site HS ............................................................................................... 61
3.5 Test ................................................................................................................................................................. 62
4 Chronogramme de réalisation................................................................................................................................... 62
Conclusion ......................................................................................................................................................................... 62
Conclusion et Perspective ................................................................................................................................................. 63
Bibliographie...................................................................................................................................................................... 64
Acronymes......................................................................................................................................................................... 65
Annexe A : JBOSS AS 7.................................................................................................................................................... 67
Annexe B : La technologie AJAX...................................................................................................................................... 69
i
Liste des figures
Figure 1 : Organisation de la division Supervision au sein de TUNISIANA .................................................... 4
Figure 2:Types d’incidents BTS........................................................................................................................ 6
Figure 3: Méthodologie Agile ........................................................................................................................... 8
Figure 4:Sprint Scrum ....................................................................................................................................... 9
Figure 5 : Processus Scrum ............................................................................................................................. 13
Figure 6 Concept cellulaire ............................................................................................................................. 15
Figure 7 Le Sous-système Radio..................................................................................................................... 16
Figure 8:Le Sous-système d'Acheminement ................................................................................................... 17
Figure 9 : Le Sous-système d'Exploitation et de Maintenance........................................................................ 18
Figure 10 : Architecture du Réseau GPRS ...................................................................................................... 20
Figure 11 : Architecture de l'UMTS................................................................................................................ 21
Figure 12 : UTRAN......................................................................................................................................... 22
Figure 13: diagramme cas d'utilisation globale ............................................................................................... 29
Figure 14 : Diagramme cas d'utilisation traitement des fichiers...................................................................... 31
Figure 15 : Cas d'utlisation de sprint 2 ............................................................................................................ 33
Figure 16 : Cas d'utilisation Déterminer les sites HS ...................................................................................... 35
Figure 17 Afficher Availibility 2G RAN......................................................................................................... 35
Figure 18 Gestion BTS.................................................................................................................................... 37
Figure 19 Cas d'utilisations Afficher cellules................................................................................................. 38
Figure 20 : Cas d'utilisations Gestion Utilisateur ............................................................................................ 38
Figure 21 modèle MVC................................................................................................................................... 41
Figure 22 : Diagramme séquence objet authentification ................................................................................. 43
Figure 23 : Diagramme de séquence de user story traitement des fichiersde données BTS........................... 43
Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS ................................................ 44
Figure 25 : Diagramme séquence objet Map 2G............................................................................................. 45
Figure 26: Diagramme d'activité « Géolocalisation des sites BTS »............................................................... 46
Figure 27 : Diagramme séquence géolocalisation des incidents ..................................................................... 47
Figure 28 : diagramme de séquence « l’Availibility 2G »............................................................................... 48
Figure 29 : Diagramme d'activité « géolocalisation des incidents »................................................................ 49
Figure 30 : Diagramme de séquence « ajouter utilisateur »............................................................................. 49
Figure 31: Diagramme d'activité « ajouter utilisateurs »................................................................................ 50
Figure 32:Diagramme de classe ...................................................................................................................... 51
Figure 33 : JSF ................................................................................................................................................ 55
Figure 34 EJB3.1............................................................................................................................................. 55
Figure 35 : Architecture de la spécification JPA ............................................................................................. 57
Figure 36 : MAP 2G........................................................................................................................................ 58
Figure 37 : MAP 3G........................................................................................................................................ 58
Figure 38 Recherche par LAC......................................................................................................................... 59
Figure 39: courbe 2G RAN ............................................................................................................................. 59
Figure 40: géo localisation des incidents......................................................................................................... 60
Figure 41 : Exemple de fichiers incidents ....................................................................................................... 60
Figure 42 : voisinage d'un incident.................................................................................................................. 61
Figure 43 : Chronogramme de Réalisation...................................................................................................... 62
ii
Liste des tableaux
Tableau 1: Les seuils des KPIs........................................................................................................................ 25
Tableau 2 Tableau 1 Backlog du Produit ........................................................................................................ 28
Tableau 3: user story traitements des fichiers de données BTS....................................................................... 30
Tableau 4 : User Story Traitements des fichiers des incidents ........................................................................ 30
Tableau 5:user story Géo-localisation des sites BTS....................................................................................... 31
Tableau 6:User Story “rechercher site ” .......................................................................................................... 32
Tableau 7 : User Story “Afficher les voisinage ” ............................................................................................ 32
Tableau 8:User Story “geolocalisation des incident ” ..................................................................................... 34
Tableau 9:User Story “ KPI du réseau ”........................................................................................................ 34
Tableau 10: User Story “Availibilite 2G/3G RAN ” ..................................................................................... 34
Tableau 11: User Story gestion des cellules.................................................................................................... 36
Tableau 12: User Story gestion des Utilisateurs.............................................................................................. 36
Tableau 13: User Story gestion des BTS......................................................................................................... 37
1
Introduction Générale
Les réseaux mobiles ont connu un large succès avec l’apparition de la norme de deuxième
génération qui a permis essentiellement d’obtenir une meilleure qualité de voix. Afin de
permettre la création de nouveaux services et d’offrir aux usagers une véritable itinérance à
l’échelle mondiale, il était devenu nécessaire d’effectuer un saut technologique et de
franchir le pas vers les réseaux cellulaires de troisième et de quatrième génération.
Il s'avère donc que la qualité de service, dans ce domaine comme dans beaucoup d'autres,
constitue une source fondamentale de différenciation, aussi déterminante que le prix du
service fourni ou l'étendue de la couverture. Le maintien et le suivi de cette qualité
nécessitent le contrôle continu de l'état de fonctionnement du réseau et de toutes
les performances réalisées et par conséquent, l'intérêt d'outils d'ingénierie adaptés. L’un des
moyens de contrôle et de supervision qui s’offrent aux opérateurs téléphoniques est
l’utilisation d’outils ou applications qui rendraient facile la gestion des équipements
constituant leurs réseaux, entre autres les équipements BTS dont le contrôle ainsi la gestion
des incidents est le sujet de ce projet.
C’est dans cet ordre d’idées que s’inscrit ce projet de fin d'études qui a pour objectif
la conception et la réalisation d’un portail web pour l’évaluation des performances du
réseau de l’opérateur Tunisiana.
Le présent rapport se décompose en cinq chapitres, nous présentons le contenu de chaque
chapitre. Dans le premier chapitre, nous présentons l'environnement du travail ainsi que le
sujet à traiter. Le second chapitre est consacré à la présentation des architectures des
réseaux cellulaires tels que GSM, GPRS, et UMTS et les étapes de l'évolution de ces
réseaux. Nous traitons aussi dans ce chapitre le concept et les critères de la qualité de
service (QoS). Le troisième chapitre traite l’analyse des besoins et des spécifications de
l’application à développer. La conception globale et détaillée de l’outil que nous avons
réalisé fait l’objet du quatrième chapitre .Enfin, le dernier chapitre de ce rapport illustrera
les réalisations effectuées au cours de ce projet.
Chapitre 1 : Présentation du cadre de travail et du sujet
2
Chapitre 1
Présentation du cadre de travail et du
sujet
Chapitre 1 : Présentation du cadre de travail et du sujet
3
Introduction
Avant de traiter le sujet du présent projet de fin d’études, il convient de présenter
l’environnement dans lequel il a été mené à bien. En effet, c’est de l’environnement que
dépend, en grande partie, l’efficacité et la qualité d’un travail.
Nous avons effectué notre projet de fin d’études au sein de l’entreprise TUNISIANA
premier opérateur privé de télécommunications en Tunisie.
1 Cadre du projet
1.1 Présentation de l’entreprise
Orascom Telecom a octroyé, le 11 mai 2002, la deuxième licence de téléphonie mobile en
Tunisie (OTT) et devient ainsi le premier operateur GSM privé en Tunisie.
Cette licence a permis la mise en place d’un réseau de transmission GSM et d’une
passerelle internationale, d’une durée de quinze ans, renouvelable deux fois tous les cinq
ans et une exclusivité jusqu’au 30 juin 2004. Ainsi TUNISIANA a réalisé son lancement
commercial le 27 décembre 2002 pour atteindre jusqu’à aujourd’hui 100% de couverture
de la population Tunisienne.
Depuis son lancement, grâce à la qualité des ressources humaines et aux performances
techniques qui ne sont plus à démontrer et une qualité du réseau reconnue à l’échelle
nationale et internationale, Tunisiana a su arracher la première place sur le marché
Tunisien et devenir ainsi fin 2010 le leader National en GSM avec presque 52% de part de
marché.
Tunisisana a pour objectifs de :
 Satisfaire sa clientèle en assurant un bon niveau de service.
 Maximiser et maintenir les objectifs en termes de parts de marché sur la base d’un
programme à trois dimensions : Acquisition, Fidélisation, Consommation.
TUNISIANA est une entreprise en plein essor, l’hiérarchie interne est conçue pour faciliter
les promotions et garantir ainsi un maximum de motivation pour le personnel. La Division
Supervision dans laquelle nous avons effectué notre Projet est ainsi conçue comme suit :
Chapitre 1 : Présentation du cadre de travail et du sujet
4
Division Supervision
Service supervision front
Office Service supervision back
Office
Figure 1 : Organisation de la division Supervision au sein de TUNISIANA
1.2 Rôle de la Division Supervision
Le service supervision Back Office se charge de détecter les dysfonctionnements qui n’ont
pas un impact direct ou immédiat, majeur ou critique sur la qualité de service offerte au
client. Les tâches principales consistent à :
 faire des statistiques quotidiennes, hebdomadaires ou mensuelles sur les différents
équipements BSS
 identifier les quels est défectueux,
 alerter les concernés,
 suivre les problèmes récurrents impactant le client.
Comme son nom l’indique, le service Front Office a la charge :
 détecter immédiatement les incidents majeurs et critiques, les classifier par criticité.
 identifier l’impact.
 alerter les concernés, support niveau 1 et escalade en cas de besoin.
Les incidents traités sont ceux qui ont un impact direct sur la qualité de service offerte.
Chapitre 1 : Présentation du cadre de travail et du sujet
5
1.3 Le concept « Incident »
Apres sept ans et plus depuis son lancement commercial, TUNISIANA est devenue mature
en terme de prestataire de service de téléphonie mobile, la clientèle est devenu assez
grande et diversifiée, l’environnement est de plus en plus concurrentiel avec l’arrivée d’un
troisième opérateur sur le marché, en plus l’abonné est devenu de plus en plus exigeant.
Tous ces facteurs obligent Tunisiana à être compétitive, innovatrice et surtout très vigilante
concernant l’état de son réseau. Pour garder son image de marque, elle est appelée à
superviser tout son réseau en temps réel ainsi que tous ses services et promotions.
Donc, si on se réfère au service front Office, un incident est un événement qui peut
provoquer un dysfonctionnement ou qui a un impact immédiat sur le client pour pouvoir
gérer les incidents il est primordial d’implémenter tout un processus de détection,
d’investigation, d’alerte, de support niveau 1, et d’enregistrement dans une Base.
Dans ce qui suit on se penchera seulement sur les incidents qui touchent la partie BSS du
réseau GSM, c'est-à-dire les BTS et les BSC
Les types des incidents :
 Système : ce sont des incidents dus à un élément défectueux dans un équipement
réseau (carte électronique, capteur, câble…..)
 Transmission: Tous les équipements réseau sont connectés les uns par rapport aux
autres selon un routage bien spécifique, la mise Hors Service de l’une de ces routes
impacte directement un équipement, c’est pour cela que le réseau de transmission
est supervisé
 Environnement : un incident peut se déclencher par un facteur externe au réseau qui
peut être une coupure courant, un facteur climatique, un défaut de climatisation
Chapitre 1 : Présentation du cadre de travail et du sujet
6
Figure 2:Types d’incidents BTS
2 Présentation de sujet :
Ce projet de fin d’étude porte sur la réalisation d’un outil de suivi de performance du
réseau de TUNISIANA et à présenter L’impact de disfonctionnement d’un site sur la QOS
de réseaux 2G/3G.
3 Conduite du projet
3.1 Processus de développement
Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui
concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système
existant. Ce processus a pour objectif de produire des solutions informatiques de qualité
répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles. De ce fait,
Chapitre 1 : Présentation du cadre de travail et du sujet
7
l’adéquation du projet au processus de développement peut largement affecter le sort d’un
projet informatique.
3.2 Méthodologie Agile
Méthode de développement informatique tournée vers le client. Le développement agile
tire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17
personnalités dont Kent Beck, Ward Cunnigham, Martin Fowler ou Dave Thomas. Douze
principes ont été définis. Parmi les principaux:
 Parvenir à la satisfaction du client par le biais d'un cycle de développement rapide,
récurrent et incrémental de versions fonctionnelles;
 Se montrer apte à prendre en compte les changements de dernière minute à tout
moment du projet;
 Mettre en place une coopération quotidienne entre développeurs et
décideurs/commerciaux;
 Motiver les développeurs par un environnement, un soutien et une confiance
solides;
 Faire simple, mais pas simpliste;
 Laisser l'équipe s'organiser au mieux de ses possibilités.
Il existe une dizaine de méthodologies "officielles" s'adaptant chacune à des
besoins différents. Certaines sont plus adaptées aux petites équipes, comme Crystal,
XP, Scrum, tandis que d'autres sont prévues pour des groupes conséquents, par
exemple RAD, RUP et ASD.
Nous avons opté pour la méthode de développement agile Scrum, car elle est très adaptée
aux projets comme le mien et dont les besoins sont constamment redéfinis.
Chapitre 1 : Présentation du cadre de travail et du sujet
8
Figure 3: Méthodologie Agile
3.3 Scrum
Davantage qu’une méthode formelle, Scrum peut être vu comme un framework
méthodologique – ses fondateurs parlent d’organisationnel pattern – dont l’implémentation
doit être ajustée en fonction des caractéristiques techniques, organisationnelles et
culturelles des projets qui souhaitent la mettre en œuvre (Scrum, au demeurant, ne limite
pas son champ d’application aux seuls projets informatiques : ses principes sont
applicables pour toute activité visant à produire un résultat).
Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et
d’artefacts qui permettent de relever les défis principaux du développement incrémental :
la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement
piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de
ce prisme. Scrum identifie trois acteurs :
Chapitre 1 : Présentation du cadre de travail et du sujet
9
 le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et
est à même de réaliser les arbitrages nécessaires à la priorisation des
développements. Son rôle est absolument essentiel, et son respect des règles du jeu
est la pierre angulaire du succès d’un projet agile. Dans notre cas il s’agit d’Imed
Hamza.
 le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la
capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à
s’améliorer constamment. Il est également le garant de la bonne implémentation de
Scrum. Dans notre cas il s’agit de Md Jihéne ben Abderazek
 l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis
comme une borne supérieure), et qui prend en charge le développement du produit
(planification, conception, codage, tests, documentation) sans spécialisation des
rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc
dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les
approches managériales traditionnelles, qui privilégient un contrôle centralisé
généralement incarné par le Chef de Projet. Dans notre cas il s’agit de moi.
L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de
2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification
initiale.
Le schéma suivant décrit l’articulation générale de Scrum :
Figure 4:Sprint Scrum
Chapitre 1 : Présentation du cadre de travail et du sujet
10
Scrum définit également trois artefacts :
 le Product Backlog,
 le Sprint Backlog
 le Burndown Chart, qui est une représentation graphique très simple de
l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un
autre pour la version du produit
Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog
sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et
faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métiers du
produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les
informations suivantes :
 un identifiant – unique, il permet de tracer l’élément quand on le renomme
 un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et
l’Equipe comprennent approximativement de quoi il est question
 l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux
yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur
relative compte
 l’estimation initiale – exprimée en points de complexité, et dont la valeur est
déterminée par l’Equipe.
 comment faire la démo ? – cela correspond globalement à la spécification d’un test
fonctionnel simple.
 des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer
vers d’autres
Le Product Backlog peut également contenir des éléments techniques – mais il est
indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de
Produit puisse lui affecter une valeur. Il peut être conservé sous différentes formes, la plus
fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.Le
Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent
être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées)
Chapitre 1 : Présentation du cadre de travail et du sujet
11
de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et
l’estimation initiale peuvent être revues, à la hausse ou à la baisse.
Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de
Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et
le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est
durant cette cérémonie que l’estimation fine de la charge de développement de chaque
histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet
d’une estimation de charge –exprimée en heures ou en jours. Il est important de noter que
c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de
cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que
l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches
correspondantes.
La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de
l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette
capacité de production, ou vélocité estimée).
Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour
son exploitation en production – cette caractéristique est à l’origine du qualificatif «
incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet
d’une démonstration publique.
Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux
tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le
terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les
méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous-
tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est
de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon
générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de
l’Equipe, et ne fait pas l’objet de négociations
Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies
additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits
Chapitre 1 : Présentation du cadre de travail et du sujet
12
en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait
partie de l’ADN de Scrum (on parle de time boxing).
Voici les principales cérémonies préconisées par Scrum :
 le Sprint planning, que nous avons déjà abordé
 la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes)
menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et
dont l’objectif est de maintenir chacun au courant de l’activité de tous, de
déterminer les tâches de la journée et d’identifier les éventuels obstacles qui
ralentissent ou empêchent la progression du sprint la revue de sprint (Sprint
Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une
démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le
caractère incrémental du développement (pour être démontré, le produit doit être
utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins
d’ajuster le contenu du backlog de produit
 la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au
terme de chaque sprint afin d’identifier les erreurs commises lors du sprint
précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le
processus ; la rétrospective est une cérémonie capitale qui incarne l’un des
principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers,
l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son
comportement en conséquence ».
Chapitre 1 : Présentation du cadre de travail et du sujet
13
Figure 5 : Processus Scrum
Conclusion
Dans ce chapitre, nous avons essayé de définir le cadre de notre projet en termes
organisationnel et professionnel. Ensuite nous avons présenté la notion d’incident tout en
insistant sur l’importance du processus de résolution des incidents. Ainsi le sujet à traiter
qui est le développement d’un outil pour le suivi des performances du réseau Tunisiana
2G/3G. A ce stade, on va étudier et présenter les architectures des réseaux 2G /3G et
définir aussi les concepts liés à la qualité de service, ce qui fera l'objet du deuxième
chapitre
Chapitre 2 : Etat de l’art des réseaux cellulaires
14
Chapitre 2
Etat de l'Art des Réseaux Cellulaires
Chapitre 2 : Etat de l’art des réseaux cellulaires
15
Introduction
Ce chapitre est un état de l'art de la téléphonie radio mobile dans lequel nous présenterons le
contexte dans lequel s'inscrit le présent projet afin de pouvoir se focaliser sur les composantes
de notre sujet. Nous étudierons successivement les interfaces radio mobiles mises en jeu,
ensuite, nous traiterons le concept de qualité de service.
1 Concept Cellulaire
Le concept cellulaire constitue le principe de base des réseaux radio mobiles. La zone
desservie par un opérateur est divisée en cellules alimentées à partir d'une station de base.
Une cellule représente l'ensemble des points du territoire couvert par une même BTS (Base
Transceiver Station) et oïl le signal transmis par cette BTS est le plus fort .Chaque cellule est
identifiée par un BSIC (Base Station Identity Code). Le mobile est toujours connecté à la BTS
la plus proche de point de vue radio. [1]
Figure 6 : Concept cellulaire
L’utilisation du concept cellulaire permet d'ajuster les ressources radio à la demande en trafic.
Le principe se traduit par des zones à forte concentration de BTS couvrant de petites cellules
et des zones rurales à faible concentration de BTS couvrant des cellules.
Chapitre 2 : Etat de l’art des réseaux cellulaires
16
2 Evolution des réseaux cellulaires
2.1 Norme GSM
La norme GSM est un système cellulaire de transmission numérique. Le réseau GSM a pour
rôle essentiellement de permettre des communications entre abonnés mobiles (GSM) et
abonnés du réseau téléphonique commuté (RTC ou réseau fixe). Le GSM qui a fait une
rupture avec les systèmes cellulaires analogiques, utilise les bandes de fréquences 900 MHz
1800 MHz et utilise la technique de multiplexage F-TDMA ce qui offre un multiplexage
temporel et fréquentiel à la fois.
2.1.1 Architecture Générale et Equipements
Le réseau GSM comporte les 3 sous-ensembles :
 Le Sous-système Radio BSS : responsable d'assurer et gérer les transmissions radios.
Une station mobile est un terminal de données qui transmet et reçoit des messages du
réseau. La «Base Transceiver Station» ou (BTS)»représente l'ensemble d'émetteurs et
de récepteurs fixes. Elle a pour rôle d'échanger des messages avec les stations mobiles
présentes dans la cellule qu'elle contrôle. Nous trouvons aussi le contrôleur de station
de base nommé «Base Station Controller » ou (BSC). Il communique avec une ou
plusieurs BTS.
Figure 7 Le Sous-système Radio
Le Sous-système Réseau NSS : comporte l'ensemble des fonctions nécessaires pour
les appels et la gestion de la mobilité .On trouve le commutateur du réseau «Mobile
Switching Centre» ou (MSC) qui a pour rôle le contrôle de la BSC .D'une part, il
permet l'interconnexion entre un réseau GSM et une réseau téléphonique public
interconnecte un réseau GSM avec le réseau téléphonique public RTCP/RNIS, D'autre
part, il présente l'interface des bases de données du réseau GSM avec le sous-système
Chapitre 2 : Etat de l’art des réseaux cellulaires
17
radio. Ces bases de données enregistrent la localisation des abonnés. A ce niveau, on
trouve les entités :
 VLR «Visitor Location Register» : Une base de données représentant l'enregistreur
des visiteurs.
 HLR «Home Location Register» : Une base de données contenant les informations
relatives à chaque utilisateur (abonné) à savoir l'IMSI et l'IMEI.
 AUC «Authentification Centre» : Une base de données qui permet
l'authentification des demandes de services En effet, quand cet abonné demande
l'accès à un service, un équipement du réseau qui veut contrôler la validité des
privilèges du demandeur interroge le HLR de l'abonné. Le HLR d'un abonné
contient des informations permanentes. En revanche, un VLR enregistre les
informations temporaires, relatives à une station mobile.
Figure 8:Le Sous-système d'Acheminement
 Le Sous-système d'Exploitation et de Maintenance OSS : permet à l'opérateur
d'exploiter et de contrôler son réseau. Les équipements (OMC, EIR et AUC) assurent
ensemble l'administration du réseau. L'OMC est responsable de la gestion du
rendement, la gestion de la sécurité, et les opérations de maintenance. L'EIR est une
base de données qui peut être consultée lors des demandes de services d'un abonné
pour vérifier que le terminal utilisé est autorisé à fonctionner sur le réseau. L'AUC est
une base de données qui permet l'authentification des demandes de services.
Chapitre 2 : Etat de l’art des réseaux cellulaires
18
Figure 9 : Le Sous-système d'Exploitation et de Maintenance
2.1.2 Identités dans un réseau GSM
Nous s'intéresse dans cette partie aux paramètres d'identification des clients dans le réseau.
 IMSI
IMSI (International Mobile Subscriber Identity) est l'identifiant unique affecté à un abonné
qui souscrit à un abonnement mobile auprès d'un opérateur. Ce numéro d'IMSI a été
préalablement stocké sur la carte SIM (Subcriber Identity Module). Le numéro d'IMSI n'est
pas connu de la part de l'abonné mobile et n'est utilisé que par le réseau GSM. LIMSI est
constitué de trois sous-champs :
 MCC (Mobile Country Code) : Il présente le code du pays du réseau.
 MNC (Mobile Network Code) : Il s'agit du code du réseau mobile. Il identifie de
manière unique le réseau GSM à l'intérieur d'un pays.
 MSIN (Mobile Subscriber Identification Number) : il s'agit du numéro d'identification
du mobile. Il identifie l'abonné mobile à l'intérieur du réseau mobile.
 MSISDN
MSISDN (Mobile Station ISDN Number) est le numéro de téléphone associé à la station
mobile .Il contient les trois sous-champs suivantes :
 CC (Country Code) : présente le code du pays dans lequel l'abonné mobile a
inscrit son abonnement.
 NDC (National Destination Code) : Il s'agit du numéro national du réseau GSM
dans lequel un client a souscrit un abonnement.
 SN (Subscriber Number) : Il s'agit du numéro d’abonné
 IMEI
L'IMEI, (International Mobile Equipment Identity) permet d'identifier de façon unique un
terminal mobile au niveau international. Ce numéro est donné par le constructeur du terminal
Chapitre 2 : Etat de l’art des réseaux cellulaires
19
mobile. L'IMEI est utilisé par les opérateurs GSM pour lutter et défendre contre les vols de
terminaux ou pour empêcher l'accès au réseau à des terminaux.
2.1.3 Les limites de la Norme GSM
Le GSM offre un débit maximal de 9,6 Kbit/s ce qui permet de transmettre en plus de la voix,
des données de faible volume comme le SMS ou le MMS. Il est apparu vers le milieu des
années 1990 que cette norme atteindrait rapidement ses limites en termes de support d'un
service de transmission de données à haut débit. De plus et avec le progrès dans les services
proposés par l'internet, il parait nécessaire de coupler la mobilité avec l'accès à l'internet. Pour
cela les opérateurs ont pensé à migrer de la norme GSM à une autre norme qui évite les
lacunes et les défauts du système de seconde génération et qui répond aussi au défi de la
transmission de données à haut débit. Cette évolution débute par la phase de l'introduction du
GPRS avec la transmission en mode paquet sur la voie radio.
2.2 Le standard GPRS
2.2.1 L'apport de la technologie GPRS
Cette technologie étend l'architecture de la norme GSM et permet un transfert de données à un
débit plus élevé tout en optimisant l'utilisation des ressources. La technologie GPRS donne la
possibilité d'atteindre un débit maximal théorique de 171,2 Kbit/s ce qui correspond pour
l'utilisateur à un débit maximal de 114 Kbit/s dans les conditions optimales.
Donc la mise en place d'un réseau GPRS permet à un opérateur de proposer de nouveaux
services de type data avec un débit de données 5 à 10 fois supérieur au débit maximum
théorique d'un réseau GSM.
Le GPRS spécifie une technique de transmission en mode paquet qui immobilise le canal de
communication. Cet action donne la possibilité d'avoir une connexion permanente et une
facturation à la donnée ce qui présente un avantage non négligeable pour l'utilisateur qui peut
rester connecté sans surcoût et ne paye que le coût du volume échangé de données le contraire
de GSM où l'utilisateur est facturé par le temps de connexion ainsi il paye même s'il ne
consomme pas la capacité du réseau.
2.2.2 Architecture Matérielle du GPRS
L'intégration du GPRS nécessite l'ajout de quelques équipements et des mises à jour aux
entités du réseau GSM pour que l'ancien réseau accepte l'intégration de la nouvelle
Chapitre 2 : Etat de l’art des réseaux cellulaires
20
technologie tout en conservant ses fonctionnalités. La figure ci-dessous présente une
architecture de la norme GPRS.
Figure 10 : Architecture du Réseau GPRS
Comme la figure 9 le présente, il existe coté NSS un réseau de commutation de paquets en
parallèle du réseau de commutation de circuit. Pour cela on ajoute deux entités (SGSN et
GGSN). Le SGSN est le dual paquet du MSC/VLR circuit. Il est connecté au BSS et à des
SGSN et GGSN voisins. Le SGSN joue le même rôle réalisé par le VLR dans la gestion de
mobilité. En effet, il s'occupe aussi de la compression et cryptage des données. Pour le GGSN
il s'agit d'un nœud d'interfonctionnement entre le réseau de données extérieur et le réseau
mobile de transfert de paquets.
2.2.3 La technologie EDGE
L'EDGE peut être considéré comme une amélioration du GPRS. Les opérateurs font le
recours à cette technologie car la norme UMTS les oblige à déployer un autre réseau physique
et donc des investissements très lourdes. L'EDGE présente l'avantage de pouvoir utiliser les
infrastructures déjà déployées contrairement à l'UMTS.
L'EDGE est mis en place afin d'accroître la capacité des données par rapport au GPRS. La
vitesse de transfert de données pour un réseau EDGE peut théoriquement atteindre un débit
maximum de 384 Kbps contre seulement 114 Kbps pour un réseau GPRS.
Chapitre 2 : Etat de l’art des réseaux cellulaires
21
Même avec l'introduction du GPRS et EDGE, le débit pratique dans des conditions optimales
ne passe pas les 120 Kbit/s ce qui ne pas correspond aux attentes des utilisateurs .Pour cela les
opérateurs se trouvent obligés à sacrifier financièrement et installer le réseau de troisième
génération.
2.3 Téléphonie à mode paquet à haut débit : UMTS
L'UMTS ou 3G est une norme pour les réseaux mobiles permettant de fournir aux utilisateurs
une meilleure qualité de service. L'UMTS est capable d'offrir de nouvelles applications
multimédias et des services à valeur ajoutée telle que la visiophonie et internet à haut débit.
L'UMTS utilise des fréquences plus élevées que le standard 2G. L'UMTS occupe les bandes
passantes : 1885-2025MHz et2110-2200MHz.
2.3.1 Architecture de l'UMTS
Le réseau UMTS possède une architecture flexible et modulaire. L'architecture illustrée à la
figure 10, est composée de trois entités qui sont l'équipement de l'usager(UE), le réseau
d'accès radio (UTRAN) et le réseau cœur (CN). En effet, chaque équipement doit réaliser une
fonction bien déterminée dans le réseau, alors que des interfaces d'échange, notés
par Uu et Iu, assurent les échanges et la communication entre les différentes entités du réseau.
[6]
Figure 11 : Architecture de l'UMTS
Chapitre 2 : Etat de l’art des réseaux cellulaires
22
2.3.2 Le domaine UE (User Equipement)
Il comprend tous les équipements terminaux et permet l'accès à l'infrastructure du réseau et à
ses services par le biais de l'interface Uu. [2]
2.3.3 UTRAN (UMTS Terrestrial Radio Access Network)
Il fournit les ressources radio et les mécanismes nécessaires à l'UE pour accéder au CN. Il
permet la maintenance et la libération des canaux radio entre le terminal et le réseau coeur CN
et la gestion de ressources radio. L'UTRAN est composé d'un ensemble de sous-systèmes
nommés RNC et de plusieurs stations de base appelé NodeB.
 NodeB : il a comme rôle la transmission et la réception d'informations entre
l'UTRAN et un ou plusieurs équipements usagers. Les UEs sont connectés au
Node B via l'interface Uu, qui assure la connexion radio. Le Node B s'occupe de la
transmission et de la réception du signal radio, de la modulation/démodulation, du
codage de canal et l'adaptation du débit de transmission.
 RNC: Il assure essentiellement le routage des communications entre les Nodes B
et le réseau coeur d'une part et le contrôle et la supervision des Noeuds B d'autre
part par le biais de l'interface IuB.
Figure 12 : UTRAN
2.3.4 Riau Cœur CN (Core Network)
Le CN assure la connexion entre les différents réseaux d'accès radio d'une part et les autres
réseaux externes d'autre part tels que RTCP et les réseaux Internet. Sa principale
fonctionnalité est la commutation et le routage des données utilisateurs vers la destination
correspondante, la gestion de la mobilité, de l'authentification, de la sécurité des échanges, de
la taxation et de signalisation entre les terminaux mobiles et les réseaux distants via l'interface
Chapitre 2 : Etat de l’art des réseaux cellulaires
23
radio. Dans le rôle d'acheminement, le réseau coeur se compose de serveurs et de passerelles
qui se divisent entre deux sous-systèmes principaux: le domaine CS et le domaine PS.
2.4 HSPDA
HSPDA (High Speed Downlink Packet Access) ou encore 3.5G ou le 3G+ présente une norme
évoluée du standard UMTS. En effet, ce protocole pour la téléphonie mobile offre des
performances dix fois supérieures à la 3G.Cette évolution basée essentiellement sur la
technologie WCDMA permet à un utilisateur de télécharger à des débits théoriques de 1,8
Mbit/s ; 3,6 Mbit/s ; 7,2 Mbit/s et 14,4 Mbit/s. Donc, il s'agit d'une amélioration qui offre des
occasions de téléchargement à des très hauts débits de telle façon qu'on peut atteindre un débit
de téléchargement qui dépasse 7,2 Mbit/s avec la Release7.
2.5 HSUPA
HSUPA (High Speed Uplink Packet Access) est une norme de haut-débit mobile de troisième
génération dont les standards ont été définies et diffusés par le 3GPP dans la sixième édition
du référentiel UMTS (Release 6 de l'UMTS). HSUPA présenté comme un successeur de la
technologie HSPDA, vient d'améliorer le débit sur la voie montante (Uplink) qui peut
atteindre à ce niveau 5,8 Mbit/s alors que le débit descendant (Downlink) reste le même que
celui de son prédécesseur (HSPDA) qui atteint 14 Mbit/s.
3 Concept de la qualité de service
3.1 Définition
Généralement, la qualité de service ou Quality of Service (QoS) est la capacité de transférer
dans les bonnes conditions un type de trafic donné, en termes de disponibilité, débit, et délai
de transition. La qualité de service pour le réseau détermine le degré de satisfaction de
l'utilisateur aux services offerts.
3.2 Critères de performances des réseaux 2G/3G
Afin de permettre aux opérateurs d'obtenir des informations sur la qualité du service offert par
leur réseau et de l'optimiser, des indicateurs de performance appelés KPIs
(Key Performance Indicators) qui spécifient le fonctionnement radio des cellules ont été
également définis. [4]
En effet, un KPI est une valeur représentative permettant d'évaluer la performance de
système. Cette valeur est obtenue à partir d'une ou de plusieurs mesures brutes relevées par
Chapitre 2 : Etat de l’art des réseaux cellulaires
24
des compteurs spécifiques. Ces indicateurs permettent la localisation des anomalies de réseau
et par suite, l'identification et le diagnostic des causes de ces problèmes afin de réagir avec
des actions correctives adéquates.
Dans le but d'offrir une qualité de service acceptable il faut que certains problèmes doivent
être résolus. Ces problèmes sont principalement liés à :
3.2.1 La couverture :
Ce problème ne peut pas être détecté par le système mais évalué par les plaintes des abonnées
et par les mesures radio. Les causes probables de ce problème sont les suivants :
 Mauvaise configuration du réseau c'est-à-dire problème lié à la position des sites, ou
les types d'antennes.
 Problème d'installation qui peut être due à la perte des puissances dans les câbles.
 Problème de maintenance.
3.2.2 La disponibilité du réseau :
C'est la probabilité d'obtention d'un nouvel appel. La diminution de taux d'appel aboutis
implique que les abonnées ne peuvent pas établir une communication. Les actions de l'échec
d'établissement d'appel s'expliquent par :
 Le niveau d'accès minimum dans la cellule.
 L'interférence et la mauvaise couverture radio.
3.2.3 La qualité de voix :
L'opérateur agit contre le problème de la mauvaise qualité de communication, par les mesures
système et par les analyseurs de la qualité vocale. Les causes de dégradation de la qualité de
la voix sont :
 La hors couverture.
 La mauvaise installation.
 La qualité des terminaux.
3.2.4 Les coupures d'appels :
La coupure de communication peut être engendré par :
 La mauvaise couverture.
 Les interférences.
Chapitre 2 : Etat de l’art des réseaux cellulaires
25
Si un des KPI excède les seuils fixés par l'opérateur, le superviseur du réseau vient de signaler
un problème détecté au niveau de la fonctionnalité qu'assure cet indicateur. Généralement, ce
problème est généré à partir d'un problème ou une anomalie de couverture, d'insuffisance de
capacité, d'interférence, ou d'un problème mauvais paramétrage du réseau.
A titre d'exemple, si nous enregistrons un taux de coupure de l'appel supérieur à 2%, alors
nous avons un problème de maintien d'appel qui peut 1tre causé par la mauvaise couverture,
l'interférence, problème lors du handover (dans ce cas on consultera les taux de succès de
handover) ou un mauvais paramétrage du réseau. De plus, si le taux de succès de
l'établissement d'un service est inférieur à 95%, dans ce cas nous avons un problème d'accès
au réseau causé par la capacité, l'interférence ou un problème de paramétrage du réseau.On
présente ci-dessous un tableau qui illustre les seuils de quelques KPI :
Tableau 1: Les seuils des KPIs
Conclusion
Après avoir traité tout le long de ce deuxième chapitre les architectures des réseaux cellulaires
ainsi que le concept de la qualité de service(QoS), en présentant les différents paramètres et
critères de performance de la QoS, nous présentons passer à l’analyse des besoins à travers le
chapitre suivant.
Chapitre 3 : Analyse des besoins et spécifications
26
Chapitre 3
Analyse des Besoins et Spécifications
Chapitre 3 : Analyse des besoins et spécifications
27
Introduction
Nous allons maintenant nous consacrer à la phase d’analyse et de spécification. Elle consiste à
identifier les différentes fonctionnalités de l’application et à décrire les différents cas
d’utilisation posés par le sujet de point de vue utilisateur.
Dans cette optique nous allons tout d’abord définir les fonctionnalités offertes par le système
répondant aux besoins de TUNISIANA ensuite spécifier les acteurs pour arriver à la fin à la
présentation des cas d’utilisation.
1 Objectifs
L'objet de ce projet est la conception et la réalisation d'un outil destiné à gérer et à présenter
L’impact de disfonctionnement d’un site sur la QOS de réseaux Tunisiana.
Pour répondre à ces objectifs, différents volets d’analyse seront menés dans le cadre de ce lot,
à savoir la définition des besoins fonctionnels, l’analyse de l’existant et la conception de la
cible globale, pour avoir le dossier fonctionnel des besoins (fonctionnels et techniques).
2 Spécification des exigences
Dans cette section nous identifions une liste d’exigences fonctionnelles et non fonctionnelles
du système à concevoir. Certaines exigences sont ajoutées pour clarifier d’avantage les
besoins des utilisateurs.
2.1 Les acteurs système
Cette application est destinée à l’équipe de supervision de Tunisiana. La structure de cette
application ainsi que tous les services proposés par l’application, seront détaillés dans les
chapitres suivants.
2.1.1 Administrateur :
L’administrateur de cette application sera en charge de la création des différents Utilisateur.
L’administrateur est le seul à pouvoir créer et supprimer des fiches de personne en tant
qu’administrateur, il n’a pas le droit de modifier les données des fiches. Cependant, il aura la
possibilité de prendre l’identité d’une personne pour avoir accès à ses droits, et effectuer ainsi
des modifications.
Chapitre 3 : Analyse des besoins et spécifications
28
2.1.2 Utilisateur :
C’est l'équipe de supervision qui a le droit de manipuler l'application.
2.2 Le Backlog du produit :
Tout dans Scrum tourne autour du backlog produit. Ce backlog contient, sous forme de liste,
les choses que le client veut que l'équipe réalise. C'est en quelque sorte une « liste priorisée
d'exigences, d'histoires, de caractéristiques, ou autre ». Le backlog produit est maintenu par
le product owner.
Nous avons choisi d’intégrer dans notre système les fonctionnalités les plus importantes qui
sont les suivantes:
 Traitement Des Informations.
 L’analyse des données.
 Déterminer l’Availability de 2 G RAN/ 3G RAN de réseaux Tunisiana.
 Déterminées l’emplacement des tous les sites de réseaux Tunisiana.
 Déterminer le voisinage d’un site sur une distance bien déterminé.
 Déterminer L’impact de disfonctionnement d’un site sur le QOS de réseau Tunisiana
sur cette zone.
Story
ID
Story name Status Sprint Priority Estimation
(j)
1 analyse et traitement des données Done 1 1 18
2 Géolocalisation des sites 2G/3G sur google maps Done 2 1 18
3 calculer et afficher l'avaibility 2G/3GRAN Done 3 1 10
4 traitement des incidents et déterminer les sites HS
et l'impact sur le reseau
Done 3 2 20
5 afficher tous les cellules du réseau Tunisiana Done 4 2 7
6 gestion d’utilisateur Done 4 3 7
7 gestion BTS Done 4 3 7
Tableau 2 Tableau 1 Backlog du Produit
Chapitre 3 : Analyse des besoins et spécifications
29
2.3 Diagramme des cas d’utilisation globale :
L’approche consiste à regarder le système à construire de l’extérieur, du point de vue de
l’utilisateur et des fonctionnalités qu’il attend. Chaque cas d’utilisation sera une spécification
de ce qu’il sera possible de demander de l’extérieur à l’entité ainsi représentée.
Figure 13: diagramme cas d'utilisation globale
Cette figure nous donne une vue globale sur les différents besoins fonctionnels ainsi les
acteurs qui interagissent avec notre application.
2.4 Sprint
Après avoir spécifié les besoins avec le « Product Owner », nous avons organisé les tâches
sous la forme de « Sprints » où chaque sprint aura une durée de vingt jours ou plus avec pour
objectif avoir un produit fonctionnel et livrable à la fin de chaque sprint. Nous avons organisé
notre produit backlog sous la forme de cinq sprints selon l’ordre de priorité des tâches à
réaliser et la durée que nécessite l’accomplissement de chaque tâche. Nos sprints serons
composés comme suit :
2.4.1 Sprint 1
Le sprint 1 est Généralement de criticité élevée. Ce sprint est composé de Deux User Stories
décrits ci-dessous.
Chapitre 3 : Analyse des besoins et spécifications
30
User Story 1
Tableau récapitulatif du première User Story “ Traitements des fichiers de données BTS ”
Id 1 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Traitements des fichiers des données BTS
Valeur/criticité 1 Criticité élevée
Estimation 10j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Serveur des fichiers
2. Sélections des fichiers
3. Sélections de données
4. organisation et gestion des données BTS
Pourquoi ? Déterminées l’équipement du réseau
Tableau 3: User Story traitements des fichiers de données BTS
User Story 2
Tableau récapitulatif du première User Story “ Traitements des fichiers des incidents ”
Id 2 Projet Portail Web d’Evaluation de Performances du
Réseau Tunisiana.
Nom Traitements des fichiers des incidents
Valeur/criticité 1 Criticité élevée
Estimation 8j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Serveur des fichiers
2. Sélections des fichiers
3. Sélections de données
4. Sélections des BTS HS
Pourquoi ? Suivre l’état des équipements réseaux
Tableau 4 : User Story Traitements des fichiers des incidents
Chapitre 3 : Analyse des besoins et spécifications
31
Figure 14 : Diagramme cas d'utilisation traitement des fichiers
2.4.2 Sprint 2
Ce sprint est composé de trois User Stories suivants :
User Story 3
Tableau récapitulatif du première User Story “Géolocalisation des sites BTS ”
Id 3 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Géo-localisation des sites BTS
Valeur/criticité 1 Criticité élevée
Estimation 6j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. Sélections des Bts 2G/3G
3. Sélections des cordonnées GPS
4. géo-localisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites
Tableau 5:User story Géolocalisation des sites BTS
Chapitre 3 : Analyse des besoins et spécifications
32
User Story 5
Tableau récapitulatif du première User Story “rechercher site ”
Id 3 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Rechercher site
Valeur/criticité 2 Criticité élevée
Estimation 6j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. Sélections des BTS 2G/3G
3. Sélections des cordonnées GPS
4. rechercher in site
5. géo-localisation sur google MAPS
Pourquoi ? Déterminer les emplacements d’un site bien déterminé
Tableau 6:User Story “rechercher site ”
User Story 6
Tableau récapitulatif du première User Story “Afficher les voisinage ”
Id 6 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana..
Nom Afficher les voisinages
Valeur/criticité 2 Criticité élevée
Estimation 6j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. Sélections des Bts 2G/3G
3. Sélections des cordonnées GPS
5. déterminer la distance des voisinages
4. géolocalisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites voisinage d’un site choisi
Tableau 7 : User Story “Afficher les voisinage ”
Chapitre 3 : Analyse des besoins et spécifications
33
La figure suivante présente le digramme de cas d’utilisation résultant du Sprint 2
Figure 15 : Cas d'utlisation de sprint 2
2.4.3
2.4.4 Sprint 3
Ce sprint est composé de trois User Stories suivants :
User Story 7
Tableau récapitulatif du première User Story “géolocalisation des incident ”
Id 7 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom géolocalisation des incidents
Valeur/criticité 3 Criticité élevée
Estimation 10j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. Sélections des BTS 2G/3G
3. Sélections des cordonnées GPS
5. sélections des incidents
6. déterminer les sites HS
4. géolocalisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites HS
Chapitre 3 : Analyse des besoins et spécifications
34
Tableau 8:User Story “géolocalisation des incident ”
User Story 8
Tableau récapitulatif du première User Story “KPI du réseau ”
Id 8 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana..
Nom Mesure QOS du réseau
Valeur/criticité 3 Criticité élevée
Estimation 10j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. Sélections des BTS 2G/3G
3. choix des KPI
4. afficher KPI
Pourquoi ? Déterminer les QOS de réseau
Tableau 9:User Story “ KPI du réseau ”
User Story 9
Tableau récapitulatif du première User Story “ Availibility 2G/3G RAN ”
Id 9 Projet d’Evaluation de Performances du Réseau
Tunisiana.
Nom Mesure 2G/3G RAN
Valeur/criticité 3 Criticité élevée
Estimation 5j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. déterminer la liste des incidents
3. calculer 2G/3G RAN
4. afficher courbe
Pourquoi ? Déterminer les QOS du réseau
Tableau 10: User Story “Availibilite 2G/3G RAN ”
Chapitre 3 : Analyse des besoins et spécifications
35
Figure 16 : Cas d'utilisation Déterminer les sites HS
Figure 17 Afficher Availibility 2G RAN
Chapitre 3 : Analyse des besoins et spécifications
36
2.4.5 Sprint 4
Ce sprint est composé de trois User Stories suivants :
User Story 8
Tableau récapitulatif du première User Story “gestion des cellules”
Id 8 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Gestion des cellules
Valeur/criticité 4 Criticité élevée
Estimation 7j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. déterminer la liste des cellules
3. afficher tous les cellules
4. recherche par plusieurs critères
5. modifier/ supprimer/ ajouter des cellules
Pourquoi ? Gestion des cellules
Tableau 11: User Story gestion des cellules
User Story 9
Tableau récapitulatif du première User Story “gestion des Utilisateurs”
Id 9 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Gestion des Utilisateurs
Valeur/criticité 4 Criticité élevée
Estimation 7j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. déterminer la liste des utilisateurs
3. afficher tous les utilisateurs
4. modifier / supprimer / ajouter des utilisateurs
Pourquoi ? Gestion des utilisateurs
Tableau 12: User Story gestion des Utilisateurs
Chapitre 3 : Analyse des besoins et spécifications
37
User Story 10
Tableau récapitulatif du première User Story “gestion des BTS”
Id 10 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Gestion des cellules
Valeur/criticité 4 Criticité élevée
Estimation 7j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Base de données
2. déterminer la liste des cellules
3. afficher tous les cellules
4. recherche par plusieurs critères
5. modifier / supprimer / ajouter des cellules
Pourquoi ? Gestion des BTS
Tableau 13: User Story gestion des BTS
Les figures suivantes présentes les digrammes de cas d’utilisation résultant du Sprint3
Figure 18 : Gestion BTS
Chapitre 3 : Analyse des besoins et spécifications
38
Figure 19 : Cas d'utilisations Afficher cellules
Figure 20 : Cas d'utilisations Gestion Utilisateur
Chapitre 3 : Analyse des besoins et spécifications
39
2.5 Besoins Non Fonctionnels
S’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d'implémentation (langage de programmation, type SGBD, de système
d'Exploitation...)
Dans le cadre de ce travail, l'application devra être extensible, c'est-à-dire qu'il pourra y avoir
une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.
L'application devra être capable de :
 Rapidité : l’application traite souvent un grand volume de données, elle doit alors
effectuer ces traitements d’une façon rapide et optimale afin d’éviter une longue durée
d’attente.
 Robustesse : l’application doit pouvoir gérer un très grand volume de données sans se
bloquer.
 Fidélité : la comparaison de paie est une étape cruciale qui manipule des données
sensible ainsi les résultats de calcul doivent être justes.
 Portabilité : l’application doit être facilement utilisable et ne doit pas nécessiter des
étapes de configuration ou d’installation.
 Evolutivité : l’outil doit être facilement modifié afin d’ajouter des nouveaux modules
répondant à des nouveaux besoins.
Conclusion
Ce chapitre a permis de détailler les spécifications du projet, d’identifier les cas d’utilisation
et d’élaborer les diagrammes correspondants. A présent nous sommes prêts à passer à l’étape
de conception dans le chapitre suivant.
Chapitre 4 : Conception
40
Chapitre 4
Conception
Chapitre 4 : Conception
41
Introduction
A la fin du chapitre précédent, nous avons présenté l’aspect architectural de la solution. Dans
la section suivante, nous présentons l’aspect conceptuel de notre application ; une
étape primordiale avant l’implémentation.
3 Architecture du système : Modèle multi couches
Les choix architecturaux d’une application sont décisifs dès lors qu’ils interviennent sur
les performances, l’évolutivité, le temps de développement, et bien sûr le coût. Aujourd’hui
nous parlons d’une séparation des applications en différentes couches, et nous parlons alors
d’applications multi niveaux.
L’architecture de notre système est une architecture multi niveaux à base de composants
respectant le paradigme JEE. Elle est constituée des couches suivantes modélisées dans la
figure ci-dessous. Nous notons la délimitation des couches de conception du modèle MVC2
des autres couches constituant notre système.
Figure 21 : modèle MVC
 Couche de présentation : Chargée de gérer les interactions entre l’utilisateur et
l’application (Navigateur Internet).
 Couche web : Permet de définir ce que doit afficher l’interface utilisateur et la manière
de gérer les requêtes.
 Couche métier : Contient le traitement à exécuter, qui sera appelé via la couche de
présentation faisant intervenir en général l’extraction et le traitement du contenu de la
couche de données via la couche d’accès aux données.
 Couche d’accès aux données : Prend en charge toutes les interactions entre la couche
logique et la couche de données. Si une telle couche n’existait pas, nous serions
contraints de réécrire les mêmes lignes de code à différents endroits de l’application.
Chapitre 4 : Conception
42
 Couche de données : Ce niveau contient les données de l’application (Base de
données, fichiers XML,).
Grâce à cette séparation en couches la souplesse, la maintenance et le développement de
l’application se trouveront grandement améliorés.
Par la suite, nous intéresserons aux détails des couches de la partie MVC2 qui contiendra
toute notre logique applicative.
4 Conception
Dans cette section nous présentons en premier lieu l’architecture logicielle de notre
application via un diagramme décrivant les dépendances entre les différents packages. En
second lieu nous présentons chacun de ces modules.
4.1 Conception détaillé
La conception détaillée consiste à concevoir et documenter précisément le code qui va être
produit. Dans cette phase, toutes les questions concernant la manière de réaliser le système à
développer doivent être élucidées. Le produit d'une conception détaillée consiste en
l'obtention d'un modèle prêt à coder. Lorsque l'on utilise des langages orientés objet le
concept de classe UML correspond exactement au concept de classe du langage concerné.
Cette propriété facilite la compréhension des modèles de conception et donne encore plus
d'intérêt à la réalisation d'une conception détaillée avec UML.
Dans cette partie, nous présentons la conception de l’application réalisée à chaque sprint à l’aide
de quelques diagrammes de séquence et d’activité des user stories les plus importants.
4.2 Sprint 1
4.2.1 Diagramme de séquence
La figure suivante décrit le scénario d’authentification.Il commence l’lorsque un utilisateur
demande l’accès a l’application :
Chapitre 4 : Conception
43
Figure 22 : Diagramme séquence objet authentification
La figure suivante décrit le user story ‘ Traitements des fichiers de données BTS ‘, chaque
heurs le serveur ftp envoie des fichiers des données des incidents ainsi la mise à jour des BTS.
le scenario suivant décrit le traitement de ces fichiers :
Figure 23 : Diagramme de séquence de user story traitement des fichiersde données
BTS
Chapitre 4 : Conception
44
4.2.2 Diagramme d’activité :
Le diagramme d'activité permet de modéliser le comportement du système, dont la séquence
des actions et leurs conditions d'exécution. Les actions sont les unités de base du
comportement du système.
La figure suivante résume le processus de traitement des fichiers de données BTS.
Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS
4.3 Sprint 2
4.3.1 Diagramme de séquence
Ce scénario est décrit par la figure suivante il commence lorsque l’utilisateur demande la
carte des sites 2G. En effet l’utilisateur a le choix de la géolocalisation les sites selon plusieurs
critères.
Chapitre 4 : Conception
45
Figure 25 : Diagramme séquence objet Map 2G
4.3.2 Diagramme d’activité :
Le processus de création de Géolocalisation des sites BTS peut être résumé dans le diagramme
d’activités suivant :
Chapitre 4 : Conception
46
Figure 26: Diagramme d'activité « Géolocalisation des sites BTS »
4.4 Sprint 3
4.4.1 Diagramme de séquence
Le scénario suivant décrit le user story « géolocalisation des incident » par la figure suivante
d’après ce dernier on peut géolocaliser les incident ainsi les sites hors service a chaque
moment données et définit les KPI des sites voisinage.
Chapitre 4 : Conception
47
Figure 27 : Diagramme séquence géolocalisation des incidents
Chapitre 4 : Conception
48
Le scénario suivant décrit les étapes à suivre pour afficher la courbe de l’Availibility 2G
ainsi les déférentes actions qui peuvent les établir.
Figure 28 : diagramme de séquence « l’Availibility 2G »
4.4.2 Diagramme d’activité
Le diagramme d’activité suivant représente le scenario relatif au user story « géolocalisation
des incident »
Chapitre 4 : Conception
49
Figure 29 : Diagramme d'activité « géolocalisation des incidents »
4.5 Sprint 4
4.5.1 Diagramme de séquence
Le scénario suivant décrit les étapes à suivre pour ajouter un utilisateur après les vérifications
des champs de formulaire qu'on doit remplir. Nous vérifions au niveau de base de données
l’unicité de cet utilisateur.
Figure 30 : Diagramme de séquence « ajouter utilisateur »
Chapitre 4 : Conception
50
4.5.2 Diagramme d’activité
Le diagramme d’activité suivant représente le scenario relatif cas d’utilisation « ajouter
utilisateurs »
Figure 31: Diagramme d'activité « ajouter utilisateurs »
4.6 Diagramme de classes
L'approche objet prône le rapprochement des données et des opérations dans une seule entité :
l'objet. Les traitements sont ainsi répartis entre les déférents objets qui incarnent les données
manipulées par le programme.
Le concept des objets est fondamental dans l'approche objet. Les objets sont des entités
atomiques formées par l'union d'un état et d'un comportement et qui communiquent par
échange de messages. Afin de réduire la complexité des objets du monde réel, la notion
d'abstraction a permis de regrouper les objets en classes. Parmi les relations les plus
importantes entre les classes, les associations (relations sémantiques bidirectionnelles) et
l'héritage. Les classes et leurs relations sont regroupées dans un diagramme (diagramme de
classes) représentant une vue statique des interactions entre les objets.
Chapitre 4 : Conception
51
Figure 32:Diagramme de classe
Conclusion
Nous finissons ainsi l'étape de conception, élaborée dans ce chapitre et dans laquelle nous
avons préparé tout ce qu'il fallait pour présenter et réaliser cette application. La réalisation est
Le sujet du chapitre suivant
Chapitre 5 : Réalisation
52
Chapitre 5
Réalisation
Chapitre 5 : Réalisation
53
Introduction
Cette partie contient le dernier volet de ce rapport, elle a pour objectif d’exposer le travail
achevé. Nous allons commencer, tout d’abord, par la présentation de l’environnement
matériel et logiciel utilisé pour développer l’application demandée. Ensuite, nous présentons
le travail accompli tout au long de la période du stage. Enfin, nous montrons
le chronogramme de la réalisation du projet.
1 Environnement de travail
Nous présentons dans cette section l’environnement matériel ainsi que celui logiciel utilisés
pour le développement de notre application.
1.1 Environnement matériel
Un PC avec les configurations suivantes :
 un processeur Intel Core I5
 une RAM de 4 Go.
1.2 Environnement logiciel
Le long de la phase de développement, nous avons utilisé l’environnement logiciel suivant :
– Système d’exploitation : Microsoft Windows Seven pour la PC de développement.
Linux fedora Serveur de Tunisiana ou le déploiement de l’application.
– Outils de développement : Eclipse 3.7
– Serveur d’application : JBoss AS 7.1.1
– MySQL Server 5 : utilisé pour la gestion de la base de données.
– Paradigm for UML 10.1 et ArgoUML : pour la conception UML.
2 Choix techniques
Dans cette partie, nous justifions les choix techniques du langage de programmation, de la
plateforme de développement et des frameworks utilisés.
2.1 Choix du standard de développement
Java EE 6 est une version importante. Non seulement elle marche dans les pas de Java EE 5
pour fournir un modèle de développement simplifie, mais elle ajoute également de nouvelles
spécifications et apporte des profils et de l’élagage pour alléger ce modèle. La sortie de Java
EE 6 coïncide avec le dixième anniversaire de la plate-forme entreprise : elle combine donc
les avantages du langage Java avec l’expérience accumulée au cours de ces dix dernières
Chapitre 5 : Réalisation
54
années. En outre, elle tire profit du dynamisme de la communauté open-source et de la rigueur
du JCP. Désormais, Java EE est une plate-forme bien documentée, avec des développeurs
expérimentes, une communauté d’utilisateurs importante et de nombreuses applications
déployées sur les serveurs d’entreprises. C’est un ensemble d’API permettant de construire
des applications multi-tiers reposant sur des composants logiciels standard ; ces composants
sont déployés dans différents conteneurs offrant un ensemble de services.
2.2 Choix du Framework pour la couche de présentation
JSF2.0 (Java Server Faces) permet de développer des application web en bénéficiant des
concepts déjà approuvés par Java et Java EE composants graphiques Swing, JSP, Servelts,
JSTL…)et par les apports d’autres Framework Open source tel que Struts.
JSF est un standard, donc est supporté par l’industrie. Face à la multitude des frameworks
MVC (Model-View-Controller) disponibles sur le marché, il s’agit là d’un argument non
négligeable.JSF apporte plusieurs fonctionnalités destinées à résoudre les problèmes inhérents
à la programmation web. JSF se compose d’un ensemble d’API fournissant notamment :
 Une séparation entre la couche présentation et les autres couches
 Une librairie de composants graphiques
 La navigation entre pages
 Le traitement des formulaires et leur validation
JSF ne remplace pas les autres technologies web, il les utilise et les complète. Son architecture
est basée sur le design pattern MVC. Pour rendre le développement d’une application web
plus modulaire et plus souple, JSF décore le tous ces éléments (traitement, présentation,
navigation) et enrichit le pattern MVC. Le modèle est toujours représenté par les Entity
Beans. Le contrôleur intercepte les requêtes http, la navigation entre les pages web est
configurable par un fichier XML dit faces-config.xml
Chapitre 5 : Réalisation
55
Figure 33 : JSF
2.3 EJB3.1
Figure 34 : EJB3.1
Chapitre 5 : Réalisation
56
Au sein d'une architecture Java EE, les EJB sont utilisés pour créer les services. Cette
technologie ne s'arrête cependant pas à cette couche, mais permet aussi de créer l'abstraction
de l'accès aux données. Ce sont les entités qui remplissent cette fonction.
Tout comme les beans sessions, entre le client et le logique métier, les beans entités forment
la passerelle entre la logique applicative et les sources de données. Ils offrent une abstraction
quasi complète du stockage des données, permettant à l'application de rendre persistantes ou
de charger des données de manière totalement transparente.
2.4 Choix du conteneur de la couche de persistance de données
Depuis les débuts de J2EE, le modèle de persistance ne cesse d’évoluer et de s’engluer de
version en version. Les entity beans 1.0 ont été complètement ré architecturés pour laisser
place aux entity beans 2.1. Bien que cette évolution ait apporté beaucoup d’améliorations, ce
modèle de composants persistants continuait à faire des détracteurs parmi la communauté.
Ce mécontentement a donné naissance à une nouvelle spécification (JDO, Java Data Object)
ainsi qu’à différents outils de mapping objet/relationnel payants ou libres (Top Link,
Hibernante...). Java EE 5, et son lot de nouveautés, nous apporte un nouveau modèle de
persistance : JPA (Java Persistence API). Fortement inspirés par des outils Open Source tels
qu’Hibernante ou par JDO, le mapping objet/relationnel et le langage de requête sont
totalement différents de l’ancêtre entity bean 2.1. JPA, ou JSR-220, réconcilie ainsi les
utilisateurs de la plate-forme JEE avec les composants persistants. Java Persistent API
s’appuie sur JDBC pour communiquer avec la base de données. En revanche, grâce à
l’abstraction apportée par JPA, nous n’aurons nul besoin d’utiliser directement JDBC dans le
code Java.
La couche [dao] dialogue maintenant avec la spécification JPA, un ensemble d'interfaces. Le
développeur y a gagné en standardisation. Avant, s'il changeait sa couche ORM, il devait
également changer sa couche [dao] qui avait été écrite pour dialoguer avec un ORM
spécifique. Maintenant, il va écrire une couche [dao] qui va dialoguer avec une couche JPA.
Quelque soit le produit qui implémente celle-ci, l'interface de la couche JPA présentée à la
couche [dao] reste la même.
Dans notre projet la spécification JPA a été implémentée par le produit Hibernate.
Chapitre 5 : Réalisation
57
Figure 35 : Architecture de la spécification JPA
2.5 Choix du SGBD MySQL
Notre application ne dispose pas d’un grand volume de données à gérer, donc MYSQL suffira
comme étant une solution open source. En plus ce SGBD est le serveur de base de données le
plus utilisé dans le monde. Son architecture logicielle le rend extrêmement rapide et facile à
personnaliser. Il faut aussi noter sa rapidité, sa robustesse, et sa facilité d’utilisation et
d’administration. Enfin sa documentation complète et bien construite
2.6 Choix du serveur d’application JBOSS AS 7.1 :
Alors que Tomcat est un conteneur web, JBOSS est un serveur d'applications qui embarque
Tomcat (ou un équivalent) et qui propose en plus un hébergeur des EJB, des transactions, de
la persistance...
Côté performance, administration et connecteurs sont des raisons à considérer pour justifier le
choix d’un serveur d'applications fiable.
Tomcat est largement utilisé car c’est plus "léger" (empreinte mémoire, temps de
démarrage...). Ceci dit, les serveurs d'applications en général font des progrès dans ce coté là.
Avec l'arrivée dans les entreprises de Java EE 6, il y a un réel regain d'intérêt pour les
serveurs d'application.
JBOSS est le nom du serveur d'applications Open Source Java 6, il est entièrement écrit en
Java.
3 Phase d’implémentation
Les interfaces Homme/Machine constituent un élément important dans la réussite d’une
application. Cette contribution est d’autant plus importante lorsqu’il s’agit d’une application
Web. Ces interfaces doivent obéir à des chartes graphiques et aux règles d’ergonomie pour
que l’utilisateur s’adapte le plus rapidement possible à la logique de l’application.
Afin d’atteindre ces objectifs, nous avons choisi d’adopter un style commun pour toutes les
interfaces à l’aide d’une feuille de style.
Chapitre 5 : Réalisation
58
3.1 Géolocalisation site 2G
Figure 36 : MAP 2G
Description :
Nous utilisons le Technique de localisations Global Positioning System(GPS) pour obtenir
cette interface qui permet à l’utilisateur d’avoir une vue globale sur le réseau 2G de
Tunisiana ainsi la géolocalisation des sites 2G. Cette résultat c’est la récolte de traitement des
fichiers BTS sous format Excel ce derniers contient plus que seize mille ligne ainsi
l’enregistré dans la base de données a fin de les affichées sur l’API de google MAPS.
3.2 Géolocalisation site 3G
Figure 37 : MAP 3G
Chapitre 5 : Réalisation
59
Description :
Il s’agit de la même interface de géolocalosation 2G mais pour le cas de 3G.
3.2.1 Recherche par lac
Figure 38 : Recherche par LAC
Description :
L’exemple présenté par la figure 38 montre l’affichage d’un ensemble des sites qui sont de
même local area code (LAC) 1119.
3.2.2 L'Availability 2G RAN :
Figure 39: courbe 2G RAN
Chapitre 5 : Réalisation
60
Description :
Cette interface permette à l’utilisateur d’avoir une vue globale sur les performances du
réseau de Tunisiana. En effet Cette courbe est la résulta de la formule suivante :
3.3 Géolocalisation des Site HS
Figure 40: géolocalisation des incidents
Description :
Notre application est basée sur la récupération les fichiers incidents sur un serveur FTP.
Après le traitement de ces fichiers par la technologie EJB Timer nous obtenons cette interface
d’où via ce dernier l’utilisateur est capable de visualiser l’ensemble de site hors service (HS)
ainsi de déterminer la cause de l’incident.
Figure 41 : Exemple de fichiers incidents
Chapitre 5 : Réalisation
61
3.4 Affichage des sites en voisinage d’un site HS
Figure 42 : voisinage d'un incident
Description :
Cette Interface permet de définir les voisinages des sites HS ainsi leur KPI. Après le choix de
distance de voisinage ou par LAC d’un site HS un ensemble des sites sera affiché sur la carte
chaque de ces site on peut présenter ces KPI et déterminer si il y a un impacte sur cette suite à
la dysfonction de ce site ou non.
Figure 43 : Voisinage Site HS par LAC
Chapitre 5 : Réalisation
62
3.5 Test
La phase de test est l’une des plus coûteuses et des plus importantes pour un cycle de vie d’un
logiciel. A la fin de cette phase qu’on peut juger la qualité d’un logiciel. Dans notre projet on
a mené les tests suivants :
Les tests unitaires qui sont faits par le programmeur afin que chaque module puisse
fonctionner sans erreur de programmation.
Le test du système afin de vérifier si le logiciel fonctionne sur la machine cible (avec les
logiciels et matériel du client).
Le test de validation qui est fait par le client pour vérifier le niveau de qualité : c’est un test
assez lourd pour adopter le logiciel aux attentes de client.
4 Chronogramme de réalisation
Le diagramme de GANTT est un outil permettant de modéliser la planification de tâches
nécessaires à la réalisation d'un projet dans le temps.
Figure 44 : Chronogramme de Réalisation
Conclusion
Au cours de ce dernier chapitre nous avons précisé notre choix technique et montré quelques
interfaces de notre application. A la fin nous avons présenté notre chronogramme modélisant
les étapes de notre travail. A présent nous passerons dans la partie suivante à la conclusion
globale de notre projet.
63
Conclusion et Perspective
Aujourd’hui, le souci majeur des opérateurs de téléphonie mobile consiste à assurer une
qualité de service suffisamment bonne afin de permettre le bon fonctionnement des services
offerts à leurs abonnés. La nécessité d’améliorer le service rendu au niveau des réseaux
mobiles s’est largement manifestée. Ainsi, l’utilisation des techniques d’optimisation
appropriées est essentielle afin de qualifier les performances de réseaux.
Le but principal de ce projet était de créer une plateforme qui facilite la tâche de suivi et de
monitoring de la qualité de service de l'opérateur Tunisiana. Ce travail a suivi plusieurs étapes
qui ont été très importantes pour la phase de réalisation et le développement. La première
étape était de mettre le sujet dans son contexte général, ce qui a permis de dégager les
différentes besoins dont l'application est chargée d'y répondre. Ces besoins ont été bien traités
et analysés dans la phase de spécification.
L'étape suivante, était la conception, durant toute cette phase, une étude globale et détaillée
des fonctionnalités du système était réalisée à l'aide de langage de modélisation UML pour
aboutir enfin à l'application opérateur qui vise à aider l'opérateur à améliorer la qualité de
service offert.
Ce projet présente une occasion pour s'améliorer dans le développement Java/Jee sur plusieurs
niveaux appliquées les nouvelle technologie JEE6, communication client/serveur,
communication réseaux avec les serveurs FTP, conception et interaction avec les bases de
données, aussi, il m'a permis d'acquérir des connaissances importantes surtout au niveau de la
qualité de service des réseaux mobiles 2 G et 3 G. Le travail présenté répond au cahier de
charge déjà posé, mais il ne représente pas la version finale qu'on peut atteindre. En effet, ce
travail peut s'améliorer certainement dans le futur, avec des nouvelles idées.
Enfin, l’application que nous avons développée pourrait être enrichie par des fonctionnalités
avancées telles que l’intégration d’partie mobile.
Pour conclure, ce stage était très important, dans la mesure où il m'a permis d'appliquer mes
connaissances acquises lors de mon cursus éducatifs et des maitriser des nouvelles
technologies de développement. Finalement, il était une occasion pour s'introduire et
s'intégrer dans le milieu professionnel.
64
Bibliographie
[1] Pierre Lescuyer UMTS Les origines, l’architecture, la norme
[2] Jean CELLMER, « Réseaux cellulaires, Système GSM»
[3] Michel Thériault, "Étude des performances d’un système DS-CDMA avec récepteur Rake
dans le contexte UWB".
[4] http://www-igm.univ-mlv.fr/~dr/XPOSE2006/eric_meurisse/umts.php
[5] Thierry Lucidarme, "Principes de radiocommunication de troisième génération",
Vuilbert,Paris, 2002
[6] T. Okumura, E. Ohmor, and K. Fukada, "Field Strength and its variability in VHF and
UHF Land mobile Service", Review Electrical Communication Laboratory, pp. 825-873,
1968
[7] J. Walfisch and H. Bertoni, "A theoretical model of UHFpropagation in urban
environment", IEEE Transactions on antennas and propagation, vol. 36, pp. 1788-1796,
December 1988
[8] Maciej J. Nawrocki, Mischa Dohler and A. Hamid Aghvami, "Understanding UMTS
Radio network"
65
Acronymes
0-9
1G First Generation of wireless communication technology
2G Second Generation of wireless communication technology
3G Third Generation of wireless communication technology
A
API Application Programming Interface
B
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
C
Cell ID CDMA CN
E
EDGE
F
FDD FTP
G
GPRS GSM
H
HSPA HSDPA
J
JVM J2EE
Cellule Identity
Code Division Multiple Access Core Network
66
Frequency Division Duplex File Transfert Protocol
Global System for Mobile communication
High-Speed Packet Access High-Speed Downlink Packet Access
Java Virtuel Machine Java2 Enterprise Edition
LAC Location Area code
M
MCC Mobile Country Code
MMS Multimedia Message Service Mobile Network Code
MSC Mobile Switching Center
N
NSS Network and Switching Subsystem
O
OSS Operation and Support Subsystem
Q
QoS Quality of Service
R
RAN Radio Access Network
T
TDD TDMA
U
UMTS UTRAN
Time Division Multiple Access
Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network
W
W-CDMA Wideband Code Division Multiple Access
67
Annexe A : JBOSS AS 7
JBoss Application Server est un serveur d'applications J2EE libre entièrement écrit en Java.
Les développeurs du cœur de JBoss ont tous été employés par une société de services appelée
« JBoss Inc. ». Le projet est sponsorisé par un réseau mondial de partenaires et utilise un
business model fondé sur le service. En effet, JBoss est maintenu par le Groupe JBoss
gratuitement, mais toute customisation et tous services consultants sont facturés. Ce groupe
est une division de RedHat depuis avril 2006. La DGI (Direction Générale des Impôts) utilise
JBoss.
JBoss est similaire à Weblogic de BEA ou à WebSphere d’IBM dans sa complexité.
Compatible avec les standards :
• CORBA OTS (Object Transaction Service),
• JTA/JTS (Java API Transaction/Service),
• WebServices
Caractéristiques :
• Supporte les Sun JDK 1.6 et 1.7
• Version 5as 7est en passe d’être certifiée 1.7
• Clustering: Failover (including sessions) / Load balancing
• Distributed caching (using JBoss Cache, a standalone product)
• Distributed deployment (farming)
• Deployment API
• Management API
• Aspect-Oriented Programming (AOP)-support
• JSP/Servlet 2.1/2.5 (Tomcat)
68
• JavaServer Faces 2.1 (Mojarra)
• Enterprise Java Beans version 3 and 3.1
• JNDI (Java Naming and Directory Interface)
• Hibernate-integration (for persistence programming; JPA)
• JDBC
• JTA (Java Transaction API)
• Support for Java EE-Web Services like JAX-RPC (Java API for XML for Remote Procedure
Call), JAX-WS, JAXB
• SAAJ (soap with Attachments API for Java)
• JMS (Java Message Service) integration / JavaMail
• RMI-IIOP (JacORB, alias Java and CORBA)
• JAAS (Java Authentication and Authorization Service)
• JCA (Java Connector Architecture)-integration
• JACC (Java Authorization Contract for Containers)-integration
• Java Management Extensions
Figure 45 : JBOSS AS7
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

Contenu connexe

Tendances

Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
Donia Hammami
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
Oussama Djerba
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
JinenAbdelhak
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
slim Hannachi
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
ALALSYSE
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
Mohamed Boubaya
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
jihene Ab
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Mohamed Amine Mahmoudi
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
YounessLaaouane
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Ahmed Makni
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
Amine MEGDICHE
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Arnold Stellio
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI
 

Tendances (20)

Pfe 2015
Pfe 2015Pfe 2015
Pfe 2015
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 

Similaire à pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

Rapport finale
Rapport finaleRapport finale
Rapport finale
Hassen BEN SLIMA
 
Bureau virtuel
Bureau virtuelBureau virtuel
Bureau virtuel
raymen87
 
Chronemics and Caring in the Nurse Client Interaction
Chronemics and Caring in the Nurse Client InteractionChronemics and Caring in the Nurse Client Interaction
Chronemics and Caring in the Nurse Client Interaction
Glance Ruiz
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
Mohamed Arar
 
4.1 règlement - projet arrêté
4.1  règlement - projet arrêté4.1  règlement - projet arrêté
4.1 règlement - projet arrêté
Orgerus Mairie
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
Codendi
 
Rapport atef
Rapport atefRapport atef
Rapport atef
Atef Kouiri
 
Importation TADIMCA en belgique
Importation TADIMCA en belgiqueImportation TADIMCA en belgique
Importation TADIMCA en belgique
Necdet Cagpar
 
Maroc codetravail-111206050140-phpapp02
Maroc codetravail-111206050140-phpapp02Maroc codetravail-111206050140-phpapp02
Maroc codetravail-111206050140-phpapp02
Imane Labriki
 
Maroc code travail
Maroc   code travailMaroc   code travail
Maroc code travail
yahsimoc
 
Luxembourg chiffres
Luxembourg chiffresLuxembourg chiffres
Luxembourg chiffres
Paperjam_redaction
 
Statec lux en_chiffres_2021_fr
Statec lux en_chiffres_2021_frStatec lux en_chiffres_2021_fr
Statec lux en_chiffres_2021_fr
NicolasLonard3
 
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
CLES-FACIL
 

Similaire à pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana (20)

Verre
VerreVerre
Verre
 
Charte aeenap
Charte aeenapCharte aeenap
Charte aeenap
 
Rapport finale
Rapport finaleRapport finale
Rapport finale
 
Bureau virtuel
Bureau virtuelBureau virtuel
Bureau virtuel
 
Tutorial Autocad 2006 2D
Tutorial Autocad 2006 2DTutorial Autocad 2006 2D
Tutorial Autocad 2006 2D
 
Chronemics and Caring in the Nurse Client Interaction
Chronemics and Caring in the Nurse Client InteractionChronemics and Caring in the Nurse Client Interaction
Chronemics and Caring in the Nurse Client Interaction
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
4.1 règlement - projet arrêté
4.1  règlement - projet arrêté4.1  règlement - projet arrêté
4.1 règlement - projet arrêté
 
Manuel 3
Manuel 3Manuel 3
Manuel 3
 
Manuel 3
Manuel 3Manuel 3
Manuel 3
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Rapport atef
Rapport atefRapport atef
Rapport atef
 
Importation TADIMCA en belgique
Importation TADIMCA en belgiqueImportation TADIMCA en belgique
Importation TADIMCA en belgique
 
TCE2-Maroc code travail
TCE2-Maroc code travailTCE2-Maroc code travail
TCE2-Maroc code travail
 
Maroc codetravail-111206050140-phpapp02
Maroc codetravail-111206050140-phpapp02Maroc codetravail-111206050140-phpapp02
Maroc codetravail-111206050140-phpapp02
 
Maroc code travail
Maroc   code travailMaroc   code travail
Maroc code travail
 
Luxembourg chiffres
Luxembourg chiffresLuxembourg chiffres
Luxembourg chiffres
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Statec lux en_chiffres_2021_fr
Statec lux en_chiffres_2021_frStatec lux en_chiffres_2021_fr
Statec lux en_chiffres_2021_fr
 
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
 

pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

  • 1. TABLE DES MATIÈRES Liste des figures .................................................................................................................................................................... i Liste des tableaux.................................................................................................................................................................ii Introduction Générale .......................................................................................................................................................... 1 Chapitre 1 Présentation du cadre de travail et du sujet....................................................................................................... 2 Introduction.......................................................................................................................................................................... 3 1 Cadre du projet........................................................................................................................................................... 3 1.1 Présentation de l’entreprise............................................................................................................................... 3 1.2 Rôle de la Division Supervision ....................................................................................................................... 4 1.3 Le concept « Incident »..................................................................................................................................... 5 2 Présentation de sujet :................................................................................................................................................. 6 3 Conduite du projet...................................................................................................................................................... 6 3.1 Processus de développement............................................................................................................................. 6 3.2 Méthodologie Agile.......................................................................................................................................... 7 3.3 Scrum................................................................................................................................................................ 8 Conclusion ......................................................................................................................................................................... 13 Chapitre 2 Etat de l'Art des Réseaux Cellulaires............................................................................................................... 14 Introduction........................................................................................................................................................................ 15 1 Concept Cellulaire.................................................................................................................................................... 15 2 Evolution des réseaux cellulaires.............................................................................................................................. 16 2.1 Norme GSM ................................................................................................................................................... 16 2.2 Le standard GPRS........................................................................................................................................... 19 2.3 Téléphonie à mode paquet à haut débit : UMTS............................................................................................. 21 2.4 HSPDA........................................................................................................................................................... 23 2.5 HSUPA........................................................................................................................................................... 23 3 Concept de la qualité de service ............................................................................................................................... 23 3.1 Définition........................................................................................................................................................ 23 3.2 Critères de performances des réseaux 2G/3G ................................................................................................. 23 Conclusion ......................................................................................................................................................................... 25 Chapitre 3 Analyse des Besoins et Spécifications .............................................................................................................. 26 Introduction........................................................................................................................................................................ 27 1 Objectifs ................................................................................................................................................................... 27 2 Spécification des exigences...................................................................................................................................... 27 2.1 Les acteurs système ........................................................................................................................................ 27 2.2 Le Backlog du produit :.................................................................................................................................. 28 2.3 Diagramme des cas d’utilisation globale : ...................................................................................................... 29 2.4 Sprint .............................................................................................................................................................. 29 2.5 Besoins Non Fonctionnels .............................................................................................................................. 39 Conclusion ......................................................................................................................................................................... 39 Chapitre 4 Conception....................................................................................................................................................... 40
  • 2. Introduction........................................................................................................................................................................ 41 3 Architecture du système : Modèle multi couches ..................................................................................................... 41 4 Conception ............................................................................................................................................................... 42 4.1 Conception détaillé......................................................................................................................................... 42 4.2 Sprint 1 ........................................................................................................................................................... 42 4.3 Sprint 2 ........................................................................................................................................................... 44 4.4 Sprint 3 ........................................................................................................................................................... 46 4.5 Sprint 4 ........................................................................................................................................................... 49 4.6 Diagramme de classes..................................................................................................................................... 50 Conclusion ......................................................................................................................................................................... 51 Chapitre 5 Réalisation ....................................................................................................................................................... 52 Introduction........................................................................................................................................................................ 53 1 Environnement de travail ......................................................................................................................................... 53 1.1 Environnement matériel.................................................................................................................................. 53 1.2 Environnement logiciel................................................................................................................................... 53 2 Choix techniques...................................................................................................................................................... 53 2.1 Choix du standard de développement ............................................................................................................. 53 2.2 Choix du Framework pour la couche de présentation..................................................................................... 54 2.3 EJB3.1 ............................................................................................................................................................ 55 2.4 Choix du conteneur de la couche de persistance de données .......................................................................... 56 2.5 Choix du SGBD MySQL................................................................................................................................ 57 2.6 Choix du serveur d’application JBOSS AS 7.1 : ............................................................................................ 57 3 Phase d’implémentation ........................................................................................................................................... 57 3.1 Géolocalisation site 2G................................................................................................................................... 58 3.2 Géolocalisation site 3G................................................................................................................................... 58 3.3 Géolocalisation des Site HS............................................................................................................................ 60 3.4 Affichage des sites en voisinage d’un site HS ............................................................................................... 61 3.5 Test ................................................................................................................................................................. 62 4 Chronogramme de réalisation................................................................................................................................... 62 Conclusion ......................................................................................................................................................................... 62 Conclusion et Perspective ................................................................................................................................................. 63 Bibliographie...................................................................................................................................................................... 64 Acronymes......................................................................................................................................................................... 65 Annexe A : JBOSS AS 7.................................................................................................................................................... 67 Annexe B : La technologie AJAX...................................................................................................................................... 69
  • 3. i Liste des figures Figure 1 : Organisation de la division Supervision au sein de TUNISIANA .................................................... 4 Figure 2:Types d’incidents BTS........................................................................................................................ 6 Figure 3: Méthodologie Agile ........................................................................................................................... 8 Figure 4:Sprint Scrum ....................................................................................................................................... 9 Figure 5 : Processus Scrum ............................................................................................................................. 13 Figure 6 Concept cellulaire ............................................................................................................................. 15 Figure 7 Le Sous-système Radio..................................................................................................................... 16 Figure 8:Le Sous-système d'Acheminement ................................................................................................... 17 Figure 9 : Le Sous-système d'Exploitation et de Maintenance........................................................................ 18 Figure 10 : Architecture du Réseau GPRS ...................................................................................................... 20 Figure 11 : Architecture de l'UMTS................................................................................................................ 21 Figure 12 : UTRAN......................................................................................................................................... 22 Figure 13: diagramme cas d'utilisation globale ............................................................................................... 29 Figure 14 : Diagramme cas d'utilisation traitement des fichiers...................................................................... 31 Figure 15 : Cas d'utlisation de sprint 2 ............................................................................................................ 33 Figure 16 : Cas d'utilisation Déterminer les sites HS ...................................................................................... 35 Figure 17 Afficher Availibility 2G RAN......................................................................................................... 35 Figure 18 Gestion BTS.................................................................................................................................... 37 Figure 19 Cas d'utilisations Afficher cellules................................................................................................. 38 Figure 20 : Cas d'utilisations Gestion Utilisateur ............................................................................................ 38 Figure 21 modèle MVC................................................................................................................................... 41 Figure 22 : Diagramme séquence objet authentification ................................................................................. 43 Figure 23 : Diagramme de séquence de user story traitement des fichiersde données BTS........................... 43 Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS ................................................ 44 Figure 25 : Diagramme séquence objet Map 2G............................................................................................. 45 Figure 26: Diagramme d'activité « Géolocalisation des sites BTS »............................................................... 46 Figure 27 : Diagramme séquence géolocalisation des incidents ..................................................................... 47 Figure 28 : diagramme de séquence « l’Availibility 2G »............................................................................... 48 Figure 29 : Diagramme d'activité « géolocalisation des incidents »................................................................ 49 Figure 30 : Diagramme de séquence « ajouter utilisateur »............................................................................. 49 Figure 31: Diagramme d'activité « ajouter utilisateurs »................................................................................ 50 Figure 32:Diagramme de classe ...................................................................................................................... 51 Figure 33 : JSF ................................................................................................................................................ 55 Figure 34 EJB3.1............................................................................................................................................. 55 Figure 35 : Architecture de la spécification JPA ............................................................................................. 57 Figure 36 : MAP 2G........................................................................................................................................ 58 Figure 37 : MAP 3G........................................................................................................................................ 58 Figure 38 Recherche par LAC......................................................................................................................... 59 Figure 39: courbe 2G RAN ............................................................................................................................. 59 Figure 40: géo localisation des incidents......................................................................................................... 60 Figure 41 : Exemple de fichiers incidents ....................................................................................................... 60 Figure 42 : voisinage d'un incident.................................................................................................................. 61 Figure 43 : Chronogramme de Réalisation...................................................................................................... 62
  • 4. ii Liste des tableaux Tableau 1: Les seuils des KPIs........................................................................................................................ 25 Tableau 2 Tableau 1 Backlog du Produit ........................................................................................................ 28 Tableau 3: user story traitements des fichiers de données BTS....................................................................... 30 Tableau 4 : User Story Traitements des fichiers des incidents ........................................................................ 30 Tableau 5:user story Géo-localisation des sites BTS....................................................................................... 31 Tableau 6:User Story “rechercher site ” .......................................................................................................... 32 Tableau 7 : User Story “Afficher les voisinage ” ............................................................................................ 32 Tableau 8:User Story “geolocalisation des incident ” ..................................................................................... 34 Tableau 9:User Story “ KPI du réseau ”........................................................................................................ 34 Tableau 10: User Story “Availibilite 2G/3G RAN ” ..................................................................................... 34 Tableau 11: User Story gestion des cellules.................................................................................................... 36 Tableau 12: User Story gestion des Utilisateurs.............................................................................................. 36 Tableau 13: User Story gestion des BTS......................................................................................................... 37
  • 5. 1 Introduction Générale Les réseaux mobiles ont connu un large succès avec l’apparition de la norme de deuxième génération qui a permis essentiellement d’obtenir une meilleure qualité de voix. Afin de permettre la création de nouveaux services et d’offrir aux usagers une véritable itinérance à l’échelle mondiale, il était devenu nécessaire d’effectuer un saut technologique et de franchir le pas vers les réseaux cellulaires de troisième et de quatrième génération. Il s'avère donc que la qualité de service, dans ce domaine comme dans beaucoup d'autres, constitue une source fondamentale de différenciation, aussi déterminante que le prix du service fourni ou l'étendue de la couverture. Le maintien et le suivi de cette qualité nécessitent le contrôle continu de l'état de fonctionnement du réseau et de toutes les performances réalisées et par conséquent, l'intérêt d'outils d'ingénierie adaptés. L’un des moyens de contrôle et de supervision qui s’offrent aux opérateurs téléphoniques est l’utilisation d’outils ou applications qui rendraient facile la gestion des équipements constituant leurs réseaux, entre autres les équipements BTS dont le contrôle ainsi la gestion des incidents est le sujet de ce projet. C’est dans cet ordre d’idées que s’inscrit ce projet de fin d'études qui a pour objectif la conception et la réalisation d’un portail web pour l’évaluation des performances du réseau de l’opérateur Tunisiana. Le présent rapport se décompose en cinq chapitres, nous présentons le contenu de chaque chapitre. Dans le premier chapitre, nous présentons l'environnement du travail ainsi que le sujet à traiter. Le second chapitre est consacré à la présentation des architectures des réseaux cellulaires tels que GSM, GPRS, et UMTS et les étapes de l'évolution de ces réseaux. Nous traitons aussi dans ce chapitre le concept et les critères de la qualité de service (QoS). Le troisième chapitre traite l’analyse des besoins et des spécifications de l’application à développer. La conception globale et détaillée de l’outil que nous avons réalisé fait l’objet du quatrième chapitre .Enfin, le dernier chapitre de ce rapport illustrera les réalisations effectuées au cours de ce projet.
  • 6. Chapitre 1 : Présentation du cadre de travail et du sujet 2 Chapitre 1 Présentation du cadre de travail et du sujet
  • 7. Chapitre 1 : Présentation du cadre de travail et du sujet 3 Introduction Avant de traiter le sujet du présent projet de fin d’études, il convient de présenter l’environnement dans lequel il a été mené à bien. En effet, c’est de l’environnement que dépend, en grande partie, l’efficacité et la qualité d’un travail. Nous avons effectué notre projet de fin d’études au sein de l’entreprise TUNISIANA premier opérateur privé de télécommunications en Tunisie. 1 Cadre du projet 1.1 Présentation de l’entreprise Orascom Telecom a octroyé, le 11 mai 2002, la deuxième licence de téléphonie mobile en Tunisie (OTT) et devient ainsi le premier operateur GSM privé en Tunisie. Cette licence a permis la mise en place d’un réseau de transmission GSM et d’une passerelle internationale, d’une durée de quinze ans, renouvelable deux fois tous les cinq ans et une exclusivité jusqu’au 30 juin 2004. Ainsi TUNISIANA a réalisé son lancement commercial le 27 décembre 2002 pour atteindre jusqu’à aujourd’hui 100% de couverture de la population Tunisienne. Depuis son lancement, grâce à la qualité des ressources humaines et aux performances techniques qui ne sont plus à démontrer et une qualité du réseau reconnue à l’échelle nationale et internationale, Tunisiana a su arracher la première place sur le marché Tunisien et devenir ainsi fin 2010 le leader National en GSM avec presque 52% de part de marché. Tunisisana a pour objectifs de :  Satisfaire sa clientèle en assurant un bon niveau de service.  Maximiser et maintenir les objectifs en termes de parts de marché sur la base d’un programme à trois dimensions : Acquisition, Fidélisation, Consommation. TUNISIANA est une entreprise en plein essor, l’hiérarchie interne est conçue pour faciliter les promotions et garantir ainsi un maximum de motivation pour le personnel. La Division Supervision dans laquelle nous avons effectué notre Projet est ainsi conçue comme suit :
  • 8. Chapitre 1 : Présentation du cadre de travail et du sujet 4 Division Supervision Service supervision front Office Service supervision back Office Figure 1 : Organisation de la division Supervision au sein de TUNISIANA 1.2 Rôle de la Division Supervision Le service supervision Back Office se charge de détecter les dysfonctionnements qui n’ont pas un impact direct ou immédiat, majeur ou critique sur la qualité de service offerte au client. Les tâches principales consistent à :  faire des statistiques quotidiennes, hebdomadaires ou mensuelles sur les différents équipements BSS  identifier les quels est défectueux,  alerter les concernés,  suivre les problèmes récurrents impactant le client. Comme son nom l’indique, le service Front Office a la charge :  détecter immédiatement les incidents majeurs et critiques, les classifier par criticité.  identifier l’impact.  alerter les concernés, support niveau 1 et escalade en cas de besoin. Les incidents traités sont ceux qui ont un impact direct sur la qualité de service offerte.
  • 9. Chapitre 1 : Présentation du cadre de travail et du sujet 5 1.3 Le concept « Incident » Apres sept ans et plus depuis son lancement commercial, TUNISIANA est devenue mature en terme de prestataire de service de téléphonie mobile, la clientèle est devenu assez grande et diversifiée, l’environnement est de plus en plus concurrentiel avec l’arrivée d’un troisième opérateur sur le marché, en plus l’abonné est devenu de plus en plus exigeant. Tous ces facteurs obligent Tunisiana à être compétitive, innovatrice et surtout très vigilante concernant l’état de son réseau. Pour garder son image de marque, elle est appelée à superviser tout son réseau en temps réel ainsi que tous ses services et promotions. Donc, si on se réfère au service front Office, un incident est un événement qui peut provoquer un dysfonctionnement ou qui a un impact immédiat sur le client pour pouvoir gérer les incidents il est primordial d’implémenter tout un processus de détection, d’investigation, d’alerte, de support niveau 1, et d’enregistrement dans une Base. Dans ce qui suit on se penchera seulement sur les incidents qui touchent la partie BSS du réseau GSM, c'est-à-dire les BTS et les BSC Les types des incidents :  Système : ce sont des incidents dus à un élément défectueux dans un équipement réseau (carte électronique, capteur, câble…..)  Transmission: Tous les équipements réseau sont connectés les uns par rapport aux autres selon un routage bien spécifique, la mise Hors Service de l’une de ces routes impacte directement un équipement, c’est pour cela que le réseau de transmission est supervisé  Environnement : un incident peut se déclencher par un facteur externe au réseau qui peut être une coupure courant, un facteur climatique, un défaut de climatisation
  • 10. Chapitre 1 : Présentation du cadre de travail et du sujet 6 Figure 2:Types d’incidents BTS 2 Présentation de sujet : Ce projet de fin d’étude porte sur la réalisation d’un outil de suivi de performance du réseau de TUNISIANA et à présenter L’impact de disfonctionnement d’un site sur la QOS de réseaux 2G/3G. 3 Conduite du projet 3.1 Processus de développement Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système existant. Ce processus a pour objectif de produire des solutions informatiques de qualité répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles. De ce fait,
  • 11. Chapitre 1 : Présentation du cadre de travail et du sujet 7 l’adéquation du projet au processus de développement peut largement affecter le sort d’un projet informatique. 3.2 Méthodologie Agile Méthode de développement informatique tournée vers le client. Le développement agile tire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17 personnalités dont Kent Beck, Ward Cunnigham, Martin Fowler ou Dave Thomas. Douze principes ont été définis. Parmi les principaux:  Parvenir à la satisfaction du client par le biais d'un cycle de développement rapide, récurrent et incrémental de versions fonctionnelles;  Se montrer apte à prendre en compte les changements de dernière minute à tout moment du projet;  Mettre en place une coopération quotidienne entre développeurs et décideurs/commerciaux;  Motiver les développeurs par un environnement, un soutien et une confiance solides;  Faire simple, mais pas simpliste;  Laisser l'équipe s'organiser au mieux de ses possibilités. Il existe une dizaine de méthodologies "officielles" s'adaptant chacune à des besoins différents. Certaines sont plus adaptées aux petites équipes, comme Crystal, XP, Scrum, tandis que d'autres sont prévues pour des groupes conséquents, par exemple RAD, RUP et ASD. Nous avons opté pour la méthode de développement agile Scrum, car elle est très adaptée aux projets comme le mien et dont les besoins sont constamment redéfinis.
  • 12. Chapitre 1 : Présentation du cadre de travail et du sujet 8 Figure 3: Méthodologie Agile 3.3 Scrum Davantage qu’une méthode formelle, Scrum peut être vu comme un framework méthodologique – ses fondateurs parlent d’organisationnel pattern – dont l’implémentation doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en œuvre (Scrum, au demeurant, ne limite pas son champ d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité visant à produire un résultat). Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et d’artefacts qui permettent de relever les défis principaux du développement incrémental : la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de ce prisme. Scrum identifie trois acteurs :
  • 13. Chapitre 1 : Présentation du cadre de travail et du sujet 9  le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et est à même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès d’un projet agile. Dans notre cas il s’agit d’Imed Hamza.  le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à s’améliorer constamment. Il est également le garant de la bonne implémentation de Scrum. Dans notre cas il s’agit de Md Jihéne ben Abderazek  l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis comme une borne supérieure), et qui prend en charge le développement du produit (planification, conception, codage, tests, documentation) sans spécialisation des rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les approches managériales traditionnelles, qui privilégient un contrôle centralisé généralement incarné par le Chef de Projet. Dans notre cas il s’agit de moi. L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de 2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification initiale. Le schéma suivant décrit l’articulation générale de Scrum : Figure 4:Sprint Scrum
  • 14. Chapitre 1 : Présentation du cadre de travail et du sujet 10 Scrum définit également trois artefacts :  le Product Backlog,  le Sprint Backlog  le Burndown Chart, qui est une représentation graphique très simple de l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un autre pour la version du produit Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métiers du produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les informations suivantes :  un identifiant – unique, il permet de tracer l’élément quand on le renomme  un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et l’Equipe comprennent approximativement de quoi il est question  l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur relative compte  l’estimation initiale – exprimée en points de complexité, et dont la valeur est déterminée par l’Equipe.  comment faire la démo ? – cela correspond globalement à la spécification d’un test fonctionnel simple.  des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer vers d’autres Le Product Backlog peut également contenir des éléments techniques – mais il est indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de Produit puisse lui affecter une valeur. Il peut être conservé sous différentes formes, la plus fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.Le Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées)
  • 15. Chapitre 1 : Présentation du cadre de travail et du sujet 11 de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et l’estimation initiale peuvent être revues, à la hausse ou à la baisse. Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est durant cette cérémonie que l’estimation fine de la charge de développement de chaque histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet d’une estimation de charge –exprimée en heures ou en jours. Il est important de noter que c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches correspondantes. La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette capacité de production, ou vélocité estimée). Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour son exploitation en production – cette caractéristique est à l’origine du qualificatif « incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet d’une démonstration publique. Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous- tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de l’Equipe, et ne fait pas l’objet de négociations Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits
  • 16. Chapitre 1 : Présentation du cadre de travail et du sujet 12 en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait partie de l’ADN de Scrum (on parle de time boxing). Voici les principales cérémonies préconisées par Scrum :  le Sprint planning, que nous avons déjà abordé  la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes) menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et dont l’objectif est de maintenir chacun au courant de l’activité de tous, de déterminer les tâches de la journée et d’identifier les éventuels obstacles qui ralentissent ou empêchent la progression du sprint la revue de sprint (Sprint Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le caractère incrémental du développement (pour être démontré, le produit doit être utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins d’ajuster le contenu du backlog de produit  la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au terme de chaque sprint afin d’identifier les erreurs commises lors du sprint précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le processus ; la rétrospective est une cérémonie capitale qui incarne l’un des principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers, l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son comportement en conséquence ».
  • 17. Chapitre 1 : Présentation du cadre de travail et du sujet 13 Figure 5 : Processus Scrum Conclusion Dans ce chapitre, nous avons essayé de définir le cadre de notre projet en termes organisationnel et professionnel. Ensuite nous avons présenté la notion d’incident tout en insistant sur l’importance du processus de résolution des incidents. Ainsi le sujet à traiter qui est le développement d’un outil pour le suivi des performances du réseau Tunisiana 2G/3G. A ce stade, on va étudier et présenter les architectures des réseaux 2G /3G et définir aussi les concepts liés à la qualité de service, ce qui fera l'objet du deuxième chapitre
  • 18. Chapitre 2 : Etat de l’art des réseaux cellulaires 14 Chapitre 2 Etat de l'Art des Réseaux Cellulaires
  • 19. Chapitre 2 : Etat de l’art des réseaux cellulaires 15 Introduction Ce chapitre est un état de l'art de la téléphonie radio mobile dans lequel nous présenterons le contexte dans lequel s'inscrit le présent projet afin de pouvoir se focaliser sur les composantes de notre sujet. Nous étudierons successivement les interfaces radio mobiles mises en jeu, ensuite, nous traiterons le concept de qualité de service. 1 Concept Cellulaire Le concept cellulaire constitue le principe de base des réseaux radio mobiles. La zone desservie par un opérateur est divisée en cellules alimentées à partir d'une station de base. Une cellule représente l'ensemble des points du territoire couvert par une même BTS (Base Transceiver Station) et oïl le signal transmis par cette BTS est le plus fort .Chaque cellule est identifiée par un BSIC (Base Station Identity Code). Le mobile est toujours connecté à la BTS la plus proche de point de vue radio. [1] Figure 6 : Concept cellulaire L’utilisation du concept cellulaire permet d'ajuster les ressources radio à la demande en trafic. Le principe se traduit par des zones à forte concentration de BTS couvrant de petites cellules et des zones rurales à faible concentration de BTS couvrant des cellules.
  • 20. Chapitre 2 : Etat de l’art des réseaux cellulaires 16 2 Evolution des réseaux cellulaires 2.1 Norme GSM La norme GSM est un système cellulaire de transmission numérique. Le réseau GSM a pour rôle essentiellement de permettre des communications entre abonnés mobiles (GSM) et abonnés du réseau téléphonique commuté (RTC ou réseau fixe). Le GSM qui a fait une rupture avec les systèmes cellulaires analogiques, utilise les bandes de fréquences 900 MHz 1800 MHz et utilise la technique de multiplexage F-TDMA ce qui offre un multiplexage temporel et fréquentiel à la fois. 2.1.1 Architecture Générale et Equipements Le réseau GSM comporte les 3 sous-ensembles :  Le Sous-système Radio BSS : responsable d'assurer et gérer les transmissions radios. Une station mobile est un terminal de données qui transmet et reçoit des messages du réseau. La «Base Transceiver Station» ou (BTS)»représente l'ensemble d'émetteurs et de récepteurs fixes. Elle a pour rôle d'échanger des messages avec les stations mobiles présentes dans la cellule qu'elle contrôle. Nous trouvons aussi le contrôleur de station de base nommé «Base Station Controller » ou (BSC). Il communique avec une ou plusieurs BTS. Figure 7 Le Sous-système Radio Le Sous-système Réseau NSS : comporte l'ensemble des fonctions nécessaires pour les appels et la gestion de la mobilité .On trouve le commutateur du réseau «Mobile Switching Centre» ou (MSC) qui a pour rôle le contrôle de la BSC .D'une part, il permet l'interconnexion entre un réseau GSM et une réseau téléphonique public interconnecte un réseau GSM avec le réseau téléphonique public RTCP/RNIS, D'autre part, il présente l'interface des bases de données du réseau GSM avec le sous-système
  • 21. Chapitre 2 : Etat de l’art des réseaux cellulaires 17 radio. Ces bases de données enregistrent la localisation des abonnés. A ce niveau, on trouve les entités :  VLR «Visitor Location Register» : Une base de données représentant l'enregistreur des visiteurs.  HLR «Home Location Register» : Une base de données contenant les informations relatives à chaque utilisateur (abonné) à savoir l'IMSI et l'IMEI.  AUC «Authentification Centre» : Une base de données qui permet l'authentification des demandes de services En effet, quand cet abonné demande l'accès à un service, un équipement du réseau qui veut contrôler la validité des privilèges du demandeur interroge le HLR de l'abonné. Le HLR d'un abonné contient des informations permanentes. En revanche, un VLR enregistre les informations temporaires, relatives à une station mobile. Figure 8:Le Sous-système d'Acheminement  Le Sous-système d'Exploitation et de Maintenance OSS : permet à l'opérateur d'exploiter et de contrôler son réseau. Les équipements (OMC, EIR et AUC) assurent ensemble l'administration du réseau. L'OMC est responsable de la gestion du rendement, la gestion de la sécurité, et les opérations de maintenance. L'EIR est une base de données qui peut être consultée lors des demandes de services d'un abonné pour vérifier que le terminal utilisé est autorisé à fonctionner sur le réseau. L'AUC est une base de données qui permet l'authentification des demandes de services.
  • 22. Chapitre 2 : Etat de l’art des réseaux cellulaires 18 Figure 9 : Le Sous-système d'Exploitation et de Maintenance 2.1.2 Identités dans un réseau GSM Nous s'intéresse dans cette partie aux paramètres d'identification des clients dans le réseau.  IMSI IMSI (International Mobile Subscriber Identity) est l'identifiant unique affecté à un abonné qui souscrit à un abonnement mobile auprès d'un opérateur. Ce numéro d'IMSI a été préalablement stocké sur la carte SIM (Subcriber Identity Module). Le numéro d'IMSI n'est pas connu de la part de l'abonné mobile et n'est utilisé que par le réseau GSM. LIMSI est constitué de trois sous-champs :  MCC (Mobile Country Code) : Il présente le code du pays du réseau.  MNC (Mobile Network Code) : Il s'agit du code du réseau mobile. Il identifie de manière unique le réseau GSM à l'intérieur d'un pays.  MSIN (Mobile Subscriber Identification Number) : il s'agit du numéro d'identification du mobile. Il identifie l'abonné mobile à l'intérieur du réseau mobile.  MSISDN MSISDN (Mobile Station ISDN Number) est le numéro de téléphone associé à la station mobile .Il contient les trois sous-champs suivantes :  CC (Country Code) : présente le code du pays dans lequel l'abonné mobile a inscrit son abonnement.  NDC (National Destination Code) : Il s'agit du numéro national du réseau GSM dans lequel un client a souscrit un abonnement.  SN (Subscriber Number) : Il s'agit du numéro d’abonné  IMEI L'IMEI, (International Mobile Equipment Identity) permet d'identifier de façon unique un terminal mobile au niveau international. Ce numéro est donné par le constructeur du terminal
  • 23. Chapitre 2 : Etat de l’art des réseaux cellulaires 19 mobile. L'IMEI est utilisé par les opérateurs GSM pour lutter et défendre contre les vols de terminaux ou pour empêcher l'accès au réseau à des terminaux. 2.1.3 Les limites de la Norme GSM Le GSM offre un débit maximal de 9,6 Kbit/s ce qui permet de transmettre en plus de la voix, des données de faible volume comme le SMS ou le MMS. Il est apparu vers le milieu des années 1990 que cette norme atteindrait rapidement ses limites en termes de support d'un service de transmission de données à haut débit. De plus et avec le progrès dans les services proposés par l'internet, il parait nécessaire de coupler la mobilité avec l'accès à l'internet. Pour cela les opérateurs ont pensé à migrer de la norme GSM à une autre norme qui évite les lacunes et les défauts du système de seconde génération et qui répond aussi au défi de la transmission de données à haut débit. Cette évolution débute par la phase de l'introduction du GPRS avec la transmission en mode paquet sur la voie radio. 2.2 Le standard GPRS 2.2.1 L'apport de la technologie GPRS Cette technologie étend l'architecture de la norme GSM et permet un transfert de données à un débit plus élevé tout en optimisant l'utilisation des ressources. La technologie GPRS donne la possibilité d'atteindre un débit maximal théorique de 171,2 Kbit/s ce qui correspond pour l'utilisateur à un débit maximal de 114 Kbit/s dans les conditions optimales. Donc la mise en place d'un réseau GPRS permet à un opérateur de proposer de nouveaux services de type data avec un débit de données 5 à 10 fois supérieur au débit maximum théorique d'un réseau GSM. Le GPRS spécifie une technique de transmission en mode paquet qui immobilise le canal de communication. Cet action donne la possibilité d'avoir une connexion permanente et une facturation à la donnée ce qui présente un avantage non négligeable pour l'utilisateur qui peut rester connecté sans surcoût et ne paye que le coût du volume échangé de données le contraire de GSM où l'utilisateur est facturé par le temps de connexion ainsi il paye même s'il ne consomme pas la capacité du réseau. 2.2.2 Architecture Matérielle du GPRS L'intégration du GPRS nécessite l'ajout de quelques équipements et des mises à jour aux entités du réseau GSM pour que l'ancien réseau accepte l'intégration de la nouvelle
  • 24. Chapitre 2 : Etat de l’art des réseaux cellulaires 20 technologie tout en conservant ses fonctionnalités. La figure ci-dessous présente une architecture de la norme GPRS. Figure 10 : Architecture du Réseau GPRS Comme la figure 9 le présente, il existe coté NSS un réseau de commutation de paquets en parallèle du réseau de commutation de circuit. Pour cela on ajoute deux entités (SGSN et GGSN). Le SGSN est le dual paquet du MSC/VLR circuit. Il est connecté au BSS et à des SGSN et GGSN voisins. Le SGSN joue le même rôle réalisé par le VLR dans la gestion de mobilité. En effet, il s'occupe aussi de la compression et cryptage des données. Pour le GGSN il s'agit d'un nœud d'interfonctionnement entre le réseau de données extérieur et le réseau mobile de transfert de paquets. 2.2.3 La technologie EDGE L'EDGE peut être considéré comme une amélioration du GPRS. Les opérateurs font le recours à cette technologie car la norme UMTS les oblige à déployer un autre réseau physique et donc des investissements très lourdes. L'EDGE présente l'avantage de pouvoir utiliser les infrastructures déjà déployées contrairement à l'UMTS. L'EDGE est mis en place afin d'accroître la capacité des données par rapport au GPRS. La vitesse de transfert de données pour un réseau EDGE peut théoriquement atteindre un débit maximum de 384 Kbps contre seulement 114 Kbps pour un réseau GPRS.
  • 25. Chapitre 2 : Etat de l’art des réseaux cellulaires 21 Même avec l'introduction du GPRS et EDGE, le débit pratique dans des conditions optimales ne passe pas les 120 Kbit/s ce qui ne pas correspond aux attentes des utilisateurs .Pour cela les opérateurs se trouvent obligés à sacrifier financièrement et installer le réseau de troisième génération. 2.3 Téléphonie à mode paquet à haut débit : UMTS L'UMTS ou 3G est une norme pour les réseaux mobiles permettant de fournir aux utilisateurs une meilleure qualité de service. L'UMTS est capable d'offrir de nouvelles applications multimédias et des services à valeur ajoutée telle que la visiophonie et internet à haut débit. L'UMTS utilise des fréquences plus élevées que le standard 2G. L'UMTS occupe les bandes passantes : 1885-2025MHz et2110-2200MHz. 2.3.1 Architecture de l'UMTS Le réseau UMTS possède une architecture flexible et modulaire. L'architecture illustrée à la figure 10, est composée de trois entités qui sont l'équipement de l'usager(UE), le réseau d'accès radio (UTRAN) et le réseau cœur (CN). En effet, chaque équipement doit réaliser une fonction bien déterminée dans le réseau, alors que des interfaces d'échange, notés par Uu et Iu, assurent les échanges et la communication entre les différentes entités du réseau. [6] Figure 11 : Architecture de l'UMTS
  • 26. Chapitre 2 : Etat de l’art des réseaux cellulaires 22 2.3.2 Le domaine UE (User Equipement) Il comprend tous les équipements terminaux et permet l'accès à l'infrastructure du réseau et à ses services par le biais de l'interface Uu. [2] 2.3.3 UTRAN (UMTS Terrestrial Radio Access Network) Il fournit les ressources radio et les mécanismes nécessaires à l'UE pour accéder au CN. Il permet la maintenance et la libération des canaux radio entre le terminal et le réseau coeur CN et la gestion de ressources radio. L'UTRAN est composé d'un ensemble de sous-systèmes nommés RNC et de plusieurs stations de base appelé NodeB.  NodeB : il a comme rôle la transmission et la réception d'informations entre l'UTRAN et un ou plusieurs équipements usagers. Les UEs sont connectés au Node B via l'interface Uu, qui assure la connexion radio. Le Node B s'occupe de la transmission et de la réception du signal radio, de la modulation/démodulation, du codage de canal et l'adaptation du débit de transmission.  RNC: Il assure essentiellement le routage des communications entre les Nodes B et le réseau coeur d'une part et le contrôle et la supervision des Noeuds B d'autre part par le biais de l'interface IuB. Figure 12 : UTRAN 2.3.4 Riau Cœur CN (Core Network) Le CN assure la connexion entre les différents réseaux d'accès radio d'une part et les autres réseaux externes d'autre part tels que RTCP et les réseaux Internet. Sa principale fonctionnalité est la commutation et le routage des données utilisateurs vers la destination correspondante, la gestion de la mobilité, de l'authentification, de la sécurité des échanges, de la taxation et de signalisation entre les terminaux mobiles et les réseaux distants via l'interface
  • 27. Chapitre 2 : Etat de l’art des réseaux cellulaires 23 radio. Dans le rôle d'acheminement, le réseau coeur se compose de serveurs et de passerelles qui se divisent entre deux sous-systèmes principaux: le domaine CS et le domaine PS. 2.4 HSPDA HSPDA (High Speed Downlink Packet Access) ou encore 3.5G ou le 3G+ présente une norme évoluée du standard UMTS. En effet, ce protocole pour la téléphonie mobile offre des performances dix fois supérieures à la 3G.Cette évolution basée essentiellement sur la technologie WCDMA permet à un utilisateur de télécharger à des débits théoriques de 1,8 Mbit/s ; 3,6 Mbit/s ; 7,2 Mbit/s et 14,4 Mbit/s. Donc, il s'agit d'une amélioration qui offre des occasions de téléchargement à des très hauts débits de telle façon qu'on peut atteindre un débit de téléchargement qui dépasse 7,2 Mbit/s avec la Release7. 2.5 HSUPA HSUPA (High Speed Uplink Packet Access) est une norme de haut-débit mobile de troisième génération dont les standards ont été définies et diffusés par le 3GPP dans la sixième édition du référentiel UMTS (Release 6 de l'UMTS). HSUPA présenté comme un successeur de la technologie HSPDA, vient d'améliorer le débit sur la voie montante (Uplink) qui peut atteindre à ce niveau 5,8 Mbit/s alors que le débit descendant (Downlink) reste le même que celui de son prédécesseur (HSPDA) qui atteint 14 Mbit/s. 3 Concept de la qualité de service 3.1 Définition Généralement, la qualité de service ou Quality of Service (QoS) est la capacité de transférer dans les bonnes conditions un type de trafic donné, en termes de disponibilité, débit, et délai de transition. La qualité de service pour le réseau détermine le degré de satisfaction de l'utilisateur aux services offerts. 3.2 Critères de performances des réseaux 2G/3G Afin de permettre aux opérateurs d'obtenir des informations sur la qualité du service offert par leur réseau et de l'optimiser, des indicateurs de performance appelés KPIs (Key Performance Indicators) qui spécifient le fonctionnement radio des cellules ont été également définis. [4] En effet, un KPI est une valeur représentative permettant d'évaluer la performance de système. Cette valeur est obtenue à partir d'une ou de plusieurs mesures brutes relevées par
  • 28. Chapitre 2 : Etat de l’art des réseaux cellulaires 24 des compteurs spécifiques. Ces indicateurs permettent la localisation des anomalies de réseau et par suite, l'identification et le diagnostic des causes de ces problèmes afin de réagir avec des actions correctives adéquates. Dans le but d'offrir une qualité de service acceptable il faut que certains problèmes doivent être résolus. Ces problèmes sont principalement liés à : 3.2.1 La couverture : Ce problème ne peut pas être détecté par le système mais évalué par les plaintes des abonnées et par les mesures radio. Les causes probables de ce problème sont les suivants :  Mauvaise configuration du réseau c'est-à-dire problème lié à la position des sites, ou les types d'antennes.  Problème d'installation qui peut être due à la perte des puissances dans les câbles.  Problème de maintenance. 3.2.2 La disponibilité du réseau : C'est la probabilité d'obtention d'un nouvel appel. La diminution de taux d'appel aboutis implique que les abonnées ne peuvent pas établir une communication. Les actions de l'échec d'établissement d'appel s'expliquent par :  Le niveau d'accès minimum dans la cellule.  L'interférence et la mauvaise couverture radio. 3.2.3 La qualité de voix : L'opérateur agit contre le problème de la mauvaise qualité de communication, par les mesures système et par les analyseurs de la qualité vocale. Les causes de dégradation de la qualité de la voix sont :  La hors couverture.  La mauvaise installation.  La qualité des terminaux. 3.2.4 Les coupures d'appels : La coupure de communication peut être engendré par :  La mauvaise couverture.  Les interférences.
  • 29. Chapitre 2 : Etat de l’art des réseaux cellulaires 25 Si un des KPI excède les seuils fixés par l'opérateur, le superviseur du réseau vient de signaler un problème détecté au niveau de la fonctionnalité qu'assure cet indicateur. Généralement, ce problème est généré à partir d'un problème ou une anomalie de couverture, d'insuffisance de capacité, d'interférence, ou d'un problème mauvais paramétrage du réseau. A titre d'exemple, si nous enregistrons un taux de coupure de l'appel supérieur à 2%, alors nous avons un problème de maintien d'appel qui peut 1tre causé par la mauvaise couverture, l'interférence, problème lors du handover (dans ce cas on consultera les taux de succès de handover) ou un mauvais paramétrage du réseau. De plus, si le taux de succès de l'établissement d'un service est inférieur à 95%, dans ce cas nous avons un problème d'accès au réseau causé par la capacité, l'interférence ou un problème de paramétrage du réseau.On présente ci-dessous un tableau qui illustre les seuils de quelques KPI : Tableau 1: Les seuils des KPIs Conclusion Après avoir traité tout le long de ce deuxième chapitre les architectures des réseaux cellulaires ainsi que le concept de la qualité de service(QoS), en présentant les différents paramètres et critères de performance de la QoS, nous présentons passer à l’analyse des besoins à travers le chapitre suivant.
  • 30. Chapitre 3 : Analyse des besoins et spécifications 26 Chapitre 3 Analyse des Besoins et Spécifications
  • 31. Chapitre 3 : Analyse des besoins et spécifications 27 Introduction Nous allons maintenant nous consacrer à la phase d’analyse et de spécification. Elle consiste à identifier les différentes fonctionnalités de l’application et à décrire les différents cas d’utilisation posés par le sujet de point de vue utilisateur. Dans cette optique nous allons tout d’abord définir les fonctionnalités offertes par le système répondant aux besoins de TUNISIANA ensuite spécifier les acteurs pour arriver à la fin à la présentation des cas d’utilisation. 1 Objectifs L'objet de ce projet est la conception et la réalisation d'un outil destiné à gérer et à présenter L’impact de disfonctionnement d’un site sur la QOS de réseaux Tunisiana. Pour répondre à ces objectifs, différents volets d’analyse seront menés dans le cadre de ce lot, à savoir la définition des besoins fonctionnels, l’analyse de l’existant et la conception de la cible globale, pour avoir le dossier fonctionnel des besoins (fonctionnels et techniques). 2 Spécification des exigences Dans cette section nous identifions une liste d’exigences fonctionnelles et non fonctionnelles du système à concevoir. Certaines exigences sont ajoutées pour clarifier d’avantage les besoins des utilisateurs. 2.1 Les acteurs système Cette application est destinée à l’équipe de supervision de Tunisiana. La structure de cette application ainsi que tous les services proposés par l’application, seront détaillés dans les chapitres suivants. 2.1.1 Administrateur : L’administrateur de cette application sera en charge de la création des différents Utilisateur. L’administrateur est le seul à pouvoir créer et supprimer des fiches de personne en tant qu’administrateur, il n’a pas le droit de modifier les données des fiches. Cependant, il aura la possibilité de prendre l’identité d’une personne pour avoir accès à ses droits, et effectuer ainsi des modifications.
  • 32. Chapitre 3 : Analyse des besoins et spécifications 28 2.1.2 Utilisateur : C’est l'équipe de supervision qui a le droit de manipuler l'application. 2.2 Le Backlog du produit : Tout dans Scrum tourne autour du backlog produit. Ce backlog contient, sous forme de liste, les choses que le client veut que l'équipe réalise. C'est en quelque sorte une « liste priorisée d'exigences, d'histoires, de caractéristiques, ou autre ». Le backlog produit est maintenu par le product owner. Nous avons choisi d’intégrer dans notre système les fonctionnalités les plus importantes qui sont les suivantes:  Traitement Des Informations.  L’analyse des données.  Déterminer l’Availability de 2 G RAN/ 3G RAN de réseaux Tunisiana.  Déterminées l’emplacement des tous les sites de réseaux Tunisiana.  Déterminer le voisinage d’un site sur une distance bien déterminé.  Déterminer L’impact de disfonctionnement d’un site sur le QOS de réseau Tunisiana sur cette zone. Story ID Story name Status Sprint Priority Estimation (j) 1 analyse et traitement des données Done 1 1 18 2 Géolocalisation des sites 2G/3G sur google maps Done 2 1 18 3 calculer et afficher l'avaibility 2G/3GRAN Done 3 1 10 4 traitement des incidents et déterminer les sites HS et l'impact sur le reseau Done 3 2 20 5 afficher tous les cellules du réseau Tunisiana Done 4 2 7 6 gestion d’utilisateur Done 4 3 7 7 gestion BTS Done 4 3 7 Tableau 2 Tableau 1 Backlog du Produit
  • 33. Chapitre 3 : Analyse des besoins et spécifications 29 2.3 Diagramme des cas d’utilisation globale : L’approche consiste à regarder le système à construire de l’extérieur, du point de vue de l’utilisateur et des fonctionnalités qu’il attend. Chaque cas d’utilisation sera une spécification de ce qu’il sera possible de demander de l’extérieur à l’entité ainsi représentée. Figure 13: diagramme cas d'utilisation globale Cette figure nous donne une vue globale sur les différents besoins fonctionnels ainsi les acteurs qui interagissent avec notre application. 2.4 Sprint Après avoir spécifié les besoins avec le « Product Owner », nous avons organisé les tâches sous la forme de « Sprints » où chaque sprint aura une durée de vingt jours ou plus avec pour objectif avoir un produit fonctionnel et livrable à la fin de chaque sprint. Nous avons organisé notre produit backlog sous la forme de cinq sprints selon l’ordre de priorité des tâches à réaliser et la durée que nécessite l’accomplissement de chaque tâche. Nos sprints serons composés comme suit : 2.4.1 Sprint 1 Le sprint 1 est Généralement de criticité élevée. Ce sprint est composé de Deux User Stories décrits ci-dessous.
  • 34. Chapitre 3 : Analyse des besoins et spécifications 30 User Story 1 Tableau récapitulatif du première User Story “ Traitements des fichiers de données BTS ” Id 1 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Traitements des fichiers des données BTS Valeur/criticité 1 Criticité élevée Estimation 10j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Serveur des fichiers 2. Sélections des fichiers 3. Sélections de données 4. organisation et gestion des données BTS Pourquoi ? Déterminées l’équipement du réseau Tableau 3: User Story traitements des fichiers de données BTS User Story 2 Tableau récapitulatif du première User Story “ Traitements des fichiers des incidents ” Id 2 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Traitements des fichiers des incidents Valeur/criticité 1 Criticité élevée Estimation 8j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Serveur des fichiers 2. Sélections des fichiers 3. Sélections de données 4. Sélections des BTS HS Pourquoi ? Suivre l’état des équipements réseaux Tableau 4 : User Story Traitements des fichiers des incidents
  • 35. Chapitre 3 : Analyse des besoins et spécifications 31 Figure 14 : Diagramme cas d'utilisation traitement des fichiers 2.4.2 Sprint 2 Ce sprint est composé de trois User Stories suivants : User Story 3 Tableau récapitulatif du première User Story “Géolocalisation des sites BTS ” Id 3 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Géo-localisation des sites BTS Valeur/criticité 1 Criticité élevée Estimation 6j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. Sélections des Bts 2G/3G 3. Sélections des cordonnées GPS 4. géo-localisation sur google MAPS Pourquoi ? Déterminer les emplacements des sites Tableau 5:User story Géolocalisation des sites BTS
  • 36. Chapitre 3 : Analyse des besoins et spécifications 32 User Story 5 Tableau récapitulatif du première User Story “rechercher site ” Id 3 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Rechercher site Valeur/criticité 2 Criticité élevée Estimation 6j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. Sélections des BTS 2G/3G 3. Sélections des cordonnées GPS 4. rechercher in site 5. géo-localisation sur google MAPS Pourquoi ? Déterminer les emplacements d’un site bien déterminé Tableau 6:User Story “rechercher site ” User Story 6 Tableau récapitulatif du première User Story “Afficher les voisinage ” Id 6 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana.. Nom Afficher les voisinages Valeur/criticité 2 Criticité élevée Estimation 6j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. Sélections des Bts 2G/3G 3. Sélections des cordonnées GPS 5. déterminer la distance des voisinages 4. géolocalisation sur google MAPS Pourquoi ? Déterminer les emplacements des sites voisinage d’un site choisi Tableau 7 : User Story “Afficher les voisinage ”
  • 37. Chapitre 3 : Analyse des besoins et spécifications 33 La figure suivante présente le digramme de cas d’utilisation résultant du Sprint 2 Figure 15 : Cas d'utlisation de sprint 2 2.4.3 2.4.4 Sprint 3 Ce sprint est composé de trois User Stories suivants : User Story 7 Tableau récapitulatif du première User Story “géolocalisation des incident ” Id 7 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom géolocalisation des incidents Valeur/criticité 3 Criticité élevée Estimation 10j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. Sélections des BTS 2G/3G 3. Sélections des cordonnées GPS 5. sélections des incidents 6. déterminer les sites HS 4. géolocalisation sur google MAPS Pourquoi ? Déterminer les emplacements des sites HS
  • 38. Chapitre 3 : Analyse des besoins et spécifications 34 Tableau 8:User Story “géolocalisation des incident ” User Story 8 Tableau récapitulatif du première User Story “KPI du réseau ” Id 8 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana.. Nom Mesure QOS du réseau Valeur/criticité 3 Criticité élevée Estimation 10j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. Sélections des BTS 2G/3G 3. choix des KPI 4. afficher KPI Pourquoi ? Déterminer les QOS de réseau Tableau 9:User Story “ KPI du réseau ” User Story 9 Tableau récapitulatif du première User Story “ Availibility 2G/3G RAN ” Id 9 Projet d’Evaluation de Performances du Réseau Tunisiana. Nom Mesure 2G/3G RAN Valeur/criticité 3 Criticité élevée Estimation 5j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. déterminer la liste des incidents 3. calculer 2G/3G RAN 4. afficher courbe Pourquoi ? Déterminer les QOS du réseau Tableau 10: User Story “Availibilite 2G/3G RAN ”
  • 39. Chapitre 3 : Analyse des besoins et spécifications 35 Figure 16 : Cas d'utilisation Déterminer les sites HS Figure 17 Afficher Availibility 2G RAN
  • 40. Chapitre 3 : Analyse des besoins et spécifications 36 2.4.5 Sprint 4 Ce sprint est composé de trois User Stories suivants : User Story 8 Tableau récapitulatif du première User Story “gestion des cellules” Id 8 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Gestion des cellules Valeur/criticité 4 Criticité élevée Estimation 7j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. déterminer la liste des cellules 3. afficher tous les cellules 4. recherche par plusieurs critères 5. modifier/ supprimer/ ajouter des cellules Pourquoi ? Gestion des cellules Tableau 11: User Story gestion des cellules User Story 9 Tableau récapitulatif du première User Story “gestion des Utilisateurs” Id 9 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Gestion des Utilisateurs Valeur/criticité 4 Criticité élevée Estimation 7j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. déterminer la liste des utilisateurs 3. afficher tous les utilisateurs 4. modifier / supprimer / ajouter des utilisateurs Pourquoi ? Gestion des utilisateurs Tableau 12: User Story gestion des Utilisateurs
  • 41. Chapitre 3 : Analyse des besoins et spécifications 37 User Story 10 Tableau récapitulatif du première User Story “gestion des BTS” Id 10 Projet Portail Web d’Evaluation de Performances du Réseau Tunisiana. Nom Gestion des cellules Valeur/criticité 4 Criticité élevée Estimation 7j Acteurs Les utilisateurs cible sont les consultants et les managers Sujet 1. Connexion à Base de données 2. déterminer la liste des cellules 3. afficher tous les cellules 4. recherche par plusieurs critères 5. modifier / supprimer / ajouter des cellules Pourquoi ? Gestion des BTS Tableau 13: User Story gestion des BTS Les figures suivantes présentes les digrammes de cas d’utilisation résultant du Sprint3 Figure 18 : Gestion BTS
  • 42. Chapitre 3 : Analyse des besoins et spécifications 38 Figure 19 : Cas d'utilisations Afficher cellules Figure 20 : Cas d'utilisations Gestion Utilisateur
  • 43. Chapitre 3 : Analyse des besoins et spécifications 39 2.5 Besoins Non Fonctionnels S’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes d'implémentation (langage de programmation, type SGBD, de système d'Exploitation...) Dans le cadre de ce travail, l'application devra être extensible, c'est-à-dire qu'il pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités. L'application devra être capable de :  Rapidité : l’application traite souvent un grand volume de données, elle doit alors effectuer ces traitements d’une façon rapide et optimale afin d’éviter une longue durée d’attente.  Robustesse : l’application doit pouvoir gérer un très grand volume de données sans se bloquer.  Fidélité : la comparaison de paie est une étape cruciale qui manipule des données sensible ainsi les résultats de calcul doivent être justes.  Portabilité : l’application doit être facilement utilisable et ne doit pas nécessiter des étapes de configuration ou d’installation.  Evolutivité : l’outil doit être facilement modifié afin d’ajouter des nouveaux modules répondant à des nouveaux besoins. Conclusion Ce chapitre a permis de détailler les spécifications du projet, d’identifier les cas d’utilisation et d’élaborer les diagrammes correspondants. A présent nous sommes prêts à passer à l’étape de conception dans le chapitre suivant.
  • 44. Chapitre 4 : Conception 40 Chapitre 4 Conception
  • 45. Chapitre 4 : Conception 41 Introduction A la fin du chapitre précédent, nous avons présenté l’aspect architectural de la solution. Dans la section suivante, nous présentons l’aspect conceptuel de notre application ; une étape primordiale avant l’implémentation. 3 Architecture du système : Modèle multi couches Les choix architecturaux d’une application sont décisifs dès lors qu’ils interviennent sur les performances, l’évolutivité, le temps de développement, et bien sûr le coût. Aujourd’hui nous parlons d’une séparation des applications en différentes couches, et nous parlons alors d’applications multi niveaux. L’architecture de notre système est une architecture multi niveaux à base de composants respectant le paradigme JEE. Elle est constituée des couches suivantes modélisées dans la figure ci-dessous. Nous notons la délimitation des couches de conception du modèle MVC2 des autres couches constituant notre système. Figure 21 : modèle MVC  Couche de présentation : Chargée de gérer les interactions entre l’utilisateur et l’application (Navigateur Internet).  Couche web : Permet de définir ce que doit afficher l’interface utilisateur et la manière de gérer les requêtes.  Couche métier : Contient le traitement à exécuter, qui sera appelé via la couche de présentation faisant intervenir en général l’extraction et le traitement du contenu de la couche de données via la couche d’accès aux données.  Couche d’accès aux données : Prend en charge toutes les interactions entre la couche logique et la couche de données. Si une telle couche n’existait pas, nous serions contraints de réécrire les mêmes lignes de code à différents endroits de l’application.
  • 46. Chapitre 4 : Conception 42  Couche de données : Ce niveau contient les données de l’application (Base de données, fichiers XML,). Grâce à cette séparation en couches la souplesse, la maintenance et le développement de l’application se trouveront grandement améliorés. Par la suite, nous intéresserons aux détails des couches de la partie MVC2 qui contiendra toute notre logique applicative. 4 Conception Dans cette section nous présentons en premier lieu l’architecture logicielle de notre application via un diagramme décrivant les dépendances entre les différents packages. En second lieu nous présentons chacun de ces modules. 4.1 Conception détaillé La conception détaillée consiste à concevoir et documenter précisément le code qui va être produit. Dans cette phase, toutes les questions concernant la manière de réaliser le système à développer doivent être élucidées. Le produit d'une conception détaillée consiste en l'obtention d'un modèle prêt à coder. Lorsque l'on utilise des langages orientés objet le concept de classe UML correspond exactement au concept de classe du langage concerné. Cette propriété facilite la compréhension des modèles de conception et donne encore plus d'intérêt à la réalisation d'une conception détaillée avec UML. Dans cette partie, nous présentons la conception de l’application réalisée à chaque sprint à l’aide de quelques diagrammes de séquence et d’activité des user stories les plus importants. 4.2 Sprint 1 4.2.1 Diagramme de séquence La figure suivante décrit le scénario d’authentification.Il commence l’lorsque un utilisateur demande l’accès a l’application :
  • 47. Chapitre 4 : Conception 43 Figure 22 : Diagramme séquence objet authentification La figure suivante décrit le user story ‘ Traitements des fichiers de données BTS ‘, chaque heurs le serveur ftp envoie des fichiers des données des incidents ainsi la mise à jour des BTS. le scenario suivant décrit le traitement de ces fichiers : Figure 23 : Diagramme de séquence de user story traitement des fichiersde données BTS
  • 48. Chapitre 4 : Conception 44 4.2.2 Diagramme d’activité : Le diagramme d'activité permet de modéliser le comportement du système, dont la séquence des actions et leurs conditions d'exécution. Les actions sont les unités de base du comportement du système. La figure suivante résume le processus de traitement des fichiers de données BTS. Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS 4.3 Sprint 2 4.3.1 Diagramme de séquence Ce scénario est décrit par la figure suivante il commence lorsque l’utilisateur demande la carte des sites 2G. En effet l’utilisateur a le choix de la géolocalisation les sites selon plusieurs critères.
  • 49. Chapitre 4 : Conception 45 Figure 25 : Diagramme séquence objet Map 2G 4.3.2 Diagramme d’activité : Le processus de création de Géolocalisation des sites BTS peut être résumé dans le diagramme d’activités suivant :
  • 50. Chapitre 4 : Conception 46 Figure 26: Diagramme d'activité « Géolocalisation des sites BTS » 4.4 Sprint 3 4.4.1 Diagramme de séquence Le scénario suivant décrit le user story « géolocalisation des incident » par la figure suivante d’après ce dernier on peut géolocaliser les incident ainsi les sites hors service a chaque moment données et définit les KPI des sites voisinage.
  • 51. Chapitre 4 : Conception 47 Figure 27 : Diagramme séquence géolocalisation des incidents
  • 52. Chapitre 4 : Conception 48 Le scénario suivant décrit les étapes à suivre pour afficher la courbe de l’Availibility 2G ainsi les déférentes actions qui peuvent les établir. Figure 28 : diagramme de séquence « l’Availibility 2G » 4.4.2 Diagramme d’activité Le diagramme d’activité suivant représente le scenario relatif au user story « géolocalisation des incident »
  • 53. Chapitre 4 : Conception 49 Figure 29 : Diagramme d'activité « géolocalisation des incidents » 4.5 Sprint 4 4.5.1 Diagramme de séquence Le scénario suivant décrit les étapes à suivre pour ajouter un utilisateur après les vérifications des champs de formulaire qu'on doit remplir. Nous vérifions au niveau de base de données l’unicité de cet utilisateur. Figure 30 : Diagramme de séquence « ajouter utilisateur »
  • 54. Chapitre 4 : Conception 50 4.5.2 Diagramme d’activité Le diagramme d’activité suivant représente le scenario relatif cas d’utilisation « ajouter utilisateurs » Figure 31: Diagramme d'activité « ajouter utilisateurs » 4.6 Diagramme de classes L'approche objet prône le rapprochement des données et des opérations dans une seule entité : l'objet. Les traitements sont ainsi répartis entre les déférents objets qui incarnent les données manipulées par le programme. Le concept des objets est fondamental dans l'approche objet. Les objets sont des entités atomiques formées par l'union d'un état et d'un comportement et qui communiquent par échange de messages. Afin de réduire la complexité des objets du monde réel, la notion d'abstraction a permis de regrouper les objets en classes. Parmi les relations les plus importantes entre les classes, les associations (relations sémantiques bidirectionnelles) et l'héritage. Les classes et leurs relations sont regroupées dans un diagramme (diagramme de classes) représentant une vue statique des interactions entre les objets.
  • 55. Chapitre 4 : Conception 51 Figure 32:Diagramme de classe Conclusion Nous finissons ainsi l'étape de conception, élaborée dans ce chapitre et dans laquelle nous avons préparé tout ce qu'il fallait pour présenter et réaliser cette application. La réalisation est Le sujet du chapitre suivant
  • 56. Chapitre 5 : Réalisation 52 Chapitre 5 Réalisation
  • 57. Chapitre 5 : Réalisation 53 Introduction Cette partie contient le dernier volet de ce rapport, elle a pour objectif d’exposer le travail achevé. Nous allons commencer, tout d’abord, par la présentation de l’environnement matériel et logiciel utilisé pour développer l’application demandée. Ensuite, nous présentons le travail accompli tout au long de la période du stage. Enfin, nous montrons le chronogramme de la réalisation du projet. 1 Environnement de travail Nous présentons dans cette section l’environnement matériel ainsi que celui logiciel utilisés pour le développement de notre application. 1.1 Environnement matériel Un PC avec les configurations suivantes :  un processeur Intel Core I5  une RAM de 4 Go. 1.2 Environnement logiciel Le long de la phase de développement, nous avons utilisé l’environnement logiciel suivant : – Système d’exploitation : Microsoft Windows Seven pour la PC de développement. Linux fedora Serveur de Tunisiana ou le déploiement de l’application. – Outils de développement : Eclipse 3.7 – Serveur d’application : JBoss AS 7.1.1 – MySQL Server 5 : utilisé pour la gestion de la base de données. – Paradigm for UML 10.1 et ArgoUML : pour la conception UML. 2 Choix techniques Dans cette partie, nous justifions les choix techniques du langage de programmation, de la plateforme de développement et des frameworks utilisés. 2.1 Choix du standard de développement Java EE 6 est une version importante. Non seulement elle marche dans les pas de Java EE 5 pour fournir un modèle de développement simplifie, mais elle ajoute également de nouvelles spécifications et apporte des profils et de l’élagage pour alléger ce modèle. La sortie de Java EE 6 coïncide avec le dixième anniversaire de la plate-forme entreprise : elle combine donc les avantages du langage Java avec l’expérience accumulée au cours de ces dix dernières
  • 58. Chapitre 5 : Réalisation 54 années. En outre, elle tire profit du dynamisme de la communauté open-source et de la rigueur du JCP. Désormais, Java EE est une plate-forme bien documentée, avec des développeurs expérimentes, une communauté d’utilisateurs importante et de nombreuses applications déployées sur les serveurs d’entreprises. C’est un ensemble d’API permettant de construire des applications multi-tiers reposant sur des composants logiciels standard ; ces composants sont déployés dans différents conteneurs offrant un ensemble de services. 2.2 Choix du Framework pour la couche de présentation JSF2.0 (Java Server Faces) permet de développer des application web en bénéficiant des concepts déjà approuvés par Java et Java EE composants graphiques Swing, JSP, Servelts, JSTL…)et par les apports d’autres Framework Open source tel que Struts. JSF est un standard, donc est supporté par l’industrie. Face à la multitude des frameworks MVC (Model-View-Controller) disponibles sur le marché, il s’agit là d’un argument non négligeable.JSF apporte plusieurs fonctionnalités destinées à résoudre les problèmes inhérents à la programmation web. JSF se compose d’un ensemble d’API fournissant notamment :  Une séparation entre la couche présentation et les autres couches  Une librairie de composants graphiques  La navigation entre pages  Le traitement des formulaires et leur validation JSF ne remplace pas les autres technologies web, il les utilise et les complète. Son architecture est basée sur le design pattern MVC. Pour rendre le développement d’une application web plus modulaire et plus souple, JSF décore le tous ces éléments (traitement, présentation, navigation) et enrichit le pattern MVC. Le modèle est toujours représenté par les Entity Beans. Le contrôleur intercepte les requêtes http, la navigation entre les pages web est configurable par un fichier XML dit faces-config.xml
  • 59. Chapitre 5 : Réalisation 55 Figure 33 : JSF 2.3 EJB3.1 Figure 34 : EJB3.1
  • 60. Chapitre 5 : Réalisation 56 Au sein d'une architecture Java EE, les EJB sont utilisés pour créer les services. Cette technologie ne s'arrête cependant pas à cette couche, mais permet aussi de créer l'abstraction de l'accès aux données. Ce sont les entités qui remplissent cette fonction. Tout comme les beans sessions, entre le client et le logique métier, les beans entités forment la passerelle entre la logique applicative et les sources de données. Ils offrent une abstraction quasi complète du stockage des données, permettant à l'application de rendre persistantes ou de charger des données de manière totalement transparente. 2.4 Choix du conteneur de la couche de persistance de données Depuis les débuts de J2EE, le modèle de persistance ne cesse d’évoluer et de s’engluer de version en version. Les entity beans 1.0 ont été complètement ré architecturés pour laisser place aux entity beans 2.1. Bien que cette évolution ait apporté beaucoup d’améliorations, ce modèle de composants persistants continuait à faire des détracteurs parmi la communauté. Ce mécontentement a donné naissance à une nouvelle spécification (JDO, Java Data Object) ainsi qu’à différents outils de mapping objet/relationnel payants ou libres (Top Link, Hibernante...). Java EE 5, et son lot de nouveautés, nous apporte un nouveau modèle de persistance : JPA (Java Persistence API). Fortement inspirés par des outils Open Source tels qu’Hibernante ou par JDO, le mapping objet/relationnel et le langage de requête sont totalement différents de l’ancêtre entity bean 2.1. JPA, ou JSR-220, réconcilie ainsi les utilisateurs de la plate-forme JEE avec les composants persistants. Java Persistent API s’appuie sur JDBC pour communiquer avec la base de données. En revanche, grâce à l’abstraction apportée par JPA, nous n’aurons nul besoin d’utiliser directement JDBC dans le code Java. La couche [dao] dialogue maintenant avec la spécification JPA, un ensemble d'interfaces. Le développeur y a gagné en standardisation. Avant, s'il changeait sa couche ORM, il devait également changer sa couche [dao] qui avait été écrite pour dialoguer avec un ORM spécifique. Maintenant, il va écrire une couche [dao] qui va dialoguer avec une couche JPA. Quelque soit le produit qui implémente celle-ci, l'interface de la couche JPA présentée à la couche [dao] reste la même. Dans notre projet la spécification JPA a été implémentée par le produit Hibernate.
  • 61. Chapitre 5 : Réalisation 57 Figure 35 : Architecture de la spécification JPA 2.5 Choix du SGBD MySQL Notre application ne dispose pas d’un grand volume de données à gérer, donc MYSQL suffira comme étant une solution open source. En plus ce SGBD est le serveur de base de données le plus utilisé dans le monde. Son architecture logicielle le rend extrêmement rapide et facile à personnaliser. Il faut aussi noter sa rapidité, sa robustesse, et sa facilité d’utilisation et d’administration. Enfin sa documentation complète et bien construite 2.6 Choix du serveur d’application JBOSS AS 7.1 : Alors que Tomcat est un conteneur web, JBOSS est un serveur d'applications qui embarque Tomcat (ou un équivalent) et qui propose en plus un hébergeur des EJB, des transactions, de la persistance... Côté performance, administration et connecteurs sont des raisons à considérer pour justifier le choix d’un serveur d'applications fiable. Tomcat est largement utilisé car c’est plus "léger" (empreinte mémoire, temps de démarrage...). Ceci dit, les serveurs d'applications en général font des progrès dans ce coté là. Avec l'arrivée dans les entreprises de Java EE 6, il y a un réel regain d'intérêt pour les serveurs d'application. JBOSS est le nom du serveur d'applications Open Source Java 6, il est entièrement écrit en Java. 3 Phase d’implémentation Les interfaces Homme/Machine constituent un élément important dans la réussite d’une application. Cette contribution est d’autant plus importante lorsqu’il s’agit d’une application Web. Ces interfaces doivent obéir à des chartes graphiques et aux règles d’ergonomie pour que l’utilisateur s’adapte le plus rapidement possible à la logique de l’application. Afin d’atteindre ces objectifs, nous avons choisi d’adopter un style commun pour toutes les interfaces à l’aide d’une feuille de style.
  • 62. Chapitre 5 : Réalisation 58 3.1 Géolocalisation site 2G Figure 36 : MAP 2G Description : Nous utilisons le Technique de localisations Global Positioning System(GPS) pour obtenir cette interface qui permet à l’utilisateur d’avoir une vue globale sur le réseau 2G de Tunisiana ainsi la géolocalisation des sites 2G. Cette résultat c’est la récolte de traitement des fichiers BTS sous format Excel ce derniers contient plus que seize mille ligne ainsi l’enregistré dans la base de données a fin de les affichées sur l’API de google MAPS. 3.2 Géolocalisation site 3G Figure 37 : MAP 3G
  • 63. Chapitre 5 : Réalisation 59 Description : Il s’agit de la même interface de géolocalosation 2G mais pour le cas de 3G. 3.2.1 Recherche par lac Figure 38 : Recherche par LAC Description : L’exemple présenté par la figure 38 montre l’affichage d’un ensemble des sites qui sont de même local area code (LAC) 1119. 3.2.2 L'Availability 2G RAN : Figure 39: courbe 2G RAN
  • 64. Chapitre 5 : Réalisation 60 Description : Cette interface permette à l’utilisateur d’avoir une vue globale sur les performances du réseau de Tunisiana. En effet Cette courbe est la résulta de la formule suivante : 3.3 Géolocalisation des Site HS Figure 40: géolocalisation des incidents Description : Notre application est basée sur la récupération les fichiers incidents sur un serveur FTP. Après le traitement de ces fichiers par la technologie EJB Timer nous obtenons cette interface d’où via ce dernier l’utilisateur est capable de visualiser l’ensemble de site hors service (HS) ainsi de déterminer la cause de l’incident. Figure 41 : Exemple de fichiers incidents
  • 65. Chapitre 5 : Réalisation 61 3.4 Affichage des sites en voisinage d’un site HS Figure 42 : voisinage d'un incident Description : Cette Interface permet de définir les voisinages des sites HS ainsi leur KPI. Après le choix de distance de voisinage ou par LAC d’un site HS un ensemble des sites sera affiché sur la carte chaque de ces site on peut présenter ces KPI et déterminer si il y a un impacte sur cette suite à la dysfonction de ce site ou non. Figure 43 : Voisinage Site HS par LAC
  • 66. Chapitre 5 : Réalisation 62 3.5 Test La phase de test est l’une des plus coûteuses et des plus importantes pour un cycle de vie d’un logiciel. A la fin de cette phase qu’on peut juger la qualité d’un logiciel. Dans notre projet on a mené les tests suivants : Les tests unitaires qui sont faits par le programmeur afin que chaque module puisse fonctionner sans erreur de programmation. Le test du système afin de vérifier si le logiciel fonctionne sur la machine cible (avec les logiciels et matériel du client). Le test de validation qui est fait par le client pour vérifier le niveau de qualité : c’est un test assez lourd pour adopter le logiciel aux attentes de client. 4 Chronogramme de réalisation Le diagramme de GANTT est un outil permettant de modéliser la planification de tâches nécessaires à la réalisation d'un projet dans le temps. Figure 44 : Chronogramme de Réalisation Conclusion Au cours de ce dernier chapitre nous avons précisé notre choix technique et montré quelques interfaces de notre application. A la fin nous avons présenté notre chronogramme modélisant les étapes de notre travail. A présent nous passerons dans la partie suivante à la conclusion globale de notre projet.
  • 67. 63 Conclusion et Perspective Aujourd’hui, le souci majeur des opérateurs de téléphonie mobile consiste à assurer une qualité de service suffisamment bonne afin de permettre le bon fonctionnement des services offerts à leurs abonnés. La nécessité d’améliorer le service rendu au niveau des réseaux mobiles s’est largement manifestée. Ainsi, l’utilisation des techniques d’optimisation appropriées est essentielle afin de qualifier les performances de réseaux. Le but principal de ce projet était de créer une plateforme qui facilite la tâche de suivi et de monitoring de la qualité de service de l'opérateur Tunisiana. Ce travail a suivi plusieurs étapes qui ont été très importantes pour la phase de réalisation et le développement. La première étape était de mettre le sujet dans son contexte général, ce qui a permis de dégager les différentes besoins dont l'application est chargée d'y répondre. Ces besoins ont été bien traités et analysés dans la phase de spécification. L'étape suivante, était la conception, durant toute cette phase, une étude globale et détaillée des fonctionnalités du système était réalisée à l'aide de langage de modélisation UML pour aboutir enfin à l'application opérateur qui vise à aider l'opérateur à améliorer la qualité de service offert. Ce projet présente une occasion pour s'améliorer dans le développement Java/Jee sur plusieurs niveaux appliquées les nouvelle technologie JEE6, communication client/serveur, communication réseaux avec les serveurs FTP, conception et interaction avec les bases de données, aussi, il m'a permis d'acquérir des connaissances importantes surtout au niveau de la qualité de service des réseaux mobiles 2 G et 3 G. Le travail présenté répond au cahier de charge déjà posé, mais il ne représente pas la version finale qu'on peut atteindre. En effet, ce travail peut s'améliorer certainement dans le futur, avec des nouvelles idées. Enfin, l’application que nous avons développée pourrait être enrichie par des fonctionnalités avancées telles que l’intégration d’partie mobile. Pour conclure, ce stage était très important, dans la mesure où il m'a permis d'appliquer mes connaissances acquises lors de mon cursus éducatifs et des maitriser des nouvelles technologies de développement. Finalement, il était une occasion pour s'introduire et s'intégrer dans le milieu professionnel.
  • 68. 64 Bibliographie [1] Pierre Lescuyer UMTS Les origines, l’architecture, la norme [2] Jean CELLMER, « Réseaux cellulaires, Système GSM» [3] Michel Thériault, "Étude des performances d’un système DS-CDMA avec récepteur Rake dans le contexte UWB". [4] http://www-igm.univ-mlv.fr/~dr/XPOSE2006/eric_meurisse/umts.php [5] Thierry Lucidarme, "Principes de radiocommunication de troisième génération", Vuilbert,Paris, 2002 [6] T. Okumura, E. Ohmor, and K. Fukada, "Field Strength and its variability in VHF and UHF Land mobile Service", Review Electrical Communication Laboratory, pp. 825-873, 1968 [7] J. Walfisch and H. Bertoni, "A theoretical model of UHFpropagation in urban environment", IEEE Transactions on antennas and propagation, vol. 36, pp. 1788-1796, December 1988 [8] Maciej J. Nawrocki, Mischa Dohler and A. Hamid Aghvami, "Understanding UMTS Radio network"
  • 69. 65 Acronymes 0-9 1G First Generation of wireless communication technology 2G Second Generation of wireless communication technology 3G Third Generation of wireless communication technology A API Application Programming Interface B BSC Base Station Controller BSS Base Station Subsystem BTS Base Transceiver Station C Cell ID CDMA CN E EDGE F FDD FTP G GPRS GSM H HSPA HSDPA J JVM J2EE Cellule Identity Code Division Multiple Access Core Network
  • 70. 66 Frequency Division Duplex File Transfert Protocol Global System for Mobile communication High-Speed Packet Access High-Speed Downlink Packet Access Java Virtuel Machine Java2 Enterprise Edition LAC Location Area code M MCC Mobile Country Code MMS Multimedia Message Service Mobile Network Code MSC Mobile Switching Center N NSS Network and Switching Subsystem O OSS Operation and Support Subsystem Q QoS Quality of Service R RAN Radio Access Network T TDD TDMA U UMTS UTRAN Time Division Multiple Access Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network W W-CDMA Wideband Code Division Multiple Access
  • 71. 67 Annexe A : JBOSS AS 7 JBoss Application Server est un serveur d'applications J2EE libre entièrement écrit en Java. Les développeurs du cœur de JBoss ont tous été employés par une société de services appelée « JBoss Inc. ». Le projet est sponsorisé par un réseau mondial de partenaires et utilise un business model fondé sur le service. En effet, JBoss est maintenu par le Groupe JBoss gratuitement, mais toute customisation et tous services consultants sont facturés. Ce groupe est une division de RedHat depuis avril 2006. La DGI (Direction Générale des Impôts) utilise JBoss. JBoss est similaire à Weblogic de BEA ou à WebSphere d’IBM dans sa complexité. Compatible avec les standards : • CORBA OTS (Object Transaction Service), • JTA/JTS (Java API Transaction/Service), • WebServices Caractéristiques : • Supporte les Sun JDK 1.6 et 1.7 • Version 5as 7est en passe d’être certifiée 1.7 • Clustering: Failover (including sessions) / Load balancing • Distributed caching (using JBoss Cache, a standalone product) • Distributed deployment (farming) • Deployment API • Management API • Aspect-Oriented Programming (AOP)-support • JSP/Servlet 2.1/2.5 (Tomcat)
  • 72. 68 • JavaServer Faces 2.1 (Mojarra) • Enterprise Java Beans version 3 and 3.1 • JNDI (Java Naming and Directory Interface) • Hibernate-integration (for persistence programming; JPA) • JDBC • JTA (Java Transaction API) • Support for Java EE-Web Services like JAX-RPC (Java API for XML for Remote Procedure Call), JAX-WS, JAXB • SAAJ (soap with Attachments API for Java) • JMS (Java Message Service) integration / JavaMail • RMI-IIOP (JacORB, alias Java and CORBA) • JAAS (Java Authentication and Authorization Service) • JCA (Java Connector Architecture)-integration • JACC (Java Authorization Contract for Containers)-integration • Java Management Extensions Figure 45 : JBOSS AS7