This list is intended primarily for students on the IT University
study programs MSc Computer Science, MSc Software Design, MSc Data
Science, BSc Software Development, and BSc Data Science.
See also the list of advice in relation
to the thesis presentation and examination.
Planning
Preferably plan ahead so you can make a preliminary project before
the thesis project proper; e.g. in specialization or in a 7.5 ECTS
project. You will learn the basics of the subject matter and you
will learn to work with the supervisor.
Find a supervisor well ahead of thesis start. Look at all the IT
University research groups, not only the teachers you have met in
courses or projects already.
Decide on the thesis project group size; preferably 2 or 3 people.
Single-person projects are more frustrating, more often go off
track, and more often take more than the six months they should.
Decide on the project's goals: what do you want to learn, what do
you want to show, build, evaluate, ...
Decide on the project type and method: construction, theory
development, literature study, ...
Preliminary list of literature. What theoretical contents is
needed?
Other necessary resources: a place to work at the IT University, a
particular server, particular software, particular net connections
through the IT University firewall?
Place of work: The IT University, a company (project partner),
your home?
Make a preliminary schedule that takes into account vacations and
other absence. An MSc thesis project typically lasts 26 weeks and a
BSc project around 18 weeks, so you can use one A4 sheet (29 cm long)
to set aside 1 cm per week. Put in the date of each week, then mark
vacations, exams, weddings and other obstacles. Then work backwards
from the hand-in date to see when you need to finish writing the final
report, when you need to start writing it, when you need to finish
testing and evaluating your software (or whatever), finish developing
your software, finish designing it, finish your literature study, and
so on and so forth.
Expectations concerning supervisor and possible co-supervisor;
distribution of workload over these?
Your own ambitions, expectations concerning final grade, or
expectations that somebody will use what you write or develop?
Planned work besides the project? (At most one day a week, and
not in the final month)
Planned vacation?
Other obligations (child care, chronically ill family members, ...)?
Expectations concerning you future job; do you expect to use your
thesis or the skills acquired during the project when looking for a
full-time job?
What qualifications do you especially want to strengthen during
the thesis project?
In what language do you want to write your thesis report (usually
Danish or English)? It is strongly recommended to get a friend,
fellow student or family member to proof-read the report -- but in any
case it is your responsibility that the report is readable. Whatever
language you choose, make sure that everybody in the group is
comfortable with the choice.
Be aware of intellectual property rights, in particular when
working with a company. In many cases the simplest approach is to
agree that no party (students, supervisor, the company, the IT
University) can prevent any of the others from exploiting the product
in any way after the project. When the result is a piece of software,
a BSD license or an MIT license is a suitable tool to ensure this.
During the thesis project
Maintain a project diary, possibly using a Wiki. This is
especially useful when the goals, requirements or methods are not
really clear from the outset.
Remember to put dates on the documents you write, especially
drafts. Otherwise you supervisor will have a pile of versions and
little chance of deciding which is the newest one.
When you send documents to others, give them a name that makes
sense to
the recipient. Half the documents I receive are called
rapport.docx, draft.pdf, main.pdf or similar. When I receive documents
from six different groups, I really appreciate distinctive file names
such as john-20100626.pdf.
The 2025 ITU rules about using generative AI
(https://itustudent.itu.dk/Study-Administration/Generative-AI)
say that your project report must state how you have used
generative AI during the project, also for coding etc. So keep track
of that.
Make a detailed table of contents, discuss the structure with your
supervisor, and put approximate page counts and planned date of
completion on each chapter. Ask one or more fellow students to read
and comment on the near-final report, both to make sure that report is
comprehensible to people outside the project group, and to avoid the
worst spelling mistakes and other language problems.
A thesis about a software development project can be structured
along the guidelines in Udformning af
Rapporter or Writing Reports.
These guidelines were aimed at four-week projects, but the list of
sections and other advice are nevertheless relevant (and to my
knowledge nobody at the IT University has made guidelines that are
specific to MSc theses).
If the thesis is written in Danish, there must be a summary in
English or another non-Scandinavian foreign language.
There is a huge literature about technical writing, academic
writing, university thesis projects, and so on. The most important is
the goal: The purpose of the report is to present information,
and that you (hope to) have a reader: When writing
your report, you [should] continuously bear in mind the busy reader,
who has only a limited time to devote to your report and who, in
addition, may not be very familiar with your subject. These
quotes are from a NASA document about
technical reports (1964).
An old but interesting piece about project work in computer
science is Peter Naur: Project Activity in
Computer Science Education. Pubblicazione N. A 70-10, Istituto di
Elaborazione della Informazione, Consiglio Nationale delle Richerche,
Pisa 1970.
David Parnas (1986) describes some of the pitfalls in poor
technical communication, which you should strive to avoid:
Boring prose: Lots of words are used to say what could be said
by a single programming language statement, a formula, or a diagram.
Certain facts are repeated in many different sections. This increases
the cost of the documentation and its maintenance. More important, it
leads to inattentive reading and undiscovered errors.
Confusing and inconsistent terminology: Any complex system
requires the invention and definition of new terminology. Without it
the documentation would be far too long. However, the writers of
software documentation often fail to provide precise definitions for
the terms that they use. As a result, there are many terms used for
the same concepts and many similar but distinct concepts described by
the same term.
Myopia: Documentation that is written when the project is nearing
completion is written by people who have lived with the system for so
long that they take the major decisions for granted. They
document the small details that they think they will forget.
Unfortunately, the result is a document useful to people who know the
system well, but impenetrable for newcomers.
Another take on the same topic is Steven
Pinker's The
Source of Bad Writing: As a writer you know so much more than
the reader that it is difficult to understand what the reader will
find it difficult to understand.
William Safire, an American writer, has a brief funny piece about
proper English:
Remember to never split an infinitive.
The passive voice should never be used.
Do not put statements in the negative form.
Verbs has to agree with their subjects.
Proofread carefully to see if you words out.
If you reread your work, you can find on rereading a great deal of
repetition can be avoided by rereading and editing.
A writer must not shift your point of view.
And don't start a sentence with a conjunction.
(Remember, too, a preposition is a terrible word to end a sentence
with.)
Don't overuse exclamation marks!!
Place pronouns as close as possible, especially in long sentences, as
of 10 or more words, to their antecedents.
Writing carefully, dangling participles must be avoided.
If any word is improper at the end of a sentence, a linking verb is.
Take the bull by the hand and avoid mixing metaphors.
Avoid trendy locutions that sound flaky.
Everyone should be careful to use a singular pronoun with singular
nouns in their writing.
Always pick on the correct idiom.
The adverb always follows the verb.
Last but not least, avoid cliches like the plague; seek viable
alternatives.
Usually a thesis is written using Microsoft Word, OpenOffice
Writer or LaTeX. Regardless of the software, make sure to use the
facilities for auto-numbering of chapters, sections and subsections;
for auto-numbering of figures and tables; for automatic
cross-referencing; and so on. Here is an old brief lecture with some
advice about Struktureret
tekstbehandling: MS Word og Latex (in Danish).
In general, avoid footnotes: They interrupt the flow of reading,
mess up the page layout, and too often contain information that is
either completely irrelevant or so important that it ought to be in
the running text. If you as the author cannot decide whether the
information in the footnote is relevant enough for inclusion in the
running text, how do you expect your reader to decide?
Write references to web pages in the list of references, not as footnotes:
[23] Moscow ML homepage. URL <http://raspi.itu.dk/people/sestoft/mosml.html>
Seen January 2010.
But properly published sources are always preferable. Do not refer to
Wikipedia for proof of any point you are making.
In advanced text formatting systems (TeX, LaTeX), write references
to the literature as numbers [23], corresponding to bibliography
style plain. Do not give page numbers when referring, except to quotations.
About generative AI for technical and academic writing
Until the fall of 2022, the ability to produce a large amount of
coherent and grammatically well-formed text could be taken as a sign
of a high education, intelligence, attention to detail, and hard
work. So the production of a long well-formed text could be considered
A Good Thing, or Proof of Competence. Since the public release of
ChatPGT and other generative AI systems, this is no longer the case.
With generative AI, well-formed text is cheap, as it can be produced
by machines in large quantities. But human attention, and the time
needed to read the text, remain scarce, and should not be wasted on
verbose, flowery prose.
Hence we as writers need to ask ourselves: What purpose does this
sentence, this paragraph, this section, or even this dissertation,
serve? Who would learn what from reading it? Who would be motivated to
do so? That is the core question in technical and academic writing.
Generative AI may be useful for shortening text, but it is a crime
against humanity to use it to make text more verbose, to use more
words of Greek or Latin origin, or otherwise more convoluted and
pretentious.
Generative AI should also never be used to "paraphrase" other
works just to evade plagiarism detection tools. A perfectly meaningful
text might get messed up completely. Instead, properly cite and then
copy verbatim: "Following (Driscoll 1989) we define a linked data
structure to be [...]" - provided this quote is actually useful for
your reader. Also, even with rephrasing, copying the work of others
without crediting them is plagiarism.
You may use generative AI as a writing assistant, but first and
foremost you must keep the future reader of your text in mind. Figure
out what the reader needs to know; figure how to convey this to the
reader in the most effective way; do it; then critically revise and
remove superfluous stuff.
Remember that besides ordinary text, effective communication may
involve numbered bullet lists, tables, diagrams, drawings, specific
notation and terminology invented for the purpose, and so on.
Last but not least, a warning that ought to be wholly unnecessary:
Plagiarism is illegal. Why? One reason is that the purpose of
academic work is the advancement of knowledge, so originality is
central. If you copy without reference what others have written,
then you are guilty not only of stealing their text (and labor) but
also of pretending to be original where you are not. (This point is
inspired by a blog post by professor Stanley Fish in New York Times,
August 2010). Hence, if a report contains text, figures or tables
taken from a book, paper or web site without clear and correct
reference to the source and without making it entirely clear that you
have not yourself written that text, then the project is
automatically failed and you risk being kicked out of university.
This holds not only for the final report, but also your
drafts. Fortunately I have never seen plagiarism in MSc theses I have
supervised, but sadly, I have seen it in project reports -- where it
is no less illegal, stupid and dishonest. See also the Study Board's
policy on academic misconduct.
Til slut en, skulle man tro, helt overflødig advarsel: Plagiat
er forbudt. Hvorfor? Blandt andet fordi formålet med akademisk
arbejde er at skabe ny viden, så originalitet er centralt. Hvis man
uden kildeangivelse kopierer hvad andre har skrevet, så er man skyldig
ikke blot i tyveri af deres tekst (og arbejdsindsats) men også i at
foregive at man er mere nyskabende end man faktisk er. (Denne pointe
er inspireret af et blogindlæg af professor Stanley Fish i New York
Times, august 2010). Derfor, hvis en rapport indeholder tekst,
figurer eller tabeller taget fra bøger, artikler eller websider uden
korrekt kildehenvisning og uden at det er helt klart at I ikke selv
har skrevet denne tekst, så er projektet dumpet og I risikerer
bortvisning fra universitetet. Dette gælder ikke blot den endelige
aflevering, men også jeres kladder. Jeg har heldigvis aldrig set
plagiat i specialer jeg har vejledt, men desværre i
projektrapporter -- hvor det er lige så ulovligt, stupidt og
uhæderligt. Se også ITU-Studienævnets
politik om akademisk uredelighed.