Plan de développement logiciel

Transcription

1 Date : 09/03/2004 Groupe : Is3be2 Isi Engineering Process Publisher Version 4.0 Superviseurs de projet : Claude Aubry Nombre de pages : 12 Bernard Cherbonneau Responsable Sandra Poulain

2 Historique des révisions VERSION DATE DESCRIPTION DES EVOLUTIONS AUTEURS /10/2003 Création Tous /11/ /11/ /01/ /01/2003 Prise en compte des remarques de la revue Modification des objectifs des itérations Rôles et responsabilités après intégration des 2A Modifications des objectifs des itérations Nicolas Michel Sandra Poulain Sandra Poulain Sandra Poulain /03/2004 Modifications du planning et des ITs Sandra Poulain 2

3 Table des matières Chapitre 1 : Introduction Objectif Portée Références... 4 Chapitre 2 : Vue d ensemble du projet But du projet, portée, et objectifs Hypothèses et contraintes Fournitures du projet Evolution du plan de développement logiciel... 5 Chapitre 3 : Organisation de projet Structure de l organisation Interfaces externes Rôles et responsabilités Superviseurs de projet Equipe 3ème année Equipe 2 ème année... 7 Chapitre 4 : Processus de gestion Estimations de projet Plan de projet Plan de Phase Objectifs des itérations Livraisons Calendrier de projet...10 Chapitre 5 : Processus qualité Mécanismes de suivi et de contrôle Gestion de la documentation Gestion de configuration

4 Chapitre 1 : Introduction 1.1 Objectif Ce document a pour but de présenter l ensemble des informations nécessaires au contrôle du projet IEPP. Il sert à la bonne gestion du projet. Il décrit en détail les différentes phases du projet avec leur durée, les ressources nécessaires à leur bon déroulement et les produits attendus lors des différentes itérations. 1.2 Portée Ce document sera utilisé par l équipe du projet et sera disponible pour le client si celui-ci désire l étudier et faire des remarques. 1.3 Références - Le processus RUPF - Vision - Liste des risques - Document des cas d utilisations Chapitre 2 : Vue d ensemble du projet 2.1 But du projet, portée, et objectifs Le projet consiste à réaliser un outil de publication de processus d ingénierie à partir d une configuration de processus. Il permet aux ingénieurs processus d assembler des composants de processus de publier facilement le résultat sous forme de site Web. 2.2 Hypothèses et contraintes - L application développée devra être livrée obligatoirement à la fin du mois de Mars. Une version stable de l application devra être livrée impérativement une semaine avant la recette finale afin de permettre au client de tester suffisamment le produit pour faire des remarques pertinentes. - L application devra être développée en Java. - L équipe de projet sera constituée de 4 membres de 3 ème année et de 3, 4 ou 5 membres de 2 ème année. L équipe ne pourra pas être modifiée en cours de projet. 4

5 2.3 Fournitures du projet Produits de l expression des exigences : Enoncé & Spécifications des besoins Spécifications supplémentaires Identification des cas d'utilisation Vision Modèle des cas d'utilisation Produits d analyse et conception : Document d'architecture du logiciel Document de conception Maquette Produits de gestion de projet : Plans des itérations Evaluation des itérations Listes des risques Compte-rendu de revue Produits de gestion du processus : Guide de programmation Plan de cycle de vie Produit final : Logiciel IEPP Cahier de recette Tests : Tests unitaires Tests d intégration Cahier de test Plan de validation du logiciel Déploiement : Manuel Utilisateur 2.4 Evolution du plan de développement logiciel Ce PDL sera amené à changer au cours du projet. Une nouvelle version devrait être disponible à chaque itération, si cela s avère nécessaire. En cas d imprévus, une nouvelle version de ce document pourra être disponible en cours d itération. 5

6 Chapitre 3 : Organisation de projet 3.1 Structure de l organisation L équipe est pour l instant composée de 4 étudiants de 3ème année et de 5 étudiants de 2ème année. 6

7 3.2 Interfaces externes La majorité des contacts externes se feront avec les superviseurs du projet. Afin d assurer la compatibilité avec les outils d édition, de présentation et d exécution, un standard de fichier commun à tous les groupes de travail de l ensemble des projets a été défini. 3.3 Rôles et responsabilités Superviseurs de projet Nom Claude AUBRY Bernard CHERBONNEAU Rôle Client Client Equipe 3ème année Nom Sylvain LAVALLEY Nicolas MICHEL Sandra POULAIN Nicolas PUJOS Rôle Architecte, Analyste Spécialiste Outil, Analyste Chef de projet, Analyste Ingénieur processus, Analyste Equipe 2 ème année Nom Robin EYSSERIC Natalia BOURSIER Cédric BOUHOURS Stéphane ANRIGO Vincent MARRILLAUD Rôle Analyste-programmeur Analyste-programmeur Analyste-programmeur Analyste-programmeur Analyste-programmeur Chapitre 4 : Processus de gestion 4.1 Estimations de projet L ensemble du projet devra être terminé à la fin du mois de Mars, et il ne sera pas possible de repousser cette échéance. 7

8 4.2 Plan de projet Plan de Phase Phase Nombre d itérations Date de début Date de fin Lancement 1 17 Octobre Novembre 2003 Elaboration 2 16 Novembre 2003 Fin des cours Décembre 2003 Construction 2 Fin des cours Mi Mars 2004 Décembre 2003 Transition 1 Mi Mars Fin Mars 2004 Une revue aura lieu à chaque fin d itération. Une revue informelle aura lieu au milieu de la phase d élaboration Objectifs des itérations * Itération 0 : - Identifier les cas d utilisation - Définir les cas d utilisation principaux - Commencer à définir l architecture * Itération 1 : - Définir l architecture à utiliser - Définir tous les cas d utilisations retenus et vérifier qu ils couvrent la totalité des besoins exprimés par le client - Réaliser une première version de l application (prototype) réalisant les Opérations Systèmes du CU1 Editer une définition de processus : créer une nouvelle définition de processus ajouter un composant au processus * Itération 2 : - Intégrer l équipe de 2ème année à l aide de formations - Affiner l architecture et continuer à construire l application - Eliminer les risques majeurs : maîtrise du processus, architecture adaptée - Des cas d'utilisation doivent être réalisés et testés. Il sera donc possible de : ajouter au diagramme un composant ajouter un composant au processus en prenant en compte les interfaces éditer les propriétés d une définition de processus lier graphiquement deux composants avec leurs interfaces générer un site web en HTML pour une définition de processus comportant un seul composant vérifier l assemblage de composant (réalisé en partie) exporter le diagramme en JPEG ou PNG imprimer le diagramme 8

9 * Itération 3 : - Tester l application et corriger les erreurs éventuelles - Ajouter les fonctionnalités manquantes : Exporter la définition de processus vers l outil 4 Paramétrer et générer le site web Lancer la vérification de la définition de processus (à finaliser) Ajouter un composant à la définition de processus (charger le fichier presentation.xml) Lier deux composant à l aide de produits (à finaliser), renommer un produit fusion Supprimer la liaison entre deux composants Editer les propriétés générales d une définition (à finaliser) Créer un composant vide Editer l'interface d'un composant vide Sauvegarder un composant vide avec ses interfaces * Itération 4 : - Eliminer la plupart des risques - Ajouter les fonctionnalités manquantes : Gérer le référentiel Sauvegarder une définition de processus Sauvegarder une définition de processus sous Ouvrir une définition de processus existante Fermer une définition de processus Lier deux composants à l aide de produits (à finaliser) Supprimer un composant du diagramme d assemblage Générer le site Web (à finaliser) Exporter une définition de processus * Itération 5 : - Corriger les dernières erreurs éventuelles - Effectuer les tests de validation - Effectuer la recette Finaliser les actions Undo/Redo 9

10 4.2.3 Livraisons Une livraison aura lieu à la fin de chaque itération, et chaque livraison devra être représentative d une partie du produit final afin de suivre le bon déroulement du processus Calendrier de projet Lancement Itération 0 Elaboration Itération 1 Itération 2 Construction Itération 3 Itération 4 Transition Itération 5 Novembre Décembre Janvier Février Mars Itération 0 : 4 semaines Itération 1 : 5 semaines Itération 2 : 5 semaines Itération 3 : 4 semaines Itération 4 : 4 semaines Plan de composition de l équipe La composition de l équipe a changé une fois au cours du projet lors de l intégration des membres de 2ème année, qui joueht des rôles de développeurs Plan de formation - Formation à l outil Eclipse et intégration de CVS - Formation à XML et génération avec transformateur XSLT - Présentation du sujet et de l outil à l équipe de 2ème Année 10

11 Chapitre 5 : Processus qualité 5.1 Mécanismes de suivi et de contrôle Le chef de projet doit chaque semaine établir un rapport du travail effectué par chacun des membres. Celui-ci sera basé sur des fiches de travaux remplies soit sur le site Web du projet soit fournies directement au chef de projet. Ce rapport permettra d effectuer des mesures précises du temps consacré au projet. 5.2 Gestion de la documentation Le chef de projet s assure d'avoir un exemplaire de tous les documents produits pour chaque itération. Il assure aussi la diffusion de toutes les informations au sein du groupe et vers le client lors des revues. Les documents doivent être conformes aux plans type correspondants et au modèle général de document du projet. Les documents doivent être fournis dans deux formats : - format.doc de Microsoft Word/openOffice - format.pdf d Adobe Tous les documents produits, les plans type et le modèle de document (.dot) sont publiés sur le site Web du projet. Le nom des documents doit être de la forme : IEPP_nom_du_document_vx.x.format Le responsable du document indique le passage d une version à une autre. 5.3 Gestion de configuration Afin de garantir un environnement de travail cohérent, il a été décidé d utiliser l outil CVS pour faire de la gestion de configuration. Ainsi l équipe dispose d un espace centralisé et accessible depuis Internet. Pour le projet IEPP, suite à la fermeture du site c est désormais le serveur marine.edu.ups-tlse.fr qui héberge le serveur CVS. Chaque membre de l équipe disposera d un compte et peut faire des modifications sur le dépôt. L équipe utilise également l outil Eclipse. Cet outil dispose d un module d interfaçage avec CVS intégré. Chaque membre de l équipe peut donc utiliser cet outil pour récupérer les dernières versions des sources et partager son travail. Les règles de mise en place dans le référentiel CVS sont les suivantes : 11

12 - le code ne doit pas poser de problèmes de compilation - le code doit avoir passé l ensemble des tests disponibles - le code réalisé permet de répondre à un besoin ou corrige un bug La gestion de configuration ne concerne que les fichiers source ; les documents sont gérés par leurs responsables et disponibles sur le site. La mise en référentiel de chaque nouveau module doit être approuvé par le chef de projet. 12