Architecturally-sensitive usability scenarios are important usability concerns that require early consideration in software design so that architectural support can render them easy and cost-effective to implement. Examples include providing the ability to cancel a command, undo commands, aggregate data, etc. This chapter reports on our experiences applying these scenarios to the design of MERBoard, a wall-sized interactive system developed by NASA to assist Mars Rover science teams with collaborative data analysis. We applied the scenarios during a major redesign of the software architecture that introduced usability as a valued quality attribute. In the process, we found that the scenarios were well-received by developers who readily understood how they related to MERBoard, that they applied to a collaborative workspace despite having been initially developed for a single-user desktop system, that they had a real impact on the architecture redesign, and that the scenario consideration process was quick and not too onerous for any of the team members.

Abstract. The development of video games is a complex software engineering activity bringing together large multidisciplinary teams under stringent constraints. While much has been written about how to develop video games, there has been as yet little attempt to view video game development from a quality perspective, attempting to enumerate the quality attributes that must be satisfied by game implementations, and to relate implementation techniques to those quality attributes. In this paper, we discuss desired quality attributes of 3D computer games, and we use the development of our own Life is a Village game to illustrate architectural tactics that help achieve these desired qualities. 1

Management of architecture knowledge is vital for improving an organization’s architectural capabilities. Despite the recognition of the importance of capturing and reusing architecture knowledge, there is no suitable support mechanism. We propose a conceptual framework for providing appropriate guidance and tool support for making tacit or informally described architecture knowledge explicit. This framework identifies different approaches to capturing implicit architecture knowledge. We discuss different usages of the captured knowledge to improve the effectiveness of architecting process. The report also presents a brief description of a prototype of a web-based architecture knowledge management tool to support the storage and retrieval of the captured knowledge. The report concludes with open issues that we plan to address in order to successfully transfer this support mechanism for capturing and using architecture knowledge to the industry. 1.

A controlled experiment was performed to assess the usefulness of portions of a Usability-Supporting Architectural Pattern (USAP) in modifying the design of software architectures to support a specific usability concern. Results showed that participants using a complete USAP produced modified designs of significantly higher quality than participants using only a usability scenario. Comparison of solution quality ratings with a quantitative measure of responsibilities considered in the solution showed positive correlation between the measures. Implications for software development are that usability concerns can be included at architecture design time, and that USAPs can significantly help software architects to produce better designs to address usability concerns. Implications for empirical software engineering are that validated quantitative measures of software architecture quality may potentially be substituted for costly and often elusive expert assessment. 1.

Current usability evaluation methods are essentially holistic in nature. However, engineers that apply a component-based software engineering approach might also be interested in understanding the usability of individual parts of an interactive system. This paper examines the efficiency dimension of usability by describing a method, which engineers can use to test, empirically and objectively, the physical interaction effort to operate components in a single device. The method looks at low-level events, such as button clicks, and attributes the physical effort associated with these interaction events to individual components in the system. This forms the basis for engineers to prioritise their improvement effort. The paper discusses face validity, content validity, criterion validity, and construct validity of the method. The discussion is set within the context of four usability tests, in which 40 users participated to evaluate the efficiency of four different versions of a mobile phone. The results of the study show that the method can provide a valid estimation of the physical interaction event effort users made when interacting with a specific part of a device.

Usability supporting architectural patterns (USAPs) have been shown to provide developers with useful guidance for producing a software architecture design that supports usability in a laboratory setting [7]. In close collaboration between researchers and software developers in the real world, the concepts were proven useful [2]. However, this process does not scale to industrial development efforts. In particular, development teams need to be able to use USAPs while being distributed world-wide. USAPs also must support legacy or already partially-designed architectures, and when using multiple USAPs there could be a potentially overwhelming amount of information given to the software architects. In this paper, we describe the restructuring of USAPs using a pattern language to simplify the development and use of multiple USAPs. We also describe a delivery mechanism that is suitable for industrial-scale adoption of USAPs. The delivery mechanism involves organizing responsibilities into a hierarchy, utilizing a checklist to ensure responsibilities have been considered, and grouping responsibilities in a fashion that both supports use of multiple USAPs simultaneously and also points out reuse possibilities to the architect.

Abstract. Challenges in designing effective groupware include technical issues associated with concurrent and distributed work and social issues associated with supporting group activities. To address some of these problems, we have developed a quality-centered architectural design framework that links requirements analysis to architectural design decisions for groupware systems. The framework supports reasoned architectural design choices that are used to tailor software architecture to the unique quality and functional requirements of the software being developed. The framework has been applied to the development of the Software Design Board, a tool for collaborative software engineering. 1

Software architecture (SA) of a product family constrains the achievement of various quality attributes (such as reusability, performance, security, maintainability and usability) [1]. A number of methods, such as Architecture Tradeoff Analysis Method (ATAM) [2], Quality Attribute-oriented Software Architecture design method (QASAR) [3] and Quality-driven Architecture Design and Analysis (QADA) [4], have been developed to pay significant attention to quality related issues at the software architecture level. These approaches heavily depend on architectural styles and patterns to design candidate architectures and on scenarios and associated reasoning frameworks to evaluate software architecture for desired quality attributes. A quality attribute is a non-functional requirement of a system, e.g., reliability, modifiability and so forth. Scenarios are widely used in product line software engineering: abstract scenarios to capture behavioural requirements and quality-sensitive scenarios to specify architecturally significant quality attributes. Patterns 1 embody proven solutions to recurring problems by capturing concentrated wisdom of many experienced practitioners. Patterns are a vital means of designing software architecture of large complex systems. One of the major objectives of using patterns is to develop a software system with predictable nonfunctional properties [1]. Each pattern helps achieve one or more quality attribute and may hinder others. In product line development, an architect designs a desirable software architecture by composing a number of architectural styles and patterns. Scenarios are used to characterize quality goals and patterns are used to achieve those goals. Moreover, scenarios are used to reason about the design decisions during software architecture design stage and to evaluate that software architecture with respect to target quality requirements. Recently, there have been attempts to codify the links that exist among scenarios, quality attributes, and patterns [5, 6]. However, there has been little research on systematically studying, identifying, and documenting the synergistic relationships that informally exist in each pattern’s description. There are different formats of describing patterns. However, each type of format uses

c ○ 2009 Brandon Salmonii · Putting Home Data Management into PerspectiveFor Mary. I love you.

conclusions, or recommendations expressed in this material are those of the author and should not be interpreted as representing the official opinions, either expressed or implied, of the funding agencies or the U.S. Government. Keywords In spite of the goodwill and best efforts of software engineers and usability professionals, systems continue to be built and released with glaring usability flaws that are costly and difficult to fix after the system has been built. Although user interface (UI) designers, be they usability or design experts, communicate usability requirements to software development teams, seemingly obvious usability features often fail to be implemented as expected. The impact of usability issues becomes increasingly severe in all kinds of software as computer use continues to rise in the home, in the workplace, and in education. If, as seems likely, software developers intend to build what UI designers specify and simply do not know how to interpret the ramifications that usability requirements have for the deep structure of the software (i.e. the “software architecture”), something is needed to help to bridge the gap between UI designers and software