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, decide on a project, complete lab assignment 0, begin lab assignment 1.
W4	Week 2	Complete Lab Assignment 1 : Design Mockup with HTML and CSS, start discussing the application and what functionality you plan on implementing.
W5	Week 3	Complete lab 2, first version of backend with support for 2-3 use cases.
W6	Week 4	Complete lab 3, first version of frontend. Extend both frontend and backend to 4-5 use cases
W7	Week 5	Complete lab 4, connecting database and backend. Extend all three components to 6-7 use cases.
W8	Week 6	Extend app to 8-9 use cases.
W9	Week 7	Complete first version of app with 10 use cases.
W10	Week 8	Final testing, debugging, refactoring, and polishing of documentation.
W11	Week 9	The last date to make changes to your repository is on Tuesday 14 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 stack taught in the course: NodeJS, ExpressJS, ReactJS and MongoDB (optional). If you want to use a different choice, then you must first make sure that Beata and I are both willing to supervise and grade the project.
There must be at least 5 working use cases. (See the information under 'Functionality' below.)
The project 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.

The Report

Reports are usually 8-10 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 install and 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. We will "tick off" the use cases listed in your report as you present.

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%)
- Does the code match the design in the documentation?
- Does the code follow good software engineering principles, including the SOLID principles?
- Is there a clean separation of responsibilities between frontend and backend well thought?
- Are good coding practices followed and is the code readable?
- 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?
Functionality (30%)
- Number and complexity of working use cases:
  - For grade 3: 5 working use cases
  - For grade 4: 7 working use cases (not all simple CRUD operations), or 5 working use cases (not all simple CRUD operations) and database integration
  - For grade 5: 10 working use cases including 1 that is technically complex; or 7 working use cases including 1 that is technically complex and database integration.
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
The evaluation by the other members of your group
Your own self-estimation

The final grade for each individual will usually be the same as the project grade, but a particularly good or bad individual contribution may raise or lower your grade by 1. A student's final grade is almost never different from the project grade by more than 1.

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 Tuesday 14 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.