Unbiased and objective architectural design decisions are crucial for the success of a software development project. Stakeholder inputs play an important role in arriving at such design decisions. However, the stakeholders may act in a biased manner in order to ensure that their requirements and concerns are addressed in a specific way in the software. Most of the existing methods of architectural decision-making do not adequately account for such biased behaviour of stakeholders. We view the software architecture design as a collective decision making (CDM) problem in social choice theory, and introduce the central ideas of mechanism design to our field. Our contributions are twofold: i) Using the impossibility results from social choice theory, we show that a rational stakeholder can game, to her advantage, almost every known method of software architecture decision making. ii) We also show that if the architect is willing to bear the extra cost of giving suitable incentives to stakeholders, then architectural decision making can be protected from strategic (biased) manipulations. For achieving this objective, we introduce the Vickrey-Clarke-Groves (VCG) mechanism from social choice theory to the software architecture domain. We illustrate our contributions by comparing and using the examples drawn from the well-known CBAM method of architectural decision making.
Software architecture has many definitions. One widely accepted definition of software architecture is that it is a composition of a set of architectural design decisions. Hence, designing a software architecture is a decision-making process. Agile methods drastically changed the way of designing a software architecture. In projects using agile methods (e.g. Scrum), making architectural design decisions is not the responsibility of a single person, but rather the whole development team. Despite the popularity of such methods in the industry, little research exists on how to make these decisions from the perspective of a group effectively. Current techniques usually focus on the identification of quality attributes and design alternatives, not addressing the whole decision-making process. The quality of decisions directly reflects the quality of the software architecture. Therefore poor decisions lead to bad software architectures. In this paper, we discuss current research on group decision-making in software architecture and the proposal of a combination of concepts from two architecture definition methods into a single approach that can be used in agile projects and addresses the most critical concerns of group decision-making. This proposal is part of a master's research project.  Uncertainty and conflicting stakeholders' objectives make many requirements and architecture decisions particularly hard. Quantitative probabilistic models allow software architects to analyse such decisions using stochastic simulation and multi-objective optimisation, but the difficulty of elaborating the models is an obstacle to the wider adoption of such techniques. To reduce this obstacle, this paper presents a novel modelling language and analysis tool, called RADAR, intended to facilitate requirements and architecture decision analysis. The language has relations to quantitative AND OR goal models used in requirements engineering and to feature models used in software product lines. However, it simplifies such models to a minimum set of language constructs essential for decision analysis. The paper presents RADAR's modelling language, automated support for decision analysis, and evaluates its application to four real-world examples.  Uncertainty complicates early requirements and architecture decisions and may expose a software project to significant risk. Yet software architects lack support for evaluating uncertainty, its impact on risk, and the value of reducing uncertainty before making critical decisions. We propose to apply decision analysis and multi-objective optimisation techniques to provide such support. We present a systematic method allowing software architects to describe uncertainty about the impact of alternatives on stakeholders' goals; to calculate the consequences of uncertainty through Monte-Carlo simulation; to shortlist candidate architectures based on expected costs, benefits and risks; and to assess the value of obtaining additional information before deciding. We demonstrate our method on the design of a system for coordinating emergency response teams. Our approach highlights the need for requirements engineering and software cost estimation methods to disclose uncertainty instead of hiding it. During the development of a software system, architects deal with a large number of stakeholders, each with differing concerns. This inevitably leads to inconsistency: goals, concerns, design decisions, and models are interrelated and overlapping. Existing approaches to support inconsistency management are limited in their applicability and usefulness in day to day practice due to the presence of incomplete, informal and heterogeneous models in software architecture. This paper presents a novel process in the form of a lightweight generic method, the Concern-Driven Inconsistency Management (CDIM) method, that is designed to address limitations of different related approaches. It aims to aid architects with management of intangible inconsistency in software architecture.