154 artículo revista de tecnología e innovación marzo 2015 … · 2015-09-16 · 154 artículo...
TRANSCRIPT
154
Artículo Revista de Tecnología e Innovación Marzo 2015 Vol.2 No.2 154-167
Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A. de
C.V
LIMA-Margarita†, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-Martha
Universidad Tecnológica de Tlaxcala, Carr. A el Carmen Xalpatlahuaya S/N C.P. 90500
Recibido14 de Enero,2014;Aceptado17 de Julio, 2014 ___________________________________________________________________________________________________
Resumen
El uso de modelos para elevar la calidad de software en
el sector tecnologías de la información en materia de
innovación y especialización se ha vuelto un requisito
para las pequeñas medianas y grandes empresas en todo
el mundo. En México la Secretaría de Economía a través
de convocatorias en diversos programas ha invitado a
este sector para facilitar el desarrollo y competitividad de
las empresas mexicanas, así como la atracción de
inversiones extranjeras.
El objetivo de este trabajo es describir la experiencia al
implementar el modelo CMMI-DEV2 en la PYME
Miracle Business Network S.A. de C.V., ubicada en el
estado de Tlaxcala, hacer una remembranza de lo que es
CMMI origen, evolución, niveles; haciendo hincapié en
el nivel 2 de desarrollo que fue el utilizado, mostrar
algunos artefactos utilizados, resaltar la importancia del
trabajo en equipo.
Software, PyMES, Desarrollo
Abstract
The use of models to improve the quality of software in
the information technology sector in terms of innovation
and specialization has become a requirement for small,
medium and large enterprises around the world. In
Mexico, the Ministry of Economy, response to calls to
several programs. It has invited to this sector to facilitate
the development and competitiveness of Mexican
companies and the attraction of foreign investments.
The objective of this work is to describe the experience to
implement CMMI-DEV2 model. The SME Miracle
Business Network SA de CV, located in the state of
Tlaxcala, make a remembrance of what is CMMI origin,
evolution, levels; with emphasis on development level 2
that was used to show some artefacts used, highlighting
the importance of teamwork in the project called
acquisition of property and infrastructure of the
microenterprise.
Software, SMES, Development
___________________________________________________________________________________________________
Citación: LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-Martha. Experiencia aplicando el
modelo Integración de modelos de madurez de capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network
S.A. de C.V. Revista de Tecnología e Innovación 2015, 2-2:154-167
___________________________________________________________________________________________________
† Investigador contribuyendo como primer autor.
© ECORFAN-Bolivia www.ecorfan.org/bolivia
155
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Introducción
CMMI es el sucesor de CMM, la meta del
proyecto CMMI fue mejorar la usabilidad de
los modelos de madurez de la ingeniería de
software y de otras disciplinas integrando
diferentes modelos en un solo marco de trabajo.
CMM fue desarrollado desde 1987 hasta
1997. En 1987 Watts Humphrey publicó las
primeras ideas del marco CMM en la revista de
IEEE Software. En 1989 publicó su libro
titulado Managing the software Process. En
1991 se publican el informe técnico donde se
describían las áreas de proceso de la versión 1.0
del CMM (Key Practices of Capability
Maturity Model for Software Engineering
v1.0-CMU-SEI/91.TR-25). En 1993 se
actualiza el modelo y se publica la versión
v1.2 del CMM en el informe técnico(Key
practices of capability Maturity Model for
Software Engineering v1.1-CMU-SEI/93-TR-
25) en el año 2000 surgió la versión 1.0, en el
año 2002 la versión 1.1 en el año 2006 fue
liberada la versión 1.2. Y en el 2010 salió la
versión 1.3. Para construir el CMMI se usaron
como fuentes un primer conjunto de modelos
como fueron el SW-CMM versión 2, EIA/IS
731, IPD-CMM. (Piattini Velthuis Mario,
Garzas Parra Javier, 2010)
CMMI permite aproximarse a la mejora
continua y evaluaciones del software utilizando
2 representaciones, la representación por etapas
y la representación continua cada una de las
representaciones proporciona un camino para
implementar la mejora del proceso de software
con el objetivo de alcanzar los objetivos del
negocio, ambas representaciones proporcionan
el mismo contenido pero organizado de formas
diferentes; se tienen dos representaciones
diferentes por herencia del modelo que utilizan
previamente:
Si se está familiarizado con el CMM
Software entonces se utiliza la representación
por etapas, mientras que si se proviene del
System Engineering Capability Model (SECM)
se utiliza la representación continua.
El modelo CMMI DEV 2 es un conjunto
de productos (suite) que soportan la mejora del
sistema, este conjunto está formado por el
conjunto de modelos CMMI de referencia, los
métodos de evaluación SCAMPI (Standard
CMMI Apraisal Method for procesos
Improvement) y los cursos de entrenamiento.
Los modelos CMMI identifican las áreas
de proceso presentes en un enfoque industrial
del desarrollo de software o sistemas. El
objetivo es ayudar a las organizaciones a
mejorar su capacidad para entregar los
productos a sus clientes, pueden utilizarse para
mejorar toda la organización una división o
una unidad de la organización.
CMMI ayuda a integrar los esfuerzos de
mejora, completando aspectos tradicionalmente
separados como lo son aspectos de gestión y
desarrollo, ayuda a determinar metas y
prioridades en la mejora, al disponer de un
mecanismo de evaluación y modelos de
referencia (Piattini et al. Pg.236)
El modelo CMMI DEV 2 parte de las
políticas de la organización donde se especifica
las directrices para desarrollar software. En este
nivel se pide que los proyectos se gestionen
es decir que el equipo de trabajo siga un plan
definido con actividades de cada una de las
áreas de proceso con responsables, esfuerzo y
duración de todo el proyecto.
156
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
―Implica capacitar a las personas para
que hagan los procesos como se han previsto
en el plan, establecer cómo se van a controlar
los documentos producidos en cada etapa
(Software Engineering Institute [SIE], 2010)
Nivel de capacidad 2: Gestionado
Un proceso de nivel de capacidad 2 se
caracteriza como un proceso gestionado. Un
proceso gestionado es un proceso realizado
(nivel de capacidad 1) que tiene la
infraestructura básica dispuesta para soportar el
proceso. Se planifica y ejecuta de acuerdo a
políticas; emplea personal con habilidades;
tiene los recursos adecuados para producir
resultados controlados; involucra a las partes
interesadas relevantes; se monitoriza, controla y
revisa; y se evalúa la adherencia a su
descripción de proceso.[SEI] (2010). La
disciplina de proceso reflejada por el nivel de
capacidad 2 ayuda a asegurar que las prácticas
existentes se mantienen durante tiempos de
presión.
En la república Mexicana 49 empresas
han alcanzado certificarse y registrarse en este
nivel, esto indica que la mejora en el proceso de
la calidad del software bajo este modelo está
vigente. (Yesenia Nohemí González Meneses,
2014)
Este artículo tiene como objetivo
describir las actividades relevantes de cada
etapa del proceso del modelo CMMI-DEV 2
ver 1.3. Del proyecto sistema Adquisición de
Bienes, servicios e infraestructura,
implementado en la PYME Miracle Business
S.A.de C.V.
Se encuentra estructurado de la siguiente
forma: En primer lugar se describe el giro de la
microempresa, posteriormente se argumenta la
importancia del trabajo en equipo, se hace
referencia a la metodología de software usada,
luego se cita los cinco niveles con los que
cuenta el modelo, posteriormente se describe el
nivel CMMI-DEV2; finalmente se hace una
conclusión.
Giro de PYME Miracle Business S.A. de C.V
Miracle Business S.A. de C.V. Es una empresa
de profesionales dedicados a proporcionar
Consultoría de negocios usando Tecnologías de
Información. MBN inició operaciones en el año
2000 a través de su socio tecnológico
MiracleSoft y convirtiéndose en una razón
social independiente en el 2006.
Miracle Business Network, S.A. de C.V.
fue constituida el 16 de marzo del 2006,
derivada de la experiencia e iniciativa de sus
socios por generar oportunidades de empleo a
nivel nacional. En el año 2008 se identificó la
necesidad de contar con una metodología que
permitiera brindar la calidad requerida a los
proyectos, para mayor satisfacción de los
clientes.
Por este motivo se implanto la Norma
de CalidadNMX-I-059/NYCE-2005
(MoProSoft). En ella se establecen las
actividades y responsabilidades para cada uno
de los procesos que integran a la organización.
Un año después, MBN se sometió a la
evaluación por parte del Organismo Verificador
NYCE, y tras realizar el proceso de
Verificación fue Aprobada y Certificada dentro
del NIVEL 2 de la Norma de Calidad.
157
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Actualmente MBN cuenta con la
distinción ORACLE Gold Partner, y se
encuentra en el recorrido para convertirse en
Partner Especializado en la herramienta
GOLDEN GATE, para replicación de la
información en tiempo real.
Trabajo en equipo
El liderazgo es el proceso de influencia entre
líderes y seguidores para lograr los objetivos
organizacionales por medio del cambio, se
considera crucial para el éxito de cualquier
proyecto, algunos rasgos de los líderes
efectivos son: dominio, gran energía, locus de
control interno, integridad, flexibilidad,
confianza personal, estabilidad, inteligencia, y
sensibilidad hacia los demás. El establecimiento
de roles asignados al personal que contribuye
con una tarea específica en este tipo de
proyectos están conscientes de que deberán
combinar actitudes, habilidades
conocimientos, comunicación y controlar el
estrés generado en momentos de dificultad o
contingencia. Dado el uso creciente de los
equipos para organizar las actividades de
trabajo en innumerables organizaciones, el rol
de los lideres es primordial para facilitar las
conductas productivas entre los miembros de
un equipo, existe la necesidad de un liderazgo
porque los equipos están formados por varias
personalidades, estados mentales motivos y
agendas. Para ser un líder de quipo efectivo se
requiere de un cambio en el estado mental y en
el comportamiento de quienes están
involucrados, con el fin de fomentar el
desarrollo del espíritu de equipo los lideres
deben observar de manera perspicaz lo que
sucede en el equipo hacer contribuciones
cuando sea necesario, alentar un clima de
dialogo, convertir los obstáculos en
oportunidades y considerarse a ellos mismos y
a los demás como parte del conjunto de
conocimiento, habilidades, e ideas del equipo.
(Lussier, 2010)
La mayor parte de software profesional
se trabaja en equipos de proyecto, como regla
general, los grupos del proyecto de ingeniería
de software no deben tener mas de 10
miembros cuando se usan grupos pequeños se
facilita la comunicación.La buena gestion no
puede garantizar el éxito del proyecto, sin
embargo, la mala gestión por lo general da
como resultado una falla del proyecto: el
software puede entregarse tarde, costar mas de
lo estimado originalmente o no cumplir las
expectativas de los clientes. (Somerville, 2011)
Modelo de software en cascada
Consta de las siguientes etapas:
1. Análisis y definición de requisitos. Los
servicios, restricciones y metas del sistema se
definan a partir de las consultas con los
usuarios. Entonces, se definen en detalle y
sirven como especificación de requisitos.
2. Diseño de sistema de software. El
proceso de diseño de sistema divide los
requerimientos en sistemas hardware o
software. Establece una arquitectura completa
del sistema. El diseño de software identifica y
describe las abstracciones fundamentales del
sistema software y sus relaciones.
3. Implementación y prueba de unidades.
Durante esta etapa el diseño se lleva a cabo
como un conjunto de unidades o programas se
integran y prueban como un sistema completo
para asegurar que se cumplan con los
requerimientos de software, posteriormente
estas pruebas se le entregan al cliente.
158
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
4. Funcionamiento y mantenimiento. El
sistema se instala y se pone en funcionamiento.
El mantenimiento implica corregir errores no
descubiertos en las etapas anteriores del ciclo
de vida, mejorar las implementaciones de las
unidades del sistema y resaltar los servicios del
sistema una vez que se descubren nuevos
requerimientos.(Somerville I. 2005)
Modelo de referencia CMMI DEV 2 ver 1.3
Los componentes básicos que soporta este
modelo son las personas, los métodos y
procedimientos y las herramientas y el
equipamiento, como se muestra en la figura 1.
Figura 1
CMMI es un modelo de referencia que
cubre las actividades del desarrollo y del
mantenimiento aplicadas tanto a los productos
como los servicios. Las utilizan organizaciones
de numerosas industrias incluyendo la
aeroespacial; los bancos, la construcción de
ordenadores, el software la defensa, la
fabricación del automóvil, y las
telecomunicaciones utilizan el CMMI para
desarrollo. Los modelos de la constelación de
CMMI para desarrollo contienen prácticas que
cubren la gestión de proyectos, la gestión de
procesos, la ingeniería de sistemas, la ingeniería
del hardware, la ingeniería del software, y otros
procesos utilizados en el desarrollo y
mantenimiento.
Las metas genéricas y las practicas
genéricas (GGs- GPs) son la base para
incorporar los procesos que implementa un área
de proceso.
La planeación del proyecto es un proceso
iterativo que comienza cuando se diseña un
plan de proyecto inicial durante la fase de
arranque del proyecto.
Al comienzo de un proceso de
planeación, hay que valorar las restricciones
que afectan el proyecto, estas son fecha de
entrega, personal disponible, presupuesto global
y herramientas disponibles.
Como se observa en la siguiente figura.
Figura 2
Componentes requeridos, esperados e
informativos
Los componentes requeridos describen lo que
una organización debe realizar para realizar
para satisfacer un área de proceso.
Los componentes esperados describen lo
que una organización puede implementar para
lograr un componente requerido. Los
componentes requeridos guían a los que
implementan mejoras o realizan evaluaciones,
también incluyen practicas específicas y
genéricas.
159
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Los componentes informativos
proporcionan detalles que ayudan a las
organizaciones a comenzar a pensar en cómo
aproximarse a los componentes requeridos y
esperados. Figura 3
Figura 3
Áreas de proceso
Un área de proceso es un grupo de prácticas
relacionada en un área que cuando se
implementan de forma conjunta, satisfacen un
grupo de objetivos considerados importantes
para la mejora de esta área, en este modelo de
referencia hay 22 áreas de proceso. Figura no
4.
Figura 4
Modelo CMMI DEV 2 aplicado al
desarrollo de BSI (Sistema de adquisición de
bienes servicios e infraestructura)
El sistema se desarrolló bajo este modelo en un
periodo de junio a Septiembre del 2014 con 4
módulos y son:
1. Artículos
Cartas de asignación.
Préstamos.
Mantenimiento.
2. Proveedores
3. Servicios
4 .Iniciar sesión
Figura 5
El equipo de trabajo estuvo conformado
por 10 personas que tomaron los siguientes
roles: Director de operaciones, responsable de
administración de Proyecto específico,
responsable de pruebas, responsable de
desarrollo y mantenimiento de software
programador, analista, diseñador, responsable
de manuales, administrador de base de datos,
revisor, usuarios, diseñador de interfaz de
usuario y cliente.
160
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
A continuación se describe brevemente
la responsabilidad asociada a cada rol.
Administrador del Proyecto Específico
(APE)
Toma de decisiones, planeación
estratégica, manejo de personal y desarrollo de
software.
Director de Operaciones (DO)
Mantiene visibilidad sobre la asignación
de recursos y los resultados que se obtienen por
parte de los equipos de trabajo asignados a las
diferentes tareas de agregación de valor.
Participa en la aprobación de procesos,
estándares y uso de herramientas.
Responsable de Procesos y Calidad
(CPC)
Mantiene actualizados los procesos
organizacionales y activos de proceso.
Comunica a los involucrados los cambios y
versiones actualizadas de procesos.
Facilita la capacitación en el uso de procesos,
formatos y herramientas. Verifica el
cumplimiento de las políticas y procesos
organizacionales.
Auditor (AU)
Conocimiento de las diferentes fases del
desarrollo de proyectos y capacidad para la
verificación de la ejecución de los procesos en
cada una de sus etapas.
Medición y Análisis (MA)
Conocer y valorar indicadores asociados
al desarrollo de proyectos que permitan medir
el estado de los mismos.
Administración de la Configuración (AC)
Conocimiento y experiencia en el manejo
de control de versiones y administración de los
repositorios.
Responsable de pruebas (RP)
Conocimiento y experiencia en la
planeación y realización de pruebas de
integración y de sistema.
Responsable de Desarrollo y
Mantenimiento de Software (RDM)
Manejo en la planificación de proyecto
que consiste en desplegar el plan del
proyecto/servicio, involucrar a los actores
apropiadamente, obtener el acuerdo sobre el
plan y mantenerlo, dentro de las funciones más
importantes de esta etapa se encuentran las
siguientes:
1. Estimación de atributos de tareas y productos
de trabajo
2. Determinación de recursos
3. Negociación y validación de compromisos
4. Generación de planes, incluido el
cronograma
5. Identificación y análisis de riesgos a planes
de mitigación
Medición y análisis (MA)
La función principal es apoyar a los
equipos en factores críticos de éxito, mantener
la visibilidad del uso de los recursos, medir y
reportar la eficiencia de los procesos relevantes
a la organización.
161
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Analista (AN)
La función principal es la obtención,
especificación y análisis de los requerimientos.
Programador (PR)
La función principal es la programación,
en algún lenguaje de programación, integración
y pruebas unitarias.
Diseñador (DI)
La función principal es diseño de la
estructura de los componentes de software.
Responsable de Manuales (RM)
Conocimiento de las técnicas de
redacción y experiencia en el desarrollo y
mantenimiento de software.
Administrador de Base de Datos (DBA)
Conocimiento en administración de bases
de datos.
Cliente (CL)
Interpretación del estándar de la
especificación de requerimientos.
Revisor (RE)
Conocimiento en las técnicas de revisión
y experiencia en el desarrollo y mantenimiento
de software.
Diseñador de Interfaz de Usuario (DU)
Conocimiento en diseño de interfaces de
usuario y criterios ergonómicos.
Niveles de madurez
Nivel de madurez 1
En el nivel de madurez 1, los procesos son
generalmente ad-hoc y caóticos. La
organización generalmente no proporciona un
entorno estable para dar soporte a los procesos.
A pesar de este caos, las organizaciones de
nivel de madurez 1, a menudo producen
productos y servicios que funcionan; sin
embargo frecuentemente exceden sus
presupuestos y no cumplen sus calendarios.
Nivel de madurez 2: Gestionado
En este nivel los proyectos de la organización
han asegurado que los procesos se planifican y
realizan de acuerdo a políticas los proyectos
emplean personal con habilidad que dispone
de recursos adecuados para producir resultados
controlados; involucran a las partes interesadas
relevantes; se monitorizan controlan y revisan;
y se evalúan en cuanto a su adherencia a sus
descripciones de proceso.
Nivel de madurez 3: Definido
Los procesos son bien caracterizados y
comprendidos y se describen en estándares,
procedimientos, herramientas y métodos. El
conjunto de procesos estándar de la
organización, que es la base del nivel de
madurez 3, se establece y mejora a lo largo del
tiempo. Estos procesos estándar se usan para
establecer la consistencia en toda la
organización. Los proyectos establecen sus
procesos definidos adaptando el conjunto de
procesos estándar de la organización de acuerdo
a las guías de adaptación de ―conjunto de
procesos estándar de la organización‖
162
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Nivel de madurez 4
En este nivel la organización y los proyectos
establecen objetivos cuantitativos en cuanto al
rendimiento de calidad y del proceso, y los
utilizan como criterios en la gestión de los
procesos.
Los objetivos cuantitativos se basan en
las necesidades del cliente, usuarios finales,
organización e implementación del proceso. El
rendimiento de calidad y del proceso se
comprende en términos estadísticos y se
gestionan durante la vida de los procesos [SEI
2010].
Nivel de madurez 5: En optimización
Una organización mejora continuamente sus
procesos basándose en una comprensión
cuantitativa de las causas comunes de variación
inherentes a los procesos, este nivel se centra
en mejorar continuamente el rendimiento de
proceso mediante mejoras incrementales e
innovadoras de proceso y tecnológicas. Los
objetivos cuantitativos de mejora de procesos
para una organización se establecen, se revisan
continuamente para reflejar el cambio a los
objetivos del negocio y se utilizan como
criterios para gestionar la mejora de proceso.
Los efectos de procesos desplegados se miden y
evalúan frente a los objetivos cuantitativos de
mejora de procesos. Figura 6.
Figura 6
En el nivel 2 hay siete áreas de proceso
1. Gestión de requerimientos
(REQM)
2. Planificación de proyecto(PP)
3. Monitorización y control de
proyecto(PMC)
4. Gestión de acuerdos con
Proveedores (SAM)
5. Gestión Cuantitativa del
proyecto(QPM)
6. Gestión de riesgos (RSKM)
7. Gestión de configuración (CM)
Como se muestra en la siguiente figura.
Figura 7
163
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Actividades relevantes dentro de cada una de
las fases
Planificación de proyecto (PP)
Reside en desarrollar el plan del proyecto o
servicio, involucrar a los actores
apropiadamente, obtener el acuerdo sobre el
plan y mantenerlo, dentro de esta fase se debe
cubrir al menos lo siguiente: Estimación de
atributos de tareas y productos de trabajo,
determinación de recursos, determinación de
recursos, negociación y validación de
compromisos, generación de planes, incluido el
cronograma, identificación y análisis de riesgos
a planes de mitigación como se muestra en la
figura 8.
Se inició con la estimación de tiempo
para realizar la planificación de recursos
materiales y humanos. Tabla 1
Tabla 1
Especificación de Requerimientos
Consiste en seguir las recomendaciones del
formato IEE-830 en cual se usa para la
especificación de requerimientos del cliente,
realizar especificación de requisitos (En sitio
con el cliente).
Verificación de especificación de
requisitos, corrección de especificación de
requisitos, validación/aceptación de la
especificación de requisitos, elaborar matriz de
trazabilidad, realizar baseline de documentos de
requerimientos, entrega de documento de
especificación de requisitos, conocidos también
como artefactos.
Específicamente este documento de manera
breve, se integra de las siguientes partes:
Especificación de requerimientos IEEE
830
1. Introducción. Contexto del
problema a resolver.
2. Propósito: Esta sección define el rol
o propósito de la especificación de
requerimientos en el contexto de la
documentación general.
Alcance: Se refiere a una breve
descripción del alcance de la especificación de
requerimientos; que proyecto (s) están
asociados, y cualquier otra cosa que es afectada
o influenciada por este documento.
Definiciones, Acrónimos y
Abreviaturas: Esta sección define las
definiciones de todos los términos, acrónimos,
y abreviaturas requeridas para interpretar
adecuadamente la especificación de
requerimientos. Esta información puede
proveerse por referencia al glosario de la
organización.
Audiencia: Esta sección identifica la
audiencia específica esperada para la
especificación de requerimientos. Para cada uno
de los participantes se debe indicar los niveles
de participación.
164
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Referencias: Esta sección tiene una
lista completa de todos los documentos
referenciados en cualquier lugar del documento.
Cada documento debe ser identificado por
título, número de reporte (si aplica), fecha de
publicación, archivo que lo contiene y
organización que lo publica. Especificar las
fuentes desde las que se obtuvieron las
referencias. Esta información puede ser provista
por referencia a un apéndice o a otro
documento.
1. Presentación del producto
2. Propósito del sistema
3. Objetivo: En este apartado se debe
indicar de manera general lo que se pretende
lograr con el desarrollo del sistema.
4. Alcance: Se indican en términos
generales las funciones que el sistema deberá
realizar.
No contempla: Este campo sirve para
indicar algunos aspectos funcionales o no
funcionales que se desea destacar, no estarán
incluidos en el producto. El objetivo de esta
sección es dejar expresadas cuestiones que el
producto no cubrirá.
Restricciones y supuestos: El objetivo
de este apartado es indicar cualquier aspecto
que debe ser considerado para el desarrollo, que
puede afectar al cumplimiento de los
requerimientos, que viene dado desde el
ambiente del negocio, o acordado con
anterioridad. Fundamentalmente se debe
destacar cuestiones políticas o legales del
entorno de la organización que pueden afectar
el éxito del proyecto si no se les brinda un
adecuado tratamiento.
5. Descripción general:
Listado de la funcionalidad del
sistema: Esta sección provee una descripción
general de la funcionalidad del sistema. Es
utilizado por la persona interesada en el
comportamiento del sistema, tales como:
clientes, arquitectos, analistas de sistemas,
analistas de proceso de negocio, diseñadores de
interfaz gráfica de usuario, analistas de prueba,
diseñadores de casos de prueba,
administradores, etc. Debe listar para cada caso
de uso:
El número del caso de uso: Es un
número correlativo, que se asigna conforme se
identifican las funciones del sistema y sirve
para facilitar su identificación.
El nombre del caso de uso: Debe ser
una frase representativa de la funcionalidad
que ese caso de uso realiza, el nombre no debe
repetirse.
Prioridad: En este campo se deberá
categorizar al caso de uso con relación a su
importancia en el contexto del sistema que se
está especificando, un criterio de clasificación
podría ser: esencial, deseable, útil.
Esencial: Cuando el caso de uso deba
incluirse en el sistema ya que es indispensable
para lograr el objetivo del desarrollo.
Útil: Cuando el sistema funcione menos
eficientemente si no se agrega este caso de uso,
es decir, que si no se incluye el objetivo del
desarrollo se alcanza, pero no de manera
óptima.
Deseable: Cuando el caso de uso no es
esencial para el sistema pero que lo hace, de
alguna manera más atractivo para los usuarios.
165
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Complejidad: Aquí se permite
categorizar los casos de uso en función de su
dificultad para el desarrollo, los valores
sugeridos son: muy simple, medio, complejo,
muy complejo; y se determinan en función de
dos parámetros básicos, si el caso de uso tiene
interfaces complicadas o cálculos complicados
o combinación de ambos.
En la tabla 3 se muestra una parte de la
descripción general y listado de la
funcionalidad del sistema, en la tabla no. 2 se
muestra el diagrama de casos de uso, Tabla
no.2
Tabla 2
Los siguientes documentos son otros
artefactos utilizados en esta fase.
Diagramas de casos de uso
Listado de actores
Perspectiva del producto
Modelo de dominio
Descripción detallada de requerimientos
Prototipo de interfaces
Reglas y funciones de negocio
Requerimientos no funcionales
Requerimientos de interfaz
Especificaciones suplementarias
La Gestión de proyectos (PP PMC)
Genera los planes de proyecto, lleva a cabo las
actividades de monitoreo y control incluyendo
la comunicación con el cliente, da seguimiento
a las actividades del equipo, gestiona cambios,
revisa que las actividades asociadas al ciclo de
Ingeniería se lleven a cabo adecuadamente,
verifica que las actividades relacionadas con la
calidad del producto, y de procesos se lleve a
cabo, da seguimiento a costos, actualiza estado
de riesgos coordina actividades de mitigación,
administra recursos materiales y humanos,
gestiona adquisiciones para el proyecto da
seguimiento a planes de entrenamiento y
desarrollo de recursos humanos, lleva a cabo el
seguimiento a la planeación de datos para
verificar la seguridad y confiabilidad de los
mismos, como se muestra en la figura 9.
Figura 8
Gestión de requerimientos (RE REQM)
En esta fase el analista ejecuta el plan de
análisis, para especificar los requerimientos
funcionales y no funcionales utilizando
representaciones como prototipos, casos de uso
o escenarios. También es necesario definir el
proceso de levantamiento de requerimientos,
control de los cambios, y documentación de la
matriz de trazabilidad. Como se muestra en las
siguientes figura 10.
166
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Figura 9
Aseguramiento de calidad (PPQA)
Se establecen planes de calidad y calendarios de
auditorías para cada uno de los procesos,
también se coordinan las funciones de
documentación y ejecución de pruebas. Figuras
11.
Figura 10
Gestión de la Configuración (CM)
En esta etapa se realizan planes de gestión de la
configuración a nivel organizacional y a nivel
proyecto, que administre los productos de
trabajo activos de proceso para integrar las
líneas base, auditorias físicas, auditorias
funcionales, administración de cambios de
elementos de configuración, y reportes de
estado. Figura 12.
Figura 11
Gestión de Adquisiciones (SAM)
En esta fase se establecen planes de
adquisiciones, acuerdos, contratos y de
seguimiento a los mismos. En la fase de
definición es necesario que revise el proceso
actual de adquisiciones y lo documente junto
con los formatos aplicables para llevar a cabo
esta gestión como pueden ser listas de
proveedores, inventarios de activos o licencias,
formatos para solicitud de compras para evaluar
proveedores, reportes de avances periódicos de
desempeño de proveedores y cierre de
adquisiciones.
Conclusión
Hay que recordar que el enfoque general de
CMMI radica en el desarrollo de procesos
organizacionales que permiten mejorar el
desarrollo de productos y servicios. En
particular, el nivel 2 tiene como esencia el
proveer los fundamentos para gestionar bajo
procesos y las bases para la estandarización de
los mismos. Los resultados finales tangibles
del proyecto fueron documentar la
especificación de requisitos que contiene la
descripción de casos de uso así como los
requerimientos no funcionales y funcionales
que deberá cumplir el proyecto, análisis y
diseño: que contiene.
167
Artículo Revista de Tecnología e Innovación Marzo 2015. Vol. 2 No.2 154-167
ISSN-2410-3993
ECORFAN® Todos los derechos reservados. LIMA-Margarita, CRISOSTOMO-Sebastián, CONTRERAS-Jessica & PEREZ-
Martha. Experiencia aplicando el modelo Integración de modelos de madurez de
capacidades nivel 2 (CMMI- DEV 2) en la Pyme Miracle Business Network S.A.
de C.V. Revista de Tecnología e Innovación 2015
Referencias
Institute, S. E. (2010). CMMI® for
Development, Version 1.3. Carnegie Mellon
University.
Lussier, R. (2010). Liderazgo teoria, aplicación
y desarrollo de habilidades (4 ed.). Queretaro:
CENGAGE Learning.
Piattini, M. y Garzás Javier (2 ed.). (2010).
Alfaomega.
Somerville, I. (2011). Ingeniería de software
(2011 ed.). México: Pearson Educación.
Yesenia Nohemí González Meneses, N.Y.
(2014). Análisis del estado actual de
certificaciones CMMIDEV ver. 1.3 año 2013 y
2014, a nivel Mundial y en México . Research
in Computing Science 79 (2014), 124.
Institute, S. E. (2010). CMMI® for
Development, Version 1.3. Carnegie Mellon
University.
Recuperado de
http://cmmiinstitute.com/resources/cmmi-
development-version-13
Rodríguez Cosme, B. (2014) Sistema de
adquisición de bienes, servicios e
infraestructura aplicando el modelo CMMI-
DEV2 (Memoria de estadia profesional inédita
de Técnico Superior Universitario).
Universidad Tecnológica de Tlaxcala
PYME Miracle Business S.A.de C.V.
Kernel-SEI. HandsOnCMMiDev Vjca
[Diapositivas], 91 Diapositivas
Secretaría de Economía. Prosoft 3.0
Convocatoria Prosoft 2014. Recuperado de
http://www.prosoft.economia.gob.mx