Abstract— Matching the software industry requirements with the academy is a significant challenge that must be accomplished for the benefit of both sectors. In Mexico, the small and medium size companies (SMEs) are key for the software development, in such a way that having highly capable personal in the development of high quality software products is a fundamental piece to warranty their permanency in the market. In this context, the Mexican organizations for the accreditation to ensure quality in Software Engineering are: for the SMEs software industry, the Moprosoft norm; and for the undergraduate education institutions in Computer Science and Informatics, the CONAIC. In this document a comparative analysis is made to understand the coverage of the academic curricula in higher education, regarding the software industry requirements; based on what these government norms establish for their accreditation.
Keywords— Software Engineering, Computer Science and Informatics curricula, software industry.
I. INTRODUCCIÓN
N décadas recientes la industria del software se ha venido fortaleciendo y hoy en día representa una de las actividades más importantes para la generación de empleo [1, 2, 3]. Por otro lado, las pequeñas y medianas empresas (pymes), se han convertido en una pieza clave en la industria del desarrollo de software [4].
El término pyme se utiliza para clasificar a las empresas de acuerdo al número de sus empleados, sus ventas y sus activos.
Una categorización genérica, que aplica para México, es la basada en su número de empleados: pequeña empresa entre 10 y 50 empleados y mediana empresa entre 51 y 100 empleados, de tal forma que una pyme es, en términos generales, una empresa con no más de 100 empleados. En México, el 99%
de las empresas son pyme, generando el 72% del empleo y el 52% del PIB (producto Interno bruto) [5]; de este universo, las pyme que se dedican a la industria del software representan el 1.23% [6] y producen el 5.6% del PIB [5].
Mediante un estudio que determinó las características de las empresas desarrolladoras de software en México [7], se encontró que en su gran mayoría eran pymes con pocos recursos, además de usar procesos no estandarizados, dependientes del personal que los ejecutaba. El nivel de capacidad promedio fue de 0.9 en una escala del 0 al 5 del ISO/IEC 15504. Posteriormente, mediante entrevistas, se
M. Muñoz, Centro de Investigación de Matemáticas, Zacatecas, Zacatecas, México, [email protected]
A. Peña, CUCEI de la Universidad de Guadalajara, Guadalajara, Jalisco, México, [email protected]
J. Mejía, Centro de Investigación de Matemáticas, Zacatecas, Zacatecas, México, [email protected]
G. Lara, CUCEI de la Universidad de Guadalajara, Guadalajara, Jalisco, México, [email protected]
precisó que las empresas mexicanas solicitaban un modelo de procesos fácil de entender, práctico y económico, características que no presentan en conjunto modelos como ISO9000:2000, CMM-SW, ISO12207, ISO15504 y CMMI [7].
Por lo anterior, a solicitud de la Secretaría de Economía en México, la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México, desarrolla un modelo que se establece en la Norma Mexicana NMX- I059/02-NYCE-2011 o Modelo de Procesos para la industria del Software (Moprosoft), cuyas principales características son: un modelo mexicano basado en una combinación de estándares (entre ellos: SW-CMM, ISO 9000:2000 y PMBok [7]); que cubre el ámbito completo de una organización;
orientado a empresas dedicadas al desarrollo y mantenimiento de software; siendo sencillo y entendible; con penetración en las pymes en México; que comprende bajos costos de verificación en comparación con otros estándares; y del que se puede obtener un dictamen de conformidad con los procesos de verificación en términos de la Ley Federal sobre Metrología y Normalización [8,9]. Además, Moprosoft cubre los requisitos de la norma ISO 9000:2000 Gestión de Calidad, y contiene un modelo de escala de evaluación y un método de evaluación que cumple con los requisitos de ISO/IEC 15504 [9].
La certificación en Moprosoft, al igual que en otras certificaciones como CMMI, permite participar en apoyos gubernamentales con la ventaja de ser más económica y sencilla.
La calidad en el software está directamente relacionada con la calidad de los procesos que se utilicen para su desarrollo [11]. Especialmente para las pymes, los procesos de gestión de proyectos se enfocan a la implementación de mejoras [12]. De acuerdo con el CMMI-DEV [13] cuatro de seis áreas de proceso para alcanzar el nivel de madurez 2 en las organizaciones pertenecen a la administración de proyectos.
De tal manera que los procesos relacionados con la administración de proyectos se identifican como procesos clave para las pymes.
En este documento se presenta un análisis de la cobertura que tienen los contenidos curriculares sobre el conocimiento necesario para el uso de un modelo requerido por la industria del desarrollo del software. Esto es, el modelo para pymes Moprosoft, particularmente en la gestión de proyectos, y los modelos curriculares que aconseja la Asociación Nacional de Instituciones de Educación Informática (ANIEI), con base en el marco de acreditación del Consejo Nacional de Acreditación en Informática y Computación (CONAIC);
organismo que evalúa y otorga la acreditación a los programas académicos de nivel licenciatura, técnico superior
Coverage of the University Curricula for the Software Engineering Industry in Mexico
M. Muñoz, A. Peña, J. Mejía, G. Lara
E
universitario y medio superior, en Informática y Computación, en los 32 estados de la República Mexicana.
II. ESTÁNDAR DE CURRÍCULAS CONAIC
El CONAIC es el organismo gubernamental mexicano que busca asegurar la calidad en los programas educativos de instituciones de educación públicas y privadas en las áreas de Informática y Computación.
Entre las categorías a acreditar, de acuerdo con el “Marco de referencia para la Acreditación de Programas Académicos de Informática y Computación para Educación Superior” [14], se encuentra el plan de estudios en el que se sintetiza la estrategia del programa educativo y se describen los conocimientos a obtener y las habilidades a desarrollar de los alumnos, así como los recursos para llevarlo a cabo.
La metodología de los criterios curriculares se basa en la medida denominada “unidad” que equivale a 1 hora de teoría o a 3 horas de práctica frente a grupo. Además, el CONAIC maneja los perfiles de egresados conforme a cuatro dominios:
1) Licenciatura en Informática; 2) Ingeniería del Software; 3) Licenciatura en Ciencias de la Computación; e 4) Ingeniería en Computación.
TABLA I
UNIDADES MÍNIMAS POR ÁREAS DE CONOCIMIENTO PARA CADA PERFIL DE EGRESADO CONFORME A LOS CUATRO DOMINIOS
Áreas de Conocimiento Perfil
1 2 3 4
Entorno Social 300 125 100 100
Matemáticas 100 125 250 175
Arquitectura de redes 50 75 100 175
Redes 75 75 100 150
Software base 75 75 100 125
Programación e ingeniería del software 175 225 200 175
Tratamiento de información 175 200 75 50
Interacción hombre-máquina 50 100 75 50
Total de Unidades Mínimas 1,000 1,000 1,000 1,000
Los programas de estudios deben cubrir un mínimo de unidades de cada área de conocimiento, sin importar el perfil, como sigue: 300 de Ciencias Sociales, Humanidades y otras;
420 de Matemáticas y Ciencias Básicas; y 1000 de Informática y Computación. Las unidades mínimas de Informática y Computación, tienen a su vez unidades mínimas en ocho áreas de conocimiento que varían para cada uno de los perfiles de egresado de los cuatro dominios, como se desglosa en la Tabla I.
III. NORMA MOPROSOFT
El modelo de proceso Moprosoft está desarrollado bajo una arquitectura de tres capas llamadas “categorías”, cada una de las cuales contienen un conjunto de procesos que abordan la misma área general de actividades dentro de una organización.
A continuación se describen brevemente cada una de las categorías y el conjunto de procesos que abarca.
Categoría de Alta Dirección: aborda las prácticas relacionadas con la gestión del negocio, proporcionando lineamientos para sus procesos y retroalimentándose con la información proporcionada por ellos. Está integrada por el proceso de gestión del negocio.
Categoría de Gerencia: aborda las prácticas de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos en la categoría de alta dirección, proporcionando los elementos para el funcionamiento de los procesos de la categoría de operación. Además, recibe y evalúa la información generada por los procesos de categoría de operación y comunica los resultados a la categoría de alta dirección. Está integrada por los procesos de gestión de procesos, gestión de proyectos y gestión de recursos.
Categoría Operativa: aborda las prácticas de los proyectos de desarrollo y mantenimiento de software, realizando las actividades de acuerdo a los elementos proporcionados por la categoría de gerencia y entregando a ésta la información y productos generados. Está integrada por los procesos de administración de proyectos específicos y el desarrollo y mantenimiento de software.
IV. METODOLOGÍADELAEVALUACIÓNDE COBERTURA
La metodología para la realización de la evaluación de cobertura consta de tres pasos. A continuación se describe brevemente cada uno de ellos.
a) Análisis Moprosoft
Esta etapa se centra en la selección de los procesos de análisis dentro de la estructura Moprosoft y la identificación del conocimiento genérico.
Se considera conveniente que los estudiantes en formación universitaria adquieran el conocimiento adecuado para gestionar proyectos software bajo los modelos y estándares demandados por las empresas como es el caso de Moprosoft para las pymes mexicanas.
Como se mencionó, las áreas relacionada con la gestión de proyectos son clave para las pymes. Mediante la gestión de proyectos se garantiza que éstos se planifiquen y controlen de acuerdo a las políticas de la empresa, y que las prácticas existentes se mantengan incluso durante periodos de presión [13]. En este análisis, se han seleccionado entonces las áreas de conocimiento y procesos relacionados con la gestión de proyectos Moprosoft; en la Fig. 1 se muestran gráficamente los procesos seleccionados.
Figura 1. Procesos Moprosoft detro del alcance de la investigación.
Posteriormente se realizó un mapeo entre la descripción de las prácticas contenidas en los procesos Moprosoft seleccionados y el conocimiento contenido en los procesos del Modelo de Capacidad y Madurez Integrado para desarrollo (CMMI-DEV) [13] con la intención de hacer una clasificación de los procesos relacionados con la gestión de proyectos de lo que se obtuvo:
En el área de Gestión de proyectos: gestión de requerimientos, planificación de proyectos, monitoreo y seguimiento de proyectos, gestión de acuerdos con proveedores y gestión de riesgos;
En el área de Ingeniería: desarrollo de requerimientos, verificación y validación y;
En el área de Soporte: gestión de configuración y medición y análisis.
Este mapeo permitió clasificar las prácticas Moprosoft dentro de los procesos CMMI-DEV para posteriormente identificar el “conocimiento genérico”. Para el mapeo se realizaron los siguientes pasos: (1) Identificar categoría, proceso, práctica y subpráctica; (2) Analizar la descripción de la subpráctica resaltando términos genéricos; (3) Identificar el proceso CMMI-DEV, leer las metas y prácticas específicas;
(4) Identificar la relación de la subpráctica Moprosoft y clasificarla en uno de los procesos de CMMI-DEV; y finalmente (5) Identificar el conocimiento genérico requerido para llevar a cabo la subactividad Moprosoft.
En la Fig. 2 se muestra un ejemplo de la trazabilidad para el proceso de gestión de proyectos en la categoría de gerencia.
Como resultado de este análisis se identificaron 92 conocimientos genéricos que tienen relación con los procesos de gestión de proyectos de Moprosoft, mismos que se muestran en la Tabla II.
Figura 2. Mapeo y clasificación de prácticas Moprosoft de procesos seleccionados en procesos CMMI-DEV.
TABLA II
CONOCIMIENTO GENÉRICO IDENTIFICADO Análisis de reportes de seguimiento del
proyecto
Análisis y diseño de requerimientos Aprobar el plan de proyecto Asignación de actividades al equipo de trabajo
Asignación de tareas a los roles Asignar recursos al proyecto Asignar responsable administrativo del proyecto
Cerrar contratos de subcontratación Cerrar proyectos internos Conducir reuniones de seguimiento Corrección de defectos
Corrección de defectos de verificación de productos o componentes de producto (documentos)
Definición de medidas
Definir o adoptar un proceso específico para el proyecto
Definir pruebas unitarias, de integración y de sistema Desarrollar plan de adquisición y capacitación
Desarrollar plan de adquisiciones Desarrollar plan de capacitación Desarrollar plan de desarrollo Desarrollar requerimientos Describir proyectos
Descripción de propuesta comercial del proyecto
Documentar el proyecto
Elaborar contratos Elaborar plan de riesgos Elaborar reportes de mediciones Elaborar reportes de seguimiento Elicitar requerimientos Especificación de requerimientos Establecer acuerdos con el cliente Establecer hitos del proyecto Establecer y manejar líneas base Establecimiento de políticas del negocio para realizar proyectos Estimación de costos a alto nivel Estimar costos del proyecto Estructuras de desglose de trabajo Generación de metas cuantitativas
Generar reportes cuantitativos y cualitativos de seguimiento del proyecto
Gestión de acciones correctivas Gestión de activos de proceso Gestión de cartera de proyectos Gestión de configuración de tipos de proyectos
Gestión de defectos de validación Gestión de la configuración Gestión de lecciones aprendidas Gestión de medidas
Gestión de peticiones de cambio Gestión de proveedores Gestión de requerimientos Gestionar la comunicación Gestionar la configuración Gestionar lecciones aprendidas Gestionar los riesgos de un proyecto (identificación de riesgos, probabilidad e impacto de los riesgos, priorización de riesgos)
Gestionar propuestas comerciales Gestionar solicitudes de cambio Gestionar subcontratación
Identificar actividades, entregables y componentes de un producto o servicio Identificar necesidades de clientes Identificar riesgos potenciales del proyecto
Inicio de proyecto
Llevar a cabo reuniones de inicio del proyecto
Realizar pruebas del sistema Realizar calendario del proyecto Realizar manual de usuario Realizar plan de pruebas Realizar pruebas
Realizar pruebas de integración Recolección de reportes de seguimiento del proyecto
Recopilar sugerencias de mejora Registrar valores reales del proyectos durante su ejecución (costos, recursos, tiempos)
Registro de actividades, compromisos y medidas
Revisar el avance del proyecto
Manejar solicitudes de cambio Manejo de acciones correctivas Manejo de activos del proceso Manejo de defectos de validación Manejo de defectos de verificación Manejo de Diagramas de dependencias, ruta crítica, etc.
Manejo de modelos y estándares de mejora de procesos
Manejo de Roles y responsabilidades Modelos de mejora de procesos
Seguimiento a los riesgos del proyecto Seguimiento de acciones correctivas Seguimiento del plan de ventas Técnicas de recopilación de datos Uso de ciclos de desarrollo de software Validación de planes del proyecto Validar los productos y componentes de un producto de un proyecto
Validar los requerimientos Verificar los productos y componentes de un producto de un proyecto Verificar productos o componentes de producto (documentos)
b) Descripción del modelo curricular ANIEI
Esta etapa se centra en la identificación de los elementos de la propuesta curricular.
Para cada una de las ocho áreas de conocimiento establecidas por el CONAIC, la ANIEI hace un desglose en subáreas y subsubáreas para las que se determinan temas de estudio con descripción del contenido. Los temas de estudio se identifican con las iniciales de su área de conocimiento de la siguiente forma: Arquitectura de Computadoras (AC); Redes (RE); Programación e Ingeniería del Software (PI) y de Tratamiento de información (TI); y un número consecutivo,
por ejemplo para Arquitectura de Computadoras: AC1, AC2…
AC32. Dando un total de 212 temas de estudio [15].
c) Evaluación de Cobertura
Esta etapa se centra en establecer la escala de valores y la cobertura curricular CONAIC respecto al conocimiento requerido para llevar a cabo la gestión de proyectos bajo la norma Moprosoft.
Para llevar a cabo la evaluación de cobertura, cada uno de los 92 conocimientos genéricos y sus prácticas Moprosoft relacionadas se compararon respecto al contenido propuesto por los 212 temas de estudios que componen las diferentes subsubáreas del modelo curricular propuesto por el ANIEI.
Para la asignación de valores de cobertura se estableció una escala de entre 0 y 4 como a continuación se describe: (0) no tiene conocimiento relacionado con la práctica Moprosoft, no lo cubre, (1) indirectamente aporta conocimiento mínimo relacionado con la práctica Moprosoft; (2) aporta conocimiento genérico que apoya a la realización de la práctica Moprosoft; (3) conocimiento que directamente apoya la realización de la práctica Moprosoft; y (4) aporta conocimiento específico directamente relacionado con la práctica Moprosoft.
La cobertura queda representada por el valor más alto dado a uno de los tema de estudio, sin importar cuántos temas de estudio cubran la práctica, ésta queda cubierta hasta el valor máximo que alguno de los tema de estudio presente.
De tal manera que para establecer qué tan cubierta está una práctica Moprosoft, se analizó el contenido de cada tema de estudio propuestos por el ANIEI para las áreas de conocimiento del CONAIC, frente al conocimiento genérico identificado de la práctica Moprosoft. La Fig. 3 muestra el proceso de asignación de valores de cobertura.
Figura 3. Proceso de asignación de valores de cobertura por práctica.
Cabe resaltar que en esta evaluación participaron 4 investigadores, ésta se hizo de manera individual por cada uno de ellos y posteriormente se realizó una revisión cruzada de los resultados para corroborar los valores obtenidos. Además,
se mantuvieron reuniones para llegar a consenso en los valores en los que había discrepancia. De esta manera se obtuvo un refinamiento de los valores de cobertura asignados a las prácticas Moprosoft para los procesos seleccionados.
V. ANÁLISIS DE COBERTURA CURRICULAR
En esta sección se muestra el análisis de los principales resultados obtenidos.
A. Resultados de cobertura por proceso
Aquí se realiza un concentrado por proceso para establecer su grado de cobertura. Para obtener un valor proporcional de cobertura de cada área de conocimiento se aplicó la siguiente fórmula: valor de cobertura = Σi...n valor de cobertura de las prácticas / (no. de prácticas * valor máximo de cobertura), siendo 4 el valor para una cobertura completa (de acuerdo a la asignación de valores descrita en la Sección IV ‘c) Evaluación de cobertura’). A manera de ejemplo consideremos las prácticas Moprosoft relacionadas con el proceso Gestión de Requerimientos en las tres categorías:
Categoría gerencial: práctica Moprosoft “A2.1 Realizar actividades del Plan de Ventas” y conocimiento genérico relacionado “elicitar requerimientos”, temas de estudio que cubren de alguna manera la práctica separados por subáreas:
AC14 al AC17 cobertura de 2; los temas AC20 al AC25 cobertura asignada de 2 ; los temas RE4 al RE9 cobertura de 2; RE10 al RE14
cobertura de 2; RE15 y RE16 cobertura de 2; RE17 al RE21
cobertura de 2; RE22 y RE23 cobertura de 2; PI24 cobertura de 4;
PI36 cubre 1; y TI18 cobertura de 2. De tal manera que la cobertura para “elicitar requerimientos” es de 4 , ya que el tema de estudio PI24, “Análisis de sistemas”, aporta conocimiento específico directamente relacionado con esta práctica.
Categoría operación: práctica “A2.8 Revisar el Registro de Rastreo de los requerimientos” y conocimiento genérico relacionado “gestión de requerimientos”, se asignó un valor máximo de cobertura de 3.
Categoría operación-mantenimiento: práctica “A2.2 Documentar” y conocimiento genérico relacionado
“especificación de requerimientos”, se asignó un valor de máximo de cobertura de 3.
Aplicando la fórmula de valor de cobertura, se establece que de los temas de estudio sugeridos por ANIEI y de acuerdo con su descripción, se consigue cubrir un 83% para este proceso.
En la Tabla III se muestra un resumen de los valores obtenidos para los procesos analizados.
TABLA III
RESUMEN DE VALORES OBTENIDOS POR PROCESO
Área Proceso Cobertura
Gestión de
proyectos Gestión de Requerimientos 83%
Planificación de Proyectos 84%
Monitoreo y Control del Proyecto 94%
Gestión de Acuerdo con Proveedores 56%
Gestión de Riesgos 58%
Ingeniería Desarrollo de Requerimientos 67%
Verificación 100%
Validación 63%
Soporte Gestión de configuración 48%
Medición y análisis 30%
Para interpretar los resultados, los procesos se han agrupado de acuerdo con las áreas de conocimiento del CMMI-DEV enfocadas en este artículo: gestión de proyectos, soporte e ingeniería:
• Gestión de proyectos: contiene procesos clave para realizar un proyecto adecuadamente, y se relaciona con las prácticas de planificación, monitorización y control del proyecto.
Interpretación: Basado en los resultados de la Tabla III, se identifica que el currículo propuesto por la ANIEI no proporciona una cobertura completa para ningún área. Si bien los egresados obtienen conocimientos en áreas de proceso como planificación del proyecto, monitoreo y control, y gestión de requerimientos, se detectan deficiencias de conocimiento en áreas como la gestión de riesgos y la gestión de proveedores, encontrándose una oportunidad de mejora para reforzar el conocimiento para la identificación y gestión de los riesgos, así como la adquisición de recursos que pueden impactar al proyecto.
• Ingeniería: contiene los procesos que soportan actividades para el desarrollo de software, se enfoca en las prácticas de verificación, validación y gestión de requerimientos.
Interpretación: Basado en los resultados de la Tabla III, se identifica que el currículo propuesto por la ANIEI únicamente proporciona una cobertura completa para el proceso de verificación, sin embargo, el conocimiento proporcionado para los procesos de desarrollo de requerimientos y validación tienen una cobertura muy baja, es importante puntualizar que el desarrollo de requerimientos es crítico para la correcta definición de los requisitos de software, teniendo una relación directa con el éxito de software a desarrollar, y por otro lado, el proceso de validación dirigido a garantizar que el software producido sea lo que el cliente necesita tiene una relación directa con la satisfacción del cliente.
• Soporte: contiene procesos enfocados en proporcionar el soporte necesario para la realización de un proyecto.
Interpretación: Basado en los resultados de la Tabla III, se identifica que el currículo propuesto por la ANIEI presenta una cobertura muy baja en conocimiento relacionado con el proceso de gestión de configuración, que está enfocado en mantener la integridad de los productos obtenidos, tanto software como documentación asociada, y del proceso de medición y análisis, que está enfocado en proporcionar la capacidad para la definición y uso correcto de las medidas para obtener la información requerida.
B. Resultados de cobertura por área
Aquí se establece el porcentaje de cobertura por áreas, enfocándonos como se ha dicho, en aquellas que son clave para el desarrollo y soporte de un proyecto. Para hacerlo se aplica la siguiente fórmula: % cobertura por área = % de cobertura / (no. de procesos).
Los resultados obtenidos se muestran en la Tabla 4, en dónde se puede ver que ningún área presenta cobertura total.
Como se observa, el área de ingeniería es la que tiene una mayor cobertura (76%), lo que refleja que los graduados adquieren mayor conocimiento en actividades relacionadas
con el desarrollo. Sin embargo, se detecta un conocimiento moderado en áreas de gestión de proyectos encargadas de actividades relacionadas con la planificación, seguimiento y control de un proyecto, así como un conocimiento mínimo en áreas de soporte orientadas a la medición, control de calidad y la gestión de configuración. Estos resultados confirman que existe una necesidad de reforzar sus conocimientos para afrontar el reto de integrarse en las organizaciones y gestionar un proyecto con una visión holística y de forma adecuada.
TABLA IV VALORES OBTENIDOS POR ÁREA
Área Cobertura
Gestión de proyectos 71%
Ingeniería 76%
Soporte 51%
C. Resultados por área de proceso-categoría Moprosoft Aquí se establece el nivel de cobertura del currículo sugerido por el ANIEI, sobre los procesos Moprosoft en las categorías de este modelo de: alta dirección, gerencia y operativo. Los resultados se obtuvieron relacionando el número de temas de estudio y su nivel de cobertura individual como se muestran en la Tabla V.
TABLA V
VALORES OBTENIDOS POR ÁREA
Área Categoría Temas
de estudio
Con cobertura
4 3 2 1 0
Gestión de
proyectos Gerencial 22 16 3 3 - -
Operación 29 12 8 6 2 1
Operación- mantenimiento
16 13 3 - - -
Ingeniería Gerencial 2 - - 2 - -
Operación 4 4 - - - -
Operación- mantenimiento
32 25 2 5 - -
Soporte Gerencial 4 3 - - - 1
Operación 4 1 - 2 1 -
Operación- mantenimiento
7 1 - 6 - -
Como se puede ver en la Tabla V no todas las prácticas son completamente cubiertas (valor 4) por el contenido en el modelo curricular propuesto por la ANIEI, resaltando los siguientes puntos:
• Gestión de Proyectos: 41/67 prácticas referentes a la planificación, seguimiento y control del proyecto son cubiertas completamente, lo que significa que en el modelo curricular de la ANIEI contiene conocimiento específico en estas prácticas, donde 16 proporcionan conocimiento de gestión de proyectos a nivel gerencial y 25 proporcionan conocimiento de gestión de proyectos a nivel operativo y de mantenimiento (niveles de mandos intermedios y operativos). Estas prácticas se enfocan principalmente en desarrollo de planes, identificación y desglose de actividades de proyectos, mismas que son compartidas por los tres niveles para la planificación de los proyectos. Sin embargo, prácticas enfocadas en descripciones del proyecto, planes relacionados con el plan de proyecto como: plan de comunicación, reportes de seguimiento, llevar a cabo y
dirigir reuniones de seguimiento, asignación de actividades a un equipo, e inicio y cierres de proyecto, tienen un nivel de cobertura muy bajo respecto al conocimiento sugerido por el modelo curricular de la ANIEI.
• Ingeniería: 29/38 prácticas referentes al desarrollo de software son cubiertas completamente, lo que significa que el modelo curricular de la ANIEI contiene conocimiento específico relacionado con estas prácticas; donde las 29, completamente cubiertas, son prácticas relacionadas con las categorías de soporte y mantenimiento (niveles de mandos intermedios y operativos, por ejemplo, desarrolladores de software, analistas, etc.). Específicamente las prácticas mejor cubiertas son las relacionadas con la verificación del software que es lo que nos permite validar su correcto funcionamiento. Sin embargo, las prácticas relacionadas con el desarrollo de requerimientos y la validación del software, críticas para el buen entendimiento de las necesidades del software y la validación de desarrollar el producto adecuado, tienen una cobertura muy baja. Además, se detecta una deficiencia en prácticas a nivel gerencial.
• Soporte: 4/15 prácticas de esta categoría orientadas a medir, asegurar la calidad y la gestión de configuración, son cubiertas completamente con el conocimiento proporcionado por el modelo curricular ANIEI, de las cuales 3 son de nivel gerencial y 2 son nivel operación y mantenimiento. Las prácticas del nivel de soporte consideradas en esta investigación están relacionadas por un lado, con la gestión de configuración de todos los productos generados durante el desarrollo de un proyecto (software, líneas base, diagramas, documentación, código, versionado, estándares de defectos y de códigos, etc.), y por otro con la definición de medidas adecuadas para proyectos a desarrollar, así como la definición de los análisis que se van a realizar a los productos obtenidos. El resultado en esta categoría en general refleja que existe muy poca cobertura de conocimiento en este tipo de prácticas, necesarias para el correcto soporte de la ejecución y medición de todos los elementos que conforman el desarrollo de un proyecto (Ver Fig. 4).
Figura 4. Cobertura total de temas de estudio por categorías Moprosoft.
En la Fig. 4 se muestra una gráfica con los porcentajes de prácticas completamente cubiertas por categoría, independientemente del área a la que pertenezcan, con un total de: 19 de la categoría Gerencial; 17 de la de Operación y 39
de Operación-mantenimiento. Lo que claramente demuestra que el currículo sugerido por la ANIEI tiene una tendencia a la enseñanza de procesos operativos, más que a los procesos gerenciales.
VI. CONCLUSIONES
Dos de los principales retos a los que se enfrentan los recién graduados que se integran a la industria del software son: 1) tener el conocimiento para desempeñar un rol en el desarrollo de un proyecto, ya sea como gestor de un proyecto o como parte del equipo de desarrollo y 2) trabajar bajo un modelo o estándar de calidad requerido por la organización, especialmente en pymes donde los recursos con los que se trabajan son mínimos.
Para lograr integrarse exitosamente en una organización y ser capaz de enfrentar este reto, el ingeniero o licenciado recién egresado, debe haber adquirido durante su formación un conjunto de prácticas de software que le permitan desempeñar sus tareas de manera adecuada.
Con la finalidad de establecer el grado de conocimiento que el ingeniero o licenciado egresado de carreras relacionadas con el desarrollo de software adquiere durante su formación universitaria, en este artículo se seleccionó, por una parte un estándar que la mayoría de los currículos de las universidades tienden a cumplir para obtener programas de calidad y, por otro lado, un estándar con una alta práctica en las pymes mexicanas.
Como se observa en los resultados obtenidos, si bien se tiene un grado medio de cobertura entre el conocimiento requerido por el estándar y el conocimiento proporcionado por los temas de conocimiento del currículo, se resaltan los siguientes hallazgos:
El modelo curricular de la ANIEI contiene conocimiento en gestión de requerimientos, sin embargo, el desarrollo de requerimientos tiene una cobertura muy baja. El conocimiento de desarrollo de requerimientos es importante para identificar de manera adecuada las necesidades del cliente, de lo contrario, aun cuando se tenga conocimiento para la gestión de requerimientos, no se tiene éxito en los proyectos si éstos están mal definidos.
El modelo curricular de la ANIEI contiene conocimiento en la monitorización y control de los proyectos, sin embargo, la cobertura en prácticas relacionadas con la gestión de riesgos, validación, medición y análisis, y la gestión de la configuración debe ser mejorada. El conocimiento relacionado con la gestión de riesgos es muy importante, ya que de no identificarse, pueden afectar al proyecto desviándolo significativamente de lo planificado; el conocimiento relacionado con la validación es clave para saber si el producto que se está desarrollando es el adecuado conforme a las necesidades del cliente; el conocimiento relacionado con la medición y análisis es necesario para elegir las medidas adecuadas para conocer el rendimiento del proyecto; y finalmente, el conocimiento relacionado con la gestión de la configuración es necesario para llevar el control de las líneas base, documentación y productos obtenidos a lo largo del
desarrollo del proyecto. Estas áreas son necesarias para el adecuado seguimiento y control del proyecto.
Es también importante resaltar que los temas de estudio que propone la ANIEI para cada una de las ocho áreas de conocimiento requeridas por el CONAIC (ver Tabla I) corresponden a un modelo sugerido, de tal manera que las instituciones académicas pueden o no seguir dicha recomendación. Por otro lado, sería interesante, una vez que se ha establecido la metodología, conocer el valor de cobertura de programas de estudios de algunas universidades representativas en México.
Basado en este análisis se puede crear un currículo que presente el programa de estudios con mayor cobertura e incluso uno ideal que incluya las materias que se ha detectado son necesarias. El modelo de este análisis también puede servir para hacer un postgrado que contemple la especialización en gestión de proyectos basado en Moprosoft, en el que se incluyan las materias que cubran los temas de estudio según el currículo del egresado a nivel licenciatura.
Finalmente es importante mencionar que los resultados obtenidos se consideran útiles tanto para el área académica como para la industria. En la academia como apoyo para identificar las oportunidades de mejora en la formación de ingenieros y estudiantes tal que sean capaces de integrarse en la industria trabajando bajo normas requeridas; y en la industria para identificar en qué áreas tienen una mayor o menor formación, de tal manera que puedan establecerse programas adecuados de educación.
REFERENCIAS
[1] T. M. Moreno, “Cuatro talones de Aquiles de las pymes,” [En línea].
Observatorio PYME, 2008 Disponible en:
http://www.observatoriopyme.org/index.php?option=com_content&vi ew=article&id=74&Itemid=102
[2] Ministerio de Industria, Energía y Turismo, "Más Información sobre la nueva definición de la PYME en UE," vol. 2012, 2013
[3] G. Rodríguez, Á. Soria, and M. Campo, “Supporting Assessment of Practices in Software Engineering Courses,” IEEE Latin America Transactions, Vol. 13, No. 9, 2015
[4] G. Rodríguez, Á. Soria, and M. Campo, “Supporting Assessment of Practices in Software Engineering Courses,” IEEE Latin America Transactions, Vol. 13, No. 9, 2015
[5] E. Muñoz, M. Muñoz, E. C. García and J. Mejia, “Knowledge Management in Process Improvement and Best Practices Sharing,”
IEEE Latin America Transactions, Vol. 12, NO. 3, 2014
[6] ProMéxico, PyMES, “eslabón fundamental para el crecimiento enMéxico,” [En línea]. ProMéxico 2014. Disponible en: http://
www.promexico.gob.mx/negocios-internacionales/
[7] INEGI, Instituto Nacional de Estadísticas y Geografía [En línea}, Base de datos, 2015, http://www.inegi.org.mx
[8] H. Oktaba, “Historia de una norma: MoProSoft y sus primeros pasos,”
Revista Software Gurú, vol. 1, no. 8, pp. 6-11, 2005
[9] G. Cuevas, “Algunos aspectos clave a considerar para la mejora de procesos software,” Conferencia Magistral 1er Congreso Internacional de Mejora de Procesos Software (CIMPS 2012).
Zacatecas, México, 2012
[10] M. G. Sanabria, “¿Quién hace la calidad?,” Conferencia Magistral 2do Congreso Internacional de Mejora de Procesos Software (CIMPS 2013). Zacatecas, México, 2013
[11] H Oktaba, “Moprosoft: el nuevo modelo que impondrá́ una norma mexicana para la calidad en la industria del software.” Entrevista con la Dra. Hanna Oktaba, presidenta de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS). Boletín IIE, julio- septiembre, 2003
[12] M. Muñoz, J. Mejia and C. Valtierra, “Helping organizations to address their effort toward the implementation of improvements in
their software process,” Revista Facultad de Ingeniería, Universidad de Antioquia, no. 77, pp. 115-126, 2015
[13] M. Chrissis, M. Konrad and S. Shrum, “CMMI para desarrollo, versión 1.3: guía para la integración de procesos y la mejora de procesos (Versión Español),” Editorial Universitaria Ramón Areces, 1ª ed, May 17, 2012
[14] CONAIC, “Marco de referencia para la Acreditación de programas académicos de Informática y Computación de Educación Superior,”
[En línea], Enero, 2013, Disponible en:
http://conaic.net/formatos/CRITERIOS_EVALUACION_CONAIC_2 013.pdf
[15] ANIEI, Asociación Nacional de Instituciones de Educación Informática, “Catálogo de áreas de concimiento,” [En línea], Mayo
2014, Disponible en:
http://www.aniei.org.mx/portal/modeloscatalogo.html
Mirna Ariadna Muñoz Mata Doctor en Informática por la Universidad Politécnica de Madrid, en Madrid España, con mención de “Doctorado Europeo”. Ha realizado una estancia posdoctoral en la Universidad Carlos III de Madrid, España.
Actualmente es investigador del Centro de Investigación en Matemáticas (CIMAT) - Unidad Zacatecas en el área de Ingeniería de Software y es miembro del grupo de investigación Cátedra de Mejora de Procesos Software en el Espacio
Iberoamericano (MPSEI).
Adriana Peña Pérez Negrón recibió el grado de Doctora en Informática de la Universidad Politécnica de Madrid haciendo una estancia de investigación en la Universidad de Salford del Reino Unido para obtener la mención de “Doctor Europeo”.
Su interés es en la interacción del usuario y el desarrollo de agentes en los entornos virtuales colaborativos, así como en la enseñanza de la Informática.
Jezreel Mejía Miranda es doctor en Informática por la Universidad Politécnica de Madrid (UPM), España, donde se le concedió la nota máxima, Cum Laude, y mención de
"Doctorado Europeo". Realizó una estancia de investigación para obtener el doctorado europeo en la Universidad Fernando Pessoa en Oporto, Portugal. Es miembro del grupo de investigación Cátedra de Mejora de Procesos Software en el Espacio Iberoamericano (MPSEI).
Graciela Lara López obtuvo su título de Licenciada en Informática y el grado de Maestra en Sistemas de Información por la Universidad de Guadalajara (UDG). Es Doctora en Metodología de la Enseñanza por el Instituto Mexicano de Estudios Pedagógicos (IMEP), México. Actualmente es doctoranda en Software y Sistemas en la Universidad Politécnica de Madrid.
