Chapitre I : Cadre Général du
Projet
A cours de ce chapitre, nous allons étudier le cadre générale du projet. Cette
étude ...
Chapitre I : Cadre Général du Projet
Titre projet Page 2
Introduction
Au cours de ce premier chapitre, nous allons étudier...
Chapitre I : Cadre Général du Projet
Titre projet Page 3
Nous avons fait le compromis de vous satisfaire et de créer l’ima...
Chapitre II : Etude de
l’existant
Ce chapitre représente une étude bien déterminée de l’existant, ses critiques
et ses ori...
Chapitre II : Etude de l’existant
Titre projet Page 2
Introduction
L’étape de l’étude de l’existant est une étape primordi...
Chapitre III : Analyse &
spécification des besoins
Ce chapitre représente une vision approximative de la finalité du proje...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 2
Introduction
L’analyse, étant considérée comme une ...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 3
l’UP (Unified Process) qui est en mesure de répondr...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 4
2) Langage de conception
UML (Unified Modeling Lang...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 5
II- Spécification des besoins
1) Les besoins foncti...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 6
d) MODE DE LIVRAISON :
Un client qui a déjà confirm...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 7
Il faut détailler les autres fonctionnalités, ce n’...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 8
L’administrateur : pour les sites web on l’appelle ...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 9
Mettre en relief surtout les fonctionnalités primor...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 10
passe ou le pseudo est incorrect ou invalide
Post-...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 11
Figure : Diagramme de cas d’utilisation « Gestion ...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 12
Patron textuel du cas d’utilisation « Modifier Com...
Chapitre III : Analyse & spécification des besoins
Titre projet Page 13
Exception : Pas d’exception
Post-condition : Compt...
Prochain SlideShare
Chargement dans…5
×

Prototype rapport

1 491 vues

Publié le

Modèle de rapport PFE

Publié dans : Formation
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 491
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
96
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Prototype rapport

  1. 1. Chapitre I : Cadre Général du Projet A cours de ce chapitre, nous allons étudier le cadre générale du projet. Cette étude comprend la présentation de l’entreprise dans laquelle s’est déroulé le stage ainsi qu’une petite présentation du projet.
  2. 2. Chapitre I : Cadre Général du Projet Titre projet Page 2 Introduction Au cours de ce premier chapitre, nous allons étudier le cadre générale du projet. Dans un premier temps, une brève présentation de l’organisme d’accueil sera effectuée. Et dans un second temps, nous décrivons le contexte du projet proposé ainsi que la problématique et le travail demandé. I- Présentation de l’organisme d’accueil Media Plus imagine et construit des sites web fonctionnels et attractifs aux dernières technologies tels que le responsive. Avec un effectif formé d’un groupe solide et dynamique de professionnel de l’infographie, du web design et du développement web, l’agence Media Plus vous propose des services variés tel que :  WEB DESIGN : - La création d’un graphisme en adéquation avec votre identité visuelle actuelle - Flash, Photoshop, Illustrator  INTEGRARTION WEB : - La programmation de votre site avec HTML5, CSS3, JavaScript, jQuery - L’hébergement de votre site en toute sécurité  COMMUNICATION PAPIER : - Catalogue produits, magazine, Menu de restaurant ou de café, Couverture de livre - Dépliant publicitaire, Flyers, affiches publicitaires - Brochure publicitaire, carte de visite, papier à entête, Modèle de facture...  IDENTITE VISUELLE – CHARTE GRAPHIQUE : - Création de logo, conception habillage, Enseigne - Plaquette, Porte Document, Enveloppe - Création ou refonte d’identité visuelle.  WEB MOBILE : - Android, IPhone OS, Windows mobile  NOUVELLE ACTIVITE : - Impression Numérique laser
  3. 3. Chapitre I : Cadre Général du Projet Titre projet Page 3 Nous avons fait le compromis de vous satisfaire et de créer l’image la plus excitante et attrayante de votre entreprise et de vous fournir les solutions informatiques les plus adaptées à vos besoins pour vous aider à atteindre vos objectifs. Que vous soyez un particulier ou une petite ou grande entreprise, nous vous invitons à entendre notre manière de penser, nous proposons nos produits et solutions, collaborons avec vous pour mener à bien vos projets. Nous demeurons à votre entière disposition pour toute précision. Dans l’attente de vous lire, nous vous prions d’agréer, chers partenaires, nos salutations les plus sincères. II- Présentation du projet Présenter votre projet en quelques lignes. Exemple : L’évolution de la technologie de l’information et de la communication a contribué au développement des systèmes d’information et de gestion au sein des entreprises. En effet l’intégration de l’outil informatique dans le domaine de l’entreprise est devenue une nécessité dont l’enjeu est déterminant face au processus d’amélioration des qualités de service et des conditions de travail. Le sujet de notre projet de fin d’études consiste à développer … L'objectif de ce stage est de concevoir et développer … III- Travail demandé Présenter le travail demandé (les principales fonctionnalités à implémenter dans votre application) Conclusion C’est ainsi que nous sommes parvenus à définir le cadre général de ce stage et le contexte large du projet à réaliser. Le prochain chapitre aura pour objectif la présentation des solutions existantes, les insuffisances qu’elles apportent ainsi que la solution future.
  4. 4. Chapitre II : Etude de l’existant Ce chapitre représente une étude bien déterminée de l’existant, ses critiques et ses orientations futures favorables.
  5. 5. Chapitre II : Etude de l’existant Titre projet Page 2 Introduction L’étape de l’étude de l’existant est une étape primordiale dans la réalisation de tout projet informatique. Cette étape préalable fera l’objet de ce chapitre et permettra de décrire le système existant, de dégager les insuffisances de l’état actuel et de proposer les orientations de la solution future. Il est indispensable si c’est possible avant de se lancer dans la réalisation de tout projet, de bien étudier et analyser des projets similaires s’il existe pour profiter des avantages et éviter les malveillances dans le présent projet. I- Description de l’existant Si l’application à développer est pour un système non informatisé qui n’existe pas déjà donc à décrire les fonctionnalités qui existe manuellement, ou à travers des manipulations des fichiers Excel ou autres… Si le système possède déjà une application mais qui contient des trous et des insuffisances alors décrire ce qui existe en mettant en relief les points positifs et en citant aussi les points négatives pour y remédier. S’il existe des applications pareilles dans le même domaine alors décrivez les applications existantes, leurs fonctionnalités, les avantages pour pouvoir les critiquer par la suite. Vous pouvez mettre des imprimes écrans des applications qui existent et les décrire selon leur contenus. II- Critique de l’existant III- Orientation de la solution future Conclusion En se basant sur la critique de l’existant, nous allons déterminer les différentes améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes
  6. 6. Chapitre III : Analyse & spécification des besoins Ce chapitre représente une vision approximative de la finalité du projet qui consiste à comprendre le contexte du système à réaliser en recensant à la fois les besoins fonctionnels et les besoins non fonctionnels. Et nous présentons la conception de notre projet avec les diagrammes de cas d’utilisations.
  7. 7. Chapitre III : Analyse & spécification des besoins Titre projet Page 2 Introduction L’analyse, étant considérée comme une première ébauche du modèle de conception, joue un rôle capital pour la démarche ergonomique. Cette analyse s’intéresse aux besoins et aux attentes des utilisateurs en général. Il s’agit de modéliser les éléments et les mécanismes principaux du nouveau système, ainsi que de livrer des spécifications pour permettre de choisir la conception de la solution. Une méthode d'analyse et de conception a pour objectif de permettre de formaliser les étapes préliminaires du développement d'un système afin de rendre ce développement plus fidèle aux besoins du client. Ce modèle d’analyse permet d’avoir une spécification complète des besoins issus des cas d’utilisation et les structures sous une forme (diagrammes d’activités, séquences, états transitions, …etc.) qui facilite la compréhension, la préparation (définition de l’architecture), la modification et la maintenance du système. I- Langage et méthodologie utilisés Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C’est également un bon moyen de maitriser sa complexité et d’assurer sa cohérence. Un modèle est en effet un langage commun, précis, qui est connu par tous les membres d’une équipe et il est donc un vecteur privilégié pour communiquer. Dans le domaine de l’ingénierie du logiciel, ce modèle permet de mieux répartir les tâches et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des délais. Ce modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace car, une fois mise en production, l’application va devoir être maintenue, probablement par une autre équipe et pas nécessairement la même ayant créée l’application. Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui concoure à l’obtention d’un système logiciel ou à l’évolution d’un système existant pour produire des logiciels de qualité, qui répondent aux besoins des utilisateurs dans des temps et des coûts prévisibles. 1) Méthodologie de conception Plusieurs méthodologie de conception et à vous de chercher quelle méthodologie adoptée. Exemple de choix de méthodologie de conception : Processus Unifié (UP) Les méthodes de développement dites « méthodes agiles » visent à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement. On peut citer parmi les méthodes agiles
  8. 8. Chapitre III : Analyse & spécification des besoins Titre projet Page 3 l’UP (Unified Process) qui est en mesure de répondre directement ou indirectement à diverse problématiques notamment financières ou temporelles. Le processus unifié (UP) est un processus de développement logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :  Itératif et incrémental : Le projet est découpé en itérations de courte durée (environ un mois et demi) qui aident à mieux suivre l’avancement global. À la fin de chaque itération, une partie exécutable du système final est produite de façon incrémentale.  Centré sur l’architecture : Tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facile. Cette architecture (fonctionnelle, logique, matérielle, … etc.) doit être modélisée en UML et pas seulement documentée en texte.  Conduit par les cas d’utilisation : Le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits avec précision et priorisés.  Piloté par les risques : Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des itérations. Le processus que nous avons utilisé pour le développement de notre système, comme c’est présenté dans la figure ci-contre, est:  Itératif et conduit par les cas d’utilisation, comme UP mais beaucoup plus simple ;  Relativement léger et restreint, comme les méthodes agiles, mais sans négliger les activités de modélisation en analyse et conception ;  Fondé sur l’utilisation des diagrammes du langage UML 2.0 (Unified Modeling Language), conformément à la modélisation agile (Agile Modeling).
  9. 9. Chapitre III : Analyse & spécification des besoins Titre projet Page 4 2) Langage de conception UML (Unified Modeling Language) est un langage de modélisation graphique apparu dans le monde du génie logiciel dans le cadre de la conception orientée objet. C’est l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. UML est à présent un standard défini par l’OMG (Object Management Group). La dernière version diffusée par l’OMG est la 2.4.1 depuis août 2011 *4+. UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour représenter l'architecture logicielle. Les différents éléments représentables sont :  Activité d'un objet/logiciel,  Acteurs,  Processus,  Schéma de base de données,  Composants logiciels,  Réutilisation de composants. Grâce aux outils de modélisation UML, il est également possible de générer automatiquement une partie de code, par exemple Java, à partir des divers documents réalisés. UML 2.0 propose 14 types de diagrammes et comme n’étant pas une méthode, leur utilisation est laissée à l’appréciation de chacun et la nature du projet. Par exemple, les diagrammes utilisés pour un projet d’application mobile diffèrent de ceux utilisés pour un site web.
  10. 10. Chapitre III : Analyse & spécification des besoins Titre projet Page 5 II- Spécification des besoins 1) Les besoins fonctionnels Dans cette section du chapitre, nous nous intéressons aux besoins des utilisateurs traités dans notre projet c’est à dire l’inscription du client, le choix des produits, le lancement des commandes enfin la confirmation et donc le payement en ligne à travers les spécifications fonctionnelles et non fonctionnelles pour aboutir à un site de qualité qui répond aux besoins des clients. Selon le cahier de charge, les besoins changent d’un projet à un autre. Vous allez citer dans cette partie les besoins fonctionnels de votre application. Exemple : Les besoins fonctionnels se présentent en huit grandes parties :  Exposition des produits ainsi que leurs prix et caractéristiques.  Inscription des clients.  Ajout des produits choisis au panier.  Choix du mode de livraison.  Choix de la boutique de livraison.  Confirmation de la commande.  Le payement en ligne.  Confirmation de l’opération d’achat et la réception de la facture. a) L’EXPOSITION DES PRODUITS: Notre site doit disposer d’une vitrine virtuelle à travers laquelle le client peut consulter une grande variété des produits, il sera donc indispensable d’y présenter les prix et les caractéristiques techniques de chaque produit pour faciliter la sélection du produit à acheter. b) L’INSCRIPTION DU CLIENT : Jusqu’à ce stade, le client est toujours anonyme mais pour pouvoir passer à un stade plus rigoureux, il faut qu’il s’inscrive, ce la se fait uniquement pour la première commande mais après, notre client peut s’authentifier avec son E-mail et son mot de passe pour passer d’autres commandes. c) AJOUT DES PRODUITS AU PANIER : Après le choix d’un produit le client doit mentionner la quantité qui s’ajoute automatiquement à son panier avec le prix unitaire et le prix total.
  11. 11. Chapitre III : Analyse & spécification des besoins Titre projet Page 6 d) MODE DE LIVRAISON : Un client qui a déjà confirmé sa commande il est libre de choisir le mode de livraison de sa marchandise soit à domicile ou chez une boutique selon une liste de chois mentionnée sur notre site web. e) BOUTIQUE DE LIVRAISON: Si le mode de livraison choisi est la boutique il faut que le client indique cette boutique avec une précision qui permet aux livreurs d’être sûrs que la marchandise sera dans le bon lieu et dans les rendez-vous, ayant une panoplie de boutiques réelles, le client pourra choisir la plus proche. f) LA LIVRAISON A DOMICILE : En choisissant cette option comme mode de livraison, le client devrait remplir soigneusement un formulaire contenant les informations nécessaires telles que :  Le nom du destinataire qui peut être le client même ou une autre personne.  L’adresse précise de livraison.  Le numéro de la pièce d’identité du destinataire.  Le jour et l’heure de la livraison estimés. g) LA CONFIRMATION DE LA COMMANDE : Jusqu’à cette phase on a un client, une commande et une adresse de livraison le chemin maintenant est plus clair, la commande ne passera qu’après la validation de toutes les informations qui sont affichées dans une seule interface avant de passer à la phase de payement. h) LE PAYEMENT : C’est une phase très sensible, pour cela il faut qu’elle soit très sécurisée, pour terminer la procédure de payement avec succès le client doit choisir un mode de paiement proposées sur notre site web (paiement par cheque, paiement contre remboursement, paiement espèce, paiement chez la boutique…). i) LA FIN DE L’OPERATION D’ACHAT: La page finale représente un petit message de remerciement à nos clients avec une idée sur l’adresse, la date, le temps de la livraison en question et bien sur la possibilité d’imprimer la facture du client.
  12. 12. Chapitre III : Analyse & spécification des besoins Titre projet Page 7 Il faut détailler les autres fonctionnalités, ce n’est qu’un exemple pour vous faire comprendre quoi mettre. 2) Les besoins non fonctionnels Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le résultat et sur le rendement de l’utilisateur, ce qui fait qu’ils ne doivent pas être négligés, pour cela il faut répondre aux exigences suivantes :  Fiabilité: L’application doit fonctionner de façon cohérente sans erreurs et doit être satisfaisante.  Les erreurs : Les ambigüités doivent être signalées par des messages d’erreurs bien organisés pour bien guider l’utilisateur et le familiariser avec notre application.  Ergonomie et bonne Interface : L’application doit être adaptée à l’utilisateur sans qu’il ne fournisse aucun effort (utilisation claire et facile) de point de vue navigation entre les différents modules, couleurs et mise en textes utilisés.  Sécurité : Notre solution doit respecter surtout la confidentialité des données personnelles des clients qui reste l’une des contraintes les plus importantes dans les sites web.  Aptitude à la maintenance et la réutilisation : Le système doit être conforme à une architecture standard et claire permettant sa maintenance et sa réutilisation.  Compatibilité et portabilité : Un site web quel que soit son domaine, son éditeur et son langage de programmation ne peut être fiable qu’avec une compatibilité avec tout les navigateurs web et tous les moyens que ce soit PC, IPAD ou Mobiles. III- Identifications des acteurs Définir les acteurs selon votre projet. Décrire chaque acteur à part et citer les fonctionnalités de chacun si vous voulez dans un tableau. Exemple : Le visiteur : c’est un individu qui est entrain de fouiller sur le net, cherchant un produit pour l’acheter ou pour avoir une idée sur les modèles et les prix. Jusqu’au ce stade c’est un utilisateur inconnu donc il n’est pas encore un client. Le Client : cette acteur est un visiteur ayant déjà créer un compte sur notre site, il peut donc suivre le processus d’achat des produits en toute sécurité sachant que notre système doit être l’unique responsable de la confidentialité des données personnelles de ses clients.
  13. 13. Chapitre III : Analyse & spécification des besoins Titre projet Page 8 L’administrateur : pour les sites web on l’appelle généralement « le webmaster ». C’est celui qui assure le dynamisme du site et veille sur les mises à jour des produits, de leurs prix, de leurs disponibilités, de la gestion des payements et la gestion des livraisons. IV-Diagrammes de cas d’utilisation Les cas d’utilisation sont très utiles en phase de recherche de besoin. L’approche consiste à regarder le système à construire de l’extérieure, du point de vue de l’utilisateur et des fonctionnalités afin de déterminer ses besoins fonctionnels c'est-à-dire ce qu’il attend du système. 1) Diagramme de cas d’utilisation global Mettre le diagramme de cas d’utilisation global de votre système. Figure : Diagramme cas d’utilisation global 2) Diagramme de cas d’utilisation Détaillé Vous aller détailler les différents cas d’utilisation de votre système à mettre en œuvre.
  14. 14. Chapitre III : Analyse & spécification des besoins Titre projet Page 9 Mettre en relief surtout les fonctionnalités primordiales (Mettre le diagramme de cas d’utilisation, écrire un petit paragraphe descriptif et mettre un tableau détaillant les scénarios.) a) Description scénario cas d’utilisation « Authentification » Pour que l’utilisateur puisse bénéficier de n’importe quel service de l’application, il doit avant tout s’authentifier avec son login et son mot de passe. Figure : Diagramme de cas d’utilisation « Authentification » Patron textuel du cas d’utilisation « Authentification» Sommaire d’authentification Nom : S’authentifier Résumé : Le système vérifie l’identité de l’utilisateur en utilisant son pseudo et son mot de passe. Acteur : Citer les acteurs … Pré-condition L’utilisateur doit être inscrit : possède un compte. Description du scénario : 1) L’utilisateur introduit son login et son mot de passe. 2) L’utilisateur confirme son identification 3) Le système vérifie les informations fournit par l’utilisateur 4) Le système autorise ou refuse l’accès à l’application Exception : Affichage d’un message d’erreur dans le cas ou le mot de
  15. 15. Chapitre III : Analyse & spécification des besoins Titre projet Page 10 passe ou le pseudo est incorrect ou invalide Post-condition : Utilisateur authentifié b) Description scénario cas d’utilisation « Gestion Discipline » Exemple de cas d’utilisation détaillé de la gestion des disciplines. Figure : Diagramme de cas d’utilisation « Gestion Discipline » c) Description scénario cas d’utilisation « Gestion Compte » L’administrateur est le responsable de la gestion des comptes, il peut :  Créer un nouveau compte : la création se fait après avoir fournir les données nécessaires (nom, prénom, tél, email, adresse, login et mot de passe…)  Consulter un compte : la consultation se fait à travers certains critères spécifiques pour chaque compte. L’utilisateur peut déjà consulter les paramètres de son compte.  Supprimer un compte : après la consultation des données relatives à un compte, l’administrateur peut les supprimer.  Modifier les paramètres d’un compte : cette fonctionnalité consiste à modifier les données du paramètres compte et les remplacer par des nouvelles données. Exemple de cas d’utilisation détaillé de la gestion des disciplines.
  16. 16. Chapitre III : Analyse & spécification des besoins Titre projet Page 11 Figure : Diagramme de cas d’utilisation « Gestion Compte » Patron textuel du cas d’utilisation « Créer Compte » Sommaire créer compte Nom : Créer compte Résumé : Création d’un nouveau compte Acteur : Administrateur Pré-condition Utilisateur authentifié Description du scénario : 1. L’utilisateur choisit l’option « Créer compte » 2. L’utilisateur fournit les informations nécessaires du compte approprié 3. L’utilisateur valide l’ajout 4. Le système vérifie les informations 5. Le système enregistre les informations fournies par l’administrateur 6. Le système renvoie un message d’ajout effectué. Exception : Si le compte (apprenant, tuteur) existe déjà, donc le système affiche un message d’utilisateur existant. Post-condition : Compte créé
  17. 17. Chapitre III : Analyse & spécification des besoins Titre projet Page 12 Patron textuel du cas d’utilisation « Modifier Compte » Sommaire Modifier Compte Nom : Modifier compte Résumé : Modifier les paramètres du compte Acteur : Acteur : Administrateur, Etudiant Pré-condition Utilisateur authentifié Description du scénario : 1. L’utilisateur sélectionne le paramètre de « Modification paramètres » 2. L’utilisateur fournit les nouvelles données (Email, Tel, Adresse, mot de passe…) 3. Le système vérifie les données 4. Le système enregistre les modifications 5. Le système renvoie un message pour informer l’administrateur que la modification est effectuée avec succès. Exception : Si les nouvelles données sont erronées donc le système affiche un message de saisie erronée. Post-condition : Paramètres compte mis à jour Patron textuel du cas d’utilisation « supprimer Compte » Sommaire Supprimer Compte Nom : supprimer compte Résumer : Supprimer compte Acteur : Acteur : Administrateur. Pré-condition Utilisateur authentifié et compte existant Description du scénario : 1. L’utilisateur sélectionne le compte à supprimer 2. L’utilisateur confirme la suppression 3. Le système supprime le compte en question. 4. Le système renvoie un message pour informer l’administrateur que la suppression est effectuée avec succès
  18. 18. Chapitre III : Analyse & spécification des besoins Titre projet Page 13 Exception : Pas d’exception Post-condition : Compte supprimé Patron textuel du cas d’utilisation « Consulter Compte » Sommaire Consulter Compte Nom : Consulter compte Résumer : L’utilisateur peut consulter les paramètres du son compte. Acteur : Administrateur, Etudiant Pré-condition Utilisateur authentifié et compte existant Description du scénario : 1. L’utilisateur accède à son espace de paramètre compte 2. Le système recherche les données du compte approprié 3. Le système affiche les informations du paramètre du compte concerné. Exception : Pas d’exception Post-condition : Compte consulté A compléter tout les diagrammes de cas d’utilisation primordial dans votre application. Conclusion En se basant sur la critique de l’existant, nous allons déterminer les différentes améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes

×