Software Defect Prediction is an attempt to find defects in software in an automated fashion. Three main goals of software defect prediction are:
\bi 
\item Detect defects in an efficient manner.
\item Detect defects, and explore defective modules, in a cost effective manner.
\item Detect the maximum number of defects while minimizing the number of false alarms.
\ei

By quickly finding the defects in software, the overall cost impact of the defects can be lowered\cite{IVnV}. When a defect is found in software after deployment, the impact can spread far beyond the cost of fixing the defect. The most immediate impact is that the patch for the defect must be deployed to not just the production and development environments, but also to the customers which are using the software. Another cost which can be more far reaching is the impact of the defects on customer satisfaction and assurance\cite{bugsMakeCustomersSad}.

If a defect is found during the verification or development phases of the software, it can eliminate the impact on customer satisfaction. If the defect is found during verification, it can force the developers to re-verify that portion of the software once the defect has been fixed, possibly having to restructure a portion of the project in the process. The optimal time to find defects is during the development phases of software\cite{IVnV}. If the defect is found during development, it can reduce the expenditures during verification. Another benefit is that, if found quickly, the developer still has the code that caused the defect in mind. This will allow the developer to more quickly find and correct the defect. Neilsen\cite{fasterIsBetter} shows that if a defect is found within 1 second, the developer's train of thought is still on the project at hand, and this can assist the developer in correcting the defect.

%Neilsen\cite{fasterIsBetter} reports that response times of the defect predictor of $<$ 1 second will allow the developer to maintain their train of thought, and response times of $<$ 10 seconds will allow the developer to continue to focus on the defect predictor. This provides an argument that a software defect predictor should run quickly.

Standard software defect prediction uses static code metrics, or numeric descriptions of the source code. An instance in a software defect prediction dataset represents a single module\footnote{A module is also called a function or a method, depending on the language.}. A module is the smallest section of source code that is functionally complete\cite{06learnPredict}. By choosing a module rather than a source code file to use for defect prediction, three things are accomplished:
\bi
\item The location of possible defects is constrained to the smallest sample of source code.
\item Noise from other defective or non-defective modules is removed.
\item More data points are collected with the same effort.
\ei
