20
CHAPTER 1. INTRODUCTION
intervals during the day. The ESM approach opens for other possibilities than just asking participants questions related to how they feel under certain circumstances. Instead of asking questions at predefined time intervals, a mobile device can be equipped with sensors allowing it to collect context information surrounding the mobile user. Many new mobile devices have Global Positioning System (GPS) as a built-in feature, hence the device can prompt questions dependent on the geographical position of the device, or store information about where the user has been. It also opens for the possibility of presenting a participant with information when and where he or she might need it [3].
1.2
Problem Definition
The main focus in this thesis is to develop a software tool for simplifying the process of creating, running and collecting results from surveys based on the ESM approach. The development shall be done with help from the middleware platform known as Argos1 to clarify how applications built on top of Argos can benefit from its features.
1.3
Interpretation
From the problem definition we have split the software development in two parts: • Design and develop a desktop application for creating, distributing and collecting results from ESM-based surveys. • Design and develop a generic ESM engine for running the actual surveys on PDA devices. Due to the limited amount of time available in this thesis, the software tool will be developed as a prototype. When building a new software system it is very important to focus on the acquisition of the knowledge that is to complete the system, rather than actually building a fully functional system. In [4] this is illustrated through a very simple example. Starting out coding a new system a lot of functionality is added to it and during the development cycle various testing is performed to verify that the system behaves intentionally. During this process one can make a separation between knowledge and non-knowledge. The first is the one we want, while the second is errors or behaviour that we do not want the new system to employ. The non-knowledge is removed from the developed system, and at a certain state the system contains only the wanted knowledge. Even though the system does not contain the non-knowledge, there may still be leads to where in the code they actually occurred. Only the developer knows and understands what would have to be redesigned to remove it completely. Over time he or she might forget it or stop working for the company that made the system. The company will have a working system, but no one that knows why certain parts of the code may lead to errors due to faults in an early phase of the development. The process one should follow is to rewrite the code once all the necessary knowledge is in place. The process of rewriting the code should be rather quick if the observations done in the first phase are documented and well understood. This approach is called prototyping and will provide us with knowledge about a future system. 1
http://argos.cs.uit.no