Jocelyn Simmonds

MDE software process lines in small companies

Software organizations specify their software processes so that process knowledge can be systematically reused across projects. However, different projects may require different processes. Defining a separate process for each potential project context is expensive and error-prone, since these processes must simultaneously evolve in a consistent manner. Moreover, an organization cannot envision all possible project contexts in advance because several variables may be involved, and these may also be combined in different ways. This problem is even worse in small companies since they usually cannot afford to define more than one process. Software process lines are a specific type of software product lines, in the software process domain. A benefit of software process lines is that they allow software process customization with respect to a context. In this article we propose a model-driven approach for software process lines specification and configuration. The article also presents two industrial case studies carried out at two small Chilean software development companies. Both companies have benefited from applying our approach to their processes: new projects are now developed using custom processes, process knowledge is systematically reused, and the total time required to customize a process is much shorter than before.

A megamodel for Software Process Line modeling and evolution

Companies formalize software processes as a way of organizing development projects. Since there are differences in project contexts, a one-size-fits-all approach does not work well in practice. Some companies use a family of a predefined processes, but this approach has a high process maintenance cost. Instead, we define Software Process Lines (SPrL), where a general process with variability is tailored to project contexts. Model- Driven Engineering (MDE) provides a formal framework for defining the models and transformations required for automated SPrL tailoring. However, this approach requires the definition and co-evolution of various types of models and tool support beyond the skills of process engineers, making the industrial adoption challenging. This paper shares our experience using a megamodeling approach to the development of the back-end of our toolset. The megamodel provides a uniform mechanism for process definition, variability, tailoring and evolution, and we hide the MDE complexity through a user-friendly front-end. We report the application of our approach at Mobius, a small Chilean software enterprise.

Using megamodeling to improve industrial adoption of complex MDE solutions

Companies formalize their software processes as a way of organizing their development projects. As each project has its own requirements and objectives, a family of processes is required in practice, in order to ensure that each project is handled appropriately. This family may be a collection of predefined processes, but can also be automatically generated by tailoring a general process to a project’s context which requires formalization and tool support to be successful. Model-driven engineering provides a formal framework for defining the models and transformations required for automated process tailoring, but various types of models must be specified and evolved, limiting the industrial adoption of this approach. To address this problem, in this paper we propose a megamodel for automated process tailoring. Megamodeling provides an integrating framework for modeling in the large, including the definition and evolution of all models and transformations required for tailoring while hiding complexity. We report the application of our approach to the software development process of Rhiscom, a small Chilean company.

BehaviorDroid: monitoring Android applications

Mobile app developers declare permissions, but these do not guarantee that apps will behave as expected. Existing work focuses on checking predefined app properties, e.g., clone detection and API analysis. We propose BehaviorDroid, a framework for monitoring general app properties at runtime. Properties are currently specified using automata, describing desired and unwanted interactions between an app and phone resources. BehaviorDroid is a robust, extensible and configurable framework that can simultaneously monitor multiple apps and properties, showing reasonable CPU and memory usage during execution. Initial experiments show that we can improve memory usage by combining automata that have similar alphabets.

Semi-automated Tool Recommender for Software Development Processes

Application life-cycle management (ALM) tools are key for streamlining software development processes. However, small and medium development companies (SMBs) cannot afford to carry out time- and people-intensive tool evaluations for each project, and instead adopt fixed toolsets, thus losing flexibility. To simplify the tool selection process, this article proposes formalizing tool selection as a set of Multiple-Criteria Decision-Making (MCDM) problem, one for each ALM domain. Our domain-parametric recommender takes as inputs a domain, a process definition, and a set of tool evaluation criteria, and yields a ranked list of tools. The approach has been prototyped with the Testing domain and evaluated using a real process and project; the recommendations generated by our approach were quite similar to those of three Testing experts. Pending further evaluation, these results suggest that our approach can generate project-specific tool recommendations with results comparable to those of experts, but at a fraction of the cost.

Mobile Application Monitoring

To date, there are more than 800.000 applications available on each of the two largest mobile application markets (Google Play and Apple App Store), each reporting around 40 billion downloads in total. At this scale, it is impossible to analyze each application for malware behavior before making them available for download. Vendors mostly rely on user feedback to remove malware from their marketplaces, so it can take a while for these applications to be removed. In practice, users must be very careful when picking which applications to install. Moreover, it can be hard to detect a malware application once it is installed, unless the application has noticeable side-effects. To improve this situation, we propose a framework for performing runtime monitoring of mobile applications against behavioral correctness properties. These properties specify forbidden and desired interactions between applications and the phones resources as sequences of events. The user can then determine which applications to uninstall based on which properties they violate. We have implemented a prototype of this framework for the Android operating system. In this first version of the framework, the user must specify the properties to be monitored directly as automata.

The v-algorithm for discovering software process lines

A software company can define a software process line (SPrL) to deal with projects with different characteristics. This entails defining a base process and its variation points; the SPrL is then tailored to each project. This approach avoids the co‐evolution problems but is expensive to set up. In companies that register project events, this information could be used to discover the SPrL. However, traditional discovery algorithms focus on extracting a single process, which can be overly complex and would not be useful for managing future projects. Filtering out less frequent behavior leads to the discovery of simpler models, but these may not include relevant behavior. To address these issues, we propose the v‐algorithm, which discovers a SPrL from process logs. Two thresholds split the log into three clusters based on relation frequency. The first one is used to generate the base process, the second one is used to identify variable elements, and the last one is discarded. We used the v‐algorithm to discover the SPrL of Mobius, a small Chilean software company. We also discuss how the values of the thresholds affect the process discovery quality dimensions, extending existing metrics to the SPrL case. Copyright

Spin lock killed the performance star

The Internet has grown quite quickly, requiring more and more processing power each year to handle user requests in a timely fashion. In the multicore world, the addition of server-side threads should help improve server performance. However, several studies have shown that this is not true, identifying the Linux kernel as the possible culprit. Our working hypothesis is that the kernel does not provide a scalable interface for network communications. Through various tests, we narrowed the problem down to the implementation of the spin lock mechanism (a synchronization structure used mostly at the kernel level), which has been inherited from early versions of the Linux kernel. It is only now, with the emergence of multicore architectures, that users have begun to notice the performance hit that the existing spin lock implementation has on parallel systems, especially in multithreaded network protocols. Thus, our recommendation is that spin locks be redesigned so that the full power of multicore systems can be harnessed.

Assessing software development skills among K-6 learners in a project-based workshop with scratch

Recent literature reports a fair amount of initiatives on how to engage younger populations in achieving computational literacy. However, there is considerable less research on how to effectively deliver software development skills in a way that can be accepted and ultimately adopted by this user group. As a way to bridge this gap, we ran an extracurricular project-based workshop, targeting 10-12 years old learners with no prior coding experience, delivered over five days in the computer labs at the University of Chile. In this workshop, participants follow hands-on activities where they acquire the basics of computer programming and develop a small-scale software application using Scratch. These activities showcase that good software engineering practices can be taught to K-6 students, where these students are guided by experienced computer science undergraduate and graduate students. This paper presents a descriptive case study that focuses on assessing how K-6 learners assimilate and use these practices when developing their first computing application in a non-traditional learning experience. In order to do this, we designed and calibrated a rubric to evaluate the software products generated by the workshop participants. Our findings provide further evidence that it is indeed possible to teach initial notions of software engineering to this user group, structuring these constructs in a non-technical language that can be assimilated by novice developers. Furthermore, we did not observe significant differences in this matter according to gender and socio-economic status.

Software product line evolution: A systematic literature review

Abstract Context: Software Product Lines (SPL) evolve when there are changes in the requirements, product structure or the technology being used. Different approaches have been proposed for managing SPL assets and some also address how evolution affects these assets. Existing mapping studies have focused on specific aspects of SPL evolution, but there is no cohesive body of work that gives an overview of the area as a whole. Objective: The goals of this work are to review the characteristics of the approaches reported as supporting SPL evolution, and to synthesize the evidence provided by primary studies about the nature of their processes, as well as how they are reported and validated. Method: We conducted a systematic literature review, considering six research questions formulated to evaluate evolution approaches for SPL. We considered journal, conference and workshop papers published up until March 2017 in leading digital libraries for computer science. Results: After a thorough analysis of the papers retrieved from the digital libraries, we ended up with a set of 60 primary studies. Feature models are widely used to represent SPLs, so feature evolution is frequently addressed. Other assets are less frequently addressed. The area has matured over time: papers presenting more rigorous work are becoming more common. The processes used to support SPL evolution are systematic, but with a low level of automation. Conclusions: Our research shows that there is no consensus about SPL formalization, what assets can evolve, nor how and when these evolve. Case studies are quite popular, but few industrial-sized case studies are publicly available. Also, few of the proposed techniques offer tool support. We believe that the SPL community needs to work together to improve the state of the art, creating methods and tools that support SPL evolution in a more comparable manner.