There are two different types of software defect prediction data:
\bd
	\item[Within Company] This is the standard approach to software defect prediction. The user assumes that an organization has existing software defect prediction data to be used for training on a given project. This is often difficult to find because either 1) The project/organization is new and has not had the time to build up a repository of data to work with, or 2) The project/organization has not tracked or stored a priori defect data.
	\item[Cross Company] This is another approach to software defect prediction. In this approach, the user gathers data from alternative projects from within the same organization or from projects at other organizations that are similar in domain. The more similar the original projects are to the new project, the better the classification results will be\cite{cc}. I will explore Cross Company data while ignoring the similarity between the testing dataset and the training datasets.
\ed

If automated defect prediction is implemented from the beginning of the implementation phase of software development, 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. Turhan at al. recommends starting with cross company software defect prediction, and then expanding towards within company data as it becomes available.\cite{08Turhan}

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 ostensibly 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 the Promise Data Repository\cite{promiseData}. This type of data has a higher probability of detection because of the increased training data available. The drawbacks of Cross-Company data are:
\be
\item The false alarm rate, or PD, is increased.
\item The data freely available was collected with various degrees of accuracy.
\item If you collect Cross-Company data from your own projects, it is more expensive to collect than Within-Company data, because of the increased number of instances utilized.
\ee
