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

Khalid H. Siddiqui

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

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

Software engineering, systems software and programming languages · 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
Requirements engineering and software design · 100%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Performance modeling and evaluation · 100%

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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design › specification
software specification
0.012002
Performance-related completions for software specifications · ICSE 2002
Performance modeling and evaluation › software performance engineering
software performance analysis
0.012002
Performance-related completions for software specifications · ICSE 2002

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

use case maps · 0.1
YearPublicationVenuePosition
2002 Performance-related completions for software specifications
abstract
To evaluate a software specification for its performance potential, it is necessary to supply additional information, not required for functional specification. Examples range from the execution cost of operations and details of deployment, up to missing subsystems and layers. The term "completions" is used here to include all such additions, including annotations, component insertions, environment infrastructure, deployment, communication patterns, design refinements and scenario or design transformations which correspond to a given deployment style. Completions are related to the purpose of evaluation, so they are tailored to describing the performance at a suitable level of detail. Completions for evaluating other attributes such as reliability or security are also possible. The paper describes how completions are added to a specification regardless of the language used (provided that it describes the system behaviour as well as its structure), and experience with completions in Use Case Maps.
C. Murray Woodside, Dorin Bogdan Petriu, Khalid H. Siddiqui
ICSE3