Overleg:Onderzoeksmethoden 2/het werk/2011-12/Group 1

Uit Werkplaats
Ga naar: navigatie, zoeken

Meeting 10 october

Interview subjects

  • Jan Broos
  • Harko Cuppens
  • Ronny Wichers Scheur
  • Jan Michels (pilot)

Some things about the interviews

  • ~ 30 minutes
  • Record audio
  • Paper and pen for drawing diagrams
  • Record video for drawing diagrams? (test in pilot)

Topics

(in order)

  • Introduction
  • Goal
  • Structure
    • Hierarchy
    • Tasks and processes
  • Communication


Steps in creating interview

  1. Define the goal of the interview: The goal of the interview is to generate texts in which subjects describe the organisation in which they work.
  2. Define the theoretical variables (conceptual schema): We are asking for the model and the vocabulary. For the first we are interested mainly in the objecttypes and the facttypes used by the subject. For the second we are interested in the nouns and verbs that the subject uses in sentences that describe the organisation.

Another important element in the conceptual scheme is relevance of text

  1. Define the indicators (reference scheme)
  • for objecttypes we will use nouns
  • for facttypes we will use verbs
  • for words (verbs and nouns) we don't need indicators
  • for relevance of a piece of text we have no indicators yet other than our judgement that the piece of text is about the organisation.(what when pieces of text are about organisations in general or part of the description of a contrast case?)
  1. Line up rough variables for the interview: I don't know what this step means
  2. Create an answer- and recording system: I don't know what this step means
  3. Create instructions for asking the questions: Do this in the paragraph interview instructions
  4. Create a logical order for asking the questions
  5. Describe lay-out, intro and closure
  6. Creating the conceptual schema
  7. Finalizing the definitive schema



Planning

  • Wk 42: Have concrete questions
  • Wk 43: (meeting tuesday) (Niels back wednesday) Interview finished
  • Wk 44: Conduct pilot, Finish coding scheme
  • Wk 45: Discuss pilot
  • Wk 46: Conduct interviews
  • Wk 47: Conduct interviews
  • Wk 48: Transcribe / Coding
  • Wk 49: Coding / Writing
  • Wk 50: Writing / prepare presentation
  • Wk 51: Presentations



any comment on the alternative introduction? will we use it or use the existing one?
Niels Braakensiek.jpg
Niels BraakensiekOnderzoeksmethoden 2 Remove this comment when resolved!

Alternative introduction:

Making models of a domain is one of the tools used in software engineering. A more or less formal model is made to describe a domain. Based on one or more of these models design decisions are taken both about what the application has to do and how this could be best implemented. In a relatively good situation an IT engineer communicates with the intended users and other domain experts and from that makes the models. When the models are finished they need to be validated but there is a problem. The models are expressions in modelling languages that are made by and for IT people. The people from the domain that need to understand the model in order to validate it more often than not don't. A attempt to solve this problem is to let the domain experts make the model. This can be done but it turns out that you need to train the domain experts in the use of the modelling languages. This makes it an unusable alternative for two reasons. The domain experts don't want to learn these languages and even if they do the training is so long and intensive that is costs way to much to learn all the needed domain experts to express themselves in the modelling languages of the IT branch.

An interesting possibility would be that the IT people make an effort to understand the people in the domain on a deeper level, make an effort what they mean when they use certain words and what words are relevant for the meaning of central concepts. When IT people can understand this they could create a custom modelling language for use by one person or group of persons. These persons could manipulate the concepts in the language because the behaviour would be very close to what they expect of the concepts as they use them in the wild and underneath the model created would still have certain formality. This formality would make the models amenable to connection to the modelling constructs in use in IT. There are a few points of interest when we start discovering the way a person thinks and talks about a domain. What words and concepts are used to describe the domain, what mental model is behind the talking, what do the concepts used mean. These points are interdependent.


The domain we are mainly interested in is organisations. We are interested in the words, concepts and models that people use to talk and think about organisations. We think that a combination of interviews and text analysis could be an interesting possibility to discover more about these. The following wiki page intends to give an impression of an attempt to show that it is.