The need is becoming evident for a software engineering research community that focuses on the development and maintenance of Evolving Critical Systems (ECS). This community must concentrate its efforts on the techniques, methodologies and tools needed to design, implement, and maintain critical software systems that evolve successfully (without risk of failure or loss of quality).

In recent years a number of factors have changed in the software engineering landscape to highlight the importance of Evolving Critical Systems (ECS). There are new difficulties and new attitudes that may have been specific to particular industries and software engineering sub-fields but are now widespread across the discipline. We have identified the following five “game changers”:

• Universality of Software: This means that software failures are more likely to affect ordinary people.
• Pervasiveness of Software: As software embeds itself into the fabric of society failures affect more of society. This increases the criticality of even very simple software.
• Increased Interactions with People: As software is deployed to control systems in which human actors participate, the issue of people in the loop becomes more important. As it is more common for software and (non-technical) humans to interact the implications for modelling the system and for criticality have become more common.
• (iv) Increasing Complexity: Software itself is more complex and much real-world software is becoming entangled and dependent on software developed by third-party operators.
• Increased Tempo of Evolution: The tempo of software evolution is increasing as users become accustomed to demanding more from software.

We believe that the software engineering community needs to concentrate efforts on the techniques, methodologies and tools needed to design, implement, and maintain critical software systems that evolve successfully (without risk of failure or loss of quality. The Perspectives Workshop on Evolving Critical Systems held in Schloss Dagstuhl in December 2009 brought key software engineering researchers and practitioners (19 participants from 8 countries) who are in positions to influence their organisation's research direction together to discuss ECS. Similar issues and questions must be addressed within ECS as in other (non-ECS) software engineering research, but with the added (and conflicting) requirements of predictability/quality and the ability to change.

The fundamental research question underlying ECS research is: How do we design, implement, and maintain critical software systems that are highly reliable, and that retain this reliability as they evolve without incurring prohibitive costs. We discussed an incomplete list of demands that must be met before the ideals of ECS can be fully realised, including:

• Architectural models: We must determine the characteristics that make a successful architectural model and/or technique for ECS.
• Changing Development Environment: We must be able to maintain the quality of critical software in spite of constant change in its teams, processes, methods and toolkits. We must improve our existing software design methodologies so that they facilitate the support and maintenance of ECS, e.g., how can we use agile development methodologies to evolve critical software?
• Capturing Requirements: We must be able to specify what we want to achieve during an evolution cycle and to be able to confirm that we achieved what we intended, and only what we intended; in other words, we must be able to capture and elucidate the requirements for change in such a manner that allows that change to take place correctly.
• Effort Estimation: We must develop techniques for better estimating specific evolution activities a priori and only attempt software change when we are certain that evolution will be successful and that the benefit outweighs the cost. Too many software change activities run over time and budget and ultimately many are abandoned.
• Model Based Evolution: We must develop strategies to make model-driven, automatic evolution a viable alternative to manual change. In cases where it is not appropriate to mechanise change we must develop heuristics for determining when such an approach is viable. Where it is necessary for humans to perform the change we must develop support tools that make this a less risky enterprise.
• Traceability: We must develop new tools for traceability that keep the various software artefacts (e.g., documentation and source code) in sync throughout the evolution cycle. Where regulatory compliance is required, these tools must ensure that evolution results in compliant software.
• Evolving in Runtime: During runtime evolution we must ensure that run time policies must be adhered to. We must develop techniques that can monitor and model changing requirements in dynamic environments (especially autonomic and adaptive software). We must develop strategies for evolution that are tolerant of uncertainty in the operational environment, where the environment changes in a deterministic, non-deterministic, or stochastic manner? We must ensure that software never evolves into a state where it exhibits unstable behaviour.

One of the outcomes of the workshop was a special issue of IEEE Computer Magazine on Evolving Critical Systems in May 2010.