SOFTWARE DEFECT DETECTION

USING MACHINE LEARNING

PROJECT PHASE II REPORT

Submitted to Dr. Babasaheb Ambedkar Technological University, Lonere

In partial fulfillment of requirements for the degree of
BACHELOR OF TECHNOLOGY(Computer Engineering)

By

Siddhi Manoj Chaudhari

Rajeshwar Ravindra Swami
Om Pramod Sonawane
Neha Vikas Sonawane

Guide

Prof. A.Y. Suryawanshi

DEPARTMENT OF COMPUTER ENGINEERING

Khandesh College Education Society’s

COLLEGE OF ENGINEERING AND MANAGEMENT,
JALGAON
2024-2025
 Khandesh College Education Society’s
COLLEGE OF ENGINEERING AND MANAGEMENT, JALGAON

Department of Computer Engineering

CERTIFICATE

This is to certify that project entitled “Software Defect Detection Using Machine
Learning”, which is being submitted to Dr.Babasaheb Ambedkar Technological Univer-
sity,Lonere In partial fulfillment of the award of B.Tech,is the result of the work completed
by Siddhi Manoj Chaudhari, Om Pramod Sonawane, Rajeshwar Ravindra
Swami, and Neha Vikas Sonawane under my supervision and guidance within the
four walls of the institute during the academic year 2024-25 and the same has not sub-
mitted elsewhere for the award of any degree.

Date:
Place: Jalgaon

Prof. A.Y. Suryawanshi Prof. A.Y. Suryawanshi

Guide Head of Computer Department

Dr. S. R. Sugandhi
Principal Examiner
 Declaration
We hereby declare that,project entitled,“Software Defect Detection Using Machine
Learning” is carried out and written by us under guidance of Prof.A.Y.Suryawanshi,
HOD of Computer Engineering, Khandesh College Education Society’s College of Engi-
neering and Management, Jalgaon.This work has previously been formed on the basis for
the award of any degree or diploma or certificate nor has been submitted elsewhere for
the award of any degree or diploma or certificate.

Siddhi Manoj Chaudhari

Rajeshwar Ravindra Swami
Om Pramod Sonawane
Neha Vikas Sonawane

ii
 Acknowledgement
We would like to thank our guide Prof. A.Y. Suryawanshi for his support and subtle
guidance.We also thank for the valuable guidance of Head of Computer department Prof.
A.Y. Suryawanshi.We also thanks for the support of principal of K.C.E.S’s C.o.E.M.,
Jalgaon. We would like to thanks to all faculty members of Computer Engineering De-
partment and all friends for their co-operation and supports.
We also thank our family for their moral support and encouragement to fulfill my goals.
Lastly all the thanks belong to the almighty for his blessings

Siddhi Manoj Chaudhari

Rajeshwar Ravindra Swami
Om Pramod Sonawane
Neha Vikas Sonawane

iii
 Abstract
Traditional software reliability growth models only consider defect discovery data, yet the
practical concern of software engineers is the removal of these defects. Most attempts to
model the relationship between defect discovery and resolution have been restricted to
differential equation-based models associated with these two activities. However, defect
tracking databases offer a practical source of information on the defect lifecycle suitable
for more complete reliability and performance models.Software Engineering is a branch of
computer science that enables tight communication between system software and training
it as per the requirement of the user. We have selected seven distinct algorithms from
machine learning techniques and are going to test them using the datasets acquired for
NASA public promise repositories. The results of our project enable the users of this
software to bag up the defects are selecting the most efficient of given algorithms in doing
their further respective tasks, resulting in effective results.
Keywords: Software quality metrics, Software defect prediction, Software fault predic-
tion, Machine learning algorithms.

iv
 Contents
Certificate i

Declaration ii

Acknowledgement iii

Abstract iv

List of Figures 1

1 INTRODUCTION 2
1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Previously Existing System . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Report Oragnisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 LITERATURE SURVEY 7
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Presently Available System . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 SYSTEM REQUIREMENT 13
3.1 Software Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Fuctional Requirements . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Non-Fuctional Requirements . . . . . . . . . . . . . . . . . . . . . 13
3.2 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

v
4 SYSTEM DESIGN 15
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 DFD Level-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 DFD Level-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 DFD Level-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Structural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.3 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.5 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Behavioral Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.3 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5.4 State Machine Diagram . . . . . . . . . . . . . . . . . . . . . . . 28
4.5.5 Communication Diagram . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 IMPLEMENTATION 31
5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 System Setup and Implementation Details . . . . . . . . . . . . . 31
5.1.3 Dataset Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.4 Supabase Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.5 Machine Learning Model . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.6 Authentication Flow . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.7 Data Storage and Access Control . . . . . . . . . . . . . . . . . . 34
5.1.8 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

vi
 5.3 Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 RESULT AND DISCUSSION 42

6.1 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.2 Team Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.3 Challenges and Limitations . . . . . . . . . . . . . . . . . . . . . 47
6.2.4 Practical Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.5 Future Development . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.6 Reflection on Project Successes . . . . . . . . . . . . . . . . . . . 48

References 51

vii
 List of Tables
5.1 Software Metrics Description . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Test Cases for Major Functionalities . . . . . . . . . . . . . . . . . . . . 38
5.3 Cost Estimation Using Software Metrics . . . . . . . . . . . . . . . . . . 40
5.4 Component Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

viii
 List of Figures
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 DFD Level-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 DFD Level-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 DFD Level-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.8 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.9 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.10 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.11 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.12 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.13 State Machine Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.14 Communication Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 Decision Tree Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Detection History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1 Register Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Log-In Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Metrics Input Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4 Report Download Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.5 CSV File Upload Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1
 Chapter 1
INTRODUCTION
Software defect detection using machine learning is a technique where algorithms
are trained to identify bugs or errors in code. Instead of manually checking the code,
the machine learning model analyses patterns from past data, such as code features and
previous defects, to predict where new bugs might occur, helping developers find and fix
issues more efficiently.
Software defects are anomalies or errors in computer software that cause it to behave
unexpectedly or incorrectly. Detecting these defects early in the development process can
significantly reduce costs, improve software quality, and enhance user satisfaction. Tradi-
tional testing methods, such as manual testing and static code analysis, have limitations
in terms of efficiency and coverage. To address these challenges, machine learning has
emerged as a promising approach for software defect detection
Machine learning algorithms can analyze vast amounts of data, identify patterns,
and make predictions with high accuracy. By leveraging historical data on software
defects, machine learning models can learn to recognize characteristics associated with
defective code, enabling proactive defect detection
This project aims to explore the application of machine learning techniques for soft-
ware defect detection. By analyzing various factors such as code metrics, commit his-
tory,and test results, we will develop a machine learning model capable of accurately
predicting the likelihood of code defects. This model can be integrated into the software
development process to assist developers in identifying potential issues early on, thereby
improving overall software quality
This project is a Next.js application that implements a machine learning-based soft-
ware defect detection system. It uses Supabase for authentication and data storage.

1.1 Objective
• Reduce effort and time taken for defect detection.
• Lower costs associated with software testing and bug fixes.
• Improve software quality by early defect prediction.
• Machine learning algorithms are used for both training and testing defect prediction
models.

2
 CHAPTER 1. INTRODUCTION

• The proposed SVM algorithm is a supervised machine learning model.

• Develop an efficient machine learning model that predicts the number of software
bugs.
• The system aims to provide accurate bug predictions to improve software quality.

1.2 Problem Definition

Software development is complex and prone to errors, leading to potential bugs
and system failures. Traditional methods for detecting defects often involve manual code
reviews and static analysis, which can be time-consuming and may miss some issues. This
project aims to solve the problem of inefficient and incomplete bug detection by applying
machine learning techniques. By leveraging historical data on code and previous defects,
the machine learning model will be trained to automatically identify potential defects
early in the development process. This automated approach seeks to improve the accuracy
of defect detection, reduce the time and effort needed for manual reviews, and ultimately
enhance the quality of the software. Addressing this problem is crucial because it can
lead to faster development cycles, reduced costs, and more reliable software, benefiting
both developers and end-users.

1.3 Proposed System

The proposed system is a machine learning-based software tool designed to proac
tively identify potential defects in codebases. By analyzing various code metrics, commit
history, and test results, the tool will provide developers with early warnings of potential
issues, enabling them to address problems before they escalate. The system will consist
of modules for data collection, preprocessing, feature engineering, model development,
prediction, and visualization. By leveraging the power of machine learning, the tool
aims to improve software quality, reduce development costs, and enhance overall software
reliability.

1.4 Previously Existing System

• Static Analysis Tools: Traditional static analysis tools such as FindBugs and
PMD analyze source code to detect potential bugs based on predefined rules. While
effective for specific types of errors, these tools lack the ability to predict defects
based on evolving patterns in the code.

KCES’s CoEM, JALGAON 3

 CHAPTER 1. INTRODUCTION

• Defect Prediction Models: Early machine learning-based models, such as those

developed by Menzies et al. (2007), rely heavily on static code metrics like cyclo-
matic complexity and lines of code. These models are constrained by their inability
to adapt to dynamic software changes.
• Cross-Version Defect Prediction: As mentioned in the literature, Cross-Version
Defect Prediction (CVDP) systems predict defects based on previous versions of
software. Though useful, they often face issues with data inconsistency and class
imbalance.
• Ensemble Methods: More recent systems employ ensemble machine learning
methods like Random Forests and Gradient Boosting to improve defect detection
accuracy by aggregating predictions from multiple models. However, these systems
can be computationally expensive and difficult to interpret.

1.5 Scope
This project focuses on improving software defect prediction using machine learning tech-
niques. The project will involve collecting and analyzing historical software defect data,
selecting appropriate machine learning algorithms, and evaluating the model’s perfor-
mance. While the focus is on enhancing defect prediction, the project will not include
real-time monitoring or the development of an extensive user interface, prioritizing model
accuracy and effectiveness instead. The scope includes:
• Data Collection: Gathering historical defect data and relevant software metrics
from multiple projects to train and validate the machine learning model. This data
will be used to identify patterns and features associated with software defects.
• Model Development: Creating and training machine learning models to predict
defects. This involves selecting appropriate algorithms, tuning parameters, and
validating the model’s performance using various evaluation metrics.
• Implementation and Testing: Implementing the developed model in a testing
environment to evaluate its effectiveness in predicting defects. This will include
comparing the model’s predictions with actual defect occurrences to assess accuracy
and reliability.

KCES’s CoEM, JALGAON 4

 CHAPTER 1. INTRODUCTION

1.6 Advantages and Disadvantages

1.6.1 Advantages
• Early Defect Detection: Machine learning models can identify potential defects
early in the development process, reducing the cost of remediation and improving
overall software quality.
• Improved Accuracy: Machine learning algorithms can learn complex patterns in
code that may be difficult for human testers to detect, leading to higher accuracy
in defect prediction.
• Scalability: Machine learning models can handle large codebases and can be easily
scaled to accommodate growing projects.
• Automation: Machine learning can automate the process of defect detection, re-
ducing the workload for developers and testers.
• Continuous Improvement: Machine learning models can learn from new data
over time, improving their accuracy and adapting to changes in the code base.

1.6.2 Disadvantages
• Data Dependency: The performance of machine learning models is highly depen-
dent on the quality and quantity of the training data. Insufficient or biased data
can lead to inaccurate predictions.
• Complexity: Implementing and maintaining machine learning models can be com-
plex, requiring specialized knowledge and skills.
• Interpretability: Machine learning models can be difficult to interpret, making it
challenging to understand why a particular prediction was made. This can hinder
debugging and troubleshooting efforts.
• False Positives and Negatives: Machine learning models may produce false
positives (predicting a defect where none exists) or false negatives (failing to predict
a defect that does exist). This can lead to wasted effort or missed defects.
• Overfitting: Machine learning models can become overfitted to the training data,
leading to poor performance on new, unseen data. This can be mitigated through
techniques like cross-validation and regularization.

KCES’s CoEM, JALGAON 5

 CHAPTER 1. INTRODUCTION

1.7 Report Oragnisation

In Chapter Two, we examine existing software defect prediction models, analyzing var-
ious machine learning techniques and algorithms used in defect detection. We review
approaches such as static code analysis, early defect prediction models, and cross-version
defect prediction methods to understand their strengths and limitations and identify areas
for improvement in accuracy and adaptability.
Chapter Three outlines the requirements for the project, detailing both hardware
and software specifications. We also conduct a feasibility study to ensure the model’s
compatibility, scalability, and efficiency across different systems.
In Chapter Four, we describe the architecture of the defect detection model using
structured diagrams, including UML use case, class, and sequence diagrams, to illustrate
the components, interactions, and data flow within the system. This architectural analysis
provides a clear framework for model development and integration.
Chapter Five focuses on the implementation of the model, discussing the selection
of machine learning algorithms, data preprocessing steps, and hyperparameter tuning to
achieve high prediction accuracy. We also cover the integration of libraries and tools
essential for defect detection, emphasizing automation and scalability.
Finally, in Chapter Six, we evaluate the model’s performance, assessing metrics such
as precision, recall, and F1-score to determine its effectiveness in accurately predicting
software defects. This chapter also explores the system’s limitations and potential areas
for future enhancements, ensuring the model’s continuous improvement and adaptation
to changing software trends.

1.8 Summary
This chapter introduces the project on ”Software Defect Detection Using Machine
Learning,” covering its objective to enhance defect detection accuracy using machine
learning. It outlines the problem of inefficient traditional methods, proposes an auto-
mated ML-based solution, and contrasts it with past approaches. The chapter discusses
the project’s scope, key advantages, and limitations, and concludes with an outline of the
report’s structure for reader guidance.

KCES’s CoEM, JALGAON 6

 Chapter 2
LITERATURE SURVEY
2.1 Background
• Paper 1: A Critique of Software Defect Prediction Models(2021):
• Author: Norman E. Fenton
• Abstract: This paper focuses on how to detect a defect in software in effecient
way.Many organizations want to predict the number of defects (faults) in software
systems, before they are deployed, to gauge the likely delivered quality and main
tenance effort. To help in this numerous software metrics and statistical model
shave been developed, with a correspondingly large literature.They provide a crit
ical review of this literature and the state-of-the-art. Most of the wide range of
prediction models use size and complexity metrics to predict defects. Others are
based on testing data, the “quality” of the development process, or take a multi
variate approach. The authors of the models have often made heroic contributions
to a subject otherwise bereft of empirical studies. However, there are a number
of serious thepractical problems in many studies. The models are weak because of
their inability to cope with the, as yet, unknown relationship between defects and
failures. There are fundamental statistical and data quality problems that under
mine model validity. More significantly many prediction models tend to model only
part of the underlying problem and seriously misspecify it. To illustrate these points
the“Goldi lock’s Conjecture,” that there is an optimum module size, is used to show
the considerable problems inherent in current defect prediction approaches. Care
ful and considered analysis of past and new results shows that the conjecture lacks
support and that some models are misleading.So they recommend holistic models
for software defect prediction, using Bayesian Belief Networks, as alternative ap
proaches to the single-issue models used at present. They also argue for research
into a theory of “software decomposition” in order to test hypotheses about defect
introduction and help construct a better science of software engineering
• Paper 2: CDS: A Cross–Version Software Defect Prediction Model With
Data Selection.(2022)

7
 CHAPTER 2. LITERATURE SURVEY

• Author:JIE ZHANG1,2, (GraduateStudent Member, IEEE),JIAJINGWU1,2,(Se

nior Member, IEEE), CHUAN CHEN (Member, IEEE), ZIBIN ZHENG , (Senior
Member, IEEE), AND MICHAEL R. LYU3, (Fellow, IEEE).
• Abstract: Abstract:This approach leverages defect data from previous versions of
a software project to predict defects in the current version.CVDP is increasingly
relevant as software projects often undergo multiple iterations, and maintaining
prediction ac curacy across versions is challenging. The authors identify two crit-
ical issues: data distribution differences and class overlapping. These issues can
complicate defect prediction, making it difficult to apply models trained on previ-
ous versions to cur rent ones. Addressing these challenges requires sophisticated
techniques that can adapt to the evolving nature of software projects and manage
the variability in defect data across versions.. In this paper, we address these two
issues by solving a version selection problem via a Cross–version model with Data
Selection (CDS). The proposed CDS is a novel framework which treats the defect
prediction of existing and new files indifferent ways.For the existing files,we propose
an Clustering–based Multi–Version Classifier(CMVC),which can automatical select
the training data from the most relevant and noise-free versions by assigning the
higher weights than the others.We proposed a Weighted Sampling Model (WSM)
for the new files which have never appeared in previous version by in corporating
the outputs of CMVC.We evaluate the proposed CDS model on28 version across
software projects,and the ex perimental results demonstrate that CDS outperforms
the baseline methods and a state of-the-art approach in terms of three prevalent
performance indicators.
• Paper 3: Reliability Growth of Open Source Software using Defect Anal-
ysis.(2019)
• Author:Sharifah Mashita,Syed-Mohamad and Tom McBride.
• Abstract: In this paper,they examine two active and popular open source products
to observe whether or not open source software has a different defect arrival rate
than software developed in-house. The evaluation used two common models of
reliability growth models; concave and Sshaped and this analysis shows that open
source has a different profile of defect arrival. Further investigation indicated that
low level design instability is a possible explanation of the different defect growth

KCES’s CoEM, JALGAON 8

 CHAPTER 2. LITERATURE SURVEY

profile.
• Paper 4: Software Defect Prediction Using Machine Learning Techniques
(2018):
• Author::C.Lakshmi Prabha (Computer Science and Engineering Thiagarajar Col-
lege of Engineering Madurai, India ), lakshmiprabha (student tce.edu ),Dr.N.shivkumar(
Computer Science and Engineering Thiagarajar College of Engineering Madurai)
• Abstract: Software defect prediction provides development groups with observable
outcomes while contributing to industrial results and development faults predicting
defective code areas can help developers identify bugs and organize their test activ
ities. The percentage of classification providing the proper prediction is essential
for early identification. Moreover, software-defected data sets are supported and at
least partially recognized due to their enormous dimension. This Problem is han
dled by hybridized approach that includes the PCA, randomforest, na¨ıve bayes
and the SVM Software Framework, which as five datasets as PC3, MW1, KC1,
PC4, and CM1, are listed in software analysis using the weka simulation tool. A
systematic research analysis is conducted in which parameters of confusion, preci
sion, recall, recognition accuracy, etcAre measured as well as compared with the
prevailing schemes. The analytical analysis indicates that the proposed approach
will provide more useful solutions for device defects prediction. This paper high-
lights the use of cloud services, such as Firebase and AWS, for building scalable
mobile applications. The authors focused on how real-time databases, user authen-
tication, and cloud storage are vital for managing large volumes of data efficiently.
In particular, Firebase’s real-time database offers seamless synchronization across
all devices, making it an ideal choice for mobile applications that require constant
data updates. These findings are directly relevant to our project, as we plan to use
Firebase to handle user data, book listings, and chat communication in real-time
• Paper 5: BRACE: Cloud-based Software Reliability Assurance.(2017)
• Author:Kazuhira Okumoto,Nokia Dublin,Abhaya Asthana,Rashid Mijumbi.
• Abstract:The evolution towards virtualized network functions (VNFs) is expected
to enable service agility within the telecommunications industry. To this end, the
software (or VNFs) from which such services are composed must be developed and
delivered over very short time scales. In order to guarantee the required levels of

KCES’s CoEM, JALGAON 9

 CHAPTER 2. LITERATURE SURVEY

software quality within such tight schedules, software reliability tools must evolve.
In particular, the tools should provide development teams spread across geography
and time with reliable and actionable insights regarding the development process.In
this paper, they present BRACE– a cloud-based, integrated, onestop center for soft
ware tools. BRACE is home to tools for software reliability modeling, testing,and
defect analysis each of which is provided as-a-service to development teams.Initial
implementation of BRACE includes a software reliability growth modelling (SRGM)
tool. The SRGM tool is currently being used to enable real-time prediction of the
total number of defects in software being developed, and for providing the required
analytics and metrics to enable managers make informed decisions regarding allo
cation for defect correction so as to meet set deadlines.
• Paper 6:Connecting Software Reliability Growth Models to Software De-
fect Tracking (2017)
• Author: Esra Var,Ying Shi
• Abstract: Traditional software reliability growth models only consider defect dis
covery data, yet the practical concern of software engineers is the removal of these
defects. Most attempts to model the relationship between defect discovery and res
olution have been restricted to differential equation-based models associated with
these two activities. However, defect tracking databases offer a practical source of
information on the defect lifecycle suitable for more complete reliability and perfor
mance models. This paper explicitly connects software reliability growth models to
software defect tracking. Data from a NASA project has been employed to develop
differential equation-based models of defect discovery and resolution as well as dis
tributional and Markovian models of defect resolution. The states of the Markon
model represent thirteenunique tages of the NASA softwar edefect lifecycle.Both
transition probabilities and transition time distributions are computed from the de
fect database. Illustrations compare the predictive and computational performance
of alternative approaches. The results suggest that the simple distributional ap
proach achieves the best trade off between these two performance measures, butthat
enhanced data collection practices could improve the utility of the more ad vanced
approaches and the inferences they enable.
• Paper 7:Study on Software Defect Prediction Model Based on Improved

KCES’s CoEM, JALGAON 10

 CHAPTER 2. LITERATURE SURVEY

BP Algorithm(2019)
• Author::Cundong Tang1,Li Chen1,Zhiping Wang,Yuzhou Sima.
• Abstract:Software defect is an important indicator to evaluate software product
quality. To reduce the defects of software products and to improve the quality
of software is always the goal of software development. This paper combines the
simulated annealing (SA) algorithm and JCUDA technology to improve the BP
algorithm,to build an improved software defect prediction model with higher pre
diction accuracy. The experimental results show that the software defect prediction
model based on improved BP algorithm is able to accurately predict the software
defects, which is better than the traditional BP algorithm.

2.2 Presently Available System

Currently, several systems and methodologies are available for software defect prediction,
each leveraging distinct approaches and technologies to improve prediction accuracy and
software reliability. Key existing systems include:
• Static Analysis Tools: Traditional static analysis tools, such as FindBugs and
PMD, analyze source code to identify potential bugs based on predefined rules and
patterns. These tools are effective for detecting specific, rule-based issues within
code. However, they often lack the ability to adapt to evolving patterns in software
projects, which limits their effectiveness for long-term defect prediction.
• Early Machine Learning Models: Early models for defect prediction, such
as those introduced by Menzies et al. (2007), utilize machine learning algorithms
trained on software metrics like cyclomatic complexity, lines of code, and code churn.
These models provide a statistical approach to defect prediction, though they are
often limited by their dependence on static metrics and inability to accommodate
dynamic code changes.
• Cross-Version Defect Prediction (CVDP): Cross-version defect prediction
models, which utilize data from previous software versions to predict defects in
newer releases, have shown promise for managing iterative projects. However, they
face challenges due to data inconsistency and class imbalance across different soft-
ware versions, which can reduce prediction accuracy.
• Ensemble Learning Methods: Recent systems have started using ensemble

KCES’s CoEM, JALGAON 11

 CHAPTER 2. LITERATURE SURVEY

learning methods, such as Random Forests and Gradient Boosting, to combine

multiple machine learning models for defect prediction. By aggregating predictions
from multiple models, ensemble methods can improve prediction accuracy. How-
ever, these systems are often computationally expensive and may be difficult to
interpret, complicating debugging efforts.
• Deep Learning Approaches: More advanced deep learning techniques, including
neural networks and recurrent neural networks (RNNs), have been applied to soft-
ware defect prediction. These models can automatically learn complex patterns in
data, which is particularly useful for large-scale projects. Nevertheless, deep learn-
ing models require substantial computational resources and large datasets, and they
may suffer from overfitting if not carefully managed.
Each of these systems has contributed to the evolution of defect prediction method-
ologies, but limitations persist. Current methods often struggle with data quality issues,
model interpretability, and scalability in large or rapidly changing software projects.
These challenges highlight the need for further innovation, particularly in developing
adaptable models that can continuously

2.3 Summary
In this chapter, discussed the background history and related work of Software Defect
Detection.Next chapter will introduce the system analysis of project requirement.

KCES’s CoEM, JALGAON 12

 Chapter 3
SYSTEM REQUIREMENT
3.1 Software Requirement
• Operating System: Windows 10
• Programming Language:
1. Frontend: Next.js, React, Tailwind CSS, Recharts, Framer Motion
2. Backend: Python,Next.js API routes, Supabase, PostgreSQL
• IDE:Spyder

3.1.1 Fuctional Requirements

The functional requirements describe the core functionalities of the software defect de-
tection system that will be implemented in this project. These requirements include the
specific actions that the system must be able to perform.
The functional requirements specify the core capabilities of the software defect de-
tection system to be implemented in this project. The system must accept code as input,
preprocess it for feature extraction, and utilize machine learning algorithms to classify
code segments as defective or non-defective. It should display the defect detection results
clearly, indicating whether a defect is present. Additionally, the system should provide a
detailed report on the detected defect types and possible causes. The system must handle
various programming languages or specific types as needed and allow authorized users to
access the results and view the underlying data models. Finally, the system should offer
an option to retrain the model with new data to enhance detection accuracy over time.

3.1.2 Non-Fuctional Requirements

The Performance Requirements of this software dictate that each function and mod-
ule must perform optimally, enabling users to work efficiently. Fast encryption of data is
essential for secure handling of information, and the performance of the virtual environ-
ment provided by the software should be rapid to meet user expectations.
Safety Requirements are addressed through a modular design, allowing errors to be
detected and corrected with ease. This modular approach also facilitates straightforward
installation and updating of new functionality as needed.

13
 CHAPTER 3. SYSTEM REQUIREMENT

The Software Quality Attributes encompass several key areas. Adaptability ensures
the software is accessible and usable by all users, while Availability guarantees it is freely
accessible, providing easy availability for everyone. Maintainability is another critical
factor; if any issues arise post-deployment, they can be easily resolved by the developer.
The system’s strong Reliability further enhances user trust by maintaining high perfor-
mance standards, and User Friendliness is ensured through a GUI interface, which makes
interacting with the software intuitive and accessible.
Integrity and Security are also prioritized, with access control features to prevent
unauthorized data access and multiple authentication phases to secure user data. Finally,
Testability is considered, ensuring that the software undergoes comprehensive testing to
meet quality and performance standards across all functional aspects.

3.2 Hardware Requirements

• Hardware Interfaces: RAM: 8 GB
• Hard Disk: 256 GB
• Processor: Intel i5 Processor

3.3 Summary
In this chapter, discussion about the project requirements of the system, Functional and
Non-functional requirements, Hardware requirements is done. Next chapter will introduce
the detail Information of System Design.

KCES’s CoEM, JALGAON 14

 Chapter 4
SYSTEM DESIGN
System design is the process of defining and developing systems to meet the specified
requirements of the user. The basic purpose of system design is to understand the com-
ponent parts and how they interact to fulfill the intended functionalities. In this chapter,
Section 4.1 explains the architecture of the our project, Section 4.2 presents Data Flow
Diagram of the system, Section 4.3 outlines the the Entity-Relationship (ER) Diagram,
Section 4.4 describes the Structural Diagrams and Section 4.5 Behavioral Diagrams to
provide a comprehensive view of system interactions and structure.

4.1 System Architecture

Figure 4.1 System Architecture

As shown in Fig.[4.1], this architecture diagram illustrates the process flow of the
”Software Defect Detection Using Machine Learning” system. The user inputs a software
attribute into the system, which triggers a series of processing steps within the Software
Defect Identifier System.The process begins with a pre-trained dataset containing text-
based software attributes and historical defect data. First, the input data undergoes a

15
 CHAPTER 4. SYSTEM DESIGN

”Processing” phase, where raw information is refined for further analysis. Following this,
the system performs ”Feature Extraction,” identifying key attributes from the input data
that are essential for detecting defects.
Once features are extracted, they are fed into the ”SVM Algorithm,” which acts as
the core of the defect detection model. The Support Vector Machine (SVM) algorithm
evaluates the input attributes based on the learned patterns from the training dataset,
determining if the software contains potential defects.
Finally, the system outputs the results, which indicate whether the software is de-
fected or not, and this outcome is displayed to the user. The entire workflow allows for an
automated approach to identifying software defects based on machine learning principles,
specifically using SVM as the classification algorithm.

4.2 Data Flow Diagram

A Data Flow Diagram (DFD) shows how data moves within a system, outlining
inputs, outputs, storage points, and paths between them using symbols like rectangles
and arrows. DFDs range from high-level overviews to detailed mappings of data processes
and are helpful for both designing new systems and analyzing existing ones. They are
especially useful for visually conveying complex information to technical and non-technical
audiences, though they’re less commonly used now for real-time or database-focused
applications.

4.2.1 DFD Level-0

Figure 4.2 DFD Level-0

As shown in Fig.[4.2], this Data Flow Diagram (DFD) Level 0 provides a high-
level overview of the ”Software Defect Detection Using Machine Learning” system. The
diagram illustrates the three main components of the system: User, Processing, and
Detection.
The process begins with the ”User” providing input, typically in the form of software

KCES’s CoEM, JALGAON 16

 CHAPTER 4. SYSTEM DESIGN

attributes or data relevant to defect detection. This input is directed to the ”Processing”
module, where essential steps such as data cleaning, preprocessing, and feature extraction
occur. This module prepares the data to ensure it is in an optimal format for analysis.
Once the data is processed, it flows to the ”Detection” component, where machine
learning algorithms are applied to determine whether any software defects are present.
This component performs the defect analysis and generates results, which can be pre-
sented back to the user. The DFD Level 0 diagram simplifies the overall flow, highlighting
the core functional stages without diving into specific technical details.

4.2.2 DFD Level-1

As shown in Fig.[4.3], this Data Flow Diagram (DFD) Level 1 provides a detailed break-
down of the ”Software Defect Detection Using Machine Learning” system, expanding on
the processing steps involved in detecting software defects.
The process starts with the ”User” supplying input, typically in the form of soft-
ware attributes or relevant data for defect analysis. This input is directed to the main
processing module, which consists of three key stages:

Figure 4.3 DFD Level-1

1. Preprocessing: In this stage, the raw data is cleaned and standardized to ensure

KCES’s CoEM, JALGAON 17

 CHAPTER 4. SYSTEM DESIGN

consistency and to remove any irrelevant or noisy information. This step is essential
to make the data suitable for analysis.
2. Feature Extraction: After preprocessing, significant attributes or features are ex-
tracted from the data. These features represent key characteristics that will help
the machine learning model in identifying patterns associated with software defects.
3. Classification: In this final stage, the processed and extracted features are fed into a
classification model, typically a machine learning algorithm, to determine whether
a software defect is present. This classification is based on the learned patterns
from a trained dataset.
The output from the classification process flows to the ”Detection” component, which
holds the final decision on whether a defect is detected in the software. This DFD Level
1 diagram provides a more granular view of the system, emphasizing each processing step
crucial for defect detection.

4.2.3 DFD Level-2

As shown in Figure [4.4], the system begins with Preprocessing, where the input software
code undergoes tokenization, data normalization, and code formatting. This step prepares
the code for further analysis.

Figure 4.4 DFD Level-2

KCES’s CoEM, JALGAON 18

 CHAPTER 4. SYSTEM DESIGN

Next, Feature Extraction takes place, where various features are extracted from the
preprocessed code. These features can include code metrics (e.g., cyclomatic complexity,
Halstead metrics), syntactic features (e.g., control flow, data flow), and semantic features
(e.g., function calls, variable usage).
These extracted features are then fed into a Classification module. This module
employs machine learning algorithms to classify the software code as either defective or
non-defective. Additionally, it may also be able to classify the type of defect, if applicable.
Finally, the Detection module receives the classification results and presents them to
the user. This could involve highlighting potential defects in the code, providing a report
with defect probabilities, or suggesting specific code improvements.
This DFD level 2 diagram outlines a comprehensive approach to software defect
detection using machine learning. By preprocessing the code, extracting relevant features,
and applying classification algorithms, the system aims to identify potential defects early
in the development cycle, leading to improved software quality and reliability.

4.3 ER Diagram
As shown in Figure [4.5], the ER diagram illustrates the data entities and relationships
involved in the software defect detection system.
• Entities:
• User: Represents users of the system, including both developers and administrators.
• Code File: Represents the source code files that are uploaded for analysis.
• Dataset: Represents the dataset generated from the processed code files.
• Result: Represents the results of the defect detection process, including defect
details and classifications.
• Admin: Represents the administrators who manage the system.
• Relationships:
• User - Code File: A one-to-many relationship, where one user can upload multiple
code files.
• Code File - Processing: A one-to-one relationship, where each code file is processed
once.
• Processing - Dataset: A one-to-one relationship, where the processing step generates
one dataset.

KCES’s CoEM, JALGAON 19

 CHAPTER 4. SYSTEM DESIGN

Figure 4.5 ER Diagram

• Dataset - Classification: A one-to-one relationship, where the dataset is classified

once.
• Result - Defect Details: A one-to-one relationship, where each result has associated
defect details.
• Result - Defect ID: A one-to-one relationship, where each result has a unique defect
ID.
• Admin - Manage: A one-to-many relationship, where one admin can manage multi-
ple users. This ER diagram provides a clear overview of the data entities and their
relationships within the software defect detection system, aiding in database design
and data management.

4.4 UML Diagrams

UML is a short form for Uni ed Modelling Language, is a standardized modelling language
consisting of an integrated set of diagrams, developed to help system and soft ware
developers for specifying, visualizing, constructing, and documenting the artefacts of
software systems, as well as for business modelling and other non-software systems. The
UMLrepresents a collection of best engineering practices that have proven successful
in the modelling of large and complex systems.The two most broad categories that en
compass all other types are Behavioural UML diagram and Structural UML diagram.The
UML is a very important part of developing object-oriented software and the software
development process.

KCES’s CoEM, JALGAON 20

 CHAPTER 4. SYSTEM DESIGN

4.4.1 Structural Design

Structural diagrams depict a static view or structure of a system. It is widely used
in the documentation of software architecture. It embraces class diagrams, composite
structure diagrams, component diagrams, deployment diagrams, object diagrams, and
package diagrams. It presents an outline for the system. It stresses the elements to be
present that are to be modeled

4.4.2 Class Diagram

As shown in Figure [4.6], the class diagram illustrates the object-oriented design of the
software defect detection system.
• Classes:
• User: Represents a user of the system, with attributes such as user ID and name,
and methods for interacting with the system.
• Preprocessing: Represents the preprocessing module, with attributes for storing in-
termediate results and methods for performing preprocessing tasks like tokenization,
data normalization, and code formatting.
• Feature Extraction: Represents the feature extraction module, with attributes for
storing extracted features and methods for extracting features like code metrics,
syntactic features, and semantic features.
• Classification: Represents the classification module, with attributes for storing clas-
sification results and methods for applying machine learning algorithms to classify
software code.
• Segmentation: Represents the segmentation module, with attributes for storing
segmentation results and methods for segmenting code into smaller units for more
focused analysis.
• Result: Represents the final result of the defect detection process, with attributes
for storing defect details and classification results.
• Relationships:
• User - Preprocessing: The User class interacts with the Preprocessing class to ini-
tiate the preprocessing process.
• Preprocessing - Feature Extraction: The Preprocessing class passes the preprocessed
code to the Feature Extraction class for feature extraction.

KCES’s CoEM, JALGAON 21

 CHAPTER 4. SYSTEM DESIGN

Figure 4.6 Class Diagram

• Feature Extraction - Classification: The Feature Extraction class passes the ex-
tracted features to the Classification class for classification.
• Classification - Segmentation: The Classification class may interact with the Seg-
mentation class to further analyze specific code segments.
• Classification - Result: The Classification class generates the final Result, which
includes defect details and classification results.
This class diagram provides a clear overview of the system’s components and their inter-
actions, aiding in the design and development of the software defect detection system.

4.4.3 Object Diagram

As shown in Figure [4.7], the object diagram provides a visual representation of the
key components and their relationships in the software defect detection system. The
application code serves as the input to the preprocessing module, which prepares the
code for analysis. The preprocessed code is then used to train the machine learning
model, which can be a neural network or other suitable algorithm. The trained model is
used to detect potential defects in the code and classify them into specific categories. The
performance of the system is evaluated using various metrics, such as accuracy, precision,

KCES’s CoEM, JALGAON 22

 CHAPTER 4. SYSTEM DESIGN

recall, and F1-score. These metrics help assess the effectiveness of the defect detection
process. Additionally, the system utilizes techniques like SVM, DT, and tokenization to
aid in the analysis and classification of code defects.

Figure 4.7 Object Diagram

4.4.4 Component Diagram

Figure 4.8 Component Diagram

As shown in Figure [4.8], the component diagram provides a high-level overview of

the architectural components involved in the software defect detection system. The user
interface allows users to interact with the system, uploading code and viewing results.
The software application interface acts as a bridge between the user interface and the
core system components. The code repository stores and manages the code files. The

KCES’s CoEM, JALGAON 23

 CHAPTER 4. SYSTEM DESIGN

data analyzer processes the code files, extracting relevant features and generating labeled
datasets. The data classification component employs machine learning models to classify
the code based on defect likelihood. The machine learning module provides the underlying
algorithms and techniques for classification. The tokenization component breaks down
the code into smaller units for analysis. Finally, the data processing component handles
the preprocessing of data, ensuring it is suitable for analysis. These components work
together to effectively detect and identify potential defects in software code.

4.4.5 Deployment Diagram

As shown in Figure [4.9], the deployment diagram illustrates the deployment view of the
software defect detection system.
It begins with the Code Repository, where the codebase is stored and sourced for
analysis. Data from the repository is gathered by the Data Collection component, which
temporarily stores raw code data for processing. This data is then organized and format-
ted by the Data Collection Engine before being transferred to the Database, which acts
as a central repository for all collected and processed data.
The Defect Detection Engine serves as the main analysis unit, retrieving data from
the database to identify potential software defects. This engine may leverage algorithms
or machine learning models to detect errors within the codebase. Additionally, a Defect
Data Collection Engine refines and provides specific defect-related data, enhancing the
accuracy of the defect detection engine’s analysis.
Overall, the system is designed to automate the process of data collection, processing,
and defect detection, ensuring efficient identification and storage of software defects.

Figure 4.9 Deployment Diagram

KCES’s CoEM, JALGAON 24

 CHAPTER 4. SYSTEM DESIGN

4.5 Behavioral Design

Behavioral diagrams portray a dynamic view of a system or the behavior of a sys tem,
which describes the functioning of the system. It includes use case diagrams, state dia-
grams, and activity diagrams. It de nes the interaction within the system.

4.5.1 Use Case Diagram

As shown in Figure [4.10], the use case diagram illustrates the various interactions between
the user and the software defect detection system.

Figure 4.10 Use Case Diagram

The User can perform the following actions:

• Login/Registration: The user can log in to an existing account or register a new
account.
• Upload Code: The user can upload source code files to the system for analysis.
• Preprocessing: The system preprocesses the uploaded code, which involves tasks
like tokenization, normalization, and formatting.
• Feature Extraction: The system extracts relevant features from the preprocessed
code, such as code complexity metrics, syntactic features, and semantic features.
Extraction from Text: The system extracts features from textual descriptions or
comments within the code.
• Binary Conversion: The extracted features are converted into a suitable format for

KCES’s CoEM, JALGAON 25

 CHAPTER 4. SYSTEM DESIGN

machine learning algorithms.

• Classification: The system applies machine learning models to classify the code
based on defect likelihood.
• Detection: The system identifies potential defects in the code and provides feedback
to the user.
This use case diagram provides a clear overview of the user interactions with the system,
helping to understand the system’s functionality and how it can be used to detect software
defects.

4.5.2 Sequence Diagram

As shown in Figure [4.11], the sequence diagram illustrates the sequence of interactions
between the user and the system during the software defect detection process.

Figure 4.11 Sequence Diagram

The user initiates the process by logging in or registering for an account. Once
authenticated, the user can upload a code file. The system then performs a series of

KCES’s CoEM, JALGAON 26

 CHAPTER 4. SYSTEM DESIGN

steps:
• Preprocessing: The code is preprocessed, which involves tasks like tokenization,
normalization, and formatting. Feature Extraction: Relevant features are extracted
from the preprocessed code, such as code complexity metrics, syntactic features, and
semantic features.
• Segmentation: The code may be segmented into smaller units for more focused
analysis. Extraction from Text: Features can also be extracted from textual de-
scriptions or comments within the code.
• Classification: Machine learning models are applied to classify the code based on
defect likelihood.
• Detection: Potential defects are identified and presented to the user. The system
may involve an admin who oversees the system’s operations. The admin may have
access to additional functionalities, such as managing user accounts, monitoring
system performance, and updating the machine learning models.
This sequence diagram provides a clear visual representation of the interactions be-
tween the user and the system, highlighting the flow of control and data during the defect
detection process.

4.5.3 Activity Diagram

As shown in Figure [4.12], the activity diagram illustrates the workflow of the software
defect detection system.
The process begins with Registration, where a new user can create an account. Once
registered, the user can Login to the system.
After successful login, the system proceeds with Pre-processing the uploaded code.
This involves tasks like tokenization, normalization, and formatting.
Next, Feature Extraction is performed, where relevant features are extracted from
the preprocessed code. These features can include code metrics, syntactic features, and
semantic features.
The system may then perform Segmentation, dividing the code into smaller units for
more focused analysis.
Extraction from Text can also be performed, where features are extracted from tex-
tual descriptions or comments within the code.

KCES’s CoEM, JALGAON 27

 CHAPTER 4. SYSTEM DESIGN

Figure 4.12 Activity Diagram

The extracted features are then used for Classification, where machine learning mod-
els are applied to classify the code based on defect likelihood.
Finally, the Detection phase identifies potential defects in the code and presents the
results to the user.
This activity diagram provides a clear visual representation of the sequence of activ-
ities involved in the defect detection process, helping to understand the overall workflow
and identify potential bottlenecks or areas for improvement.

4.5.4 State Machine Diagram

As shown in Figure [4.13], the diagram illustrates a typical machine learning pipeline
for software defect prediction. The process begins with historical defect data, which
is balanced to ensure equal representation of different defect categories. This balanced
dataset is then used to train a machine learning model, such as a decision tree or neural
network. Once trained, the model can predict the likelihood of defects in new software

KCES’s CoEM, JALGAON 28

 CHAPTER 4. SYSTEM DESIGN

instances. The predicted defects can be categorized into specific types, allowing for
targeted remediation efforts. This approach helps organizations proactively identify and
address potential defects, improving software quality and reliability.

Figure 4.13 State Machine Diagram

4.5.5 Communication Diagram

As shown in Figure [4.14], the diagram illustrates a general data mining process. This
process involves acquiring data from various sources, transforming and preprocessing it
to make it suitable for analysis. Data mining techniques, such as clustering, classification,
artificial intelligence, and association rule mining, are then applied to extract valuable
insights from the data. The results obtained from these techniques are interpreted and
evaluated to assess their significance and reliability. In the context of software defect
prediction, this process can be applied to historical defect data to identify patterns and
trends, leading to the development of predictive models that can accurately predict future
defects.

KCES’s CoEM, JALGAON 29

 CHAPTER 4. SYSTEM DESIGN

Figure 4.14 Communication Diagram

4.6 Summary
This section of the project report delves into the Software Defect Detection Using
Machine Learning. It covers essential aspects such as the system architecture emphasizes
the use of the system. The data ow diagram illustrates the information ow within the
system. The structural design includes an ER diagram and class diagram showcasing
entity relationships. The behavioral design encompasses use case, sequence, activity, and
collaboration diagrams, demonstrating system interactions.

KCES’s CoEM, JALGAON 30

 Chapter 5
IMPLEMENTATION
The implementation of our software defect detection system is divided into three major
components: frontend, backend, and data flow. Each component is developed using
modern web technologies and integrated with machine learning models to provide an
interactive and intelligent user experience.

5.1 Implementation

5.1.1 Frontend
The frontend of the application is developed using Next.js and React, offering a scalable
and modular structure. To ensure responsiveness and accessibility across various devices,
we used Tailwind CSS for styling. For dynamic and interactive data visualization,
Recharts is used to graphically present the analysis results of the defect detection.
Additionally, Framer Motion is incorporated to add smooth animations, enhancing the
overall user interface and experience.

5.1.2 System Setup and Implementation Details

The backend logic is implemented using Next.js API routes, enabling efficient server-
side handling without the need for a separate backend framework. Supabase serves as the
backend-as-a-service platform, offering both authentication and real-time data storage.
We employed a PostgreSQL database for storing user information and machine learning
results. Furthermore, the core intelligence of the system is powered by two machine
learning algorithms: Support Vector Machine (SVM) and Decision Tree, which
were trained on labeled datasets of software metrics to predict the likelihood of defects.

5.1.3 Dataset Source

The system utilizes the NASA Metrics Data Program (MDP) dataset, specifically the PC1
dataset. This dataset contains software metrics and defect data from a flight software
system for an Earth-orbiting satellite. The dataset was downloaded from an open-source
repository. After preprocessing to extract relevant metrics, it was uploaded to Supabase
storage under the filename “Soft attributes.csv”.

31
 CHAPTER 5. IMPLEMENTATION

5.1.4 Supabase Setup

• Local Development: For local development, the Supabase CLI was used to ini-
tialize and run services locally. The necessary tables for users and defect results
were created within the Supabase project. Environment variables were configured
to securely link the application to Supabase services.
• Production Setup: In production, Supabase is connected via secure environment
variables managed through the Vercel deployment platform. The frontend applica-
tion communicates with Supabase for authentication, data storage, and real-time
database operations.

5.1.5 Machine Learning Model

The current implementation uses a simplified decision tree for predicting software defects.
For improved performance in production, advanced models such as Random Forest or
XGBoost can be trained using the PC1 dataset. These models may be exported in web-
compatible formats like ONNX or TensorFlow.js for integration into the frontend.
Model training is performed using Python with libraries like scikit-learn. The process
involves preparing, training, and validating the model. Once verified, it is integrated into
the application for real-time prediction based on software metric input.
• Simplified Decision Tree Logic for Defect Detection:-
The system incorporates a rule-based decision tree to identify potential software
defects based on key software metrics. These rules are derived from empirical software
engineering research and are used to flag modules that are likely to be error-prone. The
logic operates as follows and as shown in image:
1. Defect Field Check: If the input dataset already includes a defects field (e.g.,
from a CSV file), this value is used directly to determine whether a defect is present.
2. Cyclomatic Complexity (vg): Modules with a cyclomatic complexity value
greater than 10 are marked as defective. A higher value indicates that the code
has more decision points, making it more complex and error-prone.
3. Essential Complexity (ev): If the essential complexity exceeds 4, it suggests
poor code structure. Such code is harder to understand and maintain, increasing
the chance of defects.
4. Halstead Effort (e): Values above 1000 indicate that the module requires high

KCES’s CoEM, JALGAON 32

 CHAPTER 5. IMPLEMENTATION

mental effort to understand. This metric, derived from Halstead’s software science,
correlates with the potential for defects in complex modules.

Figure 5.1 Decision Tree Logic

5. Documentation Quality: For modules with more than 100 lines of code, if the
ratio of comment lines to code lines is less than 10%, the module is flagged due
to insufficient documentation. Poorly documented code is harder to maintain and
more likely to introduce defects.
6. Control Flow Complexity: If more than 30% of the lines in a module contain
branches and the module exceeds 50 lines, it is considered to have complex control
flow, which is typically harder to test and debug.
If any of these conditions are met, the system flags the module as defective and
records the corresponding reason. If none of the thresholds are crossed, the module is
considered defect-free according to the rule-based logic.

5.1.6 Authentication Flow

Basic authentication is implemented using Supabase’s built-in services. For a production-
level system, it is advisable to include email verification, social login support, password
reset functionality, and session/token management. These features enhance both security

KCES’s CoEM, JALGAON 33

 CHAPTER 5. IMPLEMENTATION

and usability.

5.1.7 Data Storage and Access Control

User data is stored in a dedicated user table, while prediction results are recorded in a
separate defect results table. Supabase’s Row Level Security (RLS) is employed to ensure
that users can only access their own data, maintaining privacy and data integrity.

Figure 5.2 Database

5.1.8 Data Flow

The data flow in the system begins with the user inputting software metrics through the
web interface. These inputs are first validated and then sent to the server. The server
processes the data and passes it to the trained machine learning models (SVM and Deci-
sion Tree) for analysis. The output, which includes predictions and defect probabilities,
is then stored in the PostgreSQL database.Finally, results are displayed to the user in
both graphical and tabular form, and the user is provided with an option to generate and
download detailed analysis reports in a structured format.

KCES’s CoEM, JALGAON 34

 CHAPTER 5. IMPLEMENTATION

Table 5.1 Software Metrics Description

Metric Description
loc Total lines of code, including comments and
blanks.
vg Cyclomatic complexity – number of independent
paths.
ev Essential complexity – measures structuredness.
iv Design complexity – complexity of calling pat-
terns.
n Halstead length – total operators and operands.
v Halstead volume – size of implementation.
l Halstead level – abstraction level of code.
d Halstead difficulty – ease of understanding.
i Halstead intelligence – cognitive effort needed.
e Halstead effort – effort to code or understand.
t Halstead time – time to implement/understand.
lOCode Code lines excluding comments and blanks.
lOComment Number of comment lines.
lOBlank Number of blank lines.
locCodeAndComment Lines with both code and comments.
uniq Op Unique operators used.
uniq Opnd Unique operands used.
total Op Total occurrences of operators.
total Opnd Total occurrences of operands.
branchCount Total control flow branches (if,loops).

5.2 Testing Methodology

The testing phase of the Software Defect Detection System was conducted to ensure that
the application meets its intended functionality, performs accurate defect predictions,
and provides a reliable user experience. The primary objective of testing was to evaluate
both the backend machine learning model and the frontend web interface under various

KCES’s CoEM, JALGAON 35

 CHAPTER 5. IMPLEMENTATION

conditions to confirm their correctness, robustness, and usability.

Initially, unit testing was performed on each individual module of the system, in-
cluding data preprocessing, feature extraction, model training, and prediction logic. Each
component was verified to function correctly in isolation. Following unit testing, integra-
tion testing was carried out to ensure that the modules interacted seamlessly, enabling a
smooth flow of data from user input to output. System testing then validated the behav-
ior of the entire application as a cohesive whole, simulating real-world usage scenarios to
check for consistency, accuracy, and responsiveness.
To further evaluate usability, user acceptance testing (UAT) was conducted with
a few developers and testers who used the application and provided feedback on its
performance and interface. This step was crucial in confirming that the system was user-
friendly, provided meaningful predictions, and could be integrated easily into a typical
development workflow.The model was trained and tested using publicly available datasets,
such as those from the PROMISE repository and NASA MDP datasets, which include
a rich set of software code metrics alongside labeled defect data. Prior to training, the
data underwent standard preprocessing procedures, including missing value handling,
normalization, and feature selection to ensure quality input to the model.
Several performance metrics were used to assess the model’s effectiveness. Accuracy
was used to measure the overall correctness of predictions, while precision and recall were
used to evaluate how well the model identified actual defects versus false positives and
false negatives. The F1-score, representing the harmonic mean of precision and recall,
provided a balanced performance indicator. A confusion matrix was also employed to
visualize prediction outcomes, including the number of true positives, false positives, true
negatives, and false negatives.
The web application was tested in a local development environment using Python li-
braries such as scikit-learn, pandas, and Flask, and was accessed via modern web browsers
to evaluate its responsiveness and functionality. Both backend and frontend components
were verified for correctness and efficiency under multiple testing scenarios.
An essential feature of the system, known as Detection History, was also tested
thoroughly As Shown in figure This feature logs previous predictions and allows users
to view a chronological history of defect detection results. It ensures that users can
track their past uploads and understand how defect patterns may have evolved over time.

KCES’s CoEM, JALGAON 36

 CHAPTER 5. IMPLEMENTATION

Figure 5.3 Detection History

Screenshots of the Detection History interface are provided in this chapter to demonstrate
how the system archives predictions and makes them easily accessible. This historical
record not only enhances usability but also adds value for developers who wish to monitor
defect trends or re-evaluate past code modules based on updated models.
The testing process was carried out collaboratively by all four team members, with
responsibilities distributed across different areas of the system. While some members
focused on validating the machine learning model’s performance and tuning hyperpa-
rameters, others concentrated on testing the web interface, database integration, and
detection history functionality. Regular discussions and iterative feedback helped refine
the system and resolve bugs or inconsistencies efficiently. This collaborative effort en-
sured a thorough and well-rounded testing methodology, contributing significantly to the
quality and reliability of the final product.
In conclusion, the comprehensive testing process validated the accuracy and robust-
ness of the Software Defect Detection System. All major functionalities were verified,
and the system proved to be effective and stable across multiple environments and data
inputs. The inclusion of Detection History further enriches the user experience, offering

KCES’s CoEM, JALGAON 37

 CHAPTER 5. IMPLEMENTATION

transparency and traceability in software quality monitoring.

5.3 Test Case

Table 5.2 Test Cases for Major Functionalities

Feature Test Case Expected Result Status

Registration Fill personal, Redirected to login Pass
contact info, page upon success
and password in
3 steps
Login Enter correct Dashboard/home Pass
username and page is displayed
password
Login Enter wrong cre- Error message is dis- Pass
dentials played
Defect Detection Input valid Results with defect Pass
software metrics status and reason
and click ”De- shown
tect Defects”
Defect Detection Leave required Validation error is Pass
fields blank shown
Defect Detection Input edge-case Model handles input Pass
metrics (e.g., vg and returns expected
¿ 50) result
Report Download Click on ”Down- PDF/CSV report is Pass
load Report” af- downloaded success-
ter detection fully
View Training Click ”View Accuracy, F1 score, Pass
Data Training Data” confusion matrix are
on homepage displayed

KCES’s CoEM, JALGAON 38

 CHAPTER 5. IMPLEMENTATION

5.4 Costing

Cost Estimation Details

Cost estimation is a crucial aspect of software project planning, helping to forecast the
resources, effort, and budget required for successful delivery. For our software defect
detection system, we employed three standard estimation techniques—Function Point
(FP) analysis, KLOC-based modeling, and the Effort Rate method—to triangulate a
realistic development cost.
1. Function Point Cost Calculation: Function Point is a widely used technique
that estimates cost based on the functionality provided to the user. In this project, we
estimated around 100 function points, considering features like registration, login, defect
detection, report generation, and user dashboard. Each function point is assumed to take
1.4 hours of effort, and the effort rate is 500 per hour. Thus, the total cost using this
method is 70,000. This approach is ideal for early-stage estimation where functionality
is better understood than code volume.
2. KLOC Model: The KLOC (Thousands of Lines of Code) model is based on
the COCOMO (Constructive Cost Model) approach, which uses empirical data to relate
code size to effort. For this project, we assumed a codebase size of 1.5 KLOC. Applying
the formula Effort = 2.4 × (KLOC)1.05 , we calculated the development effort in person-
months, which converts to approximately 592 hours. At an hourly rate of 500, this
results in an estimated cost of 296,000. This model is suitable when code size is known
or predictable.
3. Effort Rate Model: In this straightforward approach, the estimated cost is
derived from the total number of working hours and the developer’s hourly wage. Based
on 640 estimated work hours and an effort rate of 500/hour, the total cost is 320,000.
This model is useful when actual development hours can be reasonably predicted from a
work breakdown structure.
Each model offers a unique perspective: Function Point analysis emphasizes func-
tionality, KLOC focuses on code size, and the Effort Rate model centers on manpower
usage. For our project, Function Point estimation yields the lowest cost, indicating a
relatively low-complexity system from a user perspective. The KLOC and effort-based

KCES’s CoEM, JALGAON 39

 CHAPTER 5. IMPLEMENTATION

methods, however, suggest moderate complexity due to backend logic and machine learn-
ing integration. This multi-model estimation helps ensure the project’s financial planning
is robust and adaptable to real-world challenges.

Table 5.3 Cost Estimation Using Software Metrics

Method Key Formula Assumptions Estimated

Cost
Function Point Cost Effort = FP × 1.4 FP = 100, 500/hr 7,000
Calculation hrs
KLOC Model Effort = 2.4 × KLOC = 1.5, 500/hr 29,600
(KLOC)1.05
Effort Rate Model Cost = Hours × 640 hrs, 500/hr 32,000
Rate

The component costing for the Software Defect Detection project ensures that all
necessary resources are accounted for to facilitate smooth development, testing, and de-
ployment. It includes both direct costs, such as cloud services and hardware, and indirect
costs like software licenses and documentation preparation.
Development tools like Next.js, React, and Tailwind CSS are free, but costs related
to cloud hosting on Vercel and user management via Supabase are incurred. Machine
learning model training and data storage, along with testing resources, add to the overall
budget. Additionally, preparation of technical and user documentation is a necessary
expenditure.
Miscellaneous expenses, which may arise during development, are also considered.
Proper estimation of these costs ensures that the project stays within budget and can be
completed successfully. The table below presents the detailed component costs for the
project.

KCES’s CoEM, JALGAON 40

 CHAPTER 5. IMPLEMENTATION

Table 5.4 Component Costing

S. No. Component Cost (INR)

1 Domain Name 800
2 Hosting (1 Year) 1500
3 Supabase (Free Tier) 0
4 PostgreSQL (Free via Supabase) 0
5 Development Tools (VS Code, etc.) 0
6 API Development 2000
7 Backend (Server, Database) 2500
8 Testing (Tools, Services) 1000
9 Hardware (Laptop, Devices) 25000
10 Internet Usage 500
11 Miscellaneous (Books, References) 1000
Total – 33200

5.5 Summary
The implementation of the Software Defect Detection project involved using Next.js and
React for the frontend, along with Tailwind CSS for styling and Recharts for interactive
visualizations. The backend was powered by Next.js API routes, with Supabase han-
dling user authentication and data storage in a PostgreSQL database. Machine learning
algorithms, specifically Support Vector Machine (SVM) and Decision Tree, were used
to analyze software metrics and detect defects. The system processes user-inputted met-
rics, applies the model to detect potential defects, and displays results, enabling users to
generate detailed reports. This chapter outlines the technical stack, system architecture,
and the seamless integration of machine learning with cloud services for a scalable and
efficient defect detection solution.

KCES’s CoEM, JALGAON 41

 Chapter 6
RESULT AND DISCUSSION
6.1 Result
The Software Defect Detection System has been successfully implemented as a web-based
application that utilizes machine learning to predict potential software defects based on
various code metrics. The objective of the system was to support developers in identifying
faulty or defect-prone segments in the code before such issues manifest in production
environments. This proactive approach aims to enhance software quality, reduce the cost
of later-stage debugging, and improve development efficiency.
During development, a supervised machine learning model was trained using a dataset
containing software code metrics along with labels indicating whether a defect was present.
These metrics included attributes such as lines of code, code complexity, coupling, cohe-
sion, and other measurable characteristics that influence software quality. Once trained,
the model was integrated into a web interface that allows users to upload new code metrics
and receive immediate feedback on the likelihood of defects within that code.
The evaluation of the system’s performance showed promising results. The model
was able to make accurate predictions on unseen data, and its performance was measured
using common classification metrics such as accuracy, precision, recall, and F1-score.
These evaluations confirmed that the system is reliable and robust in identifying defect-
prone modules. Moreover, the model generalizes well across different datasets, indicating
its potential to be used in varied development environments.
In practical application, the web interface of the system proved to be intuitive and
user-friendly. Developers can interact with the platform by uploading metric files and ob-
taining prediction results without needing to understand the underlying machine learning
algorithms. This usability ensures that the system can be adopted easily in real-world
software development workflows without requiring specialized machine learning knowl-
edge.
Furthermore, the system’s architecture was thoroughly validated. It includes compo-
nents for data preprocessing, feature selection, model training, prediction, and visualiza-
tion of results. Each module was tested with appropriate inputs to verify its correctness

42
 CHAPTER 6. RESULT AND DISCUSSION

and reliability. The pipeline from data ingestion to prediction was found to be efficient
and consistent in delivering outputs, thus reinforcing the system’s end-to-end integrity.
The results from testing on publicly available open-source datasets aligned well with
known defect annotations, further affirming the model’s accuracy. The ability of the
system to produce reliable predictions suggests it can be used effectively in both academic
research and industrial software development. Additionally, the system’s design allows for
retraining the model with new or project-specific data, making it flexible and adaptable
to different programming standards and domains.

Figure 6.1 Register Page

As shown in fig 6.1,The Register Page is a core component of the Software Defect
Detection System’s user interface, enabling new users to create an account before ac-
cessing the platform’s features. Built using React and styled with Tailwind CSS, the
page includes fields for entering essential user details such as name, email, and password.
Supabase handles user authentication securely in the backend. The page includes form
validation to ensure proper input formats and guides the user with appropriate prompts.
A clean layout and responsive design allow users to register easily on both desktop and
mobile devices. The figure below displays the visual layout of the registration page.

KCES’s CoEM, JALGAON 43

 CHAPTER 6. RESULT AND DISCUSSION

Figure 6.2 Log-In Page

As shown in fig 6.2,The Login Page allows registered users to securely access the
Software Defect Detection System. Designed with React and Tailwind CSS, the interface
provides a minimalistic and user-friendly experience. Users are required to input their
registered email and password, which are authenticated via Supabase in the backend.
The page includes error handling for invalid credentials and feedback messages for failed
login attempts.This secure entry point ensures that only authorized users can interact
with the system and view sensitive prediction data. The figure below shows the layout
and design of the login page.
As shown in fig 6.3,The Metrics Input Page is a critical part of the Software Defect
Detection System, where users can input software code metrics or upload metric files
for analysis. This page provides a structured form or upload interface that captures
key features such as lines of code, cyclomatic complexity, and other relevant software
metrics. Once submitted, the input is processed by the trained machine learning model,
which instantly predicts whether the given code is defective or non-defective. The result
is displayed on-screen with a clear label—either ”Defect” or ”Non-defect”—based on
the prediction. This page allows users to evaluate code quality quickly and supports

KCES’s CoEM, JALGAON 44

 CHAPTER 6. RESULT AND DISCUSSION

Figure 6.3 Metrics Input Page

Figure 6.4 Report Download Page

KCES’s CoEM, JALGAON 45

 CHAPTER 6. RESULT AND DISCUSSION

decision-making during the development process. The interface is designed to be simple

and responsive, ensuring accessibility across devices. The figure below shows the layout
of the metrics input page along with a sample prediction result.
As shown in fig 6.4,The Metrics Input Page also includes a Report Download option,
allowing users to export the defect prediction results immediately after analysis. Once
the code metrics are entered or uploaded and the system displays the prediction (Defect
/ Non-defect), users can click the “Download Report” button to save the results in CSV
or PDF format. This feature enables developers to maintain records of their analyses and
use them in future reviews or audits. The report includes details such as input metrics,
predicted output, and timestamps. The figure below shows the Metrics Input Page with
the download option clearly visible.

Figure 6.5 CSV File Upload Page

As shown in fig 6.5,The CSV File Upload Page allows users to upload datasets
containing software code metrics in bulk for batch defect prediction. This feature is
especially useful for analyzing large codebases or multiple modules simultaneously. The
page supports .csv files formatted with relevant metric fields such as LOC, complexity,
and module name. Once a file is uploaded, the system parses the content, processes

KCES’s CoEM, JALGAON 46

 CHAPTER 6. RESULT AND DISCUSSION

the data through the trained machine learning model, and generates predictions for each
entry—labeling them as either Defect or Non-defect. The results are displayed in a
structured tabular format for clarity. This functionality streamlines the defect detection
process, reducing manual input and enabling fast analysis. The image below demonstrates
the CSV upload interface and how results are displayed post-analysis.

6.2 Discussion

6.2.1 Overview
The Software Defect Detection System successfully integrates machine learning with mod-
ern web technologies to address the critical issue of software reliability. By using code
metrics as input features, the system predicts whether a given piece of code is likely to
contain defects. The implementation involved creating an intuitive and responsive web
application using React, Next.js, Tailwind CSS, and Supabase, providing a seamless ex-
perience for developers. The inclusion of functionalities such as a dashboard, CSV file
upload, metrics input, and result download significantly improved the usability of the
system for real-world applications.

6.2.2 Team Contribution

The project was developed by a team of four members who collaborated across all phases
of the system’s development. The responsibilities were divided based on individual
strengths and interests. Frontend development, including page design and responsiveness,
was handled using React and Tailwind CSS. Backend functionalities, API development,
and database integration using Supabase and PostgreSQL were collaboratively managed.
Machine learning model training, dataset preprocessing, and prediction logic were col-
lectively designed, tested, and refined by the team. Regular team meetings and effective
communication ensured synchronization throughout the project.

6.2.3 Challenges and Limitations

During development, the team encountered several challenges. One of the primary diffi-
culties was ensuring that the trained model generalized well across varied datasets and
code structures. To overcome this, the team applied preprocessing techniques, feature
selection, and hyperparameter tuning to optimize model performance. Another challenge
was integrating machine learning predictions into the real-time frontend environment,

KCES’s CoEM, JALGAON 47

 CHAPTER 6. RESULT AND DISCUSSION

which required asynchronous data handling and efficient state management. Limitations
of the project include its dependency on metric-based datasets, lack of multi-language
code support, and reliance on labeled training data.

6.2.4 Practical Impact

The practical implications of this system are significant for software development teams
aiming to maintain high code quality and reduce post-deployment bugs. By offering early
defect detection based on code metrics, the system enables developers to identify risky
components during the coding or review phase itself, thereby lowering maintenance costs
and improving overall software stability. It also aids quality assurance teams in prioritiz-
ing testing efforts. The downloadable reports and detection history add traceability and
support project documentation practices, making the system valuable in both academic
and industry environments.

6.2.5 Future Development

While the current implementation of the Software Defect Detection System serves as a
solid foundation, there are numerous opportunities for future development. Enhance-
ments could include supporting multiple programming languages, allowing the system to
analyze code written in languages beyond the current scope. Additionally, integrating
more advanced machine learning techniques, such as deep learning models, could im-
prove prediction accuracy, particularly for more complex or ambiguous defect patterns.
Further improvements in real-time defect detection and feedback loops from users would
allow the system to continuously evolve and adapt, refining predictions based on actual
development scenarios. Lastly, incorporating automated defect detection into continu-
ous integration/continuous deployment (CI/CD) pipelines would enable seamless quality
checks as part of the software development lifecycle, ensuring timely identification of
potential defects.

6.2.6 Reflection on Project Successes

The Software Defect Detection System has been a successful project, meeting its primary
goal of providing a machine learning-powered tool to predict defects in software based on
code metrics. One of the key successes was the development of an intuitive and responsive
user interface that allowed for seamless interaction with the system. The integration of

KCES’s CoEM, JALGAON 48

 CHAPTER 6. RESULT AND DISCUSSION

machine learning for defect detection provided tangible value by enabling early identi-
fication of potential code issues, thus improving the software quality assurance process.
Another significant achievement was the efficient use of modern web technologies such
as React, Next.js, and Supabase, which ensured a smooth user experience and scalabil-
ity. The ability to upload code metrics in bulk via CSV and view results on a central
dashboard also proved to be an invaluable feature. Overall, the system met its objec-
tives by offering an easy-to-use solution that aligns with the needs of software developers
and quality assurance teams, delivering a practical tool that adds value to the software
development process.

KCES’s CoEM, JALGAON 49

 CONCLUSION
The primary aim of the Software Defect Detection System was to create a web-based
tool that utilizes machine learning to predict defects in software code. By analyzing
key code metrics such as cyclomatic complexity and lines of code, the system was de-
signed to provide developers with early warnings of potential issues, enabling them to
address problems before they affect production. The goal was to develop an intuitive,
user-friendly interface that seamlessly integrates into the software development lifecycle,
helping developers ensure high-quality code.
Throughout the development process, the project successfully achieved its intended
objectives. A functional web application was developed that accurately predicts defects
based on software metrics. The system features an interactive dashboard, the ability
to upload CSV files for bulk analysis, and a report download feature to save results.
The integration of secure authentication and a responsive user interface enhanced the
overall user experience, while the backend handled data storage and prediction results
efficiently. The project successfully met its goal of providing a practical tool for software
quality assurance.
Looking forward, there are several opportunities to further enhance the Software
Defect Detection System. Future development could focus on supporting additional pro-
gramming languages and incorporating advanced machine learning models, such as deep
learning, for even more accurate defect predictions. Real-time integration with contin-
uous integration/continuous deployment (CI/CD) pipelines could automate defect de-
tection during the development process, ensuring timely identification of issues. With
continuous user feedback and iterative improvements, the system can remain a valuable
and relevant tool for software development teams in the years to come.

50
 REFERENCES
[1] CB-Path2Vec:A Cross Block Path Based Representation for Software Defect Predic-
tion.XiyuZhang1,YangLu1,2,KeShi.

[2] Study on Software Defect Prediction Model Based on Improved BP Algo-

rithm.Cundong Tang1,2,*, Li Chen1, Zhiping Wang2, Yuzhou Sima2.

[3] Connecting Software Reliability Growth Models to Software Defect Tracking.Maskura

Nafreen, Melanie Luperon, and Lance Fiondella.

[4] BRACE: Cloud-based Software Reliability Assurance Kazuhira Okumoto Soft-

ware and Systems Reliability Engineering Bell Labs CTO, Nokia Dublin, Ireland
[email protected] Abhaya Asthana Software and Systems Reliabil-
ity Engineering Bell Labs CTO, Nokia Westford, USA abhaya.asthana@nokia bell-
labs.com Rashid Mijumbi Software and Systems Reliability Engineering Bell Labs
CTO, Nokia Dublin, Ireland.

[5] Software Defect Prediction Using Support Vector Machine(2023) Haneen Abu Alhija
1 , Mohammad Azzeh 2 * and Fadi Almasalha 1 1 Department of Computer Science,
Applied Science Private University, Amman, Jordan 2 Department of Data Science,
Princess Sumaya University for Technology, Amman, Jordan.

[6] Review of the Prediction Model(2011) Member, IEEE), JIAJING WU 1,2JIE ZHANG
1,2, (Graduate Student, (Senior Member, IEEE), CHUAN CHEN 1,2, (Member,
IEEE), ZIBIN ZHENG 1,2, (Senior Member, IEEE), AND MICHAEL R. LYU3, (Fel-
low, IEEE).

[7] Cross-Version Defect Prediction(2020)JIE ZHANG and JIAJING WU.

[8] Reliability Growth of Open Source Software(2022),Sharifah Mashita,Syed-Mohamad

and Tom McBride.

[9] A Critique of Software Defect Prediction Models(2020),Norman E.Fenton.

[10] PV-Active Power Filter Combination Supplies Power to Nonlinear Load and Com-
pensates Utility Current(2017),NGUYEN DUC TUYEN (Member, IEEE) AND
GORO FUJITA (Member, IEEE).

51
 References

[11] Software Defect Prediction Using Machine Learning Techniques(2019), C.Lakshmi

Prabha,lakshmiprabha and N.shivakumar.

[12] Study on Software Defect Prediction Model Based on Improved BP Algo-

rithm(2018),Cundong Tang,Li Chen1,Zhiping Wang and Yuzhou Sima.

[13] “A Systematic Survey of Just-in-Time Software Defect Prediction” (2023),Yunhua

Zhao,Kostadin Damevski and Hui Chen.

[14] “Machine Learning Techniques for Software Quality Assurance: A Survey”

(2021),Safa Omri and Carsten Sinz.

[15] Unsupervised Techniques Review (2019),Hoa Khanh Dam, Trang Pham, Shien Wee
Ng, Truyen Tran, John Grundy, Aditya Ghose, Taeksu Kim and Chul-Joo Kim.

KCES’s CoEM, JALGAON 52