A Survey of Architecture Design Rationale

Many claims have been made about the problems caused by not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence available on what design rationale mean to practitioners, how valuable they consider them, and how they use and document design rationale during the design process. This paper reports an empirical study that surveyed practitioners to probe their perception of the value of design rationale and how they use and document background knowledge related to their design decisions. Based on eighty-one valid responses, this study has discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated barriers to the use and documentation of design rationale. Based on the findings, we conclude that much research is needed to develop methodology and tool support for design rationale capture and usage. Furthermore, we put forward some research questions that would benefit from further investigation into design rationale in order to support practice in industry

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

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Desain Perangkat Lunak : Konsep dan Tantangannya

Desain perangkat lunak merupakan tahapan pengembangan perangkat lunak yang hasilnya akan digunakan oleh pengembang perangkat lunak untuk membuat program. Dalam tulisan ini, disajikan berbagai konsep penting mengenai desain perangkat lunak, termasuk proses desain itu sendiri. Tulisan ini diakhiri dengan mengkaji berbagai tantangan dalam desain perangkat lunak, dalam hal bagaimana merancang perangkat lunak secara efektif dan perancangan perangkat lunak untuk embedded system. Dari kajian tersebut diharapkan memicu riset-riset dalam desain perangkat lunak

Reasoning and Reuse in Software Architecture Design: Practices in the Argentine Industry

Over the last years, software architecture design has gained significant importance in both, industrial and research areas due to its relevance in the software system development process. In this context, special attention has been given to the documentation of architects’ reasoning during an architectural design, highlighting the advantages and disadvantages of this activity. This work intends to present a view of architects’ practices in the Argentine industry regarding reasoning documentation and its subsequent use and access.Fil: Carignano, Maria Celeste. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Gonnet, Silvio Miguel. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Leone, Horacio Pascual. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); Argentin

Value-based design decision rationale documentation: Principles and empirical feasibility study

The explicit documentation of the rationale of design decisions is a practice generally encouraged, but rarely implemented in industry because of a variety of inhibitors. Methods proposed in the past for Design Decisions Rationale Documentation (DDRD) aimed to maximize benefits for the DDRD consumer by imposing on the producer of DDRD the burden to document all the potentially useful information. We propose here a compromise which consists in tailoring DDRD, based on its intended use or purpose. In our view, the adoption of a tailored DDRD, consisting only of the required set of information, would mitigate the effects of DDRD inhibitors. The aim of this paper is twofold: i) to discuss the application of Value-Based Software Engineering principles to DDRD, ii) to describe a controlled experiment to empirically analyze the feasibility of the proposed method. Results show that the level of utility related to the same category of DDRD information significantly changes depending on its purpose; such result is novel and it demonstrates the feasibility of the proposed value-based DDRD