This document describes what we expect from your group and your work on the project during the course. It includes a list of requirements and information on how to write the final project documentation. We also provide some useful information on what to think about, when the deadline is and when you should demonstrate your project to the rest of the class.

Suggested timeline

Here is a suggested timeline. This is only a recommended timeline and you are free to modify it and work in any order or pace that you decide. However, we strongly recommend that you define the model of your application somewhere at the beginning of the course. During your work, you should employ an iterative process where you go back and improve and extend previous implementations and choices.

W4	Week 1	Start forming groups. Course introduction (no project work).
W5	Week 2	Taking inspiration from the mockup you did in Lab Assignment 2 : Design Mockup with HTML and CSS, decide on a project and start discussing the application and what functionality you plan on implementing.
W6	Week 3	Start implementing the object-relational-model and the persistence layer. You will do this in smaller groups, allowing you to test multiple solutions.
W7	Week 4	Finish your first version of the persistence layer and the model. Start working on the frontend.
W8	Week 5	Show a first working prototype of your application to your supervisor.
W9	Week 6	Implement security into your application. Work on improving use cases and functionality, expanding the model if needed.
W10	Week 7	Work on improving use cases and functionality, expanding the model if needed.
W11	Week 8	Work on improving use cases and functionality, expanding the model if needed.
W12	Week 9	The last date to make changes to your repository is at the end of this week (midnight between Thursday-Friday). Present your project to the class.

Requirements

You must create a full stack web application. You may add any useful frameworks even though they are not directly covered in the course
The main backend has to be implemented in Java. You have a free choice of frontend technology (Java Server Faces, Vue, React, Angular etc), but we strongly discourage the use of a secondary server instance (like requiring NodeJS for the frontend). Most JavaScript frameworks can employ client-side rendering. We can make exceptions, but then you have to make your case to your supervisor
There must be at least 10 working use cases. For a grade higher than 3, these should not all be simple CRUD operations
Must contain a test suite
There must be a short and accurate paper describing the architecture/design of the application, the used techniques, the responsibilities, the flow. There should be a screenshot of the applications main page and an picture of the group in the documentation
The complete git repository of the project (code, documentation, and other assets), including the history of the repository must be provided. You have two options:
- Host it as a public git repository and provide the link somewhere on your group section on canvas
- Provide a `tar.gz` archive with the repository archived and published on canvas under your group section. In this case, the archive has to include the complete git history

What to think about when you work

Less is more. Try to keep your methods short and your indentation level to a minimum
Don’t use unnecessary code comments – write self-documenting code with good class names, method names and variable names
Follow the same code conventions throughout the code base. Tools such as CheckStyle (checkstyle.org) and PMD (pmd.github.io) can help you to achieve this. We highly recommend these tools! Ask your supervisor on how to get these going if you are having any issues
Make sure your commits are clean and describe the work you do in each commit. We want to be able to follow development. It's therefore imperative that the git log is in order and not a complete mess. If your make a lot of changes and your commits becomes very big and difficult to describe, use a tool like `git gui` or similar to divide it up into multiple commits

The Report

Reports are usually 3-5 pages, but feel free to use more space if you believe you need it. If something helps us to better grade your project it's probably a good idea to add it. Diagrams and screenshots are appreciated!

A typical report contains the following sections:

Introduction - A brief description of the app, with links to the git repo.
A list of use cases
User manual - Describe how to use your app, from the user's point of view
Design - describe the technical construction of your app, including all libraries, frameworks and other technologies used
Application flow - To help explain your design, describe the flow of your app for a few of the use cases: the user actions, then which components/classes perform which actions in which order: this request is sent to the server, handled by this servlet, which calls this method of ModelClass, etc. We recommend a UML sequence diagram to illustrate this
Package diagram - A top level UML diagram describing the design and layers of the project
Show a code coverage report - Use a tool like JaCoCo (www.eclemma.org/jacoco) to generate a code coverage report. Preferably use the Maven plugin (www.eclemma.org/jacoco/trunk/doc/maven.html) when adding it to your project
Model diagram - An UML diagram of the model
Responsibilities - Describe which members of your team were responsible for which parts of the project

Project Demo

The group should run a demo of the project in week 12 (20'th of March). You will have 30 minutes total, including questions. We recommend you plan your presentation to last 20 minutes, leaving 5 minutes for questions at the end, and 5 minutes for setup at the start. Use this Doodle (https://doodle.com/poll/v3thbxspqtmkwk3v) to book a time slot for your group if you have not already done so.

During the demo you must show all working use cases. Before the demo, you should hand over a list of use cases for us to tick off as you demonstrate them.

You should also hand in a self evaluation. This is important during our grading process.

Project Grading

Each group will be awarded a grade for their project (in order of importance):

Design, code quality and style (40%)
- Is there an easily identifiable architectural pattern?
- Does the code match the design in the documentation?
- Does the code follow good architectural principles?
- Is the project structure clean and void of external dependencies?
- Are good coding practices followed and is the code readable and self-documenting?
- What is the general technical level/quality of the code?
- Are the logical parts of the application easily identifiable?
- Is there any duplicated code?
- Do the different parts communicate through well-defined interfaces and/or is the he design of each part modular?
- Is the view, model and controller clearly separated? Are the services clearly separated?
- Is the design taking advantage of Enterprise Java Beans and/or it's support for transactions?
Functionality (30%)
- Number and complexity of working use cases
- Are there different roles for users? (e.g. customer, employee, admin)
- How is security implemented?
- Is data validation used where appropriate?
- Is the website somewhat responsive? Using some kind of grid system like the one in PrimeFaces or Bootstrap (as we practiced in Lab Assignment 2 : Design Mockup with HTML and CSS) is enough
Testing (20%)
- Is there testing code?
- Is it cleanly separated from the production code?
- How many of the app's features are covered by the testing code?
- How is the quality of the testing code?
- Are there any integration tests using Arquillian and Drone/Graphene or any similar frameworks for testing the frontend?
Documentation (10%)
- Is the code well commented (difficult parts commented, helpful comments, not too many comments)?
- How is the quality of the report?
- Please note that while we don't put much focus on the report, it's still a very important guide for helping us to grade the other parts. A good and well-explaining report gives us more time to give you a fair grade!

We will judge your individual contribution based on:

Your responsibilities, as recorded in your group's report
Your activity on Git, as measured by gitinspector
An anonymous evaluation by the other members of your group
Your own self-estimation

If everybody has worked throughout the course and continuously contributed to the code, the average of the final grades of the members of your group will usually be very close to the group's project grade.

Weekly supervised meetings

The supervised weekly project meetings are mandatory. If you have a lot of absence, your supervisor may decide to give you an extra assignment within the context of the group project.

Submission

The deadline for the project is Thursday 19 March at 23.59, the Thursday before the presentations. Please make sure that the code and documentation (including the final report) that you want to be graded is in the master branch of your git repository at that time. Please include a README.TXT file in the root branch of your repository that tells us how the files are organised in your repository's directories, including where to find your final report.

Miscellaneous

As a guideline for how complex a project we expect, a typical project is 4000-10 000 lines of code (including Java, HTML, CSS, etc). We expect each member of the group to contribute at least 1000 lines of code.

This is only a guideline: more code is not always better (and is usually worse!) However, if your project is smaller than 1000 lines per person, it is probably too simplistic to get a good grade. If your contribution is below 1000 lines, it is probably (but not necessarily) too small to get a good individual grade.

The number of lines of code only works as a guide and not a measure.