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?
You 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.
Are there rules about how long the thesis report should be, how
many hours should be spent on the project (by students and
supervisor) and so on? No but there used to be Guidelines
approved by the board of studies; however, they moved somewhere else
and now (July 2017) I cannot find them. In any case, use any guidelines as just
that; it is your responsibility to make maximal sense of them.
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.doc, 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.
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 your writing.
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 a 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://www.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.
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.