Student group programming project

The project shall develop a emergency management application using big data. Development and run-time platform is free choice, as is programming language. The project should be carried out in groups of three and not more. Working individually or in pairs is not recommended.

This autumn, we specifically invite projects that are related to emergency management.

Finding a project idea

Optional deadline: Friday September 21st

I invite informal, non-mandatory suggestions for programming project ideas by Thursday September 21st, by email to vimala.nunavath@uia.no. Your ideas do not have to be elaborate, but it would be great if you have a (non-binding) group on its feet by then! There will be a mandatory deadline for project proposals later.

Programming-project proposals

Deadline: Wednesday October 10th 1400

The deadline for written project proposals is Thursday October 5th 1400. Everyone who intends to take the course must send me a proposal by then, by email to vimala.nunavath@uib.no.

At this time, you must have decided whether to work alone or in a group. I only need a single email from each group, with Cc to all group members.

The proposal does not have to be long, but the following points must be made clear:

What you are planning to make using big data and big data technologies.
Why it is a good idea to use big data and big data technologies for this purpose.
Exactly what you think is new with your idea.
What you have done to ensure that something very similar has not been done before.
Which datasets you are planning to use.
What technologies (programming language, libraries, development and collaboration tools) you are planning to use.

(These points are particularly important if you want to do a project based on your own ideas. If you chose one of the suggests project themes, some of the points may of course be given.)

Project presentations

The final project presentations: Friday November 23rd.

Depending a little on the number of project groups, each presentation will be brief: perhaps 20 minutes for 3-person groups, 15 minutes for pairs, and 10 minutes if your are working alone.

You may demonstrate your project live (most convincing), or you may replay a recorded demonstration (which is good to have as a backup in any case). In addition, I expect each presentation to address/answer at least these points:

what have you made? - or: what is your application doing?
which technologies have you used (languages, libraries, IDEs etc.)
which datasets have you used? - or: where did you get your data from? are you using (only) semantic data, or are you lifting (some of) them?
which vocabularies are you using? have you created a new vocabulary/ontology, or extend existing ones?
why is it a good idea to do this using big data and big data technologies? - or: what does your app do that was not possible (or at least not easy) to do before?
exactly what have you done and programmed so far?
what are you planning to do in the last weeks?
have you got particular problems you need to address?

Final project submission

Hard deadline: November 27th, kl.14.00

The end result of the project should be submitted as a ZIP archive through Inspera:

Just one person in the group shall deliver the group assignment (ZIP file) in Inspera.
The groups must be created by the candidates. To do that you must create an ID for your group. The ID must be four digits and all the members must know it, and use it.
When you log in to Inspera you get two options: "Join existing group" or "Create new group".
The first member in a group logging in to Inspera must choose: "Create new group".
All the other members in the same group must choose: "Join existing group".
All members in the group must log in to Inspera Assessment (and join the Group), BEFORE one person delivers the group assignment. (Each group can only deliver once)

The submitted ZIP archive should contain your complete project in a single directory, but DO NOT INCLUDE large semantic data sets like DBpedia or other. You do not need to include standard libraries like Jena either. Instead, include a file README.TXT in the root of the project directory to let us know if you have used a particular development environment (like Eclipse), what is needed before your code can be run, and how to run it, and if there are other things to do.

The file name of your archive should contain the student numbers of everyone in the group. (Not that your student number is different from your student card number...). In addition to your code, the ZIP archive should contain a two-page description of your project (see below). You can also include small example data sets to run the code on, if you want to.

Submitted code

You should comment the code lightly in-line. This does not mean one comment line for each code line but, e.g., one brief comment for each logical group of code lines. In particular, we do not require full Javadoc.

Project description

Your ZIP archive should contain a short project description. Put this description in the root folder of your project directory before you ZIP it. The project description file should be anonymous, and contain the exam numbers of all group members, BOTH on the first page and in the file name (e.g., ProjectDescription_102_113.pdf .)

The length of the project description is max 2 A4 pages with 11pt font and 2.5 cm margins. This is a HARD limit. You can have appendices, though, and any figures or tables come in addition to the two pages. The quality of your code is more important than the quality of the 2-page description. You receive a grade on the project, not on the report.

You should briefly explain the purpose of your system. Why have you made this? Why is it a good idea to do this using semantic technologies? What can you do now that wasn't possible before?
You should probably list the technologies/tools/standards/vocabularies you have used and explain briefly why you chose each of them. Did you consider alternatives? Why were the ones you chose better?
If you are reading/converting/lifting data from multiple sources and/or using existing tools in addition to your own program, you should probably include a flow chart or architecture sketch (which is different from a class diagram).
You should probably include a class diagram and/or data flow diagram of your system.
You should mention any particular problems you have had and/or things you want to do differently next time.
If you want to briefly describe how to run the code you have submitted, you can do that separately in a README.TXT file.