ECOM

From air
Revision as of 08:23, 16 September 2013 by Pierre.Lartigue (talk | contribs) (RICM5)
Jump to: navigation, search

Objectifs du projet

Le projet eCOM consiste à concevoir et développer une application de commerce électronique. Une motivation principale du projet eCOM est qu'il intègre dans sa mise en œuvre différentes thématiques étudiées dans les formations en informatique : en particulier, interfaces homme-machine, applications et architectures réparties, bases de données. Les aspects relatifs au génie logiciel sont également présents puisque le projet eCOM comprend la conception et la réalisation d'un produit logiciel qui satisfait certains critères de qualité (documentation, respect des normes, etc).

L'intégration de différentes thématiques présente les atouts suivants :

  • Valorisation des enseignements acquis dans les différentes thématiques au profit d'un projet important et réaliste.
  • Appréhension des (inter)dépendances entre les thématiques.
  • Communications entre les différents réalisateurs du projet.

En outre, une deuxième motivation forte du projet eCOM est qu'il intègre des technologies et des standards récents et largement utilisés dans le domaine des applications Internet. Ce projet permet plus précisément de se placer en tant qu'utilisateurs de la technologie JEE (Java Enterprise Edition) destinée à la réalisation de serveurs d'information ou de serveurs de commerce électronique à base de composants distribués, transactionnels et persistants. Les réalisateurs sont confrontés par ce biais à la manipulation de mécanismes et de fonctions générales d'un système réparti : gestion de la désignation de composants distribués, configuration d'une application distribuée, association de propriétés non fonctionnelles aux composants (persistance, transactions), gestion des images persistantes des composants (liaisons avec une base de données). Des extensions au projet sont décrites ici et seront réalisées lors du projet RICOM/GICOM au semestre 2.

L'application réalisée devra offrir deux interfaces distinctes :

  • les administrateurs qui gèrent les stocks de produits, les comptes des utilisateurs de l'application et le suivi des commandes ;
  • les consommateurs/acheteurs qui peuvent consulter des articles, les placer dans leur caddie et valider une commande.

Chaque groupe devra élaborer un cahier des charges précis de l'application en termes de fonctionnalités et de critères d'ergonomie. Par ailleurs, le projet devra être réalisé en employant les méthodes et technologies présentées en cours. Ces différents aspects devront être validés par l'équipe pédagogique tout au long du projet.

Étapes du projet

La partie IHM et la partie Système sont menées en parallèle pendant toute la durée du projet. Le projet se conclut par une soutenance finale pour chaque partie (IHM et système).

Conduite de projet

Le projet eCOM est très court en durée. Il est préconisé d'utiliser la méthodologie Scrum pour la conduite du projet dans chaque groupe.

Critères d'évaluation

La conduite du projet sera principalement évaluée en fonction des critères suivants :

  • vous devez choisir un Scrum Master (unique ou tournant) : vous devez justifier votre choix
  • durée du sprint (idem : vous devez justifier votre choix)

Sur ces 2 premiers critères, vous n'en changez pas !!!

Vous devez prévoir :

  • product backlog
  • sprint backlog
  • sprint planning
  • démos
  • rétrospectives

Pensez à créer un wiki qui regroupera l'ensemble de vos documentations. Cela doit être une documentation Agile !!!!

Un point de bonus pour ceux qui réussiront à mettre en place des "poker planning". 20121002 141359.jpg

Partie IHM

Etapes et documents demandés

Trois documents sont à produire : le cahier des charges (CDC), le dossier de conception IHM (à rédiger avant de développer l'IHM du site) et le document d'évaluation IHM. Les versions finales des deux premiers documents (CDC et dossier de conception IHM) sont à remettre une semaine avant les soutenances et le dossier d'évaluation, le jour de la soutenance.


Le détail sur l'organisation et l'évaluation du travail concernant les spécifications du site sera communiqué lors des premières séances de cours. En résumé :

  • Une fois le sujet choisi, analyser les sites "concurrents" et mener une enquête auprès d'utilisateurs représentatifs du futur site marchand, faire une analyse des données recueillies, en déduire les requis fonctionnels et non fonctionnels du site, identifier le modèle de l'utilisateur type, produire le modèle de tâches. Les analyses amont (sites concurrents et enquête) seront mises en annexe du CDC.
  • Définir une norme de présentation pour tous les documents du projet.
  • Ensuite, rédiger le cahier des charges. Bien penser à définir les priorités de développement. Des exemples des années précédentes seront consultables en séances d'audit.
  • Une fois le CDC validé, rédiger le dossier de conception IHM : IHM abstraite, IHM concrète, charte graphique.

Critères d'évaluation

La partie IHM du projet sera principalement évaluée en fonction des critères suivants :

  • Conformité de l'IHM concrète et abstraite avec le modèle de tâche
  • Couverture fonctionnelle de l'application et robustesse au regard des priorités que vous avez retenues
  • Qualité ergonomique au regard des principes vus en cours
  • Rigueur de la démarche

Partie Système

La partie Système est axée sur deux étapes successives.

Première étape

La première consiste à définir le cœur de l'application, c'est-à-dire le modèle de données et la logique métier, puis à réaliser un premier prototype qui démontre une bonne maîtrise des EJB (session et entity beans).


Il est vivement conseillé de définir le modèle de données aussi tôt que possible et d"en discuter avec les enseignants. Il est également recommandé de limiter le premier prototype à un sous-ensemble des spécifications fonctionnelles, à la fois assez vaste pour couvrir les principales difficultés techniques et assez léger pour respecter les délais imposés.


À ce stade, l'application est seulement accessible par l'intermédiaire d'un "client lourd" (programme java offrant une console en mode texte). En particulier, il n'est pas demandé, pour cette première étape, de réaliser une interface web pour interagir avec l'application. L'application doit cependant offrir deux interfaces (administrateur et consommateur) et exécuter les requêtes avec des garanties transactionnelles.


Une présentation/démonstration du prototype V1 sera réalisée à la fin de l'étape n°1.

Deuxième étape

La seconde étape consiste à compléter le premier prototype avec les objectifs suivants :

  • ajout des beans nécessaires pour couvrir l'ensemble des spécifications fonctionnelles ;
  • développement d'une interface Web basée sur le modèle MVC ;
  • rédaction des documents demandés (voir ci-dessous) ;
  • modification de la configuration de déploiement : (1) client (lourd/léger) distant, (2) base de données externe (MySQL, Oracle, HSQL ...) et éventuellement distante ;
  • ajout éventuel de fonctionnalités non prioritaires.

Une présentation d'une mini-maquette d'interface web aura lieu au milieu de l'étape n°2.

Remarque : Aucune des phases du projet ne nécessite le développement d'un client lourd en mode graphique (SWT ...).

Documents demandés

Deux rapports doivent être rédigés pour la partie Système : un document de conception système et un document d'évaluation système.

Document de conception système

Le dossier de conception système (DCS) a pour but de permettre à toute personne de connaitre les principaux composants JEE de votre application ECOM. Cette connaissance doit pouvoir être acquise rapidement, sans avoir à entrer dans les détails de l'implémentation. Le DCS doit donc être de taille relativement limitée (5 à 10 pages, 20 pages au grand maximum). Le DCS est centré sur un schéma d'architecture système (SAS) : ce schéma doit faire apparaître les composants qui vont constituer l'application, ainsi que les liens entre les beans. Un lien depuis un composant A vers un (ou plusieurs) composant(s) B signifie qu'une interaction peut avoir lieu depuis A vers B. Un lien peut être monovalué ou multivalué, monodirectionnel ou multidirectionnel.

Pour chaque composant et lien du SAS, le DCS doit fournir :

  • Une description fonctionnelle : La description fonctionnelle d'un composant fait apparaître les attributs qui le composent, ainsi que les méthodes qu'il fournit. Attributs et méthodes seront associés à une courte description. Les besoins liées à la persistence ou aux aspects transactionnels peuvent également être explicités.
  • Une description d'implantation JEE : La description d'implantation décrit l'implantation du composant ou du lien dans l'environnement JEE. Un composant peut être implanté par un programme Java externe (client léger / client lourd JEE), par un servlet, par un bean ou par un objet POJO. Dans ces derniers cas, il faut préciser les caractéristiques des beans / POJO (local / distribué, session / évenementiel, stateful / stateless, etc). Un lien peut être implanté par une relation JEE, ou bien par conservation de référence de bean.

Document d'évaluation système

Le rapport final système du projet ECOM a pour but de préciser l’état d’avancement de votre application ECOM.

Le rapport final système doit préciser :

  • L’état de chaque composant : non réalisé, réalisé, réalisé et validé
  • Les fonctions réalisées, réalisées et testées, et celles restant à réaliser
  • Les propriétés non fonctionnelles garanties par votre réalisation, et celles restant à considérer pour finaliser votre application
  • Le temps consacré à la conception système
  • Le temps consacré au développement système
  • Les principales difficultés rencontrées

Critères d'évaluation

La partie système du projet sera principalement évaluée en fonction des critères suivants :

  • Conformité aux spécifications de l'application et aux consignes données dans le cadre du projet
  • Respect des échéances pour les différentes étapes du projet (y compris pour les prototypes intermédiaires et les documents)
  • Qualité de l'architecture de l'application
  • Qualité et robustesse du code applicatif
  • Compréhension des principaux concepts de la technologie JEE
  • Rigueur de la démarche de conception
  • Qualité des présentations/soutenances

En complément, les aspects suivants seront également considérés :

  • Méthodologie de test
  • Performances (résultat du injection de charge avec JMeter ou Clif)
  • Utilisation (optionnelle) de technologies/APIs/frameworks avancés

Consignes pour la soutenance

Consignes spécifiques pour les soutenances IHM

  • documents (version papier) à apporter : cahier des charges (version finale), dossier de conception IHM, dossier d'évaluation IHM
  • votre passage doit contenir une présentation globale du projet, le processus de conception (illustré), le bilan (point de vue IHM) et une démo PRÉPARÉE
  • arrivez avec l'application démarée (on ne perd pas de temps) et 1 ou 2 scénarios (de test)
  • prévoyez 5 minutes de questions lors de votre passage

Consignes spécifiques pour les soutenances Système

  • Apportez un exemplaire du dossier d'évaluation système (déposé la veille sur Moodle) lors de la soutenance. Il n'est pas nécessaire d'apporter un exemplaire du dossier de conception système.
  • Préparez vous 30 minutes avant votre soutenance pour démarrer les instances Windows Azure avec le service développé.
  • Prévovez environ 30 minutes pour la présentation/démo/questions. Utilisez des transparents pour présenter votre projet.
  • Les démonstrations peuvent être faites sur vos machines personnelles cependant le service eCOM doit IMPERATIVEMENT s'exécuter sur une ou plusieurs instances Windows Azure.
  • Conditionnez le projet final sous la forme d’une archive (zip ou tar.gz) après avoir inclus la documentation (dans un repertoire /main/site). Utilisez la convention de nommage suivante : ecom_final_1213-X.zip où X correspond au nom du projet.
  • Déposez immédiatement après la soutenance (et en aucun cas après le 20 décembre) l'archive sur Moodle.
  • le rapport de charge (benchmark) doit être (MUST) fourni dans la documentation.
  • le rapport sur les métriques logicielles doit être (MUST) fourni dans la documentation.

Organisation 2013-2014

EN COURS DE CONSTRUCTION

Planning

M2PGI Apprenti

Equipe pédagogique: Noël de Palma (NdP), Sybille Caffiau (SC), Didier Donsez (DD), Sebastien Chassand-Barrioz (SCB), Fy RAVOAJANAHARY (FR)

Dates Importantes:

  • Démo système V1 classique : jeudi 25 octobre
  • Démo système V2 classique : jeudi 29 novembre
  • Semaine bloquée : lundi 17 décembre - vendredi 21 décembre
  • Soutenances (IHM + système) : vendredi 21 décembre
  • Remise du cahier des charges : vendredi 14 décembre (version electronique (pdf) à SC et NdP, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier de conception IHM : vendredi 14 décembre (version electronique (pdf) à SC, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier d'évaluation IHM : jeudi 20 décembre (lors de votre passage)
  • Remise du dossier de conception système : vendredi 14 décembre (version electronique (pdf) à NdP, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier d'évaluation système : jeudi 20 décembre (lors de votre passage)

M2PGI Classique

Equipe pédagogique: Noël de Palma (NdP), Sybille Caffiau (SC), Didier Donsez (DD), Sebastien Chassand-Barrioz (SCB), Fy RAVOAJANAHARY (FR)

Dates Importantes:

  • Démo système V1 classique : jeudi 25 octobre
  • Démo système V2 classique : jeudi 29 novembre
  • Semaine bloquée : lundi 17 décembre - vendredi 21 décembre
  • Soutenances (IHM + système) : vendredi 21 décembre
  • Remise du cahier des charges : vendredi 14 décembre (version electronique (pdf) à SC et NdP, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier de conception IHM : vendredi 14 décembre (version electronique (pdf) à SC, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier d'évaluation IHM : jeudi 20 décembre (lors de votre passage)
  • Remise du dossier de conception système : vendredi 14 décembre (version electronique (pdf) à NdP, avec "[M2PGI-ECOM]" dans le sujet)
  • Remise du dossier d'évaluation système : jeudi 20 décembre (lors de votre passage)

RICM5

Equipe pédagogique: ??? (XE), Sybille Caffiau (SC), Didier Donsez (DD)

Dates Importantes:

  • Démo système V1 : ??
  • Démo système V2 : ??
  • Soutenances (IHM + système) : ??/12/2012 après midi
  • Remise du cahier des charges : 08/10/2012 (moodle)
  • Remise du dossier de conception IHM : 12/12/2013 (version electronique (pdf) à SC, avec "[RICM-ECOM]" dans le sujet)
  • Remise du dossier d'évaluation IHM : 19/12/2013 (lors de votre passage)
  • Remise du dossier de conception système : 19/12/2013 (version electronique (pdf) à XS)
  • Remise du dossier d'évaluation système : 19/12/2013 (version electronique (pdf) à XS)


Séances:

  • 13/09 Ma: Introduction 1H00 DD, CM Ergonomie 2H00 SC Media:PresentationECOM-RICM5-2013.pdf
  • 24/09 Ma: CM JavaEE & EJB 3h00 XX
  • 24/09 Ap: TD Ergonomie IHM 3h00 SC
  • 01/10 Ma: CM Ergonomie IHM 3h00 SC
  • 01/10 Ap: Install JavaEE, tutoriel EJB 3h00 XX
  • 08/10 Ma: CM HTTP & Servlet/JSP 3h00 DD
  • 08/10 Ap: TD Ergonomie IHM 1h30 SC, Tutoriel EJB 2h00 XX
  • 22/10 Ma: CM JSF 3h00 XX
  • 22/10 Ap: Tutoriel Servlet/JSP/JSF 3h00 XX
  • 05/11 Ma: TD Ergo IHM 3H00 SC
  • 12/11 Ma: TD JavaEE 3H00 XX
  • 19/11 Ma: TD JavaEE 3H00 XX
  • 19/11 Ap: En parallele : TD JavaEE 3H00 XX + TD Ergo IHM 3H00 SC
  • 26/11 Ma: TD JavaEE 3H00 XS
  • 26/11 Ap: En parallele : TD JavaEE 3H00 XS + TD Ergo IHM 3H00 SC
  • 03/12 Ma: En parallele : TD JavaEE 3H00 XX + TD Ergo IHM 3H00 SC
  • 03/12 Ap: En parallele : TD JavaEE 3H00 XX + TD Ergo IHM 3H00 SC
  • 10/12 Ma: TD JavaEE 3H00 XX
  • 17/12 Ma: En parallele : TD Ergo IHM 3H00 SC + TD JavaEE 3H00 XX
  • Soutenance IHM le ??/12/2013 Ap
  • Soutenance Système le ??/12/2013 Ap

Groupes

M2PGI Apprenti

M2PGI Classique

RICM5

Groupe 1 : Thème = Vente de fichiers STL pour imprimantes 3D

  • Nicolas Afonso : Chef de projet
  • Jean-François Bianco
  • Elisa Martinez
  • Rebecca Poustis

Groupe 2 : Thème = Vente de forfaits mobile

  • LARTIGUE Pierre : Chef de projet
  • LEMOINE Jonathan
  • HUSSON Nicolas

Groupe 3 : Thème XYZ

  • XY : Chef de projet
  • XY : Membre (Outils, Forge ou Azure)
  • XY : ...

Groupe 4 : Thème XYZ

  • XY : Chef de projet
  • XY : Membre (Outils, Forge ou Azure)
  • XY : ...

Groupe 5 : Thème XYZ

  • XY : Chef de projet
  • XY : Membre (Outils, Forge ou Azure)
  • XY : ...

Soutenance

M2PGI Apprenti

M2PGI Classique

RICM5

IMPERATIF

  • le projet doit être (MUST) géré selon la méthode Scrum : le Scrum Master devra présenter le déroulement du projet.
  • le serveur JavaEE doit être (MUST) hébergé sur une instance Windows Azure à partir du compte étudiant Azure offert gratuitement en début de projet (la machine virtuelle peut etre de type Windows ou Linux).
  • un rapport de charge (benchmark) doit être (MUST) fourni : les outils JMeter ou Clif peuvent être utilisés.
  • un rapport sur les métriques logicielles doit être (MUST) fourni : l'outil Sonar peut être utilisé.


Ordre de passage :

  • Respectez l'ordre établi
  • Faites attention au temps. Vous disposez de 15 minutes par soutenance pour : votre présentation, la démo et les questions

File:OrdrePassageSoutenance2013.jpg

ATTENTION : Si vous voulez modifier ce planning, vous devez :

  • trouver un autre groupe avec qui échanger
  • vous assurer que tous les membres de ce groupe acceptent l'échange
  • envoyer un mail à SC et XS pour informer du changement (avec le chef de projet de l'autre groupe en copie)

Aucune modification ne sera acceptée après le 18 décembre.

Documentation

Transparents de cours

  • Cours JEE/EJB(NDP) Media:EJB-ECOM2010.pdf
  • Cours IHM (SC) : url
  • Cours JSF (PR) : url
  • Cours maven (DD) : url
  • Cours versionning (DD) : url
  • Cours subversion (DD) : url
  • Cours forge (DD) : url
  • Cours http (DD) : url
  • Cours servlet (DD) : url

Squelette du projet

ecom-maven.zip Inaccessible

Doc utiles

http://proton.inrialpes.fr/~depalma/ecom/liens/liens.html

Quelques livres

REMARQUE: les livres sur JavaEE se periment très vite avec l'évolution de la spécification