2015 IEEE/ACM 37th IEEE International Conference on Software Engineering 2015
DOI: 10.1109/icse.2015.198
|View full text |Cite
|
Sign up to set email alerts
|

Fast Feedback Cycles in Empirical Software Engineering Research

Abstract: Background/Context: Gathering empirical knowledge is a time consuming task and the results from empirical studies often are soon outdated by new technological solutions. As a result, the impact of empirical results on software engineering practice is often not guaranteed.Objective/Aim: In this paper, we summarize the ongoing discussion on "Empirical Software Engineering 2.0" as a way to improve the impact of empirical results on industrial practices. We propose a way to combine data mining and analysis with do… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
12
0

Year Published

2015
2015
2020
2020

Publication Types

Select...
3
2
1

Relationship

2
4

Authors

Journals

citations
Cited by 8 publications
(12 citation statements)
references
References 17 publications
0
12
0
Order By: Relevance
“…Concerning the latter one, we usually obtained it by bringing the analysis results printout to discussion with the product owners. For Project 1, the feedback was collected differently: the whole team participated and the results were continuously displayed on a wall in a common space, so that each team member was able to add his/her own ideas and observations at any time: this was intended as a simulation of the approach described in [22]. We could not apply the same strategy to the other projects because not all team members were located in Munich: however all product owners were there, so it was possible to gather their comments.…”
Section: Discussionmentioning
confidence: 99%
See 1 more Smart Citation
“…Concerning the latter one, we usually obtained it by bringing the analysis results printout to discussion with the product owners. For Project 1, the feedback was collected differently: the whole team participated and the results were continuously displayed on a wall in a common space, so that each team member was able to add his/her own ideas and observations at any time: this was intended as a simulation of the approach described in [22]. We could not apply the same strategy to the other projects because not all team members were located in Munich: however all product owners were there, so it was possible to gather their comments.…”
Section: Discussionmentioning
confidence: 99%
“…Estimation meeting -part 1 Each estimation meeting should take place in front of the estimation wall with a computer screen visible to all team members: according to the vision of the fast feedback cycles [22], practitioners should rely on the use of data (interactive) visualisations for their activities. Therefore the team can use the computer to access the original user story in JIRA and for its discussion (e.g.,to estimate user story is necessary to examine the current status of the product increment).…”
Section: # Id Question Answer Options Q1mentioning
confidence: 99%
“…What are their responsibilities and their levels of expertise? A further problem, finally, consists of that knowledge acquisition in software engineering is yet not always in tune with the pace of changes in our cases under investigation (e.g., industrial practices) [33].…”
Section: Challenges In Empirical Software Engineeringmentioning
confidence: 99%
“…For example, we need to be able to show them that a new code analysis technique, we want to investigate, has the potential to help them find defects faster. Finally, we also learnt that providing feedback early on and giving them quick results (such as in an iterative approach), helps to keep the participants interested and improves the results [14]. This also means that we have to be opportunistic in the subject and the case selection.…”
Section: Convincing Contacts To Participatementioning
confidence: 99%