Análisis y Diseño de Una Herramienta Gráfica para Los

ANLISIS Y DISEO DE UNA HERRAMIENTA GRFICA PARA LOS
PROCESOS DE LA INGENIERA DE REQUISITOS
DANIEL LEMA BECERRA

LUIS FELIPE RODAS VALENCIA
UNIVERSIDAD TECNOLGICA DE PEREIRA

FACULTAD INGENIERAS: ELCTRICA, ELECTRNICA, FSICA, CIENCIAS DE
LA COMPUTACIN
INGENIERA DE SISTEMAS Y COMPUTACIN
PEREIRA
2012
ANLISIS Y DISEO DE UNA HERRAMIENTA GRFICA PARA LOS

PROCESOS DE LA INGENIERA DE REQUISITOS
DANIEL LEMA BECERRA

LUIS FELIPE RODAS VALENCIA
Trabajo de grado para optar por el ttulo de Ingeniera de Sistemas y Computacin
Asesora
LUZ STELLA VALENCIA AYALA
UNIVERSIDAD TECNOLGICA DE PEREIRA

FACULTAD INGENIERAS: ELCTRICA, ELECTRNICA, FSICA, CIENCIAS DE
LA COMPUTACIN
INGENIERA DE SISTEMAS Y COMPUTACIN
PEREIRA
2012
Nota de aceptacin:
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
Firma del presidente del jurado
__________________________
Firma del jurado
.
__________________________
Firma del jurado
.
Pereira, 23 de Mayo de 2012
AGRADECIMIENTOS
Queremos dar nuestros agradecimientos por el apoyo, la colaboracin, la muy

buena disposicin y el tiempo dedicado al proyecto a la ingeniera Luz Stella
Valencia Ayala, ya que siempre mostr una actitud muy positiva hacia el proyecto
motivndonos siempre a seguir adelante en l.
Agradecemos a la ingeniera Paula Andrea Villa Snchez por brindarnos su tiempo
en asesoras y recomendaciones para realizar la parte de UML de este proyecto
de grado.
TABLA DE CONTENIDO
pg.
CAPTULO 1. INTRODUCTORIO ...................................................... 26

1
FORMULACIN DEL PROBLEMA ......................................... 28
1.1
PROBLEMAS DE ARTICULACIN ............................................................................ 29
1.2
PROBLEMAS DE LIMITACIONES COGNITIVAS DEL SER HUMANO .......................... 29
1.3
PROBLEMAS DE COMUNICACIN ENTRE LOS INTERESADOS, ANALISTAS Y EQUIPO
DE DESARROLLO .................................................................................................................. 29
1.4
TCNICOS ............................................................................................................... 29
1.5
PROBLEMA DE LA INFORMACIN ESTRUCTURADA .............................................. 29
JUSTIFICACIN ...................................................................... 31
OBJETIVOS ............................................................................. 33
3.1
OBJETIVO GENERAL ............................................................................................... 33
3.2
OBJETIVOS ESPECFICOS ........................................................................................ 33
CAPTULO 2. MARCO TERICO ...................................................... 34

4
EL PROCESO DE LA INGENIERA DE REQUISITOS ........... 35

i
4.1
CLASIFICACIN DE LOS REQUISITOS ...................................................................... 36
4.1.1
Requisitos funcionales ................................................................................... 36
4.1.2
Requisitos no funcionales .............................................................................. 36
4.1.3
Requisitos del dominio. .................................................................................. 37
4.2
CARACTERSTICAS DE LOS REQUISITOS ................................................................. 38
4.3
DESARROLLO DE REQUISITOS ................................................................................ 38
4.3.1
Obtencin ...................................................................................................... 39
4.3.2
Anlisis ........................................................................................................... 39
4.3.3
Documentacin o especificacin ................................................................... 40
4.3.4
Validacin ....................................................................................................... 40
4.4
ADMINISTRACIN DE REQUISITOS ........................................................................ 41
4.4.1
Priorizacin de requisitos ............................................................................... 41
4.4.2
Trazabilidad de requisitos .............................................................................. 42
4.5
PLAN DE ADMINISTRACIN DE REQUISITOS ......................................................... 49
4.6
ROLES EN LOS PROCESOS DE LA INGENIERA DE REQUISITOS .............................. 50
4.6.1
Analista .......................................................................................................... 50
4.6.2
Desarrollador ................................................................................................. 56
4.6.3
Profesional de pruebas .................................................................................. 62
4.6.4
Administrador ................................................................................................ 63
ii
4.6.5
Adicionales ..................................................................................................... 68
5
METODOLOGA DE SISTEMAS BLANDOS: MODELO DE
PETER CHECKLAND ......................................................................... 72
5.1
HISTORIA ............................................................................................................... 74
5.2
FILOSOFIA DE LA SSM ............................................................................................ 74
5.3
PROCESO DE LA METODOLOGA ........................................................................... 75
5.3.1
Estadio 1: investigar la situacin problema no estructurado ......................... 76
5.3.2
Estadio 2: expresar la situacin del problema ............................................... 76
5.3.3

Estadio 3: seleccionar una visin de la situacin y producir una definicin raz

....................................................................................................................... 77
5.3.4
Estadio 4: confeccin y verificacin de modelos conceptuales ..................... 78
5.3.5
formal
Estadio 4a: verificacin del modelo conceptual con un modelo de sistema

....................................................................................................................... 79
5.3.6
Estadio 5: comparacin de los modelos conceptuales con la realidad .......... 80
5.3.7
Estadio 6: diseo de cambios deseables, viables y factibles .......................... 81
5.3.8
Estadio 7: acciones para mejorar la situacin del problema .......................... 82
MAPAS CONCEPTUALES ...................................................... 83
6.1
ORIGEN DE LOS MAPAS CONCEPTUALES .............................................................. 83
6.2
ELEMENTOS DE LOS MAPAS CONCEPTUALES ....................................................... 85
iii
6.2.1
Conceptos ...................................................................................................... 85
6.2.2
Palabras de enlace ......................................................................................... 86
6.2.3
Proposiciones ................................................................................................. 87
6.3
CARACTERSTICA DE LOS MAPAS CONCEPTUALES ................................................ 88
6.3.1
Estructura Proposicional ................................................................................ 89
6.3.2
Estructura Jerrquica ..................................................................................... 90
6.3.3
Pregunta de Enfoque ..................................................................................... 90
6.3.4
Enlaces Cruzados ............................................................................................ 90
6.4
ELABORACIN DE UN MAPA CONCEPTUAL .......................................................... 90
DISEO METODOLGICO ..................................................... 93
7.1
DEFINICIN DE LA HIPTESIS ................................................................................ 93
7.2
TIPO DE ESTUDIO ................................................................................................... 93
7.3
TCNICAS DE INVESTIGACIN ............................................................................... 93
7.3.1
Observacin ................................................................................................... 93
7.3.2
Variables ........................................................................................................ 94
CAPTULO 3. DESARROLLO DE LOS OBJETIVOS ....................... 95

8
ANLISIS Y DISEO DEL MDULO DESARROLLO DE
REQUISITOS ..................................................................................... 96
iv
8.1
REQUISITOS FUNCIONALES ................................................................................... 96
8.2
DOCUMENTACIN REFERENTE AL ANLISIS ....................................................... 102
8.2.1
Casos de Uso ................................................................................................ 102
8.2.2
Diagramas de secuencia ............................................................................... 105
8.2.3
Diagramas de Colaboracin ......................................................................... 115
8.3
8.3.1
DOCUMENTACIN REFERENTE AL DISEO ......................................................... 122

Interfaces de usuario ................................................................................... 122
9
ANLISIS Y DISEO DEL MDULO ADMINISTRACIN DE
REQUISITOS ................................................................................... 126
9.1
REQUISITOS FUNCIONALES ................................................................................. 126
9.2
9.2.1
Casos de uso ................................................................................................. 136
9.2.2
9.2.3
Diagramas de colaboracin .......................................................................... 152
9.3
9.3.1

Interfaces de usuario. .................................................................................. 159
10
ANLISIS Y DISEO DEL MDULO DOCUMENTACIN DE
REQUISITOS ................................................................................... 168
10.1
REQUISITOS FUNCIONALES ................................................................................. 168

v
10.2
10.2.1
Casos de uso ................................................................................................. 173
10.2.2
10.2.3
Diagramas de Colaboracin ......................................................................... 181
10.3
10.3.1
Interfaces de usuario ................................................................................... 184
10.3.2
Diagrama de clases y diccionario de clases .................................................. 190
10.3.3
Modelo de la base de datos ......................................................................... 219
10.3.4
Diagrama de componentes .......................................................................... 220
11
VALIDACIN DE LA HIPTESIS . Error! Marcador no definido.
12
CONCLUSIONES ................................................................. 224
13
RECOMENDACIONES .......................................................... 224
14
BIBLIOGRAFA ..................................................................... 228
15
ANEXOS ................................................................................ 235
vi
LISTADO DE TABLAS
pg.
Tabla 1. Requisito
funcional:
El
sistema
permite
administrar
la
imagen
enriquecida. ............................................................................................................ 96
Tabla 2. Requisito funcional: El sistema permite insertar figuras. ....................... 97
Tabla 3.
Requisito funcional: El sistema permite utilizar las herramientas de
dibujar.
........................................................................................................... 97
Tabla 4. Requisito funcional: El sistema permite utilizar las opciones de edicin. .

............................................................................................................... 98
Tabla 5.
Requisito funcional: El sistema permite utilizar las opciones de paleta
de colores. ........................................................................................................... 98
Tabla 6. Requisito funcional: El sistema permite utilizar las
dibujo.
herramientas de
............................................................................................................... 99
Tabla 7. Requisito funcional: El sistema permite administrar las definiciones

races.
............................................................................................................. 100
Tabla 8.
Requisito funcional: El sistema permite administrar los requisitos
obtenidos.
......................................................................................................... 100
Tabla 9.
Requisito funcional: El sistema permite validar el entendimiento entre
los interesados. .................................................................................................... 101

Tabla 10.
Caso de uso: Administrar imagen enriquecida ................................. 102
vii
Tabla 11.
Requisito funcional: El sistema permite administrar el archivo de mapa
conceptual. ......................................................................................................... 126

Tabla 12.
Requisito funcional: El sistema permite al usuario crear requisitos. 127
Tabla 13.
Requisito funcional: El sistema permite administrar los requisitos
creados.
...................................................................................................... 127
Tabla 14.
Requisito funcional: El sistema permite crear una pregunta de
enfoque.
......................................................................................................... 128
Tabla 15.
Requisito funcional: El sistema permite administrar palabras de
enlace.
......................................................................................................... 128
Tabla 16.
Requisito funcional: El sistema permite administrar enlaces cruzados. .

......................................................................................................... 129
Tabla 17.
Requisito funcional: El sistema permite cambiar de posicin elementos
del mapa conceptual. ........................................................................................... 130

Tabla 18.
Requisito funcional: El sistema permite verificar la inclusin de
requisitos obtenidos. ............................................................................................ 131

Tabla 19.
Requisito funcional: El sistema permite ingresar informacin a la
plantilla RMP. ....................................................................................................... 131

Tabla 20.
Requisito funcional: El sistema permite ingresar informacin a la
plantilla SRS. ........................................................................................................ 132

Tabla 21.
Requisito funcional: El sistema permite la especificacin de los
requisitos creados. ............................................................................................... 132

Tabla 22.
Requisito funcional: El sistema permite seleccionar respecto a que
elementos se va hacer trazabilidad. ..................................................................... 133

viii
Tabla 23.
Requisito funcional: El sistema permite generar un diagrama de red y
una pila de actividades. ........................................................................................ 134

Tabla 24.
Requisito funcional: El sistema permite seleccionar una categora
respecto a la que se vaya hacer priorizacin. ...................................................... 134

Tabla 25.
Requisito funcional: El sistema permite seleccionar un rango de
visualizacin del reporte de prioridad. .................................................................. 135

Tabla 26.
Caso de uso: Administrar mapa conceptual ..................................... 136
Tabla 27.
Caso de uso: Ingresar informacin a las plantillas ........................... 139
Tabla 28.
Caso de uso: Especificar un requisito .............................................. 140
Tabla 29.
Caso de uso: Procesos de administracin ....................................... 141
Tabla 30.
Requisito funcional: El sistema permite crear un proyecto .............. 168
Tabla 31.
Requisito funcional: El sistema permite abrir un proyecto. .............. 168
Tabla 32.
Requisito funcional: El sistema permite guardar un proyecto. ......... 169
Tabla 33.
Requisito funcional: El sistema permite administrar la plantilla RMP. ....

......................................................................................................... 170
Tabla 34.
Requisito funcional: El sistema permite administrar la plantilla SRS. ....

......................................................................................................... 170
Tabla 35.
Requisito funcional: El sistema permite administrar la plantilla atributos
de los requisitos. .................................................................................................. 171

Tabla 36.
Requisito funcional: El sistema permite administrar la plantilla de tipos
de requisitos. ........................................................................................................ 171

ix
Tabla 37.
Requisito funcional: El sistema permite generar el documento RMP. ...

......................................................................................................... 172
Tabla 38.
Requisito funcional: El sistema permite generar el documento SRS. ....

......................................................................................................... 172
Tabla 39.
Caso de uso: Administrar Proyectos ................................................ 173
Tabla 40.
Caso de uso: Configurar plantillas ................................................... 175
Tabla 41.
Caso de uso: Generar documentacin ............................................. 177
Tabla 42.
Descripcin de la clase: Interface de usuario ................................... 193
Tabla 43.
Descripcin de la clase: Controlador de proyectos .......................... 194
Tabla 44.
Descripcin de la clase: Controlador plantillas ................................. 194
Tabla 45.
Descripcin de la clase: Interface de gestor grafico ......................... 196
Tabla 46.
Descripcin de la clase: Controlador imagen enriquecida ............... 197
Tabla 47.
Descripcin de la clase: Imagen enriquecida ................................... 197
Tabla 48.
Descripcin de la clase: Controlador imgenes ............................... 198
Tabla 49.
Descripcin de la clase: Imgenes prediseadas ............................ 199
Tabla 50.
Descripcin de la clase: Herramientas de dibujar ............................ 200
Tabla 51.
Descripcin de la clase: Opciones de edicin .................................. 201
Tabla 52.
Descripcin de la clase: Herramientas de dibujo ............................. 202
Tabla 53.
Descripcin de la clase: Paleta de colores ....................................... 202

x
Tabla 54.
Descripcin de la clase: Controlador definiciones races ................. 203
Tabla 55.
Descripcin de la clase: Almacn definiciones races ...................... 203
Tabla 56.
Descripcin de la clase: Controlador requisitos obtenidos ............... 204
Tabla 57.
Descripcin de la clase: Requisitos obtenidos ................................. 205
Tabla 58.
Descripcin de la clase: Interface mapa conceptual ........................ 206
Tabla 59.
Descripcin de la clase: Controlador mapa conceptual ................... 207
Tabla 60.
Descripcin de la clase: Imagen enriquecida ................................... 208
Tabla 61.
Descripcin de la clase: Controlador pregunta de enfoque ............. 208
Tabla 62.
Descripcin de la clase: Pregunta de enfoque ................................. 209
Tabla 63.
Descripcin de la clase: Controlador de requisito ............................ 210
Tabla 64.
Descripcin de la clase: Requisitos .................................................. 211
Tabla 65.
Descripcin de la clase: Controlador de palabra de enlace ............. 211
Tabla 66.
Descripcin de la clase: Palabra de enlace ..................................... 212
Tabla 67.
Descripcin de la clase: Controlador enlace cruzado ...................... 213
Tabla 68.
Descripcin de la clase: Enlace cruzado .......................................... 213
Tabla 69.
Descripcin de la clase: Controlador trazabilidad ............................ 214
Tabla 70.
Descripcin de la clase: Controlador priorizacin ............................ 215
Tabla 71.
Descripcin de la clase: Controlador diagramacin ......................... 216

xi
Tabla 72.
Descripcin de la clase: Controlador documentacin ...................... 217
Tabla 73.
Descripcin del atributo: Prioridad ................................................... 239
Tabla 74.
Descripcin del atributo: Origen ....................................................... 240
Tabla 75.
Descripcin del atributo: Estado ....................................................... 240
Tabla 76.
Descripcin del atributo: Dificultad ................................................... 241
Tabla 77.
Descripcin del atributo: Estabilidad ................................................ 242
Tabla 78.
Descripcin del atributo: Costo ........................................................ 242
Tabla 79.
Descripcin del atributo: Tiempo estimado de desarrollo ................ 243
Tabla 80.
Descripcin del atributo: Asignado a ................................................ 243
Tabla 81.
Descripcin del tipo de requisito: Regla de negocio ........................ 244
Tabla 82.
Descripcin del tipo de requisito: Solicitud de cambio ..................... 244
Tabla 83.
Descripcin del tipo de requisito: Necesidad ................................... 244
Tabla 84.
Descripcin del requisito: Caso de uso ............................................ 244
Tabla 85.
Descripcin del tipo de requisito: Caso de prueba ........................... 245
Tabla 86.
Descripcin del tipo de requisito: Riesgo ......................................... 245
Tabla 87.
Descripcin del tipo de requisito: Requisito funcional ...................... 246
Tabla 88.
Formato de estrategia para la trazabilidad ....................................... 247

xii
LISTADO DE FIGURAS
pg.
Figura 1.
Sub disciplinas de la ingeniera de Requisitos. .................................. 35
Figura 2.
Clasificacin de los requisitos no funcionales. ................................... 37
Figura 3.
Modelo para los procesos de ingeniera de requisitos ...................... 39
Figura 4.
Pre y pos trazabilidad de requisitos ................................................... 43
Figura 5.
Trazabilidad hacia adelante y hacia atrs .......................................... 44
Figura 6.
Atributos de los requisitos que deben ser trazados ........................... 45
Figura 7.
Ejemplo de una lista de trazabilidad ................................................... 47
Figura 8.
Ejemplo de una matriz de trazabilidad ............................................... 48
Figura 9.
Business- process analyst role ........................................................... 51
Figura 10. Business designer role ....................................................................... 52

Figura 11. Business-model reviewer role ............................................................ 52
Figura 12. Requirements reviewer role ............................................................... 53
Figura 13. Requirements specifier role ................................................................ 53
Figura 14. System analyst role ............................................................................ 54
Figura 15. Test analyst role ................................................................................. 55
Figura 16. User-interface designer role ............................................................... 55
xiii
Figura 17. Capsule designer role ........................................................................ 56

Figura 18. Code reviewer role ............................................................................. 57
Figura 19. Database designer role. ..................................................................... 57
Figura 20. Implementer role ................................................................................ 58
Figura 21. Integrator role ..................................................................................... 59
Figura 22. Software architect role ........................................................................ 59
Figura 23. Architecture reviewer role ................................................................... 60
Figura 24. Design reviewer role ........................................................................... 60
Figura 25. Designer role ...................................................................................... 61
Figura 26. Test designer role ............................................................................... 62
Figura 27. Tester role .......................................................................................... 63
Figura 28. Change control manager role ............................................................. 63
Figura 29. Configuration manager role ................................................................ 64
Figura 30. Deployment manager role .................................................................. 65
Figura 31. Process engineer ............................................................................... 65
Figura 32. Project manager role .......................................................................... 66
Figura 33. Project reviewer role ........................................................................... 67
Figura 34. Test manager role .............................................................................. 67
xiv
Figura 35. Course developer role ........................................................................ 68

Figura 36. Graphic artist role ............................................................................... 69
Figura 37. Technical writer role ........................................................................... 70
Figura 38. Tool specialist role .............................................................................. 71
Figura 39. Any role. ............................................................................................. 71
Figura 40. Mapa conceptual de la SSM .............................................................. 73
Figura 41. Los 7 estadios de la SSM ................................................................... 76
Figura 42.
Ideas tericas subyacentes a la construccin y uso de los mapas
conceptuales ........................................................................................................ 84
Figura 43. Caractersticas de los mapas conceptuales ....................................... 89
Figura 44. Variables ............................................................................................ 94
Figura 45. Caso de uso administrar imagen enriquecida .................................. 102
Figura 46.
Diagrama de secuencia: Administrar imagen enriquecida. Seccin
administrar un archivo de imagen enriquecida .................................................... 106

Figura 47. Fuente: Los autores ......................................................................... 106
Figura 48.
insertar figuras ..................................................................................................... 107

Figura 49.
herramientas de dibujar ....................................................................................... 108
xv
Figura 50.
opciones de edicin - parte 1 ............................................................................... 110

Figura 51.
opciones de edicin - parte 2 ............................................................................... 111

Figura 52.
opciones de paleta de colores ............................................................................. 112

Figura 53.
herramientas de dibujo ......................................................................................... 113

Figura 54.
administrar definiciones races ............................................................................. 114

Figura 55.
validar requisitos obtenidos .................................................................................. 114

Figura 56.
administrar requisitos obtenidos .......................................................................... 115

Figura 57.
Diagrama de colaboracin: Administrar imagen enriquecida. Seccin
administrar un archivo de imagen enriquecida .................................................... 116

Figura 58.
insertar figuras ..................................................................................................... 117

Figura 59.
herramientas de dibujar ....................................................................................... 117

Figura 60.
opciones de edicin ............................................................................................. 118
xvi
Figura 61.
herramientas de dibujo ......................................................................................... 119

Figura 62.
opciones de paleta de colores ............................................................................. 119

Figura 63.
administrar definiciones races ............................................................................. 120

Figura 64.
administrar requisitos obtenidos .......................................................................... 121

Figura 65.
validar requisitos obtenidos .................................................................................. 122

Figura 66. Ejemplo de uso del editor grfico. .................................................... 123
Figura 67.
Ejemplo de un formulario para la validacin del entendimiento de un
requisito.
...................................................................................................... 124
Figura 68. Interfaz del men Archivo ................................................................. 125

Figura 69. Caso de uso administrar mapa conceptual ...................................... 136
Figura 70. Caso de uso ingresar informacin a las plantillas ............................ 139
Figura 71. Caso de uso especificar un requisito ............................................... 140
Figura 72. Caso de uso procesos de administracin ........................................ 141
Figura 73.
Diagrama de secuencia: Administrar mapa conceptual. Seccin
administrar un archivo de mapa conceptual ........................................................ 144
xvii
Figura 74.
crear una pregunta de enfoque ............................................................................ 144

Figura 75.
administrar palabras de enlace ............................................................................ 145

Figura 76.
administrar requisitos ........................................................................................... 146

Figura 77.
administrar enlace cruzado .................................................................................. 147

Figura 78. Diagrama de secuencia: Ingresar informacin a las plantillas ......... 148
Figura 79. Diagrama de secuencia: Especificar un requisito ............................ 148
Figura 80.
Diagrama de secuencia: Procesos de administracin. Seccin
proceso de trazabilidad ........................................................................................ 150

Figura 81.
proceso de priorizacin ........................................................................................ 151

Figura 82.
proceso de diagramacin ..................................................................................... 152

Figura 83.
Diagrama de colaboracin: Administrar mapa conceptual. Seccin
administrar un archivo de mapa conceptual ........................................................ 153

Figura 84. Diagrama de colaboracin: Administrar mapa conceptual. Seccin
crear una pregunta de enfoque ............................................................................ 153
Figura 85.
administrar requisitos ........................................................................................... 154

xviii
Figura 86.
administrar palabras de enlace ............................................................................ 155

Figura 87.
administrar enlace cruzado .................................................................................. 155

Figura 88. Diagrama de colaboracin: Ingresar informacin a las plantillas ..... 156
Figura 89. Diagrama de colaboracin: Especificar un requisito ........................ 156
Figura 90.
Diagrama de colaboracin: Procesos de administracin. Seccin
proceso de trazabilidad ........................................................................................ 157

Figura 91.
proceso de priorizacin ........................................................................................ 158

Figura 92.
proceso de diagramacin ..................................................................................... 158

Figura 93.
Ejemplo de un mapa conceptual elaborado a partir de la
especificacin de requisitos ................................................................................. 159

Figura 94. Ejemplo de uso de la herramienta enlace cruzado .......................... 160
Figura 95. Panel Especificacin de requisitos y ejemplo de especificacin ...... 161
Figura 96.
Panel proyecto y ejemplo de cmo aadir la descripcin a un item
de una plantilla ..................................................................................................... 162

Figura 97. Panel de priorizacin y ejemplo de reporte completo de priorizacin ....
......................................................................................................... 163
Figura 98. Panel de Trazabilidad entre elementos y ejemplo de configuracin del
nivel 1
......................................................................................................... 164
xix
Figura 99.
Panel de Trazabilidad entre elementos y ejemplo de configuracin
del nivel 2
...................................................................................................... 165
Figura 100.
Panel de Trazabilidad entre elementos y ejemplo de visualizacin de
la trazabilidad ...................................................................................................... 166

Figura 101.
Panel de diagramas y ejemplo de un diagrama de red con pila de
actividades
...................................................................................................... 167
Figura 102.
Caso de uso administrar proyectos............................................... 173
Figura 103.
Caso de uso configurar plantillas .................................................. 175
Figura 104.
Caso de uso generar documentacin ........................................... 177
Figura 105.
Diagrama de secuencia: Administrar proyecto. Seccin guardar
proyecto
................................................................................................... 178
Figura 106.
Diagrama de secuencia: Administrar proyecto. Seccin crear
proyecto
...................................................................................................... 179
Figura 107.
Diagrama de secuencia: Administrar proyecto. Seccin abrir
proyecto
...................................................................................................... 180
Figura 108.
Diagrama de secuencia: Configurar plantilla ................................ 180
Figura 109.
Diagrama de secuencia: Generar documentacin ........................ 181
Figura 110.
Diagrama de colaboracin: Configurar plantilla ............................ 182
Figura 111.
Diagrama de colaboracin: Administrar proyecto. ........................ 182
Figura 112.
Diagrama de colaboracin: Generar documentacin.................... 183
Figura 113.
Abrir o crear proyecto.................................................................... 184

xx
Figura 114.
Configuracin plantilla: Plan de administracin de requisitos. ...... 185
Figura 115.
Configuracin plantilla: Especificacin de requisitos de software . 186
Figura 116.
Configuracin plantilla: Atributos de los requisitos........................ 187
Figura 117.
Configuracin plantilla: Tipos de requisitos................................... 188
Figura 118.
Panel para generar los documentos formales del proyecto ......... 189
Figura 119.
Diagrama de clases parte 1 ....................................................... 190
Figura 120.
Figura 121.
Figura 122.
Clase: Interface de usuario ........................................................... 193
Figura 123.
Clase: Controlador de proyectos................................................... 194
Figura 124.
Clase: Controlador plantillas ......................................................... 194
Figura 125.
Clase: Interface de gestor grafico ................................................. 195
Figura 126.
Clase: Controlador imagen enriquecida ........................................ 197
Figura 127.
Clase: Imagen enriquecida ........................................................... 197
Figura 128.
Clase: Controlador imgenes........................................................ 198
Figura 129.
Clase: Imgenes prediseadas..................................................... 199
Figura 130.
Clase: Herramientas de dibujar..................................................... 200
Figura 131.
Clase: Opciones de edicin .......................................................... 201

xxi
Figura 132.
Clase: Herramientas de dibujo ...................................................... 201
Figura 133.
Clase: Paleta de colores ............................................................... 202
Figura 134.
Clase: Controlador definiciones races ......................................... 203
Figura 135.
Clase: Almacn definiciones races .............................................. 203
Figura 136.
Clase: Controlador requisitos obtenidos ....................................... 204
Figura 137.
Clase: Requisitos obtenidos.......................................................... 205
Figura 138.
Clase: Interface mapa conceptual................................................. 206
Figura 139.
Clase: Controlador mapa conceptual ............................................ 207
Figura 140.
Clase: Imagen enriquecida ........................................................... 207
Figura 141.
Clase: Controlador pregunta de enfoque ...................................... 208
Figura 142.
Clase: Pregunta de enfoque ......................................................... 209
Figura 143.
Clase: Controlador de requisito..................................................... 209
Figura 144.
Clase: Requisitos .......................................................................... 210
Figura 145.
Clase: Controlador de palabra de enlace...................................... 211
Figura 146.
Clase: Palabra de enlace .............................................................. 212
Figura 147.
Clase: Controlador enlace cruzado ............................................... 213
Figura 148.
Clase: Enlace cruzado .................................................................. 213
Figura 149.
Clase: Controlador trazabilidad ..................................................... 214

xxii
Figura 150.
Clase: Controlador priorizacin ..................................................... 215
Figura 151.
Clase: Controlador diagramacin.................................................. 216
Figura 152.
Clase: Controlador documentacin ............................................... 217
Figura 153.
Modelo de la base de datos para el sistema................................. 219
Figura 154.
Diagrama de componentes para el sistema.................................. 220
Figura 155.
Fuente: Los autores ...................................................................... 220
xxiii
CAPTULO 1.
INTRODUCTORIO
26
INTRODUCCION

En este trabajo de grado se elabora el anlisis y diseo de una herramienta
grfica, la cual tiene como objetivo proporcionar un mecanismo visual de
comunicacin para identificar de forma inequvoca las necesidades que dan lugar
al desarrollo de un proyecto de software, como tambin proporcionar un
mecanismo visual que de sencillez a la monitorizacin de la informacin que se
genera en los procesos de la ingeniera de requisitos.
Este trabajo de grado, se encuentra divido en tres captulos: la introduccin al
trabajo de grado, el segundo captulo el marco terico donde se describen los
procesos de la ingeniera de requisitos que se proponen llevar a cabo mediante la
implementacin de las metodologas de sistemas blandos y mapas conceptuales,
y por ltimo el captulo desarrollo de los objetivos en el cual est el anlisis y
diseo de la herramienta grfica.
Este tercer captulo a su vez se divide en tres mdulos: en el primer mdulo se
realiza el anlisis y diseo de las herramientas y el rea de trabajo que permitan a
un equipo de desarrollo implementar la teora de los sistemas blandos, para que, a
travs de la construccin de imgenes enriquecidas se minimicen los problemas
relacionados a la especificacin de requisitos de naturaleza cognitivos,
antropolgicos, sociales y lingsticos en la comunicacin, las cuales son
enunciados en la seccin: 3 formulacin del problema.
En el segundo mdulo se realiza el anlisis y diseo de las herramientas y el rea
de trabajo que permitan a un equipo de desarrollo implementar la teora de los
mapas conceptuales para configurar el plan de administracin de requisitos y
tambin realizar la administracin de los requisitos durante un proyecto de
software.
En el tercer mdulo se realiza el anlisis y diseo de las herramientas y el rea de
trabajo que permitan al equipo de desarrollo obtener los documentos formales del
plan de administracin de requisitos y la especificacin de requisitos a partir del
mapa conceptual y las plantillas que se hayan construido.
27
1 FORMULACIN DEL PROBLEMA

Un punto crucial en la gestin de un proyecto de desarrollo de software es la
determinacin de los requisitos que ste debe satisfacer para ser considerado un
"software de calidad"1. En este punto entra el rol de la ingeniera de requisitos, la
cual es definida como:
"la rama de la ingeniera del software interesada en definir necesidades reales,
funciones, y lmites de los sistemas de software. Incluso en describir la relacin de
estos factores con la especificacin exacta del comportamiento del software, as
como de la evolucin de esta especificacin por el trascurso de las dems ramas
de la ingeniera del software"2.
Aunque la ingeniera de requisitos est formada por una serie de ramas3, siguen
existiendo diferentes dificultades para la obtencin de requisitos, en parte porque
"es una actividad principalmente de carcter social, mucho ms que tecnolgico"4.
De esta forma, desde la perspectiva de una actividad social, "los problemas que se
plantean son por tanto de naturaleza cognitivos, antropolgicos, sociales y
lingsticos en la comunicacin"5 de los participantes del desarrollo de requisitos.
Esto implica que la ingeniera de requisitos sea sensible a cmo la gente percibe
y entiende el mundo que les rodea, cmo interactan, y cmo el entorno social del
lugar de trabajo afecta a sus acciones. De este modo, esta propuesta est dirigida
a reducir la complejidad del proceso de desarrollo de requisitos, asociada a la
siguiente serie de dificultades:
1 Red de Revistas Cientficas de Amrica Latina y el Caribe, Espaa y Portugal.

http://redalyc.uaemex.mx/pdf/496/49614310.pdf

2 NUSEIBEH, Bashar y EASTERBROOK, Steve. Requirements Engineering: A Roadmap.
http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf

3 WIEGERS, Karl. When telepathy wont do: Requirements engineering key practices.
http://www.processimpact.com/articles/telepathy.pdf

4 GRUPO DE INGENIERIA DEL SOFTWARE, Universidad de Sevilla.
http://www.lsi.us.es/docencia/get.php?id=2006

5 NUSEIBEH, Bashar y EASTERBROOK, Steve. Requirements Engineering: A Roadmap
28
1.1
PROBLEMAS DE ARTICULACIN
Estn relacionados con la expresin de sus necesidades por parte de los
interesados y la comprensin de dichas necesidades por parte de los analistas.
Dificultad para expresar claramente las necesidades

No ser conscientes de sus propias necesidades
No entender como la tecnologa puede ayudar
Miedo a parecer incompetentes por ignorancia tecnolgica
No tomar decisiones por no poder prever las consecuencias, no entender
las alternativas o no tener una visin global
No escuchar adecuadamente a los clientes y usuarios.
PROBLEMAS DE LIMITACIONES COGNITIVAS DEL SER HUMANO

No conocer el dominio del problema
Hacer suposiciones sobre el dominio del problema
Hacer suposiciones sobre aspectos tecnolgicos
Hacer simplificaciones excesivas.
1.2
1.3
PROBLEMAS DE COMUNICACIN ENTRE LOS INTERESADOS,
ANALISTAS Y EQUIPO DE DESARROLLO
Cultura y vocabulario diferentes
Intereses distintos en el sistema a desarrollar
Medios de comunicacin inadecuados (por ejemplo diagramas que no
entienden los interesados)
Conflictos personales o polticos.
1.4
TCNICOS
Complejidad del dominio del problema
Complejidad de los requisitos
Cambios en los requisitos
Mltiples fuentes de requisitos
Fuentes de informacin poco claras.
1.5
PROBLEMA DE LA INFORMACIN ESTRUCTURADA
La desventaja de ver la informacin de forma estructurada es que a menudo slo
es una abstraccin parcial de la informacin que representa. En estos casos, los
datos formalizados pierden aspectos de la informacin que pretenden representar,
y los pedazos resultantes de datos discretos no son significativos sino se
29
contextualizan adecuadamente. Esta forma tradicional de visualizar la informacin

es con la que normalmente se trabaja y resulta ser inapropiada para deducir la
relacin entre los datos.6 En otras palabras, aplicando este concepto a la
ingeniera de requisitos sera: comprender las relaciones entre los requisitos es
importante para comprender los propios requisitos.
Una vez especificados y validados los requisitos, stos debern ser medibles,
trazables y comprobables, ya que de su cumplimiento se determinar el xito o
fracaso del proyecto. Asignarle a una persona la responsabilidad de mantener la
informacin de los requisitos actualizada es una tarea que incrementa en
dificultad, a medida que aumenta la complejidad, el tamao y la cantidad de
personas involucradas en el proyecto. Es por esto, que se propone mejorar el
proceso de documentacin en la trazabilidad de requisitos, por medio de una
sincronizacin actualizada de la informacin pertinente a los requisitos que es
generada en las diferentes etapas del proyecto y a la cual, le es necesaria llevar
un seguimiento segn como se hubiese realizado la configuracin de la
trazabilidad7.
La anterior descripcin, explica los problemas relacionados en el desarrollo y
administracin de requisitos, los cuales son los aspectos del contexto de la
realidad problemtica8. De esta manera, se enuncia la formulacin del problema
para este proyecto de grado:
Para realizar una gestin eficiente en un proyecto orientado al desarrollo de
software, no existe un formato de comunicacin entendible entre los involucrados
en el proyecto. Al no existir este formato de comunicacin, es difcil comprender y
relacionar la informacin gestionada desde el momento en que se identifican las
necesidades por las cuales se inicia el proyecto hasta el desarrollo y la
administracin de los requisitos en el trascurso del proyecto.
6 HSIEH, Haowei y SHIPMAN Frank. Supporting Visual Problem Solving in Spatial Hypertext
http://journals.tdl.org/jodi/article/viewArticle/173

7 GODOY, Danny Alexander. Generacin automtica de documentos de requisitos en proyectos de software
http://captura.uchile.cl/jspui/handle/2250/11311

8 ARTEAGA PACHECO, Carlos Mario. Unidad 2: La propuesta , de la materia Proyecto de Grado I. 2009-II
30
2 JUSTIFICACIN
En la actualidad, la especificacin de requisitos se basa en el uso de la norma
IEEE-830, pero se pierde informacin en las etapas previas a la especificacin, en
parte porque son actividades principalmente de carcter social. De esta forma,
desde la perspectiva de una actividad social, los problemas que se plantean son
por tanto de naturaleza cognitivos, antropolgicos, sociales y lingsticos en la
comunicacin de los participantes. Estos procesos de desarrollo de requisitos,
pueden ser mejorados con la ayuda de sistemas blandos, por ello, un beneficio de
este proyecto ser para los interesados y analistas, mejorando los mecanismos de
comunicacin para identificar el problema y establecer el qu se va hacer en el
proyecto.
Una vez especificados y validados los requisitos, la informacin relacionada a
estos, es almacenada y recuperada de forma estructurada, resultando ser
inapropiada para comprender las relaciones entre los requisitos. Estos procesos
de especificacin y validacin de requisitos pueden ser mejorados con la ayuda de
este gestor visual, mediante la captura de requisitos en la imagen enriquecida y/o
modelo(s) conceptual(es). Otro beneficio de este proyecto es en el proceso de
administracin de requisitos porque mejora los mecanismos de comunicacin
interna para el equipo de desarrollo con la ayuda de los mapas conceptuales.
Realizando este anlisis y diseo se proveera la informacin necesaria para
implementar en un futuro un gestor visual, para llevar a cabo los procesos de la
ingeniera de requisitos, implementando la teora de los mapas conceptuales y la
administracin visual para mejorar en aspectos como:
Dar sencillez a la monitorizacin de la informacin que se genera en los

proyectos de software, para as mejorar la toma de decisiones en el
proyecto
Minimizar los inconvenientes de carcter social en la etapa de desarrollo de
requisitos, los cuales se traducen en "errores en la etapa inicial del proyecto
que a su vez, repercuten negativamente las dems etapas del proyecto de
software"9. Esto significara mejorar la calidad de la etapa inicial del
proyecto de software
9 MIZUNO, Y. Software Quality Improvement

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1654331
31
Automatizar tareas que faciliten la administracin de procesos asociados

con los requisitos especificados, pretendiendo mejorar la trazabilidad de
requisitos y ahorro de tiempo en el desarrollo del proyecto
"Disear un ambiente visual de trabajo que permita relacionar de forma
clara la informacin gestionada en su conjunto, y que a la vez, cuando sea
necesario, permita la manipulacin directa de la informacin o de su
organizacin por medio de una tcnica intuitiva y eficiente a los usuarios. Lo
cual significara tomar ventaja de la cognicin espacial humana y de la
retroalimentacin inmediata de los entornos visuales."10
10 HSIEH, Haowei y SHIPMAN Frank. Supporting Visual Problem Solving in Spatial Hypertext
http://journals.tdl.org/jodi/article/viewArticle/173
32
3 OBJETIVOS
3.1
OBJETIVO GENERAL
Desarrollar el anlisis y diseo de un gestor grfico de requisitos, para el apoyo al
desarrollo y administracin de requisitos en proyectos de software.
3.2
OBJETIVOS ESPECFICOS
Realizar el anlisis y diseo del mdulo desarrollo de requisitos, el cual,
propicie la comunicacin entre los participantes del proyecto.
Realizar el anlisis y diseo del mdulo administracin de requisitos, en

el cual, se configure el plan de administracin de requisitos y su
trazabilidad.
Realizar el anlisis, diseo del mdulo documentacin de requisitos, el

cual, genere los documentos: especificacin de requisitos y el plan de
administracin de requisitos.
33
CAPTULO 2.
MARCO TERICO
34
4 EL PROCESO DE LA INGENIERA DE REQUISITOS

La base de cualquier software recae sobre su proceso de ingeniera de requisitos.
El xito o fallo del software depende casi siempre de que tan bien se hayan
capturado, entendido y usado los requisitos como base para el desarrollo. La
ingeniera de requisitos es la fase de la ingeniera del software donde se definen
las propiedades y la estructura del software11. Una definicin ms precisa de
ingeniera de requisitos puede ser la siguiente12:
Rama de la ingeniera del software interesada en definir necesidades reales,
funciones, y lmites de los sistemas de software. Incluso en describir la relacin de
estos factores con la especificacin exacta del comportamiento del software, as
como de la evolucin de esta especificacin por el trascurso de las dems ramas
de la ingeniera del software.
Figura 1. Sub disciplinas de la ingeniera de Requisitos.
Fuente: When Telepathy Wont Do: Requirements Engineering Key Practices, Karl
E. Wiegers
En la figura 113 se han ilustrado las dos sub disciplinas comprendidas por la
ingeniera de requisitos. Para empezar a describir estas dos sub disciplinas, hay
11 INTECO, Instituto Nacional de Tecnologas de la Comunicacin. Gua prctica de gestin de requisitos
http://es.scribd.com/doc/38820789/Guia-Practica-de-Gestion-de-Requisitos

12 NUSEIBEH, Bashar y EASTERBROOK, Steve. Requirements Engineering: A Roadmap.

13 WIEGERS, Karl E. When Telepathy Wont Do: Requirements Engineering Key Practices
http://www.processimpact.com/articles/telepathy.pdf
35
que describir primero, lo que es un requisito, sus clasificaciones y sus

caractersticas. La definicin propuesta por la IEEE es la siguiente14:
Una condicin o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estndar, especificacin u
otro documento formal.
4.1
CLASIFICACIN DE LOS REQUISITOS
Clasificar requisitos es una forma de organizarlos, segn los tipos de requisitos
necesarios para poder ser administrados eficientemente. A continuacin se
describen algunos de los tipos de requisitos existentes segn Ian Sommerville en
su libro ingeniera del software sptima edicin:
4.1.1 Requisitos funcionales
Los requisitos funcionales de un sistema describen lo que el sistema debe hacer o
reaccionar a entradas particulares y de cmo se debe comportar en situaciones
particulares. Estos requisitos dependen del tipo de software que se desarrolle, de
los posibles usuarios del software y del enfoque general tomado por la
organizacin al redactar requisitos. Cuando se expresan como requisitos del
usuario, habitualmente se describen de una forma bastante abstracta. Sin
embargo, los requisitos funcionales del sistema describen con detalle la funcin de
ste, sus entradas y salidas, excepciones, etctera.
4.1.2 Requisitos no funcionales
Los requisitos no funcionales, como su nombre sugiere, son aquellos requisitos
que no se refieren directamente a las funciones especficas que proporciona el
sistema, sino a las propiedades emergentes de ste como la fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las
restricciones del sistema como la capacidad de los dispositivos de entrada/salida y
las representaciones de datos que se utilizan en las interfaces del sistema.
En la figura 2 se muestra la clasificacin de los requisitos no funcionales. En esta
figura puede verse que los requisitos no funcionales pueden clasificarse en tres
categoras principales, de acuerdo a las caractersticas requeridas del software
14 INSTITUTE FOR ELECTRONICS AND ELECTRICAL ENGINEERS. Glosario estndar de la terminologa de la

ingeniera de software estndar 610.12-1990. s.I.: La institucin, 1997.

36
(requerimientos del producto), de la organizacin que desarrolla el software

(requerimientos organizacionales) o de fuentes externas.
Figura 2. Clasificacin de los requisitos no funcionales.
Fuente: Ingeniera del Software sptima edicin, Ian Sommerville

4.1.3 Requisitos del dominio.
Los requisitos del dominio se derivan del dominio de aplicacin del sistema ms
que de las necesidades especficas de los usuarios. Normalmente incluyen
terminologa especializada del dominio o referencias a conceptos del dominio.
Pueden ser requisitos funcionales nuevos, restringir los existentes o establecer
cmo se deben ejecutar clculos particulares. Debido a que stos se especializan,
a los ingenieros de software a menudo les resulta difcil entender cmo se
relacionan con los otros requerimientos del sistema.
Los requisitos del dominio son importantes debido a que a menudo reflejan los
fundamentos del dominio de aplicacin. Si estos requerimientos no se satisfacen,
puede ser imposible hacer que el sistema funcione de forma satisfactoria.
37
4.2
CARACTERSTICAS DE LOS REQUISITOS
Un conjunto de requisitos deben presentar una serie de caractersticas tanto
individualmente como en grupo15:
Necesario: Un requisito es necesario si su omisin provoca una deficiencia

en el sistema a construir, y adems su capacidad, caractersticas fsicas o
factor de calidad no pueden ser reemplazados por otras capacidades del
producto o del proceso
Conciso: Un requisito es conciso si es fcil de leer y entender. Su
redaccin debe ser simple y clara para aquellos que vayan a consultarlo en
un futuro
Completo: Un requisito est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su
comprensin
Consistente: Un requisito es consistente si no es contradictorio con otro
requerimiento
No ambiguo: Un requisito no es ambiguo cuando tiene una sola
interpretacin. El lenguaje usado en su definicin, no debe causar
confusiones al lector
Verificable: Un requisito es verificable cuando puede ser cuantificado de
manera que permita hacer uso de los siguientes mtodos de verificacin:
inspeccin, anlisis, demostracin o pruebas.
4.3
DESARROLLO DE REQUISITOS
Una vez, definido el concepto de requisito se pasa a describir el proceso de la
ingeniera de requisitos, que como lo muestra la figura 1 consta de dos ramas
principales:
La rama desarrollo de requisitos es un conjunto estructurado de actividades,
mediante las cuales se obtiene, valida y mantiene el SRS y su objetivo es entregar
una especificacin de requisitos de software correcta y completa.
Este proyecto de grado toma como base el modelo de actividades para los
procesos de ingeniera de requisitos descrito por el profesor Ian Sommerville. Este
modelo tiene como estructura los siguientes procesos para la etapa de desarrollo
de requisitos, tal como se muestra en la figura 3.
15 ROWLAND YOUNG, Ralph. The requirements engineering handbook Escrito por
http://bib.tiera.ru/dvd51/Young%20R.%20R.%20-
%20The%20Requirements%20Engineering%20Handbook(2003)(278).pdf
38
Figura 3. Modelo para los procesos de ingeniera de requisitos
Fuente: Requirements Engineering, St Andrews University. Professor Ian

Sommerville.
4.3.1 Obtencin
La obtencin de requisitos se considera como el primer proceso necesario en
realizar, para lograr entender los problemas que hay que resolver e identificar las
fuentes de los requisitos de software y adems de cmo estos podran ser
identificados por la ingeniera de software. La elicitacin de requisitos es
fundamentalmente una actividad humana.
El proceso de obtencin de requisitos involucra los estadios 1) para recolectar la
informacin disponible y 2) construir una imagen enriquecida que exprese la
situacin problemtica o en otras palabras como es el funcionamiento del sistema
y cmo influyen los actores. Para realizar este proceso se puede recurrir a
tcnicas como las siguientes:
4.3.2 Anlisis
Una vez identificados estos requisitos, los requisitos se agrupan por categoras y
se organizan en subconjuntos, se estudia cada requisito en relacin con el resto,
se examinan los requisitos en su consistencia, completitud y ambigedad, se
clasifican en base a las necesidades de los interesados16 y se
16 SOTO, Lauro. MiTecnologico.com. Especificaciones de requerimientos

http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos

39
establecen los lmites del software al igual de cmo este debe interactuar con su
entorno.17
El proceso de anlisis de requisitos involucra los estadios 3) para elegir una
posible solucin. 4) Construir un modelo mental de la posible solucin 4a) Verificar
que el modelo conceptual este acorde a la posible solucin. 5) Comparar la
imagen enriquecida que describe la situacin problemtico con el modelo
conceptual con el cual se quiere dar solucin. 6) Disear posibles cambios y 7)
implantar los cambios.
4.3.3 Documentacin o especificacin
Este documento recoge la especificacin de requisitos realizando una descripcin
completa del sistema,18 para sistemas complejos consta de tres documentos:
definicin del sistema, requisitos del sistema y los requisitos del software. En
cambio, si se desarrolla un sistema no complejo basta con realizar el documento
de requisitos del software.19
A partir de sta documentacin se establece un diseo que se ajuste a los
requisitos aqu expuestos. En el anexo1, se ilustra un modelo de documento SRS
basado en la propuesta del estndar IEEE-STD-830-1998.
4.3.4 Validacin
La validacin es la etapa final del desarrollo de requisitos, en ella se debe ratificar
los requisitos, es decir, verificar todos los requisitos que aparecen en el SRS para
detectar omisiones, conflictos y ambigedades no detectadas en el anlisis y
tambin se debe comprobar que los requisitos siguen las normas de calidad
establecidas. En otras palabras, los autores combinan validacin y verificacin en
una sola actividad para asegurarse que representan una descripcin, por lo
menos, aceptable del sistema que se debe implementar. Esto implica verificar que
los requisitos sean consistentes y que estn completos.
El proceso de validacin de requisitos involucra los estadios 4, 5, 6 y 7, los
cuales pueden ser utilizados tanto para el proceso de anlisis como para el de
17 SOMMERVILLE, Ian. Ingeniera de software sptima edicin., Addison-Wesley, 2005.

18 IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, IEEE, 1998.

19 SWEBOK, Software Engineering Body of Knowledge 2004

40
validacin. Esto se da porque la implementacin de la metodologa de sistemas

blandos sugiere tres aspectos claves para solucionar los problemas de carcter
social y que en cierto grado estn relacionados con ambos procesos. Estos tres
aspectos de la metodologa son: modelar la situacin problemtica y su posible
solucin. 2) Comparar la situacin problemtica con su posible solucin y 3)
Disear posibles cambios.
4.4
ADMINISTRACIN DE REQUISITOS
La rama de administracin de requisitos, comprende el conjunto de procesos
necesarios, para mantener el control y consistencia de los requisitos especificados
inicialmente en el SRS, de los cambios realizados a stos y lo que se desarrolla en
el proyecto, para as, en lo posible asegurar que el producto desarrollado satisfaga
las necesidades de los usuarios.
En la administracin de requisitos, los requisitos se utilizan como base para
determinar las actividades a realizar durante el proyecto, como lo es la
planificacin inicial y dems re-planificaciones necesarias.20 Algunas de las
actividades para administrar los requisitos son:
4.4.1 Priorizacin de requisitos
Para minimizar dificultades respecto a fechas de entrega, recursos limitados,
administrar una cantidad elevada de requisitos, el jefe de proyecto tiene que
buscar un equilibrio entre el alcance del proyecto deseado y las restricciones de
agenda, presupuesto, recursos y metas de calidad. Las decisiones que hay que
tomar sobre la priorizacin involucran estos diversos factores, y estos factores
estn a menudo en continuo conflicto entre ellos.
Los clientes y los desarrolladores deben proporcionar las entradas para la
priorizacin de los requisitos. Los clientes priorizan los requisitos inicialmente
desde la perspectiva de cuan valiosos son cada uno de estos para ellos. Una vez
que el desarrollador especifica el coste, dificultad y riesgos asociados a los
requisitos, los clientes deben decidir si son tan esenciales como pensaban. La
priorizacin es un balance entre los beneficios de negocio de cada requisito, su
coste y cualquier implicacin que pueda tener.
20 PEA GARCA, Mara. Impacto de la aplicacin del modelo cmmi nivel 2 en el ciclo de vida de un
proyecto.
http://oa.upm.es/1645/
41
4.4.2 Trazabilidad de requisitos

Como cualquier proceso de software, establecer la trazabilidad surge de la
necesidad de poder realizar un seguimiento al cumplimiento y dar apoyo a los
cambios en los requisitos. La trazabilidad es el mecanismo que permite lograr
estas actividades. Esta prctica es la base de la administracin de los
requisitos,21 puesto que brinda la informacin necesaria para el control de las
actividades y cambios en los productos de trabajo, proporcionando elementos que
ayudan a la comunicacin entre el equipo de trabajo a lo largo del proceso de
desarrollo de software. Los modelos de trazabilidad reconocen tres elementos
bsicos: los participantes (interesados), las fuentes (documentos y modelos) y los
objetos a ser trazados.
Estos elementos y su evolucin se deben identificar explcitamente en cada flujo
de trabajo para as controlar y soportar el trazado en las fases del proceso. Por lo
tanto, es necesario que un flujo de control de la trazabilidad apoye los flujos de
trabajo del proyecto. Los modelos de trazabilidad se deben generar por iteracin
para que los grupos de trabajo tomen decisiones acerca del alcance del desarrollo
y del impacto del cambio. As, se realizarn negociaciones oportunas con los
participantes del proyecto.
4.4.2.1 Qu es trazabilidad?
La trazabilidad de requisitos se define como:
la habilidad para describir y seguir la vida de un requisito en ambos sentidos,
hacia sus orgenes o hacia su implementacin, a travs de todas las
especificaciones generadas durante el proceso de desarrollo de software22.
Para ello el proceso de trazabilidad ha de considerar dos sub actividades:

Configuracin de la trazabilidad de acuerdo con las necesidades concretas del
proyecto, para as conseguir un resultado positivo respecto del costo-beneficio
asociado. La segunda sub actividad es la especificacin de la trazabilidad en el
21 TABARES, Marta Silvia. Revista EIA, ISSN 1794-1237 Nmero 4 p. 95-102. Noviembre 2005. Escuela de
Ingeniera de Antioquia, Medelln (Colombia). anlisis de la trazabilidad desde la perspectiva de la
orientacin a aspectos
http://revista.eia.edu.co/articulos4/art%208%20N4.pdf
22 GOTEL, Orlena & FINKELSTEIN, Antony. An Analysis of the Requirements Traceability Problem.
International Conference on Requirements Engineering, ICRE94, Los Alamitos,
California, Abril, 1994, pp 94-101.
http://selab.netlab.uky.edu/homepage/gotel94analysis.pdf

42
proyecto y la posterior explotacin de dicha informacin.23 Para llevar a cabo la

segunda actividad se puede realizar cualquiera de los mtodos que se enuncian
en la siguiente clasificacin.
4.4.2.2 Clasificacin de la trazabilidad de requisitos
La pre y pos trazabilidad de requisitos son las dos clasificaciones bsicas en que
se divide la trazabilidad de requisitos. Las siguientes son las definiciones dadas
por Gotel a estas dos clasificaciones:
4.4.2.2.1 Pre trazabilidad de requisitos
La pre trazabilidad de requisitos, hace referencia a la capacidad de describir y
seguir las particularidades de la vida de un requisito previo a su especificacin en
el SRS. Este seguimiento puede ser hacia adelante o hacia atrs.
La pre trazabilidad es una actividad para documentar la razn por la cual se
especifica el requisito, al igual que la fuente de los requisitos (personas que
participan, normas, estndares, etc.).
4.4.2.2.2 Pos trazabilidad de requisitos
Figura 4. Pre y pos trazabilidad de requisitos
Fuente: GOTEL, Orlena & FINKELSTEIN, Antony. An Analysis of the Requirements

Traceability Problem.
23 ANAYA, Victor & LETELIER, Patricio. SmarTTrace Una Herramienta para Trazabilidad de Requisitos en
Proyectos basados en UML
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.9907
43
La pos trazabilidad de requisitos hace referencia a la capacidad de describir y

seguir las particularidades de la vida de un requisito que resultan debido a su
especificacin en el SRS. Este seguimiento puede ser hacia adelante o hacia
atrs, lo que da visibilidad a cmo una necesidad es satisfecha en el software,
identificando los requisitos involucrados a esta. La figura 4 ilustra en que parte del
proyecto es que se usa la pre y post trazabilidad de requisitos.
4.4.2.2.3 Trazabilidad hacia adelante y trazabilidad hacia atrs.
Figura 5. Trazabilidad hacia adelante y hacia atrs
Fuente: Requirements traceability. Mia Hokkanen

La trazabilidad hacia adelante y hacia atrs, significa que un requisito puede ser
seguido desde su origen hasta su implementacin y/o verificacin.24 La figura 5
muestra un total de cuatro clases de enlaces para la trazabilidad hacia adelante y
hacia atrs. Las necesidades del cliente son relacionadas hacia adelante por
medio de la especificacin de requisitos, por lo que s las necesidades cambian
durante el desarrollo del proyecto, mediante este vnculo se podr ver cuales
requisitos se vern directamente afectados.
4.4.2.3 Atributos de los requisitos que deben ser trazados
Existen diferentes tipos de informacin que deben ser trazadas, las cuales deben
ser monitoreadas durante el trascurso del proyecto. La figura 6 ilustra ocho tipos
de informacin a ser trazada. Esta clasificacin se basa en la relacin entre los
requisitos y otros entes. Mia Hokkanen recopila en su tesis requirements
traceability25 la siguiente clasificacin basada en la relacin entre los requisitos y
otros entes.
24 HOKKANEN, Mia. Requirements traceability

http://www.doria.fi/bitstream/handle/10024/35358/nbnfi-fe20011576.pdf?sequence=1

25 Ibid
44
Figura 6. Atributos de los requisitos que deben ser trazados

4.4.2.3.1 Las fuentes de los requisitos
Es la relacin existente entre un requisito y la informacin en la que se justifica su
existencia. Una fuente de requisitos puede ser un interesado, estndar, un
documento tcnico, otro requisito, una combinacin de estos, etc.
Esta relacin ayuda a analizar un requisito y a entender porque el requisito existe.
Si el requisito cambia de fuente podra ser fcilmente encontrada, siendo til para
la administracin de cambios y en las actividades de validacin, anlisis,
especificacin y priorizacin de requisitos.
4.4.2.3.2 Razn por la que existe el requisito
Es la relacin existente entre una necesidad y el requisito con la solucin
propuesta al problema. La razn de su existencia ayuda al entendimiento del
requisito y al momento de evaluar el impacto de los cambios a los requisitos.
Este tipo de trazabilidad tambin resulta til para comprobar si un requisito es
consistente con la solucin propuesta al problema, con la priorizacin del requisito,
a estimar la probabilidad de hacer cambios y reso de los requisitos.
4.4.2.3.3 Personas involucradas con los requisitos
Es la forma de mantener el vnculo de las personas que han participado en la
especificacin de requisitos. S la informacin necesaria para contactarlas est
45
disponible, aquellas personas podrn ser consultadas cuando se necesite mayor

informacin o clarificacin acerca de los requisitos.
Esta podra ser la nica oportunidad de volver a obtener informacin referente a
los
requisitos una vez especificados estos. Ya bien sea, porque los
proyectos no suelen disponer del tiempo suficiente para documentar toda la
informacin de los requisitos, o porque no sea viable para el proyecto invertir los
recursos que se necesitan para realizar la documentacin a tal nivel de detalle.
4.4.2.3.4 Interfaz de los requisitos
Es la forma de relacionar a un requisito con la interfaz de un sistema externo el
cual se utilizan para la comunicacin con otros requisitos. Este vnculo debe
utilizar cuando existe una alta dependencia de otros sistemas.
4.4.2.3.5 Requisitos de los requisitos
Es la forma de relacionar a un requisito con otros requisitos de los cuales existe
cierta dependencia. Este tipo de informacin siempre debera mantenerse
actualizada
4.4.2.3.6 Requisitos de la arquitectura
Es la forma de relacionar los requisitos con los subsistemas donde estos requisitos
son implementados. Este tipo de trazabilidad cobra importancia cuando en un
mismo proyecto existen varios equipos de trabajo desarrollando los diferentes
subsistemas.
4.4.2.3.7 Requisitos de diseo
Es la forma de relacionar a un requisito con un componente especfico del
sistema, el cual es usado para implementar el requisito. Este componente puede
ser software o hardware.
Es importante clasificar los requisitos en los diferentes componentes siempre y
cuando el sistema sea complejo o critico o contenga diversos componentes con
una funcionalidad que no sea siempre la misma.
Este tipo de trazabilidad es utilizada para asegurar que todos los requisitos sean
implementados en el sistema. As, como para asignar el desarrollo de los
componentes crticos a las personas idneas.
46
4.4.2.3.8 Requisitos para pruebas

Este vnculo ayuda a priorizar las pruebas. De forma que cuando un cambio en los
requisitos del sistema se lleva a cabo, los casos de prueba afectados pueden ser
identificados con los vnculos entre las pruebas y requisitos.
4.4.2.4 Tcnicas para la trazabilidad de requisitos
Comentario de las tcnicas que se van a emplear, En la actualidad existen varias
tcnicas para llevar a cabo la trazabilidad de requisitos. Las siguientes sub
secciones describen algunas de estas tcnicas.
4.4.2.4.1 Listas de trazabilidad
Las listas de trazabilidad son una simplificacin de la tabla de trazabilidad, segn
la descripcin de cada requisito, una o ms listas son mantenidas para asociar a
los requisitos. La figura 7 describe la lista de trazabilidad, la cual es una lista de
relaciones que pueden ser implementadas como texto o como tablas. Estas tablas
describen las dependencias entre requisitos, pueden haber tantas listas como
cada tipo de trazabilidad requerida. La desventaja de utilizar las listas de
trazabilidad en comparacin de la matriz de trazabilidad, es que implementar la
trazabilidad hacia atrs resulta ser compleja. En la siguiente figura26 se ilustra un
ejemplo de las listas de trazabilidad
Figura 7. Ejemplo de una lista de trazabilidad

De esta lista resulta sencillo establecer que el requisito R1 depende de los
requisitos R3 y R4, pero con esta tcnica el proceso de trazabilidad se empezara
a dificultar, s se quiere conocer los otros requisitos de los cuales depende R1
indirectamente como lo son R5 y R6, puesto que se tendra que recorrer la tabla
en su totalidad.
26 Ibid
47
4.4.2.4.2 Automatizacin de los enlaces de trazabilidad

Significa que los requisitos son almacenados en una base de datos y los enlaces
de trazabilidad son grabados en la base de datos mediante uno o ms campos
adicionales. Estos campos deben contener informacin que facilite la trazabilidad
como por ejemplo del tipo de trazabilidad hacia adelante y hacia atrs. Cuando los
requisitos son administrados a travs de una base de datos, se facilita mantener la
trazabilidad entre un requisito y un grupo abstracto de requisitos.
4.4.2.4.3 Matriz de trazabilidad
Figura 8. Ejemplo de una matriz de trazabilidad
Fuente: Desarrollo de un sistema para la gestin de artculos deportivos. Csar

Lpez Rodrguez
Una matriz de trazabilidad es una tabla de referencias cruzadas en la que se
relacionan los tems de las columnas con los tems de las filas. Su fin es hacer un
seguimiento a los requisitos, los diferentes tipos de requisitos y de elementos que
48
compongan el proyecto. Tambin puede ser utilizada para verificar el cumplimiento

de las necesidades del proyecto. Cada punto de interseccin de los elementos
verticales con los horizontales de la matriz indica que existe un tipo de relacin
bien sea de un nivel mayor de detalle, de dependencia o de limitacin.
En la figura 6 se ilustra un ejemplo de una matriz de trazabilidad, la cual hace
parte del proyecto Desarrollo de un sistema para la gestin de artculos
deportivos27 que tiene como objetivo mostrar un ejemplo de desarrollo de
software basado en la metodologa RUP.
Lo que pretende llevar a cabo este trabajo de grado, es realizar el proceso de
trazabilidad a travs de una tcnica que involucre tanto el uso de colores para
indicar la relacin existente entre los tems trazados, como el uso del mapa
conceptual para poder obtener una contextualizacin completa del proyecto. En
las figuras de las interfaces Panel de Trazabilidad entre elementos y ejemplo de
configuracin del nivel 1, Panel de Trazabilidad entre elementos y ejemplo de
configuracin del nivel 2 y Panel de Trazabilidad entre elementos y ejemplo de
visualizacin de la trazabilidad se hace una descripcin ms detallada de cmo
se lleva a cabo el proceso de trazabilidad propuesto.
4.5
PLAN DE ADMINISTRACIN DE REQUISITOS
El propsito del plan de administracin de requisitos es garantizar que el cliente y
el equipo del proyecto tienen una comprensin en comn de cules son los
requisitos en los que se fundamenta el proyecto. En este plan tambin se
describen las configuraciones de los mecanismos de control que sern usados
para medir, comunicar, control de cambios, trazabilidad y dems actividades
consideradas necesarias en el proyecto para administrar los requisitos.28
El documento final del plan depender de las guas y/o estndares con las que se
realice dicha configuracin.29
27 Csar Lpez Rodrguez. Desarrollo de un sistema para la gestin de artculos deportivos

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/index.html
28 RUP, Rational Unified Process. Rational software corporation requirements management plan
http://rup.hops-fp6.org/process/artifact/ar_ratgl.htm

29 Ludwig Consulting Services, Introduction to Requirements Planning
http://www.jiludwig.com/Requirements_Management.html
49
El formato que utilizado en las interfaces donde se configuran las plantillas: Plan
de administracin de requisitos, es la plantilla empleada en la metodologa RUP, a
la cual se le hicieron modificaciones para realizar la especificacin de requisitos
segn el estndar IEEE-STD-830-1998.
4.6
ROLES EN LOS PROCESOS DE LA INGENIERA DE REQUISITOS
En los procesos de la ingeniera de requisitos, al igual que en el resto de procesos
de un proyecto de software es necesario contar con una gua que permita la
asignacin de actividades de acuerdo al perfil profesional exigido por el tipo de
proyecto. La siguiente lista de actividades se categorizan por el tipo de role segn
la metodologa RUP30.
4.6.1 Analista
El role analista se compone por el conjunto de roles principalmente involucrados
en la obtencin y la investigacin de requisitos. Este conjunto de roles son:
4.6.1.1
Analista del proceso de negocio
El role analista del proceso de negocio es el responsable de la arquitectura del

negocio contorneando y delimitando la organizacin que es modelada; por
ejemplo, establecer los actores y casos de uso del negocio y la coordinacin entre
ellos.
30 Rational Unified Process. Rational Software Corporation.

http://www.ts.mah.se/RUP/RationalUnifiedProcess/index.htm
50
Figura 9. Business- process analyst role
Fuente31: Roles and activities. Rational Software Corporation.

4.6.1.2 Diseador del negocio
El diseador del negocio detalla la especificacin de una parte de la organizacin
describiendo el flujo de trabajo (Workflow) de uno o varios casos de uso del
negocio. Este rol especifica los trabajadores del negocio y las entidades de
negocio necesarios para realizar un caso de uso del negocio y distribuye el
comportamiento del caso de uso del negocio a stos. El diseador del negocio
define las responsabilidades, las operaciones, las cualidades, y las relaciones de
uno o varios trabajadores del negocio y entidades de negocio.
31 Roles and activities. Rational Software Corporation.

51
Figura 10. Business designer role

4.6.1.3 Revisor del modelo de negocio
Figura 11. Business-model reviewer role

El revisor del modelo de negocio participa en las revisiones formales del modelo
del caso de uso del negocio y del modelo del objeto del negocio.
4.6.1.4 Revisor de requisitos
El revisor de los requisitos planea y conduce la revisin formal del modelo del caso
de uso.
32 Ibid

33 Ibid
52
Figura 12. Requirements reviewer role

4.6.1.5 Especificador de requisitos
Figura 13. Requirements specifier role

El especificador de requisitos detalla la especificacin de una parte de la
funcionalidad del sistema describiendo el aspecto de los requisitos de uno o varios
casos de uso y otros requisitos de soporte del software. El especificador de
requisitos puede tambin ser responsable de un conjunto de casos de uso, y
mantiene la integridad de ese conjunto. Se recomienda que el especificador de los
requisitos responsable de un conjunto de casos de uso sea tambin responsable
de sus casos de uso y actores contenidos.
34 Ibid

35 Ibid
53
4.6.1.6 Analista del sistema.

El analista del sistema conduce y coordina los requerimientos y los Casos de Uso
modelando y delimitando la funcionalidad del sistema y delimitando el sistema; por
ejemplo, estableciendo que actores y casos de uso existen y cmo interactan.
Figura 14. System analyst role

4.6.1.7 Analista de pruebas
El rol analista de pruebas es responsable inicialmente de identificar y
posteriormente de definir las pruebas requeridas, de supervisar la cobertura de la
prueba y de evaluar la calidad total experimentada al probar los elementos de
prueba. Este papel tambin implica el especificar los datos de prueba requeridos y
el evaluar el resultado de la prueba conducida en cada ciclo de la prueba. Este
papel tambin se refiere a veces como el diseador de pruebas o considerado
parte del rol verificador. Este rol es responsable de:
Identificar los elementos de prueba que se evaluarn por el esfuerzo de la
prueba
Definir las pruebas apropiadas requeridas y cualquier dato de prueba
asociado
Recopilar y manejar los datos de prueba
Evaluar el resultado de cada ciclo de prueba.
36 Ibid
54
Figura 15. Test analyst role

4.6.1.8 Diseador de interfaz de usuario
Figura 16. User-interface designer role
37 Ibid
38 Ibid
55
El diseador de la interfaz de usuario conduce y coordina los prototipos y el diseo

de la interfaz de usuario, por ejemplo:
Capturando requisitos de la interfaz de usuario, incluyendo requisitos de
usabilidad
Construyendo prototipos de Interfaces de usuario
Implicando a otros stakeholders acerca de la IU, tales como usuarios
finales, en revisiones de la utilidad y sesiones de prueba de uso.
Repasando y proporcionando el feedback apropiado en la implementacin
final de la IU, segn lo creado por otros desarrolladores; es decir,
diseadores e implementadores.
4.6.2 Desarrollador
El role desarrollador se compone por el conjunto de roles principalmente
involucrados en el diseo y desarrollo del software. Este conjunto de roles son:
4.6.2.1 Diseador de cpsula
Figura 17. Capsule designer role

El rol diseador de cpsula centra su atencin en asegurar que el Sistema pueda
responder a los eventos de una manera oportuna de acuerdo a los requisitos. El
principal vehculo para solucionar estos problemas es el artefacto Cpsula (Una
cpsula es un patrn de diseo especfico que representa un hilo de control
encapsulado en el sistema).
39
Ibid
56
4.6.2.2 Revisor de cdigo

El rol revisor de cdigo asegura la calidad del cdigo fuente y planea y conduce
revisiones de cdigo fuente. El revisor de cdigo es responsable de cualquier
feedback de la revisin realizada.
Figura 18. Code reviewer role

4.6.2.3 Diseador de la base de datos
Figura 19. Database designer role.

El rol diseador de la base de datos define las tablas, ndices, vistas, constraints,
triggers y otros objetos especficos de la base de datos necesarios para
almacenar, recuperar y eliminar objetos persistentes.
40
Ibid
41
Ibid
57
4.6.2.4 Implementador
Figura 20. Implementer role

El rol implementador es responsable de desarrollar y de probar componentes de
acuerdo con los estndares adoptados del proyecto para la integracin en
subsistemas ms grandes. Cuando los componentes de prueba, tales como
drivers o partes se deben crear para apoyar la prueba, el implementador es
tambin responsable de desarrollar y de probar los componentes de prueba y los
subsistemas correspondientes.
4.6.2.5 Integrador
Los implementadores entregan sus componentes probados dentro de un espacio
de trabajo de integracin, mientras que los integradores los combinan para
producir una estructura. Un integrador es tambin responsable de planear la
integracin, que ocurre en los niveles del subsistema y de sistema con cada uno
teniendo un espacio de trabajo separado de integracin. Los componentes
probados son entregados desde un espacio de trabajo privado de desarrollo
dentro de un espacio de trabajo de integracin del subsistema, mientras que la
implementacin de los subsistemas integrados se entregan del espacio de trabajo
de integracin del subsistema hacia el espacio de trabajo de la integracin del
sistema.
42
Ibid
58
Figura 21. Integrator role

4.6.2.6 Arquitecto de software
Figura 22. Software architect role
43
Ibid
44
Ibid
59
El rol Arquitecto de software conduce y coordina las actividades y los artefactos

tcnicos a travs del proyecto. El Arquitecto de Software establece la estructura
total para cada visin arquitectnica: la descomposicin de la vista, la agrupacin
de elementos, y las interfaces entre agrupaciones mayores. Por lo tanto, en
contraste con otros roles, la visin del Arquitecto de Software es ms amplia en
comparacin con otras.
4.6.2.7 Revisor de la arquitectura
El rol Revisor de la arquitectura planea y conduce las revisiones formales de la
arquitectura del software en general.
Figura 23. Architecture reviewer role

4.6.2.8 Revisor de diseo
El rol revisor de diseo planea y conduce las revisiones formales del Modelo de
diseo.
Figura 24. Design reviewer role
45
Ibid
46
Ibid
60
4.6.2.9 Diseador
Figura 25. Designer role

El rol Diseador define las responsabilidades, las operaciones, los atributos, y las
relaciones de una o varias clases y determina cmo sern ajustadas al ambiente
de implementacin. Adems, el rol diseador puede tener la responsabilidad de
unos o ms paquetes de diseo, o de diseo de subsistemas, incluyendo
cualquiera contenido por los paquetes o los subsistemas.
4.6.2.10
Diseador de pruebas
Es responsable de las actividades bsicas de ejecucin de pruebas, que implica el
conducir las pruebas necesarias y el registrar los resultados de aquello que
prueba. Esto cubre:
Identificar la implementacin ms apropiada para una prueba efectuada
Implementar pruebas individuales
Crear y ejecutar las pruebas
Registrar los resultados verificar la ejecucin de la prueba
Analizar y recuperar errores de ejecucin.
47
Ibid
61
Figura 26. Test designer role

4.6.3 Profesional de pruebas
La categora de profesional de pruebas, clasifica los roles relacionados con las
pruebas. Cabe aclarar que existen roles relacionados con esta disciplina que no
estn en esta categora, debido a las funciones adicionales que desempean.
4.6.3.1 Verificador
Es responsable de las actividades bsicas de ejecucin de pruebas, que implica el
conducir las pruebas necesarias y el registrar los resultados de aquello que
prueba. Esto cubre:
Identificar la implementacin ms apropiada para una prueba efectuada
Implementar pruebas individuales
Crear y ejecutar las pruebas
Registrar los resultados verificar la ejecucin de la prueba
Analizar y recuperar errores de ejecucin.
48
Ibid
62
Figura 27. Tester role

4.6.4 Administrador
La categora de administrador, clasifica los roles involucrados principalmente en la
administracin y la configuracin de los procesos de la ingeniera de software.
4.6.4.1 Administrador de control de cambios.
Figura 28. Change control manager role

49
Ibid
63
El rol encargado del control del cambio supervisa el proceso de control del cambio.
Este rol es desempeado por un tablero de control de configuracin (o cambio)
(Configuration Control Board CCB) y consta generalmente de representantes de
todas las partes interesadas, incluyendo clientes, desarrolladores, y usuarios. En
un proyecto pequeo, un solo miembro del equipo, como el encargado de proyecto
o el arquitecto del software, puede desempear este papel.
4.6.4.2 Administrador de configuracin

Figura 29. Configuration manager role
El encargado de la configuracin proporciona la infraestructura y el ambiente

completo de la gerencia de configuracin (CM) al equipo de desarrollo del
producto. La funcin del CM es la de apoyar la actividad del desarrollo del
producto de modo que los desarrolladores y los integradores tengan espacios de
trabajo apropiados para construir y para probar su trabajo, y de modo que todos
los artefactos estn disponibles para la inclusin en la unidad de despliegue
cuando sea necesario. El encargado de la configuracin tambin tiene que
asegurarse de que el ambiente del CM facilite la revisin del producto, y las
actividades de seguimiento de los cambios y defectos. El encargado de la
configuracin es tambin responsable de escribir el plan del CM y de divulgar la
estadstica del progreso basada en las solicitudes de cambio.
50
Ibid
51
Ibid
64
4.6.4.3 Administrador de desarrollo

Este rol planea el paso del producto a la comunidad de usuarios al igual que los
documentos asociados.
Figura 30. Deployment manager role

4.6.4.4 Ingeniero de procesos
El rol ingeniero de procesos es responsable del proceso de desarrollo de software.
Esto incluye configurar el proceso antes del inicio del proyecto y continuamente
mejorar el proceso durante el desarrollo del proyecto.
Figura 31. Process engineer

52
Ibid
53
Ibid
65
4.6.4.5 Administrador de proyecto

El rol administrador de proyecto se encarga de asignar recursos, priorizar,
coordinar interacciones con los clientes y los usuarios, y generalmente mantiene al
equipo de proyecto centrado en el objetivo correcto. El encargado de proyecto
tambin establece un sistema de las prcticas que aseguran la integridad y la
calidad de los artefactos del proyecto.
Figura 32. Project manager role
4.6.4.6 Revisor de proyecto

El rol revisor de proyecto es responsable de evaluar la planificacin del proyecto y
las evaluaciones de proyecto en los puntos de revisin importantes en el ciclo de
vida del proyecto. Estos son hechos importantes de revisin, ya que marca puntos
en los que puede ser cancelado si el proyecto de planificacin es insuficiente o si
el progreso es inaceptable
54
Ibid
66
Figura 33. Project reviewer role

4.6.4.7 Administrador de pruebas
Figura 34. Test manager role

El rol de administrador de pruebas tiene la responsabilidad general para el xito de
las pruebas. El papel consiste en la promocin de calidad y de pruebas, la
planificacin y gestin de recursos, y la resolucin de los problemas que impidan
la prueba. Esto incluye:
Negociar el propsito y los resultados en curso de las pruebas.
55
Ibid
56
Ibid
67
Velar por la adecuada planificacin y gestin de los recursos de prueba

Evaluar el progreso y la eficacia de la prueba.
Abogar el nivel adecuado de calidad para la resolucin de defectos
importantes.
Abogar un nivel apropiado de pruebas enfocado al proceso de desarrollo
del software.
4.6.5 Adicionales
En la categora de roles adicionales estn los roles que implican apoyo u otros
roles que participan en el proyecto.
4.6.5.1 Course developer
Este rol, desarrolla el material del entrenamiento para ensear a usuarios cmo
utilizar el producto. Esto incluye crear las diapositivas, notas del estudiante,
ejemplos, clases particulares, y as sucesivamente para realzar la comprensin de
los usuarios del producto.
Figura 35. Course developer role

4.6.5.2 Artista grfico
El artista grfico crea las ilustraciones del producto que son incluidas como parte
del empaquetado del producto.
57
Ibid
68
Figura 36. Graphic artist role

4.6.5.3 Stakeholder
El rol Stakeholder se define como cualquier persona que sea afectada
materialmente por el resultado del proyecto. Solucionar con eficacia cualquier
problema complejo implica el satisfacer las necesidades de un grupo diverso de
stakeholders. Tpicamente, los stakeholders tendrn diversas perspectivas del
problema y diversas necesidades que se deben tratar para la solucin. Muchos
stakeholders son usuarios del sistema. Otros stakeholders son solamente usuarios
indirectos del sistema o son solo afectados por los resultados del negocio que el
sistema influencia. Una comprensin de quienes son los stakeholders y sus
necesidades particulares son elementos dominantes al desarrollar una solucin
eficaz.
Cliente o representante del cliente

Usuario o representante del usuario
Inversionista
Accionista
Encargado de la produccin
Comprador.
4.6.5.4 Administrador de sistema

El rol administrador de sistema mantiene el entorno de desarrollo, tanto de
hardware como de software, administracin de sistemas, seguridad, etc. En las
grandes organizaciones, las personas asignadas a esta funcin por lo
58
Ibid
69
general pertenecen a un grupo de recursos fuera del proyecto, y ser responsable

de apoyar el entorno de desarrollo en mltiples proyectos.
4.6.5.5 Escritor tcnico

El escritor tcnico produce el material de ayuda del usuario final tal como guas del
usuario, textos de ayuda, notas del lanzamiento, etc.
Figura 37. Technical writer role

4.6.5.6 Especialista de herramientas
El especialista de herramientas es responsable de los instrumentos de apoyo en el
proyecto. Esto incluye seleccionar y adquirir las herramientas. El especialista de
herramienta tambin configura herramientas y verifica que funcionen
correctamente.
59
Ibid
70
Figura 38. Tool specialist role

4.6.5.7 Cualquier role
Cualquier rol identificado en RUP, da todos los privilegios de acceso, tambin
puede enviar peticiones de cambio y modificar las peticiones de cambio que l
haya creado.
Figura 39. Any role.
60
Ibid
61
Ibid
71
5 METODOLOGA DE SISTEMAS BLANDOS: MODELO DE

PETER CHECKLAND
La metodologa de sistemas blandos de Peter Checkland, es una tcnica
cualitativa que se puede utilizar para aplicar los sistemas estructurados a
situaciones poco estructuradas o difusas. Es decir, La SSM (Soft Systems
Methodology o en espaol Metodologa de Sistemas Blandos) es un enfoque para
la solucin de problemas en los cuales no resulta claro o no existe consenso sobre
el objetivo que se debe conseguir, pero s existe una necesidad sentida de hacer
algo para mejorar la situacin.
Peter Checkland desarroll esta metodologa con el propsito de analizar
problemas en los cuales hay una actividad con un alto componente social, poltico
y humano. Esto distingue el SSM de otras metodologas que se ocupan de los
problemas duros que estn a menudo ms orientados a la tecnologa. La SSM
aplica los sistemas estructurados al mundo de las organizaciones humanas,
resultando til para la describir situaciones complejas.
En esta metodologa se asume que cada individuo ve al mundo de manera
diferente. Visiones del mundo diferentes inevitablemente llevan a comprensiones y
evaluaciones distintas de cualquier situacin, lo cual lleva a su vez a ideas
diferentes para la accin propositiva. Estas ideas no necesariamente opuestas
entre ellas (generalmente hay probabilidad de algunos traslapes), pueden ser
suficientemente diferentes y constituir un hecho crtico al decidir en un curso de
accin. En la figura 40 se muestra un resumen de la metodologa por medio de un
mapa conceptual donde se muestra en cual situacin se puede aplicar y en qu
consiste.
Lo que brinda SSM es llegar a describir un problema que an no haya sido
descrito correctamente o que su objetivo sea difuso, pero que a su vez es claro en
que hay algo que se podra hacer para mejorarlo. Como la obtencin de requisitos
es de carcter social se pueden tener diferentes puntos de vista de lo que se
debera de hacer, bien sea porque se desconozcan las necesidades reales por las
que se inicia el proyecto o que no haya en el proyecto un consenso de cul sera
la solucin que mejor satisfaga las necesidades a abordar por el proyecto.
72
Figura 40. Mapa conceptual de la SSM
Fuente62: Blog Sistemigramas.

62 Blog Sistemigramas, Enfoque Sistmico en Ingeniera.
http://cmapspublic.ihmc.us/rid=1H5VT7529-1Y35B8V-
81C/SSM%20Metodologia%20de%20Sistemas%20Suaves.cmap
73
La descripcin de la historia y la filosofa de la metodologa de sistemas blandos

que se realiza a continuacin han basado en una clase impartida por la ingeniera
Mara Paz Acosta63:
5.1
HISTORIA
Surge en los aos 70s y se desarrolla en los aos 80s, cuando Peter Checkland
prueba la metodologa de sistemas duros, aplicada a situaciones de desorden
directivo ms que a los llamados problemas estructurados, tratando de comprobar
si los sistemas duros eran apropiados para emplearlos en situaciones de sistemas
blandos.
Cuando inicia su estudio se da cuenta que el enfoque de sistemas duros no era
aplicable en situaciones donde no haba objetivos definidos. Por lo que inici un
programa de investigacin, para probar, desarrollar y perfeccionar el enfoque en
las organizaciones reales, trabajando en conjunto con la Universidad de
Lancaster.
Fue as como el enfoque inicial cambi para adecuarse y enfrentar la mayor
complejidad y ambigedad de los problemas que se presentan en la gestin y
administracin, a diferencia de lo que ocurre en los problemas que enfrenta la
ingeniera. Lo que finalmente surgi despus de este proceso, fue un tipo de
enfoque e diferente conocido como la Metodologa de los Sistemas Suaves.
5.2
FILOSOFIA DE LA SSM
La SSM, parte de que las situaciones de los problemas surgen cuando la gente
tiene una pluralidad de puntos de vistas en una misma situacin. Por tanto la SSM
se centra en responder: Qu debera hacerse?. Para estola SSM emplea cuatro
principios, estos son: aprendizaje, cultura, participacin y los dos modos de
pensamientos. La SSM articula un proceso de investigacin, es un sistema de
aprendizaje que emplea una accin til en un continuo ciclo. El aprendizaje es
sobre la percepcin y evaluacin de las partes del flujo antes de decidir y tomar
acciones, los cuales se vuelven una parte del flujo con nuevas percepciones,
evaluaciones y acciones emergentes. El aprendizaje, entonces, es un ciclo el cual
no tiene principio ni fin.
63 ACOSTA QUINTANA, Mara Paz. INSTITUTO TECNOLGICO DE SONORA Materia: Ingeniera de Sistemas III
UNIDAD I. METODOLOGA DE SISTEMAS SUAVES DE Checkland
ivan_1.tripod.com/sitebuildercontent/sitebuilderfiles/metodologiadesistemassuaves.doc
74
En la SSM, los avances son decididos por trminos de importancia dados por los
involucrados, factibilidad cultural (restricciones que se pueden hallar) y
sistmicamente convenientes (pensamiento esenciales de sistemas que no deben
ser violados).
La factibilidad cultural puede tomarse como la caracterstica clave de la SSM. La
idea de la cultura gua al usuario de la SSM, a exponer categricamente las
restricciones sociales y organizacionales en el mundo real con cambios
potenciales y que deben reunirse por medio de la intervencin.
El fundamento interpretativo de la SSM se basa en el principio de participacin,
sin la participacin de los involucrados, cualquier aplicacin de la SSM debe ser
invalidada en sus propios trminos.
El proceso de la SSM distingue dos modos de pensamiento: el pensamiento de
sistemas abstracto e ideal, y especficamente relacionados con el contexto del
pensamiento del mundo real. El primero es una corriente de investigacin basado
en la lgica, el otro una corriente de investigacin basada en la factibilidad cultural.
5.3
PROCESO DE LA METODOLOGA
El modelo de la SSM es empleado en contextos pluralistas, donde hay una
compatibilidad de intereses donde los valores y las creencias de los participantes
divergen y donde todava el compromiso y la participacin genuina son posibles.
La figura 41, ilustra la metodologa de siete fases las cuales no representan un
proceso al que puede seguirse de principio a fin. Por lo contrario este proceso
puede tener que ser repetido varias veces o realizado en diferente orden, antes de
que un acomodamiento razonable o acuerdo pueda ser alcanzado. La lnea
divisora representa el lmite entre las actividades en el mundo real y las
actividades relacionadas con el uso de conceptos de sistemas empleados para
estructurar la percepcin sobre el mundo real. Despus de la figura se mencionan
cada una de las siete fases de la metodologa descrita por Peter Checkland en el
libro Pensamientos de sistemas, prcticas de sistemas64:
64 CHECKLAND, Peter. Pensamiento de sistemas, prctica de sistemas.

http://es.scribd.com/doc/43942469/Check-Land
75
Figura 41. Los 7 estadios de la SSM
Fuente65: Blog Sistemigramas, Enfoque Sistmico en Ingeniera.

5.3.1 Estadio 1: investigar la situacin problema no estructurado
La situacin no estructurada, consiste en la delimitacin del sistema objeto del
estudio y en la definicin del entorno. Durante el estadio se observan sucesos, sin
embargo no se tiene claro la estructura ni los procesos del sistema, la descripcin
de la situacin problemtica se limita a una declaracin general sin ajustar a
trminos de sistemas. En este estadio se rene toda la informacin disponible, se
identifica a los participantes en la situacin problemtica y posiblemente se
encuentren los diferentes puntos de vista sobre la situacin en estudio.
5.3.2 Estadio 2: expresar la situacin del problema
El objetivo de este paso es expresar la situacin problemtica investigada en el
estadio 1 De forma grfica se establece la estructura, proceso y la relacin entre
estructura y proceso de la situacin que se est estudiando. La herramienta
empleada para este propsito se denomina rich picture o imagen enriquecida, la
65 65 Blog Sistemigramas, Enfoque Sistmico en Ingeniera.
http://cmapspublic.ihmc.us/rid=1H5VT7529-1Y35B8V-
81C/SSM%20Metodologia%20de%20Sistemas%20Suaves.cmap
76
cual, permite la seleccin de uno o ms puntos de vista a partir de los cuales se va

profundizar el estudio de la situacin problemtica. Adems la rich picture permite
describir principalmente dos aspectos de la situacin problemtica:
Estructura: Se puede examinar en trminos de distribucin fsica, jerarqua

de poder, estructura de reporte y del patrn de comunicaciones, tanto
formal como informal
Proceso: Se puede examinar en trminos de las actividades bsicas
requeridas para decidir hacer algo, para llevar eso a cabo, para monitorear
qu tan bien est hecho y sus efectos externos y para implementar la
accin correctiva.
5.3.3 Estadio 3: seleccionar una visin de la situacin y producir una

definicin raz
El tercer estadio permite conocer la situacin problemtica y la bsqueda de
alternativas de solucin pertinentes, las cuales indican qu cambios se consideran
necesarios en el mundo real para mejorar la situacin percibida. Bajo un enfoque
amplio y profundo, la alternativa de solucin es nombrada como definicin raz o
definicin bsica. Cada definicin raz representa una imagen del mundo
particular, las cules se emplean para verificar la estructura del pensamiento de
los observadores.
El objeto del estadio es tener definiciones races que brinden a futuro la posibilidad
de realizar cambios que sean viables y deseables para el investigador y para los
propietarios de la situacin problemtica.
5.3.3.1 Definicin raz
La definicin raz es la descripcin de lo que el sistema es desde una percepcin
particular. La definicin raz declara qu proceso de transformacin se tiene que
hacer en la realidad; el cual es descrito mediante un grupo de actividades
humanas con un propsito determinado denominado sistema de actividad
humana. Producir una definicin de raz es un proceso progresivo de dos pasos:
Un hecho o una tarea se elige de una visin enriquecida

Se define un sistema para realizar la tarea o para dirigir los hechos.
77
Las definiciones races se escriben como sentencias que efectan una

transformacin, se compone de seis elementos resumidos en la mnemnica
CATWOE por sus siglas en ingls66:
Cliente: es el beneficiario o a quien afecta la actividad del sistema

Actor: Personas que ejecutan una o ms de las actividades que hacen
posible el funcionamiento del sistema
Trasformacin: Es el proceso mediante el cual las entradas se convierten
en salidas
Weltanschauung: Es la opinin del mundo que da sentido y determina al
proceso de la transformacin sea significativo en contexto
Propietario: Cada sistema tiene algn propietario, quien tiene el poder para
comenzar y/o parar el proceso de trasformacin
Restricciones ambientales: Elementos externos al sistema que se toman
como dados y constituyen restricciones para el proceso de trasformacin,
incluye polticas de organizacin as como asuntos legales y de tica.
5.3.4 Estadio 4: confeccin y verificacin de modelos conceptuales

El estadio se inicia con la construccin de un modelo elemental, al que se le puede
dar dos posibles enfoques. Este modelo podra describirse en trminos de su
estado al enumerar los elementos que lo componen, sus condiciones en curso,
sus relaciones con elementos externos que afectan al sistema, y el describir la
condicin de aquellos elementos externos. Alternativamente se podra
proporcionar una descripcin de sistemas al considerar un sistema como una
entidad que recibe algunas entradas y genera algunas salidas; el sistema mismo
transforma las entradas en las salidas.
El modelo debe representar las principales actividades de la definicin raz,
teniendo en cuenta que, cualquier definicin raz se puede considerar como una
descripcin de un grupo de actividades humanas con propsitos determinados y
concebidas como un proceso de transformacin. En el momento de la
construccin del modelo se debe mostrar las actividades necesarias para lograr la
transformacin descrita en la definicin. La definicin es un reporte de lo que el
sistema es; el modelo conceptual es un reporte de las actividades que el sistema
debe hacer para convertirse en el sistema nombrado en la definicin.
66 MARTNEZ AVELLA, Mario Ernesto. Ideas para el cambio y el aprendizaje en la organizacin: Una
perspectiva sistmica
http://books.google.com.co/books?id=VU2wxjDcNBUC&pg=PA58&lpg=PA58&dq=sigla+catwoe&source=bl&
ots=FpBQyhGp0m&sig=lNg5jhZeFzupdrzXyD1eQ2CLm3g&hl=es&sa=X&ei=r_2zT4K8D4mi8QTW75nqDw&ve
d=0CF8Q6AEwBA#v=onepage&q=sigla%20catwoe&f=false
78
El modelo conceptual se puede escribir como grfico dirigido, similar a un

diagrama PERT. Los nodos en el grfico son actividades que se harn. Estas
actividades se basan en los verbos de la definicin raz. La estructuracin del
sistema se basa en la dependencia lgica. Las dependencias lgicas se muestran
como arcos en el grfico. Un arco en el grfico significa que la actividad de la
fuente es un requisito previo para la actividad de la destinacin. Debido a que el
modelo conceptual es un modelo de un sistema de actividad, sus elementos sern
verbos. La tcnica del modelado consiste en ensamblar la lista mnima de verbos
que describen las actividades que son necesarias en un sistema especificado en
la definicin raz, y en estructurar los verbos en una secuencia de acuerdo a la
lgica. Las actividades ms Importantes del sistema se deben mantener
separadas para mantener la consistencia del nivel de resolucin, es decir, a partir
de las principales actividades de la definicin raz, el modelo se va expandiendo a
niveles de mayor detalle y se detiene a criterio de los involucrados en el proceso.
El resultado final es un grupo estructurado de actividades que la lgica requiere en
un sistema nocional que va a ser el definido en la definicin raz.
5.3.5 Estadio 4a: verificacin del modelo conceptual con un modelo de
sistema formal
El modelo de sistema formal tiene como objetivo ayudar a la construccin de
modelos conceptuales que son en s mismos formales: ellos no son informes de lo
que debiera existir en el mundo real, porque no es en absoluto Intencin de la
metodologa el disminuir la libertad que tengan los sistemas de actividad humana.
El modelo es una combinacin de componentes de administracin que
argumentalmente tienen que estar presentes si desea que un grupo de actividades
incluya un sistema capaz de realizar actividad con propsito. Los componentes del
modelo de verificacin propuesto por Checkland son los siguientes. S es un
"sistema formal" si, y slo si:
i)
S tiene un propsito o misin en curso, en el caso de un sistema suave

esto podra ser una bsqueda constante de algo que finalmente nunca
se pueda lograr. En sistemas ms duros esto es lo que se divide en
"objetivos" o "metas", caracterizadas por ser alcanzables.
ii)
S tiene una medida de desempeo, esta es la medida que seala el

progreso o retroceso del alcance de propsitos o del logro de objetivos.
iii)
S incluye un proceso de toma de decisiones: el sistema puede llevar a

cabo esta accin reguladora basada en los puntos i) y ii).
79
iv)
S tiene componentes que son en s sistemas, que tienen todas las

propiedades de S.
v)
S tiene componentes que interactan, que muestran un grado de

conectividad tal, que los efectos y acciones se puedan transmitir por el
sistema.
vi)
S existe en sistemas ms amplios y/o medios con los cuales interacta.
vii)
S tiene un lmite, que los separa de vi), que se define formalmente como
el rea dentro de la cual el proceso de toma de decisiones tiene poder
para generar accin.
viii)
S tiene recursos, fsicos y, a travs de los participantes humanos,

abstractos, que estn a la disposicin del proceso de toma de
decisiones.
ix)
S tiene alguna garanta de continuidad, no es efmero, tiene estabilidad

a largo plazo, recuperar la estabilidad despus de algn grado de
disturbio. Se podra dar apoyo a esto ltimo desde fuera del sistema;
quiz derive internamente del compromiso de los participantes con i) la
misin.
5.3.6 Estadio 5: comparacin de los modelos conceptuales con la realidad

El estadio de "comparacin" se denomina as porque en l, partes de la situacin
problema analizada en el estadio 2 se examinan a la par de los modelos
conceptuales: esto se debe hacer junto con los participantes interesados en la
situacin problemtica, con el objeto de generar un debate acerca de posibles
cambios que se podran introducir para as aliviar la condicin del problema.
La comparacin es el punto en el cual las percepciones intuitivas del problema se
confrontan con las construcciones de sistemas que el pensador de sistemas
asegura proporcionan una descripcin de la realidad ms general y
epistemolgicamente ms profunda; debajo de las apariencias superficiales. El
80
estadio de comparacin es un medio para mitigar las complejidades de la

realidad. A continuacin se describen cuatro formas para llevar la comparacin67:
Modelamiento de sistemas para abrir un debate acerca del cambio. Este

mtodo para utilizar los modelos conceptuales como una base de
cuestionamiento ordenado en la situacin problemtica siempre ser una
manera posible de avanzar en cualquier estudio.
Reconstruir una secuencia de sucesos del pasado y al comparar lo que

haba sucedido al producirlo con lo que habra sucedido si los modelos
conceptuales pertinentes se hubiesen habilitado de verdad. Esto es
lgicamente una manera satisfactoria para exhibir el significado de los
modelos, y quizs las diferencias de los procesos reales.
Generar preguntas estratgicas acerca de las actividades presentes, ms

que las indagaciones detalladas acerca de los procedimientos; preguntas
tales como: Por qu hacer esto?, ms que: Est esto bien hecho?
Encimamiento de modelo. Despus de terminar la conceptualizacin

basada en la definicin raz elegida, se hace un segundo modelo, esta vez
de lo que existe; este segundo modelo conceptual, el objetivo es redibujar
ese modelo cambiando nicamente donde la realidad difera del modelo
conceptual, esto revela cabalmente el desajuste, que es la fuente de la
discusin del cambio.
5.3.7 Estadio 6: diseo de cambios deseables, viables y factibles

Se detectan los cambios que son posibles llevar acabo en la realidad y en el
estadio siguiente. Estos cambios se detectan de las diferencias emergidas entre el
mundo real, y los modelos conceptuales, se proponen cambios tendientes a
superarlas, dichos cambios deben ser evaluados y aprobado por las personas,
que conforman el sistema humano, para garantizar que sean deseables y viables.
Estos cambios pueden ser de 3 tipos:
Cambio en la estructura: Son los cambios realizados en las partes

estticas del sistema
67 SOCHACKYJ AMARO, Euhen Alexander. Sistema para dar soporte en la generacin del contenido de un
curso aplicando recursos multimedia, caso de estudio curso introductorio.
http://biblo.una.edu.ve/docu.7/bases/marc/texto/t4147.pdf
81
Cambio en el procedimiento: Son los cambios en los elementos

dinmicos del sistema
Cambio en la actitud: Son los cambios en el comportamiento del sistema.
5.3.8 Estadio 7: acciones para mejorar la situacin del problema

La implantacin de cambios, que fueron diseados en la etapa 6, ahora son
implementados, con el propsito de solucionar la situacin problemtica, y el
control de los mismos.
82
6 MAPAS CONCEPTUALES
Un mapa conceptual es una herramienta grfica, utilizada para organizar y
representar el conocimiento, por medio de conceptos significativos
interrelacionados. Ubicando a estos conceptos dentro de temas y subtemas,
obteniendo como resultado una representacin grfica estructurada. En general,
cualquier conocimiento complejo que pueda expresarse verbalmente podr ser
representado en un mapa conceptual, especialmente cuando sea un conocimiento
relacionado con las ciencias humanas y sociales.
El mapa conceptual se usa para mostrar la estructura conceptual de un
conocimiento. Por tanto es un instrumento til para la formacin, ya sea como
actividad de aprendizaje o de evaluacin. Vale aclarar que un mapa conceptual en
el cual las proposiciones son limitadas a representaciones formales (o rgidas) que
puedan ser interpretadas por computadoras, pasa a ser en una red semntica, o
una representacin de tipo RDF o similar.
6.1
ORIGEN DE LOS MAPAS CONCEPTUALES
Los mapas conceptuales fueron desarrollados en 1972 derivados de un proyecto
de investigacin donde nios de primero y segundo grado se les enseaba
conceptos bsicos de ciencias y se les entrevistaba peridicamente a lo largo de
los doce aos de su vida escolar para determinar cmo esta instruccin temprana
influenci su posterior aprendizaje de las ciencias68. En esta investigacin Novak
y su equipo trataron con varias estrategias de evaluacin para monitorear el
aprendizaje de los nios, revisando a profundidad los principios de aprendizaje
Ausbeliano y tambin las ideas constructivistas epistemolgicas.
Las ideas epistemolgicas que fueron consideradas en esta investigacin son: (1)
El universo consiste de objetos y eventos, y la energa se intercambia durante los
eventos. (2) Los conceptos son construidos por los humanos y son regularidades
percibidas o patrones en eventos de objetos o registros de eventos u objetos,
designados con una etiqueta, usualmente una palabra. (3) Dos o ms conceptos
pueden ser enlazados con las palabras apropiadas para formar una declaracin
significativa o proposicin. (4) Los conceptos y las proposiciones son los bloques
de construccin del conocimiento en todos los campos.
68 Novak, J.D. (2005). Results and implications of a 12-year longitudinal study of science concept learning.
Research In Science Education.

83
Los principios de aprendizaje que fueron considerados, basados en las psicologa

cognitiva de Ausubel fueron:69 70 (1) El aprendizaje significativo (en contraste con
el aprendizaje memorstico) es necesario para el desarrollo de un entendimiento
conceptual. El aprendizaje significativo es caracterizado a veces como aprendizaje
profundo o dinmico, (en contraste con el aprendizaje superficial o esttico). (2) El
nuevo aprendizaje se debe construir sobre conceptos y proposiciones previas
relevantes sostenidas por el aprendiz. (3) Al aprendiz se le debe motivar para que
elija aprender significativamente. (4) Se necesitan ayudas apropiadas para
aprender conceptos abstractos, junto con la instruccin didctica apropiada. (5) El
aprendizaje es altamente idiosincrtico y progresa con el tiempo. (6) El
aprendizaje significativo de alta calidad lleva a la construccin de estructuras
conceptuales y proposicionales bien integradas (es decir estructuras cognitivas)
que facilitan mejor el nuevo aprendizaje y la solucin creativa de problemas.
Figura 42. Ideas tericas subyacentes a la construccin y uso de los mapas
conceptuales
Fuente71: CAAS, Alberto y NOVAK, Joseph.

A partir de las anteriores ideas epistemolgicas y principios de aprendizaje, los
grupos de Novak buscaron representar el conocimiento con una estructura
69 Ausubel, D. (1963). The Psychology of Meaningful Verbal Learning. New York: Grune & Stratton.

70 Ausubel, D. P. Educational psychology: A cognitive view, Holt, Rinehart and Winston, Nueva York, 1968.
71 CAAS, Alberto y NOVAK, Joseph. Re-examinando los fundamentos para el uso efectivo de mapas
conceptuales
http://cmap.ihmc.us/Publications/ResearchPapers/Re-ExaminandoLosFundmentos.pdf
84
jerrquica de conceptos y proposiciones, una forma a la que ellos llamaron mapa

conceptual.
En la siguiente figura es un mapa conceptual donde se muestra los componentes
del universo, donde los objetos necesitan para su descripcin hacer uso de un
pensamiento esttico, con lo cual se obtiene un pensamiento memorstico o
superficial y el resultado ser un mapa conceptual descriptivo. A parte de poder
realizarse la descripcin de un objeto, se pueden describir los eventos en los que
los objetos estn implicados. Para llevar a cabo esta descripcin de eventos se
necesita de un pensamiento dinmico para obtener un pensamiento significativo o
profundo y a su vez producir mapas conceptuales explicativos.
En general, los mapas conceptuales que muestran el conocimiento sobre un
acontecimiento requieren un pensamiento profundo y dinmico. Sin embargo, la
mayora de los mapas conceptuales tratan sobre objetos, no sobre
acontecimientos. Pero a travs de una pregunta de enfoque apropiada, y del
cuestionamiento en general, se puede pasar hacia el pensamiento dinmico que
se requiere para construir mapas conceptuales que muestran explicaciones.
El tipo de pensamiento que se aconseja tener para empezar a un construir mapa
conceptual en la herramienta grfica que se propone en este trabajo de grado es
el dinmico, porque mediante este tipo de pensamiento se puede realizar a la vez,
la especificacin de requisitos y ver las relaciones existentes entre ellos mediante
los enlaces. De esta forma se le puede brindar al equipo de desarrollo una
explicacin o descripcin general del sistema en el que se est trabajando.
6.2
ELEMENTOS DE LOS MAPAS CONCEPTUALES
Los elementos bsicos de un mapa conceptual son los conceptos, las palabras
enlace y las proposiciones, los cuales son descritos en detalle a continuacin.
6.2.1 Conceptos
Novak define un concepto72 como una regularidad o patrn percibido en los
acontecimientos u objetos, o registros de acontecimiento u objetos, designados
por una etiqueta. Generalmente los objetos y los acontecimientos son los usados
para describir un concepto, sus definiciones y diferencias son las siguientes:
72 Novak, J. D., & Gowin, D. B. (1984). Learning How to Learn. New York, NY: Cambridge University Press.
http://books.google.com.co/books?hl=es&lr=&id=8jkBcSDQPXcC&oi=fnd&pg=PR9&dq=Learning+How+to+L
earn&ots=nymVvztO35&sig=HdMTYzG_KrZg1UUo3coR1b6acm4#v=onepage&q&f=false

85
6.2.1.1 Los objetos como conceptos

Las palabras son una forma de describir y nombrar conceptos, es decir, se usan
como etiquetas para los conceptos la mayora de las veces es una sola palabra,
aunque a veces puede ser necesario emplear ms de una palabra. 'Perro' o 'rbol'
son ejemplos de palabras que sirven como etiquetas para objetos. Un concepto
tambin puede ser definido como:
Una agrupacin mental de diferentes entidades en una sola categora con base
en alguna similitud subyacente, alguna forma en que todas las entidades son
semejantes, algn ncleo comn que hace que todas sean, en cierto sentido, la
misma cosa.73
En la herramienta grfica cada etiqueta o concepto equivale a un requisito o una

agrupacin de estos, al cual se le puede ingresar la informacin necesaria para
ser administrados durante el proyecto.
6.2.1.2 Los acontecimientos como conceptos

El universo consiste de objetos y acontecimientos. Tanto los objetos como los
acontecimientos son necesarios para representar el conocimiento sobre el
universo y sus contenidos. Usualmente los acontecimientos son interpretados
como sucesos tales como una "fiesta" o una "reunin". Sin embargo, el trmino
acontecimientos incluye cambios de estado tales como mejoras. Por ejemplo,
"aumento en la calidad de la educacin" es un concepto que es un acontecimiento,
como tambin lo son la "adopcin del constructivismo".
Estas dos clases de registros, se diferencian en que el uso de conceptos que son
acontecimientos lleva a mapas conceptuales ms explicativos, mientras que los
conceptos que son objetos llevan a mapas conceptuales ms descriptivos y a
menudo ms bien de clasificacin.
6.2.2 Palabras de enlace
Las palabras de enlace74 se usan para unir dos o ms conceptos con el fin de
formar proposiciones. Un concepto por s solo no necesariamente comunica un
73 FLAVELL, J. H., MILLER, P. H., & MILLER, S. A. (2002). Cognitive development (4th ed.). Upper Saddle River,
NJ: Prentice Hall.
74 CAAS, Alberto J. Qu son las palabras de enlace? desde la perspectiva de los mapas conceptuales
http://cmap.ihmc.us/docs/palabrasdeenlace.html
86
sentido claro e inequvoco. Por ejemplo si alguien dice planta, qu est

comunicando?, si se llegase a tomar fuera de contexto, no se podra decir a cul
de las acepciones de la palabra se estara haciendo referencia.75 Esto debido que
el concepto planta puede tener varios significados, que incluyen "vegetal", "parte
inferior del pie", " planta de un edificio".
Una reduccin de posibles acepciones a un significado particular ocurre como
resultado de conceptos que interactan entre s. Sin embargo, an dentro del
mismo contexto un concepto puede tener diferentes acepciones, por ejemplo, en
el contexto de un edificio, "planta" refirindose a "planta baja" tiene un sentido
distinto que "planta" como diseo del edificio, o el edificio de una planta elctrica.
Por tanto, el contexto basado en la relacin entre conceptos en una afirmacin
ayuda en la seleccin del significado de los conceptos. Por esto, es posible que
escoger las palabras de enlace apropiadas para expresar claramente la relacin
entre dos conceptos sea la tarea ms difcil durante la elaboracin de mapas
conceptuales. Una relacin esttica reduce la incertidumbre en las etiquetas al
conectar los conceptos de una proposicin y la relacin dinmica tiene que ver con
la covariacin entre los conceptos.
6.2.2.1 Relaciones Estticas

Las relaciones estticas entre conceptos ayudan a describir, definir y organizar el
conocimiento para un dominio dado y son fundamentales para crear estructuras
conceptuales jerrquicas.
6.2.2.2 Relaciones Dinmicas

Una relacin dinmica describe la forma en que el cambio en un concepto afecta
el otro concepto.
6.2.3 Proposiciones
Las proposiciones76 son oraciones sobre algn objeto o acontecimiento que
contienen dos o ms conceptos conectados mediante palabras de enlace para
formar una declaracin con sentido.
75 Gibson, J. J. (1979). The Ecological Approach to Visual Perception. Boston: Houghton Mifflin Company.
http://books.google.com/books?id=BJGCuje64FcC&printsec=frontcover&hl=es#v=onepage&q&f=false

76 CAAS, Alberto J. Qu son las proposiciones? desde la perspectiva de los mapas conceptuales
http://cmap.ihmc.us/docs/proposicion.html
87
En la herramienta grfica las proposiciones son las encargadas de expresar la

relacin existente entre dos o ms requisitos.
6.2.3.1 Creacin de proposiciones
En una proposicin, las palabras de enlace expresan la relacin que existe entre
los conceptos vinculados. Al agregar un verbo (tienen o causar) la proposicin se
transforma en una unidad de significado, en una enunciacin que tiene sentido en
s misma y que transmite conocimiento:
Aves tienen Huesos Huecos

Aumento en la Lluvia puede causar Inundaciones.
Cada una de estas proposiciones se puede leer y entender en forma

independiente, aunque el contexto de la proposicin no se enuncie claramente.
Por esta razn, a veces se llaman unidades semnticas
6.3
CARACTERSTICA DE LOS MAPAS CONCEPTUALES
Los elementos de los mapas conceptuales, se organizan grficamente, de tal
manera, que formen las cadenas semnticas. El conocimiento est organizado
lineal y jerrquicamente formando agrupaciones holsticas de forma tal, que
cuando se activa una se activa el resto.
88
Figura 43. Caractersticas de los mapas conceptuales
Fuente77: IRIARTE NAVARRO, Leonel.

Los mapas conceptuales tienen dos caractersticas importantes para facilitar el
pensamiento creativo: la estructura jerrquica que se expresa en un buen mapa
conceptual y la habilidad de buscar y caracterizar nuevos enlaces cruzados. Las
siguientes caractersticas especficas de los mapas conceptuales son las que lo
distinguen de otras herramientas de representacin de conocimiento78:
6.3.1 Estructura Proposicional
En un mapa conceptual, cada concepto consiste del mnimo de palabras
necesarias para expresar el objeto o acontecimiento, las palabras de enlace deben
ser concisas y casi siempre incluyen un verbo. Al construir un mapa conceptual, se
debe tener cuidado de que cada dos conceptos enlazados con sus palabras de
enlace forman una unidad de significado, una oracin corta. En ocasiones, una
77 IRIARTE NAVARRO, Leonel. Revista de Educacin a Distancia RED. Mapas conceptuales y objetos de
aprendizaje
http://www.um.es/ead/red/M2/leonel21.pdf
78 CAAS, Alberto J. & NOVAK, Joseph D.Qu es un mapa conceptual?
http://cmap.ihmc.us/docs/mapaconceptual.html
89
proposicin se extiende a tres o ms conceptos, pero se debe evitar hasta donde

sea posible.
6.3.2 Estructura Jerrquica
Dentro de cualquier dominio de conocimiento, hay una jerarqua de conceptos,
donde los ms generales estn arriba en la jerarqua y los conceptos ms
especficos, menos generales, se encuentran jerrquicamente ms abajo. Los
mapas conceptuales tienden a ser representados como una jerarqua grfica
siguiendo esta jerarqua conceptual. Por esto, los mapas conceptuales tienden a
empezar a leerse desde arriba, progresando hacia abajo.
6.3.3 Pregunta de Enfoque
Una forma de delinear el contexto de un mapa conceptual es definir una Pregunta
de Enfoque, esto es, una pregunta que claramente especifique el asunto que el
mapa conceptual debe tratar de estudiar. Todo mapa conceptual responde a una
pregunta de enfoque, y una buena pregunta de enfoque puede llevar a un mapa
conceptual ms expresivo.
6.3.4 Enlaces Cruzados
Son relaciones o enlaces entre conceptos de diferentes segmentos o dominios del
mapa conceptual. Los enlaces cruzados ayudan a ver cmo un concepto en un
dominio de conocimiento representado en el mapa est relacionado con un
concepto en otro dominio expresado en el mapa.
6.4
ELABORACIN DE UN MAPA CONCEPTUAL
A inicios de los aos setenta en el Departamento de Educacin de la Universidad
de Cornell en los Estados Unidos de Amrica, Ausubel, encabezando un grupo de
psiclogos, present una nueva concepcin terica en el campo de la psicologa
educativa acerca del aprendizaje significativo.
A partir de entonces, y a manera de instrumentar la teora del aprendizaje de
Ausubel, la nocin de mapa conceptual fue desarrollada por un grupo de
psiclogos encabezados por:
Novak y Gowin: para el desarrollo de mapas conceptuales
Buzan: para el desarrollo de mapas mentales.
Ms adelante, en los aos ochenta, surgen otros desarrollos en la misma lnea
tales como:
90
Los de Eden, Jones y Sims: para el desarrollo de mapas cognitivos

Los de Checkland: para el desarrollo de modelos conceptales.
Cada uno de ellos, en sus mbitos especficos ofrecen una solucin a la

necesidad de representar esquemticamente las imgenes mentales que permiten
a un individuo estructurar una situacin especfica.
La siguiente serie de pasos del mtodo definido por Novak & Gowin para la
construccin de mapas conceptuales, han sido retomadas de las actas del I
seminario internacional de innovacin docente en la enseanza superior del
desarrollo rural en Iberoamrica79:
1. Definir el tema o pregunta de enfoque. Los mapas conceptuales que intentan
cubrir ms de una pregunta pueden ser difciles de construir y leer.
2. Una vez que el tema de enfoque ha sido definido, el siguiente paso es
identificar y listar los conceptos ms generales o importantes que estn asociados
con ese tema.
3. A
continuacin, los conceptos se ordenan
jerrquicamente (de
arriba
hacia abajo), pasando de los ms generales e inclusivos a los ms especficos en
la parte inferior, lo que fomenta la representacin explcita de las relaciones
de subsuncin.
4. Una vez que los conceptos clave han sido identificados y ordenados, los
enlaces se agregan para formar un concepto preliminar del mapa.
5. Se aaden las palabras de enlace para describir las relaciones entre los
conceptos.
6. Una vez que el mapa conceptual preliminar ha sido construido, el siguiente
paso es buscar enlaces cruzados, que vinculan los conceptos que se encuentran
en diferentes reas o sub-dominios en el mapa.
79 Actas del I seminario internacional de innovacin docente en la enseanza superior del desarrollo rural
en Iberoamrica
http://www.indirural.ual.es/seminarioDocente/LibroDeActasSeminario1.pdf
91
7. Por ltimo, se revisa el mapa y se realiza cualquier cambio necesario en la

estructura o contenido.
92
DISEO METODOLGICO
7.1
DEFINICIN DE LA HIPTESIS
Podr este anlisis y diseo ser la base para la implementacin de una
herramienta grfica para la gestin del desarrollo y administracin de requisitos
en un proyecto de software?
7.2
TIPO DE ESTUDIO
El tipo de estudio es exploratorio.
7.3
TCNICAS DE INVESTIGACIN
7.3.1 Observacin
Por medio de la observacin, se identificarn las deficiencias, tendencias e
impacto de los gestores de requisitos utilizados en la gestin de proyectos
orientados al desarrollo de software, as como software basado en la aplicacin de
las metodologas, en las cuales tambin se va a desarrollar este proyecto de
grado, esto facilitar el anlisis y diseo del prototipo.
93
7.3.2 Variables
Figura 44. Variables
Fuente: Los autores

94
CAPTULO 3.
DESARROLLO DE LOS OBJETIVOS
95
8 ANLISIS Y DISEO DEL MDULO DESARROLLO DE

REQUISITOS
El enfoque que tiene este primer mdulo es brindar una opcin al equipo de
desarrollo cuando realice el proceso de identificacin de requisitos, mediante la
implementacin de la metodologa SSM de Peter Checkland y as establecer el
qu se va hacer en el proyecto de software. En este mdulo estn los anlisis y
diseos de las herramientas necesarias para la elaboracin de dibujos, en los
cuales se pueda expresar o bien sea, una situacin problemtica o un modelo
conceptual segn la metodologa SSM de Peter Checkland.
8.1
REQUISITOS FUNCIONALES
Los siguientes requisitos funcionales describen las funcionalidades del mdulo:
Tabla 1.
Requisito funcional: El sistema permite administrar la

imagen enriquecida.
Id
Requerimiento
de RF08 El sistema permite administrar la

imagen enriquecida.
Descripcin
El sistema permite al usuario crear un

documento, abrir y guardar un archivo de
imagen enriquecida.
Entradas
Opcin seleccionada por el usuario.
Salidas
El sistema crear, abrir o guardar un

documento de imagen enriquecida.
Proceso
Acceder a la interfaz del editor grfico

Acceder al men archivo Acceder a la
seccin Documento Seleccionar entre las
opciones abrir, nuevo y guardar.
Precondiciones
Abrir el gestor grfico.
Efectos Colaterales
El sistema realizara la accin elegida por el

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
96
Tabla 2.
Requisito funcional: El sistema permite insertar figuras.
Id
Requerimiento
de
RF09 El sistema permite insertar figuras.
Descripcin
El sistema permite al usuario agregar figuras

prediseadas e imgenes del proyecto.
Entradas
Figuras e imgenes.
Salidas
Se dibujan las figuras en el rea de trabajo.
Proceso

Acceder al men herramientas Acceder a
la seccin figuras Seleccionar imagen a
insertar.
Precondiciones
Tener abierta una imagen enriquecida.
Efectos Colaterales
El sistema dibujara las imgenes insertadas

en el rea de trabajo.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 3.
Requisito funcional: El sistema permite utilizar las

herramientas de dibujar.
Id
Requerimiento
de RF10 El sistema permite

herramientas de dibujar.
utilizar
las
Descripcin
El sistema permite al usuario utilizar

herramientas para dibujar como son dibujar
con lpiz, relleno, tipo, grosor y texto.
Entradas
Imgenes.
Salidas
Se dibujan las figuras en el rea de trabajo.
Proceso

la seccin dibujar Seleccionar herramienta
a utilizar.
Precondiciones
Efectos Colaterales
El sistema mostrara en el rea de trabajo el

resultado de la herramienta utilizada por el
usuario.
97
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 4.
Requisito funcional: El sistema permite utilizar las opciones

de edicin.
Id
Requerimiento
de RF11 El sistema permite utilizar las opciones

de edicin.
Descripcin
El sistema permite al usuario utilizar opciones

de edicin como son pegar, copiar, cortar,
seleccionar, girar, acercar y alejar.
Entradas
Opcin utilizada por el usuario.
Salidas
Se aplicaran la opcin utilizada por el usuario.
Proceso

la seccin edicin Seleccionar herramienta
a utilizar.
Precondiciones
Efectos Colaterales

resultado de la opcin utilizada
por el
usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 5.
Requisito funcional: El sistema permite utilizar las opciones

de paleta de colores.
Id
Requerimiento
de RF12 El sistema permite utilizar las opciones

de paleta de colores.
Descripcin
El sistema permite al usuario utilizar opciones

de colores
como son escoger un color
primario y uno secundario de una paleta de
colores.
Entradas
Seleccionar
secundario.
la
98
opcin
color
primario
Salidas
Se asignara el color a la opcin primario o

secundario.
Proceso

la seccin paleta de colores Seleccionar la
opcin color primario o secundario
Seleccionar un color.
Precondiciones
Efectos Colaterales
El sistema
seleccionara los colores para
primario y secundario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 6.
Requisito funcional: El sistema permite utilizar las

herramientas de dibujo.
Id
Requerimiento
de RF13 El sistema permite

herramientas de dibujo.
utilizar
las
Descripcin
El sistema permite al usuario utilizar

herramientas de dibujo como son deshacer,
rehacer, regla, cuadricula.
Entradas
Opcin utilizada por el usuario.
Salidas
Se aplicaran la opcin utilizada por el usuario.
Proceso

seccin dibujo Seleccionar la herramienta a
utilizar.
Precondiciones
Efectos Colaterales

resultado de la herramienta utilizada por el
usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores
99
Tabla 7.
Requisito funcional: El sistema permite administrar las

definiciones races.
Id
Requerimiento
de RF14 El sistema permite administrar las

definiciones races.
Descripcin
El sistema permite al usuario aadir, modificar

y eliminar definiciones races.
Entradas
Texto.
Salidas
Definiciones races.
Proceso
Acceder a la interfaz del editor grfico Click

a la pestaa Definicin raz Presionar en el
botn de (+) para aadir una definicin raz,
Presionar el botn (-) para eliminar, dar dos
clicks para modificar una definicin raz - El
sistema almacena las definiciones races.
Precondiciones
Efectos Colaterales
El sistema muestra la definicin raz.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 8.
Requisito funcional: El sistema permite administrar los

requisitos obtenidos.
Id
Requerimiento
de RF15 El sistema permite administrar los

Descripcin
El sistema permite al usuario aadir, modificar

el nombre y eliminar requisitos obtenidos.
Entradas
Texto.
Salidas
Requisitos obtenidos.
Proceso

la seccin requisitos - Click en el botn aadir
requisito obtenido Dar click en el rea de
trabajo escribir el nombre del requisito - El
requisito se aade a la lista de requisitos
obtenidos.
100
Para modificar el nombre dar dos clicks en la

lista de requisitos obtenidos Para eliminarlo
seleccionarlo en la lista de requisitos
obtenidos e eliminarlo.
Precondiciones
Haber obtenido un requisito de la imagen.
Efectos Colaterales
El sistema muestra, cambia o elimina el

requisito.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 9.
Requisito funcional: El sistema permite validar el

entendimiento entre los interesados.
Id
Requerimiento
de RF16 El sistema permite validar

entendimiento entre los interesados.
el
Descripcin
El sistema permite validar el entendimiento de

los requisitos obtenidos entre las personas
interesadas.
Entradas
Informacin al formulario de validacin.
Salidas
Requisitos obtenidos ya validados.
Proceso

Seleccionar el requisito a validar su
entendimiento en la lista de requisitos
obtenidos Dar doble click para abrir el
formulario de validacin Llenar el formulario
de validacin con la informacin requerida
dar click en el botn validar.
Precondiciones
Existan requisitos obtenidos

Efectos Colaterales
El sistema indica que el requisito ha sido

validado.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores
101
en la lista de
8.2
DOCUMENTACIN REFERENTE AL ANLISIS
8.2.1 Casos de Uso

Los siguientes casos de uso describen el comportamiento del mdulo desde el
punto de vista del usuario:
Figura 45. Caso de uso administrar imagen enriquecida
Fuente: Los autores

Tabla 10. Caso de uso: Administrar imagen enriquecida
Caso de uso
Administrar imagen enriquecida
Actores
Usuario
Propsito
Permitir al
usuario
administrar una
imagen enriquecida para obtener y validar
requisitos a partir de esta
Resumen
Este caso de uso se inicia cuando el
usuario desea construir una imagen
enriquecida, el usuario acceder a un
gestor grafico el cual le permite
administrar una imagen enriquecida,
insertar imgenes y figuras, utilizar
herramientas de dibujar, opciones de
edicin, opciones de paleta de colores,
herramientas de dibujo, administrar
definiciones races, administrar y validar
requisitos obtenidos
Precondiciones
Haber creado un proyecto
Tipo
Esencial
Referencias
R08,R09,R10,R11,R12,R13,R14,R15,R16
Curso Normal de los Eventos
Accin de los actores
Respuesta del sistema
1. Este caso de uso inicia cuando el 2. El gestor grafico ofrece al usuario
usuario desea realizar y administrar herramientas para la construccin de la
una
imagen
enriquecida
para imagen enriquecida, y para la obtencin y
102
posteriormente obtener y validar

requisitos obtenidos a partir de ella
Para esto el usuario debe acceder al
gestor grafico
validacin de requisitos.
El gestor grafico ofrece las siguientes
herramientas:
a) Administrar un archivo de imagen
enriquecida
b) Insertar imgenes y figuras
c) Herramientas de dibujar
d) Opciones de edicin
e) Opciones de paleta de colores
f) Herramientas de dibujo
g) Administrar definiciones races
h) Administrar requisitos obtenidos
i) Validar requisitos obtenidos
3. El usuario construye la imagen 4. El sistema muestra la imagen
enriquecida,
obtiene
y
valida enriquecida y los requisitos obtenidos a
requisitos a partir de ella
partir de ella
Seccin Administrar un archivo de imagen enriquecida
1. El usuario accede a la interfaz del
2. El sistema muestra al usuario en la
gestor grafico - Men archivo, donde seccin documento tres opciones que son
el sistema permite al usuario crear un abrir guardar y nuevo
documento, abrir y guardar un
archivo de imagen enriquecida.
3. El usuario seleccionara la opcin
4. El sistema realizara la opcin
que desee utilizar
seleccionada por el usuario
Seccin Insertar figuras
1.El usuario accede a la interfaz del
2. El sistema muestra al usuario un
gestor grafico Men herramientas,
seccin de imgenes prediseadas y una
acceder a la seccin figuras donde el seccin de galera del proyecto
sistema permite al usuario insertar
figuras y imgenes del proyecto
3. El usuario selecciona una figura o
4.El sistema dibujara las imgenes
una imagen y las adiciona al rea de insertadas en el rea de trabajo
trabajo
Seccin Herramientas de dibujar
2. El sistema le ofrece al usuario
herramientas como dibujar con lpiz,
acceder a la seccin dibujar donde el relleno, tipo, grosor y texto.
sistema permite al usuario usar
herramientas para dibujar
3. El usuario selecciona una de las
4.El sistema dibujara segn la opcin
herramientas de dibujar y la usa
escogida por el usuario
Seccin Opciones de edicin
2. El sistema le muestra al usuario
103

acceder a la seccin edicin donde el
sistema permite al usuario utiliza
herramientas de edicin
opciones de edicin y la usa
opciones de edicin como son pegar,

copiar, cortar, seleccionar, girar, acercar y
alejar
4. El sistema mostrara en el rea de

trabajo el resultado de la opcin utilizada
por el usuario.
Seccin Opciones de paleta de colores
2. El sistema le muestra al usuario un
color primario y uno secundario donde
acceder a la seccin paleta de
podr asignarle un color de la paleta de
colores, donde el sistema permite al
colores, tambin un selector para obtener
usuario escoger un color primario y
colores del rea de trabajo para
uno secundario de la paleta de
asignarlo.
colores
4.El sistema seleccionar los colores
opciones de paleta de colores
primario y secundario
Seccin Herramientas de dibujo
2. El sistema le muestra al usuario
herramientas de dibujo como son
acceder a la seccin dibujo, donde el deshacer, rehacer, regla y cuadricula.
sistema permite al usuario utiliza
herramientas de dibujo
4. El sistema mostrara en el rea de
opciones de edicin y la usa
trabajo el resultado de la opcin utilizada
por el usuario.
Seccin Administrar definiciones races
2. El sistema muestra una interfaz donde
gestor grafico acceder a la pestaa el usuario podr Presionar el botn de
Definicin raz, donde el sistema
(+) para aadir una definicin raz o
permite al usuario aadir y eliminar
presionar el botn (-) para eliminarla
definiciones races
4.El sistema guarda o elimina definiciones
opciones y aade o borra
races
definiciones raz
Seccin Administrar requisitos obtenidos
2. El sistema muestra una botn de
aadir requisito el cual le permite al
acceder a la seccin aadir requisito, usuario aadir requisitos a la imagen y a
donde el sistema permite al usuario
su vez en la lista de requisitos obtenidos.
agregar requisitos a la imagen
construida y a la lista de requisitos
obtenidos.
Tambin permite eliminar y modificar
104
requisitos agregados
3. El usuario despus de haber
4.El sistema realiza la opcin escogida
creado el requisito podr eliminarlo o por el usuario
modificarlo
Seccin Validar requisitos obtenidos
2. El sistema muestra una plantilla de
gestor grfico, el usuario da doble
validacin
click al requisito a validar en la lista
de requisitos obtenidos
3. Los interesados describen el
4.El sistema valida el requisito
requisito y lo validan mediante una
identificacin (usuario, contrasea)
Curso Alterno
3. Nombre de usuario o contrasea incorrecta, el sistema muestra una alerta de
nombre de usuario y o contrasea incorrecta
Fuente: Los autores
8.2.2 Diagramas de secuencia
Los siguientes diagramas de secuencia permiten ver la interaccion de los objetos
en la herramienta visual a traves del tiempo, los cuales se han modelado para los
casos de uso.
105
Figura 46. Diagrama de secuencia: Administrar imagen enriquecida. Seccin

administrar un archivo de imagen enriquecida
Figura 47. Fuente: Los autores

El usuario puede crear, abrir y guardar un archivo de imagen enriquecida, para el
primer caso el sistema muestra el rea de trabajo en blanco, en el segundo caso
el sistema retorna un men de exploracion donde el usuario selecciona el archivo
106
para que el sistema la cargue y en el ultimo caso el sistema guarda la imagen y

retorna un mensaje de confirmacin.
insertar figuras
Fuente: Los autores

El usuario puede insertar figuras prediseadas e imgenes de galeria del proyecto
al rea de trabajo, seleccionandolas en su men; las imgenes se insertan y
quedan resaltadas.
107

herramientas de dibujar
Fuente: Los autores

108
El usuario puede seleccionar las herramientas de: dibujar para realizar trazo
simples en el rea de trabajo , relleno para crear figuras prediseadas con un color
de relleno, tipos de linea para seleccionar el tipo un tipo de linea, tipo de grosor
para seleccionar el espesor de las lineas e insertar texto para ingresar texto en el
rea de trabajo, el sistema mostrara en el rea de trabajo el resultado de la opcin
seleccionada.
109

opciones de edicin - parte 1
Fuente: Los autores

El usuario puede seleccionar las opciones de cortar, pegar, copiar, seleccionar, las
usara en el rea de trabajo y el sistema mostrara los cambios segn la opcion
seleccionada.
110

opciones de edicin - parte 2
Fuente: Los autores

El usuario puede seleccionar las opciones de alejar para realizar un alejamiento de
del rea de trabajo, acercar para realizar un acercamiento del rea de trabajo.
111

Fuente: Los autores

El usuario selecciona un color como primario o secundario, color primario se
asigna para, dibujar con el color seleccionado como primario , color del borde y
color de la letra; color secundario se asigna para insertar una figura prediseada
con el color seleccionado; tambin se podra asignar un color del rea de trabajo
con la herramienta gotero o selector.
112

Fuente: Los autores

El usuario puede seleccionar las opciones de deshacer para eliminar una accin
realizada, rehacer para rehacer una accin eliminada, regla mostrara una regla
horizontal y una vertical, cuadrcula mostrara una cuadrcula en el rea de trabajo.
113

administrar definiciones races
Fuente: Los autores

El usuario puede crear definiciones raices y el sistema las mostrara en la interface,
despues de creadas el usuario podra eliminarlas o modificarlas.
validar requisitos obtenidos
Fuente: Los autores

El usuario puede validar un requisito obtenido por medio de un formato de
validacin el sistema almacenara el requisito obtenido.
114

administrar requisitos obtenidos
Fuente: Los autores

El usuario puede obtener requisitos y agregarlos por medio de una caja de texto al
rea de trabajo, posteriormente puede eliminarlo o modificarlo. Los requisitos
obtenidos se mostraran en el rea de trabajo y en una lista de requisitos
obtenidos.
8.2.3 Diagramas de Colaboracin
En los siguientes diagramas de colaboracin se muestra la iteracin entre objetos
haciendo nfasis en el contexto de la operacin:
115
Figura 57. Diagrama de colaboracin: Administrar imagen enriquecida. Seccin

administrar un archivo de imagen enriquecida
Fuente: Los autores

El usuario puede crear, abrir y guardar un archivo de imagen enriquecida, para el
el sistema retorna un men de exploracin donde el usuario selecciona el archivo
para que el sistema la cargue y en el ultimo caso el sistema guarda la imagen y
retorna un mensaje de confirmacin.
116

insertar figuras
Fuente: Los autores

El usuario puede insertar figuras prediseadas e imgenes de galeria del proyecto
al rea de trabajo, seleccionandola de su men; las imgenes se insertan y
quedan resaltadas.
herramientas de dibujar
Fuente: Los autores
117
El usuario puede seleccinar las herramientas de: dibujar para realizar trazo
simples en el rea de trabajo , relleno para crear figuras prediseadas con un color
de relleno, tipos de linea para seleccionar un tipo de lnea, tipo de grosor para
seleccionar el espesor de las lneas e insertar texto para ingresar texto en el rea
de trabajo, el sistema mostrara en el rea de trabajo el resultado de la opcin
seleccionada.
opciones de edicin
Fuente: Los autores

El usuario puede seleccionar las opciones de cortar, pegar, copiar, seleccionar, las
usara en el rea de trabajo y el sistema mostrara los cambios segn la opcin
seleccionada.
El usuario podra seleccionar las opciones de alejar para realizar un alejamiento de
del rea de trabajo, acercar para realizar un acercamiento del rea de trabajo.
118

Fuente: Los autores

El usuario puede seleccionar las opciones de deshacer para eliminar una accin
realizada, rehacer para rehacer una accin eliminada, regla mostrara una regla
horizontal y una vertical, cuadrcula mostrara una cuadrcula en el rea de trabajo.
Fuente: Los autores

El usuario selecciona un color como primario o secundario, color primario se
asigna para, dibujar con el color seleccionado como primario , color del borde y
color de la letra; color secundario se asigna para insertar una figura prediseada
119
con el color seleccionado; tambien se podra asignar un color del rea de trabajo
con la herramienta gotero o selector.
administrar definiciones races
Fuente: Los autores

El usuario puede crear definiciones raices y el sistema las mostrara en la interface,
despues de creadas el usuario podra eliminarlas o modificarlas.
120

administrar requisitos obtenidos
Fuente: Los autores

El usuario puede obtener requisitos y agregarlos por medio de una caja de texto al
rea de trabajo, posteriormente puede eliminarlo o modificarlo. Los requisitos
obtenidos se mostraran en el rea de trabajo y en una lista de requisitos
obtenidos.
121

validar requisitos obtenidos
Fuente: Los autores

El usuario puede validar un requisito obtenido por medio de un formato de
validacin el sistema almacenara el requisito obtenido.
8.3
DOCUMENTACIN REFERENTE AL DISEO
En la documentacin referente al diseo de este mdulo, slo se listan las
interfaces de usuario. Los dems diagramas referentes al diseo estn en la
seccin 10.3.2 puesto que los diagramas de diseo realizados representan la
estructura del sistema, ms no nicamente la de este primer mdulo.
8.3.1 Interfaces de usuario
122
Figura 66. Ejemplo de uso del editor grfico.
Fuente: Los autores

Las funcionalidades que le permite llevar a cabo al usuario esta interfaz son:
construir una imagen enriquecida, realizar definiciones races, obtener requisitos a
partir de la imagen enriquecida y validar el entendimiento de requisitos. Mediante
esta interfaz se implementan los estadios de la SSM a los procesos de obtencin y
anlisis de requisitos, la forma en que se aplican los estadios se ha explicado en
las secciones 4.3.1 y 4.3.2 respectivamente.
La figura 66 se hizo en base a un ejemplo de construccin de una imagen
enriquecida del video que se va mostrar en la sustentacin del trabajo de grado
sobre la metodologa de sistemas blandos.
123
Figura 67. Ejemplo de un formulario para la validacin del entendimiento de un

requisito.
Fuente: Los autores

La funcionalidad que le permite llevar a cabo esta interfaz es validar el
entendimiento de un requisito entre el cliente y la persona encargada de realizar el
proceso de obtencin de requisitos por parte del equipo de desarrollo. De esta
forma se garantiza la existencia de un formato de comunicacin entendible entre
los involucrados en el proyecto en el proceso de obtencin de los requisitos.
124
Figura 68. Interfaz del men Archivo
Fuente: Los autores

guardar el archivo, Abrir e importar otra imagen enriquecida, realizar las acciones
de deshacer y rehacer y finalmente visualizar las ayudas de regla y cuadrcula en
el rea de trtabajo.
125
9 ANLISIS Y DISEO DEL MDULO ADMINISTRACIN DE

REQUISITOS
El enfoque que tiene este segundo mdulo es brindar una opcin al equipo de
desarrollo cuando construya la especificacin de requisitos de software y realice la
administracin de requisitos, mediante la implementacin de la teora de los
mapas conceptuales. Esto con el fin de asignar los requisitos a desarrollar,
responsabilidades al equipo de desarrollo y fechas lmites de inicio y fin para los
requisitos asignados, con el fin de tener en un mismo contexto a todos los
requisitos del proyecto con sus respectivas relaciones o influencias entre ellos. De
esta forma se establece al equipo de desarrollo el cmo se va hacer el proyecto de
software. En este mdulo estn los anlisis y diseos de las herramientas
necesarias para la elaboracin de mapas conceptuales, en los cuales se realice o
bien sea, la especificacin de requisitos de software, la configuracin del plan de
administracin de requisitos o se lleve a cabo los procesos de administracin de
requisitos.
9.1
REQUISITOS FUNCIONALES
Tabla 11. Requisito funcional: El sistema permite administrar el archivo
de mapa conceptual.
Id
Requerimiento
de RF17 El sistema permite administrar el

archivo de mapa conceptual.
Descripcin
El sistema permite al usuario crear, abrir y

guardar un archivo de mapa conceptual.
Entradas
Opcin seleccionada por el usuario.
Salidas
El sistema creara, abrir o guardara un

archivo de mapa conceptual.
Proceso
Acceder a la interfaz de mapa conceptual

seccin documento Seleccionar entre las
opciones abrir, nuevo y guardar.
Precondiciones
Abrir el editor mapa conceptual.
Efectos Colaterales
El sistema realizara la accin elegida por el

usuario.
Prioridad
Alta.
126
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 12. Requisito funcional: El sistema permite al usuario crear
requisitos.
Id
Requerimiento
de RF18 El sistema permite al usuario crear

requisitos.
Descripcin
El sistema permite al usuario crear requisitos y

subrequisitos ingresndolos por texto y
tabulaciones, los requisitos creados se
dibujaran en el mapa conceptual.
Entradas
Texto.
Salidas
Requisitos y sub requisitos.
Proceso

Acceder al editor de requisitos Crear un
requisito, ingresndolo mediante texto
Crear sub requisitos mediante tabulaciones e
ingresando el nombre digitando texto.
Precondiciones
Abrir el editor mapa conceptual.
Efectos Colaterales
El sistema mostrara el requisito o subrequisito

en el editor de requisitos y lo dibujara en el
mapa conceptual.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 13. Requisito funcional: El sistema permite administrar los
requisitos creados.
Id
Requerimiento
de RF19 El sistema permite administrar los

requisitos creados.
Descripcin
El sistema permite al usuario modificar y

eliminar requisitos o sub requisitos creados.
Entradas
Texto.
Salidas
Requisitos y sub requisitos modificados o

eliminados.
127
Proceso

Acceder al editor de requisitos Seleccionar
el requisito a modificar o eliminar Eliminar el
requisito o modificarle el nombre.
Precondiciones
Existan requisitos creados.
Efectos Colaterales
El sistema mostrara el requisito o subrequisito

en el editor de requisitos y lo dibujara en el
mapa conceptual.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 14. Requisito funcional: El sistema permite crear una pregunta
de enfoque.
Id
Requerimiento
de RF20 El sistema permite crear una pregunta

de enfoque.
Descripcin
El sistema permite al usuario crear una

pregunta de enfoque.
Entradas
Texto.
Salidas
Pregunta de enfoque
Proceso
El usuario podr agregar la pregunta de

enfoque para el mapa conceptual dando
click en la barra de ttulo.
Precondiciones
Efectos Colaterales
El sistema mostrara la pregunta de enfoque

en la barra de ttulo.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 15. Requisito funcional: El sistema permite administrar palabras
de enlace.
Id
Requerimiento
Descripcin
de RF21 El sistema permite administrar palabras

de enlace.
El sistema permite al usuario crear, modificar y
128
eliminar palabras de enlace.

Entradas
Texto.
Salidas
Palabras de enlace.
Crear, eliminar o modificar palabras de
enlace
Proceso
Para crear se selecciona el espacio donde se

insertara la palabra de enlace
Para modificar o eliminar se selecciona la
palabra de enlace y se modifica o elimina.
Precondiciones
Que existan requisitos creados.

El sistema mostrara la palabra de enlace en
el rea seleccionada por el usuario para
crearla.
Efectos Colaterales
El sistema cambiara o eliminara la palabra de

enlace en caso que el usuario seleccione
estas opciones.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 16. Requisito funcional: El sistema permite administrar enlaces
cruzados.
Id
Requerimiento
de RF22 El sistema permite administrar enlaces

cruzados.
Descripcin
El sistema permite al usuario crear, modificar y

eliminar enlaces cruzados.
Entradas
Texto.
Salidas
Enlaces cruzados.
Proceso

Crear, eliminar o modificar enlaces cruzados.
Para crear se selecciona el requisito y
despus se selecciona el requisito a enlazar
129
se agrega el enlace cruzado.

Para modificar o eliminar se selecciona el
enlace cruzado y se modifica o elimina
Precondiciones
Que existan requisitos creados.
Efectos Colaterales
El sistema mostrara el enlace cruzado en el

rea seleccionada por el usuario.
El sistema cambiara o eliminara el enlace
cruzado en caso que el usuario seleccione
estas opciones.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 17. Requisito funcional: El sistema permite cambiar de posicin
elementos del mapa conceptual.
Id
Requerimiento
de RF23
El sistema permite cambiar de
posicin elementos del mapa conceptual.
Descripcin
El sistema permite al usuario seleccionar un

elemento del mapa conceptual y cambiarlo
a una nueva posicin.
Entradas
Elemento a cambiar de posicin.
Salidas
Cambio de posicin.
Proceso

Seleccionar el elemento a cambiar posicin
Mover el elemento a una nueva posicin.
Precondiciones
Que existan elementos creados en el mapa

conceptual.
Efectos Colaterales
El
sistema
mostrara
el
elemento
seleccionado en la nueva posicin.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores
130
Tabla 18. Requisito funcional: El sistema permite verificar la inclusin

de requisitos obtenidos.
Id
Requerimiento
de RF24 El sistema permite verificar la inclusin

de requisitos obtenidos.
Descripcin
El sistema proporciona al usuario una ayuda

visual para que los requisitos obtenidos
anteriormente
sean
creados
en
la
especificacin de requisitos y en el mapa
conceptual.
Entradas
Texto.
Salidas
Requisitos y sub requisitos.
Proceso

Acceder a la pestaa de requisitos obtenidos
El sistema verifica la existencia de este
requisito en ambas listas.
Precondiciones
Que existan requisitos obtenidos.
Efectos Colaterales
Si el requisito se encuentra en ambas listas se

tachar de la lista de requisitos obtenidos.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 19. Requisito funcional: El sistema permite ingresar informacin
a la plantilla RMP.
Id
Requerimiento
de RF25 El sistema permite ingresar informacin

a la plantilla RMP.
Descripcin
El sistema permite al usuario agregar

informacin a los tems de la plantilla
previamente configurada.
Entradas
Texto.
Salidas
Contenido del documento RMP.
Proceso

Pestaa de proyecto - Seleccionar la plantilla
RMP importada Seleccionar un tem de la
plantilla Aadir informacin a el tem Se
almacena la informacin agregada.
131
Precondiciones
Haber configurado la plantilla RMP.
Efectos Colaterales
Se almacena la informacin aadida por el

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 20. Requisito funcional: El sistema permite ingresar informacin
a la plantilla SRS.
Id
Requerimiento
de RF26 El sistema permite ingresar informacin

a la plantilla SRS.
Descripcin
El sistema permite al usuario agregar

informacin a los tems de la plantilla
previamente configurada.
Entradas
Texto.
Salidas
Contenido del documento SRS.
Proceso

Pestaa de proyecto - Seleccionar la plantilla
SRS importada Seleccionar un tem de la
plantilla Aadir informacin a el tem Se
almacena la informacin agregada.
Precondiciones
Haber configurado la plantilla SRS.
Efectos Colaterales

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 21. Requisito funcional: El sistema permite la especificacin de
los requisitos creados.
Id
Requerimiento
Descripcin
de RF27 El sistema permite la especificacin de

los requisitos creados.
El sistema permite al usuario especificar
requisitos mediante un formulario de
especificacin de requisitos.
132
Entradas
Doble click a un requisito creado.
Salidas
Requisitos especificados.
Proceso

Pestaa especificacin de requisitos
Seleccionar y dar doble click al requisito a
especificar Se almacena la informacin
agregada al formulario.
Precondiciones
Existan requisitos creados.
Efectos Colaterales

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 22. Requisito funcional: El sistema permite seleccionar respecto
a que elementos se va hacer trazabilidad.
Id
Requerimiento
de RF28 El sistema permite seleccionar respecto

a que elementos se va hacer trazabilidad.
Descripcin
Cuando un usuario desee ver la relacin que

existe entre elementos, lo podr hacer
mediante esta herramienta de trazabilidad.
Entradas
Elementos a trazar.
Salidas
La
relacin
seleccionados.
Proceso

Acceder a la pestaa trazabilidad entre
elementos - Seleccionar los elementos - Dar
click en el botn aceptar El sistema genera
la nueva interfaz.
Precondiciones
Los requisitos ya deben estar especificados.
Efectos Colaterales
El sistema muestra en el rea de trabajo una

interfaz con los elementos y su relacin.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

133
entre
los
elementos
Tabla 23. Requisito funcional: El sistema permite generar un diagrama

de red y una pila de actividades.
Id
Requerimiento
de RF29
El sistema permite generar un
diagrama de red y una pila de actividades.
Descripcin
Cuando un usuario desee generar un

diagrama de secuencia y/o una pila de
actividades lo podr hacer accediendo a la
pestaa de diagrama de actividades.
Entradas
Informacin para los diagramas.
Salidas
Diagrama de
actividades.
Proceso

Acceder a la pestaa Diagramas Seleccionar la opcin diagrama de red y pila
de actividades Dar click en el botn
aceptar El sistema genera los diagramas.
Precondiciones
Efectos Colaterales
El sistema muestra en el rea de trabajo una

interfaz con los diagramas.
Prioridad
Alta.
Rol del ejecutor
Usuario.
secuencia
y/o
pila
de
Fuente: Los autores

Tabla 24. Requisito funcional: El sistema permite seleccionar una
categora respecto a la que se vaya hacer priorizacin.
Id
Requerimiento
de
RF30 El sistema permite seleccionar una

categora respecto a la que se vaya hacer
priorizacin.
Descripcin
Cuando un usuario desee seleccionar una

categora de priorizacin podr seleccionar
entre las opciones de tiempo faltante para la
entrega y de dificultad del requisito.
Entradas
Informacin de los requisitos.
Salidas
Categora seleccionada para posteriormente

visualizarla.
Proceso

134
Acceder a la pestaa Priorizacin Seleccionar la opcin que desee el usuario Dar click en el botn aceptar El sistema
selecciona la opcin de priorizacin
seleccionada por el usuario.
Precondiciones
Efectos Colaterales
El sistema muestra la opcin escogida por el

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 25. Requisito funcional: El sistema permite seleccionar un rango
de visualizacin del reporte de prioridad.
Id
Requerimiento
de
RF31
El sistema permite seleccionar un
rango de visualizacin del reporte de
prioridad.
Descripcin
Cuando un usuario desee visualizar el reporte

de priorizacin podr escoger entre las
opciones definir un color, reporte completo, o
definir un rango personalizado
lo cual
permite visualizar los requisitos en el mapa
conceptual que segn su estado respecto a
la fecha de entrega o su nivel de dificultad
corresponden al color definido, al reporte
completo o el rango personalizado en la
escala de priorizacin.
Entradas
Informacin de los requisitos.
Salidas
Categora seleccionada para posteriormente

visualizarla.
Proceso

Acceder a la pestaa Priorizacin Seleccionar la opcin que desee el usuario Dar click en el botn aceptar El sistema
selecciona la opcin de priorizacin
seleccionada por el usuario.
Precondiciones

135
Efectos Colaterales
El sistema muestra la opcin escogida por el

usuario.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

9.2
9.2.1 Casos de uso

Figura 69. Caso de uso administrar mapa conceptual
Fuente: Los autores

Tabla 26. Caso de uso: Administrar mapa conceptual
Caso de uso
Actores
Propsito
Resumen
Administrar mapa conceptual

Usuario
Permitir al usuario administrar un
mapa conceptual
usuario desea construir un mapa
conceptual, el usuario accede al
gestor de mapa conceptual el cual le
permite administrar un archivo de
mapa conceptual, crear requisitos,
administrar
requisitos
creados,
verificar la inclusin de requisitos
obtenidos, crear una pregunta de
enfoque, administrar palabras de
136
enlace, administrar enlaces cruzados,

cambiar la posicin elementos del
mapa conceptual
Precondiciones
Tipo
Esencial
Referencias
R17,R18,R19,R20,R21,R22,R23,R24
1. Este caso de uso inicia cuando el 2. El gestor de mapa conceptual
usuario desea realizar y administrar ofrece al usuario herramientas para la
un mapa conceptual en el cual creara construccin del mapa conceptual
requisitos del proyecto
El gestor de mapa conceptual ofrece
Para esto el usuario debe acceder al las siguientes herramientas:
gestor de mapa conceptual
a) Administrar un archivo de mapa
conceptual
b) Crear una pregunta de enfoque
c) Crear requisitos
d) Administrar requisitos creados
e) Verificar la inclusin de requisitos
obtenidos
f) Administrar palabras de enlace
g) Administrar enlaces cruzados
h) Cambiar la posicin de elementos
del mapa conceptual
3. El usuario construye el mapa 4. El sistema muestra el mapa
conceptual con los requisitos de su conceptual
proyecto
Seccin Administrar una un archivo de mapa conceptual
2. El sistema muestra al usuario en la
gestor de mapa conceptual - Men
seccin documento tres opciones que
archivo, donde el sistema permite al
son abrir guardar y nuevo
usuario crear un documento, abrir y
guardar un archivo de mapa
conceptual
3. El usuario seleccionara la opcin
4. El sistema realizara la opcin
que desee utilizar
seleccionada por el usuario
Seccin Crear una pregunta de enfoque
2. El sistema permite al usuario
gestor grfico y da doble click en la
escribir texto
barra de titulo
3. El usuario escribe su pregunta de
4.El sistema guarda y muestra la
enfoque
pregunta de enfoque en la barra de
137
titulo
Curso Alterno
3. El usuario no aade su pregunta de enfoque, el sistema no realiza cambios
a la barra de titulo
Seccin Crear requisitos
2. El sistema le ofrece al usuario la
gestor de mapa conceptual da un
herramienta editor de requisitos en la
click en la pestaa especificacin de
cual el usuario podr administrar los
requisitos.
requisitos
3. El usuario crea un requisito al cual 4. El sistema muestra el requisito en
se le debe dar un nivel de tabulacin el editor de requisitos y lo dibuja en el
y un nombre
mapa conceptual
Curso Alterno
3. 1. Si se agrega (//) antes de un requisito, El sistema crea el requisito pero
no lo dibuja en el mapa conceptual
Seccin Administrar requisitos creados
2. El sistema muestra en el editor de
gestor de mapa conceptual da un
los requisitos y en el mapa
click en la pestaa especificacin de
conceptual los requisitos creados
requisitos.
3. El usuario selecciona el requisito
4.El sistema mostrara los cambios en
para modificarle el nombre o
el editor de requisitos y en el mapa
eliminarlo
conceptual
Curso Alterno
3. El usuario no realiza ningn cambio ni elimina requisitos creados, el
sistema no realiza cambios
Seccin Verificar la inclusin de requisitos obtenidos
1.El usuario crea un requisito en el
2. El sistema verifica la existencia de
editor de requisitos
este requisito en la lista de requisito
obtenidos y el editor de requisitos, si
esto se cumple se tachar de la lista
de requisitos obtenidos
Curso Alterno
1.El requisito no se encuentra en ambas listas, el sistema no realiza nada
Seccin Administrar palabras de enlace
2. El sistema genera una palabra de
gestor de mapa conceptual, y en el
enlace entre ellos
momento que el usuario cree dos
requisitos
3.El usuario nombra la palabra de
4. El sistema muestra el nombre de
enlace por medio de una caja de
palabra de enlace en el mapa
texto
conceptual
5. El usuario despus podr
6. El sistema mostrara los cambios
138
modificarle el nombre o eliminar la

en el mapa conceptual
palabra de enlace
Seccin Administrar enlaces cruzados
2. El sistema muestra encima del
gestor de mapa conceptual, el
requisito seleccionado la herramienta
usuario selecciona un requisito dando de enlace cruzado
un click
3.El usuario da click sostenido desde 4. El sistema genera el enlace
el botn de esta herramienta hasta el cruzado
otro requisito
5. El usuario le da un nombre al
6. El sistema muestra el nombre del
enlace cruzado
enlace cruzado
7. El usuario despus podr
8. El sistema mostrara los cambios
modificarle el nombre o eliminar el
enlace cruzado
Seccin cambiar de posicin elementos del mapa conceptual
2. El sistema muestra el elemento
gestor de mapa conceptual y en el
seleccionado
mapa conceptual selecciona el
elemento a cambiar
3. El usuario arrastra el elemento a
4.El sistema muestra los cambios en
su nueva posicin y lo suelta
el mapa conceptual
Curso Alterno
3. El usuario no cambia de posicin el elemento el sistema no realiza cambio
en los elementos
Fuente: Los autores
Figura 70. Caso de uso ingresar informacin a las plantillas
Fuente: Los autores

Tabla 27. Caso de uso: Ingresar informacin a las plantillas
Caso de uso
Ingresar
informacin
a
plantillas
Actores
Usuario
139
las
Propsito
Permitir al
usuario
ingresar
informacin
a
las
plantillas
configuradas para su proyecto
Resumen
usuario desea aadir la informacin a
las plantillas.
Precondiciones
Haber configurado las plantillas
Tipo
Esencial
Referencias
R25,R26
1. Este caso de uso inicia cuando el 2. El sistema le muestra al usuario el
usuario desea aadir informacin a esqueleto del proyecto
las plantillas para esto desde el
gestor de mapa conceptual accede a
la pestaa proyectos
3. El usuario escoge el tem de la 4. El sistema muestra una caja de
plantilla al cual desea aadir la texto con el nombre del tem.
informacin.
5. El usuario aade la informacin
6. El sistema guarda la informacin
Curso Alterno
5. El usuario no aade informacin al tem , el sistema no almacena
informacin
Fuente: Los autores
Figura 71. Caso de uso especificar un requisito
Fuente: Los autores

Tabla 28. Caso de uso: Especificar un requisito
Caso de uso
Especificar un requisito
Actores
Usuario
Propsito
Permitir al usuario especificar los
140
requisitos creados para el proyecto

usuario
desea
especificar
un
requisito, lo podr realizar mediante
un formulario
Precondiciones
Haber creado requisitos
Tipo
Esencial
Referencias
R27
1. Este caso de uso inicia cuando el 2. El sistema le muestra al usuario los
usuario desea especificar un requisito requisitos creados
para esto desde el gestor de mapa
conceptual accede a especificacin
de requisitos
3. El usuario selecciona el requisito al 4. El sistema muestra un formulario
cual desea especificar.
con campos para especificar.
Resumen
5. El usuario aade la informacin

6. El sistema guarda la informacin
Curso Alterno
5. El usuario no especifica el requisito , el sistema no almacena informacin
Fuente: Los autores
Figura 72. Caso de uso procesos de administracin
Fuente: Los autores

Tabla 29. Caso de uso: Procesos de administracin
Caso de uso
Procesos de administracin
Actores
Usuario
Propsito
Permitir
al usuario realizar
un
proceso
de
administracin
de
requisitos
como
los
son
la
trazabilidad, priorizacin, diagrama
de secuencia.
141
Resumen

usuario desea realizar un proceso de
administracin como son:
a) Trazabilidad
b) Generar diagrama de red y pila
de actividades
c) Priorizacin y visualizacin del
reporte de priorizacin
el usuario podr configurar los

procesos a las necesidades de su
proyecto.
Precondiciones
Haber especificado los requisitos
Tipo
Esencial
Referencias
R28,R29,R30,R31
1. Este caso de uso inicia cuando el 2. El sistema muestra opciones
usuario necesita realizar un proceso segn el proceso seleccionado
de administracin, para ello ingresa a
la interfaz del gestor de mapa
conceptual y accede a la pestaa del
proceso que desee realizar
a)Pestaa Priorizacin
b)Pestaa diagramas
c)Pestaa
trazabilidad
entre
elementos
3. El usuario realiza configuraciones 5.El sistema realiza el proceso y
al proceso
muestra la interfaz correspondiente al
proceso realizado
Curso Alterno
Accin 3: El usuario no configura el proceso o los requisitos no han sido
especificados; el sistema no realiza el proceso
Seccin Trazabilidad
1.El usuario da un click en el botn
2. La interfaz mostrara 2 botones
trazabilidad entre elementos
para elegir los elementos a trazar
3. El usuario da click en el botn nivel 4. El sistema queda a la espera de
1
que el usuario de click en el botn
nivel 2 o aceptar
5. El usuario da click en el botn nivel 6. El sistema queda a la espera de
2
que el usuario de click en el botn
aceptar
7. El usuario da click en el botn
8. El sistema muestra la trazabilidad
142
aceptar
Curso Alterno
Accin 5: El usuario configura una plantilla vaca, el sistema muestra un
mensaje que informa al usuario que la plantilla est vaca
Seccin Generar diagrama de red y pila de actividades
1.El usuario da un click en el panel
2. El sistema muestra una interfaz en
diagramas
la que se encuentre la herramienta
para generar el diagrama de red y
pila de actividades
3. El usuario selecciona alguien de
4. El sistema genera una interfaz
las opciones y da click en aceptar
donde se muestra el diagrama de red
y pila de actividades
Seccin Priorizacin y visualizacin del reporte de priorizacin
1.El usuario da click en el panel
2. El sistema muestra una interfaz
priorizacin
con un men desplegable llamado
configuracin donde se encuentran
las opciones de tiempo faltante para
la entrega, dificultad del requisito.
3. El usuario selecciona alguna de las 4. El sistema muestra otro men
opciones.
desplegable llamado visualizacin
donde se encuentran las opciones
Reporte completo, rango
personalizado y un color.
4. El usuario selecciona alguna de las
opciones.
5. El usuario da click en aceptar
6. El sistema genera el reporte
Fuente: Los autores
Los siguientes diagramas de secuencia permiten ver la interaccion de los objetos
en la herramienta visual a traves del tiempo, los cuales se han modelado para los
casos de uso.
143
Figura 73. Diagrama de secuencia: Administrar mapa conceptual. Seccin

administrar un archivo de mapa conceptual
Fuente: Los autores

El usuario puede crear abrir y guardar un archivo de mapa conceptual , para el
para que el sistema la cargue y en el ultimo caso el sistema guarda el mapa
conceptual y retorna un mensaje de confirmacin.
Figura 74. Diagrama de secuencia: Administrar mapa conceptual. Seccin crear
una pregunta de enfoque
Fuente: Los autores

EL usuario puede crear una pregunta de enfoque para la construccin de su mapa
conceptual, la pregunta de enfoque se mostrara en la barra superior del sistema,
despues de creada podra cambiarla o eliminarla.
144

administrar palabras de enlace
Fuente: Los autores

El usuario puede crear una palabra de enlace siempre y cuando existan por los
menos dos requisitos creados , el sistema la mostrara en la interface, despues de
creada el usuario podra eliminarla, modificarla o cambiar su posicin.
145

administrar requisitos
Fuente: Los autores

El usuario puede crear requisitos mediante un editor de requisitos, el sistema
mostrara los requisitos creados en el rea de trabajo como nodos ademas en la
lista de editor de requisitos, despues de creado el usuario puede eliminarlo,
modificarlo o cambiar su posicin.
146
Ademas el sistema verfica la lista de requisitos obtenidos con la del editor de

requisitos para marcarlo como agregado.
En este diagrama se agreg la seccin de crear requisito, verificar la inclusin de
requisitos obtenidos y la seccin de reposicin de elementos
administrar enlace cruzado
Fuente: Los autores

El usuario puede crear enlace cruzado siempre y cuando existan por los menos
dos requisitos creados, el usuario selecciona el primer requistio el sistema muestra
la opcin de enlace cruzado para que el usuario arrastre el icono hasta el
requisito que desea enlazar.
147
Figura 78. Diagrama de secuencia: Ingresar informacin a las plantillas
Fuente: Los autores

El usuario selecciona entre las plantillas configuradas para agregar, borrar o
modificar la informacin de cada uno de sus atributos.
Figura 79. Diagrama de secuencia: Especificar un requisito
Fuente: Los autores

148
El usuario selecciona entre los requisitos que se encuentra en el editor de

requisitos para especificarlo por medio de el formato de especificacin de
requisitos correspondiente.
149
Figura 80. Diagrama de secuencia: Procesos de administracin. Seccin

proceso de trazabilidad
Fuente: Los autores
150
El usuario configura el proceso de trazabilidad mediante la opcin para este

proceso , el sistema le mostrara una lista de elementos, el usuario selecciona
elementos de esa lista como elementos de nivel 1, despues debera configurar el
los elementos de nivel 2 , el sistema selecciona los elementos del nivel 2 y los
muestra al usuario para que el los seleccine, estos elementos estan vinculados a
los elementos seleccionados en el nivel 1, despues el procesos se realiza y se
muestran los resultados en la interface.
proceso de priorizacin
Fuente: Los autores
151
El usuario configura este proceso primero seleccionando frente a que quiere

realizar la priorizacin , y tambien debera seleccionar la opcin de visualizacin, el
proceso queda configurado y se muestran los resultados en las interfaces.
proceso de diagramacin
Fuente: Los autores

El usuario puede generar el diagrama de red y la pila de actividades mediante la
opcin de diagramas, el sistema realiza el proceso y muestra la informacin en la
interface.
9.2.3 Diagramas de colaboracin
152

administrar un archivo de mapa conceptual
Fuente: Los autores

El usuario puede crear abrir y guardar un archivo de mapa conceptual , para el
para que el sistema la cargue y en el ultimo caso el sistema guarda el mapa
conceptual y retorna un mensaje de confirmacin.
crear una pregunta de enfoque
Fuente: Los autores

153
El usuario puede crear una pregunta de enfoque para la construccin de su mapa

conceptual, la pregunta de enfoque se mostrara en la barra superior del sistema,
despues de creada podra cambiarla o eliminarla.
administrar requisitos
Fuente: Los autores

El usuario puede crear requisitos mediante un editor de requisitos, el sistema
mostrara los requisitos creados en el rea de trabajo como nodos ademas en la
lista de editor de requisitos, despues de creado el usuario puede eliminarlo,
modificarlo o cambiar su posicin.
Ademas el sistema verifica la lista de requisitos obtenidos con la del editor de
requisitos para marcarlo como agregado.
En este diagrama se agreg la seccin de crear requisito, verificar la inclusin de
requisitos obtenidos y la seccin de reposicin de elementos.
154

administrar palabras de enlace
Fuente: Los autores

El usuario puede crear una palabra de enlace siempre y cuando existan por los
menos dos requisitos creados , el sistema la mostrara en la interface, despues de
creada el usuario podra eliminarla, modificarla o cambiar su posicin.
administrar enlace cruzado
Fuente: Los autores

El usuario puede crear un enlace cruzado siempre y cuando existan por los menos
dos requisitos creados, el usuario selecciona el primer requisto el sistema muestra
la opcin de enlace cruzado para que el usuario arrastre el icono hasta el
requisito que desea enlazar.
155
Figura 88. Diagrama de colaboracin: Ingresar informacin a las plantillas
Fuente: Los autores

El usuario selecciona entre las plantillas configuradas para agregar, borrar o
modificar la informacin para sus atributos.
Figura 89. Diagrama de colaboracin: Especificar un requisito
Fuente: Los autores

156
El usuario selecciona entre los requisitos que se encuentra en el editor de

requisitos para especificarlo por medio de el formato de especificacin de
requisitos correspondiente.
Figura 90. Diagrama de colaboracin: Procesos de administracin. Seccin
Fuente: Los autores

El usuario configura el proceso de trazabilidad mediante la opcin para este
proceso , el sistema le mostrara una lista de elementos, el usuario selecciona
elementos de esa lista como elementos de nivel 1, despues debera configurar el
los elementos de nivel 2 , el sistema selecciona los elementos del nivel 2 y los
muestra al usuario para que el los seleccine, estos elementos estan vinculados a
los elementos seleccionados en el nivel 1, despues el procesos se realiza y se
muestran los resultados en la interface.
157

Fuente: Los autores

El usuario configura este proceso primero seleccionando frente a que quiere
realizar la priorizacin , y tambien debera seleccionar la opcin de visualizacin, el
proceso queda configurado y se muestran los resultados en las interfaces.
Fuente: Los autores

El usuario podra generar el diagrama de red y la pila de actividades mediante la
opcin de diagramas, el sistema realiza el proceso y muestra la informacin en la
interface.
9.3
DOCUMENTACIN REFERENTE AL DISEO
En la documentacin referente al diseo de este mdulo, slo se listan las
interfaces de usuario. Los dems diagramas referentes al diseo estn en la
158
seccin 10.3.2 puesto que los diagramas de diseo realizados representan la

estructura del sistema, ms no nicamente la de este primer mdulo.
9.3.1 Interfaces de usuario.
Figura 93. Ejemplo de un mapa conceptual elaborado a partir de la
especificacin de requisitos
Fuente: Los autores

describir los tems de las plantillas del proyecto, especificar requisitos, administrar
el mapa conceptual, realizar los procesos de administracin de requisitos
(priorizacin, diagrama de red, trazabilidad), generar los documentos formales (el
plan de administracin de requisitos y/o el documento de especificacin de
requisitos). Mediante esta interfaz se implementa la teora de los mapas
conceptuales en donde cada concepto equivale a un requisito o una agrupacin
de estos, al cual se le puede ingresar la informacin necesaria para ser
administrados durante el proyecto y las proposiciones son las encargadas de
expresar la relacin existente entre dos o ms requisitos.
El ejemplo del mapa conceptual de la figura 93 y siguientes, se hizo en base a los
requisitos que se tenian en el principio del trabajo de grado, aunque los requisitos
posteriormente fueron cambiados por los requisitos funcionales y los casos de uso
159
de cada mdulo, se conservo esta imagen para tenerla de ejemplo en las

interfaces.
Figura 94. Ejemplo de uso de la herramienta enlace cruzado
Fuente: Los autores

En esta interfaz se muestra la herramienta enlace cruzado sobre el requisito
GESTOR VISUAL una vez que se ha dado click en l. Luego de aparecer la
herramienta en pantalla, se le da click sostenido hasta el requisito a unir mediante
el enlace cruzado. Mediante esta herramienta y la herramienta palabras de enlace
se implementa el concepto de preposiciones de la teora de los mapas
conceptuales.
160
Figura 95. Panel Especificacin de requisitos y ejemplo de especificacin
Fuente: Los autores

La funcionalidad que le permite llevar a cabo al usuario esta interfaz es:
especificar un requisito mediante los atributos con que se hayan configurado la
plantilla atributos de los requisitos, del mismo modo especificar qu tipo de
requisitos es, segn los tipos de requisitos que se hayan configurado en la plantilla
tipos de requisitos (esta opcin no aparece en este ejemplo de especificacin,
aunque la opcin para seleccionar el tipo de requisito se podra hacer por medio
de un men desplegable).
161
Figura 96. Panel proyecto y ejemplo de cmo aadir la descripcin a un item de

una plantilla
Fuente: Los autores

ingresar la informacin del plan de administracin de requisitos y del documento
de especificacin de requisitos mediante los atributos con que se hayan
configurado las plantillas plan de administracin de requisitos y especificacin
de requisitos de software respectivamente.
162
Figura 97. Panel de priorizacin y ejemplo de reporte completo de priorizacin
Fuente: Los autores

En esta interfaz se muestra la barra de gama de colores en la parte derecha de la
pantalla, esta barra se emplea tambin para visualizar la priorizacin con las
opciones de rango personalizado o un color en el mapa conceptual para poder
obtener una contextualizacin completa del proyecto.
163

nivel 1
Fuente: Los autores

En esta interfaz, el usuario selecciona los elementos o requisitos de nivel 1 que
desea trazar involucrando tanto el uso de colores para indicar la relacin existente
entre los tems trazados, como el uso del mapa conceptual para poder obtener
una contextualizacin completa del proyecto.
164

nivel 2
Fuente: Los autores

Ya seleccionados los elementos o requisitos de nivel 1, se realiza una cosulta por
cada uno de los tems seleccionados para saber que requisitos estn vinculados a
este tem y por cual atributo es que estan vinculados. Finalmente se muestran en
pantalla aquellos que se puedan trazar para que el usuario realice una nueva
seleccin.
165
Figura 100. Panel de Trazabilidad entre elementos y ejemplo de visualizacin de

la trazabilidad
Fuente: Los autores

Finalmente, luego de haber configurado los dos niveles se muestra en pantalla la
trazabilidad. En la anterior figura se ha colocado de ejemplo en el nivel 1
necesidades, en el nivel 2 casos de uso y como resultado en el mapa conceptual
se muestran los requisitos funcionales vinculados a los tems del nivel 1 y2.
166
Figura 101. Panel de diagramas y ejemplo de un diagrama de red con pila de

actividades
Fuente: Los autores

En esta interfaz, el usuario selecciona la opcin de diagramas de red y pila de
actividades del panel diagramas. Una vez da click en el boton aceptar, se muestra
en el rea de trabajo las divisiones para el mapa conceptual como para el
diagrama de red y pila de actividades. Esta segunda divisin consta del diagrama
de red en la parte inferior y en la superior de la tabla pila de actividades que se
compone por las columnas:
Pila de actividades: Es donde aparece a quien esta asignado cada
requisito(En este ejemplo las personas se representan por D1, D2 y D3)
Descripcin: Nombre del requisito
Duracin: Tiempo estimado para desarrollar el requisito
Predecesores: Requisitos que tienen que estar terminados para poder
empezar a desarrollar un requisito.
167
10 ANLISIS Y DISEO DEL MDULO DOCUMENTACIN DE

REQUISITOS
El enfoque que tiene este tercer mdulo es brindar una opcin al equipo de
desarrollo cuando construya el plan de administracin de requisitos y el
documento de especificacin de requisitos. Esto con el fin de ahorrar tiempo y
costo en el proceso de documentacin de los requisitos. En este mdulo estn los
anlisis y diseos de las herramientas necesarias para la configuracin de
plantillas y generacin de los documentos plan de administracin de requisitos y
especificacin de requisitos.
10.1 REQUISITOS FUNCIONALES
Tabla 30. Requisito funcional: El sistema permite crear un proyecto
Id
Requerimiento
de
RF01 El sistema permite crear un proyecto.
Descripcin
El sistema
proyecto.
permite
al
usuario
crear
Entradas
Nombre del proyecto y ubicacin.
Salidas
Se crea la carpeta del proyecto en el

sistema.
Proceso
Accede a la interfaz de administracin de

proyectos Crear proyecto - Ingresa los datos
requeridos - El sistema almacena los datos.
Precondiciones
El sistema haya cargado satisfactoriamente

la interfaz de inicio.
Efectos Colaterales
El proyecto es creado.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 31. Requisito funcional: El sistema permite abrir un proyecto.
Id
Requerimiento
de
RF02 El sistema permite abrir un proyecto.

168
un
Descripcin
El sistema permite al usuario abrir un proyecto

creado.
Entradas
Se selecciona el proyecto abrir.
Salidas
Se abre el proyecto seleccionado.
Proceso

proyectos Abrir un proyecto Selecciona el
proyecto abrir - El sistema abre el proyecto.
Precondiciones
Que el proyecto a abrir se haya creado.
Efectos Colaterales
El sistema muestra el proyecto completo.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 32. Requisito funcional: El sistema permite guardar un proyecto.
Id
Requerimiento
de RF03 El
proyecto.
sistema
permite
guardar
un
Descripcin
El sistema permite al usuario guardar un

proyecto.
Entradas
Datos al proyecto.
Salidas
Se almacena el proyecto al igual que la

carpeta del proyecto.
Proceso

proyectos Guardar un proyecto El sistema almacena el proyecto.
Precondiciones
Que se haya creado un proyecto.
Efectos Colaterales
El sistema guarda el proyecto y crea una

carpeta del proyecto.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores
169
Tabla 33. Requisito funcional: El sistema permite administrar la

plantilla RMP.
Id
Requerimiento

plantilla RMP.
Descripcin
El sistema permite al usuario agregar,

importar,
eliminar
plantillas
y
aadir,
renombrar y cambiar la posicin de un tem.
Entradas
Plantilla tipo RUP.
Salidas
Plantilla configurada.
Proceso
Acceder a la interfaz configurar plantilla RMP

Administrar plantilla Importar la plantilla al
proyecto.
Precondiciones
El proyecto este creado.
Efectos Colaterales
La plantilla configurada es importada al

proyecto.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

plantilla SRS.
Id
Requerimiento

plantilla SRS.
Descripcin

importar,
eliminar
plantillas
y
aadir,
Entradas
Plantilla tipo IEEE 830
Salidas
Proceso
Acceder a la interfaz configurar plantilla SRS

Administrar plantilla Importar la plantilla al
proyecto.
Precondiciones
Efectos Colaterales

proyecto.
Prioridad
Alta.
170
Rol del ejecutor
Usuario.
Fuente: Los autores

plantilla atributos de los requisitos.
Id
Requerimiento

plantilla atributos de los requisitos.
Descripcin

importar,
eliminar
plantillas
y
aadir,
Entradas
Plantilla tipo RUP.
Salidas
Proceso
Acceder a la interfaz configurar plantilla de

atributos de los requisitos
Administrar
plantilla Importar la plantilla al proyecto.
Precondiciones
Efectos Colaterales

proyecto.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

plantilla de tipos de requisitos.
Id
Requerimiento

plantilla de tipos de requisitos.
Descripcin

importar,
eliminar
plantillas
y
aadir,
Entradas
Plantilla tipo RUP.
Salidas
Proceso
Acceder a la interfaz configurar plantilla de

tipos de requisitos Administrar plantilla
Importar la plantilla al proyecto.
Precondiciones

171
Efectos Colaterales

proyecto.
Prioridad
Alta.
Rol del ejecutor
Usuario.
Fuente: Los autores

Tabla 37. Requisito funcional: El sistema permite generar el
documento RMP.
Id
Requerimiento
de RF32
El sistema
documento RMP.
permite
generar
el
Descripcin
El sistema permite al usuario generar el

documento RMP despus de haber aadido
la informacin al proyecto
Entradas
Plantilla configurada e informacin aadida

a ella.
Salidas
Documento RMP.
Proceso

Acceder a la pestaa de documentacin Seleccionar generar RMP - Dar click en el
botn aceptar El sistema genera el
documento.
Precondiciones
Plantilla configurada y informacin aadida a

ella.
Efectos Colaterales
Se genera un documento
Prioridad
Alta
Rol del ejecutor
Usuario
Fuente: Los autores

Tabla 38. Requisito funcional: El sistema permite generar el
documento SRS.
Id
Requerimiento
Descripcin
de RF33
El sistema
documento SRS.
permite
generar
el
El sistema permite al usuario generar el

documento SRS despus de haber aadido
la informacin al proyecto
172
Entradas
Plantilla configurada e informacin aadida

a ella.
Salidas
Documento SRS.
Proceso

Acceder a la pestaa de documentacin Seleccionar generar SRS - Dar click en el
botn aceptar El sistema genera el
documento.
Precondiciones
Plantilla configurada y informacin aadida a

ella.
Efectos Colaterales
Se genera un documento
Prioridad
Alta
Rol del ejecutor
Usuario
Fuente: Los autores

10.2
10.2.1 Casos de uso

Figura 102. Caso de uso administrar proyectos
Fuente: Los autores

Tabla 39. Caso de uso: Administrar Proyectos
Caso de uso
Administrar Proyectos
Actores
Usuario
Propsito
Permitir al usuario abrir, crear y
guardar un proyecto
Resumen
Este caso de uso comienza cuando el
173
usuario decide crear un nuevo

proyecto al sistema o decide abrirlo o
guardarlo.
Precondiciones
El
sistema
haya
cargado
satisfactoriamente
la interfaz de
inicio.
Tipo
Esencial
Referencias
R01,R02,R03
1. Este caso de uso inicia cuando el 2. El sistema muestra el formulario
usuario necesita crear un nuevo correspondiente para la solicitud que
proyecto, abrir un proyecto ya el usuario haya seleccionado
existente, o guardar un proyecto, a)Crear
para ello ingresa a la interfaz b)Abrir
principal del sistema all ingresa al c)Guardar
submdulo Archivo y despus
escoge la opcin a ejecutar.
3. El usuario llena los campos del 4. El sistema verifica que todos los
formulario correspondiente
datos sean consistentes.
Curso Alterno
Accin 4: Si el usuario no ingresa datos consistentes o ingresa incompletos,
el sistema muestra un mensaje solicitando los datos faltantes paso 2
Seccin crear proyecto
1. .El usuario accede a la interfaz de 2. El sistema retorna un formulario
administracin de proyectos y da solicitando el nombre del archivo y la
click en la opcin Crear proyecto
direccin donde se va a guardar
3. El usuario suministra esta 4. El aplicativo crea el proyecto y una
informacin para crear el proyecto
carpeta en el sistema
Curso Alterno
Accin 3: La informacin suministrada por el usuario no es correcta o est
mal escrita, retorna a la interfaz del paso 2 solicitando el nombre del archivo y
la direccin donde se va a guardar
Seccin abrir proyecto
1.El usuario accede a la interfaz de 2. El sistema retorna una interfaz con
administracin de proyectos y da el explorador del sistema
click en la opcin Abrir proyecto
3. El usuario selecciona el proyecto a 4. El sistema abre el proyecto
abrir
Curso Alterno
Accin 3: La Ubicacin suministrada por el usuario no se encuentra, retorna
el mensaje al paso 3 solicitando que se verifique la direccin de ubicacin
174
ingresada
Seccin guardar proyecto
1.El usuario da click en el botn 2. El sistema guarda los cambios
guardar
realizados al proyecto
Figura 103. Caso de uso configurar plantillas
Fuente: Los autores

Tabla 40. Caso de uso: Configurar plantillas
Caso de uso
Configurar plantillas
Actores
Usuario
Propsito
Permitir al
usuario
configurar
plantillas para el proyecto
Resumen
usuario
desea
configurar
las
plantillas, el podr configurar como
quiere que queden sus plantillas de
acuerdo a las necesidades del
proyecto.
El usuario podr configurar 4 tipos de
plantillas.
Precondiciones
Tipo
Esencial
Referencias
R04,R05,R06,R07
1. Este caso de uso inicia cuando el 2. El sistema muestra unas listas de
usuario necesita configurar las plantillas de acuerdo a la plantilla
plantillas a utilizar en el proyecto, seleccionada en el paso numero 1
para ello ingresa a la interfaz
principal del sistema y escoge la
plantilla a configurar.
a)Plantilla RMP
b)Plantilla SRS
c)Plantilla atributos de los requisitos
d)Plantilla de tipos de requisitos
175
3. El usuario configura la plantilla

4.El usuario importa la plantilla
5.El sistema importa la plantilla al

proyecto
Curso Alterno
Seccin plantilla RMP
1.El usuario solicita configurar
2. El sistema muestra una lista de
plantilla RMP
plantillas RMP
3. El usuario seleccionara una
4.El sistema muestra un panel de
plantilla
configuracin de la plantilla
5. El usuario podr realizar las
6. El sistema realizara la accin
siguientes acciones a la plantilla :
solicitada por el usuario
aadir, eliminar, subir, bajar y
renombrar campos
8. El sistema importa la plantilla al
importar plantilla
proyecto
Curso Alterno
Seccin plantilla SRS
plantilla SRS
plantillas SRS
plantilla
renombrar campos
importar plantilla
proyecto
Curso Alterno
Seccin plantilla atributos de los requisitos
plantilla para los atributos de los
plantillas para los atributos de los
requisitos
requisitos
plantilla
176

renombrar campos
importar plantilla
proyecto
Curso Alterno
Seccin plantilla tipos de los requisitos
plantilla para los tipos de los
plantillas para los tipos de los
requisitos
requisitos
plantilla
renombrar campos
importar plantilla
proyecto
Curso Alterno
Fuente: Los autores
Figura 104. Caso de uso generar documentacin
Fuente: Los autores

Tabla 41. Caso de uso: Generar documentacin
Caso de uso
Generar documentacin
Actores
Usuario
Propsito
Permitir al
usuario
generar
documentacin formal del RMP y
SRS
177
Resumen

usuario
desea
generar
la
documentacin de su proyecto
Precondiciones
Haber
aadido
informacin
al
proyecto
Tipo
Esencial
Referencias
R32,R33
1. Este caso de uso inicia cuando el 2. El sistema le muestra las opciones
usuario
desea
generar
la de RMR y SRS
documentacin con la informacin
aadida anteriormente al proyecto,
para esto da click a la pestaa
documentacin
3. El usuario escoge la opcin y da 4. El sistema genera el documento.
click en aceptar
Fuente: Los autores
Los siguientes diagramas de secuencia muestran los objetos del sistema y las
llamadas que se hacen en cada uno de ellos mientras trascurre el tiempo despus
de haber recibido una peticin en el sistema para llevar a cabo una tarea
determinada.
Figura 105. Diagrama de secuencia: Administrar proyecto. Seccin guardar
proyecto
Fuente: Los autores

178
El usuario puede guardar un proyecto , el sistema aplica los cambios al

proyecto,guarda el proyecto y retorna un mensaje de confirmacin.
Figura 106. Diagrama de secuencia: Administrar proyecto. Seccin crear
proyecto
Fuente: Los autores

El usuario puede crear un proyecto, el sistema muestra un formulario de creacin
de proyecto, guarda el proyecto y retorna un mensaje de confirmacin.
179
Figura 107. Diagrama de secuencia: Administrar proyecto. Seccin abrir proyecto
Fuente: Los autores

El usuario puede abrir un proyecto , el sistema retorna un men de exploracin
donde el usuario selecciona el proyecto para que el sistema lo cargue.
Figura 108. Diagrama de secuencia: Configurar plantilla
Fuente: Los autores

180
El usuario puede seleccionar entre las cuatro(4) plantillas a configurar en el

sistema , el sistema le muestra el formato y el usuario configura las plantillas de
acuerdo a sus necesidades.
Figura 109. Diagrama de secuencia: Generar documentacin
Fuente: Los autores

El usuario podra seleccionar el documento a generar, el sistema realiza los
procesos de documentacin y genera el documento.
10.2.3 Diagramas de Colaboracin
181
Figura 110. Diagrama de colaboracin: Configurar plantilla
Fuente: Los autores

El usuario puede seleccionar entre las cuatro(4) plantillas a configurar en el
sistema , el sistema le muestra el formato y el usuario configura las plantillas de
acuerdo a sus necesidades.
Figura 111. Diagrama de colaboracin: Administrar proyecto.
Fuente: Los autores

182
El usuario puede guardar un archivo de mapa conceptual , el sistema aplica los

cambio al proyecto,guarda el proyecto y retorna un mensaje de confirmacin.
El usuario puede abrir un proyecto , el sistema retorna un men de exploracin
donde el usuario selecciona el proyecto para que el sistema lo cargue.
El usuario puede crear un proyecto, el sistema muestra un formulario de creacin
de proyecto, guarda el proyecto y retonra un mensaje de confirmacin.
Figura 112. Diagrama de colaboracin: Generar documentacin
Fuente: Los autores

El usuario puede seleccionar el documento a generar, el sistema realiza los
procesos de documentacin y genera el documento.
10.3 DOCUMENTACIN REFERENTE AL DISEO
Vale la pena aclarar que en esta documentacin referente al diseo se han
aadido diagramas que representan la estructura del sistema, ms no nicamente
la de este tercer mdulo, se decide ubicarlos a partir de la seccin 10.3.2 porque
su construccin parte de los diagramas elaborados en este y dems mdulos
anteriores:
183
10.3.1 Interfaces de usuario

Figura 113. Abrir o crear proyecto.
Fuente: Los autores

En esta interfaz se permite abrir o iniciar el proyecto.
184
Figura 114. Configuracin plantilla: Plan de administracin de requisitos.
Fuente: Los autores

En la interfaz se muestra un ejemplo de configuracin de las secciones que
componen el plan de administracin de requisitos segn la metodologa RUP. En
el anexo 1 estn listadas y explicadas las secciones que propone dicha
metodologa.
185
Figura 115. Configuracin plantilla: Especificacin de requisitos de software
Fuente: Los autores

En la interfaz se muestra un ejemplo de configuracin de las secciones del
documento de especificacin de requisitos segn el estndar IEEE-830.
186
Figura 116. Configuracin plantilla: Atributos de los requisitos
Fuente: Los autores

En la interfaz se muestra un ejemplo de configuracin de los atributos de los
requisitos segn la metodologa RUP, en estos atributos es donde se guarda la
informacin relevante de los requisitos para el proyecto de software. En el anexo 1
estn listados y explicados los atributos de los requisitos que propone dicha
metodologa.
187
Figura 117. Configuracin plantilla: Tipos de requisitos
Fuente: Los autores

En la interfaz se muestra un ejemplo de configuracin de los tipos de requisitos
segn la metodologa RUP, con estos tipos de requisitos se categorizan los
requisitos del proyecto de software para facilitar su administracin y
entendimiento. En el anexo 1 estn listados y explicados los atributos de los
requisitos que propone dicha metodologa.
188
Figura 118. Panel para generar los documentos formales del proyecto
Fuente: Los autores

En el anexo 1 se encuentran explicadas las posibles secciones del documento del
plan de administracin de requisitos. Esta plantilla es basada en la metodologa
RUP y es utilizada como ejemplo para hacer las configuraciones de las plantillas
Plan de administracin de requisitos, Atributos de los requisitos y Tipos de
requisitos, dicha configuracin es la que se mostr en las imgenes anteriores.
189
10.3.2 Diagrama de clases y diccionario de clases

Figura 119. Diagrama de clases parte 1
Fuente: Los autores
190
Fuente: Los autores

191
Fuente: Los autores

192
Figura 122. Clase: Interface de usuario
Fuente: Los autores

Tabla 42. Descripcin de la clase: Interface de usuario
Clase
Interface de usuario
Descripcin
Interface de creacin de proyecto y de procesos de
trazabilidad
Atributos
Nombre
Tipo
Descripcin
Panel_administrar_proyecto
Menu
Menu(nuevo,abrir,guardar)
Panel_configurar_plantilla
Menu
Menu administrar plantilla
Panel_trazabilidad
Menu
Panel_priorizacion
Menu
Panel_diagramacion
Menu
Panel_documentacion
Menu
Menu
para
configurar
Menu
para
configurar
Menu
para
configurar
Menu para seleccionar
documento a generar
Mtodos
Nombre
actualizar_interface()
mostrar_trazabilidad()
mostrar_priorizacin()
mostrar_diagramas()
Fuente: Los autores
Propsito
Mostrar los cambios en las interface
Mostrar trazabilidad
Mostrar priorizacin
Mostrar diagramas
193
Figura 123. Clase: Controlador de proyectos
Fuente: Los autores

Tabla 43. Descripcin de la clase: Controlador de proyectos
Clase
Controlador de proyectos
Descripcin Realiza la gestin de proyectos entre a interface y el almacn de
proyectos
Mtodos
Nombre
Propsito
gestiona_proyectos
Satisfacer solicitudes entre la interface y
el almacn de proyecto
valida_datos
Valida datos de creacin del proyecto
Fuente: Los autores
Figura 124. Clase: Controlador plantillas
Fuente: Los autores

Tabla 44. Descripcin de la clase: Controlador plantillas
Clase
Controlador plantillas
Descripcin
Se encarga de la gestin de plantillas y elementos
procesos
Mtodos
194
para
Nombre
gestionar_plantillas()
agregar_plantilla()
importar_plantilla()
gestionar_formato_especificacion()
gestionar_plantillas_a_configurar()
gestionar_lista_de_elementos
gestionar_informacion_elementos_vinculados
Fuente: Los autores
Figura 125. Clase: Interface de gestor grafico
Fuente: Los autores
195
Propsito
Satisfacer
peticiones
de
la
interface a donde se almacenan
las plantillas
Enva plantillas configuradas para
usarlas posteriormente
Agrega la plantilla configurada al
proyecto
Gestionar el formato para la
especificacin de un requisito
Gestionar plantilla para el proceso
de configuracin
Gestionar elementos para el
Gestionar elementos vinculados
para el proceso de trazabilidad
Tabla 45. Descripcin de la clase: Interface de gestor grafico

Clase
Interface de gestor grafico
Descripcin
Interface principal para construir una imagen enriquecida,
agregar definiciones raices y requisitos obtenidos
Atributos
Nombre
Tipo
Descripcin
Panel_administar_imagen
Menu
Panel_inserta_imagenes
Menu
Panel para selecciona
imgenes prediseadas o
del proyecto
Panel_herramientas de dibujar
Menu
Menu con herramientas
para dibujar
Panel_opciones de edicin
Menu
Menu con opciones de
edicinn
Panel_paleta_de_colores
Menu
Menu para seleccionar
color primari y secundario
Panel__herramientas_de_dibujo
Menu
Menu con herramientas de
dibujo
Panel_administrar_definiciones_raices Menu
Menu en el cual se
administrar y se muestran
definiciones races
Panel_aministrar_requisitos_ontenidos Menu
Menu para activar la
herramienta para agregar
requisitos
obtenidos
y
administrarlos
Mtodos
Nombre
Propsito
mostrar_area_de_trabajo_en_blanco
Se crea rea de trabajo en blanco
cargar_imagen
Abrir una imagen ya creada
actualiza_interface
Muestra cambios en la interface
despus de haber usado opciones
o herramientas sobre la imagen
mostrar_lista_requisitos_obtenidos
Mostrar en una lista los requisitos
obtenidos
mostrar_ventana_de_ecploracin
Abrir directorio para cargar una
imagen
Fuente: Los autores
196
Figura 126. Clase: Controlador imagen enriquecida
Fuente: Los autores

Tabla 46. Descripcin de la clase: Controlador imagen enriquecida
Clase
Controlador imagen enriquecida
Descripcin Gestionar la administracin del archivo de imagen enriquecida
Mtodos
Nombre
Propsito
gestionar_imagen
Gestionar el archivo de imagen
enriquecida(abrir, nuevo, guardar)
agregar_imagen_al_proyecto
Enviar el archivo de imagen enriquecida
al proyecto
Fuente: Los autores
Figura 127. Clase: Imagen enriquecida
Fuente: Los autores

Tabla 47. Descripcin de la clase: Imagen enriquecida
Clase
Imagen enriquecida
Descripcin Crea la imagen enriquecida y aplica los cambios realizados en el
rea de trabajo
Atributos
Nombre
Tipo
Descripcin
nombre
integer
Nombre de la imagen
tamao
integer
Define tamao de la imagen
197
Metodos
Nombre
crea_imagen_enriquecida
Aplicar_cambios_a_imagen
Propsito
Crea imagen enriquecida
Aplica los cambios a la
realizados en el rea de trabajo
imagen
Fuente: Los autores

Figura 128. Clase: Controlador imgenes
Fuente: Los autores

Tabla 48. Descripcin de la clase: Controlador imgenes
Clase
Controlador imgenes
Descripcin Encargado de la gestin de imgenes prediseadas e imgenes de
galeria de proyecto
Metodos
Nombre
Propsito
gestionar_imagen_prediseada
Gestionar las imgenes prediseadas
Gestionar_imagen_galeria
Gestionar las imgenes de la galera del
proyecto
Fuente: Los autores
198
Figura 129. Clase: Imgenes prediseadas
Fuente: Los autores

Tabla 49. Descripcin de la clase: Imgenes prediseadas
Clase
Imgenes prediseadas
Descripcin Constructor de figuras
Atributos
Nombre
Tipo
Descripcin
Tamao
float
Define el tamao de la
imagen
Posicin
float
Define la posicin de la
imagen
Mtodos
Nombre
Propsito
enviar_imagen()
Enviar imagen al controlador
circulo()
Construye figura circulo
rectangulo()
Construye figura de triangulo
nube1()
Construye tipo de nube
nube2()
Construye tipo de nube
rayo()
Construye rayo
Fuente: Los autores
199
Figura 130. Clase: Herramientas de dibujar
Fuente: Los autores

Tabla 50. Descripcin de la clase: Herramientas de dibujar
Clase
Herramientas de dibujar
Descripcin Activar herramientas de dibujar
Atributos
Nombre
Tipo
Descripcin
valor_grosor
Float
Define el grosor
valor_tipo
Float
Define el tipo
Mtodos
Nombre
dibujar()
relleno()
tipo()
grosor()
texto()
Fuente: Los autores
Propsito
Dibujar en el rea de trabajo lneas o
curvas de forma
Colorear relleno
Selecciona el tipo de lnea
Selecciona el tamao del grosor
Permite insertar texto
200
Figura 131. Clase: Opciones de edicin
Fuente: Los autores

Tabla 51. Descripcin de la clase: Opciones de edicin
Clase
Opciones de edicin
Descripcin Activar herramientas de dibujar
Mtodos
Nombre
Propsito
pegar()
Pegar
una
porcin
seleccionada
anteriormente
cortar()
Copiar una porcin del rea de trabajo
copiar()
Cortar una porcin del rea de trabajo
seleccionar()
Selecciona una porcin
girar()
Girar un rea seleccionada
acercar()
Realizar un zoom
alejar()
Retroceder zoom
Fuente: Los autores
Figura 132. Clase: Herramientas de dibujo
Fuente: Los autores

201
Tabla 52. Descripcin de la clase: Herramientas de dibujo

Clase
Herramientas de dibujo
Descripcin Activar herramientas de dibujo
Mtodos
Nombre
Propsito
Retornar una o varias acciones realizadas al
deshacer()
dibujo
Retornar una o varias acciones realizadas al
dibujo
Proporcionar una regla vertical y horizontal
en el rea de trabajo
Ubicar una cuadricula sobre el rea de
trabajo
rehacer()
regla()
cuadricula()
Fuente: Los autores
Figura 133. Clase: Paleta de colores
Fuente: Los autores

Tabla 53. Descripcin de la clase: Paleta de colores
Clase
Paleta de colores
Descripcin Seleccionar el color primario, secundario y capturar un color
Atributos
Nombre
Tipo
Descripcin
valor_color_primario
String
Contiene el valor del color
valor_color_secundario
String
Contiene el valor del color
color_selector
Mtodos
Nombre
String
Contiene al valor del color

selector
Propsito
202
seleccionar_color_primario
seleccionar_color_secundario
color_selector
Fuente: Los autores
Asignar un color como primario

Asignar un color secundario
Seleccionar un color del rea de trabajo
Figura 134. Clase: Controlador definiciones races
Fuente: Los autores

Tabla 54.
Descripcin de la clase: Controlador definiciones races
Clase
Controlador definiciones races
Descripcin Se encarga de la gestin para administrar las definiciones races
Mtodos
Nombre
Propsito
Gestionar_definiciones _races
Realiza la gestin para la administracin
de definiciones races
Fuente: Los autores
Figura 135. Clase: Almacn definiciones races
Fuente: Los autores

Tabla 55. Descripcin de la clase: Almacn definiciones races
Clase
Almacn definiciones races
Descripcin Administrar las definiciones raices
203
Atributos
Nombre
id_definicion
definicin_raiz
Mtodos
Nombre
eliminar_definicion_raiz()
guardar_definicion_raiz()
modificar_definicion_raiz()
Fuente: Los autores
Tipo
Integer
String
Descripcin
Id de la definicin raz
Cadena de definicin raz
Propsito
Elimina la definicin raz
Guarda la definicin raz
Modificar la definicin raz
Figura 136. Clase: Controlador requisitos obtenidos
Fuente: Los autores

Tabla 56. Descripcin de la clase: Controlador requisitos obtenidos
Clase
Controlador requisitos obtenidos
Descripcin
Se encarga de la gestin para administrar los requisitos
obtenidos y para su validacin
Mtodos
Nombre
Propsito
validar_requisito
Realiza la gestin y valida el
requisito
gestionar_requsito_obtenido
Realiza la gestin para la
administracin
de
requisitos
obtenidos
verificar_la_inclusion_de_requisitos_obtenidos Verificar la inclusin de requisitos
obtenidos en la lista de requisitos
Fuente: Los autores
204
Figura 137. Clase: Requisitos obtenidos
Fuente: Los autores

Tabla 57. Descripcin de la clase: Requisitos obtenidos
Clase
Requisitos obtenidos
Descripcin Administrar y validar los requisitos obtenidos
Atributos
Nombre
Tipo
Descripcin
id_requisito
Integer
Id de la definicin raz
nombre_requisito
String
Cadena
de
requisito
obtenido
formulario_validacion
Form
Formulario de validacin
Mtodos
Nombre
guardar_requisitos
borrar_requisitos
Modificar_requisitos
enviar_lista()
enviar__formulario_validacion()
Fuente: Los autores
Propsito
Guarda el requisito obtenido
Elimina el requisito obtenido
Modifica el requisito obtenido
Enva lista de requisitos obtenidos
Enva formulario de validacin
205
Figura 138. Clase: Interface mapa conceptual
Fuente: Los autores

Tabla 58. Descripcin de la clase: Interface mapa conceptual
Clase
Interface mapa conceptual
Descripcin
Interface principal para construir un mapa conceptual ,
crear y especificar requisitos ye ingresar informacin a
las plantillas
Atributos
Nombre
Tipo
Descripcin
Panel_administrar_mapa_conceptual Menu
Panel_editor_de_requisitos
Panel
Panel el cual permite
ingresar texto con el cual
se
puede
ingresar
requisitos y sub requisitos
Mtodos
Nombre
actualiza_interface
Propsito
Muestra cambios en el mapa
conceptual
Muestra
lista
de
requisitos
obtenidos actualizados
Dibuja el requisito creado en el
editor de requisitos
actualizar_lista_requisitos_obtenidos
dibujar_requisito
206
actualizar_editor_de_requisitos
Actualiza lista de requisitos del

editor
Crear,eliminar, y modificar palabra
de enlace
Crear,eliminar, y modificar enlace
cruzado
Muestra el directorio del proyecto
con las plantillas a editar
Pedir formato de especificacin
administrar_palabra_de_enlace
administrar_enlace cruzado
mostrar_plantillas_a_editar
solicitar_formato_especificacin
Fuente: Los autores
Figura 139. Clase: Controlador mapa conceptual
Fuente: Los autores

Tabla 59. Descripcin de la clase: Controlador mapa conceptual
Clase
Controlador mapa conceptual
Descripcin Gestionar la administracin del archivo de mapa conceptual
Mtodos
Nombre
Propsito
gestionar_mapa_conceptual
Gestionar
el
archivo
de
mapa
conceptual(abrir, nuevo, guardar)
Importar_al_proyecto
Enviar el archivo de mapa conceptual al
proyecto
Fuente: Los autores
Figura 140. Clase: Imagen enriquecida
Fuente: Los autores

207
Tabla 60. Descripcin de la clase: Imagen enriquecida

Clase
Imagen enriquecida
Descripcin Crea la imagen enriquecida y aplica los cambios realizados en el
area de trabajo
Atributos
Nombre
Tipo
Descripcin
nombre
integer
Nombre de la imagen
tamao
integer
Define tamao de la imagen
Mtodos
Nombre
crea_imagen_enriquecida
Aplicar_cambios_a_imagen
Propsito
Aplica los cambios a la
imagen
Fuente: Los autores

Figura 141. Clase: Controlador pregunta de enfoque
Fuente: Los autores

Tabla 61. Descripcin de la clase: Controlador pregunta de enfoque
Clase
Controlador pregunta de enfoque
Descripcin Gestiona la creacin de una pregunta de enfoque en la barra
superior de la interface de mapa conceptual
Mtodos
Nombre
Propsito
gestionar_pregunta_de_enfoque
Gestionar la pregunta de enfoque para al
el mapa conceptual
Fuente: Los autores
208
Figura 142. Clase: Pregunta de enfoque
Fuente: Los autores

Tabla 62. Descripcin de la clase: Pregunta de enfoque
Clase
Pregunta de enfoque
Descripcin Administrar pregunta de enfoque
Atributos
Nombre
Tipo
Descripcin
id_pregunta_de_enfoque
Integer
Id de pregunta de enfoque
pregunta_de_enfoque
String
Cadena
pregunta
de
enfoque
Mtodos
Nombre
Propsito
administras_pregunta_de_enfoque
Guardar, eliminar y modificar la pregunta
de enfoque
Fuente: Los autores
Figura 143. Clase: Controlador de requisito
Fuente: Los autores
209
Tabla 63. Descripcin de la clase: Controlador de requisito

Clase
Controlador de requisito
Descripcin
Gestiona la creacin de requisitos, gestiona la
informacin para procesos de administracin,
gestiona informacin de requisitos y realiza clculos,
gestiona formato de especificacin
Mtodos
Nombre
Propsito
gestionar_requisitos
Gestionar la administracin
de requisitos
gestionar_informacin_para_procesos
Gestionar informacin para
procesos de administracin
gestionar_informacion_de_atributos_de_requisitos Gestionar informacin de
atributos
de
requisitos
creados y especificados
gestionar_formato_especificacin_de_requisitos
Gestiona
formato
de
especificacin de requisitos
calcular_atributos
Realiza clculos con los
atributos de requisitos para
los
procesos
de
administracin
proceso_visualizacion
Realiza
proceso
para
visualizar la priorizacin
Fuente: Los autores
Figura 144. Clase: Requisitos
Fuente: Los autores

210
Clase
Descripcin
Tabla 64. Descripcin de la clase: Requisitos

Requisitos
Administrar requisitos, administrar especificacin de
requisitos, administrar informacin, consultas de
requisitos vinculados
Atributos
Nombre
id_requisito
requisito
Tipo
Integer
String
Descripcin
Id de requisito
Cadena de requisito
posicion
Integer
Posicin de requisito
formulario_especificacion_de_requisitos
Form
Formulario
especificacin
requisito
Mtodos
Nombre
administrar_requisitos
administrar_especificacin_de_requisitos
administrar_informacion
consulta_de_requisitos_vinculados
reposicion_requisito
Propsito
Crear, guardar, eliminar y
modificar los requisitos
Administrar el formato de
especificacin de requisitos de
un requisito
Administrar informacin de
atributos de requisitos
Realiza
consultas
de
informacin
para
realizar
procesos de administracin
Modificar la posicin del
requisito
Fuente: Los autores

Figura 145. Clase: Controlador de palabra de enlace
Fuente: Los autores

Tabla 65. Descripcin de la clase: Controlador de palabra de enlace
Clase
Controlador de palabra de enlace
Descripcin
Gestionar la administracin de las palabras enlace
211
de
de
Mtodos
Nombre
gestionar_palabra_de_enlace
Propsito
Gestionar
para
la
administracin de las palabras
de enlace
Fuente: Los autores

Figura 146. Clase: Palabra de enlace
Fuente: Los autores

Tabla 66. Descripcin de la clase: Palabra de enlace
Clase
Palabra de enlace
Descripcin Administrar palabras de enlace, y cambiar su posicin
Atributos
Nombre
Tipo
Descripcin
id_palabra_de_enlace
Integer
Id de palabra de enlace
palabra_de_enlace
String
Cadena de palabra de
enlace
posicion
Integer
Posicin palabra de enlace
Mtodos
Nombre
guardar_palabra_de_enlace()
eliminar_palabra_de_enlace
modificar_palabra_de_enlace
reposicion_palabra_
Propsito
Guardar palabra de enlace
Eliminar palabra de enlace
Modificar el nombre de la palabra de
enlace
Modificar la posicin de la palabra de
enlace
Fuente: Los autores
212
Figura 147. Clase: Controlador enlace cruzado
Fuente: Los autores

Tabla 67. Descripcin de la clase: Controlador enlace cruzado
Clase
Controlador enlace cruzado
Descripcin
Gestionar la administracin de los enlaces cruzados
Mtodos
Nombre
Propsito
gestionar_palabra_de_enlace
Gestionar
para
la
administracin
del
enlace
cruzado
Fuente: Los autores
Figura 148. Clase: Enlace cruzado
Fuente: Los autores

Tabla 68. Descripcin de la clase: Enlace cruzado
Clase
Enlace cruzado
Descripcin Administrar enlaces cruzados
Atributos
Nombre
Tipo
Descripcin
Id_enlace_cruzado
Integer
Id de enlace cruzado
palabra_de_enlace
String
Cadena de enlace cruzado
requisito_asociado
Integer
Id del requisito al cual se

213
asocia el enlace cruzado

Mtodos
Nombre
guardar_ enlace_cruzado()
eliminar_enlace_cruzado
modificar_enlace_cruzado
Fuente: Los autores
Propsito
Guardar_enlace_cruzado
Eliminar enlace cruzado
Modificar el nombre de el enlace cruzado
Figura 149. Clase: Controlador trazabilidad
Fuente: Los autores

Tabla 69. Descripcin de la clase: Controlador trazabilidad
Clase
Controlador trazabilidad
Descripcin
Gestionar la informacin para el
y realizar
procesos de esta informacin para
realizar el proceso de trazabilidad
Mtodos
Nombre
Propsito
gestionar_informacin_de_requisitos_par Gestionar
la informacin de los
a_proceso_de_trazabilidad
requisitos necesaria para realizar este
proceso
gestionar_informacion_de_plantillas_par Gestionar
la informacin de las
a_proceso_de_trazabilidad
plantillas necesarias para realizar este
proceso
realizar_proceso_de_informacion
Procesar la informacin del proceso de
trazabilidad
para
posteriormente
mostrarla en la interface
Fuente: Los autores
214
Figura 150. Clase: Controlador priorizacin
Fuente: Los autores

Tabla 70. Descripcin de la clase: Controlador priorizacin
Clase
Controlador priorizacin
Descripcin
y realizar
realizar el proceso de trazabilidad
Mtodos
Nombre
Propsito
gestionar_informacin_de_atributos_de_ Gestionar
requisitos
atributos de los requisitos necesaria
para realizar este proceso
calcular_priorizacion_tiempo_faltante
Procesar informacin del atributo
tiempo faltante para la entrega para el
calcular_priorizacion_dificultad
Procesar informacin del atributo
dificultad
para
el
proceso
de
priorizacin
realizar_proceso_para_visualizar
Procesar la informacin del proceso de
priorizacin
para
posteriormente
visualizarla
Fuente: Los autores
215
Figura 151. Clase: Controlador diagramacin
Fuente: Los autores

Tabla 71. Descripcin de la clase: Controlador diagramacin
Clase
Controlador diagramacin
Descripcin
proceso de diagramacin y realizar
realizar el proceso de diagramacin
Mtodos
Nombre
Propsito
gestionar_informacin_de_ requisitos
Gestionar
atributos de los requisitos necesaria
para realizar este proceso
calcular_duracin_de_requisito
Procesar informacin para calcular la
duracin
para el proceso de
diagramacin
elaborar_pila_de_actividades
Organizar informacin para elaborar
pila de actividades
elaborar_diagrama_de_red
Organizar informacin para elaborar
diagrama de red
Fuente: Los autores
216
Figura 152. Clase: Controlador documentacin
Fuente: Los autores

Tabla 72. Descripcin de la clase: Controlador documentacin
Clase
Controlador documentacin
Descripcin Controlar los procesos para generar el documento
Atributos
Nombre
Tipo
Descripcin
Formato_srs
Form
Formato de documento srs
Formato_rmp
Form
Formato de documento rmp
Mtodos
Nombre
gestionar_informacin_requisitos
gestionar_informacion_plantillas
organizar_informacin_requisitos
organizar_informacin_plantillas
generar _documento
Fuente: Los autores
Propsito
Gestionar la informacin necesaria de
los requisitos para generar el documento
Gestionar la informacin necesaria de
las plantillas para generar el documento
Organiza la informacin de los requisitos
en el formato del documento
Organiza la informacin de las plantillas
en el formato del documento
Genera el documento
217
Clase: Mapa conceptual
Fuente: Los autores

Descripcin de la clase: Mapa conceptual
Clase
Mapa conceptual
Descripcin Crea el mapa conceptual y aplica los cambios realizados en el rea
de trabajo
Atributos
Nombre
Tipo
Descripcin
nombre
integer
Nombre
del
mapa
conceptual
Mtodos
Nombre
Propsito
crea_im_enriquecida
aplicar_cambios_a_mc
Aplica los cambios al mapa conceptual
Fuente: Los autores
218
10.3.3 Modelo de la base de datos

Figura 153. Modelo de la base de datos para el sistema
Fuente: Los autores

El modelo de la base de datos del sistema cuenta con tablas dinmicas , con el
propsito de que el usuario pueda configurar las plantillas del proyecto de
acuerdo a sus necesidades, de esta forma el sistema permite al usuario agregar o
eliminar atributos, secciones, campos para valores, campos para describir las
secciones o atributos de las plantillas.
219
10.3.4 Diagrama de componentes

Figura 154. Diagrama de componentes para el sistema
Figura 155. Fuente: Los autores
220
11 VALIDACIN DE LA HIPTESIS
La hiptesis del presente trabajo de grado se valida a partir de la siguiente
encuesta realizada a dos grupos de estudiantes de ingeniera de sistemas de la
asignatura laboratorio de software de la Universidad Tecnolgica de Pereira:
Esta encuesta se realiza para corroborar que un software puede ser implementado
a partir de un conjunto de vistas del software y a su vez poder evaluar la hiptesis
del trabajo de grado: Anlisis y diseo de una herramienta grfica para los
procesos de la ingeniera de requisitos. De ante mano le agradecemos por
brindarnos un momento de su tiempo y responder las siguientes preguntas:
1. Considera usted que el siguiente conjunto de vistas del software son suficientes
para implementar un software de escritorio:
Requisitos funcionales
Casos de uso
Diagramas de secuencia
Diagramas de colaboracin
Interfaces de usuario
Diagrama de clases
Diagrama de despliegue
Diagrama de componentes
Modelo de la base de datos
SI
NO
2. Responda esta pregunta solamente si su respuesta a la pregunta anterior fue

NO. Que otro(s) diagrama(s) falta(ran) para implementar un software de
escritorio?
Se hizo una muestra de 25 personas de las cuales el 100% respondi SI en la

pregunta 1. Como la encuesta arroj un 100%, se puede corroborar que este
221
conjunto de vistas del software son suficientes para implementar un software de

escritorio, se procede a listar los indicadores con el nombre de las figuras o tablas
donde se elaboraron las respectivas vistas de software:
Est especificado un caso de uso que permita crear y administrar

imgenes enriquecidas, con el que el sistema cuente con herramientas
necesarias para aplicar los estadios de la SSM a los procesos de anlisis y
obtencin de requisitos? En la tabla 10 Caso de uso: Administrar imagen
enriquecida., se elabor el referido caso de uso
Existe el requisito funcional o requisitos funcionales que permitan al

usuario comprender e identificar las necesidades de un proyecto de
software por medio de una imagen enriquecida, para de este modo
establecer el qu se va hacer segn la SSM? En las tablas 2 Requisito
funcional: El sistema permite insertar figuras, 3 Requisito funcional: El
sistema permite utilizar las herramientas de dibujar, 4 Requisito funcional:
El sistema permite utilizar las opciones de edicin, 5 Requisito funcional:
El sistema permite utilizar las opciones de paleta de colores y 6 Requisito
funcional: El sistema permite utilizar las herramientas de dibujo se
elaboraron los referidos requisitos funcionales
Existe la interfaz o interfaces para implementar el concepto de

preposiciones de la teora de los mapas conceptuales? En las Figuras 93
Ejemplo de un mapa conceptual elaborado a partir de la especificacin de
requisitos y 94 Ejemplo de uso de la herramienta enlace cruzado se
elabororaron las referidas interfaces
Existen las interfaces para llevar a cabo el proceso de trazabilidad que

involucre tanto el uso de colores para indicar la relacin existente entre los
tems trazados, como el uso del mapa conceptual para poder obtener una
contextualizacin completa del proyecto? En las figuras 98 Panel de
Trazabilidad entre elementos y ejemplo de configuracin del nivel 1, 99
Panel de Trazabilidad entre elementos y ejemplo de configuracin del nivel
2 y 100 Panel de Trazabilidad entre elementos y ejemplo de visualizacin
de la trazabilidad se elabororaron las referidas interfaces
Existe el requisito funcional o requisitos funcionales donde el sistema

permita al usuario crear requisitos en el mapa conceptual y en el
documento de especificacin de requisitos del proyecto? En las tablas 13
222
Requisito funcional: El sistema permite administrar los requisitos creados

y 21 Requisito funcional: El sistema permite la especificacin de los
requisitos creados se elaboraron los referidos requisitos funcionales
Existe la interfaz de usuario para llevar a cabo la visualizacin del proceso

de priorizacin mediante el uso de colores en el mapa conceptual para
poder obtener una contextualizacin completa del proyecto? En la figura 97
Panel de priorizacin y ejemplo de reporte completo de priorizacin se
elabor la referida interfaz
Existe el diagrama de secuencia para generar el documento RMP, a partir

de la configuracin e informacin guardada en esta plantilla? En la figura
109 Diagrama de secuencia: Generar documentacin se elabor el
referido diagrama de secuencia.
Existe el diagrama de colaboracin para generar el documento de

especificacin de requisitos, a partir de la configuracin e informacin
guardada en esta plantilla? En la figura 112 Diagrama de colaboracin:
Generar documentacin se elabor el referido diagrama de colaboracin.
223
12 CONCLUSIONES
Al trmino de este trabajo y examinando el cumplimiento de los objetivos
inicialmente planteados se puede concluir que:
Se cumpli con el objetivo general, el cual era, desarrollar el anlisis y

diseo de un gestor grfico de requisitos.
Referente al objetivo especfico del anlisis y diseo para el mdulo desarrollo de

requisitos se concluye que:
Se present el anlisis y diseo de una solucin a los problemas de
articulacin, tcnicos y de comunicacin presentes en el proceso de

desarrollo de requisitos a travs de la implementacin de la metodologa de
sistemas blandos.
Con la utilizacin de la metodologa de sistemas blandos se le brinda al
usuario gran libertad para dibujar la estructura, los procesos y los

elementos que hacen parte de un sistema en estudio, para de esta forma
determinar el qu se va a trabajar en el proyecto de software. Al principio,
cuando se estaba elaborando el marco terico del trabajo se pretendi
utilizar los mapas mentales para dar cumplimiento a este objetivo
especfico, pero la poca libertad ofrecida para dibujar produjo que se
cambiara a la metodologa de sistemas blandos.
Referente al objetivo especfico del anlisis y diseo para el mdulo administracin

de requisitos se concluye que:
Se present el anlisis y diseo de una solucin al problema de

comunicacin interna para el equipo de desarrollo a travs de la
implementacin de los mapas conceptuales, para indicar cmo se van a
trabajar los requisitos en un proyecto de software, permitiendo a la vez la
modificacin y administracin de los requisitos.
Con la utilizacin de los mapas conceptuales se le brinda al equipo de

desarrollo un ambiente visual de trabajo, en donde, en un mismo contexto
224
se pueden observar los requisitos de un proyecto de software con sus

respectivas relaciones o influencias entre ellos para que se facilite la toma
de decisiones.
Referente al objetivo especfico del anlisis y diseo para el mdulo
documentacin de requisitos se concluye que:
Se realiz el anlisis y diseo para generar los documentos de

especificacin de requisitos y del plan de administracin de requisitos. En
este anlisis y diseo se incluy la configuracin de las plantillas Plan de
administracin de requisitos, Atributos de los requisitos, Tipos de
requisitos y Documento especificacin de requisitos. Las cuales fueron
necesarias para la generacin de dichos documentos.
Se realiz un nico diagrama de clases para los tres mdulos y se decide

ubicarlo en la parte final de este mdulo porque su construccin parti de
los dems diagramas elaborados en este trabajo. El motivo por el que solo
se realiz un nico diagrama de clases para el sistema en general y no un
diagrama de clases por mdulo fue que algunas clases de los mdulos
desarrollo de requisitos y documentacin de requisitos estaban vinculadas
con clases del mdulo administracin de requisitos.
225
13 RECOMENDACIONES
Referente a las sugerencias de funcionalidades y mejoras futuras que se han

identificado en la elaboracin de este trabajo de grado hay:
Realizar un mdulo de gestin de cambios en los requisitos.
Realizar un mdulo de control de versiones.
Realizar un mdulo para la gestin de perfiles de usuario. Un proceso a

mejorar con este mdulo sera el de la validacin del entendimiento de
requisitos.
Realizar la funcionalidad de la ruta crtica del proyecto.
Permitir al usuario personalizar la plantilla de las definiciones races segn

las necesidades que surjan al implementar la metodologa de sistemas
blandos al proyecto de software en el que se est trabajando.
Permitir al usuario cambiar la fuente y el tamao de la letra.
Permitir al usuario cambiar el tamao de la herramienta borrador.
Permitir al usuario cambiar la forma de los enlaces cruzados y palabras de

enlace.
Permitir al usuario agregar o cambiar los valores en el proceso de

priorizacin, segn el tiempo de entrega o nivel de dificultad que l
considere crtico o difcil respectivamente.
Permitir al usuario selecciona los colores con los cuales se vaya realizar el
proceso de trazabilidad.
Brindar otras opciones de visualizacin para mapas conceptuales grandes.

Las opciones de visualizacin que se proponen son el uso de pestaas,
divisiones de pantalla, ocultar/mostrar zonas del mapa conceptual.
Integrar este trabajo de grado que cubre el rea de la ingeniera de

requisitos con otros mdulos que cubran las dems reas o etapas de un
proyecto de software, como lo son la gestin de proyectos, el diseo del
software, el desarrollo del software, etc. Para as lograr en un futuro la
construccin de una herramienta grfica para los proyectos de software.
226
Migrar el aplicativo a una arquitectura web y multiusuario y de esta forma

los usuarios tengan mayores facilidades para acceder al proyecto.
227
14 BIBLIOGRAFA
ACOSTA QUINTANA, Mara Paz. INSTITUTO TECNOLGICO DE SONORA
Materia: Ingeniera de Sistemas III UNIDAD I. METODOLOGA DE SISTEMAS
SUAVES DE Checkland
ivan_1.tripod.com/sitebuildercontent/sitebuilderfiles/metodologiadesistemassuaves
.doc (Consulta: 12 de Julio. 2011)
ANAYA, Victor & LETELIER, Patricio. SmarTTrace Una Herramienta para
Trazabilidad de Requisitos en Proyectos basados en UML
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.9907 (Consulta: 22 de
Junio. 2011)
ARTEAGA PACHECO, Carlos Mario. Unidad 2: La propuesta , de la materia
Proyecto de Grado I. 2009-II
AUSUBEL, D. (1963). The Psychology of Meaningful Verbal Learning. New
York: Grune & Stratton.
AUSUBEL, D. P. Educational psychology: A cognitive view, Holt, Rinehart and
Winston, Nueva York, 1968.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.2090&rep=rep1&type
=pdf (Consulta: 03 de Agosto. 2011)
Campus Virtual de la Pontificia Universidad Catlica de Valparaso. Construccin
del mapa mental.
http://icc.ucv.cl/geotecnia/ (Consulta: 03 de Agosto. 2011)
CAAS, Alberto y NOVAK, Joseph. Institute for Human and Machine Cognition.
Qu es un Mapa Conceptual?
http://cmap.ihmc.us/docs/MapaConceptual.html (Consulta: 03 de Agosto. 2011)
CAAS, Alberto y NOVAK, Joseph. Institute for Human and Machine Cognition.
Qu es un Concepto? ... desde la Perspectiva de los Mapas Conceptuales.
http://cmap.ihmc.us/docs/Concepto.html (Consulta: 03 de Agosto. 2011)
228
CAAS, Alberto. Institute for Human and Machine Cognition. Qu son las
Palabras de Enlace? ... desde la Perspectiva de los Mapas Conceptuales.
http://cmap.ihmc.us/docs/PalabrasDeEnlace.html (Consulta: 04 de Agosto. 2011)
CAAS, Alberto. Institute for Human and Machine Cognition.Qu son las
Proposiciones? ... desde la Perspectiva de los Mapas Conceptuales.
http://cmap.ihmc.us/docs/Proposicion.html (Consulta: 04 de Agosto. 2011)
IRIARTE NAVARRO, Leonel. Revista de Educacin a Distancia RED. Mapas
conceptuales y objetos de aprendizaje.
http://www.um.es/ead/red/M2/leonel21.pdf (Consulta: 04 de Agosto. 2011)
CHECKLAND, Peter. Pensamiento de sistemas, prctica de sistemas.
http://es.scribd.com/doc/43942469/Check-Land (Consulta: 12 de Julio. 2011)
DE LA ROSA, Martn Ramiro. Anlisis de impacto basado en informacin de
trazabilidad y decisiones de diseo
http://materias.fi.uba.ar/7500/delarosa-tesisdegradoingenieriainformatica.pdf
(Consulta: 22 de Junio. 2011)
DEL VALLE, Juan Antonio. Introduccin a la Metodologa de los Sistemas Suaves
http://www.ingenieria.unam.mx/javica1/biblioteca/SistemasSuaves/introduccion_ss
m.html (Consulta: 5 de Febrero. 2011)
DAZ PARRA, Ocotln. Tcnias de Modelacin de Sistemas Blandos Aplicadas al
Problema del Transporte Escolar.
http://campusv.uaem.mx/cicos/memorias/5tocic2006/Articulos/articulo3.pdf
(Consulta: 3 de Febrero. 2011)
DURAN, Amador. Tesis doctoral: Un Entorno Metodolgico de Ingeniera de
Requisitos para Sistemas de Informacin.
http://fondosdigitales.us.es/tesis/tesis/30/un-entorno-metodologico-de-ingenieriade-requisitos-para-sistemas-de-informacion/ (Consulta: 2 de Diciembre. 2010)
229
DURN, Ismary Alfonso y GARCA RODRGUEZ, Andrs.

Revista de
Arquitectura e Ingeniera, vol. 2, nm. 3, diciembre, 2008. Gestin por el
Conocimiento. Metodologa para la implementacin de Mapas Conceptuales.
http://redalyc.uaemex.mx/redalyc/pdf/1939/193915935006.pdf (Consulta: 03 de
Agosto. 2011)
FINKELSTEIN, Antony. "Tracing Back from Requirements", IEEE Colloquium,
Computing and Control Division, Professional Group C1, 1991, pp. 7/1-7/2.
http://eprints.ucl.ac.uk/857/ (Consulta: 22 de Junio. 2011)
FLAVELL, J. H., MILLER, P. H., & MILLER, S. A. (2002). Cognitive development
(4th ed.). Upper Saddle River, NJ: Prentice Hall.
Gatherspace requirements on demand. The value of a requirements management
plan
http://www.gatherspace.com/static/requirements_management_tool.html#6
GIBSON, J. J. (1979). The Ecological Approach to Visual Perception. Boston:
Houghton Mifflin Company.
http://books.google.com/books?id=BJGCuje64FcC&printsec=frontcover&hl=es#v=
onepage&q&f=false (Consulta: 03 de Agosto. 2011)
GODOY, Danny Alexander. Generacin automtica de documentos de requisitos
en proyectos de software
http://captura.uchile.cl/jspui/handle/2250/11311 (Consulta: 3 de Diciembre. 2010)
GOTEL, Orlena & FINKELSTEIN, Antony. An Analysis of the Requirements
Traceability Problem.
International Conference on Requirements Engineering, ICRE94, Los Alamitos,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.2090&rep=rep1&type
=pdf (Consulta: 01 de Agosto. 2011)
GRANT Zemont. Towards Value-Based Requirements Traceability
http://facweb.cs.depaul.edu/research/techreports/TR05-011.pdf (Consulta: 01 de
Agosto. 2011)
230
GRUPO DE INGENIERIA DEL SOFTWARE, Universidad de Sevilla.

http://www.lsi.us.es/docencia/get.php?id=2006 (Consulta: 10 de Diciembre. 2010)
HEIIM, Philipp. Graph-based Visualization of Requirements Relationships.
http://www.vis.unistuttgart.de/~heimpp/assets/files/Publikationen/id/19280.pdf
(Consulta: 26 de Noviembre. 2010)
HSIEH, Haowei y SHIPMAN Frank. Supporting Visual Problem Solving in Spatial
Hypertext
http://journals.tdl.org/jodi/article/viewArticle/173 (Consulta: 30 de Noviembre. 2010)
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications, IEEE, 1998.
INSTITUTE FOR ELECTRONICS AND ELECTRICAL ENGINEERS. Glosario
estndar de la terminologa de la ingeniera de software estndar 610.12-1990.
s.I.: La institucin, 1997.
INTECO, Instituto Nacional de Tecnologas de la Comunicacin. Gua prctica de
gestin de requisitos
http://es.scribd.com/doc/38820789/Guia-Practica-de-Gestion-de-Requisitos
(Consulta: 2 de Marzo. 2011)
INTECO, Instituto Nacional de Tecnologas de la Comunicacin. Gua avanzada
de gestin de requisitos.
http://www.inteco.es/file/teW3c753nhQkEhLjAz6BbA (Consulta: 2 de Marzo. 2011)
IRIARTE NAVARRO, Leonel. Revista de Educacin a Distancia RED. Mapas
conceptuales y objetos de aprendizaje obj1 WHI_CMP .
http://www.um.es/ead/red/M2/leonel21.pdf (Consulta: 03 de Agosto. 2011)
LUDWIG CONSULTING SERVICES. Introduction to Requirements Planning
http://www.jiludwig.com/Requirements_Management.html
231
MARTINEZ AVELLA, Mario Ernesto. Ideas para el cambio y el aprendizaje en la

organizacin
http://books.google.com/books?id=VU2wxjDcNBUC&pg=PA47&dq=metodologia+d
e+sistemas+blandos&hl=es&ei=YlwvTd3XNs_qgQeembRa&sa=X&oi=book_result
&ct=result&resnum=1&ved=0CCcQ6AEwAA#v=onepage&q&f=false (Consulta: 24
de Enero. 2011)
MIA
Hokkanen.
REQUIREMENTS
TRACEABILITY.
LAPPEENRANTA
UNIVERSITY OF TECHNOLOGY
http://www.doria.fi/bitstream/handle/10024/35358/nbnfife20011576.pdf?sequence=
1 (Consulta: 01 de Agosto. 2011)
MIZUNO, Y. Software Quality Improvement
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1654331 (Consulta: 2 de
Diciembre. 2010)
Norman, D. A. (1993). Things that Make Us Smart. NY: Addison Wesley.
http://www.amazon.com/Things-That-Make-Smart-Attributes/dp/0201626950
(Consulta: 12 de Julio. 2011)
Novak, J. D., & Gowin, D. B. (1984). Learning How to Learn. New York, NY:
Cambridge University Press.
http://books.google.com.co/books?hl=es&lr=&id=8jkBcSDQPXcC&oi=fnd&pg=PR9
&dq=Learning+How+to+Learn&ots=nymVvztO35&sig=HdMTYzG_KrZg1UUo3coR
1b6acm4#v=onepage&q&f=false (Consulta: 12 de Julio. 2011)
Novak, J.D. (2005). Results and implications of a 12-year longitudinal study of
science concept learning. Research In Science Education.
NUSEIBEH, Bashar y EASTERBROOK, Steve. Requirements Engineering: A
Roadmap. http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf (Consulta:
24 de Enero. 2011)
Red de Revistas Cientficas de Amrica Latina y el Caribe, Espaa y
Portugal.http://redalyc.uaemex.mx/pdf/496/49614310.pdf
(Consulta:
3
de
Diciembre. 2010)
232
OLIVERA, Jos. Fundamentos y Esquema de la MSB. FIS - UNCP

http://issuu.com/jloliverafis/docs/fundamentos_de_la_msb (Consulta: 13 de Julio.
2011)
PEA GARCA, Mara. Impacto de la aplicacin del modelo cmmi nivel 2 en el
ciclo de vida de un proyecto.
http://oa.upm.es/1645/ (Consulta: 12 de Diciembre. 2010)
Rational Unified Process.
Febrero. 2011)
(Consulta:
24
de
ROWLAND YOUNG, Ralph. The requirements engineering handbook Escrito por

http://bib.tiera.ru/dvd51/Young%20R.%20R.%20%20The%20Requirements%20En
gineering%20Handbook(2003)(278).pdf (Consulta: 12 de Diciembre. 2010)
REAL ACEDEMIA ESPAOLA. Diccionario de la lengua espaola 22 y avance
de la 23 edicin. http://www.rae.es/rae.html. (Consulta: 2010-2012)
RUP, Rational Unified Process. Rational software corporation requirements
management plan
http://rup.hops-fp6.org/process/artifact/ar_ratgl.htm (Consulta: 24 de Febrero.
2011)
SistemiGramas, Para qu sirve la Metodologa de Sistemas Suaves?
http://sistemigramas.wordpress.com/category/metodologia-sistemas-suaves/
(Consulta: 12 de Diciembre. 2010)
SOCHACKYJ AMARO, Euhen Alexander. Sistema para dar soporte en la
generacin del contenido de un curso aplicando recursos multimedia, caso de
estudio curso introductorio.
http://biblo.una.edu.ve/docu.7/bases/marc/texto/t4147.pdf
(Consulta: 10 de
Diciembre. 2010)
SOMMERVILLE, Ian. Ingeniera de software sptima edicin., Addison-Wesley,
2005.
233
SOTO, Lauro. MiTecnologico.com. Especificaciones de requerimientos

http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos (Consulta:
12 de Diciembre. 2010)
SWEBOK, Software Engineering Body of Knowledge 2004
TABARES, Marta Silvia. Revista EIA, ISSN 1794-1237 Nmero 4 p. 95-102.
Noviembre 2005. Escuela de Ingeniera de Antioquia, Medelln (Colombia). anlisis
de la trazabilidad desde la perspectiva de la orientacin a aspectos
http://revista.eia.edu.co/articulos4/art%208%20N4.pdf (Consulta: 02 de Agosto.
2011)
Tractors, Training material in creativity and innovation for European R&D
Organisations & SMEs.
http://www.train4creativity.eu/dat/B733AF62/file.pdf?634309658922023766
WIEGERS, Karl. When telepathy wont do: Requirements engineering key
practices.http://www.processimpact.com/articles/telepathy.pdf (Consulta: 27 de
Noviembre. 2010)
234
15 ANEXOS
ANEXO 1: PLANTILLA DEL DOCUMENTO PLAN DE ADMINISTRACIN DE
REQUISITOS
NOMBRE DEL PROYECTO

Plantilla de un RMP basada en RUP
NOMBRE DEL DOCUMENTO
Plan de Administracin de Requisitos
Versin #
junio 18, 2012
235
INFORMACIN DEL DOCUMENTO

HISTRICO DE REVISIONES
Versin
Fecha
Responsable(s)
Nombre del archivo
HISTRICO DE CAMBIOS
Versin
Fecha
Cambios
236
TABLA DE CONTENIDO
1. Introduccin
1.1 Propsito
1.2 Alcance
1.3 Aplicabilidad
1.4 Organizacin del documento
1.5 Documentos aplicables
1.6 Cuestiones
2. El programa para la administracin de requisitos
2.1 Roles y responsabilidades
2.1.1 Resumen de la organizacin
2.1.2 Descripcin de los roles
2.2 Atributos
2.3 Organizacin de los requisitos
2.2.1 Tipo re requisitos
2.3.1 Convencin numrica
2.3.2 Estructura del repositorio
2.4 Trazabilidad
2.5 Control de cambio en los requisitos
2.5.1
Procesamiento y aprobacin de las solicitudes de cambio
2.6 Flujo de trabajo y actividades
3. Documentacin de requisitos
3.1 Estructuras de distribucin
3.2 Informacin asociada
4. Mtricas
5. Reportes
6. Formacin y recursos
6.1 Herramientas
6.2 Recursos
6.3 Capacitacin
7. Apndices
237
1. INTRODUCCIN
1.1 PROPOSITO
Definir el objetivo del documento.
1.2
ALCANCE
El alcance del plan incluye:
Qu se debe hacer?
Cmo se har?
Quin llevar a cabo diversas actividades?
Cundo se debe realizar?
Qu nivel de requisitos de calidad se debe lograr?
1.3 APLICABILIDAD
Describa quin y qu se ve afectado por el plan.
1.4 ORGANIZACIN DEL DOCUMENTO
Resumen del contenido del documento.
1.5 DOCUMENTOS APLICABLES
Identificar los documentos de control DE procesos contenidos en el RMP.
1.6 CUESTIONES
Describir los problemas que puedan afectar la aplicacin del plan de gestin de
requisitos (formacin, seleccin de la herramienta, la distribucin geogrfica del
equipo, etc.)
238
2. EL PROGRAMA PARA LA ADMINISTRACIN DE REQUISITOS

2.1 ROLES Y RESPONSABILIDADES
2.1.1 RESUMEN DE LA ORGANIZACIN
Proporcionar una visin general de la organizacin desde una perspectiva de los
roles que se necesiten para llevar a cabo el proyecto. El uso de grficos y / o una
tabla que muestra la organizacin del proyecto para una fcil referencia. La
informacin de contacto tambin pueden ser incluidos.
Role
Nombre
2.1.2 DESCRIPCIN DE LOS ROLES

Proporcionar las responsabilidades y deberes de cada persona o grupo durante el
proyecto.
2.2 ATRIBUTOS
Tabla 73. Descripcin del atributo: Prioridad
SECCION PRINCIPAL
Nombre del atributo
Prioridad
Propsito
La importancia dada a un requerimiento
Tipo de requisitos a
los que aplica
DESCRIPCIN DE LOS VALORES
Valor
Descripcin del valor
Crtica
La funcin debe estar presente en la aplicacin.
Alta
Requisitos esenciales. La falta de estas en la

aplicacin significa que el sistema no va a
satisfacer las necesidades de los clientes
Media
Requisitos importantes para la eficacia y

eficiencia del sistema para la mayora de
las aplicaciones. La funcionalidad no se
puede proporcionar fcilmente de alguna
239
otra manera. La falta de inclusin de un

requisito importante puede afectar a los
clientes o la satisfaccin del usuario, o
incluso los beneficios.
Baja
Sin Opinin
Los requisitos que son tiles en

aplicaciones menos tpicas se utilizan
con menos frecuencia, o para que
soluciones razonablemente eficiente se
puede lograr. No hay beneficios
importantes o impacto de satisfaccin del
cliente se puede esperar si tal producto
no est incluido.
Si la funcin no est incluida no habr ningn

efecto.
Fuente: Rational Software Corporation

Tabla 74. Descripcin del atributo: Origen
SECCION PRINCIPAL
Nombre del atributo
Origen
Propsito
Identifica el sector que identificaba el requisito.
los que aplica
Valor
Desconocido (D), Comit Ejecutivo,

Gestin de Producto, Clientes, Socios,
Soporte tcnico, Ventas, Marketing,
Desarrollo, Redactores tcnicos,
Prueba
N/A

Tabla 75. Descripcin del atributo: Estado
SECCION PRINCIPAL
Nombre del atributo
Estado.
240
Propsito
El estado dado a un tipo determinado de requisito.

Establecido despus de la negociacin y la
revisin por el equipo de gestin de proyectos \
equipo de gestin de productos, y otras partes
interesadas.
los que aplica
Valor
Validado
Requisito
que ha sido revisado por el equipo de
aprobacin de CCB consejo de administracin como
requisito "vlido". Permanecer en este estado hasta que
el requerimiento es aprobado e incluido en un proyecto de
producto.
Aprobado
Requisito ha sido aprobado para su inclusin en el

proyecto del producto.
Asignado
Requisito ha sido asignado al director de producto,

desarrollo, pruebas, o las partes interesadas original.
Invalidado
Requisito no se ajusta a la definicin del producto.

Tabla 76. Descripcin del atributo: Dificultad
SECCION PRINCIPAL
Nombre del atributo
Dificultad
Propsito
los que aplica
El esfuerzo que se requiere incorporar a un

requisito determinado del producto (si este
esfuerzo incluyen la arquitectura, el diseo,
cdigo, o de prueba).

Valor
Alta
Encima del promedio para implementar.
Media
Esfuerzo medio para implementar.

241
Baja
Por debajo del promedio para implementar.

Tabla 77. Descripcin del atributo: Estabilidad
SECCION PRINCIPAL
Nombre del atributo
Estabilidad
Propsito
La probabilidad de que un requerimiento

especfico va a cambiar o tener un efecto en los
dems requisitos. Se utiliza para ayudar a
establecer las prioridades de desarrollo y
determinar los elementos para que la exploracin
y el descubrimiento adicional sea apropiada.
los que aplica
Valor
Alta
Es muy poco probable que este requisito va a cambiar, o

que la comprensin del equipo de desarrollo lo hagan
cambiar.
Media
No existe indicador para predecir la probabilidad de

cambio del requisito.
Baja
Es muy probable que este requisito va a cambiar, o que la

comprensin del equipo de desarrollo lo hagan cambiar.

Tabla 78. Descripcin del atributo: Costo
SECCION PRINCIPAL
Nombre del atributo
Costo
Propsito
El costo se medir con la estimacin del costo

monetario de la implementacin de las reglas de
negocio.
los que aplica
Valor

242
Nmero real
Proporcionar el valor numrico del costo para implementar

el requisito.

Tabla 79. Descripcin del atributo: Tiempo estimado de desarrollo
SECCION PRINCIPAL
Nombre del atributo
Tiempo estimado de desarrollo.
Propsito
Esfuerzo estimado en horas para disear y

desarrollar un requisito. Valor: valor numrico en
horas.
los que aplica
Valor
Nmero real

Proporcionar el valor numrico de las horas estimadas
que se necesita para implementar el requisito.

Tabla 80. Descripcin del atributo: Asignado a
SECCION PRINCIPAL
Nombre del atributo
Asignado a.
Propsito
Miembro del equipo a quien se asigna el requisito.
los que aplica
Valor
Persona/Grupo

Nombre del equipo y el miembro a quien es asignado el
requisito. Estos valores de la lista tendr que ser
configurado por el equipo de administracin del proyecto.
2.3 ORGANIZACIN DE LOS REQUISITOS

2.3.1 TIPO DE REQUISITOS
243
Tabla 81. Descripcin del tipo de requisito: Regla de negocio

SECCION PRINCIPAL
Nombre
Regla de negocio (BR).
Descripcin
Este tipo de requisito se utiliza para identificar una

declaracin de poltica o una condicin que debe
ser satisfecha.
Prioridad, estado de origen, dificultad, costo, horas
estimadas de desarrollo, estabilidad, asignado a,
notificacin de revisin, obsoleto.
Posibles atributos

Tabla 82. Descripcin del tipo de requisito: Solicitud de cambio
SECCION PRINCIPAL
Nombre
Solicitud de cambio (CR)
Descripcin
Una solicitud de cambio es una solicitud para

corregir/cambiar o solicitar nuevas caractersticas.
Cualquier funcin puede presentar una solicitud
de cambio como parte de cualquier actividad en
todo el ciclo de vida del proyecto.
Prioridad, Estado, Dificultad, Estabilidad, Horas
estimadas de desarrollo, Asignado a, Requisito
CR, Notificacin de revisiones, Obsoleto.
Posibles atributos

Tabla 83. Descripcin del tipo de requisito: Necesidad
SECCION PRINCIPAL
Nombre
Necesidad (STRQ)
Descripcin
(Solicitudes de los interesados) son las

necesidades de alto nivel de un cliente.
Estado, prioridad, costo, dificultad, estabilidad,
asignado a, iteracin o versin actual, rigen,
fundamento, horas estimadas de desarrollo,
obsoleto, notificacin de revisiones.
Posibles atributos

Tabla 84. Descripcin del requisito: Caso de uso
SECCION PRINCIPAL
244
Nombre
Caso de Uso (UC)
Descripcin
La respuesta del sistema a un evento externo que

se documenta en un caso de uso.
Iteracin o versin actual, prioridad, estado,
costo, dificultad, estabilidad, asignado a, riesgo,
afecta a la arquitectura, notificacin de la revisin,
actores, curso normal, curso alterno, referencias,
precondiciones.
Posibles atributos

Tabla 85. Descripcin del tipo de requisito: Caso de prueba
SECCION PRINCIPAL
Nombre
Caso de prueba (TC)
Descripcin
Un caso de prueba es un conjunto de entradas de

prueba, las condiciones de ejecucin y los
resultados esperados desarrollados para el
objetivo particular o para verificar el cumplimiento
de un requisito especfico.
Posibles atributos
Resultados esperados, salida, notas de prueba,

prioridad, dificultad, riesgo, estabilidad, estado,
asignado a, planificacin de iteracin o versin,
iteracin o versin actual, obsoleto, notificacin de
revisiones

Tabla 86. Descripcin del tipo de requisito: Riesgo
SECCION PRINCIPAL
Nombre
Riesgo (RISK)
Descripcin
Almacena la lista de riesgo del proyecto. Se utiliza

para fines de gestin de proyectos para abordar la
mitigacin de riesgos. Estos requisitos pueden ser
trazados a otros requisitos que son identificados
como un riesgo.
Planificacin de iteracin o la versin, estado,
rango del riesgo, probabilidad, impacto, afecta,
asignado a, notas, costo semana, dueo del
equipo, Impacto del equipo, Obsoleto ,
Notificacin de revisiones.
Posibles atributos
245

Descripcin del tipo de requisito: Estrategia de mitigacin
SECCION PRINCIPAL
Nombre
Estrategia de mitigacin (MITSTRAT)
Descripcin
Almacena los requisitos que se identifican como

una estrategia para mitigar el riesgo. Estos
requisitos se trazaran a los riesgos.
Iteracin planificada o versin, iteracin o versin
actual, estado, asignado a, costos, propietario del
equipo, notas, condicin de disparo, porcentaje de
reduccin de destino, tipo, obsoleto, notificacin
de revisiones.
Posibles atributos

Tabla 87. Descripcin del tipo de requisito: Requisito funcional
SECCION PRINCIPAL
Nombre
Requisito funcional (RF)
Descripcin
Almacena los requisitos que

funcionalidades del sistema
Posibles atributos
Origen, dificultad, horas estimadas, entradas,

precondiciones, salidas, prioridad.
describen
las

2.3.2 CONVENCIN NUMRICA
Describir cmo va ser la composicin mnemotcnica para enumerar los requisitos,
2.3.3 ESTRUCTURA DEL REPOSITORIO
Describir cmo van a estar almacenados los requisitos en la herramienta para la
administracin de requisitos y/o del sitio en el que estos almacenen y como se
relacionan. Se describe tambin, como se relacionarn los datos generados y/o
utilizados por otras herramientas.
2.4 TRAZABILIDAD
Describir la estrategia de trazabilidad aclarando que se va trazar y porque.
246
Tabla 88. Formato de estrategia para la trazabilidad

SECCION PRINCIPAL
Artefacto a trazar
Atributo Tipo de Requisito
Nombre
Motivo por el que se
traza
Valor

2.5
CONTROL DE CAMBIO EN LOS REQUISITOS /VERSIONES
Tiene como propsito definir el procedimiento por el cual se efectan cambios en
los requerimientos.
2.6 FLUJO DE TRABAJO Y ACTIVIDADES
Sintetizar en un diagrama o tabla las actividades que conforman los procesos de
administracin de requisitos, identificando a los principales roles intervinientes.
3. DOCUMENTACIN DE LOS REQUISITOS
3.1 DOCUMENTACIN DE REQUISITOS
En esta seccin se encuentra la documentacin de requisitos generada por el
proyecto.
3.1.1 ESTRUCTURAS DE DISTRIBUCIN
Proporcionar los diagramas que muestren los requisitos clasificados
Proporcionar el estndar de cmo los requisitos se organizarn y se
descompondrn.
3.1.2 INFORMACIN ASOCIADA
Describa la informacin que se asociar a cada requisito y quien se encargar de
recopilar la informacin.
4. MTRICAS
247
Describir las medidas que se utilizarn para la gestin de los requisitos.

5. REPORTES
Describir los informes que sern generados y su propsito.
6. FORMACIN Y RECURSOS
Describir las herramientas de software, personal y capacitacin necesarios para
ejecutar las actividades de administracin los requisitos especificados.
7. ANEXOS
Se coloca la informacin de soporte relacionada al plan de administracin de
requisitos o de cualquier tema que se trate en alguna de sus secciones.
248

Análisis y Diseño de Una Herramienta Gráfica para Los

Cargado por

Copyright:

Formatos disponibles

Análisis y Diseño de Una Herramienta Gráfica para Los

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Análisis y Diseño de Una Herramienta Gráfica para Los

Cargado por

Copyright:

Formatos disponibles

ANLISIS Y DISEO DE UNA HERRAMIENTA GRFICA PARA LOS

PROCESOS DE LA INGENIERA DE REQUISITOS

DANIEL LEMA BECERRA

UNIVERSIDAD TECNOLGICA DE PEREIRA

ANLISIS Y DISEO DE UNA HERRAMIENTA GRFICA PARA LOS

DANIEL LEMA BECERRA

Trabajo de grado para optar por el ttulo de Ingeniera de Sistemas y Computacin

UNIVERSIDAD TECNOLGICA DE PEREIRA

Pereira, 23 de Mayo de 2012

Queremos dar nuestros agradecimientos por el apoyo, la colaboracin, la muy

CAPTULO 1. INTRODUCTORIO ...................................................... 26

FORMULACIN DEL PROBLEMA ......................................... 28

PROBLEMAS DE ARTICULACIN ............................................................................ 29

PROBLEMAS DE LIMITACIONES COGNITIVAS DEL SER HUMANO .......................... 29

PROBLEMA DE LA INFORMACIN ESTRUCTURADA .............................................. 29

OBJETIVO GENERAL ............................................................................................... 33

OBJETIVOS ESPECFICOS ........................................................................................ 33

CAPTULO 2. MARCO TERICO ...................................................... 34

EL PROCESO DE LA INGENIERA DE REQUISITOS ........... 35

CLASIFICACIN DE LOS REQUISITOS ...................................................................... 36

Requisitos funcionales ................................................................................... 36

Requisitos no funcionales .............................................................................. 36

Requisitos del dominio. .................................................................................. 37

CARACTERSTICAS DE LOS REQUISITOS ................................................................. 38

DESARROLLO DE REQUISITOS ................................................................................ 38

Documentacin o especificacin ................................................................... 40

ADMINISTRACIN DE REQUISITOS ........................................................................ 41

Priorizacin de requisitos ............................................................................... 41

Trazabilidad de requisitos .............................................................................. 42

PLAN DE ADMINISTRACIN DE REQUISITOS ......................................................... 49

ROLES EN LOS PROCESOS DE LA INGENIERA DE REQUISITOS .............................. 50

Profesional de pruebas .................................................................................. 62

FILOSOFIA DE LA SSM ............................................................................................ 74

PROCESO DE LA METODOLOGA ........................................................................... 75

Estadio 1: investigar la situacin problema no estructurado ......................... 76

Estadio 2: expresar la situacin del problema ............................................... 76

Estadio 3: seleccionar una visin de la situacin y producir una definicin raz

Estadio 4: confeccin y verificacin de modelos conceptuales ..................... 78

Estadio 4a: verificacin del modelo conceptual con un modelo de sistema

Estadio 5: comparacin de los modelos conceptuales con la realidad .......... 80

Estadio 6: diseo de cambios deseables, viables y factibles .......................... 81

Estadio 7: acciones para mejorar la situacin del problema .......................... 82

MAPAS CONCEPTUALES ...................................................... 83

ORIGEN DE LOS MAPAS CONCEPTUALES .............................................................. 83

ELEMENTOS DE LOS MAPAS CONCEPTUALES ....................................................... 85

Palabras de enlace ......................................................................................... 86

CARACTERSTICA DE LOS MAPAS CONCEPTUALES ................................................ 88

Estructura Proposicional ................................................................................ 89

Estructura Jerrquica ..................................................................................... 90

Pregunta de Enfoque ..................................................................................... 90

Enlaces Cruzados ............................................................................................ 90

ELABORACIN DE UN MAPA CONCEPTUAL .......................................................... 90

DISEO METODOLGICO ..................................................... 93

DEFINICIN DE LA HIPTESIS ................................................................................ 93

TIPO DE ESTUDIO ................................................................................................... 93

TCNICAS DE INVESTIGACIN ............................................................................... 93

CAPTULO 3. DESARROLLO DE LOS OBJETIVOS ....................... 95

REQUISITOS FUNCIONALES ................................................................................... 96

DOCUMENTACIN REFERENTE AL ANLISIS ....................................................... 102