APLICACION DEL MODELO “KITE” PARA LA VALORACION DE CALIDAD DEPRODUCTOS DE SOFTWARE: INSTRUMENTALIZACION DE LISTAS DE CHEQUEO.

EDGAR FABIAN IBANEZ JIMENEZMARISOL MARQUEZ GOMEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDASFACULTAD DE INGENIERIAINGENIERIA DE SISTEMAS

BOGOTA2017

APLICACION DEL MODELO KITE PARA LA VALORACION DE CALIDAD DEPRODUCTOS DE SOFTWARE: INSTRUMENTALIZACION DE LISTAS DE CHEQUEO.

EDGAR FABIAN IBANEZ JIMENEZMARISOL MARQUEZ GOMEZ

Trabajo de grado para optar al tıtulo de Ingeniero(a) de sistemas

DirectoresHenry Alberto Diosa, PhD.

Sergio A. Rojas, PhD.

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDASFACULTAD DE INGENIERIAINGENIERIA DE SISTEMAS

BOGOTA2017

Indice

1. INTRODUCCION 7

2. DESCRIPCION DEL PROBLEMA 8

3. JUSTIFICACION DE LA PROPUESTA 93.1. JUSTIFICACION ACADEMICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2. JUSTIFICACION PERSONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. JUSTIFICACION INSTITUCIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. PREGUNTAS DE INVESTIGACION 94.1. OBJETIVO GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2. OBJETIVOS ESPECIFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5. MARCO REFERENCIAL 115.1. Marco referencial contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.1. Estandares relacionados con valoracion de calidad de productos de software . 125.1.2. Valoracion de productos de software en el ambito acedemico a nivel Nacional 135.1.3. Modelos de valoracion de productos de software a nivel internacional . . . . . 155.1.4. Comparativo modelos de valoracion a nivel de productos de software . . . . . 20

5.2. Marco referencial teorıco-conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3. Marco referencial tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6. MARCO METODOLOGICO 28

7. APLICACION DE LA METODOLOGIA 307.1. Determinacion de las perspectivas de la valoracion usando KITE . . . . . . . . . . . 30

7.1.1. Perspectiva del proponente del producto a valorar . . . . . . . . . . . . . . . 307.1.2. Perspectiva del experto evaluador tematico . . . . . . . . . . . . . . . . . . . 327.1.3. Perspectiva del experto evaluador de software . . . . . . . . . . . . . . . . . . 32

7.2. Comprension de los estados de un producto de software bajo el modelo KITE . . . . 327.3. Elaboracion de guiones de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.3.1. La estructura basica de un guion de prueba . . . . . . . . . . . . . . . . . . . 357.3.2. Tipos de indagacion o preguntas . . . . . . . . . . . . . . . . . . . . . . . . . 377.3.3. Modelos de computo definidos y correspondencia al modelo conceptual KITE 39

7.4. Seleccion de productos de software para validacion del modelo KITE . . . . . . . . . 427.4.1. Productos de software seleccionados . . . . . . . . . . . . . . . . . . . . . . . 42

7.5. Criterios de seleccion de los expertos evaluadores . . . . . . . . . . . . . . . . . . . . 447.5.1. Seleccion de expertos evaluadores . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.6. Mecanismo facilitador del proceso de evaluacion: La herramienta KITEWeb . . . . . 457.6.1. Niveles de especificacion de la herramienta KITEWeb. . . . . . . . . . . . . . 457.6.2. Arquitectura tecnologica de KITEWeb. . . . . . . . . . . . . . . . . . . . . . 507.6.3. Tipos de reporte generados por la herramienta KITEWeb . . . . . . . . . . . 51

7.7. Analisis de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.7.1. Alcance y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.7.2. Comunicacion visual geometrica de calidad del producto . . . . . . . . . . . . 537.7.3. Metodos estadısticos de analisis y su utilidad . . . . . . . . . . . . . . . . . . 567.7.4. Hallazgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8. TRABAJO FUTURO 63

9. CONCLUSIONES 64

10.GLOSARIO 65

4

Indice de figuras

1. Matriz de calidad global Sistematica . . . . . . . . . . . . . . . . . . . . . . . . . . . 122. Factores de calidad de McCall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163. Estructura jerarquica del modelo GQM . . . . . . . . . . . . . . . . . . . . . . . . . 174. Niveles y enlaces del modelo Bansiya . . . . . . . . . . . . . . . . . . . . . . . . . . . 185. Vista general del enfoque de evaluacion de calidad . . . . . . . . . . . . . . . . . . . 196. Cadena de herramientas Quamoco . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207. Propuesta grafica modelo KITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248. Valores maximos posibles para el modelo KITE . . . . . . . . . . . . . . . . . . . . . 259. Proceso general del ejercicio de valoracion . . . . . . . . . . . . . . . . . . . . . . . . 3110. Definicion maquina de estados. Ciclo de valoracion de un producto de software . . . 3411. Definicion preliminares. Guiones de prueba . . . . . . . . . . . . . . . . . . . . . . . 3512. Ejemplo guion de prueba. Guiones de prueba . . . . . . . . . . . . . . . . . . . . . . 3613. Definicion subatributos Portabilidad (E6) . . . . . . . . . . . . . . . . . . . . . . . . 3714. Ejemplo de formato de pregunta. Guiones de prueba . . . . . . . . . . . . . . . . . . 3715. Pregunta con unica respuesta, tomada del guion de prueba I2-Asequibilidad. . . . . 3816. Pregunta con respuesta multiple, tomado del guion de prueba I2-Cobertura. . . . . . 3817. Pregunta condicional, tomado del guion de prueba E2.3-Extendibilidad y manteni-

bilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3918. Arbol de decision representando modelo de computo con preguntas excluyentes con

cuadro de equivalencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4019. Arbol de decision representando modelo de computo con resultados independientes

con cuadro de equivalencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4120. Arbol de decision representando modelo de computo con preguntas incluyentes . . . 4221. Ejemplo especificacion de requerimientos funcionales KITEWeb. . . . . . . . . . . . 4522. Diagrama de casos de uso. Gestion de productos de software y registro de evaluacion.

Herramienta KITEWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4623. Formato extendido para el caso de CUGP07. Herramienta KITEWeb . . . . . . . . . 4624. Diagrama de actividad del caso de uso CUGP07. Herramienta KITEWeb . . . . . . 4725. Diagrama de despliegue herramienta KITEWeb . . . . . . . . . . . . . . . . . . . . . 4826. Diagrama de despliegue herramienta KITEWeb . . . . . . . . . . . . . . . . . . . . . 4927. Diagrama de despliegue herramienta KITEWeb . . . . . . . . . . . . . . . . . . . . . 5128. Reporte geometrico KITEWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5129. Reporte cuantitativo KITEWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5230. Histograma por determinante E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5631. Histograma por determinante I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5732. Histograma por determinante T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5833. Histograma por determinante K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5934. Comparativo de madurez de un producto de software frente a los otrosl . . . . . . . 62

5

Indice de tablas

1. Cuadro comparativo modelos de valoracion de productos de software . . . . . . . . . 222. Cuadro comparativo modelos de valoracion de productos de software por atributos

de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233. Tabla casos de uso herramienta KITEWeb . . . . . . . . . . . . . . . . . . . . . . . . 454. Reporte geometrico productos de software Prototipos academicos. . . . . . . . . . . 545. Reporte geometrico productos de software Protoripos academicos. . . . . . . . . . . 556. Reporte geometrico productos de software Propietarios. . . . . . . . . . . . . . . . . 567. Histograma por atributos, E2 - Extendibilidad y Mantenibilidad, I2 - Asequibilidad,

K1 - Inventiva y T4 - Mejoramiento continuo. . . . . . . . . . . . . . . . . . . . . . . 608. Histograma por categorıas Determinante K, I, T y E. . . . . . . . . . . . . . . . . . . 61

6

1. INTRODUCCION

Al momento de referirse a valoracion de un producto de software, las herramientas disponi-bles para medir los niveles de calidad no son ampliamente conocidas, detalladas ni intuitivas. Estoconlleva a que los grupos desarrolladores de productos de software no cuenten con modelos de valo-racion de calidad de software que los apoyen en el cumplimiento de estandares de calidad [12] [11],dado que no es facil saber si los cumplen y con que rigurosidad lo hacen.

El modelo de valoracion de productos de software para el ambito academico KITE [19], es unmodelo conceptual que valora o evalua productos de software desde cuatro diferentes perspectivas:Aporte o no de nuevo conocimiento, innovacion tecnologica, aspectos de calidad del producto desdela perspectiva de la ingenierıa de software y finalmente impacto en terminos del beneficio para lacomunidad academica y su contribucion a los proyectos de investigacion. Estas cuatro perspectivas,conforman un espacio de cuatro ejes en donde de acuerdo a sus valores especificados dibujan unpolıgono. El area de la figura corresponde al resultado de la valoracion de un producto, entre mayorsea este valor significa que el puntaje de cada uno de los ejes se incremento, y por ende tiene unamayor valoracion de calidad.

Este trabajo busca, en primer lugar, describir los mecanismos necesarios para instrumentalizarel modelo (perspectivas de evaluacion, estados de evaluacion, guiones de prueba y herramienta deapoyo), en segundo lugar, aplicar el modelo a una muestra de productos de software, analizando losresultados del ejercicio de valoracion y poder obtener ası, conclusiones que nos indiquen fortalezas,debilidades y la viabilidad como modelo de valoracion de productos de software.

7

2. DESCRIPCION DEL PROBLEMA

Un modelo enfocado a valorar los productos o prototipos de software desarrollados en el ambitoacademico puede servir como una herramienta para la toma de decisiones academicas al identificarlos perfiles de productividad del software en grupos de investigacion o a nivel individual, y tambienal determinar polıticas adecuadas para apoyar, promover y recompensar los logros obtenidos delos profesionales involucrados; por lo anterior, es importante que un modelo para la evaluacion yvaloracion de dichos productos sea claro y a disposicion de la comunidad academica.

Por otro lado, los modelos de valoracion de software existentes tienen un enfoque para produc-tos usados por la industria mas no para los productos originados en el ambito academico. Estaevaluacion de software limitada a la industria ha propuesto modelos impulsados por las gananciasque conlleva tener un producto con una valoracion de alta calidad, por otro lado, en el contextoacademico, el desarrollo de software es impulsado por el aporte al conocimiento y la innovacion.En la actualidad, dentro de la comunidad academica colombiana, los instrumentos de valoracionde software se limitan a listas de chequeo diligenciadas por pares evaluadores en los que se confıarespecto a su juicio experto. En algunos casos, estos pares evaluadores son idoneos a nivel tematicoo disciplinar mas no satisfacen la necesidad de un solido conocimiento en ingenierıa de software oviceversa.

El modelo de valoracion de calidad KITE [19] genera representacion grafica de los resultados devaloracion, para cada atributo de calidad representados en 4 ejes. Si bien existe la descripcion con-ceptual del modelo KITE [19], junto con una propuesta de las listas de chequeo para atributos ysub-atributos de calidad, aun no se ha validado la aplicacion del modelo en un ejercicio practico.

Inicialmente se buscara hacer una recopilacion de la muestra de productos de software suscep-tibles a ser valorados, seguido a ello, durante la exploracion del manual conceptual para valorarcada atributo en cada eje, se verificaran las necesidades que le permitan a los expertos evaluadoresrealizar su evaluacion. Finalmente, se recolectaran las evaluaciones obtenidas para realizar una in-terpretacion cuantitativa y cualitativa con el fin de identificar la viabilidad del modelo KITE [19].

8

3. JUSTIFICACION DE LA PROPUESTA

3.1. JUSTIFICACION ACADEMICA

En la actualidad a nivel nacional las herramientas disponibles para medir el nivel del calidadde un producto de software no son ampliamente conocidos, y a nivel academico es difıcil encontrarmodelos, metodologıas o guıas para aplicar y mantener los estandares de calidad de un producto desoftware, es por ello que se considera que el modelo KITE es interesante por la amplia presentacionde ıtems a evaluar, destacando entre ellos los atributos correspondientes al aporte cientıfico-academi-co y la presentacion visual de los resultados producto de la aplicacion de un modelo matematicoestablecido, a partir de esto construiremos guiones de prueba cumpliendo el objetivo de dar soportea las listas de chequeo de dicho modelo que aportara a la valoracion academica de productos desoftware.

3.2. JUSTIFICACION PERSONAL

Como futuros ingenieros de sistemas, la elaboracion de este proyecto implica la aplicacion delos conocimientos teoricos y practicos obtenidos durante la carrera, nos enfocamos en seguir estosprincipios, importantes para ser mejores profesionales y seguir el compromiso adquirido de aportara la expansion de los resultados surgidos en el ambito academico, ası mismo, con la experiencia deaplicar el modelo de valoracion enriqueceremos nuestro conocimiento frente a los elementos esen-ciales que requiere un producto de software para ser de excelente calidad, y tener la oportunidadde llevar a la practica dicha valoracion a productos de software reales, que actualmente estan en laindustria o han sido desarrollados en el ambito academico, acercandonos a los conceptos y evalua-ciones tanto de expertos en software y diversas areas tematicas permitiendonos ser partıcipes delproceso.

3.3. JUSTIFICACION INSTITUCIONAL

Como estudiantes de la Universidad Distrital Francisco Jose de Caldas, es de interes desarrollarla instrumentalizacion para facilitar la aplicacion del modelo de valoracion de productos de soft-ware KITE, el cual fue desarrollado por docentes de la misma institucion, para aportar ası a laproduccion academica dentro del marco de la ingenierıa de sistemas. De otra parte, esta validacione instrumentalizacion incentivara a su vez el desarrollo de productos de software con calidad dentrodel ambiente academico y comercial.

4. PREGUNTAS DE INVESTIGACION

¿Como y con que estructura se podran definir instrumentos basados en guiones de prueba parabrindar soporte a la valoracion de cada uno de los atributos de calidad definidos en las listas dechequeo?

4.1. OBJETIVO GENERAL

Aplicar el modelo de valoracion de calidad KITE [19] a una muestra heterogenea de productosde software, construyendo y aplicando guiones de prueba que seran la instrumentalizacion necesariapara tal fin, siendo el soporte de las listas de chequeo que hacen parte del modelo.

9

4.2. OBJETIVOS ESPECIFICOS

1. Recopilar una muestra heterogenea de productos de software que abarque los ambitosacademico y empresarial, ası como los tipos de licencia libre y propietaria, que sean aptospara el ejercicio de valoracion

2. Elaborar los guiones de prueba de atributos y sub-atributos de cada determinante del modeloKITE [19], en los casos que sea nececesario, conforme se avance en la aplicacion sistematicadel modelo, apoyandose para ello en el cuerpo del conocimiento de la Ingenierıa de Software.

3. Efectuar la valoracion a cada uno de los productos de la muestra recopilada, aplicando elmodelo y los instrumentos desarrollados

4. Realizar un analisis cuantitativo y cualitativo (referido a las formas geometricas) de los re-sultados obtenidos en el ejercicio de valoracion de productos de software.

5. Identificar y describir las fortalezas y debilidades del modelo de valoracion de productos desoftware KITE [19] de acuerdo al analisis realizado.

10

5. MARCO REFERENCIAL

5.1. Marco referencial contextual

La calidad de un sistema, aplicacion o producto esta definida por los requerimientos que descri-ben el problema, el diseno que modela la solucion, el codigo que conduce a un programa ejecutabley las pruebas que ejercitan el software para detectar errores, de este modo es necesario evaluar lacalidad, los modelos de diseno, el codigo fuente y los casos de prueba que se han creado y para ellose deben utilizar medidas tecnicas o metricas que sean objetivas, claras y faciles de implementar.

Los modelos de evaluacion y mejora de procesos de software permiten calcular la capacidad omadurez de todos los procesos que intervienen en el ciclo de vida del software [6] [17] [2] [20] [21],detectar los puntos fuertes y los debiles de cada uno y proponer un conjunto de actividades otareas orientadas a guiar a la organizacion o institucion hacia una mejora gradual y continua decada uno de estos procesos, pero no solo existen modelos para procesos, hay diversos modelos condiferentes enfoques, que nos permiten abarcar de una manera diferente este tipo de valoracionesfrente a productos de software desarrollados. Para ello algunos autores presentan valoracionesbasados en medidas de un producto utilizando metricas orientadas al tamano (lınea de codigo,defectos y costos promedio por lınea de codigo, costo por pagina de documentacion), tambien estanlas valoraciones enfocadas a metricas por funcion (calculo por puntos de funcion de acuerdo a unlenguaje de programacion en particular), o valoraciones con un enfoque sistematico de valoracionde los atributos de calidad.

Modelos de valoracion de productoLos modelos que tienen la perspectiva de la valoracion del producto, se centran en las caracterıs-

ticas del software mas no en como fue producido. Tıpicamente se caracterizan por tener 3 nivelesen su estructura [28]:

Factores o aspectos de calidad: Son los atributos de calidad que desde el punto de vista delusuario, se valoran para definir el nivel de calidad de un producto de software.

Criterios de calidad: Son atributos que se presentan para contribuir al factor de calidad enun aspecto asociado.

Metricas: Son medidas cuantitativas que permiten obtener una comprension acerca de cadacriterio de calidad de un producto de software [24].

La ventaja que tienen los modelos de valoracion de producto, radica en la obtencion, mediantelos puntos anteriores, de cifras concretas que se pueden medir por cada aspecto de calidad. Cabemencionar que dado que estos se basan en el criterio del evaluador o evaluadores en particular,las metricas utilizadas en cada modelo existente, pueden ser muy diferentes o interpretadas deuna manera distinta. En la Figura 1 podemos observar algunos modelos que abarcan el conceptode factores o atributos de calidad y que seran detallados en este proyecto, cada grafica circularrepresenta un modelo particular, donde sus particiones hacen referencia a la cantidad de atributosde calidad del software contemplados en su filosofıa. Esto con el fin de dar una vision general acercade cuantos han surgido desde la decada del setenta.

En las siguientes secciones se realizara una revision parcial de las valoraciones de productosde software mencionadas en la Figura 1 y adicionalmente la realizadas en el ambito academico anivel nacional teniendo en cuenta su compleja mezcla de factores que varıan a traves de diferentesaplicaciones y segun el usuario que los haya solicitado.

11

Figura 1: Modelos de valoracion de productos de software de acuerdo a los atributos de calidad desoftware contemplados. Elaborados por Autores

5.1.1. Estandares relacionados con valoracion de calidad de productos de software

ISO/IEC 9126 [12]

El estandar ISO/IEC 9126 tiene como objetivo la definicion de un modelo de calidad y su usocomo marco para la evaluacion de software. El estandar propone una jerarquıa de factoresde calidad clasificados como caracterısticas, subcaracterısticas y atributos segun su grado deabstraccion, entre los que se propone un conjunto de factores de partida compuestos de seiscaracterısticas y veintisiete subcaractersticas.

El estandar ISO/IEC 9126 distingue entre calidad interna y calidad externa, e introducetambien el concepto de calidad de uso. La calidad interna tiene como objetivo medir lacalidad del software mediante factores medibles durante su desarrollo. La calidad externapretende medir la calidad del software teniendo en cuenta el comportamiento de este softwareen un sistema del cual forme parte. Finalmente, la calidad de uso corresponde a la calidaddel software desde el punto de vista de un usuario. La version de 2001 del ISO/IEC 9126 [12]consiste en cuatro partes:

• ISO/IEC 9126-1 (2001). Presenta un modelo de calidad, que es comun para medir lacalidad interna y externa, y uno distinto para medir la calidad en uso y esta se definecomo la capacidad que tiene un producto software para facilitar que usuarios especıficosalcancen metas especıficas con eficacia, productividad, seguridad y satisfaccion en uncontexto especıfico de uso.

• ISO/IEC 9126-2 (2003) TR Metricas Externas. Propone las metricas externas que sepueden utilizar para la medicion de las caracterısticas de calidad del software, observablesen las etapas finales del ciclo de vida del producto software. Las metricas externas quese proponen en esta parte establecen una escala cuantitativa y una forma de medirlas caracterısticas dinamicas del codigo cuando se ejecuta en una computadora o en elentorno requerido.

• ISO/IEC 9126-3 (2003) TR Metricas Internas. Brinda las metricas internas que se pue-den utilizar para la medicion de las caracterısticas de la calidad del software que serelacionan con las etapas tempranas del proceso de desarrollo o su ciclo de vida. Lacalidad interna se puede medir y evaluar a traves de atributos estaticos que se pueden

12

consultar de documentos o artefactos generados en el proceso de desarrollo del producto,como por ejemplo: especificacion de requerimientos, la arquitectura o diseno, piezas decodigo fuente, etc. En esta parte se proponen metricas internas que establecen una escalacuantitativa y una forma de medir dichas caracterısticas.

• ISO/IEC 9126-4 (2004) TR Metricas de Calidad de Uso. Esta parte presenta el conceptode calidad en uso proponiendo un modelo de calidad en uso que permite visibilizar lainterrelacion entre el usuario y el producto desde la optica de la eficiencia y la satisfaccion.

NORMA ISO/IEC 14598 [11]

Es un estandar internacional que define el proceso para evaluar un producto de software.Establece un marco de trabajo para evaluar la calidad de los productos, teniendo en consi-deracion los posibles actores, como son los desarrolladores, evaluadores o compradores. Estacompuesto por cinco partes:

• ISO 14598-1. Vision general: Indica la relacion existente con la norma ISO/IEC 9126 [12].Describe los diferentes terminos tecnicos generales que son usados y los requisitos que setienen para realizar la especificacion y evaluacion de calidad de productos de software.

• ISO 14598-2. Gestion y planificacion: A nivel de administracion y planificacion de la eva-luacion, provee una guıa indicando requisitos y recomendaciones que pueden ser tenidosen cuenta por las personas responsables de administrar el uso de la tecnologıa de eva-luacion o las que dan soporte tecnico a la evaluacion del software.

• ISO 1498-3. Proceso para los desarrolladores: Indica la implementacion a nivel practicode la evaluacion cuando esta se lleva a cabo en forma paralela con el desarrollo del soft-ware, indicando los requerimientos y recomendaciones que deben ser tenidos en cuenta.Esta parte puede ser usada por los administradores de proyectos (para definir los re-querimientos de calidad o para realizar monitoreo y control de la calidad del softwaredurante el desarrollo), y puede ser util tambien al personal de aseguramiento de calidaddel software.

• ISO 14598-4. Proceso para los compradores: Esta parte contiene los requerimientos yrecomendaciones para realizar la evaluacion de la calidad del software durante la comprao adquisicion de productos de software.

• ISO 14598-5. Proceso para los evaluadores: Se proveen los requerimientos y recomenda-ciones para la implementacion practica de evaluaciones de productos de software.

Existen diferentes actividades para cada una de las etapas propuestas para el proceso deevaluacion, con las cuales se busca que el proceso para evaluar la calidad del software primeroestablezca los requerimientos de calidad para despues especificar, disenar y efectuar la evalua-cion.

5.1.2. Valoracion de productos de software en el ambito acedemico a nivel Nacional

En Colombia el estado ha buscado incentivar la generacion de nuevo conocimiento en cuanto aciencia, tecnologıa e innovacion en diversos sectores mediante la integracion de las diferentes insti-tuciones academicas y el Estado, con miras al progreso y desarrollo de la sociedad, a continuacionse numeran algunas de las instituciones que implementan procesos de valoracion de productos desoftware, en el Anexo 1 se puede encontrar mas informacion sobre su metodologıa:

13

UNIVERSIDAD DEL VALLE

La Universidad del Valle cuenta con un formato especıfico para la evaluacion de productividadacademica, modalidad de software avalado por el comite interno de asignacion y reconocimien-to de puntaje CIARP [8], este formato contempla dos modalidades:

• Produccion cientıfica.

• Produccion tecnologica con generacion de innovacion.

Cada especialista evalua diferentes criterios y la escala de valoracion, junto con un rango depuntajes numerico, esta dada por “bajo” (0-10-20-30-40 puntos), “medio” (50-60-70) y “alto”(80-90-100); y cada criterio tiene un porcentaje de importancia determinado (10 % para uncriterio y 9 % para los demas).

Los criterios de evaluacion de software en las dos modalidades, estan especificados por descrip-ciones del producto puestas a juicio. Estos son valorados por la figura de dos diferentesevaluadores, especialista en software y especialista en el area tratada por el producto desoftware.

UNIVERSIDAD DE ANTIOQUIA

En la Universidad de Antioquia, el comite de asignacion de puntajes, contemplado en eldecreto presidencial 1444 de 1992, es dirigido por el Vicerrector de Docencia, y tiene comofunciones determinar los puntajes correspondientes a los tıtulos universitarios y la productivi-dad academica contemplados en el Artıculo 1 ◦, lo referente a la remuneracion de los docentessin tıtulo universitario y la asignacion de puntajes a quienes ingresan o reingresan a la carreradocente.

Para el cumplimiento de estas funciones el comite tiene en cuenta criterios como calidadacademica, cientıfica, tecnica, humanıstica, artıstica o pedagogica; relevancia y pertinenciade los trabajos con las polıticas academicas; contribucion al desarrollo y cumplimiento de losobjetivos institucionales definidos en las polıticas de la Universidad.

En cuanto a la produccion de tecnologıa se tienen ciertos criterios de evaluacion y para que elsistema o proceso se le puedan asignar puntos salariales debe estar enmarcado dentro de unascategorıas propuestas por Colciencias, se le asigna el maximo puntaje cuando el producto seencuentra en la fase de transferencia tecnologica, lo que quiere decir que goza de aceptacionen el medio y es confiable.

UNIVERSIDAD NACIONAL DE COLOMBIA

La Universidad Nacional tiene la figura de ‘El Comite Interno de Asignacion y Reconoci-miento de Puntaje’, el cual es el organo interno universitario encargado de la asignacion yreconocimiento de bonificaciones, de puntos salariales por tıtulos, categorıas, experienciacalificada, cargos academico-administrativos y desempeno en docencia y extension y porproduccion academica, es por ello que tienen la mision de gestionar y apoyar de formaimparcial, amable, oportuna y veraz, el proceso de solicitud de asignacion y reconocimientode puntaje por la evaluacion de los productos academicos, tıtulos universitarios, experienciacalificada y desempeno en cargos academico administrativos de los docentes de planta de laUniversidad Nacional de Colombia.

14

Para realizar estos tramites cuentan con una aplicacion del sistema de informacion de talentohumano SARA [27] que se puede encontrar en la pagina web http://www.sara.unal.edu.co/,en la que a traves de la Hoja de Vida version web, los docentes de la Universidad, puedenhacer solicitudes y consultar el estado de las mismas en lınea.

COLCIENCIAS

El Departamento Administrativo de Ciencia, Tecnologıa e Innovacion Colciencias junto conel Consejo Nacional de Beneficios Tributarios en Ciencia, Tecnologıa e Innovacion (CNBT)promueven la calificacion de proyectos para otorgar la exencion de IVA en la importacion deequipos y elementos que seran destinados a proyectos de Ciencia, Tecnologıa e Innovacion,entre sus miembros cuenta con dos expertos en ciencia, tecnologıa e innovacion, designadospor el Director de Colciencias y su objetivo es fomentar el desarrollo de la investigacion enlas instituciones de educacion y los centros reconocidos, facilitando y disminuyendo el costode los equipos o elementos destinados a la ejecucion de proyectos de CT+I que requieran serimportados.

Para ello, Colciencias debera calificar segun los lineamientos del Consejo Nacional de Benefi-cios Tributarios el caracter en CT+I de los proyectos verificando la necesidad de los equiposa importar con destino a estos proyectos.

Entre las funciones del ‘Consejo Nacional de Beneficios Tributarios en Ciencia, Tecnologıa eInnovacion’ –CNBT– se encuentran:

• Establecer los criterios y condiciones para calificar los proyectos.

• Definir los procedimientos de control, seguimiento y evaluacion de los proyectos califica-dos como “de investigacion y desarrollo tecnologico”.

• Certificar los nuevos productos de software elaborados en Colombia, con un alto conte-nido de investigacion cientıfica y tecnologica nacional, de conformidad con el numeral 8del artıculo 207-2 del Estatuto Tributario.

5.1.3. Modelos de valoracion de productos de software a nivel internacional

McCall [32]

El modelo de calidad de McCall fue escrito en el ano 1977 por McCall [14], Richards yWalters, en un documento denominado “Factors in software quality’ ’, propone una serie defactores de calidad organizados en tres ejes o puntos de vista desde los cuales el usuario puedecontemplar la calidad de un producto de software:

1. Calidad en la operacion del producto: En general se requiere que este pueda ser claro ydetallado, que opere eficientemente y que los resultados sean los requeridos inicialmentepor el usuario.

2. Revision de calidad del producto. Tiene como objetivo realizar revisiones durante elproceso de desarrollo para detectar los errores que afecten a la operacion del productode software. Las revisiones involucran grupos de personas que examinan parte o todo elproceso del software, los sistemas o su documentacion asociada para descubrir problemaspotenciales. Las conclusiones de la revision se registran formalmente y se pasan al autoro a quien sea responsable de corregir los problemas descubiertos.

15

3. Calidad en el proceso. Desde este enfoque se recomienda definir o seleccionar estandaresy procedimientos que sirvan como marco de trabajo durante el desarrollo de software.En la Figura 2 se pueden apreciar la relacion que guardan estos tres aspectos.

Figura 2: Factores de calidad de McCall. Tomado de [23]

Cada factor determinante de la calidad, se descompone, a su vez, en una serie de criterioso propiedades que determinan su calidad. Los criterios pueden ser evaluados mediante unconjunto de metricas que indican en que medida el sistema posee una caracterıstica dada.

BOEHM [5]

En el ano 1978 Barry Boehm propuso un modelo que define la calidad de software en terminosde atributos cualitativos. El modelo es de naturaleza jerarquica y los criterios de calidad sepresentan en tres grandes subdivisiones:

1. Portabilidad: La facilidad con que el software puede ser llevado de un entorno a otro.

2. Usabilidad: Operacion del producto.

3. Mantenibilidad: La facilidad con que una modificacion puede ser realizada.

EL modelo de Boehm tiene como finalidad lograr que el software realice lo que desea elusuario, utilice recursos informaticos de manera correcta y eficiente, sea facil de utilizar yaprender, sea bien disenado, codificado, probado y mantenido. Este usa metricas directas eindirectas para determinar el nivel en el cual un criterio en particular afecta a los principalesfactores de calidad.

Cada factor se descompone en varios criterios, factores tales como portabilidad, confiabilidad,facilidad de mantenimiento y facilidad de modificacion son propiedades estaticas. La facilidadde prueba y la eficiencia dependen del comportamiento de las interpretaciones especıficas yconstituyen propiedades dinamicas.

GOAL QUESTION METRIC [31]

El enfoque “Goal Question Metric” (GQM) se basa en que, una organizacion para realizaruna medicion de forma adecuada, primero debe especificar las metas para sı mismo y susproyectos; entonces es necesario trazar esos objetivos y posteriormente definir los objetivosoperativos, para que finalmente proporcionen un marco para la interpretacion de losresultados con respecto a los objetivos fijados. Esta informacion pueden ser cuantificadasiempre que sea posible, y esta puede ser analizada desde la perspectiva de si o no se logran

16

los objetivos.

El modelo GQM es una estructura jerarquica como se puede ver en la Figura 3, a partir deun objetivo (especificando efectos de su medicion, objeto a medir, tema que se desea medir,y punto de vista desde el que se toma la medida). El objetivo se compone y estructura pormedio de varias preguntas, a su vez, cada pregunta se detalla y estructura por medio de lasmetricas. La misma metrica se puede utilizar con el fin de responder a diferentes preguntasbajo el mismo objetivo. Varios modelos GQM tambien pueden tener preguntas y metricas encomun, asegurandose de que, cuando se adopte la medida de hecho, los diferentes puntos devista se tienen en cuenta correctamente (la metrica podrıa tener valores diferentes cuando setoman desde diferentes puntos de vista).

Figura 3: Estructura jerarquica del modelo GQM. Tomado de [31] y traducido por los autores.

El modelo GQM se desarrolla mediante la identificacion de un conjunto de objetivos de calidady/o productividad, en las empresas, la division o nivel de proyecto; la satisfaccion del cliente,la entrega a tiempo, un mejor desempeno. A partir de esos objetivos y tomando los modelosdel objeto de medicion, derivamos preguntas que definen los objetivos de forma mas completa.

FURPS [7]

En 1987 Hewlett-Packard desarrollo una serie de factores de calidad que reciben el acronimo deFURPS, que incluye cinco (5) categorıas de calidad de software principales por sus nombresen ingles: funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability),desempeno (Performance) y facilidad de soporte (Supportability), de aquı el nombre del mo-delo. Se trata de variables sobre las que se incide durante todo el ciclo de vida del productocompuesto por diversas fases.

Los factores de calidad FURPS y atributos descritos anteriormente pueden usarse para esta-blecer metricas de la calidad para todas las actividades del proceso del software.

GILB [1]

El modelo de GILB (1988) establece una lista de caracterısticas que especifican los requisitosde calidad para un software. Estas se dividen en dos tipos [1]:

1. Originales

2. Modelos Tradicionales

17

Mediante el metodo GILB es posible especificar los atributos de calidad de software en formacuantitativa, incluyendo tanto tiempos de respuesta como conceptos conocidos de usabilidady portabilidad, entre otros.

Este modelo propone caracterısticas como la correccion, la integridad, la facilidad de mante-nimiento y la facilidad de uso, como base para proporcionar indicadores utiles para los equiposde trabajo y sugiere las definiciones, puntos de vista y medida para cada uno de las siguientescaracterısticas:

• Correccion: Grado en el que el software lleva a cabo su funcion requerida. Si un programano opera correctamente, no dara valor agregado a sus usuarios.

• Facilidad de mantenimiento: Posibilidad de corregir un programa si se encuentra unerror, adaptarlo si cambia su entorno, mejorarlo si el cliente desea un cambio.

• Integridad: Habilidad de un sistema para resistir ataques, tanto accidentales como inten-cionados, contra su seguridad, a nivel de cualquiera de los tres principales componentesdel software: programas, datos y documentos. Para medir la integridad, sugiere la utili-zacion de otros dos atributos como base:

◦ Amenaza: Es la probabilidad (que se puede estimar o deducir de la evidencia empıri-ca) de que un ataque de cualquier tipo ocurra en un tiempo determinado.

◦ Seguridad: Es la probabilidad que se pueda repeler un determinado ataque.

• Facilidad de uso: Es un intento por cuantificar “lo amigable que puede ser el productocon el usuario”

QUALITY MODEL FOR OBJECT-ORIENTED DESIGN [13]

El modelo denominado Quality Model for Object-Oriented Design (QMOOD+) fue desarro-llado por Jagdish Bansiya y Carl G. Davis [13], presenta un modelo para la evaluacion deatributos de calidad de alto nivel en diseno orientado a objetos, consta de cuatro niveles (L1 aL4) conectados entre sı, ademas contiene seis atributos de calidad (reusabilidad, flexibilidad,comprensibilidad, funcionalidad, extensibilidad y efectividad) y once propiedades de disenoque complementan a los atributos y posee una serie de metricas para la evaluacion de losmismos.

Figura 4: Niveles y enlaces del modelo Bansiya. Tomado de [13] y traducido por los autores.

En cada uno de los enlaces, Bansiya y Davis identifican relaciones explıcitas entre componentesde ambos niveles, el peso de cada atributo puede ser negativo o positivo y se han ido calculandode manera intuitiva, de hecho, los autores informan que los pesos se pueden variar paraajustarse a los objetivos perseguidos por la organizacion que haga uso del modelo. Ademas

18

de ello, el grado de importancia de cada atributo de calidad es relativo pues queda a criteriodel disenador y no propiamente el de un experto.

QUAMOCO [30]

Expertos en calidad de software, tanto del mundo academico como de la industria en Alemaniase unieron para crear el proyecto de investigacion Quamoco. El proyecto esta formado porpersonas de la Universidad Technische de Munich, SAP, Siemens, Capgemini, FraunhoferIESE e Itestra.

Entre los modelos de calidad desarrollados anteriormente se recogen ciertos aspectos decalidad, por ejemplo, los atributos mencionados por la ISO 25010 [29] son importantes perocostosos para un sistema de software especıfico, es por ello que se concentran en los factorescon mayor impacto [26] [15] y los toman como base para la especificacion de los requisitosde calidad desarrollando un metodo explıcito, pero no todos los elementos son importantesy es poco practico construir un unico modelo, por lo que ellos introducen un conceptoque permite dividir el modelo de calidad en modulos. Tambien desarrollaron un metodode adaptacion explıcito, que guıa a un responsable de calidad en la eleccion de los aspec-tos relevantes para la calidad de productos, factores y medidas para cada tipo de proyecto. [18]

Metodo de evaluacion de la calidad

En la Figura 5 se pueden observar las actividades de evaluacion de la calidad dentro de laestructura jerarquica del modelo base. En el lado izquierdo, hay actividades y productosesenciales que se necesitan para hacer operativo el modelo y ası llevar a cabo las evaluaciones.

Figura 5: Vista general del enfoque de evaluacion de calidad.Tomado de [30]

En el lado derecho, se encuentra las actividades realizadas durante la evaluacion de un pro-ducto especıfico y sus salidas. Inicialmente se tiene:

1. Definicion de Medidas / Medicion: Se asocian las medidas para todos los datos de entradanecesarios para la evaluacion de la calidad con los instrumentos de medicion adecuados.

19

Cada medida fue revisada por dos expertos en medicion, ellos plantearon una medidanormalizada basada en un conjunto definido de reglas (M1, M2, M3, ....Mn). Las medidascuantifican los factores que se encuentran en el nivel mas bajo en la jerarquıa de gestionde calidad. Durante la aplicacion, se recogen los datos de la medicion objetiva. Para hacerfrente a los datos de medicion incompleta, el enfoque utiliza aritmetica de intervalos paradeterminar la gama de posibles resultados para los factores.

2. Definicion de funciones de utilidad/puntuacion: Durante la parte operativa se define unafuncion de utilidad para cada medida de los factores. El factor de utilidad se define comola suma ponderada de las utilidades de todas las medidas relacionadas con el factor. [30]

3. Definicion de pesos factoriales y adicion de operador: Se especifica la importancia relativade los elementos adyacentes de la gestion de calidad, donde entre los elementos se incluyenlos factores y las medidas directamente asociadas a los del nivel mas bajo. Los pesosdeben estar entre 0 y 1. Para apoyar dicho peso de manera eficiente utilizaron el metodode orden de rango Centroide [3] para calcularlo de forma automatica basandose en unaclasificacion de relevancia entre factores del mismo nivel, usando el enfoque Swing [9].

4. Definicion y aplicacion de la interpretacion del modelo: Estas actividades apoyan la tomade decisiones en la interpretacion de la utilidad del factor, si es apropiado o no.

Figura 6: Cadena de herramientas Quamoco.Tomado de [10].

El modelo base fue disenado de forma que permita ser utilizado inmediatamente y sin ningunamodificacion para cualquier proyecto de software, independiente del dominio de aplicacion,ademas como parte de su contribucion contienen un conjunto de herramientas integradas paraambos modelos tanto de calidad como de evaluacion [10] dejando a disposicion el sitio webQuamoco [25].

5.1.4. Comparativo modelos de valoracion a nivel de productos de software

Al realizar un recorrido por todos y cada uno de los modelos de valoracion de calidad del soft-ware desde la decada de los 80’s hemos podido evidenciar en cada uno de ellos ciertas fortalezas ydebilidades que han servido para retroalimentar los modelos mas recientes. Entre los factores comu-nes de todos los modelos analizados hemos encontrado dos grandes grupos, el primero, contempla lacantidad de expertos evaluadores y su naturaleza frente a la especificacion del software, el grado deinstrumentalizacion y el tipo de valoracion realizada sobre los productos de software. El segundo,se enfoca en la cantidad de atributos de calidad que abarca modelo sobre los productos de software

20

y como ha evolucionado a traves del tiempo. Podemos observar en la Tabla 1 las caracterısticaspertenecientes a los diferentes modelos para medir la calidad de productos de software:

1. Modelo: Listado de los modelos incluidos en la categorıa de “Modelos de valoracion de pro-ductos de software”.

2. Naturaleza de evaluadores: Los evaluadores son aquellos que valoran y fijan una calificaciona las diferentes caracterısticas de un producto de software, de acuerdo a unas especificacionesdadas por el modelo.

3. Grado de instrumentalizacion: A cada modelo se le puede otorgar un grado de instrumenta-lizacion, teniendo en cuenta ciertos criterios junto con una calificacion (1, 2 o 3) donde 1 esel grado mas bajo y 3 el grado mas alto, segun la siguiente descripcion:

a) El modelo no es claro y ademas no especifica herramientas, software, manuales o ins-tructivos claros para aplicar el modelo.

b) El modelo es presentado de manera clara, mas no posee herramientas, software, manualeso instructivos claros para aplicar el modelo.

c) El modelo es presentado de manera clara y especifica mecanismos acerca de su modo deuso.

4. Tipo de evaluacion

Cuantitativa: La evaluacion cuantitativa establece que sus datos son fruto de medicionesnumericas.

Cualitativa: Sus datos son el resultado de la apreciacion de la calidad; no del cuantosino del como, por lo cual calificar cualitativamente consiste en describir el hecho que seevalua, reducir el juicio valorativo a la eleccion de un grado de cumplimiento de ciertacualidad en una escala.

En el caso que algun criterio no se especifique, no este disponible o no este explıcitamentepresentado en el modelo se utiliza la siguiente convencion:

N/E : No especificado

En la Tabla 2 podemos observar una lista de atributos que a lo largo de los anos se han venidoincorporando en el conjunto de atributos de calidad que identifican a un producto de software,en las siguientes columnas se pueden observar los modelos de valoracion que manejan entre sudefinicion el concepto de atributos o factores. En la tabla se marcan los atributos que son manejadospor cada modelo y en la ultima fila se da un total de los atributos resaltando que el modelode valoracion de productos de software KITE [19] es uno de los que mas atributos de calidad trabaja.

Segun el analisis del estado del arte, la revision de los modelos de valoracion de calidad masrepresentativos y la comparacion a cada de uno de los procesos de valoracion hacia los productos desoftware, vemos las fortalezas y beneficios que ofrece el modelo de valoracion de calidad KITE [19],permitiendo abarcar la mayorıa de las caracterısticas de un producto de software, no solo en elambito tecnologico sino permitiendo reconocer en el una fuente de conocimiento para toda lacomunidad academica.

21

Tabla 1: Cuadro comparativo modelos de valoracion de productos de software. Elaborado por autores

22

Tabla

2:

Cuadro

com

para

tivo

model

os

de

valo

raci

on

de

pro

duct

os

de

soft

ware

por

atr

ibuto

sde

cald

iad.

Ela

bora

do

por

auto

res

23

5.2. Marco referencial teorıco-conceptual

El modelo KITE [19], presentado en el 2013, es una propuesta para valorar productos de softwaredesarrollados en el ambito academico. Sus siglas hacen referencia a 4 ejes propuestos por los autores:

K: New knowledge dissemination effect (Efecto en la diseminacion o avance en el conocimien-to).

I: Impact in target population (Impacto en la poblacion usuaria potencial).

T: Technological innovation (Innovacion tecnologica).

E: Engineering achievement (Calidad desde la perspectiva de la Ingenierıa de Software).

Valorar la complejidad inherente al desarrollo de un producto de software de calidad, es aquelloque buscan abarcar los anteriores ejes. Cubriendo aspectos como la investigacion que se llevo previaal desarrollo del producto de software, si su funcionamiento es aquel que se espera por el nicho depoblacion al cual va dirigido para su utilizacion, la facilidad para acceder al producto y el hechode que sea un software robusto, seguro y documentado.

Los resultados que estos ejes arrojan son presentados de manera grafica, uniendo rectas entrelos puntos donde los ejes marcan una determinada puntuacion, se dibuja una cometa en forma derombo, y su area varıa de acuerdo a la evaluacion final de los ejes. El modelo grafico propuesto semuestra en la Figura 7.

Figura 7: Propuesta grafica modelo KITE. Tomado de [19]

Cada atributo de calidad es evaluado y su resultado determina el rango de valores maximosque puede tomar cada eje en la grafica de valoracion de un producto. Se hace la suposicion que elmejor producto de software academico dara forma a un cometa con una superficie equivalente a100 puntos. Ası, se define el rango en cada determinante, estos valores son el resultado de usar unaecuacion matematica establecida en el modelo para cada eje.

E ∈ [0 . . . 16] ,K ∈ [0 . . . 4] , T ∈ [0 . . . 6] , I ∈ [0 . . . 4] (1)

En la siguiente imagen se muestra el area formada por los valores maximos que puede tomaruna valoracion de un producto de software:

24

Figura 8: Valores maximos posibles para el modelo KITE. Tomado de [19]

La definicion de los ejes, se presenta en los siguientes parrafos y se denominan tambien comodeterminantes. A su vez se muestran los atributos que abarca cada determinante.

Determinante E: Se encamina a dar un indicador del grado de calidad a nivel de ingenierıade software, ofreciendo ası, garantıas para su desarrollo a gran escala o nivel industrial. Estedeterminante tiene una gran relevancia dentro del modelo debido a que brinda una medidadel cumplimiento de las practicas y principios de ingenierıa de software que el producto tiene.Los atributos que contiene el determinante E, se muestran a continuacion:

• Robustez

• Extensibilidad y mantenibilidad

• Desempeno

• Usabilidad

• Integridad

• Portabilidad

• Compatibilidad

• Documentacion

La suma de los valores de cada atributo, tendra un valor maximo de 16. Este se calcula pormedio de la siguiente formula:

E =

8∑i=1

Ei (2)

Determinante T: Tiene como objetivo determinar que grado de innovacion tecnologica haaportado el producto de software. La innovacion es definida como la formulacion de una ideanovedosa, por lo que se presentarıa cuando un producto de software propone un nuevo usode una tecnologıa existente, o cuando se proponen nuevas tecnologıas. Dentro del modelo,se busca que con la medida de este determinante, esa idea innovadora, este desarrolladade manera completa en un nuevo contexto como producto. Los atributos que contiene eldeterminante T, se muestran a continuacion:

• Novedad

25

• Alcance

• Singularidad

• Superioridad

• Originalidad

• Nivel de Endogamia

La suma de los valores de cada atributo, tendra un valor maximo de 6. Este se calcula pormedio de la siguiente formula:

T =6∑

i=1

Ti (3)

Determinante K: Tiene en cuenta la importancia que puede tener un producto de softwarepara un area academica, por lo que busca que la difusion de nuevo conocimiento, surgidode la investigacion y desarrollo del software, sea un indicador de calidad. Los atributos quecontiene el determinante K, se muestran a continuacion:

• Inventiva

• Diseminacion

La suma de los valores de cada atributo, tendra un valor maximo de 4. Este se calcula pormedio de la siguiente formula:

K = K0K1 (4)

Determinante I: La razon de incluir este determinante en el modelo, es dar una medida deque tan visible y disponible esta para su poblacion objetivo, ası como su utilizacion. Es unindicador que resalta el impacto que tiene un producto de software, sus actualizaciones oversiones futuras del mismo. Esto conlleva a la motivacion por parte de los desarrolladoresdel campo academico, de mejorar el producto por medio del uso de nuevas tecnologıas ofuncionalidades, dando ası una vision de la influencia que tienen en el desarrollo de software:

• Cobertura

• Disponibilidad

• Utilizacion

• Liberalidad de Uso

La suma de los valores de cada atributo, tendra un valor maximo de 4. Este se calcula pormedio de la siguiente formula:

I =

4∑i=1

Ii (5)

Un producto de software se puede evaluar mediante el calculo de la puntuacion obtenido a partirde la suma de las areas en las regiones triangulares resultantes en cada cuadrante.

S� =1

2(K + T )(E + I) (6)

26

5.3. Marco referencial tecnologico

En este proyecto se utilizaron una serie de herramientas que apoyaron el proceso de diseno ymodelado de cada uno de los elementos de este trabajo. A continuacion se describe cada uno de ellos:

Herramientas de diseno

Para describir el ciclo de vida de un producto de software y representar el modelo de computoque hace parte de la instrumentalizacion de los guiones de prueba se vio la necesidad de utilizarunas herramientas que nos permitieran disenar de una manera flexible estos procesos:

Modelado de maquinas de estado utilizando UML 2.4.1

Diseno de diagramas de actividad para los modelos de computo utilizando UML 2.4.1

Modelado de procesos para el ciclo de vida del producto de software utilizando BPMN 2.0.

1. Herramienta de modelado Enterprise Architec 13 [16]

El ambiente de modelado de Enterprise Architec esta potenciado por UML 2.4.1, abarca elciclo de vida completo del desarrollo de software, con herramientas que pueden proveerle unaestructura competitiva en modelado de negocio, diseno de software, ingenierıa de sistemas,arquitectura de empresas y gestion de requisitos, cuenta las siguientes caracterısticas:

Incluye los 14 diagramas UML 2.x

Repositorio escalable

Interfaz rapida e intuitiva

Herramientas estables y probadas

Rapida descarga e instalacion de extensiones

BPMN, SysML, DDS, TOGAF, Zachman Framework y UPDM

Archimate, ArcGIS

Control de versiones

2. Herramienta de modelado Bizagui Modeler 3.1 [4]

Desde diseno y modelado hasta automatizacion e implementacion, Bizagi Suite apoya el ciclode vida completo de BPM. Es el reconocido ambiente de modelado BPMN mas potente delmercado, Bizagi Modeler permite a los expertos en negocios disenar, documentar y evolucionarsu modelo de proceso con total confianza. Entre sus caracterısticas encontramos:

Servicios de colaboracion en la nube

Notacion BPMN 2.0

Simulacion de procesos

Multi-idioma

27

6. MARCO METODOLOGICO

Al empezar a desarrollar el planteamiento dado en el anteproyecto vimos la necesidad de realizaralgunos ajustes a la metodologıa puesto que fue necesario profundizar y ajustar ciertos procesospara facilitar la labor de los expertos evaluadores quienes apoyan el proceso de valoracion y asımismo darle mas peso al ciclo de vida del producto de software en todo el proceso de valoracion.A continuacion se describe la metodologıa implementada en el desarrollo del proyecto:

1. Revision del Estado del Arte

La primera etapa en este proyecto consistio en hacer una revision completa del estado delarte, entendiendolo como un estudio analıtico del conocimiento acumulado que hace partede la investigacion documental y que tiene como objetivo profundizar y sistematizar la pro-duccion en un area del conocimiento en especıfico, es por ello que se realizo una revision yanalisis profundo sobre las tendencias, informacion y vacıos sobre los modelos de evaluacionde software a nivel de procesos y buscamos profundizar en aquellos modelos que se centranen una evaluacion sistematica y formal a nivel de productos de software, se hizo una revisioncompleta sobre el material documental, artıculos, tesis, proyectos, estandares, entre otros, ya su vez se consideraron los siguientes criterios de clasificacion:

Modelos y estandares internacionales de valoracion de calidad de software a nivel deproducto de software.

Modelos y estandares nacionales de valoracion de calidad de software a nivel de productode software.

Modelos de evaluacion nacionales de software desarrollados en el ambito academico, odesarrollados con fines academicos

2. Sistematizacion de la informacion

En esta etapa se realizo el estudio profundo del modelo de valoracion de atributos de calidadKITE [19]. Se profundizo sobre el estudio del modelo conceptual, sus manuales procedimen-tales y formalizacion del ciclo de vida de un producto de software sometido al ejercicio devaloracion. Ver Figura 10.

3. Recopilacion de datos

Se realizo una exploracion sobre los posibles productos de software candidatos a ser validadoscon el modelo KITE [19].

4. Caracterizacion y recopilacion de los productos

Se tomo la lista completa de los productos de software candidatos y se seleccionaron aquellosque cumplian con los criterios de seleccion previamente mencionados, y de cada uno de ellos sedetermino la intencionalidad con la que fue seleccionado, los expertos de software y tematicos,y a su vez se agruparon en tres categorıas:

“Open Source”version estable

Prototipos Academicos

Propietarios

Para que un producto de software se tomara en cuenta en el ejercicio de valoracion se debıatener a disposicion el archivo ejecutable y ademas adjuntar alguno de los siguientes elementos:

28

Modelos funcionales, estructurales, dinamicos y arquitectonicos.

Codigo Fuente

Manual de usuario

Documentacion

Es importante aclarar que entre mas documentacion se encontro, fue mas exacta la evaluacion.

5. Diseno y elaboracion de instructivos o guiones

En esta etapa se realizaron los instructivos o guiones para la valoracion de calidad de losrespectivos productos de software usando el modelo KITE [19]; es decir, los pasos que sedeben ejecutar para que atributos y subatributios de calidad del producto de software seanvalorables.

6. Validacion o aplicacion del modelo

Se realizo la valoracion de calidad de los productos de software por parte de losexpertosevaluadores (expertos de software, expertos tematicos) usando el modelo KITE [19] con losinstructivos o guiones previamente realizados a todos y cada uno de los productos de soft-ware seleccionados. Se dio un periodo de tiempo determinado para dicha valoracion y serecolectaron los resultados de cada uno.

7. Analisis de Resultados

Seguido a la realizacion de la valoracion de los productos de software se analizaron e interpre-taron los resultados obtenidos en el ejercicio de evaluacion y a partir de ellos se determino:

Procesamiento y analisis de los resultados obtenidos de cada una de los productos desoftware en cada categorıa.

Procesamiento y analisis de los resultados obtenidos por categorıas, verificar similitudesy patrones determinantes.

Identificar fortalezas y debilidades del modelo de evaluacion KITE [19], y a su vez con-siderar dificultades y retos al momento de realizar la valoracion de calidad por parte delos expertos.

8. Retroalimentacion de resultados hacia los instructivos

A partir de los resultados y conclusiones obtenidos del punto anterior, se retroalimentaron losinstructivos y guiones del modelo de evaluacion y se realizaron sus respectivas correcciones.

29

7. APLICACION DE LA METODOLOGIA

7.1. Determinacion de las perspectivas de la valoracion usando KITE

El modelo de valoracion de calidad de productos de software KITE [19] se desarrolla bajotres perspectivas, la primera es la perspectiva del proponente de software, que puede ser el autor,desarrollador, o persona que desea incluir el producto de software en el ejercicio de valoracion, lasegunda es la perspectiva del experto evaluador de software, quien es el encargado de valorar ladeterminante (E) relacionada con los aspectos de calidad de software, y por ultimo, la perspectivadel experto evaluador tematico que se encarga de valorar los determinante de conocimiento,impacto e innovacion tecnologica.

Para realizar la valoracion de un producto de software se siguen los pasos descritos en la Figura 9.El ejercicio de valoracion depende de los atributos de calidad seleccionados y soportados por elproponente del producto de software. El experto evaluador ya sea tematico o de software deberavalidar las aseveraciones plasmadas para cada una de las preguntas de los atributos seleccionadospara los productos de software, contando como insumo fundamental los soportes relacionados porel proponente.

7.1.1. Perspectiva del proponente del producto a valorar

El proponente del producto de software es aquella persona que desea postular un producto desoftware para el ejercicio de valoracion de atributos de calidad, puede ser el desarrollador del pro-ducto, autor registrado, lıder tecnologico de una companıa empresarial con acceso a la informaciondel producto, integrante de grupos de investigacion, entre otros, esta persona tendra las siguientesfunciones:

Recolectar los soportes necesarios para aplicar al ejercicio de valoracion. Ver Anexo 5.

Segun su conocimiento sobre el producto de software debera seleccionar los atributos (atri-butos propuestos por el modelo KITE [19]) que desea que sean evaluados para su producto.

Diligenciar los guiones de prueba de acuerdo a los atributos seleccionados, realizar las ase-veraciones de su producto segun corresponda y a su vez asociar para cada uno los soportesnecesarios. Ver Anexo 10.

Al finalizar el ejercicio de registro se podra tener una vista parcial de los resultados generadosen la valoracion por parte del proponente, es un estimado de como ve el proponente a su productode acuerdo al modelo KITE [19].

30

Figura

9:

Pro

ceso

gen

eral

del

ejer

cici

ode

valo

raci

on.

Ela

bora

do

por

auto

res

31

7.1.2. Perspectiva del experto evaluador tematico

El modelo KITE [19] se ha disenado teniendo en cuenta el merito de desarrollar un productode software como un vehıculo de diseminacion de nuevo conocimiento originado en actividades deinvestigacion aplicada o basica, valorar el grado de innovacion tecnologica logrado con el productode software, y finalmente el impacto que este tiene en su version actual o futuras. De esta manera, elmodelo se orienta a promover la continuidad de los proyectos de software desde los grupos o unidadesdesarrolladoras del producto, quienes lo evolucionan con nuevas tecnologıas y funcionalidades. Portodas estas caracterısticas es necesario contar una persona experta en el area tematica especificaen la que se desarrolla el producto de software, para ası tener el criterio suficiente de validar o nolas aseveraciones realizadas por el proponente. Al igual que el experto de software puede acceder alos soportes y debera dar su juicio experto frente a cada aseveracion.

7.1.3. Perspectiva del experto evaluador de software

El modelo KITE [19] contempla al Software desde el ambito academico entendido como unesfuerzo especial en desarrollar prototipos de software, pero a su vez es posible aplicarlo en productosde software que han sido desarrollados a nivel empresarial buscando en ellos explorar aquellascaracterısticas que lo hacen de calidad. El experto de software debe ser una persona idonea en elarea de ingenierıa de software, teniendo los conocimientos suficientes para lograr validar atributosde calidad [19], y ser capaz de profundizar en las aseveraciones realizadas por el proponente, realizarla revision de los soportes brindados y dar su juicio experto frente a cada uno de ellos. La labor delexperto evaluador de software es solo de validador, el no se encarga de diligenciar ningun guion,solo dar su juicio experto frente a las aseveraciones del proponente.

En el desarrollo del proyecto se vio la necesidad de facilitar la labor de los expertos evaluadores,puesto que los tiempos de diligenciamiento de los guiones de prueba es extenso y requiere de unconocimiento previo sobre el producto de software (ver capıtulo analisis de resultados), es por esoque se asigno dicha responsabilidad a los proponentes y los expertos evaluadores adquieren la tareade ser validadores de las aseveraciones y soportes dados por el proponente.

7.2. Comprension de los estados de un producto de software bajo el modeloKITE

En el proceso de entendimiento del ciclo de valoracion de un producto de software se en-contro que de acuerdo al actor se presentan tareas diferentes. Una era el registro y valoracion delproducto por parte del proponente y la otra era la validacion por parte del experto.

Se encontro que no es sencillo determinar el momento en el que un proponente termina derealizar las aseveraciones acerca de la calidad de su producto de software y decide someterlo avaloracion, o cuando un experto completa una valoracion desde la perspectiva tematica pero elexperto de software aun no lo hace.

Por lo anterior se da la necesidad de crear una serie de Estados, dentro del ciclo de valoracion deun producto de software no solo se contemplan las evaluaciones desde cada perspectiva (softwarey tematico), tambien se debe tener en cuenta el proceso de asignacion de expertos evaluadores,tiempo de registro de aseveraciones y soportes por parte del proponente.

Una maquina de estados brinda la solucion para identificar los diferentes estados del productodentro del ciclo de valoracion. Se considero que la transicion de un estado a otro no solo se podıa dar

32

por acciones de un actor determinado, puede ser debido al superar un margen de tiempo especificadoen dıas.

En la Figura 10 se presenta la maquina de estados propuesta para el entendimiento del ciclo devida de un producto sometido al modelo de valoracion de calidad KITE [19] y una breve descripcionde sus diferentes estados1:

Registration pending : Es el estado inicial y corresponde al momento donde el proponenterealiza las aseveraciones y adjunta evidencias para soportar la calidad de su producto. Quiendecide proseguir con el ciclo de valoracion (transicion al siguiente estado) sera el proponenteal decidir que esta listo para que su producto sea sometido a evaluacion.

Checking prerequisites: Corresponde a una etapa donde se puede establecer margenes decalidad (coherencia, formato) sobre los soportes o evidencias presentados por un proponente.Solo si se superan dichos criterios se puede proceder a la transicion a los estados propios devaloracion.

Expert reviewer assigment (Software): Aquı se debe definir el experto encargado de realizarla valoracion desde la perspectiva de software. Se pueden definir criterios de carga de trabajoy disponibilidad para la asignacion de evaluadores a un producto.

Expert reviewer assigment (Domain): Aquı se debe definir el experto encargado de realizarla valoracion desde la perspectiva tematica. Se pueden definir criterios de carga de trabajo,disponibilidad y naturaleza del producto para la asignacion de evaluadores.

Awaiting expert confirmation (Software): Al definir el experto encargado de la valoraciondesde la perspectiva de software, este debe decidir si aceptar dicha asignacion, el cual sepuede negar en ciertos casos, como por ejemplo si considera que dado el poco conocimientoen el campo del producto de software es incapaz de dar un criterio confiable sobre lo aseveradopor el proponente.

Awaiting expert confirmation (domain): Al definir el experto encargado de la valoracion desdela perspectiva de tematica, este debe decidir si aceptar dicha asignacion, el cual se puede negaren ciertos casos, como por ejemplo si considera que dado el poco conocimiento en el campodel producto de software es incapaz de dar un criterio confiable sobre lo aseverado por elproponente.

Expert assessment period (software): Este es el estado concreto en donde un experto evaluadorde software valida las aseveraciones realizadas por el proponente apoyandose en los soportesbrindados. El experto sera el encargado de notificar la finalizacion de la evaluacion. Delanterior ejercicio se determinara la puntuacion final del determinante E(Ingenierıa).

Expert assessment period (domain): Este es el estado concreto en donde un experto evaluadortematico valida las aseveraciones realizadas por el proponente apoyandose en los soportesbrindados. El experto sera el encargado de notificar la finalizacion de la evaluacion. Delanterior ejercicio se determinara la puntuacion final de los determinantes K(Conocimiento),I(Inventiva) y T (Innovacion tecnologica).

1La maquina de estados se encuentra en un idioma diferente debido a que hace parte de un articulo en Ingles queaun esta en construccion

33

Assessment completed : Solo cuando se han finalizado las valoraciones de calidad del produc-to de software desde las dos perspectivas, de software y tematico, el producto de softwarehabra terminado el ciclo de valoracion. Aquı se consolidan los resultados finales por determi-nante y por atributos de calidad.

Registration archived : Este estado identifica cuando un producto de software no ha superadolos criterios establecidos para continuar con el ciclo de valoracion de atributos de calidad enun tiempo determinado.

Figura 10: Definicion maquina de estados. Ciclo de valoracion de un producto de software. Elaboradopor autores

34

7.3. Elaboracion de guiones de prueba

Hasta el incio del proyecto, el modelo KITE [19] contaba solamente con un Manual devaloracion de productos de software compuesto por unas listas de chequeo para cada determinante,pero entre sus condiciones los expertos evaluadores y los proponentes deben conocer el modelo aldetalle junto con los instrumentos de las listas de chequeo.

Los guiones de prueba propuestos, ver Figura 12, facilitan esta labor, se elaboraron 54 guionesde prueba en los que se plantean una serie de preguntas mas sencillas para poder dar una respuestaacertada a cada uno de los subatributos o preguntas planteadas por el modelo KITE [19].

A continuacion, se describira su estructura y la extrapolacion al modelo KITE [19]. Los guionesde prueba elaborados se pueden encontrar en el Anexo 6.

7.3.1. La estructura basica de un guion de prueba

Los guiones de prueba estan compuestos por tres grandes secciones, en la primera podemosencontrar los preliminares como se puede observar en la Figura 11, esta conformado por los soportesdel producto asociados por el proponente que seran utilizados por parte de los expertos evaluadorespara validar las aseveraciones y las herramientas de apoyo (script, documentacion, etc.) que sonrecursos que se le facilitan al experto evaluador para facilitar la validacion de lo indicado por elproponente.

Figura 11: Preliminares guion de prueba K1. Elaborado por autores

En la seccion del proponente se proponen varias preguntas que responden a la preguntaplanteada en el subatributo del modelo KITE [19] y que seran diligenciadas por el proponente desoftware, estas seran las denominadas aseveraciones. En la seccion del experto evaluador se planteala opcion de indicar si se esta de acuerdo o no con la aseveracion del proponente. Esta seccion sedescribe a profundidad en el apartado 6.3.2.

La tercera y ultima seccion es el modelo de computo del guion de prueba, esta es una extrapo-lacion del resultado dado en el guion de prueba a los valores de los subatributos planteados en elmodelo KITE [19]. Esta seccion se profundizara en el apartado 6.3.3.

35

Figura

12:

Eje

mplo

guio

nde

pru

eba.

Ela

bora

do

por

auto

res

36

7.3.2. Tipos de indagacion o preguntas

El modelo KITE [19] esta compuesto por atributos y subatributos, por ejemplo, el atributode Portabilidad (E6) contiene 3 subatributos como se observa en la Figura 13, al responder estossubatributos se da una puntuacion y al ponderarlos todos se obtien una valoracion parcial alatributo. En ciertas ocasiones no es tan facil responder al planteamiento de los subatributos, a veceses necesario tener una granularidad mas fina para dar con una respuesta acertada. Los guionesde prueba permiten dar una solucion a estos inconvenientes, se elaboraron en total 54 guiones deprueba, uno por cada subatributo del modelo KITE [19], cada uno plantea un cuestionario queayudan a responder o dar una puntuacion al subatributo indicado.

Figura 13: Definicion subatributos Portabilidad (E6). Tomado de [19]

Estas preguntas son presentadas al proponente del producto de software, el debe responderlas ya su vez dar una justificacion que sustente la aseveracion realizada, adicionalmente debe anexar lossoportes correspondientes con los cuales el experto podra constatar lo indicado por el proponentecomo se indico en la seccion de preliminares. Todas las preguntas planteadas en el guion estandadas para darle un valor al subatributo y facilitarle el proceso de valoracion al proponente desoftware.

Figura 14: Ejemplo de formato de pregunta. Guiones de prueba. Elaborado por autores

Como se observa en la Figura 14, cada pregunta de la seccion del proponente tiene a su vez unaseccion del experto evaluador, en ella se plantea la siguiente afirmacion: ”Frente a la respuesta dada

37

por el proponente su apreciacion es:”, el experto evaluador puede estar de acuerdo o en desacuerdocon:

Las respuestas del proponente y su justificacion.

Los soportes asociados para verificar las afirmaciones dadas por el proponente.

El experto evaluador puede asociar soportes que apoyen la justificacion de la opcion seleccio-nada.

Entre los tipos de preguntas que se desarrollaron se pueden clasificar de la siguiente manera:

Preguntas con unica respuestaSon aquellas que se contienen dos o mas opciones y el usuario unicamente puede seleccionaruna de ellas. Tıpicamente cada opcion tiene una equivalencia directa con una las opciones delmodelo KITE.

Figura 15: Pregunta con unica respuesta, tomada del guion de prueba I2-Asequibilidad. Elaborado porautores

Preguntas con multiple respuestaSon aquellas que se contienen dos o mas opciones y el usuario puede seleccionar una o masde ellas. Tıpicamente tienen como objetivo medir la puntuacion de acuerdo al numero deopciones marcadas. Se establece un rango de valores equivalentes con una opcion del modeloKITE.

Figura 16: Pregunta con respuesta multiple, tomado del guion de prueba I2-Cobertura. Elaborado porautores

38

Preguntas condicionalesSon aquellas que se contienen dos o mas opciones , el usuario unicamente puede seleccionaruna de ellas y esta puede habilitar o no la resolucion de otra pregunta. Si se selecciona una´opcion que habilita otra , la segunda es la que determinara el puntaje y la equivalenciadirecta con las opciones del modelo KITE [19]. Si por el contrario se selecciona una opcionno habilitante se seleccionara la opcion de mas baja puntuacion segun el modelo KITE [19].Tıpicamente corresponde a opciones de tipo booleano (Si o No).

Figura 17: Pregunta condicional, tomado del guion de prueba E2.3-Extendibilidad y mantenibilidad.Elaborado por autores

7.3.3. Modelos de computo definidos y correspondencia al modelo conceptual KITE

El diligenciamiento del guion de prueba que contempla las aseveraciones del proponente ylas validaciones del experto, requerıa de un mecanismo que interpretara dichos datos para poderdeterminar la opcion del subatributo mas indicada dentro del modelo KITE [19].

Por lo que se propuso una seccion denominada ”Modelo de computo” compuesto por un arbolde decision modelado con diagramas de actividad, una ecuacion logica relacionada y un cuadro deequivalencia para las puntuaciones del modelo KITE [19].

Arbol de decision modelado con diagramas de actividad

La resolucion de un guion de prueba puede modelarse como un flujo definido dado una tomade decisiones, teniendo en cuenta tanto las optadas por el proponente como las del experto.Un proponente toma una decision al seleccionar una opcion de una pregunta del guion deprueba, pero el experto determinara el flujo a seguir dependiendo de su decision, si esta deacuerdo o no.

Se decidio optar por el modelado de arboles de decision mediante diagramas de actividad segunla especificacion UML 2.x, dado que nos brinda la flexibilidad de modelar flujos determinadospor decisiones. Se consideran dos tipos de actividades, una identifica la accion de diligenciaruna pregunta de un guion de prueba por parte del proponente y otra actividad similar, peropor parte del experto.

Las decisiones corresponderan a nodos de decision y solo se presentara dos tipos diferentes,el primero preguntando que opcion selecciono el proponente (varıa la cantidad de opcionessegun el guion) y el segundo preguntando que opcion selecciono el experto (Si o No).

Ecuacion modelo de computo

Para la implementacion de los posibles flujos que se evidencia en un diagrama de actividadse construyo una ecuacion. Dicha ecuacion esta constituida por operadores logicos y dosvariables por cada pregunta del guion, una identificando la decision del experto y otra por ladel proponente.

39

El dominio de valores para la variable del proponente sera determinado por cada guion deprueba, siento este un numero entero positivo con un decimal. Por el contrario, el dominio devalores para la variable del experto se limitara a 0 o 1.

Cuadro de equivalencia con el modelo KITE [19]

La resolucion de la ecuacion anterior sera la definicion de uno de los flujos plasmados enel diagrama de actividad, pero dicho resultado, identificado con un puntaje, debe tener unaequivalencia con las opciones posibles que define el modelo KITE [19] para la pregunta adesarrollar. Por lo que cada guion de prueba se establece una tabla con la equivalencia entreel resultado de la ecuacion y a que opcion del modelo KITE [19] equivale.

Cada flujo terminara con un nodo al que se le asignara un puntaje que servira para determinar laopcion a seleccionar del modelo KITE [19]. Cada guion de prueba tendra un diagrama de actividad,pero se resumen en los siguientes 3 tipos de diagrama:

Arbol de decision con preguntas excluyentes

Son aquellos que cuentan con un nodo final por cada flujo y solo se permite la eleccion deuno de ellos como solucion del guion de prueba. Ver Figura 18.

Figura 18: Arbol de decision representando modelo de computo con preguntas excluyentes con cuadrode equivalencia. Elaborado por autores

40

E6P1 = Q1P&Q1E&Q2E(Q2P1 |Q2P2) (7)

Arbol de decision con resultados independientes

Son aquellos que representan preguntas con multiples respuestas. Se utilizaron tantas barrasde sincronizacion como opciones tenga la pregunta del modelo KITE [19], por lo que se puedetener cada resultado y evaluar las posibles combinaciones que definiran los puntajes segun elmodelo KITE [19]. Ver Figura 19.

Figura 19: Arbol de decision representando modelo de computo con resultados independientes con cuadrode equivalencia. Elaborado por autores

T4 = Q1P&Q1E&Q2P&Q2E (8)

Arbol de decision con preguntas incluyentes

Son aquellos que representan preguntas con unica respuesta pero que se necesita tener encuenta el resultado de cada una de las preguntas del guion de prueba. Ver Figura 20.

41

Figura 20: Arbol de decision representando modelo de computo con preguntas incluyentes. Elaboradopor autores

7.4. Seleccion de productos de software para validacion del modelo KITE

Para la seleccion de los productos de software del ejercicio de valoracion se tuvieron en cuentatres grandes categorıas, en la primera se realizo una busqueda de los posibles candidatos en losgrupos de investigacion ARQUISOFT y LAMIC, esto con fin de facilitar la busqueda de expertosevaluadores dado que podrıan estar familiarizados con los temas de cada producto.

7.4.1. Productos de software seleccionados

Los productos seleccionados fueron:

Grupo de investigacion Arquisoft

Librerıa criptografica: Es una librerıa de componentes de codificacion con los reconocidosalgoritmos RSA e IDEA usando el DSBC, realizada en el lenguaje OZ usando la abstraccionde componente mediante el uso de functores.

PintArq: Representacion visual de la ejecucion de una arquitectura de software basada encomponentes con especificacion formal en calculo parq

MetriColector: Aplicacion basada en componentes de software para el apoyo a la captura demetricas de proceso en proyectos de desarrollo de software.

42

PLANTAE: Diseno de un aplicativo de software para la recoleccion de muestras biologicas encampo para el instituto de ciencias naturales de la Universidad Nacional.

FenixSGA V.1.0.: Desarrollo de un prototipo de software para gestionar los procesos universi-tarios de matrıcula e inscripcion de espacios academicos usando ISOS (Ingenierıa de softwareorientada a servicios).

GOLDENBERRY V.2.0.: Coleccion de componentes de software para algoritmos geneticos eimplementacion en una plataforma abierta de programacion visual.

Portal ARQUISOFT: Es un prototipo de portal para los grupos de investigacion de la Uni-versidad, los procesos primarios, de apoyo del grupo, y mediante la personalizacion de apli-caciones existentes y en el desarrollo de aplicaciones tipo portlet.

Grupo de investigacion LAMIC

Simulador TM-AC: Caracterizacion de un modelo de automata celular para simular el com-portamiento de una estacion tıpica del sistema TransMilenio.

ForumForte: Mecanismo de filtrado de censura en foros Web resistente a transliteracion ASCII,mediante algoritmos de comparacion aproximada de cadenas.

GOLDENBERRY V.1.0.: Es un software Add-On para Orange (Un entorno de programa-cion visual OPEN-SOURCE de analisis de datos), que proporciona apoyo a la optimizacion,tecnicas de busqueda basada en estocastica, clasificacion y tareas de seleccion de funciones,permite conectar componentes visuales que son unidades de procesamiento que pueden serconectadas para ejecutar varias etapas de un proceso de minerıa de datos.

En la siguiente categorıa de productos de software seleccionados se encuentran los “Open sour-ce”, esto con el fin de ver la fortalezas y debilidades que tiene el software libre, desde el acceso asu documentacion, codigo fuente y diferentes versiones, entre ellos estan:

Heuristic and Evolutionary Algorithms Laboratory: HeuristicLab es un framework para al-goritmos heurısticos y evolutivos desarrollado por miembros del Laboratorio de AlgoritmosHeurısticos y Evolutivos (HEAL) desde 2002.

Weka 3. Data Mining Software in Java: Weka es una coleccion de algoritmos de aprendizajeautomatico para tareas de minerıa de datos. Los algoritmos pueden ser aplicados directamentea un conjunto de datos o llamados desde su propio codigo Java. Weka contiene herramien-tas para pre-procesamiento de datos, clasificacion, regresion, clustering, reglas de asociaciony visualizacion. Tambien es adecuado para desarrollar nuevos esquemas de aprendizaje demaquinas.

ParadisEO - A software framework for Metaheuristics: ParadisEO es un framework de caja-blanca orientado a objetos dedicado al diseno flexible de metaheurısticas.

ECJ A Java-based Evolutionary Computation Research System: ECJ es un framework decomputacion evolutivo escrito en Java. El sistema fue disenado para grandes y pesadas nece-sidades experimentales aobre algoritmos evolutivos y proporciona diversas herramientas, perocon un enfasis particular en la programacion genetica.

43

Orange Data Mining Library: Aprendizaje de maquinas de codigo abierto y visualizacion dedatos para principiantes y expertos. Flujos de trabajo interactivos de analisis de datos conuna gran caja de herramientas.

Scikit-Learn Machine Learning in Python: Herramientas simples y eficientes para la minerıade datos y analisis de datos, accesible a todo el mundo, y reutilizable en diversos contextos.

ArgoUML- Editor de diagramas UML: ArgoUML es la principal herramienta de modeladoUML de codigo abierto e incluye soporte para todos los diagramas UML 1.4 estandar. Seejecuta en cualquier plataforma Java y esta disponible en diez idiomas.

Por ultimo, se seleccionaron dos productos de software a nivel empresarial de la empresa NA-TURA:

Agenti Q&A Community (AGQA): Es una comunidad en la que se pueden formular y respon-der preguntas, ası como votar y comentar las preguntas y respuestas formuladas por otros.Las preguntas y respuestas pueden ser revisadas y mejoradas. Proporcionado para la entidadColfuturo.

Cuadro de Mando Integral Programas de Accion Transversal - PAT de la Alcaldıa Mayor deBogota: El SGCF es una herramienta que contribuye a la toma de decisiones gerenciales atraves de la verificacion y cumplimiento de indicadores de gestion que aportan en la opti-mizacion de recursos financieros, con el fin de definir estrategias para el mejoramiento de lacalidad de la educacion.

7.5. Criterios de seleccion de los expertos evaluadores

Cada producto de software debe contar con 2 expertos evaluadores, el experto de software, quesera encargado de valorar todos los atributos de calidad de software, determinante E, y el expertotematico, que sera el encargado de evaluar todos los atributos relacionados con el area tematicaespecıfica, es por eso que se tuvieron en cuenta los siguientes criterios de seleccion:

El experto de software debe ser una persona experta en el area de ingenierıa de sistemas o enel area de software.

De acuerdo al area tematica del producto de software se seleccionara una persona experta enel area indicada.

Sobre estos criterios se seleccionaron 19 expertos de software y 17 expertos tematicos, algunoscontaban con la disponibilidad y la disposicion para participar del ejercicio de valoracion en mas deun producto de software, entre la seleccion se conto con el apoyo de los directores del proyecto quetenıan conocimiento de egresados y maestros de la Universidad Distrital Francisco Jose de Caldascon el criterio y experiencia suficientes para participar del proyecto.

7.5.1. Seleccion de expertos evaluadores

Inicialmente se realizo la invitacion, ver Anexo 7.0, en donde se planteaban los objetivos delproyecto, y se solicitaba la colaboracion de parte de los expertos para el ejercicio de valoracion, seenviaron 40 invitaciones de las cuales 37 fueron exitosas. Al recibir la respuesta positiva frente ala invitacion se le facilito el acceso a la herramienta KITEWeb para realizar la valoracion de losproductos de software. A cada experto se le asigno uno o dos productos (maximo), y de acuerdo ala disponibilidad de cada experto se fueron valorando los productos de software. Ver Anexo 9.0.

44

7.6. Mecanismo facilitador del proceso de evaluacion: La herramienta KITE-Web

Se utilizo el prototipo de una aplicacion de software para la implementacion de los guiones deprueba, ası como su validacion por parte de los proponentes y expertos evaluadores. Ver Anexo 11.

A continuacion, se describe brevemente la herramienta KITEWeb.

7.6.1. Niveles de especificacion de la herramienta KITEWeb.

Se establecieron 19 requerimientos funcionales, su descripcion se encuentra en la tabla de re-querimientos funcionales del Anexo 2, y esta compuesta por el identificador del requerimiento,descripcion y prioridad como se observa en la Figura 21.

Figura 21: Ejemplo especificacion de requerimientos funcionales KITEWeb. Elaborado por autores

Especificacion de casos de uso

De los requerimientos presentados se generaron 6 modulos, cada uno con sus respectivosdiagramas de casos de uso. En la Tabla 3. se presenta una breve descripcion de cada uno delos modulos con la cantidad de casos de uso con los cuales estan compuestos.

Tabla 3: Tabla casos de uso herramienta KITEWeb. Elaborado por autores

45

Con el proposito de ilustrar el nivel de detalle alcanzado en el modelamiento de casos de uso,se presenta en la Figura 22 el diagrama de casos de uso denominado ”Gestion de productos desoftware y registro de evaluacion”. Los demas diagramas de casos de uso se pueden encontraren el Anexo 2.

Figura 22: Diagrama de casos de uso. Gestion de productos de software y registro de evaluacion. Herra-mienta KITEWeb

En la Figura 23 se muestra un ejemplo del formato extendido utilizado para la especificaciondel caso de uso CUGP07. Los demas formatos extendidos de los casos de uso de cada modulose pueden encontrar en el Anexo 2.

Figura 23: Formato extendido para el caso de CUGP07. Herramienta KITEWeb

46

Figura 24: Diagrama de actividad del caso de uso CUGP07. Herramienta KITEWeb. Elaborado porautores

Modelo estructural

A continuacion se muestra el diagrama del modelo estructural implementado por la herra-mienta de apoyo KITEWeb, solo se presentan las clases sin sus atributos ni metodos para unamejor visualizacion, y adicionalmente, se incluyen los siguientes patrones de diseno:

• Patron Strategy : Encargado de definir clases que implementen un conjunto de posiblescomportamientos en tiempo de ejecucion. Se utilizo para utilizar diferentes estrategias

47

en el calculo de los resultados del diligenciamiento de cada guion de prueba.

• Patron State: Encargado de ejemplificar y encapsular el comportamiento de un objetodefinido como contexto dependiendo del estado en el que este se encuentre. Se utilizo paraejemplificar los estados identificados en el apartado 6.2.

Figura 25: Diagrama de despliegue herramienta KITEWeb. Elaborado por autores

Para mas detalle acerca de las diferentes clases se puede consultar el diccionario de clasesubicado en el Anexo 3.

Diagrama relacional

En la Figura 26 se presenta el modelo relacional disenado para la herramienta de apoyo KITE-Web, solo se presentan la tablas sin los nombres de sus columnas para una mejor visualizacion.

Para mas detalle acerca de las diferentes tablas se puede consultar el diccionario de datosubicado en el Anexo 3.

48

Figura

26:

Dia

gra

ma

de

des

plieg

ue

her

ram

ienta

KIT

EW

eb.

Ela

bora

do

por

auto

res

49

7.6.2. Arquitectura tecnologica de KITEWeb.

KITEWeb es una aplicacion Web disenada usando el patron arquitectonico MVC sobre laplataforma Java EE. Se desarrollo con la version 8 de Java y se genero un artefacto (ArchivoKITEWEB.war) para su despliegue en un servidor de aplicaciones.

Capa de presentacion

Ubicada dentro del artefacto KITEWEB.war, los componentes de interfaz grafica se desarro-llaron bajo el marco de trabajo JSF 2.2, lo que incluye el uso de ”facelets components”parala realizacion de componentes visuales reutilizables a lo largo de las paginas XHTML, usode ”Templates” o plantillas para mantener la estructura de ubicacion de los componentesvisuales, tecnologıas un poco mas conocidas como archivos CSS para el manejo de estilosy archivos de propiedades para el manejo de todos los mensajes presentados por pantalla.Debido a la gran variedad de opciones se utilizo Primefaces 6.0. Tambien se implementaronlos ”ManagedBean” encargados de la comunicacion con cada pagina XHTML y que a su vezutilizan los servicios provistos en la capa de negocio y persistencia.

Capa de negocio y modelo de dominio

La capa independiente con la logica de negocio se ubico dentro del archivo KITEWE.war yesta constituido por clases con anotaciones @EJB. Allı se encuentran paquetes encargadosdel manejo de los reportes de resultados, gestion de las evaluaciones de los productos desoftware, gestion de los resultados de cada guion de prueba, el manejo de los usuarios y rolesde la aplicacion.

Capa de persistencia

Aquı se implemento el patron fuente de datos DataMapper como intermediario entre lacapa de negocio y las clases del modelo de datos (entidades), a las cuales se les anadieronanotaciones y namedQuery para el uso con JPA (EclipseLink). Tambien se definio el ar-chivo persistence.xml encargado de gestionar la conexion con la base de datos PostgreSQL [22].

Diagrama de despliegue

En la Figura 27 se presenta un diagrama de despliegue para la aplicacion KITEWeb que seencuentra en lınea:

50

Figura 27: Diagrama de despliegue herramienta KITEWeb. Elaborado por autores

7.6.3. Tipos de reporte generados por la herramienta KITEWeb

La herramienta de apoyo KITEWeb permite generar dos tipos de reportes en donde se ex-presan los resultados parciales o totales de la valoracion de un producto de software, esta opcionesta disponible para los proponentes y para los expertos evaluadores.

Reporte geometrico

El reporte geometrico se compone de una grafica romboidal compuesta por 4 ejes que re-presenta cada determinante del modelo de valoracion de calidad de productos de softwareKITE [19], como se observa en la Figura 28.

Figura 28: Reporte geometrico KITEWeb. Elaborado por autores

Reporte cuantitativo

Adicional al reporte geometrico se presenta un reporte cuantitativo de los atributos de calidadagrupados por determinante, estos valores estan reflejados en diagramas de barras como se

51

observa en la Figura 29 . Adicionalmente, se presenta el valor total de la calificacion delproducto que esta conformada por el area total del rombo mencionado anteriormente.

Figura 29: Reporte cuantitativo KITEWeb. Elaborado por autores

52

7.7. Analisis de datos

7.7.1. Alcance y limitaciones

El tamano de la muestra susceptible al ejercicio de valoracion es de diecinueve (19), y es unaseleccion heterogenea de productos Open source con una version estable, prototipos academicos yproductos propietarios.

De acuerdo a las caracterısticas del modelo KITE [19], se exigio un mınimo de recursosdisponibles de cada uno de los productos de software susceptibles para el ejercicio de valoracion,por lo que la cantidad de documentacion o recursos adjuntos fue determinante tanto parainiciar el ejercicio de valoracion como para los resultados de cada determinante. El ejerciciode valoracion se realizo desde la perspectiva del proponente aunque se brindo la posibilidad deextrapolarlo a un ejercicio de valoracion desde la perspectiva del experto, que a su vez se condi-ciono a la disponibilidad de los mismos y al tiempo requerido para concluir el ejercicio de valoracion.

Las caracterısticas del producto de software y objetivo de evaluacion (punto de vista tematico ode ingenierıa) determinaron, a cada producto de software susceptible para el ejercicio de valoracion,la asignacion de un experto evaluador conocedor de su area tematica y un experto evaluadorconocedor de los aspectos de calidad de software

7.7.2. Comunicacion visual geometrica de calidad del producto

El modelo KITE exhibe una representacion visual con la forma romboidal de una cometa,que representa los cuatro determinantes relevantes en la valoracion de productos de software (Kconocimiento, I impacto, T innovacion tecnologica, E aspectos de ingenierıa) y su combinaciongeometrica en cuatro cuadrantes (KI, IT, TE y EK). El area total de la cometa obtenida sera lasuma de las areas triangulares definidas por las valoraciones individuales en cada determinante yrepresentara la madurez y calidad de un producto de software.

A continuacion, se presentan las cometas que surgieron como resultado del ejercicio de valoracionde los productos de software desde la perspectiva del proponente divididas en tres categorıas.

53

Productos de software Open source con version estable

Tabla 4: Reporte geometrico productos de software Prototipos academicos. Elaborado por autores

54

Prototipos academicos

Tabla 5: Reporte geometrico productos de software Protoripos academicos. Elaborado por autores

55

Propietarios

Tabla 6: Reporte geometrico productos de software Propietarios. Elaborado por autores

7.7.3. Metodos estadısticos de analisis y su utilidad

Con el fin de analizar y ver en detalle los resultados de la valoracion de cada uno de los pro-ductos de software, se utilizaron histogramas divididos en diferentes categorıas. En cada categorıase detallan los resultados obtenidos desde la perspectiva del proponente junto con un breve analisisde los mismos. A continuacion se presentan una serie de histogramas con la presentacion de losresultados por determinantes para cada producto de software. En el eje horizontal se encuentran losproductos de software y en el eje vertical la frecuencia esta delimitada por la puntuacion maximaposible que se puede obtener en la valoracion de cada determinante.

Histogramas de frecuencias por determinantes

Segun la Figura 33 se puede evidenciar que en el ejercicio de valoracion del determinante E,el producto de software con mas alta puntuacion fue “Cuadro de Mando Integral Programasde Accion Transversal - PAT de la Alcaldıa Mayor de Bogota. SGCF” el cual fue financiadopor la alcaldıa mayor de Bogota, lo que trajo consigo una inversion importante de recursos.

Figura 30: Histograma por determinante E. Elaborado por autores

56

Lo anterior hizo posible la contratacion de equipos de pruebas (Que presentaron pruebasde cargue, rendimiento y verificacion del producto frente a su especificacion) y adquisicionde plataformas robustas de software (Implicaba opciones en el manejo de polıticas de res-paldo, integridad de la informacion y seguridad), por lo que aumentaron en gran medida lapuntuacion en los atributos desempeno e integridad.

Cabe destacar que 3 de los 4 primeros productos con mejor puntuacion son prototiposgenerados en la academia, que no tienen la posibilidad de obtener los recursos de un softwarepropietario, demostrando que, segun los lineamientos establecidos por el area de ingenierıade software y aplicando la rigurosidad de la academia se puede llegar a obtener productoscon un alto nivel de ingenierıa. La gran diferencia predomino en la profundidad y el niveldetalle en temas como medir la robustez y desempeno de un producto de software. Tanto elsoftware libre como en los prototipos no tienen como objetivo principal el trabajo en dichosfrentes, porque requiere una inversion de conocimiento y de tiempo que se prefiere invertir eldesarrollo de funcionalidades del producto.

La mayorıa de productos de software aplicaron esfuerzos en sus procesos de desarrollo apor-tando a temas como portabilidad, compatibilidad y mantenibilidad, ası como las acciones dedocumentacion. Aunque es evidente que no se obtuvieron puntuaciones muy altas (El maximopuntajes es 16), se puede explicar debido a que la gran mayorıa de los productos carecieronde soportes para demostrar aspectos de robustez, integridad y desempeno, propios de areasde pruebas de software.

Figura 31: Histograma por determinante I. Elaborado por autores

En la Figura 31, correspondiente a los resultados de las valoraciones del determinante I, losproductos con la puntuacion mas alta fueron aquellos que se denominaron como “Open sourcecon versiones estables”. En ellos se evidencio la preocupacion por mejorar su disponibilidad y

57

visibilidad hacia la comunidad de usuarios objetivo, publicando sus productos en sitios webpublicos y sin restricciones para descargar sus ejecutables y codigos fuente. En general seobtuvieron puntuaciones altas y medias.

El punto bajo, presente en casi todos, fue en demostrar que grado de utilizacion tiene elproducto de software, sobre todo en los prototipos producidos en la academia, son muy pocoslos que se exhiben en un dominio de internet publico o se publicitan en medios con unacobertura importante.

Figura 32: Histograma por determinante T. Elaborado por autores

En la Figura 32, los resultados de las valoraciones del determinante T determinaron quelos tres primeros productos con mas alta puntuacion fueron prototipos academicos. El grandenominador fue la importancia que se dio a adicionar nuevas funcionalidades o aspectosimportantes (desempeno, usabilidad, costo, tamano) a sus productos de software que se des-tacaron en cada una de sus areas. Es de resaltar el aumento de la madurez del producto desoftware Goldenberry 2.0 debido a las mejoras implementadas respecto a su version anterior(Mejoras en terminos de ingenierıa de software).

El alcance de la novedad que origina un producto de software depende la mayorıa de las vecespor la institucion que lo patrocina, esto es una limitante para el reconocimiento en el ambitomundial que afecta al mejoramiento continuo de los productos producidos en la comunidadacademica. Vemos como gran fortaleza que tanto los productos denominados ”Open Sourcecon versiones estables” y los prototipos academicos obtuvieron una buena puntuacion debidoa la colaboracion de entes pertenecientes a unidades de trabajo o de investigacion academicos.

58

Figura 33: Histograma por determinante K. Elaborado por autores

En la Figura 33, los resultados de las valoraciones del determinante K se diferencian nota-blemente a los obtenidos en los anteriores determinantes. El determinante K - Conocimiento,abarca dos atributos importantes, uno de ellos se asocia con la difusion de la investigacion queorigina el producto de software, aquı se destacaron varios productos presentando publicacionesde resultados en revistas indexadas sometidas a pares evaluadores.

En el otro subatributo que busca definir si el software surgio como el resultado de una in-vestigacion, todos los prototipos academicos tienen una fuerte exploracion del estado del arteen relacion con el planteamiento de su producto destacando sus diferentes propuestas inno-vadoras. De los productos “Open source” y propietarios no se pudo determinar el grado deinventiva por la carencia de soportes.

59

Histograma de frecuencia por atributos

Es importante ver en detalle las razones para que cada determinante obtenga dicho puntaje,por eso los resultados individuales de cada atributo que se muestran en la Tabla 7, evidenciancon mas claridad los puntos de inflexion en la valoracion de un determinado atributo. Debidoa la cantidad de atributos, a continuacion se presenta solo uno por cada determinante, losdemas se pueden encontrar en el Anexo 8.

Tabla 7: Histograma por atributos, E2 - Extendibilidad y Mantenibilidad, I2 - Asequibilidad, K1 -Inventiva y T4 - Mejoramiento continuo. Elaborado por autores

60

Histogramas por categorıas

Dada la categorizacion de productos de software planteada, en la Tabla 8, se presenta el pro-medio en la puntuacion de cada uno de los determinantes divididos en productos de software”Open source con version estable”, prototipos academicos y propietarios.

Tabla 8: Histograma por categorıas Determinante K, I, T y E. Elaborado por autores

Podemos destacar las grandes fortalezas de los prototipos academicos en determinantes comoK, T y E, en donde la preocupacion por realizar un software robusto, innovador, que aporte a lacomunidad academica marcan un factor diferenciador, pero en comparacion con los productos”Open source con version estable”no se dan a conocer en otros ambitos diferentes al institutoque los patrocina.

61

Histograma por areas

Finalmente se puede ver en la Figura 34 el comparativo del area total de cada uno de losproductos que participaron en el ejercicio de valoracion desde la perspectiva del proponente.

Figura 34: Comparativo de madurez de un producto frente a los otros. Elaborado por autores

Se puede ver que las puntuaciones fueron bajas en relacion con el maximo puntaje posible(100), aun en los productos con evidente esfuerzo en aplicar buenas practicas en ingenierıa desoftware o con grandes esfuerzos en la produccion cientıfica y academica. La cantidad de soportespresentados, ası como el contenido de los mismos, fueron determinantes. Recordando que el areatotal se calcula con la suma de las areas individuales que se obtienen mediante la combinacion delos resultados de dos determinantes y que generan un cuadrante,ver Figura 7, los cuadrantes E-T yT-I de las valoraciones de los productos de software fueron los que contribuyeron en mayor medidaa la puntuacion final (Aporta un maximo de 60 por ciento), pero debido a que la puntuacion deldeterminante K, en la mayorıa de los productos de software es baja , los otros cuadrantes quepodrıan llegar a aportar puntaje (K-E y K-I) no lo hicieron, independiente del resultado en losdeterminantes I y E. Lo anterior es importante, ya que se deja de aportar a la puntuacion de unarea que representa el 40 por ciento del total posible.

7.7.4. Hallazgos

En el desarrollo del proyecto se evidenciaron ciertas debilidades en el modelo de valoracionde calidad KITE, se ajustaron algunas opciones, ponderaciones y enunciados de los subatributospropuestos por el modelo, esta retroalimentacion se dio a conocer a los autores del modelo y junto

62

con su asesorıa se plantearon los nuevos valores. La bitacora de cambios se puede encontrar en elAnexo 4.

8. TRABAJO FUTURO

En el desarrollo del proyecto se presentaron nuevas ideas que se pueden llevar a cabo comocomplemento y extension del trabajo realizado. A continuacion, se describen algunas de ellas:

Debido al grado de confidencialidad inmerso en el proceso de valoracion de un producto desoftware por medio de la Herramienta KITEWeb se debe dar la opcion al proponente deindicar si esta informacion sera de caracter publico o privado, incluyendo la presentacion deresultados.

Generar automaticamente los diagramas, histogramas, reportes estadısticos mas especializa-dos y consolidado de reportes por categorıas de productos entre otros, desde la herramientaKITEWeb.

Extender KITEWeb con un modulo de parametrizacion de listas de chequeo para flexibilizaro endurecer las calificaciones y los modelos de computo implementados en los guiones deprueba.

Para extrapolar el modelo de valoracion de calidad KITE a nivel internacional se sugiereutilizar en el atributo K1 – Diseminacion a las categorias establecidas por Scopus [33].

Contemplar en el modelo de valoracion de calidad KITE en el atributo de cobertura a laspersonas discapacitadas.

Adicionar un modulo para administrar el historico de las evaluaciones y guardar las diferentesversiones de los productos para compararlas.

Crear un simulador de evaluacion para que el proponente pueda proyectar, frente a unoscambios en su producto, como mejora segun el modelo de valoracion de calidad KITE.

Analisis de datos con Inteligencia Artificial: El actor Verificador de la informacion puedadeterminar por cada uno de los campos del registro de los actores o productos si es veraz ono la informacion, adicionalmente generar LOG de cambios para controlar la integridad delos registros.

63

9. CONCLUSIONES

La herramienta KITEWeb permite disminuir notablemente los tiempos de valoracion deproductos de software, hace que la labor de los expertos evaluadores y proponentes se reduzcasustancialmente y sea mas facil acceder a los resultados brindados por el modelo de valoracion KITE.

En la exploracion de los productos de software que participaron en el ejercicio de valoraciondestacamos la calidad en la documentacion encontrada en los prototipos de origen academico, nospermitio conocer la variedad de productos de software que se han desarrollado en la UniversidadDistrital con un alto grado de rigurosidad en aspectos de software, ası mismo, vimos las limitantesque se presentan en los productos propietarios en proporcionar la documentacion y soportes decada producto, finalmente, a pesar de la filosofıa de codigo abierto del software “Open Sour-ce” no es facil acceder a la documentacion, y no se soporta adecuadamente el proposito del producto.

Se evidenciaron unos patrones en los reportes geometricos de acuerdo a la categorıa delproducto de software. Aquellos de tipo propietario y “Open Source” no buscan difundir y soportarsu grado de novedad o simplemente no lo tienen, a diferencia de los prototipos academicos quesu mayorıa siendo producto de tesis universitarias logran soportar su grado de innovacion ydiseminacion en el desarrollo del proyecto

Gracias al conocimiento adquirido en las areas abarcadas por la ingenierıa de sistemas se logro laconstruccion de los guiones de prueba, logramos abstraer los conceptos para su implementaciontecnologica mediante el uso del lenguaje de modelado UML, arboles de decision y logica booleana.

El uso de la herramienta KITEWeb nos brindo las facilidades de extraer los datos frente a lapuntuacion por producto, permitiendonos aplicar metodos estadısticos para identificar el grado demadurez de calidad del software. Nos da la posibilidad de retroalimentar a los proponentes de losproductos frente a las deficiencias que tienen en aspectos especıficos.

Llevar a cabo la instrumentalizacion del modelo KITE, nos motivo a interiorizar la vision delsoftware no solo como un artefacto ingenieril sino como un conjunto de caracterısticas que logranaportar conocimiento a la comunidad. Fue productiva la retroalimentacion realizada a los autoresdel modelo KITE, viendo la necesidad de ajustarlo para hacerlo mas preciso en algunos de susatributos.

64

10. GLOSARIO

Robustez: Un programa es robusto si se comporta “razonablemente”, incluso en circunstan-cias que no estaban anticipadas en la especificacion de requerimientos; por ejemplo, cuandose encuentra con datos de entrada erroneos o algun mal funcionamiento de hardware (porejemplo, un fallo de disco). Un programa que asume una entrada perfecta y genera un e-rror irrecuperable en tiempo de ejecucion tan pronto el usuario involuntariamente digita uncomando incorrecto no es robusto.

Desempeno: Es una cualidad externa basada en los requerimientos del usuario. Hay tres acer-camientos basicos para evaluar el desempeno de un sistema: medicion, analisis y simulacion.Podemos medir el desempeno actual de un sistema por medios como monitores de hardware ysoftware que recolectan datos mientras el sistema esta en ejecucion y aı permitirnos descubrircuellos de botella en el sistema. El segundo acercamiento es construir un modelo del productoy analizarlo matematicamente. La tercera aproximacion es usar ese modelo para simular elproducto.

Integridad: El codigo posee la caracterıstica de la integridad en la medida en que todas suspartes estan presentes y cada parte esta completamente desarrollada

Compatibilidad: Un sistema operativo puede albergar un gran numero de aplicaciones, in-dependientemente de sus proveedores. Los sistemas operativos genericos son un repositoriocentral para los componentes compartidos a traves de las aplicaciones

Confiabilidad: Un producto basado en software es confiable en la medida en que lleva a cabo lasfunciones previstas de forma satisfactoria, esto implica que el programa se compilara, cargara,ejecutara y producira respuestas de la forma requerida; tambien implica que es completa y esconsistente de manera externa, etc.

Funcionalidad: Un programa es funcionalmente correcto si se comporta de acuerdo a los reque-rimientos funcionales establecidos. La definicion de exactitud asume que las especificacionespara el sistema estan disponibles y que es posible determinar claramente si un programacumple con las especificaciones.

Facilidad de reutilizacion: La capacidad de reutilizacion es afın a la capacidad de evolucion.En la evolucion del producto, modificamos un producto para construir una nueva version deese mismo producto; en la reutilizacion del producto, usamos el producto – tal vez con cambiosmenores – para construir otro producto. La capacidad de reutilizacion puede ser aplicada adiferentes niveles de granularidad – de aplicaciones completas a rutinas individuales – peroal parecer es mas aplicable a componentes de software que a productos completos.

Flexibilidad: Representa el esfuerzo requerido para modificar el codigo de un sistema, moduloo funcion de software en operacion. El objetivo del atributo es generar codigos bien estructu-rados que sean entendibles.

Inventiva: Atributo que especifica si la realizacion de un producto de software es nuevo endiferentes ambitos a nivel mundial.

Novedad: Cualidad que indica en donde se encuentra el aporte unico del desarrollo de unproducto de software, ya sea a nivel tecnologico o presentado para un nuevo contexto.

65

Singularidad: Especifica si un producto de software implementa una caracterıstica diferentecomparada con productos similares o versiones anteriores del mismo. Esta pueden ser a nivelesencial o a nivel estetico.

Originalidad: A pesar de que un producto de software puede ser unico en su contenido, esteatributo define si es totalmente suficiente para ejecutarse en un sistema operativo o si por elcontrario necesita de un software base para agregarse a el, como una extension.

Cobertura: Indica a que nivel ha sido difundido o distribuido el producto de software. Estepuede ser desde nivel local hasta nivel mundial.

Usabilidad: Un sistema de software es facil de usar – o amigable al usuario – si sus usuarioshumanos lo encuentran facil de utilizar. En general, la facilidad para el usuario de un sistemadepende de la consistencia y previsibilidad de su usuario y las interfaces de operacion.

Extensibilidad y mantenibilidad: La mantenibilidad puede ser vista como dos cualidades se-paradas: reparabilidad y capacidad de evolucion. El software es reparable si permite la co-rreccion de defectos y tiene la capacidad de evolucionar si permite cambios que lo habilitanpara satisfacer requerimientos nuevos o modificados.

Portabilidad: El software es portable si puede correr en diferentes ambientes. El terminoambiente se puede referir a un software tal como un sistema operativo en particular. Laportabilidad es importante economicamente porque ayuda a amortiguar la inversion en elsistema de software a traves de diferentes ambientes y diferentes generaciones del mismoambiente.

Documentacion: El proceso de desarrollo de software tiene visibilidad si todos sus pasos ysu estado actual estan claramente documentados. Otro termino utilizado para caracterizaradecuadamente esta propiedad, tambien usada en procesos de empresas y organizaciones,es transparencia. La idea es que los pasos y el estado del proyecto esten disponibles y seanfacilmente accesibles para una examinacion externa.

Facilidad de soporte: Los requisitos que abarcan este atributo se refiere a los requisitos deinstalacion, requisitos de configuracion, requisitos de adaptabilidad y requisitos de compa-tibilidad.

Correccion: Es al atributo que indica si un un producto de software es consistente con susespecificaciones. Si realmente hace lo que debe hacer el software.

Trazabilidad: La trazabilidad del software trata sobre como enlazar o relacionar los requisitoscon otros elementos del ciclo de vida, principalmente, casos de prueba y codigo. A su vez debeidentificar la fuente de origen de los documentos de diseno, codigo y guiones de prueba de unproducto de software.

Facilidad de prueba: Se refiere a la facilidad con la que el software puede demostrar sus fallasa traves de la ejecucion de pruebas.

Interoperabilidad: La interoperabilidad se refiere a la habilidad que tiene un sistema paracoexistir y cooperar con otros sistemas; por ejemplo, la habilidad de un procesador de palabraspara incorporar un grafico producido por un paquete grafico, la habilidad de ese paquetegrafico para graficar los datos producidos por una hoja de calculo, o la habilidad de esa hojade calculo para procesar una imagen escaneada por un escaner. La interoperabilidad puedeser vista como la capacidad de reutilizacion al nivel de aplicacion.

66

Diseminacion: Teniendo en cuenta la produccion academica que origino la realizacion delproducto de software, se mide de acuerdo en que tipo de revista cientıfica se publico. Entremas rango de aceptacion cientıfica tenga la revista o conferencia, este atributo tendra unmayor valor.

Alcance: Define a quien va destinado la utilizacion del software.

Superioridad: Este atributo indica que tanto ha superado un producto de software a uno deversion anterior, frente a tiempos de ejecucion, gestion de memoria, etc.

Nivel de endogamia: Indica en donde se origino la idea de crear un producto de softwareinnovador.

Disponibilidad: Este atributo indica a traves de que medio es distribuido el software y quetan accesible es.

Liberalidad de uso: Indica el tipo de licencia del producto de software al momento de liberarlo(Software libre, propietario etc. . . ).

Seguridad: Un sistema es seguro si provee sus servicios unicamente a sus usuarios autorizadosy protege los derechos y la informacion de esos usuarios. La integridad de datos asegura queuna vez los datos del usuario estan comprometidos en el sistema, no seran modificados odestruidos a traves del malfuncionamiento del sistema o por actos involuntarios o maliciosospor parte de otros usuarios. La privacidad asegura que las transacciones del usuario y susdatos estan protegidos de usuarios no autorizados y no seran utilizados para propositos noautorizados.

Referencias

[1] Aguirre, P. A. R. Estudio de las practicas de calidad del software implementadas en lamipymes desarrolladoras de software de pereira. Master’s thesis, Universidad Tecnologica dePereira, 2010.

[2] Alain Abran, Rafa AlQutaish, J. D. N. H. An information model for software qualitymeasurement with iso standards. International Conference on Software Development (may2005), 104–116.

[3] Barron, F. H., and Barrett, B. E. Decision quality using ranked attribute weights.Management Science 42, 11 (1996), 1515–1523.

[4] Bizagi. Bizagi modeler, 2017.

[5] Boehm, B. W. Characteristics of software quality. North-Holland, 1980.

[6] Carnegie Mellon, U. Software engineering institute, April 2015.

[7] Caswell, R. G. D. Software Metrics: Establishing a Company-Wide Program, vol. 1. PrenticeHall PTR, Junio 1987.

[8] de asignacion y reconocimiento de puntaje CIARP, C. I. EVALUACION DE PRO-DUCTIVIDAD ACADEMICA MODALIDAD DE SOFTWARE, vicerrectorıa academica ed.Universidad del Valle, 2002.

67

[9] Edwards, W., and Barron, F. H. Smarts and smarter:improved simple methods for mul-tiattribute utility measuremen. Organizational Behavior and Human Decision Processes 60, 3(1994), 306–325.

[10] F. Deissenboeck, L. Heinemann, M. H. K. L., and Wagner, S. The quamoco tool chainfor quality modeling and assessment. ICSE 11, 11 (2011).

[11] ISO/IEC. Information technology software product evaluation. 14598-1, 1999.

[12] ISO/IEC. Information technology software product quality. 9126-1, 2000.

[13] Jagdish Bansiya, C. D. A hierarchical model for object-oriented design quality assessment.IEEE Transactions on Software Engineering 28, 1 (January 2002), 14.

[14] Jorge Moreno, Liliam Bolanos, M. N. Exploracion de modelos y estandares de calidadpara el producto de software. UIS Ingenierıas: Facultad de Ingenierıas Fisicomecanicas 9, 1(Junio 2010), 39–53.

[15] Lochmann, K. Engineering quality requirements using quality models. ICECCS’10 (2010).

[16] Ltd., S. S. P. Enterprise architect 13, 2017.

[17] Luis Mendoza, Perez Maria, G. A. Prototipo de modelo sistemico de calidad (mosca) delsoftware. Computacion y Sistemas 8, 3 (Diciembre 2004), 196–217.

[18] M. Klas, C. Lampasona, S. N. S. W. M. H., and Lochmann, K. Adapting softwarequality models: Practical challenges, approach, and first empirical results. SEAA11 (2011).

[19] Melgarejo, S. R. H. D. M. The kite model for assessment of academic software products.Facultad de Ingenierıa de la Universidad Distrital Francisco Jose de Caldas 18, 2 (Octubre2013), 17.

[20] NASA. National aeronautics and space administration: Software assurance standard. STD-8739.8, November 1992.

[21] NASA. National Aeronautics and Space Administration: Goddard Space Flight Center. NASA,http://www.nasa.gov, April 2015.

[22] PostgreSQL. Posgresql-es, 2017.

[23] Pressman, R. Ingenierıa de Software: Un enfoque practico, 5 ed. Mc Graw Hill, 2001.

[24] Pressman, R. Ingenierıa de Software: Un enfoque practico, 7 ed. Mc Graw Hill, 2010. pag571.

[25] QUAMOCO. Open quality model and tool support for quality modelling and evaluation.Tech. rep., QUAMOCO, 2008.

[26] R. Plosch, A. M., and Korner, C. Collecting quality requirements using quality modelsand goals. QUATIC’10 (2010).

[27] SARA. Sistema de informacion de talento humano sara. Universidad Naciona de Colombia,2008.

68

[28] SCALONE, F. Estudio comparativo de los modelos y estandares de calidad del software.Maestria en ingenieria en calidad, UNIVERSIDAD TECNOLOGICA NACIONAL FACUL-TAD REGIONAL BUENOS AIRES, Junio 2006.

[29] SQuaRE. Software engineering: Software product quality requirements and evaluation qualitymodel and guide. ISO/ IEC 25010, 2007.

[30] Stefan Wagner., Klaus lochman., L. H. The quamoco product quality modelling andassessment approach. Software Engineering (ICSE), 2012 34th International Conference on(June 2012), 1133 – 1142.

[31] Victor Basili, D. R. GOAL QUESTION METRIC PARADIGM, vol. 2. Encyclopedia ofSoftware Engineering, 1994.

[32] Walters, J. M. P. R. G. Factors in Software Quality: Concept and Definitions of SoftwareQuality, vol. 1. RADC-TR, January 1978.

[33] Wordmark, E. Scopus, 2017.

69