Case Studies

advertisement
382C Empirical Studies in Software Engineering
Lecture 6
Case Studies
Dewayne E Perry
ENS 623
perry@mail.utexas.edu
Adapted from Perry, Sim & Easterbrook,Case Studies for Software Engineering, ICSE 2004 Tutorial
© 2000-present, Dewayne E Perry
1
382C Empirical Studies in Software Engineering
Lecture 6
What is a case study?
™
A case study is an empirical research method.
 It is not a subset or variant of other methods, such as
experiments, surveys or historical study.
™
Best suited to applied problems that need to be studied in
context.
 Phenomena under study cannot be separated from context.
Effects can be wide-ranging.
 How and why questions
™
™
Settings where researcher has little control over
variables, e.g. field sites.
Effects take time to appear.
 Days, weeks, months, or years rather than minutes or hours.
© 2000-present, Dewayne E Perry
2
382C Empirical Studies in Software Engineering
Lecture 6
What is not a case study?
™
Not an exemplar or case history
 In medicine and law, patients or clients are “cases.” A
review of interesting instance(s) is called a case study.
 Not a report of something interesting that was tried on a
toy problem
™
Not an experience report
 Retrospective report on an experience (typically, industrial)
with lessons learned
™
Not a quasi-experiment with small n
 Weaker form of experiment with a small sample size
 Uses a different logic for designing the study and for
generalizing from results
© 2000-present, Dewayne E Perry
3
382C Empirical Studies in Software Engineering
Lecture 6
Why conduct a case study?
™
To gain a deep understanding of a phenomenon
 Example: To understand the capability of a new tool
 Example: To identify factors affecting communication in code
inspections
 Example: To characterize the process of coming up to speed
on a project
™
Objective of Investigation
 Exploration- To find what’s out there
 Characterization- To more fully describe
 Validation- To find out whether a theory/hypothesis is true
™
Subject of Investigation
 An intervention, e.g. tool, technique, method, approach to
design, implementation, or organizational structure
 An existing thing or process, e.g. a team, releases, defects
© 2000-present, Dewayne E Perry
4
382C Empirical Studies in Software Engineering
Lecture 6
When to use case studies
Strategy
Form of Research
Question
Requires Control
of Behavioral
Events?
Focuses on
contemporary
events?
Experiment
How, why?
Yes
Yes
Survey
Who, what, where,
how many, how much?
No
Yes
Archival
Analysis
Who, what where,
how many, how much?
No
Yes/No
History
How, why?
No
No
Case Study
How, why?
No
Yes
© 2000-present, Dewayne E Perry
5
382C Empirical Studies in Software Engineering
Lecture 6
How can I tell it’s a case study?
™
™
™
™
Has research questions set out from the beginning of the
study
Data is collected in a planned and consistent manner
Inferences are made from the data to answer the
research questions
Produces an explanation, description, or causal analysis of
a phenomenon
 Can also be exploratory
© 2000-present, Dewayne E Perry
6
382C Empirical Studies in Software Engineering
Lecture 6
What is a case study?
™
A case study is an empirical inquiry that
 Investigates a contemporary phenomenon within its real-life
context, especially when
 The boundaries between phenomenon and context are not
clearly evident.
™
The case study inquiry
 Copes with the technically distinctive situation in which there
will be many more variables of interest that data points, and
as one result
 Relies on multiple sources of evidence, with data needing to
converge in a triangulating fashion, and as another result
 Benefits from the prior development of theoretical
propositions to guide data collection and analysis.
© 2000-present, Dewayne E Perry
7
382C Empirical Studies in Software Engineering
Lecture 6
Parts of a Case Study Research Design
™
A research design is a “blueprint” for a study
 Deals more with the logic of the study than the logistics
 Plan for moving from questions to answers
 Ensures that the data is collected and analyzed to produce
an answer to the initial research question
 Strong similarities between a research design and a system
design
™
Five parts of a case study research design
1.
2.
3.
4.
5.
Research questions
Propositions (if any)
Unit(s) of analysis
Logic linking the data to the propositions
Criteria for interpreting the findings
© 2000-present, Dewayne E Perry
8
382C Empirical Studies in Software Engineering
Lecture 6
Part 1: Study Questions
™
™
™
Case studies are most appropriate for research questions
that are of the “how” and “why” variety
The initial task is to clarify precisely the nature of the
study questions (i.e. make sure they are actually “how” or
“why” questions)
Examples:
 “Why do 2 organizations have a collaborative relationship?”
 "Why do developers prefer this tool/model/notation?"
 "How are inspections carried out in practice?“
 "How does agile development work in practice?"
 "Why do programmers fail to document their code?“
 "How does software evolve over time?“
 "Why have formal methods not been adopted widely for
safety critical applications?“
 "How does a company identify which software development
projects to start?"
© 2000-present, Dewayne E Perry
9
382C Empirical Studies in Software Engineering
Lecture 6
Types of Case Studies
™
Explanatory
 Adjudicates between competing explanations
 Example: How important is implementation bias in requirements
engineering?
¾ Rival theories: existing architectures are useful for anchoring, vs.
existing architectures are over-constraining during RE
™
Descriptive
™
Causal
 Describes sequence of events and underlying mechanisms
 Example: How does pair programming actually work?
 Example: How do software immigrants naturalize?
 Looks for causal relationship between concepts
 Example: Requirements errors are more likely to cause safetyrelated defects than programming errors are
¾ See study by Robyn Lutz on the Voyager and Galileo spacecraft
™
Exploratory
 Criteria or parameters instead of purpose
 Example: Christopher Columbus’ voyage to the new world
 Example: What do CMM level 3 organizations have in common?
© 2000-present, Dewayne E Perry
10
382C Empirical Studies in Software Engineering
Lecture 6
Part 2: Study Propositions
™
Propositions are statements that help direct attention to
something that should be examined in the case study, i.e.
point to what should be studied
 Example: “Organizations collaborate because they derive
mutual benefits”
™
Propositions will tell you where to look for relevant
evidence
 Example: Define and ascertain the specific benefits to each
organization
™
Some studies may not have propositions – this implies a
topic of “exploration”
 Note: Even exploratory studies should have both clearlystated purposes and clearly-stated criteria for success
© 2000-present, Dewayne E Perry
11
382C Empirical Studies in Software Engineering
Lecture 6
Part 3: Unit of Analysis
™
The unit of analysis defines what a “case” is in a case
study
 Example: a unit of analysis (case) may be an individual, and
the case study may be the life history of that person
™
Other units of analysis include decisions, social programs,
processes, changes
 Note: It is important to clarify the definition of these
cases as they may be subjective, e.g. the beginning and end
points of a process
™
™
™
What unit of analysis to use generally depends on the
primary research questions
Once defined, the unit of analysis can still be changed if
desired, e.g. as a result of discoveries based on data
To compare results with previous studies (or allow others
to compare results with yours), try to select a unit of
analysis that is or can be used by others
© 2000-present, Dewayne E Perry
12
382C Empirical Studies in Software Engineering
Lecture 6
Examples of Units of Analysis
™
For a study of how software immigrants naturalize
 Individuals
 Development team
 Organization
™
For a study of pair programming




™
Programming episode
Pairs of programmers
Development team
Organization
For a study of software evolution





Modification report
File
System
Release
Stable release
© 2000-present, Dewayne E Perry
13
382C Empirical Studies in Software Engineering
Lecture 6
Part 4: Linking Logic
™
™
™
™
Logic or reasoning to link data to propositions
One of the least well developed components in case
studies
Many ways to perform this, but none as precisely defined
as the treatment/subject approach used in experiments
One possibility is pattern matching
 Describe several potential patterns, then compare the case
study data to the patterns and see which one is closer
© 2000-present, Dewayne E Perry
14
382C Empirical Studies in Software Engineering
Lecture 6
Part 5: Interpretation Criteria
™
™
™
Need criteria for interpreting a study’s findings
Also a relatively undeveloped component in case studies
Statistical tests not possible when only single data points
are captured (as is the case with single-case studies)
 Currently there is no precise way of setting the criteria for
interpreting these types of findings
© 2000-present, Dewayne E Perry
15
382C Empirical Studies in Software Engineering
Lecture 6
Generalizing from Case Study to Theory
™
™
™
“The appropriately developed theory is also at the level
at which generalization of the case study results will
occur”
Theory for case studies is characterized as analytic
generalization and is contrasted with another way of
generalizing results known as statistical generalization
Understanding the difference between these two types of
generalization is important
© 2000-present, Dewayne E Perry
16
382C Empirical Studies in Software Engineering
Lecture 6
Analytical and Statistical Generalization
Figure 2.2 Making Inferences: Two Levels
© 2000-present, Dewayne E Perry
17
382C Empirical Studies in Software Engineering
Lecture 6
Statistical Generalization
™
™
Making an inference about a population on the basis of
empirical data collected about a sample
This method of generalization is commonly recognized
because research investigators have quantitative formulas
characterizing generalizations that can be made
 Examples: significance, confidence, size of the effect, power
of test
™
™
Using this as a method of generalizing the results of a
case study is a “fatal flaw”, since cases are not sampling
units, nor should they be chosen for this reason
Statistical generalizations are considered a Level One
Inference
© 2000-present, Dewayne E Perry
18
382C Empirical Studies in Software Engineering
Lecture 6
Analytical Generalization
™
™
™
™
™
Previously developed theory is used as a template with
which to compare the empirical results of the case study
If 2 or more cases support the same theory, replication
may be claimed
Results may be considered more “potent” if 2 or more
cases support the same theory but don’t support the same
rival theory
Analytical generalizations are considered a Level 2
Inference
Aim toward analytical generalization in doing case studies
 Avoid thinking in terms of samples when doing case studies
© 2000-present, Dewayne E Perry
19
382C Empirical Studies in Software Engineering
Lecture 6
How can I evaluate a case study?
™
Using the same criteria for other empirical research
™
Construct Validity
 Concepts being studied are operationalized and measured
correctly
™
Internal Validity
 Establish a causal relationship and distinguish spurious
relationships
™
External Validity
 Establish the domain to which a study’s findings can be
generalized
™
Experimental Reliability
 Demonstrate that the study can be repeated with the same
results
© 2000-present, Dewayne E Perry
20
382C Empirical Studies in Software Engineering
Lecture 6
Embedded Designs
™
Strengths
 Introduces higher sensitivity to “slippage” from the original
research questions
™
Weaknesses
 Can lead to focusing only on the subunit (i.e. a multiple-case
study of the subunits) and failure to return to the larger
unit of analysis
© 2000-present, Dewayne E Perry
21
382C Empirical Studies in Software Engineering
Lecture 6
Multiple-Case Designs
™
™
If the same study contains more than a single case, it is
a multiple-case design
Advantages
 Evidence is considered more compelling
 Overall study is therefore regarded as more robust
™
Disadvantages
 Rationale for single-case designs usually cannot be satisfied
by multiple cases
 Can require extensive resources and time
© 2000-present, Dewayne E Perry
22
382C Empirical Studies in Software Engineering
Lecture 6
Replication in Multiple-Case Studies
™
When using multiple-case studies, each case must be
carefully selected so that it either:
 Predicts similar results (literal replication)
 Predicts contrasting results but for predictable reasons
(theoretical replication)
™
™
™
If all cases turn out as predicted, there is compelling
support for the initial propositions
Otherwise the propositions must be revised and retested
with another set of cases
With replication procedures, a theoretical framework
must be developed that states the conditions under which
a particular phenomenon is likely to be found (a literal
replication) and the conditions when it is not likely to be
found (a theoretical replication)
 This framework is used to generalize to new cases
© 2000-present, Dewayne E Perry
23
382C Empirical Studies in Software Engineering
Lecture 6
Replication Logic vs. Sampling Logic
™
™
™
Consider multiple-cases analogous to multiple experiments (NOT
analogous to multiple subjects within an experiment or multiple
respondents in a survey)
This replication logic used in multiple-case studies must be
distinguished from the sampling logic commonly used in surveys
 Sampling logic requires defining a pool of potential respondents,
then selecting a subset from that pool using a statistical
procedure
 Responses from the subset are supposed to accurately reflect
the responses of the entire pool
 This procedure is used to determine the prevalence or
frequency of a particular phenomenon
Sampling logic is not for use with case studies
 Case studies are not the best method for assessing the
prevalence of phenomenon
 Case studies would have to cover both the phenomenon of
interest and its context, yielding a larger number of potential
variables, and thus requiring an impossible number of cases
 Sampling logic simply cannot be used for all types of empirical
investigations
© 2000-present, Dewayne E Perry
24
382C Empirical Studies in Software Engineering
Lecture 6
Replication Approach for Multiple-Case Studies
Figure 2.5 Case Study Method (page 50)
© 2000-present, Dewayne E Perry
25
382C Empirical Studies in Software Engineering
Lecture 6
Rationale for Multiple-Case Designs
™
™
Multiple-case designs are useful when literal or
theoretical replications would provide valuable information
for the study
More results that back your theory typically adds more
credibility to your case study
© 2000-present, Dewayne E Perry
26
382C Empirical Studies in Software Engineering
Lecture 6
Multiple-Case Designs: Holistic or Embedded
™
™
™
A multiple-case study can consist of multiple holistic
cases or multiple embedded cases, depending on the type
of phenomenon being studied and the research questions
Note there is no mixing of embedded and holistic cases in
the same multiple-case study
It is also important to note that for embedded studies,
subunit data is NOT pooled across the subunits, but is
used to draw conclusions for the subunit’s case only
© 2000-present, Dewayne E Perry
27
382C Empirical Studies in Software Engineering
Lecture 6
Selecting Case Study Designs – Single/Multiple?
™
If you have a choice and the resources, multiple-case
designs are preferred
 Analytic conclusions independently arising from two cases will
be more powerful than from a single case
 The differences in context of multiple cases that have
common conclusions provide for expanded generalizability of
findings
 If two deliberately contrasting cases are selected and
findings support the hypothesized contrast, the results
represent theoretical replication and strengthen external
validity
™
Single-case studies are often criticized due to fears
about uniqueness surrounding the case
 Criticisms may turn to skepticism about your ability to do
empirical work beyond a single-case study
 If you choose single-case design, be prepared to make an
extremely strong argument justifying your choice for the
case
© 2000-present, Dewayne E Perry
28
382C Empirical Studies in Software Engineering
Lecture 6
Selecting Case Study Designs – Closed/Flexible?
™
™
A case study’s design can be modified by new information
or discovery during data collection
If you modify your design, be careful to understand the
nature of the alteration:
 Are you merely selecting different cases, or are you also
changing the original theoretical concerns and objectives?
 Flexibility in design does not allow for lack of rigor in design
© 2000-present, Dewayne E Perry
29
382C Empirical Studies in Software Engineering
Lecture 6
Data Analysis
™
™
™
™
Analytic Strategies
3 general strategies
5 specific analytic techniques
Criteria for high quality analysis
© 2000-present, Dewayne E Perry
30
382C Empirical Studies in Software Engineering
Lecture 6
Characteristics of Case Study Analysis
™
™
™
Data analysis consists of examining, categorizing,
tabulating, testing and recombining both quantitative and
qualitative evidence to address the initial propositions of
a study
Analyzing case study evidence is difficult because
strategies and techniques have not been well defined
Every case study should have a general analytic strategy
to define priorities for what to analyze and why
© 2000-present, Dewayne E Perry
31
382C Empirical Studies in Software Engineering
Lecture 6
Criteria for High Quality Analysis
™
™
™
™
™
Present all the evidence
Develop rival hypotheses
Address all major rival interpretations
Address most significant aspect of the case study
Use prior or expert knowledge
© 2000-present, Dewayne E Perry
32
382C Empirical Studies in Software Engineering
Lecture 6
Objectives of Analytical Study
™
™
™
Produce high quality analyses
Present all evidence and separate them from any
interpretation
Explore alternative interpretations
© 2000-present, Dewayne E Perry
33
382C Empirical Studies in Software Engineering
Lecture 6
Needs for Analytic Strategies
™
™
™
Investigations on how the evidence is to be analyzed
easily become stalled
Analytic tools can only be helpful if the investigators know
what to look for
Analytic strategies are needed to address the entire case
study since verbatim and documentary texts are usually
the initial phase
© 2000-present, Dewayne E Perry
34
382C Empirical Studies in Software Engineering
Lecture 6
Benefits of Analytic Strategies
™
™
™
™
™
™
Put the evidence in preliminary order and treat the
evidence fairly
Prevent false starts
Save time
Produce compelling analytic conclusions
Rule out alternative interpretations
Help investigators use tools and make manipulations
effectively
© 2000-present, Dewayne E Perry
35
382C Empirical Studies in Software Engineering
Lecture 6
Three General Strategies
1.
2.
3.
™
Relying on Theoretical Propositions
Thinking about Rival Explanations
Developing a Case Description
GS 1 - Relying on Theoretical Propositions
 Shapes the data collection plan and gives priorities
to the relevant analytic strategies
 Helps to focus attention on certain data and to
ignore other useless data
 Helps to organize the entire case study and define
alternative explanations to be examined
© 2000-present, Dewayne E Perry
36
382C Empirical Studies in Software Engineering
Lecture 6
Three General Strategies
™
GS 2 - Thinking About Rival Explanations
 Defines and tests rival explanations
 Relates to theoretical propositions, which contain rival
hypotheses
 Attempts to collect evidence about other possible influences
 The more rivals the analysis addresses and rejects, the
more confidence can be placed in the findings
™
GS 3 - Developing a Case Description
 Serves as an alternative when theoretical proposition and
rival explanation are not applicable
 Identifies
¾ an embedded unit of analysis
¾ an overall pattern of complexity to explain why implementation
had failed
© 2000-present, Dewayne E Perry
37
382C Empirical Studies in Software Engineering
Lecture 6
Five Specific Analytic Techniques
1.
2.
3.
4.
5.
Pattern Matching
Explanation Building
Time-Series Analysis
Logic Models
Cross-Case Synthesis
Note: They are intended to deal with problems of developing
internal and external validity in doing case studies
© 2000-present, Dewayne E Perry
38
382C Empirical Studies in Software Engineering
Lecture 6
AT 1 - Pattern Matching
™
™
Pattern matching compares an empirically based
pattern with a predicted one
If the patterns coincide, the results can strengthen
the internal validity of the case study
Types
1.
2.
3.
of pattern matching:
Nonequivalent dependent variables as a pattern
Rival explanations as patterns
Simpler patterns
© 2000-present, Dewayne E Perry
39
382C Empirical Studies in Software Engineering
Lecture 6
PM 1 - Nonequivalent dependent variables
™
™
Quasi-experiment may have multiple dependent
variables (variety of outcomes)
If, for each outcome, the initially predicted values
have been found, and at the same time alternative
“patterns” of predicted values (including those
deriving from methodological artifacts or threats to
validity) have not been found, strong causal
inferences can be made
© 2000-present, Dewayne E Perry
40
382C Empirical Studies in Software Engineering
Lecture 6
PM 2 - Rival Explanations
™
™
™
Each case has certain type of outcome, and the
investigation has to be focused on how and why
this outcome occurred
This analysis requires the development of rival
theoretical propositions, articulated in operational
terms
Each rival explanation involves a pattern of
independent variables that is mutually exclusive: If
one explanation is to be valid, the others cannot
be
© 2000-present, Dewayne E Perry
41
382C Empirical Studies in Software Engineering
Lecture 6
PM 3 - Simpler Patterns
™
™
There may be only 2 different dependent (or
independent) variables, pattern matching is possible
as long as a different pattern has been stipulated
for these 2 variables
The fewer the variables, the more dramatic the
different patterns will have to allow any
comparisons of their differences
© 2000-present, Dewayne E Perry
42
382C Empirical Studies in Software Engineering
Lecture 6
AT 2 - Explanation Building
™
™
™
™
™
Analyzes the case study data by building an explanation
about the case
Stipulates a presumed set of causal links, which are
similar to the independent variables in the use of rival
explanations
Has mostly occurred in narrative form
May lead to starting a cross-case analysis, not just an
analysis of each individual case
Disadvantage: may drift away from original focus
© 2000-present, Dewayne E Perry
43
382C Empirical Studies in Software Engineering
Lecture 6
AT 2 - Explanation Building
™
Series of iterations in building explanation
1.Making initial theoretical statement
2.Comparing the findings of the initial case against such a
statement
3.Revising the statement
4.Comparing other details of the case against the revision
5.Comparing the revisions to the facts of 2nd, 3rd or more
cases
6.Repeating the process if needed
© 2000-present, Dewayne E Perry
44
382C Empirical Studies in Software Engineering
Lecture 6
AT 3 - Time Series Analysis
™
™
™
The objective of time series analysis is to examine
relevant “how” and “why” questions about the
relationship of events over time
Time series analysis can follow intricate patterns
The more intricate the pattern, the firmer the
foundation for conclusions of the case study
Three types of Time Series Analyses:
 Simple Time Series
 Complex Time Series
 Chronologies
© 2000-present, Dewayne E Perry
45
382C Empirical Studies in Software Engineering
Lecture 6
TA 1 - Simple Time Series
™
™
™
Trace changes over time
Single variable only, so statistical analysis of data is
possible
Match between a trend of data points compared to
 significant trend specified before investigation
 rival trend specified earlier
 any other trend based on some artifact or threat to
internal validity
© 2000-present, Dewayne E Perry
46
382C Empirical Studies in Software Engineering
Lecture 6
TA 2 - Complex Time Series
™
™
™
™
Contain multiple set of variables (mixed patterns) which
are relevant to the case study
Each variable is predicted to have different pattern over
time
Create greater problems for data collection, but lead to
elaborate trend that strengthens the analysis
Any match of a predicted with an actual time series will
produce strong evidence for an initial theoretical
proposition
© 2000-present, Dewayne E Perry
47
382C Empirical Studies in Software Engineering
Lecture 6
TA 3 - Chronologies
™
™
™
™
™
Trace events over time
Sequence of a cause and effect cannot be inverted
Some events must be followed by other events on a
contingency basis after an interval of time
Cover many different types of variables
Goal is to compare chronology with that predicted by the
explanatory theory
© 2000-present, Dewayne E Perry
48
382C Empirical Studies in Software Engineering
Lecture 6
AT 4 - Logic Models
™
™
™
™
Stipulate a complex chain of events over time
Events are staged in repeated cause-effect-cause-effect
patterns
Match empirically observed events to theoretically
predicted events
Four types of logic models:
 Individual-Level Logic Model
 Firm or Organizational-Level Logic Model
 An alternative configuration for an Organizational-Level
Logic Model
 Program-Level Logic Model
© 2000-present, Dewayne E Perry
49
382C Empirical Studies in Software Engineering
Lecture 6
Logic Models
A) Individual-level logic model
 Assumes the case study is about an individual person
B) Firm or organizational-level logic model
 Traces events taking place in an individual organization
C) An alternative configuration for an organizational-level
logic model
 Encounters dynamic events that are not progressing linearly
 Changes may reverse course and not just progress in one
direction (Transformation and reforming)
D) Program-level logic model
 Analyzes data from different case studies by collecting data
on rival explanations
© 2000-present, Dewayne E Perry
50
382C Empirical Studies in Software Engineering
Lecture 6
AT 5 - Cross-Case Synthesis
™
™
Case study consists of at least 2 cases
Using multiple case studies will
 Treat each individual case study as a separate study
 Have to create word tables that display data from individual
cases according to some uniform framework
 Examine word tables for cross-case patterns
 Rely strongly on argumentative interpretation, not numeric
properties
 Be directly analogous to cross-experiment interpretations
© 2000-present, Dewayne E Perry
51
382C Empirical Studies in Software Engineering
Lecture 6
What Makes an Exemplary Case Study?
™
™
The exemplary case study goes beyond the
methodological procedures
Mastering the techniques does not guarantee an
exemplary case study
© 2000-present, Dewayne E Perry
52
382C Empirical Studies in Software Engineering
Lecture 6
Characteristics of an Exemplary Case Study
™
1. The Case Study Must Be Significant
 The case should be unusual and of general public interest
 The issue are nationally important, either in theory or
practical terms
 Prior to selecting a case study, the contribution should be
described in detail assuming that the intended case study
were to be completed successfully
™
2. The Case Study Must be “Complete”
 Completeness can be characterized in at least three ways:
¾ The boundaries of the case are given explicit attention
¾ Exhaustive effort is spent on collecting all the relevant
evidence
¾ The case study was not ended because of nonresearch
constraints
© 2000-present, Dewayne E Perry
53
382C Empirical Studies in Software Engineering
Lecture 6
Characteristics of an Exemplary Case Study
™
3. The Case Study Must Consider Alternative Perspectives
 The case study should include consideration of rival propositions and
the analysis of the evidence in terms of such rivals
 This can avoid the appearance of a one-sided case
™
4. The Case Study Must Display Sufficient Evidence
 The report should include the most relevant evidence so the reader
can reach an independent judgment regarding the merits of the
analysis
 The evidence should be able to convince the reader that the
investigator “knows” his or her subject
 The investigator should also show the validity of the evidence being
presented
™
5. The Case Study Must Be Composed in an Engaging Manner
 A written case study report should be able to entices the reader to
continue reading
© 2000-present, Dewayne E Perry
54
382C Empirical Studies in Software Engineering
Lecture 6
Case Study as a Research Method
™
The case study is a distinct research method with its own
research designs
 It is not a subset or variant of research designs used for
other strategies (such as experiments)
™
Scientific
 Synergistic relationship between theory and data
 Starting a case study requires a theoretical orientation,
which drives data collection
™
Useful for answering “how” and “why” questions
 In contrast to who, what, when, how many, how much
 How, why = explanatory, descriptive
™
Does not require control over events
 More observational
™
Focus on contemporary events
 Less historical
© 2000-present, Dewayne E Perry
55
Download