Applications are invited for PhD candidates at the Software Composition Group, University of Bern, Switzerland.
The Software Composition Group carries out research in software engineering and programming languages, with a view to enabling software evolution. The SCG is led by Prof. Oscar Nierstrasz and is part of the Institute of Computer Science at the University of Bern.
Applicants will contribute to the ongoing SNSF project, “Agile Software Analysis”, and towards the planned successor project:
http://scg.unibe.ch/research/snf16
The candidate must have a MSc in Computer Science (equivalent to a Swiss MSc), should demonstrate strong programming skills, and have research interests in several of the following areas:
- software evolution
- program understanding
- dynamic analysis
- static analysis
- software modeling
- model-driven engineering
- secure software engineering
- programming language design
- domain specific languages
- virtual machine technology
Female candidates are especially welcome to apply. To apply, please send an email including your research statement and your CV, with at least two references, to Prof. Oscar Nierstrasz (oscar(a)inf.unibe.ch), by June 1, 2017.
Kind regards,
Oscar Nierstrasz
---
Prof. Dr. O. Nierstrasz -- oscar(a)inf.unibe.ch
Software Composition Group -- http://scg.unibe.ch
University of Bern -- Tel +41 31 631 4618
========================================================================
10th Seminar Series on Advanced Techniques & Tools for Software Evolution (SATToSE 2017)
June 7 - June 9, 2017, Madrid, Spain
Find us on the web: http://sattose.org/2017 <http://sattose.org/2017>
Follow us on twitter: https://twitter.com/sattose <https://twitter.com/sattose>
========================================================================
SATToSE is the Seminar Series on Advanced Techniques & Tools for Software Evolution. The goal of SATToSE is to gather both undergraduate and graduate students to showcase their research, exchange ideas, and improve their communication skills.
SATToSE will host invited talks, paper presentations, tutorials, and a hackathon, fostering interactions among participants and stimulating lively debates and discussions around the topics of interest of the event. We expect attendees to be active participants and not just passive listeners. Presenters should be open to and encourage questions and discussions during their talks.
This year's SATToSE has a co-located event on the day before: the SENECA European (http://senecaproject.github.io <http://senecaproject.github.io/>) project training for PhDs. It is a one-day seminar on "writing up & moving on" and "commercializing research", that will have five renowned speakers. Those who register for SATToSE will have the possibility to attend this event for free.
### Important Dates
14th April, 2017 - Submission deadline
4th May, 2017 - Notification of acceptance
9th May, 2017 - Registration deadline
6th June, 2017 - SENECA European project training for PhDs
7th - 9th June, 2017 - SATToSE Seminar
### Topics of Interest
Contributions are solicited on all aspects of software and model evolution, practices, and technologies. In particular, we encourage submissions about the following (non-exhaustive) list of topics:
* Supporting tools, processes, and models for managing software evolution
* Industrial needs, case studies and experiences
* Software analytics and visualisation techniques to support software evolution
* Empirical studies in evolution and maintenance
* Program transformation, refactoring, renovation, and migration
* Program and/or data reverse engineering
* Evolution of data-intensive or process-intensive systems
* Approaches of model-driven software evolution
* Software evolution for emerging paradigms
* Coupled evolution of meta-models, models, and transformations
* Classification of evolution scenarios
* Reliability and security aspects of software evolution
* Negative research results in software evolution
* Software ecosystem evolution
* Formalisms, notations, theories, methods, and languages for expressing software evolution
* Conformance checking, inconsistency management, synchronisation, differencing, comparison, versioning, impact analysis of evolving models
### Types of Submission
We solicit extended abstracts of 2–5 pages, in one of the following forms:
* Work in Progress: Early ideas and achievements that you want to share with the community and get feedback on.
* Publication Summaries: Overview of research results already published or ready to be submitted to a conference or a journal.
* Technology Showdown Demonstrations: Technical explanation of important features of your framework, library or tool.
Contributions are managed through EasyChair. Please submit your paper using the following link:
https://www.easychair.org/conferences/?conf=sattose2017 <https://www.easychair.org/conferences/?conf=sattose2017>
### Presentation and Publication
All submissions will be reviewed and screened for scope and compatibility by the program committee, which will provide feedback for improving the abstract and preparing the talk. All contributions accepted for presentation will receive 10–30 minutes during the event for presentation and discussion. Submitters will also be offered the opportunity to receive feedback and guidance to improve their submission towards a formally published paper, in a SATToSE post-proceedings issue of an open access journal.
### Program Committee
* General chair:
Gregorio Robles, Universidad Rey Juan Carlos, Spain.
* Program co-chairs:
Haidar Osman, University of Bern, Switzerland.
Andrei Chis, Feenk, Switzerland.
* Hackathon chair
Felienne Hermans, Delft University of Technology, The Netherlands.
### Program Committee
Haidar Osman (co-chair), University of Bern, Switzerland
Andrei Chis (co-chair), Feenk , Switzerland
Alexandre Bergel, University of Chile, Chile.
Andrea Caracciolo, Software Improvement Group (SIG), The Netherlands.
Tommaso Dal Sasso, University of Lugano, Switzerland.
Coen De Roover, Vrije Universiteit Brussel, Belgium.
Serge Demeyer, University of Antwerpen, Belgium.
Davide Di Ruscio, University of L'Aquila, Italy.
Anne Etien, University of Lille 1, France
Mohammad Ghafari, University of Bern, Switzerland.
Anya Helene Bagge, University of Bergen, Norway.
André Hora, Federal University of Minas Gerais, Brazil.
Mircea Lungu, University of Groningen, The Netherlands.
Kim Mens, Université catholique de Louvain, Belgium.
Nevena Milojković, University of Bern, Switzerland.
Luca Ponzanelli, University of Lugano, Switzerland.
Sebastiano Panichella, University of Zurich, Switzerland.
Alexander Serebrenik, Eindhoven University of Technology, The Netherlands.
Michael W. Godfrey, University of Waterloo, Canada.
Vadim Zaytsev, Raincode, Belgium
[Apologies for duplicate reception of this CFP]
IEEE Software Special Issue on Release Engineering 3.0
https://www.computer.org/software-magazine/2016/12/14/release-engineering-3… <https://www.computer.org/software-magazine/2016/12/14/release-engineering-3…>
Submission deadline: 1 August 2017
Publication: Mar./Apr. 2018
Whereas software used to be released in shrink-wrapped form, the advent of the Web and agile methodologies has totally changed the landscape. For example, lean startups such as IMVU continuously deliver their software up to 50 times per day, and companies such as Intuit, Google, and Mozilla take only a couple of hours or days between releases. Even Mozilla Firefox releases every six weeks, generating updates for dozens of versions on a variety of platforms for more than 80 locales. In other words, releasing modern applications requires coordinating their release on multiple mobile platforms, Web platforms with centralized backend services, and native desktop clients.
Software release engineering is the discipline of integration, build, test execution, deployment, and delivery of high-quality software releases to users. In particular, independently developed software components must be integrated such that all of them form a coherent whole. The integrated components (a mixture of textual source code and binary libraries) must be transformed into a working set of executables (a build system). The executables must be tested, deployed into the production environment (cloud, app store, download site, and so on), and eventually released to the user’s device of choice. These activities form the vital link between a software product’s design and development and the finished product’s use and maintenance. However, they require specialized skills and automation that all too often are classified as outside the scope of software engineering research.
Large software companies such as Google, Facebook, and Netflix have been pioneering release-engineering technologies and practices, and that journey has been risky and costly. Even at this point, these companies aren’t sure about the long-term viability or deficiencies of practices such as continuous delivery or canary deployment, especially in today’s migration toward hundreds of interdependent yet autonomously updated microservices. All of this makes it difficult for small companies, startups, civic organizations, government administrations, and safety-critical industries (healthcare, automotive systems, and so on) to select and adopt a release-engineering process and tool chain that fits their needs. An out-of-the-box release-engineering process and tool chain is far from a reality, as are textbooks or experience reports with empirically validated best practices for release engineering.
So, this IEEE Software theme issue focuses on Release Engineering 3.0. Release Engineering 1.0 and 2.0 refer, respectively, to the traditional ad hoc and today’s highly automated release-engineering processes for general-purpose software systems. Release Engineering 3.0 targets the future iteration of release-engineering processes aimed at supporting small companies, startups, civic organizations, government administrations, and safety-critical industries. For example, the software in cars, hospital equipment, or election software needs updates to deliver critical bug fixes and new functionality. However, without proper precautions, innocent people’s lives could be at stake.
We seek experience reports and articles on tools, methods, practices, and techniques to streamline Release Engineering 3.0. Topics include, but aren’t limited to,
best practices for code movement (branching or integration);
continuous integration and testing;
build and configuration of software;
build system maintenance;
testing and reporting infrastructures;
infrastructure as code;
package and dependency management;
legal sign-off and bill of materials;
software deployment and delivery;
code signing and certificate management;
continuous delivery, deployment, installation, and updates;
feature toggles or flags;
cloud provisioning and management;
interaction with mobile-app stores;
principles and automated techniques for release planning;
release engineering for product-line systems;
DevOps and interaction with developers, users, and so on;
multiplatform release engineering;
release engineering for safety-critical systems (healthcare, automotive, and so on);
experience reports on adoption of modern release-engineering techniques; and
pipeline security or testing.
Several guest editors are release engineers, and one-third of the reviewers will be release engineers. So, we guarantee that each submission will receive at least one review from a practitioner.
Besides seeking regular-length articles (see the section “Submission Guidelines), we also seek short experience reports (2,500 to 3,000 words) from practitioners. These reports don’t need to make a research contribution but should instead present the experiences of a practitioner or practitioners by describing things such as the current release processes used, challenges faced, solutions attempted, and results obtained.
Submission Guidelines
Manuscripts must not exceed 3,000 words including figures and tables, which count for 250 words each. Submissions exceeding these limits might be rejected without refereeing. Articles deemed within the theme and scope will be peer reviewed and are subject to editing for magazine style, clarity, organization, and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the theme issue for which you’re submitting.
Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments aren’t appropriate. Articles should be novel. IEEE Software doesn’t republish material published previously in other venues, including other periodicals and formal conference or workshop proceedings, whether previous publication was in print or electronic form. For more information, contact the guest editors at software2a-2018(a)computer.org <mailto:software2a-2018@computer.org>.
Theme Issue Guest Editors
Bram Adams, Polytechnique Montreal
Stephany Bellomo, SEI
Christian Bird, Microsoft Research
Boris Debíc, Google
Foutse Khomh, Polytechnique Montreal
Shane McIntosh, McGill University
Kim Moir, Mozilla
John O’Duinn, US Digital Service
For general author guidelines: www.computer.org/software/author.htm <http://www.computer.org/software/author.htm>
For submission details: software(a)computer.org <mailto:software@computer.org>To submit an article: https://mc.manuscriptcentral.com/sw-cs <https://mc.manuscriptcentral.com/sw-cs>
