IMPLEMENTACIÓN DEL MODELO INTEGRAL COLABORATIVO (MDSIC) COMO FUENTE DE INNOVACIÓN PARA EL DESARROLLO ÁGIL DE SOFTWARE EN LAS EMPRESAS DE LA ZONA CENTRO - OCCIDENTE EN MÉXICO

IMPLEMENTACIÓN DEL MODELO INTEGRAL COLABORATIVO (MDSIC) COMO FUENTE DE INNOVACIÓN PARA EL DESARROLLO ÁGIL DE SOFTWARE EN LAS EMPRESAS DE LA ZONA CENTRO - OCCIDENTE EN MÉXICO

José Luis Cendejas Valdéz (CV)

Volver al índice

Capitulo IV. Desarrollo de la propuesta del Modelo para el Desarrollo de Software Integral Colaborativo – MDSIC.

En este capítulo se presenta el análisis de los resultados obtenidos sobre la investigación. Esta información sirvió como fundamento para el diseño y usabilidad del modelo propuesto (MDSIC). Por ello dicho capítulo está organizado en cinco secciones que contemplan los temas más sobresalientes de los resultados obtenidos de la investigación las cuales son:

  • Primera sección, metodologías más utilizadas por las empresas entrevistadas y  del uso de metodologías con indicadores de calidad (matriz de jerarquización).
  • Segunda sección se describe de manera general el análisis preliminar de los datos obtenidos a través de la encuesta aplicada a empresas pertenecientes al sector de la industria del software de la zona centro – occidente de México, la cual se le denomino “Análisis de empresas desarrolladoras de software en la zona Centro – Occidente de México” y de las entrevistas generadas a empresas que desarrollan software en la zona centro – occidente del país. Además, de presentar la fiabilidad de los resultados de la encuesta por medio del estudio 1) “Alfa de Cronbach” y a partir de las variables obtenidas en dicho análisis de fiabilidad se generó el estudio denominado 2) Correlación de “Pearson”; donde se indagan las correlaciones directas entre las variables, lo que determina las áreas más débiles que tienen las empresas desarrolladoras de software de la zona centro – occidente de nuestro país y en las que se debe de poner mayor interés para generar software de calidad a través del modelo propuesto. Y los resultados de la encuesta.
  • Tercera sección, se propone el modelo generado de esta investigación para desarrollar software de calidad además de integrar las cinco primeras áreas del conocimiento del modelo para la administración de proyectos del Project Management Institute (PMI), respaldando así su estructura general y los puntos a considerar en el proceso esencial en el desarrollo de software, además de generar una base de conocimiento por expertos a través del social bussines.
  • Cuarta sección se expone el software que acompaña al MDSIC.
  • Quinta sección, se exponen las situaciones generadas de la aplicación del MDSIC en empresas  de nuestro país; cuasi - experimento.

4.1 Análisis de los datos obtenidos de las entrevistas y de la encuesta

Con base en el formato propuesto en la tabla 3.13 del capítulo no. 3 acerca de la obtención de información denominada “Registro de funcionalidades de metodologías y modelos (matriz de jerarquización), que sirve para realizar una comparativa además de recopilar información de las distintas metodologías que se encuentran en la actualidad y que sirven para desarrollar software. Se generó el siguiente concentrado emanado de las distintas entrevistas realizadas a la MTI Karina Coria Vargas (Caja popular Morelia Valladolid) y MTI Manuel Gutiérrez Pineda - Scio Consulting International
Estas personas cuentan con más de diez años en el área del desarrollo de software en empresas especializadas en desarrollar software a la medida utilizando diferentes metodologías para su desarrollo, los cuales concluyeron con base en los indicadores de impacto, costo y beneficio como se han comportado las metodologías mencionadas en diferentes proyectos, como se muestra en la tabla 4.1 Se adjuntan formatos de entrevistas en el “Anexo A”.
Para el desarrollo del modelo se tomaron en consideración las metodologías, que son consideradas por las empresas desarrolladoras de software y que fueron entrevistadas, en el “Anexo C” se presenta de manera gráfica el funcionamiento que tiene cada una de ellas.

4.2 Análisis de los resultados

4.2.1 Encuesta

A partir de la base de datos generada con la información obtenida mediante la encuesta “Análisis de empresas desarrolladoras de software en la zona centro – occidente de México”, el análisis preliminar de datos consistió en términos generales, en las tareas de depuración de datos, caracterización y exploración de la naturaleza de las variables originales, análisis de la fiabilidad y validez de las escalas utilizadas para la generación de las nuevas variables, y análisis de la correlación estadística entre las variables del modelo.

Las variables dependientes con las que se trabajó en la encuesta pudieron ser valoradas a través de una escala tipo Likert, las cuales cuentan con la bondad de ser tratadas como variables cualitativas dicotómicas las cuales pueden tomar dos valores posibles como sí y no, hombre y mujer o son politómicas cuando pueden adquirir tres o más valores (Morgan, 2004; Miquel, 1997). Respecto al conjunto de variables independientes, se les realizó un análisis descriptivo y exploratorio, con el fin no sólo de tener un referente de los valores medios, máximos y mínimos de ocurrencias de las respuestas dadas por los participantes en el estudio, sino además, para conocer la naturaleza de su distribución. La encuesta fue respondida por 52 empresas pertenecientes a diferentes estados de la zona centro – occidente. Las gráficas con los resultados de las preguntas de la encuesta se pueden observar en la tabla 4.2

4.2.2 Alfa de Cronbach

Para la valoración de la fiabilidad de las escalas utilizadas en las preguntas, se utilizó el software SPSS de IBM el cual permite generar diferentes estudios estadísticos, antes de iniciar con la aplicación de análisis de correlación, se realizó un análisis de fiabilidad1 aplicando la prueba de Alfa de Cronbach, además de utilizar Excel. Se consideró como valor de aceptación 2 de la fiabilidad 0.812 (Hair, 2005; Pardo, 2005:437-39). Como resultado de este análisis, en promedio los valores obtenidos superan el valor de 0.8 del test de fiabilidad, como se muestra en la tabla 4.3. Con base en esta prueba, se identificó que  el instrumento (encuesta) diseñado y aplicado a 52 empresas que desarrollan software en la zona centro – occidente de nuestro país, es validó y nos permite identificar diferentes elementos que se deben de considerar en el desarrollo de software en la actualidad.
El valor mínimo aceptable para el coeficiente alfa de Cronbach es 0,70; por debajo de ese valor la consistencia interna de la escala utilizada es baja. Por su parte, el valor máximo esperado es 0,90; por encima de este valor se considera que hay redundancia o duplicación. Varios ítems están midiendo exactamente el mismo elemento de una pregunta; por lo tanto, los items redundantes deben eliminarse. Usualmente, se prefieren valores de alfa entre 0,80 y 0,90 (Oviedo et al., 2005). En general, se observa en el estudio realizado, ver “Anexo D”, que las cargas factoriales de cada una de las variables obtenidas en el estudio superan el valor aceptable de 0,7. Respecto al promedio del Alfa de Cronbach, cada una de las preguntas del instrumento es superior a ese factor con lo cual se asegura que se cuenta con los mínimos de fiabilidad en la construcción de nuevas variables.

4.2.3 Estudio de correlación bivariada de Pearson

El procedimiento de correlaciones bivariadas permite medir el grado de dependencia existente entre dos o más variables mediante la cuantificación por los denominados coeficientes de correlación lineal de Pearson, de Spearman y la Tau-b de Kendall con sus respectivos niveles de significación. Este coeficiente de correlación de Pearson es una medida de asociación lineal.
Es el más conocido y utilizado de todos. Por lo que dos variables pueden estar perfectamente relacionadas, pero si la relación no es lineal, el coeficiente de correlación de Pearson no será un estadístico adecuado para medir su grado de asociación. Pearson es la medida de la asociación lineal entre dos variables. Los valores del coeficiente de correlación varían entre -1 a 1. El signo del coeficiente indica la dirección de la relación y su valor absoluto indica la fuerza o grado. Los valores mayores indican que la relación es más estrecha y un valor de 0 indica que no existe una relación lineal. Dado dos variables, la correlación permite hacer estimaciones del valor de una de ellas conociendo el valor de la otra variable. Los coeficientes de correlación son medidas que indican la situación relativa de los sucesos respecto a las dos variables, es decir, son la expresión numérica que nos indica el grado de relación existente entre las 2 variables y en qué medida se relacionan. Son números que varían entre los límites +1 y -1 (Leech, 2005; Morgan, 2004; Kotrlik, 2003). En la tabla 4.4 se observa la descripción de la escala de los coeficientes de correlación.
Para averiguar la existencia de relaciones estadísticamente significativas entre las diferentes variables del estudio, se realizó un análisis de correlación el cual fue generado a través del software SPSS de IBM. El resumen de las correlaciones más importantes se muestran de la tabla 4.5 a la 4.15 y se enumeran con números romanos, el estudio completo generado se muestra en el “Anexo E” de este documento.

4.3 Modelo para el desarrollo de software integral colaborativo - MDSIC.

El modelo para el desarrollo de software propuesto tiene como objetivo presentar una serie de pasos a través de cinco niveles que faciliten la administración de proyectos de software en pequeñas-medianas empresas y que requieran desarrollar software de una manera ágil. Este modelo está conformado por cinco niveles que son:

  • Nivel 0: Detección del Problema.
  • Nivel 1: Análisis y Diseño.
  • Nivel 2: Desarrollo.
  • Nivel 3: Implementación.
  • Nivel 4: Indicadores de calidad.

Además de contemplar los primeros cinco niveles de los grupos de procesos que contempla el Project Management Institute (PMI):

  • Integración de la administración del proyecto.
  • Alcance.
  • Tiempo.
  • Costo.
  • Calidad.

Los cuales permiten producir un entregable (SF) de calidad.
Dicho modelo se puede leer de una manera sencilla ya que cuenta con la generalidad de poder entender su funcionamiento desde la parte superior izquierda a la inferior derecha y de arriba hacia abajo. Además de estar conformado por niveles, a continuación se describe el funcionamiento de los niveles:
1.- Nivel 0. El primer nivel denominado “0” permite iniciar con la identificación del problema, este proceso consiste en la identificación de una problemática, la cual contempla que se lleve a cabo de 3 a 10 reuniones como máximo en donde se busca conocer las necesidades específicas del proyecto y el alcance que se pretende. Generando un análisis de viabilidad y fiabilidad para que el cliente conozca las ventajas y desventajas de la generación del software además este tipo de estudios permite disminuir tiempos, costos y generar beneficios en el producto.

En dichas reuniones participará un equipo multidisciplinario que estará conformado por las personas que solicitan dicho software (cliente) y un equipo conformado por expertos (skateholders) de cada una de las áreas que dominan los procesos del modelo y las áreas involucradas de la organización así como del proyecto que ayudaran a identificar las necesidades que se tienen en dicho proyecto. Después de esto los documentos generados de todos los subprocesos que conforman los niveles se enviaran a una base denominada “memoria de actividad” la cual almacenara todos los datos de la información generada del proyecto a desarrollar.

2.- Nivel 1. El segundo nivel denominado “1” hace referencia al análisis y diseño ya que son dos de las etapas más importantes para muchas de las empresas encuestadas que desarrollan software; pensando en que este modelo permita un desarrollo ágil de software a las organizaciones se contempla unir las etapas de análisis y diseño para la generación de desarrollos agiles. Además de contemplar uno de los principios básicos de la planeación estratégica como lo es el alinear las Tecnologías de la Información con los objetivos de la organización, lo que permite llevar a cabo un análisis adecuado de los requerimientos y especificaciones del proyecto a desarrollar (SF), el cual se verá plasmado en un Work Breakdown Structure (WBS). Esto es la base para la generación de la etapa de diseño de las interfaces graficas del usuario (SF) y la selección del lenguaje de programación más óptimo en el cual se realizará el desarrollo del producto.

Es importante medir y comparar los resultados generados hasta este punto de esta etapa, por ello se propone una evaluación a través de un “plan de pruebas”, que permite comparar los avances contra los resultados generados del grupo multidisciplinario. Después de esta comparativa de los resultados generados hasta este punto con toda la información generada anteriormente se propone generar un prototipo (Beta testing) con el cual el cliente interactúe con el producto y determine su satisfacción con el producto y exponga los puntos con los cuales no está de acuerdo y que se hayan generado en los requerimientos y especificaciones. El uso de prototipos es una forma práctica y útil para conocer la satisfacción del cliente y generar una interacción con el producto para conocer las fortalezas, oportunidades, debilidades y amenazas que se pueden tener con base en el proyecto.

3.- Nivel 2. El tercer nivel denominado “2” hace referencia al desarrollo de la aplicación en la cual la primer etapa consiste en dividir el desarrollo del sistema a través de módulos, lo cual permitirá su desarrollo por partes, esto facilita realizar la evaluación de los módulos desarrollados e ir realizando las pruebas correspondientes. La siguiente etapa habla de la evaluación de los requerimientos en conjunto con los módulos desarrollados, con base en dicha evaluación se determinará la aprobación de los módulos para pasar al proceso del nivel 3 relacionado con la implementación.

4.- Nivel 3. El cuarto nivel denominado “3” hace referencia a la implementación del sistema. Como primer etapa se comienza con la implementación del sistema y se realizan las diferentes pruebas relacionadas con el funcionamiento del sistema, como siguiente etapa se presenta una pre - entrega del sistema para que el usuario interactúe con la aplicación desarrollada y se corrigen errores. Por último se procede con la entrega de la documentación y los procesos post-desarrollo.
5.- Nivel 4. El quinto nivel denominado “4” hace referencia a los indicadores de calidad que hablan de once indicadores que se dividen en tres grupos y permiten medir la calidad del software Pressman & Perry (2006). A continuación se describen cada uno de ellos y en qué consisten, como se muestra en la tabla 4.16
4.3.1 Integración del PMI en el modelo para el desarrollo de software.
A continuación se describen las etapas del PMI que integran el modelo para el desarrollo de software. Dichas etapas se acoplan de manera significativa a los cinco niveles que conforman  el modelo propuesto, teniendo como objetivo el aseguramiento de la calidad del producto final (SF). A continuación se describe el funcionamiento de las etapas a través de sus procesos de funcionamiento en los diferentes niveles que conforman al modelo, como se muestra en la figura 4.3.

1.- PMI 1. Esta etapa contempla identificar al patrocinador principal del proyecto, quien será el que brinde la información necesaria para identificar la problemática y conocer los alcances y límites del proyecto antes de iniciar con la planeación del mismo. En esta etapa de iniciación el PMI contempla que se genere una serie de premisas y actividades que  permitan iniciar formalmente con el arranque además de aplicar recursos a las diferentes actividades que conforman al proyecto y generar un entendimiento común entre los interesados. Estas actividades son las siguientes:

  • Proceso de iniciación
  • Análisis de viabilidad.
  • Análisis de fiabilidad.
  • Justificación.
  • Acta de constitución del proyecto.
  • Enunciado del trabajo del proyecto(alcance preliminar del proyecto).
  • Expectativas de skateholders.
  • Factores ambientales de la empresa-proyecto.
  • Activos de la organización en los procesos.

2.- PMI 2. Se optó que la etapa del modelo del PMI 2, la cual hace referencia a los procesos de planificación y de costos brinden soporte a la etapa 1 del modelo (análisis y diseño). Esta etapa pretende generar una planificación útil que sirva como guía de las diferentes actividades a desarrollar durante el proceso y que ayude a la medición de los avances de dichas actividades. En esta etapa de planificación el PMI contempla que se genere una serie de premisas y actividades que  permitan iniciar formalmente con la planificación de un proyecto además de aplicar recursos a las diferentes actividades que conforman al proyecto y generar un entendimiento común entre los interesados. Estas actividades son las siguientes:

  • Proceso de planificación
  • Tiempo
  • Levantamiento de requisitos.
  • Definición del alcance y actividades.
  • Planificación del alcance y secuencia de actividades – WBS (Work Breakdown Structure).
  • Metodología.
  • Verificación del alcance.
  • Control del alcance.
  • Análisis y respuesta de riesgos.
  • Costos
  • Estimación de costos.
  • Presupuesto del proyecto.
  • Asignación del recurso.

3.- PMI 3. Se optó que la etapa del modelo del PMI 3, la cual hace referencia a los procesos de calidad brinden soporte a los procesos del nivel 2 y 3 del modelo, los cuales hacen referencia al desarrollo e implementación del software. Esta etapa pretende generar una ejecución , supervisión y control en las diferentes actividades a desarrollar durante el proceso ayudando así a la medición de los avances de dichas actividades y de su calidad, estas actividades son las siguientes:

  • Calidad
  • Evaluación de la calidad.
  • Aseguramiento de la calidad.

4.- PMI 4. Se optó que la etapa del modelo del PMI 4, la cual hace referencia a los procesos de cierre brinden soporte al proceso del nivel 4 del modelo, los cuales hacen referencia a los indicadores de calidad del software generado a través del modelo.

  • Proceso de cierre
  • Procedimiento de cierre administrativo.
  • Procedimiento de cierre del contrato.
  • Producto, servicio o resultado final.
  • Activos de los procesos de la organización (actualizados).
  • Contratos concluidos.
  • Cierre del proyecto.
  • Cierre del contrato.
  • Documentación.

4.3.2 Integración del social business en el modelo para el desarrollo de software integral colaborativo.

Los seres humanos por naturaleza siempre hemos sido sociales. El incremento de las tecnologías sociales han permitido a las personas saciar su deseo innato de estar más interconectadas. La posibilidad de gestionar la información de las redes sociales recae sobre los usuarios. La oleada social se ha afianzado firmemente en el día a día tanto de los países desarrollados como de los que están en vías de desarrollo. Una mejor comunicación y colaboración mediante las tecnologías sociales ha aumentado la productividad de los trabajadores que necesitan estar interconectados con los demás.
Por ello el MDSIC ha incorporado al social bussines como elemento generador de una base de conocimiento, la cual obtendrá comentarios y opiniones de gente experta en el desarrollo de software a la medida y de los usuarios que tomen como base al MDSIC como herramienta para el desarrollo del software a través de los comentarios generados de las redes sociales que se encuentran incorporadas en el software MDSIC 1.0. A continuación se describe el proceso general de los pasos que se deben de seguir para utilizar el modelo para el desarrollo de software integral colaborativo, el cual se muestra en la figura 4.1

4.4 Software del modelo de desarrollo de software integral colaborativo – MDSIC v1.0.

Una parte esencial en el MDSIC es la parte denominada “memoria de actividad”, la cual se ve reflejada en un sistema que se encuentra en internet, basado en la tecnología denominada “Responsive web design” o “Diseño web adaptable” la cual es una forma de programación que permite a cualquier sitio o sistema basado en web adaptarse al medio a través de cualquier dispositivo por el cual un usuario este accediendo al mismo. Los tamaños de pantalla cambian según el medio con el que se accede. El software que acompaña al MDSIC, tiene como objetivo capturar y almacenar la información que se va generando de los proyectos desarrollados que toman como base el MDSIC.

Además de generar una base de conocimiento generada por expertos que busca generar mejoras en los procesos de desarrollo de software a la medida y de los diferentes niveles que propone el MDSIC. MDSIC 1.0 permite el trabajo colaborativo a partir de su naturaleza multiusuario, la cual se refleja en el registro de diferentes usuarios que pueden registrarse en el sistema, como se muestra en la figura 4.2 y ser invitados a diferentes proyectos de desarrollo de software, dependiendo de su perfil.

Después de estar registrado en el software MDSIC, el usuario puede ingresar al sistema para poder participar en proyectos de desarrollo de software, como se muestra en la figura 4.3
La pantalla principal del software muestra el modelo y la descripción grafica del mismo, además de que en la parte inferior izquierda presenta las opciones principales del sistema, como son:

  • Abrir (proyecto existente)
  • Nuevo (crear nuevo proyecto)
  • Unirse (a un proyecto en el cual se haya realizado una invitación)
  • Cuenta (cambiar de contraseña de la cuenta)
  • Ayuda (relacionada con las principales opciones y campos del software MDSIC)

En la parte superior derecha se presenta la opción de salir y en la inferior el icono de facebook para contribuir con aportaciones a través de diferentes redes sociales, como se muestra en la figura 4.4
Existen diferentes niveles y roles, como se muestra en la figura 4.5 con los que los usuarios pueden participar en el software MDSIC 1.0, como:

  • Administrador de proyectos
  • Cliente
  • Analista
  • Diseñador
  • Desarrollador
  • QA (aseguramiento de la calidad)

El rol de administrador de proyectos es el nivel más alto, ya que es el encargado de crear, administrar y dar seguimiento a todo el proyecto desde el nivel 0 hasta el nivel 4 propuestos por el MDSIC. Además, de que será el responsable de capturar la información de las minutas que se presentan en dichos niveles, como se muestra en la figura 4.6. La creación de los demás roles dependerán, de su necesidad de creación y están inmersos en el proceso del desarrollo del proyecto. El analista y diseñador participan específicamente en el nivel 1 del MDSIC, el desarrollador en el nivel 2 y el QA solo participa en el nivel 3, 4 y 5 para aprobar los módulos y elementos que se entregarán al cliente.

1.- La opción de “Identificación del problema” la cual representa el nivel cero en el modelo, el administrador tendrá la opción de poder dar de alta varias minutas que registren la información generada a través de las diferentes reuniones llevadas a cabo con el cliente y con el equipo multidisciplinario, dichas minutas están basadas en las plantillas que presenta MOPROSOFT. En este nivel el administrador del proyecto encontrará datos básicos y necesarios para la identificación del problema a resolver, como se muestra en la figura 4.7
El administrador del proyecto tendrá que capturar el lugar y la fecha en que fue llevada a cabo dicha reunión, el objetivo, los participantes, los puntos tratados, los acuerdos obtenidos, el seguimiento de los compromisos pendientes como los asuntos pendientes por resolver. Los participantes en el proyecto deberán de firmar cada minuta generada siempre y cuando hayan intervenido en su realización y el administrador del proyecto haya solicitado su firma, la firma se representa a través de un código QR que es generado por el sistema para cada uno de los participantes, esto permite dar validez a la información generada por todos los participantes que intervienen en las reuniones, como se muestra en la figura 4.8

2.- El nivel uno denominado “Diseño”, consta de dos opciones principales, como se muestra en la figura 4.9, las cuales son:

  • Minuta de especificación de requerimientos
  • Reporte del plan de pruebas y prototipo

En la minuta de especificación de requerimientos el administrador del proyecto capturará el campo de introducción, propósito, alcance, alcance del proyecto, arquitectura y funcionamiento así como la arquitectura general del software a desarrollar. Esta minuta va acompañada por un documento que representa la planeación, dicho documento puede ser generado desde cualquier aplicación (administradora de proyectos) en formato “pdf” que permita generar la planeación del proyecto en mención, esto permitirá que los miembros que participan en dicho proyecto conozcan las diferentes actividades además de firmar los costos, los tiempos y las fechas de entrega que se generan para cada actividad así como en las minutas en que ellos participan como se muestra en la figura 4.10 y 4.11.

1 A través del análisis de fiabilidad se busca asegurar que el valor que se utiliza en la escala esté libre de error aleatorio, es decir, que el valor generado por la escala sea consistente y estable.

2 Valor válido para investigaciones de tipo exploratorio.