Assessment Overview

There are two types of assessments:

• Group Assessments are are approx two-month long, allowing a deep-delve into a specific area of Data Science applied to Cyber Security. They make up a total of 60% of the course mark (two, each worth 30%).

• Individual Portfolios are whole-semester activities, individually undertaken to explore areas of data science covered by the lecture material in greater depth. Portfolios make up remaining 40% of the course.

• Formative Assessments (that do not contribute to grade):
  • Assessment 0 (Due Week 3)
  • Portfolio 0 (Due Week 3)
• Summative Group Assessments: total 60% (each 30%)
  • Assessment 1: Supervised Prediction (First group assessment)
  • Assessment 2: Data at Scale (Second group assessment)
• Individual Portfolios: total 40%
  • Individual Portfolio: Statistical Machine Learning

The Assessments are released in the appropriate Block of the timetable but are also linked here (links are only active when the Block is released):

• Portfolio 01
• Portfolio 02
• Portfolio 03
• Portfolio 04
• Portfolio 05
• Portfolio 06
• Portfolio 07
• Portfolio 08
• Portfolio 09
• Portfolio 10
• Portfolio 11

  Guidance on Individual Portfolios

The Portfolio is assessed on each block from 2-11. Block 1 is marked similarly but is formative, i.e. does not contribute to your mark. The deadline is the start of TB2. In each block you will do two activities:

1. Worksheets: Multiple choice questions submitted via Noteable (log in via Blackboard). These should be straightforward, either direct from your notes or with very simple experiments you can conduct as extensions of the Workshop. These are worth 20% of the Portfolio mark.
2. Reflection: Long-form reflective questions that should require a deeper understanding of the course material and may require you to undertake further reading or experimentation. These are worth 80% of the Portfolio mark.

You may take the multiple-choice component at any time and it is recommended that you do this when you work through the Workshop content. The long-form content is submitted at the end of the course, and you are recommended to make a first draft/note form attempt when you first see the content, and reflect back on it in a finessing stage during the examination preparation time (in lieu of an exam).

Length and format of long-form portfolio

Your Portfolio should give a one-page answer to the question of each Block. Therefore the whole Portfolio is only 10 pages long. However:

• The goal is not to make you undertake a length-finessing exercise. If the content you provide appears as if it would fit on one page after such an exercise, you can submit is anyway. There is a strict limit of 15 pages for the portfolio content, with answers that are clearly too long being be penalised.
• You can however submit Supporting Evidence as an appendix to the portfolio. It will not be directly assessed but may be used as evidence to support your claims, i.e. any statements you make with supporting evidence will be more favourably interpreted, but if your statements are carefully given and correct the evidence is not essential. This is not limited. Appropriate content is RMarkdown files knitted to pdf, Jupyter Notebooks, etc.

Guidance on Group Assessments

There is a complete Example Assessment.

Undertaking a group project online is a difficult process that requires care and planning. Help for planning your project is given in Block 1, and includes:

• 1.3.3 Workshop Lecture on Assessments, listed completely in Block 01.
• The Example Group Assessment, which you should go over carefully.
• Appendix 1: Preparation List.
• Appendix 2: Replicability, which explains how to make your project run reliably on others’ computers.
• Appendix 3: GitHub, which explains how to use GitHub.
• Appendix 5: Bluecrystal, which is our High Performance Computing Infrastructure.
• The Equity Formula for redistributing marks.

The individual assessment instructions has significant guidance. These extra thoughts are less directly relevant but give context.

Comment on Markdown reflections:

The PDF versions of the example reflections are created using Pandoc and it is trivial:

pandoc -o RachelR_Reflection.pdf RachelR_Reflection.md 

Markdown is an acceptable format, though PDF looks nicer. Referencing is important but don’t overdo it; you might use footers [^ref1], or just place simple labels without worrying about Markdown format at all (label2).

[^ref1]: Lawson D, An Example Reference, 2020.

(label2): Lawson D, A Second Example Reference without Markup, 2020.

Comment on Report formats:

It is completely fine to present a well commented Rmd or ipynb file. You are welcome to try to generate a beautiful PDF in which all of the results are knitted together, but it can be awkward if content is fundamentally separated. Yes, you can create a PDF from each file and merge the PDF, and doing so once is educational, but it isn’t the point of DST.

Please commit your final output. It is generally considered bad practice to commit transient content to your repository. This would include the Jupyter Notebook with all of the content competed, and the html output of Rmd. However, for the purposes of generating a one-off assessed report, it is safest to do this, though best only for your final commit.

This is because it is possible that I cannot run your code, for a good reason or a bad, and therefore I want to see what the output should be.

Why is transient content bad? You repository will get bigger and take longer to process as the whole history of everything that you’ve generated is stored. Text files compress very nicely for this content, but binary objects such as images and data, hidden inside html or ipynb files, compress badly.

Comment on data:

Don’t commit very large datasets to GitHub, and don’t commit modestly large ones unless necessary (and try not to duplicate them). There are file size limits, but it is inefficient. Try to use a different data sharing solution, such as OneDrive, for such data.