Student group programming project

From info319

The project shall develop an emergency management application using big data technologies and social media data. Development and run-time platform is a free choice, as is a programming language. The project should be carried out in groups of three. Working individually is allowed only if you come up with your own proposal.

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

Finding a project idea

Optional deadline: Friday September 27th.

I invite informal, non-mandatory suggestions for programming project ideas by Friday September 27th, 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: Friday October 4rth 1400

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

Student project has to be in a group consist of not more than 4 members. Send me 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, December 6th.

Depending a little on the number of project groups, each presentation will be brief: 20 minutes for each group.

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?
  • 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 future?
  • have you got any particular problems you need to address?

Final project submission

Hard deadline: December 13th 1400.

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. 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 2 page description of your project (see below). You can also include the data sets to run the code on.

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 or similar.

Project description

Your ZIP archive should contain a 2-page 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 maximum 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 big data technologies? What can you do now that wasn't possible before?
  • You should probably list the technologies/tools/standards/ datasets 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.