Copy and past from last year's project README

README.adoc

@@ -36,3 +36,142 @@ Project -- "participants [*]" Participant
 Participant -> "*" Idea
 Task *--> "[*]" Tags
 ----
+
+== SCE Bank
+
+SCE Bank est un logiciel de gestion de clients et comptes d'une banque.
+Dans le cadre de ce projet, vous allez contribuer au développement de ce logiciel.
+
+== Préambule
+
+Si vous utilisez les machines des salles de TPs dans le cadre de ce projet, vous devez utiliser le Java JDK *java-8-oracle*.
+Vous pouvez changer le JDK utilisé dans un projet dans le menu "Project structure" > "Project" > "Project SDK".
+
+== Communication
+
+Avant de commencer le projet, connectez-vous au serveur https://mattermost.univ-nantes.fr[Mattermost] de l'Université,
+en utilisant votre compte GitLab.
+
+Ensuite, rejoignez l'équipe "Génie Logiciel", puis le canal "CEL" (Construction et Évolution de Logiciels).
+
+**Utilisez ce canal comme SEUL et UNIQUE moyen de communication avec les encadrants, pour toute question concernant le projet.**
+
+
+== Organisation
+
+Ce projet sera réalisé par groupe de 3 étudiants.
+Vous allez suivre le processus de maintenance vu en cours.
+Pour rappel:
+
+Commencez par préparer l'environnement de votre projet :
+
+. Avant toutes choses, un membre du groupe doit créer un *"Fork"* du projet sur le serveur.
+Pour ce faire, cliquez sur l'icône "Fork" (ou "Créer une divergence" en français) de la page du projet pour accéder au lien suivant: https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/forks/new
+
+. Ajouter tous les autres membres du groupe à votre fork.
+
+. Créez des étiquettes pour organiser les tickets du projet: _bug_, _improvement_, _smell_, _performance_, _test_, etc.
+
+. Chaque membre du groupe doit cloner *votre fork du projet* (et non pas celui d'origine).
+Toutes vos modifications devront être poussées sur votre _fork_ et toutes les _issues_ (ou "tickets" en français) ouvertes le seront sur votre version du projet.
+
+. *Il ne doit y avoir qu'un seul "fork" par groupe d'étudiants.* Il sera utilisé comme espace de rendu des fichiers liés au projet.
+
+== Diagramme de classes niveau conception
+
+image::class-diagram.png[align=center]
+
+
+== Travail à réaliser
+
+Le travail à réaliser est réparti en différentes "issues" (ou tickets), répertoriées dans le fichier
+https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/blob/master/ISSUES.md[`ISSUES.md`].
+*Le but du projet est de résoudre tous ces tickets.*
+Pour ce faire, *vous devrez suivre le protocole de travail suivant*, suivant la méthodologie Test-Driven Development (TDD).
+
+Pour chaque ticket du fichier https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/blob/master/ISSUES.md[`ISSUES.md`] :
+
+. Ouvrez un ticket dans votre projet Gitlab (sur l'interface en ligne de Gitlab, section _Tickets_).
+Vous y détaillerez les points suivants:
+
+.. Un bref résumé du problème lié au ticket.
+.. Quels sont les tests à mettre en oeuvre pour vérifier que le ticket a bien été résolu ?
+.. Comment la solution au ticket doit être mise en oeuvre ?
+
+. *Associez un membre du groupe* à la résolution du ticket, via l'interface de GitLab.
+Cette personne, et uniquement celle-ci, sera chargée de résoudre le ticket.
+
+. Créez les tests unitaires qui permettront de vérifier d'abord qu'il s'agit bien d'un problème et ensuite de la résolution du ticket.
+Pour le nommage de vos tests, vous pouvez vous référer à la ressource suivante : https://dzone.com/articles/7-popular-unit-test-naming.
+
+. Implémentez le code qui résout le ticket.
+Les tests écrits précédemment devront valider votre implémentation. _Faites attention à la régression !_ :
+toute modification ne doit pas "casser" du code qui marchait auparavant (les autres tests unitaires doivent passer).
+
+. Si jamais vous devez changer d'approche au niveau des tests, de l'implémentation, etc.
+*Ajoutez un commentaire sur le ticket Gitlab* pour documenter tout changement.
+*N'éditez pas le texte du ticket original*, afin de garder un historique de votre travail.
+
+. Effectuez un (ou plusieurs) commit(s) pour pousser vos modifications sur le dépôt,
+en référençant le numéro du ticket et en indiquant votre progression dans sa résolution.
+Nous vous invitons à lire le billet suivant à ce sujet: https://chris.beams.io/posts/git-commit/.
+
+. Enfin, quand le ticket est résolu, marquez-le comme "résolu" dans l'interface de Gitlab.
+Vous pouvez aussi fermer les tickets automatiquement à l'intérieur d'un message de commit :
+https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html[Automatic issue closing]
+
+Le code du projet est là pour vous fournir une base de code.
+Vous êtes libre de _modifier l'implémentation comme vous l'entendez_,
+voire même de modifier le modèle de classes UML en lui-même !
+*Mais attention, vous devrez motiver tous vos changements dans vos différents tickets/commits !!!*
+
+== Évaluation
+
+* Le travail à rendre se composera de votre *fork en ligne Gitlab*, sur lequel vous aurez poussé toutes vos modifications.
+Cela inclut également tous les messages de commits et tickets ouverts.
+
+* Ajoutez un fichier "`RENDU.md`" à la racine du projet, afin de décrire les spécificités de votre projet
+(choix techniques, parties non traitées, extensions non demandées, etc.).
+
+* Pour être évalué, *tout étudiant doit participer activement au projet*, en réalisant des "commits",
+en ajoutant des lignes de code, en ouvrant des tickets sur le serveur GitLab, etc.
+
+* L'évaluation portera sur les critères suivants :
+
+** Respect du cycle de développement donné dans l'énoncé:
+. ouverture du ticket;
+. écriture des tests;
+. validation (`git commit`);
+. codage;
+. validation;
+. publication des validations (`git push`);
+. fermeture  du ticket.
+
+** Qualité des tickets ouverts sur votre projet Gitlab: description du problème, des tests requis et de la solution mise en oeuvre.
+** Qualité du code produit.
+** Qualité et pertinence des tests unitaires mis en place.
+** Approche choisie pour résoudre chaque ticket.
+** Qualité des messages de commits.
+
+*Ne sacrifiez pas la qualité à la quantité !* Il vaut mieux rendre un projet bien réalisé avec des
+tickets non résolus qu'un projet avec tous les tickets mal résolus.
+
+== Détectez les erreurs de code avec IntelliJ et Sonarlint
+
+L'éditeur IntelliJ propose un plugin appelé https://www.sonarlint.org/[Sonarlint], capable de détecter les _code smells_ dans vos projets.
+Nous vous recommandons de l'installer et de l'utiliser dans le cadre de ce projet.
+
+Pour l'installer, vous avez deux options:
+
+. Allez dans le menu "Préférences" de IntelliJ -> Section "Plugins", cherchez "Sonarlint" puis cliquez sur "Installer".
+. Installez le manuellement : https://plugins.jetbrains.com/plugin/7973-sonarlint
+
+== Dépendances Maven
+
+Le projet de démarrage est configuré comme un projet Maven standard.
+Vous êtes libres d'ajouter de nouvelles extensions lors du développement du projet.
+Par défaut, les dépendances suivantes sont configurées :
+
+* JUnit (https://junit.org/junit5/) pour gérer les tests.
+
+* Apache Commons Lang (https://commons.apache.org/proper/commons-lang/) qui fournit une extension de la librairie Java standard.
\ No newline at end of file