Implementación CMMI para El Desarrollo de Software

UNIVERSIDAD NACIONAL AUTÓNOMA DE MEXICO
FACULTAD DE INGENIERÍA
“IMPLEMENTACIÓN Y ADAPTACIÓN DEL MODELO DE

CALIDAD CMMI PARA EL DESARROLLO DE
SOFTWARE”
INFORME DE TRABAJO PROFESIONAL
QUE PARA OBTENER EL TÍTULO DE:
INGENIERO EN COMPUTACIÓN
P R E S E N T A:
MARCO ANTONIO REYES NAVA
ASESOR: M.C. ALEJANDRO VELÁZQUEZ MENA
CIUDAD UNIVERSITARIA 20/AGOSTO/2015

AGRADECIMIENTOS
Lo que soy como persona, esposo y profesional se lo debo invaluablemente a mis padres
(Bernardo Agustín Reyes Guzmán y Carolina Nava León) y hermanos (Bernardo Reyes
Nava y Daniel Reyes Nava), quienes me enseñaron que el buen camino y el triunfo se
encuentran con: rectitud, lealtad, honestidad, humildad y ética.
La mejor herencia que me pudieron dejar mis padres es mi carrera profesional que me ha
permitido obtener cada logro de mi vida.
A mi esposa (Martha Elena Martínez Irigoyen) e hijos como motor de todos los días; que
cada paso es por y para ellos; y que nunca me permiten flaquear en los tiempos difíciles y
ser soberbio en los tiempos de abundancia.
Mis suegros (Mario de Jesús Martínez Coria y Guadalupe Martha Irigoyen Rivera) que
empujaron para que tomara la decisión de titularme, además de inculcarme que la
paciencia era una virtud que tenía que desarrollar en mi vida.
A mis amigos, que aún se cuentan con los dedos de la mano y ¡saben quiénes son!, me
enseñaron el significado de la palabra lealtad y cuando los necesito están ahí siempre.
FACULTAD DE INGENIERÍA – UNAM
MÉXICO 2015
ÍNDICE
INTRODUCCIÓN ....................................................................................................................................... 1
CAPÍTULO 1. ORGANIGRAMA ............................................................................................................ 16

CAPÍTULO 2. ANTECEDENTES PARA IMPLEMENTAR UN MODELO DE CALIDAD PARA
DESARROLLO DE SOFTWARE ........................................................................................................... 18
2.1 IMPLEMENTACIÓN DEL MODELO DE CALIDAD CMMI EN LAS EMPRESAS DE SOFTWARE ...................... 18
A. ANTECEDENTE .................................................................................................................................... 18
B. OBJETIVOS .......................................................................................................................................... 18
2.2 ADAPTACIÓN DEL MODELO DE CALIDAD CMMI EN EL PROYECTO DE “MODERNIZACIÓN INTEGRAL”
PARA UNA INSTITUCIÓN GUBERNAMENTAL................................................................................................... 19
A. ANTECEDENTE .................................................................................................................................... 19
B. OBJETIVOS .......................................................................................................................................... 20
2.3 ADAPTACIÓN DEL MODELO DE CALIDAD CMMI EN EL ÁREA DE SISTEMAS DE UNA INSTITUCIÓN
BANCARIA Y DE VALORES Y SU CONVIVENCIA CON LA METODOLOGÍA DEL PMI (PROJECT MANAGEMENT
INSTITUTE) ................................................................................................................................................... 21
A. ANTECEDENTE .................................................................................................................................... 21
B. OBJETIVOS .......................................................................................................................................... 21
CAPÍTULO 3. IMPLEMENTACIÓN Y ADAPTACIÓN DEL MODELO DE CALIDAD CMMI PARA
EL DESARROLLO DE SOFTWARE ..................................................................................................... 23
3.1 CONSTELACIONES DE CMMI ................................................................................................................ 23

3.2.1 REPRESENTACIÓN CONTINUA: ........................................................................................................... 27
3.2.2 REPRESENTACIÓN ESCALONADA ....................................................................................................... 31
3.3 ÁREAS DE PROCESO.............................................................................................................................. 35
3.3.1 DISCIPLINAS ....................................................................................................................................... 35
3.3.2 ELEMENTOS DE LAS ÁREAS DE PROCESOS. ...................................................................................... 37
3.3.3 EL MODELO DE IMPLEMENTACIÓN IDEAL ........................................................................................ 38
3.3.3.1 FASES DEL MODELO IDEAL ........................................................................................................... 40
3.4 MÉTODO DE EVALUACIÓN FORMAL DE CMMI SCAMPI ....................................................................... 42
3.4.1 CLASES DE SCAMPI ......................................................................................................................... 42
3.4.2 HERRAMIENTAS DE EVALUACIÓN ....................................................................................................... 45
3.5 CASOS DE ÉXITO.................................................................................................................................... 46
3.5.1 IMPLEMENTACIÓN DEL MODELO DE CALIDAD CMMI EN LAS EMPRESAS DE DESARROLLO DE
SOFTWARE ................................................................................................................................................... 47
3.5.2 CONTROL DE INVENTARIO Y CÉDULAS (EMPRESA MANUFACTURERA DE MALTA).............................. 66
3.5.3 SISTEMA DE AUTOMATIZACIÓN DE FORMAS DE PAGO POR CHEQUES (EMPRESA DE RETAIL DE
DISTRIBUCIÓN DE ARTÍCULOS PARA OFICINA) .............................................................................................. 74
FIGURA 1 – 22 GUÍA DE ADAPTACIÓN SISTEMA DE AUTOMATIZACIÓN DE FORMAS DE PAGO POR CHEQUES
(EMPRESA DE RETAIL DE DISTRIBUCIÓN DE ARTÍCULOS PARA OFICINA) ..................................................... 80
3.5.4 CONTROL DE VENTAS (EMPRESA DE RETAIL DE DISTRIBUCIÓN DE ARTÍCULOS PARA OFICINA) ........ 80
FIGURA 1 – 23 REPORTE SUMARIO POR TIENDA......................................................................................... 82
i
MÉXICO 2015
FIGURA 1 – 24 REPORTE DETALLADO POR TIENDA-EMPLEADO.................................................................. 82

FIGURA 1 – 25 REPORTE DE VENTAS 5 NIVELES ........................................................................................ 83
FIGURA 1 – 26 REPORTE DE VENTAS 4 NIVELES ........................................................................................ 83
FIGURA 1 – 27 REPORTE DE VENTAS POR CLIENTE.................................................................................... 83
FIGURA 1 – 28 REPORTE DE VENTAS VENDEDOR-CLIENTE ........................................................................ 84
FIGURA 1 – 29 REPORTE DE VENTAS VENDEDOR-CLIENTE ........................................................................ 89
3.5.5 ADAPTACIÓN DEL MODELO DE CALIDAD CMMI EN EL PROYECTO DE “MODERNIZACIÓN INTEGRAL”
PARA UNA INSTITUCIÓN GUBERNAMENTAL................................................................................................... 89
3.5.6 ADAPTACIÓN DEL MODELO DE CALIDAD CMMI EN EL ÁREA DE SISTEMAS DE UNA INSTITUCIÓN
BANCARIA Y DE VALORES Y SU CONVIVENCIA CON LA METODOLOGÍA DEL PMI .......................................... 93
CONCLUSIONES .................................................................................................................................... 98
GLOSARIO ............................................................................................................................................ 102
REFERENCIA........................................................................................................................................ 110
ANEXOS ................................................................................................................................................ 111
ANEXO A. POLÍTICA PARA DESARROLLO DE PROYECTOS ..................................................... 112
ANEXO B. ERS – ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE .......................... 119
ANEXO C. PDP – PLAN DE DESARROLLO DEL PROYECTO ...................................................... 126
ANEXO D. GUÍA DE ADAPTACIÓN ................................................................................................... 145
ANEXO E. LÍNEA BASE ...................................................................................................................... 151
ANEXO F. REPORTE DE AVANCE SEMANAL CON EL CLIENTE ............................................... 154
ANEXO G. EJEMPLO DE MÉTRICAS ORGANIZACIONALES ....................................................... 155
ANEXO H. LISTA DE VERIFICACIÓN DE AUDITORÍA AL PROYECTO ....................................... 157
ii
MÉXICO 2015
INTRODUCCIÓN
Hoy en día la tecnología va creciendo con una rapidez impresionante y con
ello la necesidad de desarrollar sistemas cumpliendo el tiempo establecido, con
calidad, rentable para el proveedor y satisfacción total del cliente. Para ello las
empresas dedicadas al desarrollo de software se enfrentan a una gran
problemática, la cual es que los proyectos se alarguen en tiempos, se eleven los
costos y disminuya su rentabilidad; por eso la necesidad de adoptar un modelo, el
cual les ayude a planificar estos proyectos y así cumplir en tiempo, con el
presupuesto asignado y con la calidad y satisfacción que el cliente requiere.
Uno de los Modelos más utilizados es CMMI (Capability Maturity Model
Integration) -Modelo de Madurez de Capacidades Integradas- el cual fue
desarrollado por el SEI (Software Engineering Institute) – Instituto de Ingeniería de
Software- de la Universidad de Carnegie Mellon, Pittsburgh U.S.A., a partir de
experiencias en proyectos y a petición del departamento de defensa. Es una
herramienta que permite a las organizaciones, especialmente a las empresas
desarrolladoras de software a definir y mejorar sus procesos y con ello planificar,
controlar y monitorear los proyectos.
Ahora más que nunca como consecuencia del avance tecnológico las
empresas deben entregar mejores productos y servicios en mucho menos tiempo
y costo, esto obliga a las empresas a construir sistemas cada vez más complejos,
pero es raro encontrar a una institución que se dedica 100% al desarrollo e
1
MÉXICO 2015
implantación del mismo; en ocasiones algunas partes se adquieren y son
agregadas al servicio o producto final. Por tal motivo, es necesario que las
empresas sean capaces de completar el proceso de desarrollo, mantenimiento e
implantación de los productos. Por ello los procesos y procedimientos ayudan a
que las empresas tengan guías que permitan administrar sus proyectos y
controlarlos para alcanzar los objetivos establecidos.
Acerca de los modelos de calidad para desarrollo de software
Con el avance tecnológico es importante conocer la importancia de los
modelos de calidad para desarrollo de software a las organizaciones, instituciones
y, principalmente a los futuros profesionistas, la importancia de utilizar procesos y
los beneficios que ofrece, ya que estos son parte vital para el éxito de una
organización y del crecimiento profesional de los individuos.
Un modelo de calidad para desarrollo de software es el conjunto de
procesos organizados que puede adoptar una organización de acuerdo a su forma
de operación, la cual le permite contar con información que puede ser utilizada
para desarrollar planes de trabajo, proyecciones, establecer indicadores y mejorar
su operación, además de identifica las fortalezas y debilidades de la organización.
El modelo de calidad para desarrollo de software consiste en un proceso
que muestra y explica el camino de una organización para alcanzar la excelencia.
Dentro de su investigación el SEI define varias dimensiones con las que operan
las organizaciones, pero 3 críticas que son esenciales para el funcionamiento de la
2
MÉXICO 2015
misma, las cuales son los procedimientos, las personas y las herramientas. Estas
en conjunto sustentan su buen funcionamiento, pero también dependen de los
procesos que se utilizan en la organización para alinear el modo de operar y para
explotar adecuadamente los recursos (Ver figura 1-1).
Figura 1 – 1 El modelo de calidad es un proceso para alcanzar la excelencia
El modelo CMMI
Antecedentes
En la década de los 30’s Walter Shewhart comenzó a trabajar en la mejora
de procesos introduciendo los principios del control estadístico de la calidad.
Estos principios fueron refinados por Phillip Crosby y Josep Juran. Watts
Humphrey y Ron Radice los ampliaron y comenzaron a aplicarlos en su trabajo en
IBM y en el SEI. Watts Humphrey en su libro, Maneging The Software Process,
3
MÉXICO 2015
describe los principios y conceptos básicos los cuales se basan muchos de los
modelos de madurez y de capacidad.
La definición de un modelos de madurez y de capacidad permite desarrollar
modelos que soporten diversas aproximaciones a la mejora de procesos, con tal
de que un modelo contenga los elementos esenciales de los procesos eficaces
para una o más disciplinas y que describa una trayectoria evolutiva de mejora,
permitiendo transformar desde procesos Ad hoc y no maduros a procesos
disciplinados.
En 1991 el SEI publico el CMM (Capability Maturity Model), este modelo
está dirigido al desarrollo de software, para lo cual contempla las consideradas
mejores prácticas de ingeniería de software.
A mediados de la década de los 90’s en SEI decidió unificar los modelos de
Ingeniería de software (SW-CMMI), de Ingeniería de Sistemas (SE-CMM) y de
desarrollo integrado de productos (IPD-CMM), embarcándose en una tarea que
termino en el 2002 dando origen a la nueva generación llamada CMMI. El CMMI
brinda un marco con una estructura común para todas las disciplinas y ramas de
las ingenierías de sistemas e incorpora una forma de representación llamada
continua, orientada a medir la mejora de procesos de manera individual en vez de
hacerlo de manera conjunta como la representación por niveles del modelo
original (véase figura 1-2).
4
MÉXICO 2015
Figura 1 – 2 Historia de los CMM´s
Dentro de esta nueva generación de modelos, el sucesor directo del CMM
original es denominado CMMI-SW. Este modelo presenta una mayor cobertura
con respecto a las prácticas y objetivos de cada área de proceso para el
Desarrollo de Software.
En paralelo con la creación de CMMI el SEI elaboró un método para la
evaluación formal del modelo denominado SCAMPI (Método de Evaluación para la
Mejora de Procesos).
5
MÉXICO 2015
El SCAMPI es el método de evaluación que utiliza el SEI para certificar a
las empresas sobre el uso adecuado de los Procesos, siempre respetando la
forma de operación de cada empresa u organización.
Modelos previos.
En 1986 a petición del gobierno federal de los Estados Unidos el SEI
desarrollo la primera definición del modelo de madurez de procesos para el
desarrollo de software que se publicó en septiembre de 1987. Este trabajo
desplego al Modelo CMM o SW-CMM.
CMM establece un conjunto de prácticas claves agrupadas en áreas claves
de procesos. El modelo CMM ha servido como marco de referencia para la
implementación de mejora de procesos en instituciones en varias partes del
mundo. CMM tiene como objetivo lograr que los procesos sean óptimos y
repetibles en el desarrollo de software.
Durante los años 90, el SEI desarrollo modelos de específicos para la mejora y
medición de la madurez en varias áreas:
 CMM-SW: CMM for software
 P-CMM: People CMM.
 SA-CMM: Software Acquisition CMM.
 SSE-CMM: Security Systems Engineering CMM.
 T-CMM: Trusted CMM
6
MÉXICO 2015
 SE-CMM: Systems Engineering CMM.
 IPD-CMM: Integrated Product Development CMM.
Durante esta década era habitual que las organizaciones implantaran de
manera simultánea el modelo SW-CMM y SE-CMM, de aquí la necesidad de
desarrollar un modelo que evitara la implantación de varios modelos al mismo
tiempo. CMMI fue desarrollado para facilitar y evitar la implantación de varios
modelos e integra y releva a sus predecesores.
 CMM-SW (CMM for Software).
 SE-CMM (Systems Engineering Capability Maturity Model).
 IPD-CMM (Integrated Product Development).
La representación de CMMI es un concepto que se relaciona con la estructura
del mismo:
SW-CMM
Contiene el modelo escalonado o de niveles, que utiliza el concepto de
madurez, y que define 5 niveles en los en los cuales se mide la madurez de los
procesos de una organización.
SE-CMM
Es el Modelo de capacidad y Madures en la Ingeniería de sistemas. Está
dirigido a las actividades de ingeniería de sistemas. A diferencia de SW- CMM,
7
MÉXICO 2015
este modelo utiliza la representación continua, la cual se enfoca en las áreas de
proceso.
IPPD-CMM
Es el Modelo que usa un método ordenado que usa la colaboración de
varios grupos de interés durante el ciclo de vida de un sistema para satisfacer la
necesidad, la calidad y los requisitos del cliente.
Otros modelos de calidad
Existen otros modelos y estándares de calidad de software los cuales son
empleados por distintas organizaciones alrededor del mundo para la mejora de
procesos, como se ha indicado las organizaciones eligen de acuerdo a su
operación, tamaño de empresa y recursos financieros el modelo que se ajusta a
sus necesidades.
Mencionamos otros modelos para evidencias que las alternativas en el
mercado de los procesos de calidad para software existen, pero bajo la
experiencia personal, CMMI es un modelo que cubre todas las aristas de la
industria de ingeniera de software y su adaptabilidad a diversas líneas de negocios
relacionados como: soporte técnico, consultoría de aplicaciones, proyectos para
optimizar procesos de negocio entre otras variantes de la industria.
8
MÉXICO 2015
ISO
Es el Organismo Internacional para la Estandarización de Procesos
(International Estandar Organization), éste es el más conocido, es un estándar
internacional que puede ser aplicado a cualquier tipo de organización sin importar
cuál sea su giro en gestión de la calidad.
Calidad: Según ISO son aquellas características que hacen que un
producto satisfaga necesidades evidentes de los clientes.
Existe un grupo de estándares dentro de ISO para la industria de software:
ISO 9000:
Son estándares de sistemas de calidad utilizados para el desarrollo,
suministro y mantenimiento de software los cuales son 3 modelos de acuerdo al
giro de la empresa de software:
9001: Diseña su propio producto o servicio (desarrollo de software)
9002: Manufactura su producto y/o servicio (fábrica de software)
9003: Cubre inspección y examen de productos finales (consultoría de sistemas)
ISO 9000–3
Está basada en el control de calidad debe ser aplicado a todas las fases de
la producción de software, incluido el mantenimiento y tareas posteriores a su
implantación.
9
MÉXICO 2015
Tres premisas importantes que maneja este modelo son:
 Auditorías Internas del sistema de calidad
 Especificación de los requerimientos de la organización
 Administración de la configuración
Se relaciona con los siguientes estándares ISO 9001 e IEEE 730.
La ISO 9000-3 nos proporciona una guía útil que nos sirve para detectar y
corregir una serie de problemas de los productos software, consiguiendo tras su
aplicación una mejora en la calidad de los mismos.
El control de calidad debe ser aplicado a todas las fases de la producción
de software, incluido el mantenimiento y tareas posteriores a su implantación.
Debe existir una estricta colaboración entre la organización que adquiere el
software y el proveedor del mismo.
El proveedor del software debe definir su sistema de calidad y asegurarse
que toda la organización ponga en práctica este sistema.
ITIL
Es el acrónimo ITIL (Information Technology Infraestructure Library) fue
creado en la década de los 80´s por la CCTA (Central Computer &
Telecomunication Agency) del Reino Unido y administrado por la OGC (Office of
Government Commerce).
10
MÉXICO 2015
Es denominado como un conjunto de mejores prácticas en servicios de
tecnología de la información en lo relacionado a procesos, personas y tecnología,
por lo que hace posible que las organizaciones reduzcan costos, mejoren la
calidad de sus servicios y principalmente aprovechan las habilidades de su
personal y de sus herramientas de trabajo.
Así como CMMI tiene 5 niveles de Madurez en los cuales se puede ubicar
una organización, ITIL cuenta con 3 niveles de certificación en los se puede
certificar una sola persona y no la organización completa.
1.- Certificado Básico:
Este sólo certifica que la persona tiene el conocimiento básico de ITIL en la
gestión de servicios de TI y que comprende la terminología que comprende ITIL.
2.- Certificado Responsable:
Es dirigida a personas con administración de departamentos de sistemas,
responsabilidad en el diseño de procesos de mejora y planificación de actividades
relacionadas con mejores prácticas.
3.- Certificado de Director:
Este certifica que la persona es apta y dispone de conocimientos
avanzados para la administración de departamentos de sistemas y está habilitada
para la implantación de soluciones basadas en ITIL.
11
MÉXICO 2015
SIX SIGMA
Σ = Sigma
σ = Desviación estándar, mide cuánto se separan los datos.
6 σ = Es equivalente a 0 defectos por que mide el nivel funcionamiento correcto
del 99.9997 por 100 donde los defectos en los procesos y productos
prácticamente no existen.
Este modelo busca la perfección absoluta, Permite hacer comparaciones
entre negocios, productos, servicios, hace una medición por medio de
herramientas para conocer el nivel de calidad de la empresa
Six sigma también es conocido como DMAMC y consiste en la aplicación
proyecto a proyecto de un proceso estructurado que consta de 5 fases den de
cada fase se encadena lógicamente a la fase previa, derivadas del nombre
DMAMC,
 Definir
 Medir
 Analizar
 Mejorar
 Controlar
12
MÉXICO 2015
La razón de six sigma es alcanzar 6 defectos por millón de oportunidades.
Se basa en la curva de distribución normal (para conocer el nivel de
variación de cualquier actividad)
¿Cuál es el modelo de calidad apropiado a utilizar?
La manera de incrementar la calidad del desarrollo de software es aumentar
el control del ciclo de vida del mismo. Cuanto más estructurado sea el proceso de
desarrollo, más sencillo será controlar sus diferentes etapas y saber qué
posibilidades reales tiene una organización para llevar a cabo un proyecto. A
través de la implantación de procesos de desarrollo probados, bien documentados
e institucionalizados, una compañía es capaz de incrementar la precisión de sus
planificaciones, dando la posibilidad de establecer compromisos con sus clientes
que antes no podía o no era capaz de asumir. Por otro lado, implantando nuevos
procesos de desarrollo, también se aumenta la competitividad de la compañía al
poder ofrecer una calidad de software superior.
Pero ¿cómo se puede conseguir aumentar el control del desarrollo
implantando nuevos procesos? A lo largo de los años se ha investigado y
recopilado procesos y buenas prácticas probadas para el desarrollo de software.
Toda esta información ha generado modelos de procesos como CMMI-DEV, ISO
9000, ISO 9000-3, ITIL, etc. Estos modelos de procesos determinan cuáles deben
existir en una organización que desarrolle software.
13
MÉXICO 2015
La existencia de estos procesos en una organización no garantiza por sí
sola la calidad del software desarrollado, ya que estos procesos no sólo debe
existir, sino estar institucionalizados en la organización, es decir, la implantación
debe suponer un cambio en la manera de trabajar. De nada sirve tener los
procesos determinados por uno de estos modelos y seguir trabajando de la misma
manera que se hacía antes de implantarlos. Una crítica común a los modelos de
procesos es que responden a la pregunta ¿Qué hay que hacer? Pero no a
¿Cómo hay que hacerlo? Ésta es una crítica discutible, pues no existe una
respuesta general a la pregunta. Ya que la respuesta está totalmente ligada a la
naturaleza de la organización donde se implantan los procesos, debe ser esta
misma organización, con o sin ayuda externa, la que trate de responderla.
En cualquier caso, no es objetivo de este reporte discutir sobre los modelos
de procesos. Aunque sí es pertinente entender qué son y para qué sirven, pues
pretendemos presentar una propuesta de cómo administrar proyectos e inculcar
desde nuestra formación la utilización de procesos formales que garanticen
resultados satisfactorios en nuestros proyectos. Y para ello tomemos como base
una organización donde se ha implantado un modelo de procesos como CMMI-
DEV y que se encuentra en un nivel de madurez 3. Esto significa que se han
implantado los procesos de gestión de requisitos, planificación, desarrollo de
requisitos y medición y análisis. Los procesos determinan la manera de trabajar de
la organización en el campo de la ingeniería de requisitos y se establece cómo
14
MÉXICO 2015
medir y analizar otros procesos de la organización, entre ellos, con el propósito de
conocer su rendimiento y poder conocer puntos débiles y proponer mejoras.
En resumen, el mejor modelo de calidad es aquel que se adapta a las
necesidades de la organización, está documentado y se institucionaliza para ser
ejecutado por todos los miembros de la empresa como una forma vida. Además
que cualquier modelo siempre es un marco de referencia con mejores prácticas,
pero no es una “varita mágica” para por sí mismo cambiar la cultura laboral de una
empresa.
15
MÉXICO 2015
CAPÍTULO 1. ORGANIGRAMA
Se presenta el ejemplo de un organigrama del área de sistemas, donde la
oficina de proyectos funge como la responsable de gestionar, controlar y
monitorear que los proyectos y requerimientos se cumplan de acuerdo a los
tiempos estimados por las áreas de Desarrollo e Infraestructura correspondiente
(Véase de la figura 1 – 3 a la 1- 6).
DIRECCIÓN TI
SEGURIDAD TI
OFICINA DE PROYECTOS
SUBDIRECCIÓN SUBDIRECCIÓN
INFRAESTRUCTURA DESARROLLO
Figura 1 - 3 Nivel Directivo
SUBDIRECCIÓN
INFRAESTRUCTURA
ASESOR
INFRAESTRUCTURA
OPERACIÓN /
SOPORTE TÉCNICO COMUNICACIONES
PRODUCCIÓN
OPERACIÓN CC Y
BASES DE DATOS
FACILITIES
SISTEMAS MESA DE AYUDA Y

OPERATIVOS SOPORTE TÉCNICO
PC s
WAS / MQ / TIBCO SOPORTE A LA

PRODUCCIÓN /
STORAGE /
RESPALDOS
BCP / DRP
CONTROL DE
NETWORKERS CAMBIOS
INCIDENT MANAGER
Figura 1 - 4 Nivel Gerencial Respecto a la Subdirección de Infraestructura
16
MÉXICO 2015
SUBDIRECCIÓN
DESARROLLO
CAMBIOS, BANCO,BANCA FONDOS SERVICIOS, NUEVOS

LIQUIDACIÓN A PRIVADA, MERCADO DE FINANZAS, CAPITALES PROYECTOS
TERCEROS FIDUCIARIO DINERO FIX-A2K RIESGOS, PLD CAPITALES
FACTORAJE,
CRÉDITO, CORE BANCARIO
ARRENDADORA
BUS CENTRAL
BANCA
ELECTRÓNICA,
PORTALES
Figura 1 - 5 Nivel Gerencial Respecto a la Subdirección de Desarrollo
OFICINA DE PROYECTOS
PM Marco Antonio PM
Reyes Nava PM PROYECTOS
PROYECTOS AUDITORÍA
PROYECTOS MANTENIMIENTOS INFRAESTRUCTURA
ESTRATÉGICOS
REGULATORIOS Y
MANTENIMIENTOS
Figura 1 - 6 Nivel Administrativo Respecto a la Oficina de Proyectos
17
MÉXICO 2015
CAPÍTULO 2. ANTECEDENTES PARA IMPLEMENTAR UN MODELO DE
CALIDAD PARA DESARROLLO DE SOFTWARE
2.1 Implementación del modelo de calidad CMMI en las empresas de
software
a. Antecedente
Las empresas dedicas al desarrollo de software tiene la necesidad de
administrar, controlar y monitorear los proyectos de una manera más eficiente. El
aumento del costo operativo en la unidad de negocio de desarrollo de software, la
disminución notable en las ganancias, así como las diversas insatisfacciones del
cliente origina la búsqueda de una metodología que permita conocer a cada
momento el estatus, finanzas y comentarios de los clientes y colaboradores para
realizar proyectos rentables.
Establecer de acuerdo al modelo de CMMI las políticas y procedimientos
que permitan implementar el nivel de Madurez 2 (ML 2) para la constelación de
Desarrollo de Software (DEV) en la representación continua.
b. Objetivos
Los objetivos de la implementación:
a. Realizar un análisis situacional del nivel de madurez de la empresa
b. Determinar de acuerdo al análisis situacional el nivel de madurez que la
empresa puede implementar
18
MÉXICO 2015
c. Colaborar con la organización a la definición, implementación y
capacitación de sus políticas y procedimientos
d. Ejecutar proyectos basados en la metodología implementada
e. Apoyar en la optimización y mejora a los procesos
f. Colaborar en la certificación de la empresa como Líder de Mejora en
Procesos.
2.2 Adaptación del modelo de calidad CMMI en el proyecto de
“Modernización integral” para una institución gubernamental
a. Antecedente
MAAGTIC (Manual Administrativo de Aplicación General en Materia de
Tecnologías de la Información y Comunicaciones) es una normatividad para la
eficiencia operativa gubernamental de las operaciones del área de tecnologías de
la información y comunicación emitido por la Secretaría de Función por decreto
presidencial; cuyo ámbito de aplicación y alcance está definido para
implementarse en las instituciones a través de sus correspondientes unidades
administrativas responsables de proveer infraestructura y servicios de tecnologías
de la información y comunicaciones; regulado bajo el marco jurídico aplicable a
reglamentos, lineamientos, leyes, decretos y seguridad de la información.
MAAGTIC es un conjunto de 29 procesos en el que establece un marco rector
para la gestión de las TIC´s, agrupados en 4 grupos principales para la gestión del
gobierno, para la organización estratégica, para la ejecución entrega y soporte de
los servicios de TIC. Los procesos se basan en las mejores prácticas

19
MÉXICO 2015
internacionales como Six Sigma, COBIT, BSC, normas ISO (como la ISO/IEC
9001, ISO/IEC 27,000, entre otras), Risk IT, CMMI, PMI, ITIL, MoProSoft, Rational
Unified Process, etc. En resumen, “el mejor modelo de calidad es aquel que se
adapta a las necesidades” y en este caso encaja de manera precisa al utilizar una
guía de adaptación que fusionó ambos modelos, logrando una metodología
adaptable, robusta y enriquecedora al desarrollo del proyecto y la organización
gubernamental.
b. Objetivos
Realizar la guía de ajuste al proceso y entregables al proyecto con lo cual
se cumplan los procesos de calidad de ambas partes; tanto del cliente en la
metodología de MAAGTIC como del proveedor en CMMI ML 3.
Los objetivos de la guía de adaptación:
a. Conciliar el modelo de calidad de MAAGTIC con el modelo de proveedor.
b. Generar la guía de adaptación y obtener su aprobación por ambas partes.
c. Adaptar los entregables del proveedor para cumplir con las especificación
de la metodología MAAGTIC.
d. Control y monitorear el cumplimiento al proceso y guía de adaptación
aprobada.
20
MÉXICO 2015
2.3 Adaptación del modelo de calidad CMMI en el área de sistemas de una
institución bancaria y de valores y su convivencia con la metodología del
PMI (Project Management Institute)
a. Antecedente
Para el caso de la institución bancaria y de valores se manejaba una
metodología compleja que hacia al personal preguntar: ¿desarrollo o documento?
Y para dar la atención de un proyecto (ciclo de vida mayor a 3 meses) se pedía la
misma documentación que para la atención de un requerimiento de usuario (ciclo
de vida menor a 2 meses e incluso solo días). Es importante destacar que por el
tipo de empresa y operación, establecer ciclos largos detiene la productividad y
eso se ve reflejado en las ganancias que puede o no generar una casa de bolsa y
banco. Dado que la metodología anterior no permitía un control y monitoreo
adecuado surge la necesidad de adaptar y simplificar el procedimiento para ser
más eficientes en el trabajo interno, ante las instituciones reguladas y el cliente
final.
b. Objetivos
Realizar ajuste a la metodología de administración de proyectos para que la
organización cumpla en tiempo y forma con la atención de todos los
requerimientos solicitados por los usuarios internos y organismos regulatorios de
la banca mexicana.
21
MÉXICO 2015
Los objetivos a cumplir:
a. Optimizar el proceso actual de administración de proyectos.
b. Diferenciar la atención entre requerimientos de usuario y proyectos.
c. Definir el procedimiento de ventanilla para la entrega de requerimientos
d. Establecer una guía de documentación que se adapte a la atención de
requerimientos o proyectos
e. Control y monitorear el cumplimiento a los requerimientos y proyectos
22
MÉXICO 2015
CAPÍTULO 3. IMPLEMENTACIÓN Y ADAPTACIÓN DEL MODELO DE
CALIDAD CMMI PARA EL DESARROLLO DE SOFTWARE
3.1 Constelaciones de CMMI
En el modelo CMMI existen constelaciones que aparecen a partir de la
versión 1.2 que fue publicada en el año 2006, una constelación es una colección
de componentes utilizados para construir modelos, materiales de capacitación y
evaluación en un área de interés. En la cual existen 3 constelaciones publicadas.
(Véase figura 1 – 7).
Figura 1 – 7 Constelaciones de calidad de CMMI
CMMI para la adquisición:
CMMI para adquisición (CMMI-ACQ) es un conjunto de prácticas para
mejorar el proceso de adquisición de productos y servicios que provee al
comprador una guía para aplicar las mejores prácticas de CMMI.
23
MÉXICO 2015
Hoy en día las organizaciones son cada vez más compradoras de
capacidades necesarias para la obtención de productos y servicios de
proveedores y desarrollan cada vez menos estas capacidades en casa.
Las organizaciones lo toman como una estrategia de negocio, la cual es
ampliamente adoptada para mejorar la eficiencia operativa de una organización
mediante el aprovechamiento de las capacidades de los proveedores para ofrecer
soluciones de calidad y a menor costo, con la tecnología más apropiada.
El comprador tiene un objetivo específico que incluyen requerimientos para
mantener una relación con los usuarios finales y a la capacidad para comprender
sus necesidades.
Esta constelación ayuda al comprador extenderse más allá de garantizar la
capacidad correcta entregada por los proveedores como puede ser la integración
de producto o servicio, la transición en operación y la obtención de conocimiento y
adecuación para satisfacer las necesidades del cliente.
También proporciona una oportunidad de evitar y/o eliminar las barreras en
el proceso de adquisición por medio de sus prácticas y terminologías.
Todas las prácticas del Modelo CMMI-ACQ se enfocan en las actividades
del comprador, incluyen al proveedor de abastecimiento, desarrollo y atribución de
contratos con los proveedores.
24
MÉXICO 2015
CMMI para servicios:
Es la constelación de CMMI que ofrece un marco de referencia adecuado
para la administración y la entrega de los servicios que ofrece una institución,
proporcionando una guía para aplicar las mejores prácticas en una organización
que provee servicios.
Cubre las actividades requeridas para establecer entregas y administra
servicios (uno o varios) por lo cual pretende mejorar el costo, tiempo y
presupuesto de los proyectos con la capacidad de ampliarse a otras áreas de la
organización, de tal manera que la operación de los otros modelos operan de
forma síncrona con otras iniciativas existentes.
CMMI-SVC es una nueva constelación dentro de la suite CMMI que
pretende cubrir las necesidades de la industria de servicios, la cual surge de la
necesidad de establecer un marco de referencia como medio para mejorar las
satisfacción del cliente, el desempeño y la rentabilidad de las organizaciones que
proveen servicios.
Un servicio es un producto intangible y no almacenable que son entregados
mediante procesos.
Esta constelación es la respuesta de SEI ante otros modelos y estándares
orientados a los servicios de TI como ITLI, MS15000, ISO2000, etc.
25
MÉXICO 2015
CMMI para desarrollo:
CMMI-DEV Utiliza un programa de mejora de procesos para las
organizaciones de desarrollo, denominado como una colección de mejoras
prácticas las cuales las organizaciones deben seguir para mejorar la eficacia,
eficiencia y la calidad de sus productos y servicios.
Cubre el ciclo de vida de los productos y servicios desde el inicio hasta la
entrega y mantenimiento de los mismos. Incluye una identificación de las
fortalezas y debilidades de los procesos de una organización convirtiendo las
debilidades en fortalezas.
Éste es el modelo más conocido del CMMI y fue diseñado para una
solución integra y completa para las actividades de desarrollo y mantenimiento
aplicadas a productos y servicios.
3.2 Representaciones
CMMI formado por los modelos ya mencionados integra dos tipos de
representaciones, continua y por etapas o niveles. La representación continua
enfocada a la mejora de la calidad de las áreas de proceso y la representación por
etapas a la mejora de un conjunto de áreas de proceso.
Representación continua
Permite a las instituciones seleccionar cualquier área de proceso para el
mejoramiento de las mismas. Evalúa cada área de proceso.
26
MÉXICO 2015
Representación por etapas (niveles)
Esta representación permite llevar a un conjunto de áreas de proceso a un
nivel de madurez, el logro de cada nivel define el mejoramiento de una empresa
lo que permite una mejora incremental y duradera (Véase figura 1- 8).
Figura 1 – 8 Las 2 diferentes formar de representación del modelo de CMMI

(continua y por etapas o escalonada)
3.2.1 Representación continua:
La representación continua en un modelo en el cual consiste en evaluar una
o varios procesos que se usan en una organización, estableciendo una línea base
para que a partir de ésta se mida la mejora individual en cada área, dicha
organización lo evalúa y lo califica en uno de sus 6 niveles de capacidad, entre 1 y
6.
Normalmente las organizaciones operan en un nivel de capacidad
dependiendo de las distintas áreas de proceso, y en consecuencia el resultado de
una valoración será el perfil de capacidad del proceso o cada área de proceso.
27
MÉXICO 2015
Una organización puede elegir el mejorar el rendimiento de un punto en
específico, el cual, le cause problemas dentro uno o varios procesos. Este modelo
es llamado un modelo más fino debido a que considera prácticas individuales o en
grupo, puede elegir uno o varios procesos que estén relacionados con los
objetivos de negocios de la organización.
Se dice que esta representación es la más flexible ya que permite que las
organizaciones elijan un punto para aplicar CMMI, el cual por algún motivo
desean corregir u optimizar.
Niveles de capacidad
Los niveles de capacidad se caracterizan por mejorar un estado mal
definido hasta uno que utiliza cuantitativamente información para definir, gestionar
y hacer las mejoras que satisfagan a los objetivos de la organización.
Estos niveles de capacidad son aplicados en el logro de mejora de
procesos de una organización en áreas de procesos individuales, estos niveles
son un medio de mejorar los procesos de forma incremental.
Existen 6 niveles de capacidad que van de 0 a 5:
Nivel 0.- Incompleto:
Un nivel de capacidad de nivel 0 es un nivel en el cual los procesos son
incompletos, no son realizados en su totalidad, no se ejecutan de ahí su nombre
incompletos.
28
MÉXICO 2015
Nivel 1.- Realizado
El proceso de nivel de capacidad 1, es caracterizado como un proceso
realizado por que es un proceso que satisface los objetivos específicos de una
Área de proceso, es decir que soporta y trabaja sólo lo necesario para producir los
productos del trabajo.
Un proceso realizado da como resultado las mejoras importantes y si no se
institucionalizan las mejoras pueden perderse.
Nivel 2.- Administrado – gestionado
Un proceso de nivel de capacidad 2 se caracteriza como un proceso
administrado o gestionado debido a que este es un proceso realizado (de nivel 1)
que tiene la infraestructura básica para que soporte el proceso. Se planea y
ejecuta de acuerdo a las políticas, utiliza 3 dimensiones críticas para producir
resultados controlados. Monitoriza, controla, revisa y evalúa la adherencia al
proceso.
La disciplina que contiene este nivel ayuda a las organizaciones a que las
prácticas se mantengan durante tiempos de estrés.
29
MÉXICO 2015
Nivel 3.- Definido
Un proceso de nivel de capacidad 3, es un proceso caracterizado como
gestionado, debido a que se adapta a partir de los procesos estándar de la
organización de acuerdo a la guía de adaptación de la operación. Establece el
propósito, el criterio de entrada, las actividades, los roles, medidas, etapas de
evaluación, salidas y criterios de salida. Contribuye a los activos del proceso de
la organización con productos del trabajo, medida de información adicional de
mejora de procesos.
Nivel 4.- Gestionado cuantitativamente.
Un proceso gestionado cuantitativamente es un proceso definido (de nivel
3), establece los objetivos de calidad y rendimiento del proceso que se gestionan a
lo largo de la vida del proceso, además de ser definido se controla utilizando
técnicas estadísticas.
Con el tiempo de estas técnicas brindan una mayor información de la
calidad y del estado del proyecto permitiendo compararlo con otros proyectos
similares y detectar cualquier anomalía tempranamente y corregirla.
Nivel 5.- Optimización
Es un proceso gestionado cuantitativamente, cada proceso es analizado y
controlado permanentemente con la intención de que sea mejorado en todo
30
MÉXICO 2015
momento. El objetivo de un proceso optimizado es mejorar continuamente el rango
de ejecución mediante mejoras de éste.
Para un área de proceso alcanzar el nivel 5 quiere decir que el área de
proceso se ha estabilizado en sus subprocesos y que reduce las causas comunes
de variación de este.
3.2.2 Representación escalonada
Define 5 niveles de madurez dentro de los cuales se puede encontrar una
organización. Cada nivel de madurez representa e indica el camino evolutivo que
permite alcanzar la madurez del proceso.
Dividido en etapas para mejorar los procesos de una organización, estos
son probados agrupados y ordenados. Cada nivel de madurez contiene un
conjunto de áreas de proceso que indican donde una organización debería
enfocarla mejora de uno o varios de sus procesos. Cada área de proceso se
describe como prácticas que contribuyen a satisfacer objetivos, estas prácticas
son actividades que contribuyen a la implementación de un área de proceso.
Se aumenta el nivel de madurez cuando las áreas de proceso satisfacen los
objetivos del nivel de madurez donde se encuentran ubicados.
Niveles de madurez
Un nivel de Madurez es un camino evolutivo definido para la mejora de los
procesos de una organización.
31
MÉXICO 2015
Los niveles de madurez son un indicador donde señala que tan maduros
son los procesos de la institución, proporcionan una manera de ejecutar y
caracterizar el desempeño de sus procesos, los niveles de madures donde se
pueden encontrar las organizaciones son 5:
Nivel 1 Inicial
El Nivel 1 de CMMI es en donde se encuentran todas las empresas de
software, esto es debido a que tan solo por el hecho de existir como empresa de
software ya está en el nivel 1.
En este nivel los procesos dependen de la competencia de las personas, la
empresa no dispone de los procesos y controles definidos, se trabajan con
procedimientos que no están normalizados. Los resultados de la calidad obtenidos
son consecuencia de las personas y de las herramientas no de los procesos por
qué no los hay o no se usan.
Nivel 2 Repetible
En este nivel los proyectos de las organizaciones son planeados y
ejecutados de acuerdo con una política, se emplea gente con las capacidades y
los recursos adecuados para producir salidas. Los proyectos son monitoreados
controlados y revisados, se puede saber el estado de estos en cualquier momento.
32
MÉXICO 2015
Se definen procesos efectivos, que son definidos, documentados,
medidos, reforzados y mejorados, también define los estándares de los proyectos
y las organizaciones asegurándose que esto sean respetados.
El principal objetivo de este nivel es institucionalizar los procesos y permitir
a las organizaciones repetir las prácticas de los proyectos exitosos anteriores.
Establece compromisos por las partes interesadas para el control básico de
administración de proyectos.
Nivel 3 Definido
En el nivel 3 los procesos son bien caracterizados y entendibles, están
descritos en procedimientos, herramientas, estándares y métodos los cuales son
establecidos y mejorados con el tiempo.
Un proceso de nivel 3 o proceso definido deja claramente establecido el
propósito, los criterios de entrada, las actividades, los roles, medidas, etapas de
verificación, y criterios de salida. Como el proceso está bien definido la
administración del proyecto tiene una visión interna muy amplia sobre el progreso
técnico del proyecto.
En pocas palabras lo procesos de la organización, están documentados,
estandarizados e integrados y el procesos de desarrollar proyectos está definido,
documentado y personal está entrenado en él y su uso es obligatorio.
33
MÉXICO 2015
Nivel 4 Gestionado cuantitativamente.
En este nivel de madurez, la organización y los proyectos establecen
objetivos cuantitativos medibles para el rendimiento de calidad y del proceso, los
cuales se utilizan como criterios de administración de los procesos.
El rendimiento de calidad y del proceso se comprende en términos
estadísticos. Se usan objetivos medibles para alcanzar las necesidades de los
clientes y de la organización. Los directivos y desarrolladores utilizan los datos con
técnicas estadísticas para la administración de los procesos y resultados.
Dichas técnicas son utilizadas a nivel de la organización y de proyecto para
comprender resultados anteriores de la calidad de los productos y de los servicios
y predecir los futuros resultados.
En otras palabras la administración y el proceso se pueden ajustar y
adaptar a proyectos particulares sin pérdida de calidad o desviaciones de las
especificaciones.
Nivel 5 Optimizado.
Este es el nivel de madurez más alto donde las organizaciones mejoran
continuamente sus procesos basados en una comprensión de las causas
comunes de variaciones inherentes al proceso. Se centra en mejorar
continuamente el rendimiento de procesos, mediante mejoras incrementales e
innovadoras de proceso con tecnología innovadora.
34
MÉXICO 2015
La organización se interesa en tratar las causas comunes de variaciones
inherentes que se presentan, para mejorar el rendimiento del proceso y así poder
alcanzar los objetivos de mejora de procesos establecidos.
En las áreas clave de proceso se centran, en las mejoras continuas y no solo se
obtiene el control, si no también se consigue eficacia.
3.3 Áreas de proceso
Un área de proceso es un gripo de prácticas que se realizan
conjuntamente para alcanzar determinadas metas y objetivos, utilizados
principalmente para la mejora de una área.
Definidas como el conjunto de actividades agrupadas que le facilitan a una
organización el camino a la mejora, establecen la capacidad del proceso de la
misma cubriendo el desarrollo del producto y/o servicio hasta el mantenimiento de
los mismos.
Existen 25 áreas de proceso agrupadas en 4 disciplinas diferentes, cada
una presente un campo diferente de conocimiento.
3.3.1 Disciplinas
 Administración de proyectos
Está enfocada a la planeación, seguimiento y control del proyecto. Estas
actividades permiten asegurar que el proyecto se lleve a cabo en el tiempo
35
MÉXICO 2015
establecido y de acuerdo a la planificación, así como asegurar de que cumpla los
requerimientos establecidos.
Mantiene un entorno de colaboración entre equipos y los más importantes
es que proporciona un método para gestionar cuantitativamente el proyecto
anticipándose a los problemas.
 Administración de procesos
Contiene actividades del proyecto relacionado con la definición,
planificación, asignación de recursos, implementación, ejecución, seguimiento,
control, evaluación, medición y mejora de los procesos.
Cada una de las áreas depende de la capacidad de desarrollar e
implementar los procesos, la organización analizara los datos del rendimiento de
los mismos recolectados en los procesos que ya están definidos para el desarrollo
de datos estadísticos de la calidad del producto.
 Ingeniería
La ingeniería de procesos cubre actividades de desarrollo y
mantenimiento. Dan soporte a una estrategia de mejora de procesos orientado a
productos, estos apuntan a objetivos de negocio.
Las áreas de proceso de ingeniería se aplican al desarrollo de cualquier
producto o servicio dentro del dominio de desarrollo soportando las actividades del
ciclo de vida del producto desde el desarrollo inicial.
36
MÉXICO 2015
 Soporte
Las áreas de soporte cubren actividades que dan soporte al desarrollo y al
mantenimiento del producto.
Se enfocan a los procesos que están dirigidos hacia el proyecto y también
estos pueden dirigirse a procesos que se aplican generalmente a la organización.
Establecen y mantienen un entorno de trabajo que estimula la integración del
personal para premiar comportamientos integradores.
3.3.2 Elementos de las áreas de procesos.
 Áreas de proceso:
Conjunto de prácticas ejecutadas en un área que satisfacen un conjunto
de metas.
 Metas especificas
Aplicadas para describir características únicas sobre un área de proceso
que deben ser implementadas.
 Practicas especificas
Es una actividad considerada como importante para lograr una meta
específica, son interpretaciones y descripciones detalladas que resultan útiles para
la mejora de proceso.
37
MÉXICO 2015
 Sub practicas
Son descripciones detalladas que sirven de guía para interpretar las
prácticas específicas o genéricas.
 Metas genéricas
Son denominadas genéricas debido a que aparecen en varias áreas de
proceso.
 Practicas genéricas
Buscan la institucionalización para asegurar que las procesos asociados
con las áreas de proceso sean eficaces, repetibles y duraderos.
3.3.3 El Modelo de implementación IDEAL
IDEAL un método elaborado por el SEI para dirigir el inicio, planificación e
implementación de mejora de procesos de una organización.
El modelo IDEAL provee un enfoque disciplinado de ingeniería para la
mejora de procesos y establece fundamentos para la estrategia a largo plazo. Es
un modelo de mejora organizacional que sirve como mapa para la mejora de
procesos.
Se le llama IDEAL por sus 5 etapas (Véase Figura 1 – 9):
 Iniciar (Initiating)
 Diagnosticar (Diagnosing)
38
MÉXICO 2015
 Establecer (Establishing)
 Actuar (Acting)
 Aprender (Learning)
Figura 1 - 9 Modelo IDEAL creado por el SEI para la dirección de

proyectos
39
MÉXICO 2015
3.3.3.1 Fases del modelo IDEAL
Fase: Iniciar
Es la fase en la cual se establecer las bases de proyecto, ayuda a
establecer y asegurar el patrocinio de la gerencia para obtener el desarrollo de la
infraestructura que se necesitara para realizar el proceso de mejora.
Establece fundamentos básicos para garantizar la iniciativa de
mejoramiento de procesos, la organización decide cómo hay que organizarse
para establecer las bases de una serie de mejoras. Esta fase inicia cuando la
organización identifica y admite la necesidad de posibles mejoras.
Fase: Diagnostico
Evalúa mediante un método formal, las fortalezas y debilidades del
proceso que se sigue en los proyectos. Los objetivos se relacionan con prácticas
que ya existen y se determinan aquellas que no están bien desarrolladas.
Se identifica el punto de partida y el destino antes de empezar con la tarea
de identificar las debilidades y las fortalezas de la organización en sus prácticas
actuales.
40
MÉXICO 2015
Fase: Establecer
Realiza una planificación para los mejoramientos que se desean alcanzar,
organizara y preparara a un grupo de personas quienes formaran el grupo de
procesos para establecer y desarrollar el plan de acción.
El plan de acción es un plan detallado con acciones específicas y de
responsabilidades que está basado en los objetivos que se quieren alcanzar, la
elaboración del plan no es una tarea fácil ya que se definen prioridades, se
consideran recursos, dependencias, factores externos y necesidades de la
organización.
Fase: Actuar
Esta es la fase donde se lleva más tiempo y la que consume más
recursos, se implementan acciones que se establecieron en el plan de acción.
Crea la mejor solución para resolver las necesidades de la organización,
estas requieren ser probadas en proyectos pilotos para decidir si serán
institucionalizadas en otros proyectos y son refinadas para alcanzar una solución
satisfactoria. Una vez alcanzada la solución es implementada en toda la
organización
Fase: Aprender
En un proyecto de mejora de procesos son evaluadas las mejoras
aplicadas y aprendidas como la conclusión y el inicio de un nuevo ciclo.
41
MÉXICO 2015
Esta fase tiene como propósito revisar y analizar las lecciones aprendidas
en las 4 fases anteriores del modelo, incorporando motivos, metas, compromiso y
el patrocinio para el proyecto. El proceso de evolución de las prácticas aprendidas
ocurre al final del ciclo pero el proceso de retroalimentación es continuo.
3.4 Método de evaluación formal de CMMI SCAMPI
Con el surgimiento de CMMI, el SEI desarrollo en paralelo un método
denominado SCAMPI el cual, es un método de evaluación formal creado por el
SEI que utiliza como referencia el modelo CMMI y es utilizado para identificar
fortalezas y debilidades de los procesos de la organización. Este método revela
los riesgos del desarrollo y determina el nivel de madurez de la organización y el
nivel de capacidad de sus procesos.
El método SCAMPI requiere una capacitación forzosa por parte de las
personas que integran el equipo de evaluación, estas deben conocer el modelo
CMMI el cual será usado para la evaluación SCAMPI. Como requisito obligatorio
el SEI indica que todas las personas que conforman el jurado calificador deben
haber cursado exitosamente el curso oficial “Introduction to SW-CMMI” impartido
por el SEI.
3.4.1 Clases de SCAMPI
SCAMPI tiene 3 clases de evaluación: clases A, B Y C, en cada una de
estas clases se lleva a cabo un conjunto de procesos.
42
MÉXICO 2015
Las distintas clases de SCAMPI pueden ser utilizadas desde una simple
prueba de enfoque hasta una rigurosa evaluación detallada, obteniendo la
posibilidad de obtener un nivel de madurez.
El SCAMPI es realizado por evaluadores autorizados por el SEI llamados
Lead Apraissers (Líder Evaluador Scampi)
SCAMPI Clase A
Una evaluación SCAMPI de tipo A es el método más rigoroso del SEI para
la evaluación de procesos de una organización.
Una evaluación de este tipo se realiza cuando una organización se ha
encaminado en mejorar sus procesos importantes, se centra en la
institucionalización mediante una rigurosa y detallada recolección de datos sobre
la implementación de los procesos en la organización. SCAMPI A permite realizar
un “Benchmarking” y obtener una evaluación de nivel de madurez.
Este método de clase A es el único de la familia de evaluaciones que
permite la obtención de un nivel de madurez.
Benchmarking: En las ciencias de la administración de empresas, puede
definirse como un proceso sistemático y continuo para una evaluación
comparativamente de productos, servicios y procesos de trabajo en
organizaciones.
43
MÉXICO 2015
SCAMPI Clase B
Una evaluación SCAMPI tipo B está diseñada para proporcionar
resultados detallados, esta es necesaria cuando una organización necesita
evaluar su desempeño hacia un objetivo de nivel de madurez pero a un costo más
bajo.
Prácticamente SCAMPI tipo B ayuda a las organizaciones a entender el
estado en que se encuentra su software y el proceso de ingeniería de sistemas
que está manejando, también se puede utilizar para comprobar las mejoras que
sean hecho en la organización y detectar las áreas donde la documentación no
está bien definida como debe ser o donde los procesos no son apropiados para la
organización.
SCAMPI Clase C
La evaluación SCAMPI tipo C es la evaluación menos formal si la
comparamos con las otras 2 clases ya que dura mucho menos tiempo que ellas y
porque es utilizada para crear una línea base para iniciar el programa de mejoras
y no verifica la calidad de aplicación de los mismos.
Es la evaluación inicial que hacen los expertos evaluadores para saber
qué nivel podría estar adoptando, con el tiempo vendrá SCAMPI B donde
seriamente se decide que se quiere certificar.
44
MÉXICO 2015
Línea base: Se define como un producto que acaba de ser aprobado y
que define la base del producto también puede verse como un punto de referencia
en la configuración de un proyecto que marca un estado estable en algún punto
del proyecto.
3.4.2 Herramientas de evaluación
El método SCAMPI define una serie de reglas para la evaluación del
modelo, las cuales deben utilizarse para valorar distintas partes del mismo, estas
reglas hacen necesario el uso de herramientas para una evaluación detallada y
estadística.
Existen 3 herramientas de evaluación para CMMI:
CMM-QUEST:
Es una herramienta que permite efectuar evaluaciones de acuerdo al
modelo CMMI-SE en su representación continua. Se limita a asignar valores a los
objetivos, no permite evaluaciones a nivel de prácticas y no brinda soporte al
método SCAMPI.
Es la herramienta de Auto evaluación para las organizaciones de
desarrollo de software y proyectos para evaluar y analizar sus procesos de
desarrollo de forma rápida y eficiente conforme a CMMI – DEV.
Realiza una evaluación para determinar sus fortalezas y debilidades con
respecto a la forma de desarrollar software. El resultado contiene evaluaciones
45
MÉXICO 2015
completas y análisis en forma de cartas, que corresponden a los perfiles de
capacidad.
IME Toolkit:
Es una herramienta de valoración rápida de procesos de software. Efectúa
evaluaciones de acuerdo al modelo CMMI – SE/SW. Las evaluaciones asignan
valores numéricos a las prácticas en base a los cuales la herramienta genera
puntajes para las áreas de proceso y no brinda soporte para el método SCAMPI.
APPRAISAL WISARD:
Esta herramienta que se basa en organizar y gestionar la auditoria de
cumplimiento más amplio, las actividades relacionadas con el uso de cualquier
modelo interno o externo. Requiere amplios conocimientos de SCAMPI por parte
del usuario.
3.5 Casos de éxito
Los Casos de éxito que se mencionan a continuación tiene el objetivo de
mostrar, como a partir de la adopción de una metodología, las organizaciones
obtienen beneficios desde tener una certificación reconocida a nivel mundial,
estandarizar sus procesos y procedimientos desde la creación de la propuesta
comercial y la adaptación con otras metodologías en proyectos complejos.
46
MÉXICO 2015
3.5.1 Implementación del modelo de calidad CMMI en las empresas de
desarrollo de software
Cuando se realiza una implementación de un modelo de calidad, siempre el
primer paso es realizar un análisis situacional de los procesos que ejecuta o no
ejecuta la organización. Con esta evaluación sabremos el nivel de madurez de la
empresa de acuerdo al marco establecido por CMMI. Esta información la
proporcionan los dueños del proceso por lo que es vital acercarse con cada uno
de los administradores de proyectos, líder de proyectos, analistas, diseñadores,
programadores, ingenieros de pruebas, administradores de la configuración e
involucrado relevante en el desarrollo de un proyecto.
Algo importante es que este análisis se basará en el nivel de madurez que
la organización quiera adoptar para el desarrollo para ello se explica ante el comité
de mejora de procesos de la empresa las áreas de proceso que deberán cumplir
de acuerdo al modelo. Si en este análisis situacional la organización está
desarrollando otras áreas de proceso de otro nivel de madurez o no realiza la
ejecución de alguna de ellas, es importante que por el método continuo se e
evalúen permitiendo tener un mayor grado de madurez (en el caso de ejecutar
más áreas de las solicitadas por un nivel de CMMI) y ser limitante en el proceso de
la organización (para aquellas áreas que no son utilizadas) (Véase figura 1 – 10 y
1 - 11).
47
MÉXICO 2015
Figura 1 – 10 Análisis situacional de las áreas de proceso en una empresa

antes de la mejora de procesos a implementar
Figura 1 – 11 Tiempo promedio para implementar de CMMI de ML1 a ML2 es

de aproximadamente 23 meses.
48
MÉXICO 2015
En algunos casos las metas pueden superarse por ejemplo: La meta era
establecer el nivel de madurez 2 (ML 2 –Administrado-) sin embargo el análisis
situacional arrojó que también se ejecutaban dos áreas de procesos del nivel 3
(ML 3 –Definido-) correspondiente a la parte de Ingeniería.
Lo que se pretende con el nivel 2 es conseguir que en los proyectos de la
organización haya una gestión de los requisitos y que los procesos (formas de
hacer las cosas) estén planeados, ejecutados, medidos y controlados. El nivel 3 es
la estandarización de procesos organizacionales. (Véase Figura 1 -12)
Nivel Enfoque Acrónimo Área de Proceso
REQM Administración de
requerimientos
PP Planeación de proyectos
PMC Monitoreo y control de
proyecto
SAM Administración de acuerdos
Nivel 2 Administración de proyectos
con proveedores
MA Medición y análisis
PPQA Aseguramiento de calidad
del producto y proceso
CM Administración de la
configuración
Estandarización de VER Verificación
Nivel 3
procesos VAL Validación
Figura 1 – 12 Ejemplo de un proyecto de implementación de CMMI

combinando áreas de procesos de nivel 2 y 3.
Explicado un poco más:
El uso de los procesos a nivel 2 ayuda a ejecutan y gestionan de acuerdo
con los planes de trabajo del proyecto.
El estado de los elementos de trabajo (análisis, diseño, código y
documentación) están visibles (estado de avance) a la gerencia en puntos
49
MÉXICO 2015
definidos (hitos del proyecto). Se sabe cuánto trabajo está hecho y cuánto queda
por hacer.
Los compromisos adquiridos con todas las personas involucradas en el
proyecto se revisan de acuerdo a las necesidades. Los elementos de trabajo se
revisan con las personas involucradas y son controlados. Estos elementos de
trabajo satisfacen las especificaciones, estándares y objetivos.
Áreas de proceso del nivel 2 de CMMI:
1. Administración de requisitos
2. Planeación de proyectos
3. Monitorización y control de proyecto
4. Medición y análisis
5. Aseguramiento de calidad del producto y proceso
6. Administración de la configuración
7. Administración de acuerdos con proveedores (No aplicó para la
organización)
El uso de los procesos a nivel 3 ayuda a las organizaciones para disponer de
correctos procedimientos de coordinación entre grupos, formación del personal,
técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los
procesos.
50
MÉXICO 2015
Áreas de proceso del nivel 3 de CMMI:
1. Verificación
2. Validación
Pasaremos a explicar cada una de las áreas de proceso con un poco más de
detalle.
1. Administración de requerimientos
El objetivo de la gestión de requisitos es gestionar los requisitos de los
elementos del proyecto y sus componentes e identificar inconsistencias entre
estos requisitos, el plan de proyectos y los elementos de trabajo.
En este proceso se deben de gestionar todos los requisitos del proyecto, tanto
los requisitos técnicos como los requisitos no técnicos.
Estos requisitos han de ser revisados conjuntamente con la fuente de los
mismos así como con las personas que se encargarán del desarrollo posterior.
2. Planeación de proyectos
El objetivo de la planificación de proyectos es establecer y mantener planes
que define las actividades del proyecto.
Las tareas que conlleva la planificación de proyectos son:
- Desarrollar un plan inicial del proyecto
51
MÉXICO 2015
- Establecer una relación adecuada con todas las personas involucradas en
el proyecto
- Obtener compromiso con el plan
- Mantener el plan durante el desarrollo del proyecto
El plan incluye estimación de los elementos de trabajo y tareas, recursos
necesarios, negociación de compromisos, establecimiento de un calendario, e
identificación y análisis de los posibles riesgos que pueda tener el proyecto.
El plan de proyectos es un herramienta de trabajo viva que se debe de
actualizar con mucha frecuencia ya que los requisitos cambiarán, habrá que
reestimar, habrá riesgos que desaparezcan y otros que surjan nuevos, habrá que
tomar acciones correctivas…
3. Monitoreo y control de proyectos
El objetivo de la monitorización y control de proyectos es proporcionar una
compresión del estado del proyecto para que se puedan tomar acciones
correctivas cuando la ejecución de proyecto se desvíe del plan.
El documento del plan de proyecto es la base para monitorizar las actividades,
comunicar el estado y tomar acciones correctivas. El progreso se determina
comparando los actuales elementos de trabajo: tareas, horas realizadas, coste y
calendario actual, con los estimados en el plan de proyecto. Una apropiada
52
MÉXICO 2015
visibilidad nos permitirá tomar acciones correctivas antes de que el trabajo real se
desvíe mucho del plan.
Estas acciones que tomaremos, harán que tengamos que rehacer/ajustar
nuestro plan de proyectos.
4. Medición y análisis
El objetivo de la medición y el análisis es desarrollar y sostener una capacidad
de medición que sea usada para ayudar a las necesidades de información de la
gerencia.
Los datos tomados para la medición deben estar alineados con los objetivos de
la empresa para proporcionar información útil a la misma.
Se ha de implantar un mecanismo de recogida de datos, almacenamiento y
análisis de los mismos de forma que las decisiones que se tomen puedan estar
basadas en estos datos.
Este sistema tiene que permitir además:
- Planificación y estimación objetiva
- Comparar el rendimiento actual contra el rendimiento esperado en el plan
- Identificar y resolver problemas relacionados con los procesos
- Proporcionar una base para añadir métricas en procesos futuros
53
MÉXICO 2015
5. Aseguramiento de la calidad del producto y proceso
El objetivo del aseguramiento de la calidad es proporcionar personas y gestión
con el objetivo de que los procesos y los elementos de trabajo cumplan los
procesos.
Esto se consigue mediante:
- Evaluar objetivamente la ejecución de los procesos, los elementos de
trabajo y servicios contra las descripciones de procesos, estándares y
procedimientos.
- Identificar y documentar los elementos no conformes.
- Proporcionar información a las personas que están usando los procesos y a
los gestores, de los resultados de las actividades del aseguramiento de la
calidad.
- Asegurar de que los elementos no conformes son arreglados.
Esta es un área de proceso clave, que a veces no se le da la suficiente
importancia, pero que sin ella no será posible implanta un modelo de calidad.
6. Administración de la configuración
El objetivo de la gestión de la configuración es establecer y mantener la
integridad de los elementos de trabajo identificando, controlando y auditando
dichos elementos.
54
MÉXICO 2015
Más concretamente mediante:
- La identificación de los elementos de trabajo que componen una línea base.
- Controlando los cambios de dichos elementos
- Proporcionando formas de construir los elementos de trabajo a partir del
sistema de control de la configuración
- Mantener la integridad de las líneas base
- Proporcionar información precisa de los datos de la configuración a
desarrolladores y clientes.
Quizás esto le suene a chino, lo que viene a decir es que necesitas tener un
sistema de control y gestión de versiones, como puede ser: Source Safe, CVS,
PVCS, ClearClase, etc.
7. Verificación
El propósito es asegurar que los productos de trabajo seleccionados
responden a los requerimientos especificados. A continuación se desglosan las
metas a conseguir con este proceso, y las prácticas que se requieren para
conseguir estas metas:
Preparar la verificación
- Seleccionar los productos de trabajo para la verificación
- Establecer el entorno de verificación.
- Establecer los procedimientos y criterios de verificación.
55
MÉXICO 2015
- Realizar revisiones por terceros.
- Preparar revisiones por terceros.
- Realizar revisiones por terceros.
- Analizar resultados de revisiones por terceros.
- Verificar los productos de trabajo seleccionados.
- Realizar la verificación.
- Analizar los resultados de la verificación e identificar las acciones
correctivas.
8. Validación
El propósito es demostrar que un producto o componente satisface su uso
pretendido, en el ambiente operativo planeado. A continuación se desglosan las
metas a conseguir con este proceso, y las prácticas que se requieren para
conseguir estas metas:
Preparar la validación.
- Seleccionar los productos a validar.
- Establecer el entorno de validación.
- Establecer los procedimientos y criterios de validación.
- Validar los productos o componentes de los productos.
- Realizar la validación.
- Analizar los resultados de la validación.
56
MÉXICO 2015
El paso siguiente a la identificación de las áreas de proceso es la elaboración
de un plan de trabajo para definir, capacitar e implementar cada una de las áreas
de proceso. Aquí se vuelve fundamental la ubicación de los involucrados
relevantes que ejecutan los procesos de la organización, ya que sus
responsabilidades serán:
1. Definir las políticas y procedimiento
2. Capacitar a los nuevos recursos que se integren a la organización
3. Ejecutar y monitorear los procesos
4. Realizar mejoras a los procesos
Todos los involucrados relevantes conformaran el SEPG (Software Engineering
Process Group) – Equipo de Ingeniería en Mejora de Procesos de Software- con
los siguientes roles y responsabilidad:
a. Sponsor o patrocinador del proyecto de mejora.
 La persona de la organización responsable de canalizar todo los esfuerzos
de la mejora de procesos. Esta persona tiene la facultad de asignar
recursos financieros y humanos al proyecto. Esta persona se encuentra en
el nivel de directivo de la organización.
b. Consultor de mejora de procesos
 La persona externa a la organización con el conocimiento suficiente en el
marco de referencia (CMMI) para:
 Dar soporte a la gestión del proyecto de mejora
57
MÉXICO 2015
 Proporcionar el enfoque técnico de la adecuación
 Dar soporte a la implantación y gestión del cambio
 Dar soporte a la definición de los procesos.
 Verificar la adherencia a las prácticas del modelo.
 Validar el avance del proyecto.
c. Líder de mejora de procesos
 La persona de la organización parte del grupo de mejora que revisa los
procesos. Esta persona asigna tareas a los miembros de la SEPG,
monitorea sus esfuerzos, y planea las tareas diarias.
d. Líder de proyecto
 Responsable de detectar las necesidades de los usuarios y gestionar los
recursos económicos, materiales y humanos, para obtener los resultados
esperados en los plazos previstos y con la calidad necesaria. Es la persona
que tiene la responsabilidad total del planeamiento y la ejecución acertados
de cualquier proyecto
e. Análisis de sistemas
 El analista de sistemas evalúa de manera sistemática el funcionamiento de
un negocio mediante el examen de la entrada y el procesamiento de datos
y su consiguiente producción de información, con el propósito de mejorar
los procesos de una organización.
f. Desarrollador
58
MÉXICO 2015
 Es un programador que se dedica a una o más facetas del proceso de
desarrollo de software, un ámbito algo más amplio de la programación. Esta
persona puede contribuir a la visión general del proyecto más a nivel de
aplicación que a nivel de componentes o en las tareas de programación
individuales.
g. Administrador de la configuración
 Nos ayuda a localizar más fácilmente nuestros productos, ya sean para uso
propio o de algún otro involucrado en el proyecto. Adicionalmente, nos
ayuda a tener un control sobre las versiones de lo que vamos
desarrollando. De hecho, nació con la idea de poder establecer
mecanismos para tener el control sobre lo que se estaba creando en el ciclo
de desarrollo de software. Esto fue porque se tenían sistemas complejos y
se quería reducir el tiempo de respuesta al momento de buscar algún
producto de trabajo en los proyectos.
h. Ingeniero de pruebas
 Realizar pruebas de ejecución del software, detectar posibles fallos y
analizar desde el punto de vista del usuario detalles de usabilidad del
sistema de información a implementar.
i. Asegurador de la calidad
 El aseguramiento de la calidad del software provee claro control del
proceso que está siendo usado por el proyecto y del producto que se está
construyendo.
59
MÉXICO 2015
Algunos de los documentos definidos por el equipo de mejora de proceso son
los siguientes (Véase Figura 1 – 13 al 20):
Figura 1 – 13 Índice de una especificación de requerimientos de software
60
MÉXICO 2015
Figura 1 – 14 Índice de un plan de desarrollo de proyecto (PDP)
61
MÉXICO 2015
Figura 1 – 15 Ejemplo de un plan de trabajo
Figura 1 – 16 Índice de minuta
62
MÉXICO 2015
Figura 1 – 17 Ejemplo de control en excel para los indicadores del proyecto
Figura 1 – 18 Gráfica de control del valor ganado de un proyecto
63
MÉXICO 2015
Figura 1 – 19 Ejemplo de control en excel para los indicadores de calidad del

proyecto
64
MÉXICO 2015
Figura 1 – 20 Índice del plan de gestión de la configuración del proyecto
Ya que todo el equipo de mejora de procesos ha definido sus políticas,
procedimientos y se encuentran capacitados en los mismo; llega el momento de
llevarlo a la práctica con aquellos proyectos foco que servirán para la certificación
de la organización. Algo importante de resaltar es que para lograr la certificación
NO es obligatorio que los proyectos estén liberados o hayan cumplido todo el ciclo
de la metodología; si no que los procesos implementados en la organización se
ejecuten y permitan monitorear y control los proyectos.
65
MÉXICO 2015
La visión errónea de muchas organizaciones es implementar recetas de
cocina, que en mi experiencia, solo crean burocracia hacia la organización,
descontento, confusión y fracaso en cumplir los objetivos de los clientes y de la
propia empresa. Aunque suene reiterativo: “El mejor proceso implementado es
aquél que se adapta a las necesidades, capacidades y objetivos de la
organización”.
Para el caso de estudio, los 3 proyectos seleccionados para iniciar la
implementación de su metodología y utilizarlos para lograr su certificación CMMI
ML 2 son los siguientes:
3.5.2 Control de inventario y cédulas (empresa manufacturera de malta)
Propuesta comercial
1.1 Definición mercadológica.
 Dado el crecimiento de la empresa manufacturera de malta y su estrecha
relación comercial con una la trasnacional más importante en el mercado de
mexicano en exportación de cerveza, surge la necesidad de tener
sistematizados todos las fuentes de información para que interactúen, en un
futuro inmediato, con el sistema central SAP que regirá la operación en
común de las empresas.
 La situación actual de costear la producción desde su siembra hasta la
entrega de producto terminado se realiza por procesos manuales a través
66
MÉXICO 2015
de hojas de Excel, por lo cual surge la necesidad de tener en un sistema de
información homologado la información.
1.2 Mercado meta.
 A nivel de empresa:
o Sistema de Información de costeo que en un futuro interactúen
directamente con los sistemas centrales de administración (SAP).
o Administrar la información en una fuente homologada, donde el
conocimiento y reglas de negocio se encuentran en el sistema de
información (proceso) y no en las personas que ejecutan.
o Sistema que funcione de manera independiente al sistema ADAM,
DIBLON u cualquier otro, con el objetivo de ser implementado en
otras empresas relacionadas con la operación de la empresa
manufacturera de malta.
 A nivel de usuario final:
o Interfaz de información programable dependiente de procesos y no
de personas.
1.3 Necesidades a satisfacer.
 Sistema modernizado
 Sistema con estándar de programación
 Sistema robusto
 Sistema front – end
67
MÉXICO 2015
 Sistema parametrizable
 Sistema con reportes parametrizables
 Optimizar recursos y tiempos
 Dar un mejor servicio al cliente interno y externo
1.4 Variables de competitividad.
 Proporcionamos el conocimiento y experiencia en el desarrollo de sistemas
similares.
 Utilizar un modelo internacional de desarrollo de proyectos como es CMMI,
que permite llevar y entregar proyectos en tiempo y forma.
 Detectar de manera preventiva (y no correctiva) los desvíos que pudieran
poner en riesgo al proyecto.
1.5 Características funcionales.
 Sistema amigable con el empleado
 Información en línea.
 Obtener información a partir de cargas de archivos estándares de
inventarios y costos.
 Sistema centralizado
 Utilizar la información histórica del sistema para generar en el futuro toma
de decisiones.
68
MÉXICO 2015
1.6 Hábitos de consumo.
 La ejecución de costeo es realizado por las personas y no por procesos.
 Existe cultura de propiedad de la información.
1.7 Vida funcional.
 El ciclo de vida del sistema de información debe de ser permanente, ya que
se comenta que esos cálculos no han variado desde hace 30 años.
Adicionalmente se diseñaría un sistema parametrizable de tal forma que
sea flexible.
1.8 Restricciones.
 Si es un desarrollo WEB, el cliente tendría que invertir en equipos e
infraestructura para manejar cliente – servidor .NET. Además si se requiere
que los costos sean mínimos, el personal de sistemas necesitará conocer la
administración por ejemplo de Linux u otro software que sea utilizado bajo
está filosofía.
1.9 Productos en competencia.
 No identificados
1.10 Aspectos tecnológicos.
 Propuesta AS400:
o Programación RPG y Base de Datos DB2
69
MÉXICO 2015
o Modulo parametrizable similar a los módulos de ADAM por ejemplo
XP.
o Programador(es) AS400
 Propuesta .NET
o Servidor
o Sistema operativo windows server (licencia)
o Desarrollo sobre visual studio
o Herramienta de desarrollo Infragistics. Funcionalidad de manejo
sobre gris, por ejemplo: sumatoria de columnas, ordenamientos,
entre otros.
o Programado sobre stored procedure en AS400
o Programador AS400 y Programador .NET
o Modulo parametrizable similar a los módulos de ADAM por ejemplo
XP.
o Sistema WEB
1.11 Ángulos de diferenciación.
 Desarrollo de sistemas de información bajo las mejores prácticas
implementadas por un modelo mundial en calidad de software que es el
CMMI.
70
MÉXICO 2015
1.12 Productos Complementarios.
 N/A.
1.13 Propuesta del Valor
 CMMI como modelo de calidad y desarrollo de software (Véase Figura 1 –
21)
 Ampliar la solución de negocio, de acuerdo a las experiencias de nuestros
colaboradores
 Construcción de sistemas parametrizables
 El equipo de trabajo se vuelve un socio de negocios de nuestros clientes,
para ver por el fin común.
Proyecto
Workflows y Tareas Primera Opción Alternativa Criterio adoptado
Nuevo
Workflows de Ejecución
Workflow de Requerimientos
Capturar Información Si Minuta Correo electrónico Si se realizará
Definir Alcance del Sistema Si Especificación de Requerimientos Cualquiera aprobada por el Si se realizará
de Software gerente de proyectos
Realizar Modelo de Casos de Uso Si Casos de Uso de Negocio Cualquiera aprobada por el Si se realizará
gerente de proyectos
Realizar Descripción de Interfaz del Si Diseños de Interfaz Cualquiera aprobada por el Si se realizará
Usuario gerente de proyectos
Definir Requerimientos No Funcionales Si Especificación de Requerimientos Cualquiera aprobada por el Si se realizará
de Software y Hoja de Casos de gerente de proyectos
Uso
Actualizar Matriz de Rastreabilidad Si Matriz de Rastreabilidad Cualquiera aprobada por el Si se realizará
Realizar Revisión por pares de Si Reporte Revisión por Pares Correo electrónico Si se realizará
Requerimientos
Realizar Revisión de ERS y Casos de Uso Si Plantillas de Auditorias y Si se realizará
Revisiones, Plantilla de
71
MÉXICO 2015
Seguimiento de Desviaciones de
Auditorias
Realizar Aceptación de ERS y Casos de Si Minuta Correo electrónico Si se realizará
Uso
Validar y Aceptar ERS y Casos de Uso Si Minuta Correo electrónico Si se realizará
Workflow de Análisis y Diseño
Realizar Análisis Arquitectónico No Hoja de Análisis Cualquiera aprobada por el No se realizará
Definir Arquitectura No Hoja de Análisis Cualquiera aprobada por el No se realizará
Elaborar Diseño de la Solución Si Hoja de Diseño Cualquiera aprobada por el Si se realizará
Diseñar Interfaces de Hardware, Software No Hoja de Diseño Cualquiera aprobada por el No se realizará
y Comunicación gerente de proyectos
Realizar Revisión por pares de No Reporte Revisión por Pares Cualquiera aprobada por el No se realizará
Arquitectura gerente de proyectos
Workflow de Codificación
Determinar Estrategia y ambiente de No Documento de secuencia de integración No se realizará
integración
Realizar Codificación y Pruebas unitarias Si Reporte de Pruebas Unitarias Si se realizará
Integrar Componentes No Checklist de integración Correo con los componentes No se realizará
integrados
Realizar Pruebas de Integración Si Reporte de Pruebas de Integración Si se realizará
Realizar Revisión por Pares de No Reporte Revisión por Pares No se realizará
Codificación
Realizar Manual de Usuario Si Plantilla de manual de usuario Cualquiera aprobada por el Si se realizará
Realizar Manual de Administración Si Plantilla de manual de Readme, Notas de release Si se realizará
(Memoria Técnica) administración (Memoria técnica)
Realizar Revisión por Pares de Manuales Si Reporte Revisión por Pares Si se realizará
Generar la Versión del Sistema Si Si se realizará
Workflow de Prueba
Diseñar Casos de Prueba Si Plantilla de Casos de Prueba Si se realizará
Realizar Revisión por Pares de Casos de Si Reporte Revisión por Pares Si se realizará
Prueba
Preparar Entorno de Prueba Si Si se realizará
Realizar Prueba de Sistema Si Reporte de Ejecución de Pruebas REDMINE Si se realizará
Realizar Revisión de los Resultados de Si Minuta Correo electrónico, items de Si se realizará
Prueba acción
Realizar Validación del sistema Si Reporte de pruebas de validación. Minuta Si se realizará
Workflow de Despliegue
Preparar Versión del Sistema Entregable Si Si se realizará
72
MÉXICO 2015
Instalar y Configurar Versión del Sistema Si Si se realizará
Realizar Capacitación al Usuario Si Si se realizará
Workflows de Soporte
Workflow de Planificación
Realizar Plan de Desarrollo de Software Si Plantilla de Plan de Desarrollo de Software Si se realizará
Realizar Estimaciones Si Formato de Estimaciones Si se realizará
Identificar y Evaluar Riesgos Si Checklist y Formato de Riesgos Cualquiera aprobada por el Si se realizará
Realizar Plan de Iteración No Plan de Iteración No se realizará
Realizar Plan de Calidad Si Plantilla de plan de calidad Si se realizará
Realizar Plan de Administración de la Si Plantilla de Plan de Administración de la Configuración y Datos Si se realizará
Configuración y Datos
Realizar Plan de Pruebas Si Plantilla de Plan de Pruebas Si se realizará
Realizar Plan de Medición Si Plantilla de Plan de Medición Si se realizará
Realizar Plan de Comunicación Si Plantilla de Plan de Comunicación Si se realizará
Realizar Revisión por Pares de Planes Si Reporte Revisión por Pares Si se realizará
Aceptar Compromisos Si Minuta Correo electrónico Si se realizará
Aprobar Planes Si Minuta Correo electrónico Si se realizará
Workflow de Monitoreo y Control
Recolectar Datos de Mediciones Si Formato de Métricas del Proyecto Si se realizará
Analizar Mediciones y Crear Reporte del Si Formato de Métricas del Proyecto Si se realizará
Proyecto
Revisar Progreso Si Minuta, Items de Acción REDMINE Si se realizará
Preparar el Cierre de la Iteración/Proyecto Si Plantillas de Cierre de Proyecto Si se realizará
Realizar la Evaluación del Cierre de Si Minuta Correo electrónico Si se realizará
Iteración/Proyecto
Workflow de Administración de la Configuración
Definir Repositorios del Proyecto Si Plan de Administración de la Configuración y Datos Si se realizará
Generar los Reportes De Estado de Si Reporte de Estado de la Reporte de herramientas de Si se realizará
Configuración Configuración y Datos admin. de la configuración
Generar Linea Base Si Reporte de Linea Base Si se realizará
Desarrollar Auditoria de Configuración Si Plantillas de Auditorias y REDMINE Si se realizará
Física Revisiones, Plantilla de
Auditorias
Desarrollar las Auditorias de Configuración Si Plantillas de Auditorias y REDMINE Si se realizará
Funcional Revisiones, Plantilla de
Auditorias
Revisar Cambios a Linea Base Si Minuta Correo electrónico Si se realizará
Workflow de Aseguramiento de Calidad
Realizar Auditorías y Revisiones Si Plantillas de Auditorias y REDMINE Si se realizará
73
MÉXICO 2015
Auditorias
Realizar Revisión de Aseguramiento de Si Plantillas de Auditorias y REDMINE Si se realizará
Calidad de la ERS Revisiones, Plantilla de
Auditorias
Calidad de los Planes Revisiones, Plantilla de
Auditorias
Realizar Revisión de Aseguramiento de No Plantillas de Auditorias y REDMINE No se realizará
Calidad de la Arquitectura Revisiones, Plantilla de
Auditorias
Calidad de Casos de Prueba Revisiones, Plantilla de
Auditorias
Calidad de Versión Revisiones, Plantilla de
Auditorias
Workflow de Analisis y Toma de Decisiones
Definir Criterios, Alternativas y Métodos de No Plantilla de decisiones de Documento de análisis y No se realizará
Evaluación proyecto evaluación de alternativas
Evaluar y Seleccionar Alternativa No Plantilla de decisiones de Correo electrónico No se realizará

proyecto, minuta
Figura 1 – 21 Guía de adaptación control de inventario y cédulas (empresa

manufacturera de malta)
3.5.3 Sistema de automatización de formas de pago por cheques (empresa
de retail de distribución de artículos para oficina)
Propuesta comercial
Con el objeto de dar una mejor idea en el funcionamiento de cada una de las
aplicaciones, a continuación se presenta una descripción general de cada una de
éstas (Véase Figura 1 - 22).
74
MÉXICO 2015
 ANÁLISIS Y DISEÑO
Objetivo. Recabar información y analizarla de manera tal que se tenga un
modelo previo en el cual se basará el desarrollo de las adecuaciones.
Se realizarán actividades orientadas a recabar información concerniente a
cada uno de los puntos anteriormente descritos de manera que se pueda elaborar
un diseño de los mismos el cual se apegue al 100% a los requerimientos del
cliente.
 DESARROLLO
Objetivo. Elaborar los programas necesarios para poder cumplir con los
requerimientos provenientes del diseño.
1. Mantenimiento a parámetros generales/reglas de negocio.
En esta sesión podrán configurarse los parámetros que sirven para evitar
que el código requiera de mantenimiento ante posibles cambios de valores y
eviten programación fija y condicionada. Algunos datos a considerar son:
folios, agrupadores, entre otros.
2. Crear y modificar programas del proceso de forma de pago
“cheque”.
Se modificará el proceso actual de confirmación de pedidos en el sistema
clientes y pedidos de manera que en la forma de pago acepte “cheque” y
realice el proceso completo de validación y confirmación con el proveedor de
cheques.
75
MÉXICO 2015
Los procesos detectados al momento de acuerdo a los requerimientos
especificados por los usuarios y el proveedor son:
 Catálogo de productos del proveedor
 Catálogo de estados del proveedor
 Catálogo de ciudades del proveedor
 Catálogo de bancos de proveedor
 Crear nueva transacción
 Relacionar formas de pago a nueva transacción
 Validar cheque solo transacciones 01800 y COD en modificar pedido
 Proceso de reenvió de datos en caso de no confirmar recepción
 Enviar cancelación al proveedor si se elimina forma de pago
 Agregar tablas satélites para registro de datos de cheque
 Registro de datos de cheques
 Configuración por tiendas
 Integrar los estados del proveedor y el cliente
 Integrar las ciudades del proveedor y el cliente
 Bloquear que se puede eliminar la forma de pago después de 4 horas
de autorizado
 Integrar Productos del proveedor a productos del cliente
76
MÉXICO 2015
 PRUEBAS UNITARIAS
Esta sección tiene como objetivo probar la nueva parametrización y los
programas nuevos de manera individual; con esto, se asegura el funcionamiento
de cada documento y programa.
 PRUEBAS INTEGRALES
Esta sección tiene como objetivo asegurar la funcionalidad de la configuración
de conceptos integradas con las interfaces y modificaciones; además se espera
que el usuario dé el visto bueno sobre la integración con los sistemas existentes
así como su desempeño.
 LIBERACIÓN
En esta actividad se instalará la aplicación en los servidores designados por la
empresa de retail de distribución de artículos para oficina, y se les proporcionará
una explicación acerca de la manera en cómo trabaja el archivo de pantalla a los
encargados de la administración de los servidores y aplicación
Workflows y Tareas Proyecto Nuevo Primera opción Alternativas Criterio adoptado
Definir Alcance del Sistema Si Especificación de Requerimientos de Cualquiera aprobada por el Si se realizará
Software gerente de proyectos
Realizar Modelo de Casos de Uso Si Hoja Casos de Uso Cualquiera aprobada por el Si se realizará
Realizar Descripción de Interfaz del Si Hoja Casos de Uso Cualquiera aprobada por el Si se realizará
Usuario gerente de proyectos
Definir Requerimientos No Funcionales Si Especificación de Requerimientos de Cualquiera aprobada por el Si se realizará
Software y Hoja de Casos de Uso gerente de proyectos
Actualizar Matriz de Rastreabilidad Si Matriz de Rastreabilidad Cualquiera aprobada por el Si se realizará
77
MÉXICO 2015
Realizar Revisión por pares de Si Reporte Revisión por Pares Correo electrónico Si se realizará
Requerimientos
Realizar Revisión de ERS y Casos de Si Plantillas de Auditorias y Revisiones, Si se realizará
Uso Plantilla de Seguimiento de
Desviaciones de Auditorias
Realizar Aceptación de ERS y Casos de Uso Minuta Correo electrónico Si se realizará
Realizar Análisis Arquitectónico Si (opcional) Hoja de Análisis Cualquiera aprobada por el gerente de proyectos
Definir Arquitectura Si Hoja de Análisis Cualquiera aprobada por el gerente de proyectos
Elaborar Diseño de la Solución Si Hoja de Diseño Cualquiera aprobada por el Si se realizará
Diseñar Interfaces de Hardware, Si Hoja de Diseño Cualquiera aprobada por el No se realizará
Software y Comunicación gerente de proyectos
Realizar Revisión por pares de Si Reporte Revisión por Pares Cualquiera aprobada por el gerente de proyectos
Arquitectura
Determinar Estrategia y ambiente de Si Documento de secuencia de integración No se realizará
integración
Realizar Codificación y Pruebas Si Reporte de Pruebas Unitarias Si se realizará
unitarias
Integrar Componentes Si Checklist de integración Correo con los componentes No se realizará
integrados
Realizar Pruebas de Integración Si Reporte de Pruebas de Integración No se realizará
Realizar Revisión por Pares de Si Reporte Revisión por Pares No se realizará
Codificación
Realizar Manual de Usuario Si Plantilla de manual de usuario Cualquiera aprobada por el Si se realizará
Realizar Manual de Administración Si Plantilla de manual de Readme, Notas de release No se realizará
(Memoria Técnica) administración (Memoria técnica)
Realizar Revisión por Pares de Si Reporte Revisión por Pares Si se realizará
Manuales
Workflow de Prueba
Diseñar Casos de Prueba Si Plantilla de Casos de Prueba Si se realizará
Realizar Revisión por Pares de Casos Si Reporte Revisión por Pares Si se realizará
de Prueba
Realizar Prueba de Sistema Si Reporte de Ejecución de Pruebas REDMINE Si se realizará
Realizar Revisión de los Resultados de Si Minuta Correo electrónico, items de Si se realizará
Prueba acción
78
MÉXICO 2015
Realizar Validación del sistema Si Reporte de pruebas de validación. Minuta Si se realizará
Preparar Versión del Sistema Si Si se realizará
Entregable
Instalar y Configurar Versión del Si Si se realizará
Sistema
Realizar Plan de Desarrollo de Software Si Plantilla de Plan de Desarrollo de Software Si se realizará
Identificar y Evaluar Riesgos Si Checklist y Formato de Riesgos Cualquiera aprobada por el Si se realizará
Realizar Plan de Iteración Si (opcional) Plan de Iteración No se realizará
Realizar Plan de Administración de la Si Plantilla de Plan de Administración de la Configuración y Datos Si se realizará
Realizar Plan de Pruebas Si Plantilla de Plan de Pruebas Si se realizará
Realizar Plan de Medición Si Plantilla de Plan de Medición No se realizará
Realizar Plan de Comunicación Si Plantilla de Plan de Comunicación Si se realizará
Realizar Revisión por Pares de Planes Si Reporte Revisión por Pares Si se realizará
Recolectar Datos de Mediciones Si Formato de Métricas del Proyecto Si se realizará
Analizar Mediciones y Crear Reporte del Si Formato de Métricas del Proyecto Si se realizará
Proyecto
Preparar el Cierre de la Si Plantillas de Cierre de Proyecto Si se realizará
Iteración/Proyecto
Realizar la Evaluación del Cierre de Si Minuta Correo electrónico Si se realizará
Iteración/Proyecto
Workflow de Administración de la Configuración
Definir Repositorios del Proyecto Si Plan de Administración de la Configuración y Datos Si se realizará
Generar los Reportes De Estado de Si Reporte de Estado de la Reporte de herramientas de Si se realizará
Configuración Configuración y Datos admin. de la configuración
Desarrollar Auditoria de Configuración Si Plantillas de Auditorias y Revisiones, REDMINE Si se realizará
Física Plantilla de Seguimiento de
Desarrollar las Auditorias de Si Plantillas de Auditorias y Revisiones, REDMINE Si se realizará
Configuración Funcional Plantilla de Seguimiento de
79
MÉXICO 2015
Realizar Auditorías y Revisiones Si Plantillas de Auditorias y Revisiones, REDMINE Si se realizará
Plantilla de Seguimiento de
Realizar Revisión de Aseguramiento de Si Plantillas de Auditorias y Revisiones, REDMINE Si se realizará
Calidad de la ERS Plantilla de Seguimiento de
Calidad de los Planes Plantilla de Seguimiento de
Calidad de la Arquitectura Plantilla de Seguimiento de
Calidad de Casos de Prueba Plantilla de Seguimiento de

Calidad de Versión Plantilla de Seguimiento de
Figura 1 – 22 Guía de adaptación sistema de automatización de formas de

pago por cheques (empresa de retail de distribución de artículos para
oficina)
3.5.4 Control de ventas (empresa de retail de distribución de artículos para
oficina)
Propuesta comercial
Con el objeto de dar una mejor idea en el funcionamiento de cada una de las
aplicaciones, a continuación se presenta una descripción general de cada una de
éstas.
 ANÁLISIS Y DISEÑO
Objetivo. Recabar información y analizarla de manera tal que se tenga un
modelo previo en el cual se basará el desarrollo de las adecuaciones.
80
MÉXICO 2015
Se realizarán actividades orientadas a recabar información concerniente a
cada uno de los puntos anteriormente descritos de manera que se pueda elaborar
un diseño de los mismos el cual se apegue al 100% a los requerimientos del
cliente.
 DESARROLLO
Objetivo. Elaborar los programas necesarios para poder cumplir con los
requerimientos provenientes del diseño.
3. Mantenimiento a parámetros generales/reglas de negocio.
En esta sesión podrán configurarse los parámetros que sirven para evitar que
el código requiera de mantenimiento ante posibles cambios de valores y eviten
programación fija y condicionada. Algunos datos a considerar son: niveles,
jerarquías, dependencias, estructura de ventas, entre otros…
4. Modificar proceso que sube ventas al repositorio.
Se modificará el proceso actual que genera repositorio de ventas y comisiones,
a fin de que complemente las columnas a utilizar en los reportes. Algunas de las
columnas a considerar (aún por evaluar) pueden ser:
 Fecha de alta del cliente
 Es cliente con crédito
 No. Cliente (puntos)
 Entre otros
81
MÉXICO 2015
5. Reporte sumario por tienda.
Se creará una sesión para poder emitir la consulta, reporte y exportación de
datos, acorde a las siguientes columnas (Véase Figura 1 – 23) :
Figura 1 – 23 Reporte sumario por tienda
6. Reporte detallado por tienda-empleado.
datos, acorde a las siguientes columnas (Véase Figura 1 – 24):
Figura 1 – 24 Reporte detallado por tienda-empleado
7. Reporte de ventas 5 niveles.
82
MÉXICO 2015
Figura 1 – 25 Reporte de ventas 5 niveles
8. Reporte de ventas 4 niveles.
Figura 1 – 26 Reporte de ventas 4 niveles
9. Reporte de ventas por cliente.
Figura 1 – 27 Reporte de ventas por cliente
83
MÉXICO 2015
10. Reporte de ventas vendedor-cliente.
Figura 1 – 28 Reporte de ventas vendedor-cliente
 PRUEBAS UNITARIAS
Esta sección tiene como objetivo probar la nueva parametrización y los
programas nuevos de manera individual; con esto, se asegura el
funcionamiento de cada documento y programa.
 PRUEBAS INTEGRALES
Esta sección tiene como objetivo asegurar la funcionalidad de la
configuración de conceptos integradas con las interfaces y modificaciones;
además se espera que el usuario dé el visto bueno sobre la integración con
los sistemas existentes así como su desempeño.
 LIBERACIÓN
En esta actividad se instalará la aplicación en los servidores designados por
la empresa, y se les proporcionará una explicación acerca de la manera en
84
MÉXICO 2015
cómo trabaja el archivo de pantalla a los encargados de la administración de
los servidores y aplicación.
Guía de adaptación control de ventas
De esta experiencia es importante resaltar los siguientes puntos críticos que hacen
el éxito o fracaso de la implementación de una metodología en una organización
(Véase Figura 1 – 29):
 Capacitar al equipo de proyecto en la metodología
 Adquirir el compromiso del equipo de proyecto
 Conocer y controlar los costos del proyecto
 Entender, validar y acordar el alcance del proyecto con el cliente
 Documentar durante cada etapa los artefactos necesarios para administrar
el proyecto
 Implementar el proceso de administración de cambios
 Monitorear y controlar cada semana al equipo de trabajo, los avances, al
cliente, la ejecución de procesos y las auditorías del mismo.
Tipos de Proyecto Guías de adaptación

Criterio
Workflows y Tareas Proyecto de Desarrollo
adoptado
Nuevos Primera opción Alternativas
Definir Alcance del Sistema Si Especificación de Cualquiera aprobada por el
Requerimientos de gerente de proyectos
Software Si se realizará
Realizar Modelo de Casos de Uso Si Hoja Casos de Uso Cualquiera aprobada por el
Si se realizará
85
MÉXICO 2015
Realizar Descripción de Interfaz del Usuario Si Hoja Casos de Uso Cualquiera aprobada por el
gerente de proyectos Si se realizará
Definir Requerimientos No Funcionales Si Especificación de Cualquiera aprobada por el
Requerimientos de gerente de proyectos
Software y Hoja de Casos
de Uso Si se realizará
Si Matriz de Rastreabilidad Cualquiera aprobada por el
Actualizar Matriz de Rastreabilidad gerente de proyectos Si se realizará
Realizar Revisión por pares de Requerimientos Si Reporte Revisión por Correo electrónico
Pares Si se realizará
Si Plantillas de Auditorias y
Seguimiento de
Desviaciones de
Realizar Revisión de ERS y Casos de Uso Auditorias Si se realizará
Realizar Aceptación de ERS y Casos de Uso Minuta Correo electrónico Si se realizará
Realizar Análisis Arquitectónico Si (opcional) Hoja de Análisis Cualquiera aprobada por el
Definir Arquitectura Si Hoja de Análisis Cualquiera aprobada por el
Si Hoja de Diseño Cualquiera aprobada por el
Elaborar Diseño de la Solución gerente de proyectos Si se realizará
Diseñar Interfaces de Hardware, Software y Si Hoja de Diseño Cualquiera aprobada por el No se realizará
Comunicación gerente de proyectos
Realizar Revisión por pares de Arquitectura Si Reporte Revisión por Cualquiera aprobada por el
Pares gerente de proyectos
Si Documento de secuencia No se realizará
Determinar Estrategia y ambiente de integración de integración
Si Reporte de Pruebas Si se realizará
Realizar Codificación y Pruebas unitarias Unitarias
Si Checklist de integración Correo con los componentes No se realizará
Integrar Componentes integrados
Si Reporte de Pruebas de No se realizará
Realizar Pruebas de Integración Integración
Si Reporte Revisión por No se realizará
Realizar Revisión por Pares de Codificación Pares
Si Plantilla de manual de Cualquiera aprobada por el Si se realizará
Realizar Manual de Usuario usuario gerente de proyectos
86
MÉXICO 2015
Si Plantilla de manual de Readme, Notas de release No se realizará
Realizar Manual de Administración (Memoria administración (Memoria
Técnica) técnica)
Si Reporte Revisión por Si se realizará
Realizar Revisión por Pares de Manuales Pares
Workflow de Prueba
Si Plantilla de Casos de Si se realizará
Diseñar Casos de Prueba Prueba
Si Reporte Revisión por Si se realizará
Realizar Revisión por Pares de Casos de Prueba Pares
Si Reporte de Ejecución de REDMINE Si se realizará
Realizar Prueba de Sistema Pruebas
Si Minuta Correo electrónico, items de Si se realizará
Realizar Revisión de los Resultados de Prueba acción
Si Reporte de pruebas de Si se realizará
Realizar Validación del sistema validación. Minuta
Preparar Versión del Sistema Entregable Si Si se realizará
Instalar y Configurar Versión del Sistema Si Si se realizará
Realizar Plan de Desarrollo de Software Si Plantilla de Plan de Si se realizará
Desarrollo de Software
Identificar y Evaluar Riesgos Si Checklist y Formato de Cualquiera aprobada por el Si se realizará
Riesgos gerente de proyectos
Realizar Plan de Iteración Si (opcional) Plan de Iteración No se realizará
Realizar Plan de Administración de la Si Plantilla de Plan de Si se realizará
Configuración y Datos Administración de la
Realizar Plan de Pruebas Si Plantilla de Plan de Si se realizará
Pruebas
Realizar Plan de Medición Si Plantilla de Plan de No se realizará
Medición
Realizar Plan de Comunicación Si Plantilla de Plan de Si se realizará
Comunicación
Realizar Revisión por Pares de Planes Si Reporte Revisión por Si se realizará
Pares
87
MÉXICO 2015
Formato de Métricas del Si se realizará
Recolectar Datos de Mediciones Si Proyecto
Formato de Métricas del Si se realizará
Analizar Mediciones y Crear Reporte del Proyecto Si Proyecto
Plantillas de Cierre de Si se realizará
Preparar el Cierre de la Iteración/Proyecto Si Proyecto
Realizar la Evaluación del Cierre de Minuta Correo electrónico Si se realizará
Iteración/Proyecto Si
Workflow de Administración de la
Configuración
Plan de Administración de Si se realizará
Definir Repositorios del Proyecto Si la Configuración y Datos
Reporte de Estado de la Reporte de herramientas de Si se realizará
Generar los Reportes De Estado de Configuración Si Configuración y Datos admin. de la configuración
Plantillas de Auditorias y REDMINE Si se realizará
Seguimiento de
Desviaciones de
Desarrollar Auditoria de Configuración Física Si Auditorias
Seguimiento de
Desarrollar las Auditorias de Configuración Desviaciones de
Funcional Si Auditorias
Seguimiento de
Desviaciones de
Realizar Auditorías y Revisiones Si Auditorias
Seguimiento de
Realizar Revisión de Aseguramiento de Calidad de Desviaciones de
la ERS Si Auditorias
Realizar Revisión de Aseguramiento de Calidad de Revisiones, Plantilla de
los Planes Si Seguimiento de
88
MÉXICO 2015
Desviaciones de
Auditorias
Seguimiento de
Realizar Revisión de Aseguramiento de Calidad de Desviaciones de
la Arquitectura Si Auditorias

Seguimiento de
Desviaciones de
Realizar Revisión de Aseguramiento de Calidad de Auditorias
Casos de Prueba Si
Seguimiento de
Desviaciones de
Realizar Revisión de Aseguramiento de Calidad de Auditorias
Versión Si
Figura 1 – 29 Reporte de ventas vendedor-cliente
3.5.5 Adaptación del modelo de calidad CMMI en el proyecto de
“Modernización Integral” para una institución gubernamental
En este tipo de proyecto donde el cliente tiene una metodología, el proceso
de adaptabilidad es importante, permitiendo optimizar tiempo, recursos y
esfuerzos; para ser aprovechados en actividades de ejecución, pruebas o
liberación de entregables hacia el cliente.
Uno de los errores frecuentes es determinar como administrador de proyectos la
generación de doble documentación porque, así lo solicita el cliente y además se
tiene que cumplir con los procesos internos de la empresa que desarrolla.
89
MÉXICO 2015
Además de que este esfuerzo no es facturable, implica dar mantenimiento a
documentos que durante el paso del proyecto sufren infinidad de cambios y
realizar la misma actividad para dos o más archivos causa gastos innecesarios.
A continuación se presenta la guía de adaptación donde se identifican amarillo los
documentos que son compartidos por las metodologías (Véase Figura 1 – 30).
Artefacto Responsable Estatus Observaciones
FASE 01. ANALISIS
DST-2.01QFD Especificación de requerimientos de soluctec LP Cerrado
FASE 02. DISEÑO
DST-8.03QFDx Catálogo de servicios FSW Cerrado
CasosPruebaSistema QA Cerrado
CST-7.03QFD Escenarios de prueba_integración FSW Cerrado DAT-1.05QFDx Escenarios de prueba_integración.
DAT-1.05QFDx Diseño de la Base de Datos BD Cerrado
DST-8.04QFDx Acuerdo de nivel de servicios LP Cerrado
DAT-1.02QFDx Modelo conceptual de datos BD Cerrado
DAT-1.01QFDx Matriz CRUD LP Cerrado
DAT-1.03QFDx Modelo físico de datos BD Cerrado
DAT-1.04QFDx Modelo lógico de datos BD Cerrado
FASE 03.1. DESARROLLO
Módulo de Administración de Certificados
a. Sub-módulo de parámetros de Certificados
DST-11.01QFD Manual técnico de la solución tecnológica FSW Cerrado
DST-11.02QFD Instructivo de operación de la solución FSW/QA

Cerrado
tecnológica
*FRM_EvidenciaPruebasUnitarias 03 00 00 FSW
Cerrado
* FRM_Evidencia Pruebas Sistema 03 00 00 QA

Cerrado
* FRM_ CtrlErroresC 03 00 01 QA NO APLICA, SE UTILIZO HERRAMIENTA MANTIS PARA

Cerrado
CONTROL
* Migración de datos Migración de datos (únicamente para LP NO APLICA

Cerrado
operar Catálogos básicos ya existentes en SENASICA
FASE 04.1 INTEGRACIÓN
CST-7.04QFDx Evidencia de pruebas QA Cerrado
90
MÉXICO 2015
CST-7.05QFDx Carta de terminación de pruebas LP Cerrado
DST-12.01QFD Reporte de integración FSW Cerrado
DST-13.01QFD Registro de cambios LP Cerrado SIN CAMBIOS
FASE 03.2 DESARROLLO
Módulo de Administración de Certificados
a. Sub-módulo de parámetros de Certificados
b. Sub-módulo de Administración de Solicitudes
Registro de solicitud
Verificación documental
Inspección o verificación documental
Dictaminación
DST-11.01QFD Manual técnico de la solución tecnológica FSW Cerrado
DST-11.02QFD Instructivo de operación de la solución FSW

Cerrado
tecnológica
*FRM_EvidenciaPruebasUnitarias 03 00 00 FSW
Cerrado
* FRM_Evidencia Pruebas Sistema 03 00 00 FSW

Cerrado
* FRM_ CtrlErroresC 03 00 01 QA Cerrado
* Migración de datos Migración de datos (únicamente para LP

Cerrado
operar Catálogos básicos ya existentes en SENASICA
FASE 04.2 INTEGRACIÓN
CST-7.04QFDx Evidencia de pruebas QA Cerrado
CST-7.05QFDx Carta de terminación de pruebas QA Cerrado
DST-12.01QFD Reporte de integración LP Cerrado
DST-13.01QFD Registro de cambios LP Cerrado
MAAGTIC
Planeación
APTI-7.01QFD Informes de rendimiento del programa de LP

Cerrado
proyecto
APTI-7.03QFD Lista de asuntos y acuerdos (LAA) LP Cerrado
APTI-7.04QFD Actas de aceptación de entregables LP Este documento está contenido en el APTI-0.02QFDx Carta de
Cerrado
Entrega.
CST-1.01QFD Programa de calidad * LP No se entrega porque es un documento común y se entregará hasta

Cerrado
el cierre del proyecto
CST-1.02QFD Documento de ambientes FSW Cerrado NO APLICA
CST-2.01QFD Lista de verificación LP Cerrado NO APLICA
APTI-8.01QFD Acta de cierre * LP No se entrega porque es un documento común y se entregará hasta

Cerrado
91
MÉXICO 2015
APTI-8.02QFD Cuestionario de retroalimentación de la ejecución LP No se entrega porque es un documento común y se entregará hasta
Cerrado
del proyecto * el cierre del proyecto
Análisis
DST-2.01QFD Especificación de requerimientos de soluctec LP Cerrado
DST-3.01QFD Diagrama conceptual de la solución tecnológica FSW Cerrado
FRM_CasosPruebaSistema QA La información del entregable se encuentra contenida en el
Cerrado documento: CasosPruebaSistema. CST-7.02QFD Escenarios de
prueba_aceptación
DST-1.01QFD Modelo de flujo de negocio LP Cerrado
DST-1.03QFD Documento de visión del producto o servicio LP Cerrado
DST-4.01QFD Registro de validación de requerimientos LP Cerrado
DST-6.01QF Matriz de rastreo y trazabilidad LP Cerrado
DST-7.01QFD Modelo de arquitectura de soluciones técnicas FSW Cerrado
DST-7.02QFD Reporte de evaluación de alternativas de solución LP Cerrado
Diseño
CST-7.03QFD Escenarios de prueba_integración FSW Este documento se encuentra dentro de la carpeta

Cerrado
“ENTREGABLES” por lo que solo se entrega una vez.
DST-8.01QFD Documento de diseño FSW Cerrado
DST-9.01QFD Reporte de evaluación de componentes FSW Cerrado
Desarrollo
DST-11.01QFD Manual técnico de la solución tecnológica FSW Este documento se encuentra dentro de la carpeta
Cerrado
DST-11.02QFD Instructivo de operación de la solución FSW Este documento se encuentra dentro de la carpeta
Cerrado
tecnológica “ENTREGABLES” por lo que solo se entrega una vez.
CST-8.01QFD Lecciones aprendidas * LP No se entrega porque es un documento común y se entregará hasta

Cerrado
Integración
DST-12.01QFD Reporte de integración FSW Este documento se encuentra dentro de la carpeta

Cerrado
DST-13.01QFD Registro de cambios Este documento se encuentra dentro de la carpeta

Cerrado
Liberación y entrega
LE-3.01QFD Documento de método de liberación y entrega FSW Cerrado
LE-4.01QFD Programa de liberación y entrega LP Cerrado
LE-6.01QFD Resultado de las pruebas del servicio QA Cerrado
LE-6.02QFD Reporte de entrega LP Cerrado
LE-5.01QFD Paquete de liberación entregado a ambiente FSW

Cerrado
productivo
THO-1.01QFD Programa de transición a la operación y soporte LP Cerrado
92
MÉXICO 2015
THO-1.02QFD Criterios de aceptación del servicio LP Cerrado
THO-3.01QFD Programa de uso de recursos de TIC LP

Cerrado
THO-4.01QFD Informe del rendimiento del programa de LP

transición a la operación y soporte
Cerrado
Figura 1 – 30 Guía de adaptación Modernización Integral entre CMMI y

MAAGTIC
3.5.6 Adaptación del modelo de calidad CMMI en el área de sistemas de una
institución bancaria y de valores y su convivencia con la metodología del
PMI
En este tipo de proyecto donde el cliente tiene una metodología robusta que
sobre pasa su capacidad instalada y tiempos (cuantas veces hemos escuchado:
“… o desarrollo o documento”), el proceso de simplificación es la mejor opción,
permitiendo optimizar tiempo, recursos y esfuerzos; para ser utilizados en
actividades de ejecución o desarrollo principalmente.
Uno de los errores frecuentes es determinar como administrador de proyectos la
generación de una metodología amplia, pero sin considerar el tamaño de la
organización, los factores culturales, las dependencias de recursos, costos y sobre
todos que los marcos de referencia como CMMI, PMI, ITIL, etc. No son una regla
que deba seguirse, sino que “SUGIEREN LAS MEJORES PRÁCTICAS” con una
premisa o supuesto importante: Que la organización donde se implemente realiza
proyectos con duración de más de 12 meses y que se tienen todos los recursos
disponibles para llevarlo a cabo.
93
MÉXICO 2015
A continuación se presenta el cambio de metodología realizado en la Institución
Bancaria y de Valores, donde se concretó de DOS modelos para Administrar
Proyectos (uno para Desarrollo y otra para Infraestructura –cada uno con 20
documentos obligatorios-). A UN SOLO modelo de Gestión clasificando por la
necesidad de atención: Mantenimiento (10 documentos) o Proyecto (15
documentos) (Véase Figuras de la 1 – 31 a la 34) .
Figura 1 – 31 Metodología anterior dividido para el área de desarrollo e

infraestructura con diferentes entregables
94
MÉXICO 2015
Figura 1 – 32 Metodología actual sin dividir los entregables por área de

desarrollo e infraestructura
95
MÉXICO 2015
Id Fecha
RUS ID del RUS
Líder de Proyecto Correo Electrónico
Área Subdirector
Líder de Negocio Área de Negocio
MANTENIMIENTO REGULATORIO ☐
MANTENIMIENTO MANDATORIO ☐
MANTENIMIENTO ☐
MANTENIMIENTO INFRAESTRUCTURA ☐
MANTENIMIENTO INFRA REGULATORIO ☐
Fases del RUS

Inicio ☐ Planeación ☐ Ejecución ☐ Cierre ☐
Entregables en sitio de proyectos revisados de acuerdo a etapa actual del RUS

Fase Entregable Requerido Encontrado Comentarios
Inicio RUS ☐ ☐
RFP o Contrato ☐ ☐
Documento de respaldo de ☐ ☐
Regulación
Planeación Casos de Uso o Análisis ☐ ☐
de Funcionalidad
Cronograma Final ☐ ☐
Ejecución Matrices de Prueba ☐ ☐
Plan de Implementación a ☐ ☐
Producción
Control de Cambio a ☐ ☐
Producción
Cierre Acta de Cierre de ☐ ☐
Requerimiento
Monitoreo y Minutas ☐ ☐
Control Presentaciones de ☐ ☐
seguimiento
Correo de notificación al ☐ ☐
usuario
Figura 1 – 33 Lista de verificación para auditoría de requerimiento
96
MÉXICO 2015
Id Fecha
Proyecto ID del Proyecto
Líder de Proyecto Correo Electrónico
Área Subdirector
Líder de Negocio Área de Negocio
PROYECTO INFRAESTRUCTURA ☐
PROYECTO REGULATORIO ☐
PROYECTO MANDATORIO ☐
PROYECTO ☐
Fases del proyecto

Inicio ☐ Planeación ☐ Ejecución ☐ Cierre ☐
Entregables en sitio de proyectos revisados de acuerdo a etapa actual del proyecto

Fase Entregable Requerido Encontrado Comentarios
Inicio RUS ☐ ☐
RFP o Contrato ☐ ☐
Carta de Constitución de ☐ ☐
Proyecto
Kick Off ☐ ☐
Documentación de ☐ ☐
Respaldo de Regulación
Planeación Definición de Procesos de ☐ ☐
Negocio
Casos de Uso / Análisis de ☐ ☐
Funcionalidad
Estrategia de Pruebas ☐ ☐
Prototipo ☐ ☐
Documento Técnico ☐ ☐
Cronograma Final ☐ ☐
Ejecución Matrices de Pruebas ☐ ☐
Plan de Implementación a ☐ ☐
Producción
Control de Cambio a ☐ ☐
Producción
Cierre Carta de Cierre de ☐ ☐
Proyecto
Monitoreo y Minutas ☐ ☐
Control Presentaciones de ☐ ☐
seguimiento
Correo de notificación al ☐ ☐
usuario
Figura 1 – 34 Lista de verificación para auditoría de proyecto
97
MÉXICO 2015
CONCLUSIONES
Actualmente la sociedad es cada vez más dependiente de la tecnología,
esto como consecuencia de las necesidades que vamos obteniendo en nuestra
vida cotidiana, debido a estos factores las empresas dedicadas al desarrollo de
software tienen la tarea de crear sistemas cada vez más complejos obligando a
que las organizaciones modifiquen su forma de trabajo para poder ofrecer un
servicio y/o producto de calidad.
Existen varios estándares y modelos dedicados a la industria del desarrollo
de software y a las TI, algunos miden la calidad del producto y otros procuran que
el producto cumpla con los requerimientos para la calidad, pero en especial CMMI
buscan que las empresas y su personal sean lo suficientemente maduras al
desarrollar software y/o servicio.
Alcanzar la madurez implica que el personal de la organización sea capaz
de ser criticados y criticar con gratitud y así aceptar las responsabilidades de sus
propios actos sin excusas.
Saber el ¿por qué?, ¿qué es?, ¿para qué?, ¿cómo funciona CMMI? hoy en
día es vital no sólo para la industria de software sino también para las personas
que aún no concluyen con su preparación en el mundo de TI; esto es debido a la
necesidad de desarrollar software para actividades de la vida cotidiana y con
calidad desde la concepción de un proyecto.
98
MÉXICO 2015
Es importante conocer los diferentes modelos y estándares de calidad para
saber la exigencia que piden las organizaciones y la demanda de mejoras
prácticas que existe en la industria para llegar preparado a este ámbito.
El objetivo de este trabajo es mostrar que una metodología (para nuestro
caso de estudio CMMI, pero puede ser cualquiera que la organización donde
trabajes utilice) es ADAPTABLE a cada empresa y las necesidades del proyecto.
Considerar siempre que ningún documento está de más o de menos, sin embargo
es importante preguntarse si para el proyecto, y en ese momento, le da valor o no
y las implicaciones que tiene hacia el cronograma o plan de trabajo y presupuesto.
Siempre hay que tener presente al adaptar una metodología dos factores
importantes:
1. Los factores culturales de la empresa
a. No podemos llegar a imponer prácticas que no son parte de la
empresa, para ello existe en toda empresa un área que define las
políticas y procedimientos.
b. Recuerda que la resistencia al cambio es algunas organizaciones es
dolorosa, así que es importante que la alta dirección está en el
mismo camino de la mejora continua de lo contrario cualquier
esfuerzo puede llegar a ser poco productivo.
99
MÉXICO 2015
c. Demostrar ética profesional y respecto que permita lograr la empatía
dentro de los equipos de trabajo, principalmente cuando hablamos
de personas de diferentes nacionalidades, usos y costumbres.
d. Siempre debes investigar y determinar a todos los involucrados de la
organización y nunca menos preciar a nadie por rango, puesto u otro
factor que pudieras considerar menos importante, ya que puede ser
una parte esencial para el éxito de la implementación de la
metodología.
2. Los activos de procesos de la organización
a. Antes de querer implementar procesos, políticas, procedimiento o
formatos; investiga si la organización cuenta con algo desarrollado e
implementado
b. Investiga con los dueños de los activos de procesos de la
organización que debe de mejorarse, ya que ellos en el día a día
conocen si funciona o no.
c. Evita frases parecidas como “… Lo que hacíamos en otra
organización o empresa…”, ya que cada una tiene objetivos de
negocio diferente aun siendo del mismo giro, respetando su cultura
organizacional.
d. Presenta siempre más de una opción para el manejo de activos de la
organización, como lo hemos venido mencionando a lo largo del
100
MÉXICO 2015
trabajo, siempre existe una “guía de adaptación” para cada proyecto
según su naturaleza.
Finalmente podemos decir que el objetivo NO es presentar un trabajo más
sobre la teoría de modelo de CMMI o mostrar artefactos sugeridos ya que existe
para ello una bibliografía extensa; sino que un marco de referencia de mejores
prácticas (cualquiera que este sea) es adaptable a todo tipo de organización y
proyectos. Nunca debemos de ser estrictos o restrictivos, ya que la labor como
líder de proyecto o administradores de proyectos es facilitar el trabajo de los
equipos y siempre enfocar los esfuerzos en los objetivos que se hayan
comprometido, ni más ni menos. Las metodologías por si solas no son una
garantía del éxito de los proyectos, pero proveen guías importante para
conducirnos con reglas que permiten siempre tener puntos de control y
seguimiento que hacen corregir en el momento adecuado desviaciones o
situaciones que pueden poner en riesgo un proyecto.
101
MÉXICO 2015
GLOSARIO
El glosario son términos que constan de un sustantivo y uno o más restrictivas.
(Hay algunas excepciones a esta regla que cuenta para los términos de una sola
palabra.) El glosario tiene como objetivo que todos los usuarios de este
documento pueden entender el mismo concepto. El término "servicio" se define
como un tipo de producto, muchos de los términos en el glosario contienen tanto la
palabra "producto" y la palabra "servicio" para enfatizar que CMMI se aplica tanto
a los productos y servicios.
Acción correctiva Actos o hechos utilizados para remediar una

situación o eliminar un error.
Activos de la organización Una biblioteca de información utilizada para
almacenar y hacer activos de los procesos
disponibles que son de utilidad para aquellos que
están definiendo, implementación y gestión de
los procesos de la organización. Esta biblioteca
contiene activos de los procesos que incluyen la
documentación de procesos relacionados tales
como las políticas, procesos definidos, listas de
control, las lecciones aprendidas documentos,
plantillas, normas, procedimientos, planes y
materiales de capacitación.
Adquisición El proceso de obtención de productos o servicios
a través de acuerdos con proveedores.
Análisis de riesgos La evaluación, clasificación y priorización de los
riesgos.
Área de proceso Un grupo de prácticas relacionadas en un área
que, cuando se implementa en conjunto, cumple
una serie de objetivos que se consideran
importantes para la toma de mejora en esa área.
102
MÉXICO 2015
Arquitectura El conjunto de estructuras necesarias para

razonar acerca de un producto. Estas estructuras
se componen de elementos, las relaciones entre
ellos, y propiedades de ambos.
En un contexto de servicio, la arquitectura se
aplica a menudo el sistema de servicio.
Tenga en cuenta que la funcionalidad es sólo un
aspecto del producto. Atributos de calidad, tales
como la capacidad de respuesta, fiabilidad y
seguridad, también son importantes para razonar
sobre. Estructuras proporcionan los medios para
poner de relieve diferentes porciones de la
arquitectura.
Auditoría El objetivo es examinar un producto de trabajo o
conjunto de productos de trabajo en función de
criterios específicos (por ejemplo, requisitos.
Este es un término que se utiliza de varias
maneras en CMMI, incluyendo auditorías de
configuración y las auditorías de cumplimiento de
procesos.
Auditoría de configuración Una auditoría llevada a cabo para verificar que
un elemento de configuración o una colección de
elementos de configuración que forman una línea
de base se ajusta a una norma o prescripción.
Capability Maturity Model Un modelo que contiene los elementos
esenciales de los procesos eficaces para una o
más áreas de interés y describe una trayectoria
de mejora evolutiva ad hoc, procesos inmaduras
a maduras, procesos disciplinados con una mejor
calidad y eficacia.
Ciclo de vida Una partición de la vida de un producto, servicio,
proyecto, grupo de trabajo, o un conjunto de
actividades de trabajo en fases.
Ciclo de vida del producto El período de tiempo, que consiste en fases, que
comienza cuando un producto o servicio es la
concepción y termina cuando el producto o
servicio ya no está disponible para su uso. Un
ciclo de vida del producto podría constar de las
103
MÉXICO 2015
siguientes fases: (1) Concepción, (2)

Crecimiento, (3) Madurez, (4) Declive y (5)
Retiro.
Cliente El responsable de aceptar el producto o para
autorizar el pago. El cliente es externo al
proyecto o grupo de trabajo (excepto
posiblemente en ciertas estructuras de proyecto
en el que el cliente efectivamente está en el
equipo del proyecto o en el grupo de trabajo),
pero no necesariamente externos a la
organización. El cliente puede ser un mayor nivel
de proyecto o grupo de trabajo. Los clientes son
un subconjunto de las partes
Criterios de aceptación Los criterios que un entregable debe cumplir para
ser aceptados por un usuario, cliente, u otra
entidad autorizada.
Constelación Una colección de componentes de CMMI que se
utilizan para la construcción de modelos,
materiales de capacitación, y los documentos de
evaluación relacionados a un área de interés (por
ejemplo, la adquisición, desarrollo, servicios).
Desarrollo Para crear un sistema, producto o servicio por el
esfuerzo realizado. En algunos contextos, el
desarrollo puede incluir el mantenimiento del
producto desarrollado.
Documento Una colección de datos, independientemente del
medio en el que se registró, que generalmente
tiene permanencia y puede ser leído por los
seres humanos o máquinas. Los documentos
incluyen tanto en papel y documentos
electrónicos.
Ejemplo de producto de trabajo Un componente modelo informativo que
proporciona salidas de muestra de una práctica
específica.
Elemento de configuración Una agregación de productos de trabajo que se
designa para la gestión de configuración y
tratado como una sola entidad en el proceso de
gestión de la configuración.
104
MÉXICO 2015
Entregable Un elemento que debe proporcionarse a un

usuario u otro destinatario designado como se
especifica en un acuerdo. Este artículo puede ser
un documento, elemento de hardware, software
artículo, servicio o cualquier tipo de producto de
trabajo.
Estructura de desglose del trabajo (EDT)
Una disposición de los elementos de trabajo y su
relación entre sí y con el producto o servicio final.
Por sus siglas en inglés: work breakdown
structure (WBS)
Evaluación (Appraisal) Un examen de uno o más procesos por un
equipo capacitado de profesionales que utilizan
un modelo de referencia de la evaluación como
base para determinar, como mínimo, los puntos
fuertes y débiles.
Gerente Una persona que se encarga de la dirección y
control técnico y administrativo a los que realizan
tareas o actividades dentro del área de la gerente
de la responsabilidad. Las funciones tradicionales
de un gerente incluyen la planificación,
organización, dirección y control de trabajo
dentro de un área de responsabilidad.
Gestión de datos Los procesos disciplinados y sistemas que
planifican, adquirir, y proporcionan la
administración de datos empresariales y
técnicos, de conformidad con los requisitos de
datos, a lo largo del ciclo de vida.
Gestión de la configuración Una disciplina aplicando dirección técnica y
administrativa y de vigilancia para (1) identificar y
documentar las características funcionales y
físicas de un elemento de configuración , (2) los
cambios de control a esas características , (3)
Registro y cambio de informe de proceso y
estado de ejecución , y (4) verificar el
cumplimiento de los requisitos especificados.
Gestión de requisitos La gestión de todos los requerimientos recibidos
o generados por el proyecto o grupo de trabajo,
incluidos los requisitos tanto técnicos como no
105
MÉXICO 2015
técnicos , así como los requisitos que gravan el

grupo de proyecto o el trabajo de la organización.
Gestión de riesgos Un proceso analítico organizado utiliza para
identificar lo que podría causar daños o pérdidas
(identificar los riesgos); para evaluar y cuantificar
los riesgos identificados ; y desarrollar y, de ser
necesario, aplicar un enfoque adecuado para
prevenir o controlar las causas de riesgo que
podría ocasionar daños o pérdida significativa.
Gestión del cambio El uso prudente de los medios para efectuar un
cambio, o un cambio propuesto, a un producto o
servicio.
Identificación de riesgos Un enfoque exhaustivo organizado utiliza para
buscar a los riesgos probables o reales en la
consecución de objetivos.
Involucrado relevante Un grupo o individuo que se ve afectado por o es
de alguna manera responsable por el resultado
de un compromiso.
Línea base Un conjunto de especificaciones o productos de
trabajo que ha sido revisado formalmente y
acordó que a partir de entonces sirve como la
base para un mayor desarrollo, y que sólo se
puede cambiar a través de los procedimientos de
control de cambios.
Línea base de configuración La información de configuración designado
formalmente en un momento específico durante
la vida de un componente de producto, además
de los cambios aprobados a partir de esas líneas
de base constituyen la información de
configuración actual.
Métrica Variable a la que se asigna un valor como un
resultado de la medición.
Medición Un conjunto de operaciones para determinar el
valor de una medida.
Nivel de capacidad El logro de la mejora de procesos dentro de un
área de proceso individual. Un nivel de capacidad
se define por los objetivos específicos y
generales apropiadas para un área de proceso.
106
MÉXICO 2015
Nivel de madurez Grado de mejora de procesos a través de un

conjunto predefinido de áreas de proceso en el
que se alcanzan todos los objetivos en el
conjunto.
Objetivos de negocio Objetivos diseñados para asegurar la existencia
continua de una organización y mejorar su
rentabilidad, cuota de mercado y otros factores
que influyen en el éxito de la organización La alta
gerencia desarrollada.
Objetivo específico Un componente modelo requerido que describe
las características únicas que deben estar
presentes para satisfacer el área de proceso.
Objetivo genérico Un componente modelo requerido que describe
las características que deben estar presentes
para institucionalizar procesos que implementan
un área de proceso.
Política Son lineamientos, reglas y sanciones
establecidos por la organización para garantizar
la ejecución de los procesos y procedimientos.
Práctica específica Un componente modelo espera que se considera
importante en la consecución del objetivo
específico asociado.
Práctica genérica Un componente modelo espera que se considera
importante en la consecución del objetivo
genérico asociado. Las prácticas genéricas
asociadas con un objetivo genérico se describen
las actividades que se espera que resulte en el
logro del objetivo genérico y contribuir a la
institucionalización de los procesos asociados a
un área de proceso.
Procesos de la organización Una colección de definiciones de los procesos
que guían las actividades de una organización.
Estas descripciones de procesos cubren los
elementos fundamentales del proceso (y sus
relaciones entre sí, tales como pedidos y las
interfaces) que deben ser incorporados en los
procesos definidos que se implementan en los
proyectos, grupos de trabajo, y el trabajo en toda
la organización. Un proceso estándar permite a
107
MÉXICO 2015
las actividades de desarrollo y mantenimiento

coherentes en toda la organización y es esencial
para la estabilidad y la mejora a largo plazo.
Proceso definido Un proceso gestionado que se adapta desde el
conjunto de procesos estándar de acuerdo con
las guías de adaptación de la organización de la
organización; tiene una descripción del proceso
mantenido; y contribuye experiencias proceso
relacionado con los activos de los procesos
organizacionales.
Proyecto Un conjunto ordenado de actividades y recursos
interrelacionados, entre ellos personas, que
ofrece uno o más productos o servicios a un
cliente o usuario final.
Pruebas de aceptación Las pruebas formales a cabo para permitir a un
usuario, cliente, u otra entidad autorizada para
determinar si acepta un entregable. (Ver también
"pruebas unitarias.")
Pruebas unitarias Pruebas de unidades o grupos de unidades de
hardware o de software individuales.
Requisito asignado Requisito que resulta de la percepción de la
totalidad o parte de un requisito de nivel superior
en un elemento arquitectónico nivel inferior o
componente de diseño.
En términos más generales, los requisitos
pueden ser asignados a otros componentes
físicos o lógicos que incluyen personas,
consumibles, incrementos de entrega, o la
arquitectura como un todo, en función de lo que
mejor permite que el producto o servicio para
alcanzar los requisitos.
Este término tiene un significado especial en la
suite de productos CMMI además de su
significado estándar común inglés.
Representación continua Una estructura Capability Maturity Model en
donde los niveles de capacidad proporcionan un
orden recomendado para acercarse a la mejora
108
MÉXICO 2015
de procesos dentro de cada área de proceso

especificado.
Revisión por pares La revisión de los productos del trabajo realizado
por sus compañeros durante el desarrollo de
productos de trabajo para identificar los defectos
para su eliminación.
Trazabilidad Una asociación entre dos o más entidades
lógicas que es discernible en cualquier dirección
(es decir, hacia y desde una entidad) los
objetivos de negocio.
Validación La confirmación de que el producto o servicio,
como siempre (o como se le proporcionará),
cumplirá con su uso previsto.
Verificación La confirmación de que funcionen productos
reflejan adecuadamente los requisitos
especificados para ellos.
109
MÉXICO 2015
REFERENCIA
CMMI for Development, CMMI Product Team. (2010). CMMI for

Version 1.3 Development, Version 1.3 (CMU/SEI-2010-TR-
033). Retrieved March 10, 2013, from the
Project Management Institute, Inc., website:
http://resources.sei.cmu.edu/library/asset-
view.cfm?AssetID=9661
CMMI for Service, Version CMMI Product Team. (2010). CMMI for
1.3 Services, Version 1.3 (CMU/SEI-2010-TR-034).
Retrieved July 02, 2014, from the Software
Engineering Institute, Carnegie Mellon
University website:
CMMI for Acquisition (CMMI- Phillips, Michael. (2011). CMMI for Acquisition
ACQ) Primer, Version 1.3 (CMMI-ACQ) Primer, Version 1.3 (CMU/SEI-
2011-TR-010). Retrieved January 05, 2015,
from the Software Engineering Institute,
Carnegie Mellon University website:
Standard CMMI Appraisal SCAMPI Upgrade Team. (2011). Standard

Method for Process CMMI Appraisal Method for Process
Improvement (SCAMPI) A, Improvement (SCAMPI) A, Version 1.3: Method
Version 1.3: Method Definition Document. Retrieved December 22,
Definition Document 2014, from the Software Engineering Institute,
Carnegie Mellon University website:
view.cfm?assetid=9703
PROJECT MANAGEMENT PMI Product Team. (2013). PROJECT

BODY OF KNOWLEDGE MANAGEMENT BODY OF KNOWLEDGE
(PMBOK GUIDE) Fifth (PMBOK GUIDE) Fifth Edition. Retrieved
Edition November 12, 2014, from the Software
Engineering Institute, Carnegie Mellon
University website:
http://www.pmi.org/PMBOK-Guide-and-
Standards/pmbok-guide.aspx
110
MÉXICO 2015
ANEXOS
Como apoyo, se adjuntas ejemplos de documentos probados en la
administración de los proyectos y cumplen con los estándares indicados por la
metodología de CMMI, además de tener otras adiciones importantes que aunque
la metodología no lo señala, la experiencia en el desarrollo de software y servicios
se identifican para un mejor control y seguimiento.
111
MÉXICO 2015
ANEXO A. Política para desarrollo de proyectos
La política organizacional, para todos sus proyectos de soluciones a la

medida, establece que se deberá:
1. Proveer recursos y fondos adecuados para la ejecución de las actividades

vinculadas con:
a. La administración de los requerimientos asignados al proyecto.

b. La planificación de proyectos de desarrollo de software, utilizando un
proceso de desarrollo adaptado para el proyecto, tomando como base el
proceso estándar de la organización.
c. El monitoreo y control de los proyectos de software.
d. La administración de configuración.
e. La medición y análisis de la información recopilada.
f. La ejecución de las actividades de Ingeniería de software de pruebas.
g. El aseguramiento de calidad de proceso y productos y la detección
temprana de defectos de los productos de software.
2. Designar:
a. Un líder de proyecto que sea el responsable de:
i. Negociar los compromisos vinculados al proyecto de software
(actividades, recursos, productos de trabajo, etc.)
ii. Coordinar las dependencias entre el grupo de trabajo y otros
grupos afectados al proyecto.
iii. Desarrollar, en etapas tempranas, el plan de proyecto, que será
la base para efectuar el control de las actividades de software y
comunicar el estado de las mismas.
iv. Analizar y documentar los requerimientos asignados al software y
de gestionar el documento de especificación de requerimientos
de software.
112
MÉXICO 2015
b. Un grupo de trabajo (desarrolladores, diseñador de interfaz,

documentador y tester), responsables del desarrollo de los productos de
trabajo del proyecto.
c. Un administrador de configuración que sea responsable de:
i. La coordinación e implementación de la administración de
configuración y datos a través del ciclo de vida del proyecto.
ii. Identificar, controlar y hacer disponibles los productos de trabajo
de los proyectos de desarrollo de software.
iii. Informar a los grupos e Individuos del estado y contenido de la
línea base.
iv. Establecer un sistema de administración de directorios como
repositorio de las líneas base del proyecto.
v. Identificar los productos de trabajo de los proyectos de desarrollo
de software que serán puestos bajo administración de
configuración y datos en coordinación con el líder de proyecto.
d. Un asegurador de calidad que reporte en forma directa al director de
operaciones y conduzca auditorías y revisiones a las actividades y
productos de trabajo relacionados con:
i. Administración de requerimientos
ii. Planificación de los proyectos de software
iii. Monitoreo y control de los proyectos
iv. Ingeniería de software (pruebas)
v. Administración de configuración y datos
vi. Medición y análisis
Para verificar objetivamente que los mismos cumplen con los
estándares, procedimientos y requerimientos.
Reportar los resultados a los grupos e individuos afectados y dar
seguimiento a las no conformidades.
113
MÉXICO 2015
e. Un comité de control de cambios que posea la autoridad para

administrar las líneas base en el contexto de los proyectos y de controlar
los cambios a los productos de trabajo de los proyectos de desarrollo de
software.
f. Un administrador de configuración global que audite periódicamente las
líneas base para verificar que cumplen con la documentación que las
define y que los artefactos contenidos en las mismas y en los
repositorios del proyecto cumplen con los estándares y ubicación
definidos.
g. Reunión de avances con la alta gerencia: líder de proyecto, responsable
de mejora, capital humano, responsable de mediciones, responsable de
aseguramiento de calidad y director de operaciones.
3. Proveer de la capacitación técnica, en el uso de herramientas y
procedimientos aplicables, según su área de responsabilidad, a los
involucrados en el proceso de soluciones a la medida, para que puedan
ejecutar las actividades que les han sido asignadas de acuerdo al plan de
desarrollo de software y a las necesidades específicas del proyecto.
4. Brindar orientación a todos los Grupos e individuos involucrados en el
proyecto respecto a las técnicas, herramientas, estándares y
procedimientos organizacionales vigentes, utilizados por otros grupos e
individuos de la organización, que si bien no son de su incumbencia directa
por no formar parte de las responsabilidades de su trabajo, deben ser
conocidos genéricamente por ellos.
5. Realizar revisiones tanto periódicamente como por hitos concretos, por
parte del director de operaciones como por el comité directivo, de las
actividades y los resultados relacionados con:
a. Administración de requerimientos.
b. Planificación, monitoreo y control del proyecto.
c. Medición y análisis del proyecto.
d. Administración de configuración y datos.
114
MÉXICO 2015
e. Ingeniería de software (pruebas)

f. Compromisos del proyecto hechos a individuos y grupos externos y/o
internos a la organización.
g. El aseguramiento de calidad tanto del proceso como del producto.
6. Definir, recolectar y utilizar mediciones para determinar el estado de las
actividades de:
a. Administración de requerimientos.
b. Planificación, monitoreo y control del proyecto.
c. Administración de configuración y datos.
d. Medición y análisis.
e. Aseguramiento de calidad del proceso y del producto.
f. Detección temprana de defectos.
g. Proceso de desarrollo definido para el proyecto.
7. Obtener consenso de todos los grupos e Individuos afectados, respecto de

sus compromisos y los cambios a estos, vinculados a los proyectos de
soluciones a la medida.
8. Tener un plan de proyecto que defina el ciclo de vida seleccionado y los
procedimientos que serán ejecutados, el cual sea una adaptación del
proceso estándar de desarrollo.
9. Tomar el plan de proyecto como base para realizar el seguimiento del
proyecto e informar sobre el estado del mismo al director de operaciones y
comité directivo.
10. Contar con un repositorio organizacional en el cual se almacenen los
productos de desarrollo de software que podrán ser utilizados en la
planificación y ejecución de proyectos futuros.
11. Realizar revisiones del documento de especificación de requerimientos de
software y del plan de proyecto por todos los involucrados relevantes en el
mismo.
115
MÉXICO 2015
12. Tomar las acciones correctivas cuando el desempeño y los resultados

reales se desvían significativamente y efectuar un seguimiento de las
mismas hasta su cierre.
13. Tener una base de datos del proceso de software organizacional donde se
almacenan datos de medición de los proyectos.
14. Ejecutar las actividades de software teniendo en cuenta que:
a. deben estar en concordancia con el Proceso de desarrollo de software
definido para el proyecto.
b. deben ser definidas, integradas y ejecutadas consistentemente para
producir el resultado esperado.
15. Obtener productos de software que respeten las siguientes
consideraciones:
a. deben tener rastreabilidad con los requerimientos del sistema asociados
al software.
b. deben ser monitoreados y rastreados convenientemente para garantizar
su consistencia.
c. para su construcción y mantenimiento se utilizarán métodos y
herramientas definidos.
d. deben haberse realizado revisiones por pares a los productos de trabajo
identificados.
e. deben realizarse acciones para identificar y eliminar sus eventuales
defectos y posteriormente implementar actividades de mejora y
prevención.
Haberes
 LA EMPRESA proveerá los recursos humanos, tecnológicos y económicos

para la ejecución de las actividades del proyecto.
 LA EMPRESA designará en tiempo y forma un equipo de trabajo para el
proyecto.
116
MÉXICO 2015
 El equipo de trabajo estará integrado mínimo por: gerente de proyecto, líder

de proyecto, desarrollador, tester, asegurador de calidad, administrador
global de la configuración, documentador.
 LA EMPRESA proveerá de la capacitación técnica, en el uso de
herramientas y procedimientos aplicables, según su área de
responsabilidad, a los involucrados en el proceso de soluciones a la
medida.
 LA EMPRESA brindará orientación a todos los grupos e individuos
involucrados en el proyecto respecto a las técnicas, herramientas,
estándares y procedimientos organizacionales vigentes.
Deberes
 El equipo de trabajo se comprometerá a utilizar y ejecutar los

procedimientos y técnicas definidas para soluciones a la medida.
 El equipo de trabajo se compromete a recolectar y reportar las métricas del
proyecto.
 El equipo de trabajo se comprometerá con todas las actividades a realizar
en el proyecto.
 Toda la información del proyecto deberá ser puesta bajo administración de
la configuración y respetando las herramientas, técnicas y formatos
establecidos para ello.
 Monitorear, reportar y controlar los riesgos del proyecto.
 Entregar productos de software apegados a los requerimientos
establecidos.
Sanciones
El NO cumplimiento con la presente política llevará a tomar las siguientes

acciones con el colaborador:
117
MÉXICO 2015
 Nivel 1. Capacitarlo en el área (s) de proceso detectado como debilidad las

veces que sea necesario, siempre y cuando la evidencia sea la falta de
entendimiento por parte del colaborador sobre los procesos.
 Nivel 2. Registrará una amonestación en su expediente laboral cuando se
detecta que por falta de compromiso, el colaborador no ejecuta el proceso
o los procesos, y esto trae consecuencias y riesgos para el proyecto.
 Nivel 3. Cuando el colaborador reincide en la no ejecución de los proceso, y
no es a acusa de una debilidad de entendimiento y como antecedente se
tiene una amonestación en su historial. El colaborador será dado de baja de
la organización de manera inmediata y con las reservas establecidas por
Capital Humano al momento de la contratación.
118
MÉXICO 2015
Anexo B. ERS – Especificación de requerimientos de software
Presentación del producto.
Propósito del sistema.
 Definir la razón de negocios del cliente por la cuál es necesario desarrollar

dicho proyecto. (No son los objetivos)
Objetivo.
 Definir los objetivos generales que integrarán el proyecto.

Alcance.
 Determinar los límites iniciales y finales del proyecto, estos pueden ser
obtenidos desde la hoja de estudio preliminar o justificación del proyecto.
Es esencial este punto, ya que nos permite determinar cambios de alcance.
No Contempla.
 Determinar aquellas actividades, desarrollos u objetivos que no serán

realizados en la estimación del proyecto. Esto nos permite limitar nuestras
responsabilidades y contemplar cambios de alcance.
Restricciones y Supuestos.
 Determinar las actividades que por su naturaleza son obvias para el

desarrollo, y que determinan un supuesto o una restricción. Estás
actividades pueden ser cuantitativas o cualitativas del proyecto.
Descripción general.
Diagrama de contexto.
 El diagrama de contexto es una representación gráfica y expresa a nivel

negocio el flujo esperado para la implementación del proyecto.
Caso de uso.
119
MÉXICO 2015
 Realizar los casos de uso necesarios para el desarrollo del proyecto. Como
sugerencia, se podría hacer referencia a un documento externo que
concentre todos los casos de uso generados.
Listado de actores.
sugerencia, se podría hacer referencia a un documento externo que
Interrelaciones del producto
 Determinar si el proyecto a desarrollar intervendrá con otros sistemas, para

ser considerados en las interfaces y pruebas integrales hacia otros
sistemas.
Descripción detallada del requerimiento.
Requerimientos funcionales.
Descripción detallada de los casos de uso
sugerencia se podría hacer referencia a un documento externo que
 Los requerimientos funcionales son aquellos tangibles a la programación,
por ejemplo: Generar tickets de entrada para el cine.
Prototipo de interfaz de usuario.
sugerencia es hacer referencia a un documento externo que concentre
todos los casos de uso generados.
 El prototipo de interfaz puede ser descrito dentro de los casos de uso.
Reglas y funciones de negocio.
120
MÉXICO 2015
 Determinar todas las reglas y funciones de negocio para el desarrollo del

proyecto. Está sección es importante, ya que con estas reglas se define el
análisis, diseño y procesos del sistema de información.
Requerimientos no funcionales.
 Los requerimientos no funcionales son aquellos no tangibles a la

programación, pero que deben ser documentados dentro de los casos de
uso para ser tomados en cuenta en el proceso. Por ejemplo: No vender
boletos a menores de 18 años para las películas de clasificación B.
Del Producto.
Usabilidad:
 Especificar el tiempo de capacitación requerido para usuarios normales

y expertos para convertirse en productivos en operaciones particulares.
 Especificar tiempos de tareas mensurables para tareas típicas,

alternativamente, requerimientos de usabilidad básica del nuevo sistema
sobre otros sistemas que los usuarios conocen y les agradan.
Confiabilidad:
 Disponibilidad: Especificar el porcentaje de disponibilidad de tiempo,

horas de uso, acceso de mantenimiento, etc.
 Tiempo mínimo entre fallas: Especificado usualmente en horas, pero

también puede especificarse en días, meses y años.
 Tiempo máximo de reparación: ¿Cuánto tiempo está permitido que el

sistema esté fuera de operación después de una falla?
 Certeza: Precisión específica (resolución) y certeza (sobre un estándar)
121
MÉXICO 2015
que es requerida para las salidas del sistema.
 Errores (bugs) máximos: Usualmente expresados en términos de

BUGS/KLOC (miles de líneas de código) o bugs por puntos de función.
Performance:
 Tiempo de respuesta para una transacción (promedio, máximo).
 Transacciones por segundo, de principio a fin.
 Capacidad (el número de clientes o transacciones que el sistema puede

acomodar) sin degradar el desempeño esperado.
 Modos de degradación (modo aceptable de operación cuando el sistema

ha sido degradado).
 Utilización de recursos (memoria, disco, comunicaciones)
Facilidad de mantenimiento:
Se indica cualquier requerimiento que mejorará la soportabilidad o

mantenibilidad del sistema que se está construyendo, incluyendo códigos
estándar, convenciones de nombres, librerías de clases, acceso de
mantenimiento y utilidades de mantenimiento.
Documentación:
Describe los requerimientos, si hay, para documentación en línea del

usuario, ayudas del sistema, manuales impresos, etc.
Del ambiente.
Ético: Si existen requerimientos que deben considerarse en el contexto del

producto que si bien no están legislados, responde a factores morales o pautas de
conducta, deberán especificarse o referenciarse aquí.
122
MÉXICO 2015
Legales: Identificar si existen legislaciones nacionales, internacionales,

provinciales, etc. aplicables y vigentes, que el software deba considerar.
Requerimientos de interfaz.
 Define las interfaces que debe soportar la aplicación. Debería contener

adecuada especificidad, protocolos, puertos, direcciones lógicas, etc., de tal
forma que el software pueda ser desarrollado y verificado contra los
estándares de requerimientos.
Interfaces de usuario
 Describe las interfaces de usuario que tendrán que ser implementadas por
el software.
Interfaces de hardware
 Define cualquier interfaz de hardware que deberá ser soportada por el

software, incluyendo estructura lógica, direcciones físicas y comportamiento
esperado.
Interfaces de software
 Describe las interfaces del software con otros componentes del sistema de
software. Estos pueden ser componentes comprados, componentes
reusados de otra aplicación, o componentes que están siendo desarrollados
por subsistemas fuera del alcance de esta Especificación de
Requerimientos de Software pero con los cuales esta aplicación de
software debe interactuar.
Interfaces de comunicación
 Describe las interfaces de comunicación u otros requerimientos de

restricción o dispositivos, tales como redes de área local o dispositivos
seriales remotos.
Especificaciones suplementarias.
123
MÉXICO 2015
Restricciones de diseño
 Esta sección debería indicar cualquier restricción de diseño en el sistema.

Estas restricciones representan decisiones de diseño a las que hay que
adherirse. Ejemplos de esto son: lenguajes de software, requerimientos del
proceso de software, uso prescripto de las herramientas de desarrollo,
restricciones arquitectónicas y de diseño, componentes comprados, y
librerías de clase.
Operaciones
 En esta sección debería especificarse cómo se espera que sea utilizado el

sistema, indique cualquier situación especial a tener en cuenta:
o Operaciones que inician los usuarios.
o Operaciones que se inician automáticamente.
o Operaciones de respaldo y recuperación.

Requerimientos de licencia
 Esta parte del documento debería especificar la necesidad de licencias

sobre productos asociados a la implementación de este producto.
Componentes comprados
 Describe todos los componentes comprados a ser usados por el sistema,

cualquier licencia aplicable o restricción de uso, y cualquier compatibilidad /
interoperabilidad asociada o estándares de interfaz.
Observaciones
 Esta sección permite incorporar cualquier información que se considera de

importancia, que no haya sido especificada con anterioridad.
Criterios de aceptación del producto
124
MÉXICO 2015
 Se refiere a los criterios de aceptación acordados con el cliente para que

éste acepte formalmente el producto.
125
MÉXICO 2015
Anexo C. PDP – Plan de desarrollo del proyecto
Datos generales
Proyecto: <Nombre del proyecto>
Propósito, alcance y objetivos
Objetivo del negocio
[Indique la problemática que se intenta resolver en el contexto del negocio

del cliente.]
Objetivo del proyecto
[Si el plan contempla iteraciones, deberá referenciar a los alcances de

dichos planes de iteración, si no se deberán especificar los objetivos,
características funcionales y no funcionales del proyecto.]
Supuestos y restricciones
[Describir los supuestos sobre los cuales se basa el proceso y las

restricciones impuestas al proyecto como: calendario, presupuesto, recursos,
software a reutilizar, adquisición de software para incorporar, tecnología a emplear
e interfaces con otros productos.]
Entregables del proyecto y objetivos de calidad
[Liste los entregables que se generarán durante el cumplimiento del

proyecto. Para cada entregable, describa sus objetivos de calidad en términos de
requerimientos de salida, de calidad y de aprobación por parte del cliente.
Ejemplo:
Especificación de requerimientos de software
Versión de sistema
126
MÉXICO 2015
Manual de usuario
Manual de configuración y datos
Para cada uno de ellos, los requerimientos de salida están dados por el
seguimiento de los estándares respectivos definidos en el proceso utilizado para el
desarrollo, incluidos en el software tortoise. Los requerimientos de calidad y
aprobación se establecen en que no existan errores que invaliden las tareas de
aseguramiento de calidad.]
Entregable Objetivos de calidad
Especificación de Especificar los requerimientos del proyecto

requerimientos de software
Casos de uso Especificar la funcionalidad programa del proyecto
Manual de administración Proveer al área de sistemas del cliente las indicaciones

necesarias para el control del sistema de información
Manual de usuario Proveer al usuario final una herramienta de consulta

para conocer la funcionalidad del sistema de
información
Manual técnico Proveer todas las especificaciones técnicas de

construcción del sistema de información
Memoria técnica Proveer al área de soporte del cliente una herramienta

para resolver problemas en caso de contingencia
Modelo E/R (base de datos) Especificar el diseño de la base de datos.
127
MÉXICO 2015
Hitos del proyecto
[Estas son las fechas de hitos acordados con el cliente [dd/mm/aaaa],

agregar más si es necesario]
Fecha de aprobación de la propuesta
Fecha esperada inicio proyecto
Fecha esperada fin proyecto
Arranque
[Describir las actividades necesarias para que el proyecto inicie.]
Cierre
[Especificar las condiciones en que el proyecto finalizará o será considerado

como un proyecto nuevo.]
Organización del proyecto
Interfaces externas
[Describir los límites entre el proyecto y las entidades externas. Esto puede
incluir subcontratos y otras entidades que interactúan con el proyecto. Pueden
utilizarse organigramas o diagramas para representar las interfaces externas.
Ejemplo:]
Cliente
Representante del cliente Líder de proyecto Usuarios
128
MÉXICO 2015
Estructura interna
[Describir la estructura interna de la organización del proyecto para incluir

las interfaces entre las unidades del equipo de desarrollo. Adicionalmente, las
interfaces con las entidades que proveen soporte como configuración, calidad,
verificación y validación. Pueden utilizarse graficas u organigramas para
representar las líneas de autoridad, responsabilidad y comunicación en el
proyecto. Ejemplo:]
Líder de proyecto
Líder de proyecto
Asegurador de Administrador
calidad global de la
configuración
Administrador
Diseñador de DesarrolladoresDiseñador
y de Tester
Arquitecto Documentador
interfaz administrador de Interfaz
la configuración
Roles y responsabilidades Arquitecto
ción
[Es importante incluir una tabla con todos los roles y responsabilidades
incluyendo la gente involucrada directamente en el proyecto por parte de otras
empresas sabiendo exactamente los roles que desempeñan y la importancia de su
participación en el proyecto.
Nota: no olvidar incluir los involucrados en aseguramiento de calidad,

administración de configuración y datos, pruebas, comunicación, entre otros.]
Externos
Rol Responsabilidad
129
MÉXICO 2015
Cliente Es responsable de validar el producto. Puede, de ser

necesario, aprobar la especificación de requerimientos del
proyecto, así como los planes de desarrollo de software, de
instalación y de aceptación del producto, y firmar la
aceptación una vez que se concluye el proyecto
Representante del cliente Es todo aquel que pertenezca a un área de trabajo

específico de la organización del cliente, y el cual este
designado por el mismo para realizar validaciones, cambios,
sugerencias y demás acciones que puedan llegar a afectar el
desarrollo del proyecto.
Asegurador de calidad Es el responsable de revisar y auditar los productos de

software y las actividades para verificar que acaten los
estándares y procedimientos aplicables, y proveer los
resultados de esas revisiones y auditorías al Líder de
Proyecto, al Gerente de Producto y otros involucrados.
Ayudará a asegurar que los planes, estándares y
procedimientos que se han definido sean adecuados para las
necesidades del proyecto y a verificar que sean utilizables
para la ejecución de revisiones y auditorías a lo largo del
ciclo de vida del software. Realizará además las auditorias
de configuración y datos funcionales del proyecto.
Comité de control de Son los responsables de evaluar los cambios que afectan al
cambios producto.
Administrador de la Realizar respaldo a repositorios

configuración global
Realizar respaldo a copias locales desde las terminales de
trabajo.
130
MÉXICO 2015
Internos
Rol Responsabilidad
Director de operaciones Es responsable de asignar el equipo para dicho proyecto,

recibirá informes de avance del proyecto.
Gerente de proyecto Es responsable de la definición del proyecto y de la

asignación de recursos al mismo. Da soporte a las tareas de
estimación y definición de las actividades contenidas en los
planes y realiza la revisión y aprobación de los mismos. Es
responsable de recolectar sus métricas y coordinar su
ingreso semanal a las métricas del proyecto.
Líder de proyecto Es responsable de la elaboración y seguimiento del plan de

desarrollo de software, asignación de los recursos y
prioridades. Deberá coordinar todas las actividades
asociadas al desarrollo del proyecto tales como control de
avance, solución de problemas, administración de riesgos,
etc. Es responsable de recolectar las métricas del proyecto
para presentarlas en las reuniones de monitoreo.
Elicita los requerimientos del cliente, tanto funcionales como

no funcionales, y realiza la definición de los mismos en la
especificación de requerimientos de software. La descripción
de los requerimientos funcionales se realiza mediante el
Modelo de Casos de Uso.
131
MÉXICO 2015
Rol Responsabilidad
Desarrollador Define y mantiene el código fuente de uno o varios

componentes, garantizando que cada componente
implementa la funcionalidad correcta. Tiene responsabilidad
por la integridad de uno o más subsistemas de
implementación y de sus contenidos a lo largo del desarrollo.
Es responsable de recolectar sus métricas y coordinar su
Tester Es el encargado de la ejecución puntual de los casos de

prueba. Es encargado también de la elaboración de casos de
prueba del proyecto en base a los casos de uso.
Se encarga de documentar la secuencia de integración así

como realizar las actividades de integración del sistema. Es
el responsable de ejecutar las pruebas de integración y con
ello verificar el acoplamiento con las diversas interfaces del
producto. Es responsable de recolectar sus métricas y
coordinar su ingreso semanal a las métricas del proyecto.
Administrador de la Es responsable de la elaboración del plan de administración

configuración y datos de configuración y datos y de realizar las actividades
asociadas a la administración de configuración definidas en
el plan, además de asegurar que el entorno de configuración
permita la revisión del producto y las actividades de control
de cambio y seguimiento del estado de los ítems de
configuración. Es responsable de recolectar sus métricas y
132
MÉXICO 2015
Rol Responsabilidad
Administrador global de Es el responsable de realizar las auditorias físicas

la configuración relacionadas al proyecto. Es responsable de recolectar sus
métricas y coordinar su ingreso semanal a las métricas del
proyecto.
Arquitecto Se encarga de realizar el análisis arquitectónico y elaborar el

documento de arquitectura. Es responsable de realizar un
desarrollo de alternativas y soluciones orientadas a la
solución del problema, así como la puesta en marcha de la
arquitectura. Es responsable de recolectar sus métricas y
Diseñador de interfaz Encargado de realizar un diseño de interfaces de usuario

que satisfagan las necesidades del cliente y del proyecto
tomando en cuenta requerimientos no funcionales de
accesibilidad. Es responsable de recolectar sus métricas y
Documentador Se encarga de realizar los manuales de usuario y de

administración del sistema. Es responsable de recolectar sus
métricas y coordinar su ingreso semanal a las métricas del
proyecto.
Inspector Es el responsable de encontrar defectos durante las

revisiones por pares de los productos seleccionados del
proyecto. Es responsable de recolectar sus métricas y
133
MÉXICO 2015
Rol Responsabilidad
Asegurador de calidad Es el responsable de revisar y auditar los productos de

software y las actividades para verificar que acaten los
estándares y procedimientos aplicables, y proveer los
resultados de esas revisiones y auditorías al líder de
proyecto, al gerente de producto y otros involucrados.
Ayudará a asegurar que los planes, estándares y
procedimientos que se han definido sean adecuados para las
necesidades del proyecto y a verificar que sean utilizables
para la ejecución de revisiones y auditorías a lo largo del
ciclo de vida del software. Realizará además las auditorias
de configuración y datos funcionales del proyecto. Es
responsable de recolectar sus métricas y coordinar su
134
MÉXICO 2015
Planificación del proyecto
Ciclo de vida
[Identificar el ciclo de vida y las fases e iteraciones a ser utilizadas en el

proyecto. Defina los objetivos, entradas y criterios de éxito de cada fase/ iteración.
Para cada fase/ iteración, referenciar o identifique los procedimientos aplicables,
métodos, herramientas, lineamientos e instructivos de documentos. Ejemplo:
Para este proyecto se decidió utilizar el ciclo de vida <nombre del ciclo de vida>
basado en el documento <nombre del documento> del cual se deriva la
siguiente tabla para identificar los criterios de entrada y salida para cada una de
las fases o iteración definidas para el proyecto.]
135
MÉXICO 2015
Etapa/Fase Criterio de entrada Criterio de salida
Requerimientos Hoja de concepto Requerimientos no funcionales y casos de

uso definidos y validados
Justificación del proyecto
Infraestructura del proyecto definida
Propuesta de proyecto
El equipo de proyecto ha sido identificado
Control de cambios
El equipo de proyecto ha sido capacitado
Pliego de licitación (si
apropiadamente
aplica)
La evaluación inicial de riesgos ha sido
realizada
Los requerimientos iniciales han sido

aceptados por el Cliente
….
136
MÉXICO 2015
Etapa/Fase Criterio de entrada Criterio de salida
Diseño Especificación de Se ha desarrollado y validado un prototipo

requerimientos de de interfaz de usuario
software aprobada por
Se ha desarrollado y validado un diagrama
todos los involucrados
de clases
Se han cumplido todos los
Se ha desarrollado y validado un modelo de
criterios de salida de la
datos (si se usa una base de datos
etapa / fase anterior
relacional para la persistencia de los
objetos)
Se han desarrollado y validado diagramas

de interacción para modelar la lógica de los
casos de uso
Se ha desarrollado y validado un diagrama

de despliegue
….
[Si el ciclo de vida contiene iteraciones mencionar que cada iteración tiene
asociado su plan de iteración EMP-SM-PLN-02 e Iteración.doc.]
Estimaciones
Estimación de tamaño, tiempo y esfuerzo del proyecto
[Referenciar a la plantilla de estimación EMP-SM-PLT-01

PlantillaEstimacion.xls o incluya aquí el tamaño, tiempo y esfuerzo estimado del
137
MÉXICO 2015
proyecto y cualquier cálculo e información de soporte.] Cantidad de horas o

puntos de casos de uso.
Estimación de costos del proyecto
[Referenciar a la plantilla de estimación EMP-SM-PLT-01

PlantillaEstimacion.xls o incluya aquí el costo del proyecto.]
Facilidades y recursos del proyecto
Plan de equipamiento
[Referenciar la plantilla de estimación EMP-SM-PLT-01

PlantillaEstimacion.xls o incluya aquí el costo del proyecto.]
Nota: no olvidar ingresar los recursos del sistema para la prueba del
proyecto.]
Plan de recursos
[Incluye el calendario de asignación por rol y responsabilidad al personal de

la organización]
Rol Nombre Tiempo
Fecha de Inicio Fecha de

término
Líder de proyecto
Desarrollador
Tester
Administrador de la
configuración
138
MÉXICO 2015
Administrador global
de la configuración
Arquitecto
Diseñador de interfaz
Plan de capacitación
Se puede hacer referencia a la base de datos organizacional que contiene

la lista de capacitaciones necesarias por rol definido. Con lo cual se puede
verificar las capacitaciones faltantes por parte de cada uno de los involucrados por
parte de LA EMPRESA
Opciones y desviaciones del proceso
[Especificar el proceso definido para el proyecto, esta especificación se

realiza utilizando el estándar de EMP-SM-FOR-05 ProcesoProyecto.xls.]
Plan de tiempos
[Referenciar al Plan de Trabajo del Proyecto EMP-SM-PLN-04 WBS.mpp.
Nota: No olvidar incluir la programación de actividades de administración de

la configuración y datos, calidad, pruebas, comunicación, entre otros.]
Proceso técnico
Ingeniería y tecnología
[Especifica el ambiente, herramientas, métodos y técnicas relacionadas con

la ingeniería de software y la tecnología necesaria para llevar a cabo el proyecto.
Esto incluye el análisis, diseño, codificación y pruebas del producto o sus
componentes, así como la plataforma o aspectos tecnológicos en los que se
139
MÉXICO 2015
basará la realización del proyecto.] Las herramientas de redmine y tortoise serán

las herramientas de administración de la configuración que usará el equipo de
trabajo.
Ambiente
[Forma de adaptación o rechazo al estándar de ambiente de trabajo

correspondiente]
Métodos, herramientas y técnicas
[Metodologías utilizadas para el levantamiento de requerimientos, control de

cambios, administración de la configuración y datos, pruebas, entre otros, así
como el software y hardware involucrados en el proyecto.]
Las siguientes herramientas podrán emplearse para este proyecto:
[NOTA: El siguiente ejemplo es para la realización de pruebas. Agregue

ítems conforme sea apropiado e indique los que no apliquen en el proyecto. Se
pueden dividir por áreas.]
Herramientas Vendedor/In-house Versión
Documentación
Diseño
Registro de defectos
Reporte de defectos
Generación de métricas
140
MÉXICO 2015
Herramientas Vendedor/In-house Versión
Automatización (prueba
funcional- prueba de
perfomance)
Infraestructura
[Especifica las necesidades para crear y concluir el ambiente de desarrollo

del proyecto.]
Planes para actividades de soporte
Plan de administración de configuración y datos
[Haga referencia aquí al Plan de administración de configuración y datos de

software EMP-SM-PLN-07 AdministracionConfiguracionDatos.doc, al
Procedimiento de Administración de Cambios EMP-SM-PRO-05
AdministracionCambios.doc o describa las actividades relacionadas con la misma.
Toda la documentación resultante del trabajo de desarrollo de software debe ser
guardada en el repositorio oficial de LA EMPRESA (tortoise, redmine, CVS y
source safe) o estar referenciada]
Plan de calidad
[Haga referencia al Plan de calidad EMP-SM-PLN-10

AseguramientoCalidad.doc, o describa las actividades relacionadas a garantizar la
calidad, en el contexto del proyecto.]
141
MÉXICO 2015
Plan de administración de riesgos
[Haga referencia al plan de administración de riesgos EMP-SM-PLN-06

Riesgos.xls o la herramienta redmine (sección riesgos), o describa cualquier
riesgo asociado con el proyecto y el tratamiento que se dará a los mismos.]
Plan de pruebas del proyecto
[Haga referencia aquí, si aplica, al plan de prueba del proyecto EMP-SM-

PLN-03 Pruebas.doc, o describa las actividades de prueba que se realizarán en el
contexto del proyecto.]
Plan de mediciones
[Haga referencia aquí, al plan de medición EMP-SM-PLN-08

MedicionOrganizacional.doc, o describa las actividades de medición y análisis que
se realizarán en el contexto del proyecto EMP-SM-PLN-09 MedicionProyecto.doc.]
Plan de comunicación
[Haga referencia aquí, al plan de comunicación EMP-SM-PLN-05

Comunicación.doc, o describa las actividades de comunicación que se realizarán
en el contexto del proyecto.]
Planes adicionales
Plan de dependencias
[Describa cualquier dependencia identificada que afecte al desarrollo y

término exitoso del proyecto e identifique las actividades para eliminar o disminuir
dichas dependencias así como el responsable de llevarlas a cabo. Se deben
considerar tanto las actividades internas como externas.]
142
MÉXICO 2015
Dependencia Actividad Responsable Fecha
[Nota: No olvidar incluir las dependencias para realizar actividades de

calidad, pruebas, administración de la configuración y datos.]
Monitoreo y control de proyecto
 Especificar el tipo y frecuencia de producción de los reportes del

proyecto.
 Especificar la frecuencia y asistencia de las reuniones del equipo de
proyecto.
 Especificar la frecuencia de las reuniones de aceptación de fase/ etapa.
Describir el método usado para registrar y controlar las acciones

preventivas o correctivas del proyecto o hacer referencia al procedimiento de
monitoreo y control de proyectos EMP-SM-PRO-07 MonitoreoControl.doc.
Ejemplo:
Para el seguimiento y control del proyecto se utilizarán los reportes publicados en

la herramienta tortoise, se elabora un formato de control de estado interno del
proyecto que se presentara semanalmente en las reuniones con la gerencia
evaluando costo, duración, esfuerzo, tamaño, avance.
Se realiza una reunión semanal con el equipo para controlar la duración,

esfuerzo, tamaño, avance del proyecto, donde quedara en una minuta el resultado
de la misma.
Se presentara semanalmente el avance del proyecto con el cliente.
Se realizará una revisión quincenal con el gerente de proyecto para

controlar a duración, esfuerzo, tamaño, avance del proyecto.
143
MÉXICO 2015
Las actividades de seguimiento y control del proyecto están alineados con

lo establecido por el procedimiento de monitoreo y control de proyectos para el
proceso de desarrollo utilizado.
Las versiones revisadas de todos los planes del proyecto deberán estar
alineadas con sus respectivos estándares y procedimientos que los rigen y hayan
sido aprobados en las revisiones correspondientes. Al cierre de fase/ proyecto se
realizará el post-mortem del proyecto con los miembros del equipo para evaluar el
proyecto. ]
144
MÉXICO 2015
Anexo D. Guía de adaptación

Iteración
Tipos de
Adaptación para Guías de adaptación Número
Proyecto
<Nro.>
Criterio Criterio de
Workflows y Tareas
Proyecto de adoptado Completitud
Proyecto <Nombre
Desarrollo definido
del Proyecto> Primera opción Alternativas
Nuevos para la
Tarea
Capturar Información Si Minuta Correo electrónico
Cualquiera
Especificación de
aprobada por el
Definir Alcance del Sistema Si Requerimientos
gerente de
de Software
proyectos
Cualquiera
Hoja Casos de aprobada por el

Realizar Modelo de Casos de Uso Si
Uso gerente de
proyectos
Cualquiera
Hoja Casos de aprobada por el

Realizar Descripción de Interfaz del Usuario Si
Uso gerente de
proyectos
Especificación de
Cualquiera
Requerimientos
aprobada por el
Definir Requerimientos No Funcionales Si de Software y
gerente de
Hoja de Casos de
proyectos
Uso
Cualquiera
Matriz de aprobada por el

Actualizar Matriz de Rastreabilidad Si
Rastreabilidad gerente de
proyectos
Reporte Revisión
Realizar Revisión por pares de Requerimientos Si Correo electrónico
por Pares
Plantillas de
Auditorias y
Revisiones,
Realizar Revisión de ERS y Casos de Uso Si Plantilla de
Seguimiento de
Desviaciones de
Auditorias
145
MÉXICO 2015
Realizar Aceptación de ERS y Casos de Uso Minuta Correo electrónico
Validar y Aceptar ERS y Casos de Uso Si Minuta Correo electrónico
Cualquiera
aprobada por el
Realizar Análisis Arquitectónico Si (opcional) Hoja de Análisis
gerente de
proyectos
Cualquiera
aprobada por el
Definir Arquitectura Si Hoja de Análisis
gerente de
proyectos
Cualquiera
aprobada por el
Elaborar Diseño de la Solución Si Hoja de Diseño
gerente de
proyectos
Cualquiera
Diseñar Interfaces de Hardware, Software y aprobada por el

Si Hoja de Diseño
Comunicación gerente de
proyectos
Cualquiera
Reporte Revisión aprobada por el

Realizar Revisión por pares de Arquitectura Si
por Pares gerente de
proyectos
Documento de
Determinar Estrategia y ambiente de integración Si secuencia de
integración
Reporte de
Realizar Codificación y Pruebas unitarias Si
Pruebas Unitarias
Correo con los

Checklist de
Integrar Componentes Si componentes
integración
integrados
Reporte de
Realizar Pruebas de Integración Si Pruebas de
Integración
Reporte Revisión
Realizar Revisión por Pares de Codificación Si
por Pares
Cualquiera
Plantilla de aprobada por el

Realizar Manual de Usuario Si
manual de usuario gerente de
proyectos
Realizar Manual de Administración (Memoria Plantilla de Readme, Notas de

Si
Técnica) manual de release
146
MÉXICO 2015
administración
(Memoria técnica)
Reporte Revisión
Realizar Revisión por Pares de Manuales Si
por Pares
Generar la Versión del Sistema Si
Workflow de Prueba
Plantilla de Casos
Diseñar Casos de Prueba Si
de Prueba
Reporte Revisión
Realizar Revisión por Pares de Casos de Prueba Si
por Pares
Preparar Entorno de Prueba Si
Reporte de
Realizar Prueba de Sistema Si Ejecución de REDMINE
Pruebas
Correo electrónico,
Realizar Revisión de los Resultados de Prueba Si Minuta
items de acción
Reporte de
Realizar Validación del sistema Si pruebas de
validación. Minuta
Preparar Versión del Sistema Entregable Si
Instalar y Configurar Versión del Sistema Si
Realizar Capacitación al Usuario Si
Plantilla de Plan
Realizar Plan de Desarrollo de Software Si de Desarrollo de
Software
Formato de
Realizar Estimaciones Si
Estimaciones
Cualquiera
Checklist y
aprobada por el
Identificar y Evaluar Riesgos Si Formato de
gerente de
Riesgos
proyectos
Realizar Plan de Iteración Si (opcional) Plan de Iteración
Plantilla de plan
Realizar Plan de Calidad Si
de calidad
Plantilla de Plan
de Administración
Realizar Plan de Administración de la
Si de la
Configuración y
Datos
Realizar Plan de Pruebas Si Plantilla de Plan
147
MÉXICO 2015
de Pruebas
Plantilla de Plan
Realizar Plan de Medición Si
de Medición
Plantilla de Matriz
Realizar Plan de Comunicación Si
de Comunicación
Reporte Revisión
Realizar Revisión por Pares de Planes Si
por Pares
Aceptar Compromisos Si Minuta Correo electrónico
Aprobar Planes Si Minuta Correo electrónico
Formato de
Recolectar Datos de Mediciones Si Métricas del
Proyecto
Formato de
Analizar Mediciones y Crear Reporte del Proyecto Si Métricas del
Proyecto
Minuta, Items de
Revisar Progreso Si REDMINE
Acción
Plantillas de
Preparar el Cierre de la Iteración/Proyecto Si Cierre de
Proyecto
Realizar la Evaluación del Cierre de

Si Minuta Correo electrónico
Iteración/Proyecto
Workflow de Administración de la
Configuración
Plan de
Administración de
Definir Repositorios del Proyecto Si
la Configuración y
Datos
Reporte de Reporte de
Estado de la herramientas de
Generar los Reportes De Estado de Configuración Si
Configuración y admin. de la
Datos configuración
Reporte de Línea
Generar Línea Base Si
Base
Plantillas de
Auditorias y
Revisiones,
Desarrollar Auditoria de Configuración Física Si Plantilla de REDMINE
Seguimiento de
Desviaciones de
Auditorias
148
MÉXICO 2015
Plantillas de
Auditorias y
Revisiones,
Desarrollar las Auditorias de Configuración
Si Plantilla de REDMINE
Funcional
Seguimiento de
Desviaciones de
Auditorias
Revisar Cambios a Línea Base Si Minuta Correo electrónico
Plantillas de
Auditorias y
Revisiones,
Realizar Auditorías y Revisiones Si Plantilla de REDMINE
Seguimiento de
Desviaciones de
Auditorias
Plantillas de
Auditorias y
Revisiones,
Realizar Revisión de Aseguramiento de Calidad
de la ERS
Seguimiento de
Desviaciones de
Auditorias
Plantillas de
Auditorias y
Revisiones,
de los Planes
Seguimiento de
Desviaciones de
Auditorias
Plantillas de
Auditorias y
Revisiones,
de la Arquitectura
Seguimiento de
Desviaciones de
Auditorias
Plantillas de
Auditorias y
Revisiones,
de Casos de Prueba
Seguimiento de
Desviaciones de
Auditorias
149
MÉXICO 2015
Plantillas de
Auditorias y
Revisiones,
de Versión
Seguimiento de
Desviaciones de
Auditorias
150
MÉXICO 2015
Anexo E. Línea base
Datos de la línea base
1. Identificación de la línea base
[En este campo escriba la etiqueta que identifica a la línea base. La versión de
la línea base se identificará con el acrónimo definido en el glosario organizacional
de LA EMPRESA más el identificador de la versión (X.X)]
1.1. Fechas
[En este campo ingrese la fecha en la que se genera la línea base.]
1.2. Ubicación
[Servidor de archivos, herramienta de gestión de configuración donde se almacena

la Línea Base.]
1.3. Momento de creación de la línea base
[Momento o circunstancia en la que se conforma la línea base (Ejemplo, fin de

workflow de requerimientos, cierre de etapa, cierre de fase, etc.).]
1.4. Identificación de los componentes que la integran
[Nombre de los componentes y versión que forman parte de esta línea base y
por quién ha sido aprobado (Ejemplo: especificación de requerimientos de
software Versión 1.10 aprobado asegurados de calidad).]
Nombre del componente Número de Aprobado por:

versión
151
MÉXICO 2015
1.5. Descripción de cambios
[Incluir una descripción clara del cambio realizado. Si existiera un

requerimiento de cambio, incluir su número y el nombre del solicitante.]
Cambio (descripción) Referencia (número Solicitante

único de cambio)
1.6. Problemas, requerimientos o temas pendientes de revisar
[Incluir un número correlativo que identifique cada problema a tratar, una

descripción u observación sobre el mismo, y el nombre del responsable de su
tratamiento.]
Identificador o múmero. Observaciones Responsable

(problemas, requerimientos o
temas)
152
MÉXICO 2015
1.7. Archivos y productos de software utilizados para la conformación de

la línea base
[Nombre de los componentes y versión necesarios para la conformación de la

línea base y su localización (Ejemplo: rational rose enterprise edition, repositorio
software).
Nombre del componente Número de versión Localización
153
MÉXICO 2015
Anexo F. Reporte de avance semanal con el cliente

PROYECTO: Nombre del Proyecto
I. PLANEACIÓN Y AVANCES AL de del 20XX
Resumen del Plan
1. Periodo Anterior 2. Periodo Actual
DD de MMM al DD de MMM de 2008 DD de MMM al DD de MMM de 2008
IMAGEN DEL PLAN DE TRABAJO AL DIA DEL REPORTE
Avance Real Z% Avance Real Z%
Avance Planeado Y % Avance Planeado Y %
Desviación X% Desviación X%
II. ACTIVIDADES REALIZADAS
1. Listas las Actividades realizadas en la semana con la mayor claridad y precisión, para que sean entendibles para el usuario como el líder de
proyecto del cliente.
III.INCIDENCIAS PRESENTADAS Y ACCIONES A REALIZAR
Incidencias Presentadas Acciones a Realizar
1. Indicar las incidencias presentadas en la semana, cualquiera que 1. Indicar cuál(es) son las acciones que se llevaron o se
está allá sido. llevaran a cabo para mitigar la incidencia.
IV. ACTIVIDADES PRÓXIMA SEMANA
1. Indicar las actividades realizar la próxima semana, se debe ser claro y preciso en cada punto. Esto debe de reportarse en el siguiente
reporte de estado con el cliente, cual es el estatus de cada actividad.
V. RIESGOS DETECTADOS
1. Indicar los riesgos detectados. Es importante acompañar en caso de haber riesgos con el documento EMP-DM-PLN-06
PlandeRiesgos.xls
____________________________________ ____________________________________
Nombre Líder de Proyecto Cliente Nombre Líder de Proyecto
Líder de Proyecto Cliente Líder de Proyecto
Vo.Bo. Vo.Bo.
154
MÉXICO 2015
Anexo G. Ejemplo de métricas organizacionales

Nombre de la Métrica Descripción
Porcentaje de Desviación del Es la diferencia del esfuerzo planeado a la fecha menos el esfuerzo real a la fecha con respecto al esfuerzo planeado a la
Esfuerzo por Workflow (PDE) fecha.
Unidad de Medida Porcentaje
Mediciones Base Horas planeadas a la fecha por workflow.
Horas reales a la fecha por workflow.
Origen de los Datos Gantt del Proyecto
Responsable de Recolección Líder de Proyecto
Cálculo PDEW = (HPFW – HRFW) / HPFW
Mecanismo de Recolección Las horas son obtenidas con lo reportado por el líder de proyecto en el Gantt del Proyecto
Mecanismo de Almacenamiento El líder de proyecto almacena está información en el EMP-SM-FOR-10 MetricasProyecto.xls
El responsable de mediciones almacena en el EMP-SM-FOR-09 MetricasOrganizacionales.xls
Mecanismo de Reporte Líder de Proyecto reporta por medio de la presentación de proyectos en las Juntas de Avances.
Responsable de mediciones reporta por medio de la presentación de las métricas organizacionales.
Frecuencia del Reporte Líder de proyecto reporta cada 2 semanas en la Junta de Avances.
Responsable de mediciones reporta cada semana al enviar la presentación de las métricas organizacionales.
Umbral Color Rango Estatus

Menor o igual a 0% Normal
Mayor a 0% y menor o igual a 10 % Riesgo
Mayor a 10 % Problema
Porcentaje de Desviación del Es la diferencia del porcentaje de avance planeado a la fecha con respecto al porcentaje de avance real a la fecha.
Avance por Workflow (PDAW)
Mediciones Base Porcentaje de avance planeado a la fecha por workflow.
Porcentaje de avance real a la fecha por workflow.
155
MÉXICO 2015
Cálculo PDAW = (PAPFW – PARFW)
Mecanismo de Recolección Los porcentajes son obtenidas con lo reportado por el líder de proyecto en el Gantt del Proyecto

Porcentaje de Retrabajo por Es el esfuerzo de retrabajo del período analizado con respecto al esfuerzo planeado a la fecha.
Workflow (PRW)
Mediciones Base Horas de retrabajo del período analizado por workflow.
Horas planeadas a la fecha por workflow.
Cálculo PRW = ERPW / EPFW
Mecanismo de Recolección Las horas son obtenidas con lo reportado por el líder de proyecto en el Gantt del Proyecto

156
MÉXICO 2015
Anexo H. Lista de verificación de auditoría al proyecto
Condiciones
Verificación No Observaciones
Si No
Aplica
Administración de Requerimientos
¿Se identificó el tipo de requerimiento que originó el
1
proyecto?
¿Se cumplieron todas las actividades de aprobación
2
de la solicitud?
¿Se adjuntó la documentación correspondiente en
3
función del tipo de requerimiento?
¿Existe un Documento de Especificación de
4
Requerimientos?
¿Hay rastreabilidad con las Minutas e información de
5
captura?
¿Se cumplieron todas las actividades de revisión
6
vinculadas a la ERS?
¿El documento de ERS ha sido revisado por el grupo
7
de ingeniería de software?
8 ¿Existen reportes de revisión por pares de la ERS?
¿Se han registrado las métricas asociadas a las
9
actividades de Revisión por Pares de la ERS?
¿Se realizaron todas las aprobaciones definidas para
10
la ERS?
¿Se han identificado unívocamente todos los
11 requerimientos, tanto funcionales como no
funcionales?
12 ¿El documento de ERS está actualizado y completo?
13 ¿Existieron cambios a los requerimientos?
14 ¿Se revisó el impacto del cambio solicitado?
15 ¿El Comité de Control de Cambios aprobó el cambio?
¿El Comité de Control de Cambios aprobó los cambios
16
una vez implementados?
¿Existe evidencia de validación de los requerimientos
17 con el cliente en base a lo definido como estrategia de
validación en la ERS?
Análisis y Diseño
18 ¿Existe el documento de arquitectura? (Si Aplica)
19 ¿Existe un modelo de análisis y diseño?
¿Existe rastreabilidad entre el documento de
20
arquitectura y el documento de ERS? (Si Aplica)
157
MÉXICO 2015
¿Existe rastreabilidad entre los modelos de análisis y

21
diseño y el documento de arquitectura?
¿Están actualizados los modelos con respecto al
22
documento de ERS?
¿La metodología de modelado de análisis y diseño ha
23
sido especificada?
¿El documento de arquitectura ha cumplido con las
24
revisiones correspondientes? (Si Aplica)
¿El modelo de análisis y diseño ha cumplido con las
25
revisiones correspondientes?
¿Existen reportes de revisión por pares de la
26
arquitectura? (Si Aplica)
¿Se han registrado las métricas asociadas a las
27 actividades de revisión por pares de la arquitectura?
(Si Aplica)
28 ¿Existen reportes de revisión por pares del Diseño?
Codificación e Integración
¿Las actividades de implementación se basan en la
29
Especificación de Requerimientos?
30 ¿Se realizaron las Pruebas Unitarias y de Integración?
¿Se documentaron las PruebasUnitarias y de
31
Integración realizadas?
¿Se elaboraron los manuales y el material de soporte
32
para usuarios del Producto?
¿Se integraron los componentes de acuerdo a lo
33
especificado en la secuencia de Integración?
¿Se completó la matriz de rastreabilidad incluyendo las
34 referencias correspondientes a la construcción del
código?
Prueba
35 ¿Se ha definido el alcance del ciclo de prueba?
36 ¿Existe un documento de diseño de casos de prueba?
¿Se diseñaron los casos de prueba en función del
37
alcance definido para el ciclo de prueba?
¿Se diseñaron los casos de prueba desde el
38
documento de ERS aprobado para el proyecto?
¿Existe al menos un caso de prueba para cada
39
requerimiento?
¿Se alcanzó la cobertura de prueba especificada en el
40
Plan de Prueba?
¿Se registraron los resultados de la ejecución de las
41
pruebas?
158
MÉXICO 2015
¿Se informaron los resultados de las pruebas a los

42
involucrados?
¿Se completó la matriz de rastreabilidad incluyendo las
43 referencias correspondientes al diseño de los casos de
prueba?
¿Se tomaron las acciones correctivas derivadas de los
44
resultados de las pruebas?
Planificación de Proyectos
¿Existe al menos una solicitud de requerimientos
45
vinculada al Proyecto?
46 ¿Se realizó la aprobación del inicio del Proyecto?
¿Existe el Plan de Desarrollo de Software para el
47
Proyecto?
¿Se basó la construcción del Plan de Desarrollo de
48
Software en los requerimientos definidos?
49 ¿Se ha seleccionado el ciclo de vida para el Proyecto?
¿Se ha especificado la adaptación realizada al
50
Proceso por el proyecto?
51 ¿Se han identificado los involucrados en el proyecto?
52 ¿Se han identificado los recursos para el proyecto?
¿Se han identificado las necesidades de capacitación
53
del proyecto?
54 ¿Existen los Planes de Soporte?
55 ¿Se han realizado estimaciones?
¿Las estimaciones realizadas se han basado en
56
información histórica?
¿Se completaron las revisiones de pares de las
57
estimaciones y documentado los resultados?
¿Se consultó información histórica de proyectos
58
anteriores?
¿Se han cumplido todas las actividades de revisión y
59
aprobación definidas para los planes?
¿La Dirección de Operaciones ha revisado los
60 compromisos del proyecto hechos a individuos y
grupos externos de la organización?
¿Están actualizados y completos los planes del
61
proyecto?
¿Se realizaron las asignaciones de trabajo en forma
62
consensuada con todos los involucrados?
63 ¿Cada actividad tiene asignado un responsable?
¿Están disponibles los planes para todos los
64
involucrados?
159
MÉXICO 2015
¿Se han asignado recursos para las actividades de

65
soporte?
¿Todos los planes realizados para el proyecto cumplen
66
con los estándares definidos para los mismos?
Monitoreo y Control de Proyectos
¿Se cumplieron las actividades de control del
67
proyecto?
68 ¿Se controlaron los parámetros del proyecto?
69 ¿Se controlaron los compromisos del proyecto?
¿Se controlaron las actividades de administración de
70
datos del proyecto?
¿Se controlaron las actividades de administración de
71
riesgos?
72 ¿Se controló la participación de los involucrados?
73 ¿Se realizaron las reuniones de progreso?
¿Se realizaron los controles frente a los hitos
74
identificados?
75 ¿Se han identificado ítems de acción en el proyecto?
¿Se realizó el seguimiento de los mismos hasta su
76
cierre?
Aseguramiento de Calidad
77 ¿Existe el Plan de QA aprobado para el proyecto?
78 ¿Se ha llevado a cabo la Auditoria de la Propuesta?
¿Se han llevado a cabo y están en estado Aprobado
79 todas las Auditorias de Producto planificadas a la
fecha?
¿Se han llevado a cabo y están en estado Aprobado
80 todas las Auditorias de Proyecto planificadas a la
fecha?
Medición y Análisis
81 ¿Se han especificado los objetivos de medición?
82 ¿Se han especificado las métricas?
83 ¿Se han especificado los procedimientos de análisis?
¿Se han especificado responsables para la recolección
84
de los datos?
¿Se han especificado herramientas para recolección y
85
análisis?
86 ¿Se determinó la frecuencia de las mediciones?
¿Se ha definido el lugar de almacenamiento de los
87
datos?
¿Se ha definido el mecanismo de publicación de
88
resultados?
160
MÉXICO 2015
¿Se han publicado los resultados de las métricas de

89
acuerdo a lo definido?
¿Están correctos los datos del Formato de Métricas de
90 Proyecto en función de la información en y la Plantilla
de Estimaciones?
Administración de la Configuración
¿Se han realizado auditorías de configuración físicas
91 de acuerdo al Plan de Administración de
Configuración?
¿Se han realizado auditorías de configuración
92 funcional de acuerdo al Plan de Administración de
Configuración?
161

Implementación CMMI para El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Implementación CMMI para El Desarrollo de Software

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementación CMMI para El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL AUTÓNOMA DE MEXICO

“IMPLEMENTACIÓN Y ADAPTACIÓN DEL MODELO DE

INFORME DE TRABAJO PROFESIONAL

QUE PARA OBTENER EL TÍTULO DE:

MARCO ANTONIO REYES NAVA

ASESOR: M.C. ALEJANDRO VELÁZQUEZ MENA

CIUDAD UNIVERSITARIA 20/AGOSTO/2015

encuentran con: rectitud, lealtad, honestidad, humildad y ética.

permitido obtener cada logro de mi vida.

ser soberbio en los tiempos de abundancia.

empujaron para que tomara la decisión de titularme, además de inculcarme que la

paciencia era una virtud que tenía que desarrollar en mi vida.

CAPÍTULO 1. ORGANIGRAMA ............................................................................................................ 16

3.1 CONSTELACIONES DE CMMI ................................................................................................................ 23

FIGURA 1 – 24 REPORTE DETALLADO POR TIENDA-EMPLEADO.................................................................. 82

GLOSARIO ............................................................................................................................................ 102

ANEXOS ................................................................................................................................................ 111

ANEXO A. POLÍTICA PARA DESARROLLO DE PROYECTOS ..................................................... 112

ANEXO B. ERS – ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE .......................... 119

ANEXO C. PDP – PLAN DE DESARROLLO DEL PROYECTO ...................................................... 126

ANEXO D. GUÍA DE ADAPTACIÓN ................................................................................................... 145

ANEXO E. LÍNEA BASE ...................................................................................................................... 151

ANEXO F. REPORTE DE AVANCE SEMANAL CON EL CLIENTE ............................................... 154

ANEXO G. EJEMPLO DE MÉTRICAS ORGANIZACIONALES ....................................................... 155

ANEXO H. LISTA DE VERIFICACIÓN DE AUDITORÍA AL PROYECTO ....................................... 157

Hoy en día la tecnología va creciendo con una rapidez impresionante y con

ello la necesidad de desarrollar sistemas cumpliendo el tiempo establecido, con

empresas dedicadas al desarrollo de software se enfrentan a una gran

problemática, la cual es que los proyectos se alarguen en tiempos, se eleven los

costos y disminuya su rentabilidad; por eso la necesidad de adoptar un modelo, el

presupuesto asignado y con la calidad y satisfacción que el cliente requiere.

Uno de los Modelos más utilizados es CMMI (Capability Maturity Model

Integration) -Modelo de Madurez de Capacidades Integradas- el cual fue

desarrollado por el SEI (Software Engineering Institute) – Instituto de Ingeniería de

Software- de la Universidad de Carnegie Mellon, Pittsburgh U.S.A., a partir de

experiencias en proyectos y a petición del departamento de defensa. Es una

herramienta que permite a las organizaciones, especialmente a las empresas

desarrolladoras de software a definir y mejorar sus procesos y con ello planificar,

controlar y monitorear los proyectos.

empresas deben entregar mejores productos y servicios en mucho menos tiempo

pero es raro encontrar a una institución que se dedica 100% al desarrollo e

implantación del mismo; en ocasiones algunas partes se adquieren y son

empresas sean capaces de completar el proceso de desarrollo, mantenimiento e

implantación de los productos. Por ello los procesos y procedimientos ayudan a

controlarlos para alcanzar los objetivos establecidos.

Acerca de los modelos de calidad para desarrollo de software

Con el avance tecnológico es importante conocer la importancia de los

modelos de calidad para desarrollo de software a las organizaciones, instituciones

y, principalmente a los futuros profesionistas, la importancia de utilizar procesos y

organización y del crecimiento profesional de los individuos.

Un modelo de calidad para desarrollo de software es el conjunto de

procesos organizados que puede adoptar una organización de acuerdo a su forma

para desarrollar planes de trabajo, proyecciones, establecer indicadores y mejorar

su operación, además de identifica las fortalezas y debilidades de la organización.

El modelo de calidad para desarrollo de software consiste en un proceso

que muestra y explica el camino de una organización para alcanzar la excelencia.

las organizaciones, pero 3 críticas que son esenciales para el funcionamiento de la

en conjunto sustentan su buen funcionamiento, pero también dependen de los