Adriana Lopes

MoLVERIC: An Inspection Technique for MoLIC Diagrams

During interaction design, interaction models are developed to help design adequate user interaction with the system. MoLIC (Modeling Language for Interaction as Conversation) is a language used to represent an interaction model, which can then be used as a basis for building other artifacts, such as mockups. However, inspections are necessary to verify whether the MoLIC diagrams are complete, consistent, unambiguous, and contain few or no defects, to avoid propagating preventable defects to derived artifacts. In this paper, we present MoLVERIC, a technique for the inspection of MoLIC diagrams that uses cards with verification items and employs principles of gamification. Furthermore, we discuss the results of a pilot study conducted to analyze the feasibility of this technique.

An Empirical Study to Evaluate the Feasibility of a UX and Usability Inspection Technique for Mobile Applications.

Usability and UX (User eXperience) are some of the most important factors for evaluating the quality of mobile applications. They focus on how easy to use an application is and the emotions that such use evokes. However, these aspects are often evaluated separately in industry through different evaluation techniques. Although it is possible to identify more usability and UX problems by employing different UX and usability evaluation methods, this distributed approach may not be cost effective and may not allow to thoroughly explore the identified issues. In order to support the identification of both UX and usability problems in a single evaluation, we have proposed Userbility, an UX and usability inspection technique that allows evaluating these aspects in mobile applications. This paper presents an empirical study over the second version of Userbility to verify its feasibility. In this study, we compared Userbility with the UX and Usability Guidelines Approach (UUGA) that helps the evaluation of usability and UX separately in mobile applications. According to the quantitative results, considering efficiency, UUGA was better than the Userbility technique. However, the qualitative results suggest that Userbility pointed more improvement suggestions, which could be useful for redesigning the evaluated application. the emotions, perceptions and judgements of an application. Therefore, software development teams willing to increase the quality in use of the developed mobile applications need to evaluate both of them. To evaluate usability and UX together, in our previous work (13), we developed Userbility in order to support inspectors in the evaluation of both UX and usability in mobile applications at the same time, to assess whether Userbility can support inspectors in detecting usability and UX problems. Nascimento et al. (13) conducted a study with five mobile applications. The results showed that it is possible to identify improvements in applications, and allowed us to identify problems during the use of the technique. Based on this, in this paper, we proposed a new version of the technique and an empirical study to evaluate the feasibility of Userbility. We have compared the Userbility to an approach proposed by De Paula et al. (5), which evaluates UX and usability separately. The remainder of this paper is organized as follows. Section II presents a background on UX and usability evaluation techniques that can be applied to evaluate mobile applications. Then, Section III shows the Userbility technique in its second version. Section IV presents the empirical study where we compared Userbility with another evaluation approach. In Section V, we present the results of the empirical study. Finally, Section VI presents our conclusions and future work.

Collaborative identification of code smells: a multi-case study

Code smells are anomalous program structures that may indicate software maintainability problems. God Classes and Feature Envies are examples of code smells that frequently become the target of software refactoring. However, smell identification might be harder than expected due to the subjectivity involved in the recognition of the apparently simple structure of each smell. Moreover, smell identification might require the knowledge of multiple program elements, which are better understood by different developers. Thus, the use of collaboration among developers may have the potential to improve effectiveness on smell identification. However, current knowledge, especially empirically developed and evaluated in the industry, is quite scarce. This paper reports an industrial case study aimed at observing how 13 developers individually and collaboratively performed smell identification in five software projects from two software development organizations. Our results suggest that collaboration contributes to improving effectiveness on the identification of a wide range of code smells. We also analyzed the factors contributing to such effectiveness improvement.

How Do Software Developers Identify Design Problems?: A Qualitative Analysis

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 affects several elements in the program. Despite its harmfulness, it is difficult 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 different 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 identification of each design problem. Some strategies were frequently used to locate code elements for analysis, and other strategies were frequently used to confirm design problems in these elements. Developers unfamiliar with the systems relied only on the use of code smells along the task. Despite some differences among the subjects from both scenarios, we noticed that developers often search for multiple indicators during the identification of each design problem.

Applying user-centered techniques to analyze and design a mobile application

IntroductionTechniques 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 descriptionThis 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 evaluationFrom 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.ConclusionsThrough 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.

An Acceptance Empirical Assessment of Open Source Test Tools.

Software testing is one of the verification and validation activities of software development process. Test automation is relevant, since manual application of tests is laborious and more prone to error. The choice of test tools should be based on criteria and evidence of their usefulness and ease of use. This paper presents an acceptance empirical assessment of open source testing tools. Practitioners and graduate students evaluated five tools often used in the industry. The results describe how these tools are perceived in terms of ease of use and usefulness. These results can support software practitioners in the process of choosing testing tools for

Analyzing the Use Case Communicability

Software artifacts are products created during software development. Through them, designers communicate their intent and understanding of a system to other members of the development team. And the intent will, in the end, be communicated to end users through the systems interface. In this paper, we present a study about forms of expression for the informational content of use cases, and how they can affect mutual understanding among members of a software development team. We adopted the Semiotic Engineering perspective (in particular, the SigniFYIng Message tool) and the maxims of the Grices Cooperative Principle to structure and analyze data collected from 17 pairs of participants. The results show evidence of communication strategies that may impair the communication between designers and developers and, subsequently, the metacommunication of design intent to end users through the systems interface.