Modelos de Calidad de Software en la Práctica:Mejorando su Construcción con el Soporte de

Modelos Conceptuales

Jorge Bermeo Conto, Malhena Sánchez, Jorge J. Maldonado, and Juan PabloCarvallo

Universidad de Cuenca, Departamento de Ciencias de la Computación,Cuenca, Ecuador

{jorge.bermeo, malhena.sanchez, jorge.maldonado, pablo.carvallo}@ucuenca.edu.ec

Abstract. Los Modelos de Calidad del Software (QM), son artefactosespecíficamente diseñados y construidos para soportar evaluación y se-lección de componentes de software. Permiten la definición estructuradade criterios de evaluación, la especificación de requerimientos, la descrip-ción de componentes en relación a ellos y la identificación de desajustesde manera sistemática facilitando el proceso de evaluación y seleccióndel software. Sin embargo, la construcción de QM suele ser compleja,dada la dificultad de identificar elementos de calidad apropiados a serincluidos en su estructura, la ambigüedad semántica asociada a algunosde ellos y la dificultad para determinar cuándo su estructura está conclu-ida. Basado en trabajo previo, este artículo propone el uso de modelosconceptuales (MC) como base semántica para construir y validar QMy un conjunto de casos de mapeo que permiten relacionar los elemen-tos de calidad incluidos en el QM con los conceptos incluidos en el MC.La propuesta se ilustra con un caso de aplicación en el contexto de losSistemas de Gestión de Aprendizaje (LMS).

Keywords: Modelo de calidad software, MC, mapeo, elementos de ca-lidad.

1 Introducción

La evaluación de la calidad de un producto de software juega un papel funda-mental tanto en la selección de un componente de software (p.e., un sistemalegado o un componente a ser adquirido, ya sea de índole comercial -COTS- olibre y de código abierto -FOSS-), como en la validación de un producto resul-tante de un proceso de construcción a la medida (sea este construido por unaunidad interna de la organización o por una empresa externa subcontratada paraeste propósito). Un modelo de calidad (QM) es “el conjunto de característicasy relaciones entre ellas que proporcionan la base para especificar requisitos decalidad y evaluación de la calidad” [1]. Un QM provee una taxonomía de factoresde calidad y medidas asociadas a los mismos, apropiadas para evaluar la calidad

de un sistema de software. Una vez disponible, el QM puede ser utilizado paraestablecer requisitos del sistema (a modo de restricciones, utilizando las medidasasociadas a los elementos de calidad incluidos en el QM). En las últimas décadasse han propuesto diversos enfoques para la construcción de QM [2] [3] [4] [5] [6],pero aun así, su construcción sigue presentando diversos retos, particularmenterelacionados con la dificultad de identificar elementos de calidad apropiados aser incluidos en su estructura, la ambigüedad semántica asociada a algunos deellos y la dificultad para determinar cuándo su estructura se encuentra conclu-ida. En [7] se ha propuesto el método Individual Quality Model Construction(IQMC), que comprende un conjunto de pasos específicamente diseñados parasoportar la construcción de un QM. El paso 0, de naturaleza exploratoria, tienepor objeto estudiar el dominio de software y definir un MC para el mismo (dia-grama de clases en UML). Una vez construido, el MC se utiliza como marcosemántico para la identificación de los elementos a ser incluidos en el QM, paraesto el método propone algunas guías, p.e., identificar factores de calidad en basea clases, atributos, métodos y asociaciones incluidas en el mismo. En la prácticala propuesta resulta insuficiente, por lo que en este artículo propone extenderlasmediante la definición de un conjunto de casos de mapeo entre elementos del MCy elementos de calidad (subcaracterísticas y propiedades de calidad de acuerdoa ISO/IEC 25010) a ser incluidos en el QM.

El resto del artículo está estructurado como sigue: sección 2 introduce eltrabajo relacionado, la sección 3 presenta los casos de mapeo que conforman lapropuesta central de este artículo, la sección 4 introduce el caso de estudio, ilustrael uso de los casos de mapeo identificados y presenta algunos números en relaciónal uso de los caso de mapeo, finalmente, la sección 5 ofrece las conclusiones deeste artículo.

2 Trabajo relacionado

En las últimas décadas se han propuesto varios modelos de calidad de software[8] [9] [10] [3] [4] [5] [6], algunos de los cuales han sido recopilados en normasinternacionales p.e., ISO/IEC 9126, ISO/IEC 25010 o IEEE 1661. Sin embargo,la mayoría de los modelos de calidad propuestos presentan solo un conjunto deelementos de calidad de alto nivel de abstracción que deben ser descompuestosen elementos más específicos con el propósito de hacerlos evaluables, lo que seconvierte en una limitante ya que no proporcionan un fundamento para guiar enla descomposición.

Construir modelos de calidad supone un reto, puesto que hay que considerarvariables que afectan el desarrollo del mismo como son: (1) el equipo que realizala construcción del modelo, en el caso de que este equipo no tenga experiencia enla construcción de modelos de calidad o bien en el contexto del dominio del com-ponente objeto; (2) el dominio para el que se construye el modelo, para el que enmuchas ocasiones no existe una terminología común; (3) factores metodológicos,ya que es difícil conocer el nivel de profundidad hasta el que es necesario descom-poner los modelos, y por tanto cuándo se puede decir que un modelo de calidad

se ha finalizado. Por ello, la existencia de métodos que proporcionen directricespara la construcción (descomposición) de los QM puede ayudar a paliar estasdificultades.

Algunos autores [11] [12] [14] [19] han planteado una serie de directrices ge-nerales para apoyar este proceso. En [11] los autores presentan su enfoque a laidentificación de un conjunto de características y un conjunto de métricas para ladetección de anomalías, que se enumeran a continuación: “1. Definir un conjuntode características relevantes para el software y razonablemente exhaustivas y nosuperpuestas; 2. Desarrollar métricas de calidad para evaluar el grado en que elsoftware cumple las características definidas; 3. Investigar las características ymétricas para determinar su correlación con la calidad del software, magnitudo beneficio potencial de utilizarlo, y facilidad de automatización asociada; 4.Evaluar cada métrica candidata con respecto a los criterios anteriores y con res-pecto a sus interacciones con otras métricas: traslapos, dependencias, carencias,etc.; 5. Basados en estas evaluaciones, perfeccionar el conjunto de característi-cas de software en un conjunto que es más mutuamente exclusivo y exhaustivo,y adecuado para soportar la evaluación de calidad de software; 6. Refinar lasmétricas candidatas y realinearlas en el contexto del conjunto de característicasrevisadas”.

En [19] cuando se refiere a la construcción de modelos basados en Métrica deCuestiones de Objetivos (Goal Question Metric -GQM-), se señala que: “Aplicarel GQM implica (1) desarrollar un conjunto de objetivos de productividad y ca-lidad a nivel corporativo, de división y de proyecto, p.e., satisfacción del cliente,tiempo de entrega, mejora de la calidad, (2) generar preguntas (basadas en mo-delos) que definan esos objetivos tan completamente como sea posible de unamanera cuantificable, (3) especificar las medidas necesarias a ser recolectadaspara responder a esas preguntas y rastrear el cumplimiento de los procesos yproductos en relación a los objetivos (4) desarrollar mecanismos para la recolec-ción de datos y (5) recolectar, validar y analizar los datos en tiempo real paraproporcionar retroalimentación a los proyectos”.

En [14] se proponen los siguientes cinco pasos para la construcción de un QMque sea comprobable, medible y refinable: “1. identificar un conjunto de atributosde alto nivel de calidad del producto; 2. identificar los componentes del producto;3. identificar y clasificar las propiedades más significativas, tangibles, ejecuciónde calidad para cada componente; 4. proponer un conjunto de axiomas paravincular propiedades de los productos con atributos de calidad; 5. evaluar elmodelo, identificar sus debilidades y afinarlo o lo desecho y empezar de nuevo”.

En [12] define un método como: “un enfoque organizado basado en la apli-cación de alguna técnica. Un método tiene asociada una técnica, así como unconjunto de directrices acerca de cómo y cuándo aplicarlas, cuando dejar de apli-carlas, cuando la técnica es apropiada y cómo podemos evaluarla”. Esta defini-ción demuestra que los enfoques anteriores no pueden ser considerados como unmétodo. Aunque todos ellos proporcionan algunas orientaciones metodológicassobre cómo construir modelos de calidad de software, fallan en proporcionar téc-

nicas para apoyar estas directrices u orientación de qué técnicas utilizar o cuándodeben ser aplicadas, en el proceso de construcción de modelos de calidad.

El método IQMC [4] proporciona un conjunto de guías y técnicas para la iden-tificación de los factores de calidad apropiados y que deben ser incluidos en unmodelo de calidad que permita analizar la calidad de componentes pertenecientesa un dominio de software.

IQMC adopta un enfoque de construcción mixto partiendo de un catálogopreexistente p.e., ISO/IEC 25010. El método propone unos pasos para el re-finamiento de dichos catálogos que conducen a la construcción de modelos decalidad para componentes software de un cierto dominio. Los modelos que seobtienen se estructuran según los elementos incluidos en estos catálogos p.e.,Características, Subcaracterísticas, Propiedades de Calidad y medidas según elISO/IEC 25010.

Como se indicó en la introducción, el método IQMC consiste de siete pasos(ver figura 1) que, aunque se presentan como si fueran secuenciales, pueden sersimultaneados y/o iterados si se considera necesario. En el primer paso, el ámbitode calidad es explorado en profundidad y, a continuación, los seis pasos restantesconducen la construcción del modelo de calidad partiendo de las característicasde calidad, y la descomposición en subcaracterísticas del catálogo de partida. Laconstrucción del QM se sustenta en el MC construido en el paso 1.

Fig. 1. Metodo IQMC

3 Casos de mapeo entre elementos del ModeloConceptual y elementos del Modelo de Calidad

Luego de haber efectuado varios casos académicos e industriales de construcciónde QMs, en los que se ha utilizando MC como artefacto de sustento al proceso,

se han identificado un conjunto de casos de mapeo que permiten extender lajerarquía del QM en basea los conceptos incluidos en el MC (o viceversa en casode que el MQ exista y se desee construir/extender el MC). Los casos de mapeofueron identificados considerando las clases, incluidas en el MC y las subcarac-terísticas y propiedades de calidad a ser incluidas en el QM, sin considerar lasmétricas asociadas a estos elementos de calidad. En consecuencia el análisis se re-alizó siguiendo los siguientes pasos (ver figura 2): Primero, se analiza cada clase,atributo o metodo presente en el MC, asi como las relaciones existentes entre lasclases incluidas en el modelo (composición, especialización y asociación), paraentender los conceptos que representan. Segundo, se analiza cada característica,subcaracterística y propiedad de calidad en el QM para entender su significadoy los requerimientos relacionados. Tercero se identifica casos particulares queasocien a los elementos incluidos en el QM con los incluidos en el MC. En casode que no se identifiquen en el QM elementos de calidad relacionados al MC, seextenderia su jerarquía con propiedades de calidad que representen estos nuevosconceptos.

Fig. 2. Proceso de análisis de mapeos

Es necesario precisar que aunque nuestro propósito es mejorar la construcciónde QM identificando elementos que deben ser incluidos en el mismo, a partir delos elementos incluidos en el MC, lo contrario tambien posible, es decir extenderel MC en base a elementos incluidos en el QM. Ver figura 3.

Fig. 3. Consideraciones de los casos presentados

3.1 Casos de mapeo identificados

A continuación se describen los casos típicos encontrados:

– Caso 1: Mapeo 1 a 1. Una clase, un atributo o un método del MC es mapeadoa una propiedad de calidad incluida en el QM. La propiedad de calidaddescompone a una subcaracterística incluidas en el QM (ver figura 4).

Fig. 4. Ilustración del caso de mapeo 1 - 1

– Caso 2: Mapeo 1 a N. Una clase, un atributo o un método del MC es mapeadoa varias propiedades de calidad de diferentes subcaracterísticas incluidas enel QM (ver figura 5).

Fig. 5. Ilustración del caso de mapeo 1 - N

– Caso 3: Mapeo N a 1. Varias clases, atributos o métodos del MC son ma-peados a una propiedad de calidad incluida en el QM (ver figura 6).

Fig. 6. Ilustración del caso de mapeo N - 1

– Caso 4: Mapeo 0 a 0. Ninguna clase, atributo o un método del MC tienerelación con los componentes del QM (Ver figura 7).

Fig. 7. Ilustración de la inexistencia de mapeo. Caso 0 - 0

El Caso 4 permite identificar los siguientes subcasos:1. Caso 4a. Una clase, un atributo o un método del MC es incorporado

como una nueva propiedad de calidad para el QM (ver figura 8).

Fig. 8. Ilustración del Caso 4a

2. Caso 4b. Nuevos conceptos (clases, atributos o métodos), son incorpo-rados en el MC a partir de una propiedad de calidad incluida en el QM(ver figura 9).

Fig. 9. Ilustración del Caso 4b

4 Estudio de Caso a través de un Sistema de Gestión deAprendizaje

A modo de ejemplo y para ilustrar la propuesta, se ha seleccionado el dominio delos LMS y algunos artefactos preexistentes en relación al mismo, que se describenen las siguientes secciones.

4.1 Ontología (Modelo conceptual)

Entre las definiciones de ontologías que existen cabe destacar la definición deGruber, 1993 “Una ontología es la especificación de una conceptualización” estoes, un marco común o una estructura conceptual sistematizada y de consenso nosólo para almacenar la información, sino también para poder buscarla y recu-perarla. Una ontología define los términos y las relaciones básicas para la com-presión de un área del conocimiento, así como las reglas para poder combinarlos términos para definir las extensiones de este tipo de vocabulario controlado.

El término conceptualización se refiere a un MC, que ayuda a organizar y es-tructurar el conocimiento adquirido usando lenguajes de representación (tablas,lenguaje unificado de modelado - UML, jerarquías) independientes de los lengua-jes de implementación. Es decir se basa principalmente en lenguaje natural [13].

Existe un creciente interés en ontologías como artefactos para la representacióndel conocimiento. Una ontología es generalmente considerada como un artefactodiseñado que consta de un vocabulario compartido específico utilizado para des-cribir entidades de algún dominio de interés, así como un conjunto de hipótesissobre el significado intencional de los términos en el vocabulario [15].

La ontología basada en tecnologías de la web semántica prometen solu-ciones para dar una definición explícita de la conceptualización compartida deun cierto dominio. De hecho, las ontologías restringen el conjunto de posiblesasignaciones entre símbolos y sus significados. Obviamente, la sistematizacióndel conocimiento y su estandarización proporciona una infraestructura para elconocimiento dentro de un sistema basado en el conocimiento [16].

En el dominio de los LMS o Sistemas de Gestión de Aprendizaje, en la últimadécada se han propuesto diferentes ontologías con el objetivo de alcanzar lamadurez conceptual necesaria como para identificar claramente ciertas variablesy precisar la calidad sistémica dentro de los procesos de selección e implantaciónde un LMS en una organización [17].

Gabriela Diaz-Anton y Maria A. Perez en el 2006 [15] proponen una ontologíade LMS basada en la exploración de los siguientes temas: (1) definición de E-learning, (2) definición de LMS, (3) LMS, CMS y LCMS, (4) Normas de AulaVirtual, (5) LMS de evaluación y elección (6) de aplicación LMS. Inicia con lacreación de modelos conceptuales para cada temática basados en definiciones,instrumentos de evaluación y estándares E-learning, estos modelos se integran enuna ontología que organiza y documenta todo el conocimiento que gira en tornoal concepto de LMS y ofrece una relación de conceptos para obtener un puntode vista global y sistémico en la implantación de un LMS en una organización.

4.2 Modelos de Calidad de Software

Luis A. Iñiguez, Malhena Sánchez y Johnny Solórzano en 2015 desarrollan unQM de LMS basado en la norma ISO/IEC 25010. Parten del modelo de negociode una organización orientada a brindar educación en modalidad E-learning parala cual se define una Arquitectura de Tecnologías de la Información (ATI) funda-mentada en requerimientos de calidad, utilizando el método DHARMA basadoen el uso de diagramas i* que concibe cuatro actividades básicas: (1) modeladodel entorno de la organización, (2) modelado del entorno del sistema, (3) de-scomposición de los objetivos del sistema y (4) identificación de la arquitecturagenérica del sistema. En el estudio, seleccionan el LMS como el sistema de in-formación más amplio y representativo de la ATI para elaborar el QM, tomandocomo base las características y subcaracterísticas de la norma ISO/IEC 25010(ver figura 10). El modelo de calidad del LMS presenta un conjunto de caracterís-ticas y subcaracterísticas con varias propiedades de calidad junto con medidaspara evaluar las propiedades de un LMS. Por último el modelo de calidad delLMS recomienda un conjunto de factores no técnicos que pueden ser evaluados.

Fig. 10. Modelo de calidad definido por la ISO/IEC 25010

4.3 Los casos de mapeo en la práctica

En esta sección se describe el mapeo encontrado entre el MC [15] y el QM1 pormedio de muestras. Para esto se inicia estableciendo el contexto utilizado parael mapeo.

El MC estaba originalmente conformado por 151 clases y en el caso del QMcontaba con 8 características, 30 subcaracterísticas y 61 propiedades de calidad,modelo que tambíen incluía factores no técnicos que recogían 2 características, 5subcaracterísticas y 16 propiedades de calidad. Ambos modelos fueron analizadosa detalle y se procedió a modificar su cobertura, debido a que se encontraban1 Luis A. Iñiguez, Malhena Sánchez y Johnny Solórzano - Trabajo de Modelos de

Calidad de la Maestría en Gestión Estratégica de Tecnologías de la Información,Universidad de Cuenca, 2015. Si es requerida contactarse con los autores del presenteartículo

clases que no eran pertienentes a un LMS, p.e., clases de un Sistema de Gestiónde Contenidos (CMS) y clases de un Sistema integral de gestión de contenidos yaprendizaje (LCMS). Después de este análisis se obtuvo para el MC 106 clases ypara el QM se obtuvo 8 características, 25 subcaracterísticas y 54 propiedades decalidad, para el caso de los factores no técnicos se mantuvo los mismos números.

Muestras encontradas:

– Aplicación de caso 1 - 1: Se identifica que una clase es compatible con unapropiedad de calidad (caso 1), argumentado en el sentido de que en unLMS tiene que estar presente herramientas que den soporte al “ curso”,considerando a la clase “Evaluación y Puntuación” como una parte del con-junto de herramientas del curso y que debe estar presente en los requisitoscontemplados dentro de la propiedad de calidad de la “Cursos” a través delos diferentes requisitos relacionados a los “Atributos de Evaluación”. Verfigura 11.

Fig. 11. Ilustración de la aplicación caso 1 - 1

– Aplicación de caso 1 - N: Se identifica que una clase es compatible conuna propiedad de calidad de diferentes subcaracterísticas (caso 2), argumen-tado en el sentido de que en un LMS tiene que estar presente herramientasde “Productividad”, considerando a un “Buscador interno” como una partedel conjunto de herramientas que permitan la productividad, buscador quenecesariamente tiene estar presente bajo su completitud funcional dentrolas propiedades de calidad de los “Reportes y búsquedas” a través de susrequisitos, y al mismo tiempo desde su pertinencia funcional como requisitoineludible dentro de las propiedades de calidad de las “Características delreporte”. Ver figura 12.

Fig. 12. Ilustración de la aplicación caso 1 - N

– Aplicación de caso N - 1: Se identifica que varias clases son compatiblescon una propiedad de calidad del QM (caso 3), argumentado en el sentidode que el “Lenguaje XML” utiliza estándares “E-learning” los cuales sondesarrollados una parte por “IMS” y otra parte por “ADLNet” a través de“SCORM”, estos requisitos deben ser cumplidos por el “Vendedor” contandocon Certificaciones obtenidas por el cumplimiento de esos estándares (Verfigura 13).

Fig. 13. Ilustración de la aplicación caso N - 1

– Aplicación de caso 0 - 0: Se identifica que ninguna clase de los atributos delMC pueden ser cotejados ya sea con las características, subcaracterísticas opropiedades de calidad del modelo de calidad (caso 4). Ver figura 14.

Fig. 14. Ilustración de la aplicación caso 0 - 0

Bajo el contexto de la aplicación del caso 0 - 0, se presenta dos casos:

1. El primero identifica el escenario en el que desde el MC se consideranmás herramientas de comunicación que las que están presentes en el QM(caso 4a). Es así que se incluye en el QM herramientas de comunicaciónrelacionadas a “ Notas/Diarios” y “ Pizarra electrónica” . Ver figura 15.

Fig. 15. Ilustración del caso 4a

2. El segundo identifica el escenario en el que existen características, subca-racterísticas o propiedades de calidad del QM que son incorporados comoclases al MC (caso 4b). Argumentado en el sentido de que las propiedadesde calidad “Banco de preguntas” “Cuestionarios” y “Tareas” no han sidoconsiderados en el MC y permiten extender este último. Ver figura 16.

Fig. 16. Ilustración del caso 4b

4.4 Algunos números

El resultado del mapeo realizado entre el MC y el QM ha permitido identificaruna serie de casos entre ambos modelos. Casos que han sido expuestos a través deun detallado análisis en el apartado anterior. Entonces surge la siguiente cuestión:¿cuál es la frecuencia de aparición de estos casos cuando intentamos mapeos deeste tipo?, para responder a esta pregunta se identificó estos resultados. Vertabla 1.

Tabla 1. Frecuencia de aparición de Casos

Casos Frecuencia PorcentajeCaso 1 1 - 1 30 65,22%Caso 2 1 - N 4 8,70%Caso 3 N - 1 10 21,74%Caso 4 0 - 0 2 4,35%Total 46 100%

Se identifica que el principal caso encontrado bajo este mapeo, es el caso 1,en el que una clase puede ser compatible con una propiedad de calidad, teniendouna frecuencia de aparición un 65%. Seguido por el caso 3, en el que varias clasesson compatibles con una propiedad de calidad, llegando a obtener un 21% deaparición. Los caso 2 y 4 son los menos encontrados, pues tiene una presenciaque bordea el 8% y el 4% respectivamente.

5 Conclusiones

La construcción de QM presenta retos que están particularmente relacionadoscon la dificultad de identificar los elementos de calidad apropiados a ser incluidosen su estructura. La ambigüedad semántica asociada a cada uno de ellos y la di-ficultad para determinar cuándo su estructura se encuentra concluida representaun reto al momento de desarrollar QM.

A pesar que existen lineamientos, que buscan guiar el desarrollo de los QM,la mayoría de los QM propuestos presentan solo un conjunto de elementos decalidad de alto nivel de abstracción que deben ser descompuestos en elementosmás específicos con el propósito de hacerlos evaluables, lo que se convierte enuna limitante ya que no proporcionan un fundamento para guiar en la descom-posición.

En este artículo hemos presentado una propuesta de 5 casos de mapeo quepueden ser utilizados para extender los QM en base a los conceptos incluídosen el MC. Estos casos presentan importantes ventajas respecto a métodos deconstrucción de QMs mas tradicionales, debido a:

1. Permite que la construcción de los QM sea realizada con un importantesustento semántico que reduce notablemente la ambigüedad.

2. La extención del la jerarquía del QM puede ser controlada en base a lacobertura de los conceptos relevantes para el dominio que se encuentrendescritos en el MC.

3. La interacción del los participantes en el procesos de QM es soportada por unartefacto que aclara los conceptos apropiados para el dominoio de software,incluso cuando el equipo este integrado por personas con baja experienciaen el dominio o en la construcción de QMs.

A futuro pretendemos explorar posibles nuevos casos que se deriven de lasasociaciones exitentes entre clases (asociación, composición o herencia), porejemplo la descomposición de subcaracterísticas en base a las áreas conceptualesque estas asociaciones describan en el modelo.

6 Agradecimientos

Este estudio ha sido financiado por el Consorcio Ecuatoriano para el Desarrollode Internet Avanzado (CEDIA), a quienes agradecemos por el proyecto de inves-tigación: “Proyecto Repositorios de Aprendizaje” y el apoyo para la consolidaciónde esta investigación.

Referencias

1. J.P. Carvallo, “Systematic Construction of Quality Models for Cots-Based Systems”.PhD thesis, Departament de Llenguatges i Sistemes Informàtics, Universitat Politèc-nica de Catalunya, (2005)

2. R.G. Dromey. A Model for Software Product Quality. IEEE TSE 21, (1995)3. Correia, J., Kanellopoulos, Y., Visser, J. A survey-based study of the mapping of

system properties to ISO/IEC 9126 maintainability characteristics. Software Main-tenance, ICSM. IEEE International Conference on, 1, 10. (2009)

4. Juristo, N., Moreno, A., Sanchez-Segura,. M.-I. Guidelines for Eliciting UsabilityFunctionalities. Software Engineering, IEEE Transactions on, 33, 15.

5. Chotjaratwanich, U., Arpnikanondt, C. A Visualization Technique for Metrics-Based Hierarchical Quality Models. Software Engineering Conference (APSEC),19th Asia-Pacific, 1, 4 (2012)

6. Munawar, M., Salim, N., Ibrahim, R. Towards Data Warehouse Quality throughIntegrated Requirements Analysis. Advanced Computer Science and InformationSystem (ICACSIS), International Conference on, 1, 6 (2011)

7. X. Franch, J.P. Carvallo. Using Quality Models in Software Package Selection. IEEESoftware 20(1), (2003)

8. ISO/IEC Standard 25000. Software engineering Software product Quelite Require-ments and Evaluation (SQuaRE) Guide to SQuaRE, (2005).

9. T. Gilb. Principles of Software Engineering Management. Addison Wesley, (1988).10. C. Lampasona et al. Software quality modeling experiences at an oil company.

ESEM (2012)11. B.W. Boehm, J.R. Brown, H. Kaspar, M. Lipow, G.J. MacLeod, M.J.: Merritt, “

Characteristics of Software Quality”, North Holland Publishing Company, (1978)12. V. Basili, G. Caldeira, and H. Rombach, “The Goal Question Metric Approach”,

in J. Marciniak (ed.), Encyclopedia of Software Engineering, John Wiley and Sons.1994.

13. Coriel, M., Ramos, L., Borgies, A., Contreras, L., Gil, R.: Modelo ontológico comoapoyo a la toma de decisiones en oportunidades de estudio. Revista de la Facultadde Ingeniería. U.C.V., 29-37 (2010)

14. R.G. Dromey. “Cornering the Chimera”. IEEE Software, vol. 20, January 1996.15. Diaz-Antón, M. G.: Towards an Ontology of LMS - A Conceptual Framework.

ResearchGate. (2006)16. Kholief, M., Nada, N., Khedr , W.: Ontology-Oriented Inference-based Learning

Content Management System. International Journal of Web & Semantic Technology(July de 2012)

17. Carvallo, J., Franch, X., Quer, C.: Improving quality model construction throughknowledge reuse. XVIII Ibero-American Conference on Software Engineering, 549-562 (April de 2015)

18. Dávila , A., Melendez , K., Flores , L.: Determinación de los Requerimien-tos de Calidad del Producto Software Basados en Normas Internacionales. IEEELatinAmerica-Transactions, 4, 100-106 (2006)

19. V.R. Basili, “Software modeling and measurement. The Goal-Question-Metricparadigm”, Computer Science Technical ReportSeries NR: UMIACS-TR-92-96, 1992

20. Gordieiev , O., Kharchenko, V., Fominykh , N., Sklyar , V.: Evolution of SoftwareQuality Models in Context of the Standard ISO 25010 (2014)