VLDB 2026 Research / reviewers in the wild / expert
Robert Waters
dblp:78/6783
· DBLP profile ↗
3ranked-venue papers
1as first author
0since 2021 · last 2000
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Human-computer interaction and ubiquitous computing · 2Software engineering, systems software and programming languages · 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
1 paper |
Requirements engineering and software design · 75% Software maintenance and evolution · 25% | |
| Theoretical computer science
1 paper |
Logic in computer science · 100% |
Topics — the 5 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › software architecture › architectural design
architecture synthesis |
0.0 | 1 | 1999 | Architectural Element Matching Using Concept Analysis · ASE 1999 |
Software maintenance and evolution
reverse engineering |
0.0 | 1 | 1999 | Architectural Element Matching Using Concept Analysis · ASE 1999 |
Requirements engineering and software design
software architecture |
0.0 | 1 | 1999 | Architectural Element Matching Using Concept Analysis · ASE 1999 |
Requirements engineering and software design › software architecture › software architecture analysis
software architecture recovery |
0.0 | 1 | 1999 | Architectural Element Matching Using Concept Analysis · ASE 1999 |
Logic in computer science › knowledge representation and reasoning
formal concept analysis |
0.0 | 1 | 1999 | Architectural Element Matching Using Concept Analysis · ASE 1999 |
Methods — techniques the papers use, named apart from their topics
lattice construction · 0.0concept analysis · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2000 | A Proposed Curriculum for an Undergraduate Software Engineering DegreeabstractWe have developed a curriculum for a software engineering undergraduate degree. We used the medical school clinical model to guide our design as it successfully combines both knowledge and practice components. Through rotations, our curriculum will provide graduates with both an advanced knowledge of software engineering concepts and practical skills that have been honed in a realistic setting. We present our proposed curriculum and the difficulties we foresee in implementing it. Michael McCracken, Idris Hsi, Heather Lipford, Robert Waters, Laura Burkhart |
CSEE&T | 4 |
| 1999 | Why? When an otherwise successful intervention failsabstractProblem-Based Learning (PBL) has been an effective technique in developing self-directed learning and problem-solving skills in students --- especially in the medical school environment. This paper looks at some preliminary results of an ethnographic study of students in a software development environment trying to use PBL. Our findings indicate that students need explicit training in group dynamics, students tend to rely excessively on existing knowledge, and they focus almost solely on product-related issues versus process-related ones. We then present some suggested improvements and future planned research. Michael McCracken, Robert Waters |
ITiCSE | 2 |
| 1999 | Architectural Element Matching Using Concept AnalysisabstractA large portion of software development effort is focused on modification and evolution of existing software systems. To feed forward-engineering and design activities, analysts must first recover and synthesize a complete and consistent set of architectural representations. Architectural Synthesis is one method to build this representation. During the Architectural Synthesis of a software system, an analyst must combine information derived from a variety of sources (which we call perspectives). This combination process requires the analyst to make decisions about which elements in the perspectives denote the same underlying parts of the software system. We present an automated technique for matching these elements based upon a mathematical technique called concept analysis. This technique constructs a spectrum of matching relations using a lattice of concepts drawn from the perspectives and descriptive information about the system's application domain. The results show the promise of using concept analysis to match elements and aid in synthesizing a large number of perspectives. Robert Waters, Spencer Rugaber, Gregory D. Abowd |
ASE | 1 |