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

L'atenció a la diversitat, una responsabilitat compartida

Abstract not availabl

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

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

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

Minutiae filtering using ridge-valley method

In order to identify subjects in a convenient and efficient way one must use some special feature that makes it possible to discriminate between persons. Some of the features are biometric in nature, such as iris texture, hand shape, the human face, and of course finger prints. These play an important role in many automatic identification systems, since every person is believed to have a unique set of fingerprints. Before a fingerprint image can be looked up in a database, it has to be classified into one of 5 types in order to reduce processing times

Situaciones de presión en el Mediterráneo Occidental

Abstract not availabl

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