COMP0034 Coursework 01 specification

2025-02-07 Admin 写评论


Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due


COMP0034 Coursework 01 specification

1. Introduction

This document specifies coursework 1 which is worth 50% of the assessment marks available for the module.
In this coursework you will develop and test a dashboard web application using Plotly Dash (python) and your data set from COMP0035.

2. Coursework specification

2.1. Getting started

1. Create a GitHub repository using GitHub classroom:
1. Login to GitHub.com.
2. Click on the GitHub classroom link (https://classroom.github.com/a/__qn3F-P).
3. Accept the assignment.
4. If prompted, accept to join the comp0035-ucl organisation.
2. Clone the repository you created in step 1 to your IDE (VS Code / PyCharm).
3. Create and activate a virtual environment in the project in the IDE.
4. Install the required packages in the virtual environment e.g. pip install -r requirements.txt
5. Add your data files, e.g., .csv, .xlsx, .db files, from COMP0035 to the COMP0034 project structure.

2.2. General requirements and constraints

  • Compile all written work into a single report in either PDF or Markdown format. Name the document coursework1.
  • Use the repository you created in the ‘getting started’ section. Keep the repository private. Keep the repository in the ucl-comp0035 organisation.
  • You must use the data set allocated to you in COMP0035.
  • You must use the Python open source version of Plotly Dash (https://dash.plotly.com) to create the app. Do not use any other web framework.
  • Do not submit .ipynb files, these are not acceptable for this coursework. The code must be submitted in .py files in a structure appropriate to run the Dash app from a Python virtual environment.
  • This is an individual coursework. Do not collude with other students using the same data set.
  • Use of code AI tools is permitted. UCL recommends using Microsoft Copilot (https:// liveuclac.sharepoint.com/sites/Office365/SitePages/Bing-Enterprise-Chat.aspx) using your UCL credentials. Usage must be stated in the ‘References’ section.
2.3. Coursework content
This describes what is required for each section to be included in the coursework.
The sections are:
1. Application code
2. Test code
3. Tools
4. References (references, statement of AI use, dataset attribution)

Section 1: Application code

Write Python code to create a data visualisation, or dashboard, app using the Python open source version of Plotly Dash (https://dash.plotly.com).
The minimum required:
  • A Dash app that can be run in development mode from the command line.
  • An HTML layout that includes at least 4 different charts that are dynamically generated.
  • Interacts with the data set data using either the .csv/.xslx files; or the sqlite database.

There is no written evidence required for this section. However, if there is something you wish to explain in relation to the application code then please add this in a section called ‘Application code’ in the coursework1 report. It can be useful to indicate here anything notable achievements in your app such as aspects you believe show your independent research; and/or to explain how the structure of your app meets design principles.

Code quality is considered in the marking criteria.

Section 2: Test code

Write Python code tests for the Dash app.
The minimum required:
  • At least 4 browser-driven tests that use:
    • the Chrome browser
    • Pytest assertions
    • Selenium webdriver (https://www.selenium.dev/documentation/webdriver/) (or Playwright (https://playwright.dev)) to simulate user actions in the browser
  • The marker will run the tests using the command pytest in the terminal. If your tests cannot be run using this command, please provide instructions to run them in readme.md (preferably a line of code).
  • Add evidence that shows the tests ran to the coursework1 report in a section named ‘Testing’. A screenshot of the results is suggested.
Code quality is considered in the marking criteria.
Optionally, include other testing evidence such as:
  • unit testing of callbacks
  • use of CI in GitHub Actions
Manual testing is not acceptable for the coursework.

Section 3: Tools

The purpose of this section is to demonstrate use of relevant software engineering tools.

Section 3.1 Environment management

Provide relevant files and instructions that allow the marker to set up and run your code in a Python virtual environment. They will use pip and setuptools with the command:
pip install -r requirements.txt
pip install -e .
Edit the files that were provided in the starter code of the repository:
  • requirements.txt: list the packages used in your code (this is preferred rather than adding dependencies to pyproject.toml)
  • pyproject.toml: basic project detail and code package location required
  • README.md: instructions to install and run the test code

Section 3.2: Source code control

Add the URL for your repository to the report.

Make regular use of source code control.

Section 3.3: Linting

Use a Python linter to demonstrate how your code meets Python style standards such as PEP8, PEP257.
For example:
  • state which Python linter you used.
  • provide evidence of the results of running the linter.
  • if issues are reported by the linter, address these and then run the linter again and show the results.
  • if any issue cannot be addressed, explain why not.

Section 4: References

Include code references in comments in the code files close to where it is used.

Include all other references, if used, in the report.

Section 4.1: Use of AI

State either that you used AI, or state that you did not.

If you used AI, include the details stated in the UCL guidance (https://library-guides.ucl.ac.uk/ referencing-plagiarism/acknowledging-AI#s-lg-box-wrapper-19164308).

Section 4.2: Dataset attribution

Include a statement to acknowledge your dataset (attribution) to comply with any license condition required for your data set (given in the data set link in Moodle > Resources > Data sets).

Each license is different and tells you what has to be cited; e.g. see open government licence v3 (https:// www.nationalarchives.gov.uk/doc/open-government-licence/version/3/).

3.4. Submission

Refer to Moodle > Assessment for the deadline date and time.

Submit your work on Moodle as a single .zip in the assignment submission.

GitHub is not an acceptable alternative for submission. However, it allows you to download files as a .zip file, this .zip file can then be uploaded to Moodle.

Make sure all files are in the zip. URLs linking to external files cannot be marked as they could be changed after the submission time.

DO NOT include your virtual environment, e.g. .venv, folder in the zip file, this creates
unnecessarily large zip files.
Table: Submission checklist

Section
 Report
 Code files
1. Application
 -
 Python code to create the Dash app.
2. Testing
 Evidence that the tests ran (screenshots). Explain how to run the tests if the command pytest from the terminal is insufficient.
 Python test code.
3. Tools
 Source code control: URL to GitHub repository Linting evidence
 Environment management: requirements.txt pyproject.toml README.md
4.References
Statement of AI use
Data set attribution
Other references if used
Include code references within the code files

4. Marking

4.1. Course learning outcomes

The following learning outcomes are assessed in this coursework.

Outcome
 Coursework 1
 Coursework 2
1. Develop an application using an appropriate design/ architecture (design is taught in COMP0035).
Yes
Yes
2. Use a structured language to develop the presentation layer of a web application.
 Yes
 Yes
3. Use a data interchange format (e.g. JSON, XML).
 No
 No
4. Use appropriate tools and programming languages for developing the application logic in the browser and on the server.
 Yes
 Yes
5. Use database technologies to store and query persistent data for an application.
 No
 Yes
6. Write unit tests, and test and debug an application.
 Yes
 Yes
7. Use tools for version control.
 Yes
 No
8. Apply the skills and knowledge gained to design, develop and (optionally) deploy an application.
 Yes
 Yes

Please note:
  • 3: You are welcome to use JSON and XML if useful, however this is not required in the assessment.
  • 5: You may use a database rather than .csv/.xlsx for coursework 1. This is optional.
  • 8: Deployment is not currently allowed. This is excluded in the ethics approval given for the use of the data.

4.2. Mark allocation and calculation

You are expected to spend 22.5 hours on coursework 1 (45 * 50%).

Component
 Percentage
 Expected hours
App code
 60%
 12.5
Test code
 35%
 8
Tools
 5%
 1.5

4.3. Grading criteria

The ‘UCL Computer Science: Marking Criteria and Grade Descriptors’ will be used to assess the coursework (using only the criteria that are relevant to this coursework). In addition to the standard descriptors, further guidance is given for this coursework in the table below.

As there can be a wide range of solutions it isn’t possible to cover everything you might do to achieve a given level. The following should be used as guidance.

Higher mark bands assume that the criteria from lower bands have been fully achieved.

App code

Grade band
 Generic CS Descriptor
 Coursework-specific indicators
Distinction 90+
 Exceptional solution and advanced algorithm/ technical design.
 Generic CS descriptor used, no additional coursework-specific indicators.
Distinction 70-89
 Excellent solution, novel and creative approach.

Evidence of challenge and code that goes beyond that covered in the taught materials.

Makes good use of the technologies introduced to manipulate data.

Excellent code quality maintained throughout; evidence the code meets principles of good design.

Merit 60-69
 Good solution, skilled use of concepts, mostly correct and only minor faults.
Evidence of challenge beyond the minimum requirements.
Consistently good code quality. App created and configured effectively.
Good use of a range of techniques.
High pass
50-59
Reasonable solution, using basic required concepts, several flaws in implementation.
Meets the minimum requirements.
Code quality issues.
Little/no evidence of challenge beyond the core teaching.
Low pass 40-49
 Rudimentary technical solution, but mostly incomplete.
There is a working app though this may not meet the minimum requirements.
Significant errors in the code and/or issues with code quality.
Code that is largely a copy of the course materials with minimal change.

Test code

Grade band
Generic CS Criteria
Coursework-specific indicators
Distinction 90+
 Exceptionally comprehensive testing, extremely thorough approach to testing.
 Tests are extensive in their range and scope. There is greater evidence of sophistication in the testing. Exemplary use of supporting tools such as CI.
Distinction 70-89
Very well done test cases.
 Tests are more extensive than the minimum AND test code quality is consistently excellent AND tests show a distinctive level of sophistication e.g. in the use of fixtures, parameterised tests, types of tests etc. Effective use of CI is also expected for this level.
Merit 60-69
 Solid testing.
Test code quality is consistently good. Tests show some sophistication e.g. in the use of fixtures or the types of tests.
Some use of CI may be expected at this level.
High pass
50-59
Basic testing done.
 Minimum requirements met; though the test quality may be lower and the tests straightfoward.
Low pass 40-49
 Few test cases, but weak execution.
 Tests may be incomplete or have substantial issues.

Tools

These are not covered by the generic CS grading criteria.

Grade band
 Coursework-specific indicators
Distinction 90+
Near flawless use of tools and techniques; techniques used in a way that is beyond the course base materials.
Distinction 70-89
Exceptional use of a range of tools and techniques that goes beyond the minimum required.
Merit 60-69
Effective use of source code control e.g. timely use, appropriate messages.
Setup includes pyproject.toml (or alternative).
Setup instructions complete and clear.
High pass
50-59
Regular use of source code control.
All dependencies appropriately included (e.g. in requirements.txt).
Setup instructions provided.
Low pass
40-49
Limited use of source code control.
Requirements.txt missing substantial number of dependencies.
setup instructions may be missing or incomplete.

5. Appendices

5.1. Guidance on Moodle

Please refer to Moodle for the following:
  • Referencing: AI, Code, other (https://moodle.ucl.ac.uk/mod/page/view.php?id=6363796)
  • Assessment information Q&A: support, late submission, SoRA and EC, submission date change (https://moodle.ucl.ac.uk/mod/page/view.php?id=6363705)
  • Computer science grading criteria (https://moodle.ucl.ac.uk/mod/resource/view.php?id=6089928)
  • Examples of previous student work (https://moodle.ucl.ac.uk/mod/page/view.php?id=6363498)
  • Data sets: ethics, collusion (https://moodle.ucl.ac.uk/mod/page/view.php?id=6370978)
  • Academic terms (https://moodle.ucl.ac.uk/mod/page/view.php?id=6700138)

5.2. Code quality

This is considered as:
1. Code that is easy for others to read and understand.
2. Code that is re-usable. The focus in this IEP minor is on writing code that could be used in applications, not simply on whether the code works.
When you are writing code consider:
  • code structure, e.g. use of design principles and or/patters, use of relevant functions, classes, modules, packages.
  • adherence to python conventions (PEP8 style guide (https://peps.python.org/pep-0008/), PEP275 docstring conventions (https://peps.python.org/pep-0257/)).
  • documentation (docstrings, comments).
  • error handling.
For test code, also consider:
  • appropriate use of assertions
  • test documentation
  • use of fixture

5.3. Code that does not fully function

If your code does not fully work, and you cannot ‘debug’ and fix it before submission, then in the relevant section of the coursework document state as much of the following as you can:

  • What is the code that doesn’t work (e.g. a function name)
  • What you think the problem may be. This shows you understand the issue even if you cannot solve it.
  • Any solutions you have tried. This shows that you understand the issue and were able to take steps to try and resolve it.

Clear code documentation (docstrings, comments) is useful in these situations as the marker can more easily see what you intended your code to do, even if it does not fully achieve that.

发表评论

电子邮件地址不会被公开。 必填项已用*标注