148.204.210.201148.204.210.201/tesis/1551292767913tesisimplement.pdfincluso en los peores momentos y...
TRANSCRIPT
Agradecimientos
Quiero agradecer principalmente a la Dra. Elizabeth Acosta Gonzaga, quien con su experiencia y
habilidad en el tema enriqueció este trabajo. Gracias por el tiempo, comprensión y atención
oportuna a mis dudas y sobre todo por guiarme hasta la conclusión de mi tesis.
Al Dr. Eduardo René Rodríguez Ávila por sus oportunas correcciones que permitieron que este
trabajo se presentara de la mejor manera.
Al Dr. Jesús Antonio Álvarez Cedillo por su atención y comentarios hacia el presente trabajo.
Al M en C. Rafael Salvador Ibáñez Castañeda por formar parte del comité de revisión para esta
tesis, muchas gracias por todo su apoyo.
Al Dr. Abraham Gordillo Mejía que gracias a su gran conocimiento en el tema, se pudo reflejar
en este trabajo diversos conceptos vistos durante mi trayecto en la maestría.
A todos y cada uno de ustedes, miembros de la comisión revisora de ésta tesis, muchas gracias
por el apoyo y orientación durante todo este proceso.
Dedicatorias
A Dios por permitirme llegar hasta este punto y poder lograr una meta más en mi vida, sin su
ayuda no podría lograrlo.
A mi madre por brindarme todo su apoyo durante el desarrollo de esta tesis, agradezco a dios
tenerte en mi vida y poder dedicarte este trabajo, pues eres parte fundamental de él. Eres mi
motor y te estaré eternamente agradecida por siempre enseñarme el valor de la dedicación y el
esfuerzo. Te amo mucho mami.
A mi hermana – segunda madre Raque, que han sido parte fundamental desde siempre, pues el
apoyo económico y moral que he recibido de tu parte es lo que me permite estar hoy día donde
me encuentro. Agradezco que estés en mi vida y con orgullo puedo decir que este trabajo te lo
dedico con todo el amor del mundo pues formas parte de él. Gracias por todo hermana. Te amo
mucho.
A Carlos Tycho, tu apoyo fue fundamental durante todo este proceso, pues has estado conmigo
incluso en los peores momentos y a pesar de mis berrinches. Saber que cuento contigo me llena
de mucha alegría, pues siempre estuviste motivándome a ser la mejor versión de mi misma, a no
rendirme y pese a todo siempre dar lo mejor. Por ello quisiera hacerte participe de uno más de
mis logros, con mucho cariño. Te amo mucho
A todos mis amigos Tere, George, Glo, Cindy, Cesar, Rubén, Arturo que siempre están ahí
apoyándome en todo momento, aconsejándome y brindándome siempre su cariño y amor. Las
veces que quería claudicar siempre estuvieron conmigo echándome porras, confiando en mí.
Gracias por siempre estar junto a mí y darme su mano cuando más lo he necesitado. Los quiero
muchísimo.
Índice
Resumen ...................................................................................................................................................................... 11
Abstract ....................................................................................................................................................................... 12
INTRODUCCIÓN ..................................................................................................................................................... 13
CAPÍTULO 1. MARCO CONTEXTUAL Y PLANTEAMIENTO DEL PROBLEMA ...................................... 15
1.1. Planteamiento del Problema .............................................................................................................................. 15
1.2. Pregunta de Investigación e Hipótesis ............................................................................................................... 16
1.3. Objetivo de la Investigación ............................................................................................................................... 16
1.4. Justificación ......................................................................................................................................................... 17
CAPÍTULO 2. MARCO TEÓRICO ........................................................................................................................ 19
2.1. MAAGTICSI ....................................................................................................................................................... 19
2.1.1. Ventajas y desventajas de MAAGTICSI........................................................................................................ 20
2.1.2. Procesos del MAAGTICSI .............................................................................................................................. 21
2.1.2.1. Gobernanza.................................................................................................................................................... 22
2.1.2.2. Organización .................................................................................................................................................. 24
2.1.2.3. Entrega ........................................................................................................................................................... 26
2.1.3. Roles y Responsabilidades del MAAGTICSI................................................................................................. 29
2.2. Modelo Ideal ........................................................................................................................................................ 32
2.2.1. Fase de iniciación (Initiating) .......................................................................................................................... 33
2.2.2. Fase de diagnóstico (Diagnostic) ..................................................................................................................... 34
2.2.3. Fase de establecimiento (Establishing) ........................................................................................................... 35
2.2.4. Fase de Actuación (Acting) .............................................................................................................................. 36
2.2.5. Fase de Aprendizaje (Learning) ...................................................................................................................... 37
2.3. Capability Maturity Model Integration (CMMI®) .............................................................................................. 39
2.3.1. Utilidad de CMMI® .......................................................................................................................................... 41
2.3.2. Casos de éxito en implementación de CMMI® en México ............................................................................ 42
2.3.3. Niveles de CMMI® ............................................................................................................................................ 47
CAPÍTULO 3. MARCO METODOLÓGICO ......................................................................................................... 51
3.1. Empresa Xcom: Objeto de Estudio ................................................................................................................... 51
3.1.1. Objetivo de la Empresa ................................................................................................................................... 53
3.1.2. Misión, Visión y Valores .................................................................................................................................. 53
3.1.3. Organigrama del Área de TI ........................................................................................................................... 55
3.1.4. Descripción de la Problemática Actual .......................................................................................................... 57
3.2. Uso del MAAGTICSI en Xcom .......................................................................................................................... 66
3.3. Descripción de Procesos para el Desarrollo de Software.................................................................................. 70
3.4. Ejecución de Aplicativos Basados en el MAAGTICSI ..................................................................................... 77
3.4.1. Ejecución del Aplicativo BATCH en el SASE ............................................................................................... 77
3.4.2. Ejecución del Aplicativo Host to Host en JAIS .............................................................................................. 80
3.4.3. Ejecución del aplicativo modalidad mixta en HIDS (Sector Público) ......................................................... 83
3.5. Implementación de CMMI® Nivel 2 .................................................................................................................. 87
3.5.1. Modelo Ideal - Fase Inicial .............................................................................................................................. 87
3.5.2. Modelo Ideal - Fase de Diagnóstico ................................................................................................................ 88
3.5.3. Modelo Ideal - Fase de Establecimiento ......................................................................................................... 88
3.5.3.1. REQM - Administración de Requerimientos.............................................................................................. 91
3.5.3.2. PP – Planeación de Proyectos ....................................................................................................................... 94
3.5.3.3. PMC – Monitorización y Control de Proyectos ........................................................................................ 100
3.5.3.4. AP – Administración de Proveedores ........................................................................................................ 101
3.5.3.5. MA – Medición y Análisis ........................................................................................................................... 102
3.5.3.6. PPQA – Aseguramiento de Calidad de Procesos y Productos ................................................................ 104
3.5.3.7. CM – Administración de la Configuración ............................................................................................... 105
CAPÍTULO 4. HALLAZGOS Y ANÁLISIS DE LOS RESULTADOS ............................................................. 107
4.1. Evaluación del Aplicativo SASE ...................................................................................................................... 108
4.1.1. Cálculo de la Calidad en Aplicativo SASE ................................................................................................... 108
4.1.2. Cálculo de la Eficiencia en Aplicativo SASE ............................................................................................... 110
4.1.3. Cálculo de la Ganancia en Aplicativo SASE ................................................................................................ 112
4.2. Evaluación del Aplicativo JAIS ....................................................................................................................... 114
4.2.1. Cálculo de la Calidad en Aplicativo JAIS .................................................................................................... 114
4.2.2. Cálculo de la Eficiencia en Aplicativo JAIS ................................................................................................. 116
4.2.3. Cálculo de la Ganancia en Aplicativo JAIS ................................................................................................. 118
4.3. Evaluación del Aplicativo HIDS (Sector Público) .......................................................................................... 120
4.3.1. Cálculo de la Calidad en Aplicativo HIDS (Sector Público) ....................................................................... 120
4.3.2. Cálculo de la Eficiencia en Aplicativo HIDS (Sector Público) ................................................................... 121
4.3.3. Cálculo de la Ganancia en Aplicativo HIDS (Sector Público) .................................................................... 123
4.4. Entrevistas ......................................................................................................................................................... 126
CONCLUSIONES .................................................................................................................................................... 138
ANEXOS ................................................................................................................................................................... 141
BIBLIOGRAFÍA ...................................................................................................................................................... 143
Índice de Figuras
Figura 1. Procesos MAAGTICSI. Fuente: Comisión Intersecretarial para el Desarrollo del
Gobierno Electrónico, 2017 ......................................................................................................... 21
Figura 2. Roles y Responsabilidades MAAGTICSI. Fuente: Comisión Intersecretarial para
el Desarrollo del Gobierno Electrónico, 2017 ............................................................................ 30
Figura 3. Matriz de responsabilidades MAAGTICSI. Fuente: Comisión Intersecretarial
para el Desarrollo del Gobierno Electrónico, 2017 ................................................................... 31
Figura 4. Modelo IDEAL iterativo (SEI, 1996) ......................................................................... 32
Figura 5. Estructura de CMMI® (Ramirez Luján, Rodriguez Baryolo, & Molina Villalobos,
2010) ............................................................................................................................................... 40
Figura 6. Niveles de Madurez CMMI® (SEI, 2010) ................................................................. 47
Figura 7. Organigrama del área de TI (Xcom, 2018) ............................................................... 55
Figura 8. Ejemplo pantalla SIGS ................................................................................................ 57
Figura 9. Cobro modalidad HOST TO HOST (Xcom, 2018)................................................... 58
Figura 10. Cobro modalidad BATCH (Xcom, 2018) ................................................................ 59
Figura 11. Cobro modalidad MIXTO (Xcom, 2017) ................................................................. 60
Figura 12. Proceso de solicitud y liberación de un proyecto (Xcom, 2017) ............................ 64
Figura 13. Porcentaje de cumplimiento de procesos MAAGTICSI en Xcom (Auditoria
Xcom, Julio 2018) ......................................................................................................................... 69
Figura 14. Recepción de la solicitud de un sistema informático (Xcom, 2017) ...................... 71
Figura 15. Análisis de la solicitud (Xcom, 2017) ........................................................................ 72
Figura 16. Asignación de Recursos (Xcom, 2017) .................................................................... 73
Figura 17. Desarrollo de Software (Xcom, 2017) ...................................................................... 74
Figura 18. Pruebas Operativas (Ambiente de Desarrollo) (Xcom, 2017) ............................... 75
Figura 19. Liberación a producción (Xcom, 2017) .................................................................... 76
Figura 20. Ejemplo de pantalla para cobro SASE .................................................................... 78
Figura 21. Ingresos económicos y No. Operaciones SASE ....................................................... 80
Figura 22. Ejemplo de captura de datos JAIS .......................................................................... 81
Figura 23. Ingresos económicos y No. de Operaciones JAIS .................................................. 83
Figura 24. Ejemplo pantalla de captura HIDS (SECTOR PÚBLICO) .................................. 84
Figura 25. Ingresos económicos y No. de Operaciones HIDS (SECTOR PÚBLICO) ........... 86
Figura 26. Formato de descripción de requerimientos (SEI CMMI® Production, 2010). .... 92
Figura 27. Formato Acta de Reunión (SEI CMMI® Production, 2010). ................................ 93
Figura 28. Matriz de Formulación de proyectos (SEI CMMI® Production, 2010). .............. 95
Figura 29. Microsoft Project para cronogramas ....................................................................... 96
Figura 30. Matriz de planificación de proyectos (SEI CMMI® Production, 2010). .............. 97
Figura 31. Formato de Planificación de Proyectos (SEI CMMI® Production, 2010). .......... 98
Figura 32. Repositorio GIT ......................................................................................................... 99
Figura 33. Formato de Descripción de Defectos ...................................................................... 104
Figura 34. Descripción de defectos SASE ................................................................................ 109
Figura 35. Comparación de operaciones SASE ....................................................................... 114
Figura 36. Descripción de Defectos JAIS ................................................................................. 115
Figura 37. Comparación de operaciones JAIS ........................................................................ 119
Figura 38. Descripción de Defectos HIDS (SECTOR PÚBLICO) ......................................... 120
Figura 39. Comparación de operaciones HIDS (SECTOR PÚBLICO) ................................ 125
Índice de Tablas
Tabla 1. Modelo IDEAL enlistado. (SEI, 1996) ......................................................................... 38
Tabla 2. Empresas a nivel nacional que implementan CMMI® (Meneses, Padilla, Mora, &
Barrera, 2014) ............................................................................................................................... 42
Tabla 3. Relación de aplicativos en SIGS (Xcom, 2018) ........................................................... 61
Tabla 4. Descripción de Procesos MAAGTICSI (Órgano Interno de Control Xcom, 2018) 66
Tabla 5. Procesos actuales de la GDSI (Xcom, 2017) ................................................................ 70
Tabla 6. Plan de trabajo SASE ................................................................................................... 78
Tabla 7. Operaciones SASE por mes .......................................................................................... 79
Tabla 8. Plan de Trabajo JAIS ................................................................................................... 81
Tabla 9. Operaciones JAIS por mes ........................................................................................... 82
Tabla 10. Plan de Trabajo HIDS (SECTOR PÚBLICO) ......................................................... 84
Tabla 11. Operaciones HIDS (SECTOR PÚBLICO) por mes ................................................. 86
Tabla 12. Cursos propuestos para Xcom ................................................................................... 87
Tabla 13. Roles para el programa de Mejora con CMMI® nivel 2 .......................................... 89
Tabla 14. Resumen de Cumplimiento CMMI® nivel 2 ........................................................... 107
Tabla 15. Plan de trabajo de alto nivel SASE .......................................................................... 110
Tabla 16. Operaciones SASE por mes aplicando MAAGTICSI Y CMMI® nivel 2............ 112
Tabla 17. Plan de trabajo de alto nivel JAIS .......................................................................... 116
Tabla 18. Operaciones JAIS por mes aplicando MAAGTICSI Y CMMI® nivel 2 ............. 118
Tabla 19. Plan de trabajo de alto nivel HIDS (SECTOR PÚBLICO) ................................... 121
Tabla 20. Operaciones HIDS (SECTOR PÚBLICO) por mes aplicando MAAGTICSI Y
CMMI® nivel 2 ............................................................................................................................ 124
Tabla 21. Resumen de respuestas a las entrevistas ................................................................. 136
11
Resumen
La mayoría de las empresas hoy día optan por adaptarse al cambio e implementar una
metodología y/o modelos acorde a sus necesidades y al objetivo principal de la organización. El
modelo CMMI® (Capability Maturity Model Integration) se ha implementado en una gran
cantidad de empresas y ha dado muy buenos resultados en cuanto a la mejora de procesos de
desarrollo de software, así como un gran aumento a la productividad de estas. Dentro del sector
público es más complicado el implementar un programa de mejora debido a que los empleados
ejercen resistencia al cambio y eso dificulta mucho la implementación y el desarrollo de los
procesos. Sin embargo, a pesar de los obstáculos que pudieran encontrarse dentro del sector
público, es posible que las empresas gubernamentales mejoren y sean más productivas en las
áreas de TI. La implementación de CMMI en su segundo nivel permite que esto sea posible.
El presente trabajo consiste en mostrar la aplicación y funcionalidad del modelo CMMI® nivel 2
para mejorar los procesos de las áreas de informática en un organismo gubernamental. Mediante
la implementación de este modelo, se ayuda considerablemente a la mejora de procesosaún
teniendo el Manual Administrativo de Aplicación General en las materias de Tecnologías de la
Información y Comunicaciones y en la Seguridad de la Información (MAAGTICSI)
implementado.
12
Abstract
Most companies today choose to adapt to change and implement a methodology according to
their needs and the main objective of the organization. The CMMI® (Capability Maturity Model
Integration) model has been implemented in a large number of companies and has given very
good results in terms of improving software development processes, as well as a large increase in
productivity of this. Within the public sector, it is more complicated to implement an
improvement program because employees exercise resistance to change and that makes
implementation and development of the processes very difficult. However, despite the obstacles
that may be encountered within the public sector, it is possible for government companies to
improve and be more productive in the IT areas. The implementation of CMMI® at its second
level allows this to be possible.
This job is to show the application and functionality of the Capability Maturity Model Integration
(CMMI®) level 2 model to improve the processes of the information technology areas in a
government agency, by studying how the implementation of this model helps considerably to
improve of processes, even having the Administrative Manual of General Application in the areas
of Information Technology and Communications and in the Information Security (MAAGTICSI)
implemented.
13
INTRODUCCIÓN
Debido a la existencia de auditorías dentro de las organizaciones para verificar los procesos, y
particularmente, aquellos relacionados a los sistemas informáticos que se desarrollan dentro de un
área de TI, es necesario contar con un modelo que permita realizar la automatización de procesos
para tenerlos bien claros, plasmarlos dentro de documentos y hacerlos del conocimiento del
personal involucrado.
Actualmente muchas empresas no cuentan con una definición clara de roles dentro del personal,
ni con la definición de actividades precisa para que cada miembro del equipo de desarrollo sepa
las actividades que debe realizar. En el caso de la descripción de los roles es de suma importancia
ya que en ocasiones el personal desarrollador renuncia a la empresa y no deja ningún documento
que explique los módulos y clases que intervinieron dentro de su elaboración, por lo que el
personal que se hará cargo de dichos sistemas tiene que explorar el código para encontrar
soluciones y poder modificarlo en caso de que sea necesario, sin embargo, este proceso lleva
tiempo, el cual puede emplear para sus actividades habituales.
Es por ello que, en el presente trabajo, se analizará un caso de estudio de un organismo
gubernamental al que denominamos Xcom. Éste cuenta con un área de Tecnología de la
Información (TI) llamada Gerencia de Desarrollo de Sistemas Informáticos (GDSI), la cual
necesita contar con un mayor control en documentación de actividades y roles, definición de
procesos, aumento en la productividad y mejor calidad en los productos de software, por lo que
se propondrá la implementación del modelo CMMI® en su nivel 2 para crear procesos más
eficientes y lograr una mayor administración en la información que se debe tener de cada uno de
los productos informáticos que se desarrollan en la gerencia. El modelo CMMI® también se usará
con el Manual Administrativo de Aplicación General en las materias de Tecnología de la
Información (MAAGTICSI), que es la regulación para el control de las actividades
correspondientes a las áreas de TI.
14
La propuesta que se presentará a continuación consiste en la implementación de un Programa de
Mejora (PM) que estandarice los procesos de la GDSI mediante la aplicación del modelo de
CMMI® en nivel 2, especialmente dentro de las actividades desempeñadas en el desarrollo de
software.
CMMI® en su nivel 2 proporciona un área de proceso llamada Medición y Análisis, que permitirá
el uso de métricas que ayudarán a evaluar el desempeño de las actividades, así como verificar el
cumplimiento de metas, lo cual no se considera actualmente en la GDSI.
Se planteará principalmente el estado actual de la GDSI, utilizando el Modelo IDEAL. Mientras
que para definir las acciones que se llevaran a cabo dentro del PM, se incluirán actividades,
herramientas, formatos y estándares aplicables, se identificarán los procesos de la GDSI, se
definirán métricas para la evaluación de calidad y eficiencia de los aplicativos y se adaptará la
forma de trabajo al nuevo PM incluyendo a todo el personal que interviene en el desarrollo de un
producto de software.
Por último, se mostrará como la implementación del modelo CMMI® nivel 2 sirve para mejorar
la manera de trabajar de la GDSI y con base en los resultados es posible ampliar su aplicación a
las demás áreas de Xcom. Lo que se demostrará en esta tesis, es que la implementación del
modelo CMMI® brinda muchos beneficios a un área de TI dentro de los organismos
gubernamentales comprobando la eficiencia y calidad de los aplicativos con la implementación
de este modelo. Todo ello para que no sólo se pueda implementar dentro de un organismo
gubernamental, sino que pueda aplicarse a cualquier área de informática del sector público.
15
CAPÍTULO 1. MARCO CONTEXTUAL Y PLANTEAMIENTO
DEL PROBLEMA
1.1. Planteamiento del Problema
En las áreas de TI de la organización Xcom, en particular, en la Gerencia de Desarrollo de
Sistemas Informáticos se tiene un Sistema Integral de Gestión de Servicios (SIGS) que controla
todos los desarrollos informáticos menores que se utilizan en varias sucursales encargadas de
realizar cobros para Xcom.
El SIGS abre paso a más de 100 aplicaciones, cada una de ellas es un servicio de las sucursales, y
está abierto a nivel nacional en los 32 estados de la República Mexicana, disponibles también en
zonas rurales. Sin embargo, al solicitar un nuevo desarrollo, las áreas solicitantes no realizan el
requerimiento de una manera apropiada y la GDSI no lo recibe correctamente. Lo cual genera
que:
La atención de solicitudes de desarrollo y mantenimiento siguen procesos no uniformes y
con distintos niveles de madurez y control.
No se cuenta con suficientes indicadores objetivos para evaluar el desempeño como área o
como acuerdos de servicio.
El tiempo para la resolución de solicitudes (desde que se recibe una solicitud hasta que se
da por resuelta y terminada) es elevado.
El tiempo estimado para cada resolución se calculan a juicio de un experto y muchas
veces se ven afectado por causas externas al área, tales como cambios de prioridad.
No se cuenta con un inventario confiable de políticas, formatos, guías, manuales técnicos,
etc. (activos de procesos).
Aunque se tiene claridad en la necesidad de implementar mejoras en los procesos, la
operación no permite asignar recursos, ni se cuenta con la experiencia para estructurar un
programa de mejora.
No se cuenta con un inventario real de la descripción de cada uno de los roles dentro del
área, así como de las actividades que desempeña cada miembro.
16
Estos problemas causan cuellos de botella que se van desde la subdirección de desarrollos
informáticos hasta la GDSI. Inician desde que se recibe el requerimiento (que no tiene un formato
estándar) de cualquier área, de diversas formas y por diversos medios. En la mayoría de los casos,
la petición es ambigua.
Otro problema es que los ambientes de desarrollo regularmente no cuentan con las mismas
características que los de producción. La liberación a producción de los sistemas siempre trae
algún problema por incompatibilidad de configuración, así como por herramientas y frameworks
usados en el desarrollo.
1.2. Pregunta de Investigación e Hipótesis
¿Cuáles son los efectos de la implementación de CMMI nivel 2 a la productividad de la Gerencia
de Desarrollo de Sistemas Informáticos de la organización Xcom?
Hipótesis: Dado que los procesos de desarrollo de software dentro de la empresa Xcom no se
encuentran propiamente documentados; la implementación de CMMI nivel 2 ayudará a
incrementar la productividad de la GDSI.
1.3. Objetivo de la Investigación
Proponer un programa de mejora con la finalidad de estandarizar y documentar los procesos y
servicios principales de la GDSI de la organización Xcom usando el modelo CMMI nivel 2.
17
1.4. Justificación
En años recientes, las empresas se han percatado de la necesidad de implementar metodologías y
cumplir estándares que les permitan mejorar sus procesos y adoptar mejores prácticas para el
desarrollo de software. Algunos de estos estándares y mejores prácticas son: ITIL, COBIT, ISO
27000, CMMI, Moprosoft, PSP (Personal Software Process), TSP (Team Software Process),
ISO/IEC 15504, PMBOK y SWEBOK ( Ruiz, E. M. M., Granda, W. X. B., & Sarmiento, P. A.
Q., 2017).
En un informe llamado “The Standish Group, 2003” (Jiménez Romero & Aparicio Álvarez,
2009) que trata sobre el éxito de los proyectos de desarrollo de software y cuyo fundamento
principal consistió en las respuestas a una serie de encuestas que se realizaron a los encargados de
tales proyectos, las cuales arrojaron los siguientes resultados:
-El 30% de los proyectos llegaban a cancelarse.
-El 54% de los proyectos excedían ampliamente tiempos y costos estimados inicialmente.
-El 16% de los proyectos concluían de manera exitosa con normalidad en el tiempo,
funcionalidad y costos.
Es por ello por lo que se pretende día con día mejorar esas cifras mediante la implementación de
los estándares mencionados anteriormente.
El Software Engineering Institute (SEI) cuenta en su sitio web con un informe donde se muestran
datos y estadísticas de las empresas que reportan las evaluaciones al SEI. En un informe del año
2010 se contabilizó un total de 5499 evaluaciones en 4468 empresas, de las cuales no todas son
compañías estadounidenses sino también mexicanas.
Esta investigación servirá para coadyuvar el crecimiento de la productividad dentro de la empresa
Xcom. Derivado de esta investigación, se beneficiará a todo el personal involucrado de la GDSI,
así como a los clientes internos y externos de Xcom que solicitan soluciones de software de
calidad.
18
El presente trabajo servirá de precedente para aquellas empresas del sector gobierno que quieran
implementar CMMI en un área de TI.
La razón por la que se utiliza CMMI y no otro modelo, resulta de la evaluación de modelos
presentada por Manuel de la Villa, Mercedes Ruiz e Isabel Ramos, en su artículo bajo el tema
“Modelos de Evaluación y Mejora de Procesos: Análisis Comparativo” (De la Villa, M. y Ruiz,
M., 2004), en donde se explica que CMMI está por encima de varios modelos para la mejora de
procesos y entre las fortalezas que este autor comenta destacan las siguientes:
Inclusión de las prácticas de institucionalización, que permiten asegurar que los procesos
asociados con cada área de proceso serán efectivos, repetibles y duraderos.
Guía paso a paso para la mejora, a través de niveles de madurez y capacidad (frente a
ISO).
Transición del ‘aprendizaje individual’ al ‘aprendizaje de la organización’ por mejora
continua, lecciones aprendidas y uso de bibliotecas y bases de datos de proyectos
mejorados.
Contiene prácticas genéricas y áreas de proceso de ingeniería que aportan un camino de
mejora de la capacidad de cada área de proceso en la representación continua con
respuesta rápida y guiada a nuevas demandas de las necesidades del negocio y que
permite la priorización de los esfuerzos y la puesta en marcha de funciones de gestión de
proyectos, que darán soporte al resto del proceso.
19
CAPÍTULO 2. MARCO TEÓRICO
2.1. MAAGTICSI
Los Manuales de Aplicación General son documentos que se desarrollaron con la finalidad de
establecer lineamientos y homologar los procesos y procedimientos en todas las dependencias de
la Administración Pública Federal para las áreas de informática se estableció el MAAGTICSI, el
cual muestra los procesos para la administración y desarrollo del hardware y software del
organismo (Diario Oficial de la Federación, 2016).
Dicho manual consiste en conformar tres grupos que a su vez constan de procesos necesarios para
desarrollar un ágil y oportuno manejo de las actividades dentro de las Tecnologías de la
Información y Comunicación (TIC), sumando en total de 9 procesos en los cuales se muestran
factores críticos, responsables y actividades que cada persona debe llevar a cabo para lograr su
cumplimiento.
Este manual se publicó en el Diario Oficial de la Federación (DOF) el 13 de julio de 2010 y entró
en vigor entró en vigor el 20 de agosto del 2010, su aplicación es obligatoria para toda la
Administración Pública Federal (APF).
Para cada una de las áreas de conocimiento se utilizan los principales estándares y mejores
prácticas relacionadas para cada una de ellas. El objetivo de este manual es el definir los
procesos con los que en los términos de TIC y de Seguridad de la Información, las instituciones
deberán regular su operación, independientemente de la estructura organizacional que se posea y
de las metodologías y/o modelos que se encuentren implementados dentro de la organización.
20
2.1.1. Ventajas y desventajas de MAAGTICSI
Moisés Macías, CIO del Fondo de Capitalización e Inversión del Sector Rural (FOCIR),
menciona que una de las ventajas del MAAGTICSI es la iniciativa que persiguió el Gobierno
Federal (GF) para estandarizar la operación la gestión de los recursos de las instituciones, a través
de un enfoque de mejores prácticas de modelos internacionales, con la cual, se puede conseguir
una optimización en el aprovechamiento de los recursos tecnológicos así como poder ordenar y
clarificar las actividades diarias dentro de un área de sistemas (Medrano Macías, 2012).
Por otro lado, el mismo autor señala que una desventaja principal del MAAGTICSI es que las
organizaciones tienen características diferentes, ya que no todas poseen la misma estructura, los
mismos procesos e incluso el mismo presupuesto autorizado. Es por ello por lo que el autor
recomienda que al implementar el MAAGTICSI, se debe evaluar de una manera objetiva el
alcance de la implementación con respecto al tamaño de la institución y las características
principales de la misma.
21
2.1.2. Procesos del MAAGTICSI
MAAGTICSI se compone de tres grupos cada uno contiene procesos tal como se ilustra a
continuación en la figura 1:
Figura 1. Procesos MAAGTICSI. Fuente: Comisión Intersecretarial para el Desarrollo del
Gobierno Electrónico, 2017
A continuación, se explicará en qué consiste cada uno de los procesos, las actividades a realizar y el
indicador del cumplimiento de cada uno de ellos. La información se obtiene del Diario Oficial de la
Federación, directamente del MAAGTICSI, publicado el 04 de Febrero del 2016 (Diario Oficial de la
Federación, 2016), dentro de este se puede encontrar más información referente a cada proceso, tal
Gobernanza
PE-Proceso de Planeación Estratégica
APCT-Administración del Presupuesto y las Contratacioens
Organización
ADS-Proceso de Administración de Servicios
ACNF-Proceso de Administración de la Configuración
ASI-Proceso de Administración de la Seguridad de la Información
Entrega
ADP-Proceso de Administración de Proyectos
APRO-Proceso de Administración de Proveedores
AOP- Proceso de Administración de la Operación
OPEC-Operación de Controles de Seguridad de la Información y del Equipo de Respuesta a
Incidentes de Seguridad en TIC (ERISC)
22
como los objetivos específicos y generales, roles, factores críticos de cada actividad y los productos
que se generan.
2.1.2.1. Gobernanza
PE – PROCESO DE PLANEACIÓN ESTRATÉGICA
En este proceso se pretende mantener la operación de un modelo de gobierno de TI en la institución,
para efectuar el análisis de aprovechamiento de las TI y su planeación estratégica, así como asegurar
la adecuada organización al interior de la Unidad Administrativa de Tecnologías de la Información y
Comunicaciones (UTIC).
Actividades del proceso
PE 1. Establecer la gobernabilidad de las operaciones de la UTIC
PE 2 Integrar la información de la Cartera Ejecutiva de Proyectos de TIC.
PE 3 Validar, aprobar, comunicar y adecuar, de ser necesario, la Cartera Ejecutiva de Proyectos de
TIC.
PE 4 Dar seguimiento a la planeación estratégica de TIC.
Indicador del proceso
Por cada uno de los proyectos en la Cartera Ejecutiva de Proyectos de TIC, se deberá aplicar la
fórmula descrita a continuación:
% 𝐄𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 𝐞𝐧 𝐥𝐚 𝐞𝐣𝐞𝐜𝐮𝐜𝐢ó𝐧 𝐝𝐞𝐥 𝐩𝐫𝐨𝐲𝐞𝐜𝐭𝐨 =Avance real
Avance estimado𝑥 100 (1. 1)
Una vez realizado el cálculo de cada uno de los proyectos que integran la Cartera Ejecutiva de
Proyectos de TIC, se deberá realizar el siguiente cálculo, conforme a la fórmula 1.2:
23
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 𝐞𝐧 𝐥𝐚 𝐞𝐣𝐞𝐜𝐮𝐜𝐢ó𝐧 𝐝𝐞 𝐥𝐨𝐬 𝐩𝐫𝐨𝐲𝐞𝐜𝐭𝐨𝐬 = Promedio de la eficiencia de cada proyecto (1.2)
APCT- ADMINISTRACIÓN DEL PRESUPUESTO Y LAS CONTRATACIONES
En este proceso se coordinan las acciones para el ejercicio del presupuesto destinado a las TI, a fin de
maximizar su aplicación en las contrataciones de las mismas requeridas por cada institución, así como
las acciones para efectuar el acompañamiento necesario a las unidades facultadas para realizar los
procedimientos de contrataciones en la institución, de manera que se asegure su ejecución en tiempo y
forma, alineado al presupuesto autorizado; así como el seguimiento a los contratos que se celebren.
Actividades del proceso
APCT 1. Participar en el establecimiento de prioridades del presupuesto de TIC.
APCT 2 Establecer el listado de bienes y servicios de TIC a contratar por la UTIC en cada ejercicio
fiscal.
APCT 3 Estudios de Factibilidad.
APCT 4 Participar como área técnica, en los procedimientos de contratación de TIC.
Indicador del Proceso
Para el cálculo de eficiencia en este proceso, se utiliza la fórmula 1.3, descrita a continuación:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Número de estudios de factibilidad favorables
Número de estudios de factibilidad presentados a la Unidad 𝑥 100 (1. 3)
24
2.1.2.2. Organización
ADS- PROCESO DE ADMINISTRACIÓN DE SERVICIOS
En este punto se definen los compromisos y costos de los servicios de TI necesarios para mantener el
adecuado funcionamiento de la Institución, así como identificar iniciativas de servicios de TIC que
aporten beneficios importantes en el cumplimiento de los objetivos estratégicos de la Institución, con
apego a la EDN y efectuar su instrumentación.
Actividades del proceso
ADS 1. Mantener actualizado el catálogo de servicios de TIC.
ADS 2. Diseñar los servicios de TIC.
ADS 3. Administrar la capacidad de la infraestructura de TIC.
ADS 4. Administrar la continuidad de servicios de TIC.
Indicador de proceso
Para este proceso se utiliza la fórmula 1.4 para el cálculo del cumplimiento.
% 𝐝𝐞 𝐜𝐮𝐦𝐩𝐥𝐢𝐦𝐢𝐞𝐧𝐭𝐨 =Número de revisiones efectuadas
Número de evaluaciones del periodo que se reporta 𝑥 100
(1. 4)
ACNF- PROCESO DE ADMINISTRACIÓN DE LA CONFIGURACIÓN
En este proceso se encargan de establecer y actualizar un repositorio de configuraciones, en el que se
integren las soluciones tecnológicas y sus componentes, así como la información funcional y técnica
de estos y la relativa a los diversos ambientes y arquitecturas tecnológicas de la UTIC, como
elementos de configuración, con la finalidad de facilitar su acceso a los involucrados en los procesos
de la UTIC, cuando éstos así lo requieran para la operación del proceso respectivo.
25
Actividades del proceso
ACNF 1. Establecer la cobertura y el alcance de la administración de la configuración.
ACNF 2. Definir la estructura del repositorio de configuraciones.
ACNF 3. Registrar los elementos de configuración en el repositorio de configuraciones
Indicador del proceso
En este proceso se evalúa las revisiones en el repositorio de configuraciones, tal como se muestra en
la fórmula 1.5.
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Número de revisiones efectuadas
Número de revisiones programadas x 100 (1.5)
ASI- PROCESO DE ADMINISTRACIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
Dentro de este proceso se establecen y vigilan los mecanismos que permitan la administración de la
seguridad de la información de la institución, así como la disminución del impacto de eventos
adversos, que potencialmente podrían afectar el logro de los objetivos de la Institución o constituir
una amenaza para la Seguridad Nacional.
Actividades del proceso
ASI 1. Establecer un modelo de gobierno de seguridad de la información.
ASI 2. Operar y mantener el modelo de gobierno de seguridad de la información.
ASI 3. Diseño del SGSI.
ASI 4. Identificar las infraestructuras de información esenciales y, en su caso, críticas, así como los
activos clave.
ASI 5. Elaborar el análisis de riesgos.
ASI 6. Integrar al SGSI los controles mínimos de seguridad de la información.
ASI 7. Mejorar el SGSI.
26
2.1.2.3. Entrega
ADP- PROCESO DE ADMINISTRACIÓN DE PROYECTOS
En este proceso se administra la cartera operativa de proyectos de TI, a fin de optimizar la aplicación
de los recursos y obtener mayores beneficios para la institución.
Actividades del proceso
ADP 1. Establecer directrices para la gobernabilidad y evaluación de la Cartera Operativa de
Proyectos de TIC.
ADP 2. Identificar y documentar iniciativas de TIC (derogado).
ADP 3. Priorizar, equilibrar y autorizar la Cartera Operativa de Proyectos de TIC.
ADP 4. Administrar y monitorear la Cartera Operativa de Proyectos de TIC.
ADP 5. Monitorear el desarrollo de los proyectos de TIC y sus programas (derogado).
ADP 6. Cerrar iniciativas y proyectos de TIC.
Indicador del proceso
En este proceso, para el cálculo de la eficiencia se utiliza la fórmula 1.6, indicada a continuación:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Número de proyectos pertenecientes − número de proyectos cancelados
Número total proyectos pertenecientes x100 (1.6)
APRO- PROCESO DE ADMINISTRACIÓN DE PROVEEDORES
Dentro de este proceso se maneja un mecanismo que permita verificar el cumplimiento de las
obligaciones derivadas de los contratos celebrados para la adquisición, arrendamiento o servicios de
TI.
27
Actividades del proceso
APRO 1. Generar lista de verificación de obligaciones.
APRO 2. Monitorear el avance y desempeño del proveedor.
APRO 3. Apoyo para la verificación del cumplimiento de las obligaciones de los contratos.
Indicador del proceso
Dentro de este proceso, para el cálculo de la eficiencia se utiliza el número de revisiones de avance y
conclusión, por lo que se debe implementar la formula 1.7.
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Número de revisiones de avance y conclusión ejecutadas
Número de revisiones de avance y conclusión programadas 𝑥 100 (1.7)
AOP- PROCESO DE ADMINISTRACIÓN DE LA OPERACIÓN
Para este proceso se hace entrega a los usuarios los servicios de TI, conforme a los niveles de servicio
acordados y con los controles de seguridad definidos.
Actividades del proceso
AOP 1. Establecer el mecanismo de operación y mantenimiento de los sistemas, aplicaciones,
infraestructura y servicios de TIC.
AOP 2. Programar y ejecutar las tareas de la operación de los sistemas, aplicaciones y servicios de
TIC.
AOP 3. Monitorear la infraestructura de TIC en operación.
AOP 4. Implementar y verificar que se cumplan los controles de seguridad física en el centro de
datos.
AOP 5. Elaborar y dar seguimiento al programa de aprovisionamiento de la infraestructura
tecnológica (derogado).
AOP 6. Mantener los recursos de infraestructura tecnológica y su disponibilidad. (Derogado)
28
Indicador del proceso
Para el cálculo de la eficiencia en este proceso, se utilizará la fórmula 1.8, que se describe a
continuación:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Incidentes en la operación resueltos
Incidentes que se presentaron en el ambiente operativo 𝑥 100 (1.8)
OPEIC- OPERACIÓN DE CONTROLES DE SEGURIDAD DE LA INFORMACIÓN Y DEL
EQUIPO DE RESPUESTA A INCIDENTES DE SEGURIDAD EN TIC (ERISC)
Para este proceso se implementan y operan los controles de seguridad de la información de acuerdo
con el programa de implementación del SGSI, así como los correspondientes a la capacidad de
respuesta a incidentes.
Actividades del proceso
OPEC 1. Designar un responsable de la supervisión de la implementación de los controles de
seguridad definidos en el SGSI y en el análisis de riesgos.
OPEC 2. Establecer los elementos de operación del ERISC.
OPEC 3. Operación del ERISC en la atención de incidentes.
OPEC 4. Implementar los controles de mitigación de riesgos y los controles del SCSI (Derogado)
OPEC 5. Implementar los controles del SCSI relacionados con los dominios tecnológicos del TIC
(Derogado).
OPEC 6. Revisar la operación del SCSI (Derogado).
OPEC 7. Aplicar al SCSI las mejoras que defina el grupo estratégico de seguridad de la información
(Derogado).
29
PE
• Titular de la UTIC.
• Responsable de la Planeación Estratégica de la UTIC.
• Grupo de Trabajo para la dirección de TI.
APCT
• Responsable del Proceso de Administración del Presupuesto y las Contrataciones.
• Responsable del seguimiento del presupuesto autorizado de TI.
• Responsable del listado de bienes y servicios de TI.
ADS
• Responsable del proceso de Administración de Servicios (ADS) y administrador del catálogo de servicios de TI.
• Grupo de trabajo para la dirección de TI.
• Responsable del diseño de servicios de TI.
• Responsable de la Planeación Estratégica de la UTIC.
• Responsables de los servicios de TI en operación.
ACNF• Responsable del proceso de Administración de la Configuración (ACNF)
Indicador del proceso
Para el cálculo de la eficiencia en este proceso, se utilizará la fórmula 1.9, la cual se describe a
continuación:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =Controles implementados en operación de acuerdo a su definición
Total de Controles implementados 𝑥 100 (1.9)
2.1.3. Roles y Responsabilidades del MAAGTICSI
En cada uno de los procesos, se cuenta con roles y responsabilidades específicas, las cuales se
muestran a continuación en la figura 2:
30
Figura 2. Roles y Responsabilidades MAAGTICSI. Fuente: Comisión Intersecretarial para
el Desarrollo del Gobierno Electrónico, 2017
Las responsabilidades se pueden indicar dentro de la siguiente matriz, donde se tienen un listado de
todos los roles descritos en la figura 3. Se indica, además, de cada uno de los procesos quien es el
responsable principal, quien aprueba, a quien se le consulta y a quien solamente se le informa,
conforme a las siguientes abreviaturas:
ASI
• Responsable de la seguridad de la información en la institución o RSII.
• Grupo estratégico de seguridad de la información o GESI
• Equipo de trabajo de infraestructuras críticas
• Equipo de Trabajo de análisis de riesgos
• Equipo de respuesta a incidentes de seguridad o ERISC
AOP• Responsable del Proceso de Administración de la Operación (AOP).
• Responsable del mantenimiento de la infraestructura.
ADP
• Grupo de trabajo para la dirección de TI
• Responsable del proceso y administración de la cartera operativa de proyectos de TI
• Administradores de proyectos de TI.
APRO• Responsable del proceso de administración de proveedores.
• Administradores de contrataciones.
OPEC
•Responsable de la supervisión de la implementación de los controles de seguridad de la información y de manejo de riesgos.
•Responsables de la implementación de los controles de seguridad de la información y de manejo de riesgos.
•ERISC
31
Figura 3. Matriz de responsabilidades MAAGTICSI. ([R] Responsable, [A] Aprueba, [C]
Consultado, [I] Informado). Fuente: Comisión Intersecretarial para el Desarrollo del
Gobierno Electrónico, 2017
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 5 6 7
Titular de la UTIC. A
Responsable de la Planeación Estratégica de la UTIC. R R R R
Grupo de Trabajo para la dirección de TI. C
Responsable del Proceso de Administración del Presupuesto y las
Contrataciones.R A
Responsable del seguimiento del presupuesto autorizado de TI. R R
Responsable del listado de bienes y servicios de TI. C C R
Responsable del proceso de Administración de Servicios (ADS) y
administrador del catálogo de servicios de TI.R
Grupo de trabajo para la dirección de TI. I I I I
Responsable del diseño de servicios de TI. R C A
Responsable de la Planeación Estratégica de la UTIC. A
Responsables de los servicios de TI en operación R
Responsable del proceso de Administración de la Configuración
(ACNF)R R R
Responsable de la seguridad de la información en la institución o RSII. R A
Grupo estratégico de seguridad de la información o GESI R R R R R R
Equipo de trabajo de infraestructuras críticas C C
Equipo de Trabajo de análisis de riesgos I
Equipo de respuesta a incidentes de seguridad o ERISC C C C C C
Responsable del Proceso de Administración de la Operación (AOP). R A
Responsable del mantenimiento de la infraestructura. R R R
Grupo de trabajo para la dirección de TI A
Responsable del proceso y administración de la cartera operativa de
proyectos de TIR R R
Administradores de proyectos de TI. C R
Responsable del proceso de administración de proveedores. C C
Administradores de contrataciones. R R R
Responsable de la supervisión de la implementación de los controles de
seguridad de la información y de manejo de riesgos.C
Responsables de la implementación de los controles de seguridad de la
información y de manejo de riesgos.R C C R
ERISC
ADP APRO OPECPE APCT ADS ACNF ASI AOP
32
Aprendizaje
Documentar y analizar las lecciones
Revisar el enfoque de la organizacion
Iniciacion
Estimulo para la mejora
Establecer contexto, patrocinador e infraestructura
Diagnóstico
Evaluar la práctica actual
Desarrollar recomendacines y documentar los resultados de la fase
Establecimiento
Establecer reglas y prioridades
Establecer equipos de acción y planificar acciones
Actuación
Planificar, ejecutar y hacer seguimiento de actividades
Planificar y ejecutar proyectos piloto
Definir los procesos y las medidas
2.2. Modelo Ideal
Para la implementación de la metodología CMMI® se tomará como base el modelo IDEAL.
Este modelo pretende dar respuesta a la pregunta: ¿Qué debo hacer una vez evaluados mis
procesos, para iniciar un programa de mejora y que actividades debe incluir dicho programa? El
modelo IDEAL, pretende marcar el camino de acciones que deben formar parte del programa de
mejora de procesos de software cuando una organización desea llevar a cabo las buenas prácticas
para llevar a cabo una mejor operación dentro de la empresa.
IDEAL es el acrónimo que corresponde a las iniciales de las cinco fases del modelo, tal como se
muestra en la figura 4:
I: Initiating (Iniciación)
D: Diagnostic (Diagnóstico)
E: Estabilishing (Establecimiento)
A: Acting (Actuación)
L: Learning (Aprendizaje)
Figura 4. Modelo IDEAL iterativo (SEI, 1996)
33
2.2.1. Fase de iniciación (Initiating)
A continuación, se definirá cada una de las etapas del modelo ideal, las cuales fueron tomadas del
manual del Software Engineering Institute (SEI), titulado “MODELO IDEAL”. (McFeeley,
1996).
Las actividades que componen esta fase son necesarias para el éxito en todo el programa de
mejora que se desee implementar ya que aquí se establecen las bases del trabajo a realizar.
Comienza con un reconocimiento de las necesidades de cambio dentro del área que se desea
mejorar. Mientras más evidentes sean estas necesidades mayor aceptación y posibilidad de éxito
tendrá el cambio.
Considerando las razones para iniciar el cambio es necesario establecer las metas y objetivos del
trabajo a realizar, evaluar la forma en que se afectará el trabajo y los beneficios que se esperan
obtener. También es necesario contar con un apoyo efectivo de la dirección desde que se inicia el
programa. Para ello es necesario que la dirección brinde una atención directa y tenga compromiso
con el programa, ya que de ello depende la disponibilidad de recursos, la infraestructura y la
priorización del proyecto de mejoramiento.
Dentro de la fase de inicio (Initiating) se tienen las siguientes actividades para la identificación de
los objetivos de negocio:
• Identificar los principales problemas a resolver
• Obtener el compromiso y el patrocinio de la dirección
• Informarse sobre métodos de mejora
• Comunicar la iniciativa a la organización
34
Para poder llevar a cabo la mejora de procesos se deberán realizar tres grupos los cuales se
describen a continuación:
Definición y despliegue
• Grupo Directivo “Habilitador”: Management Steering Group (MSG)
• Grupo de Ingeniería de Procesos “Facilitador”: Engineering Process Group (EPG)
• Grupo de Trabajo Técnico “Desarrollador”: Technical Working Group (TWG)
Seguimiento
• Grupo de Aseguramiento de Calidad: “Revisor / Auditor”
2.2.2. Fase de diagnóstico (Diagnostic)
El objetivo de esta fase es obtener un entendimiento completo del trabajo a realizar para lo cual
es necesario caracterizar el estado actual de la empresa y el estado futuro. Por lo general esta
evaluación se realiza con base en algún modelo de referencia como puede ser CMMI®.
Como resultado de la evaluación se proponen recomendaciones que sirven para definir las
actividades siguientes del programa y que influyen en las decisiones que debe tomar la gerencia.
En la etapa de diagnóstico se realiza lo siguiente:
• Establecer la madurez de la organización
• Identificar las fortalezas
• Identificar áreas de mejora
• Definir recomendaciones de mejora
35
2.2.3. Fase de establecimiento (Establishing)
Durante esta fase se elabora un plan detallado con acciones específicas, entregables y
responsabilidades para el programa de mejora basado en los resultados del diagnóstico y en los
objetivos que se quieren alcanzar. Para elaborar el plan se deben definir las prioridades para el
esfuerzo de mejora, para ello se consideran los recursos, dependencias, factores externos y
necesidades de la organización. Posteriormente se identifica el enfoque a seguir considerando las
prioridades y los resultados del diagnóstico. Adicionalmente se definen las métricas que
permitirán medir el progreso alcanzado y se comienzan a definir y capacitar a los grupos técnicos
de trabajo que desarrollarán los procesos.
En la fase de establecimiento se debe:
• Desarrollar los planes estratégicos de mejora de procesos
• Establecer las metas de mejora
• Desarrollar los planes tácticos para abordar las recomendaciones
36
2.2.4. Fase de Actuación (Acting)
Es la fase que más tiempo y recursos consume ya que es cuando se implementan las acciones que
han sido planeadas. La fase inicia con la definición de la solución que cubre los objetivos de la
organización. La solución comprende: herramientas, procesos, habilidades, asesorías e
información y generalmente es desarrollada por los grupos técnicos de trabajo que se
establecieron. La solución propuesta es probada en proyectos pilotos y posteriormente refinada
para reflejar la experiencia, conocimiento y lecciones aprendidas en las pruebas.
El proceso se itera hasta obtener una solución satisfactoria que funcione, sin esperar a que sea
perfecta. Finalmente, la solución obtenida se comienza a implantar en la organización.
En la fase de actuación principalmente se enlistan las siguientes actividades:
• Definir los procesos
• Definir las mediciones
• Usar o desarrollar herramientas
• Pilotear los nuevos procesos y las mediciones
• Refinar los procesos
• Institucionalizar los procesos y las mediciones
37
2.2.5. Fase de Aprendizaje (Learning)
Esta fase cierra el ciclo de mejora y su objetivo es garantizar que el próximo ciclo sea más
efectivo. Durante la misma se revisa toda la información recolectada en los pasos anteriores y se
evalúan los logros y objetivos alcanzados para lograr implementar el cambio de manera más
efectiva y eficiente en el futuro.
Las lecciones aprendidas deben quedar documentadas. Adicionalmente deben re-evaluarse las
metas del negocio y verificar su cumplimiento, así como proponer mejoras para las siguientes
etapas del proceso.
Dentro de la fase de aprendizaje se tienen las siguientes actividades:
• Identificar las lecciones aprendidas
• Analizar las lecciones aprendidas
• Medir el esfuerzo dedicado
• Reforzar el compromiso y el patrocinio
• Planificar el siguiente ciclo de mejora
Para tener un entendimiento más claro de las 5 etapas del modelo IDEAL, se puede visualizar un
enlistado de las etapas, tal como se muestra en la tabla 1.
38
Tabla 1. Modelo IDEAL enlistado. (SEI, 1996)
I Iniciar
1. Fijar el contexto
2. Estructurar el equipo
3. Definir infraestructura
D Diagnosticar
1. Caracterizar los estados actuales y
los deseados
2. Desarrollar recomendaciones
E Establecer
1. Crear la solución
2. Ejecutar proyecto piloto de la
solución
3. Refinar la solución
4. Implementar la solución
A Actuar
1. Fijar las prioridades
2. Desarrollar el acercamiento
3. Planificar las acciones
L Aprender 1. Analizar y validar
2. Proponer futuras acciones
39
2.3. Capability Maturity Model Integration (CMMI®)
CMMI® es el acrónimo de Capability Maturity Model Integration y consiste en una serie de
modelos que contienen las mejores prácticas para ayudar a las organizaciones a mejorar sus
procesos. Es una guía que ayuda en la mejora de procesos y el enfoque del modelo permite
evolucionar desde un proceso en crisis a un proceso controlado, estandarizado, medido y
optimizado que sienta las bases de la mejora continua y permite a la organización adoptar nuevas
prácticas sobre un proceso estable y controlado.
Según el modelo que se utilice se puede obtener el documento con un conjunto de guías que
ayudan en:
Desarrollo y mantenimiento de productos y servicios (CMMI® DEV)
Adquisición de productos y servicios (CMMI® ACQ)
Establecimiento, entrega y gestión de los servicios (CMMI® SVC)
Entre las características del modelo CMMI®, se encuentran las siguientes:
Contiene elementos esenciales de un proceso efectivo y propone una forma de adopción
para las organizaciones que permite incrementar la calidad y productividad, al tiempo que
controla el presupuesto y los compromisos establecidos. Cada una debe interpretar,
adoptar y aplicar aquellas prácticas que le apoyan en el logro de sus objetivos y
cumplimiento de sus necesidades de manera eficiente (Kulpa & Johnson, 2008).
Considera dos enfoques o rutas para adoptar las mejoras y medir el nivel en que han
evolucionado y se conocen como representaciones. En una forma se consideran áreas de
proceso de manera individual y se califican en niveles de capacidad de acuerdo con la
representación continua. El otro enfoque considera un conjunto preestablecido de áreas de
proceso que constituyen un nivel de madurez y que es la forma de evaluar la
representación escalonada o por etapas.
40
Está estructurado para facilitar su uso en elementos que definen la forma y modo de
aplicarlo, considerando los elementos que son obligatorios, sugeridos o el material
informativo en las áreas de proceso. En general el documento se puede revisar en función
de metas, prácticas y subprácticas con el resto del material informativo.
CMMI® cuenta con una estructura definida, cada área de proceso se divide en objetivos
específicos (SG) y objetivos genéricos (GG), los cuales a su vez se dividen en prácticas
específicas y genéricas respectivamente, tal como se puede apreciar en la figura 5.
Figura 5. Estructura de CMMI® (Ramirez Luján, Rodriguez Baryolo, & Molina Villalobos,
2010)
CMMI® es utilizado por las organizaciones para entender las mejores prácticas de la industria,
para priorizar y adoptar las mejoras a los procesos existentes, para compararse con su
competencia dentro del mercado o para que los clientes puedan identificar las prácticas que
necesitan demostrar sus proveedores.
Niveles de Madurez Área de Proceso
Objetivos Específicos (SG) Objetivos Genéricos (GG)
Prácticas Específicas (SP) Prácticas Genéricas (GP)
41
Siendo un modelo refleja una abstracción de la realidad que permite a las organizaciones adoptar
prácticas útiles para alcanzar sus objetivos de negocio, constituye una referencia no es un proceso
en sí. Para establecer una analogía, querer adaptar la organización al modelo es como si al ver
una maqueta de una casa una persona deseara vivir en ella.
La adecuada interpretación del modelo para cubrir las diferentes situaciones, necesidades y
objetivos de una organización son esenciales para lograr los resultados que se quieren. Muchas
veces por desconocimiento o por falta de sentido común o criterio, el resultado no es lo esperado.
2.3.1. Utilidad de CMMI®
La implementación de CMMI® ha servido para que a nivel mundial las empresas puedan
automatizar sus procesos así como también mejorar la productividad y calidad de sus productos
de software, ya que es importante no solo mejorar los procesos de producción sino también los
más importantes que son los procesos de gestión (Estrada, 2014).
Algunas de las razones por las que es útil implementar CMMI® en las organizaciones son las
siguientes (Kulpa & Johnson, 2008):
Permite actualizarse y ser competitivo en el mercado.
Los niveles de madurez de CMMI® permiten escalar y que la organización siga creciendo,
aun llegando al nivel 5 la mejora continua siempre se hace presente debido a los hábitos
que se crean.
Este modelo incluye ayuda/dirección/ideas sobre la ingeniería de software, ingeniería de
sistemas, ingeniería de hardware y equipos de desarrollo integrados.
Una de las metas principales de CMMI® es permitir a las organizaciones reducir el costo
y la confusión incurrida de múltiples evaluaciones y múltiples programas de mejora para
cubrir las actividades de los sistemas y de ingeniería de software.
42
2.3.2. Casos de éxito en implementación de CMMI® en México
Si bien es cierto, muchas empresas optan por elegir diversos modelos a implementar dentro de
sus organizaciones. Sin embargo, la mayoría de ellas eligen CMMI® para la incorporación de
mejores prácticas, así como incrementar la calidad y productividad de los servicios y/o productos
que ofrecen.
En la revista UNAM, vol. 9, que lleva por título “Implementación de Modelos de Calidad en la
Construcción del Software en México”, se muestra una investigación que consiste en realizar un
diagnóstico del conocimiento y uso actual de CMMI®, mostró que de 114 empresas, el 88%
reporto contar con un proceso de desarrollo definido y aquellas que carecen de algún modelo
están interesadas en la implantación de un modelo de procesos como CMMI® (Gasca, 2018). En
la actualidad existen 70 instituciones certificadas en CMMI® en México, tal como se muestra en
la tabla 2 a continuación:
Tabla 2. Empresas a nivel nacional que implementan CMMI® (Meneses, Padilla, Mora, &
Barrera, 2014)
Empresa Área Certificada Fecha Nivel Estado de
la República
Tecnología de Gestión y Comunicación S.A. de C.V.
Tecnología de Gestión y
Comunicación S.A. de C.V.
07/05/2010 2 CHIH
Saitosoft, S.A. de C.V.
SAITOSOFT – PROJECT
MANAGEMENT AND QUALITY
ASSURANCE AREAS
28/03/2008 2 DF
ITE Soluciones S.A. de C.V. ITE Software
Development Unit 12/06/2009 2 DF
Centro de Inteligencia Competitiva S.A. de C.V.
Centro de Inteligencia
Competitiva (CIC) 25/09/2009 2 DF
Mapdata S.A. de C.V. Technology
Direction 16/10/2009 2 DF
Tecnología, Asesoría, Sistemas, S.A. de C.V.
Development and Support &
13/11/2009 2 DF
43
Consulting Units e-Nfinito e-Nfinito 12/02/2009 2 GTO
Universidad Tecnologica de Leon (UTL)
Serv. Informaticos & Tec. de Informacion
y Comunicacion: Software
Development
17/12/2009 2 GTO
Simbyosis S.C. Software
Development Area 30/04/2010 2 GTO
Computación en Acción, S.A. de C.V.
COMPUTACION EN ACCION, S.A. DE C.V.
07/02/2009 2 JAL
Dw IT Services S.A. de C.V. Software
Development Services
08/01/2010 2 JAL
Ejecutivos en Computación y Servicios S.A. de C.V.
Area de Desarrollo de Software Interna de Compusoluciones
19/03/2010 2 JAL
Tecnología en Informática y Administración S.A. de C.V.
Development Area 15/04/2010 2 JAL
Grupo Embotelladoras Unidas S.A. de C.V.
Systems Department
30/04/2010 2 JAL
linium S.A. Operations and Development
09/08/2007 2 NL
Kernel Technologies Group
Software Development Team
including the Quality Assurance
Team
29/09/2007 2 NL
Tecnologico de Monterrey – VRHTI
Tecnologico de Monterrey – VRHTI
12/12/2008 2 NL
I-place i-place 30/01/2009 2 NL
Consiss S.A. de C.V. Custom Software
Development 28/08/2009 2 NL
T-Systems México, S.A. de C.V.
T-SYSTEMS MEXICO 01/02/2008 2 PUE
Universidad Popular Autónoma del Estado de
Puebla, A.C.(UPAEP)
Dirección de Sistemas de Información
22/05/2009 2 PUE
Vision Software Factory, S.A. de C.V.
Vision Software Factory, S.A. de C.V.
21/12/2007 2 QRO
Business Intelligent Software, SA de CV
Software Development Team
31/08/2007 2 SIN
ARASYS S.A. de C.V. Software
Development Projects
23/11/2007 2 SIN
DpSoft S.A. de C.V. DpSoft Software 30/11/2007 2 SIN
44
Development Team Coppel SA de CV Coppel SA de CV 29/08/2008 2 SIN
Macro Pro S.A. de C.V. Macropro New Developments
12/09/2008 2 SIN
Applied Protocol Interfaces S.A. de C.V.
Custom Software Development and
Software Manteinance
13/11/2009 2 SIN
Factor Informático de Negocios S.A. de C.V.
Operations Unit 23/04/2010 2 SIN
Portillo Firm S. de R.L. de C.V. Consultancy and
Support Units 10/06/2010 2 SIN
Plenumsoft – Servicios y suministros en Informática,
S.A. de C.V
INGENIERIA DE SOFTWARE
24/07/2008 2 YUC
Brainup Systems S.A. de C.V. (Compartida con
Argentina)
BUS Development and Services
17/07/2009 2 DF
Zentrum Ziztemaz S.A. De C.V.
Zentrum Ziztemaz Tijuana
26/11/2009 3 BC
Logica Interactiva S.A. de C.V. Interlogic –
Software Engineering Area
15/09/2009 3 CHIH
Intelligent Network Technologies S.A. de C.V.
Intelligent Network Technologies S.A. de
C.V. 18/09/2009 3 COAH
IDS Comercial S.A. de C.V. IDS Project
Development 14/03/2008 3 DF
Informática Integral Empresarial S.A. de C.V.
Sinersys Technologies
14/03/2008 3 DF
Servicios Telepro, S.A. de C.V. SERVICIOS
TELEPRO, S.A. DE C.V.
29/05/2008 3 DF
Accenture Technology Solutions – Mexico
Accenture – MXDC 22/08/2008 3 DF
HP Company
Mexico City SAT account – Servicio de Aduanas Area –
AGA-Administración General de Aduanas
15/10/2008 3 DF
Blitz Software BLITZ SOFTWARE 20/12/2008 3 DF QuarkSoft S.C. QuarkSoft S.C. 27/02/2009 3 DF
Azertia Tecnologias de la Información México S.A. de
C.V
Azertia Tecnologias de la Información México S.A. de C.V. (Una Empresa de
13/03/2009 3 DF
45
INDRA SISTEMAS S.A.)
Automated Testing and Development Software, S.A.
de C.V. GRUPO TECNIS 03/04/2009 3 DF
Vision Consulting
Software Development and
Maintenance Projects
25/09/2009 3 DF
AsTecI S.A. de C.V. Software
Development and Maintenance
28/01/2010 3 DF
IBM AMS Mexico Grupo Modelo
Account 19/03/2010 3 DF
IBM AMS Mexico Grupo Nacional
Provincial Account 04/06/2010 3 DF
D&T Tecnología S de RL de CV
Deloitte GDC México 31/07/2009 3 GTO
VENTUS Technology S.A. de C.V.
VENTUS Technology 22/03/2008 3 NL
World Software Services Group, SA de CV
World Software Services Group, SA
de CV 25/03/2009 3 NL
AD Infinitum S.A. de C.V.
Software development and implementation
services
14/08/2009 3 NL
SYTECSO, S.A. de C.V Software Factory 28/08/2009 3 NL Expert Sistemas
Computacionales S.A. de C.V. Expert Tecnología 29/08/2009 3 NL
Solutions S de RL de CV – Queretaro Mexico
OPEN ROAD Solutions S de RL de
CV 19/12/2008 3 QRO
ALTEC S.A. de C.V. ALTEC Mexico S.A
de C.V. 19/06/2009 3 QRO
ImagenSoft, S.C. ImagenSoft Projects
Division 03/07/2008 3 SIN
Expresión Informativa y Técnicas Organizadas S.A. de
C.V.
New Developments Division
18/12/2008 3 SIN
Homex S.A. DE C.V IT Deparment 04/06/2010 3 SIN
TSI ARYL S. de R.L. de C.V. QUALISYS –
SYSTEMS AREA 12/09/2008 3 SON
INNEVO S.A. de C.V. Innevo Software
Development Services, Product
07/09/2007 3 JAL
46
Factory
CRS IT Consulting S.A. de C.V. Technical Solution
Implementation Unit
03/07/2009 3 DF
Sieena Software S. de R. L. de C. V.
Sieena Software S. de R. L. de C. V.
17/07/2009 3 COAH, NL
INNEVO Custom Software
Development Unit 11/06/2010 4 JAL
Hildebrando Software Factory
Hildebrando Software Factory
07/09/2007 5 AGS
Ultrasist S.A. de C. V. Ultrasist 28/03/2009 5 DF
Praxis de México
CEDS (Center of Excellence for
Development of Software)
18/12/2009 5 DF
IBM Application
Management Services Mexico
30/03/2010 5 JAL
Softtek GDC Monterrey High
Growth Accounts 04/12/2009 5 NL
SigmaTao Factory, S.A. de C.V.
SigmaTao Factory, S.A. de C.V.
24/08/2007 5 QRO
47
2.3.3. Niveles de CMMI®
El modelo CMMI® se compone de 5 niveles, los cuales se describen a continuación y se
visualizan en la figura 6:
Figura 6. Niveles de Madurez CMMI® (SEI, 2010)
A continuación, se describe cada uno de los niveles de CMMI® de acuerdo con el documento del
SEI en la versión 1.3 citado en este trabajo.
Nivel 1. Inicial
En el nivel de madurez 1, los procesos son generalmente ad hoc y caóticos. La organización
generalmente no proporciona un entorno estable para dar soporte a los procesos. El éxito en estas
organizaciones depende de la competencia y la heroicidad del personal de la organización y no
del uso de procesos probados. A pesar de este caos, las organizaciones de nivel de madurez 1 a
menudo producen productos y servicios que funcionan, sin embargo, exceden con frecuencia el
presupuesto y los plazos planificados. Las organizaciones de nivel de madurez 1 se caracterizan
Nivel de Madurez 1: Inicial
La organización no proporciona un entorno estable para dar soporte a los procesos
Nivel de Madurez 2: Gestionado
Se garantiza la planificación de procesos y su ejecución mediante políticas
Nivel de Madurez 3: Definido
Procesos descritos en estándares, procedimientos, herramientas y
métodos
Nivel de Madurez 4: Gestionado Cuantitativamente
Se establecen objetivos cuantitativos para la calidad y
el rendimiento del proceso para la gestión de
proyectos.
Nivel de Madurez 5: En Optimización
Mejora continua de procesos
48
por una tendencia a comprometerse en exceso, a abandonar sus procesos en momentos de crisis y
a no ser capaces de repetir sus éxitos.
Nivel 2. Gestionado
En el nivel de madurez 2, se garantiza que los procesos de los proyectos se planifican y ejecutan
de acuerdo con las políticas; los proyectos emplean personal cualificado que dispone de recursos
adecuados para producir resultados controlados. Se involucra a las partes interesadas relevantes,
se monitorizan, controlan y revisan y se evalúan en cuanto a la adherencia a sus descripciones de
proceso. La disciplina de proceso reflejada por el nivel de madurez 2 ayuda a asegurar que las
prácticas existentes se mantienen durante periodos bajo presión. Cuando estas prácticas están
desplegadas, los proyectos se realizan y gestionan de acuerdo con sus planes documentados.
También en el nivel de madurez 2, el estado de los productos de trabajo es visible para la
dirección en puntos definidos. Se establecen compromisos entre las partes interesadas relevantes
y se modifican, según sea necesario. Los productos de trabajo se controlan de forma apropiada.
Los productos de trabajo y servicios satisfacen sus descripciones de proceso, estándares y
procedimientos especificados.
Nivel 3. Definido
En el nivel de madurez 3, los procesos están bien caracterizados y comprendidos, y se describen
en estándares, procedimientos, herramientas y métodos. El conjunto de procesos estándar de la
organización, que es la base del nivel de madurez 3, se establece y se mejora a lo largo del
tiempo. Estos procesos estándar se utilizan para establecer la integridad en toda la organización.
Los proyectos establecen sus procesos definidos adaptando el conjunto de procesos estándar de la
organización de acuerdo a las guías de adaptación (véase la definición de “conjunto de procesos
estándar de la organización” en el glosario). Una diferencia crítica entre los niveles de madurez 2
y 3 es el alcance de los estándares, descripciones de proceso y procedimientos. En el nivel de
madurez 2, los estándares, descripciones de proceso y procedimientos pueden ser bastante
diferentes en cada instancia específica del proceso (p. ej., en un proyecto particular).
49
En el nivel de madurez 3, los estándares, descripciones de proceso y procedimientos para un
proyecto se adaptan a partir del conjunto de procesos estándar de la organización para adecuarse
a un proyecto particular o unidad organizativa y, por tanto, son más consistentes, exceptuando las
diferencias permitidas por las guías de adaptación. Otra diferencia crítica es que en el nivel de
madurez 3, los procesos normalmente se describen más rigurosamente que en el nivel de madurez
2.
Un proceso definido establece claramente el propósito, entradas, criterios de entrada, actividades,
roles, medidas, etapas de verificación, salidas y criterios de salida. En el nivel de madurez 3, los
procesos se gestionan más proactivamente a través de la comprensión de las interrelaciones de las
actividades del proceso, de las medidas detalladas del proceso, de sus productos de trabajo y de
sus servicios. En el nivel de madurez 3 la organización mejora, aún más, sus procesos
relacionados con las áreas de proceso del nivel de madurez 2. Para lograr el nivel de madurez 3,
se aplican las prácticas genéricas asociadas con la meta genérica 3 que no fueron tratadas en el
nivel de madurez 2.
Nivel 4. Gestionado Cuantitativamente
En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos para
la calidad y el rendimiento del proceso, y los utilizan como criterios en la gestión de los
proyectos. Los objetivos cuantitativos se basan en las necesidades del cliente, usuarios finales,
organización e implementadores del proceso. La calidad y el rendimiento del proceso se
interpretan en términos estadísticos y se gestionan durante la vida de los proyectos. Para los
subprocesos seleccionados, se recogen y se analizan estadísticamente medidas específicas del
proceso. Cuando se seleccionan subprocesos para su análisis, es crítico comprender las relaciones
entre diferentes subprocesos y su impacto en la consecución de los objetivos de calidad y de
rendimiento del proceso.
Este enfoque ayuda a asegurar que la monitorización de subprocesos usando técnicas estadísticas
y otras técnicas cuantitativas se aplica donde tiene más valor global para el negocio. Las líneas
50
base y los modelos de rendimiento del proceso pueden usarse para ayudar a establecer los
objetivos de calidad y de rendimiento del proceso que ayuden a lograr los objetivos de negocio.
Una diferencia crítica entre los niveles de madurez 3 y 4 es la predictibilidad del rendimiento del
proceso. En el nivel de madurez 4, el rendimiento de los proyectos y de los subprocesos
seleccionados se controla utilizando técnicas estadísticas y otras técnicas cuantitativas, y las
predicciones se basan, en parte, en el análisis estadístico de los datos detallados de proceso.
Nivel 5. En optimización
En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en una
comprensión cuantitativa de sus objetivos de negocio y necesidades de rendimiento. La
organización utiliza un enfoque cuantitativo para comprender la variación inherente en el proceso
y las causas de los resultados del proceso. El nivel de madurez 5 se centra en mejorar
continuamente el rendimiento de los procesos mediante mejoras incrementales e innovadoras de
proceso y de tecnología. Los objetivos de calidad y de rendimiento del proceso de la organización
se establecen, se modifican continuamente para reflejar cambios en los objetivos del negocio y en
el rendimiento de la organización, y se utilizan como criterios para gestionar la mejora de
procesos. Los efectos de las mejoras de procesos desplegadas se miden utilizando técnicas
estadísticas y otras técnicas cuantitativas, y se comparan con los objetivos de calidad y de
rendimiento del proceso.
Los procesos definidos del proyecto, el conjunto de procesos estándar de la organización y la
tecnología de soporte, son objeto de actividades de mejora medibles. Una diferencia crítica entre
los niveles de madurez 4 y 5 es el enfoque de gestión y mejora del rendimiento de la
organización. En el nivel de madurez 4, la organización y los proyectos se enfocan en interpretar
y controlar el rendimiento a nivel de subprocesos y en utilizar los resultados para gestionar
proyectos. En el nivel de madurez 5, la organización se preocupa por el rendimiento global de la
organización usando los datos recogidos de múltiples proyectos. El análisis de los datos identifica
deficiencias o lagunas en el rendimiento. Esas lagunas se utilizan para orientar la mejora de
procesos en la organización que genera mejoras medibles en el rendimiento.
51
CAPÍTULO 3. MARCO METODOLÓGICO
3.1. Empresa Xcom: Objeto de Estudio
El Gobierno Federal cuenta con un organismo gubernamental que ofrece servicios financieros
básicos y satelitales con el objetivo de atender las necesidades de comunicación dirigidos a las
personas físicas, empresas privadas y entidades gubernamentales. Para efectos de esta tesis, se
denominará como Xcom. Cabe mencionar, que todos los procesos presentados en este trabajo son
reales.
Xcom cuenta con diversas sucursales en donde se pueden realizar diferentes operaciones de 12
instituciones financieras con cobertura a nivel nacional: Afirme, Banamex, Banco Azteca, Banco
del Bajío, Banorte, Bansefi, BBVA Bancomer, HSBC, Inbursa, Santander y Scotiabank. Algunas
de las formas de servicio son las siguientes:
• Depósito a cuenta de cheques.
• Depósito a cuenta concentradora.
• Depósito a tarjeta de débito.
• Pago a Tarjeta de crédito y otros créditos.
• Pago de servicios diversos.
• Retiro de efectivo con Tarjeta de débito.
• Retiro de efectivo con Tarjeta de crédito.
• Consulta de saldos.
• Consulta de movimientos.
• Apertura de Cuentas.
• Reposición de Tarjetas.
En dichas sucursales se pueden realizar pagos de las siguientes entidades:
AEROLINEAS
Aeroméxico, Interjet, Volaris.
52
COSMÉTICOS
Avon, Arabela, Estrellas B&S.
TIENDAS
Coppel, Dinamo-Abaco y Refácil (ConsorcioPeredo), Electrónicos y Más (Quality Stores y
Computerama), Famsa, Tiendas Chedraui (Consupresta).
SERVICIOS
Telmex, CFE, SKY, IZZI, Alestra, Cablemas, Dish México, Gas Natural – Metrogas, Mas TV,
Ruralsat, Tocom MVS, TV Cable Tepa, Telcel (Plan tarifario), Viaducto Bicentenario (prepago
caseta), Televía.
TIEMPO AIRE (LARGA DISTANCIA)
Convergia, Marcatel, Net Camino, Todito Cash, Todito Tarjeta Bueno.
TIEMPO AIRE (RECARGAS)
Iusacel, Movistar, Nextel, Telcel, Unefon.
GOBIERNOS ESTATALES (PAGO DE IMPUESTOS O SERVICIOS)
Baja California, Chiapas, Chihuahua, Colima, Durango, Guerrero, Hidalgo, Jalisco, México,
Puebla, Tabasco, Veracruz.
DEPENDENCIAS ESTATALES
Comisión Estatal de Servicios Públicos de Mexicali (CESPM), Comisión Intermunicipal de Agua
Potable y Alcantarillado Mpos. de Colima y Villa de Álvarez (CIAPACOV), Comisión de
Vivienda del Estado de Guanajuato (COVEG Secretaría de Fomento Económico (SEFOE) de
Yucatán, Sistema de Administración Tributaria del Estado de Coahuila (SATEC), Sistema
Intermunicipal para los Servicios de Agua Potable y Alcantarillado (SIAPA Jalisco).
SEGUROS DE VIDA
Sura.
53
DONATIVOS
Fundación Azteca, Fundación Realidad, Teletón.
Así como también servicios satelitales:
Telepuertos
Servicios Móviles por Satélite
Servicios Radio Marítimos
Servicios de Redes de Comunicación de Datos
Servicios de Alojamiento y Administración de Bases de Datos
3.1.1. Objetivo de la Empresa
El principal objetivo es brindar servicios de calidad a bajas comisiones para así atraer a la mayor
cantidad de clientes posibles que puedan ayudar a difundir más los servicios con los que cuenta
Xcom, así como también apoyar a que se pueda incrementar cada vez más el catálogo de
servicios que esta institución proporciona al público en general y personas morales.
3.1.2. Misión, Visión y Valores
Misión
En Xcom se proporcionan servicios integrales de telecomunicación y financieros básicos para la
población, dependencias gubernamentales y empresas en todo el país, facilitando la inclusión
social a través de sucursales y una red moderna de telecomunicaciones con cobertura satelital,
fibra óptica e informática, a precios competitivos y altos estándares de calidad.
54
Visión
Xcom será reconocido como un organismo descentralizado de clase mundial, que participa de
manera estratégica en el desarrollo y operación de una red robusta de servicios de
telecomunicación, así como una red de sucursales consolidada que continúa innovando y
prestando servicios financieros básicos en todo el país de manera eficiente y con personal
altamente capacitado.
Valores
Confiabilidad
Xcom es capaz de proporcionar servicios de una manera segura y permanente.
Honestidad
En Xcom respetamos la propiedad de los demás.
Innovación
En Xcom integramos soluciones de manera creativa.
Compromiso
En Xcom entregamos lo mejor de nosotros mismos para dar servicios de valor a nuestros clientes
y al Organismo.
Trabajo en Equipo
El éxito de Xcom lo construimos juntos.
Eficiencia
En Xcom logramos los resultados con el mejor manejo de los recursos.
Dinamismo
En Xcom logramos adaptarnos a los cambios con velocidad.
55
3.1.3. Organigrama del Área de TI
Para el desarrollo de esta investigación, nos centraremos especialmente en el área de TI y las
áreas que intervienen en el proceso de esta, en la figura 7, observaremos como se compone el
área y se explicará las funciones de cada una de ellas.
Figura 7. Organigrama del área de TI (Xcom, 2018)
Dirección General
Dirección Comercial
Gerencia Comercial de Servicios
Financieros Básicos
Gerencia Comercial de Comunicación y Nuevos canales de
servicio
Dirección Operaciones
Gerencia de Implementación de
Procesos de Servicios
Dirección de Finanzas
Subdirección de Desarrollos
Informáticos
Gerencia de Desarrollo de
Sistemas Informáticcos
Gerencia de Redes
Gerencia de Equipamiento
Informático
Gerencia de Seguridad
Informática
56
En la figura anterior se tienen dos vertientes: Áreas requirentes y áreas de aprovisionamiento y
soporte las cuales se describen a continuación:
Áreas requirentes:
o Dirección Comercial
Encargada de establecer contratos con los clientes, detona un nuevo de
desarrollo o mantenimiento a solicitud del cliente.
Genera nuevos esquemas de negocio que se reflejan en desarrollos de
aplicativos informáticos.
o Dirección de Operaciones
Opera el SIGS (Sistema Integral de Gestión de Servicios) en las Red de
Sucursales.
Encargada de los procesos operativos al interior del Organismo y con los
clientes,
Realiza solicitud de mantenimientos a los módulos del SIGS (Sistema
Integral de Gestión de Servicios).
Solicita nuevos módulos de apoyo a la operación del SIGS (Sistema
Integral de Gestión de Servicios).
Valida y apruebas los nuevos módulos y mantenimientos al SIGS (Sistema
Integral de Gestión de Servicios).
Áreas de aprovisionamiento y soporte:
o Subdirección de Desarrollo de Informática
Realiza las liberaciones de aplicativos de cómputo a producción (desarrollo
y mantenimiento)
o Gerencia de Centros de Cómputo y Equipamiento Informático
Encargada de servidores y base de datos.
o Gerencia de Red Telegráfica Integrada
57
Brinda la comunicación entre los usuarios del SIGS (Sistema Integral de
Gestión de Servicios) y el servidor.
o Gerencia de Seguridad Informática y Comunicaciones
Aprueba las liberaciones de aplicativos de cómputo a producción
(desarrollo y mantenimiento)
3.1.4. Descripción de la Problemática Actual
Dentro de la operación del área de TI, en especial de la Gerencia de Desarrollo de Sistemas
Informáticos se cuenta con el manejo de un sistema integral que controla todos los pequeños
desarrollos informáticos que se utilizan dentro de las sucursales encargadas de realizar los cobros.
El sistema integral se llama SIGS (Sistema Integral de Gestión de Servicios), actualmente este
sistema abre paso a más de 100 aplicaciones, cada una de ellas es un servicio que se cobra dentro
de las sucursales correspondientes y está abierto a nivel nacional en los 32 estados de la república
disponibles en zonas rurales de igual manera. En la figura 8, observamos un ejemplo de la
pantalla principal del SIGS donde eligen los servicios disponibles para el público en general.
Sistema Integral de Gestión de Servicios (SIGS)
Recargas Telefónicas
Teléfonos
Ventas Catálogos
Microfinancieras
Otras Instituciones
Aquí se describen todos los servicios y permite seleccionar de entre mas de 100 aplicaciones
Figura 8. Ejemplo pantalla SIGS
58
Dentro de las sucursales siempre hay dos o tres operadores recibiendo a las personas que desean
efectuar los pagos de algún servicio. Ellos tienen abierto el SIGS en las computadoras para tal fin
y eligen el servicio solicitado.
Esos servicios representan un aplicativo desarrollado para que se realice la captura de referencia,
importe, nombre del contribuyente, fecha dependiendo de lo que requiera cada servicio para
permitir el cobro. Al final de la operación y si todas las validaciones del aplicativo resultan
correctas, se genera un recibo al contribuyente.
Cada sistema cuenta con alguna de las tres modalidades de cobro:
Host to Host significa que el pago que realice el usuario de las sucursales se reflejará en el
momento
Batch el pago se reflejará en las próximas 24 horas
Mixta si se requiere tener ambas modalidades de cobro.
Las figuras 9 a la 11 explican cada una de las modalidades de cobro:
CLIENTESUCURSALUSUARIO
Realiza pago
El pago se refleja en el
momento hacia el cliente
Figura 9. Cobro modalidad Host to Host (Xcom, 2018)
59
CLIENTE
SUCURSALUSUARIO
Realiza pago
Se genera Archivo de
Conciliación con los pagos
realizados durante el día
Se guardan los pagos en
la Base de Datos
Se envía el
archivo al
cliente
Figura 10. Cobro modalidad batch (Xcom, 2018)
60
CLIENTE
SUCURSALUSUARIO
Realiza pago
El pago se refleja en el
momento hacia el cliente
La Infraestrucura del
cliente está disponible
SI
CLIENTE
Se genera Archivo de
Conciliación con los pagos
realizados durante el día
Se envía el
archivo al
cliente
NO
Se guardan los pagos en
la Base de Datos
Figura 11. Cobro modalidad mixta (Xcom, 2018)
En la tabla 3, se muestran algunos de los aplicativos con los que cuenta actualmente la GDSI, el
tipo de modalidad de cobro que tienen y el lenguaje de programación que se emplea para cada
uno de los aplicativos.
61
Tabla 3. Relación de aplicativos en SIGS (Xcom, 2018)
CLIENTE H2H BATCH MIXTO LENGUAJE
SKY
X
SQL-C
TELMEX
X
JAVA
ALESTRA
X
SQL-C
TOCOM
X
SQL-C
MASTV
X
SQL-C
RURALSAT
X
SQL-C
AVON
X
SQL-C
JAFRA X
JAVA JDK 8.2
MARCATEL
X
SQL-C
ARABELA
X
SQL-C
CFE
X
SQL-C
TARJETAS TELETON
X JAVA JDK 8.2
COPPEL
X
SQL-C
VOLARIS
X
SQL-C
GOB EDO VERACRUZ
X
SQL-C
GOB EDO DURANGO
X
SQL-C
GOB EDO MEX
X JAVA JDK 8.2
CONCORD
X
SQL-C
GOB EDO PUE
X
SQL-C
SIAPA
X
SQL-C
GAS NATURAL
X
SQL-C
DINAMO
X
SQL-C
GOB EDO CHIH
X
SQL-C
FONACOT
X
SQL-C
COMERCIALIZADORA DE FRECUENCIAS
SATELITALES (DISH) X
SQL-C
GOB EDO GUERRERO
X
SQL-C
GOB EDO HIDALGO
X SQL-C
TELCEL
X
SQL-C
AEROMEXICO
X
SQL-C
FAX NACIONAL (101)
X
SQL-C
FAX INTERNACIONAL (103)
X
SQL-C
ISSSTE(104)
X
SQL-C
TELECABLE(107)
X
SQL-C
SUAUTO
X
SQL-C
GOB EDO BCS
X
SQL-C
INTERJET
JAVA JDK 8.2
GOB EDO CHIAPAS
X
SQL-C
SEGUROS VIDA SURA
X
SQL-C
62
GOB EDO TABASCO
X
SQL-C
GOB EDO COLIMA
X
SQL-C
ELECTRONICOS Y MAS X
JAVA JDK 8.2
CABLEMAS
X
SQL-C
(GOB EDO COAH) SATEC X
JAVA JDK 8.2
EOZ
X
JAVA JDK 8.2
GOB EDO OAXACA
X
JAVA JDK 8.2
DONATIVOS TELETON
X
JAVA JDK 8.2
GOBIERNO MUNICIPAL DE NAUCALPAN
X
JAVA JDK 8.2
CRUZ ROJA
X
JAVA JDK 8.2
UNIVERSIDAD DE GUANAJUATO
X
JAVA JDK 8.2
OSSY
X
JAVA JDK 8.2
SABES- DER. EDUCATIVOS
X JAVA JDK 8.2
GOB EDO GUANAJUATO X
JAVA JDK 8.2
SABES- ING. PROPIOS
X JAVA JDK 8.2
DICONSA GUERRERO
X
JAVA JDK 8.2
SIMAPAG
X
JAVA JDK 8.2
CMAPAS SALAMANCA, GTO.
X
JAVA JDK 8.2
GOBIERNO DE NUEVO LEON
X
JAVA JDK 8.2
COMAPA TAMPICO
X
JAVA JDK 8.2
TECATE_CESPTE
X
JAVA JDK 8.2
FISCALIA GENERAL DEL ESTADO DE
TABASCO X
JAVA JDK 8.2
IZZI
X JAVA JDK 8.2
UNIVERSIDAD VIRTUAL DEL EDO. DE
GUANAJUATO (UVEG) X
JAVA JDK 8.2
CMAPS LA ANTIGUA, VER.
X
JAVA JDK 8.2
COMAPA VICTORIA
JAVA JDK 8.2
SOFIPA CORPORATION
X
JAVA JDK 8.2
EMPRENDAMOS (GARANTIA DE
CREDITOS) X
JAVA JDK 8.2
EMPRENDAMOS (PAGO DE CREDITOS)
X
JAVA JDK 8.2
APOYO MULTIPLE
X
JAVA JDK 8.2
FINCOMUN
X
JAVA JDK 8.2
CREDIEQUIPOS CONTIGO
X
JAVA JDK 8.2
SIDEC
X
JAVA JDK 8.2
MICROSOL
X
JAVA JDK 8.2
BROXEL
X
JAVA JDK 8.2
SAE (SISTEMA DE ADMINISTRACIÓN Y
ENAJENACIÓN DE BIENES) X JAVA JDK 8.2
63
Sin embargo, al momento de solicitar un nuevo desarrollo, las áreas requirentes no realizan el
requerimiento de una manera apropiada y en la GDSI no se recibe correctamente. Lo que genera
los siguientes problemas:
La atención de solicitudes de desarrollo y mantenimiento sigue procesos no uniformes y
con distintos niveles de madurez y control.
No se cuenta con suficientes indicadores objetivos para evaluar el desempeño como área o
como acuerdos de servicio, sin embargo, se percibe que el desempeño en algunos casos se
puede mejorar.
El tiempo de resolución de algunas solicitudes (desde que se recibe una solicitud hasta
que se da por resuelta y terminada) son altos.
El tiempo estimado de cada resolución se calculan a juicio experto y muchas veces se ven
afectados por causas externas al área o cambios de prioridad.
No se cuenta con un inventario confiable de políticas, plantillas de formatos, guías,
manuales técnicos, etc. (activos de procesos)
Aunque se tiene claridad en la necesidad de implementar mejoras en los procesos, la
operación no permite asignar recursos ni se cuenta con la experiencia para estructurar un
programa de mejora.
No se tiene un inventario terminado con la descripción de cada uno de los roles dentro del
área, así como de las actividades que desempeña cada uno de ellos.
En la figura 12, se muestran los principales cuellos de botella marcados en círculo.
64
ESTADO ACTUAL GERENCIA DE DESARROLLO DE SISTEMAS (SOLICITUD Y LIBERACIÓN DE UN APLICATIVO)
DIRECCIÓN DE OPERACIONES
DIRECCIÓN COMERCIAL GDSISUBDIRECCIÓN DE
DESARROLLOS INFORMATICOS
Firma Contrato con el cliente
Valida la petición del usuario y genera
un requerimiento
Se recibe el requerimiento
Se asigna a un programador y un
documentador los cuales deben de diseñar el
nuevo sistema y generar el acta del proyecto
respectivamente
Se envía el plan de proyecto para la
validación
Da a conocer al cliente el tiempo
que tardará la aplicación.
Se encarga de poner en un ambiente de
desarrollo la apliicación
Realiza pruebas en el ambiente de
desarrollo e informa el resultado de las
pruebas
Las pruebas resultaron
satisfactoriasPrueba el aplicativo con las correcciones
realizadas
Se realiza formato de liberación a
producción
SI
NO
Recibe el formato de liberación
Pone en producción la aplicación
Realiza pruebas en producción
Informa al cliente que el producto esta listo en las
sucursales
Las pruebas fueron exitosas
SI
NO
Figura 12. Proceso de solicitud y liberación de un proyecto (Xcom, 2017)
65
Los cuellos de botella que muestran en la figura 12, se generan prácticamente desde el área de TI,
tanto en la subdirección de desarrollos informáticos y en la GDSI, pues inician desde que se
recibe el requerimiento, ya que este no es un formato estándar, sino cualquier área manda el
requerimiento por diversos medios y la mayoría de las veces la petición es ambigua.
En el caso de los formatos de liberación, conlleva el llenado de diversos apartados que no quedan
claros y que la subdirección de desarrollos informáticos no ha podido aclarar hasta el momento,
por lo que en general, los formatos se llenan mal y las solicitudes por parte de esta área se
atienden de una manera incorrecta o no conforme a lo que se requiere por parte de la GDSI.
Otro cuello de botella importante es con respecto a los ambientes de desarrollo, regularmente no
cuentan con las mismas características que se requieren para la puesta en producción, por lo que
la liberación de los sistemas siempre fracasa debido a la incompatibilidad de la configuración
tanto del servidor de aplicaciones como en las herramientas y frameworks que se utilizaron para
desarrollar los sistemas informáticos.
66
3.2. Uso del MAAGTICSI en Xcom
Actualmente la GDSI tiene implementado el MAAGTICSI para el control de los procesos en
materia de tecnologías de información y comunicaciones, así como de la seguridad informática.
El estatus actual de la implementación que se tiene en Xcom se describe en la tabla 4:
Tabla 4. Descripción de Procesos MAAGTICSI (Órgano Interno de Control Xcom, 2018)
Proceso MAAGTICSI Formula
Indicador
%
cumplimiento
Gobernanza Planeación Estratégica
% Eficiencia en la
ejecución del
proyecto = (avance
real / avance
estimado) * 100
60%
PE 1. Establecer la gobernabilidad de las operaciones de la
UTIC
PE 2 Integrar la información de la Cartera Ejecutiva de
Proyectos de TIC.
PE 3 Validar, aprobar, comunicar y adecuar, de ser
necesario, la Cartera Ejecutiva de Proyectos de TIC.
PE 4 Dar seguimiento a la planeación estratégica de TIC.
Administración del Presupuesto y las
contrataciones % de eficiencia =
(Número de estudios de
factibilidad
favorables/número de
estudios de factibilidad
presentados a la
Unidad) X 100.
70%
APCT 1. Participar en el establecimiento de prioridades del
presupuesto de TIC.
APCT 2 Establecer el listado de bienes y servicios de TIC a
contratar por la UTIC en cada ejercicio fiscal.
APCT 3 Estudios de Factibilidad.
APCT 4 Participar como área técnica, en los procedimientos
de contratación de TIC.
Organización
Administración de Servicios % de cumplimiento =
(número de revisiones
efectuadas/número de
evaluaciones del
periodo que se reporta)
X 100.
50%
ADS 1. Mantener actualizado el catálogo de servicios de
TIC.
ADS 2. Diseñar los servicios de TIC.
ADS 3. Administrar la capacidad de la infraestructura de
TIC.
67
ADS 4. Administrar la continuidad de servicios de TIC.
Administración de la Configuración % de eficiencia =
(número de revisiones
efectuadas al
repositorio de
configuraciones/número
de revisiones
programadas al
repositorio de
configuraciones) X 100.
50%
ACNF 1. Establecer la cobertura y el alcance de la
administración de la configuración.
ACNF 2. Definir la estructura del repositorio de
configuraciones.
ACNF 3. Registrar los elementos de configuración en el
repositorio de configuraciones
Administración de la Seguridad de la
Información
% de implementación y
validación de SGSI 50%
ASI 1. Establecer un modelo de gobierno de seguridad de la
información.
ASI 2. Operar y mantener el modelo de gobierno de
seguridad de la información.
ASI 3. Diseño del SGSI.
ASI 4. Identificar las infraestructuras de información
esenciales y, en su caso, críticas, así como los activos clave.
ASI 5. Elaborar el análisis de riesgos.
ASI 6. Integrar al SGSI los controles mínimos de seguridad
de la información.
ASI 7. Mejorar el SGSI.
Entrega
Administración de Proyectos % de eficiencia =
(Número de proyectos
pertenecientes a la
Cartera Operativa de
Proyectos de TIC -
número de proyectos
cancelados o
modificados en alcance
/ número total
proyectos
50%
ADP 1. Establecer directrices para la gobernabilidad y
evaluación de la Cartera Operativa de Proyectos de TIC.
ADP 3. Priorizar, equilibrar y autorizar la Cartera Operativa
de Proyectos de TIC.
68
ADP 4. Administrar y monitorear la Cartera Operativa de
Proyectos de TIC.
pertenecientes a la
Cartera Operativa de
proyectos de TIC) X
100.
ADP 6. Cerrar iniciativas y proyectos de TIC.
Administración de Proveedores
% de eficiencia =
(número de revisiones
de avance y conclusión
ejecutadas / número de
revisiones de avance y
conclusión
programadas) X 100.
50%
APRO 1. Generar lista de verificación de obligaciones.
APRO 2. Monitorear el avance y desempeño del proveedor.
APRO 3. Apoyo para la verificación del cumplimiento de las
obligaciones de los contratos.
Administración de la Operación
% de eficiencia =
(incidentes en la
operación resueltos /
incidentes que se
presentaron en el
ambiente operativo) X
100.
60%
AOP 1. Establecer el mecanismo de operación y
mantenimiento de los sistemas, aplicaciones, infraestructura
y servicios de TIC.
AOP 2. Programar y ejecutar las tareas de la operación de los
sistemas, aplicaciones y servicios de TIC.
AOP 3. Monitorear la infraestructura de TIC en operación.
AOP 4 Implementar y verificar que se cumplan los
controles de seguridad física en el centro de datos.
Operación de Controles de Seguridad de la
información y del equipo de respuesta a
incidentes de seguridad en TIC (ERISC) % de eficiencia =
(controles
implementados en
operación de acuerdo a
su definición / controles
implementados) X 100.
60% OPEC 1. Designar un responsable de la supervisión de la
implementación de los controles de seguridad definidos en el
SGSI y en el análisis de riesgos.
OPEC 2 Establecer los elementos de operación del ERISC.
OPEC 3 Operación del ERISC en la atención de incidentes.
69
De esta manera, gráficamente tendremos los siguientes resultados del cumplimiento de cada uno
de los procesos del MAAGTICSI, como se describe en la figura 13.
Figura 13. Porcentaje de cumplimiento de procesos del MAAGTICSI en Xcom (Auditoria
Xcom, Julio 2018)
La auditoría la realiza el área de Órgano Interno de Control de la organización mediante el
cálculo de los indicadores que se presentan en la tabla 4, con base en lo mencionado, eso se
determina el porcentaje de cumplimiento de cada uno de los procesos del MAAGTICSI.
0% 20% 40% 60% 80%
Planeacion Estratégica
Administración del Presupuesto y las contrataciones
Administración de Servicios
Administración de la Configuración
Administración de la Seguridad de la Información
Administración de Proyectos
Administración de Proveedores
Administración de la Operación
Operación de Controles de Seguridad de la información y delequipo de respuesta a incidentes de seguridad en TIC (ERISC)
Procesos MAAGTICSI
70
3.3. Descripción de Procesos para el Desarrollo de Software
Un proceso se define como un conjunto de actividades interrelacionadas o interactuantes que
transforman las entradas y salidas dentro de una organización. (Gordillo Mejía, Licona Padilla, &
Acosta Gonzaga, 2013)
Dentro de las actividades que se realizan actualmente en la GDSI, se contemplan diversos
procesos implementados con el MAAGTICSI para el desarrollo de sistemas. Sin embargo, no han
tenido los resultados esperados. La tabla 5, enlista los procesos que conlleva el desarrollo de
sistemas:
Tabla 5. Procesos actuales de la GDSI (Xcom, 2017)
No. Proceso Descripción
Proceso 1 Recepción de la solicitud de un sistema informático
Proceso 2 Análisis de la solicitud
Proceso 3 Asignación de Recursos
Proceso 4 Desarrollo del Sistema
Proceso 5 Pruebas Operativas (Ambiente Desarrollo)
Proceso 6 Liberación a Producción
Cada uno de los procesos a su vez cuenta con diversas actividades y depende del software
solicitado. Sin embargo, los procesos descritos en la tabla 5 se pueden detallar de la siguiente
manera en las figuras 14 a la 19 donde se describen las áreas involucradas y el responsable de
efectuarlo.
Actualmente en la GDSI no hay una descripción de roles como tal, por lo que las actividades de
desarrollo de un sistema en ocasiones pueden estar a cargo de una sola persona.
71
Nombre del Proceso: Recepción de la solicitud de un sistema informático.
Responsable: GDSI
Recepción de una solicitud de un sistema informático
Áreas RequirentesSubdirección de
InformáticaGDSI
inicio
Continua con el siguiente proceso
La solicitud es viable
Prepara la solicitud
Se regresa retroalimentación
explicando motivos de no
viabilidad
No
Si
No
Envío de CorreoOficio
Solicitando un aplicativo
Figura 14. Recepción de la solicitud de un sistema informático (Xcom, 2017)
72
Nombre del Proceso: Análisis de la solicitud de un sistema informático
Responsable: GDSI
Análisis de la solicitud
GDSI Analistas
Continua con el siguiente proceso
Valida la solicitud
Solicita la elaboración del
acta del proyecto
Realiza la elaboración del
acta del proyecto en base a los
datos que contiene la
solicitud
Figura 15. Análisis de la solicitud (Xcom, 2017)
73
Nombre del Proceso: Asignación de Recursos
Responsable: GDSI
Asignación de Recursos
GDSI Programadores
Continua con el siguiente proceso
Analiza los requerimientos de los programadores y brinda el apoyo
Delega el proyecto a los
programadores capacitados para
ello
Analiza la solicitud e informa cuanto
tiempo tardara, las herramientas a
utilizar y los recursos que
necesitará
Figura 16. Asignación de Recursos (Xcom, 2017)
74
Nombre del Proceso: Desarrollo del Sistema
Responsable: GDSI
Desarrollo del Sistema
GDSI AnalistasUsuario Programador
Codifica los módulos descritos
en diagramas
Prepara documento con
dudas para aclarar por el área usuaria
Brinda los requermientos
Recibe los requerimientos
Es entendible
Si
Realiza diagramas de flujo y UML
para el programador
No
Recibe e interpreta los diagramas de
flujo y UML
Aclara dudas de los analistas
mediante oficio o correo electrónico
Recibe aclaraciones
Interpreta las aclaraciones
Figura 17. Desarrollo de Software (Xcom, 2017)
75
Nombre del Proceso: Pruebas Operativas (Ambiente Desarrollo)
Responsable: GDSI
Pruebas Operativas (Ambiente Desarrollo)
GDSIDirección de
OperacionesProgramador
Finaliza el desarrollo de la
aplicación y pasa a pruebas mediante
correo
Recibe correo para pruebas y las inicia
Las pruebas son satisfactorias
SiPrepara el
proyecto para producción
No
Prepara un documento con observaciones a
corregir
Corrige las observaciones
Figura 18. Pruebas Operativas (Ambiente de Desarrollo) (Xcom, 2017)
76
Nombre del Proceso: Liberación a Producción
Responsable: GDSI
Liberación a Producción
GDSIDirección de
OperacionesProgramador
Subdirección de
Informática
Prueba la aplicación en ambiente de
desarrollo y comunica la aprobación del
mismo
Las pruebas son satisfactorias
Si
Prepara la aplicación en el repositorio Tortoise (.war)
Prepara un formato de liberación de la
aplicación
No
Realiza las correcciones que
envía el área operativaAutoriza el formato de
liberación del aplicativo
Recibe el formato de liberación del
aplicativo
Recupera el archivo .war del repositorio y lo carga en el servidor
de produccion.
Prueba la aplicación en ambiente de
desarrollo y comunica la aprobación del
mismo
Autoriza que la aplicación se haga disponible para las sucursales a nivel
nacional
Figura 19. Liberación a producción (Xcom, 2017)
77
3.4. Ejecución de Aplicativos Basados en el MAAGTICSI
Con base en lo anterior, la GDSI ha aplicado los procesos anteriores (figuras 14 a 19) a todos los
proyectos que se realizan para integrar el SIGS. Sin embargo, para cumplir los objetivos de este
trabajo, se evaluarán tres aplicativos, comprendiendo las modalidades de cobro implementadas
actualmente en Xcom: Host to Host, Batch y mixta (véanse figuras 9 a 11).
Los aplicativos mencionados son:
Aplicativo Batch: SASE
Aplicativo Host to Host: JAIS
Aplicativo modalidad mixta: HIDS (SECTOR PÚBLICO).
A continuación, se presentará la descripción de cada servicio, la asignación de recursos, tiempo
de desarrollo, el número de operaciones que se llevan a cabo dentro de las sucursales, la
representación de los ingresos adquiridos, así como las ganancias para los clientes y Xcom.
3.4.1. Ejecución del Aplicativo BATCH en el SASE
Desarrollo con modalidad de cobro BATCH que, mediante el ingreso del nombre del usuario, No.
de referencia e importe permiten realizar los pagos correspondientes al cliente de Xcom, SASE.
El operador del SIGS, que es el sistema que engloba todos los servicios, atiende al usuario en las
sucursales. Dicho usuario pregunta por el servicio SASE junto con la factura o los datos
necesarios para efectuar el pago, por lo que le brinda al operador del SIGS el número de
referencia, nombre completo y el importe a pagar. Se realizan las validaciones correspondientes
de la información brindada por el usuario y al final, si todo es correcto, se le otorga un
comprobante de pago.
78
La figura 20 ejemplifica la pantalla de ingreso de datos para efectuar los cobros de este
aplicativo.
SASE
$0.00
Nombre Apellido Paterno Apellido Materno
Enviar Pago
No. Referencia Importe
Figura 20. Ejemplo de pantalla para cobro SASE
En la tabla 6 se describe un plan de trabajo indicando los recursos que se asignarán, así como el
tiempo que se requiere para desarrollar el proyecto.
Tabla 6. Plan de trabajo SASE
Actividad Recurso Tiempo
(Días) Fecha Inicio
Fecha
Término
Recepción de Requerimiento Analista 3 días 27/11/17 29/11/17
Elaboración de Acta de
Proyecto Analista 7 días 30/11/17 08/12/17
Elaboración de Plan de
Trabajo Analista 7 días 11/12/17 19/12/17
Diseño de Pantallas Desarrollador 15 días 20/12/17 09/01/18
Codificación de Pantallas Desarrollador 60 días 10/01/18 03/04/18
Pruebas Analista,
Desarrollador 10 días 04/04/18 17/04/18
Total de Días 102 días
79
El tiempo de desarrollo sería de 3 meses y solo se asignarían dos recursos.
El proyecto inició el 27 de noviembre de 2017 y se planeó su entrega para el 17 de abril de 2018,
sin embargo, es hasta el 16 de mayo de 2018 que el aplicativo se liberó a producción, al realizar
el análisis del proceso se determinó que las razones por las cuales hubo un retraso en el desarrollo
fueron:
Falta de consistencia en el requerimiento inicial
No se realizó la ambientación correcta en producción
Se pidieron cambios aun cuando el aplicativo ya estaba puesto en producción a nivel
nacional
No se realizó un registro de las inconsistencias de las pruebas
Falta de comunicación entre áreas
Cuando el aplicativo se encontró a nivel nacional, se empezó a registrar el número de operaciones
que se realizaban, así como la ganancia tanto para Xcom como para SASE.
En la tabla 7, se pueden observar los ingresos monetarios que se obtienen por las operaciones
realizadas en este servicio por mes, a nivel nacional.
Tabla 7. Operaciones SASE por mes
Mes No. de
Operaciones Ingreso
Ganancia
Xcom
Ganancia
SASE
Mayo 2018 5, 203 $ 10,039,284.50 $2,509,821.13 $7,529,463.38
Junio 2018 7, 178 $ 17,407,513.00 $4,351,878.25 $13,055,634.75
Julio 2018 4, 564 $ 8,467,923.86 $2,116,980.97 $6,350,942.90
TOTALES $35,914,721.36 $8,978,680.34 $26,936,041.02
Los ingresos económicos de Xcom representan el 25% del monto total de las operaciones, tal
porcentaje se establece dentro del contrato que se firma con la dirección comercial.
80
A mayor número de operaciones es mayor la ganancia para ambos.
El número de operaciones e ingresos económicos se pueden interpretar mediante la figura 21.
Figura 21. Ingresos económicos y No. Operaciones SASE
3.4.2. Ejecución del Aplicativo Host to Host en JAIS
Desarrollo Host to Host que realiza el cobro de las referencias que JAIS emite y que hacen
referencia al cliente, son referencias únicas y solo el importe es el que varía en cada uno de los
pagos. La pantalla de captura de datos se muestra en la figura 22.
0
1000
2000
3000
4000
5000
6000
7000
8000
Mayo Junio Julio
$ 10,039,284.50
$ 17,407,513.00
$ 8,467,923.86
No. de Operaciones SASE
81
JAIS
$0.00
Enviar Pago
No. Referencia
Importe
Figura 22. Ejemplo de captura de datos JAIS
Este aplicativo trabaja mediante el consumo del web service de JAIS para obtener los datos de
importe y nombre del cliente y efectuar la validación con los datos que se están ingresando.
Este tipo de actividades extra generan que se utilice más tiempo en la ambientación y conexión al
web service que se utilizará. En la tabla 8, se muestra el plan de trabajo para este aplicativo.
Tabla 8. Plan de Trabajo JAIS
Actividad Recurso Tiempo
(Días)
Fecha
Inicio
Fecha
Termino
Recepción de
Requerimiento Analista 3 días 02/10/17 04/10/17
Elaboración de Acta de
Proyecto Analista 7 días 05/10/17 13/10/17
Elaboración de Plan de
Trabajo Analista 7 días 6/10/17 24/10/17
Diseño de Pantallas Desarrollador 15 días 25/10/17 14/11/17
Consumo web service Desarrollador 22 días 15/11/17 14/12/17
Ambientación Desarrollador 15 días 15/12/17 04/01/18
Codificación de Pantallas Desarrollador 60 días 05/01/18 29/03/18
Solicitud de Insumos para Analista 5 días 30/03/18 05/04/18
82
pruebas JAIS
Pruebas Analista,
Desarrollador 10 días 06/04/18 19/04/18
Total de Días 144 días
Como podemos observar el proyecto se realizaría en 144 días. El proyecto inicio el 2 de octubre
de 2017 y se planea concluya el 19 de abril de 2018, sin embargo, el aplicativo se liberó a
producción hasta el 15 de mayo de 2018, al analizar el proceso se encontró que el retraso en el
desarrollo se debió a las siguientes causas:
Definición de requerimientos ambigua.
Método de Conexión al web service mal elaborado.
Al realizar las pruebas, se comprobó que el ambiente no era compatible.
Una vez que el aplicativo logró estar en producción a nivel nacional, se puede obtener la
información de las operaciones que se realizaron en las sucursales de Xcom. La tabla 9 describe
los ingresos monetarios percibidos por el aplicativo JAIS.
Tabla 9. Operaciones JAIS por mes
Mes No. de
Operaciones Ingreso
Ganancia
Xcom
Ganancia
JAIS
Mayo 1371 $ 2,532,262.16 $ 379,839.32 $2,152,422.84
Junio 1684 $ 4,388,701.95 $ 658,305.29 $3,730,396.66
Julio 1211 $ 1,586,500.00 $ 237,975.00 $1,348,525.00
TOTALES $ 8,507,464.11 $1,276,119.62 $7,231,344.49
Las ganancias de Xcom representan el 15% acordado mediante el contrato firmado con el cliente
JAIS.
83
En la figura 23 se muestra el número de operaciones y monto por mes.
Figura 23. Ingresos económicos y No. de Operaciones JAIS
3.4.3. Ejecución del aplicativo modalidad mixta en HIDS (Sector
Público)
Desarrollo Mixto para las sucursales a nivel estatal, consiste en la captura de la referencia, fecha
de vigencia e importe. El sistema deberá validar la referencia con el algoritmo 97 y condensar la
fecha e importe contenidos dentro de la referencia.
Consume un web service y así corrobora los datos ingresados, incluso regresará el nombre del
contribuyente, pero en caso de no estar disponible, se generará un archivo de conciliación con las
operaciones del día y se enviarán a HIDS al siguiente día.
0
200
400
600
800
1000
1200
1400
1600
1800
Mayo Junio Julio
$2,532,262.16
$4,388,701.95
$1, 586, 500.00
No. Operaciones JAIS
84
La figura 24 muestra la pantalla de captura de datos para este aplicativo.
HIDS (SECTOR PÚBLICO)
$0.00
Enviar Pago
No. Referencia
Importe
Fecha de Vigencial
25
julio de 2018
m m j v s d
26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24
30 31
Figura 24. Ejemplo pantalla de captura HIDS (SECTOR PÚBLICO)
Este es un aplicativo que requiere de más tiempo, pues el desarrollo consiste en agregar las dos
formas de cobro (Batch y Host to Host) en uno solo. En la tabla 10, se muestra el plan de trabajo
para el HIDS (SECTOR PÚBLICO).
Tabla 10. Plan de Trabajo HIDS (SECTOR PÚBLICO)
Actividad Recurso Tiempo
(Días)
Fecha
Inicio
Fecha
Termino
Recepción de
Requerimiento Analista 3 días 04/07/17 06/07/17
Elaboración de Acta de
Proyecto Analista 7 días 07/07/17 17/07/17
Elaboración de Plan de
Trabajo Analista 7 días 18/07/17 26/07/17
85
Diseño de Pantallas Desarrollador 15 días 27/07/17 16/08/17
Construcción de Modulo
BATCH
Desarrollador 20 días 17/08/17 13/09/17
Construcción de Módulo
HOST TO HOST
Desarrollador 20 días 14/09/17 11/10/17
Consumo WebService Desarrollador 22 días 12/10/17 10/11/17
Ambientación Desarrollador 15 días 13/11/17 01/12/17
Codificación de Pantallas Desarrollador 60 días 04/12/17 23/02/18
Solicitud de Insumos para
pruebas Analista 5 días 26/02/18 02/03/18
Pruebas Analista,
Desarrollador 10 días 05/03/18 16/03/18
Total de Días 184 días
El proyecto se inició el 04 de julio de 2017 y se planeó que finalizara el 16 de marzo de 2018. Sin
embargo, el 2 de mayo el aplicativo logró estar en producción.
Las principales causas del retraso obtenido fueron:
Falta de claridad y consistencia en los requerimientos iniciales.
Falta de capacitación del personal en el uso del lenguaje Java.
Planeación inicial errónea
Falta de ambientación de los servidores de desarrollo y producción
Manejo incorrecto de versiones de WebLogic
Cambios solicitados dentro de las pruebas de desarrollo
Cambios solicitados aun estando en ambiente productivo a nivel nacional
86
Cuando el aplicativo se encontró en producción, se reportaron las siguientes cifras con respecto a
las operaciones realizadas dentro del periodo mayo-julio. La tabla 11, muestra la información
recuperada del ingreso y ganancia correspondiente.
Tabla 11. Operaciones HIDS (SECTOR PÚBLICO) por mes
Mes No. de
Operaciones Ingreso
Ganancia
Xcom
Ganancia
HIDS (SECTOR PÚBLICO)
Mayo 9090 $ 2,481,846.00 $ 620,461.50 $1,861,384.50
Junio 8405 $ 1,217,973.53 $ 304,493.38 $ 913,480.15
Julio 10560 $ 3,943,331.92 $ 985,832.98 $2,957,498.94
TOTALES $ 7,643,151.45 $1,910,787.86 $5,732,363.59
La ganancia de Xcom representa el 25% del ingreso a las sucursales y fue lo acordado mediante
el contrato firmado con el HIDS (SECTOR PÚBLICO).
En la figura 25, se muestra mediante una gráfica el número de operaciones en el periodo de
mayo-julio.
Figura 25. Ingresos económicos y No. de Operaciones HIDS (SECTOR PÚBLICO)
0
2000
4000
6000
8000
10000
12000
Mayo Junio Julio
$2,481,846.00$1,217,973.53
$3,943,331.92
No. Operaciones HIDS (SECTOR PÚBLICO)
87
Como se puede notar en cada uno de los servicios, los recursos asignados son pocos y el tiempo
de desarrollo no fue suficiente para que se cumpliera en forma con la entrega de los aplicativos.
Los proyectos sufrieron retrasos, las actividades mencionadas no fueron suficientes y la
planeación para cada proyecto no fue la adecuada. ¿Qué pasaría si se utilizara un modelo para el
desarrollo de software que permitiera regular los procesos a seguir y controlar mejor las
actividades? ¿Se generarían más ganancias o se quedarían igual? ¿Habría cambios significativos
en la manera en la que la GDSI desempeña las actividades? Veamos en los siguientes apartados.
3.5. Implementación de CMMI® Nivel 2
Dentro de este capítulo se mostrará la implementación en Xcom de CMMI® nivel 2 a través de la
aplicación del modelo IDEAL, con este modelo se describirán las acciones a seguir: el plan de
trabajo de cada una de las áreas de proceso, así como para cada una de las metas. Además, se
propondrán las actividades a realizar, las cuales consisten en la generación de nuevos formatos,
definición de políticas y descripción de procedimientos.
3.5.1. Modelo Ideal - Fase Inicial
Las actividades de esta fase inicial se realizaron de la siguiente manera:
CONTEXTO: Con el objetivo de hacer de conocimiento a todo el personal la metodología
CMMI®, se impartieron diversos cursos, los cuales se describen en la tabla 12:
Tabla 12. Cursos propuestos para Xcom
Curso Duración
Mejora de Procesos 2 semanas
CMMI® DEV versión 1.3 3 semanas
PATROCINIO: Se consiguió el apoyo de la dirección, en este caso, se establecieron firmas de
compromiso por parte del Subdirector de Desarrollos Informáticos, tanto para el establecimiento
88
del plan de mejora como para designar los recursos económicos, humanos y materiales para tal
fin.
INFRAESTRUCTURA: Para la implementación del plan de mejora con CMMI® a nivel 2, no se
requirió más infraestructura, Xcom cuenta con lo necesario para realizar la implementación a ese
nivel.
3.5.2. Modelo Ideal - Fase de Diagnóstico
De acuerdo con el modelo IDEAL se realizó un diagnostico bajo las siguientes pautas:
CARACTERIZACIÓN: Los hallazgos encontrados es que la empresa se encuentra en un nivel 1,
ya que con la implementación del MAAGTICSI se ha logrado controlar varios procesos:
Administración de la Configuración
Administración de Proyectos
Administración de Proveedores
Administración de la Operación
DESARROLLO: Se planea madurar los procesos anteriores mediante la implementación de
CMMI® nivel 2, que reforzará los procesos y permitirá mejorar la calidad de los productos de
software, cumplimiento de tiempos y mayor productividad.
3.5.3. Modelo Ideal - Fase de Establecimiento
En esta fase se establecen las acciones a seguir de acuerdo con los resultados de las fases
anteriores.
PRIORIDADES: Se dará prioridad a los siguientes procesos con el objetivo de madurar y
mejorar las actividades individuales en éstos.
Administración de la Configuración
89
Administración de Proyectos
Estos procesos fueron elegidos debido a que son los que reportan menor porcentaje de eficiencia
en las auditorias.
PROPUESTA: La tabla 13 muestra el rol de cada miembro de cada grupo, los cuales cuentan con
los conocimientos y habilidades necesarios para implementar el programa de mejora. Así mismo
se muestra participación y responsabilidad que tendrán. (SEI, 2010)
Tabla 13. Roles para el programa de Mejora con CMMI® nivel 2
Rol Conocimientos y habilidades Participación y responsabilidades
MSG –
Management
steering group
Conocimiento de la
estrategia, negocio y
organización de Xcom.
Conocimiento del modelo
CMMI® DEV. v1.3.
Habilidad para toma de
decisiones estructurada.
Comunicación asertiva.
Técnicas de juntas efectivas
y trabajo en consenso.
Administración del cambio.
Conocimiento del modelo
IDEAL.
Patrocinador del proyecto de mejora.
Definir / aprobar los objetivos de mejora.
Alinear los objetivos de mejora con objetivos
de negocio.
Proporcionar los recursos para llevar a cabo
el proyecto (humanos, hardware, software).
Aprobar el proyecto de mejora.
Apoyar al proyecto para lograr la
implementación (quita barreras y obstáculos
que bloquean el esfuerzo de mejora).
Ayudar al equipo de proyecto a minimizar la
resistencia al cambio.
Definir las políticas y directrices de los
procesos.
Aprobar los procesos definidos.
EPG – Engineering
process group
Conocimiento del modelo
CMMI® DEV. v1.3.
Conocer técnicas de juntas
efectivas, trabajo en equipo y
toma de decisiones en
consenso.
Capacidad de negociación
con MSG y TWG’s.
Conocimiento del negocio,
organización y operación de
Xcom.
Trabajo bajo presión.
Técnicas de diagramación y
documentación de procesos.
Conocimiento completo de
Definir la estrategia de mejora e
implementación.
Mapear las actividades de los procesos vs
modelos de calidad.
Definir plan de mejora, planes de acción y
piloto de procesos.
Crear planes de acción.
Ayudar al MSG en la toma de decisiones
referentes a la implementación de los
procesos.
Gestionar los recursos del proyecto.
Monitorizar y gestionar el proyecto.
Reportar el progreso y los incidentes del
proyecto.
90
los activos de procesos de
Xcom.
Administración del cambio.
Conocimiento del modelo
IDEAL.
TWG – Technical
working group
Conocimiento del modelo
CMMI® DEV. v1.3.
Conocimiento de la
organización, pasos,
herramientas y operación
relacionado con los procesos
a su cargo.
Conocimiento de
herramientas y técnicas de
documentación de definición
de activos de procesos.
Definir las soluciones a los problemas de
proceso y de implementación de procesos.
Responsable de la documentación y
descripción de procesos de acuerdo con la
asignación realizada por el EPG.
Responsables del diseño de plantillas y
procedimientos para la ejecución del proceso.
Revisar el resultado del piloto de proceso
para hacer ajustes necesarios.
QA – Quality
Assurance
Conocimiento detallado del
modelo CMMI® DEV. v1.3.
Conocimiento de todos los
procesos organizacionales.
Conocimiento detallado del
proceso organizacional de
aseguramiento de calidad.
Conocimiento detallado en
técnicas y métodos de
auditorías de calidad.
Conocimiento de
herramientas de apoyo al
proceso de aseguramiento de
calidad y verificación.
Definir los checklist de calidad.
Asegurar que las prácticas de un modelo
estén cubiertas por un proceso, subproceso o
documento.
Actualizar planes de calidad con nuevas
auditorías.
Estas actividades serán avaluadas de acuerdo a (CMMI Product Team, 2010) en el cual se
proponen las siguientes métricas para la monitorización y el seguimiento del plan de mejora de
CMMI® para el proceso de desarrollo de software, tal como se especifican en las fórmulas 3.1 a
3.3.
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =No.de defectos solucionados
Total de defectos encontrados en pruebas 𝑥 100 (3.1)
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =No de días reales en un proyecto
No.de días estimados en un proyecto 𝑥 100 (3.2)
91
𝐆𝐚𝐧𝐚𝐧𝐜𝐢𝐚 𝐞𝐜𝐨𝐧ó𝐦𝐢𝐜𝐚 = Ingreso 𝑥 Porcentaje de comisión acordado con el cliente (3.3)
Como se puede observar, dentro de esta fase, se implementan las áreas de proceso de el nivel 2 de
CMMI®. A continuación, se detallan los formatos, políticas, manuales y procedimientos
requeridos para el cumplimiento de cada área. Los formatos que se presentan son sugeridos por el
manual de CMMI® versión 1.3, adaptados a las necesidades de Xcom (SEI CMMI Production,
2010).
3.5.3.1. REQM - Administración de Requerimientos
El objetivo de la Administración de Requerimientos es cubrir las fases de licitación, análisis,
especificación, verificación y validación, y mantenimiento para un desarrollo de software. Se
requieren políticas y documentos que gestionen los requerimientos y que permitan la validación
rápida de los mismos.
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Administrar requerimientos. Para cumplir con esta meta, se definieron
y establecieron los siguientes documentos y procedimientos:
1. Entrevistas con el cliente. Es necesario no solo realizar lo que el cliente pida, sino entender
realmente lo que el cliente necesita. Con ese principio, las entrevistas permitirán conocer el rol
principal del cliente y así desarrollar un aplicativo que cubra las necesidades del objetivo de su
negocio.
2. Después de las entrevistas, se realizará una lluvia de ideas con los involucrados en el proyecto,
para comprender los requerimientos obtenidos con el cliente. Dentro de esta reunión todos los
miembros del equipo aportan sus ideas, comentarios y observaciones del cliente.
92
3. Una vez que los miembros del equipo reunieron las ideas, se deben plasmar en un documento.
En la figura 26 se muestra la propuesta del formato para la especificación y entendimiento de
requerimientos funcionales y no funcionales.
Formato para administración de requerimientos para especificación y entendimiento de requerimientos
funcionales y no funcionales
Cliente:
Requerimientos Funcionales Interfaz Gráfica, Hardware, Software
Requerimientos No Funcionales Seguridad, Eficiencia, Usabilidad
Figura 26. Formato de descripción de requerimientos (SEI CMMI Production, 2010).
93
4. Una vez que se documentan los requerimientos, se deben generar minutas para formalizar
acuerdos. En la figura 27, se muestra el formato propuesto del acta de reunión para evidenciar los
compromisos de los requerimientos y la participación de los involucrados
Cliente:
Acuerdos
Nombre y cargo Correo y Teléfono Firma
Figura 27. Formato Acta de Reunión (SEI CMMI Production, 2010).
94
5. La formalidad en los requerimientos también consiste en aceptar cambios y no conformidades
en los aplicativos por parte del cliente, sim embargo no todos los cambios deben proceder, por lo
que se debe crear un procedimiento de tratamiento de producto no conforme y acciones
correctivas.
6. Un buen proyecto debe aprender a prever las situaciones que puedan salir de control, por ello
se debe crear un procedimiento de acciones preventivas y metodologías de análisis y solución de
problemas.
3.5.3.2. PP – Planeación de Proyectos
La ejecución de un proyecto de desarrollo de software es, en general, una tarea de considerables
proporciones que requiere que sus fases sigan un plan. Hay tres aspectos importantes que hay que
tener en cuenta para la definición de un plan: la estimación de tiempo y demás recursos, los
mecanismos de seguimiento y control de la ejecución del plan, y asegurar y controlar
permanentemente que para el cumplimiento del plan éste se difunda adecuadamente y los
involucrados adquieran los compromisos respectivos.
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Establecer estimaciones. Para cumplir con esta meta, se definieron y
establecieron los siguientes documentos y procedimientos:
1. Formato matriz de formulación de proyectos, que permite estimar el alcance del proyecto con
base en criterios generales tales como el objetivo del proyecto, los resultados esperados,
actividades y riesgos. En la figura 28, se muestra el ejemplo del formato.
95
Proyecto
Objetivo
Resultados Esperados
Actividades Riesgos
VoBo. Firma de Aprobación
Figura 28. Matriz de Formulación de proyectos (SEI CMMI Production, 2010).
96
2. Mecanismo. Lluvia de ideas, manejando el consenso grupal para establecer las estimaciones de
los productos de trabajo y tareas.
3. Definición de política sobre el modelo de ciclo de vida de los proyectos de software a seguir,
caracterizando las fases de análisis, diseño, implementación e implantación.
Meta Específica 2 – Desarrollar un plan del proyecto. Para cumplir con esta meta, se
definieron y establecieron los siguientes documentos y procedimientos:
1. Se usó como software base un programa de administración de proyectos, Microsoft Project
para realizar los cronogramas de los proyectos, con información de personas por actividad,
tiempo y ejecución de cada actividad por persona, dependencia de actividades y determinación de
la línea base. En la figura 29 se muestra la pantalla de la herramienta que se utilizará para realizar
este formato.
Figura 29. Microsoft Project para cronogramas
97
2. La planeación de proyectos es indispensable por lo que se debe generar un formato matriz de
planificación de proyectos, para establecerlos, con las directrices de la metodología de gestión de
proyectos. En la figura 30 se puede ver la estructura del formato mencionado.
Matriz de planificación de Proyectos
Objetivo General
Objetivo Proyecto
Destinatarios
Productos/Estrategias
Actividades
Figura 30. Matriz de planificación de proyectos (SEI CMMI Production, 2010).
98
3. Formato matriz de planificación de proyectos, para registrar y administrar los riesgos
identificados. Adicionalmente permite planear los recursos del proyecto. En la figura 31 se
muestra el formato mencionado.
Id Riesgo Descripción del Riesgo Riesgo Amenazas Agente de la amenaza
Riesgo de ejemplo
Divulgación no autorizada de
información y Pérdida de
disponibilidad de servicios o
información por Código
malicioso, Software obsoleto,
Extorsión, Código malicioso a
causa de Proveedor /
Contratista, Comunidad, Grupo
terrorista, Milicia extranjera,
Servicios inteligencia /
contrainteligencia, Personal
inerno, Ex-empleado, Personal
interno descontento
(intencional), Hacker, Script
Kiddies en Activo de ejemplo
por Vulnerable a Eternalblue
Divulgación no autorizada de información y Pérdida de disponibilidad de
servicios o información
Código malicioso,
Software obsoleto,
Extorsión, Código
malicioso
Proveedor / Contratista, Comunidad,
Grupo terrorista, Milicia extranjera,
Servicios inteligencia /
contrainteligencia, Personal inerno,
Ex-empleado, Personal interno
descontento (intencional), Hacker,
Script Kiddies
Riesgo de ejemplo
Divulgación no autorizada de
información y Pérdida de
disponibilidad de servicios o
información por Código
malicioso, Software obsoleto,
Extorsión, Código malicioso a
causa de Proveedor /
Contratista, Comunidad, Grupo
terrorista, Milicia extranjera,
Servicios inteligencia /
contrainteligencia, Personal
inerno, Ex-empleado, Personal
interno descontento
(intencional), Hacker, Script
Kiddies en Activo de ejemplo
por Uso de Windows XP
Divulgación no autorizada de información y Pérdida de disponibilidad de
servicios o información
Código malicioso,
Software obsoleto,
Extorsión, Código
malicioso
Proveedor / Contratista, Comunidad,
Grupo terrorista, Milicia extranjera,
Servicios inteligencia /
contrainteligencia, Personal inerno,
Ex-empleado, Personal interno
descontento (intencional), Hacker,
Script Kiddies
Figura 31. Formato de Planificación de Proyectos (SEI CMMI Production, 2010).
99
4. Se debe crear un repositorio central para administrar los datos de los proyectos. Para este fin
se ocupará la herramienta GitHub, que permitirá llevar un control de cambios y versiones de los
aplicativos, así como delimitar las funciones del equipo de desarrollo de un proyecto.
En la figura 32, se muestra la pantalla principal de GitHub, y las principales funciones.
Figura 32. Repositorio GIT
5. Matriz de competencias, donde se pueden consultar los perfiles necesarios del recurso humano
que se pueda requerir. En este caso, todo el personal de la GDSI deberá enviar su Curriculum
Vitae al gerente. Se evaluará las competencias de cada uno de los miembros del área y si existen
deficiencias, se capacitará al personal que así lo requiera. Esto no solo permitirá que los recursos
humanos se actualicen, sino también los hará sentirse valiosos dentro de un equipo de trabajo al
poder involucrarlos en más actividades.
100
Meta Específica 3 – Obtener compromisos con el plan. Para cumplir con esta meta, se
definieron y establecieron los siguientes documentos y procedimientos:
1. Se definió como política organizacional que:
“Los coordinadores de los proyectos con su grupo de trabajo deben evaluar los planes y riesgos
que afecten la ejecución y el plan del proyecto”
2. Se evalúan, en reuniones de seguimiento, la consistencia entre el recurso estimado y el
disponible, para realizar la planeación de los proyectos de una mejor manera.
3. Formato matriz de planificación de proyectos y cronograma, donde quedan establecidos los
compromisos de cada actividad y los responsables. Se debe agregar las firmas de compromiso
correspondientes.
3.5.3.3. PMC – Monitorización y Control de Proyectos
Para asegurar la adecuada ejecución de un proyecto de desarrollo de software, las fases definidas
en su planeación deben vigilarse y controlarse, y en caso de que en la ejecución existan
desviaciones con respecto a la planeación, el plan mismo y sus compromisos deben ajustarse.
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Monitorear el proyecto respecto al plan.
Para cumplir con esta meta, se definieron y establecieron los siguientes documentos y
procedimientos:
1. Se estableció un documento formal con los puntos que se monitorean y controlan en los planes.
Los monitoreos se realizan en reuniones periódicas de seguimiento.
2. Formato acta de reunión donde se registrará las evaluaciones de los compromisos trazados en
las reuniones de seguimiento al plan.
101
3. Se definió como política organizacional:
“Monitorear los riesgos del proyecto en las reuniones de seguimiento al plan, basándose en los
riesgos documentados en la matriz de planificación de proyectos”
Meta Específica 2 – Administrar las medidas correctivas a ser tomadas. Para cumplir con
esta meta, se definieron y establecieron los siguientes documentos y procedimientos:
1. Formato acta de seguimiento, donde se registran los inconvenientes y acciones
correspondientes.
2. Planes de corrección, a partir de las acciones correctivas generadas.
3. Se definió como política organizacional, diligenciar formatos por cada inconsistencia,
registrando sus causas y soluciones, y almacenarlos en la carpeta del proyecto.
3.5.3.4. AP – Administración de Proveedores
Esta área de proceso establece las metas que deben cumplirse con respecto a la gestión
formalizada de proveedores, que debe estar definida y monitoreada, sobre todo en los aspectos de
criterios y condiciones de aceptación de productos.
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Establecer acuerdos con los proveedores. Para cumplir con esta meta se
definieron y establecieron los siguientes documentos y procedimientos:
1. Manual de aseguramiento de calidad para proveedores, donde se define el proceso de
adquisición de productos y/o servicios externos.
2. Formato de requisición de bienes y/o servicios, para registrar los datos del producto a adquirir
dentro de Xcom.
3. Guía de referencia para evaluación de proveedores, donde se definen los puntos de evaluación
de proveedores, lo cual permitirá clasificar los proveedores.
FASE DE ACTUACIÓN
102
4. Formato de calificación mensual de desempeño, para registrar el seguimiento a los acuerdos
con los proveedores y evaluación a los mismos.
Meta Específica 2 – Satisfacer los acuerdos con los proveedores. Para cumplir con esta meta
se definieron y establecieron los siguientes documentos y procedimientos:
1. Formato para el plan de verificación y validación, para realizar seguimiento a la ejecución de
acuerdos con el proveedor.
2. Se define la política:
“La aceptación de los productos depende de los resultados de los procesos de verificación y
validación”
3.5.3.5. MA – Medición y Análisis
Las actividades críticas que comprenden los procesos de desarrollo de software deben contar con
registros de datos relativos a su desempeño, y que permitan realizar un análisis cuantitativo de los
respectivos procesos. El resultado de este análisis debe servir para tomar decisiones, acciones
correctivas y de re-planeación en caso de que se requiera.
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Alinear actividades de medición y análisis. Para cumplir con esta
meta se definieron y establecieron los siguientes documentos y procedimientos:
1. En un documento formal se identificaron las necesidades de medición, alineadas con las
necesidades de información y los objetivos estratégicos de la empresa, los procesos críticos del
desarrollo de software.
2. Se definió como política organizacional que para los procedimientos de recolección de datos se
deben utilizar las herramientas de software desarrolladas por la empresa.
103
Meta Específica 2 – Suministrar resultados de medición.
Para cumplir con esta meta se definieron y establecieron los siguientes documentos y
procedimientos:
1. Se definieron las siguientes políticas organizacionales como primera política organizacional en
este aspecto:
“Realizar reuniones mensuales del comité de calidad para analizar los datos de medición”
“Los datos de medición y los resultados de análisis deben ser administrados y almacenados en
las herramientas de apoyo”
2. Se definió un formato de comunicados escritos, que debe utilizarse para presentar los
resultados de las mediciones e indicadores, y sus respectivos análisis.
3. Roger S. Pressman define en su libro “Ingeniería de Software: un enfoque práctico”, la
importancia de realizar mediciones dentro de una organización:
“1) para caracterizar un esfuerzo y obtener comprensión “de los procesos, productos, recursos y
entornos, y establecer líneas de referencia para comparar con valoraciones futuras”; 2) para
evaluar y “determinar el estado de avance con respecto a los planes”; 3) para predecir al “obtener
comprensión de las relaciones entre procesos y productos, y construir modelos de dichas
relaciones”, y 4) para mejorar al “identificar barricadas, causas raíz, ineficiencias y otras
oportunidades para mejorar la calidad del producto y el desempeño del proceso” (Pressman,
2010),
Es por ello, que se usan las métricas 3.1 a la 3.3 descritas anteriormente, ya que se determina la
importancia de medir la calidad y eficiencia de los proyectos, así como la ganancia económica
que representa el desarrollo de cada proyecto:
Para la métrica de calidad, se diseña un formato de descripción de defectos, el cual se muestra en
la figura 33. Se puede observar que hay un campo de impacto y otro un indicador de evaluación
104
que se utilizará en las pruebas del aplicativo para determinar si el cliente acepta o no la
corrección del defecto. Este formato es sugerido por el manual de CMMI® versión 1.3. (SEI
CMMI® Production, 2010).
Figura 33. Formato de Descripción de Defectos
3.5.3.6. PPQA – Aseguramiento de Calidad de Procesos y Productos
El software presenta una dualidad en su naturaleza, como producto y como conocimiento, que se
materializa como resultado del proceso de su desarrollo. De esta manera, para asegurar su
calidad, es necesario adelantar tareas de revisión, evaluación, verificación y validación, tanto en
las distintas fases del proceso de su desarrollo como en el producto final, y realizar las acciones
correctivas respectivas. Estas tareas pueden formalizarse, por ejemplo, mediante auditorías de
calidad.
105
Meta Específica 1 – Evaluar objetivamente procesos y productos de trabajo. Para cumplir
con esta meta, se definieron y establecieron los siguientes documentos y procedimientos:
1. Manual de referencia de auditorías internas de calidad, en donde se definen los criterios que
deben ser evaluados en los procesos.
2. Formato de referencia de auditorías internas de procesos, donde se registran las actividades
auditadas, hallazgos y observaciones.
3. Formato de calificación de auditores.
4. Referencia de auditorías internas para productos, donde se definen los criterios de evaluación
de productos y servicios.
5. Metodología de pruebas para sistemas de información.
Meta Específica 2 – Suministrar una visión objetiva. Para cumplir con esta meta, se
definieron y establecieron los siguientes documentos y procedimientos:
1. Procedimiento tratamiento producto no conforme y acciones correctivas, donde se establece la
manera de identificar, determinar los controles, responsabilidades y autoridades relacionadas con
la no conformidad.
2. Se definió como política organizacional, comunicar las no conformidades y su gestión en los
comités de calidad a la alta dirección.
3. Repositorio central para almacenar los documentos de no conformidades para facilitar el
manejo de estadísticas y evolución de estas.
3.5.3.7. CM – Administración de la Configuración
Los productos de software se componen de múltiples elementos que, por su naturaleza,
evolucionan y deben estar cambiando constantemente.
Estos elementos se denominan ítems de configuración, y, dada su criticidad, sobre todo en
aquellos que son parte del código, sus versiones deben estar debidamente controladas, al igual
que las versiones globales del producto que ellos componen. Esta área de proceso considera todos
los aspectos relativos al mantenimiento de las versiones de los ítems de configuración, lo cual
incluye su control de cambios, rastreabilidad e integridad global.
106
Procedimientos y documentos definidos para cumplir con los objetivos del área de proceso.
Meta Específica 1 – Establecer línea base. Para cumplir con esta meta se definieron y
establecieron los siguientes documentos y procedimientos:
1. Proceso de administración de la configuración, donde se establece lista estándar de ítems de
configuración y atributos base para formar las líneas base de cada producto.
2. Se definió como política organizacional:
“Controlar el código fuente en un servidor central para almacenar la información general de los
proyectos”
Meta Específica 2 – Monitoreo y control de cambios. Para cumplir con esta meta, se
definieron y establecieron los siguientes documentos y procedimientos:
1. Formato solicitud de cambios a ítems de configuración, para registro y control de los cambios
a los ítems de configuración.
Meta Específica 3 – Establecer integridad. Para cumplir con esta meta, se definieron y
establecieron los siguientes documentos y procedimientos:
1. Se definió como política organizacional:
“Realizar auditorías de integridad de las líneas base por parte del área de Auditoría Interna”
107
CAPÍTULO 4. HALLAZGOS Y ANÁLISIS DE LOS
RESULTADOS
Al poner en práctica las áreas de proceso de CMMI® nivel 2 y desarrollar los mismos sistemas
presentados en el capítulo 2, dentro del mismo periodo de tiempo, se puede evaluar los resultados
obtenidos y el tiempo de desarrollo estimado para cada proyecto.
Se evaluarán los indicadores presentados al inicio del capítulo 3, para verificar los cambios a los
procesos en calidad y eficiencia.
La aplicación de las áreas de proceso de nivel CMMI® para los proyectos que se mencionan a
continuación se resume de la siguiente manera en la tabla 14:
Tabla 14. Resumen de Cumplimiento CMMI® nivel 2
ÁREA DE PROCESO CUMPLIMIENTO
REQM - ADMINISTRACION DE
REQUERIMIENTOS
Elaboración de cuestionarios a clientes
para conocer sus necesidades
Formatos para el claro entendimiento de
los requerimientos
Reuniones con el equipo de trabajo,
técnica lluvia de ideas, planteamiento de
la solución
PP – PLANEACIÓN DE
PROYECTOS
Delimitación de actividades
Asignación de recursos (materiales,
económicos y humanos)
Elaboración del plan de trabajo a alto
nivel
PMC – MONITORIZACIÓN Y
CONTROL DE PROYECTOS
Reuniones semanales para el registro y
control de avances.
108
Revisión de hitos en el proyecto
AP – ADMINISTRACIÓN DE
PROVEEDORES
Los proyectos no requieren de servicios
adicionales de proveedores
MA – MEDICIÓN Y ANÁLISIS
Definición de métricas de calidad,
eficiencia y ganancia de Xcom
Verificación de métricas mediante
reuniones
PPQA – ASEGURAMIENTO DE
CALIDAD DE PROCESOS Y
PRODUCTOS
Definición de grupo de aseguramiento de
la calidad
Auditorías internas en la GDSI, para
determinar el cumplimiento de metas.
CM – ADMINISTRACIÓN DE LA
CONFIGURACIÓN
Control de versiones
Control de cambios en código mediante
un documento oficial
4.1. Evaluación del Aplicativo SASE
La evaluación del aplicativo SASE consiste en realizar el cálculo de las tres métricas definidas:
calidad, eficiencia y ganancia de Xcom.
4.1.1. Cálculo de la Calidad en Aplicativo SASE
La evaluación de la calidad está relacionada con el número de defectos de un aplicativo. Se le
denomina defecto a todo aquello que no cumpla con los requerimientos iniciales del cliente.
(Caballero, Calvo-Manzano Villalón, Cuevas Agustín, & San Feliu Gilabert, 2009). Lo anterior
se obtiene directamente de las pruebas iniciales que realiza la GDSI y consiste en el llenado del
formato diseñado para ello (ver figura 33). La figura 34 muestra los defectos encontrados en las
pruebas internas de la GDSI.
109
Una vez que se realiza el listado de defectos, se anota el impacto que tendrá el defecto en el
funcionamiento del sistema. Como podemos observar, dentro del indicador de evaluación se
encuentran dos defectos no aceptables, lo que significa que, aunque fueron “No Aceptables”, se
permitió marcar como completados dentro del estatus.
Figura 34. Descripción de defectos SASE
Por lo tanto, se llega a la conclusión de que los defectos encontrados son diez y los que se
solucionaron fueron ocho.
Aplicando la métrica de calidad y al sustituir los valores en la fórmula 3.1, tenemos lo siguiente:
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =No. de defectos solucionados
Total de defectos encontrados en pruebas 𝑥 100
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =8
10 𝑥 100
110
% de calidad = 80%
Como en todos los proyectos, en este caso de diez defectos que se encontraron se solucionaron
ocho. Los dos restantes cumplieron con aceptación del cliente por no ser relevantes al
funcionamiento de la aplicación, por lo que se logra un % de calidad de 80% aceptable por el
cliente.
4.1.2. Cálculo de la Eficiencia en Aplicativo SASE
Con la aplicación de CMMI® nivel 2, se permitió construir un nuevo plan de trabajo. En la tabla
15, se muestra la asignación de recursos necesarios y los tiempos para cada actividad.
Tabla 15. Plan de trabajo de alto nivel SASE
Actividad Recurso Tiempo
(Días) Fecha Inicio Fecha Término
Recepción de
Requerimiento Analista 2 días 27/11/17 28/11/17
Junta con Equipo de
Trabajo
Analista
Desarrollador 1
Desarrollador 2
Desarrollador 3
Tester
Auditor
1 día 29/11/17 29/11/17
Lluvia de Ideas
Analista
Desarrollador 1
Desarrollador 2
Desarrollador 3
Tester
Auditor
1 día 30/11/17 30/11/17
Llenado de formatos para Analista 1 día 01/12/17 01/12/17
111
el levantamiento de
requerimientos
Tester
Auditor
Elaboración de Acta de
Proyecto Analista 5 días 02/12/17 07/12/17
Elaboración de Plan de
Trabajo Analista 7 días 08/12/17 18/12/17
Diseño de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
5 días 19/12/17 25/12/17
Codificación de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
50 días 26/12/17 05/03/18
Pruebas Internas (GDSI)
Analista
Tester
Auditor
5 días 06/03/18 12/03/18
Pruebas Operativas Área Operativa 7 días 13/03/18 21/03/18
Aplicativo en Desarrollo Área Operativa 7 días 22/03/18 30/03/18
Aplicativo en Ambiente QA Auditor 7 días 30/03/18 09/04/18
Aplicativo en Producción Área Operativa 7 días 09/04/18 17/04/18
Total de Días 105 días
El proyecto se planeaba finalizara el 17 de abril del 2018, sin embargo, debido a que las
actividades fueron mejor organizadas, el aplicativo se encontró en producción el 01 de abril de
2018, lo cual nos indica que el proyecto se desarrolló en 90 días en vez de 105.
Al aplicar la fórmula 3.2, para calcular la eficiencia tenemos lo siguiente:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 = No de días reales en un proyectoNo.de días estimados en un proyecto
𝑥 100
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =90
105 𝑥 100
112
% de eficiencia = 85.71% 1
El porcentaje de eficiencia fue de 85.71%. Esto fue debido a que el proyecto se terminó antes de
lo acordado. Lo anterior se debe a que los recursos se administraron de una mejor manera, ya no
solo había un solo desarrollador en el cual caía toda la responsabilidad de entregar en tiempo y
forma.
4.1.3. Cálculo de la Ganancia en Aplicativo SASE
Una de las métricas más importantes representa los beneficios económicos para Xcom. Para
calcularla, tenemos la fórmula descrita anteriormente 3.3:
𝐆𝐚𝐧𝐚𝐧𝐜𝐢𝐚 𝐞𝐜𝐨𝐧ó𝐦𝐢𝐜𝐚 = Ingreso 𝑥 Porcentaje de comisión acordado con el cliente
Para el aplicativo SASE, el porcentaje de comisión acordado es de 25%, por lo que, en la tabla
16, se muestran las operaciones, el ingreso y la ganancia obtenida, aplicando MAAGTICSI y
aplicando CMMI® nivel 2.
Tabla 16. Operaciones SASE por mes aplicando MAAGTICSI Y CMMI® nivel 2
MAAGTICSI
Mes No. de
Operaciones Ingreso
Ganancia
Xcom
Ganancia
SASE
Abril 0 $ 0.00 $ 0.00 $ 0.00
Mayo 5, 203 $ 10,039,284.50 $2,509,821.13 $7,529,463.38
Junio 7, 178 $ 17,407,513.00 $4,351,878.25 $13,055,634.75
Julio 4, 564 $ 8,467,923.86 $2,116,980.97 $6,350,942.90
TOTALES $35,914,721.36 $8,978,680.34 $26,936,041.02
CMMI® NIVEL 2
Mes No. de
Operaciones Ingreso
Ganancia
Xcom
Ganancia
SASE
Abril 4, 340 $ 9,453,987.23 $ 2,363,496.81 $ 7,090,490.42
1 En Xcom. si la eficiencia es mayor a 100% significa que no se desarrolló eficientemente el sistema, por lo que se
considera que este valor al aplicar la fórmula debe estar entre 80% y 100% para conseguir una eficiencia deseada.
113
Mayo 5, 500 $ 11,362,453.48 $ 2,840,613.37 $ 8,521,840.11
Junio 8, 164 $ 19,876,351.90 $ 4,969,087.98 $14,907,263.93
Julio 6, 743 $ 13,215,339.50 $ 3,303,834.88 $ 9,911,504.63
TOTALES $53,908,132.11 $13,477,033.03 $40,431,099.08
Como se puede notar, dentro de los datos recabados con CMMI® nivel 2, se tienen operaciones
registradas en abril, pues el aplicativo logró estar en producción en ese mes, a diferencia del
SASE desarrollado con MAAGTICSI, el cual estuvo en producción hasta el mes de mayo.
Aunque los sistemas se encontraban en paralelo y ambos sistemas se guardaban en servidores de
producción, cada mes reportan un número de operaciones diferente. Esto se debe a que el
aplicativo desarrollado con MAAGTICSI, aun estando en producción presentaba muchas fallas y
detenía el servicio, por lo que en esos lapsos solo se registraban las operaciones que el aplicativo
con CMMI® nivel 2 guardaba en la base de datos de Xcom.
En la figura 35, se muestra una gráfica con el número de operaciones registradas con el aplicativo
SASE desarrollado con MAAGTICSI y con CMMI® nivel 2.
114
Figura 35. Comparación de operaciones SASE
4.2. Evaluación del Aplicativo JAIS
La evaluación del aplicativo JAIS consiste en realizar el cálculo de las tres métricas definidas:
calidad, eficiencia y ganancia de Xcom.
4.2.1. Cálculo de la Calidad en Aplicativo JAIS
Para este aplicativo, también se cuenta con la descripción de defectos, éstos se describen en la
figura 36.
115
Figura 36. Descripción de Defectos JAIS
En este aplicativo se encontraron 10 defectos, los cuales se corrigieron y resultaron aceptables
por el cliente, por lo que el cálculo del porcentaje de calidad quedaría de la siguiente manera,
utilizando la fórmula 3.1.
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =No. de defectos solucionados
Total de defectos encontrados en pruebas 𝑥 100
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =10
10 𝑥 100
% de calidad = 100%
Los defectos encontrados se realizaron en tiempo y forma antes de la puesta en marcha en
producción, por lo que este aplicativo tuvo un porcentaje de calidad del 100% al detectar
tempranamente los defectos que pudieron ocasionar inconvenientes en la ejecución del aplicativo.
116
4.2.2. Cálculo de la Eficiencia en Aplicativo JAIS
En la tabla 17, se muestra el plan de trabajo correspondiente al aplicativo JAIS, con todas las
actividades que componen la elaboración del proyecto, así como las personas involucradas y los
tiempos que durará cada una de las actividades a desempeñar.
Tabla 17. Plan de trabajo de alto nivel JAIS
Actividad Recurso Tiempo
(Días) Fecha Inicio Fecha Termino
Recepción de Requerimiento Analista 2 días 02/10/17 03/10/17
Junta con Equipo de
Trabajo
Analista
Desarrollador 1
Desarrollador 2
Desarrollador 3
Tester
Auditor
1 día 04/10/17 04/10/17
Lluvia de Ideas
Analista
Desarrollador 1
Desarrollador 2
Desarrollador 3
Tester
Auditor
1 día 05/10/17 05/10/17
Llenado de formatos para el
levantamiento de
requerimientos
Analista
Tester
Auditor
1dìa 06/10/17 06/10/17
Elaboración de Acta de
Proyecto Analista 7 días 09/10/17 17/10/17
Elaboración de Plan de
Trabajo
Analista
Tester 7 días 18/10/17 26/10/17
117
Conexión al Web Service
Desarrollo 1
Desarrollo 2
Desarrollo 3
15 días 27/10/17 16/11/17
Solicitud de Insumos para
pruebas WebService Analista 10 días 17/11/17 30/11/17
Diseño de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
5 días 01/12/17 07/12/17
Ambientación Desarrollador 1 10 días 08/12/17 21/12/17
Codificación de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
50 días 22/12/17 01/03/18
Pruebas Internas (GDSI) Analista 7 días 01/03/18 09/03/18
Pruebas Operativas
Analista
Desarrollador 7 días 09/03/18 19/03/18
Aplicativo en Desarrollo Área Operativa 7 días 19/03/18 27/03/18
Aplicativo en Ambiente QA Auditor 7 días 27/03/18 04/04/18
Aplicativo en Producción Área Operativa 7 días 05/04/18 13/04/18
Total de días 144 días
El aplicativo inició el 02 de octubre de 2017 y se planeaba terminarlo en 144 días, sin embargo,
el 11 de abril de 2018 el aplicativo se liberó a producción, por lo que los días reales para el
desarrollo del proyecto fueron 142 días.
Para calcular el porcentaje de eficiencia de este proyecto, se aplica la fórmula 3.2, descrita
anteriormente:
118
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =No. de días reales en un proyecto
No. de días estimados en un proyecto 𝑥 100
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =142
144 𝑥 100
% de eficiencia = 98.61%
La eficiencia del aplicativo es de 98.61%, lo cual resulta favorable para la entrega y puesta en
producción del aplicativo.
4.2.3. Cálculo de la Ganancia en Aplicativo JAIS
Para el cálculo de la ganancia dentro del aplicativo JAIS se tiene que aplicar la fórmula 3.3:
𝐆𝐚𝐧𝐚𝐧𝐜𝐢𝐚 𝐞𝐜𝐨𝐧ó𝐦𝐢𝐜𝐚 = Ingreso 𝑥 Porcentaje de comisión acordado con el cliente
Siendo que para este aplicativo se acordó un porcentaje de 15% de comisión del ingreso por las
operaciones. En la tabla 18, se muestra la información de las operaciones, los ingresos y la
ganancia económica obtenida.
Tabla 18. Operaciones JAIS por mes aplicando MAAGTICSI Y CMMI® nivel 2
MAAGTICSI
Mes No. de
Operaciones Ingreso
Ganancia
Xcom Ganancia JAIS
Abril 0 $0.00 $0.00 $0.00
Mayo 1,371 $ 2,532,262.16 $ 379,839.32 $2,152,422.84
Junio 1,684 $ 4,388,701.95 $ 658,305.29 $3,730,396.66
Julio 1,211 $ 1,586,500.00 $ 237,975.00 $1,348,525.00
TOTALES $ 8,507,464.11 $1,276,119.62 $7,231,344.49
CMMI® NIVEL 2
Mes No. de
Operaciones Ingreso
Ganancia
Xcom Ganancia JAIS
Abril 1,690 $ 2,140,294.43 $ 321,044.16 $ 1,819,250.27
119
En la figura 37, se muestra mediante una gráfica el comparativo de las operaciones que se
registraron con el aplicativo JAIS aplicando MAAGTICSI y las operaciones que se registraron
con el aplicativo implementando CMMI® nivel 2.
Figura 37. Comparación de operaciones JAIS
0
500
1000
1500
2000
2500
3000
Abril Mayo Junio Julio
Aumento en Operaciones JAIS
MAAGTICSI CMMI NIVEL 2
Mayo 2,000 $ 3,632,244.78 $ 544,836.72 $ 3,087,408.06
Junio 1,900 $ 5,563,190.89 $ 834,478.63 $ 4,728,712.26
Julio 2,400 $ 4,643,320.40 $ 696,498.06 $ 3,946,822.34
TOTALES
$15,979,050.50 $2,396,857.58 $13,582,192.93
120
4.3. Evaluación del Aplicativo HIDS (Sector Público)
La evaluación del aplicativo HIDS (SECTOR PÚBLICO) consiste en realizar el cálculo de las
tres métricas definidas: calidad, eficiencia y ganancia de Xcom.
4.3.1. Cálculo de la Calidad en Aplicativo HIDS (Sector Público)
El Formato de descripción de defectos para el aplicativo HIDS (SECTOR PÚBLICO), se muestra
en la figura 38.
Figura 38. Descripción de Defectos HIDS (SECTOR PÚBLICO)
Podemos notar que en esta ocasión solo se encontraron cinco defectos de alto impacto, los cuales
después de su corrección se marcaron como aceptables, tal como se puede visualizar en la figura
38.
El cálculo de la calidad quedaría de la siguiente manera, mediante la fórmula 3.1:
121
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =No. de defectos solucionados
Total de defectos encontrados en pruebas 𝑥 100
% 𝐝𝐞 𝐜𝐚𝐥𝐢𝐝𝐚𝐝 =5
5 𝑥 100
% de calidad = 100%
Los defectos encontrados se realizaron en tiempo y forma antes de la puesta en marcha en
producción, por lo que tuvo calidad de 100% aprobada por el cliente.
4.3.2. Cálculo de la Eficiencia en Aplicativo HIDS (Sector Público)
Para el cálculo de la eficiencia, es necesario conocer el plan de trabajo de alto nivel que se realizó
para el proyecto HIDS (SECTOR PÚBLICO). En la tabla 19 se muestran las actividades y
duración de estas para el desarrollo del proyecto.
Tabla 19. Plan de trabajo de alto nivel HIDS (SECTOR PÚBLICO)
Actividad Recurso Tiempo
(Días) Fecha Inicio Fecha Termino
Recepción de Requerimiento Analista 2 días 04/07/17 06/07/17
Junta con Equipo de Trabajo
Analista
Desarrollador 1
Desarrollador 2
Desarrollador 3
Tester
Auditor
1 día 06/07/17 06/07/17
Lluvia de Ideas
Analista
Desarrollador 1
Desarrollador 2
1 día 07/07/17 07/07/17
122
Desarrollador 3
Tester
Auditor
Llenado de formatos para el
levantamiento de
requerimientos
Analista
Tester
Auditor
1 día 10/07/17 10/07/17
Elaboración de Acta de
Proyecto Analista 7 días 11/07/17 19/07/17
Elaboración de Plan de
Trabajo
Analista
Tester 7 días 20/07/17 28/07/17
Construcción de Módulo HOST TO HOST
Conexión WebService
Desarrollador 1
Desarrollador 2
Desarrollador 3
15 días 31/07/17 18/08/17
Solicitud de Insumos para
pruebas Analista 10 días 21/08/17 01/09/17
Diseño de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
5 días 04/09/17 29/09/17
Ambientación Desarrollador 1 10 días 02/10/17 13/10/17
Codificación de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
30 días 16/10/17 01/12/17
Construcción de Módulo BATCH
Diseño de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
10 días 04/12/17 29/12/17
Codificación de Pantallas
Desarrollador 1
Desarrollador 2
Desarrollador 3
10 días 01/01/18 26/01/18
Pruebas Internas (GDSI) Auditor 10 días 29/01/18 06/02/18
123
Pruebas Operativas Área Operativa 7 días 07/02/18 15/02/18
Aplicativo en Desarrollo Área Operativa 7 días 16/02/18 26/02/18
Aplicativo en Ambiente QA Auditor 7 días 27/02/18 07/03/18
Aplicativo en Producción Área Operativa 7 días 08/03/18 16/03/18
184 días
En el caso de este proyecto, se planteó iniciará el 04 de julio de 2017 y se planea termine el 16 de
marzo del 2018.
El aplicativo se liberó a producción exactamente el 16 de marzo de 2018, por lo que los días
reales del proyecto fueron 184.
Para obtener el porcentaje de eficiencia, se tiene lo siguiente mediante la aplicación de la fórmula
3.2:
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =No de días reales en un proyecto
No. de días estimados en un proyecto 𝑥 100
% 𝐝𝐞 𝐞𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐢𝐚 =184
184 𝑥 100
% de eficiencia = 100 %
4.3.3. Cálculo de la Ganancia en Aplicativo HIDS (Sector Público)
Para el cálculo de la ganancia dentro del aplicativo HIDS (SECTOR PÚBLICO) se tiene que
aplicar lo siguiente:
𝐆𝐚𝐧𝐚𝐧𝐜𝐢𝐚 𝐞𝐜𝐨𝐧ó𝐦𝐢𝐜𝐚 = Ingreso 𝑥 Porcentaje de comisión acordado con el cliente
124
Siendo que para este aplicativo se acordó un porcentaje de 25% de comisión del ingreso por las
operaciones. En la tabla 20, se muestra la información de las operaciones, los ingresos y la
ganancia económica obtenida para el aplicativo HIDS (SECTOR PÚBLICO).
Tabla 20. Operaciones HIDS (SECTOR PÚBLICO) por mes aplicando MAAGTICSI Y
CMMI® nivel 2
MAAGTICSI
Mes No. de
Operaciones Ingreso
Ganancias
Xcom
Ganancias
HIDS (SECTOR
PÚBLICO)
Marzo 0 $ 0.00 $ 0.00 $ 0.00
Abril 0 $ 0.00 $ 0.00 $ 0.00
Mayo 9090 $ 2,481,846.00 $ 620,461.50 $1,861,384.50
Junio 8405 $ 1,217,973.53 $ 304,493.38 $ 913,480.15
Julio 10560 $ 3,943,331.92 $ 985,832.98 $2,957,498.94
TOTALES
$ 7,643,151.45 $1,910,787.86 $5,732,363.59
DESPÚES DE CMMI® NIVEL 2
Mes No. de
Operaciones Ingreso
Ganancias
Xcom
Ganancias
HIDS (SECTOR
PÚBLICO)
Marzo 4200 $956,903.45 $239,225.86 $717,677.59
Abril 9130 $1,912,376.76 $478,094.19 $1,434,282.57
Mayo 9120 $ 2,981,846.00 $ 745,461.50 $ 2,236,384.50
Junio 9203 $ 1,915,976.76 $ 478,994.19 $ 1,436,982.57
Julio 11608 $ 4,342,131.40 $1,085,532.85 $ 3,256,598.55
TOTALES $12,109,234.37 $3,027,308.59 $9,081,925.78
Como puede notarse, gracias a que el proyecto se desarrolló en tiempo y forma, se pudieron
realizar operaciones meses antes inclusive que el aplicativo implementado con MAAGTICSI se
liberara a producción.
En la figura 39, se muestran las operaciones con respecto al aplicativo implementado con
MAAGTICSI y con la implementación CMMI® nivel 2.
125
Figura 39. Comparación de operaciones HIDS (SECTOR PÚBLICO)
0 0
90908405
10560
4200
9130 9120 9203
11608
0
2000
4000
6000
8000
10000
12000
14000
Marzo Abril Mayo Junio Julio
Operaciones HIDS (SECTOR PÚBLICO)
MAAGTICSI
CMMI NIVEL 2
126
4.4. Entrevistas
La entrevista es la práctica que permite obtener información de primera mano. En el caso de las
entrevistas estructuradas, se realizan mediante un cuestionario donde se van asentando las
respuestas del entrevistado (Ortiz Uribe & García Nieto, 2009).
Las siguientes entrevistas se realizaron a 10 miembros del personal de la GDSI que participó en
la implementación del programa de mejora con CMMI®, estas entrevistas nos permiten conocer
los resultados de la aplicación de este modelo.
Miembro MSG- SUBDIRECTOR DE DESARROLLOS INFORMÁTICOS
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: Con MAAGTICSI se convirtió por mucho tiempo en un grave problema llamado
“formatitis”, el cual, en vez de apoyar a la automatización y control de procesos, con el paso
del tiempo, los entorpecía. CMMI®, por otro lado, vino a reestructurar la manera de pensar
y de trabajar así que no puede decirse que es solo llenar formatos sino es crear un hábito
para mejorar cada día.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Mejor comunicación entre áreas, mayor agilidad en los procesos, menos errores y con
respecto al ingreso económico se obtiene un mayor beneficio monetario.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: Resistencia al cambio, miedo al fracaso
127
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: Llevar mejor orden en todas las actividades
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si es útil
Miembro MSG- GERENTE
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: A pesar de que ambas son metodologías, tienen diferente forma de guiar a un equipo de
trabajo hacia un objetivo.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Los beneficios fueron el establecer más claramente los requerimientos del usuario,
agilizar el proceso de análisis y facilitar la implementación del desarrollo.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: El inconveniente principalmente fue la resistencia al cambio y a modificar la manera de
trabajar.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
128
R: Ayuda a eficientar los requerimientos, así como unificar esos requerimientos con el
desarrollo de software.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R= Si es muy útil por que agiliza el proceso y sería viable en cuanto se modifiquen los
paradigmas de trabajo
Miembro EPG- ANALISTA
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: El significado de equipo de trabajo no es el mismo en ambas metodologías.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Mayor control en los procesos, mayor comunicación entre áreas
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: La incertidumbre de no saber si el esfuerzo valdrá la pena o se fracasará.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: Llevar un mejor control en todo
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
129
R: Si es viable, inclusive siempre queda la idea de seguir mejorando, una vez llevando a
cabo los procesos de CMMI®.
Miembro TWG – DESARROLLADOR 1
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: Los procesos que ambos tienen, son muy diferentes.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Mayor estructura en el desarrollo de proyectos
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: Miedo al cambio
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: Tener un mayor estándar hasta dentro el código de las aplicaciones
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si, y si creo que sea viable
130
Miembro TWG – DESARROLLADOR 2
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: El manejo de errores y el desarrollo intuitivo de las aplicaciones
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Mejora continua, mayor cumplimiento en las entregas de los proyectos.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: Miedo al fracaso, a que se invierta un tiempo que no valdrá la pena en un proyecto
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: Controlar mayormente la parte de codificación al documentar las líneas de código
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si, pienso que, si en el nivel 2 se pudieron encontrar mejoras considerables, conforme se
vaya avanzando en nivel, se podrán alcanzar mejoras considerables.
131
Miembro TWG – DESARROLLADOR 3
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: Que no se tenía un control tan estructurado como con CMMI® nivel 2
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Mayor comunicación entre las áreas y el equipo de trabajo de la GDSI.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: Que muchos estamos acostumbrados a trabajar solos porque siempre se ha tenido un
desarrollo por persona, entonces el modificar eso y trabajar como equipo de trabajo fue lo
que a mi parecer fue un inconveniente.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: Principalmente al tener estándares en la programación, documentarlos, ya que es más
sencillo explorar el código cuando se está documentado.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si fue útil, aunque a mi parecer no se cuenta con la infraestructura para aplicar más
niveles en CMMI®.
132
Miembro TWG – DESARROLLADOR 4
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: La forma de trabajar con más control
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Aprender a trabajar como un equipo de verdad
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: La resistencia al cambio
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: A entregar los proyectos que tengo asignados en tiempo y forma.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si pues hubo muchos beneficios sobre todo económicos
133
Miembro TWG – DESARROLLADOR 5
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: En que antes podría no cumplirse lo requerido por MAAGTICSI, sin embargo, con
CMMI® si no se cumple el proceso no es posible avanzar
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Brinda la oportunidad de sentirse valiosos como recurso humano, pues se asignan
actividades conforme a la capacidad de cada uno, eso permite que los equipos de trabajo
que se formen sean eficientes y juntos logren los resultados esperados.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: Muchos compañeros no saben trabajar en equipo, quieren hacer todas las actividades
por ellos mismos y no permiten que los demás miembros aporten.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: A aprender cada día más conforme a los lenguajes de programación, a seguir aportando
en los equipos de trabajo tanto mis ideas como mis conocimientos.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Fue útil, aunque siento que muchos compañeros no aportan lo que deberían aportar
para que se siga creciendo en CMMI®.
134
Miembro TWG – DESARROLLADOR 6
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: La manera en que la metodología va guiando, es más entendible CMMI® que
MAAGTICSI.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: La comunicación entre las áreas.
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: La resistencia al cambio de muchos de los compañeros de equipo, incluso las relaciones
de los compañeros entre sí.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: En que el desarrollo de los proyectos es más optimizado y la entrega más eficiente.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Si fue útil y si creo que sea viable y necesario seguir creciendo en niveles de madurez en
CMMI®.
135
Miembro EPG- AUDITOR
1. ¿Qué diferencias encuentra en el desarrollo de proyectos informáticos con la implementación
del MAAGTICSI y CMMI® nivel 2?
R: Aunque los procesos se auditaban desde antes con MAAGTICSI, el hecho de estar
controlando el cumplimiento de metas y objetivos era algo que no se veía dentro de la
GDSI.
2. Mencione los beneficios que a su parecer brinda la implementación de CMMI® nivel 2
R: Muchos, entre ellos la parte de mejorar todos los procesos para lograr el cumplimiento
de las metas y objetivos
3. Mencione los inconvenientes que se presentaron al implementar CMMI® nivel 2
R: La oposición de los compañeros de no querer que se les revise su trabajo, que se les
corrija la manera en la que están llevando a cabo las actividades.
4. ¿Cómo le ha ayudado la implementación del programa de mejora con CMMI® nivel 2 al
desempeño de sus actividades laborales diarias?
R: El tratar de que el trabajo de hoy sea mejor que el de ayer.
5. ¿Considera que fue útil la implementación de CMMI® nivel 2 y cree que es viable la
implementación de los siguientes niveles de madurez en la GDSI?
R: Sí, sería maravilloso que se implementaran los demás niveles de madurez, aunque veo
difícil que la gente pueda adaptarse a una manera diferente de trabajar.
136
Las encuestas fueron realizadas a dos miembros del equipo MSG, que corresponden al
Subdirector de Desarrollos Informáticos y al Gerente de la GDSI, un analista miembro del EPG,
seis desarrolladores y un auditor.
Conforme a las preguntas realizadas a los 10 entrevistados se destaca lo siguiente en la tabla:
Tabla 21. Resumen de respuestas a las entrevistas
Pregunta Respuestas
Diferencias entre CMMI® y
MAAGTICSI
Cambia la costumbre de “Formatitis”
implementando CMMI®
Trabajo en equipo
Manejo de errores
Manejo de proceso
Mayor control en CMMI®
Cumplimiento mayor de los procesos con CMMI®
Beneficios de Implementar CMMI Mayor comunicación
Mejor trabajo en equipo
Mejora en la entrega de los aplicativos
Mejora en los procesos
Inconvenientes al implementar CMMI Resistencia al cambio
Miedo al fracaso
Aporte de CMMI en las actividades
diarias
Mejor orden en las actividades a desempeñar
Mejor eficiencia
Mejor control
Mejora continua
Fue útil implementar CMMI SI
Es viable implementar los siguientes
niveles SI
137
Los resultados de las entrevistas muestran que hubo mejora en la ejecución de los procesos,
observadas en el desarrollo de los aplicativos, y en las actividades diarias de administración,
desarrollo y evaluación. Se puede observar que el nivel de aceptación fue alto, lo cual fue visto,
en que los involucrados mostraron un índice de aceptación y satisfacción en sus respuestas, en los
tiempos de desarrollo y en la entrega de aplicativos.
El punto de inflexión como en muchas acciones de transformación, se presentó en la renuencia al
cambio, lo cual puede ser atajado mediante la sensibilización con talleres y cursos sobre los
beneficios del modelo.
138
CONCLUSIONES
Para la fase de aprendizaje del modelo ideal, se puede concluir que, con la implementación de
CMMI®, se vio el avance e incremento en la calidad, efectividad y productividad en los sistemas
desarrollados. Se consiguió madurar varios procesos del MAAGTICSI, lo cual ayuda a que en las
auditorias se encuentren menos NO CONFORMIDADES.
En cuando a las auditorías, el Órgano Interno del Control de Xcom, observó el cambio trimestral
que tuvo para efectos de la implementación del programa de mejora y exhorto a seguir aplicando
el modelo CMMI® en sus siguientes niveles. La importancia de usar un modelo radicó en la
comprensión de los elementos específicos de una organización, a la vez que ayudó a identificar y
trabajar en lo que se debe mejorar dentro de la misma y de cómo se pueden lograr dichas mejoras.
Este caso de estudio ha permitido ver las diversas ventajas que tiene el implementar CMMI®
nivel 2 dentro de un área de TI, al evaluar los beneficios que se obtuvieron en el proceso de
desarrollo de software de Xcom. La implementación del modelo CMMI® permitió crear hábitos
dentro del equipo de trabajo para que, de esta manera se logre que los procesos sean mejores cada
día.
No fue fácil implementar el programa de mejora en Xcom dentro de la GDSI, pues al principio
existió resistencia al cambio de varios miembros de un equipo, es por ello que el líder del
programa de mejora requirió ser de carácter fuerte, decisivo, asertivo y dispuesto a lidiar con ello
así como tener la capacidad de resolver conflictos dentro del área de trabajo y persuadir el ganar-
ganar dentro de un equipo, pues como pudimos observar, las ventajas son muchas y aunque el
esfuerzo es más, bien vale la pena.
Se debe convencer al equipo de que el doble trabajo no volverá a repetirse, la definición de un
plan de trabajo bien estructurado, una definición correcta de errores y una buena administración
de recursos son los ingredientes clave para el éxito del programa de mejora para así cumplir con
los objetivos propuestos.
139
La implementación del modelo CMMI® nivel 2, permitió desarrollar aplicativos con mayor
calidad y menos fallas incluso estando en ambiente productivo. Permite llevar un mejor control
en la asignación de recursos humanos dentro de un proyecto, permitiendo así que la
responsabilidad de liberación de un aplicativo no recaiga en una sola persona, lo cual permite que
se consiga una mayor eficiencia en el desarrollo de sistemas.
También se logró el control en la validación y verificación de los aplicativos mediante la
definición de los defectos, técnica que antes no se llevaba a cabo y que, por tanto, el encontrar
defectos era difícil, lo cual no permitía que se liberara un producto de calidad. Con la
implementación del modelo CMMI® nivel 2 se logra conseguir una calidad de 100% para liberar
aplicativos a producción y se asegura que cumpla con todos los requerimientos planteados desde
un inicio por el cliente, de ésta manera se asegura que los aplicativos se corrijan una vez que se
encuentren en ambiente productivo.
La puesta en marcha de tres aplicativos en paralelo sirvió para poder realizar la evaluación de la
ganancia que se obtiene cuando los aplicativos brindan servicio dentro de las sucursales de
Xcom. Se observó la importancia de contar con desarrollos de calidad que presenten menos
errores en ejecución, pues entre mayor sea el número de operaciones, mayor es el ingreso
percibido y por lo tanto, mayor es la ganancia de Xcom y de sus clientes.
Como siguientes pasos se recomendaría la aplicación de ISO 27001, para llevar a cabo un mayor
control del Sistema de Gestión de Seguridad Informática SGSI, que requiere el proceso de
administración de la seguridad de la información.
Teniendo los procesos maduros:
Administración de Proyectos
Administración de la Configuración
140
Se puede ir escalando al nivel 3, donde las áreas de proceso se empiezan a perfeccionar para así
mantener la implementación de CMMI® de una manera más estructurada pero con el añadido de
migrarlo a las demás funciones inherentes de las áreas de informática, como son la
administración y mantenimiento de mobiliario informático, administración de servidores y redes,
pero sobre todo y lo que significa el objetivo de esta tesis, el llevarlo a todas la dependencias del
GF, como una alternativa para la homologación de procesos entre las dependencias ubicando sus
puntos débiles y fuertes dentro del MAAGTICSI.
141
ANEXOS
REQM - Administración de Requerimientos
1. Formato para la especificación y entendimiento de requerimientos funcionales y no
funcionales (Figura 26).
2. Formato de acta de reunión (Figura 27)
PP – Planeación de Proyectos
1. Formato matriz de formulación de proyectos (Figura 28)
2. Matriz de planificación de proyectos (Figura 30)
3. Planificación de Proyectos (Administración de Riesgos) (Figura 31)
4. Política Organizacional:
“Los coordinadores de los proyectos con su grupo de trabajo deben evaluar los planes y riesgos
que afecten la ejecución y el plan del proyecto”
PMC – Monitorización y Control de Proyectos
1. Política organizacional:
“Monitorear los riesgos del proyecto en las reuniones de seguimiento al plan, basándose en los
riesgos documentados en la matriz de planificación de proyectos”
AP – Administración de Proveedores
1. Política
“La aceptación de los productos depende de los resultados de los procesos de verificación y
validación”
142
MA – Medición y Análisis
1. Políticas Organizacionales:
“Realizar reuniones mensuales del comité de calidad para analizar los datos de medición”
“Los datos de medición y los resultados de análisis deben ser administrados y almacenados en
las herramientas de apoyo”
2. Formato de descripción de defectos (Figura 33)
PPQA – Aseguramiento de Calidad de Procesos y Productos
1. Política organizacional:
“Comunicar las no conformidades y su gestión en los comités de calidad a la alta dirección”
CM – Administración de la Configuración
1. Políticas organizacionales:
“Controlar el código fuente en un servidor central para almacenar la información general de los
proyectos”
“Realizar auditorías de integridad de las líneas base por parte del área de Auditoría Interna”
143
BIBLIOGRAFÍA
Caballero, E., Calvo-Manzano Villalón, J. A., Cuevas Agustín, G., & San Feliu Gilabert, T.
(2009). Análisis de la calidad y productividad en el desarrollo de un proyecto software en
una microempresa con TSPi. Revista Española de Innovación, Calidad e Ingeniería del
Software (REICIS), 5, 28–37.
CMMI Product Team, C. (2010). CMMI® para Desarrollo, Versión 1.3. Software Engineering
Institute.
De la Villa, M.,Ruiz, M., R. I. (2004). Modelos de evaluación y mejora de procesos: Análisis
comparativo. Presentado en In 5th ADIS Workshop (Apoyo a la Decisión en Ingeniería
del Software), Málaga, España.
Diario Oficial de la Federación. (2016). MAAGTICSI_2016_ACUERDO. Última reforma
publicada DOF 04-02-2016. Recuperado de
http://www.ran.gob.mx/ran/images/remos_downloads/MAAGTIC%20-
SI/manuales/MAAGTICSI_2016_ACUERDO.pdf
Estrada, A. C. (2014). Modelo de calidad de software. Innovación, Ingeniería y Desarrollo, 1(1).
Recuperado de
http://www.coruniamericana.edu.co/publicaciones/ojs/index.php/IID/article/view/171
Gasca, E. G. (2018). Implementación de modelos de calidad en la construcción del software en
México. Recuperado el 10 de abril de 2018, de
http://www.revista.unam.mx/vol.9/num9/art73/int73-2.html
Gordillo Mejía, A., Licona Padilla, D., & Acosta Gonzaga, E. (2013). Desarrollo y aprendizaje
organizacional mediante el usi de TIC´s (2da Edición). Trillas.
144
Jiménez Romero, M., & Aparicio Álvarez, D. A. (2009). Reporte MADI (B.S. thesis).
Universidad EAFIT.
Kulpa, M. K., & Johnson, K. A. (2008). Interpreting the CMMI. A process Improvement
Approach. (Second Edition). New York: CRS Press.
McFeeley, B. (1996). IDEAL: A User’s Guide for Software Process Improvement. CARNEGIE-
MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.
Medrano Macías, M. A. (2012). DESARROLLO DE UN MODELO SIMPLIFICADO DE
GESTIÓN DE TIC PARA AGENCIAS GUBERNAMENTALES DE ESTRUCTURAS
REDUCIDAS. The University of Texas at Dallas, Mexico DF. Recuperado de
http://infotec.repositorioinstitucional.mx/jspui/handle/1027/175
Meneses, Y. N. G., Padilla, N. Y. L., Mora, J. J. H., & Barrera, M. G. M. (2014). Análisis del
estado actual de certificaciones CMMI-DEV ver. 1.3 año 2013 y 2014, a nivel mundial y
en México, 14.
Órgano Interno de Control Xcom. (2018, julio). Resultados Preliminares de la Auditoría 2018.
Ortiz Uribe, F. G., & García Nieto, M. del P. (2009). Metodología de la Investigación, el proceso
y sus técnicas (1ra ed.). Mexico DF: Limusa.
Pressman, R. S. (2010). Ingeniería del software: un enfoque práctico.
Ramirez Luján, D., Rodriguez Baryolo, Y., & Molina Villalobos, C. (2010). La utilización de la
gestión del conocimiento y la toma de decisiones en el área de proceso monitoreo y
control de proyecto (PMC) de CMMI. Revista Cubana de Ciencias Informáticas, 4(3–4).
Recuperado de http://www.redalyc.org/resumen.oa?id=378343670004
Ruiz, E. M. M., Granda, W. X. B., & Sarmiento, P. A. Q. (2017). Gobierno de TI: Elección y
Aplicación de Buenas Prácticas en Corporación Nacional de Telecomunicación.
SEI CMMI Production. (2010). CMMI for Development v1. 3. Lulu. com.