The paper is an extension of one top three paper of ESEM conference 2018 and includes:•A theory that explains how 15 companies achieved successful DevOps adoption.•A model based on the theory, using ...GQM definition and transcriptions of interviews.•A case study of the application of the model, with data collected through a focus group.
DevOps is a set of practices and cultural values that aims to reduce the barriers between development and operations teams. Due to its increasing interest and imprecise definitions, existing research works have tried to characterize DevOps.
Nevertheless, little is known about the practitioners’ understandingabout successful paths for DevOps adoption. Therefore, our goal is to detail real scenarios of DevOps adoption, presenting a theory, a model, and a case study.
We used classic Grounded Theory to build a theory about 15 scenarios of successful DevOps adoption in companies from different domains and countries. We proposed a model (i.e., a workflow for DevOps adoption) and evaluated it through a case study at a Brazilian Government institution. We used a focus group to collect the company perceptions about DevOps adoption.
This paper increments the existing view of DevOps by detailing real scenarios and explaining the role of each category during DevOps adoption. We provide evidence that collaboration is the core DevOps concern, contrasting with an existing wisdom that automation and tooling can be enough to achieve DevOps.
Altogether, our results contribute to: generating an adequate understanding of DevOps, from the practitioners’ perspective; and assisting other institutions in the path towards DevOps adoption.
Static code analysis tools such as FindBugs and SonarQube are widely used on open-source and industrial projects to detect a variety of issues that may negatively affect the quality of software. ...Despite these tools’ popularity and high level of automation, several empirical studies report that developers normally fix only a small fraction (typically, less than 10% (Marcilio et al., 2019) of the reported issues—so-called “warnings”. If these analysis tools could also automatically provide suggestions on how to fix the issues that trigger some of the warnings, their feedback would become more actionable and more directly useful to developers.
In this work, we investigate whether it is feasible to automatically generate fix suggestions for common warnings issued by static code analysis tools, and to what extent developers are willing to accept such suggestions into the codebases they are maintaining. To this end, we implemented SpongeBugs, a Java program transformation technique that fixes 11 distinct rules checked by two well-known static code analysis tools (SonarQube and SpotBugs). Fix suggestions are generated automatically based on templates, which are instantiated in a way that removes the source of the warnings; templates for some rules are even capable of producing multi-line patches. Based on the suggestions provided by SpongeBugs, we submitted 38 pull requests, including 946 fixes generated automatically by our technique for various open-source Java projects, including Eclipse UI – a core component of the Eclipse IDE – and both SonarQube and SpotBugs. Project maintainers accepted 87% of our fix suggestions (97% of them without any modifications). We further evaluated the applicability of our technique on software written by students and on a curated collection of bugs. All results indicate that our approach to generating fix suggestions is feasible, flexible, and can help increase the applicability of static code analysis tools.
•We present SpongeBugs: a technique to fix violations of static code analysis rules.•SpongeBugs supports 11 widely-used rules checked by SonarQube and SpotBugs.•SpongeBugs is completely automatic, precise, and scalable.•SpongeBugs generated hundreds of fixes accepted in 12 open-source projects.
Misuse of cryptographic (crypto) APIs is a noteworthy cause of security vulnerabilities. For this reason, static analyzers were recently proposed for detecting crypto API misuses. They differ in ...strengths and weaknesses, and they might miss bugs. Motivated by the inherent limitations of static analyzers, this paper reports on a study of runtime verification (RV) as a dynamic-analysis-based alternative for crypto API misuse detection. RV monitors program runs against formal specifications; it was shown to be effective and efficient for amplifying the bug-finding ability of software tests. We focus on the popular JCA crypto API and write 22 RV specifications based on expert-validated rules in a static analyzer. We monitor these specifications while running tests in five benchmarks. Lastly, we compare the accuracy of our RV-based approach, RVSec, with those of three state-of-the-art crypto API misuses detectors: CogniCrypt, CryptoGuard, and CryLogger. Results show that RVSec has higher accuracy in four benchmarks and is on par with CryptoGuard in the fifth. Overall, RVSec achieves an average F 1 measure of 95%, compared with 83%, 78%, and 86% for CogniCrypt, CryptoGuard, and CryLogger, respectively. We highlight the strengths and limitations of these tools and show that RV is effective for detecting crypto API misuses. We also discuss how static and dynamic analysis can complement each other for detecting crypto API misuses.
•A refactoring recommendation tool using fine-grained co-change dependencies is proposed.•The approach outperforms a state-of-the-art approach based on quality metrics.•The approach’s refactorings ...complement the ones from other tools.•The refactorings from the approach are feasible and may spot further design problems.•Refactoring tools that challenge the software design may face strong resistance.
A fine-grained co-change dependency arises when two fine-grained source-code entities, e.g., a method, change frequently together. This kind of dependency is relevant when considering remodularization efforts (e.g., to keep methods that change together in the same class). However, existing approaches for recommending refactorings that change software decomposition (such as a move method) do not explore the use of fine-grained co-change dependencies. In this paper we present a novel approach for recommending move method and move field refactorings, which removes co-change dependencies and evolutionary smells, a particular type of dependency that arise when fine-grained entities that belong to different classes frequently change together. First we evaluate our approach using 49 open-source Java projects, finding 610 evolutionary smells. Our approach automatically computes 56 refactoring recommendations that remove these evolutionary smells, without introducing new static dependencies. We also evaluate our approach by submitting pull-requests with the recommendations of our technique, in the context of one large and two medium size proprietary Java systems. Quantitative results show that our approach outperforms existing approaches for recommending refactorings when dealing with co-change dependencies. Qualitative results show that our approach is promising, not only for recommending refactorings but also to reveal opportunities of design improvements.
The popularization of the Android platform and the growing number of Android applications (apps) that manage sensitive data turned the Android ecosystem into an attractive target for malicious ...software. For this reason, researchers and practitioners have investigated new approaches to address Android’s security issues, including techniques that leverage dynamic analysis to mine Android sandboxes. The mining sandbox approach consists in running dynamic analysis tools on a benign version of an Android app. This exploratory phase records all calls to sensitive APIs. Later, we can use this information to (a) prevent calls to other sensitive APIs (those not recorded in the exploratory phase) or (b) run the dynamic analysis tools again in a different version of the app. During this second execution of the fuzzing tools, a warning of possible malicious behavior is raised whenever the new version of the app calls a sensitive API not recorded in the exploratory phase.
The use of a mining sandbox approach is an effective technique for Android malware analysis, as previous research works revealed. Particularly, existing reports present an accuracy of almost 70% in the identification of malicious behavior using dynamic analysis tools to mine android sandboxes. However, although the use of dynamic analysis for mining Android sandboxes has been investigated before, little is known about the potential benefits of combining static analysis with a mining sandbox approach for identifying malicious behavior. Accordingly, in this paper we present the results of two studies that investigate the impact of using static analysis to complement the performance of existing dynamic analysis tools tailored for mining Android sandboxes, in the task of identifying malicious behavior.
In the first study we conduct a non-exact replication of a previous study (hereafter BLL-Study) that compares the performance of test case generation tools for mining Android sandboxes. Differently from the original work, here we isolate the effect of an independent static analysis component (DroidFax) they used to instrument the Android apps in their experiments. This decision was motivated by the fact that DroidFax could have influenced the efficacy of the dynamic analyses tools positively—through the execution of specific static analysis algorithms DroidFax also implements. In our second study, we carried out a new experiment to investigate the efficacy of taint analysis algorithms to complement the mining sandbox approach previously used to identify malicious behavior. To this end, we executed the FlowDroid tool to mine the source–sink flows from benign/malign pairs of Android apps used in a previous research work.
Our study brings several findings. For instance, the first study reveals that DroidFax alone (static analysis) can detect 43.75% of the malwares in the BLL-Study dataset, contributing substantially in the performance of the dynamic analysis tools in the BLL-Study. The results of the second study show that taint analysis is also practical to complement the mining sandboxes approach, with a performance similar to that reached by dynamic analysis tools.
Evolving software is particularly challenging when the code has been poorly written or uses confusing idioms and language constructs, which might increase maintenance efforts and impose a significant ...cognitive load on developers. Previous research has investigated possible sources of confusion in programs, including the impact of small code patterns (hereafter atoms of confusion) that contribute to misunderstanding the source code. Although researchers have explored atoms of confusion in code written in C, C++, and Java, different languages have different features, developer communities, and development cultures. This justifies the exploration of other languages to verify whether they also exhibit confusion-inducing patterns. In this paper we investigate the impact of atoms of confusion on understanding JavaScript code—a dynamically typed language whose popularity is growing in the most diverse application domains. We present the results of a mixed-methods research comprising a mining software repositories (MSR) study, two experiments, and a set of interviews with practitioners. Our MSR effort shows that atom candidates are frequent and used intensively in 72 popular open-source JavaScript projects: four atom candidates appear in 90% of them and two of them occur more than once for every 100 lines of code. This helps motivate the other three studies. The results of both experiments suggest that two code patterns that have been previously observed to confuse C programmers also confuse JavaScript programmers: the comma operator and assignments being used as values. In addition, some code patterns, such as omitted curly braces and change of literal encoding, have caused confusion in participants in one of the experiments. We discover that some JavaScript-specific elements, such as automatic semicolon insertion and object destructuring, also have the potential to cause confusion. For all these cases effect sizes were either medium or high. The interviews we conducted indicate other constructs and idioms that merit investigation in the future.
•Our study investigates the impact and prevalence of atoms of confusion in JavaScript.•Some atoms proved to confuse C programmers also confuse JavaScript programmers.•JavaScript-specific atom candidates also have the potential to confuse developers.•Examined code patterns are frequent and used intensively in JavaScript projects.
During the software development process and throughout the software lifecycle, organizations must guarantee users’ privacy by protecting personal data. There are several studies in the literature ...proposing methodologies, techniques, and tools for privacy requirements elicitation. These studies report that practitioners must use systematic approaches to specify these requirements during initial software development activities to avoid users’ data privacy breaches. The main goal of this study is to identify which methodologies, techniques, and tools are used in privacy requirements elicitation in the literature. We have also investigated Information Technology (IT) practitioners’ perceptions regarding the methodologies, techniques, and tools identified in the literature. We have carried out a systematic literature review (SLR) to identify the methodologies, techniques, and tools used for privacy requirements elicitation. Besides, we have surveyed IT practitioners to understand their perception of using these techniques and tools in the software development process. We have found several methodologies, techniques, and tools proposed in the literature to carry out privacy requirements elicitation. Out of 78 studies cataloged within the SLR, most of them did not verify their methodologies and techniques in a practical case study or illustrative contexts (38 studies), and less than 35% of them (26 studies) experimented with their propositions within an industry context. The Privacy Safeguard method (PriS) is the best known among the 198 practitioners in the industry who participated in the survey. Moreover, use cases and user story are their most-used techniques. This qualitative and quantitative study shows a perception of IT practitioners different from those presented in other research papers and suggests that methodologies, techniques, and tools play an important role in IT practitioners’ perceptions about privacy requirements elicitation.
Modularity benefits, including the independent maintenance and comprehension of individual modules, have been widely advocated. However, empirical assessments to investigate those benefits have ...mostly focused on source code, and thus, the relevance of modularity to earlier artifacts is still not so clear (such as requirements and design models). In this paper, we use a multimethod technique, including designed experiments, to empirically evaluate the benefits of modularity in the context of two approaches for specifying product line use case scenarios: PLUSS and MSVCM. The first uses an annotative approach for specifying variability, whereas the second relies on aspect-oriented constructs for separating common and variant scenario specifications. After evaluating these approaches through the specifications of several systems, we find out that MSVCM reduces feature scattering and improves scenario cohesion. These results suggest that evolving a product line specification using MSVCM requires only localized changes. On the other hand, the results of six experiments reveal that MSVCM requires more time to derive the product line specifications and, contrasting with the modularity results, reduces the time to evolve a product line specification only when the subjects have been well trained and are used to the task of evolving product line specifications.
Background: The Java programming language version eight introduced several features that encourage the functional style of programming, including the support for lambda expressions and the Stream ...API. Currently, there is common wisdom that refactoring legacy code to introduce lambda expressions, besides other potential benefits, simplifies the code and improves program comprehension. Aims: The purpose of this work is to investigate this belief, conducting an in-depth study to evaluate the effect of introducing lambda expressions on program comprehension. Method: We conduct this research using a mixed-method study. For the quantitative method, we quantitatively analyze 166 pairs of code snippets extracted directly either from GitHub or from recommendations from three tools (RJTL, NetBeans, and IntelliJ). We also surveyed practitioners to collect their perceptions about the benefits on program comprehension when introducing lambda expressions. We asked practitioners to evaluate and rate sets of pairs of code snippets. Results: We found contradictory results in our research. Based on the quantitative assessment, we could not find evidence that the introduction of lambda expressions improves software readability—one of the components of program comprehension. Our results suggest that the transformations recommended by the aforementioned tools decrease program comprehension when assessed by two state-of-the-art models to estimate readability. Differently, our findings of the qualitative assessment suggest that the introduction of lambda expression improves program comprehension in three scenarios: when we convert anonymous inner classes to a lambda expression, structural loops with inner conditional to a anyMatch operator, and structural loops to filter operator combined with a collect method. Implications: We argue in this paper that one can improve program comprehension when she applies particular transformations to introduce lambda expressions (e.g., replacing anonymous inner classes with lambda expressions). Also, the opinion of the participants shines the opportunities in which a transformation for introducing lambda might be advantageous. This might support the implementation of effective tools for automatic program transformations.
The emission produced by sulfite induced autoxidation of Ni(II)/tetraglycine complex in the presence of luminol can be used to determine sulfite in the range of (0.0500–5.00)×10
−6
mol
l
−1. The ...limit of detection is 2.8×10
−8
mol
l
−1 and the relative standard deviation is 4.6% for 1×10
−7
mol
l
−1 sulfite in five repeated measurements. This method has been successfully used for the determination of sulfite in wine, juices, white sugar and rainwater. The sulfite was extracted from the sample by using one gas-diffusion unit. Results for various samples of wine and juices were compared with those obtained by using a recommended procedure (correlation coefficient=0.9998,
n=10), and recovery range for white sugar was between 99 and 104%. The mechanism involves a chain reaction with Ni(II) and radicals formations, which can then oxidize luminol.
PDF
