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

(1)

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

12 janvier 2010

(2)

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 ... 14

IV. Analyse des besoins ... 16

IV.A. Interview avec des acteurs ... 16

IV.B. Use case ... 16

Diagramme ... 16

Use Case Scénarii ... 17

IV.C. Diagramme de séquence ... 23

IV .C.1 Afficher un agenda ... 23

IV .C.2 Création d’un agenda ... 24

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

V. Solutions possibles ... 25

V.A. Améliorer Horde (plug‐in) ... 25

V.B. Créer une autre interface ... 26

V.C. Utiliser Zimbra (payant) ... 26

VI. Analyse des contraintes ... 29

VI.A. Plateformes utilisées ... 29

VI.B. Analyse des coûts ... 30

VII. Analyse de faisabilité ... 31

VII.A. Les risques ... 31

VII.B. Compétence technique de l’équipe ... 31

VII.C. Temps ... 31

VII.D. Faisabilité par rapport au coût ... 32

VIII. Annexes ... 32

VIII.A. Bibliographie ... 32

VIII.C. Glossaire ... 33

Annexe 1 – myFunambol Screenshot ... 34

(3)

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.

(4)

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.

(5)

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.

(6)

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).

(7)

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).

(8)

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).

(9)

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).

(10)

10 III.C.1.c. Horde

Horde est un Framework¹ libre² en PHP³. Horde propose une solution collaborative complète grâce à ces nombreux modules comme IMP⁴ 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

4IMP pour Internet Messaging Program est un client Webmail pour IMAP utilisé dans Horde

(11)

11 III.C.1.d. Funambol

D’après le site officiel (http://www.funambol.com) Funambol est un serveur de synchronisation de données pour mobile qui fournis des fonctionnalités tel que le push e‐mail ¹ et la PIM Synchronisation². Le push email 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³/IMAP⁴. 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é⁵.

 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

(12)

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 Email 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.

(13)

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.

(14)

Ce découp l’appella filtres, N

M permet simplifié mode m disponib

eci est la er en diffé ation courr Nag pour le

Maintenant d’accéder ée et adap minimaliste ble pour les

III.C.2.

III

page d’acc érentes pa ier, Kronoli s tâches et

III t la plupart

aux Web

ptée aux pe plus simple s ordinateur

User .C.2.a.

Figure

cueil une fo rtie. Chaqu th sous cel Mnemo po

.C.2.b.

t des appar mail. Il s’a etits écrans e mais auss rs).

Figure

14 r Interface

Horde

3 Horde en mo

ois qu’un ue partie e

le d’Agenda our les Note

Exemple reils mobile agit donc d s. Horde pr si plus rapid

e 4 Mode mini

ode "traditionn

utilisateur est un mo a, Turba po

s.

d'affichage es possède

de simplem ropose pou de à télécha

maliste d'Hord el"

est authen odule. On a

ur les conta

sur appareil nt un navig ment propo r les applic arger (ce m

e

ntifié. Elle aperçoit IM acts, INGO

l embarqué gateur inte oser une i cations mo mode est ég

peut se MP sous pour les

rnet qui nterface biles un alement

(15)

M gestion trouver

L amélior ainsi qu

Mais les ap d’email, la a sur un log

Figure

L'ordinateu rant l'interfa ue l'ergonom

ppareils mo gestion de giciel spécia

e 5 IPod accueil

III r permet ace graphiq mie.

biles emba es contacts, alisé pour or

l boite

.C.2.c.

les même que (compte

Figu

15 rquent auss

… On y retr rdinateur.

Exemple es fonction

e tenu de la

ure 7 Microsoft

si des appli rouve en gé

d'affichage nnalités qu a plus grand

t Outlook 2007

ications spé énéral toute

Figure 6 IPo

sur ordinate ue les app

de place dis

écialisées te es les partie

od liste des mai

eur

pareils mob ponible sur

el que la es qu’on

ils

biles en r l'écran)

(16)

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

(17)

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 :

(18)

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.

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 :

(19)

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.

L'utilisateur possède des droits de lecture et d’écriture sur l’agenda à modifier.

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 :

L’événement a été créé dans l’agenda Besoins en IHM :

Une interface de modification Contraintes non fonctionnelles :

L’agenda n’existe pas

(20)

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.

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 :

L’agenda a été modifié Besoins en IHM :

L’Utilisateur ne possède pas les droits d’écriture

(21)

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.

L’utilisateur fait une demande de suppression Scénario nominal :

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 :

L’agenda a été modifié Besoins en IHM :

L’Utilisateur ne possède pas les droits d’écriture

(22)

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 :

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

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

` L’Utilisateur ne possède pas les droits.

(23)

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

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

(24)

24 IV .C.2 Création d’un agenda

IV .C.3 Création d’un évènement

(25)

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¹, 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.

(26)

26 V.B. Créer une autre interface

Si on choisit cette solution, il faudra que récupérer les informations de Horde pour les intégrer et une fois les modifications effectuées, les réintégrer à Horde. Aussi il sera possible de prendre une plus grande liberté en termes d’ergonomie, permettant ainsi le développement d’une interface client lourd et léger.

V.C. Utiliser Zimbra (payant)

Zimbra est un logiciel qui permet de « se simplifier la vie» en ce sens ou Zimbra est une suite d’application de messagerie et d’application de collaboration (agendas partagés par exemple). Cela permet une organisation des boites mails, des conversations, etc. Zimbra offre des services du type Messagerie Instantanée, les agendas partagés ainsi que le partage de documents soumis à des droits de lecture/écriture. Un des slogans Zimbra est « Any Place, Any Machine » ce qui montre également le fait que l’application est à la fois portable (Windows, Linux, Mac OSX). Il permet également la synchronisation avec plusieurs types de Smartphones BlackBerry, IPhone, Windows Mobile,…

L’outil « Zimbra Calendar » est un outil assez puissant. Il propose des fonctionnalités basiques d’un agenda tel qu’afficher l’agenda soit par jour, jour ouvrable, semaine, mois. Il propose également des agendas partagés différenciés de l’agenda personnel. Bien sûr le créateur de l’agenda peut organiser les droits des personnes concernées par l’agenda, tel que droit de modification, d’ajout, et de suppression. Cependant il est tout à fait possible de voir les agendas sur le même écran avec en plus des couleurs différentes pour chaque agendas (cf., figure 8). Il est possible d’afficher son agenda sur son mobile, soit en passant par la passerelle web Zimbra Desktop ou en synchronisant son appareil (via des fichiers iCal).

Figure 8: Vue de plusieurs agendas

(27)

27

Lorsque l’utilisateur souhaite organisé un évènement plutôt que d’envoyer un e‐mail à ses collaborateurs pour leur demander leurs emplois du temps, il est envisageable de voir directement les temps libres et occupés de ces personnes (cf., Figure 9)

Figure 9: Planning Libre/Occupé des personnes sélectionné

Bien que Zimbra soit payant il est proposé différents tarifs en ce qui concerne les différentes versions :

(28)

28

Il est également possible de retrouver toutes les fonctionnalités disponibles en fonction de la version :

(29)

29 VI. Analyse des contraintes

VI.A. Plateformes utilisées

Aujourd’hui, Il existe une multitude d’appareils offrant les mêmes services, cela implique des constructeurs différents et donc des manières de conception différentes. Pour éviter de se perdre dans toutes ces technologies, nous définissons nos plateformes :

Les mobiles :

 Nous utiliserons des Windows mobiles pour tous nos tests, dans un premier temps.

La cause de ce choix réside dans le fait que l’université dispose d’une flotte de ces téléphones qui sont utilisés par tous les responsables. Aussi, les codes sources de ces mobiles sont libres, ce qui nous permet de faire des économies.

 Il serait possible d’effectuer des tests sur des IPhones, dans un deuxième temps mais bien que les codes de ces téléphones soient « open Source », les constructeurs imposent d’acheter leur bibliothèque et leur kit de développement. Cette solution n’est pas donc privilégiée car elle coûte chères.

 Nous allons aussi, si tout marche bien, intégrer dans nos tests des PDA, l’objectif final étant que toute personne, ayant un mobile, puisse se connecter à l’agenda partagé.

Les fixes

 En ce qui concerne les ordinateurs fixes, nous ne donnons aucune recommandation.

Cependant, une interface devra être rajoutée pour facilité le travail des secrétaires et permettra une modification simultanée de plusieurs agendas lors de la création d’un événement.

(30)

30 VI.B. Analyse des coûts

Tout projet d’étude nécessite un certain budget pour le mener à bien. Ce budget peut être représenté sous forme d’argent ou de matériel. Dans cette partie nous allons essayer d’estimer les coûts.

Les mobiles

 Pour nos tests, nous avons reçu de la part de notre tuteur, un « Windows Mobile » de type « Smartphones/PDA HTC Touch HD ». Ce dernier est estimé à 380€.

 Au cas où nous utiliserons un « IPhone », le prix moyen pour un téléphone avec 8Go de mémoire tourne autour de 520€.

Les logiciels

 Si on utilise la solution « Zimbra Network Professional Edition », il faudrait souscrire à la version valable pendant un an. Cette version comporte 25 boites aux lettres et chacune des boites aux lettres coûte 26€. Cela nous fait un total de 650€ (source : http://www.commeo.fr/tarif_zimbra.php).

 Avec la solution « Funambol », il existe une version gratuite pour les développeurs.

Cette solution ne nous coûtera pas d’argent au moins jusqu’à la fin du développement de l’application.

 Les deux solutions, qui consistent à mettre en place une interface et de créer un plug‐in pour améliorer Horde, ne nous coûteront pas chères.

(31)

31 VII. Analyse de faisabilité

VII.A. Les risques

Tout projet comporte des risques. Dans notre cas, ces derniers seront : 1. Que le projet dépasse le budget prévisionnel

En effet, certaines solutions peuvent facilement faire grimper le budget, limité, de notre projet. Le risque est que l’université ne finance plus et que nous soyons obligés d’arrêter les recherches, ou de prendre une solution sans avenir pour au moins avancer dans le projet.

2. Ne pas réussir à synchroniser nos données

L’utilisation de « Funambol » par exemple fait partie des meilleurs, mais les constructeurs de

« Horde » n’ont pas prévu cette éventualité donc nous n’allons peut être pas l’utiliser.

3. Ne pas terminer notre projet

Jusqu’à présent, il n’est pas possible de dire avec certitude qu’elle sera la solution que nous allons implémenter. Toutes les solutions présentent aussi bien des avantages que des inconvénients. Donc il est possible qu’en mettant en place une d’entre elle qu’on s’aperçoive un moment donné qu’il va falloir l’abandonner au profit d’une autre.

VII.B. Compétence technique de l’équipe

Les membres d’un groupe de projet doivent avoir des compétences variées. Cette différence permet au groupe d’être plus fort. Nous allons vous présenter tour à tour les compétences techniques de chacun des membres du groupe.

 Arnauld SCHOEN, le responsable de la communication, dispose des compétences multiples dans les réseaux et la programmation.

 Safiatou FANNY, la rédactrice, possède aussi bien des compétences dans les techniques de rédaction qu’en réseau.

 Vincent BOUVIER, le webmaster, a des compétences variées dans les domaines que sont la programmation et la recherche documentaire.

 Renauld MAMBOUNDOU, le responsable, quand à lui, possède des connaissances dans les domaines que sont le réseau et le suivi de projet.

VII.C. Temps

Tout projet doit être mené dans des périodes de temps bien définies. Le notre ira jusqu’à la fin de l’année scolaire. Pendant tout le second semestre, nous ferons tout notre possible pour mettre en place une ou plusieurs des solutions citées plus haut.

(32)

32 VII.D. Faisabilité par rapport au coût

Les coûts de notre projet varient en fonction des solutions que nous allons choisir d’implémenter. Il est possible de réaliser tout notre travail en utilisant des outils qui ne nous demande pas trop de financement. Mais comme nous l’avons vu plus haut, certaines solutions envisagées peuvent empêcher la poursuite du projet. Dans tous les cas, il est possible de mener à bien cette mission.

VIII. Annexes

VIII.A. Bibliographie

 Site official de Horde: http://www.horde.org/

 David Buchmann, SyncML and its Java Implementation sync4j, September 2002, http://idkf.bogor.net/bio2/java‐docs/syncml‐david%20buchmann.pdf

 Site officiel de Funambol: http://www.funambol.com/

 Site officiel de Zimbra : http://www.zimbra.com/ ainsi que la vidéo de présentation : http://www.zimbra.com/demos/zimbra_tour/

 Site technet de Microsoft:

http://technet.microsoft.com/fr‐fr/library/bb124307%28EXCHG.65%29.aspx

(33)

33 VIII.C. Glossaire

F

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.

I

IMP pour Internet Messaging Program est un client Webmail pour IMAP utilisé dans

Horde

Internet Message Access Protocol (IMAP) est aussi un protocole de récupération de message, mais lui, les laisse sur le serveur.

L

Libre signifie qu’il est possible d’accéder au code source, de le modifier et de le redistribuer sous la même licence.

O

Open source : cf. Libre

P

PHP est un langage de programmation web

PIM Synchronisation est pour Personal Information Manager, donc PIM Synchronisation réfère à la synchronisation des contacts, agenda, etc.…

Plugin (aussi nommé module) est un logiciel qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités.

Post Office Protocol (POP)est un protocole qui permet de récupérer ses mails sur le serveur de messagerie

Push e‐mail est une méthode redirigeant les e‐mails arrivant sur un serveur directement jusqu'à un Smartphone.

(34)

34 Annexe 1 – myFunambol Screenshot