SciELO - Scientific Electronic Library Online

 
vol.32 número6Despacho óptimo de potencia reactiva considerando un abordaje multiperíodoParámetros de corte en brocas genéricas para su aplicación en pequeñas y medianas empresas metalmecánicas del Ecuador índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • En proceso de indezaciónCitado por Google
  • No hay articulos similaresSimilares en SciELO
  • En proceso de indezaciónSimilares en Google

Compartir


Información tecnológica

versión On-line ISSN 0718-0764

Inf. tecnol. vol.32 no.6 La Serena dic. 2021

http://dx.doi.org/10.4067/S0718-07642021000600191 

ARTICULOS

Calidad en el desarrollo de software en economías emergentes versus clase mundial: caso Chihuahua, México

Quality of software development in emerging economies versus world-class: Chihuahua (Mexico) case study

Carlos L. López-Sisniega1 

María del C. Gutiérrez-Diez2 

José L. Bordas-Beltrán2 

Ana B. Sáenz-Salinas1 

1 Tecnología de Gestión y Comunicación S.A de C.V, Chihuahua, México. (correo-e: clopez@tgc.mx; asaenz@tgc.mx)

2 Facultad de Contaduría y Administración, Universidad Autónoma de Chihuahua. Chihuahua, México. (correo-e: cgutierr@uach.mx; jbordas@uach.mx)

Resumen:

El objetivo principal de esta investigación es analizar si con el capital humano disponible en la ciudad de Chihuahua (México), es posible tener una organización de desarrollo de software que cumpla con los niveles de calidad que ofrecen empresas globales. Con un enfoque cuantitativo se analiza la cantidad de defectos generados de 15 proyectos de software administrativo realizados por desarrolladores egresados de universidades locales. Estos son analizados y comparados con referencias internacionales, incluyendo organizaciones globales de clase mundial. Los proyectos provienen de una organización local y utilizan los marcos de procesos de desarrollo de software de TSP (Team Software Process) y PSP (Personal Software Process). Los resultados muestran que los equipos de desarrollo locales son capaces de lograr niveles de calidad de excelencia. Por lo tanto, se concluye que independientemente del origen del talento humano, es posible competir en mercados de clase mundial.

Palabras clave: gestión; desarrollo; software; calidad; CMMI; TSP; PSP

Abstract:

The main objective of this study is to assess whether employing the available human capital from the city of Chihuahua (Mexico) is possible to build a software development organization that can achieve quality levels similar to that of world-class organizations. A quantitative approach is applied to evaluate the number of defects generated in 15 administrative software projects developed by graduates of local universities. These are analyzed and compared against international benchmarks, including that of world-class organizations. All projects are developed at a local organization and used TSP (Team Software Process) and PSP (Personal Process Software) software process development frameworks. The results show that local software development teams are capable of achieving quality levels of excellence. Therefore, it is concluded that regardless of the origin of the human talent, it is possible to compete against world-class markets.

Keywords: software; development; management; quality; CMMI; TSP; PSP

INTRODUCCIÓN

La industria de software es reconocida como un importante motor de desarrollo económico, al tiempo que es considerada una de las mejores opciones que tiene un país en desarrollo para convertirse en un participante importante en la industria de tecnología de información y comunicaciones (TIC) (Bonilla et al., 2015). Reconociendo esta oportunidad, muchos países en desarrollo han establecido estrategias exitosas para desarrollar su industria de software, en especial enfocada hacia las exportaciones (Aliyev, 2018). Tales estrategias incorporan políticas nacionales y regionales que juegan roles críticos en el desarrollo de la industria de software (Avgerou, 2010). Para las economías desarrolladas, el software tiene importancia desde dos perspectivas: 1) como un sector industrial económicamente importante por sí mismo y 2) como habilitador de innovación en otros sectores industriales. Es por ello que el impacto económico esperado de la innovación de software es posiblemente mayor cuando se observa su impacto en toda la economía y no cuando solamente se examina el capital invertido en el sector (Agolla y Van Lill, 2013; Ollo-López y Aramendía-Muneta, 2012).

Una de las estrategias utilizadas para hacer crecer la industria de software de un país, es enfocarse inicialmente en los servicios de tercerización (subcontratación) del desarrollo de software, ya que para permanecer competitivas, muchas organizaciones en todo el mundo acuden a estrategias de tercerización de aquellos procesos que no forman parte de su negocio principal (Mishra y Mahanty, 2016; Pellicelli, 2018). La subcontratación de los servicios basados en tecnología de información, y en especial el desarrollo de software, es una opción estratégica que los directores de informática de cualquier tipo de organización deben considerar (Ali et al., 2017). El software es cada vez más importante en la vida cotidiana de las personas y las organizaciones, su ubicuidad se manifiesta desde los aparatos electrodomésticos y los automóviles hasta los sistemas de información más avanzados que permiten el funcionamiento de todo tipo de organizaciones. La sociedad depende en gran medida del buen funcionamiento del software para que prosperen las organizaciones que la forman.

Sin embargo, el software no es un recurso que se obtenga libremente de la naturaleza; el software debe ser desarrollado para que cumpla a cabalidad con los requerimientos de sus usuarios. La industria mundial de software creció 10.9% entre 2010 y 2014; en 2020 alcanzó 466,647 millones de dólares, con un crecimiento de más del 10% anual, siendo el software empresarial el de mayor crecimiento, debido a la aceleración de los esfuerzos de digitalización por parte de las empresas que dan servicios virtuales como aprendizaje a distancia o telesalud (Gartner, 2021; Vinaja, 2015). En los últimos años la industria de software de México ha crecido más que quizá ningún otro sector. El mercado mexicano de software tuvo un valor de $3.4 mil millones de dólares en 2014, con un crecimiento de 5.7% respecto a 2013. En 2019, se estimó un valor de 4.8 mil millones, lo que implicaría un crecimiento desde 2014, de 41.2% (Alvarado, 2021).

Para 2021, se espera que el gasto mundial en software empresarial ronde alrededor de 517 mil millones de dólares, un crecimiento de 10.8% respecto de 2020. Como casi todos los sub-segmentos de la industria de TIC, ha experimentado altos niveles de crecimiento en los últimos años, con ganancias en el mercado que se han duplicado entre 2009 y 2019. Sin embargo, debido al impacto económico negativo traído por la pandemia, el gasto global de TIC disminuyó en 2020. A pesar de ello, se espera que para 2021 el crecimiento regrese a todos los sectores de la industria TIC (STATISTA, 2021). En México, el Gobierno Federal ha reconocido el carácter estratégico de esta industria tanto como una oportunidad importante para convertir al país en uno de los principales jugadores a nivel mundial, como para la modernización de las organizaciones mexicanas. Aun cuando los países líderes en servicios de desarrollo de software en el mundo tienen una ventaja por los sueldos bajos, en México se ha optado competir con base en calidad en vez de competir a partir de sueldos bajos (Gómez et al., 2014; Koteska et al., 2018).

La industria de software de Chihuahua, por su ubicación geográfica y la cultura de calidad que existe en la ciudad derivada de la existencia de diversas empresas globales que han instalado operaciones de manufactura en la región, tiene oportunidad de acceder al principal mercado del mundo que es el de Estados Unidos. En la ciudad de Chihuahua se ha creado un clúster de empresas de TIC, en el que la mayoría de ellas se dedican al desarrollo de software, básicamente de tipo administrativo, cuyos colaboradores provienen principalmente de instituciones educativas locales. Sin embargo, no existe información sobre la calidad del software que se desarrolla en la ciudad de Chihuahua, así como en otras economías similares. En esta investigación se busca analizar si es posible lograr los niveles de calidad requeridos en el mercado internacional del software, cuando es desarrollado por talento disponible en la ciudad de Chihuahua. Disponer de esta información puede ser muy útil para el sector público, privado y académico, en la definición de estrategias de desarrollo económico regional, estrategias de formación de capital humano y estrategias de inversión en la industria de software para la región. Por ello, el objetivo de este trabajo consiste en analizar si con el capital humano disponible en la ciudad de Chihuahua, es posible tener una organización de desarrollo de software que cumpla con los niveles de calidad que ofrecen las empresas globales que compiten en esta industria.

OTROS ANTECEDENTES

A raíz de los movimientos de calidad en manufactura que cobraron auge en la década de los ochenta, se popularizó la idea de que la calidad de los productos depende de la calidad de los procesos que se utilizan en su producción. En la industria de software se ha adoptado la premisa de que la calidad de un producto de software depende de la calidad de los procesos que se utilizan para desarrollarlo y mantenerlo (Vegendla et al., 2018). De manera similar, respecto del análisis de varios aspectos que inciden sobre la calidad del software desarrollado específicamente en Chile, donde se encontró que la fiabilidad, entre otros, tiene relevancia en el proceso de desarrollo de software (Vidal-Silva et al, 2017). Otro estudio que realiza una revisión de literatura orientada hacia de calidad es el de Guerrero y Londoño (2016), identificando cinco categorías dentro de esta, una de ellas la calidad dentro del proceso de desarrollo.

Modelos de calidad para la industria del software

En el desarrollo de software los proyectos fracasan principalmente por la falta de procesos que permitan una adecuada gestión de proyectos y por falta de procesos de ingeniería de software (Chevers, 2017; Lehtinen et al., 2014). En muchos aspectos, el desarrollo de software se puede considerar como una actividad artesanal cuando se lleva a cabo sin procesos formales. Las desviaciones en los calendarios y presupuestos, así como la alta dependencia hacia algunos de los miembros de los equipos de desarrollo de software, son frecuentemente características de proyectos enfocados al fracaso (Cataldo y Herbsleb, 2013; Chevers, 2017).

Las organizaciones que desarrollan software han buscado adoptar modelos de procesos que recomiendan cuáles son los procesos o áreas de proceso que se deben implementar para minimizar los riesgos en los proyectos y sugieren las mejores prácticas de la industria para mejorarlos. Existe una variedad de modelos de procesos desarrollados desde diferentes perspectivas dentro de la industria, por ello es frecuente escuchar acrónimos en inglés, como CMMI (Modelo de Capacidad de Madurez de Proceso Integrado), TSP (Proceso de software de equipo), PSP (Proceso Personal de Software), ISO (Organización Internacional de Estándares), RUP (Proceso Racional Unificado), entre muchos otros. Sin embargo, una organización debe comprender las perspectivas de los diferentes modelos de procesos para poder aplicar las recomendaciones de mejora de procesos que le convienen. Por ejemplo, CMMI e ISO 9000- 2001 se pueden considerar modelos de proceso a nivel organizacional que consideran todas las actividades que la organización debe llevar a cabo para producir software de calidad, desde el establecimiento de una infraestructura de control de procesos y calidad, hasta la gestión de la capacitación organizacional, pasando por los procesos propios de la gestión de proyectos e ingeniería de software. Estos modelos organizacionales sugieren qué es lo que la organización debería hacer, pero no la forma precisa sobre cómo debe hacerlo. Por otro lado, TSP, PSP y RUP se pueden considerar modelos enfocados exclusivamente a la ingeniería de software y prescriben la forma en que deben hacerse las cosas a nivel personal o de los equipos de desarrollo, y no necesariamente a nivel organizacional.

Análisis económico del desarrollo de software

Para conocer la forma en que el proceso de desarrollo de software aporta valor a la sociedad, es importante analizarlo desde la perspectiva de la economía, viéndolo como un proceso de producción. Por ello, en esta sección, se describen las diferentes formas para medir el desarrollo de software, para posteriormente describir la forma de medir la calidad en el desarrollo de software.

Métricas del proceso de desarrollo de software

Si se aborda al desarrollo de software como un proceso de producción, es importante medir la cantidad y calidad del producto generado, así como los insumos requeridos para producirlo. De acuerdo con Jones (2018a), las métricas más efectivas para medir el proceso de desarrollo de software son: 1) puntos de función para medir el tamaño del software, 2) potenciales de defectos relacionados con el tamaño medio en puntos de función, y 3) eficiencia en remoción de defectos (DRE por sus siglas en inglés). El insumo principal en el proceso de desarrollo de software es el tiempo del personal de desarrollo, denominado esfuerzo, y se mide contando las horas efectivamente dedicadas al desarrollo de software por cada persona del equipo de desarrollo. Para medir la producción, es importante contar con una métrica del tamaño del software ya que es fundamental para poder medir la calidad de los productos de software.

Para medir la cantidad de software que se produce (de aquí en adelante se referirá como tamaño) se usa la unidad de medida denominada punto de función. El punto de función es una unidad de medida del tamaño del software que mide las funciones del software, es decir, lo que hace el software desde la perspectiva del usuario final. Esta medida se norma bajo el estándar que propone que a las funciones (entradas, salidas, archivos, consultas, e interfaces) se les asigne un valor en puntos que se suma para conocer el tamaño de un módulo de software. Esta medición es independiente de la plataforma de desarrollo y ejecución del software. Para este estudio se usa la metodología de medición definida por el Grupo Internacional de Usuarios de Puntos de Función (IFPUG por sus siglas en inglés), aplicada al desarrollo de software para aplicaciones administrativas (Desharnais et al., 2011).

Para este estudio, la calidad del producto de los equipos de desarrollo se mide en función de la cantidad de defectos generados en cada uno de los equipos que es liberada al usuario final, en relación con la cantidad o tamaño del software que producen; a esta relación se le conoce como densidad de defectos liberados. Se considera defecto a cualquier falla en el software o alguno de sus componentes. Se consideran componentes del software a su documentación y todos los artefactos que son necesarios para el desarrollo, tales como casos de uso, casos de prueba, diagramas de arquitectura, código fuente, etc.

Medición de la calidad del desarrollo de software

Debido a la omnipresencia del software en las sociedades modernas, su calidad se vuelve un factor de suma importancia. Desde la perspectiva de los usuarios finales, la falta de calidad del software puede implicar desde molestias triviales, hasta pérdida de vidas humanas. Para las empresas, la mala calidad del software puede implicar altos costos e impacto en su reputación con graves consecuencias. Por su impacto en el costo, la calidad derivada de los procesos de desarrollo de software es un factor crítico en la competitividad de las organizaciones de software. Es poco conocido que el principal factor de costo en la industria del software es encontrar y corregir defectos, mientras que el segundo es producir documentación. La programación propiamente dicha es el tercer factor de costo de la industria (Jones, 2018a). Para medir la calidad se utilizan varias métricas como el potencial de defectos, la eficiencia en remoción de defectos (DRE, por sus siglas en inglés) y la densidad de defectos liberados. A continuación, se explican cada una de ellas.

La métrica de potencial de defectos se calcula a partir de las estadísticas de defectos encontrados en los proyectos anteriores de la organización que desarrolla el software. El potencial de defectos de una aplicación de software es la suma de los defectos probables en todas las fases del ciclo de desarrollo, es decir, en las fases de acopio de requerimientos, diseño, codificación, documentación e inclusive errores inyectados al tratar de corregir errores (Liu y Lavazza, 2021). Es común expresar el potencial de defectos en relación con los puntos de función. En 2017 el potencial de defectos promedio en Estados Unidos fue de alrededor de 4.25 defectos por punto de función con un rango desde menos de 2.00 defectos por punto de función, hasta un máximo de 6.50 defectos por punto de función (Jones, 2018a). No todos los defectos generados durante el desarrollo de software están en el código. Los errores en el código representan alrededor de 27% del potencial de errores total.

La segunda métrica importante para medir la capacidad de producir software de calidad por parte de una organización, es la DRE, definida como el porcentaje de defectos encontrados por cualquier técnica desde inspecciones, inspecciones automáticas de código o pruebas manuales o automáticas en relación con el potencial de defectos. El DRE promedio en Estados Unidos en 2017 fue de 92.50% con un rango desde 99.80%, hasta cerca de 78.00%. La mayoría de las técnicas de prueba tienen una eficiencia de 30.00%, es decir, encuentran un error de cada tres. El análisis estático tiene una eficiencia de alrededor de 55.0% mientas que las inspecciones en cada fase de desarrollo tienen una eficiencia de alrededor de 85.00% (Jones, 2018a). La tercera métrica utilizada para la calidad en la industria de software es la densidad de defectos liberados, que consiste en la cantidad de defectos que llegan al usuario final por punto de función. En este estudio la métrica de densidad de defectos liberados se utiliza para comparar los parámetros de calidad de los proyectos ejecutados por los equipos de desarrollo de Chihuahua, con los parámetros de calidad de la industria internacional.

Al aplicar dichas métricas de calidad se puede caracterizar la calidad del software. Por ejemplo, el software comercial en Estados Unidos en 2017 tuvo un potencial de defectos por cada punto de función de 3.50, una DRE de 97.50% y se entregan 0.09 defectos por punto de función al usuario final. El software en gobiernos municipales en Estados Unidos tiene un potencial de defectos de 4.80 por punto de función, una DRE de 90% y una tasa de liberación al cliente de 0.48 defectos por punto de función. El software administrativo (ERP, por sus siglas en inglés) en Estados Unidos tiene un potencial de defectos de 5.70 por punto de función, una DRE de 89% y una tasa de liberación al cliente de .63 defectos por punto de función. Hasta el año 2017, el promedio de la industria de desarrollo de software de Estados Unidos para DRE es de 92.50% cuando debería ser de 99.5% (Jones, 2018a).

Los datos de calidad por país son agregados y no muestran las metodologías utilizadas en cada caso. Sin embargo, cuando se consideran las metodologías, se han observado niveles de calidad aún más altos en algunas de ellas. Por ejemplo, TSP y PSP son muy robustas en cuanto a calidad, principalmente fundamentada en hacer inspecciones durante el proceso de desarrollo previo a las pruebas. Estas metodologías se basan en un riguroso sistema de medición de la calidad y la productividad, por lo que el desempeño de los equipos de desarrollo durante los proyectos genera una documentación muy completa, mejor que cualquier otra metodología (Jones, 2018b). Por ejemplo, un proyecto de TSP de mil puntos de función tiene un potencial de 2,350 defectos; una DRE antes de pruebas, de 85.00%; una DRE en pruebas, de 90.00% y una DRE de 98.50% en total. Por lo que al usuario final se liberan alrededor de 0.035 defectos por punto de función o 35 defectos por los mil puntos de función del proyecto. Dentro de estos 35 defectos, cinco podrían ser de alta severidad. Cuando se considera CMMI por nivel, la calidad del producto va mejorando considerablemente, como se puede observar en la Tabla 1.

Tabla 1: Calidad típica por nivel de CMMI (Jones, 2018a) 

Estudiar el desarrollo de software como un proceso productivo implica analizar los insumos del proceso y el producto desarrollado. El insumo principal en el proceso de desarrollo de software es la cantidad de recurso humano requerido, mientras que para analizar el producto desarrollado hay que conocer su tamaño y su calidad. La existencia de estándares para medir tamaño, esfuerzo y calidad permite avanzar en el perfeccionamiento del desarrollo de software al hacerlo una disciplina cada vez más ingenieril y susceptible de mejora continua.

Para comparar los resultados de los equipos de Chihuahua con los de la industria de software internacional y poder determinar si los equipos de Chihuahua son competitivos, es necesario caracterizar en términos de calidad lo que se considera un proyecto excelente, promedio y malo en un mercado de alta exigencia. Jones (2018b) realizó un análisis de 750 proyectos de desarrollo de software en empresas y organizaciones gubernamentales en Estados Unidos y cuantificó las principales características de proyecto, calificando los resultados de los proyectos como excelentes, promedio y malos. En la Tabla 1 se muestra un extracto de los resultados de Jones (2018a). La variable en este estudio es la calidad expresada en cantidad de defectos liberados por cada mil puntos de función desarrollados. Para poder realizar la comparación con los posteriores resultados, se presenta la Tabla 2 donde se muestran los parámetros de referencia de los proyectos excelentes, promedio y pobres de Jones (2018a).

Tabla 2: Datos de referencia de la industria de desarrollo de software en Estados Unidos organizados por resultado de los proyectos y nivel de CMMI, de acuerdo a Jones (2018a). 

METODOLOGÍA

El enfoque de la investigación fue cuantitativo ya que se buscó medir la calidad del producto de software generado por equipos de la industria de software de Chihuahua, orientados al desarrollo de aplicaciones de tipo administrativo, por medio de variables numéricas con el fin de compararlos con los niveles de calidad que ofrecen otras organizaciones que participan en el mercado mundial de desarrollo de software. Fue una investigación de tipo aplicada, ya que se utilizaron datos disponibles sobre organizaciones locales e internacionales. Asimismo, el diseño fue no experimental y longitudinal de tendencia, ya que buscó analizar los cambios presentados con el paso del tiempo en las variables de calidad de los productos de software. Su modo fue de campo, al estudiar los equipos en su ambiente de trabajo, y con apoyo bibliográfico al comparar sus resultados con referencias mundiales (Jones, 2018a), quien cuenta con datos de la industria mundial del software desde 1960. Es así que para lograr hacer esta comparativa, se seleccionaron los datos pertenecientes a 15 proyectos de desarrollo de software administrativo, llevados a cabo en una firma local perteneciente al clúster de TI. Dicha organización cuenta con las certificaciones y herramientas necesarias para el registro de los datos requeridos para hacer la comparación. Dicha comparación se hace de acuerdo a las características de los proyectos de software de corte administrativo, realizados bajo un enfoque de procesos. De igual manera, la demografía de sus colaboradores, puede considerarse representativa y similar a la de otras empresas desarrolladoras de software en la entidad, en lo referente a ambas cualidades.

Recolección de Datos

Se recolectaron datos de varios equipos de desarrollo ubicados en la ciudad de Chihuahua, desde agosto de 2014 hasta agosto 2017, pertenecientes a una organización que cuenta con evaluación de capacidad CMMI nivel 4. Los equipos analizados utilizan la metodología TSP, que requiere del registro sistemático y riguroso de datos de calidad, los cuales son registrados en la herramienta Tablero de proceso de software (SPD, por sus siglas en inglés). De los cuales se analizan tendencias y se comparan contra referencias mundiales para el desarrollo de software a la medida, enfocado a aplicaciones administrativas.

Cabe mencionar que la selección de los proyectos, en el período ya mencionado, se debe a que por una parte fue un muestreo no probabilístico definido por conveniencia, donde se privilegió la disponibilidad de datos a analizar por parte de los proyectos considerados. Adicionalmente, hay que recordar que dichos marcos de referencia permiten básicamente un auto-descubrimiento del propio proceso de trabajo, de la mano de la disciplina para el registro del mismo. Dichos enfoques hicieron posible lograr obtener los elementos necesarios para su respectivo análisis y posterior comparación, bajo un enfoque metódico. Por otra parte, debido a cláusulas de confidencialidad establecidas con los clientes, estos fueron todos los proyectos disponibles para el estudio.

Instrumento

La herramienta SPD fue desarrollada originalmente por la Fuerza Aérea de Estados Unidos y continuó su evolución bajo el modelo de software libre con la Licencia Pública General (GPL, por sus siglas en inglés). En ella, cada equipo captura las actividades que llevará a cabo para cumplir con los objetivos de su proyecto, así como los productos intermedios que se irán generando para cumplirlo. Para cada producto se estima tamaño y esfuerzo en horas por persona que se requieren para su elaboración. Aquí se recolectan tanto datos planeados como reales de tiempo, defectos y tamaño. Dicha herramienta apoya la metodología PSP/TSP, generando reportes que permiten analizar las tendencias históricas de datos.

La información utilizada y proporcionada a través del SPD contiene el detalle acerca de la participación de cada miembro del equipo, en cada uno de los ciclos de los proyectos. Cada ciclo registra su fecha de inicio y fin, la clave del equipo que lo ejecutó (equipo A, B o C), el número de integrantes del equipo, tipo de proyecto (nuevo o mantenimiento), ciclo de vida utilizado (cascada o iterativo) y tecnología usada (Java Enterprise Edition, .Net, etc.). Las claves observadas en el registro, como D1.1 se refiere a ciclo 1 del proyecto 1, mientras que D5.2, se refiere al ciclo 2 del proyecto 5.

SDP se encuentra instalado en el equipo de cómputo personal de cada miembro del equipo y coexiste con el ambiente de programación. De tal forma que la persona al iniciar una tarea, activa un cronómetro que registra la duración de su trabajo, el cual puede detener si hay interrupciones. Así es cómo se obtiene la suma de los tiempos reales que son comparados con los estimados. De igual manera la herramienta permite registrar defectos encontrados durante las inspecciones, la etapa en que fueron inyectados y el tiempo necesario para su corrección.

Unidad de análisis y variable

Las unidades de análisis fueron equipos de proyecto formados por un líder y ocho ingenieros desarrolladores de software, todos ellos contratados en Chihuahua y egresados de las diferentes instituciones de educación superior locales. El muestreo fue de conveniencia y el tamaño de la muestra fue de 15 proyectos. La variable de estudio fue la calidad de los productos de software. Dicha calidad se mide en función de la cantidad de defectos generados en cada uno de los equipos que es liberada al usuario final, en relación con la cantidad/tamaño del software producido. Dicha relación se denomina DRE. Considerándose defecto a cualquier falla en el software o alguno de sus componentes. Para medir la calidad para cada proyecto se calculó el total de defectos por ciclo, que proviene del registro del número de defectos por ciclo en todas las etapas del ciclo de desarrollo de software, y se identificaron los defectos detectados en pruebas de aceptación. Para hacer las comparaciones con los niveles internacionales, se calcularon las densidades de defectos totales del ciclo y del ciclo en pruebas de aceptación, al dividir el número de defectos entre el número total de puntos de función del ciclo.

Técnicas

Para hacer el análisis de datos, se capturaron los datos en Excel y se exportaron a Minitab 18, donde se hicieron los análisis, gráficas y diferentes pruebas estadísticas a los datos de los equipos de desarrollo de Chihuahua. Se considera que un proceso está bajo control si la variación de sus parámetros se mantiene dentro de los límites de control establecidos (Shewhart, 1931). Para validar que los procesos de desarrollo de Chihuahua están bajo control, se aplicaron las ocho pruebas de detección de causas especiales de variación disponibles en la herramienta Minitab 18, basadas en los criterios de Shewhart (1931). Las pruebas son: 1) un punto a más de tres desviaciones estándar de la media; 2) nueve puntos consecutivos en el mismo lado de la línea central; 3) seis puntos consecutivos, todos en orden creciente o decreciente; 4) catorce puntos consecutivos, alternativamente arriba y abajo; 5) dos de tres puntos a más de dos desviaciones estándar de la línea central del mismo lado; 6) cuatro de cinco puntos a más de una desviación estándar de la línea central del mismo lado; 7) quince puntos consecutivos dentro de una desviación estándar de la línea central en cualquier lado; 8) ocho puntos consecutivos a más de una desviación estándar de la línea central en cualquiera de los lados.

RESULTADOS

En primera instancia se presentan los datos que describen la composición de los miembros de los equipos que participaron en este análisis:

Tabla 3: Perfil de miembros de equipos 

Cabe mencionar, que durante el tiempo que duró el estudio, no hubo cambios en la composición de los equipos, únicamente al final del período una persona fue dada de baja. Siendo este otro motivo que coadyuvó a la selección de dichos proyectos. Todos los miembros han sido capacitados y certificados en PSP y TSP, para realizar los diversos roles establecidos para ello, recordando que estos equipos son auto-dirigidos.

En la Tabla 3, se presentan los datos de calidad por proyecto y por ciclo. Se presenta el total de defectos del ciclo y los defectos detectados en pruebas de aceptación, así como la densidad de defectos normalizada a 1,000 puntos de función para facilitar su comparación con los datos de referencia que se presentan en ese formato. Los datos de calidad se presentan en gráficas Individual y Rangos Móviles (I-MR, por sus siglas en inglés) a lo largo del tiempo para cada uno de los tres equipos. Las gráficas I-MR se recomiendan para analizar procesos cuyas mediciones son escasas por ser costosas, requerir mucho tiempo entre ellas o cuando el proceso es de muy bajo volumen. En las Figuras 1, 2, 3 y 4 se presentan las mediciones individuales en la parte superior con el valor de la medición en el eje de las ordenadas y el tiempo desde que se inició el primer proyecto del equipo en el eje de las abscisas. Adicionalmente, se muestran los límites de control superior (LCS) e inferior (LCI) que corresponden a tres desviaciones estándar respectivamente. En la Figura 1 se observan lo defectos del equipo A, el cual no tuvo defectos liberados en el primer ciclo del proyecto cuatro (D4.1) ni en el tercer ciclo del proyecto siete (D7.3). El equipo A entrega en promedio 22.6 defectos por cada mil puntos de función, ligeramente mejor que la referencia de CMMI nivel 5 que libera 23 defectos por cada mil puntos de función y se puede considerar competitivo. Se observan los altibajos que se tuvieron durante el transcurso del tiempo, presentando el mayor contraste en los últimos meses, cuando se observan la mayor cantidad de defectos, 58, para luego disminuir a cero. Este es el equipo que muestra más variaciones, pero a la vez logra el menor promedio de defectos. En la Figura 2 se observan lo defectos del equipo B.

Tabla 4: Calidad en cada ciclo por proyecto 

Fig. 1: Densidad de defectos liberados por el equipo A en forma individual. 

Fig. 2: Densidad de defectos liberados por el equipo B en forma individual. 

El equipo B entrega en promedio 37.8 defectos por cada mil puntos de función, mejor que la referencia de CMMI nivel 4 que libera 63 defectos por cada mil puntos de función y se puede considerar competitivo. Este equipo inicia con una de las mayores cantidades de defectos,78, para luego continuar obteniendo valores alrededor del promedio. Sin embargo, poco antes del final aumentan hasta 58 y en el periodo final mostrar una disminución importante, para terminar con siete. En la Figura 3 se observan lo defectos del equipo C.

Fig. 3 Densidad de defectos liberados por el equipo C en forma individual. 

A pesar de ser un equipo nuevo y contar con dos muestras de proyectos, el equipo C entrega en promedio 59.8 defectos por cada mil puntos de función, mejor que la referencia de CMMI nivel 4 que libera 63 defectos por cada mil puntos de función y se puede considerar competitivo. Este equipo es el que muestra un comportamiento más estable y menos variación en la generación de defectos. Aunque inicia con 79 defectos identificados, para terminar con alrededor de 40. Aunque muestra mejoría, es la menor, comparada con los otros equipos. En la Figura 4 se observan los defectos de todos los equipos.

En la Figura 4 se pueden observar los resultados de los proyectos de los tres equipos que en conjunto tienen una media de 34.6 defectos liberados por cada 1,000 puntos de función. Se observan las variaciones que en su mayoría se encuentran por debajo de la línea del promedio, sin embargo, no se obtiene un desempeño consistente. A pesar de lo cual se puede concluir que los resultados de los proyectos de los equipos locales, presentan mejores resultados en promedio que los proyectos de organizaciones con nivel 4 de CMMI (63 defectos liberados por 1,000 puntos de función), por lo que se pueden considerar competitivos. Sin embargo, los equipos no han llegado al nivel de excelencia del nivel 5 de CMMI, que libera 23 defectos por 1,000 puntos de función, lo cual demanda alcanzar mejores resultados en la prevención de la generación de defectos.

Fig. 4: Densidad de defectos liberados por todos los equipos en forma individual. 

DISCUSIÓN

Este estudio aporta elementos que contribuyen a disminuir la brecha respecto del conocimiento de las condiciones del desarrollo de software en economías emergentes, específicamente a través de caso de Chihuahua, México y haciendo uso del talento local. Asimismo, proporciona elementos concretos que ayudan a una evaluación objetiva de la calidad en el software desarrollado, al permitir una comparación clara con proyectos a nivel internacional.

Respecto de la comparación de este estudio con otros similares, como Vidal-Silva et al. (2017) y Guerrero y Londoño (2016), se carece, en ambos casos, de datos específicos respecto de proyectos o del capital humano disponible. En el primer estudio, solo se cuenta con la percepción de desarrolladores, y el segundo como una revisión de literatura más orientada a evaluar la calidad en el servicio en el desarrollo de aplicaciones en nube. Es así que se encuentran como limitantes de este estudio, la carencia de referentes similares que permitan una discusión más amplia; aunado a la cantidad de proyectos disponibles y con datos recolectados bajos las estrictas medidas que dictan metodologías de desarrollo, enfocadas a calidad.

En el caso de los estudios utilizados para realizar la comparación (Jones, 2018b), donde los datos de calidad por país son agregados, y que al incluir metodologías permiten observar mayores niveles de calidad. Tal es el caso de PSP y TSP, las cuales generan una documentación muy completa, por lo que fueron seleccionados proyectos que contaran con dicho marco de referencia. Adicionalmente, para lograr la comparación, se definieron en términos de calidad, diferentes niveles (excelente, promedio y malo), de acuerdo a un mercado de alta exigencia, como lo son las economías desarrolladas.

Es así que al comparar los datos de calidad por nivel de CMMI se puede observar que el valor de 63 defectos liberados por 1,000 puntos de función corresponde al nivel 4 de CMMI que, de acuerdo con el criterio utilizado para la comparación de productividad, se considera competitivo. Del análisis de los resultados de los proyectos ejecutados por los equipos formados por talento local, se encontró que en promedio los equipos tienen una tasa de liberación de defectos de 35 defectos por cada 1,000 puntos de función desarrollados, mejor a la referencia de 63 defectos por cada 1,000 puntos de función y muy cercana a los 23 defectos liberados por cada 1,000 puntos de función del nivel 5 de CMMI, considerado por Jones (2018a) como excelente y competitivo.

CONCLUSIONES

Es evidente la demanda que existe a nivel mundial para el desarrollo de software, en todas sus diferentes modalidades, así como la escasez del talento humano e insumo principal requerido para realizarlo. Esta demanda representa una oportunidad para las economías emergentes de fortalecerse y participar en el mercado internacional, ayudando a disminuir la brecha entre la demanda y la oferta. Específicamente, en el caso de empresas ubicadas en dichas economías y que desean competir a nivel internacional, su principal fuente de capital humano tiene su origen de manera local. Por lo que es necesario reconocer si las capacidades disponibles pueden asumir el reto de competir a nivel global, sin importar su ubicación u origen.

Para lograr hacer este reconocimiento de capacidades disponibles, la existencia de estándares internacionales hace posible la medición del tamaño, esfuerzo y calidad. De esta forma se fortalecen tanto el proceso del desarrollo de software, como la posibilidad de establecer comparaciones. Siendo así que este trabajo propone alinear ambos aspectos: la medición de la calidad a través de la generación de defectos en proyectos formados por talento local, y así lograr establecer comparaciones entre estos proyectos locales y los internacionales.

Es así como a través del reconocimiento y aplicación de dichos estándares internacionales, es posible reconocer la calidad de un producto de software, independientemente del origen o ubicación. Tal como se estableció al inicio, existe una escasez de estudios que permitan realizar una variedad de comparaciones, particularmente en lo referente a economías emergentes. Sin embargo, fue a través de los estudios realizado por Jones (2018a, 2018b), donde se muestran y clasifican los resultados obtenidos por diferentes proyectos registrados internacionalmente, que fue posible encontrar, analizar y comparar proyectos, desarrollados por equipos locales, que cumplieran con una rigurosa y disciplinada recolección de datos, bajo los marcos de referencia ya establecidos.

De acuerdo a los resultados de este estudio y su respectiva discusión, al hacer la comparación respecto de los datos obtenidos como referencia, se llega a la conclusión de que efectivamente en la ciudad de Chihuahua se cuenta con el talento humano necesario para desarrollar software de calidad de clase mundial, ya que pueden alcanzar niveles de calidad comparables a los niveles de excelencia referidos, de acuerdo a los mercados internacionales. Del análisis demográfico de los integrantes de los tres equipos de desarrollo, se encontró que la totalidad de ellos egresaron de alguna institución de educación superior del Estado de Chihuahua.

Es entonces que se posible observar que la complejidad inherente al proceso de desarrollo de software, no es un obstáculo que impida que su ejecución sea llevada a diferentes países, independientemente del nivel de avance de las economías donde se encuentren. Aunque estos resultados son de una pequeña muestra, contienen elementos para poder pensar en extrapolar dichos efectos a empresas con características similares, dentro de la región de Chihuahua, México.

REFERENCIAS

Agolla, J.E., y Van Lill, J. B., Public sector innovation drivers: a process model,htttps://doi.org/10.1080/09718923.2013.11893128, Journal of Social Sciences, 34(2), 165-176 (2013) [ Links ]

Ali, S., Hongqi, L., y otros tres autores, Success factors for software outsourcing partnership management: an exploratory study using systematic literature review, https://doi.org/10.1109/ACCESS.2017.2764946, IEEE access, 5, 23589-23612 (2017) [ Links ]

Aliyev, A. G., Methodological aspects of estimation of ICT-based economic development, https://doi.org/10.25019/MDKE/6.2.03, Management Dynamics in the Knowledge Economy, 6(2), 227-245 (2018) [ Links ]

Alvarado, R. A., Política pública para la apropiación de las TIC en organizaciones en México: el caso del Prosoft,https://doi.org/10.32870/pk.a11n20.577, PAAKAT: Revista de Tecnología y Sociedad, 11(20), 1-22 (2021) [ Links ]

Avgerou, C., Discourses on ICT and development, Information Technologies & International Development, 6(3),1-18 (2010) [ Links ]

Bonilla, L. B., Baraya, A. R., y otros dos autores, Revisiting the software industry in Costa Rica: achievements and challenges, https://doi.org/10.19030/jss.v8i1.9495, Journal of Service Science, 8(1), 29-32 (2015) [ Links ]

Cataldo, M., y Herbsleb, J. D., Coordination breakdowns and their impact on development productivity and software failures, https://doi.org/10.1109/TSE.2012.32, IEEE Transactions on Software Engineering, 39(3), 343-360 (2013) [ Links ]

Chevers, D. A., Toward a simplified software process improvement framework for small software development organizations, https://doi.org/10.1080/1097198X.2017.1321356, Journal of Global Information Technology Management, 20(2), 110-130 (2017) [ Links ]

Desharnais, J.M., Abran, A., y Suryn, W., Identification and analysis of attributes and base measures within ISO 9126, https://doi.org/10.1007/s11219-010-9124-5, Software Qual J, 19, 447-460 (2011) [ Links ]

Gartner, Press release, Newsroom, Gartner forecasts worldwide IT spending, https://www.gartner.com/en/newsroom/press-releases/2021-04-07-gartner-forecasts-worldwide-it-spending-to-reach-4-trillion-in-2021 (2021) [ Links ]

Gómez, O., Aguileta, A., Gómez, G., y Aguilar, R., Estudio del proceso de software personal (PSP) en un entorno académico, Revista ReCIBE, 3(2), 3-33 (2014) [ Links ]

Guerrero, C .A., y Londoño, J.M., Revisión de la problemática de la calidad del software para el desarrollo de aplicaciones de computación en la nube, https://dx.doi.org/10.4067/S0718-07642016000300007, Información Tecnológica, 27(3), 61-80 (2016) [ Links ]

Jones, C., Quantifying software: global and industry perspectives, 1a edición, 1-561. CRC Press, Boca Raton, USA (2018a) [ Links ]

Jones, C., Software methodologies: a quantitative guide, 1a edición, 1-578. CRC Press, Boca Raton, USA (2018b) [ Links ]

Koteska, B., Mishev, A., y Pejov, L., Quantitative measurement of scientific software quality: definition of a novel quality model, https://doi.org/10.1142/S0218194018500146, International Journal of Software Engineering and Knowledge Engineering, 28(3), 407 (2018) [ Links ]

Lehtinen, T. O. A., Mäntylä, M. V., y otros tres autores, Perceived causes of software project failures - an analysis of their relationships, https://doi.org/10.1016/j.infsof.2014.01.015, Information and Software Technology, 56(6), 623-643 (2014) [ Links ]

Liu,G., y Lavazza, L., Early and quick function points analysis: evaluations and proposals, https://doi.org/10.1016/j.jss.2020.110888, Journal of Systems and Software, 174,110888 (2021) [ Links ]

Mishra, D., y Mahanty, B., A study of software development project cost, schedule and quality by outsourcing to low cost destination, https://doi.org/10.1108/JEIM-08-2014-0080, Journal of Enterprise Information Management, 29(3), 454-478 (2016) [ Links ]

Ollo-López, A., y Aramendía-Muneta, M.E., ICT impact on competitiveness, innovation and environment, https://doi.org/10.1016/j.tele.2011.08.002, Telematics and Informatics, 29(2), 204-210 (2012) [ Links ]

Pellicelli, M., Gaining flexibility and innovation through offshore outsourcing, https://doi.org/10.3390/su10051672, Sustainability, 10(5), 1672 (2018) [ Links ]

Shewhart, W. A., Economic control of manufactured product, 7a edición, Van Nostrand Company Inc., New York, USA (1931) [ Links ]

STATISTA, Enterprise software total worldwide expenditure 2009-2022, https://www.statista.com/statistics/203428/total-enterprise-software-revenue-forecast/ (2021) [ Links ]

Vegendla, A., Duc, A. N., y otros dos autores, A systematic mapping study on requirements engineering in software ecosystems, https://doi.org/10.4018/JITR.2018010104, Journal of Information Technology Research, 11(1), 49-69 (2018) [ Links ]

Vidal-Silva, C.L, Madariaga, E. A, y Solís, R. A., Estudio piloto de la importancia del rendimiento, seguridad y fiabilidad en el proceso de desarrollo de software en Chile, https://dx.doi.org/10.4067/S0718-07642017000300011, Información Tecnológica, 28(3), 95-106 (2017) [ Links ]

Vinaja, R., Die internationalisierung deutscher softwarebasierter unternehme, https://doi.org/0001971748; 10.1080/1097198X.2015.1017407, Journal of Global Information Technology Management, 18(1), 72-74 (2015) [ Links ]

Received: June 24, 2021; Accepted: July 21, 2021

* Autor a quien debe ser dirigida la correspondencia. correo-e: cgutierr@uach.mx

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