Investigation & Reporting

Course overview

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)

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

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.

The architecture of investigation

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

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.

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.

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.

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

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.

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.

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.

Literature review

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

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)

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.

Exercise B Notice, this requires some reading as well

Self monitoring

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.

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.

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

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.