ECOM-M2PGI: Difference between revisions

From air
Jump to navigation Jump to search
 
(73 intermediate revisions by 2 users not shown)
Line 21: Line 21:


Pensez à créer un wiki qui regroupera l'ensemble de vos documentations. Cela doit être une documentation Agile !!!!
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".
[[File:20121002 141359.jpg|center|400px|PokerPlanningECOM2013]]


==Partie IHM==
==Partie IHM==


===Etapes et documents demandés===
===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. Liste des Livrables et date de rendu pour les M2PGI Alternants :
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.

* Livrable 1 : par email, membres du groupe et brève description du sujet (un seul groupe OK)

====[[Audit 1 :]]====
* L2.1 : Description des profils
* L2.2 : Questionnaire profils (OPT-ALT)
* L3.1 : Scénarios
* L3.2 : Analyse de la concurrence (OPT-ALT)
* L3.3 : Questionnaire sur l'utilisation (OPT-ALT)
* L4 : Modèles de tâches (Audit 2 pour ALT)
* L5 : Fonctionnalités
* L6.1 : Objectifs pour chaque version (priorités de développement)

====[[Audit 2 :]]====
* Mise à jour de L2 à L6.1
* L7.1 : Architecture (OPT-ALT)
* L7.2 : Base de données (OPT-ALT)
* L7.3 : IHM Abstraite
* L7.4 : Maquettes
* L6.2 : Objectifs pour les versions suivantes
* L8 : Démo de V0

====[[Audit 3 (Soutenances) :]]====
* Mise à jour de L7.3 (correction des erreurs)
* L9 : Rapport d'évaluation experte (imprimé pour la soutenance)
* L10 : Rapport d'évaluation par expérimentation (imprimé pour la soutenance)
* L11 : Démonstration finale
* L12 : Diapos de votre présentation (version numérique à laquelle l'enseignant a accès au moment de votre passage)

OPT signifie que le livrable est optionnel soit parce qu'il ne s'applique pas à tous les groupes, soit parce qu'il ne peut qu'apporter une plus value à votre projet (points en plus mais pas en moins au moment de l'attribution de la note).
Lorsque ce n'est pas précisé, c'est à vous de choisir le mode présentation (écrit, schéma...) des informations du livrable


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===
===Critères d'évaluation===
La partie IHM du projet sera principalement évaluée en fonction des critères suivants :
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
* Conformité de l'IHM concrète et abstraite avec le modèle de tâches
* Couverture fonctionnelle de l'application et robustesse au regard des priorités que vous avez retenues
* 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
* Qualité ergonomique au regard des principes vus en cours
* Rigueur de la démarche
* Rigueur de la démarche


La note est obtenue par l'évaluation tout au long du projet elle est composée de :
==Partie Système==
* Les besoins (3 pts) : informations sur les besoins que vous allez prendre en compte (livrables et audit 1)
La partie Système est axée sur deux étapes successives.
* La conception (5 pts) : proposition de solution pour répondre aux besoins (livrables et audit 2)
===Première étape===
* L'évaluation (3 pts) : évaluation de votre (ou vos) solution(s) (livrable et soutenance finale)
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).
* Présentations (3 pts) : qualité des présentations (documents, email et slides de soutenance finale)
* Développement (6 pts) : qualité et quantité du code (démo et code)




Les notes des membres du groupe peuvent être différentes en fonction du travail fourni et constaté par l'enseignant.
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.


==Partie Système==

À 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 ...).
Remarque : Aucune des phases du projet ne nécessite le développement d'un client lourd en mode graphique (SWT ...).
Line 72: Line 82:


====Document de conception 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 dossier de conception système (DCS) a pour but de permettre à toute personne de connaitre les principaux composants 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.
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====
====Document d'évaluation système====
Line 96: Line 102:
* Qualité de l'architecture de l'application
* Qualité de l'architecture de l'application
* Qualité et robustesse du code applicatif
* Qualité et robustesse du code applicatif
* Compréhension des principaux concepts de la technologie JEE
* Compréhension des principaux concepts de la technologie Web
* Rigueur de la démarche de conception
* Rigueur de la démarche de conception
* Qualité des présentations/soutenances
* Qualité des présentations/soutenances
En complément, les aspects suivants seront également considérés :
En complément, les aspects suivants seront également considérés :
* Méthodologie de test
* Méthodologie de test
* Déploiement et retrait de l'application sur/de la plateforme cloud (Azure) avec [http://roboconf.net/ Roboconf] ([http://roboconf.net/en/user-guide/lamp-example-part-1.html voir l'exemple avec LAMP])
* Déploiement et retrait de l'application sur/de la plateforme cloud
* Préparation d'images de VMs avec [[Kameleon]]
* Préparation d'images de VMs avec [[Kameleon]]
* Performances (résultat du injection de charge avec [[Apache JMeter]] ou OW2 CLIF)
* Performances (résultat du injection de charge avec [[Apache JMeter]] ou OW2 CLIF)
Line 109: Line 115:
==Consignes pour la soutenance==
==Consignes pour la soutenance==
===Consignes spécifiques pour les soutenances IHM===
===Consignes spécifiques pour les soutenances IHM===
Salle : F113
Durée totale : 20 minutes

* documents (version papier) à apporter : cahier des charges (version finale), dossier de conception IHM, dossier d'évaluation IHM
Durée totale : 45 minutes


Pour le 23/09 minuit au plus tard :
* les documents de conception (hors évaluation), gestion de projet et le code doivent être accessibles à l'enseignant : envoyer un email avec l'ensemble des liens permettant d'y accéder

Le jour de la soutenance :
* envoyé avant votre passage les liens vers les derniers documents (évaluations + diapositives de soutenance)
* 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
* 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
* présentez individuellement un bilan de ce que vous retenez (positif, améliorations personnelles, négatif)
* arrivez avec l'application démarée (on ne perd pas de temps) et 1 ou 2 scénarios (de test)
* 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
* prévoyez 15 minutes de questions lors de votre passage


===Consignes spécifiques pour les soutenances Système===
===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.
* 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éparez vous 30 minutes avant votre soutenance pour démarrer les instances 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.
* 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.
* 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 VM.
* 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.
* 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.
* Déposez immédiatement après la soutenance (et en aucun cas après le 20 décembre) l'archive sur Moodle.
Line 125: Line 140:
* le rapport sur les métriques logicielles doit être (MUST) fourni dans la documentation.
* le rapport sur les métriques logicielles doit être (MUST) fourni dans la documentation.


=Organisation 2015-2016=
=Organisation 2021-2022=


==Planning==
==Planning==
===M2PGI (Alternant)===
===M2PGI (Alternant)===
'''Equipe pédagogique:''' Noël de Palma (NdP), Vincent Lesne (VL), Sybille Caffiau (SC), Sebastien Chassand-Barrioz (SCB), Ibrahim Safiedinne (FR)
'''Equipe pédagogique:''' VL = Vincent Lesne, NDP= Noel De Palma, LP = Laura Pruzco, SCB = Sebastien Chassande


*01 sept 09h-12h F203, Boot Projet +Cours Spring (SCB/NDP)
'''Dates Importantes:'''
*01 sept 14h-17h F203, Cours Spring (SCB/NDP)
*Soutenances (IHM + système) : 9h-17h, le 18 septembre
*02 sept 09h-12h F203, Cours Angular (SCB/NDP)
*Remise du dossier de conception système : le 18 septembre (lors de votre passage)
*02 sept 14h-17h F203, Cours Angular (SCB/NDP)
*Remise du dossier d'évaluation système : le 18 septembre (lors de votre passage)
*03 sept 09h-12h F203, Cours Agile (VL)
*03 sept 14h-17h F203, Cours Agile (VL)
*06 sept 09h-12h F216, Libre Service
*06 sept 14h-17h F203, Cours IHM (LP)
*07 sept 09h-12h F216, Audit Syst. (SCB/NDP)
*07 sept 14h-17h F216, Libre service
*08 sept 09h-12h F216, Libre service
*08 sept 14h-17h F216, Audit Agile (VL)
*09 sept 09h-12h F203, Audit IHM (LP)
*09 sept 14h-17h F216, Libre service
*10 sept 09h-12h F216, Libre Service
*10 sept 14h-17h F216, Libre Service
*13 sept 09h-12h F203, Libre Service
*13 sept 14h-17h F215, Libre Service
*14 sept 09h-12h F203, Audit Agile (VL)
*14 sept 14h-17h F216, Libre Service
*15 sept 09h-12h F216, Audit Syst. (SCB/NDP)
*15 sept 14h-17h F216, Audit IHM (LP)
*16 sept 09h-12h TP F203, Libre Service
*16 sept 14h-17h TP F216, Libre Service
*17 sept 09h-12h F203, Libre Service
*17 sept 14h-17h F216, Libre Service
*20 sept 09h-12h F215, Audit Agile (VL)
*20 sept 14h-17h F215, Libre Service
*21 sept 08h-12h F215, Audit Syst. (SCB/NDP)
*21 sept 13h-17h F215, Libre Service
*22 sept 08h-12h F215, Audit IHM (LP)
*22 sept 13h-17h F215, Libre Service
*23 sept 08h-12h F203, Libre Service
*23 sept 13h-17h F203, Libre Service
*24 sept 08h-12h30 F203, Soutenances système
*24 sept 13h30-17h F216, Soutenances Agile+IHM


===M2PGI (Classique)===
*01 sept 09h-12h F114, Boot Projet/ JEE (NDP)
'''Equipe pédagogique:''' Noël de Palma (NdP), Vincent Lesne (VL), Laura Pruzco (LP), Sebastien Chassand-Barrioz (SCB)
*01 sept 14h-17h F114, Boot Projet/ JEE (NDP)
*02 sept 09h-12h F114, cours Agile (FDJ)
*02 sept 14h-17h F114, cours MVC/JSF/GWT (SCB)
*03 sept 09h-12h F114, cours IHM (SC)
*03 sept 14h-17h F114, cours outils et angular (SCB)
*04 sept 09h-12h Libre service
*04 sept 14h-17h F217, Support Syst. Cl&Alt (NDP)
*07 sept 09h-12h F114, cours Agile (FDJ)
*07 sept 14h-17h F114, cours Cloud (IS)
*08 sept 09h-12h F217, Support Syst. (NDP)
*08 sept 14h-17h Libre Service
*09 sept 09h-12h Support Syst. Cl&Alt (NDP)
*09 sept 14h-17h Libre Service
*10 sept 09h-12h F217, Support Syst. (SCB/IS)
*10 sept 14h-17h Libre Service
*11 sept 09h-12h Libre Service
*11 sept 14h-17h F217, Support Syst. (SCB/IS)
*14 sept 09h-12h F217, Support Syst. (IS/NDP)
*14 sept 14h-17h Libre Service
*15 sept 09h-12h F217, Support Syst. (IS/NDP)
*15 sept 14h-17h Libre Service
*16 sept 09h-12h F217, Support Syst. (IS/NDP)
*16 sept 14h-17h Libre Service
*17 sept 09h-12h F217, Support Syst. (IS/NDP)
*17 sept 14h-17h Libre Service
*18 sept 09h-12h Soutenance F109/F217
*18 sept 14h-17h Soutenance F109/F217


===M2PGI (Classique)===
'''Equipe pédagogique:''' Noël de Palma (NdP), Vincent Lesne (VL), Sybille Caffiau (SC), Sebastien Chassand-Barrioz (SCB), Ibrahim Safiedinne (FR)
'''Dates Importantes:'''
'''Dates Importantes:'''
*TODO
*Soutenances (IHM + système) : 9h-17h, le 19 décembre
*Remise du dossier de conception système : le 15 décembre (version electronique (pdf) à NdP, avec "[M2PGI-ECOM]" dans le sujet)
*Remise du dossier d'évaluation système : le 19 décembre (lors de votre passage)



==Groupes==
==Groupes==
Line 177: Line 193:


===M2PGI Classique===
===M2PGI Classique===
Consigne pour la constitution des groupes : Les étudiants ayant choisis l'option multimobile doivent se mettre ensemble. Ils doivent constituer des groupes de 4/5 afin d'avoir en tout 4 groupes (de M2 PGI classiques)


==Soutenance==
==Soutenance==
Line 183: Line 198:


===M2PGI Classique===
===M2PGI Classique===


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=
=Documentation=
==Transparents de cours==
==Transparents de cours==

* Cours JEE/EJB(NDP) [[Media:EJB-ECOM2010.pdf]]
* Cours JEE tiers presentation (SCB) : [https://dl.dropboxusercontent.com/u/9706615/JEE_tiers_presentation.pdf url]
* Cours GWT (SCB) : [https://dl.dropboxusercontent.com/u/9706615/cours_GWT.pdf url]
* Cours maven (DD) : [http://membres-liglab.imag.fr/donsez/cours/maven.pdf url]
* Cours versionning (DD) : [http://membres-liglab.imag.fr/donsez/cours/version.pdf url]
* Cours subversion (DD) : [http://membres-liglab.imag.fr/donsez/cours/subversion.pdf url]
* Cours forge (DD) : [http://membres-liglab.imag.fr/donsez/cours/forge.pdf url]
* Cours http (DD) : [http://membres-liglab.imag.fr/donsez/cours/http.pdf url]
* Cours servlet (DD) : [http://membres-liglab.imag.fr/donsez/cours/servletjsp.pdf url]
* Cours IHM (SC) : [[Media:Cours2015-2016v3.pdf]]
* Annexe cours IHM (SC) : [[Media:Annexe1-HeuristiqueNielsen.pdf]], [[Media:Annexe2-KMADe.pdf]], [[Media:Annexe3-Placement.pdf]], [[Media:Annexe4-Accessibilité.pdf]]

==Squelette du projet==
[http://dl.dropbox.com/u/66952950/ecom-maven.zip ecom-maven.zip] Inaccessible


==Doc utiles==
==Doc utiles==
* [http://wiki.easybeans.org/xwiki/bin/view/Main/Documentation Documentation Easybeans (conteneur EJB3 utilisé par Jonas)]
* [http://docs.oracle.com/javaee/6/tutorial/doc/ Tutorial JavaEE 6 ]
* [http://netbeans.org/kb/67/javaee/ejb30.html Tutorial NetBean et JEE ]
* [http://docs.oracle.com/javaee/6/api/ API JavaEE 6]
* [https://java.net/projects/javaee-spec/pages/Home Spécifications JavaEE 6]
* [http://www.theserverside.com/news/thread.tss?thread_id=55191 JPA implementation patterns ]
* [http://jonas.ow2.org/JONAS_5_1_2/doc/doc-en/html/getting_started_guide.html#id1316973 Glossaire]
* [http://www.easybeans.net/xwiki/bin/download/Main/Documentation/ejb3-annotations.pdf Aide mémoire pour les annotations EJB3 ]
* Présentation sur le Cloud Computing : http://erods.liglab.fr/icar2013/programme.html
* Documentation et Training Kit sur Windows Azure : http://www.microsoft.com/en-us/download/details.aspx?id=8396
* Documentation de [http://roboconf.net/en Roboconf]
** Exemple avec LAMP http://roboconf.net/en/user-guide/lamp-example-part-1.html
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
* Java EE6 Cookbook for securing, tuning, and extending enterprise applications: http://www.packtpub.com/java-ee6-securing-tuning-extending-enterprise-applications-cookbook/book
* Holly Cummins and Timothy Ward, Enterprise OSGi in Action, March, 2013, 400 pages, ISBN: 9781617290138, http://www.manning.com/cummins/ ([http://www.manning.com/cummins/EOSGI_sample_ch02.pdf chapitre 2], [http://www.manning.com/cummins/EOSGI_sample_ch10.pdf chapitre 10])
* Debu Panda, Reza Rahman, Derek Lane, EJB 3 in Action, Pub Mannings, 2007, http://www.manning.com/panda/
* Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan, EJB 3 in Action, Second Edition, Pub Mannings, 2011, http://www.manning.com/panda2/

Latest revision as of 08:07, 18 August 2021

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

É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 !!!!

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. Liste des Livrables et date de rendu pour les M2PGI Alternants :

  • Livrable 1 : par email, membres du groupe et brève description du sujet (un seul groupe OK)

Audit 1 :

  • L2.1 : Description des profils
  • L2.2 : Questionnaire profils (OPT-ALT)
  • L3.1 : Scénarios
  • L3.2 : Analyse de la concurrence (OPT-ALT)
  • L3.3 : Questionnaire sur l'utilisation (OPT-ALT)
  • L4 : Modèles de tâches (Audit 2 pour ALT)
  • L5 : Fonctionnalités
  • L6.1 : Objectifs pour chaque version (priorités de développement)

Audit 2 :

  • Mise à jour de L2 à L6.1
  • L7.1 : Architecture (OPT-ALT)
  • L7.2 : Base de données (OPT-ALT)
  • L7.3 : IHM Abstraite
  • L7.4 : Maquettes
  • L6.2 : Objectifs pour les versions suivantes
  • L8 : Démo de V0

Audit 3 (Soutenances) :

  • Mise à jour de L7.3 (correction des erreurs)
  • L9 : Rapport d'évaluation experte (imprimé pour la soutenance)
  • L10 : Rapport d'évaluation par expérimentation (imprimé pour la soutenance)
  • L11 : Démonstration finale
  • L12 : Diapos de votre présentation (version numérique à laquelle l'enseignant a accès au moment de votre passage)

OPT signifie que le livrable est optionnel soit parce qu'il ne s'applique pas à tous les groupes, soit parce qu'il ne peut qu'apporter une plus value à votre projet (points en plus mais pas en moins au moment de l'attribution de la note). Lorsque ce n'est pas précisé, c'est à vous de choisir le mode présentation (écrit, schéma...) des informations du livrable

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âches
  • 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

La note est obtenue par l'évaluation tout au long du projet elle est composée de :

  • Les besoins (3 pts) : informations sur les besoins que vous allez prendre en compte (livrables et audit 1)
  • La conception (5 pts) : proposition de solution pour répondre aux besoins (livrables et audit 2)
  • L'évaluation (3 pts) : évaluation de votre (ou vos) solution(s) (livrable et soutenance finale)
  • Présentations (3 pts) : qualité des présentations (documents, email et slides de soutenance finale)
  • Développement (6 pts) : qualité et quantité du code (démo et code)


Les notes des membres du groupe peuvent être différentes en fonction du travail fourni et constaté par l'enseignant.

Partie Système

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

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 Web
  • 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
  • Déploiement et retrait de l'application sur/de la plateforme cloud
  • Préparation d'images de VMs avec Kameleon
  • Performances (résultat du injection de charge avec Apache JMeter ou OW2 CLIF)
  • Supervision du système déployé avec des sondes Nagios ou Shinken conditionnées dans les VMs à déployer.
  • Utilisation (optionnelle) de technologies/APIs/frameworks avancés

Consignes pour la soutenance

Consignes spécifiques pour les soutenances IHM

Salle : F113

Durée totale : 45 minutes


Pour le 23/09 minuit au plus tard :

  • les documents de conception (hors évaluation), gestion de projet et le code doivent être accessibles à l'enseignant : envoyer un email avec l'ensemble des liens permettant d'y accéder

Le jour de la soutenance :

  • envoyé avant votre passage les liens vers les derniers documents (évaluations + diapositives de soutenance)
  • 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
  • présentez individuellement un bilan de ce que vous retenez (positif, améliorations personnelles, négatif)
  • arrivez avec l'application démarée (on ne perd pas de temps) et 1 ou 2 scénarios (de test)
  • prévoyez 15 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 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 de VM.
  • 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 2021-2022

Planning

M2PGI (Alternant)

Equipe pédagogique: VL = Vincent Lesne, NDP= Noel De Palma, LP = Laura Pruzco, SCB = Sebastien Chassande

  • 01 sept 09h-12h F203, Boot Projet +Cours Spring (SCB/NDP)
  • 01 sept 14h-17h F203, Cours Spring (SCB/NDP)
  • 02 sept 09h-12h F203, Cours Angular (SCB/NDP)
  • 02 sept 14h-17h F203, Cours Angular (SCB/NDP)
  • 03 sept 09h-12h F203, Cours Agile (VL)
  • 03 sept 14h-17h F203, Cours Agile (VL)
  • 06 sept 09h-12h F216, Libre Service
  • 06 sept 14h-17h F203, Cours IHM (LP)
  • 07 sept 09h-12h F216, Audit Syst. (SCB/NDP)
  • 07 sept 14h-17h F216, Libre service
  • 08 sept 09h-12h F216, Libre service
  • 08 sept 14h-17h F216, Audit Agile (VL)
  • 09 sept 09h-12h F203, Audit IHM (LP)
  • 09 sept 14h-17h F216, Libre service
  • 10 sept 09h-12h F216, Libre Service
  • 10 sept 14h-17h F216, Libre Service
  • 13 sept 09h-12h F203, Libre Service
  • 13 sept 14h-17h F215, Libre Service
  • 14 sept 09h-12h F203, Audit Agile (VL)
  • 14 sept 14h-17h F216, Libre Service
  • 15 sept 09h-12h F216, Audit Syst. (SCB/NDP)
  • 15 sept 14h-17h F216, Audit IHM (LP)
  • 16 sept 09h-12h TP F203, Libre Service
  • 16 sept 14h-17h TP F216, Libre Service
  • 17 sept 09h-12h F203, Libre Service
  • 17 sept 14h-17h F216, Libre Service
  • 20 sept 09h-12h F215, Audit Agile (VL)
  • 20 sept 14h-17h F215, Libre Service
  • 21 sept 08h-12h F215, Audit Syst. (SCB/NDP)
  • 21 sept 13h-17h F215, Libre Service
  • 22 sept 08h-12h F215, Audit IHM (LP)
  • 22 sept 13h-17h F215, Libre Service
  • 23 sept 08h-12h F203, Libre Service
  • 23 sept 13h-17h F203, Libre Service
  • 24 sept 08h-12h30 F203, Soutenances système
  • 24 sept 13h30-17h F216, Soutenances Agile+IHM

M2PGI (Classique)

Equipe pédagogique: Noël de Palma (NdP), Vincent Lesne (VL), Laura Pruzco (LP), Sebastien Chassand-Barrioz (SCB)

Dates Importantes:

  • TODO

Groupes

M2PGI Apprenti

M2PGI Classique

Soutenance

M2PGI Apprenti

M2PGI Classique

Documentation

Transparents de cours

Doc utiles

Retrieved from "https://air.imag.fr/index.php?title=ECOM-M2PGI&oldid=51190"