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.

Robert G. Mays

dblp:63/811 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 1990
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 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 · 61% Empirical software engineering · 30% Requirements engineering and software design · 9%

Topics — the 3 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering
causal inference
0.011990
Applications of Defect Prevention in Software Development · IEEE J. Sel. Areas Commun. 1990
Software maintenance and evolution › software quality assurance
defect prevention
0.011990
Applications of Defect Prevention in Software Development · IEEE J. Sel. Areas Commun. 1990
Software maintenance and evolution
software process improvement
0.011990
Applications of Defect Prevention in Software Development · IEEE J. Sel. Areas Commun. 1990

Methods — techniques the papers use, named apart from their topics

case study · 0.0
YearPublicationVenuePosition
1990 Applications of Defect Prevention in Software Development
abstract
A description is given of the defect prevention process. It consists of causal analysis meetings to identify the root causes of errors and suggest preventive actions, an action team that implements the preventive actions, stage kickoff meetings to provide feedback to developers at each stage of the development cycle, and data collection and tracking of associated data. Typical preventive actions include process changes (including common error lists, checklists, and other forms of feedback), new or improved tools, improved education, product changes, and improved communications among developers. The defect prevention process has been applied successfully in a number of software development organizations within IBM, with significant reduction in errors. The application of this process to different types of organizations involved in software development, including design, development, test, information development, planning and requirements, and human factors is described. For each type of organization, different processes, tools, and methodologies are used. It is shown that the defect prevention process can be applied to errors arising from each particular process.>
Robert G. Mays
IEEE J. Sel. Areas Commun.1