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 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:
- a reference to the chosen project,
- the members composing the team (in case of a team),
- the extimated starting date for the project, and
- 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:
- 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
- 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 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:
- 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: 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 section extensively describing the goals and _expected deliverables_ of the project, along with their requirements
- 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)
- 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 teachers' approval or suggestions
- upon approval, teachers will provide:
- a Git repository for the project
- an Apice Web page for the project
After receiving a Git repository, students can start working at their project.
Committing and pushing frequently is recommended.
Procedure 4: 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 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.
This means that automatic tests should be designed and written along with interfaces, and before implementation.
- 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].
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.
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 have submitted a final report, have submitted their lab activity, and 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.
About the final report
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:
The provided templates are just suggestions and their structure is _not_ the only admissible one.