ISSRE 2020 : The 31st International Symposium on Software Reliability Engineering

Important dates (all in 2020)

• Abstract submission deadline: May 18th
• Full paper submission deadline: May 25th
• Author rebuttal period: July 16th-18th
• Notification to authors: July 28th
• Camera ready papers: August 20th

Paper Categories

Submissions can be made in one of the following categories (authors are required to indicate the category as part of the paper’s title, for review only).

• REG papers: 10 pages + 2 pages (for references alone).
• PER papers: 10 pages + 2 pages (for references alone).
• TAR papers: 6 - 10 pages (with references).

Papers that exceed the number of pages for that submission category will be rejected without review.

Topics of Interest

Topics of interest include development, analysis methods and models throughout the software development lifecycle, and are not limited to:

• Primary dependability attributes (i.e., security, safety, maintainability) impacting software reliability
• Secondary dependability attributes (i.e., survivability, resilience, robustness) impacting software reliability
• Reliability threats, i.e. faults (defects, bugs, etc.), errors, failures
• Reliability means (fault prevention, fault removal, fault tolerance, fault forecasting)
• Metrics, measurements and threat estimation for reliability prediction and the interplay with safety/security
• Reliability of software services
• Reliability of open source software
• Reliability of Software as a Service (SaaS)
• Reliability of software dealing with Big Data
• Reliability of model-based and auto-generated software
• Reliability of software in artificial intelligence based software systems
• Reliability of software within specific types of systems (e.g., autonomous and adaptive, green and sustainable, mobile systems)
• Reliability of software within specific technological spaces (e.g., Internet of Things, Cloud, Semantic Web/Web 3.0, Virtualization, Blockchain)
• Normative/regulatory/ethical spaces pertaining to software reliability
• Societal aspects of software reliability

Anonymizing Rules

Authors shall anonymise their paper. As an author, you should not identify yourself in the paper either explicitly or by implication (e.g., through the references or acknowledgments). However, only non-destructive anonymization is required. For example, system names may be left un-anonymized, if the system name is important for a reviewer to be able to evaluate the work. For example, a paper on experiences with the design of .NET should not be re-written to be about “an anonymous but widely used commercial distributed systems platform.”

Additionally, please take the following steps when preparing your submission:

• Remove authors’ names and affiliations from the title page
• Remove acknowledgement of identifying names and funding sources
• Use care in naming your files. Source file names, e.g., Joe.Smith.dvi, are often embedded in the final output as readily accessible comments.
• Use care in referring to related work, particularly your own. Do not omit references to provide anonymity, as this leaves the reviewer unable to grasp the context. Instead, a good solution is to reference your past work in the third person, just as you would any other piece of related work.
• If you have a concurrent submission, reference it as follows: “Closely related work describes a microkernel implementation [Anonymous 2014].” with the corresponding citation: “[Anonymous 2014] Under submission. Details omitted for double-blind reviewing.”
• If you cite anonymous work, you must also send the deanonymized reference(s) to the PC chair in a separate email.
• Submissions that do not conform to the above submission deadline, anonymization and formatting guidelines (e.g., are too long, use fonts or line spacing smaller than what is indicated) or are unoriginal, previously published, or under submission to multiple venues, will be disregarded.