Linking Quality Attributes and Constraints with Architectural Decisions

Quality attributes and constraints are among the main drivers of architectural decision making. The quality attributes are improved or damaged by the architectural decisions, while restrictions directly include or exclude parts of the architecture (for example, the logical components or technologies). We can determine the impact of a decision of architecture in software quality, or which parts of the architecture are affected by a constraint, but the difficult problem is whether we are respecting the quality requirements (requirements on quality attributes) and constraints with all the architectural decisions made. Currently, the common practice is that architects use their own experience to design architectures that meet the quality requirements and restrictions, but at the end, especially for the crucial decisions, the architect has to deal with complex trade-offs between quality attributes and juggle possible incompatibilities raised by the constraints. In this paper we present Quark, a computer-aided method to support architects in software architecture decision making

An Empirical Study on Collaborative Architecture Decision Making in Software Teams

Architecture decision making is considered one of the most challenging cognitive tasks in software development. The objective of this study is to explore the state of the practice of architecture decision making in software teams, including the role of the architect and the associated challenges. An exploratory case study was conducted in a large software company in Europe and fifteen software architects were interviewed as the primary method of data collection. The results reveal that the majority of software teams make architecture decisions collaboratively. Especially, the consultative decision- making style is preferred as it helps to make decisions efficiently while taking the opinions of the team members into consideration. It is observed that most of the software architects maintain a close relationship with the software teams. Several organisational, process and human related challenges and their impact on architecture decision-making are also identified

On Making Architecturally Significant Decisions in Agile Development : Case Study

Päätöksenteko on tärkeä osa ohjelmistokehitystä erityisesti kun kyse on ohjelmistoarkkitehtuurista. Ohjelmistoarkkitehtuuri voidaan jopa ajatella joukkona arkkitehtuurisia päätöksiä. Päätöksenteko vaikuttaa siis hyvin paljon siihen millaiseksi ohjelmistoarkkitehtuuri muodostuu. Tämä tutkielma tutkii arkkitehtuurista päätöksentoa ohjelmistokehitysprojektiin liittyen. Tämä tutkielma esittää tapaustutkimuksen tulokset, joiden pääasiallisena lähteenä on ollut haastattelut. Tapaustutkimuksen tapaus on yksittäinen tapaus, joka tehtiin alihankitun ohjelmistokehitysprojektin aikana. Päätökseen liittyy ohjelmistokehitystiimi ja useita sidosryhmiä asiakkaan puolelta, mukaanlukien arkkitehtejä. Ohjelmistokehitystiimi reagoi nopeasti päätöksen tarpeellisuuteen kun tarve nousi esille projektin aikana. Suurin osa päätöksentekoon liittyvästä työstä tehtiin ketterän ohjelmistokehityksen lomassa sujuvasti. Vain lopullinen päätös asiakkaalta tapahtui erillään ohjelmistokehitysprosessista. Tämä viimeinen hyväksyntä annettiin vasta jälkeenpäin, kun päätös oli jo käytännössä päätetty ja implementoitu. Tämä kuvaa hyvin kuinka vaikeaa on yhdistää ohjelmistokehityksen ulkopuolista päätöksentekoa ohjelmistokehitysprosessiin tehokkaasti. Tämän tutkimuksen tapauksessa päätöksenteossa oli työnjako, jossa yksi henkilö tutki ja valmisteli päätöksen. Tämän henkilön työ muodosti suurimman osan tehdystä työstä päätökseen liittyen. Tämän tyyppinen työnjako voisi mahdollisesti olla yleistettävissä päätöksentekoon yleisesti ohjelmistokehityksen piirissä.Decision-making is an important part of all of software development. This is especially true in the context of software architecture. Software architecture can even be thought of as a set of architectural decisions. Decision-making therefore plays a large part in influencing the architecture of a system. This thesis studies architecturally significant decision-making in the context of a software development project. This thesis presents the results of a case study where the primary source of data was interviews. The case is a single decision made in the middle of a subcontracted project. It involves the development team and several stakeholders from the client, including architects. The decision was handled quickly by the development team when an acute need for a decision arose. The work relating to the decision-making was mostly done within the agile development process used by the development team. Only the final approval from the client was done outside the development process. This final approval was given after the decision was already decided in practise and an implementation based on it was built. This illustrates how difficult it is to incorporate outside decision-making into software development. The decision-making also had a division of labour where one person did the researching and preparing of the the decision. This constituted most of the work done relating to the decision. This type of division of labour may perhaps be generalized further into other decision-making elsewhere within software development generally

An Automated Negotiation-based Framework via Multi-Agent System for the Construction Domain

In this paper, we propose an automated multi-agent negotiation framework for decision making in the construction domain. It enables software agents to conduct negotiations and autonomously make decisions. The proposed framework consists of two types of components, internal and external. Internal components are integrated into the agent architecture while the external components are blended within the environment to facilitate the negotiation process. The internal components are negotiation algorithm, negotiation style, negotiation protocol, and solution generators. The external components are the negotiation base and the conflict resolution algorithm. We also discuss the decision making process flow in such system. There are three main processes in decision making for specific projects, which are propose solutions, negotiate solutions and handling conflict outcomes (conflict resolution). We finally present the proposed architecture that enables software agents to conduct automated negotiation in the construction domain

Closing the loop of design and analysis: Parametric modelling tools for early decision support

There is a growing need for parametric design software that communicates building performance feedback in early architectural exploration to support decision-making. This paper examines how the circuit of design and analysis process can be closed to provide active and concurrent feedback between architecture and services engineering domains. It presents the structure for an openly customisable design system that couples parametric modelling and energy analysis software to allow designers to assess the performance of early design iterations quickly. Finally, it discusses how user interactions with the system foster information exchanges that facilitate the sharing of design intelligence across disciplines