-Acyl El Hassani -Ameny El Okb -Oumaima Haj Ali -Welid Gueddari -Malek Gridah
Encadré par :
Mme Sonia Ghannouchi & Mme Neila Hochlef
Plan : A introduction E Diagrammes de cas d’utilisation
B Problématique F Diagramme de classe
C Objectifs G Les Interfaces
D Spécification des besoins H Tables relationnelles
A- Introduction : L'homme au cours de son évolution s'est buté aux problèmes liés à l'ignorance et au rythme du développement des sciences. Étant un être intelligent, il n'a pas voulu rester dans les conditions de vie médiocre mais il a cherché à les améliorer.
Dans la recherche d'une évolution, l'homme a souhaité mettre fin à ce travail lourd et long portant sur des opérations arithmétiques et logiques complexes et de tâches répétitives.
Au contrôle des structures des facultés manuel, nous avons trouvé multiples difficultés quant à ce qui concerne le traitement des informations qui lui sont liées.
Ainsi, il nous a été capital de voir, pour le cas de notre sujet : <<Conception et réalisation d’une application web pour la gestion des étudiants, des groupes >>, dans quelle mesure la gestion automatisée peut-elle être un élément nécessaire permettrait surtout l'allégement du travail de l'homme et fournir les résultats précis. B- Problématique : C- Objectifs: Compte tenu de la richissime diversité et du nombre sans cesse grandissant des étudiants dans les instituts et les facultés supérieures, une gestion plus efficace utilisant les outils informatiques permettra de gérer au mieux les volumes importants des étudiants mises à la disposition du responsable de gestion des ressources humaines.
L'objectif de ce projet est de mettre en place une application de gestion semi-automatique
qui permet de gérer le système d'information des étudiants et leurs groupes , ce qui facilitera le travail du responsable de gestion de ressources humaines et exclura les erreurs qu’il peut faire d'une part, et d'autre part, qui réduira de manière systématique la durée de recherche documentaire.
Pour aboutir à cette fin nous allons tout d'abord effectuer une étude conceptuelle de l'application . Cette dernière nous permettra , en effet , d'accéder facilement à la réalisation de l'application en organisant les idées et en structurant le processus de codage suivant des diagrammes . D- Spécification des besoins : 1-identification des besoins :
1.1 – besoins fonctionnelles:
Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement d'entrée / sortie du Système. 1.2 -Besoins non-fonctionnelles:
Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes d'implémentation.
l'application devra être:
Extensible, c'est-à-dire qu'il pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités. Compatible avec n'importe quel système d'exploitation. Hautement sécurisée car les informations ne devront pas être accessibles à tout le monde afin de protéger les données personnelles des étudiants. Avec une interface simple et facile à utiliser pour aider l’utilisateur à mieux gérer son espace de travail. 2- IDENTIFICATION DES ACTEURS:
Pour cette application, nous avons identifié un seul acteur principale, c’est l’administrateur qui a pour rôle de gérer les étudiants et leurs groupes depuis la conception jusqu’à la maintenance de l’application web. E- Diagramme de cas d’utilisation: Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de: - Modélisant les besoins des utilisateurs. - Identifiant les grandes fonctionnalités et les limites du système. - Représentant les interactions entre le système et ses utilisateurs. Scénario: spécification du cas d'utilisation : gérer les étudiants résumé: ce cas d'utilisation permet d'effectuer des opérations quant à ce qui concerne un étudiant acteur principal : administrateur Scénario nominal : cas d'utilisation 1 : Ajouter un étudiant 1-Le système affiche le formulaire à remplir 2-l’administrateur remplit le formulaire et le valide 3-le système met à jour la base de données cas d'utilisation 2 : Rechercher un étudiant 1-le système affiche le formulaire de recherche 2-l’administrateur ajoute le numéro d’inscription de l’étudiant 3-le système affiche les coordonnées de l’étudiant cas d'utilisation 3: supprimer un étudiant 1-l'administrateur choisit l’étudiant à supprimer 2-le système demande une confirmation 3-l’administrateur valide l'opération 4-le système met à jour la base de données des étudiants cas d'utilisation 4: modifier des données 1-l’administrateur choisit l’étudiant à modifier 2-le système affiche le formulaire de modification 3-l’administrateur modifie les coordonnées 4-le système met à jour la base de données suite au modification Scénario alternatif et d’erreurs : • cas d'utilisation 1 : Ajouter un étudiant 1.a étudiant existe déjà • cas d'utilisation 3: supprimer un étudiant 3.a étudiant n’existe pas 1-le système affiche un message d’erreur 1- le système affiche un message d’erreur 2-le CU se termine. 2- le CU se termine 1.b champs non conformes aux types • cas d'utilisation 4: modifier des données 1-le système affiche un message d’erreur 4.a champs non conformes aux types 1-le système affiche un message d’erreur 2-le CU se termine. 2-le CU se termine. 1.c formulaire avec des champs vides 4.b formulaire avec des champs vides 1-le système affiche un message d’erreur 1-le système affiche un message d’erreur 2-le CU se termine. 2-le CU se termine. • cas d'utilisation 2 : Rechercher un étudiant 2.a étudiant non existant 1- le système annonce l’administrateur que cet étudiant n'existe pas 2- le CU se termine Scénario spécification du cas d'utilisation : gérer les groupes résumé: ce cas d'utilisation permet d'effectuer des opérations quant à ce qui concerne un groupe d’étudiant acteur principal : administrateur
Scénario nominal : • cas d’utilisation 5: affecter un étudiant à un groupe
• cas d'utilisation 1 : Ajouter un groupe 1-l’administrateur choisir un groupe déjà existant 1-Le système affiche le formulaire à remplir 2-le système affiche le formulaire d’ajout d’un nouveau étudiant 2-l’administrateur remplit le formulaire et le valide 3-l’administrateur remplit le formulaire et le valide 3-le système met à jour la base de données 3-le système met à jour la base de données des étudiants et • cas d'utilisation 2 : Rechercher un groupe des groupes 1-le système affiche le formulaire de recherche • cas d’utilisation 6 : afficher la liste des groupes 2-l’administrateur ajoute le numéro du groupe 1-le système affiche la liste des groupes existant 3-le système affiche les informations du groupe • cas d'utilisation 3: supprimer un groupe 1-l'administrateur choisit le groupe à supprimer 2-le système demande une confirmation 3-l’administrateur valide l'opération 4-le système met à jour la base de données des groupes • cas d'utilisation 4: modifier des données du groupe 1-l’administrateur choisit le groupe à modifier 2-le système affiche le formulaire de modification 3-l’administrateur modifie les coordonnées voulus 4-le système met à jour la base de données suite au modification. Scénario alternatif et d’erreurs :
cas d'utilisation 1 : Ajouter un groupe • cas d'utilisation 3: supprimer un groupe
1.a groupe existe déjà 3.a groupe inexistant 1- le système affiche un message d’erreur 1-le système affiche un message d’erreur 2- le CU se termine 2-le CU se termine. 1.b champs non conformes aux types cas d'utilisation 4: modifier des données du groupe • 4.a champs non conformes aux types 1-le système affiche un message d’erreur 1-le système affiche un message d’erreur 2-le CU se termine. 2-le CU se termine. 1.c formulaire avec des champs vides 4.b formulaire avec des champs vides 1-le système affiche un message d’erreur 1-le système affiche un message d’erreur 2-le CU se termine. 2-le CU se termine. • cas d'utilisation 2 : Rechercher un groupe 2.a groupe inexistant 1- le système annonce l’administrateur que ce groupe n'existe pas 2- le CU se termine F- Diagramme de classe : Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et dynamiques. G- les interfaces : Les interfaces graphiques de l'application sont très importantes, car elles permettent de faciliter le dialogue entre l'homme et la machine ainsi que d'améliorer les performances de l'application. Dans la conception des interfaces de notre application nous avons respecté un ensemble des choix ergonomiques comme la lisibilité, la compréhensibilité, etc. Dans ce qui suit une présentation des captures écrans des plus importantes interfaces de l'application. interface d’authentification: l'authentification pour un système informatique est un processus permettant au système de s’assurer de la légitimité de la demande d’accès faite par le responsable Cette première capture présente l'interface d'authentification dans laquelle on doit choisir le nom d'utilisateur et entrer le mot de passe pour commencer à utiliser notre application. Interface d'accueil : Dans notre application , on a seulement un utilisateur qui est l’administrateur . Par conséquent, nous avons prévu un login et un mot de passe pour lui . Une fois l'administrateur est authentifié, il aura accès aux différentes utilisations de l'application et pourra gérer tous les éléments de la base de données. Il possède tous les droits d'accès sur toutes les tables de la base. Pour la gestion des étudiants, par exemple, il suffit de cliquer sur le menu données puis le menu item« Gestion des étudiants » pour effectuer une modification, un ajout, ou une suppression dans la liste des étudiants. Interface de gestion des étudiants : Interface de gestion des Groupes : H- Tables relationnelles
USER STORY: Une user story est une demande fonctionnelle basée sur l’un ou les utilisateurs clés du produit qui va rajouter de la valeur business au produit. Elle sera écrite dans un langage naturel compris par l’ensemble des acteurs du projet ou liés à celui-ci. Elle est généralement rédigée par le Product Owner, afin de définir un besoin auprès des équipes de développement USER BACKLOG: Aujourd'hui, nous vous parlons de l'importance du Product Backlog dans un projet Scrum. Sous la responsabilité du Product Owner, il va permettre de planifier les sprints et de prioriser les attentes et les besoins du client. Courbe De Burn Down Chart :
Un Burndown Chart est un graphique simple qui indique le degré d'avancement dans la réalisation des tâches. En d'autres termes, c'est une représentation graphique de l'évolution de la quantité de travail résiduelle en fonction du temps, sur une période donnée
