Soutenance mémoire
Contexte et Objectifs
Après recherche et étude juridique, nous avons conclus que le gérant n’a pas besoin de nous fournir tous les papiers que nous avons cités auparavant pour le dépôt de sa demande. Nous avons besoin seulement du registre de commerce et l’agrément qui nous permet de déterminer le type de société à savoir :
-Droit commun,
-Magasin cale,
-Entrepôt privé pour le propre compte/compte d’autrui,
-Consignataire de navire,
-Commissionnaire en douanes,
-Transporteur aérien,
-Transporteur maritime,
– Entrepôts franc (totalement exportatrice).
Cette distinction nous aide, en premier lieu, à déterminer les transactions du système SINDA appropriées à chaque type de société afin d’éviter de les attribuer à toutes les sociétés indépendamment de leur type et en deuxième lieu, elle permet d’avoir une statistique exacte pour chaque type.
Cette étude entre dans la conception de notre application et facilite la gestion de dépôt de la demande de la connexion au système SINDA.
Besoins fonctionnels
Les besoins fonctionnels ou besoins métiers représentent les actions que le système doit exécuter, il ne devient opérationnel que s’il les satisfait. Notre application web doit couvrir principalement les besoins fonctionnels suivants :
Permettre aux gérants de la société de déposer leurs demandes avec les pièces jointes nécessaires.
Gérer les comptes des gérants de façon à ne pas avoir des demandes dupliquées.
Assurer le suivi des demandes en ligne pour éviter le va et vient des gérants.
Etude et gestion des demandes tout en respectant le circuit de traitement exigé.
Restituer des statistiques sur les sociétés autorisées.
Besoins non fonctionnels
Pour le bon fonctionnement de notre solution et la satisfaction du client, l’application devrait être :
Extensible, c’est-à-dire qu’il pourra y avoir la possibilité d’ajouter des nouvelles fonctionnalités ou de modifier l’existant.
Agréable, lisible et facile à utiliser par les utilisateurs.
Sécurisée dont la mesure où elle doit respecter la confidentialité des données et vérifier la signature électronique des gérants ayant déposés leurs demandes de connexion.
Modélisation des besoins
Pour modéliser nos besoins nous avons choisie l’UML (Langage de modélisation unifié) puisqu’il exprime mieux la vue statique et dynamique du système informatique et nous fournit des diagrammes pour représenter l’application web développée : son fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par l’application [5] et faire une analyse approfondie pour dégager les nécessités de développement en s’appuyant sur la notion d’orienté objet.
Pour le choix des diagrammes UML dans notre application web, nous avons recours aux diagrammes de cas d’utilisation et diagrammes séquentiels.
Identifications des acteurs
Les acteurs qui vont interagir avec l’application sont :
Le gérant : C’est le responsable juridique de la société qui a le droit de déposer la demande de l’accord de connexion au système SINDA.
L’agent de douane : C’est la personne chargée de la gestion des demandes déposées en ligne par les gérants : il consulte et vérifie ces demandes et selon l’avis de la commission, il les informe.
L’administrateur : C’est le gestionnaire de l’application web. Il gère les comptes des utilisateurs.
Diagramme de cas d’utilisation
A titre explicatif, nous donnons un aperçu sur les principaux cas d’utilisation :
S’inscrire : permet au gérant de s’inscrire pour avoir un login et un mot de passe.
Authentification : permet d’identifier chaque utilisateur et de lui donner l’accès aux fonctionnalités propices.
Gérer comptes utilisateurs : permet à l’administrateur d’ajouter, supprimer, modifier et consulter un utilisateur.
Déposer une demande : permet au gérant de saisir les informations et charger les documents relatifs à la société.
Suivre la demande : permet au gérant de suivre l’évolution du traitement de sa demande.
Consulter dossier : permet à l’agent de douane de consulter les demandes et les pièces jointes déposées.
Vérifier dossier : permet à l’agent de douane de vérifier les dossiers déposés par le gérant afin de les passer à la commission pour avis.
Administrateur Pré condition : – Utilisateur existe dans la base Post condition : – Connexion de l’administrateur à la base – L’administrateur accède à son espace. Scénario nominal : – L’administrateur choisi la tâche souhaitée : « gérer compte agent douane » ou « gérer compte gérant ». – L’administrateur choisi l’utilisateur souhaité. – L’administrateur choisi l’action souhaité. Scénario d’alternatif : – Login ou mot de passe incorrecte. – Le système n’a ni ajouté, ni supprimer ni modifier les données dans la base de données. Scénario d’exception : – L’administrateur ne peut pas se connecter à la base.
Agent douane Pré condition : – Une demande de connexion au système SINDA est enregistrée dans la base Post condition : – Authentification de l’agent douane. – L’agent de douane accède à son espace. Scénario principal : – Le système affiche la liste les dossiers déposés. – L’agent douane choisi le dossier à vérifier. – Le douanier vérifie les données saisies par le gérant ainsi que les documents chargés. – Si le dossier est complet l’agent de douane le transmet à la commission. – Si le dossier est incomplet l’agent de douane informe le gérant. – Si la demande de connexion est acceptée par la commission, l’agent de douane prépare l’accord et informe le gérant. – Si la demande de connexion est rejetée de même l’agent de douane informe le gérant Scénario d’alternatif : – Le système n’affiche pas la liste des demandes. Scénario d’exception : – Le système est en panne.
|
Guide du mémoire de fin d’études avec la catégorie MODELISATION DES BESOINS |
|
Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie OBJECTIFS DU SYSTEME « SINDA » où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1. ETUDE DE L’EXISTANT
1.1 INTRODUCTION
1.2 PRESENTATION DE L’ORGANISME D’ACCUEIL
1.2.1 MISSIONS DE LA DSI
1.2.2 ORGANIGRAMME
1.3 DESCRIPTION DE L’EXISTANT
1.3.1 LE SYSTEME SINDA
1.3.2 OBJECTIFS DU SYSTEME « SINDA »
1.3.3 L’ACCORD DE CONNEXION AU SYSTEME SINDA
1.4 PROBLEMATIQUE
1.5 SOLUTION PROPOSEE
1.6 CONCLUSION
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
2.1 INTRODUCTION
2.2 CONTEXTE ET OBJECTIFS
2.3 BESOINS FONCTIONNELS
2.4 BESOINS NON FONCTIONNELS
2.5 MODELISATION DES BESOINS
2.5.1 IDENTIFICATIONS DES ACTEURS
2.5.2 DIAGRAMME DE CAS D’UTILISATION
2.5.2.1 CAS D’UTILISATION « GERER COMPTE UTILISATEUR »
2.5.2.2 CAS D’UTILISATION « VERIFIER DOSSIER »
2.5.3 DIAGRAMMES DE SEQUENCE
2.5.3.1 DIAGRAMME DE SEQUENCE DU CAS « GERER COMPTE AGENT DOUANE »
2.5.3.2 DIAGRAMME DE SEQUENCE DU CAS « GERER COMPTE GERANT »
2.5.3.3 DIAGRAMME DE SEQUENCE DU CAS « S’INSCRIRE »
2.5.3.4 DIAGRAMME DE SEQUENCE DU CAS « DEPOSER UNE DEMANDE »
2.5.3.5 DIAGRAMME DE SEQUENCE DU CAS « VERIFIER DOSSIER »
2.6 CONCLUSION
CHAPITRE 3. CONCEPTION
3.1 INTRODUCTION
3.2 ARCHITECTURE DE L’APPLICATION
3.2.1 ARCHITECTURE PHYSIQUE
3.2.2 ARCHITECTURE LOGIQUE
3.3 DIAGRAMME DE CLASSE
3.4 BASE DE DONNEES
3.5 CONCLUSION
CHAPITRE 4. REALISATION
4.1 INTRODUCTION
4.2 OUTILS DE REALISATION
4.3 PLAN DE SITE
4.3.1 PAGE D’ACCUEIL
4.3.2 ESPACE GERANT
4.3.3 ESPACE ADMINISTRATEUR
4.3.4 ESPACE AGENT DOUANE
4.4 CONCLUSION
CONCLUSION GENERALE
NETOGRAPHIE
Télécharger le rapport complet
