rad-framework Software development plan document version 01 Oussama Boudyach April 20, 2011

Transcription

1 rad-framework Software development plan document version 01 Oussama Boudyach April 20,

2 Contents 1 Introduction 3 2 Documents et matériels Document et matériel octroyé: Documents à fournir: Présentation 4 4 Approche de Développent: Calendrier Milestone Gestion du développement organisation du projet et des ressources Ressources matérielles: Structure organisationnelle: Activités Gestion de risques:

3 1 Introduction L objectif de ce projet et de développer une Framework RAD suivant la logique MDA qui à partir d un diagramme UML génère l essentiel d une application web. Ce projet s inscrit dans le cadre du projet de fin d étude à l INP-ENSEEIHT.. Ce document décrit le plan de développement du projet, l organisation établie et les buts à remplir. Ce document doit être validé par le client. Ce document est appelé à progresser tout au long du processus de développement suivant plusieurs versions. 2 Documents et matériels 2.1 Document et matériel octroyé: On a en notre disposition: Un ordinateur DELL processeur à double cœur cadencé à 3 ghz avec 2 go de ram. Un réseau internet haut débit. Droits d administrateur sur la machine pour installer tous les outils dont on a besoin. Documentation java/j2ee. 2.2 Documents à fournir: On doit fournir: le document software requirement. le document software development plan. le document software validation plan. le document software quality insurance plan. le code (via svn). un exécutable du produit (sous forme jar). le document software maintenance guide. un set de tests pour chaque partie du produit. 3

4 3 Présentation le projet rad Framework est un plugin Eclipse développé en langage java. Il aura donc besoin et de la JRE 1.6 et une plateforme riche d Eclipse. Le projet est divisé en plusieurs partie, chacune fera l objet d un plugin séparé. Voici une liste des différentes parties: editor: perspective rad-framework avec navigateur et plateforme pour créer un diagramme de classes et un diagramme d activités. jsf-generator: pour générer le code nécessaire à l interface utilisateur de l application web via JBoss Seam. ejb-generator: pour générer la partie métier de l application web, notamment les stateless session beans et les message driven beans. jpa-generator: pour générer la partie persistance de l application web, et donc des entity beans. war-project: un rendu de l application web sous forme de projet war. ear-project: un rendu de l application web sous forme de projet ear. doc-generator: pour générer la documentation lié au modèle défini. La partie editor est ce qui sert d entrée pour le projet; en effet c est cette partie qui permet de créer ou charger un nouveau modèle. Elle permet également d introduire et compléter le modèle grâce au stéréotypes, et au final générer l application web en partie ou en intégralité. Cette partie est donc lié à toutes les autres parties du projet du moment qu elle permet de les appeler. En suite les trois parties jsf-generator, ejb-generator et jpa-generator ont toutes pour objectif de générer le code java correspondant. D une part elle sont indépendantes; on peut donc les traiter dans un ordre quelconque, et d autre part elle fonctionnent quasiment de la même manière; on peut donc créer une architecture commune à adapter pour chaque type de génération. Enfin les deux parties war-project et ear-project représentent le rendu de l application web créée. Celle ci sera structuré grâce à Maven, et donc dé-ployable après installation directement sur un serveur JBoss adapté. En supplément la partie doc-generation permet de générer de la documentation correspondant au modèle créé à partir des commentaires rajoutés. cf SoftwareRequirement.pdf pour une vue plus détaillé sur les différentes parties du projet. 4

5 4 Approche de Développent: 4.1 Calendrier Semaines et objectifs Première rencontre avec le tuteur de stage. Découvrir le plateau Amadeus au sein de Logica. 28/03 au 04/04 Découvrir le matériel et les applications à notre disposition. Installation des logiciels et outils retenus pour le développement. Explication du sujet de stage en profondeurs par le tuteur. 04/04 au 11/04 L état de l art des Framework existant et en retenir les plus prometteurs qu on va utiliser. Se documenter sur les frameworks retenus. Définir un cahier de charges. Propositions d un plan de développement. 11/04 au 18/04 Établissement d un plan de suivi pour la validation. Établissement d un plan de suivi pour la qualité. Paramétrage et configuration des différents outils afin de commencer la conception et le développement. 18/04 au 25/04 à compléter. 4.2 Milestone les étapes importantes du développement sont: Validation de la spécification par le client. Validation des choix techniques, du GUI, et de la structure des données par le client. Une version remplissant les charges importantes définis par le client. 5

6 5 Gestion du développement 5.1 organisation du projet et des ressources Ressources matérielles: Le développement aura lieu dans le plateau d Amadeus au sein des locaux de Logica PACA. Le développement s effectuera sur des machines Dell doté de processeur E Structure organisationnelle: Le développement suivra cinq parties indépendantes: la partie management qui aura comme base les réunions avec le tuteur pour ainsi surveiller la progression du projet. la partie qualité qui va assurer que le développement va atteindre une qualité standard définie avec le client. la partie technique ou il faut s assurer du bon choix des solutions techniques utilisé et leur impacte sur les développement à venir. la partie production ou il faut définir l environnement de développement et gérer les versions de production. la partie validation ou il faut planifier au fur et à mesure un processus de validation et d acceptation. Le développement sera évidemment supervisé par le tuteur de stage au sein de Logica Mr. Eric Antoni. 5.2 Activités Le projet a débuté le 28/03/2011 et va se terminer en fin septembre Pour ce projet on va utilisé un cycle itératif de type agile. 5.3 Gestion de risques: Les risques majeures vis à vis de notre projet sont les problèmes imprévisible durant les tache critiques. Les taches sont bien identifiées: La validation de la spécification par le client. La validation de la structure des données. la validation de l algorithme suivi pour la génération de code. Pour éviter tout problème au niveau des taches critiques, plusieurs réunions sont programmées avec le tuteur. Risques action préventives action correctives Technologies inconnue Faire des prototypes. Requête pour changement de technologie. Volatilité de la structure de données Réunions avec le client. Requête pour changement de charge. 6