CAHIER DES CHARGES. Chef de Projet: Stéphane Igounet. Conseiller Technique: Arnaud Icard

Transcription

1 Vincent BOUVIER Arnaud SCHOEN Renauld MAMBOUNDOU Safiatou FANNY CAHIER DES CHARGES Chef de Projet: Stéphane Igounet Conseiller Technique: Arnaud Icard Responsable de Gestion de Projet : Corinne Fredouille, Sophie Nabitz 1 12 janvier 2010

2 Table des matières Table des matières... 2 Remerciements... 3 I. Introduction... 4 II. Présentation du projet... 5 II.A. Présentation globale... 5 II.B. Objectifs... 5 II.C. Définition des acteurs... 6 III. Etat de l art... 6 III.A. Définir un état de l art... 6 III.B. Sujet traité... 6 III.C. Analyse des possibilités techniques existantes... 7 III.C.1. Synchronisation... 7 III.C.2. User Interface IV. Analyse des besoins IV.A. Interview avec des acteurs IV.B. Use case Diagramme Use Case Scénarii IV.C. Diagramme de séquence IV.C.1 Afficher un agenda IV.C.2 Création d un agenda IV.C.3 Création d un évènement V. Solutions possibles V.A. Améliorer Horde (plug in) V.B. Créer une autre interface V.C. Utiliser Zimbra (payant) VI. Analyse des contraintes VI.A. Plateformes utilisées VI.B. Analyse des coûts VII. Analyse de faisabilité VII.A. Les risques VII.B. Compétence technique de l équipe VII.C. Temps VII.D. Faisabilité par rapport au coût VIII. Annexes VIII.A. Bibliographie VIII.C. Glossaire Annexe 1 myfunambol Screenshot

3 Remerciements Dans des projets, tel que projet d université il est possible de dénombrer un bon nombre d intervenant en dehors des personnes réalisant le projet lui même (l équipe étudiant). Dans un premier temps nous souhaitons remercier M. Stéphane Igounet qui a su se montrer présent lorsque nous avions besoins de lui même si son emploi du temps est plutôt chargé. Nous voulons également remercier M. Arnaud Icard, qui nous a assistés lorsque M. Stéphane Igounet n était pas en mesure d être présent. Pour terminer nous remercions Mme Sophie Nabitz ainsi que Corinne Fredouille pour leur implication dans la suivie de ce projet, et la compréhension dont elles ont fait preuve lorsque nous avons eu des problèmes. 3

4 I. Introduction Chaque année, les étudiants de master Informatique du CERI d Avignon sont en charge d un projet tutoré qui dure toute l année. Le premier semestre est dévolu à la rédaction du cahier des charges et de la documentation préparatoire quant au second semestre lui est consacré à la réalisation de l application. L écriture du cahier des charges est l étape décisive dans la réalisation d un projet. Elle permet de celer le contrat entre les deux parties, le client (la maitrise d ouvrage) et le prestataire (la maitrise d œuvre). La première partie du cahier des charges est consacrée à la présentation du projet. Il intègre également l état de l art qui permet de répertorier et détailler les différentes technologies existantes en relation avec le projet. Lors de l écriture du cahier des charges il est primordiale de prendre en compte le système déjà en place chez le client de manière à cerner le mieux possible les changements à effectuer par le biais de l analyse fonctionnel de l existant suivit de l analyse des besoins. Dans le but de faire ressortir les solutions possibles, une analyse des contraintes ainsi qu une étude de faisabilité sera menée. Nous terminerons le cahier des charges en montrant l organisation des différents tests qui seront effectués. 4

5 II. Présentation du projet II.A. Présentation globale Ce projet, sous la direction du CRI, doit permettre d améliorer la synchronisation des agendas du personnel aussi bien administratif qu enseignant, ainsi que les étudiants de l université d Avignon. Le personnel administratif comprend entre autre le bureau de la Présidence avec leurs secrétaires, ainsi que le CRI. Ce bureau possède une flotte mobile (la plupart sous Windows mobile) et une flotte fixe affectée aux secrétaires de direction. La problématique des agendas partagés réside dans l accès simultané en lecture et / ou écriture de nombreux agendas aussi bien personnel que professionnel. Notons également, qu une des difficultés de ce projet est de gérer le multi plateformes compliquant ainsi la synchronisation des données. II.B. Objectifs Le but de ce projet est de développer des interfaces web dédié à la gestion (lecture / écriture) de nos agendas sur l ENT de l Université et sur les téléphones mobiles. Les agendas partagés de l Université d Avignon sont actuellement basées sur Horde et SyncML. Les interfaces proposées par défaut manque de fonctionnalité. Il faut donc améliorer cette interface (par exemple ajouter des couleurs) pour la rendre plus simple et ergonomique. Cet ajout pourrait se faire par le biais d une nouvelle interface web, ou d un plug in par exemple. Cette interface, plus fonctionnelle pour les secrétaires leurs simplifiera la tâche dans les prises de rendez vous entre plusieurs acteurs. En ce qui concerne la navigation sur appareil mobile (téléphone portable, Smartphones, PDA,...), un client léger sera mis en place et doit offrir une ergonomie très simple afin de permettre l'affichage d'agenda de manière simultanée. Cette interface doit offrir un mode non connecté pour permettre à l'utilisateur de consulter son agenda et cela même dans une zone non couverte. Il faut également prévoir une authentification par LDAP (Lightweight Directory Access Protocol). La solution ainsi obtenue profitera dans un premier temps au personnel et pourra être étendu aux étudiants. 5

6 II.C. Définition des acteurs Les acteurs de ce projet se séparent en trois parties le client, la maitrise d ouvrage (MOA) et la maitrise d œuvre (MOE) : Le client comprend le Bureau de la Présidence et les secrétaires associées. La MOA, dans le cas présent, est le CRI ou, Centre de Ressources Informatique de l Université d Avignon. Celui ci est représenté en les personnes de M. Thierry Spriet, M. Stéphane Igounet et M. Arnaud Icard. Et enfin la MOE qui se compose de Mlle Fanny Safiatou, M. Arnaud Schoen, M. Vincent Bouvier et M. Renauld Mamboundou. III. Etat de l art III.A. Définir un état de l art Tous projets quelques qu il soit se réfère à plusieurs types de documentations détaillées afin de les mener jusqu'à la fin en évitant le plus d obstacles possibles. Cela permet entre autre de pouvoir respecter les contraintes technico monétaire fonctionnelles. Il peut être intéressant, mais pas obligatoire, de faire ce que l on appelle un état de l art. La réalisation de ce livrable se fait en tant que acte préliminaire à tout travail scientifique, tant au niveau de la recherche que de l applicatif. Il doit recenser les avancées scientifiques ou techniques sur le domaine sur lequel on s apprête à travailler. III.B. Sujet traité Cet état de l art montre les problèmes et possible solutions de la synchronisation entres mobiles et ordinateurs en s appuyant sur un exemple de serveur de calendrier (Horde Kronolith). 6

7 III.C. Analyse des possibilités techniques existantes III.C.1. Synchronisation La synchronisation est une étape essentielle dés le moment où des données sont dupliquées dans différents endroit, afin de s'assurer que toutes les copies contiennent les mêmes informations (cohérence). Il y a différentes manières de synchroniser. L'une des plus simples est celle appelée "Full Sync" ou synchronisation complète. Cette synchronisation n'est pas rapide car elle va mettre à jours toutes les entrées existantes même si aucune modification n'a été apportée. Il serait bien plus efficace de n'envoyer que les objets modifiés basé sur le principe du "dirty bit" coté client et de la date de modification coté serveur. Il arrive que des conflits se déclarent si un même fichier a été modifié des deux coté depuis la dernière session de synchronisation. Certains sont solvables automatiquement d'autre non, dans se cas l'utilisateur sera sollicité afin de définir laquelle des versions est correcte. III.C.1.a. Mobile De nos jours les téléphones mobiles n ont pas uniquement de la mémoire pour stocker les numéros de téléphone. En effet ils sont devenus de vrais assistants personnels et propose des fonctionnalités tel que la gestion d un agenda, la consultation les e mails, la navigation sur Internet, etc. Les données relatives aux agendas par exemples doivent être stockées dans des bases de données. Prenons le cas d une base de données d entreprise. Comme l appareil mobile n est pas toujours connecté au réseau d entreprise, il est nécessaire de garder une trace des différents événements sur le mobile. Ensuite des modifications peuvent être apportée tant du coté mobile que du coté réseau. C est pourquoi de manière périodique, les informations concernant les changements sont échangées : c est ce qu on appelle la synchronisation de données. Actuellement les fabricants d appareil mobile utilise leurs propres protocoles de synchronisation et de là vient un grand manque d interopérabilité. De ce fait, des problèmes de flexibilité et d utilisation de certains outils de synchronisation sont insatisfaisants. C est pourquoi on utilise ce qu on appelle «connecteur». Un connecteur est une extension d un serveur assurant la synchronisation d un certains type de données. En d autre terme le connecteur joue le rôle d interface qui se place entre l outil de synchronisation et l appareil à synchroniser (i.e., figure 1 : Schéma de synchronisation utilisant un connecteur). 7

8 Figure 1 Schéma de synchronisation III.C.1.b. SyncML SyncML est un protocole de synchronisation de données. La «Synchronisation Markup Language» a été entreprise par les plus grandes compagnies de téléphone mobile, d'information et technologie pour finalement définir une méthode "standard" de synchronisation de données entre appareil mobile et fixe. Dans le domaine professionnel il est très important de maintenir une cohérence des données entre le serveur d'une part et le client d autre part. Le concept de SyncML comme dit précédemment, a vraiment été pensé pour les appareils mobiles et donc a été soumis à des spécifications strictes: Opérer de manière efficace sur un réseau filaire ou sans fil Être compatible avec plusieurs protocoles de transport Accepter l'accès aux données de plusieurs applications Prendre en compte la limitation des ressources des appareils mobiles Être compatible avec la technologie existante du Web et de l'internet Être compatible avec une large gamme d'appareils. Le protocole de synchronisation SyncML utilise les mêmes approches qu'une application client serveur basique, à l'exception d'une chose: le serveur peu aussi initier une communication (cf. Figure 2). 8

9 Figure 2: Flux de données initié par le serveur pour le client Ce schéma peut bien entendu être simplifié afin d'optimiser le nombre de requête. Par exemple le client peut envoyer les modifications effectuées en même temps que l'initialisation. Dans ce cas si les informations d'authentification (credentials) sont acceptées par le serveur, alors celui ci dispose des informations à mettre à jour et peut ainsi les renvoyer directement au client. Afin de permettre un échange plus rapide sur un protocole sans fil par exemple, une nouvelle définition est apparue: WBXML (Wap Binary XML). WBXML est une forme compressé de XML où les balises n existent plus pour laisser place à un code. Cela permet de réduire considérablement la taille d'un message XML. SyncML peut être utilisé sur différentes couches de transport tel que HTTP(S), WSP (Wireless Session Protocol) ou OBEX (infrarouge, Bluetooth, etc.). Il existe deux grandes implémentations qui continue d'être maintenue: libsyncml (dernière maintenance en date 04/06/2009) qui est une librairie C++ et également sync4j qui elle est une librairie Java développée par Funambol (cf., III.C.1.d). 9

10 III.C.1.c. Horde Horde est un Framework 1 libre 2 en PHP 3. Horde propose une solution collaborative complète grâce à ces nombreux modules comme IMP 4 pour le Webmail, Kronolith pour l'agenda ou Turba pour les contacts. Il est possible de configurer ces modules afin qu ils interagissent ensemble. On peut également l interfacer avec le système d exploitation via le LDAP qui permet la création automatique des comptes ainsi que l utilisation de WebService pour le développement d'applications (administration / utilisateurs). Dans Horde, il est possible de créer des groupes publics qui peuvent être utilisés dans tous les modules d Horde. Les données d Horde peuvent être partagées à des utilisateurs ou aux groupes en lecture seule, en écriture ou en délégation totale. Il est possible d afficher les agendas publics des membres mais les agendas de groupes n existent pas. Pour synchroniser les données de manière synchrone Horde utilise le standards ical et pour le mode asynchrone il emploie SyncML via un connecteur. Il est possible d importer et d exporter les données au format ICS. 1 Un Framework est un ensemble de bibliothèque, d outils et de conventions de développement d application. Il fournit les blocs de base et les méthodes permettant un développement et une maintenance aisés. 2 Open source ou libre signifie qu il est possible d accéder au code source, de le modifier et de le redistribuer sous la même licence. 3 Le PHP est un langage de programmation web 4 IMP pour Internet Messaging Program est un client Webmail pour IMAP utilisé dans Horde 10

11 III.C.1.d. Funambol D après le site officiel ( Funambol est un serveur de synchronisation de données pour mobile qui fournis des fonctionnalités tel que le push e mail 1 et la PIM Synchronisation 2. Le push est compatible avec les technologies Windows Mobile, BlackBerries et SyncML et peut récupérer les e mails de serveur tel que Yahoo! Mail, Gmail, AOL Mail, et autres serveurs utilisant les protocoles POP 3 /IMAP 4. Quant aux données PIM il est possible d effectuer une synchronisation aves les appareils mobiles compatible SyncML ou encore Outlook, Windows Mobile (Pocket PC ou Smartphones), Blackberry, Palm ou encore IPod/IPhone. Il existe 2 versions de Funambol : une Open Source (Community Edition) et une commerciale (Carrier Edition). La Community Edition comprend : Un serveur de synchronisation des données Linux et Windows. Les clients pour mobile Un connecteur e mail compatible avec les protocoles POP et IMAP Des outils d administration Un kit de développement et d interface Une documentation Les caractéristiques suivantes sont celles proposées en plus dans la Carrier Edition qui: Inclus un grand panel de fonctionnalités permettant le déploiement étendu. Par exemple cela inclus un portail qui automatise la configuration sans fil des appareils mobiles. Est certifiée sur une infrastructure commerciale, telle qu un système de base de données relationnel, et à ce titre, permet d être déployée dans un environnement de haute disponibilité 5. Est couvert par un accord commercial qui permet au client rendre le code qu il a développé privé. Une application web appelée myfunambol (cf., Annexe 1 myfunambol) permet de voir et manipuler les données PIM en ligne. Au moment de l inscription, il est demandé toutes les informations personnelles classiques (nom, prénom, nom d utilisateur, mot de passe, ) ainsi que le modèle de téléphone portable et le numéro de téléphone. Ceci permet 1 Le push e mail est une méthode redirigeant les e mails arrivant sur un serveur directement jusqu'à un Smartphone. 2 PIM est pour Personal Information Manager, donc PIM Synchronisation réfère à la synchronisation des contacts, agenda, etc. 3 Post Office Protocol (POP) est un protocole qui permet de récupérer ses mails sur le serveur de messagerie 4 Internet Message Acces Protocol (IMAP) est aussi un protocole de récupération de message, mais lui, les laisse sur le serveur. 5 Plugin (aussi nommé module) est un logiciel qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités 11

12 entre autre de fournir à l utilisateur un logiciel compatible à installer sur son appareil. Certaines fonctionnalités cependant ne sont pas disponible avec certains appareil, par exemple, il n est pas encore possible de synchroniser Funambol avec l agenda utilisé sur IPhone/IPod Touch generation 2. III.C.1.e. Active Sync ActiveSync Exchange est le protocole propriétaire de synchronisation développé par Microsoft en 1996 (actuellement nous sommes en version 4.5). Ce protocole est compatible avec les périphériques portables ou les SmartPhone utilisant le système d'exploitation Windows Mobile, ou Windows CE et les périphériques compatible telle que les plateforme Symbian, IPhone v2+ et Androïd v2+. Il permet à un appareil mobile d'être synchronisé avec un PC de bureau ou avec un serveur hébergeant FirstClass Collaboration Suite, Microsoft Exchange Server, PostPath and Collaboration Server, Kerio MailServer, Zimbra ou Z Push. Seules les gestionnaires d'informations personnelles (courriers électroniques, calendriers, contacts, tâches, notes) peuvent être synchronisés avec le serveur Exchange. Il permet aussi le transfert de ficher manuel. ActiveSync Exchange est téléchargeable gratuitement depuis le Centre de téléchargement de Microsoft. L'assistance est en général fournie par le fabricant du mobile (cout variable) ou par Microsoft au cout de 72 par demande. 12

13 Communication ActiveSync Exchange entre client et serveur Les étapes suivantes se produisent pour toutes les commandes que le client envoie au serveur : 1. Le client crée une requête et l'envoie au serveur de synchronisation en tant que POST HTTPS. 2. Le serveur de synchronisation traite la requête, en communiquant avec le serveur principal Exchange pour accéder aux données PIM de l'utilisateur. 3. Le serveur de synchronisation crée une réponse et l'envoie au client en tant que réponse POST HTTPS. 4. Le client traite la réponse et, le cas échéant, met à jour les données PIM locales. Les étapes suivantes se produisent lorsque le client envoie une commande Sync : 1. Le client identifie toutes les modifications effectuées dans les données PIM locales depuis la dernière synchronisation. 2. Le client crée une commande Sync contenant ces modifications. 3. Le client envoie la commande au serveur de synchronisation en tant que POST HTTPS. 4. Le serveur de synchronisation identifie les modifications apportées aux données sur le serveur depuis la dernière synchronisation, en communiquant avec le serveur principal Exchange pour accéder aux données de l'utilisateur. 5. Le serveur de synchronisation résout tous les conflits éventuels entre les modifications apportées aux éléments sur le client et sur le serveur. 6. Le serveur de synchronisation crée une réponse contenant les modifications du serveur à répliquer sur le client. 7. Le serveur de synchronisation envoie la réponse en tant que réponse POST HTTPS. 8. Le client traite la réponse et met à jour les données PIM locales. 13

14 III.C.2. III.C.2.a. User Interface Horde Figure 3 Horde en mode "traditionnel" Ceci est la page d accueil une fois qu un utilisateur est authentifié. Elle peut se découper en différentes partie. Chaque partie est un module. On aperçoit IMP sous l appellation courrier, Kronolith sous celle d Agenda, Turba pour les contacts, INGO pour les filtres, Nag pour les tâches et Mnemo pour les Notes. III.C.2.b. Exemple d'affichage sur appareil embarqué Maintenantt la plupart des appareils mobiles possèdent un navigateur internet qui permet d accéder aux Webmail. Il s agit donc de simplement proposer une interface simplifiée et adaptée aux petits écrans. Horde propose pour les applications mobiles un mode minimaliste plus simple mais aussi plus rapide à télécharger (ce mode est également disponible pour les ordinateurs). Figure 4 Mode minimaliste d'horde 14

15 Mais les appareils mobiles embarquent aussi des applications spécialisées tel que la gestion d , la gestion des contacts, On y retrouve en général toutes les parties qu on trouvera sur un logiciel spécialisé pour ordinateur. Figure 5 IPod accueil boite III.C.2.c. Figure 6 IPod liste des mails Exemple d'affichage sur ordinateur L'ordinateur permet les mêmes fonctionnalités que les appareils mobiles en améliorant l'interface graphique (compte tenu de la plus grande place disponible sur l'écran) ainsi que l'ergonomie. Figure 7 Microsoft Outlook

16 IV. Analyse des besoins IV.A. Interview avec des acteurs Dans le cadre de l'analyse des besoins, il est important de se reporter aux utilisateurs finaux afin de mieux cerner leurs besoins pour l'évolution de l'application. M. Stéphane Igounet a bien voulu se porter volontaire pour répondre à l'interview suivante. 1. A quelle fréquence utilisez l agenda? L agenda est utilisé 10 à 20 fois par jour. Dès qu'il sort ou revient dans son bureau il exécute une synchronisation. Il indique qu'il n'utilise pas la fonction push car sinon il n'aurait pas assez de batterie pour la journée. 2. Comment trouvez vous l agenda qui est proposé par l université? Il trouve que les agendas fonctionnent à "l'envers". Actuellement tout est public sauf ceux qu'on indique privé. Il souhaiterait avoir le système inverse. 3. S il fallait modifier des fonctionnalités de l agenda, lesquelles choisiriez vous? Il souhaiterait pouvoir synchroniser des fichiers en plus de ce qui existe déjà (contact, mail, agenda, note ) 4. Avez vous des suggestions par rapport à la solution citée précédemment? Il souhaite avoir la possibilité de revenir en arrière si jamais il y a un problème sans pour autant tout recommencer au début. Il souhaite également ne pas avoir à s'authentifier à chaque fois sur les appareils mobiles. IV.B. Use case Diagramme 16

17 Use Case Scénarii Case 1 : Titre du cas d'utilisation : Afficher un agenda Résumé du cas d'utilisation : Partie permettant à l Utilisateur d afficher un agenda à l écran. Acteurs qui participent au ca d'utilisation : L utilisateur Pré conditions à l'exécution du cas d'utilisation : L'utilisateur possède des droits de lecture et sur l agenda sélectionné. Le système est accessible. Déclencheur du cas d'utilisation : L utilisateur sélectionne un agenda Scénario nominal : 1. L utilisateur sélectionne un agenda 2. L AP vérifie les droits de l Utilisateur 3. L AP récupère l agenda sélectionné par l Utilisateur 4. L AP affiche l agenda à l Utilisateur Scénarios alternatifs : 2.a. Si l Utilisateur ne possède pas les droits sur l agenda 2.a.1. L AP informe l Utilisateur de ses droits Post conditions : L agenda s affiche à l écran Besoins en IHM : Un ordinateur avec ou sans connexion internet Un téléphone mobile avec connexion internet Un PDA Contraintes non fonctionnelles : 17

18 Case 2: Titre du cas d'utilisation : Créer un agenda Résumé du cas d'utilisation : Étape permettant à un utilisateur de créer un agenda. Acteurs qui participent au ca d'utilisation : L utilisateur Pré conditions à l'exécution du cas d'utilisation : L'utilisateur possède des droits d écriture sur l agenda sélectionné. L agenda est accessible Déclencheur du cas d'utilisation : L utilisateur valide la saisie de ses informations personnelles Scénario nominal : 1. L utilisateur saisie ses informations personnelles 2. L Utilisateur valide la saisie des ses informations personnelles 3. L AP récupère les informations de l Utilisateur 4. L AP vérifie les informations de l Utilisateur 5. L AP enregistre les informations de l Utilisateur 6. L AP crée l agenda de l Utilisateur 7. L AP renvoie à l Utilisateur ses identifiants Scénarios alternatifs : 4.a. Si les informations entrées existent déjà 4.a.1. L AP informe l Utilisateur de l existence de l agenda 4.a.2. L AP demande à l'utilisateur de saisir ses identifiants pour l envoi d un mail de rappel. 4.a.3. envoie du message de rappel Post conditions : L agenda a été crée Besoins en IHM : Un ordinateur avec ou sans connexion internet Un téléphone mobile avec connexion internet Un PDA 18

19 Case 3: Titre du cas d'utilisation : Créer un événement Résumé du cas d'utilisation : Étape permettant à l Utilisateur de créer un événement dans un agenda existant. Acteurs qui participent au ca d'utilisation : L utilisateur Pré conditions à l'exécution du cas d'utilisation : L'utilisateur possède des droits de lecture et d écriture sur l agenda à modifier. L agenda est accessible Déclencheur du cas d'utilisation : L utilisateur fait une demande de création d événement Scénario nominal : 1. L Utilisateur affiche un agenda 2. L Utilisateur fait une demande de création d événement 3. L AP présente l interface de modification à l Utilisateur 4. L Utilisateur modifie et valide sa saisie 5. L AP ajoute cet événement dans l agenda 6. L AP envoie une notification de modification à l Utilisateur Scénarios alternatifs : Post conditions : L événement a été créé dans l agenda Besoins en IHM : Un ordinateur avec ou sans connexion internet Un téléphone mobile avec connexion internet Un PDA Une interface de modification Contraintes non fonctionnelles : L agenda n existe pas 19

20 Case 4 : Titre du cas d'utilisation : Modifier un agenda Résumé du cas d'utilisation : Étape permettant à l Utilisateur de modifier un agenda existant. Acteurs qui participent au ca d'utilisation : L utilisateur Pré conditions à l'exécution du cas d'utilisation : L'utilisateur possède des droits de lecture et d écriture sur l agenda à modifier. L agenda est accessible Déclencheur du cas d'utilisation : L utilisateur valide la prise en compte des modifications Scénario nominal : 1. L Utilisateur affiche un agenda 2. L Utilisateur modifie l agenda 3. L Utilisateur valide la prise en compte des modifications 4. L AP récupère les modifications 5. L AP applique les modifications sur l agenda 6. L AP envoie une notification de modification Scénarios alternatifs : Post conditions : L agenda a été modifié Besoins en IHM : Un ordinateur avec ou sans connexion internet Un téléphone mobile avec connexion internet Un PDA Contraintes non fonctionnelles : L Utilisateur ne possède pas les droits d écriture 20

21 Case 5: Titre du cas d'utilisation : Supprimer un agenda Résumé du cas d'utilisation : Étape permettant à l Utilisateur de supprimer un agenda existant. Acteurs qui participent au ca d'utilisation : L utilisateur Pré conditions à l'exécution du cas d'utilisation : L'utilisateur possède des droits de lecture et d écriture sur l agenda à modifier. L agenda est accessible Déclencheur du cas d'utilisation : L utilisateur fait une demande de suppression Scénario nominal : 1. L Utilisateur affiche un agenda 2. L Utilisateur fait une demande de suppression 3. L AP vérifie la disponibilité de l agenda 4. L AP envoie un message d avertissement et demande une confirmation 5. L Utilisateur confirme la suppression 6. L AP supprime l agenda Scénarios alternatifs : Post conditions : L agenda a été modifié Besoins en IHM : Un ordinateur avec ou sans connexion internet Un téléphone mobile avec connexion internet Un PDA Contraintes non fonctionnelles : L Utilisateur ne possède pas les droits d écriture 21

22 Case 6: Titre du cas d'utilisation : S abonné à un agenda Résumé du cas d'utilisation : étape permettant à l Utilisateur de s abonner à un agenda. Il existe plusieurs type d agenda: Les agendas personnels Les agendas de cours Les agendas de groupe Acteurs qui participent au ca d'utilisation : L Utilisateur Pré conditions à l'exécution du cas d'utilisation : L'Utilisateur n est pas abonné à l agenda Déclencheur du cas d'utilisation : L Utilisateur valide l abonnement Scénario nominal : 1. L Utilisateur affiche un agenda 2. L Utilisateur fait une demande d abonnement à l agenda 3. L AP enregistre la demande 4. L AP vérifie la disponibilité de l agenda 5. L AP modifie l agenda 6. L AP envoie une notification d abonnement Scénarios alternatifs : 4.a si l agenda n est pas disponible (ex : nombre max de personnes atteint) 4.a.1 L AP envoie une notification Post conditions : L Utilisateur est abonné à l agenda. Besoins en IHM : Un ordinateur avec connexion au système Un téléphone mobile avec connexion internet Un PDA Contraintes non fonctionnelles : ` L Utilisateur ne possède pas les droits. 22

23 Case 7 : Titre du cas d'utilisation : Dépanner un agenda Résumé du cas d'utilisation : Étape permettant au manager d assurer la maintenance sur le système. Acteurs qui participent au ca d'utilisation : Le manager Pré conditions à l'exécution du cas d'utilisation : L'Agenda partagé ne fonctionne plus correctement. Déclencheur du cas d'utilisation : Constatation d arrêt de fonctionnement de l agenda Scénario nominal : Scénarios alternatifs : Post conditions : Besoins en IHM : Un ordinateur Contraintes non fonctionnelles : L Agenda n est pas en panne IV.C. Diagramme de séquence IV.C.1 Afficher un agenda 23

24 IV.C.2 Création d un agenda IV.C.3 Création d un évènement 24

25 V. Solutions possibles Après un brainstorming entre l'équipe projet et le client représenté par Monsieur Stéphane Igounet, il apparait deux sortes de solutions. D'un coté, l'amélioration de l'existant en ajoutant la/les parties manquantes et d'un autre coté l'achat et la mise en place d'une solution déjà prête à l'emploi. Chacune des solutions devra respecter la sécurité et la confidentialité des données. Du coté de l'amélioration de l'existant les différentes solutions partent de l'idée de fusions des différents agendas afin de voir les créneaux possibles. Une fois le choix du créneau, on créé l'événement sur tous les agendas. Il est aussi envisageable de créer une interface de gestion de groupe où chaque groupes a un agenda et où chacune des personnes du groupe peut le modifier de la même manière que le sien à condition d avoir les droits suffisant. Dans cette optique il peut également être rendu possible le fait de voir son agenda fusionné avec ceux des autres groupes auxquels l utilisateur appartient utilisant par exemple un système de coloration pour les distinguer. Afin de faciliter la prise de réunion entres plusieurs acteurs, un système de planning des temps libres et temps occupés permet de voir rapidement les créneaux disponibles pour tous les membres sélectionnés. V.A. Améliorer Horde (plug in) Si on décide d'améliorer directement Horde en ajoutant un plug in 1, il s'agira de respecter les principes de développement et d'intégration afin de simplifier l'adaptation et la maintenabilité du plug in. Il sera envisageable, si le plug in fonctionne correctement, de le proposer pour une intégration officielle. Il faudrait bien sûr, s'adapter à l'ergonomie générale d'horde afin de proposer des interfaces au moins pour les différentes vues utilisées en production par le client. 1 Plugin (aussi nommé module) est un logiciel qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités. 25