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

William L. Bryan

dblp:92/6859 · DBLP profile ↗
← Back
1ranked-venue papers
1as 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 · 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
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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design › software design evaluation
design review
0.011984
Making Software Visible, Operational, and Maintainable in a Small Project Environment · IEEE Trans. Software Eng. 1984
Software maintenance and evolution
software configuration management
0.011984
Making Software Visible, Operational, and Maintainable in a Small Project Environment · IEEE Trans. Software Eng. 1984
Software testing
test process
0.011984
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
YearPublicationVenuePosition
1984 Making Software Visible, Operational, and Maintainable in a Small Project Environment
abstract
Practical 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.1