1. Investigation & Reporting

2. Course overview

3. Course idea The requirement to your bachelor thesis include:
In the final bachelor project, the student must demonstrate the ability, on an analytical and methodical basis, to process a complex and practice-related problem to a specific task in the IT field
There are three parts to the course:
How to make a systematic investigation
To do it in practice
Report your findings (written and oral)

4. Corse overview Theory part: Overview, literature and reflection
Prototypes and evaluations
Code analysis and Performance
Interviews and Qualitative Methods
Project in one of the other classes
Reporting
Writing workshop
Presentations

5. Exam Exam is part of what is done in the last part of the course.
You must write a blog entry about your investigation
You must give feed back to one blog
You must give a presentation of your work
You must revise your blog entry
You must then individually write a review of one other blog, and recommend literature
Grades will be given on January 4th.
Reexam will be to do a week-long take home exam with a new report and oral exam based on report.

6. The architecture of investigation

7. The architecture of investigation
Outlook
discussion
Initiating
problem
statement
Evidence
Evidence
Evidence
Evidence
Problem
Statement
Conclusion

8. Initiating problem statement
It is the problem that caused the work to be initiated. As such, it will not change over time. Over time it might turn out it was naïve, overly broad, no longer relevant, etc. But in any case it was the issue that caused the work to be initiated.

9. The narrowing phase
Mostly it consists of background material that is necessary to be able to state the narrow problem statement concisely. Sometimes that background material is in part a related work section. Sometimes the related work is a work package. It depends on the concrete problem statement.
In addition, it relates back to the initiating problem statement. Some times the delimitation will be argued from initiating problem statement, other times delimitation can be done based on interest.

10. Problem statement Short few line statement.
In order for those few lines to be readable a significant amount of background material might be needed to be presented.
When working with concrete problems statements relating to specifics in concrete companies, it is for instance mostly necessary to introduce company and some relevant products to allow the reader to appreciate the problem statement.

11. Work packages provide evidence
This is all the work to be carried out to reach a conclusion.
Work packages depend on the problem statement, but include argumentation based on:
Literature, blogs etc.
Prototypes
Measurements
Interviews

12. Conclusion
It should answer the problem statement based on the work packages. New material or perspectives should not be included here.
Sometimes when writing the conclusion ideas for new work packages surface.
Writing a preliminary conclusion shortly after the problem statement is formulated and initial work packages outlined is useful.

13. Outlook discussion
The conclusion did not answer the initiating problem statement but the narrow problem statement.
The work packages have (hopefully) been saying more than strictly needed to answer the problem statement in the conclusion.
The widening at the end of the report draws some presumed consequences of the conclusion in relation to the initiating problem statement.

14. Pragmatics One do not (need to) work from left to right.
One has to understand the overall picture at all times, and can then fill in in what ever order one wants.
It is good to get some version of the problem statement and intended conclusion nailed early on. But often be prepared that the problem statement move and adjust both all the way up to the deadline.
Sometimes you have wish to do specific work packages. The model serves well to highlight what is needed in a thesis beyond the work package.
Mostly there is a hidden motivation and initial problem statement that lies behind the wish to do said work package.

15. Literature review

16. One should not reinvent the wheel
You must know what is best practice in your field
You must know which sources of information can be relied on to be on the edge.
List of popular sources:
Stackoverflow
Officiel dokumentation (for system X)
Thought Ram (angular 4)
Youtube
Mooc courses
Code project
Lynda
Tutorialspoint
Google Scholar
Reddit
Github issues på ens system
Google generelt
Diskussions for a
Slack channels
Wikipedia

17. True/False and Know/Believe
KNOWN
TRUE
BELIEVE
Where do we want to be?
How can we know we are there?
FALSE
KNOWN
FALSE
BELIEVE
Assess the argument and “work packages” done to claim a statement
Try to validate by “doing it yourself” (next week).
The one claiming has been right in many other respects (stackoverflow principle)

18. Exercise A See course home page for today
Type the sources you find in the scrapbook
Which of the following two questions do you expect will be easiest to answer? 
What are the three most important problems with using Scrum
What are three important problems with using Scrum
Try to find evidence for one problem in using Scrum, and try to assess the validity of the claims.

19. Exercise B
Notice, this requires some reading as well

20. Self monitoring

21. Reflect on your…. Sometimes (and in your thesis) you will be asked to:
Reflect on your experience. For example:
Reflect on how you used test driven development
Reflect on how you used micro services
Reflect on how you could have improved the architecture
One important way of documenting your work is to base your reflection on a diary.

22. Technical diary Think of it as a personal log.
Many short entries are better than few short.
It can help you in documenting things like:
How long did it take to do X
What misunderstandings arose
Which micro-experiments were done
Which false leads were taken
When you have an objective diary, you can better look on happened. You will then be able to argue from your concrete experience that so and so must be the case.

23. Method for technical diary
Keep the diary in the source code project (so it is at hand)
Set a timer for every X minutes (typically every hour or so)
Write short entries (must be possible to do in 2-3 minuttes). For example:
Datetime stamp
Problem being working on
What file you are working in
What is currently your frustration
When you were last in contact with your team-mates
URL of example or idea you are trying out
When you expect to be done with this micro-task

24. Week exercise Read the exercise
Make a brainstorm session with two others on the exercise of the week - the purpose is to find out which topics need to be resolved.