Projet UML Etude d`une plate-forme pédagogique orientée gestion

Projet UML
Etude d'une plate-forme pédagogique orientée gestion de projet
1. Descriptif du projet
Une plate-forme de gestion de projet pédagogique permet à un enseignant de suivre
l'évolution des projets qu'il a donnés à ses étudiants. Elle permet aussi à chaque groupe
d'étudiants d'organiser l'activité au sein de son projet, d'échanger, et de déposer des
documents. Cette plate-forme se présente sous la forme d'une application Web qui propose un
outil de gestion de projet aux étudiants et des fonctions de visualisation de l'état d'un projet
pour l'enseignant.
2. Cahier des charges
2.1.Du point de vue de l'enseignant
L'enseignant doit pouvoir mettre en place un projet en :
-
Choisissant une promotion d'étudiants,
-
Constituant une liste de groupes,
-
Déposant un cahier des charges,
-
Définissant une liste de phases (nom, date début, date fin, objectif).
Pour chaque phase l'enseignant doit décrire :
-
Les documents (artefacts) à rendre (nom, forme, format, descriptif),
-
Les outils à utiliser,
-
Les acteurs et leur rôle (cf. définition des rôles).
La visualisation de l'état d'avancement du projet permet à l'enseignant de voir pour chacune
des phases qu'il a planifiées et pour chacun des groupes :
1
-
Son état d'avancement (planifiée, en cours avec pourcentage d'avancement, terminée,
en suspend à cause d'un problème),
-
Les documents produits et leur état d'avancement,
-
Les noms d'étudiants affectés aux acteurs,
-
Les demandes (questions) formulées par les étudiants,
-
La liste des échanges effectués par les étudiants au sein de leur groupe.
Enfin l'enseignant doit pouvoir répondre aux demandes des étudiants et formuler ses propres
demandes.
2.2.Du point de vue des étudiants
Chacun des groupes d'étudiants doit utiliser la plate-forme pour gérer son projet. Il doit
pouvoir :
-
Créer des tâches à l'intérieur des phases planifiées par l'enseignant,
-
Affecter des noms d'étudiants aux acteurs définis par l'enseignant,
-
Déposer les documents (artefacts) demandés par l'enseignant et indiquer leur état
d'avancement,
-
Modifier l'état d'avancement des phases,
-
Envoyer une demande (par phase) à l'enseignant,
-
Envoyer des demandes (par tâche ou phase) aux acteurs (de la tâche ou phases)
Chaque tâche définie par les étudiants est associée à une liste d'acteurs (parmi ceux défini
par l'enseignant) participant à la tâche, une liste de documents à produire ou à utiliser. Une
tâche possède un objectif à atteindre, une date de début au plutôt, une date de début au plus
tard, une fin au plutôt, une fin au plus tard, une durée et un état (planifiée, en cours avec
pourcentage d'avancement, terminée, en suspend à cause d'un problème).
2.3.Remarques
Tout acteur possède un nom, un état décrivant sa participation au projet : inactif (ne participe
pas actuellement à l'activité du projet), actif (participe actuellement à l'activité), et un état
relativement à la plate-forme (connecté, non connecté).
Un acteur, associé à une tâche ou à une phase, possède un rôle : responsable, producteur,
lecteur. Ces rôles définissent des droits d'accès à l'information attachée à la tâche ou à la
phase. Le responsable a tous le droits (ajout/suppression d'acteur, ajout/suppression de
2
documents, formulation de tout type de demandes,...), le producteur peut déposer, modifier,
supprimer les documents associés à la tâche, enfin les lecteurs ne peuvent que consulter les
documents et formuler un avis.
Les demandes sont des messages typés. Elles sont formulées par un acteur ou par l'enseignant
à partir d'une phase ou d'une tâche. Elles sont adressées à l'enseignant (quand elles
proviennent d'étudiants) ou à un ou plusieurs étudiants (quand elles proviennent d'étudiants ou
de l'enseignants). Les destinataires étudiants doivent faire partie des acteurs de la tâche ou de
la phase concernée. Elles contiennent : un sujet (objet de la demande), une liste de
destinataires, un type, le descriptif de la demande. Des documents peuvent être liés à la
demande, ils doivent être pris dans ceux définis dans la tâche ou phase associée. Le type d'une
demande peut être :
-
Pour information : informer les destinataires
-
Pour avis : un avis en retour est demandé
-
Pour validation : une validation (d'un responsable) est demandée
-
Pour réalisation : une demande de travail à faire est demandée (d'un responsable à un
autre acteur)
3. Travail demandé :
Le travail demandé consiste à fournir un rapport de conception de l'application ainsi qu'une
maquette du logiciel. Il consiste en la première itération du processus et s'effectuera par
groupe de trois ou quatre.
Il est demandé de gérer le projet en suivant les règles de bonne pratique de la gestion de projet
et de l'assurance qualité. Les justificatifs (compte-rendu de réunion, analyse de risques,
livrables (versionné si besoin), planning prévu/réel, répartition des personnes et des rôles,
etc.) devront être annexés au projet.
Le rapport consistera en un document qui contiendra une partie dédiée à l'aspect gestion de
projet, une autre à l'analyse et finalement à la conception de cette plate-forme.
Proposition de plan :
-
Présentation du projet
3
-
Définition des objectifs
-
Environnement projet
o Analyse des besoins
o Cas d'utilisation
-
Séquence système
-
Faisabilité et Risques
-
Planification
-
Analyse
o Modèle du domaine
o Diagramme des classes participantes
o Diagramme d'activités de navigation
-
Conception
o Diagrammes d'interaction
o Diagramme de classes de conception
-
Maquette
-
Conclusion
Remarques :
-
La modélisation de l'application se fait sur le logiciel de votre choix mais doit être
motivé.
-
Le développement de la maquette se fait aussi dans le langage de votre choix et sera
tout aussi motivé.
-
L'ensemble des cas d'utilisation peut ne pas être traité mais les cas d'utilisation
fondamentaux doivent tout de même l'être.
-
Le rapport sera remis le 19 janvier 2014, et une démonstration de l’application sera
fixée la semaine qui suit les examens du premier semestre.
4