Giovanni Ciatto, Andrea Omicini

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 90 hours per person in total. A project may be designed and implemented by a group of cooperating students. The maximum size for a group is 3 people—4 people in exceptional and well-motivated cases. In this case, the required effort is expected to scale up linearly with the amount of students composing the group, which means about 90 * N hours, being N the amount of students in a group. In any case, 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 (i.e. unique) 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 one of the teachers in order for them to be considered valid. The teacher approving the project is usually the one that will supervise the work and assess it once it is over.

Worker students, non-italian-speaking students, or students having some other sort of special need, may ask to renegotiate the terms of the examination. In this case, students can send a private email to [email protected], adding all other teachers in copy.

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

Plase use the following naming convention for conversations:

[Surname1, Surname2, ..., SurnameN] Project reservation|proposal: <brief activity name>

The reservation post must specify at least:

1. a reference to the chosen project,
2. the members composing the team (in case of a team),
3. the extimated starting date for the project, and
4. some strict temporal constraint, if any
   • e.g. someone in the group is going to graduate soon

Students are allowed – and actually kindly invited – to propose a project by opening a new conversation on the Projects Forum. In doing so, proposers need to describe:

• their vision, i.e. what they want to realise
• their learning goals, i.e. why they believe the proposed project is interesting for the course and what they expect to learn
• the deliverable they intend to produce (application, library, presentation, etc)
• in case the deliverable consists of some software artifact, a description of the usage scenarios for the software

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

Plase use the following naming convention for conversations:

[Surname1, Surname2, ..., SurnameN] Project reservation|proposal: <brief activity name>

Proposals must be explicitly accepted by one of the teachers before the students may proceed with Procedure 3.

The teachers may also suggest some edits to the proposed project in order for it to be approved.

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

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

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

   1. a title for the project
   2. an abstract for the project (max 2000 chars), briefly summarising the goal of the project
   3. a section extensively describing the goals and expected deliverables of the project, along with their requirements
   4. a section describing the expected work plan, and the expected division of labour in case of a group

   (such a report can be written using either Markdown or LaTeX, and it can eventually be extended to become the final report)

   (notice that the aforementioned information are allowed to change during the project development)

2. 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

3. wait for the teachers' 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.

The workflow described above is aimed to:

• make students aware of what they should do BEFORE doing it
• ease our projects management activities
• prevent the loss of the produced knowledge or code, making your projects potentially useful for the future students.

In particular, the initial report is the most valuable artifact in this phase. Within the initial report, students must take care of specifying their goals in a clear, precise, undambigous, and incremental way.

Project assessment will take goals satisfaction into account: it is important that your projects satisfy the goals that you have chosen

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

By submitting an initial report students commit to the goals therein described

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---provided that minimal pool of goals has already been satisfied.

Students are assumed to properly design and develop the projects they have chosed, 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 well-known Git flow, which is slightly more complicated, but also more popular and used in the real world

This is mandatory in case of a group.

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

Students are encouraged to exploit GitLab's "Issues" feature during the development process, in particular when:

• discussing the implementation of a new idea
• submitting feature proposals
• reporting bugs and malfunction
• elaborating new code implementations

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.

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.

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, but in that case it is your responsibility to select the most adequate build automation technology

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.

Before admitting the students to the project discussion, the supervisor will take care of assessing their lab activity. This may involve the scheduling of another meeting with the supervisor to discuss the lab activity.

Summarising, students are admitted to the final discussion with prof. Omicini only after they (i) have submitted a final report, (ii) have submitted their lab activity, and (iii) both the final report and the lab-activity have been assessed by some supervisor.

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.

The final report must be correctly written (either in Italian or 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.