María Belén Rivera

Facultad de Ingeniería - Universidad Nacional de La Pampa

Enfoque Integrado de Medición, Evaluación y Mejora de Calidad con soporte a Metas de Negocio y de Necesidad de Información: Aplicación de Estrategias a partir de Patrones de Estrategia

Tesis para obtener el grado de: Doctor en Ciencias Informáticas
Universidad Nacional de La Plata
22 de Marzo de 2018

Director: Dr. Luis Olsina
Co-Director: Dr. Gustavo Rossi

Primera edición - EPUB - ISBN: 978-950-863-359-0

Editorial EdUNLPam - 01.06.2019

Rivera, Marma Belen
Enfoque integrado de medicisn, evaluacisn y mejora de calidad con soporte a metas de negocio y de necesidad de informacisn : aplicacisn de estrategias a partir de patrones de estrategia / Marma Belen Rivera. - 1a ed mejorada. - Santa Rosa : Universidad Nacional de La Pampa, 2019.
Libro digital, EPUB - (Publicacisn de tesis de grado, maestrma, doctorado y trabajos finales de especializacisn ; 2)

Archivo Digital: descarga y online ISBN 978-950-863-359-0

1. Ingenierma Informatica. I. Tmtulo. CDD 004

Resumen

En toda organización de software madura, se debe asegurar la mejora continua de la calidad de los productos, servicios, procesos y recursos. Para ello, no solo es necesario contar con actividades de medición y evaluación que permitan conocer la situación real o estimada de una entidad, analizando y detectando debilidades y vulnerabilidades; sino que también es preciso contar con actividades que permitan introducir cambios orientados a la mejora. Un modo ingenieril de organizar las actividades y recursos involucrados es mediante la gestión de proyectos de medición, evaluación y/o cambio. Estos proyectos operacionalizan metas de necesidad de información de medición y evaluación. Por ejemplo, una meta de este tipo puede ser “comprender el estado actual de una aplicación móvil respecto a la característica usabilidad”. Estas metas constituyen un tipo de meta de necesidad de información que da soporte a metas de negocio operativas, las cuales debieran estar alineadas con metas de negocio estratégicas.

A su vez, una estrategia integrada ayuda a alcanzar las metas de un proyecto mediante sus actividades y métodos bien establecidos. En especial, la aplicación de dichas estrategias para llevar a cabo metas de necesidad de información de medición y evaluación, se puede realizar a partir de la instanciación de patrones de estrategia.

La presente tesis doctoral se centra en definir un Enfoque Multinivel y Multipropósito de Evaluación de la Calidad que permita establecer metas de necesidad de información de medición y evaluación vinculadas con metas de negocio a distintos niveles organizacionales. Promueve además, la utilización de estrategias integradas específicas para llevar a cabo dichas metas, por medio de la instanciación de patrones de estrategia, como modo de proveer soluciones reusables a problemas recurrentes en la instanciación de estrategias integradas empleadas en proyectos de medición, evaluación y/o cambio.

Agradecimientos

Gracias, muchas gracias, a mi director Luis Olsina y a Pablo Becker. Porque sin el esfuerzo, entusiasmo, disciplina y directiva de Luis y el compañerismo, la dedicación, la tranquilidad para transmitir las ideas y organizar el trabajo de Pablo, este trabajo no hubiera sido posible. Sinceras muchas gracias, a mi co-director Gustavo Rossi, a María Silvia Di Liscia y autoridades de la Facultad de Ingeniería de la UNLPam. Si no hubiera sido por la cordialidad de Gustavo en La Plata, así como también su indudable respaldo académico; por el incentivo continuo y la confianza de María Silvia y por el apoyo económico de la Facultad de Ingeniería y de la UNLPam, este trabajo hubiera resultado costoso en muchos aspectos.

Dedico también miles de gracias a quienes a través de su amistad, me acompañaron en este proceso. A Gabriela B. y Leandro M. dado que su compañerismo inmediato y la predisposición que demostraron para sumarme a sus grupos de pares del LIFIA, permitieron que enseguida me sienta en confianza y rodeada de un grupo de personas excelentes. Siempre estaré agradecida por el buen trato recibido y el intercambio de experiencias y saberes generado. También fueron valiosísimos los consejos, el tiempo y la contención que, sin dudar, me brindaron Fernanda P., Juancho H., Mirta M., Verónica V. y Araceli H.. Y la colaboración con el caso práctico de Guido y Denis.

“Gracias Totales” (como así prefiere mi mamá) a mis padres, María Antonia y Osvaldo por acompañarme una vez más y demostrarme continuamente que querer es poder. A Luján, mi adorada hermana quien ha cubierto siempre mis ausencias, brindando su ayuda absoluta. A Roberto, por su infinita paciencia e incondicional amor. A mis abuelos, donde estén.

Por último, agradezco el cariño de mis amistades de siempre y la atención de compañeros y profesores del doctorado con los cuales me enriquezco profesionalmente.

A todos, gracias por su tiempo, ayuda y lección.

María Belén

Tabla de contenidos

Portada

Enfoque Integrado de Medición, Evaluación y Mejora de Calidad con soporte a Metas de Negocio y de Necesidad de Información: Aplicación de Estrategias a partir de Patrones de Estrategia

Resumen

Agradecimientos

Tabla de contenidos

Parte I: Introducción y Fundamentos de Estrategias de Medición y Evaluación

Capítulo 1 - Introducción

1.1. Motivación

1.2. Objetivos

1.3. Contribuciones

1.4. Otras publicaciones

1.4.1. Revistas (Journals) Internacionales

1.4.2. Congresos Internacionales/Iberoamericanos

1.4.3. Congresos y Revistas Nacionales

1.4.4. Otras publicaciones

1.5. Estructura

Capítulo 2 - Estrategias Integradas de Medición y Evaluación

2.1. ¿Qué es una Estrategia?

2.2. Estrategias Integradas

2.2.1. Estrategia Integrada GOCAME

2.2.2. Estrategia Integrada SIQinU

2.2.3. Estrategia Integrada GOCAMEC

2.3. Marco Conceptual para Estrategias Integradas de Medición y Evaluación

2.3.1. Componente de Proyecto

2.3.2. Componente de Requisitos No Funcionales

2.3.3. Componente de Contexto

2.3.4. Componente de Medición

2.3.5. Componente de Evaluación

2.4. Procesos de Estrategias Integradas de Medición y Evaluación

2.4.1. Proceso de GOCAME

2.4.2. Proceso de SIQinU

2.4.3. Proceso de GOCAMEC

2.5. Métodos de Medición y Evaluación

2.6. Conclusiones

Parte II: Estado del Arte, Problema Detectado y Solución Propuesta

Capítulo 3 - Estado del Arte

3.1. Vistas de Calidad

3.2. Enfoques Multinivel y Estrategias Integradas Orientados a Medición, Evaluación y Mejora de la Calidad

3.2.1. GQM+ Strategies-Goal Question Metric Plus Strategies

3.2.2. BSC-Balanced Scorecard

3.2.3. GQ(I)M Goal Question (Indicator) Metric

3.2.4. BSC-GQ(I)M

3.2.5. Guía de Medición Orientada a Metas

3.2.6. PSM-Practical Software and Systems Measurement

3.2.7. Estrategias integradas GOCAME, SIQinU y GOCAMEC

3.3. Patrones de Estrategia de Medición y Evaluación

3.4. Conclusiones

Capítulo 4 - Resumen de la Problemática Detectada y la Solución Propuesta

4.1. Problemática Detectada

4.2. Solución Propuesta

Parte III: Desarrollo de la Solución Propuesta

Capítulo 5 - Vistas de Calidad en el Enfoque de Evaluación de Calidad

5.1. Ontología de Vistas de Calidad

5.2. Relación entre Vistas de Calidad y Requisitos No Funcionales

5.3. Conclusiones

Capítulo 6 - Metas de Negocio y de Necesidad de Información en el Enfoque de Evaluación de Calidad

6.1. Metas de Negocio y Metas de Soporte

6.2. Ontología de Metas de Negocio y de Proyecto

6.3. Conclusiones

Capítulo 7 - Patrones de Estrategia

7.1. Vistas de Calidad y Patrones de Estrategia

7.2. Patrón de Estrategia GoME_1QV

7.3. Patrón de Estrategia GoMEC_1QV

7.4. Patrón de Estrategia GoMEC_2QV

7.5. Discusión de Otros Patrones de Estrategia

7.6. Conclusiones

Capítulo 8 - Pasos del Enfoque de Evaluación de Calidad: Un Caso Aplicado

8.1. Aplicabilidad del Enfoque de Evaluación de Calidad

8.2. Prueba de Concepto

8.2.1. Establecimiento de las metas de negocio y las metas de necesidad de información

8.2.2. Prosecución de la meta de necesidad de información de medición y evaluación

8.2.3. Verificación de las metas de negocio

8.3. Conclusiones

Capítulo 8 - Implementación de la Ontología de Vistas de Calidad y Metas de Negocio

9.1. Metodologías para el Desarrollo de Ontologías

9.2. Desarrollo de la Implementación

9.2.1. Especificación

9.2.2. Conceptualización

9.2.3. Implementación

9.2.4. Evaluación

9.3. Conclusiones

Parte IV: Conclusiones y Trabajos Futuros

Capítulo 10 - Conclusiones y Trabajos Futuros

10.1. Cumplimiento de Objetivos y Contribuciones Realizadas

10.2. Trabajos Futuros

Notas

Referencias

Apéndice A

Documento OWL

Parte I:
Introducción y Fundamentos de Estrategias de Medición y Evaluación

Capítulo 1 - Introducción

El aumento paulatino del desarrollo de sistemas y aplicaciones software y web es indiscutible. Sin embargo, para que sean aceptadas por los usuarios, es necesario que dichos sistemas y aplicaciones alcancen ciertos niveles de calidad, de igual modo para los procesos y recursos que intervienen en su desarrollo. Por consiguiente, las organizaciones de software y web deben contar con mecanismos de medición y evaluación de la calidad a fin de asegurar la calidad de sus productos y procesos.

Desde hace tiempo la medición de la calidad constituye un área fundamental para la Ingeniería de Software, siendo transversal al resto de las áreas de una organización de software. Actualmente existen modelos de madurez, estándares, metodologías y guías que ayudan a una organización a mejorar y resaltan la importancia de los procesos de medición como buena práctica de la gestión de la calidad. Por ejemplo, la guía SWEBOK (Software Engineering Body of Knowledge) [Bourque et al., 2014] define quince áreas de conocimiento de Ingeniería de Software. Una de ellas, denominada Proceso de la Ingeniería de Software, trata con la definición del proceso y el ciclo de vida del software, junto con la definición de procesos de medición, evaluación y mejora del software y, herramientas del proceso de Ingeniería de Software. A su vez, esta área se divide en cinco sub-áreas, donde una de ellas se enfoca específicamente en la medición de la calidad de los productos software y de los procesos. Si bien el tema de medición es un aspecto importante en todas las áreas de conocimiento de la guía SWEBOK, es en esta área donde se presenta el tema de programas de medición. Por su parte, el área de conocimiento Calidad de Software se ocupa de las consideraciones sobre prácticas, herramientas y técnicas para definir la calidad del software y para evaluar el estado de la misma durante el ciclo de vida del software. Las menciones referidas a medición se hacen presentes también en el área de conocimiento denominado Fundamentos de Ingeniería, en el cual, uno de los tópicos (Medición), explora la teoría de medición, destacando su rol en ingeniería y describe algunos conceptos importantes aplicables a la medición del software, como por ejemplo, atributo, medición directa e indirecta y escalas.

Otro ejemplo es CMMI (Capability Maturity Model Integration) [CMMI Product Team, 2010] el cual enfatiza también, la importancia de contar con un área de medición en una organización de software. Este estándar de facto, para su representación por etapas, define cinco niveles de madurez, a saber: 1) Inicial, 2) Gestionado, 3) Definido, 4) Gestionado Cuantitativamente y, 5) En Optimización. En el nivel 2 (Gestionado), dos de las áreas de proceso de soporte que la organización debería utilizar para orientar la mejora de procesos, es la de Medición y Análisis y la de Aseguramiento de la Calidad del Proceso y del Producto. Esto significa que ya en el nivel de madurez 2, CMMI establece el desarrollo de actividades de medición, en este caso, para dar soporte a las necesidades de información de la gerencia. En otras palabras, proveer a la dirección de la organización, con los datos adecuados para una correcta toma de decisión. Por su parte, el área de proceso Aseguramiento de la Calidad del Proceso y del Producto da soporte a la entrega de productos de alta calidad, proporcionando al personal y a la gerencia una visión objetiva de los procesos y de los productos de trabajo asociados. El nivel 4 (Gestionado Cuantitativamente) implica que la organización cuenta con datos cuantitativos (medidas) relacionados a la calidad basados en las necesidades del cliente.

Las áreas de proceso Medición y Análisis y Aseguramiento de la Calidad del Proceso y del Producto dan soporte a todas las áreas de proceso de cada nivel de madurez, proporcionando prácticas específicas que permiten, por un lado, desarrollar enfoques de medición y por otro, garantizar la entrega de productos y servicios de alta calidad, respectivamente.

Dependiendo del nivel de madurez de una organización (2, 3, 4 ó 5), las actividades de medición se realizan de distintas maneras. En los niveles iniciales de madurez, tales como los niveles 2 y 3, el foco está puesto en desarrollar procesos de medición que otorguen datos para dar soporte a necesidades de información gerenciales. En niveles de madurez más alto, tales como 4 y 5, la medición se lleva a cabo como un control estadístico de procesos. Esto implica comprender el comportamiento de los procesos a través de la utilización de un conjunto de técnicas estadísticas que determinan si un proceso está bajo control, es decir, si su comportamiento es estable, con variaciones dentro de los límites esperados, calculados a partir de datos históricos.

Por lo expuesto, la medición efectiva se ha convertido en una de las piedras angulares de la madurez de una organización [Bourque et al., 2014]. Los procesos de medición son fundamentales dado que permiten cuantificar un conjunto de características deseadas acerca de un aspecto específico de alguna entidad en particular, proveyendo una visión más o menos detallada de su estado o condición. Sin embargo, la medición como tal, sólo recolecta medidas, es decir, un conjunto de valores que no otorgan por sí solos información alguna, careciendo por lo tanto, de utilidad para la toma de decisiones. Se necesita interpretar dichos datos, con el fin de obtener información cuantitativa o cualitativa. Para esto, se emplea la evaluación. A través de la utilización de indicadores, es posible interpretar los valores medidos, brindando así información útil para la toma de decisiones [Olsina et al., 2008b]. El uso de indicadores contribuye a conocer el nivel de satisfacción alcanzado para los atributos y características de una entidad. Adicionalmente, las actividades de medición y evaluación pueden ser complementadas con actividades que permitan introducir cambios orientados a la mejora.

Claramente las organizaciones de software debieran entonces promover proyectos y programas de medición y evaluación y/o cambio como punto inicial para saber dónde están y hacia dónde se dirigen en materia de calidad de los productos que desarrolla, servicios que ofrece o procesos que en ellas intervienen. Cada proyecto de este tipo operacionaliza una meta de necesidad de información de medición y evaluación, la cual contiene un propósito determinado, como por ejemplo comprender, predecir, controlar o mejorar. Para aquellas metas de necesidad de información de medición y evaluación con el propósito de controlar o mejorar, el proyecto que las operacionaliza es uno relacionado a medición, evaluación y cambio, el cual implica efectuar cambios dirigidos por evaluación a fin de tener la entidad bajo control, o, según el caso, mejorarla.

Un proyecto de medición, evaluación y/o cambio tiene que prever la utilización de una estrategia que ayude a alcanzar la meta de necesidad de información de medición y evaluación que operacionaliza. En el acervo diario, una estrategia constituye un conjunto de acciones planificadas sistemáticamente en el tiempo que se llevan a cabo para lograr un fin o misión. En [Papa, 2012] se define una estrategia integrada como un recurso organizacional que ayuda a alcanzar metas de necesidad de información de medición y evaluación siguiendo un determinado curso de acción, basado en un conjunto de métodos apropiados y una base conceptual que define el dominio de aplicación de la estrategia.

Si bien se ha resaltado que, en la implementación de proyectos de desarrollo de software, los procesos de medición suponen, junto con los de evaluación, una de las actividades principales previstas en los estándares para el control y el aseguramiento de la calidad, a menudo las organizaciones de software suelen encontrar problemas cuando establecen procesos de este tipo. En este sentido, se observa que recolectan muchos datos, pero no son capaces de determinar si son útiles o no, y no cuentan con estrategias adecuadas que permitan operacionalizar las metas de medición de modo que contribuyan a decisiones estratégicas [Basili et al., 2010]. Esto se debe a que frecuentemente las organizaciones dedicadas al software no establecen metas de negocio y de necesidad de información a distintos niveles, o bien, éstas no suelen estar alineadas. De acuerdo con esto, Basili et al. [Basili et al., 2007b], [Basili et al., 2010] sostienen que una cuestión crítica en una organización es la falta de vinculación entre las metas de nivel estratégico con las de nivel operativo.

El problema de la falta de alineamiento entre metas de necesidad de información de medición y metas de negocio estratégicas, fue señalado también por Becker y Bostelman, quienes mencionan las siguientes causas de dicho desalineamiento: [Becker y Bostelman,1999]

– Las decisiones estratégicas son desconocidas o no utilizadas en el desarrollo de metas de proyecto (metas de medición).

– A nivel de proyecto, los datos que se obtienen no soportan o no se condicen con las metas organizacionales.

– Los indicadores financieros tienden a conducir la toma de decisión estratégica.

– La medición se realiza de manera mecánica sin un claro propósito del porqué se está llevando a cabo.

– La medición se realiza de manera aislada de otros proyectos.

Por lo tanto, toda organización debiera establecer objetivos o metas de negocio alineados a distintos niveles organizacionales, tales como estratégico, táctico y operativo y, las organizaciones de software, no deberían ser la excepción. Pero si, en caso contrario, las metas que se formulan a nivel operativo no están alineadas con alguna meta de nivel táctico o estratégico, la organización puede mal direccionar sus esfuerzos y malgastar recursos, especialmente, podrían no justificar los esfuerzos invertidos en el desarrollo de la medición. Al respecto, CMMI también afirma que, si bien el foco inicial para las actividades de medición es a nivel de proyecto, las mismas debieran dar soporte a necesidades de información a distintos niveles organizacionales, como por ejemplo, a nivel estratégico. Agrega además, que los objetivos de medición se derivan de necesidades de información que provienen de objetivos de negocio u organizacionales.

Además de establecer metas de negocio a distintos niveles, una organización debe establecer metas de necesidad de información las cuales constituyen metas de soporte a las metas de negocio, y permiten conocer en qué medida se está alcanzando la meta de negocio con la cual están relacionadas. Un tipo particular de meta de necesidad de información es la meta de necesidad de información de medición y evaluación de la que se viene hablando [Rivera et al., 2016b].

En consecuencia, es de suma importancia que las organizaciones de software que gestionen el aseguramiento de la calidad a través de proyectos de medición, evaluación y/o cambio cuenten con un enfoque de evaluación de la calidad sistemático que les permita establecer y alinear metas a diferentes niveles organizacionales, además de definir proyectos y estrategias en pos de alcanzar tales metas. Si bien en la literatura existen enfoques que consideran algunos de estos aspectos, no se encuentran integrados, tal como se discutirá a lo largo de esta tesis. De acuerdo con esto, se propone un enfoque multinivel de evaluación de la calidad que puede ayudar a las organizaciones de software a establecer metas de necesidad de información de medición y evaluación para dar soporte a metas de negocio formuladas a nivel operativo y vinculadas con metas de negocio a distintos niveles organizacionales. Además, el enfoque propuesto promueve la selección de estrategias integradas para proyectos de medición, evaluación y/o cambio a partir de patrones de estrategias [Rivera et al., 2016a]. Los patrones de estrategia brindan solución a problemas relacionados con la instanciación de estrategias integradas específicas en el área de aseguramiento de calidad del software.

1.1. Motivación

Según el modelo de representación por etapas de CMMI, el primer paso que debe enfrentar una organización en su camino a la madurez, es ascender hasta el nivel 2: el nivel Gestionado. Pasar de una manera ad-hoc a una forma disciplinada y estable de definir y gestionar los procesos involucrados en cada proyecto es, quizás, el salto más complicado para una organización. Desde ese momento, la organización ya tiene que, entre otras cuestiones, desarrollar y mantener actividades de medición que permitan obtener datos cuantitativos para dar soporte a las necesidades de información, tal como se indicó en la Introducción al respecto. En este sentido, y considerando el propósito del área de proceso de Medición y Análisis, en el nivel 2 es menester que una organización, en su carrera por alcanzar la madurez de sus procesos, considere las metas de necesidad de información de medición alineadas, para que no sean establecidas de manera aislada.

El tema del alineamiento organizacional está constantemente entre los diez principales intereses de los ejecutivos de las últimas dos décadas [Luftman y Ben-Zvi, 2010]. Al respecto, Basili et at. [Basili et al., 2010] indican que una cuestión crítica en las organizaciones es la falta de vinculación entre metas formuladas a nivel estratégico (o nivel de gestión, considerando la palabra que emplean) con aquellas metas formuladas a un nivel operativo (proyecto). Concretamente, los autores establecen que “el problema no es que las organizaciones fal lan en alcanzar sus objetivos, sino que no siempre establecen estos objetivos de manera clara o lo suficientemente explícitos como para verificar que realmente los han alcanzado. Es aún un poco menos claro como la organización traduce sus objetivos en otros de niveles organizacionales y en proyectos. Al presente no hay una metodología que cubra el hueco entre estrategias de negocio y sus implementaciones a nivel de proyecto” [Basili et al., 2010, p.58].

Considerando la primera parte de la cita expuesta, dos décadas antes Gilb et al. [Gilb y Finzi, 1988] indicaron que, proyectos sin metas claras no alcanzarán sus metas claramente. Respecto de la segunda parte de la cita de Basili, una década anterior Park et al. [Park et al., 1996] afirmaron que el correcto establecimiento de metas de negocio a diferentes niveles organizacionales determina gran parte del éxito en la ejecución del proyecto. Como consecuencia, si las metas en un nivel operativo no están alineadas con metas a niveles tácticos o estratégicos, la organización puede direccionar sus esfuerzos y recursos de manera equivocada.

En [Olsina et al., 2008b] se presenta un enfoque de medición y evaluación que considera metas de necesidades de información de medición y evaluación a nivel de proyecto, sin especificar cómo derivan de metas de otros niveles, principalmente de metas de negocio a nivel estratégico. Para llevar a cabo esas metas, el enfoque promueve el empleo de estrategias integradas, las cuales poseen tres capacidades [Papa, 2012]: (1) un marco conceptual de dominio, (2) una especificación de las perspectivas del proceso y (3) una especificación de métodos. Distintas estrategias integradas podrían distinguirse de acuerdo al propósito de la meta de necesidad de información de medición y evaluación y la cantidad de vistas de calidad involucradas en la misma (vista de calidad de sistema, por ejemplo). Considerar estos aspectos permite que la estrategia integrada sea la adecuada para una meta específica, de manera tal de proveer el curso de acción correcto para llevarla a cabo. Además, consolidar todo el conocimiento sobre la instanciación de estrategias integradas para distintas situaciones, en soluciones probadas como patrones de estrategia, permitiría consolidar una base de experiencias reusables al momento de instanciar dichas estrategias.

Las vistas de calidad han sido caracterizadas desde los años ’80, principalmente por Garvin, quien definió a la calidad desde cinco perspectivas [Garvin, 1984], a saber: (1) vista trascendental, (2) vista de usuario, (3) vista de manufactura, (4) vista de producto y (5) vista basada en el valor. Por su parte, los estándares ISO 9126 [ISO/IEC, 2001] e ISO 25010 [ISO/IEC, 2011] consideran también de algún modo, vistas de calidad y determinan relaciones de “influencia” y “depende de” entre ellas. Dichas relaciones se fundamentan en la premisa subyacente de la administración de procesos de software que establece que, la calidad de un producto software es determinada por la calidad del proceso empleado en desarrollarlo y mantenerlo [Humphrey, 1989]. La industria del software, como cualquier otra industria, puede mejorar solo de un modo, comprendiendo el producto y el proceso que lo generó.

En base a lo expuesto, y considerando trabajos como [Park et al., 1996], [PMI,2013] y afirmaciones como “...al momento ninguna metodología cierra la brecha entre estrategias de negocio y su implementación a nivel de proyecto” [Basili et al., 2010, p.58], es que en el presente trabajo se construyen las principales motivaciones para actualizar y robustecer el citado enfoque de evaluación de la calidad.

Por un lado, se pretende adaptar y rediseñar el enfoque inicial propuesto en [Olsina et al., 2008b] para que contemple metas a diferentes niveles organizacionales, principalmente, explicitar la relación entre metas de necesidades de información de medición y evaluación con metas de negocio de otros niveles. Por otro lado, que se establezca la formulación de proyectos y se defina la utilización de la estrategia integrada adecuada para alcanzar las metas establecidas en los proyectos, considerando las vistas de calidad involucradas en la meta y su propósito de evaluación. En este sentido, Basili et al. han desarrollado GQM+ Strategies [Basili et al., 2007b], [Basili et al.,2010], [Trendowicz et al., 2014] enfoque que al momento, constituye una solución en el alineamiento de metas operativas con metas organizacionales. Sin embargo, se observan algunas oportunidades de mejora a este enfoque, que serán abordadas a lo largo del presente trabajo.

El enfoque propuesto se denomina Enfoque Multinivel y Multipropósito de Evaluación de la Calidad (de aquí en más, se mencionará como Enfoque de Evaluación de Calidad ). Dicho enfoque se caracteriza por tres aspectos principales, los cuales dan origen a las contribuciones aportadas por la presente tesis:

La identificación de vistas de calidad y las relaciones entre ellas, en las metas de necesidad de información de medición y evaluación en conjunto con el tipo de propósito de evaluación que las mismas declaran.

La definición de metas de negocio y de necesidad de información multinivel, y la formulación de proyectos de medición, evaluación y/o cambio para operacionalizar específicamente las metas de necesidad de información de medición y evaluación.

La adopción de patrones de estrategia para la instanciación de estrategias integradas específicas que ayuden a alcanzan los propósitos de evaluación de las metas de necesidad de información de medición y evaluación.

El Enfoque de Evaluación de Calidad se compone además de bases conceptuales, estructuradas en ontologías, para el dominio de medición y evaluación que relacionan conceptos de metas de negocio y metas de necesidades de información, con necesidades de información de medición y evaluación, categoría de entidad, foco de calidad y vistas de calidad, además de conceptos de proyecto, estrategia y patrones de estrategia. Tener los términos del dominio modelados como ontologías permite posteriormente traducirlos en un lenguaje formal ontológico y utilizar dicha formalización para la construcción de un servicio web semántico que recomiende patrones de estrategia.

En síntesis, la motivación de esta tesis es contribuir en el área de aseguramiento de calidad, particularmente en lo concerniente a procesos de medición y evaluación, actualizando el enfoque de medición y evaluación presentado en [Olsina et al., 2008b] para contemplar metas de necesidad de información de medición y evaluación que den soporte a metas de negocio formuladas a diferentes niveles organizacionales, tal como sostiene la literatura al respecto. Además, se persiguen otras mejoras relacionadas a la instanciación de estrategias integradas a partir de patrones de estrategia, de acuerdo a las vistas de calidad que se consideran y al propósito de la meta que la estrategia ayuda a alcanzar.

1.2. Objetivos

Considerando las aserciones presentadas en la sección anterior, la presente tesis persistirá en dar respuesta a los siguientes interrogantes:

– ¿Por qué es útil considerar vistas de calidad en una meta de necesidad de información de medición y evaluación?

– ¿Por qué es importante para una organización tener sus metas de necesidad de información de medición y evaluación (a nivel operativo) alineadas con metas de negocio de distintos niveles organizacionales?

– ¿Qué relación puede establecerse entre una meta operativa de necesidad de información de medición y evaluación y las metas principales de negocio?

– ¿Cómo se puede elegir la estrategia integrada adecuada para l levar a cabo una meta de necesidad de información de medición y evaluación?

– ¿Qué beneficios acarrearía el uso de patrones de estrategia para instanciar estrategias integradas de medición y evaluación?

En base a estas preguntas de investigación, el objetivo general del presente trabajo consiste en robustecer el enfoque integral de evaluación de calidad que se presenta en [Olsina et al., 2008b] de manera tal de incluir el alineamiento de necesidades de información de medición y evaluación con metas de negocio, así como también proveer

un mecanismo de selección de la estrategia más adecuada a partir de la instanciación de su patrón de estrategia, considerando vistas de calidad, sus relaciones y el propósito de evaluación de la meta de necesidad de información de medición y evaluación.

El objetivo general se descompone en los siguientes objetivos específicos:

– Ampliar la base conceptual del enfoque integral de evaluación de calidad en [Olsina et al., 2008b] para incluir terminología relacionada a vistas de calidad, metas, proyectos, estrategias y patrones de estrategia.

– Formalizar la nueva base conceptual en ontologías de vistas de calidad y metas de negocio y proyecto.

– Especificar patrones de estrategia para generalizar el conocimiento sobre la utilización de distintas estrategias integradas de medición y evaluación.

– Establecer los pasos para utilizar el nuevo Enfoque de Evaluación de Calidad.

1.3. Contribuciones

Las contribuciones de esta tesis se resumen en los siguientes puntos:

– Una ontología de vistas de calidad.

– Una ontología de metas de negocio y proyecto.

– Un conjunto de patrones de estrategia que permiten la instanciación de distintas estrategias integradas para resolver el propósito de evaluación de metas de necesidad de información de medición y evaluación.

– Un enfoque integrado de medición, evaluación y mejora de calidad que provea soporte a metas de negocio y de necesidad de información a distintos niveles organizacionales y la aplicación de estrategias por medio de la instanciación de patrones de estrategia.

1.4. Publicaciones

Esta tesis se ha desarrollado en el contexto de los trabajos de investigación llevados a cabo en el grupo de investigación GIDIS_Web de la Facultad de Ingeniería de la Universidad Nacional de La Pampa. A continuación se listan, por un lado, las publicaciones que han dado soporte al desarrollo de la presente tesis. Por otro lado, también se detallan aquellas publicaciones que tienen una relación indirecta con los objetivos particulares desarrollados en la presente tesis.

1.4.1. Revistas (Journals) Internacionales

– A Holistic Quality Evaluation, Selection and Improvement Approach driven by Multilevel Goals and Strategies (Rivera B., Becker, P., Papa, M.F., Olsina L.). En: CLEI Electronic Journal, Vol.19, N.3, Paper 3, pp. 1-28. ISSN 0717-5000, 2016.

– Quality Views and Strategy Patterns for Evaluating and Improving Quality: Usability and User Experience Case Studies (Rivera B., Becker, P., Olsina L.). En: Journal of Web Engineering (JWE), Rinton Press, US, Vol.15, N.56, pp.

433-464. ISSN 1540-9589, 2016.

1.4.2. Congresos Internacionales/Iberoamericanos

– Hacia la Evaluación y Mejora de Software dirigidas por Metas Multinivel y Estrategias. (Rivera B., Becker, P., Papa, M.F., Olsina L.). En Proceed. de la XIX Conferencia Iberoamericana en Software Engineering (CIbSE’16), pp. 1-14, Quito, Ecuador, 2016.

– Patrones de Estrategia para Proyectos de Medición, Evaluación y Mejora (Rivera B., Becker, P., Olsina L.). En Proceed. de la XVIII Conferencia Iberoamericana en Software Engineering (CIbSE’15). ISBN: 978-9972-825-80-4, pp. 166-180, Lima, Perú, 2015.

– Towards Strategy Patterns for Evaluating Usability (Rivera B., Becker, P., Lew P., Olsina L.). En: 15 Int’l Conference on Web Engineering (ICWE’15). LNCS 9114, P. Cimiano, F. Frasincar, G-J. Houben, and D. Schwabe (Eds.), Springer

International Publishing Switzerland, pp. 705-708, Rotterdam, Netherlands, 2015.

1.4.3. Congresos y Revistas Nacionales

– A Quality Evaluation and Improvement Approach driven by Multilevel Goals and Strategy Patterns (Rivera B., Becker, P., Papa, M.F., Olsina L.). En 2do Simposio Argentino de Ontologías y sus Aplicaciones (SAOA’16), en conjunto con 45º Jornadas Argentinas de Informática (JAIIO). ISSN: 2451-7518, pp. 15-28, CABA, 2016.

– Estrategia de Medición, Evaluación y Mejora Continua de Calidad (Riv era B., Becker P., Olsina L.). Revista Tecnología y Ciencia (RTyC), Universidad Tecnológica Nacional, Edición Especial CoNaIISI, Año 13, N.27, ISSN 1666-6917, pp. 73-88, 2015.

– Strategy Patterns for Evaluating and Improving Usability (Rivera B., Becker, P., Lew P., Olsina L.). En Simposio Argentino de Ingeniería de Software (ASSE’15), en conjunto con 44º Jornadas Argentinas de Informática (JAIIO). ISSN 2451-7593, pp. 69-84, Rosario, Argentina, 2015.

– Extending the Conceptual Base for a Holistic Quality Evaluation Approach (Rivera B., Becker, P., Olsina L.). En 1er Simposio Argentino de Ontologías y sus Aplicaciones (SAOA’15), en conjunto con 44º Jornadas Argentinas de Informática (JAIIO). ISSN: 2451-7518, pp. 121-130, Rosario, Argentina. Disponible en CEUR, ISSN: 1613-0073, Vol.1449, 2015.

– Sistema Colaborativo de Revisión de Métricas (Baffini Malvina, Rivera B., Olsina L.) En Actas del XII Congreso Congreso Argentino de Ciencias de la Computación (CACIC 2006), Workshop WISBD. ISBN 950-609-050-5, Potrero de los Funes, San Luis, 2006.

1.4.4. Otras publicaciones

– Escenarios de Metas de Negocio y de Necesidad de Información de Nivel Operativo soportadas por Estrategias basadas en Medición, Evaluación y Cambio (Becker, P., Rivera B., Papa, M.F., Santos L., Olsina L.). En Actas del 4to Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNaIISI). ISSN: 2347-0372, pp. 1-14, Salta, 2016.

– Estrategia de Comprensión y Análisis aplicado a un Proyecto de Evaluación de Usabilidad de LinkedIn (Tebes, G., Peppino, D., Rivera B., Becker, P., Olsina L.). En Actas del 4to Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNaIISI). ISSN: 2347-0372, pp. 1-14, Salta, 2016.

– Evaluation and Improvement of an Organizational Resource applying Strategy Patterns (Papa, M.F., Rivera B., Becker, P., Olsina L.). En: Journal of Software Engineering and Applications (JSEA), Special issue: Software Analysis Patterns. ISSN: 1945-3116, Vol.9 N.4, pp. 1-19, Irvine, USA, 2016.

– Patrón de Estrategia de Evaluación y Mejora de una Vista de Calidad aplicado a un Recurso Organizacional (Papa, M.F., Rivera B., Becker, P., Olsina L.). En Actas del 3er Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNaIISI). ISBN: 978-987-1896-47-9, pp. 1-12, CABA, 2015.

– Updating Quality Models for Evaluating New Generation Web Applications (Olsina L., Lew P., Dieser A., Rivera B.). En: Journal of Web Engineering (JWE), Special issue: Quality in New Generation Web Applications. ISSN 1540-9589, Rinton Press, US, Vol.11, N.3, pp. 209-246, 2012.

– Using Web Quality Models and a Strategy for Purpose-Oriented Evaluations (Olsina

L., Lew P., Dieser A., Rivera B.). En: Journal of Web Engineering (JWE). ISSN: 1540-9589, Rinton Press, US, Vol.10, N.4, pp. 316-352, 2011.

1.5. Estructura

Esta tesis está estructurada en cuatro partes, tal como se ilustra en la Figura 1.1. La Parte I, además de la presente introducción (Capítulo 1), presenta los fundamentos de estrategias integradas de medición y evaluación (Capítulo 2). Este capítulo introduce el contexto teórico necesario relacionado a la utilización de estrategias integradas que ayudan a alcanzar metas de necesidades de información de medición y evaluación. El objetivo de este capítulo es proporcionar al lector el conocimiento necesario para entender las bases sobre las cuales se sostiene y construye este trabajo.

Figura 1.1 Estructura de la tesis.

La Parte II desarrolla el estado del arte, los problemas detectados y la solución propuesta. Se compone de los Capítulos 3 y 4.

– Capítulo 3: analiza el estado del arte considerando los tres temas que conducen esta tesis, a saber: vistas de calidad, enfoques y estrategias integradas con soporte a multiniveles organizacionales y, la utilización de patrones de estrategia en el área medición y evaluación del software. Asimismo, se analizan estas cuestiones para las estrategias integradas introducidas en el Capítulo 2.

– Capítulo 4: identifica los aspectos a robustecer en las estrategias integradas en función del análisis del estado del arte y propone una solución, la cual pretende dar respuesta a las preguntas de investigación formuladas en la Sección 1.2.

La Parte III presenta el desarrollo de la solución. Se compone de los capítulos 5, 6, 7, 8 y 9.

– Capítulo 5: presenta la ontología de vistas de calidad y describe la utilidad de determinar cuál/cuales son las vistas de calidad que se pueden identificar en el propósito de la meta operativa de necesidad de información de medición y evaluación, considerando las mismas dentro de un enfoque de evaluación de calidad.

– Capítulo 6: presenta la ontología de metas multinivel que enlaza conceptos de meta de negocio y necesidad de información con los conceptos de proyecto, estrategia y patrón de estrategia. Se definen todos los términos y relaciones involucrados y se destacan las relaciones surgidas con la anterior base conceptual de requisitos no funcionales, que se analiza en el Capítulo 2.

– Capítulo 7: describe la utilización de patrones de estrategia, resaltando su valor al momento de instanciar estrategias integradas de medición y evaluación. Se presenta la plantilla de especificación de tres patrones de estrategia y se describen otros posibles patrones de estrategia.

– Capítulo 8: describe los pasos para aplicar el enfoque de evaluación de calidad a través de un caso aplicado. En dicha prueba de concepto, se especifica la definición de metas de negocio y de necesidad de información a distintos niveles organizacionales; la identificación de una meta de necesidad de información de medición y evaluación y la selección del patrón de estrategia adecuado. Además, se describe la instanciación de la estrategia adecuada al caso y la aplicación de la misma, considerando su proceso y métodos para alcanzar la meta de necesidad de información de medición y evaluación.

– Capítulo 9: describe la implementación con un lenguaje ontológico, de la ontología de vistas de calidad y metas de negocio. Debido que a futuro se prevé la construcción de un servicio web que recomiende patrones de estrategia, en esta tesis se propone la especificación conceptual y formal de la ontología que dará soporte a dicho servicio con conocimiento sobre vistas de calidad y metas y estrategias, para que pueda ser compartido y reusado por otros agentes y/o herramientas.

La Parte IV se compone del Capítulo 10, el cual presenta las conclusiones de este trabajo y las líneas futuras de investigación.

La tesis incluye además el Apéndice A que detalla el código de la ontología implementada en OWL (Web Ontology Language) a través de la herramienta Protegé, descripta en el Capítulo 9.

Capítulo 2 - Estrategias Integradas de Medición y Evaluación

El presente capítulo realiza un repaso sobre el concepto de estrategia, resaltando la importancia de su utilización en el área de medición y evaluación de la calidad del software. El capítulo se estructura de la siguiente manera:

– Sección 2.1: Introduce el origen del término estrategia y distintos significados de acuerdo al dominio de aplicación.

– Sección 2.2: Describe los principios de estrategias integradas de medición y evaluación. Se presentan tres estrategias integradas que satisfacen dichos principios.

– Sección 2.3: Describe el marco conceptual para estrategias integradas de medición y evaluación.

– Sección 2.4: Describe el proceso de las estrategias integradas de medición y evaluación.

– Sección 2.5: Describe los métodos utilizados por las estrategias integradas de medición y evaluación.

– Sección 2.6: Expone las conclusiones.

2.1. ¿Qué es una Estrategia?

El término estrategia proviene de la fusión de dos palabras griegas: stratos, que significa ejército y agein, que significa guiar, conducir. Atenas fue una de las ciudades más importantes de la Antigua Grecia y su ejército (denominado también estrategia) constituía el cargo oficial de mayor relevancia [Curtius, 1962]. Los estrategas o strategos eran quienes tenían el puesto de jefe de las tropas de mar y tierra, además de la inspección de todo lo referente a la seguridad del Estado. Cuando los estrategas dirigían sus ejércitos lo hacían con claros objetivos de defensa o conquista. Para alcanzar cada tipo de objetivo era necesario establecer un curso de acción específico y disponer de los recursos o medios apropiados para tal fin. Por lo tanto, cuando el ejército avanzaba, contaban con una planificación previa de recursos y acciones que, además, servía para tomar decisiones de acuerdo al ataque del oponente. Desde entonces el término estrategia adquiere el significado referido a los medios y la disposición adecuada de los mismos para llegar al objetivo perseguido.

Con el correr del tiempo, el significado de estrategia fue discutido por diversos autores, quienes le otorgaron distintos matices de acuerdo al dominio de empleo. Un modo de comprender qué es una estrategia es pensar en ella como un proceso que integra el “qué”, el “por qué”, y el “cómo” de cualquier intención decisiva [Lusk y Birks, 2014]. El “qué” es el resultado esperado y las opciones que deben ser escogidas para alcanzarlo. El “por qué” considera dicho resultado esperado como una hipótesis y comprueba por qué debería ser esa la opción correcta (o la equivocada) a llevar a cabo explorando el contexto y también exponiendo los principios, ideales, creencias (y prejuicios) que han conducido a desarrollar la hipótesis. El “cómo” es el medio a partir del cual una opción que conduce al resultado esperado se lleva a cabo, incluyendo las decisiones sobre la asignación de recursos y aquello que se planea realizar, o dejar de realizar, o más bien, realizar de un modo diferente. Los autores en [Lusk y Birks, 2014] enfatizan que, estrategia, se refiere a cambiar cosas, de otro modo, sería una “lista de deseos” que no hace ninguna diferencia tangible a nada.

Por su parte, Mintzberg et al. establecen que una estrategia es “un plan, o algo equivalente, una dirección, una guía o curso de acción en el futuro, un camino para ir desde aquí hasta al lá.[...]. Es también un patrón, es decir, consistencia en el comportamiento a lo largo del tiempo” [Mintzberg et al., 2005, p.9]. Esta definición caracteriza a una estrategia como un plan, mirando el futuro y como un patrón, mirando el comportamiento pasado. La Figura 2.1 contrasta estas dos características.

Figura 2.1 Estrategia como intención en el futuro (plan) y como algo ya realizado (patrón). Extraída de: [Mintzberg et al., 2005].

En [Hax et al., 1986] los autores combinaron distintas definiciones del término estrategia para concluir con una interpretación más comprehensiva, aunando varios aspectos mencionados como importantes para la misma. La definición establece que una estrategia es un patrón de decisión coherente, unificador e integrador, que determina y revela el propósito de una organización en términos de objetivos de largo plazo, las acciones para concretarlos y la asignación de recursos considerando prioridades. Determina además el negocio donde la organización está inmersa, definiendo el tipo de organización que es, intentando lograr una ventaja sostenible de largo plazo a nivel de negocio, respondiendo adecuadamente a las oportunidades o amenazas suscitadas en el entorno, así como también a las fortalezas y debilidades de la organización; comprometiendo para esto todos los niveles organizacionales y definiendo la naturaleza de las contribuciones económicas y no económicas que pretende hacer a sus partes interesadas. Considerando esta definición, una estrategia se convierte en un marco de trabajo fundamental en una organización que garantiza su normal desarrollo, al mismo tiempo que facilita su adaptación a entornos cambiantes.

Las definiciones abordadas coinciden en sugerir que una estrategia tiene que ver con metas y con decisiones de negocio que la organización enfrenta, las cuales determinan su éxito o fracaso. El énfasis en considerarla como un patrón y un marco de la organización implica que la estrategia se consolida en términos de un comportamiento consistente, significando que, una vez establecido, no es fácilmente retrotraible. Finalmente, la idea de que una estrategia define el tipo de organización que es o debiera ser, sugiere que las decisiones que la estrategia establece forman a las organizaciones en relación a su entendimiento de cómo suceden los hechos dentro de su ambiente competitivo [Besanko et al., 2009].

En efecto, la utilización de estrategias constituye la manera junto a los medios, de alcanzar una meta, aunque a menudo la distinción entre el qué (la meta a conseguir) y el cómo (la manera de alcanzarla) no esté claramente identificada [Bider et al., 2005]. Cualquiera sea el tipo de organización que se trate, las estrategias son el recurso adecuado que ayudan a alcanzar el propósito de la meta que se persigue, indicando los medios y acciones a realizar. Las organizaciones de software no son la excepción, especialmente interesan en este trabajo, aquellas que formulan proyectos de medición y evaluación y operacionalizan metas de necesidad de información de medición y evaluación, como parte de las tareas de aseguramiento de la calidad. En este sentido, Basili et al. definen estrategias [Basili et al., 2010] como un conjunto posible de enfoques para alcanzar una meta que puede ser refinada a través de un conjunto de actividades concretas. Ejemplos de estrategias que ayudan a alcanzar metas de medición y evaluación son Goal Question Metric (GQM) [Caldiera et al., 1994], GQM+ Strategies ([Basili et al., 2007a], [Basili et al., 2007b], [Basili et al., 2010], [Trendowicz et al., 2014]), Balanced Scorecard (BSC) ([Kaplan y Norton, 1996], [Kaplan y Norton, 2005]), Practical Software and System Measurement (PSM) [PSM, 2000], por citar aquellas que más se destacan en la literatura ¹.

Teniendo en cuenta estas definiciones, en particular la dada en [Basili et al., 2010], en este trabajo se define el término estrategia como “principios, patrones, conceptos de un dominio en particular y marcos conceptuales que pueden ser especificados mediante un conjunto de procesos concretos, además de un conjunto apropiado de métodos y herramientas, como recursos principales que ayudan a alcanzar el propósito de una meta de proyecto” [Rivera et al., 2016b, p.7]. Además, en [Papa, 2012] se establece que una estrategia tendiente a satisfacer algún tipo de meta, debiera tener tres principios o capacidades integradas, a saber: un marco conceptual de dominio, una especificación de las perspectivas del proceso y una especificación de métodos. Contar con estrategias que integren estas tres capacidades permite comprender claramente qué hacer (proceso), cómo hacerlo (métodos y herramientas) y que exista un entendimiento común de los conceptos claves del dominio particular (marco conceptual). En especial, en el contexto de la investigación que enmarca a esta tesis, interesan las estrategias integradas que ayudan a alcanzar propósitos de metas de necesidades de información de medición y evaluación, por lo que el dominio del marco conceptual, así como el proceso y los métodos se corresponden al dominio de medición y evaluación.

Una estrategia integrada de medición y evaluación puede ser considerada como un recurso empleado en actividades de aseguramiento de calidad en cualquier línea de producción de software. Ejemplos de estrategias integradas desarrolladas en nuestro grupo de investigación son: Goal-Oriented Context-Aware Measurement and Evaluation (GOCAME)[Olsina et al., 2008b], Strategy for Improving Quality in Use (SIQinU) [Lew et al., 2012] y Goal-Oriented Context-Aware Measurement, Evaluation and Change (GOCAMEC)[Rivera et al., 2014]. GQM+ Strategies y PSM pueden ser consideradas también estrategias integradas.

A continuación, se introducen los principios deseables de una estrategia integrada y se describen las estrategias GOCAME, SIQinU y GOCAMEC.

2.2. Estrategias Integradas

Una organización de software comprometida con el aseguramiento de la calidad de sus procesos y productos, debe encarar proyectos de medición y evaluación con claros objetivos a satisfacer. Si no es así, probablemente los esfuerzos llevados a cabo para medir y evaluar la calidad se verían reducidos, conduciendo a la frustración, pérdida de tiempo y confusión al implementar el proyecto. La medición del software es el medio para cumplir un fin, no el fin en sí mismo [Bassman et al., 1995]. El fin es la necesidad de información, la meta de medición y evaluación a cumplir para ayudar a la toma de decisiones. Toda meta tiene un propósito, en particular, las metas de necesidades de información de medición y evaluación pueden tener como propósitos, entre otros, “comprender”, “mejorar”, un foco de calidad para distintas categorías de entidades tales como producto, sistema, recurso. Para llevar a cabo metas con estos propósitos, este trabajo se centra en la utilización de estrategias integradas de medición y evaluación. Una estrategia integrada posee los tres principios o capacidades introducidos en la Sección 2.1: i) un marco conceptual robusto que permita disponer de un vocabulario común para un dominio dado, ii) una especificación de las perspectivas del proceso en la cual se documenten, entre otros aspectos, las principales actividades que deben ser planificadas y ejecutadas, y iii) especificaciones de métodos para llevar a cabo las actividades.

El principio del marco conceptual robusto (como por ejemplo una ontología) promueve la uniformidad y consistencia en el empleo de los términos (y sus relaciones) involucrados en un dominio en particular. Para una estrategia integrada de medición y evaluación, este principio es fundamental. Frecuentemente cuando se llevan a cabo las actividades de medición y evaluación, se utilizan términos técnicos sin un claro consenso en la definición de los mismos [McGarry et al., 2001][García et al., 2006]. Esto es, un mismo término -como por ejemplo medida- podría llegar a tener distintas interpretaciones de acuerdo al contexto y distintas fuentes en el que se lo use. Esto conduce a ambigüedades e imprecisiones al momento de comunicar los resultados de distintos proyectos entre los analistas de la medición. Por lo tanto, disponer de una terminología de medición explícita, consistente y consensuada es de especial importancia.

El principio de la especificación de las perspectivas de proceso permite identificar qué se debe hacer, la secuencialidad de las tareas, quiénes son los responsables y consumidores, cuáles son los productos de trabajo necesarios y cuáles son los producidos [Becker et al., 1997] considerando un dominio en particular. Para una estrategia integrada de medición y evaluación, este principio también es relevante. Así como es posible encontrar imprecisiones en la terminología empleada al llevar a cabo actividades de medición y evaluación, es frecuente también que no esté claro qué actividades deben llevarse a cabo y en qué orden. Lo mismo sucede con la identificación de los insumos y agentes involucrados. Es decir, a menudo, se carece de una guía clara y repetible de las actividades que deben llevarse a cabo, como así también de la identificación de los productos de trabajo insumidos y producidos. Y además, entre otros aspectos, se podría escoger inadecuadamente los agentes que ocuparán los roles involucrados en la realización de las actividades.

Finalmente, el principio de métodos y herramientas específicos bien definidos permite tener una guía clara respecto de cómo se deben realizar las actividades involucradas en el proceso. Una medición efectiva y eficiente requiere soporte metodológico y tecnológico [Lavazza, 2000]. Por lo tanto, al igual que los dos principios anteriores, para una estrategia integrada de medición y evaluación, disponer de métodos y herramientas automáticas o semiautomáticas contribuye a una efectiva realización de las tareas de medición y evaluación.

Los tres principios enunciados permiten que una estrategia integrada de medición y evaluación asegure un cumplimiento de las metas de necesidades de información con resultados repetibles y comparables entre proyectos de la organización, a partir del establecimiento de un conjunto de actividades y métodos que permitan especificar, recolectar, almacenar y utilizar de manera coherente, los valores de las medidas e indicadores obtenidos.

Este trabajo se sustenta en la teoría de estrategias integradas de medición y evaluación como recurso valioso a considerar al momento de desarrollar proyectos de aseguramiento de calidad en organizaciones de software. El análisis de otras propuestas similares así como las debilidades y oportunidades de mejora detectadas para las estrategias que se proponen, serán analizadas en el Capítulo 3. A continuación, se describen tres estrategias integradas de medición y evaluación: GOCAME, SIQinU y GOCAMEC.

2.2.1. Estrategia Integrada GOCAME

GOCAME [Olsina et al., 2008b] es una estrategia que lleva a cabo metas de necesidad de información de medición y evaluación de un modo top-down, es decir, derivando medidas como resultado del proceso de medición a partir de la cuantificación de atributos de la entidad bajo evaluación.

GOCAME ayuda a alcanzar metas de necesidad de información con el propósito de “comprender” la situación actual de una entidad respecto a alguna característica de calidad. Un ejemplo de una meta de este tipo es “comprender la usabilidad de LinkedIn para dispositivos móviles”. Según establecen [Fenton y Pfleeger, 1998], [Morasca, 2001] o [INCOSE, 2010], comprender la situación actual de una entidad es un objetivo de medición primario puesto que permite tener una instantánea de la realidad o situación de la entidad evaluada respecto a alguna característica de calidad. De acuerdo a la evaluación efectuada, se realizan recomendaciones que servirán para tomar alguna decisión o, simplemente, conocer la situación actual en la que se encuentra la entidad evaluada.

El curso de acción que establece GOCAME es el siguiente. Como parte de la definición de los requisitos no funcionales se instancia un modelo de calidad, como por ejemplo, aquellos definidos en la ISO 9126 [ISO/IEC, 2001], ISO 25010 [ISO/IEC, 2011] o bien, establecer un modelo propio o adaptado de un estándar como 2Q2U (Internal/External Quality, Quality in Use, Actual Usability, and User experience) [Lew et al., 2010]. El modelo de calidad se conforma de características y sub-características, estructuradas en forma de árbol, cuyas hojas son los atributos de la entidad bajo análisis. Para cada atributo del modelo de calidad instanciado se especifican las métricas que los cuantificarán y los indicadores más apropiados que servirán para interpretar los valores obtenidos de las métricas, esto es, las medidas de los atributos. Luego se analiza la información obtenida y se brindan recomendaciones en base a las debilidades detectadas. De esta manera, la estrategia permite llevar a cabo la meta con el propósito de comprender puesto que, como resultado, otorga recomendaciones que servirán para tomar decisiones y, justamente, comprender la situación actual de la entidad evaluada.

GOCAME es considerada una estrategia integrada ya que simultáneamente satisface los tres principios descriptos en la Sección 2.1. En la Sección 2.3 se describe su marco conceptual, en la Sección 2.4, la especificación de una de las perspectivas para el proceso que define y, en la Sección 2.5, los métodos y herramientas necesarios para llevar a cabo el proceso.

Esta estrategia fue utilizada para evaluar aspectos de la calidad externa, específicamente la calidad funcional de una aplicación de mashup relacionada a datos meteorológicos [Olsina et al., 2012]. También se utilizó, entre otros casos, para evaluar la calidad externa del componente carrito de compras del sitio Amazon ² [Olsina et al., 2008b].

2.2.2. Estrategia Integrada SIQinU

Una de las principales cuestiones a abordar cuando se trata de asegurar la calidad de productos y sistemas software es que los desarrolladores no son usuarios y los usuarios no son desarrolladores [Nielsen, 1994]. Los desarrolladores no pueden predecir completamente el comportamiento de los usuarios y éstos perciben el sistema a partir de las tareas que realizan y el contexto de uso. Un mismo sistema puede ser fácil de usar para usuarios entrenados, mientras que puede resultar poco usable para usuarios novatos. Por lo tanto, no solo es preciso considerar como requisitos no funcionales a evaluar, las característica dinámicas de un sistema ejecutándose o aquellas estáticas, a partir de modelos de calidad externa o interna respectivamente; sino que también debe prestarse atención a aquellas características que podrían ser evaluadas cuando el sistema es usado, en un contexto real por usuarios reales. La calidad en uso es por lo tanto, otra característica que merece ser evaluada, instanciando apropiadamente un modelo con atributos relacionados a la entidad a evaluar.

SIQinU [Lew et al., 2012] es una estrategia de medición y evaluación que permite llevar a cabo necesidades de información con propósitos que involucren tanto características de calidad en uso como de calidad externa. Al igual que GOCAME, sigue un enfoque top-down orientado a metas. La principal diferencia con esta estrategia es que SIQinU utiliza la premisa que establece el estándar ISO/IEC 25010 que, si la calidad puede ser mejorada desde el punto de vista de calidad externa, esto influencia y mejora la calidad desde el punto de vista de la calidad en uso. Por lo tanto, SIQinU provee solución a las metas de necesidad de información con el propósito de mejorar, de manera incremental y continua, la calidad en uso de un sistema a partir de la mejora de la calidad externa del mismo. Y considerando además, que la calidad externa “influencia” a la calidad en uso y, a su vez, la calidad en uso “depende de” o “está determinada por” la calidad externa ³. Con este fin, en [Lew et al., 2010] se extiende a los modelos de calidad de ISO/IEC 25010 en el marco de modelado denominado 2Q2U.

SIQinU se deriva de GOCAME, por lo tanto, comparten la misma base conceptual, reutiliza muchos de los elementos del proceso para definir uno nuevo que contempla ciclos de mejora y re-evaluación, además de algunos métodos y herramientas. Es una estrategia integrada que permite evaluar y mejorar la calidad en uso pero en consideración de la mejora de la calidad externa de los atributos relacionados. Para esto, recolecta datos (a través de funcionalidades agregadas al sistema) de las actividades del usuario cuando ejecuta las tareas específicas de la aplicación en uso diseñadas para la evaluación. De esta manera se recolectan las medidas que permitirán calcular los indicadores para calidad en uso. Fue utilizada a mediados del año 2010 para examinar JIRA ⁴, una aplicación web comercial para el seguimiento de defectos. Se evaluó la calidad en uso de la aplicación a través de la tarea más común de la aplicación que consiste en “ingresar un nuevo defecto” [Lew et al., 2012].

SIQinU es también considerada una estrategia integrada dado que simultáneamente cuenta con los tres principios. El marco conceptual es el mismo que utilizan GOCAME y GOCAMEC, el cual será descripto en la Sección 2.3. La especificación de una de las perspectivas del proceso definido para esta estrategia se realiza en la Sección 2.4. Finalmente, la Sección 2.5 especifica los métodos y herramientas necesarios para llevar a cabo las especificaciones de dicho proceso.

2.2.3. Estrategia Integrada GOCAMEC

GOCAMEC ⁵ [Rivera et al., 2014] es una estrategia que sigue el mismo enfoque de medición top-down que GOCAME. De hecho, GOCAMEC se deriva de GOCAME pero contempla de manera integral, actividades de mejora y cambio, posteriores a la medición y evaluación, que permiten, tanto analizar como detectar debilidades y vulnerabilidades. Su surgimiento radica en que, frecuentemente, las actividades involucradas en procesos de cambio y mejora no están contempladas en estrategias de medición y evaluación. Considerando que toda organización que desee ser exitosa debe apuntar a la mejora continua de la calidad de sus productos, servicios, procesos y recursos, es menester desde luego, contar con actividades de medición y evaluación que permitan introducir cambios orientados a la mejora.

GOCAMEC ayuda a alcanzar metas de necesidades de información de medición y evaluación con el propósito de mejorar la situación actual de una entidad. Un ejemplo de una meta de este tipo es “mejorar la usabilidad de LinkedIn para dispositivos móviles”. El propósito de mejorar tiene embebido el de comprender la situación actual pero, a partir de las debilidades detectadas, se diseñan e implementan acciones de cambio para revertirlas. Por esta razón, es una estrategia de cambio guiada por medición y evaluación.

GOCAMEC es también una estrategia integrada de medición y evaluación dado que cuenta de manera integrada con un marco conceptual, procesos y métodos. La Sección 2.3 describe su marco conceptual, la Sección 2.4 describe la perspectiva funcional y de comportamiento para el proceso que establece y la Sección 2.5, los métodos que utiliza.

Esta estrategia fue utilizada para evaluar la usabilidad y la calidad de la información de un carrito de compras, utilizando refactoring como método de cambio [Olsina et al., 2008a]. Además, se utilizó en un estudio de comparación y mejora de estrategias integradas [Papa, 2012].

2.3. Marco Conceptual para Estrategias Integradas de Medición y Evaluación

Una de las tres capacidades deseables en una estrategia integrada es el marco conceptual de dominio. Un marco conceptual robusto debe estar construido sobre una base conceptual terminológicamente consistente (como por ejemplo, una taxonomía o una ontología) que especifique, de manera formal y explícita los conceptos, relaciones y restricciones del dominio en cuestión.

Para las estrategias integradas GOCAME, SIQinU y GOCAMEC el marco conceptual se denomina C-INCAMI (Contextual-Information Need, Concept Model, Attribute, Metric and Indicator ) [Molina y Olsina, 2008][Olsina et al., 2008b]. Este marco provee un vocabulario explícito y común para el dominio de medición y evaluación. C-INCAMI permite la especificación de los datos y metadatos necesarios en las actividades y artefactos del proceso de medición y evaluación, como así también de aquellos relacionados a métodos y herramientas que son asignados en las actividades del proceso.

El marco conceptual C-INCAMI está definido formalmente a través de una ontología de medición y evaluación [Martin y Olsina, 2003][Olsina y Martin, 2004]. Definir la base terminológica del marco conceptual como una ontología permitió especificar un vocabulario común, con una semántica bien definida posibilitando, de esta manera, que la información de métricas e indicadores pueda ser procesada por alguna aplicación o servicio que así lo requiera. Bajo estas consideraciones, la ontología fue implementada en RDF (Resource Description Framework ) ⁶, un lenguaje para procesar datos semánticamente. Esto permitió la realización de un sistema de catalogación de métricas e indicadores con potencia de web semántica [Martin y Olsina, 2003]. El objetivo del sistema fue facilitar la explotación e intercambio consistente de información de métricas e indicadores tanto por parte de usuarios como por parte de aplicaciones, agentes y herramientas automáticas de la web.

La formalización de la base conceptual de C-INCAMI en un ontología de medición y evaluación permitió además resolver problemas de terminología entre diferentes fuentes de información al momento de instanciar proyectos de medición y evaluación. En este sentido, la disciplina de medición de software es relativamente nueva y aún no existe consenso total en los términos y sus relaciones [McGarry et al., 2001] [García et al., 2006]. Dentro de otras iniciativas relacionadas al desarrollo de ontologías para dicho dominio pueden citarse las propuestas de Bertoa, Vallecillos y García [Bertoa et al., 2006] y la de Barcellos, Falbo y Dal Moro [Barcellos et al., 2010], con las cuales se observan algunas diferencias. Entre las más notables a resaltar puede mencionarse la utilización del término “medida” en lugar del término “métrica”, la cual es una diferencia compartida con muchos trabajos relacionados a medición. Frecuentemente, en la literatura sobre teoría de medición del software (como por ejemplo, [Fenton y Pfleeger, 1998], [Zuse, 1998] o [Morasca, 2001]) se considera que tanto el término “métrica” como “medida” son sinónimos, proponiendo la utilización de “medida” al referenciar una “métrica”. Sin embargo, la base conceptual de C-INCAMI considera que una medida es el valor resultante de una actividad de medición, mientras que una métrica representa el método, es decir, la manera específica y explícita de llevar a cabo dicha actividad de medición. Así queda establecido en el estándar ISO 14598-1 [ISO/IEC, 1999], significados adoptados en la ontología de [Olsina y Martin, 2004]. Otra diferencia es la consideración de que las medidas se expresan en unidades de medidas [Bertoa et al., 2006][Barcellos et al., 2010] en contraposición con lo que se modeliza en la ontología de [Olsina y Martin, 2004] la cual indica que sólo las escalas numéricas se expresan en unidades. Finalmente, otro problema que se destaca en la terminología, es el concepto de indicador. En [Barcellos et al., 2010], un indicador es un rol que desempeña una medida cuando se utiliza para indicar el logro de una meta. Bajo esta consideración, un indicador está siempre asociado a un objetivo, el cual está relacionado con una necesidad de información. En [García et al., 2006] un indicador es considerado como un sub-tipo de medida, pero no especifican que es un rol, como se distingue en [Barcellos et al., 2010]. Aunque también establecen que un indicador puede estar (o no) asociado a una necesidad de información. Estas definiciones difieren del significado de indicador de [Olsina y Martin, 2004] en donde se establece que un indicador (elemental) interpreta la medida obtenida de la evaluación de los atributos y calcula los valores (indicador derivado) para las sub-características y características evaluadas, obteniendo valores que indicarán el nivel de satisfacción o aceptabilidad alcanzado para la característica de calidad evaluada. En este sentido, un indicador no está directamente relacionado con el logro de una necesidad de información, sino que constituye el método de evaluación que permite mapear los valores medidos y calculados en valores que indican un nivel de aceptabilidad, que luego mediante un análisis adicional permite juzgar el logro (o no) de una meta.

La ontología de métricas e indicadores ha tomado además como fuente de conocimiento, las definiciones dadas por los estándares ISO 14598-1 [ISO/IEC, 1999], ISO 15939 [ISO/IEC, 2007], ISO 9126-1 [ISO/IEC, 2001] y reconocidos trabajos en el área tales como [Zuse, 1998], [Kitchenham et al., 2001], [Briand et al., 2002] por lo que varias de las definiciones de los conceptos coinciden y otras fueron adaptadas. Una discusión pormenorizada sobre los distintos términos que la componen puede consultarse en [Olsina y Martin, 2004], [Olsina et al., 2008b] y [Becker et al., 2015]. La Figura 2.2 ilustra algunos de los componentes del marco conceptual C-INCAMI, basado en la ontología de métricas e indicadores y estructurado de la siguiente manera: (I) Proyecto, (II) Requisitos No Funcionales, (III) Contexto, (IV) Medición y (V) Evaluación

Figura 2.2 Principales términos y relaciones del marco conceptual C-INCAMI.

A continuación se describen dichos componentes, resaltando en itálica, los términos tal como se presentan en el marco conceptual.

2.3.1. Componente de Proyecto

Este componente agrupa los conceptos mínimos necesarios involucrados en la especificación de proyectos de medición y evaluación. En la Figura 2.3 se observa el concepto proyecto (Project ), y como tipos de proyectos concretos se modelan el de medición y evaluación (MEProject ), el de requisitos (RequirementsProject ), el de medición (MeasurementProject ) y el de evaluación (EvaluationProject ). Un proyecto de medición y evaluación define los requisitos no funcionales de la evaluación por medio de un proyecto de requisitos. A su vez, puede contener muchos proyectos de medición y, por cada uno de éstos, pueden llevarse a cabo varios proyectos de evaluación. Cada uno de estos proyectos se gestionan de manera separada, permitiendo así la planificación coordinada de los mismos y la eficiente asignación de recursos a cada uno.

Figura 2.3 Componente de Proyecto de C-INCAMI.

2.3.2. Componente de Requisitos No Funcionales

Este componente, ilustrado en la Figura 2.4, modela los conceptos necesarios para la especificación de requisitos no funcionales. La conceptualización de dicho dominio establece a la necesidad de información (Information Need ) como uno de los conceptos principales a considerar. En la ontología citada se define la necesidad de información como la información necesaria para gestionar objetivos, metas, riesgos y problemas. Indica además, que la necesidad de información especifica una entidad (Entity) concreta a evaluar, es decir, un objeto que va a ser caracterizado mediante la medición de sus atributos (Attribute). Una entidad pertenece a una categoría de entidad (Entity Category), la que a su vez pertenece a una súper-categoría de entidad (Super Entity Category) correspondiente.

La necesidad de información tiene como atributos un propósito (purpose) y un punto de vista de usuario (user viewpoint ). Se describe por medio de uno o más conceptos calculables (Calculable Concept ) de evaluación. Un concepto calculable representa una característica abstracta de calidad (pero podría ser también de costo) deseable para la evaluación de una entidad. Un concepto calculable con el rol de foco (focus) es la característica de más alto nivel (por ejemplo, calidad externa). Puede estar formado a su vez por sub-conceptos calculables (sub-características), que se relacionan entre sí en múltiples niveles jerárquicos formando un árbol de requisitos. En el último nivel del árbol se combinan, para determinados conceptos calculables, los atributos, esto es, las propiedades de una entidad [Morasca, 2001]. Esta estructuración en un árbol de conceptos calculables y atributos conforman un modelo de concepto (Concept Model ). Los estándares ISO 9126 e ISO 25010 definen modelos de conceptos para calidad interna, calidad externa, y calidad en uso los cuales pueden utilizarse por completo, considerar adaptaciones de ellos o bien, diseñar un modelo propio.

Figura 2.4 Componente de Requisitos No Funcionales de C-INCAMI.

2.3.3. Componente de Contexto

Este componente, ilustrado parcialmente en la Figura 2.5, modela los conceptos y relaciones para describir el contexto en el que se desarrolla un proyecto de medición y evaluación. El concepto principal es el término contexto (Context ) que representa el estado relevante de la situación de una entidad. Contexto es considerado como un tipo de entidad y se describe por un conjunto de propiedades (Context Properties), que son un tipo especial de atributo y caracterizan a las entidades relevantes involucradas en el contexto de la entidad de interés. Por lo tanto, las propiedades de contexto pueden ser cuantificadas y evaluadas de la misma manera que los atributos.

La necesidad de información se caracteriza por un contexto y esto resulta valioso de considerar a los efectos de realizar comparaciones con resultados de otros proyectos [Molina y Olsina, 2008].

Figura 2.5 Fragmento del componente de Contexto de C-INCAMI.

2.3.4. Componente de Medición

Este componte, ilustrado en la Figura 2.6, modeliza los conceptos y relaciones que intervienen en la especificación de las métricas que cuantifican cada atributo del árbol de requisitos. Un atributo puede ser cuantificado por más de una métrica pero para un proyecto de medición en particular, sólo una métrica es seleccionada para cada atributo.

Una métrica (Metric) provee una especificación de la medición (Measurement ) indicando cómo cuantificar un atributo de una entidad y cómo representar sus valores, a partir de una escala (Scale) determinada que expresará los valores medidos (Measure). Las escalas pueden ser numéricas o categóricas. Las escalas numéricas poseen una unidad (Unit ) y su representación puede ser continua o discreta. Una escala además se caracteriza por ser de un tipo (Scale Type), distinguiéndose entre tipos de escalas nominales, ordinales, intervalo, proporción o absoluta, de acuerdo a tres propiedades de las categorías, a saber: 1) existencia de orden entre las categorías, 2) preservación de la distancia entre las mismas y, 3) existencia de la categoría cero, con semántica de ausencia.

Figura 2.6 Componente de Medición de C-INCAMI.

Las métricas se clasifican en dos tipos: directas (Direct Metric) e indirectas (Indirect Metric). Las métricas directas especifican un procedimiento de medición (Measurement Procedure) que indica los pasos a seguir para obtener el valor del atributo medido. Las métricas directas se utilizan en una medición directa (Direct Measure), aquella que no depende de la medición previa de otros atributos y el valor que se obtiene se denomina medida base (Base Measure). Por otra parte, las métricas indirectas especifican un procedimiento de cálculo (Calculation Procedure) y se utilizan en una medición indirecta (Indirect Measure) y el valor que se obtiene se denomina medida derivada (Derived Measure) por ser un valor que se deriva o proviene de valores de otras métricas. La métrica indirecta especifica una fórmula o función que permite efectuar el cálculo.

2.3.5. Componente de Evaluación

Este componente, ilustrado en la Figura 2.7, incluye los conceptos y relaciones necesarios para especificar el diseño e implementación de la evaluación. El término principal es el de indicador (Indicator ) que permite especificar cómo interpretar los valores medidos de los atributos y cómo calcular los valores de los conceptos calculables (características) del árbol de requisitos de manera tal de obtener un valor (Indicator Value). Este valor indica el nivel de aceptabilidad alcanzado por cada atributo y concepto calculable evaluado y se obtiene a través de un procedimiento de cálculo, utilizando una escala para representar el valor. Los indicadores se clasifican en dos tipos: elementales (Elementary Indicator ) y derivados (Derived Indicator ). Un indicador elemental evalúa a través de una evaluación elemental (Elementary Evaluation) un atributo y tiene asociado un modelo elemental (Elementary Model ). Dicho modelo provee la función de mapeo para transformar el valor medido del atributo en un valor (Indicator Value) de acuerdo a los umbrales objetivos de satisfacción establecidos en los criterios de decisión (Decision Criteria), o niveles de aceptabilidad.

Figura 2.7 Componente de Evaluación de C-INCAMI.

Por otra parte, un indicador derivado evalúa, mediante una evaluación derivada (Derived Evaluation), los conceptos calculables intermedios (sub-características) y los de más alto nivel (características) del modelo de concepto representados en el árbol de requisitos. Utiliza un modelo global (Global Model ) o de agregación que define cómo se interpretarán los valores (Indicator Value) correspondientes a los conceptos y/o atributos de menor nivel en el árbol de requisitos. Al igual que una métrica derivada, un indicador derivado depende del valor de otros indicadores para evaluar o estimar un concepto calculable. El valor final calculado para la característica de más alto nivel -el foco de calidad- del árbol de requisitos representa, en principio, el grado de satisfacción alcanzado para la necesidad de información establecida. Un análisis adicional podría ser necesario para determinar el logro de la meta establecida, tal como se verá en la Parte III de esta tesis.

2.4. Procesos de Estrategias Integradas de Medición y Evaluación

Una estrategia integrada destinada a llevar a cabo metas de necesidad de información de medición y evaluación, tiene que considerar un proceso bien definido y modelado para cumplir dichos objetivos. La definición de un proceso de medición y evaluación permite tener una guía que indique las actividades de especificación de requisitos no funcionales, diseño e implementación de la medición, diseño e implementación de la evaluación, y aquellas relacionadas a los análisis, recomendaciones y acciones de cambio. Desde luego, contar con el principio de una especificación del proceso en una estrategia integrada asegura repetibilidad y reproducibilidad en la ejecución de las tareas del proceso, determinando para eso, un conjunto de actividades, entradas y salidas, interdependencias, entre otros aspectos.

Para manejar la complejidad inherente de los procesos es conveniente modelarlos. La extensión que caracteriza a muchos de ellos los hace difíciles de comunicar, generando cierta ambigüedad en las descripciones de las actividades. Dado esto, se han definido perspectivas de proceso como un modelo particular para representar, especificar y comunicar los aspectos involucrados en un proceso. Curtis [Curtis et al., 1992] establece que un proceso puede ser modelado considerando cuatro perspectivas, a saber: funcional, de comportamiento, informacional y organizacional. La perspectiva funcional permite modelar el proceso a partir de las actividades y tareas que el mismo comprende. Identifica además, la jerarquía estructural de las actividades y las entradas requeridas y salidas producidas. La perspectiva de comportamiento representa la dinámica del proceso, esto es, la secuencia y sincronización de las actividades, paralelismos, iteraciones, ciclos, condiciones, entre otros aspectos. La perspectiva informacional permite modelar la estructura de los artefactos producidos o consumidos por las actividades. Finalmente, la vista organizacional trata con los agentes y sus recursos asociados involucrados en la ejecución de las actividades, los roles que tienen, las estrategias de comunicación usadas, entre otros aspectos. Además de esta distinción de perspectivas de proceso, en [Olsina, 1997] se presenta una perspectiva metodológica que muestra los constructores (los métodos específicos) centrados en modelos que realizan las descripciones de las actividades.

Por otra parte, una estrategia integrada debe contar con una metodología bien definida, que especifique los métodos, es decir, la manera específica de realizar cada tarea del proceso. La especificación del proceso define el “qué”, esto es, las actividades con sus respectivas tareas. En tanto que la especificación de métodos define el “cómo” de dichas tareas, indicando también si corresponde, herramientas que lo automaticen.

En esta sección se analizan las perspectivas funcional y de comportamiento del proceso para las estrategias integradas GOCAME, SIQinU y GOCAMEC utilizando la notación del lenguaje de modelado de procesos SPEM (Software Process Engineering Metamodel ) ⁷ . Para esto, se indican cada una de las actividades que se llevan a cabo en el proceso de cada estrategia, como así también el orden o secuencia en que se realizan junto a las entradas y salidas.

2.4.1. Proceso de GOCAME

El proceso de medición y evaluación que define la estrategia GOCAME consta de seis actividades principales [Olsina et al., 2008b], a saber:

- A1 Definir los Requisitos No Funcionales.

- A2 Diseñar la Medición.

- A3 Implementar la Medición.

- A4 Diseñar la Evaluación.

- A5 Implementar la Evaluación.

- A6 Analizar y Recomendar.

La Figura 2.8 muestra el proceso de medición y evaluación especificando las vistas funcional y de comportamiento.

Se puede observar que los conceptos definidos en el marco conceptual C-INCAMI (recordar Figura 2.2) tales como métrica, medida, indicador, entre otros, son también usados en la especificación del proceso. La Figura 2.8 solo corresponde al modelo con las actividades de alto nivel, por lo que no detalla las sub-actividades que componen cada actividad principal del proceso de medición y evaluación. Dichas especificaciones el lector puede encontrarlas en [Becker, 2014].

La primera actividad de GOCAME a desarrollarse es la de Definir los Requisitos No Funcionales (A1). Para esto, es necesario que la organización haya establecido una meta, un problema, un riesgo a solucionar, como entrada a la actividad. Esto significa identificar cuál es la necesidad de información de medición y evaluación que se quiere satisfacer. La necesidad de información tiene, entre otros atributos, el propósito. En la Sección 2.2.1, se describió que GOCAME está destinada a llevar a cabo metas de necesidades de información de medición y evaluación cuyo propósito sea el de “comprender”. Con la necesidad de información, se identifican el foco de la evaluación y las características asociadas. Se define además, el modelo de concepto adecuado, y los atributos, conformando el árbol de requisitos. En base a estas definiciones, se genera el documento que contiene la especificación de los requisitos no funcionales, dando por finalizada la actividad de Definir los Requisitos No Funcionales.

Figura 2.8 Vista funcional y de comportamiento del proceso de GOCAME.

La próxima actividad es la de Diseñar la Medición (A2), la cual permite identificar las métricas que cuantificarán cada atributo del árbol de requisitos, seleccionándolas de un repositorio de métricas de la organización. La salida de esta actividad es el documento de especificación de métricas. En la Figura 2.8, el repositorio de métricas está indicado con el estereotipo «datastore» y contiene los metadatos asociados a métricas que han pasado por un proceso de discusión y consenso entre expertos [Baffini et al., 2006]. Una vez que la medición fue diseñada, pueden realizarse en paralelo o en cualquier orden, el diseño de la evaluación o la implementación de la medición.

Si se escoge como próxima actividad Diseñar la Evaluación (A4), la misma establece la identificación de los indicadores elementales y derivados (seleccionados desde un repositorio de indicadores) que interpretarán las medidas obtenidas para cada atributo del árbol de requisitos y calcularán los valores resultantes para las características y sub-características evaluadas. La salida de esta actividad es el documento Especificación de Indicadores el cual se conforma por los documentos de Especificación de Indicadores Elementales para los atributos y de un conjunto de documentos de Especificación de Indicadores Derivados para las características.

Por su parte, la actividad Implementar la Medición (A3) utiliza las métricas diseñadas para medir los atributos y obtener las medidas, las cuales se almacenan en el repositorio de medidas (ver «datastore» Medidas de la Figura 2.8). Esta actividad implica ejecutar, iterativamente, la tarea de medición la cual consume un atributo y produce una medida.

La próxima actividad, Implementar la Evaluación (A5), consiste en ejecutar iterativamente la tarea de evaluación elemental para cada medida de los atributos, obtenida del repositorio de medidas y producir un valor de indicador, que será almacenado en el repositorio de valores de indicadores (ver «datastore» Valores de Indicadores de la Figura 2.8). Una vez que la evaluación de los indicadores elementales ha sido ejecutada para la interpretación de todos los atributos, debe llevarse a cabo la evaluación derivada para comprender el nivel de satisfacción alcanzado por cada característica en el árbol de requisitos. La tarea de evaluación derivada, a diferencia de la tarea de evaluación elemental consume un valor de indicador y produce otro valor de indicador.

Finalmente, se lleva a cabo la actividad de Analizar y Recomendar (A6), que tiene como entrada los valores de las medidas y de los indicadores, el documento de especificación de requisitos no funcionales y los metadatos asociados a la especificación de las métricas e indicadores, para producir el Informe de Conclusión y el Informe de Recomendación. Este informe permite conocer fortalezas y debilidades identificados en los atributos evaluados. Con esta información, los interesados comprenden la situación actual de la entidad evaluada respecto al foco de evaluación y pueden, a partir de ella, tomar las decisiones pertinentes.

2.4.2. Proceso de SIQinU

El proceso que establece SIQinU para comprender y mejorar la calidad en uso tiene seis fases principales [Becker et al., 2011], [Becker et al., 2012], a saber:

- Fase I: Especificar Requisitos y Criterios de Evaluación para Calidad en Uso.

- Fase II: Ejecutar la Evaluación y los Análisis de la Calidad en Uso.

- Fase III: Derivar/Especificar Requisitos y Criterios de Evaluación para Calidad Externa.

- Fase IV: Ejecutar la Evaluación y Análisis de Calidad Externa.

- Fase V: Recomendar, Ejecutar Acciones de Mejora y Re-evaluar Calidad Externa.

- Fase VI: Re-evaluar Calidad en Uso y Analizar Acciones de Mejora.

La Figura 2.9 muestra la vista de comportamiento del proceso con las fases mencionadas y las actividades que involucran.

La fase I, Especificar Requisitos y Criterios de Evaluación para Calidad en Uso, consiste en definir los requisitos no funcionales para calidad en uso relacionados a la entidad a evaluar. Para esto, se selecciona un modelo de calidad que incluya características y sub-características relacionadas al foco de evaluación, calidad en uso (o alguna de sus sub-características asociadas) y se determinan atributos para la entidad [Lew et al., 2012]. Esta fase implica también diseñar las tareas y sub-tareas más comunes y representativas a realizar utilizando la aplicación software/web, puesto que la calidad en uso se evalúa considerando las tareas que el usuario realiza al utilizar la aplicación. Se especifica también el tipo de usuario y el contexto de uso. Luego de esto, se diseñan las métricas que se usarán en la medición y los indicadores a utilizar durante la evaluación.

Figura 2.9 Vista de comportamiento del proceso de SIQinU.

La fase II, Ejecutar la Evaluación y los Análisis de la Calidad en Uso, lleva a cabo la medición y la evaluación, actividades que permitirán obtener valores de medidas y de indicadores respectivamente. Estos valores permiten conocer el nivel de satisfacción alcanzado por la entidad evaluada respecto a calidad en uso. De esta manera se detectan problemas de calidad en uso que deben ser resueltos. Esta fase también involucra recolectar datos de uso y, para esto, es deseable que la aplicación evaluada tenga la capacidad de registrar datos tales como cantidad de errores, completitud y precisión en la realización de las tareas, tipo de usuarios, entre otros. Las medición de los diferentes atributos se realiza a partir de los datos de uso almacenados en archivos de registro, logrando así una medición no intrusiva que no afecta el desempeño del usuario. Las actividades de la segunda fase están enfocadas en conseguir el primer propósito de la estrategia SIQinU, a saber: conocer el nivel de satisfacción actual de la calidad en uso de la aplicación evaluada.

En la fase III, Derivar/Especificar Requerimientos y Criterios de Evaluación para Calidad Externa, se derivan requisitos no funcionales relacionados a calidad externa considerando los problemas encontrados en la fase II. Este mapeo o derivación de características y atributos de calidad en uso a características y atributos de calidad externa se realiza considerando las relaciones establecidas en los estándares ISO 9126 e ISO 25010, a saber, la calidad en uso “depende de” la calidad externa y ésta a su vez “influencia” la calidad en uso. En esta fase además, se diseña la medición y evaluación de calidad externa especificando las métricas e indicadores a utilizar. La fase III se centra en el diseño de aspectos relacionados a la evaluación de la calidad externa, mientras que la fase I se centraba en calidad en uso.

La fase IV, Ejecutar Evaluación y Análisis de Calidad Externa, lleva a cabo la cuantificación de los atributos definidos en la fase III por medio de las métricas seleccionadas. Además, se calculan los valores de indicadores elementales para dichos atributos y globales para características y sub-características del modelo de calidad externa. Luego de realizada la medición y evaluación, se llevan a cabo los análisis para determinar las mejoras que deben realizarse sobre la aplicación. A diferencia de la fase II donde se recolectaban datos a partir de archivos de registro, en la fase IV, la medición y evaluación se realizan por inspección de expertos.

La fase V, Recomendar, Ejecutar Acciones de Mejora y Re-evaluar Calidad Externa, involucra establecer e implementar acciones de mejora en base al análisis realizado en la fase IV. Las acciones de mejora se establecen indicando cómo se realizarán los cambios en la aplicación.

Posteriormente, se procede a re-evaluar la entidad con el foco de calidad externa para conocer la ganancia lograda respecto a la evaluación de la fase IV. Puede que sea necesario implementar nuevas mejoras en la aplicación evaluada o bien que los evaluadores detecten nuevos atributos de calidad externa que pueden derivarse. Si este fuera el caso, se puede volver a realizar la fase III para definir un nuevo árbol de requisitos y especificar las nuevas métricas e indicadores a utilizarse.

El proceso culmina con la fase VI, Re-evaluar Calidad en Uso y Analizar Acciones de Mejora, en la cual se vuelve a evaluar la calidad en uso para comparar la ganancia lograda respecto a la obtenida en la fase II. Si la ganancia no fue la esperada, entonces se puede volver a ejecutar la fase III, mejorando la calidad externa y así sucesivamente hasta que el nivel de aceptabilidad para calidad en uso sea el requerido.

2.4.3. Proceso de GOCAMEC

El proceso de GOCAMEC es similar al que especifica GOCAME, pero difiere en que especifica actividades que permiten introducir cambios orientados a la mejora. Dicho proceso genérico se presenta en la Figura 2.10 y consta de ocho actividades principales [Rivera et al., 2014], a saber :

- A1 Definir los Requisitos no Funcionales.

- A2 Diseñar la Medición.

- A3 Implementar la Medición.

- A4 Diseñar la Evaluación.

- A5 Implementar la Evaluación.

- A6 Analizar y Recomendar.

- A7 Diseñar las Acciones de Cambio.

- A8 Implementar las Acciones de Cambio.

Las primeras seis actividades son las mismas que las descriptas para GOCAME. La actividad Analizar y Recomendar (A6) permite realizar un análisis de los valores de indicadores obtenidos y, en base a éstos, recomendar cambios a realizar a fin de lograr mejorar la calidad de la entidad. Como resultado de esta actividad se obtiene el documento Informe de Recomendación, donde se detallan recomendaciones para aquellos atributos que no satisfacen cierto nivel de aceptabilidad. En base al Informe de Recomendación, se debe analizar si se desea mejorar el nivel de satisfacción de los atributos cuyo valor de indicador obtuvo un bajo nivel de desempeño. En caso de querer realizar los cambios propuestos en el informe, se lleva a cabo la actividad Diseñar las Actividades de Cambio (A7).

En la actividad A7, de acuerdo al Informe de Recomendación se especifican las acciones para cada recomendación, otorgando una prioridad a las mismas e indicando cómo deben llevarse a cabo en pos de concretar los cambios. El cómo, indica cada uno de los métodos y/o técnicas que se emplearán para hacer efectivas las acciones de cambio, como por ejemplo reconfiguraciones parametrizadas, reprogramación del código, refactoring de interface, rediseño arquitectural, por mencionar algunas. Como resultado se obtiene el Plan de Mejoras que organiza y prioriza, las acciones de cambio a desarrollar para cada recomendación dada.

Figura 2.10 Vista funcional y de comportamiento del proceso de GOCAMEC.

Finalmente, la actividad Implementar las Acciones de Cambio (A8) lleva a cabo, en la entidad evaluada, las acciones de cambio previstas en el documento Plan de Mejoras. Como salida se genera una nueva versión, mejorada, de la entidad evaluada.

Luego de implementados los cambios, puede volver a evaluarse la entidad con los cambios producidos en A8 para comprender la ganancia lograda en la mejora. Si se desea realizar la re-evaluación, entonces se vuelven a realizar las actividades A3, A5 y A6, como puede observarse en la Figura 2.10. Las actividades A1, A2 y A4 no vuelven a realizarse puesto que se miden y evalúan los atributos y conceptos calculables ya especificados, utilizando las métricas e indicadores previamente definidos. Los resultados obtenidos en la nueva versión pueden ser comparados con la versión original a fin de notar si los cambios implementados dieron resultados y determinar cuáles atributos han aumentado su nivel de satisfacción gracias a las mejoras introducidas o, por el contrario, cuáles han visto su nivel disminuido. Puede ocurrir que cambios en algunos atributos se traduzcan en un detrimento del nivel de satisfacción de otros que estaban en niveles óptimos. Si esto ocurre, se vuelve a recomendar acciones de cambio que intenten mejorar otros atributos mediante un nuevo documento Plan de Mejoras. El proceso continúa cíclicamente hasta lograr una versión de la entidad evaluada con el nivel de mejora deseado.

GOCAMEC contempla de algún modo el ciclo de mejora continua propuesto inicialmente por Shewhart y adaptado y difundido posteriormente por Deming. El ciclo conocido como Planificar, Hacer, Verificar y Actuar (popularizado como PDCA por sus siglas en inglés de Plan-Do-Check-Act y luego renombrado como PDSA, tras intercambiar la palabra Check por Study) [Deming, 1986] representa un enfoque básico para la mejora continua donde se planifican acciones de mejora, se las lleva a cabo, luego se verifican (evalúan) los resultados obtenidos para, finalmente, actuar sobre los problemas hallados, pudiendo implicar esto, una nueva iteración del ciclo PDCA.

2.5. Métodos de Medición y Evaluación

Un proceso describe concretamente qué hacer pero no especifica cómo hacerlo. Para esto, son necesarios métodos, técnicas y herramientas que sean aplicados sistemáticamente a las distintas tareas del proceso. El tercer principio de una estrategia integrada lo constituyen los métodos.

Existen distintas categorías de métodos, a saber, de inspección, de testing, de consulta, simulación, entre otros; y tipos específicos de métodos de evaluación como evaluación heurística, análisis de archivos de registros y evaluación de características. Las estrategias GOCAME, SIQinU y GOCAMEC utilizan métodos de inspección y evaluación de características (aunque podrían utilizar otros tipos de métodos como por ejemplo redes neuronales, cuando son usadas para evaluar calidad u otras características como costo). De acuerdo a este tipo de método, en [Olsina y Rossi, 2002] se propone como base, la metodología WebQEM (Web Quality Evaluation Method ) que aporta los métodos y herramientas necesarios para dar soporte al proceso que describen las estrategias.

Los métodos que se proponen en WebQEM para llevar a cabo la medición y la evaluación son las métricas e indicadores respectivamente. Específicamente, para la tarea de cuantificar un atributo existen dos tipos de métricas: directas e indirectas y cada una especifica los pasos concretos a seguir para realizar la medición del atributo.

Una métrica directa especifica dichos pasos en el procedimiento de medición, mientras que una métrica indirecta lo especifica en el procedimiento de cálculo. La Figura 2.11 muestra la plantilla de especificación de una métrica directa y de una indirecta, detallando el nombre de la misma, el atributo que cuantifica, el procedimiento que debe seguirse para obtener el valor del atributo, la escala que utiliza y su respectiva unidad.

Figura 2.11 Plantillas de especificación de métodos para la tarea de medición:
a) Métrica Directa; b) Métrica Indirecta.

Para las tareas de calcular un indicador elemental y calcular un indicador derivado se utilizan indicadores elementales y derivados respectivamente. Los indicadores elementales establecen cómo transformar el valor medido del atributo en un valor que represente el nivel de satisfacción de dicho atributo. Los indicadores derivados en cambio, especifican cómo calcular el nivel de satisfacción pero para los conceptos calculables, utilizando modelos de agregación de características, sub-características y atributos. La especificación de estos cálculos se realiza por medio de la especificación del procedimiento de cálculo y la interpretación del valor medido se realiza a través de los criterios de decisión. La Figura 2.12 muestra la plantilla de especificación de un indicador elemental.

Respecto a la utilización de soporte tecnológico para llevar a cabo los métodos propuestos, en [Molina, 2012] se presenta una aplicación web denominada C-INCAMI_Tool la cual automatiza el proceso de medición y evaluación de la estrategia GOCAME. La aplicación posibilita al usuario la creación del proyecto de medición y evaluación específico, la especificación de los requisitos no funcionales y de información de contexto, el diseño e implementación de la medición y evaluación, además de la generación de informes con los resultados obtenidos. C-INCAMI_Tool se basa además en el marco conceptual C-INCAMI para especificar los datos y metadatos involucrados.

Figura 2.12 Plantilla de especificación del método para la tarea de evaluación elemental: Indicador Elemental.

2.6. Conclusiones

Dado el creciente auge de tecnologías, las organizaciones de software no solamente necesitan contar con métodos de desarrollo robustos para mejorar el proceso de construcción, sino que también es necesario que consideren mecanismos para medir y evaluar los productos intermedios y finales. En este sentido, este capítulo ha discutido la utilización de estrategias integradas de medición y evaluación para llevar a cabo metas de necesidades de información de medición y evaluación.

La utilización de estrategias que integren simultáneamente i) un marco conceptual de dominio, ii) la especificación del proceso y iii) métodos y herramientas, permite a la organización disponer de manera consensuada los términos involucrados en el dominio logrando de este modo, consistencia en la utilización de los mismos. A su vez permite tener especificado concretamente cuáles son las actividades, roles y agentes destinados para cumplir un fin y por último, especificar la manera en la que se llevarán a cabo las tareas que implican las actividades que establece el proceso. De este modo, la recolección de las medidas como parte de las tareas de medición, así como también el cálculo de los indicadores como parte de la tarea de evaluación, en conjunto con los análisis y recomendaciones finales, pueden repetirse entre proyecto y proyecto, posibilitando la comparación y consistencia de resultados y la posterior toma de decisión.

En este capítulo se presentaron tres estrategias integradas, destinadas cada una a satisfacer un propósito específico de una meta de necesidad de información de medición y evaluación. La estrategia GOCAME está diseñada para satisfacer metas con el propósito de comprender la situación actual de la entidad a evaluar. Este propósito de comprender se relaciona a conocer, como si se tratara de una instantánea que muestra el nivel de satisfacción alcanzado por una entidad respecto de, por ejemplo, su calidad interna o externa. Por su parte, la estrategia GOCAMEC, suma a las capacidades de GOCAME, la realización de cambios tendientes a mejorar la entidad bajo análisis. Satisface metas con el propósito de mejorar, a partir de la realización de cambios guiados por medición y evaluación.

Finalmente, SIQinU es una estrategia para llevar a cabo metas que impliquen mejorar calidad en uso a partir de mejoras realizadas en calidad externa de la entidad a evaluar. Para esto, y a diferencia de los procesos establecidos para las dos estrategias anteriores, establece un ciclo que consiste en (1) mejora del sistema, (2) re-evaluación de calidad externa, y (3) re-evaluación de calidad en uso.

El objetivo de este capítulo fue presentar los conceptos necesarios que permitirán identificar el problema y la motivación del trabajo. La Figura 2.13 ilustra los fundamentos teóricos abordados. Por un lado, se observa la alegoría de los tres principios que debe satisfacer una estrategia integrada y, por otro lado, cuales han sido los avances en el grupo de investigación respecto a estrategias que cumplen con tales características. La segunda parte de la tesis analiza el estado del arte y señala aspectos a robustecer de la teoría abordada hasta el momento.

Figura 2.13 Fundamentos de estrategias integradas de medición y evaluación.

Parte II:
Estado del Arte, Problema Detectado y Solución Propuesta

Capítulo 3 - Estado del Arte

En este capítulo se analizan trabajos relacionados a los tres ejes temáticos que conducen esta tesis, a saber: i) vistas de calidad, ii) enfoques multinivel de medición, evaluación y mejora de la calidad, y estrategias integradas; y iii) patrones de estrategia. La organización del capítulo es la siguiente:

– Sección 3.1: Analiza trabajos sobre vistas de calidad y sus relaciones.

– Sección 3.2: Describe enfoques de evaluación y mejora de la calidad, así como también estrategias integradas de medición y evaluación que contemplen alineamiento de metas a distintos niveles organizacionales.

– Sección 3.3: Analiza trabajos sobre la utilización de patrones de estrategia de medición y evaluación.

– Sección 3.4: Expone las conclusiones del capítulo, mencionando las debilidades encontradas en el estado del arte. Las mismas servirán para describir los temas que aborda el Capítulo 4, esto es, la problemática detectada y la solución propuesta.

3.1. Vistas de Calidad

Según Kitchenham y Pfleeger [Kitchenham y Pfleeger, 1996] la calidad es un concepto complejo porque significa diferentes cosas para diferentes personas y es además, altamente dependiente del contexto. Mencionan que, así como no hay un automóvil que satisfaga las necesidades de cada persona, no hay una definición universal de calidad. No es posible determinar tampoco una única manera de medirla que sea aceptable para todos. Por lo tanto, cuando se trata de medir y evaluar la calidad, se deben definir los aspectos de la misma (caracterizarla) en los cuales se está interesado. La manera en la que se mide depende del punto de vista que se considere y los aspectos de la misma que se quieran capturar [Kitchenham y Pfleeger, 1996]. En especial, se observa que estos aspectos (conocidos como focos de calidad) se determinan en una meta de medición y evaluación.

Bajo estas consideraciones, las vistas de calidad son un concepto clave en un enfoque de medición y evaluación. En su artículo de los años ’80, What does product quality real ly mean? [Garvin, 1984], Garvin sugiere que la importancia y significado de calidad difiere de acuerdo a las vistas (o perspectivas) que se tenga. Estas vistas ayudan a decidir qué significa calidad de acuerdo a diferentes aspectos y colaboran en desarrollar métricas que posibiliten la medición de las entidades involucradas. De acuerdo a esto, Garvin describió la calidad a partir de cinco vistas, considerando la manera en la que distintas personas la perciben. Dichas perspectivas son:

Vista trascendental : La calidad es algo que se puede reconocer pero no definir. Bajo esta perspectiva, calidad es sinónimo de “excelencia innata”.

Vista de usuario: La calidad se ajusta a un propósito. Se corresponde con una perspectiva personal y subjetiva de la calidad.

Vista de manufactura: La calidad se define conforme con los requisitos y las especificaciones establecidas.

Vista de producto: La calidad está ligada a propiedades inherentes del producto.

Vista basada en el valor : La calidad depende en la cantidad que el cliente está dispuesto a pagar.

Garvin señala que hay una “necesidad de cambiar activamente un enfoque de calidad en la medida que los productos se mueven desde el diseño al mercado. Las características que connotan a la calidad deben primero, ser identificadas a través de un estudio de mercado (enfoque de calidad basado en el usuario), estas características deben luego ser traducidas en atributos del producto (enfoque de calidad basado en el producto); y el proceso de manufactura debe entonces estar organizado para asegurar que los productos están hecho siguiendo estas especificaciones (enfoque de calidad basado en manufactura). Un proceso que ignore algunos de estos pasos no dará como resultado un producto de calidad. Las tres vistas son necesarias y deben ser conscientemente cultivadas” [Garvin, 1984, p.29].

En consideración de las vistas de calidad que describió Garvin, Baskerville et al. mencionan la vista basada en el producto y la vista basada en el usuario. Al respecto enuncian que “la vista de calidad basada en el producto establece que, debido a que calidad se vincula con características mensurables de un producto, la calidad del producto representa la conformidad a los requerimientos establecidos para el producto [...]. La vista basada en el usuario, en contraste, dice que la calidad trata sobre colmar las expectativas del usuario o ’ajustarse a un propósito’. Es importante saber qué práctica afecta qué vista y cómo” [Baskerville et al., 2001, p.56].

En el año 2001, el estándar ISO 9126 hizo explícita las relaciones de “influencia” y “depende de” entre, lo que denominan, enfoques de calidad (ver Figura 3.1). Al respecto establece que “la calidad del proceso [...] contribuye a mejorar la calidad del producto y la calidad del producto contribuye a mejorar la calidad del producto en uso. Por lo tanto, evaluando y mejorando un proceso es un medio para mejorar la calidad de un producto y, evaluando y mejorando la calidad de un producto es un medio para mejorar la calidad en uso. De manera similar, evaluando calidad en uso puede proveer retroalimentación para mejorar un producto y evaluando un producto puede proveer retroalimentación para mejorar un proceso.” [ISO/IEC, 2001, p.2]. Además, señala que la evaluación de estas vistas puede ser alcanzada utilizando medidas del proceso, en adición con medidas internas, externas y de calidad en uso.

Figura 3.1 Enfoques (vistas) de calidad y sus relaciones. Extraído de ISO 9126 [ISO/IEC, 2001].

En el año 2011 surge el estándar ISO 25010 que se diferencia de su antecesor (el estándar ISO 9126) por, entre otras cuestiones, considerar la vista de recurso, manteniendo de igual modo, la hipótesis de las relaciones de “influencia” y “depende de”. Establece que los procesos que componen el ciclo de vida del software (tales como los procesos de requerimientos de calidad, de diseño o de testing) influencian la calidad del producto software. Por otra parte, la calidad de los recursos, tales como recursos humanos, herramientas de software y técnicas usadas para los procesos, influencia la calidad del proceso y, por consiguiente, influencia también la calidad del producto. A su vez, la calidad del producto software (un diseño arquitectural, el código fuente de un módulo, por ejemplo), influencia la calidad del sistema y ésta, la del sistema en uso. La calidad del sistema en uso tiene varias influencias (efectos) dependiendo del contexto de uso. El contexto de uso puede ser definido por el conjunto de usuarios, tareas y ambiente. La Figura 3.2 ilustra estas vistas objetivos para calidad y sus relaciones de acuerdo a lo establecido por la ISO 25010.

Figura 3.2 Vistas objetivos y sus relaciones para evaluar calidad. Nota: VCa significa “Vista de Calidad a” y VCb significa “Vista de Calidad b”. Adaptada de: ISO 25010 [ISO/IEC, 2011].

Si bien estos estándares identifican distintas vistas de calidad y sus relaciones; el glosario de términos que describen en sus anexos no contiene la definición explícita del término vista de calidad, al igual que la definición de las relaciones de “influencia” y “depende de”. Es importante destacar también al estándar de facto CMMI, el cual está soportado por la evidencia de que, evaluando y mejorando el proceso, esto es, por medio de completar adecuadamente las metas específicas y genéricas requeridas de cada área de proceso, es un medio para mejorar la calidad del producto y/o servicio [CMMI Product Team, 2010].

Otro trabajo relacionado con vistas de calidad es [Moraga et al., 2008] en el cual la relación de “influencia” entre calidad externa y calidad en uso, es determinada por medio de redes bayesianas, tomando como referencia el estándar ISO 9126. En el trabajo, los autores proponen cambiar el foco de evaluación de la calidad, concentrándose en la calidad en uso como el factor conductor a considerar cuando se diseña un producto de software o cuando se selecciona un producto que mejor satisfaga las necesidades del usuario. Para esto, proponen un análisis hacia atrás, comenzando con un nivel dado de calidad en uso y se quiere determinar el nivel mínimo requerido de calidad externa que garantice tal nivel deseado de calidad en uso. Este enfoque es opuesto al tradicional que, valiéndose de la relación de “influencia”, realiza un análisis hacia adelante, tratando de determinar el nivel de calidad en uso de un producto software a partir de resultados obtenidos para calidad externa. Con la utilización de redes bayesianas para representar las relaciones entre calidad en uso y calidad externa, los autores analizan diferentes posibilidades para modelar dichas relaciones y proponen un enfoque que puede ser usado para distintos contextos de uso. El trabajo es interesante desde el punto de vista de la construcción de redes bayesianas para determinar la cantidad mínima de sub-características de calidad externa que influencian la calidad en uso de un producto software. Sin embargo, en este trabajo tampoco se presenta una base conceptual definiendo los términos de vista de calidad y sus relaciones.

Otro trabajo relacionado es [Neil et al., 2003], en el cual se propone también el uso de redes bayesianas para predecir algunas características de calidad externa pero, en este caso, a partir de ciertas características de calidad interna de un producto software. En este trabajo, los autores enfatizan que un aspecto imprescindible, de importancia, que debiera estar asegurado en el control de la calidad de software es la identificación de características de calidad interna de un producto que proporcionen una buena estimación respecto a si las características esperadas de calidad externa del producto serán alcanzadas. Al respecto, afirman que, en ingeniería de software, las relaciones causales entre calidad interna y calidad externa son rara vez sencillas de determinar.

La relación de “influencia” entre calidad interna y calidad externa fue también analizada en [Hansen et al., 2011]. En este trabajo, los autores plantean que, si bien es convenido que la arquitectura del software influencia la calidad del producto software, existe poca investigación empírica realizada respecto a dicha relación. Para esto, definen tres métricas referidas a la arquitectura de software (un producto) y se analiza el grado en el cual estas métricas se relacionan con métricas del producto software (el sistema). Si bien coinciden en el hecho de considerar la vista de calidad interna (la arquitectura del producto software) y su relación de “influencia” a la vista de calidad externa (el sistema software) con las definiciones de la ISO 9126, este trabajo tampoco define cómo se conforma una vista de calidad.

Finalmente, en [Lew et al., 2010] y [Olsina et al., 2012] se propone un marco de calidad denominado 2Q2U. Este trabajo extiende los modelos de calidad definidos en la ISO 25010, agregando nuevas características para calidad externa y calidad en uso. Además, considera las relaciones de “influencia” y “depende de” para tres vistas de calidad, a saber: vista de calidad de producto software, vista de calidad de sistema y vista de calidad de sistema en uso. Al igual que las propuestas comentadas, en [Olsina et al., 2012] no se presenta una base conceptual para el dominio de vistas de calidad. Por otra parte, los modelos de calidad propuestos fueron instanciados usando la estrategia integrada SIQinU, la cual permite mejorar calidad en uso de manera incremental, a partir de cambios realizados en el sistema.

En conclusión, no hay trabajos que definan y especifiquen términos del dominio de vistas de calidad, estructurándolos formalmente en una ontología o simplemente, en un glosario de términos. Además, las vistas o perspectivas de calidad que definen no distinguen el foco de evaluación, como tampoco, la categoría de entidad a medir. Como se mencionó al inicio de la sección, las vistas de calidad son importantes en los enfoques de medición y evaluación. La determinación de ellas permite conocer cuál perspectiva de la calidad se está considerando dada una meta de medición y definir de acuerdo a esto, la estrategia apropiada para satisfacer el propósito de la meta.

3.2. Enfoques Multinivel y Estrategias Integradas Orientados a Medición, Evaluación y Mejora de la Calidad

La salida de las actividades de medición y evaluación constituyen una de las principales fuentes de información sobre la cual los ingenieros de calidad o gerentes deben basar sus decisiones. A través del establecimiento de metas de necesidad de información que den soporte a metas de negocio, las actividades de medición y evaluación pueden ser llevadas a cabo de un modo bien direccionado y motivado [Rowe y Whitty, 1970]. Los enfoques de medición basados en metas se consolidan a partir de metas o necesidades de información específicas que deben resolver. Aunque, frecuentemente, y como ha sido planteado en la Introducción, dichos enfoques no contemplan la vinculación de metas a distintos niveles organizacionales.

En esta sección se describen enfoques de gestión de la calidad y estrategias integradas que contemplan de algún modo metas de negocio y de necesidad de información de medición y evaluación a distintos niveles organizacionales. Los trabajos analizados son aquellos que más se acercan a la propuesta de esta tesis, a saber: GQM⁺ Strategies, Balanced Scorecard (BSC), Goal-Question (Indicator) Metric (GQ(I)M), el enfoque combinado BSC+GQ(I)M, la guía de medición de software basado en metas y Practical Software and System Measurement (PSM). Además, se describen las limitaciones detectadas para las estrategias integradas descriptas en el Capítulo 2; GOCAME, SIQinU y GOCAMEC.

3.2.1. GQM⁺ Strategies-Goal Question Metric Plus Strategies

Uno de los enfoques de medición más usados a nivel académico e industrial es GQM (Goal Question Metric). GQM fue propuesto en los años ‘80 por Basili y Weiss [Basili y Weiss, 1984], [Caldiera et al., 1994] y permite planificar e implementar programas de medición de software orientados a metas u objetivos. La premisa que subyace en GQM es que la medición es un buen mecanismo para obtener información y señala la importancia de comprender qué datos recolectar considerando qué cosas la organización quiere saber (metas). En base a las metas (goal en el enfoque) se generan preguntas (question) que proveerán los datos (metric) cuya interpretación otorga la información para satisfacerlas.

El mecanismo básico de derivación de preguntas y métricas a partir de los objetivos propuestos a satisfacer se ilustra en la Figura 3.3 y es el siguiente. Por cada meta que la organización quiere alcanzar, se establecen un conjunto de preguntas relacionadas, cada una de las cuales son operacionalizadas cuantitativamente por medio de una o más métricas. Para interpretar los datos obtenidos de la medición utiliza implícitamente modelos, considerando además, el contexto específico.

Figura 3.3 Enfoque GQM. Extraído de: [Buglione y Abran, 2000].

El problema en el que incurre GQM es que no está explícito el alineamiento entre los objetivos de medición (a nivel operativo) y metas de negocio de una organización [Buglione y Abran, 2000], [Trendowicz et al., 2014]. El principal objeto de interés para las actividades de medición que establece, ha sido y continúa siendo, a nivel de proyecto de software [Buglione y Abran, 2000].

La evolución de GQM para solventar esta limitación, dio origen a GQM⁺ Strategies [Basili et al., 2007a], [Basili et al., 2007b], [Basili et al., 2010], [Trendowicz et al., 2014]. La diferencia con GQM radica en la capacidad de alinear metas a distintos niveles organizacionales a través de la formulación de estrategias para satisfacer esas metas y generar otras de niveles más bajos. Las metas principales son las intenciones futuras que la organización desea alcanzar, en términos de sus negocios. Por otra parte, las estrategias son las acciones definidas para alcanzar esas metas. Las metas y estrategias se vinculan a través de todos los niveles organizacionales y, por medio de los datos obtenidos de la medición, se evalúa el logro de cada meta y el éxito o fracaso de la implementación de las estrategias.

El término “estrategia” que GQM⁺ Strategies menciona, se refiere más bien a táctica, es decir, a un plan o curso de acción específico para alcanzar un objetivo. Esto difiere levemente de la definición dada en la Sección 2.1, donde se estableció que una estrategia integrada es un recurso que establece qué hay que hacer, cómo hacerlo y que además, comprende la definición conceptual de los términos que intervienen en el dominio de aplicación de la estrategia. De acuerdo a esta definición, es posible clasificar a GQM⁺ Strategies como una estrategia integrada, puesto que en gran medida satisface los tres principios, como a continuación se describirá. No obstante, en el resto de la sección se utilizará el término “estrategia” con el significado que los autores de GQM⁺ Strategies le otorgan.

GQM⁺ Strategies especifica un modelo conceptual y un proceso. El modelo conceptual (denominado grilla) comprende un conjunto mínimo de términos y relaciones involucrados en la definición de metas, estrategias y la vinculación de ellas a distintos niveles organizacionales. Además, se incluye el conocimiento empleado para evaluar el logro de las metas. El modelo está dividido en dos sub-modelos: los elementos GQM⁺ Strategies y el grafo GQM (ver Figura 3.4).

Figura 3.4 Grilla de GQM⁺ Strategies. Extraída de: [Trendowicz et al., 2014].

El sub-modelo correspondiente a los elementos GQM⁺ Strategies especifica las metas organizacionales y las estrategias, los factores de contexto, las suposiciones y las relaciones entre ellos. Una meta especifica “¿qué quiere alcanzarse?” y se documenta por medio de una plantilla. La meta puede estar relacionada con una o más estrategias que estén destinadas a alcanzar esa meta. La estrategia responde a la pregunta “¿cómo se alcanzará la meta?” y define los medios para alcanzar dicho fin (el logro de la meta). Las estrategias pueden estar vinculadas a submetas de niveles inferiores que deben ser alcanzadas por esa estrategia para ser exitosa. Las características propias de la organización inciden sobre el establecimiento de las metas y la selección de la estrategia. En este sentido, tiene relevancia el contexto y las suposiciones. El contexto son las características actuales del entorno, en tanto que las suposiciones se refieren a aspectos del entorno inciertos o presuntos. Constituyen indicadores de lo que necesita ser evaluado a partir de mediciones.

El sub-modelo correspondiente al grafo de GQM especifica un marco de medición y evaluación. Comprende los términos del enfoque clásico de GQM para especificar qué datos necesitan ser recolectados y cómo esos datos deben ser interpretados, de manera de informar sobre el éxito de la estrategia y el logro de las metas organizacionales definidas en los elementos de GQM. Cada grafo de GQM consiste en una meta de medición, preguntas, las métricas y un modelo de interpretación. Un grafo GQM debiera ser definido para cada meta organizacional de manera de evaluar cuantitativamente su logro. Cada meta organizacional establecida de acuerdo al componente de los elementos de GQM⁺ Strategies, puede tener asociadas muchas metas de medición, cada una de las cuales darán origen a un grafo completo de GQM. En [Trendowicz et al., 2014] se definen los términos que componen el modelo de GQM⁺ Strategies. Este modelo jerárquico de metas y estrategias no solo permite la definición de metas organizacionales y estrategias, sino también la definición de un modelo de medición sistemático y relevante para la perspectiva de planificación organizacional.

Respecto al proceso establecido para GQM⁺ Strategies, en la práctica el mismo puede ser instanciado para necesidades específicas de una organización, lo cual significa que algunas actividades pueden ser omitidas o bien mezcladas con procedimientos existentes en la organización. El proceso completo que se propone para ser implementado consiste de seis fases, a saber: 1) Caracterización del ambiente, 2) Definición de metas, estrategias y medición, 3) Planificación de la implementación de la grilla, 4) Ejecución de los planes, 5) Análisis de resultados y 6) Desarrollo de mejoras; y una fase adicional, 0) Inicialización, que sirve para inicializar el programa de medición en la organización. Las seis fases están organizadas como un ciclo continuo de mejora -desarrollo, implementación y aprendizaje- (ver Figura 3.5) el cual está basado en el Paradigma de Mejora de la Calidad (Quality Improvement Paradigm, QIP) [Basili, 1985] [Basili y Caldiera, 1995] o al tamaño de la grilla que se ha modelado y de cuán rápido la organización quiere evolucionar y mejorar.

La fase 0 se denomina “Inicialización” y asegura que la infraestructura y los recursos necesarios para la aplicación de GQM⁺ Strategies estén disponibles y que además, se lleve a cabo la planificación inicial del proceso de la próxima etapa. El resto de las seis fases están comprendidas en tres etapas: “Desarrollo”, “Implementación” y “Aprendizaje”.

Figura 3.5 Proceso de GQM⁺ Strategies. Extraído de: [Trendowicz et al., 2014].

La primera etapa se denomina “Desarrollo” y consiste en el desarrollo de una grilla jerárquica que alinea las metas, las estrategias y los datos requeridos de medición. Esta grilla es útil a fines de lograr consenso entre metas y estrategias y comunicar este acuerdo a la organización. En esta etapa se desarrollan dos fases. En la fase 1, “Caracterización del ambiente”, se identifica el motivo que conduce a la formulación de metas de negocio. Para esto, se definen los factores de contexto de la organización. Esto implica caracterizar el producto o servicio provisto, identificar los procesos existentes, las herramientas, los clientes, el modelo de negocio y por último, caracterizar programas de medición existentes y datos ya recolectados. Además de los factores de contexto, se documentan las suposiciones que conducen a las metas de negocio. Esto incluye determinar cuáles aspectos se pueden considerar como verdadero pero se tiene poco o nada de evidencia empírica al respecto. También se plantean suposiciones sobre la tecnología, el mercado, los clientes, la organización o el personal. La segunda fase se denomina “Definir metas, estrategias y medición” e implicar derivar la grilla de GQM⁺ Strategies, especificando y alineando metas organizacionales y estrategias. Además, se cuantifican las metas usando el grafo GQM. Para la identificación de las potenciales metas de alto nivel, se realizan preguntas tales como: ¿cuáles son los principios de la organización que no se quieren cambiar? ¿cuáles son los principales elementos del ambiente? (como por ejemplo satisfacción del usuario, control del riesgo, aprendizaje) ¿cuáles son las actuales metas de negocio? ¿cómo estima la organización crecer?, entre otras. Luego de esto, se priorizan las metas, identificando posibles conflictos. Posteriormente, se formalizan las metas usando la plantilla de especificación de metas. Adicionalmente, se listan potenciales relaciones con otras metas. La salida de esta fase es la grilla GQM⁺ Strategies completa y el alcance de aplicación propuesto.

La segunda etapa del proceso de GQM⁺ Strategies se denomina “Implementación” y consta de dos fases: la fase 3 y 4. La fase 3, denominada “Planificar la implementación de la grilla”, implica identificar las potenciales estrategias para alcanzar las metas de negocio. Las mismas se seleccionan de acuerdo a criterios relacionados con el costo y beneficio, y considerando también los factores de contexto y las suposiciones que naturalmente restringen la factibilidad de las posibles estrategias. La salida de esta fase son los planes de la estrategia y los planes de medición. En la fase 4, “Ejecución de los planes” se implementan las estrategias de acuerdo al plan de las estrategias y, además, los datos de medición se recolectan de acuerdo a los planes de medición. También, se analizan en términos de si las estrategias están funcionando y si las metas se están cumpliendo. Si esto no ocurre, el líder del proyecto puede hacer los ajustes necesarios a la grilla. Si se alcanza un cierto hito o se dispara un evento no esperado, se continúa con la fase 5. Como resultado de esta fase se obtienen los resultados de implementar las estrategias, la grilla de GQM⁺ Strategies actualizada, las estrategias y los planes de medición (si fue necesario), la retroalimentación respecto a la implementación de las estrategias organizacionales y datos de medición.

La tercera etapa se denomina “Aprendizaje” y consiste de las fases 5 y 6. En la fase 5, “Análisis de resultados” se analizan los logros de las metas y se investigan las causas de los éxitos y fracasos de las estrategias. En la fase 6, “Desarrollo de mejoras”, se refuerza lo que se ha aprendido en las fases previas y se solicitan acciones de mejora si los resultados difieren de los estimados y las metas asociadas no son alcanzadas. Las peticiones de mejora pueden incluir revisar las características de contexto y las suposiciones, ajustar la estructura de las metas y estrategias o redefinir la manera en que las medidas se realizan o se interpretan. La salida de estas fases consisten en los resultados del análisis respecto del éxito de las estrategias y el logro de las metas, y mejoras potenciales para el futuro de la grilla de GQM⁺ Strategies y los procesos.

La implementación de GQM⁺ Strategies requiere de un soporte tecnológico que permita llevar adelante estas fases y actividades propuestas. En este sentido, a la fecha, el equipo de GQM⁺ Strategies se encuentran trabajando en una plataforma integrada que permitirá desarrollar todo el enfoque multinivel, definiendo metas y estrategias y obteniendo datos de medición para la toma de decisión [Trendowicz et al., 2014]. Respecto a la recolección de datos automática, para GQM existen herramientas las cuales calculan métricas específicas de acuerdo a un algoritmo predefinido. En [Van Solingen y Berghout, 1999] se detalla una de estas herramientas que es configurable para cada programa de medición en una organización.

Por lo descripto, GQM⁺ Strategies constituye una estrategia integrada y multinivel de medición de la calidad, según se ilustra en la Figura 3.6. Permite alinear metas principales de negocio con metas operativas de medición a través de la utilización de estrategias, siguiendo las actividades previstas en el proceso que define. Sin embargo, se observan dos cuestiones. Por un lado, que en la selección de la estrategia, si bien aclaran que es de acuerdo al tipo de meta, no especifican el criterio de selección que obedecen. Principalmente, si entra en consideración el propósito de cada meta y las vistas de calidad que intervienen en ella. Por otro lado, aunque existe un glosario de términos, que contempla de algún modo la definición de términos del dominio de metas, tales como meta, estrategia, entre otros, no se cuenta con una conceptualización formal como una ontología para expresar los términos del dominio y sus relaciones.

Figura 3.6 Esquema general de GQM⁺ Strategies. Adaptado de: [Basili et al., 2010].

3.2.2. BSC-Balanced Scorecard

Balanced Scorecard (BSC) [Kaplan y Norton, 1996], [Kaplan y Norton, 2005] es un enfoque orientado a objetivos basado en los conceptos del enfoque francés del siglo ’20, Tableau de Bord. El Tableau consistía en traducir la visión y misión organizacional en un conjunto de objetivos, a partir de los cuales la organización identificaba sus factores de éxito claves (conocidos como KSF, del inglés Key Success Factors), los que a su vez, se traducían en una serie de indicadores cuantitativos de performance (KPI, Key Performance Indicators) [Epstein y Manzoni, 1998].

En el mismo sentido, BSC traduce la misión y estrategia de una organización en objetivos tangibles y un conjunto de métricas (las que denominan “medidas”) que se plasman en un mapa o cuadro estratégico. Este mapa conecta los objetivos a través de relaciones causales y permite visualizar gráficamente la estrategia de la organización. Los objetivos estratégicos muestran aquello que se quiere conseguir y las relaciones causales son la explicitación de las relaciones entre los objetivos. Estas relaciones están basadas en el conocimiento de la organización y de la experiencia. Reflejan la estrategia y deben también diseñarse indicadores adecuados para su seguimiento. Los objetivos en el cuadro estratégico se agrupan en cuatro perspectivas o dimensiones claves para la organización, a saber: financiera, cliente, procesos internos y, aprendizaje y crecimiento. Estas cuatro perspectivas conforman el marco de BSC (ver Figura 3.7).

Figura 3.7 Dimensiones del mapa estratégico de BSC. Extraído de: [Goethert y Fisher, 2003].

Usando el marco de BSC, una organización puede sistemáticamente establecer objetivos estratégicos para cada perspectiva y desarrollar un conjunto de métricas para medir cuantitativamente cada objetivo e indicadores para evaluar el alcance de cada objetivo logrado. El resultado es un conjunto de objetivos interrelacionados y medidas con relaciones bien definidas de causa y efecto.

BSC constituye un marco de gestión y medición, utilizado ampliamente para evaluar el resultado de las estrategias adoptadas por la organización. Las dimensiones permiten contar con un modelo equilibrado que no se centra únicamente en aspectos financieros, sino también en aquellos que involucran al cliente, usuarios y los procesos que se desarrollan. Si bien es una herramienta de gestión que comprende más allá de dimensiones financieras, no queda explícito la distinción de metas a distintos niveles organizacionales. En especial, no describe el alcance de metas de niveles inferiores. Las metas u objetivos que se definen pueden considerarse de nivel estratégico, pertenecientes a distintas dimensiones. Pero no se especifica la relación con metas más operativas, especialmente aquellas destinadas a satisfacer propósitos de medición y evaluación. En [Becker y Bostelman, 1999] se combina BSC con GQM con el objetivo de constituir un enfoque de medición que dé soporte al alineamiento de metas organizacionales y operativas, a nivel de proyecto. Para esto, los autores proponen embeber una estructura GQM en cada una de las cuatro perspectivas o cuadrantes de BSC. Con esto logran una mayor consistencia y comprensión en la notación y terminología relacionada a metas y métricas en todos los niveles. Sin embargo, el enfoque no soporta realmente metas a diferentes niveles organizacionales, a pesar de que se hace énfasis en la importancia de contar con dicho alineamiento. Las metas operativas operacionalizadas con GQM de cada cuadrante no necesariamente satisfacen las metas de negocio establecidas en otros cuadrantes, por lo que no se puede comprobar que exista alineamiento entre metas a distintos niveles que contribuya a la satisfacción de aquellas de más alto nivel.

3.2.3. GQ(I)M Goal Question (Indicator) Metric

Goal Question (Indicator) Metric (GQ(I)), [Goethert y Hayes, 2001] [Goethert y Siviy, 2004] es un enfoque de medición basado en GQM pero que, a diferencia de este, agrega un paso intermedio para asistir en el enlace entre las preguntas y los datos de medición que serán recolectados. En GQ(I)M se sostiene que, identificar preguntas y medidas sin visualizar un indicador, no resulta suficiente para asegurar un programa de medición exitoso. Los “displays” o reportes usados para comunicar los datos (llamados indicadores en este enfoque) son un enlace clave que pueden determinar el éxito o falla de un programa de medición. Estos indicadores sirven como la especificación de requisitos para los datos que deben ser recolectados, procesados y analizados.

Frecuentemente las organizaciones tienen dificultad para determinar si las metas de negocio han sido alcanzadas o cuándo lo han logrado. Si bien muchas de ellas implementan una estrategia y definen tareas para alcanzar las metas, aún no comprenden la diferencia entre indicadores, principalmente entre aquellos usados para determinar si las metas han sido logradas (indicadores de éxito) y aquellos usados para seguir la ejecución de las tareas (indicadores de progreso). La ejecución de tareas es una condición necesaria pero no suficiente para lograr las metas de negocio de una organización. Analizar las salidas de dichas tareas es parte del proceso de toma de decisión que permite determinar si las metas han sido alcanzadas exitosamente. GQ(I)M por lo tanto se basa en la definición de los siguientes tipos de indicadores (ver Figura 3.8).

– Indicadores de éxito: Se construyen a partir de los criterios de éxito definidos y se usan para determinar si las metas han sido alcanzadas.

– Indicadores de progreso: Se usan para seguir el progreso o la ejecución de las tareas definidas. Un gráfico de Gantt es un ejemplo de este tipo de indicador. La exitosa ejecución de todas las tareas definidas no necesariamente garantiza que la meta ha sido alcanzada con éxito.

– Indicadores de análisis: Estos indicadores son usados para analizar las salidas de cada tarea. Los análisis ayudan a probar los supuestos respecto a los datos que se usan para juzgar progreso y éxito.

Figura 3.8 Clasificación de indicadores en GQ(I)M. Adaptada de: [Goethert y Siviy, 2004].

Estos indicadores que define GQ(I)M se diferencian del concepto de indicador, descripto en la Sección 2.3.5, como parte del componente de evaluación de C-INCAMI. Los indicadores, según [Olsina et al., 2008b], sirven para interpretar los datos medidos y calculados de atributos y características. La base conceptual y proceso de las estrategias integradas adoptan la idea de medir atributos por medio de métricas adecuadas y evaluar los resultados, a partir de indicadores que interpreten los valores medidos en niveles de satisfacción esperados. Los indicadores elementales interpretan el nivel de satisfacción alcanzado por los valores medidos de los atributos. En tanto que los indicadores derivados calculan los valores finales para las características y sub-características evaluadas. Por esto, un indicador es un método utilizado en la tarea de evaluación. Por su parte, los distintos tipos de indicadores que distingue GQ(I)M son indicadores (“displays”) de progreso o éxito, más que de evaluación de resultados de medición.

GQ(I)M describe y documenta los tipos de indicadores por medio de una plantilla (ver Figura 3.9). Disponer de una especificación clara de indicadores le permite a una organización contar con un método consistente y preciso para llevar a cabo la tarea de obtener resultados. Las organizaciones adaptan dicha plantilla, ajustándola a su entorno, pudiendo agregar más campos a la misma o utilizar solo algunos de ellos.

Figura 3.9 Plantilla de indicadores en GQ(I)M. Extraída de: [Goethert y Siviy, 2004].

La plantilla de los indicadores provee un modo comprensible de documentar quien, qué, donde, cuándo, porqué y cómo de un indicador para asegurar consistencia en la construcción e interpretación. Además de la plantilla de especificación de indicadores, GQ(I)M utiliza la misma base conceptual que GQM, la cual está estructurada en forma de glosario. Respecto al proceso que define, también comparte actividades con GQM, pero agrega otras. En [Goethert y Hayes, 2001] y [Goethert y Siviy, 2004] se proponen las siguientes tres actividades para el mismo:

Identificar las metas.

Identificar los indicadores y los datos necesarios de medición.

Evaluar la infraestructura y planificar la acción para guiar la implementación.

El enfoque GQ(I)M está destinado a ayudar a las organizaciones en determinar medidas y sus respectivos indicadores. Es un enfoque igual a GQM, por lo tanto, está dirigido a satisfacer metas de medición a nivel operativo, de proyecto, con el agregado que permite contemplar la utilización de indicadores para evaluar los resultados de la medición. De acuerdo a esto, no contempla la vinculación de estas metas con aquellas de niveles organizacionales más altos. No obstante, en la subsección 3.2.4 se presenta una propuesta para combinarlo con BSC con el objetivo de vincular metas estratégicas de las distintas dimensiones con metas de medición que se evalúan con GQ(I)M.

3.2.4. BSC-GQ(I)M

En [Goethert y Fisher, 2003] se propone un enfoque que combina BSC con GQ(I)M con la intención de permitir mapear metas estratégicas a perspectivas de BSC e identificar indicadores y medidas para cada una de las perspectivas.

El proceso que especifica este enfoque combinado es iterativo y contiene cuatro pasos:

Definir claramente la misión y la visión. La misión describe el propósito de la organización en términos de qué hace y porqué lo hace. En tanto que la visión describe aquello que la organización quiere aspirar, es decir, la motivación por detrás para hacer lo que se hace, reflejando los valores de la organización.

Derivar metas estratégicas y sub-metas usando GQ(I)M. Las metas estratégicas pueden ser refinadas utilizando GQ(I)M para derivar otras metas de niveles inferiores. Las sub-metas son análogas a los requerimientos funcionales que una organización especifica e implementa, satisfaciendo así, no solo las sub-metas sino también las metas estratégicas. Las sub-metas se articulan con un componente cuantitativo y si es posible, uno de tiempo. Se deben priorizar y desarrollar una estrategia para alcanzarlas.

Mapear las sub-metas a las dimensiones de BSC. Cada sub-meta se mapea en alguna de las perspectivas del cuadro de mando de BSC. En este mapeo, se hacen preguntas sobre cada cuadrante para saber como ubicar las sub-metas, pudiendo ocurrir que existan cuadrantes que tengan las mismas sub-metas asignadas.

Aplicar GQ(I)M para:

a) Especificar criterios de éxito para cada sub-meta. Estos criterios o indicadores de éxito indican como definir el éxito, como se sabe cuando se alcanzó, y cuáles son sus

b) Derivar medidas e Hacer preguntas y postular indicadores que se ajusten con cada criterio de éxito de cada sub-meta de los cuadrantes. Para cada sub-meta, desarrollar las preguntas que servirán para determinar si el criterio de éxito se logró. Se deben elaborar de tal manera que lleven a una respuesta cuantitativa. Luego de identificarse la pregunta se puede diseñar un indicador para cada una. Más tarde puede ser posible combinar los indicadores.

c) Identificar las medidas que permitieron establecer los Además, documentar los resultados, a través del uso de las plantillas de indicadores que permiten especificar y documentar ítems tales como porqué, qué, quien, dónde, cuándo y cómo para cada indicador.

La idea de este enfoque combinado es que la organización pueda sistemáticamente establecer metas para cada perspectivas de BSC y desarrollar un conjunto de medidas e indicadores para determinar y seguir la calidad de los resultados y la performance de la organización. Al igual que BSC y GQ(I)M, no se provee de una conceptualización del dominio de metas multinivel, ni tampoco es explícita la descripción del tipo de estrategia para satisfacer las metas ni la consideración de las vistas de calidad que se desean evaluar.

3.2.5. Guía de Medición Orientada a Metas

En [Park et al., 1996] se presenta una guía que permite definir metas de medición que den soporte a metas de negocio de una organización. Para esto, la guía define un proceso basado en tres preceptos y que consiste en diez pasos. Los preceptos son:

– Las metas de medición se derivan de metas de negocio.

– El contexto y el foco los proveen modelos mentales.

– Utilización de GQ(I)M para derivar medidas e indicadores.

Respecto a los pasos del proceso, la guía establece los siguientes (ver Figura 3.10):

Identificar las metas de negocio.

Identificar qué se quiere conocer o aprender.

Identificar las sub-metas.

Identificar las entidades y atributos relacionados a las sub-metas.

Formalizar las metas de medición.

Identificar preguntas cuantificables e indicadores relacionados que se usarán para alcanzar las metas de medición.

Identificar los datos que se recolectarán para construir los indicadores que ayuden a responder las preguntas.

Definir las medidas que se utilizarán y hacer dichas definiciones operativas.

Identificar las acciones que implican implementar las medidas.

Preparar el plan para implementar las medidas.

Figura 3.10 Proceso de derivación de metas. Extraído de: [Goethert y Fisher, 2003].

El proceso de derivación de metas inicia indicando que la organización debe plantear las metas de negocio en algún nivel organizacional (paso 1). A partir de esas metas surgirán interrogantes relacionados a qué se quiere saber. Por ejemplo, preguntas del estilo “¿Qué se quiere alcanzar o mejorar?, Para hacer esto, se necesita hacer...”. Estos interrogantes o preguntas permiten identificar posibles entidades de interés involucradas a través de una lista de entidades-preguntas (paso 2). Con esta lista, se agrupan de acuerdo a temáticas principales que pueden identificarse. Este agrupamiento puede inicialmente ser arbitrario, dado que está basado en la percepción y visión sobre los temas que tenga el equipo a cargo. La agrupación de temas y preguntas origina una lista de sub-metas (paso 3) para las cuales se deben identificar las entidades y los atributos pertinentes asociados a cada una de ellas. Los atributos son las propiedades que, si se cuantifican, ayudan a responder las preguntas o establecen un contexto para interpretar los resultados (paso 4).

Hasta aquí el proceso está centrado en la identificación de metas de negocio y en aspectos (o “cosas” tal como se refieren los autores) que afectan el alcance de esas metas. En lo que resta, las actividades del proceso están orientadas a manejar las sub-metas, para obtener información cuantitativa. Para esto, se utiliza GQM para formalizar las metas de medición (paso 5), esto es, especificar el objeto de interés de la meta de medición (la entidad), el propósito, la perspectiva y una descripción del ambiente y las restricciones. Con las preguntas e indicadores definidos que serán usados para alcanzar las metas de medición (paso 6), se identifican las medidas ⁸ y se define la manera en que los datos serán recolectados (paso 7). Con las medidas identificadas, se deben definirlas, para saber cómo los datos serán recolectados, esto es la definición operacional (paso 8). Posteriormente, se arma el plan de medición (paso 9) estableciendo actividades de análisis, diagnóstico y la acción para trasladar los resultados de los análisis y diagnósticos en pasos implementables. Finalmente, el plan de medición se prepara (paso 10), mediante una plantilla que contiene ítems tales como objetivo, descripción, implementación operativa; y se ejecuta conforme dicho plan.

Lo destacable de este proceso es la posibilidad de mantener trazabilidad de las sub-metas hacia las metas de negocio que las originaron. Esto permite que las decisiones operativas que se tomen sean consistentes con las metas de negocio. En definitiva, este alineamiento permite comprender que las sub-metas de medición no están aisladas y que su concreción conlleva el cumplimiento de metas de otros niveles, en especial, las metas de negocio a nivel organizacional.

Por lo descripto, esta guía constituye un enfoque multinivel de valiosa referencia, puesto que detalla el proceso de medición a través de la descomposición de metas de negocio en metas operativas. Como base conceptual utiliza los términos que define GQM, pero carece de un glosario específico que incluya términos como meta de negocio, nivel organizacional, necesidad de información, estrategia, entre otros términos relacionados al dominio de metas multinivel. El proceso que define permite especificar un plan de medición que contemple metas operativas derivadas de metas de otros niveles organizacionales. Además, provee plantillas que permiten formalizar las metas e instanciar el proceso. Sin embargo, no se explicitan cuales serían las estrategias destinadas a satisfacer las metas de negocio y sus sub-metas derivadas, aunque para las metas operativas de medición se establezca el uso de GQM.

3.2.6. PSM-Practical Software and Systems Measurement

Practical Software and Systems Measurement (PSM) [McGarry et al., 2001] constituye una guía para definir e implementar un proceso de medición que puede ser ajustado a necesidades de información específicas. Dichas necesidades de información son a nivel de proyecto y el manejo de ellas muestra cómo la medición puede ser usada para satisfacer las necesidades de cada proyecto. Surgido en el año 1994 dentro del ámbito militar de los Estados Unidos, PSM fue la base para el desarrollo del estándar ISO/IEC 15939 y, con la aparición de dicho estándar, fue actualizado para proveer más detalles sobre las actividades y tareas presentes en el estándar. Actualmente, la guía que PSM especifica, implementa dicho estándar y, además, da soporte al área de Medición y Análisis de CMMI.

PSM especifica un modelo de información de la medición el cual vincula necesidades de información con los procesos de ingeniería de software y aquellos productos que pueden ser medidos. Modela los términos y relaciones del dominio de medición, proveyendo así un marco conceptual para la definición consistente de terminología de medición, que permite una comunicación efectiva entre los analistas, usuarios y otros agentes involucrados en el proceso de medición.

Por otro lado, PSM especifica un modelo de proceso de la medición. Dicho modelo define un proceso de medición con actividades y tareas que, en conjunto con el modelo de información de la medición, conforman un marco para la creación y desarrollo de proyectos de medición. El modelo está basado en el ciclo de gestión para la mejora continua, PDCA, pero adaptado para soportar actividades y tareas específicas de medición. Las actividades que define (ver Figura 3.11) son las siguientes: 1) Planificar la medición (Plan measurement ), 2) Ejecutar la medición (Perform measurement ), 3) Evaluar la medición (Evaluate measurement ), 4) Establecer y mantener el compromiso de la medición (Establish and sustain commitment ).

Figura 3.11 Modelo de proceso de medición de PSM. Extraído de: [McGarry et al., 2001].

La actividad de “Planificar la medición” implica determinar la necesidad de información del proyecto y la selección de las métricas apropiadas. Esta actividad también incluye tareas relacionadas con la definición de la recolección de datos, análisis y la generación de reportes. La salida de esta actividad es un enfoque de medición bien definido con soporte a la necesidad de información del proyecto. La actividad de “Planificar la medición” junto con la de “Ejecutar la medición”, conforman las actividades núcleos que tienen relación directa con los requerimientos de medición del usuario. La actividad “Ejecutar la medición” implica recolectar y procesar los datos de medición; implementar el plan de medición y generar informes con recomendaciones, necesarios para una efectiva toma de decisión.

Por su parte, la actividad de “Evaluar la medición” aplica técnicas de medición y análisis al proceso de medición en sí. Evalúa tanto las métricas aplicadas como la capacidad del proceso de medición y ayuda a identificar acciones de mejora. Esta actividad asegura que el proyecto de medición se actualice continuamente para reflejar la necesidad de información actual y promueve un incremento de la madurez del proyecto y de los procesos de medición de la organización. La última actividad, “Establecer y mantener el compromiso de la medición”, asegura que la medición es soportada tanto a nivel de proyecto como a nivel organizacional. Provee los recursos y la infraestructura organizacional requerida para implementar un programa de medición viable.

Por último, existe una quinta actividad que, aunque técnicamente no es específica de medición, tiene relación directa con el proceso de medición. Se trata de la actividad Procesos Técnicos y de Gestión. Los gerentes del proyecto operan con estos procesos, definen necesidades de información y usan los productos de información de la medición para tomar decisiones.

De acuerdo a lo comentado, PSM puede ser considerado más que un enfoque, una estrategia integrada. El modelo de información de medición permite contar con terminología de medición concisa y consistente para una efectiva comunicación entre analistas y líderes de proyectos de medición. Pero este modelo no provee una estructuración formal de su base conceptual, como por ejemplo, una ontología. Respecto al proceso, el modelo de proceso de medición es un proceso iterativo, diseñado para ser ajustado a las características y contexto de cada proyecto en particular. Es importante destacar que dicho modelo, no incluye actividades del proceso de evaluación, necesarias para obtener información útil para la toma de decisiones, a partir de una interpretación fehaciente de los datos medidos. Tampoco se describe un proceso de cambio orientado a mejorar la entidad medida y su contexto, a partir del análisis obtenido en la interpretación de la medición realizada.

Por otra parte, es preciso resaltar que PSM no soporta el alineamiento de objetivos a diferentes niveles organizacionales. El foco de interés es a nivel de proyecto, donde se establecen los requerimientos del usuario a partir de la necesidad de información. El catálogo de términos de medición que provee, no distingue distintos tipos de metas (en especial, alguna distinción entre metas principales y metas de soporte) y tampoco queda explícito el foco de evaluación, para determinar la vista de calidad desde la cual se está midiendo y evaluando.

PSM ha sido combinado con GQM y BSC de manera de crear un enfoque de medición más amplio. En [Bianchi, 2001] se presenta dicho enfoque combinado, con el objetivo de cubrir la brecha entre la visión de negocio, las metas estratégicas de la organización y los aspectos técnicos, relacionados con metas operativas. Para esto, se utiliza BSC como un marco general para enfocar en la visión de negocio organizacional desde las cuatro perspectivas. GQM, por su parte es útil para definir las metas operativas y las estrategias acorde que serán medidas en cada perspectiva de BSC. Y, PSM, se utiliza para proveer un conjunto de medidas ya definidas que pueden servir para los objetivos definidos con GQM, así como también brindar herramientas y métodos para definir nuevas medidas y soportar la incorporación de un programa de gestión de indicadores. Si bien este enfoque combinado permite reunir las principales características de cada enfoque, aún resulta una propuesta que no soporta el alineamiento de metas operativas con metas de negocio a nivel estratégico.

En [Card, 2003] también se discute la aplicación de PSM para satisfacer las necesidades de información a nivel de la gerencia, utilizando las dimensiones de BSC. Como resultado de la combinación, Card prueba que ambos enfoques son compatibles y complementarios, pero sin hacer mención a la vinculación que existe entre las metas que se formulan.

Figura 3.12 Combinación BSC-GQM-PSM. Adaptada de: [Bianchi, 2001].

3.2.7. Estrategias integradas GOCAME, SIQinU y GOCAMEC

En el Capítulo 2 se describieron tres estrategias integradas, GOCAME, SIQinU y GOCAMEC las cuales poseen una base conceptual ontológica relacionada a medición y evaluación, un proceso con actividades específicas para satisfacer los propósitos de las metas que las estrategias ayudan a alcanzar y métodos y herramientas para llevar a cabo las actividades del proceso propuesto. Estas estrategias están destinadas a satisfacer metas de necesidad de información de medición y evaluación a nivel operativo, para las cuales, no está explícito cuales fueron las metas de negocio que originaron dichas metas. En el Capítulo 4 se retoma este análisis, detallando el problema detectado y la solución propuesta en este trabajo.

3.3. Patrones de Estrategia de Medición y Evaluación

En Ingeniería de Software y Web, una definición bien conocida para patrones de diseño es la descripta por Gamma et.al, pero originalmente, pronunciada por Christopher Alexander, la cual afirma lo siguiente: “cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta solución un mil lón de veces, sin hacer dos veces lo mismo.” [Alexander et al., 1977, p.x] [Gamma et al., 1995, p.3]. La idea de patrones fue tomada de Alexander quien fue el primero en introducir patrones en el dominio urbanístico, pero el concepto principal fue luego aplicado al dominio de software y web. En sí, Alexander planteaba proveer una solución reusable e instanciable a un problema recurrente en situaciones similares. Y esta misma idea fue aplicada por Gamma et.al para proponer patrones de diseño que den solución en términos de objetos e interfaces a problemas de software dentro de un contexto.

En el área de medición y evaluación de la calidad del software, la utilización de patrones no está muy difundida. En [Lindvall et al., 2005] se definen patrones de medición para establecer objetivos, sub-objetivos y métricas para una meta organizacional, utilizando el enfoque GQM. La intención de estos patrones es proveer soluciones reusables a problemas similares encontrados en la creación de programas de medición. Adicionalmente, los autores sostienen que la idea de los patrones de medición fue tomada de [Gamma et al., 1995], pero la especificación de los patrones que ilustran no sigue ningún estilo recomendado tal como nombre, intención, problema, solución/estructura, usos conocidos, entre otros ítems.

Por otro lado, muchos trabajos que tratan sobre patrones están frecuentemente destinados para etapas tempranas de desarrollo y cambio, enfocándose por ejemplo, en patrones de usabilidad y de diseño de interfaces de usuario, o diseños arquitecturales. Pero rara vez están destinados para etapas de evaluación y mejora en las cuales pueden considerarse la apropiada utilización de vistas de calidad y patrones de estrategia para instanciar estrategias integradas de medición y evaluación. Por ejemplo, en [Folmer et al., 2003] y [Folmer y Bosch, 2010], los autores definen un marco que expresa relaciones entre la arquitectura del software y usabilidad. La propuesta consiste en un conjunto de soluciones de diseño que han sido identificadas a partir de varios casos prácticos en la industria.

Finalmente, [Houdek y Kempter, 1997] proponen patrones de calidad considerando la estrategia GQM. Los autores estructuran en forma de patrones las experiencias almacenadas en lo que llaman Factoría de Experiencias [Basili, 1989] y forma parte del Paradigma de Mejora de la Calidad (Quality Improvement Paradigm (QIP)) [Basili, 1985]. Estos patrones facilitan la selección y reuso de las experiencias almacenadas en la Factoría, aspecto de relevancia en el aprendizaje de experiencias pasadas en un ambiente de mejora continua. Los patrones se especifican utilizando una plantilla similar a la utilizada en [Gamma et al., 1995]. Aunque QIP contempla el diseño de patrones para la especificación de experiencias y hacerlas reusable; no es una propuesta semejante a la presentada en esta tesis dado que no representa una estrategia integrada de medición, evaluación y/o cambio. Es decir, QIP es un enfoque de mejora continua, que no está dirigido por objetivos de evaluación y cambio de manera integrada.

De acuerdo a la observación elaborada tras el desarrollo de la presente investigación, los citados trabajos sobre patrones en el área de medición y evaluación de la calidad carecen de una clara separación de conceptos entre vistas de calidad, modelos de calidad y estrategias integradas de medición y evaluación. Y aún más, no permiten instanciar estrategias integradas de medición y evaluación.

3.4. Conclusiones

En este capítulo se abordó el estado del arte respecto a los tres tópicos de interés del presente trabajo: vistas de calidad, enfoques y estrategias integradas y multinivel orientados a metas de medición, evaluación y mejora de la calidad y, patrones de estrategia.

Respecto a vistas de calidad, tanto la definición de ellas así como también de sus relaciones de “influencia” y “depende de” han sido de algún modo empíricamente observadas en [Garvin, 1984], [Neil et al., 2003], [Moraga et al., 2008], [CMMI Product Team, 2010], [Lew et al., 2012] y definidas en los estándares ISO 9126 e ISO 25010. Sin embargo, no se encontraron trabajos donde se explicite el significado de vista de calidad, así como también el de sus relaciones de causa-efecto. Los estándares ISO definen vistas en el contexto del ciclo de vida de calidad de un sistema donde especifica aquellas vistas que pueden ser evaluadas por medio de los modelos de calidad que proponen.

A pesar que dichas vistas comprenden implícitamente un foco de calidad (como por ejemplo el foco de calidad externa o de calidad interna) y una categoría de entidad (como por ejemplo producto o sistema); no establecen como importante en la definición de una vista de calidad, la asociación entre estos dos conceptos. Tampoco se detectaron otros trabajos que propongan una definición de vistas contemplando estos aspectos. Por lo tanto, se concluye que aún falta una definición formal de vistas de calidad y sus relaciones, como así también determinar cómo se conforma una vista de calidad. Este aspecto es de especial importancia puesto que de esto dependerá la estrategia a utilizar para satisfacer la meta de medición.

En cuanto a enfoques y estrategias integradas y multinivel, muchos trabajos dan evidencia de la necesidad de alinear metas de medición con metas de negocio, para soportar cuantitativamente, las decisiones gerenciales de una organización. Existen algunos enfoques que dan cuenta del alineamiento entre los tres principales niveles de una organización: el estratégico, el táctico y el operativo. En este capítulo se analizó la literatura relacionada a enfoques y estrategias que contemplen el alineamiento estratégico de metas. A partir de dicho análisis se determinó que GQM⁺ Strategies y la guía de medición basada en metas presentada en [Park et al., 1996] constituyen la estrategia y el enfoque respectivamente, que satisfacen ampliamente la característica del alineamiento de metas. Consideramos a GQM⁺ Strategies como una estrategia integrada con soporte multinivel. En [Olsina et al., 2011b] y en [Papa, 2012] se presenta un estudio comparativo de estrategias integradas de medición y evaluación el cual concluye que GQM⁺ Strategies satisface en buena medida las tres capacidades deseables de una estrategia integrada, aunque su aspecto más débil es la calidad de las capacidades del marco conceptual de dominio. Por otra parte, el aspecto a resaltar de GQM⁺ Strategies es que contempla el alineamiento de metas organizacionales a distintos niveles, proveyendo de un mecanismo para la derivación de metas y su posterior análisis e interpretación. Sin embargo, la selección de la estrategia (o táctica en este caso) está descripta de manera genérica, se establece que es de acuerdo a la meta organizacional que se intenta satisfacer, considerando el contexto, las suposiciones, entre otros aspectos, pero no se detalla cuáles estrategias pueden determinarse. Tampoco está explícita la consideración de las vistas de calidad, aunque determinan el objeto y el foco como parte de la especificación de la meta.

Respecto a la guía de medición presentada en [Park et al., 1996] describe un proceso que permite definir metas de medición que ayudan a comprender aspectos de metas de negocio de la organización. Esta guía constituye una referencia valiosa por la descripción que realiza de la descomposición de metas principales en sub-metas relacionadas para procesos de medición y evaluación. Sin embargo, no contiene una definición formal de los términos meta de negocio, necesidad de información y estrategia (entre otros relacionados al dominio de metas multinivel). Además, tampoco se hace mención a la estrategia específica a emplear y la vista de calidad que corresponde evaluar.

En cuanto a BSC-GQ(I)M y la combinación entre ellos, se observa que no soportan la vinculación de metas a distintos niveles organizacionales, simplemente mencionan distintas perspectivas desde las cuales una organización establece metas, y luego definen la manera de evaluar dichas metas, pero sin considerar la relación de estas con otras metas de otros niveles organizacionales.

Por su parte, PSM ofrece una guía detallada sobre el proceso de medición (pero no de evaluación), incluyendo un catálogo de medidas específicas y de información sobre cómo una organización puede aplicar dichas medidas en proyectos. Además, establece un proceso para la selección de medidas de acuerdo a los objetivos del proyecto. PSM es también una estrategia integrada pero que no da soporte a metas multinivel puesto que se limita a la consideración de metas a nivel de proyecto.

Si bien entonces, algunos de los enfoques o estrategias analizados consideran el alineamiento de metas multinivel, ninguno de ellos describe una base conceptual de metas multinivel de manera de permitir que los enfoques de medición y evaluación cuenten con una definición formal de los mismos al momento de utilizarlos cuando se proyectan metas de negocio y se derivan metas de medición a partir de ellas.

Por último, la literatura revisada respecto a patrones de estrategia indica que no hay soluciones aplicables de patrones para instanciar estrategias de medición y evaluación. Existen propuestas como la de [Lindvall et al., 2005] para utilizar patrones en la creación de programas de medición, siguiendo el enfoque GQM, y otros trabajos como [Folmer et al., 2003] y [Folmer y Bosch, 2010] que consisten en un conjunto de soluciones integradas para aplicar en arquitectura de software y usabilidad. Pero, de acuerdo al análisis efectuado, no existen propuestas que consideren empaquetar el conocimiento obtenido en la utilización de estrategias integradas de medición y evaluación de modo de obtener soluciones reusables e instanciables para utilizar en distintos proyectos de medición, evaluación y/o cambio.

Capítulo 4 - Resumen de la Problemática Detectada y la Solución Propuesta

A partir del análisis del estado del arte del Capítulo 3 que permitió encontrar ciertas limitaciones y oportunidades de mejora en trabajos relacionados a vistas de calidad, enfoques multinivel y estrategias integradas; y patrones de estrategia, este capítulo se centra en delimitar el problema y proponer soluciones para estos tres aspectos.

La organización del capítulo es la siguiente:

– Sección 4.1: Realiza una síntesis de la problemática detectada.

– Sección 4.2: Expone la solución propuesta, que será desarrollada en la Parte III de este trabajo.

4.1. Problemática Detectada

En el Capítulo 2 se introdujeron los fundamentos de estrategias integradas de medición y evaluación, describiendo los principios o características que son deseables que las mismas posean. En especial, se abordaron tres estrategias integradas que sirven para satisfacer metas de necesidades de información de medición y evaluación con propósitos tales como comprender o mejorar. El desarrollo de estas estrategias, principalmente, el avance producido en cada uno de sus pilares (esencialmente en lo concerniente al proceso, métodos y marco conceptual), han sido los trabajos de investigación que, hasta la fecha, el grupo de investigación GIDIS_Web ha producido y, cuyos resultados, han sido plasmados en tesis de posgrados y trabajos de divulgación científica de alcance nacional e internacional ([Olsina y Rossi, 2002], [Olsina y Martin, 2004], [Olsina et al., 2008b], [Molina, 2012], [Papa, 2012], [Lew et al., 2012], [Olsina et al., 2012], [Becker et al., 2015] entre otros). Sin embargo, se han detectado oportunidades de mejora para las estrategias integradas. La Figura 4.1 ilustra los fundamentos de estrategias integradas de medición y evaluación, resaltando cuales son los aspectos débiles detectados, los que a continuación se analizan.

Figura 4.1 Limitaciones (señaladas en recuadro punteado) detectadas para las estrategias integradas de medición y evaluación.

En primer lugar, la declaración de una meta de necesidad de información de medición y evaluación, no solo comprende un propósito, sino que también, tras ella puede identificarse la vista de calidad que se desea evaluar. Tener en consideración la vista de calidad es importante, tal cual lo analizamos en el estado del arte. Por ejemplo, los estándares internacionales ISO 9126 e ISO 25010 hacen mención al respecto indicando las relaciones existentes entre distintas perspectivas de calidad y cómo afectan unas a otras. Tiempo antes de estas menciones, Garvin había establecido la manera de caracterizar el alcance y significado de la calidad, de acuerdo a la perspectiva respecto de la cual se requería evaluar. Además, y considerando que categorías de entidades relevantes en el área de medición de software son proceso, producto y recurso [Fenton y Pfleeger, 1998], la vista de calidad tiene que estar descripta en consideración de ellas.

Esto es, no solo es preciso determinar el foco de evaluación, sino también interesa el objeto a medir, la entidad, más precisamente, la categoría a la que pertenece. La asociación del foco de calidad y la categoría de entidad determinará la vista de calidad. Y, por lo tanto, determinar la vista de calidad involucrada en la meta de necesidad de información de medición y evaluación permite escoger la estrategia integrada adecuada para llevar a cabo la meta del proyecto, puesto que el proceso que una estrategia prescribe variará de acuerdo a dicha perspectiva desde la cual se realiza la evaluación de la entidad. Al presente, las estrategias integradas de medición y evaluación no se escogen de acuerdo a la vista de calidad que la meta de necesidad de información de medición y evaluación involucra. Tampoco en el análisis del estado del arte respecto a vistas de calidad se detectaron estrategias que sí contemplen formalmente vistas de calidad, aunque la evidencia empírica que arrojan los trabajos indagados respecto a las relaciones entre vistas de calidad, constituye una importante contribución para el presente trabajo.

En segundo lugar, las estrategias integradas de medición y evaluación están diseñadas para llevar a cabo metas de necesidad de información de medición y evaluación a nivel de proyecto, es decir, satisfacen metas operativas que resultan útiles para obtener datos cuantitativos. Pero este tipo de meta en una organización que lleva adelante proyectos de medición y evaluación, no está aislada; sino más bien, tendrían que estar derivadas de objetivos organizacionales de negocio [Abran et al., 2011]. Principalmente, porque las actividades de medición no son un fin en sí mismo, sino un medio para alcanzar y monitorear el logro de otros objetivos [Ebert y Dumke, 2007]. Tal como se viene señalando a lo largo de este trabajo, la importancia de un proyecto de medición y evaluación se justifica en términos del valor del negocio. Aunque, desafortunadamente, a menudo es percibido como algo intrusivo y un costo innecesario respecto al “real trabajo” a realizar [Mayes, 2012]. Sin embargo, debiera existir un alineamiento de metas organizacionales, de manera tal de identificar objetivos cuantitativos de medición que soporten decisiones de negocio [Ebert y Dumke, 2007]. En vista a esto, es importante establecer la relación entre metas operativas con metas de otros niveles organizacionales, en especial, con metas de negocio a nivel estratégico.

El análisis realizado del estado del arte respecto a enfoques de evaluación de la calidad multinivel y estrategias integradas permite concluir que, si bien existen propuestas que contribuyen en este sentido, no todas vinculan directa y explícitamente las metas de medición y evaluación con las de negocio. Consecuentemente, la inversión realizada para recolectar datos de medición no resulta en los beneficios esperados y, la contribución del proyecto en alcanzar metas estratégicas permanece confusa [Basili et al., 2010]. Actualmente, esta relación tampoco se evidencia en las metas de necesidad de información de medición y evaluación que las estrategias integradas descriptas llevan a cabo, puesto que no está explícito de cuales otras metas se derivan ⁹ . Y aún más, cual es el valor agregado para las metas organizacionales de mayor nivel.

Por último, la experiencia obtenida en la última década en el desarrollo y uso de las estrategias integradas de medición y evaluación [Olsina et al., 2008b], [Lew et al., 2012], [Olsina et al., 2012], [Papa, 2012] ha permitido concluir que distintas estrategias pueden ser aplicadas a problemas recurrentes dentro de situaciones de medición, evaluación y cambio para metas de proyectos específicos. Se observa que una misma estrategia puede ser utilizada para resolver distintas metas que compartan características en común, principalmente, en cuanto al propósito que las mismas definen y la cantidad de vistas de calidad involucradas. Por lo tanto, encapsular el conocimiento sobre el empleo de estrategias integradas permitirá construir soluciones que sean reutilizables e instanciables, de acuerdo a la situación que se presente. Para esto, contar con patrones de estrategia podría ser de utilidad al momento de seleccionar una estrategia integrada, instanciándola de acuerdo al patrón que corresponda, permitiendo de este modo, aplicar a distintas situaciones de instanciación de estrategias.

De acuerdo a estas observaciones detectadas e ilustradas en la Figura 4.1, se concluye que las estrategias integradas de medición y evaluación: 1) no se instancian de acuerdo a la vista de calidad que comprende la meta de necesidad de información de medición y evaluación a satisfacer; 2) que dicha meta al presente no se relaciona con metas principales de negocio de la organización y, finalmente, 3) que la instanciación de las estrategias integradas podría beneficiarse a partir de la utilización de patrones de estrategia.

4.2. Solución Propuesta

El análisis del estado del arte permitió identificar dos aspectos importantes. Por un lado, no existen trabajos que relacionen vistas de calidad con términos de requisitos no funcionales y que sirvan para identificar la estrategia integrada de medición y evaluación de acuerdo a esto. Aun más, no existe una conceptualización formal, en forma de ontología, de los términos y relaciones involucrados en el dominio de vistas de calidad.

Por otro lado, se detectó que existen algunas propuestas respecto a relacionar metas de necesidades de información de medición y evaluación con metas de otros niveles organizacionales. Pero, al igual que para el dominio de vistas de calidad, pocas de ellas discuten una ontología de metas organizacionales que incluya términos como meta, necesidad de información, proyecto, entre otros. Y no se detectaron trabajos sobre el empleo de patrones para instanciar estrategias integradas de medición y evaluación.

En la sección anterior fueron expuestas las debilidades encontradas en las estrategias integradas de medición y evaluación. En vista a esto, en este trabajo se propone un enfoque integrado de medición, evaluación y mejora de calidad con soporte a metas de negocio y de necesidad de información. El enfoque se denomina Enfoque Multinivel y Multipropósito de Evaluación de la Calidad el cual, para abreviar, se renombra como Enfoque de Evaluación de Calidad. Dicho enfoque comprende las siguientes características principales:

La especificación de vistas de calidad que serán referenciadas por las metas de necesidad de información de medición y evaluación.

La definición de metas de negocio y de necesidad de información a distintos niveles organizacionales y la formulación de proyectos de medición, evaluación y/o cambio para operacionalizar específicamente las metas de necesidad de información de medición y evaluación.

La adopción de patrones de estrategia para la instanciación de estrategias específicas que ayuden a alcanzar los propósitos de las metas.

La Figura 4.2 ilustra cada uno de estos tres aspectos. Para el primer aspecto mencionado, se muestra gráficamente cómo, a partir de la categoría de entidad y el foco de calidad que describe la meta necesidad de información de medición y evaluación, se determina la vista de calidad. Esta contribución se presenta en el Capítulo 5.

Respecto a la segunda característica del enfoque mencionada, la Figura 4.2 describe que, en cada nivel organizacional, se establecen metas de negocio que están soportadas por metas de necesidad de información, las cuales se encuentran alineadas unas con otras. En especial, hay un tipo de meta de necesidad de información que es la meta de necesidad de información de medición y evaluación, la cual se vincula con metas de negocio a nivel operativo. Esta contribución se presenta en el Capítulo 6.

Finalmente, las metas de necesidades de información de medición y evaluación se llevan a cabo (o se realizan) por medio de estrategias integradas (como se ha expuesto en capítulos previos). No obstante, las mismas pueden ser instanciadas a partir de patrones de estrategia. En este sentido, la cantidad de vistas de calidad identificada en la declaración de estas metas, en conjunto con el tipo de propósito de evaluación de las mismas (como por ejemplo comprender, mejorar o monitorear) permite determinar cuál es el patrón de estrategia acorde a seleccionar, de una familia de patrones, e instanciar a partir de éste, la estrategia integrada correspondiente. Esta es la tercera característica del enfoque y se presenta en el Capítulo 7.

Figura 4.2 Esquema de la solución propuesta.

Los tres principios del Enfoque de Evaluación de Calidad se sostienen en una arquitectura constituida por bases conceptuales estructuradas como ontologías; a saber, la ontología de vistas de calidad y la ontología de metas organizacionales y proyecto. La ontología de vistas de calidad modeliza vistas de calidad y sus relaciones de “influencia” y “depende de”. Formalizar estos conceptos y relaciones es de importancia en la definición y selección de patrones de estrategia de evaluación y, en definitiva, para la instanciación de estrategias específicas para ser usadas en proyectos de medición, evaluación y/o cambio. En cuanto a la ontología de metas organizacionales y proyecto, la misma pretende contribuir a las bases conceptuales que conforman el marco de medición y evaluación C-INCAMI previamente desarrollado (según revisamos en la Sección 2.3). De esta manera, se enlazarán conceptos de meta de negocio y necesidad de información con conceptos de proyecto, estrategia, requisitos no funcionales y vistas de calidad.

Parte III:
Desarrollo de la Solución Propuesta

Capítulo 5 - Vistas de Calidad en el Enfoque de Evaluación de Calidad

En este capítulo se presenta el desarrollo de la primera contribución de la tesis, a saber, la definición de vistas de calidad en el Enfoque de Evaluación de Calidad, a través del desarrollo de una ontología que define los principales términos y relaciones que intervienen en la definición de una vista de calidad. Los trabajos de investigación que dan el sustento teórico a este capítulo son: [Olsina et al., 2011a], [Rivera et al., 2015d] y [Rivera et al., 2016a].

La organización del capítulo es la siguiente:

– Sección 5.1: Presenta la base conceptual, estructurada como una ontología, de vistas de calidad.

– Sección 5.2: Relaciona los términos de vistas de calidad con los términos de requisitos no funcionales de C-INCAMI.

– Sección 5.3: Expone las conclusiones del capítulo.

5.1. Ontología de Vistas de Calidad

Cualquier proyecto de medición y evaluación operacionaliza una meta de necesidad de información de medición y evaluación a satisfacer, la cual debiera estar alineada con metas de negocio a distintos niveles organizacionales, tal como se ha introducido en los capítulos previos. Hay proyectos de medición y evaluación que están enfocados en mejorar la calidad de un proceso, en tanto que otros en mejorar la calidad de un producto, o en mejorar la calidad de un sistema. Por lo tanto, se observa que, a menudo, los proyectos comparten las mismas metas/objetivos de medición y evaluación (en este caso, metas con el mismo propósito de mejorar ) que involucran a distintas vistas de calidad, en donde, cada vista relaciona una categoría de entidad (como por ejemplo, proceso, producto, sistema) con su respectivo foco de calidad (calidad de proceso, calidad interna y calidad externa respectivamente).

Para alcanzar sus metas de necesidad de información de medición y evaluación, diferentes proyectos aunque con características similares, pueden utilizar la misma estrategia integrada, la cual debiera escogerse de acuerdo a la cantidad de vistas de calidad y el tipo de propósito que la meta defina. En un enfoque de evaluación de calidad, modelizar vistas de calidad y sus relaciones es importante puesto que ayuda a seleccionar estrategias a partir de un conjunto de estrategias, como se explicará a lo largo de este capítulo.

El marco conceptual C-INCAMI descripto en la Sección 2.3 del Capítulo 2 se compone, entre otros, del componente de requisitos no funcionales. El mismo contiene los términos y sus relaciones, necesarios para la definición de requisitos no funcionales estructurados en forma de características, sub-características y atributos a ser evaluados. Los atributos son las propiedades medibles de la entidad objeto de evaluación, la cual, según la Figura 2.2, pertenece a una categoría de entidad. En Ingeniería de Software, se distinguen como categorías de entidad de interés a proceso, producto y recurso [Fenton y Pfleeger, 1998], [Wohlin et al., 2012]. No obstante, otras podrían ser consideradas, tales como sistema y sistema en uso. Distinguir entre producto, sistema y, sistema en uso, permite categorizar una entidad de software a evaluar, respecto a sus propiedades estáticas e internas, a propiedades relacionadas a la ejecución del software (el sistema), o bien a propiedades que se distinguen cuando la entidad está siendo usada en un contexto específico de uso, respectivamente. Cada una de estas categorías de entidad, que en esta tesis se denominan súper-categoría de entidad, por ser la categoría de entidad de mayor nivel de abstracción, serán evaluadas para un foco de calidad determinado, siendo el foco el concepto de más alto nivel de abstracción -la raíz- de un modelo de calidad. Bajo estas consideraciones, se define una vista de calidad (Quality View) como la asociación entre una súper-categoría de entidad (Entity Super Category) y un concepto foco de calidad (Quality Focus) a evaluar. Esta relación de asociación se especifica en la Figura 5.1. De acuerdo a esto, una entidad concreta, como por ejemplo, la aplicación Facebook v127 para Android, pertenece a una categoría de entidad denominada aplicación móvil de red social, que pertenece a la súper-categoría de entidad sistema. Por otra parte, el foco de calidad para sistema, es calidad externa. Así, la asociación entre este foco de calidad y la súper-categoría de entidad se llama vista de calidad de sistema.

Figura 5.1 Base conceptual de vistas de calidad.

Entre las vistas de calidad pueden existir relaciones de dependencia (depends on) e influencia (influences), tal como se muestra en la Figura 5.1, adoptando cada vista, un rol específico de acuerdo a la relación que se trate. Por ejemplo, si se considera la vista de calidad de recurso y la de proceso, la primera resulta ser la vista independiente (independent view) y la segunda la vista dependiente (dependent view), dado que la vista de calidad de proceso depende de la vista de calidad de recurso. La Figura 5.2 ilustra instancias de vistas de calidad y las relaciones entre ellas que pueden intervenir en evaluación para una línea de producción de software. Se observa que la vista de calidad de recurso –que relaciona la súper-categoría de entidad recurso (en donde un recurso puede ser un agente, método, herramienta, entre otros) con el foco calidad de recurso- influencia a la vista de calidad de proceso. A su vez, la vista de calidad de proceso influencia a la vista de calidad de producto software –siendo el código fuente un ejemplo de una entidad para la súper-categoría producto software-, y ésta a su vez, influencia a la calidad de sistema. Además, la vista de calidad de sistema influencia a la vista de calidad de sistema en uso – siendo ejemplo de entidad para sistema en uso, una aplicación móvil que es ejecutada por usuarios reales en contextos específicos de uso. En sentido inverso se interpreta a la relación depende de, es decir, la vista de calidad de sistema en uso depende de la vista de calidad de sistema, y así sucesivamente. Estas relaciones están basadas en la evidencia empírica que propone la ISO 9126 y, posteriormente la ISO 25010, respecto a cómo afectan unas vistas de calidad a otras, tal lo discutido en la Sección 3.1 del Capítulo 3. En este trabajo se contribuye al respecto, modelizando el dominio de vistas de calidad, definiendo sus términos y relaciones, tal como expone, la Tabla 5.1 y la Tabla 5.2 respectivamente.

Figura 5.2 Una instanciación de vistas de calidad para una línea de producción en Ingeniería de Software.

Tabla 5.1 Definición de los términos del componente de Vistas de Calidad.

Término
Definición

Categoría de Entidad (Entity Category) (de la ontología de métricas e indicadores)
Categoría de objeto a ser caracterizada al medir sus atributos.

Concepto Calculable (Calculable Concept )(de la ontología de métricas e indicadores)
Relación abstracta entre atributos de una categoría de entidad y necesidades de información.
Nota 1: un concepto calculable, usualmente denominado característica, representa una combinación de atributos mesurables. Por lo tanto una característica puede ser evaluada pero no puede ser medida como un atributo.
Nota 2: una característica puede tener sub-características.

Foco de Calidad (Quality Focus)
Es el concepto calculable foco para calidad. Es la característica raíz de un modelo de calidad.

Súper-categoría de Entidad (Entity Super-Category)
Relación de alto nivel de abstracción entre un concepto calculable foco y una súper-categoría de entidad.
Nota: instancias de vistas de calidad son: vista de calidad de producto, vista de calidad de sistema, vista de calidad de recurso, entre otras.

Vista de Calidad (Quality View)
Relación de alto nivel de abstracción entre un concepto calculable foco y una súper-categoría de entidad.
Nota: instancias de vistas de calidad son: vista de calidad de producto, vista de calidad de sistema, vista de calidad de recurso, entre otras.

Tabla 5.2 Definición de las relaciones del componente de Vistas de Calidad.

Relación | Definición
depende de (depends on) | Una vista de calidad depende de otra vista de calidad.
influencia (influences) | Una vista de calidad influencia a otra vista de calidad.
pertenece (pertains) | Una categoría de entidad puede ser clasificada en una super categoría de entidad.

Comparado con la caracterización de las vistas de calidad realizada por Garvin y las normas ISO 9126 y 25010, se puede establecer algunas similitudes. Por ejemplo, la vista de calidad de sistema propuesta en la base conceptual de vistas de calidad, es comparable a la vista de sistema que establece la ISO 25010 y, puede considerarse similar a la vista de usuario y la vista de manufactura de Garvin (aunque Garvin realiza la caracterización para industrias, pero no esencialmente para la de software). La vista de usuario de Garvin podría ser comparada también con la vista de calidad de sistema en uso, según la interpretación que se le dé a la definición dada por Garvin. También, la vista de manufactura de Garvin tiene alguna correspondencia con la vista de calidad de proceso de nuestra propuesta, puesto que Garvin la define como respaldada por las conformidades a un determinado proceso. Por su parte, la vista basada en el producto es comparable con la vista del producto software mencionada por los estándares ISO y considerada en la base conceptual de vistas de calidad. La vista basada en el valor no está presente en las ISO 9126 y 25010. No obstante, es posible modelarla considerando vistas de calidad o vista de costo.

5.2. Relación entre Vistas de Calidad y Requisitos No Funcionales

El nuevo componente de vistas de calidad se incorpora como parte del componente de requisitos no funcionales de C-INCAMI, relacionándose con algunos de sus términos, tal como ilustra la Figura 5.3.

Figura 5.3 Componente de requisitos no funcionales de C-INCAMI en conjunto con el componente de vistas de calidad.

Particularmente, una súper-categoría de entidad (Entity Super-Category) del sub-componente de vistas de calidad, es una categoría de entidad (Entity Category), del componente de requisitos funcionales. Por otra parte, un foco de calidad (Quality Focus) es un concepto calculable (Calculable Concept ) el cual está representado por uno o más modelos de conceptos de calidad (Quality Concept Model ) (también del componente de requisitos no funcionales).

La razón de incluir el concepto de vista de calidad en requisitos no funcionales se justifica puesto que una vista de calidad se deriva, como se ha descripto, de la relación de un foco de calidad y su súper-categoría de entidad relacionada. Además, sabiendo que como parte de la especificación de los requisitos no funcionales de evaluación se especifica la necesidad de información de medición y evaluación (Information Need ), la misma, en la declaración de su propósito contiene una o más vistas de calidad relacionadas. Por lo tanto, en esta instancia es lógico que se consideren las vistas de calidad, dado que es lo que permitirá determinar la estrategia integrada a utilizar para llevar a cabo la meta de necesidad de información. Determinar la estrategia integrada adecuada es importante puesto que cada una provee un curso de acción específico para resolver un problema u objetivo de evaluación, enfocado en una o más vistas de calidad.

De acuerdo a esto, para las estrategias integradas presentadas en la Sección 2.2 del Capítulo 2, se mencionó que cada una estaba destinada a satisfacer un propósito de medición específico. Así, GOCAME se utiliza para metas de necesidad de medición y evaluación con el propósito de comprender, GOCAMEC, para propósitos de mejorar, en tanto que SIQinU, para propósitos de mejorar calidad en uso haciendo cambios en calidad externa.

A estas afirmaciones, ahora se agrega que tanto GOCAME como GOCAMEC, sirven para evaluar una vista de calidad (la vista de calidad de proceso, la vista de calidad de recurso o la vista de calidad de producto, o la vista de calidad de sistema). Es decir, el propósito de las metas que llevan a cabo comprenden únicamente una súper-categoría de entidad con su foco relacionado, determinando así, una vista de calidad. Por ejemplo, para la meta comprender la usabilidad de LinkedIn para dispositivos móviles, se identifica como tipo de propósito comprender, como súper-categoría de entidad sistema, (por tratarse de la entidad LinkedIn para dispositivos móviles) y como foco de calidad, calidad externa (por ser usabilidad, la característica a evaluar). Por lo tanto, en el propósito de esta meta se determina solo una vista, la vista de calidad de sistema. Por tratarse de una meta con el propósito de comprender y que atañe una vista de calidad, GOCAME es la estrategia integrada que otorga el proceso y métodos afines para llevarla a cabo. Con una meta similar, pero con el propósito de mejorar, la estrategia integrada a emplear sería GOCAMEC, pudiendo (o no) variar el tipo de vista de calidad, no así la cantidad. Por otra parte, las metas que satisface SIQinU relacionan dos vistas de calidad, a saber, la vista de calidad de sistema en uso con la vista de calidad de sistema. La súper-categoría de entidad se corresponde con sistema en uso y sistema para los focos de calidad en uso y calidad externa respectivamente. SIQinU provee un proceso con actividades destinadas solamente a satisfacer metas de este tipo. Otras estrategias que involucren dos vistas de calidad con propósitos de comprensión y mejora podrían diseñarse. Por lo tanto, la clara especificación de las vistas de calidad ayuda a seleccionar la estrategia adecuada. En el Capítulo 7 se retoma esta idea, como utilidad en la utilización de patrones de estrategia.

5.3. Conclusiones

El componente de vistas de calidad presentado forma parte de la arquitectura del Enfoque de Evaluación de Calidad propuesto en esta tesis. Contar con un marco de modelado de calidad que contemple vistas y relaciones entre ellas permite, por una lado, tener explícitamente definido los términos y relaciones que intervienen en el dominio de vistas de calidad y, robustecer así, el marco conceptual C-INCAMI. Por otro lado, en conjunto con el tipo de propósito de la meta de necesidad de información de medición y evaluación, contribuyen a la selección de la estrategia integrada a utilizar en proyectos concretos de medición, evaluación y aquellos que incluyen también actividades de cambio. Por otro lado, poder seleccionar la estrategia adecuada permite considerar múltiples escenarios de evaluación, para los cuales cada estrategia aportará el proceso específico y los métodos necesarios para llevar a cabo la meta de necesidad de información de medición establecida en el proyecto.

Capítulo 6 - Metas de Negocio y de Necesidad de Información en el Enfoque de Evaluación de Calidad

En este capítulo se presenta el desarrollo de la segunda contribución de la tesis, esto es, la definición de metas de negocio y de necesidad de información a distintos niveles organizacionales en el Enfoque de Evaluación de Calidad y la formulación de proyectos de medición, evaluación y/o cambio para operacionalizar específicamente las metas de necesidad de información de medición y evaluación. Para este fin, se presenta una ontología de metas de negocio y proyecto, en la cual queda explícita la definición de metas de negocio y de necesidad de información multinivel, además de proyectos, estrategias y patrones de estrategia vinculados.

Los trabajos de investigación desarrollados que dan el sustento teórico a este capítulo son: [Rivera et al., 2016b], [Rivera et al., 2016c], [Rivera et al., 2016d] y [Becker et al., 2016].

La organización del capítulo es la siguiente:

– Sección 5.1: Introduce la importancia de contar con metas de negocio que estén asistidas por metas de necesidad de información y la vinculación entre ellas a distintos niveles organizacionales.

– Sección 5.2: Presenta la base conceptual estructurada como ontología, de metas de negocio y de proyecto.

– Sección 5.3: Expone las conclusiones.

6.1. Metas de Negocio y Metas de Soporte

En cualquier organización, los proyectos de medición y evaluación operacionalizan metas de necesidad de información que dan soporte a metas principales o de negocio, las cuales pueden estar formuladas a distintos niveles organizacionales, como operativo, táctico y estratégico. Para alcanzar una meta de negocio y evaluar su logro, a menudo es necesario contar con cierta información. En este sentido, una organización también debe establecer metas de necesidad de información que den el soporte necesario para permitir conocer en qué medida se está alcanzando una meta de negocio. Una meta de necesidad de información siempre está relacionada con una meta de negocio y está basada en distintos tipos de análisis de datos cualitativos y cuantitativos que se pueden realizar. Un tipo particular de meta de necesidad de información es la meta de necesidad de información de medición y evaluación, la cual permite obtener datos e información que dan soporte a metas de negocio a nivel operativo, contribuyendo a una eficaz toma de decisiones en niveles superiores.

Por otra parte, las diferentes metas establecidas se operacionalizan mediante proyectos. A su vez, en un proyecto se debería considerar, como recursos durante la planificación del mismo, estrategias que ayuden a alcanzar las metas. Por ejemplo, algunas estrategias que ayudan a alcanzar metas de necesidad de información de medición y evaluación, y que han sido analizadas en la discusión del estado del arte, son, GQM, GQM⁺ Strategies, PSM, GOCAME, GOCAMEC y SIQinU. Además, existen estrategias (comúnmente llamadas metodologías) de desarrollo como por ejemplo, la del Proceso Unificado o las metodologías ágiles.

En resumen, es de importancia que un enfoque integral de evaluación de calidad permita establecer y alinear metas a diferentes niveles organizacionales, en especial, vincular las metas de medición a nivel operativo con metas de negocio a nivel estratégico, evaluando su alcance por medio de metas de soporte. Además de definir proyectos y estrategias en pos de alcanzar tales metas.

6.2. Ontología de Metas de Negocio y de Proyecto

En el Capítulo 2 se presentó el marco conceptual C-INCAMI para el dominio de medición y evaluación, el cual está formado por cinco componentes, a saber: Proyecto, Contexto, Requisitos No Funcionales, Medición y Evaluación. Los términos, atributos y relaciones de estos componentes surgen de la ontología de medición y evaluación documentada en [Olsina y Martin, 2004] y [Olsina et al., 2008b].

Si bien la ontología de medición y evaluación cuenta con los términos necesarios para especificar requisitos no funcionales (como entidad, atributo, necesidad de información de medición y evaluación, entre otros) no considera que una necesidad de información de medición y evaluación es una meta de necesidad de información que da soporte a metas de negocio, lo cual es importante para mostrar el alineamiento entre metas a diferentes niveles organizacionales. Por otra parte, el componente de Proyecto existente no considera términos como estrategia y tampoco se relaciona con el término meta.

Con el fin de robustecer el marco conceptual C-INCAMI y consolidar el Enfoque de Evaluación de Calidad propuesto, en esta sección se presentan los componentes de Metas de Negocio y de Proyecto (también estructurados en forma de ontologías), ilustrados en la Figura 6.1.

Figura 6.1 Conceptos principales del dominio de metas de negocio (paquete business goal ) y conceptos del dominio de proyecto (paquete project ).

Comparando la Figura 6.1 con la Figura 2.2 del marco conceptual C-INCAMI, los componentes nuevos añadidos permiten especificar metas a distintos niveles organizacionales, que se operacionalizan mediante proyectos y son alcanzadas por medio de estrategias integradas adecuadas. Las estrategias se instancian a partir de patrones de estrategia, como se describirá en el Capítulo 7, siendo importante la consideración de las vistas de calidad, como se especificó en el capítulo anterior. A seguir, se resaltan en itálica los términos (en inglés) de los componentes de Metas de Negocio y de Proyecto.

Una organización (Organization) es una entidad que comprende personas, que está estructurada y gestionada para establecer y perseguir metas y que es afectada y afecta, el contexto en el que se encuentra. La mayoría de las organizaciones tienen una estructura de gestión orientada en niveles que determina relaciones entre los diferentes miembros y las actividades, y subdivide y asigna roles, junto con la autoridad pertinente para ejecutar distintas tareas. En [Barcellos y Falbo, 2009] se establece que una organización es un agente social que emplea recursos humanos para llevar a cabo acciones para alcanzar las metas establecidas. Similar definición otorga CMMI, al establecer a una organización como una estructura administrativa en la que el personal gestiona de forma conjunta uno o más proyectos o grupos de trabajos [CMMI Product Team, 2010].

La organización establece (establishes) metas (Goal ) u objetivos. Algunos trabajos como [BMM Team, 2015] consideran que una meta suele ser más general y de largo plazo, en tanto que un objetivo suele ser más específico y de corto plazo. Si bien esta diferencia suele establecerse en la literatura al respecto, en este trabajo se consideran ambos términos como sinónimos.

Una meta es la declaración del objetivo a alcanzar por la organización, que considera el contenido proposicional de un propósito en un período de tiempo determinado. Esta definición fue adaptada de [Barcellos y Falbo, 2009] y [Barcellos et al., 2013] las cuales establecen que una meta es el contenido proposicional de una intención. Siendo una intención, el propósito por el cual las acciones son planeadas y ejecutadas en una organización.

Una meta contiene una declaración (statement ) explícita sobre el fin o propósito que se quiere alcanzar en un período de tiempo. El propósito (purpose) de una meta es el fundamento por el cual se quiere lograr la misma, en un período de tiempo. El período de tiempo (timeframe) es el tiempo establecido para concretar la meta y puede variar de corto, mediano a largo plazo. Las metas que establece una organización pueden clasificarse en metas de negocio (Business Goal ) y metas de necesidad de información (Information Need Goal ), las cuales dan soporte a las primeras. Esta distinción entre metas principales y metas de soporte sigue en cierto modo, la idea que subyace en CMMI, el cual propone áreas de procesos principales y de soporte. Un área de proceso es un grupo de prácticas relacionadas dentro de un área que, cuando se implementan conjuntamente, satisface un conjunto de metas consideradas importantes para mejorar ese área. Mientras que un área de proceso de soporte provee las funciones o prácticas de soporte fundamentales que se usan por todas las áreas de proceso [CMMI Product Team, 2010]. Por lo que esta adherencia conceptual hace que la distinción adoptada difiera levemente de, por ejemplo [Barcellos et al., 2010] o [Basili et al., 2007b] donde se establece que, en el contexto de medición del software, una meta puede ser de negocio, de software o de medición. En este trabajo, como se explica a seguir, una meta de medición es una meta de negocio a nivel operativo, una meta de software puede ser considerada una meta de negocio a nivel táctico y, existen también, las metas de negocio a nivel estratégico; las cuales debieran estar todas alineadas.

Una meta de negocio es una declaración cualitativa que expresa un estado o condición general, de largo plazo de la organización (por ejemplo, incrementar en un 10 % para el próximo año, la cantidad de usuarios de una aplicación X móvil ) [Barcellos et al., 2010]. CMMI la describe como “objetivos de negocio de la organización”, refiriéndose a aquellos desarrollados por la dirección con el fin de asegurar la existencia continua de la organización y aumentar su rentabilidad, la cuota de mercado, entre otros factores que inciden en el éxito de la organización [CMMI Product Team, 2010]. Por lo que entonces, las metas de negocio constituyen las metas principales que la organización se fija considerando la misión (mission) y la visión (vision).

De acuerdo a [BMM Team, 2015], la visión describe el estado futuro de la organización, sin considerar cómo se alcanzará el mismo. La visión es el estado final que la organización quiere alcanzar. Por ejemplo, para una organización dedicada al desarrollo de aplicaciones y/o servicios web para la búsqueda de empleo, la visión puede ser consolidarse como el motor de búsqueda de empleo favorito. Por su parte, la misión indica las actividades operativas en marcha de la organización. Describe de qué se trata el negocio o cómo lo será en el día a día. La misión hace a la visión operativa puesto que indica las actividades que hacen a la visión una realidad. La misión se planea por medio de políticas y estrategias. La declaración de la misión debiera estar compuesta de los tres ítems siguientes: 1) una acción (como por ejemplo “proveer”), 2) un producto o servicio (por ejemplo, “búsqueda de empleo”), 3) un cliente o un negocio (por ejemplo “los clientes de cualquier parte del mundo”). Un ejemplo de misión para la organización dedicada al desarrollo de aplicativos para búsqueda laboral, sería “proveer servicios de búsqueda de empleo a clientes (usuarios) de cualquier parte del mundo“.

Una meta de negocio puede estar formulada a (isFormulatedAt ) distintos niveles organizacionales (Organizational Level ). Un nivel organizacional representa un nivel administrativo y de toma de decisión donde, usualmente, las metas de negocio a nivel estratégico suelen ser de largo plazo, en tanto que aquellas especificadas a nivel operativo se caracterizan por ser de corto plazo.

De acuerdo a Schendel et al. [Schendel y Hofer, 1979], las metas organizacionales se categorizan en tres niveles distintivos, a saber, el estratégico, el táctico y el nivel operacional, categorías que se adoptaron en esta tesis. En cada nivel, las metas se definen con distinto grado de abstracción, heredando complejidades y sirviendo para distintos propósitos. Por ejemplo, las metas de nivel estratégico son definidas para dar soporte a la misión y visión organizacional y se establecen para y por los gestores de más alto rango de la organización. En este nivel, no hay una dirección clara respecto a cómo las metas serán realizadas. Por su parte, las metas de nivel táctico se vinculan a las metas estratégicas y se establecen por y para los gestores de nivel intermedio. Las metas en este nivel se enfocan en operacionalizar las metas estratégicas, además de indicar los niveles de logro necesarios. Finalmente, las metas operativas se determinan en el nivel más bajo de la organización y son establecidas para y por los gestores de más bajo nivel (los stakeholders). Brian et al. [Briand et al., 2002] indican que las metas corporativas, estratégicas (las cuales señalan que deben ser priorizadas de acuerdo a la naturaleza del negocio de la organización) en conjunto con el ambiente específico, conducen a la generación de metas tácticas, más acotadas y mejor enfocadas que las metas estratégicas, a cuyo logro contribuyen. Mientras que las metas tácticas y el conocimiento del ambiente, conducen a metas de medición (metas operativas). A su vez, toda meta de negocio establecida en algún nivel organizacional puede descomponerse en submetas (subGoal ).

Por su parte, una meta de necesidad de información es una meta de soporte que tiende a ser alcanzada en el corto plazo y puede requerir de metas más específicas que puedan ser medidas cuantitativamente en un plazo de tiempo específico. El estándar ISO 15939 define una necesidad de información como “la información necesaria para gestionar objetivos, metas, riesgos y problemas” [ISO/IEC, 2007, p.3].

Las metas de necesidad de información son metas de soporte a las metas principales o de negocio (isSupportedBy). Usualmente brindan información útil para analizar en qué medida se ha alcanzado una meta de negocio. Una meta de necesidad de información puede a su vez requerir (requires) de metas de necesidad de información de medición y evaluación (ME Information Need ). En [Barcellos et al., 2010] y [Barcellos et al., 2013] establecen también que una necesidad de información se identifica a partir de otras metas (aunque no aclaran que tipo de metas). Pero, sostienen que este tipo de metas se satisfacen por medio de medidas, las cuales pueden ser utilizadas para indicar el logro de las metas. En este caso, las medidas desempeñan, según los autores, el rol de indicador. Las diferencias entre la denominación de medida e indicador, adoptadas en la base conceptual C-INCAMI y otras propuestas relacionadas, fueron resaltadas en los Capítulos 2 y 3 (Sección 3.2.3 GQ(I)M) respectivamente.

Una necesidad de información de medición y evaluación es una meta de necesidad de información específica, cuantificable, que está dirigida por actividades de medición y evaluación. Una meta de este tipo es consistente con las características que establece el criterio SMART (Specific, Measurable, Asignable, Realistic, Time-Related ) [Doran, 1981] para la definición de metas u objetivos de corto plazo. El criterio dice que las metas de corto plazo deben ser definidas de tal manera de ser específicas, medibles, alcanzables, realistas o relevantes y de duración limitada. Una meta de necesidad de información de medición y evaluación da soporte a una meta de negocio de nivel operativo, la que a su vez, se relaciona con una meta de otro nivel organizacional. Para cuantificar metas de negocio, una meta de necesidad de información de medición y evaluación especifica un objeto (Entity Category) a ser evaluado, el cual pertenece a una súper-categoría de entidad (Entity Super-Category) y describe un foco de calidad (Quality Focus). En conjunto, categoría de entidad con un foco de calidad, forman la vista de calidad, analizada en el Capítulo 5. En la Figura 6.1 se observa la relación entre los componentes de Meta de Negocio y Requisitos No Funcionales, a partir de la relación entre una meta de necesidad de información de medición y evaluación y una meta de necesidad de información. De igual modo, la relación entre el componente de Requisitos No Funcionales y el sub-componente de Vista de Calidad, por medio de la relación de una categoría de entidad con su súper categoría asociada, y de la necesidad de información de medición y evaluación (MEInformationNeed ) con un foco de calidad (Quality Focus).

Una organización organiza el trabajo (arrangesWorkBy) mediante proyectos (Project ) que permiten operacionalizar (operationalizes) las metas establecidas. Proyecto es una categoría de entidad para gestionar el trabajo en cualquier organización. La Guía de los Fundamentos para la Dirección de Proyectos, conocida por sus siglas en inglés como PMBOK (Project Management Body Of Knowledge), define un proyecto como “un esfuerzo temporal que se l leva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos implica que un proyecto tiene un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto, cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto.” [PMI, 2013, p.3]. El estándar CMMI por su parte establece en su glosario, la definición de proyecto como un “conjunto gestionado de actividades y recursos interrelacionados, incluyendo personal, que entrega uno o más productos o servicios a un cliente o a un usuario final. Un proyecto tiene un comienzo previsto (es decir, el arranque del proyecto) y un final. Los proyectos operan normalmente de acuerdo a un plan. Dicho plan frecuentemente está documentado y especifica qué es lo que se va a entregar o implementar, los recursos y la financiación que van a utilizarse, el trabajo que se va a realizar y el calendario para hacer el trabajo. Un proyecto puede estar compuesto de varios proyectos.” [CMMI Product Team, 2010, p.599]. Alineadas con estas definiciones, en este trabajo se considera la siguiente definición de proyecto: “una entidad que representa un comportamiento temporal y orientado a metas, con una fecha de inicio y fin determinados, que considera un conjunto de actividades, tareas y recursos interrelacionados dirigidos a producir y modificar productos de trabajo únicos (artefactos, servicios o resultados) para satisfacer una necesidad dada."[Becker et al., 2015, p.1].

Los proyectos pueden ser de diversos tipos, de acuerdo a la naturaleza de la meta que operacionalizan. Por ejemplo un proyecto de desarrollo (Development Project ) es aquel que operacionaliza una meta de negocio que tiene como propósito construir un nuevo producto software o sistema. Particularmente, en este trabajo interesan los proyectos de medición y evaluación (ME Project ), que operacionalizan metas de necesidad de información de medición y evaluación, y los proyectos de medición, evaluación y cambio (MEC Project ) que operacionalizan metas de necesidad de información de medición, evaluación con el propósito de mejora. En este último tipo de proyecto los cambios son dirigidos por medición y evaluación, por lo tanto, se compone de sub-proyectos de medición y evaluación y de cambio (Change Project ). Un proyecto de cambio operacionaliza una meta de negocio con el propósito de cambiar o modificar el estado actual de una entidad. Los cambios pueden ser adaptativos, perfectivos, correctivos o evolutivos.

La gestión de proyecto (Project Management ) se define como “la aplicación del conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir los requisitos del mismo.” [Duncan, 1996, p.6] [PMI, 2013, p.47]. Sumando a esta definición, en la base conceptual de proyecto, se establece la gestión de proyecto como el conjunto de procesos destinados a alcanzar una meta operacionalizada por el proyecto.

La gestión de proyecto produce (produces) un plan (Project Management Plan), el cual el estándar ISO 10006 lo define como el documento que especifica qué es necesario para alcanzar el/los objetivo/s del proyecto [ISO/IEC, 2003]. CMMI, coincide afirmando que, un plan de proyecto proporciona la base para realizar y controlar las actividades del proyecto (estimar los atributos de los productos de trabajo y de las tareas, determinar los recursos necesarios, negociar los compromisos, elaborar un calendario, e identificar y analizar los riesgos del proyecto) [CMMI Product Team, 2010]. En resumen, constituye el documento que describe cómo el proyecto será ejecutado, monitoreado y controlado [PMI, 2013].

Un proyecto adopta (adopts) un ciclo de vida (Project Life Cycle) que indica las fases por las que atraviesa, desde su inicio hasta su fin. El ciclo de vida proporciona el marco de referencia básico para dirigir el proyecto, independientemente del trabajo específico involucrado [PMI, 2013]. El ciclo de vida involucra al menos recursos (Resource) y definiciones de trabajo (Work Definition), e instancia (instantiates) estrategias (Strategies). En el Capítulo 2 se introdujo la definición de estrategia considerada en esta tesis, que establece a la misma como “principios, patrones, conceptos de un dominio en particular y marcos conceptuales que pueden ser especificados mediante un conjunto de procesos concretos, además de un conjunto apropiado de métodos y herramientas, como recursos principales que ayudan a alcanzar el propósito de una meta de proyecto” [Rivera et al., 2016b, p.7]. La estrategia es un recurso que ayuda a alcanzar (helpsToAchieve) una meta. Esta investigación está basada en estrategias integradas que ayudan a alcanzar metas de necesidades de información de medición y evaluación. Adicionalmente, se propone que cualquier estrategia que se utilice en los ciclos de vida del proyecto, puede estar instanciada (instantiates) a partir de patrones de estrategia (Strategy Patterns). Particularmente, las estrategias integradas de medición y evaluación pueden ser instanciadas de esta manera. Un patrón de estrategia está formado por una estructura (Structure) que contiene las tres capacidades integradas abordadas en el Capítulo 2, a saber: una base conceptual de dominio (Domain Conceptual Base), una especificación del proceso (Process Specification) y una especificación de métodos (Method Specification).

En las Tablas 6.1, 6.2 y 6.3 se encuentran las definiciones de los términos, las relaciones y los atributos de los componentes de Metas de Negocio y de Proyecto. Si bien en la Figura 6.1 dichos términos, relaciones y atributos se encuentran en inglés, en las tablas que a continuación se muestran, fueron traducidos al español para una mejor comprensión por parte del lector.

Tabla 6.1 Definición de los términos de los componentes de Metas de Negocio y Proyecto.

Término
Definición

Base Conceptual de Dominio (Domain Conceptual Base)
Es una base terminológica en la cual, para un dominio dado, los principales términos o conceptos están explícitamente definidos. Nota: Una base conceptual puede ser estructurada por ejemplo, en un glosario, taxonomía u ontología, entre otras.

Ciclo de Vida de Proyecto (Project LifeCycle)
La serie de fases que atraviesa un proyecto desde su inicio hasta el final [PMI, 2013]. Nota: Ejemplos de fases en un proyecto son planificación, programación, monitoreo, entre otras.

Definición de Trabajo (Work Definition) (de la ontología de Procesos)
Entidad abstracta que describe el trabajo por medio de productos de trabajo consumidos y producidos, condiciones y roles involucrados. Nota: Trabajo representa un proceso, una actividad o tarea [Becker et al., 2015].

Especificación de Método (Method Specification)
Es la representación de un método. Nota 1: Método es la manera específica y particular de ejecutar los pasos específicos en la descripción de una definición de trabajo (Work Definition). Nota 2: La manera específica y particular de un método -esto es, cómo los pasos descriptos en una definición de trabajo debería realizarse- está representado por un procedimiento y reglas [Becker et al., 2015].

Especificación de Proceso (Process Specification)
Es un modelo que relaciona un conjunto de elementos de procesos tales como actividades, tareas, entradas y salidas, pre y post condiciones, artefactos, roles, entre otros. Nota 1: Una especificación de proceso puede considerar distintas perspectivas de proceso tales como funcional, de comportamiento, informacional y organizacional [Curtis et al., 1992]. Nota 2: Usualmente, una especificación de proceso establece qué hacer más que cómo hacer las descripciones de las actividades.

Estrategia (Strategy)
Principios, patrones y conceptos y marco de un dominio particular que pueden ser especificados por un conjunto de procesos principales, en adición a un conjunto de métodos apropiados y herramientas, como recursos, para ayudar a alcanzar el propósito de la meta de proyecto.

Estructura (Strategy Pattern Structure)
Solución genérica e instanciable que ofrece un patrón de estrategia. Nota: La estructura de un patrón de estrategia se compone de tres capacidades, a saber: (i) una base conceptual de dominio (Domain Conceptual Base); (ii) especificaciones de proceso (Process Specifications) que comprende perspectivas de proceso; y, (iii) especificaciones de métodos (Method )

Gestión de Proyecto (Project Management )
Es el conjunto de procesos y actividades gerenciales destinadas a alcanzar la meta operacionalizada por un proyecto. Nota: La aplicación de conocimiento, habilidades, tareas, y técnicas a las actividades del proyecto para alcanzar los requerimientos del proyecto, según establece [PMI, 2013].

Meta (sinónimo Objetivo) (Goal )
Es la declaración del objetivo a alcanzar por una organización que considera el contenido proposicional de un propósito en un determinado período de tiempo. Nota: En alguna literatura, como por ejemplo en [BMM Team, 2015], una meta comparada con un objetivo tiende a ser general más que específica, un término de largo plazo más que uno de corto plazo.

Meta de Negocio (Business Goal )
Es la meta principal que una organización intenta alcanzar.

Meta de Necesidad de Información (Information Need Goal )
Es una meta destinada a obtener información de una meta de negocio dada. Nota: Necesidad de Información, según ISO 15939 [ISO/IEC, 2007] se define como “el conocimiento necesario para gestionar objetivos, metas, riesgos y problemas”.

Meta de Negocio (Business Goal )
Es la meta principal o primaria que una organización intenta alcanzar.

Necesidad de Información de Medición y Evaluación (ME Information Need )
Es una meta de necesidad de información (Information Need Goal ) conducida por actividades de medición y evaluación.

Nivel Organizacional (Organizational Level )
Representa un nivel de gestión y toma de decisión en el cual se formulan las metas de negocio de una organización y las metas de necesidad de información son tenidas en cuenta. Nota: Usualmente, las metas de negocio de largo plazo se formulan a nivel organizacional estratégico, mientras que las metas de negocio de corto plazo se formulan a nivel organizacional operativo.

Organización (Organization)
Es una entidad que comprende personas, estructurada y administrada para establecer y perseguir metas organizacionales y es afectada por y afecta a su ambiente o contexto. Nota: La mayoría de las organizaciones tienen una estructura de gestión orientada a niveles que determina relaciones entre los distintos miembros y las actividades y subdivide y asigna roles y autoridad para ejecutar distintas tareas.

Patrón de Estrategia (Strategy Pattern)
Es un activo de conocimiento que incluye una solución reusable y customizable para un problema de proyecto recurrente en situaciones similares. Nota: Un patrón de estrategia de medición, evaluación y cambio es una solución reusable y customizable que trata con proyectos de medición, evaluación y cambio.

Plan de Gestión del Proyecto (Project Management Plan)
El documento que describe como el proyecto será ejecutado, monitoreado y controlado [PMI, 2013].

Proyecto (Project )
Es una entidad que representa un comportamiento temporal y orientado a metas con una fecha de inicio y fin establecidas, y que considera un conjunto de actividades interrelacionadas, tareas y recursos destinados a producir y modificar productos de trabajo (artefactos, servicios o resultados) para satisfacer una necesidad dada.

Proyecto de Cambio (Change Project )
Es un proyecto que operacionaliza una meta de negocio con el propósito de cambiar el estado actual de una entidad. Nota: Distintos tipos de cambios (por ejemplo, adaptativo, perfectivo, correctivo) pueden ser implementados en proyectos de mantenimiento. Además, los cambios pueden realizarse en proyectos de desarrollo.

Proyecto de Desarrollo (Development Project )
Es un proyecto que operacionaliza una meta de negocio con el propósito de construir un nuevo producto o sistema.

Proyecto de Medición y Evaluación (ME Project )
Es un proyecto que operacionaliza una meta de negocio con el propósito de comprender, monitorear, el estado actual de una entidad, además de seleccionar alternativas entre entidades.

Proyecto de Medición, Evaluación y Cambio (MEC Project )
Es un proyecto que operacionaliza una meta de negocio con el propósito de mejorar una entidad. Nota: un Proyecto MEC comprende tanto un proyecto de cambio, como uno de medición y evaluación, donde los cambios en la entidad son conducidos por medición y evaluación.

Recurso (Resource)
Activo asignado a una definición de trabajo. Nota: Un activo es una entidad (como por ejemplo agente, persona, estrategia, método, herramienta, entre otras) con valor agregado para una organización [Becker et al., 2015].

Tabla 6.2 Definiciones de las relaciones para los componentes de Metas de Negocio y Proyecto.

Relación | Definición
adopta (adopts) | Un proceso de gestión del proyecto (Project Managemen) adopta un ciclo de vida de proyecto (Project Life Cycle).
arreglaTrabajoCon (arrangesWorkBy) | Una organización (Organization) organiza su trabajo (arrangesWorkBy) u esfuerzo por medio de proyectos (Project) para el logro de las metas (Goals) establecidas.
ayudaAlcanzar (helpsToAchieve) | Una estrategia (Strategy) brinda soporte para alcanzar una o más metas (Goal ) organizacionales.
esAdministradoA (isManagedAt ) | Una organización (Organization) es administrada a distintos niveles organizacionales (Organizational Level) tal como niveles estratégico, táctico y operativo.
esAdministradoPor (isManagedBy) | Un proyecto (Project ) es administrado por medio de procesos de gestión de proyectos (Project Management ).
esFormuladaA (isFormulatedAt ) | Una meta de negocio (Business Goal ) se formula en una nivel organizacional (Organizational Level ).
esSoportadoPor (isSupportedBy) | Una meta de negocio (Business Goal ) es soportada por ninguna o varias metas de necesidad de información (Information Need Goal ).
establece (establishes) | Una organización (Organization) establece y persigue metas (Goal) como parte de su misión (Mission) y alineado con su visión (Vision).
instancia (instantiates) | Una estrategia (Strategy) puede instanciar un patrón de estrategia (Strategy Pattern).
involucra (involves) | La realización de un ciclo de vida de un proyecto (Project Life Cycle) involucra recursos (Resources) y definiciones de trabajo (Work Definitions) entre otros aspectos.
operacionaliza (operationalizes) | Un proyecto (Project ) operacionaliza metas (Goal ).
produce (produces) | Un proceso de gestión de proyecto (Project Managemen) produce un plan de gestión de proyecto (Project Management Plan) como artefacto.
requiere (requieres) | Una meta de necesidad de información (Information Need Goal ) puede requerir una o varias metas de necesidad de información de medición y evaluación (ME Information Need Goal ).
subMeta (subGoal ) | Una meta de negocio (Business Goal) puede ser dividida en submetas las cuales son a su vez metas de negocio en un nivel de granularidad menor.
usa(uses) | Un ciclo de vida del proyecto (Project Life Cycle) usa una o más estrategias (Strategy).

Tabla 6.3 Definiciones de los atributos para los términos de los componentes de Metas de Negocio y Proyecto.

Término-Atributo
Definición

Ciclo de Vida de Proyecto (Project Life Cycle) - fases (phases)
Un conjunto de fases de un ciclo de vida de proyecto es un grupo de de procesos fuertemente relacionados y actividades definidas en un orden dado. Nota 1: Una fase termina con un hito, tal como terminar un entregable, como un plan de proyecto. Nota 2: Un ciclo de vida de proyecto tiene muchas fases como planificación, programación, monitoreo, entre otros.

Estrategia (Strategy) - nombre (name)
Etiqueta o nombre de la estrategia a ser identificada.

Meta (Goal ) - declaración (statement )
Una declaración explícita del objetivo a ser alcanzado. Nota: una declaración es usualmente una afirmación escrita en alto nivel o lenguaje natural.

Meta (Goal ) - período (timeframe)
Un período de tiempo en el cual la meta es perseguida o se espera que sea alcanzada. Nota: Un período de tiempo de una meta puede variar de corto, mediano plazo a largo.

Meta (Goal )- propósito (purpose)
La razón fundamental para alcanzar una meta específica. Nota: Ejemplos de propósitos de evaluación son: comprender, mejorar, monitorear y controlar, comparar y seleccionar, predecir, entre otros.

Nivel organizativo (Organization Level ) - nivel (level )
Representa un nivel específico en el cual las metas de negocio de una organización se formulas y las metas de necesidad de información son tenidas en cuenta. Nota 1: Comúnmente la literatura identifica tres niveles, tales como estratégico, táctico y operativo [Schendel y Hofer, 1979]. De acuerdo a [Basili et al., 2010], distintas metas existen a diferentes niveles de una organización, como el nivel administrativo, el nivel departamental, el nivel de proyecto. Estos niveles concuerdan en gran medida con los mencionados niveles organizacionales. Nota 2: Usualmente, las metas de negocio de plazo largo se formulan a nivel estratégico,mientras que aquellas de corto o mediano plazo se formulan a nivel operativo o táctico.

Organización (Organization) - misión (mission)
Establece el propósito principal de la organización y el foco. Nota: La declaración de la misión normalmente permanece sin cambios en el tiempo.

Organización (Organization) - visión (vision)
Describe qué quiere la organización aspirar y cual es la motivación específica que se une a la de los stakeholders de la organización. Nota: La visión refleja la realización de los valores de la organización.

Patrón de Estrategia (Strategy Pattern) - nombre (name)
Un nombre descriptivo y único. Nota: La etiqueta o nombre usualmente se expresa en inglés.

Patrón de Estrategia (Strategy Pattern) - alias (alias)
Acrónimo u otro nombre diferente para el patrón de estrategia.

Patrón de Estrategia (Strategy Pattern) - intención (intention)
Principal objetivo para el patrón de estrategia.

Patrón de Estrategia (Strategy Pattern)- motivación (motivation)
Problema/meta del proyecto a resolver por el patrón de estrategia.

Proyecto (Project )- nombre (name)
La etiqueta o nombre de un proyecto a ser identificado.

Proyecto (Project ) - fechaInicio (startDate)
Fecha o instante de tiempo cuando el proyecto comienza.

Proyecto (Project ) - fechaFin (endDate)
Fecha o instante de tiempo cuando el proyecto termina.

6.3. Conclusiones

Como se señala en [Basili et al., 2010], los datos cuantitativos son un prerrequisito para comprender la relación entre las metas de negocio y, verificar su alcance. Por esta razón, las necesidades de información de medición no deberían ser un fin en sí mismo, sino una razón fundamental para alcanzar metas de negocio en una organización. Siempre debería haber una respuesta al interrogante de “¿porqué estamos midiendo esto?”. Y, mantener esta trazabilidad entre metas a distintos niveles ayuda a responderla [CMMI Product Team, 2010].

Contar con un enfoque de calidad que contemple estas características de alineamiento beneficia a las organizaciones en el establecimiento de metas de negocio a distintos niveles organizacionales y la posterior verificación de su alcance, de un modo sistemático y disciplinado.

En este capítulo se describieron las bases conceptuales de Metas de Negocio y de Proyecto del Enfoque de Evaluación de Calidad que permiten tener definido los términos, relaciones y atributos mínimos y necesarios para enlazar conceptos del dominio de metas de negocio y de necesidad de información con conceptos de proyecto, estrategia y requisitos no funcionales. Se describió que un proyecto operacionaliza una meta de negocio en algún nivel organizacional y que las mismas, tienen metas de soporte denominadas metas de necesidad de información. Un caso particular de meta de soporte es la meta de necesidad de información de medición y evaluación, la cual puede requerir seleccionar, durante el ciclo de vida del proyecto, una estrategia integrada adecuada para llevarla a cabo. Instanciar dicha estrategia permite determinar el curso de acción específico necesario a realizar a fin de alcanzar la meta establecida. Para determinar cuál es la estrategia a seleccionar se tiene en cuenta el tipo de propósito de la meta de necesidad de información de medición y evaluación y la cantidad de vistas que subyacen en la declaración de la meta. Además, que dicha instanciación está soportada por patrones de estrategia, tal como se fundamentará en el capítulo siguiente.

Es preciso destacar que debido al alcance establecido, la cantidad de términos de los componentes de metas de negocio y de proyecto representan un conjunto mínimo para modelar y relacionar estos dominios. El lector podrá concluir que, por ejemplo, para el término Project Management podrían haber más términos específicos relacionados, los cuales no han sido representados en la base conceptual principalmente por el alcance y foco del objetivo de investigación.

Capítulo 7 - Patrones de Estrategia

En este capítulo se presenta el desarrollo de la tercera contribución de la tesis, a saber, un conjunto de patrones de estrategia que permiten la instanciación de distintas estrategias integradas para resolver el propósito de metas de necesidad de información de medición y evaluación. Los siguientes trabajos de investigación: [Rivera et al., 2015a], [Rivera et al., 2015b], [Rivera et al., 2015c], [Papa et al., 2015], [Rivera et al., 2016a], [Rivera et al., 2016b] y [Papa et al., 2016] dan el sustento teórico y práctico necesario para el desarrollo de los temas presentados.

La organización del capítulo es la siguiente:

– Sección 7.1: Describe la importancia de la base conceptual de vistas de calidad para el diseño de patrones de estrategia.

– Sección 7.2: Especifica tres patrones de estrategia que consideran una y dos vistas de calidad.

– Sección 7.3: Discute otros patrones de estrategia.

– Sección 7.4: Presenta las conclusiones.

7.1. Vistas de Calidad y Patrones de Estrategia

La utilización de patrones surge como medio para encapsular conocimiento de problemas en contextos específicos y presentar una solución probada que permita resolverlos. En Ingeniería de Software, comenzaron a popularizarse con el libro de diseño de patrones orientado a objetos publicado por Gamma et al. [Gamma et al., 1995], adaptando la idea postulada por Alexander, quien propuso la utilización de patrones urbanísticos [Alexander et al., 1977]. Desde entonces, ha surgido una comunidad dedicada al desarrollo de patrones para distintos tipos de problemas. Entre aquellos más conocidos pueden mencionarse los patrones de diseño [Gamma et al., 1995], los patrones arquitecturales [Buschmann et al., 1996], los patrones de análisis [Kerth, 1995], los patrones de programación (por ejemplo, los detallados en [Coplien, 1998]) y los patrones navegacionales [Rossi et al., 1999].

En esta tesis, el concepto de patrón no utiliza soluciones basadas en diseño de software en términos de objetos y clases (como los patrones de diseño). Sino más bien, se propone encapsular el conocimiento adquirido sobre la utilización de estrategias integradas para llevar a cabo metas de necesidades de información de medición y evaluación.

Un patrón de estrategia puede ser visto entonces como una solución general y reusable para problemas recurrentes en el área de medición, evaluación y/o cambio. Los patrones de estrategia brindan una solución al momento de utilizar estrategias integradas, proveyendo un proceso con un conjunto de actividades que tienen que ser personalizadas y métodos para medición, evaluación y/o cambio para la realización de las actividades.

De acuerdo a lo analizado en los Capítulos 5 y 6, las metas de necesidad de información de medición y evaluación pueden comprender una o más vistas de calidad y distintos tipos de propósitos de evaluación. Considerando estos dos aspectos, se ha enfatizado que la estrategia integrada para llevar a cabo dicha meta debe ser la adecuada para el tipo de propósito y cantidad de vistas que comprende la meta. Los patrones de estrategia surgen como un modo de proveer una solución en la instanciación de estas estrategias integradas.

La base conceptual de vistas de calidad presentada en el Capítulo 5 desempeña un rol importante en la definición de patrones de estrategia. Esto es, sin una clara especificación de los términos y relaciones de vistas de calidad, la ulterior especificación de patrones de estrategia no podría realizarse de manera apropiada. Específicamente, la ontología de vistas de calidad fomenta la especificación y selección de patrones de estrategia adecuados y su instanciación de acuerdo a distintos propósitos de evaluación de las metas de necesidad de información de medición y evaluación.

Por lo tanto, se han identificado un conjunto de patrones considerando algunas de las vistas de calidad instanciadas en la Figura 5.2 y propósitos de evaluación como comprender y mejorar. Por ejemplo, se pueden especificar patrones que ofrezcan solución para la instanciación de la estrategia integrada adecuada en proyectos en los cuales sólo se desea comprender el estado actual de una entidad para una sola vista de calidad. También, patrones para proyectos donde la meta de necesidad de información de medición sea la de mejorar una entidad introduciendo cambios, considerando una o más vistas de calidad. Con el mismo propósito otros patrones pueden especificarse, pero teniendo en cuenta las relaciones de “influencia” y “depende de” entre dos vistas de calidad, o, entre tres vistas.

Para la especificación de los patrones de estrategia se utiliza una plantilla que es una adaptación de la utilizada en [Gamma et al., 1995] para especificar patrones de diseño. La plantilla consta de los siguientes campos: i) nombre: denominación descriptiva, normalmente expresada en inglés, que permite identificar unívocamente y referenciar al patrón; ii) alias: acrónimo o forma abreviada de nombrar al patrón; iii) intención: descripción del objetivo del patrón; iv) motivación (problema): problema que soluciona el patrón; v) aplicabilidad : situaciones en las cuales se puede utilizar el patrón; vi) estructura (solución): solución genérica e instanciable que propone el patrón; vii) usos conocidos: casos reales de aplicación o uso; viii) escenario de uso: ejemplo concreto de instanciación del patrón.

En las secciones siguientes se especifican los patrones de estrategia denominados Goal-oriented Measurement and Evaluation for One Quality View (GoME_1QV), Goal-oriented Measurement, Evaluation and Change for One Quality View (GoMEC_1QV) y Goal-oriented Measurement, Evaluation and Change for Two Quality View (GoMEC_2QV) para propósitos de comprender una vista de calidad y de mejora, considerando una y dos vistas de calidad.

7.2. Patrón de Estrategia GoME_1QV

Una meta de necesidad de información de medición y evaluación puede tener propósitos como comprender, mejorar, monitorear, controlar, seleccionar, entre otros. Particularmente, el propósito de comprender es considerado como uno de los propósitos de evaluación primarios ([Fenton y Pfleeger, 1998], [Morasca, 2001], [INCOSE, 2010]) puesto que implica obtener información del estado o rendimiento actual de una entidad. Por ejemplo, si se considera el propósito de mejora, primero se debe comprender la situación actual de la entidad para poder saber cuáles atributos se deben mejorar de la misma. Si, por otro lado, se considera el propósito de monitorear, el mismo tiene como objetivo el seguimiento del estado o desempeño (rendimiento o performance) de atributos de una entidad [Briand et al., 1996]. En otras palabras, este propósito consiste en una comprensión continua de una entidad a lo largo del tiempo para analizar su evolución y posibles tendencias. En este caso, monitorear involucra al propósito de comprender aplicado de un modo repetitivo, con cierta frecuencia en un intervalo de tiempo definido. Otros propósitos podrían analizarse en función del propósito de comprender y de allí su importancia en evaluación ¹⁰.

En consideración de esto, un proyecto podría operacionalizar una meta de necesidad de información de medición y evaluación cuya declaración establezca “comprender la usabilidad de la aplicación móvil XYZ”. En este caso, la meta comprende la vista de calidad de sistema, puesto que la entidad concreta es la aplicación móvil XYZ la cual pertenece a la súper-categoría de entidad sistema y, al ser usabilidad, la característica a evaluar, el foco de calidad corresponde a calidad externa. Otras vistas de calidad podrían estar comprendidas en una meta de necesidad de información de medición y evaluación con el propósito de “comprender”. Por ejemplo, una meta que establezca “comprender el rendimiento del grupo de desarrolladores XYZ”, siendo la vista de calidad en este caso, la vista de calidad de recurso.

Así pues, para un proyecto de medición y evaluación que operacionalice una meta con el propósito de comprender e involucre una sola vista de calidad, el mismo patrón de estrategia debería ser seleccionado e instanciado con el fin de utilizar sistemáticamente una estrategia de comprensión guiada por actividades de medición, evaluación y análisis. Este patrón de estrategia se denomina Goal-oriented Measurement and Evaluation for One Quality View (GoME_1QV). Los items utilizados para describirlo son:

Nombre: Goal-oriented Measurement and Evaluation for One Quality View.

Alias: GoME_1QV.

Intención: Proveer una solución en la instanciación de una estrategia de medición y evaluación a ser empleada en un proyecto específico cuyo principal objetivo involucre comprender una vista de calidad en un contexto dado.

Motivación (Problema): El propósito es comprender la situación actual de una entidad con respecto a un foco de calidad, en un contexto dado, mediante el empleo sistemático y disciplinado de procesos y métodos de medición, evaluación, análisis que permitan determinar el estado actual de la entidad evaluada, documentando los resultados en un informe de recomendación.

Aplicabilidad : Este patrón se aplica a proyectos de medición, evaluación donde el propósito es comprender la entidad evaluada, involucrando una sola vista de calidad (la vista de calidad de sistema o cualquiera de las vistas de calidad ilustradas en la Figura 5.2).

Estructura (Solución): La estructura del patrón se basa en tres capacidades de una estrategia integrada, esto es: la especificación de un marco conceptual para el dominio de medición y evaluación, la especificación del proceso y la especificación de métodos para dicho dominio.

Este patrón provee como solución un curso de acción genérico que indica las actividades que deben ser instanciadas durante la planificación del proyecto. A su vez, provee especificaciones de métodos que indican cómo deben llevarse a cabo las mismas. Los métodos podrán ser instanciados durante otras fases del ciclo de vida del proyecto como programación y ejecución.

A seguir se muestran los principales aspectos estructurales de las tres capacidades:

La especificación del marco conceptual se corresponde a la ontología de dominio del marco conceptual C-INCAMI, la cual, como ya se ha visto, incluye términos, atributos y relaciones – agrupados en componentes- para el área de medición y evaluación. Los conceptos representan metadatos utilizados de modo uniforme y consistente en las actividades, productos de trabajo y métodos del patrón de estrategia.

El proceso o curso de acción genérico se especifica desde distintas perspectivas, tal cual lo analizado en el Capítulo 2 en la sección relacionada a estrategias integradas de medición y evaluación. La Figura 7.1 muestra, haciendo uso de la perspectiva funcional y de comportamiento, el proceso genérico provisto como solución. Los nombres de las seis actividades (A1-A6) de la Figura 7.1 deben personalizarse cuando se instancie el patrón con la estrategia correspondiente, para la vista de calidad que se esté considerando en el proyecto.

La especificación de métodos indica cómo deben llevarse a cabo las descripciones de las actividades del proceso genérico. El patrón prescribe como tal, la especificación de una métrica directa, la de una indirecta, como métodos para realizar una tarea de medición directa e indirecta respectivamente. Además, se especifica un indicador elemental, como método utilizado durante la evaluación elemental. La plantilla de especificación de dichos métodos es la descripta en la Sección 2.4 del Capítulo 2, donde los campos en cada plantilla se corresponden con términos y atributos de la base conceptual C-INCAMI. Cabe destacar que otros métodos podrían ser utilizados, tales como cuestionarios para actividades de medición, o métodos de agregación para evaluación derivada.

Figura 7.1 Perspectiva funcional y de comportamiento del proceso genérico de GoME_1QV. Nota: VC significa “Vista de Calidad ”.

Usos Conocidos: Este patrón de estrategia instancia la estrategia integrada GOCAME (introducida en la Sección 2.2.1) y ha sido utilizado en distintos casos de estudios, como por ejemplo, para comprender la calidad externa de un sitio web de compras [Olsina et al., 2008b] o la calidad funcional de una aplicación de mashup [Olsina et al., 2012].

Escenario de Uso: Un escenario de uso de este patrón está documentado en [Olsina et al., 2012] donde se describe la instanciación de la estrategia integrada GOCAME para llevar a cabo una meta de necesidad de información de medición y evaluación cuya declaración establecía “comprender la aplicación web ¹¹ desde el punto de vista del usuario viajero considerando el foco de calidad funcional ”.

A continuación, y con el fin de ilustrar un escenario de uso respecto a la utilización de GoME_1QV para instanciar la estrategia GOCAME, se hará brevemente mención al caso de estudio en [Olsina et al., 2012]. Para esto, se indican cada una de las seis actividades detalladas en la Figura 7.1 que debieron instanciarse apropiadamente.

La actividad A1 se instanció como "Definir los Requisitos No Funcionales para la Vista de Calidad de Sistema". La entidad a evaluar era woozor.com, que se categoriza como una entidad perteneciente a la categoría de entidad aplicación web mashup, que corresponde a la súper-categoría de entidad sistema, conformando así, la vista de calidad de sistema a evaluar. El modelo de calidad que se utilizó fue 2Q2U [Lew et al., 2010] con las sub-características (functional accuracy y functional suitability) y atributos relacionados a calidad funcional. Seguidamente, y de acuerdo a las actividades de la Figura 7.1, se instanció la actividad A2, “Diseñar la Medición para Calidad de Sistema”, actividad en la cual se seleccionaron desde el repositorio de métricas, aquellas convenientes para medir los atributos del árbol de requisitos generado en la actividad A1. Por ejemplo, un atributo evaluado fue Component Integratedness on clicking, el cual referenciaba el comportamiento sincronizado y armonioso entre los componentes de la aplicación web luego de seleccionar los iconos del tiempo (aquellos que implicaban la funcionalidad del mashup). La métrica que se utilizó para medir este atributo permitió determinar el grado de integración que los componentes de la aplicación (denominados esclavos) mantenían con respecto al componente principal (el componente del mashup).

Posteriormente y, tal como indica el proceso de GoME_1QV, pudieron realizarse en paralelo o en cualquier orden, el diseño de la evaluación o la implementación de la medición. En esta oportunidad, se realizó primero la actividad A4 (según Figura 7.1), instanciándola como “Diseñar la Evaluación para Calidad de Sistema”. Para esto, se diseñaron los indicadores elementales para cada atributo del árbol de requisitos, como así también los indicadores derivados que calcularían el grado de satisfacción alcanzado por cada sub-característica de calidad funcional. Seguido, se continuó con la actividad A3 ilustrada en la Figura 7.1 e instanciada como “Implementar la Medición para Calidad de Sistema”. La medición se realizó cuantificando los atributos del árbol de requisitos, por medio de las métricas seleccionadas en la actividad A2. La recolección de los datos para todas las métricas directas tuvo lugar en diciembre del 2011 y fue realizada por los evaluadores del proyecto de medición y evaluación. Luego, se ejecutó la actividad A5, instanciada como Implementar la Evaluación para Calidad de Sistema, actividad que permitió interpretar el valor de las métricas de cada atributo evaluado a partir de una transformación del valor medido en un valor evaluado y criterios de decisión (en términos de niveles de aceptabilidad). Por otra parte, fue necesario calcular los valores finales para las sub-características evaluadas. Los detalles relacionados a cómo llevar a cabo la evaluación elemental y global, así como también del modelo de agregación aditivo que se utiliza para calcular los indicadores, el lector puede consultarlos en [Olsina et al., 2008b]. No obstante, en el Capítulo 8, estos métodos de evaluación se describen con mayor detalle para la prueba de concepto, en la que se utiliza el patrón de estrategia GoMEC_1QV, discutido en la próxima sección.

Finalmente, la última actividad, de acuerdo al proceso modelado en la Figura 7.1, a instanciar fue A6 “Analizar y Recomendar para Calidad de Sistema”. En esta actividad, se analizaron los resultados obtenidos para las sub-características de calidad funcional, determinándose que la misma, alcanzaba un nivel de aceptabilidad no satisfactorio (32,26 %). Dado que el propósito de la meta era de comprender, la evaluación concluyó con un análisis, que sirvió para determinar fortalezas y debilidades de la aplicación web evaluada en consideración de la calidad funcional. Por lo tanto, esta actividad tuvo como salida un informe de conclusiones y recomendaciones respecto a fortalezas y debilidades de la entidad evaluada, en un determinado momento, tal como si fuera un análisis instantáneo de la situación actual de la entidad evaluada.

7.3. Patrón de Estrategia GoMEC_1QV

Si un proyecto tiene una meta de necesidad de información de medición y evaluación referida a “mejorar la usabilidad de la aplicación móvil XYZ” esto significa que tiene como tipo de propósito “mejorar” y comprende la vista de calidad de sistema. Esto es porque la entidad concreta es la aplicación móvil XYZ la cual pertenece a la súper-categoría de entidad sistema y el foco de calidad es calidad externa, por ser usabilidad la característica a evaluar. Para esta meta, y tal como se mencionó en la sección anterior, no solo es necesario comprender la situación actual de la entidad respecto a usabilidad sino también ejecutar cambios de manera de re-evaluarla para medir la ganancia de la mejora obtenida.

Podría existir otro proyecto con una meta de necesidad de información de medición y evaluación que tenga también como propósito “mejorar”, pero la vista a considerar puede ser otra (por ejemplo, la vista de calidad de producto software o la de proceso). Por lo tanto, para un proyecto concreto de medición, evaluación y cambio que comprenda una sola vista de calidad, el mismo patrón de estrategia debería ser seleccionado e instanciado adecuadamente. Para este caso, el patrón de estrategia se denomina Goal-oriented Measurement, Evaluation and Change for One Quality View (GoMEC_1QV). Los ítems usados para especificar el patrón son los siguientes:

Nombre: Goal-oriented Measurement, Evaluation and Change for One Quality View.

Alias: GoMEC_1QV.

Intención: Proveer una solución en la instanciación de una estrategia de medición, evaluación y cambio a ser empleada en un proyecto específico cuyo principal objetivo involucre la mejora de una vista de calidad en un contexto dado.

Motivación (Problema): El propósito es comprender la situación actual de una entidad y mejorarla, con respecto a un foco de calidad, en un contexto dado, mediante el empleo sistemático y disciplinado de procesos y métodos de medición, evaluación, análisis y cambio.

Aplicabilidad : Este patrón se aplica a proyectos de medición, evaluación y cambio, donde el propósito es comprender y mejorar la entidad evaluada y que involucra una sola vista de calidad, como por ejemplo la vista de calidad de sistema, la vista de calidad de producto software, entre otras (como aquellas mostradas en la Figura 5.2).

Estructura (Solución): La estructura del patrón se basa en las tres capacidades de una estrategia integrada, esto es: la especificación de la base conceptual de medición y evaluación, un proceso genérico que provea actividades de medición, evaluación y cambio, y métodos para llevar a cabo las actividades. Tanto la base conceptual como los métodos se reúsan del patrón GoME_1QV. Además de los métodos vistos, para las actividades de cambio, otros pueden ser especificados, tales como refactorización, re-estructuración, re-parametrización.

Respecto al proceso, la Figura 7.2 muestra, haciendo uso de la perspectiva funcional y de comportamiento, el proceso genérico provisto como solución. Al igual que la especificación indicada en GoME_1QV, los nombres de las ocho actividades (A1-A8) de la Figura 7.2 deben personalizarse cuando se instancie el patrón con la estrategia correspondiente, para la vista de calidad que se esté considerando en el proyecto.

Usos Conocidos: Este patrón de estrategia fue utilizado en un proyecto de medición, evaluación y cambio cuyo objetivo era mejorar atributos de calidad externa de un carrito de compras a través de refactorización como método de cambio [Olsina et al., 2008a]. También, este patrón se instanció en un proyecto de mejora de un recurso organizacional (una estrategia) [Papa, 2012] [Papa et al., 2015].

Escenario de Uso: Un escenario de uso de este patrón será ilustrado en el Capítulo

8, donde se describe un proyecto de medición, evaluación y cambio para evaluar la usabilidad de la aplicación LinkedIn para dispositivos móviles con Android. El objetivo del estudio fue detectar problemas de usabilidad, mediante el análisis de fortalezas y debilidades de la interface gráfica, y la recomendación y ejecución de acciones de cambio para minimizar o eliminar las debilidades.

Figura 7.2 Perspectiva funcional y de comportamiento del proceso genérico de GoMEC_1QV. Nota: VC significa “Vista de Calidad ”.

7.4. Patrón de Estrategia GoMEC_2QV

Situaciones más complejas son aquellos casos donde intervienen dos o más vistas de calidad. Recordando que la calidad externa depende de la calidad interna (relación “depends on” entre la vista de calidad de sistema y la de calidad de producto software de la Figura 5.2) es posible introducir cambios en un producto, como por ejemplo, en un diagrama de clases, y que estos mejoren la mantenibilidad del sistema como, por ejemplo, una aplicación Java.

Para un proyecto cuya meta de necesidad de información de medición tenga como propósito la mejora de una entidad e involucre para ello, dos vistas de calidad, el patrón adecuado a instanciar es el denominado Goal-oriented Measurement, Evaluation and Change for Two Quality Views (GoMEC_2QV). Es por tanto, aplicable a proyectos de medición, evaluación y cambio donde se busque mejorar una vista de calidad introduciendo cambios en otra vista de calidad.

Este patrón de estrategia se basa en el hecho que una vista de calidad puede ser mejorada a partir de acciones de cambio dirigidas por evaluación, llevadas a cabo en otra vista de calidad relacionada, gracias a las ya mencionadas relaciones de “influencia” y “depende de” entre vistas de calidad. Es importante destacar que una restricción en este patrón es que la vista a mejorar debe depender de la vista sobre la cual se realizan los cambios. El patrón puede ser instanciado con otras dos vistas relacionadas, tal como la vista de calidad de recurso con la vista de calidad de proceso, considerando que la calidad de un recurso (por ejemplo, una nueva herramienta) influencia la calidad del proceso (por ejemplo, el proceso de desarrollo). Lo mismo es válido, pero en sentido contrario. La calidad del proceso depende de la calidad del recurso.

Cuando se trata de la vista de calidad de sistema y la vista de calidad de sistema en uso, la instanciación de este patrón da lugar a la estrategia SIQinU, la cual personaliza el proceso del patrón GoMEC_2QV para dichas vistas de calidad. La especificación del patrón es la siguiente:

Alias: GoMEC_2QV.

Intención: Proveer una solución en la instanciación de una estrategia de medición, evaluación y mejora, que da soporte a una meta de necesidad de información de medición y evaluación cuando se consideran dos vistas de calidad relacionadas.

Motivación (Problema): Considerando que una vista de calidad dada depende (directa o indirectamente) de otras vistas de calidad, el propósito es mejorar la situación actual de una entidad concreta que pertenece a una vista de calidad dependiente por medio de la aplicación de cambios dirigidos por evaluación sobre otra entidad que pertenece a una vista de calidad independiente relacionada.

Aplicabilidad : Este patrón se aplica en proyectos de medición, evaluación y cambio donde el propósito es mejorar una entidad respecto a un foco de calidad (conformando una vista de calidad dependiente) a través de mejorar, ejecutando cambios, otra entidad respecto a otro foco de calidad (dando lugar a una vista de calidad independiente). Por ejemplo, mejorar una aplicación en uso (considerando la vista de calidad de sistema en uso) por medio de la mejora del sistema (considerando la vista de calidad de sistema). La relación “depende de” puede ser considerada también de un modo transitivo. Por ejemplo, mejorando la vista de calidad de sistema a través de la mejora de la vista de calidad de recurso.

Estructura (Solución): La estructura del patrón está basada en las tres capacidades de una estrategia integrada. La especificación de la base conceptual de medición y evaluación, así como la especificación de los métodos, se reusan del patrón GoMEC_1QV.

Respecto a la especificación del proceso, el patrón provee un curso de acción genérico el cual indica las actividades que pueden ser instanciadas durante la planificación del proyecto. La Figura 7.3 ilustra el proceso genérico de este patrón. Los nombres de las actividades de medición, evaluación y cambio deben ser personalizadas considerando las vistas de calidad concretas a evaluar.

Figura 7.2 Perspectiva de comportamiento del proceso genérico de GoMEC_2QV. Nota: VCD significa “Vista de Calidad Dependiente” y VCI significa “Vista de Calidad Independiente”.

Usos conocidos: GoMEC_2QV fue usado para instanciar la estrategia SIQinU en un caso de estudio documentado en [Lew et al., 2012].

Escenario de uso: Un ejemplo de instanciación de este patrón de estrategia es el caso de estudio relacionado con la evaluación de la aplicación para el seguimiento de defectos, conocida como JIRA. El caso de estudio completo fue presentado en [Lew et al., 2012] por lo que solo se resaltarán aspectos generales del proceso usado a fin de ilustrar un escenario de aplicación del patrón de estrategia. Cabe destacar que la estrategia SIQinU fue usada en el contexto de una empresa de testing real, con sede en Pekín, China.

El proyecto tenía como meta de necesidad de información de medición y evaluación “comprender y mejorar la usabilidad actual del sistema JIRA en uso”. La evaluación debía hacerse considerando el punto de vista de un usuario principiante, ejecutando la tarea más habitual en JIRA, a saber, ingresar un nuevo defecto. La comprensión y mejora se realizó definiendo requisitos no funcionales para calidad en uso y evaluando el sistema en uso. Con los problemas detectados en calidad en uso que se consideraban que influían positivamente en la calidad en uso, se definieron los requisitos no funcionales para calidad externa asociados, evaluándolos, de tal manera de comprobar si, la mejora de ellos, incidía en la mejora de los atributos y características de calidad en uso.

Por lo tanto, la meta de necesidad de información de medición y evaluación comprendía dos vistas de calidad. Por un lado, la vista de calidad de sistema en uso; con el foco de calidad, calidad en uso (por considerarse para la evaluación, la característica usabilidad en uso, según el marco de calidad 2Q2U) y como súper-categoría de entidad sistema en uso (puesto que la aplicación JIRA se consideró cuando estaba siendo utilizada por usuarios reales). Por otro lado, y dado que el objetivo era la mejora a partir de la mejora de atributos relacionados de la aplicación, la otra vista de calidad comprendida fue la vista de calidad de sistema. Siendo calidad externa el foco de la evaluación ya que era usabilidad la característica a ser evaluada en el sistema y, la súper-categoría de entidad sistema. En consecuencia, GoMEC_2QV resultó el patrón indicado a instanciar, por tratarse de dos vistas de calidad relacionadas y el tipo de propósito de mejora.

Dado que las vistas de calidad comprendidas fueron la vista de calidad de sistema en uso y la vista de calidad de sistema, la estrategia instanciada a partir del patrón GoMEC_2QV fue SIQinU. De acuerdo al proceso que indica el patrón de estrategia, SIQinU personalizó las actividades que éste comprende para las dos vistas de calidad que intervienen. En este caso, y de acuerdo a la Figura 7.3, la vista de calidad dependiente fue la vista de calidad de sistema en uso, mientras que la vista de calidad independiente se correspondió con la vista de calidad de sistema.

Considerando entonces el proceso propuesto por el patrón de estrategia, la primera actividad a realizarse fue la de “Definir Requisitos y Criterios de Evaluación para la Vista de Calidad de Sistema en Uso” (A1_VCD en la Figura 7.3). Esto se llevó a cabo especificando la tarea considerada (ingresar un nuevo defecto). Con el fin de recolectar datos de las actividades del usuario de manera no intrusiva, cuando ejecuta la tarea específica a evaluar, fue necesario agregar funcionalidades de registro de datos (usage data) al sistema. Luego se instanció la actividad “Diseñar la Medición y Evaluación para la Vista de Calidad de Sistema en Uso” (A2_VCD en la Figura 7.3) la cual consistió en diseñar las métricas e indicadores correspondientes. A continuación se ejecutó la actividad “Implementar la Medición, Evaluación y Análisis para Vista de Calidad de Sistema en Uso” (A3_VCD en la Figura 7.3) en la cual se midió cada atributo con su correspondiente métrica y se obtuvieron los valores de indicadores para cada valor de medida obtenido de los atributos y aquellos calculados para las características y sub-características evaluadas. Los resultados de la evaluación se analizaron en la actividad A4 “Analizar Resultados para la Vista de Calidad de Sistema en Uso”. Esto implicó llevar a cabo un análisis preliminar en el cual se detectó que algunos atributos de usabilidad en uso (particularmente para eficiencia y eficiencia en uso) no fueron satisfechos, debido a que el valor de sus indicadores dieron por debajo del valor óptimo establecido.

Dado que los requisitos no fueron satisfechos, esto condujo a la actividad “Derivar Requisitos y Criterios de Evaluación para la Vista de Calidad de Sistema” (A1_VCI en la Figura 7.3). Con los problemas detectados en calidad en uso usando la aplicación, se definieron los requisitos no funcionales para calidad externa asociados que pudieran afectar (influenciar) la calidad en uso. Por consiguiente, luego de la actividad A1 para la vista de calidad independiente, el sistema se midió y evaluó nuevamente (actividades A2_VCI y A3_VCI en la Figura 7.3) considerando características de calidad externa. En la actividad “Analizar Resultados para la Vista de Calidad de Sistema” (A4_VCI en Figura 7.3) se analizaron los resultados de la evaluación y se dieron recomendaciones de mejora (cambio) para aquellos atributos con un bajo nivel de aceptabilidad. A partir de estas recomendaciones y mediante re-parametrización como técnica de cambio, se diseñaron los cambios en el sistema (actividad “Diseñar Acciones de Cambio para la Vista de Calidad de Sistema”, A5_VCI en Figura 7.3), y se implementaron dichos cambios a través de la actividad “Implementar Acciones de Cambio para la Vista de Calidad de Sistema” (A6_VCI en la Figura 7.3). De este modo, se generó una nueva versión reparametrizada de la aplicación. Posteriormente, se volvió a evaluar la calidad externa para conocer la ganancia obtenida luego de los cambios realizados. Como luego no hubo más recomendaciones de mejora, se evaluó nuevamente la calidad en uso (A3_VCD en la Figura 7.3) para observar la ganancia obtenida en la vista calidad de sistema en uso gracias a las mejoras realizadas en la vista de calidad de sistema. La nueva evaluación se llevó a cabo con las mismas pruebas y tipos de usuarios, en el mismo contexto de uso. De esta manera, fue posible determinar cómo la vista de calidad dependiente (en este caso, la vista de calidad de sistema en uso) fue mejorada gracias a mejoras realizadas en la vista de calidad independiente (la vista de calidad de sistema). Para conocer detalles de las evaluaciones y cambios introducidos, el lector interesado puede dirigirse a [Lew et al., 2012].

7.5. Discusión de Otros Patrones de Estrategia

Además de los patrones presentados en la sección anterior, otros podrían diseñarse considerando distintos propósitos de evaluación y la cantidad de vistas de calidad relacionadas.

Hemos visto que el caso más básico y fácil de instanciar es el patrón de estrategia GoME_1QV que se utiliza con metas de necesidad de información de medición y evaluación que comprendan una sola vista de calidad (por ejemplo, la vista de calidad de recurso o la vista de calidad de sistema o la de producto software) con el propósito únicamente de comprender. GoME_1QV es un patrón similar a GoMEC_1QV, pero difieren en que GoMEC_1QV sirve para propósitos no solo de comprender sino también de mejorar la entidad evaluada. Por esta razón el proceso de GoMEC_1QV cuenta con ciclos de cambio y re-evaluación, actividades que no prescribe el proceso de GoME_1QV.

Considerando el mismo propósito de comprender, es factible también distinguir metas de necesidad de información de medición y evaluación que requieran la evaluación de dos vistas de calidad. Para esta situación, el patrón de estrategia que aporta solución se denomina Goal-oriented Measurement, Evaluation for Two Quality View (GoME_2QV). Por ejemplo, podría aplicarse para comprender la usabilidad de una aplicación teniendo en consideración aspectos arquitecturales. En este caso, las vistas involucradas son la vista de calidad de sistema y la vista de calidad de producto software. En [Folmer et al., 2003] los autores plantean que la arquitectura del software puede restringir la usabilidad del sistema, argumentando que muchos de los problemas de usabilidad en los sistemas actuales se detectan en etapas de desarrollo o testing, cuando en realidad debería prestarse atención a etapas tempranas, considerando los artefactos de software (modelos arquitecturales, de diseño, navegacionales, entre otros). Para esto, proponen un conjunto de soluciones de diseño (en la forma de patrones y propiedades de usabilidad) para los cuales analizan los efectos en la usabilidad y las potenciales implicancias en la arquitectura de software. Por lo tanto, considerando que no es una cuestión menor la relación de “influencia” y “depende de” entre las vista de calidad de sistema y la vista de calidad de producto software, GoME_2QV puede aportar otra solución para el problema que enfatizan en [Folmer et al., 2003].

Teniendo en cuenta las relaciones entre vistas de calidad, puede diseñarse también un patrón de estrategia para tres vistas de calidad. En este sentido, el patrón Goal-Oriented Measurement, Evaluation and Change for Three Quality View (GoMEC_3QV) sirve para instanciar estrategias que lleven a cabo metas de necesidad de información de medición que consideren tres vistas de calidad, como por ejemplo, la vista de calidad de producto software, la vista de calidad de sistema y la vista de calidad de sistema en uso; con el propósito de mejorar. En este sentido, un proyecto podría operacionalizar una meta de necesidad de información de medición referida a “mejorar la calidad en uso de una aplicación móvil XYZ por medio de la mejora de la calidad del sistema y el producto software”. Cabe resaltar que, al momento, no están especificados los patrones GoME_2QV y GoMEC_3QV. Simplemente, se vislumbra que otras soluciones podrían aportar los patrones con las características especificadas pero que, al momento, su proceso no ha sido definido.

7.6. Conclusiones

Los beneficios de tener documentados patrones son bien conocidos en Ingeniería de Software y Web. En este sentido, esta tesis propone contribuir con la especificación de un conjunto de patrones de estrategia para ser aplicados en proyectos de medición, evaluación y aquellos que contemplen también cambio.

En este capítulo se han descripto tres patrones de estrategia para metas de necesidad de información de medición y evaluación que comprenden distintas cantidades de vistas de calidad y la comprensión y mejora como propósitos de evaluación. Para esto, el modelado de vistas de calidad y sus relaciones es de especial importancia puesto que ayuda a desarrollar una familia de patrones de estrategia, a partir de las relaciones de “influencia” y “depende de”.

Esencialmente, los patrones de estrategia pueden ser considerados como “experiencias enlatadas”, que, en este caso, están listas para ser abiertas y usadas por evaluadores en procesos de aseguramiento de calidad.

Es importante también resaltar que la inclusión de patrones de estrategia en el Enfoque de Evaluación de Calidad, lo hace escalable, gracias a la concepción de distintos patrones de estrategia aplicados a distintas vistas de calidad relacionadas, y tipos de propósitos de medición que comprendan las metas de proyectos de medición y evaluación (y eventualmente, cambio). El enfoque puede extenderse para, no solo especificar vistas de calidad, sino también requerimientos de costo, dado que costo, es también una característica calculable, como calidad. Además, otros propopósitos como comparar, monitorear y controlar y seleccionar se pueden concevir. Por lo tanto, estos aspectos se desarrollarán en trabajos futuros.

Capítulo 8 - Pasos del Enfoque de Evaluación de Calidad: Un Caso Aplicado

En este capítulo se presenta la aplicabilidad del Enfoque de Evaluación de Calidad a través de la descripción de las actividades involucradas en el establecimiento de metas, sub-metas, proyectos y estrategias a distintos niveles organizacionales. Se ilustra además la aplicación con una prueba de concepto.

Los trabajos de investigación que acreditan el desarrollo de la teoría presentada son: [Rivera et al., 2014], [Rivera et al., 2016b] y [Rivera et al., 2016c].

La organización del capítulo es la siguiente:

– Sección 8.1: Describe los pasos a seguir en el Enfoque de Evaluación de Calidad.

– Sección 8.2: Presenta una prueba de concepto relacionada a evaluar y mejorar la usabilidad de la aplicación LinkedIn para smartphones.

– Sección 8.3: Presenta las conclusiones.

8.1. Aplicabilidad del Enfoque de Evaluación de Calidad

El Enfoque de Evaluación de Calidad combina las siguientes características:

– Metas de negocio y de necesidad de información multinivel.

– Distintos propósitos de evaluación y vistas de calidad en las metas de necesidad de información de medición y evaluación.

– Proyectos de medición y evaluación y/o cambio para operacionalizar metas de necesidad de información de medición y evaluación.

– Patrones de estrategia para la instanciación de la estrategia integrada adecuada que ayude a alcanzar metas de necesidad de información de medición y evaluación.

Para la aplicación del enfoque se propone una serie de pasos o actividades principales. Esta guía de actividades puede ayudar a los participantes (stakeholders) en el proceso de relacionar metas de negocio con metas de necesidad de información de medición y evaluación, además de la formulación y ejecución de proyectos de medición, evaluación y/o cambio. A continuación, se listan los pasos o actividades principales propuestos para la aplicación del enfoque:

Establecer una meta de negocio a algún nivel organizacional.

Refinar la meta de negocio de ser necesario, en metas de negocio tácticas/operativas.

Establecer la meta de necesidad de información para cada meta de negocio en el correspondiente nivel organizacional.

Formular proyectos de medición, evaluación y/o cambio para aquellas metas de necesidad de información que requieran metas de necesidad de información de medición y evaluación.

4.1. Seleccionar un patrón de estrategia para cada meta del proyecto de medición, evaluación y/o cambio.

4.2. Para cada patrón de estrategia seleccionado, instanciar la estrategia integrada adecuada conforme al contexto (o caso) particular.

Ejecutar los proyectos de medición, evaluación y/o cambio.

Verificar el logro de las metas de negocio a través del análisis de las metas de necesidad de información.

Es importante destacar que estos pasos no consideran cómo se realiza el descubrimiento de metas en cada nivel organizacional. Según [Singh y Woo, 2008], una revisión de la literatura referida a ingeniería de requerimientos revela que hay pocos enfoques para el descubrimiento de metas. Y, de los existentes, la mayoría carecen de una estructura detallada y sistemática, además de ser más bien abstractos y de alto nivel. Por lo que cuestiones como ¿qué es una meta de alto nivel? o ¿quien establece qué es alto nivel? permanecen poco claras, aun después de la elicitación de las metas. A modo de resolver algunas de estas limitaciones, proponen una metodología para el descubrimiento de metas estratégicas, tácticas y operativas, haciendo claras distinciones entre cada una de ellas. Por ejemplo, para el descubrimiento de metas estratégicas, establecen la utilización de cuestionarios cuyas preguntas estén validadas.

GQM+ Strategies también establece la realización de preguntas para la identificación de metas de alto nivel, tal como se describió en la sub-sección 3.2.1 del Capítulo 3. Por otra parte, para la identificación de las metas de software (metas tácticas) mencionan que se derivan a partir del análisis realizado sobre las implicancias de la estrategia elegida para las metas de alto nivel y teniendo en cuenta los factores de contexto y las suposiciones. BSC constituye otra propuesta para representar metas estratégicas y tácticas, como se discutió en el Capítulo 3.

La guía de medición orientada a metas [Park et al., 1996] también se refiere a la identificación de metas de negocio a partir de las llamadas “tormenta de ideas”(mejor conocidas como brainstorming) o utilizando la técnica NGT (Nominal Group Technique). Y proponen para la identificación de las sub-metas, un proceso en el cual, para cada meta de alto nivel, identifican los actores involucrados, crean esquemas (modelos mentales) de los procesos relevantes, listan las entidades que intervienen en los procesos y, para cada entidad, realizan preguntas cuyas respuestas ayudan a planear y manejar las metas. Con estas preguntas, agrupadas en temáticas, se derivan las sub-metas, a partir de cada grupo temático generado.

Si bien el trabajo de Singh et al., la guía de medición orientada a metas y los trabajos de Basili respecto de GQM+ Strategies (como por ejemplo [Basili et al., 2007b] o [Basili et al., 2010]) sirvieron como referencia para la distinción de metas a distintos niveles organizacionales; este trabajo no se enfoca en establecer la manera en la cual, en cada nivel -a excepción del nivel operativo o de proyecto-, las metas son establecidas. Por lo tanto, es válido considerar la identificación de metas de negocio tal como lo proponen los tres trabajos citados, o bien, utilizar la técnica que la organización determine sea la más acertada para la definición de sus metas de negocio estratégicas o tácticas.

Interesan en este trabajo las metas de negocio y de necesidad de información de medición y evaluación, para las cuales se propone identificar su propósito de evaluación y las vistas de calidad. Estas cuestiones permiten la adecuada selección de la estrategia integrada a utilizar para llevarla a cabo. Es preciso destacar que estos aspectos no se observan en GQM+ Strategies como tampoco en la guía de medición orientada a metas, por citar los enfoques analizados que más se asemejan a la presente propuesta.

8.2. Prueba de Concepto

Para ilustrar los pasos de aplicación del enfoque, listados previamente, en las sub-secciones siguientes se desarrollará una prueba de concepto para la evaluación y mejora de la usabilidad de la aplicación LinkedIn para smartphones. La Figura 8.1 muestra las actividades realizadas, según los pasos descriptos en la sección anterior, en consideración de esta prueba de concepto, a partir un modelo de proceso utilizando la notación BPMN (Business Process Model ling Notation) ¹² .

Figura 8.1 Principales actividades del Enfoque de Evaluación de Calidad para el escenario de evaluación y mejora de LinkedIn para smartphones.

8.2.1. Establecimiento de las metas de negocio y las metas de necesidad de información

Según el sitio de estadísticas Statista ¹³, en el segundo trimestre del año 2016, LinkedIn ha tenido un promedio de 63 millones de usuarios visitantes desde la aplicación móvil, datos que pueden observarse en la Figura 8.2. Esta cifra, de acuerdo a los valores mostrados en el gráfico de la Figura 8.3, representa el 59 % de todos los usuarios visitantes para ese trimestre.

En consideración de esta información, puede suponerse que, con el objetivo de ampliar aún más el porcentaje de usuarios visitantes móviles, la gerencia de LinkedIn establece a nivel estratégico la siguiente meta de negocio “Ampliar en un 20 % el mercado de usuarios que utilizan la versión móvil de la aplicación para el próximo año”, la cual es una meta que será operacionalizada por un proyecto específico (paso 1 de la Figura 8.1).

Figura 8.2 Usuarios móviles que visitan LinkedIn desde el primer trimestre de 2013 hasta el segundo trimestre de 2016 (expresado en millones). Fuente: ©Statista 2017, con información proporcionada por LinkedIn.

Figura 8.3 Cantidad de usuarios (en millones) de LinkedIn desde el primer trimestre del 2009 al tercer trimestre del 2016. Fuente: ©Statista 2017, con información proporcionada por LinkedIn.

Para la meta de negocio a nivel estratégico identificada, se establecen dos sub-metas de negocio relacionadas (paso 2 de la Figura 8.1):

(a) Incrementar un 5 % la publicidad en dispositivos móviles.

(b) Incrementar un 10 % la usabilidad de la aplicación en dispositivos móviles en un plazo de 8 meses.

Respecto a la sub-meta de negocio (b), la misma puede ser alcanzada efectuando mejoras en la aplicación LinkedIn, a partir de actividades de medición, evaluación y cambio, por lo tanto, se considera una meta operativa a nivel de proyecto. Para dar soporte a esta meta de negocio, se establece una meta de necesidad de información (paso 3 de la Figura 8.1), la cual tiene como declaración “Analizar si la usabilidad ha mejorado en un 10 % luego de los cambios efectuados” en el período de tiempo comprendido en los 8 meses. Esta meta de necesidad de información permitirá conocer el grado en el cual la meta de negocio operativa (b) ha sido alcanzada.

Para esta situación, esta meta de necesidad de información requiere de una meta de necesidad de información de medición y evaluación, la cual tiene como declaración “Mejorar la usabilidad de la aplicación en dispositivos móviles en un 10 % en un plazo de 4 meses”. Esta meta implica que, primero se deberá comprender, es decir, se obtendrá información respecto al estado actual de la aplicación considerando sub-características de usabilidad. Posteriormente, dicha información servirá para dar recomendaciones e introducir los cambios necesarios en la aplicación a fin de lograr una mejora. Para esta meta de necesidad de información de medición y evaluación se formula un proyecto de medición, evaluación y cambio (paso 4 de la Figura 8.1). La Figura 8.4 ilustra los términos resaltados en esta parte de la descripción de la prueba de concepto, a saber, meta de negocio (BusinessGoal ), meta de necesidad de información (InformationNeedGoal ), meta de necesidad de información de medición y evaluación (MEInformationNeed ) y proyecto (Project ), instanciados de acuerdo al modelo de la base conceptual de metas de negocio de la Figura 6.1, del Capítulo 6.

Respecto a la sub-meta de negocio (a), “Incrementar un 5 % la publicidad en dispositivos móviles”, es preciso resaltar que no será analizada dado que seguramente es una meta que requiera sub-metas, proyectos y estrategias relacionadas al área de marketing (o publicidad), que está fuera del alcance de esta tesis. Constituye una meta de nivel táctico que, efectuada su exitosa concreción, en conjunto con la concreción de la meta de negocio operativa detallada anteriormente, deberían contribuir al logro de la meta de negocio a nivel estratégico, planteada por la gerencia de LinkedIn.

Figura 8.4 Escenario de la prueba de concepto, donde la meta de negocio, a nivel estratégico, se descompone en sub-metas las cuales están soportadas por metas de necesidad de información y de necesidad de información de medición y evaluación.

8.2.2. Prosecución de la meta de necesidad de información de medición y evaluación

Como parte de la asignación de recursos del proyecto de medición, evaluación y cambio, se debe escoger la estrategia integrada que llevará a cabo la meta de necesidad de información de medición y evaluación. En esta instancia, y tal cual propone el Enfoque de Evaluación de Calidad, se selecciona el patrón de estrategia acorde que instanciará la estrategia integrada adecuada (paso 4 de la Figura 8.1).

En la declaración de la meta de necesidad de información de medición y evaluación (“Mejorar la usabilidad de la aplicación en dispositivos móviles en un 10 % en un plazo de 4 meses”) está comprendido el propósito de mejora y la vista de calidad de sistema, por tratarse de la evaluación de la usabilidad, que pertenece al foco de calidad externa; y la categoría de entidad aplicación web, que pertenece a la súper-categoría, sistema. La Figura 8.5 muestra estos términos instanciados de acuerdo a la base conceptual de requisitos no funcionales y vistas de calidad de la Figura 6.1, del Capítulo 6. Bajo estas condiciones, el patrón de estrategia adecuado es GoMEC_1QV. Tal lo discutido en el Capítulo 7, este patrón provee un curso de acción genérico que deberá ser personalizado mediante la estrategia adecuada. En este caso, la estrategia que instancia al patrón es GOCAMEC (ver Figura 8.4 para la instanciación de los términos de estrategia y patrón de estrategia, según la prueba de concepto que se está describiendo). De acuerdo al proceso de GoMEC_1QV (descripto en la Figura 7.2 del Capítulo 7) que tiene que personalizar la estrategia GOCAMEC, en esta sub-sección se describe la instanciación de cada actividad para la evaluación de la usabilidad de LinkedIn.

Figura 8.5 Escenario de la prueba de concepto instanciando la meta de necesidad de información de medición y evaluación.

De nuevo, la meta de necesidad de información de medición y evaluación establece en su declaración “Mejorar la usabilidad de la aplicación en dispositivos móviles en un 10% en un plazo de 4 meses”. La usabilidad constituye un aspecto clave para asegurar y mantener la adopción de aplicaciones caracterizadas por la heterogeneidad de personas y plataformas [Nielsen y Budiu, 2012]. En este trabajo se considera la definición de usabilidad de [Olsina et al., 2012] la cual se define en el marco del modelo de calidad 2Q2U (introducido en el Capítulo 3, como parte de los trabajos relacionados a vistas de calidad).

En la Figura 8.6 se define usabilidad junto con algunas sub-características, que conforman el modelo de calidad utilizado en la prueba de concepto para evaluar la meta de necesidad de información de medición y evaluación.

Figura 8.6 Definición de las sub-características de usabilidad para el foco de calidad externa, consideradas en la prueba de concepto.

Definir los Requisitos No Funcionales

De acuerdo a la Figura 7.2 del proceso establecido para GoMEC_1QV, la actividad A1 se personaliza como “Definir los Requisitos No Funcionales para la Vista de Calidad de Sistema”. Esta actividad tiene como entrada la meta de necesidad de información de medición y evaluación, “Mejorar la usabilidad de la aplicación LinkedIn en dispositivos móviles en un 10 % en un plazo de 4 meses”. La entidad concreta a evaluar es la aplicación “LinkedIn” para smartphones en su versión 4.0.44 ¹⁴ . La categoría de entidad es “aplicación de red social” y la súper-categoría de entidad es “sistema”. La actividad produce como resultado el documento “Especificación de los Requisitos No Funcionales” donde se detalla el árbol de requisitos no funcionales indicando las características, sub-características y atributos relacionados a usabilidad para el foco de calidad externa que lo conforman ¹⁵, como se observa en la Figura 8.7.

Figura 8.7 Características, sub-características y atributos (en itálica) del árbol de requisitos no funcionales diseñado para la evaluación de LinkedIn.

Uno de los atributos diseñados es “Reconocimiento de Iconos de Controles Principales” y los sub-entes seleccionados se corresponden con los íconos de controles principales, resaltados en la parte superior de la Figura 8.8 (a). Otro atributo diseñado es “Reconocimiento de Iconos de Controles Contextuales”, para el cual se identificaron los sub-entes (los íconos de controles contextuales ilustrados en la Figura 8.8 (a)) en la pantalla “Home”. El tercer atributo es “Soporte de Entrada Obligatoria” y los sub-entes a medir se corresponden con los campos que necesitan soporte de entrada obligatoria ¹⁶ ,como ilustra la Figura 8.8 (b). Estos campos son los mínimos y necesarios que el usuario debe completar para poder continuar con la tarea que está realizando. También existen campos opcionales, pero no han sido tenidos en cuenta en la medición y evaluación del atributo mencionado.

Figura 8.8 Pantallas de LinkedIn utilizadas para la medición de los atributos: (a) “Reconocimiento de Iconos de Controles Principales” y “Reconocimiento de Iconos de Controles Contextuales”; (b) “Soporte de Entrada Obligatoria”.

Diseñar la Medición

La segunda actividad (A2 en la Figura 7.2) que se personaliza, es la de “Diseñar la Medición para la Vista de Calidad de Sistema”. En el diseño de la medición se seleccionan desde un repositorio las métricas a utilizar que cuantificarán los atributos ilustrados en la Figura 8.7. Si las métricas a seleccionar no se adecuaran a los atributos que se quieren medir, estas pueden ser modificadas o bien creadas, las que luego serán almacenadas en el repositorio para poder ser reusadas en ulteriores mediciones.

Para que el diseño de las métricas (ya sean directas o indirectas) sea uniforme y consistente, fue de utilidad utilizar las plantillas de especificación de métodos (Figura

2.11) que provee el patrón de estrategia GoMEC_1QV. La Figura 8.9 ejemplifica la plantilla instanciada para la métrica indirecta “Porcentaje del Soporte de Entrada Obligatoria” que cuantifica al atributo “Soporte de Entrada Obligatoria”. Por su parte, la Figura 8.10 ejemplifica la plantilla instanciada para su métrica directa relacionada denominada “Nivel de Soporte de Entrada Obligatoria”.

Figura 8.9 Especificación de la métrica indirecta para el atributo Soporte de Entrada Obligatoria.

Figura 8.10 Especificación de la métrica directa relacionada a la métrica indirecta Porcentaje del Soporte de Entrada Obligatoria..

Para poder medir el atributo Soporte de Entrada Obligatoria, tal como se indica en la especificación de la métrica indirecta, fue necesario seleccionar el conjunto de campos adecuados, que deberían ser de entrada obligatoria. La Figura 8.11 indica, en letra itálica, todos estos campos, que fueron considerados para la medición. Los mismos se encuentran clasificados según las distintas pantallas de LinkedIn.

Figura 8.11 Especificación de pantallas seleccionadas de LinkedIn para smartphones con campos a medir para el atributo Soporte de Entrada Obligatoria.

Diseñar la Evaluación

La siguiente actividad que se instanció fue la de “Diseñar la Evaluación para la Vista de Calidad de Sistema” (A4 en la Figura 7.2). Al igual que las métricas, los indicadores pueden ser seleccionados desde un repositorio, modificados e incluso creados. Para el diseño de los indicadores también se utilizó la plantilla de especificación del método de evaluación elemental (Figura 2.12) provista por el patrón GoMEC_1QV. La Figura 8.12 ejemplifica el diseño del indicador elemental “Nivel de Desempeño de Soporte de Entrada Obligatoria” que, al igual que en el caso de las métricas ilustradas en las Figuras 8.9 y 8.10, corresponde al atributo “Soporte de Entrada Obligatoria”. En la plantilla instanciada se especifica el modelo elemental para el indicador, es decir, la función que indica el mapeo del valor medido del atributo al valor de indicador.

Los indicadores cuentan además con valores umbrales que son los que definen los criterios de decisión o niveles de aceptabilidad. Para esta evaluación, se definieron tres niveles, usando una escala porcentual acordada, a saber: valores entre 0-60 representan un nivel insatisfactorio y significa que las acciones de cambio se deben realizar de manera urgente; valores entre 60-80 representan un nivel marginal indicando que se necesitan acciones de cambio; y valores entre 80-100 indican un nivel satisfactorio, lo cual significa que no se necesitan acciones de cambio. Estos niveles fueron establecidos por los evaluadores, quienes, de acuerdo a su experticia, determinan cuáles son los rangos que consideran como indicadores de satisfacción y cuáles están por debajo de ello. Además, el significado de cada nivel es importante para las recomendaciones de cambio.

Figura 8.12 Especificación del indicador elemental para el atributo Soporte de Entrada Obligatoria.

Una vez seleccionado un indicador elemental para cada atributo, se diseñaron los indicadores derivados para calcular el valor de cada característica y sub-característica del árbol de requisitos. Para estos indicadores se usó un modelo global de agregación que permitió calcular el nivel global de usabilidad obtenido. El modelo utilizado para la evaluación fue el modelo de puntaje aditivo, que se puede representar o especificar con la siguiente fórmula:

donde IP/G es “Indicador Parcial/Global ”, Pi son los diferentes pesos asignados a los indicadores elementales/parciales, e I Ei son los valores de indicadores obtenidos. La fórmula asigna pesos a los indicadores elementales (los atributos) y a los indicadores derivados (características y sub-características) de acuerdo a la importancia relativa que los evaluadores determinan para cada uno de ellos. Utilizando la fórmula matemática descripta, se calcula, de manera agregada, el valor de las características y sub-características para obtener el valor final del requisito de calidad evaluado, a saber, usabilidad.

Implementar la Medición

Luego del diseño de la medición y evaluación, se continuó con la actividad A3 que, instanciada, se renombra como “Implementar la Medición para la Vista de Calidad de Sistema”. Para ello se procedió a medir los diferentes atributos por medio de sus métricas ya seleccionadas en la actividad A2, siguiendo los pasos establecidos en la especificación de las mismas.

Para el atributo “Soporte de Entrada Obligatoria” –cuya métrica indirecta fue especificada en la Figura 8.9-, las mediciones de todos los campos (ilustrados en la Figura 8.11) dieron el valor cero como resultado, ya que no se encontró soporte para entradas obligatorias en ninguno de estos campos evaluados. Los valores de las medidas quedan registrados en el repositorio de medidas («datastore» Medidas de la Figura 2.8).

Implementar la Evaluación

Luego de implementar la medición se continuó con la actividad A5 de la Figura 7.2, esto es “Implementar la Evaluación para la Vista de Calidad de Sistema”. Para la evaluación elemental, se realizó la transformación del valor medido del atributo en un valor de indicador, de acuerdo a la función que se especificó en el modelo elemental. Una vez finalizada dicha evaluación, es decir, calculado el valor de los indicadores para cada atributo del árbol de requisitos, se ejecutó la evaluación global según el modelo de puntaje aditivo. Los resultados obtenidos para la evaluación elemental y global se detallan en la 3ra y 4ta columna en la Figura 8.13.

Analizar y Recomendar

Finalizada la evaluación, la próxima actividad fue la A6, “Analizar y Recomendar para la Vista de Calidad de Sistema”. Esta actividad utiliza la meta de necesidad de información, cuyo propósito es analizar los resultados de la evaluación para determinar si se alcanzó o no la meta de negocio operativa propuesta.

Observando los resultados de la Figura 8.13, se puede concluir que, a pesar de que en la mayoría de los atributos evaluados el nivel de aceptabilidad resultó ser satisfactorio (mayor al 80 %), sólo dos atributos influyeron negativamente en la evaluación parcial y global, a saber: “Soporte de Entrada Obligatoria” y “Soporte para Lenguajes Extranjeros”. Es decir, la evaluación global de usabilidad cayó en el nivel marginal, arrojando un valor de 74,84 %. El desempeño de estos atributos afectaron al puntaje de la sub-característica “Comprensibilidad ”, que fue marginal (73,14 %), y de la sub-característica “Operabilidad ” cuyo valor de indicador cayó a un nivel insatisfactorio (57,93 %).

Figura 8.13 Árbol de Requisitos No Funcionales. Características de usabilidad y sus atributos (en itálica). Los valores de indicadores elementales (IE) se muestran en la 3ra columna y los valores de indicadores derivados/globales se muestran en la 4ta columna.

En consecuencia, se recomendó realizar acciones de cambio principalmente sobre el atributo “Soporte de Entrada Obligatoria” ya que, sin efectuar grandes esfuerzos se podría mejorar significativamente el nivel de satisfacción alcanzado. Del mismo modo, se recomendó mejorar el atributo “Soporte para Lenguajes Extranjeros”. Vale remarcar que la ausencia de la propiedad “Soporte para Lenguajes Extranjeros” es una debilidad encontrada en LinkedIn para smartphones, la cual representa una desventaja con respecto a, por ejemplo la red social Instagram para smartphones, que sí soporta totalmente esta propiedad.

Como resultado de esta actividad se generó el documento Informe de Recomendación en el cual se especifican los atributos cuyos valores de indicadores no han alcanzado un nivel de aceptabilidad satisfactorio. Además, por cada uno de estos atributos se sugirieron una o más recomendaciones que permitieron luego, llevar a cabo acciones de cambio que aumenten el nivel de satisfacción del atributo. El informe especifica también la prioridad del cambio, es decir, cuáles recomendaciones debieron ser consideradas con carácter de urgente (A acción con prioridad alta) y cuáles con carácter de urgencia moderada (M, prioridad moderada). En la Figura 8.14 se presentan las recomendaciones sugeridas para los atributos con nivel de satisfacción inferior al óptimo (menos del 80 %) y se señala la prioridad establecida para planificar las acciones de cambio.

Figura 8.14 Extracto del documento Informe de Recomendación.

Diseñar las Acciones de Cambio

En base al Informe de Recomendación, durante la siguiente actividad que fue instanciada, esto es, A7, “Diseñar las Acciones de Cambio para la Vista de Calidad de Sistema”, se generó el documento Plan de Mejoras. Este documento indica para cada recomendación documentada, cuáles son las acciones de cambio planificadas, las fuentes de los registros de medición que dan soporte al cambio, y cómo pueden llevarse a cabo en la aplicación. El cómo implica que, para cada acción, se debe enumerar el método y/o técnica que se empleará para hacer efectiva dicha acción de cambio en la próxima actividad. A fin de ilustrar el contenido de un posible Plan de Mejoras para el caso de la evaluación de LinkedIn, la Figura 8.15 indica diferentes acciones de cambio a llevarse a cabo.

Figura 8.14 Extracto del documento Plan de Mejoras.

Implementar las Acciones de Cambio

En base al documento Plan de Mejoras, los desarrolladores realizan los cambios correspondientes en la aplicación LinkedIn, produciendo así una nueva versión, mejorada, de la misma. Las tareas involucradas en la actividad A8, “Implementar las Acciones de Cambio para la Vista de Calidad de Sistema” están relacionadas a las diferentes acciones sugeridas en el Plan de Mejoras y métodos y/o técnicas a utilizar. Por ejemplo, para el atributo Soporte para Lenguajes Extranjeros implica agregar un nuevo requisito funcional a desarrollar, mientras que para el atributo Soporte de Entrada Obligatoria se deberán llevar a cabo tareas relacionadas a re-programación y refactoring de la interface gráfica de usuario. Notar que, por tratarse LinkedIn de un producto propietario, cuya empresa no nos encomendó la evaluación de la usabilidad que se ilustró en esta prueba de concepto, las acciones de cambio recomendadas no han sido realizadas y sólo están sujetas a los requisitos no funcionales establecidos en el estudio.

8.2.3. Verificación de las metas de negocio

Cuando el proyecto de medición y evaluación termina (esto es, se completan todas las actividades que debe instanciar la estrategia para llevar a cabo la meta) se debe verificar el logro de las metas de negocio (paso 6 de la Figura 8.1). Esto se realiza por medio de la meta de necesidad de información relacionada, la cual indica “Analizar si la usabilidad ha mejorado en un 10 % luego de los cambios efectuados”. Este análisis puede implicar otros ciclos de medición-evaluación y mejora. Y, si aún no resulta en la satisfacción de la meta operativa (b), “Incrementar un 10 % la usabilidad de la aplicación en dispositivos móviles en un plazo de 8 meses”, entonces el experto puede determinar cambiar la meta de necesidad de información de medición y evaluación o bien, la meta operativa. Pues solo cuando la meta de negocio operativa (b) haya sido satisfecha y, en conjunto con otras metas de negocio a otros niveles (por ejemplo, la meta (a) a nivel táctico) contribuirán al cumplimiento o éxito de la meta de negocio estratégica planteada.

El experto, para el análisis de las metas de necesidad de información, y la consiguiente toma de decisión al respecto, puede emplear distintas técnicas. Por ejemplo, podría utilizar un modelo de agregación lógica de preferencias, particularmente el modelo LSP (Logic Scoring of Preference) [Dujmovic, 1996] para evaluar el éxito de cada meta, de acuerdo a la importancia relativa otorgada a cada una. En este caso, las metas se ponderarían y su evaluación de éxito estaría asociado no solo al cumplimiento de la misma, sino también a su importancia dentro del conjunto de metas a satisfacer.

8.3. Conclusiones

La guía de pasos establecida para el Enfoque de Evaluación de Calidad está basada en el establecimiento de metas principales y metas de soporte, en cualquier nivel organizacional, las cuales son operacionalizadas a través de proyectos específicos. Los pasos descriptos siguen en cierto modo los pasos que propone la guía de medición basada en metas [Park et al., 1996]. En el estado del arte se afirmó que dicha guía ha sido una referencia valiosa para el desarrollo de este trabajo, si bien se consideran ciertas diferencias, como por ejemplo, el empleo explícito de estrategias integradas de acuerdo al propósito de las metas de medición y de la cantidad de vistas de calidad involucradas.

Para probar la validez de los pasos propuestos para el Enfoque de Evaluación de Calidad se utilizó una prueba de concepto, definiendo un proyecto de medición, evaluación y cambio, cuya meta de necesidad de información de medición y evaluación se encuentra vinculada a una meta de negocio a nivel estratégico. La prueba de concepto sirvió también para validar las bases conceptuales de vistas de calidad y metas de negocio y proyecto, puesto que las mismas se instanciaron apropiadamente, de manera de conformar un escenario de evaluación según la prueba de concepto establecida. De este modo, se ha probado que, conceptualmente, los términos y relaciones modelados para los dominios de vistas de calidad y metas organizacionales satisfacen el alcance inicial de la investigación realizada.

A futuro, se persigue la aplicación del enfoque en alguna institución madura con cultura de gestión de la calidad, para la cual sea posible, no solo evaluar algún sistema, sino también un recurso o proceso organizacional. Además, se pretende utilizar el sistema que recomiende el patrón de estrategia adecuado para instanciar la estrategia integrada acorde a la declaración de la meta. Para este fin, el próximo capítulo describe la implementación formal de las ontologías de vistas de calidad y metas de negocio y proyecto, que servirá para el desarrollo de dicho sistema recomendador.

Capítulo 8 - Implementación de la Ontología de Vistas de Calidad y Metas de Negocio

En este capítulo se presenta la implementación y la validación preliminar, de las ontologías de vistas de calidad y metas de negocio descriptas en los Capítulos 5 y 6 respectivamente, de acuerdo a preguntas de competencia de interés.

La organización del capítulo es la siguiente:

– Sección 9.1: Describe distintas propuestas para el desarrollo de ontologías.

– Sección 9.2: Presenta la implementación de la ontología en OWL (Ontology Web Language) ¹⁷ , describiendo los pasos de acuerdo a la metodología utilizada.

– Sección 9.3: Presenta las conclusiones.

9.1. Metodologías para el Desarrollo de Ontologías

Desde el punto de vista de las ciencias de la computación, las ontologías están destinadas a capturar el conocimiento de un dominio y proveer un entendimiento consensuado del mismo, que puede ser reutilizado y compartido entre grupos y aplicaciones. Por lo tanto, las ontologías proveen un vocabulario común de un área y definen con distintos niveles de formalidad, el significado de los términos y las relaciones entre ellos.

La definición más citada del término ontología en el área de Inteligencia Artificial es la de Grüber que expresa que “una ontología es la especificación explícita de una conceptualización” [Gruber, 1995, p.908]. Borst [Borst, 1997] modifica ligeramente esta definición, añadiendo la característica de “conceptualización compartida” y reemplazando “explícita” por “formal”. Por lo tanto, a una ontología se le reconocen cuatro características principales, fundamentadas en las siguientes razones.

Especificación significa que:

– hace explícitas las suposiciones del dominio,

– clarifica el significado y permite razonamiento,

– genera un balance entre información explícita e implícita.

Formal implica que:

– el significado no es ambiguo,

– se expresa mediante un lenguaje formal,

– permite razonamiento, haciendo explícita información implícita.

Por ser una conceptualización de un dominio:

– trata sobre una parte concreta del mundo,

– permite formar una idea del dominio en la mente de las personas.

Finalmente, es compartida debido a que:

– se establece mediante consenso,

– facilita su utilización y reuso.

De acuerdo a la recopilación realizada en [Corcho et al., 2001] y [Corcho et al., 2003], una serie de enfoques han sido propuestos para el desarrollo de ontologías. Por mencionar algunos, el método de Uschold y King [Uschold y King, 1995] propone cuatro actividades: 1) la identificación del propósito de la ontología, 2) la construcción de la misma, 3) la evaluación y 4) la documentación. Durante la actividad de construcción los autores proponen capturar el conocimiento, codificarlo e integrarlo con otras ontologías. Proponen además, tres enfoques para identificar los principales conceptos en la ontología: un enfoque bottom-up que considera desde los conceptos más concretos a los más abstractos, un enfoque top-down, que considera desde los más abstractos a los más concretos o un enfoque intermedio, middle-out, que combina ambos enfoques.

Grüninger y Fox [Grüninger y Fox, 1995] por su parte, proponen identificar los escenarios principales en los cuales la ontología tendrá su aplicación. Luego se determina el alcance de la ontología a partir de un conjunto de preguntas de competencia, las cuales sirven para extraer los términos principales del dominio, sus propiedades y relaciones, junto con los axiomas de la ontología. Estos componentes son posteriormente expresados en lógica de primer orden, por lo que este es un método formal que adquiere la robustez de la lógica y puede ser usado para transformar escenarios informales en modelos computables.

METHONTOLOGY [Fernández-López et al., 1997], [López et al., 1999] es otra metodología para el desarrollo de ontologías, creada en el laboratorio de Inteligencia Artificial de la Universidad Politécnica de Madrid. Esta metodología es una de las más difundidas y permite tanto la construcción como la reutilización de ontologías o bien, proceder a la re-ingeniería de las mismas. El proceso de desarrollo identifica las siguientes actividades: especificación, conceptualización, formalización, implementación y mantenimiento. Especifica además, las técnicas usadas en cada actividad, los productos de salida y cómo deben ser evaluados. La fase de conceptualización es la principal en esta metodología.

Otra metodología reciente la constituye SABiO [Falbo, 2014]. Está basada en la metodología de Uschold y King y agrega algunas características para mejorarla, tales como un lenguaje gráfico para expresar ontologías, una clasificación de axiomas y el uso de preguntas de competencias para chequear la ontología, como propusieron Grüninger y Fox. Esta metodología ha sido usada para construir varias ontologías de dominio, principalmente su uso está destinado a ontologías fundacionales [Guizzardi et al., 2008].

Como cualquier producto software, la construcción de ontologías debe estar conducida por un proceso, por lo que se necesitan herramientas que soporten dicha construcción. Idealmente, estas herramientas deben permitir la formalización del dominio y la definición de preguntas de competencia. Por otro lado, es necesario el consenso de expertos, ya sea mediante la captura del conocimiento de fuentes reconocidas o por poner a discusión la opinión de expertos en el dominio, los conceptos y relaciones que integran la ontología. Finalmente, en la construcción de una ontología, la evaluación de la misma a partir de la verificación y validación de las preguntas de competencia es esencial. De esta manera, es posible asegurar que los conceptos, relaciones, propiedades y axiomas satisfacen el alcance requerido por la ontología. En este sentido, la pregunta “¿la ontología se está construyendo correctamente?” obedece a responder respecto a la verificación de la ontología, mientras que la pregunta “¿se está construyendo la ontología correcta?” corresponde con la validación de la misma. Para ambos casos, dicha evaluación se sostiene a partir de las preguntas de competencia [Calero et al., 2006].

En las próximas secciones se describen los pasos llevados a cabo para construir las ontologías de vistas de calidad y metas de negocio. Principalmente, el foco está puesto en la implementación y validación de dichas ontologías, siendo necesario para esto, la transformación del modelo conceptual descripto en los Capítulos 5 y 6 en un modelo formal o semi-computable a partir de un lenguaje ontológico.

9.2. Desarrollo de la Implementación

Para el desarrollo de las ontologías de vistas de calidad y de metas de negocio se consideró como referencia los pasos propuestos por la metodología METHONTOLOGY, puesto que es la metodología que provee la descripción más detallada de las actividades involucradas en el proceso de desarrollo de una ontología [Calero et al., 2006]; además de estar basada en el ciclo de vida del software propuesto por el estándar IEEE 1074 [IEEE, 1998]. Esta metodología también fue usada para desarrollar la ontología de métricas e indicadores [Martin y Olsina, 2003]. La Figura 9.1 ilustra las actividades consideradas, de acuerdo a las propuestas por METHONTOLOGY.

Figura 9.1 Pasos del ciclo de vida de la metodología METHONTOLOGY considerados en el desarrollo de las ontologías propuestas. Adaptado de: [López et al., 1999].

9.2.1. Especificación

En la etapa de especificación se consideró comprender el dominio a modelar para establecer el propósito y el alcance, además de determinar las fuentes de conocimiento utilizadas. Para el desarrollo de las ontologías presentadas en los Capítulos 5 y 6, el dominio a modelar se corresponde, por un lado, al relacionado a vistas de calidad y, por el otro, con el de metas organizacionales (de negocio y de soporte), proyectos y estrategias. Se pretende que, en conjunto con la ontología de métricas e indicadores introducida en el Capítulo 2, constituyan una fuente formal de consulta entre los participantes de proyectos de medición y evaluación en cualquier organización de software. Otro objetivo perseguido con las ontologías propuestas, es el de conformar una base de conocimiento para el diseño e implementación de un servicio web que recomiende patrones de estrategia. Dicho servicio web tiene que estar diseñado para facilitar la recomendación semántica del patrón de estrategia más adecuado según el propósito de la meta de necesidad de información de medición y evaluación a satisfacer y la cantidad de vistas de calidad involucradas en ella, tal como se ha enfatizado en capítulos previos.

El alcance de la ontología comprende conceptos relacionados a la definición de vistas de calidad y sus relaciones, además de metas de negocio y de necesidad de información; proyecto, estrategia y patrones de estrategia y, aquellos que se han considerado más relevantes a fines de relacionarlos con los términos de requisitos no funcionales de la ontología de métricas e indicadores existente. Una forma de determinar y cotejar el alcance es diseñar preguntas de competencias que la ontología debería responder. En especial, se identificaron dos preguntas de competencia, aquellas que, en primera instancia, son pertinentes resolver para el diseño de un servicio web recomendador. Las preguntas son:

– ¿Cuál es el patrón de estrategia más apropiado dada una meta de necesidad de información de medición y evaluación con un propósito de evaluación y vistas de calidad específicas?.

– ¿Cuál es la vista de calidad correcta para una súper-categoría de entidad y un foco de calidad dado?.

Las fuentes de conocimiento utilizadas para tener cierta adherencia o contraste en la especificación de los términos del dominio y las relaciones entre ellos, fueron las siguientes:

– Los trabajos de Barcellos, Falbo y Rocha: “A Wel l-Founded Software Process Behavior Ontology to Support Business Goals Monitoring in High Maturity Software Organizations” [Barcellos et al., 2010] y “A Strategy for Preparing Software Organizations for Statistical Process Control” [Barcellos et al., 2013].

– La propuesta de Basili y otros denominada GQM+ Strategies, documentada en varios trabajos, como por ejemplo “Bridging the Gap Between Business Strategy and Software Development ”[Basili et al., 2007b], “Determining the Impact of Business Strategies Using Principles from Goal-oriented Measurement ” [Basili et al., 2009], “Linking Software Development and Business Strategy Through Measurement” [Basili et al., 2010].

– El modelo para la mejora y evaluación de procesos CMMI [CMMI Product Team, 2010].

– La propuesta de Guizzardi, Falbo y Guizzardi sobre ontologías fundacionales: “Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The case of the ODE Software Process Ontology”. [Guizzardi et al., 2008].

– Las definiciones dadas por los estándares: ISO/IEC 15939 [ISO/IEC, 2007] respecto al proceso de medición del software, ISO/IEC 9126 [ISO/IEC, 2001] e ISO/IEC 25010 [ISO/IEC, 2011] relacionadas a modelos de calidad de productos software.

– El metamodelo propuesto por la OMG, Business Motivation Model (BMM) [BMM Team, 2015].

– La guía de los fundamentos para la dirección de proyectos, PMBOK [PSM, 2000].

– El trabajo de Sing y Woo: “A Methodology for Discovering Goals at Different Organizational Levels” [Singh y Woo, 2008].

– Las definiciones dadas en las formulaciones de requisitos no funcionales [Olsina y Martin, 2004], [Olsina et al., 2008b].

9.2.2. Conceptualización

La etapa de conceptualización del dominio se realizó modelando los términos y relaciones por medio de un diagrama de clases UML. A partir de las fuentes de conocimiento citadas y teniendo en cuenta el alcance y propósito de las ontologías, en el Capítulo 5 se presentó el modelo conceptual de vistas de calidad (Figura 5.1) y, en el Capítulo 6, se presentó el modelo conceptual de la ontología de metas de negocio y proyecto (Figura 6.1) que incluye además, el de vistas de calidad. Para ambas bases conceptuales se describieron los términos y las relaciones que intervienen.

9.2.3. Implementación

La formalidad del lenguaje utilizado para representar una ontología se clasifica en informal, semi-formal y formal [Calero et al., 2006]. En este sentido, las ontologías expresadas usando lenguaje natural se consideran totalmente informal, mientras que aquellas representadas usando lógica de primer orden son formales [Jasper et al., 1999]. En el medio se consideran las ontologías representadas usando diagramas de clase UML, el cual es considerado semi-formal, por presentar cierto nivel de ambigüedad y no es interpretable por las computadoras. En este caso, el nivel de formalidad a un modelo construido con un diagrama UML puede ser alcanzado usando invariantes y reglas de negocio en OCL (Object Constraint Language) ¹⁸.

Si bien los modelos conceptuales de las ontologías de vista de calidad y de metas de negocio y proyecto fueron modelados con UML, a futuro se persigue la construcción de un servicio web semántico que recomiende el patrón de estrategia adecuado para una meta de necesidad de información de medición y evaluación. Por lo tanto, tener la ontología representada como base conceptual en UML no contribuye para el procesamiento semántico. Tampoco es posible que el conocimiento que la misma embebe sea reusado y compartido por otras ontologías o agentes, aspecto que constituye un objetivo propuesto para las ontologías.

En esta sección se presenta la implementación de las ontologías de vistas de calidad y de metas de negocio en el lenguaje OWL, que constituye uno de los lenguajes estándares recomendados por la W3C (World Wide Web Consortium) ¹⁹ para la representación de conocimiento completo en la web.

Para la conversión del modelo conceptual en lenguaje UML al lenguaje OWL existen herramientas que proveen mecanismos para tal fin. A continuación se mencionan dos de las testeadas, además de la escogida para llevar a cabo la implementación de la ontología. Un análisis completo de herramientas de este tipo se discute en [Grünwald, 2011].

En [Gasevic et al., 2004] se describe una herramienta para transformar diagramas UML basada en XSLT (Extensible Stylesheet Language Transformation). El convertidor se llama UMLtoOWL ²⁰ y permite exportar modelos estereotipados con el perfil UML Ontology [Djurić et al., 2005] a XMI (XML Metadata Interchange) para luego transformarlos en OWL. Para la conversión, es necesario un procesador XSLT como por ejemplo Xalan (Java). El problema que surgió con este convertidor fue que las herramientas de modelado UML sobre las que está testeado (MagicDraw v9.5 y Poseidon for UML, Community Edition v4.0 ) son herramientas propietarias para las cuales fue bastante difícil conseguir una licencia de manera gratis o bien, versiones que, aunque de prueba, sirvieran para probar la herramienta.

La otra herramienta para convertir UML a OWL probada fue la que provee el entorno Eclipse ²¹ denominada también UMLtoOWL ²². Este trabajo es una implementación de la OMG (Object Management Group) denominada OMD (Ontology Definition Metamodel ) que usa transformaciones ATL (Atlas Transformation Language) para producir una ontología en OWL y sus individuos, a partir de un modelo UML y sus instancias. OMD ofrece un conjunto de meta modelos (UML 2.0 y OWL) y mapeos para realizar la transformación a partir de ellos. UMLtoOWL incluye dos partes: la primera está dedicada a la conversión de un modelo UML a ontología. Esto es, clases UML se mapean a clases en OWL, los atributos en propiedades de datos y las asociaciones en propiedades de objetos. La segunda parte de la transformación trata con las instancias que se definieron en el mismo diagrama de clases UML. Estas instancias se convierten en individuos en OWL. De esta manera, se permite trabajar con instancias en UML y formar la ontología con el conocimiento requerido según sea el dominio de la misma. Para ejecutar la transformación ATL es necesario el entorno Eclipse.

Finalmente, se optó por la utilización de la herramienta UMLToOWL ²³ [Grünwald, 2011] para la conversión del modelo conceptual en lenguaje UML a OWL. La misma permite transformar diagramas de clases UML construidos con las herramientas de modelado Visual Paradigm, Microsoft Visio 2010 o ArgoUML, en ontologías OWL DL (Description Logic) completamente compatibles con el editor de ontologías Protégé [Musen, 2015]. Para esto, transforma clases, clases abstractas, interfaces, atributos, relaciones (agregación, composición, asociación, generalización) y comentarios, en elementos propios de OWL. Las clases las transforma manteniendo el mismo nombre, mientras que los atributos pasan a ser propiedades de datos (data property) y las relaciones propiedades de objetos (object property).

La ontología fue implementada en el editor de ontologías Protégé versión 5.1.0 ²⁴. La mayoría de los elementos de una ontología OWL se refieren a clases, propiedades, instancias de clases y relaciones entre esas instancias. A continuación se analizará cada uno de esos elementos para un fragmento de la ontología. En el Apéndice A se expone el documento completo en OWL de la ontología.

La Figura 9.2 muestra la definición de la clase QualityView. En la misma se observa la definición de varias sub-clases denominadas restriction, que identifican clases sin nombres y representan el conjunto de cosas con al menos la cantidad que indica la cardinalidad para la propiedad. Esto significa que, por ejemplo en la definición de la clase QualityView, cada individuo (instancia) de una vista de calidad (QualityView) debe participar en una relación con una super-categoría de entidad (relación hasQualityViewEntitySuperCategoryRelation remarcada en la Figura 9.2) y con un foco de calidad (relación hasQualityViewQualityFocusRelation).

Figura 9.2 Fragmento de código OWL que implementa la clase QualityView.

Otro de los elementos son las propiedades, las cuales constituyen una relación binaria. En OWL pueden distinguirse dos tipos de propiedades:

– Propiedades de datos: son relaciones entre instancias de clases y literales RDF y tipos de datos XML Schema.

– Propiedades de objetos: son las relaciones entre instancias de dos clases.

Cuando se define una propiedad, hay maneras de restringir la relación, esto es, se puede especificar el dominio y rango. La Figura 9.3 ilustra la definición de la propiedad que relaciona una EntitySuperCategory con un QualityFocus. La propiedad hasEntitySuperCategoryQualityFocusRelation tiene como dominio EntitySuperCategory y como rango QualityFocus. Esto significa que relaciona instancias de la clase EntitySuperCategory con instancias de la clase QualityFocus. Si hubiesen múltiples dominios significa que el dominio de la propiedad es la intersección de las clases identificadas (y lo mismo para el rango).

Por otro lado, las propiedades tienen ciertas características (transitivas, simétricas, funcional, inversa e inversa funcional). Para la propiedad ilustrada en la Figura 9.3 se observa la relación inverseOf. Una relación de este tipo especifica que, si una propiedad P1 está etiquetada como owl:inverseOf P2, entonces, para todo x e y: P1(x,y) iff P2(y,x). Para el caso de la propiedad hasEntitySuperCategoryQualityFocusRelation la propiedad inversa es la que relaciona una instancia de QualityFocus con otra de EntitySuperCategory.

Figura 9.3 Fragmento de código OWL que describe la propiedad de objeto hasEntitySuperCategoryQualityFocusRelation.

Respecto a las propiedades de datos, OWL utiliza mayormente los tipos de datos de XML Schema (por ejemplo, xsd:string, xsd:boolean, xsd:integer). La Figura 9.4 ilustra la definición de una propiedad de datos para definir el atributo purpose de una meta. La propiedad hasPurpose relaciona metas (Goal ) a valores de “cualquier tipo” (anyType). Esto es debido a que la conversión que se realiza desde diagramas de clase realizados en ArgoUML no mantiene el tipo de datos utilizados (en este caso debiera ser string).

Figura 9.4 Fragmento de código OWL que describe la propiedad de dato hasPurpose para una meta.

Posteriormente se crearon instancias como miembros de una clase e implementadas como individuos de la ontología. Por ejemplo, una instancia que se creó fue la de System Quality View, la cual ilustra la Figura 9.5.

Figura 9.5 Fragmento de código OWL que describe la instacia System Quality View.

La definición de una instancia implica identificar el tipo de recurso al cual pertenece a través de rdf:type, propiedad RDF que vincula un individuo a la clase de la cual es miembro. Para el ejemplo ilustrado, la instancia System Quality View es un individuo de la clase QualityView. Además, identifica propiedades de objetos (relaciones) en las que participa. Para la instancia de System Quality View, participa en la instancia “System” de la propiedad de objeto “hasQualityViewEntitySuperCategoryRelation” y, de la instancia “External_Quality” de la propiedad de objeto “hasQualityViewQualityFocusRelation”.

9.2.4. Evaluación

Luego de crear las instancias, se procedió a validar la ontología como parte de la etapa de evaluación de la misma, infiriendo nuevas relaciones y validando las existentes. Para esto, se utilizó el razonador Pel let ²⁵ el cual viene integrado a Protegé y se caracteriza por ser el primer razonador con lógica descriptiva, completo y robusto para razonar sobre ontologías DL [Sirin et al., 2007].

Para la evaluación de la ontología, se procedió a corroborar la validez de las preguntas de competencia formuladas evaluando las respuestas obtenidas por la ontología. Las preguntas de competencia se formalizaron con el lenguaje de consultas SPARQL (acrónimo recursivo del inglés SPARQL Protocol and RDF Query Language). En la Figura 9.6 se muestra la pregunta de competencia ¿Cuál es el patrón de estrategia más apropiado dada una meta de necesidad de información de medición y evaluación con un propósito de evaluación y vistas de calidad específicas? implementada en SPARQL y la respuesta obtenida considerando una meta con propósito de “comprender” y foco de calidad “calidad externa” y súper-categoría de entidad “sistema” (vista de calidad de sistema). Por su parte, la Figura 9.7 ilustra la segunda pregunta de competencia de interés, a saber: ¿Cuál es la vista de calidad correcta para una súper-categoría de entidad y un foco de calidad dado? y su respuesta correspondiente considerando la súper-categoría de entidad “sistema” y el foco de calidad “calidad externa”.

Con estas preguntas de competencia y más instancias sobre la ontología, especialmente instancias de estrategias y sus patrones asociados, así como también de distintos propósitos de evaluación, y vistas de calidad, se puede construir un servicio web semántico que procese dichas consultas en SPARQL sobre la ontología. Por ejemplo, la librería ARC2 ²⁶ para PHP permite realizar estas consultas semánticas, tal como JENA ²⁷ , que provee un entorno de programación para RDF, RDFS, OWL y SPARQL en JAVA. Debido al alcance establecido para esta tesis, el servicio web no ha sido implementado, pero sí, uno de los objetivos de implementar la ontología en OWL era lograr la inferencia que requiere el sistema recomendador de patrones de estrategia.

Figura 9.6 Consulta en SPARQL de la pregunta de competencia ¿Cuál es el patrón de estrategia más apropiado dada una meta de necesidad de información de medición y evaluación con un propósito de evaluación y vistas de calidad específicas?.

Figura 9.7Consulta en SPARQL de la pregunta de competencia ¿Cuál es la vista de calidad correcta para una súper-categoría de entidad y un foco de calidad dado?.

9.3. Conclusiones

En este capítulo se presentó la implementación de la ontología de metas de negocio y proyecto en conjunto con la de vistas de calidad, utilizando para ello, una herramienta que transforma los modelos conceptuales UML presentados en los Capítulos 5 y 6, en lenguaje OWL.

El objetivo de implementar dichas ontologías con una representación más formal, computacionalmente procesable es, por un lado, contribuir en el área de medición y evaluación con una terminología común en el dominio de metas organizacionales, vistas de calidad, proyectos, estrategias y patrones de estrategia, que permita el procesamiento automatizado de la información así como su correcta interpretación. Por otro lado, responder las preguntas de competencia que permitan posteriormente, llevar a cabo el desarrollo de un servicio web semántico que recomiende, como ha sido expuesto, el patrón de estrategia adecuado para instanciar la estrategia integrada que corresponda para llevar a cabo una meta de necesidad de información de medición y evaluación.

Las ontologías capturan un conocimiento consensuado. En este caso, el consenso vino dado por las fuentes de referencia que han sido consultadas para la elaboración de la conceptualización del dominio y las discusiones realizadas durante un año en nuestro grupo de investigación. Contar con dicha conceptualización, tal lo analizado en los Capítulos 5 y 6, permitió definir un vocabulario consistente de términos y relaciones requeridos, de acuerdo al alcance de este trabajo. La definición formal fue realizada en el lenguaje OWL, que permitió consultar e inferir sobre la ontología a fines de validar el conocimiento explícito e implícito de la misma.

Respecto a facilitar la utilización de la ontología y su reuso, en [Barcellos et al., 2013] se define una sub-ontología similar, que contiene términos, relaciones y restricciones relacionadas al alineamiento entre medición, metas y organización. Si bien esta propuesta de ontología fue también una referencia muy valiosa al momento de consensuar los términos y relaciones de la ontología de metas organizacionales presentada en este trabajo, se distinguen algunas diferencias. Por ejemplo, los autores no describen el uso de estrategias para alcanzar las metas y la consideración de vistas de calidad, en tanto que sostienen que una manera de juzgar el nivel de logro o satisfacción de metas es a través de indicadores, que constituyen las medidas ²⁸. Al momento, no hay referencia respecto de la implementación de esta ontología en OWL. Por lo que de hallarse disponible en algún momento, sería beneficioso poder reusar parte de ella o bien compartir el conocimiento (por ejemplo, el relacionado a metas de medición y evaluación) que cada ontología provee. De este modo, es posible aportar un único corpus de conocimiento respecto a metas organizacionales de negocio y de medición y evaluación; sumando el conocimiento sobre metas de necesidad de información vinculadas a las metas de negocio y estrategias para llevarlas a cabo, que contribuye esta tesis.

Parte IV:
Conclusiones y Trabajos Futuros

Capítulo 10 - Conclusiones y Trabajos Futuros

En este capítulo se presentan las conclusiones de la tesis y trabajos futuros.

La organización del capítulo es la siguiente:

– Sección 10.1: Enumera cada objetivo establecido, cuáles preguntas de investigación resultaron respondidas con el logro de cada objetivo y qué contribución aportó cada uno, de acuerdo a las indicadas en el Capítulo 1.

– Sección 10.2: Presenta los avances que se desprenden de esta investigación y los trabajos futuros que se persiguen.

10.1. Cumplimiento de Objetivos y Contribuciones Realizadas

En esta tesis se presentó un enfoque para ser empleado en el área de medición y evaluación de la calidad, denominado Enfoque Multinivel y Multipropósito de Evaluación de la Calidad, que, para abreviar, en toda la tesis se lo identificó como Enfoque de Evaluación de Calidad. El enfoque reviste la característica de multinivel porque fomenta la vinculación de metas de negocio a distintos niveles organizacionales, en especial, aquellas establecidas a nivel operativo con las de nivel estratégico. Además de considerar el soporte a éstas por medio de metas de necesidad de información. Es también multipropósito porque las metas de necesidad de información de medición y evaluación que considera pueden tener distintos propósitos de evaluación, esencialmente, se hizo énfasis en los propósitos de comprender y mejorar una entidad. Los distintos tipos de propósitos, como ha sido expuesto, junto con las vistas de calidad, permiten determinar el patrón de estrategia que ayuda a instanciar a la estrategia integrada adecuada, recurso de utilidad para llevar a cabo metas de medición.

El Enfoque de Evaluación de Calidad puede ser utilizado en cualquier tipo de organización que realice proyectos de medición y evaluación. En particular, esta tesis ha hecho referencia a organizaciones dedicadas al desarrollo de software, que posean madurez de nivel 3 en adelante de CMMI, aunque también podrían considerarse aquellas que recién inician y certifican un nivel 2. En [Ebert y Dumke, 2007] proponen un conjunto de métricas para cada área de proceso de CMMI. La selección de las métricas fue en base a aquello que los autores consideran útil medir en cada área de proceso a partir del nivel de madurez 2. Claramente, las métricas que definen pueden ser utilizadas como métodos de medición por parte de las estrategias integradas propuestas, de acuerdo a la meta de necesidad de información de medición y evaluación que se quiera satisfacer.

Por otra parte y de acuerdo a lo analizado en el Capítulo 3, podría considerarse la utilización de BSC para la definición de metas de negocio, principalmente, a nivel estratégico. Dado que uno problema habitual en la selección de objetivos estratégicos es que suelen haber demasiados [Fernández, 2001]; los mapas estratégicos pueden ayudar a englobar y priorizarlos puesto que ayudan a valorar la importancia de cada objetivo estratégico, identificándolos en alguna de las dimensiones que propone BSC, las cuales representan dimensiones críticas y claves en una organización [Fernández, 2001].

Con el fin de introducir al lector en los fundamentos teóricos que acompañan el desarrollo del enfoque propuesto, en la sección 2.2 del Capítulo 2 se describieron los principios de estrategias integradas de medición y evaluación. Se presentaron además, tres estrategias integradas que satisfacen dichos principios, haciendo referencia, en las secciones siguientes, a cada uno de esos principios para las estrategias integradas abordadas. Posteriormente, en el Capítulo 4 se determinó que el marco conceptual C-INCAMI de las estrategias integradas de medición y evaluación contiene los términos y relaciones necesarias para modelar el dominio de requisitos no funcionales, medición, evaluación, contexto y proyecto. Pero que, al momento, no contemplaba términos del dominio de vistas de calidad, metas organizacionales, proyecto, estrategia, patrones de estrategia y las relaciones entre ellos. Dada esta observación, el capítulo concluye que, las estrategias integradas de medición y evaluación presentan las siguientes limitaciones:

1) no se instancian de acuerdo a la vista de calidad que comprende la meta de necesidad de información de medición y evaluación a satisfacer; 2) que dicha meta al presente no se relaciona con metas principales de negocio de la organización y, finalmente, 3) que la instanciación de las estrategias integradas podría beneficiarse a partir de la utilización de patrones de estrategia. Conforme a estas observaciones detectadas, los objetivos establecidos en el Capítulo 1 estuvieron destinados a resolver estas cuestiones, valiéndose del análisis del estado del arte para justificar las decisiones adoptadas en cada contribución que esta tesis aportó en el área de medición y evaluación de calidad del software. Los objetivos planteados, fueron, saber:

Ampliar la base conceptual del enfoque integral de evaluación de calidad en [Olsina et al., 2008b] para incluir terminología relacionada a vistas de calidad, metas, proyectos, estrategias y patrones de estrategia.

Formalizar la nueva base conceptual en ontologías de vistas de calidad y metas de negocio.

Especificar patrones de estrategia para generalizar el conocimiento sobre la utilización de distintas estrategias integradas de medición y evaluación.

Establecer los pasos para utilizar el nuevo Enfoque de Evaluación de Calidad.

Para cada uno de ellos, a continuación se describe, cómo se abordaron, las preguntas de investigación en las que el cumplimiento del objetivo ayudó a responder y, la manera en la que cada objetivo colaboró en alguna contribución de las que propone esta tesis. Además, se citan las principales publicaciones que dan soporte a las contribuciones.

El objetivo (1) de ampliar la base conceptual C-INCAMI fue desarrollado en el Capítulo 4, al describir la problemática detectada y la solución propuesta. Desarrollar este objetivo permitió dar respuesta a las dos primeras preguntas de investigación formuladas, a saber:

– ¿Por qué es útil considerar vistas de calidad en una meta de necesidad de información de medición y evaluación?.

– ¿Por qué es importante para una organización tener sus metas de necesidad de información de medición y evaluación (a nivel operativo) alineadas con metas de negocio de distintos niveles organizacionales?.

Respecto a la primera pregunta, en el Capítulo 3, sección 3.1, se analizaron distintos trabajos relacionados a vistas de calidad. Haciendo una analogía con el mensaje que subyace en la parábola del “elefante y los seis sabios ciegos” ²⁹, como corolario de la sección 3.1 se afirma que la calidad se puede conceptualizar desde diferentes perspectivas, todas válidas pero que resulta difícil conformar una única definición del término y la vista que del mismo se enfoque. En este sentido, uno de los autores estudiados fue Garvin, quien afirma que, la literatura respecto a calidad no ha sido revisada exhaustivamente y por tanto, el problema es considerar una sola definición y perspectiva del término. Garvin se refiere a que los académicos de cuatro disciplinas -filosofía, economía, marketing y administración-, han considerado el tema de definir la calidad, pero que cada grupo lo ha considerado desde un punto de vista distinto. Por lo tanto, el resultado ha sido la contemplación de distintas perspectivas, cada una basada en diferentes análisis y empleando su propia terminología [Garvin, 1984]. De acuerdo a esto, Garvin describe distintas vistas para definir o contemplar la calidad de un producto. Por ejemplo, en el Capítulo 3 se introdujo que, si se trata de aspectos filosóficos, entonces la calidad se considera en función de la vista trascendental o por, el contrario, si se contemplan aspectos económicos, puede tratarse de la vista basada en el producto o la vista basada en el usuario.

En esta misma dirección, los estándares ISO 9126 y 25010 abordaron lo que denominan, enfoques de calidad, identificando distintas perspectivas de las cuales es posible considerar la calidad para su evaluación, estableciendo además, relaciones de “influencia” y “depende de” entre ellas. De acuerdo a estas consideraciones que analizan Garvin y los estándares mencionados, se observó que, para una meta de necesidad de información de medición y evaluación, es importante determinar la vista de calidad que involucra. Esto es, resulta relevante saber cuál es la vista de calidad que se está considerando en la evaluación de una entidad. Precisamente, conocer cuántos y cuáles aspectos de la calidad se quieren evaluar, interesa para determinar la estrategia integrada adecuada que servirá para llevar a cabo la meta de necesidad de información de medición y evaluación.

Las razones expuestas sirvieron para considerar la inclusión de términos relacionados a vistas de calidad en el marco conceptual C-INCAMI y, conformar, lo que constituye el segundo objetivo, esto es, la ontología de vistas de calidad, presentada en el Capítulo 5.

Respecto a la segunda pregunta de investigación formulada, se ha mencionado en varios capítulos, la importancia para una organización, de tener sus metas de necesidad de información de medición y evaluación (a nivel operativo) alineadas con metas de negocio a distintos niveles organizacionales. En este sentido, diversos son los autores que sostienen que las metas de medición, establecidas a nivel organizacional operativo tienen que estar alineadas con las metas estratégicas, como por ejemplo [Schendel y Hofer, 1979], [Park et al., 1996], [Becker y Bostelman, 1999], [Goethert y Fisher, 2003], [Basili et al., 2007a], [Basili et al., 2007b], [Singh y Woo, 2008], [Basili et al., 2009], [Basili et al., 2010], [Mayes, 2012], [Barcellos et al., 2013], [Trendowicz et al., 2014].

De acuerdo a esto, se observó que la meta de necesidad de información que considera el marco conceptual C-INCAMI y que las estrategias integradas de medición y evaluación están destinadas a llevar a cabo, no se relaciona con metas de negocio a distintos niveles organizacionales. Esto es importante, si se quiere consolidar un enfoque de evaluación de la calidad integrado y multinivel, en el cual se proponga que los esfuerzos invertidos en actividades de medición y evaluación, no solo permita tomar decisiones a nivel operativo, sino que también contribuya a decisiones estratégicas [Basili et al., 2007a]. Por esta razón, se consideró incluir una nueva base conceptual al marco conceptual C-INCAMI, que modela términos de meta, necesidad de información, proyecto, estrategia y patrón de estrategia, la cual fue presentada en el Capítulo 6. La base conceptual se estructuró en forma de ontología -la ontología de metas de negocio y de proyecto- que fundamenta el segundo objetivo de la presente tesis, discutido a continuación.

El objetivo (2) establece la formalización, estructurada en ontología, de las nuevas bases conceptuales de vistas de calidad y de metas de negocio y de proyecto. La ontología de vistas de calidad fue presentada en el Capítulo 5. Como parte de su conceptualización, se especificaron los términos, atributos y relaciones que intervienen. Por su parte, la ontología de metas de negocio y proyecto fue presentada en el Capítulo 6, describiendo también, sus términos, atributos y relaciones. Las bases conceptuales han sido formalizadas en ontologías puesto que las mismas constituyen una forma especial de modelos conceptuales y su rol primario es ser interpretables y procesables por las máquinas, de tal manera que las computadoras puedan razonar sobre los modelos [Gruber, 1995]. Por esta razón, dichas ontologías fueron implementadas en lenguaje OWL y el desarrollo de su implementación, junto con la validación a través de preguntas de competencia de interés en esta instancia de la investigación, fueron presentadas en el Capítulo 9. Si bien esta tesis no está centrada pura y exclusivamente en la implementación formal de la ontología (sino más bien en la conceptualización y definición de los términos y las relaciones que la conforman), fue conveniente su transformación (de los modelos conceptuales construidos con UML presentados en los Capítulos 5 y 6) a un lenguaje computable para continuar con otras investigaciones relacionadas, las cuales se detallarán como parte de los trabajos futuros.

El desarrollo del objetivo (2), esto es, consolidar las bases conceptuales añadidas al marco C-INCAMI, en forma de ontologías, permitió dar respuesta a las siguientes preguntas de investigación:

– ¿Qué relación puede establecerse entre una meta operativa de necesidad de información de medición y evaluación y las metas de negocio?.

– ¿Cómo se puede elegir la estrategia integrada adecuada para satisfacer una meta de necesidad de información de medición y evaluación?.

Respecto a la primera pregunta, la conceptualización del dominio de metas de negocio y de proyecto permitió comprender que una meta de negocio está soportada por una meta de necesidad de información, la cual, en un enfoque de evaluación orientado a metas, está destinada a satisfacer la pregunta inicial de ¿qué quiero aprender/comprender? tal como se señala en [Park et al., 1996]. Por lo tanto, una meta de necesidad de información controla el progreso de alcance de metas de negocio y verifican si están siendo alcanzadas [Barcellos et al., 2013]. En el Enfoque de Evaluación de Calidad presentado, una meta de necesidad de información puede requerir para la verificación de las metas principales de negocio, de metas de necesidad de información de medición y evaluación. En particular, estas metas constituyen un tipo de meta de necesidad de información, que son operacionalizadas por medio de proyectos de medición y evaluación y/o cambio. Requerir de estas metas implica que se necesita obtener datos cuantitativos, a partir de actividades de medición y evaluación que sirven para la toma de decisión y colaboran en la satisfacción de las metas de niveles mayores, las cuales estaban vinculadas. Además, para llevar a cabo estas metas se requiere la instanciación de la estrategia integrada adecuada, de acuerdo al patrón de estrategia acorde a utilizar.

Por otra parte, se determinó que una meta de negocio es operacionalizada por un proyecto y puede estar formada por otras sub-metas, las cuales se establecen a distintos niveles organizacionales, sin dejar todas de estar asociadas a una meta de necesidad de información que permite analizar si dichas metas de negocio se cumplieron.

En el análisis del estado del arte se concluyó que al momento, no existen propuestas de bases conceptuales que integren términos de metas de negocio, proyecto y estrategia. En los enfoques de evaluación de calidad multinivel y estrategias de medición y evaluación analizados, algunos de ellos consideran el alineamiento de metas, en especial, las de medición con aquellas formuladas a nivel estratégico. Aunque no determinan distintos tipos de metas y no especifican formalmente, por ejemplo como ontologías, la conceptualización del dominio de metas organizacionales. Una propuesta que se asemeja es [Barcellos et al., 2013], trabajo en el cual se presenta una sub-ontología de metas de medición. En esta sub-ontología (tal como la denominan los autores por ser parte de un conjunto de otras ontologías relacionadas) se distinguen como tipos de metas a metas de medición, metas de software y metas de negocio, dejando la posibilidad de incluir nuevos tipos de metas. Distinguen también a la necesidad de información, pero identificada a partir de las metas (de algunos de los tipos mencionados), desempeñando el papel de metas de soporte de algún modo, aunque explícitamente no lo establecen.

En cuanto a la pregunta de investigación ¿Cómo se puede elegir la estrategia integrada adecuada para satisfacer una meta de necesidad de información de medición y evaluación?, haber especificado distintas vistas de calidad, a partir de la categoría de entidad y foco de calidad de la meta necesidad de información de medición y evaluación, junto con la identificación del tipo de propósito de evaluación (como comprender o mejorar) permitió establecer los criterios involucrados en la selección de la estrategia adecuada para llevar a cabo dichas metas. En el Capítulo 2 se describieron los procesos de tres estrategias integradas, GOCAME, SIQinU y GOCAMEC, cada una destinada a satisfacer metas de necesidad de información de medición y evaluación con distintos propósitos. Cada una de las estrategias integradas especifica un proceso en el cual se detalla las actividades necesarias a llevar a cabo para la meta de necesidad de información de medición y evaluación y su propósito de evaluación. Claramente, la consideración de las vistas de calidad para elegir la estrategia es importante, como se ha ya destacado, puesto que la estrategia integrada tiene que ser la adecuada de acuerdo a la cantidad de vistas de calidad que la meta incluya y los tipos de propósitos, tal como se analizó en el Capítulo 7. De acuerdo a esto será el proceso que deberá llevarse a cabo junto con los métodos propios necesarios y, esto variará de acuerdo a la estrategia integrada que sea.

Una de las estrategias de medición más popularizadas la constituyen GQM y GQM⁺ Strategies. En el análisis efectuado en el estado del arte respecto a las mismas, se concluye que no queda explícito específicamente cuales metas satisfacen, en especial, GQM⁺ Strategies, que contempla metas a distintos niveles organizacionales. Tampoco la consideración de vistas de calidad, aunque los elementos que conforman a GQM son: el objeto a medir, el propósito, el foco, el ambiente y el punto de vista. En la propuesta de esta tesis, el objeto (la entidad, en este caso) asociado al foco determina la vista de calidad.

Desarrollar el objetivo (2) permitió documentar dos contribuciones de las mencionadas en el Capítulo 1. Por un lado, contar con una ontología de vistas de calidad y, por otro, con una de metas de negocio y de proyecto. Las publicaciones que respaldan estas contribuciones son: [Olsina et al., 2011a], [Olsina et al., 2012], [Rivera et al., 2015d], [Rivera et al., 2016a], [Rivera et al., 2016b], [Rivera et al., 2016c] y [Rivera et al., 2016d].

El objetivo (3) propone la especificación de patrones de estrategia para generalizar el conocimiento sobre la utilización de distintas estrategias integradas de medición y evaluación. El Capítulo 7 aborda este objetivo planteando la idea que, la instanciación de estrategias integradas puede realizarse a partir de patrones de estrategias, debido a que se observa que hay situaciones similares, donde la misma estrategia se aplica. El desarrollo de este objetivo permitió dar respuesta a la pregunta de investigación:

– ¿Qué beneficios acarrearía el uso de patrones de estrategia para instanciar estrategias integradas de medición y evaluación.

Si bien la utilización de patrones (especialmente los de diseño) es ampliamente difundida y promovida en Ingeniería de Software y Web, en el área de medición y evaluación de la calidad, son pocas las propuestas que describen soluciones de este estilo. En el Capítulo 3 se abordaron algunos trabajos relacionados a la instanciación de patrones cuando se trata de actividades de aseguramiento de calidad (como por ejemplo, la propuesta de [Lindvall et al., 2005] para la utilización de patrones en la creación de programas de medición). Si bien todos ellos resultan útiles de acuerdo a la intención dada por los autores, ninguno hace referencia a instanciar estrategias integradas que lleven a cabo metas de necesidades de información de medición y evaluación.

En el Capítulo 7 se han descripto tres patrones de estrategia para metas de necesidad de información de medición y evaluación que comprenden distintas cantidades de vistas de calidad y los propósitos de evaluación de comprender y mejorar. Para esto, el modelado de vistas de calidad y sus relaciones fue de especial importancia puesto que ayudó a desarrollar una familia de patrones de estrategia, a partir de sus relaciones de “influencia” y “depende de”. Los patrones fueron especificados de acuerdo a los items de una plantilla, similar a la que propone Gamma para la utilización de patrones de diseño. El ítem estructura (solución) de la plantilla se expresa en términos de un curso de acción genérico, un marco conceptual de dominio y la especificación de métodos, los tres pilares que conforman una estrategia integrada.

El desarrollo de este objetivo permitió documentar otra de las contribuciones de las presentadas en esta tesis, esto es, contar con un conjunto de patrones de estrategia que permiten la instanciación de distintas estrategias integradas para resolver el propósito de metas de necesidad de información de medición y evaluación. Estos patrones son útiles de aplicarse en proyectos de medición, evaluación y aún aquellos que contemplen cambio. Las publicaciones que respaldan esta contribución son: [Rivera et al., 2015a], [Rivera et al., 2015b], [Rivera et al., 2015c], [Papa et al., 2015], [Rivera et al., 2016a], [Rivera et al., 2016b] y [Papa et al., 2016].

Finalmente, el objetivo (4) fue desarrollado en el Capítulo 8. En el mismo, se detallaron los pasos implicados en el establecimiento de metas de negocio, metas de necesidad de información y, en especial, el desarrollo de cómo se lleva a cabo una meta de necesidad de información de medición y evaluación operacionalizada por un proyecto de medición, evaluación y cambio correspondiente. Para esta meta, se propone la utilización de estrategias integradas a partir de la instanciación del patrón de estrategia adecuado.

El desarrollo de los pasos del Enfoque de Evaluación de Calidad puede ser aplicado en organizaciones en las cuales los niveles organizacionales varíen el grado de abstracción y desempeño allí realizado. Establecer los pasos del Enfoque de Evaluación de Calidad que considera todos los aspectos abordados en esta tesis (vistas de calidad, metas de negocio y de necesidad de información, estrategias, patrones de estrategia y proyectos) permitió consolidar un enfoque de medición, evaluación y mejora de la calidad que provea soporte a metas de negocio y de necesidad de información a distintos niveles organizacionales y la aplicación de estrategias por medio de la instanciación de patrones de estrategia, aportando de este modo, la ultima contribución de la presente investigación, indicada en el Capítulo 1. Las publicaciones que respaldan esta contribución son: [Rivera et al., 2014], [Rivera et al., 2016b] y [Rivera et al., 2016c].

En conclusión, el objetivo general de esta tesis estuvo centrado en consolidar el Enfoque Multinivel y Multipropósito de Evaluación de la Calidad que permite considerar los aspectos analizados para cada objetivo que, en general, en la literatura revisada, no se hallan integrados.

10.2. Trabajos Futuros

A partir del desarrollo del Enfoque Multinivel y Multipropósito de Evaluación de la Calidad presentado en esta tesis, se desprenden trabajos futuros relacionados (algunos ya en marcha), que se mencionan a continuación:

Un sistema que recomiende el patrón de estrategia adecuado, de acuerdo a la cantidad de vistas de calidad y el tipo de propósito de evaluación de la meta de necesidad de información de medición y evaluación. Para esto, la implementación en OWL de las ontologías de vistas de calidad y metas de negocio y proyecto (presentada en el Capítulo 9) constituye el punto inicial para este desarrollo. De aquí en más, se espera avanzar en este sistema como un servicio web que pueda ser empleado por organizaciones que lleven a cabo proyectos de medición, evaluación y/o cambio. De esta manera, se pretende consolidar un servicio que permita determinar, cuál es el patrón de estrategia que instancie la estrategia integrada que más se adapte para llevar a cabo la meta de necesidad de información de medición y evaluación de un proyecto específico.

En la misma línea referida a patrones de estrategia, otro trabajo que se prevee continuar es el relacionado a la especificación de otros patrones de estrategia. Para esto, y tal lo presentado en el Capítulo 7, se propone desarrollar los patrones de estrategia GoME_2QV y GoMEC_3QV, instanciándolos para casos de prueba que consideren evaluar aspectos de usabilidad y seguridad en un sistema de gestión de la información.

El Enfoque de Evaluación de Calidad propuesto considera para la evaluación, metas de medición y evaluación de requisitos no funcionales de calidad, aunque podrían ser de costo también. En este sentido, se está trabajando en el desarrollo de una estrategia integrada que contemple la selección de alternativas considerando características y atributos de calidad y factores de costo. Esto significa que la estrategia llevará a cabo metas operativas con el propósito similar a “seleccionar la mejor alternativa considerando calidad y costo”. Las entidades a evaluar serán un conjunto de entidades competitivas pre-seleccionadas que constituyen las alternativas a evaluar a fin de seleccionar aquella que mejor satisfaga la relación calidad-costo.

Se trabajará también para que el Enfoque de Evaluación de Calidad considere requisitos funcionales. Al momento, se ha descripto la aplicación del enfoque en consideración de proyectos de medición y evaluación (y aquellos que también incluyen cambio) que consideran la evaluación de requisitos no funcionales para una entidad particular. Sin embargo, y tal como se ha descripto en los pasos del enfoque detallado en el Capítulo 8, otros tipos de proyectos que operacionalizan metas a distintos niveles organizacionales, pueden ser considerados. Un caso lo constituyen los proyectos de desarrollo y, para esto, se propone modelar la sub-ontología de requisitos funcionales y vincular sus términos con aquellos relacionados a metas de negocio y requisitos no funcionales (tales como entidad, atributo).

Finalmente, el Enfoque de Evaluación de Calidad no solo puede ser empleado para metas de necesidad de información de medición y evaluación que tengan como propósito comprender o mejorar, tal como se ha detallado en el desarrollo de la tesis. De hecho, los patrones de estrategia especificados contemplan únicamente esos propósitos. Sin embargo, existen muchos otros propósitos de evaluación, como por ejemplo, los documentados en [Preece y Rombach, 1994], [Briand et al., 1996], [Fenton y Pfleeger, 1998], [Briand et al., 2002], [INCOSE, 2010], [PMI, 2013], [BMM Team, 2015] y [Rivera et al., 2016b] que se refieren a caracterizar, predecir, monitorear, controlar, comparar, seleccionar, entre otros. Revisando la literatura al respecto, se observa que, al momento, no siempre existe un amplio consenso en algunas de las definiciones de los propósitos que cada trabajo emplea. En vista a esto, se está trabajando en una categorización de propósitos de evaluación [Olsina y Becker, 2017] que aporte claridad y mayor entendimiento a los objetivos de los diferentes propósitos, dejando las categorías abiertas para la inclusión de nuevos propósitos que no han sido tenidos en cuenta.

La consideración de otros propósitos de evaluación permitirá el diseño de nuevos patrones de estrategia que permitan instanciar nuevas estrategias integradas, cada una con un proceso y métodos específicos para llevar a cabo metas de necesidad de información de medición y evaluación con estos tipos de propósitos. En este sentido, otros integrantes del grupo de investigación se encuentran trabajando en una estrategia integrada que ayude a alcanzar el propósito de comparar y adoptar fortalezas de diferentes entidades a ser adoptadas en una nueva entidad.

Notas

1 En la Parte II de esta tesis se abordarán dichas estrategias como parte del análisis del estado del arte.

2 www.amazon.com. Consultado: Febrero 2017.

3 Estas relaciones serán estudiadas en el Capítulo 3, en el análisis del estado del arte respecto a vistas de calidad.

4 www.atlassian.com/software/jira/. Consultado: Febrero 2017.

5 En [Rivera et al., 2014] esta estrategia se denomina GOCAME+ , posteriormente su nombre fue reemplazado por GOCAMEC (Goal-Oriented Context Aware Measurement, Evaluation and Change) dado que la misma, a diferencia de GOCAME, incluye actividades de cambio para una vista de calidad.

6 https://www.w3.org/RDF/. Consultado: Febrero 2017.

7 http://www.omg.org/spec/SPEM/2.0/. Consultado: Marzo 2017.

8 En realidad son las métricas de GQM, pero los autores prefieren utilizar el término “medida” debido a que, según su criterio, ésta tiene una definición más aceptada que el término “métrica”.

9 El lector puede consultar el componente de Requisitos No Funcionales del marco conceptual C-INCAMI (Figura 2.4) para corroborar que no está explícito cómo se deriva una necesidad de información de medición y evaluación (Information Need ).

10 Como parte de los trabajos futuros que siguen al desarrollo de esta tesis, se está avanzando en una categorización de propósitos de evaluación.

11 Se trataba de la aplicación mashup woozor.com relacionada a datos metereológicos.

12 http://www.bpmn.org/. Consultado: Junio 2017.

13 www.statista.com/topics/951/linkedin/. Consultado: Junio 2017.

14 El estudio se llevó a cabo en Junio del 2016, por lo que a la fecha, la versión seguramente ha variado.

15 Para cada característica del árbol de requisitos (Comprensibilidad, Facilidad de Aprendizaje, Operabilidad y Protección a Errores de Usuario) las sub-características y atributos se establecieron considerando aspectos que la literatura (como por ejemplo [Nielsen, 1994] o [Norman, 2013]) menciona como buenas prácticas de diseño para lograr una mayor usabilidad.

16 Se describirá la prueba de concepto en función de uno de estos tres atributos mencionados. El diseño del resto de los atributos se describe en [Tebes et al., 2016], trabajo realizado por becarios que colaboran con la investigación.

17 https://www.w3.org/OWL/. Consultado: Junio 2017.

18 https://www.omg.org/sec/OCL/. Consultado: Junio 2017.

19 www.w3.org. Consultado: Junio 2017.

20 www.sfu.ca/dgasevic/projects/UMLtoOWL/. Consultado: Diciembre 2016.

21 www.eclipse.org. Consultado: Julio 2017.

22 www.eclipse.org/atl/usecases/ODMImplementation. Consultado: Diciembre 2016.

23 Disponible para la descarga en https://bitbucket.org/agruenwald/umltuowl/downloads. Consultado: Diciembre 2016.

24 Disponible en http://protege.stanford.edu/. Consultado: Diciembre 2016.

25 En www.owl.cs.manchester.ac.uk/tools/list-of-reasoners/ se encuentra una lista actualizada de razonadores. Consultado: Junio 2017.

26 www.semanticweb.org/wiki/ARC. Consultado: Junio 2017.

27 http://jena.apache.org/index.html. Consultado: Junio 2017.

28 A lo largo de esta tesis se ha resaltado la diferencia entre éste uso de indicador y el propuesto en [Olsina et al., 2008b] basado en considerar que un indicador contribuye a conocer el nivel de satisfacción alcanzado para los atributos y características de una entidad medida y evaluada.

29 Parábola originaria de la India, atribuida a Rumi, sufí persa del siglo XIII, quien incluyó en su masnavi, una versión del relato llamada “El elefante en la oscuridad ” [Ru¯m¯ı, 1993]. La historia ha sido utilizada para ilustrar la incapacidad del hombre para conocer la totalidad de la realidad.

Referencias

Abran, A., April, A., y Buglione, L. (2011). Software Measurement Body of Knowledge. Encyclopedia of Software Engineering, páginas 1–12.

Alexander, C., Ishikawa, S., Silverstein, M., i Ramió, J. R., Jacobson, M., y Fiksdahl-King, I. (1977). A Pattern Language. Oxford University Press, ISBN: 9780195019193.

Baffini, M., Rivera, B., y Olsina, L. (2006). Sistema Colaborativo de Revisión de Métricas. En III Workshop de Ingeniería de Software y Bases de Datos, XII CACIC, San Luis, Argentina.

Barcellos, M. y Falbo, R. (2009). Using a Foundational Ontology for Reengineering a Software Enterprise Ontology. En Heuser, C. A. y Pernul, G., editors, Advances in Conceptual Modeling - Chal lenging Perspectives: ER 2009 Workshops CoMoL, ETheCoM, FP-UML, MOST-ONISW, QoIS, RIGiM, SeCoGIS, Gramado, Brazil, páginas 179–188. Springer Berlin Heidelberg, ISBN: 978-3-642-04947-7, doi:10.1007/978-3-642-04947-7_22.

Barcellos, M., Falbo, R., y Dal Moro, R. (2010). A Well-Founded Software Measurement Ontology. En Proceedings of the 6 th International Conference on Formal Ontology in Information Systems (FOIS 2010), páginas 213–226. IOS Press, ISBN: 978-1-60750-534-1.

Barcellos, M., Falbo, R., y Rocha, A. R. (2013). A Strategy for Preparing Software Organizations for Statistical Process Control. Journal of the Brazilian Computer Society, 19(4):445–473, doi:10.1007/s13173-013-0106-x.

Basili, V., Heidrich, J., Lindvall, M., Münch, J., Regardie, M., Rombach, D., Seaman, C., y Trendowicz, A. (2007a). GQM+ Strategies: A Comprehensive Methodology For Aligning Business Strategies With Software Measurement. En MetriKon 2007: Proceedings of th DASMA Software Metric Congress.

Basili, V., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Münch, J., Rombach, D., y Trendowicz, A. (2007b). Bridging the Gap Between Business Strategy And Software Development. En Proceedings of the International Conference on Information Systems, ICIS 2007.

Basili, V. R. (1985). Quantitative Evaluation of Software Methodology. Technical report, DTIC Document.

Basili, V. R. (1989). Software Development: A Paradigm for the Future. En Proceedings of the 13 th Annual International Computer Software and Applications Conference (COMPSAC), páginas 471–485. IEEE, doi:10.1109/CMPSAC.1989.65127.

Basili, V. R. y Caldiera, G. (1995). Improve Software Quality by Reusing Knowledge and Experience. MIT Sloan Management Review, 37(1):55–64, ISSN: 0019-848X.

Basili, V. R., Heidrich, J., Lindvall, M., Münch, J., Seanian, C., Regardie, M., y Trendowicz, A. (2009). Determining the Impact of Business Strategies Using Principles from Goal-Oriented Measurement. En Proceedings of the 9 Internationale Tagung Wirtschaftsinformatik (WI 2009), páginas 545–554.

Basili, V. R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Münch, J., Rombach, D., y Trendowicz, A. (2010). Linking Software Development and Business Strategy Through Measurement. IEEE Computer, 43(4):57–65, ISSN: 0018-9162, doi:10.1109/MC.2010.108.

Basili, V. R. y Weiss, D. M. (1984). A Methodology for Collecting Valid Software Engineering Data. IEEE Transactions on Software Engineering, 10(6):728–738, doi:10.1109/TSE.1984.5010301.

Baskerville, R., Levine, L., Pries-Heje, J., y Slaughter, S. (2001). How Internet Software Companies Negotiate Quality. IEEE Computer, 34(5):51–57, ISSN: 0018-9162, doi:10.1109/2.920612.

Bassman, M., McGarry, F., y Pajerski, R. (1995). Software Measurement Guidebook-Revision 1 (Software Engineering Laboratory Series). Technical report, SEL-94-102, NASA GSFC, Greenbelt.

Becker, P. (2014). Visión de Proceso Estrategias Integradas de Medición y Evaluación de Calidad. PhD thesis, Universidad Nacional de La Plata.

Becker, P., Lew, P., y Olsina, L. (2011). Strategy to Improve Quality for Software Applications: A Process View. En Proceedings of the 2011 International Conference on Software and Systems Process, páginas 129–138. ACM, ISBN: 978-1-4503-0730-7, doi:10.1145/1987875.1987897.

Becker, P., Lew, P., y Olsina, L. (2012). Specifying Process Views for a Measurement, Evaluation, and Improvement Strategy. Advances in Software Engineering-Special Issue on Software Quality Assurance Methodologies and Techniques, 2:27, doi:10.1155/2012/949746.

Becker, P., Papa, F., y Olsina, L. (2015). Process Ontology Specification for Enhancing the Process Compliance of a Measurement and Evaluation Strategy. CLEI Electronic Journal, 18(1):3–3, ISSN: 0717-5000.

Becker, P., Rivera, B., Papa, F., Santos, L., y Olsina, L. (2016). Escenarios de Metas de Negocio y de Necesidad de Información de Nivel Operativo Soportadas por Estrategias Basadas en Medición, Evaluación y Cambio. En IX Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNAIISI), páginas 1–14. ISSN: 2347-0372.

Becker, S. A. y Bostelman, M. L. (1999). Aligning Strategic and Project Measurement Systems. IEEE Software, 16(3):46–51.

Becker, U., Hamann, D., y Verlage, M. (1997). Descriptive Modeling of Software Processes. En Proceedings of the 3 rd Conference on Software Process Improvement.

Bertoa, M. F., Vallecillo, A., y García, F. (2006). An Ontology for Software Measurement. En Calero, C., Ruiz, F., y Piattini, M., editors, Ontologies for Software Engineering and Software Technology, páginas 175–196. Springer Berlin Heidelberg, ISBN: 978-3-540-34517-6, doi:10.1007/3-540-34518-3_6.

Besanko, D., Dranove, D., Shanley, M., y Schaefer, S. (2009). Economics of Strategy. John Wiley & Sons.

Bianchi, A. J. (2001). Management Indicators Model to Evaluate Performance of IT Organizations. En Management of Engineering and Technology, 2001. PICMET’01. Portland International Conference on, páginas 217–229. IEEE, doi:10.1109/PICMET.2001.952021.

Bider, I., Johannesson, P., Nurcan, S., et al. (2005). A Strategy Driven Business Process Modelling Approach. Business Process Management Journal, 11(6):628–649, doi:10.1108/14637150510630828.

BMM Team (2015). Business Motivation Model (BMM) Specification. Ver. 1.3. Technical Report OMG Document Number: formal/2015-05-19.

Borst, W. N. (1997). Construction of Engineering Ontologies for Knowledge Sharing and Reuse. PhD thesis, ISBN: 90-365-0988-2.

Bourque, P., Fairley, R. E., et al. (2014). Guide to the Software Engineering Body of Knowledge (SWEBOK (R)): Version 3.0. IEEE Computer Society Press, ISBN: 0769551661 9780769551661.

Briand, L. C., Differding, C. M., y Rombach, H. D. (1996). Practical Guidelines for Measurement-Based Process Improvement. Software Process Improvement and Practice, 2(4):253–280, doi:10.1002/(SICI)1099-1670(199612)2:4<253::AID-SPIP53>3.0.CO;2-G.

Briand, L. C., Morasca, S., y Basili, V. R. (2002). An Operational Process for Goal-Driven Definition of Measures. IEEE Transactions on Software Engineering, 28(12):1106–1125, ISSN: 0098-5589, doi:10.1109/TSE.2002.1158285.

Buglione, L. y Abran, A. (2000). Balanced Scorecards and GQM: What are the Differences. En Proceedings of the 3 rd European Software Measurement Conference (FESMA-AEMES 2000), páginas 18–20.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., y Stal, M. (1996). Pattern-Oriented Software Architecture - Volume 1: A System of Patterns. Wiley Publishing, ISBN: 0471958697.

Caldiera, G., Basili, V. R., y Rombach, H. D. (1994). Goal Question Metric Paradigm. Encyclopedia of Software Engineering, 1:528–532.

Calero, C., Ruiz, F., y Piattini, M. (2006). Ontologies for Software Engineering and Software Technology. Springer Science & Business Media.

Card, D. (2003). Integrating Practical Software Measurement and the Balanced Scoreboard. En Proceedings 27 th Annual International Computer Software and Applications Conference. COMPAC 2003, páginas 362–363. IEEE, ISSN: 0730-3157, doi:10.1109/CMPSAC.2003.1245366.

CMMI Product Team (2010). CMMI® for Development. Version 1.3. Improving Processes for Developing Better Products and Services. no. CMU/SEI-2010-TR-033. Software Engineering Institute.

Coplien, J. (1998). C++ Idioms. En EuroPLoP, páginas 11–34.

Corcho, O., Fernández-López, M., y Gómez-Pérez, A. (2001). OntoWeb-Technical Roadmap v. 1.0. Universität Madrid.

Corcho, O., Fernández-López, M., y Gómez-Pérez, A. (2003). Methodologies, Tools and Languages for Building Ontologies. Where is Their Meeting Point? Data and Knowledge Engineering, 46(1):41–64, ISSN: 0169-023X, doi:10.1016/S0169-023X(02)00195-7.

Curtis, B., Kellner, M. I., y Over, J. (1992). Process Modeling. Communications of the ACM, 35(9):75–90, ISSN: 0001-0782, doi:10.1145/130994.130998.

Curtius, E. (1962). Historia de Grecia, volume 2. Ediciones Siglo Veinte.

Deming, W. E. (1986). Out of the Crisis. Massachusetts Institute of Technology (MIT). Center for Advanced Engineering Study.

Djurić, D., Gašević, D., Devedžić, V., y Damjanović, V. (2005). En Model Driven Architecture: European MDA Workshops: Foundations and Applications, MDAFA 2003 and MDAFA 2004, Twente, The Netherlands, June 26-27, 2003 and Linköping, Sweden, June 10-11, 2004. Revised Selected Papers, chapter A UML profile for OWL Ontologies, páginas 204–219. Springer Berlin Heidelberg, ISBN: 978-3-540-31819-4, doi:10.1007/11538097_14.

Doran, G. T. (1981). There’s a SMART Way to Write Management’s Goals and Objectives. Management review, 70(11):35–36.

Dujmovic, J. (1996). A Method for Evaluation and Selection of Complex Hardware and Software Systems. En Proceedings 22 nd International Conference for the Resource Management and Performance Evaluation of Enterprise, páginas 368–378.

Duncan, W. R. (1996). A Guide to the Project Management Body of Knowledge. Project Management Institute.

Ebert, C. y Dumke, R. (2007). Software Measurement: Establish-Extract-Evaluate-Execute. Springer-Verlag Berlin Heidelberg, ISBN: 978-3-540-71648-8, doi:10.1007/978-3-540-71649-5.

Epstein, M. y Manzoni, J.-F. (1998). Implementing Corporate Strategy: From Tableaux de Bord to Balanced Scorecards. European Management Journal, 16(2):190–203, doi:10.1016/S0263-2373(97)00087-X.

Falbo, R. (2014). SABiO: Systematic Approach for Building Ontologies. En ONTO. COM/ODISE@ F OIS.

Fenton, N. E. y Pfleeger, S. L. (1998). Software Metrics: A Rigorous and Practical Approach. PWS Publishing Company, 2nd edition, ISBN: 0534954251.

Fernández, A. (2001). El Balanced Scorecard: Ayudando a Implantar la Estrategia. IESE-Universidad de Navarra-Revista de antiguos alumnos, páginas 31–42.

Fernández-López, M., Gómez-Pérez, A., y Juristo, N. (1997). Methontology: From Ontological Art Towards Ontological Engineering. En Proceedings of the Ontological Engineering AAAI-97 Spring Symposium Series, páginas 33–40. American Asociation for Artificial Intelligence, http://oa.upm.es/5484/.

Folmer, E. y Bosch, J. (2010). Experiences with Software Architecture Analysis of Usability. En Web Engineering Advancements and Trends: Building New Dimensions of Information Technology, páginas 177–202. IGI Global.

Folmer, E., Van Gurp, J., y Bosch, J. (2003). A Framework for Capturing the Relationship Between Usability and Software Architecture. Software Process: Improvement and Practice, 8(2):67–87, ISSN: 1099-1670, doi:10.1002/spip.171.

Gamma, E., Helm, R., Johnson, R., y Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addisson-Wesley, ISBN: 0-201-63361-2.

García, F., Bertoa, M. F., Calero, C., Vallecillo, A., Ruíz, F., Piattini, M., y Genero, M. (2006). Towards a Consistent Terminology for Software Measurement. Information and Software Technology, 48(8):631–644, ISSN: 0950-5849, doi:10.1016/j.infsof.2005.07.001.

Garvin, D. A. (1984). What Does “Product Quality” Really Mean? Sloan Management Review, 26:25–45.

Gasevic, D., Djuric, D., Devedzic, V., y Damjanovic, V. (2004). From UML to Ready-to-Use OWL Ontologies. En Proceedings 2 nd International IEEE Conference Intel ligent Systems, volume 2, páginas 485–490. IEEE, doi:10.1109/IS.2004.1344798.

Gilb, T. y Finzi, S. (1988). Principles of Software Engineering Management, volume 11. Addison-Wesley.

Goethert, W. y Fisher, M. (2003). Deriving Enterprise-Based Measures Using the Balanced Scorecard and Goal-Driven Measurement Techniques. Technical Report CMU/SEI-2003-TN-024, Software Engineering Institute (SEI).

Goethert, W. y Hayes, W. (2001). Experiences in Implementing Measurement Programs. Technical Report CMU/SEI-2001-TN-026, Software Engineering Institute (SEI).

Goethert, W. y Siviy, J. M. (2004). Applications of the Indicator Template for Measurement and Analysis. Technical Report CMU/SEI-2004-TN-024, Software Engineering Institute (SEI), http://resources.sei.cmu.edu/library/asset-view.cfm? AssetID=6969.

Gruber, T. R. (1995). Toward Principles for the Design of Ontologies Used for Knowledge Sharing? International Journal of Human-Computer Studies, 43(5-6):907–928, ISSN: 1071-5819, doi:10.1006/ijhc.1995.1081.

Grüninger, M. y Fox, M. S. (1995). Methodology for the Design and Evaluation of Ontologies. En Proceedings Workshop on Basic Ontological Issues in Knowledge Sharing.

Grünwald, A. (2011). Evaluation of UML to OWL Approaches and Implementation of a Transformation Tool for Visual Paradigm and MS Visio. Technical report, Vienna, AT: Vienna University of Technology.

Guizzardi, G., Falbo, R., y Guizzardi, R. S. (2008). Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The case of the ODE Software Process Ontology. En XI Conferencia Iberoamericana de Software Engineering (CIbSE 2008), páginas 127–140.

Hansen, K. M., Jonasson, K., y Neukirchen, H. (2011). An Empirical Study of Software Architectures’ Effect on Product Quality. Journal of Systems and Software, 84(7):1233–1243, doi:10.1016/j.jss.2011.02.037.

Hax, A. C., Majluf, N. S., et al. (1986). Strategy and the Strategy Formation Process. Sloan School of Management, Massachusetts Institute of Technology-MIT.

Houdek, F. y Kempter, H. (1997). Quality Patterns — An Approach to Packaging Software Engineering Experience. En Proceedings of the 1997 Symposium on Software Reusability, volume 22, páginas 81–88. ACM, doi:10.1145/258366.258391.

Humphrey, W. S. (1989). Managing the Software Process. Addison-Wesley.

IEEE, S. (1998). IEEE Std 1074-1997. Standard for Developing Software Life Cycle Processes. doi:10.1109/IEEESTD.1998.88827.

INCOSE (2010). Systems Engineering Measurement Primer: A Basic Introduction to Measurement Concepts and Use for Systems Engineering. Technical report.

ISO/IEC (1999). ISO 14598-1. Information Technology - Software Product Evaluation - Part 1: General Overview.

ISO/IEC (2001). ISO 9126-1. Software Engineering - Product Quality - Part 1: Quality Model.

ISO/IEC (2003). ISO 10006. Quality Management Systems–Guidelines for Quality Management in Projects. ISO/IEC (2007). ISO 15939. Systems and Software Engineering - Measurement Process. ISO/IEC (2011). ISO 25010-3. Systems and Software Engineering. Systems and Software Quality Requirements and Evaluation (SQuaRE). System and Software Quality Models.

Jasper, R., Uschold, M., et al. (1999). A Framework for Understanding and Classifying Ontology Applications. En Proceedings 12 th Int. Workshop on Knowledge Acquisition, Model ling, and Management KAW, volume 99, páginas 16–21.

Kaplan, R. S. y Norton, D. P. (1996). The Balanced Scorecard: Translating Strategy into Action. Harvard Business Press, ISBN: 9780875846514.

Kaplan, R. S. y Norton, D. P. (2005). The Balanced Scorecard: Measures That Drive Performance. Harvard Business Review, 83(7-8):172–+.

Kerth, N. L. (1995). Pattern Languages of Program Design. chapter Caterpillar’s Fate: A Pattern Language for the Transformation from Analysis to Design, páginas 293–320. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, ISBN: 0-201-60734-4, http://dl.acm.org/citation.cfm?id=218662.218684.

Kitchenham, B. y Pfleeger, S. L. (1996). Software Quality: The Elusive Target. IEEE Software, 13(1):12–21, doi:10.1109/52.476281.

Kitchenham, B. A., Hughes, R. T., y Linkman, S. G. (2001). Modeling Software Measurement Data. IEEE Transactions on Software Engineering, 27(9):788–804, doi:10.1109/32.950316.

Lavazza, L. (2000). Providing Automated Support for the GQM Measurement Process. IEEE Software, 17(3):56–62, ISSN: 0740-7459, doi:10.1109/52.896250.

Lew, P., Olsina, L., Becker, P., y Zhang, L. (2012). An Integrated Strategy to Systematically Understand and Manage Quality in Use for Web Applications. Requirements Engineering, 17(4):299–330, ISSN: 1432-010X, doi:10.1007/s00766-011-0128-x.

Lew, P., Olsina, L., y Zhang, L. (2010). Quality, Quality in Use, Actual Usability and User Experience as Key Drivers for Web Application Evaluation. Web Engineering: 10 th International Conference (ICWE 2010), páginas 218–232, ISBN: 978-3-642-13911-6, doi:10.1007/978-3-642-13911-6_15.

Lindvall, M., Donzelli, P., Asgari, S., y Basili, V. (2005). Towards Reusable Measurement Patterns. En Proceedings of the 11 th IEEE International Software Metrics Symposium, METRICS ’05, páginas 1–8. IEEE Computer Society, ISBN: 0-7695-2371-4, doi:10.1109/METRICS.2005.49.

López, M. F., Gómez-Pérez, A., Sierra, J. P., y Sierra, A. P. (1999). Building a Chemical Ontology Using METHONTOLOGY and the Ontology Design Environment. IEEE Intel ligent Systems and their Applications, 14(1):37–46, doi:10.1109/5254.747904.

Luftman, J. y Ben-Zvi, T. (2010). Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. 9(4):263–273.

Lusk, S. y Birks, N. (2014). Rethinking Public Strategy. Palgrave Macmillan.

Martin, M. d. l. A. y Olsina, L. (2003). Towards an Ontology for Software Metrics and Indicators as the Foundation for a Cataloging Web System. En Proceedings of the IEEE/LEOS 3 rd International Conference on Numerical Simulation of Semiconductor Optoelectronic Devices (IEEE Cat. No.03EX726), páginas 103–113. ISBN: 0-7695-2058-8, doi:10.1109/LAWEB.2003.1250288.

Mayes, J. (2012). Achieving Business Objectives: Building a Software Metrics Support Structure. En The IFPUG Guide to IT and Software Measurement, páginas 306–316. Auerbach Publications, ISBN: 1439869308, 9781439869307.

McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., y Dean, J. (2001). Practical Software Measurement: Objective Information for Decision Makers. Addison-Wesley Professional.

Mintzberg, H., Ahlstrand, B., y Lampel, J. (2005). Strategy Safari: A Guided Tour Through the Wilds of Strategic Mangament. Simon and Schuster.

Molina, H. (2012). Soporte Organizacional de Medición y Evaluación orientada a Objetivos y Sensible al Contexto. PhD thesis, Universidad Nacional de La Plata.

Molina, H. y Olsina, L. (2008). Assessing Web Applications Consistently: A Context Information Approach. En 8 th International Conference on Web Engineering (ICWE’08), páginas 224–230. IEEE, doi:10.1109/ICWE.2008.21.

Moraga, M., Bertoa, M., Morcillo, M., Calero, C., y Vallecillo, A. (2008). Evaluating Quality-in-Use Using Bayesian Networks. En Proceedings of QAOOSE, páginas 1–10.

Morasca, S. (2001). Software Measurement. Handbook of Software Engineering and Knowledge Engineering, 1:239–276.

Musen, M. A. (2015). The Protégé Project: A Look Back and a Look Forward. AI Matters. Association of Computing Machinery Specific Interest Group in Artificial Intel ligence, 1(4):4–12, doi:10.1145/2557001.25757003.

Neil, M., Krause, P., y Fenton, N. (2003). Software Quality Prediction Using Bayesian Networks. En Software Engineering with Computational Intel ligence, páginas 136–172. Springer.

Nielsen, J. (1994). Usability Engineering. Elsevier, ISBN: 9780125184069.

Nielsen, J. y Budiu, R. (2012). Mobile Usability. Pearson Education, ISBN: 0133122174, 9780133122176.

Norman, D. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books (AZ).

Olsina, L. y Becker, P. (2017). Family of Strategies for Different Evaluation Purposes. En Proceedings of the XX Conferencia Iberoamericana en Software Engineering (CIbSE’17) held in the framework of ICSE (XXXIX Int’l Conference on Software Engineering), página 14.

Olsina, L., Garrido, A., Rossi, G., Distante, D., y Canfora, G. (2008a). Web Application Evaluation and Refactoring: A Quality-Oriented Improvement Approach. Journal of Web Engineering, 7(4):258–280, ISSN: 1540-9589.

Olsina, L., Lew, P., Dieser, A., y Rivera, B. (2011a). Using Web Quality Models and a Strategy for Purpose-Oriented Evaluations. Journal of Web Engineering (JWE), 10(4):316–352, ISSN: 1540-9589.

Olsina, L., Lew, P., Dieser, A., y Rivera, B. (2012). Updating Quality Models for Evaluating New Generation Web Applications. Journal of Web Engineering (JWE), 11(3):209–246.

Olsina, L. y Martin, M. d. l. A. (2004). Ontology for Software Metrics and Indicators. Journal of Web Engineering, 2(4):262–281.

Olsina, L., Papa, F., y Molina, H. (2008b). How to Measure and Evaluate Web Applications in a Consistent Way, páginas 385–420. Springer London, ISBN: 978-1-84628-923-1, doi:10.1007/978-1-84628-923-1_13.

Olsina, L., Papa, M. F., y Becker, P. (2011b). Assessing Integrated Measurement and Evaluation Strategies: A Case Study. En Proceedings of the 7 th Central and Eastern European Software Engineering Conference (CEE-SECR), páginas 1–10. IEEE, doi:10.1109/CEE-SECR.2011.6188462.

Olsina, L. y Rossi, G. (2002). Measuring Web Application Quality with WebQEM. IEEE Multimedia, 9(4):20–29, doi:10.1109/MMUL.2002.1041945.

Olsina, L. A. (1997). Applying the Flexible Process Model to Build Hypermedia Products. Hypertextes et hypermédias, páginas 211–221.

Papa, F. (2012). Toward the Improvement of a Measurement and Evaluation Strategy from a Comparative Study. En Proceedings of the 12th International Conference on Current Trends in Web Engineering, ICWE’12, páginas 189–203. Springer Berlin Heidelberg, ISBN: 978-3-642-35623-0, doi:10.1007/978-3-642-35623-0_20.

Papa, M. F., Rivera, B., Becker, P., y Olsina, L. (2015). Patrón de Estrategia de Evaluación y Mejora de una Vista de Calidad aplicado a un Recurso Organizacional. En III Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNaIISI’15), páginas 1–12. ISBN: 978-987-1896-47-9.

Papa, M. F., Rivera, B., Becker, P., y Olsina, L. (2016). Evaluation and Improvement of an Organizational Resource Applying Strategy Patterns. Journal of Software Engineering and Applications, 9(04):1–19, ISSN: 1945-3116, doi:10.4236/jsea.2016.94011.

Park, R. E., Goethert, W. B., y Florac, W. A. (1996). Goal-Driven Software Measurement. A Guidebook. Technical Report CMU/SEI-96-HB-002, Software Engineering Institute (SEI).

PMI (2013). Guía de los Fundamentos Para la Dirección de Proyectos (Guía del PMBOK)–Quinta Edición. Project Management Institute, ISBN: 978-1-62825-009-1.

Preece, J. y Rombach, H. D. (1994). A Taxonomy for Combining Software Engineering and Human-Computer Interaction Measurement Approaches: Towards a Common Framework. International journal of human-computer studies, 41(4):553–583, doi:10.1006/ijhc.1994.1073.

PSM (2000). Practical Software and Systems Measurement: A Foundation for Objective Project Management. Technical report, Department of Defense and US Army.

Rivera, B., Becker, P., Lew, P., y Olsina, L. (2015a). Towards Strategy Patterns for Evaluating Usability. En International Conference on Web Engineering (ICWE’15), páginas 705–708. Springer International Publishing Switzerland.

Rivera, B., Becker, P., Lew, P., y Olsina Santos, L. A. (2015b). Strategy Patterns for Evaluating and Improving Usability. En Simposio Argentino de Ingeniería de Software (ASSE’15)-44º Jornadas Argentinas de Informática (JAIIO 44), páginas 69–84. ISBN: 24517593.

Rivera, B., Becker, P., y Olsina, L. (2014). Estrategia de Medición, Evaluación y Mejora Continua de Calidad. En 2 do Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNaIISI), páginas 833–844. ISSN: 2346-9927.

Rivera, B., Becker, P., y Olsina, L. (2015c). Patrones de Estrategia para Proyectos de Medición, Evaluación y Mejora. En XVIII Conferencia Iberoamericana en Software Engineering (CIbSE’15), páginas 166–180.

Rivera, B., Becker, P., y Olsina, L. (2016a). Quality Views and Strategy Patterns for Evaluating and Improving Quality: Usability and User Experience Case Studies. Journal of Web Engineering (JWE), 15(5-6):433–464.

Rivera, B., Becker, P., y Olsina Santos, L. A. (2015d). Extending the Conceptual Base for a Holistic Quality Evaluation Approach. En I Simposio Argentino de Ontologías y sus Aplicaciones (SAOA)-JAIIO 44, volume 1449, páginas 121–130. ISSN: 1613-0073.

Rivera, B., Becker, P., Papa, F., y Olsina, L. (2016b). A Holistic Quality Evaluation, Selection and Improvement Approach driven by Multilevel Goals and Strategies. CLEI Electronic Journal, 19(3):1–28.

Rivera, B., Becker, P., Papa, F., y Olsina, L. (2016c). Hacia la Evaluación y Mejora de Software Dirigidas por Metas Multinivel y Estrategias. En XIX Conferencia Iberoamericana en Software Engineering (CIbSE’16), páginas 1–14. ISBN: 978-9978-301-81-4.

Rivera, B., Becker, P., Papa, F., y Olsina, L. A. (2016d). A Quality Evaluation and Improvement Approach driven by Multilevel Goals and Strategy Patterns. En II Simposio Argentino de Ontologías y sus Aplicaciones (SAOA 2016)-JAIIO 45º, páginas 15–28.

Rossi, G., Schwabe, D., y Lyardet, F. (1999). Improving Web Information Systems with Navigational Patterns. Proceedings of the 8 th International Conference on World Wide Web, 31(11):1667–1678, ISSN: 1389-1286, doi:10.1016/S1389-1286(99)00015-8.

Rowe, A. y Whitty, R. (1970). AMI: A Quantitative Approach to Software Management. WIT Transactions on Information and Communication Technologies, 8, ISSN: 1743-3517, doi:10.1002/stvr.4370020307.

Ru¯m¯ı, J. a.-D. (1993). Tales from the Masnavi. Psychology Press.

Schendel, D. y Hofer, C. (1979). Strategic Management: A New View of Business Policy and Planning. Little, Brown.

Singh, S. N. y Woo, C. (2008). A Methodology for Discovering Goals at Different Organizational Levels. En Proceedings of BUSITAL, volume 8, página 17.

Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., y Katz, Y. (2007). Pellet: A Practical OWL-DL Reasoner. Web Semantics: Science, Services and Agents on the World Wide Web, 5(2):51–53, doi:10.1016/j.websem.2007.03.004.

Tebes, G., Peppino, D., Rivera, B., Pablo, B., y Olsina, L. (2016). Estrategia de Comprensión y Análisis Aplicado a un Proyecto de Evaluación de Usabilidad de LinkedIn. En IX Congreso Nacional de Ingeniería Informática/Sistemas de Información (CoNAIISI), páginas 1–14. ISSN: 2347-0372.

Trendowicz, V. B. A., Heidrich, M. K. J., Münch, C. S. J., y Rombach, D. (2014). Aligning Organizations Through Measurement-The GQM + Strategies Approach. Springer, ISBN: 978-3-319-05046-1, ISSN: 2193-8199, doi:10.1007/978-3-319-05047-8.

Uschold, M. y King, M. (1995). Towards a Methodology for Building Ontologies. En Proceedings Workshop on Basic Ontological Issues in Knowledge Sharing.

Van Solingen, R. y Berghout, E. (1999). The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software development. McGraw-Hill.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., y Wesslén, A. (2012). Experimentation in Software Engineering. Springer Science & Business Media, doi:10.1007/978-3-642-29044-2.

Zuse, H. (1998). A Framework of Software Measurement. Walter de Gruyter.

Apéndice A

Documento OWL

<?xml version="1.0¿>

<rdf:RDF xmlns="http://www.tuwien.ac.at/out.owl" xml:base="http://www.tuwien.ac.at/out.owl" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns" xmlns:owl="http://www.w3.org/2002/07/owl" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema»

<owl:Ontology rdf:about="http://www.tuwien.ac.at/out.owl/>

<!–

///////////////////////////////////////////////////////////////////////////////////////

//

// Datatypes

//

///////////////////////////////////////////////////////////////////////////////////////

–>

<!– http://www.tuwien.ac.at/out.owlanyType –>

<rdfs:Datatype rdf:about="http://www.tuwien.ac.at/out.owlanyType/>

<!–

///////////////////////////////////////////////////////////////////////////////////////

//

// Object Properties

//

///////////////////////////////////////////////////////////////////////////////////////

–>

<!– http://www.tuwien.ac.at/out.owl –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owl»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewQualityViewRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasAttributeCharacteristicRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasAttributeCharacteristicRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicAttributeRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;combinesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasAttributeEntityCategoryRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasAttributeEntityCategoryRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryAttributeRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection» 

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;associatedWithquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasBusinessGoalInformationNeedGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasBusinessGoalInformationNeedGoalRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlBusinessGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isSupportedByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasBusinessGoalOrganizationalLevelRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasBusinessGoalOrganizationalLevelRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationalLevelBusinessGoalRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlBusinessGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isFormulatedAtquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasCharacteristicAttributeRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicAttributeRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;combinesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasCharacteristicCharacteristicsModelRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicCharacteristicsModelRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelCharacteristicRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;includesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasCharacteristicsModelCharacteristicRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelCharacteristicRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:unionOf>

</owl:Class> 

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;includesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasCharacteristicsModelQualityFocusRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelQualityFocusRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusCharacteristicsModelRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isRepresentedByquot;.</rdfs:com

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityCategoryAttributeRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryAttributeRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;associatedWithquot;.</rdfs:comm

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityCategoryEntityRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntityRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityEntityCategoryRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntity/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;belongsToquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityCategoryEntitySuperCategoryRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntitySuperCategoryRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryEntityCategoryRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;pertainsquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityCategoryMEInformationNeedGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryMEInformationNeedGoalRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalEntityCategoryRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain> 

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;specifiesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityEntityCategoryRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityEntityCategoryRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntity/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;belongsToquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryEntityCategoryRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryEntityCategoryRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;pertainsquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityFocusRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityFocusRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusEntitySuperCategoryRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityViewRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityViewRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewEntitySuperCategoryRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasGoalStrategyRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasGoalStrategyRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyGoalRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategy/> 

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;helpsToAchievequot;.</rdfs:comm

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasInformationNeedGoalMEInformationNeedGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasInformationNeedGoalMEInformationNeedGoalRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;requiresquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalEntityCategoryRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalEntityCategoryRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;specifiesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalQualityFocusRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalQualityFocusRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusMEInformationNeedGoalRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;describesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasOrganizationOrganizationalLevelRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasOrganizationOrganizationalLevelRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganization/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isManagedAtquot;.</rdfs:commen

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasOrganizationProjectRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasOrganizationProjectRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasProjectOrganizationRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganization/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlProject/>

</owl:unionOf>

</owl:Class>

</rdfs:range> 

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;arrangesWorkByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasOrganizationalLevelBusinessGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasOrganizationalLevelBusinessGoalRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlBusinessGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isFormulatedAtquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasProjectOrganizationRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasProjectOrganizationRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlProject/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlOrganization/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;arrangesWorkByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityFocusCharacteristicsModelRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityFocusCharacteristicsModelRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;isRepresentedByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityFocusEntitySuperCategoryRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityFocusEntitySuperCategoryRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityFocusMEInformationNeedGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityFocusMEInformationNeedGoalRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;describesquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityFocusQualityViewRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityFocusQualityViewRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewQualityFocusRelation/>

<rdfs:domain> 

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityViewEntitySuperCategoryRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityViewEntitySuperCategoryRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityViewQualityFocusRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityViewQualityFocusRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasQualityViewQualityViewRelation  –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasQualityViewQualityViewRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasStrategyGoalRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasStrategyGoalRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlGoal/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;helpsToAchievequot;.</rdfs:comm

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasStrategyPatternStrategyRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasStrategyPatternStrategyRelation»

<owl:inverseOf rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategyPattern/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class> 

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;instantiatesdByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!– http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation –>

<owl:ObjectProperty rdf:about="http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation»

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>

<rdfs:range>

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlStrategyPattern/>

</owl:unionOf>

</owl:Class>

</rdfs:range>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchemastring»Originally, association was named quot;instantiatesdByquot;.</rdfs:comment>

</owl:ObjectProperty>

<!–

///////////////////////////////////////////////////////////////////////////////////////

//

// Data properties

//

///////////////////////////////////////////////////////////////////////////////////////

–>

<!– http://www.tuwien.ac.at/out.owlhasAlias –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasAlias»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasCharacteristicDefinition –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicDefinition»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristic/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasDefinition –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasDefinition»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasDescription –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasDescription»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlEntity/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasEndDate –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEndDate»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlProject/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasEntityCategoryDescription  –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryDescription»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasIntent  –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasIntent»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasMision –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasMision»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlOrganization/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasMotivation –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasMotivation»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasObjective –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasObjective»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasPurpose –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasPurpose»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasSpecification –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasSpecification» 

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasStartDate –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasStartDate»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlProject/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasStatement  –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasStatement»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasTimeframe –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasTimeframe»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasType –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasType»

<rdf:type rdf:resource="http://www.w3.org/2002/07/owlFunctionalProperty/>

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasUserviewpoint  –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasUserviewpoint»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!– http://www.tuwien.ac.at/out.owlhasVision –>

<owl:DatatypeProperty rdf:about="http://www.tuwien.ac.at/out.owlhasVision»

<rdfs:domain rdf:resource="http://www.tuwien.ac.at/out.owlOrganization/>

<rdfs:range rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:DatatypeProperty>

<!–

///////////////////////////////////////////////////////////////////////////////////////

//

// Classes

//

///////////////////////////////////////////////////////////////////////////////////////

–>

<!– http://www.tuwien.ac.at/out.owlAttribute –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlAttribute»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasAttributeEntityCategoryRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasAttributeEntityCategoryRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasAttributeCharacteristicRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasDefinition/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasObjective/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasDefinition/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlBusinessGoal –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlBusinessGoal»

<rdfs:subClassOf rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

<rdfs:subClassOf> 

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasBusinessGoalInformationNeedGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlInformationNeedGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasBusinessGoalOrganizationalLevelRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlCharacteristic –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlCharacteristic»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicAttributeRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicAttributeRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicCharacteristicsModelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicCharacteristicsModelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicDefinition/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasCharacteristicDefinition/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlCharacteristicsModel –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlCharacteristicsModel»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelCharacteristicRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelCharacteristicRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristic/>

</owl:Restriction>

</owl:intersectionOf> 

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasCharacteristicsModelQualityFocusRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasSpecification/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasSpecification/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlEntity –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlEntity»

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityEntityCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasDescription/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasDescription/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlEntityCategory –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlEntityCategory»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryAttributeRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryAttributeRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlAttribute/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntityRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntity/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntityRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntity/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryMEInformationNeedGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction> 

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryMEInformationNeedGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntitySuperCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:Restriction>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntitySuperCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryEntitySuperCategoryRelation/>

<owl:maxQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:maxQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntityCategoryDescription/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasEntityCategoryDescription/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlEntitySuperCategory  –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlEntitySuperCategory»

<rdfs:subClassOf rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryEntityCategoryRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryEntityCategoryRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityFocusRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEntitySuperCategoryQualityViewRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlGoal –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlGoal»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasGoalStrategyRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:Restriction>

</owl:unionOf>

</owl:Class> 

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasPurpose/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStatement/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasTimeframe/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasStatement/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlInformationNeedGoal –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlInformationNeedGoal»

<rdfs:subClassOf rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasInformationNeedGoalMEInformationNeedGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlMEInformationNeedGoal –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal»

<rdfs:subClassOf rdf:resource="http://www.tuwien.ac.at/out.owlInformationNeedGoal/>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalEntityCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasMEInformationNeedGoalQualityFocusRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasUserviewpoint/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlOrganization –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlOrganization»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationOrganizationalLevelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationOrganizationalLevelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlOrganizationalLevel/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf> 

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationProjectRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlProject/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationProjectRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlProject/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasMision/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasVision/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasMision/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlOrganizationalLevel –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlOrganizationalLevel»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasOrganizationalLevelBusinessGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlBusinessGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasType/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasType/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlProject –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlProject»

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasProjectOrganizationRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlOrganization/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasEndDate/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStartDate/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasStartDate/>

</owl:hasKey>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlQualityFocus –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlQualityFocus»

<rdfs:subClassOf rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristic/> 

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusCharacteristicsModelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusCharacteristicsModelRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlCharacteristicsModel/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusMEInformationNeedGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusEntitySuperCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityFocusQualityViewRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlQualityView –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlQualityView»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owl/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewQualityViewRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewEntitySuperCategoryRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasQualityViewQualityFocusRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:Restriction> 

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlStrategy –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlStrategy»

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyGoalRelation/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:minQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlGoal/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class>

<owl:intersectionOf rdf:parseType=Çollection»

<owl:Class>

<owl:unionOf rdf:parseType=Çollection»

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»0</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

</owl:Restriction>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyStrategyPatternRelation/>

<owl:maxQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:maxQualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</rdfs:subClassOf>

</owl:Class>

<!– http://www.tuwien.ac.at/out.owlStrategyPattern –>

<owl:Class rdf:about="http://www.tuwien.ac.at/out.owlStrategyPattern»

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasStrategyPatternStrategyRelation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onClass rdf:resource="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasAlias/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasIntent/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.tuwien.ac.at/out.owlhasMotivation/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchemanonNegativeInteger»1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="http://www.tuwien.ac.at/out.owlanyType/>

</owl:Restriction>

</rdfs:subClassOf>

<owl:hasKey rdf:parseType=Çollection»

<rdf:Description rdf:about="http://www.tuwien.ac.at/out.owlhasAlias/>

</owl:hasKey>

</owl:Class>

<!–

///////////////////////////////////////////////////////////////////////////////////////

//

// Individuals

//

///////////////////////////////////////////////////////////////////////////////////////

–>

<!– http://www.tuwien.ac.at/out.owlExternalQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlExternalQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

<hasQualityFocusEntitySuperCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystem/> 

<hasQualityFocusQualityViewRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystemQ ualityV  iew”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlGOCAME –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlGOCAME»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlStrategy/>

<hasStrategyStrategyPatternRelation rdf:resource="http://www.tuwien.ac.at/out.owlGoal-orientedM easurementa ndE valuationf orO neQ ualityV  i

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlGOCAMEC –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlGOCAMEC»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlGoal-orientedM easurementE valuationa ndC hangef orO neQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlGoal-orientedM easurementE valuationa ndC hangef orO neQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

<hasAlias rdf:datatype="http://www.tuwien.ac.at/out.owlanyType»GoMEC1 QV   < /hasAlias >

<hasPurpose rdf:datatype="http://www.w3.org/2001/XMLSchemastring»improve</hasPurpose>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlGoal-orientedM easurementa ndE valuationf orO neQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlGoal-orientedM easurementa ndE valuationf orO neQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlStrategyPattern/>

<hasStrategyPatternStrategyRelation rdf:resource="http://www.tuwien.ac.at/out.owlGOCAME/>

<hasAlias rdf:datatype="http://www.tuwien.ac.at/out.owlanyType»GoME1 QV   < /hasAlias >

<hasPurpose rdf:datatype="http://www.w3.org/2001/XMLSchemastring»understand</hasPurpose>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlInternalQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlInternalQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

<hasQualityFocusEntitySuperCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlProduct/>

<hasQualityFocusQualityViewRelation rdf:resource="http://www.tuwien.ac.at/out.owlProductQ ualityV  iew”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlLinkedInm obilev ersion − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlLinkedInm obilev ersion” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntity/>

<hasEntityEntityCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlWebA pplication”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlMEInf1 –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlMEInf1»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlMEInformationNeedGoal/>

<hasGoalStrategyRelation rdf:resource="http://www.tuwien.ac.at/out.owlGOCAME/>

<hasMEInformationNeedGoalEntityCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlWebA pplication”/ >

<hasMEInformationNeedGoalQualityFocusRelation rdf:resource="http://www.tuwien.ac.at/out.owlExternalQ uality”/ >

<hasPurpose rdf:datatype="http://www.w3.org/2001/XMLSchemastring»understand</hasPurpose>

<hasStatement rdf:datatype="http://www.tuwien.ac.at/out.owlanyType»understand LinkedIn‘s Usability</hasStatement>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProcess –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProcess»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProcessQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProcessQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProcessQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProcessQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProduct –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProduct»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProductQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProductQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProject –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProject»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProjectQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProjectQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlProjectQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlProjectQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlResource –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlResource»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlResourceQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlResourceQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlResourceQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlResourceQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSIQinU –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSIQinU»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlStrategy/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSystem –>

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSystem»

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/> 

<hasEntitySuperCategoryEntityCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlWebA pplication”/ >

<hasEntitySuperCategoryQualityFocusRelation rdf:resource="http://www.tuwien.ac.at/out.owlExternalQ uality”/ >

<hasEntitySuperCategoryQualityViewRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystemQ ualityV  iew”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSystemQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSystemQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

<hasQualityViewEntitySuperCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystem/>

<hasQualityViewQualityFocusRelation rdf:resource="http://www.tuwien.ac.at/out.owlExternalQ uality”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSystemi nU se − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSystemi nU se” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntitySuperCategory/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSystemi nU seQ uality − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSystemi nU seQ uality” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityFocus/>

<hasQualityFocusEntitySuperCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystemi nU se”/ >

<hasQualityFocusQualityViewRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystemi nU seQ ualityV  iew”/ >

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlSystemi nU seQ ualityV  iew − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlSystemi nU seQ ualityV  iew” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlQualityView/>

</owl:NamedIndividual>

<!– http://www.tuwien.ac.at/out.owlWebA pplication − − >

<owl:NamedIndividual rdf:about="http://www.tuwien.ac.at/out.owlWebA pplication” >

<rdf:type rdf:resource="http://www.tuwien.ac.at/out.owlEntityCategory/>

<hasEntityCategoryEntitySuperCategoryRelation rdf:resource="http://www.tuwien.ac.at/out.owlSystem/>

</owl:NamedIndividual>

</rdf:RDF>

<!– Generated  by the OWL API (version 4.2.6.20160910-2108) https://github.com/owlcs/owlapi –>