Teaching software quality via source code inspection tool

In Engineering and Scientific computing, a significant number of software systems that are being commonly used by the Engineering community are developed and deployed as Open Source Systems (OSS). This collaborative development model has been widely accepted in both academia and industry. As these systems are typically developed by developers who are experts in their fields (e.g., Engineering), some of those programmers may be lacking an essential skillset today's software quality and engineering concepts (e.g., source code maintainability and analyzability, source code vulnerability, parallelization, etc.). An empirical study is presented that examines some of the source code quality aspects and programming practices (e.g., jumps statements, usage of recursion) from software engineering perspective in ten open source Engineering software systems. The studied systems are written in the C/C++ programming languages and comprised of over ten million lines of code, and present numerous tasks of the engineering community, including computer-aided design, computational fluid dynamics, and finite element analysis. Static analysis methods are applied to each system to determine the number of jump statements (Goto and Break statements) and functions that are recursively invoked. Functions that contain direct or indirect recursive calls are determined and counted. The results show that number of the used jump statements and functions that have recursive calls are significant and thus pose more of a roadblock to effectively and automatically maintain, comprehend, analyze, and re-engineer systems. Lastly, this leads to inefficiencies in a software engineer's ability to accomplish these common tasks. The study showed that issues in source code stemming from the lack of coding standards have increased over time and are prevalent.

Early prediction of quality of service using interface-level metrics, code-level metrics, and antipatterns

Source code quality is undoubtedly very important, yet usually forgotten aspect of software development process. This study shows different approaches to analysis of student codes, mainly in Java. By comparing different widely-used tools and our solution, we are able to get precise results from such an analysis, and thus to improve the code quality. The analysis results can also be used to determine knowledge and skills of novice programmers (students). Analysis of source codes may be as simple as counting the occurrences of language constructs or as complex as design pattern detection. Different approaches and solutions, i.e. measurements of language construct occurrences, copy-pasted code and design pattern detection, or source code quality, are discussed and subjected to evaluation by being executing on source codes of students as novice programmers.

Putting Requirements and Quality at the Core of Global Service Delivery: Current Efforts and Future Plans at Pace University

Software use is ubiquitous. The quality and the evolution of quality over long periods of time is therefore of notable importance. Software engineering research investigates software quality in multiple areas. One of these areas are predictive models, in which measurements of past changes to the source code or file contents are used to assess the quality of changes, files or even product releases. However, these predictive models have yet to transition from research to practice on a larger scale. In contrast, Automated Static Analysis Tools (ASATs) are used in practice and are also part of several software quality models. ASATs are able to warn developers about parts of the source code that violate best practices or match common defect patterns. One downside of ASATs are false positives, i.e., warnings about parts of the code which are not problematic. Developers have to manually assess the warnings and annotate the code or the ASAT configuration to mitigate this. Within this thesis, we investigate the evolution of software quality with a focus on a general purpose ASAT for Java. Our main objective is to determine if the use of an ASAT can improve software quality, as measured by defects, significantly enough to mitigate additional effort by the developers to use the ASAT. We combine multiple software engineering research techniques and data validation studies to improve the signal-to-noise ratio to increase the validity and stability of our results. We focus on a general purpose ASAT for the Java programming language due to the maturity of the language and the large number of projects available for this language. Both the language and the general purpose ASAT have been available for a long time, which allows us to include longer periods of time for our analyses. We study how the ASAT is applied, how the generated warnings evolve over long time periods, and how it affects the quality of the source code in terms of defects. In addition, we include the perspective of the developers regarding software quality improvement by measuring changes when developers intend to improve the quality of the source code. Our studies yield surprising insights. While our results show that ASATs have a positive impact on software quality, the magnitude of the impact is much smaller than expected. Moreover, we can show that corrective changes are the main driver of complexity in software projects. They introduce more complexity than feature additions or any other type of maintenance. In addition, we find that software quality estimation models benefit more from size and complexity metrics than static analysis warnings of an ASAT. Our study of developer intents to increase software quality mirrors this result.

The support of software quality in a software development process may be regarded under two aspects: first, by providing techniques, which support the development of high quality software and second, by providing techniques, which assure the required quality attributes in existing artifacts. Both approaches have to be combined to achieve effective and successful software engineering.In this study, we compare three of the most industrially relevant software development process models (Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP)) regarding their software quality support in terms of software quality development and software quality assurance. Based on the results we propose a de-facto standard for quality support in software development process models.

Defect prediction is an active topic in software quality assurance, which can help developers find potential bugs and make better use of resources. To improve prediction performance, this paper introduces cross-entropy, one common measure for natural language, as a new code metric into defect prediction tasks and proposes a framework called DefectLearner for this process. We first build a recurrent neural network language model to learn regularities in source code from software repository. Based on the trained model, the cross-entropy of each component can be calculated. To evaluate the discrimination for defect-proneness, cross-entropy is compared with 20 widely used metrics on 12 open-source projects. The experimental results show that cross-entropy metric is more discriminative than 50% of the traditional metrics. Besides, we combine cross-entropy with traditional metric suites together for accurate defect prediction. With cross-entropy added, the performance of prediction models is improved by an average of 2.8% in F1-score.

Software is being produced so fast that its growth hinders its sustainability. Technical debt, which encompasses internal software quality, evolution and maintenance, reengineering, and economics, is growing such that its management is becoming the dominant driver of software engineering progress. It spans the software engineering life cycle, and its management capitalizes on recent advances in fields such as source code analysis, quality measurement, and project management. Managing technical debt will become an investment activity applying economic theories. It will effectively address the architecture level and will offer specific processes and tools employing data science and analytics to support decision making. It will also be an essential part of the software engineering curriculum. Getting ahead of the software quality and innovation curve will inevitably involve establishing technical-debt management as a core software engineering practice. This article is part of a special issue on the Future of Software Engineering.

A significant slowdown in processor performance growth is associated with approaching the physical limits of reducing transistor size. This has led to the situation where traditional ways of increasing performance (increasing the clock frequency or the number of cores) no longer fully deliver performance gains. In modern processors, SIMD (Single Instruction, Multiple Da-ta) instruction-set architectures play an important role in increasing computing performance. They allow a processor to perform one operation on multiple data streams simultaneously on a single core. In such a situation, parallel processing at the data level, implemented using SIMD instructions, becomes key. Directing the compilation process with special directives, options, and proper data organization makes it possible to obtain an optimized, vectorized code without explicitly using SIMD instructions in the program source code. However, the effectiveness of such mechanisms largely depends on a number of factors: the processor architectural features, the compiler version, the source code quality, and the optimizer state. The article analyzes some existing methods and tools for vectorizing code using SIMD instructions and proposes an ap-proach to automating vectorization by inserting labels into source code, detecting section boundaries in compiled code, analyzing instructions within sections, and generating a report with a link to the source code. A comparative analysis of existing vectorization tools and the developed prototype is conducted. The proposed approach allows for automating the verifica-tion of code vectorization with line-level accuracy and works even with aggressive optimiza-tion, including function embedding.

Aims: Software quality assurance is a formal process for evaluating and documenting the quality of the work products during each stage of the software development lifecycle.The practice of applying software metrics to operational factors and to maintain factors is a complex task.Successful software quality assurance is highly dependent on software metrics.It needs linkage the software quality model and software metrics through quality factors in order to offer measure method for software quality assurance.The contributions of this paper build an appropriate method of Software quality metrics application in quality life cycle with software quality assurance.Design: The purpose approach defines some software metrics in the factors and discussed several software quality assurance model and some quality factors measure method.Methodology: This paper solves customer value evaluation problem are: Build a framework of combination of software quality criteria.Describes software metrics.Build Software quality metrics application in quality life cycle with software quality assurance.Results: From the appropriate method of Software quality metrics application in quality life cycle with software quality assurance, each activity in the software life cycle, there is one or more QA quality measure metrics focus on ensuring the quality of the process and the resulting product.Future research is need to extend and improve the methodology to extend metrics that have been validated on one project, using our criteria, valid measures of quality on future software project.

In this chapter, we looked at some of the C#, .NET, and Visual Studio features that you can use to improve the quality of your source code and reduce the likelihood of errors or unexpected behavior in your program. No single technique is perfect, but a combination of the approaches we have looked at can provide a great deal of insight into how your code will operate and the implicit assumptions that we all make when writing code. Few programmers like testing, but the more experienced you become with C# and .NET, the more you will appreciate how much of your time and your users’ time can be saved by improving the quality of your code.

Abstract: In terms of software, continuous of the software is the best quality assurance. Continuous development requires either the original developer to continue development, or the next generation of developers to take over the development. It has been noted that when the original developer has used a development paradigm in which the source code is kept open to all, highly motivated and competent developers will participate in development. This makes it easier for a project to survive. However, at the same time, when the source code is opened to a broad audience a in the source code tends to occur. When this happens, those with a high level of competence and motivation abandon the development and go their separate ways. In such a situation, it is difficult for a project to survive. In the case of Denshin 8 go, a guardian for the source code was appointed, and the original developer and the guardians avoided this dilemma. Richard Stallman of the GNU project and Linus Torvalds of Linux project act as legitimate guardians to avoid fork.Keywords: software development, open source, fork, buried source code, legitimate guardian, Denshin 8 goIntroductionFor software, continuous of the software is the best quality assurance (Ikuine 8s Fujita, 2013). Continuous development requires either the original developer to continue development or others to take over (Fujita 8s Ikuine, 2013b). When other developers take over, the original developer must share the source code with others. Open Source is a paradigm wherein the source code is shared and made broadly available to others. It has been noted that the project adopting open source can attract competent and highly motivated developers. Thus, some claim that developers can readily ensure the survival of software development projects when the source code is open.However, opening the source code to a broad audience can cause heterogeneity in the source code, even when people continue the development based on the original source code, a phenomenon known as fork (forking). In the case of open source software (hereinafter, OSS), literally anyone can obtain the source code and modify it to develop new software and start up new projects. Therefore, forks often occur in the OSS project, and the impact of forking has been studied for very long (Dibona, Ockman, 8s Stone, 1999; Kogut 8s Metiu, 2001; Nyman 8s Lindman, 2013; Nyman, Mikkonen, Lindman, 8s Fougere, 2012; Raymond, 1997, 1999). Moreover, some studies have focused on how to maintain forked projects, under the assumption that forking will inevitably occur (Gamalielesson 8s Lundell, 2013; Ray 8s Kim, 2012; Ray, Wiley, Kim, 2012).When forking does occur, competent and motivated developers start to abandon the project and go their separate ways, which may affect the survival of these projects. In other words, sharing the source code comes with a dilemma. If one loosens restrictions and shares the source code broadly, that project may survive; however, if the project is forked, competent successors with strong skills and desires will end up working on their own, or perhaps inter-project competition may lead to vying for competent successors. On the other hand, while establishing strict conditions and sharing the source code only with a select few may make the source code easy to control and reduce the possibility of forking, it may become more difficult to find competent successors willing to participate under those conditions. This puts the survival of the project at risk. Ensuring the survival of a project requires that one avoid this dilemma of source code sharing.Research on avoiding the has heretofore focused on developer motivation, licenses, and project governance (Ernst, Easterbrook, 8s Mylopoulos, 2010; Neville-Neil, 2011; Nyman 8s Mikkonen, 2011; Robles 8s Gonzalez-Barahona, 2012; Viseur, 2012). However, forking is a phenomenon not limited to OSS, and examples can be seen in Unix as well (Takahashi 8s Takamatsu, 2002, 2013). …

Measuring the internal quality of source code is one of the traditional goals of making software development into an engineering discipline. Cyclomatic complexity (CC) is an often used source code quality metric, next to source lines of code (SLOC). However, the use of the CC metric is challenged by the repeated claim that CC is redundant with respect to SLOC because of strong linear correlation.We conducted an extensive literature study of the CC/SLOC correlation results. Next, we tested correlation on large Java (17.6 M methods) and C (6.3 M functions) corpora. Our results show that linear correlation between SLOC and CC is only moderate as a result of increasingly high variance. We further observe that aggregating CC and SLOC as well as performing a power transform improves the correlation.Our conclusion is that the observed linear correlation between CC and SLOC of Java methods or C functions is not strong enough to conclude that CC is redundant with SLOC. This conclusion contradicts earlier claims from literature but concurs with the widely accepted practice of measuring of CC next to SLOC. Copyright © 2015 John Wiley & Sons, Ltd.

This work presents the results of a study of web sites of 230 OA digital repositories in 16 European countries. The analysis addresses the extent to which these repositories fulfil display characteristics of quality sites, over and above the quality of their content. The objective of this study is to verify whether web sites specifically committed to free access to information satisfy the quality criteria of accessibility, web positioning and quality of the source code. The results obtained find that accessibility must be improved upon, source code quality is merely acceptable, and web positioning is good. In short, bad practices were observed that should not occur in sites whose objective is to facilitate the free access to information.

Software quality assurance (SQA) must be able to support the practical application. This chapter presents the models as well as the software engineering standards available for correctly defining performance or non‐functional requirements of software. It describes the research carried out over the years that culminated in a definition of a software quality model. Quality assurance, in certain industries and business models overseen by the software developer, requires a more formal management of software quality throughout the software life cycle. Quality is often measured by considering a specific perception of quality. The chapter provides the SQA practitioner with the knowledge to use the ISO 25010 software quality model concepts. It presents the history of the different models and standards designed to characterize software quality. The chapter introduces the concept of quality requirements and presents a process for defining quality requirements.