148.204.210.201148.204.210.201/tesis/1551292767913tesisimplement.pdfincluso en los peores momentos y...

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.


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.


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


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


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.


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.


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.


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


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.


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.


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


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.


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)


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


Valida y apruebas los nuevos módulos y mantenimientos al SIGS (Sistema


Á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 =


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 =


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



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


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


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


(Días)

Fecha

Inicio

Fecha

Termino

Recepción de

Requerimiento Analista 3 días 02/10/17 04/10/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


Solicitud de Insumos para Analista 5 días 30/03/18 05/04/18

82

pruebas JAIS

Pruebas Analista,



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)


(Días)

Fecha

Inicio

Fecha

Termino

Recepción de






85


Construcción de Modulo

BATCH


Construcción de Módulo

HOST TO HOST


Consumo WebService Desarrollador 22 días 12/10/17 10/11/17

Ambientación Desarrollador 15 días 13/11/17 01/12/17


Solicitud de Insumos para

pruebas Analista 5 días 26/02/18 02/03/18

Pruebas Analista,



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:





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.


89


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.


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


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.


IDEAL.

TWG – Technical

working group


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.


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,


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,


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,


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


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.


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.


Meta Específica 1 – Establecer acuerdos con los proveedores. Para cumplir con esta meta se


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.


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


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


Meta Específica 1 – Establecer línea base. Para cumplir con esta meta se definieron y


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.


“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


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



“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


(Días) Fecha Inicio Fecha Término

Recepción de


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





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


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.




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


(Días) Fecha Inicio Fecha Termino


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




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


pruebas WebService Analista 10 días 17/11/17 30/11/17


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


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





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


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:


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




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)


(Días) Fecha Inicio Fecha Termino


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




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


pruebas Analista 10 días 21/08/17 01/09/17


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


Desarrollador 1

Desarrollador 2

Desarrollador 3

30 días 16/10/17 01/12/17

Construcción de Módulo BATCH


Desarrollador 1

Desarrollador 2

Desarrollador 3

10 días 04/12/17 29/12/17


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




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 𝑥 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:


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



R: A pesar de que ambas son metodologías, tienen diferente forma de guiar a un equipo de

trabajo hacia un objetivo.


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.


R: El inconveniente principalmente fue la resistencia al cambio y a modificar la manera de

trabajar.



128

R: Ayuda a eficientar los requerimientos, así como unificar esos requerimientos con el

desarrollo de software.



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



R: El significado de equipo de trabajo no es el mismo en ambas metodologías.


R: Mayor control en los procesos, mayor comunicación entre áreas


R: La incertidumbre de no saber si el esfuerzo valdrá la pena o se fracasará.



R: Llevar un mejor control en todo



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



R: Los procesos que ambos tienen, son muy diferentes.


R: Mayor estructura en el desarrollo de proyectos


R: Miedo al cambio



R: Tener un mayor estándar hasta dentro el código de las aplicaciones



R: Si, y si creo que sea viable

130




R: El manejo de errores y el desarrollo intuitivo de las aplicaciones


R: Mejora continua, mayor cumplimiento en las entregas de los proyectos.


R: Miedo al fracaso, a que se invierta un tiempo que no valdrá la pena en un proyecto



R: Controlar mayormente la parte de codificación al documentar las líneas de código



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




R: Que no se tenía un control tan estructurado como con CMMI® nivel 2


R: Mayor comunicación entre las áreas y el equipo de trabajo de la GDSI.


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.



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.



R: Si fue útil, aunque a mi parecer no se cuenta con la infraestructura para aplicar más

niveles en CMMI®.

132




R: La forma de trabajar con más control


R: Aprender a trabajar como un equipo de verdad


R: La resistencia al cambio



R: A entregar los proyectos que tengo asignados en tiempo y forma.



R: Si pues hubo muchos beneficios sobre todo económicos

133




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


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.


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.



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.



R: Fue útil, aunque siento que muchos compañeros no aportan lo que deberían aportar

para que se siga creciendo en CMMI®.

134




R: La manera en que la metodología va guiando, es más entendible CMMI® que

MAAGTICSI.


R: La comunicación entre las áreas.


R: La resistencia al cambio de muchos de los compañeros de equipo, incluso las relaciones

de los compañeros entre sí.



R: En que el desarrollo de los proyectos es más optimizado y la entrega más eficiente.



R: Si fue útil y si creo que sea viable y necesario seguir creciendo en niveles de madurez en

CMMI®.

135

Miembro EPG- AUDITOR



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.


R: Muchos, entre ellos la parte de mejorar todos los procesos para lograr el cumplimiento

de las metas y objetivos


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.



R: El tratar de que el trabajo de hoy sea mejor que el de ayer.



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:



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.

148.204.210.201148.204.210.201/tesis/1551292767913tesisimplement.pdfincluso en los peores momentos y...

Documents