conferences.computer.science

All conferences / ICSE / 2027

ICSE 2027

49th International Conference on Software Engineering

Held25 Apr – 1 May 2027 WhereDublin 🇮🇪 RankCORE A* Website conf.researchr.org/dates/icse-2027 ↗
Closed

Submission closed on 30 Jun 2026.

Submission timeline

  • 23 Jun 2026 Abstract registration
  • 30 Jun 2026 Full paper
  • 18 Dec 2026 Notification
  • 25 Apr 2027 Conference opens

What to submit

Format
10 pages ACM + 2p references
Proceedings
ACM open — Free access
Reviewing
Double blind
Rebuttal
23 Sep 2026 to 25 Sep 2026
Artifacts
Open artifacts encouraged though not mandatory

ICSE 2026 will follow a dual deadline structure introduced in 2024. Revisions, rebuttal. Also a doctoral symposium, tutorials, demos, and other events.

Call for papers

The call, as published

Reproduced verbatim from the organisers’ announcement. The conference’s own page is at conf.researchr.org/dates/icse-2027.

-----------------------------------------------------------------------------------------
CALL FOR PAPERS - ICSE 2027 - RESEARCH TRACK
-----------------------------------------------------------------------------------------
49th International Conference on Software Engineering (ICSE 2027) Sun 25th April - Sat 1st May 2027
Dublin, Ireland

Call for Papers: Research Track
https://conf.researchr.org/track/icse-2027/icse-2027-research-track

Submission deadlines:
* Tuesday 23rd June 2026 (Mandatory) Abstract
* Tuesday 30th June 2026 Submission
------------------------------------------------------------------------------------------

The International Conference on Software Engineering (ICSE) is the premier forum for presenting and
discussing the most recent and significant technical research contributions in the field of Software
Engineering. In the research track, we invite high-quality submissions of technical research papers
describing original and unpublished results of software engineering research.

# STRUCTURE
-----------------------------------------------

ICSE 2027 will follow a single deadline structure.
In other words, submissions will occur in one cycle. Further details in the section on Single Submission
Cycle below.

# RESEARCH AREAS
-----------------------------------------------

ICSE welcomes submissions addressing topics across the full spectrum of Software Engineering, namely
quantitative, qualitative, and mixed-methods research. Topics of interest include the following, grouped
into nine research areas. Please note that these topics are by no means exhaustive.

Each submission will need to indicate one of these nine areas as the chosen area. Optionally, the authors
can consider adding an additional area. A paper may be moved from the chosen area(s) to another focus
area at the discretion of the program chairs. Program chairs will ultimately assign a paper to an area
chair, considering the authors' selection, the paper's content, and other factors such as (if applicable)
possible conflicts of interest.

## AI for Software Engineering
-----------------------------------------------
* AI-enabled recommender systems for automated SE (e.g., code generation, program repair, AIOps,
software composition analysis, etc.)
* Human-centered AI for SE (e.g., how software engineers can synergistically work with AI agents)
* Trustworthy AI for SE (e.g., how to provide guarantees, characterize limits, and prevent misuse of AI for
SE)
* Sustainable AI for SE (e.g., how to reduce energy footprint for greener AI for SE)
* Collaborative AI for SE (e.g., how AI agents collaborate for automating SE)
* Automating SE tasks with LLM and other foundation models (e.g., large vision model)
* Efficacy measurement beyond traditional metrics (e.g., accuracy, BLEU, etc.)
* Prompt engineering for SE (e.g., novel prompt design)
* AI-assisted software design and model driven engineering (e.g., specification mining, program
synthesis, software architectural design)

## Analytics
-----------------------------------------------
* Mining software repositories, including version control systems, issue tracking systems, software
ecosystems, configurations, app stores, communication platforms, and novel software engineering data
sources, to generate insights through various research methods
* Software visualization
* Data-driven user experience understanding and improvement
* Data driven decision making in software engineering
* Software metrics (and measurements)

## Architecture and Design
-----------------------------------------------
* Architecture and design measurement and assessment
* Software design methodologies, principles, and strategies
* Theory building for/of software design
* Architecture quality attributes, such as security, privacy, performance, reliability
* Modularity and reusability
* Design and architecture modeling and analysis
* Architecture recovery
* Dependency and complexity analysis
* Distributed architectures, such as microservice, SOA, cloud computing
* Patterns and anti-patterns
* Technical debt in design and architecture
* Architecture refactoring
* Adaptive architectures
* Architecture knowledge management

## Dependability and Security
-----------------------------------------------

* Formal methods and model checking (excluding solutions focusing solely on hardware)
* Reliability, availability, and safety
* Resilience and antifragility
* Confidentiality, integrity, privacy, and fairness
* Performance
* Design for dependability and security
* Vulnerability detection to enhance software security
* Dependability and security for embedded and cyber-physical systems

## Evolution
-----------------------------------------------

* Evolution and maintenance
* API design and evolution
* Release engineering and DevOps
* Software reuse
* Refactoring and program differencing
* Program comprehension
* Reverse engineering
* Environments and software development tools
* Traceability to understand evolution

## Human and Social Aspects
-----------------------------------------------

* Focusing on individuals (from program comprehension, workplace stress to job satisfaction and career
progression)
* Focusing on teams (e.g., collocated, distributed, global, virtual; communication and collaboration
within a team), communities (e.g., open source, communities of practice) and companies (organization,
economics)
* Focusing on society (e.g., sustainability; diversity and inclusion)
* Focusing on programming languages, environments, and tools supporting individuals, teams,
communities, and companies.
* Focusing on software development processes

## Requirements and Modeling
-----------------------------------------------

* Requirements engineering (incl. non-functional requirements)
* Theoretical requirement foundations
* Requirements and architecture
* Feedback, user and requirements management
* Requirements traceability and dependencies
* Modeling and model-driven engineering
* Variability and product lines
* Systems and software traceability
* Modeling languages, techniques, and tools
* Empirical studies on the application of model-based engineering
* Model-based monitoring and analysis

## Software Engineering for AI
-----------------------------------------------

* SE for AI models
* SE for systems with AI components
* SE for AI code, libraries, and datasets
* Engineering autonomic systems and self-healing systems
* Automated repair of AI models
* Testing and verification of AI-based systems
* Validation and user-based evaluation of AI-based systems
* Requirements engineering for AI-based systems

## Testing and Analysis
-----------------------------------------------

* Software testing
* Automated test generation techniques such as fuzzing, search-based approaches, and symbolic
execution
* Testing and analysis of non-functional properties
* GUI testing
* Mobile application testing
* Program analysis
* Program synthesis (e.g., constraint-based techniques)
* Program repair
* Debugging and fault localization
* Runtime analysis and/or error recovery

# SCOPE
-----------------------------------------------

Since the authors will choose an area for their submission, the scope of each area becomes important.
Some submissions may relate to multiple areas. In such cases, the authors should choose the area for
which their paper brings the maximum new insights. Moreover, authors also have the choice of
indicating an alternate area for each paper.

Similarly, for certain papers, authors may have a question whether it belongs to any area, or is simply out
of scope. For such cases, we recommend that the authors judge whether their paper brings new insights
for software engineering. As an example, a formal methods paper with a focus on hardware verification
may be deemed out of scope for ICSE. In general, papers that only peripherally concern software
engineering and do not give new insights from the software engineering perspective would be less
relevant to ICSE. Our goal, however, is to be descriptive rather than prescriptive, enabling authors to
make their own decisions about relevance.

# SINGLE SUBMISSION CYCLE
-----------------------------------------------

ICSE 2027 will have one submission cycle as follows:

* (Mandatory) Abstract: June 23, 2026
* Submission: June 30, 2026
* Author response period (3 days): September 23-25, 2026
* Notification: October 20, 2026
* Revision due: November 17, 2026
* Camera-ready (of directly accepted papers): November 24, 2026
* Final decision (of major revision papers): December 18, 2026
* Camera-ready (of accepted major revision papers): January 25, 2027

All dates are 23:59:59 AoE (UTC-12h).

# REVIEW CRITERIA
-----------------------------------------------

Each paper submitted to the Research Track will be evaluated based on the following criteria:

i) Novelty: The novelty and innovativeness of contributed solutions, problem formulations,
methodologies, theories, and/or evaluations, i.e., the extent to which the paper is sufficiently original
with respect to the state-of-the-art.

ii) Rigor: The soundness, clarity, and depth of a technical or theoretical contribution, and the level of
thoroughness and completeness of an evaluation.

iii) Relevance: The significance and/or potential impact of the research on the field of software
engineering.

iv) Verifiability and Transparency: The extent to which the paper includes sufficient information to
understand how an innovation works; to understand how data was obtained, analyzed, and interpreted;
and how the paper supports independent verification or replication of the paper's claimed contributions.
Any artifacts attached to or linked from the paper will be checked by one reviewer.

v) Presentation: The clarity of the exposition in the paper.

Reviewers will carefully consider all the above criteria during the review process, and authors should
take great care in clearly addressing them all. The paper should clearly explain and justify the claimed
contributions. Each paper will be handled by an area chair who will ensure reviewing consistency among
papers submitted within that area.

The outcome of each paper will be one of the following Accept, Major Revision, Reject. We now
elaborate on the Major Revision outcome in the following.

# MAJOR REVISIONS
-----------------------------------------------

Papers submitted can go through major revisions in response to specific revision requests made by the
reviewers. Authors of papers receiving a Major Revision decision are expected to submit the revised
papers, as well as the revised papers with changes marked in a different colour, such as using LaTeXdiff.
The authors also need to submit an "Author Response" document capturing the authors' response to
each reviewer's comment and how those comments were addressed in the revision. This is similar to the
"Summary of Changes and Response" document that is typically submitted by authors for a journal
paper's major revision. Authors may use the revision opportunity to revise and improve the paper, but
should not use this to submit a substantially different paper. The reviewers will check the revised paper
against the original paper and the suggested changes. The same set of reviewers will examine revised
papers. An unsatisfactory revised paper will be rejected. Authors are given approximately 4 weeks to
submit the revised papers. Authors are given an additional page of text in a revised paper to
accommodate the required changes specified in the reviews.

# SUBMISSION PROCESS
-----------------------------------------------

All submissions must conform to the IEEE conference proceedings template, specified in the IEEE
Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt type, LaTeX users
must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf
options). Note that IEEE format is being used this year, whereas last year it was ACM format.

All submissions must not exceed 10 pages for the main text, inclusive of all figures, tables, appendices,
etc. Two more pages containing only references are permitted. All submissions must be in PDF.
Accepted papers will be allowed one extra page for the main text of the camera-ready version.

* Submissions must strictly conform to the IEEE conference proceedings formatting instructions specified
above. Alterations of spacing, font size, and other changes that deviate from the instructions may result
in desk rejection without further review.
* By submitting to the ICSE Technical Track, authors acknowledge that they are aware of and agree to be
bound by the ACM Policy and Procedures on Plagiarism and the IEEE Plagiarism FAQ. In particular, papers
submitted to ICSE 2027 must not have been published elsewhere and must not be under review or
submitted for review elsewhere whilst under consideration for ICSE 2027.

Contravention of this concurrent submission policy will be deemed a serious breach of scientific ethics,
and appropriate action will be taken in all such cases. To check for double submission and plagiarism
issues, the chairs reserve the right to (1) share the list of submissions with the PC Chairs of other
conferences with overlapping review periods and (2) use external plagiarism detection software, under
contract to the ACM or IEEE, to detect violations of these policies.

* If the research involves human participants/subjects, the authors must adhere to the ACM Publications
Policy on Research Involving Human Participants and Subjects. Upon submitting, authors will declare
their compliance with such a policy. Alleged violations of this policy or any ACM Publications Policy will
be investigated by ACM and may result in a full retraction of your paper, in addition to other potential
penalties, as per ACM Publications Policy.
* Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing
process for your accepted paper. ACM and IEEE have been involved in ORCID and may collect ORCID IDs
from all published authors. We are committed to improve author discoverability, ensure proper
attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will
help in these efforts.
* The ICSE 2027 Research Track will employ a double-anonymous review process. Thus, no submission
may reveal its authors' identities. The authors must make every effort to honor the double-anonymous
review process. In particular:
* Authors' names must be omitted from the submission.
* All references to the author's prior work should be in the third person.
* While authors have the right to upload preprints on ArXiV or similar sites, they must avoid specifying
that the manuscript was submitted to ICSE 2027.
* To facilitate double-anonymous reviewing, we recommend authors to postpone publishing their
submitted work on arXiv or similar sites until after notification
* All communication with the program committee must go through the program committee chairs. Do
not contact individual program committee members regarding your submission.
* Further advice, guidance, and explanation about the double-anonymous review process can be found
on the Q&A page.
* By submitting to the ICSE Research Track, authors acknowledge that they conform to the authorship
policy of the IEEE, submission policy of the IEEE, and the authorship policy of the ACM (and associated
FAQ). This includes following these points related to the use of Generative AI:

** "Generative AI tools and technologies, such as ChatGPT, may not be listed as authors of an ACM
published Work. The use of generative AI tools and technologies to create content is permitted but must
be fully disclosed in the Work. For example, the authors could include the following statement in the
Acknowledgements section of the Work: 'ChatGPT was utilized to generate sections of this Work,
including text, tables, graphs, code, data, citations, etc.' If you are uncertain about the need to disclose
the use of a particular tool, err on the side of caution, and include a disclosure in the acknowledgements
section of the Work." - ACM

** "The use of artificial intelligence (AI)-generated text in an article shall be disclosed in the
acknowledgements section of any paper submitted to an IEEE Conference or Periodical. The sections of
the paper that use AI-generated text shall have a citation to the AI system used to generate the text." -
IEEE

** "If you are using generative AI software tools to edit and improve the quality of your existing text in
much the same way you would use a typing assistant like Grammarly to improve spelling, grammar,
punctuation, clarity, engagement or to use a basic word processing system to correct spelling or
grammar, it is not necessary to disclose such usage of these tools in your Work." - ACM

Submissions to the Technical Track that meet the above requirements can be made via the Research
Track submission site by the submission deadline. Any submission that does not comply with these
requirements may be desk rejected without further review.

Submission site:
https://icse2027.hotcrp.com/

We encourage the authors to upload their paper info early (and can submit the PDF later) to properly
enter conflicts for double-anonymous reviewing. It is the sole responsibility of the authors to ensure that
the formatting guidelines, double anonymous guidelines, and any other submission guidelines are met at
the time of paper submission.

IEEE Transactions on Software Engineering, ACM Transactions on Software Engineering and Methodology
and ICSE 2027, have received approval from the ICSE Steering Committee to launch and participate in
the Sustainable Community Review Effort (SCRE) program, aimed at reducing community effort in
reviewing journal extensions of conference papers and allowing authors to get faster and more
consistent feedback.

# OPEN SCIENCE POLICY
-----------------------------------------------

The research track of ICSE 2027 is governed by the ICSE 2027 Open Science policies. The guiding
principle is that all research results should be accessible to the public and, if possible, empirical studies
should be reproducible. In particular, we actively support the adoption of open artifacts and open source
principles. We encourage all contributing authors to disclose (anonymized and curated) data/artifacts to
increase reproducibility and replicability. Note that sharing research artifacts is not mandatory for
submission or acceptance. However, sharing is expected to be the default, and non-sharing needs to be
justified. We recognize that reproducibility or replicability is not a goal in qualitative research and that,
similar to industrial studies, qualitative studies often face challenges in sharing research data. For
guidelines on how to report qualitative research to ensure the assessment of the reliability and
credibility of research results, see this curated Q&A page -
https://conf.researchr.org/home/icse-2027/#QA

Upon submission to the research track, authors are asked

* to make their artifact available to the program committee (via upload of supplemental material or a
link to an anonymous repository) - and provide instructions on how to access this data in the paper; or
* to include in the submission an explanation as to why this is not possible or desirable; and
* to indicate in the submission why they do not intend to make their data or study materials publicly
available upon acceptance, if that is the case. The default understanding is that the data and/or other
artifacts will be publicly available upon acceptance of a paper.

# WITHDRAWING A PAPER
-----------------------------------------------
Authors can withdraw their paper at any moment until the final decision has been made, through the
paper submission system. Resubmitting the paper to another venue before the final decision has been
made without withdrawing from ICSE 2027 first is considered a violation of the concurrent submission
policy, and will lead to automatic rejection from ICSE 2027 as well as any other venue adhering to this
policy. Such violations may also be reported to appropriate organizations e.g. ACM and IEEE.

# CONFERENCE ATTENDANCE EXPECTATION
-----------------------------------------------

If a submission is accepted, at least one author of the paper is required to register for ICSE 2027 and
present the paper. We are assuming that the conference will be in-person, and if it is virtual or hybrid,
virtual presentations may be possible. These matters will be discussed with the authors closer to the
date of the conference.


Maria Angela Ferrario
Publicity Co-Chair, ICSE 2027
https://conf.researchr.org/home/icse-2027

School of Electronics, Electrical Engineering & Computer Science
Queen's University Belfast, UK
https://pure.qub.ac.uk/en/persons/maria-angela-ferrario

Data entirely hand-typed, one call for papers at a time. There is no scraper behind any of this: I read the announcement and type the dates in, in the gaps between other work, and with the hope it is useful to others. Organisers then move deadlines without telling anyone, calls get edited in place, and now and then the typing is simply wrong. Treat this as a well-meaning notebook rather than an authority, and check the conference’s own page before you submit anything you care about.