Vous êtes sur la page 1sur 21

Dossier de Conception

Intranet Pédagogique

Dossier de Conception Intranet Pédagogique

Table des matières

I. Introduction

2

II. Qu’est ce que « méthode agile »

2

III. Les différentes méthodes agiles

3

 

1. Méthode agile « XP »

4

2. Méthode agile «RUP »

4

3. Méthode agile « Scrum »

5

4. Méthode agile « FDD »

5

IV. Comparaison entre les méthodes

7

V. Méthode agile adaptée

8

VI. Implémentation de la méthode

10

Conception

13

I.

User Cases

14

1. User case : Etudiant

14

2. User case : Professeur

16

3. User case : Personnel pédagogique

18

4. User case : Personnel administratif

21

I.

Introduction

Afin de faciliter l’interaction client et maitre d’ouvrage, on procède par une méthode agile qui permet au client d’être pilote à part entière de son projet et être à jour de son avancement. Cette méthode vise la satisfaction réelle du besoin du client et non les termes d’un contrat du développement.

Dans le cas du projet de l’Intranet Pédagogique, on a opté pour la méthode « Scrum » et « XP » (Extreme programming). La première pour la gestion de l’équipe et la deuxième pour l’application.

Ce document propose une clarification des différentes méthodes et une synthèse du fondement du choix proposé.

II. Qu’est ce que «méthode agile » :

Les méthodes agiles permettent de concevoir des logiciels en impliquant au maximum le demandeur (Client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus programmatique. Elles visent la satisfaction réelle du besoin du client, et non d’un contrat préalablement.

Une telle intégration du client dans l’avancement du projet ne serais que favorable, Le client sera tous d’abord impliquer, la rectification rapide des problèmes de compréhension du besoin du client, et aussi la motivation de l’équipe de travail.

Il y’a quatre fondamentaux processus de méthode agile :

mettre en œuvre des individualités et des interactions, plutôt que des procédés et des outils. Cela se manifeste par l'accent mis sur les êtres humains en tant qu'individus et sur l'expertise des équipes de développement, qui communiquent entre elles de façon très serrée et dans un esprit de confiance constant.

Travail en groupe, communication

produire un logiciel entièrement testé et qui fonctionne, plutôt qu'une documentation claire. On rejoint ici les notions de développement itératif (notion de phases) et d'intégration continue (notion de builds journaliers), en insistant sur la simplicité et la robustesse du code produit (tests systématiques).

Documentations succinctes à jours, documentation permanente du code

collaborer avec le client, plutôt que négocier un contrat. Le client devient un partenaire à part entière, qui participe au développement dans le sens où il détermine l'objectif à atteindre pour obtenir une réelle plus-value (qui seule justifie les efforts effectués pendant le développement)

Feedback régulier du client, solution répondant réellement aux attentes, relation de confiance

répondre aux modifications, plutôt que suivre un plan. Il est bien évident que personne, pas même le client, ne peut appréhender avec précision l'ensemble des besoins dès le début du projet. Le développement agile vise à atteindre un compromis entre les spécifications initiales présentées aux développeurs (et sur lequel se fonde le planning) et le résultat final qui bien souvent s'en éloigne un peu voire beaucoup, en absorbant les modifications tout au long du cycle de développement. Cela réclame des outils de suivi et une attitude constante de coopération avec le client.

Planning flexible, modification possible après première version du système

III.

Les différentes méthodes agiles :

Parmi les différentes méthodes agiles existantes on site :

- XP (Extrem Programming)

- Scrum

- FDD (Feature-Driven Development)

- RUP (Rational Unified Process)

1. La méthode agile « XP »

Il s'agit plus d'un ensemble de pratiques à dimension humaine, plutôt qu'une véritable méthode. Il faut bien reconnaître qu'elle a de gros côtés positifs et qu'elle est assez facile à mettre en œuvre, au prix parfois d'un changement de mentalité et d'une acceptation par l'ensemble des équipes impliquées. Il s'agit ici d'appliquer "à l'extrême" les principes du développement agile, en se focalisant sur les besoins du client, les individualités, le développement itératif et l'intégration continue. Le développeur et ses relations avec le client sont au cœur de XP. Cette méthode convient à des équipes petites voire moyennes, soit jusqu'à une vingtaine de personnes environ.

Le plus surprenant dans cette méthode est qu'elle peut sembler naturelle, mais qu'elle n'est concrètement pas évidente à appliquer et à maîtriser car elle réclame beaucoup de discipline et de communication (contrairement à la première impression qui peut faire penser à une ébullition de cerveaux individuels). Il s'agit d'aller vite, sans perdre de vue la rigueur du codage et les fonctions finales de l'application. La grande force de XP (et le plus grand risque de le faire échouer) est précisément sa simplicité et le fait qu'on va droit à l'essentiel, selon un rythme qui doit rester constant.

2. La méthode agile « RUP »

RUP est une véritable méthode qui couvre l'ensemble du cycle de développement. Son étendue, son coût et sa lourdeur apparente la réserve pour les projets de moyenne voire de grande importance. Bien que ses auteurs affirment qu'il est possible d'adapter RUP pour de petits projets, la tâche semble ardue, car RUP propose un processus complet dont la rigueur et le formalisme (documentation exhaustive) peuvent rebuter. Une formation préalable est indispensable si on ne veut pas se perdre dans les centaines de pages HTML qui forment le processus et les nombreux "artefacts" (documents et logiciels) que RUP propose de produire.

RUP a un coût d'investissement très important et, en un sens, il peut être considéré comme pas tellement "agile" car trop rigide. Il s'agit ici cependant d'un véritable outil complet de gestion de projets. RUP fournit un cadre générique qu'il faut adapter à chaque application. Il est centré sur une architecture incrémentale et itérative, le développement s'articule autour du modèle objet et des cas d'utilisation, et favorise UML en tant que langage de modélisation. RUP affecte à chacun un rôle très clair. RUP est formé d'un découpage en 4 phases : inception (objectifs et cas d'utilisation), élaboration (architecture logicielle), construction (développement), transition (déploiement). Chaque phase se découpe en itérations. Chaque itération dure entre deux semaines et six mois et fournit une version de l'application.

Moins "extrémiste" que XP, RUP donne en même temps une apparence de plus grande rigueur, ce qui peut rassurer certains clients habitués aux documentations exhaustives.

3. La méthode agile « Scrum »

Le terme "Scrum" (qui provient d'une stratégie de rugby) se rapproche plus d'une gestion de ressources humaines plutôt que d'une réelle méthode de développement. Il s'agit ici de ne pas oublier le côté humain du développement. Cette approche a été mise au point par Ken Schwaber.

Théoriquement, Scrum peut se marier d'ailleurs très bien avec XP, en fournissant aux développeurs "agiles" un cadre de prise en compte du facteur humain. On peut alors envisager des projets plus importants qu'avec le simple XP. Comme RUP, il s'agit d'un processus incrémental, mais bien moins formalisé : Scrum ne propose aucune pratique de développement, juste des pratiques de management. Il s'agit en fait d'un cadre de gestion de projets bien adapté aux méthodes de développement agile, comme XP.

4. La méthode agile « FDD »

Cette méthode, élaborée par Jeff de Luca et Peter Code, est plus formalisée que XP. On peut presque considérer que FDD est une application très "light" de RUP, car sa particularité est de ne se concentrer que sur les phases de design et de réalisation, ce qui consiste à élaborer le modèle objet du domaine avec des diagrammes UML, découvrir la liste des fonctions de l'application, puis implémenter chacune de ces fonctions, l'une après l'autre.

IV.

Comparaison entre les méthodes

Voici un tableau synthétique de la comparaison entre les méthodes cités au préalable.

Méthodes

 

Points forts

   

Points faibles

 

XP

Développement guidé par les besoins du client.

les

-

Equipes

réduites,

centrées

-

sur

focalisation sur l'aspect individuel du développement.au détriment d'une vue globale et des pratiques de management ou de formalisation.

-

développeurs.

 

- Binômes. Builds journaliers.

 

-

Risque de manque de contrôle et de

- Amélioration constante.

structuration

 

en

laissant

les

développeurs

 

- Adaptabilité aux modifications.

 

RUP

-Processus complet assisté par des outils

-Lourd, largement étendu, il peut être difficile à mettre en œuvre de façon spécifique.

-Exhaustif

 

-Rôles bien définis, modélisation.

 

- Convient pour les gros projets qui génèrent beaucoup de documentation.

Scrum

-Petites équipes.

 

-La mise en œuvre du développement n'est pas précisée.

-Itérations de 30 jours.

 
 

-Priorité

à

la

gestion des

ressources

humaines.

-Réunions journalières.

 

FDD

-Procédé bien défini et simple.

 

-Uniquement

 

centré

sur

le

 

développement.

 

-Orienté

objet

et

basé

sur

le

 

développement. Itérations très courtes.

 

V.

Méthode agile adaptée :

D’après le tableau comparatif on remarque que la combinaison entre la méthode « Scrum » et « XP » est la mieux adaptée à notre projet intranet pédagogique, pour les raison suivantes

- On forme une petite équipe de 6 personnes.

- Réunions régulières

- Rapport livrable chaque quinzaine.

- Donner confiance au développeur

On a divisé le projet en deux parties coté organisation dans le quel on va utiliser « Scrum » et coté mise en place dans lequel on va utiliser « XP ».

Quant à la pratique de ces deux méthodes on les résume dans les points suivants :

- donner toute confiance aux développeurs et les laisser faire leur travail

- faire des réunions tous les jours pour encadrer les équipes et recaler les objectifs

- Le développement est itératif, le logiciel est livré fréquemment : XP découpe le projet en phases, comme dans un projet classique (définition des besoins, construction, déploiement), mais la phase de construction est découpée en multiples itérations qui sont elles-mêmes découpées en phases (spécifications courtes, développement, tests, retour du client). Le fonctionnel de l'application est décrit en brefs scenariis qu'on peut implémenter tout de suite et que le client peut juger très tôt. Les mésententes de compréhension sont alors réduites au maximum.

- Les équipes XP mettent en production un système simple très tôt, et intègrent les modifications très fréquemment, sur un temps de cycle très court. L'objectif est de disposer d'un pilote opérationnel très rapidement et de réduire au maximum les risques dès le début du projet, ainsi que de fournir très régulièrement des versions effectives

- Le système est remanié progressivement, tout au long du développement, par petits morceaux. Le logiciel est propre : pas de duplication, une grande communication, simple, mais complet. Le nettoyage doit se faire régulièrement (prévoir des séances pour toute l'équipe).

- Les programmeurs XP travaillent en binôme sur la même machine. Chaque programmeur code à tour de rôle, pendant que l'autre réfléchit à la prochaine fonctionnalité à implémenter. Cela nécessite tout de même une bonne entente en tant qu'individualités. Cela est censé produire un code robuste et de qualité. En pratique ce n'est pas aussi simple ni

répandu, car il ne s'agit pas de perdre de temps en discussions interminables entre deux façons de coder une fonction. Souvent, les développeurs ne s'associent donc en binômes que lors des séances de refactoring, ou quand ils ont à résoudre un problème difficile à plusieurs.

- Tout le code appartient à tous les programmeurs, la responsabilité est collective. Quand il faut changer quelque chose, on peut le faire tout de suite, ce qui permet de travailler à plein régime et de bien appréhender les problèmes de turn-over

- L'intégration du logiciel est continue, avec plusieurs builds par jour. On n'attaque pas tout en bloc de front, mais on sépare la tâche en petits modules intégrés et testés progressivement. Le système est donc plus stable et opérationnel rapidement. Cela impose de disposer d'outils que chaque développeur maîtrise pleinement.

VI.

Implémentation de la méthode :

On va définir les spécifications sous forme de Backlogs ces derniers seront subdivisés en unités fonctionnelles indépendantes appelées épics. Jusqu’à la date de livraison du produit final le temps sera définit en plusieurs itérations chacune comportera un certain nombre d’épics. A la fin de chaque itération il sera établi un bilan de ce qui a été fait. Chaque épic sera subdivisé en sous unité appelées stories. Une story est écrite sous la forme suivante :

« En tant que <rôle> je veux <But> pour <Résultat> » Une story est subdivisée en petit tâches techniques appelés tasks. La fin d’une story est conditionnée par la réalisation de conditions de test exprimées dans une phase appelée critère d’acceptation.

Backlog
Backlog
épic
épic
épic
épic
story
story
story
story
task
task
task
task

Hiérarchie de l’implémentation Scrum

On va distinguer trois rôles :

Un Scrum Master : animateur d’équipe. Son rôle est de s’occuper de toutes les choses non liées au développement afin que l’équipe ne soit pas dérangée.

Un Product Owner : représentant du (des) client(s) au sein de l’entreprise. Son rôle est de définir les priorités dans les tâches à réaliser (fonctionnalités à développer) et de valider / conseiller les choix effectués (ex: pour une IHM). Cette personne doit bien connaître les besoins du client.

L’équipe : elle est auto-gérée et il n’y a aucune notion de hiérarchie. Les décisions se prennent ensemble et elles peuvent récupérer des informations auprès du ProductOwner.

Au niveau du planning de livraison du produit (logiciel), on retrouve également 3 niveaux :

du produit (logiciel), on retrouve également 3 niveaux :  Un point quotidien est fait sur

Un point quotidien est fait sur l’état du logiciel (lors du Daily Scrum)

Le sprint : correspond à une itération du projet livrée en interne, durant laquelle un lot de fonctionnalités (déterminé au départ) est développé. Les buts d’une itération sont fixés au début de celle-ci et ne sont pas (ou peu) changés durant les quelques semaines du sprint.

La release : constituée de plusieurs sprints, cette étape correspond à un état d’avancement où le produit doit potentiellement pouvoir être mis en production.

Ainsi la méthode Scrum s’occupe de tout ce qui est organisation et relation (Client / équipe). Afin d’optimiser la réalisation de notre intranet on fera appel à la méthode XP pour tout ce qui est développement.

Les pratiques de base de XP sont les suivantes :

Les pratiques de base de XP sont les suivantes : Pratique de base du processus XP

Pratique de base du processus XP

Programmation en binôme : le principe est de faire travailler deux développeurs sur une même machine afin de garantir une bonne qualité du code.

Règle du codage : tous les développeurs doivent respectés les mêmes règles du codage.

Priorité collectif du code : le code n’appartient à personne.

Métaphore : décrire le système et les fonctionnalités par une métaphore pour améliorer la communication entre techniciens et fonctionnels.

Intégration continue : assembler l’intégralité du code et le tester plusieurs fois par jour sur une machine dédiée à cela.

Conception simple : adopté une solution simple à implémenter.

Développement piloté par les tests unitaires : chaque développeur écrit un scénario de test unitaire pour le code qu’il produit.

Remaniement continu ou refactorisation de code : consiste à rendre le code plus « propre » et à améliorer la conception sans en modifier le comportement.

Conception

I.

Use Cases :

Nous allons passez à la partie conception, en commençant par les user cases de l’étude de l’intranet.

1. Use case étudiant :

ID Use Case :

1

Titre du cas d’utilisation:

Espace Etudiant

Description sommaire:

Les principales fonctionnalités données à un étudiant

Référence croisée :

Aucune

Acteurs :

Etudiant de l’AIAC

Règle d’initiation :

 

- Une connexion à l’intranet doit être établie.

- La personne doit faire partie des élèves inscrits à l’AIAC pour faire une nouvelle inscription.

- Le nom de l’utilisateur ainsi que le mots de passe doivent être validés.

Description :

Un étudiant à l’académie peut se connecter à cet intranet, après avoir créer un compte propre à lui, pour télécharger des documents postés auparavant , participer au forum, passer un test, entrer au wiki ou au FAQ ou tout simplement pour consulter sa boîte de messagerie et voir les actualités qui peuvent le concerner. Tout cela vient après une authentification valide de cet étudiant.

Règle de terminaison:

-

Pour une nouvelle inscription un nouvel étudiant sera ajouté à la liste.

-

Exception :

-

La personne tentant de se connecter ne fait pas partie des véritables élèves.(pas de validation de compte)

-

Identifiant ou mot de passe erroné.

Cas d’utilisation :

Contacter webmaster S'inscrire <<include>> Regarder l'actualité,publication
Contacter webmaster
S'inscrire
<<include>>
Regarder l'actualité,publication
<<extend>>
Consulter actualité
Consulter publication
<<extend>>
Participer au forum
<<include>>
Consulter messagerie
<<include>>
S'authentifier
<<include>>
Agir sur cartable électronique
<<extend>>
Ajouter cours,TD,fiche de TP
<<extend>>
Ajouter
<<extend>>
Supprimer
<<include>>
Entrer au FAQ
<<extend>>
<<extend>>
Poser de nouvelles questions
Consulter questions+réponses
Passer test
<<include>>
<<extend>>
Entrer au wiki
<<include>>
<<extend>>
<<extend>>
Modifier topic
Ajouter topic
Consulter topic
<<extend>> <<extend>> Modifier topic Ajouter topic Consulter topic Etudiant

Etudiant

2. Use case professeur:

ID Use Case :

2

Titre du cas d’utilisation:

Espace Professeur

Description sommaire:

L’utilisateur étant membre des professeurs de l’académie accède à l’espace qui lui est consacrée et bénéficie de toutes les fonctionnalités qui lui sont destinées.

Référence croisée :

Aucune

Acteurs :

Professeur

Règle d’initiation :

L’utilisateur doit être un Professeur

Le login et mot de passé de l’utilisateur doivent etre validés.

Description du processus:

Toute personne déjà inscrite et authentifié autant que personnel administratif peut bénéficier des différentes fonctionnalités offertes dans cet espace.

Parmi ces fonctionnalités y on a celle qui sont commune pour tous les espaces tel que :

Forum

Wiki

FAQ

Messagerie

Contacter le web master. etc.…

Les différentes fonctionnalités qu’offre cet espace sont :

Gestion des documents : Ce module offre la possibilité au professeur de gérer ses documents, notamment l’ajout, la modification et la suppression

La consultation des de la liste des élèves et le téléchargement des documents administratifs publiés par le personnel administratif

La création d’un QCM : Après création du QCM, le professeur a le choix entre publier ce QCM ou le stocker.

Règle de terminaison:

 

Cas d’utilisation :

contacter le webmaster s'inscrire <<include>> telecharger les documentation adiministratif
contacter le webmaster
s'inscrire
<<include>>
telecharger les documentation adiministratif
<<include>>
<<include>>
gerer le profil
<<include>>
faire une publication
<<include>>
consulter actualite publication
<<extends>>
<<extends>>
consulter publication
consulter actualite
lister les eleves
<<include>>
s'authentifier
<<include>>
participer au forum
professeur
consulter messagerie
<<include>>
gerer les documents
<<include>>
<<extends>>
<<extends>>
<<extends>>
modifier
ajouter
supprimer
creer un QCM
<<extends>>
<<include>>
<<extends>>
publier un QCM
stocker QCM
entrer FAQ
<<include>>
<<extends>>
<<extends>>
proposer des reponse
consulter
entrer en wiki
<<include>>
<<extends>> <<extends>>
modifier topic
ajouter topic

3. User cases personnel Pédagogique :

ID Use Case :

3

Titre du cas d’utilisation:

Espace pédagogique

Description sommaire:

-

Le cas d’utilisation comporte l’ensemble des tâches lié à la gestion pédagogique au sein de l’académie

Référence croisée :

Aucune

Acteurs :

- Personnel pédagogique.

Règle d’initiation :

- Le web browser ouvert.

- Connexion à l’intranet, utilisateur authentifié ainsi qu’une tâche planifié.

Description :

Le personnel pédagogique peut via le système exécuter un ensemble de tâche qui entre dans le cadre de la gestion pédagogique au sein de l’académie. L’ensemble de tâche se résume en :

- Gestion des publications et actualité : qui contient la consultation de l’ensemble des actualités et publication ajouter par d’autre utilisateur de l’intranet ainsi que la l’ajout des actualités et publication.

- Gestion des emplois du temps : comporte la création des emplois de temps pour l’ensemble des professeurs et étudiant. L’emploi du temps sera générer par un outil de reporting.

- Gestion des étudiants : comprend la gestion de la liste des étudiants (ajout d’un étudiant, liste des étudiants et la modification des informations relatives à un étudiant) ainsi que la gestion de l’absence qui comportera l’état global de nombre d’absence par étudiant sur un intervalle de temps et aussi les alertes d’absence sur des seuils préalablement fixé

- Gestion professeurs : ce cas d’utilisation contient l’édition de liste de matière par professeur ainsi d’autres information et l’envoie de ses listes au professeur concerne par les listes et aussi comportera des cas d’utilisation propre au professeur vacataire. Par le quelle peuvent valider le nombre d’heure de vacation écouler ainsi que le nombre d’heure restant.

- Gestion des documents administratifs : comportera la gestion électronique des documents administratifs

Le cas d’utilisation « gestion pédagogique » intègre l’ensemble des fonctions générique propre a l’intranet tel que :

Messagerie , Wiki , FAQ, Forum etc.

Cas d’utilisation :

Contacter webmaster S'inscrire <<include>> Créer profil <<include>> Participer
Contacter webmaster
S'inscrire
<<include>>
Créer profil
<<include>>
Participer au
forum
<<include>>
Regarder l'actualités,
publications
Consulter
Consulter
<<extend>>
<<extend>>
Actualités
publication
<<include>>
Consulter messagerie
<<include>>
Gérer les emplois du temps
Gérer les
Gérer les
emplois du
emplois du
temps pr
temps pr
<<extend>>
<<extend>>
étudiants
prof
S'authentifier
Gérer les étudiants
<<include>>
<<extend>>
Gérer l'
abscence
<<extend>>
Afficher
liste des
Ajouter
étudiants
Modifier
liste des
liste des
étudiants
<<extend>>
étudiants
<<extend>>
Gérer les professeurs
<<include>>
gestion des
gestion des
<<extend>>
prof
prof
vacataire
permanent
<<extend>>
<<extend>>
<<extend>>
<<extend>>
envoyer la
ajouter liste
envoyer la
consulter le
valider le
ajouter liste
liste de
des matieres
liste de
nbre d'heure
nbre d'heure
des matieres
matiere de
par prof
matiere de
de vacation
ecouler
par prof2
prof2
<<extend>>
<<extend>>
prof
Gérer les documents
administratifs
<<include>>
Entrer au FAQ
<<include>>
Ajouter
Répondre à
question
des quéstions
<<extend>>
<<extend>>
Entrer au wiki
<<include>>
Modifier
Ajouter
topic
topic
<<extend>><<extend>>

personnel pedagogique

4. User cases personnel Administratif :

ID Use Case :

4

Titre du cas d’utilisation:

Espace Personnel Administratif

Description sommaire:

L’utilisateur étant membre du personnel administratif accède à l’espace qui lui est consacrée et bénéficie de toutes les fonctionnalités qui lui sont destinées.

Référence croisée :

Aucune

Acteurs :

Personnel Administratif

Règle d’initiation :

L’utilisateur doit être déjà inscrit.

Une authentification obligatoire de l’usager.

Description :

Toute personne déjà inscrite et authentifié autant que personnel administratif peut bénéficier des différentes fonctionnalités offertes dans cet espace.

Parmi ces fonctionnalités y on a celle qui sont commune pour tous les espaces tel que :

Forum

Wiki

FAQ

Messagerie

Contacter le web master. etc.…

Ce qui caractérise le plus cet espace c’est le fait qu’il donne à ses utilisateurs

l’opportunité de gérer facilement et avec fiabilité les différents modules tout en utilisant des outils simple à manipuler.

On ce qui concerne les modules qui sont propres a cet espace on cite :

Gestion des étudiants : ce module inclus la gestion des documents administratifs propre à l’étudiant tel que les certificats de scolarité, on y trouve aussi un outil de gestion du transport afin d’identifier les différents circuits tout en se basant sur les adresses des élèves.

Gestion des vacations : comme toute école, l’académie fait appel à des professeurs de l’externe et donc une gestion des vacations est primordiale. Pour ce faire cet outil donne la possibilité à l’administration de faire une gestion financière propre à chaque professeur tout en se basant sur le nombre d’heure travaillé par ce dernier.

Gestion des salles : parmi les taches du personnel administratif est la gestion des classes lors des examens, des TP, des séminaires etc. … ce qui est le rôle de cet outil.

Gestion des événements : grâce à ce module l’usager pourra générer un événement que ca soit une publication ou une publication afin d’informer les autres utilisateurs des nouveautés.

Règle de terminaison:

 

Cas d’utilisation :

Contacter le WebMaster S'inscrire <<include>> Gérer le profil <<include>> Gerer
Contacter le WebMaster S'inscrire <<include>> Gérer le profil <<include>> Gerer
Contacter le WebMaster
S'inscrire
<<include>>
Gérer le profil
<<include>>
Gerer les évenements
<<extend>>
Supprimer évenement
<<extend>>
<<extend>>
Ajouter évenement
envoyer évenement
<<include>>
Gérer les étudiant
Gérer les documents administratifs
Gérer le transport
<<extend>>
<<extend>>
<<include>>
Gérer le personnel
<<include>>
gestion des
vacation
Gestion du programme
Gestion financiaire
<<extend>> <<extend>>
<<include>>
S'authentifier
Gestion des salles
Consulter messagerie
<<include>>
participer au forum
<<include>>
Entrer au FAC
<<include>>
Répondre à des question
Consulter
<<extend>>
<<extend>>
Entrer au wiki
<<include>>
modifier Topic
Ajouter Topic
<<extend>>
<<extend>>
Regarder Actualité et
<<include>>
publication
Consulter
Consulter les publication
Actualité
<<extend>> <<extend>>

Personnel administratif