Référence du document. Maîtrise d ouvrage (MOA) Maîtrise d œuvre (MOE) Suivi du Document

Transcription

1 Référence du document Utilisation Externe Mots clefs SDP Phase Requirements Objet du document MOA Faculté de Créteil MOA Premier Enseignant Mr Brenner MOA Second Enseignant Mr Giraud Maîtrise d ouvrage (MOA) Maîtrise d œuvre (MOE) MOE Neuvième Sens MOE Chef de Projet Jérémie Klein MOE Resp. Fonctionnel Sébastien Gissinger MOE Resp. Technique Youssef Foullous Version Auteur Date Description 1 Jérémie KLEIN 30/11/2007 Création du document Suivi du Document Utilisation Destinataires Lecture Commentaire Validation Approbation Information 9ème Sens X Mr GIRAUD Mr BRENNER X X Neuvième Sens Reproduction Interdite 1/12

2 SOMMAIRE 1 SCOPE IDENTIFICATION OVERVIEW PRINCIPES MÉTHODOLOGIQUES TUP Principes Mise en Place NORMES DE CODAGE DOCUMENTATION DU CODE TESTS DRIVEN DEVELOPMENT (TDD) LIVRABLES DU PROJET ORGANIGRAMME RÔLES ET RESPONSABILITÉS BUDGET ET DÉPENSES COMPÉTENCES TECHNIQUES PLAN DE FORMATION Neuvième Sens Reproduction Interdite 2/12

3 1 Scope Ce SDP établit un plan permettant l'implémentation, les tests et la gestion de 2bornew, un moteur de calcul distribué Open Source. Ce projet est développé sous la direction du groupe de travail Neuvième Sens, composé d'étudiants en Master MIAGE deuxième année à la faculté de Créteil. Ce document sera mis à jour en parallèle de l'avancement du projet afin de permettre à une personne extérieure de savoir comment l'application est gérée ou de pouvoir rejoindre l'équipe à tout moment. 1.1 Identification Ce document s'applique aux deux applications constituant la solution : Le moteur de calcul distribué, dans sa préversion L application cliente chargée d'effectuer le calcul Aperçu du système Les besoins tels qu'énoncés impliquent la création des deux applications bien distinctes. Une sera chargée de la gestion des projets, de la répartition des calculs, de la gestion du client et du reporting de l'application. Elle pourra être considérée comme le serveur du fait de son rôle central. La seconde application est le client, qui elle est exécutée sur les postes client afin de permettre la résolution des calculs que le serveur lui enverra. Le serveur peut fonctionner de manière autonome, toutefois il n'effectue aucun calcul luimême, il peut uniquement transmettre les calculs à ses clients qui traitent la demande. Le système doit permettre la gestion des différents projets de calcul, des différents clients ainsi que la consultation de statistiques sur les clients et les serveurs. L'application doit de plus permettre aux volontaires d'implémenter leurs propres calculs de leur domaine métier au sein d'un projet. 1.2 Overview Ce document identifie les Requirements et les standards pour le projet. Ce document et ses annexes (Iteration Plan, Risk Management Plan, Quality Assurance Plan, Charges) définissent le planning, l'organisation, les ressources et les procédures nécessaires au développement du projet Neuvième Sens Reproduction Interdite 3/12

4 2 Principes Méthodologiques Etant donné l'envergure du projet, Neuvième Sens a décidé d'utiliser la Méthode de conduite de projet 2TUP (Two Tracks Unified Process) pour tout ce qui concerne la gestion (avec un développement dirigé par les Use Case), et comme méthode de développement une méthode AGILE. On utilise donc plusieurs méthodes parce que l'utilisation du 2TUP ou RUP sur l'intégralité du projet ne serait pas adaptée. Nous allons de plus utiliser la méthode de développement Test Driven Development TUP Principes Cette Méthode propose un traitement en parallèle des aspects liés aux questions fonctionnelles et des aspects liés à l'architecture technique du projet. De plus, l'utilisation du cette méthode permet de rendre plus visible les trois aspects que sont les délais, les couts, la qualité. De ce fait, le Client possède un ensemble de documents et d'éléments lui permettant de contrôler et de comprendre l'ensemble des activités du projet et d'intervenir à tout moment. Dans la mesure où il a connaissance de l'ensemble des moyens de gestion de projet et que cette méthode a fait ses preuves, il peut être rassuré par rapport au déroulement du projet. Déroulement du 2TUP Neuvième Sens Reproduction Interdite 4/12

5 La branche fonctionnelle correspond à la modélisation du domaine, du problème à résoudre et des besoins des utilisateurs. Mais contrairement aux autres méthodes de conduites de projet existantes qui considèrent que l'aspect technique se déduit d'une manière ou d'une autre des aspects fonctionnels, nous avions besoin de traiter indépendamment la branche technique. En effet la mise en place de l'infrastructure technique du projet 2bornew devient elle-même un sujet de la conception et de la modélisation dans les différentes études et choix des différentes solutions technique qu'elle impose. Il faut donc créer de toutes pièces un modèle des composants et de leurs interactions. Il faut faire des choix en matière de techniques : il n'y a pas qu'une base de données centrale unique mais des BD réparties qui communiquent entre elles. les logiciels mettent en œuvre des composants autres que le seul stockage et accès sécurisé aux données : interfaces utilisateurs, communication de l'information via des réseaux (locaux, intranet, internet...), présentation de l'information sur les postes de travail, etc. La troisième branche est une synthèse des 2 chemins. Elle consiste à articuler le mieux possible des composants "métier" avec des composants technologiques. La méthode de conduite de projet 2TUP, héritant de la méthode RUP (mais avec une différente approche), hérite donc logiquement des mêmes principes méthodologiques de cette dernière : Système définit avec les utilisateurs Processus de développement guidé par les cas d'utilisations Estimation de charges et planification Gestion des risques Suivit des couts Formalisation des besoins (cahier des charges et spécifications fonctionnelles) Cahier de recette Modélisation Développement (Accompagné par les utilisateurs) Test Déploiement Neuvième Sens Reproduction Interdite 5/12

6 2.1.2 Mise en Place Le client est impliqué à chaque étape & itération pour validation (ou non) et tests. Durant la réalisation, chaque itération (de préférence courte : 1 à 2 semaines) donne lieu à une livraison (validation), même si ce n est que pour livrer l écran de connexion : cela montre au client que les développements ont commencé, que la charte graphique est en place, etc. Cette démarche de «multiples petites livraisons» permet d éviter «l effet tunnel», de détecter rapidement une mécompréhension des besoins et évite une livraison définitive «dans la douleur». Bien sûr chaque livraison d un module/lot/fonctionnalité implique de repasser les tests effectués dans les précédentes itérations, garantissant ainsi la non régression de l application. 2.2 Normes de codage Des normes de codage devront être définis et utilisées dans tout le code. Ces normes permettent une uniformisation du code et moins de disparités entre les différents développements. Ils devront en outre permettre une relecture facile du code avec l'utilisation de noms adaptés pour les objets, les fonctions ou les variables. Ces normes seront décrites dans les spécifications techniques. 2.3 Documentation du code L'ensemble de la documentation fait partie de la liste des livrables présentée plus bas. Néanmoins le code lui-même sera documenté afin d'en assurer la maintenance. La documentation n'est en aucun cas une partie annexe d'un programme. L écriture de la documentation permet en outre de penser à tous les cas à implémenter. Cette documentation doit être écrite avant l'écriture du test et de la fonction. Le test devra s'appuyer sur cette documentation pour connaître les cas à tester et ce qu'il faut tester. La fonction doit elle correspondre exactement à ce qui est décrit dans la documentation. Le codage de l'application n'est qu'une transformation de qui est écrit dans la doc en code Neuvième Sens Reproduction Interdite 6/12

7 2.4 Tests Driven Development (TDD) Test Driven Development (Développement piloté par les tests) est une méthode de développement permettant d'assurer un maximum de sécurité au développement en préconisant l'écriture des tests unitaires avant l'écriture du code. Cette méthode se déroule en plusieurs étapes et doit être reproduit à chaque écriture d'une fonctionnalité ou d'une fonction : Ecrire le test servant à tester la fonctionnalité (fonction) avant même que la fonctionnalité ne soit disponible Faire tourner le test et le faire échouer (la fonctionnalité n'est pas encore présente) Ecrire le bout de code chargé de gérer la fonctionnalité en allant au plus simple Tester la fonctionnalité avec le test. Il faut retourner à l'étape précédente jusqu'à ce que celui-ci passe. Si le test passe, on sauvegarde (ne fait pas partie des principes du TDD, mais c'est un ajout utile) Refactoriser le code de manière plus propre Refaire passer le Test. De la même manière, si celui-ci échoue on retourne à l'étape précédente, sinon on sauvegarde (sous SVN encore) Cette méthode de développement apporte plusieurs avantages : Permet d'assurer la non régréssivité de l'application lors d'ajout de nouvelles fonctionnalités Permet de s'assurer que la fonctionnalité répond bien au besoin voulu. 3 Livrables du projet Les livrables suivant seront livrés au fur et à mesure de l avancement du projet. Livrable Date de Livraison Cahier des charges fonctionnelles 30/11/2007 Cahier des charges technique 30/11/2007 Software Development plan 30/11/2007 Benchmarking 30/11/2007 Planning général 30/11/2007 Planning détaillé 30/11/2007 Maquette (avec ébauche d architecture) 07/12/2007 Spécifications fonctionnelles 18/01/2008 Spécifications techniques 18/01/2008 Cahier de recette 18/01/2008 Dossier technique (dossier d installation d exploitation et de maintenance) 11/04/2008 Application 16/04/ Neuvième Sens Reproduction Interdite 7/12

8 4 Organigramme Cet organigramme a été construit en fonction des besoins nécessaires à l'accomplissement de l'ensemble des tâches, mais aussi en fonction des envies et désirs de chacun. Cet organigramme n'est pas fixe, il peut être amené à évoluer en fonction des besoins immédiats. Ceci est possible parce que les compétences de chacun des membres du groupe se recoupent et que l'on dispose sensiblement des mêmes compétences. Par exemple, pendant la phase d'inception, un développeur a rejoint l'équipe fonctionnelle en soutien Neuvième Sens Reproduction Interdite 8/12

9 5 Rôles et responsabilités Afin de mener le projet au bout, nous avons identifié différents rôles ; Chaque rôle dispose de ses taches propres. Chef de projet : Opère les activités de gestion et de requirements. Il coordonne en outre l'équipe fonctionnelle et technique. Il s'assure que le travail est bien fait dans les délais impartis, avec les couts fixés et la qualité souhaitée. Il gère l'équipe de travail et contrôle le travail effectué. Chef d équipe fonctionnelle : Il participe donc aux activités de management. Il participera à toutes les activités d'analyse, et de recette. Assistant fonctionnel : Il est chargé d'assister le chef d'équipe fonctionnelle dans ses tâches. Il effectue les activités de requirement du domaine fonctionnel. Il participe à la recette de chaque lot et à leur analyse. Responsable d équipe technique : Il est chargé de gérer l'équipe technique. Il a pour rôle d'organiser son équipe de développement afin de tenir les délais ainsi que la qualité. Il est aussi en charge de contrôler le travail effectué par ses équipes. Il participe aux activités de recette et effectue les activités d'analyse avec l'architecte. Il participe aux tests de l'application. Concepteur/Architecte : Il participe aux activités d'analyse et de conception. Il pourra participer au développement de la maquette, au développement et au déploiement de chaque lot. Il participe aussi aux activités de requirement concernant le domaine technique avec le responsable de l'équipe technique. Il participe aux tests de l'application. 4 développeurs : Ils opèrent principalement les activités de développement et de tests. Ils participeront éventuellement au déploiement de l'application ainsi qu'à la recette. Ils participent à tous les tests effectués par l'équipe. 6 Budget et dépenses Le groupe de travail est composé uniquement d'étudiants et il n'y a encore aucun client intéressé par l'application. Dans la mesure où ce projet est à objectif purement universitaire, le budget dont dispose d'équipe est de 0. Nous ne parlerons donc pas de l'aspect prix, les points importants étant la qualité et les délais. Le suivi des activités est quand à lui nécessaire afin d'assurer les délais. Ces informations sont présentes dans le Measurement Plan Neuvième Sens Reproduction Interdite 9/12

10 7 Compétences techniques L équipe projet est composée de 9 membres qui ont été amené à travailler dans des domaines variés. Néanmoins, certaines connaissances sont communes. Jérémie KLEIN Chef de Projet Il dispose de peu de connaissance en conduite de projet, c'est le premier projet ou il doit gérer une équipe. Web : PHP (avec et sans Framework cake PHP), HTML, CSS, Perl (Framework Catalyst), Python (Zope) Développement : Java, Perl, C, C++, Python, Capability Discipline SGBD : Oracle, Mysql Système : Linux, Unix, Soekris Méthodes : Test Driven Development, Extreme Programming Sébastien GISSINGER - Chef d'équipe fonctionnelle Web : XHTML, CSS, Javascript, Tomcat (jsp, servlet), PHP, ASP Développement : Java (RMI) SGBD : MySQL Méthode : UML Abderrazak ZOUIRI - Assistant fonctionnel Web : J2EE Développement : Java, Visual visuel Basic, HTML SGBD : Oracle, MySQL, Access Système : Linux, Windows Méthode : UML, Merise Youssef FOULLOUS - Responsable d'équipe technique Web : J2EE Développement : Java Struts ou Hibernate en Java afin de faire du mapping relationnel Objet/Base de données SGBD : Oracle, MySQL Méthode : UML Neuvième Sens Reproduction Interdite 10/12

11 Youssef HANNAD : Développeur Web : J2EE, PHP Développement : Java Struts et Hibernate SGBD : MySQL Méthode : UML Daniel SAWAN - Développeur Web : Microsoft SharePoint Développement : Java, Perl, Progress SGBD : Oracle, MySQL Système : Unix, Linux Méthode : UML Thomas SERVAIS - Architecte Web : HTML, PHP, CSS, J2EE, Ajax, Webdev, Apache, IIS Développement : C, C++, Java, Delphi, RPG (As400), SQL, Windev Bases de données : Oracle, MySQL, DB2, HyperFile Système : MacOSX, Windows, linux Méthode : Merise, UML 2.0 Hicham ZINI - Développeur Web : J2EE Développement : Java, Visual Basic, PHP, HTML SGBD : Oracle, MySQL, Access Système : Linux, Windows Méthode : UML, Merise Mohammed Otmann ABADI - Développeur Web : J2EE Développement : Java, Visual Basic, PHP, HTML SGBD : Oracle, MySQL, Access Système : Unix, Windows Méthode : UML, Merise Nos ressources sont a priori suffisantes pour réaliser le projet dans les délais impartis. Nous ne prévoyons donc aucune acquisition de ressources, surtout que la cadre de ce projet (universitaire) nous l interdit Neuvième Sens Reproduction Interdite 11/12

12 8 Plan de formation Avant ou au commencement du projet, les développeurs qui n'ont jamais travaillé sous un serveur J2EE seront familiarisés avec cet environnement par ceux de l'équipe qui connaissent déjà. De même certaines personnes ne connaissent pas de Framework Java (Struts, Hibernate) devront se former dessus avec l'aide des membres connaissant déjà ce type de technologie. De même, Corba est aussi un pré-requis pour les développeurs. Nous ne disposons de personne connaissant cette technologie. Afin de se former sur Corba, de nombreux documents et exemples peuplent le web et permettront à un développeur de se former et de présenter une maquette. Ce développeur devra aussi former les autres. La personne désignée en tant que spécialiste Corba et qui souhaite faire cette étude est Thomas Servais Neuvième Sens Reproduction Interdite 12/12