Edson Cesar Cunha de Oliveira

Checklist-based Inspection of SMarty Variability Models

Software inspection is a particular type of software review applied to all life-cycle artifacts and follows a rigorous and well-defined defect detection process. Existing literature defines several inspection techniques for different domains. However, they are not for inspecting product-line UML variability models. This paper proposes SMartyCheck, a checklist-based software inspection technique for product-line use case and class variability models according to the SMarty approach. In addition, it presents and discusses the empirical feasibility of SMartyCheck based on the feedback from several experts. It provides evidence of the SMartyCheck feasibility, as well as to improve it, forming a body of knowledge for planning prospective empirical studies and automation of SMartyCheck.

Variability Identification and Representation in Software Product Line UML Sequence Diagrams: Proposal and Empirical Study

Variability management is an essential activity to ensure which products can be instantiated from the core assets of Software Product lines (SPLs). Stereotype-based Management of Variability (SMarty) is one of the several approaches to manage variabilities specified in UML diagrams. SMarty, in its fourth version, supports variability management specification in use case, class, activity and components diagrams. However, it lacked the representation of dynamic aspects of a SPL. The inclusion of UML interaction diagrams in the core assets allows the representation of an important abstraction level. Therefore, this paper presents a proposal for extending SMarty to manage variabilities in UML sequence diagrams. In addition, it presents an experimental validation that provides evidences of the effectiveness of this extension which supports its use both in academic and industrial environment.

Knowledge management and organizational culture in a software organization: a case study

Software development activities are usually knowledge intensive. Knowledge management is essential to foster improvements and innovation on software development processes. Organizational Culture (OC) is a key factor that impacts the success of knowledge management, since it influences the way employees learn and share knowledge in the organization. The Competing Values Framework (CVF) was proposed to support the definition of organizations cultural outline. CVF aims to diagnose and facilitate Organizational Culture changes. Previous researches presented a theoretical model to correlate knowledge management to the CVF. However, the existing literature does not present evidences of this correlation. The goal of this work is to identify whether this correlation exists or not in the context of a software organization by means of a case study. We performed a comparison between the values obtained and those presented in the theoretical model. The comparison output enabled us to verify that the case study results diverged from the theoretical ones. Therefore, it was not possible to observe the theoretical models propositions on the investigated software development organization.

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.

Towards Initial Evidence of SMartyCheck for Defect Detection on Product-Line Use Case and Class Diagrams

Software Product Line (SPL) is a promising approach for specific domain software artifacts reuse. In order to ensure SPL quality it is essential to perform activities for verification and validation. In this scenario, one applies software revision to the quality control process in order to ensure the quality of a software engineering process in each stage. Amongst software revision techniques, there is the checklist-based reading technique. This technique allows the detection of several defect types, whereas improves the quality of the software products. This paper presents the empirical evaluation of an SPL inspection technique based on checklist, named SMartyCheck. The main objective of SMartyCheck is to inspect Unified Modeling Language (UML) use case and class SPL diagrams based on the Stereotype-based Management of Variability (SMarty) approach. For evaluating SMartyCheck it was adopted the sequential exploratory strategy based on mixed-methods, aiming at analyzing the SMartyCheck feasibility throughout qualitative, then quantitative studies. The results obtained with such empirical studies allowed providing initial evidence improving SMartyCheck corroborating the relevance of the technique quality in the academic environment. Therefore, we provide an initial body of knowledge for planning prospective studies in industrial sets, as well as the automation of SMartyCheck.

How have Software Engineering Researchers been Measuring Software Productivity? - A Systematic Mapping Study.

Context: productivity has been a recurring topic, and despite its importance, researchers have not yet reached a consensus on how to properly measure productivity in software engineering. Aim: to investigate and better understand how software productivity researchers are using software productivity metrics. Method: we performed a systematic mapping study on publications regarding software productivity, extracting how software engineering researchers are measuring software productivity. Results: In total, 91 software productivity metrics were extracted. The obtained results show that researchers apply these productivity metrics mainly focusing on software projects and developers, and these productivity metrics are predominantly composed by Lines of Code (LOC), Time and Effort measures. Conclusion: although there is no consensus, our results shows that single ratio metrics, such as LOC/Effort, for software projects, and LOC/Time, for software developers, are a tendency adopted by researchers to measure productivity.

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

An Empirical Study about the Influence of Project Manager Personality in Software Project Effort

Project effort is a main concern on software organizations. The project budget is derived from project effort which in turn is based on the software engineersâ?? effort cost. Project manager is responsible for planning and controlling this effort estimation. Some researches relate how project manager can influence the project success, specially when considering project manager personality. This research aims to evaluate the influence between project manager personality and teamwork behavior over projectâ??s effort deviation. A case study was performed with 65 real projects collected from a software company dedicated to develop software projects for its local government. Unlike previous researches our results show no statistically significant influence of project manager personality, assesed by MBTI test, over projectâ??s effort deviation. However, our results show the project manager teamwork behavior, assesed by Belbinâ??s BTRSPI, has a statistically significant influence on the projectâ??s effort deviation.

SyMPLES-CVL: A SysML and CVL Based Approach for Product-Line Development of Embedded Systems

Background: A Software Product Line (SPL) is a group of systems that share a common set of features satisfying the specific needs of a market segment. These systems are systematicaly developed from a common set of core assets. Objective: This paper proposes SyMPLES-CVL, an alternative approach to the management of variability based on SysML models to support the development of SPLs for embedded systems. In addition, we present a comparative study between our previous approach, SyMPLES-SMarty, and SyMPLES-CVL. Method: SyMPLES-CVL was specified based on SyMPLES-SMarty, then an experimental study was carry to compare the approaches. A total of 20 participants with Software Engineering background were divided into two groups, one for each approach. The data were collected with the support of questionnaires which was analysed based on test hypotheses using inferential statistics. Results: SyMPLES-CVL was not considered significantly more effective than SyMPLES-SMarty at an significance level of 0.05 for T-Test test. Limitations: Generalization of results is limited due to the sample size of this study. Conclusion: The results showed that the approaches compared did not have a significant difference in terms of effectiveness, although they use different means (annotative and compositional) for the management of variability in SPLs. Paper Category: Experimental and Technological.