Difference between revisions of "ECOM-1FO"

From air
Jump to navigation Jump to search
Line 272: Line 272:
 
* Votre code source doit être accessible en ligne avec un lien depuis votre fiche de suivi sur le wiki.
  
* Votre code source doit être accessible en ligne avec un lien depuis votre fiche de suivi sur le wiki.
 
* Le dossier de conception système et le dossier d'évaluation doivent aussi être disponibles depuis votre page wiki. (Ils peuvent si vous le souhaiter être directement édités sur le wiki)
 
* Le dossier de conception système et le dossier d'évaluation doivent aussi être disponibles depuis votre page wiki. (Ils peuvent si vous le souhaiter être directement édités sur le wiki)
  +
* Le rapport de charge (benchmark) doit être (MUST) disponible sur le wiki.
 
* Le rapport sur les métriques logicielles doit être (MUST) disponible sur le wiki.
  
* Le rapport sur les métriques logicielles doit être (MUST) disponible sur le wiki.
 
* Préparez vous 30 minutes avant votre soutenance pour démarrer les instances Windows Azure (ou autre plateforme de Cloud de votre choix) avec le service développé.
  
* Préparez vous 30 minutes avant votre soutenance pour démarrer les instances Windows Azure (ou autre plateforme de Cloud de votre choix) avec le service développé.

Revision as of 18:02, 8 December 2015

Le projet eCOM consiste à concevoir et développer une application de commerce électronique. suite ...

Étapes du projet ECOM

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).

Media:PresentationECOM-Seance1Modif.pdf

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. Néanmoins, vous pouvez inspirer de la méthode Lean Startup pour livrer rapidement votre application.

Choix des sujets

Vous devez choisir le domaine d'application dans lequel vas s'inscrire votre projet. Des sujets sont interdits :

  • les sites de ventes de livres, CD, chaussures, alcool
  • les sites pornographiques

Votre projet ne doit pas nécessairement être un site commercial mais doit respecter les contraintes a respecter sont :

  • gestion de compte utilisateur (login propriétaire ou login OAuth)
  • envoi de mails
  • une transaction (transactions ACID) avec retours en arrière possible
  • (May)accès aux ressources externes

Ce sujet doit être validé par vos enseignants dès le premier jour du projet. Envoyez une description dans un corps de mail à Didier Donsez et Sybille Caffiau. Cette description doit contenir :

  • les membres du projet
  • le nom du chef de projet
  • le nom du scrum master
  • les rôles envisagés par chaque membre
  • le titre du sujet
  • un paragraphe descriptif du sujet dans lequel est particulièrement explicité l'adéquation du sujet et les requis ci-dessus

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".

PokerPlanningECOM2013

Partie IHM

Etapes et documents demandés

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.

Critères d'évaluation

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

  • Conformité de l'IHM 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
  • Explication des choix de conception faits
  • Intégration des retours de tests utilisateur

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 ; adaptative (utilisation des Media Queries de CSS);
  • 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 ...).

Troisième étape

La troisième étape consiste à ajouter au prototype précédent les fonctionnalités suivantes :

  • Interface CLI ou Shell pour l'administration et le bulk loading (initialisation du catalogue du service, l'ajout de nouveaux produits). Vous pouvez utiliser l'interface EJB facade directement ou bien une interface RESTful.
  • Gestion de l'internationalisation (i18n) des applications web et mobiles. Remarque : vous pouvez utiliser les principes et outils appris dans l'UE Communication Langagière.
  • Gestion de la confidentialité avec SSL/TLS lors des phases de login, signin, et de paiement
  • Gestion de la concurrence et de la reprise sur panne avec des transactions ACID
  • Gestion asynchrone et transactionnelle de l'envoi des courriels via JMS et des EJBTimer (voir http://ecom.ow2.org/xwiki/bin/view/Main/fremail)
  • Performances (résultat du injection de charge avec Apache JMeter, Gatling, OW2 CLIF)
  • Déploiement de l'application eCOM distribuée sur plusieurs VM CoreOS ou Ubuntu Core avec Vagrant et VirtualBox, Azure, Amazon EC2, Google's Compute Engine ...

De façon facultative, vous pourrez ajouter au prototype précédent quelques unes des fonctionnalités suivantes :

Remarque: les fonctionnalités sont assez indépendantes du noyau du projet : elles peuvent être mis en place dès le départ de l'étape 1.

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. Ces documents doivent être accessibles depuis le wiki (ils peuvent même être directement édités sur le wiki).

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 :

  • Outils collaboratifs
  • Méthodologies de test (unitaire, intégration, performance)
  • Intégration en continue
  • Livraison en continue
  • Utilisation (optionnelle) de technologies/APIs/frameworks avancés

Remarques Importantes

NE COMMITEZ JAMAIS vos credentials Cloud (AWS, Azure, ...) DANS UN DEPOT PUBLIC !!!!!

Votre compte serait utilisé pour créer plusieurs centaines de VMs et vous serez lourdement facturés (bitcoins, DDoD, ...) !

Planning 2015

Equipe pédagogique: Sybille Caffiau (SC), Didier Donsez (DD), Thomas Ropars (TR)

Dates Importantes:

  • Dépôt en ligne sur le wiki des livrables d'étape (Questionnaire et son analyse, Maquettes, SRS, Diagramme UML et Modèle de tâches, Scrum (waffle ou autre), Journal, lien vers le dépôt Git) : 19/10 Minuit
  • Soutenance Conception (IHM + système) : 20/10 (après-midi à CONFIRMER)
  • Dépôt en ligne sur le wiki des livrables d'étape (Documents modifiés, Scrum (waffle ou autre), Journal, Evaluation utilisateur, Métriques logiciels et performance) : 14/12 Minuit
  • Soutenance Finale (IHM + système) : 15/12

Séances: (Voir sur ADE)

  • 08/09 08H00-11H15: Introduction 1H00 (DD), CM Définition des besoins 2H00 (SC)
  • 29/09 08H00-11H15: CM HTTP & Servlets/JSP 3h00 (DD)
  • 29/09 13H30-16H45: Tutoriel EJB, Tutoriel Servlet/JSP/REST/WS 3h00 (DD)
  • 06/10 08H00-11H15: TD Besoins utilisateur (SC)
  • 06/10 13H30-16H45: CM Conception IHM 1H00 (SC), TD Conception IHM 2H00 (SC)
  • 20/10 08H00-11H15: Permanence Système (DD) + IHM (SC)
  • 20/10 13H30-16H45: Soutenance Conception Système (DD) + IHM (SC)
  • 03/11 08H00-11H15: Journée Polytech Pro
  • 09/11 16h30-18h30: Permanence Système (TR)
  • 10/11 08H00-11H15: CM Evaluation utilisateur (1H00) + Travail en autonomie (2H)
  • 17/11 08H00-11H15: Permanence Système (TR) + IHM (SC)
  • 24/11 08H00-11H15: Permanence Système (TR) + IHM (SC)
  • 24/11 13H30-16H45: Permanence Système (TR) + IHM (SC)
  • 01/12 08H00-11H15: Permanence Système (TR) + IHM (SC)
  • 08/12 08H00-11H15: Permanence Système (TR) + IHM (SC)
  • 15/12 13H30-16H45: Soutenances

Groupes eCOM-RICM 2015-2016

Les groupes sont imposés par les enseignants.

Soutenances

IMPERATIFS

  • 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é.


Deux soutenances sont prévues : - soutenance de conception le 20 Octobre 2015 - soutenance de fin de projet le 15 Décembre 2015 Dans les deux cas, les soutenances doivent présenter les parties GL, Système et IHM.

Soutenance de conception : Vous devez présenter les étapes de conception réalisées et les résultats (choix techniques…). De plus, nous vous rappelons que pour le lundi minuit, vous devez avoir rendu accessibles les livrables.

Contenu attendu dans votre présentation(à avoir au minimum dans vos slides) :

Pour la partie GL

  • Organisation de l'équipe (roles, ...)
  • Méthodologie de travail
  • Planning (envisagé)

Pour la partie Système

  • Architecture systeme du service
  • Nombre de Beans (diagramme de classe, type, ...)
  • Extensions réalisées et envisagées
  • Etat d'avancement dans les développements

Pour la partie IHM

  • Résultats de l’analyse de l’existant
  • Utilisateurs cibles, contexte d’utilisation et objectifs utilisateurs (ie objectifs de l’IHM)
  • Maquettes de la v0 et squelette du site (pour la plateforme cible)

Ordre de passage :

Respectez l'ordre établi Faites attention au temps. Vous disposez de 30 minutes par soutenance pour : votre présentation et les questions

  • 13h30 - Groupe 2 : Site de vente de stickers personnalisés
  • 14h05 - Groupe 1 : Site de vente de sushis
  • 14h40 - Groupe 5 : Site de restauration personnalisée
  • 15h15 - Groupe 4 : ???
  • 15h50 - Groupe 3 : Pixel-Shirt


Soutenance de fin de projet :

Consignes spécifiques pour les soutenances IHM

Durée totale : 20 minutes

  • votre passage doit contenir une présentation globale du projet, le processus de conception (illustré), des évaluations, 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
  • à apporter sur clés : tous les documents numérisés produits (ppt des audits, scan des maquettes papier...)

Consignes spécifiques pour les soutenances Système

  • Remplissez et apportez une version papier de la fiche d'évaluation suivante Media:FicheEval20142015-GROUPE-THEME.doc
  • Votre code source doit être accessible en ligne avec un lien depuis votre fiche de suivi sur le wiki.
  • Le dossier de conception système et le dossier d'évaluation doivent aussi être disponibles depuis votre page wiki. (Ils peuvent si vous le souhaiter être directement édités sur le wiki)
  • Le rapport de charge (benchmark) doit être (MUST) disponible sur le wiki.
  • Le rapport sur les métriques logicielles doit être (MUST) disponible sur le wiki.
  • Préparez vous 30 minutes avant votre soutenance pour démarrer les instances Windows Azure (ou autre plateforme de Cloud de votre choix) avec le service développé.
  • 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 de machines virtuelles sur le Cloud de votre choix


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

A DEFINIR

ATTENTION : Si vous voulez modifier l'un des plannings, 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 DD pour informer du changement (avec le chef de projet de l'autre groupe en copie)

Les modifications ne sont acceptées que jusqu'au dimanche précédent la soutenance.

Documentation

Transparents de cours

Doc utiles

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

Quelques livres et technologies

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

JavaEE

REST

Web

Responsive Web Design

AngularJS

Bootstrap

Ember

Tests unitaires

Intégration en Continue

Misc

Questionnaires pour les sites web

Questionnaire SUS (évaluation de la satisfaction)

[1]

Retrieved from "https://air.imag.fr/index.php?title=ECOM-1FO&oldid=25367"