The term “case study” appears every now and then in the title of software engineering
research papers. These papers have in common that they study a specific case, in
contrast to a sample from a specified population. However, the presented studies
range from very ambitious and well-organized studies in the field of operations
(in vivo) to small toy examples in a university lab (in vitro) that claim to be case
studies. This variation creates confusion, which should be addressed by increased
knowledge about case study methodology.
Case study is a commonly used research strategy in areas such as psychology,
sociology, political science, social work, business, and community planning
In these areas, case studies are conducted with the objectives of not only increasing knowledge (e.g., knowledge about individuals, groups,
and organizations and about social, political, and related phenomena) but also bringing about change in the phenomenon being studied (e.g. improving education or social
care). Software engineering research has similar high-level objectives, that is, to better understand how and why software engineering should be undertaken and, with
this knowledge, to seek to improve the software engineering process and the resultant
software products.
There are different taxonomies used to classify research in software engineering.
The term case study is used in parallel with terms like field study and observational
study, each focusing on a particular aspect of the research methodology. For example,
Case studies offer an approach that does not require a strict boundary between the
object of study and its environment. Case studies do not generate the same results
on, for example, causal relationships, as controlled experiments do, but they provide
a deeper understanding of the phenomena under study. As they are different from
analytical and controlled empirical studies, case studies have been criticized for being
of less value, being impossible to generalize from, being biased by researchers, and so
on. This critique can be met by applying proper research methodology practices and
by reconsidering that knowledge is more than statistical significance.
However, the research community has to learn more about the case study methodology
in order to conduct, report, review, and judge it properly.
HISTORY:
The term case study first appeared in software engineering journal papers in the
late 1970s. At that time, a case study was typically a demonstration case, that
is, a case that demonstrated the implementation of some software technology or
programming concept.
In the mid- to late-1980s, papers started to report case studies of a broader range
of software development phenomena, for example, Alexander and Potter’study
of formal specifications and rapid prototying. For these types of papers, the term case
study refers to a self-experienced and self-reported investigation. Throughout the
1990s the scale of these “self investigations” increased and there were, for example, a
series of papers reporting case studies of software process improvement in large and
multinational organizations such as Boeing, Hughes, Motorola, NASA, and Siemens.
Case studies based on the external and independent observation of a software
engineering activity first appeared in the late 1980s, for example, Boehm and
Ross’s “extensive case study” of the introduction of new information
systems into a large industrial corporation in an emerging nation. These case studies,
however, did not direct attention at case study methodology that is, at the design,
conduct, and reporting of the case study
The first case study papers that explicitly report the study methodology were
published in 1988: Curtis et al.’s [37] field study of software design activities and
Swanson and Beath’s [199] multiple case study of software maintenance. Given the
status of case study research in software engineering at the time, it is not surprising that Swanson and Beath were actually researchers in a school of management
in the United States, and were not software engineering researchers. Swanson and
Beath use their multiple case studies to illustrate a number of challenges that arise
when conducting case studies research, and they also present methodological lessons.
Their paper therefore appears to be the first of its kind in the software engineering
research community that explicitly discusses the challenge of designing, conducting,
and reporting case study research.
During the 1990s, both demonstration studies and genuine case studies (as we
define them here) were published, although only in small numbers. Glass et al.
analyzed software engineering publications in six major software engineering journals
for the period 1995–1999 and found that only 2.2% of these publications reported case
studies .Much more recently, a sample of papers from Sjøberg et al.’s large systematic review of experimental studies in software engineering were analysed
by Holt .She classified 12% of the sample as case studies. This compares to
1.9% of papers classified as formal experiments in the Sjøberg study. But differences
in the design of these reviews make it hard to properly compare the reviews and draw
firm conclusions.
The first recommendations, by software engineering researchers, regarding case
study methodology were published in the mid-1990s . However, these recommendations focus primarily on the use of quantitative data. In the late 1990s, Seaman
published guidelines on qualitative research . Then, in the early twenty-first
century, a broader set of guidelines on empirical research were published by Kitchen ham et al. Sim et al. arranged a workshop on the topic, which was summarized
in Empirical Software Engineering, Wohlin et al. provided a brief introduction
to case studies among other empirical methods , and Dittrich et al. edited a special issue of Information and Software Technology on qualitative software engineering
There is a very wide range of activities in software engineering, such as development, operation, and maintenance of software and related artifacts as well as the
management of these activities. A frequent aim of software engineering research is to
investigate how this development, operation, and maintenance is conducted, and also
managed, by software engineers and other stakeholders under different conditions.
With such a wide range of activities, and a wide range of software products being
developed, there is a very diverse range of skills and experience needed by the actors
undertaking these activities.
Software engineering is also distinctive in the combination of diverse topics that
make up the discipline
Many of the interim products are produced either intentionally by the actors (e.g.,
the minutes of meetings) or automatically by technology (e.g., updates to a version
of control system). Therefore, one of the distinctive aspects of software engineering
is the raw data that are naturally, and often automatically, generated by the activities
and technologies.
There are clear overlaps with other disciplines, such as psychology, management,
business, and engineering, but software engineering brings these other disciplines
together in a unique way, a way that needs to be studied with research methods
tailored to the specifics of the discipline
Case studies investigate phenomena in their real-world settings, for example, new
technologies, communication in global software development, project risk and failure
factors, and so on. Hence, the researcher needs to consider not only the practical
requirements and constraints from the researcher’s perspective, but also the objectives
and resource commitments of the stakeholders who are likely to be participating in,
or supporting, the case study. Also, practitioners may want to intervene in future
projects – that is, change the way things are done in future projects – on the basis
of the outcomes from the case studies, and often software engineering managers
are interested in technology interventions, such as adopting a new technology
the above content is taken from
" Case Study Research in Software Engineering: Guidelines and Examples "
research papers. These papers have in common that they study a specific case, in
contrast to a sample from a specified population. However, the presented studies
range from very ambitious and well-organized studies in the field of operations
(in vivo) to small toy examples in a university lab (in vitro) that claim to be case
studies. This variation creates confusion, which should be addressed by increased
knowledge about case study methodology.
Case study is a commonly used research strategy in areas such as psychology,
sociology, political science, social work, business, and community planning
In these areas, case studies are conducted with the objectives of not only increasing knowledge (e.g., knowledge about individuals, groups,
and organizations and about social, political, and related phenomena) but also bringing about change in the phenomenon being studied (e.g. improving education or social
care). Software engineering research has similar high-level objectives, that is, to better understand how and why software engineering should be undertaken and, with
this knowledge, to seek to improve the software engineering process and the resultant
software products.
There are different taxonomies used to classify research in software engineering.
The term case study is used in parallel with terms like field study and observational
study, each focusing on a particular aspect of the research methodology. For example,
Case studies offer an approach that does not require a strict boundary between the
object of study and its environment. Case studies do not generate the same results
on, for example, causal relationships, as controlled experiments do, but they provide
a deeper understanding of the phenomena under study. As they are different from
analytical and controlled empirical studies, case studies have been criticized for being
of less value, being impossible to generalize from, being biased by researchers, and so
on. This critique can be met by applying proper research methodology practices and
by reconsidering that knowledge is more than statistical significance.
However, the research community has to learn more about the case study methodology
in order to conduct, report, review, and judge it properly.
HISTORY:
The term case study first appeared in software engineering journal papers in the
late 1970s. At that time, a case study was typically a demonstration case, that
is, a case that demonstrated the implementation of some software technology or
programming concept.
In the mid- to late-1980s, papers started to report case studies of a broader range
of software development phenomena, for example, Alexander and Potter’study
of formal specifications and rapid prototying. For these types of papers, the term case
study refers to a self-experienced and self-reported investigation. Throughout the
1990s the scale of these “self investigations” increased and there were, for example, a
series of papers reporting case studies of software process improvement in large and
multinational organizations such as Boeing, Hughes, Motorola, NASA, and Siemens.
Case studies based on the external and independent observation of a software
engineering activity first appeared in the late 1980s, for example, Boehm and
Ross’s “extensive case study” of the introduction of new information
systems into a large industrial corporation in an emerging nation. These case studies,
however, did not direct attention at case study methodology that is, at the design,
conduct, and reporting of the case study
The first case study papers that explicitly report the study methodology were
published in 1988: Curtis et al.’s [37] field study of software design activities and
Swanson and Beath’s [199] multiple case study of software maintenance. Given the
status of case study research in software engineering at the time, it is not surprising that Swanson and Beath were actually researchers in a school of management
in the United States, and were not software engineering researchers. Swanson and
Beath use their multiple case studies to illustrate a number of challenges that arise
when conducting case studies research, and they also present methodological lessons.
Their paper therefore appears to be the first of its kind in the software engineering
research community that explicitly discusses the challenge of designing, conducting,
and reporting case study research.
During the 1990s, both demonstration studies and genuine case studies (as we
define them here) were published, although only in small numbers. Glass et al.
analyzed software engineering publications in six major software engineering journals
for the period 1995–1999 and found that only 2.2% of these publications reported case
studies .Much more recently, a sample of papers from Sjøberg et al.’s large systematic review of experimental studies in software engineering were analysed
by Holt .She classified 12% of the sample as case studies. This compares to
1.9% of papers classified as formal experiments in the Sjøberg study. But differences
in the design of these reviews make it hard to properly compare the reviews and draw
firm conclusions.
The first recommendations, by software engineering researchers, regarding case
study methodology were published in the mid-1990s . However, these recommendations focus primarily on the use of quantitative data. In the late 1990s, Seaman
published guidelines on qualitative research . Then, in the early twenty-first
century, a broader set of guidelines on empirical research were published by Kitchen ham et al. Sim et al. arranged a workshop on the topic, which was summarized
in Empirical Software Engineering, Wohlin et al. provided a brief introduction
to case studies among other empirical methods , and Dittrich et al. edited a special issue of Information and Software Technology on qualitative software engineering
There is a very wide range of activities in software engineering, such as development, operation, and maintenance of software and related artifacts as well as the
management of these activities. A frequent aim of software engineering research is to
investigate how this development, operation, and maintenance is conducted, and also
managed, by software engineers and other stakeholders under different conditions.
With such a wide range of activities, and a wide range of software products being
developed, there is a very diverse range of skills and experience needed by the actors
undertaking these activities.
Software engineering is also distinctive in the combination of diverse topics that
make up the discipline
Many of the interim products are produced either intentionally by the actors (e.g.,
the minutes of meetings) or automatically by technology (e.g., updates to a version
of control system). Therefore, one of the distinctive aspects of software engineering
is the raw data that are naturally, and often automatically, generated by the activities
and technologies.
There are clear overlaps with other disciplines, such as psychology, management,
business, and engineering, but software engineering brings these other disciplines
together in a unique way, a way that needs to be studied with research methods
tailored to the specifics of the discipline
Case studies investigate phenomena in their real-world settings, for example, new
technologies, communication in global software development, project risk and failure
factors, and so on. Hence, the researcher needs to consider not only the practical
requirements and constraints from the researcher’s perspective, but also the objectives
and resource commitments of the stakeholders who are likely to be participating in,
or supporting, the case study. Also, practitioners may want to intervene in future
projects – that is, change the way things are done in future projects – on the basis
of the outcomes from the case studies, and often software engineering managers
are interested in technology interventions, such as adopting a new technology
the above content is taken from
" Case Study Research in Software Engineering: Guidelines and Examples "
No comments:
Post a Comment