Software Library Investment Metrics: a New Approach, Issues and Recommendations

work of W. Edwards Deming has convinced industry that must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of perception that software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make as an industry and as an engineering discipline rather than craft. Developing reliable and usable software that is delivered on and within budget still represents difficult endeavour for many organisations. As role of software becomes increasingly critical for businesses as well as for human lives, problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, news media is there to make big stories. Organisations are realising that their fundamental problems is immaturity of their software process. Robert Lai (1993) proposes that process improvement is second maturity wave of software industry. He states that the first wave of software was developed using waterfall model in 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Management in midst of second wave maturity movement as we attempt to formally define development process and best ways to continuously improve it (Lai 1993). Taking lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and Software Engineering Institute (SEI) at Carnegie Mellon University. SEI started in 1986 to develop process maturity framework to help organisations appraise maturity of their software process, and to provide guidance for organisations to improve their software process capability. A brief description of framework was released in September 1987, including maturity questionnaire. SEI evolved model and questionnaire into 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, released CMM version 1.1 (Paulk et al 1993). This paper discusses software process and describes capability maturity model (CMM). It also shows how CMM can be used as basis to measure maturity of software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book Quality is Free Phil Crosby states that: Quality is free. It is not gift, is free. What cost money are unqualify of things all actions that involve not doing jobs right first time (Crosby 1980). If such statement is true for many disciplines, is particularly true for evidence is abundant in number of software products which exceeded their budget, were produced late, failed to satisfy user requirements, and are full of bugs. demand for improved software quality is increasing to ensure reliable products and services. benefits of improved quality comes in form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software link between process maturity and software quality is expressed in premise that The quality of software system is governed by quality of process used to develop and maintain it. One stumbling block to improving software quality seems to be that not enough attention is paid to overall development process itself. While software professionals typically devote their to developing, testing or documenting software products, no one has prime responsibility for improving software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Systems 217 no one is working on software process, orderly improvement is unlikely. process certainly won't improve itself, rather, most likely, will deteriorate over time. Continuous improvement can occur only if process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: Without work on process, there will be little or no progress in improving software. THE SOFTWARE PROCESS Adopting process view of software development represents revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by software process. What Is Software Process According to Webster's dictionary, process is a system of operations in producing something .. series of actions, changes, or functions that achieve an end result. Chambers Concise Dictionary defines process as a series of actions or events .. sequence of operations or changes undergone. IEEE defines process as a sequence of steps performed for given purpose. In general business context, process is defined as a structured, measured set of activities designed to produce specified output for particular customer or market (Davenport 1993). These definitions put strong emphasis on HOW work is done, in contrast to product focus's emphasis on WHAT. Accordingly, process can be considered as a specific ordering of work activities across and place, with beginning, an end, and clearly identified inputs and outputs: structure for action. In this paper we will adopt following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. software process is The set of activities, methods, and practices used in production and evolution of software. software engineering process is The total set of software engineering activities needed to transform user's requirements into software. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Management People and Software Process Software development is still people-intensive activity. Talented people are most important element in any software organisation. Even if you get best people available, if they do not follow common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, results will be chaos. Successful software organisations have learned that even best professionals need structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. obvious fact is that attracting best people is vital, but is also essential to support them with an effectively managed software process. Technology and Software Process Another myth is widespread belief that some technologically advanced tool or method will provide magic answer to software crisis. This is not only wrong, but is dangerous. Organisations which jumped on bandwagon of CASE tools, and ended up in failure and wasted and effort have learned their lesson hard way. Just ask yourself before introducing technology: What do I want to automate? In absence of defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. Need for Defined Process If no effort is made to define and enhance software development process across whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle task of developing complex software systems. goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. principles are same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to software development as they are to production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

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.

Abstract: DevOps, an extension of agile methods, integrates numerous principles to improve communication between development and operations teams. The fundamental goal of this research is to look at the effects of DevOps adoption on software quality, as well as to explore effective ways for improving quality effectively. An thorough literature investigation was conducted to investigate existing DevOps methods in the sector, resulting in the construction of a conceptual research model with five derived hypotheses. The study objectives were met by evaluating hypotheses with Pearson correlation and developing a linear model based on linear regression analysis. To collect quantifiable data, an online questionnaire was used, followed by interviews with DevOps and Quality Assurance professionals to determine how DevOps may improve software quality. Feedback from interviews, coupled with The hypotheses were tested using regression analysis, and suggestions were based on them. The quantitative study's findings show that adopting DevOps leads to considerable improvements in software quality, particularly when using the CAMS (Culture, Automation, Measurement, Sharing) architecture. Among the considerations, automation emerged as the most important component for improving software quality. The findings of multiple regression analysis highlight the relevance of culture, automation, measurement, and sharing in the goal of higher software quality. In conclusion, this study strongly argues for the use of DevOps to produce high-quality software. Organizations may significantly improve the overall quality of their software products by implementing the CAMS Framework and adhering to concepts such as automation.

Estimating the quality of software modules provides a practical way to assess their potential risk. A software quality estimation can be used to provide a targeted software quality improvement initiative. The aim is to provide the management team with a practical quality assessment of software modules for a cost‐effective utilization of software quality improvement resources. In our previous and ongoing research, we have empirically investigated three different kinds of software quality models that are built using software measurement data—software quality classification, software fault prediction, and module‐order modeling. The classification model predicts the class membership of software modules into the fault‐prone and not fault‐prone classes. The fault prediction model estimates the number of faults expected in the modules. A module‐order model predicts the ranking of the modules with respect to their relative software quality. The preference among the three software quality models depends on the software quality improvement goals of the given software project team. We present the useful principles and a detailed overview of the three software quality estimation models, using a case study of a large‐scale telecommunications software system. The classification model is built using the logistic regression technique, whereas the fault prediction model is built using the multiple linear regression technique. The module‐order model is built using the estimations of the fault prediction model for ranking the software modules. We summarize our work with suggestions for software tools that can be used to build software quality estimation models.

The C* Conference on Computer Science and Software Engineering (C3S2E) was established in 2008. C3S2E 2010 is the third annual meeting in the C3S2E conference series and is held in Montréal, Québec, Canada, during May 19-20, 2010. The conference aims to address the need of the academic community in computer science and software engineering. It brings together academics, government and industry professionals to discuss recent progress and challenges in a broad range of areas in the field of computer science and software engineering such as algorithms and theory, artificial intelligence, bioinformatics, computer architecture, computer graphics, computer security, computer vision, data mining, databases, image processing, information retrieval, machine learning, as well as software engineering. C3S2E 2010 also serves as a platform for theoreticians and practitioners to exchange their original research ideas on academic or application aspects of computing and engineering of software systems, present their new findings on theoretical or practical aspects of computer science and software engineering, share their experiences on integrating new technologies into products and applications, discuss their work on applying computing and software engineering to real-life situations, describe their development and operations of challenging computing related systems, and identify unsolved challenges. Although it is the third time C3S2E is held, this comprehensive conference has grown from a Canadian conference into an international conference. For C3S2E 2010, we continue to keep our tradition for inviting international experts in various areas of computer science and software engineering to join our team of international program committee. As a result, our Program Committee consists of professionals from different parts of the world including Australia, Canada, Germany, Hong Kong, Italy, Japan, Portugal, South Korea, Turkey, UAE, and UK. This committee has done an excellent job in finishing the single-blind review and on-line double-blind debate processes in record time. On average, about 90% of reviews were submitted by the due date and about 3.67 reviews were received for each paper. In terms of submissions, we have attracted many high-quality papers submitted by authors globally. The paper selection process was thorough and competitive. On average, each paper was refereed by at least three reviewers, and about 18% of submissions were accepted as full research papers. This year, we have an intensive program that spans over two days. In addition to research papers and student posters, we also include position papers, which allow authors to give their opinions and vision on exploring new concepts and research directions.

Software engineering is human intensive. Thus, it is important to understand and evaluate the value of different types of experiences, and their relation to the quality of the developed software. Many job advertisements focus on requiring knowledge of specific programming languages. This may seem sensible at first sight, but maybe it is sufficient to have general knowledge in programming and then it is enough to learn a specific language within the new job. A key question is whether prior knowledge actually does improve software quality. This paper presents an empirical study where the programming experience of students is assessed using a survey at the beginning of a course on the Personal Software Process (PSP), and the outcome of the course is evaluated, for example, using the number of defects and development time. Statistical tests are used to analyse the relationship between programming experience and the performance of the students in terms of software quality. The results are mostly unexpected, for example, we are unable to show any significant relation between experience in the programming language used and the number of defects detected.

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.

A discussion is presented of the two primary ways of understanding software costs. The black-box or influence-function approach provides useful experimental and observational insights on the relative software productivity and quality leverage of various management, technical, environmental, and personnel options. The glass-box or cost distribution approach helps identify strategies for integrated software productivity and quality improvement programs using such structures as the value chain and the software productivity opportunity tree. The individual strategies for improving software productivity are identified. Issues related to software costs and controlling them are examined and discussed. It is pointed out that a good framework of techniques exists for controlling software budgets, schedules, and work completed, but that a great deal of further progress is needed to provide an overall set of planning and control techniques covering software product qualities and end-user system objectives.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

This research is to study the application software development of the distributed control system (DCS) in a manufacturing company named ABC (unreal name). The company delivered a DCS product including both hardware and software. Since the hardware is manufactured aboard, this research focuses only at the software development from the process of gathering the customer requirements to the software inspection test and product delivery. The developed application software is made-to-order and unique. The company provides different software according to the different needs of different customers. The writer has used the failure mode and effect analysis (FMEA) and the fault tree analysis (FTA) as quality tools for analysing the potential failure modes and their effects in the DCS project execution in a systematic way. From the study, the writer has discovered three major problems in the DCS project execution. These included (1) lack of procedures to control the project execution, (2) lack of the document and data control, and (3) technical problems. The result of these problems heavily affects to the DCS project execution. The company is unable to deliver the DCS to the customer on time for several projects and software bugs are also embedded to the delivered software product. These lead to the customer dissatisfaction and the company itself has made the profit much less than it was expected. The results of the analysis using the FMEA technique have leaded to the establishment of the quality assurance system for the DCS project execution which include checklists, standard document and prodedures, and the engineering database pool software (EDP). The EDP retains the useful engineering knowledge and the application software functions of the past DCS projects. The EDP is developed with the purpose to share and enhance engineering knowledge of engineers and to reuse the past application software functions so that engineers do not have to redesign the customer requested functions which have already been created before. The established quality assurance system has been implemented to one DCS project in the company and the results were the improvement in software quality and on-time delivery. 37 software errors were detected during the pre-inspection test and there were only 8 errors during the inspection test with the customer, comparing to the average of 50 to 60 errors found during the inspection test in the past projects. In the view of changes in RPN (Risk Priority Number), the percentage of RPN for each critical process of the project execution comparing between before and after implementation decreased 33 to 94%.

Software evolution is an essential foundation in delivering technology that adapts to user needs and industry dynamics. In an era of rapid technological development, software evolution is not just a necessity, but a must to ensure long-term relevance. Developers are faced with major challenges in maintaining and improving software quality over time. This research aims to investigate the correlation between feature volatility and bug occurrence rate in software evolution, to understand the impact of dynamic feature changes on software quality and development process. The research method uses commit analysis on the dataset as a marker of bug presence, studying the complex relationship between feature volatility and bug occurrence rate to reveal the interplay in software development. Validated datasets are measured by metrics and correlations are measured by Pearson-product-moment analysis. This research found a strong relationship between feature volatility and bug occurrence rate, suggesting that an increase in feature changes correlates with an increase in bugs that impact software stability and quality. This research provides important insights into the correlation between feature volatility and bug occurrence rates, guiding developers and quality practitioners to develop more effective testing strategies in dynamic development environments.

The thesis deals with the implementation and application of out-of-the-box tools in linear and mixed integer programming. It documents the lessons learned and conclusions drawn from five years of implementing, maintaining, extending, and using several computer codes to solve real-life industrial problems. By means of several examples it is demonstrated how to apply algebraic modeling languages to rapidly devise mathematical models of real-world problems. It is shown that today's MIP solvers are capable of solving the resulting mixed integer programs, leading to an approach that delivers results very quickly. Even though, problems are tackled that not long ago required the implementation of specialized branch-and-cut algorithms. In the first part of the thesis the modeling language Zimpl is introduced. Chapter 2 contains a complete description of the language. In the subsequent chapter details of the implementation are described. Both theoretical and practical considerations are discussed. Aspects of software engineering, error prevention, and detection are addressed. In the second part several real-world projects are examined that employed the methodology and the tools developed in the first part. Chapter 4 presents three projects from the telecommunication industry dealing with facility location problems. Chapter 5 characterizes questions that arise in UMTS planning. Problems, models, and solutions are discussed. Special emphasis is put on the dependency of the precision of the input data and the results. Possible reasons for unexpected and undesirable solutions are explained. Finally, the Steiner tree packing problem in graphs, a well-known hard combinatorial problem, is revisited. A formerly known, but not yet used model is applied to combine switchbox wire routing and via minimization. All instances known from the literature are solved by this approach, as are some newly generated bigger problem instances.

The research topic focuses on the characterization of software quality considering the main software elements such as people, process and product. Many attributes (size, language, testing techniques etc.) probably could have an effect on the quality of software. In this thesis we aim to understand the impact of attributes of three P's (people, product, process) on the quality of software by empirical means. Software quality can be interpreted in many ways, such as customer satisfaction, stability and defects etc. In this thesis we adopt ‘defect density' as a quality measure. Therefore the research focus on the empirical evidences of the impact of attributes of the three P's on the software defect density. For this reason empirical research methods (systematic literature reviews, case studies, and interviews) are utilized to collect empirical evidence. Each of this research method helps to extract the empirical evidences of the object under study and for data analysis statistical methods are used. Considering the product attributes, we have studied the size, language, development mode, age, complexity, module structure, module dependency, and module quality and their impact on project quality. Considering the process attributes, we have studied the process maturity and structure, and their impact on the project quality. Considering the people attributes, we have studied the experience and capability, and their impact on the project quality. Moreover, in the process category, we have studied the impact of one testing approach called ‘exploratory testing' and its impact on the quality of software. Exploratory testing is a widely used software-testing practice and means simultaneous learning, test design, and test execution. We have analyzed the exploratory testing weaknesses, and proposed a hybrid testing approach in an attempt to improve the quality. Concerning the product attributes, we found that there exist a significant difference of quality between open and close source projects, java and C projects, and large and small projects. Very small and defect free modules have impact on the software quality. Different complexity metrics have different impact on the software quality considering the size. Product complexity as defined in Table 53 has partial impact on the software quality. However software age and module dependencies are not factor to characterize the software quality. Concerning the people attributes, we found that platform experience, application experience and language and tool experience have significant impact on the software quality. Regarding the capability we found that programmer capability has partial impact on the software quality where as analyst capability has no impact on the software quality. Concerning process attributes we found that there is no difference of quality between the project developed under CMMI and those that are not developed under CMMI. Regarding the CMMI levels there is difference of software quality particularly between CMMI level 1 and CMMI level 3. Comparing different process types we found that hybrid projects are of better quality than waterfall projects. Process maturity defined by (SEI-CMM) has partial impact on the software quality. Concerning exploratory testing, we found that exploratory testing weaknesses induce the testing technical debt therefore a process is defined in conjunction with the scripted testing in an attempt to reduce the associated technical debt of exploratory testing. The findings are useful for both researchers and practitioners to evaluate their projects

Phase containment metrics for software quality improvement

Software refactoring is an effective method for improvement of software quality while software external behavior remains unchanged. To facilitate software refactoring, a number of tools have been proposed for code smell detection and/or for automatic or semi-automatic refactoring. However, these tools are passive and human driven, thus making software refactoring dependent on developers' spontaneity. As a result, software engineers with little experience in software refactoring might miss a number of potential refactorings or may conduct refactorings later than expected. Few refactorings might result in poor software quality, and delayed refactorings may incur higher refactoring cost. To this end, we propose a monitor-based instant refactoring framework to drive inexperienced software engineers to conduct more refactorings promptly. Changes in the source code are instantly analyzed by a monitor running in the background. If these changes have the potential to introduce code smells, i.e., signs of potential problems in the code that might require refactorings, the monitor invokes corresponding smell detection tools and warns developers to resolve detected smells promptly. Feedback from developers, i.e., whether detected smells have been acknowledged and resolved, is consequently used to optimize smell detection algorithms. The proposed framework has been implemented, evaluated, and compared with the traditional human-driven refactoring tools. Evaluation results suggest that the proposed framework could drive inexperienced engineers to resolve more code smells (by an increase of 140 percent) promptly. The average lifespan of resolved smells was reduced by 92 percent. Results also suggest that the proposed framework could help developers to avoid similar code smells through timely warnings at the early stages of software development, thus reducing the total number of code smells by 51 percent.

Software Technology for Adaptable, Reliable Systems (STARS) technical program plan