Analysis - Overview
Analysis Overview
Overview of Material
•How do we analyse qualitative data?
-What type of analysis
-Elements of analysis
-Inductive and Deductive analysis
•Grounded Theory
-One method for analysing qualitative data
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Qualitative Data Analysis: An Overview of Grounded Theory and Techniques, Study notes of Computer Science
An overview of qualitative data analysis, focusing on the grounded theory approach. It covers the process of open coding, axial coding, and selective coding, as well as the importance of theoretical sensitivity. The text also includes an example of how to apply these techniques to software engineering data.
Typology: Study notes
Pre 2010
1 / 21
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Qualitative Data Analysis: An Overview of Grounded Theory and Techniques and more Study notes Computer Science in PDF only on Docsity!
Analysis - Overview
Analysis Overview
Overview of Material
• How do we analyse qualitative data?
- What type of analysis
- Elements of analysis
- Inductive and Deductive analysis
• Grounded Theory
- One method for analysing qualitative data
Analysis Overview
Objective
• Fieldwork produces
- Voluminous raw data
• Analysis turns this raw data into findings
- Search for patterns in data
- Ideas that help explain why those patterns are there
• Analysis process
- Organise fieldnotes into readable narrative descriptions
- Major themes/categories identified
- Illustrative case studies provide
Analysis Overview
A quirk of grammar
• Qualitative Data Analysis
- Qualitative Analysis of Data (what kind of data?)
- Analysis of Qualitative Data (what kind of analysis?)
• Four possibilities
- Qualitative Analysis of Qualitative Data
- This is what we will primarily focus on
- Qualitative Analysis of Quantitative Data
- The search for meaning of quantitative data (in some senses there’s always some qualitative analysis of quantitative data
- Quantitative Analysis of Qualitative Data
- Turning data from words and images into numbers, “descriptive statistics”
- Quantitative Analysis of Quantitative Data
Analysis Overview
Three Elements Common to All Analysis
• Data reduction
- The process of selection,^ focusing,^ simplifying,^ abstracting the raw data
- Going on throughout the qualitative research study
• Data organisation
- The process of organising the reduced data in ways that allow you to begin to generate explanations + Little of this early on, gets more significant throughout the study
• Data explanation and verification
- Drawing conclusions from the explanations (organising the explanations)
- (^) Most intensive at the end
- Testing the conclusions drawn:^ verifying their plausibility
Analysis
Inductive or Deductive
• Inductive Analysis
- Let the analytic themes emerge from the study of the data
- Happens in the exploratory phases of analysis
- Early to middle phases of explanation development
• Deductive Analysis
- Starting with a hypothesis for data analysis
- Happens in the confirmatory stage of analysis
- Middle to late phases of explanation development and confirmation
• Maybe conducting both Inductive and Deductive
- In one study because some concepts further developed than others
Grounded Theory
One Approach to Data Analysis
Grounded Theory
Overview
• What is it?
• How do I do it?
• Concepts
- Theoretical Sensitivity
- Open Coding
- Axial Coding
- Selective Coding
• Illustrated with an example
- From my own research!
Grounded Theory
Getting Started
• Before you commence analysis
- Theoretical sensitivity is about developing insight into data
- Being able to give the data meaning, understand it, and separate pertinent from not
• Theoretical sensitivity
- Use literature: readings on theory, research, and supporting evidence
- Ground yourself in the multiple contexts that surround the data your analysing
- Professional experience
- Use background knowledge of practioners in the field (including yourself)
Grounded Theory
Example: Theoretical Sensitivity in Software
• Prior to analysis of start-up data
- I did the following things to enhance my theoretical sensitivity
• Literature: software engineering
- Followed ICSE proceedings, SCM workshop etc. to understand CM
• Professional experience: get others insights
- Followed CM usenet group to learn about practice of CM manager
Grounded Theory
First Step: Open Coding
• Open coding
- Process of breaking down,^ examining,^ comparing,^ conceptualising and categorising data + Data reduction (although it doesn’t feel like “reduction” when you’re doing it) + Inductive
• Open coding consists of
- Labelling phenomena
- Discovering categories
- Developing categories:^ properties and dimensions
Open Coding
Labelling Phenomena
• Break down raw full descriptive field notes
- By asking questions about notes
- What is this?
- What does it represent?
- For each phenomenon (incident,^ idea or event)
• Give each discrete phenomenon a name
- Give it a name that captures its essence in a more general way:^ concept
• Compare it to others already discovered
- Could it be labelled in a way that others are labelled preserving integrity
Example
Open Coding
• Context
- Interview with a software developer about her work Well I try to avoid parallel development, I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work, which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Example: Open Coding
Phenomena
• Phenomena: events being described
- Parallel development
- Merge
• Picked these because they seemed to be main acts
Well I try to avoid parallel development , I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work, which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Example: Open Coding
Category Discovery and Development
• Category
- Initially, code coordination, but too broad so Individuals coordinating code
• Properties and Dimensions
- Work : that varies from independent to dependent
- What’s being talked about here? Work talked about -- see italics
- Module Change : varies from separate to the same
- Changes to the code, modules specifically, described in detail Well I try to avoid parallel development , I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work , which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Open Coding
Practical Moment
• Computers probably useful for open coding
- Sadly, I’ve never done that way—I’m still manual
• Initially I used post-it notes for each concept
- And a large flat surface
- My slide door wardrobe which I then could not get into for several days
• Now I tend to use absurd numbers of 3x5 cards
- And a floor or conference room table
- One colour for concepts,^ one concept per card
- Another colour for categories, one category per card
Axial Coding
Intervening Conditions and (Inter)Actional Strategies
• Intervening Conditions
- Broader structural context pertaining to category
- Space, time, culture, economic status, technological status, career, history, biography
• Action/Interactional Strategies
- Particular emphasis of Grounded Theory: it focuses on action & interaction
- What actions do individuals take with respect to the category
- How do groups or collectives interact and act with respect to the category
Axial Coding
Consequences
• Consequences
- There are always consequences :-)
- Here it means the outcomes of the (inter)actional strategies
Example: Axial Coding
Casual Conditions
• Individuals coordinating code
• What causes individuals coordinating code?
- bad management
- bad code
- being in the same part of the code Well I try to avoid parallel development, I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work, which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Example: Axial Coding
Context
• Individuals coordinating code
- Work : that varies from independent to dependent
- Dependent work
- Module Change : varies from separate to the same
- Same changes Well I try to avoid parallel development, I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work, which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Example: Axial Coding
Consequences
• Individuals coordinating code
• Not keeping things separate
- Leads to a mess (another negative example)
• Separation leads to ease
- Of interaction (positive example) Well I try to avoid parallel development, I grumble about it, to me it's out there, it happens in our company and in others, but it seems to me that if there's better management and better decomposition of problems then should be avoided. Number 1 solve it by keeping things separate as far the units of work, the resolutions of work, which in our case is source files, and number 2 when you go about assigning this work you could try and assign common problems to the same person so they are not doing parallel development. ... What has to happen is the last guy who checks something in has to merge these two together, and merging to be honest is generally pretty easy, as long as the people aren't working on the same checks in the code. If I'm working at the top of the file and somebody else is working on something and the bottom of the file then it's fairly easy to merge unless those changes change the overall algorithm, then it gets messy.
Example:
Open and Axial Coding
• Open Coding
- Concept: “Toy Car”
- Properties and Dimensions:
- (^) Place: Public - Private
- Control: Moving - Letting Go (not quite right name)
• Axial Coding
- Casual Conditions: sitting down, being still
- Context:^ public setting letting go
- Intervening Conditions: Behaviour in public places
- Interactional Strategies: Observation of boy by mother, reaction to prevent
- Consequences: punishment
• Not enough data for selective coding
First Observational Example, page 96 Lofland and Lofland
Grounded Theory
Third Step: Selective Coding
• Selective coding
- The process of selecting the core category
- The central category around which your final analysis will be based
- Then relating it to other categories
• Three processes
- Explicating the story line: analytic description of the core category
- Relating other categories to the core
- Validating the story line
Selective Coding
The Story Line
• Commit, commit commit!
- After months of analysis EVERYTHING seems important
- But a story line needs to priortise one category over all others
• Finding the story
- Ask yourself what seems the most striking/interesting
- Write it in no more than a paragraph, just a FEW sentences
• Does one category seem more central?
- Can it explain the others?
- If you have two, drop one!
Example
• Previously, we had one category
- Individuals coordinating code
- Parallel development, history of the code base ,many others
• Others emerged
- Groups coordinating code
- (^) Life cycle, architecture
- Organisations coordinating code
- Multiple organisations coordinating code
• And these are just the relevant ones
- For the gory details, there’s my dissertation!
Example: Selective Coding
The Story Line
• Eventually the story line became
- Technical dependencies in software create social dependencies among the developers responsible for the pieces + Named the core category: recomposition + Recomposition is all the work it takes to coordinate the assembling software from its parts + Name came from decomposition, the process of breaking software apart
• It took me a long time to abandon
- Individual, group, organisational distinction
- Present in categories, but not actually important to the central story
- Important in explaining the details of the theory, but not in summarising it
Example: Selective Coding
Relating Categories to the Story Line
• Recomposition
- Seemed to encompass individual, group, organisational coordination
- Same roots
• Properties of interrelationship of work and code
- All the problems happen when work and code can not be separated
• Differences emerged
- Causes and consequences depending on scale—individual v. organisation
- But they could be parameterised and organised into the story line
Example: Selective Coding
Validating the Story Line
• Revisited my data with this analytic focus
- Wrote my dissertation using the core category story line
- Good story line—explanation—is a thesis
• Other ways to validate
- Go into other settings and see whether it works
• Publish it
- Independent confirmation of ideas