Rules

Overview

The exam consists of an oral discussion where students present a project of their choice, backed by a final report which must be submitted and validated before the discussion.

Generally speaking, a project consists of a study, design and implementation effort requiring about 100 hours per person in total (175 hours per person if selected also 3 CFU of project activity).

A project may be designed and implemented by a group of cooperating students.
The maximum size for a group is 2 people—3 people in exceptional and well-motivated cases.

A final report is expected to be produced for each project, (possibly) during its development.
In case of a group project, the final report can be shared but it is required to explicitly state how the work was split among the members of the group.

Finally, students will have to discuss their project in order for them to be assessed.
Assessment is always individual, even in case of a group of students jointly participating to the same project.

Students may either reserve a project among the ones we propose on the Project Proposals Page or propose one proactively.
In both cases they will have to open a new conversation on the Projects Forum in order to either reserve or propose a project.
Since then, any discussion concerning the project must will be held within that conversation—there including submission.
Projects proposed by students need to be explicitly approved by the teacher in order for them to be considered valid.

Procedure 1: Reserving a project

Students – either as individuals or as groups – may reserve a project by opening a new conversation on the Projects Forum.

Please use the following naming convention for conversations:

[Surname1, Surname2, ..., SurnameN] Project reservation: [brief activity name]

The reservation post must specify at least:

a reference to the chosen project,
the members composing the team (in case of a team),
some strict temporal constraint, if any
- e.g. someone in the group is going to graduate soon

Procedure 2: Proposing a project

Students are allowed – and actually kindly invited – to propose a project by opening a new conversation on the Projects Forum.

Please use the following naming convention for conversations:

[Surname1, Surname2, ..., SurnameN] Project proposal: [brief activity name]

Proposers need to describe:

their vision, i.e. what they want to realise
the goals (and corresponding deliverable) they intend to reach (and produce) (e.g., application, library, presentation, etc)

It is ok to initially provide a raw description of your idea, ask for feedback, and provide the aforementioned information later.

Proposals must be explicitly accepted by the teacher before the students may proceed with Procedure 3.

Acceptance – as well as suggestions – will be communicated on the same conversation opened by students.

Procedure 3: Beginning a project

Before actually start working on a project, students will have to:

produce an (very short, 1-2 pages) initial report, specifying:

a title for the project
an abstract for the project (max 2000 chars), briefly summarising the goal of the project
a description section discussing the _goals_ and _expected deliverables_ of the project
such a report can be written using either Markdown or LaTeX, and it can be extended to become the final report. Note: information are allowed to change during the project development

post the initial report on the project conversation on the Projects Forum (the conversation is assumed to exists at this point because of Procedure 1-2)
wait for the teacher' s approval or suggestions, upon approval, teachers will provide:

a GitLab repository for the project
an Apice Web page for the project

After receiving a GitLab repository, students can start working on the provided GitLab repository.

About the initial report

The workflow described above is aimed to:

make clear the project's goal
ease our projects management activities
prevent the loss of the produced knowledge or code, making your projects potentially useful for the future students.

Negotiation of the initial report is aimed at helping the students in the selection and formalisation of reasonable goals.

However, we are aware that issues may arise while working on a project.
For this reason, it is important to describe goals in an incremental way.
In some significant issues arise, students may ask to renounce to the satisfaction of some goals.

Procedure 4: Project design & development

Students are assumed to properly design and develop the projects they have chosen, producing quality code to be tracked by means of the provided GitLab repository.

They are encouraged to use some structured workflow during the development, like for instance:

the GitLab flow, which may be sufficient in this context
or the Git flow, which is slightly more complicated, but also more popular and used in the real world

Students are encouraged to keep track of their design and architectural choices by progressively extending the initial report.
They are discouraged from filling the report with (too much) code: the report must track ideas and choices, design and architectures, but the code must NOT be its main content.

Students are encouraged to adopt a test-driven and model-first approach, when possible: they are going to be engineers, not programmers.

If an apparently unsolvable technical or organizational problem arises, students are encouraged to first try to solve it autonomously and, in case of failure, ask for help to teachers, either within some GitLab issue (for what concerns technical aspects) on the Projects Forum .

About the GitLab repository

Despite not strictly required for the course, please take care of keep your repository clean.
This involves:
- correctly setting up your `.gitignore`
- fill up the `README.md` file in a meaningful and informative way
- avoid tracking binary files, dependencies, or IDE configuration files

Finally, take care of making the last version of your code available on the `master` or `main` branches.

About Build Automation

In case your project involves the production of software artifacts, it is mandatory to leverage some build automation system.

There are no constraint on the particular build automation system, but keep in mind that each programming platform comes with its preferred build automation systems:
- Maven or Gradle for the Java, Kotlin, Scala
- Sbt for Scala
- NPM for JS projects
- Pip for Python projects
- Make for C
- etc

It is ok to develop your project in some language different from Java, feel free to select the most adequate build automation technology

Procedure 5: Project discussion

Students must explicitly communicate to the project supervisor their intention to discuss the project, by adding a new post on the project conversation on the Projects Forum, and by attaching the final report.
The supervisor will then propose an appointment for the discussion, provided that the final report is satisfying.
Otherwise the supervisor may propose some improvements.
In this case, students will have to produce an improved version of the final report and post if again, without removing or replacing the previous version.

Summarising, students are admitted to the final discussion with prof. Omicini only after they a) have submitted a final report, and b) the final report has been assessed by prof. Calegari.

During the discussion, the professor will test the students' knowledge about the project topic, and, possibly, its connection to the other topics presented within the course.
In case of a group project, the individual knowledge and contribution will be tested.
The professor will also quickly test the quality of the produced report and code.

About the final report

The final report must be correctly written (in English) and it must be a meaningful but brief (up to 50 pages) guide to the topic studied during the project.

The admissible formats are:
- Markdown (template here)
- Latex (template here)

The provided templates are just suggestions and their structure is _not_ the only admissible one.