Regole
- Overview
- Procedure 1: Reserving a project
- Procedure 2: Proposing a project
- Procedure 3: Beginning a project
- Procedure 4: Project design & development
- Procedure 5: Project discussion
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 Proposal page, or propose one proactively. In both cases they will have to open a new conversation on the Project 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, 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 Project Forum.
Plase use the following naming convention for conversations:
The reservation post must specify at least:
- a reference to the chosen project,
- the members composing the team (in case of a team) and their email addresses
- 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 colleagues, either in the current academic 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 Project 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:
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
The report must be written using LaTeX, and it can eventually be extended to become the final report
The aforementioned information about the project are allowed to change during the project development
- post the initial report on the project conversation on the Project 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
- upon approval, teachers will provide:
After receiving a Git repository, students can start working on the provided Git repository.
About the initial report
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 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 (i.e. prefer using numbered lists). In case some significant issues arise, students may ask to renounce to the satisfaction of some goals---provid.ed that minimal pool of goals has already been satisfied.
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 Git 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 Project Forum.
About the Git repository
It is mandatory to 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, but in that case it is your responsibility to select the most adequate build automation technology
Please endow your codebase with adequate automated test suites, possibly runnable with a single command, via the build automation tool of choice.
Setting up a continous integration pipeline running the tests as frequently as possible is strongly encouraged as well.
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 Project 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
- have submitted a final report,
- have pushed their code on the provided Git repository,
- have addressed all the supervisor's concerns, and
- both the final report and the code have been assessed by some supervisor.
During the discussion, the professor will test the students' knowledge about the project topic, and, of course, 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 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 only admissible format is Latex — Final report template here.
The provided templates are just suggestions and their structure is not the only admissible one.