No abstract

Ruptures and interruptions in supply chains (SC) can cause large financial losses and undermine the reputation of firms. In this respect, there is growing interest among researchers in the theme of supply chain risk management (SCRM). SCRM involves analysis carried out in various steps. However, researchers diverge over the number and content of these steps. In light of this problem, the aim of the present study was to analyze whether it is possible to apply the ISO 31000 standard as a systematic procedure for SCRM. And, if so, how the standard can be implemented in the SCRM context, as a framework in a specific company. Through a systematic literature review, we compared and harmonized the risk management steps proposed by researches about SCRM. Additionally we developed a pathway to identify and prioritize which ISO 31000:2009 risk assessment tools and techniques are supposed to integrate a procedure for SCRM, based on the Analytic Hierarchy Process (AHP), exemplified in an automotive supply chain. Based on the research findings, we infer that ISO 31000 can be used beneficially as a standardized method to perform SCRM, as long as tools and techniques are selected according to the company needs and business characteristics.

The work to be performed on open source systems, whether feature developments or defects, is typically described as an issue (or bug). Developers self-select bugs from the many open bugs in a repository when they wish to perform work on the system. This paper evaluates a recommender, called NextBug, that considers the textual similarity of bug descriptions to predict bugs that require handling of similar code fragments. First, we evaluate this recommender using 69 projects in the Mozilla ecosystem. We show that for detecting similar bugs, a technique that considers just the bug components and short descriptions perform just as well as a more complex technique that considers other features. Second, we report a field study where we monitored the bugs fixed for Mozilla during a week. We sent mails to the developers who fixed these bugs, asking whether they would consider working on the recommendations provided by NextBug; 39 developers (59%) stated that they would consider working on these recommendations; 44 developers (67%) also expressed interest in seeing the recommendations in their bug tracking system.

Solidity is a language used for smart contracts on the Ethereum blockchain. Smart contracts are embedded procedures stored with the data they act upon. Debugging smart contracts is a really difficult task since once deployed, the code cannot be reexecuted and inspecting a simple attribute is not easily possible because data is encoded. In this paper, we address the lack of inspectability of a deployed contract by analyzing contract state using decompilation techniques driven by the contract structure definition. Our solution, SmartInspect, also uses a mirror-based architecture to represent locally object responsible for the interpretation of the contract state. SmartInspect allows contract developers to better visualize and understand the contract stored state without needing to redeploy, nor develop any ad-hoc code.

No abstract

Even though blockchain is mostly popular for its cryptocurrency, smart contracts have become a very prominent blockchain application. Smart contracts are like classes that can be called by client applications outside the blockchain. Therefore it is possible to develop blockchain-oriented software (BOS) that implements part of the business logic in the blockchain by using smart contracts. Currently, there is no design standard to model BOS. Since modeling is an important part of designing a software, developers may struggle to plan their BOS. In this paper, we show three complementary modeling approaches based on well-known software engineering models and apply them to a BOS example. Our goal is to start the discussion on specialized blockchain modeling notations.

In Ethereum blockchain, the user needs to set a Gas price to get a transaction processed and approved by Miners. To have the transaction executed, the Gas price has to be greater than or equal to the lowest Ethereum transaction fees. This paper presents a set of data sampled every 15 seconds, from 1 December 2018 to 15 December 2018, coming from different blockchain web APIs. The aim of the paper is to investigate whether and to what extent different variables -such as the number of pending transactions, the value of the USD/Ether pair, average electricity prices around the world, and the number of miners -influence the Ethereum transaction fees. This study is relevant from an economic perspective because more and more companies in different economic fields are adopting Ethereum blockchain. From historical data analysis, we found that only some of these variables do have an influence. For example, the number of pending transactions and the number of miners have a major influence on Ethereum transaction fees when compared to the other variables.

Background: Due to the characteristics of the maintenance process followed in open source systems, developers are usually overwhelmed with a great amount of bugs. For instance, in 2012, approximately 7,600 bugs/month were reported for Mozilla systems. Improving developers' productivity in this context is a challenging task. In this paper, we describe and evaluate the new version of NextBug, a tool for recommending similar bugs in open source systems. NextBug is implemented as a Bugzilla plug-in and it was design to help maintainers to select the next bug he/she would fix. Results: We evaluated the new version of NextBug using a quantitative and a qualitative study. In the quantitative study, we applied our tool to 130,495 bugs reported for Mozilla products, and we consider as similar bugs that were handled by the same developer. The qualitative study reports the main results we received from a survey conducted with Mozilla developers and contributors. Most surveyed developers stated their interest in working with a tool like NextBug. Conclusion:We achieved the following results in our evaluation: (i) NextBug was able to provide at least one recommendation to 65% of the bugs in the quantitative study, (ii) in 54% of the cases there was at least one recommendation among the top-3 that was later handled by the same developer; (iii) 85% of Mozilla developers stated that NextBug would be useful to the Mozilla community.