Tesis Cmmi Dev Moskitt4me

Mster Universitario en Ingeniera del Software, Mtodos
Formales y Sistemas de Informacin
Universitat Politcnica de Valncia
Departamento de Sistemas Informticos y

Computacin
CMMI aplicado a entornos de

desarrollo software: El caso de
MOSKitt4ME
Valencia, Septiembre 2013
Author : Director :
Daz Aspilcueta, Edith Vicente, Pelechano Ferragud
Co-directora :
Manuela, Albert Albiol
Curso Acadmico 2012/2013

Dime y lo olvido, ensame y lo recuerdo, involcrame y lo aprendo"
Benjamin Franklin
Resumen
El estudio est centrado principalmente en la calidad del proceso de desarrollo de softwa-
R

re. En concreto, el trabajo busca la integracin del estndar CMMI un modelo para
la mejora y evaluacin de mtodos para el desarrollo y ejecucin de sistemas de softwa-
re y MOSKitt4ME una herramienta para la denicin de mtodos de desarrollo de
software y la construccin de las herramientas CASE que les dan soporte.
Para conseguir el objetivo descrito, se ha aplicado a MOSKitt4ME las mejores prcti-

R

cas de calidad descritas en CMMI para desarrollo v1.3, hasta alcanzar los niveles de
madurez 2 y 3, con el n de obtener entornos de desarrollo de software donde se apli-
quen mtodos o procesos que estn bien caracterizados y comprendidos. Este propsito
se realiz por medio de la evaluacin, anlisis y determinacin de las relaciones y diver-

R

gencias que existan entre MOSKitt4ME y CMMI para desarrollo v1.3 en los niveles
de madurez 2 y 3.
Para nalizar, una vez identicadas las relaciones o diferencias que existen entre MOS-
R

Kitt4ME y CMMI para desarrollo v1.3, se realizaron propuestas para extender MOS-
R

Kitt4ME y de esta forma alcanzar el nivel de calidad descrito en CMMI para desarrollo
v1.3 y lograr una mayor sinergia entre ambos.

Abstract
The main focus of present study is the quality of software development processes. In
R

particular, it attempts to integrate the standard CMMI a model for the improvement
and evaluation of methods for the development and enactment of software systems with
MOSKitt4ME a tool for denition of software development methods and building CASE
tools that support them.
To obtain the objective described above, the best quality practices that are described in
R

CMMI for Development v1.3 were applied in MOSKitt4ME until maturity levels 2 and
3 had been reached, in order to obtain software development environments where methods
or processes are applied that are well characterized and understood. This aim has been
achieved through evaluation, analysis and identication of the existing connections and
R

dierences between MOSKitt4ME and CMMI for Development v1.3 maturity levels 2
and 3.
R

Finally, once the connections or dierences between MOSKitt4ME and CMMI for
Development v1.3 had been identied, proposals were made to extend MOSKitt4ME in
R

order to the quality level described in CMMI for Development v1.3 and thus accomplish
greater synergy between them.

Agradecimientos
A Dios por darme la fuerza para perseverar y alcanzar una de mis metas.
A todos los profesores del mster y compaeros de estudios de ellos he aprendido tanto
e incluso ms de las expectativas que me haba formulado, antes de llegar a este hermoso
pas. Es admirable la vocacin y profesionalismo de muchos de los docentes que imparten
clases.
A Mario Cervera por ser un excelente gua, por compartir sus conocimientos, su tiempo
y mucha paciencia de no contar con su apoyo no habra logrado nalizar este proyecto.
A Manuela Albert y Victoria Torres quienes desde el inicio fueron mis guas.
A Markus Hdl ( ) mi esposo, por toda su ayuda incondicional, su disciplina, por toda
su comprensin, sus buenos consejos que siempre me acompaan y me guan, sobre todo
por su amor que ha sido mi principal pilar ante los buenos y malos momentos.
A mis buenos amigos que he encontrado en este perodo de estancia, imposible men-
cionarlos a todos porque llenara muchas pginas...Sin embargo, de quien he aprendido
mucho, indiscutiblemente, es de Angel Cuenca, gracias a todo su apoyo y amistad a lo
largo del mster. A Priscila Cedillo que junto con su familia me ha brindado una amistad
incondicional.
A mis padres, familiares y buenos amigos que siempre me apoyan a pesar de la distancia.
Edith Daz
Valencia, Septiembre 2013
iv
ndice general
Resumen ii
Abstract iii
Agradecimientos iv
ndice de Figuras xi
ndice de Tablas xii
1. Introduccin 1
1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Contexto de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Contexto Tecnolgico 7
2.1. Integracin de Modelos de Madurez de Capacidades . . . . . . . . . . . . 7
R
2.1.1. Acerca de CMMI para desarrollo . . . . . . . . . . . . . . . . . . 8
2.1.1.1. Niveles de madurez . . . . . . . . . . . . . . . . . . . . . 8
2.1.1.2. Niveles de capacidad . . . . . . . . . . . . . . . . . . . . . 10
2.1.2. Componentes del rea de proceso . . . . . . . . . . . . . . . . . . . 10
2.1.3. SCAMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Marco metodolgico para construir mtodos de desarrollo de software

MOSKitt4ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Ingeniera de mtodos . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2. SPEM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2.1. Caractersticas generales de SPEM 2.0 . . . . . . . . . . . 19
2.2.2.2. Conceptos claves SPEM 2.0 . . . . . . . . . . . . . . . . . 20
2.2.2.3. Descripcin detallada . . . . . . . . . . . . . . . . . . . . 21
2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3. Comparacin de CMMI Vs MOSKitt4ME - Nivel de Madurez 2 27

3.1. Gestin de acuerdos con proveedores (SAM) . . . . . . . . . . . . . . . . . 27
3.2. Gestin de requisitos (REQM) . . . . . . . . . . . . . . . . . . . . . . . . 28
v
ndice general vi
3.2.1. SG 1 Gestionar los requisitos . . . . . . . . . . . . . . . . . . . . . 28
3.2.1.1. SP 1.1 Comprender los requisitos . . . . . . . . . . . . . . 28
3.2.1.2. SP 1.2 Obtener el compromiso sobre los requisitos . . . . 28
3.2.1.3. SP 1.3 Gestionar los cambios a los requisitos . . . . . . . 29
3.2.1.4. SP 1.4 Mantener la trazabilidad bidireccional de los re-

quisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1.5. SP 1.5 Asegurar el alineamiento entre el trabajo del pro-

yecto y los requisitos . . . . . . . . . . . . . . . . . . . . . 30
3.3. Monitorizacin y control del proyecto (PMC) . . . . . . . . . . . . . . . . 30
3.3.1. SG 1 Monitorizar el proyecto frente al plan . . . . . . . . . . . . . 30
3.3.1.1. SP 1.1 Monitorizar los parmetros de planicacin del

proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1.2. SP 1.2 Monitorizar los compromisos . . . . . . . . . . . . 31
3.3.1.3. SP 1.3 Monitorizar los riesgos del proyecto . . . . . . . . 31
3.3.1.4. SP 1.4 Monitorizar la gestin de los datos . . . . . . . . . 31
3.3.1.5. SP 1.5 Monitorizar la involucracin de las partes interesadas 32
3.3.1.6. SP 1.6 Llevar a cabo las revisiones del progreso . . . . . . 32
3.3.1.7. SP 1.7 Llevar a cabo las revisiones de hitos . . . . . . . . 32
3.3.2. SG 2 Gestionar las acciones correctivas hasta su cierre . . . . . . . 33
3.4. Planicacin del proyecto (PP) . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1. SG 1 Establecer las estimaciones . . . . . . . . . . . . . . . . . . . 33
3.4.1.1. SP 1.1 Estimar el alcance del proyecto . . . . . . . . . . . 33
3.4.1.2. SP 1.2 Establecer las estimaciones de los atributos de los

productos de trabajo y de las tareas . . . . . . . . . . . . 34
3.4.1.3. SP 1.3 Denir las fases del ciclo de vida del proyecto . . . 35
3.4.1.4. SP 1.4 Estimar el esfuerzo y el coste . . . . . . . . . . . . 35
3.4.2. SG 2 Desarrollar un plan de proyecto . . . . . . . . . . . . . . . . . 35
3.4.2.1. SP 2.1 Establecer el presupuesto y el calendario . . . . . 36
3.4.2.2. SP 2.2 Identicar los riesgos del proyecto . . . . . . . . . 36
3.4.2.3. SP 2.3 Planicar la gestin de los datos . . . . . . . . . . 36
3.4.2.4. SP 2.4 Planicar los recursos del proyecto . . . . . . . . . 36
3.4.2.5. SP 2.5 Planicar el conocimiento y las habilidades nece-

sarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2.6. SP 2.6 Planicar la involucracin de las partes interesadas 37
3.4.2.7. SP 2.7 Establecer el plan de proyecto . . . . . . . . . . . 38
3.4.3. SG 3 Obtener el compromiso con el plan . . . . . . . . . . . . . . . 38
3.5. Aseguramiento de la calidad del proceso y del producto (PPQA) . . . . . 38
3.5.1. SG 1 Evaluar objetivamente los procesos y los productos de trabajo 39
3.5.1.1. SP 1.1 Evaluar objetivamente los procesos . . . . . . . . . 39
3.5.1.2. SP 1.2 Evaluar objetivamente los productos de trabajo . 39
3.5.2. SG 2 Proporcionar una visin objetiva . . . . . . . . . . . . . . . . 40
3.5.2.1. SP 2.1 Comunicar y resolver las no conformidades . . . . 40
3.5.2.2. SP 2.2 Establecer los registros . . . . . . . . . . . . . . . 40
3.6. Gestin de conguracin (CM) . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1. SG 1 Establecer las lneas base . . . . . . . . . . . . . . . . . . . . 40
3.6.1.1. SP 1.1 Identicar los elementos de conguracin . . . . . 41
3.6.1.2. SP 1.2 Establecer un sistema de gestin de conguracin 41

ndice general vii
3.6.1.3. SP 1.3 Crear o liberar las lneas base . . . . . . . . . . . . 41
3.6.2. SG 2 Seguir y controlar los cambios . . . . . . . . . . . . . . . . . 42
3.6.2.1. SP 2.1 Seguir las peticiones de cambio . . . . . . . . . . . 42
3.6.2.2. SP 2.2 Controlar los elementos de conguracin . . . . . 42
3.6.2.3. SP 3.1 Establecer los registros de gestin de conguracin 43
3.6.2.4. SP 3.2 Realizar auditoras de conguracin . . . . . . . . 43
3.7. Medicin y anlisis (MA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4. Comparacin de CMMI Vs MOSKitt4ME - Nivel de Madurez 3 47

4.1. Denicin de procesos de la organizacin (OPD) . . . . . . . . . . . . . . 47
4.1.1. SG 1 Establecer los activos de proceso de la organizacin . . . . . 47
4.1.1.1. SP 1.1 Establecer los procesos estndar . . . . . . . . . . 48
4.1.1.2. SP 1.2 Establecer las descripciones de los modelos de ciclo

de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1.3. SP 1.3 Establecer los criterios y las guas de adaptacin . 48
4.1.1.4. SP 1.4 Establecer el repositorio de mediciones de la or-

ganizacin . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.1.5. SP 1.5 Establecer la biblioteca de activos de proceso de

la organizacin . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.1.6. SP 1.6 Establecer los estndares del entorno de trabajo . 50
4.1.1.7. SP 1.7 Establecer las reglas y guas para los equipos . . . 50
4.2. Enfoque en procesos de la organizacin (OPF) . . . . . . . . . . . . . . . . 51
4.2.1. SG 1 Determinar las oportunidades de mejora de procesos . . . . . 51
4.2.1.1. SP 1.1 Establecer las necesidades de proceso de la orga-

nizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1.2. SP 1.2 Evaluar los procesos de la organizacin . . . . . . 52
4.2.1.3. SP 1.3 Identicar las mejoras de procesos de la organizacin 52
4.2.1.4. SG 2 Planicar e implementar las acciones de proceso . . 52
4.2.2. SG 3 Desplegar los activos de proceso de la organizacin e incor-

porar las experiencias . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2.1. SP 3.1 Desplegar los activos de proceso de la organizacin 53
4.2.2.2. SP 3.2 Desplegar los procesos estndar . . . . . . . . . . . 53
4.2.2.3. SP 3.3 Monitorizar la implementacin . . . . . . . . . . . 53
4.2.2.4. SP 3.4 Incorporar las experiencias en los activos de pro-

ceso de la organizacin . . . . . . . . . . . . . . . . . . . 54
4.3. Formacin en la organizacin (OT) . . . . . . . . . . . . . . . . . . . . . . 54
4.4. Gestin de riesgos (RSKM) . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5. Gestin integrada del proyecto (IPM) . . . . . . . . . . . . . . . . . . . . . 55
4.5.1. SG 1 Utilizar el proceso denido del proyecto . . . . . . . . . . . . 56
4.5.1.1. SP 1.1 Establecer el proceso denido del proyecto . . . . 56
4.5.1.2. SP 1.2 Utilizar los activos de proceso de la organizacin

para planicar las actividades del proyecto . . . . . . . . 56
4.5.1.3. SP 1.3 Establecer el entorno de trabajo del proyecto . . . 57
4.5.1.4. SP 1.4 Integrar los planes . . . . . . . . . . . . . . . . . . 57
4.5.1.5. SP 1.5 Gestionar el proyecto utilizando planes integrados 57
4.5.1.6. SP 1.6 Establecer los equipos . . . . . . . . . . . . . . . . 58

ndice general viii
4.5.1.7. SP 1.7 Contribuir a los activos de proceso de la organizacin 58
4.5.2. SG 2 Coordinar y colaborar con las partes interesadas relevantes . 59
4.5.2.1. SP 2.1 Gestionar la involucracin de las partes interesa-

das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.2.2. SP 2.2 Gestionar las dependencias . . . . . . . . . . . . . 59
4.5.2.3. SP 2.3 Resolver las cuestiones de coordinacin . . . . . . 59
4.6. Desarrollo de requisitos (RD) . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6.1. SG 1 Desarrollar los requisitos de cliente . . . . . . . . . . . . . . . 60
4.6.1.1. SP 1.1 Educir las necesidades . . . . . . . . . . . . . . . . 60
4.6.1.2. SP 1.2 Trasformar las necesidades de las partes interesa-

das en requisitos de cliente . . . . . . . . . . . . . . . . . 60
4.6.2. SG 2 Desarrollar los requisitos de producto . . . . . . . . . . . . . 60
4.6.3. SG 3 Analizar y validar los requisitos . . . . . . . . . . . . . . . . . 61
4.6.3.1. SP 3.1 Establecer los conceptos y los escenarios de operacin 61
4.6.3.2. SP 3.2 Establecer una denicin de la funcionalidad y de

los atributos de calidad requeridos . . . . . . . . . . . . . 61
4.6.3.3. SP 3.3 Analizar los requisitos . . . . . . . . . . . . . . . . 62
4.6.3.4. SP 3.4 Analizar los requisitos para conseguir un equilibrio 62
4.6.3.5. SP 3.5 Validar los requisitos . . . . . . . . . . . . . . . . 62
4.7. Integracin del producto (PI) . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.7.0.6. SG 1 Prepararse para la integracin del producto . . . . . 63
4.7.0.7. SP 1.1 Establecer una estrategia de integracin . . . . . . 63
4.7.0.8. SP 1.2 Establecer el entorno de integracin del producto . 63
4.7.0.9. SP 1.3 Establecer los procedimientos y los criterios de

integracin del producto . . . . . . . . . . . . . . . . . . . 64
4.7.0.10. SG 2 Asegurar la compatibilidad de las interfaces . . . . . 64
4.7.0.11. SP 2.1 Revisar la completitud de las descripciones de las

interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7.0.12. SP 2.2 Gestionar las interfaces . . . . . . . . . . . . . . . 65
4.7.1. SG 3 Ensamblar los componentes de producto y entregar el producto 65
4.7.1.1. SP 3.1 Conrmar la disponibilidad de los componentes

de producto para la integracin . . . . . . . . . . . . . . . 66
4.7.1.2. SP 3.2 Ensamblar los componentes de producto . . . . . . 66
4.7.1.3. SP 3.3 Evaluar los componentes de producto ensamblados 66
4.7.1.4. SP 3.4 Empaquetar y entregar el producto o componente

de producto . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.8. Solucin tcnica (TS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.8.1. SG 1 Seleccionar soluciones de componentes de producto . . . . . . 67
4.8.1.1. SP 1.1 Desarrollar soluciones alternativas y los criterios

de seleccin . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.8.1.2. SP 1.2 Seleccionar las soluciones de componentes de pro-

ducto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8.2. SG 2 Desarrollar el diseo . . . . . . . . . . . . . . . . . . . . . . . 68
4.8.2.1. SP 2.1 Disear el producto o los componentes de producto 69
4.8.2.2. SP 2.2 Establecer un paquete de datos tcnicos . . . . . . 69
4.8.2.3. SP 2.3 Disear las interfaces usando criterios . . . . . . . 69

ndice general ix
4.8.2.4. SP 2.4 Realizar los anlisis sobre si hacer, comprar o re-

utilizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.8.3. SG 3 Implementar el diseo del producto . . . . . . . . . . . . . . 70
4.8.3.1. SP 3.1 Implementar el diseo . . . . . . . . . . . . . . . . 71
4.8.3.2. SP 3.2 Desarrollar la documentacin de soporte del pro-

ducto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.9. Validacin (VAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.9.1. SG 1 Preparar la validacin . . . . . . . . . . . . . . . . . . . . . . 72
4.9.1.1. SP 1.1 Seleccionar los productos para la validacin . . . . 72
4.9.1.2. SP 1.2 Establecer el entorno de validacin . . . . . . . . . 72

validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.9.2. SG 2 Validar el producto o los componentes de producto . . . . . . 73
4.9.2.1. SP 2.1 Realizar la validacin . . . . . . . . . . . . . . . . 73
4.9.2.2. SP 2.2 Analizar los resultados de la validacin . . . . . . 73
4.10. Vericacin (VER) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.10.1. SG 1 Preparar la vericacin . . . . . . . . . . . . . . . . . . . . . 74
4.10.1.1. SP 1.1 Seleccionar los productos de trabajo para la veri-

cacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.10.1.2. SP 1.2 Establecer el entorno de vericacin . . . . . . . . 74

validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.10.2. SG 2 Realizar las revisiones entre pares . . . . . . . . . . . . . . . 75
4.10.3. SG 3 Vericar los productos de trabajo seleccionados . . . . . . . . 75
4.10.3.1. SP 3.1 Realizar la vericacin . . . . . . . . . . . . . . . . 76
4.10.3.2. SP 3.2 Analizar los resultados de la vericacin . . . . . . 76
4.11. Anlisis de decisiones y resolucin (DAR) . . . . . . . . . . . . . . . . . . 77
4.12. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5. Propuestas 81
5.1. Incorporacin de un plan de proyecto . . . . . . . . . . . . . . . . . . . . . 81
5.1.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2. Creacin de una gestin de cambio . . . . . . . . . . . . . . . . . . . . . . 85
5.2.1. Gestin de cambio en MOSKitt4ME . . . . . . . . . . . . . . . . . 87
5.3. Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1. Gestin de riesgos en MOSKitt4ME . . . . . . . . . . . . . . . . . 88
5.4. Manejo de costos y esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5. Validaciones y Vericaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.1. Denicin de OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.2. Uso de OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6. Conclusiones y trabajos futuros 94
A. Glosario 97
A.1. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.2. Armaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
ndice general x
A.3. Lnea Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.4. Gestin Conguracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.5. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.6. Revisiones entre Pares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Bibliografa 99
ndice de Figuras
1.1. Resultados de las evaluaciones publicadas por CMMI Institute por Pas . 3
2.1. Estructura de la representacin por etapas y representacin continua . . . 9
2.2. Niveles de madurez por rea de proceso . . . . . . . . . . . . . . . . . . . 11
2.3. Evaluacin de los niveles de madurez [8] . . . . . . . . . . . . . . . . . . . 16
2.4. Arquitectura general de ambiente CAME[1] . . . . . . . . . . . . . . . . . 17
2.5. Niveles de modelado de MOF . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Marco de trabajo conceptual de SPEM 2.0 [2] . . . . . . . . . . . . . . . . 19
2.7. Conceptos claves del Contenido de Mtodo vs. Proceso . . . . . . . . . . . 21
2.8. Estructura del metamodelo SPEM 2.0 . . . . . . . . . . . . . . . . . . . . 22
5.1. Estructura de desglose de trabajo en MOSKitt4ME . . . . . . . . . . . . . 83
5.2. Plan de proyecto en MS Project 2010 . . . . . . . . . . . . . . . . . . . . . 84
5.3. Proceso de gestin de cambio . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4. Actividades gestin de riesgos [3] . . . . . . . . . . . . . . . . . . . . . . . 89
xi
ndice de Tablas
2.1. Asignacin peso a las prcticas especcas . . . . . . . . . . . . . . . . . . 14
2.2. Resumen de los conceptos de SPEM 2.0 1ra parte . . . . . . . . . . . . . 24
2.3. Resumen de los conceptos de SPEM 2.0 2da parte . . . . . . . . . . . . 25
3.1. Resumen comparativo entre CMMI-DEV vs. MOSKitt4ME - Nivel 2 . . . 44
3.2. Resumen de conceptos entre CMMI-DEV vs. MOSKitt4ME - Nivel 2 . . 46
4.1. Resumen comparativo entre CMMI-DEV vs. MOSKitt4ME - Nivel 3 . . . 78
4.2. Resumen de conceptos entre CMMI-DEV vs. MOSKitt4ME - Nivel 3 . . . 80
5.1. Resumen comparativo SPEM 2.0 vs. Microsoft Project 2010 . . . . . . . . 83
5.2. Prcticas especcas implementadas al incorporar el plan de proyecto . . 85
5.3. Prcticas especcas implementada al crear la gestin de cambios . . . . . 88
5.4. Prcticas especcas implementadas al crear la gestin de riesgos . . . . . 90
5.5. Prcticas especcas implementada al aplicar mtricas . . . . . . . . . . . 91
5.6. Prcticas especcas implementada al usar restricciones OCL . . . . . . . 93
xii
Dedicado a mi esposo y padres.
xiii
Captulo 1
Introduccin
Los procesos son un conjunto de actividades que se interrelacionan, donde se transforman
las entradas en salidas para lograr un propsito. stos pueden estar compuestos por
subprocesos y por elementos de procesos, y pueden formar jerarquas donde el proceso
es el trmino del ms alto nivel, los sub-procesos su siguiente nivel y los elementos de
procesos los ms especcos [4].
Dentro del mbito del desarrollo de software, lo ideal es conseguir que los procesos sean
reproducibles y predecibles, por lo que deben apuntar a mejorar la productividad y
calidad. Para poder llevar a cabo esta meta se debe contar con una efectiva gestin de
proyectos, siendo fundamental la evaluacin de los procesos.
La evaluacin de los procesos de desarrollo de software se realiza para determinar las
necesidades, las capacidades, el grado de eciencia y los errores, ayudando as a encontrar
las soluciones de eventuales errores a tiempo. La eciencia se logra en gran medida por
la calidad de un producto (o de un sistema) que es la consecuencia de la calidad de los
procesos empleados en su desarrollo y mantenimiento.
Todo proceso de desarrollo de software que desee alcanzar un nivel de calidad deber
implementar modelos de mejoras de procesos o estndares de calidad. Uno de los modelos
de mejoras de procesos ha sido proporcionado por el organismo SEI (Software Engineering
Institute ) y consta de un conjunto completo e integrado que combina la madurez de los
procesos de software, la calidad y la abilidad en los productos entregados. Este modelo

R

se denomina CMMI (Capability Maturity Model Integration ) y es un modelo para la
mejora y evaluacin de procesos de la industria para el mantenimiento, desarrollo, la
adquisicin y operacin de productos y servicios.
1
Captulo 1. Introduccin 2
R

CMMI se basa en las mejores prcticas para la gestin y organizacin del desarrollo
de productos y servicios. En el nivel de madurez 3 del modelo para el desarrollo existe
un rea de ingeniera del software que proporciona un excelente enfoque que incluye
requisitos exigentes, efectividad de los diseos, planicacin y seguimiento de proyectos,
realizacin de pruebas estrictas y realizacin de auditoras.
R

Mientras CMMI es un modelo de mejoras de procesos, MOSKitt4ME [5] es un marco
metodolgico para la construccin de mtodos de produccin de software y ejecucin en
proyectos. MOSKitt4ME se basa en tcnicas de desarrollo dirigido por modelos (MDD)
y de ingeniera de mtodos (ME).
MDD es un estilo de desarrollo de software donde el artefacto primario son los modelos, a
partir de los cuales se obtiene el cdigo y otros artefactos. Por otro lado, el campo de ME
se centra en el diseo, la construccin y evaluacin de mtodos, tcnicas y herramientas
de apoyo para el desarrollo de sistemas de informacin [6].
En lneas generales, MOSKitt4ME se basa en meta-modelos y tcnicas de transformacin
de modelos que utilizan las tcnicas de MDD, aunados con los conceptos de ME para el
diseo y la ejecucin del mtodo, el soporte del producto y una parte de los mtodos de
procesos para el desarrollo de software.
R

El propsito del trabajo consiste en la integracin entre MOSKitt4ME y CMMI para
desarrollo v1.3. Para el logro de este objetivo se han evaluado, analizado y determinado
R

las relaciones y divergencias existentes entre MOSKitt4ME y CMMI para desarrollo
v1.3 en los niveles de madurez 2 y 3. Una vez determinado el grado de integracin se
pueden formalizar propuestas para extender MOSKitt4ME.
1.1. Motivacion
Hoy en da las organizaciones hacen uso de procesos de calidad; estos sientan las bases
para la introduccin y utilizacin de las tecnologas emergentes, que sirvan de apoyo para
la consecucin de los objetivos estratgicos de las organizaciones.
Las empresas tecnolgicas, con el n de mejorar la calidad y los valores agregados a sus
productos, evalan constantemente modelos que les ayuden a obtener tcnicas relevantes.
Para obtener mejor posicionamiento y mayor competitividad en el mercado, se emplean
las certicaciones de calidad que, adicionalmente, le proporcionan a las organizaciones
conocimiento acerca de sus procesos.
R

Una aproximacin, que est siendo muy utilizada, es CMMI (Capability Maturity Model
R

Integration ) para la evaluacin de la calidad en los procesos. El modelo CMMI contiene
las mejores prcticas de ingeniera de sistemas e ingeniera de software que se encuentran
en el mercado internacional.
Espaa representa el notable 4 %, mientras que EEUU representan un 23 % de las evalua-
ciones realizadas a nivel mundial, desde el 2010 hasta la fecha (ver gura 1.1). Reciente-
mente, el inters de las empresas y organizaciones espaolas en realizar las evaluaciones
del nivel de madurez (1 al 5) o un perl de rendimiento de nivel de capacidad (1 al 3)
experiment un considerable aumento.
Figura 1.1: Resultados de las evaluaciones publicadas por CMMI

Institute por Pas
R

CMMI para desarrollo proporciona una gua para la creacin de procesos y la medicin
de capacidad y madurez en una organizacin para el desarrollo y la entrega de software
de alta calidad. Por otro lado, MOSKitt4ME proporciona un marco metodolgico para
ayudar en la denicin de los mtodos de desarrollo de software en requisitos particulares.
Incluyendo modelos de mejoras de procesos en MOSKitt4ME se tendr el benecio de
producir mtodos de forma organizada, sistemtica, consistente y efectiva. Es por ello
que MOSKitt4ME requiere contar con modelos de mejoras de procesos, al ser un marco
metodolgico para la construccin de mtodos de produccin de software y ejecucin en

R

proyectos. Para la sinergia con CMMI es necesario un estudio para determinar el grado
R

de integracin de MOSKitt4ME con CMMI para desarrollo.
R

Aprovechando de esta sinergia, se pueden aplicar las mejores prcticas de CMMI en
MOSKitt4ME, siendo un proyecto en pleno desarrollo y auge. De esta manera, se po-
dra garantizar que los mtodos (o procesos) construidos por medio de MOSKitt4ME se
R

ajustan a las directrices y recomendaciones de CMMI para desarrollo v1.3
Se pretende que las organizaciones de desarrollo de software que hacen uso de MOS-
Kitt4ME obtengan las ventajas de las mejores prcticas para la optimizacin y evaluacin
R

de los procesos, dado que MOSKitt4ME estar integrado con CMMI para desarrollo
en los niveles de madurez 2 y 3. Con ello, se proporciona tambin que las organizaciones
R

obtengan las certicaciones requeridas de los niveles de madurez 2 3 de CMMI , lo
que conduce a la calidad en sus procesos o mtodos.
Las ventajas as obtenidas por las organizaciones se resumen en:
Los mtodos y procesos estn bien caracterizados y comprendidos por todos los
miembros de la organizacin. Los proyectos son ms visibles, por lo tanto, la direc-
tiva y los integrantes del equipo saben en que trabajan y conocen el estado de los
proyectos.
Los procesos se gestionan ms proactivamente y se describen mediante estndares,
procedimientos, herramientas y mtodos.
Se genera un producto de desarrollo de software con mejor calidad, mediante una
apropiada obtencin de requerimientos, la deteccin temprana de errores y la tra-
zabilidad de los requerimientos.
El proceso estndar de la organizacin

1 se establece y se mejora a lo largo del
tiempo, por lo tanto es ms consistente. Adicionalmente, el proceso estndar se
utiliza para establecer la integridad en toda la organizacin.
1.2. Objetivos
El trabajo tiene como objetivo integrar el modelo de mejoras de procesos y mtodos
CMMI-DEV v1.3 con el entorno de desarrollo de software MOSKitt4ME. La integracin
consiste en aplicar a MOSKitt4ME las mejores prcticas de calidad descritas en CMMI-
DEV v1.3, hasta alcanzar los niveles de madurez 2 y 3. El propsito es obtener entornos de
desarrollo de software donde se apliquen mtodos o procesos que estn bien caracterizados
y comprendidos.
Para el logro de este objetivo general se realizan los siguientes objetivos especcos:
Identicar el grado de implementacin de las prcticas especcas del nivel de
madurez 2 y 3 de CMMI-DEV v1.3 en relacin a MOSKitt4ME.
1
El proceso estndar es un conjunto de deniciones de procesos que dirigen las actividades de una
organizacin [4]
Proponer soluciones que aseguren la implementacin de las prcticas especcas
no implementadas para extender MOSKitt4ME con los niveles de madurez 2 y 3
de CMMI-DEV v1.3.
1.3. Contexto de la tesis
La tesis de mster ha sido desarrollada para el centro de investigacin de Mtodos de
Produccin de Software (ProS) de la Universidad Politcnica de Valencia. Especca-
mente, el anlisis y la propuesta de este trabajo han sido realizados dentro del contexto
del proyecto MOSKitt4ME.
El proyecto de MOSKitt4ME tiene como objetivo dar apoyo a la ingeniera de mtodos,
proporcionando un marco metodolgico para ayudar a los ingenieros de mtodos en la
denicin de los mtodos de desarrollo de software y la construccin de las herramientas
de apoyo CASE
2 (http://users.dsic.upv.es/mcervera/moskitt4me/ ). El desarrollo del
proyecto, a su vez, se basa en la plataforma de MOSKitt.
Modeling Software KIT (MOSKitt) es una herramienta CASE LIBRE, basada en Eclipse
que est siendo desarrollada por la Consellera de Infraestructuras, Territorio y Medio
Ambiente para dar soporte a la metodologa gvMtrica (una adaptacin de Mtrica III
a sus propias necesidades). (http://www.moskitt.org/ )
1.4. Estructura del documento
Esta tesis est estructurada de la siguiente manera:
Captulo I (este captulo): se indican el contexto, el alcance y la organizacin del trabajo.
Captulo II: se presentan los conceptos necesarios en que se enmarca la tesis y los estn-
dares que sern mencionados a lo largo del trabajo.
Captulo III: se realiza el anlisis para determinar el nivel de implementacin de las
prcticas especcas del nivel de madurez 2 de CMMI-DEV v.1.3 con MOSKitt4ME; al
nal del captulo se muestra un resumen del anlisis comparativo realizado.
Captulo IV: se realiza el anlisis para determinar el nivel de implementacin de las
prcticas especcas del nivel de madurez 3 de CMMI-DEV v.1.3 con MOSKitt4ME; al
nal del captulo se muestra un resumen del anlisis comparativo realizado.
2
C
omputer- Aided S oftware E ngineering; Ingeniera de software asistida por computadora.
Captulo V: se detallan las propuestas de mejoras a incorporar en MOSKitt4ME para
aumentar el grado de implementacin de las prcticas especcas de CMMI-DEV v1.3.
Captulo VII: se resumen las conclusiones generales y se presentan posibles direcciones
para trabajos futuros.
Glosario: Al nal del documento se incluye un glosario con los trminos comnmente
empleados a lo largo de la tesis.

Captulo 2
Contexto Tecnolgico
En este captulo se presentan los conceptos principales del contexto de la presente tesis,
divido en dos partes principales.
La primera parte consta de la descripcin de los modelos de integracin de madurez y
de capacidades para desarrollo (CMMIDEV, Capacity Model Maturity Integration for
Development ) en la versin 1.3 y sus constelaciones, es decir, la coleccin de componentes

R

que utiliza CMMI para desarrollo.
Adems, se presenta uno de los mtodos de evaluacin, SCAMPI (Standard CMMI Ap-
praisal Method for Process Improvement ) clase A versin 1.3, que se utiliza comnmente
R

CMMI para evaluar a una organizacin con respecto a su grado de adecuacin al mo-
delo de mejoras de procesos. No se describe a detalle el estndar de evaluacin, solamente
los puntos necesarios para realizar la valoracin de MOSKitt4ME.
La segunda parte describe los conceptos en que est basado MOSKitt4ME.
2.1. Integracin de Modelos de Madurez de Capacidades
R

El modelo CMMI (Capability Maturity Model Integration ) surge como una continua-
cin del modelo CMM (Capability Maturity Model ) que mide el grado de madurez y de
capacidad de los procesos, consiste en determinar el rango de resultado esperado que se
puede lograr siguiendo un proceso. Para ello, se debe contar de forma explcita y consien-
te el despliegue de los procesos estando documentados, gestionados, medidos, controlados
y mejorados de forma continua. Este modelo ha sido creado por el SEI (Software Engi-
neering Institute ) que pertenece a la Carnegie Mellon University.
7
Captulo 2. Contexto Tecnolgico 8
Actualmente, se encuentra en la versin 1.3 de CMMI, y dentro de esta versin existen
tres reas de inters diferentes que fueron liberados en noviembre del 2010.
CMMI-DEV (CMMI for Development ) Este modelo se enfoca al desarrollo, y
en l se tratan procesos referidos a desarrollo de productos y servicios.
CMMI-ACQ (CMMI for Acquisition ) Este modelo se enfoca a la adquisicin, y
en l se tratan procesos relacionados con el gobierno y con la industria, por ejemplo,
la gestin de la cadena de suministros, la adquisicin y contratacin externa.
CMMI-SVM (CMMI for Services ) Este modelo se enfoca a la gestin, el esta-
blecimiento y la entrega de servicios.
R para desarrollo
2.1.1. Acerca de CMMI
R

La tesis de mster se centrar en CMMI para desarrollo, en adelante CMMI-DEV, que
posee cinco categoras de las reas de procesos y veintids reas de procesos que incluyen
la gestin de proyectos, la gestin de procesos, el desarrollo de software y otros procesos
de soporte para el desarrollo y mantenimiento.
En CMMI-DEV existen dos caminos o representaciones de mejora usando los niveles,
como se muestra en la gura 2.1
1. La representacin por etapas, el primer camino, est relacionada con la madurez
organizacional que permite a las organizaciones de mejorar un conjunto de proce-
sos relacionados, tratando de forma incremental conjuntos sucesivos de reas de
proceso.
2. El segundo camino, la representacin continua, relacionada con la capacidad de
cada rea de proceso, permite a las organizaciones de mejorar de forma incremental
los procesos que corresponden a un rea de proceso individual (o un grupo de reas
de proceso), seleccionada por la organizacin.
2.1.1.1. Niveles de madurez
Los niveles de madurez constan de prcticas especcas y genricas, relacionadas con un
conjunto predenido de reas de procesos, y tienen como propsito el mejoramiento del
rendimiento global de las organizaciones y, por ende, ser ms productivas. Los niveles
de madurez poseen la estructura por etapas que se muestra en gura 2.1, la imagen
izquierda.
Figura 2.1: Estructura de la representacin por etapas y representacin continua
Nivel de madurez 1 Inicial Este nivel es cuando no se realiza ningn tipo de
proceso, o que no se consiguen sus objetivos. Son generalmente ad hoc y caticos,
donde las organizaciones no son capaces de repetir sus xitos.
Nivel de madurez 2 Gestionado Toda organizacin que disponga de procesos,
planicacin y ejecucin de acuerdo con los procesos y estndares para el logro de
sus objetivos. Se mantienen los procesos y estndares en perodos bajo presin y el
establecimiento de los compromisos de las partes interesadas.
Nivel de madurez 3 Denido A parte de tener gestionados los procesos, stos
se ajustan a la poltica de procesos marcada por la organizacin. Se mejoran a lo
largo del tiempo. La gestin es ms proactiva mediante las actividades del proceso.
Nivel de madurez 4 Gestionado cuantitativamente Los procesos se controlan
utilizando tcnicas cuantitativas.
Nivel de madurez 5 Optimizado Adems de cumplir todas las condiciones de
los niveles que le preceden, se revisa y modica o cambia, de forma sistemtica, los
procesos para adaptarlos a los objetivos del negocio.
El presente trabajo se centrar en los niveles de madurez 2 y 3 de CMMI-DEV v1.3
debido a que existen prcticas que proporcionan efectividad en los diseos, planicacin
y seguimiento. Al estar integrado MOSKitt4ME con CMMI-DEV v1.3 en los niveles de
madurez 2 y 3, es posible crear mtodos y ejecucin de proyectos con procesos denidos.

2.1.1.2. Niveles de capacidad
Los niveles de capacidad son la consecucin de la mejora de los procesos desde el punto de
vista de los procesos individuales de una organizacin, para mejorar de forma incremental
para una determinada rea.
Los niveles de capacidades, de representacin continua, son los siguientes de acuerdo
con lo mostrado en gura 2.1, del lado derecho:
Nivel de capacidad 0 Incompleto Es un proceso que o no se realiza, o se realiza

slo parcialmente.
Nivel de capacidad 1 Realizado Es un proceso realizado que lleva a cabo
el trabajo necesario para producir productos de trabajo. Se satisfacen las metas
especcas del rea de proceso.
Nivel de capacidad 2 Gestionado Es un proceso gestionado, eso quiere decir,
un proceso realizado que se ha planicado y ejecutado de acuerdo con las polticas
de la organizacin, produciendo resultados controlados.
Nivel de capacidad 3 Denido Es un proceso denido donde los procesos se
gestionan de forma ms proactiva a travs de la comprensin de las interrelaciones
de las actividades del proceso y de las medidas detalladas del proceso y de sus
productos de trabajo.
2.1.2. Componentes del rea de proceso
Las constelaciones de CMMI-DEV constan de todas las metas y prcticas que se utilizan
para generar los modelos CMMI; los modelos se componen de las reas de procesos que
cubren los conceptos de mejoras de los procesos de desarrollo.
CMMI-DEV se compone de 22 reas de procesos y, a continuacin, se muestra gura 2.2
que contiene las siglas de las reas de procesos y sus categoras por niveles de madurez
asociados.
A continuacin, se describen los acrnimos de las reas de procesos de CMMI-DEV, que se
usan a lo largo del documento en el Captulo 3 Comparacin de CMMI Vs MOSKitt4ME
- Nivel de Madurez 2 y en Captulo 4 Comparacin de CMMI Vs MOSKitt4ME - Nivel
de Madurez 3
Gestin de acuerdos con proveedores (SAM)

Figura 2.2: Niveles de madurez por rea de proceso
Gestin de requisitos (REQM)
Monitorizacin y control del proyecto (PMC)
Planicacin del proyecto (PP)
Aseguramiento de la calidad del proceso y del producto (PPQA)
Gestin de conguracin (CM)
Medicin y anlisis (MA)
Denicin de procesos de la organizacin (OPD)

Enfoque en procesos de la organizacin (OPF)
Formacin en la organizacin (OT)
Gestin de riesgos (RSKM)
Gestin integrada del proyecto (IPM)
Desarrollo de requisitos (RD)
Integracin del producto (PI)
Solucin tcnica (TS)
Validacin (VAL)
Vericacin (VER)
Anlisis de decisiones y resolucin (DAR)
Rendimiento de procesos de la organizacin (OPP)
Gestin cuantitativa del proyecto (QPM)
Gestin del rendimiento de la organizacin (OPM)
Anlisis causal y resolucin (CAR)
Existen 4 categoras por las cuales estn asociadas estas reas de procesos que se men-
cionan en gura 2.2, y que consisten en:
Gestin de proyectos: debe integrar las actividades que establecen y mantienen el
plan de proyecto, establece y mantiene los compromisos, la monitorizacin del plan
de proyecto y la gestin de acuerdo con los proveedores.
Gestin de procesos: es el conjunto de actividades de planeacin, control y ejecucin
de los elementos de un proceso de una empresa. Adems, contiene los elementos
que se representan, la capacidad de documentar y compartir las buenas prcticas,
los activos de procesos, las normas, los procedimientos u otros.
Ingeniera: es el conjunto de las actividades de desarrollo y mantenimiento de todas
las disciplinas de ingeniera. Sin embargo, no solo de ingeniera de software, ya que
se utilizan trminos genricos, para el desarrollo de producto.
Soporte: incluye las actividades que dan soporte al desarrollo y mantenimiento del
producto. Esta categora est dirigida hacia el proyecto y puede ser abordada en
los procesos ms generales de la organizacin.

Las reas de procesos estn compuestas a su vez por metas y prcticas especcas, as
como metas y prcticas genricas. Dado que se ha mantenido el mismo esquema que
presenta CMMI-DEV, Versin 1.3, se procede a explicar en qu consisten:
La meta especca: describe las caractersticas nicas que deben estar presentes
para satisfacer el rea de proceso. Cada meta especca comienza con el prejo
SG (Specic Goal ).
La meta genrica: describe las caractersticas que deben estar presentes para es-
tablecer los procesos que implementan un rea de proceso, y se utiliza en las eva-
luaciones para determinar si se satisface un rea de proceso. Las metas genricas
comienzan con el prejo GG (Generic Goal ).
La prctica especca: es la descripcin de una actividad que se considera impor-
tante para lograr la meta especca asociada. Las prcticas especcas describen
las actividades que se espera que produzcan el logro de las metas especcas de
un rea de proceso. Cada prctica especca comienza con el prejo SP (Specic
Practice ), seguido por un nmero en la forma x.y (ejemplo, SP 1.1).
La prctica genrica: se denomina genrica porque la misma prctica se aplica a
mltiples reas de proceso. Cada prctica genrica comienza con el prejo GP
(Generic Practice ), seguido por un nmero de la forma x.y (ejemplo, GP 1.1).
2.1.3. SCAMPI
SCAMPI
SM A (Mtodo de Evaluacin Estndar de CMMI para la Mejora de Procesos,
R

en ingls Standard CMMI Appraisal Method for Process Improvement A), en la versin
1.3, es un mtodo de evaluacin que permite medir los procesos de una organizacin a
travs de unos estndares: niveles de madurez y de capacidad de un rea de proceso[7].
Durante los siguientes dos captulos se aplicar parcialmente el mtodo de evaluacin
SCAMPI v1.3 para identicar el grado de implementacin que posee MOSKitt4ME en
relacin a los niveles de madurez 2 y 3.
De acuerdo con el trabajo realizado por [8], quien valor las reas de procesos, las prc-
ticas especcas y los niveles de CMMI, obtenemos la siguiente escala con algunas modi-
caciones realizadas en relacin a la versin 1.3:
Las valoraciones posibles de prcticas especcas de acuerdo con el mtodo SCAMPI son:
CI Completamente implementada
AI Ampliamente implementada
PI Parcialmente implementada
NI No implementada
NA No an
Completamente implementada: hay sucientes artefactos (ver denicin A.1) y/o
armaciones (ver denicin A.2) que fueron juzgados como adecuados para demostrar la
implementacin de la prctica, sin presentar debilidades.
Ampliamente implementada: hay sucientes artefactos (ver denicin A.1) y/o ar-
maciones (ver denicin A.2) que fueron juzgados como adecuados para demostrar la
implementacin de la prctica, pero se observan una o ms debilidades.
Parcialmente implementada: los datos (artefactos y / o armaciones) proporcionados

al equipo presentan conictos: algunos datos implican que la prctica s se llev a cabo
mientras que otros indican lo contrario; se observan una o ms de una debilidad.
No implementada: Algunos o todos los datos necesarios estn ausentes o juzgados
como insucientes, los datos suministrados no apoyan las conclusiones de que la prctica
se lleva a cabo; existe una o ms de una debilidad.
No an: la unidad base o funcin de apoyo an no ha llegado a la etapa de la secuencia

de trabajo, o la puesta en marcha para la implementacin de la prctica. Este caso no
ha sido tomado en cuenta durante la evaluacin.
Adicionalmente, se asign un peso numrico a las prcticas especcas descritas, con el
propsito de generar los resultados de la evaluacin a realizar:
Prctica Peso
Completamente implementada 1,00
Ampliamente implementada 0,66
Parcialmente implementada 0,33
No implementada 0,00
Tabla 2.1: Asignacin peso a las prcticas especcas
Valoraciones de las reas de proceso de acuerdo con el mtodo SCAMPI:
Satisfecha
Insatisfecha
No aplicable
Sin puntaje
La valoracin Satisfecha para el modelo de representacin por etapas puede depender
del objetivo del nivel de madurez de la evaluacin, es decir si se realiza la calicacin de
evaluacin de nivel de madurez 2, se requerir dar como satisfecha la meta genrica 2
con el propsito de apoyar el nivel de madurez 2 como resultado de la evaluacin.
Si algunas de las metas se clasican sin valoracin y ninguna de las dems se calica
Insatisfecha, el rea de proceso est clasicada como Sin Valoracin
Cuando un rea de proceso se determina que es fuera del alcance de la unidad de or-
ganizacin del trabajo, el rea de proceso se designa como No Aplicable y no ha sido
calicada.
Cuando un rea de proceso es aplicable fuera del mbito de aplicacin del modelo utili-
zado para la evaluacin, el rea de proceso se designa como Fuera de Alcance y no ha
sido calicada.
Las valoraciones de los niveles nales del proceso son:
Nivel alcanzado
Nivel no alcanzado
En el diagrama que se muestra en la gura 2.3, se indican los niveles de madurez y su
evaluacin, seguiremos este mismo proceso a lo largo del presente trabajo.
2.2. Marco metodolgico para construir mtodos de desa-

rrollo de software MOSKitt4ME
MOSKiit4ME es una herramienta que se basa en un enfoque metodolgico tomando en
consideracin a dos reas de la ingeniera. Una de ellas es el desarrollo dirigido por mode-
los (MDD) fundamentndose en su infraestructura para la denicin de meta-modelos y
tcnicas de transformacin de modelos; la otra es la ingeniera de mtodos (ME) utilizada
para la denicin de mtodos de desarrollo de software.
Usando el enfoque ME se dene los mtodos como modelos de mtodo basados en el
estndar SPEM 2.0 en la fase del diseo y a partir de estos modelos en la fase
Figura 2.3: Evaluacin de los niveles de madurez [8]
de implementacin se obtienen de forma semiautomtica los entornos CASE que da
soporte a los mtodos.
Adicionalmente, se combinan el estndar SPEM 2.0 con el estndar BPMN 2.0 [9] para
mejorar la ejecucin del proceso, apoyar en la creacin del mtodo al brindar editores
grcos y ayudar en la ejecucin del mtodo mediante el uso de un motor de proceso
[5][10][11].
2.2.1. Ingeniera de mtodos
La ingeniera de mtodos es la disciplina que aborda el diseo, construccin, y adaptacin
de los mtodos, tcnicas y herramientas para el desarrollo de sistemas de informacin
[6]. Dentro de los tipos de ingeniera de mtodos se encuentra la ingeniera de mtodo
situacional (SME) denido por [12] como es una disciplina que aborda la adaptacin de
mtodos a la situacin especca del proyecto en desarrollo, proporcionando normas para
congurar los mtodos partiendo de fragmentos de mtodos estndares ya existentes.
Los entornos que generalmente dan soporte al modelado de los procesos SME son las
llamadas herramientas Ingeniera de Mtodo Asistido por Computadora (CAME; Com-
puter Aided Method Engineering ) e Ingeniera de Software Asistida por Computadora en
un meta-nivel (Meta-CASE; Computer Assisted Software Engineering on a Meta-level ).

Figura 2.4: Arquitectura general de ambiente CAME[1]
En general, la arquitectura de una herramienta CAME se compone de dos partes (ver
gura 2.4) y posee las siguientes caractersticas generales [1][11][13]:
La parte CAME cuenta con la habilidad de proporcionar habilidades aportando
una amplia gama de actividades para la ingeniera de mtodos; esta tecnologa
posee sus inicios con la ME. Los elementos principales del CAME constituyen las
herramientas de ingeniera de mtodo (ofrecen herramientas para facilitar el trabajo
a los ingenieros de mtodos, por ejemplo, la extraccin de componentes del mtodo
y el almacenamiento de la base del mtodo) y la base del mtodo (que es el ncleo
del ambiente CAME). Por lo general, CAME se enfoca en la fase de diseo del
mtodo y ofrece apoyo a la especicacin de los mtodos del proyecto de desarrollo
de software.
La parte CASE tiene como objetivo la mejor comprensin de los modelos de em-
presa, sus actividades y el desarrollo de los sistemas de informacin. Ofrece medios
para la generacin de herramientas CASE del proyecto en especco, obtiene como
entrada los productos y apoya a los entornos de procesos. Su insumo es el proceso
centrado de entornos de ingeniera de software (Process-centered Software Enginee-
ring Environments ; PSEEs) y se generan entornos de soporte de procesos, basados
en los mtodos de proceso. Por lo general, los entornos CASE se enfocan en la
implementacin del mtodo, permitiendo la personalizacin de las herramientas
CASE mediante especicaciones a un alto nivel.
Los procesos de ingeniera de mtodo denen los aspectos relacionados con los productos
y los procesos, que abarcan en lneas generales los mtodos y su denicin. Los productos
representan los artefactos que se producen durante la ejecucin del mtodo. El proceso
es la especicacin de forma precisa, completa y bien estructurada del producto, siendo
til para facilitar la comprensin del desarrollo del software. Adems, se recomienda la
ejecucin de la especicacin del proceso, debido a que es til para guiar a los ingenieros
de software en lo que respecta a los procesos de desarrollo real y la automatizacin nal
[10].
2.2.2. SPEM 2.0
SPEM 2.0 (Software & Systems Process Engineering Meta-Model ; SPEM 2.0) es un estn-
dar para la representacin de modelos de procesos de ingeniera del software e ingeniera
de sistemas. Por lo que se considera SPEM 2.0 un estndar de meta-modelado que brinda
un marco conceptual para el modelado, documentacin, presentacin, gestin e intercam-
bio de procesos de desarrollo de software y sus componentes, la ejecucin de los procesos
de desarrollo y los mtodos [14].
SPEM 2.0 est basado en la especicacin MOF (Meta Object Facility ) en la cual dene
una arquitectura de modelado de cuatro niveles conceptuales (ver gura 2.5), desarrollado
dentro del marco del OMG

1 (Object Management Group ). SPEM 2.0 es un metamodelo
que sirve para representar los modelos de los procesos del software.
Figura 2.5: Niveles de modelado de MOF
Los metamodelos (M2) denotan la denicin de modelos para modelos, y los modelos
(M1) representan la realidad para un propsito de un cierto dominio, siendo los modelos
una abstraccin de la realidad (M0), dado que no se puede representar todos los aspectos
de la realidad (ver gura 2.5).
1
Para mayor referencias en: http://www.omg.org/spec/
2.2.2.1. Caractersticas generales de SPEM 2.0
La implementacin del marco conceptual del metamodelo se enmarca en las siguientes
caractersticas comnmente utilizadas (ver gura 2.6):
Figura 2.6: Marco de trabajo conceptual de SPEM 2.0 [2]
Proveer una representacin estandarizada y una gestin de libreras de

mtodos reutilizable. Los desarrolladores de software necesitan conocer los m-
todos y prcticas para los desarrollos, conociendo las tareas bsicas del desarrollo,
as como la especicacin y gestin de requisitos, las tcnicas de anlisis y diseo,
adems de las implementaciones en todas las fases del producto.
Con este n, SPEM 2.0 permite disponer de un formato estandarizado por el cual se
puede crear una base de conocimiento para la ingeniera de procesos de desarrollo de
software y sistemas que pueda ser desplegada y gestionada por los propios desarro-
lladores. El formato estandarizado representa el contenido de mtodo reutilizable,
es decir, una coleccin de roles, tareas, productos de trabajos, guas, fragmentos de
mtodos y procesos elementos en que se basa SPEM para la representacin de
los procesos.
Soportar el desarrollo, la gestin y el crecimiento de procesos. SPEM 2.0

admite la creacin de procesos basados en el contenido de mtodo reutilizable. El
contenido de mtodo es independiente del ciclo de vida del proceso, siendo reutili-
zado a lo largo del ciclo de vida de un proceso o fuera del mismo, y, dependiendo del
contexto de desarrollo de cada proceso, ser su adaptacin o personalizacin. Desde

este punto de vista, los procesos pueden ser representados como ujos de trabajo
(Workows ) y/o estructuras de desglose de trabajo (Work Breakdown Structures ;
WBS). SPEM 2.0 soporta la creacin sistemtica de procesos basados en la reutili-
zacin de contenidos de mtodos, gracias a la reutilizacin de patrones de proceso.
Soportar el despliegue slo de los procesos y componentes de mtodos

necesarios en un determinado entorno mediante la denicin de con-
guraciones de procesos y componentes de mtodo. Congurar un marco
de trabajo consiste en desplegar los contenidos del mtodo y procesos necesarios
que sean requeridos para los equipos de desarrollo. SPEM 2.0, mediante el desplie-
gue del contenido de mtodo y proceso, se ajusta a la necesidad de los proyectos,
tomando en consideracin que ningn proyecto es exactamente igual a otro y un
proceso de desarrollo nunca se ejecuta bajo las mismas condiciones. SPEM 2.0,
para cumplir con estas caractersticas mencionadas, incorpora los conceptos de re-
utilizacin de procesos o patrones de procesos y la variabilidad, que ambos son
procesos que incluyen alternativas congurables, y la particularizacin en donde
los usuarios denen sus propias extensiones sobre procesos estndares reutilizables.
Soportar la implementacin / ejecucin o realizacin de procesos para

proyectos en desarrollo. Se considera un aporte de los procesos cuando afecta
el comportamiento del equipo, por lo que las deniciones de proceso deben ser des-
plegadas en un formato que les permitan su ejecucin de forma automtica. SPEM
2.0 incluye las estructuras de denicin de proceso que permiten expresar cmo
un proceso ser realizado de forma automtica, bien sea a travs de sistemas de
planicacin (ejemplo mediante Microsoft Project) o un motor de proceso (ejemplo
mediante BPMN 2.0).
2.2.2.2. Conceptos claves SPEM 2.0
La clave de SPEM 2.0 es la divisin entre la denicin de los mtodos y la aplicacin de
los mtodos denidos al desarrollo de un proceso en particular, como se puede apreciar
en la gura 2.7:
Primero, se puebla el contenido de mtodo (Method Content ) con los elementos
de contenido (Content Element s), es decir, los elementos primarios o constructores
bsicos. Se denen las tareas (Task Denition ), se organizan en distintos pasos
(Steps), se dene cules sern los productos de entrada o de salida para cada uno
de ellos (Work Product Denition ) para luego especicar quin realizar dicha tarea
(Role Denition ).
En la interseccin del contenido de mtodo y los procesos existe la gua (Guidan-
ce ) que consiste en plantillas, ejemplos, elementos de comprobacin, etc. que dan
soporte tanto al mtodo como a los procesos.
Despus, se combinan y reutilizan dichos elementos para obtener los procesos (Pro-
cesses ), conformados por un grupo de elementos que estn denidos, descritos en
una serie de relaciones especcas para un mtodo.
Figura 2.7: Conceptos claves del Contenido de Mtodo vs. Proceso
2.2.2.3. Descripcin detallada
La divisin del metamodelo de SPEM 2.0 se estructura en siete paquetes (ver gura
2.8), organizados en unidades lgicas. Estas unidades se extienden, se complementan y le
proporcionan estructuras adicionales a las unidades que dependen de ellas. Las unidades
de la capa inferior de SPEM 2.0 se pueden implementar parcialmente sin requerir a
los paquetes de la capa superior. Regularmente, las clases del metamodelo se denen
de forma sencilla en unidades de niveles inferiores, para luego extenderse a unidades
superiores, si se desea cumplir con requisitos ms complejos del modelado del proceso, e
incluso se puede utilizar diferentes niveles de capacidad, conjuntos de conceptos y niveles
de formalismo para expresar sus procesos al utilizar diferentes paquetes.
A continuacin, se describen las capacidades de los paquetes que se mencionan en la
gura 2.8:
Figura 2.8: Estructura del metamodelo SPEM 2.0
Core es el ncleo de metamodelo de SPEM 2.0 y contiene todas las clases
y abstracciones que son la base para las clases de los dems paquetes. Las dos
capacidades bsicas que posee son:
crear cualicaciones denidas por el usuario (Kinds ) que permiten establecer
diferentes tipos de instancias de una clase;
denir trabajos expresados como procesos mediante un conjunto de clases
abstractas.
Process Structure Contiene las clases requeridas para la creacin de modelos

de procesos bien sean exibles y sencillos. Adicionalmente, proporciona la capacidad
de reutilizacin a travs del ensamblado de proceso, usando para ello un conjunto
de actividades vinculadas de forma dinmica. La estructura de proceso contiene
los elementos principales que permiten denir los procesos de desarrollo, como por
ejemplo las actividades.
Process Behaviour permite la representacin de la parte dinmica de los
procesos, por ejemplo los diagramas de actividad de UML 2.0 (comportamiento de
proceso), las mquinas de estado, etc.

Managed Content ayuda en la gestin e incorporacin de las descripciones en

lenguaje natural de los documentos y otras informaciones que son de utilidad a los
procesos o a los sistemas de anotaciones. Adems de eso, ayudan para capturar cier-
tos valores y culturas, por lo que existe libertad total para realizar combinaciones
de los modelos estructurales de procesos con contenido de lenguaje natural.
Method Content proporciona los conceptos necesarios para construir una base
de conocimientos sobre el desarrollo que puede ser independiente de los procesos
especcos y los proyectos de SPEM 2.0. Contiene los principales elementos de
mtodo y puede estar organizado a voluntad del usuario mediante una jerarqua
de paquetes de contenido (Content Package ). El objetivo principal de este paque-
te es denir las tareas (Task Denition ), organizarlas en distintos pasos (Steps ),
denir cules son los productos de entrada-salida de cada una de ellas (Work Pro-
duct Denition ) y especicar quin ha sido el que ha realizado dicha tarea (Role
Denition ).
Process with Methods incorpora nuevas estructuras para la integracin del

paquete de la estructura de proceso (Process Structure) y los conceptos y elementos
del paquete del contenido de mtodo (Method Content). Cuando se asocian los
elementos del mtodo en las partes especcas de proceso, se crean nuevas clases
que heredarn los elementos del mtodo, aunque con cambios particulares.
Method Plugin insiere conceptos (por ejemplo, Method Plugin, Process Com-
ponent, Variability...) para disear, gestionar y mantener repositorios y bibliotecas
de contenidos de mtodos y procesos.
De los paquetes arriba mencionados, se proceder a explicar de forma resumida algunos
conceptos relevantes, como muestra la tabla 2.2 y la tabla 2.3:

CONTENIDO DE MTODO (Method Content )
Tarea (Task De- Dene una unidad asignable y gestionable de trabajo, que se establece a
nition ) unos pocos roles y que afecta o es afectada por uno o varios productos
de trabajo (Work Product ).
Rol (Role Deni- Dene un conjunto de habilidades, competencias y responsabilidades de
tion ) un participante o de un conjunto de participantes.
Producto de tra- Es un elemento que es consumido, producido o modicado por las ta-
bajo (Work Pro- reas, siendo en muchos casos productos de trabajo tangibles. Contiene
duct Denition ) las asociaciones de tipo de composicin (Composition ), de agregacin
(Aggregation ) y de impactado por (Impacted by ). Adicionalmente, posee
los tipos predenidos de especializacin como es de artefacto (Artifact ),
de entregable (Deliverable ) y de resultado (Outcome ).
Cualicacin Es la habilidad o competencia especca que se utiliza para modelar
(Qualication ) y representar a las cualicaciones o las condiciones requeridas para el
desempeo de una tarea y / o un rol. E incluso se puede usar para
encontrar individuos con cualidades especcas.
Paso (Step ) Sirve para organizar una tarea en partes o subunidades de trabajo.
CONTENIDO ADMINISTRADO (Managed Conten t)
Gua (Guidance ) Un elemento descriptible que proporciona informacin adicional relacio-

nada con otros elementos. Dentro los tipos de guas (Guidance Kinds ) se
encuentran: lista de comprobacin (Checklist ), concepto (Concept ), con-
sideraciones para el clculo (Estimation Consideration ), mtrica para la
estimacin (Estimation Metric ), ejemplo (Example ), instruccin (Guide-
line ), prctica (Practice ), informe (Report ), activo reutilizable (Reusable
Asset ), mapa (Roadmap ), material de soporte (Supporting Materia l),
plantilla (Template ), denicin de trmino (Term Denition ), gua de
herramienta (Tool Mentor ), documentacin (Whitepaper ).
Categora (Cate- Es un elemento descriptible que se utiliza para categorizar cualquier ele-
gory ) mento, en base a criterios que se denan. Una categora puede estar
asociada a otras categoras creando as las jerarquas de agrupamien-
tos de procesos que pueden ser de tipo estndar (Standard Category ) o
personalizada (Custom Category )
ESTRUCTURA DE PROCESO (Process Structure )
Elemento de des- Es el principal tipo de elemento de desglose, ya que representa la des-

glose de trabajo composicin del trabajo. Puede ser de dos tipos: actividades o hitos.
(Work Breakdown Entre sus propiedades se encuentran: se puede repetir (Is Repeatable ),
Element ) son continuas (Is Ongoing ) y estn condicionados por sucesos (Is Event
Driven ).
Actividad (Acti- Es el elemento que sirve para representar la unidad bsica de trabajo o
vity ) para representar un proceso en s mismo.
Tabla 2.2: Resumen de los conceptos de SPEM 2.0 1ra parte

ESTRUCTURA DE PROCESO (Process Structure )
Hito (Milestone ) Se trata de un evento signicativo dentro del proceso de desarrollo.

Secuencia de tra- Es un elemento que representa una relacin entre dos elementos de des-
bajo (Work Se- glose de trabajo en la que uno de los elementos de desglose de trabajo
quence ) depende del inicio o el nal de otro elemento de desglose de trabajo, con
el n de comenzar o terminar, denominados como predecesor y sucesor.
PROCESO CON MTODOS (Process with Methods )
Actividad (Acti- Se dene como un grupo de distintos elementos (otras actividades, tarea
vity ) en uso, rol en uso, e hitos) denidos en un espacio de nombres y para los
que se han descrito una serie de relaciones segn el mtodo o proyecto
particulares. SPEM 2.0 tiene denidos varios tipos de actividades espe-
ciales que son la iteracin (Iterations ), las fases (Phases ) y el proceso
(Process ).
Contenido de m- Es el concepto clave para entender la separacin entre procesos y el con-
todo en uso (Met- tenido de mtodo. El contenido de mtodo posee una serie de elementos
hod Content Use ) y relaciones que son modicados debido a que se usan en un proceso par-
ticular para el cul ha sido creado el contenido de mtodo que pueden
ser tareas, roles y productos de trabajo, denominados elementos en uso .
PLUG-IN DE MTODO (Method Plugin )
Plug-in de mto- Se dene como una unidad de almacenamiento fsico de la conguracin,

do (Method Plu- modularizacin, empaquetado e implantacin de proceso y el contenido
gin ) de mtodo. Un plug-in de mtodo se puede extender y ser extendido por
otros plug-ins de mtodo.
Biblioteca de m- Denominada como repositorio o biblioteca de mtodos y procesos se de-
todo (Method Li- ne como una coleccin de una o ms plug-ins y deniciones de congu-
brary ) raciones de mtodos (Method Conguration ).
Conguracin de Se trata de un subconjunto lgico dentro de una biblioteca de mtodo
mtodo (Method (Method Library ) denido mediante una seleccin de paquetes de mto-
Conguration ) do (Method Packages ), permitiendo denir una visibilidad dentro de la
biblioteca de mtodo, que se puede usar para ltrar contenido de mtodo
y proceso.
Elemento de Va- DEste elemento sirve para proporcionar capacidades de variacin y ex-
riabilidad (Varia- tensin de los elementos de SPEM 2.0. Se contempla 5 tipos de varia-
bility Element ) bilidad entre los elementos de contenido: no aplicable (not assigned ),
contribuye (contributes ), ampla (extends ), reemplaza (replaces ), ampla
y reemplaza (extends-replaces ).
Tabla 2.3: Resumen de los conceptos de SPEM 2.0 2da parte

2.3. Conclusiones
Determinar las relaciones o divergencias que existen entre un marco metodolgico para
construir mtodos de desarrollo de software (MOSKitt4ME) y las mejores prcticas de
integracin de los modelos de madurez y capacidades para desarrollo (CMMI-DEV) es
completamente factible y se puede comprobar mediante trabajos previamente realizados.
El estudio comparativo parte del anlisis de la semntica [15] y de la aplicacin entre los
R

modelos de CMMI y SPEM, evaluando la correlacin entre ambos modelos, e incorpora
en esta comparacin el estndar BPMN 2.0 realizada por [16]. El aporte de estos artculos
R

se resume en cuanto a que el modelo de CMMI se centra en la parte estructural del
proceso, mientras que SPEM contiene una mayor representatividad del modelado de los
procesos con un mayor grado de concrecin. BPMN, por su parte, tiene como objetivo
la integracin de los procesos organizativos, adems de su ms fcil comprensin.
Los trabajos se han centrado en realizar un anlisis semntico y de la aplicacin entre
CMMI-DEV 2.0 y SPEM 2.0. Sin embargo, el propsito de la presente investigacin
pretende realizar un estudio ms detallado que establezca la comparacin entre CMMI-
DEV y MOSKitt4ME. Para ello, [17] analiz las buenas prcticas descritas por MDD
propuestas en la literatura y se bas en ellas para realizar la evaluacin, determinando si
brindan el soporte a las prcticas especcas por CMMI-DEV v1.3 del nivel de madurez
2, cuales son las reas denidas y el grado de soporte. Su anlisis y evaluacin llegaron
slo hasta el nivel de madurez 2 de CMMI-DEV v1.3.
A pesar de que no se utilizarn modelos intermedios, ni mejores prcticas como en los
trabajos anteriormente mencionados, se ha demostrado que puede existir una clara rela-
cin entre las mejores prcticas de CMMI-DEV y los estndares de SPEM 2.0 y BPMN
2.0 (en donde MOSKitt4ME se fundamenta en estos estndares).
A lo largo de los siguientes captulos, se realizar la comparacin entre el marco metodo-
lgico para construir mtodos de desarrollo de software y los modelos de integracin de
madurez y de capacidades para el desarrollo, para poder determinar el grado de imple-
mentacin de las prcticas especcas de los niveles de madurez 2 y 3. A continuacin, se
realizarn unas propuestas factibles que permitan la integracin del marco metodolgico
con las mejores prcticas en los niveles de madurez 2 y 3.

Captulo 3
Comparacin de CMMI Vs
MOSKitt4ME - Nivel de Madurez 2
R

En el nivel de madurez 2 de CMMI para desarrollo en la versin 1.3 (CMMI-DEV),
los proyectos deben ser gestionados y controlados. En este nivel, se debe garantizar para
la ejecucin en los proyectos que los procesos sean: planicados, ejecutados de acuerdo
con las polticas, monitorizados, controlados y revisados.
A continuacin, se realizar una comparacin de las reas de procesos del nivel de ma-
R

durez 2 de CMMI para desarrollo en su versin 1.3 (CMMI-DEV), con el marco me-
todolgico para la construccin de mtodos de produccin de software, determinando
de esta manera si las prcticas especcas de las reas de procesos que se analizan son
implementadas en MOSKitt4ME o no.
3.1. Gestin de acuerdos con proveedores (SAM)
El propsito del rea de gestin de acuerdos con proveedores es gestionar la adquisicin
de productos y servicios con los proveedores, implicando actividades como: determinar el
tipo de adquisicin, seleccionando, manteniendo y ejecutando acuerdos con los proveedo-
res, aceptar y asegurar la entrega satisfactoria de los productos adquiridos; un ejemplo
de los mismos son los subsistemas.
Se dice que el rea de proceso no es aplicable por MOSKitt4ME, debido a que no con-
templa la adquisicin de productos, servicios, componentes de productos o servicios que
puedan ser adquiridos y gestionados a travs de proveedores.
Valoracin: No aplicable.
27
Captulo 3. Comparacin de CMMI Vs MOSKitt4ME - Nivel de Madurez 2 28
3.2. Gestin de requisitos (REQM)
El rea de gestin de requisitos (ver denicin A.3) tiene como propsito gestionar los
requisitos y componentes de los productos del proyecto. De esta manera se asegura la
alineacin entre los requisitos, los planes y los productos de trabajo del proyecto.
3.2.1. SG 1 Gestionar los requisitos
La gestin de requisitos son procesos que realizan la identicacin, asignacin, validacin
y modicacin de los requisitos. Tambin se encarga de identicar las inconsistencias con
los planes y los productos de trabajo.
3.2.1.1. SP 1.1 Comprender los requisitos
Esta prctica especca se basa en analizar los requisitos para asegurar que se alcanza
una comprensin compatible y compartida del signicado de los requisitos, a medida que
maduran los proyectos. Los resultados de estos anlisis y dilogos son un conjunto de
requisitos aprobados.
En MOSKitt4ME, se puede hacer uso de la primitiva disciplinas (Disciplines ) para cate-
gorizar
1 las tareas y as establecer un conjunto de tareas dedicadas a la comprensin de
los requisitos. Las disciplinas tienen un objetivo en comn dentro del proyecto completo.
En la medida que el proyecto se desarrolla todos los requisitos se han de ir incorporando
a esta categora que se ha denido, para su posterior anlisis y comprensin.
Valoracin: Completamente implementada.
3.2.1.2. SP 1.2 Obtener el compromiso sobre los requisitos
La prctica especca indica que los participantes involucrados se comprometen con el
cumplimiento de los acuerdos y compromisos, lo cual implica llevar a cabo los requisitos
actuales y aprobados.
En MOSKitt4ME, no es posible de certicar los acuerdos entre los roles (que represen-
taran las participantes involucradas), en un principio porque no se puede determinar
cundo cambian los requisitos y cundo se produce un nuevo requisito o llevan una do-
cumentacin de los cambios. Por ende, no se puede evaluar el impacto de los nuevos
requisitos sobre los compromisos de los requisitos ya existentes.
1
Las disciplinas son un tipo predenidos de categoras
Valoracin: No implementada.
3.2.1.3. SP 1.3 Gestionar los cambios a los requisitos
La gestin de cambios a los requisitos consiste en almacenar y documentar de forma
eciente y ecaz todas las posibles modicaciones que puedan ocurrir a lo largo del
trabajo en cuanto a los requisitos existentes. Para determinar el impacto de los cambios
es necesario saber la fuente de los requisitos, documentando la razn de cualquier cambio
que llegue a ocurrir en los requisitos.
A travs de MOSKitt4ME no es posible realizar el proceso de gestin de cambios, debido
a que no mantiene un histrico, ni documentacin de las posibles variaciones que puedan
suceder en los requisitos a lo largo del proyecto.
3.2.1.4. SP 1.4 Mantener la trazabilidad bidireccional de los requisitos
La prctica especca permite comprobar la completitud de los requisitos, al determinar
la asociacin que se pueda establecer claramente entre los requisitos de los diferentes
niveles inferiores o superiores. La trazabilidad bidireccional se utiliza para los sistemas de
seguimiento de requisito fuente hasta sus requisitos de ms bajo nivel y viceversa (como
tambin las relaciones a otras entidades, por ejemplo productos de trabajo intermedios
y nales).
SPEM 2.0 posee un elemento del mtodo denominado variabilidad (Variability ) que per-
mite denir ciertos tipos de diferencias con el respecto al elemento original. Aplicando el
plugin o no permite incluir o remover estas capacidades de variabilidad en los elementos.
Entre los tipos de variabilidad se encuentra la contribucin (Contribution ) que le aporta
con sus propiedades al elemento base sin alterar directamente ninguna de las propieda-
des ya existentes, es decir, solo aade propiedades. Este tipo de variabilidad se puede
utilizar para crear la trazabilidad bidireccional al aadir propiedades que le permitan
ver la asociacin que existen entre los elementos, ya que puede ser creado entre los roles,
tareas o productos de trabajo. Por ende, si se denen los requisitos como un grupo de
tareas categorizadas, se puede aplicar esta primitiva.

3.2.1.5. SP 1.5 Asegurar el alineamiento entre el trabajo del proyecto y los

requisitos
La prctica especca consiste en determinar las inconsistencias e iniciar las acciones
correctivas que ocurran entre: los requisitos, los planes del proyecto y los productos de
trabajo.
En SPEM 2.0, al contar entre sus caractersticas con la variabilidad de los elementos
de contenidos, especcamente la contribucin, por consecuencia, la trazabilidad bidirec-
cional de los requisitos, se puede determinar si existe inconsistencia entre los requisitos
haciendo un seguimiento y control. Adicionalmente, en la fase de implementacin del
mtodo, al vericar los resultados, se puede determinar si los requerimientos concuer-
dan con lo planicado. Sin embargo, al aplicar las acciones correctivas en MOSKitt4ME,
implicara volver a implementar el mtodo en esta fase.
3.3. Monitorizacin y control del proyecto (PMC)
La monitorizacin y control del proyecto proporcionan ayudan para determinar el pro-
greso del proyecto, evaluando las posibles variaciones que puedan ocurrir y que desven
de forma signicativa el plan global del proyecto. Esta monitorizacin servir para poder
tomar las acciones correctivas que se consideren apropiadas.
3.3.1. SG 1 Monitorizar el proyecto frente al plan
La meta especca se encarga de monitorizar el progreso y el avance real del proyecto
frente al plan de proyecto.
3.3.1.1. SP 1.1 Monitorizar los parmetros de planicacin del proyecto
La prctica especca indica los siguientes puntos: los parmetros de planicacin del
proyecto que constituyen los indicadores tpicos del progreso y del rendimiento del pro-
yecto y, tambin, incluyen atributos de los productos de trabajo, de las tareas, del coste,
del esfuerzo y del calendario. A parte de esto, los atributos de los productos de trabajo,
incluyendo el tamao, la complejidad, el nivel de servicio, la disponibilidad, el peso, la
forma, el ajuste, la funcin y, nalmente, la frecuencia de monitorizacin de los par-
metros. Se deben comparar los valores reales de los parmetros con la planicacin del
proyecto para as determinar las posibles variaciones que puedan ocurrir.

Existen ciertos parmetros que se pueden monitorizar en MOSKitt4ME - como es el
caso del rendimiento del proyecto - a travs de la revisin peridica del avance de las
actividades e hitos. Dicho rendimiento del proyecto se puede visualizar mediante la apli-
cacin del mtodo, en el ambiente CASE. Los dems parmetros no estn contemplados
en MOSKitt4ME, por lo tanto, no se puede llevar a cabo una monitorizacin completa
de la planicacin del proyecto.
Valoracin: Parcialmente implementada.
3.3.1.2. SP 1.2 Monitorizar los compromisos
La monitorizacin de los compromisos debe realizar en relacin con las obligaciones que
han sido identicadas en el plan del proyecto, efectuando una revisin, identicacin y
documentacin de los compromisos internos y externos.
Al desarrollar el contenido de mtodo en MOSKitt4ME, se denen las tareas. El con-
tenido de mtodo son los compromisos. Entonces, es posible realizar la monitorizacin
del cumplimiento de las tareas, ya que ellas representan las porciones ms pequeas del
trabajo en un modelo de proceso. Al realizar la implementacin del mtodo y generarse
el CASE, se puede ver claramente, en qu fase o etapa se encuentra la ejecucin de las
tareas.
3.3.1.3. SP 1.3 Monitorizar los riesgos del proyecto
Al igual que los compromisos, los riesgos que se han identicado se deben monitorizar
en relacin con el plan de proyecto.
El mtodo para construir mtodos de desarrollo de software (MOSKitt4ME) no contem-
pla el manejo de los riesgos que consiste en la vericacin del comportamiento de los
mismos, es decir, la comunicacin del cambio de probabilidad que suceda y del cambio
de prioridad de los riesgos.
3.3.1.4. SP 1.4 Monitorizar la gestin de los datos
Dependiendo de los cambios de requisitos y del estado del proyecto, ser necesaria o no la
replanicacin de los datos del proyecto. Razn por la cual se requiere la monitorizacin
de los datos para lograr una correcta gestin de los mismos.

Para ello, MOSKitt4ME cuenta con los llamados artefactos, los cuales son de naturaleza
tangible. Un ejemplo de los artefactos son los modelos, documentos, cdigos, archivos,
etc. stos representan los datos y pueden determinar si se han ejecutado de forma satis-
factoria, al ejecutarse los productos de trabajo a los cuales los artefactos se encuentran
asociados. Cumpliendo as con la prctica especca de monitorizar la gestin de los da-
tos del proyecto frente al plan de proyecto, en la fase de implementacin del mtodo.
3.3.1.5. SP 1.5 Monitorizar la involucracin de las partes interesadas
La prctica especca se pide la comprobacin de las partes interesadas frente al plan de
proyecto. En SPEM 2.0 las partes interesadas representaran los roles que se encuentran
asociados a las tareas; los mismos se denen como un conjunto de habilidades, compe-
tencias y responsabilidades relacionadas de un individuo o de un grupo. El proceso de
monitorizacin y control de las partes interesadas y su participacin en el proyecto se
pueden llevar a cabo mediante la implementacin del mtodo, en la vista de proceso al
seleccionar un rol especco, vericando si se ha realizado la tarea.
3.3.1.6. SP 1.6 Llevar a cabo las revisiones del progreso
Para determinar el progreso de los proyectos, se requiere saber en un momento deter-
minado el estado de los mismos, con el propsito de mantener informadas a las partes
interesadas.
En MOSKitt4ME, se consigue una representacin ejecutable del proceso del mtodo
mediante la transformacin del diseo del mtodo a un conjunto de procesos, usando para
ello el estndar de BPMN 2.0. En las vistas de procesos, generadas en la transformacin,
es posible observar las tareas que han sido ejecutadas y, por ende, el estado actual de los
procesos.
3.3.1.7. SP 1.7 Llevar a cabo las revisiones de hitos
Los hitos son eventos planicados con antelacin, y son revisiones formales del estado
del proyecto que se realizan de forma minuciosa y detallada. El propsito es comprender
cmo y si se estn cumpliendo los requisitos planicados.

Debido a que se pueden denir en SPEM 2.0 - estndar en el que se basa MOSKitt4ME -
los hitos de trabajo como los llamados Milestones que representan un evento signica-
tivo para el desarrollo de un proyecto. Cumpliendo el mismo objetivo para CMMI-DEV
como para SPEM 2.0.
3.3.2. SG 2 Gestionar las acciones correctivas hasta su cierre
El propsito de la meta especca es gestionar las acciones correctivas ante posibles
desviaciones del plan, recopilando y analizando las posibles acciones que se deben tomar,
efectuando las acciones correctivas para luego determinar si stas han sido efectivas para
corregir las desviaciones del plan.
El mtodo de desarrollo del software permite realizar la monitorizacin del proyecto, sin
embargo, no permite determinar si han existido desviaciones del plan, ya que no mantiene
un histrico u otro medio que indique que haya existido una desviacin del plan.
3.4. Planicacin del proyecto (PP)
La planicacin del proyecto consiste en establecer los planes necesarios para llevar a
cabo las tareas o actividades que se requieren a lo largo de los proyectos.
Para que todo proyecto tenga xito, se debe: desarrollar el plan de proyecto, interactuar
con las partes interesadas de forma apropiadas, obtener el compromiso del plan y por
ltimo mantener el plan.
3.4.1. SG 1 Establecer las estimaciones
Los parmetros de planicacin de proyecto deben ser establecidos y mantenidos. Con
el propsito mantener toda la informacin necesaria que el proyecto necesite para su
planicacin y organizacin, en la medida que el proyecto se ejecute.
3.4.1.1. SP 1.1 Estimar el alcance del proyecto
La estimacin del alcance del proyecto implica que se debe establecer la estructura de
descomposicin del trabajo (WBS; Work Breakdown Structure ) de alto nivel. La WBS
ofrece un esquema para la identicacin, organizacin y gestin de estos paquetes de
trabajo que resultan de la descomposicin mencionada.
La WBS para MOSKitt4ME representa los procesos (Processes ). En SPEM 2.0, se en-
cuentran dos etapas en la denicin del mtodo (Method Library ). Primero se denen
los constructores bsicos en el contenido de mtodo, por ejemplo los roles, las tareas, los
productos de trabajo, las guas, etc. Segundo, se combinan y se reutilizan estos construc-
tores bsicos para ensamblar las actividades y los procesos. Los patrones ensamblados de
procesos ayudan a dividir el proyecto global en un conjunto de componentes manejables
que estn interconectados, como es el caso de las tareas o los productos de trabajo.
3.4.1.2. SP 1.2 Establecer las estimaciones de los atributos de los productos

de trabajo y de las tareas
El atributo tamao es una de las entradas principales para realizar las estimaciones de
los modelos y, con base en el tamao, se le asigna a los productos de trabajo y a las tareas
un nivel relativo de dicultad y complejidad. El atributo tamao se utiliza tambin para
estimar el costo y el calendario del proyecto, as como el nivel de servicio, la conectividad,
la disponibilidad y la estructura.
En esta prctica especca se dice que es ampliamente implementada, debido a que en
SPEM 2.0 existe el elemento de desglose de trabajo (Work Breakdown Element ) que es el
tipo de elemento principal ya que representa la descomposicin del trabajo. El elemento
de desglose de trabajo posee dos tipos, que son las actividades y los hitos. Entre las
propiedades comunes de las actividades y los hitos estn:
Se pueden repetir: existen varias iteraciones
Son continuos: son trabajos sin duracin ja
Poseen condiciones de sucesos: el inicio es determinado por un evento en especial
Adicionalmente, SPEM 2.0 posee el elemento del mtodo llamado gua que provee in-
formacin adicional relacionada con otros elementos. Para la estimacin de mtricas y
medidas existe una gua llamada mtrica para la estimacin (Estimating Metric ) que se
usa comnmente para calcular el tamao del esfuerzo, as como el mejor potencial de
trabajo.
Estas primitivas determinan el atributo tamao y, por ende, ayudan a identicar la
dicultad, la calidad, el nivel de servicio y la complejidad de los productos de trabajo y
de las tareas.
Sin embargo, en MOSKitt4ME, al no contar con las primitivas de costos y tiempos no
se permite establecer completamente las estimaciones de los atributos de los productos
de trabajo y de las tareas de la prctica especca.
Valoracin: Ampliamente implementada.
3.4.1.3. SP 1.3 Denir las fases del ciclo de vida del proyecto
Las fases del ciclo de vida de un proyecto se denen con el objetivo de proporcionar
ciertos periodos planicados de revisiones o evaluaciones de los proyectos. Por lo general,
son puntos lgicos de decisin, facilitando la oportunidad de tomar acciones correctivas
de existir algn debi del plan original.
Dado que en SPEM 2.0 se pueden utilizar la primitiva fase (Phase ) proporcionada por s-
te estndar para denir un periodo de tiempo representativo en un proyecto, nalizando
generalmente con grupo importante de entregables concluidos o hito. Debido a ste com-
ponente que posee MOSKitt4ME se puede concluir que es perfectamente implementada
esta prctica especca.
3.4.1.4. SP 1.4 Estimar el esfuerzo y el coste
Las estimaciones de esfuerzo y costo se basan en los resultados de anlisis de modelos o
datos histricos aplicados al tamao y a las actividades.
Dos atributos importantes que MOSKitt4ME no maneja son los datos histricos y los
costos.
3.4.2. SG 2 Desarrollar un plan de proyecto
La base de la planicacin de un proyecto es plan de proyecto, el cual consiste en los
requisitos y las estimaciones establecidas considerando todas las fases del ciclo de vida de
los proyectos, para ello se debe establecer y mantener un documento formal y aprobado.
3.4.2.1. SP 2.1 Establecer el presupuesto y el calendario
La prctica especca consiste en constituir y mantener el presupuesto y el calendario
del proyecto. El presupuesto y el calendario se deben basar en las estimaciones que se
han desarrollado previamente, con una correcta asignacin de recursos, una adecuada
complejidad y dependencia en las tareas.
A pesar de poder denir en el mtodo la complejidad de las tareas y las dependencias
entre las mismas mediante la secuencias de trabajo, no es posible denir las estimaciones
de un presupuesto ni el calendario del proyecto mediante MOSKitt4ME.
3.4.2.2. SP 2.2 Identicar los riesgos del proyecto
Implica identicar los asuntos potenciales, posibles peligros, amenazas, vulnerabilidades,
entre otros que afecten de forma negativa el correcto desenvolvimiento de los planes
del proyecto. Los riesgos se descubren y se analizan para dar soporte a la planicacin,
modicando los riesgos que sean necesarios.
En MOSKitt4ME no es posible realizar la identicacin, el anlisis, determinar el im-
pacto, la probabilidad de ocurrencia y la priorizacin de los riesgos.
3.4.2.3. SP 2.3 Planicar la gestin de los datos
Los datos son las diferentes documentaciones que posee un proyecto que sirven para
darles soporte en todas sus reas y podrn ser entregables o no entregables.
Para MOSKitt4ME, los datos se representan como los productos de trabajo (Work Pro-
duct Denition ), los cuales pueden ser producidos, consumidos o modicados por las
tareas. Por lo tanto, pueden ser perfectamente planicados para su gestin.
Valoracin: Completamente implementada
3.4.2.4. SP 2.4 Planicar los recursos del proyecto
Los recursos del proyecto se denen como los materiales, talento humano, equipamiento,
mtodos, etc. Se basan en estimaciones iniciales, proporcionando informacin adicional
para extender la estructura de descomposicin de trabajo (WBS ). La WBS se apoya en

actividades o productos de trabajo, tareas o una combinacin de estos elementos y va
acompaada de diccionarios que describen el contenido del trabajo que realiza la WBS,
as como diagramas de procesos e informes de estado.
La prctica especca, llamada planicar los recursos del proyecto, se cumple en MOS-
Kitt4ME mediante la siguiente relacin:
La estructura de descomposicin de trabajo (WBS ) est representada en SPEM
2.0 por los elementos de desglose de trabajo (Work Breakdown Element )
Los diccionarios describen el contenido del trabajo que realiza la WBS a travs
de las guas (Guidance ), especcamente por el tipo de gua denominado concepto
(Concept )
El estndar de BPMN 2.0 proporciona los diagramas de procesos y permite ver por
completo la planicacin de los recursos
Los informes de estado mediante las guas, en especial con el tipo de gua llamada
informe (Report )
3.4.2.5. SP 2.5 Planicar el conocimiento y las habilidades necesarias
En esta prctica especca se requiere planicar las necesidades de conocimiento y de
habilidades para realizar el proyecto; para ello se requiere poseer inventario de las habi-
lidades necesarias, bases de datos con las habilidades y los planes de formacin.
En un principio, MOSKitt4ME es desarrollado por los profesionales ms experimentados,
como el ingeniero del mtodo, quien analiza los requerimientos del mismo y genera los
mtodos de especicacin del proyecto, adems de ser un experto del dominio. En segundo
lugar, SPEM 2.0 posee las primitivas en los roles y las tareas como son las cualicaciones,
habilidades o competencias que permiten incorporar bien sea en las tareas o en los roles
los conocimientos requeridos para realizar una actividad en particular. Lo que no posee
MOSKitt4ME es el desarrollo de los planes de formacin.
3.4.2.6. SP 2.6 Planicar la involucracin de las partes interesadas
Para determinar las partes interesadas e identicarlas en las fases del ciclo de vida del
proyecto, determinando las funciones, su grado de importancia y el grado de interaccin

existe la denicin de los roles (Role Denition ) en MOSKitt4ME, los cuales se denen
como un conjunto de habilidades, competencias y responsabilidades relacionadas de un
individuo o de un grupo. Y la matriz bidimensional, planteada por la prctica especca,
se puede denir en las llamadas tareas (Tasks ) donde se describe la unidad atmica de
trabajo para los procesos, afectando a unos pocos productos de trabajo y vinculando a
unos pocos roles.
3.4.2.7. SP 2.7 Establecer el plan de proyecto
El plan de proyecto permite una comprensin del plan general a todas las personas u
organizaciones involucradas para dar soporte al plan. Por ello, se requiere un documento
que posea todos los componentes relevantes de la planicacin.
Para la comprensin del plan general se puede utilizar la vista consolidada (Consolidated
View ), que proporciona el editor de EPF Composer que es el editor de SPEM 2.0, y
que est integrada en MOSKitt4ME. Esta vista posee la informacin del desglose de las
actividades e hitos, los roles y los productos de trabajo.
3.4.3. SG 3 Obtener el compromiso con el plan
Las prcticas especcas requieren que en la planicacin del proyecto las personas res-
ponsables adquieran el compromiso para que sean implementadas y den el soporte al
plan.
El mtodo de desarrollo de software no permite llevar un control de las posibles modi-
caciones que se puedan producir, o de los presupuestos que se negocien como resultado
de los compromisos realizados.
3.5. Aseguramiento de la calidad del proceso y del producto

(PPQA)
El rea de aseguramiento de calidad del proceso y del producto tiene como objetivo
ofrecer y dar soporte a la entrega de productos de alta calidad. Proporcionando a las

personas involucradas del proyecto, la visibilidad idnea sobre los procesos y los productos
de trabajo asociados, conforme a las especicaciones.
3.5.1. SG 1 Evaluar objetivamente los procesos y los productos de

trabajo
La evaluacin consiste en comparar de forma objetiva los estndares y procedimientos
contra los productos de trabajo y los procesos realizados.
3.5.1.1. SP 1.1 Evaluar objetivamente los procesos
Se debe realizar una evaluacin objetiva de los procesos que se han ejecutado en rela-
cin con la documentacin de la descripcin de los procesos y procedimientos. Para el
cumplimiento de esta prctica se recomienda realizar informes de evaluacin y de no
conformidad y, de ser preciso, tomar las acciones correctivas.
En MOSKitt4ME, se puede realizar la evaluacin objetiva de los procesos y procedimien-
tos una vez ejecutada la tarea. Debido a que la informacin se encuentra documentada
en la pestaa que contiene los avances (Preview ), los procesos de despliegue (Delivery
Process ), los patrones de procesos (Capability Pattern s), el desglose de las estructuras
de trabajo o incluso los diagramas de procesos de BPMN 2.0, es posible visualizar la
descripcin de los procesos. Al contar con la documentacin de los procesos se puede
realizar la evaluacin y, en el caso de no conformidad, tomar las acciones correctivas. Sin
embargo, no es posible mediante MOSKitt4ME de establecer los criterios de evaluacin
de los procesos.
3.5.1.2. SP 1.2 Evaluar objetivamente los productos de trabajo
Se debe evaluar objetivamente los productos de trabajo seleccionados frente a las des-
cripciones de proceso, estndares y procedimientos aplicables.
MOSKitt4ME al tener denidos los productos de trabajo (Work Product Denition ), de
tres tipos predenidos - artefactos (Artifact ), entregables (Deliverable ) o de resultado
(Outcome ) -, stos pueden ser evaluados de forma objetiva con las descripciones de
procesos que poseen.

3.5.2. SG 2 Proporcionar una visin objetiva
S durante la evaluacin de los estndares y procedimiento existen no conformidades se
debe seguir y comunicar de forma objetiva, asegurando su solucin.
3.5.2.1. SP 2.1 Comunicar y resolver las no conformidades
Esta prctica especca busca comunicar los problemas de calidad o las no conformidades
con el personal, que se han identicado ante la falta de conformidad con los estndares,
y propone acciones correctivas ante las posibles desviaciones.
MOSKitt4ME no posee esta funcionalidad.
3.5.2.2. SP 2.2 Establecer los registros
Se deben establecer los registros de las evaluaciones realizadas y las acciones correcti-
vas que se han tomado con el informe del estado en el cual se encuentran las medidas
correctivas tomadas y las tendencias de calidad.
Estos puntos anteriormente mencionados, se pueden extraer de MOSKitt4ME, aunque
no es posible llevar a cabo los registros de las evaluaciones, ni un control de las acciones
correctivas.
3.6. Gestin de conguracin (CM)
El rea de gestin de conguracin (ver denicin A.4) se focaliza en un control muy
estricto de los elementos de conguracin. sta rea establece y mantiene la integridad de
los productos mediante la identicacin, el control, el informe de estado y las auditoras
de la conguracin.
3.6.1. SG 1 Establecer las lneas base
Se deben crear las lneas bases (ver denicin A.3) de los productos de trabajo.
3.6.1.1. SP 1.1 Identicar los elementos de conguracin
Los elementos de conguracin pueden incluir el hardware, los activos tangibles, el soft-
ware y la documentacin o incluso los resultados de las pruebas. Un elemento de con-
guracin puede consistir en varios productos de trabajo relacionados, agrupados en
forma lgica que proporcionan facilidad de identicacin y un acceso controlado para
formar una lnea base. Para ello, se debe identicar los elementos de conguracin, los
componentes y los productos de trabajo.
En SPEM 2.0 hay un elemento denominado conguracin de mtodo (Method Congura-
tion ) permite denir vistas de una misma biblioteca de plugins, basada en las deniciones
de otras conguraciones. Permitiendo de esta manera la denicin de subconjuntos lgi-
cos de una biblioteca de mtodos, mediante la seleccin de paquetes deseados, bien sea
de contenido de mtodo como de procesos. Permitiendo de esta manera la identicacin
de los elementos de conguracin para formar una lnea base.
Valoracin:: Completamente implementada.
3.6.1.2. SP 1.2 Establecer un sistema de gestin de conguracin
La gestin de conguracin incluye en los medios de almacenamiento, procedimientos y
herramientas para acceder al sistema, y puede constar de mltiples subsistemas de acuer-
do con el entorno de la conguracin. Contando con un sistema de gestin de cambios
que den soporten a los medios de almacenamiento, los procedimientos, y herramientas.
MOSKitt4ME no dispone de primitivas para registrar y acceder a las peticiones de gestin
de cambios.
3.6.1.3. SP 1.3 Crear o liberar las lneas base
Una lnea base es un conjunto de requisitos, de diseo, cdigos fuentes, archivos de cons-
truccin y documentacin de usuario. La lnea base representa a una coleccin de ele-
mentos de conguracin que se le asigna un identicador y que representan un momento
determinado en el tiempo.
MOSKitt4ME cuenta con la coleccin de elementos de conguracin, desarrollados en
la etapa de denicin del mtodo, aunque no posee una propiedad importante que es
mantener los datos histricos o mantener un sistema de gestin de cambios, que le permita
crear o liberar las lneas bases (ver denicin A.3).

3.6.2. SG 2 Seguir y controlar los cambios
Una vez liberada la lnea base se debe seguir y controlar los productos de trabajo que se
han creado en la gestin de conguracin.
3.6.2.1. SP 2.1 Seguir las peticiones de cambio
El seguimiento de las peticiones de cambio se reere a las modicaciones, incorporaciones
de requisitos y fallos de los productos de trabajo. Las mismas sirven para medir el impacto
que tendrn dichas modicaciones de los productos de trabajo para el proyecto.
En la plataforma de Eclipse (el editor de SPEM EPF Composer) existe en los elemen-
tos de contenidos del mtodo como los roles, las tareas, los productos de trabajo, las
guas y los artefactos, en la pestaa de descripcin la informacin de la versin (Version
Information ) en ella se puede almacenar la siguiente informacin:
Versin
Fecha de cambio
Descripcin del cambio
Autores
Copyright o derechos de autor
En MOSKitt4ME, no son obligatorios ni tampoco estn presentes en los procesos. Por lo
que es posible realizar un seguimiento a las modicaciones de los elementos del mtodo,
pero no a los procesos, bien sea por fallos o nuevos requisitos que se realicen.
3.6.2.2. SP 2.2 Controlar los elementos de conguracin
La prctica especca consiste en mantener la conguracin de cada elemento de con-
guracin, controlar la lnea base, aprobar nuevas conguraciones y actualizar la lnea
base cuando se requiera.

En SPEM 2.0 mediante conguracin de mtodo, la cual permite identicar y mantener
los elementos de la conguracin, sin embargo, al no es posible crear las lneas bases,
debido a que no maneja las primitivas de tiempo ni datos histricos, por lo tanto no
se puede llevar a cabo un historial de revisiones de los elementos de conguracin ni
archivos de las lneas bases.
SG 3 Establecer la integridad.
Se debe permitir realizar las auditoras o controles de cambios de los elementos de con-
guracin.
3.6.2.3. SP 3.1 Establecer los registros de gestin de conguracin
Esta prctica especca indica que se debe establecer y dar soporte a los registros de los
elementos de la conguracin. Para ello se debe llevar un historial, registros de cambios
o solicitudes de los diferentes elementos de la conguracin.
Esta prctica especca indica que se debe establecer y dar soporte a los registros de los
elementos de la conguracin. Para ello se debe llevar un historial, registros de cambios
o solicitudes de los diferentes elementos de la conguracin.
3.6.2.4. SP 3.2 Realizar auditoras de conguracin
En MOSKitt4ME, se puede llevar a cabo un examen objetivo de un producto de traba-
jo frente a criterios especcos, como son los estndares o requisitos especicados. Por
ejemplo, mediante la comprobacin de la transformacin de modelos, para el caso de
modelo a modelo (M2M) o de modelo a texto (M2T), MOSKitt4ME pero no contempla
el proceso de evaluacin de la integridad de las lneas bases, ni la conrmacin de los
elementos completos, correctos y consistentes.
3.7. Medicin y anlisis (MA)
Las prcticas especcas del rea de proceso de medicin y anlisis consisten en deter-
minar cules son los criterios de medicin, anlisis, especicacin de medidas y tcnicas
de anlisis de recoleccin de datos, as como proveer los resultados para poder tomar las
acciones correctivas en caso de que existieran desviaciones en relacin con los requeri-
mientos de informacin.
En MOSKitt4ME, no se puede llevar a cabo estas prcticas especcas debido a que no
poseen atributos tangibles o medibles como es en el caso del tiempo, de los costos, o de
un registro de fallos o defectos, etc.
Valoracin: Sin puntaje.
3.8. Resumen
Una vez realizada la comparacin entre las reas de proceso del nivel de madurez 2 de
CMMI-DEV 1.3, con MOSKitt4ME, se puede apreciar que muchas de las prcticas espe-
ccas son implementadas a completitud, mientras que otras no han sido implementadas.
A continuacin, se resume en una tabla los resultados obtenidos.
Tabla 3.1: Resumen comparativo entre CMMI-DEV vs. MOSKitt4ME - Nivel 2
En la tabla 3.1 se realiza una sntesis cuantitativa del anlisis realizado a lo largo del
presente captulo. La tabla indica las reas de proceso, el nmero total de prcticas
especcas que son completamente implementadas, ampliamente implementadas, par-
cialmente implementadas y las no implementadas, y en la ltima columna el porcentaje
de las prcticas especcas las cuales son implementadas por MOSKitt4ME.
En cuanto al rea de proceso de gestin de acuerdos con proveedores (SAM), se puede
indicar que no es aplicable para MOSKitt4ME, debido a que dentro de los propsitos
o metas que posee el mtodo no es posible de gestionar la adquisicin de productos y
servicios con los proveedores.

En relacin a las reas de procesos de gestin de requisitos (REQM), monitorizacin y
control del proyecto (PMC), planicacin del proyecto (PP), aseguramiento de la calidad
del proceso y del producto (PPQA) y gestin de conguracin (CM), es posible realizar
mejoras al mtodo o incluso aplicar funcionalidades ya existentes de SPEM 2.0. Por lo que
estas reas de proceso se consideran insatisfechas al no ser implementas por CMMI-DEV
al 100 %.
En cuanto al rea de proceso medicin y anlisis (MA) se la considera sin puntaje, debido
a que de las ocho prcticas especcas ninguna de ellas es soporta por MOSKitt4ME. Sin
embargo, si se aplican mejoras al mtodo incorporando atributos tangibles de medicin
y anlisis, es posible que algunas prcticas especcas sean implementadas por CMMI-
DEV.
Existen conceptos y trminos que han surgido a lo largo del desarrollo de este captulo y
que se pueden resumir en este cuadro resumen; en algunos se puede ver una clara relacin
entre CMMI-DEV v1.3 y MOSKitt4ME. Si se desea ver un anlisis ms detallado se
recomienda ver las prcticas especcas descritas anteriormente.

CMMI-DEV MOSKitt4ME (SPEM 2.0/BPMN 2.0)

Comprensin de requisitos Denir requisitos como tareas; crear disciplinas
para su comprensin
Trazabilidad bidireccional Variabilidad Contribucin
Monitorizacin y control del proyecto: Se aplica en la fase de aplicacin del mtodo:
1. Progreso, rendimiento y avance de la 1. El avance de actividades e hitos

tareas
2. Artefactos, documentos, cdigos y archivos
2. Datos
3. Vistas de roles especcos
3. Involucracin de las partes interesa-
4. Vistas del mtodo de proceso
das
5. Hitos
4. Revisin del progreso
5. Revisin de hitos
Estimar atributos de productos de trabajo Mtricas para la estimacin

Fases del ciclo de vida Fases Hito
Estructuras de descomposicin de trabajo Elementos de desglose de trabajo (WBE)
(WBS)
Diccionarios Guas Concepto
Planicacin de los recursos Diagramas de procesos
Informe de estado Guas Informe
Planicar conocimientos y habilidades Cualicaciones y habilidades
Plan de proyecto Vista consolidadas
Productos de trabajo Denicin de productos de trabajo:
1. Artefactos
2. Entregables
3. Resultados
Identicar elementos de conguracin Conguracin del mtodo
Tabla 3.2: Resumen de conceptos entre CMMI-DEV vs. MOSKitt4ME - Nivel 2

Captulo 4
Comparacin de CMMI Vs
MOSKitt4ME - Nivel de Madurez 3
En el nivel de madurez 3 de integracin de modelos de madurez y capacidades de desa-
rrollo (CMMI-DEV) en la versin 1.3, los procesos estn denidos, por lo que estn
debidamente establecidos y documentados, basados en propsitos claramente constitui-
dos para el logro de sus objetivos.
A continuacin, se realizar una comparacin entre el nivel de madurez 3 de CMMI-DEV
1.3 y el marco metodolgico para la construccin de mtodos de produccin de software,
con el propsito de determinar el grado de implementacin de las prcticas especcas
con respecto a MOSKitt4ME.
4.1. Denicin de procesos de la organizacin (OPD)
El rea de proceso de denicin de procesos de la organizacin gestiona el conjunto
reutilizable de activos de proceso, los estndares del entorno de trabajo, y las reglas y
guas para los equipos.
4.1.1. SG 1 Establecer los activos de proceso de la organizacin
Los activos de proceso de la organizacin consisten en los artefactos que contienen la
descripcin, implementacin y mejora de los procesos. La meta especca tiene como
propsito establecer y mantener este conjunto de activos de proceso de la organizacin.
47
4.1.1.1. SP 1.1 Establecer los procesos estndar
Los procesos estndar son los componentes de los procesos bsicos que existen en cual-
quier proceso denido y su relacin entre los componentes del proceso. Los procesos
estndar pueden interconectarse a una o ms arquitecturas de procesos e incluyen nor-
malmente procesos tcnicos, de gestin y organizativos.
Mediante SPEM 2.0, es posible denir los procesos estndar a travs del patrn de capa-
cidades (Capability Pattern ), al poseer las propiedades de reusabilidad y aplicabilidad en
la denicin de procesos bsicos. stas caractersticas antes mencionadas son esenciales
para denir los procesos estndar. El patrn de capacidades representa un fragmento de
proceso y puede ser reutilizado ms de una vez en los procesos de despliegue.
Adicionalmente en MOSKitt4ME, ha denido los fragmentos del mtodo que denen los
elementos atmicos con el cual el mtodo puede ser ensamblado. Estos fragmentos del
mtodo son almacenados en un repositorio del mtodo para ser reusados como activos
reutilizables. Siendo una coleccin organizada de roles, productos de trabajo, tareas,
guas y procesos y fragmentos de mtodo. El propsito es crear un repositorio de activos
reutilizables con un formato estandarizado.
4.1.1.2. SP 1.2 Establecer las descripciones de los modelos de ciclo de vida
Los modelos de ciclo de vida se utilizan comnmente para denir las fases del proyecto
y se desarrollan para diferentes situaciones o clientes, debido a que no necesariamente se
adecuan a todas las situaciones. MOSKitt4ME posee atributos que permiten especicar
aspectos transitorios para los componentes del proceso, para que luego los atributos
puedan estar asociados a los planes del proyecto. Por ejemplo, en los dos tipos especiales
de actividades llamadas fase e iteracin. La fase representa un ciclo de vida evolutivo,
debido a que es un perodo de tiempo signicativo para un proyecto, y, cuando nalice,
representa un punto de gestin importante. La iteracin representa la ejecucin de una
o varias descripciones de trabajo que se repiten ms de una vez.
4.1.1.3. SP 1.3 Establecer los criterios y las guas de adaptacin
Los criterios y las guas de adaptacin indican:

Cmo utilizar el conjunto de procesos estndar de la organizacin
Los requisitos a satisfacer los procesos denidos
Los procedimientos a seguir para documentar y realizar la adaptacin del proceso
En SPEM 2.0 existe la gua (Guidance ), un elemento del mtodo, que provee in-
formacin adicional y se relaciona con otros elementos. A manera de ejemplo, los
tipos de predenidos de guas son:
Las plantillas (Template ) que establecen tablas de contenido, secciones y formatos
estandarizados predenidos de un artefacto
La prctica (Practice ) que ayuda a denir estrategias predenidas para elaborar un
trabajo, resumiendo los aspectos importantes que impactan dentro de los procesos
La gua de herramienta (Tool Mentor ) que explica el uso de una herramienta inde-
pendiente al contexto actual de trabajo
Al contar MOSKitt4ME con estos elementos predenidos de las guas es posible establecer
los criterios y guas de adaptacin del proceso.
4.1.1.4. SP 1.4 Establecer el repositorio de mediciones de la organizacin
El repositorio posee medidas de producto y de proceso que estn relacionadas con los
procesos estndar. El repositorio posee tambin la informacin requerida para poder
comprender, evaluar e interpretar las medidas.
MOSKitt4ME utiliza el estndar RAS [18] para almacenar los fragmentos del mtodo
(los fragmentos conceptuales como las tareas, roles, productos y procesos). Las propieda-
des de estos fragmentos del mtodo son: situacin, tipo, origen y objetivo, siendo posible
determinar la medida de esfuerzo de los productos a travs de sus propiedades de re-
peticin y mltiples ocurrencias. Sin embargo, entre dichas propiedades no encontramos
el tamao de los productos de trabajo y costos (horas/personas), medidas de abilidad
o medidas de calidad, aunque son importantes ya que se utilizan frecuentemente para
realizar las mediciones en las organizaciones.

4.1.1.5. SP 1.5 Establecer la biblioteca de activos de proceso de la organi-

zacin
El diseo, los elementos elegidos y el catlogo de elementos establecen la biblioteca de
los activos de procesos de las organizaciones.
La biblioteca de los activos de proceso es posible establecerse y mantenerse en MOS-
Kitt4ME, a travs de las guas o instrucciones (Guidance ), debido a que son los elemen-
tos del mtodo que provee informacin relacionada con otros componentes. Ejemplo de
ello, son los activos reutilizable (Reusable Asset ) que proporcionan informacin sobre
el funcionamiento de los roles, cmo crear los productos de trabajo, cmo realizar las
tareas, ayudas de procesos, entre otros.
4.1.1.6. SP 1.6 Establecer los estndares del entorno de trabajo
Los estndares del entorno de trabajo permiten a las organizaciones y a los proyectos
favorecerse de las herramientas, formacin y mantenimientos comunes. El mtodo de
desarrollo de software est basado en el desarrollo dirigido por modelos, en donde MOS-
Kitt4ME es un CAME
1 que se desarroll para dar soporte a la construccin de mtodos
de produccin de software. Se fundamenta en los dos estndares SPEM 2.0 (para la cons-
truccin del mtodo, fase de diseo del mtodo) y BPMN 2.0 (en la mejora del proceso,
especcamente en la ejecucin del proceso). En la fase de implementacin del mtodo,
MOSKitt4ME provee un entorno CASE

2 (logrado mediante una transformacin M2T).
Todo esto contribuye a crear un entorno de trabajo estandarizado para las organizaciones
en la construccin de mtodos.
4.1.1.7. SP 1.7 Establecer las reglas y guas para los equipos
Quines denen y controlan cmo se debe crear e interactuar para el logro comn de los
objetivos son las guas y reglas para los equipos. Al establecer estas reglas o guas se debe
asegurar el cumplimiento de las normas, leyes o estndares que afecten su utilizacin por
los equipos. As como la denicin de los estatutos de los equipos, sus miembros, los
lderes y la asignacin de los recursos para que cada equipo cumpla con su trabajo.
1
C
omputer- A
ided M ethod E
ngineering; Ingeniera de Mtodo Asistido por Computadora
2
C
omputer- A
ided S
oftware E ngineering, Ingeniera de Software Asistida por Computadora
En SPEM 2.0 existen los elementos, llamados cualicaciones (Qualication ), que se de-
nen en los roles o las tareas. Las cualicaciones o habilidades de los roles representan
el conjunto de destrezas y capacidades que poseen en comn un grupo o individuo. Las
cualicaciones de las tareas son las destrezas requeridas para realizar una tarea en par-
ticular. Se puede denir y controlar las reglas mediante esta primitiva que posee SPEM
2.0, para el cumplimiento del trabajo.
4.2. Enfoque en procesos de la organizacin (OPF)
El rea de enfoque en procesos de la organizacin cuenta entre sus objetivos con el
plan de mejora de procesos de la organizacin. Para ello debe planicar, implementar
y ejecutar mejoras en la organizacin, tomando en cuenta sus fortalezas y debilidades
actuales, adems de los activos de procesos de la organizacin.
4.2.1. SG 1 Determinar las oportunidades de mejora de procesos
Consiste en la identicacin de forma peridica de las fortalezas, debilidades y oportu-
nidades de los procesos de la organizacin.
4.2.1.1. SP 1.1 Establecer las necesidades de proceso de la organizacin
La prctica especca indica que se debe establecer y mantener la descripcin de las
necesidades de procesos. Los objetivos, necesidades y limitaciones del negocio afectan en
forma directa a los procesos de la organizacin determinando sus objetivos y necesidades.
Dentro del entorno del negocio que afecta a los procesos se puede mencionar la satisfaccin
del cliente, de las nanzas, la tecnologa y los recursos humanos.
MOSKitt4ME contribuye a los procesos de la organizacin, dado que permite a los inge-
nieros de mtodos crear mtodos de desarrollo de software, incidiendo directamente en
la tecnologa de la organizacin y, por consecuencia, en sus nanzas.

4.2.1.2. SP 1.2 Evaluar los procesos de la organizacin
La evaluacin de los procesos se debe realizar de forma peridica, manteniendo una
comprensin de sus fortalezas y debilidades. El propsito de realizar la evaluacin de los
procesos es:
Identicar las mejoras de procesos
Conrmar el progreso a los benecios de las mejoras
Satisfacer las necesidades de una relacin Cliente-Proveedor
Motivar y facilitar que se involucren los procesos
En MOSKitt4ME, no se realiza una evaluacin de los procesos de forma peridica.
4.2.1.3. SP 1.3 Identicar las mejoras de procesos de la organizacin
Esta prctica especca requiere realizar un anlisis e identicacin de las mejoras a los
procesos en la organizacin. Para el logro de dichas mejoras se debe determinar, identi-
car, priorizar y documentar las mejoras en los procesos candidatos que se implementarn.
En SPEM 2.0, los procesos organizativos se relacionan con los procesos de despliegue (De-
livery Process ) ayudando para la identicacin de mejoras de los procesos. Sin embargo,
la categorizacin y la priorizacin dependern de las polticas de la empresa.
4.2.1.4. SG 2 Planicar e implementar las acciones de proceso
La meta especca, en primer lugar, establece los planes de accin de proceso, los cuales
consisten en mejorar los procesos y los activos de procesos. Al involucrar a las partes
interesadas y obtener el compromiso en las mejoras de proceso se incrementa la probabi-
lidad de un desarrollo ecaz. Y en segundo lugar, implementa el establecimiento de los
planes de accin de proceso.
En MOSKitt4ME, no se contempla el manejo de los planes de accin, debido a que no se
realizan evaluaciones que permitan descubrir las debilidades y, por ende, no se pueden
mejorar mediante la implementacin de los planes de accin.
4.2.2. SG 3 Desplegar los activos de proceso de la organizacin e in-

corporar las experiencias
La meta especca tiene como propsito expandir e incorporar las experiencias adquiridas
a los activos de procesos en toda la organizacin.
4.2.2.1. SP 3.1 Desplegar los activos de proceso de la organizacin
Se debe garantizar el despliegue de los activos de proceso de forma organizada y su
incorporacin (segn sea necesario) en algunas reas de la organizacin.
En MOSKitt4ME, al contar con procesos estndar, modelos de ciclos de vida, criterios
y guas de adaptacin, bibliotecas de activos y estar basado en estndares como los
Procesos de Ingeniera de Software (SPEM 2.0) y Modelado y Notacin de Procesos
de Negocios (BPMN 2.0), se garantizan los materiales de formacin de despliegue y los
materiales de soporte de los activos de procesos. No obstante, en dicho mtodo no estn
contempladas la planicacin del despliegue o la documentacin de los cambios de los
activos de procesos.
4.2.2.2. SP 3.2 Desplegar los procesos estndar
Los procesos estndar no slo consisten en crearlos y desplegarlos, sino que deben ser
actualizados de acuerdo con los cambios que puedan surgir durante el transcurso de vida
de los proyectos. Estos procesos estndar deben ser adaptados y, con el transcurrir del
tiempo, han de ser cada vez ms ecaces, sobre todo en las actividades ms crticas de
los procesos.
En MOSKitt4ME, al denirse los procesos estndar mediante el patrn de capacidad,
estos bien podran ser adaptados, modicados o servir de base para crear unos patrones
de capacidad, y as incluir los benecios de los otros proyectos aprendidos.
4.2.2.3. SP 3.3 Monitorizar la implementacin
Para determinar si los activos de procesos se adecuan y se acoplan a los proyectos, se
requiere monitorizar la implementacin y determinar cules son los activos de procesos
que se estn manejando y en dnde, dentro de la organizacin.

En MOSKitt4ME, una vez generado el ambiente CASE de forma automtica - en la vista
de proceso -, es posible realizar la monitorizacin, para un momento determinado, de los
activos de procesos, siempre que se encuentren involucrados a los procesos que se estn
monitorizando. Mediante MOSKitt4ME, es factible cumplir con la prctica especca de
monitorizar la implementacin de los activos de procesos.
4.2.2.4. SP 3.4 Incorporar las experiencias en los activos de proceso de la

organizacin
Los resultados que se han obtenido de la planicacin y ejecucin del proceso en cuanto
a las experiencias concernientes al proceso se deben incorporar a los activos de procesos.
Adems, se debe registrar las actividades de mejoras de los procesos en la organizacin.
Para el cumplimiento de esta prctica especca sera necesario que MOSKitt4ME cumpla
con:
Contar con revisiones peridicas
Obtener retroalimentacin
Listar y poner en prctica las lecciones aprendidas
Contar con registros histricos de las actividades de los procesos
4.3. Formacin en la organizacin (OT)
El propsito de las prcticas especcas concernientes al rea de formacin en la or-
ganizacin consiste en aumentar las habilidades y destrezas de las personas para que
puedan efectuar sus roles de una forma ecaz y ecientemente durante los proyectos. En
su primera etapa, se debe establecer lo siguiente:
Las necesidades estratgicas de formacin
Cules son las necesidades de formacin que dependen de la organizacin
El plan de formacin tctico

La capacidad de formacin
Como ltima etapa, impartir, establecer los registros y evaluar la formacin de forma
ecaz.
El rea de procesos de formacin en la organizacin se considera no aplicable para MOS-
Kitt4ME, debido a que el mtodo no fue creado con propsitos formativos o de entrena-
miento.
4.4. Gestin de riesgos (RSKM)
El rea de gestin de riesgos implica reconocer los problemas ms transcendentes y que
pueden inuir de forma signicativa en el transcurso de la ejecucin de los proyectos,
con el propsito de mitigar el impacto que puedan tener, para lograr los objetivos del
proceso.
En MOSKitt4ME, no se realizan las siguientes prcticas especcas:
Determinar las fuentes y las categoras de riesgos
Denir los parmetros
Establecer una estrategia de gestin de riesgos
Identicar, evaluar, clasicar y priorizar los riesgos
Desarrollar los planes de mitigacin de riesgo e implementarlos
Valoracin: Sin puntaje.
4.5. Gestin integrada del proyecto (IPM)
El rea de gestin integrada del proyecto tiene como objetivo la creacin y gestin de
los proyectos. Optimiza los recursos necesarios, alcanza el nivel de eciencia y el nivel
de ecacia de los benecios previstos, contando para ello con un conjunto de procesos
estndar denidos en la organizacin.

4.5.1. SG 1 Utilizar el proceso denido del proyecto
Mediante los procesos denidos se llevan a cabo los proyectos. Los procesos denidos -
basados en los procesos estndar - tratan todos aquellos mtodos necesarios para adquirir,
desarrollar y mantener el producto.
4.5.1.1. SP 1.1 Establecer el proceso denido del proyecto
Lo procesos denidos se basan en los requisitos de las partes interesadas, los compromisos
y las necesidades de la organizacin, los procesos estndar, las guas de adaptacin de
la organizacin, as como su entorno operacional y de negocio. Por lo tanto, los procesos
denidos se deben instaurar desde la fase de inicio de vida de los proyectos, como a lo largo
de los mismos y deben estar integrados de forma coherente. Los procesos denidos traen
como benecios los planes del proyecto y permiten instaurar ecientemente el conjunto
inicial de requisitos.
Se relacionan los procesos denidos con MOSKitt4ME mediante el proceso de despliegue
(Delivery Process) que sirven de plantilla en la planicacin y ejecucin de los proyectos,
abarcando un ciclo de vida integrado y completo. Los patrones de capacidades (asociados
como procesos estndar) estn acoplados a un proceso de despliegue, permitiendo de
esta manera adaptar los procesos estndar para que se ajusten a las necesidades de los
proyectos mediante el proceso denido (ver seccin 4.1 SP 1.1 Establecer los procesos
estndar).
4.5.1.2. SP 1.2 Utilizar los activos de proceso de la organizacin para plani-

car las actividades del proyecto
Los resultados de las mediciones y los activos de procesos son utilizados para estimar los
parmetros de planicacin y evaluar las actividades del proyecto respectivamente.
En MOSKitt4ME, es posible utilizar los procesos de la organizacin para estimar las ac-
tividades del proyecto o estimar los parmetros de planicacin, a travs de los elementos
de desglose de trabajo (Work Breakdown Element) mediante:
Las guas
La denicin de fases e iteraciones
Algunos parmetros de planicacin como la medicin del esfuerzo

Lo que no se puede estimar con el mtodo son los parmetros de medicin para la plani-
cacin del proyecto; por ejemplo: datos vlidos histricos del proyecto, costo, calendario.
4.5.1.3. SP 1.3 Establecer el entorno de trabajo del proyecto
El entorno de trabajo se fundamenta en las instalaciones, las herramientas y los equipos
que requieren las personas para el cumplimiento correcto de los objetivos del proyecto.
Para que pueda existir un mantenimiento y establecimiento del ambiente de trabajo
idneo, dicho ambiente se debe basar en los estndares del entorno de trabajo.
En primer lugar, MOSKitt4ME se desarroll con base en el resultado de un marco me-
todolgico que combinaba las tcnicas de ingeniera de mtodos y el desarrollo dirigido
por modelos bajo un entorno de ECLIPSE. En segundo lugar, MOSKitt4ME utiliza una
serie de estndares ya preestablecidos - con base en SPEM 2.0 y BPMN 2.0 - para que
los ingenieros de mtodos puedan disear e implementar mtodos para el desarrollo de
software, permitiendo de esta manera establecer un entorno de trabajo adecuado para el
desarrollo del proyecto.
4.5.1.4. SP 1.4 Integrar los planes
Los planes del proyecto se deben integrar a los otros planes que inuyen en los proyec-
tos y que describen los procesos denidos. Los otros planes se pueden considerar como
las actividades adicionales de la planicacin, como por ejemplo coordinar las partes
interesadas relevantes, incorporar el proceso denido, establecer los criterios de entrada
y salida de las tareas.
Los planes adicionales que se requieran en la planicacin de los proyectos a travs de los
elementos de desglose de trabajo (Work Breakdown Element ), relacionados previamente
como procesos denidos en las prcticas especcas de CMMI-DEV, pueden integrarse
con SPEM 2.0.
4.5.1.5. SP 1.5 Gestionar el proyecto utilizando planes integrados
La prctica especca tiene como objetivo gestionar el proyecto, por lo que se requieren
el proceso denido, el plan y los otros planes que afecten al proyecto.

En SPEM 2.0, al contar con los procesos de despliegue como los procesos denidos y
los planes como los elementos del desglose de trabajo, es posible realizar la gestin del
proyecto mediante los planes integrados.
4.5.1.6. SP 1.6 Establecer los equipos
Los equipos se establecen tomando en consideracin sus habilidades y experiencias, para
que en conjunto puedan alcanzar los objetivos planteados en el proyecto. En los equipos
se deben identicar las responsabilidades, los papeles que desempean en el proyecto,
siendo preciso, para poder medir y gestionar los resultados que se puedan obtener como
grupo de trabajo.
Todas estos aspectos se encuentran en SPEM 2.0 a travs de las cualicaciones de los roles
y las tareas, quienes pueden estar asociados con los productos de trabajo y las habilidades
que provee el rol. Los roles representan a un grupo o un individuo que posee un conjunto
de competencias y responsabilidades. Las tareas poseen la opcin de las cualicaciones
siendo las habilidades necesarias para desarrollar una tarea. Estas caractersticas de los
roles y de las tareas hacen factible el establecimiento de los equipos.
4.5.1.7. SP 1.7 Contribuir a los activos de proceso de la organizacin
La contribucin de informacin se realiza desde los procesos denidos del proyecto hasta
los activos de procesos de la organizacin.
En SPEM 2.0 existe la posibilidad de realizar la documentacin del proceso de despliegue
(relacionado con el proceso denido) a travs de las guas, por ejemplo las guas de com-
probacin (Checklist ) o las descripciones de ejemplares de procesos (Guideline ). SPEM
2.0 ejecuta el apoyo a la monitorizacin de la implementacin (mediante la fase de im-
plementacin del mtodo), especcamente a los artefactos que se encuentran asociados
con los procesos estndar del mtodo. Lo que no es posible realizar en SPEM 2.0 son las
mejoras a las propuestas de los activos de procesos, ni proporcionar las medidas reales
de los mtodos y del producto en el proyecto.

4.5.2. SG 2 Coordinar y colaborar con las partes interesadas relevantes
La meta especca describe la coordinacin y colaboracin entre el proyecto y las partes
interesadas.
4.5.2.1. SP 2.1 Gestionar la involucracin de las partes interesadas
Se debe garantizar la gestin para el logro del compromiso de las partes interesadas en
el desenvolvimiento del proyecto.
Las partes interesadas se relacionan con MOSKitt4ME mediante la denicin de los roles
(Role Denition ), y las tareas se vinculan a unos pocos roles. Al tener asociados las tareas
y los roles a los procesos de despliegue (como procesos denidos), es posible gestionar la
involucracin de las partes interesadas para un desarrollo correcto del plan de proyecto.
4.5.2.2. SP 2.2 Gestionar las dependencias
Se debe hacer un seguimiento, control e identicacin de las dependencias crticas (de
los recursos) con las partes interesadas del proyecto.
Mediante SPEM 2.0 no es posible determinar si existen dependencias crticas a lo largo de
la planicacin del proyecto, por lo que no se puede realizar una gestin de dependencias
con las partes interesadas.
4.5.2.3. SP 2.3 Resolver las cuestiones de coordinacin
Resolver los asuntos con las partes interesadas relevantes. Estos asuntos pueden ser los
defectos en los requisitos o los defectos en el diseo, los problemas a nivel de producto o
la falta de disponibilidad de los recursos crticos para el proyecto.
Mediante MOSKitt4ME no existen procedimientos preestablecidos que canalicen para
coordinar y dar una solucin a los posibles asuntos arriba mencionados.
4.6. Desarrollo de requisitos (RD)
El rea de desarrollo de requisitos deduce, analiza y determina tres tipos de requisitos
que se describen en esta rea de clientes, de productos y de componentes del producto.
Los requisitos son la base de todo diseo, por lo que se considera que todos los proyectos
de desarrollo tienen requisitos.
4.6.1. SG 1 Desarrollar los requisitos de cliente
Los requisitos del cliente representan las necesidades, expectativas, restricciones e inter-
faces de las partes interesadas.
4.6.1.1. SP 1.1 Educir las necesidades
La deduccin de las necesidades implica la identicacin de los requisitos que no han
sido explcitamente proporcionados por el cliente.
Mediante MOSKitt4ME, no es posible educir las necesidades no proporcionadas por el
usuario nal.
Valoracin: No implementada
4.6.1.2. SP 1.2 Trasformar las necesidades de las partes interesadas en re-

quisitos de cliente
Implica realizar la transformacin de las necesidades, las expectativas, las restricciones
y las interfaces de las partes interesadas en requisitos de cliente priorizados.
En MOSKitt4ME, al no poder educir las necesidades, tampoco se puede realizar la prio-
rizacin de los requisitos de cliente.
4.6.2. SG 2 Desarrollar los requisitos de producto
Los requisitos de clientes deben ser elaborados, analizados o clasicados para poder
desarrollar los requisitos de productos y de componentes de productos.

Mediante MOSKitt4ME, es posible establecer, analizar y clasicar los requisitos de los
productos o los componentes de los productos mediante las disciplinas.
4.6.3. SG 3 Analizar y validar los requisitos
El anlisis y la validacin se realizan con el propsito de determinar los requisitos con-
ceptuales que optarn a satisfacer las necesidades expectativas y las restricciones de las
partes interesadas, que luego se transformarn en requisitos funcionales.
4.6.3.1. SP 3.1 Establecer los conceptos y los escenarios de operacin
Un escenario representa la secuencia de eventos que podran ocurrir en el desarrollo o
uso del producto. Dicho escenario se usa para describir las necesidades funcionales o de
calidad. Un concepto operacional para un producto depende de la solucin del diseo
como del escenario. La prctica especca establece y mantiene estos conceptos.
En SPEM 2.0, se puede dar soporte mediante las primitivas de guas, para el escenario
mediante la lista de comprobacin (Checklist ) que representa una serie de pasos a ser
comprobados y el concepto mediante la documentacin (Whitepaper ) que es una versin
especial del concepto que ha sido revisada y publicada.
4.6.3.2. SP 3.2 Establecer una denicin de la funcionalidad y de los atri-

butos de calidad requeridos
Dene la funcionalidad y los atributos de calidad analizando los escenarios para la des-
cripcin del producto.
Mediante MOSKitt4ME, es posible la denicin de los atributos de calidad y funcionali-
dad a travs de los procesos de despliegue. Adicionalmente, se permite realizar diagramas
de actividad, diagramas de caso de uso e incorporar el anlisis orientado a objetos.

4.6.3.3. SP 3.3 Analizar los requisitos
Se analizan los requisitos para determinar si son necesarios y sucientes para cumplir con
los objetivos. En la medida que se realiza el anlisis de los requisitos, se debe comprender
la relacin entre los atributos de calidad, la funcionalidad de alto nivel y los requisitos
de ms alto nivel.
En proceso de analizar los requisitos depender sustancialmente del ingeniero de mtodo
y la organizacin o categorizacin de los requisitos del proyecto que haya realizado. A
travs de los patrones de capacidades, roles, tareas y guas, MOSKitt4ME le proporciona
todas las primitivas necesarias para la denicin y organizacin de los requisitos, bien
sean funcionales o de calidad.
4.6.3.4. SP 3.4 Analizar los requisitos para conseguir un equilibrio
Consiste en analizar los requisitos para mantener un equilibrio entre las necesidades y
las restricciones de las partes interesadas.
Al consistir en un proceso, el anlisis depender del ingeniero de mtodo para mantener
este equilibrio.
4.6.3.5. SP 3.5 Validar los requisitos
La validacin de los requisitos est relacionada con el rea de validacin, y se debe
garantizar el funcionamiento correcto del producto, de acuerdo con lo previsto en el
entorno del usuario nal.
En MOSKitt4ME, es posible realizar el proceso de validacin de los requisitos, bien sea
mediante la creacin de prototipos, demostraciones o simulaciones en el entorno CASE
de mtodos.
Valoracin: Completamente implementada

4.7. Integracin del producto (PI)
El rea de integracin del producto tiene como propsito garantizar que el producto sea
ensamblado, funcione correctamente de acuerdo con los atributos de calidad requeridos
y sea entregada debidamente.
4.7.0.6. SG 1 Prepararse para la integracin del producto
La meta especca se reere a la preparacin del ambiente o al entorno donde se realizar
la integracin del producto, as como los procedimientos y criterios que se deben denir
antes de efectuarse la integracin.
4.7.0.7. SP 1.1 Establecer una estrategia de integracin
El establecimiento y mantenimiento de una estrategia de integracin consiste en una
aproximacin que describe, ensambla y evala los componentes del producto. Dichas
estrategias de integracin deben estar alineadas con las aproximaciones tcnicas y la
seleccin de las soluciones de diseo y sus componentes de producto.
Como MOSKitt4ME se basa en el estndar SPEM 2.0 se permite establecer las estrategias
de integracin de los productos y sus componentes del mtodo con las aproximaciones
tcnicas y la seleccin de las soluciones tcnicas que se puedan proponer, gracias al marco
conceptual de SPEM 2.0 que provee los conceptos necesarios para modelar, documentar,
presentar, publicar y realizar mtodos y procesos de software.
4.7.0.8. SP 1.2 Establecer el entorno de integracin del producto
El entorno mediante el cual se realiza la integracin del producto se debe establecer y
mantener bien sea que se haya adquirido o desarrollado. Puede incluir el equipamiento
de pruebas, simuladores y dispositivos de grabacin.
Actualmente, MOSKitt4ME est siendo soportado por el Centro de Investigacin en
Mtodos de Produccin de Software, de la Universidad Politcnica de Valencia, sien-
do una extensin de MOSKitt (http://www.moskitt.org/ ) que da soporte al trabajo de
investigacin.

4.7.0.9. SP 1.3 Establecer los procedimientos y los criterios de integracin

del producto
Establecimiento y mantenimiento de los criterios de los procedimientos para la integra-
cin del producto pueden incluir el nmero de iteraciones incrementales, el detalle de las
pruebas y otras evaluaciones.
Los procedimientos y criterios pueden indicar:
La disponibilidad de un componente
La denicin de los criterios de vericacin de componentes de productos y su
comportamiento
El grado de simulacin permitido o el entorno a utilizar para las pruebas de inte-
gracin
El calendario y las pruebas de ensamblaje, para evitar la aparicin de retrasos y
fallas de componentes
Mediante las guas que se denen en MOSKitt4ME es posible establecer los procedimien-
tos y los criterios de integracin de los productos. Un ejemplo para el tipo de gua es la
prctica (Practice ) que es una manera predenida de hacer un trabajo, y que resume los
aspectos que pueden impactar en diferentes partes de un mtodo o proceso.
4.7.0.10. SG 2 Asegurar la compatibilidad de las interfaces
Se debe garantizar que las interfaces, tanto internas como externas, de los componentes
de producto sean completas y compatibles.
4.7.0.11. SP 2.1 Revisar la completitud de las descripciones de las interfaces
Las interfaces deben incluir la cobertura y completitud con sus descripciones adecuadas.
Se debe garantizar que los componentes de producto y las interfaces sean etiquetadas
para asegurar una conexin fcil y correcta para la unin de los componentes de producto.
MOSKitt4ME provee soporte al uso de herramientas externas del contexto de Eclipse.
Para ello, SPEM 2.0 utiliza el tipo de elemento llamado gua de herramienta (Tool Men-
tor ), que permite explicar el uso de ciertas herramientas en el contexto de un trabajo

o de forma independiente. Con el uso de la gua de herramienta es posible realizar las
descripciones adecuadas de las interfaces.
4.7.0.12. SP 2.2 Gestionar las interfaces
Mantener la consistencia de las interfaces durante toda la vida del producto, cumplir
con las limitaciones de la arquitectura, solucionar los conictos, cambios y las no con-
formidades estn en la responsabilidad de la gestin de las interfaces. Por ello, se deben
considerar las deniciones y diseos de las interfaces internas y externas, para los pro-
ductos y componentes de productos.
La interfaz externa en MOSKitt4ME se dene a travs de las guas de herramientas. La
interfaz interna se dene como la relacin que se mantiene entre la tarea y los productos
de trabajo. Una tarea est asociada a los productos de trabajo como salidas y entradas
obligatorias u opcionales. Los productos de trabajo estn predenidos como:
Artefactos (Artifact ): pueden ser modelos, documentos, cdigos, archivos, etc.
Entregables (Deliverable ): estn asociados con cero o ms de un componente en-
tregable
Resultados (Outcome ): son de naturaleza tangible
Al existir estas especializaciones de los productos de trabajo en SPEM 2.0 es posible
que un producto de trabajo de salida de una tarea pueda ser el producto de trabajo de
entrada de otra tarea. Por esta razn, se considera a las relaciones entre las tareas y los
productos de trabajo como las interfaces internas.
Por lo anteriormente expuesto, se considera posible gestionar en MOSKitt4ME las inter-
faces, tanto internas como externas, de los productos y los componentes de los productos.
4.7.1. SG 3 Ensamblar los componentes de producto y entregar el

producto
Los componentes de producto deben estar ensamblados y vericados. Adems, se debe
proporcionar un producto integrado, vericado y validado.

4.7.1.1. SP 3.1 Conrmar la disponibilidad de los componentes de producto

para la integracin
Se debe vericar antes de realizar la integracin de los componentes de producto si estos
han sido identicados de forma correcta, si su comportamiento es de acuerdo con lo
descrito y si las interfaces del componente cumplen con las descripciones que poseen.
En MOSKitt4ME, a travs de la ejecucin del mtodo, en la fase de implementacin,
es posible realizar las evaluaciones de los componentes de los productos. Sin embargo
en la fase de diseo, no existe un proceso que permita determinar en forma automtica
la vericacin de los componentes de producto y as determinar si cumplen o no con la
funcionalidad que se ha descrito.
4.7.1.2. SP 3.2 Ensamblar los componentes de producto
La prctica especca tiene como propsito ensamblar los componentes de producto de
acuerdo con los procedimientos de integracin.
Los componentes de producto en SPEM 2.0 representan el contenido de mtodo (Method
Content ), y el proceso de ensamblaje de dichos componentes se realiza en el marco me-
todolgico de los procesos (Processes ) donde se reutilizan y combinan dichos elementos.
4.7.1.3. SP 3.3 Evaluar los componentes de producto ensamblados
Los componentes de producto, una vez ensamblados, deben someterse a una validacin
en cuanto a la compatibilidad de las interfaces.
Se considera parcialmente implementada la prctica especca de evaluacin debido a
que no se realizan procesos de validacin formales en MOSKitt4ME. No obstante, existe
la vista consolidada (Consolidated View ) en los procesos ya ensamblados que permite
realizar una evaluacin visual de la jerarqua o la arquitectura de producto.

4.7.1.4. SP 3.4 Empaquetar y entregar el producto o componente de pro-

ducto
La entrega y empaquetado del producto o componente de producto al cliente.
Esta prctica especca se relaciona con MOSKitt4ME mediante la fase de implementa-
cin del mtodo que consiste en la generacin de forma semiautomtica de un entorno
CASE que provee soporte a la creacin de productos de mtodo y tambin a la ejecucin
del proceso.
4.8. Solucin tcnica (TS)
El rea de solucin tcnica se focaliza en la seleccin de la solucin, el desarrollo de-
tallado y la implementacin del diseo. Las soluciones tcnicas engloban los productos,
los componentes de producto y los procesos del ciclo de vida relativos al producto, bien
individualmente o en conjunto.
4.8.1. SG 1 Seleccionar soluciones de componentes de producto
Las soluciones alternativas y sus ventajas relativas son parte de la solucin del compo-
nente, en donde las soluciones alternativas son establecidas mediante los requisitos clave,
los asuntos de diseo y las limitaciones.
4.8.1.1. SP 1.1 Desarrollar soluciones alternativas y los criterios de seleccin
La identicacin de soluciones alternativas permite la seleccin de una solucin equili-
brada en trminos de coste, de calendario, de rendimiento y de riesgo. Las soluciones
alternativas y los criterios de seleccin se basan en:
Las arquitecturas de productos de trabajos que posean atributos crticos de calidad
Un diseo factible de soluciones
La asignacin de alternativas de requisitos para diferentes componentes de producto
Un rango aceptable de coste, de calendario y de rendimiento

Normalmente podran tratar costes (p. ej., tiempo, personal, dinero), benecios (p. ej.,
prestacin del producto, capacidad, ecacia) y riesgos (p. ej., tcnicos, de coste, de ca-
lendario).
Mediante SPEM 2.0 se pueden proporcionar las soluciones alternativas y los criterios de
seleccin mediante el concepto de variabilidad (Variability ). Esta ltima se organiza en
plug-ins (Plugins ) en donde los procesos incluyen partes alternativas que son congura-
bles, y es un mecanismo que permite modicar los elementos de mtodo o de proceso
sin realizar la modicacin del componente original. A los criterios de seleccin se puede
dar soporte mediante los tipos de guas llamadas instruccin (Guideline ) que proveen
informacin adicional para la realizacin de un grupo de tareas y recomendacin sobre
productos de trabajo.
Como MOSKitt4ME se basa en el estndar SPEM 2.0, se puede incluir los criterios de
seleccin. Sin embargo, para la identicacin de soluciones alternativas, el mtodo no
posee las primitivas del calendario o de la gestin de riesgos.
4.8.1.2. SP 1.2 Seleccionar las soluciones de componentes de producto
Con base en los criterios de seleccin previamente denidos, se debe seleccionar los com-
ponentes de productos. Debe existir una relacin entre los requisitos y los componentes
de productos, en donde la decisin de la solucin y evaluacin deben estar debidamente
documentadas e incluir un anlisis razonado.
En SPEM 2.0, una vez identicado los componentes de producto dentro de la fase de
contenido de mtodo (Method Content ) y establecido los criterios de seleccin, con el uso
de las guas (Guidance ), se puede establecer la seleccin de las soluciones y su debida
documentacin de la decisin mediante el uso de las guas, ya que sirven de soporte o
ayuda a los dems elementos del mtodo. As, por ejemplo, es el caso del tipo de gua
llamada informe (Report ) que es una plantilla predenida de un resultado que se obtiene
de forma automtica.
4.8.2. SG 2 Desarrollar el diseo
El desarrollo del diseo debe ser apropiado para todas las fases del ciclo de vida del pro-
ducto que incluye la modicacin, el reaprovisionamiento, el mantenimiento, el soporte

y la instalacin. Los diseos de producto deben contar tambin con una documentacin
apropiada que den referencia para la comprensin del diseo y mantenimiento de sus
componentes.
4.8.2.1. SP 2.1 Disear el producto o los componentes de producto
La fase del diseo del producto comprende dos grandes fases: el diseo preliminar y el
diseo detallado. El diseo preliminar establece las capacidades y la arquitectura del
producto. El diseo detallado dene por completo el detalle de la estructura y las capa-
cidades de los componentes de producto.
SPEM 2.0 es un estndar de metamodelado que sirve para representar procesos de in-
geniera de software, un metamodelo describe un conjunto de conceptos genricos y sus
interrelaciones para la denicin de modelos de un cierto dominio. A travs de la deni-
cin del metamodelo se dene la primera fase para la arquitectura del diseo preliminar.
Y, mediante la ejecucin del mtodo, MOSKitt4ME brinda todas las directrices que
permiten el desarrollo de un diseo detallado del mtodo.
4.8.2.2. SP 2.2 Establecer un paquete de datos tcnicos
Los paquetes de datos tcnicos son la descripcin adecuada de un producto o de los
componentes de un producto que sirve de apoyo a una estrategia de adquisicin, o fase de
implementacin, produccin, ingeniera y soporte logstico del ciclo de vida del producto.
Es particularmente til usar la arquitectura del producto como un medio para organizar
estos datos, y para abstraer vistas que son claras y relevantes para una caracterstica de
inters.
En SPEM 2.0 los paquetes de datos tcnicos se pueden establecer mediante las guas en
el tipo de denicin de trmino (Term Denition ) que sirve para generar una especie de
glosario automtico y se relaciona a los elementos de contenido.
4.8.2.3. SP 2.3 Disear las interfaces usando criterios
Mediante los criterios establecidos se debe disear la interfaz de componentes.

En SPEM 2.0, al poderse desarrollar las interfaces en sus componentes y denir los
criterios mediante las guas, es posible aplicar los criterios que se hayan establecido,
sobre todo con el tipo de gua llamada prctica (Practice ).
4.8.2.4. SP 2.4 Realizar los anlisis sobre si hacer, comprar o reutilizar
El proceso de evaluacin sobre si hacer, comprar o reutilizar, se basa en las necesidades
del proyecto y depende de muchos factores, por ejemplo:
Funcionalidad de los productos y su ajuste al proyecto
Recursos y habilidades disponibles del proyecto
Costes de adquisicin frente a costes de desarrollo interno
Fechas crticas de integracin y de entrega
Funcionalidad y calidad de los productos disponibles
Impacto en las competencias bsicas
Licencias, garantas, responsabilidades y limitaciones asociadas con los productos
que estn siendo adquiridos
Disponibilidad del producto
Reduccin del riesgo
Correspondencia entre las necesidades y los activos bsicos de la lnea de producto
Mediante SPEM 2.0 es posible realizar la evaluacin y el uso de los componentes de
productos bien se haga, compre o se reutilice, dado que da el soporte requerido.
4.8.3. SG 3 Implementar el diseo del producto
Una vez realizado el diseo de los productos, se procede a implementarlos. Se debe incluir
las pruebas unitarias de los componentes de producto antes de realizar la integracin del
mismo.
4.8.3.1. SP 3.1 Implementar el diseo
La actividad de implementacin de los componentes de producto parte del diseo e
incluye la asignacin, el renamiento, la coordinacin de los esfuerzos de desarrollo y la
vericacin de cada componente del producto.
Mediante MOSKitt4ME, se puede realizar la implementacin de diseo por las siguientes
razones:
Se realiza una asignacin entre los componentes en la fase de diseo del mtodo,
por ejemplo, cuando se establece la relacin entre los artefactos, las tareas y las
guas.
El proceso de renamiento se realiza mediante la conguracin del mtodo, que
consiste en una seleccin de contenidos de los plug-ins de una librera, de forma
que se limita la vista de la librera a sub-conjuntos seleccionados.
La coordinacin de los esfuerzos de desarrollo se hace bajo un ambiente de desarrollo
de ECLIPSE que est unicado y estandarizado.
La vericacin se lleva a cabo de forma manual o mediante la documentacin que
poseen los componentes de productos. Aunque quizs sea posible mejorar dicho
proceso.
4.8.3.2. SP 3.2 Desarrollar la documentacin de soporte del producto
La prctica especca requiere el desarrollo y mantenimiento de la documentacin que
se elabora en la instalacin, operacin y mantenimiento del producto.
SPEM 2.0 cuenta con los descriptores en todos sus componentes de productos que se
desarrollan. Adicionalmente, posee elementos como las guas que le permiten incluir la
documentacin suplementaria necesaria a lo largo del ciclo de vida del proyecto.
4.9. Validacin (VAL)
La validacin signica que un producto cumple con su uso deseado, es decir, la valida-
cin asegura que se construy lo correcto. En la mayora de los casos, los usuarios
nales y las partes interesadas estn involucrados en las actividades de validacin. Estas
actividades se aplican en todos los aspectos del producto y en cualquier entorno previsto.
4.9.1. SG 1 Preparar la validacin
Consiste en preparar el entorno, seleccionar los productos o los componentes de producto,
crear los procedimientos y los criterios de validacin. Cualquier producto o componente
de producto puede estar sujeto a validacin.
4.9.1.1. SP 1.1 Seleccionar los productos para la validacin
Se puede seleccionar los requisitos, los productos y los componentes de productos para
realizar la validacin con relacin a las necesidades del usuario nal. Se deben crear los
mtodos, requisitos y las restricciones a considerar para realizar el proceso de validacin
en esta prctica especca.
En MOSKitt4ME, es factible realizar la seleccin de los requisitos, los productos y de los
componentes, y con los procesos de despliegue (Delivery Processes ) se llevara a cabo la
creacin de los mtodos, las restricciones y los requisitos del proceso de validacin.
4.9.1.2. SP 1.2 Establecer el entorno de validacin
Es el ambiente donde se realizan las validaciones de los diseos, los prototipos y de la
versin nal. El entorno de validacin se debe establecer y mantener a lo largo del ciclo
de vida del proyecto.
MOSKitt4ME permite la creacin de prototipos, por lo tanto, se puede realizar las va-
lidaciones con el usuario nal, as como tambin en la fase de ejecucin del mtodo
(Ambiente CASE) ejecutar las validaciones.
4.9.1.3. SP 1.3 Establecer los procedimientos y los criterios de validacin
Son los procedimientos, criterios y estndares de validacin que se denen para asegurar
que el producto cumpla con los objetivos que se hayan denido para su uso. Incluyen las
pruebas y evaluaciones.
Los procedimientos y los criterios de validacin se pueden establecer en SPEM2.0 median-
te las guas (Guidance ), especcamente con el tipo de gua llamada prctica (Practice ).
4.9.2. SG 2 Validar el producto o los componentes de producto
Para realizar la validacin del producto o los componentes de producto se usa los mtodos,
los procedimientos y los criterios de validaciones que se han denido previamente.
4.9.2.1. SP 2.1 Realizar la validacin
Se ejecuta el proceso de validacin de los productos o componentes con los usuarios o
partes interesadas, de acuerdo con los procedimientos preestablecidos.
En MOSKitt4ME el procesos de validacin se puede realizar en la fase de ejecucin
del mtodo, creando previamente procesos de validacin y ejecutndolos en esta fase
(mediante la herramienta CASE) para as comprobara si los procesos de desarrollo de
software cumplen con lo preestablecido. Sin embargo, el proceso de validacin se debe
realizar en todas las fases del ciclo de vida del producto de trabajo, y, durante la fase del
diseo del mtodo, no se realiza el proceso de validacin.
4.9.2.2. SP 2.2 Analizar los resultados de la validacin
Los resultados de las pruebas se analizan frente a los criterios de validacin denidos.
Los informes de anlisis por lo general contienen:
Si cumplieron con las necesidades
Cuando ocurren las deciencias, documentan el grado de xito o fallo y clasican
las causas del fallo
Si los malos resultados de las pruebas son debido a problemas de procedimiento de
validacin o del entorno.
Con MOSKitt4ME, es posible realizar el anlisis de los resultados mediante la ayuda de
las guas para los resultados, especcamente el tipo de gua llamada informe (Report ).

4.10. Vericacin (VER)
La vericacin es la conrmacin de que los productos reejan los requisitos conforme se
han especicado, es decir la vericacin asegurar que lo construy correctamente. Al
aplicar la vericacin de los productos de trabajo es directamente proporcional de que el
producto satisfaga los requisitos del cliente, de producto y de componente de producto.
El rea especca de vericacin incluye a los productos y de los productos de trabajo
intermedio, los requisitos de cliente, de producto y de componente de producto frente a
los requisitos seleccionados.
4.10.1. SG 1 Preparar la vericacin
La preparacin de la vericacin consiste en la seleccin de los productos a vericar, la
preparacin del entorno y la creacin de los procedimientos a utilizar durante el proce-
so de vericacin que incluye todo el ciclo de vida de producto o los componentes de
producto de trabajo.
4.10.1.1. SP 1.1 Seleccionar los productos de trabajo para la vericacin
La prctica especca de procesos implica la seleccin de los productos de trabajo y
mtodos para la vericacin. Para seleccionar los componentes se toma en consideracin
su contribucin con el logro de los objetivos y los requisitos del proyecto.
En MOSKitt4ME, es factible realizar la seleccin de los productos de vericacin, debido
a que se pueden seleccionar los componentes y crear los mtodos de vericacin mediante
los procesos de despliegue (Delivery Processes ).
4.10.1.2. SP 1.2 Establecer el entorno de vericacin
El entorno de trabajo se puede adquirir, desarrollar, reutilizar, modicar o ser una mezcla
de todos. Esto depender de las necesidades del proyecto. Algunos entornos pueden
requerir simuladores, emuladores, generadores de escenarios, herramientas de reducciones
de datos, interfaces con otros sistemas o simplemente los revisores y una sala (para el
caso de revisores entre pares; ver denicin A.6).

Es posible establecer entornos de trabajo mediante MOSKitt4ME, ya que al estar desa-

3
rrollado en la plataforma de un entorno ECLIPSE , este permite la integracin o imple-
mentacin pblica, abierta y gratuita con otros sistemas.
4.10.1.3. SP 1.3 Establecer los procedimientos y los criterios de validacin
Los procedimientos y los criterios de vericacin se denen para asegurar que los pro-
ductos de trabajo cumplen sus requisitos.
Los procedimientos y los criterios de vericacin se pueden establecer en SPEM2.0 me-
diante las guas (Guidance ), especcamente con el tipo de gua llamada prctica (Prac-
tice ).
4.10.2. SG 2 Realizar las revisiones entre pares
La revisin entre pares es un mtodo usado para la validacin de la calidad de un trabajo,
por lo general entre autores de rango semejante o superior al autor o creador, en este caso
de los productos desarrollados en el proyecto. La realizacin de las revisiones entre pares
(ver denicin A.6) es altamente recomendada entre las prcticas especcas, debido a
que es un mecanismo probado para eliminar defectos ecazmente, de tal forma que se
pueden prevenir los defectos y se pueden identicar las oportunidades de mejoras.
En la metodologa descrita por MOSKitt4ME, no se contempla el uso de este mtodo
de revisin entre pares para la vericacin de los productos desarrollados. Sin embargo,
su uso y aplicacin se consideran factibles y consisten en identicar al personal que
participar en la revisin entre pares, realizar el proceso de revisin con el propsito de
encontrar y eliminar defectos en fases tempranas, y analizar los resultados de los datos
obtenidos.
4.10.3. SG 3 Vericar los productos de trabajo seleccionados
Vericar los productos y productos de trabajo incrementalmente promueve la deteccin
temprana de problemas y puede dar como resultado la eliminacin de defectos a tiempo.
3
Ms informacin se puede encontrar en: www.eclipse.org/epf/
. Consultado al 08-05-2013
Los resultados de la vericacin ahorran un coste considerable de aislamiento de fallos y
re-trabajo asociados con la resolucin de problemas.
Realizar el proceso de vericacin de acuerdo con los mtodos y procedimientos estable-
cidos en los requerimientos.
4.10.3.1. SP 3.1 Realizar la vericacin
Realizar la vericacin sobre los productos de trabajo seleccionados. Tiene como benecio
la deteccin de los problemas si se aplica desde las primeras fases del proceso ahorrando
costes y re-trabajos asociados a la resolucin de problemas. Por lo general, la vericacin
del desarrollo de software incluye prototipado, modelado y simulacin para vericar la
idoneidad del diseo del sistema (y la asignacin).
En MOSKitt4ME, se puede realizar la vericacin por las siguientes razones:
Se pueden crear prototipos
Su objetivo principal es el diseo y desarrollo de mtodos de desarrollo de software
Se permite la ejecucin de proyectos (con uso de herramientas CASE), con ello se
puede realizar la simulacin, de ser requerido
No obstante, el proceso de vericacin se debe realizar en todas las fases del ciclo de
vida del producto de trabajo, en la fase de diseo del mtodo para MOSKitt4ME, no se
realiza la vericacin.
4.10.3.2. SP 3.2 Analizar los resultados de la vericacin
El anlisis de los resultados se debe comparar con los criterios establecidos previamente
determinando su validez y registrar para guardar como evidencia del proceso de veri-
cacin.
Con MOSKitt4ME, es posible realizar el anlisis de los resultados de la vericacin con
respecto a la ejecucin de los otros procesos, mediante la ejecucin del mtodo, con la
generacin de la herramienta CASE, y se pueden apoyar mediante la ayuda de las guas,
especcamente el tipo de gua llamada informe (Report ).

4.11. Anlisis de decisiones y resolucin (DAR)
El rea de anlisis de decisiones y resoluciones consiste en establecer guas y poder deter-
minar mediante un proceso de evaluacin formal las posibles decisiones, que evaluarn
las alternativas frente a unos criterios establecidos. El proceso de evaluacin formal es
un enfoque estructurado e implica las siguientes acciones:
Establecer los criterios para evaluar alternativas
Identicar soluciones alternativas
Seleccionar mtodos para evaluar alternativas
Evaluar soluciones alternativas utilizando los criterios y los mtodos establecidos
Seleccionar soluciones recomendadas a partir de las alternativas identicadas con
base en los criterios de evaluacin
Se establecen las evaluaciones formales para cuestiones que lo requieran, por ejemplo la
seleccin entre distintas alternativas de diseo o de arquitectura, la utilizacin de com-
ponentes reutilizables o de componentes de productos comerciales (COTS), los entornos
de prueba, las alternativas de entrega.
Para MOSKitt4ME, se considera no aplicable esta rea de anlisis de decisiones y re-
solucin, debido a que no es requerido establecer guas o procesos formales que evalen
alternativas de diseo o arquitectura.
4.12. Resumen
Una vez realizado el anlisis comparativo entre las reas de proceso del nivel de ma-
durez 3 de CMMI-DEV 1.3 con MOSKitt4ME, se puede apreciar que muchas de las
prcticas especcas son implementadas a completitud, mientras muy pocas no han sido
implementadas. A continuacin, se resumen los resultados obtenidos.
En tabla 4.1 se encuentra sintetizado el anlisis que se efectu a lo largo del presente
captulo. La tabla est comprendida por las siguientes columnas:
rea de Proceso comprende el nivel de madurez 3 de CMMI-DEV

Tabla 4.1: Resumen comparativo entre CMMI-DEV vs. MOSKitt4ME - Nivel 3
En Nro. Prcticas Especcas Implementadas, el nmero de prcticas especcas
que han sido implementas completamente, ampliamente, parcialmente o no imple-
mentadas, de acuerdo con el estudio realizado
% Prcticas Especcas Implementadas da el porcentaje del nmero de prcticas
especcas que se consideran implementadas en relacin con el total de prcticas que
posee el rea de proceso. Este porcentaje se obtuvo mediante la siguiente frmula:
(, P esosrelacionP racticasEspecif icas) / Nmero de Prcticas Epeccas
En cuanto a las reas de formacin en la organizacin (OT) y al anlisis de decisiones y
resolucin (DAR), se puede indicar que no son aplicables para MOSKitt4ME, debido a
que no estn dentro de los propsitos o metas que posee el mtodo.
En relacin con las reas de procesos de denicin de procesos de la organizacin (OPD),
gestin integrada del proyecto (IPM), integracin del producto (PI), solucin tcnica
(TS), validacin (VAL) y vericacin (VER), se consideran que han alcanzado casi al
100 % la implementacin de las prcticas especcas con respecto al mtodo. De estas 42
prcticas evaluadas, slo estos puntos que se mencionan de las prcticas especcas no
se han implementado o se consideran parcialmente implementada por MOSKitt4ME:
Repositorio de mediciones: especcamente las propiedades de tamao de los pro-
ductos de trabajo y costos (horas/personas), medidas de abilidad o medidas de
calidad
Resolver las cuestiones de coordinacin: dar garanta de los defectos en los requi-
sitos o los defectos en el diseo, los problemas a nivel de producto o la falta de
disponibilidad de los recursos crticos para el proyecto
Conrmar la disponibilidad de los componentes de producto para la integracin:
determinar en forma automtica la vericacin de los componentes de producto y
as determinar si cumplen o no con la funcionalidad acordada
Coordinacin entre pares: un mtodo de vericacin del producto
Vericacin: la vericacin automtica del producto o los componentes del producto
en todas las fases del ciclo de vida.
En cuanto al rea de gestin de riesgos (RSKM), desarrollo de requisitos (RD) y enfoque
en procesos de la organizacin (OPF), se consideran sin puntaje o con un bajo punta-
je, debido a que ninguna de sus prcticas especcas o muy pocas son soportadas por
MOSKitt4ME. Sin embargo, en su mayora son procedimientos para la gestin de los
riesgos, de los requisitos y de los procesos de la organizacin por lo que mediante SPEM
2.0, al ser un estndar de metamodelado, les permitir representar e implementar sus
procedimientos y procesos de ingeniera de software enmarcados en estas reas.
A continuacin, se realiz una tabla resumen de algunos conceptos o trminos que han
surgido a lo largo del presente captulo en donde se ha encontrado una relacin entre
MOSKitt4ME y CMMI-DEV 1.3 (ver la tabla 4.2). Si se desea ver mayor detalle se
pueden consultar las prcticas especcas en donde han sido implementadas con respecto
al mtodo.
El estndar de SPEM 2.0 y, por ende, MOSKitt4ME provee primitivas que ayudan con
el cumplimiento de madurez del nivel 3 de CMMI-DEV, debido a que poseen caracte-
rsticas que se han analizado a lo largo de este captulo, conrmando lo indicado en la
especicacin de SPEM 2.0. [14]
La primera caracterstica son los mecanismos de adaptacin y reutilizacin de sus
elementos, por ejemplo, los patrones de procesos o capacidades.
Otro elemento descrito es la variabilidad o adaptabilidad de los elementos del m-
todo. Las guas y sus diferentes tipos sirven de ayuda en lo que respecta a la docu-
mentacin, la denicin del glosario de trminos, la denicin de los procedimientos
para los dems elementos.
Los elementos de descomposicin de trabajo se relacionan con la creacin de pro-
cesos denidos.
CMMI-DEV MOSKitt4ME (SPEM 2.0/BPMN 2.0)

Procesos estndar Patrn de capacidades, fragmentos del mtodo
(activos reutilizables)
Modelos de ciclo de vida Fases e iteraciones
Guas de adaptacin Guas Plantillas
Bibliotecas de activos Guas Activos reutilizable
Reglas y guas de equipos Cualicaciones
Procesos denidos Procesos de despliegue
Interfaces internas Relaciones entre las tareas, roles, artefactos
Interfaces externas Guas Gua de herramienta
Todos los procedimientos Guas Prctica
Ensamblar los componentes En el proceso de SPEM 2.0
del producto
Soluciones alternativas Variabilidad
Criterios de seleccin Guas Directrices
Renamiento Conguracin del mtodo
Entorno Lo establece la plataforma ECLIPSE
Tabla 4.2: Resumen de conceptos entre CMMI-DEV vs. MOSKitt4ME - Nivel 3
Todo lo anteriormente mencionado es fundamental a lo largo del establecimiento del
mapeo entre CMMI-DEV y MOSKitt4ME.

Captulo 5
Propuestas
En el anlisis comparativo realizado entre las prcticas especcas del nivel 2 y 3 de ma-
durez de CMMI-DEV y MOSKitt4ME, se pudo apreciar que existen prcticas especcas
que no han sido implementadas por MOSKitt4ME. Las propuestas que a continuacin
se describe proponen alternativas o soluciones que tienen como objetivo mejorar MOS-
Kitt4ME para que de soporte a las diferentes reas de procesos, que se han mencionado
en el nivel 2 y 3 de CMMI-DEV.
5.1. Incorporacin de un plan de proyecto
Al no implementar por completo las prcticas especcas del rea de Planicacin del
Proyecto (PP) se propone una extensin en MOSKitt4ME que se basa en la incorpora-
cin de un plan de proyecto. Para ello, SPEM 2.0 ofrece diferentes mecanismos para la
ejecucin de los procesos del mtodo:
Se mapean los procesos a planes del proyecto, y se realiza la ejecucin de los planes
mediante herramientas de gestin de proyectos, tales como IBM Rational Portfolio
Manager o Microsoft Project.
Se mapean los procesos a representaciones ejecutables, por ejemplo BPMN 2.0,
para luego ejecutar la representacin de los procesos mediante un motor de proceso
implementadas de las prcticas.
Se debe analizar la primera opcin de ejecucin de proyectos mediante la herramienta de
gestin de proyectos, con el propsito de poder establecer las equivalencias conceptuales
entre SPEM 2.0 y MS Project 2010, para dar un mayor porcentaje de implementacin
81
Captulo 5. Propuestas 82
a las prcticas especcas y as dar por satisfecha el rea de Planicacin del Proyecto
(PP).
A continuacin se realizar un mapeo entre SPEM 2.0 y Microsoft Project 2010:
En SPEM 2.0 los procesos de entrega (DeliveryProcess), describen el enfoque com-
pleto e integrado para la realizacin de un tipo de proyecto especco. En MS
Project 2010 este concepto se representa por medio del archivo del proyecto prin-
cipal, cuya funcin es la administracin de los proyectos.
La iteracin (Iteration ) de SPEM 2.0 representa un perodo de tiempo signicativo
en los proyectos, se relaciona con MS Project 2010 mediante la tarea llamada
resumen, que ayuda a organizar la lista de tareas.
La actividad (Activity ) en SPEM 2.0 son unidades de trabajo general de un proceso.
En MS Project 2010 se representa como la tarea que agrupa a una serie de tareas
con un mismo objetivo.
La tarea (Task ), tanto en SPEM 2.0 como en MS Project 2010, se denomina de la
misma manera, representando la porcin ms pequea del trabajo. La diferencia
principal radica que en MS Project 2010 se debe indicar la duracin y su delimita-
cin (fecha de inicio y fecha de n) a la tarea. Lo que SPEM 2.0 y MS Project 2010
tienen en comn es la propiedad de dependencia o predecesoras entre las tareas.
En SPEM 2.0 el rol (Role ) dene las competencias y responsabilidades de un in-
dividuo o grupo y est asociado a los productos de trabajo o a las habilidades que
el rol provee. En MS Project 2010 la llamada informacin del recurso (aunque no
solamente se utiliza para el manejo de personal, sino tambin para los materiales
y los costos) permite crear, asignar o eliminar los roles o personas al/del proyecto.
Al gestionar los recursos, MS Project 2010 permite asignar los valores de costos
bajo ciertas premisas. A las tareas o actividades se le asignan los nombres de los
recursos.
Los hitos (Milestone ), que se denomina de la misma manera tanto en SPEM 2.0
como en MS Project 2010, representan un evento signicativo para el desarrollo
del proyecto.
A continuacin se muestra la tabla 5.1 que menciona los trminos utilizados para esta-
blecer la relacin entre SPEM 2.0 y Microsoft Project 2010:
En la gura 5.1, se puede ver a manera de ejemplo un proceso desarrollado en SPEM 2.0,
desde la estructura de desglose de trabajo y en la gura 5.2, de forma similar el mismo

SPEM 2.0 Microsoft Project 2010

Procesos de entrega Archivo del proyecto principal
Iteracin Resumen
Actividad Tarea que agrupa a una serie de tareas
Tarea Tarea
Rol Informacin del recurso
Hitos Hitos
Tabla 5.1: Resumen comparativo SPEM 2.0 vs. Microsoft Project 2010
plan de proyecto desde la vista diagrama de Gantt con el objetivo de ver las diferencias
que poseen.
Figura 5.1: Estructura de desglose de trabajo en MOSKitt4ME
1. La primera diferencia que se puede apreciar en la 5.1, en la tarea de Anlisis y
diseos de casos de uso, donde el atributo de mltiples ocurrencias se encuentra
activado (has_multiple_occurrances true ) en la estructura de desglose de trabajo

(Work Breakdown Element ), es el hecho de que existe una sola tarea. Comparando
con la gura 5.2 se nota que existen dos tareas.
2. La segunda diferencia se muestra en la iteracin en SPEM 2.0,Control de Cambios.
Para que este grupo de tareas se repita es necesario tener activado el atributo de que
es repetible (Is_repeatable true ), mientras en MS Project 2010 se debe planicar
en dos oportunidades las actividades de Control de Cambios.

Figura 5.2: Plan de proyecto en MS Project 2010
3. En MS Project 2010 existe una opcin que se llama Herramientas de Organizador
de equipo que presenta los recursos con las tareas asignadas para una fecha deter-
minada. Estas vistas de recursos ayudan a determinar la criticidad de los mismos,
y, por consecuencia, a realizar una mejor gestin y coordinacin de dependencias.
4. Otra funcionalidad que posee MS Project 2010 y que no posee SPEM 2.0 es la
creacin de lneas bases que consisten en un plan actual previamente acordado,
siendo una referencia inicial, antes de comenzar los proyectos, para poder comparar
los cambios que puedan surgir a lo largo de dichos proyectos.
5.1.1. Conclusiones
Despus de haber realizado el mapeo entre SPEM 2.0 y MS Project 2010, se puede
concluir que el plan de proyecto (a diferencia del proceso representado en SPEM 2.0)
dene los siguientes puntos:
Incluye los parmetros de planicacin de los proyectos, entre ellos el coste, el
esfuerzo y el calendario del proyecto.
Se crea la lnea base, con la cual es posible medir las desviaciones del plan, efec-
tuando las acciones correctivas.
Ayudan a determinar la criticidad de los recursos mediante las herramientas de
organizacin de equipo. Al incorporar los planes de proyecto es posible que sean
implementadas las siguientes prcticas especcas descritas en la tabla 5.2 .

Tabla 5.2: Prcticas especcas implementadas al incorporar el plan de proyecto
5.2. Creacin de una gestin de cambio
A lo largo del ciclo de vida de un proyecto, es altamente probable que ocurran cambios.
Para llevar de forma ms eciente y seguir los procedimientos establecidos, asegurando
en todo momento la calidad y continuidad, es requerido poseer una correcta evaluacin
y planicacin del proceso de cambio.
A continuacin se mencionan algunos benecios de una correcta gestin de cambio:
Reduccin del nmero de fallos que se encuentren asociados a los cambios.
En caso de fallos que se encuentren asociados a los cambios, es posible volver a la
conguracin anterior.
Permite el desarrollo de procedimientos de controles de cambio estndares, facili-
tando una rpida actualizacin de sistemas no crticos.
Maximiza la productividad y minimiza los errores que puedan ocurrir en el desarro-
llo de los proyectos. A continuacin se muestra la gura 5.3, que describe en forma
grca como deberan llevarse las iteraciones y funcionalidades de una gestin de

1
cambio :
1
Fuente tomada de http://itil.osiatis.es/Curso_ITIL/ . Consultada el 14/07/2013
Figura 5.3: Proceso de gestin de cambio
A continuacin, se describe el proceso de gestin de cambio basado en ITIL

2:
La monitorizacin y el seguimiento indican que todo proceso debe ser monitorizado,
realizar informes de rendimiento y elaborar las mtricas de rendimiento
Las solicitudes de cambios se realizan mediante los RFC que son registros que
poseen las especicaciones funcionales y tcnicas de una versin, las cuales pueden
ser aceptados o no, y pueden estar clasicadas en:
Versiones de emergencia que son modicaciones que reparan de forma rpida
un error conocido
Versiones para su aprobacin y planicacin
El proceso de distribucin o implementacin de la versin es conocido tambin
como Rollout, y puede ser completo o fragmentado.
De ocurrir algn fallo, con la nueva versin implementada, se requiere tener previsto
planes o procesos de recuperacin llamados Backout. Se reinicia el proceso para
analizar la causa de la falla y tomar las correcciones respectivas.
La gestin de conguracin debe contar con los siguientes aspectos funcionales:
Manejo de versiones; debe ser capaz de guardar todas las versiones de los productos
que se manejen o se produzcan. Permitiendo realizar un reverso de los cambios,
cuando se requiera.
2
Information Technology Infrastructure Library
ITIL ( ) proporciona un marco prctico y sensato pa-
ra identicar, planicar, entregar y apoyar a los servicios de TI para el negocio. Fuente tomada de
http://www.itil-ocialsite.comy consultada el 10/09/2013
Gestin de seguimiento y dependencia de los cambios; cuando se realiza una modi-
cacin que pueda afectar a otro componente y este componente falla, es de suma
importancia llevar un estricto control de dependencia entre los mismos, as se man-
tienen la integridad de la informacin y la generacin de productos o artefactos
que se produzcan.
Rutas de auditora; toda la informacin adicional que pueda servir de utilidad para
realizar un rastreo o seguimiento a los cambios que se han realizado, por ejemplo,
cuando, por quin, por qu, cuantas veces se han realizado los cambios.
5.2.1. Gestin de cambio en MOSKitt4ME
Se detalla los aspectos funcionales de la gestin de cambio en MOSKitt4ME.
1. El control de versiones se puede realizar de la siguiente manera: Actualmente,
para la plataforma de Eclipse (EPF Composer), en los elementos de contenido
del mtodo, en la descripcin de informacin de la versin (Version Informatio n),
existe la siguiente informacin:
Versin
Fecha de cambio
Descripcin del cambio
Autores
Copyright o derechos de autor
Al contar con la informacin de versin de los cambios que se realizan, en la plata-
forma de Eclipse Process Framework Composer, que contiene la informacin mni-
ma y mediante la aplicacin, programacin o adaptacin de los plugins es posible
poseer un completo control de versiones.
2. Para determinar el control de dependencias es de suma importancia la trazabilidad
bidireccional que se realiza en SPEM 2.0 mediante la primitiva de variabilidad en los
elementos de contenido, explicada en la seccin 3.2 de la prctica especca SP 1.4
Mantener la trazabilidad bidireccional de los requisitos. No solo es aplicable a los
requisitos, sino tambin a los elementos del contenido del mtodo. El seguimiento
y control permite mantener un estricto control de dependencia.
3. El resultado de la trazabilidad bidireccional y el histrico de un control de versiones,
permiten realizar procesos de auditoras. A continuacin se muestra en la tabla 5.3:

Tabla 5.3: Prcticas especcas implementada al crear la gestin de cambios
5.3. Gestin de riesgos
Los riesgos son amenazas para los proyectos, por lo que deben ser minimizadas. Sin
embargo, existen riesgos positivos llamados oportunidades. Los riesgos son eventos no
certeros, expresados como impactos y con cierta probabilidad de ocurrencia.
A continuacin se muestra en la gura 5.4) en donde:
Las actividades estn relacionadas con el desarrollo del plan de gestin de riesgos
e implica cmo se va a realizar dicha gestin.
Incluyen identicar riesgos que afectan al proyecto
Se procede a analizar los riesgos bien sean un anlisis cuantitativo de los riesgos o
por priorizacin
El plan de respuesta de riesgos que consiste en un seguimiento y control de los
riesgos de un proyecto
Por ltimo el cierre de la gestin de los riesgos que consiste en documentar las
lecciones aprendidas
5.3.1. Gestin de riesgos en MOSKitt4ME
De acuerdo con las actividades de una gestin de riesgo descrita por [3], se puede inte-
grarlas con MOSKitt4ME mediante las siguientes consideraciones:
1. La planicacin de una gestin de riesgo consiste en una serie de actividades que
se pueden denir mediante los procesos de despliegue, y que poseen asociados una
serie de tareas, roles, artefactos y guas.

Figura 5.4: Actividades gestin de riesgos [3]
2. La identicacin de los riesgos es una labor que depender de cada proyecto que
se aborde. Sin embargo, con MOSKitt4ME, al estar basado en el enfoque de un
desarrollo dirigido por modelos, se reducen los problemas de riesgo que ocurren
comnmente a nivel tecnolgico. Entre los riesgos que se mitigan estn:
Las estrategias de desarrollo
El conocimiento de tecnologa
Ventajas:
Al estar basado en metamodelos y tcnicas de transformacin de modelos, las
implementaciones que se realicen representan el conocimiento del dominio y
por lo tanto son reutilizables
Hasta cierto punto es posible la portabilidad y la interoperabilidad
3. Para asignar la prioridad a los riesgos identicados existe un campo descriptivo
llamado nivel de riesgo (Risk Level), que se encuentra en el editor de SPEM llamado
Eclipse Process Framework Composer, en las propiedades de los elementos de los
procesos de despliegue.
4. El plan de respuesta y el cierre de los riesgos ya dependern del tipo de riesgo o
su nivel, y se pueden monitorizar mediante las dos opciones de ejecucin de SPEM
2.0, bien sean mediante planes de proyecto o representaciones ejecutables.
De aplicarse la gestin de riesgos en MOSKitt4ME, ella incidira de forma positiva en
las siguientes reas que se describen en la tabla 5.4.

Tabla 5.4: Prcticas especcas implementadas al crear la gestin de riesgos
5.4. Manejo de costos y esfuerzo
En SPEM 2.0 existen las mtricas que son elementos especiales, que contienen una o
ms restricciones, proporcionando mediciones a cualquier elemento que sea descriptible.
Se pueden denir mtricas en la denicin de trabajo; por ejemplo, los costos por hora,
promedios de calidad, errores, etc. Las mtricas son documentadas con descripciones de
contenido asociadas a la mtrica.
El uso requerido del tipo de gua para la estimacin de mtricas es imprescindible, ya que
dicha gua provee el tamao de las medidas o estndares de tamao de esfuerzo y est
asociada a una pieza de trabajo. E, incorporando adicionalmente las descripciones de
contenido a las mtricas en MOSKitt4ME, permitir la denicin de grupos de mtricas
de productividad, calidad y escala en las diferentes etapas de denicin e implementacin
del mtodo.
Gestionando a estos dos elementos antes mencionados de forma correcta, es posible im-
plementar las siguientes prcticas especcas 5.5:

Tabla 5.5: Prcticas especcas implementada al aplicar mtricas
5.5. Validaciones y Vericaciones
Las validaciones y vericaciones son las conrmaciones de que los productos o servicios se
han proporcionado con su uso deseado y reejan adecuadamente los requisitos que se han
especicado. A travs de MOSKitt4ME es posible realizar las conrmaciones requeridas
de los productos, no obstante mediante las restricciones OCL, se propone dar un mayor
aporte para realizar el cumplimiento de forma automtica a estas reas de procesos.
5.5.1. Denicin de OCL
Object Constraint Language (OCL) es un lenguaje notacional para el anlisis y diseo
de sistemas software. Fue desarrollado como un lenguaje de modelado de negocios y tiene
sus races en el mtodo Syntropy.
Est denido como lenguaje estndar para dar soporte al Unied Modeling Language
(UML), que es un estndar de OMG para el anlisis y diseo orientado a objetos. OCL
da soporte a UML para la especicacin de restricciones y consultas sobre modelos,
permitiendo denir y documentar los modelos UML de forma ms precisa [19]

Algunas de las caractersticas de las restricciones OCL son:
Al ser un lenguaje de especicacin pura, se garantiza que no existan efectos se-
cundarios. Al evaluarse las expresiones, simplemente devuelve un valor
No se puede cambiar nada en el modelo, las OCL se pueden utilizar para especicar
un cambio de estado (por ejemplo, en un post-condiciones)
Por no ser un lenguaje de programacin, no es posible escribir lgicas de progra-
macin, invocar procesos, activar operaciones no consultadas en OCL
Las expresiones OCL deben ajustarse a las normas de conformidad del estndar
denido
La evaluacin de la expresin es instantnea, es decir, el estado del objeto no puede
cambiar durante su evaluacin
Las instrucciones OCL pueden ser usadas por UML y otros lenguajes basados en MOF,
para especicar restricciones, expresiones de navegacin, expresiones booleanas, consultas
y otras expresiones incluidas en estos modelos
5.5.2. Uso de OCL

OCL puede ser usado con distintos nes:
Para especicar invariantes sobre clases y tipos en el modelo de clases
Para especicar pre-condiciones y post-condiciones sobre operaciones y mto-
dos
Para describir guardas (en statecharts y otros elementos)
Como lenguaje de navegacin
Como lenguaje de consultas y propiedades derivadas
OCL es utilizado tambin para especicar la semntica de UML Uso de las restric-
ciones OCL en MOSKitt4ME Se podra complementar el conjunto de primitivas
que actualmente posee SPEM 2.0 para mejorar y automatizar las reas de procesos
de validacin y de vericacin mediante la incorporacin de las restricciones OCL
de la siguiente manera:
Asegurar que todos los requisitos posean identicadores nicos.

Los parmetros de los requisitos que sean reutilizables posean un tipo vlido, por
ejemplo los tipos de activos reutilizables soportados por MOSKitt4ME: Model
Transformation, Graphical Editor, Form-based Editor, Textual Editor y
Meta-Model
La vericacin de las relaciones de trazabilidad que se hayan denido entre los
elementos de contenido del mtodo, cuando se haya activado la variabilidad por
contribucin.
Al incorporar las restricciones de OCL se pueden implementar las siguientes prcticas
especcas 5.6:
Tabla 5.6: Prcticas especcas implementada al usar restricciones OCL

Captulo 6
Conclusiones y trabajos futuros
En este trabajo se ha presentado la integracin de CMMI-DEV v1.3 del nivel de madurez
2 y 3 con MOSKitt4ME. Para ello, se ha realizado una evaluacin completa y detallada
de la relacin que existe entre CMMI-DEV v1.3 y MOSKitt4ME. Adicionalmente, se
realizaron una serie de propuestas para extender MOSKitt4ME y de esta forma alcanzar
R

las mejores prcticas descritas por CMMI .
Con el propsito de realizar una evaluacin y un anlisis objetivos se sigui el mtodo de
SCAMPI v1.3 descrito en la Subseccin 2.1.3, en donde se han evaluado las 140 prcticas
especcas que comprenden los niveles de madurez 2 y 3. Se logr establecer las relaciones
y divergencias que existen entre MOSKitt4ME y CCMI-DEV. Se pueden ver resumidos
los resultados de forma cuantitativa en la tabla 3.1 y la tabla 4.1.
Durante la evaluacin se ha determinado que las reas de procesos que han sido imple-
mentadas representan el 61 % aproximadamente. Esto corresponde a 13 reas de procesos
que mantienen relacin con MOSKitt4ME (de las 18 que presenta CMMI-DEV v1.3 del
nivel de madurez 2 y 3) que se consideran Satisfechas.
Se han logrado determinar importantes relaciones entre CMMI-DEV v1.3 y MOSKitt4ME
para los niveles de madurez 2 y 3. Entre ellas se pueden mencionar:
La trazabilidad bidireccional que se puede llevar a cabo mediante MOSKitt4ME
mediante la variabilidad, especcamente mediante el tipo de variabilidad llamado
contribucin.
La monitorizacin de los proyectos que se puede realizar mediante la fase de apli-
cacin del mtodo (ambiente CASE), lo que permite llevar un control del progreso
del proyecto.
94
Captulo 6. Conclusiones y trabajos futuros 95
El proceso estndar (los componentes de los procesos bsicos) que se dene en
SPEM 2.0 como el patrn de capacidades (al ser reusables).
Los diccionarios, bibliotecas, procedimientos, criterios e informes que se pueden
denir mediante las guas de SPEM 2.0 y sus diferentes tipos de guas.
Las relaciones anteriormente descritas entre CMMI-DEV v1.3 y MOSKitt4ME son de vi-
tal importancia en las organizaciones, debido a que proporcionan calidad en sus procesos
y mtodos en el desarrollo de software. Por ejemplo:
La trazabilidad bidireccional permite la generacin de productos con mejor
calidad mediante una apropiada obtencin de requerimientos.
La monitorizacin de los proyectos garantiza que los procesos estn bien carac-
terizados y comprendidos al hacerlos ms visibles.
El proceso estndar da soporte a los procesos estndares de la organizacin, les
ayuda a mantener la integridad y la consistencia en los mtodos y productos que
se denen mediante MOSKitt4ME.
Existen otras relaciones conceptuales y semnticas que han sido fundamentales para
determinar el grado de implementacin entre las prcticas especcas del nivel de madurez
2 y 3 de CMMI-DEV v1.3 y MOSKitt4ME. Las cuales se pueden ver resumidas en la
tabla 3.2 y la tabla 4.2.
Para lograr disminuir el grado de implementacin que es el 39 % restante e incluso incor-
porar reas de proceso que no presentan puntaje, se han propuesto algunas alternativas
tericas que pueden ser implementadas en MOSKitt4ME, y as estar alienadas a las
mejores prcticas propuestas por CMMI-DEV v1.3.
Las propuestas que han surgido se han basado en las prcticas especcas de CMMI-DEV
v1.3 del nivel de madurez 2 y 3 que no han sido implementadas en MOSKitt4ME. El
propsito fue eliminar las brechas que se detectaron y as extender las funcionalidades
que actualmente presenta MOSKitt4ME.
Algunas ventajas en las organizaciones al implementar las propuestas seran las siguien-
tes:
Durante la ejecucin de los procesos del mtodo, de poseer un plan de proyecto la
organizacin puede generar sus planes, indicadores y estimaciones que les sirven de
base de conocimiento:
Captulo . Conclusiones y trabajos futuros 96
Se pueden crear las lneas bases, fundamentales para determinar las posibles
desviaciones del plan y por ende tomar las acciones correctivas.
Se incluyen los parmetros en la planicacin de los proyectos, como son las
deniciones del calendario y de los costos.
Otro benecio es que existen trminos que son comunes entre SPEM 2.0 y
Microsoft Project 2010 (herramienta de gestin de proyecto que se analiz),
ver Tabla 7 Resumen comparativo SPEM 2.0 vs. Microsoft Project 2010.
Contar con una gestin de cambio; para ello se debe aprovechar de las funcionali-
dades de la plataforma de Eclipse con la informacin de la versin y la variabilidad
por contribucin (primitiva de SPEM 2.0) y adicionalmente incorporar las audi-
toras. Estos puntos traeran como consecuencia la reduccin de nmero de fallas,
controles de cambio estndar, maximizan la productividad y minimizan los errores.
Al incorporar validaciones y vericaciones de forma automtica mediante el uso
de las restricciones de OCL, se garantiza que desde todas las fases del desarrollo
del mtodo se realicen los procesos de validaciones y vericaciones, por ejemplo
Asegurar que todos los requisitos posean identicadores nicos. Por consecuencia,
productos y mtodos con mejor calidad.
Aspectos a considerar para trabajos futuros sern implementar las propuestas tericas
que han surgido a lo largo del anlisis realizado.
Por otro lado, se plantea la creacin de una gestin de cambio, como una propuesta o
un control de las modicaciones que puedan surgir durante la creacin de mtodos de
desarrollo de software en MOSKitt4ME. Sin embargo, existen tcnicas o propuestas que
describen tipos de propagacin de cambio en el contexto de la ingeniera de mtodo [20]
que podra ser evaluado.

Apndice A
Glosario
A.1. Artefactos
Representan de forma tangible la evidencia del trabajo que se realiza y pueden incluir
las polticas de la organizacin u otros productos de trabajo a nivel de aplicacin. Para
vericar la implementacin del modelo de la prctica asociada son necesarios sucientes
artefactos que demuestran y corroboran el trabajo que se realiza.
A.2. Armaciones
Son declaraciones orales o escritas que conrman o apoyan la implementacin (o la falta
de implementacin) de una prctica de modelo, proporcionadas por quienes implementan
la prctica.
A.3. Lnea Base
El conjunto de especicaciones que sean claves o productos de trabajo, que se han re-
visado y acordado en un momento del tiempo, servirn para comparar la planicacin
original del proyecto con el desarrollo posterior, en donde slo se podr modicar dichos
conjuntos de especicaciones mediante acuerdos previamente discutidos por las personas
involucradas.
97
Glosario Glosario 98
A.4. Gestin Conguracin
Una disciplina que aplica la direccin tcnica y administrativa, y la supervisin para
(1) identicar y documentar las caractersticas funcionales y fsicas de un elemento de
conguracin, (2) controlar los cambios a esas caractersticas, (3) registrar e informar
sobre el proceso de cambios y su estado de implementacin, y (4) vericar el cumplimiento
de los requisitos especicados. [8]
A.5. Requisitos
Son condiciones o capacidades que son necesitadas para dar solucin a un problema o
para lograr un objetivo.
A.6. Revisiones entre Pares
Son las vericaciones de los productos de trabajo que efectan personas con el mismo co-
nocimiento que los autores de los desarrollos de los productos de trabajo, con el propsito
reconocer y eliminar posibles defectos.

Bibliografa
[1] A. Niknafs and R. Ramsin, Computer-aided method engineering: An analysis of
existing environments, in Advanced Information Systems Engineering (Z. Bellahs-
ne and M. Lonard, eds.), vol. 5074 of Lecture Notes in Computer Science, pp. 525
540, Springer Berlin Heidelberg, 2008.
[2] F. Ruiz and J. Verdugo, Gua de Uso de SPEM 2 con EPF Composer. Universidad
de Castilla-La Mancha, Abril 2008.
[3] INTECO, Gua avanzada de gestin de riesgo, 2008.
R for Development, Version 1.3. Carnegie Mellon, Noviembre 2010.

[4] SEI, CMMI
[5] M. Cervera, M. Albert, V. Torres, and V. Pelechano, A model-driven approach for
the design and implementation of software development methods, in International
Journal of Information System Modeling and Design (IJISMD), 2012.
[6] S. Brinkkemper, Method engineering: engineering of information systems develop-
ment methods and tools, Information and Software Technology, vol. 38, no. 4,
pp. 275 280, 1996.
R Appraisal Method for Process Improvement (SCAMPI SM)

[7] SEI, Standard CMMI
A v1.3. Carnegie Mellon, Marzo 2011.
[8] M. L. Peralta, Asistente para la evaluacin de cmmisw, Master's thesis, ITBA,
2004.
[9] OMG, Business Process Model and Notation (BPMN) (v2.0). OMG Object Mana-
gemet Group, 2011.
[10] M. Cervera, M. Albert, V. Torres, and V. Pelechano, The moskitt4me approach:
Providing process support in a method engineering context, in Conceptual Modeling
(P. Atzeni, D. Cheung, and S. Ram, eds.), vol. 7532 of Lecture Notes in Computer
Science, pp. 228241, Springer Berlin Heidelberg, 2012.
99
Bibliografa 100
[11] M. Cervera, Model driven method enginneering. a supporting infraestructure, Mas-
ter's thesis, Universidad Politcnica de Valencia. Departamento de Sistemas Infor-
mticos y Computacin., 2010.
[12] F. Harmsen, S. Brinkkemper, and J. L. H. Oei, Situational method engineering
for informational system project approaches, in Proceedings of the IFIP WG8.1
Working Conference on Methods and Associated Tools for the Information Systems
Life Cycle, (New York, NY, USA), pp. 169194, Elsevier Science Inc., 1994.
[13] M. Cervera, M. Albert, V. Torres, and V. Pelechano, Turning method enginee-
ring support into reality, in Engineering Methods in the Service-Oriented Context
(J. Ralyt, I. Mirbel, and R. Deneckre, eds.), vol. 351 of IFIP Advances in Infor-
mation and Communication Technology, pp. 138152, Springer Berlin Heidelberg,
2011.
[14] OMG, Software & Systems Process Engineering Meta-Model Specication (SPEM),
(v2.0). OMG Object Managemet Group, 2008.
[15] S. Bezerra, A. Lins De Vasconcelos, and R. Cavalcante, Mapeamento dos conceitos
do guia do cmmi em notaes do spem no contexto da deniao do processo de
software, vol. v. 5, pp. 8392, INFOCOMP (UFLA), 2006.
[16] C. Portela, A. Vasconcelos, A. Silva, E. S. Ariane Sinimb, M. Ronny, W. Lira,
and S. Oliveira, A comparative analysis between bpmn and spem modeling stan-
dards in the software processes context, in The 5th International Conference on
Computer Science and Software Engineering (CSSE 2014), January 12-14, 2014,
Shenzhen,China, vol. 5, pp. 330339, Journal of Software Engineering and Applica-
tions, Mayo 2012.
[17] V. Esterkin and C. Pons, Anlisis y evaluacin del mdd (model driven software
development) desde la perspectiva del nivel 2 del cmmi-dev 1.3, in Workshop Inge-
niera de software (WIS) (C. Commons, ed.), Centro de Altos Estudios en Tecnologa
Informtica (CAETI), 2012.
[18] OMG, Reusable Asset Specication (RAS). OMG Available Specication version 2.2.
OMG Object Managemet Group, 2005.
[19] OMG, OMG Object Constraint Language (OCL) (v2.3.1). OMG Object Managemet
Group, 2012.
[20] M. Saeki, Conguration management in a method engineering context, in Advanced
Information Systems Engineering (E. Dubois and K. Pohl, eds.), vol. 4001 of Lecture
Notes in Computer Science, pp. 384398, Springer Berlin Heidelberg, 2006.

Tesis Cmmi Dev Moskitt4me

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tesis Cmmi Dev Moskitt4me

Загружено:

Авторское право:

Доступные форматы

Mster Universitario en Ingeniera del Software, Mtodos

Formales y Sistemas de Informacin

Universitat Politcnica de Valncia

Departamento de Sistemas Informticos y

CMMI aplicado a entornos de

Curso Acadmico 2012/2013

la mejora y evaluacin de mtodos para el desarrollo y ejecucin de sistemas de softwa-

re  y MOSKitt4ME  una herramienta para la denicin de mtodos de desarrollo de

software y la construccin de las herramientas CASE que les dan soporte.

Para conseguir el objetivo descrito, se ha aplicado a MOSKitt4ME las mejores prcti-

madurez 2 y 3, con el n de obtener entornos de desarrollo de software donde se apli-

se realiz por medio de la evaluacin, anlisis y determinacin de las relaciones y diver-

v1.3 y lograr una mayor sinergia entre ambos.

tools that support them.

greater synergy between them.

pas. Es admirable la vocacin y profesionalismo de muchos de los docentes que imparten

cionarlos a todos porque llenara muchas pginas...Sin embargo, de quien he aprendido

mucho, indiscutiblemente, es de Angel Cuenca, gracias a todo su apoyo y amistad a lo

Valencia, Septiembre 2013

ndice de Tablas xii

1.3. Contexto de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1.1. Niveles de madurez . . . . . . . . . . . . . . . . . . . . . 8

2.1.1.2. Niveles de capacidad . . . . . . . . . . . . . . . . . . . . . 10

2.1.2. Componentes del rea de proceso . . . . . . . . . . . . . . . . . . . 10

2.2. Marco metodolgico para construir mtodos de desarrollo de software 

2.2.1. Ingeniera de mtodos . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2. SPEM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2.1. Caractersticas generales de SPEM 2.0 . . . . . . . . . . . 19

2.2.2.2. Conceptos claves SPEM 2.0 . . . . . . . . . . . . . . . . . 20

2.2.2.3. Descripcin detallada . . . . . . . . . . . . . . . . . . . . 21

3. Comparacin de CMMI Vs MOSKitt4ME - Nivel de Madurez 2 27

3.2. Gestin de requisitos (REQM) . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1. SG 1 Gestionar los requisitos . . . . . . . . . . . . . . . . . . . . . 28

3.2.1.1. SP 1.1 Comprender los requisitos . . . . . . . . . . . . . . 28

3.2.1.2. SP 1.2 Obtener el compromiso sobre los requisitos . . . . 28

3.2.1.3. SP 1.3 Gestionar los cambios a los requisitos . . . . . . . 29

3.2.1.4. SP 1.4 Mantener la trazabilidad bidireccional de los re-

3.2.1.5. SP 1.5 Asegurar el alineamiento entre el trabajo del pro-

3.3. Monitorizacin y control del proyecto (PMC) . . . . . . . . . . . . . . . . 30

3.3.1. SG 1 Monitorizar el proyecto frente al plan . . . . . . . . . . . . . 30

3.3.1.1. SP 1.1 Monitorizar los parmetros de planicacin del

3.3.1.2. SP 1.2 Monitorizar los compromisos . . . . . . . . . . . . 31

3.3.1.3. SP 1.3 Monitorizar los riesgos del proyecto . . . . . . . . 31

3.3.1.4. SP 1.4 Monitorizar la gestin de los datos . . . . . . . . . 31

3.3.1.5. SP 1.5 Monitorizar la involucracin de las partes interesadas 32

3.3.1.6. SP 1.6 Llevar a cabo las revisiones del progreso . . . . . . 32

3.3.1.7. SP 1.7 Llevar a cabo las revisiones de hitos . . . . . . . . 32

3.3.2. SG 2 Gestionar las acciones correctivas hasta su cierre . . . . . . . 33

3.4. Planicacin del proyecto (PP) . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.1. SG 1 Establecer las estimaciones . . . . . . . . . . . . . . . . . . . 33

3.4.1.1. SP 1.1 Estimar el alcance del proyecto . . . . . . . . . . . 33

3.4.1.2. SP 1.2 Establecer las estimaciones de los atributos de los

3.4.1.4. SP 1.4 Estimar el esfuerzo y el coste . . . . . . . . . . . . 35

3.4.2. SG 2 Desarrollar un plan de proyecto . . . . . . . . . . . . . . . . . 35

3.4.2.1. SP 2.1 Establecer el presupuesto y el calendario . . . . . 36

3.4.2.2. SP 2.2 Identicar los riesgos del proyecto . . . . . . . . . 36

3.4.2.3. SP 2.3 Planicar la gestin de los datos . . . . . . . . . . 36

3.4.2.4. SP 2.4 Planicar los recursos del proyecto . . . . . . . . . 36

3.4.2.5. SP 2.5 Planicar el conocimiento y las habilidades nece-

3.4.2.6. SP 2.6 Planicar la involucracin de las partes interesadas 37

3.4.2.7. SP 2.7 Establecer el plan de proyecto . . . . . . . . . . . 38

3.4.3. SG 3 Obtener el compromiso con el plan . . . . . . . . . . . . . . . 38

3.5. Aseguramiento de la calidad del proceso y del producto (PPQA) . . . . . 38

re y MOSKitt4ME una herramienta para la denicin de mtodos de desarrollo de

madurez 2 y 3, con el n de obtener entornos de desarrollo de software donde se apli-

2.2. Marco metodolgico para construir mtodos de desarrollo de software

3.3.1.1. SP 1.1 Monitorizar los parmetros de planicacin del

3.4. Planicacin del proyecto (PP) . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.2.2. SP 2.2 Identicar los riesgos del proyecto . . . . . . . . . 36

3.4.2.3. SP 2.3 Planicar la gestin de los datos . . . . . . . . . . 36

3.4.2.4. SP 2.4 Planicar los recursos del proyecto . . . . . . . . . 36

3.4.2.5. SP 2.5 Planicar el conocimiento y las habilidades nece-

3.4.2.6. SP 2.6 Planicar la involucracin de las partes interesadas 37

3.6. Gestin de conguracin (CM) . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6.1.1. SP 1.1 Identicar los elementos de conguracin . . . . . 41

3.6.1.2. SP 1.2 Establecer un sistema de gestin de conguracin 41

3.6.2.2. SP 2.2 Controlar los elementos de conguracin . . . . . 42

3.6.2.3. SP 3.1 Establecer los registros de gestin de conguracin 43

3.6.2.4. SP 3.2 Realizar auditoras de conguracin . . . . . . . . 43

4.2.1.3. SP 1.3 Identicar las mejoras de procesos de la organizacin 52

4.2.1.4. SG 2 Planicar e implementar las acciones de proceso . . 52

4.5.1. SG 1 Utilizar el proceso denido del proyecto . . . . . . . . . . . . 56

4.5.1.1. SP 1.1 Establecer el proceso denido del proyecto . . . . 56

4.6.3.2. SP 3.2 Establecer una denicin de la funcionalidad y de