Automated defect prediction uses static code metrics extracted from the source code of the software being developed. There are two different types of software defect prediction data: Within Company and Cross Company. These two types of data will will be explained in \tion{design}. If automated defect prediction is implemented from the beginning of the implementation phase, Cross-Company data must be used for initial training of the defect predictor. If automated defect prediction is implemented towards the end of the implementation phase, Within-Company data may be used for training the defect predictor. When automated defect prediction is used, defects can be found earlier in the development process. 

Using Within-Company data, or data that was written for the project being classified, reduces noise by only using data local to the current project. This results in a lower false alarm rate\footnote{This would be defective modules being classified as non-defective, or non-defective modules being classified as defective}. Within-Company data seems like the optimal, and in-veritably only, choice. The drawback of Within-Company data is that it is:
\be
\item Expensive to collect, both in the time expended and in the infrastructure involved.
\item Often does not provide enough data to clearly identify the areas of the search space that are defective.
\bi
\item Because of the lack of data, the probability of detection is also decreased.
\ei
\ee
Cross-Company data is the alternative to Within-Company data. Cross-Company data is data taken from a selection of other organizations, development teams, or projects. Cross-Company data is cheap to gather given free software defect prediction data repositories such as Promise Data\cite{promiseData}. This type of data has a higher probability of detection because of the increased training data available. It also has a subsequent increase in the false alarm rate.

