Doing an MSc Thesis

This page describes how to do an MSc thesis with me at DTU. Before reading on, please read the official DTU Regulations on the MSc. Thesis. Here you can read the following:

“The objective of the master’s thesis is to give students the opportunity to apply the knowledge they have acquired in an independent way on a larger project that concludes with a written report. The thesis must document skills in applying scientific theories and methodologies to a clearly defined academic topic.” (my emphasis).

Then read Rasmus Paulsen’s guide on choosing the right project with the right supervisor.

Once you have read these pages, you may consult my list of project proposals in the DTU Career Hub for students to work with. All projects are related to my research in personal health technology, and you will be working with a range of other researchers (PhD students) and programmers. Most of my research is centered on the following research areas:

When selecting a topic for your thesis, I recommend you to look at your previous courses and pick the topic in line with your favorite course(s). Note that an MSc Thesis is not a course – you don’t learn anything new – you apply what you already know to a specific project. Hence, if you want to excel in your thesis, you should pick a topic you already excel in.

Your background

Prospective students should:

  • Have a solid computer science background and previous exposure to the research areas listed above (HCI, UbiComp, mHealth) or related areas. This means that you probably are following a master’s degree at DTU Compute, such as:
  • I do consider outstanding students with other degrees (like Biomedical Engineering), but an equivalent computer science background is required.
  • Have taken relevant DTU master courses on HCI, embedding programming, and software engineering, such as
  • Be a strong programmer and enjoy programming – most of my students’ research projects require very sophisticated programming, either because projects involve non-standard interfaces or building underlying architectures.
  • Also, be interested in non-technical cross-discipline aspects of HCI and health, such as sociological or psychological aspects of computer technology, design methods, and thinking, usability & UX (graphical) design, health and disease management, and human physiology;
  • Be able to conduct user studies, including user-centered design, evaluations, controlled experiments, and pilot field trials involving users such as patients, relatives, and clinicians.
  • Team up as a pair – I always recommend an MSc. thesis to be done in a team of no more and no less than 2 persons. However, according to the DTU regulations, you can be up to 4 persons.

Supervision

My supervision is applying a group-based supervision approach. You’ll be able to read more about this here. This basically means that:

  • There is a joint kick-off meeting for all students that initiates supervision.
  • We prepare the project database entry for DTU academic approval after the kick-off meeting. This mainly states: the title, description (10-20 lines), starting date, ETCS points (normally 30), and ending date.
  • Then you start making the detailed project definition report including a plan for your work (see below). The has to be submitted to DTU within 4 weeks of the project. Once this is in place, you follow this plan (unless some radical problems occur).
  • All of my students meet bi-weekly for a joint supervision meeting. Before the meeting, you prepare your progress report (see below). At the meeting, you get supervision from me, and you help each other. Each group has a 20 min. timeslot, so make the best of it (i.e., be prepared).
  • You should work empirically (i.e., doing practical things like coding, analyzing, running test, and evaluating applications) and theoretically (i.e., doing things like reading related literature, writing thesis chapters, and creating nice illustrations) throughout the entire project period. I DO NOT recommend writing the thesis during the last week of the project…
    • You may want to consult my “The Art of Doing a PhD” page – the description here applies equally to doing a thesis project on a smaller scale. Especially the Fish model can be useful.

  • I do not review your final thesis before you submit it. Supervision is a strange thing; on the one hand, I am supposed to supervise you, and yet, on the other hand, I’m also the one to review and grade your thesis. Hence, to see what you can do independently and grade your work, you need to write up your thesis independently. This is the tail of the fish above.

The Project Definition Report

Besides the final thesis, the Project Definition Report (PDR) is the most important thing to write. The PDR contains the following outline:

  1. Project description
    1. Background
    2. Prior work
    3. Research question or hypothesis
    4. Contributions and goals
    5. Empirical and practical considerations
    6. Ethical considerations
    7. Impact, innovation, and application
  2. Intended learning objectives
  3. Plan
    1. Gantt chart
    2. Activities
    3. Milestones
    4. Deliverable, incl. chapters of the Thesis
    5. Risk analysis

Here is an example of a DTU Thesis Project Description Example, as it should look like. Here is a link to the template in Overleaf. One of the most important parts of the PDR is the Gantt chart, which is illustrated below.

According to the DTU regulations, the PDR should be made within the first month of the project. The PDR will be the major discussion item at the kick-off meeting.

Type of Thesis

In my experience, an MSc. thesis can be divided into six main types – all of which are related to the kind of ‘contribution‘ your thesis aims at:

  1. Theoretical – a theoretical thesis addresses a problem entirely theoretical, i.e. makes a contribution which is an abstraction of the problem. This can take many forms; a mathematical model (but then I’m probably not the right supervisor); a computational or simulation model; a conceptual model or framework; or a systematic literature review.
  2. Design – a design thesis focuses on a deep analysis of a particular domain and problem and, through a thorough design process (typically with a deep involvement of users and stakeholders) comes with a system design. Here, the focus is on your problem analysis and design skills, incl. user-centered design method, graphical user interface design, etc.
  3. Technology – a technology thesis focuses on the creation of a fundamental, general-purpose technology that can be used in several applications. This type of thesis appeals to most computer scientists and engineers and is one of the more typical ones I supervise. Here, the focus is on your analytical and technical skills and your ability to create a novel and technically sound system design and implement it. You should also evaluate your technology by creating (at least) two proof-of-concepts that demonstrate the generalizability of your solution. Examples include a programming framework for the collection of activity data from wearable devices using a web API and a software package for building cognitive tests for study apps on Android and iOS
  4. Application – in this type of thesis, you build an application, ie. a hardware/software system that ‘solves’ a problem. Like the technology thesis, this type of thesis also appeals to most computer scientists and engineers. Again, the focus is on your analytical and technical skills and your ability to create a novel and technically sound system design and implement a proof-of-concept of it. But in this type of thesis, the focus is on creating an application that solves a real-world problem for real users/patients and hence involves user-centered analysis, design, and evaluation activities. Examples include designing a personal health technology for behavior change in alcohol misuse or automatic fall detection using phone sensors.
  5. Study – in this type of thesis you take an existing technology (which you did not design yourself) and make a thorough evaluation of it. Study theses fall normally into two broad categories; (i) technical study and (ii) user study – but when working in health technology, a third type exists; (iii) clinical study. In a technical study, you evaluate a system’s functional and non-functional software architecture qualities (e.g. scalability, security, etc.). In a user study, you run a detailed usability study of the technology. In a clinical study, you run a study with patients to assess the feasibility of the system for clinical use (note that providing real-world clinical evidence will almost always be outside the scope of an MSc. thesis – this often requires a PhD project).
  6. Dataset – this is a sub-type of the “Study” type of thesis where the purpose is to collect, structure, and make available a dataset. In this type of thesis, the focus is on (i) creating a well-design data collection protocol, (ii) recruiting a set of study subjects, (iii) executing the study collecting the data, (iv) cleaning, structuring, pre-processing, and documenting the data collected, and (v) make the dataset available (e.g., at DTU Data).

It is of crucial importance that you upfront (in your PDR) decide which type of thesis you’re aiming at. I cannot emphasize this enough; I’ve seen a number of students struggling because they didn’t decide what they wanted to do with respect to the type of thesis, i.e. what the main contribution (aka ‘story’) of their thesis was. It is also important that you tell your supervisor what kind of thesis you’re doing – the choice of external examiner (Danish: ‘censor’) highly depends on this, and you don’t want your thesis being examined by the wrong type of examiner…!

Having said that; most theses contain elements of several types; it is hard to build a system without doing a design, and it is a strong addition to a system thesis to also do an evaluation or study. However, the important part is here; what is your main problem statement and contribution?

For your inspiration, here are some MSc theses, one of each type:

Theoretical

At the time of writing, I don’t have a good example of a theoretical MSc. thesis.

Design

In 2018, Lys Egholm Andersen and Alina Gabriela Ciobanu did a thesis on “Echo: guided self awareness. Using personal data to support client self awareness through therapy“. This is a very good example of what I would call a ‘design thesis’ because it details the design of a specific app, including the design process and methods applied.  It also contains good examples of the different “design artifacts”, including the entire overview and micro-interactions of the final design.

A more recent (2020) example is the thesis “Breaking the Cycle of Addiction by Design” by Margarita Genova and Nermen Ghoniem who did a very thorough design process and produced a set of impressive design artifacts.

Technology

Several of my MSc Thesis students contribute to the CACHET Research Platform (CARP) with different technology components, some of them being published as open source. Examples include:

  • “A Flutter Package for Real-Time Mobility Feature Computation” by Thomas N. Nilson (2020). [pdf] [GitHub] [pub.dev].
  • “Removing Code Duplication Through Code Generation for Kotlin Web Services” by Mathias E. Boon (2020). [pdf]
  • “The Gardener Framework – An open-source programming framework for the collection of wearable activity and health data from web-based services” by Richard Pekk (2022). [pdf] [Github].

Application

In 2008, Niels Nørskov did a thesis on “Improving Patient Safety in the Operating Room Using Context-Aware Technologies and RFID” which resulted in the design of the “Context Aware Patient Safety and Information System” (CAPSIS). This was later turned into a scientific publication [1].

More recent DTU examples include:

  • “Personal Health Technology for Behaviour Change in Alcohol Misuse” by Andrea Quemada (2018). [pdf]
  • “Mobile Health Application for Self-Administered Evaluation of Neuropathy” by Julia Gabriela Makulec & Mads Westermann (2023). [pdf]

Study

In 2008, Sanne Jensen, Joan Nielsen Meyer, Jesper Dahl, and Annabel Lee Krarup did a study of the CAPSIS system. This study was done in a simulated clinical environment at the IT Experimatarium at Herlev Hospital. The thesis – entitled “AXHIS: Metode til vurdering af it- systemer inden implementering” (in Danish) provided both a thorough evaluation of the system as well as a proposal for a systematics clinical simulation methodology. Later, Sanne Jensen continued this work in her PhD Thesis [2].

Dataset

I don’t have an example of an MSc Thesis creating a dataset. But we did create a dataset as part of the REAFEL / mCardia project, which is published at DTU Data and documented in a paper [3], which to a large degree resembles what an MSc Thesis on a dataset would look like.

Supervision Meetings – the PPP Model

As said above, I always run group-based supervision. This has a lot of benefits, not least that you are able to help each other. I expect all my students to be open-minded and helpful towards each other. Some are good at solving technical problems, others are good at LaTex, and others are good at writing. Often you would also help each other in the different studies you are doing when evaluating your technology or application.

So – please help each other out!

In the meetings, we use the PPP model, where each group/student presents:

  • Progress – what have you done since the last meeting? You should prepare and show tangible artifacts that you have worked on. This can be the project plan, a literature review, some UX design, a software architecture, code, a running demo, or even some hardware setup.
  • Problems – what problems, challenges, or questions do you have? What do you want to have my – and the rest of the group’s – input on?
  • Plan – what do you plan to work on for the next 2-week period? Do you need me or others in the time in between supervision meetings?  Note that I run a pretty tight schedule, so it is important to book me for supervision outside the bi-weekly slots.

Supervision takes place in person in the “lab”. I do not run hybrid supervision meetings with students online, since this has turned out simply not to work.

Legal Notes

As a “regular” (i.e., BSc and MSc) student in Denmark, you are a legally independent entity. This means that whatever you do, is at your own risk and responsibility, and you make or sign your own contracts (since you are not employed at DTU). This entails three things (at least):

  • You are solely responsible for what you do in your project. If you invite participants to join your project or act as subjects in a study, you are responsible for what is going on. This often entails obtaining informed consent from study participants, for example. Of course, I will supervise you in this, but legally speaking, it’s your responsibility.
  • On the flip side, you own all intellectual property (IPR) you may produce, including design sketches, prototypes, graphics, source code, datasets, etc. If someone – like DTU or a company – wants to use or get access to your IPR, you should make a contract with them. For source code, another option is to release your code as open source, thereby allowing everyone to use (“fork”) your work.
  • Any contract you may need to agree to or sign, you do this on your own. This applies to Non-Disclosure Agreements (NDAs) e.g., with companies, Data Management Agreements e.g., with a hospital (accessing clinical data), or IPR contracts e.g., handing over IRP to a company. Note that I DO NOT sign any contracts (incl. NDAs) as part of supervision (I am not allowed to do this, since I’m employed at DTU).

(Note that this does not apply to PhD “students” since they are employed at DTU and hence not students, legally speaking in Denmark.)

For the above reasons, if you choose to do a thesis based on my project proposals and work on a research project associated with me, you most often would need to sign a so-called “G Declaration” that handles “Confidentiality” and “Assignment of Rights to Software” to the Technical University of Denmark.

Writing the Thesis

According to the DTU regulations for the MSc Thesis, the thesis must be written in English (otherwise, approval from the Head of Studies must be obtained).

A Thesis is structured according to the type of thesis. However, chapter 1 is almost always structured in the same way, as described by Saul Greenberg on his “Deconstruction Chapter 1” page.

As Saul Greenberg puts it:

“Almost all chapter 1’s contain the following structure. You can use this as a ‘formula’ to create your own draft of Chapter 1. Of course, you can alter and deviate from this formula, but only do so if you have a good reason for it.”

Please always follow this outline.

Chapter 2 is almost always a literature review of related work (the chapter is often entitled “Background and Related Work”). Again, Saul Greenberg has a good description of how a literature review can be done. Note, however, that this guide is targeted PhD students, and as an MSc student, you should only include a lighter version of a literature review.

I am often asked whether commercial systems should be included in the “Related Work” chapter. This is a tricky question, and the answer is “if relevant”. For example, suppose you’re doing a thesis on a particular type of technology. In that case, there might be relevant commercial technologies to introduce and discuss to show what you’re doing is similar/different/related. But remember that it should be commercial technologies relevant to what you are doing, i.e. technologies that address the same research question. It is not relevant to discuss commercial technologies that you have used to build your own system (e.g., docker, Kafka, Spring, …). These are “merely” tools or implementation details, which are presented later in the thesis.

Patents are very rarely included in chapter two.

Length of the Thesis

I’m often asked what the length of the thesis should be. Well – there are no formal requirements. However, the following guidelines apply:

  • You should use the DTU Latex template (see below), which sets the standard for font size, etc.
  • A typical thesis is 40-70 pages long for the main sections, excluding pre-matter (summary, foreword, table of contents), bibliography, and appendices.
  • But – a thesis must NEVER exceed 100 pages.

You should make clever use of appendices where you can put details that you want to document, but which are less important to the main story of the thesis. This includes detailed design diagrams, interview transcripts, pictures, detailed statistics (including graphs), etc.

Stating “Distribution of Contributions”

According to National Danish regulations, grades are given on an individual basis. Therefore, if you are doing an MSc. Thesis as a group (which I, as mentioned above, recommend), it is essential that it is clear which group member did what. There are two ways to do this:

  1. Each chapter has a separate author. In this case, the thesis is like an edited book, with each chapter written by someone. And, of course, the person who wrote the chapter also did the work/research described in this chapter.
  2. You include Appendix A entitled “Distribution of Contributions”, which in detail outlines for each group member what s/he did – both in terms of the empirical work (e.g. interviews, transcribing, coding, testing, evaluation) and in terms of writing the thesis.

It is NOT permitted to write something like “The work was done equally by all group members”.

Note that if the distribution of contributions is not explained, we cannot evaluate the thesis and hence grade you!

Hand-in

The main hand-in is clearly the Thesis, as explained above.

However, relevant empirical material should also be handed in or made available for download. Examples of empirical material are:

  • Source code – can be made available, e.g., on GitHub or as a zip file.
  • Binary files, an executable application that can be installed and run “out-of-the-box”.
  • Dataset – a data set collected as part of a study.
  • Analysis scripts – like Jupyter Notebook or MatLab scripts
  • Design artifacts – like physical mockups, pictures, graphics, and mock-ups (e.g., in Figma)
  • Video – a video (e.g., on Vimeo) that shows a demonstration of an application or the execution of a study (e.g., collection of data from participants)

Note that it is essential to nicely structure and document this empirical material. You should add README files to Github repros, make API documentation, make documentation of analysis scripts, put your design artifacts in a nice “portfolio”, and make proper speech and/or text in the video(s).

A big unstructured zip file with stuff you have on your hard drive is NOT a good submission.

Oral Exam

Sune Lehmann has provided an excellent description of how the MSc. Thesis oral exam runs. Please read this.

I have only two additions:

  • I always recommend making a DEMO of your main contribution during the exam. This can be a live demo of an application, showcasing some infrastructure processes communicating, or showing interactive UX design prototypes. Also, images or videos from real user studies are a very strong addition to your presentation.
  • In line with the description above, we grade you on an individual basis. This implies that each group member will have his/her own individual oral exam. This is also stipulated in the DTU regulations for the MSc Thesis.

Practical Things

  • We typically use Slack for coordination and communication. Each project has a separate channel.

LaTex

If you’re doing a thesis with me, it is mandatory to write your thesis, PDR, and progress reports in LaTex. There is plenty of support for LaTex at DTU, including different thesis templates.

Resources

There are a lot of resources available online which can help you write a good thesis. Below is a list of such resources with some small meta-comments on why I find them useful.

  • How to Write a Thesis, According to Umberto Eco. This essay is an excerpt from Umberto Eco’s book “How to Write a Thesis” and contains a lot of good advice on how to write proper English. Students – and certainly technically minded students – often struggle to write proper English, and this essay may help a little.
    • Using spelling and grammar tools is a small but important help in writing proper English. I highly recommend installing and using Grammarly (and/or ChatGPT).
  • How to make reports – and improve your grades. This essay has several good guidelines for structuring a technical thesis at DTU. One core message is the “Two-page Rule“, which states that; “one person can produce two pages (only 2 pages!) of quality text in one day“. I also find this rule valid, so please plan for ample time to write your thesis. For example, a typical thesis is 60 pages, and according to the two-page rule, this will take you 120 (working) days to write – that is 4 months! So – you’re already behind before you even start your thesis. Hence, my advice is to start writing (parts of) the thesis from the very beginning.
  • “Many students carry out excellent projects, but they get too low grades considering the amount and quality of work they have produced”. In this essay, Andreas Bærentzen tries to help you write a good thesis that reflects all the good empirical work you have put into the project. The essay is old (2006) and talks about 11 and 13 grades (who remembers these?), but the text and the bits of advice apply equally today.
  • Saul Greenberg’s Grad Tips. These pages have a lot of good advice on how to “survive” graduate school, which in the US/Canadian system is similar to an MSc. Thesis.  In particular, I highly recommend reading his advice on How to Structure Chapter 1.

References

[1] [pdf] J. E. Bardram and N. Norskov, “A Context-aware Patient Safety System for the Operating Room,” in Proceedings of Ubicomp 2008: Ubiquitous Computing, 2008, pp. 272-281.
[Bibtex]
@inproceedings{ubicomp2008:bardram,
Author = {Jakob E. Bardram and Niels Norskov},
Booktitle = {Proceedings of Ubicomp 2008: Ubiquitous Computing},
Pages = {272-281},
Publisher = {ACM},
Title = {{A Context-aware Patient Safety System for the Operating Room}},
Url = {http://portal.acm.org/citation.cfm?id=1409672},
Year = 2008,
}
[2] [pdf] S. Jensen, “Use of Clinical Simulation in Development of Clinical Information Systems,” PhD Thesis, 2014.
[Bibtex]
@phdthesis{jensen2014use,
title={Use of Clinical Simulation in Development of Clinical Information Systems},
school = {Aalborg University, Denmark},
author={Jensen, Sanne},
year={2014}
}
[3] [pdf] D. Kumar, S. Puthusserypady, H. Dominguez, K. Sharma, and J. E. Bardram, “CACHET-CADB: A Contextualized Ambulatory Electrocardiography Arrhythmia Dataset,” Frontiers in Cardiovascular Medicine, p. 1702, 2022.
[Bibtex]
@article{kumar2022cachet,
title={CACHET-CADB: A Contextualized Ambulatory Electrocardiography Arrhythmia Dataset},
author={Kumar, Devender and Puthusserypady, Sadasivan and Dominguez, Helena and Sharma, Kamal and Bardram, Jakob E},
journal={Frontiers in Cardiovascular Medicine},
pages={1702},
year={2022},
publisher={Frontiers}
}