1 sur 14
Sommaire Sommaire! 1! I. Introduction! 3! II. Guide de lecture! 3! III. Concept de base! 3! IV. Organisation! 4! 1. Décomposition en tâches 4 2. Structure des équipes 6 V. Planification! 7! VI. Cycle de vie! 8! VII. Méthodes et outils! 9! 1. Méthodes 9 2. Outils 9 VIII. Documentation! 10! IX. Qualité! 11! X. Annexes! 11! XI. Glossaire! 12! XII. Références! 14! 2 sur 14
I. Introduction Ce document vise à décrire l'ensemble de la phase de développement de l application. En complément du cahier des charges et du cahier de recettes, il rend compte de la méthode, de l organisation et fait le lien entre exécution technique et attente du client. II. Guide de lecture Ce plan de développement est d abord destiné à notre hiérarchie mais peut tout a fait être suivie par des personnes externes. Les grandes parties sont indépendantes et peuvent être parcouru individuellement ou successivement. Un glossaire fourni permet de retrouver les définitions des mots techniques utilisés. III. Concept de base Le développement ce décompose en plusieurs phase : Création d'un module pour chaque domaine lié à l'application (Vélib s, métro, RER, Tramways, Gares ) Gestion du traitement des données Open Data. Création d'une interface ergonomique et intuitive. La suite du document présentera donc les différents aspects technique mais aussi l organisation temporelle et pratique. 3 sur 14
IV. Organisation 1. Décomposition en tâches L ensemble du planning, des tâches et attributions se trouvent dans l annexe jointe au document présent. A. Partie serveur: Création de l API vélib: il s agit de créer une API capable de récupérer les informations relatives aux stations Vélib s. Responsable Félix (10h), Testeur Brian(4h) Création de l API SNCF: il s agit de créer une API capable de récupérer les informations relatives aux gares SNCF. Responsable Félix(14h), Testeur Brian(4h) Création de l API RATP: il s agit de créer une API capable de récupérer les informations relatives aux stations RATP. Responsable Brian(20h), Testeur Félix(4h) Gestion des erreurs: Il s agit de pouvoir traiter les erreurs HTTP (décrites dans le cahier des recettes). Responsable Brian (10h), Testeur Félix (12h) Documentation: référencement de l API. Responsables Brian et Félix (20h), Testeur Selim Développeur suppléant: Boksic 4 sur 14
B. Partie application Recherche et création d images pour les vues. Responsable Boksic (3h), Testeur Selim Creations de vues (templates, Vélibs, métros, RER, bus, transilien, trams, noctiliens) Responsable Boksic (16h) Testeur Selim (8h) Générateur de requêtes: fonction s occupant d organiser des requêtes a l API serveur. Responsable Selim (14h), Testeur Boksic (8h) Analyseur de requêtes: fonction demandant et transmettant les requêtes du générateur aux vues. Responsable Selim (14h), Testeur Boksic (8h) Intégration de l ensemble de l application dans la map de l application mère. Responsables Selim et Boksic (15h), Testeur Brian (15h) Intégration des capteurs GPS des autres groupes Responsable Selim Testeur Boksic Documentation: référencement de l application, manuel d utilisateur Responsables Selim et Boksic (10h) Testeur Brian (5h) Développeur suppléant: Félix 5 sur 14
2. Structure des équipes Composés de quarte membres aux qualités diverses et complémentaires, il a été décidé de confier la direction du groupe de travail à chacun d entre nous en suivant une rotation définie par périodes et compétences. L équipe rend ellemême compte de son avancement et de son travail lors de réunion hebdomadaire à l encadrant associé (M. Nguyen). L équipe est composé de deux pôles de travail en interface, selon le schéma diviser pour régner. Les pôles sont organisés en binôme de compétences dont les membres développeurs vérifient tour à tour la validité de leurs travaux respectifs. A chaque étape importante, le travail d un binôme est alors testé conforme par l autre avant intégration. Pour des tâches communes ou de réflexions, les sousgroupes s effacent de manière flexible pour entretenir une puissance de travail et une dynamique supplémentaire et ponctuellement requise. La logique de l obtention et du traitement des informations du coté serveur est donc distincte et complémentaire du groupe s occupant de la partie client et de l intégration graphique (voir description de l architecture du cahier des charges). L équipe est donc repartie comme suit: Brian: Développeur API Serveur, testeur API Serveur et application Félix: Développeur API Serveur et application, testeur API Serveur Boksic: Développeur application et API Serveur, testeur application Selim: Développeur application, testeur application et API Serveur 6 sur 14
V. Planification Pour le 07.03.2014 L API Serveur doit être suffisamment avancé pour fournir les données requises à l application. Le template et des vues sont élaboré pour les premiers test. L analyseur et le générateur de requêtes sont dans un état de fonction basique Pour le 14.03.2014 L API Serveur est fonctionnel mais ne gère pas encore les exceptions/erreurs Le template ainsi que les vues sont dans un état finale. L analyseur et le générateur sont dans un état très avancé. Pour le 20.03.2014 L ensemble de l application et de l API serveur sont dans leurs états finaux. Pour le 24.03.2014 L ensemble de la documentation se trouve dans son état final. Livraison de l application. 7 sur 14
VI. Cycle de vie Il a été convenu d adopter un cycle de développement dit en «V» (voir sources et références), le but étant d élaborer un mode de fonctionnement rationnel, empirique et collaboratif comme explicité dans le schéma 2: Schéma 1 : cycle de développement en V Chaque élément de notre application est classé selon son état et sa finition au moyen de l échelle suivante: niveau 0: objet à concevoir niveau 1: objet en cours de développement (dev) niveau 2: objet en cours de test et de déploiement (testing/staging) niveau 3: objet fini et prêt à la livraison (production) En fonction de l état d un objet, il est intégrer à l une des applications suivantes: application / API niveau 0: développement fonctionnel (developping) application / API niveau 1: test logique/unitaire (testing) application / API niveau 2: test d intégrations (staging) application / API niveau 3: objet final livrable 8 sur 14
VII. Méthodes et outils 1. Méthodes L ensemble de notre application devra suivre le schéma de développement MVC (lire Modèle-Vue-Contrôleur) qui subdivise chaque fonction en ces trois entités: Données - Visuel - Logique. Assurant à l ensemble de notre code d être particulièrement agile, réutilisable, extensible et modifiable. 2. Outils Afin d obtenir le meilleur résultat possible et de simplifier le développement, nous avons choisis d utiliser l outil Phonegap / Cordova qui permet de transcrire du langage web en application Android. Afin de tester sur divers supports (affichage) nous avons opté pour Rippler une extension pour le navigateur Google Chrome. Outils technique: Eclipse, Phonegap / Cordova, Rippler (Chrome), console de débuguage chrome. Langage: HTML 5, Javascript (JQuery), CSS, Java, JSON Pour la partie serveur afin de répondre à nos critères de qualités, nous avons choisis la solutions du framework PHP Codeigniter. Outils technique: Eclispe, Codeigniter, Chrome, PHPMyAdmin Langage: PHP5, SQL, JSON, (GTFS format spécifique au transport, au besoin) 9 sur 14
VIII. Documentation L application est accompagné des documents: 1. Le cahier des charges 2. Le cahier des recettes 3. Le plan de développement (document présent) 4. Le manuel d utilisation 5. Le manuel d installation 6. Le plan de tests 7. La documentation interne du code Le manuel d utilisation permettra à l utilisateur d apprendre à se servir de l application. Il recensera l ensemble des fonctionnalités et permettra de s informer quant à leurs utilisation. Le manuel d installation permettra à l utilisateur, d implanté l application sur son système en suivant des étapes claires et précises. Le plan de test permettra de garantir l adéquation de l application avec le cahier des charges. La documentation interne du code se fera à la fois sur le code sources (commentaires, références aux wiki, annotations..) et sur un wiki dédié. Ces documents seront tous disponible sur la forge et au format papier. 10 sur 14
IX. Qualité Notre logiciel est conçu pour être particulièrement flexible, extensible au besoin et facilement intégrable. En effet, la programmation MVC (voir VII méthodes et outils), mais aussi la programmation par module (services) doit nous permettre d atteindre cet objectif. De plus, nous avons dégagé trois critères de validation de la qualité de notre application: La fluidité: il est essentiel à notre application de réagir rapidement aux requêtes envoyées. En effet, l'utilisateur désire pouvoir naviguer dans les différents menus de l'application sans pour autant devoir attendre trop longuement la réponse. La précision de l'information: notre application étant basée sur l'information en temps réel, il est nécessaire que les informations envoyées soient les plus proche possible de la réalité. Nous pensons sans cesse au futur de l application, dans ce sens, nous voulons pouvoir rendre très simple l ajout de nouveaux services mais aussi de fournir une documentation de qualité, claire et accessible. X. Annexes Plan de développement prévisionnel des tâches détaillés - joins à part 11 sur 14
XI. Glossaire Serveur: Un serveur informatique est un dispositif informatique matériel ou logiciel qui offre des services, à différents clients (source wikipedia) Déploiement (informatique - staging): Fait de mettre en place un nouveau système ou un nouveau logiciel (source: dictionnaire.phpmyvisites.net) Production, environnement de: sur lequel sont exécutés les programmes opérationnellement. (source: wikipedia) Base de données: est un conteneur informatique permettant de stocker - le plus souvent dans un même lieu - l'intégralité des informations en rapport avec une activité. Une base de données permet de stocker et de retrouver un ensemble d'informations de plusieurs natures ainsi que les liens qui existent entre les différentes informations. (source : wikipedia) Android: est un système d'exploitation pour smartphones, tablettes tactiles, PDA et terminaux mobiles. C'est un système open source utilisant le noyau Linux. (source: wikipedia) MVC: Le patron modèle-vue-contrôleur est un modèle destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective. (source: wikipedia) Open Data: Une donnée ouverte est une donnée numérique d'origine publique ou privée. Elle est produite par une collectivité ou un service public (éventuellement délégué). Elle est diffusée de manière structurée selon une méthodologie et une licence ouverte garantissant son libre accès et sa réutilisation par tous, sans restriction technique, juridique ou financière. (source wikipedia) Contrôle (graphique): Un contrôle graphique est un composant logiciel paramétrable destiné à être affiché sur le formulaire. (source http://www.agroparistech.fr/) XML: «langage de balisage extensible» en français) est un langage informatique de balisage générique qui dérive du SGML. (source wikipedia) 12 sur 14
PHP: est un langage de programmation libre4 principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP3, mais pouvant également fonctionner comme n'importe quel langage interprété de façon locale. PHP est un langage impératif orienté-objet. (source wikipedia) API: une interface de programmation (abr. API pour Application Programming Interface) est un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels (source wikipedia) Java: est un langage de programmation orienté objet mis au point par Sun Microsystems (source wikipedia) Framework: un framework est un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d une partie d'un logiciel (architecture). (source wikipedia) 13 sur 14
XII. Références 1. Wikipedia 2. Moopencafé 3. Eclipse 4. PHP Codeigniter 5. Rippler 6. Apache Cordova 7. JQuery 8. Norme GTFS 9. API PARIS 3.0 14 sur 14