Adopting SOLID Principles in Android Application Development: A Case Study and Best Practices

JavaScript (JS) is one of the most popular programming languages for developing client-side applications mainly due to allowing the adoption of different programming styles, not having strict syntax rules, and supporting a plethora of frameworks. The flexibility that the language provides may accelerate the development of application, but also pose threats to the quality of the final software product, e.g., introducing Technical Debt (TD). TD reflects the additional cost of software maintenance activities to implement new features, occurring due to poorly developed solutions. Being able to forecast the levels of TD in the future can be extremely valuable in managing TD, since it can contribute to informed decision making when designating future repayments and refactoring budget among a company's projects. Despite the popularity of JS and the undoubtful benefits of accurate TD forecasting, in the literature, there is available only a limited number of tools and methodologies that are able to: (a) forecast TD during software evolution, (b) provide a ground-truth TD quantifications to train forecasting, since TD tools that are available are based on different rulesets and none is recognized as a state-of-the-art solution, (c) take into consideration the language-specific characteristics of JS. As a main contribution for this study, we propose a methodology (along with a supporting tool) that supports the aforementioned goals based on the Backward Stepwise Regression and Auto-Regressive Integrated Moving Average (ARIMA). We evaluate the proposed approach through a case study on 19,636 releases of 105 open-source applications. The results point out that: (a) the proposed model can lead to an accurate prediction of TD, and (b) the Number of appearances of the “new” and “eval” keyword along with the number of “anonymous” and “arrow” functions are among the features of JavaScript language that are related to high levels of TD.

Cross-disciplinary and cross-life-cycle-phase Technical Debt in automated Production Systems: two industrial case studies and a survey

Technical Debt tracking: Current state of practice

The practical implications of technical debt for the entire software life cycle; with examples and case studies. Technical debt in software is incurred when developers take shortcuts and make ill-advised technical decisions in the initial phases of a project, only to be confronted with the need for costly and labor-intensive workarounds later. This book offers advice on how to avoid technical debt, how to locate its sources, and how to remove it. It focuses on the practical implications of technical debt for the entire software lifecycle, with examples and case studies from companies that range from Boeing to Twitter. Technical debt is normal; it is part of most iterative development processes. But if debt is ignored, over time it may become unmanageably complex, requiring developers to spend all of their effort fixing bugs, with no time to add new features—and after all, new features are what customers really value. The authors explain how to monitor technical det, how to measure it, and how and when to pay it down. Broadening the conventional definition of technical debt, they cover requirements debt, implementation debt, testing debt, architecture debt, documentation debt, deployment debt, and social debt. They intersperse technical discussions with “Voice of the Practitioner” sidebars that detail real-world experiences with a variety of technical debt issues.

In the context of modern Android application development, security issues and secure programming are considered unignorable aspects to ensure the safety of Android applications while still guarantee the development speed. The lack of attention to security factors in the software development process or the delay of traditional security assurance methods are the main causes of unsafe Android software. Those unsafe Android applications contain many vulnerabilities and a high risk of leaking user information, especially since Android applications are rapidly developed and published. Developers must adhere to a secure development process to counter Android application risks to avoid data leakage or access control flaws. Security has to be integrated throughout the application development process to secure the software development life cycle. This paper presents two main research contributions: summarizing common security issues in Android applications and developing a plug-in for Android Studio to support secure programming, 9Fix. The low-time-cost 9Fix plug-in can inspect your vulnerable code and instantly suggest an alternative secure code for developers in programming time that helps to improve the security and instruct the developers on how to write a secure code. Moreover, the developers can add their own security rules to 9Fix so 9Fix can adapt smoothly in a specific situation. We also demonstrate the effectiveness and the convenience based on the student feedback by experimenting with the 9Fix plugin.

Technical debt are those convenience tasks that developers perform to obtain short-term benefits but that in the future can produce activities that are difficult to perform or more costly. The impact of technical debt is perceived in all project resources, becoming a present and future problem in software development, affecting the quality of the software. This study uses a qualitative analysis, through interviews with a software development team, explores the knowledge and perception of technical debt, the practices used to manage it, the factors that influence its appearance and accumulation, the impact that development suffers, as well as the team and the maintainability of the software, as a result, ideas and solutions are proposed to address it effectively. The study was carried out with a qualitative investigative approach, which was based on the study of a single case with which the experiences and practices in the perception and management of technical debt are investigated. The data obtained reveal that technical debt affects the normal development of the development team and that it is present in the activities carried out by the team. Although the development team has a perception of the debt, it does not address it directly, and it is necessary to implement good practices to identify it and integrate it into the software development process. Addressing technical debt with the implementation of a formal process to manage it will ensure that scheduled time is controlled and resources are optimized, which will result in a culture of good practices that will ensure product quality, improving team performance and guaranteeing software maintainability

One major problem in using static analyzers to manage, monitor, control, and reason about technical debt is that industrial projects have a huge amount of technical debt which reflects hundreds of quality rule violations (e.g., high complex module or low comment density). Moreover the negative impact of violating quality rules (i.e., technical debt interest) may vary across rules or even across contexts. Thus, without a context-specific validation and prioritization of quality rules, developers cannot effectively manage technical debt. This paper reports on a case study aimed at exploring the interest associated with violating quality rules; i.e., we investigate if and which quality rules are important for software developers. Our empirical method consists of a survey and a quantitative analysis of the historical data of a CMMI Level 5 software company. The main result of the quantitative analysis is that classes violating several quality rules are five times more defect prone than classes not violating any rule. The main result of the survey is that some rules are perceived by developers as more important than others; however, there is no false positive (i.e., incorrect rule or null interest). These results pave the way to a better practical use of quality rules to manage technical debt and describe new research directions for building a scientific foundation to the technical debt metaphor.

Due to cost and time constraints, software quality is often neglected in the evolution and adaptation of software. Thus, maintainability suffers, maintenance costs rise, and the development takes longer. These effects are referred to as “technical debt”. The challenge for project managers is to find a balance when using the given budget and schedule, either by reducing technical debt or by adding technical features. This balance is needed to keep time to market for current product releases short and future maintenance costs at an acceptable level. Method: The project ProDebt aimed at developing an innovative methodology and a software tool to support the strategic planning of technical debt in the context of agile software development. In this project, we created quality models and collected corresponding measurement data for two case studies in two different companies. Altogether, the two case studies contributed 5–6 years of data, from the end of 2011, resp. mid-2012, until today. Using measurement and effort data, we trained a machine-learning model to predict productivity based on measurement data—representing the technical debt of a file at a given point in time. Result: We developed a prototype and a prediction model for forecasting potential savings based on proposed refactorings of key drivers of technical debt identified by the model. In this paper, we present the approach and the experiences made during model development.

Technical Debt is a term coined by Ward Cunningham to denote the amount of rework required to put a piece of software into that state which it should have had from the beginning. The term outdates the agile revolution. Technical debt can occur using any development approach, but since agile development has become wide spread the notion of “technical debt” has gained much more attention. That is because if agile development is not done properly, technical debt accrues very fast and threatens to strangle the project. In this paper the author describes how technical debt comes to being, how it can be measured and what can be done to prevent it in agile development. The emphasis of the paper is on how to prevent it. What measures are necessary in an agile development project to keep technical debt from accruing over time? The paper lists out a number of measures which can be taken – organizational, procedural and technical. Automated tools play an important role in the struggle against technical debt. Samples are given how a tool can be helpful in identifying and removing problems before they get out of hand. Also important is an external auditing agency which monitors projects in progress with the aide of automated tools. In the end a case study is presented which illustrates the monitoring of technical debt within an agile development and what counter measures are required to stop it.KeywordsTechnical debtcode qualityproduct documentationsoftware defectsrefactoringsoftware metricsagile team organizationagile testing

According to International Data Corporation (IDC), Android accounted for 81% of all smartphone shipments in the third quarter of 2013. With the increase in smartphones, mobile application installs from Google Play have reached more than 48 billion app installs as revealed by Sundar Pichai, senior vice president, Chrome and Apps at Google I/O 2013. Thus, Android application development has become increasingly popular with the need of an effective software solution for application development and testing. While most Android applications are developed in Java, the Android framework is quite different fromm typical Java frameworks. Thus, while development or testing of Android applications, the user needs to be aware of all the terms and concepts specific to the Android framework such as activity, views and the Android SDK in general.

Technical debt (TD) is a concept used to describe a sub-optimal solution of a software artifact that negatively affects its comprehensibility, extendability and maintainability. As such, TD adversely affects the costs or quality associated with the artifact, which is also called interest. TD has through research been identified in all types of software artifacts, from architectural design to automated tests (Testware). However, research into testware technical debt (TTD) is limited and primarily focused on testing on lower level of system abstraction, i.e. unit-and integration tests, leaving a need for more TTD research on GUI-based testing. In this study we explore this gap in knowledge through an industrial case study at a Swedish avionics software development company. Four repositories are studied for the presence of TTD using expert interviews, semi-automated document analysis and automatic metric analysis. Results of the study provide initial support that the concept of TTD is applicable to GUI-based testware and show the presence of both TD items unique to GUI-based testware and items common to software. The implications of these results are that engineering best practices must be established for GUI-based testware to minimize TD interest.

Costs and obstacles encountered in technical debt management – A case study

A Third-Party Library(TPL) is often used in developing Android applications, however older TPLs may have vulnerabilities. Hence developers need to keep them in their applications the latest version. Nevertheless, there is a lot of applications using older TPLs. In this paper, we propose a new method which users enable to update TPLs in Android applications. An Android application and TPLs can be converted to smali file which is more of an assembly based language. A smali file can be replaced with another smali file on the same class. Our method takes advantage of its properties and exchanges a vulnerable TPL for an security fixed one. Moreover, we apply it to real applications and evaluate feasibility of it.

This paper focuses on software quality assurance in android application development with focus on approaches to confirm software quality in android applications. In this work, we compare the waterfall model with agile-scrum methodologies to realize software quality assurance with special focus on mobile applications. This research allows us to answer, “Which process model and practices are available for android software development along with focus on quality assurance?” The other research focus in this paper is “How auditors, developers and testers play their defined roles to maintain quality in mobile application development?” Agility for software development has transformed into a preferred and favored method for mobile application development. The major aim of this research is to contribute for a better knowledge for mobile application development methodologies practiced by the organizations for the development of applications based on systematic literature review.

In this paper, a novel self-punishment based scheduling algorithm for a cooperative real- time content download application is designed. In the proposed protocol, selfish mobile devices autonomously form cooperative groups. For each formed group, the base station transmits the content to a selected mobile device designated as seed. Then, the seed shares the content with other mobile devices called sinks over device-to-device links. After analyzing the proposed protocol using a repeated game, new self-punishment mechanisms by revocation or by decreasing the bit rate, are proposed. Such self-punishment mechanisms enable the mobile devices in each cooperative group to autonomously punish selfish seeds without requiring any help from other mobile devices outside cooperative group. ‌Based on the proposed self-punishment mechanisms, a fair algorithm is designed to schedule the seeds in each cooperative group. Then, the designed scheduling algorithm is implemented using an Android application that is developed using Java in the Android Development Tool Bundle. The developed Android application does not depend on the operation system of mobile devices. Simulation results demonstrate that, on the average, the proposed protocol improves the energy efficiency of mobile devices to download real-time content of around 42 % compared to a traditional multicast scenario. Moreover, the proposed protocol does not let the energy efficiency of mobile devices degrade more than 11 %, on average, from the optimal solution even when all the mobile devises are selfish. The practical results show that the maximum difference in the run time of a real- time video over real-world smartphone screens is less than 500 milliseconds when the smartphones form a cooperative group using the developed Android application.