INGENIEUR EN SCIENCES INFORMATIQUES RAPPORT DE STAGE DE QUATRIEME ANNEE Analyse et conception pour la refonte d un logiciel de suivi de dossiers Stagiaire : Suzy PAETA (SI4) Maître de stage : Roger SCHIPORST ENTREPRISE : Métropole Nice Côte d Azur 24 juin 2013 30 août 2013 Ce stage s est déroulé au sein de la Métropole Nice Côte d Azur. Ma mission était de commencer la refonte d un logiciel de suivi de dossiers utilisé par des agents de la Métropole. Celle-ci étant dans une technologie qui commence à être obsolète et qui ne répond plus à tous leurs besoins, je me suis attelée à la tâche de l analyse de cette application pour faire la conception de la nouvelle. Pour cela, j ai pris contact avec les utilisateurs afin de rédiger un nouveau cahier des charges. La rédaction de celui-ci s est accompagnée de la réalisation de maquettes et de la conception de la nouvelle base de données.
Remerciements Je tiens à remercier toute l équipe du Service Développement de la Métropole pour son accueil et son aide durant ces deux mois de stage. Je remercie tout particulièrement, Jean-Luc Civilise (Chef du Service Développement - Direction des Systèmes d'information) et Roger Schiporst (Chef de projet - Direction des Systèmes d'information) pour leur encadrement et les conseils qu ils m ont prodigués. Je remercie aussi Annick Oliva (Spécialisée dans le développement Lotus Notes) pour sa collaboration au quotidien. 2
Table des matières Remerciements... 2 Introduction... 4 1. Description du travail proposé... 5 2. Description du travail réalisé... 5 2.1. Critique de l existant... 5 2.2. Communication avec les utilisateurs... 8 2.3. Maquettes... 10 2.4. Transfert des données... 12 2.5. Conception de la base de données... 13 2.6. Rédaction du cahier des charges... 14 2.7. Planning... 15 2.7.1. Planning prévisionnel... 15 2.7.2. Planning effectif... 15 Conclusion... 17 Bibliographie... 18 Annexes... 19 Abstract... 23 3
Introduction J ai effectué mon stage au sein de la Métropole de Nice Côte d Azur sur la période du 24 juin au 30 août 2013. J ai travaillé dans le Service Développement. Il existe d autres services informatiques, par exemple pour la gestion des serveurs, du réseau, des comptes utilisateurs et pour le dépannage matériel. L équipe du Service Développement est composée d un peu plus d une dizaine de personnes. Ce chiffre est variable en fonction des périodes par rapport au nombre de sous-traitants en fonction des besoins et des projets en cours. Dans mon bureau, j étais entourée de 3 développeurs dont Annick Oliva avec qui j ai collaboré et qui a suivi mon travail. Une partie des agents de la Métropole de Nice utilisent un logiciel de suivi de dossiers (son utilisation sera détaillée dans la suite du rapport). Malheureusement, cette application a plus de 10 ans et a été développée avec une vieille technologie : Lotus Notes 1. Elle sera abandonnée car vieillissante et ne permet pas la richesse et l ergonomie des applications web d aujourd hui. De plus, de nouveaux besoins sont apparus durant cette décennie et notamment le besoin de rendre plus simple son utilisation s est fait ressentir. La décision de refaire cette application a donc été prise. L objectif de mon stage est donc de commencer ce travail de refonte, c est-à-dire étudier l ancienne application afin de pouvoir concevoir la nouvelle dans une technologie plus récente tout en gardant ses principales fonctionnalités. Dans ce rapport, vous trouverez donc le cheminement de l analyse de l ancienne application et des nouveaux besoins des utilisateurs jusqu à la conception de la base de données et l établissement du cahier des charges en passant par la réalisation de maquettes. 1 «IBM Notes est un logiciel de travail collaboratif, utilisé dans des entreprises ou des administrations pour gérer les projets, les courriels et les échanges d'informations autour d'une base commune. À l'origine nommé Lotus Notes, il est rebaptisé IBM Notes depuis la version 9.» http://fr.wikipedia.org/wiki/ibm_lotus_notes#technologies_li.c3.a9es 4
1. Description du travail proposé Mon stage répond à un besoin interne de la Métropole. Au sein de la Métropole de Nice, il existe 8 pôles de proximité. Ces pôles de proximité sont un complément aux mairies et mairies annexes concernant les tâches administratives et ils permettent un rapprochement avec les usagers et leurs problèmes du quotidien. Ces pôles de proximité utilisent une application appelée «Territoire» (les pôles de proximité étaient autrefois appelés territoires) permettant un suivi de dossiers. Ces dossiers concernent les requêtes (exemple : problème de voirie devant sa maison) et les doléances des administrés d un pôle (citoyens d un pôle de proximité). Il a été donc été décidé de refaire l application de suivi de dossiers qui est actuellement en Lotus Notes vers une application en ASP.NET 2 /C# 3. C est une technologie qui est déjà beaucoup utilisée pour les applications et logiciels gérés par le service développement de la Métropole ce qui leur permettra de rester homogène dans les technologies qu ils utilisent et donc aussi de gagner du temps. L application devra être une application de type client léger, ici un navigateur web qui fonctionnera en intranet et non de type client lourd 4 comme elle l était précédemment. Ceci permettra un accès simple et rapide pour les utilisateurs et facilitera sa mise à jour. Pour pouvoir effectuer ce travail de refonte, il m a été confié la tâche de faire une critique de l existant, c est-à-dire d analyser l application existante afin d en comprendre son fonctionnement, puis d en dégager les points positifs et négatifs pour commencer à réfléchir à son évolution en proposant des solutions. Suite à cela, faire la conception de la nouvelle (et première) base de données relationnelles, puis la réalisation de maquettes tout en effectuant, en parallèle de ces tâches, le nouveau cahier des charges. Pour finir, il a été envisagé que je développe une des fonctionnalités de l application. Dans la suite du rapport et plus précisément dans le planning, vous pourrez constater que tout ne s est pas déroulé comme prévu notamment la dernière partie du stage. 2. Description du travail réalisé 2.1. Critique de l existant Dans un premier temps, j ai du analyser l application lourde développée avec Lotus Notes que les agents de la Métropole utilisent actuellement. 2 ASP.NET est un framework.net de développement pour des applications web. Il peut être associé à de l HTML, a du CSS et du JavaScript ou à des bibliothèques plutôt pour la partie graphique et à du C# pour le code. 3 C# est un langage de programmation orienté objet 4 Le terme «client lourd» (en anglais «fat client» ou «heavy client»), par opposition au client léger, désigne une application cliente graphique exécutée sur le système d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de traitement évoluées et peut posséder une interface graphique sophistiquée. http://www.commentcamarche.net/contents/219-reseaux-client-lourd#q=client+lourd&cur=2&url=%2f 5
J ai testé l application comme un utilisateur sans analyser le code afin de comprendre son fonctionnement global et d en dégager toutes les fonctionnalités disponibles puisque dans l ensemble les utilisateurs étaient satisfaits des principales fonctionnalités de l application. L application existante «Territoire» permet la gestion des suivis de Dossiers. Ces dossiers concernent les requêtes et les doléances des administrés d un pôle de proximité. Ceux-ci sont appelés Demandeurs dans cette application. Ces dossiers doivent être suivis afin de répondre aux demandeurs et suivre le déroulement de l affaire. Pour cela, un système d Actions existe afin de suivre toutes les étapes du déroulement de l affaire. Ces requêtes et doléances concernent souvent un Site précis (adresse ou établissement). Toutes ces informations sont saisies dans des formulaires (voir Figure 1). Une fois remplis, ces dossiers peuvent être consultés. Ils sont affichés en listes et peuvent être triées suivants différents critères ou bien être recherchés à l aide d une barre de recherche (voir Figure 2). Figure 1 : Exemple de formulaire de saisie/consultation d'un dossier 6
Figure 2 : Ancienne application, affichage des dossiers en cours triés par numéro Pour continuer l analyse, il m a fallu étudier le contenu de ces dossiers afin de savoir quelles données il était pertinent ou non de garder en fonction notamment de leur fréquence d utilisation. Pour pouvoir étudier ces données qui ne sont pas dans une base de données mais enregistrées dans des documents Lotus Notes, il a fallu les extraire dans des fichiers Excel grâce à des vues Lotus Notes. Il y avait donc 4 types de documents Lotus Notes (Dossier, Demandeur, Action et Site), ce qui fait 4 fichiers Excel par pôle de proximité et donc 32 fichiers en tout puisqu il y a 8 pôles de proximité. En analysant ces fichiers, je me suis rendu compte que certains champs des formulaires n étaient quasiment jamais remplis et que d autres étaient remplis mais pas avec des valeurs correspondantes à l intitulé du champ. De plus lors de l utilisation, j ai pu remarquer qu il y avait des problèmes d ergonomie au niveau du menu latéral gauche puis au niveau des fonctionnalités comme «ajouter une action» dont l accès n était pas très intuitif puisqu il fallait faire plusieurs manipulations. Enfin, pour pouvoir établir un nouveau cahier des charges, la rencontre avec les utilisateurs était une tâche primordiale. Il fallait donc les rencontrer notamment pour leur faire part des remarques que j ai précédemment citées. Il fallait également qu ils nous fassent part de leurs nouveaux besoins et remarques sur leur utilisation de l application. Dans ce but, Roger Schiporst, Annick Oliva et moi avons donc participé à plusieurs réunions avec les actuels et futurs utilisateurs de l application. 7
2.2. Communication avec les utilisateurs Après avoir analysé l application, il était nécessaire de rencontrer les utilisateurs afin d avoir d abord un premier retour sur leur utilisation (ce qu ils utilisent le plus et ce qu ils utilisent le moins) et puis aussi savoir s ils avaient déjà des avis sur l évolution de l application et connaître leurs nouveaux besoins. Plusieurs réunions ont donc été organisées durant ces deux mois. Le but de ces réunions était donc plus précisément d obtenir toutes les informations nécessaires afin d établir un nouveau cahier des charges qui convienne aux 8 pôles de proximité, soit environ une vingtaine d utilisateurs permanent. Ceci n a pas toujours été évident puisque tous les pôles n utilisaient pas l application de la même manière et n avaient pas les mêmes objectifs (statistiques, suivis des dossiers pour des assemblées générales etc.). De plus, il ne faut pas oublier que ces réunions se sont déroulées durant la période estivale, ce qui a entrainé une absence fréquente des utilisateurs. Des contraintes sont apparues pour définir les dates des réunions afin de faire en sorte qu au moins une personne par pôle soit présente. Il a donc fallu communiquer aussi par e-mail et établir des comptes rendus de réunion afin de tenir au courant les personnes qui étaient absentes. A mon arrivée à la Métropole de Nice, les comptes rendus des réunions précédentes m ont été fournis. Une première réunion avait déjà eu lieu le 2 mai afin d informer les utilisateurs de l obsolescence de l application et afin de commencer à discuter avec eux de son évolution ainsi que du budget obtenu par la Ville de Nice pour la réalisation de la nouvelle. Ensuite, deux réunions (6 mai et 6 juin) ont eu lieu seulement entre les utilisateurs dans le but notamment de revoir les valeurs des champs des formulaires de l application. Par exemple : revoir le contenu des listes déroulantes ou les libellés des cases à cocher, etc. Ensuite étant donné les ressources disponibles dans l équipe, le projet n a pas réellement avancé jusqu à mon arrivée. Puis les réunions se sont poursuivies, comme décrites ci-dessous, quelques jours après mon arrivée. Réunion du 01/07/2013 - Lieu : Pôle de proximité 5 (Locaux à Saint Roch) - Durée : 1h - Participants : 2 utilisateurs du pôle de proximité 5, Roger Schiporst et Annick Oliva - Objectifs : Une semaine après mon arrivée, une première réunion a donc été organisée afin d avoir une première approche avec les utilisateurs. De plus, il nous fallait éclaircir certains points détaillés dans les comptes rendus des réunions précédentes afin de pouvoir mieux cerner leur utilisation actuelle et leurs besoins. Réunion du 04/07/2013 - Lieu : Pôle de proximité 1 (Locaux à l Arénas) - Durée : 1h30 - Participants : les pôles de proximité 1, 2, 3, 7, 8, Roger et Annick - Objectifs : Commencer à travailler avec les utilisateurs sur les modifications à apporter à l application. Pour cela, nous avons travaillé sur une première ébauche de maquettes (simplement des images pour cette première fois). 8
Réunion du 11/07/2013 - Lieu : Pôle de proximité 1 (Locaux à l Arénas) - Durée : 2h30 - Participants : les pôles de proximité 1, 2, 3, 5, 6, 7, 8, Roger et Annick - Objectifs : Présentation des nouvelles maquettes faites dans la technologie dans laquelle l application sera développée (C#, ASP.NET) afin d avoir un résultat au plus proche de ce qui pourra être réalisé. Ces maquettes comportaient déjà les améliorations suites aux remarques des précédentes réunions. De plus, elles ont permis de poursuivre le travail de tri sur les données, ce que l on garde, supprime ou modifie. Réunion du 30/07/2013 - Lieu : Pôle de proximité 1 (Locaux à l Arénas) - Durée : 5h30 - Participants : les pôles de proximité 1, 3, 7, 8, Roger et Annick - Objectifs : Durant les deux semaines précédant cette réunion, plusieurs questions ont été posées et il était nécessaire d obtenir des réponses immédiates provenant des utilisateurs. De plus, nous leur avons proposé certaines solutions afin de simplifier au maximum la nouvelle application. Pour finir, nous avons repris une à une toutes les données afin de confirmer leur devenir dans l application puis connaître leur caractère obligatoire ou facultatif. Publication de la maquette le 19/08/2013 sur le serveur de test afin que les utilisateurs prennent le temps de tout revérifier. Pour cela, j ai rédigé un document détaillé (environ 3 pages) indiquant à l utilisateur tout ce qu il devait vérifier et en mettant en avant tous les changements par rapport à l ancienne application. Cette sollicitation a mené à plusieurs échanges d e-mails entre Roger, les utilisateurs et moi-même tout ceci dans le but de faire une validation finale lors de la dernière réunion de mon stage. Au cours de cette dernière semaine, j ai donc modifié les maquettes et le cahier des charges en prenant en compte toutes les dernières petites remarques reçues par e-mail. Réunion du 27/08/2013 - Lieu : Pôle de proximité 8 (Locaux à la Madeleine) - Durée : 2h - Participants : les pôles de proximité 1, 3, 5, 6, 7, 8, Roger - Objectifs : Montrer une version de la maquette qui est proche de la version finale et avoir la confirmation des utilisateurs que toutes leurs dernières remarques ont bien été prises en compte. Une prochaine réunion est prévue le 17 septembre avec les directeurs des pôles de proximité. L objectif de la réunion est de faire valider le cahier des charges dans le but de débloquer les fonds nécessaires et de pouvoir lancer le développement de la nouvelle application. Il faut aussi prendre en compte le fait qu avant chaque réunion avec les utilisateurs, nous faisions le point avec Roger, Annick et Jean-Luc afin de bien cibler l objectif de chacune d entre elles. Pour moi cela me permettait de préparer les bonnes maquettes et la liste des questions/problèmes à leur poser afin d avancer dans mon travail. Durant les réunions, j étais bien sûr toujours encadrée par mon maître de stage Roger Schiporst et parfois accompagnée de Annick Oliva. Mais c est bien moi qui menais la majeure partie de la discussion avec les utilisateurs. Après chaque réunion, je rédigeais aussi un compte rendu pour garder une trace de nos échanges. Tout cela prend du temps et n est pas négligeable par rapport aux autres tâches que j ai effectuées. 9
Cette partie de communication avec les utilisateurs a été une partie importante de mon stage. De plus, étant donné que mes supérieurs, collaborateurs et utilisateurs ont tous été en congé à un moment donné, j ai permis de faire le lien entre tous afin que personne ne perde le fil de notre projet et j ai aussi transmis le maximum d informations à chacun pour qu ils puissent poursuivre plus simplement ce travail après mon départ. 2.3. Maquettes Pour une meilleure compréhension et un meilleur dialogue avec les utilisateurs, il m a été demandé de réaliser des maquettes représentant la future application. Les maquettes sont un reflet du cahier des charges pour les utilisateurs. Elles permettent de montrer les fonctionnalités et les données qui seront présentent dans l application. Bien sûr, le cahier des charges est plus complet mais un aperçu visuel est souvent plus simple pour communiquer. Lors des réunions, les maquettes ont permis à l utilisateur de pouvoir se représenter la nouvelle application et suggérer les améliorations possibles. Pour nous, elles ont été utiles afin de pouvoir «trier» les données et les fonctionnalités à garder ou à supprimer. Pour chacune des données, il a fallu prendre une décision qui mette les 8 pôles de proximité en adéquation. Tout ceci a permis d affiner le cahier des charges au fur et à mesure. Au départ, les maquettes comportaient tout ce qui nous semblait pertinent de garder ou d ajouter en fonction de l analyse de l application que j avais faite précédemment. Au fur et à mesure, elles ont été affinées en fonction des demandes des utilisateurs et de ce qu il était possible de faire techniquement. Les maquettes ont été réalisées en ASP.NET, C#. C est un langage que je ne maitrisais pas réellement mais que j avais déjà utilisé au cours du dernier semestre et j ai donc pu, au bout de quelques heures, l utiliser comme je le voulais. De plus, j ai réellement progressé en demandant des conseils auprès de mes collègues de bureau qui ont l habitude d utiliser cette technologie. Concernant l ergonomie, j ai consulté deux personnes du service, Evelyne Saul et Mathieu Fraioli. D une part, ils m ont conseillé de regarder les applications qu ils avaient déjà développées puisque sur celles-ci ils avaient déjà réfléchi à des problèmes d ergonomie. Par exemple pour afficher le maximum d informations dans un tableau, il était utile de mettre des icônes plutôt que du texte pour certaines informations (voir sur la Figure 3, Statut, Alerte etc.) ou bien afficher des informations grâce à des info bulles (voir Figure 3, la Date de rappel s affiche quand la souris est sur l icône «cloche») ou encore un arbre qui se «développe» pour afficher plus d informations sur un dossier (voir Figure 3, quand on clique sur le bouton + dans la colonne Objet, les dernières actions du dossier s affiche en dessous) sans avoir à consulter complètement le dossier. 10
Figure 3 : Maquette représentant la page de recherche de dossiers. La partie haute correspond à la barre de recherche et la partie basse correspond à l'affichage des dossiers trouvés Ici, on ne peut pas se rendre compte que ces maquettes sont interactives mais lorsqu on clique sur le numéro de dossier 201307-01-04, l utilisateur ouvre le dossier et passe en mode consultation/modification (voir Figure 5 en annexe). Si on clique sur le lien créer un nouveau dossier, la page de création de dossier s ouvre (voir ci-dessous la Figure 4 ci-dessous). 11
Figure 4 : Maquette exemple de la page de création d'un dossier Sur la Figure 4 si l on clique sur un des boutons + vert, des pop-up s ouvrent afin d ajouter d avantages d informations au dossier. Voir Figure 6 en annexe, un pop-up qui permet d ajouter un lieu. Au total, j ai réalisé 7 pages différentes pour l application dont une réservée pour l administrateur. Celui-ci pourra faire des modifications dans l application en ajoutant par exemple des valeurs dans les listes déroulantes ou en consultant les dossiers de tous les pôles, ce que les autres utilisateurs n auront pas le droit de faire bien entendu. En regardant ces maquettes vous pouvez donc constater la différence avec l ancienne application. Celle-ci parait quand même beaucoup plus claire et simple d utilisation (lorsqu il est possible de tester son interactivité). 2.4. Transfert des données Durant ce stage, il ne fallait pas perdre de vue le fait que l application devait évoluer tout en étant capable de conserver tous les dossiers, demandeurs, etc. qui existaient déjà, sachant qu il y a environ 1500 dossiers créés par an et par pôle de proximité. 12
Avant de concevoir la nouvelle base de données, nous nous sommes rendus compte que le transfert de données de l ancienne application vers la nouvelle base de données serait difficile. Dans l application en Lotus Notes, les données n étaient pas stockées dans une base de données relationnelles mais dans des documents Lotus Notes, c est-à-dire que les formulaires étaient enregistrés entièrement (la partie graphique et les données). Il y avait 4 types de documents enregistrés : Dossiers, Sites, Demandeurs et Actions. Des identifiants étaient utilisés pour savoir quels demandeurs ou sites appartenaient à quel dossier, de même pour les actions. C est donc de cette manière qu il y avait des relations entre les différentes entités. Il a donc fallu savoir de quelle manière s y prendre pour récupérer ces données et garder les bonnes liaisons entres elles pour la nouvelle base de données. De plus, la question s est posée de savoir de quelle manière allait s effectuer le transfert des données, directement de Lotus Notes vers la base de données Oracle, en sachant qu il faudrait créer un script Lotus Notes et que peu de personnes pourraient le faire ou en faisant une extraction des données de Lotus Notes vers Excel puis de Excel vers la base de données Oracle ce qui serait une opération en deux temps. J avais commencé ce travail en collaboration avec Annick le premier mois malheureusement au cours du deuxième elle n a pas été présente pour qu on puisse continuer ce travail et qu elle puisse m aiguiller sur ce qu il était possible de faire en Lotus Notes puisqu elle s y connaissait très bien dans ce domaine. Elle poursuivra donc ce travail à son retour (après mon départ). 2.5. Conception de la base de données Grâce à l analyse de l application, j ai pu identifier les entités principales (Dossiers, Demandeurs, Contact, Sites etc.) de l application et les relations entre elles. Exemples de relation : un dossier peut avoir un demandeur principal et un demandeur secondaire, et il peut être situé seulement sur un site. Grâce aussi à l étude des fichiers Excel contenant l extraction des données comme décrit dans la partie 2.1 j ai pu rentrer dans les détails. J ai pu constater par exemple qu il y a plus d informations enregistrées pour le demandeur principal (nom, prénom, adresse, numéro de téléphone, etc.) que pour le demandeur secondaire (nom, prénom). A partir de ces informations là j ai pu commencer à dessiner un schéma simplifié de la base de données. Puis au fur et à mesure que l établissement du cahier des charges avançait au fil des réunions, la construction du schéma de la base de données évoluait. Dans la nouvelle application, il a été décidé qu il sera possible d avoir plusieurs demandeurs et non pas deux seulement et puis plusieurs sites et non pas un seul. Ceci est un exemple de la manière dont les liaisons entre les différentes entités ont évoluées et ont fait évoluer le schéma relationnel. Pour réaliser le schéma de la base de données, j ai utilisé le logiciel Microsoft Visio 2007 qui est utilisé dans l équipe et qui permet de générer un script SQL 5. Celui-ci peut être utilisé dans Oracle afin de créer automatiquement toutes les tables vides avec leurs champs et le type de chaque champ (identifiant numérique, texte, données numériques, images, documents, etc.). Cela permettra de gagner du temps au début du développement. 5 SQL (sigle de Structured Query Language, en français langage de requête structurée) est un langage informatique normalisé servant à effectuer des opérations sur des bases de données relationnelles. La partie langage de manipulation de données de SQL permet de rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de données relationnelles. http://fr.wikipedia.org/wiki/sql 13
2.6. Rédaction du cahier des charges Comme décrit précédemment dans ce rapport, le cahier des charges a été rédigé en parallèle des maquettes, de la conception de la base de données et des réunions. Le cahier des charges est la finalité de mon travail durant ce stage. Il contient une présentation générale de la nouvelle application. Ensuite il détaille toutes les fonctionnalités qui devront être développées. Celles-ci sont accompagnées de copies d écrans des maquettes pour les illustrer. Il contient le schéma de la base de données et aussi les valeurs des listes déroulantes (celles-ci ont été fournies par les utilisateurs). Il n est cependant pas complet. Une partie sur les définitions des rôles (administrateur, utilisateur avec des droits en lecture seulement ou écriture et lecture, etc.) sera complétée plus tard. Une autre partie concernant les contraintes légales de l application n a pas été rédigée. En effet nous attendions la réponse d une personne de la Métropole qui devait nous indiquer au bout de quel délai les informations personnelles sur les demandeurs ne pouvaient plus être conservées et ce, afin de respecter la réglementation de la CNIL 6. Puis concernant le transfert des données, il faut terminer de réfléchir à la meilleur solution (voir paragraphe 2.4). A ce moment, là elle pourra être ajoutée au cahier des charges. Pour avoir une idée de toutes les fonctionnalités de l application, vous pouvez voir en annexe (Figure 7) le sommaire du cahier des charges qui les liste toutes. 6 Commission nationale de l'informatique et des libertés 14
2.7. Planning 2.7.1. Planning prévisionnel Voici le planning qui m a donnée la semaine de mon arrivée : Semaines 1et 2 : Analyse et critique de l existant. Semaines 3 et 4 : Conception de la base de données. Semaine 5 : Réalisation des maquettes. Semaines 6 à 10 : Début du développement de l application en développant une des fonctionnalités. Je pense que lorsque ce planning a été effectué, il ne prenait pas assez en compte les rencontres avec les utilisateurs et la réelle rédaction du cahier des charges ne qui pourrait aboutir que lorsque le travail avec eux serait terminé. Le développement de l application ne pouvait donc pas commencer avant. 2.7.2. Planning effectif Semaine 1 : Analyse et critique de l existant. Semaine 2 : Analyse et critique de l existant avec en parallèle le commencement des maquettes (images pas encore en ASP.NET) pour les prochaines réunions. Déroulement effectif de la première réunion. Semaine 3 : Début des maquettes en ASP.NET et deuxième réunion. Semaine 4 : Amélioration des maquettes, début de réflexion sur la base de données et extraction, et analyse des fichiers Excel contenant les données. Semaine 5 : Poursuite des maquettes et réflexion sur le transfert des données (avec Annick). Semaine 6 : Grâce à toutes les informations que j ai pu recueillir au cours des premières semaines, j ai donc pu commencer à rédiger un cahier des charges bien rempli. J ai aussi poursuivi mon travail sur les maquettes. Semaine 7 : Fin de la conception de la base de données et validation par mes supérieurs et poursuite de la rédaction du cahier des charges. Semaine 8 : Poursuite des maquettes et rédaction d un guide pour les utilisateurs. Semaine 9 : Envoi du lien des maquettes pour que les utilisateurs puissent tester. Modification dès leurs premiers retours par e-mail. Semaine 10 : Finalisation du cahier des charges et préparation de la dernière réunion. Préparation du rendu de mon travail pour la poursuite du projet, c est-à-dire, le développement de l application. 15
La différence de planning est notamment dû au fait que mon travail évoluait en fonction des réunions. Elle est aussi due au fait que les maquettes sont devenues beaucoup plus importantes que prévu. Elles sont devenues interactives et très détaillées. Elles sont l aboutissement de nombreuses modifications afin d obtenir quelque chose de simple et d ergonomique à utiliser. Au total, la conception de la base de données n a pas dû prendre plus de temps que prévu mais seulement elle n a pas été réalisée de manière continue. L analyse et la critique de l existant a été assez rapide et je suis tout de même rentrée très rapidement dans le vif du sujet en rencontrant les utilisateurs. De plus, durant le stage, j ai appris que le développement allait être sous-traité et donc que je ne pourrais pas y contribuer. C est pour cela que l on m a demandé de faire un cahier des charges très précis, la conception de la base de données avec des commentaires très complet pour chaque champ et des maquettes très détaillées et interactives. Les personnes chargées du développement auront donc tout cela à leur disposition pour commencer rapidement. 16
Conclusion Au cours de ce stage, j ai pu mettre en œuvre des connaissances acquises tout au long des mes études notamment la partie analyse du besoin, la conception d une base de données, le développement en ASP.NET/C#, la rédaction d un cahier des charges et le travail d ergonomie sur des maquettes. Toutes ces connaissances ont été étoffées en les mettant en application et grâce à tous les conseils qui m ont été donnés. En revanche, j aurais bien aimé commencer la partie développement pour progresser un peu plus dans ce domaine, comme cela avait été prévu initialement. La difficulté principale de ce stage a été de devoir effectuer plusieurs tâches en parallèle plutôt que les unes après les autres mais cela permet aussi d apprendre à s organiser et à gérer son travail autrement. C est la succession de détails et de modifications du cahier des charges/maquettes à la demande des utilisateurs qui a fait que ce début de refonte du logiciel a été plus long que prévu. En revanche ce travail étant très détaillé, le développement en sera d autant plus rapide avec toutes ces informations à disposition. J ai beaucoup apprécié travailler en collaboration avec les personnes du service développement et aussi les utilisateurs avec qui j ai passé beaucoup de temps. Lors de la dernière réunion, les utilisateurs et Roger ont exprimé la satisfaction de mon écoute à leur égard pour répondre au mieux à leurs besoins, de mon travail en général et de notre collaboration sur ce projet. Je compte bien rester en contact avec l équipe pour suivre l évolution de l application. Je pense donc que ce stage a été enrichissant sur tous les plans, que ce soit technique, humain ou bien encore sur les tâches réalisées par un chef de projet. 17
Bibliographie http://www.nicecotedazur.org/ http://www.asp.net/ajaxlibrary/ajaxcontroltoolkitsamplesite/ http://office.microsoft.com/fr-fr/visio-help/creer-un-modele-de-base-de-donnees-egalement-appelediagramme-entite-relation-ha010115477.aspx http://msdn.microsoft.com/en-us/library/vstudio/kx37x362.aspx http://www.w3schools.com/aspnet/ 18
Annexes Description de la Métropole de Nice Côte d Azur La métropole Nice Côte d Azur est une structure intercommunale française, située dans le département des Alpes-Maritimes et la région Provence-Alpes-Côte d'azur, autour de la ville de Nice. Elle a été mise en place le 31 décembre 2011 et résulte de la fusion de la communauté urbaine Nice Côte d'azur(nca) avec trois communautés de communes des Alpes-Maritimes 2. Elle regroupe 45 communes et environ 545 000 habitants 3, sur un territoire d'environ1 400 km 24. Les communes concernées partagent un certain nombre de compétences. Il s'agit de la première métropole fondée en France 3. Son siège est situé à Nice. Mais il ne s'agit pas d'une véritable zone urbaine, puisque 80 % environ de son territoire est constitué de zones rurales ou montagnardes naturelles (forêts, alpages, haute montagne ). 19
Maquettes Figure 5 : Maquette représentant un exemple de consultation/modification d'un dossier de la nouvelle application 20
Figure 6 : Exemple de pop-up lorsque l'utilisateur veut ajouter un nouveau lieu pour le dossier qu'il consulte 21
Sommaire du cahier des charges Figure 7 : Sommaire du cahier des charges 22
Abstract My internship took place at the Métropole Nice Côte d Azur. The task that was given to me was to redesign a software used to monitor citizen s files filled by some agents of the Métropole. This software was developed with an old technology and some needs from the users had to be added. In consequence, I had to analyse the old application in order to design the new one. To do this, I had to communicate with the users to redact the specifications. The specifications were associated with mock-up and the design of the data base. 23