Demo Data from VLDB 2026 / reviewers in the wild / expert
Stanley G. Siegel
dblp:01/194
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 1984
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2Applied, interdisciplinary, general and emerging 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 |
Software maintenance and evolution · 44% Requirements engineering and software design · 44% Software testing · 13% |
Topics — the 3 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 evaluation
design review |
0.0 | 1 | 1984 | Making Software Visible, Operational, and Maintainable in a Small Project Environment · IEEE Trans. Software Eng. 1984 |
Software maintenance and evolution
software configuration management |
0.0 | 1 | 1984 | Making Software Visible, Operational, and Maintainable in a Small Project Environment · IEEE Trans. Software Eng. 1984 |
Software testing
test process |
0.0 | 1 | 1984 | Making Software Visible, Operational, and Maintainable in a Small Project Environment · IEEE Trans. Software Eng. 1984 |
Methods — techniques the papers use, named apart from their topics
configuration control board · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1984 | Making Software Visible, Operational, and Maintainable in a Small Project EnvironmentabstractPractical suggestions are presented for effectively managing software development in small-project environments (i.e., no more than several million dollars per year). The suggestions are based on an approach to product development using a product assurance group that is independent from the development group. Within this check-and-balance management/development/product assurance structure, a design review process is described that effects an orderly transition from customer needs statement to software code. The testing activity that follows this process is then explained. Finally, the activities of a change control body (called a configuration control board) and supporting functions geared to maintaining delivered software are described. The suggested software management practices result from the experience of a small (approximately 100 employees) software engineering company that develops and maintains computer systems supporting real-time interactive commercial, industrial, and military applications. William L. Bryan, Stanley G. Siegel |
IEEE Trans. Software Eng. | 2 |
| 1979 | Attaining software product integrityabstractThis paper discusses what is required to attain integrity in a software product. The concept of product integrity is first defined. Organizational structures required to attain software product integrity are then discussed. The role of management in attaining and maintaining software product integrity is then addressed. The paper concludes with a discussion of the two groups of disciplines needed to attain this integrity -the product assurance disciplines and the "doing" disciplines. Edward H. Bersoff, Vilas D. Henderson, Stanley G. Siegel |
COMPSAC | 3 |