Managing designtime uncertainty Any software system is the accumulated result of many design decisions taken by its developers. During the course of development, however, developers are often uncertain about how to make these decisions. This uncertainty reflects lack of knowledge about the design of the system, rather than about the environment in which the system is intended to operate. It is therefore called designtime uncertainty, and is different from environmental uncertainty 1. Addressing environmental uncertainty requires using strategies such as selfadaptation 2, which result in fully functional software systems, capable of operating under uncertain conditions, i.e., uncertaintyaware software. In contrast, designtime uncertainty (henceforth, also simply uncertainty) cannot be coded away. Rather, it must be tackled as part of the process of software development, i.e., using uncertaintyaware software development methodologies.   Existing methodologies, languages and tools assume that their inputs do not contain any uncertainty. Thus, uncertainty is rendered an undesirable characteristic that developers should either avoid or remove altogether before resuming their work. This results in either costly delays or potentially premature  and therefore risky  resolutions of uncertainty as developers make provisional decisions and attempt to keep track of them in case they need to be undone. We present an alternative strategy: the explicit management of design time uncertainty as part of the course of software development 3.   Specifically, we build on previously published work for encoding alternative design decisions in partial models which can subsequently be used for tasks such as reasoning, refinement and transformation 4. These techniques had been implemented as partial model operators in MuMmint, an interactive modelling tool 5. We combine these point solutions into a coherent, toolsupported methodology for tackling designtime uncertainty. This combination allows deferring the resolution of uncertainty for as long as necessary while the development work can continue.   To create a coherent methodology, we must address some fundamental questions, such as: What does it mean to tackle uncertainty? How does it get added to software artifacts? When does it get removed? To gain a more detailed understanding of how uncertainty is manifested and manipulated at different stages, as well as the different inputs, outputs, pre and postconditions of partial model operators, we developed the DesignTime Uncertainty Management (DeTUM) model, shown in Fig. 1. The DeTUM model consists of three stages: During the Articulation stage, uncertainty increases as developers encode alternative designs in partial models. During the Deferral stage, the goal is to avoid making premature decisions, while still being able to make use of software engineering techniques. To do that, developers use partial models as primary development artifacts in combination with techniques that are appropriately lifted so that they are applicable to partial models. During this stage the degree of uncertainty in the model remains unchanged. During the Resolution stage, the degree of uncertainty in the partial model is reduced to reflect newly acquired information. The ultimate result is a model without any uncertainty. The DeTUM model allows us to to contextualize the various partial modelling operators and identify gaps through lessons learned from nontrivial scenarios.   This work makes the following contributions: (a) the DeTUM model; (b) the mapping of various partial model operators to the DeTUM model; (c) based on the above, a methodology for managing designtime uncertainty, and (d) a validation of the usability and effectiveness of the methodology based on two nontrivial uncertainty management scenarios.

What should your runtime configuration framework do to help developers? The users or deployment engineers of a software system can adapt such a system to a wide range of deployment and usage scenarios by changing the value of configuration options, for example by disabling unnecessary features, tweaking performancerelated parameters or specifying GUI preferences. However, the literature agrees that the flexibility of such options comes at a price: misconfigured options can lead a software system to crash in the production environment, while even in the absence of such configuration errors, a large number of configuration options makes a software system more complicated to deploy and use. In earlier work, we also found that developers who intend to make their application configurable face 22 challenges that impact their configuration engineering activities, ranging from technical to managementrelated or even inherent to the domain of configuration engineering. In this paper, we use a prototyping approach to derive and empirically evaluate requirements for tool support able to deal with 13 (primarily technical) configuration engineering challenges. In particular, via a set of interviews with domain experts, we identify four requirements by soliciting feedback on an incrementally evolving prototype. The resulting xe2x80x9cConfig2Codexe2x80x9d prototype, which implements the four requirements, is then empirically evaluated via a user study involving 55 participants that comprises 10 typical configuration engineering tasks, ranging from the creation, comprehension, refactoring, and reviewing of configuration options to the quality assurance of options and debugging of configuration failures. A configuration framework satisfying the four requirements enables developers to perform more accurately and more swiftly in 70% and 60% (respectively) of the configuration engineering tasks than a stateofthepractice framework not satisfying the requirements. Furthermore, such a framework allows to reduce the time taken for these tasks by up to 94.62%, being slower for only one task.