COMP0015 Coursework Brief
Description
This document explains the arrangements for the coursework. You will work in pairs to create a Fair Grade Allocator. The purpose of the application is to help teams allocate the credit for a project so that all parties are satisfied with the outcome. The idea is inspired by the work of Ariel Procaccia, a professor, and Jonathan Goldman, a student, who were both at Carnegie Mellon University in the USA (Jonathan now works for Facebook). They went on to produce a web application called Spliddit which offers provably fair solutions for a variety of division problems including rent payments, restaurant bills and shared tasks. You can use the website to find out how the fair grade allocator works. If you are interested, more information about Spliddit can be found in an article published in XRDS which is a Computer Science magazine for students1 but it is not necessary to read the article for this coursework.
The project runs through the remainder of the term and counts for 65% of the marks available for the module. The lab sessions can, and should, be used by you to work on your project and discuss the work with teaching assistants.
You will deliver the project in three stages, broadly speaking these will contain functionality to:
1. Register a project and participants.
2. Collect votes for a project.
3. Calculate and display the allocation of marks for each project. Use a text file to store and retrieve the information.
The coursework is phased and modular so that you:
do not have a single, large deliverable at the end of term,
can get helpful feedback during development and,
will gain experience of developing a non-trivial application composed of a number of python classes.
The rules governing the main menu:
1. Choosing option ‘A’ will display an explanation for the application.
2. Choosing ‘V’ or ‘S’ in this phase will take the user back to the main menu. Choosing ‘Q’ will end the application
3. Choosing option ‘C’ will allow the user to create a new project using the dialogue below.
4. The user should be able to create more than one project before quitting the program.
Coding style is important, please see the section on Coding Style, below.
It is essential to test and validate your software carefully. You can do this by entering invalid information and seeing how your program behaves. For example: does your program accept the value ‘-1’ for the number of team members?
Due to the iterative nature of software development it is highly likely that your software will alter by the end of the term. This is normal and completely acceptable. However, any changes you make will not affect the mark given for this deliverable.
1.2 Deliverable 2: Vote – 40%
In this deliverable it is essential that you use object oriented (OO) design. You must have:
A Person class
A Project class
You must think carefully about what attributes and methods these classes need. You may have additional classes if you think that they are necessary or fit with your design.
You must extend your application to collect the votes cast for a project.
The dialogue for option ‘V’:
Choosing option ‘V’ will allow the user to record the votes for the project. The partial dialogue could look like that shown in the box below. Information entered by the user is underlined:
The rules governing this part of the application are:
1. Choosing option ‘V’ will allow the user to enter the team’s votes for a particular project.
Coding style is important, please see the section on Coding Style, below. As before, it is essential to test and validate your software carefully.
Due to the iterative nature of software development it is highly likely the code written for Deliverable 2 will alter by the end of the project. This is normal and completely acceptable. However, any changes you make after submission will not affect the mark given for this deliverable.
Deliverable 3: Show Project Point Allocation – 40%
You will finish the application by adding the final features:
When the user chooses option ‘S’, you will show the fairly allocated points for each project member for a given project.
You will store all the information about projects in a text file.
The partial dialogue with the user could look like that shown in the box below. Information entered by the user is underlined:
Enter the project name: C1-ENGS101P
There are 3 team members.
The point allocation based on votes is:
Xiang: 25
Asim: 35
Bogdan: 40
Press <Enter> to return to the main menu: _ Appendix 1.
The rules governing the new features are:
1. Teams should have 3 people or more. This is because the allocation algorithm does not work for teams of 2.
2. Choosing option ‘S’ will allow the user to view the fair point allocation for a particular project. The information you need to calculate the point allocation can be found in Appendix 2.
3. At the start of the application (before the menu is displayed) you will read the file containing the voting information. You cannot assume that the content of the file is valid.
4. At the end, after the user has chosen option ‘Q’, you will overwrite the text file with all the project information.
Submission requirements
For all three deliverables you will use the Codio system to develop and submit your code. Both members of the team must have exactly the same code files in their project folders so that either student’s Codio account can be used for marking. The deliverables are:
A short design report (1 page maximum) and,
Your source code.
The design report is not marked, its purpose is to help guide the marker. It should be submitted on moodle and should contain:
Brief instructions on how to run your program,
The Python style guide that you used,
A list of your files with a short description of each,
A short description of how you tested your app,
A contribution mark for each team member; you have 20 points to share between you. This mark will only be used by the course leader if there is a significant difference in the contribution of either team member.
Assessment
Your project work will be marked using the rubric made available to you on moodle. Both members of the team will receive the same mark unless the lecturer has been notified of issues and determines otherwise.
Marks for your project work will be awarded for the capabilities (i.e. functional requirements) your system achieves, evidence of the design process you followed and the quality of the code. You should show that you have thought about the structure of your application, considering where the logic for the various elements of the application should reside. You should also demonstrate that you have thought about how the functionality should be broken down into various components of the application. You are expected to use object-oriented programming.
Coding Style
Coding style is important: well-formatted code, self-explanatory variable names and comments enhance the readability of programs. Whilst there are no universally accepted coding style rules, developers will generally agree on which guidelines to use at the start of a project. You should choose a set of guidelines, you may use either of these:
Short – Python Style Guide, Simplified version for beginner programmers by John Magee
The real thing - PEP8 – Style Guide for Python Code
Collaborating on Your Code
There are no marks associated with the way in which you write your code together. It’s not possible to share a folder on Codio at the moment and this is something that you are going to have to work around. One simple rule will help to avoid file synchronisation accidents:
Each python file in your system should have only one author.
You can manage your file synchronisation manually in Codio. If you want to download a file, you can right click on the file in the file tree view and select ‘Download’. To upload a file to your Codio project you can choose ‘Upload’ from the File menu.
Additional Challenges
The most effective way to improve your grade is not to take on additional challenges but to ask a member of staff for feedback in lab sessions. This is because staff can provide information about how to improve your application design.
Additional marks may also be gained by taking on extra challenges but you should only do this if you have satisfied all requirements for the deliverable you are working on. You can think of your own challenges or you might like to consider:
Automating testing with unittest, this is arguably the most important additional thing you can learn.
Allowing the user to edit the point allocations for a project.
Using Github (see Appendix 3)
Implementing other provably fair solutions such as bill splitting. See spliddit for other ideas.
Using a database.
Examples: 231
Team member 1’s vote for the effort of Team member 2 compared with Team member 3.
132
Team member 2’s vote for the effort of Team member 1 compared with Team member 3.
123
Team member 3’s vote for the effort of Team member 1 compared with Team member 2.
Worked Example
Here is a fully worked example of the calculation for a project of 3 people.
Xiang’s votes :
Xiang thinks that Asim and Bogdan did the same amount of work. Expressing this as a ratio we can write this as 50:50.
Bogdan’s votes:
Bogdan believes that Xiang did about half as much work as Asim and so he assigns the ratio 35:65.
Asim’s votes :
Asim has decided that Bogdan did about a third more than Xiang and so assigns the ratio 60:40 to represent the work they did.
Showing the ratios as a table:
Xiang |
Bogdan |
Asim |
||||||||||||
X’s votes |
X |
50/50 |
50/50 |
|||||||||||
B’s votes |
35/65 |
X |
65/35 |
|||||||||||
A’s votes |
40/60 |
60/40 |
X |
Appendix 3
Using Github
!!! Warning: Do not use Github unless you have significant time to spare.
Github is a professional tool used by software engineers to manage or control versions of code or other material and to share and collaborate with others. You might like to use your project development as a way of getting to know how to use it. Be warned, it can be complicated.
First Steps with Github: If you don't already have a GitHub account then you can create one using the free Student Developer Pack option: https://education.github.com/pack. Using an education account will allow you to create repositories that are private. This is important as you won’t want others to be able to see your code. GitHub Guides explain how to create a repository: https://guides.github.com/activities/hello-world/. Next you should add your team member as a collaborator for the project so that they can use the repository too. Go to the Settings for the newly created repository, click on Collaborators and add the GitHub usernames of the others in your team. https://help.github.com/articles/inviting-collaborators-to-a-personal-repository/.
Create and merge a branch of the code: Using the ‘Hello World’ GitHub Guide, all members should create a branch of your group repository, make a simple change, commit it, create a pull request and finally merge the change. See here: https://guides.github.com/activities/hello-world/.
Github and Codio: There are some instructions for associating your Codio account with your Github account on this page, navigate to the section entitled: ‘I do not yet have a remote repo’. Once you have done that, you can open a terminal and use git commands to check out the project, create branches, commit changes and so on. Use the Github flow described here: https://guides.github.com/introduction/flow/. You will use the Codio terminal command line and type git commands to manage your git repository. One of the best guides I have found is this one: https://services.github.com/on-demand/github-cli/, although the examples featured are web pages not code.