COMP0035 2023/24 Coursework 1 specification

Version: Approved. Version 1.0 27/09/23

Contents

• Introduction
• Getting started
• Technologies to use
• Coursework content
• Submission
• Marking
• Appendix

Introduction

This document specifies coursework 1 which is worth 50% of the assessment marks available for the module.

The aim of this coursework is for you to select and apply relevant software development and data science techniques for aspects of a project lifecycle to define and design two data science web applications. You are also expected to evidence the use of appropriate software engineering tools and techniques in your work.

This assessment includes:

• Data preparation and understanding
• Product and project definition
• Tools and techniques
• Methodology (groups only)

You will submit a portfolio of work with evidence for each section. The required evidence is detailed in section 5 Coursework content.

Coursework 2 will continue from coursework 1, covering further aspects of the lifecycle.

For students continuing to COMP0034 Application Programming for Data Science, in COMP0034 you will develop and test the applications that you design in COMP0035.

Getting started

There are 3 steps in this section:

1. Choose to work as an individual or group
2. Be allocated a data set
3. Accept a GitHub classroom assignment

Step 1. Choose to work as an individual or group

Please carefully consider the choice as you cannot change your decision during the course i.e. if you work as a group for coursework 1 you must also work with the same group for coursework 2 (likewise for individuals).

Groups should carefully consider the potential for conflicting timetables and competing time demands in your 3rd year which can make group work more challenging.

If you choose to work as a group, read the group work guidance in Moodle.

Use the selection task on Moodle to register your choice.

Step 2. Be allocated a data set

Data sets are allocated as soon as the group selection task is completed, typically at the end of the first week of the module.

Where multiple groups/individuals are allocated the same dataset, ensure that you do not collude with other students ; collusion is considered Academic Misconduct. It is expected that those using the same dataset will have very different coursework as you will each have your own product ideas, target audience, questions etc.

Step 3. Accept a GitHub classroom assignment

Create a new repository by accepting the GitHub classroom assignment. Instructions are also given in the first tutorial.

Individuals

1. Login to GitHub.com.
2. Click on the GitHub classroom link for individuals
3. Accept the assignment.
4. If prompted, accept to join the comp0035-ucl organisation.

Groups

1. Login to GitHub.com.
2. Click on the GitHub classroom link for groups
3. One person only (first person from the group)
   1. Accept the assignment.
   2. If prompted, accept to join the comp0035-ucl organisation.
   3. Create the group (team) using the same name as your Moodle group name (e.g. Group1, Group2 etc.).
4. All other group members
   1. Accept the assignment.
   2. If prompted, accept to join the comp0035-ucl organisation.
   3. Select your group (team) name from the list.

Technologies to use

Technologies that must be used

¹ Students who prefer audio to text may audio record any textual submissions instead. Use .mp3 format. Do not create video as you can be more easily identified.

Use of AI

You are permitted, but not required, to use AI (e.g. GitHub Copilot, ChatGPT) only for the data preparation code.

You are not permitted to use AI for any other section (including the explanation of your data preparation code).

You must state and explain your use of AI in the 'tools and techniques' section of the course content.

Coursework content

Creating the content

The following subsections state what must be produced. You can choose to provide any additional relevant items that you believe are useful.

Variances for groups and individuals are noted within each section.

Use techniques included in the teaching materials, or other techniques that are typically used in software engineering and data science. Please provide a relevant reference if you use a technique not included in the course materials.

Add all the content to your GitHub repository.

Add all the written content is to be added to the same file in the order shown below for submission. Please use the section numbering shown below:

1. Data preparation and understanding
   1.4 Explanation of code preparation & understanding
2. Product and project definition
   2.1 Problem statement
   2.2 Product overview 
   2.3 Persona
   2.4 Project goal & objectives  /  Questions
3. Tools & techniques
   3.1 Source code control
   3.2 Linting
   3.3 Project planning and tracking
   3.4 Use of AI 
4. Methodology
   4.1 Methodology selection
5. References

Do not change the names of the files given in the starter code and use the filenames given in the following sections. Automated scripts are used to separate files for marking purposes, if you change the filenames your coursework is likely to be missed from marking.

1. Data preparation and understanding

The purpose of this section is:

• to demonstrate that you understand the data. You should have a good understanding of the data set structure, attributes and their data types, statistics, distribution etc.
• to prepare the data for later use in developing the web apps (products). For example, ensure you have the data that you need, remove any unnecessary data, address any data quality issues you discover (e.g. missing values, inappropriate data types), etc.

For this section add evidence for the following to the indicated files:

Code and data set

Write python code that makes use of the pandas and matplotlib libraries to explore and prepare the data.

Include the original dataset and the dataset after the code has been applied to it.

You may create charts as part of your preparation and understanding e.g. to examine distributions, outliers etc. Do not spend significant effort formatting any charts you create as the visual aesthetic is not assessed.

You may have a data set that is already well-prepared with few corrections or changes needed. You should still demonstrate in the code that you have examined the data set to show that this is the case, and you should still explain your findings.

Groups are expected to spend more time than individuals on the code. This is because all group members must understand the code that is created.

Code quality will be considered in the marking. This includes:

• code structure (e.g. use of functions and/or classes)
• adherence to appropriate python conventions (e.g., PEP8 style guide , PEP275 docstring conventions)
• documentation (comments, docstrings) and more generally whether your code is easy for others (in this case the marker) to read and understand.

Code quality will not consider file length. Typically, code that exceeds 300-400 lines of code would be split into modules. For this coursework, please ignore this aspect of code quality as for marking purposes all the code must be in a single python file.

Explanation

Describe and explain the results of your code to prepare and explore the data. Explain any decisions that you took.

For example, if you identify code quality issues then explain how you addressed these; or if you chose not to address them, then explain the reason for not addressing them.

There is no word limit for this as it depends on the format used and the number of decisions made.

2. Product and project definition

The purpose of this section is to provide those working on, or those interested in, the project with an understanding of what the project will deliver (i.e. the web apps products); why these apps are needed; and who they are being created for.

For this section add all the following to a single file named coursework1.pdf/md:

2.1 Problem statement

Write an appropriately structured problem statement, or a product vision, that summarises the problem or opportunity your web app product (App2) will attempt to provide a solution to.

2.2 Product overview

You will be designing two web app products in coursework 2. The product overview will be very short, likely a few sentences. It should make clear the type of web product (web app) that you plan to develop and the focus of the data. There is no formal technique or template for this. It provides a context for the marker.

The two web apps products are:

• App1: A REST API that will allow developers to programmatically access and use your dataset in their apps. The target audience for this is software developers.
• App2: A web app product that makes use of your dataset via the REST API (App1). You can choose from the following types of app:
  • a. A data visualisation / dashboard app
  • b. An app that deploys a machine learning model
  • c. A web app that uses the data in some other way e.g. to generate content that has interactive features

See Moodle for links to real world apps that are examples of 2a and 2b. It is expected most students will create an app of type 2a or 2b. 2c is intended for those who can imagine an app using the data that doesn't fit either a. or b.

2.3 Persona

Create a persona(s) that describes the target audience(s) for App2 only. A single persona is typical though there may be instances where you intend your web app to be used by multiple personas in which case you can create as many as needed. Creating more personas is not an indicator for higher marks.

For App1 the target audience will be software developers who need to use your REST API in their own web app. You do not need to create a persona for this target audience.

2.4 EITHER 'goals and objectives' OR 'questions'

Provide either option 1 or option 2. Providing both will not lead to more marks.

Option 1: Write project goal(s) and objectives. Objectives should be SMART. These can focus on just App2 or both apps if you prefer.

Option 2 (for data visualisation apps only): Write questions you will attempt to answer by creating visualisations ( charts) using your dataset. The questions should relate to the target audience and the problem statement.

3. Tools and techniques

The purpose of this section is to demonstrate appropriate and effective use of relevant software engineering tools and techniques.

For this section add evidence for all the following to coursework1.pdf/md:

3.1 Source code control

Add the URL for your repository to coursework1.(pdf/md).

Make regular use of source code control throughout the project. Use it for all the coursework documents, not just code.

For groups all members are expected to show evidence of source code control. This can be seen in the commit history.

3.2 Linting

Make use of a linter to demonstrate how effectively your code meets Python style standards such as PEP8, PEP257.

In coursework1.(pdf/md):

• provide evidence of the results of running the linter.
• explain how you used this to improve your code quality.
• state which Python linter you used.

3.3 Project planning and tracking (groups only)

Provide evidence of regular project planning and tracking in coursework1.(pdf/md).

These should indicate what all members of the group did (use initials rather than full names). A typical format might be similar to the Scrum daily stand up:

• What did you do in the last reporting period?
• What do you plan to do in the next reporting period?
• State any issues that are blocking progress

You may use any planning and tracking technique and tool that you think is relevant. Options include but not limited to:

• Add .txt or .md files to your GitHub with your weekly plan/progress/issues
• Submit reports using the optional weekly Moodle reporting task (see Further resources section for each week)

Use GitHub Projects to add and assign tasks

Past students have also used Kanban-style boards, Sprint plans/reviews, etc. When using external tools you must save the evidence (e.g. to PDF) and include it in your submission. A URL hyperlink to an external tool is not acceptable for marking.

The exact timing of the report is not graded; though reports that are submitted just before the assessment deadline or where there is no evidence of timing are not considered to as 'regular' reporting.

3.4 Use of AI

You are permitted to use code assistance AI (e.g. GitHub Copilot, ChatGPT) only for the data preparation code.

If you did not use AI, then please clearly state "AI not used" in this section.

If you did use AI then explain your use of AI in this section. For example, state which tool(s) you used then explain how you used them and to what extent the resulting code was used.

Note, if you do not explain your use of AI here, and it is found to have been used in the coursework, then it may be considered as plagiarism.

4. Methodology

The purpose of this section is to demonstrate that you can select an appropriate methodology for a given situation. This is one of the module learning outcomes.

For this section add the following to coursework1.(pdf/md):

Select a methodology, or combination of methodologies, that is suitable for use in the project.

Justify your choice. For example, you could define selection criteria and review how well your choice meets these. Use relevant literature to support your views and (if relevant) your own experience.

There is no ‘correct’ choice, what is important is that you demonstrate why what you have chosen is relevant to the particular nature and circumstances of your project.

You can consider methodologies from data science and software engineering.

The 'project' in this instance refers to all the activities that you will carry out across both coursework 1 and 2 in both COMP0035 and COMP0034. The activities will include project and product definition, data preparation, requirements analysis, application design, development, testing.

There is no word limit for this as it depends on the format used to present your response. For example, some use tables, others write textual paragraphs that tend to be longer. There are past examples on Moodle.

5. References

The methodology section is expected to have some references.

Other sections are a report of your work, rather than a dissertation. As a result you are unlikely to have many references.

If you do have any then please state them here.

5. Submission

Please refer to Moodle for the deadline date and time.

Submit your work on Moodle as a single .zip in the assignment submission (see Checklist in the next section). Moodle is used as the submission date/time and to authenticate students. GitHub is NOT an acceptable alternative for submission.

Check carefully that you have the correct files with the correct file names. Automated scripts will be used to separate elements for marking; if you change the file name your work is likely to be missed.

Files that are only provided as URLs that link to external locations will be excluded from marking consideration since they may be modified after the coursework is submitted.

GitHub provides an option to download repository contents as a zip.

You can include other files in the zip; though marking will only consider the files stated in the coursework content sections above.

DO NOT add your .venv folder to the zip file, this creates unnecessarily large zip files.

Submission checklist

Check you have the following content in each file:

6. Marking

Mark allocation

Marks will be allocated for the coursework as follows.

It is expected each person will spend 25 hours on the coursework during the first 5 weeks of the module and part of reading week.

Groups will have 100 hours in total, 76 hours to complete the deliverables and 24 hours co-ordination overhead. An overhead for co-ordination is expected for groups. This has been assumed at 1 hour per person per week for 6 weeks ( total 24 hours). This allows for a 30-minute weekly meeting as well as review of work items.

While not exact, an indication of the hours of effort given the marking weighting is shown below.

Mark calculation

Marks for individuals will be given for each section. Each section is then weighted using the % in the table above to calculate the mark.

A group's raw mark is calculated using the same method as for individuals. All members of a group are required to complete an IPAC assessment that includes their own and peers performance. The calculated IPAC rating will then be applied to the group raw mark to calculate the specific mark for each person within the group, i.e.

individual group member mark = group raw mark * individual's IPAC rating

IPAC guidance is given in the appendix .

Grading criteria

The coursework will be assessed according to the standards set in the standard UCL Computer Science grading criteria ( see copy on Moodle in the Assessment section).

The criteria most relevant to this assessment are:

• 1 Quality of the response to the task set: answer, structure and conclusions
• 2 Understanding of relevant issues
• 3 Engagement with related work, literature and earlier solutions
• 4 Analysis: reflection, discussion, limitations
• 5 Algorithms and/or technical solution (note: this applies to the code aspects only)
• 8 Writing, communication and documentation
• 9 Formatting aspects, visuals, clarity, references

The following tables gives indicators that are more specific to this coursework. Given the open-ended nature of the coursework it is not possible to describe every possible aspect that could be considered for each level. Please use the tables below as a guide and not an absolute.

Some aspects relate only to groups, individuals, or both. Check 'section 5 coursework content' for what each needs to include.

NOTE: Marks are not awarded for doing more. For example, individuals choosing to do items identified for groups will not achieve higher marks as this would be unfair since groups do not have the same opportunity.

Data preparation and understanding

Product and project overview

Methodology

Software engineering tools and techniques

Source code control will be assessed using the commit history in the repository. You must include the URL in your submitted work.

There are no generic CS criteria relating to this aspect.

The following questions are not exhaustive and are indicators only:

Source code control

• Appropriate:
  • has it been used regularly? i.e. not just for a day or two before the coursework deadline
  • has it been used by all team members? Everyone needs to demonstrate competence
• Effective:
  • has it been used effectively? e.g. are the commit messages clear and specific?
  • are there typical files used appropriately e.g. README.md, .gitignore? Are appropriate files excluded e.g. virtual environments?
• Exceptional: is there any evidence of sophistication? e.g. branches, pull requests, other features of GitHub

Linting

• Limited: has a linter been used? e.g. is there evidence of the results of a linter?
• Appropriate: has linting been used to improve code quality? e.g. does a linter report show few issues, or is there are before/after linter report that shows a reduction
• Effective: is there an explanation of any issues that have not been addressed with appropriate reasons given for these? or an explanation of steps taken to address issues identified by the linter? Linting may be automated in GitHub Actions.
• Exceptional: is there evidence that goes beyond what was taught in the course?

Progress tracking

• Limited: some evidence but it is not clear that this was created weekly/periodically and may be of limited use in understanding the project progress.
• Appropriate: weekly reports submitted on Moodle.
• Effective: weekly reports submitted, and provide clear updates for all team members.
• Exceptional: goes beyond effective, for example, may include additional techniques e.g. evidence sprint planning/reviews; evidence of tasks/plans; etc

Appendix

The appendix contains supplementary guidance and is common to all assessments on this module.

Data sets

Only use the ethics approved data set

The data sets allocated to students on this course have been approved by the Computer Science Ethics Committee and signed by the Head of Department for use in this course. These data sources comply with GDPR and UCL ethics and data protection policies. You must not use any other data set for the coursework.

The approved data sets do not require data protection registration and since you will not be working with participants in your project there is no requirement to complete any further training relating to data protection and GDPR.

Data set selection was guided by the following principles:

• does not contain data related to, or collected from, humans. There are some very limited exceptions to this and these also demonstrate:
  • the data was gathered lawfully and in accordance with GDPR, and that this can be verified
  • consent was given by the human participants and this consent can be verified
  • the data is wholly anonymous
• is available in the public domain (and further does not requires userid/password to access it)
• is not sensitive
• grants permission for its use (i.e. there is an stated license permitting you to use it)

Complete the mandatory ethics training

UCL computer science provides a series of videos aimed at introducing students to the ethical implications of using secondary data in computer science projects, and in particular the processes that must be followed at UCL.

You must complete the two mandatory ethics training videos as shown on Moodle.

Assessment

Examples of previous coursework

Partial extracts from previous submissions are given on Moodle as examples.

Full coursework examples are not provided since the coursework remains similar to the previous year, and it would then be too easy to simply copy and adapt the coursework from a previous student. Turnitin plagiarism detection is used.

You are encouraged to start work early on your coursework and use the tutorials to gain formative feedback.

Time estimates for assessment

An average module is expected to take around 150 learning hours.

To help you plan your time, the coursework is designed with the expectation you will spend the following time on it:

• 2.5 hours per week (all weeks except reading week)
• 7 hours during reading week
• 10 hours during Christmas/Easter periods

Each coursework should take 20-25 hours.

All assessments are based on projects that start in week 1 and run throughout the module. You are expected to make progress each week. There are weekly activities and checkpoints in Moodle to guide your progress.

Support and guidance

Module staff will be available to provide support and guidance in weekly lab sessions.

The tutor will be available during a weekly module office hour (see Moodle).

You can ask questions at any time in the Moodle Q&A forum where anyone in the course is able to reply.

IPAC peer assessment for groups

The assessment for groups includes peer assessment using the UCL IPAC assessment software and process.

Please read the IPAC student presentation if you are not familiar with IPAC. All IEP students should be familiar with this as it was used in ENGF0001 and other IEP modules.

For each assessment all members of a group must complete an IPAC evaluation that includes their own and peers performance. This determines an individuals IPAC rating. The calculated IPAC rating will then be applied to the raw group mark.

For example, for a coursework graded at 60%:

• a student with an IPAC of 0.9 would receive a mark of 54%
• a student with an IPAC of 1.0 would receive a mark of 60%
• a student with an IPAC of 1.1 would receive a mark of 66%

The criteria used in the IPAC are:

Note that:

• the self-promotion score, which is provided by the IPAC software, quantifies how a student has valued his/her contribution in regard to the contribution of the group (ratio of averages). If the self-promotion score is too high ( over 1.25), then the software ignores the scores given by that student from the calculations.
• 0.5 is the minimum IPAC score a student needs to have before being allowed to take his/her peer marks into account. The reasoning is that those students that do not contribute to the group cannot accurately rate their peers.
• student comments are moderated both automatically by the software and by the course tutor
• different students will be more generous or harsher when assessing their team, the IPAC software applies bias correction

Requests to change coursework submission dates

Coursework submission dates are set centrally in Computer Science and not by the course tutor.

These have been planned carefully to fit with the teaching schedule.

Requests to change these for all students must be made to the course tutor who will then forward the request to the relevant authority in the computer science department. Requests must be supported with appropriate evidence of the need for change.

SoRA and EC

SORA: alternative formats

If you need the assessment or any teaching materials in an alternative format than has been provided, please contact the course tutor directly sarah.sanders@ucl.ac.uk.

If you need/prefer to submit the assessment in a way that minimises use of the written word, audio recordings instead of markdown text are accepted. Please don't use video, the files are too large, and you are more likely to be recognised ( marking should be anonymous).

If you choose to use markdown and are concerned with spelling and grammar, there are spell checkers available for VSCode and included in PyCharm. The mark scheme does not focus on spelling and grammar.

SORA and EC implications for groups

Where a group member has an approved statement of reasonable adjustment (SoRA) or extenuating circumstances (EC) that allows for 1-2 weeks delay to submission, then the approved revised submission date will apply to the whole group. This is because it is not possible to separate an individual's contribution from the group's submission.

In the rare situation where a group member has an approved EC that extends beyond 1-2 weeks, e.g. into LSA, then the impact on the group will need to be considered on a case by case basis. It is more likely in this event that the student concerned would need to submit a new individual assessment and the group would continue to the original submission date.

Late submission penalties

Late submission rules apply to all assessments. Any penalties for late submission are applied by the computer science teaching and learning team when marks are entered in portico. The mark you see in the Moodle gradebook, therefore, is the mark before moderation or any penalty has been applied.

If you have an approved extension resulting from a SoRA or EC, these will be carefully checked by the teaching and learning team before marks are entered in portico. However, the deadlines in Moodle may not be modified for individuals, so it may appear on Moodle that your submission is late even though you have an approved extension to cover the period.

Referencing

Book, journal, web article etc.

For book, journal, and web article references, follow the referencing style you use in your own department (e.g. Harvard, APA). Different departments in UCL use different styles. Include these in a 'References' section in your markdown.

Code

When you copy code from an external source, whether you are copying a snippet of code or an entire module, you must credit the source. This includes where you copy and then adapt the code. External sources include:

• user forums e.g. stack overflow
• open source repositories e.g. GitHub repos where an explicit open source license is stated
• communities associated with a library e.g. plotly forum
• course teaching materials
• official library documentation and tutorials of the python libraries and frameworks

It is not appropriate to copy from other students on the course, past or present.

For COMP0034 and COMP0035 you do not need to cite code from the course teaching materials or boilerplate code from the official library documentation of the required python libraries and frameworks that are expected to be used in the coursework (used in the courses e.g. pandas, flask, dash, bootstrap).

UCL has no single method for referencing code. For the purposes of this coursework use the following.

• Give the author, URL and the date of retrieval. If you adapted the code, indicate "Adapted from" or "Based on".
• Include citations within your code using code comments close to the affected code.

An example:

def play_sound(button_text):
    # Adapted from code from 'remdog' on the Plotly Community Forum at 
    # https://community.plotly.com/t/linking-scatter-plot-elements-to-audio-files/11908/6 
    # Accessed 01/02/21
    ...some code here...

Academic terms

It is assumed that you are familiar with essay terms such as 'describe', 'explain', 'discuss' and 'justify'.

There are numerous sources that provide guidance on these and academic writing in general:

• Essay question words
• UCL Guidance for academic writing
• UCL students union academic writing guide