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

Assisting software architects in architectural decision-making using Quark

Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool.Peer ReviewedPostprint (published version

Usage of architectural styles and technologies in IT companies and organizations

As in many other software engineering activities, Non-Functional Requirements (NFR) are fundamental in the process of selection of the architectural style and the technologies for developing a software system. To know more about this issue, we are currently driving a survey to find out which architectural styles and technologies are being in use in IT companies and organizations, and their relation to types of NFR. We want to apply this knowledge to Model-Driven Software Development (MDSD), and in fact we are currently developing a framework that considers NFR in the MDSD process.Peer ReviewedPostprint (author’s final draft

Relacions entre matemàtiques i tecnologia en 3er i 4rt de l'ESO

Context: Aquest TFM gira entorn dues matèries d'àmbits diferents. D'una banda tecnologia de l'àmbit cientificotecnològic i per l'altre matemàtiques de l'àmbit de les matemàtiques. El fet que aquestes matèries, tot i que clarament tenen lligams, estiguin en àmbits diferents pot haver ocasionat que els currículums d'ambdues no estiguin ben sincronitzats. És a dir, que els coneixements de cadascuna no s'imparteixen en el moment adequat perquè es puguin reutilitzar. Objectiu: L'objectiu principal d'aquest TFM és trobar punts de sinergia entre les dues matèries que donin possibilitat de crear activitats de forma conjunta. Metodologia: La metodologia utilitzada es basa en l'anàlisi documental i en l'aplicació dels coneixements obtinguts al màster per tal de dissenyar o adaptar les activitats proposades. Resultat: En aquest TFM es proposen activitats per dur a terme de forma conjunta en aquestes matèries. Conclusió: Aquest TFM ha deixat constància que es poden realitzar activitats per a impartir de manera conjunta matemàtiques i tecnologia ja que el currículum actual permet trobar certes sinergies entre ambdues matèries. No obstant això, cal dir que aquesta simbiosi és més adequada en 3er que en 4rt d'ESO a causa de l'optativitat de tecnologia en 4rt i l'escassa connexió entre els continguts

iStarJSON : a lightweight data-format for i* models

JSON is one of the most widely used data-interchange format. There is a large number of tools open for modelling with i*. However, none of them provides supporting for JSON. In this paper we propose iStarJSON language, a JSON-based proposal for interchanging i* models. We also, present an open source software that transforms XML-based format models to JSON models that expose a set of web services for mining iStarJSON models.Peer ReviewedPostprint (author's final draft

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

Proceedings of the First Workshop on Requirements Prioritisation and Enactment, PrioRE’17 : In conjunction with REFSQ 2017 : Preface

It is our pleasure to welcome the reader to the proceedings of the First International Workshop on Requirements Prioritization and Enactment, PrioRE’17 co-located with the 23rd International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ 20167) held in Essen, Germany. First in its series, the PrioRE’17 aims to play a role in bringing research experts and practitioners together, and provide them with a platform to exchange their visions on requirements prioritization, release planning and their enactment. The main focus will be on how requirements can be best prioritized, and how the releases are planned and enactedPostprint (published version

Dealing with non-functional requirements in model-driven development

The impact of non-functional requirements (NFRs) over software systems has been widely documented. Consequently, cost-effective software production method shall provide means to integrate this type of requirements into the development process. In this vision paper we analyze this assumption over a particular type of software production paradigm: model-driven development (MDD). We report first the current state of MDD approaches with respect to NFRs and remark that, in general, NFRs are not addressed in MDD methods and processes, and we discuss the effects of this situation. Next, we outline a general framework that integrates NFRs into the core of the MDD process and provide a detailed comparison among all the MDD approaches considered. Last, we identify some research issues related to this framework.Preprin

Towards guidelines for building a business case and gathering evidence of software reference architectures in industry

Background: Software reference architectures are becoming widely adopted by organizations that need to support the design and maintenance of software applications of a shared domain. For organizations that plan to adopt this architecture-centric approach, it becomes fundamental to know the return on investment and to understand how software reference architectures are designed, maintained, and used. Unfortunately, there is little evidence-based support to help organizations with these challenges. Methods: We have conducted action research in an industry-academia collaboration between the GESSI research group and everis, a multinational IT consulting firm based in Spain. Results: The results from such collaboration are being packaged in order to create guidelines that could be used in similar contexts as the one of everis. The main result of this paper is the construction of empirically-grounded guidelines that support organizations to decide on the adoption of software reference architectures and to gather evidence to improve RA-related practices. Conclusions: The created guidelines could be used by other organizations outside of our industry-academia collaboration. With this goal in mind, we describe the guidelines in detail for their use.Peer ReviewedPostprint (published version