Español (pdf)
Articulo en XML
Referencias del artículo
Traducción automática
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
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.
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.
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.
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:
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:
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:
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:
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.
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.
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:
Tiempo estimado a nivel gestor y líder técnico.
Tiempo estimado del equipo de proyecto.
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).
