EMPIRICAL CHARACTERIZATION OF SOFTWARE QUALITY

Software testing is an important process in a software development life-cycle as validation and verification mechanisms to guarantee the quality of the intended software product. Exploratory testing is a software testing where the testers may interact with the system in whatever way they want and use the information the system provides to react and generally explore the system functionalities without restraint. Exploratory testing allows the full power of the human brain to be brought to bear on finding bugs and verifying functionality without preconceived restrictions. This paper discuss about enacting exploratory software testing in a software project which was developing Student Marking System (SMS) in University XYZ.

As the systems concerning semiconductor manufacturing process at Samsung Electronics have been increased the complexity and expanded the size, the importance of software quality is taken a growing interests. Managing manufacturing process on the basis of controlling software quality in the Samsung Electronics Semiconductor Business deeply influence the quality of semiconductor yield. Therefore, software quality assurance activities become more critical than before. SQA is not only terminology of quality but a department handling software quality in the Samsung Electronics Semiconductor Business. SQA has handled software quality related activities employed throughout the software development life cycle to positively influence and quantify the quality of the delivered software. SQA has monitored the software development to make sure that the software process and products should be followed a set of clearly-defined standards and processes. These SQA activities and SBS improve the software quality and products of IT projects. This paper explores the system based SQA and software process improvements for the successful projects. It has been proved that the introduction of SBS substantially has improved the rate of delivery at the appointed date and software quality by carrying out that system. Therefore, this paper, on the basis of SBS, examines the effect on quality and process improvement.

The Global software industry worth about $293 billion in 2011 is plagued by an ironic fact that a huge proportion of the software projects are below their schedules or are not completed due to bad planning, poor specification of software product specifications and technical inadequacies. The concept of software quality management is gaining increasingly more and more popularity as software firms now prefer the use of quality assurance practices to provide software products that are more reliable and efficient. This paper aims to augment earlier research conducted relating to software quality assurance practices and identifies any link between customer satisfaction and optimization of costs associated with the development and maintenance of software products. The gathered data from Clients and development teams is analyzed in SPSS tool to measures the impact of implementing Software Quality Standards on Customer Satisfaction through variations in Product Development Time and Product Safety.

Quality model is regarded as a well-accepted approach for assessing, managing and improving software product quality. There are three categories of quality models for software products, i.e., definition model, assessment model, and prediction model. Quality assessment model (QAM) is a metric-based approach to assess the software quality. It is typically regarded as of high importance for its clear method on how to assess a system. However, the current state-of-the-art in QAM research is under limited investigation. To address this gap, the paper provides an organized and synthesized summary of the current QAMs. In detail, we conduct a systematic mapping study (SMS) for structuring the relevant articles. We obtain a total of 716 papers from the five databases, and 31 papers are selected as relevant studies at last. In summary, our work focuses on QAMs from the following aspects: software metrics, quality factors, aggregation methods, evaluation methods and tool support. According to the analysis results, our work discovers five needs that researchers in this area should continue to address: (1) new method and criteria to tailor a quality framework (i.e., structure of software metrics and quality factors) according to different specifics, (2) systematic investigations on the effectiveness, strength and weakness of different aggregation methods to guide the method selection in different context, (3) more investigations on evaluating QAMs in the context of industrial cases, (4) further investigations or real-world case studies on the QAMs related tools, and (5) building a public and diverse software benchmark which can be adopted in different application context.

In this paper, we study oligopolistic competition between closed and open source softwares. By intersecting existing economic contributions on open source, we propose a two stage game with perfect information and product di¤eretiation in which producers firstly set softwares quality, then they determine prices (constrained at zero for open source programs). In doing this, we explicitly model lock-in e¤ects, network externality components of software quality as well as knowledge accumulation in software use and implementation. With respect to a monopolistic benchmark case, we argue that in duopoly a pro- prietary sofware producer facing an open source software will reduce its selling price whether: (i) its network of users is larger than open sources one and its consumers are largely experienced on its program, (ii) it has a small network of un-skilled consumers. In opposition, after open source softwares emergence, proprietary software price does augment if proprietary software users form a large, but poorly skilled network. Fur- thermore, we show that, in all above cases, proprietary software quality increases because of the existence of a open source alternative to a previouisly monopolistic program. Finally, by modeling knowledge accumulation processes through di¤erence equations, we show that the ratio between closed and open source programs opportunity costs of software learning and deployment plays a crucial role in shaping market outcomes. Until an open source software remains too complex and technical for unskilled or time-scarse users, a shared market solution in which both softwares are adopted is predicted. In contrast, if opportunity costs in learning and understanding open source programs are remarkably low, or at least equal to opportunity costs of a closed source software, then a open source dominance outcome (i.e. all software are open ones) phases out.

The moderator has offered seven propositions relative to the meaning and conduct of effective software quality assurance. Although I find it difficult to give unqualified acceptance or rejection to any of these propositions, in response to the rules of the session I accept propositions 1, 2, 3 and 5 and reject 4, 6 and 7.After a number of years experience in the software quality arena, both in government and industry, I have come to the conclusion that the most important aspect of software quality assurance is to make a positive contribution to the objective of the software project. I define this objective as the development of a quality software product delivered on time and within budget. I further define a quality software product as one which meets customer requirements and provides usable service. In short my perspective of software quality assurance is one of contribution in contrast to the “righteousness of the cause.”To this end I suggest an “engineering analysis approach” to software quality. Such an approach can take the form of a typical engineering problem solving model with steps of problem formulation, problem analysis, search, decision, specification and implementation. Using such an approach the advocates for quality software can use empirical evidence to establish the contributions software quality assurance efforts make toward the software project objective.

Background: Technical Debt (TD) refers to the problem of pending or incomplete tasks and artifacts that brings short term gain to a software project, but may have to be paid with interest later on in its life-cycle. We use the term test-related debt to refer to TD items faced by software testing practitioners. Goal: To investigate, from the point of view of software testing practitioners, TD types associated with test-related debt, the causes that lead to it, and the effects of its existence. Method: We perform a replication of a well-known TD survey with software testing practitioners and combine the obtained responses with the ones collected in the original study. In total, the study analyses, quantitatively and qualitatively, 54 responses from Brazilian testing practitioners. Results: Test-related debt items are associated with TD types such as documentation, code, and test debt itself. The survey identified 61 TD causes that are organized into eight categories. The main causes are deadline, outdated / incomplete documentation, and inappropriate planning. The survey identified 45 TD effects that are grouped into six categories. The main effects are delivery delay, rework, and low external quality. Conclusion: This paper organizes the identified causes and effects in probabilistic cause-effect diagrams, which provide a broad view of the state of the practice concerning test-related debt causes and effects.

Customer satisfaction and profit making are the two motives that define software quality; therefore, software industry uses new technologies like component-based software engineering, re-engineering, etc., to make their software production more profitable. The proposed mathematical model is executed under ISO/IEC 9126 quality assurance model and justifies the definition of software quality given by IEEE 1061(1998). The model calculates the degree of stakeholder satisfaction (Q) by combining the quality attributes and it is validated using Shuffled Frog-Leaping Algorithm (SFLA) which improved the result by 2.46%.

Technical debt in general refers to suboptimal decisions the practitioners make during software development that achieve short-term goals at the expense of long-term quality concerns. Architecture technical debt is a subset of technical debt, when software practitioners make wrong or sub-optimal decisions related to the architecture of the software. Identifying such architecture technical debt plays a crucial role in software quality. In the last decade, there were several methods proposed to identify architecture debts in the literature.In this study, we conduct a systematic literature review of methods that identify architecture technical debt by inspecting 28 primary studies published from 2011 to 2020. Based on the outcomes of our review: (1) design rule space and traceability graphs are the dominant techniques; (2) despite the increase of automated techniques in identifying architecture debt, pure manual methods using expert opinion is still popular; (3) majority of the approaches use code/version history to mine archictural technical debt; (4) the field is getting increasingly more attraction in the last five years.

We empirically examine the relationship between software design modularity and software quality in open source software (OSS) development projects. Conventional wisdom suggests that degree of software modularity affects software quality. An analysis of 203 software releases in 46 OSS projects hosted on SourceForge.net lends support for a more complex relationship between software modularity and software quality than conventional wisdom suggests. We find that software modularity is associated with reduced software complexity, an increased number of static software bugs, and a mixed relationship with the percentage of bugs closed. We do not find empirical evidence supporting any relationship between modularity and other measures of customer satisfaction. In addition to empirically testing the relationship between modularity and quality, we introduce new measures of software modularity and software quality. Implications are developed for the theory of modularity and the practice of software development.

The technical debt (TD) in a software project refers to the adoption of an inadequate solution from its design to the source code. When developers admit the presence of technical debt in the source code, through comments or commit messages, it is called self-admitted technical debt (SATD). This aspect of TD has been the subject of numerous research studies, which have investigated its distribution, the impact on software quality, and removal. Therefore, this work focuses on the relationship between SATD and TD values. In particular, the study aims to compare the admitted technical debt with respect to its objective measure. In fact, the trends of TD values during SATD removals have been studied. This was done thanks to the use of an SATD dataset and their related removals in four open source projects. Instead, the SonarQube tool was used to measure TD values. Thanks to this work, it turned out that SATD removals in a few cases correspond to an effective reduction of TD values, while in numerous cases, the classes indicated are removed.

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.

The development of software house have impact to the increment of software productivity circulating in the community, but the quality of software currently available is still questionable whether the software meet quality standards or not. White-box testing is a test that can be used to examine the internal structure of the program that access to the source code and can be done at any time in the software development cycle, so that the mistakes of the unwanted programs can be improved and can be a qualified software product. This research aimed to test the software using white box testing approach that can be used to find an unexpected error in the software are built. The research method in this research is the study of literature and experimental by testing the internal structure of the software that include control flow testing, branch testing, basis path testing, data flow testing, and loop testing. By doing white box testing, the improvement of the software can be done at any time and can produce qualified software. Keywords: software testing, white box testing, software quality.

One of the first steps towards the effective Technical Debt (TD) management is the quantification and continuous monitoring of the TD principal. In the current state-ofresearch and practice the most common ways to assess TD principal are the use of: (a) structural proxies—i.e., most commonly through quality metrics; and (b) monetized proxies—i.e., most commonly through the use of the SQALE (Software Quality Assessment based on Lifecycle Expectations) method. Although both approaches have merit, they seem to rely on different viewpoints of TD and their levels of agreement have not been evaluated so far. Therefore, in this paper, we empirically explore this relation by analyzing data obtained from 20 open source software projects and build a regression model that establishes a relationship between them. The results of the study suggest that a model of seven structural metrics, quantifying different aspects of quality (i.e., coupling, cohesion, complexity, size, and inheritance) can accurately estimate TD principal as appraised by SonarQube. The results of this case study are useful to both academia and industry. In particular, academia can gain knowledge on: (a) the reliability and agreement of TD principal assessment methods and (b) the structural characteristics of software that contribute to the accumulation of TD, whereas practitioners are provided with an alternative evaluation model with reduced number of parameters that can accurately assess TD, through traditional software quality metrics and tools.

Software development encompasses various factors beyond technical considerations. Neglecting non-technical elements like individuals, processes, culture, and social and organizational aspects can lead to debt-like characteristics that demand attention. Therefore, we introduce the non-technical debt (NTD) concept to encompass and explore these aspects. This indicates the applicability of the debt analogy to non-technical facets of software development. Technical debt (TD) and NTD share similarities and often arise from risky decision-making processes, impacting both software development professionals and software quality. Overlooking either type of debt can lead to significant implications for software development success. The current study conducts a comprehensive multivocal literature review (MLR) to explore the most recent research on NTD, its causes, and potential mitigation strategies. For analysis, we carefully selected 40 primary studies among 110 records published until October 1, 2022. The study investigates the factors contributing to the accumulation of NTD in software development and proposes strategies to alleviate the adverse effects associated with it. This MLR offers a contemporary overview and identifies prospects for further investigation, making a valuable contribution to the field. The findings of this research highlight that NTD’s impacts extend beyond monetary aspects, setting it apart from TD. Furthermore, the findings reveal that rectifying NTD is more challenging than addressing TD, and its consequences contribute to the accumulation of TD. To avert software project failures, a comprehensive approach that addresses NTD and TD concurrently is crucial. Effective communication and coordination play a vital role in mitigating NTD, and the study proposes utilizing the 3C model as a recommended framework to tackle NTD concerns.