## 3 DePaaS: Architecture and Design
### Architecture  
The conceptual framework of DePaaS described in Figure 1 is converted into a detailed technical architecture. The architectural components are grouped into five layers. Each layer shows modules, which are implementation units of software that provide a coherent set of responsibilities. Five types of users are identified--SDP Researcher, SDP Model Provider, Dataset Provider, Project Team or End User or SDP Runner and SDP Admin. Internal data entities are also identified. The resulting technical architecture is shown in Figure 2.  
To keep the high-level architecture simple to understand, messages passed between components are abstracted and not shown. The architecture separates software modules and storage. At least five layers can be recognized in DePaaS architecture. The number of layers coincidently match with the number of users. However, there is no strict one-to-one correlation between users and layers even though Figure 2 implies it. Each layer is briefly described below:  
* _Security Layer_: This layer consists of modules that register end users, maintains their profiles, and impose role-based security across the DePaaS platform at the application level. DePaaS shall consist of multiple security controls, including _integration of active directory services_ provided by the cloud service provider, dual factor authentication before uploading SDP model and datasets, formation of security groups to enforce common security controls and enforce perimeter network control using a firewall. DePaaS shall enforce encryption, anonymization of names of the organization, business unit, project, software product, module file, package, class and methods. Each user shall have own containers which prevents sharing of data. While uploading SDP models and datasets, end users can mark specific data elements that they would like to hide from other users. DePaaS shall seek minimal personal information of DePaaS users, and typically includes name, affiliation and email address. Figure 2: Layered, Modular Architecture of DePaaS. Incidents related to data security and privacy are logged in DePaaS Logs and are periodically analysed by the DePaaS admin. * _Data and Feature Set Layer_: This layer consists of modules that manage upload, validation, and integration of datasets. First the details of the dataset such as list of features are accepted, and then the dataset is validated for redundancy and relevance. A cost benefit analysis could also be performed to estimate the perceived value of integrating the new dataset. The dataset meeting the threshold for redundancy, relevance and cost is integrated into DePaaS. * _Model Management Layer_: This layer consists of modules that manage upload, validation, and integration of SDP models. First the details of the SDP model such as learning technique, tunable parameters, performance parameters, etc., are accepted and the model is validated against acceptable thresholds of performance. A cost benefit analysis could be performed to estimate the perceived value of integrating the new SDP model. The SDP model meeting stated thresholds is integrated into DePaaS. * _SDP Run Management Layer_: This layer consists of multiple modules that guide the industry practitioner to perform one run of software defect prediction. These modules together implement the SDP process shown in Figure 3.  
To initiate the use of DePaaS, the software development team shall register into DePaaS using the front-end application, choosing an appropriate commercial model such as pay-per-use. Then, the user (a member of the software development team) shall log into the front-end application and choose the most appropriate SDP model based on the nature of the current project and other relevant parameters.