Project

General

OBS: gör nedanstående så snart som möjligt!

• Choose a group name and register the group, which have either four or five members. You can do this here.
• The project must use the Git versioning system (use GitHub or other). Setup the project site using the group name.
• Start thinking about an interesting project. The topic of the project isn’t normally critically related to the grade, almost any application can be more complex by adding more requirements and/or features. Have a talk with Alex if you need assistance. (though, please avoid 2D games and be more creative when choosing an application)

Mandatory supervision meetings

You are going to have a weekly meeting with you supervisor and these are mandatory! These meetings are essential to reach the learning goals of this course, and the success of the project. Not attending a mandatory meeting can have consequences. If you can’t make it, please find a different time in the same week.

We apply the following rules:

• If you have a valid reason (for example: being sick, attending a funeral, etc.) you are allowed to miss one meeting. Not being honest about this results in failing the course.
• If you miss one meeting without a valid reason (working, vacation, etc.) or a second meeting with a valid reason, you will get an extra (relevant and instructive) task. The deadline for such a task is two weeks after the end of the course.
• Attending a supervision meeting via digital media (Skype etc.) is not allowed and counts as missing a meeting. Our experiences are not positive with this kind of participation. It is hard to participate in discussions, let alone to draw something on a whiteboard.
• Missing an extra supervision meeting (which corresponds to 25% or 38%!) will result in failing the course.

Again, we have these rules for you own good, such that you can reach the learning goals.

Use the following template and make sure to archive all in your GitHub repository.

Requirements

All required documents and code should be downloadable from the Git repository. It’s assumed that the branch ”master” is the final delivery.

Application

We expect a standalone, desktop or mobile Java end user application (i.e. a graphical user interface). Application should use “some kind of” MVC architecture. There must be an OO-model as the core of the application. The project must be possible to run on Win/Mac/Linux. If additional information is required to run the project there should be a README-file explaining how to do.

You may extend the application (client/server, database, etc.) but note:

• It’s much harder to get a clean design when combining different technologies
• It’s not necessary to extend to get the highest grade

You will probably not be able to finish and you don’t need to, but we do expect a prototype. On the other had, much functionality will impress of course. If you have difficulties to get things to work: simplify, emulate, and talk with your supervisor.

Documentation

All documentation should be in PDF format.

RAD and SDD

Use the following templates for your documentation:

• Mötesprotokoll, exempel
• User story template, exempel
• Requirements and Analysis Document template, contact Alex if you want the LaTeX source
• System Design Document template, LaTeX source available
• Självskattning

We have the following requirements on the documentation:

• A section in RAD or SDD should be short and concise probably require at most 1-3 paragraphs. If something isn’t applicable just add a NA (not applicable) under the actual section (the sections are there to guide you, they are not mandatory).
• UML-diagrams should be on class/package/module-level. We are usually not interested in variables and methods except for methods in interfaces. We don’t want to clutter a diagram with too detailed information.
• For the dynamic model (RAD) we use sequence-diagram (if necessary).
• No auto generated UML (other UML welcome).
• Javadoc not mandatory but helpful comments are appreciated.
• User stories texts should be in the RAD.

Peer review

A part of the examination is the peer review (kollegial granskning) of other’s code and design. You will be assigned to review another group’s code and design in the final week of the course (läsvecka 8). You will do the review with the entire group and will write a short report about it, at least one page and maximum of two pages (A4). You should be critical and spot inadequacies, but also give appraisal where it is due. Have an extra group meeting devoted to the peer review (or extend an existing one) and spend say two hours on it.

Here are a number of aspects you should consider:

• Do the design and implementation follow design principles?

  • Does the project use a consistent coding style?
  • Is the code reusable?
  • Is it easy to maintain?
  • Can we easily add/remove functionality?
  • Are design patterns used?
• Is the code documented?
• Are proper names used?
• Is the design modular? Are there any unnecessary dependencies?
• Does the code use proper abstractions?
• Is the code well tested?
• Are there any security problems, are there any performance issues?
• Is the code easy to understand? Does it have an MVC structure, and is the model isolated from the other parts?

• Can the design or code be improved? Are there better solutions?

You will receive the to be reviewed code and documentation from your supervisor. You need to supply your own code and documentation (RAD and SDD) to your supervisor as well. The deadline for this is listed below.

Final report (slutraport)

The final report collects the following three items:

• The content of the RAD document
• The content of the SDD document
• The peer review of the design and code of another project

So, you just reuse the contents of the RAD and SDD and add the peer review. You can use this template for the report.

Deadlines

Review

Hand in a snapshot of your code and the accompanying RAD and SDD for the review to your supervisor before 21 October 2018 at 23:59 (end of läsvecka 7). Put the documents and the code in a zip-file and mail it to your supervisor (put the examiner Alex on the CC). The RAD and SDD files should be in your Git repository, so create a zip-file of your repo.

Note that this should not take (almost) any extra effort: the RAD, SDD, and code have been developed and improved in each iteration. Just hand in what you have at that moment in time, maybe do some cleaning up before hand.

Self estimation (självskattning)

The self estimation should be handed in before your oral presentation. Alternatively, send a digital copy to the examiner (Alex) and your supervisor.

Final report

The final report should be ready before the end of läsvecka 8, that is 28 October 2018 at 23:59. Put the report in your Git repository and mail your supervisor that it is ready (put the examiner Alex on the CC).