Rafael Maiani de Mello

Would Sociable Software Engineers Observe Better

Quantitative studies in Software Engineering are frequently dependent on primary studies in which population is usually small and established by convenience. It brings several limitations for the analysis and strength of results due sampling issues. Therefore, when these studies are reapplied, different and non-clustered populations are established, making unfeasible evidence generalization and contributing for an imbalance between research and practice. Aiming at investigating ways to overcome the absence of large sampling frames in Software Engineering studies, this short paper presents the results of an initial experience concerned with the systematic recruitment of subjects for a survey regarding software requirements effort factors by using social networks compared with recruitment by convenience. We have observed in this particular case that using social networks technology does not guarantee sample enlargement by just posting invitations in specific forums. However, its usage can contribute to increase the subjects heterogeneity and to increase the level of confidence of the sample, which consequently improve our capacity of observing the object under study, with the probable strengthen of results.

Activity Diagram Inspection on Requirements Specification

The requirements specification of contemporary software applications usually is composed by diverse artifacts describing lots of activities, flows, dependencies among the flows, branches and business rules. For instance, web or scientific workflow (e-science) based applications require structural representations for the various activities and functionalities involved in their execution, usually described trough activity diagrams. The quality assurance of such specifications represents a challenge for software engineers. The results of a quasi-systematic review indicated there is a lack of software technologies to support the inspection of this type of requirements specification. Therefore, in this paper, besides the review results, an inspection technique (checklist) to review Activity Diagrams on the requirements specifications is introduced. A proof of concept on applying the checklist for the inspection of a real requirements specification concerned with a scientific workflow based application indicated some advantages on its defect detection capacity when compared with previously executed ad-hoc inspection by software engineers.

Lessons learnt in conducting survey research

Context: Surveys constitute an valuable tool to capture a large-scale snapshot of the state of the practice. Apparently trivial to adopt, surveys hide, however, several pitfalls that might hinder rendering the result valid and, thus, useful. Goal: We aim at providing an overview of main pitfalls in software engineering surveys and report on practical ways to deal with them. Method: We build on the experiences we collected in conducting many studies and distill the main lessons learnt. Results: The eight lessons learnt we report cover different aspects of the survey process ranging from the design of initial research objectives to the design of a questionnaire. Conclusions: Our hope is that by sharing our lessons learnt, combined with a disciplined application of the general survey theory, we contribute to improving the quality of the research results achievable by employing software engineering surveys.

Checklist-Based Inspection Technique for Feature Models Review

Software Product Line Engineering aims to ensure the correctness, completeness and consistency among its artifacts and the specified domain, in order to prevent the spread of defects for the products derived from this domain. Among initial artifacts of a software product line, feature models are artifacts generated in various domain engineering approaches. Although software inspection is highlighted as an effective review activity for detection of defects in software artifacts, mainly in the early models of software projects, a recent quasi-systematic review of literature indicated a lack of techniques to support the inspection of software product line artifacts, which include features models. Thus, this paper presents FMCheck, a checklist-based inspection technique to support the detection of defects on feature models. This technique was developed to be configurable and to be applied on several extensions of the original feature model notation presented by FODA approach, including the Odyssey-FEX notation, in particular. FMCheck was submitted to a proof of concept and to a further in vitro feasibility study, in which it could be seen the feasibility of FMCheck application and also that inspections applying FMCheck are more effective than ad-hoc inspections, when applied on four distinct domains.

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.

Investigating Samples Representativeness for an Online Experiment in Java Code Search

Context: The results of large-scale studies in software engineering can be significantly impacted by samples representativeness. Diverse population sources can be used to support sampling for such studies. Goal: To compare two samples, one from the crowdsourcing platform Mechanical Turk and another from the professional social network LinkedIn, in an online experiment for evaluating the relevance of Java code snippets to programming tasks. Method: To compare the samples (subjects experience, programming habits) and experimental results concerned with three experimental trials. Results: LinkedIns subjects present significantly higher levels of experience in Java programming and programming in general than Mechanical Turks subjects. The experimental results revealed a significant difference between samples and suggested that LinkedIns subjects were more pessimistic than Mechanical Turks subjects despite a high level consistency in the experimental results. Conclusion: The combined use of sources of sampling can bring benefits to large scale studies in software engineering, especially when heterogeneity is desired in the population. Thus, it can be useful to investigate and characterize alternative sources of sampling for performing large-scale studies in software engineering.

Identifying design problems in the source code: a grounded theory

The prevalence of design problems may cause re-engineering or even discontinuation of the system. Due to missing, informal or outdated design documentation, developers often have to rely on the source code to identify design problems. Therefore, developers have to analyze different symptoms that manifest in several code elements, which may quickly turn into a complex task. Although researchers have been investigating techniques to help developers in identifying design problems, there is little knowledge on how developers actually proceed to identify design problems. In order to tackle this problem, we conducted a multi-trial industrial experiment with professionals from 5 software companies to build a grounded theory. The resulting theory offers explanations on how developers identify design problems in practice. For instance, it reveals the characteristics of symptoms that developers consider helpful. Moreover, developers often combine different types of symptoms to identify a single design problem. This knowledge serves as a basis to further understand the phenomena and advance towards more effective identification techniques.

Towards effective teams for the identification of code smells

Code smells are symptoms of poor design and implementation choices. Several techniques for the automated detection of code smells have been proposed, but their effectiveness is limited due to the inherent subjectivity of the task. Accepting false warnings generated by a tool may lead to unnecessary maintenance effort. Moreover, bypassing undetected smells may contribute to the software degradation. Thus, developers need to perform a subsequent manual identification of code smells to confirm their occurrences as well as address both false and missing warnings. However, performing ad hoc manual identification of smells does not assure more effective results. Indeed, different context factors may influence on the conclusion about the incidence of a code smell. Based on evidence collected from previous work, this paper presents and discusses a set of context factors that may influence the effectiveness of smell identification tasks. These factors are addressed to human aspects, such as the interaction among individuals and their professional roles. Based on such factors, we present an initial set of practical suggestions for composing more effective teams to the identification of code smells.

Structuring and Verifying Requirement Specifications through Activity Diagrams to Support the Semi-automated Generation of Functional Test Procedures

The higher the quality of the specification document, the lower the effort of its translation into design models and testing plans. Besides, an adequate level of abstraction to promote such translations must be described. Therefore, to ensure the quality of requirements specifications it is strategic to develop high quality software applications. So, in this paper a model-based approach to support the correctness, structuring, and translation of functional requirements specifications is described. This approach consists of facilities to build and inspect requirements specifications based on activity diagrams (capturing use cases), and derive functional tests from them. A tool to model and check the activity diagram, a checklist-based inspection technique and a test procedure generation tool form it. This approach was assessed in experimental studies that indicated its feasibility in specification time and a significant reduction of defects in the specified use cases when compared to ad-hoc approaches.