No abstract

No abstract

Introduction: Techniques that help in understanding and designing user needs are increasingly being used in Software Engineering to improve the acceptance of applications. Among these techniques we can cite personas, scenarios and interaction models. Personas are fictitious representations of target users. Scenarios provide various types of information at different levels of abstraction. Interaction models help in design of an adequate user interaction with the system. Case description: This paper presents a research that reports a set of practical activities applied by a software team using techniques in the analysis and design phases of a mobile application. In the analysis phase, we created personas and scenarios for the extraction of requirements. In the design phase, we created interaction models for describes the behavior between user and system during the interaction. We employed these interaction models to develop other artifacts, such as prototypes. In addition, we presented a technique developed by the analysis and design team for the inspection of interaction models. This technique reduced the spread of defects in the interaction models.Discussion and evaluation: From the results of this research, we suggest: (i) employing personas and scenarios to understand the requirements; (ii) employing interaction models to understand the behavior between user and system; and (iii) using interaction models as basis to develop other artifacts. Conclusions: Through the reporting of this set of practical activities, we hope to provide support for software engineers willing to adopt techniques that support the analysis and design of applications aiming at better quality of use for their users.

When a software design decision has a negative impact on one or more quality attributes, we call it a design problem. For example, the Fat Interface problem indicates that an interface exposes non-cohesive services. Thus, clients and implementations of this interface may have to handle with services that they are not interested. A design problem such as this hampers the extensibility and maintainability of a software system. As illustrated by the example, a single design problem often a ects several elements in the program. Despite its harmfulness, it is di cult to identify a design problem in a system. It is even more challenging to identify design problems when the source code is the only available artifact. In particular, no study has observed what strategy(ies) developers use in practice to identify design problems when the design documentation is unavailable. In order to address this gap, we conducted a qualitative analysis on how developers identify design problems in two di erent scenarios: when they are either familiar (Scenario 1) or unfamiliar (Scenario 2) with the analyzed systems. Developers familiar with the systems applied a diverse set of strategies during the identi cation of each design problem. Some strategies were frequently used to locate code elements for analysis, and other strategies were frequently used to con rm design problems in these elements. Developers unfamiliar with the systems relied only on the use of code smells along the task. Despite some di erences among the subjects from both scenarios, we noticed that developers often search for multiple indicators during the identi cation of each design problem. CCS CONCEPTS •Software and its engineering →Software design engineering;

No abstract

No abstract

No abstract

No abstract