ECOM-1FO

From air
Jump to navigation Jump to search

Le projet eCOM consiste à concevoir et développer une application d’échange en ligne (commerce électronique, échanges de services…). suite ...

Organisation

Aide à la lecture du document

Acronymes

Les enseignants :

  • DD : Didier Donsez (didier.donsez@imag.fr)
  • SC : Sybille Caffiau (sybille.caffiau@imag.fr)
  • VZ : Vincent Zurczak (vzurczak@linagora.com)

Les réalisations :

  • DCS : Dossier de Conception Système
  • SAS : Schéma d'Architecture Système

Autres :

  • ADE : Emploi du temps en ligne

Groupes et sujets

Groupes eCOM-RICM 2018-2019

Les groupes sont imposés par les enseignants et seront donnés lors de la première séance. Ils ne seront définitifs que le mardi 18/09 à 8h.

Groupes eCOM-RICM Années précédentes

Planning des séances

La partie IHM et la partie Système sont menées en parallèle pendant toute la durée du projet. Pendant toutes les séances vous travaillerez en groupe, il est donc obligatoire pour tous les étudiants d'être présents à toutes les séances. Celles-ci sont composées :

  • du cours (CM)
  • du travail encadré (TD) : séance pendant lequel l'enseignant vous accompagnera pour la réalisation d'une étape de votre projet
  • du travail en autonomie : séance réservée au travail d'ECOM pendant laquelle vous travaillez entre étudiants
  • de permanences : séances pendant lesquelles vous pouvez demander l'aide d'un enseignant pour vous aidez à avancer. Ces séances sont également l'occasion pour vos enseignants de faire le point avec vous sur votre avancé, vous devez donc IMPERATIVEMENT signaler votre lieu de travail si vous n'êtes pas dans les salles prévues par ADE (par email à SC et VZ).

An cas d’incohérence de planning avec ADE ; suivre ADE.

  • 18/09 8h00-12h15 : Introduction 1h00(DD+SC) (transparents), CM REST, MicroServices, Spring, JHipster (DD) (P005)
  • 18/09 15h45-18h30 : (DD) Installation JHipster et Docker. Génération de l'application MVP de eCOM, lancement du profile dev, lancement du profil prod (avec Docker), analyse de qualité du code (généré) avec le container SonarQube et déploiement sur Heroku de 2 applications (stage, production) (F214, F215).
  • 25/09 8h00-12h15 : Des scénarios aux spécifications IHM (SC) (P257)
  • 25/09 15h45-18h30 : Séance en autonomie (F114, F214)
  • 02/10 8h00-12h15 : Test utilisateur (SC) puis Séance en autonomie (P039)
  • 02/10 15h45-18h30 : Séance en autonomie (F214, F215)
  • 09/10 8h00-12h15 : Audit 1 (P013) et Séance en autonomie (P105, P133)
  • 09/10 15h45-18h30 : Tests de robustesse (charges) (VZ) (F114, F214)
  • 16/10 8h00-12h15 : Séance en autonomie (P257)
  • 16/10 15h45-18h30 : Séance encadrée (SC) (F214, F215)
  • 23/10 8h00-12h15 : Séance encadrée (VZ) (P257)
  • 23/10 15h45-18h30 : Séance en autonomie (F214, F215)
  • 06/11 8h00-12h15 : Audit 2 (F114) et Séance en autonomie (F202)
  • 06/11 15h45-18h30 : Séance en autonomie (F214, F215)
  • 20/11 8h00-12h15 : Séance en autonomie + Séance encadrée (SC) (P257)
  • 20/11 15h45-18h30 : Séance encadrée (VZ) (F214, F215)
  • 27/11 8h00-12h15 : Séance en autonomie (P257)
  • 27/11 15h45-18h30 : Séance encadrée (VZ) (F214, F215)
  • 04/12 8h00-12h15 : Séance encadrée (VZ) (P257)
  • 04/12 15h45-18h30 : Séance en autonomie (F214, F215)
  • 11/12 8h00-12h15 : Séance encadrée (VZ) (P257)
  • 11/12 15h45-18h30 : Séance en autonomie (F214, F215)
  • 18/12 8h00-12h15 : Soutenances (F114) et rendus finaux
  • 18/12 15h45-18h30 : Soutenances (F114) et rendus finaux

Modalités d’évaluation

La note d’ECOM est obtenue par l’addition de notes obtenues tout au long de la réalisation du projet, elle peut être différente pour chaque membre du groupe en fonction du travail fourni et constaté par les enseignants. Attention : elle repose sur la qualité du travail fourni autant que sur la quantité.

  • présentation soutenance conception (3 pts) : note affectée sur la présentation (qualité des slides, discours...), les réponses aux questions
  • présentation soutenance finale (3 pts) : note affectée sur la présentation (qualité des slides, discours...), les réponses aux questions
  • conception (5 pts) : note obtenue à partir des livrables de conception, de la prise en compte des remarques faites par les enseignants pendant la soutenance de conception, du travail fourni (et observé) et du contenu de la soutenance de conception
  • développement (5 pts) : note obtenue à partir de la qualité et quantité du code réalisé, la démo de la soutenance finale. En particulier, seront observés, la qualité de l'architecture de l'application, la qualité et robustesse du code et la mise en place des principaux concepts de la technologie Spring Boot / JHipster.
  • suivi de projet (4 pts) : cette note est obtenue par rapport aux livrables (qualité, livraison dans les délais...), la mise en place et bonne utilisation des outils collaboratifs, l'intégration continue, Livraison en continue sur plusieurs VM dans un cloud public (AWS, GAE, Heroku, Azure, ...), le contenu de la soutenance finale

Soutenances

Trois soutenances sont prévues (2 audits et 1 soutenance finale) :

  • audit 1 (exigences, besoins client) : le 09 octobre 2017
  • audit 2 (conception) : le 06 novembre 2017
  • soutenance de fin de projet le 18 Décembre 2017

Dans les trois cas, les soutenances doivent présenter les parties GL, Système et IHM. Attention : les concepts que vous avez vus en cours d'architecture doivent être mis en application pour l'architecture de votre projet. Une attention particulière sur ce point doit être portée lors de vos présentations à l'audit 2 et à la soutenance. Le travail que vous présenterez fournira de support à l'évaluation du module de GL.

Audit 1

  • Salle : P
  • Durée totale : 30 min par groupe (max 20 minutes de présentation et ensuite les questions des enseignants représentant les clients)
  • Utilisez des transparents pour présenter votre projet.
  • ordre de passage :

- 8h35 : Restaurant

- 9h10 : Spectacle

- 9h45 : Camping

- 10h20 : Transport

- 10h55 : Sport

- 11h30 : Brule ta bûche

Contenu :

Pour la partie GL et gestion de projet

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

Besoins pour clients, avec en particulier (mais non exhaustive) :

  • Résultats de l’analyse de l’existant
  • Utilisateurs cibles, contexte d’utilisation et objectifs utilisateurs (ie objectifs de l’IHM)

Audit 2

  • Salle : P
  • Durée totale : 25 min
  • Utilisez des transparents pour présenter votre projet.


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 dimanche minuit, vous devez avoir rendu accessibles les livrables.

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

Pour la partie GL et gestion de projet :

  • Organisation de l'équipe (roles, ...)
  • Méthodologie de travail
  • Planning (modifications par rapport à ce que vous aviez prévu jusqu'à maintenant et le planning futur)
  • Architecture complète
  • Procédure de tests
  • Procédure d'intégration du code

Pour la partie Système

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

Pour la partie IHM

  • Maquettes et squelette du site (pour la plateforme cible)
  • Charte graphique

Une démonstration (rapide) de votre application telle qu'elle est (v0 ou v1 en fonction des groupes)

Ordre de passage :

- groupe 6 :

- groupe 1 :

- groupe 5 :

- groupe 2 :

- groupe 4 :

- groupe 3 :

Respectez l'ordre établi. Faites attention au temps. Vous disposez de 25 minutes par soutenance pour : votre présentation et les questions. Vous devrez gérer le temps. Les remarques (d’amélioration) qui seront faites pendant cette soutenance par les enseignants devront être prises en compte pour la version finale (pris en compte dans la note finale).


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.

Soutenance de fin de projet

  • Salle : P
  • Durée totale : 30 min
  • Utilisez des transparents pour présenter votre projet. Lors de votre passage vous devez présenter une démo PRÉPARÉE.

Arrivez avec l'application démarrée (on ne perd pas de temps) et 1 ou 2 scénarios (de test)

  • 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é.
  • 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
  • Vous devez avoir tous les documents demandés (accessibles en ligne et/ou imprimés)
  • Vous devez fournir au début de votre passage les fiches d'auto-évaluation complétées (version papier)

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

  • une présentation globale du projet
  • le processus de conception (illustré avec vos différentes productions)
  • la démonstration de votre application
  • des évaluations
  • le bilan (pédagogique ET du projet/individuel ET groupe)
  • le temps consacré à la conception
  • le temps consacré au développement
  • les principales difficultés rencontrées


Ordre de passage :

  • groupe 1
  • groupe 3
  • groupe 5
  • groupe 4
  • groupe 6
  • groupe 2

Respectez l'ordre établi. Faites attention au temps. Vous disposez de 30 minutes par soutenance pour : votre présentation et les questions. Au bout de 15 minutes de présentation vous serez interrompus pour être interrogés. Les questions peuvent être posées nominativement (c'est à dire que la personne qui doit répondre est désignée par l'enseignant).



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, DD et VZ pour demande d'accord 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.

Livrables

Tout votre projet doit être suivi grâce à gitLab.

A tout moment, les enseignants doivent donc pouvoir

  • avoir la dernière version du code (dernière version du logiciel en production et ce qui est en cours de développement dans des branches dédiées)
  • voir les tâches prévues/en cours/réalisées
  • savoir le travail de chaque membre (effectué et assigné)
  • consulter les documents de conception (à jour)
  • consulter les CR des daily meeting et autres réunions et les rétrospectives et vos présentations aux différents audits
  • avoir connaissance des procédures de qualité que vous mettez en place au sein de votre projet
  • consulter les résultats des différents tests pour chaque release

Attention : nous insistons particulièrement sur le fait que toutes ces données doivent être maintenues en temps réel et accessibles sur le gitlab de votre projet.

Attention : nous consulterons également les messages de commit.


Rendus

Vous trouverez ci-dessous une liste (non exhaustive) de certains livrables pouvant être produits au sein de votre projet

L1. Composition des groupes et sujet. (obligatoire) Le sujet doit être validé par vos enseignants dès le premier jour du projet. Envoyez une description dans un corps de mail à DD et SC. 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 (quelques lignes)

L2. Dossier de conception Système. Le Dossier de Conception Système (DCS) a pour but de permettre à toute personne de connaitre les principaux composants Spring 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). 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 Spring : La description d'implantation décrit l'implantation du composant ou du lien dans l'environnement Spring. Un composant peut être implanté par un client généré à partir de l'interface de/des micro-services, par un micro-service REST (Controller), par un Service, par un Entity ou par un client Feign vers un micro-service externe au systeme (par exemple, service de paiement Swipe.com, ...).

Le dossier de conception système doit être disponibles depuis votre page wiki.

L3. Analyse des besoins. Questionnaire et son analyse pour définir les besoins utilisateurs que doit satisfaire votre application.

L4.Maquette.

L5.SRS.

L6.Diagramme UML.

L7.Modèle de tâches.

L8.Scrum (tableau de tâches de Gitlab).

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

L9.Journal. Détaillez l'affectation des taches effectuées ainsi le temps estimé et le temps effectif pour chaque tache et son état (Réalisée, Reportée, Abandonnée, ...) Le journal doit être nominatif. Chaque membre de projet doit gérer son propre journal. Il fera l'objet d'une évaluation personnelle.

L10.Dépôt Git. Votre code source doit être accessible en ligne avec un lien depuis votre fiche de suivi sur le wiki.

L11.Application en ligne.

L12. Evaluation de l'IHM réalisée. cf cours IHM Media:Cours2015-2016RICM.pdf

Evaluation utilisateur : media:System-Usability-ScaleLogicielComplet.pdf et/ou experte : media:EvalEfficacite.pdf, Media:Annexe1-HeuristiqueNielsen.pdf


L13. Evaluation de la qualité du projet.

  • Nombre de lignes de code (outil CLOC à minima)
  • Métriques de qualité du code (SonarQute, ...)

L14. Evaluation des performances du projet.

  • Résultat d'une injection de charge simpliste avec Gatling
  • Résultat d'une injection de charge suivant un scénario complet avec Gatling

L15. Evaluation économique du projet.

  • Utilisez les temps effectifs des taches renseignées dans le journal.
  • Utilisez le coût du travail d'un ingénieur débutant.
  • Comparez votre coût à l'évaluation COCOMO de votre projet (utiliser les valeurs de L9).


L16. Diapos de votre présentation de conception.

L17. Diapos de votre présentation finale.

L18. Auto evaluation. Système : Media:FicheEval20162017-ECOM.doc

L18. Diapos de votre présentation client.

Réalisations attendues

Conduite et suivi de projet

Le projet eCOM est très court en durée. Vous utiliserez la méthodologie Scrum pour la conduite du projet dans chaque groupe. Vous pouvez vous inspirer de la méthode Lean Startup pour livrer rapidement votre application. Vous devez choisir un Scrum Master (unique ou tournant) : justifiez votre choix et la durée du sprint (justifiez votre choix). Vous devez prévoir :

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

Pensez à utiliser un outil adapté cela doit être une documentation Agile !!!!

(May) mettre en place des "poker planning"

PokerPlanningECOM2013

Ces 2 premiers critères sont fixes !!!

Selon les principes de la méthodologie Agile, vous devez composer votre travail en fonctionnalités. Chacune fera l’objet d’une conception (système et IHM) et d’un développement. Conception ET développement constituent l’ensemble des réalisations attendues.

Vous devez utiliser GitLab comme support à votre projet (versioning, gestion des tâches...).

Nous vous demandons également d'utiliser les issues pour la communication avec les enseignants. En particulier, toute absence ou télétravail doit être signalé par ce média.

Réalisations système

Conception système

La conception système est composée de deux réalisations principales : le modèle de donnée : 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. le 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.

Développement système

Pour chaque fonctionnalités conçues, le développement système sera réalisé en deux étapes.

Les étapes

Etape 0 : Créer un groupe GitLab. Y ajouter les membres du projet eCOM. Créer plusieurs projets pour les différents parties. Activer les notifications. Ajouter les webhooks utiles.

Etape 1 : La première consiste à définir le cœur de l'application, c'est-à-dire le modèle de données (UML ou similaire JDL) et la logique métier, puis à réaliser un premier prototype qui démontre une bonne maîtrise des Entity (annotations JAX-RS, annotations Swagger).

L'application RESTful est seulement accessible par l'intermédiaire de clients type cUrl (généré avec le générateur swagger-codegen), Swagger UI, injecteur de charge Gatling, ....) et le frontend AngularX que vous aurez généré avec JHipster.

Il n'est pas demandé, de réaliser une interface web pour interagir avec l'application. L'application doit cependant offrir deux modes d’utilisation (administrateur et utilisateurs finaux) et exécuter certaines requêtes avec des garanties transactionnelles.

TRES IMPORTANT : Votre machine virtuelle doit être sécurisée (Security Group et/or UFW/IPtables pour les ports exposés). Evitez de vous faire rançonner comme un binôme de la promo 2016-2017 (voir ci-dessous, la rançon d'une BD MongoDB). 

$ db.PLEASE_READ_ME.find()
{ 
    "_id" : ObjectId("58a7287db7dc324adb249fdf"),
    "info" : "Don't panic. Your DB is in safety and backed up (check logs). 
              To restore send 0.1 BTC and email with your server ip or domain name. Each 48 hours we erase all the data.",
    "amount" : "0.1 BTC",
    "data_we_have" : { 
        "local" : [ "startup_log" ],
        "first_database" : [ "users", "preferences" ],
        "MyAppXXX" : [ "emails" ] 
    }, 
    "Bitcoin Address" : "1NSz9TRBGKHKFdjdjH2Gme3LwDi5", 
    "email" : "xxxxx@xxxx.org" 
}


Etape 2 : La seconde étape consiste à compléter le premier prototype (étape 1) avec les objectifs suivants :

  • Développement d'une interface Web basée sur le modèle MVC (SPA ou non) ;
  • Modification de la configuration de déploiement pour la haute disponibilité (HA) :
  1. Mise en place d'un container base de données externe (MySQL, ...) pour la production (non répliquée)
  2. Mise en place de 2 containers base de données (MySQL) en cluster (réplication)
  3. Mise en place de 2 containers frontends load balancer HAProxy ou Nginx en mode SSL terminaison (instructions)
  4. Génération et rafraichissement des certificats SSL avec Let's Encrypt
  • Amélioration des fonctionnalités. En particulier, considérez les points suivants :
    • Renseignement de la notice relative à la protection de la vie privée.
    • Gestion de la concurrence et de la reprise sur panne avec des transactions ACID
    • 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 des contenus multimedia (photos, videos, docs ...) avec un FileStorageService (lien)
    • Gestion adaptative des contenus multimedia (photos) avec un ThumbnailService (montrez l'amélioration des performances avec Gatling)
    • Gestion du cache client pour les photos et les thumbnails avec Cache-Control et ETag (montrez l'amélioration des performances avec Gatling)
    • Utilisation de mode Lazy pour les chargements (fetch) des collections et des médias (CLOB,BLOB).
    • Génération d'une application mobile Ionic avec generator-jhipster-ionic (inclure les plugins Apache Cordova utiles à votre projet).
    • Utilisation d'un cache (préconisé par JHipster)
  • Ajout éventuel de fonctionnalités non prioritaires. De façon facultative, vous pourrez ajouter au prototype précédent quelques unes des fonctionnalités suivantes :
    • Stockage externalisé des contenus multimedia par des Content Delivery Networks (Amazon S3, Azure, Akamaï ...)
    • Génération de documents PDF à partir des valeurs de champs d'une entité ou du collection d'entités (exemple d'applications : facture, dossard coureur, export RGPD, ...) lien
    • Import et export massifs de collections d'entités en format CSV, JSON.
    • Suivi du click stream avec des Filters/Aspects en vue d'une analyse Big Data avec Spark (Click Analytics, Recommender System).
    • Gestion rudimentaire d'une interface vocale avec un serveur vocal VoiceXML.
    • Utilisation de OAuth2 ou OpenID pour le login et l'accès aux API REST avec Keycloak ou OKTA.
    • Utilisation du service de paiement Stripe.com en mode développeur
    • Chat avec un opérateur du helpdesk (texte et/ou audio avec WebRTC)
    • Chatbot du helpdesk (comme ovh-chatbot)
    • Gestion d'un CaaS Docker privé avec Minikube, Kubernetes, Rancher ou Docker Swarm
    • Traduction automatique et à la volée des champs des produits (nom, description, commentaires et avis) en fonction de la langue de l'usager, au moyen d'un service tiers.
    • Script périodique (crontab) de dump et de backup distant de la base MySQL.
    • Gestion asynchrone et transactionnelle de l'envoi des courriels via le MailService, Thymeleaf et des taches @Scheduled
    • Gestion asynchrone et transactionnelle de l'envoi de SMS (si le destinataire a un compte gratuit pour l'auto-réception de SMS)

Remarque: certaines 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.

Le déploiement en continu

Dès le démarrage, votre projet devra être géré selon les principes du DevOps : chaque version devra être déployé sur votre infrastructure de production en minimum de temps et sans interuption de services. Vous devez mettre en place des procédures de mise à jour des artifacts de l'application en mode rolling update et fast rollback (lien).

Remarques pour la mise en ligne : NE COMMITEZ JAMAIS vos credentials Cloud (AWS, Azure, Google ...) DANS UN DEPOT PUBLIC !!!!!

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

Vous devez obligatoirement mettre en place les points suivants dès le démarrage du projet :

  • Déploiement et retrait de l'application sur/de la plateforme cloud publique ou privée (UFR, Amazon, Azure, Google, Heroku)
  • Performances (résultat du injection de charge avec Apache JMeter ou Gatling) : Astuce: utiliser les images Docker.
  • Reprise sur panne simple et alerte des ops avec Monit (ie relance simple du serveur en cas de "plantage").
  • Script "basique" pour le rolling update des composants répliqués (application, base de données, serveurs de mail, load balancer). Remarque: Kubernetes gère les rolling updates (lien).
  • Script "basique" pour le Fast forward (en cas de panne des composants dernièrement mis à jour).

Vous devez optionnellement mettre en place les points suivants:

Réalisations IHM

Conception

La conception de la partie IHM du projet sera principalement composée :

  • Des mécanismes pour intégrer les besoins des utilisateurs
  • Des modèles (tâches, IHMA)
  • De la charte graphique
  • De l'explication des choix de conception faits

Développement

Vous êtes libres des technologies à utiliser pour le développement de la partie IHM de l'application. Cependant, vous devez être capable de justifier vos choix. La partie IHM doit être distincte du noyau fonctionnel. Les codes de la partie présentation et du contenu de l'IHM doivent également être séparés. Veuillez aux noms que vous attribuerez. Les "zones" définies dans vos IHMA doivent être facilement identifiables dans le code que vous réalisez (ex : ID des DIV).

L'IHM des utilisateurs différents peut être gérée différemment. Par exemple, l'IHM de l'administrateur de l'application peut être une Interface en ligne de commande (pour l'initialisation du catalogue du service, l'ajout de nouveaux produits). Vous pouvez utiliser l'interface EJB facade directement ou bien une interface RESTful en utilisant directement Curl).

Evaluation des IHMs

Une IHM doit être évaluée par au moins deux types d'évaluation (en plus de l'évaluation fonctionnelle) :

  • évaluation experte pour vérifier que les principes fondamentaux d'utilisabilité sont respectés
  • tests utilisateur pour étudier comment vos utilisateurs utilise dans leurs contextes d'utilisation votre interface

Documentation

Transparents de cours

Doc utiles

Quelques livres et technologies

REMARQUE: les livres sur ces technologies se périment très vite.

Spring

JHipster

JavaEE

REST

Web

Responsive Web Design

Bootstrap

Ember

Tests unitaires

Intégration en Continue

Continuous Delivery

Misc

Questionnaires pour les sites web

Evaluations des interfaces

Organisation

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