Demo Data from EDBT 2026 / reviewers in the wild / expert
Mark G. Bradac
dblp:74/2609
· DBLP profile ↗
2ranked-venue papers
2as first author
0since 2021 · last 1994
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2 · 2 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 |
Services computing and microservices · 86% Requirements engineering and software design · 14% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Services computing and microservices › business process management
business process monitoring |
0.0 | 2 | 1994 | Prototyping a Process Monitoring Experiment · IEEE Trans. Software Eng. 1994 Prototyping a Process Monitoring Experiment · ICSE 1993 |
Requirements engineering and software design › software product lines
feature-oriented software development |
0.0 | 1 | 1994 | Prototyping a Process Monitoring Experiment · IEEE Trans. Software Eng. 1994 |
Methods — techniques the papers use, named apart from their topics
time diary · 0.0sampling · 0.0prototyping · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1994 | Prototyping a Process Monitoring ExperimentabstractFeatures are often the basic unit of development for a very large software system and represent long-term efforts, spanning up to several years from inception to actual use. Developing an experiment to monitor (by means of sampling) such lengthy processes requires a great deal of care in order to minimize casts and to maximize benefits. Just as prototyping is often a necessary auxiliary step in a large-scale, long-term development effort, so, too, is prototyping a necessary step in the development of a large-scale, long-term process monitoring experiment. Therefore, we have prototyped our experiment using a representative process and reconstructed data from a large and rich feature development. This approach has yielded three interesting sets of results. First, we reconstructed a 30-month time diary for the lead engineer of a feature composed of both hardware and software. These data represent the daily state (where the lead engineer spent the majority of his time) for a complete cycle of the development process. Second, we found that we needed to modify our experimental design. Our initial set of states did not represent the data as well as we had hoped. This is exemplified by the fact that the "Other" category is too large. Finally, the data provide evidence for both a waterfall view and an interactive, cyclic view of software development. We conclude that the prototyping effort is a necessary part of developing and installing any large-scale process monitoring experiment.> Mark G. Bradac, Dewayne E. Perry, Lawrence G. Votta |
IEEE Trans. Software Eng. | 1 |
| 1993 | Prototyping a Process Monitoring Experiment
Mark G. Bradac, Dewayne E. Perry, Lawrence G. Votta |
ICSE | 1 |