SciELO - Scientific Electronic Library Online

 
 número45Ruta para selección de herramientas qué apoyan las EMPs en la implementación del estándar ISO/IEC 29110Implementación de plan de contingencia ante la pandemia COVID-19 llamado rompiendo paradigmas docentes índice de autoresíndice de assuntosPesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

versão impressa ISSN 1646-9895

RISTI  no.45 Porto mar. 2022  Epub 31-Mar-2022

https://doi.org/10.17013/risti.45.24-47 

Artigos

Propuesta de Métricas para la implementación del estándar ISO/IEC 29110

Metrics proposal for the implementation of the ISO/IEC 29110 standard

Jezreel Mejía1 

1 Centro de Investigación en Matemáticas- Unidad Zacatecas, Parque Quantum, Ciudad el Conocimiento. Avenida Lassec, Andador Galileo Galilei, Manzana, 3 Lote 7, 98160. Zacatecas, México. jmejia@cimat.mx


Resumen

El estándar ISO/IEC 29110 tiene como objetivo proveer y contribuir una serie de diferentes actividades, tareas y productos de trabajo que buscan mejorar la calidad de los diferentes productos de software desarrollado por Entidades Muy Pequeñas (EMPs). Sin embargo, la calidad no debe ser solo cualitativa sino cuantitativa a través del uso de métricas y aún en muchas EMPs existe el desconocimiento de la correcta aplicación de las diferentes métricas que pueden ser implementadas en este estándar. Este artículo presenta una propuesta de Métricas que apoyen a las EMPs en la implementación de este estándar y tener una visión cuantitativa en la calidad a nivel proceso, producto y proyecto. Para identificar las métricas viables, se analizaron dos proyectos presentados por dos EMPs para obtener su certificación, identificando el conjunto de métricas a través de la documentación presentada por las EMPs.

Palabras-clave: ISO/IEC 29110; entidades muy pequeñas; métricas de producto; proceso y proyecto

Abstract

The ISO/IEC 29110 standard aims to provide and contribute to a series of different activities, tasks and work products that seek to improve the quality of the different software products developed by Very Small Entities (VSEs). However, quality should not only be qualitative but quantitative through the use of metrics and even in many VSEs there is a lack of knowledge of the correct application of the different metrics that can be implemented in this standard. This article presents a metrics proposal that support VSEs in the implementation of this standard and have a quantitative vision of quality at the product, process and project levels. To identify viable metrics, two projects submitted by two VSEs to obtain their certification were analyzed, identifying the set of metrics through the documentation submitted by these.

Keywords: ISO/IEC 29110; Very Small Entities; Product; Process and Project Metrics

1. Introducción

De acuerdo a los resultados obtenidos de INEGI en 2018, existen más de 4 millones de empresas en México, de las cuales el 97.3% corresponden a microempresas (Mipymes), y 2.7% a PYMES (INEGI, 2018). Debido a su importancia en México el 76% de estas empresas fueron apoyadas por parte de PROSOFT, lo que indica su importancia en la industria del software, en este país (Laporte, et al 2017). Además, es importante resaltar que tienen una gran presencia en la industria del software en algunos países, donde alrededor del 94% está formado por este tipo de empresas (Mejia, et al 2020) (Galván-Cruz, et al 2021).

A nivel mundial, se encuentran asociada al desarrollo de software alrededor del 92% de las empresas (Mejia, et al 2021). Por lo tanto, este tipo de empresas están cada vez más interesadas en implementar estándares o modelos orientado a procesos que permitan guiar el desarrollo de sus productos y servicios de software adecuados a su tamaño y características. En respuesta a esta necesidad para las Entidades Muy Pequeñas (EMPs) o Micro, pequeña y medianas empresas (Mipyme), se crea el estándar ISO/IEC 29110 (ISO/IEC, 2011). El objetivo de este estándar es mejorar la calidad del producto a través del uso de dos procesos: el proceso de Gestión de Proyectos (GP) y el proceso de Implementación del Software (IS).

Sin embargo, alrededor del 15% de las EMPs han indicado que los estándares son complejos y no proporcionan una guía para su uso en un entorno pequeño (Laporte & Mejia, 2020). Este contexto, puede desencadenar problemas como productos de una calidad baja, por lo que deben evaluarse y mejorarse continuamente los procesos implementados (Choras, et al 2020). Para lograrlo, se requiere hacer uso de diferentes métricas de software, necesarias para evaluar tanto el proyecto, proceso y producto en este tipo de empresas y durante la implementación del estándar ISO/IEC 29110. Por lo tanto, la medición permite que la mejora continua no sea solo cualitativa sino cuantitativa.

Este artículo tiene como objetivo, proponer un conjunto de métricas viables identificas a través de un estudio de caso en dos EMPs que han permitido identificar métricas que pueden ser implementadas bajo el estándar ISO/IEC 29110.

Después de la introducción, este artículo se estructura como sigue: la sección 2 describe de manera general el estándar ISO/IEC 29110; la sección 3 presenta la clasificación de métricas que fueron seleccionadas; la sección 4 muestra el estudio de caso que sirvió para identificar y proponer el conjunto de métricas seleccionadas; y finalmente la sección 5 presenta las conclusiones y trabajo futuro.

2. ISO/IEC 29110

La ISO/IEC 29110 (2011) es una serie de estándares títulado “Ingeniería de Software - Perfiles de Ciclo de Vida para Pequeñas Organizaciones. Una Entidad Muy Pequeña (VSE por sus siglas en inglés - Very Small Entities) se define como una entidad (empresa, organización, departamento o proyecto) que tiene menos de 25 personas. La mayoría de las PYMES de software pertenecen a la categoría VSE [3]. Esta norma contiene dos áreas de proceso, las cuales se describen a continuación:

1. Proceso de Gestión de Proyectos (GP): El propósito de GP es establecer y llevar a cabo de manera sistemática las tareas del proyecto de implementación de software, lo que permite cumplir con los objetivos del proyecto respecto a la calidad, tiempo y costos esperados (ISO/IEC, 2011). Esta parte del estándar ISO/IEC 29110 está destinada a ser utilizada por las EMPs para establecer procesos para implementar cualquier enfoque o metodología de desarrollo que incluya, por ejemplo, un enfoque ágil, evolutivo, incremental, impulsado por pruebas desarrollo, etc., en función de las necesidades de la organización o el proyecto de VSE. Esta área de proceso contiene 7 objetivos (Galván-Cruz, et al 2021). El proceso de GP consta de cuatro actividades y cada actividad con un número de tareas especificas. Cada una de estas actividades con sus tareas producen los siguientes productos.

Productos de Entrada: los productos de Entrada son necesarios para realizar las tareas del proceso de GP.

  • Enunciado del Trabajo.

  • Configuración del Software.

  • Solicitud de Cambio.

Productos Internos: los productos internos para el proceso de GP son generados y consumidos por el mismo proceso.

  • Solicitud de Cambio.

  • Acciones Correctivas.

  • Acta de Reunión.

  • Resultados de Verificación.

  • Reporte de Avance.

  • Respaldo del Repositorio del Proyecto.

Productos de Salida: los productos de salida son aquellos que se generan al realizar las tareas del proceso de GP:

  • Plan de Proyecto.

  • Acta de Aceptación.

  • Repositorio del Proyecto.

  • Acta de Reunión.

  • Configuración de Software.

2. Proceso de Implementación de Software (IS): Su propósito es la realización sistemática del análisis, el diseño, actividades de construcción, integración y pruebas de productos de software nuevos o modificados de acuerdo con los requisitos (ISO/IEC, 2011). Esta parte del estándar ISO/IEC 29110 está destinada a ser utilizada por el VSE para establecer procesos para implementar cualquier enfoque o metodología de desarrollo que incluya, por ejemplo, un enfoque ágil, evolutivo, incremental, impulsado por pruebas desarrollo, etc. en función de las necesidades de la organización o el proyecto de VSE. El proceso IS, a través de la realización de cada una de sus actividades, pretende cumplir 7 objetivos al igual que el proceso de GP. Cada una de estas actividades con sus tareas producen los siguientes productos.

Productos de Entrada: los productos de Entrada son necesarios para realizar las tareas del proceso de IS.

  • Enunciado del Trabajo.

  • Plan del Proyecto Gestión de Proyectos.

  • Repositorio del Proyecto Gestión de Proyectos.

Productos Internos: los productos internos para el proceso de IS son generados y consumidos por el mismo proceso.

  • Resultados de Verificación.

  • Resultados de Validación.

Productos de Salida: los productos de salida señala son aquellos que se generan al realizar las tareas del proceso de IS.

  • Configuración de Software:

  • Especificación de Requisitos.

  • Diseño de Software.

  • Registro de Trazabilidad.

  • Componente de Software.

  • Software.

  • Casos de Prueba y Procedimientos de Prueba.

  • Reporte de Pruebas.

  • Manual de Operación.

  • Manual de Usuario.

  • Manual de Mantenimiento.

  • Solicitud de Cambio.

La Figura 1, muestra la estructura general de los procesos GP e IS con sus actividades y total de tereas.

Figura 1 Estructura de los procesos GP e IS 

Como puede observarse en la Figura 1, cada área de procesos tiene 7 objetivos. El proceso GP consta de 4 actividades y la sumatoria de sus tareas es de 26, donde la actividad 1 es la que contiene el máximo de tareas asignadas, 15 en total. Con respecto al proceso IS consta de 6 actividades y la sumatoria de sus tareas es de 41, siendo la actividad 5 es la que contiene el máximo de tareas asignadas, 11 en total. Como resultado se debe de realizar la implementación de 67 tareas que producen en total 22 productos de trabajo.

3. Métricas

Para realizar la identificación de métricas se tomo como referencias las métricas de Proceso, de producto y de Proyecto (Baso, 2014; Constanzo, et al 2014; Gehlot, et al 2019; Haindl, et al 2021; Noor, et al 2020; Rashid, et al 2019; Vogel, et al 2020) Ver Anexo A:

  • Métricas del proceso: Evalúan la vialidad y la naturaleza del proceso de programación (Rashid, et al 2019), permiten la obtención de indicadores que buscan a analizar avances en el proceso y el ambiente de desarrollo de software, utilizada para evaluar la eficiencia de un proceso, encontrándose atributos como el costo del desarrollo, esfuerzo y tiempo dedicado a pruebas, cantidad de personas por día, por mes, interrupciones, entre otros (Noor, 2020).

  • Métricas del producto: Evalúan la calidad de los productos entregables y la estimación de los elementos del trabajo obtenido en los diferentes periodos del desarrollo de software (Rashid, et al 2019), considerando atributos como el tamaño, calidad, complejidad, esfuerzo, volatilidad, entre otros (Noor, 2020).

  • Métricas del proyecto: Describen características propias del proyecto y su ejecución, reflejando las cualidades y la ejecución de la empresa, con el objetivo de reducir la planificación de desarrollo o minimizar defectos, para lo que consideran atributos como la duración real del proyecto, esfuerzo real por proceso, subproceso, por proyecto, costo total invertido, tamaño del proyecto, entre otros (Noor, 2020).

4. Estudio de caso

El desarrollo del estudio de caso se realizó en dos Mipymes de desarrollo de productos y servicios de software en el estado de Zacatecas, México. Para poder llevar a cabo la propuesta y viabilidad de las métricas, se solicitó la carpeta de los proyectos presentados, para obtener la certificación en el ISO/IEC 29110 de estas empresas.

La primera EMPs fue creada en el año 2005 y es una organización privada dedicada a la venta de productos y soluciones informáticas. Tiene como objetivo proveer de soluciones tecnológicas más eficaces y de mejorar el cumplimiento de los estándares de calidad deseados. Uno de los enfoques de dicha empresa el desarrollo de software a medida, tomando en cuenta estrictos estándares de calidad. La documentación presentada se enlista a continuación con la siguiente estructura:

1REQ

1.02_ EspecificaciónRequerimientos

MAT_Rastreabilidad

2DIS

3.01_CU

3.02_ModeloArquitectónico

3.03_BD-DD

3.04_PrototiposManualPreliminar

3DEV

UT

Acceso

AltadeUsuarios

Aretes

Médicos

Productores

Pruebas

UPP

4TST

IT

PlanPruebasIntegracion

ADM

Minutas

1.02_MIN_JuntaValidaciónRequerimientos20191003

6.04_ MIN_EntregaAlCliente20200331

MIN_JuntaAvanceCliente20191107

MIN_JuntaAvanceCliente20191205

MIN_ReporteAvance20191007

MIN_ReporteAvance20191104

MIN_ReporteAvance20191202

MIN_ReporteAvance20200106

MIN_ReporteAvance20200203

SolicitudCambio

Reportes

ReporteAvance20191007

ReporteAvance20191104

ReporteAvance20191202

ReporteAvance20200106

ReporteAvance20200203

1.01_EnunciadoTrabajo

1.03_PlanProyecto

1.04_PAC

1.05_PlanRiesgos

1.06_Cronograma

4.01_BitácoraVersiones

4.02_AccionesCorrectivas

6.05_ActaEntrega

6.05_ActaEntrega.pdf

CriteriosVerificaciones

SESIAJ-EstrategiaControlVersiones

ETC

Linea Base

LB_1REQ

LB_2DIS

LB_3DEV

LB_4TST

LB_5Final

Manuales

6.01_Manual Usuario

6.02_Manual Mantenimiento

6.03_Manual Operación

Finalconfig

1.02_EspecificaciónRequerimientos

6.01_Manual Usuario

6.02_Manual Mantenimiento

6.03_Manual Operación

La segunda Mipyme fundada en el año 2008. Tiene como objetivo ser pionera en el desarrollo de nuevas soluciones basadas en la innovación, constante perfeccionamiento, así como la total satisfacción del cliente a través de Ingeniería, Investigación y Tecnología de Clase Mundial. Las áreas de desarrollo Incluyen: Minería, Construcción, Pirotecnia, Academia e Instrumentación. Sus principales desarrollos se enfocan a: Desarrollo de Aplicaciones Mecatrónicas, Sistemas Embebidos e Internet de las Cosas; totalmente compatible con la plataforma de desarrollo de Atmel. La documentación presentada para la obtención de la certificación está relacionadas a 18 productos de trabajo que a continuación se enlistan:

Gestión del Proyecto.

  • Acciones Correctivas.

  • Acta de Aceptación.

  • Actas de Reunión.

  • Cronograma de actividades.

  • Descripción del Proyecto.

  • Plan de adquisición y capacitación.

  • Plan del Proyecto.

  • Reportes de Avance.

  • Solicitud de Cambio.

Implementación de Software.

  • Análisis y Diseño.

  • Casos de Prueba y Procedimientos de Prueba.

  • Especificación de Requisitos.

  • Manual de Mantenimiento y Operación.

  • Manual de Usuario.

  • Registro de Trazabilidad.

  • Reporte de Pruebas.

  • Reporte de Verificación y Validación.

  • Software.

4.1. Identificación de métricas

Para llevar a cabo la identificación de métricas que se proponen se realizó las siguientes actividades:

  • Análisis de las tareas y los productos de trabajo: el análisis de las tareas y la relación que tienen entre ellas desde el proceso de GP e IS fueron analizadas.

  • Análisis de documentación presentada: se tomo como referencia la documentación presentada por las dos empresas de desarrollo de software en consideración de la aplicación del estándar ISO/EIC 29110.

Tras la realización de las actividades anteriores, se detectaron 63 métricas viables agrupados de acuerdo a la Figura 2.

PRODUCTO:

Tamaño:

  • Líneas de Código (Medida en miles - KLDC), .

  • Puntos de Función (PF).

  • Páginas de Documentación.

Complejidad:

  • Complejidad Ciclomática.

  • Nivel de Acoplamiento de los Módulos.

  • Nivel de Modularidad (Cohesión de Módulos).

Calidad:

  • Cantidad de defectos por KLDC.

  • Cantidad de errores encontrados por KLDC.

  • Cantidad de defectos/errores que encuentran los usuarios después de la entrega.

  • Tipo y origen de los defectos (requerimientos, análisis y diseño, construcción, integración y pruebas).

Mantenimiento:

  • Cantidad de Componentes.

  • Volatilidad de los Componentes.

  • Complejidad de los componentes.

  • Cantidad de requerimientos nuevos, de cambios o mejoras.

  • Cantidad de requerimientos de corrección de defectos.

  • Tiempo promedio de corrección de errores ó defectos.

  • Tiempo promedio de cambios.

  • Porcentaje del código corregido.

Confiabilidad:

  • Tiempo transcurrido entre fallas

  • Tiempo esperado entre fallas

  • Tiempo requerido para corregir una falla

  • Nivel de severidad de la falla

Usabilidad:

  • Facilidad de aprendizaje de uso.

  • Errores cometidos por los usuarios con el uso.

  • Tiempo requerido para realizar las tareas.

Rendimiento:

  • Tiempos de respuesta (Acuerdos SLA).

  • Utilización de recursos (Troughput o Thruput) - cantidad de transacciones que pueden ejecutarse concurrentemente con un tiempo de respuesta razonable.

  • Tiempo de recuperación.

PROYECTO:

Esfuerzo

  • Cantidad de horas trabajadas.

  • Cantidad de personas que trabajan en el proyecto.

  • Tiempo transcurrido.

  • Distribución del esfuerzo por fase.

Costo:

  • Costo del Desarrollo.

  • Costo del Soporte.

  • Costo de hs/persona.

Productividad

  • Cantidad de software desarrollado por unidad de trabajo.

  • Tamaño/Esfuerzo.

  • Ritmo de entrega del software por unidad de tiempo transcurrido.

Seguimiento

  • Cronograma real vs Cronograma estimado.

  • Porcentaje de tareas completadas.

  • Porcentaje de requerimientos implementados por unidad de tiempo.

  • Porcentaje de tiempo total dedicado a las pruebas.

  • Porcentaje de error en la estimación de tiempo.

  • Costo sobre el valor agregado.

Estabilidad

  • Origen de los cambios en los requerimientos.

  • Cambios de los requerimientos en el desarrollo.

  • Cambios en los requerimientos en producción.

PROCESO:

Esfuerzo:

  • Distribución del esfuerzo por fase del proceso.

  • Cantidad de personas requeridas.

  • Esfuerzo requerido para corregir un defecto.

  • Esfuerzo requerido para mejorar un defecto.

Reusabilidad:

  • Cantidad de componentes reutilizados.

  • Grado de reusabilidad de los componentes.

Calidad:

  • Cantidad de defectos sin corregir.

  • Costo de corrección de defectos.

  • Eficacia en la eliminación de defectos.

  • Cantidad de veces que un módulo fue probado.

  • Tamaño de un módulo.

  • Tiempo promedio en corrección de defectos.

Soporte a clientes:

  • Tamaño del back log de defectos.

  • Tiempo de respuesta en atender los defectos.

  • Tiempo de resolución de defectos.

Herramientas:

  • Soporte de herramientas para procesos propuestos.

Asociado a la documentación analizada de las dos empresas, se identificó cuales elementos permiten obtener información asociada a las métricas identificadas. El Anexo A, muestra los productos de trabajo del estándar que inciden en la extracción de información para poder alimentar los datos de las métricas, las cuales se originan en el proceso de Gestión de Proyectos y reciben información a partir de datos generados en el mismo proceso o bien del proceso de Implementación de Software.

Figura 2 Total de métricas que pertenecen a cada categoría según su atributo 

Respecto a la información que se obtiene a partir del análisis de la documentación, y de acuerdo a la Figura 3, se observa que existe una gran cantidad de información que se obtiene a partir del análisis o implementación de casos y procedimientos de prueba, de donde se obtiene información para alimentar 26 de las 63 métricas.

Figura 3 Cantidad de métricas que pueden ser analizadas a partir del producto de trabajo generado 

Además, en la Figura 3 se observa que, para el caso de la documentación asociada a los componentes de software, se obtiene información para alimentar 25 de las 63 métricas y adicionalmente, mientras qué, asociado a los diferentes reportes de avance y reporte de pruebas, permite alimentar con información a 18 y 23 de las 63 métricas analizadas respectivamente, y finalmente del plan de proyecto se pueden cubrir 17 métricas.

En relación con la cantidad de tareas que cubren las diferentes métricas, es posible obtener que existen 7 tareas asociadas al proceso de Gestión de Proyectos que permiten alimentar estas métricas. Para el proceso de Implementación de Software, existen 15 tareas que permiten alimentar métricas, donde adicionalmente. Por lo tanto, se identificó que, para el proceso de Gestión de Proyectos, la tarea que presenta una mayor frecuencia en relación a su aportación de información a las métricas corresponde a la tarea 2.1 (Monitorear la ejecución del Plan de Proyecto y registrar la información actual en el Reporte de Avance), 28 de las 63 métricas presentadas en la Anexo A.

4.2 Propuesta de Mejoras para la implementación de productos de trabajo

Después del análisis de la documentación presentada por ambas EMPs y de los resultados obtenidos a través de la identificación de métricas y establecer su viabilidad que se presenta en el Anexo A, se identificaron mejoras con respecto a los productos de trabajo relacionadas a las métricas propuestas:

a) Tiempo estimado: la estimación de tiempo es la actividad de la planificación del proyecto que intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto. De acuerdo al análisis de las actividades de GP e IS, la estimación de tiempo debe realizarse a tres niveles para ser presentado en un plan de proyecto mas cercano al tiempo que se empleará en el desarrollo del proyecto, estos tres niveles son:

  1. Tiempo estimado a nivel gestor y líder técnico.

  2. Tiempo estimado del equipo de proyecto.

  3. Tiempo estimado global del proyecto.

b) Tiempo real: en el cronograma el Líder Técnico y el equipo de trabajo analizan los tiempos de acuerdo con el reporte de avance de cada miembro del equipo, y si hay algún pendiente en una tarea asignada poder tomar una decisión. Cabe resaltar que, si hay una solicitud de cambio y es aceptado, esta métrica será afectado, ya que cambiaría los tiempos de algunas tareas o en el peor de los casos el tiempo de todas las tareas. El cronograma real debe ser alimentado con los reportes de avance de cada miembro del equipo. Por lo tanto, puede existir algún ajuste en la estimación de tareas y en el tiempo real de cada tarea.

Por lo tanto, en relación con la generación de reportes de avances, esclarecer que debe existir a lo menos tres niveles de reportes de avance, siendo estos a nivel individual, para realizar el análisis del cumplimiento de las tareas por cada miembro del equipo, a nivel de equipo, siendo este el conjunto un análisis a partir de los reportes levantados por los miembros del equipo y reportes a nivel de proyectos, considerando los elementos anteriores para realizar el análisis del cumplimiento que se lleva como equipo y así realizar una comparativa con los demás proyectos en ejecución.

c) Costo Estimado: la estimación de costo es la actividad de la planificación del proyecto que intenta determinar cuánto dinero, esfuerzo y recursos tomará construir un sistema o producto. De acuerdo al análisis de las actividades de GP e IS, la estimación de costos debe realizarse a tres niveles para ser presentado en un plan de proyecto mas cercano al costo que implica todo el desarrollo del proyecto, estos tres niveles son:

Costo estimado a nivel gestor y líder técnico.

Costo estimado del equipo de proyecto.

Costo estimado global del proyecto.

d) Costo Real: en el cronograma el Líder Técnico y el equipo de trabajo analizan los costos de acuerdo con el reporte de avance de cada miembro del equipo, y si hay algún pendiente en una tarea asignada poder tomar una decisión. Cabe resaltar que si hay una solicitud de cambio y es aceptado, esta métrica será afectado, ya que cambiaría los costos de algunas tareas o en el peor de los casos el costo de todas las tareas. El cronograma real debe ser alimentado con los reportes de avance de cada miembro del equipo. Por lo tanto, puede existir algún ajuste en la estimación de tareas y en el tiempo real de cada tarea.

Con respecto a las métricas anteriores puede concluirse que es necesario que se deben desarrollar 3 planes de proyectos, uno de alto nivel (Requisitos y algunos requerimientos del proyecto), uno de bajo nivel, con el detalle de los requerimientos analizados por parte de los miembros del equipo de trabajo, para realizar la evaluación de los costos asociados para el desarrollo del proyecto y poseer información que permita alimentar el plan de proyectos de alto nivel para no incurrir en malas proyecciones respecto a lo planificado. Y finalmente, el plan de proyecto global, que es la versión que se entregará al cliente para ser validado por él.

5. Conclusiones y trabajo futuro

El estándar ISO/IEC 29110 fue creado para apoyar a Las Entidades Muy Pequeñas (EMPs) en la mejora de sus procesos de desarrollo de software, debido al rol que tienen muy importante en el desarrollo de software, las cuales tienen en promedio el 92% de representación a nivel mundial. Por lo tanto, es importante que las EMPs implementen de manera adecuada los procesos de este estándar. Sin embargo, debido a la falta de experiencia previa en el uso de estándares, la falta de comprensión del mismo y el desconocimiento de métricas asociadas al producto, proyecto y proceso que faciliten la evaluación cualitativa a lo largo de los proyectos desarrollados puede dificultar la correcta evaluación de la calidad.

En este artículo se muestra un conjunto de métricas que apoyan en la implementación del estándar. El hacer uso de diferentes métricas permite mejorar la calidad desde la perspectiva de las tareas asociadas a cada una de las actividades del estándar ISO/IEC 29110, así como permitir realizar un análisis respecto de la calidad desde el punto de vista del producto, proyecto y proceso. De acuerdo al Anexo A, se describe el tipo de métrica, su descripción; así como, en que tarea y producto de trabajo del estándar puede alimentarse.

El estudio de caso que se llevo a cabo, permitió proponer un conjunto de métricas que a través de la documentación presentada para obtener su certificación en el estándar ISO/IEC 29110 se identificó su viabilidad a través de la realización de los productos de trabajo. Como resultado, se lograron identificar 63 métricas. Además, se identifico que existe una gran cantidad de información que se obtiene a partir del análisis o implementación de casos y procedimientos de prueba, de la documentación asociada a los componentes de software, de reportes de avance y reporte de pruebas, y finalmente del plan de proyecto. Por lo que, es importante resaltar la importancia de estos productos de trabajo y su incidencia en la generación de información para implementar métricas. El resultado del análisis de la documentación de los proyectos presentados se fue posible obtener información para el 48% de las 63 métricas a partir de su documentacion. Lo que resalta la importancia de capacitar a las EMPs en el uso de métricas de producto, proyecto y del proceso. Finalmente, como resultado de este análisis a través de las métricas se identificaron hallazgos de mejora asociadas a los productos de trabajo o formatos entregados para mejorarlos y asociar estos a diferentes datos que son necesarios para implementar métricas, las cuales permitirán mejorar la base de conocimientos de las EMPs en relación con los proyectos realizados.

Como trabajo futuro, es analizar la correcta implementación en los productos de trabajo de las empresas que presenten proyectos para la obtención de la certificación en el estándar ISO/IEC 29110. Ademas, de incluir de manera explicita el uso de métricas asociadas a los productos de trabajo indicados en el Anexo A.

Agradecimientos

Este trabajo de investigación ha sido posible gracias a la participación de Mipymes de desarrollo de software en Zacatecas, México y por el trabajo aportado por los estudiantes de México (Edgar Bonilla, Israel Faustino, Einar Jhordany, Elizabeth Villanueva del Centro de Investigación en Matemáticas, Unidad Zacatecas, México) y de Chile (Octavio Zepeda Valero de la Escuela de Ingeniería Universidad Católica del Norte).

Referencias

Basso, D. (2014). Propuesta de Metricas para Proyectos de Explotacion de Informacion. Revista Latinoamericana de Ingenieria de Software, 2(4), 157. https://doi.org/10.18294/relais.2014.157-218. [ Links ]

Constanzo, M. A., Casas, S. I., Marcos, C. A. (2014). Comparación de modelos de calidad, factores y m.tricas", Informes Cient.ficos T.cnicos - UNPA, 6(1), 1-36. Accedido el 14 de enero de 2022. https://doi.org/10.22305/ict-unpa.v6i1.89 [ Links ]

Choras, M., Springer, T., Kozik, R., López, L. (2020). Measuring and Improving Agile Processes in a Small-Size Software Development Company", IEEE Access, 8, 78452-78466. https://doi.org/10.1109/access.2020.2990117 [ Links ]

Galván-Cruz, S., Muñoz, M., Mejía, J., Laporte, C.Y., Negrete, M. (2021). Building a Guideline to Reinforce Agile Software Development with the Basic Profile of ISO/IEC 29110 in Very Small Entities. In: Mejia, J., Muñoz, M., Rocha, Á., Quiñonez, Y. (eds) New Perspectives in Software Engineering. CIMPS 2020. Advances in Intelligent Systems and Computing, vol 1297. Springer, Cham. https://doi.org/10.1007/978-3-030-63329-5_2 [ Links ]

Gehlot, S. (2019). Complexity Metrics for Component Based Software - A Comparative Study. Journal of Computers, 14(6), 389-396. https://doi.org/10.17706/jcp.14.6.389-396 [ Links ]

Haindl, P & Plosch, R. (2021). Value‐oriented quality metrics in software development: Practical relevance from a software engineering perspective, IET Software, pp. 1-18. https://doi.org/10.1049/sfw2.12051 [ Links ]

ISO/IEC. (2011). ISO/IEC 29110-4-1:2011 Software engineering -- Lifecycle profiles for Very Small Entities (VSEs) -- Part 4-1: Profile specifications: Generic profile group. https://www.iso.org/standard/51154.htmlLinks ]

ISO/IEC 29110. (2011). Software engineering- Lifecycle profiles for Very Small Entities (VSEs) - Part 5-1-2: Management and engineering guide: Generic profile group: Basic profile. ISO/IEC TR 29110-5-1-2:2011. Technical report. http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html. [ Links ]

INEGI. (2018). INEGI Presenta Resultados de la Encuesta Nacional Sobre Productividad y Competitividad de las Micro, Pequeñas y Medianas Empresas (ENAPROCE) 2018. En A. Asociación Mexicana de Secretarios de Desarrollo Económico (Ed.), Comunicado de Prensa Num. 448/19, (pág. 16). [ Links ]

Laporte, C. Y. & Mejia, J. (2020). Delivering Software- and Systems-Engineering Standards for Small Teams. Computer, 53(8), 79-83. https://doi.org/10.1109/mc.2020.2993331 [ Links ]

Laporte, C. Y., Muñoz, M., Gerançon, B. (2017). The education of students about ISO/IEC 29110 software engineering standards and their implementations in very small entities. IEEE Canada International Humanitarian Technology Conference (IHTC), pp. 94-98. https://doi.org/10.1109/IHTC.2017.8058208. [ Links ]

Mejía, J., Bonilla, E., Faustino, I., Jhordany, E., Villanueva, E. (2020). GPIS:Tool to assess internal processes and projects based on ISO/IEC 29110," 2020 9th International Conference On Software Process Improvement (CIMPS), pp. 44-51. https://doi.org/10.1109/CIMPS52057.2020.9390129. [ Links ]

Mejia, J., Bonilla, E., Faustino, I., Jhordany, E., Villanueva, E. (2021). Apoyando a las Mipymes en la Evaluaci.n Interna de Procesos y Proyectos para la Certificaci.n en la Norma ISO/IEC 29110", RISTI - Revista Iberica de Sistemas e Tecnologias de Informação, (41), 80-96. https://doi.org/10.17013/risti.41.80-96 [ Links ]

Noor, H., Hayat, B., Hamid, A., Wakeel, T., Nasim, R. (2020). Software Metrics: Investigating Success Factors, Challenges, Solutions And New Research Directions. International Journal Of Scientific & Technology Research, 9(8), 38-44. http://www.ijstr.org/final-print/aug2020/Software-Metrics-Investigating-Success-Factors-Challenges-Solutions-And-New-Research-Directions.pdfLinks ]

Rashid, J., Mahmood, T., Nisar, M. W. (2019). A Study on Software Metrics and its Impact on Software Quality. Technical Journal, University of Engineering and Technology (UET) Taxila, Pakistan, 24(1), 69-82. [ Links ]

Vogel, M., Knapik, P., Cohrs, M., Szyperrek, B., Pueschel, W., Etzel, H., Fiebig, D., Rausch, A., Kuhrmann, M. (2020). Metrics in automotive software development: A systematic literature review. Journal of Software: Evolution and Process, e2296. https://doi.org/10.1002/smr.2296 [ Links ]

Anexo A

Anexo A Métricas existentes en ingeniería de software y análisis de las métricas y su obtención a partir de la documentación entregada. 

Recibido: 14 de Diciembre de 2021; Aprobado: 28 de Febrero de 2022

Creative Commons License Este es un artículo publicado en acceso abierto bajo una licencia Creative Commons