Diagnóstico del uso de métricas de calidad de la norma ISO/IEC 25000 en mipymes de desarrollo de software de países miembros del HASTQB

Texto completo

(1)ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS. DIAGNÓSTICO DEL USO DE MÉTRICAS DE CALIDAD DE LA NORMA ISO/IEC 25000 EN MIPYMES DE DESARROLLO DE SOFTWARE DE PAÍSES MIEMBROS DEL HASTQB. PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN. DENNIS FERNANDO VEINTIMILLA ALVARADO [email protected]. CHRISTIAN ANDRÉS CHICAIZA CAIZA [email protected]. DIRECTOR: PHD. SANDRA PATRICIA SÁNCHEZ GORDÓN [email protected]. Quito, marzo 2020.

(2) CERTIFICACIÓN. Certifico que el presente trabajo fue desarrollado por Dennis Fernando Veintimilla Alvarado y Christian Andrés Chicaiza Caiza, bajo mi supervisión.. PhD. Sandra Patricia Sánchez Gordón DIRECTOR DE PROYECTO. I.

(3) DECLARACIÓN. Nosotros, Dennis Fernando Veintimilla Alvarado y Christian Andrés Chicaiza Caiza , declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que hemos consultado las referencias bibliográficas que se incluyen en este documento.. A través de la presente declaración cedemos nuestros derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente.. Dennis Fernando Veintimilla Alvarado. Christian Andrés Chicaiza Caiza. II.

(4) DEDICATORIA. Dedico este trabajo a mis padres, Cristóbal y Marianita, por su inmensurable e incondicional apoyo, por sus valiosos y oportunos consejos, por su ejemplo y guía, por creer siempre en mí, y porque cada uno de mis logros son gracias a ellos.. Dennis.. III.

(5) DEDICATORIA. Dedico este trabajo con todo cariño y amor a mi madre Rocio, por su apoyo constante y por llenar mi vida con sus valiosos consejos. Está tesis y todo lo que logre hacer será gracias a su fortaleza, virtudes y valores inculcados en mí.. Christian.. IV.

(6) AGRADECIMIENTOS. En primer lugar, agradezco a Dios por incluir en su propósito para mi vida la culminación de esta maravillosa etapa. A mi padre, Cristóbal, por su guía, ejemplo y constante soporte a lo largo de toda mi carrera. A mi madre, Marianita, por ser un modelo a seguir, por su ética de trabajo, por su afecto sin medida y acertados consejos. A mis hermanos, Gabriela y Mauricio, por tener esa confianza en mí y por permitirme siempre contar con ellos pase lo que pase. A mi familia, amigos y amigas, quienes hicieron más amena, llevadera e inolvidable la presente travesía. Agradezco también a nuestra tutora Sandra Sánchez, por su gran apoyo, supervisión y asesoramiento, así como sus valiosos conocimientos impartidos tanto para el presente trabajo como en el transcurso de la carrera. Finalmente, agradezco a la Escuela Politécnica Nacional por dar la oportunidad a sus estudiantes de cursar tan honorable carrera y permitirnos mejorar nuestro futuro, por tanto conocimiento impartido y tan cálida acogida.. Dennis.. V.

(7) AGRADECIMIENTOS. A mis padres por ser los principales motores de mis sueños, gracias por cada día confiar y creer en mí y en mis expectativas, por su comprensión, motivación y el apoyo que me han brindado para lograr todas y cada una de mis metas, así como me impulsan a lograr mis sueños y mis anhelos. A mi familia en general, porque siempre me han brindado su apoyo incondicional. A mis amigos y amigas, gracias por compartir junto a mí tantos momentos especiales a lo largo de mi vida. Agradezco también a mi tutora de tesis la Ingeniera Sandra Sánchez por haberme brindado la oportunidad de recurrir a su capacidad y conocimiento científico, así como también por la paciencia y orientación brindada en el desarrollo de esta investigación. Y por supuesto a la Escuela Politécnica Nacional y a todas las autoridades, por permitirme concluir con esta etapa de mi vida.. Christian.. VI.

(8) CONTENIDO. Resumen. 1. Abstract. 2. 1. 3. 2. 3. INTRODUCCIÓN 1.1 Preguntas de Investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.2 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 1.3 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 1.4 Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 1.5 Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 1.5.1 Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.5.2 Trabajos Relacionados al Estudio . . . . . . . . . . . . . . . . . . . . .. 9. 1.5.3 Investigación del Estado del Arte . . . . . . . . . . . . . . . . . . . . .. 10. METODOLOGÍA. 20. 2.1 Definición del Objetivo de la Encuesta . . . . . . . . . . . . . . . . . . . . . .. 20. 2.2 Reclutamiento de Entidades a Encuestar . . . . . . . . . . . . . . . . . . . .. 21. 2.3 Diseño del Instrumento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 2.4 Validación del Cuestionario . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 2.5 Ejecución de la Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 2.6 Procesamiento de la Información Recolectada . . . . . . . . . . . . . . . . .. 30. 2.7 Análisis de Resultados de la Encuesta . . . . . . . . . . . . . . . . . . . . . .. 30. 2.8 Difusión de los Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. RESULTADOS Y DISCUSIÓN. 32. 3.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 3.2 Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42. 3.2.1 Análisis de Métricas por País . . . . . . . . . . . . . . . . . . . . . . .. 42. 3.2.2 Ecuador vs el Resto de Países de Hispanoamérica . . . . . . . . . . .. 48. 3.3 Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50. 3.3.1 Recomendaciones para mejorar el uso de las métricas en los países de Hispanoamérica . . . . . . . . . . . . . . . . . . . . . . . . . . . .. VII. 51.

(9) 4. 5. CONCLUSIONES Y RECOMENDACIONES. 53. 4.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.2 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54. REFERENCIAS BIBLIOGRÁFICAS. 55. A ANEXOS. I. A.1 Países miembros de HASTQB y sus Representantes . . . . . . . . . . . . . .. II. A.2 Arte Auspiciado por CITEC . . . . . . . . . . . . . . . . . . . . . . . . . . . .. III. A.3 Encuesta para Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. IV. A.4 Datos Socio-Demográficos . . . . . . . . . . . . . . . . . . . . . . . . . . . .. VIII. A.5 Información Técnica sobre el Uso de Métricas. . . . . . . . . . . . . . . . . .. IX. A.6 Retroalimentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. X. A.7 Encuesta Completa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. XI. VIII.

(10) RESUMEN. La presente investigación pretende solventar la pregunta de cuál es el uso que se está haciendo actualmente de la norma ISO/IEC 25000 para los parámetros de Adecuación Funcional, Usabilidad, Seguridad y Mantenibilidad dentro de las MIPYMES (micro, pequeñas y medianas empresas) de desarrollo de software de los países miembros del HASTQB (Hispanic American Software Testing Qualification Board). Esto, sustentado en la hipótesis de que estas MIPYMES utilizan menos del 25 % de las métricas de calidad para Adecuación Funcional, Mantenibilidad, Seguridad y Usabilidad de la norma ISO/IEC 25000. En los estudios relacionados se tienen varios trabajos correspondientes a la evaluación y creación de modelos basados en la norma ISO/IEC 25000; así como también en la norma ISO 29110. No obstante, existen carencias en cuanto a trabajos sobre aplicaciones reales de estas normas sobre MIPYMES y, aún más, dentro de la región hispanoamericana. Para el presente proyecto se utilizó una metodología fundamentada principalmente en la encuesta como técnica de investigación, la cual está estructurada por actividades que van desde la definición de objetivos hasta el tratamiento estadístico de los datos, pasando por el diseño y ejecución de la encuesta. En el estudio realizado se obtuvieron un total de 181 respuestas, las cuales se recogieron de empresas de los diferentes países miembros del HASTQB. Se halló mayor popularidad para las métricas de Adecuación Funcional con un 84 % de acogida, seguido de Usabilidad con un 61.47 %, después Seguridad con 58 % y finalmente Mantenibilidad con un 31.13 %. Por último, se confirmó la hipótesis planteada al obtener un porcentaje de 13,24 % de encuestados que afirmaron usar la norma ISO/IEC 25000 en sus proyectos de desarrollo de software.. Palabras Clave: ISO/IEC 25000, MIPYMES, Adecuación Funcional, Usabilidad, Seguridad, Mantenibilidad, HASTQB.. 1.

(11) ABSTRACT. The current investigation aims to answer the question of what is the use that is currently being done of ISO/IEC 25000 for the parameters of Functional suitability, Usability, Security and Maintainability within the MSMES of software development in member countries of the HASTQB. It is under the hypothesis that these MSMES use less than 25 % of quality metrics for Functional Suitability, Maintainability, Security and Usability of ISO/IEC 25000. The related studies at the moment have several works corresponding to the evaluation and creation of models based on the ISO/IEC 25000 as well as in ISO/IEC 29110, however, there are gaps in work on real applications of these standards on MSMES, and even more within the Hispanic American region. This project uses a methodology primarily based on the survey as a research technique. The activities that compose this technique range from the definition of objectives through statistical treatment data and passing through the design and implementation of the survey. The study received a total of 181 replies recollected from companies of different member countries of the HASTQB. It was found greater popularity for the characteristic of Functional Suitability with a 84 % of reception followed by Usability with a 61.47 %, Security with a 58 % and finally Maintainability with a 31.13 %. In the end, it was confirmed the hypothesis due to the percentage of 13.24 % obtained from respondents use the ISO/IEC 25000 in their software development projects. Finally, it was confirmed the hypothesis due to percentage of 13.24 % obtained from the answers of respondents that declare use the ISO/IEC 25000 in their software development projects.. Keywords: ISO/IEC 25000, MSMES, Functional Suitability, Usability, Security, Mantainability, HASTQB.. 2.

(12) 1 INTRODUCCIÓN. Cada día los expertos de la industria y la academia en ingeniería de software trasmiten al mundo la necesidad de desarrollar software de calidad. En diferentes publicaciones, congresos, foros, entre otros, que versan sobre temas relacionados con el desarrollo de software, se refuerza la calidad como un elemento intrínseco y de vital importancia [1]. En la industria del software, el objetivo primordial es llegar a obtener software de calidad aplicando diferentes procesos estandarizados y maduros de gestión y desarrollo de software, junto con otros aspectos que contribuyen a la eficiencia y eficacia de estos procesos. Cabe recalcar que los sistemas de software son cada vez más complejos, por lo que las exigencias de calidad sobre su desarrollo son mayores [1]. Es necesario que el desarrollo de software sea más riguroso para obtener un producto de alta calidad. Esto busca reducir el número de defectos insertados en su construcción. La identificación y tratamiento de estos errores en etapas tempranas del proyecto es crucial para disminuir los costos de su operación y evitar errores en etapas posteriores [1]. El análisis del uso de métricas de calidad de software proporciona un enfoque estratégico al momento de evaluar la calidad de los productos en un punto determinado de su desarrollo. Razón por la cual, se debe conocer el estado actual de las empresas que se dedican al desarrollo de productos software con el propósito de considerar que, si no se realizaran mediciones sobre los procesos con la ayuda de métricas, no habría forma real de evidenciar el perfeccionamiento o la ejecución eficiente de estos procesos. En trabajos de países hispanoamericanos, como es el caso de Colombia [1], pueden evidenciarse una serie de falencias y puntos que demandan optimización; puesto que, llegan a considerarse como nuevas propuestas de procedimientos. Algunas de ellas tienen que ver con el uso de buenas prácticas propuestas por la ingeniería de requerimientos que buscan resolver los principales problemas que surgen en los procesos relacionados con los requisitos. Se evidencia de esta manera la falta de control sobre estos procesos y, en con-. 3.

(13) secuencia, sus productos son de baja calidad. Otra gran carencia es la falta de aplicación práctica de las propuestas de mejora de calidad en el sector productivo, dentro de todo el ámbito regional hispanoamericano. Finalmente, puede decirse que la mayoría de los trabajos revisados indican la necesidad de desarrollar herramientas, artefactos o investigaciones adicionales para el mejoramiento de la calidad de software [1]. Con el análisis del uso de métricas de calidad en las MIPYMES (micro, pequeñas y medianas empresas) se podrá realizar un diagnóstico y formular recomendaciones con el fin de mejorar las falencias de calidad de software dentro de estas empresas en trabajos futuros, también se proporcionarán gráficos estadísticos, los cuales detallarán el estado actual de las empresas desolladoras de software de los países miembros de HASTQB (Hispanic American Software Testing Qualification Board). Esto podrá ayudar en futuras investigaciones; debido a que, actualmente, no existe un estudio detallado del uso de métricas en MIPYMES a nivel hispanoamericano.. 1.1. PREGUNTAS DE INVESTIGACIÓN. Día a día, más y más organizaciones se sienten interesadas en el aseguramiento y control de la calidad de los productos de software. Aunque cada una de estas organizaciones tengan características diferentes unas de otras, es posible clasificarlas de forma general dentro de las siguientes categorías: Organizaciones del Gobierno, ya sean nacionales, regionales o a nivel local; empresas de software que externalizan sus procesos mediante nearshoring u offshoring; fábricas y compañías de desarrollo de software interesadas en tener un mecanismo que les permita asegurar la calidad del software que desarrollan, o fábricas y compañías de desarrollo de software que se interesan por asegurar a sus clientes con productos de calidad [2]. Esta investigación tiene como propósito informar a las organizaciones y público en general acerca de la pregunta, ¿cuál es el uso que se está haciendo actualmente de la norma ISO/IEC 25000 para los parámetros de Adecuación Funcional, Usabilidad, Seguridad y Mantenibilidad dentro de las MIPYMES de desarrollo de software de los países miembros del HASTQB? Con esta información se puede llegar a realizar una autoevaluación por parte de cada una de las empresas con el fin de conocer su estado en cuanto a estos parámetros y de ser. 4.

(14) el caso, realizar mejoras en sus procesos. Se busca también motivar a las empresas que nunca hayan utilizado estas series de estándares para que comiencen a implementarlas y que consideren los beneficios que pueden llegar a obtener. Independientemente de las categorías de los tipos de empresas indicadas anteriormente, se citan a continuación algunos de los beneficios que estas pueden adquirir [2]: p Diferenciarse de los competidores, cumplir con plazos de entrega y asegurar la disminución de defectos en sus productos. p Ser capaz de establecer acuerdos de nivel de servicios, definiendo parámetros de calidad específicos que deba cumplir su producto antes de ser entregado. p Detectar defectos en los productos software y proceder a eliminarlos antes de su entrega, consiguiendo la reducción de costos en la fase de mantenimiento. p Evaluar y monitorear el rendimiento de los productos software desarrollados, que aseguren la provisión de resultados correctos en función de las limitaciones de tiempo y recursos. p Asegurar que los desarrollos realizados cumplan con los niveles adecuados para las características de Seguridad (Confidencialidad, Integridad, Autenticidad, No Repudio, entre otras). p Verificar que los productos software desarrollados puedan ser desplegados sin problemas en el ambiente de producción, sin comprometer a otros sistemas y manteniendo una adecuada compatibilidad con las interfaces necesarias.. La figura 1.1 muestra los beneficios que provee la evaluación del software, separados en compañías que desarrollan el software y aquellas que lo adquieren.. 5.

(15) Figura 1.1: Beneficios de evaluar el producto software [2].. 1.2. OBJETIVO GENERAL. Diagnosticar el uso de métricas de calidad de la norma ISO/IEC 25000 en MIPYMES de desarrollo de software de países miembros del HASTQB.. 1.3. OBJETIVOS ESPECÍFICOS. A) Elaborar una revisión de la literatura acerca de artículos científicos publicados sobre el uso de métricas de calidad de la norma ISO/IEC 25000 en MIPYMES de desarrollo de software en Hispanoamérica. B) Diseñar un cuestionario en línea para diagnosticar el uso de métricas de calidad para Adecuación Funcional, Mantenibilidad, Seguridad y Usabilidad de la norma ISO/IEC 25000 en MIPYMES de desarrollo de software de países miembros del HASTQB. C) Obtener datos depurados del muestreo consecutivo conformado por el conjunto de respuestas receptadas de las MIPYMES de desarrollo de software de los países miembros del HASTQB. D) Analizar los datos depurados para obtener un diagnóstico y recomendaciones.. 6.

(16) 1.4. HIPÓTESIS. Las MIPYMES de desarrollo de software de los países miembros del HASTQB utilizan menos del 25 % de las métricas de calidad para Adecuación Funcional, Mantenibilidad, Seguridad y Usabilidad de la norma ISO/IEC 25000.. 1.5. MARCO TEÓRICO. La última década del siglo XX ha visto un rápido incremento en el uso de los productos de software en una variedad de áreas de aplicación; sin embargo, su correcto funcionamiento es a menudo crítico para el éxito empresarial y la seguridad humana. Se espera que esta tendencia continúe a la luz del progreso, así como la utilización de la evaluación de la medición de calidad del producto de software, particularmente desde la perspectiva de la estandarización internacional. En el área de ingeniería de software, el concepto de medición de software (o lo que comúnmente se denomina "métricas"de software) no es nuevo [3]. La industria reconoce que las MIPYMES que desarrollan sistemas de software son muy importantes para la economía. En el caso de que las empresas no puedan entregar un producto a tiempo y dentro del presupuesto, se compromete la competitividad de ambas organizaciones. Una forma de mitigar estos riesgos es hacer que todos los proveedores de una cadena de productos implementen prácticas de ingeniería reconocidas. Muchos estándares y modelos internacionales como ISO/IEC 29110 se han desarrollado para capturar prácticas de ingeniería probadas. Aunque, estos estándares no han sido acoplados con otros que ayuden a evaluar la calidad del producto software [3]. El número de empresas dedicadas al desarrollo software está experimentando un notable crecimiento, en línea con el incremento de la demanda de productos del sector. Para este tipo de empresas, la calidad del software tiene un papel fundamental por su repercusión en los costos finales, así como los elementos diferenciadores de competitividad y de imagen frente a sus clientes. Además, son conscientes de las pérdidas económicas que los problemas de la calidad en el software pueden llegar a ocasionar. En definitiva, según el informe The CHAOS Manifesto del Standish Group en 2013, sólo el 39 % de los proyectos de desarrollo software finalizaron en el tiempo estimado, con los recursos planificados y con una calidad aceptable [4].. 7.

(17) En este contexto, las actividades relacionadas con la calidad de software están cobrando cada vez más importancia debido, principalmente, a dos factores. El primero es el aumento de la externalización, que consiste en que las empresas cliente deban evaluar y controlar la calidad de los productos software que les entregan las empresas desarrolladoras; y, a su vez, estas tienen que disponer de los recursos necesarios para asegurarse de que el producto que desarrollan cumplirá con las expectativas del cliente. El segundo es la proliferación de normas y certificaciones relacionadas con la calidad del software [4].. 1.5.1. Estado del arte. Las características elegidas para el estudio fueron resultado de un análisis que buscaba conocer las características más relevantes de la norma ISO/IEC 25000 para evaluar la calidad de software y las más usadas actualmente o en las cuales las empresas hispanoamericanas estaban más interesadas. En la figura 1.2 se muestran todas las características de la norma.. Figura 1.2: Características de calidad de producto de software ISO/IEC 25000 [2].. Se recolectó información respecto al tema y se llegó a la conclusión de que las empresas buscaban certificarse principalmente en 4 de las características que presenta la ISO/IEC 25000. AQCLab, el primer laboratorio acreditado a nivel mundial para evaluación de productos software y calidad de datos conforme al estándar ISO/IEC 25000 presenta certificaciones para las características de Mantenibilidad y Adecuación Funcional. Esta misma entidad especifica que la característica de Adecuación Funcional es una de las características más importantes en calidad de software puesto que implica que los productos software satisfagan las necesidades y los requerimientos de los usuarios [5]. De la misma forma establece que la característica de Mantenibilidad es una de las más. 8.

(18) frecuentemente solicitadas por los clientes de software, puesto que necesitan que sus productos puedan evolucionar y ser mejorados ya sea por parte de ellos mismos o por terceros [6]. Para las características de Seguridad y Usabilidad se hallaron trabajos en donde indican la alta importancia que tienen dichas características en la evaluación de calidad. Como es conocido, las empresas son altamente dependientes de sus sistemas de información debido a que forman parte de procesos clave para sus negocios. Por ello, la Seguridad es una característica importante para la protección de información frente a riesgos como errores humanos o técnicos, fraudes, desastres naturales, entre otros [7]. En estudios sobre la característica de Usabilidad sobre la calidad de software se destaca su importancia llegando a poner en la discusión de si esta característica es el factor determinante para el éxito que tenga todo un sistema software [8].. 1.5.2. Trabajos Relacionados al Estudio. Los trabajos investigados fueron divididos en las siguientes categorías: Modelos de Evaluación basados en ISO/IEC 25000, Estudios sobre uso de ISO 29110 en MIPYMES, Estudio sobre uso de métricas de ISO/IEC 25000 en MIPYMES, Estudio sobre uso de ISO 29110 en MIPYMES hispanoamericanas. Se encontraron varios estudios al respecto, pero al ir acotando más los títulos de las categorías, se reducían al mismo tiempo el número de referencias, concluyendo en la falta de precedentes específicos para el estudio que se realiza en el presente trabajo.. Figura 1.3: Trabajos relacionados [2].. Los criterios para la creación de la figura 1.3 fueron elegidos en base a la revisión de la literatura revisada en base al tema del presente trabajo. Los títulos de las columnas de. 9.

(19) dicha tabla se redactaron en base a características comunes que se encontraron en los trabajos.. 1.5.3. Investigación de Estado del Arte. Los resultados de la investigación del estado del arte se presentan a continuación agrupados por tema de análisis, en el orden previo que se indica en la tabla 1.3.. Resultados de Estudio sobre Modelos de Evaluación Basados en ISO/IEC 25000. La norma ISO/IEC 25000 y el proyecto KEMIS para su automatización con software libre [9]. En este artículo se establece una medición de la calidad de software bajo un punto de vista cuantitativo. Se indica que las métricas son la mejor vía para llevar a cabo la medición de calidad, específicamente, en cuanto a la calidad de producto. En este trabajo se muestra un diseño metodológico para la medición de la calidad del estándar ISO/IEC 25000 a base del estándar ISO/IEC 9126. Se enfoca en la medición de la calidad de la característica de mantenibilidad de la ISO/IEC 25000 para el producto "Kybele Environment Measurement Information System” (KEMIS). Esta medición se hará a base de la división 2502n, que corresponde a las mediciones de calidad y permitirá extraer de forma periódica y automática un conjunto de informes acerca de la calidad del producto; de manera que, se obtengan, entre otras cosas, métricas de código y microarquitectura dentro de la norma ISO/IEC 25000. Entre las métricas aplicadas de más relevancia se encuentran las líneas de código ("Lines of Code", LOC) y la complejidad ciclomática (“Cyclo- matic Complexity", CC). Entre las herramientas de software libre que permiten automatizar la medición de métricas destacan "JavaNCSS", "PMD", "JDepend", que junto con herramientas de construcción de software como "Maven” o “Continuum” permiten automatizar y personalizar las mediciones de un producto, necesidades de cada usuario y la capacidad de generar informes y representaciones de los resultados obtenidos.. Initial Framework for Software Quality Evaluation based on ISO/IEC 25022 and ISO/IEC 25023 [10]. 10.

(20) En el presente artículo se explica, en base a estudios, que solamente el 28 % de compañías aplican el estándar ISO/IEC, debido a que este contiene métricas, medidas, objetos de entradas y salidas demasiado complejas o ambiguas. Por consiguiente, la mayoría de las compañías tienden a utilizar sus propios modelos de calidad. Por ello, aquí se propone un marco de trabajo inicial, claro y comprensible de medición de calidad con un plan basado en la ISO/IEC 25022 y 25023. Este marco de trabajo propuesto consta de dos partes, Calidad de Producto y Calidad en Uso. En la primera, se abarcan características, métricas y medidas de calidad de producto tanto interna como externa basadas en la ISO/IEC 25023, y en la segunda parte se utilizan las características, métricas y medidas de calidad de uso basadas en la ISO/IEC 25022. Se definen 47 métricas de producto y 18 métricas de calidad en uso. Como se puede observar en la figura 1.4, para medir la calidad de producto será necesaria información previa así como manuales, especificaciones, entre otros. Y para medir la calidad en uso, la información debe ser recolectada y evaluada usando un cuestionario y un test de uso, para posteriormente, con base a los resultados, establecer qué características de su producto software son o no son suficientes desde el punto de vista de los estándares internacionales.. Figura 1.4: Esquema de Marco de Trabajo [10].. 11.

(21) The Applicability of ISO/IEC 25023 Measures to the Integration of Agents and Automation Systems [11]. En este artículo se discute el uso del estándar ISO/IEC 25023 para la evaluación de la integración de sistemas de automatización industrial y agentes software. En sus resultados se muestran que algunas mediciones son más relevantes que otras para dicha integración. También se determinó que algunas mediciones, concretamente las de naturaleza más técnica, eran difíciles de computar en la integración de sistemas automáticos o en su defecto, no proveían una guía práctica suficiente para ser llevada a cabo la evaluación. Con la aparición de Internet of Things (IoT) o Cyber-Physical Systema (CPS) se ha visto necesaria la integración de sistemas de automatización industrial y agentes software para su uso en temas como: automatización de fábricas, sistemas de energía y potencia, o automatización de edificios. Como discusión se tiene que ciertas características satisfacen el objetivo de proveer buenas capacidades de evaluación para la integración de sistemas de automatización industrial y agentes software, mientras que otras no lo hacen; puesto que, generan discrepancias entre un tema y otro, lo cual dificulta consecuentemente su integración. Estos problemas surgen por la cantidad de variables involucradas en dicha integración, como su ciclo de vida, el dominio o requerimientos de casos de uso o la elección del contexto exacto para los sistemas multiagente y los accesos a los componentes de los dispositivos. Por lo tanto, se concluye que de ser realizada la evaluación, de ninguna manera podrá ser de manera lineal ni de un solo proceso, si no que constaría de sucesivas versiones y con severas fluctuaciones a lo largo de todo el proceso.. Enhancing ISO/IEC 25021 quality measure elements for wider application within ISO 25000 series [12]. Este artículo presenta un enfoque innovador que se concreta en un conjunto básico de elementos de medición de calidad. Con dicha innovación s busca hacer una mejora a la capacidad de aplicación de la ISO/IEC 25021, que es crítica dentro de la serie de estándares SQuaRE. La metodología presentada dice pasar de un estado obsoleto y de gran cantidad de medidas a una lista central de medidas básicas que se pueden diversificar. Aún. 12.

(22) más, a través de contextos de uso, parámetros que permiten simplificar considerablemente el desarrollo de medidas derivadas. El método utilizado para la mejora de la norma ISO/IEC 25021 se fundamenta en una extensa revisión de otras normas similares a esta, las cuales pueden aportar valor adicional a la primera. Posteriormente se crea un modelo de QMEs (Quality Measure Elements) de todas las normas investigadas para hallar, tanto los elementos más útiles como sus falencias. En consecuencia, se requiere crear un conjunto de básico de QMEs lo más reducido posible que pase de un conjunto inicial de 67 a un total de 21, para en definitiva conseguir una amplia reducción de QMEs, el cual era el objetivo. Por tanto, es imprescindible aplicar un modelo sencillo, pero que abarque las bondades de gran cantidad de normas como se observa en el gráfico 1.5.. Figura 1.5: Base de Conocimiento QME [12].. Software Quality Assessment Applied for the Governmental Organizations using ISO/IEC 25000 [13]. El presente estudio comparte la experiencia en la aplicación del estándar ISO/IEC 25000 para la evaluación de los sistemas Outlook Web Access (OWA) y Thunderbird, detalla sus beneficios como un método para evaluar la calidad de software. Para ambos productos, se obtuvieron resultados por encima de 73 % en los porcentajes. 13.

(23) de calidad generales. La evaluación sobre satisfacción y libertad de riesgo obtuvo logros sobresalientes debido a que el producto OWA es similar a Microsoft Outlook, por tanto, los usuarios lo sienten familiar. En los resultados de la evaluación de calidad interna, externa y calidad en uso del producto Thunderbird se puede evidenciar que las características más fuertes son las de adecuación funcional, fiabilidad, usabilidad y compatibilidad. Es fundamental establecer la implementación de posibles e innovadoras ideas como trabajos futuros. Una de ellas, es la creación de un modelo gubernamental ecuatoriano para la evaluación de productos software utilizados en las instituciones del sector público que concierte con el acuerdo 166 y el estándar NTE ISO/IEC 27001, para que no solo provean una forma de automatizar la evaluación de calidad de estos productos, sino que también se añada la generación de reportes bajo el estándar que posteriormente debe ser aprobado por autoridades y organismos pertinentes. La otra idea consiste en la creación de un sistema de información que sea capaz de automatizar el modelo desarrollado en el presente artículo, con la capacidad de ser parametrizado en función de las características y necesidades propias de cada producto.. Resultados de Estudio sobre Uso de ISO/IEC 29110 en MIPYMES. A Multi-case Study Analysis of Software Process Improvement in Very Small Companies Using ISO/IEC 29110 [14]. Este documento detalla tres casos de estudio de organizaciones que implementaron la norma ISO/IEC 29110 con el propósito de ilustrar el uso de este estándar en un contexto industrial, así como proveer retroalimentación a los autores de la norma. El primer caso fue la implementación en un start-up de TI que consistía en el desarrollo de una aplicación web de alta calidad utilizando prácticas probadas de ISO 29110. En el segundo caso se implementó en una institución financiera, la cual es responsable del desarrollo y mantenimiento de las herramientas de software utilizadas por comerciantes. El tercer caso, se implementó en la división de una empresa de ingeniería que buscaba, mediante la utilización de la norma, la reducción de costos excesivos y retrasos en los proyectos. Se concluye que mediante el uso de ISO / IEC 29110, es posible planificar y ejecutar proyec-. 14.

(24) tos. También se pueden desarrollar productos o llevar a cabo proyectos utilizando prácticas comprobadas de ingeniería de sistemas o software sin interferir en la creatividad de los desarrolladores. Esta estrategia demuestra que todas las organizaciones, no solo las "Very Small Enti- ties” (VSE’s), tienen el imperativo de prestar atención a las prácticas de procesos de software, como las normas ISO.. Software Project Management in Very Small Entities with ISO/IEC 29110 [15]. El presente estudio analiza la función y la estructura de la gestión de proyectos en los ciclos de vida de los procesos de software de la norma ISO/IEC 29110 emergentes para entidades muy pequeñas, así como sus implicaciones prácticas. También se centra en el diseño y desarrollo de la documentación de soporte de gestión de proyectos y su uso asociado. Concluye en que como la norma ISO/IEC 29110 es una norma emergente, aún queda mucho trabajo por completar. Ejemplo de esto, es la necesidad de terminar la definición de perfiles incompletos como un proyecto de seis meses-persona de esfuerzo o una "start-up", la gestión de varios proyecto a la vez o prácticas de gestión de negocios y portafolios.. Reinforcing Very Small Entities Using Agile Methodologies with the ISO/IEC 29110 [16]. Este documento describe la experiencia para reforzar el proceso de desarrollo de software de 4 organizaciones de desarrollo de software que utilizaron metodologías ágiles e implementaron la norma ISO / IEC 29110 utilizando la metodología Scrum en México. El documento presenta esta experiencia, los beneficios, las lecciones aprendidas y los objetivos alcanzados. También se mencionan algunos de los principales problemas a los que se enfrenta un VSE al usar una metodología ágil, tanto en la administración del proyecto como en la implementación del software. Finalmente, concluye que el conjunto de prácticas provisto en la norma se puede implementar fácilmente y ayudar a los VSE a proporcionar productos de calidad dentro del presupuesto y programa aprobados.. 15.

(25) ISO/IEC 29110 Implementation on two Very Small Software Development Companies in Lima. Lessons Learned [17]. Este artículo recoge las experiencias de implementación del estándar ISO/IEC 29110 enmarcado en el contexto del proyecto ProCal-ProSer en dos microempresas que desarrollan software y que tienen expectativas de certificarse. Este estudio se manejó de manera corporativa en un conjunto de empresas en las ciudades de Lima, Trujillo y Arequipa, la experiencia de la implementación en estas dos empresas se ha comparado de modo que sirvan de base para otras iniciativas. En ambas empresas la evaluación inicial mostró que la adhesión a los procesos era de baja a media; pero al completar el ciclo de mejora, en todos los casos, se vio un incremento en el cumplimiento de las buenas prácticas.. Connecting Business Development and Systems Engineering with ISO/IEC 29110 Standard in Small and Medium Enterprises of France [18]. El estudio trata de cómo la Asociación Francesa de Ingeniería en Sistemas (AFIS) junto con el Gobierno francés ayudó a 6 empresas ubicadas en el sur de Francia a implementar procesos de Ingeniería de Sistemas, utilizando los procesos de ingeniería y gestión del marco ISO / IEC 29110, y midió la efectividad de sus acciones. Los resultados obtenidos muestran cómo estos procesos ayudaron a las PYMES a comprender los beneficios de la Ingeniería de Sistemas para su desarrollo empresarial, a adoptar un punto de vista más amplio y a comprender cómo cambia su entorno empresarial. Finalmente, los autores proponen que las PYME pueden abordar muchos de estos desafíos de desarrollo de negocios utilizando un marco de Ingeniería de Sistemas como el ISO / IEC 29110. Resultados de Estudio sobre Uso de Métricas de ISO/IEC 25000 EN MIPYMES. Integración de marcos de trabajo para desarrollo de software: Scrum, PSP e ISO 25000 [19]. 16.

(26) En este artículo se define un proceso de desarrollo de software en una PYME dedicada al desarrollo de productos software ERP, CRM y educativos, entre otros. La calidad de estos productos se mide mediante el uso de un conjunto integrado de marcos de trabajo conformado por ISO/IEC 25000, Scrum y Personal Software Process (PSP). Se hace uso también de herramientas de apoyo como los lineamientos establecidos por SWEBOK y la técnica Goal Question Metric (GQM) para determinar las métricas a evaluar. Las métricas de la ISO/IEC 25000 a evaluar se redujeron, debido a la extensión de la norma y en base a la respuesta del “product owner” de la empresa, a las siguientes: Funcionabilidad, Usabilidad, Eficiencia y Mantenibilidad. Además el proceso de integración se llevó a cabo a través de la valoración y unión de las actividades desarrolladas en todas las normas, ISO/IEC 25000, Scrum y PSP, obteniendo las ventajas de cada una de ellas. Como resultado de la aplicación del marco de trabajo implementado, se obtuvieron aumentos en el porcentaje de tareas completadas en los sprints, se detectaron falencias de calidad mayormente sobre las características de usabilidad y mantenibilidad. Además, se observaron ciertas dificultades como la alta cantidad de tiempo que se ocupó en las pruebas de calidad, en especial las de rendimiento y la tarea de generar los indicadores de cumplimiento.. Evaluación de Calidad de Productos Software en Empresas de Desarrollo de Software Aplicando la Norma ISO/IEC 25000 [20]. En esta tesis se muestra la evaluación de calidad completa del sistema LogiNotificador de la empresa Logiciel Cía. Ltda., bajo la norma ISO/IEC 25000, realizando las personalizaciones necesarias de este modelo para la total adaptación del modelo al producto. Al iniciar con la evaluación se definieron claramente las características del sistema a evaluar, las características de la norma y una planificación del proceso. Se asignaron porcentajes referenciales de nivel de importancia a las normas en función del sistema, como se puede visualizar en la figura 1.6.. 17.

(27) Figura 1.6: Definición del Nivel de Importancia para las Características y Subcaracterísticas [20].. Además, se definieron las métricas de la norma de forma detallada previo a su implementación y posteriormente, se realizó la matriz de calidad para evaluar cada parámetro, obteniendo un resultado global (calidad interna, externa y de uso) de 8, 35 (satisfactorio) donde se destacaron, con los mejores porcentajes, características como Adecuación funcional, Mantenibilidad y Compatibilidad.. Resultados de Estudio sobre Uso de ISO/IEC 29110 en MIPYMES Hispanoamericanas. Análisis de experiencias de mejora de procesos de desarrollo de software en PYMEs [21]. Este artículo presenta una revisión bibliográfica de modelos existentes para la mejora de procesos software, así como las experiencias de su aplicación, que contribuye a entender el entorno de su implementación. Se contó con 34 recursos bibliográficos, los mismos que fueron distribuidos entre artículos científicos, documentos oficiales, libros y sitios web oficiales. Se establece que los esfuerzos para conseguir un mejor producto software han derivado en el desarrollo de varios modelos de mejora de procesos como es el caso de la ISO/IEC 29110. En conclusión la ISO/IEC 29110 nace como el estándar para la aplicación de la. 18.

(28) mejora de procesos, definida de forma íntegra para las pequeñas empresas y a pesar de que tiene pocos años, ya existen empresas certificadas en el perfil básico por esto la norma ISO/IEC 29110, es una oportunidad para las Pymes de los países de Latinoamérica como la aplicación de un modelo de mejora de procesos en el desarrollo de productos software.. Análisis, Diseño Y Evaluación del Proceso Gestión del Proyecto de una Organización de Desarrollo de Software [22]. El presente trabajo se enfoca en detallar el proceso que va desde el análisis y diseño, hasta la evaluación, de la gestión de proyectos de desarrollo de software en empresas virtuales de la Universidad Peruana de Ciencias Aplicadas (UPC). Este objetivo se lleva a cabo en función de las normas ISO/IEC 29110 y la ISO/IEC 15504, las cuales sirvieron como apoyo para su implantación en las empresas virtuales de la universidad y para llevar a cabo la optimización y evaluación de los procesos software, respectivamente. En definitiva, el estudio indica que la norma ISO/IEC 15504 pudo aplicarse en función del marco de trabajo establecido por la ISO/IEC 29110, la cual es una norma adaptable, tanto para empresas físicas como virtuales, al ser una norma internacional. Además, se indica que, en países como México, Brasil, entre otros, ha sido adaptada la norma ISO/IEC 15504 para aplicarla a los procesos de desarrollo de software y certificación de sus empresas, logro que permite obtener ventajas competitivas y alcanzar un sitial preponderante en la industria de software internacional.. 19.

(29) 2 METODOLOGÍA. Para el presente proyecto se utiliza una metodología basada principalmente en la encuesta como técnica de investigación. Las actividades que conforman la presente técnica van desde la elaboración del cuestionarios hasta el tratamiento estadístico de los datos. Las actividades de la presente metodología fueron obtenidas de [23] con algunas modificaciones realizadas por los autores. Se compone de las siguientes actividades:. p Definición del objetivo de la encuesta p Reclutamiento de entidades de la encuesta p Diseño del cuestionario de la encuesta p Validación del cuestionario de la encuesta p Ejecución de la encuesta p Procesamiento de la información recolectada p Análisis de los resultados de la encuesta p Difusión de resultados. 2.1. DEFINICIÓN DEL OBJETIVO DE LA ENCUESTA. El objetivo de la encuesta es obtener información sobre la eficacia del uso de las métricas de calidad del software propuestas por la ISO/IEC 25000. Con esto no se presupone que las empresas utilicen algún tipo de métrica en particular, sino que se trata de indagar qué métodos de validación de calidad utilizan en sus productos y puedan asociarse a algún tipo de. 20.

(30) métrica. Todo ello, principalmente, dentro de las características de Adecuación Funcional, Usabilidad, Mantenibilidad y Seguridad. El tratamiento para recabar la información se tuvo que realizar de manera cordial, ágil y efectiva con el encuestado; puesto que, al aplicarse en varios países, la dificultad en obtención de respuestas es alta.. 2.2. RECLUTAMIENTO DE ENTIDADES A ENCUESTAR. Las empresas a reclutar para el buen ejercicio del diagnóstico se identificaron en base a los países miembros del HASTQB. Anexo A.1 Los países fueron: p Argentina. p Cuba. p Paraguay. p Bolivia. p Ecuador. p Perú. p Chile. p El Salvador. p República Dominicana. p Colombia. p México. p Uruguay. p Costa Rica. p Panamá. p Venezuela. Tras la identificación de estos países, se realizó una investigación sobre cuáles eran las entidades que agrupan o dan apoyo y seguimiento a las empresas desarrolladoras de software de cada uno de ellos. Dentro de las páginas oficiales de cada organización fue posible recoger un listado de 45 empresas desarrolladoras de software de cada país, obteniendo la base de datos hacia la cual se dirigieron las invitaciones a la encuesta. Entre ellas se encuentra la CITEC (Cámara de Innovación y Tecnología del Ecuador) que brindó su apoyo para realizer el envio official de una notificación, como se muestra en el Anexo A.2 a todas las empresas ecuatorianas desarrolladoras de software reconocidas por dicha organización. Además, fue posible conseguir el apoyo del HASTQB, el cual envío un detalle de la investigación vinculando a la encuesta, a todos los representantes de cada país miembro de la organización. Para poder obtener un mayor índice de respuestas se implementó el contacto directo con las empresas, principalmente, aquellas que facilitaban en sus páginas oficiales números. 21.

(31) telefónicos o redes sociales. Para ello fue necesario crear una campaña en canales de comunicación virtual con la invitación a ser parte de la encuesta por medio de una Fan Page como se muestra en la figura 2.1.. Figura 2.1: Fan Page creada para dar a conocer el estudio [24].. 22.

(32) 2.3. DISEÑO DEL INSTRUMENTO (CUESTIONARIO). El cuestionario inicia con el planteamiento del problema y los objetivos que se formulan para el instrumento. Se ideó una estructura de 3 fases, a base de la ayuda de la metodología Goal-Question-Metric (GQM) la cual se muestra en la figura 2.2.. Figura 2.2: Metodología Goal-Question-Metric [25].. La primera fase corresponde al nivel conceptual, en la cual se definen las metas de la encuesta en base a modelos de calidad. Al tener como metas el conocimiento de qué empresas utilizan un tipo de métrica u otro fue necesario incluir en la encuesta preguntas de tipo informativo de la empresa que contestará el cuestionario. Posteriormente, se incluyen las preguntas netamente técnicas, las cuales serán tratadas en la siguiente y fase. Por último se incluyen preguntas necesarias para conocer el nivel de satisfacción e interés que la encuesta pudo motivar sobre el encuestado. La segunda fase corresponde al nivel operacional. En esta fase se crean las preguntas para la encuesta teniendo en cuenta las métricas que pueden obtenerse de dichas preguntas. En este caso se utiliza como base el documento ISO/IEC 25023:2016 como se muestra en la figura 2.3, el cual detalla un ejemplo de cómo se definen las métricas de la ISO de las cuales se deben obtener respuestas para el estudio.. 23.

(33) Figura 2.3: Ejemplo Métricas Adecuación Funcional de ISO/IEC 25023:2016 [26].. La tercera fase corresponde al nivel cuantitativo, donde se recogen todas las métricas objetivo del estudio. Se contrastan las preguntas planteadas con las métricas de la ISO/IEC 25023:2016 para comprobar la eficacia del cuestionario. Como resultado de estas fases se obtuvo un cuestionario, anexo en A.6, constituido por los siguientes bloques de información. Información socio-demográfica de la encuesta: En este apartado se busca conocer información de la empresa con el fin de obtener un análisis más específico de las encuestas, esto lo podemos apreciar en Anexo A.4. Las preguntas formuladas para la recolección de datos socio-demográficos de las empresas se detallan a continuación: Seleccionar el país de origen de la empresa a la que pertenece. 1. ¿Cuántos años de existencia tiene la empresa? 2. ¿Cómo es considerada la empresa? 3. ¿En qué sectores se desarrolla la empresa? 4. ¿Qué tipos de proceso de desarrollo de software utiliza usualmente? 5. ¿Cuál es el porcentaje de recursos que estima que se destinan a pruebas en los proyectos de desarrollo de su empresa?. 24.

(34) 6. ¿Qué tipos de técnicas de pruebas utilizan? 7. ¿Qué tipo de pruebas utilizan? 8. ¿Qué normas o modelos utiliza como respaldo a sus procesos de software? Información técnica sobre el uso de métricas: Se incluyen las métricas de la ISO/IEC 25023, redactadas de manera explícita para el encuestado. Anexo A.5. Información de retroalimentación y de contacto: Se añadieron preguntas opcionales, sobre algún comentario que el encuestado desee manifestar o si desea recibir los resultados de la presente investigación. Anexo A.6. Las preguntas utilizadas para la recolección de información de retroalimentación y de contacto fueron: Escriba sus opiniones/recomendaciones acerca de la encuesta. ¿Desearía recibir los resultados una vez finalizado el proyecto? Ingrese su información de contacto para recibir los resultados.. 2.4. VALIDACIÓN DEL CUESTIONARIO. El cuestionario fue validado por expertos en la materia, concretamente, lo certificaron cinco especialistas en calidad de software.. 25.

(35) Figura 2.4: Ejemplo de revisión de las preguntas de encuesta. Elaborado por los autores.. Cada una de estas validaciones se utilizaron para depurar el cuestionario final y poder implementarlo en la herramienta para su posterior ejecución. La encuesta que se utilizó para que puedan realizar las validaciones se encuentra en el anexo A.3. Una muestra de las revisiones recibidas se muestra en la figura 2.4.. 2.5. EJECUCIÓN DE LA ENCUESTA. El cuestionario, que se encuentra en el anexo A.7, fue ingresado en la herramienta QuestionPro. Esta es una herramienta que permite crear encuestas en línea, con la capacidad de distribuirlas y analizar sus resultados. La forma de ejecución de la encuesta se ha realizado en función del modo de recepción de las encuestas respondidas, el cual está basado en un muestreo no probabilístico, concreta-. 26.

(36) mente, en un muestreo consecutivo. Cabe mencionar que este tipo de muestreo demanda elegir un grupo de muestra con todos los individuos accesibles que cumplan con los requisitos para el estudio y analizar dichos resultados. Todo ello en el tiempo que se necesario para obtener una muestra representativa, el cual fue definido en un número base de 135 MIPYMES para la presente investigación. Se procedió a crear listas con correos electrónicos de contactos de empresas aptas para responder la encuesta. Los contactos de las empresas fueron, en mayor parte, recogidos de directorios otorgados por asociaciones nacionales de cada país. De manera que, el número de correos enviados concuerda con el número de empresas incluidas en el estudio, tal como se muestra en la tabla 2.1.. 27.

(37) País. No Empresas. Directorio. Incluidas Argentina. CESSI - Cámara de Empresas de Software y. 45. Servicios Informáticos de la República Argentina) Bolivia. CBTI - Cámara Boliviana de Tecnologías de la. 19. Información Chile. CHILETEC - Asociación Chilena de Empresas de. 45. Software y Servicios A.G. Colombia. FEDESOFT - Federación Colombiana de la Industria. 45. de Software y TI Costa Rica. CAMTIC - Cámara de Tecnologías de Información y. 45. Comunicación Cuba. CALISOFT - Centro Nacional de Calidad de Software. 14. Ecuador. CITEC - Cámara de Innovación y Tecnología del. 45. Ecuador El Salvador. ASETI - Asociación Salvadoreña de Empresas de. 21. Tecnología México. AMITI - Asociación Mexicana de la Industria de. 45. Tecnologías de Información Panamá. CAPATEC - Cámara Panameña de Tecnologías de. 20. Información, Innovación y Telecomunicaciones Paraguay. CISOFT - Cámara de la Industria del Software del. 45. Paraguay Perú. APESOFT - Asociación Peruana de Productores de. 45. Software República. CAMARATIC - Cámara de Tecnologías de. Dominicana. la Información y la Comunicación. Uruguay. CUTI - Cámara Uruguaya de Tecnología de. 45. 45. la Información Venezuela. CAVEDATOS - Cámara Venezolana de Empresas de. 24. Tecnologías de la Información Total. 548. Tabla 2.1: Directorios por país y número de empresas contactadas. Elaborado por los autores, [27].. El correo enviado se detalla en la figura 2.5.. 28.

(38) Figura 2.5: Correo electrónico enviado a las empresas. Elaborado por los autores.. Se realizó el envío masivo de correos por medio de la herramienta. Sin embargo, al no tener la suficiente acogida, este método fue complementado con el envío de encuestas de una forma más directa. Esto consistió en recoger información de contacto de los sitios web de cada una de las empresas con el fin de enviar un mensaje más directo y personalizado, haciendo uso de diferentes plataformas como mensajería instantánea, redes sociales o. 29.

(39) números telefónicos. Cabe destacar que esta nueva forma de contacto implementada proporcionó el mayor número de respuestas al estudio. En conjunto, las dos formas de contacto permitieron obtener un total de 1,063 vistas a la encuesta. Lo cual, al tener un total de 181 respuestas completas, se determina que el índice de respuestas fue del 17,03 %.. 2.6. PROCESAMIENTO DE LA INFORMACIÓN RECOLECTADA. La información recolectada fue procesada con el fin de eliminar encuestas incompletas o vacías de empresas que no estaban dentro del alcance del estudio. Además, estas se fueron filtrando para satisfacer los objetivos propuestos al momento de crear la encuesta. Se utilizaron las bondades de la herramienta QuestionPro para obtener resúmenes gráficos y estadísticas. Sin embargo, para otros tipos de análisis, como porcentajes de encuestas por país fue necesario tabular datos de forma manual.. 2.7. ANÁLISIS DE RESULTADOS DE LA ENCUESTA. Se obtuvieron porcentajes de respuestas por país, porcentajes de respuestas en función de la métrica, en función de las normas de calidad y en función de las métricas por país. Con el fin de responder a las preguntas: ¿Cuáles son las métricas que más se utilizan?, ¿Cuáles son las normas de calidad más utilizadas?, ¿Cuáles son los países que más métricas de calidad utilizan? Estos análisis, debido a la diferencia de respuestas de cada país, fueron calculados proporcionalmente. Se efectuó un análisis particular de los resultados obtenidos para Ecuador, que tuvo un índice de respuesta por encima de los demás países de Hispanoamérica.. 2.8. DIFUSIÓN DE LOS RESULTADOS. Los resultados obtenidos fueron enviados a todos los participantes que lo hayan requerido. Para esto se revisaron todas las respuestas que hubieran indicado “Sí” en la pregunta. 30.

(40) “¿Desearía recibir los resultados una vez finalizado el proyecto?” Por tanto, se enviaron los resultados del estudio al correo electrónico indicado en el campo “Dirección de correo electrónico (Personal o de Empresa)” correspondiente al enunciado “Ingrese su información de contacto para recibir los resultados” ubicado al final de la encuesta. En la figura 2.6 se observa el detalle del porcentaje de respuestas de quienes requirieron o no los resultados del estudio.. Figura 2.6: Porcentaje de respuestas que desean recibir los resultados del estudio. Elaborado por los autores.. 31.

(41) 3 RESULTADOS Y DISCUSIÓN. 3.1. RESULTADOS. En el estudio realizado se obtuvieron un total de 181 respuestas válidas, las cuales se recogieron de los diferentes países miembros del HASTQB con la participación indicada en la figura 3.1.. Figura 3.1: Porcentaje de respuestas en función del país.. En Ecuador, país originario del estudio, se obtuvo la mayor acogida, con un 18,23 % de participación. Los demás países pertenecientes al HASTQB reflejan un porcentaje de participación que versan entre el 5 % y el 7 %. Además, otros países, ajenos al HASTQB fueron. 32.

(42) partícipes del estudio, tales como España y Holanda, cuyas respuestas no fueron consideradas para el estudio,debido a las condiciones preestablecidas para la investigación. Concretamente, fueron 3 respuestas externas al estudio, las cuales fueron eliminadas para lograr una análisis más preciso. Por otra parte también se recolectaron datos informativos de las empresas correspondientes a sus años de existencia y al tipo de empresa en base al número de sus empleados en la figuras 3.2 y 3.3 se evidencia las respuestas obtenidas.. Figura 3.2: Número de empresas clasificadas por su edad.. Figura 3.3: Número de empresas clasificadas por su tipo.. 33.

(43) Dentro de la encuesta se recibieron varias respuestas en cuanto al uso de métricas de calidad de software. En la figura 3.4 se detallan las respuestas obtenidas a la pregunta: “¿Utiliza métricas/procedimientos para medir una de estas características en sus productos software?”. Figura 3.4: Porcentaje de respuestas en función de la característica.. Los porcentajes corresponden al 100 % de las respuestas para cada característica.. Adecuación Funcional El 79,35 % de respuestas afirman que sí se utilizan métricas para medir la adecuación funcional de sus productos software, mientras que el 20,65 % respondió que no. A continuación se indica la tabla 3.1 con los porcentajes obtenidos de cada respuesta para cada una de las métricas dentro de la característica de Adecuación Funcional. Cabe recalcar que los porcentajes de cada métrica se determinaron en función del total de respuestas que afirmaron usar métricas/procedimientos para medir la presente característica. Para este caso, según lo indicado en la figura 3.1, el total global para los porcentajes de la tabla 3.1 corresponde al 79,35 %,. 34.

(44) % Empresas que considera que la Característica. Subcaracterística. Métrica. métrica sí se toma en cuenta en sus productos software. Adecuación Funcional. Completitud. Cobertura funcional. Funcional. (Functional Coverage). Exactitud. Exactitud funcional. Funcional. (Functional correctness). 91,78 %. 82,19 %. Pertinencia funcional de Pertinencia Funcional. objetivo de uso. 50,68 %. (Functional appropiateness of usage objective) Pertinencia funcional de sistema. 34,25 %. (Functional appropiateness of system) Tabla 3.1: Porcentajes de uso de métricas para la característica de Adecuación Funcional.. Usabilidad El 58,7 % de respuestas afirman que sí se utilizan métricas o procedimientos para medir la adecuación funcional de sus productos software, mientras que el 41,30 % respondió que no. Se muestra el detalle para la presente característica en las tablas 3.2, 3.3 y 3.4.. 35.

(45) % Empresas que considera que la Característica. Subcaracterística. Métrica. métrica sí se toma en cuenta en sus productos software. Completitud Capacidad. de la descripción. para reconocer. (Description completeness). su adecuación. Cobertura. Usabilidad. de demostración. 73,83 %. 59,81 %. (Demonstration coverage) Capacidad de autodescripción de. 25,23 %. puntos de entrada (Entry point self-descriptiviness) Efectividad de la documentación del usuario o ayuda del sistema Capacidad. (User guidance. de aprendizaje. completeness). 64,49 %. Campos de entrada por defecto. 59,81 %. (Entry fields defaults) Comprensibilidad de mensajes de error. 56,07 %. (Error messages understandability) Interfaz de usuario autoexplicativa. 45,79 %. (Self-explanatory user interface) Tabla 3.2: Porcentajes de uso de métricas para la característica de Usabilidad.. 36.

(46) % Empresas que considera que la Característica. Subcaracterística. Métrica. métrica sí se toma en cuenta en sus productos software. Consistencia operacional. 47,66 %. (Operational consistency) Claridad de mensajes. 73,83 %. (Message clarity) Usabilidad. Operatividad. Personalización funcional. 32,71 %. (Functional customizability) Personalización de interfaz de usuario. 38,32 %. (User interface customizability) Capacidad de monitoreo. 55,14 %. (Monitoring capability) Capacidad de deshacer. 29,91 %. (Undo capability) Categorización de información entendible. 28,04 %. ( Understandable categorization of information ) Consistencia en apariencia. 19,63 %. (Appearance consistency) Soporte de dispositivos de entrada. 22,43 %. (Input device support) Tabla 3.3: Porcentajes de uso de métricas para la característica de Usabilidad.. 37.

(47) % Empresas que considera que la Característica. Subcaracterística. Métrica. métrica sí se toma en cuenta en sus productos software. Capacidad de evitar errores. Usabilidad. Protección. de operación de usuario. contra errores. (Avoidance of user operation error). de usuario. Corrección de errores de entrada por parte. 57,01 %. 49,53 %. de usuarios (User entry error correction) Recuperabilidad de errores de usuario. 31,78 %. (User error recoverability) Estética de la interfaz de usuario. Apariencia estética de interfaz de usuario. 91,59 %. (Appearance aesthetics of user interfaces) Accesibilidad para usuarios con discapacidad. Accesibilidad. 24,30 %. (Accesibility for users with disabilities) Adecuación de lenguajes admitidos. 41,12 %. (Supported languages adequacy) Tabla 3.4: Porcentajes de uso de métricas para la característica de Usabilidad.. Seguridad El 56,22 % de respuestas afirman que sí se utilizan métricas o procedimientos para medir la adecuación funcional de sus productos software, mientras que el 43,78 % respondió que no. Se muestra el detalle para la presente característica en la tabla 3.5.. 38.

(48) % Empresas que considera que la Característica. Subcaracterística. Métrica. métrica sí se toma en cuenta en sus productos software. Capacidad de control de acceso Confidencialidad. 92,31 %. (Acces controllability) Exactitud de encriptación de datos. 53,85 %. (Data encryption correctness) Seguridad. Fortaleza de algoritmos criptográficos (Strenght of. 32,69 %. cryptographicalgorithms) Integridad de datos Integridad. (Data integrity). 82,69 %. Prevención de corrupción de datos internos (Internal data corruption. 48,08 %. prevention) Prevención contra desbordes de memoria. 31,73 %. (Buffer overflow prevention) Utilización de No repudio. firma digital. 43,27 %. (Digital signature usage) Efectividad de auditoría de usuario Responsabilidad. (User audit trail. 43,27 %. completeness) Retención de registros del sistema. 39,42 %. (System log retention) Suficiencia de métodos de autenticación Autenticidad. (Authentication mechanism. 55,77 %. sufficiency) Conformidad de reglas de autenticación. 28,85 %. (Authentication rules conformity) Tabla 3.5: Porcentajes de uso de métricas para la característica de Seguridad.. 39.

(49) Mantenibilidad El 34,05 % de respuestas afirman que sí se utilizan métricas o procedimientos para medir la adecuación funcional de sus productos software, mientras que el 65,95 % respondió que no. Se muestra el detalle para la presente característica en la tabla 3.6.. Característica. Subcaracterística. Modularidad. Mantenibilidad. Reusabilidad. Capacidad para ser analizado. Capacidad para ser modificado. Capacidad para ser probado. Métrica. Acoplamiento de componentes (Coupling of components) Adecuación de complejidad ciclomática (Cyclomatic complexity adequacy) Reusabilidad de activos (Reusability of assets) Conformidad de reglas de codificación (Coding rules conformity) Efectividad de los registros del sistema (Systema log completeness) Efectividad de funciones de diagnóstico (Diagnosis function effectiveness) Suficiencia de funciones de diagnóstico (Diagnosis function sufficiency) Eficiencia de modificación (Modification efficiency) Exactitud de modificación (Modification correctness) Capacidad de modificación (Modification capability) Completitud de funciones de prueba (Test function completeness) Capacidad de prueba autónoma (Autonomous testability) Capacidad de reiniciación de pruebas (Test restartability). % Empresas que considera que la métrica sí se toma en cuenta en sus productos software 61,29 %. 29,03 %. 59,68 % 30,65 %. 59,68 %. 50,00 %. 35,48 %. 64,52 % 38,71 % 32,26 % 43,55 %. 29,03 %. 20,97 %. Tabla 3.6: Porcentajes de uso de métricas para la característica de Mantenibilidad.. 40.

(50) En la figura 3.5 se indican las respuestas de las empresas en cuanto a métricas, independientemente de la norma en la que se basen o que utilicen. Por ello, se muestran también, a continuación, el detalle de respuestas a la pregunta: “¿Qué normas o modelos utiliza como respaldo a sus procesos de software?”. Figura 3.5: Porcentajes en función de las normas que señalaron las empresas. Elaborado por los autores.. El porcentaje de respuestas para el uso de la norma ISO/IEC 25000 es del 13,24 %. El mayor porcentaje 38,24 % de respuestas la obtiene el campo de “Otra”, que se refiere a cualquier otro tipo de norma, o bien, otra forma que tenga la empresa de medir la calidad de su software. A esta respuesta le sigue la norma CMMI-Dev con un 27,45 %. Por debajo de la ISO/IEC 25000 está la ISO/IEC 12207 con un 10,78 %. La ISO/IEC 29110 obtuvo un porcentaje de 6,37 % y finalmente la ISO/IEC 33001 con un 3,92. Entre las respuestas para la opción “Otra” se hallan las indicadas en la tabla 3.7.. 41.

(51) Norma / Modelo. Descripción. MCDAI Cuba. Modelo de la Calidad para Desarrollo de Aplicaciones. Se trata de un modelo de referencia ideado por el Centro Nacional de Calidad de Software (CALISOFT) de Cuba.. ISO 9001:2008 en base a. La norma ISO 9001:2008 se basa en el cumplimien-. directrices ISO/IEC 9003. to de un sistema de gestión de calidad centrado en los elementos de administración y optimización con los que cuenta una empresa. La ISO 9003 son normas contractuales que pueden certificar una empresa, organización o institución independientemente del tamaño de la misma.. ISO 9001:2015. La certificación 9001:2015 contiene cambios importantes respecto a sus versiones previas, aunque el más destacado es la incorporación de la gestión del riesgo o el enfoque basado en riesgos en los Sistemas de Gestión de la Calidad.. Tabla 3.7: Resumen de las normas o modelos alternativos ingresados por los encuestados [28], [29], [30], [31].. 3.2. DISCUSIÓN. A continuación, se relacionan los resultados obtenidos por métrica y por país, así como la diferencia de resultados entre Ecuador vs Hispanoamérica. Puesto que, Ecuador ha destacado más, debido al considerable incremento del valor de respuestas frente a los demás países pertenecientes al estudio.. 3.2.1. Análisis de Métricas por País. Mediante los resultados obtenidos por la encuesta realizada a MIPYMES, desarrolladoras de Software de Hispanoamérica, se pudo clasificar, por país, el porcentaje de uso de MIPY-. 42.

(52) MEs en cuanto a las características de: Adecuación Funcional, Usabilidad, Seguridad y Mantenibilidad, el resultado se presenta en el cuadro de la figura 3.6.. Figura 3.6: Porcentaje de uso de métricas por país.. Adecuación Funcional Los resultados obtenidos muestran que a nivel de Hispanoamérica los países que más utilizan la característica de Adecuación Funcional son Costa Rica y Paraguay mientras que los que menos la utilizan son El Salvador y Ecuador. Por otro lado, se puede evidenciar en. 43.

(53) la fig 3.7 que más del 50 % de las empresas de Hispanoamérica utilizan esta característica.. Figura 3.7: Porcentaje de uso de métricas de Adecuación Funcional por país.. Usabilidad. Según los resultados obtenidos los países de Hispanoamérica que más utilizan la característica de usabilidad son México, República Dominicana y Paraguay en cambio los que menos utilizan son Ecuador y El Salvador. En la fig 3.8 se puede observar que el uso de la norma de Usabilidad varia en la región, mostrando que mas del 50 % de Países utilizan esta característica.. 44.

(54) Figura 3.8: Porcentaje de uso de métricas de Usabilidad por país.. Seguridad. Los resultados obtenidos muestran que a nivel de Hispanoamérica los países que mas usan la característica de Seguridad son Argentina y México. En cambio, los que menos utilizan son Cuba, Panamá y Perú. En la fig 3.9 se puede observar que mas del 50 % de las empresas de los países de Hispanoamérica utilizan la característica de Seguridad.. 45.

(55) Figura 3.9: Porcentaje de uso de métricas de Seguridad por país.. Mantenibilidad. Los datos obtenidos muestran que los países que mas utilizan la característica de Mantenibilidad son México y Ecuador en cambio los países que menos la utilizan son Costa Rica y Panamá. En la fig 3.10 se puede apreciar que la mayoría de los países de Hispanoamérica no utilizan esta característica; ya que, en su mayoría menos del 50 % de las empresas señalan que utilizan la misma.. 46.

(56) Figura 3.10: Porcentaje de uso de métricas de Mantenibilidad por país.. En la fig 3.11 los resultados obtenidos revelan que en el 87 % de los países de Hispanoamérica las métricas de Adecuación Funcional son las más utilizadas, en contraste se tiene que 80 % de los países de Hispanoamérica tienen como métricas menos utilizadas a las de Mantenibilidad. También se puede observar que las métricas de Seguridad y Usabilidad mantienen resultados de uso similares que varían entre el segundo y tercer lugar.. 47.

(57) Figura 3.11: Porcentaje de respuestas por métricas en función del país.. 3.2.2. Ecuador vs el Resto de Países de Hispanoamérica. Los resultados obtenidos revelan que las MIPYMES desarrolladoras de Software de Ecuador utilizan menos del 60 % las métricas de: Adecuación Funcional, Mantenibilidad, Seguridad y Usabilidad. La fig 3.12 revela que en Ecuador la métrica que más se utiliza es Adecuación Funcional por otra parte la menos empleada es la métrica de Usabilidad.. Figura 3.12: Uso de métricas en Ecuador.. 48.