Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Rebecca Tiarks

dblp:10/7870 · DBLP profile ↗
← Back
6ranked-venue papers
3as first author
0since 2021 · last 2014
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 6 · 3 first-authorDatabases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
2 papers
Empirical software engineering · 59% Software maintenance and evolution · 41%

Topics — the 5 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering
developer studies
0.322014
On the Comprehension of Program Comprehension · ACM Trans. Softw. Eng. Methodol. 2014
How do professional developers comprehend software? · ICSE 2012
Software maintenance and evolution
program comprehension
0.322014
On the Comprehension of Program Comprehension · ACM Trans. Softw. Eng. Methodol. 2014
How do professional developers comprehend software? · ICSE 2012
Empirical software engineering › developer studies
observational study
0.112012
How do professional developers comprehend software? · ICSE 2012
Empirical software engineering › developer studies › developer collaboration
knowledge sharing
0.112014
On the Comprehension of Program Comprehension · ACM Trans. Softw. Eng. Methodol. 2014
Software maintenance and evolution › software evolution
maintenance tasks
0.012012
How do professional developers comprehend software? · ICSE 2012

Methods — techniques the papers use, named apart from their topics

survey · 0.2qualitative analysis · 0.2observation study · 0.2observational study · 0.1interview study · 0.1
YearPublicationVenuePosition
2014 How does a typical tutorial for mobile development look like?
abstract
We report on an exploratory study, which aims at understanding how development tutorials are structured, what types of tutorials exist, and how official tutorials differ from tutorials written by development communities. We analyzed over 1.200 tutorials for mobile application development provided by six different sources for the three major platforms: Android, Apple iOS, and Windows Phone. We found that a typical tutorial contains around 2700 words distributed over 4 pages and including a list of instructions with 18 items. Overall, 70% of the tutorials contain source code examples and a similar fraction contain images. On average, one tutorial has 6 images. When analyzing the images, we found that the studied iOS community posted the largest number of images, 14 images per tutorial, on average, from which 74% are plain images, i.e., mainly screenshots without stencils, diagrams, or highlights. In contrast, 36% of the images included in the official tutorials by Apple were diagrams or images with stencils. Community sites seem to follow a similar structure to the official sites but include items and images which are rather underrepresented in the official tutorials. From the analysis of the tutorials content by means of natural language processing combined with manual content analysis, we derived four categories for mobile development tutorials: infrastructure and design, application and services, distribution and maintenance, and development platform. Our categorization can help tutorial writers to better organize and evaluate the content of their tutorials and identify missing tutorials.
Rebecca Tiarks, Walid Maalej
MSR1
2014 On the Comprehension of Program Comprehension
abstract
Research in program comprehension has evolved considerably over the past decades. However, only little is known about how developers practice program comprehension in their daily work. This article reports on qualitative and quantitative research to comprehend the strategies, tools, and knowledge used for program comprehension. We observed 28 professional developers, focusing on their comprehension behavior, strategies followed, and tools used. In an online survey with 1,477 respondents, we analyzed the importance of certain types of knowledge for comprehension and where developers typically access and share this knowledge. We found that developers follow pragmatic comprehension strategies depending on context. They try to avoid comprehension whenever possible and often put themselves in the role of users by inspecting graphical interfaces. Participants confirmed that standards, experience, and personal communication facilitate comprehension. The team size, its distribution, and open-source experience influence their knowledge sharing and access behavior. While face-to-face communication is preferred for accessing knowledge, knowledge is frequently shared in informal comments. Our results reveal a gap between research and practice, as we did not observe any use of comprehension tools and developers seem to be unaware of them. Overall, our findings call for reconsidering the research agendas towards context-aware tool support.
Walid Maalej, Rebecca Tiarks, Tobias Roehm, Rainer Koschke
ACM Trans. Softw. Eng. Methodol.2
2012 How do professional developers comprehend software?
abstract
Research in program comprehension has considerably evolved over the past two decades. However, only little is known about how developers practice program comprehension under time and project pressure, and which methods and tools proposed by researchers are used in industry. This paper reports on an observational study of 28 professional developers from seven companies, investigating how developers comprehend software. In particular we focus on the strategies followed, information needed, and tools used. We found that developers put themselves in the role of end users by inspecting user interfaces. They try to avoid program comprehension, and employ recurring, structured comprehension strategies depending on work context. Further, we found that standards and experience facilitate comprehension. Program comprehension was considered a subtask of other maintenance tasks rather than a task by itself. We also found that face-to-face communication is preferred to documentation. Overall, our results show a gap between program comprehension research and practice as we did not observe any use of state of the art comprehension tools and developers seem to be unaware of them. Our findings call for further careful analysis and for reconsidering research agendas.
Tobias Roehm, Rebecca Tiarks, Rainer Koschke, Walid Maalej
ICSE2
2012 A controlled experiment on software clones
abstract
Most software systems contain sections of duplicated source code - clones - that are believed to make maintenance more difficult. Recent studies tested this assumption by retrospective analyses of software archives. While giving important insights, the analysis of historical data relies only on snapshots and misses the human interaction in between. We conducted a controlled experiment to investigate how clones affect the programmer's performance in common bug-fixing tasks. While our results do not exhibit a decisive difference in the time needed to correct cloned bugs, we observed many cases in which cloned bugs were not corrected completely.
Jan Harder, Rebecca Tiarks
ICPC2
2011 An extended assessment of type-3 clones as detected by state-of-the-art tools
Rebecca Tiarks, Rainer Koschke, Raimar Falke
Softw. Qual. J.1
2009 An Assessment of Type-3 Clones as Detected by State-of-the-Art Tools
abstract
Code reuse through copying and pasting leads to so-called software clones. These clones can be roughly categorized into identical fragments (type-1 clones), fragments with parameter substitution (type-2 clones), and similar fragments that differ through modified,deleted, or added statements (type-3 clones). Although there has been extensive research on detecting clones, detection of type-3 clones is still an open research issue due to the inherent vaguenessin their definition. In this paper, we analyze type-3 clones detected by state-of-the-art tools and investigate type-3 clones in terms of their syntactic differences. Then, we derive their underlying semantic abstractions from their syntactic differences. Finally, we investigate whether there are any additional code characteristics that indicate that a tool-suggested clone candidate is a real type-3 clone from a human's perspective. Our findings can help developers of clone detectors to improve their tools.
Rebecca Tiarks, Rainer Koschke, Raimar Falke
SCAM1