Your SlideShare is downloading. ×
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,591
views

Published on


0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,591
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
210
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TABLE DES MATIÈRESListe des figures .................................................................................................................................................................... iListe des tableaux.................................................................................................................................................................iiIntroduction Générale .......................................................................................................................................................... 1Chapitre 1 Présentation du cadre de travail et du sujet....................................................................................................... 2Introduction.......................................................................................................................................................................... 31 Cadre du projet........................................................................................................................................................... 31.1 Présentation de l’entreprise............................................................................................................................... 31.2 Rôle de la Division Supervision ....................................................................................................................... 41.3 Le concept « Incident »..................................................................................................................................... 52 Présentation de sujet :................................................................................................................................................. 63 Conduite du projet...................................................................................................................................................... 63.1 Processus de développement............................................................................................................................. 63.2 Méthodologie Agile.......................................................................................................................................... 73.3 Scrum................................................................................................................................................................ 8Conclusion ......................................................................................................................................................................... 13Chapitre 2 Etat de lArt des Réseaux Cellulaires............................................................................................................... 14Introduction........................................................................................................................................................................ 151 Concept Cellulaire.................................................................................................................................................... 152 Evolution des réseaux cellulaires.............................................................................................................................. 162.1 Norme GSM ................................................................................................................................................... 162.2 Le standard GPRS........................................................................................................................................... 192.3 Téléphonie à mode paquet à haut débit : UMTS............................................................................................. 212.4 HSPDA........................................................................................................................................................... 232.5 HSUPA........................................................................................................................................................... 233 Concept de la qualité de service ............................................................................................................................... 233.1 Définition........................................................................................................................................................ 233.2 Critères de performances des réseaux 2G/3G ................................................................................................. 23Conclusion ......................................................................................................................................................................... 25Chapitre 3 Analyse des Besoins et Spécifications .............................................................................................................. 26Introduction........................................................................................................................................................................ 271 Objectifs ................................................................................................................................................................... 272 Spécification des exigences...................................................................................................................................... 272.1 Les acteurs système ........................................................................................................................................ 272.2 Le Backlog du produit :.................................................................................................................................. 282.3 Diagramme des cas d’utilisation globale : ...................................................................................................... 292.4 Sprint .............................................................................................................................................................. 292.5 Besoins Non Fonctionnels .............................................................................................................................. 39Conclusion ......................................................................................................................................................................... 39Chapitre 4 Conception....................................................................................................................................................... 40
  • 2. Introduction........................................................................................................................................................................ 413 Architecture du système : Modèle multi couches ..................................................................................................... 414 Conception ............................................................................................................................................................... 424.1 Conception détaillé......................................................................................................................................... 424.2 Sprint 1 ........................................................................................................................................................... 424.3 Sprint 2 ........................................................................................................................................................... 444.4 Sprint 3 ........................................................................................................................................................... 464.5 Sprint 4 ........................................................................................................................................................... 494.6 Diagramme de classes..................................................................................................................................... 50Conclusion ......................................................................................................................................................................... 51Chapitre 5 Réalisation ....................................................................................................................................................... 52Introduction........................................................................................................................................................................ 531 Environnement de travail ......................................................................................................................................... 531.1 Environnement matériel.................................................................................................................................. 531.2 Environnement logiciel................................................................................................................................... 532 Choix techniques...................................................................................................................................................... 532.1 Choix du standard de développement ............................................................................................................. 532.2 Choix du Framework pour la couche de présentation..................................................................................... 542.3 EJB3.1 ............................................................................................................................................................ 552.4 Choix du conteneur de la couche de persistance de données .......................................................................... 562.5 Choix du SGBD MySQL................................................................................................................................ 572.6 Choix du serveur d’application JBOSS AS 7.1 : ............................................................................................ 573 Phase d’implémentation ........................................................................................................................................... 573.1 Géolocalisation site 2G................................................................................................................................... 583.2 Géolocalisation site 3G................................................................................................................................... 583.3 Géolocalisation des Site HS............................................................................................................................ 603.4 Affichage des sites en voisinage d’un site HS ............................................................................................... 613.5 Test ................................................................................................................................................................. 624 Chronogramme de réalisation................................................................................................................................... 62Conclusion ......................................................................................................................................................................... 62Conclusion et Perspective ................................................................................................................................................. 63Bibliographie...................................................................................................................................................................... 64Acronymes......................................................................................................................................................................... 65Annexe A : JBOSS AS 7.................................................................................................................................................... 67Annexe B : La technologie AJAX...................................................................................................................................... 69
  • 3. iListe des figuresFigure 1 : Organisation de la division Supervision au sein de TUNISIANA .................................................... 4Figure 2:Types d’incidents BTS........................................................................................................................ 6Figure 3: Méthodologie Agile ........................................................................................................................... 8Figure 4:Sprint Scrum ....................................................................................................................................... 9Figure 5 : Processus Scrum ............................................................................................................................. 13Figure 6 Concept cellulaire ............................................................................................................................. 15Figure 7 Le Sous-système Radio..................................................................................................................... 16Figure 8:Le Sous-système dAcheminement ................................................................................................... 17Figure 9 : Le Sous-système dExploitation et de Maintenance........................................................................ 18Figure 10 : Architecture du Réseau GPRS ...................................................................................................... 20Figure 11 : Architecture de lUMTS................................................................................................................ 21Figure 12 : UTRAN......................................................................................................................................... 22Figure 13: diagramme cas dutilisation globale ............................................................................................... 29Figure 14 : Diagramme cas dutilisation traitement des fichiers...................................................................... 31Figure 15 : Cas dutlisation de sprint 2 ............................................................................................................ 33Figure 16 : Cas dutilisation Déterminer les sites HS ...................................................................................... 35Figure 17 Afficher Availibility 2G RAN......................................................................................................... 35Figure 18 Gestion BTS.................................................................................................................................... 37Figure 19 Cas dutilisations Afficher cellules................................................................................................. 38Figure 20 : Cas dutilisations Gestion Utilisateur ............................................................................................ 38Figure 21 modèle MVC................................................................................................................................... 41Figure 22 : Diagramme séquence objet authentification ................................................................................. 43Figure 23 : Diagramme de séquence de user story traitement des fichiersde données BTS........................... 43Figure 24 : Diagramme dactivité de traitement des fichiers de données BTS ................................................ 44Figure 25 : Diagramme séquence objet Map 2G............................................................................................. 45Figure 26: Diagramme dactivité « Géolocalisation des sites BTS »............................................................... 46Figure 27 : Diagramme séquence géolocalisation des incidents ..................................................................... 47Figure 28 : diagramme de séquence « l’Availibility 2G »............................................................................... 48Figure 29 : Diagramme dactivité « géolocalisation des incidents »................................................................ 49Figure 30 : Diagramme de séquence « ajouter utilisateur »............................................................................. 49Figure 31: Diagramme dactivité « ajouter utilisateurs »................................................................................ 50Figure 32:Diagramme de classe ...................................................................................................................... 51Figure 33 : JSF ................................................................................................................................................ 55Figure 34 EJB3.1............................................................................................................................................. 55Figure 35 : Architecture de la spécification JPA ............................................................................................. 57Figure 36 : MAP 2G........................................................................................................................................ 58Figure 37 : MAP 3G........................................................................................................................................ 58Figure 38 Recherche par LAC......................................................................................................................... 59Figure 39: courbe 2G RAN ............................................................................................................................. 59Figure 40: géo localisation des incidents......................................................................................................... 60Figure 41 : Exemple de fichiers incidents ....................................................................................................... 60Figure 42 : voisinage dun incident.................................................................................................................. 61Figure 43 : Chronogramme de Réalisation...................................................................................................... 62
  • 4. iiListe des tableauxTableau 1: Les seuils des KPIs........................................................................................................................ 25Tableau 2 Tableau 1 Backlog du Produit ........................................................................................................ 28Tableau 3: user story traitements des fichiers de données BTS....................................................................... 30Tableau 4 : User Story Traitements des fichiers des incidents ........................................................................ 30Tableau 5:user story Géo-localisation des sites BTS....................................................................................... 31Tableau 6:User Story “rechercher site ” .......................................................................................................... 32Tableau 7 : User Story “Afficher les voisinage ” ............................................................................................ 32Tableau 8:User Story “geolocalisation des incident ” ..................................................................................... 34Tableau 9:User Story “ KPI du réseau ”........................................................................................................ 34Tableau 10: User Story “Availibilite 2G/3G RAN ” ..................................................................................... 34Tableau 11: User Story gestion des cellules.................................................................................................... 36Tableau 12: User Story gestion des Utilisateurs.............................................................................................. 36Tableau 13: User Story gestion des BTS......................................................................................................... 37
  • 5. 1Introduction GénéraleLes réseaux mobiles ont connu un large succès avec l’apparition de la norme de deuxièmegénération qui a permis essentiellement d’obtenir une meilleure qualité de voix. Afin depermettre 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 defranchir le pas vers les réseaux cellulaires de troisième et de quatrième génération.Il savère donc que la qualité de service, dans ce domaine comme dans beaucoup dautres,constitue une source fondamentale de différenciation, aussi déterminante que le prix duservice 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 toutesles performances réalisées et par conséquent, lintérêt doutils dingénierie adaptés. L’un desmoyens de contrôle et de supervision qui s’offrent aux opérateurs téléphoniques estl’utilisation d’outils ou applications qui rendraient facile la gestion des équipementsconstituant leurs réseaux, entre autres les équipements BTS dont le contrôle ainsi la gestiondes 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 objectifla conception et la réalisation d’un portail web pour l’évaluation des performances duréseau de l’opérateur Tunisiana.Le présent rapport se décompose en cinq chapitres, nous présentons le contenu de chaquechapitre. Dans le premier chapitre, nous présentons lenvironnement du travail ainsi que lesujet à traiter. Le second chapitre est consacré à la présentation des architectures desréseaux cellulaires tels que GSM, GPRS, et UMTS et les étapes de lévolution de cesréseaux. Nous traitons aussi dans ce chapitre le concept et les critères de la qualité deservice (QoS). Le troisième chapitre traite l’analyse des besoins et des spécifications del’application à développer. La conception globale et détaillée de l’outil que nous avonsréalisé fait l’objet du quatrième chapitre .Enfin, le dernier chapitre de ce rapport illustrerales réalisations effectuées au cours de ce projet.
  • 6. Chapitre 1 : Présentation du cadre de travail et du sujet2Chapitre 1Présentation du cadre de travail et dusujet
  • 7. Chapitre 1 : Présentation du cadre de travail et du sujet3IntroductionAvant de traiter le sujet du présent projet de fin d’études, il convient de présenterl’environnement dans lequel il a été mené à bien. En effet, c’est de l’environnement quedé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 TUNISIANApremier opérateur privé de télécommunications en Tunisie.1 Cadre du projet1.1 Présentation de l’entrepriseOrascom Telecom a octroyé, le 11 mai 2002, la deuxième licence de téléphonie mobile enTunisie (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’unepasserelle internationale, d’une durée de quinze ans, renouvelable deux fois tous les cinqans et une exclusivité jusqu’au 30 juin 2004. Ainsi TUNISIANA a réalisé son lancementcommercial le 27 décembre 2002 pour atteindre jusqu’à aujourd’hui 100% de couverturede la population Tunisienne.Depuis son lancement, grâce à la qualité des ressources humaines et aux performancestechniques qui ne sont plus à démontrer et une qualité du réseau reconnue à l’échellenationale 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 demarché.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’unprogramme à trois dimensions : Acquisition, Fidélisation, Consommation.TUNISIANA est une entreprise en plein essor, l’hiérarchie interne est conçue pour faciliterles promotions et garantir ainsi un maximum de motivation pour le personnel. La DivisionSupervision dans laquelle nous avons effectué notre Projet est ainsi conçue comme suit :
  • 8. Chapitre 1 : Présentation du cadre de travail et du sujet4Division SupervisionService supervision frontOffice Service supervision backOfficeFigure 1 : Organisation de la division Supervision au sein de TUNISIANA1.2 Rôle de la Division SupervisionLe service supervision Back Office se charge de détecter les dysfonctionnements qui n’ontpas un impact direct ou immédiat, majeur ou critique sur la qualité de service offerte auclient. 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 sujet51.3 Le concept « Incident »Apres sept ans et plus depuis son lancement commercial, TUNISIANA est devenue matureen terme de prestataire de service de téléphonie mobile, la clientèle est devenu assezgrande et diversifiée, l’environnement est de plus en plus concurrentiel avec l’arrivée d’untroisiè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 vigilanteconcernant 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 peutprovoquer un dysfonctionnement ou qui a un impact immédiat sur le client pour pouvoirgé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 duréseau GSM, cest-à-dire les BTS et les BSCLes types des incidents : Système : ce sont des incidents dus à un élément défectueux dans un équipementréseau (carte électronique, capteur, câble…..) Transmission: Tous les équipements réseau sont connectés les uns par rapport auxautres selon un routage bien spécifique, la mise Hors Service de l’une de ces routesimpacte directement un équipement, c’est pour cela que le réseau de transmissionest supervisé Environnement : un incident peut se déclencher par un facteur externe au réseau quipeut être une coupure courant, un facteur climatique, un défaut de climatisation
  • 10. Chapitre 1 : Présentation du cadre de travail et du sujet6Figure 2:Types d’incidents BTS2 Présentation de sujet :Ce projet de fin d’étude porte sur la réalisation d’un outil de suivi de performance duréseau de TUNISIANA et à présenter L’impact de disfonctionnement d’un site sur la QOSde réseaux 2G/3G.3 Conduite du projet3.1 Processus de développementUn processus de développement définit une séquence d’étapes, en partie ordonnée, quiconcoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un systèmeexistant. 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 sujet7l’adéquation du projet au processus de développement peut largement affecter le sort d’unprojet informatique.3.2 Méthodologie AgileMéthode de développement informatique tournée vers le client. Le développement agiletire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17personnalités dont Kent Beck, Ward Cunnigham, Martin Fowler ou Dave Thomas. Douzeprincipes ont été définis. Parmi les principaux: Parvenir à la satisfaction du client par le biais dun 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 à toutmoment du projet; Mettre en place une coopération quotidienne entre développeurs etdécideurs/commerciaux; Motiver les développeurs par un environnement, un soutien et une confiancesolides; Faire simple, mais pas simpliste; Laisser léquipe sorganiser au mieux de ses possibilités.Il existe une dizaine de méthodologies "officielles" sadaptant chacune à desbesoins différents. Certaines sont plus adaptées aux petites équipes, comme Crystal,XP, Scrum, tandis que dautres sont prévues pour des groupes conséquents, parexemple RAD, RUP et ASD.Nous avons opté pour la méthode de développement agile Scrum, car elle est très adaptéeaux projets comme le mien et dont les besoins sont constamment redéfinis.
  • 12. Chapitre 1 : Présentation du cadre de travail et du sujet8Figure 3: Méthodologie Agile3.3 ScrumDavantage qu’une méthode formelle, Scrum peut être vu comme un frameworkméthodologique – ses fondateurs parlent d’organisationnel pattern – dont l’implémentationdoit être ajustée en fonction des caractéristiques techniques, organisationnelles etculturelles des projets qui souhaitent la mettre en œuvre (Scrum, au demeurant, ne limitepas son champ d’application aux seuls projets informatiques : ses principes sontapplicables pour toute activité visant à produire un résultat).Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies etd’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èrementpiloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers dece prisme. Scrum identifie trois acteurs :
  • 13. Chapitre 1 : Présentation du cadre de travail et du sujet9 le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle etest à même de réaliser les arbitrages nécessaires à la priorisation desdéveloppements. Son rôle est absolument essentiel, et son respect des règles du jeuest la pierre angulaire du succès d’un projet agile. Dans notre cas il s’agit d’ImedHamza. le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser lacapacité 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 deScrum. 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 admiscomme une borne supérieure), et qui prend en charge le développement du produit(planification, conception, codage, tests, documentation) sans spécialisation desrôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et doncdépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec lesapproches 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 de2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planificationinitiale.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 sujet10Scrum définit également trois artefacts : le Product Backlog, le Sprint Backlog le Burndown Chart, qui est une représentation graphique très simple del’avancement du projet (un Burndown Chart est produit pour chaque Sprint, unautre pour la version du produitLe Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlogsont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée etfaiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métiers duproduit. A minima, un élément du backlog (ou une histoire) comporte typiquement lesinformations 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 etl’Equipe comprennent approximativement de quoi il est question l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément auxyeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeurrelative compte l’estimation initiale – exprimée en points de complexité, et dont la valeur estdéterminée par l’Equipe. comment faire la démo ? – cela correspond globalement à la spécification d’un testfonctionnel simple. des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyervers d’autresLe Product Backlog peut également contenir des éléments techniques – mais il estindispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur deProduit puisse lui affecter une valeur. Il peut être conservé sous différentes formes, la plusfréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.LeProduct 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 sujet11de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance etl’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 deScrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe etle Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’estdurant cette cérémonie que l’estimation fine de la charge de développement de chaquehistoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objetd’une estimation de charge –exprimée en heures ou en jours. Il est important de noter quec’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat decette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités quel’Equipe s’engage à produire durant l’itération naissante, et liste les tâchescorrespondantes.La charge totale du Sprint Backlog ne doit pas excéder la capacité de production del’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cettecapacité de production, ou vélocité estimée).Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pourson 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’objetd’une démonstration publique.Les méthodes agiles sont inspirées des pratiques industrielles de la production en fluxtendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par leterme Lean. L’une des caractéristiques de cette approche est de ne jamais figer lesmé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 estde ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façongénérale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité del’Equipe, et ne fait pas l’objet de négociationsAfin de faciliter cette démarche, Scrum intègre un certain nombre de cérémoniesadditionnelles – 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 sujet12en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies faitpartie 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, etdont l’objectif est de maintenir chacun au courant de l’activité de tous, dedéterminer les tâches de la journée et d’identifier les éventuels obstacles quiralentissent ou empêchent la progression du sprint la revue de sprint (SprintReview), qui consiste pour l’essentiel, au terme de chaque itération, à faire unedémonstration publique du résultat du sprint ; cette cérémonie permet de garantir lecaractère incrémental du développement (pour être démontré, le produit doit êtreutilisable) mais aussi de recueillir un retour régulier des commanditaires aux finsd’ajuster le contenu du backlog de produit la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner auterme de chaque sprint afin d’identifier les erreurs commises lors du sprintprécédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer leprocessus ; la rétrospective est une cérémonie capitale qui incarne l’un desprincipes 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 soncomportement en conséquence ».
  • 17. Chapitre 1 : Présentation du cadre de travail et du sujet13Figure 5 : Processus ScrumConclusionDans ce chapitre, nous avons essayé de définir le cadre de notre projet en termesorganisationnel et professionnel. Ensuite nous avons présenté la notion d’incident tout eninsistant sur l’importance du processus de résolution des incidents. Ainsi le sujet à traiterqui est le développement d’un outil pour le suivi des performances du réseau Tunisiana2G/3G. A ce stade, on va étudier et présenter les architectures des réseaux 2G /3G etdéfinir aussi les concepts liés à la qualité de service, ce qui fera lobjet du deuxièmechapitre
  • 18. Chapitre 2 : Etat de l’art des réseaux cellulaires14Chapitre 2Etat de lArt des Réseaux Cellulaires
  • 19. Chapitre 2 : Etat de l’art des réseaux cellulaires15IntroductionCe chapitre est un état de lart de la téléphonie radio mobile dans lequel nous présenterons lecontexte dans lequel sinscrit le présent projet afin de pouvoir se focaliser sur les composantesde notre sujet. Nous étudierons successivement les interfaces radio mobiles mises en jeu,ensuite, nous traiterons le concept de qualité de service.1 Concept CellulaireLe concept cellulaire constitue le principe de base des réseaux radio mobiles. La zonedesservie par un opérateur est divisée en cellules alimentées à partir dune station de base.Une cellule représente lensemble des points du territoire couvert par une même BTS (BaseTransceiver Station) et oïl le signal transmis par cette BTS est le plus fort .Chaque cellule estidentifiée par un BSIC (Base Station Identity Code). Le mobile est toujours connecté à la BTSla plus proche de point de vue radio. [1]Figure 6 : Concept cellulaireL’utilisation du concept cellulaire permet dajuster les ressources radio à la demande en trafic.Le principe se traduit par des zones à forte concentration de BTS couvrant de petites celluleset des zones rurales à faible concentration de BTS couvrant des cellules.
  • 20. Chapitre 2 : Etat de l’art des réseaux cellulaires162 Evolution des réseaux cellulaires2.1 Norme GSMLa norme GSM est un système cellulaire de transmission numérique. Le réseau GSM a pourrôle essentiellement de permettre des communications entre abonnés mobiles (GSM) etabonnés du réseau téléphonique commuté (RTC ou réseau fixe). Le GSM qui a fait unerupture avec les systèmes cellulaires analogiques, utilise les bandes de fréquences 900 MHz1800 MHz et utilise la technique de multiplexage F-TDMA ce qui offre un multiplexagetemporel et fréquentiel à la fois.2.1.1 Architecture Générale et EquipementsLe réseau GSM comporte les 3 sous-ensembles : Le Sous-système Radio BSS : responsable dassurer et gérer les transmissions radios.Une station mobile est un terminal de données qui transmet et reçoit des messages duréseau. La «Base Transceiver Station» ou (BTS)»représente lensemble démetteurs etde récepteurs fixes. Elle a pour rôle déchanger des messages avec les stations mobilesprésentes dans la cellule quelle contrôle. Nous trouvons aussi le contrôleur de stationde base nommé «Base Station Controller » ou (BSC). Il communique avec une ouplusieurs BTS.Figure 7 Le Sous-système RadioLe Sous-système Réseau NSS : comporte lensemble des fonctions nécessaires pourles appels et la gestion de la mobilité .On trouve le commutateur du réseau «MobileSwitching Centre» ou (MSC) qui a pour rôle le contrôle de la BSC .Dune part, ilpermet linterconnexion entre un réseau GSM et une réseau téléphonique publicinterconnecte un réseau GSM avec le réseau téléphonique public RTCP/RNIS, Dautrepart, il présente linterface des bases de données du réseau GSM avec le sous-système
  • 21. Chapitre 2 : Etat de l’art des réseaux cellulaires17radio. Ces bases de données enregistrent la localisation des abonnés. A ce niveau, ontrouve les entités : VLR «Visitor Location Register» : Une base de données représentant lenregistreurdes visiteurs. HLR «Home Location Register» : Une base de données contenant les informationsrelatives à chaque utilisateur (abonné) à savoir lIMSI et lIMEI. AUC «Authentification Centre» : Une base de données qui permetlauthentification des demandes de services En effet, quand cet abonné demandelaccès à un service, un équipement du réseau qui veut contrôler la validité desprivilèges du demandeur interroge le HLR de labonné. Le HLR dun abonnécontient des informations permanentes. En revanche, un VLR enregistre lesinformations temporaires, relatives à une station mobile.Figure 8:Le Sous-système dAcheminement Le Sous-système dExploitation et de Maintenance OSS : permet à lopérateurdexploiter et de contrôler son réseau. Les équipements (OMC, EIR et AUC) assurentensemble ladministration du réseau. LOMC est responsable de la gestion durendement, la gestion de la sécurité, et les opérations de maintenance. LEIR est unebase de données qui peut être consultée lors des demandes de services dun abonnépour vérifier que le terminal utilisé est autorisé à fonctionner sur le réseau. LAUC estune base de données qui permet lauthentification des demandes de services.
  • 22. Chapitre 2 : Etat de l’art des réseaux cellulaires18Figure 9 : Le Sous-système dExploitation et de Maintenance2.1.2 Identités dans un réseau GSMNous sintéresse dans cette partie aux paramètres didentification des clients dans le réseau. IMSIIMSI (International Mobile Subscriber Identity) est lidentifiant unique affecté à un abonnéqui souscrit à un abonnement mobile auprès dun opérateur. Ce numéro dIMSI a étépréalablement stocké sur la carte SIM (Subcriber Identity Module). Le numéro dIMSI nestpas connu de la part de labonné mobile et nest utilisé que par le réseau GSM. LIMSI estconstitué de trois sous-champs : MCC (Mobile Country Code) : Il présente le code du pays du réseau. MNC (Mobile Network Code) : Il sagit du code du réseau mobile. Il identifie demanière unique le réseau GSM à lintérieur dun pays. MSIN (Mobile Subscriber Identification Number) : il sagit du numéro didentificationdu mobile. Il identifie labonné mobile à lintérieur du réseau mobile. MSISDNMSISDN (Mobile Station ISDN Number) est le numéro de téléphone associé à la stationmobile .Il contient les trois sous-champs suivantes : CC (Country Code) : présente le code du pays dans lequel labonné mobile ainscrit son abonnement. NDC (National Destination Code) : Il sagit du numéro national du réseau GSMdans lequel un client a souscrit un abonnement. SN (Subscriber Number) : Il sagit du numéro d’abonné IMEILIMEI, (International Mobile Equipment Identity) permet didentifier de façon unique unterminal mobile au niveau international. Ce numéro est donné par le constructeur du terminal
  • 23. Chapitre 2 : Etat de l’art des réseaux cellulaires19mobile. LIMEI est utilisé par les opérateurs GSM pour lutter et défendre contre les vols determinaux ou pour empêcher laccès au réseau à des terminaux.2.1.3 Les limites de la Norme GSMLe 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 desannées 1990 que cette norme atteindrait rapidement ses limites en termes de support dunservice de transmission de données à haut débit. De plus et avec le progrès dans les servicesproposés par linternet, il parait nécessaire de coupler la mobilité avec laccès à linternet. Pourcela les opérateurs ont pensé à migrer de la norme GSM à une autre norme qui évite leslacunes et les défauts du système de seconde génération et qui répond aussi au défi de latransmission de données à haut débit. Cette évolution débute par la phase de lintroduction duGPRS avec la transmission en mode paquet sur la voie radio.2.2 Le standard GPRS2.2.1 Lapport de la technologie GPRSCette technologie étend larchitecture de la norme GSM et permet un transfert de données à undébit plus élevé tout en optimisant lutilisation des ressources. La technologie GPRS donne lapossibilité datteindre un débit maximal théorique de 171,2 Kbit/s ce qui correspond pourlutilisateur à un débit maximal de 114 Kbit/s dans les conditions optimales.Donc la mise en place dun réseau GPRS permet à un opérateur de proposer de nouveauxservices de type data avec un débit de données 5 à 10 fois supérieur au débit maximumthéorique dun réseau GSM.Le GPRS spécifie une technique de transmission en mode paquet qui immobilise le canal decommunication. Cet action donne la possibilité davoir une connexion permanente et unefacturation à la donnée ce qui présente un avantage non négligeable pour lutilisateur qui peutrester connecté sans surcoût et ne paye que le coût du volume échangé de données le contrairede GSM où lutilisateur est facturé par le temps de connexion ainsi il paye même sil neconsomme pas la capacité du réseau.2.2.2 Architecture Matérielle du GPRSLintégration du GPRS nécessite lajout de quelques équipements et des mises à jour auxentités du réseau GSM pour que lancien réseau accepte lintégration de la nouvelle
  • 24. Chapitre 2 : Etat de l’art des réseaux cellulaires20technologie tout en conservant ses fonctionnalités. La figure ci-dessous présente unearchitecture de la norme GPRS.Figure 10 : Architecture du Réseau GPRSComme la figure 9 le présente, il existe coté NSS un réseau de commutation de paquets enparallèle du réseau de commutation de circuit. Pour cela on ajoute deux entités (SGSN etGGSN). Le SGSN est le dual paquet du MSC/VLR circuit. Il est connecté au BSS et à desSGSN et GGSN voisins. Le SGSN joue le même rôle réalisé par le VLR dans la gestion demobilité. En effet, il soccupe aussi de la compression et cryptage des données. Pour le GGSNil sagit dun nœud dinterfonctionnement entre le réseau de données extérieur et le réseaumobile de transfert de paquets.2.2.3 La technologie EDGELEDGE peut être considéré comme une amélioration du GPRS. Les opérateurs font lerecours à cette technologie car la norme UMTS les oblige à déployer un autre réseau physiqueet donc des investissements très lourdes. LEDGE présente lavantage de pouvoir utiliser lesinfrastructures déjà déployées contrairement à lUMTS.LEDGE est mis en place afin daccroître la capacité des données par rapport au GPRS. Lavitesse de transfert de données pour un réseau EDGE peut théoriquement atteindre un débitmaximum de 384 Kbps contre seulement 114 Kbps pour un réseau GPRS.
  • 25. Chapitre 2 : Etat de l’art des réseaux cellulaires21Même avec lintroduction du GPRS et EDGE, le débit pratique dans des conditions optimalesne passe pas les 120 Kbit/s ce qui ne pas correspond aux attentes des utilisateurs .Pour cela lesopérateurs se trouvent obligés à sacrifier financièrement et installer le réseau de troisièmegénération.2.3 Téléphonie à mode paquet à haut débit : UMTSLUMTS ou 3G est une norme pour les réseaux mobiles permettant de fournir aux utilisateursune meilleure qualité de service. LUMTS est capable doffrir de nouvelles applicationsmultimédias et des services à valeur ajoutée telle que la visiophonie et internet à haut débit.LUMTS utilise des fréquences plus élevées que le standard 2G. LUMTS occupe les bandespassantes : 1885-2025MHz et2110-2200MHz.2.3.1 Architecture de lUMTSLe réseau UMTS possède une architecture flexible et modulaire. Larchitecture illustrée à lafigure 10, est composée de trois entités qui sont léquipement de lusager(UE), le réseaudaccès radio (UTRAN) et le réseau cœur (CN). En effet, chaque équipement doit réaliser unefonction bien déterminée dans le réseau, alors que des interfaces déchange, notéspar Uu et Iu, assurent les échanges et la communication entre les différentes entités du réseau.[6]Figure 11 : Architecture de lUMTS
  • 26. Chapitre 2 : Etat de l’art des réseaux cellulaires222.3.2 Le domaine UE (User Equipement)Il comprend tous les équipements terminaux et permet laccès à linfrastructure du réseau et àses services par le biais de linterface Uu. [2]2.3.3 UTRAN (UMTS Terrestrial Radio Access Network)Il fournit les ressources radio et les mécanismes nécessaires à lUE pour accéder au CN. Ilpermet la maintenance et la libération des canaux radio entre le terminal et le réseau coeur CNet la gestion de ressources radio. LUTRAN est composé dun ensemble de sous-systèmesnommés RNC et de plusieurs stations de base appelé NodeB. NodeB : il a comme rôle la transmission et la réception dinformations entrelUTRAN et un ou plusieurs équipements usagers. Les UEs sont connectés auNode B via linterface Uu, qui assure la connexion radio. Le Node B soccupe de latransmission et de la réception du signal radio, de la modulation/démodulation, ducodage de canal et ladaptation du débit de transmission. RNC: Il assure essentiellement le routage des communications entre les Nodes Bet le réseau coeur dune part et le contrôle et la supervision des Noeuds B dautrepart par le biais de linterface IuB.Figure 12 : UTRAN2.3.4 Riau Cœur CN (Core Network)Le CN assure la connexion entre les différents réseaux daccès radio dune part et les autresréseaux externes dautre part tels que RTCP et les réseaux Internet. Sa principalefonctionnalité est la commutation et le routage des données utilisateurs vers la destinationcorrespondante, la gestion de la mobilité, de lauthentification, de la sécurité des échanges, dela taxation et de signalisation entre les terminaux mobiles et les réseaux distants via linterface
  • 27. Chapitre 2 : Etat de l’art des réseaux cellulaires23radio. Dans le rôle dacheminement, le réseau coeur se compose de serveurs et de passerellesqui se divisent entre deux sous-systèmes principaux: le domaine CS et le domaine PS.2.4 HSPDAHSPDA (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 desperformances dix fois supérieures à la 3G.Cette évolution basée essentiellement sur latechnologie WCDMA permet à un utilisateur de télécharger à des débits théoriques de 1,8Mbit/s ; 3,6 Mbit/s ; 7,2 Mbit/s et 14,4 Mbit/s. Donc, il sagit dune amélioration qui offre desoccasions de téléchargement à des très hauts débits de telle façon quon peut atteindre un débitde téléchargement qui dépasse 7,2 Mbit/s avec la Release7.2.5 HSUPAHSUPA (High Speed Uplink Packet Access) est une norme de haut-débit mobile de troisièmegénération dont les standards ont été définies et diffusés par le 3GPP dans la sixième éditiondu référentiel UMTS (Release 6 de lUMTS). HSUPA présenté comme un successeur de latechnologie HSPDA, vient daméliorer le débit sur la voie montante (Uplink) qui peutatteindre à ce niveau 5,8 Mbit/s alors que le débit descendant (Downlink) reste le même quecelui de son prédécesseur (HSPDA) qui atteint 14 Mbit/s.3 Concept de la qualité de service3.1 DéfinitionGénéralement, la qualité de service ou Quality of Service (QoS) est la capacité de transférerdans les bonnes conditions un type de trafic donné, en termes de disponibilité, débit, et délaide transition. La qualité de service pour le réseau détermine le degré de satisfaction delutilisateur aux services offerts.3.2 Critères de performances des réseaux 2G/3GAfin de permettre aux opérateurs dobtenir des informations sur la qualité du service offert parleur réseau et de loptimiser, 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 desystème. Cette valeur est obtenue à partir dune ou de plusieurs mesures brutes relevées par
  • 28. Chapitre 2 : Etat de l’art des réseaux cellulaires24des compteurs spécifiques. Ces indicateurs permettent la localisation des anomalies de réseauet par suite, lidentification et le diagnostic des causes de ces problèmes afin de réagir avecdes actions correctives adéquates.Dans le but doffrir 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éeset par les mesures radio. Les causes probables de ce problème sont les suivants : Mauvaise configuration du réseau cest-à-dire problème lié à la position des sites, oules types dantennes. Problème dinstallation qui peut être due à la perte des puissances dans les câbles. Problème de maintenance.3.2.2 La disponibilité du réseau :Cest la probabilité dobtention dun nouvel appel. La diminution de taux dappel aboutisimplique que les abonnées ne peuvent pas établir une communication. Les actions de léchecdétablissement dappel sexpliquent par : Le niveau daccès minimum dans la cellule. Linterférence et la mauvaise couverture radio.3.2.3 La qualité de voix :Lopérateur agit contre le problème de la mauvaise qualité de communication, par les mesuressystème et par les analyseurs de la qualité vocale. Les causes de dégradation de la qualité dela voix sont : La hors couverture. La mauvaise installation. La qualité des terminaux.3.2.4 Les coupures dappels :La coupure de communication peut être engendré par : La mauvaise couverture. Les interférences.
  • 29. Chapitre 2 : Etat de l’art des réseaux cellulaires25Si un des KPI excède les seuils fixés par lopérateur, le superviseur du réseau vient de signalerun problème détecté au niveau de la fonctionnalité quassure cet indicateur. Généralement, ceproblème est généré à partir dun problème ou une anomalie de couverture, dinsuffisance decapacité, dinterférence, ou dun problème mauvais paramétrage du réseau.A titre dexemple, si nous enregistrons un taux de coupure de lappel supérieur à 2%, alorsnous avons un problème de maintien dappel qui peut 1tre causé par la mauvaise couverture,linterférence, problème lors du handover (dans ce cas on consultera les taux de succès dehandover) ou un mauvais paramétrage du réseau. De plus, si le taux de succès delétablissement dun service est inférieur à 95%, dans ce cas nous avons un problème daccèsau réseau causé par la capacité, linterférence ou un problème de paramétrage du réseau.Onprésente ci-dessous un tableau qui illustre les seuils de quelques KPI :Tableau 1: Les seuils des KPIsConclusionAprès avoir traité tout le long de ce deuxième chapitre les architectures des réseaux cellulairesainsi que le concept de la qualité de service(QoS), en présentant les différents paramètres etcritères de performance de la QoS, nous présentons passer à l’analyse des besoins à travers lechapitre suivant.
  • 30. Chapitre 3 : Analyse des besoins et spécifications26Chapitre 3Analyse des Besoins et Spécifications
  • 31. Chapitre 3 : Analyse des besoins et spécifications27IntroductionNous 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 casd’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èmerépondant aux besoins de TUNISIANA ensuite spécifier les acteurs pour arriver à la fin à laprésentation des cas d’utilisation.1 ObjectifsLobjet de ce projet est la conception et la réalisation dun outil destiné à gérer et à présenterL’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 lacible globale, pour avoir le dossier fonctionnel des besoins (fonctionnels et techniques).2 Spécification des exigencesDans cette section nous identifions une liste d’exigences fonctionnelles et non fonctionnellesdu système à concevoir. Certaines exigences sont ajoutées pour clarifier d’avantage lesbesoins des utilisateurs.2.1 Les acteurs systèmeCette application est destinée à l’équipe de supervision de Tunisiana. La structure de cetteapplication ainsi que tous les services proposés par l’application, seront détaillés dans leschapitres 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 tantqu’administrateur, il n’a pas le droit de modifier les données des fiches. Cependant, il aura lapossibilité de prendre l’identité d’une personne pour avoir accès à ses droits, et effectuer ainsides modifications.
  • 32. Chapitre 3 : Analyse des besoins et spécifications282.1.2 Utilisateur :C’est léquipe de supervision qui a le droit de manipuler lapplication.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. Cest en quelque sorte une « liste prioriséedexigences, dhistoires, de caractéristiques, ou autre ». Le backlog produit est maintenu parle product owner.Nous avons choisi d’intégrer dans notre système les fonctionnalités les plus importantes quisont 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 Tunisianasur cette zone.StoryIDStory name Status Sprint Priority Estimation(j)1 analyse et traitement des données Done 1 1 182 Géolocalisation des sites 2G/3G sur google maps Done 2 1 183 calculer et afficher lavaibility 2G/3GRAN Done 3 1 104 traitement des incidents et déterminer les sites HSet limpact sur le reseauDone 3 2 205 afficher tous les cellules du réseau Tunisiana Done 4 2 76 gestion d’utilisateur Done 4 3 77 gestion BTS Done 4 3 7Tableau 2 Tableau 1 Backlog du Produit
  • 33. Chapitre 3 : Analyse des besoins et spécifications292.3 Diagramme des cas d’utilisation globale :L’approche consiste à regarder le système à construire de l’extérieur, du point de vue del’utilisateur et des fonctionnalités qu’il attend. Chaque cas d’utilisation sera une spécificationde ce qu’il sera possible de demander de l’extérieur à l’entité ainsi représentée.Figure 13: diagramme cas dutilisation globaleCette figure nous donne une vue globale sur les différents besoins fonctionnels ainsi lesacteurs qui interagissent avec notre application.2.4 SprintAprès avoir spécifié les besoins avec le « Product Owner », nous avons organisé les tâchessous la forme de « Sprints » où chaque sprint aura une durée de vingt jours ou plus avec pourobjectif 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 seronscomposés comme suit :2.4.1 Sprint 1Le sprint 1 est Généralement de criticité élevée. Ce sprint est composé de Deux User Storiesdécrits ci-dessous.
  • 34. Chapitre 3 : Analyse des besoins et spécifications30User Story 1Tableau récapitulatif du première User Story “ Traitements des fichiers de données BTS ”Id 1 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Traitements des fichiers des données BTSValeur/criticité 1 Criticité élevéeEstimation 10jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Serveur des fichiers2. Sélections des fichiers3. Sélections de données4. organisation et gestion des données BTSPourquoi ? Déterminées l’équipement du réseauTableau 3: User Story traitements des fichiers de données BTSUser Story 2Tableau récapitulatif du première User Story “ Traitements des fichiers des incidents ”Id 2 Projet Portail Web d’Evaluation de Performances duRéseau Tunisiana.Nom Traitements des fichiers des incidentsValeur/criticité 1 Criticité élevéeEstimation 8jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Serveur des fichiers2. Sélections des fichiers3. Sélections de données4. Sélections des BTS HSPourquoi ? Suivre l’état des équipements réseauxTableau 4 : User Story Traitements des fichiers des incidents
  • 35. Chapitre 3 : Analyse des besoins et spécifications31Figure 14 : Diagramme cas dutilisation traitement des fichiers2.4.2 Sprint 2Ce sprint est composé de trois User Stories suivants :User Story 3Tableau récapitulatif du première User Story “Géolocalisation des sites BTS ”Id 3 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Géo-localisation des sites BTSValeur/criticité 1 Criticité élevéeEstimation 6jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. Sélections des Bts 2G/3G3. Sélections des cordonnées GPS4. géo-localisation sur google MAPSPourquoi ? Déterminer les emplacements des sitesTableau 5:User story Géolocalisation des sites BTS
  • 36. Chapitre 3 : Analyse des besoins et spécifications32User Story 5Tableau récapitulatif du première User Story “rechercher site ”Id 3 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Rechercher siteValeur/criticité 2 Criticité élevéeEstimation 6jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. Sélections des BTS 2G/3G3. Sélections des cordonnées GPS4. rechercher in site5. géo-localisation sur google MAPSPourquoi ? Déterminer les emplacements d’un site bien déterminéTableau 6:User Story “rechercher site ”User Story 6Tableau récapitulatif du première User Story “Afficher les voisinage ”Id 6 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana..Nom Afficher les voisinagesValeur/criticité 2 Criticité élevéeEstimation 6jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. Sélections des Bts 2G/3G3. Sélections des cordonnées GPS5. déterminer la distance des voisinages4. géolocalisation sur google MAPSPourquoi ? Déterminer les emplacements des sites voisinage d’un site choisiTableau 7 : User Story “Afficher les voisinage ”
  • 37. Chapitre 3 : Analyse des besoins et spécifications33La figure suivante présente le digramme de cas d’utilisation résultant du Sprint 2Figure 15 : Cas dutlisation de sprint 22.4.32.4.4 Sprint 3Ce sprint est composé de trois User Stories suivants :User Story 7Tableau récapitulatif du première User Story “géolocalisation des incident ”Id 7 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom géolocalisation des incidentsValeur/criticité 3 Criticité élevéeEstimation 10jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. Sélections des BTS 2G/3G3. Sélections des cordonnées GPS5. sélections des incidents6. déterminer les sites HS4. géolocalisation sur google MAPSPourquoi ? Déterminer les emplacements des sites HS
  • 38. Chapitre 3 : Analyse des besoins et spécifications34Tableau 8:User Story “géolocalisation des incident ”User Story 8Tableau récapitulatif du première User Story “KPI du réseau ”Id 8 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana..Nom Mesure QOS du réseauValeur/criticité 3 Criticité élevéeEstimation 10jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. Sélections des BTS 2G/3G3. choix des KPI4. afficher KPIPourquoi ? Déterminer les QOS de réseauTableau 9:User Story “ KPI du réseau ”User Story 9Tableau récapitulatif du première User Story “ Availibility 2G/3G RAN ”Id 9 Projet d’Evaluation de Performances du RéseauTunisiana.Nom Mesure 2G/3G RANValeur/criticité 3 Criticité élevéeEstimation 5jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. déterminer la liste des incidents3. calculer 2G/3G RAN4. afficher courbePourquoi ? Déterminer les QOS du réseauTableau 10: User Story “Availibilite 2G/3G RAN ”
  • 39. Chapitre 3 : Analyse des besoins et spécifications35Figure 16 : Cas dutilisation Déterminer les sites HSFigure 17 Afficher Availibility 2G RAN
  • 40. Chapitre 3 : Analyse des besoins et spécifications362.4.5 Sprint 4Ce sprint est composé de trois User Stories suivants :User Story 8Tableau récapitulatif du première User Story “gestion des cellules”Id 8 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Gestion des cellulesValeur/criticité 4 Criticité élevéeEstimation 7jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. déterminer la liste des cellules3. afficher tous les cellules4. recherche par plusieurs critères5. modifier/ supprimer/ ajouter des cellulesPourquoi ? Gestion des cellulesTableau 11: User Story gestion des cellulesUser Story 9Tableau récapitulatif du première User Story “gestion des Utilisateurs”Id 9 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Gestion des UtilisateursValeur/criticité 4 Criticité élevéeEstimation 7jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. déterminer la liste des utilisateurs3. afficher tous les utilisateurs4. modifier / supprimer / ajouter des utilisateursPourquoi ? Gestion des utilisateursTableau 12: User Story gestion des Utilisateurs
  • 41. Chapitre 3 : Analyse des besoins et spécifications37User Story 10Tableau récapitulatif du première User Story “gestion des BTS”Id 10 Projet Portail Web d’Evaluation de Performancesdu Réseau Tunisiana.Nom Gestion des cellulesValeur/criticité 4 Criticité élevéeEstimation 7jActeurs Les utilisateurs cible sont les consultants et les managersSujet1. Connexion à Base de données2. déterminer la liste des cellules3. afficher tous les cellules4. recherche par plusieurs critères5. modifier / supprimer / ajouter des cellulesPourquoi ? Gestion des BTSTableau 13: User Story gestion des BTSLes figures suivantes présentes les digrammes de cas d’utilisation résultant du Sprint3Figure 18 : Gestion BTS
  • 42. Chapitre 3 : Analyse des besoins et spécifications38Figure 19 : Cas dutilisations Afficher cellulesFigure 20 : Cas dutilisations Gestion Utilisateur
  • 43. Chapitre 3 : Analyse des besoins et spécifications392.5 Besoins Non FonctionnelsS’agit des besoins qui caractérisent le système. Ce sont des besoins en matière deperformance, de type de matériel ou le type de conception. Ces besoins peuvent concerner lescontraintes dimplémentation (langage de programmation, type SGBD, de systèmedExploitation...)Dans le cadre de ce travail, lapplication devra être extensible, cest-à-dire quil pourra y avoirune possibilité dajouter ou de modifier de nouvelles fonctionnalités.Lapplication devra être capable de : Rapidité : l’application traite souvent un grand volume de données, elle doit alorseffectuer ces traitements d’une façon rapide et optimale afin d’éviter une longue duréed’attente. Robustesse : l’application doit pouvoir gérer un très grand volume de données sans sebloquer. Fidélité : la comparaison de paie est une étape cruciale qui manipule des donnéessensible 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 modulesrépondant à des nouveaux besoins.ConclusionCe chapitre a permis de détailler les spécifications du projet, d’identifier les cas d’utilisationet d’élaborer les diagrammes correspondants. A présent nous sommes prêts à passer à l’étapede conception dans le chapitre suivant.
  • 44. Chapitre 4 : Conception40Chapitre 4Conception
  • 45. Chapitre 4 : Conception41IntroductionA la fin du chapitre précédent, nous avons présenté l’aspect architectural de la solution. Dansla 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 couchesLes choix architecturaux d’une application sont décisifs dès lors qu’ils interviennent surles performances, l’évolutivité, le temps de développement, et bien sûr le coût. Aujourd’huinous parlons d’une séparation des applications en différentes couches, et nous parlons alorsd’applications multi niveaux.L’architecture de notre système est une architecture multi niveaux à base de composantsrespectant le paradigme JEE. Elle est constituée des couches suivantes modélisées dans lafigure ci-dessous. Nous notons la délimitation des couches de conception du modèle MVC2des 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 etl’application (Navigateur Internet). Couche web : Permet de définir ce que doit afficher l’interface utilisateur et la manièrede gérer les requêtes. Couche métier : Contient le traitement à exécuter, qui sera appelé via la couche deprésentation faisant intervenir en général l’extraction et le traitement du contenu de lacouche 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 couchelogique et la couche de données. Si une telle couche n’existait pas, nous serionscontraints de réécrire les mêmes lignes de code à différents endroits de l’application.
  • 46. Chapitre 4 : Conception42 Couche de données : Ce niveau contient les données de l’application (Base dedonnées, fichiers XML,).Grâce à cette séparation en couches la souplesse, la maintenance et le développement del’application se trouveront grandement améliorés.Par la suite, nous intéresserons aux détails des couches de la partie MVC2 qui contiendratoute notre logique applicative.4 ConceptionDans cette section nous présentons en premier lieu l’architecture logicielle de notreapplication via un diagramme décrivant les dépendances entre les différents packages. Ensecond 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 êtreproduit. Dans cette phase, toutes les questions concernant la manière de réaliser le système àdévelopper doivent être élucidées. Le produit dune conception détaillée consiste enlobtention dun modèle prêt à coder. Lorsque lon utilise des langages orientés objet leconcept 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 plusdintérêt à la réalisation dune conception détaillée avec UML.Dans cette partie, nous présentons la conception de l’application réalisée à chaque sprint à l’aidede quelques diagrammes de séquence et d’activité des user stories les plus importants.4.2 Sprint 14.2.1 Diagramme de séquenceLa figure suivante décrit le scénario d’authentification.Il commence l’lorsque un utilisateurdemande l’accès a l’application :
  • 47. Chapitre 4 : Conception43Figure 22 : Diagramme séquence objet authentificationLa figure suivante décrit le user story ‘ Traitements des fichiers de données BTS ‘, chaqueheurs 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éesBTS
  • 48. Chapitre 4 : Conception444.2.2 Diagramme d’activité :Le diagramme dactivité permet de modéliser le comportement du système, dont la séquencedes actions et leurs conditions dexécution. Les actions sont les unités de base ducomportement du système.La figure suivante résume le processus de traitement des fichiers de données BTS.Figure 24 : Diagramme dactivité de traitement des fichiers de données BTS4.3 Sprint 24.3.1 Diagramme de séquenceCe scénario est décrit par la figure suivante il commence lorsque l’utilisateur demande lacarte des sites 2G. En effet l’utilisateur a le choix de la géolocalisation les sites selon plusieurscritères.
  • 49. Chapitre 4 : Conception45Figure 25 : Diagramme séquence objet Map 2G4.3.2 Diagramme d’activité :Le processus de création de Géolocalisation des sites BTS peut être résumé dans le diagrammed’activités suivant :
  • 50. Chapitre 4 : Conception46Figure 26: Diagramme dactivité « Géolocalisation des sites BTS »4.4 Sprint 34.4.1 Diagramme de séquenceLe scénario suivant décrit le user story « géolocalisation des incident » par la figure suivanted’après ce dernier on peut géolocaliser les incident ainsi les sites hors service a chaquemoment données et définit les KPI des sites voisinage.
  • 51. Chapitre 4 : Conception47Figure 27 : Diagramme séquence géolocalisation des incidents
  • 52. Chapitre 4 : Conception48Le scénario suivant décrit les étapes à suivre pour afficher la courbe de l’Availibility 2Gainsi 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éolocalisationdes incident »
  • 53. Chapitre 4 : Conception49Figure 29 : Diagramme dactivité « géolocalisation des incidents »4.5 Sprint 44.5.1 Diagramme de séquenceLe scénario suivant décrit les étapes à suivre pour ajouter un utilisateur après les vérificationsdes champs de formulaire quon doit remplir. Nous vérifions au niveau de base de donnéesl’unicité de cet utilisateur.Figure 30 : Diagramme de séquence « ajouter utilisateur »
  • 54. Chapitre 4 : Conception504.5.2 Diagramme d’activitéLe diagramme d’activité suivant représente le scenario relatif cas d’utilisation « ajouterutilisateurs »Figure 31: Diagramme dactivité « ajouter utilisateurs »4.6 Diagramme de classesLapproche objet prône le rapprochement des données et des opérations dans une seule entité :lobjet. Les traitements sont ainsi répartis entre les déférents objets qui incarnent les donnéesmanipulées par le programme.Le concept des objets est fondamental dans lapproche objet. Les objets sont des entitésatomiques formées par lunion dun état et dun comportement et qui communiquent paréchange de messages. Afin de réduire la complexité des objets du monde réel, la notiondabstraction a permis de regrouper les objets en classes. Parmi les relations les plusimportantes entre les classes, les associations (relations sémantiques bidirectionnelles) etlhéritage. Les classes et leurs relations sont regroupées dans un diagramme (diagramme declasses) représentant une vue statique des interactions entre les objets.
  • 55. Chapitre 4 : Conception51Figure 32:Diagramme de classeConclusionNous finissons ainsi létape de conception, élaborée dans ce chapitre et dans laquelle nousavons préparé tout ce quil fallait pour présenter et réaliser cette application. La réalisation estLe sujet du chapitre suivant
  • 56. Chapitre 5 : Réalisation52Chapitre 5Réalisation
  • 57. Chapitre 5 : Réalisation53IntroductionCette partie contient le dernier volet de ce rapport, elle a pour objectif d’exposer le travailachevé. Nous allons commencer, tout d’abord, par la présentation de l’environnementmatériel et logiciel utilisé pour développer l’application demandée. Ensuite, nous présentonsle travail accompli tout au long de la période du stage. Enfin, nous montronsle chronogramme de la réalisation du projet.1 Environnement de travailNous présentons dans cette section l’environnement matériel ainsi que celui logiciel utiliséspour le développement de notre application.1.1 Environnement matérielUn PC avec les configurations suivantes : un processeur Intel Core I5 une RAM de 4 Go.1.2 Environnement logicielLe 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 techniquesDans cette partie, nous justifions les choix techniques du langage de programmation, de laplateforme de développement et des frameworks utilisés.2.1 Choix du standard de développementJava EE 6 est une version importante. Non seulement elle marche dans les pas de Java EE 5pour fournir un modèle de développement simplifie, mais elle ajoute également de nouvellesspécifications et apporte des profils et de l’élagage pour alléger ce modèle. La sortie de JavaEE 6 coïncide avec le dixième anniversaire de la plate-forme entreprise : elle combine doncles avantages du langage Java avec l’expérience accumulée au cours de ces dix dernières
  • 58. Chapitre 5 : Réalisation54années. En outre, elle tire profit du dynamisme de la communauté open-source et de la rigueurdu JCP. Désormais, Java EE est une plate-forme bien documentée, avec des développeursexpérimentes, une communauté d’utilisateurs importante et de nombreuses applicationsdéployées sur les serveurs d’entreprises. C’est un ensemble d’API permettant de construiredes applications multi-tiers reposant sur des composants logiciels standard ; ces composantssont déployés dans différents conteneurs offrant un ensemble de services.2.2 Choix du Framework pour la couche de présentationJSF2.0 (Java Server Faces) permet de développer des application web en bénéficiant desconcepts 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 frameworksMVC (Model-View-Controller) disponibles sur le marché, il s’agit là d’un argument nonné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 validationJSF ne remplace pas les autres technologies web, il les utilise et les complète. Son architectureest basée sur le design pattern MVC. Pour rendre le développement d’une application webplus 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 EntityBeans. Le contrôleur intercepte les requêtes http, la navigation entre les pages web estconfigurable par un fichier XML dit faces-config.xml
  • 59. Chapitre 5 : Réalisation55Figure 33 : JSF2.3 EJB3.1Figure 34 : EJB3.1
  • 60. Chapitre 5 : Réalisation56Au sein dune architecture Java EE, les EJB sont utilisés pour créer les services. Cettetechnologie ne sarrête cependant pas à cette couche, mais permet aussi de créer labstractionde laccè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 formentla passerelle entre la logique applicative et les sources de données. Ils offrent une abstractionquasi complète du stockage des données, permettant à lapplication de rendre persistantes oude charger des données de manière totalement transparente.2.4 Choix du conteneur de la couche de persistance de donnéesDepuis les débuts de J2EE, le modèle de persistance ne cesse d’évoluer et de s’engluer deversion en version. Les entity beans 1.0 ont été complètement ré architecturés pour laisserplace aux entity beans 2.1. Bien que cette évolution ait apporté beaucoup d’améliorations, cemodè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 depersistance : JPA (Java Persistence API). Fortement inspirés par des outils Open Source telsqu’Hibernante ou par JDO, le mapping objet/relationnel et le langage de requête sonttotalement différents de l’ancêtre entity bean 2.1. JPA, ou JSR-220, réconcilie ainsi lesutilisateurs de la plate-forme JEE avec les composants persistants. Java Persistent APIs’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 lecode Java.La couche [dao] dialogue maintenant avec la spécification JPA, un ensemble dinterfaces. Ledéveloppeur y a gagné en standardisation. Avant, sil changeait sa couche ORM, il devaitégalement changer sa couche [dao] qui avait été écrite pour dialoguer avec un ORMspécifique. Maintenant, il va écrire une couche [dao] qui va dialoguer avec une couche JPA.Quelque soit le produit qui implémente celle-ci, linterface de la couche JPA présentée à lacouche [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éalisation57Figure 35 : Architecture de la spécification JPA2.5 Choix du SGBD MySQLNotre application ne dispose pas d’un grand volume de données à gérer, donc MYSQL suffiracomme étant une solution open source. En plus ce SGBD est le serveur de base de données leplus 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 etd’administration. Enfin sa documentation complète et bien construite2.6 Choix du serveur d’application JBOSS AS 7.1 :Alors que Tomcat est un conteneur web, JBOSS est un serveur dapplications qui embarqueTomcat (ou un équivalent) et qui propose en plus un hébergeur des EJB, des transactions, dela persistance...Côté performance, administration et connecteurs sont des raisons à considérer pour justifier lechoix d’un serveur dapplications fiable.Tomcat est largement utilisé car c’est plus "léger" (empreinte mémoire, temps dedémarrage...). Ceci dit, les serveurs dapplications en général font des progrès dans ce coté là.Avec larrivée dans les entreprises de Java EE 6, il y a un réel regain dintérêt pour lesserveurs dapplication.JBOSS est le nom du serveur dapplications Open Source Java 6, il est entièrement écrit enJava.3 Phase d’implémentationLes interfaces Homme/Machine constituent un élément important dans la réussite d’uneapplication. Cette contribution est d’autant plus importante lorsqu’il s’agit d’une applicationWeb. Ces interfaces doivent obéir à des chartes graphiques et aux règles d’ergonomie pourque 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 lesinterfaces à l’aide d’une feuille de style.
  • 62. Chapitre 5 : Réalisation583.1 Géolocalisation site 2GFigure 36 : MAP 2GDescription :Nous utilisons le Technique de localisations Global Positioning System(GPS) pour obtenircette interface qui permet à l’utilisateur d’avoir une vue globale sur le réseau 2G deTunisiana ainsi la géolocalisation des sites 2G. Cette résultat c’est la récolte de traitement desfichiers BTS sous format Excel ce derniers contient plus que seize mille ligne ainsil’enregistré dans la base de données a fin de les affichées sur l’API de google MAPS.3.2 Géolocalisation site 3GFigure 37 : MAP 3G
  • 63. Chapitre 5 : Réalisation59Description :Il s’agit de la même interface de géolocalosation 2G mais pour le cas de 3G.3.2.1 Recherche par lacFigure 38 : Recherche par LACDescription :L’exemple présenté par la figure 38 montre l’affichage d’un ensemble des sites qui sont demême local area code (LAC) 1119.3.2.2 LAvailability 2G RAN :Figure 39: courbe 2G RAN
  • 64. Chapitre 5 : Réalisation60Description :Cette interface permette à l’utilisateur d’avoir une vue globale sur les performances duréseau de Tunisiana. En effet Cette courbe est la résulta de la formule suivante :3.3 Géolocalisation des Site HSFigure 40: géolocalisation des incidentsDescription :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 interfaced’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éalisation613.4 Affichage des sites en voisinage d’un site HSFigure 42 : voisinage dun incidentDescription :Cette Interface permet de définir les voisinages des sites HS ainsi leur KPI. Après le choix dedistance de voisinage ou par LAC d’un site HS un ensemble des sites sera affiché sur la cartechaque 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éalisation623.5 TestLa phase de test est l’une des plus coûteuses et des plus importantes pour un cycle de vie d’unlogiciel. A la fin de cette phase qu’on peut juger la qualité d’un logiciel. Dans notre projet ona mené les tests suivants :Les tests unitaires qui sont faits par le programmeur afin que chaque module puissefonctionner sans erreur de programmation.Le test du système afin de vérifier si le logiciel fonctionne sur la machine cible (avec leslogiciels 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 testassez lourd pour adopter le logiciel aux attentes de client.4 Chronogramme de réalisationLe diagramme de GANTT est un outil permettant de modéliser la planification de tâchesnécessaires à la réalisation dun projet dans le temps.Figure 44 : Chronogramme de RéalisationConclusionAu cours de ce dernier chapitre nous avons précisé notre choix technique et montré quelquesinterfaces de notre application. A la fin nous avons présenté notre chronogramme modélisantles étapes de notre travail. A présent nous passerons dans la partie suivante à la conclusionglobale de notre projet.
  • 67. 63Conclusion et PerspectiveAujourd’hui, le souci majeur des opérateurs de téléphonie mobile consiste à assurer unequalité de service suffisamment bonne afin de permettre le bon fonctionnement des servicesofferts à leurs abonnés. La nécessité d’améliorer le service rendu au niveau des réseauxmobiles s’est largement manifestée. Ainsi, l’utilisation des techniques d’optimisationapproprié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 demonitoring de la qualité de service de lopérateur Tunisiana. Ce travail a suivi plusieurs étapesqui 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 lesdifférentes besoins dont lapplication est chargée dy répondre. Ces besoins ont été bien traitéset analysés dans la phase de spécification.Létape suivante, était la conception, durant toute cette phase, une étude globale et détailléedes fonctionnalités du système était réalisée à laide de langage de modélisation UML pouraboutir enfin à lapplication opérateur qui vise à aider lopérateur à améliorer la qualité deservice offert.Ce projet présente une occasion pour saméliorer dans le développement Java/Jee sur plusieursniveaux appliquées les nouvelle technologie JEE6, communication client/serveur,communication réseaux avec les serveurs FTP, conception et interaction avec les bases dedonnées, aussi, il ma permis dacquérir des connaissances importantes surtout au niveau de laqualité de service des réseaux mobiles 2 G et 3 G. Le travail présenté répond au cahier decharge déjà posé, mais il ne représente pas la version finale quon peut atteindre. En effet, cetravail peut samé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ésavancées telles que l’intégration d’partie mobile.Pour conclure, ce stage était très important, dans la mesure où il ma permis dappliquer mesconnaissances acquises lors de mon cursus éducatifs et des maitriser des nouvellestechnologies de développement. Finalement, il était une occasion pour sintroduire etsintégrer dans le milieu professionnel.
  • 68. 64Bibliographie[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 Rakedans 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 andUHF Land mobile Service", Review Electrical Communication Laboratory, pp. 825-873,1968[7] J. Walfisch and H. Bertoni, "A theoretical model of UHFpropagation in urbanenvironment", IEEE Transactions on antennas and propagation, vol. 36, pp. 1788-1796,December 1988[8] Maciej J. Nawrocki, Mischa Dohler and A. Hamid Aghvami, "Understanding UMTSRadio network"
  • 69. 65Acronymes0-91G First Generation of wireless communication technology2G Second Generation of wireless communication technology3G Third Generation of wireless communication technologyAAPI Application Programming InterfaceBBSC Base Station ControllerBSS Base Station SubsystemBTS Base Transceiver StationCCell ID CDMA CNEEDGEFFDD FTPGGPRS GSMHHSPA HSDPAJJVM J2EECellule IdentityCode Division Multiple Access Core Network
  • 70. 66Frequency Division Duplex File Transfert ProtocolGlobal System for Mobile communicationHigh-Speed Packet Access High-Speed Downlink Packet AccessJava Virtuel Machine Java2 Enterprise EditionLAC Location Area codeMMCC Mobile Country CodeMMS Multimedia Message Service Mobile Network CodeMSC Mobile Switching CenterNNSS Network and Switching SubsystemOOSS Operation and Support SubsystemQQoS Quality of ServiceRRAN Radio Access NetworkTTDD TDMAUUMTS UTRANTime Division Multiple AccessUniversal Mobile Telecommunications System UMTS Terrestrial Radio Access NetworkWW-CDMA Wideband Code Division Multiple Access
  • 71. 67Annexe A : JBOSS AS 7JBoss Application Server est un serveur dapplications 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 unbusiness model fondé sur le service. En effet, JBoss est maintenu par le Groupe JBossgratuitement, mais toute customisation et tous services consultants sont facturés. Ce groupeest une division de RedHat depuis avril 2006. La DGI (Direction Générale des Impôts) utiliseJBoss.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),• WebServicesCaracté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 ProcedureCall), 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 ExtensionsFigure 45 : JBOSS AS7
  • 73. 69Annexe B : La technologie AJAXI. Présentation de la technologieAJAX, ou Asynchronous JavaScript And XML (« XML et Javascript asynchrones »), est unacronyme désignant une méthode informatique de développement dapplications Web.Àlimage de DHTML ou de LAMP, AJAX nest pas une technologie en elle-même, mais unterme qui évoque lutilisation conjointe dun ensemble de technologies couramment utiliséessur le Web : HTML (ou XHTML) pour la structure sémantique des informations ; CSS pour la présentation des informations ; DOM et JavaScript pour afficher et interagir dynamiquement avec linformation présentée ; lobjet XMLHttpRequest pour échanger et manipuler les données de manière asynchrone avec le serveur Web. XML et XSLTEn alternative au couple XML/XSLT, les applications AJAX peuvent utiliser dautrestechnologies: le HTML préformante, et les fichiers texte plats par exemple.Les applicationsAJAX peuvent être utilisées au sein des navigateurs Web qui supportent les technologiesdécrites précédemment. Parmi eux, nous trouvons Mozilla, Firefox, Internet Explorer,Konqueror, Safari ou encore Opera. Toutefois, ce dernier ne supporte pas les transformationsXSLT nativement pour les versions antérieures à la 9.0.II. Comparaison avec les applications Web traditionnelles :Les applications Web permettent aux utilisateurs deffectuer des choix (suivre un lien, rempliret valider un formulaire). Une requête est alors envoyée au serveur HTTP, qui agit enfonction de laction et des données reçues, et renvoie une nouvelle page. Ce fonctionnementconsomme inutilement une partie de la bande passante, une grande partie du code (X) HTMLétant commune aux différentes pages de lapplication. Et parce quune requête au serveurHTTP doit être réalisée à chaque interaction avec lapplication, le temps de réponse delapplication dépend fortement du temps de réponse du serveur HTTP. Cela conduit à desinterfaces utilisateurs plus lentes que leurs équivalents natives. Les navigateurs actuels
  • 74. 70mettent les éléments communs en cache, donc le chargement de pages nouvelles noblige pasle serveur à redonner les mêmes éléments à chaque fois. Les applications utilisant lestechniques AJAX quant à elles peuvent envoyer des requêtes au serveur HTTP pourrécupérer uniquement les données nécessaires en utilisant la requête HTTPXMLHttpRequest, et en utilisant la puissance des feuilles de style (CSS) ainsi que le langageJavascript côté client pour interpréter la réponse du serveur HTTP. Les applications sont alorsplus réactives, la quantité de données échangées entre le navigateur et le serveur HTTP étantfortement réduite. Le temps de traitement de la requête côté serveur est également légèrementréduit, une partie du traitement étant réalisé sur lordinateur doù provient la requête. Encontrepartie, le chargement de la première page peut être pénalisé si lapplication utilise unebibliothèque AJAX volumineuse.

×