Demo Data from EDBT 2026 / reviewers in the wild / expert
Johan Persson
dblp:161/3334
· DBLP profile ↗
1ranked-venue papers
0as first author
0since 2021 · last 2015
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Human-computer interaction and ubiquitous computing · 1
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
1 paper |
Requirements engineering and software design · 50% Empirical software engineering · 50% | |
| Human-computer interaction and pervasive computing
1 paper |
Collaborative and social computing · 100% |
Topics — the 1 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › software design representation
design documentation |
0.2 | 1 | 2015 | Communication through Boundary Objects in Distributed Agile Teams · CHI 2015 |
Methods — techniques the papers use, named apart from their topics
interview study · 0.4
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2015 | Communication through Boundary Objects in Distributed Agile TeamsabstractPersonal communication between User-Centered Design (UCD) specialists and developers is important for communicating user needs and design solutions in agile development. In distributed projects where opportunities for personal communication are limited, the design documentation is an important surrogate. This study has investigated the perceived effectiveness of boundary objects in a distributed agile team, and their role in communicating target user needs. Six in-depth interviews with UCD specialists showed that the boundary objects rarely communicate underlying needs of the users but rather focus on interaction with the system that is being developed. The used boundary objects also do not work as stand-alone deliverables; they need to be explained and elaborated. Making the boundary objects comprehensive enough to be stand-alone is seen as too time consuming and not worth the effort. For agile projects with distributed teams, this creates hand-over and follow-up problems. Johan Blomkvist, Johan Persson, Johan Aberg |
CHI | 2 |