SPÉCIFICATION DES BESOINS
L’expression des besoins comme son nom l’indique a pour objectif d’assurer une compréhension des besoins et des exigences du client. Plus précisément, la spécification des besoins permet de :
Recenser les besoins fonctionnels (de point de vue utilisateur).
Appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences.
Besoins fonctionnels
Au niveau serveur :
Le serveur reçoit une requête de client qui a mentionné une panne bien déterminée. En se basant sur cette dernière, le serveur consulte la base de données et renvoi la réponse correspondante ;
Le serveur assure l’envoi d’une notification permanente et périodique des divers tâches de la maintenance préventive convenable aux normes OACI et organisée selon un plan clair ;
Le serveur assure la localisation du déplacement des personnels et des voitures de service lors d’une intervention bien déterminée entre les différents équipements de la navigation aérienne distribués de part et d’autre de la piste de l’aéroport.
Au niveau client :
Permet aux utilisateurs d’accéder aux informations et de bénéficier d’une idée globale sur tous les équipements de la navigation aérienne.
Envoie une requête au serveur contenant les critères de recherche pour recevoir les pièces de rechange et les solutions des pannes adéquates.
En recevant la réponse, le client va explorer les données reçus pour assurer son intervention et il peut à tout moment relancer une autre recherche.
Besoins non fonctionnels
Besoins Matériels :
Afin de tester l’application, on a besoin du matériel suivant :
Téléphone portable : Pour tester l’application il nous faut un téléphone portable supportant la technologie Androïde.
Serveur connecté à internet d’une façon permanente pour la réception des requêtes envoyées par l’utilisateur.
Besoins logiciels :
Un langage de programmation d’une application mobile.
Une application serveur qui tourne d’une façon permanente pour recevoir et traiter les requêtes envoyées par l’utilisateur ou l’administrateur
Contraintes ergonomiques :
Il faut que l’interface de l’application soit facile à manipuler. Il est nécessaire de faciliter l’utilisation des différentes fonctions fournies par l’interface tout en essayant de rendre l’application facile à utiliser pour gagner le maximum du temps Il est nécessaire que l’interface soit lisible. La lisibilité de l’application peut être atteinte par la bonne répartition des différents composants de l’interface tels que le menu, les boutons… Il faut utiliser un bon style et une bonne mise en forme pour que l’apparition soit claire et compréhensible.
Cohérence de données :
Le système est conçu pour être généralisé qui englobe tous les aéroports tunisiens, une contrainte de cohérence des données et nécessaire au niveau de la base de données pour que la fusion des différents systèmes sera possible.
Processus de développement et méthodologie de conception
Le processus de développement unifié 2TUP :
Nous avons choisi pour que notre projet soit bien organisé 2TUP comme étant un processus de développement logiciel qui implémente le processus unifié doté des plusieurs caractéristiques en effet il est itératif, piloté par les risques, orienté composant, orienté utilisateur et incrémental.
Définition :
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à identifier les acteurs qui vont interagir avec le système à construire, les messages qu’échangent les acteurs et le système, à produire le cahier des charges et à modéliser le contexte (le système est une boîte noire, les acteurs l’entourent et sont reliés à lui, sur l’axe qui lie un acteur au système on met les messages que les deux s’échangent avec le sens).
Avantage :
Pour résumer, il permet à la fois de capitaliser la connaissance métier sur la branche gauche et de réutiliser un savoir-faire technique sur la branche droite. En d’autres termes, un meilleur contrôle sur les capacités d’évolution et de correction de tels système.
Architecture:
une branche technique
une branche fonctionnelle
une phase de réalisation
La branche fonctionnelle :
La branche fonctionnelle capitalise la connaissance du métier de l’entreprise. Cette branche capture des besoins fonctionnels, ce qui produit un modèle focalisé sur le métier des utilisateurs finaux.
La branche technique :
La branche technique capitalise un savoir-faire technique et/ou des contraintes techniques. Les techniques développées pour le système le sont indépendamment des fonctions à réaliser.
La phase de réalisation :
La phase de réalisation consiste à réunir les deux branches, permettant de mener une conception applicative et enfin la livraison d’une solution adaptée aux besoins.
La méthodologie de conception UML
Notation graphique de modélisation a objet Permet de visualiser, spécifier, construire et construire les différentes parties d’un système logiciel Langage graphique base sur des diagrammes.
UML est capable de : Représenter des systèmes entiers (pas uniquement logiciels) par des concepts objets ; Pouvoir modéliser des systèmes à différents niveaux de granularité ( pour permettre d’appréhender Des systèmes complexes.
Guide du mémoire de fin d’études avec la catégorie processus de développement et méthodologie de conception |
É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 diagramme de composant général où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Table des matières
INTRODUCTION GÉNÉRALE
CHAPITRE 1 : CADRE GÉNÉRAL
Introduction
I PRÉSENTATION DE L’ENTREPRISE D’ACCUEIL
I.1 Présentation de l’Office de l’aviation civile et des aéroports (OACA)
I.2 Etude de l’existant et Problématique
I.2.1 Unité de télécommande RCMS (Remote Control Monitoring System)
I.2.2 Absence d’un GMAO dans le service (Gestion de maintenance assistée par ordinateur)
I.3 Solution proposée
I.4 Travail demandé
Conclusion
CHAPITRE2 : ÉTUDE PRÉLIMINAIRE
INTRODUCTION
I CONTEXTE DE PROJET
I.1 Objectif (Aspect de la solution adoptée)
I.2 Solution de mobilité
1.3 Choix de l’environnement de développement
II Présentation de l’application
III Spécification des besoins
III.1 Besoins fonctionnels
III.2 Besoins non fonctionnels
IV processus de développement et méthodologie de conception
IV.1 Le processus de développement unifié 2TUP
IV.2 La méthodologie de conception UML
CONCLUSION
CHAPITRE 3 : EUDE FONCTIONNELLE
INTRODUCTION
I CAPTURE DES BESOINS FONCTIONNELS
I.1 IDENTIFICATION DES CAS D’UTILISATION
I.1.1 Présentation des cas d’utilisation
I.1.2 DESCRIPTION DES CAS D’UTILISATION
I.1.3 Le cas d’authentification
I.2 Le module d’administration
I.2.1 Gestions des pannes techniques
I.2.3 Diagramme de séquence des solutions des pannes techniques
I.3 Module de la maintenance préventive
I.3.1 Affinement du cas d’utilisation « consulter les notifications des tâches de la maintenance préventive »
I.3.2 Diagramme de séquence des notifications des tâches de la maintenance préventive
I.4. Diagramme de séquence de consultation des notifications des tâches de la maintenance corrective
CONCLUSION
CHAPITRE 4 : ETUDE TECHNIQUE
INTRODUCTION
I Spécification d’architecture
II ARCHITECTURE DE L’APPLICATION
II.1 Présentation du modèle MVC
II.2. Présentation de l’architecture trois tiers de l’application
III Diagramme de composant général
CONCLUSION
CHAPITRE 5 : LA CONCEPTION
INTRODUCTION
I Les diagrammes de classe:
I.1 Le diagramme de classe en couche
I.2 Le diagramme de classe de la couche présentation
I.3 Le diagramme de classe de la couche logique applicative
I.4 Le diagramme de classe de la couche modèle
CONCLUSION
CHAPITRE 6: IMPLÉMENTATION
INTRODUCTION
I. ASPECT TECHNIQUE
I.1. Choix de la plateforme
I.1.1. La plate-forme Androïde
II. ENVIRONNEMENT DU TRAVAIL
II.1Environnement matériel
II.2 Environnement logiciel
II.2.1 Outils d’infographie
II.2.2 Outils de conception
I.2.3 Outils de développement
I.2.4 Configuration pré-développement :
II Description matérielle
II.1 Implémentation
I.1.2 Interfaces du module administrateur
I.1.3 Interfaces du module maintenance corrective
CONCLUSION
CONCLUSION GÉNÉRALE
WEBOGRAPHIE
Télécharger le rapport complet