Topic
Software quality assurance
About: Software quality assurance is a research topic. Over the lifetime, 1145 publications have been published within this topic receiving 16153 citations.
Papers published on a yearly basis
Papers
Book•
1 Jan 1992
TL;DR: This chapter discusses object-oriented software engineering as a process of change, management and reuse, and some of the methods used to develop and implement object- oriented software.
Abstract: Part 1. Introduction 1. System development as an industrial process Introduction A useful analogy System development characteristics Summary 2. The system life cycle Introduction System development as a process of change System development and reuse System development and methodology Objectory Summary 3. What is object-orientation? Introduction Object Class andinstance Polymorphism Inheritance Summary 4. Object-oriented system development Introduction Function/data methods Object-oriented analysis Object-oriented construction Object-oriented testing Summary 5. Object-oriented programming Introduction Objects Classes and instances Inheritance Polymorphism An example Summary Part II. Concepts 6. Architecture Introduction System development is model building Model architecture Requirements model Analysis model The design model The implementation model Test model Summary 7. Analysis Introduction The requirements model The analysis model Summary 8. Construction Introduction The design model Block design Working with construction Summary 9. Real-time specialization Introduction Classification of real-time systems Fundamental issues Analysis Construction Testing and verification Summary 10. Database Specialization Introduction Relational DBMS Object DBMS Discussion Summary 11. Components Introduction What is a component? Use of components Component management Summary 12. Testing Introduction On testing Unit testing Integration testing System testing The testing process Summary Part III. Applications 13. Case study: warehouse management system Introduction to the examples ACME Warehouse Management Inc. The requirements model The analysis model Construction 14. Case study: telecom Introduction Telecommunication switching systems The requirements model The analysis model The design model The implementation model 15. Managing object-oriented software engineering Introduction Project selection and preparation Project development organization Project organization and management Project staffing Software quality assurance Software metrics Summary 16. Other object-oriented methods Introduction A summary of object-oriented methods Object-Oriented Analysis (OOAD/Coad-Yourdon) Object-Oriented Design (OOD/Booch) Hierarchical Object-Oriented Design (HOOD) Object Modeling Technique (OMT) Responsibility-Driven Design Summary Appendix A On the development of Objectory Introduction Objectory as an activity From idea to reality References Index
3,755 citations
TL;DR: It is shown that software failures in a variety of domains were caused by combinations of relatively few conditions, which has important implications for testing.
Abstract: Exhaustive testing of computer software is intractable, but empirical studies of software failures suggest that testing can in some cases be effectively exhaustive. We show that software failures in a variety of domains were caused by combinations of relatively few conditions. These results have important implications for testing. If all faults in a system can be triggered by a combination of n or fewer parameters, then testing all n-tuples of parameters is effectively equivalent to exhaustive testing, if software behavior is not dependent on complex event sequences and variables have a small set of discrete values.
864 citations
1 Dec 2010
TL;DR: It is hypothesized that the limits of the standard learning goal of maximizing area under the curve (AUC) of the probability of false alarms and probability of detection “AUC(pd, pf)” are reached, and certain widely used learners perform much worse than simple manual methods.
Abstract: Building quality software is expensive and software quality assurance (QA) budgets are limited. Data miners can learn defect predictors from static code features which can be used to control QA resources; e.g. to focus on the parts of the code predicted to be more defective.
Recent results show that better data mining technology is not leading to better defect predictors. We hypothesize that we have reached the limits of the standard learning goal of maximizing area under the curve (AUC) of the probability of false alarms and probability of detection "AUC(pd, pf)"; i.e. the area under the curve of a probability of false alarm versus probability of detection.
Accordingly, we explore changing the standard goal. Learners that maximize "AUC(effort, pd)" find the smallest set of modules that contain the most errors. WHICH is a meta-learner framework that can be quickly customized to different goals. When customized to AUC(effort, pd), WHICH out-performs all the data mining methods studied here. More importantly, measured in terms of this new goal, certain widely used learners perform much worse than simple manual methods.
Hence, we advise against the indiscriminate use of learners. Learners must be chosen and customized to the goal at hand. With the right architecture (e.g. WHICH), tuning a learner to specific local business goals can be a simple task.
499 citations
Book•
1 Sep 2003
TL;DR: This theory derives and the most common implementation of quality-assurance is user-generated reviews, and this theory is applied to software quality management.
Abstract: Software quality assurance (SQA) is becoming increasingly important to the software and electronics industries as software systems become more complex and integrative. This book is designed to serve the three audiences who will be facing the SQA challenge: students at universities and colleges, participants in vocational training courses and software development and maintenance practitioners/professionals.
383 citations
26 May 2019
TL;DR: This paper proposes an end-to-end deep learning framework, named DeepJIT, that automatically extracts features from commit messages and code changes and use them to identify defects.
Abstract: Software quality assurance efforts often focus on identifying defective code. To find likely defective code early, change-level defect prediction - aka. Just-In-Time (JIT) defect prediction - has been proposed. JIT defect prediction models identify likely defective changes and they are trained using machine learning techniques with the assumption that historical changes are similar to future ones. Most existing JIT defect prediction approaches make use of manually engineered features. Unlike those approaches, in this paper, we propose an end-to-end deep learning framework, named DeepJIT, that automatically extracts features from commit messages and code changes and use them to identify defects. Experiments on two popular software projects (i.e., QT and OPENSTACK) on three evaluation settings (i.e., cross-validation, short-period, and long-period) show that the best variant of DeepJIT (DeepJIT-Combined), compared with the best performing state-of-the-art approach, achieves improvements of 10.36--11.02% for the project QT and 9.51--13.69% for the project OPENSTACK in terms of the Area Under the Curve (AUC).
248 citations
Related Topics (5)
Performance Metrics
| Year | Papers |
|---|---|
| 2025 | 14 |
| 2024 | 21 |
| 2023 | 37 |
| 2022 | 49 |
| 2021 | 52 |
| 2020 | 35 |