Ingénierie des MSANs (Multi Service Access Node)

Chapitre 4 :

Développement d'une application pour la gestion des sites d'installation des MSANs

§ Problématique

§ Conception de l'application 

§ Réalisation de l'application 

2.1. Problématique

Le problème énoncé par le service déploiement concerne la mauvaise gestion dans laquelle se déroulent les missions des sites d'installation des MSANs à cause de son nombre ingérable.

En effet, l'état actuel connait les problèmes suivants :

- le manque de traçabilité d'article par son numéro de série, ce qui rend difficile la vérification de la validité de la garantie des articles de retour.

- une gestion de flux d'information d'une façon classique axée sur l'envoi de mails et l'utilisation de fichiers Excel ceci engendre un manque de fluidité dans la circulation de l'information surtout en l'absence d'un Système d'Information.

- le manque de préavis sur l'état des sites pour faire face aux différentes contraintes à savoir l'interdiction de livraison ou de stationnement ,accès à la poutre pour fixation palan, la possibilité d'extension d'un site déjà installé ..., tous ces contraintes exigent un déplacement pour le surveille de site ce qui engendre des dépenses des charges indirectes.

Cet état est dû à l'absence d'un processus qui permet de gérer au mieux le flux d'information ainsi que la fluidité des interactions entre les différents acteurs du processus.

2.1. Conception de l'application 

§ Démarche suivie :

Après avoir pris conscience de la problématique et du besoin exprimé par le service déploiement, nous étions amenés à mettre en place une solution permettant d'automatiser le processus de gestion des sites d'installation. Nous avons donc été obligés de passer par la programmation des réunions avec les différentes intervenants d'ALU pour ressortir une description général de Système d'Information qui décris l'acheminement des équipements depuis fournisseur jusqu'aux sites d'installation. Après nous avons décidé de nous lancer dans la conception de notre SI pour cette raison on a choisi MERISE pour l'analyse, la conception, et la gestion de projet, Mysql comme SGBD, et pour le développement de l'application WEB on a préférés de travaillés avec PHP.

4.1.1. Description du système d'information 

Une fois ALCATEL-LUCENT signe un contrat avec le client, PROJECT MANAGER d'ALU commande le matériel selon un document BOQ (Bilan of quantities) réalisé par l'Offreur est qui résume l'équipement nécessaire au projet. Après le département PM (Project Manager) se charge de commander ce matériel à ALU France.

Ce matériel arrive de différents pays à travers le monde (Europe / Asie..), il sera ensuite dédouané par le client et arrive soit dans son Warehouse client où il sera acheminé vers celui d'ALU Maroc, soit il arrive directement vers Warehouse ALU Maroc.

Lorsqu'il y'a une demande de mise en place de site exprimé par OS client. Le département PM se charge d'envoyer cette demande au service Deployment Team qui s'occupe à son tour de réaliser un bon de livraison (BL) par le Rollout Manager (RM). Ce BL sera envoyé en parallèle au magasin ALU Maroc pour préparer la commande, et aux intervenants(les monteurs-câbleurs ou les gens de test) qui se chargent soient d'installation ou bien extension du site.

Une fois la commande est préparée, ALU procède à la livraison du matériel sur site d'installation. Le chef du centre concerné procède à une réception quantitative conformément au BL.

Suite aux exigences d'augmentation du nombre des sites. ALU se voit contrainte d'améliorer la supervision en temps réel des sites.

Pour répondre à ce besoin les équipes d'installation doivent être informées au préalable des données suivantes :

- Données GPS de site d'installation.

- le nom de chef de site.

- la fiche de surveille de site.

- Types et quantités d'articles installés...

- Données GPS de site d'installation.

- le nom de chef de site.

- Types et quantités d'articles installés.

- les interfaces LT/NT disponibles des équipements comme DSLAM/MSAN (C'est une sorte de châssis qui contient les cartes DSL).

- les ports disponibles au niveau du Switch IP/MPLS, et les types des liaisons (directement raccordé à un Switch ou bien sur un autre DSLAM master)

-les paramètres de configuration des ports tel que les VLAN,

Dans le cas de retour client le magasinier d'ALU Maroc procède à une vérification de la validité de son garantie (dans le cas défavorable le contrat rentre dans le cadre de la maintenance de l'article sous la charge du client).

Une fois la vérification est terminée, la procédure de réparation commence par le remplissage d'un relevé de défauts FRD qui décrit le matériel défaillant (code fournisseur, numéro de série et la nature de la défaillance), ensuite l'article est enregistré dans la base de données WMS (Paradox).

Après une demande d'autorisation de retour matériel RMA est envoyée à ALU. Apres vérification, un numéro RMA est attribué au matériel et ensuite transféré au centre de réparation avec une facturation des frais de la douane.

Une fois le matériel est réparé, il revient à l'entrepôt pour être expédié à nouveau au client.

Figure 4.1 : Procédure général de livraison client

Figure 4.2 : Procédure de réparation

1.1. 4.1.2. Modélisation MERISE

MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques.

L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) décrivant les règles et les contraintes à prendre en compte.

1.1. 1.2. § Modèle conceptuel des données :

Après avoir listé toutes les informations déterminées par le système d'information. Nous les avons ensuite regroupées et structurés afin d'obtenir un MCD évitant les redondances tout en facilitant les fonctions de requête. Ce modèle a pour but d'écrire de façon formelle les données qui seront utilisées par notre système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire le système d'information à l'aide des entités et des relations.

Figure 4.3 : Modèle conceptuel des données de l'application

1.1. 1.2. 1.3. § Le modèle logique des données :

Le modèle logique des données(MLD) consiste à décrire la structure de données utilisée sans faire référence à un langage de programmation. Il s'agit donc de préciser le type de données utilisées lors des traitements.

Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique. Les identifiants de la classe d'entité sont appelé clés de la table, tandis que les attributs standards deviennent des attributs de la table, c'est-à-dire des colonnes.

Figure 4.4 : Modèle logique des données de l'application

§ Le modèle physique :

Cette étape consiste à implémenter le modèle dans le SGBD, c'est-à-dire le traduire dans un langage de définition de données.

Le langage généralement utilisé pour ce type d'opération est le SQL.

Figure 4.5 : Modèle physique de l'application