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

Athos - The C# GUI Generator

This application comes to help software architects and developers during the long process between user's stories, designing the application's structure and actually coding it.Comment: 8 pages, exposed on 5th International Conference "Actualities and Perspectives on Hardware and Software" - APHS2009, Timisoara, Romani

Aircraft systems architecting: a functional-logical domain perspective

Presented is a novel framework for early systems architecture design. The framework defines data structures and algorithms that enable the systems architect to operate interactively and simultaneously in both the functional and logical domains. A prototype software tool, called AirCADia Architect, was implemented, which allowed the framework to be evaluated by practicing aircraft systems architects. The evaluation confirmed that, on the whole, the approach enables the architects to effectively express their creative ideas when synthesizing new architectures while still retaining control over the process

How Do Experienced Architects Use Architecture Development Methods?

Software architecture methods play a central role in the development of large enterprise computer systems. However, the extent to which individual experienced IT architects employ a software architecture method is largely unknown. In this paper, we surveyed a group of experienced architects, and set up an “in practice” field study of some of these architects to explore the way they applied a well documented software architecture development method. Among the findings to emerge are that architects modify their method more regularly than previously recognised, and that tools for visual communication are the most commonly used tools by these architects

DecidArch: Playing Cards as Software Architects

Teaching software architecture is a challenge because of the difficulty to expose students to actual meaningful design situations. Games can provide a useful illustration of the design decision making process, and teach students the power of team interaction for making sound decisions. We introduce a game –DecidArch– developed to achieve three learning objectives: 1) create awareness about the rationale involved in design decision making, 2) enable appreciation of the reasoning behind candidate design decisions proposed by others, and 3) create awareness about interdependencies between design decisions. The game has been played by 22 groups with a total of 83 players, all of them students of the VU software architecture course. We present some of the lessons learned, both from our observation and through participant survey. We conclude that the game well supports our three learning objectives, and we identify several improvement points for future game editions

DecidArch: Playing Cards as Software Architects

Teaching software architecture is a challenge because of the difficulty to expose students to actual meaningful design situations. Games can provide a useful illustration of the design decision making process, and teach students the power of team interaction for making sound decisions. We introduce a game –DecidArch– developed to achieve three learning objectives: _x0001_1) create awareness about the rationale involved in design decision making, _x0002_2) enable appreciation of the reasoning behind candidate design decisions proposed by others, and _x0003_3) create awareness about interdependencies between design decisions. The game has been played by _x0002__x0002_ groups with a total of _x0008__x0003_ players, all of them students of the VU software architecture course. We present some of the lessons learned, both from our observation and through participant survey. We conclude that the game well supports our three learning objectives, and we identify several improvement points for future game editions

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 initial performance review of software components for a heterogeneous computing platform

The design of embedded systems is a complex activity that involves a lot of decisions. With high performance demands of present day usage scenarios and software, they often involve energy hungry state-of-the-art computing units. While focusing on power consumption of computing units, the physical properties of software are often ignored. Recently, there has been a growing interest to quantify and model the physical footprint of software (e.g. consumed power, generated heat, execution time, etc.), and a component based approach facilitates methods for describing such properties. Based on these, software architects can make energy-efficient software design solutions. This paper presents power consumption and execution time profiling of a component software that can be allocated on heterogeneous computing units (CPU, GPU, FPGA) of a tracked robot

Data-Driven Selection of Security Application Frameworks During Architectural Design

The selection of application frameworks is an important aspect of architectural design. Selection often requires satisficing, that is, searching a potentially large space of design alternatives until an acceptable solution is found. There is, however, little help for architects in selecting software frameworks. In this paper we investigate the criteria used by practicing software architects in selecting security frameworks. We also propose how information associated with some of the criteria that are important to architects can be obtained manually or in an automated way from online sources such as GitHub. Our ultimate goal is to identify measures associated with these criteria that can be helpful in providing support for architects to select software frameworks