4.  If prompted, accept to join the comp0035-ucl organisation.

Groups

GitHub classroom link for groups

1.  Login to GitHub.com.

2.  Click on the GitHub classroom link.

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.

2.  Add a copy of the following to your repository:

prepared data set (COMP0035 CW1)

persona(s) (COMP0035 CW2)

questions to be answered (COMP0035 CW1)

Optionally add any other files you need to use e.g. requirements/user stories, wireframes.

You are not marked against how well you meet the designs from COMP0034, however they should help you so it is recommended that you use them.

Technologies that must be used

1 Use the persona from COMP0034 CW1. You may change this if needed. The persona itself is not considered in the marking, however the target audience must be described in sufficient       detail to allow the marker to assess whether your design is appropriate for the audience.

2 State the question, or questions if appropriate, from COMP0034 CW1. You may change the questions if needed.

Key points to note:

Make sure you understand the academic terms ‘state’, ‘explain’ and ‘evaluate’ .          There is no word limit for the explanation text since the number of visualisations can

vary. As a guide, around 200-300 words per visualisation.

Use relevant literature to support your design choice. Refer to the course reading list and/or carry out your own research.

Discuss the overall dashboard design if relevant. For example, a dashboard that has

interactive elements (e.g. selectors/menu options) and structure (e.g. charts that are optionally visible/hidden) that are within the dashboard but not specific to a particular visualisation; then it would be relevant to explain these also.

There are no marks for interpreting what the data in the chart shows. That is, do not try

to explain what the answer is to the questions. Answers such as “the chart shows that x breed is the most common” would be ignored in the marking.

Code a Plotly Dash app

Develop a visualisation dashboard app using the python version of Plotly Dash. The dashboard code should include:

styling i.e. CSS; use of Dash bootstrap components or similar is suggested layout i.e. HTML layout/elements

at least 2 visualisations (charts) for individuals and at least 4 for groups interaction using callbacks

You do not have to write about your app. However, if you wish to provide an explanation of any aspect of your app that you think the markers should be aware of then note this in        README.md (add an appropriate heading such as # Dash app) . For example:

to explain decisions that you made with respect to the application design or code to indicate features of your app or code that might not be obvious

to indicate aspects of the app that you didn’t manage to get working as you would have

desired. For these please state:

what the app should do

what the app current does

what steps you took to try and address the issue

Test the app (groups only)

1.  Create and run Dash app integration tests using Selenium and pytest. Selenium is suggested in the Dash official documentation. Create appropriately named test files and directory.

2.  {optional} Create unit tests for any Python helper functions (e.g. using pytest or unittest).

3.  Provide the following evidence in README.md (add an appropriate heading such as # Testing):

state the types of tests you created with relative link(s) to the relevant test file(s) provide evidence (e.g. screenshot, saved test reports) of the results of the tests

running, coverage reports, CI reports etc

Use of tools and techniques

Add the evidence to README.md in an appropriately named section e.g. ‘Tools & Techniques’

1.  Provide evidence that demonstrates effective use of appropriate use of software engineering tools and techniques. The type of evidence that is expected is:

Source code control: Add URL to your repository to README.md. Demonstrate use

of source code control ( evidenced by commit history). This should be GitHub. If

you can’t use GitHub then a suitable alternative must be agreed with the course tutor.

Set-up instructions: Add instructions to set up and run your app to README.md Dependency management: Provide a requirements.txt file in your zip file, or if

an alternative then appropriate files and instructions for using these

Anything else (optional): If you use other tools/techniques please provide

screenshots, PDF, or other formats that can be downloaded and included in your zip (these must be able to be opened using freely available tools). URL links to   external sites are not accepted for marking purposes since they may be modified after the Moodle submission timestamp.

Note: Continuous Integration is included in the testing section.

Progress and support

You are encouraged to continue to track your own progress weekly to help you achieve the    deadline. There are tasks on Moodle that aim to help with this. However, there are no longer any checks on progress from the course teaching team; nor any marks awarded for evidencing progress tracking.

Use the weekly scheduled lab sessions to work on your coursework. The coursework tutors and several PGTAs will be available in each session and able to give you support and guidance.

Outside the scheduled lab sessions please post any requests for technical support to the Moodle Q&A. Do not send emails to the tutor or PGTAs directly as you won’t receive a response.

When posting questions about your code, please post the URL to your repository. This enables the tutor and PGTAs to see your code which is usually essential for solving technical problems! Other students won’t be able to access your repository from this URL so long as your repository is private and is within the ucl-comp0035 organisation.

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.

Groups are required to complete an IPAC assessment that includes their own and peers  performance. The calculated IPAC rating will then be applied to the raw group mark i.e.

individual 's coursework mark = group mark * IPAC rating.

IPAC guidance is given in theassessment overview .

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. Given     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 achieved.

Some aspects below relate only to groups, individuals, or both. Check the coursework content section of this specification for what each needs to include.

Visualisation design

As a guide, marking considers aspects such as:

did you meet the requirements of the section?

the extent to which the design is appropriate for the given audience and purpose

the extent to which the design considers/is influenced by relevant visualisation design

literature

the quality and nuance evidenced in the explanation and evaluation

Dash app and code

As a guide, marking considers aspects such as:

did you meet the requirements of the section?

structure of the app

appropriate use of the required technologies: Dash HTML, CSS (e.g. dash-bootstrap or

other), Plotly Express/Go, dash callbacks

code quality

range of skills/sophistication of the solution/complexity of the coding techniques involved

etc. demonstrated in the resulting application

Testing (Groups only)

As a guide  marking considers aspects such as:

did you meet the requirements of this section?

the range  challenge and complexity of the test code.

the  quality  and  structure  of the  test  code.  This  includes  code  quality ,  test  naming  and structure,  documentation ,  appropriate  use  of  assertions,  use  of fixtures  etc.

the  extent  to  which  your  tests  cover  your  code  base.  This  is  not  assessed  using  coverage statistics  since  a  single  selenium  test  can  appear  to  provide  100%  coverage.  It  will  be         assessed  by  evidence  that  your  tests  test  the  core  functions  and  features  of your                       dashboard  and  any  of the  helper  functions  you  create  in  your  code.

use  of supporting  tools  such  as  continuous  integration  to  run  the  tests  e.g.  using  GitHub actions.