Post on 11-Feb-2017
transcript
REPRESENTACIÓN EN EL NÚCLEO DE SEMAT DE PRÁCTICAS DE MÉTODOS DE
DESARROLLO BASADOS EN PLANES
Autor:
Ing. Leidy Diana Jiménez Pinzón
Director:
Ph.D. Carlos Mario Zapata Jaramillo
MAESTRÍA EN INGENIERÍA DE SISTEMAS
Universidad Nacional de Colombia
Sede Medellín
2016
DEDICATORIA
A mis padres por su apoyo absoluto en todos los proyectos que me propongo, por sus constantes
palabras, valiosos consejos y por enseñarme a perseguir mis sueños hasta cumplirlos.
A Esteban Arango, por su acompañamiento en todo este proceso, su ayuda y amor incondicional.
AGRADECIMIENTOS
Al docente Carlos Mario Zapata Jaramillo, quien me ha acompañado desde mi proceso de formación
como ingeniera de sistemas, y quien ha contribuido a mi formación personal y profesional durante el
desarrollo de esta Tesis de maestría. En todos estos años me permitió conocer a un excelente
docente y ser humano. Gracias a su paciencia, apoyo invaluable, enseñanzas y críticas constructivas
se hizo posible la realización de esta Tesis.
iv
Contenido
1. INTRODUCCIÓN ............................................................................................................................... 1
1.1 Justificación ......................................................................................................................... 1
1.2 Planteamiento del problema .............................................................................................. 2
1.3 Objetivo general .................................................................................................................. 2
1.4 Objetivos específicos ........................................................................................................... 2
1.5 Metodología ........................................................................................................................ 3
Observación ................................................................................................................. 3
Descripción .................................................................................................................. 3
Revisión ....................................................................................................................... 3
Integración .................................................................................................................. 4
Clasificación ................................................................................................................. 4
Conclusión ................................................................................................................... 4
1.6 Estructura de la Tesis .......................................................................................................... 5
2 MARCO TEÓRICO ......................................................................................................................... 5
2.1 Semat (Software Engineering method and theory) ............................................................. 5
Alfas ............................................................................................................................. 6
Espacios de actividad ................................................................................................ 11
Competencias ............................................................................................................ 12
Elementos del núcleo de Semat ................................................................................ 14
2.2 CDM (Custom Development Method) ............................................................................... 16
Definición de fases, actividades, entregables y responsables .................................. 19
2.3 UNC-Method ..................................................................................................................... 23
Definición de fases, actividades, artefactos y responsables ..................................... 23
2.4 RUP .................................................................................................................................... 25
Disciplinas, actividades, artefactos y roles [9] .......................................................... 28
2.5 Prácticas de ingeniería de software .................................................................................. 29
Desarrollo iterativo ................................................................................................... 30
Gestión de requisitos ................................................................................................ 30
Modelado visual ........................................................................................................ 30
Desarrollo basado en componentes ......................................................................... 30
Verificación continua de la calidad ........................................................................... 31
v
Control de cambios de software ............................................................................... 31
Modelado de objetos de dominio ............................................................................. 31
Visibilidad del progreso y resultados ........................................................................ 31
Establecimiento de actividades para satisfacer las prácticas de calidad requeridas 31
Gestión de valor agregado ........................................................................................ 32
Planificación del proceso ........................................................................................... 32
Suministro de recursos .............................................................................................. 32
Formación del personal ............................................................................................. 32
Monitoreo y control del proceso .............................................................................. 32
Asignación de responsabilidad .................................................................................. 33
Determinación de estimaciones de esfuerzo de trabajo y costo .............................. 33
3 ANTECEDENTES ......................................................................................................................... 33
4 CAPÍTULO 4. PROPUESTA DE SOLUCIÓN ................................................................................... 36
4.1 Representación de las prácticas en el núcleo de Semat ................................................... 36
4.2 Representación gráfica del método CDM ......................................................................... 37
Fase: Definición ......................................................................................................... 41
Fase: Modelado de requisitos ................................................................................... 52
Fase: Diseño de sistema y generación ...................................................................... 55
Fase: Transición a la producción ............................................................................... 58
4.3 Representación gráfica del UNC-Method ......................................................................... 62
Fase: Contexto del software ...................................................................................... 63
Fase: Análisis del problema ....................................................................................... 68
Fase: propuestas de solución .................................................................................... 69
Fase: esquema conceptual ........................................................................................ 70
4.4 Representación gráfica del método RUP .......................................................................... 72
Fase: Inicio ................................................................................................................. 73
Fase: Elaboración ...................................................................................................... 98
Fase: Construcción .................................................................................................. 104
Fase: Transición ....................................................................................................... 109
5 VALIDACIÓN ............................................................................................................................ 117
5.1 Validación del método CDM ........................................................................................... 117
5.2 Validación del UNC-METHOD .......................................................................................... 121
Caso de estudio 1 .................................................................................................... 121
vi
5.3 Validación de RUP ........................................................................................................... 126
6 CONCLUSIONES ....................................................................................................................... 136
7 ANEXOS ................................................................................................................................... 140
FIGURAS
Figura 1. Alfas del núcleo ............................................................................................................ 6
Figura 2. Espacios de actividad del núcleo ......................................................................... 11
Figura 3. Competencias del núcleo ......................................................................................... 13
Figura 4. Estructura de CDM ..................................................................................................... 16
Figura 5. Orden de acción de las tareas de la fase Definición ......................................... 19
Figura 6. Orden de acción de tareas de la fase Modelado de requisitos ............... ¡Error!
Marcador no definido.
Figura 7. Orden de acción de tareas de la fase Diseño de sistema y generación ...... 22
Figura 8. Orden de acción de tareas de la fase Transición a la producción ................ 23
Figura 9. Estructura de RUP ...................................................................................................... 26
Figura 10. Elementos de método RUP .................................................................................... 34
Figura 11. Componentes del método RUP ............................................................................ 34
Figura 12. Artefactos y actividades de la disciplina requisitos ....................................... 35
Figura 13. Resultados del trabajo sobre la estructura RUP en Semat ........................... 36
Figura 14. Práctica del área de conocimiento clientes ...................................................... 37
Figura 15. Prácticas del área de conocimiento solución ................................................... 37
Figura 16. Prácticas del área de conocimiento esfuerzo ................................................... 37
Figura 17. Prácticas de los métodos CDM y PJM ................................................................ 38
Figura 18. Definición de prácticas mediante los alfas ....................................................... 41
Figura 19. Definición de prácticas mediante espacios de actividad .............................. 41
Figura 20. Secuencia de actividades en la fase Definición ............................................... 44
Figura 21. Definición de la práctica Modelado de objetos de dominio .......................... 45
Figura 22. Definición de la práctica Modelado de objetos de dominio .......................... 46
Figura 23. Definición de la práctica Gestión de requisitos ............................................... 47
Figura 24. Definición de la práctica Asignación de responsabilidades ........................ 48
Figura 25. Definición de la práctica Suministro de recursos ........................................... 49
Figura 26. Definición de la práctica Monitoreo y control de recursos ........................... 49
Figura 27. Definición de la práctica Planificación del proceso ........................................ 50
Figura 28. Definición de la práctica Planificación del proceso ........................................ 51
Figura 29. Competencias de los métodos CDM y PJM ...................................................... 61
Figura 30. Roles del método CDM y PJM ............................................................................... 61
Figura 31. Progreso de un proyecto al aplicar la metodología CDM Fast Track ......... 62
Figura 32. Prácticas del UNC-Method ..................................................................................... 62
Figura 33. Secuencia de actividades en la fase contexto del software
........................................................................................................................................................... 65
Figura 34. Representación gráfica de las prácticas Asignación de responsabilidades
y Formación de personal............................................................................................................ 65
vii
Figura 35. Representación gráfica de la práctica Modelado de objetos del dominio 66
Figura 36. Representación gráfica de la práctica Modelado visual ................................ 67
Figura 37. Representación gráfica de la práctica Monitoreo y control del proceso .. 67
Figura 38. Competencias del UNC-Method ........................................................................... 71
Figura 39. Roles del UNC-Method ............................................................................................ 71
Figura 40. Progreso de un proyecto al aplicar el UNC-Method........................................ 71
Figura 41. Mejores prácticas del método RUP ..................................................................... 72
Figura 42. Secuencia de actividades en la fase inicio ........................................................ 79
Figura 43. Representación gráfica de la práctica Gestión de requisitos ...................... 85
Figura 44. Representación gráfica de la práctica Modelado visual ................................ 89
Figura 45. Representación gráfica de la práctica Control de cambios de software... 97
Figura 46. Recursos del método RUP ................................................................................... 115
Figura 47. Competencias del método RUP .......................................................................... 116
Figura 48. Roles del método RUP .......................................................................................... 116
Figura 49. Progreso de un proyecto al aplicar la metodología RUP ............................ 117
Figura 50. Diálogo controlado ................................................................................................ 122
Figura 51. Actividad Desarrollar entrevista interesado-analista y producto de trabajo
Diálogo controlado .................................................................................................................... 122
Figura 52. Esquema pre-conceptual ..................................................................................... 122
Figura 53. Actividad Establecer un vocabulario común y producto de trabajo
Esquema pre-conceptual ......................................................................................................... 122
Figura 54. Organigrama ............................................................................................................ 122
Figura 55. Actividad Identificar los actores internos y externos de la organización y
producto de trabajo Organigrama ......................................................................................... 122
Figura 56. Modelo del dominio ............................................................................................... 123
Figura 57. Actividad Establecer un vocabulario común y producto de trabajo Modelo
del dominio .................................................................................................................................. 123
Figura 58. Actividad Establecer limitaciones del proceso y producto de trabajo
Reglas del negocio .................................................................................................................... 123
Figura 59. Reglas del negocio ................................................................................................ 123
Figura 60. Actividad Caracterizar el dominio del problema y producto de trabajo
Diagrama de procesos .............................................................................................................. 124
Figura 61. Diagrama de procesos .......................................................................................... 124
Figura 62. Actividad Caracterizar el dominio del problema y producto de trabajo
Tabla explicativa del diagrama de procesos ...................................................................... 124
Figura 63. Tabla explicativa de procesos ............................................................................ 124
Figura 64. Actividad Caracterizar el dominio del problema y producto de trabajo
Diagrama de objetivos .............................................................................................................. 125
Figura 65. Diagrama de objetivos .......................................................................................... 125
Figura 66. Actividad Caracterizar el dominio del problema y producto de trabajo
Diagrama causa-efecto ............................................................................................................. 125
Figura 67. Diagrama de causa y efecto ................................................................................ 125
Figura 68. Actividad Desarrollar el diccionario de datos y producto de trabajo
Diccionario de datos ................................................................................................................. 126
Figura 69. Diccionario de datos .............................................................................................. 126
viii
Figura 70. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina requisitos .............................................................................................................. 128
Figura 71. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina gestión de proyectos ......................................................................................... 130
Figura 72. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina análisis y diseño ................................................................................................. 132
Figura 73. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina despliegue ............................................................................................................ 133
Figura 74. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina implementación .................................................................................................. 134
Figura 75. Representación en Semat de actividades, roles y productos de trabajo de
la disciplina entorno .................................................................................................................. 135
TABLAS
Tabla 1. Conceptos principales de Semat ............................................................................... 5
Tabla 2. Estados del alfa Oportunidad ..................................................................................... 7
Tabla 3. (Parte 1/2) Estados del alfa Interesados ................................................................... 7
Tabla 3. (Parte 2/2) Estados del alfa Interesados ................................................................... 8
Tabla 4. Estados del alfa Requisitos ......................................................................................... 8
Tabla 5. Estados del alfa Sistema de software ....................................................................... 9
Tabla 6. (Parte 1/2) Estados del alfa Trabajo........................................................................... 9
Tabla 6. (Parte 2/2) Estados del alfa Trabajo......................................................................... 10
Tabla 7. Estados del alfa Equipo .............................................................................................. 10
Tabla 8. (Parte 1/2) Estados del alfa Forma de trabajo ....................................................... 10
Tabla 8. (Parte 2/2) Estados del alfa Forma de trabajo ....................................................... 11
Tabla 9. (Parte 1/2) Sintaxis gráfica de elementos del núcleo ......................................... 15
Tabla 9. (Parte 2/2) Sintaxis gráfica de elementos del núcleo ......................................... 16
Tabla 10. (Parte 1/2) Fases del modelo CDM ........................................................................ 17
Tabla 10. (Parte 2/2) Fases del modelo CDM ........................................................................ 18
Tabla 11. Tareas, entregables del PJM ................................................................................... 18
Tabla 12. Procesos, tareas, entregables y responsables de la fase Definición .......... 19
Tabla 13. Procesos, tareas, entregables y responsables de la fase Modelado de
requisitos ........................................................................................................................................ 20
Tabla 14. Procesos, tareas, entregables y responsables de la fase Diseño de
sistema y generación .................................................................................................................. 21
Tabla 15. Procesos, tareas, entregables y responsables de la fase Transición a la
producción ..................................................................................................................................... 22
Tabla 16. Fases del UNC-Method ............................................................................................. 23
Tabla 17. Actividades, entregables y responsables en la fase del contexto del
software .......................................................................................................................................... 24
Tabla 18. Actividades, entregables y responsables en la fase análisis del problema.
Síntesis del autor ......................................................................................................................... 24
ix
Tabla 19. Actividades, entregables y responsables en la fase propuestas de
solución .......................................................................................................................................... 25
Tabla 20. Actividades, entregables y responsables en la fase esquema conceptual 25
Tabla 21. Objetivos de las fases del método RUP ............................................................... 27
Tabla 22. (Parte 1/2) Descripción de principales tareas..................................................... 38
Tabla 22. (Parte 2/2) Descripción de principales tareas..................................................... 39
Tabla 23. (Parte 1/2) Descripción de principales entregables .......................................... 39
Tabla 23. (Parte 2/2) Descripción de principales entregables .......................................... 40
Tabla 24. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la
fase definición ............................................................................................................................... 41
Tabla 24. (Parte de 2/4) Espacios de actividad, alfas, productos de trabajo y roles en
la fase definición .......................................................................................................................... 42
Tabla 24. (Parte de 3/4) Espacios de actividad, alfas, productos de trabajo y roles en
la fase definición .......................................................................................................................... 43
Tabla 24. (Parte de 4/4) Espacios de actividad, alfas, productos de trabajo y roles en
la fase definición .......................................................................................................................... 44
Tabla 25. (Parte 1/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase modelado de requisitos ..................................................................................................... 52
Tabla 25. (Parte 2/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase modelado de requisitos ..................................................................................................... 53
Tabla 25. (Parte 3/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase modelado de requisitos ..................................................................................................... 54
Tabla 26. (Parte 1/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase diseño de sistema y generación ..................................................................................... 55
Tabla 26. (Parte 2/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase diseño de sistema y generación ..................................................................................... 56
Tabla 26. (Parte 3/3) Espacios de actividad, alfas, productos de trabajo y roles en la
fase diseño de sistema y generación ..................................................................................... 57
Tabla 27. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición a la producción ................................................................................................ 58
Tabla 27. (Parte 2/4) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición a la producción ................................................................................................ 59
Tabla 27. (Parte 3/4) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición a la producción ................................................................................................ 60
Tabla 27. (Parte 4/4) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición a la producción ................................................................................................ 61
Tabla 28. Descripción de entregables del UNC-Method .................................................... 63
Tabla 29. Espacios de actividad, alfas, productos de trabajo, actividades y roles de
la fase análisis del problema ..................................................................................................... 63
Tabla 29. Espacios de actividad, alfas, productos de trabajo, actividades y roles de
la fase análisis del problema ..................................................................................................... 64
Tabla 30. Espacios de actividad, alfas, productos de trabajo, actividades y roles de
la fase análisis del problema ..................................................................................................... 68
Tabla 31. Espacios de actividad, alfas, productos de trabajo, actividades y roles de
la fase propuestas de solución ................................................................................................ 69
x
Tabla 32. Espacios de actividad, alfas, productos de trabajo, actividades y roles de
la fase esquema conceptual ...................................................................................................... 70
Tabla 33. (Parte 1/2) Descripción de principales artefactos ............................................. 72
Tabla 33. (Parte 2/2) Descripción de principales artefactos ............................................. 73
Tabla 34. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 73
Tabla 34. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 74
Tabla 34. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 75
Tabla 34. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 76
Tabla 34. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 77
Tabla 34. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase inicio ....................................................................................................................................... 78
Tabla 35. (Parte 1/7) Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ........................................................................................................................... 98
Tabla 35. (Parte 2/7) Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ........................................................................................................................... 99
Tabla 35. (Parte3/7) Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ......................................................................................................................... 100
Tabla 35. (Parte 4/7) Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ......................................................................................................................... 101
Tabla 35. (Parte 5/7) Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ......................................................................................................................... 102
Tabla 35. (Parte 6/7)Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ......................................................................................................................... 103
Tabla 35. (Parte 7/7)Espacios de actividad, alfas, productos de trabajo y roles en la
fase elaboración ......................................................................................................................... 104
Tabla 36. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 104
Tabla 36. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 105
Tabla 36. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 106
Tabla 36. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 107
Tabla 36. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 108
Tabla 36. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase construcción ....................................................................................................................... 109
Tabla 37. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 109
Tabla 37. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 110
xi
Tabla 37. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 111
Tabla 37. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 112
Tabla 37. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 113
Tabla 37. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 114
Tabla 37. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la
fase transición ............................................................................................................................. 115
Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method 117
Tabla 39. Productos de trabajo asociados a la práctica Modelado de objetos del
dominio ......................................................................................................................................... 118
Tabla 40. Productos de trabajo asociados a la práctica Gestión de requisitos ........ 119
Tabla 41. Productos de trabajo asociados a la práctica Verificación continua de la
calidad ........................................................................................................................................... 119
Tabla 42. Productos de trabajo asociados a la práctica Desarrollo basado en
componentes ............................................................................................................................... 120
Tabla 43. Productos de trabajo asociados a la práctica Desarrollo basado en
componentes ............................................................................................................................... 120
Tabla 44. Roles, artefactos y actividades de la disciplina requisitos .......................... 127
Tabla 45. Roles, artefactos y actividades de la disciplina gestión de proyectos ..... 129
Tabla 46. Roles, artefactos y actividades de la disciplina análisis y diseño .............. 131
Tabla 45. Roles, artefactos y actividades de la disciplina despliegue ......................... 133
Tabla 48. Roles, artefactos y actividades de la disciplina implementación ............... 134
Tabla 49. Roles, artefactos y actividades de la disciplina entorno ............................... 135
ANEXOS
Anexo A. Fase 2 del UNC-Method: Análisis del problema .............................................. 140
Anexo B. Fase 3 del UNC-Method: Propuesta de solución ............................................. 143
Anexo C. Fase 4 del UNC-Method: Esquema conceptual ............................................... 146
Anexo D. Fase 2 del CDM: Modelado de requisitos………………………………………………160
Anexo E. Fase 3 del CDM: Diseño de sistema y generación………………………………….168
Anexo F. Fase 4 de CMD: Transición a la producción……………………………...…………...176
Anexo G. Fase 2 de RUP: Elaboración………………………………………………………………….183
Anexo H. Fase 3 de RUP: Construcción……………………………………………………………….200
Anexo I. Fase 4 de RUP: Transición……………………………………………………………………..215
Anexo J. Validación del UNC-Method: Caso de estudio 2………………………………….....229
xii
RESUMEN
Los ingenieros de software utilizan métodos para asegurar la entrega de un producto de calidad,
respetando el tiempo y presupuesto planteados. La existencia de prácticas replicadas con pequeñas
modificaciones y la separación entre las prácticas industriales y de investigación académica, hacen
que la cantidad de métodos incremente en el tiempo. Generalmente, cuando se adopta un nuevo
método para el desarrollo, los existentes se excluyen completamente sin tener en cuenta que algunas
prácticas pueden ser útiles aún para el desarrollo.
Un determinado método no se adapta a todo tipo de proyecto, sino que cada tipo de proyecto tiene
un método que se ajusta mejor. Actualmente, el uso frecuente de las prácticas y técnicas que un
método define depende de la moda o tendencia de desarrollo del momento. De acuerdo con la
literatura, existen dos tipos de métodos (basados en planes y ágiles) que se diferencian por la forma
de trabajo, la inversión de tiempo y la obtención de herramientas para llevar a cabo el desarrollo del
software. Aun así, son métodos que comprenden prácticas similares.
Semat (Software Engineering Method and Theory) es una iniciativa que responde al llamado de la
acción de los métodos y la teoría de la ingeniería de software, creando un marco de pensamiento
que permite la agrupación de prácticas pertenecientes a distintos métodos, conformando así una
base teórica común con principios probados. Lo anterior con el fin permitir al ingeniero de software
organizar sus propios métodos, utilizando las prácticas de acuerdo a las necesidades de sus
proyectos.
Por ello, en esta Tesis de Maestría se propone la representación en el núcleo de Semat de las
prácticas de tres métodos basados en planes: Rational Unified Process (RUP), Custom Development
Method (CDM) y UNC-METHOD. Así, se definen las prácticas existentes y a ellas se les agregan las
actividades, roles y productos de trabajo propios de cada método, mediante la definición de los alfas,
espacios de actividad y competencias requeridas.
PALABRAS CLAVE: Semat, RUP, CDM, UNC-Method, prácticas, representación gráfica.
xiii
ABSTRACT
Software engineers use methods for ensuring the delivery of a quality, on-time, on-budget product.
The existence of practices replicated with minor modifications and the gap between industry practices
and academic research increase the number of methods over time. Commonly, when a new
development method is adopted, software engineers don’t use more the practices of the previous
methods.
A particular method is unsuitable for all types of projects, since each project type has a method fitting
best. Currently, the frequent use of the practices and techniques for defining a method depends on
either fashion or development trends. Some methods based on plans and some others are agile.
They differ in the way of working, the time invested on development, and the tools they use. Even so,
all of the methods comprise similar practices.
Semat (Software Engineering Method and Theory) is an initiative that allows grouping practices from
different methods to form a base common theoretical with proven principles, thus software engineers
can organizing their own methods and using practices according to the needs of their projects.
Consequently, in this M.Sc. Thesis we propose the representation of practices coming from three
methods based on plans—Rational Unified Process (RUP), Custom Development Method (CDM) and
UNC-METHOD—by using the Semat Essence kernel.
KEY WORDS: Semat, RUP, CDM, UNC-Method, practices, graphical representation.
1
1. INTRODUCCIÓN
1.1 Justificación
La ingeniería de software es una disciplina que comprende el estudio de métodos de desarrollo para
la producción, mantenimiento y creación de la documentación de los sistemas de software. El interés
creciente por definir nuevos métodos y la separación de la industria y la investigación académica,
permiten una amplia existencia de métodos que especifican artefactos, roles, actividades, técnicas
y prácticas para definir una forma de trabajo. Algunos métodos se excluyen completamente cuando
se adopta uno nuevo, sin tener en cuenta que contienen prácticas útiles para el desarrollo, o que los
nuevos métodos sólo proponen prácticas ya existentes con pequeñas modificaciones [1].
En la literatura se encuentran dos tipos de métodos de desarrollo de software: los métodos basados
en planes, que permiten seguir una planificación bien definida del proyecto, considerando los
términos de formación e inversión de tiempo y compra de herramientas como parte de su forma de
trabajo, y los métodos ágiles, que se concentran en el factor humano, dándole más importancia a la
colaboración del cliente y al desarrollo incremental con iteraciones muy cortas, plazos reducidos,
requisitos volátiles y aplicación de nuevas tecnologías [2]. Sin embargo, en ambos tipos de métodos
se asegura la generación de un producto de calidad, por lo cual comparten algunas prácticas
similares [3].
Los equipos requieren encontrar un balance entre las entregas, la satisfacción del interesado y la
forma de trabajar al momento de desarrollar software. Por ello, requieren de una marco de
pensamiento como Semat (Software Engineering Method and Theory), una iniciativa que existe como
una base teórica, que agrupa prácticas de distintos métodos de desarrollo de software definidas con
los mismos elementos. Así, se permite que, a partir del entendimiento de las bases de la ingeniería
de software, las prácticas se midan y comparen, logrando que los desarrolladores puedan
representar métodos exactamente de manera que se adapten a sus fines. Lo anterior implica que,
en algunos casos, la representación y aplicación parcial de un método sea suficiente para el
desarrollo de software [1] [4].
Por ello, surge la necesidad de estudiar los métodos de desarrollo existentes, para su inclusión en
el núcleo de Semat. En esta Tesis de Maestría se propone la representación de métodos basados
en planes como CDM (Custom Development Method), RUP (Rational Unified Process) y UNC-
Method, identificando las prácticas que tienen en común y asociando a éstas prácticas ya existentes
de otros métodos con sus actividades correspondientes. De esta forma se logra la unificación y
complementación de las prácticas mediante la representación de los alfas, los productos de trabajo
y espacios de actividad asociados, las etapas del ciclo de vida de un producto de software (requisitos,
2
análisis, diseño, codificación, prueba, implementación y mantenimiento), la especificación de roles
con la asignación de funciones [5] y habilidades para llevar a cabo las actividades definidas en cada
metodología.
1.2 Planteamiento del problema
En Semat, un método es una definición de lo que se debe hacer y una guía activa para un equipo y
su forma de trabajo. En cualquier momento durante el desarrollo de software, el método se puede
consultar para definir qué hacer a continuación. Además, el método se puede ajustar en cualquier
momento y regresar a pasos anteriores para saber qué hacer a continuación, en caso que se deba
reevaluar el proceso de desarrollo de software [4].
La existencia de distintos métodos de desarrollo se debe a que los equipos buscan una forma de
producir mejor el software, por lo que se generan nuevas ideas o se modifican prácticas existentes
para la definición de nuevos métodos. Semat conforma una base teórica que agrupa prácticas
definidas bajo los mismos elementos, lo cual permite unificar las prácticas existentes y que los
desarrolladores puedan crear sus propios métodos de acuerdo con lo que necesiten. De allí la
importancia de incluir en el núcleo de Semat los métodos de desarrollo existentes.
1.3 Objetivo general
Representar en el núcleo de Semat las prácticas comunes de tres métodos basados en planes (RUP,
CDM y UNC-Method) que posibilite su comparación e integración para el desarrollo de aplicaciones
de software.
1.4 Objetivos específicos
Caracterizar la estructura de los métodos de desarrollo basados en planes tales como RUP,
CDM y UNC-Method.
Identificar en cada metodología los elementos esenciales de la ingeniería de software como
los artefactos, actividades y roles.
Identificar las prácticas comunes de los métodos de desarrollo de software basados en
planes que se puedan representar en el núcleo de Semat.
Diferenciar los siguientes conceptos: método, práctica, actividad, alfa, estado, competencia
y espacio de actividad.
Representar los elementos estudiados de la estructura de los métodos escogidos con los
elementos del núcleo de Semat.
Validar con un estudio de laboratorio las representaciones del objetivo específico anterior.
3
1.5 Metodología
La metodología que se utiliza para llevar a cabo los objetivos específicos planteados en esta Tesis
comprende las siguientes fases:
Observación
Observación del comportamiento, partes y componentes del objeto de estudio:
En este caso se tienen cuatro diferentes objetos de estudio: Semat, RUP, CDM y UNC-Method. Para
esta fase es importante recolectar toda la información posible. Por ello, para esta Tesis se toman en
consideración las siguientes fuentes o tipos de documentos: Artículos, ponencias, revistas
electrónicas y páginas web oficiales.
Al final de esta primera fase se debe tener un conocimiento pleno de Semat y todos los elementos
de su núcleo y de la estructura de los tres métodos basados en planes escogidos para su
representación en el núcleo de Semat.
El objetivo específico por alcanzar con esta fase es:
Caracterizar la estructura de los métodos de desarrollo basados en planes tales como RUP,
CDM y UNC-Method.
Descripción
Identificación de todos los elementos, partes y componentes para poder entender los objetos de
estudio:
Con la fase anterior, se conocen los elementos del núcleo de Semat que se utilizarán en la
representación. Así, en esta fase se pretende identificar los elementos de los tres métodos. Como
son métodos basados en planes, tienen una estructura similar, es decir, sus elementos son los
siguientes: fases, artefactos, actividades y roles. En este paso, se deben identificar los elementos en
cada uno de los métodos de manera ordenada para su representación en el núcleo.
El objetivo específico por alcanzar con esta fase es:
Identificar en cada metodología los elementos esenciales de la ingeniería de software como
los artefactos, actividades y roles.
Revisión
Revisión rigurosa de cada uno de los elementos de un todo:
En Semat existen diferentes símbolos que representan los elementos esenciales de la ingeniería de
software. En la fase anterior se identificaron las actividades, fases, roles y artefactos de los métodos.
4
Aparte de estos elementos, se deben estudiar los demás elementos que componen el núcleo de
Semat: método, práctica, alfa, estado, competencias y espacio de actividad.
El objetivo específico por alcanzar con esta fase es:
Diferenciar los siguientes conceptos: método, práctica, actividad, alfa, estado, competencia
y espacio de actividad.
Integración
Integración de los componentes a fin de identificarlos, registrarlos y establecer sus relaciones con
los demás:
Al identificar la finalidad de los elementos de Semat en la fase anterior, se debe profundizar sobre
cada una de las clasificaciones o categorías que contienen algunos elementos como los alfas, los
espacios de actividades y las competencias.
Esta fase se hace con el fin de reconocer la finalidad de cada una de las clasificaciones, para, más
adelante, poder relacionar los elementos de los métodos y las categorías de estos elementos.
Clasificación
Ordenación de cada una de las partes por clases para conocer sus características, detalles y
comportamiento:
En esta fase ya se conocen los elementos de los métodos, los elementos de Semat y se entiende la
finalidad de cada uno de los elementos del núcleo. Por lo tanto, en este paso se pretende identificar
las prácticas de los tres métodos que se van a representar en Semat.
El objetivo específico por alcanzar en esta fase es:
Identificar las prácticas comunes de los métodos de desarrollo de software basados en
planes que se van a representar en Semat.
Conclusión
Analizar los resultados obtenidos:
Teniendo claros los elementos de cada uno de los objetos de estudio, en esta fase se realiza la
representación con la sintaxis gráfica de Semat. Los objetivos específicos por alcanzar en esta fase
son:
Representar los elementos estudiados de la estructura de los métodos escogidos con los
elementos del núcleo de Semat.
Validar con un estudio de laboratorio las representaciones del objetivo específico anterior.
5
1.6 Estructura de la Tesis
Esta Tesis se organiza de la siguiente manera: en el Capítulo 2 se presenta el Marco Teórico
relacionado con la sintaxis gráfica de los elementos del núcleo de Semat y los métodos basados en
planes como Custom Development Method (CDM), Rational Unified Process (RUP) y UNC-Method;
en el Capítulo 3 se describen las distintas representaciones gráficas que ya existen en la literatura
de los métodos basados en planes sujetas a estudio; en el Capítulo 4 se propone la representación
de las prácticas de los métodos CDM, RUP y UNC-Method; en el Capítulo 5 se presenta la validación
de la representación propuesta y, finalmente, en el Capítulo 6 se plantean las conclusiones obtenidas
y se presenta el trabajo futuro que se puede derivar de esta Tesis.
2 MARCO TEÓRICO
2.1 Semat (Software Engineering method and theory)
Semat es una iniciativa de Ivar Jacobson, Bertrand Meyer y Richard Soley [1]. Este marco de
pensamiento muestra que, a partir del análisis de todos los métodos desarrollo, se pueden definir
elementos comunes, es decir, se puede definir un núcleo con “las cosas con las que se trabaja” y
“las cosas que siempre se hacen” en el desarrollo de software. Semat tiene dos objetivos principales:
encontrar un núcleo de elementos ampliamente aceptados y definir una base teórica sólida, con el
propósito de redefinir la forma en que las personas trabajan con los métodos de desarrollo de
software. Así, se permite la definición de medidas que no dependan de las prácticas para evaluar la
calidad del software y los métodos que se utilizan para producirlo, la composición y comparación de
prácticas que se puedan definir y aplicar de manera independiente (así su origen sea diverso) que
se ajusten a las necesidades ya sea de la organización, de un proyecto o equipo de trabajo [1].
Semat incluye algunos conceptos principales [4], que se pueden visualizar en la Tabla 1:
Tabla 1. Conceptos principales de Semat. Extraído de Jacobson et al. [4]
Descripción Símbolo
Método Un método se define como una composición de prácticas y es dinámico debido a que soporta las actividades diarias durante el desarrollo de software.
Práctica
Una práctica se define como un enfoque que se repite con un propósito específico y a su vez proporciona una forma de verificar cualquier aspecto del trabajo que se realiza. Por lo cual una práctica puede pertenecer a distintos métodos.
Núcleo El núcleo se genera a partir de métodos. Los métodos específicos contienen las prácticas y éstos se incluyen en el núcleo.
Lenguaje Sirve para definir los métodos, las prácticas y los elementos del núcleo.
6
El núcleo de Semat se describe usando un pequeño conjunto de elementos, los cuales se agrupan
en tres áreas de conocimiento: cliente, solución y esfuerzo. Cada área de conocimiento se enfoca
en un aspecto específico de la ingeniería de software y se distingue con un color, el cual permite
comprender, a nivel gráfico, la relación de las áreas de conocimiento con cada uno de los elementos
agrupados en ellas. Los elementos que componen cada una de las áreas de conocimiento y que, a
su vez, definen el núcleo son: alfas, espacios de actividad y competencias [4].
Alfas
Los alfas se pueden definir como la representación de las “cosas esenciales para trabajar” y proveen
una descripción de la clase de cosas que un equipo debe gestionar, usar y producir en cualquier
esfuerzo de desarrollo de software. Un alfa representa un indicador crítico para monitorear y seguir
una línea de progreso que mide la salud del proyecto (véase la Figura 1). Esto se logra debido a que
un alfa se caracteriza con un conjunto de estados, donde cada estado tiene una lista de chequeo
que especifica los criterios necesarios para alcanzar un estado [4].
Figura 1. Alfas del núcleo [1]
En el área de conocimiento cliente, el equipo necesita comprender los interesados, lo que incluye:
Alfa Oportunidad: “Es el conjunto de circunstancias adecuado para desarrollar o modificar un
sistema de software. La oportunidad articula la razón para la creación de lo nuevo o modificado
del sistema de software”. En la Tabla 2 se especifican sus estados y listas de chequeo.
7
Estado Lista de chequeo
Identificado
• Se identificó una oportunidad que una solución basada en un software podía tratar
• Un interesado quiere hacer una inversión en un mejor valor potencial de comprensión
• Se identificaron otros interesados que quieren compartir la oportunidad
Con solución requerida
• Se confirmó la necesidad de una solución basada en software • Se identificaron las necesidades de los interesados • Se identificaron los problemas y las causas raíz subyacentes • Se propuso al menos una solución basada en software
Con valor establecido
• El valor de tratar la oportunidad se cuantificó en términos absolutos o en los retornos o de ahorros por periodo de tiempo (por ejemplo, por año)
• El impacto de la solución de los interesados se entiende • El valor que el sistema de software ofrece a las partes interesadas que
financian y utilizan el sistema de softwareLos criterios de éxito para juzgar el sistema de software son claros
• Los resultados deseados que se requieren de la solución son claros y cuantificados
Viable
• Se esbozó una solución • Las indicaciones y la solución se pueden desarrollar y desplegar dentro de las
restricciones • Los riesgos son manejables
Tratada
• Se produjo una solución que trata la oportunidad de forma demostrable • Un sistema usable está disponible • Los interesados acuerdan el despliegue de valor • La solución que satisface los interesados trata la oportunidad
Con beneficio acumulado
• El uso operacional están creando beneficios tangibles • El perfil de retorno de la inversión es al menos tan bueno como se anticipó
Tabla 2. Estados del alfa Oportunidad. Extraído de Jacobson et al. [4]
Alfa Interesados: “Las personas, grupos u organizaciones que afectan o se afectan con un
sistema de software. Los interesados proporcionan la oportunidad y son la fuente de los
requisitos y la financiación para el software sistema”. En la Tabla 3 se especifican sus estados y
listas de chequeo:
Estado Lista de chequeo
Reconocido • Se identificaron los interesados • Existe un acuerdo entre los grupos de interesados que se van a representar • Se definieron las responsabilidades de los representantes de los interesados
Representado
• Se citaron los representantes de los interesados • Los representantes de los interesados aceptan las responsabilidades y los
autorizaron • Se acordó el enfoque de la colaboración • Los representantes aceptan la forma de trabajo
Involucrado
• Los representantes de los interesados aceptan sus responsabilidades • Los representantes de los interesados entregan retroalimentación y
participan de las decisiones temporales • Los representantes de los interesados se comunican inmediatamente con el
grupo de interesados
Tabla 3. (Parte 1/2) Estados del alfa Interesados. Extraído de Jacobson et al. [4]
8
Estado Lista de chequeo
De acuerdo • Los representantes de los interesados están de acuerdo en que el equipo valora y respeta su ingreso
• Los representantes de los interesados están de acuerdo en el balance de las diversas prioridades
• Los representantes de los interesados están de acuerdo con un mínimo de expectativas de despliegue
Satisfecho para despliegue
• Los representantes de los interesados proveen retroalimentación sobre el sistema desde la perspectiva del grupo de interesados
• Los representantes de los interesados confirman que el sistema está listo para el despliegue
Satisfecho en uso
• El sistema alcanzó o excedió las expectativas mínimas de los interesados • Las necesidades y expectativas de los interesados se están cumpliendo
Tabla 3. (Parte 2/2) Estados del alfa Interesados. Extraído de Jacobson et al. [4]
En el área de conocimiento solución, el equipo necesita establecer los requisitos e implementar,
construir, probar y mantener un sistema de software que cumpla con ellos, incluyendo:
Alfa Requisitos: “Lo que el sistema de software debe hacer para tratar la oportunidad y satisfacer
a los interesados”. En la Tabla 4 se especifican sus estados y listas de chequeo.
Estado Lista de chequeo
Concebido • La necesidad de un nuevo sistema es clara • Se identificaron los usuarios • Se identificaron los promotores iniciales
Acotado
• Se acordaron el propósito y la extensión del sistema • Los criterios de éxito son claros • Se acordaron los mecanismos para manejar los requisitos • Se identificaron las restricciones y suposiciones
Coherente
• La visión general es clara y la comparten todos los involucrados • Se explicaron importantes escenarios de uso • Las prioridades son claras • Se trataron los conflictos • Se comprende el conflicto
Aceptable • Los requisitos describen una solución aceptable para los interesados • La tasa de cambio para acordar requisitos es baja • El valor es claro
Tratado • Suficientes requisitos se implementaron para que el nuevo sistema se acepte • Los interesados acuerdan que el sistema vale la pena realizando trabajo
operativo
Cumplido • El sistema satisface completamente los requisitos y las necesidades • No hay ítems excepcionales que impidan que el sistema se considere
completo
Tabla 4. Estados del alfa Requisitos. Extraído de Jacobson et al. [4]
Alfa Sistema de software: “Un sistema se compone de software, hardware y los datos que
proporciona el valor primario de la ejecución del software”. En la Tabla 5 se especifican sus
estados y listas de chequeo.
9
Estado Lista de chequeo
Con arquitectura seleccionada
• Se seleccionó la arquitectura que trata los riesgos técnicos clave • Se acordaron los criterios para seleccionar la arquitectura • Se seleccionaron las plataformas, tecnologías y lenguajes • Se tomaron las decisiones de compra, construcción y reuso
Demostrable • Se demostraron las características clave de la arquitectura • Los interesados relevantes acordaron que la arquitectura es apropiada • Se ejercieron la interfaz crítica y las configuraciones del sistema
Usable
• El sistema es usable y tiene las características de calidad deseadas • Los usuarios pueden operar el sistema • Se aceptaron los niveles de defectos • Se conoció el contenido de liberación
Listo
• Se puso a disposición la documentación de usuario • Los representantes de los interesados aceptaron el sistema • Los representantes de los interesados quieren que se haga operacional el
sistema
Operacional
• El sistema se usó en un ambiente operacional • El sistema está disponible para los usuarios previstos • Al menos un ejemplo del sistema es completamente operacional • El sistema es compatible con los niveles de servicio acordados
Retirado • No se da más soporte al sistema • No se producirán más actualizaciones al sistema • Se reemplazó o se descontinuó el sistema
Tabla 5. Estados del alfa Sistema de software. Extraído de Jacobson et al. [4]
En el área de conocimiento esfuerzo, se tienen que establecer el equipo y su forma de trabajo y se
tiene que hacer el trabajo, incluyendo:
Alfa Trabajo: “Actividad que implica un esfuerzo mental o físico realizado con el fin de lograr un
resultado. En el contexto de la ingeniería de software, el trabajo es todo lo que hace el equipo
para cumplir con las metas de producción de un sistema de software que coincida con los
requisitos”. En la Tabla 6 se especifican sus estados y listas de chequeo.
Estado Lista de chequeo
Iniciado
• Se conoce el iniciador del trabajo • Se aclaran las restricciones del trabajo • Se aclaran el patrocinio y el modelo de financiación • Se aclara la prioridad del trabajo
Preparado
• Se estimaron el costo y el esfuerzo • La financiación y los recursos trabajan en su lugar • Se comprendieron los criterios de aceptación • Se acordaron los procedimientos de gobierno • Se comprendió la exposición al riesgo • Se aclararon las dependencias
Comenzado
• Se comenzó el trabajo de desarrollo • Se monitoreó el proceso de desarrollo • Se hizo la división en ítems accionables con una clara definición • Los miembros del equipo están aceptando y progresando en los ítems de
trabajo
Tabla 6. (Parte 1/2) Estados del alfa Trabajo. Extraído de Jacobson et al. [4]
10
Estado Lista de chequeo
Bajo control • El trabajo va bien; se están manejando los riesgos • El trabajo y el re-trabajo no planteados están bajo control • Se completaron lo ítems de trabajo dentro de los estimados • Se hizo seguimiento de las mediciones
Concluido • Se terminó el trabajo que produce resultados • Se están consiguiendo los resultados de trabajo • El cliente aceptó el sistema de software resultante
Cerrado • Todas las tareas de limpieza remanentes se completaron y el trabajo se cerró oficialmente
• Todo se archivó • Se dispone de lecciones aprendidas y de métricas
Tabla 6. (Parte 2/2) Estados del alfa Trabajo. Extraído de Jacobson et al. [4]
Alfa Equipo: “Un grupo de personas que participa activamente en el desarrollo, mantenimiento o
entrega de un sistema de software”. En la Tabla 7 se especifican sus estados y listas de chequeo.
Estado Lista de chequeo
Sembrado
• La misión del equipo es clara • El equipo sabe cómo crecer para lograr su misión • Se identificaron las competencias requeridas • Se determinó el tamaño del equipo
Formado
• El equipo tiene suficientes recursos para iniciar la misión • Se comprendieron la organización del equipo y las responsabilidades
individuales • Los miembros saben cómo ejecutar el trabajo
Colaborando
• Los miembros están trabajando como una unidad • La comunicación es abierta y honesta • Los miembros se enfocan en la misión del equipo • El éxito del equipo se antepone a los objetivos personales
Ejecutando
• El equipo está trabajando eficiente y efectivamente • Se adapta al contexto cambiante • Se producen salidas de alta calidad • Se realizan mínimos retrocesos y marchas atrás • Se eliminó continuamente el desperdicio
Suspendido • El equipo ya no cuenta • Se entregaron las responsabilidades • Los miembros están disponibles para otras asignaciones
Tabla 7. Estados del alfa Equipo. Extraído de Jacobson et al. [4]
Alfa Forma de trabajo: “El conjunto adaptado de prácticas y herramientas que utiliza un equipo
de orientar y apoyar su trabajo”. En la Tabla 8 se especifican sus estados y listas de chequeo.
Estado Lista de chequeo
Con principios establecidos
• Se establecieron los principios y restricciones • Se comprometieron los principios y restricciones • Se acordaron las prácticas y herramientas • Se comprendió el contexto en que el equipo debe operar
Tabla 8. (Parte 1/2) Estados del alfa Forma de trabajo. Extraído de Jacobson et al. [4]
11
Estado Lista de chequeo
Con bases establecidas
• Prácticas clave y herramientas listas • Se analizaron y comprendieron las brechas entre prácticas y herramientas • Se analizaron y comprendieron las brechas de capacidad • Se integraron las prácticas seleccionadas y las herramientas
En uso • Algunos miembros del equipo están usando la forma de trabajo • Se inspeccionó regularmente el uso de prácticas y herramientas • Los procedimientos están en su lugar para manejar retroalimentación
En su lugar • Todos los miembros del equipo están usando la forma de trabajo • Todos los miembros tienen acceso a las prácticas y herramientas para hacer
su trabajo • El equipo completo se involucró en la inspección y adaptación de la forma de
trabajo
Trabajando bien
• La forma de trabajo está trabajando bien para el equipo • Los miembros del equipo están progresando según el plan • El equipo aplica naturalmente prácticas sin pensar en ellas • Las herramientas soportan naturalmente la forma de trabajo
Retirado • El equipo no usa más la forma de trabajo • Se compartieron las lecciones aprendidas para uso futuro
Tabla 8. (Parte 2/2) Estados del alfa Forma de trabajo. Extraído de Jacobson et al. [4]
Espacios de actividad
Los espacios de actividad complementan los alfas, ya que proporcionan el conjunto de actividades
esenciales que normalmente se hacen en ingeniería de software (véase la Fig. 2) [4].
Figura 2. Espacios de actividad del núcleo [1]
En el área de conocimiento clientes, el equipo tiene que entender la oportunidad y hacer participar a
los interesados:
Explorar las posibilidades: “explorar las posibilidades que presenta la creación de un nuevo o
mejorado sistema de software. Esto incluye el análisis de la oportunidad por abordar y la
identificación de los interesados”.
12
Comprender las necesidades de los interesados: “colaborar con los interesados para conocer
sus necesidades y garantizar los resultados. Esto incluye la identificación y el trabajo con los
representantes de los interesados para avanzar en la oportunidad”.
Asegurar la satisfacción de los interesados: “compartir los resultados de la labor de desarrollo
con los interesados que pueden aportar su aceptación del sistema producido y verificar que la
oportunidad se aborde con éxito”.
Utilizar el sistema: “Observar el uso del sistema en un entorno real y beneficiar a los interesados”.
En el área de conocimiento solución, el equipo tiene que desarrollar una solución apropiada para
aprovechar la oportunidad y satisfacer los interesados:
Comprender los requisitos: “comprender lo que el sistema producido debe hacer”.
Darle forma al sistema: “darle forma al sistema de modo que sea fácil de desarrollar, modificar y
mantener. Esto incluye el diseño general”.
Implementar el Sistema: “construir un sistema mediante la implementación, pruebas e
integración de uno o más elementos del sistema. Esto incluye la corrección de errores y pruebas
unitarias”.
Probar el sistema: “verificar que el sistema producido cumple con los requisitos de los
interesados”.
Desplegar el sistema: “tomar el sistema probado y hacer que esté disponible para su uso fuera
del equipo de desarrollo”.
Operar el sistema: “Apoyar el uso del sistema de software en el entorno de producción”.
En el área de conocimiento esfuerzo, se tiene que formar el equipo tiene y avanzar el trabajo de
acuerdo con la forma de trabajo:
Prepararse para hacer el trabajo: “establecer el equipo y su entorno de trabajo. Entender y
comprometerse a completar el trabajo”.
Coordinar actividades: “coordinar y dirigir el trabajo del equipo. Esto incluye la planificación del
trabajo y reconfiguración del equipo”.
Apoyar el equipo: “ayudar a los miembros del equipo para ayudarse a sí mismos, colaborar y
mejorar su forma de trabajar”.
Seguimiento del progreso: “medir y evaluar los progresos realizados por el equipo”.
Finalizar el trabajo: “finalizar el esfuerzo de ingeniería de software”.
Competencias
Las competencias representan las habilidades clave que se requieren para el desarrollo de software
[4] y se muestran en la Figura 3.
13
Figura 3. Competencias del núcleo. Traducido de [4]
En el área de conocimiento cliente, el equipo tiene que ser capaz de demostrar una clara
comprensión del negocio y de algunos aspectos técnicos de su dominio. Además, debe tener la
capacidad de comunicar con precisión las opiniones de sus interesados.
Representación del interesado: “esta competencia encapsula la capacidad de recopilar,
comunicar y balancear las necesidades de otras partes interesadas y con precisión representar
sus puntos de vista”.
En el área de conocimiento solución el equipo tiene que ser capaz de capturar y analizar las
necesidades, de construir y operar un sistema de software que cumple con los requisitos.
Análisis: “esta competencia encapsula la capacidad de entender las oportunidades, las
necesidades de sus interesados y transformarlas en un conjunto de requisitos consistente”.
Desarrollo: “esta competencia encapsula la capacidad de diseñar y programar sistemas de
software de forma eficaz, siguiendo las reglas y normas que acuerda el equipo”.
Pruebas: “esta competencia encapsula la posibilidad de probar un sistema, verificando que es
usable y que cumple los requisitos”.
En el área de conocimiento esfuerzo, el equipo tiene que ser capaz de organizarse y gestionar su
carga de trabajo.
Liderazgo: “esta competencia permite a una persona inspirar y motivar a un grupo de personas
para lograr éxito en su trabajo y cumplir sus objetivos”.
Gestión: “esta competencia encapsula la capacidad de coordinar, planificar y realizar un
seguimiento del trabajo que realiza un equipo”.
14
Elementos del núcleo de Semat
La sintaxis gráfica del lenguaje de Semat proporciona una forma visual para cada uno de sus
elementos, donde cada uno de estos elementos corresponde a un aspecto específico de un núcleo
o método, tal como se muestra a continuación [4]. Adicionalmente, se presentan elementos del
lenguaje necesarios para la asociación entre algunos elementos del núcleo (véase la Tabla 9).
2.1.4.1 Producto de trabajo
Un producto de trabajo es un artefacto de valor y relevancia para un esfuerzo de la ingeniería de
software. Es una concreta representación de un alfa como resultado de un esfuerzo y, en algunos
casos, es necesario como entrada para un esfuerzo posterior. Puede ser de diferentes tipos como
modelos, documentos, código, especificaciones, pruebas y ejecutables, entre otros.
2.1.4.2 Actividad
Una actividad define una o más clases de productos de trabajo y una o más clases de tareas, y
brinda una guía sobre cómo se usan estos elementos cuando se utiliza una práctica.
2.1.4.3 Patrón
Un patrón es una descripción de una estructura en una práctica.
2.1.4.4 Asociación del alfa
Una asociación de un alfa se visualiza como una línea continua para conectar dos alfas. La línea
puede tener uno o más segmentos.
2.1.4.5 Sucesor de estados
Una asociación de sucesor de estados se visualiza como una línea sólida con una flecha abierta que
conecta un estado con su sucesor. La línea puede tener uno o más segmentos conectados.
2.1.4.6 Alpha Containment
Un alpha containment se visualiza como una línea continua vertical para conectar un alfa con un
subalfa con un diamante relleno en la punta hacia el lado del alfa.
2.1.4.7 Manifiesto de producto de trabajo
Un manifiesto de producto de trabajo se visualiza como una línea continua horizontal para conectar
un alfa con un producto de trabajo con un diamante relleno en la punta hacia el lado del alfa. La línea
puede tener uno o más segmentos pero los productos de trabajo se deben ubicar al mismo nivel. Se
puede hacer uso de los límites que siguen la estructura (“<Límite inferior>..<Límite superior>”) y se
deben ubicar hacia el lado del producto de trabajo.
2.1.4.8 Asociación de actividad (“Parte de”)
Una asociación de actividad se visualiza como una línea continua horizontal para conectar un
espacio de actividad con una actividad con un diamante relleno en la punta hacia el lado del espacio
15
de actividad. La línea puede tener uno o más segmentos pero las actividades se deben ubicar al
mismo nivel.
2.1.4.9 Asociación de actividad (NO “Parte de”)
Una asociación de actividad se visualiza como una línea sólida (puede ser curva) con una punta
triangular que conecta dos actividades y/o espacios de actividades. La línea puede tener uno o más
segmentos conectados.
2.1.4.10 Asociación de patrón
Una asociación de patrón se visualiza como una línea sólida con punta de diamante relleno hacia el
lado del patrón, originada desde un círculo que se conecta a su vez con cada uno de los elementos
asociados con el patrón. El nombre de la asociación se pone dentro del círculo.
Elemento Símbolo Ejemplo
Producto de trabajo
Actividad
Patrón
Asociación de alfas
Sucesor de estados
Alpha Containment
Manifiesto de producto de trabajo
Tabla 9. (Parte 1/2) Sintaxis gráfica de elementos del núcleo. Extraído de Jacobson et al. [4]
16
Elemento Símbolo Ejemplo
Asociación de actividad (“Parte de”)
Asociación de actividad (“No Parte de”)
Asociación de patrón
Tabla 9. (Parte 2/2) Sintaxis gráfica de elementos del núcleo. Extraído de Jacobson et al. [4]
2.2 CDM (Custom Development Method)
CDM es un método de desarrollo diseñado para modelar aplicaciones de software durante cuatro
fases que comprenden el ciclo de vida del método. Tal como se puede ver en la Figura 4, CDM tiene
asociados once procesos [6]:
Figura 4. Estructura de CDM. Traducido de [6]
17
Los modelos utilizados en CDM se encuentran agrupados en tareas y las tareas se agrupan en
procesos. Un conjunto de procesos conforman una fase y cada proceso se puede asociar con una
tarea requisito previo y tiene un resultado clave que surge luego de ejecutar el proceso [7].
En la Tabla 10 se especifican los objetivos de cada fase del método.
Fase Descripción
Definición
En esta fase se establece una base sólida y viable para el proyecto. Los objetivos de esta fase son:
Obtener un claro entendimiento de los beneficios empresariales que el nuevo sistema debe alcanzar.
Identificar el promotor del proyecto.
Definir el alcance del proyecto, partir y priorizar el alcance.
Determinar los plazos, actividades, productos y recursos necesarios.
Identificar los desarrolladores que van a participar en el proyecto.
Identificar adecuadamente al usuario embajador que va a participar durante todo el ciclo de vida del proyecto.
Educar al promotor, el usuario embajador y otros interesados, explicarles el impacto en la organización, los respectivos papeles y responsabilidades en el proyecto.
Crear un equipo de proyecto que integren los desarrolladores y el usuario embajador.
Desarrollar procesos de negocio de alto nivel, la función y los modelos de datos.
Modelado de Requisitos
Se busca capturar los modelos de los procesos del negocio que describe el usuario. Los objetivos de esta fase son:
Acordar un aspecto común de la aplicación.
Establecer normas de generación de código inicial.
Obtener conocimiento detallado de los procesos de negocios, funciones e información para cumplir con los objetivos de negocio.
Generar un prototipo funcional con los acuerdos del usuario embajador para comunicar la comprensión de los desarrolladores.
Acordar la estrategia de validación detallada y participación de los usuarios durante todo el proyecto, comprobando su disponibilidad.
Diseño de Sistema y Generación
En esta fase se especifica el diseño del sistema y se realiza la entrega de una aplicación que cumpla de manera óptima con los requisitos del negocio. Los objetivos de esta fase son:
Reiterativamente, producir una base de datos física y los módulos de la aplicación.
Obtener mejoras a las exigencias del usuario embajador durante cada iteración.
Precisar los datos y modelos de funcionamiento.
Entregar documentación inicial para colaborar con el usuario embajador en la validación del sistema de aplicación.
Definir las futuras mejoras para una mayor funcionalidad.
Tabla 10. (Parte 1/2) Fases del modelo CDM [6]
18
Fase Descripción
Transición a la Producción
Se obtiene del usuario la aceptación del nuevo sistema. Los objetivos de esta fase son:
Facilitar la validación de la preproducción, a fin de confirmar que los requisitos de negocio se cumplieron.
Completar documentación técnica y operativa.
Proporcionar un corte suave a la nueva aplicación.
Gestionar el desarrollo.
Supervisar el rendimiento del sistema de producción y resolver los problemas detectados.
Tabla 10. (Parte 2/2) Fases del modelo CDM [6]
CDM Fast Track utiliza el Método de Gestión de Proyectos (PJM) de Oracle™ para proporcionar un
marco en el que los proyectos se pueden planificar, estimar, controlar y hacer seguimiento de una
manera consistente. En la Tabla 11 se encuentran las tareas y productos de trabajos asociados que
realiza el gerente del proyecto durante su ejecución:
Tarea Entregables
Recordar y revisar planes de proyecto
Plan de gestión del alcance del proyecto
Estrategias de control y presentación de informes, normas y procedimientos
Plan de gestión de proyectos
Trabajo de las estrategias de gestión, normas y procedimientos
Plan de trabajo
Plan de financiación
Las estrategias de gestión de los recursos, normas y procedimientos
Dotación de personal y plan de su organización
Guía de la orientación proyecto
Organización preparada
Plan de recursos físicos
Infraestructura preparada
Estrategias de gestión de la calidad, normas y procedimientos
Gestión de la configuración, estrategias, normas
Realizar auditoría de calidad Auditoría de calidad
Lanzar recursos físicos Lanzamiento de recursos físicos
Realizar evaluación de calidad Reporte de calidad
Auditar entregables principales Línea base auditada
Aceptar seguridad del cliente del proyecto
Aceptación del cliente
Lanzar personal Personal lanzado
Lanzar recursos físicos Recursos físicos
Concluir gestión de la configuración Preparación de la gestión de producción
Tabla 11. Tareas, entregables del PJM [6]
19
Definición de fases, actividades, entregables y responsables
2.2.1.1 Fase: Definición
En la Tabla 12 se especifican los procesos, tareas, entregables y responsables de esta fase. El orden
de acción de las tareas se muestra en la Figura 5.
Proceso Tarea Entregables Responsable
Definición de requisitos del
negocio
Implementar las normas de definición de requisitos y directrices
Normas de definición de requisitos del negocio y directrices
Desarrollador principal de la aplicación
Crear el modelo de proceso del contexto
Modelo de proceso del contexto
Desarrollador principal de la aplicación
Documentar la estructura actual y futura de la organización
Definición de la estructura actual y futura de la organización
Desarrollador principal de la aplicación
Obtener descripciones del negocio de alto nivel
Descripciones del negocio de alto nivel
Desarrollador principal de la aplicación
Desarrollar glosario Glosario Desarrollador
Examen de sistemas existentes
Obtener material de referencia ya existente
Material de referencia ya existente
Desarrollador
Crear modelo de alto nivel del Sistema de datos existente
Modelo de alto nivel del sistema de datos existente
Desarrollador
Crear el modelo de proceso del sistema existente
Modelo de proceso del sistema existente
Desarrollador principal de la aplicación
Arquitectura Técnica
Definir la arquitectura del sistema
Definición de la arquitectura del sistema
Desarrollador principal del sistema
Documentación Especificar documentación de requisitos
Documentación de requisitos
Escritor técnico
Pruebas Determinar los requisitos de pruebas
Requisitos de pruebas Tester principal
Formación Lanzar el proyecto Equipo de Proyecto Integrado
Gerente de Proyecto
Tabla 12. Procesos, tareas, entregables y responsables de la fase Definición [6]
Figura 5. Orden de acción de las tareas de la fase Definición. Traducido de [6]
20
2.2.1.2 Fase: Modelado de Requisitos
En la Tabla 13 se especifican los procesos, tareas, entregables y responsables de esta fase. El orden
de acción de las tareas se muestra en la Figura 6.
Proceso Tarea Entregables Responsable
Definición de requisitos del
negocio
Crear modelo detallado del proceso de negocio
Modelo detallado del proceso de negocio
Desarrollador
Recopilar información detallada del negocio
Información detallada del negocio
Desarrollador
Construir modelo de datos del negocio
Modelo de datos del negocio Desarrollador
Validar prototipo funcional Prototipo funcional validado Usuario embajador
Redefinir requisitos Lista MoSCoW redefinida Usuario embajador
Arquitectura técnica
Definir los requisitos operacionales detallados del sistema
Requisitos operacionales detallados del sistema
Desarrollador principal del sistema
Crear arquitectura técnica Arquitectura Técnica Desarrollador principal del sistema
Determinar problemas de rendimiento
Problemas de rendimiento Desarrollador principal del sistema
Diseño y construcción de la base de datos
Implementar normas base de datos y directrices
Normas de la base de datos y directrices
Desarrollador principal del sistema
Crear diseño lógico de base de datos
Diseño lógico de base de datos
Desarrollador principal del sistema
Desarrollo de la aplicación
Diseñar aplicación Diseño de la aplicación Desarrollador principal de la aplicación
Crear entorno de desarrollo inicial
Entorno de desarrollo inicial Gerente de configuración
Desarrollar prototipo funcional
Prototipo funcional Desarrollador
Conversión de datos
Definir estrategia de conversión de datos
Estrategia de conversión de datos
Desarrollador
Tabla 13. Procesos, tareas, entregables y responsables de la fase Modelado de requisitos [6]
21
Figura 6. Orden de acción de tareas de la fase Modelado de requisitos. Traducido de [6]
2.2.1.3 Fase: Diseño de Sistema y Generación
En la Tabla 14 se especifican los procesos, tareas, entregables y responsables de esta fase. El orden
de acción de las tareas se muestra en la Figura 7.
Tabla 14. Procesos, tareas, entregables y responsables de la fase Diseño de sistema y
generación. Elaboración propia del autor basado en [6]
Proceso Tarea Entregables Responsable
Definición de requisitos del
negocio
Redefinir los requisitos Lista MoSCoW redefinida Usuario embajador
Revisar modelos de requisitos
Modelo de requisitos del negocio rested
Desarrollador
Arquitectura técnica
Desarrollar la definición de hardware y software
Definición de hardware y software
Desarrollador principal del sistema
Desarrollar arquitectura de distribución
Arquitectura de distribución Desarrollador principal del sistema
Desarrollar estrategia de reserva y recuperación
Estrategia de reserva y recuperación
Desarrollador principal del sistema
Diseño y construcción de la base de datos
Crear esquema de autorización de objetos de base de datos
Esquema de autorización de objetos de base de datos
Desarrollador principal del sistema
Crear diseño físico de la base
Diseño físico de la base Desarrollador principal del sistema
Desarrollo de la aplicación
Desarrollar (grupo de) módulos
Módulos documentados Desarrollador
Estrenar aplicación Código de la aplicación Desarrollador principal de la aplicación
Pruebas
Crear escenarios de prueba Escenarios de pruebas Tester principal
Crear modelo de prueba de la arquitectura del sistema
Modelo de prueba de la arquitectura del sistema
Tester principal
22
Figura 7. Orden de acción de tareas de la fase Diseño de sistema y generación. Traducido de
[6]
2.2.1.4 Fase: Transición a la Producción
En la Tabla 15 se especifican los procesos, tareas, entregables y responsables de esta fase. El orden
de acción de las tareas se muestra en la Figura 8.
Proceso Tarea Entregables Responsable
Conversión de datos
Limpieza de los datos Datos limpios Administrador de los datos del cliente
Convertir y verificar los datos de producción
Datos convertidos y verificados Líder de equipo de conversión de datos
Documentación
Completar referencia del usuario
Referencia del usuario Usuario embajador
Completar guía de usuario
Guía de usuario Usuario embajador
Completar referencia técnica
Referencia técnica detallada Escritor técnico
Completar guía operacional del sistema
Guía operacional del sistema Desarrollador principal del sistema
Generar texto de ayuda en línea
Texto de ayuda en línea Desarrollador
Pruebas Realizar validación preproducción
Resultados de la validación preproducción
Coordinador de validación
Formación
Entrenar administradores
Administradores entrenados Entrenador
Entrenar equipo de validación
Equipo de validación entrenado Entrenador
Tabla 15. Procesos, tareas, entregables y responsables de la fase Transición a la
producción. Elaboración propia del autor basado en [6]
23
Figura 8. Orden de acción de tareas de la fase Transición a la producción. Traducido de [6]
2.3 UNC-Method
UNC-Method (método de la Universidad Nacional de Colombia para el desarrollo de software basado
en problemas) mezcla una lista de objetos bien conocidos (como los diagramas de UML y las
interfaces gráficas de usuario) y los enfoques no tradicionales (por ejemplo, diagrama de causa y
efecto, diagramas de objetivos de KAOS y los esquemas preconceptuales) utilizados en el intento
de superar los problemas [8].
En la Tabla 16 se especifican las cuatro fases que este método comprende [9]:
Fase Descripción
Contexto del software En esta fase se capturan, entienden y representan gráficamente actores, objetivos, responsabilidades, funciones y estructura de lo relacionado con el problema
Análisis del problema En esta fase se detallan las funciones principales de la organización, problemas y objetivos
Propuestas de solución En esta fase el equipo debe proponer un conjunto de soluciones para los problemas de la organización
Esquema conceptual En esta fase el equipo específica y prepara el proceso de diseño del sistema
Tabla 16. Fases del UNC-Method. Elaboración propia del autor basado en [9]
Definición de fases, actividades, artefactos y responsables
En esta Sección se especifican los elementos de UNC-METHOD considerados para el desarrollo de
un sistema de software [9]:
2.3.1.1 Fase: Contexto del software
En la Tabla 17 se especifican las actividades, entregables y responsables de esta fase.
24
Actividades Entregables Responsable
Desarrollar entrevista interesado-analista
Archivos digitales Analista Interesado Director del proyecto Diálogo controlado
Revisar documentación Archivos digitales Analista
Interesado Diálogo controlado
Resumir la información relacionada con los actores, los objetos y las funciones
Tarjetas de educción Analista
Identificar los actores internos y externos en la organización
Organigrama Analista
Realizar tabla de trazabilidad documental
Tabla de trazabilidad documental Analista
Establecer un vocabulario común
Esquema preconceptual Analista
Esquemas preconceptuales ejecutables Analista
Modelo del dominio Analista
Gestionar la elaboración de tareas
Tablero Kanban Analista
Reportar el progreso del proyecto
Reporte de avance de los alfas Analista
Explicar el método Guía UNC-Method Director del proyecto
Definir roles y responsabilidades
Lista de roles y responsabilidades Director del proyecto
Tabla 17. Actividades, entregables y responsables en la fase del contexto del software.
Síntesis del autor. Elaboración propia del autor basado en [10]
2.3.1.2 Fase: Análisis del problema
En la Tabla 18 se especifican las actividades, entregables y responsables de esta fase.
Actividades Entregables Responsable
Establecer reglas del negocio
Reglas del negocio Analista
Caracterizar el dominio del problema
Tabla explicativa del diagrama de procesos
Analista
Diagrama de procesos Analista
Diagrama de objetivos Analista
Diagrama causa-efecto Analista
Desarrollar el diccionario de datos
Diccionario de datos Analista
Gestionar la elaboración de tareas
Tablero Kanban Analista
Reportar el progreso del proyecto
Reporte de avance de los alfas Analista
Tabla 18. Actividades, entregables y responsables en la fase análisis del problema. Síntesis
del autor. Elaboración propia del autor basado en [10]
25
2.3.1.3 Fase: Propuestas de solución En la Tabla 19 se especifican las actividades, entregables y responsables de esta fase.
Actividades Entregables Responsable
Desarrollar nuevo organigrama
Organigrama Analista
Desarrollar nuevo diagrama de procesos
Diagrama de procesos Analista
Especificar la funcionalidad de la aplicación de software
Casos de uso Analista
Diagrama de flujo de interfaz de usuario
Analista
Establecer el valor de la solución
Estimación del valor de la solución Analista
Tabla explicativa del diagrama de procesos
Analista
Establecer factores críticos de éxito
Factores críticos de éxito Analista
Hoja de vida del indicador Analista
Gestionar la elaboración de tareas
Tablero Kanban Analista
Reportar el progreso del proyecto
Reporte de avance de los alfas Analista
Tabla 19. Actividades, entregables y responsables en la fase propuestas de solución.
Síntesis del autor. Elaboración propia del autor basado en [10]
2.3.1.4 Fase: Esquema conceptual En la Tabla 20 se especifican las actividades, entregables y responsables de esta fase.
Actividades Entregables Responsable
Especificar la funcionalidad de la aplicación de software
Especificaciones basadas en el esquema preconceptual
Analista
Diagrama de clases Analista
Diagramas de comunicación Analista
Diagramas de máquina de estados Analista
Proporcionar las bases para la construcción de la aplicación final
Ejemplo de código fuente Desarrollador
Desarrollar prototipo Alfa Prototipo Alfa Desarrollador
Gestionar la elaboración de tareas
Tablero Kanban Analista
Reportar el progreso del proyecto
Reporte de avance de los alfas Analista
Tabla 20. Actividades, entregables y responsables en la fase esquema conceptual. Síntesis
del autor. Elaboración propia del autor basado en [10]
2.4 RUP
RUP es un método que integra los aspectos que se requieren durante el proceso de desarrollo de
software para el análisis, desarrollo y documentación de sistemas orientados a objetos. Este método
26
proporciona un acercamiento disciplinado a la asignación de tareas y responsabilidades de un
proyecto en una organización [11]. Con el método RUP se realiza un levantamiento exhaustivo de
requisitos, se busca detectar defectos en las fases iniciales, intentando reducir al número de cambios
tanto como sea posible, se realiza el análisis y diseño del sistema y se intenta anticipar futuras
necesidades [12].
Las características principales de RUP son [13]:
Guiado por casos de Uso: el método describe la secuencia completa de interacciones entre el
usuario y el sistema.
Centrado en arquitectura: Comprende las diferentes vistas del sistema en desarrollo, las cuales
corresponden a los modelos del sistema, como los modelos de casos de uso, de análisis, de
diseño, de despliegue e implementación.
Iterativo e Incremental: una iteración se compone de los requisitos, el análisis, el diseño, la
implementación y las pruebas. Cada iteración sólo entrega una parte pequeña pero funcional del
sistema, los requisitos y modelos se desarrollan de forma progresiva.
Desarrollo basado en componentes: la creación de sistemas de software requiere la división del
sistema en componentes definidas.
Lenguaje de modelado único: se adopta UML para el desarrollo de todos los modelos.
Proceso integrado: RUP establece una estructura que abarca ciclos, fases, flujos de trabajo,
mitigación de riesgos, control de calidad y gestión de proyectos.
El proceso del RUP se ejecuta en tres perspectivas [11] [14] [15], tal como se aprecia en la Figura 9:
Figura 9. Estructura de RUP [15]
27
La perspectiva estática contiene los siguientes elementos:
Rol: individuo o grupo de individuos que llevan a cabo actividades y producen artefactos.
Actividad: es una unidad de trabajo que realiza un rol.
Artefacto: es un trozo de información que un proceso produce, modifica o usa. Es un producto
tangibles de un proyecto y se va creando y usando hasta obtener el producto final.
Flujo de trabajo: define la secuencia de actividades que realizan los roles.
La perspectiva dinámica contiene las fases del modelo sobre el tiempo. En la Tabla 21 se especifican
los objetivos de cada fase del método.
Fase Descripción
Inicio
En esta fase se identifican las entidades externas que interactúan con el sistema y sus respectivas iteraciones. Los objetivos principales de esta fase son:
Establecer el alcance del proyecto de software y las condiciones, incluyendo un concepto operacional, criterios de aceptación y descripciones de lo que debe ser parte o no del producto.
Discriminar los casos de uso críticos del sistema, es decir, los escenarios principales de la conducta que impulsarán la funcionalidad del sistema.
Proponer al menos una arquitectura candidata contra algunos de los escenarios principales.
Estimar el costo total y el calendario para todo el proyecto.
Estimar los riesgos.
Elaboración
Tiene como fin desarrollar un entendimiento del dominio del problema, crear un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riesgos clave. Al finalizar esta fase, se debe tener el modelo de requisitos del sistema (UML), una arquitectura y un plan de desarrollo. Los objetivos principales de esta fase son:
Definir y validar la línea base.
Definir la línea base de la visión.
Definir la línea base de un plan de alta fidelidad para la fase de construcción.
Demostrar que la arquitectura de referencia apoyará la visión a un costo y tiempo razonable.
Construcción
Su objetivo es el diseño del sistema, la programación, las pruebas y la integración de todas las partes del sistema software. Al final de esta fase se debe tener un software operativo con su respectiva documentación. Los objetivos principales de esta fase son:
Minimizar los costos de desarrollo optimizando recursos.
Lograr la adecuada calidad tan rápido como sea posible.
Lograr versiones ejecutables (alfa, beta y otras) tan rápido como sea posible.
Transición
En esta fase, el sistema de software se entrega a los interesados para sus respectivas pruebas en un entorno real. Al terminar esta fase, se debe tener un software documentado y funcionando correctamente. Los objetivos principales de esta fase son:
Lograr soporte a usuarios.
Lograr la participación de las partes interesadas.
Lograr la línea base del producto final lo más rápido y rentable como sea posible.
Tabla 21. Objetivos de las fases del método RUP. Elaboración propia del autor basado en
[16]
28
Disciplinas, actividades, artefactos y roles [16]
Este método presenta nueve disciplinas: modelo empresarial, requisitos, análisis y diseño,
implementación, pruebas, despliegue, gestión de cambios de configuración, gestión de proyectos y
entornos (véase la Fig. 9). A lo largo de las cuatro fases de RUP se presentan actividades, roles y
artefactos necesarios en el desarrollo del proyecto.
2.4.1.1 Fase: Inicio
Dentro de esta fase, los roles realizan las siguientes actividades esenciales:
Formular el alcance del proyecto, es decir, captar el contexto, las necesidades importantes
y las limitaciones para cumplir los criterios de aceptación del producto final.
Planificar y preparar un caso de negocio y evaluar alternativas para la gestión de riesgos, la
dotación de personal, el plan de proyecto y las compensaciones entre costos, el cronograma
y la rentabilidad.
Sintetizar una arquitectura candidata.
En esta fase se producen, esencialmente, los siguientes artefactos:
Documento de visión: una visión general de los requisitos del proyecto, características clave
y limitaciones principales
Modelo de casos de uso: enumera todos los casos de uso y actores que se pueden identificar
en la primera etapa
Glosario inicial del proyecto
Caso de negocio inicial:
o Contexto de negocios
o Criterios de éxito
o Previsión financiera
Evaluación inicial de riesgos
Plan de proyecto: muestra las fases e iteraciones
2.4.1.2 Fase: Elaboración
Las actividades esenciales de la fase de elaboración son las siguientes:
Elaborar la visión, una comprensión sólida que se establece de los casos de uso críticos que
impulsan las decisiones arquitectónicas y de planificación.
Elaborar el proceso, la infraestructura y el entorno de desarrollo y alistar las herramientas.
Elaborar arquitectura y seleccionar los componentes. Los componentes de arquitectura
seleccionados se integran y evalúan respecto de los escenarios principales.
En esta fase se producen esencialmente los siguientes artefactos:
Modelo de casos de uso (por lo menos 80% completo)
29
Requisitos adicionales: capturan los requisitos no funcionales y los requisitos que no se
asocian con un caso de uso específico
Descripción de la arquitectura software
Prototipo de arquitectura ejecutable
Lista de riesgos revisada y el caso de negocio revisado
Plan de desarrollo para el proyecto
Caso de desarrollo actualizado: especifica el proceso que se utilizará
Manual de usuario preliminar (opcional)
2.4.1.3 Fase: Construcción
Dentro de esta fase, los roles realizan las siguientes actividades esenciales:
Gestionar los recursos y especificar el control de los recursos y la optimización de procesos.
Desarrollar los componentes completamente y las pruebas definidas en la evaluación de
criterios.
Evaluar las versiones de los productos con los criterios de aceptación.
En esta fase se producen, esencialmente, los siguientes artefactos:
Producto de software integrado en las plataformas adecuadas
Manual de usuario
Descripción de la versión actual
2.4.1.4 Fase: Transición
Dentro de esta fase, los roles realizan las siguientes actividades esenciales:
Implementar ingeniería, es decir, paquetes comerciales, producción y despliegue de ventas.
Capacitar el personal.
Corregir errores y mejorar el rendimiento y la usabilidad.
Evaluar las líneas base de despliegue descritas en la visión y los criterios de aceptación para
el producto.
2.5 Prácticas de ingeniería de software
El método RUP define las seis mejores prácticas para el desarrollo de software, las cuales se definen
a continuación [3] [14] [17]:
30
Mejores prácticas de RUP
2.5.1.1 Desarrollo iterativo
El enfoque iterativo permite una comprensión creciente del problema mediante refinamientos
sucesivos, llegando a una solución efectiva luego de múltiples iteraciones acotadas en complejidad.
Adicionalmente, ayuda a atacar los riesgos mediante la producción de versiones ejecutables
progresivas y frecuentes que permiten la opinión e involucramiento del usuario. Por medio de las
iteraciones que generan las versiones ejecutables, se logran detectar en forma temprana los
desajustes e inconsistencias entre los requisitos, el diseño, el desarrollo y la implementación del
sistema, manteniendo al equipo de desarrollo enfocado en producir resultados.
2.5.1.2 Gestión de requisitos
La práctica de gestión de requisitos permite adquirir, organizar y documentar cómo funciona el
sistema, incluyendo sus restricciones. La gestión de requisitos permite:
Analizar el problema de interesado
Comprender las necesidades del interesado
Manejar el alcance del proyecto
Definir el sistema
Establecer y mantener un acuerdo entre el interesado y el equipo de trabajo en relación con
los requisitos cambiantes
Utilizar los casos de uso y los escenarios ayuda a capturar los requisitos funcionales, asegurar el
diseño, implementación y prueba del sistema, logrando así que el sistema satisfaga las necesidades
del usuario.
2.5.1.3 Modelado visual
Esta práctica permite modelar software visualmente para capturar el diseño del software, es decir, la
estructura y el comportamiento de arquitecturas y componentes. Las abstracciones visuales ayudan
a comunicar diferentes aspectos del software mejorando la comunicación en el equipo; comprender
los requisitos, ver como los elementos del sistema se relacionan entre sí y mantener la consistencia
entre diseño e implementación. El estándar UML (Lenguaje de Modelado Unificado), es la base para
un modelado visual exitoso.
2.5.1.4 Desarrollo basado en componentes
Esta práctica describe cómo diseñar una arquitectura flexible, que se acople con los cambios,
comprensible intuitivamente y que origine una más efectiva reutilización del software. Esta práctica
permite obtener el control intelectual del proyecto con el fin de mantener la complejidad e integridad
del mismo. El propósito es disminuir los riesgos de desempeño, capacidad y confiabilidad.
31
2.5.1.5 Verificación continua de la calidad
Durante el desarrollo de software es necesario evaluar la calidad de un sistema respecto de sus
requisitos de funcionalidad. Los artefactos que producen las actividades se deben evaluar cuando
se generan y al finalizar cada iteración, ya que la calidad del producto implica construirlo
correctamente y que sea admisible para el interesado. La actividad fundamental es el testing, el cual
permite encontrar las fallas antes de la puesta en producción. Esta práctica permite la planeación,
diseño, implementación, ejecución y evaluación de todos los tipos de testing.
2.5.1.6 Control de cambios de software
Esta práctica describe cómo controlar, encontrar y monitorear los cambios durante el desarrollo
iterativo del software de forma exitosa. Es una guía que permite establecer espacios para cada
desarrollador, proporcionando el aislamiento de los cambios hechos en otros espacios mientras se
controlan los cambios de todos los elementos del software. Esta práctica permite conocer cómo
automatizar la integración y administrar las versiones.
Prácticas de la metodología FDD (Feature Driven Development)
La metodología define mejores prácticas reconocidas en la industria para el desarrollo de software
orientado a funcionalidades. Algunas de esas prácticas se definen a continuación [3] [18]:
2.5.2.1 Modelado de objetos de dominio
Esta práctica consiste en explorar y explicar el dominio del problema a resolver. El modelado
resultante provee un marco de trabajo global en el cual agregar funcionalidades.
2.5.2.2 Visibilidad del progreso y resultados
Son frecuentes, apropiados y específicos reportes de progresos a todos los niveles organizativos,
dentro y fuera del proyecto, basándose en el trabajo o partes terminadas, lo cual permite a los
gerentes o directores dirigir correctamente el proyecto.
Prácticas de Software Quality Assurance (SQA)
Según Galin [19], Software Quality Assurance “comprende un conjunto de acciones necesarias para
proporcionar la confianza de que el proceso de desarrollo de software o mantenimiento de un
producto de sistema de software se ajusta a los requisitos establecidos durante su permanencia
dentro de la programación y el presupuesto”. A continuación, se especifica una de sus prácticas [20]:
2.5.3.1 Establecimiento de actividades para satisfacer las prácticas de calidad requeridas
Esta práctica tiene asociadas las siguientes subprácticas que la definen:
Actividades para revisar la calidad de los productos generados al final de cada fase de
desarrollo del software.
32
Actividades para revisar la calidad de los productos generados al final de cada cambio
producido en mantenimiento.
Actividades para administrar el control de cambios durante el desarrollo y mantenimiento.
Práctica de Project Management Body of Knowledge (PMBOK)
PMBOK establece que realizar el análisis del valor agregado es "un método objetivo para medir el
desempeño del proyecto en lo referente al alcance, tiempo y costo". PMI incluye el estándar del
método del valor agregado como práctica para la dirección de proyectos [21].
2.5.4.1 Gestión de valor agregado
La gestión del valor agregado es una técnica de gestión de proyectos que permite establecer el
presupuesto y el calendario de ejecución para controlar la ejecución de un proyecto.
Prácticas CMMI
CMMI (Capability Maturity Model Integration) es un modelo de madurez de mejora de los procesos
para el desarrollo de productos y servicios. Comprende las mejores prácticas que abarcan las
actividades de desarrollo y mantenimiento del ciclo de vida del proyecto [22] [23].
2.5.5.1 Planificación del proceso
El propósito de esta práctica genérica es determinar lo que se requiere para realizar un proceso y
alcanzar los objetivos establecidos durante el desarrollo del proyecto, mediante la realización de
planes y descripciones del proceso.
2.5.5.2 Suministro de recursos
El propósito de esta práctica genérica es asegurar que los recursos que son necesarios durante el
desarrollo del proyecto o proceso, que se definan en el plan, se encuentren disponibles cuando se
requieran. Los recursos incluyen instalaciones físicas y herramientas apropiadas.
2.5.5.3 Formación del personal
Es una práctica genérica que comprende el área de la planificación del proyecto. El propósito es
asegurar que las personas del equipo tengan habilidades y experiencia para llevar a cabo las
actividades del proceso mediante una formación apropiada. Dentro de esta práctica se realiza la
práctica específica “Planificar el conocimiento y habilidades necesarias”.
2.5.5.4 Monitoreo y control del proceso
El propósito de esta práctica genérica es realizar el monitoreo y control del proceso a diario, lo cual
implica medir atributos del proceso o de los productos de trabajo para tener una visibilidad apropiada
del proyecto. Esta práctica se encuentra definida en las siguiente subprácticas:
Evaluar el progreso y rendimiento reales. Revisar los logros y resultados del proceso.
33
Revisar las actividades, el estado y los resultados del proceso.
Identificar y evaluar los efectos de las desviaciones importantes dentro del plan
Identificar problemas.
Tomar acciones correctivas cuando no se satisfacen los requisitos.
2.5.5.5 Asignación de responsabilidad
Es una práctica genérica que asegura que existen responsabilidades para realizar un proceso, con
las cuales se logran resultados durante el desarrollo del proyecto. Esta práctica presenta las
siguientes subprácticas:
Asignar la responsabilidad y la autoridad en su totalidad para realizar el proceso.
Asignar la responsabilidad y la autoridad para realizar las tareas específicas del proceso.
Confirmar que las personas a las que se les asignó responsabilidad y autoridad las
comprenden y las aceptan.
2.5.5.6 Determinación de estimaciones de esfuerzo de trabajo y costo
Esta práctica establece estimaciones de esfuerzo y costo mediante la estimación de atributos de
productos de trabajo y tareas, estableciendo tiempos entre tareas y los riesgos que el proyecto
incluya. Algunos productos típicos de trabajo de esta práctica son:
Estimación racional.
Estimaciones del esfuerzo para el proyecto.
Estimaciones del costo del proyecto.
3 ANTECEDENTES
Las representaciones de la estructura de RUP existentes en la literatura presentan, en general, la
jerarquización de los elementos del método, con el fin de dar a entender el funcionamiento del
método de forma general. Por ello, estas representaciones especifican los elementos y la interacción
entre los mismos, tal como se puede apreciar en la Figuras 10 y 11, donde se visualiza la estructura
de RUP pero no se especifican todos los elementos del método.
34
Figura 10. Elementos de método RUP. Traducido de [15]
RUP consta de elementos como fases, las cuales comprenden disciplinas. Cada una de las
disciplinas agrupa actividades que se dividen en tareas, mientras las tareas se dividen en pasos. Los
diferentes roles son los encargados de llevar a cabo las tareas y de producir y utilizar los artefactos
correspondientes a cada tarea [15].
Figura 11. Componentes del método RUP. Traducido de [24]
Sin embargo, estas representaciones se enfocan únicamente en la visualización de los elementos
del método que conforman la estructura de RUP y la relación entre los mismos. En ambas
representaciones, el nivel de especificación de elementos es menor.
35
En la literatura se encontraron otras representaciones donde se pueden visualizar los elementos de
los métodos, como los artefactos y las actividades con las que se asocian (véase la Fig. 12).
Figura 12. Artefactos y actividades de la disciplina requisitos. Traducido de [15]
Sin embargo, como RUP se divide en disciplinas, se muestran las representaciones de cada una por
separado y este trabajo se enfocan únicamente en la disciplina de requisitos y modelado empresarial.
Adicionalmente, se encontró una representación de RUP con los elementos del núcleo de Semat.
Tal como se puede ver en la Figura 13, en este trabajo se caracterizan las seis mejores prácticas
propuestas en la metodología de acuerdo con las tres áreas de interés que Semat define. Se define
la asociación a la práctica “Develop Software Iteratively” los alfas asociados y definen los alfas
“Opportunity”, “Software system” y “Way of working” mediante los productos de trabajo que se
generan, de acuerdo con las actividades que especifica el método. Sin embargo, en este trabajo no
se representa el método completo, sino una parte específica de RUP. Adicionalmente, sólo se
presenta la secuencia de actividades en la representación propia del método y no con los elementos
del núcleo de Semat. Tampoco se incluyen las competencias requeridas para cada actividad ni la
definición de la práctica mediante los espacios de actividad.
36
Figura 13. Resultados del trabajo sobre la estructura RUP en Semat [25]
CDM consta de elementos como fases. Cada fase es un conjunto de procesos, cada proceso es un
conjunto de tareas y las tareas se pueden clasificar como tareas requisito o tareas resultantes de
acuerdo al proceso que se ejecute. Del método CDM no se encontraron representaciones gráficas
de los elementos que lo componen. Sin embargo, existe la representación de dos dimensiones que
permite visualizar algunos elementos del método, tal como se aprecia en la Figura 5, donde se
identifican los procesos y las fases del método.
Del UNC-Method, no se encontraron representaciones gráficas de sus elementos en la literatura.
4 CAPÍTULO 4. PROPUESTA DE SOLUCIÓN
4.1 Representación de las prácticas en el núcleo de Semat
A continuación, se presenta la caracterización de las prácticas encontradas en la literatura, de
acuerdo con las áreas propuestas en el estándar de Semat.
En el área de conocimiento cliente se incluye a los interesados, por lo cual la práctica perteneciente
a este grupo se muestra en la Figura 14:
37
Figura 14. Práctica del área de conocimiento clientes. Elaboración propia del autor.
En el área de conocimiento solución, el equipo necesita establecer los requisitos e implementar,
construir, probar y mantener un sistema de software, por lo cual las prácticas pertenecientes a este
grupo se muestran en la Figura 15:
Figura 15. Prácticas del área de conocimiento solución. Elaboración propia del autor.
En el área de conocimiento esfuerzo, se tiene que establecer el equipo, su forma de trabajo y se
tiene que hacer el trabajo, por lo cual las prácticas pertenecientes a este grupo se muestran en la
Figura 16:
Figura 16. Prácticas del área de conocimiento esfuerzo. Elaboración propia del autor.
4.2 Representación gráfica del método CDM
Para realizar la representación de los distintos conceptos del método CDM Fast Track con los
elementos del núcleo de Semat, se proponen las siguientes especificaciones:
Una tarea en CDM, al generar un servicio o entregable, se representa en Semat como una
actividad.
38
Un entregable, por su definición, se representa en Semat como un producto de trabajo.
El responsable es el rol en Semat, el cual se representa mediante el símbolo patrón.
Debido a que en la literatura no se encuentran especificadas las prácticas del método CDM, se
propone la asociación con prácticas de la ingeniería de software ya existentes para su inclusión en
el núcleo de Semat. El conjunto de actividades asociadas con los productos de trabajo y las
actividades de este método se visualizan en la Figura 17.
Figura 17. Prácticas de los métodos CDM y PJM. Elaboración propia del autor.
A continuación, se presentan las actividades, el rol que las realiza y los productos de trabajo por
fases, organizados en tablas (véanse las Tablas 24, 25, 26 y 27). Además, se muestra la asociación
con los alfas cuyos estados se afectan al realizar cada actividad. Se especifica el espacio de
actividad al que pertenece cada actividad establecida en la metodología CDM y en la metodología
de gestión de proyectos PJM. Adicionalmente, se propone la representación con los elementos del
núcleo de Semat.
Para llevar a cabo esta representación se toma en consideración la descripción de actividades y
productos de trabajo, los cuales se definen en la Tabla 22 y en la Tabla 23 respectivamente.
Actividad Descripción
Detallar el negocio y objetivos del sistema
Si la organización del cliente estableció un programa de reutilización, se deben escoger asesores.
Implementar las normas de definición de requisitos y directrices
Se pueden buscar las normas actuales de construcción de modelos y directrices que, o bien se utilizan en toda la empresa o se usaron en un proyecto anterior.
Documentar las interfaces del sistema existente
Obtener información acerca de las interfaces existentes para la identificación de las oportunidades de reutilización.
Obtener arquitectura técnica existente
Obtener información acerca de los componentes del sistema existente y arquitecturas de red que puede reutilizar.
Crear arquitectura técnica Al crear la arquitectura técnica, debe decidir qué componentes reutilizados se integrarán y cómo se encajan en la arquitectura.
Tabla 22. (Parte 1/2) Descripción de principales tareas. Elaboración propia del autor
basado en [10]
39
Actividad Descripción
Implementar normas base de datos y directrices
Buscar normas y directrices existentes de bases de datos utilizadas en la empresa, en proyectos actuales o anteriores.
Desarrollar prototipo look and feel
No se debe relacionar con el dominio del negocio; se deben reutilizar módulos de un proyecto anterior, si es posible.
Desarrollar la definición de hardware y software
Describir cualquier compra de componentes
Diseñar módulos de conversión de datos
Se deben tratar de reutilizar los scripts y programas.
Desarrollar listas de chequeo de prueba del módulo
Obtener y adaptar las listas existentes y tipos de módulos que se probarán en el proyecto.
Tabla 22. (Parte 2/2) Descripción de principales tareas Elaboración propia del autor
basado en [10]
Producto de trabajo Descripción
Negocio y objetivos del sistema
Documento en el que consten los beneficios empresariales que el cliente quiere ganar de la solución.
Modelo de proceso del contexto
El modelo de proceso, las unidades de negocio, las áreas funcionales y las relaciones entre estos ámbitos.
Lista de alto nivel MoSCoW Lista de ponderación y en orden de prioridad de los procesos de negocio y de las principales funciones de la empresa.
Procesos de particiones de alto nivel del negocio y funciones
Descripción de cómo el sistema se está partiendo.
Material de referencia ya existente
Materiales de referencia que se relacionan con los objetivos empresariales del proyecto.
Interfaces del sistema existente
Informe con la lista de interfaces del sistema existente.
Plan de capacidad existente Plan con los requisitos actuales y futuros de capacidad de almacenamiento en disco y la infraestructura en general.
Definición de la arquitectura del sistema
Se definen los requisitos de hardware y software del proyecto y entornos de producción.
Conversión de datos de los requisitos
Descripciones de alto nivel para cada uno de los sistemas de origen y los requisitos funcionales para convertir y cargar los datos.
Documentación de requisitos Documentación que se necesitará durante y al final del proyecto.
Requisitos de pruebas Requisitos para la realización de pruebas. Son los requisitos para el proceso de desarrollo en lugar del sistema que se está produciendo.
Equipo de proyecto integrado Equipo de desarrolladores, usuarios, administradores y participantes en el proyecto que entienden el proyecto y sus funciones.
Modelo detallado del proceso de negocio
Modelo de los acontecimientos y de los procesos de negocio necesarios para cumplir con los objetivos empresariales definidos.
Modelo detallado de la función del negocio
Jerarquía de funciones incluyendo sus descripciones basadas en las descripciones del negocio.
Prototipo funcional validado Prototipo generado con las decisiones de los espacios de trabajo y las peticiones de cambio registradas.
Lista MoSCoW redefinida Lista detallada de prioridades que cambia durante las iteraciones si los usuarios cambian sus prioridades.
Tabla 23. (Parte 1/2) Descripción de principales entregables. Elaboración propia del autor
basado en [10]
40
Producto de trabajo Descripción
Descripción de la función del sistema existente
Un informe completo de las descripciones de las funciones correspondientes al sistema existente.
Modelo de datos del sistema existente
Definición y modelo entidad-relación de la estructura lógica de la información del sistema actual.
Descripción de procedimientos operacionales existentes
Informe con las copias de la documentación del cliente y de los procedimientos existentes relevantes para el nuevo sistema.
Arquitectura técnica Hardware, software, herramientas y requisitos de configuración necesarios para apoyar el desarrollo y la validación.
Problemas de rendimiento Los requisitos cuantitativos para mejorar el rendimiento del sistema.
Prototipo look and feel Prototipo funcional que sólo se crea con el fin de lograr un acuerdo sobre el aspecto de la aplicación.
Plan de trabajo de conversión de datos
Plan de trabajo para la conversión de datos.
Requisitos de formación Los tipos de capacitación (cursos formales, talleres o tutoriales) que se deben preparar para el nuevo sistema.
Modelo de requisitos del negocio rested
La combinación de la salida de tareas: crear modelo detallado del proceso de negocio, recopilar información detallada del negocio, construir modelo de datos del negocio y construir modelo detallado de la función del negocio.
Datos convertidos y verificados
Datos de producción convertidos y verificados. Debe incluir todo lo que sea necesario para la aplicación en producción.
Referencia del usuario Descripciones detalladas de la utilización de cada función del sistema.
Guía de usuario Guía de procedimiento completa para el uso de la aplicación para responder a todos los eventos de negocios.
Referencia técnica detallada Describe los componentes técnicos de la aplicación. Se utiliza en el mantenimiento de la aplicación.
Guía de operaciones del sistema
Guía completa que contiene las tareas y procedimientos requeridos para mantener el sistema operando y funcionando para los usuarios.
Resultados de la validación de preproducción
Una declaración de usuario que confirma que el sistema está listo para ir a producción. Los usuarios aceptan el nuevo sistema, la conversión de datos y documentación, para su uso en producción.
Capacitación de los usuarios Los usuarios capacitados para utilizar el nuevo sistema tienen sesiones de entrenamiento y pueden resolver nuevos problemas de negocio.
Capacitación de administradores
Los administradores del sistema, los administradores de la base de datos y personal de operaciones que son capaces de mantener el sistema día a día y con éxito.
Sistema en producción Los usuarios tienen acceso y el negocio se está ejecutando en el nuevo sistema.
Plan de mejora Manejo de mejoras funcionales y no funcionales.
Tabla 23. (Parte 2/2) Descripción de principales entregables [10]
Las prácticas asociadas con este método se definen mediante alfas y espacios de trabajo, tal como
se puede ver en las Figuras 18 y 19, respectivamente.
41
Figura 18. Definición de prácticas mediante los alfas
Figura 19. Definición de prácticas mediante espacios de actividad
Fase: Definición
En la Tabla 24 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad, Interesados
Negocio y objetivos del sistema
Detallar el negocio y objetivos del sistema
Promotor del proyecto
Oportunidad Modelo de proceso del contexto
Crear el modelo de proceso del contexto
Desarrollador principal de la aplicación
Oportunidad Modelo de proceso de negocio de alto nivel
Crear el modelo de proceso de negocio de alto nivel
Desarrollador principal de la aplicación
Tabla 24. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
definición. Elaboración propia del autor.
42
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Descripciones del negocio de alto nivel
Obtener descripciones del negocio de alto nivel
Desarrollador principal de la aplicación
Oportunidad
Definición de la estructura actual y futura de la organización
Documentar la estructura actual y futura de la organización
Desarrollador principal de la aplicación
Oportunidad Modelo compuesto de función del negocio
Crear el modelo compuesto de función del negocio
Desarrollador principal de la aplicación
Oportunidad Modelo de datos del negocio de alto nivel
Crear el modelo de datos del negocio de alto nivel
Desarrollador principal del sistema
Oportunidad Procesos divididos de alto nivel del negocio y funciones
Definir las particiones Gerente de proyecto
Comprender las necesidades de los interesados
Interesados Lista de alto nivel MoSCoW
Crear lista MoSCoW Usuario embajador
Oportunidad Material de referencia ya existente
Obtener material de referencia ya existente
Desarrollador
Oportunidad, Interesados
Negocio y objetivos del sistema
Detallar el negocio y objetivos del sistema
Promotor del proyecto
Interesados Equipo de proyecto Integrado
Lanzar el proyecto Gerente de proyecto
Interesados Modelo de alto nivel del sistema de datos existente
Crear modelo de alto nivel del sistema de datos existente
Desarrollador
Interesados Modelo de proceso del sistema existente
Crear el modelo de proceso del sistema existente
Desarrollador principal de la aplicación
Interesados Interfaces del sistema existente
Documentar los Interfaces del sistema existente
Desarrollador
Interesados Arquitectura Técnica Existente
Obtener arquitectura técnica existente
Desarrollador principal del sistema
Comprender los requisitos
Oportunidad Material de referencia ya existente
Obtener material de referencia ya existente
Desarrollador
Requisitos Modelo de alto nivel del sistema de datos existente
Crear modelo de alto nivel del sistema de datos existente
Desarrollador
Requisitos Modelo de proceso del sistema existente
Crear el modelo de proceso del sistema existente
Desarrollador principal de la aplicación
Requisitos Interfaces del sistema existente
Documentar las Interfaces del sistema existente
Desarrollador
Requisitos Arquitectura técnica existente
Obtener arquitectura técnica existente
Desarrollador principal del sistema
Requisitos Glosario Desarrollar glosario Desarrollador
Tabla 24. (Parte de 2/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
definición. Elaboración propia del autor.
43
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Conversión de datos de los requisitos
Documentar la conversión de datos de los requisitos
Desarrollador
Requisitos Documentación de requisitos
Especificar documentación de requisitos
Escritor técnico
Requisitos Requisitos de pruebas
Determinar los requisitos de pruebas
Tester principal
Darle forma al sistema
Sistema de software
Definición de la arquitectura del sistema
Definir la arquitectura del sistema
Desarrollador principal del sistema
Prepararse para hacer el trabajo
Forma de trabajo
Plan de capacidad existente
Obtener el plan de capacidad existente
Desarrollador principal del sistema
Forma de trabajo
Normas de definición de requisitos del negocio y directrices
Implementar las normas de definición de requisitos y directrices
Desarrollador principal de la aplicación
Equipo Equipo de proyecto integrado
Lanzar el proyecto Gerente de proyecto
Forma de trabajo
Plan de gestión del alcance del Proyecto
Establecer el alcance, los objetivos y el enfoque
Gerente de proyecto
Forma de trabajo
Estrategias de control y presentación de informes, normas y procedimientos
Definir las estrategias de control y presentación de informes, las normas y los procedimientos
Gerente de proyecto
Forma de trabajo
Plan de gestión de proyectos
Establecer planes de gestión
Gerente de proyecto
Forma de trabajo
Trabajo de las estrategias de gestión, normas y procedimientos
Definir el trabajo Las estrategias de gestión, normas y procedimientos
Gerente de proyecto
Forma de trabajo
Plan de trabajo Establecer plan de trabajo Gerente de proyecto
Forma de trabajo, trabajo
Plan de financiación Establecer plan de financiación
Gerente de proyecto
Forma de trabajo
Las estrategias de gestión de los recursos, normas y procedimientos
Definir las estrategias de gestión de los recursos , normas y procedimientos
Gerente de proyecto
Forma de trabajo
Guía de la orientación proyecto
Creación de un proyecto guía de orientación
Gerente de proyecto
Trabajo Organización preparada
Aplicar organización Gerente de proyecto
Forma de trabajo
Plan de recursos físicos
Establecer plan de recursos físicos
Gerente de proyecto
Trabajo Infraestructura preparada
Establecer la infraestructura
Gerente de proyecto
Forma de trabajo
Estrategias de ges-tión de calidad, nor-mas y procedimientos
Definir estrategias de gestión de la calidad, normas y procedimientos
Gerente de proyecto
Tabla 24. (Parte de 3/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
definición. Elaboración propia del autor.
44
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Gestión de la configuración las estrategias, normas y procedimientos
Definir las estrategias de gestión de configuración , normas y procedimientos
gerente de proyecto
Coordinar actividades
Equipo Dotación de personal y plan de su organización
Establecer personal y organización plan
gerente de proyecto
Apoyar el equipo
Equipo Equipo de proyecto integrado
Lanzar el proyecto gerente de proyecto
Seguimiento del progreso
Trabajo Línea base auditada Auditar entregables principales
gerente de proyecto
Trabajo Reporte de calidad Realizar evaluación de calidad
gerente de proyecto
Trabajo Auditoría de calidad Realizar auditoría de calidad
gerente de proyecto
Trabajo Lanzamiento de recursos físicos
Lanzar recursos físicos gerente de proyecto
Tabla 24. (Parte de 4/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
definición. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la primera fase de CDM Fast Track
y PJM se visualizan en las Figuras 21-28 y la secuencia de actividades se muestra en la Figura 20.
Figura 20. Secuencia de actividades en la fase Definición. Elaboración propia del autor.
45
Figura 21. Definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.
46
Figura 22. Definición de la práctica Modelado de objetos de dominio
47
Figura 23. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
48
Figura 24. Definición de la práctica Asignación de responsabilidades. Elaboración propia del autor.
49
Figura 25. Definición de la práctica Suministro de recursos. Elaboración propia del autor.
Figura 26. Definición de la práctica Monitoreo y control de recursos. Elaboración propia del autor.
50
Figura 27. Definición de la práctica Planificación del proceso. Elaboración propia del autor.
51
Figura 28. Definición de la práctica Planificación del proceso. Elaboración propia del autor.
52
Fase: Modelado de requisitos
En la Tabla 25 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender las necesidades de los interesados
Interesados Información detallada del negocio
Recopilar información detallada del negocio
Desarrollador
Interesados Prototipo funcional validado
Validar prototipo funcional
Usuario embajador
Interesados Lista MoSCoW redefinida
Redefinir requisitos Usuario embajador
Interesados Descripción de la función del sistema existente
Producir descripción de la función del sistema existente
Desarrollador
Interesados Modelo de datos del sistema existente
Generar modelo de datos del sistema existente
Desarrollador
Asegurar la satisfacción de los interesados
Oportunidad, interesados
Prototipo funcional validado
Validar prototipo funcional
Usuario embajador
Oportunidad, interesados
Prototipo look and feel
Desarrollar prototipo look and feel
Desarrollador principal de la aplicación
Oportunidad, interesados
Requisitos de la interfaz usuario
Validar look and feel Usuario embajador
Oportunidad, interesados
Prototipo funcional Desarrollar prototipo funcional
Desarrollador
Comprender los requisitos
Requisitos Modelo detallado del proceso de negocio
Crear modelo detallado del proceso de negocio
Desarrollador
Requisitos Información detallada del negocio
Recopilar información detallada del negocio
Desarrollador
Requisitos Modelo de datos del negocio
Construir modelo de datos del negocio
Desarrollador
Requisitos Modelo detallado de la función del negocio
Construir modelo detallado de la función del negocio
Desarrollador
Requisitos Lista MoSCoW redefinida
Redefinir requisitos Usuario embajador
Requisitos Descripción de la función del sistema existente
Producir descripción de la función del sistema existente
Desarrollador
Requisitos Modelo de datos del sistema existente
Generar modelo de datos del sistema existente
Desarrollador
Requisitos
Descripción de los procedimientos operacionales existentes
Elaborar descripción de los procedimientos operacionales existentes
Desarrollador principal del sistema
Tabla 25. (Parte 1/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
modelado de requisitos. Elaboración propia del autor.
53
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Requisitos operacionales detallados del sistema
Definir los requisitos operacionales detallados del sistema
Desarrollador principal del sistema
Requisitos Requisitos de formación
Crear requisitos de formación
Desarrollador principal de la aplicación
Darle forma al sistema
Sistema de software
Arquitectura técnica Crear arquitectura técnica
Desarrollador principal del sistema
Sistema de software
Problemas de rendimiento
Determinar problemas de rendimiento
Desarrollador principal del sistema
Implementar el sistema
Sistema de software
Diseño lógico de base de datos
Crear diseño lógico de base de datos
Desarrollador principal del sistema
Sistema de software
Base de datos ddl del prototipo funcional
Crear base de datos ddl del prototipo funcional
Desarrollador principal del sistema
Sistema de software
Diseño de la aplicación Diseñar aplicación Desarrollador principal de la aplicación
Sistema de software
Entorno de desarrollo inicial
Crear entorno de desarrollo inicial
Gerente de configuración
Sistema de software
Prototipo funcional Desarrollar prototipo funcional
Desarrollador
Sistema de software
Prototipo look and feel Desarrollar prototipo look and feel
Desarrollador principal de la aplicación
Sistema de software
Prototipo funcional validado
Validar prototipo funcional
Usuario embajador
Prepararse para hacer el trabajo
Forma de trabajo
Normas de la base de datos y directrices
Implementar normas base de datos y directrices
Desarrollador principal del sistema
Forma de trabajo
Normas de desarrollo de la aplicación y directrices
Implementar normas de desarrollo de la aplicación y directrices
Desarrollador principal de la aplicación
Forma de trabajo
Estrategia de conversión de datos
Definir estrategia de conversión de datos
Desarrollador
Forma de trabajo
Plan de trabajo de conversión de datos
Definir plan de trabajo de conversión de datos
Líder de equipo de conversión de datos
Forma de trabajo
Normas de documentación
Determinar las normas de la documentación
Escritor técnico
Forma de trabajo
Documentación de procedimientos y entorno
Crear documentación de procedimientos y entorno
Administrador del sistema
Tabla 25. (Parte 2/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
modelado de requisitos. Elaboración propia del autor.
54
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Estrategia de pruebas Desarrollar estrategia de pruebas
Tester principal
Coordinar actividades
Trabajo Entorno de desarrollo inicial
Crear entorno de desarrollo inicial
Gerente de configuración
Equipo Dotación de personal y plan de su organización
Establecer personal y plan de organización
Gerente de proyecto
Seguimiento del progreso
Forma de trabajo
Plan de gestión del alcance del proyecto
Recordar y revisar planes de proyecto
Gerente de proyecto
Forma de trabajo
Estrategias de control y presentación de informes, normas y procedimientos
Forma de trabajo
Trabajo de las estrategias de gestión, normas y procedimientos
Forma de trabajo
Plan de trabajo
Forma de trabajo, trabajo
Plan de financiación
Forma de trabajo
Las estrategias de gestión de los recursos, normas y procedimientos
Forma de trabajo
Guía de la orientación proyecto
Trabajo Organización preparada
Forma de trabajo
Plan de recursos físicos
Trabajo Infraestructura preparada
Forma de trabajo
Estrategias de gestión de la calidad, normas y procedimientos
Forma de trabajo
Gestión de la configuración las estrategias, normas y procedimientos
Trabajo Auditoría de calidad Realizar auditoría de calidad
Gerente de proyecto
Trabajo Lanzamiento de recursos físicos
Lanzar recursos físicos
Gerente de proyecto
Trabajo Reporte de calidad Realizar evaluación de calidad
Gerente de proyecto
Trabajo Línea base auditado Auditar entregables principales
Gerente de proyecto
Tabla 25. (Parte 3/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
modelado de requisitos. Elaboración propia del autor.
55
Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase del método CDM
Fast Track se visualizan en la Sección ANEXOS.
Fase: Diseño de sistema y generación
En la Tabla 26 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Asegurar la satisfacción de los interesados
Interesados Lista MoSCoW redefinida
Redefinir los requisitos Usuario embajador
Comprender los requisitos
Requisitos Lista MoSCoW redefinida
Redefinir los requisitos Usuario embajador
Darle forma al sistema
Requisitos Modelo de requisitos del negocio rested
Revisar modelo de requisitos
Desarrollador
Requisitos Definición de hardware y software
Desarrollar la definición de hardware y software
Desarrollador principal del sistema
Requisitos Arquitectura de distribución
Desarrollar arquitectura de distribución
Desarrollador principal del sistema
Requisitos
Esquema de autorización de objetos de base de datos
Crear esquema de autorización de objetos de base de datos
Desarrollador principal del sistema
Requisitos Diseño físico de la base
Crear diseño físico de la base
Desarrollador principal del sistema
Sistema de software
Ddl de la producción de la base de datos
Crear ddl de la producción de la base de datos
Desarrollador principal del sistema
Requisitos Módulos documentados
Desarrollar (grupo de) módulos
Desarrollador
Requisitos Diseño del módulo de conversión de datos
Diseñar módulos de conversión de datos
Desarrollador
Implementar el sistema
Sistema de software
Código de la aplicación
Estrenar aplicación Desarrollador principal de la aplicación
Requisitos Módulos de conversión
Codificar módulos de conversión
Desarrollador
Sistema de software
Materiales de referencia de usuario
Ensamblar materiales de referencia de usuario
Desarrollador
Sistema de software
Guía del usuario inicial
Producir guía del usuario inicial
Usuario embajador
Sistema de software
Materiales técnicos de referencia
Ensamblar materiales técnicos de referencia
Desarrollador
Tabla 26. (Parte 1/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
diseño de sistema y generación. Elaboración propia del autor.
56
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Implementar el sistema
Sistema de software
Guía de operaciones inicial del sistema
Producir guía de operaciones inicial del sistema
Desarrollador principal del sistema
Requisitos Pruebas de escenarios
Crear pruebas de escenarios
Tester principal
Requisitos Modelo de prueba de la arquitectura del sistema
Crear modelo de prueba de la arquitectura del sistema
Tester principal
Probar el sistema
Requisitos, sistema de software
Requisitos validados Validar requisitos Usuario embajador
Requisitos, sistema de software
Datos probados convertidos y verificados
Conversión inicial y la verificación de los datos
Líder de equipo de conversión de datos
Requisitos, sistema de software
Resultados de la prueba del módulo de conversión
Realizar prueba del módulo de conversión
Desarrollador
Requisitos, sistema de software
Resultados de las pruebas del sistema
Desarrollar pruebas del sistema
Tester principal
Requisitos, sistema de software
Resultados de la prueba de integración de sistemas
Realizar prueba de integración de sistemas
Desarrollador principal del sistema
Sistema de software
Listas de chequeo de prueba del módulo
Desarrollar listas de chequeo de prueba del módulo
Tester principal
Sistema de software
Secuencia de pruebas para la integración de sistemas
Desarrollar la secuencia de pruebas para la integración de sistemas
Desarrollador principal del sistema
Prepararse para hacer el trabajo
Forma de trabajo
Estrategia de reserva y recuperación
Desarrollar estrategia de reserva y recuperación
Desarrollador principal del sistema
Forma de trabajo
Estrategia de control y seguridad
Desarrollar de estrategia seguridad
Desarrollador principal del sistema
Forma de trabajo
Plan de capacidad Crear plan de capacidad
Desarrollador principal del sistema
Forma de trabajo
Estrategia de formación
Definir estrategia de formación
Usuario embajador
Forma de trabajo
Plan de formación Crear plan de formación
Usuario embajador
Forma de trabajo
Estrategia cut-over Definir estrategia cut-over
Gerente de proyecto
Forma de trabajo
Plan de integración Planear integración Tester principal
Tabla 26. (Parte 2/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
diseño de sistema y generación. Elaboración propia del autor.
57
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Coordinar actividades
Trabajo Entorno de desarrollo inicial
Crear entorno de desarrollo inicial
Gerente de configuración
Equipo Dotación de personal y plan de su organización
Establecer personal y organización plan
Gerente de proyecto
Seguimiento del progreso
Forma de trabajo
Plan de gestión del alcance del proyecto
Recordar y revisar planes de proyecto
Gerente de proyecto
Forma de trabajo
Estrategias de control y presentación de informes, normas y procedimientos
Forma de trabajo
Trabajo de las estrategias de gestión, normas y procedimientos
Forma de trabajo
Plan de trabajo
Forma de trabajo, trabajo
Plan de financiación
Forma de trabajo
Las estrategias de gestión de los recursos, normas y procedimientos
Forma de trabajo
Guía de la orientación proyecto
Trabajo Organización preparada
Forma de trabajo
Plan de recursos físicos
Trabajo Infraestructura preparada
Forma de trabajo
Estrategias de gestión de la calidad, normas y procedimientos
Forma de trabajo
Gestión de la configuración las estrategias, normas y procedimientos
Trabajo Auditoría de calidad Realizar auditoría de calidad
Gerente de proyecto
Trabajo Lanzamiento de recursos físicos
Lanzar recursos físicos Gerente de proyecto
Trabajo Reporte de calidad Realizar evaluación de calidad
Gerente de proyecto
Trabajo Línea base auditado Auditar entregables principales
Gerente de proyecto
Tabla 26. (Parte 3/3) Espacios de actividad, alfas, productos de trabajo y roles en la fase
diseño de sistema y generación. Elaboración propia del autor.
58
Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase del método CDM
Fast Track se visualizan en la sección ANEXOS.
Fase: Transición a la producción
En la tabla 27 se presentan los productos de trabajo, actividades y roles de esta fase asociados a
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad, interesados
Futuras mejoras funcionales
Determinar futuras mejoras funcionales
Usuario embajador
Oportunidad, interesados
Plan de mejoras Planear mejoras Usuario embajador
Utilizar el sistema
Interesados Usuarios entrenados Entrenar usuarios Entrenador
Interesados Administradores entrenados
Entrenar administradores
Entrenador
Interesados Equipo de validación entrenado
Entrenar equipo de validación
Entrenador
Interesados Entorno de mantenimiento del cliente
Establecer entorno de mantenimiento del cliente
Administrador del sistema
Implementar el sistema
Sistema de software
Referencia del usuario Completar referencia del usuario
Usuario embajador
Sistema de software
Guía de usuario Completar guía de usuario
Usuario embajador
Sistema de software
Referencia técnica detallada
Completar referencia técnica
Escritor técnico
Sistema de software
Guía operacional del sistema
Completar guía operacional del sistema
Desarrollador principal del sistema
Sistema de software
Texto de ayuda en línea
Generar texto de ayuda en línea
Desarrollador
Sistema de software
Materiales de formación
Crear materiales de formación
Usuario embajador
Sistema de software
Materiales de clase de usuario
Producir materiales de clase de usuario
Usuario embajador
Sistema de software
Sistema en producción
Comenzar la producción
Administrador del sistema
Sistema de software
Datos limpios Limpiar los datos Administrador de los datos del cliente
Sistema de software
Datos convertidos y verificados
Convertir y verificar los datos de producción
Líder de equipo de conversión de datos
Tabla 27. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición a la producción. Elaboración propia del autor.
59
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Probar el sistema
Requisitos, sistema de software
Resultados de la validación preproducción
Realizar validación preproducción
Coordinador de validación
Requisitos, sistema de software
Resultados de las pruebas de actualización
Probar actualización Tester principal
Sistema de software
Datos limpios Limpiar los datos Administrador de los datos del cliente
Sistema de software
Datos convertidos y verificados
Convertir y verificar los datos de producción
Líder de equipo de conversión de datos
Operar el sistema
Sistema de software
Sistema heredado apagado
Apagar sistema heredado
Administrador del sistema
Sistema de software
Evaluación del sistema
Auditar sistema Auditor interno
Sistema de software
Métricas de rendimiento
Especificar las métricas de rendimiento
Desarrollador
Sistema de software
Estadísticas del rendimiento
Medir el rendimiento del sistema
Administrador del sistema
Sistema de software
Excepciones de rendimiento
Acordar excepciones de rendimiento
Gerente de proyecto
Sistema de software
Correcciones fallidas Analizar los problemas Desarrollador
Sistema de software
Registro de problemas
Supervisar y responder a los problemas del sistema
Personal de soporte is
Sistema de software
Scripts actualizados y procedimiento
Actualizar scripts y procedimiento
Desarrollador
Sistema de software
Aplicación actualizada Realizar cambios en la aplicación
Desarrollador
Sistema de software
Aplicación del sistema actualizada
Actualización de la aplicación sistema
Desarrollador
Sistema de software
Correcciones de rendimiento
Analizar excepciones de rendimiento
Desarrollador
Prepararse para hacer el trabajo
Forma de trabajo
Entorno de formación Crear entorno de formación
Desarrollador dba
Forma de trabajo
Plan de instalación Desarrollar plan de instalación
Desarrollador
Forma de trabajo
Entorno de producción
Preparar entorno de producción
Productor dba
Forma de trabajo
Estrategia de actualización y plan
Preparar estrategia de actualización de la aplicación y plan
Gerente de proyecto
Coordinar actividades
Trabajo Resultados de la validación preproducción
Realizar validación preproducción
Coordinador de validación
Tabla 27. (Parte 2/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición a la producción. Elaboración propia del autor.
60
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Trabajo Resultados de la validación preproducción
Realizar validación preproducción
Coordinador de validación
Forma de trabajo
Plan de gestión del alcance del proyecto
Recordar y revisar planes de proyecto
Gerente de proyecto
Forma de trabajo
Estrategias de control y presentación de informes, normas y procedimientos
Forma de trabajo
Trabajo de las estrategias de gestión, normas y procedimientos
Forma de trabajo
Plan de trabajo
Forma de trabajo, trabajo
Plan de financiación
Forma de trabajo
Las estrategias de gestión de los recursos, normas y procedimientos
Forma de trabajo
Guía de la orientación proyecto
Trabajo Organización preparada
Forma de trabajo
Plan de recursos físicos
Trabajo Infraestructura preparada
Forma de trabajo
Estrategias de gestión de la calidad, normas y procedimientos
Forma de trabajo
Gestión de la configuración las estrategias, normas y procedimientos
Forma de trabajo
Plan de gestión del alcance del proyecto
Forma de trabajo
Estrategias de control y presentación de informes, normas y procedimientos
Finalizar proyecto
Trabajo Aceptación del cliente Aceptar seguridad del cliente del proyecto
Gerente de proyecto
Equipo Personal lanzado Lanzar personal Gerente de proyecto
Tabla 27. (Parte 3/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición a la producción. Elaboración propia del autor.
61
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Finalizar proyecto
Trabajo Aceptación del cliente Aceptar seguridad del cliente del proyecto
Gerente de proyecto
Equipo Personal lanzado Lanzar personal Gerente de proyecto
Trabajo Recursos físicos Lanzar recursos físicos Gerente de proyecto
Trabajo Reporte de calidad Realizar evaluación de la calidad
Gerente de proyecto
Trabajo Línea base auditada Auditar entregables clave
Gerente de proyecto
Trabajo Preparación de la gestión de produccción
Concluir configuración de gestión de la configuración
Gerente de proyecto
Tabla 27. (Parte 4/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición a la producción. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase del método CDM
Fast Track se visualizan en la sección ANEXOS.
El grupo de competencias asociadas con los roles existentes en el método CDM Fast Track se
visualizan en la Figura 29.
Figura 29. Competencias de los métodos CDM y PJM. Elaboración propia del autor.
El grupo de roles existentes en el método CDM se visualizan en la Figura 30.
Figura 30. Roles del método CDM y PJM. Elaboración propia del autor.
El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas, al aplicar el
método se encuentra que, de acuerdo con lo que Semat propone, en la Figura 31 se especifica los
estados que afectan la ejecución de actividades de los métodos CDM y PJM durante sus cuatro
fases.
62
Figura 31. Progreso de un proyecto al aplicar la metodología CDM Fast Track. Elaboración
propia del autor.
4.3 Representación gráfica del UNC-Method
Debido a que en la literatura no se especifican las prácticas del UNC-Method, se propone la
asociación con prácticas de la ingeniería de software ya existentes para su inclusión en el núcleo de
Semat. El conjunto de prácticas asociadas con las actividades y productos de trabajo de este método
se presentan en la Figura 32.
Figura 32. Prácticas del UNC-Method. Elaboración propia del autor.
63
Para llevar a cabo la representación de los elementos de este método, se presenta en la Tabla 28 la
descripción de algunos de los productos de trabajo que se definen en el método [8] [9] [26]:
Entregable Descripción
Esquema pre-conceptual Permite representar el modelo verbal del problema
Diagrama causa y efecto Permite realizar una estructura y jerarquización de los problemas que el interesado establece en el diálogo controlado
Diagrama de objetivos Permite identificar los objetivos gerenciales y específicos de una organización
Diagrama de procesos Permite visualizar cómo una organización satisface sus objetivos, ya que define las actividades de la organización y cómo se llevan a cabo
Tabla explicativa de procesos Clarifica la información que se encuentra modelada en el diagrama de procesos
Diagrama de casos de uso Permite modelar aspectos funcionales del sistema, para reconocer sus límites, los actores y las acciones que se realizan
Reglas del negocio Aspectos de la organización que afectan su comportamiento
Tarjetas de educción Información reunida en el diálogo controlado y organizada estructuralmente
Organigrama La jerarquía y las relaciones de los actores y las funciones dentro de la organización
Diccionario de datos Los almacenes y actores del diagrama de procesos
Esquema pre-conceptual basado en especificaciones
Especifica las operaciones, eventos, límites, derivaciones y consultas necesarias
Tabla 28. Descripción de entregables del UNC-Method. Elaboración propia del autor basado
en [10]
Fase: Contexto del software
En la Tabla 29 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Archivos digitales Desarrollar entrevista interesado-analista
Analista
Interesado
Director del proyecto
Oportunidad, Interesados
Dialogo controlado Desarrollar entrevista interesado-analista
Analista
Interesado
Director del proyecto
Oportunidad Dialogo controlado Revisar documentación Analista
Tabla 29. (Parte 1/2) Espacios de actividad, alfas, productos de trabajo, actividades y roles
de la fase análisis del problema. Elaboración propia del autor.
64
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender las necesidades de los interesados
Oportunidad Tarjetas de educción
Resumir la información relacionada con los actores, los objetos y las funciones
Analista
Oportunidad
Modelo del dominio, Organigrama, Tarjetas de educción
Verificar consistencia Analista
Interesados Organigrama Identificar los actores internos y externos en la organización
Analista
Oportunidad Modelo del dominio Establecer un vocabulario común
Analista
Comprender los requisitos
Requisitos Esquema pre-conceptual
Establecer un vocabulario común
Analista
Requisitos Esquemas pre-conceptuales ejecutables
Analista
Requisitos
Esquemas pre-conceptuales ejecutables, Esquemas pre-conceptuales ejecutables, Tabla de trazabilidad documental
Verificar consistencia Analista
Requisitos Tabla de trazabilidad documental
Estructurar información de la organización
Analista
Prepararse para hacer el trabajo
Forma de trabajo
Guía UNC-Method Explicar el método Director del proyecto
Trabajo Tablero Kanban Gestionar la elaboración de tareas
Analista
Trabajo Reporte de avance de los alfas
Reportar el progreso del proyecto
Analista
Equipo Lista de roles y responsabilidades
Definir roles y responsabilidades
Director del
proyecto
Coordinar actividades
Equipo Lista de roles y responsabilidades
Definir roles y responsabilidades
Director del
proyecto
Tabla 29. (Parte 2/2) Espacios de actividad, alfas, productos de trabajo, actividades y roles
de la fase análisis del problema. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la primera fase del UNC-Method
se visualizan en las Figuras 34-37 y la secuencia de actividades se muestra en la Figura 33.
65
Figura 33. Secuencia de
actividades en la fase
contexto del software
Figura 34. Representación gráfica de las prácticas Asignación de responsabilidades y Formación de personal. Elaboración propia del autor.
66
Figura 35. Representación gráfica de la práctica Modelado de objetos del dominio. Elaboración propia del autor.
67
Figura 36. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.
Figura 37. Representación gráfica de la práctica Monitoreo y control del proceso. Elaboración propia del autor.
68
Fase: Análisis del problema
En la Tabla 30 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender las necesidades de los interesados
Interesados Reglas del negocio Establecer limitaciones del proceso
Analista
Explorar posibilidades
Oportunidad Reglas del negocio Establecer limitaciones del proceso
Analista
Oportunidad Tabla explicativa del diagrama de procesos
Caracterizar el dominio del problema
Analista
Oportunidad Diagrama de procesos
Analista
Oportunidad Diagrama de objetivos
Analista
Oportunidad Diagrama de causa y efecto
Analista
Oportunidad
Diagrama de procesos, Diagrama de objetivos, Diagrama de causa y efecto, Tabla explicativa del diagrama de procesos
Verificar consistencia Analista
Comprender los requisitos
Requisitos Tabla explicativa del diagrama de procesos
Caracterizar el dominio del problema
Analista
Requisitos Diagrama de procesos
Analista
Requisitos Diccionario de datos
Desarrollar el diccionario de datos
Analista
Requisitos
Diagrama de procesos, Tabla explicativa del diagrama de procesos
Verificar consistencia Analista
Apoyar el equipo
Equipo, Forma de trabajo
Tablero Kanban Gestionar la elaboración de tareas
Analista
Equipo, Forma de trabajo
Reporte de avance de los alfas
Reportar el progreso del proyecto
Analista
Tabla 30. Espacios de actividad, alfas, productos de trabajo, actividades y roles de la fase
análisis del problema. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase del UNC-Method
se visualizan en la Sección ANEXOS.
69
Fase: propuestas de solución
En la Tabla 31 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Factores críticos de éxito
Establecer factores críticos de éxito
Analista
Comprender los requisitos
Requisitos Casos de uso Especificar la funcionalidad de la aplicación de software
Analista
Requisitos Diagrama de flujo de interfaz de usuario
Analista
Requisitos Organigrama Desarrollar nuevo organigrama
Analista
Requisitos Diagrama de procesos
Desarrollar nuevo diagrama de procesos
Analista
Requisitos
Diagrama de procesos, Organigrama, Casos de uso, Diagrama de flujo de interfaz de usuario
Verificar consistencia Analista
Darle forma al sistema
Sistema de software
Casos de uso Especificar la funcionalidad de la aplicación de software
Analista
Prepararse para hacer el trabajo
Trabajo Valoración de la propuesta Establecer el valor de la
solución
Analista
Trabajo Costeo de la propuesta
Analista
Coordinar actividades
Equipo, Forma de trabajo
Tablero Kanban Gestionar la elaboración de tareas
Analista
Equipo, Forma de trabajo
Reporte de avance de los alfas
Reportar el progreso del proyecto
Analista
Apoyar el equipo
Equipo, Forma de trabajo
Tablero Kanban Gestionar la elaboración de tareas
Analista
Equipo, Forma de trabajo
Reporte de avance de los alfas
Reportar el progreso del proyecto
Analista
Tabla 31. Espacios de actividad, alfas, productos de trabajo, actividades y roles de la fase
propuestas de solución. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase del UNC-Method
se visualizan en la Sección ANEXOS.
70
Fase: esquema conceptual
En la Tabla 32 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad, Interesados
Prototipo Alfa Desarrollar prototipo Alfa
Desarrollador
Comprender los requisitos
Requisitos
Especificaciones basados en el esquema pre-conceptual
Especificar la funcionalidad de la aplicación de software
Analista
Requisitos Diagrama de clases Analista
Requisitos Diagramas de comunicación
Analista
Requisitos Diagramas de máquina de estados
Analista
Requisitos
Especificaciones basados en el esquema pre-conceptual, Diagrama de clases, Diagramas de comunicación, Diagrama de máquina de estados
Verificar consistencia Analista
Darle forma al sistema
Requisitos Ejemplo de código fuente
Proporcionar las bases para la construcción de la aplicación final
Desarrollador
Requisitos Prototipo Alfa Desarrollar prototipo Alfa
Desarrollador
Coordinar actividades
Trabajo Tablero Kanban Gestionar la elaboración de tareas
Analista
Trabajo Reporte de avance de los alfas
Reportar el progreso del proyecto
Analista
Seguimiento del progreso
Trabajo Tablero Kanban Gestionar la elaboración de tareas
Analista
Tabla 32. Espacios de actividad, alfas, productos de trabajo, actividades y roles de la fase
esquema conceptual. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase del UNC-Method se
visualizan en la Sección ANEXOS.
71
El grupo de competencias asociadas con los roles existentes en el UNC-Method se visualizan en la
Figura 38.
Figura 38. Competencias del UNC-Method. Elaboración propia del autor.
El grupo de roles existentes en el UNC-Method se visualizan en la Figura 39.
Figura 39. Roles del UNC-Method. Elaboración propia del autor.
El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas. Al aplicar el
método se encuentra que, de acuerdo con lo que Semat propone, en la Figura 40 se especifican los
estados que afectan la ejecución de actividades del UNC-Method durante sus cuatro fases.
Figura 40. Progreso de un proyecto al aplicar el UNC-Method. Elaboración propia del autor.
72
4.4 Representación gráfica del método RUP
En la Figura 41 se representan seis mejores prácticas que se exponen en el método RUP. Cada
práctica se incluye en el núcleo de Semat y tiene un color asociado que depende del área de interés.
Figura 41. Mejores prácticas del método RUP. Elaboración propia del autor.
Para llevar a cabo esta representación se toma en consideración la descripción de productos de
trabajo, los cuales se definen en la Tabla 33.
Artefacto Descripción
Visión Contiene los requisitos del proyecto básicos, características clave y las limitaciones principales.
Lista de riesgos Riesgos del proyecto inicial identificados.
Plan de desarrollo de software
Especifica duración y objetivos, estimaciones de recursos (específicamente los de tiempo, personal y costos entorno de desarrollo)
Plan de iteración Plan para primera iteración.
Herramientas Todas las herramientas para apoyar el proyecto. Se instalan las herramientas necesarias para el trabajo en la primera fase.
Glosario Términos importantes definidos.
Modelo de casos de uso Actores importantes, casos de uso identificados y los flujos de eventos descritos sólo para los casos de uso más críticos.
Repositorio del proyecto El entorno de gestión de la configuración se debe establecer.
Prototipos Uno o más prototipos arquitectónicos ejecutables para explorar la funcionalidad crítica y escenarios de gran importancia.
Lista de riesgos actualizado y revisado
Nuevos riesgos relacionados principalmente con el manejo de los requisitos no funcionales.
Caso desarrollo refinada El entorno de desarrollo, los procesos, herramientas y soporte de automatización necesarios para apoyar el equipo de construcción.
Documento de arquitectura de software
Descripciones detalladas de los casos de uso arquitectónicamente significativos, la identificación de los mecanismos clave y elementos de diseño, la definición de la vista del proceso y de la vista de despliegue.
Modelo de diseño Las realizaciones de casos de uso para los escenarios de gran importancia arquitectónica y el comportamiento requerido asignado a los elementos de diseño apropiados.
Modelo de datos Elementos importantes como entidades, relaciones, tablas definidos y revisados.
Tabla 33. (Parte 1/2) Descripción de principales artefactos Elaboración propia del autor
basado en [16]
73
Artefacto Descripción
Modelo de implementación Creación de la estructura inicial y componentes principales identificados y prototipos.
Visión refinada Comprensión de los casos más críticos que impulsan las decisiones arquitectónicas y de planificación.
Especificaciones suplementarias de requisitos
Requisitos no funcionales documentados y revisados.
Test Suite Pruebas de implementación y ejecución para validar la estabilidad de la construcción.
Automatización de pruebas de arquitectura
Composición de diversos mecanismos y elementos de software clave que incorporan las características fundamentales del sistema de software.
El sistema El sistema mismo ejecutable, listo para comenzar las pruebas "beta".
Materiales de capacitación Manuales y otros materiales de capacitación. Anteproyecto, basado en casos de uso si el sistema tiene robusta interfaz de usuario.
Producto completo El producto final de acuerdo con los requisitos y que debe ser utilizable para el cliente.
Tabla 33. (Parte 2/2) Descripción de principales artefactos. Elaboración propia del autor
basado en [16]
Fase: Inicio
En la Tabla 34 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Visión Desarrollar visión Analista de sistemas
Oportunidad Lista de riesgos Identificar y evaluar los
riesgos Gerente de proyecto
Oportunidad Caso de negocio Desarrollar caso de
negocio Gerente de proyecto
Oportunidad, Interesados
Glosario de negocio Capturar un vocabulario
común de negocio Analista proceso-negocio
Oportunidad, Interesados
Reglas del negocio Mantener reglas de
negocio Analista proceso-negocio
Oportunidad, Interesados
Visión del negocio Establecer y ajustar
objetivos Analista proceso-negocio
Oportunidad, Interesados
Evaluación de la organización objetivo
Evaluar organización
objetivo Analista proceso-negocio
Oportunidad, Interesados
Modelo de objetos del negocio, Trabajadores del negocio, entidades del negocio, realización de casos de uso de negocio
Encontrar las entidades y
los trabajadores del
negocio
Diseñador de negocios
Tabla 34. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
74
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Plan de gestión de requisitos, atributos de requisitos, visión
Manejar dependencias Analista de software
Oportunidad, Interesados
Actores del negocio, modelo de caso de uso del negocio, especificación de negocio suplementaria, caso de uso de negocio
Encontrar los actores del
negocio y casos de uso Analista proceso-negocio
Oportunidad
Modelo de casos de uso de negocio, casos de uso de negocio
Estructurar el modelo de
caso de uso del negocio Analista proceso-negocio
Oportunidad, Interesados
Documento de arquitectura de negocios
Definir la arquitectura de
negocios Analista proceso-negocio
Oportunidad
Casos de uso del negocio, especificación de negocio suplementaria
Detallar caso de uso del
negocio Diseñador de negocio
Oportunidad Trabajadores de negocio, unidad de organización
Detallar un trabajador de
negocios Diseñador de negocio
Oportunidad Entidades de negocio, unidad de organización
Detallar una entidad de
negocio Diseñador de negocio
Comprender las necesidades de los interesados
Interesados Revisión de registros Revisar el modelo de caso de uso del negocio
Revisor del modelo de negocio
Interesados Revisión de registros Revisar el modelo de objetos del negocio
Revisor del modelo de negocio
Oportunidad Lista de riesgos, caso de negocio, visión
Evaluar viabilidad de la prueba de concepto arquitectónico
Arquitecto de software
Comprender los requisitos
Requisitos
Modelo de análisis, especificaciones suplementarias, modelo de casos de uso
Definir requisitos de automatización
Diseñador de negocio
Requisitos Glosario Capturar un vocabulario común
Analista de software
Requisitos
Casos de uso, actores, modelo de casos de uso, especificaciones suplementarias
Encontrar los actores y casos de uso
Analista de software
Tabla 34. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
75
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Casos de uso, especificaciones suplementarias
Detallar un
caso de uso
Especificador de requisitos
Requisitos Modelo de casos de uso
Obtener solicitudes de
los interesados Analista de software
Requisitos
Especificación de requisitos, especificaciones suplementarias
Detallar los requisitos del software
Especificador de requisitos
Requisitos Clase límite, actores, guión gráfico de casos de uso
Modelar la interfaz de usuario
Diseñador interfaz-usuario
Requisitos Modelo de caso de uso, caso de uso
Estructurar el modelo de caso de uso
Analista de sistemas
Requisitos
Realización de casos de uso, Modelo de despliegue, modelo de diseño
Analizar la arquitectura Arquitecto de software
Darle forma al sistema
Sistema de software
Documento de arquitectura de software, atributos de requisitos
Priorizar casos de uso Arquitecto de software
Sistema de software
Prototipo interfaz- usuario
Realizar prototipo de la interfaz de usuario
Diseñador interfaz-usuario
Sistema de software
Documento de arquitectura de software
Analizar la arquitectura Arquitecto de software
Sistema de software
Infraestructura para el desarrollo
Dar soporte de desarrollo Administrador del sistema
Implementar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Prototipo interfaz- usuario
Realizar prototipo de la interfaz de usuario
Diseñador interfaz-usuario
Probar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Prepararse para hacer el trabajo
Trabajo Revisión de registros Revisar el modelo de caso de uso del negocio
Revisor del modelo de negocio
Trabajo Revisión de registros Revisar el modelo de objetos del negocio
Revisor del modelo de negocio
Forma de trabajo
Plan de desarrollo de software, plan de iteración
Iniciar proyecto Gerente de proyecto
Tabla 34. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
76
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Trabajo Revisión de registros Revisar el modelo de caso de uso del negocio
Revisor del modelo de negocio
Forma de trabajo
Base de datos con las mediciones del proyecto, plan de medidas
Desarrollar plan de medición
Gerente de proyecto
Trabajo Revisión de registros Revisar el modelo de objetos del negocio
Revisor del modelo de negocio
Forma de trabajo
Plan de desarrollo de software, plan de iteración
Iniciar proyecto Gerente de proyecto
Forma de trabajo
Base de datos con las mediciones del proyecto, plan de medidas
Desarrollar plan de medición
Gerente de proyecto
Forma de trabajo
Plan de gestión de riesgos
Desarrollar plan de gestión de riesgos
Gerente de proyecto
Forma de trabajo
Plan de aceptación del producto
Desarrollar plan de aceptación del producto
Gerente de proyecto
Forma de trabajo
Plan de resolución de problemas
Desarrollar plan de resolución de problemas
Gerente de proyecto
Forma de trabajo
Plan de evaluación de calidad
Desarrollar plan de evaluación de calidad
Gerente de proyecto
Forma de trabajo
Plan de medidas, plan de desarrollo de software
Definir monitoreo y procesos de control
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Definir grupo de trabajo y organización del proyecto
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Planear fases e iteraciones
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Compilar plan de desarrollo de software
Gerente de proyecto
Trabajo Plan de iteración Desarrollar plan de iteración
Gerente de proyecto
Equipo Orden de trabajo Iniciar iteración Gerente de proyecto
Equipo Plan de desarrollo de software
Adquirir personal Gerente de proyecto
Forma de trabajo
Plan de gestión de requisitos
Desarrollar Plan de gestión de requisitos
Analista de sistemas
Forma de trabajo
Plan de gestión de requisitos, atributos de requisitos, visión
Manejar dependencias Analista de software
Forma de trabajo
Plan de pruebas Identificar motivadores de pruebas
Gerente de pruebas
Tabla 34. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
77
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Lista de ideas de pruebas
Identificar ideas de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Acordar misión Gerente de pruebas
Forma de trabajo
Plan de pruebas Identificar objetivos de Prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Definir evaluación y trazabilidad necesarias
Analista de pruebas
Forma de trabajo
Plan de pruebas, arquitectura de automatización de pruebas, especificación de interfaz de prueba, configuración del medio de pruebas, solicitud de cambios
Definir enfoque de
prueba Diseñador de pruebas
Forma de trabajo
Evaluación organización de desarrollo
Evaluar organización actual
Ingeniero de procesos
Forma de trabajo
Caso de desarrollo Desarrollar caso de desarrollo
Ingeniero de procesos
Forma de trabajo
Plan de gestión de configuración
Establecer políticas de gestión de configuración
Gerente de configuración
Forma de trabajo
Plan de gestión de configuración
Escribir plan de gestión de configuración
Gerente de configuración
Forma de trabajo
Plan de gestión de configuración
Establecer proceso de cambio de control
Gerente de control de cambios
Coordinar actividades
Equipo
Orden de trabajo, plan de desarrollo de software, plan de iteración
Programar y asignar el Trabajo
Gerente de proyecto
Equipo Solicitud de cambio, orden de trabajo, lista de problemas
Manejar excepciones y Problemas
Gerente de proyecto
Apoyar el equipo
Forma de trabajo
Solicitud de cambio Lanzar caso desarrollo Ingeniero de procesos
Forma de trabajo
Solicitud de cambio
Verificar de la configuración de herramientas e instalación
Especialista de herramientas
Forma de trabajo
Solicitud de cambio Presentar solicitud de cambio
Cualquier rol
Forma de trabajo
Solicitud de cambio Actualizar solicitud de cambio
Cualquier rol
Seguimiento del progreso
Trabajo Revisión de registros Revisar aprobación de proyectos
Revisor del proyecto
Tabla 34. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
78
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Trabajo Solicitud de cambio, evaluación de o iteración
Evaluar iteración Gerente de proyecto
Trabajo Revisión de registros Revisar planeación del proyecto
Revisor del proyecto
Trabajo Revisión de registros Revisar el plan de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar criterio de evaluación de la iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar aceptación de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto
Trabajo
Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas
Monitorear estado de proyecto
Gerente de proyecto
Trabajo Revisión de registros Revisar requisitos Revisor de requisitos
Forma de trabajo
Solicitud de cambio Confirmar solicitud de cambio duplicado o rechazado
Gerente de control de cambios
Forma de trabajo
Solicitud de cambio Revisar solicitud de cambio
Gerente de control de cambios
Forma de trabajo
Base de datos de medidas del proyecto
Informar sobre estado de
configuración
Gerente de configuración
Trabajo Resultados de auditoría de configuración
Realizar auditoría de
configuración
Gerente de configuración
Tabla 34. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
inicio. Elaboración propia del autor.
79
Figura 42. Secuencia de actividades en la fase inicio. Elaboración propia del autor.
80
81
82
83
84
85
Figura 43. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.
86
87
88
89
Figura 44. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.
90
91
92
93
94
95
96
97
Figura 45. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.
98
Fase: Elaboración
En la Tabla 35 se presentan los productos de trabajo, actividades y roles de esta fase asociados con
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Lista de riesgos Identificar y evaluar los riesgos
Gerente de proyecto
Oportunidad Caso de negocio Desarrollar caso de negocio
Gerente de proyecto
Oportunidad Visión Desarrollar visión Analista de sistemas
Oportunidad Plan de gestión de requisitos, atributos de requisitos, visión
Manejar dependencias Analista de software
Comprender los requisitos
Requisitos Glosario Capturar un vocabulario común
Analista de software
Requisitos
Casos de uso, actores, modelo de casos de uso, especificaciones suplementarias
Encontrar los actores y casos de uso
Analista de software
Requisitos Modelo de casos de uso, solicitud del interesado
Obtener solicitudes de los interesados
Analista de software
Requisitos
Casos de uso, atributos de requisitos, especificaciones suplementarias
Detallar un caso de uso
Especificador de requisitos
Requisitos
Especificación de requisitos, especificaciones suplementarias, atributos de requisitos
Detallar los requisitos del software
Especificador de requisitos
Requisitos Clase límite, actores, guión gráfico de casos de uso
Modelar la interfaz de usuario
Diseñador interfaz-usuario
Requisitos Modelo de caso de uso, caso de uso
Estructurar el modelo de caso de uso
Analista de sistemas
Requisitos
Realización de casos de uso, Modelo de despliegue, modelo de diseño
Analizar la arquitectura Arquitecto de software
Requisitos
Modelo de diseño, modelo de análisis, realización de casos de uso
Analizar casos de uso Diseñador
Requisitos
Capsula, interfaz, modelo de diseño, protocolo, clase de diseño
Identificar elementos de diseño
Arquitecto de software
Tabla 35. (Parte 1/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
99
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Realización de casos de uso
Diseñar de caso de uso Diseñador
Requisitos Cápsula, protocolo Diseñar cápsula Diseñador de cápsula
Requisitos Clase diseñada Diseñar de clase Diseñador
Requisitos Paquete de diseño Diseñar de subsistema Diseñador
Requisitos Realización de casos de uso, capsula, clase diseño, interfaz
Diseñar clase de pruebas y paquetes
Diseñador
Requisitos Modelo de datos Diseñar base de datos Diseñador de base de datos
Darle forma al sistema
Sistema de software
Documento de arquitectura de software, atributos de requisitos
Priorizar casos de uso Arquitecto de software
Sistema de software
Prototipo interfaz- ususario
Realizar prototipo de la interfaz de usuario
Diseñador interfaz-usuario
Sistema de software
Infraestructura para el desarrollo
Dar soporte de desarrollo
Administrador del sistema
Sistema de software
Documento de arquitectura de software
Analizar la arquitectura Arquitecto de software
Sistema de software
Modelo de datos Diseñar base de datos Diseñador de base de datos
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Identificar mecanismos de diseño
Arquitecto de software
Sistema de software
Capsula, interfaz, clase diseñada, modelo diseñado
Identificar elementos de diseño
Arquitecto de software
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Incorporar elementos de diseño existente
Arquitecto de software
Sistema de software
Documento de arquitectura de software
Describir arquitectura tiempo real
Arquitecto de software
Sistema de software
Documento de arquitectura de software, modelo de despliegue
Describir distribución Arquitecto de software
Tabla 35. (Parte 2/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
100
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Implementar el sistema
Sistema de software
Modelo de implementación, documento de arquitectura de software
Estructurar el modelo de implementación
Arquitecto de software
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Componente, componente de prueba
Implementar componente
Implementador
Sistema de software
Componente Fijar un defecto Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Implementar componente de pruebas y subsistema
Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Realizar pruebas unitarias
Implementador
Sistema de software
Construcción, subsistema de implementación
Integrar subsistema Integrador
Sistema de software
Construcción Integrar sistema Integrador
Probar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Registro de cambios, plan de prueba, configuración de ambiente de pruebas
Definir configuraciones de ambiente de pruebas
Diseñador de pruebas
Sistema de software
Registro de cambios, especificación de interfaz de prueba
Identificar mecanismos de pruebas
Diseñador de pruebas
Sistema de software
Registro de cambios, especificación de interfaz de prueba, componente de pruebas, configuración de ambiente de pruebas
Definir elementos de pruebas
Diseñador de pruebas
Sistema de software
Caso de prueba Definir detalles de pruebas
Analista de pruebas
Sistema de software
Registro de cambios, configuración de ambiente de pruebas, Pruebas de script, test suite
Implementar prueba Suite
Tester
Sistema de software
Registro de cambios, test script
Implementar pruebas Tester
Sistema de software
Configuración de ambiente de pruebas, test log
Ejecutar pruebas Suite Tester
Tabla 35. (Parte3/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
101
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Probar el sistema
Sistema de software
Configuración de ambiente de pruebas, test script, test suite
Estructurar la implementación de pruebas
Diseñador de pruebas
Sistema de software
Registro de cambios, configuración de ambiente de pruebas, test script, test suite
Analizar fallos de pruebas
Tester
Sistema de software
Lista de idas de prueba Identificar ideas de pruebas
Analista de pruebas
Prepararse para hacer el trabajo
Equipo Orden de trabajo Iniciar iteración Gerente de proyecto
Equipo Plan de desarrollo de software
Adquirir personal Gerente de proyecto
Trabajo Plan de iteración Desarrollar plan de iteración
Gerente de proyecto
Forma de trabajo
Base de datos con las mediciones del proyecto, plan de medidas
Desarrollar plan de Medición
Gerente de proyecto
Forma de trabajo
Plan de gestión de riesgos
Desarrollar plan de gestión de riesgos
Gerente de proyecto
Forma de trabajo
Plan de aceptación del producto
Desarrollar plan de aceptación del producto
Gerente de proyecto
Forma de trabajo
Plan de resolución de problemas
Desarrollar plan de resolución de problemas
Gerente de proyecto
Forma de trabajo
Plan de evaluación de calidad
Desarrollar plan de evaluación de calidad
Gerente de proyecto
Forma de trabajo
Plan de medidas, plan de desarrollo de software
Definir monitoreo y procesos de control
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Definir grupo de trabajo y organización del proyecto
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Planear fases e iteraciones
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Compilar plan de desarrollo de software
Gerente de proyecto
Forma de trabajo
Plan de gestión de requisitos
Desarrollar plan de gestión de requisitos
Analista de sistemas
Forma de trabajo
Plan de gestión de requisitos, atributos de requisitos, visión
Manejar dependencias Analista de software
Forma de trabajo
Plan de pruebas Identificar motivadores de pruebas
Gerente de pruebas
Tabla 35. (Parte 4/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
102
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Plan de pruebas, arquitectura de automatización de pruebas, especificación de interfaz de prueba, configuración del medio de pruebas, solicitud de cambios
Definir enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Plan de pruebas Identificar objetivos de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Acordar misión Gerente de pruebas
Forma de trabajo
Plan de pruebas Definir evaluación y trazabilidad necesarias
Analista de pruebas
Forma de trabajo
Lista de ideas de pruebas
Identificar ideas de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Definir enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Caso de desarrollo Desarrollar caso de desarrollo
Ingeniero de procesos
Forma de trabajo
Modelo de datos Diseñar base de datos Diseñador de base de datos
Forma de trabajo
Plan de construcción integrada
Planear la integración Integrador
Forma de trabajo
Plan de construcción integrada
Planear integración de subsistema
Integrador
Coordinar actividades
Equipo
Orden de trabajo, plan de desarrollo de software, plan de iteración
Programar y asignar el trabajo
Gerente de proyecto
Equipo Solicitud de cambio, orden de trabajo, lista de problemas
Manejar excepciones y problemas
Gerente de proyecto
Apoyar el equipo
Forma de trabajo
Solicitud de cambio Lanzar caso desarrollo Ingeniero de procesos
Forma de trabajo
Solicitud de cambio Verificar de la configu-ración de herramientas e instalación
Especialista de herramientas
Forma de trabajo
Solicitud de cambio Presentar solicitud de cambio
Cualquier rol
Forma de trabajo
Solicitud de cambio Actualizar solicitud de cambio
Cualquier rol
Seguimiento del progreso
Trabajo Solicitud de cambio, e-valuación de o iteración
Evaluar iteración Gerente de proyecto
Trabajo Evaluación de estado Reportar estado Gerente de proyecto
Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto
Trabajo Revisión de registros Revisar requisitos Revisor de requisitos
Tabla 35. (Parte 5/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
103
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Trabajo Solicitud de cambio, evaluación de o iteración
Evaluar iteración Gerente de proyecto
Trabajo
Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas
Monitorear estado de proyecto
Gerente de proyecto
Trabajo Revisión de registros Revisar el plan de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar planeación del proyecto
Revisor del proyecto
Forma de trabajo
Base de datos de medidas del proyecto
Informar sobre estado de configuración
Gerente de configuración
Trabajo Evaluación de estado Reportar estado Gerente de proyecto
Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto
Trabajo Revisión de registros Revisar requisitos Revisor de requisitos
Trabajo
Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas
Monitorear estado de proyecto
Gerente de proyecto
Trabajo Revisión de registros Revisar el plan de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar planeación del proyecto
Revisor del proyecto
Forma de trabajo
Base de datos de medidas del proyecto
Informar sobre estado
de configuración Gerente de configuración
Trabajo Resultados de auditoría de configuración
Realizar auditoría de
Configuración
Gerente de configuración
Forma de trabajo
Solicitud de cambio Confirmar solicitud de cambio duplicado o rechazado
Gerente de control de cambios
Forma de trabajo
Solicitud de cambio Revisar solicitud de
cambio
Gerente de control de cambios
Forma de trabajo, trabajo
Solicitud de cambio, revisión de registros
Revisar el diseño Revisor de diseño
Forma de trabajo, trabajo
Solicitud de cambio, revisión de registros
Revisar la arquitectura Revisor de arquitectura
Trabajo Revisión de registros Revisar código Revisor de código
Forma de trabajo
Solicitud de cambios, lista de problemas, plan de pruebas
Obtener comentarios
de pruebas Gerente de pruebas
Tabla 35. (Parte 6/7)Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
104
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Forma de trabajo
Solicitud de cambios, lista de problemas, plan de pruebas
Obtener comentarios de pruebas
Gerente de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Verificar cambios en
construcción Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Determinar resultados
de pruebas Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar esfuerzo de
pruebas Gerente de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar calidad Gerente de pruebas
Tabla 35. (Parte 7/7)Espacios de actividad, alfas, productos de trabajo y roles en la fase
elaboración. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase de RUP se
visualizan en la sección ANEXOS.
Fase: Construcción
En la tabla 36 se presentan los productos de trabajo, actividades y roles de esta fase asociados a
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Lista de riesgos Identificar y evaluar los riesgos
Gerente de proyecto
Oportunidad Caso de negocio Desarrollar caso de negocio
Gerente de proyecto
Comprender los requisitos
Requisitos Modelo de caso de uso, caso de uso
Estructurar el modelo de caso de uso
Analista de sistemas
Requisitos Cápsula, protocolo Diseñar cápsula Diseñador de cápsula
Requisitos Realización de casos de uso
Diseñar caso de uso Diseñador
Requisitos Clase diseño Diseñar clase Diseñador
Requisitos Paquete de diseño Diseñar subsistema Diseñador
Requisitos Modelo de datos Diseñar base de datos Diseñador de base de datos
Tabla 36. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
105
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Realización de casos de uso, capsula, clase diseño, interfaz
Diseñar clase de pruebas y paquetes
Diseñador
Darle forma al sistema
Sistema de software
Infraestructura para el desarrollo
Dar soporte de desarrollo
Administrador del sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Modelo de datos Diseñar base de datos Diseñador de base de datos
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Identificar mecanismos de diseño
Arquitecto de software
Sistema de software
Capsula, interfaz, clase diseñada, modelo diseñado
Identificar elementos de diseño
Arquitecto de software
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Incorporar elementos de diseño existente
Arquitecto de software
Sistema de software
Documento de arquitectura de software
Describir arquitectura tiempo real
Arquitecto de software
Sistema de software
Documento de arquitectura de software, modelo de despliegue
Describir distribución Arquitecto de software
Implementar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Componente, componente de prueba
Implementar componente
Implementador
Sistema de software
Componente Fijar un defecto Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Implementar componente de pruebas y subsistema
Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Realizar pruebas unitarias
Implementador
Tabla 36. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
106
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Implementar el sistema
Sistema de software
Construcción Integrar sistema Integrador
Sistema de software
Construcción, subsistema de implementación
Integrar subsistema Integrador
Probar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Registro de cambios, plan de prueba, configuración de ambiente de pruebas
Definir configuraciones de ambiente de pruebas
Diseñador de pruebas
Sistema de software
Registro de cambios, especificación de interfaz de prueba
Identificar mecanismos de pruebas
Diseñador de pruebas
Sistema de software
Registro de cambios, especificación de interfaz de prueba, componente de pruebas, configuración de ambiente de pruebas
Definir elementos de pruebas
Diseñador de pruebas
Sistema de software
Caso de prueba Definir detalles de pruebas
Analista de pruebas
Sistema de software
Registro de cambios, configuración de ambiente de pruebas, Pruebas de script, test suite
Implementar prueba Suite
Tester
Sistema de software
Registro de cambios, test script
Implementar pruebas Tester
Sistema de software
Configuración de ambiente de pruebas, test log
Ejecutar pruebas Suite Tester
Sistema de software
Registro de cambios, configuración de ambiente de pruebas, test script, test suite
Analizar fallos de pruebas
Tester
Sistema de software
Configuración de ambiente de pruebas, test script, test suite
Estructurar la implementación de pruebas
Diseñador de pruebas
Sistema de software
Lista de idas de prueba
Identificar ideas de pruebas
Analista de pruebas
Prepararse para hacer el trabajo
Equipo Orden de trabajo Iniciar iteración Gerente de proyecto
Equipo Plan de desarrollo de software
Adquirir personal Gerente de proyecto
Trabajo Plan de iteración Desarrollar plan de iteración
Gerente de proyecto
Tabla 36. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
107
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Plan de medidas, plan de desarrollo de software
Definir monitoreo y procesos de control
Gerente de proyecto
Forma de trabajo
Plan de gestión de riesgos
Desarrollar plan de gestión de riesgos
Gerente de proyecto
Forma de trabajo
Plan de aceptación del producto
Desarrollar plan de aceptación del producto
Gerente de proyecto
Forma de trabajo
Plan de resolución de problemas
Desarrollar plan de resolución de problemas
Gerente de proyecto
Forma de trabajo
Plan de evaluación de calidad
Desarrollar plan de evaluación de calidad
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Definir grupo de trabajo y organización del proyecto
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Planear fases e iteraciones
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Compilar plan de desarrollo de software
Gerente de proyecto
Forma de trabajo
Plan de pruebas Identificar motivadores de pruebas
Gerente de pruebas
Forma de trabajo
Plan de pruebas Identificar objetivos de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Acordar misión Gerente de pruebas
Forma de trabajo
Plan de pruebas Definir evaluación y trazabilidad necesarias
Analista de pruebas
Forma de trabajo
Lista de ideas de pruebas
Identificar ideas de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Definir enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Plan de pruebas, arquitectura de automatización de pruebas, especificación de interfaz de prueba, configuración del medio de pruebas, solicitud de cambios
Definir enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Caso de desarrollo Desarrollar caso de desarrollo
Ingeniero de procesos
Forma de trabajo
Base de datos con las mediciones del proyecto, plan de medidas
Desarrollar plan de medición
Gerente de proyecto
Forma de trabajo
Solicitud de cambio Diseñar base de datos Diseñador de base de datos
Tabla 36. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
108
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Plan de construcción integrada
Planear integración de subsistema
Integrador
Coordinar actividades
Equipo Solicitud de cambio, orden de trabajo, lista de problemas
Manejar excepciones y problemas
Gerente de proyecto
Forma de trabajo
Solicitud de cambio
Verificar la configuración de herramientas e instalación
Gerente de control de cambios
Apoyar al equipo
Forma de trabajo
Solicitud de cambio Actualizar solicitud de cambio
Cualquier rol
Forma de trabajo
Solicitud de cambio Lanzar caso de desarrollo
Ingeniero de procesos
Forma de trabajo
Solicitud de cambio Presentar solicitud de cambio
Cualquier rol
Seguimiento del progreso
Trabajo Revisión de registros Revisar criterio de evaluación de la iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar aceptación de iteración
Revisor del proyecto
Trabajo Solicitud de cambio, evaluación de o iteración
Evaluar iteración Gerente de proyecto
Trabajo Evaluación de estado Reportar estado Gerente de proyecto
Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto
Trabajo
Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas
Monitorear estado de proyecto
Gerente de proyecto
Trabajo Revisión de registros Revisar el plan de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar planeación del proyecto
Revisor del proyecto
Trabajo Revisión de registros Revisar requisitos Revisor de requisitos
Forma de trabajo
Solicitud de cambio Confirmar solicitud de cambio duplicado o rechazado
Gerente de control de cambios
Forma de trabajo
Solicitud de cambio Revisar solicitud de
cambio
Gerente de control de cambios
Forma de trabajo
Base de datos de medidas del proyecto
Informar sobre estado
de configuración Gerente de configuración
Trabajo Resultados de auditoría de configuración
Realizar auditoría de
configuración
Gerente de configuración
Tabla 36. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
109
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Forma de trabajo
Solicitud de cambios, lista de problemas, plan de pruebas
Obtener comentarios de pruebas
Gerente de pruebas
Forma de trabajo, trabajo
Solicitud de cambio, revisión de registros
Revisar el diseño Revisor de diseño
Forma de trabajo, trabajo
Solicitud de cambio, revisión de registros
Revisar la arquitectura Revisor de arquitectura
Trabajo Revisión de registros Revisar código Revisor de código
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Verificar cambios en
construcción Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Determinar resultados
de pruebas Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar esfuerzo de
pruebas Gerente de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar calidad Gerente de pruebas
Tabla 36. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
construcción. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase de RUP se
visualizan en la sección ANEXOS.
Fase: Transición
En la Tabla 37 se presentan los productos de trabajo, actividades y roles de esta fase asociados a
los alfas y espacios de actividad que Semat propone.
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Explorar posibilidades
Oportunidad Lista de riesgos Identificar y evaluar los riesgos
Gerente de proyecto
Oportunidad Caso de negocio Desarrollar caso de negocio
Gerente de proyecto
Tabla 37. (Parte 1/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
110
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Modelo de caso de uso, caso de uso
Estructurar el Modelo de caso de uso
Analista de sistemas
Darle forma al sistema
Sistema de software
Infraestructura para el desarrollo
Dar soporte de desarrollo
Administrador del sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Identificar mecanismos de diseño
Arquitecto de software
Sistema de software
Capsula, interfaz, clase diseñada, modelo diseñado
Identificar elementos de diseño
Arquitecto de software
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Incorporar elementos de diseño existente
Arquitecto de software
Sistema de software
Documento de arquitectura de software
Describir arquitectura tiempo real
Arquitecto de software
Sistema de software
Documento de arquitectura de software, modelo de despliegue
Describir distribución Arquitecto de software
Implementar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Componente, componente de prueba
Implementar componente
Implementador
Sistema de software
Componente Fijar un defecto Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Implementar componente de pruebas y subsistema
Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Realizar pruebas unitarias
Implementador
Sistema de software
Construcción, subsistema de implementación
Integrar subsistema Integrador
Tabla 37. (Parte 2/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
111
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Comprender los requisitos
Requisitos Modelo de caso de uso, caso de uso
Estructurar el Modelo de caso de uso
Analista de sistemas
Darle forma al sistema
Sistema de software
Infraestructura para el desarrollo
Dar soporte de desarrollo
Administrador del sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Identificar mecanismos de diseño
Arquitecto de software
Sistema de software
Capsula, interfaz, clase diseñada, modelo diseñado
Identificar elementos de diseño
Arquitecto de software
Sistema de software
Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software
Incorporar elementos de diseño existente
Arquitecto de software
Sistema de software
Documento de arquitectura de software
Describir arquitectura tiempo real
Arquitecto de software
Sistema de software
Documento de arquitectura de software, modelo de despliegue
Describir distribución Arquitecto de software
Implementar el sistema
Sistema de software
Unidad de desarrollo Crear unidad de desarrollo
Gerente de configuración
Sistema de software
Componente, componente de prueba
Implementar componente
Implementador
Sistema de software
Componente Fijar un defecto Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Implementar componente de pruebas y subsistema
Implementador
Sistema de software
Componente, componente de prueba, resultados de prueba
Realizar pruebas unitarias
Implementador
Sistema de software
Construcción, subsistema de implementación
Integrar subsistema Integrador
Sistema de software
Construcción Integrar sistema Integrador
Tabla 37. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
112
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Probar el sistema
Sistema de software
Configuración de ambiente de pruebas, test log
Ejecutar pruebas Suite Tester
Sistema de software
Registro de cambios, configuración de ambiente de pruebas, test script, test suite
Analizar fallos de pruebas
Tester
Sistema de software
Configuración de ambiente de pruebas, test script, test suite
Estructurar la implementación de pruebas
Diseñador de pruebas
Sistema de software
Lista de idas de prueba
Identificar ideas de pruebas
Analista de pruebas
Desplegar el sistema
Sistema de software
Artefactos de instalación
Desplegar los artefactos de instalación
Implementador
Sistema de software
Producto Lanzar versión solo de fabricantes
Gerente de despliegue
Sistema de software
Estilos gráficos del producto
Crear estilos gráficos del producto
Artista gráfico
Operar el sistema
Sistema de software
Lista de materiales Definir lista de materiales
Gerente de despliegue
Sistema de software
Material de entrenamiento
Desarrollar material de entrenamiento
Desarrollador de curso
Sistema de software
Material de soporte para el usuario final
Desarrollar material de soporte
Escritor técnico
Sistema de software
Notas Escribir notas Gerente de despliegue
Sistema de software
Producto Verificar el producto manufacturado
Gerente de despliegue
Prepararse para hacer el trabajo
Equipo Orden de trabajo Iniciar iteración Gerente de proyecto
Equipo Plan de desarrollo de software
Adquirir personal Gerente de proyecto
Trabajo Plan de iteración Desarrollar plan de iteración
Gerente de proyecto
Forma de trabajo
Plan de gestión de riesgos
Desarrollar plan de gestión de riesgos
Gerente de proyecto
Forma de trabajo
Plan de aceptación del producto
Desarrollar plan de aceptación del producto
Gerente de proyecto
Forma de trabajo
Plan de resolución de problemas
Desarrollar plan de resolución de problemas
Gerente de proyecto
Forma de trabajo
Plan de evaluación de calidad
Desarrollar plan de evaluación de calidad
Gerente de proyecto
Forma de trabajo
Plan de medidas, plan de desarrollo de software
Definir monitoreo y procesos de control
Gerente de proyecto
Tabla 37. (Parte 3/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
113
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Prepararse para hacer el trabajo
Forma de trabajo
Plan de desarrollo de software
Definir grupo de trabajo y organización del proyecto
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Planear fases e iteraciones
Gerente de proyecto
Forma de trabajo
Plan de desarrollo de software
Compilar plan de desarrollo de software
Gerente de proyecto
Forma de trabajo
Plan de pruebas Identificar motivadores de pruebas
Gerente de pruebas
Forma de trabajo
Plan de pruebas Identificar objetivos de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Acordar misión Gerente de pruebas
Forma de trabajo
Plan de pruebas Definir evaluación y trazabilidad necesarias
Analista de pruebas
Forma de trabajo
Lista de ideas de pruebas
Identificar ideas de prueba
Analista de pruebas
Forma de trabajo
Plan de pruebas Definir Enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Plan de pruebas, arquitectura de automatización de pruebas, especificación de interfaz de prueba, configuración del medio de pruebas, solicitud de cambios
Definir Enfoque de prueba
Diseñador de pruebas
Forma de trabajo
Caso de desarrollo Desarrollar caso de desarrollo
Ingeniero de procesos
Forma de trabajo
Base de datos con las mediciones del proyecto, plan de medidas
Desarrollar plan de Medición
Gerente de proyecto
Forma de trabajo
Plan de construcción integrada
Planear integración de subsistema
Integrador
Forma de trabajo
Plan de despliegue Desarrollar plan de despliegue
Gerente de despliegue
Coordinar actividades
Forma de trabajo
Solicitud de cambio
Verificar de la configuración de herramientas e instalación
Especialista de herramientas
Equipo Solicitud de cambio, orden de trabajo, lista de problemas
Manejar excepciones y problemas
Gerente de proyecto
Apoyar al equipo
Forma de trabajo
Solicitud de cambio Lanzar caso de desarrollo
Ingeniero de procesos
Tabla 37. (Parte 4/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
114
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Apoyar al equipo
Forma de trabajo
Solicitud de cambio Actualizar solicitud de cambio
Cualquier rol
Forma de trabajo
Solicitud de cambio Presentar solicitud de cambio
Cualquier rol
Seguimiento del progreso
Trabajo Revisión de registros Revisar criterio de evaluación de la iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar aceptación de iteración
Revisor del proyecto
Trabajo Solicitud de cambio, evaluación de o iteración
Evaluar iteración Gerente de proyecto
Trabajo Evaluación de estado Reportar estado Gerente de proyecto
Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto
Trabajo
Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas
Monitorear estado de proyecto
Gerente de proyecto
Trabajo Revisión de registros Revisar el plan de iteración
Revisor del proyecto
Trabajo Revisión de registros Revisar planeación del proyecto
Revisor del proyecto
Trabajo Revisión de registros Revisar requisitos Revisor de requisitos
Forma de trabajo
Solicitud de cambio Confirmar solicitud de cambio duplicado o rechazado
Gerente de control de cambios
Forma de trabajo
Solicitud de cambio Revisar solicitud de
cambio
Gerente de control de cambios
Forma de trabajo
Base de datos de medidas del proyecto
Informar sobre estado
de configuración Gerente de configuración
Trabajo Resultados de auditoría de configuración
Realizar auditoría de
configuración Gerente de configuración
Forma de trabajo, trabajo
Solicitud de cambio, revisión de registros
Revisar la arquitectura Revisor de arquitectura
Trabajo Revisión de registros Revisar código Revisor de código
Forma de trabajo
Solicitud de cambio Gestionar las pruebas
de aceptabilidad Gerente de despliegue
Forma de trabajo
Solicitud de cambios, lista de problemas, plan de pruebas
Obtener comentarios
de pruebas Gerente de pruebas
Tabla 37. (Parte 5/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
115
Espacio de actividad
Alfa Producto de trabajo Actividad Rol
Seguimiento del progreso
Forma de trabajo
Solicitud de cambios, lista de problemas, plan de pruebas
Obtener comentarios de pruebas
Gerente de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Verificar cambios en
construcción Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba
Determinar resultados
de pruebas Analista de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar esfuerzo de
pruebas Gerente de pruebas
Forma de trabajo, trabajo
Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas
Evaluar calidad Gerente de pruebas
Finalizar proyecto
Trabajo Revisión de registros Revisar aceptación de
proyecto Revisor de proyecto
Trabajo, Forma de trabajo
Evaluación de estados, lista de problemas, plan de desarrollo de software
Preparar el cierre del
proyecto Gerente de proyecto
Tabla 37. (Parte 6/6) Espacios de actividad, alfas, productos de trabajo y roles en la fase
transición. Elaboración propia del autor.
Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase de RUP se visualizan
en la sección ANEXOS.
En RUP se exponen algunas directrices que en Semat se consideran recursos, este grupo se
visualiza en la Figura 46.
Figura 46. Recursos del método RUP. Elaboración propia del autor.
116
El grupo de competencias asociadas a los roles existentes en el método RUP se visualizan en la
Figura 47.
Figura 47. Competencias del método RUP. Elaboración propia del autor.
El grupo de roles existentes en la metodología RUP se visualizan en la Figura 48.
Figura 48. Roles del método RUP. Elaboración propia del autor.
El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas, al aplicar la
metodología se encuentra que de acuerdo a lo que Semat propone, en la Figura 49 se especifica los
estados que afectan la ejecución de actividades de RUP durante sus cuatro fases.
117
Figura 49. Progreso de un proyecto al aplicar la metodología RUP. Elaboración
propia del autor.
5 VALIDACIÓN
5.1 Validación del método CDM
En la literatura no se encontraron proyectos donde se aplica este método de desarrollo. Para realizar
la validación del método CDM Fast Track, se realiza un análisis de sus prácticas, haciendo una
comparación con los otros dos métodos representados en el núcleo de Semat en esta Tesis (véase
la Tabla 38).
PRÁCTICAS CDM UNC-METHOD RUP
Modelado de objetos de dominio X X X
Gestión de requisitos X X
Verificación continua de la calidad X X X
Modelado visual X X
Control de cambios de software X
Desarrollo basado en componentes X X
Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method.
Elaboración propia del autor.
118
PRÁCTICAS CDM UNC-METHOD RUP
Establecimiento de actividades para satisfacer las prácticas de calidad requeridas
Asignación de responsabilidad X X
Desarrollo iterativo X
Determinación de estimaciones de esfuerzo de trabajo y costo
X
Gestión de valor agregado
Visibilidad del progreso y resultados
Visualización del flujo de trabajo X
Formación del personal X
Suministro de recursos X
Planificación del proceso X
Monitoreo y control de procesos X
Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method.
Elaboración propia del autor.
1. Práctica Modelado de objetos de dominio:
Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades que se
relacionan con el modelado del dominio. En la Tabla 39 se presentan algunos modelos y documentos
asociados con esta práctica.
Los productos de trabajo que comprende esta práctica se asocian con los alfas oportunidad e
interesados en los tres métodos.
Los productos de trabajo en los tres métodos se relacionan con el comportamiento de la
organización a la cual se le desarrollará la aplicación.
El método CDM Fast Track comprende un producto de trabajo “Definición de la estructura actual
y futura de la organización”, similar al “Organigrama” del UNC-Method.
Los modelos de CDM Fast Track provee un marco de trabajo global del negocio al igual que
RUP con el modelo de objeto del negocio y los casos de uso del negocio, y el UNC-Method con
el modelo del dominio.
CDM UNC-METHOD RUP
Modelo de proceso del contexto Dialogo controlado Modelo de objeto del negocio
Modelo de proceso de negocio de alto nivel
Modelo del dominio Modelo de casos de uso del negocio
Modelo compuesto de función del negocio
Cartas de educción Glosario del negocio
Negocio y objetivos del sistema Archivos digitales Visión del negocio
Descripciones del negocio de alto nivel
Reglas del negocio Reglas del negocio
Definición de la estructura actual y futura de la organización
Organigrama Evaluación de la organización objetivo
Tabla 39. Productos de trabajo asociados a la práctica Modelado de objetos del dominio.
Elaboración propia del autor.
119
2. Práctica Gestión de requisitos:
Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades y
productos de trabajo que se relacionan con el diseño del sistema. En la Tabla 40 se presentan
algunos documentos asociados con esta práctica.
Los productos de trabajo que comprende esta práctica se asocian con los alfa requisitos en los
dos métodos.
Los productos de trabajo en los dos métodos se relacionan con el diseño del sistema y las
actividades relacionadas con la educción de requisitos (documentos y modelos del sistema
existente y documentos del sistema a desarrollar).
Los métodos CDM Fast Track y RUP comprenden para este caso el mismo producto de trabajo,
el glosario.
CDM RUP
Glosario Glosario
Documentación de requisitos Atributos de requisitos
Interfaces del sistema existente Especificación de requisitos
Requisitos de formación Especificaciones suplementarias
Tabla 40. Productos de trabajo asociados a la práctica Gestión de requisitos. Elaboración
propia del autor.
3. La práctica Verificación continua de la calidad
Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades y
productos de trabajo que se relacionan con la verificación continua de la calidad de la aplicación que
se desarrolla. En la Tabla 41 se presentan algunos documentos asociados con esta práctica.
Los productos de trabajo que comprende esta práctica se asocian con el alfa sistema de software
en los dos métodos.
Los productos de trabajo en los dos métodos se relacionan con la validación del sistema de
software que se desarrolla, comprende las actividades relacionadas con el testing.
CDM RUP
Requisitos Validados Configuración de ambiente de pruebas
Resultados de la prueba del módulo de conversión
Caso de prueba
Resultados de las pruebas del sistema Pruebas de script
Resultados de la Prueba de Integración de sistemas
Test suite
Resultados de la Validación Preproducción Test log
Tabla 41. Productos de trabajo asociados a la práctica Verificación continua de la calidad.
Elaboración propia del autor.
4. La práctica Desarrollo basado en componentes
120
Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar el desarrollo de la
aplicación por partes para luego ser integrado. En la Tabla 42 se presentan algunos documentos
asociados con esta práctica.
Los productos de trabajo que comprende esta práctica se asocian con el alfa sistema de software
en los dos métodos.
Los productos de trabajo en los dos métodos se relacionan con la creación de componentes o
módulos que permitan trabajar por separado el desarrollo de la aplicación y luego realizar la
integración del mismo para obtener una aplicación funcional.
CDM RUP
Módulos documentados Componente
Módulo de conversión de datos Componente de prueba
Tabla 42. Productos de trabajo asociados a la práctica Desarrollo basado en componentes
Elaboración propia del autor.
5. La práctica Asignación de responsabilidad
Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar los productos de trabajo
a actividades asociadas con la asignación de responsabilidades durante el desarrollo del proyecto.
En la Tabla 43 se presentan algunos documentos asociados con esta práctica.
Los productos de trabajo que comprende esta práctica se asocian con el alfa equipo en los dos
métodos.
Los productos de trabajo en los dos métodos se relacionan con la conformación del equipo de
trabajo que se va a desarrollar la aplicación, la asignación del trabajo de cada integrante dejando
en claro su organización.
CDM UNC-METHOD
Equipo de Proyecto Integrado Lista de roles y responsabilidades
Dotación de personal y Plan de su Organización
Tabla 43. Productos de trabajo asociados a la práctica Desarrollo basado en componentes.
Elaboración propia del autor.
Las otras prácticas como Suministro de recursos, Planificación del proceso y Monitoreo y control de
procesos se incluyeron por ser prácticas orientadas a la administración de proyectos. En el
documento original se propone el método PJM para complementar el método CDM, esto debido a
que CDM Fast Track es una versión que carece de actividades y productos de trabajo propios que
se relacionen con esta área del desarrollo.
A la práctica Suministro de recursos pertenece el siguiente producto de trabajo:
Lanzamiento de recursos físicos
121
Dotación de personal y plan de su organización
A la práctica Planificación del proceso pertenecen los siguientes productos de trabajo:
Plan de gestión de proyectos
Plan de recursos físicos
Organización preparada
Normas de definición de requisitos y directrices
Estrategias de control y presentación de informes, las normas y los procedimientos
Plan de trabajo
A la práctica Monitoreo y control de procesos pertenecen los siguientes productos de trabajo:
Auditoría de calidad
Reporte de calidad
Línea base auditada
5.2 Validación del UNC-METHOD
Para realizar la validación del UNC-Method se propone un análisis de laboratorio, para lo cual se
hace seguimiento a dos ejemplos de ejecución del método.
Caso de estudio 1: El primer ejemplo se basa en Zapata et al. [27], donde se especifica paso a paso
la aplicación del método, incluyendo los cuatro entregables correspondientes a las cuatro fases del
proceso de educción de requisitos. Se analizan las dos primeras fases del método siguiendo la
aplicación del proyecto que se desarrolló para el Departamento de Ciencias de la Computación y de
la Decisión de la Universidad Nacional de Colombia.
Caso de estudio 2: El segundo ejemplo se toma de Zapata [10]. En este libro se especifica paso a
paso la aplicación del método, los cuatro entregables correspondientes a las cuatro fases del proceso
de educción de requisitos, siguiendo la aplicación del proyecto ZenPhotoTM. La validación paso a
paso se expone en la sección ANEXOS.
Caso de estudio 1
En la primera fase Contexto del Software se presentan los siguientes productos de trabajo de
acuerdo con la secuencia de actividades que se visualiza en la Figura 33.
122
1. Se establece un diálogo controlado en lenguaje
natural, tal como se aprecia en la Figura 50.
Figura 50. Diálogo controlado [10]
Figura 51. Actividad Desarrollar entrevista
interesado-analista y producto de trabajo
Diálogo controlado. Elaboración propia
del autor.
2. A partir del diálogo controlado, se propone el
esquema preconceptual del mismo, incluyendo las
frases del diálogo que cumplen con las relaciones
dinámicas y estructurales que el esquema
preconceptual define (véase la Figura 52).
Figura 52. Esquema pre-conceptual [10]
Figura 53. Actividad Establecer un
vocabulario común y producto de trabajo
Esquema pre-conceptual. Elaboración
propia del autor.
3. Para conocer al interesado, se propone realizar el
organigrama de la empresa a la que se va a realizar
la aplicación, tal como se muestra en la Figura 54.
Figura 54. Organigrama [10]
Figura 55. Actividad Identificar los actores
internos y externos de la organización y
producto de trabajo Organigrama.
Elaboración propia del autor.
123
4. El modelo del dominio, se ilustra en la Figura 56.
Figura 56. Modelo del dominio [10]
Figura 57. Actividad Establecer un
vocabulario común y producto de trabajo
Modelo del dominio. Elaboración propia
del autor.
En la segunda fase, Análisis del problema, se esperan los siguientes productos de trabajo de
acuerdo con la secuencia de actividades que se visualiza en el Anexo A.1.
1. Lo primero que se establece son las reglas del negocio, necesarias para complementar la tabla
explicativa del diagrama de procesos (véase la Figura 59).
Figura 58. Actividad Establecer limitaciones del proceso y producto de trabajo Reglas del
negocio. Elaboración propia del autor.
Figura 59. Reglas del negocio [10]
2. Luego, se propone la representación del diagrama de procesos (véase la Figura 61).
124
Figura 60. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama
de procesos. Elaboración propia del autor.
Figura 61. Diagrama de procesos [10]
3. La tabla explicativa del diagrama de procesos (véase la Figura 63).
Figura 62. Actividad Caracterizar el dominio del problema y producto de trabajo Tabla
explicativa del diagrama de procesos. Elaboración propia del autor.
Figura 63. Tabla explicativa de procesos [10]
125
4. El diagrama de objetivos (véase las Figuras 65).
Figura 64. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama
de objetivos. Elaboración propia del autor.
Figura 65. Diagrama de objetivos [10]
5. El diagrama causa-efecto (véase la Figura 67).
Figura 66. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama
causa-efecto. Elaboración propia del autor.
Figura 67. Diagrama de causa y efecto [10]
126
6. Se desarrolla el diccionario de datos, tal como se muestra en la Figura 69.
Figura 68. Actividad Desarrollar el diccionario de datos y producto de trabajo Diccionario
de datos. Elaboración propia del autor.
Figura 69. Diccionario de datos [10]
5.3 Validación de RUP
Para realizar la validación de RUP se siguen dos proyectos que aplican el método en el proceso de
desarrollo de software. De acuerdo a en [28], se evidencian las experiencias de cuatro proyectos,
sin embargo se seleccionaron dos de ellos (A Y D). Las casillas coloreadas comprenden los roles,
artefactos y actividades que cada equipo utilizó para el desarrollo.
Las actividades presentes en las Tablas 44, 45, 46, 47, 48 y 49 son flujos de trabajo definidos en el
método RUP, es decir, cada uno de los elementos de la lista son un conjunto de actividades que en
muchos casos, tienen actividades en común. Por tal razón, las representaciones de los productos de
trabajo que se utilizaron durante el desarrollo se relacionan con más de una actividad, las cuales los
originan o modifican durante las fases del proyecto.
127
Tabla 44. Roles, artefactos y actividades
de la disciplina requisitos [28]
Requisitos A D
Roles
Analista de sistema
Especificador de casos de uso
Diseñador de interfaz de usuario
Arquitecto Artefactos
Glosario
Visión
Modelo de caso de uso
Especificaciones suplementarias Actividades
Analizar el problema Entender las necesidades de los interesados
Definir el sistema
Gestionar el alcance del sistema
Redefinir la definición del sistema
Gestionar requisitos cambiantes
128
Figura 70. Representación en Semat de actividades, roles y productos de trabajo de la disciplina requisitos. Elaboración propia del autor
129
Gestión de proyectos A D
Roles
Gerente de proyecto
Arquitecto de software
Diseñador de pruebas
Especialista de herramientas
Artefactos
Lista de riesgos
Caso de negocio
Plan de iteración
Plan de desarrollo de software
Base de datos de las medidas del proyecto
Solicitud de cambio
Orden de trabajo
Evaluación de iteración
Actividades
Concebir un nuevo proyecto
Planear próxima iteración
Gestionar iteración
Evaluar el objetivo y riesgo de proyecto
Desarrollar el plan de desarrollo de software
Tabla 45. Roles, artefactos y actividades
de la disciplina gestión de proyectos
[28]
130
Figura 71. Representación en Semat de actividades, roles y productos de trabajo de la disciplina gestión de proyectos. Elaboración
propia del autor.
131
Análisis y diseño A D
Roles
Ingeniero de seguridad
Integrador
Diseñador de base de datos
Arquitecto de software
Diseñador de software
Artefactos
Documento de arquitectura de software
Modelo de diseño
Realización de casos de uso
Lista de riesgos
Visión
Solicitud de cambio
Interfaz
Subsistema de diseño
Especificaciones suplementarias
Clase de diseño
Modelo de datos
Clase de componente
Actividades
Definir una arquitectura candidata
Desarrollar síntesis de arquitectura
Analizar comportamiento
Redefinir la arquitectura
Diseñar componente
Diseñar la base de datos
Tabla 46. Roles, artefactos y actividades
de la disciplina análisis y diseño [28]
132
Figura 72. Representación en Semat de actividades, roles y productos de trabajo de la disciplina análisis y diseño. Elaboración propia
del autor.
133
Despliegue A D
Roles
Gerente de despliegue
Desarrollador de curso
Artefactos
Plan de despliegue
Lista de materiales
Material de entrenamiento
Infraestructura de despliegue
Producto
Unidad de despliegue
Actividades
Planear despliegue
Gestionar prueba de aceptación
Producir unidad de despliegue
Producir pruebas beta
Producto de paquete
Proveer acceso de sitio de descarga
Tabla 47. Roles, artefactos y actividades
de la disciplina despliegue [28]
Figura 73. Representación en Semat de actividades, roles y productos de trabajo de la disciplina despliegue. Elaboración propia del autor.
134
Implementación A D
Roles
Implementador
Arquitecto de software
Integrador
Revisor de código
Tester
Artefactos
Subsistema de implementación
Documento de arquitectura de software
Componente
Componente de prueba
Construcción
Actividades
Estructurar el modelo de implementación
Planear la integración
Implemetar componentes
Integrar cada subsistema
Integrar el sistema
Tabla 48. Roles, artefactos y actividades
de la disciplina implementación [28]
Figura 74. Representación en Semat de actividades, roles y productos de trabajo de la disciplina implementación. Elaboración propia del autor.
135
Entorno A D
Roles
Gerente de proyecto
Integrador
Arquitecto de software
Tester
Artefactos
Plan CM
Solicitud de cambio
Actividades
Planear configuración y cambios del proyecto
Crear ambiente CM de proyectos
Cambiar y deliverar items de configuración
Gestionar líneas bases
Monitoriar y reportar estado de configuración
Gestionar solicitud de cambios
Tabla 49. Roles, artefactos y actividades
de la disciplina entorno [28]
Figura 75. Representación en Semat de actividades, roles y productos de trabajo de la disciplina entorno. Elaboración propia del aurot.
136
6 CONCLUSIONES
La ingeniería de software tiene prácticas inmaduras. Los problemas específicos incluyen:
La falta de una adecuada y ampliamente aceptada base teórica.
El gran número de métodos y variantes de método, con diferencias poco entendidas y
amplificadas artificialmente.
La falta de evaluación y validación experimental creíbles.
La división entre la práctica de la industria y la investigación académica.
Las ventajas de utilizar el lenguaje de Semat para representar las diferentes prácticas son, entre
otras:
Es útil para investigadores y practicantes.
En Semat se pueden incluir todos los métodos y prácticas pertinentes.
Semat incluye un núcleo de elementos ampliamente acordados, extensible para usos
específicos y que se organiza mediante Alfas, que son elementos esenciales de esfuerzo de
ingeniería de que son relevantes para la evaluación del progreso y salud de las tareas.
Se clarifican las competencias pertinentes con cada actividad.
Se puede visualizar el progreso del proyecto a medida que el equipo de trabajo realiza sus
tareas diarias.
Se pueden representar las prácticas de manera independiente sin importar el método de
origen.
Sirve para equipos pequeños y para grandes organizaciones.
Las prácticas definidas en esta Tesis pertenecen a distintas metodologías de desarrollo, ya sean
métodos basados en planes o metodologías ágiles. La clasificación en Semat se realizó mediante
su definición, la cual presenta características que permitieron escoger el área de interés (Cliente,
solución o esfuerzo) al que pertenecen.
Rational Unified Process es un método que define seis mejores prácticas que abarcan aspectos
generales del desarrollo de software. Por ejemplo, la práctica gestión de requisitos agrupa no sólo la
creación de los documentos necesarios para definir el sistema, sino que incluye la creación de
documentos del negocio o empresa para la cual se realiza la aplicación. Esto podría separarse en
dos prácticas propuestas en la Tesis para lograr la separación de intereses, las prácticas Gestión de
requisitos y Modelado de objetos de dominio respectivamente.
137
El método RUP define como artefactos diferentes directrices, que determinan cómo hacer el trabajo
durante el desarrollo de software. En Semat, este tipo de artefactos como no se crean o se modifican
en el tiempo, se definen como recursos y se representan mediante el elemento patrón.
La práctica Modelado visual se define como la agrupación de actividades, que involucran la creación
o modificación de modelos necesarios para definir el sistema. En RUP se utilizan los diagramas UML.
Sin embargo, el UNC-Method y Custom Development Method definen otros tipos de diagramas o
esquemas.
El UNC-Method es método de desarrollo que se enfoca principalmente en la educción de requisitos,
la definición del sistema hasta llegar a un prototipo alfa y al conocimiento del tiempo y valor que el
desarrollo de la aplicación puede tomar. Por esta razón, en el progreso o avance del proyecto,
medido mediante los alfas, no se alcanza a cumplir la lista de chequeo de los últimos estados.
CDM Fast Track es una metodología que no define actividades o artefactos para la administración
del proyecto, por lo cual utilizan las actividades definidas en PJM, de esta forma se complementa el
progreso o avance reflejado en el cumplimiento de todos los estados de los alfas definidos en el
núcleo.
7 BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN
[1] I. Jacobson, P. Ng, P.E. McMahon, I. Spence y S. Lidman. “The Essence of Software
Engineering: The SEMAT Núcleo”. Communications of the ACM, vol. 55, no. 12, pp. 42-49, 2012.
[2] A. O Duarte y M. Rojas. “Las metodologías de Desarrollo Ágil como una Oportunidad para la
Ingeniería del Software Educativo”. Avances en Sistemas e Informática, vol. 5, no. 2, 2009.
[3] R. Úbeda. “Métodos ágiles para el desarrollo de software”. Tesis de Maestría. Universidad
Politécnica de Cataluña, 2009.
[4] Essence –Kernel and Language for Software Engineering Methods. V 1.3, 2013.
[5] C. M. Zapata, F. I. Caraballo, K. Villamizar. “Conocimiento en coaching: su representación
mediante un esquema preconceptual”. Revista Universidad EAFIT, vol. 46, no. 158, pp. 22-33,
2010.
[6] Oracle Method SM. CDM Fast Track Method Handbook. Versión 1.2.0, 2000.
[7] F. I. Caraballo. “Método para la educción de problemas y objetivos en el Coaching ágil”. Tesis
de maetría, Escuela de sistemas, Universidad Nacional de Colombia, Medellín, Colombia, 2012.
[8] C. M. Zapata, S. S. Villegas y I. F. Arango. “Reglas de consistencia entre modelos de requisitos
de Un-Método”. Revista Universidad EAFIT, vol. 42, no. 141, pp. 40-59, 2012.
138
[9] C.M. Zapata. “The UNC-Method revisited: elements of the new approach”. Saarbrüken: Lambert
Academic Publishing.
[10] C. M. Zapata. “Unc-Method Revisited: Elements of the New Approach Eliciting Software
Requirements in a Complete, Consistent, and Correct Way”. LAP Lambert Academic Publishing,
Germany, 2012.
[11] O. A. Pérez. “Cuatro enfoques metodológicos para el desarrollo de Software RUP–MSF–XP-
SCRUM”. Revista Inventum, no. 10, 2011.
[12] C. Larman. “Estructura” en UML y Patrones: Una introducción al análisis y diseño orientado a
objetos y al proceso unificado, segunda edición, Prentice-Hall, 2002.
[13] I. Jacobson, G. Booch y J. Rumbaugh. “El proceso unificado de Desarrollo de software”, Pearson
Education S.A., Madrid, España, 2000.
[14] P. Kruchten. “Static structue: Process description” en The Rational Process Unified: an
introduction, Addison Wesley, 2003, pp. 336.
[15] J. Passing. “Requirements engineering in the Rational Unified Process”, Seminar Requirements
Engineering, Summer term, Hasso Plattner Insitute for Software Systems Engineering, p. 16,
2006.
[16] P. Kruchten, “Procesos de las disciplinas” en Rational Unified Process, The: An Introduction,
tercera edición, Addison Wesley, 2003.
[17] H. A. Fernández. “Procesos de ingeniería de software”. Vínculos, vol. 10, pp. 26-39, 2013.
[18] A. Navarro, J. D. Fernández y J. Morales. “Revisión de metodologías ágiles para el desarrollo de
software A review of agile methodologies for software development. Prospect”. vol. 11, no. 2, pp.
30-39, 2013.
[19] D. M. Owens y, D. Khazanchi. “Software Quality Assurance. Handbook of Research on
Technology Project Management”, Planning, and Operations, 2009.
[20] L. Guzmán y M. Visconti. “Propuesta de Herramientas Genéricas para Implantación de Prácticas
en SQA y SCM”, Actas VIII Encuentro Chileno de Computación, Santiago, Chile, 2000.
[21] Y. Gascón y A. Marcano. “Método de valor ganado en la gerencia de proyectos”. 9th Latin
American and Caribbean Conference for Engineering and Technology Medellín, Colombia, 2011.
[22] M. B. Chrissis, M. Konrad y S. Srhum. “Guía para la integración de procesos y la mejora de
productos”, Segunda edición, 2009.
[23] H. Arboledaa, A. Paz y R. Casallas. “Metodología para implantar el Modelo Integrado de
Capacidad de Madurez en grupos pequeños y emergentes”. Estudios Gerenciales, vol. 29, no.
127, pp. 177–188, 2013.
[24] R. Habraken. “Using qualitative research methodologies in IS development studies”. Tesis de
maestría, Universidad Radboud, Nijmegen, 2005.
139
[25] C. M. Zapata, G. González, R. Manjarrés, F. A. Vargas y W. Arévalo. Software engineering:
methods, modeling, and teaching´, vol. 3, Medellín: Centro Editorial de la Facultad de Minas,
2014.
[26] C. M. Zapata, L. A. Lezcano y P. A. Tamayo. “Validación del método para la obtención automática
del diagrama de objetivos desde esquemas preconceptuales”. Revista EIA, vol. 8, pp. 21-39,
2007.
[27] C. M. Zapata. “Un modelo de diálogo para la generación automática de especificaciones en un-
LENCEP”, Universidad Nacional de Colombia Sede Medellín. Facultad de Minas, Medellín, 2010.
[28] G. K. Hanssen, H. Westerheim y F. O. Bjørnson. “Using Rational Unified Process in an SME – A
Case Study”. Software Process Improvement, Springer Berlin Heidelberg, pp. 142-150, 2005.
140
ANEXOS Anexo A. Fase 2 del UNC-Method: Análisis del problema
Anexo A.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.
141
Anexo A.2. Definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.
142
Anexo A.3. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
143
Anexo B. Fase 3 del UNC-Method: Propuesta de solución
Anexo B.1. Secuencia de actividades en la fase y definición de la práctica Modelado visual. Elaboración propia del autor.
144
Anexo B.2. Definición de las prácticas Gestión de requisitos y Monitoreo y control del proceso. Elaboración propia del autor.
145
Anexo B.3. Definición de la práctica Determinación de estimaciones de esfuerzo de trabajo y costo. Elaboración propia del autor.
146
Anexo C. Fase 4 del UNC-Method: Esquema conceptual
Anexo C.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.
147
Anexo C.2. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
148
Anexo C.3. Definición de la práctica Modelado visual. Elaboración propia del autor.
149
Anexo D. Fase 2 de CDM: Modelado de requisitos
150
Anexo D.1. Secuencia de actividades en la fase y definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.
151
152
Anexo D.2. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
153
154
155
Anexo D.3. Definición de la práctica Planificación del proceso. Elaboración propia del autor.
156
Anexo D.4. Definición de la práctica Suministro de recursos. Elaboración propia del autor.
Anexo D.5. Definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.
157
Anexo E. Fase 3 de CDM: Diseño de sistemas y generación
Anexo E.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del auto
158
Anexo E.2. Definición de la práctica Verificación continua de la calidad. Elaboración propia del autor.
159
160
Anexo E.3. Definición de la práctica Planificación del proceso. Elaboración propia del autor.
161
Anexo E.4. Definición de la práctica Suministro de recursos. Elaboración propia del autor.
162
Anexo E.5. Definición de la práctica Desarrollo basado en componentes. Elaboración propia del autor.
163
164
Anexo E.5. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
165
Anexo F. Fase 4 de CDM: Transición a la producción
166
Anexo F.1. Secuencia de actividades en la fase y definición de la práctica Planificación del proceso. Elaboración propia del autor.
167
Anexo F.2. Definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.
168
169
Anexo F.3. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.
170
171
Anexo F.4. Definición de la práctica Verificación continua de la calidad. Elaboración propia del autor.
172
Anexo G. Fase 2 de RUP: Elaboración
173
174
175
Anexo G.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.
176
177
178
179
Anexo G.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.
180
Anexo G.3. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.
181
Anexo G.4. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.
182
183
184
185
186
187
188
Anexo G.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.
189
Anexo H. Fase 3 de RUP: Construcción
190
191
Anexo H.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.
192
193
194
Anexo H.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.
195
Anexo H.3. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.
196
Anexo H.4. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.
197
198
199
200
201
202
203
Anexo H.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.
204
Anexo I. Fase 4 de RUP: Transición
205
Anexo I.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.
206
207
208
Anexo I.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.
209
Anexo I.3. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.
210
Anexo I.4. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.
211
212
213
214
215
216
217
Anexo I.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.
218
Anexo J. Validación del UNC-Method (Caso de estudio 2)
En esta sección se presenta el caso de estudio 2 de validación del UNC-Method, para su desarrollo
se expone en paralelo el producto de trabajo y su representación en Semat, especificando el alfa
asociado, la actividad y el rol relacionado.
En la primera fase Contexto del Software se presentan los siguientes productos de trabajo de
acuerdo con la secuencia de actividades que se visualiza en la Figura 33.
1. Se establece un diálogo controlado en lenguaje
natural, tal como se aprecia en el Anexo J.1.
Anexo J.1. Diálogo controlado [10]
2. A partir del diálogo controlado, se propone el
esquema preconceptual del mismo, incluyendo las
frases del diálogo que cumplen con las relaciones
dinámicas y estructurales que el esquema
preconceptual define (véase el Anexo J.2).
Anexo J.2. Esquema pre-conceptual [10]
Anexo J.3. Actividad Desarrollar entrevista
interesado-analista y producto de trabajo
Diálogo controlado. Elaboración propia del
autor.
Anexo J.4. Actividad Establecer un vocabulario
común y producto de trabajo Esquema pre-
conceptual. Elaboración propia del autor.
219
3. Para conocer al interesado, se propone realizar el
organigrama de la empresa a la que se va a realizar
la aplicación, tal como se muestra en el Anexo J.5.
Anexo J.5. Organigrama [10]
4. Se presentan las tarjetas de educción (véase el
Anexo J.7).
Anexo J.7. Tarjetas de educción [10]
5. El modelo del dominio, se expresa a continuación:
Anexo J.9. Modelo del dominio [10]
Anexo J.6. Actividad Identificar los actores
internos y externos de la organización y
producto de trabajo Organigrama. Elaboración
propia del autor.
Anexo J.8. Actividad Resumir la información
relacionada con los actores, los objetos y las
funciones y producto de trabajo Tarjetas de
educción. Elaboración propia del autor.
Anexo J.10. Actividad Establecer un vocabulario
común y producto de trabajo Modelo del
dominio. Elaboración propia del autor.
220
En la segunda fase, Análisis del problema, se esperan los siguientes productos de trabajo de acuerdo
con la secuencia de actividades que se visualiza en el Anexo A.1.
1. Lo primero que se establece son las reglas del negocio, necesarias para complementar la tabla
explicativa del diagrama de procesos (véase el Anexo J.12).
Anexo J.11. Actividad Establecer limitaciones del proceso y producto de trabajo Reglas del
negocio. Elaboración propia del autor.
Anexo J.12. Reglas del negocio [10]
2. Luego, se propone la representación del diagrama de procesos (véase el Anexo J.14).
Anexo J.13. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama de
procesos. Elaboración propia del autor.
221
Anexo J.14. Diagrama de procesos [10]
3. La tabla explicativa del diagrama de procesos (véase el Anexo J.16)
Anexo J.15. Actividad Caracterizar el dominio del problema y producto de trabajo Tabla
explicativa del diagrama de procesos. Elaboración propia del autor.
Anexo J.16. Tabla explicativa de procesos [10]
4. El diagrama de objetivos (véase el Anexo J.18).
Anexo J.17. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama de
objetivos. Elaboración propia del autor.
222
Anexo D.18. Diagrama de objetivos [10]
5. El diagrama causa-efecto (véase el Anexo J.20).
Anexo J.19. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama
causa-efecto. Elaboración propia del autor.
Anexo J.20. Diagrama de causa-efecto [10]
6. Se desarrolla el diccionario de datos, tal como se muestra en el Anexo J.22.
Anexo J.21. Actividad Desarrollar el diccionario de datos y producto de trabajo Diccionario de
datos. Elaboración propia del autor.
223
Anexo J.22. Diccionario de datos [10]
En la tercera fase Propuestas de solución los siguientes productos de trabajo de acuerdo con la
secuencia de actividades que se visualiza en el Anexo B.1
De acuerdo al ejemplo, el diagrama de procesos y organigrama expuestos en las fases anteriores son
válidos.
1. Casos de uso:
Anexo J.23. Casos de uso [10]
Anexo J.24. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Casos de uso. Elaboración
propia del autor.
2. Diagrama de interfaz de usuario:
Anexo J.25. Diagrama de interfaz de usuário
[10] Anexo J.26. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Diagrama de flujo de
interfaz de usuario. Elaboración propia del
autor.
224
3.Factores críticos de éxito:
Anexo J.27. Factores críticos de éxito [10]
Anexo J.28. Actividad Establecer factores
críticos de éxito y producto de trabajo Factores
críticos de éxito. Elaboración propia del autor.
Adicionalmente, en esta fase se establece el valor de la solución. Tal como se puede ver en los Anexos
K.30 y K.31, se generan dos productos de trabajo: el costeo de la solución y la valoración de la
propuesta.
4. Valoración de la propuesta:
Anexo J.29. Actividad Establecer el valor de la solución y productos de trabajo Valoración de
la propuesta y Costeo de la propuesta. Elaboración propia del autor.
Anexo J.30. Tabla de valoración de la propuesta [10]
5. Costeo de la solución:
225
Anexo D.31. Costeo de la solución [10]
En la fase Esquema conceptual se presentan los siguientes productos de trabajo de acuerdo con la
secuencia de actividades que se visualiza en el Anexo C.1.
Para proporcionar las bases para la construcción de la aplicación final y desarrollar el prototipo alfa,
se requiere especificar la funcionalidad de la aplicación de software y conocer el esquema
preconceptual. A continuación se modela el comportamiento de la aplicación (véaselos Anexos K.32,
K.34, K.36 y K.38) y se muestra el código fuente (véase el Anexo J.40).
1. Esquema preconceptual basado en
especificaciones:
Anexo J.32. Esquema pre-conceptual con
especificaciones [10]
Anexo J.33. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Especificaciones basadas
en el esquema preconceptual. Elaboración
propia del autor.
2. Diagrama de clases:
Anexo J.34. Diagrama de clases [10]
Anexo J.35. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Especificaciones basadas
en el Diagrama de clases. Elaboración propia
del autor.
226
3. Diagrama de comunicaciones:
Anexo J.36. Diagrama de comunicaciones [10]
Anexo J.37. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Diagrama de
comunicaciones. Elaboración propia del autor.
4. Diagrama de máquina de estados:
Anexo J.38. Diagrama de máquina de estados [10]
5. Ejemplos de código:
Anexo J.40. Código fuente [10]
Anexo J.39. Actividad Especificar la
funcionalidad de la aplicación de software y
producto de trabajo Diagrama de máquinas de
estado. Elaboración propia del autor.
Anexo J.41. Actividad Proporcionar las bases
para la construcción de la aplicación final y
producto de trabajo Ejemplo de código fuente.
Elaboración propia del autor.