Background: Communicating software engineering research to industry practitioners and to other researchers can be challenging due to its context dependent nature. Design science is recognized as a pragmatic research paradigm, addressing this and other characteristics of applied and prescriptive research. Applying the design science lens to software engineering research may improve the communication of research contributions. Aim: The aim of this study is to 1) evaluate how well the design science lens helps frame software engineering research contributions, and 2) identify and characterize different types of design science contributions in the software engineering literature. Method: In previous research we developed a visual abstract template, summarizing the core constructs of the design science paradigm. In this study, we use this template in a review of a selected set of 38 top software engineering publications to extract and analyze their design science contributions. Results: We identified five clusters of papers, classified based on their alignment to the design science paradigm. Conclusions: The design science lens helps to pinpoint the theoretical contribution of a research output, which in turn is the core for assessing the practical relevance and novelty of the prescribed rule as well as the rigor of applied empirical methods in support of the rule.
In the management domain, van Aken propose to distinguish management theory, that is prescriptive, from organizational theory, that is explanatory @cite_9 . A corresponding division of software engineering theory has not been proposed yet, although theory types are discussed by software engineering researchers @cite_5 , @cite_16 .
@cite_5 @cite_9 @cite_16
882857864 2012058332 2156256602 2161676644
ContextMethods and processes, along with the tools to support them, are at the heart of software engineering as a discipline. However, as we all know, that often the use of the same method neither impacts software projects in a comparable manner nor the software they result in. What is lacking is an understanding of how methods affect software development. ObjectiveThe article develops a set of concepts based on the practice-concept in philosophy of sociology as a base to describe software development as social practice, and develop an understanding of methods and their application that explains the heterogeneity in the outcome. Practice here is not understood as opposed to theory, but as a commonly agreed upon way of acting that is acknowledged by the team. MethodThe article applies concepts from philosophy of sociology and social theory to describe software development and develops the concepts of method and method usage. The results and steps in the philosophical argumentation are exemplified using published empirical research. ResultsThe article develops a conceptual base for understanding software development as social and epistemic practices, and defines methods as practice patterns that need to be related to, and integrated in, an existing development practice. The application of a method is conceptualized as a development of practice. This practice is in certain aspects aligned with the description of the method, but a method always under-defines practice. The implication for research, industrial software development and teaching are indicated. ConclusionThe theoretical philosophical concepts allow the explaining of heterogeneity in application of software engineering methods in line with empirical research results. In this paper, we investigate model-driven engineering, reporting on an exploratory case-study conducted at a large automotive company. The study consisted of interviews with 20 engineers and managers working in different roles. We found that, in the context of a large organization, contextual forces dominate the cognitive issues of using model-driven technology. The four forces we identified that are likely independent of the particular abstractions chosen as the basis of software development are the need for diffing in software product lines, the needs for problem-specific languages and types, the need for live modeling in exploratory activities, and the need for point-to-point traceability between artifacts. We also identified triggers of accidental complexity, which we refer to as points of friction introduced by languages and tools. Examples of the friction points identified are insufficient support for model diffing, point-to-point traceability, and model changes at runtime. The relevance problem of academic management research in organization and management is an old and thorny one. Recent discussions on this issue have resulted in proposals to use more Mode 2 knowledge production in our field. These discussions focused mainly on the process of research itself and less on the products produced by this process. Here the focus is on the so-called field-tested and grounded technological rule as a possible product of Mode 2 research with the potential to improve the relevance of academic research in management. Technological rules can be seen as solution-oriented knowledge. Such knowledge may be called Management Theory, while more description-oriented knowledge may be called Organization Theory. In this article the nature of technological rules in management is discussed, as well as their development, their use in actual management practice and the potential for cross-fertilization between Management Theory and Organization Theory. In mature sciences, building theories is the principal method of acquir- ing and accumulating knowledge that may be used in a wide range of settings. In software engineering, there is relatively little focus on theories. In particular, there is little use and development of empirically-based theories. We propose, and illustrate with examples, an initial framework for describing software engineering theories, and give advice on how to start proposing, testing, modifying and using theories to support both research and practise in software engineering.