- You have to submit everything through your git repository.
- Everything should be in the master branch.
- Create appropriate subfolders to organize your files correctly.
- Your repo will be cloned the day after the project is due.
- Make sure you check your email regularly for the following few days in case there are issues with your repo or other aspects of your project. You might be contacted to fix some problems or clarify some things if necessary.
- Make sure your repo has been shared properly with [email protected], and submit also your repo url on Moodle (a link for that will be added on Moodle soon).
- Don't wait until the end to submit your repo, to make sure you won't forget.
- The repo timestamps will be checked to determine if you have made changes after the deadline.
- Don't change your repo permissions before all the grades for the project and the course have been entered officially in the university system, in case there are any issues submitting the final grades.
- Team registration: 1 point
- Project description: 1 point
- Microservices API: 3 points
- Presentation/demo: 5 points
- Documentation: 5 points
- Running project: 15 points
- Length: around 15 minutes (minimum 10 minutes, maximum 20 minutes)
- Start with a general project description.
- Then you should cover the following points (in the order you prefer):
- Project design overview (microservices, databases, authentication, ...)
- Demo (live demo if possible, otherwise some screenshots)
- Bugs, issues, future improvements, ...
- You can add other points to the list above.
- You don't have to use slides.
- Every team member should be present on April 15 for the presentations, but not every team member has to be part of the presentation. Every team member should be ready to answer questions about the project. Those not presenting the project are expected to contribute more to other parts of the project, such as the documentation.
- You should attend all the other presentations since you will have to participate in the peer evaluation process (presentation and project overview only, not code review).
- Penalties will be applied to those who don't participate in the peer review process.
- Penalties will also be applied to teams who exceed the hard limit of 20 minutes for their presentations.
- Code documentation (comments within the code, author and license information, ...)
- Database design (design diagrams)
README.md: in your top-level folder, you should have a readme file in the MarkDown format, following an informal convention common among projects hosted in git repositories. It should contain, at a minimum:- a general project description
- installation instructions
- how to run and use your project
- contributors (team members), with contact information (name and email addresses are sufficient)
- tasks breakdown, responsibilities (including presentation, code, testing, ...)
- known issues, bugs
- other comments, possibly addressing issues pointed out in the next section, or issues with project management.
- Most important:
- Is the project running, without crashing?
- Has the project been fully implemented? Or has significant parts been left out?
- Project scope: is the project too simple or too complicated? (related to the previous point).
- Has the project been tested properly (at least with unit testing)?
- Code quality: (well-organized, clean code, good project structure, good naming convention, ...).
- Less important (but might help compensate some other issues):
- Originality
- Potential to go "live"
- Fun