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.

Suggested timeline
Calendar week	Week of Course	Suggested Tasks
W3	Week 1	Start forming groups, complete lab assignment 0,
W4	Week 2	Complete Lab Assignment 1 : Design Mockup with HTML and CSS, decide on a project and start discussing the application and what functionality you plan on implementing.
W5	Week 3	Start implementing the model and database.
W6	Week 4	Finish your first version of the model and the database (lab assignment 2). Start working on the frontend.
W7	Week 5	Complete lab 3, first version of frontend.
W8	Week 6	Show a first working prototype of your application to your supervisor.
W9	Week 7	Implement security into your application. Work on improving use cases and functionality, expanding the model if needed.
W10	Week 8	Work on improving use cases and functionality, expanding the model if needed.
W11	Week 9	The last date to make changes to your repository is on Tuesday 15 March 23.59. 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
You should use the MERN stack (MongoDB, ExpressJS, ReactJS, NodeJS). If you want to use a different choice, 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. This should include a screenshot of your application's main page. See "The Report" section below for more detail.
The complete git repository of the project (code, documentation, and other assets), including the history of the repository must be provided.Please include a link in your project report. If it is a private git repository, you will be asked to add your grader to the project.

What to think about when you work

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. Include a screenshot of your application's main page.
Design - describe the technical construction of your app, including all libraries, frameworks and other technologies used. Include a specification of the API for the backend, i.e. what requests it accepts, and what responses it sends for valid and invalid requests.
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 the exam week (14-18 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.

During the demo you must show all working use cases. You will be asked to provide a list of use cases before the demo 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 design of each part modular?
- Are the view, model and controller clearly separated? Are the services clearly separated?
Functionality (30%)
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?
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
The 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 Friday 11 March 23.59. 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 3000-10 000 lines of code (including JavaScript, HTML, CSS, etc). We expect each member of the group to contribute at least 750 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 750 lines per person, it is probably too simplistic to get a higher grade. If your contribution is below 750 lines, it is probably (but not necessarily) too small to get a good individual grade.