# On the Use of Quality Models to Address Distinct Quality Views
## 3 Methods  
The study applies qualitative research comprising the analysis of documents and tailored quality models to specific project needs. The documents forming the input of the present research were identified by a systematic literature review [16] in the scope of [5]. As the internal/external quality views and quality-in-use view are not explicitly defined in all the model descriptions, the quality property specifications and model concepts were investigated to obtain an insight as to whether a given quality model is able to address external or quality-in-use manifestations.  
Quality models able to provide guidelines to the investigation of the source code or documentation, without exhibiting any quality property assessing the software's runtime behaviour or the perception of the end user, are designated as quality models with internal quality view only (denoted \"I\" in Table 2). Quality models that contain quality properties to assess the software's runtime behaviour are designated with the external quality view (denoted \"E\" in Table 2). In addition, if a quality model also shows up quality properties to reflect the end user's assessments in any form, then the quality-in-use view is also assigned (denoted \"U\" in Table 2). If a given quality model does not provide quality property specifications, but it contains concepts that allow to define or deal with existing quality property specifications and how to extend the model, then these concepts were examined to decide which quality views the quality model is able handle. Thus, quality models lacking explicit information about the quality views were classified based on the authors' interpretation of the published model definitions with regard to concepts, and quality properties. Cases where alternative interpretations to the authors' one may exist are indicated with brackets in Table 2 and with additional explanations in the next section. Quality models not providing enough information to perform a reasonable classification are classed \"Undefined\" in Table 2. There are also quality assessment approaches that allow the definition of a new quality model or the use of a different quality model from the one predefined. The quality views applied in such cases depend on the quality models implemented (denoted \"D\" in Table 2). The flow chart of the taxonomy process is depicted in Figure 1.  
Section 4 lays out the classification of the identified software product quality models and provides reasoning in each case where the model description does not explicitly define the use of the internal, external and quality-in-use views.  
\begin{table}
\begin{tabular}{c c c c c c c c} \hline
**ID** & **Reference Bank** & **Name** & **Quality View Consolidated** & **Predefined Quality Properties or Movies Available** & **Research Interest** & **Widespread Use Cases** & **Abs. Process Related Properties** \\ \hline  
EEE Martius Framework: Benillard in 2009 [15] & Underlined & No & No & No & Unidefined \\
20 & 13 & Mining Framework for Mobile Apps [50] & Underlined & Yes & No & No & Unidefined \\
21 & 13 & SAT(5) [51] & L.E & Yes & No & No & No \\
22 & 13 & SQL(4) & L.E & Yes & No & No & No \\
23 & 13 & SQ(16) [4] & D & D & No & No & No & D \\ \hline \end{tabular}
\end{table}
Table 2: Taxonomy: software product quality model families and their quality views.