Search

Background Several researchers have criticized the standards of performing and reporting empirical studies in software engineering. In order to address this problem, Jedlitschka and Pfahl have produced reporting guidelines for controlled experiments in software engineering. They pointed out that their guidelines needed evaluation. We agree that guidelines need to be evaluated before they can be widely adopted. Aim The aim of this paper is to present the method we used to evaluate the guidelines and report the results of our evaluation exercise. We suggest our evaluation process may be of more general use if reporting guidelines for other types of empirical study are developed. Method We used a reading method inspired by perspective-based and checklist-based reviews to perform a theoretical evaluation of the guidelines. The perspectives used were: Researcher, Practitioner/Consultant, Meta-analyst, Replicator, Reviewer and Author. Apart from the Author perspective, the reviews were based on a set of questions derived by brainstorming. A separate review was performed for each perspective. The review using the Author perspective considered each section of the guidelines sequentially. Results The reviews detected 44 issues where the guidelines would benefit from amendment or clarification and 8 defects. Conclusions Reporting guidelines need to specify what information goes into what section and avoid excessive duplication. The current guidelines need to be revised and then subjected to further theoretical and empirical validation. Perspective-based checklists are a useful validation method but the practitioner/consultant perspective presents difficulties.

Software Product Line (SPL) and Open Source Software (OSS) haveemerged as successful modes of developing software. Although they appear todiffer in terms of development principles and processes, researchers andpractitioners have been increasingly emphasising the need to achieve synergiesby exploiting the ever growing repositories of OSS components for developingSPLs. While there have been calls for the SPL community to accelerate thewidespread use of OSS in SPL, less attention has been paid to how OSScommunities could increase the use of OSS components in SPL. Sincearchitectural issues are considered critical in the SPL community, we proposethat an increased attention on architectural aspects of OSS components mayprovide the confidence that organizations need in order for them to choose anduse OSS components in SPL. We identify a number of architectural practiceswhich are followed by the SPL community and discuss the possibilities for andpotential benefits of incorporating those practices in OSS developmentprocesses.