University of Leeds Empirical Investigation Tips - 1. Introduction

👋🏼 Hi! I’ve graduated with a degree in Computer Science from Leeds University last year, and had a pretty successful project (in my opinion 😅) so I thought I’d share some small tips that could help with the project report.

I gathered these tips from my supervisor and assesor’s feedbacks, excessive googling as well as by attending several writing seminars provided by the faculty.

Please note that this is my personal tips limited to Empirical Investigation (EI) type of project, and you should definitely discuss with your supervisor / project holders!

Table of Contents

- [Aim](#aim)
- [Objectives](#objectives)
- [Deliverables](#deliverables)
- [Tasks, Milestones and Timeline](#tasks-milestones-and-timeline)
- [Risk Assessment](#risk-assessment) <!-- TOC END -->

Aim

• The aim of the project is briefly identified in the project proposal. Of course you can go in and make it more detailed, but I kept it as it is.

Objectives

• 💡 When writing objectives, phrase it as a ‘yes’ or ‘no’ question. Make it tickable!
• Why? It will be easier later in the evaluation section, when you measure the success of your project.

Don’t	Do
Academically research and review the existing architecture.	Identify the key issues in relation to edge computing performance.

• Do you recognize the difference here?
• You can’t measure if you’ve done the job with the first objective. Whereas, for the latter, there are going to be issues that you have clearly identified.

Deliverables

• It is likely that an empirical investigation project would produce a report, not a code. You can list the sections of the report that you’d deliver. It would be something like:

  1. Background research
  2. Experiment design
  3. Experiment implementation
  4. Technical evaluation
  5. Project evaluation.

Even if it seems brief, this is good to go!

Tasks, Milestones and Timeline

• I combined these three into one section - simply said, I have:
  1. Gantt chart
  2. Step by step explanation of each step of the Gantt chart
  3. Identified the milestones from 2.

Tasks and Timeline

• This is where your trusty Gantt chart comes in. The tasks and the dates are going to change a million times, but its okay!
• You can always update the Gantt chart anytime when there’s a change of plan, and the older version can go into appendix. Not necessary though!

Milestones

• 💡 It is super important to manually point out your milestones!! It is enough to mark it as a (Milestone 1) just like from the screenshot above.

Risk Assessment

Risk = Likelihood * Impact.

• It is less likely that something very risky would happen throughout the project. But think about it from different point of views such as:
  • Supervisor availability
  • Software/ Program availability
  • Software troubleshooting
  • Personal events / illnesses.

• I calculated my likelihood and impact both on (1-5) scale. so the risk range was (1-25).

✍🏼 Next time, I’ll write more about the background research/ Literature review! I completely re-did them in April - was hectic, but was worth it :)