Overview

The project is code-centric project work in the context of the lecture content. The aim is to train the process of making incremental changes in a larger system, and / or gain experience with evaluating several possible tools & frameworks, choosing the one that best suits your purposes. There are several proposed projects below, from which any one may be chosen.

Deliverables

A summary of the due dates for this project is given in this table:

Deliverable	Due date
Project proposal	Monday March 19th, 7pm
Implementation	Sunday April 29th, 7pm
Peer review	Monday may 7th, 7pm
Report	Sunday May 20th, 7pm
Presentation & demo	To be scheduled in weeks 9 - 12

There are several deliverables throughout the project:

Proposal

A 1000 word extended proposal should be submitted via Canvas by the due date. The idea is that apart from the provided system context and the description given, the project is driven by you. The proposal should go into detail about exactly what your team will implement for your project.

Following the proposal submission, the lecturers will organize a short feedback session with each team, where we will discuss whether your proposed implementation is sufficient for the project, and offer advice to change this if necessary.

Implementation

The implementation consists of the research, development, and implementation work which your team must complete, to build a functional system for demonstration. For all projects, the following general conditions must be met:

An adequate implementation effort appropriate for the time made available. We sense that this should be about 1000 lines of high-quality code apart from the test cases. This number is not a sharp condition, it just gives a dimension. Depending on the complexity of the work, this can vary. For example, a really difficult (and appropriate!) refactoring might be a good effort with fewer lines of code. On the other hand, many lines of GUI framework code might be seen as a small contribution. You'll have a good estimation about whether your implementation represents adequate effort based on the feedback received following the initial proposal submission.
Changes should be well documented and accompanied by good unit tests. Automated GUI testing is highly welcome. The design rationales should also be included in the documentation. Use both Javadoc comments and line comments. Note that the documentation must not include any information which can be used to identify team members (such as UPIs, names, etc) - this must be kept anonymous for the purposes of peer review.
Your progress should be regularly committed to a git repository. Each commit should be a self-contained unit, e.g. it should not mix multiple independent changes. Each commit should have a proper commit message describing the changes made in the commit. For the submission, push your git repository to the specified server. To provide anonymity for the peer review, we will provide each student with a git account on our own class git server. You must use this account / server rather than your own pre-existing GitHub / Butbucket accounts.
Accompany your submission with a readme file with filename ReadmeXXX.txt, where XXX is your assigned number. The readme file should contain all information that cannot be put into Javadoc comments and a pointer to the different main Javadoc comments.

Marking criteria will be the usual marking criteria used for implementation work, which coincides largely with the degree to which above conditions have been met. The implementation represents a significant proportion of the assessment for the project, and to the course as a whole. It is highly recommended to start early!

Peer Reviews

Each team will be assigned projects from two other teams to review. Reviewers will be given access to the reviewee's repository and will be able to explore the source code and solution. During the peer review process, reviewers should answer the following questions of the project under review:

How much did the group challenge itself with their project scope, within their chosen topic?
Which features particularly impressed you, if any?
Would you have liked to see some additional features?
How well does the documentation match the implementation?
Are there any undocumented bugs or errors?
How complete is the test suite?
Are installation / configuration instructions provided and can they be easily followed?

If bugs are found, reviewers should use the bug and issue tracker to make the developer aware of the problems. Reviewers are welcome to include a contribution or fix, e.g. to repair simple bugs. Push these contributions to your peer review account and send a pull request to the original repository.

Presentation

Each team will be required to give a presentation. The presentation should primarily be a demonstration of the implementation but should also include some background research / project management / design / etc (see the report section below - similar topics should be covered in the presentation).

The presentation format is fifteen minutes presentation followed by five minutes Q&A per team. Each team member should have the opportunitity to speak during the time allowed.

Presentations will begin in week 9 of semester, after the implementation is due. Presentations will take place during scheduled lecture slots - each team will be assigned a date and time by the lecturers. Attendance at all presentations is mandatory for all students.

Final Report

The report is to be individually written - each team member must submit separately (though sharing of any diagrams such as UML class diagrams etc. is allowed).

The length should be approx. 5 pages (including figures) in IEEE two-column format. See: www.ieee.org/publications_standards/publications/authors/author_templates.html (Computer Society Journals; double column)

Structure

Abstract
Introduction: Introduce and motivate the project. Goals.
Related Work: What has been done before? Compare it with your project.
Design: Software architecture (e.g. class diagram)? User interface (e.g. screen diagram)? Why this design?
Implementation: What have you implemented?
Methodology: Management of your team in the project.
Discussion: Have the goals been achieved? Problems?
Conclusion: Conclusions? Lessons? Future work?

Project Topics

This section contains descriptions for specific projects your team might wish to undertake during the course.

Gerald's Projects

G1: A lightweight Web Video Conferencing service

A Web-based video conferencing service using the WebRTC platform and using OpenID/OAuth for authentication. No installation should be necessary.

G2: A history-aware editor for writers.

This tool will be combine a text editor and an unusual novel lightweight approach to version control; it is aimed towards creative writers and its focus is on maintaining several active versions at present.

Creative writers often draft several versions of a storyline which might differ in plot elements, mood, narrative detail and many other aspects. (E.g. J.R.R. Tolkien left many versions of his unpublished manuscripts.) Often there is significant overlap for example in key scenes etc.

The idea is that the author creates new versions simply by copy/paste (in a single file or if possible even in multiple files). The key function of this editor is that it keeps a memory of these copy/pastes. If the user makes later a change at one of the copies, the text editor offers unobtrusively the possibility to apply the changes to other copies of this text as well, as good as possible. One way to do that is to have a side-bar with links to all copies.

Otherwise there is no difference to a normal text editor.

We can assume that the author primarily uses this tool to edit the text, so that the tool has knowledge of the history.

A second function for the tool is a local undo: the user can mark a region and undo the changes in that selection.

G3: Smarter File Backup
To make use of an external drive, one needs a backup tool.
There are some reasonable open source incremental backup programs such as https://www.dirsyncpro.org/index.html, that can maintain a copy or superset e.g. of a laptop disk. Often these programs will however not distinguish between moves of folders and new folders, resulting in duplicated data.

In this project the aim is to work with an existing open source project and make a distinct improvement, in this case the tool should be able to detect moves in the data and perform the same moves on the backup - after the project the result can be fed back to the open source project or be released as an independent project.

G4: A software solution to fix memory sticks

Simple solid state devices such as retail USB sticks suffer unfortunately from an inacceptably high level of bit rot. Large files are often unuseable after about a year. This project is about a simple parity-based error-correction tool: It scans all files and computes one or several checksums large enough so that small errors can be fixed. Needs only relatively basic knowledge of error correcting codes.

Languages: Free choice, Java possible. The program can be based on existing open source projects such as https://www.dirsyncpro.org/index.html

G5: Browser Extension

A Google Chrome or Firefox extension that fulfils an interesting purpose; this is open for proposals from your group, but could be for example:

A productivity application that increases productivity in browsing
An extension that uses or provides a recommender system.

G6: Lightweight Productivity App for large e-paper devices.
The e-paper display technology is the one available display alternative to glowing screens. With a new generation of devices, A4 sized e-paper displays are now available with Android devices. The challenge is that current apps are not optimized for e-paper and are slow. This project is about trying to improve the performance of apps for everyday office work on such devices. We are focusing on an email app as a prime example of an everyday productivity app that tries to optimize performance by being as responsive as possible. Because of hardware restrictions, only two groups can work on this project.

Andrew's Projects

Andrew’s projects involve the development and testing of a cross-platform mobile application. Teams should select an application domain from those listed, and use appropriate tools to develop, refine and test their solution.

Possible (deliberately broad) application domains are as follows:

Video: Develop an app which makes use of steaming video (from the smartphone's camera) in an interesting way.
Augmented Reality: Develop an app using AR technology in a meaningful way.
Blockchain: Distributed ledger technology is a hot topic in research and industry. Develop an app which utilizes the technology in some useful way.
Wearables / Medical: Develop an app which somehow makes use of the wealth of health-related data which can be generated from various wearables (e.g. Fitbit) and / or inbuilt smartphone sensors.
Location: Develop an app which makes use of a user’s GPS location and / or other context information (e.g. user calendar, weather forecast, current activity, etc).
Other: If your team has a great idea which doesn’t neatly fit into these categories, you’re welcome to meet with Andrew to discuss whether your idea is appropriate for this project.

Whatever app domain you choose, your team is welcome to contact the lecturer to discuss specific ideas. Feedback will be provided to all teams upon submission of the proposal, but contact via email beforehand is welcome.

Regardless of the app domain, a significant part of the assessment for Andrew's projects will lie in your methodology for selecting appropriate tools. In particular, make sure to consider the following:

Your app must be able to be built, run and be usable on multiple platforms, while maintaining only a single codebase as much as is possible. At the very least, Android and iOS devices should be supported , though additional platform support is a welcome bonus. There are many tools and languages that may be used to support this development. Your team should research available options, compare & contrast, and pick one which suits your project. Things to consider: What are the strengths of your chosen toolset which are beneficial? What are the attributes of your project which make that tool a good choice as opposed to others? Etc.
How can you test your app and ensure that it functions correctly on as wide a range of devices as possible? Be sure to consider device differences within the same platform (e.g. low-, mid-, and high-end Android devices, different iPhone models, etc) as well as different platforms. There are various tools which let you automate testing for multiple devices, rather than manually test on one device at a time. Investigate, compare & contrast several options, and pick one suitable for this project . In what way has this tool helped to improve your testing process, and why did you choose it over other options? Did you find that with the use of this tool, you could forego other forms of testing (e.g. unit testing) entirely, or was the tool complimentary to your existing testing process?
Developing a complex app from scratch can be a large task – perhaps too large for completion in one paper’s project! Make sure your team follows an appropriate project development methodology for planning, prioritization and assignment of various tasks. Importantly, make sure to document your process well, so we can see how the project might continue to evolve, given more time.