Création d'un logiciel de gestion de présence des enseignants

Résumé du document

Ce document est le cahier des spécifications techniques des besoins et exigences du logiciel de gestion de présence des enseignants, soumis à l'attention de notre équipe de projet, dans le cadre d'un projet de Génie Logiciel en 4GI. Le défi qui nous a été proposé est de réaliser une application permettant de gérer les présences et absences des enseignants de l'ENSP.

Le produit dont il est question est le logiciel de « Gestion de la Présence des Enseignants ». C'est un logiciel fenêtre édité par le groupe 4 dans le cadre d'un projet de Génie Logiciel en 4GI. Ce logiciel est capable de gérer les présences des enseignants de l'ENSP, en ce qui concerne la création et la gestion des emplois du temps des enseignants et des classes, l'enregistrement effectif des présences et des absences des enseignants de l'école lors des cours, et l'utilisation de ces données pour une meilleure programmation horaire des cours au sein de l'école.

Notre logiciel est un logiciel dont le principal objectif est le suivi des absences et présences des enseignants au sein de l'école, ce pour fournir au corps administratif des données essentielles pour la prise de décision et la gestion de la masse salariale. Il est conçu aussi pour pouvoir permettre aux enseignants de suivre leur progression tout au long de l'année, en ce qui concerne le volume horaire contractuellement accordé pour les matières qu'ils dispensent tout au long de l'année. C'est donc un logiciel axé sur l'édition et une consultation régulière des informations relatives aux absences des enseignants.

Les fonctionnalités que doit remplir notre logiciel découlent des besoins, à savoir notamment :
• La satisfaction des besoins qui ont été largement évoqués dans le cahier de charge, parmi lesquels, entre autres :
• La possibilité de consulter les états et de pouvoir les imprimer
• La fourniture en statistiques : en effet, c'est le principal atout pour la prise de décision
• La sécurité

Lors de la définition du projet, les limites d'utilisation de notre logiciel n'ont pas été fixées. Cependant, une estimation du nombre de personnel à traiter nous donnerait une idée des capacités limites de notre application. Ainsi, il sera défini que notre application devra être capable de pouvoir traiter dans des conditions raisonnables, un nombre de 2 000 enseignants, ce qui équivaudrait à la capacité d'une université de grande taille.

Extraits

[...] Création d'un logiciel de gestion de présence des enseignants Sommaire 1. Généralités Objet de la spécification Domaine d'utilisation Identification du produit Terminologie et abréviations Spécifications générales Description du produit et de son utilisation Descriptions générales des fonctionnalités du produit Exigences opérationnelles Contraintes d'exploitation Capacités limites Performances fonctionnelles Sûreté de fonctionnement (FDMS, confidentialité, intégrité, ) Exigences de réalisation Solutions techniques imposées Interfaces avec le matériel Interfaces avec d'autres logiciels Architecture matérielle opérationnelle Description générale de chaque fonction Fiche de description des cas d'utilisation Diagramme des cas d'utilisation Divers 14 Généralités 3 Objet de la spécification Ce document est le cahier des spécifications techniques des besoins et exigences du logiciel de gestion de présence des enseignants, soumis à l'attention de notre équipe de projet, dans le cadre d'un projet de Génie Logiciel en 4GI. [...]

[...] C'est donc un logiciel axé sur l'édition et une consultation régulière des informations relatives aux absences des enseignants Descriptions générales des fonctionnalités du produit Les fonctionnalités que doivent remplir notre logiciel découlent des besoins, à savoir notamment : La satisfaction des besoins qui ont été largement évoqués dans le cahier de charge, parmi lesquels, entre autres : La possibilité de consulter les états et de pouvoir les imprimer La fourniture en statistiques : en effet, c'est le principal atout pour la prise de décision La sécurité 11 Exigences opérationnelles 13 Contraintes d'exploitation Notre système reposera sur l'utilisation d'une architecture logique de type 3 tiers, ce qui permettra de gérer : Un grand nombre de clients (n'oublions pas que nous destinons notre logiciel à une utilisation dans une institution aussi grande qu'une université) Un très grand nombre de traitements 14 Capacités limites Lors de la définition du projet, les limites d'utilisation de notre logiciel n'ont pas été fixées. Cependant, une estimation du nombre de personnel à traiter nous donnerait une idée des capacités limites de notre application. Ainsi, il sera défini que notre application devra être capable de pouvoir traiter dans des conditions raisonnables, une masse d'enseignants de enseignants, ce qui équivaudrait à la capacité d'une université de grande taille Performances fonctionnelles Les fonctionnalités que doit satisfaire notre logiciel découlent principalement des besoins recensés dans le cahier de charge. [...]

[...] On peut donc citer comme fonctionnalités : La satisfiabilité des besoins listés dans le cahier de charge : en effet c'est la raison d'être de notre projet La possibilité de consulter et pouvoir imprimer les états du système La mise en œuvre d'une base de données statistique utile pour la prise de décision La gestion ordonnée des utilisateurs pour éviter des erreurs de privilège Sûreté de fonctionnement (FDMS, confidentialité, intégrité, ) Intégrité : Le système aura à modifier des informations de manière permanente. Le logiciel devra donc s'assurer de l'intégrité et de l'actualité des informations présentées aux utilisateurs. Un point sera mis sur la connectivité pour garantir la conservation des informations. Sécurité : Le logiciel devra s'assurer que les utilisateurs bénéficieront d'un droit d'accès ne débordant pas de leurs privilèges définis au départ. Maintenabilité : Comme nous l'avons énoncé plus tôt, le logiciel pourra dans la suite être déployé sur une plate-forme plus importante que l'ENSP. [...]

[...] Mais, vu que les logiciels utilisés n'ont pas été spécifiés, notre logiciel devra d'abord fonctionner sans tenir compte de ces autres applications. Mais, dans un souci de maintenabilité, il pourra, nonobstant des mises à jour, intégrer les logiciels qui voudront s'y ajouter Architecture matérielle opérationnelle Figure 1 Architecture du système Description générale de chaque fonction Ici, nous allons lister les cas d'utilisation et en faire une description 25 Fiche de description des cas d'utilisation NB : tous les cas d'utilisation ont un flux alternatif commun : en cas d'identification incorrecte, un message d'erreur sera envoyé Diagramme des cas d'utilisation Divers Ce cahier marque la fin de la phase d'analyse et le début de la phase de conception. [...]

[...] Des mises à jour de ce logiciel sont plus que probables. La conception de notre application devra tenir compte de modifications éventuelles futures Exigences de réalisation 19 Solutions techniques imposées Le langage de programmation imposé est le JAVA (J2SE et J2EE), qui est un langage de programmation purement orienté objet, développé par Sun Microsystems. Le logiciel devra aussi se servir des accès distants (RMI, servlets). Pour cela, nous avons choisi la spécification J2EE, qui fournit l'architecture nécessaire au développement d'applications distribuées. [...]