Photo info

Photo by williamchp@flickr.

Description: View of Marina Bay Singapore from The Singapore Flyer

The photo is copyrighted by its owner. Unauthorized use is prohibited.

ASE 2016
September 3-7, 2016

ASE 2016
Presentation Instruction
Program Committee
Important Dates
Doctoral Symposium
Previous Years
Publicity Materials
Sponsored by:
Supported by:
Held in:

Call for Papers - Main Conference

The IEEE/ACM Automated Software Engineering (ASE) Conference series is the premier research forum for automated software engineering. Each year, it brings together researchers and practitioners from academia and industry to discuss foundations, techniques, and tools for automating the analysis, design, implementation, testing, and maintenance of large software systems. ASE 2016 invites high quality contributions describing significant, original, and unpublished results. Solicited topics include, but are not limited to:

  • Automated reasoning techniques
  • Component-based systems
  • Computer-supported cooperative work
  • Configuration management
  • Data mining for software engineering
  • Domain modeling and meta-modeling
  • Empirical software engineering
  • Human-computer interaction
  • Knowledge acquisition and management
  • Maintenance and evolution
  • Model-driven development
  • Model transformations
  • Program synthesis & transformations
  • Modeling language semantics
  • Open systems development
  • Program comprehension
  • Re-engineering
  • Requirements engineering
  • Specification languages
  • Software analysis
  • Software architecture and design
  • Software product line engineering
  • Software visualization
  • Testing, verification, and validation

Three categories of submissions are solicited:

  1. Technical Research Papers should describe innovative research in automating software development activities or automated support to users engaged in such activities. They should describe a novel contribution to the field and should carefully support claims of novelty with citations to the relevant literature. Where a submission builds upon previous work of the author(s), the novelty of the new contribution must be clearly described with respect to the previous work. Papers should also clearly discuss how the results were validated.
  2. Experience Papers should describe a significant experience in applying automated software engineering technology and should carefully identify and discuss important lessons learned, so that other researchers and/or practitioners can benefit from the experience. Of special interest are experience papers that report on industrial applications of automated software engineering.
  3. New Ideas Papers should describe novel research directions in automating software development activities or automated support to users engaged in such activities. New ideas submissions are intended to describe well-defined research ideas that are at an early stage of investigation and may not be fully validated.


Papers must be submitted electronically through the ASE 2016 submission site: All submissions must come in PDF format and conform, at time of submission, to the ACM Formatting Guidelines (LaTeX users, use the style Option 2). Please be aware that there is a new ACM template and a new classification system. Technical Research Papers and Experience Papers must not exceed 10 pages (including figures and appendices) plus up to 2 pages that contain ONLY references. New Ideas Papers must not exceed 6 pages (including figures, appendices AND references). Submissions that do not adhere to these limits or that violate the formatting guidelines will be desk-rejected without review. ASE '16 will pursue a double-blind review process. For details see Instructions for Authors. All submissions must be in English.

Important Dates
  • Abstract submission: April 22, 2016
  • Paper submission: April 29, 2016
  • Author notification: July 8, 2016
  • Camera ready: July 31, 2016

ASE 2016 Instructions for Authors

General Formatting

All submissions must be in PDF format and conform, at time of submission, to the ACM formatting guidelines. Technical Research papers and Experience papers must not exceed 10 pages (including figures and appendices) plus up to 2 pages that contain ONLY references. New Ideas papers must not exceed 6 pages (including figures, appendices, AND references). Please ensure your paper incorporates the following items. This is not a complete list and does not replace the ACM Formatting Guidelines, but it serves as a list of common issues:

  • Please be aware that there is a new ACM template and a new classification system
  • Prepare your paper as a letter-size PDF document.
  • Embed all fonts.
  • Use only scalable font types (e.g., Type 1, TrueType). Bitmapped font types (e.g., Type 3) are not acceptable.
  • Use either vector graphics or at least 300-dpi graphics.
  • Caption every figure and table and reference them in the text.
  • Do not use footnotes or references in the abstract.
  • Avoid color in the regular body text. Color is allowed in figures, tables, listings, and in non-body text, such as source code, XML snippets, etc.
  • Make sure the first reference does not overlap the heading "REFERENCES".
  • Balance columns on the last page.

Double-Blind Reviewing

ASE'16 will employ a lightweight double-blind review process. The papers submitted must not reveal the authors' identities. However, the author identities will be revealed when the reviewers submit their reviews and start discussing the pros and cons of the submissions. The authors must make every effort to honor the double-blind review process. In case of questions, please contact the PC Chairs.

Please check off the following items:

  • Omit authors' names and institutions from your title page.
  • When you cite your own work, refer to it in the third person. For example, if your name is Smith and you have worked on automated bug repair, instead of saying "We extend our work on information retrieval for finding and removing earwigs [0]," you should say "We extend Smith's [0] work on information retrieval for finding and removing earwigs."
  • Do not include acknowledgements of people, grants, organizations, etc. that would give away your identity. You may, of course, add these acknowledgements in the camera-ready version.
  • In general, aim to reduce the risk of accidental unblinding. For example, if you use a identifiable naming convention for your work, such as a project name, use a different name for your submission, which you may indicate has been changed for the purposes of double-blind reviewing. This includes names that may unblind individual authors and their institutions. For example, if your project is called GoogleDeveloperHelper, which makes it clear the work was done at Google, for the submission version, use the name DeveloperHelper or BigCompanyDeveloperHelper instead.
  • Avoid revealing the institution affiliation of authors or at which the work was performed. For example, if the evaluation includes a user study conducted with undergraduates from the CS 101 class that you teach, you might say "The study participants consist of 200 students in an introductory CS course." You can of course add the institutional information in the camera-ready.
  • Avoid linking directly to code repositories or tool deployments which can reveal your identify. You may post anonymized links (with a warning that following said link may reveal author identities), include links to anonymized code or deployments, or state that you will link to the code or deployment in the camera-ready version.

See the double-blind reviewing FAQs for more information.

FAQ on Double-Blind Reviewing


Q1: Why is ASE 2016 using double-blind reviewing?
Studies have shown that a reviewer's attitude toward a submission may be affected, even subconsciously, by author identity. We want reviewers to be able to approach each submission without such involuntary reactions as "Barnaby; he writes good papers" or "Who are these people? I have never heard of them." For this reason, we ask that authors omit their names from their submissions, and avoid revealing their identities through citations and text. Many systems, security, and programming language conferences use double-blind reviewing and have done so for years (e.g., SIGCOMM, OSDI, IEEE Security and Privacy, SIGMOD, PLDI). Software engineering conferences are gradually starting to adopt this model. For ASE, 2016 will be the first time using double-blind reviewing. This process will be cooperative, not adversarial. While the authors should take precautions not to reveal their identifies (see answer to Q4 below), if a reviewer discovers the authors' identities though a subtle oversight by the authors, the authors will not be penalized.

Q2: Do you really think blinding works? I suspect reviewers can often guess who the authors are.
Reviewers can sometimes guess the authorship correctly, though studies show this happens less often than people think. Still, imperfect blinding is better than no blinding at all, and even if all reviewers guess all authors' identities correctly, double-blind reviewing simply becomes traditional single-blind reviewing.

Q3: Couldn't blind submission create an injustice if a paper is inappropriately rejected because a reviewer is aware of prior unpublished work that actually is performed by the same authors?
The double-blind review process that we will be using for ASE 2016 is lightweight in the sense that author names are revealed once reviewers have submitted their reviews and start discussing the pros and cons of the submission. In this phase, the authors' previous work can be explicitly considered.

For authors

Q4: What exactly do I have to do to anonymize my paper?
Your job is not to make your identity undiscoverable, but to make it possible for our reviewers to evaluate your submission without knowing who you are. If you have a concern that particular information is particularly easy to trace to you, consider adding a warning to reviewers in a footnote, such as "Note for reviewers: searching the commit logs of the github projects we used in our evaluation may reveal author identities."

Q5: I would like to provide supplementary material for consideration, e.g., the code of my implementation or proofs of theorems. How do I do this?
In general, supplementary material should also be anonymized. If the code or the repository cannot be anonymized easily, please either (A) provide an anonymized url (such as using a URL shortener like with a prominent warning to reviewers that following the link may unblind them or, (B) if this is not possible, remove the URL to the repository from the paper and, instead, state "link to repository removed for double-blind review" or similar. Once the author names are revealed, the reviewers can ask the PC chairs for the URL, who will contact the authors.

Q6: I am building on my own past work on the WizWoz system. Do I need to rename this system in my paper for purposes of anonymity, so as to remove the implied connection between my authorship of past work on this system and my present submission?
Not necessarily. If knowing the name of the system reveals your identity or institution, then you should use an alias system name in the submission. For example, a paper on a modification to a proprietary system (e.g., Visual C++, or a closed-source research project) implicitly reveals the identity of the authors or their institution, and that paper should use an alias name for the system. In your submission, point out that the system name has been anonymized. If you have any doubts, please contact the PC Chairs. By contrast, if the system is widely available and open-source, there is no need to rename the system.

Q7: Am I allowed to post my (non-blinded) paper on my web page? Can I advertise the unblinded version of my paper on mailing lists or send it to colleagues? May I give a talk about my work while it is under review?
As far as the authors' publicity actions are concerned, a paper under double-blind review is largely the same as a paper under regular (single-blind) review. Double-blind reviewing should not hinder the usual communication of results. But, during the review period, please don't broadcast the work on social media. Instead, you may link to it in arXiv or on your Web site and talk about it.

Q8: Will the fact that ASE is double-blind have an impact on handling conflicts of interest?
Using double-blind reviewing does not change the principle that reviewers should not review papers with which they have a conflict of interest, even if they do not immediately know who the authors are. Conflicts of interest are identified based on the authors' and reviewers' names and affiliations, and they can be declared by both the authors and reviewers.

For reviewers

Q9: What should I do if I if I learn the authors' identities? What should I do if a prospective ASE author contacts me and asks to visit my institution?
If at any point you feel that the authors' actions are largely aimed at ensuring that potential reviewers know their identity, you should contact the PC Chairs. If you are unsure, contact the PC Chairs. Otherwise you should not treat double-blind reviewing differently from regular single-blind reviewing. You should refrain from seeking out information on the authors' identities, but discovering it accidentally will not automatically remove you from reviewing a paper you have been assigned. Use your best judgment and feel free to contact us with any concerns.

Q10: How do we handle potential conflicts of interest since I cannot see the author names?
CyberChair will ask you to identify conflicts of interest before bidding. For this purpose, a list of all authors and affiliations will be presented. Please see the related question (Q8) applied to authors to decide how to identify conflicts.

This FAQ is based on several iterations of PLDI and SIGMOD guidelines for double-blind reviewing.


Call for Tool Demonstrations

The objective of the ASE 2016 Demonstrations Track is to excite the software engineering community about new advances in our field through compelling demonstrations that help advance research and practice. The track is a highly interactive venue where researchers and practitioners can demonstrate their tools and discuss them with attendees.

Tool-based demonstrations describe novel aspects of early prototypes or mature tools. The tool demonstrations must communicate clearly the following information to the audience:

  • the envisioned users;
  • the software engineering challenge it proposes to address;
  • the methodology it implies for its users; and
  • the results of validation studies already conducted for mature tools, or the design of planned studies for early prototypes.

Highlighting scientific contributions through concrete artifacts is a critical supplement to the traditional ASE research papers. A demonstration provides the opportunity to communicate how the scientific approach has been implemented or how a specific hypothesis has been assessed, including details such as implementation and usage issues, data models and representations, APIs for tool and data access. Authors of regular research papers are thus also encouraged to submit an accompanying demonstration paper.


Each submission will be reviewed by at least three members of the demonstrations selection committee. The evaluation criteria include:

  • the relevance of the proposed demonstration for the ASE audience;
  • the technical soundness of the demonstrated tool (for a tool demo);
  • the originality of its underlying ideas;
  • the quality of its presentation in the associated video; and
  • the degree to which it considers the relevant literature.

How to Submit

Submissions must conform to the ASE 2016 formatting and submission instructions. In particular, submissions of demonstrations papers must meet the following criteria.

  • A demonstration submission may not exceed six pages (including all text, references and figures).
  • Each submission MUST be accompanied by a short video (between three and five minutes long) illustrating the demonstration. The video should be made available online at the time of submission. Videos should (i) provide an overview of the tool's capabilities; (ii) walk through (some of) the tool capabilities; (iii) where appropriate, provide clarifying voice-over and/or annotation highlights; and (iv) be engaging and exciting for the watcher!
  • A submission may not have been previously published in a demonstration form.
  • Submissions for tool track will NOT follow double-blind review process.
  • The paper submission must be in PDF.

Papers must be submitted electronically through EasyChair ( by May 31st, 2016.

At the end of the abstract, please append the URL at which your demo video can be found. Please note that for consistency, we require that ALL videos be uploaded to YouTube and made accessible during the time of reviewing. Authors of successful submissions will have the opportunity to revise both the paper and the video (and its hosting location) by the camera-ready deadline.

For further information, please email

Important Dates

  • Tool demonstration submission: May 31, 2016
  • Tool demonstration notification: June 27, 2016
  • Tool demonstration camera ready: July 31, 2016

Demonstrations Co-Chairs

Formatting and submission instructions

Submissions must conform to the ASE 2016 formatting guidelines, and must not exceed 6 pages including all text, references and figures. Submissions must mention authors name and affiliation i.e., double-blind review does not apply to tool track. Submissions that do not comply with the instructions and size limits will be rejected without review.

Call for Doctoral Symposium

Invited Talk

We are pleased to announce that Andrian Marcus from University of Texas at Dallas will give a keynote at the PhD symposium.


The goal of the ASE 2016 Doctoral Symposium is to provide a supportive yet questioning setting in which the Ph.D. students have an opportunity to present and discuss their research with other researchers in the ASE community. The symposium aims at providing students useful guidance and feedback on their research and to facilitate networking within the scientific community by interacting with established researchers and with their peers at a similar stage in their careers.

Important Dates:
  • Submission: June 10, 2016 June 24, 2016, 11:59 PM (AOE)
  • Notification: July 15, 2016
  • Camera-ready copy: July 31, 2016

The technical scope of the symposium is the same as the main ASE conference. Students should consider participating in the Doctoral Symposium after they have settled on a dissertation topic with some initial research results. The ASE 2016 Doctoral Symposium is open to Ph.D. students at any stage of their research, whereby students at the initial stage (first or second year) will be able to challenge their ideas and current research directions, while students at a later stage (third or fourth year) will be able to present their preliminary results and get feedback and advice for improvement and for better exposition of their contributions and conclusions.


The Doctoral Symposium Committee will select participants using the following criteria:

  • The quality of the research (plan) and its relevance to ASE
  • Quality of the research abstract
  • Technical soundness and originality of the proposed work
  • For students at a later-stage of the PhD, quality of the achieved results

Students should not infer that a list of prior publications is in any way expected or required; we welcome submissions from students for whom this will be their first formal submission as well as those who have previously published.

How to Submit

To apply as a student participant in the ASE 2016 Doctoral Symposium, one should prepare a submission package consisting of two parts, both of which must be submitted by the submission deadline (see instructions below).

All submissions must come in PDF format and conform, at the time of submission, to ACM Formatting Guidelines. Authors should use the US letter style.

The research abstract must be submitted electronically through EasyChair at

Part 1: Research Abstract (max. 4 pages)

The research abstract must conform to the ASE 2016 formatting and submission instructions and should cover:

  • The research problem with justification of its importance
  • Discussion on previous work by submitter and others
  • A sketch of the proposed approach or solution
  • The expected contributions of the dissertation research
  • Progress that has been made so far in solving the stated problem
  • The methods that are or will be used to carry out the research
  • A plan for evaluating the work and presenting credible evidence to the research community
  • Preliminary results (if any) of the proposed approach or solution
  • A list of publications (if any) of the submitter (appeared, accepted, submitted)

The submitting student has to be the single author of the submission. No other authors are allowed. The advisor's name(s), affiliation(s) and email(s) must be clearly indicated in the submission text.

Part 2: Letter of Recommendation

In addition to the research abstract, a submitter must provide a letter for recommendation from their Ph.D. advisor. This letter should include the student's name and a candid assessment of the current status of the dissertation research and an expected date for dissertation submission. The recommendation letter should be in PDF, and sent to the co-chairs: with the subject "ASE 2016 DOCTORAL SYMPOSIUM RECOMMENDATION".


All authors of accepted contributions will receive further instructions for preparing their camera ready versions. Authors must register for the ASE 2016 Doctoral Symposium and present their work at the symposium.

Doctoral Symposium Chairs

Call for Workshops

A workshop co-located with the ASE 2016 conference should provide an opportunity for exchanging views, advancing ideas, and discussing preliminary results on topics related to Automated Software Engineering. Workshops may also serve as platforms to nurture new scientific communities. Workshops should not be seen as an alternative forum for presenting full research papers. The workshops co-located with the conference will be organized before the main conference (Saturday, Sunday). The workshop co-chairs will decide the exact day after the proposals have been reviewed and accepted. A workshop may last one, one and half, or two days.

Workshop registration will be waived for one keynote speaker per workshop.

Proposals are due by 11:59 PM (AoE), March 18, 2016.

Proposals for organizing workshops should be written in English, limited to 5 pages (in ACM format), and submitted in PDF to both workshop co-chairs Leonardo Mariani and Zhenchang Xing by e-mail ( and

Workshop proposals should include the following information:

  • Theme and goals of the workshop including its relevance to the field of Automated Software Engineering.
  • Targeted audience and the expected number of participants (minimum and maximum).
  • Workshop format (e.g., paper presentations, breakout sessions, panel-like discussions, combination of formats).
  • The equipment, room capacity, and any other resource necessary for the organization of the workshop.
  • Participant solicitation and selection process.
  • Publicity strategy that will be used by the workshop organizers to promote the workshop.
  • Brief description of the workshop organizer's background, including relevant past experience on organizing workshops and contact information.
  • Information about past editions of the same workshop, if any.
  • Initial version of the call for papers that the workshop organizers intend to use.
  • Preferences for workshop dates, duration (1, 1.5 or 2 days), and any other scheduling constraints.

Note that the workshop co-chairs will consider the preference of workshop dates specified by the workshop organizers, but the acceptance of a workshop proposal does not guarantee adherence to the requested date/time. The workshop co-chairs will assume that workshop organizers will be able to run a workshop on the dates that ASE 2016 has reserved for workshops.

All submissions must come in PDF format and conform, at the time of submission, to the ACM Formatting Guidelines (LaTeX users, use the style Option 2).

Review Process

Workshop proposals will be reviewed by the ASE 2016 workshop co-chairs. Acceptance will be based on an evaluation of the workshop's potential for generating useful results, the timeliness and expected interest in the topic, the organizer's ability to lead a successful workshop, and the potential for attracting a sufficient number of participants. Accepted workshops must adhere to the common deadlines listed below for submissions of papers, acceptance of papers, and preparation of proceedings.

Important Dates

  • Workshop proposal submission: March 18, 2016
  • Workshop proposal notification: March 25, 2016
  • Workshop websites online: April 8, 2016
  • Workshop paper submission and notification: Check the individual workshops website
  • Workshop program plan submission: June 27, 2016.
    Note: Organizers need to inform chairs about number of accepted papers and rough program (e.g., number of sessions, number of panels, number of invited or keynote talks, etc.).
  • Workshop program plan approval: July 1, 2016.
    Note: Organizers would be notified as to whether the workshop would run and the approved duration of the workshop (1, 1.5, or 2 days). Workshops with too few papers or poor program may be cancelled.
  • Workshop list of accepted papers published: July 6, 2016
  • Workshop program finalized: July 15, 2016
  • Workshop paper authors' registration deadline: July 22, 2016
    Note: The registration fee for one invited or keynote speaker will be waived. Workshop organizers need to register for their workshops to defray the cost of organizing the workshop.
  • Workshop paper camera ready: July 31, 2016
    Note: All papers must conform to the ACM Formatting Guidelines.

Call for Tutorials

Tutorials address a wide range of mature topics from theoretical foundations to practical techniques and tools for automated software engineering. The tutorials will be organized either on the Monday or Tuesday before the main conference. The general chair and organizers will decide the exact dates after all proposals have been reviewed and accepted. Note that tutorials are intended to provide independent instruction on a relevant theme; therefore, no commercial or sales-oriented proposals will be accepted.

Instructors are invited to submit proposals for half-day and full-day tutorials and, upon selection, are required to provide tutorial notes on the topic of presentation in PDF. Proposals for organizing tutorials should be written in English, limited to 5 pages (in ACM format), and submitted in PDF to both tutorials co-chairs Tien N. Nguyen and Rui Abreu. The proposal submissions should include the following information:

  • Name and affiliation of the proposer/organizer (including postal address, phone number, fax number, and e-mail address)
  • Name and affiliation of each additional instructor
  • Instructors' experience in the area, including other tutorials, courses, etc.
  • Title, objective, abstract, and duration
  • Outline with approximate timings
  • Target audience, including the indication of level (novice, intermediate, expert)
  • Assumed background of attendees
  • Brief biography of each instructor (for later inclusion in publicity materials)
  • History of the tutorial (if it has been already presented; provide location, approximate attendance, etc.)
  • Audio-visual and technical requirements
  • References including the proposers' papers on the subject
  • Preferences for tutorial date, duration (half-day or full-day), and any other scheduling constraints, with justification for full day (if a full day is proposed)

Note that the tutorial co-chairs will consider the preference of tutorial dates specified by the organizers. However, the acceptance of a tutorial proposal does not guarantee adherence to the requested date and time. The tutorial co-chairs assume that tutorial proposers will be able to run a tutorial on the dates that ASE 2016 has reserved for tutorials.

Proposals are due by 11:59 PM (AoE), May 13, 2016.

All submissions must come in PDF format and conform, at the time of submission, to the ACM Formatting Guidelines (LaTeX users, use the style Option 2).

Review Process

Tutorial proposals will be reviewed by the ASE 2016 tutorials co-chairs. Acceptance will be based on the timeliness and expected interest in the topic, the proposer's ability to present an interesting tutorial, and the potential for attracting a sufficient number of participants.

Important Dates

  • Tutorial proposal submission: May 13, 2016
  • Tutorial proposal notification: May 27, 2016
  • Tutorial advertisement text submission: June 10, 2016
    Note: The authors of accepted proposals must provide text to advertise their tutorials. This text should include tutorial description and author information (picture, website link, and biodata). This text would be put on the conference website.
  • Tutorial final notification: July 25, 2016
    Note: Tutorials with too few registered attendees may be cancelled.

Hosted by School of Information Systems, Singapore Management University, Singapore.
Webmaster: Pavneet Singh and Ferdian Thung