According to the data in Table \ref{tab:scenar1}, the total number of defects discovered in release 4.0.0 are:
\begin{equation}
\label{htotal}H_{total}=\sum H_{phase}=190+383+264=837\\
\end{equation}
Accordingly, the total quality assurance cost is:
\begin{equation}
\label{ctotal}C_{total}=\sum C_{phase}=190x+1063x+733x=1985x\\
\end{equation}
The ratio between defects fixed in testing and those fixed during the post-release stages is:
\begin{equation}
\label{ratio1}\frac{H_{2}}{H_{3}}=\frac{383}{264}\approx\frac{3}{2}\\
\end{equation}
Model Construction and Prediction
\label{model_construction}
To create a prediction model that will be able to classify new source code, a machine learning process must be performed using training data already categorized respectively, and taken from an earlier version of the program, in which the area of “high risk” can be easily identified by investigating which code areas were changed most because of bug fixes. In the case of the Texas Project we used the previously described method, that all of the source code changes caused by fixing defects, were labeled with unique defect identifiers, which were recorded in the software responsible for managing bugs in the project. Both version control system, and defect tracker application used in the project make it possible to obtain the desired data by exporting it to a file. The DePress framework consists of appropriate modules allowing for conversion of the data from both those programs to a universal internal format. Log entries from the repository, take into account all changes in the source code. All recorded changes resulting from bug fixes, are recognized by the module Marker Parser. These entries are then compared with data from the defect management system by the module Issues per Artefact (Figure \ref{fig:issues_per_artefact}). The effect of this module’s usage are statistics describing the frequency of code changes resulting from bug fixes for each of the code modules. Due to this comparison it is easy to recognize the most defective areas which are known to be “high risk”. In the case investigated (release 4.0.0), as an area of “high risk”, we pointed out all the modules that have to be modified to be able to fix more than 2 registered defects. These modules accounted for 22.4% of all modules and were responsible for 80.36% of all registered errors.