Qualitative research in software engineering (original) (raw)
Related papers
Qualitative methods in empirical studies of software engineering
IEEE Transactions on Software Engineering, 2002
ÐWhile empirical studies in software engineering are beginning to gain recognition in the research community, this subarea is also entering a new level of maturity by beginning to address the human aspects of software development. This added focus has added a new layer of complexity to an already challenging area of research. Along with new research questions, new research methods are needed to study nontechnical aspects of software engineering. In many other disciplines, qualitative research methods have been developed and are commonly used to handle the complexity of issues involving human behavior. This paper presents several qualitative methods for data collection and analysis and describes them in terms of how they might be incorporated into empirical studies of software engineering, in particular how they might be combined with quantitative methods. To illustrate this use of qualitative methods, examples from real software engineering studies are used throughout.
Research in software engineering: an analysis of the literature
Information and Software technology, 2002
In this paper, we examine the state of software engineering (SE) research from the point of view of the following research questions: 1. What topics do SE researchers address? 2. What research approaches do SE researchers use? 3. What research methods do SE researchers use? 4. On what reference disciplines does SE research depend? 5. At what levels of analysis do SE researchers conduct research?
Empirical Strategies in Software Engineering Research: A Literature Survey
2021 Second International Conference on Information Systems and Software Technologies (ICI2ST), 2021
The Software Engineering (SE) research continues to gain strength and interest for researchers considering the need to apply rigor and scientific validity to research results. Objective: Establishing an overview of the topic through a classification scheme of publications and structure the field of interest. Method: We conducted a Systematic Mapping Study, including articles published until 2019, that report at least one study of empirical strategies in SE. Results: 80 initial sets of studies were selected and analyzed, identifying: i) empirical strategy type used and ii) Software Engineering hypotheses types used. Also, 20 papers of the set of studies for mapping were selected and analyzed, identifying 17 empirical strategies and 11 main characteristics to address the empirical research inception in SE. Conclusions: We corroborate that the selection of an empirical strategy in Software Engineering research depends on the nature and scope of the research and on the resources that the researcher has at that moment, in addition to the degree of scientific and methodological knowledge that he has to carry out an empirical study. It is necessary to continue studying in-depth the behavior and nature of the empirical strategies in Software Engineering research that allows strengthening the scientific taxonomy in SE, besides walking towards the automation of the experimental process.
Concepts, Methodologies, Tools, and Applications, 2014
The classical scientific method has been settled through the last centuries as a cyclic, iterative process of observation, hypothesis formulation, and confirmation/refutation of hypothesis through experimentation. This "experimental scientific method" was mainly developed in the context of natural sciences dealing with the physical world, such as Mechanics, Thermodynamics, Electromagnetism, Chemistry and so on. But when we try to apply this classical view of the scientific method to the various branches of Computer Science and Computer Engineering, among which Software Engineering, we find two kinds of obstacles. First, Computer Science is rooted both in formal sciences such as Mathematics and experimental sciences such as Physics, therefore an excessive emphasis on the experimental side is not appropriate to give a full account of this kind of scientific activity. Second, the production of software systems has to deal not only with the behavior of complex physical systems such as computers, but also with the behavior of complex human systems (developers interacting with stakeholders, for instance, or users interacting with machines) where educational, cultural, sociological and economical factors are essential. Therefore, empirical methods in their narrow sense, even though valuable in some respects, are rather limited to understand a reality that exceeds the mere physical world. Moreover, neither formal nor empirical methods can provide a full account of scientific activity, which relies on something that is beyond any established method. Qualitative (i.e. meta-methodical) reasoning plays the directive role in scientific activity. In this chapter we claim that acknowledging a plurality of research methods in software engineering will benefit the advancement of this branch of science.
Guidelines for conducting and reporting case study research in software engineering
Empirical Software Engineering, 2009
Case study is a suitable research methodology for software engineering research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims at providing an introduction to case study methodology and guidelines for researchers conducting case studies and readers studying reports of such studies. The content is based on the authors' own experience from conducting and reading case studies. The terminology and guidelines are compiled from different methodology handbooks in other research domains, in particular social science and information systems, and adapted to the needs in software engineering. We present recommended practices for software engineering case studies as well as empirically derived and evaluated checklists for researchers and readers of case study research.
Directions and methodologies for empirical software engineering research
Empirical Software …, 1999
This report summarises and builds on the results of the "Directions and Methodologies for Empirical Software Engineering Research" group discussion. In particular, we considered the strengths, weaknesses, opportunities and threats to empirical software engineering research in light of the discussions and presentations during the workshop. The following sections describe each of these aspects of our discussion in turn. In addition, to finalise our discussion we agreed on a three-point plan for future work.
European Journal of Advances in Engineering and Technology, 2019
This research explores the multifaceted nature of software systems engineering by emphasizing the integration of qualitative factors throughout the software development lifecycle. This research provides a framework for analyzing, designing, and implementing complex software projects with a focus on maintainability, extensibility, reusability, and robustness. The study combines both top-down and bottom-up design approaches, enabling students to select and apply the most suitable methods based on technology, project duration, risk levels, and customer expectations. The research incorporates a Work Integrated Learning (WIL) experience, simulating industrial software engineering projects to bridge theoretical knowledge with practical application. Students gain hands-on experience in managing and executing software projects while receiving industry feedback to enhance their skills. The course covers essential IT concepts and project management principles, equipping students with the tools needed to succeed in the software engineering industry. This comprehensive approach ensures that graduates are well-prepared for real-world challenges in software development.
Viewpoint article: Conducting and presenting empirical software engineering
Empirical Software Engineering, 2001
Despite the heroic eorts of a small group of people, like those involved with this journal, a truly``empirical'' basis for software engineering remains a distant dream. In the current academic year I have been teaching software engineering (a double unit module) at Queen Mary (University of London) where I have been a Professor part-time since March 2000. Although I had been teaching courses on software metrics and quality assurance regularly in recent years, this was the ®rst time I had taught a``standard'' software engineering module since 1992. As the leader on a module with over 100 students, publishers have been keen to send me all their latest oerings. As a result, in the last few months I have received more than a dozen new or revised dedicated software engineering text books, and around two dozeǹ`s oftware engineering with Java'' or``object oriented software engineering'' type books. The good news is that, compared to the text books that were available when I last taught software engineering the new bunch are, almost without exception, a massive improvement. They provide students with techniques and methods that they can actually apply to their own programs and group projects. This compares favourably with the previous generation that simply documented a set of research ideas dreamed up in academia and never applied successfully in practice. This makes it easier and more satisfying to teach, and more rewarding for the students to learn (primarily because they can learn from doing which they could not in the past). Moreover, in this respect, the impression is that software engineering has come closer to being truè`e ngineering''. However, if we accept that an empirical basis is one of the other components that mark out a true engineering discipline, then the latest round of books con®rm that any progress we may have made in this area has had an almost negligible impact. The primary motivation for my own original interest in empirical software engineering was the desire to see a more rational basis for decision-making. For example, I was concerned that methods were being adopted on the basis of who, among the methods' proponents, shouted the loudest. In many cases methods were being pushed, not only without adequate tool support, but without any quantitative justi®cation of their eectiveness. I am not talking about the need for