ISSN 0718-3291 Versión Impresa

ISSN 0718-3305 Versión en línea

Volumen 22 N° 3, Julio - Septiembre 2014

pdf Índice

Modelo para valorar las organizaciones al iniciar la mejora de procesos de software

 

Yaimí Trujillo-Casañola1 Ailyn Febles-Estrada2 Giraldo León-Rodríguez3

 

1Departamento de Calidad de Software. Universidad de las Ciencias Informáticas. Km. 2 1/2 Carretera a San Antonio Reparto Torrens. Boyeros, Ciudad de La Habana, Cuba. E-mail: yaimi@uci.cu
2Vicerrectoría de producción. Universidad de las Ciencias Informáticas. Km. 2 1/2 Carretera a San Antonio Reparto Torrens. Boyeros, Ciudad de La Habana, Cuba. E-mail: ailyn@uci.cu
3Viceministerio de Economía del Ministerio de Educación Superior (MES). La Habana, Cuba. E-mail: giraldo@reduniv.edu.cu


 

RESUMEN

En el presente artículo se exponen las dificultades que presentan las organizaciones para ejecutar la mejora de procesos de software y la tendencia a identificar factores críticos de éxito. Se fundamenta la utilidad de valorar las organizaciones desarrolladoras de software al iniciar la mejora de procesos teniendo en cuenta los factores críticos de éxito para identificar las fortalezas y debilidades de acometer el cambio. Se explica cómo mejorar la fase de diagnóstico y las técnicas aplicadas en esta área para identificar el estado de la organización integralmente. Los autores exponen en el artículo la propuesta de un modelo, con el uso de indicadores, métricas y un sistema de razonamiento basado en casos, considerando los factores críticos de éxito para realizar las recomendaciones. Los resultados permiten que las organizaciones cuenten con los principales factores que inciden en el programa de mejora para la gerencia del cambio. Se ratifica la importancia de la evaluación integral de la organización en torno a los factores críticos de éxito y se describe la manera de hacerlo.

Palabras clave: Mejora de procesos de software, factores críticos de éxito, indicadores, métricas, razonamiento basado en casos.


 

ABSTRACT

This article presents the challenges that organizations are faced with in order to run the software process improvement and the tendency to identify critical success factors are discussed. The usefulness of assessing software development organizations is fundamental to initiate process improvement, considering the critical success factors in order to identify the strengths and weaknesses of undertaking the change. The way to improve the diagnostic phase and the techniques applied in this area to identify the status of the whole organization is explained. The authors state that the proposed model, with the use of indicators, metrics and a system of case-based reasoning considering the critical success factors for their recommendations. The results allow that organizations acquire the main factors affecting the improvement program for change management. The importance of comprehensive evaluation of the organization's environment related with critical success factors is ratified and described.

Keywords: Software process improvement, critical success factors, indicators, metrics, case-based reasoning.


 

INTRODUCCIÓN

La Mejora de Procesos de Software (MPS) es un concepto relativamente nuevo, la mayoría de sus ideas, conceptos y métodos se han adoptado de la definición de calidad en el desarrollo del sistema de fabricación. La teoría alrededor de la MPS se ha formado a partir de los elementos tomados de los principales autores del área de la calidad, como Deming, Juran y Crosby, así como Humphrey y Basili quienes han sido los pioneros y líderes en este campo en la industria de software [1].

La MPS es una actividad repetitiva y con independencia del enfoque adoptado, requiere de cierto tiempo, recursos, medidas, y las iteraciones para su aplicación efectiva y exitosa. Es un procedimiento sistémico para mejorar el rendimiento de un sistema de procesos existente, a partir de desarrollar un conjunto de acciones que se manifiestan en modificaciones en el proceso de desarrollo de software.

Estudios de casos documentados de la MPS indican las mejoras más significativas en la calidad del producto y la productividad, los cuales son el resultado del esfuerzo de mejora [2-4]. Otros reportes no son tan alentadores, pues reflejan las dificultades que presentan las organizaciones para ejecutar los programas [4]. Los informes del Instituto de Ingeniería de Software (SEI por sus siglas en inglés), de la Universidad Carnegie Mellon, indican que la cantidad de fracasos es muy alta, llegando al 70% [4]. Varios autores concluyen que las causas principales que conllevan a estos fracasos se encuentran asociadas a las condiciones que posee la organización para iniciar la mejora de procesos referente a la influencia de las personas y la alta gerencia, las características de la organización y de la mejora en sí, entre otros [2-4].

Abundante literatura referente a las MPS contienen estudios de casos, evidencias, anécdotas e investigaciones, y en ellas se refleja la tendencia a identificar las dificultades más frecuentes como Factores Críticos de Éxito (FCE), los que se consideran determinantes en el éxito de un programa de MPS.

Para llevar a cabo la mejora y aumentar su probabilidad de éxito se han establecido modelos y guías que ayudan a ejecutar estos programas, como el Modelo IDEAL, y las propuestas regionales de MPS.Br en Brasil, MoProSoft en México y Competisoft en Iberoamérica.

Del análisis de los modelos y guías se puede definir que, aunque con diferentes nombres, todos ofrecen un marco para llevar a cabo la MPS desde su concepción, diagnóstico, implantación y evaluación. Es significativo destacar que todos reconocen el diagnóstico como la base para el resto de las fases y clave dentro de la MPS, consideran la identificación de las fortalezas y debilidades de la organización un elemento esencial para alcanzar resultados exitosos en la mejora. La información del diagnóstico es la entrada fundamental para comenzar el desarrollo del plan de acción estratégico que proporciona una guía y dirección a la MPS. Sin embargo, un análisis de los objetivos refleja el alcance limitado del diagnóstico:

Modelo IDEAL: Establecer los niveles actuales de la madurez de procesos y las descripciones de los procesos.
Guía para la implementación MPS.Br: Hacer un análisis de las debilidades de los procesos.
Guía para la implementación de MoProSoft:
Identificar el estado real de los procesos.

De los objetivos señalados se puede identificar que es enfocado a los procesos y no a determinar las condiciones particulares de la organización para abordar la mejora con garantías de éxito. Teniendo en cuenta que los factores críticos de éxito encapsulan las principales dificultades durante la mejora a partir de las experiencias de las organizaciones, es vital ampliar el objetivo del diagnóstico a valorar la organización desarrolladora de software al iniciar la mejora de procesos teniendo en cuenta los factores críticos de éxito para identificar las fortalezas y debilidades de acometer el cambio.

Para valorar las organizaciones desarrolladoras de software al iniciar la mejora de procesos, teniendo en cuenta los factores críticos de éxito para identificar las fortalezas y debilidades de acometer el cambio, es necesario formalizar el qué y el cómo hacerlo. Los autores de la investigación formalizan el qué valorar a los doce factores críticos de éxito identificados en el proceso de gestión de la información mediante métodos teóricos y empíricos de consulta de expertos [5].

 

ANÁLISIS TEÓRICO

Con el objetivo de formalizar cómo valorar una organización al iniciar la MPS los autores consideraron combinar tres áreas del conocimiento: medición y análisis, gestión del conocimiento e inteligencia artificial.

Son varias las investigaciones que abordan la necesidad de la mejora de procesos basada en el análisis estadístico de los indicadores y fundamentados en las experiencias [6-7]. La medición y análisis proporciona la base científica para la ingeniería de software que hace que sea una verdadera disciplina de la ingeniería [6-7].

El uso de indicadores en la MPS se orienta fundamentalmente a proporcionar métodos objetivos para caracterizar la capacidad del proceso y evaluar el efecto de los cambios, en general enfocados a productos, procesos y al proyecto [6-7].

Guceglioglu y Demirors sugieren que aunque la mayoría de los modelos de evaluación se ejecutan siguiendo las huellas de las prácticas ejecutadas, el uso de indicadores puede aportar elementos tangibles al análisis [7]. Por ejemplo, Kojima y otros autores [6] proponen indicadores para valorar los procesos antes de su puesta en práctica para analizar las deficiencias, del mismo modo Guceglioglu y Demirors [7] aplican indicadores para determinar el riesgo de fracaso de un proyecto en la etapa de inicio. Aunque los indicadores no son aplicables al problema de investigación, la idea fundamental fue útil para que los autores del presente artículo desarrollaran tres indicadores para valorar las organizaciones e identificar, a partir de los datos, si el impacto de un factor es negativo o positivo [8], teniendo en cuenta que las barreras y los riesgos identifican debilidades.

Barreras: son factores críticos de éxito que influyen de manera negativa y llevan al fracaso un programa de mejora de procesos.
Riesgos: vulnerabilidades ante un posible o potencial impacto negativo de los factores críticos de éxito.

Contar con la información de las experiencias de las organizaciones y el conocimiento de expertos es vital para la toma de decisiones por parte de los gerentes de programas de MPS. Pero en la problemática abordada en la investigación existen dos elementos que complejizan el análisis:

1. La ausencia de una codificación de la información que facilite su reutilización en otros programas de mejora.
2. El volumen de experiencias, anécdotas e investigaciones superan la capacidad humana de procesarlo manualmente.

Para hacer frente a esta situación se ha sugerido la gestión del conocimiento y un grupo de técnicas, métodos e intentos para simular el intelecto humano, que se han agrupado bajo el nombre de inteligencia artificial [9-10]. Estas tecnologías sirven de soporte para el análisis y virtualización de la información. Entre las técnicas más comúnmente usadas están: redes neuronales artificiales, algoritmos genéticos, razonamiento basado en casos (RBC) [9-10] y otros.

Estas técnicas tienen campos de aplicación más adecuados según sus características y el problema a resolver. Al tener en cuenta las características del problema que se trata en la investigación, enfocado al empleo de los resultados de las experiencias de las organizaciones para ser usado en la valoración de nuevos programas de mejora, se considera adecuado por parte de los autores el uso del RBC. Esta técnica consiste en utilizar las experiencias para comprender y resolver problemas [9-10].

En el RBC se compara el problema presentado comparando un caso, con los casos almacenados previamente en la biblioteca o base de casos, recupera los casos similares y adapta las soluciones que funcionaron en el pasado al problema actual, siendo una fuente importante de criterios que ayudan a la toma de decisiones. Para que un sistema RBC comience a funcionar es suficiente con tener varios casos resueltos [10]. En el contexto de la investigación se pueden describir como rasgos predictores la evaluación de los FCE en las organizaciones (descripción del problema) y rasgos objetivos, las buenas prácticas y el resultado de la mejora de procesos (éxito o fracaso).

De este análisis los autores concluyen:

1. Que es adecuado aplicar indicadores y métricas para establecer el cómo realizar la valoración de las condiciones iniciales de la organización y orientar acciones que permitan desarrollar los aspectos positivos y contrarrestar los aspectos negativos.
2. Para el análisis de la información y el conocimiento que se genera de la evaluación de los indicadores en las organizaciones es necesario apoyarse en la gestión del conocimiento y técnicas de inteligencia artificial que faciliten la transformación y el procesamiento del conocimiento.

 

MÉTODOS

En la investigación primeramente se utilizó el análisis y la síntesis para la búsqueda de experiencias documentadas que sustenten la investigación. En conjunto con esto se hizo uso de la inducción-deducción para llegar a los puntos de contacto del marco teórico con el objeto de investigación. Los métodos de consulta de expertos como el método Delphi y la encuesta, la entrevista y las técnicas de grupo focal permitieron explicitar el conocimiento de expertos y de miembros de las organizaciones para incorporarlo a la propuesta del modelo, el que fue validado por el método un cuasiexperimental.

 

MODELO SI.MPS.CU

La creación de un modelo para valorar las organizaciones desarrolladoras de software al iniciar la mejora de procesos con el uso de indicadores, métricas y un sistema de razonamiento basado en casos que considera los factores críticos de éxito para realizar las recomendaciones, constituyó una etapa significativa en la investigación.

El modelo se sustenta en los siguientes principios, enfoques, cualidades y premisas.

Los principios que sustentan el modelo son:

• Integración de los factores críticos de éxito con los indicadores para valorar una organización, identificar las barreras y los riesgos para la mejora y recomendar las buenas prácticas.
• Carácter participativo y de cooperación en el proceso de medición para facilitar la obtención de los datos y la calidad de las mediciones.

Los enfoques científicos empleados para la construcción del modelo son:

• Mejora continua: la mejora permanente se expresa en la retroalimentación de los resultados de la mejora y el análisis del impacto del modelo.
• Sistémico: se expresa en el modelo propuesto por medio de la interacción de los componentes para obtener las salidas del modelo.
• Estratégico: se manifiesta en el objetivo del modelo de llevar a las organizaciones a un estado más propicio para el éxito en la mejora de procesos de software.

Las cualidades son:

• Integración: entre la mejora de procesos de software, la medición y análisis y la gestión de la información.
• Iterativo e incremental: los resultados de la aplicación del modelo puede acordar una nueva iteración y la experiencia incrementa el número de casos en sistema de RBC para elevar la calidad del pronóstico.
• Capacidad de retroalimentación: el modelo parte de las necesidades de las organizaciones y se retroalimenta de los casos analizados y los resultados de su instrumentación.

Finalmente, el modelo parte de la premisa: voluntad de la alta gerencia de la organización desarrolladora de software de la necesidad de la mejora de proceso de software. El modelo funcional propuesto con sus componentes y relaciones se presenta en la Figura 1.


Figura 1. Arquitectura del modelo para valorar una organización al iniciar la mejora de procesos de software.

El componente Evaluación del Impacto de los Factores Críticos de Éxito transforma los datos de la organización y el modelo de referencia deseado por la organización para evaluar los indicadores y obtener las métricas. Además obtiene las medidas base que son la entrada al componente Pronóstico de la mejora basado en experiencias, el que con un sistema de razonamiento basado en casos determina los casos similares y realiza un análisis de los resultados de éxito y fracaso. Con la evaluación de los indicadores las métricas de garantía de éxito y el pronóstico de la mejora basado en casos similares, el componente Evaluación de la organización identifica las barreras de la mejora y las buenas prácticas a recomendar, a partir de ella la organización puede decidir si inicia o no la mejora.

Con las salidas del modelo se propone hacer un análisis utilizando el método de triangulación metodológica, del que se obtiene la información para arribar a las conclusiones del diagnóstico. Los autores sugieren, en función de la experiencia y los estudios realizados en la investigación, que la interpretación de los resultados para cada una de las posibles recomendaciones sea:

1. Iniciar la mejora de procesos se software cuando la métrica se evalúa en Muy Adecuado o Adecuado y el pronóstico de éxito es superior al 60%.
2. Iniciar la mejora de procesos de software bajo riesgo: cuando la métrica se evalúa de Poco Adecuado y/o el pronóstico está en el rango de 40% a 60%.
3. No iniciar la mejora de procesos de software cuando la métrica se evalúa en No Adecuado y/o el pronóstico es inferior al 40%.

Estas recomendaciones se refuerzan con el análisis de la capacidad que tiene la organización de implementar actividades que disminuyan el impacto negativo de los FCE, esto se obtiene de los indicadores. Para ello se deben tener en cuenta las buenas prácticas que pueden implantar en la organización y de estas los riesgos y las barreras en las que impactan. Mientras más riesgos y barreras se cubran, mejores condiciones posee la organización para la mejora. Aunque no deba ser lo más común, estos elementos pueden conducir a variar las recomendaciones anteriores sobre todo en los casos donde se está cercano a los límites.

A partir del modelo se elaboró una metodología para evaluar las organizaciones al iniciar la mejora de procesos de software, que define un conjunto de fases y actividades que están en correspondencia con las entradas, salidas y componentes del modelo. Esta metodología brinda el marco para el análisis del estado de las organizaciones al iniciar la mejora de procesos de software empleando la información resultante del modelo.

Para la aplicación de la metodología es necesario que se cumplan los siguientes requisitos:

• Contar con los datos de la organización que constituyen entradas a los componentes.
• Definición del modelo de referencia que desea implantar la organización.
• Contar con los directivos de la organización para la toma de decisiones.
• Contar con la aplicación informática que automatice el procesamiento de la información.

Como se observa en la Figura 2, las fases de la metodología son: Configuración, Planificación y Organización, Ejecución y Evaluación. Estas fases se definen en función de realizar las actividades descritas como parte de los componentes del modelo y el proceso de diagnóstico que proponen los modelos y guías de referencias analizados, algunas de ellas están definidas para contextualizar los elementos del modelo que es necesario adecuar o definir para cada problema en particular. Las actividades de la fase de configuración solo requiere realizarlas la primera vez que se aplica la metodología en una organización y si es necesario introducir cambios.


Figura 2. Fases para la implementación del modelo.

Configuración: en esta fase se ajustan los componentes del modelo a las características de las organizaciones, se capturan los datos primarios de clasificación de la organización. Se identifican los FCE, se asumen los que proponen los autores de esta investigación u otros que se encuentran en la bibliografía. En el caso que la organización decida utilizar FCE diferentes debe reformular los indicadores y las métricas, ejecutando las actividades del componente Evaluación del impacto de los FCE.

Planificación y organización del diagnóstico: a partir de la guía de configuración se planifican y aseguran las actividades de recopilación de información. Se despliegan las herramientas que automatizan la captura y procesamiento de los datos.

Ejecución del diagnóstico: se ejecutan las actividades de recopilación y procesamiento de la información. Se ejecutan las actividades Evaluar los indicadores y Calcular la métrica del impacto de los FCE del componente de Evaluación del impacto de los FCE y las actividades del componente de pronóstico de la mejora basado en experiencias.

Evaluación del impacto del modelo: se analizan los resultados y se prepara el informe a presentar a los directivos. Se debe recodar a los directivos la importancia de retroalimentar la base de casos. Estas actividades están en correspondencia con el componente evaluación de la organización. De los resultados e impactos de la implementación del modelo se analizan las lecciones aprendidas y las oportunidades de mejora para incorporarlas o no al modelo y al proceso de implementación. Como parte de esta fase cada semestre se debe monitorear a partir de la implementación de la guía de revisión sistemática a la bibliografía y del análisis de tendencia de los resultados almacenados en la base de casos.

A partir de la experiencia del uso del modelo y de los criterios de las organizaciones que participaron en la validación, se proponen tres variantes de implementación del modelo:

• Implementar el modelo sin el componente de pronóstico de la mejora de procesos.
• Implementar solamente el componente de evaluación del impacto de los factores críticos de éxito.
• Implementar el modelo con otros factores críticos de éxito.

La primera variante es aplicable cuando las organizaciones no disponen de casos anteriores y no pueden hacer uso del sistema de RBC. En este caso las recomendaciones se realizarían basadas en los indicadores y las métricas y no se tendría en cuenta las experiencias anteriores.

La segunda es poco recomendada por los expertos, pues aunque obtiene las salidas más importantes del modelo no ejecuta la evaluación de la organización y esta es indispensable para la toma de decisiones, en este caso se recomienda que la organización establezca como mínimo la actividad de presentación de los resultados a los directivos.

La tercera variante establece que el modelo se puede implementar con otros factores críticos de éxito y no con los que proponen los autores del modelo [5]. Esta variante implica que las organizaciones deben desarrollar un proceso para la reformulación de los indicadores y las métricas, lo que es complejo y engorroso [8].

 

RESULTADOS

Para la validación experimental se parte de la formulación de la siguiente hipótesis: Si se emplea un modelo cuyos componentes valoren la organización al iniciar la mejora de procesos de software, basado en las experiencias de las organizaciones y el conocimiento de los expertos, con el uso de indicadores y métricas se contribuirá a disminuir el impacto negativo de los factores críticos de éxito.

La hipótesis enunciada es bivariada con una variable dependiente y una independiente, donde el Efecto de la implementación del modelo es la variable independiente y el Nivel de impacto de los factores críticos de éxito es la variable dependiente.

Los autores consideraron adecuado desarrollar un cuasiexperimento, pues en estos se manipulan deliberadamente al menos una variable independiente para observar su efecto con una o más variables dependientes. Difiere de los experimentos en el grado de seguridad o confiabilidad que pueda tenerse sobre la equivalencia inicial de los grupos. Para el cuasiexperimento accedieron a participar 14 centros productivos con estructuras organizativas y una composición de la fuerza de trabajo similar, pero sí con diferencias significativas en el campo de aplicación de los sistemas informáticos que desarrollan.

En el diseño del cuasiexperimento se consideró necesario utilizar:

 Un grupo de control, pues es adecuado para el análisis de causalidad entre las variables independiente (s) y dependiente (s).
 Dos preprueba: pues permiten evaluar qué tan adecuada fue la asignación a los grupos. Permite analizar el estado inicial.
 Dos postprueba: pues indica si hubo o no efecto en la manipulación.

Por último, teniendo en cuanta que la MPS tarda muchos meses incluso años en ejecutarse [8] y que los factores críticos de éxito tardan en manifestarse, se utilizó series cronológicas múltiples, pues este cuasiexperimento permite analizar efectos en el mediano o largo plazo, cuando se tienen bases para suponer que la influencia de la variable independiente sobre la dependiente, como es el caso, tarda en manifestarse.

Para comprobar la heterogeneidad de las dos muestras antes y después de aplicado el estímulo se usó el Test de U de Mann-Whitney, recomendado para comprobar dos muestras independientes no paramétricas.

El cuasiexperimento fue ejecutado por el equipo de diagnóstico del Centro Nacional de Calidad de Software de Cuba (Calisoft) para evitar que los investigadores influyeran en los resultados.

Para medir el efecto de la variable independiente sobre la variable dependiente se aplicó el modelo de forma simultánea en todos los centros, a partir de los resultados se analizan las relaciones entre las barreras identificadas de la implementación del modelo con los riesgos identificados en los centros y las buenas prácticas con las acciones de mitigación de riesgo, respectivamente. Pasados cinco días, a los centros del grupo experimental se le presentan los resultados de la aplicación del modelo, mostrando las barreras y las buenas prácticas recomendadas, de esta manera quedó aplicado el estímulo a los centros del grupo experimental.

Después de 15 días se analizaron los planes de gestión de riesgos del grupo experimental, existiendo correspondencia entre estos y los resultados recomendados de la aplicación del modelo. A los 3 meses se aplicaron entrevistas a profundidad a las organizaciones que forman los dos grupos para analizar el impacto negativo de los factores críticos de éxito en la materialización de los riesgos. En las Figuras 3 y 4 se representa el diseño del cuasiexperimento.


Figura 3. Representación gráfica del cuasi-experimento en el tiempo.


Figura 4. Representación gráfica del cuasi-experimento según las pruebas.

A partir de los resultados obtenidos en las dos prepuebas y las dos postpruebas se realiza el análisis del efecto de la variable dependiente sobre la independiente:

Preprueba 1: al 100 % de los centros de los grupos le impacta como barrera el FCE: Experiencia del personal, y como riesgo: Efectividad del programa de reconocimiento y remuneración. En ambos grupos, a cuatro centros, que representan el 57,14%, le impacta el factor Comunicación como riesgo y Disponibilidad de recursos en dos, que es el 28,57%. El promedio de las variables ubicadas en el nivel intermedio (0,4 a 0,6) y el nivel bajo (menos de 0,4) es de 9,4 en el grupo de control y 9 en el grupo experimental y el promedio de buenas prácticas recomendadas es de 13,9 y 13, respectivamente. En cuanto a las métricas de garantía de éxito en el grupo de control posee dos centros evaluados de Adecuado, cuatro de Poco Adecuado y uno de No Adecuado, mientras que el grupo experimental tiene un centro evaluado de Adecuado, cinco de Poco Adecuado y uno de No Adecuado. Por último, al aplicar el test de U de Mann-Whitney a los datos de las variables se obtiene que en todos los casos la significación de este test es mayor que 0,05, por lo que se concluye que los grupos no difieren cualitativamente.

Preprueba 2: en esta prueba los resultados arrojan que en ambos grupos para la dimensión, Relación entre los riesgos definidos para el proceso de mejora y las barreras identificadas los valores oscilan entre el 0,10 y el 0,12 y para la Relación entre las acciones de mitigación de los riesgos y las buenas prácticas identificadas están entre 0,6 y 0,85. Igual que en la prueba anterior se concluye que no hay diferencias significativas, pues el nivel de significación aplicando el test de U de Mann-Whitney es de 0,710 y 0,805, respectivamente. Además refleja que el plan de mitigación y contingencia de riesgos de las organizaciones no está considerando los riesgos en función de las condiciones que poseen para la MPS.

Postprueba 1: las recomendaciones fueron presentadas a los centros del grupo experimental, los que incorporaron al plan de mitigación y contingencia de riesgos del proceso de mejora. Elevando las razones consideradas en el cuasi-experimento a un valor de 1 para los centros del grupo experimental.

Postprueba 2: después de implementado un paquete de mejoras en todos los centros, el análisis arrojó que en el grupo de control la variable Relación entre el número de riesgos que se materializaron en la mejora de procesos con las barreras identificadas, los valores oscilaron entre 0,75 y 0,83, mientras que en el grupo experimental fue entre 0,11 y 0,23. Al aplicar el test de U de Mann-Whitney a los datos de la variable se obtiene que es altamente significativo: 0,001. El rango medio en el grupo experimental es superior al control (11>4), lo que refleja que en el ejercicio final de la prueba los efectos del estímulo son significativos.

Del cuasiexperimento se concluye que existen dos contribuciones importantes en la aplicación del modelo en estas organizaciones, uno relativo a que evalúa la organización integralmente aportando al análisis de los riesgos información objetiva y tangible a partir de estar fundamentada en datos y las condiciones de la organización y prepara a la organización para enfrentar el impacto negativo de los FCE, concentrando sus esfuerzos en aquellos que más le afectan. La segunda contribución es a disminuir el impacto de los FCE en las organizaciones a partir de disminuir los riesgos que se materializan durante la MPS.

 

CONCLUSIONES

El proceso de diagnóstico de los modelos de referencia para la mejora de procesos de software se centra en identificar el estado de los procesos que realiza y no en caracterizar el estado de la organización integralmente teniendo en cuenta los factores críticos de éxito, lo que constituye un elemento importante a considerar en la decisión de iniciar un programa de mejora de procesos de software.

El modelo Si.MPS.Cu que se propone usa indicadores, métricas y un sistema de razonamiento basado en casos para valorar una organización al iniciar la mejora de procesos, basado en el análisis de los FCE que identifica las barreras, los riesgos y recomienda las buenas prácticas.

La metodología brinda el marco para la contextualización del modelo mediante la implementación de sus fases y actividades.

Los resultados de la validación del modelo arrojan que ayuda a disminuir el impacto negativo de los factores críticos de éxito.

Estos resultados reafirman la necesidad de complementar el diagnóstico con el análisis integral de las organizaciones, en tanto crean las bases para impulsar la mejora de proceso de software.

 

AGRADECIMIENTOS

El colectivo de autores agradece a los expertos e instituciones que apoyaron la investigación e hicieron posible mostrar los resultados que se exponen.

 

REFERENCIAS

[1] T. Nguyen, H. Gou, R. Naguib and N. Wickramasinghe. "A view of 21st century healthcare industry and software quality improvement practices". Int. Journak Netw. Virtual Organ. Vol. 9, Issue 2, pp. 155-168. 2011. ISSN: 1470-9503.

[2] P. Clarke and R. O'Connor. "Harnessing ISO/IEC 12207 to Examine the Extent of SPI Activity in an Organization". Communications in Computer and Information Science. Vol. 99, pp. 25-36. 2010. ISSN: 1865-0929 (Print). ISSN: 1865-0957 (Online).

[3] E.Y Li, H.-G. Chen and T.C. Du. "Software Process Management in Taiwan's top 1000 Companies: A Longitudinal Analysis". 11th Annual Conference of Asia Pacific Decision Sciences Institute. Total Quality Management: Hong Kong. 2011.

[4] P.L. Bannerman. "Barriers to Project Performance". 46th Hawaii International Conference on System Sciences. IEEE Computer Society. Maui, Hawaii. 2013.

[5] Y. Trujillo Casañola, A. Febles Estrada, G. León Rodríguez y Y. Betancourt Rodríguez. "La gestión de la información y los factores críticos de éxito en la mejora de procesos de software". Revista Científica del Instituto de información y tecnología. Vol. 44 N° 3, pp. 27-33. 2013. ISSN: 1606-1945

[6] T. Kojima, T. Hasegawa, M. Misumi and T. Nakamura. "Risk analysis of software process measurements". Software Quality Control. Vol. 16, Issue 3, pp. 361-376. 2008. ISSN: 0963-9314.

[7] A.S. Guceglioglu and O. Demirors. "The Application of a New Process Quality Measurement Model for Software Process Improvement Initiatives". Proceedings of the 2011 11th International Conference on Quality Software. IEEE Computer Society. Madrid, España. 2011.

[8] Y. Trujillo Casañola, A. Febles Estrada, G. León Rodríguez, Y. Betancourt Rodríguez, O. Enamorado y Y. Sánchez. "Diagnóstico al iniciar la mejora de proceso de software". Aceptada, Revista Ingeniería Industrial. 2014. ISSN: 1815-5936.

[9] I. Nonaka and G.V. Krogh. "Perspective-Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory". Organization Science. Vol. 20, Issue 3, pp. 635-652. 2009. ISSN: 1526-5455.

[10] M.L. Espinosa, N. Martínez, Z.G. Valdivia and R. Bello Pérez. "Concept Maps Combined with Case-Based Reasoning in Order to Elaborate Intelligent Teaching/Learning Systems". Actas del Seventh International Conference Intelligent Systems Design and Applications, ISDA. Río de Janeiro, Brasil. 2007.


Recibido 2 de septiembre de 2013, aceptado 23 de abril de 2014


Artículos Relacionados

# Título Ver
1
Indicadores estáticos normalizados para estabilidad de tensión basados en reservas de potencia reactiva y en márgenes de cargabilidad (2015)
Jorge W. González, Hugo A. Cardona, Idi A. Isaac, Gabriel J. López
HTML | PDF
2
Estudio comparativo basado en métricas para diferentes arquitecturas de navegación reactiva (2016)
Felipe Correa, José Gallardo, Nelson Muñoz, Ricardo Pérez
HTML | PDF
3
Metodología para la comparación de sistemas de planificación de recursos empresariales para servicios logísticos portuarios (2017)
Paola A. Sánchez-Sánchez, José Rafael García-González, Luis Eduardo Ortiz-Ospino
PDF
4
Indicadores urbanos y su influencia en el desarrollo sostenible urbano de Huancayo metropolitano - Perú* (2019)
Cesar Fortunato Martínez Vitor
PDF


Otros Artículos

# Título Ver
1
Autoignicion 3-D en depositos de lodos provenientes de tratamientos de aguas residuales (2008)
Nelson Moraga B., Carlos Zambra S.
HTML | PDF
2
Formación de roles y buenas prácticas en el trabajo por la calidad de un ingeniero informático (2011)
Yucely López Trujillo, Margarita André Ampuero, Ana Lilian Infante Abreu
HTML | PDF
3
Desarrollo de una arquitectura de software para el robot móvil Lázaro (2018)
Jesús M. García, Ángel E. Gil, Ender A. Sánchez
PDF

Desarrollado por: Cristian Díaz Fonseca - cfonseca@matiasluke.cl