Generalizing by similarity: Lessons learnt from industrial case studies

Ghaisas, Smita; Rose, Preethu; Daneva, Maya; Sikkel, Klaas; Wieringa, Roel

doi:10.1109/cesi.2013.6618468

Cited by 30 publications

(19 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Different generalizations will probably need different architectural similarities. Architectural similarity is a worthy research topic that can only be performed in cooperation with practitioners [102,103]. There are some published results about the (dis)similarity between software engineering students and software engineering professionals [104,105,106], but more needs to be done.…”

Section: Discussionmentioning

confidence: 99%

Six strategies for generalizing software engineering theories

Wieringa

Daneva

2015

Science of Computer Programming

Self Cite

157

View full text Add to dashboard Cite

General theories of software engineering must balance between providing full understanding of a single case and providing partial understanding of many cases. In this paper we argue that for theories to be useful in practice, they should give sufficient understanding of a sufficiently large class of cases, without having to be universal or complete. We provide six strategies for developing such theories of the middle range.In lab-to-lab strategies, theories of laboratory phenomena are developed and generalized to other laboratory phenomena. This is a characteristic strategy for basic science. In lab-to-field strategies, theories are developed of artifacts that first operate under idealized laboratory conditions, which are then scaled up until they can operate under uncontrolled field conditions. This is the characteristic strategy for the engineering sciences.In case-based strategies, we generalize about components of real-world cases, that are supposed to exhibit less variation than the cases as a whole. In sample-based strategies, we generalize about the aggregate behavior of samples of cases, which can exhibit patterns not visible at the case level. We discuss three examples of sample-based strategies.Throughout the paper, we use examples of theories and generalization strategies from software engineering to illustrate our analysis. The paper concludes with a discussion of related work and implications for empirical software engineering research.

show abstract

Section: Discussionmentioning

confidence: 99%

Six strategies for generalizing software engineering theories

Wieringa

Daneva

2015

Science of Computer Programming

Self Cite

157

View full text Add to dashboard Cite

show abstract

“…With regards to the external validity, a threat could be related to the fact that we used only applications from one company. Even if we can image that with a comparable organization, in terms of project size, quality of teams, experience of team members, and application domain, we might expect similar observations, we intend to conduct further studies with data sets from other companies [15].…”

Section: Threats To Validitymentioning

confidence: 98%

Conversion from IFPUG FPA to COSMIC: Within-vs Without-Company Equations

Ferrucci

Gravino

Sarro

2014

2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications

View full text Add to dashboard Cite

Abstract-Companies have employed for years 1st generation Functional Size Measurement (FSM) methods, e.g., IFPUG Function Points Analysis (FPA), collecting IFPUGbased historical data useful for benchmarking and estimation purposes. With the advent of 2nd generation FSM methods (e.g., COSMIC) the need for resizing past projects utilizing these new measures arises. The adoption of 2nd generation FSM methods has been limited both by the costs for acquiring new know-how and the need for resizing the historical data. Conversion equations represent a useful mean to facilitate the migration towards 2nd generation FSM methods. Previous works showed a significant correlation between the COSMIC and the FPA sizes. In our study we applied the conversion equations found in those works (i.e., without-company equations) to resize 25 IFPUG-based projects coming from a single software company. We compared their use with respect to two conversion equations built by using two small subsets (i.e., 5 and 10 projects) from that company data (i.e., within-company equations). We aimed to verify whether the use of withincompany equations built using few projects could provide more accurate conversions than those achieved by applying withoutcompany equations. Our analysis revealed that the withincompany equations performed significantly better than the without-company ones. Thus, companies should develop their own equations rather than using without-company conversions.

show abstract

“…Ghaisas et al [5] address the related, but wider, question of how to generalize from observations in several similar cases. They argue that case studies have different context attributes and as soon as the attributes of reported cases vary from a newly observed case, the researcher may not be able to predict the outcome of the project.…”

Section: Related Workmentioning

confidence: 99%

“…[12]). Consequently, understanding these relations will help in reasoning about the reasons for success and failure of decisions in the respective contexts when comparing cases (as discussed in the related work by Ghaisas et al [5]). …”

Section: B Relation To Architecture Decision Makingmentioning

confidence: 99%

A Context Model for Architectural Decision Support

Carlson

Papatheocharous

Petersen

2016

2016 1st International Workshop on Decision Making in Software ARCHitecture (MARCH)

View full text Add to dashboard Cite

Abstract-Developing efficient and effective decision making support includes identifying means to reduce repeated manual work and providing possibilities to take advantage of the experience gained in previous decision situations. For this to be possible, there is a need to explicitly model the context of a decision case, for example to determine how much the evidence from one decision case can be trusted in another, similar context. In earlier work, context has been recognized as important when transferring and understanding outcomes between cases. The contribution of this paper is threefold. First, we describe different ways of utilizing context in an envisioned decision support system. Thereby, we distinguish between internal and external context usage, possibilities of context representation, and context inheritance. Second, we present a systematically developed context model comprised of five types of context information, namely organization, product, stakeholder, development method & technology, and market & business. Third, we exemplary illustrate the relation of the context information to architectural decision making using existing literature.

show abstract

Generalizing by similarity: Lessons learnt from industrial case studies

Cited by 30 publications

References 11 publications

Six strategies for generalizing software engineering theories

Six strategies for generalizing software engineering theories

Conversion from IFPUG FPA to COSMIC: Within-vs Without-Company Equations

A Context Model for Architectural Decision Support

Contact Info

Product

Resources

About