Regole

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 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, erasmus 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 <andrea.omicini@unibo.it>, adding all other teachers in copy.

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.

Plase use the following naming convention for conversations:

 [Surname1, Surname2, ..., SurnameN] Project reservation: <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), and
3. some strict temporal constraint, if any (e.g., someone in the group is going to graduate soon)

• We may reject project reservation requests involving projects which have already been reserved/completed by your colleages, either in the current accademic year or in some previous one.
  • So, please double-check your colleagues requests/proposals before submitting your reservation request.
• Consider having a look to these pages for double-checking:
  • APICe SD Projects along the years
  • Projects Forum
• In case of conflict with some previous project, feel free to submit your reservation request anyway, asking for a negotiation of a similar project.

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.
In doing so, proposers need to describe:

• their vision, i.e. what they want to realise, eliciting the functionalities of the desired system;
• their learning goals, i.e. why they believe the proposed project is interesting for the course and what they expect to learn;
• the technologies that they intend to use and why;
• the deliverable(s) they intend to produce (application, library, presentation, etc), aside from the final report;
• in case the deliverable consists of some software artifact, a description of the usage scenarios for the software;
• the members composing the team (in case of a team), and
• some strict temporal constraint, if any (e.g., someone in the group is going to graduate soon)

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

Plaese use the following naming convention for conversations:

 [Surname1, Surname2, ..., SurnameN] Project 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.

• We may reject project proposals involving projects which have already been reserved/completed by your colleages, either in the current accademic year or in some previous one.
  • So, please double-check your colleagues requests/proposals before submitting your reservation request.
• Consider having a look to these pages for double-checking:
  • APICe SD Projects along the years
  • Projects Forum
• In case of conflict with some previous project, feel free to submit your proposal anyway, asking for a _negotiation_ of a similar project.

Procedure 3: Project design & development

Students are assumed to properly design and develop the projects they have chosed, producing quality code to be tracked by means of a repository on GitHub.

• if a student does not have an account on GitHub, the student should create a new one (possibly using a professional username);
• we encourage to keep the repository public;
• in case of private repository, it is mandatory to grant access to the teachers.

Students 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 GitHub 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 adopt a test-driven and model-first approach, when possible: they are going to be engineers, not programmers.
This means that automatic tests should be designed and written along with interfaces, and before implementation.

• Students are encouraged to exploit GitHub'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 GitHub issue (for what concerns technical aspects) on the [Projects Forum].

Procedure 4: 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 final report should be in PDF format

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.

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 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 variations w.r.t. their structures are admissible, if necessary.