chore(grading): adding group grades and feedback

management_web_part_group_4.md

@@ -0,0 +1,72 @@
+# Group 4 - project management and web part feedback
+
+## Gitlab board and project management
+### Requirements
+1. Check the project description and split project requirements into gitlab iterations or gitlab milestones.
+2. Define a couple of users stories following the example and structure provided in the course slides (put them in the gitlab board backlog at this stage) as issues in gitlab board.
+3. Assign every story to one of your gitlab iterations (or gitlab milestones). 
+4. Split user stories into tasks (add the tasks to the gitlab board descriptions.
+5. Estimate 2 user stories tasks using poker cards. Timeless story point estimations are encouraged. Nevertheless, and as agreed in class, If  your group wishes to proceed with a time-based estimation then it's OK (for as long as at least one user story is also estimated in terms of timeless story points (per task and added together for the user story and the result should be put in its description). Add story points estimation per task and user story to the corresponding issue description (for 1 to 2 user stories only).
+6. Discuss differences (and document the process: duration, points of disagreements, adjustments, clarifications, perceived exercice usefulness). This documentation is added as a file in your gitlab repo (under the name: poker_planning_retro.md). 
+7. Once team reaches agreement on task estimation, sum up all tasks points and add them to the chosen user story “weight” on gitlab.
+8. Use your gitlab board during the semester in a consistent way to track issue progress. At the end of the semester, the board has to be up to date with development (e.g. close finished tasks, etc).
+
+### Grade feedback : 3.5/3.5
+* Pokercard planning: All won't change there vote, they are convice it's this level of difficulty. => amusing to some extent! but usually you are expected to reach a consensus and bring convincing facts to reach it.
+* Thank you for the precise reporting and clearly mentioning your metric.
+* Very good usage of the gitlab boards with labels
+* Convention commits : ok (well done)
+* Links between issues and commits: ok
+
+
+
+
+## Design
+### Requirements
+In this part, you are expected to deliver a documentation of your projet's design specifications, with as much as possible reference to what we have seen in this lecture. Those of you who attended this lecture, were shown sample documentations that meet our expectations. Your documentation should typically specify/include:
+* Which specific architecture styles and architecture and design patterns you will be using and make sure you refer to them correctly (a must have). Use the course slides as your reference.
+* The C4 model and/or the Kruchten's 4+ 1 views, to represent your design (strongly encouraged).
+* a couple of other complementary diagrams are also expected to illustrate/represent your projet's global architecture, how systems components will communicate, your technology stack (which will still evolve as we progress throughout the course), deployment diagrams (Kruchten's 4+1 views can typically be useful for this matter). Use UML only if you are confortable with it, otherwise it is not imposed.
+* It's about the quality not the quantity; aim for a clear, concise, and precise documentation. 
+* Once your design is specified, take some time to update your gitlab boards, prepare user stories (and corresponding tasks).
+* As you design your components and your code, keep also in mind composition (interfaces vs inheritance), and aspects related to design by contract.
+* Feel free to send me a draft until March 4, to receive a formative (non graded) feedback, to make sure sure your submissions meets expectations.
+* Your first documentation draft and the final one must be in your gitlab repository in the main branch, in a folder named "design" (in pdf or mark down format).
+
+### Grade feedback : 2/3.5
+* Very good contexte and container diagrams
+* Class diagram ok too but couldn’t find a component diagram
+* Plus I didn’t find any information regarding architecture styles and patterns identified and used
+
+
+## Dockerized app
+### Requirements
+Your project must be fully dockerized. 
+* Define a docker image per main component.
+* Then use docker-compose to run services from your docker images. Propose a complete solution for services that depend on one another.
+* Volumes or other types of storage drivers might also be useful. The system must be easy to launch locally with simple "docker-compose up command".
+* Your dockerized system should be run on gitlab (which might raise some challenge, when it comes to automatic deployment, demos/hints will be given in subsequent lectures).
+
+### Grade feedback : /3
+* 
+
+## Web app Testing
+### Requirements
+While it should be clear to all of us, that test coverage is important in real working environments, in this project specifically, the focus is not on coverage but on be able to differentiate different types of tests and experiment with different testing technologies. So each group is expect to:
+* Implement 2 Unit tests frontend (using cypress and with mock data).
+* Implement 1 Integration test frontend/backend ou a full E2E (end-to-end) test for a key feature: for example getting a specific measurements saved in the backend (in files our case) and to be displayed on the frontend Web page.
+* Tests should be called at every commit; a CI/CD pipeline needs to be using gitlab.yml (and relying on provided examples).
+* Test cases must be documented in a markdown file named web-tests.md, clarifying for each tests: the 1) test purpose, 2) the test type (unit, integration, E2E) as well as 3) the type of testing double chosen to conduct the test.
+
+### Grade feedback : /4
+* 
+
+## Webapp CI/CD
+### Requirements
+* Build a CI/CD pipeline for your dockerized project, especially in relation to deploying the required image on gitlab and using docker-in-docker
+* Tests should be called at every commit; a CI/CD pipeline needs to be using gitlab.yml
+
+### Grade feedback : /3
+ 
+
+Total Project Grade (with the Embedded Part) over 24: 19.5