Software Defect Prediction is the act of predicting which modules within a software system will be defective. This is a desirable course of action because it reduces the number of defective modules within the system, increases product satisfaction and reliability, and reduces product maintenance and deployment costs\cite{whyFindBugs}. The sooner software defects are found, the less it impacts the software development process\cite{soonerIsBetter}.

The standard view of the software development life-cycle is that it contains the following 5 steps:
\bd
\item[Requirements] Create a feature list, and decide on the objectives of the system.
\item[Design] Layout the interface options for the system. Define the architecture for the system.
\item[Implementation] The actual software development phase. This is where the source code is written.
\item[Verification] Making sure the system implemented matches the requirements specification. Finding defects.
\item[Deployment] Distributing the software, training the target audience, and maintaining the software.
\ed
Finding, fixing, and avoiding defects in the system is involved in all 5 steps. In the Requirements and Design phase of development, methods such as risk mitigation charts can be used to help avoid defects in projects\cite{gregThesis}.
It is during the Implementation, Verification, and Deployment phases that automated defect predictors can be used. Automated defect predictors are limited to these phases because they require source code for the project to be available for classification as defective or non-defective. This will be further discussed in \tion{sdp-related}.

Automated software defect predictors are generally referred to as classifiers. They provide an automated way to find defects in the software. There are two main approaches to classification algorithms:
\bd
\item[Global Classifiers] All of the training data is used during the classification process, regardless of its similarity to the data to be classified.
\item[Local Classifiers] Only the data that is local to, or relevant to, all or part of the data to be classified is used during the classification process.
\ed

Another set of algorithms that are commonly used in software defect prediction are clustering algorithms. Clustering algorithms are used to find the data that is local or similar to the classification data. They find the structure that is "hidden" amongst the data. These are trained separately from the classification algorithms using the entirety of the training data. They are then queried to find which cluster each instance to be classified belongs to, and what other training data belongs to that cluster as well.

Some recent work in software defect prediction has focused on the concept of locality\cite{localitySDP,locality2,locality3,08Turhan}\label{pg:locality3}, or finding information for use during classification which is similar to the testing data. First, I will explore a relevancy filter called the Burak filter to show the effects of localizing the data before it is used for testing. \label{pg:burak}\label{pg:pg16Issue}The Burak filter is a relevancy filter that eliminates the training instances which are significantly dissimilar to the testing instances. Next, I will explore a selection of locality based learners to explore the effect of locality during the testing phase. Finally, I will explore a selection of clustering algorithms.

Recent work has shown that locality based classifiers perform better than their non-locality based counterparts\cite{locality1,08Turhan}. Turhan et al.\cite{08Turhan} demonstrates the benefit of locality when applied to software defect prediction. This effect will be explained in \tion{burak-reproduction}\label{pg:locality-is-good}. I will show that software defect prediction data does not contain the same structure that benefits from locality as other types of data\cite{UCI}. \label{pg:doesnotwork}This will be demonstrated by showing that although locality based learning is effective for much of the UCI\footnote{The UCI data consists of a variety of datasets, and is hosted by the University of California, Irvine}\cite{UCI} data available, locality based classifiers do not improve performance when run on software defect prediction datasets. 

In this thesis I will compare local classification algorithms with global classification algorithms. I will also explore the effect of clustering algorithms and relevancy filtering on the previous classification algorithms. I will also explore Clump, a home grown decision tree based clustering algorithm augmented by a Naive Bayes classifier. Finally, I will explore the different impact that algorithms and datasets have on the probability of detection and false alarm rate. Many of the algorithms explored have a functionally and statistically similar performance. I will show that the, using current static code metrics, defective modules do not contain the necessary structure to benefit from locality.

