## 3 DePaaS: Architecture and Design
### Architecture
The model selector algorithm shall help this process by suggesting the most suitable SDP model/technique or a combination of multiple models/techniques, such as the one based on filter technique [22], or the other based on wrapper technique [23], or a hybrid model based on both filter and wrapper technique [24], or using any other recommendation algorithm [18]. The recommendation algorithm could also be made to choose the most appropriate set of reference projects in the CPDP context. Once the SDP model is chosen, its parameters, such as granularity, shall be fine-tuned using the model tuner application. As software defect prediction could be done at different granularity, the end user shall specify the appropriate level at which the software defects need to be predicted. Choices of granularity could be subsystem, module, file, class, or method. Figure 3: Novel DePaaS Process for use with DePaaS. Then the user shall upload the source code consisting of software code units that needs to be classified as defective or not. Some models may not need the actual source code but work on the defect metadata. Moreover, some of the SDP models extract desired software metrics in real time either from uploaded source code or from the public datasets. In such cases, source code shall be uploaded prior to model selection. In certain circumstances, the dataset and features need to be selected before selecting the defect prediction model. Such a pre-selection helps detecting issues in the dataset, such as, duplicate features. Additionally, pre-selecting datasets help counting the number of rows, which certain SDP models need as an input. In cases where the model might have a co-dependency on the dataset, the end user may not have a choice of datasets. In such cases, the dataset mandated by the SDP model is automatically chosen. The chosen model shall then be trained and validated. For this purpose, the chosen dataset might be broken into three parts--the training part, validation part and the testing part. In the cross-project context, the model could be trained on one project's dataset and run on another project's dataset. The chosen model is initially fit on the training dataset. The chosen model might use its own learning method such as gradient descent or stochastic gradient descent. The model is run on the training dataset and results are compared with the desired target indicated by the chosen model. Based on the proximity of the output to the desired target, model parameters are adjusted. After successively fitting the model on the training dataset, the model is run on the validation dataset. This run provides a measure of evaluation of the chosen model. The model parameters are adjusted once again to improve the performance of the chosen model as desired. Finally, the chosen model is run on the test data set which provides a final measure of performance of the tuned model. The input shall be processed as per the internal logic of the SDP model and unit-wise classification details (list of modules and a flag indicating whether the unit is defective or not) shall be produced by DePaaS as the output. Depending on the SDP model chosen, the output might consist of number of defects (defect count) and a set of source code lines marked as 'risky changes'. The end user shall view SDP outputs and download it in many formats as needed. The end user could also examine model performance parameters such as Area under the Receiver Operator Characteristic Curve (AUC), G-Mean, Balance, etc., and choose to repeat the defect prediction process with the choice of the same model or by changing the granularity or by choosing an alternate SDP model or a context. DePaaS can provide the highest, lowest, and average performance of the chosen SDP model it has observed over time. At the end of each usage cycle, DePaaS shall store its prediction experience--a set of statistics, including model performance, useful for further refinement of the model.