Tvirtual Galeria

ESCUELA SUPERIOR DE INGENIERA
INGENIERA TCNICA EN INFORMTICA DE GESTIN
TIENDA VIRTUAL PARA UNA GALERA DE ARTE
DEPARTAMENTO: Lenguajes y Sistemas Informticos
DIRECTOR DEL PROYECTO: Juan Manuel Dodero Beardo
AUTORA DEL PROYECTO: Silvia Mara Garbarino de la Rosa
San Fernando, Abril 2013
Fdo: Silvia Mara Garbarino de la Rosa

ii
iii
Despus de tanto tiempo

quiero dar las gracias:
A mis padres y tas

por estar ah siempre
que les he necesitado.
A mi marido
por su comprensin,
por su paciencia y
por estar siempre conmigo.
A mi hijo
por su alegra que cada
da comparte conmigo.
A mi tutor
por darme la oportunidad
de terminar.
Gracias a todos de corazn.

iv
v
Este documento ha sido liberado bajo Licencia GFDL 1.3 (GNU Free Documentation
License). Se incluyen los trminos de la licencia en ingls al final del mismo.
Copyright(C) 2013 Silvia Mara Garbarino de la Rosa
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.3 or any later version published by
the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no
Back-Cover Texts.
vi
ndice general
I Prolegmeno 1
1. Introduccin 5
1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Propsito, objetivos y alcance del proyecto . . . . . . . . . . . . . . . . . . 5
1.3. Producto final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Organizacin del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1. Organizacin de la memoria . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2. Organizacin del software . . . . . . . . . . . . . . . . . . . . . . . 12
2. Planificacin 13
2.1. Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Planificacin del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Objetivo inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Divisin del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Estimacin de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4. Identificacin de Sprints . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5. Planificacin temporal . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6. Anlisis de la desviacin temporal . . . . . . . . . . . . . . . . . . . 23
2.4. Organizacin del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1. Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vii
viii NDICE GENERAL
2.4.1.1. Estructura interna . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1.2. Roles y responsabilidades . . . . . . . . . . . . . . . . . . 24
2.4.2. Equipo informtico . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5. Costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6. Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.1. Evaluacin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.1.1. Identificacin de riesgos . . . . . . . . . . . . . . . . . . . 29
2.6.1.2. Anlisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 31
2.6.1.3. Priorizacin de riesgos . . . . . . . . . . . . . . . . . . . . 35
2.6.2. Control de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.2.1. Reduccin de riesgos . . . . . . . . . . . . . . . . . . . . . 36
2.6.2.2. Resolucin de riesgos . . . . . . . . . . . . . . . . . . . . . 37
II Desarrollo 39
3. Anlisis de requisitos 43
3.1. Catlogo de actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2. Modelado de casos de uso . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . 51
3.2.2.2. Descripcin de casos de uso . . . . . . . . . . . . . . . . . 57
3.3. Requisitos de Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.1. Requisitos de interfaz externa . . . . . . . . . . . . . . . . . . . . . 82

NDICE GENERAL ix
3.4.1.1. Interfaces de usuarios . . . . . . . . . . . . . . . . . . . . 82
3.4.1.2. Interfaces con el hardware . . . . . . . . . . . . . . . . . . 82
3.4.1.3. Interfaces con el software . . . . . . . . . . . . . . . . . . 82
3.4.1.4. Interfaces de comunicaciones . . . . . . . . . . . . . . . . 82
3.4.2. Requisitos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.3. Requisitos de eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.3.1. Requisitos de espacio . . . . . . . . . . . . . . . . . . . . . 83
3.4.3.2. Requisitos de rendimiento . . . . . . . . . . . . . . . . . . 83
3.4.4. Restricciones del diseo . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.5. Restricciones de base de datos . . . . . . . . . . . . . . . . . . . . . 83
3.4.6. Atributos de sistema de software . . . . . . . . . . . . . . . . . . . 83
3.5. Reglas de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.6. Estudio de alternativas tecnolgicas . . . . . . . . . . . . . . . . . . . . . . 84
3.6.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.6.1.1. Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.6.1.2. Ruby como lenguaje para mi proyecto . . . . . . . . . . . 91
3.6.2. Entorno de desarrollo Web . . . . . . . . . . . . . . . . . . . . . . . 92
3.6.2.1. Rails como framework para mi proyecto . . . . . . . . . . 94
3.6.2.2. Otros frameworks . . . . . . . . . . . . . . . . . . . . . . . 95
3.7. Anlisis GAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4. Diseo del Sistema 103
4.1. Diseo de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1.1. Arquitectura fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1.2. Arquitectura lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2. Diseo de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.1. Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2. Diagramas de navegacin . . . . . . . . . . . . . . . . . . . . . . . . 111

x NDICE GENERAL
4.3. Diseo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.3.1. Esquema de la BD . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.4. Diseo de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.4.1. Diagrama de secuencia (DSS) . . . . . . . . . . . . . . . . . . . . . 125
4.4.2. Diagrama de clases de diseo . . . . . . . . . . . . . . . . . . . . . 127
4.5. Parametrizacin del software base . . . . . . . . . . . . . . . . . . . . . . . 127
5. Implementacin del Sistema 129
5.1. Entorno tecnolgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.1.1. Lenguajes de programacin y framework . . . . . . . . . . . . . . . 129
5.1.2. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.1.3. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 130
5.1.4. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.2. Cdigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3. Implementacin del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.3.1. Implementacin del Modelo . . . . . . . . . . . . . . . . . . . . . . 140
5.3.1.1. Definicin de datos . . . . . . . . . . . . . . . . . . . . . . 142
5.3.1.2. Manipulacin de Datos . . . . . . . . . . . . . . . . . . . . 143
5.3.1.3. Configuracin de la base de datos . . . . . . . . . . . . . . 147
5.3.2. Implementacin del Controlador . . . . . . . . . . . . . . . . . . . . 148
5.3.2.1. Desarrollar las acciones del controlador . . . . . . . . . . . 149
5.3.2.2. Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3.3. Implementacin de la Vista . . . . . . . . . . . . . . . . . . . . . . 153
5.3.3.1. Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.3.3.2. Partials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.3.3.3. Hojas de estilo . . . . . . . . . . . . . . . . . . . . . . . . 156
5.3.4. Sesiones y Autenticacin . . . . . . . . . . . . . . . . . . . . . . . . 157
5.3.5. Bsqueda de obras . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

NDICE GENERAL xi
5.3.6. Notificaciones por correo electrnico . . . . . . . . . . . . . . . . . . 160
5.3.7. Pasarela de pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.3.8. Internacionalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6. Pruebas del Sistema 173
6.1. Pruebas en Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.2. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.3. Pruebas de integracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.4. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.4.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.4.2. Pruebas no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.5. Pruebas de aceptacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
III Eplogo 191
7. Manual de usuario 195
7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.2. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.3. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.4. Utilizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.4.1. Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.4.1.1. Logarse como administrador y modificar sus datos . . . . 198
7.4.1.2. Panel de administracin . . . . . . . . . . . . . . . . . . . 200
7.4.1.3. Listados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.4.1.4. Bsqueda de obras de arte . . . . . . . . . . . . . . . . . . 206
7.4.1.5. Gestores de clientes: Pedidos . . . . . . . . . . . . . . . . 206
7.4.2. Usuario de la tienda . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.4.2.1. Registrarse en la tienda virtual . . . . . . . . . . . . . . . 208

xii NDICE GENERAL
7.4.2.2. Modificacin de los datos de usuario . . . . . . . . . . . . 210
7.4.2.3. Catlogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.4.2.4. Obras recientes de la galera . . . . . . . . . . . . . . . . . 210
7.4.2.5. Bsqueda de obras de arte . . . . . . . . . . . . . . . . . . 212
7.4.2.6. Consulta y seleccin de obras de arte . . . . . . . . . . . . 212
7.4.2.7. Cesta/carrito de la compra . . . . . . . . . . . . . . . . . 215
7.4.2.8. Realizar el pedido . . . . . . . . . . . . . . . . . . . . . . 216
7.4.2.9. Quienes somos . . . . . . . . . . . . . . . . . . . . . . . . 219
7.4.2.10. Condiciones generales . . . . . . . . . . . . . . . . . . . . 219
7.4.2.11. Contactar . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.4.2.12. Cambiar de idioma . . . . . . . . . . . . . . . . . . . . . . 221
8. Manual de instalacin y explotacin 223
8.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
8.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
8.3. Inventario de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
8.4. Procedimientos de instalacin . . . . . . . . . . . . . . . . . . . . . . . . . 224
8.5. Procedimientos de operacin y nivel de servicio . . . . . . . . . . . . . . . 226
8.6. Pruebas de implantacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9. Conclusiones 231
9.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
9.2. Lecciones aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.2.1. Buenas prcticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.2.2. Mtricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
9.2.2.1. Mtricas del producto . . . . . . . . . . . . . . . . . . . . 233
9.2.2.2. Mtrica del proceso . . . . . . . . . . . . . . . . . . . . . . 235
9.2.2.3. Amortizacin del desarrollo de la aplicacin . . . . . . . . 239

NDICE GENERAL xiii
9.2.2.4. Estudio de la usabilidad de la aplicacin . . . . . . . . . . 241
9.2.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . 243
9.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
10.Anexos 245
A. Acrnimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
B. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
C. Gemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
D. Lenguaje Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
E. Metodologa gil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
F. Pruebas en Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
G. Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
H. Relacin de Casos de Uso y Mockups . . . . . . . . . . . . . . . . . . . . . 273
I. Test de Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.Glosario de trminos 277
Bibliografa 281
GNU Free Documentation License 289

xiv NDICE GENERAL
Listado de Tablas
2.1. Estimacin de tiempos del proyecto . . . . . . . . . . . . . . . . . . . . . . 17
2.2. Estudio del tiempo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3. Estudio de la desviacin temporal del proyecto . . . . . . . . . . . . . . . . 24
2.4. Costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5. Anlisis de riesgos en la planificacin . . . . . . . . . . . . . . . . . . . . . 32
2.6. Anlisis de riesgos en la organizacin . . . . . . . . . . . . . . . . . . . . . 32
2.7. Anlisis de riesgos en la infraestructura . . . . . . . . . . . . . . . . . . . . 32
2.8. Anlisis de riesgos en los requisitos . . . . . . . . . . . . . . . . . . . . . . 33
2.9. Anlisis de riesgos en el proceso . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10. Anlisis de riesgos en los clientes . . . . . . . . . . . . . . . . . . . . . . . 33
2.11. Anlisis de riesgos en el personal . . . . . . . . . . . . . . . . . . . . . . . 34
2.12. Anlisis de riesgos en el producto . . . . . . . . . . . . . . . . . . . . . . . 34
2.13. Anlisis de riesgos en diseo e implementacin . . . . . . . . . . . . . . . . 34
2.14. Estimacin de riesgos priorizados . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Entidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2. Relaciones del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3. Comparativa de entornos de desarrollo Web - Ruby . . . . . . . . . . . . . 94
3.4. Caractersticas de Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . 102
5.1. URLs habilitadas del enrutamiento de obras . . . . . . . . . . . . . . . . 152
xv
xvi LISTADO DE TABLAS
6.1. Velocidad de carga dentro de http://gadeirart.heroku.com/ . . . . . . . . 184
9.1. Estudio del tiempo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 239
9.2. Costes del proyecto para la aplicacin del Artista . . . . . . . . . . . . . . 241
9.3. Comparativa de costes de ambas aplicaciones . . . . . . . . . . . . . . . . . 241

ndice de figuras
1.1. OBJ-0001 Gestin de artistas . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. OBJ-0002 Gestin de colecciones . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. OBJ-0003 Gestin de obras . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. OBJ-0004 Gestin de secciones . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. OBJ-0005 Gestin de tcnicas . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. OBJ-0006 Gestin del catlogo . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. OBJ-0007 Gestin de la cesta de la compra . . . . . . . . . . . . . . . . . . 8
1.8. OBJ-0008 Gestin de etiquetas . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9. OBJ-0009 Gestin de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 8
1.10. OBJ-0010 Gestin de facturacin . . . . . . . . . . . . . . . . . . . . . . . 8
1.11. OBJ-0011 Gestin de internacionalizacin . . . . . . . . . . . . . . . . . . 9
1.12. OBJ-0012 Gestin de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.13. OBJ-0013 Gestin de quienes somos . . . . . . . . . . . . . . . . . . . . . . 9
1.14. OBJ-0014 Gestin de condiciones . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diagrama del proceso Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Estructura de desglose del trabajo . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Relacin actividades Diagrama de Gantt . . . . . . . . . . . . . . . . . . . 19
2.4. Relacin actividades Diagrama de Gantt - Desarrollo de la aplicacin . . . 20
2.5. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
xvii
xviii NDICE DE FIGURAS
2.7. Organigrama de la Organizacin . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1. Actores del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2. Diagrama del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3. Diagrama de CU de Gestin de Artistas . . . . . . . . . . . . . . . . . . . 52
3.4. Diagrama de CU de Gestin de Colecciones . . . . . . . . . . . . . . . . . 52
3.5. Diagrama de CU de Gestin de Obras . . . . . . . . . . . . . . . . . . . . . 53
3.6. Diagrama de CU de Gestin de Secciones . . . . . . . . . . . . . . . . . . . 53
3.7. Diagrama de CU de Gestin de Tcnicas . . . . . . . . . . . . . . . . . . . 54
3.8. Diagrama de CU de Gestin de Catlogo . . . . . . . . . . . . . . . . . . . 54
3.9. Diagrama de CU de Gestin de Cesta de la Compra . . . . . . . . . . . . . 54
3.10. Diagrama de CU de Gestin de Etiquetas . . . . . . . . . . . . . . . . . . . 55
3.11. Diagrama de CU de Gestin de Seguridad . . . . . . . . . . . . . . . . . . 55
3.12. Diagrama de CU de Gestin de Quienes somos . . . . . . . . . . . . . . . . 55
3.13. Diagrama de CU de Gestin de Facturacin . . . . . . . . . . . . . . . . . 56
3.14. Diagrama de CU de Gestin de Internacionalizacin . . . . . . . . . . . . . 56
3.15. Diagrama de CU de Gestin de Usuarios . . . . . . . . . . . . . . . . . . . 56
3.16. Diagrama de CU de Gestin de Condiciones . . . . . . . . . . . . . . . . . 57
3.17. Descripcin del CU Aadir Artista . . . . . . . . . . . . . . . . . . . . . . 57
3.18. Descripcin del CU Editar Artista . . . . . . . . . . . . . . . . . . . . . . . 58
3.19. Descripcin del CU Eliminar Artista . . . . . . . . . . . . . . . . . . . . . 58
3.20. Descripcin del CU Listar Artistas . . . . . . . . . . . . . . . . . . . . . . 59
3.21. Descripcin del CU Ver Artista . . . . . . . . . . . . . . . . . . . . . . . . 59
3.22. Descripcin del CU Introducir imagen del Artista . . . . . . . . . . . . . . 59
3.23. Descripcin del CU Buscar Obras . . . . . . . . . . . . . . . . . . . . . . . 60
3.24. Descripcin del CU Explorar catlogo de Obras . . . . . . . . . . . . . . . 60
3.25. Descripcin del CU Ficha tcnica de la Obra . . . . . . . . . . . . . . . . . 61
3.26. Descripcin del CU Ficha tcnica del artista . . . . . . . . . . . . . . . . . 61

NDICE DE FIGURAS xix
3.27. Descripcin del CU Obras ms recientes . . . . . . . . . . . . . . . . . . . 61
3.28. Descripcin del CU Aadir a la Cesta . . . . . . . . . . . . . . . . . . . . . 62
3.29. Descripcin del CU Eliminar de la Cesta . . . . . . . . . . . . . . . . . . . 62
3.30. Descripcin del CU Vaciar la Cesta . . . . . . . . . . . . . . . . . . . . . . 63
3.31. Descripcin del CU Asignar Etiquetas . . . . . . . . . . . . . . . . . . . . . 63
3.32. Descripcin del CU Editar Etiquetas . . . . . . . . . . . . . . . . . . . . . 64
3.33. Descripcin del CU Eliminar Etiquetas . . . . . . . . . . . . . . . . . . . . 64
3.34. Descripcin del CU Listar Etiquetas . . . . . . . . . . . . . . . . . . . . . . 65
3.35. Descripcin del CU Mostrar Etiquetas . . . . . . . . . . . . . . . . . . . . 65
3.36. Descripcin del CU Recomendar Obras . . . . . . . . . . . . . . . . . . . . 66
3.37. Descripcin del CU Iniciar Sesin . . . . . . . . . . . . . . . . . . . . . . . 66
3.38. Descripcin del CU Prdida de Clave . . . . . . . . . . . . . . . . . . . . . 67
3.39. Descripcin del CU Mi Cuenta . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.40. Descripcin del CU Cerrar Sesin . . . . . . . . . . . . . . . . . . . . . . . 68
3.41. Descripcin del CU Registrarse . . . . . . . . . . . . . . . . . . . . . . . . 68
3.42. Descripcin del CU Listar Usuarios . . . . . . . . . . . . . . . . . . . . . . 69
3.43. Descripcin del CU Facturar . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.44. Descripcin del CU Ver los Pedidos . . . . . . . . . . . . . . . . . . . . . . 70
3.45. Descripcin del CU Ver informacin de un Pedido . . . . . . . . . . . . . . 70
3.46. Descripcin del CU Cerrar Pedido . . . . . . . . . . . . . . . . . . . . . . . 71
3.47. Descripcin del CU Cambiar la configuracin regional . . . . . . . . . . . . 71
3.48. Descripcin del CU Agregar traduccin . . . . . . . . . . . . . . . . . . . . 72
3.49. Descripcin del CU Editar traduccin . . . . . . . . . . . . . . . . . . . . . 72
3.50. Descripcin del CU Eliminar traduccin . . . . . . . . . . . . . . . . . . . 73
3.51. Requisito de informacin sobre artistas . . . . . . . . . . . . . . . . . . . . 73
3.52. Requisito de informacin sobre colecciones . . . . . . . . . . . . . . . . . . 74
3.53. Requisito de informacin sobre obras . . . . . . . . . . . . . . . . . . . . . 74

xx NDICE DE FIGURAS
3.54. Requisito de informacin sobre secciones . . . . . . . . . . . . . . . . . . . 74
3.55. Requisito de informacin sobre tcnicas . . . . . . . . . . . . . . . . . . . . 75
3.56. Requisito de informacin sobre cesta de la compra . . . . . . . . . . . . . . 75
3.57. Requisito de informacin sobre etiquetas . . . . . . . . . . . . . . . . . . . 75
3.58. Requisito de informacin sobre pedidos . . . . . . . . . . . . . . . . . . . . 76
3.59. Requisito de informacin sobre usuarios . . . . . . . . . . . . . . . . . . . . 76
3.60. Requisito de informacin sobre quienes somos . . . . . . . . . . . . . . . . 77
3.61. Requisito de informacin sobre condiciones . . . . . . . . . . . . . . . . . . 77
3.62. Diagrama Entidad/Relacin . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.63. Diagrama conceptual de clases UML . . . . . . . . . . . . . . . . . . . . . 81
3.64. ndices de aceptacin de lenguajes de programacin - Google Code . . . . . 86
3.65. ndices de aceptacin de lenguajes de programacin - Freshmeat . . . . . . 86
3.66. ndices de aceptacin de lenguajes de programacin - Ohloh . . . . . . . . 87
3.67. ndices de aceptacin de lenguajes de programacin - Delicious . . . . . . . 88
3.68. ndices de aceptacin de lenguajes de programacin - Craigslist . . . . . . 88
3.69. ndices de aceptacin de lenguajes de programacin - Indeed . . . . . . . . 89
3.71. ndices de aceptacin de lenguajes de programacin - Yahoo search . . . . 90
3.72. ndices de aceptacin de lenguajes de programacin - Global . . . . . . . . 91
3.73. Comparativa PHP - Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.74. Tendencia del crecimiento de la demanda de Rails - Indeed.com . . . . . . 95
3.75. ndices de aceptacin de frameworks - Indeed . . . . . . . . . . . . . . . . 100
4.1. Arquitectura MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2. Representacin grfica en Rails del MVC . . . . . . . . . . . . . . . . . . . 106
4.3. Implementacin MVC en Rails . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.4. Cabecera del administrador . . . . . . . . . . . . . . . . . . . . . . . . . . 107

NDICE DE FIGURAS xxi
4.5. Cabecera general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.6. Pie de pgina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.7. Mockup - Link Registro/Acceso clientes . . . . . . . . . . . . . . . . . . . . 108
4.8. Mockup - Acceso clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.9. Mockup - Panel de administracin . . . . . . . . . . . . . . . . . . . . . . . 109
4.10. Mockup - Listado de obras . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.11. Mockup - Visualizacin del pedido . . . . . . . . . . . . . . . . . . . . . . . 110
4.12. Mockup - Catlogo de obras . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.13. Mockup - Identificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.14. Mockup - Ficha de la obra . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.15. Mockup - Cesta de la compra . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.16. Mockup email - Confirmacin del pedido al usuario registrado . . . . . . . 114
4.17. Diagrama de navegacin para el administrador: Men Administracin . . . 115
4.18. Diagrama de navegacin para el administrador: Gestores de contenidos . . 116
4.19. Diagrama de navegacin para el administrador: Gestores generales . . . . . 117
4.20. Diagrama de navegacin para el administrador: Gestores de clientes . . . . 118
4.21. Diagrama de navegacin para los usuarios: Mens . . . . . . . . . . . . . . 119
4.22. Diagrama de navegacin para los usuarios: Catlogo . . . . . . . . . . . . . 120
4.23. Diagrama de navegacin para el cliente: Cesta de la compra . . . . . . . . 121
4.24. Diagrama de navegacin para el visitante: Cesta de la compra . . . . . . . 122
4.25. Esquema ERR de la Base de Datos . . . . . . . . . . . . . . . . . . . . . . 124
4.26. Diagrama de secuencia del patrn MVC . . . . . . . . . . . . . . . . . . . 126
4.27. Diagrama de secuencia del CU-0023: Registrarse . . . . . . . . . . . . . . . 126
4.28. Diagrama clases de diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.1. Ejecucin del script Scaffold para la tabla admin_obras . . . . . . . 141
5.2. Ejemplo de ejecucin de rake migrate . . . . . . . . . . . . . . . . . . . . 143
5.3. Extracto del listado de rutas de la aplicacin . . . . . . . . . . . . . . . . . 153

xxii NDICE DE FIGURAS
5.4. Ejemplo de los partials de las Vistas de Obras . . . . . . . . . . . . . . . . 154
5.5. Ejemplo de email de confirmacin de pedido al cliente . . . . . . . . . . . . 161
5.6. Ejemplo de transacciones recibidas por Authorized.net . . . . . . . . . . . 166
5.7. Correo enviado por Authorized.net con la aprobacin del cobro . . . . . . . 167
6.1. Resultado de la ejecucin de las pruebas unitarias . . . . . . . . . . . . . . 177
6.2. Resultado de la ejecucin de las pruebas de integracin . . . . . . . . . . . 181
6.3. Resultado de la ejecucin de las pruebas funcionales . . . . . . . . . . . . . 183
6.4. Herramienta Pingdom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.5. Velocidad de carga para la url http://gadeirart.heroku.com/catalogo . . . 185
6.6. Velocidad de carga para la url http://gadeirart.heroku.com/catalogo . . . 186
6.7. Anlisis de la url http://gadeirart.heroku.com/catalogo . . . . . . . . . . 187
6.8. Monitorizacin de la aplicacin en modo de desarrollo . . . . . . . . . . . . 187
6.9. Detalles de la URL /es/galeria/artista . . . . . . . . . . . . . . . . . 188
6.10. Detalles de las sentencias SQL en la URL /es/galeria/artista . . . . 188
6.11. Resumen para la URL /es/galeria/artista . . . . . . . . . . . . . . . 189
7.1. Captura del pgina de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.2. Captura de la identificacin del administrador . . . . . . . . . . . . . . . . 198
7.3. Captura del men del administrador . . . . . . . . . . . . . . . . . . . . . 199
7.4. Captura de los datos del administrador . . . . . . . . . . . . . . . . . . . . 199
7.5. Captura de la edicin de los datos del administrador . . . . . . . . . . . . 200
7.6. Captura del panel de administracin . . . . . . . . . . . . . . . . . . . . . 200
7.7. Captura de la pantalla de administracin de artistas . . . . . . . . . . . . . 202
7.8. Captura de la pantalla de dar de alta una nueva coleccin . . . . . . . . . . 203
7.9. Captura de la pantalla que muestra los datos de una obra . . . . . . . . . . 204
7.10. Captura de la pantalla de edicin de una tcnica . . . . . . . . . . . . . . . 204
7.11. Captura de la pantalla de confirmacin de eliminacin . . . . . . . . . . . . 205

NDICE DE FIGURAS xxiii
7.12. Captura de la pantalla de traduccin . . . . . . . . . . . . . . . . . . . . . 205
7.13. Captura de ejemplo de bsquedas de obras . . . . . . . . . . . . . . . . . . 206
7.14. Captura del listado de pedidos de los clientes . . . . . . . . . . . . . . . . . 207
7.15. Captura pantalla de informacin de un pedido . . . . . . . . . . . . . . . . 208
7.16. Captura pantalla de registro de nuevo cliente . . . . . . . . . . . . . . . . . 209
7.17. Captura pantalla de datos de identificacin para el registro . . . . . . . . . 209
7.18. Captura pantalla conteniendo la informacin del usuario registrado . . . . 210
7.19. Captura pantalla de edicin de datos de identificacin del usuario . . . . . 211
7.20. Captura del catlogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
7.21. Captura de las obras recientes de la galera . . . . . . . . . . . . . . . . . . 212
7.22. Captura pantalla de bsqueda de obras de arte . . . . . . . . . . . . . . . 213
7.23. Captura la apariencia de una obra de arte . . . . . . . . . . . . . . . . . . 213
7.24. Captura de la pantalla con la informacin de la obra . . . . . . . . . . . . 214
7.25. Captura de la imagen de la obra ampliada . . . . . . . . . . . . . . . . . . 215
7.26. Captura de la cesta de la compra . . . . . . . . . . . . . . . . . . . . . . . 216
7.27. Captura de la cesta de la compra . . . . . . . . . . . . . . . . . . . . . . . 217
7.28. Captura la pgina para logarse . . . . . . . . . . . . . . . . . . . . . . . . 217
7.29. Captura de la forma de pago . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.30. Captura del pago mediante tarjeta de crdito . . . . . . . . . . . . . . . . . 218
7.31. Captura del pago mediante transferencia bancaria/ingreso en efectivo . . . 219
7.32. Captura de quienes somos . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.33. Captura de las condiciones generales . . . . . . . . . . . . . . . . . . . . . 220
7.34. Captura de como contactar con la galera . . . . . . . . . . . . . . . . . . . 221
7.35. Captura del botn para cambiar la pgina a ingls . . . . . . . . . . . . . . 221
7.36. Captura del botn para cambiar la pgina espaol . . . . . . . . . . . . . . 221
7.37. Captura del catlogo traducido . . . . . . . . . . . . . . . . . . . . . . . . 222
8.1. Captura del pgina de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . 229

xxiv NDICE DE FIGURAS
9.1. Estadsticas del repositorio del directorio app . . . . . . . . . . . . . . . . 233
9.2. Estadsticas del repositorio del directorio config . . . . . . . . . . . . . . 233
9.3. Estadsticas del repositorio del directorio public . . . . . . . . . . . . . . 233
9.4. Estadsticas del repositorio del directorio lib . . . . . . . . . . . . . . . . 234
9.5. Estadsticas del repositorio del directorio db . . . . . . . . . . . . . . . . 234
9.6. Estadsticas del repositorio del directorio test . . . . . . . . . . . . . . . . 234
9.7. Estadsticas del cdigo fuente Rails . . . . . . . . . . . . . . . . . . . . . . 234
9.8. Total de horas invertidas en el proyecto y memoria (Assembla) . . . . . . . 236
9.11. Horas invertidas cada mes (Assembla) . . . . . . . . . . . . . . . . . . . . . 236
9.9. Horas estimadas e invertidas por hitos (Assembla) . . . . . . . . . . . . . . 237
9.10. Grfica de horas por hitos (Assembla) . . . . . . . . . . . . . . . . . . . . . 237
9.12. Total horas invertidas en la aplicacin para el artista (Assembla) . . . . . . 240
9.13. Test usabilidad - Dificultad . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
9.14. Test usabilidad - Tiempo empleado . . . . . . . . . . . . . . . . . . . . . . 242
9.15. Test usabilidad - Satisfaccin . . . . . . . . . . . . . . . . . . . . . . . . . 243
10.1. Diagrama de flujo de Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
10.2. Test de usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Listado de Cdigos
4.1. Esquema de BD para la tabla admin_obras . . . . . . . . . . . . . . . . 125

5.1. Extracto del fichero Gemfile . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.2. Extracto del fichero Gemfile.lock . . . . . . . . . . . . . . . . . . . . . . . 136
5.3. Migracin de la tabla admin_obras . . . . . . . . . . . . . . . . . . . . . 142
5.4. Cabecera del modelo Admin::Obra . . . . . . . . . . . . . . . . . . . . . 144
5.5. Modelo Admin::Artistum . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.6. Modelo Admin::Obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.7. Cdigo de las relaciones del modelo Obra . . . . . . . . . . . . . . . . . . 145
5.8. Cdigo de las validaciones del modelo Obra . . . . . . . . . . . . . . . . . 145
5.9. Cdigo de los mtodos de la clase . . . . . . . . . . . . . . . . . . . . . . . 146
5.10. Contenido del fichero database.yml . . . . . . . . . . . . . . . . . . . . . 147
5.11. Cabecera del controlador Admin::Obras. . . . . . . . . . . . . . . . . . . 149
5.12. Implementacin del controlador Admin::Obras. UTF-8 . . . . . . . . . . . 149
5.13. Implementacin del controlador Admin::Obras. Helpers y filtros . . . . . 150
5.14. Implementacin del controlador Admin::Obras. Mtodos . . . . . . . . . . 150
5.15. Extracto del contenido del fichero routes.rb . . . . . . . . . . . . . . . . . 152
5.16. Lnea de cdigo para el enrutamiento de obras . . . . . . . . . . . . . . . 152
5.17. Implementacin de la vista new.html.erb utilizando partial . . . . . . . . 155
5.18. Implementacin del partial _form_1.html.erb . . . . . . . . . . . . . . . 155
5.19. Extracto de hoja de estilo (catalogo.css) . . . . . . . . . . . . . . . . . . . 156
5.20. Cabecera del modelo UserSession (models\user_session.rb) . . . . . . . . 157
5.21. Restriccin de acceso (controllers\application_controller.rb) . . . . . . . 158
5.22. Restriccin de acceso a la cesta de la compra . . . . . . . . . . . . . . . . . 158
5.23. Llamada al mtodo Search con gema MetaSearch . . . . . . . . . . . . . 159
5.24. Nombre de los campos para la bsqueda con gema MetaSearch . . . . . . 160
5.25. Configuracin del servidor de correos (setup_mail.rb) . . . . . . . . . . . 162
5.26. Metodo de confirmacin de registro (user_mailer.rb) . . . . . . . . . . . 163
5.27. Controlador invocando al mtodo del correo (user_controller.rb) . . . . . 164
5.28. Conexin con Authorize.net (config\environments\development.rb) . . . . 165
5.29. Proceso con Active Merchant (models\pedido.rb) . . . . . . . . . . . . . . 165
5.30. Fichero de traduccin al espaol . . . . . . . . . . . . . . . . . . . . . . . . 168
5.31. Fichero de traduccin al ingls . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.32. Carga de diferentes archivos de idioma . . . . . . . . . . . . . . . . . . . . 169
5.33. Idioma por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.34. Idioma por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
xxv
xxvi LISTADO DE CDIGOS
5.35. Tabla para la traduccin del modelo Obras . . . . . . . . . . . . . . . . . . 171

6.1. Pruebas unitarias sobre el modelo obras . . . . . . . . . . . . . . . . . . . 174
6.2. Pruebas de integracin para la administracin de obras . . . . . . . . . . 178
6.3. Pruebas funcionales sobre el controlador de obras . . . . . . . . . . . . . 182
8.1. Contenido del fichero librerias.sh . . . . . . . . . . . . . . . . . . . . . . 224
8.2. Contenido del fichero instalacion.sh . . . . . . . . . . . . . . . . . . . . . 225
8.3. Contenido del fichero database.yml . . . . . . . . . . . . . . . . . . . . . 227
9.1. Extracto del contenido del fichero Changelog . . . . . . . . . . . . . . . . . 238
10.1. Implementacin de la gema Paperclip en el modelo obra . . . . . . . . . 256
Parte I
Prolegmeno
1
3
Esta primera parte de la memoria de mi PFC va a contener dos cap-

tulos:
El primero ser una introduccin en el que describir en que

consiste mi proyecto junto con los objetivos que me he marcado y
por ltimo, indicar como he estructurado la presente memoria.
El segundo captulo estar dedicado a la planificacin del pro-

yecto incluyndose la metodologa que voy a emplear.
4
Captulo 1
Introduccin
En este primer captulo voy a realizar la presentacin de mi Proyecto de Fin de Car-

rera. Explico cules son los motivos, objetivos y propsito del mismo, el producto final
que deseo obtener y, por ltimo, expongo cmo est estructurada la presente memoria.
1.1. Motivacin
La realizacin de este proyecto supondr la culminacin de mis estudios de Ingeniera

Tcnica en Informtica de Gestin y un fortalecimiento personal de los conocimientos
adquiridos a lo largo de la carrera, tanto de planificacin y anlisis, como de programacin
y base de datos; as como la implicacin en el desarrollo de un proyecto completo. Por
otra parte, espero adquirir mayores conocimientos en el desarrollo de aplicaciones web,
en comercio electrnico y en lenguajes de programacin.
1.2. Propsito, objetivos y alcance del proyecto
En mi proyecto voy a desarrollar una aplicacin de comercio electrnico (e-commerce)

consistente en una Tienda Virtual. Esta podr ser adaptada a distintos requisitos, permi-
tindonos obtener una tienda para una Galera de Arte o para un Artista. De esta manera
podr evaluar las ventajas de construir la aplicacin respecto a inicializarla desde cero,
usando otros frameworks o sin framework.
Con la tienda online se pretende conseguir abrir un nuevo mercado en Internet, para
vender las obras de arte de la Galera o del Artista a travs de la red, con la oportunidad
de captar nuevos clientes y con el posible incremento de ventas que esto podra aportar.
5
6 CAPTULO 1. INTRODUCCIN
A estos, se les dar la posibilidad de poder visitar y consultar un catlogo de obras on-
line actualizado continuamente y la oportunidad de poder realizar los pedidos de manera
ms cmoda, rpida y segura.
La finalidad del proyecto no es construir un producto explotable comercialmente, sino

poder aplicar al mximo los conocimientos aprendidos durante la trayectoria de mi carrera
y adquirir nuevos conocimientos en el desarrollo de este.
Los principales objetivos de mi proyecto son:
1. Aprender a desarrollar, implementar y poner en marcha una aplicacin

Web que pueda tener una utilidad comercial, empleando la herramienta de desa-
rrollo Ruby on Rails y los conocimientos adquiridos durante la carrera.
2. Adaptar la aplicacin a distintos requisitos permitindome obtener otra a un

menor coste.
3. Realizar un anlisis comparativo del framework Ruby on Rails frente a otras

alternativas, evaluando detalladamente las ventajas y caractersticas de este respec-
to a otros.
Para cumplir con ellos, hay que salvar una serie de objetivos o subtareas que componen
el primer objetivo principal. stos se listan a continuacin:
Figura 1.1: OBJ-0001 Gestin de artistas
Figura 1.2: OBJ-0002 Gestin de colecciones

1.2. PROPSITO, OBJETIVOS Y ALCANCE DEL PROYECTO 7
Figura 1.3: OBJ-0003 Gestin de obras
Figura 1.4: OBJ-0004 Gestin de secciones
Figura 1.5: OBJ-0005 Gestin de tcnicas
Figura 1.6: OBJ-0006 Gestin del catlogo

Figura 1.7: OBJ-0007 Gestin de la cesta de la compra
Figura 1.8: OBJ-0008 Gestin de etiquetas
Figura 1.9: OBJ-0009 Gestin de seguridad
Figura 1.10: OBJ-0010 Gestin de facturacin

1.2. PROPSITO, OBJETIVOS Y ALCANCE DEL PROYECTO 9
Figura 1.11: OBJ-0011 Gestin de internacionalizacin
Figura 1.12: OBJ-0012 Gestin de usuarios
Figura 1.13: OBJ-0013 Gestin de quienes somos
Figura 1.14: OBJ-0014 Gestin de condiciones

1.3. Producto final
La aplicacin consistir en generar un sistema web formado por:
1. Un Front Office, con el que interactuarn los clientes, formado por una Tienda On-
line. Donde podrn acceder al catlogo de las Obras de Arte y realizar sus compras.
2. Un Back Office, espacio restringido que permitir al administrador gestionar toda

la informacin del sistema.
1.4. Organizacin del documento
A continuacin describo los contenidos del presente documento, as como del software
entregado en soporte informtico.
1.4.1. Organizacin de la memoria
En este apartado especifico como he estructurado esta memoria y como he organizado

la informacin en funcin de los distintos captulos que la forman.
El documento esta dividido en tres partes y cada una de ella en diferentes captulos,
los cuales describo a continuacin:
I Prolegmeno
Captulo 1 - Introduccin. Contiene una breve descripcin de mi Proyecto de

Fin de Carrera, la motivacin para su desarrollo, los objetivos y el propsito del
mismo, as como la estructuracin de la presente memoria.
Captulo 2 - Planificacin. Describe todos los aspectos relativos a la planifica-
cin del proyecto: metodologa de desarrollo, planificacin, organizacin, costes,
riesgos.
II Desarrollo
Captulo 3 - Anlisis de requisitos. Recoge la especificacin de requisitos del

proyecto, as como:
Un anlisis de la relevancia de los principales lenguajes de programacin
dentro de la industria del software, realizando una valoracin global de los
resultados obtenidos.
1.4. ORGANIZACIN DEL DOCUMENTO 11
Una comparativa de los posibles frameworks que utilizan el lenguaje con el

que voy a desarrollar mi proyecto.
Un anlisis de algunos de los frameworks ms utilizados en comercio elec-
trnico B2C.
Captulo 4 - Diseo del sistema. Alberga la arquitectura general del sistema y
los aspectos ms destacables durante las fases de diseo.
Captulo 5 - Implementacin del sistema. Describir los detalles ms signifi-
cativos de la fase de implementacin de mi aplicacin: entorno tecnolgico,
estructura de la aplicacin, implementacin del modelo, controlador y vista . . .
Captulo 6 - Pruebas del sistema. Contiene la documentacin de los diferentes
tipos de prueba llevados a cabo durante el desarrollo de la aplicacin.
III Eplogo
Captulo 7 - Manual de usuario. Detalla las instrucciones de uso del sistema.

Captulo 8 - Manual de instalacin y explotacin. Especifica las instrucciones
de instalacin y explotacin del sistema.
Captulo 9 - Conclusiones. Muestra las lecciones aprendidas tras el desarrollo del
proyecto, as como unas sugerencias sobre lneas de trabajo futuro.
Captulo 10 - Anexos. La memoria contiene los siguientes anexos:
Anexo (A) Glosario de acrnimos. Listado de acrnimos que nos podemos
encontrar en el presente documento.
Anexo (B) Glosario de definiciones. Contiene un catlogo de los trminos
utilizados junto con sus definiciones.
Anexo (C) Gemas. En este anexo nos vamos a encontrar con las descripcio-
nes de las gemas empleadas en el desarrollo de la aplicacin.
Anexo (D) Lenguaje Ruby. Habla sobre el lenguaje Ruby y sus caracters-
ticas.
Anexo (E) Metodologa gil. Describe la metodologa gil y la metodologa
scrum.
Anexo (F) Pruebas en Rails. Este anexo define las pruebas realizadas en
Rails.
Anexo (G) Rails. Trata el entorno Rails y sus caractersticas.
Anexo (H) Relacin de Casos de Uso y Mockups. Muestra un listado in-
dicando para cada Caso de Uso el mockup que lo implementa.
Anexo (I) Test de usabilidad. Test de usabilidad realizado a los usuarios.
Glosario de trminos. Contiene una relacin de trminos junto con las pginas en
las que aparecen.
Bibliografa. Ofrece las referencias utilizada para el desarrollo del proyecto.
1.4.2. Organizacin del software
A continuacin describo el contenido del CD que acompaa a la presente memoria.

ste contendr las siguientes carpetas:
aplicaciones: Contiene las dos aplicaciones realizadas para el proyecto.
galeriaArte: Cdigo de la aplicacin para la Galera de Artes.

galeriaArtista: Cdigo de la aplicacin del Artista.
changelog: Incluye el fichero Changelog conteniendo el trabajo realizado cada da sobre

el proyecto.
estadisticas_svn: Incluye las estadsticas de las diferentes carpetas del sistema soft-
ware a travs de la aplicacin StatsSVN (carpeta estadisticas_sist_software) y el
anlisis de estadsticas de cdigo incluido dentro de Ruby on Rails (carpeta estadis-
ticas_codigo).
mockup: Contiene los mockup realizados para el presente proyecto.
usabilidad: Incluye los resultados del test de usuabilidad realizado a los usuarios.
Captulo 2
Planificacin
En este captulo se describen todos los aspectos relativos a la planificacin del proyecto:
modelo de negocio, metodologa que voy a emplear, organizacin, planificacin temporal,
costes del desarrollo del proyecto y gestin de riesgos.
2.1. Modelo de negocio
La aplicacin que voy a desarrollar pertenece al Modelo de Negocio B2C Business-

to-Consumer , estrategia que desarrollan las empresas para establecer relaciones comer-
ciales directas con sus clientes a travs de Internet.
2.2. Metodologa
Para asegurar el xito, durante el desarrollo de la aplicacin, no es suficiente contar

con notaciones de modelado y herramientas, hace falta un elemento importante: la me-
todologa de desarrollo, la cual nos provee de una direccin a seguir para la correcta
aplicacin de los dems elementos.
sta nos va a ayudar a estructurar, planear y controlar el proceso de desarrollo

del sistema.
Seguir una Metodologa gil [Marcelo Hernn, Schenone] (ver anexo E), ya que lo
que necesito es poder gestionar mi proyecto de una forma gil, debido a que hoy en da lo
que se necesita es poder incorporar cambios con rapidez y en cualquier fase del proyecto.
Esta metodologa consiste en un marco de trabajo conceptual de la Ingeniera de

Software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del
proyecto.
13
14 CAPTULO 2. PLANIFICACIN
Concretamente, seguir el mtodo Scrum (ver anexo E), el cual es iterativo e incre-
mental, en el que divido el desarrollo de mi aplicacin en ciclos llamados sprints y, en
cada uno de ellos, trabajo sobre una lista de requisitos priorizada y al final de dicho ciclo,
obtengo como resultado un producto terminado y entregable.
Figura 2.1: Diagrama del proceso Scrum
Cada iteracin del ciclo de vida incluye:
planificacin,
anlisis de requerimientos,
diseo,
codificacin,
revisin y
documentacin.
2.3. Planificacin del proyecto
En este apartado voy a establecer el orden de las tareas y realizar una estimacin del
tiempo que creo necesario para la realizacin de mi proyecto. Tambin mostrar un anlisis
de la desviacin temporal, comparando los tiempos estimados con los que finalmente he
empleado.
2.3. PLANIFICACIN DEL PROYECTO 15
2.3.1. Objetivo inicial
El objetivo inicial de mi proyecto era desarrollar una aplicacin de comercio electrnico

(e-commerce) consistente en una Tienda Virtual para una Galera de Arte.
Finalmente, este objetivo se ha ampliado, desarrollando una aplicacin que puede ser
adaptada a distintos requisitos, permitindonos obtener una Tienda Virtual para una
Galera de Arte o para un Artista.
2.3.2. Divisin del trabajo
He diseado un diagrama con la Estructura de Desglose del Trabajo, WBS, en el que

muestro las actividades que he credo necesarias para completar mi proyecto.
Figura 2.2: Estructura de desglose del trabajo
Planificacin General. Al comienzo del proyecto he realizado una planificacin

general para marcarme los pasos que tena que seguir para que el proyecto fuese
exitoso. Despus, en cada Sprint, realizar una planificacin especfica.
Bsqueda bibliogrfica. He realizado una bsqueda extensa de documentacin a

la cual poder acudir en cualquier fase del proyecto.
Adquisicin de conocimientos. Al comienzo del proyecto no tena conocimientos

acerca de Comercio Electrnico, Ruby on Rails, CSS ni de LATEX [Burgos Pintos,
Aris; Cornejo Barrios, Alicia; Gmez Mellado, Antonio; Otros]. Debido a ello he
realizado un perodo inicial de aprendizaje y asimilacin de conceptos bsicos en
el que se incluyen, cursar la asignatura de Comercio Electrnico de Ingeniera In-

formtica y participar en el Taller de LATEX impartido por la Escuela durante la
Semana de la Ingeniera.
Anlisis comparativo. Efectuar un anlisis comparativo del framework Ruby on

Rails frente a otras alternativas, para poder evaluar las ventajas y caractersticas
de este respecto a otros.
Desarrollo de la aplicacin. Una vez adquiridos los conocimientos bsicos ir

desarrollando la aplicacin a travs de diversos Sprints y en cada uno de ellos
efectuar las siguientes actividades.
Planificacin. Para cada uno de los Sprint efectuar una planificacin espe-
cfica. Esta la dividir en dos pasos:
Seleccionar los requisitos a travs de entrevistas con el cliente1 .
Planificar el Sprint elaborando una lista con las tareas que tenga que
ejecutar para poder desarrollar los requisitos anteriormente marcados y
asignndole, a cada una de las tareas, los tiempos de desarrollo con un
margen de error para no verme demasiado comprometida.
Anlisis y diseo. Estas actividades las ir realizando de forma paralela a
la segunda y tercera de las fases anteriores, ya que conforme vaya analizando
las necesidades del proyecto tendr que recurrir a la documentacin recopilada
para analizar su viabilidad, y para saber cmo poder llevarlas a cabo.
Implementacin. En esta fase se realizar tambin una serie de pruebas para
ir comprobando que lo que se vaya a implementar funcionaba correctamente.
A la vez que las pruebas vayan funcionando, implementar el cdigo de la
aplicacin. Durante esta actividad sera necesario volver a las fases anteriores:
para consultar cmo hacer las cosas o bien para dar solucin a los problemas
con los que me vaya encontrando.
Revisin. Durante las actividades anteriores y una vez terminadas stas, rea-
lizar revisiones del trabajo desarrollado con el fin de comprobar que se vayan
cumplido los objetivos y los requisitos marcados.
Integracin en la Web. El despliegue de la aplicacin en la web lo realizar
en la plataforma Heroku. ste ser continuo, ya que cada vez que vaya ter-
minando un Sprint subir al servidor el desarrollo realizado de la aplicacin,
comprobando tambin de esta manera su funcionamiento y pudiendo as el
tutor o el cliente tener acceso a ella de forma rpida y sencilla en cualquier
momento para su revisin.
El despliegue de la Galera de Arte se puede visualizar en la siguiente direccin:
http://gadeirart.heroku.com/.
Documentacin. Durante todo el proceso del proyecto y al final de cada
Sprint ir completando la documentacin.
1
Cliente: Galerista o Artista
Evaluacin. Al finalizar el proyecto elaborar una evaluacin del trabajo desarro-

llado, realizando una serie de anlisis y comentando las posibles mejoras.
Completar memoria. Una vez finalizado el proyecto repasar y terminar de
completar la presente memoria.
Elaborar presentacin. Para dar por concluido el presente proyecto y poder
realizar su presentacin ante el tribunal, elaborar una presentacin del mismo.
A parte de las actividades anteriores mencionadas, realizar:
Reuniones con el tutor. Se ir realizando un seguimiento del proyecto. ste se

llevar a cabo mediante reuniones presenciales para ir viendo el avance y determinar
los cambios que se pueden realizar en la aplicacin. Tambin har uso del correo
electrnico para comunicarme con el tutor, para que me pueda solventar las dudas
que me vayan surgiendo.
Reuniones con el cliente. Se realizarn reuniones con el cliente a lo largo del
proyecto donde se definirn las Historias de Usuario y se validar el sistema.
2.3.3. Estimacin de tiempos
Para la estimacin temporal he tenido en cuenta los siguientes parmetros:
Das a la semana: 5
Horas que puedo invertir por da: 4h.
Todos los tiempos estarn expuestos a posibles imprevistos.
Actividad Duracin estimada

Planificacin General y propuesta 4 das
Actualizacin bibliogrfica 15 das
Adquisicin previa de conocimientos 27 das
Anlisis comparativo 3 das
Desarrollo de la aplicacin 279 das
Integracin en la web 15 das
Evaluacin 2 das
Completar memoria 5 das
Elaborar Presentacin 10 das
Esfuerzo total 360 das (72 semanas)
Tabla 2.1: Estimacin de tiempos del proyecto

2.3.4. Identificacin de Sprints
Para el correcto desarrollo, control y seguimiento de mi proyecto, he establecido una

serie de Sprints2 con los que podr ir viendo el avance y si se van cumpliendo los objetivos.
Sprint 0. Contendr las siguientes actividades:
Planificacin general.
Elaboracin de la propuesta de proyecto.
Bibliografa
Adquisicin de conocimientos . . .
Sprint 1 - Comienzo de la aplicacin. Algunas de las tareas de este sprint son:
Instalacin de programas.
Creacin de las BBDD.
Creacin de la estructura de la aplicacin.
CSS . . .
Sprint 2 - Artistas. Algunas tareas son (similares en los siguientes sprints):
Implementacin Historias de Usuario.

Pruebas unitarias.
Pruebas funcionales.
Pruebas de integracin . . .
Sprint 3 - Colecciones.
Sprint 4 - Obras.
Sprint 5 - Secciones.
Sprint 6 - Tcnicas.
Sprint 7 - Catlogo.
Sprint 9 - Cesta de la compra.
Sprint 10 - Etiquetado.
Sprint 11 - Seguridad.
Sprint 12 - Facturacin.
2
Sprints: Hitos.
Sprint 13 - Internacionalizacin.
Sprint 14 - Inicio.
Sprint 15 - Contactar.
Sprint 16 - Quienes somos.
Sprint 17 - Condiciones.
Sprint 18 - Panel Administracin.
2.3.5. Planificacin temporal
La planificacin temporal del proyecto la voy a mostrar mediante el Diagrama de

Gantt que he preparado con la herramienta OpenProj. A travs de ste, he establecido la
asignacin temporal prevista para la realizacin de las actividades, indicando los tiempos
y aquellas tareas que pueden realizarse a lo largo del proyecto.
El desarrollo del Diagrama de Gantt de ste proyecto est representado en funcin de

una persona, por lo que no se darn las relaciones de actividades solapadas ya que no
ser posible realizar simultneamente dos tareas al mismo tiempo.
A continuacin muestro la relacin de actividades representadas en el Diagrama de

Gantt junto con su duracin, fecha de inicio y de terminacin.
Figura 2.3: Relacin actividades Diagrama de Gantt

En la figura 2.3, para que quede un poco ms claro, podemos observar la relacin de
actividades del proyecto en general.
Y en la figura 2.4 les muestro, en detalle, la relacin de actividades del diagrama para
la actividad Desarrollo de la aplicacin que es la que ms tiempo me va a llevar.
Figura 2.4: Relacin actividades Diagrama de Gantt - Desarrollo de la aplicacin

Seguidamente se muestra el Diagrama de Gantt del proyecto, el cual, para que quede
un poco ms claro, lo he dividido en tres grficos.
Figura 2.5: Diagrama de Gantt

Figura 2.6: Diagrama de Gantt

Podemos observar en el grfico, en color azul, las tareas que pueden realizarse o des-
plazarse a lo largo del proyecto sin que ello suponga un retraso en la realizacin del mismo,
y en color rojo las tareas crticas, las cuales deben realizarse en el orden y la posicin
indicadas.
2.3.6. Anlisis de la desviacin temporal
A continuacin muestro una comparacin de los tiempos estimados con los finalmente
empleados.
Das Horas Horas Diferencia

Sprint estimados estimadas invertidas horas
(4h/da) Hor Min Hor Min
Planificacin general 2 8 5h 30m 2h 30m
Propuesta proyecto 2 8 9h -1h
Actualizacin bibliogrfica 15 60 25h 35h
Adquisicin de conocimientos 27 108 - 108h
Anlisis comparativo 3 12 - 12h
Desarrollo de la aplicacin 279 1116 1028h 30m 87h 30m
* Sprint 1 - Comienzo 6 24 15h 9h
* Sprint 2 - Artistas 10 40 30h 15m 9h 45m
* Sprint 3 - Colecciones 5 20 15h 45m 4h 15m
* Sprint 4 - Obras 20 80 68h 30m 11h 30m
* Sprint 5 - Secciones 5 20 12h 15m 7h 45m
* Sprint 6 - Tcnicas 5 20 18h 2h
* Sprint 7 - Catlogo 30 120 123h 30m -3h 30m
* Sprint 9 - Cesta de la compra 10 40 45h 30m -5h 30m
* Sprint 10 - Etiquetado 7 28 26h 2h
* Sprint 11 - Autenticacin 20 80 71h 30m 8h 30m
* Sprint 12 - Compra y . . . 30 120 130h -10h
* Sprint 13 - Internacionalizacin 20 80 85h 15m -5h 15m
* Sprint 14 - Memoria 100 400 351h 15m 48h 45m
* Sprint 15 - Men Inicio 2 8 6h 2h
* Sprint 16 - Men Contactar 2 8 3h 5h
* Sprint 17 - Men Quienes Somos 2 8 7h 30m 30m
* Sprint 18 - Men Condiciones 2 8 6h 15m 1h 45m
* Sprint 19 - Administracin 3 12 13h -1h
Integracin en la web 15 60 93h -33h
Evaluacin 2 8 - 8h
Completar memoria 5 20 34 -14h
Elaborar Presentacin 10 40 - 40h
Desviacin temporal 360 1440 1195h 245h
Tabla 2.2: Estudio del tiempo del proyecto

La adquisicin de conocimientos no est contabilizada directamente en su apartado,

ya que los he ido adquiriendo con anterioridad al comienzo del proyecto: cursando la
asignatura de Comercio Electrnico de Ingeniera Informtica y realizando el Taller de
LATEX impartido por la Escuela, y durante la realizacin del proyecto, contabilizando este
tiempo en los sprints correspondientes.
Las horas estimadas e invertidas en el anlisis comparativo y la evaluacin estn

contabilizadas dentro del Sprint 14 - Memoria.
En resumen, puedo comentar que he estimado ms o menos el nmero de semanas

necesarias para la realizacin del proyecto y de la memoria. Teniendo en cuenta, que
en este estudio estn contabilizadas las 10 semanas que invertir prximamente para la
realizacin de la presentacin del proyecto.
Semanas estimadas 72 semanas

Semanas invertidas 60 semanas
Desviacin temporal 12 semanas
Tabla 2.3: Estudio de la desviacin temporal del proyecto
2.4. Organizacin del proyecto
En esta sesin hablar sobre la relacin de personas (roles) involucradas en el proyecto

as como de los recursos inventariables utilizados.
2.4.1. Participantes
2.4.1.1. Estructura interna
En la figura 2.7 se muestra la jerarqua del equipo, as como la relacin existente entre
ellos.
2.4.1.2. Roles y responsabilidades
Podemos distinguir los siguientes roles en funcin de su perfil, segn lo recogido en

Mtrica v.3 - Participantes [PAE. Portal Administracin Electrnica (2011)].
Supervisor del proyecto. Se ocupar de guiar y supervisar el proyecto. Este rol lo

desempear el tutor del proyecto J.M. Dodero.
2.4. ORGANIZACIN DEL PROYECTO 25
Figura 2.7: Organigrama de la Organizacin
Cliente. Aporta informacin sobre las necesidades planteadas y valida los resultados
con el fin de garantizar la identificacin, comprensin e incorporacin de todos los
requisitos con las prioridades adecuadas.
Para el proyecto el cliente es un artista-galerista.
Cada uno de los roles que voy a describir a continuacin sern desempeados por mi
persona en el desarrollo del proyecto.
Perfil Jefe de Proyecto. Ejerce labores de coordinacin y direccin de equipos huma-

nos especializados en la realizacin de actividades propias de un proceso o interfaz
de PAE. Portal Administracin Electrnica (2011). La figura principal es el Jefe de
Proyecto, el cual recibe el apoyo de los distintos responsables durante la realizacin
de procesos o determinadas actividades a lo largo del proyecto.
Este perfil, vendr representado por mi persona, con las siguientes responsabilida-
des:
Realizar la estimacin del esfuerzo necesario para llevar a cabo el proyecto.
Seleccionar la estrategia de desarrollo, determina la estructura del mismo selec-
cionando los procesos principales de PAE. Portal Administracin Electrnica
(2011) que lo integran.
Fijar el calendario de hitos y entregas y establece la planificacin del proyecto.
Es el encargado de dirigir el proyecto, realizando las labores de seguimiento
y control del mismo, revisin y evaluacin de resultados y coordinacin del
equipo de proyecto.
Se ocupa tambin de la gestin y resolucin de incidencias que puedan surgir
durante el desarrollo del proyecto as como de la actualizacin de la planifica-
cin inicial.
Perfil Analista. La responsabilidad del Analista es elaborar un catlogo detallado de

requisitos que permita describir con precisin el sistema de informacin, para lo
cual mantendrn entrevistas y sesiones de trabajo con los clientes3 . Estos requisitos
permiten al analista elaborar los distintos modelos que sirven de base para el diseo,
obteniendo los modelos de clases e interaccin de objetos en anlisis orientado a
objeto. As mismo, realizan la especificacin de las interfaces entre el sistema y el
usuario.
Dentro de este perfil, se distinguirn los siguientes roles:
Analista
Administrador de Bases de Datos. Participa en la obtencin del diseo
fsico de datos, definiendo la estructura fsica de datos que utilizar el sistema a
partir del modelo lgico de datos normalizado o del modelo de clases, teniendo
presentes las caractersticas especficas del sistema de gestin de base de datos
concreto a utilizar, los requisitos establecidos para el sistema de informacin,
y las particularidades del entorno tecnolgico, se consiga una mayor eficiencia
en el tratamiento de los datos.
Si se va a realizar una migracin de datos colabora con el equipo de proyecto
estimando los volmenes de las estructuras de datos implicadas, definiendo los
mecanismos de migracin y carga inicial de datos y participando activamente
en su realizacin.
Una vez que el sistema est en produccin se ocupa de la gestin y operativa
asociada a las bases de datos y al software en el que estn implementadas.
Perfil Programador. La funcin del programador es construir el cdigo que dar lugar
al producto resultante en base al diseo tcnico realizado por el analista o analista
programador, generando tambin el cdigo asociado a los procedimientos de migra-
cin y carga inicial de datos. Igualmente se encarga de la realizacin de las pruebas
unitarias y participa en las pruebas de conjunto de la aplicacin.
2.4.2. Equipo informtico
2.4.2.1. Hardware
El hardware del equipo informtico utilizado para la realizacin del proyecto presenta
las siguientes caractersticas:
Ordenador porttil Aspire 5740G, Intel Core i3 processor 330M, 4GB RAM, 320
GB HDD.
Impresora Hewlett Packard Deskjet 5550.

3
2.5. COSTES 27
2.4.2.2. Software
El software empleado para el desarrollo bajo el entorno Ubuntu es el siguiente:
Lenguajes: Ruby 1.8.7, HTML, CSS, JavaScript (ver seccin 5.1.1).
Framework: Rails 3.0.9 (ver seccin 3.6.2.1).
Base de datos: MySql Server Versin 5.1.54 - 1ubuntu4 (ver seccin 5.1.2).
Sistema operativo: Ubuntu Linux 11.04.
Navegador: Firefox 4.0.
La justificacin de la eleccin de cada uno de ellos podemos verla en la secciones que

aparecen entre parntesis o a continuacin:
Sistema Operativo: Un elemento bsico e imprescindible a la hora de construir

una aplicacin es la eleccin del S.O.
Para el desarrollo de mi aplicacin he seleccionado el S.O. Ubuntu y algunas de las
razones son:
Instalacin de programas sencilla.

No necesita antivirus.
Es potente y fiable.
Coste cero.
Integracin con el resto de componentes: lenguajes de programacin, bases de
datos y herramientas de desarrollo.
Navegador: La aplicacin web se construir bajo el requisito de independencia

del navegador. Es por ello por lo que se utilizarn varios navegadores durante el
desarrollo probando as que se cumple dicho requisito.
2.5. Costes
En esta seccin voy a elaborar una estimacin de los costes del proyecto.
Para ello evaluar cada uno de los recursos implicados en el desarrollo: recursos huma-
nos, herramientas, costes indirectos propios de las empresas que trabajan en este sector
(conexin a internet, material de oficina, recambios de impresora. . . ) y los costes del
equipo informtico (ordenador e impresora), ya que aunque las empresas dedicadas al
desarrollo de software cuentan con el equipo informtico necesario, hay que tenerlos en
cuenta porque puede surgir cualquier imprevisto, durante el desarrollo del proyecto, que
implique el tener que realizar una nueva adquisicin.
Para obtener una estimacin de los costes de personal he consultado diferentes web
dedicadas a ofertas de trabajo (infojobs, tecnoempleo. . . ) y he obtenido que la media
salarial ronda los 25.000e/brutos/ao, a lo que hay que aadir el coste de la Seguridad
Social que se considera un tercio de la base de cotizacin. Desglosando se obtiene:
Salario mensual. Anualmente se ha estimado un sueldo de 25.000e, que repartidos

en 14 pagas hacen que el salario mensual sea de 1.785,72e.
Seguridad social. El 33 % del sueldo mensual equivale a 589.29e/mes.
Luego, el coste total mensual del personal asciende a 2.375e.
Para los costes del equipo informtico he tenido en cuenta el tiempo en el que se
amortiza. Un equipo suele tener una vida de 3 aos, por lo que si su coste es de 1.500e
se amortizarn anualmente 500e.
Los costes indirectos van a suponer un 10 % del coste del personal y los costes de las
herramientas necesarias para el proyecto, no los tengo en cuenta ya que la mayora son
software libre o la empresa ya cuenta con ellos.
Para poder determinar el tiempo empleado en el desarrollo de la aplicacin, he ido

llevando el control de las horas invertidas en Assembla, habiendo utilizado un total de
1.195h horas correspondiente a 30 semanas.
Para el clculo he tenido en cuenta los siguientes parmetros:
Personas implicadas en el proyecto: 1

Das a la semana: 5
Horas invertidas por da: 8h.
Meses empleados: 7 meses (30 semanas).
A continuacin, podemos ver la informacin recogida en la siguiente tabla:
Nombre Descripcin Tipo Coste Total

Personal cualificado
Personal Humano 2.375e/mes 16.625e
y especializado
Equipo
PC e impresora Activo 42e/mes 294e
informtico
Costes 10 % del coste
Tinta, luz. . . Material 1.662,5e
indirectos del personal
Total 18.581,50e
Tabla 2.4: Costes del proyecto
2.6. GESTIN DE RIESGOS 29
2.6. Gestin de riesgos
Un proceso efectivo de gestin de riesgos es un importante elemento para que un

proyecto de software sea exitoso.
La gestin de riesgos [Alarcos] nos permite definir de forma estructurada, operacional

y organizada, una serie de actividades para gestionar los riesgos del proyecto a lo largo
de su ciclo de vida.
El propsito es identificar los riesgos que se puedan presentar en el desarrollo del

proyecto, analizarlos, calcular la exposicin y, en base a ello, poder priorizarlos, para es-
tablecer estrategias de control y resolucin que permitan ejercer una correcta supervisin
de los mismos.
2.6.1. Evaluacin de riesgos
2.6.1.1. Identificacin de riesgos
Lo primero que voy a hacer es identificar cada uno de los posibles riesgos que pueden
afectar al proyecto.
Riesgos en la planificacin. Que puede conllevar el fracaso del proyecto. Esto es,
que no se cumplan los objetivos con las estimaciones de tiempo y recursos.
Causas:
Planificacin muy optimista.

La planificacin no incluye tareas necesarias.
Decisiones de planificacin impuestas por el cliente.
Infraestimacin de tiempos de desarrollo de las tareas.
Un retraso en una tarea produce retrasos en cascada en las tareas dependientes.
Riesgos en la organizacin y gestin.
La planificacin es demasiado mala para ajustarse a la velocidad de desarrollo

deseada.
El plan del proyecto se abandonan por la presin, llevando al caos y a un
desarrollo ineficiente.
Riesgos en la infraestructura. Causado por:
Los espacios estn disponibles pero no son adecuados (por ejemplo, cableado
de red).
Herramientas de desarrollo no disponibles o funcionamiento/prestaciones in-

deseadas.
La curva de aprendizaje para la nueva herramienta de desarrollo es ms larga
de lo esperado.
Riesgos en los clientes. Causas:
Problemas con el personal de desarrollo: entregas fuera de plazo, cree que no

entienden bien sus requisitos, dificultad en la comunicacin, etc.
El ciclo de revisin/decisin del cliente es ms lento que lo previsto.
No participacin del cliente en la revisin, implicando requisitos inestables.
El cliente insiste en tomar decisiones tcnicas que alargan la planificacin.
El cliente intenta controlar el ritmo de desarrollo y produccin.
El cliente insiste en nuevos requisitos.
El tiempo de comunicacin del cliente (por ejemplo, tiempo para responder a
las preguntas para aclarar requisitos) es ms lento del esperado.
En el ltimo momento, al cliente no le gusta el producto, por lo que hay que
volver a disearlo o a construirlo.
No se ha solicitado informacin al cliente, por lo que el producto al final no se
ajusta a las necesidades de ste, y hay que volver a crearlo.
Riesgos en los requisitos: Fundamentalmente debidos a los cambios en los requisitos,

derivados del no establecimiento de los requisitos del proyecto y cambiarlos a medida
que ste avanza. Puede deberse a:
La no correcta definicin de los requisitos y su redefinicin conforme avanza el

proyecto.
Se aaden requisitos extras.
Las partes del proyecto que no se haban especificado claramente consumen
ms tiempo de lo previsto.
Riesgos en el producto. Causas:
Utilizar lo ltimo en informtica alarga la planificacin de forma impredecible.

El desarrollo de funciones software errneas requiere volver a disearlas y a
implementarlas.
El desarrollo de una interfaz de usuario inadecuada requiere volver a disearla
y a implementarla.
El desarrollo de funciones software innecesarias alarga la planificacin.
El trabajo con un entorno software desconocido causa problemas no previstos.
Riesgos en el personal.
Problemas con los clientes.

Las tareas preliminares no se acaban a tiempo (por ejemplo, formacin).
Falta de especializacin afecta a los defectos y la necesidad de repetir tareas.
El personal necesita tiempo extra para aprender nuevos lenguajes o herramien-
tas.
Falta de motivacin del personal del equipo de proyecto.
Riesgos en diseo e implementacin. Causados por:
No se considera necesario realizar el diseo y se pasa directamente a la imple-

mentacin.
El diseo se realiza ms por cumplir una metodologa que porque se considere
necesario o til.
Se realiza un diseo simple y preliminar que no resuelve los problemas que
obligan ms tarde a redisear y volver a codificar.
El diseo es demasiado detallado y posee complicaciones innecesarias.
Un mal diseo implica volver a disear e implementar.
No es posible implementar la funcionalidad deseada en el lenguaje de progra-
macin.
No es posible integrar los componentes desarrollados y es necesario redisear
y repetir algunas tareas de programacin.
Riesgos en el proceso. Causas:
La falta de un seguimiento exacto del progreso hace que se desconozca que el

proyecto est retrasado hasta que est muy avanzado.
La falta de rigor (ignorar los fundamentos y estndares del desarrollo de soft-
ware) en los procesos provoca errores de comunicacin, problemas de cali-
dad. . . que conducen a la repeticin de tareas.
El exceso de rigor hace que se progrese ms lentamente de lo previsto.
La falta de entusiasmo en la gestin de los riesgos impide detectar los riesgos
ms importantes del proyecto.
La gestin de los riesgos del proyecto consume ms tiempo del esperado.
2.6.1.2. Anlisis de riesgos
Una vez identificados los riesgos en el apartado 2.6.1.1, el siguiente paso es analizar
cada uno de ellos para determinar su impacto.
Para ello se realizarn los siguientes clculos:
Clculo del impacto o exposicin a un riesgo.

Impacto del riesgo = Probabilidad del riesgo Magnitud del riesgo (prdida)
Estimacin de la magnitud de la prdida: Efecto sobre los objetivos del pro-

yecto en caso de ocurrir. Se computar en unidades de tiempo (retraso).
Estimacin de la probabilidad de un riesgo: Porcentaje de probabilidad de
que ocurra un riesgo, en una escala de 1 a 100, siendo 1: baja probabilidad y 100:
mxima probabilidad.
En las siguientes tablas se recogen los parmetros mencionados para cada riesgo:
Magnitud de la Exposicin al
Riesgo Probabilidad
prdida riesgo
Planificacin muy optimista 50 % 5 semanas 2,5 semanas
Planificacin no incluye tareas ne- 25 % 4 semanas 1 semana
cesarias
Decisiones impuestas por cliente 25 % 3 semanas 0,75 semana
Infraestimacin tiempos desarro- 50 % 4 semanas 2 semanas
llo tareas
Retrasos en cascada 10 % 6 semanas 0,6 semana
Tabla 2.5: Anlisis de riesgos en la planificacin
Riesgo Probabilidad
prdida riesgo
Planificacin mala 10 % 5 semanas 0,5 semana
Abandono plan proyecto 10 % 5 semanas 0,5 semana
Tabla 2.6: Anlisis de riesgos en la organizacin
Riesgo Probabilidad
prdida riesgo
Espacios no adecuados 5% 5 semanas 0,25 semana
Herramientas no disponibles o 50 % 5 semanas 2,5 semanas
funcionamiento/prestaciones in-
deseadas
Curva de aprendizaje ms larga 10 % 6 semanas 0,6 semana
Tabla 2.7: Anlisis de riesgos en la infraestructura

Riesgo Probabilidad
prdida riesgo
No correcta definicin de requisi- 50 % 5 semanas 2,5 semanas
tos
Se aaden requisitos extra 50 % 15 semanas 7,5 semanas
Partes del proyecto no especifica- 45 % 10 semanas 4,5 semanas
das claramente
Tabla 2.8: Anlisis de riesgos en los requisitos
Riesgo Probabilidad
prdida riesgo
Falta seguimiento del progreso 20 % 10 semanas 2 semanas
Repeticin de tareas 10 % 10 semanas 1 semana
Exceso de rigor 30 % 10 semanas 3 semanas
Incapacidad de deteccin riesgos 40 % 7 semanas 2,8 semanas
ms importantes
La gestin de los riesgos necesita 40 % 4 semanas 1,6 semanas
ms tiempo del esperado
Tabla 2.9: Anlisis de riesgos en el proceso
Riesgo Probabilidad
prdida riesgo
Problemas con el equipo de desa- 20 % 5 semanas 1 semana
rrollo
Lento ciclo de revisin/decisin 30 % 3 semanas 0,9 semana
del cliente
No participacin del cliente en la 10 % 4 semanas 0,4 semana
revisin
El cliente insiste en tomar decisio- 30 % 5 semanas 1,5 semanas
nes tcnicas que alargan la plani-
ficacin
El cliente intenta controlar el rit- 5% 5 semanas 0,25 semana
mo de desarrollo y produccin
El cliente insiste en nuevos requi- 25 % 5 semanas 1,25 semanas
sitos
Tiempo de comunicacin del 5% 4 semanas 0,20 semana
cliente lento
Al cliente no le gusta el producto 5% 5 semanas 0,25 semana
No se ha solicitado informacin al 15 % 6 semanas 0,9 semana
cliente
Tabla 2.10: Anlisis de riesgos en los clientes

Riesgo Probabilidad
prdida riesgo
Problemas con los clientes 20 % 5 semanas 1 semana
Las tareas preliminares no se aca- 30 % 5 semanas 1,5 semanas
ban a tiempo
Falta de especializacin 40 % 4 semanas 1,6 semanas
El personal necesita tiempo extra 50 % 4 semanas 2 semanas
de aprendizaje
Falta de motivacin 20 % 5 semanas 1 semana
Tabla 2.11: Anlisis de riesgos en el personal
Riesgo Probabilidad
prdida riesgo
Utilizar lo ltimo en informtica 5% 5 semanas 0,25 semana
Desarrollo funciones errneas 25 % 10 semanas 2,5 semanas
Desarrollo interfaz inadecuada 10 % 5 semanas 0,5 semana
Desarrollo funciones innecesarias 15 % 10 semanas 1,5 semanas
Trabajo en entorno desconocido 10 % 5 semanas 0,5 semana
Tabla 2.12: Anlisis de riesgos en el producto
Riesgo Probabilidad
prdida riesgo
Pasar directamente a implemen- 15 % 10 semanas 1,5 semanas
tar
Diseo por cumplir 20 % 8 semanas 1,6 semanas
Diseo simple y preliminar 15 % 10 semanas 1,5 semanas
Diseo demasiado detallado y con 30 % 3 semanas 0,9 semana
complicaciones innecesarias
Imposibilidad implementar fun- 40 % 4 semanas 1,6 semanas
cionalidad
No es posible integrar los compo- 40 % 5 semanas 2 semanas
nentes desarrollados
Tabla 2.13: Anlisis de riesgos en diseo e implementacin

2.6.1.3. Priorizacin de riesgos
De acuerdo con el anlisis recogido en el punto anterior y tras un estudio de qu causas

pueden influir en otras, he establecido el orden de los riesgos de mayor a menor prioridad,
que precisan su control de manera inminente:
1. Planificacin muy optimista.

2. Herramientas de desarrollo no disponibles o funcionamiento/prestaciones indesea-
das.
3. La no correcta definicin de los requisitos y su redefinicin conforme avanza el
proyecto.
4. El personal necesita tiempo extra para aprender nuevas herramientas.
5. La falta de un seguimiento exacto del progreso hace que se desconozca que el pro-
yecto est retrasado hasta que est muy avanzado.
6. No es posible integrar los componentes desarrollados y es necesario redisear y
repetir algunas tareas de programacin.
7. No es posible implementar la funcionalidad deseada en el lenguaje de programacin.
8. Se realiza un diseo simple y preliminar que no resuelve los problemas que obligan
ms tarde a redisear y volver a codificar.
A continuacin muestro la tabla de estimacin de riesgos priorizada.
Riesgo Probabilidad
prdida riesgo
Planificacin muy optimista 50 % 5 semanas 2,5 semanas
Herramientas no disponi- 50 % 5 semanas 2,5 semanas
bles o funcionamiento/pres-
taciones indeseadas
No correcta definicin de re- 50 % 5 semanas 2,5 semanas
quisitos
El personal necesita tiempo 50 % 4 semanas 2 semanas
extra de aprendizaje
Falta seguimiento del pro- 20 % 10 semanas 2 semanas
greso
No es posible integrar los 40 % 5 semanas 2 semanas
componentes desarrollados
Imposibilidad implementar 40 % 4 semanas 1,6 semanas
funcionalidad
Diseo simple y preliminar 15 % 10 semanas 1,5 semanas
Tabla 2.14: Estimacin de riesgos priorizados

2.6.2. Control de riesgos
En la seccin 2.6.1.3 se defini un listado de los principales riesgos que se deben con-
trolar. La presente seccin tiene dos objetivos principales, por un lado describir aquellas
medidas que minimizarn la probabilidad de aparicin de estos riesgos y por otro, describir
aquellas acciones a llevar a cabo en el caso de que se produzca alguno de ellos.
2.6.2.1. Reduccin de riesgos
Riesgo 1: Planificacin muy optimista.

A la hora de realizar la planificacin ser obligatorio asumir una actitud objetiva
y prepararse para el caso en que las cosas no salgan tan bien como se espere, con
el objetivo de realizar una planificacin realista. Para todo ello, ser indispensa-
ble respetar los tiempos de las tareas analizadas. La planificacin deber de ser
supervisada durante su desarrollo y corregida una vez realizada.
Riesgo 2: Herramientas de desarrollo no disponibles o funcionamiento/-

prestaciones indeseadas.
Para evitar problemas con las herramientas de desarrollo o con las prestaciones, el
proyecto no comenzar a desarrollarse hasta que las mismas no estn totalmente
disponibles. De esta manera, previamente se har un estudio lo ms adecuado y
preciso posible sobre las herramientas y prestaciones a utilizar, de manera que se
analice la viabilidad de cada una de las mismas.
Riesgo 3: La no correcta definicin de los requisitos y su redefinicin

conforme avanza el proyecto.
Para llevar a cabo una correcta definicin de los requisitos se utilizar una me-
todologa consistente en obtener la informacin sobre el dominio del problema en
primer lugar, preparar y realizar las sesiones de negociacin, identificar y revisar los
objetivos del sistema, identificar y revisar los requisitos de informacin, funcionales
y no funcionales y en ltimo lugar priorizar los objetivos y requisitos. As mismo,
todos los requisitos que se especifiquen debern ser documentados.
Riesgo 4: El personal necesita tiempo extra para aprender nuevas herra-

mientas.
Para evitar problemas del personal en cuanto al aprendizaje de las nuevas herra-
mientas, se ofrecern cursos de formacin en las mismas, a los cuales se deber
de asistir obligatoriamente para aprender y afianzar la manera de trabajar con las
herramientas a usar.
Riesgo 5: La falta de un seguimiento exacto del progreso hace que se

desconozca que el proyecto est retrasado hasta que est muy avanzado.
Para evitar este problema, se realizar un continuo seguimiento del progreso en cada
uno de los sprint para detectar a tiempo los signos de posibles retrasos. Para ello la
planificacin deber de ser supervisada y actualizada.
Riesgo 6: No es posible integrar los componentes desarrollados y es ne-

cesario redisear y repetir algunas tareas de programacin.
Para evitar problemas de integracin de componentes se invertir el suficiente tiem-
po en realizar el Diagrama de Descomposicin del Trabajo (WBS), y se planificar
y documentar la manera en la que se realizar la integracin de los diferentes com-
ponentes una vez hayan sido programados. As mismo, durante el desarrollo del
proyecto, se irn realizado diversas pruebas de integracin.
Riesgo 7: No es posible implementar la funcionalidad deseada en el len-

guaje de programacin.
Para evitar problemas sobre la imposibilidad de implementar ciertas funcionalida-
des en el lenguaje de programacin elegido, el estudio de viabilidad del sistema
realizado de manera previa deber de asegurar que no existan probabilidades de
que dicho problema pueda aparecer.
Riesgo 8: Se realiza un diseo simple y preliminar que no resuelve los

problemas que obligan ms tarde a redisear y volver a codificar.
Para evitar realizar un mal diseo, se invertir el suficiente tiempo en realizar el
mismo, y dicho tiempo ser tenido en cuenta en la planificacin temporal. Toda
la fase de diseo deber ser debidamente documentada y ser obligatorio el uso
de patrones de diseo que contribuyan al correcto funcionamiento de la aplicacin,
evitando tener que volver a redisear y codificar mdulos de la aplicacin.
2.6.2.2. Resolucin de riesgos
Riesgo 1: Planificacin muy optimista.

Una planificacin muy optimista puede llevar al proyecto a dos situaciones compa-
tibles: falta de tiempo y falta de recursos. En el caso de que se de esta situacin,
lo primero que se debe estudiar es por qu se llevo a cabo esta mala planificacin,
con el fin de documentar el error cometido y que ste no vuelva a ocurrir. Una vez
hallada la raz del problema lo siguiente ser rehacer la planificacin, intentando
arreglar en la medida de lo posible los retrasos causados sin volver a ser demasiado
optimista.
Riesgo 2: Herramientas de desarrollo no disponibles o funcionamiento /

prestaciones indeseadas.
En este caso lo primero que se har ser estudiar si el funcionamiento no deseado
es fruto de un error en la aplicacin o por el contrario es una caracterstica de su
funcionamiento. En el primero de los casos habr que ponerse en contacto con el
distribuidor con el fin denunciar la situacin.
Riesgo 3: La no correcta definicin de los requisitos y su redefinicin

conforme avanza el proyecto.
En el caso de la no correcta definicin de los requisitos, al igual que en los otros
casos, estudiaremos por qu ocurri esto para conseguir que no vuelva a ocurrir dicha
situacin. Una vez hecho esto, lo siguiente ser redefinir los requisitos y verificarlos
con el cliente, asegurando en la medida de lo posible que stos son correctos.
Riesgo 4: El personal necesita tiempo extra para aprender nuevas herra-

mientas.
El aprendizaje es un proceso difcilmente planificable, en el caso de que se produzca
esta situacin, se buscar una solucin factible. Una de estas podra ser modificar
el mtodo de aprendizaje.
Riesgo 5: La falta de un seguimiento exacto del progreso hace que se

desconozca que el proyecto est retrasado hasta que est muy avanzado.
Lo primero que se debe estudiar es por qu no se llevo a cabo un seguimiento exacto
del progreso para conseguir que no vuelva a ocurrir. Para evitar esta situacin se
irn anotando los progresos en el fichero Changelog.
Riesgo 6: No es posible integrar los componentes desarrollados y es ne-

cesario redisear y repetir algunas tareas de programacin.
Es difcil actuar contra este riesgo, en este caso lo nico que se puede hacer es
documentar la situacin para el futuro.
Riesgo 7: No es posible implementar la funcionalidad deseada en el len-

guaje de programacin.
Al igual que ocurra con el riesgo 6, en este caso no se puede hacer nada, solo
estudiar el origen del problema y documentarlo.
Riesgo 8: Se realiza un diseo simple y preliminar que no resuelve los

problemas que obligan ms tarde a redisear y volver a codificar.
De forma especial, en este riesgo es de vital importancia evitar que vuelva a ocurrir,
ya que los costes asociados a l son muy altos y puede ser evitable fcilmente.
Parte II
Desarrollo
39
41
En esta segunda parte de la memoria se describe el desarrollo del pro-

yecto siguiendo la metodologa anteriormente descrita. Va a estar es-
tructurada segn las etapas principales del proceso de ingeniera.
42
Captulo 3
Anlisis de requisitos
Una de las tareas ms importantes en el desarrollo de aplicaciones informticas es

la captura y documentacin de requisitos, ya que de una adecuada comprensin de los
requisitos del sistema depende en gran parte el xito del proyecto.
Para realizar la toma de requisitos de forma eficiente, he ido organizando reuniones

con una artista galerista, pudiendo de esta forma recopilar y definir todos los requisitos
que debe cumplir el sistema.
3.1. Catlogo de actores
Dentro del sistema he identificado los diferentes perfiles de usuarios (Figura 3.1) que
van a trabajar y utilizar la aplicacin:
El administrador, encargado de la gestin de la aplicacin en general, tendr

acceso a todas las funcionalidades del mdulo de administracin.
El visitante es el usuario que navega de forma annima por la web, tendr solo
acceso a visitar las obras contenidas en el catlogo sin poder realizar compras.
El cliente es el usuario, registrado e identificado por el sistema, que acceder a la

aplicacin para poder consultar el catlogo de productos y realizar sus compras.
Tambin vamos a tener un sistema externo:
La pasarela de pago, la cual es proporcionada por la entidad financiera a travs

de la que se efectuarn las transacciones bancarias para pagar los pedidos.
43
44 CAPTULO 3. ANLISIS DE REQUISITOS
Figura 3.1: Actores del sistema
3.2. Requisitos funcionales
Voy a describir la funcionalidad que ofrece el sistema mediante diagramas que per-
miten comprender un poco ms el funcionamiento del mismo. La realizacin de un buen
anlisis previo, aadir simplicidad durante el desarrollo y mejorar el rendimiento de la
aplicacin.
Para ello he utilizado UML (Lenguaje Unificado de Modelado), un lenguaje de

modelado utilizado en la Ingeniera del Software para especificar o describir mtodos o
procesos del sistema que se desea modelar.
3.2.1. Historias de usuario
A continuacin, para identificar los requisitos funcionales, defino las Historias de Usua-
rio1 que contiene cada uno de los Sprints de mi aplicacin:
Sprint 2 - Artistas. La Galera poseer informacin de cada uno de los Artistas.

Estos debern contener la siguiente informacin traducida: curriculum.
Aadir artista. El administrador de la Galera de Arte debe poder dar de

alta un nuevo artista a travs de un formulario, en el que rellenar sus datos.
1
Las Historias de Usuario se utilizan en la Metodologa gil para especificar los requisitos del sistema.
3.2. REQUISITOS FUNCIONALES 45
Introducir una imagen del artista. El administrador deber poder intro-

ducir una imagen del artista, la cual se mostrar a los clientes.
Editar artista. El administrador deber poder modificar los datos del artista
a travs de un formulario.
Eliminar artista. El administrador podr eliminar un artista de forma sen-
cilla.
Listar artistas. La interfaz del administrador necesita una pgina web que
tambin funcionar como una lista de todos los artistas que posee la Galera.
Ver artista. Cada artista deber tener una pgina que muestre toda su infor-
macin.
Sprint 3 - Colecciones La Galera poseer informacin de cada una de las Colec-

ciones de Arte que posea. Estas debern contener la siguiente informacin traducida:
nombre.
Aadir coleccin. El administrador debe ser capaz de dar de alta una nueva
coleccin a travs de un formulario, en el que rellenar todos los datos.
Editar coleccin. El administrador deber poder modificar los datos de la
coleccin a travs de un formulario.
Eliminar coleccin. El administrador podr eliminar una coleccin en cual-
quier momento de forma sencilla.
Listar colecciones. En la interfaz del administrador deber haber una pgina
web que tambin funcionar como una lista de todas las colecciones que posee
la Galera.
Ver coleccin. Cada coleccin deber tener una pgina que muestre toda su
informacin.
Sprint 4 - Obras. La Galera poseer informacin de cada una de las Obras de

Arte que posea en su inventario. Estas debern contener la siguiente informacin
traducida: titulo, comentario.
Aadir obra. El administrador de la galera debe ser capaz de aadir nuevas

obras en el inventario.
Introducir una imagen de la obra. El administrador deber poder intro-
ducir una imagen de la obra, la cual se mostrar a los clientes.
Editar obra. El administrador deber ser capaz de editar los datos de la obra
a travs de un formulario.
Eliminar obra. El administrador debe ser capaz de eliminar una obra de arte
del inventario de la Galera.
Ver obra de arte. Cada obra de arte deber tener una pgina en donde se
muestre toda su informacin.
Listar obras de arte. En la interfaz del administrador deber haber una

pgina web que tambin funcionar como una lista de todas las obras de arte
del inventario de la Galera.
Buscar obra de arte. El administrador deber poder buscar obras de arte a
travs de diferentes campos que debern actuar como filtros, obtenindose un
listado de todas las obras que coincidan con su bsqueda.
Sprint 5 - Secciones. La Galera de Arte clasificar sus obras en diferentes Sec-

ciones. Estas debern contener la siguiente informacin traducida: nombre.
Aadir seccin. El administrador debe ser capaz de dar de alta una nueva
seccin a travs de un formulario, en el que rellenar todos los datos.
Editar seccin. El administrador deber poder modificar los datos de las
seccin a travs de un formulario.
Eliminar seccin. El administrador podr eliminar una seccin en cualquier
momento de forma sencilla.
Listar secciones. En la interfaz del administrador deber haber una pgina
web que tambin funcionar como una lista de todas las secciones.
Ver seccin. Cada seccin deber tener una pgina que muestre toda su
informacin.
Sprint 6 - Tcnicas. Cada una de las Secciones posee una serie de Tcnicas con las
que se realizan las Obras de Arte. Estas debern contener la siguiente informacin
traducida: nombre.
Aadir tcnica. El administrador debe ser capaz de dar de alta una nueva
tcnica a travs de un formulario, en el que rellenar todos los datos.
Editar tcnica. El administrador deber poder modificar los datos de la
tcnica a travs de un formulario.
Eliminar tcnica. El administrador podr eliminar una tcnica en cualquier
momento de forma sencilla.
Listar tcnicas. En la interfaz del administrador deber haber una pgina
web que tambin funcionar como una lista de todas las tcnicas.
Ver tcnica. Cada tcnica deber tener una pgina que muestre toda su
informacin.
Sprint 7 - Catlogo. El Catlogo servir para que el usuario2 pueda consultar la

relacin de Obras que posee la Galera as como la ficha tcnica de cada una de ella
y de su artista.
Explorar catlogo de obras. La Galera necesita una pgina web donde el

usuario pueda ver todas las obras de arte que posee en su inventario, navegar
por ellas e incluirlas en su cesta de la compra.
2
Usuario: Visitante o Cliente
Ficha tcnica de la obra de arte. Se necesita que el usuario pueda consultar

toda la informacin posible de cada una de las obra de arte de la Galera.
Ficha tcnica del artista de la obra. El usuario deber poder acceder a
toda la informacin relacionada con el artista de la obra.
Obras ms recientes. El usuario deber tener la posibilidad, en el catlogo,
de obtener un listado con las obras ms recientes de la Galera.
Buscar obras de arte. El usuario deber tener la opcin de buscar obras de
arte a travs de diferentes campos que debern actuar como filtros, obtenin-
dose un listado de todas las obras que coincidan con su bsqueda.
Sprint 9 - Cesta de la Compra. En la Cesta de la Compra el cliente podr ir

aadiendo cada una de las Obras de Arte que desee comprar. En ella se visualizar
las Obras compradas, sus cantidades y el coste total de los productos.
Aadir a la cesta. El cliente deber poder aadir la obra de arte que desee
comprar en su cesta de la compra de forma fcil.
Sacar de la cesta. El cliente si se equivoca deber tener la posibilidad de
eliminar la obra de arte de su cesta de forma sencilla.
Vaciar la cesta. El cliente podr vaciar su cesta de la compra en cualquier
momento.
Sprint 10 - Etiquetado. El Etiquetado tendr dos fines para la Galera de Arte:
Poder tener las obras de arte clasificadas por categora de forma que el admi-
nistrador pueda acceder a dicha clasificacin.
Recomendar obras relacionadas cuando los usuarios estn navegando por la
ficha tcnica de una obra.
A continuacin detallo las Historias de Usuario de este Sprint.
Asignar etiquetas. El administrador deber poder asignar etiquetas a cada

una de las obras de arte del inventario de la Galera, introduciendo una lista
separadas por coma en el mismo formulario de la obra.
Editar etiquetas. El administrador podr editar las etiquetas a travs del
formulario de una obra existente.
Eliminar etiquetas. El administrador podrn eliminar etiquetas a travs del
formulario de una obra existente.
Listar etiquetas. El administrador podrn tener acceso al listado de todas
las etiquetas con las que se han clasificado las obras.
Mostrar etiquetas: En la ficha tcnica de una obra deber aparecer el con-
junto de etiquetas que esta posee, pudiendo el usuario seleccionar una etiqueta
para ver el listado de obras que tienen ese mismo etiquetado.
Recomendar obras: Mientras el usuario est observando la ficha tcnica de

una obra, el sistema debe ser capaz de recomendarle obras similares. Tam-
bin deber proporcionar enlaces a las diferentes obras y etiquetas que estn
relacionadas con la obra actual.
Sprint 11 - Seguridad. La Galera necesita que solo el usuario Administrador

sea el que pueda administrar la aplicacin evitando as algn que otro mal para la
empresa. Para realizar la compra los visitantes debern identificarse como clientes,
o registrarse si todava no tienen cuenta.
Iniciar sesin: La pgina de la Galera tendr una opcin para Iniciar Sesin,
la cual redirigir a una pgina de Inicio de Sesin donde el usuario deber
introducir su login y su clave para poder tener acceso. Una vez introducidos
los datos correctos se redirigir al catlogo donde podr ya navegar por la web
de la Galera. En caso de que los datos sean errneos se le mostrar un mensaje
de error.
Perdida de clave: Dentro de la pgina de Inicio de Sesin deber aparecer
una opcin para obtener una nueva contrasea en caso de prdida u olvido.
Haciendo clic sobre ella se le redirigir a una nueva pgina donde el usuario
indicar su correo electrnico y el sistema, automticamente, deber enviarle
un email con las instrucciones para restablecer su contrasea.
Registrarse: La pgina de la Galera tambin contar con una opcin para que
los usuarios puedan registrarse. Esta redirigir a una pgina donde el cliente
deber rellenar un formulario para poder darse de alta. Una vez rellenado y
validado, el sistema deber enviar un email de notificacin de registro al cliente
y a partir de ese momento ya podr utilizar la opcin Iniciar Sesin sin ningn
problema.
Cerrar sesin: La web tambin contar con esta opcin para que los clientes
puedan cerrar su sesin una vez finalicen.
Mi cuenta: El cliente registrado deber poder acceder a su informacin y
poder modificarla si fuera necesario.
Listar usuarios: El administrador podr ver un listado de los usuarios regis-
trados.
Sprint 12 - Facturacin. La Galera desea tener un sistema de procesamiento

para los pedidos de sus clientes a travs de una pasarela de pago. Tambin ofrecer
a sus clientes la opcin de pagar a travs de una transferencia bancaria o ingreso
en efectivo.
Facturar: Una vez que el cliente haya aadido a su cesta las obras de arte que
desea comprar, deber poder proceder a la facturacin.
Se le redirigir a una pgina donde deber introducir su informacin de contac-
to, la informacin para la facturacin y la informacin de su tarjeta de crdito
en caso de que desee pagar por este mtodo. Una vez rellenado el formulario
y antes de realizar el pedido, se le deber mostrar al usuario la informacin
introducida para que la verifique. En este momento se inicia el flujo de traba-

jo de procesamiento de pedidos que implica facturar al cliente y envo de las
obras de arte.
El sistema, inmediatamente, deber enviar un correo electrnico:
a la Galera de Arte, indicndole que existe una nueva solicitud de pedido
al cliente como confirmacin del pedido que ha realizado.
Este deber contener la informacin del pedido, la informacin de contacto y
la direccin de envo.
Ver los pedidos: El administrador deber ser capaz de ver el estado en el que
se encuentran todos los pedidos (procesado, cerrado, fracasado). Los pedidos
procesados son los que han sido facturados a los clientes pero no se han enviado
todava. Una vez hayan sido enviados debern aparecer como cerrados.
Ver informacin de un pedido: El administrador debe poder ver la informa-
cin de un pedido en cualquier momento, donde se le mostrar la informacin
del cliente y los detalles del pedido.
Cerrar pedido: Una vez que la Galera de Arte haya enviado el pedido al
cliente, el administrador deber poder cerrar el pedido a travs de un botn
en la pgina que muestra la informacin del pedido.
Sprint 13 - Internacionalizacin. La Galera desea que su pgina pueda verse

tanto en espaol como en ingls, para as poder acaparar una mayor clientela.
Cambiar la configuracin regional: El cliente debe ser capaz de cambiar

la configuracin regional a travs de un vnculo en el sitio web de la Galera.
Agregar traduccin: El administrador debe ser capaz de aadir una nueva
traduccin para los artistas, colecciones, obras, secciones y tcnicas.
Editar traduccin: El administrador debe ser capaz de modificar el texto
traducido.
Eliminar traduccin: El administrador debe ser capaz de eliminar el texto
traducido.
Sprint 14 - Inicio. La Galera desea tener una pgina de inicio donde se muestren
las nuevas obras adquiridas.
Sprint 15 - Contactar. La Galera desea tener una pgina desde la que el usuario
pueda obtener la informacin de contacto y la localizacin de la Galera.
Sprint 16 - Usuarios. La Galera poseer informacin de cada uno de los Usuarios

que se registre en su web.
Editar usuario. El administrador deber ser capaz de editar los datos del
usuario a travs de un formulario.
Eliminar usuario. El administrador debe ser capaz de eliminar una usuario
de la galera.
Listar usuarios. En la interfaz del administrador deber haber una pgina

web que tambin funcionar como una lista de todas los usuarios registrados
en la galera.
Ver usuario. Cada usuario deber tener una pgina en donde se muestre toda
su informacin.
Sprint 17 - Quienes somos. Mediante este pgina el usuario deber poder acceder
a la descripcin de la actividad de la galera.
Editar Quienes somos. El administrador deber ser capaz de editar el apar-

tado de Quienes somos a travs de un formulario.
Ver Quienes somos. Existir una pgina en donde se muestre la actividad
de la galera.
Sprint 18 - Condiciones. Mediante este men el usuario deber poder acceder a

las condiciones generales de la galera.
Aadir condicin. El administrador debe ser capaz de aadir nuevas condi-

ciones.
Editar condicin. El administrador deber ser capaz de editar los datos de
la condicin a travs de un formulario.
Eliminar condicin. El administrador debe ser capaz de eliminar una con-
dicin.
Listar condiciones. En la interfaz del administrador deber haber una pgina
web que tambin funcionar como una lista de todas las condiciones generales
de la galera.
Ver condicin.
Interfaz del administrador: Cada condicin deber tener una pgina en
donde se muestre su informacin.
Interfaz del usuario: Existir una pgina en la que se le mostrar al usuario
todas las condiciones.
Sprint 19 - Panel Administracin. La Galera necesita una pgina desde la que

el administrador pueda acceder a la administracin de la web.
En la Figura 4.26 podemos ver el Diagrama del Sistema donde se definen cada
uno de los subsistemas (Sprint) que lo componen:
Figura 3.2: Diagrama del Sistema
3.2.2. Modelado de casos de uso
En Ingeniera del Software, un Caso de Uso es una tcnica para la captura de requisitos
potenciales de un nuevo sistema. Cada uno proporciona uno o ms escenarios que indican
cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un
objetivo especfico.
En esta seccin mostrar el estudio mediante Casos de Uso de la aplicacin, donde se

mostrarn las funcionalidades y los comportamientos del sistema mediante su interaccin
con algn agente externo3 .
3.2.2.1. Diagrama de casos de uso
A continuacin se muestra el modelo inicial de Casos de Uso del sistema para cada
uno de los Sprint, utilizando para ello notacin UML.
3
Interaccin con algn agente externo: Desde una peticin de un actor o bien desde la invocacin
desde otro caso de uso.
Figura 3.3: Diagrama de CU de Gestin de Artistas
Figura 3.4: Diagrama de CU de Gestin de Colecciones

Figura 3.5: Diagrama de CU de Gestin de Obras
Figura 3.6: Diagrama de CU de Gestin de Secciones

Figura 3.7: Diagrama de CU de Gestin de Tcnicas
Figura 3.8: Diagrama de CU de Gestin de Catlogo
Figura 3.9: Diagrama de CU de Gestin de Cesta de la Compra

Figura 3.10: Diagrama de CU de Gestin de Etiquetas
Figura 3.11: Diagrama de CU de Gestin de Seguridad
Figura 3.12: Diagrama de CU de Gestin de Quienes somos

Figura 3.13: Diagrama de CU de Gestin de Facturacin
Figura 3.14: Diagrama de CU de Gestin de Internacionalizacin
Figura 3.15: Diagrama de CU de Gestin de Usuarios

Figura 3.16: Diagrama de CU de Gestin de Condiciones
3.2.2.2. Descripcin de casos de uso
En esta seccin se describen los diferentes Casos de Uso del sistema para cada uno de
los Sprint.
Gestin de Artistas
Figura 3.17: Descripcin del CU Aadir Artista

Figura 3.18: Descripcin del CU Editar Artista
Figura 3.19: Descripcin del CU Eliminar Artista

Figura 3.20: Descripcin del CU Listar Artistas
Figura 3.21: Descripcin del CU Ver Artista
Figura 3.22: Descripcin del CU Introducir imagen del Artista

Las descripciones para los CU de Gestin de Colecciones, Gestin de Obras, Gestin

de Secciones, Gestin de Tcnicas, Gestin de Usuarios, Gestin de Quienes somos y
Gestin de Condiciones son similares a la Gestin de Artistas.
Gestin de Catlogo
Figura 3.23: Descripcin del CU Buscar Obras
Figura 3.24: Descripcin del CU Explorar catlogo de Obras

Figura 3.25: Descripcin del CU Ficha tcnica de la Obra
Figura 3.26: Descripcin del CU Ficha tcnica del artista
Figura 3.27: Descripcin del CU Obras ms recientes

Gestin de Cesta de la Compra
Figura 3.28: Descripcin del CU Aadir a la Cesta
Figura 3.29: Descripcin del CU Eliminar de la Cesta

Figura 3.30: Descripcin del CU Vaciar la Cesta
Gestin de Etiquetas
Figura 3.31: Descripcin del CU Asignar Etiquetas

Figura 3.32: Descripcin del CU Editar Etiquetas
Figura 3.33: Descripcin del CU Eliminar Etiquetas

Figura 3.34: Descripcin del CU Listar Etiquetas
Figura 3.35: Descripcin del CU Mostrar Etiquetas

Figura 3.36: Descripcin del CU Recomendar Obras
Gestin de Seguridad
Figura 3.37: Descripcin del CU Iniciar Sesin

Figura 3.38: Descripcin del CU Prdida de Clave
Figura 3.39: Descripcin del CU Mi Cuenta

Figura 3.40: Descripcin del CU Cerrar Sesin
Figura 3.41: Descripcin del CU Registrarse

Figura 3.42: Descripcin del CU Listar Usuarios
Gestin de Facturacin
Figura 3.43: Descripcin del CU Facturar

Figura 3.44: Descripcin del CU Ver los Pedidos
Figura 3.45: Descripcin del CU Ver informacin de un Pedido

Figura 3.46: Descripcin del CU Cerrar Pedido
Gestin de Internacionalizacin
Figura 3.47: Descripcin del CU Cambiar la configuracin regional

Figura 3.48: Descripcin del CU Agregar traduccin
Figura 3.49: Descripcin del CU Editar traduccin

3.3. REQUISITOS DE INFORMACIN 73
Figura 3.50: Descripcin del CU Eliminar traduccin
3.3. Requisitos de Informacin
stos especifican la informacin que debe almacenar el sistema para cumplir con los
objetivos.
Los requisitos de informacin del sistema son:
Figura 3.51: Requisito de informacin sobre artistas

Figura 3.52: Requisito de informacin sobre colecciones
Figura 3.53: Requisito de informacin sobre obras
Figura 3.54: Requisito de informacin sobre secciones

Figura 3.55: Requisito de informacin sobre tcnicas
Figura 3.56: Requisito de informacin sobre cesta de la compra
Figura 3.57: Requisito de informacin sobre etiquetas

Figura 3.58: Requisito de informacin sobre pedidos
Figura 3.59: Requisito de informacin sobre usuarios

Figura 3.60: Requisito de informacin sobre quienes somos
Figura 3.61: Requisito de informacin sobre condiciones
Modelado conceptual de datos
El modelo conceptual de datos se obtiene a partir de la especificacin de requeri-

mientos. ste est orientado a representar los elementos que intervienen en el sistema y
sus relaciones.
Comenzar describiendo cada uno de los objetos que van a formar parte de l y
finalizar representado este modelo mediante el Diagrama E/R.
Tipos de entidades
Las entidades representan cada uno de los elementos contenidos en el modelo concep-
tual de datos.
Entidad Descripcin
admin_artista Artistas de la Galera.
admin_coleccions Colecciones de las obras.
admin_obras Obras de arte.
admin_seccions Secciones en que se dividen las obras de arte.
admin_tecnicas Tcnicas empleadas para realizar las obras.
carritos Cesta de la compra.
carrito_items Cada una de las obras insertadas en la cesta de la compra.
tags Etiquetas para clasificar las obras.
users Usuarios de la aplicacin.
user_sessions Sesiones de usuarios.
pedidos Pedidos realizados por los usuarios.
pedido_items Cada una de las obras que forman el pedido.
admin_nosotros Informacin sobre la actividad de la Galera.
admin_condiciones Condiciones generales.
Tabla 3.1: Entidades del sistema
Tipos de relaciones
La tabla 3.2 recoge las relaciones establecidas entre las distintas entidades del modelo
conceptual de datos.
Diagrama Entidad/Relacin
El diagrama o modelo Entidad/Relacin es una herramienta para el modelado de datos

de un sistema de informacin.
El diagrama E/R, mostrado en la Figura 3.62, representa el modelo de datos imple-

mentado en mi proyecto. En l se determinan las entidades, sus atributos y las relaciones
existentes.
Diagrama conceptual de clases
El diagrama de clases es el diagrama principal para el anlisis y el diseo. Este describe

grficamente la estructura de un sistema mostrando sus clases, atributos y las relaciones
existentes entre ellos. En la figura 3.63 se puede observar el diagrama de clases, diseado
con UML, para la aplicacin:
Relacin Descripcin Entidades

Asocia al artista con la obra.
Crea Un artista puede crear varias obras. admin_artista [1:N]
Una obra pertenece a un nico artista. admin_obras [1:1]
Asocia la coleccin con la obra.
Formada_por Es posible que exista obra que no tengan coleccin. admin_obras [0:1]
Una coleccin puede tener varias obras. admin_coleccions [1:N]
Asocia la seccin con la obra.
Contiene A una seccin pueden pertenecer varias obras. admin_seccions [1:N]
Una obra solo pertenece a una nica seccin. admin_obras [1:1]
Asocia la tcnica con la obra.
Posee Una tcnica puede pertenecer a varias obras. admin_seccions [1:N]
La obra se realiza con una nica tcnica. admin_obras [1:1]
Asocia la seccin con la tcnica.
Incluye Una seccin se compone de varias tcnicas. admin_seccions [1:N]
Una tcnica solo pertenece a una nica seccin. admin_tecnicas [1:1]
Asocia la etiqueta con la obra.
Clasifica Una etiqueta puede pertenecer a varias obras. tags [1:N]
Una obra puede no tener etiquetas. admin_obras [0:N]
Asocia la lnea del pedido con la obra.
Introduce Una lnea de pedidos slo pertenece a una obra. pedido_items [1:1]
Una obra puede tener varias lneas de pedidos. admin_obras [1:N]
Asocia la lnea del pedido con el pedido.
Consta Un pedido puede contener varias lneas de pedido. pedido_items [1:1]
Una lnea de pedidos slo pertenece a un pedido. pedidos [1:N]
Asocia la lnea del carrito con la obra.
Introduce Una lnea de carrito pertenece a una nica obra. carrito_items [1:1]
Una obra puede existir en varias lneas de pedido. admin_obras [1:N]
Asocia la lnea del carrito con el carrito.
Consta Una lnea de pedidos pertenece a un nico carrito. carrito_items [1:1]
Un carrito puede contener varias lneas de pedido. carritos [1:N]
Asocia el carrito con el pedido.
Genera Un carrito solo puede generar un pedido. carritos [1:1]
Un pedido solo puede ser generado por un carrito. pedidos [1:1]
Asocia el pedido con el usuario.
Realiza Es posible que no exista pedidos para un usuario. pedidos [1:1]
Un pedido solo puede ser realizado por un usuario. users [0:N]
Asocia el usuario con la sesin de usuario.
Tiene Un usuario solo puede tener una sesin. users [1:1]
Una sesin solo pertenece a un usuario. user_sessions [1:1]
Asocia el usuario con las condiciones.
Redacta Un usuario puede redactar varias condiciones. users [0:N]
Condicin solo puede ser redactada por un usuario. admin_condiciones [1:1]
Asocia el usuario con nosotros.
Escribe Un usuario solo puede escribir un nosotros. users [1:1]
Un nosotros solo puede ser escrito por un usuario. admin_nosotros [1:1]
Tabla 3.2: Relaciones del sistema

80
CAPTULO 3. ANLISIS DE REQUISITOS
Figura 3.62: Diagrama Entidad/Relacin
3.3. REQUISITOS DE INFORMACIN
Figura 3.63: Diagrama conceptual de clases UML
81
3.4. Requisitos no funcionales
Esta seccin contiene los requisitos detallados del sistema.
3.4.1. Requisitos de interfaz externa
A continuacin se van analizar cada uno de los requisitos relativos a las entradas y
salidas del software.
3.4.1.1. Interfaces de usuarios
El sitio web deber:
tener una estructura clara, ordenando el contenido y las funciones de la aplicacin

en pestaas o apartados que abarquen todas las funcionalidades disponibles, segn
el perfil de seguridad del usuario conectado.
posibilitar la visualizacin de cualquier tipo de contenido multimedia (texto, grfi-

cos, videos, etc.) en consonancia con la imagen corporativa de la empresa.
3.4.1.2. Interfaces con el hardware
Los usuarios debern disponer de un ordenador que posea una tarjeta de red o una
tarjeta de red inalmbrica y un punto de acceso que les permita una conexin a Internet
para poder acceder a la aplicacin.
3.4.1.3. Interfaces con el software
Los usuarios necesitarn la utilizacin de un navegador web para que la aplicacin pue-
da ser visualizada, no siendo necesario el uso de uno especfico debido a que la aplicacin
estar adaptada para poder ser visualizada en la mayora de los navegadores disponibles.
3.4.1.4. Interfaces de comunicaciones
La comunicacin entre el cliente y el servidor, consiste en una comunicacin de peticin

y respuesta. Estas se efectuarn con el protocolo HTTP y sern enviadas del cliente/ser-
vidor o del servidor/cliente con el protocolo TCP/IP.
3.4. REQUISITOS NO FUNCIONALES 83
3.4.2. Requisitos de seguridad
Los datos de la aplicacin solo podrn ser modificados por aquellas personas autori-
zadas para ello.
3.4.3. Requisitos de eficiencia
3.4.3.1. Requisitos de espacio
La aplicacin se alojar en un servidor contratado en Internet por lo que se debe tener

en cuenta el espacio contratado, ya que un catalogo de productos con sus respectivas fotos
puede requerir un espacio en el disco de tamao importante.
3.4.3.2. Requisitos de rendimiento
Las respuestas a las peticiones de los usuarios externos se deber generar en un tiempo
razonable.
3.4.4. Restricciones del diseo
El diseo de la aplicacin debe estar orientado hacia la facilidad de uso y a una rpida
localizacin de las opciones, para que pueda ser accesible a cualquier usuario.
3.4.5. Restricciones de base de datos
Ser necesaria la utilizacin de una base de datos para poder almacenar toda la in-
formacin necesaria para el correcto funcionamiento de la aplicacin. He optado por
almacenar la misma en MySql.
3.4.6. Atributos de sistema de software

Fiabilidad. El sistema debe ser fiable en cuanto a los datos que ofrece a los usuarios
clientes/visitantes como a la informacin de configuracin que muestra al usuario
administrador.
Integridad. Para salvaguardar la integridad de los datos, he optado por almacenar los
mismos en una base de datos subyacente en un SGBD. Estos sistemas ofrecen meca-
nismos y herramientas de control de la integridad sin necesidad de una supervisin
por parte del usuario.
Mantenimiento. El mantenimiento ser llevado a cabo por el Administrador del Siste-

ma, a quien se le facilita un mdulo de administracin para realizar todas las tareas
necesarias.
3.5. Reglas de negocio
Como ya mencion en la seccin 3.1, los perfiles de usuario de la aplicacin sern tres:
administrador, usuario registrado (cliente) y usuario visitante.
El administrador tendr acceso a todas las funcionalidades del mdulo de adminis-

tracin, pudiendo desempear adems el papel de usuario registrado normal.
El usuario registrado tendr acceso a un men de operaciones que no incluya labores

de administracin, pudiendo realizar compras.
El usuario visitante tendr acceso a un men de operaciones que no incluya labores

de administracin, pudiendo visitar las obras contenidas en el catlogo sin poder
realizar su compra.
3.6. Estudio de alternativas tecnolgicas
Para la eleccin del lenguaje he realizado un anlisis de la relevancia de los principales

lenguajes de programacin y una vez seleccionado, he efectuado una comparativa con los
distintos framework que lo utilizan.
3.6.1. Lenguajes
Determinar el lenguaje de programacin, que se ajusta mejor a las necesidades es-

pecficas del proyecto, es un aspecto importante cuando se va a realizar una aplicacin
Web.
Hoy en da podemos encontrarnos una gran variedad de lenguajes de programacin

y determinar cul es el ms adecuado puede resultar complicado. Por esta razn, para
realizar la seleccin, sera bueno tener en cuenta una serie de factores.
Para comenzar descartar todos los lenguajes que su desarrollo requieran el pago de
cualquier licencia.
3.6. ESTUDIO DE ALTERNATIVAS TECNOLGICAS 85
Tendremos en cuenta varios factores a la hora de aprender un nuevo lenguaje de

programacin:
la eficiencia,
la facilidad de escribir,
la alta calidad y
que sea bastante productivo.
Ya que actualmente existen muchos lenguajes de programacin con sus ventajas y

desventajas, voy a realizar un anlisis de la importancia de los principales lenguajes
de programacin dentro de la industria del software y as, podr determinar cual es el
que aporta mejores prestaciones. Para ello ejecutar consultas a mltiples servicios que
cuentan con un gran trfico de usuarios.
3.6.1.1. Anlisis
He evaluado para el estudio, a travs de la web Programming Language Popu-

larity [Welton, David N.], servicios como Freshmeat [Geeknet], Ohloh [Software], Google
Code [Google], Delicious [AVOS], Craigslist [CraigsList], Indeed [Indeed] y Yahoo Search
[Yahoo]. De los resultados obtenidos he realizado una valoracin global y para finalizar
he estudiado la tendencia de la programacin.
Freshmeat, Ohloh y Google Code
Son sitios web de referencia dentro de la comunidad de desarrolladores Open Source.
Google Code y Freshmeat son servicios web donde se almacenan todo tipo de proyectos
Open Source. Sus anlisis podemos observarlos en las Figuras 3.64 y 3.65.
Ohloh es un directorio pblico de Open Source y personas que lo desarrollan y/o usan.
Se centra en un anlisis de los proyectos que tiene enlazado.
Gracias a los datos que obtiene de los repositorios oficiales de los proyectos puede
realizar diferentes informes sobre el uso del lenguaje de programacin, el sistema de
control de versiones o incluso comparar varios proyectos. Podemos ver su anlisis en la
Figura 3.66.
Figura 3.64: ndices de aceptacin de lenguajes de programacin - Google Code
Figura 3.65: ndices de aceptacin de lenguajes de programacin - Freshmeat

Figura 3.66: ndices de aceptacin de lenguajes de programacin - Ohloh
La eleccin del lenguaje vendr determinada por las preferencias del programador
y, aunque estas estadsticas no son significativas de las necesidades en la industria del
software, si nos indican las preferencias de los programadores en el uso de un lenguaje.
Delicious
Es un servicio de gestin de marcadores sociales en web. Permite agregar los marca-

dores y categorizarlos con un sistema de etiquetado. Delicious permite almacenar sitios
webs y compartir los marcadores con el resto de sus usuarios.
Para estudiar los intereses de una comunidad de millones de usuarios, he realizado un

anlisis del nmero de referencias a los marcadores referidos a los lenguajes de programa-
cin, obtenindose los resultados en la Figura 3.67.
Craigslist, Indeed
Para obtener las prestaciones y el grado de productividad de un lenguaje, hay que

estudiar el nivel de aceptacin que tiene en la industria del software. Esto queda reflejado
en el nmero de ofertas de empleo que demandan programadores con conocimientos de
un lenguaje especfico. Para ello he evaluado dos sitios web.
Figura 3.67: ndices de aceptacin de lenguajes de programacin - Delicious
Figura 3.68: ndices de aceptacin de lenguajes de programacin - Craigslist

En la figura 3.68 podemos observar el nmero de ofertas de trabajo actuales obtenidas

del sitio web Craigslist.
En el sitio web Indeed.com he realizado un anlisis de las tendencias de la demanda

de programadores con conocimientos especficos de un lenguaje de programacin.
Figura 3.69: ndices de aceptacin de lenguajes de programacin - Indeed
La primera estadstica que podemos observar en la Figura 3.69, presenta la tendencia

relativa de crecimiento, donde se puede comprobar cmo en los ltimos aos la demanda
se ha mantenido estable, con la distincin de un crecimiento considerable de la necesidad
de programadores Ruby.
Este crecimiento de Ruby, se puede considerar normal ya que es un lenguaje joven

que est teniendo una gran aceptacin.
En la segunda grfica que se muestra en la Figura 3.70, se puede ver la tendencia de la

demanda en valores absolutos de los diferentes lenguajes. Se puede comprobar que Java es
Figura 3.71: ndices de aceptacin de lenguajes de programacin - Yahoo search
el lenguaje ms demandado en el mercado en los ltimos aos. Esto, junto con los datos
obtenidos anteriormente del estudio, nos indican que Java es el lenguaje de desarrollo por
el que se decanta la comunidad de programadores.
Yahoo Search
Es un motor de bsqueda de pginas web. Si realizamos una bsqueda genrica por

language programming se obtiene una clasificacin con el nmero de referencias que hay
de cada lenguaje en Internet. Podemos verlo en la Figura 3.71.
Conclusin
Tomando como referencia la tendencia de ofertas de trabajo absolutas (Figura 3.68 de

la pgina 88) y agrupando las estadsticas presentadas por las diferentes Webs analizadas,
se obtiene la conclusin de que los lenguajes de programacin ms populares son Java,
PHP [Gmez Lpez, Rubn] y C/C++. Ello podemos observarlo en la Figura 3.72.
C/C++ se pueden considerar lenguajes de programacin de ms bajo nivel que Java,

lo que aporta gran versatilidad y rendimiento a sus aplicaciones. La dependencia que a
veces tienen sus libreras del sistema operativo, la escasez de frameworks de desarrollo
web que existen y su complejo sistema de conexin a bases de datos, descartan estos
lenguajes a la hora de desarrollar aplicaciones Web.
Figura 3.72: ndices de aceptacin de lenguajes de programacin - Global
Java tiene un manejo muy bueno de conexiones a base de datos, la portabilidad entre
sistemas operativos es muy buena ya que ejecuta el cdigo Java en su propia maquina
virtual, no hacindola dependiente de libreras propias de un sistema operativo y tiene
una serie de frameworks de desarrollo de aplicaciones Web que hacen que este lenguaje
sea altamente productivo a la hora de desarrollar aplicaciones Web.
PHP es uno de los lenguajes mas populares en el desarrollo de aplicaciones web.

Quizs una de las ventajas frente a Java sea en cuestin de rendimiento ya que PHP
es mucho menos pesado, lo que produce una sensacin al usuario de rapidez y mayor
usabilidad. El coste estimado en estos proyectos ser menor, ya que la programacin de
un sistema PHP es mucho ms directa con resultados inmediatos.
Siempre existen diferentes variables que nos influyen a la hora de tomar una decisin
y que se deben sopesar para encontrar un equilibrio entre lo que la tecnologa nos ofrece y
lo que necesitamos nosotros de ella. Pero las variables ms importantes a tener en cuenta
sern el propsito de la aplicacin web y sus dimensiones.
Veamos en la Grfica 3.73, a modo estimativo, la comparacin entre ambas tecnologas.
3.6.1.2. Ruby como lenguaje para mi proyecto
Uno de mis objetivos, en este proyecto, es el poder adquirir nuevos conocimientos en

lenguajes de programacin orientados a la web. Dado que durante la carrera he tenido la
oportunidad de aprender algunos de los lenguajes anteriormente mencionados como ms
Figura 3.73: Comparativa PHP - Java
populares, C/C++ (orientado a objetos), y que tengo algunas nociones sobre Java de un
curso que realic hace ya algunos aos, me he decidido por aprender un nuevo lenguaje
Ruby (ver anexo D), ya que parece ser bastante interesante y presenta una nueva forma
de programar diferente a las estudiadas durante la carrera.
3.6.2. Entorno de desarrollo Web
Se puede decir que un Entorno de Trabajo Web, en ingls Framework, es un con-

junto de aplicaciones, utilidades de soporte y cdigo que simplifican las tareas de los
programadores, nos facilitan una infraestructura que nos ahorra muchas horas delante
del ordenador.
Estos pueden ser una herramienta muy til, cuando tenemos mucho trabajo, para
ahorrarnos tiempo y ayudarnos a ser ms eficientes en nuestro da a da, aunque por
supuesto, podemos decidir desarrollar todo el cdigo.
Estos persiguen los siguientes objetivos:
acelerar el proceso de desarrollo,

reutilizar cdigo ya existente y
promover buenas prcticas de desarrollo, como el uso de patrones.
Utilizando un framework para el desarrollo del proyecto conseguimos algunas ventajas

como:
El programador no necesita plantearse una estructura global de la aplicacin,

sino que el framework le proporciona un esqueleto que hay que rellenar.
Mayor velocidad a la hora de realizar los desarrollos, ya que en muchas ocasiones

ofrecen funcionalidades definidas que nos facilitan el trabajo.
Facilita la colaboracin. Cualquiera que haya tenido que pelearse con el cdigo
fuente de otro programador o incluso, con el suyo mismo pasado algn tiempo,
sabr lo difcil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y
estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.
Es ms fcil encontrar herramientas (utilidades, libreras) adaptadas al framework

concreto para facilitar el desarrollo.
Cdigo optimizado, ya que por norma se encuentra un grupo de personas tra-

bajando sobre el mismo que intentan que el cdigo sea lo ms limpio y eficiente
posible.
Reduccin de costos, ya que al mejorar la velocidad de desarrollo y obtener un

cdigo mucho mejor, los costes de desarrollo tambin se reducen.
La utilizacin de un framework en el desarrollo de una aplicacin implica un cier-

to coste inicial de aprendizaje, aunque a largo plazo es probable que facilite tanto el
desarrollo como el mantenimiento.
Actualmente se pueden encontrar una gran variedad de Entornos de Desarrollo Web

que estn basados en Ruby, y determinar cul es el ms adecuado para el presente proyecto
puede resultar complicado. Por ello se debe tener en cuenta una serie de factores para
garantizar una correcta valoracin de las prestaciones ofrecidas por cada uno ellos.
Tal y como ya mencion anteriormente en la Seccin 3.6.1.2 Ruby como lenguaje para
mi proyecto de la pgina 91, uno de los objetivos del presente proyecto es el adquirir y
reforzar nuevos conocimientos acerca de la programacin de aplicaciones Web. Es por lo
debo tener en cuenta en la eleccin que, aparte de que facilite las tareas repetitivas, me
ayude a programar siguiendo las buenas prcticas de programacin.
La filosofa de diseo MVC (Modelo-Vista-Controlador) es una de estas buenas prac-

ticas. Este patrn de diseo (descrito en la Seccin 4.1.2 Arquitectura del sistema de la
pgina 104) se emplea para separar, en la interfaz de usuario, la lgica de negocio de la
representacin de la informacin. Al seguir este patrn se incrementa la flexibilidad y la
reutilizacin al facilitar la modificacin de la lgica de negocio o de la interfaz de usuario,
sin que una afecte a la otra.
Dentro de este patrn se debe diferenciar entre dos arquitecturas:
Arquitectura Push-based. Se conoce tambin como server push, caracterizndose

en que la peticin para que se sirva una determinada informacin se produce en el
servidor, implicando que este se encarga de inyectar los contenidos hacia el cliente,
sin que se produzca la peticin previa.
Arquitectura Pull-based. Las peticiones de informacin se originan en el lado del

cliente y el servidor solo se debe encargar de enviar la respuesta a estas peticiones.
A continuacin podemos ver una comparativa de los entornos de desarrollo web de

Ruby en la siguiente tabla:
Tabla 3.3: Comparativa de entornos de desarrollo Web - Ruby
En la seccin 3.7 Anlisis GAP tratar sobre las caractersticas mostradas en la tabla
anterior.
3.6.2.1. Rails como framework para mi proyecto
Como entorno de desarrollo web para mi proyecto he seleccionado Ruby on Rails

(ver anexo G), tambin conocido como RoR.
Los motivos de esta decisin son:
En la actualidad Ruby on Rails es el Framework ms completo de todos los analiza-

dos anteriormente, lo que lo convierte en una herramienta de grandes prestaciones,
tanto en productividad, flexibilidad y facilidad de mantenimiento.
RoR, dentro de la comunidad de programadores de Ruby, es el Framework ms

popular aportando un apoyo absoluto por parte de desarrolladores, teniendo un
efecto en un crecimiento exponencial de la comunidad Rails (Foros, Lista de correos,
Screencast, Blogs, Libros, Documentacin online, etc. . . )
Si estudiamos la demanda de la industria del software (Figura 3.74) podemos ver

como el sector apuesta fuerte por este entorno. Estas circunstancias eligen a Ruby
on Rails como un entorno de desarrollo con grandes perspectivas de futuro dentro
del panorama de aplicaciones Web.
Figura 3.74: Tendencia del crecimiento de la demanda de Rails - Indeed.com
3.6.2.2. Otros frameworks
Tambin he querido analizar algunos de los frameworks ms utilizados en comercio

electrnico B2C. Aunque es difcil compararlos con Rails ya que se basan en un lenguaje
diferente: PHP.
Cabe destacar Oscommerce, Magento y Prestashop como las mejores aplicaciones

opensource, libres y gratuitas.
Oscommerce
Este gestor de tiendas apareci en Marzo del ao 2000 y posiblemente haya sido el
mejor gestor para tiendas online, ahora bien, a da de hoy, se ha quedado atrs y ms
viendo lo fuerte que vienen sus competidores. Hay que destacar su estabilidad y potencia,
en cambio tiene en contra su diseo con tablas, que en los aos en los que nos encontramos
no podemos permitir seguir usando maquetacin sin CSS.
Actualmente est la versin 3 que apareci corrigiendo grandes problemas que tena
con los logins, dispone de un cdigo obsoleto que puede traer de cabeza a ms de uno
debido al gran nmero de agujeros que presenta. . . , tambin separaron lo que es cdigo
del diseo, pero an con estas mejoras sigue existiendo una huida masiva de este sistema
hacia otras plataformas como son Prestashop y Magento.
Dado que Oscommerce est desactualizado y descontinuado, no creo que sea una buena
opcin para desarrollar mi proyecto.
A destacar:
Permite integrar varios idiomas.
Gran comunidad de desarrolladores, en 2011 la mayor comunidad en espaol desa-

parece.
Gran cantidad de mdulos desarrollados por lo que se abaratan costes.
Gestin de multitud mdulos de pago.
Gestin de envos, ya sean por zonas, tramos de pesos, etc. . . .
Desarrollar en Oscommerce es ms econmico, es ms sencillo.
Instalacin muy sencilla.
En contra:
La instalacin inicial es muy bsica, requieren de muchos mdulos para comenzar

a parecerse a una tienda.
Apenas usa CSS por lo que todos los cambios de bloques hay que realizarlos ma-
nualmente.
Proyecto estancado.
Muy laboriosos, cualquier pequea modificacin requiere grandes conocimientos de

PHP.
No son accesibles (mapas del sitio, url amigables, meta-tags, ttulos dinmicos,etc. . . )
por parte de los buscadores si no implantamos un gran nmero de mdulos.
Con el cierre del foro en espaol de Oscomerce, desaparece la mayor ayuda que
exista de este software en Espaol.
Muchsimos bugs/errores en seguridad.
Prestashop
Este es uno de los gestores ms nuevos, muy buena indexacin, Ajax totalmente
integrado, lo que le da un aspecto muy actual, y por supuesto funciona con CSS. Resulta
muy fcil cambiarle el aspecto y personalizarlo.
El proyecto se cre en Francia, pero dispone de soporte en ingls, y por supuesto en

espaol, aunque la comunidad espaola no es tan grande, sigue creciendo a buena marcha.
La aplicacin pesa muy poco y se instala con una facilidad sorprendente, en pocos minutos
se tiene la tienda funcionando.
Llama la atencin lo completo que es el panel de administracin, la facilidad y lo intui-

tivo que son todos los paneles, los clientes lo agradecern. Sobre todo cuando comprueben
la facilidad con la que podrn gestionar toda la tienda, crear categoras, productos, fa-
bricantes, controlar a los clientes, etc. . .
Es una aplicacin modular por lo que nos permitir ir aadiendo funcionalidades sin
apenas tener que modificar el core de la aplicacin.
Sin lugar a dudas en estos momentos parece ser el rey del comercio electrnico, empez
despacio pero disponer de una tienda realizada en Prestashop [Global] es garantizarse un
buen desarrollo.
A destacar:
Permite integrar varios idiomas.
Coste final de proyecto profesional econmico.
Gestin de multitud mdulos de pago. Es muy sencillo incorporar nuevos mdulos

para ampliar la caractersticas de la tienda.
Grupos de clientes integrado.
Fcil instalacin con la mayora de opciones.
La herramienta atributos, personalizable y sencilla de usar.
Permite definir productos fsicos o virtuales (descargas).
Muy fcil de usar.
Bajo consumo de CPU.
Permite introducir cdigos de barras.
Panel de administracin muy intuitivo y sencillo.
Es muy rpido.
Prestastore: Tienda de mdulos ya desarrollados.
Prestashop 1.5 dispondr de multitienda.
La comunidad en espaol est creciendo muy rpido.
Prestashop 1.5 dispondr de versin para mviles tanto para Iphone como Android.
En contra:
Soporte mayormente en Francs o Ingls.
Sistema de atributos a mejorar.
Escasos Mdulos y themes.
Magento
Naci en el ao 2007 siendo un proyecto relativamente joven, pero pese a este factor
se ha ganado el respeto de muchos programadores, siendo hoy en da uno de los sistemas
ms utilizados.
Una de las cosas que no gusta de este gestor es su instalacin, demasiados problemas
para instalar el script, igual de complicado es su panel de control, si se tiene experiencia
en pginas web, se consigue hacerse a l, pero si el cliente, que al final va a ser la persona
que va a trabajar da a da en ella, no tienes conocimientos informticos puede tener
bastantes problemas para poder gestionarla.
Si se es un usuario novel no se recomienda Magento, en cambio si ya se tiene conoci-

mientos de programacin, se puede realizar prcticamente cualquier cosa.
Es recomendable para grandes empresas o grandes proyectos, ya que es donde real-

mente se ve su potencial, eso s es muy importante saber modificar Magento porque la
inexperiencia puede ser fatal, ya que el rendimiento caer en picado con una mala pro-
gramacin.
La gestin de pedidos la realiza realmente bien.
Los principales problemas que presenta Magento son:
La lentitud, difcilmente funcionara en un hosting compartido, necesita mnima-

mente un VPS o un servidor dedicado para poder correr la tienda en condiciones,
aparte de tener instalado aplicaciones de rendimiento.
Para tocar el corazn de Magento es importante tener los suficientes conocimientos

ya que cualquier error afectar seguro a la aplicacin y su rendimiento.
Tienen una versin gratuita que cada vez van limitando ms y ms, frente a la
versin de pago que ronda los 10.000 euros al ao.
Como podemos ver Magento [Global] es potente, es muy bueno, pero un desarrollo
con esta aplicacin es caro y se debe disponer de un servidor con suficientes recursos.
A destacar:
Muy potente, se puede realizar casi todo.
Permite multitiendas.
Sistema de bsquedas en Ajax.
Permite una personalizacin completa del sitio.
El panel de administracin es el ms completo con respecto a las herramientas

anteriores.
Gestin de pedidos muy potente.
En contra:
Comunidad pequea, poco soporte, prcticamente casi todo en Ingls.
Costes finales altos.
Instalacin y personalizacin complicada.
Mdulos desarrollados o themes escasos.
Panel de administracin complicado, ms todava para empresas sin conocimientos

informticos.
Consume muchos recursos.
El tamao del archivo de instalacin es muy grande.
Caractersticas del servidor bastantes exigentes.
Muchos mdulos de pago.
En caso de tener una tienda con mucho trfico es posible necesitar dos hosting por
lo que el gasto se puede disparar.
La curva de aprendizaje es muy alta.

Comparativa
Finalmente del sitio web Indeed.com he realizado un pequeo anlisis de las tendencias
de la demanda de programadores con conocimientos especficos en un framework.
Figura 3.75: ndices de aceptacin de frameworks - Indeed
La primera estadstica, que podemos observar en la Figura 3.75, muestra la tendencia

relativa de crecimiento. Donde se puede comprobar cmo en los ltimos aos la demanda
de la necesidad de programadores que trabajen con Rails ha crecido considerablemente.
En la segunda grfica, que se muestra en la Figura 3.76, se puede ver la tendencia de

la demanda en valores absolutos de los diferentes frameworks. Aqu se puede comprobar
que Magento y Ruby on Rails son los entornos de desarrollo web ms demandados por el
mercado en los ltimos aos.
3.7. ANLISIS GAP 101
Porqu Ruby on Rails?
Ruby es un lenguaje de propsito general muy flexible y moderno, cuyo propsito,

en palabras de su creador Yukuhiro Matsumoto, es ayudar a los programadores a
ser ms productivos y que disfruten y se diviertan con la programacin. Con esta
concepcin, el lenguaje se disea para el programador, proveyendo de herramientas
de alto nivel que hacen que sea muy cmodo y rpido trabajar con l.
Rails implementa la mayora de patrones de desarrollo que se utilizan en programa-
cin web, por lo que constituye una base muy slida sobre la que arrancar nuevos
proyectos, ahorra muchas horas de trabajo y nos ayuda a mantener nuestro cdigo
estructurado.
Cdigo limpio. Gracias a los principios de convencin sobre configuracin y DRY -
No te repitas, el nmero de lneas de cdigo a mantener en un proyecto Rails es
mnimo si lo comparamos con un proyecto escrito en PHP o Java. Esto hace que
sea mucho ms flexible a cambios, y como todo programador sabe, menos cdigo
significa menos probabilidad de haber cometido un error.
Arquitectura del mundo real. Rails fue originalmente extrado por su creadorDavid
Heinemeier Hansson de la aplicacin Basecamp, una aplicacin web de gestin de
proyectos. Esto hace que toda su filosofa se haya creado sobre necesidades reales y
le da un carcter muy prctico al framework.
3.7. Anlisis GAP
El framework Ruby on Rails nos proporciona las siguientes caractersticas con las
que puedo solventar los requisitos definidos para el proyecto:
Soporte para Ajax. Mejoran la interactividad, velocidad y usabilidad de los sitios

Web.
Patrn de diseo MVC. Facilita la separacin de la lgica de negocio de la
interfaz de usuario.
Internacionalizacin y localizacin. Soporte para poder adaptarse a diferentes
idiomas y regiones sin necesidad de cambios de ingeniera, ni cambios en el cdigo.
Interaccin con bases de datos. Incorporacin de APIs para poder trabajar
a alto nivel con diferentes tipos de bases de datos sin necesidad de modificar el
cdigo. Adicionalmente se pueden suministrar herramientas de mapeo entre objetos
y estructuras relacionales (ORM), de gestin transaccional y de migracin de bases
de datos.
Testing. Funcionalidades para realizar todo tipo de testing: test unitarios, funcio-
nales y de integracin.
Seguridad. Funcionalidades para gestionar la autenticacin y autorizacin a los

usuarios en base a determinados criterios.
Uso de plantillas. De esta forma se puede generar contenido de forma dinmica

reduciendo drsticamente el nmero de pginas Web del sitio.
Uso de cache. Se utiliza la cache para almacenar temporalmente documentos con

el fin de reducir la carga del servidor y el tiempo de respuesta.
Validacin de formularios. Se suministran las herramientas necesarias para rea-

lizar la validacin de la correcta entrada de datos en formularios Web.
Scaffolding. Herramienta que nos permite crear un esqueleto funcional, que genera
una interfaz web que permite llevar a cabo las operaciones bsicas CRUD sobre una
tabla especificada de la BD.
Tareas Rake predefinidas. Con esta herramienta se pueden generar o automatizar

el cdigo.
WebServer. Servidor para el desarrollo y las pruebas: WebBrick.
En la figura 3.4 vemos resumidas las caractersticas anteriores.
Tabla 3.4: Caractersticas de Ruby on Rails

Captulo 4
Diseo del Sistema
La fase de diseo tiene como objetivo determinar cmo va ser construido el sistema a
partir de los requisitos y el modelo obtenidos durante la especificacin, aplicando patrones
de diseo.
4.1. Diseo de la arquitectura
En esta seccin se define la arquitectura general del sistema de informacin.
4.1.1. Arquitectura fsica
Los componentes que compondrn la arquitectura fsica son los siguientes:
Navegador del Cliente: Un Navegador estndar HTML capaz de soportar CSS,

Javascript + Document Object Model y XML. Este servir como dispositivo de
interfaz de usuario. Toda la interaccin entre los usuarios y el sistema se realiza a
travs del navegador.
Servidor Web: El navegador del cliente acceder al sistema a travs del servidor
Web (WEBrick), el cual acepta las peticiones del cliente y ejecuta, si es el caso, los
scripts del lado del servidor necesarios. El resultado, una pgina HTML formateada,
ser enviada al cliente.
Conexin HTTP: Es el protocolo ms comn actualmente entre el cliente y el

servidor.
Conexin SMTP: Protocolo de red utilizado para el intercambio de mensajes de

correo electrnico.
103
104 CAPTULO 4. DISEO DEL SISTEMA
Pgina dinmica: Son pginas Web generadas por un procesamiento en el lado

del servidor.
Servidor de Aplicaciones: Es el principal motor para ejecutar la lgica del ne-

gocio del lado del servidor. En nuestro caso WEBrick, incluido con Ruby.
Servidor de Base de datos: MySQL. Es la parte del sistema que mantiene el

estado actual del negocio.
4.1.2. Arquitectura lgica
El haber seleccionado Rails para desarrollar mi aplicacin implica la eleccin del pa-
trn de diseo de software MVC (Modelo, Vista y Controlador) como base para mi
proyecto. Este es una gua para el diseo de la arquitectura de aplicaciones que ofrezcan
una fuerte interactividad con los usuarios.
La forma de organizar la aplicacin consiste en separar:
un modelo que representa los datos de la aplicacin y sus reglas de negocio,
un conjunto de vistas que representa los formularios de entrada y salida de in-

formacin,
un conjunto de controladores que procesa las peticiones de los usuarios y con-

trola el flujo de ejecucin del sistema.
La importancia de este modelo viene dada por la reutilizacin de cdigo.
Arquitectura MVC en Rails
La rapidez en el desarrollo de proyectos con Rails est fundamentada en la idea de

construir la aplicacin separando en 3 capas todos los componentes de la aplicacin (Mo-
delo, Vista y Controlador).
Modelo (Datos) es el SGBD (Sistema de Gestin de la Base de Datos) y las

funciones que contienen la lgica de negocio.
En las aplicaciones web orientadas a objetos sobre bases de datos, el modelo consiste
en las clases que representan a las tablas de la base de datos.
En el caso de RoR estas clases estn gestionadas por la biblioteca de mapeo objeto-
relacional (ORM) ActiveRecord, integrada en Rails.
De esta forma, lo nico que tiene que hacer el programador es heredar de la clase
ActiveRecord::Base, y el programa averiguar automticamente qu tabla usar y
qu columnas tiene.
4.1. DISEO DE LA ARQUITECTURA 105
Figura 4.1: Arquitectura MVC
Un modelo puede tener varias vistas, cada una con su correspondiente controlador.
Es el cdigo ms reutilizable y ms susceptible a cambios.
Vista (Interfaz de usuario) es la lgica de visualizacin, o cmo se muestran los
datos de las clases del Controlador. Con frecuencia en las aplicaciones web la vista
consiste en una cantidad mnima de cdigo incluido en HTML.
Existen muchas maneras de gestionar las vistas. El mtodo que se emplea en Rails,
por defecto, es usar Ruby Empotrado (archivos.html.erb), que son bsicamente
fragmentos de cdigo HTML con algo de cdigo en Ruby, siguiendo una sintaxis
similar a JSP. Tambin pueden construirse vistas en HTML y XML.
Es necesario escribir un pequeo fragmento de cdigo en HTML para cada mtodo
del controlador que necesita mostrar informacin al usuario.
Es la parte menos reutilizable y ms fcil de modificar sin que se vea afectado
nuestro ncleo.
Controlador (Lgica de negocio) une la vista con el modelo, contiene toda la lgica
de programacin. Almacena las funciones que toman los valores de un formulario,
delega consultas de base de datos al modelo y produce valores que invocarn a la
vista adecuada.
En el MVC, las clases del Controlador responden a la interaccin del usuario e
invocan a la lgica de la aplicacin, que a su vez manipula los datos de las clases
del Modelo y muestra los resultados usando las Vistas. En las aplicaciones web
basadas en MVC, los mtodos del controlador son invocados por el usuario usando
el navegador web.
La implementacin del Controlador es manejada por el ActionPack de Rails, que
contiene la clase ApplicationController. Una aplicacin Rails simplemente hereda
de esta clase y define las acciones necesarias como mtodos, que pueden ser invo-
cados desde la web, por lo general, en la forma http://aplicacion/ejemplo/metodo,
que invoca a EjemploController#mtodo, y presenta los datos usando el archivo de
plantilla \app\views\ejemplo\mtodo.html.erb, a no ser que el mtodo redirija
a algn otro lugar.
Figura 4.2: Representacin grfica en Rails del MVC
El diagrama de clase siguiente aclara cmo se implementa la arquitectura MVC en

Rails.
Figura 4.3: Implementacin MVC en Rails
El modelo encapsula una tabla de la base de datos1 , el controlador contiene una serie
de operaciones en los que se emplearn y modificarn los datos presentes en el modelo,
y por cada una de estas operaciones, existir una vista, desde la cual el usuario podr
configurar estas operaciones o recibir informacin sobre el estado de las mismas.
1
Por convencin, el nombre de la clase del modelo es el mismo de la tabla de la BBDD en singular.
4.2. DISEO DE LA INTERFAZ DE USUARIO 107
Sobre esta convencin se basa una de las prestaciones ms tiles que ofrece Rails,
conocida como Scaffold . Consiste en un pequeo script que, a partir de una especificacin
de una tabla de una base de datos, puede construir rpidamente la mayor parte de la
lgica y vistas necesarias para realizar las operaciones ms frecuentes. (Ver Seccin 5.2
Esqueleto para la aplicacin de la pgina 139).
4.2. Diseo de la interfaz de usuario
Para el diseo de la interfaz grfica de usuario he tenido en cuenta aspectos de usa-

bilidad, ya que la aplicacin desarrollada va a ser utilizada por personas que no estn en
la obligacin de poseer conocimientos informticos avanzados. Por ello la interaccin con
el usuario es simple e intuitiva.
El usuario recibe en todo momento una respuesta del programa en torno a operacio-
nes consideradas como invlidas, indicndole cmo llevarlas a cabo de manera correcta
mediante mensajes.
Al usar hojas de estilo CSS la apariencia de la aplicacin puede ser fcilmente modi-
ficada para adaptarla a nuevas tendencias de diseo de forma sencilla y eficiente.
Cada una de las pantallas que forman la aplicacin cuenta con una cabecera, diferente
para el administrador, y un pie de pgina comn.
Figura 4.4: Cabecera del administrador
Figura 4.5: Cabecera general

Figura 4.6: Pie de pgina
En la cabecera, se puede observar tambin un enlace para que el usuario se pueda

registrar o acceder a su cuenta, as como otro para seleccionar el idioma: ingls o espaol.
Estos aparecen en las diferentes pantallas de la aplicacin.
Figura 4.7: Mockup - Link Registro/Acceso clientes
Si el usuario ha accedido a su cuenta, aparecern los siguientes links en cada una de

las pantallas.
Figura 4.8: Mockup - Acceso clientes
4.2.1. Mockups
En cada uno de los sprints de la aplicacin he ido desarrollando una serie de mockups
que me han ayudado a la hora de disear la interfaz de usuario. stos se han ido mostrando
al cliente para su modificacin y aceptacin.
En el anexo H Relacin de CU y Mockups podr visualizar un listado que indica

para cada Caso de Uso cual es el mockup que lo implementa.
A continuacin se muestran algunos ejemplos de los mockup grficos finales de la

aplicacin, mostrndose en la barra de direcciones la de cada una de las pginas. El resto
de mockups podr visualizarlos en la carpeta mockups contenida en el CD adjunto.
Ejemplos de mockups de la parte de administracin. Como se puede ver en

cada una de las pantallas, mediante el mensaje Bienvenido admin, solo el administrador
tiene acceso a ellas.
Figura 4.9: Mockup - Panel de administracin
En la pantalla anterior (figura 4.9), el administrador tendr acceso a los distintos

gestores para poder administrar la web de forma sencilla. Veamos a continuacin algunas
un ejemplo de ellas para el gestor de contenido.
Visualizamos el mockup para la pantalla del gestor de contenidos Obras. sta tiene
aadido un apartado para realizar las bsquedas, de esta forma el administrador podr
obtener un listado de las obras (figura 4.10) y tambin adquirir el listado realizando una
bsqueda por cualquiera de los campos que se muestran.
En esta pantalla de la figura 4.11, el administrador ver toda la informacin referente

al pedido de un cliente y podr cerrar el pedido una vez haya sido enviado al cliente,
cambiando de esta forma su estado a cerrado.
Ejemplos de mockups de la parte que puede visualizar cualquier usuario.

Desde la pantalla de la figura 4.12, el usuario podr tener acceso a las caractersticas de
las diferentes obras as como aadirlas a la cesta de la compra.
La figura 4.13 ser utilizada para que el usuario pueda tener acceso, en caso de estar
registrado, a su cuenta de usuario o para que pueda registrarse en la web.
La pantalla de la figura 4.14 nos muestran la ficha tcnica de las obras, podemos ver
que el usuario tambin obtendr algunas recomendaciones relacionadas con la obra que
est visitando.
Figura 4.10: Mockup - Listado de obras
Figura 4.11: Mockup - Visualizacin del pedido

Figura 4.12: Mockup - Catlogo de obras
El siguiente ejemplo lo tenemos representado en la figura 4.15 y es para la cesta de

la compra, donde el usuario podr visualizar las obras que desea adquirir as como el
importe que le supondr de manera desglosada. Desde aqu podr realizar su pedido si
est registrado, sino automticamente le enviar a la pantalla para que realice el alta en
la web.
Tambin he realizado los mockups de los diferentes emails que se le envan al usuario
y a la Galera. Un ejemplo de ellos lo tenemos representado en la figura 4.16, ste ser
recibido por el usuario cuando realice un pedido.
4.2.2. Diagramas de navegacin
Mediante los siguientes diagramas de navegacin, reflejar la secuencia de pantallas a

las que tienen acceso los diferentes roles de usuario y la conexin entre stas.
Empezar mostrando parte del diagrama de navegacin para el administrador, con-

cretamente el men de Administracin (figura 4.17), el cual he dividido para que se vea
de forma ms clara, pudindose visualizar a continuacin el correspondiente para cada
uno de sus gestores (figuras 4.18, 4.19, 4.20).
Figura 4.13: Mockup - Identificacin
Figura 4.14: Mockup - Ficha de la obra

Figura 4.15: Mockup - Cesta de la compra
En la figura 4.21 podemos observar el diagrama de navegacin de los diferentes mens

para los usuarios2 de la Galera online y, para que se vea de forma ms clara, en la figura
4.22 vemos la parte correspondiente al catlogo.
La cesta de la compra acta de diferente manera ya sea un usuario registrado3 (figura

4.23) o un visitante (figura 4.24), veamos los diagramas de navegacin para cada uno de
ellos. Como se puede observar he marcado con un crculo rojo la parte que difiere.
2
Usuario: Registrado o Visitante
3
Usuario registrado: Cliente o Administrador
Figura 4.16: Mockup email - Confirmacin del pedido al usuario registrado

4.2. DISEO DE LA INTERFAZ DE USUARIO
Figura 4.17: Diagrama de navegacin para el administrador: Men Administracin
115
116
CAPTULO 4. DISEO DEL SISTEMA
Figura 4.18: Diagrama de navegacin para el administrador: Gestores de contenidos
Figura 4.19: Diagrama de navegacin para el administrador: Gestores generales
117
118
Figura 4.20: Diagrama de navegacin para el administrador: Gestores de clientes
Figura 4.21: Diagrama de navegacin para los usuarios: Mens
119
120
Figura 4.22: Diagrama de navegacin para los usuarios: Catlogo
Figura 4.23: Diagrama de navegacin para el cliente: Cesta de la compra
121
122
Figura 4.24: Diagrama de navegacin para el visitante: Cesta de la compra
4.3. DISEO DE DATOS 123
4.3. Diseo de datos
En esta seccin se define la estructura fsica de datos que utilizar el sistema, a partir
del modelo conceptual de clases mostrado en la seccin 3.3.
Para ello, he teniendo presente los requisitos establecidos para el sistema y las par-
ticularidades del entorno tecnolgico, de forma que se consiga un acceso eficiente de los
datos.
4.3.1. Esquema de la BD
El esquema de una base de datos describe su estructura4 en un lenguaje formal so-

portado por un Sistema Administrador de Base de Datos (DBMS) que en mi caso es
MySql.
Podemos ver en la Figura 4.25 representado el esquema de la base de datos del pro-
yecto.
En el modelo de datos he tenido en cuenta requisitos bsicos en el diseo de bases de

datos como los de tener una estructura normalizada de las tablas, controlando la redun-
dancia de la informacin, manteniendo la consistencia de datos, evitando las perdidas de
informacin y manteniendo la integridad de los datos guardados.
Los nombres de las tablas se han elegido siguiendo las convenciones de RoR, donde
Active Record obliga a que las tablas de la base de datos tengan el mismo nombre que las
clases del modelo pluralizadas.
4
Estructura de la BD: tablas, campos de cada tabla y relaciones existentes.
124
Figura 4.25: Esquema ERR de la Base de Datos
4.4. DISEO DE COMPONENTES 125
A continuacin muestro, como ejemplo, el esquema de la base de datos escrito en

lenguaje formal para una de las tablas. El esquema completo lo podemos encontrar en el
fichero \pitig\galeriaArte\db\schema.rb del proyecto.
c r e a t e _ t a b l e " admin_obras " , : f o r c e => t r u e do | t |

t . string "titulo"
t . string " referencia "
t . date " anio_realizacion "
t . string " medidas "
t . decimal " p r e c i o " , : p r e c i s i o n => 1 1 , : s c a l e => 2
t . text " comentario "
t . i n t e g e r " admin_coleccion_id "
t . i n t e g e r " admin_artistum_id "
t . i n t e g e r " admin_seccion_id "
t . i n t e g e r " admin_tecnica_id "
t . datetime " created_at "
t . d a t e t i m e " updated_at "
t . string " imagen_file_name "
t . string " imagen_content_type "
t . integer " imagen_file_size "
t . d a t e t i m e " imagen_updated_at "
end
Cdigo 4.1: Esquema de BD para la tabla admin_obras
4.4. Diseo de componentes
4.4.1. Diagrama de secuencia (DSS)
Debido a que estoy usando una metodologa gil, en esta seccin solo voy a mostrar, en
la figura 4.26, un diagrama de secuencia ilustrativo del funcionamiento de las peticiones
siguiendo el patrn MVC.
Los pasos son los siguientes:
1. El usuario introduce el evento, interactuando con la interfaz de usuario.
2. El Controlador recibe el evento y lo traduce en una peticin al Modelo (aunque

tambin puede llamar directamente a la Vista).
3. El Modelo (si es necesario) llama a la Vista para su actualizacin.

Figura 4.26: Diagrama de secuencia del patrn MVC
4. Para cumplir con la actualizacin la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
A modo de ejemplo veremos, en la figura 4.27, el diagrama de secuencia para el registro

de un usuario en la galera. En l podemos observar como se construye un nuevo usuario
dentro del sistema con los datos proporcionados por ste en la web.
Figura 4.27: Diagrama de secuencia del CU-0023: Registrarse

4.5. PARAMETRIZACIN DEL SOFTWARE BASE 127
4.4.2. Diagrama de clases de diseo
El diagrama de clases es el diagrama principal de diseo para un sistema. Se utiliza

para representar la estructura esttica de un sistema. Este contiene: las clases, atributos,
operaciones y las relaciones de dependencia, generalizacin y asociacin.
El diagrama de clases de diseo de la aplicacin est representado en la figura 4.28.
4.5. Parametrizacin del software base
Al ver elegido Ruby on Rails como framework para el desarrollo, no he necesitado

realizar ninguna parametrizacin para la correcta construccin de la aplicacin.
128
Figura 4.28: Diagrama clases de diseo
Captulo 5
Implementacin del Sistema
En el siguiente captulo describir los detalles ms significativos de la fase de imple-

mentacin de mi aplicacin.
5.1. Entorno tecnolgico
En esta seccin se indica el marco tecnolgico utilizado para la construccin del sis-
tema.
5.1.1. Lenguajes de programacin y framework
Como ya coment en la seccin 3.6.1.2, he seleccionado Ruby como lenguaje para

implementar mi aplicacin, ya que presenta una nueva forma de programar diferente a
las estudiadas durante la carrera.
Para facilitarme el trabajo he elegido Ruby on Rails (ver seccin 3.6.2.1), debido a
que es un framework de cdigo abierto para Ruby que sirve para desarrollar aplicaciones
web y ayuda a programar siguiendo las buenas prcticas de programacin.
El desarrollo de la aplicacin lo realizar aplicando el mtodo tradicional, es decir, uti-

lizar un editor de texto, concretamente Gedit y el terminal para ejecutar los comandos
de Rails.
En la aplicacin tambin emplear los siguientes lenguajes, los cuales se encuentran

integrados de forma sencilla en Ruby on Rails.
129
130 CAPTULO 5. IMPLEMENTACIN DEL SISTEMA
Lenguaje HTML
Voy a emplear este lenguaje en las Vistas como veremos ms adelante. En ellas este
ser el lenguaje principal. El cdigo en Ruby integrado en las vistas va a ser traducido a
HTML antes de ser interpretado por el navegador.
Los navegadores se encargan de mostrar a los usuarios las pginas web resultantes del
cdigo interpretado.
Lenguaje CSS
La idea principal del uso de CSS [W3C] es separar la estructura del documento de su
presentacin, con lo cual HTML define la estructura del documento y las hojas de estilo
su aspecto visual.
A cada elemento html se le asignar un id o class y se le modificarn sus propiedades

definindolas en un fichero css asociado al fichero html donde se encuentra dicho elemento.
5.1.2. Base de Datos
Aunque SQLite, SGBD por defecto, es fcil de administrar, mantener y personalizar,

funciona bien solo en aplicaciones web que no cuenten con demasiada carga de acceso a
la BD. Debido a esto, he preferido utilizar para el desarrollo de mi aplicacin el SGBDR
MySQL (Open Source).
El servidor MySQL fue desarrollado para manejar grandes bases de datos mucho ms
rpido que las soluciones existentes y aunque se encuentra en desarrollo constante, ofrece
un conjunto rico y til de funciones. Su conectividad, velocidad, seguridad , y su
facilidad de uso hacen de MySQL un servidor bastante apropiado para acceder a bases
de datos en Internet.
5.1.3. Herramientas de desarrollo
A continuacin voy a describir cada una de las herramientas que he utilizado en el

desarrollo de mi proyecto. Todas ellas han sido bastante tiles y fciles de utilizar.
5.1. ENTORNO TECNOLGICO 131
Adobe Reader: Es un lector estndar que me ayuda a visualizar e imprimir los

documentos PDF, puede obtenerse en www.adobe.es.
Assembla: Es una herramienta web que me permite el control de desarrollo

y la coordinacin de las actividades de mi proyecto. Ofrece elementos para
la administracin como: seguimiento de defectos y tareas, repositorios, control de
versiones, control del tiempo empleado y Scrum.
Para alojar mi proyecto he utilizado uno de los sistema de control de versiones que
posee Assembla: Subversion(5.1.3), ya que de entre los que ofrece es el que mejor
saba manejar.
Su pgina web es: http://www.assembla.com/.
Balsamiq Mockups: Aplicacin AIR pensada para ayudarnos a crear de manera
fcil y rpida nuestros wireframes1 . Lo consigue a travs de un sistema de drag-and-
drop de componentes predefinidos.
Con este software he desarrollado los diferentes Mockups de la aplicacin.
Su pgina web es: http://www.balsamiq.com/.
Dia v.0.97: Es un editor de diagramas con las herramientas necesarias para

crear o modificar grficos. Est concebido de forma modular, con diferentes paque-
tes de plantillas (UML, Cisco computer, diagramas de lgica, . . . ) para diferentes
necesidades. Es software libre GNU con Licencia General Pblica (GPL).
1
Wireframe: Boceto que define el contenido y la funcionalidad de una web.
Podemos obtener buenos resultados con l en poco tiempo, ya que su utilizacin es

muy fcil, flexible e intuitiva. Sus datos pueden ser exportados a diferentes formatos,
como el formato grfico .png, ideal para incluir en proyectos.
Dropbox v.1.6.11: Es un servicio de alojamiento de archivos multiplatafor-

ma en la nube, operado por la compaa Dropbox. Permite a los usuarios almacenar
y sincronizar archivos en lnea y entre computadoras y compartir archivos y carpetas
con otros. Para el proyecto he utilizado la versin gratuita, donde he almacenado
las imgenes de los artistas y obras de la Galera de Arte.
La versin gratuita se puede descargar desde: https://www.dropbox.com/.
Firebug: Es un complemento del gran navegador web Firefox que me permite

ver, depurar y probar todo lo que tenga que ver con el lado del cliente: HTML,
Javascript, CSS, pudiendo visualizar su efecto en la pgina en tiempo real.
gedit: Es un editor de textos compatible con UTF-8 para GNU/Linux. Enfatiza

la simplicidad y facilidad de uso e incluye herramientas para la edicin de cdigo
fuente y textos estructurados, como lenguajes de marcado.
gedit me proporciona un adecuado coloreado de sintaxis tanto en los archivos .rb
(puro ruby) como en los .html.erb (Rhtml) y abre mltiples archivos en pestaas,
suficiente para una cmoda edicin de cdigo.
Distribuido bajo las condiciones de la licencia GPL, gedit es software libre y es el
editor predeterminado de GNOME.
Gestor de versiones Subversin: Un gestor de versiones es un servidor de

almacenamiento de ficheros que almacena las diferencias en un fichero por cada
envo. De esta forma puedo mantener un historial de todos los cambios que se
realicen en el fichero a lo largo de su desarrollo y la ltima versin ser la suma de
todos los cambios.
En el desarrollo de software resulta til tener un historial del trabajo que se est
realizando y poder volver a una copia anterior con relativa facilidad. Tambin me
servir como copia de seguridad del trabajo realizado.
El gestor de versiones lo puede encontrar en las siguientes direcciones:
Galera de arte: https://www.assembla.com/code/pitig/subversion/nodes
Artista: https://www.assembla.com/code/pitig_artista/subversion/nodes
Git: Es un software de control de versiones que utilizar para el despliegue de

la aplicacin en Heroku.
Heroku [Heroku]: Es un servicio gratuito2 de hosting en la nube para el lenguaje
de programacin Ruby, aunque tambin da soporte a otros lenguajes como Java,
PHP. . . Su S.O. base es Debian.
Este servicio lo he utilizado para el despliegue online de mis aplicaciones, pudien-
do observar el de la Galera de Arte en http://gadeirart.herokuapp.com/ y el
de la Artista en http://artista.herokuapp.com.
La pgina web principal de Heroku es: http://www.heroku.com/.
MySql WorkBrench: Es una herramienta visual de diseo de bases de

datos que integra desarrollo de software, administracin y diseo de bases de datos,
creacin y mantenimiento para el sistema de base de datos MySQL. Con ella he
realizado el diagrama ERR de la base de datos de mi aplicacin. Es open source y
podemos obtenerlo en: http://www.mysql.com/products/workbench/.
Navegadores: Emplear diferentes navegadores para poder probar y depurar mi

aplicacin. Entre ellos: Firefox, Chromium, Internet Explorer.
2
Gratuito para aplicaciones de poco consumo, lo cual es bastante bueno para poder desarrollar y
lanzar la aplicacin sin pagar.
Nero Burning ROM: Programa para grabar todo tipo de archivos en CD o

DVD. Abarca todo lo que es datos, videos, sonido . . . Podemos obtener una versin
de prueba en: http://www.nero.com.
OpenProj [Leonardo Lemus, Jorge; Navas Muos, Jenniffer]: Es una aplicacin

gratuita y de cdigo abierto que puede ser utilizada bajo licencia CPAL (Common
Public Attribution License).
Esta herramienta est pensada para la gestin de proyectos y tareas y nos

permite generar grficos como:
Diagramas Gantt.
Diagramas PERT.
Diagramas WBS.
Diagramas RBS.
En concreto, con este software he desarrollado el Diagrama de Gantt del proyecto.
Pingdom: Herramienta online que permite medir la velocidad de carga de las

pginas web, adems genera un grfico bastante sencillo de entender donde se ve
la evolucin de carga en segundos de cada uno de los archivos de la web, el cual
permitir saber cul es el origen de una posible carga lenta y a qu archivo se debe.
Su url es http://tools.pingdom.com/fpt/.
StatSVN: Herramienta para analizar los repositorios de subversion. Con ella

se pueden obtener una serie de reportes interesantes que muestran la evolucin de
cada repositorio. Bastante sencilla de utilizar. Entre los reportes tenemos:
Total de lneas de cdigo en el tiempo.

Lneas de cdigo por desarrollador.
Actividad por da y hora.
Total de archivos y tamao promedio.
Archivos con mas revisiones.
Su pgina web es: www.statsvn.org.

WinEdt [Simonic, Aleksander]: Para redactar la presente memoria del proyecto

he empleado este potente y verstil editor de texto para Windows, creado por
el matemtico Aleksander Simonic, con una fuerte predisposicin hacia la creacin
de documentos LATEX[Burgos Pintos, Aris; Cornejo Barrios, Alicia; Gmez Mellado,
Antonio; Otros].
Ha sido especficamente diseado y configurado para integrarse perfectamente con

un sistema de TeX como MiKTeX, creado y mantenido por Christian Schenk.
Se puede descargar en la direccin: http://www.winedt.com/.
5.1.4. Componentes
Lo ms comn en una aplicacin escrita en Rails es que se reutilize cdigo creado por
otros desarrolladores. Este cdigo puede ser distribuido en gemas, las cuales podemos
decir, que son libreras que nos aportan nuevas funcionalidades para nuestro desarrollo.
stas se instalan o desinstalan mediante el gestor de paquetes RubyGems, el cual

proporciona:
un formato estndar y autocontenido llamado gem para poder distribuir programas

o libreras en Ruby,
una herramienta destinada a gestionar la instalacin de stos y
un servidor para su distribucin.
En otras palabras, RubyGems nos provee de una aplicacin llamada gem que permite
instalar, desinstalar y consultar sobre las libreras o gemas que tengamos instalada para
implementar en el desarrollo.
La configuracin de gemas se realizan en el fichero Gemfile que se encuentra en el

directorio raz de la aplicacin. A continuacin, a modo de ejemplo, muestro parte
del contenido del fichero Gemfile de la aplicacin.
s o u r c e http : / / rubygems . org
gem r a i l s , 3.0.9
# Bundle edge R a i l s i n s t e a d :
# gem r a i l s , : g i t => g i t : / / g i t h u b . com/ r a i l s / r a i l s . g i t
# Usamos MySql
gem mysql , : r e q u i r e => mysql
# Gema para l a s u b i d a y t r a t a m i e n t o de imagenes

gem p a p e r c l i p , 2 . 3 . 1 6
# Gema para t r a t a r p a p e r c l i p en heroku mediante Dropbox

gem p a p e r c l i p d r o p b o x , 1 . 0 . 5
# Gema para p a g i n a r l a s v i s t a s
gem w i l l _ p a g i n a t e , ~> 3 . 0 . pre2
....
Cdigo 5.1: Extracto del fichero Gemfile
En el fichero podemos ver que la mayora de las gemas se instalan desde el repositorio
de gemas http: // rubygems. org , aunque tambin se pueden instalar desde un reposito-
rio Git o desde una ruta. Junto al nombre de la gema le he indicado la versin que deseo
instalar.
Rails posee la herramienta Bundler para gestionar de forma sencilla y eficaz las de-
pendencias de gemas configuradas en el fichero Gemfile. sta se asegura de que la
aplicacin siempre cuente con las gemas necesarias para funcionar sin problemas. Me-
diante la orden:
$>bundle install
se instalan todas las dependencias necesarias, guardndolas en el fichero Gemfile.lock

del directorio raz. Este fichero contiene una lista exhaustiva de todas las gemas que
necesita la aplicacin junto con su nmero de versin, es decir, las que he declarado en
Gemfile y todas sus dependencias.
Veamos a modo de ejemplo un extracto de mi fichero Gemfile.lock.
GEM
remote : http : / / rubygems . o rg /
specs :
....
activerecord (3.0.9)
a c t i v e m o d e l (= 3 . 0 . 9 )
a c t i v e s u p p o r t (= 3 . 0 . 9 )
5.2. CDIGO FUENTE 137
a r e l (~> 2 . 0 . 1 0 )
t z i n f o (~> 0 . 3 . 2 3 )
....
rails (3.0.9)
a c t i o n m a i l e r (= 3 . 0 . 9 )
a c t i o n p a c k (= 3 . 0 . 9 )
a c t i v e r e c o r d (= 3 . 0 . 9 )
a c t i v e r e s o u r c e (= 3 . 0 . 9 )
a c t i v e s u p p o r t (= 3 . 0 . 9 )
b u n d l e r (~> 1 . 0 )
r a i l t i e s (= 3 . 0 . 9 )
....
PLATFORMS
ruby
DEPENDENCIES
....
n o k o g i r i (= 1 . 4 . 4 )
p a p e r c l i p (= 2 . 3 . 1 6 )
p a p e r c l i p d r o p b o x (= 1 . 0 . 5 )
r a i l s (= 3 . 0 . 9 )
s u n s p o t _ r a i l s (~> 1 . 2 . 1 )
tzinfo
w i l l _ p a g i n a t e (~> 3 . 0 . pre2 )
Cdigo 5.2: Extracto del fichero Gemfile.lock
En el anexo C Gemas podr encontrar descrita cada una de las gemas que he utili-
zado para el desarrollo de la aplicacin.
5.2. Cdigo fuente
Para poder comenzar mi proyecto [Hellsten, Christian; Laine, Jarkko], lo primero que
me hizo falta fue instalar Ruby on Rails y todos los paquetes que estn relacionados con
este ltimo que, por defecto, suelen instalarse con l.
Una vez instalados y tras ejecutar el comando
$>rails new galeriaArte

en la consola, se construy la estructura de directorios y los ficheros de configuracin de

mi aplicacin.
A continuacin explicar brevemente la funcionalidad de cada uno de ellos:
app En este directorio se organizan los componentes de la aplicacin y es donde

tiene lugar la mayor parte del proceso de implementacin. Lo forman los siguientes
subdirectorios:
controllers: Aqu podemos encontrar todos los controladores, es decir, el com-
portamiento lgico de la aplicacin.
helpers: Son mtodos comunes de la aplicacin que contienen las clases que
ayudan a los controladores. Se crean por defecto cuando se crea un controller.
mailers: En esta carpeta se define la clase UserMailer cuya funcin es espec-
ficamente el envo de correos.
models: Contiene las clases que modelan y empaquetan los datos almacenados
en la base de datos de la aplicacin. En ellas se definen las relaciones entre
entidades, las validaciones de datos . . . controlndose la integridad de los datos.
views: En esta carpeta se guardan las descripciones de las vistas de la aplica-
cin, es decir, las pginas RHTML de las que est compuesta. Su estructura
est subdivida por entidades poseyendo cada una sus propias pginas para
poder operar con el contenido de BD.
Existe una carpeta llamada layout que contiene la plantilla principal de la
aplicacin. Esta modela las partes comunes de las vistas como: el encabezado,
el men principal, el pie de pgina. . . .
config Contiene el cdigo relativo a la configuracin de la aplicacin, siendo
los aspectos ms destacados la configuracin de:
la base de datos (database.yml),
las rutas y los recursos de la aplicacin (routes.rb) y
los tres entornos que presenta Rails: desarrollo, pruebas y produccin (conte-
nidos dentro del subdirectorio \environments).
Entorno de desarrollo (development): Optimiza la productividad del
desarrollador. Las caches apenas operan, as que los cambios en el cdigo
de la aplicacin se aprecian rpidamente, sin tener que recompilar o volver
a desplegar nada. Slo hay que recargar la pgina del navegador.
Entorno de pruebas (test): Optimizado para ejecutar pruebas unita-
rias, funcionales y de integracin. Cada vez que se ejecuta una prueba, la
base de datos se limpia de todos sus datos y Ruby on Rails se encarga de
poblarla con datos de prueba antes de cada test, a travs de sus fixtures3 .
Entorno de produccin (production): Es donde se despliega la apli-
cacin final. Este entorno est optimizado para rendimiento.
3
Los fixtures son los datos de carga.
5.2. CDIGO FUENTE 139
db Este directorio alberga un subdirectorio llamado migrate que contiene las mi-
graciones de ActiveRecord, las cuales se encargarn de la creacin o eliminacin
de tablas y de la inclusin o eliminacin de campos en ellas, y los ficheros del
esquema de base de datos.
doc RoR posee Rubydoc, una interfaz a partir de la cual es posible generar autom-
ticamente documentacin sobre la aplicacin a partir de los comentarios recogidos
en el cdigo y que se almacenarn en este directorio.
lib Aqu se almacenan las libreras adicionales que son utilizadas en el proyecto.
log Contiene las trazas de ejecucin, que resultan especialmente tiles para tareas
de depuracin.
public Almacena los recursos internos de la aplicacin como imgenes, hojas de

estilos, javascripts . . .
script Contiene el script rails que sirve para iniciar la aplicacin.
solr Contiene los ficheros de configuracin necesarios para la realizacin de las

bsquedas dentro de la aplicacin.
test Aqu se almacenan las correspondientes pruebas unitarias, funcionales y de

integracin llevadas a cabo junto con sus fixtures.
tmp Dedicado al almacenamiento de aquellos archivos temporales que puedan estar

relacionados con el funcionamiento de la aplicacin.
vendor Para aquellas libreras externas que extiendan el funcionamiento bsico de

Rails.
Adems de estos directorios, destacan dos ficheros:
Rakefile: Su finalidad es similar al Makefile de GNU. En l se configuran los as-

pectos orientados a la construccin de la aplicacin, su distribucin en paquetes o
los tests a realizar. Esta configuracin es utilizada por el comando rake (hecho a
similitud del make de GNU).
Gemfile: En este fichero se indican las gemas necesarias para el funcionamiento

de mi aplicacin. Este es procesado por el Bundler que se encarga de gestionar las
dependencias de las gemas en Rails.
Esqueleto para la aplicacin
Una de las utilidades que ofrece Rails y que he aprovechado para la implementacin
es el Scaffolding, el cual sirve para crear un esqueleto funcional, que genera una interfaz
web que permite llevar a cabo las operaciones bsicas CRUD sobre una tabla especificada
de la BD.
Por cada elemento que representa una tabla en la base de datos, al ejecutar el script
Scaffold (figura 5.1) se genera:
una clase para la creacin/migracin de la tabla en la BD en db\migrate,

una clase para el modelo en app\models,
una clase para los test unitarios en test\unit,
un fichero para la carga de datos en test\fixtures,
una clase para el controlador que implementa las funciones CRUD en app\controllers,
una vista para cada una de las funciones del controlador en app\views\<nombre_tabla>,
una clase para los test funcionales en test\functional,
un mdulo para los helpers en app\helpers y
una hoja de estilo, la cual he eliminado ya que creo las mas propias para el proyecto,
en public\stylesheets.
A partir del esqueleto y para cada uno de los sprint, he ido implementando lo necesario
para obtener mi aplicacin final.
5.3. Implementacin del sistema
En esta seccin describo las implementaciones ms destacadas realizadas en el sistema.
5.3.1. Implementacin del Modelo
El Modelo es el componente del patrn de diseo MVC encargado del acceso a los
datos.
Llamaremos modelo a una clase que trabaja en relacin a una tabla de la base de
datos, las instancias de esta clase son instancias del modelo y el modelo encapsula la
lgica de negocios.
Siguiendo el patrn de diseo ActiveRecord he programado la lgica de negocio de

mi aplicacin.
Este patrn me ayuda a realizar todas las tareas de la base de datos: Definicin de
Datos y Manipulacin de Datos a travs de sus capacidades de metaprogramacin, sin
tener que escribir sentencias SQL.
5.3. IMPLEMENTACIN DEL SISTEMA 141
Figura 5.1: Ejecucin del script Scaffold para la tabla admin_obras

5.3.1.1. Definicin de datos
La definicin de la base de datos la he realizado utilizando migraciones, las cuales son

clases Ruby que ActiveRecord se encarga de interpretar y traducir en las secuencias SQL
necesarias segn el motor de base de datos con el que se est trabajando.
Las migraciones contienen los mtodos necesarios para la creacin de la tabla con todos
sus campos, as como su eliminacin, y se pueden localizar en el directorio db\migrate
de mi aplicacin con el siguiente nombre:
<fecha y hora de creacin>_create_<nombre de la tabla>.rb
A continuacin muestro, como ejemplo, el fichero de migracin de la tabla admin_obras.
c l a s s CreateObras < ActiveRecord : : M i g r a t i o n

d e f s e l f . up
c r e a t e _ t a b l e : admin_obras do | t |
t . string : titulo
t . string : referencia
t . date : anio_realizacion
t . string : medidas
t . decimal : p r e c i o , : p r e c i s i o n => 1 1 , : s c a l e => 2
t . text : comentario
t . r e f e r e n c e s : admin_coleccion
t . r e f e r e n c e s : admin_artistum
t . r e f e r e n c e s : admin_seccion
t . r e f e r e n c e s : admin_tecnica
t . timestamps
end
Admin : : Obra . c r e a t e _ t r a n s l a t i o n _ t a b l e ! : t i t u l o => : s t r i n g ,

: c o m e n t a r i o => : t e x t
end
d e f s e l f . down
drop_table : admin_obras
Admin : : Obra . d r o p _ t r a n s l a t i o n _ t a b l e !
end
end
Cdigo 5.3: Migracin de la tabla admin_obras

Figura 5.2: Ejemplo de ejecucin de rake migrate
Utilizar migraciones presenta otra gran ventaja y es que permite llevar un control de
versiones de cambios del schema de la base de datos, permitiendo volver atrs tras una
modificacin errnea.
Para que la estructura sea migrada a la BD se utiliza la siguiente instruccin:
$>rake db:migrate
y, por medio de ella, Rails explora el contenido del directorio db\migrate y ejecuta las
instrucciones contenidas en cada uno de los archivos(figura 5.2).
Rails, adems de las tablas definidas en las migraciones, aade otra tabla llamada
schema_migrations en la que almacena la versin actual de las migraciones. De este
modo, Active Record puede seguir el rastro de los cambios realizados en el esquema de
cada tabla.
5.3.1.2. Manipulacin de Datos
Para la manipulacin de datos Active Record [BuenasTareas.com] provee a la aplica-

cin de un fichero del objeto modelo. ste podemos localizarlo en el directorio app\models
con el nombre:
<nombre del modelo>.rb
Para el desarrollo de las clases del modelo he realizado los siguientes pasos en el fichero
anterior:
definir las relaciones entre los diferentes modelos,

definir las validaciones oportunas y

programar la lgica de negocio de la aplicacin que recaa en cada clase.
Como ejemplo, muestro el modelo para la clase Admin::Obra.
Lo primero que podemos observar es que la clase hereda de la clase ActiveRecord::Base,

con lo que el programa averigua automticamente qu tabla debe usar y qu columnas
tiene.
c l a s s Admin : : Obra < ActiveRecord : : Base
Cdigo 5.4: Cabecera del modelo Admin::Obra
Las relaciones en Rails se expresan mediante sencillas e intuitivas instrucciones como

has_one, belongs_to, has_many. Veamos como se expresara una de estas relaciones
en Rails para la aplicacin.
Relacin (1:N) - Artista crea Obra
Esta relacin expresa que una obra puede ser creada por un artista y que un artista
puede crear n obras. En cdigo Rails se expresa de la siguiente forma.
Dentro de la carpeta app\models en la:
clase Admin::Artistum, deber aadirse:
c l a s s Admin : : Artistum < ActiveRecord : : Base

has_many : admin_obras , : class_name => "Obra" ...
end
Cdigo 5.5: Modelo Admin::Artistum
clase Admin::Obra habr que aadir:

belongs_to : admin_artistum , : class_name => " Artistum "
end
Cdigo 5.6: Modelo Admin::Obra

Para el modelo de datos del ejemplo (Cdigo 5.7) existe una serie de relaciones be-
longs_to traducidas a que la obra pertenece a un artista, a una coleccin, a una seccin
y a una tcnica. Tambin podemos ver la existencia de relaciones has_many traducidas
a que pertenece a uno o varios carritos a travs de la clase CarritoItems y a uno o varios
pedidos a travs de la clase PedidoItems.

...
### R e l a c i o n e s ###
# R e l a c i o n de uno a uno
belongs_to : admin_artistum , : class_name => " Artistum "
belongs_to : admin_coleccion , : class_name => " C o l e c c i o n "
belongs_to : admin_seccion , : class_name => " S e c c i o n "
belongs_to : admin_tecnica , : class_name => " Tecnica "
# R e l a c i o n de uno a muchos
has_many : c a r r i t o s , : through => : c a r r i t o _ i t e m s
has_many : c a r r i t o _ i t e m s , : f o r e i g n _ k e y => " admin_obra_id "
has_many : pedido_items , : f o r e i g n _ k e y => " admin_obra_id "

has_many : pedidos , : through => : pedido_items
...
end
Cdigo 5.7: Cdigo de las relaciones del modelo Obra
Tambin se puede contemplar una serie de validaciones que aseguran que los datos
que se guardan en el modelo de datos son correctos.

...
### V a l i d a c i o n de d a t o s ###
# R e s t r i n g i m o s l o s s t r i n g s a 255 caracteres
validates_length_of : titulo , : i n => 1 . . 2 5 5
v a l i d a t e s _ l e n g t h _ o f : medidas , : i n => 1 . . 2 5 5
validates_length_of : referencia , : i n => 1 . . 2 5 5
# Ningun campo podra e s t a r en b l a n c o o v a c i o

validates_presence_of : t i t u l o
validates_presence_of : r e f e r e n c i a
validates_presence_of : anio_realizacion
validates_presence_of : medidas
validates_presence_of : precio
validates_presence_of : admin_artistum
validates_presence_of : admin_seccion
# Asociacion
v a l i d a t e s _ a s s o c i a t e d : admin_artistum , : admin_coleccion ,
: admin_seccion , : admin_tecnica
# Debe s e r un numero p o s i t i v o
validates : precio ,
: n u m e r i c a l i t y => { : greater_than_or_equal_to => 0 . 0 1 }
# Valor u n i c o
validates_uniqueness_of : r e f e r e n c i a
# Paperclip
v a l i d a t e s _ a t t a c h m e n t _ p r e s e n c e : imagen , : message => : blank
validates_attachment_content_type : imagen ,
: content_type =>[ image / jpeg , image /png , image / g i f ]
v a l i d a t e s _ a t t a c h m e n t _ s i z e : imagen ,
: g r e a t e r _ t h a n => 1 . k i l o b y t e
...
end
Cdigo 5.8: Cdigo de las validaciones del modelo Obra
Por ltimo tenemos la lgica de negocio de la entidad.

...
# Obras mas r e c i e n t e s
def s e l f . l a t e s t
f i n d : a l l , : l i m i t => 1 2 , : o r d e r => " admin_obras . i d d e s c " ,
i n c l u d e => [ : admin_artistum , : admin_coleccion ,
: admin_seccion ]
end
# Metodo para s u n s p o t
s e a r c h a b l e do
text : titulo , : default_boost => 6

text : alias_artista , : default_boost => 5
text : nombre_artista , : default_boost => 4
text : nombre_seccion , : default_boost => 3
text : anio_realizacion , : default_boost => 2
text : fecha_publicacion
end
# Alias del a rt is t a
def alias_artista
r e t u r n admin_artistum . i _ a l i a s
end
# Nombre d e l a r t i s t a
d e f nombre_artista
r e t u r n admin_artistum . nombre
end
# Nombre de l a s e c c i o n
d e f nombre_seccion
admin_seccion . nombre
end
end
Cdigo 5.9: Cdigo de los mtodos de la clase
5.3.1.3. Configuracin de la base de datos
Dentro del directorio config se encuentra el fichero database.yml en el que se

definen las BBDD que utilizar el sistema, as como el nombre de usuario y contrasea
para su acceso.
He definido tres bases de datos, una para cada uno de los entornos definidos en el
directorio config\environments: development, test, production (descritos en la seccin
5.2).
development :
a d a p t e r : mysql
database : galeriaArte_development
username : g a l e r i a A r t e
password : hacked
encoding : utf8
test :
adapter : mysql
database : galeriaArte_test
username : galeriaArte
password : hacked
encoding : utf8
production :
adapter : mysql
database : galeriaArte_production
password : hacked
encoding : utf8
Cdigo 5.10: Contenido del fichero database.yml
Como comentar anteriormente en la Seccin 5.3.1.1 Definicin de datos, para de-

finir la informacin que se desea almacenar, Rails emplea unos ficheros de migracin
abstrayndose de que tipo de BD se va a utilizar. De esta forma se podr utilizar la apli-
cacin con otras BBDD, sin tener que volver a definir las variables que se van a almacenar.
Para ello bastar con migrar4 la informacin de los ficheros a la nueva base de datos.
Prcticamente se ha abstrado la existencia de una base de datos durante la progra-

macin en Rails. El almacenamiento o eliminacin de los datos han sido gestionados por
medio de los modelos, nunca mediante comandos propios de la base de datos (aunque se
podran haber usado). Las BBDD han sido gestionadas mediante la herramienta rake a
travs de rdenes como:
$>rake db:create
$>rake db:drop
$>rake db:fixtures:load
5.3.2. Implementacin del Controlador
Como vimos anteriormente en la Seccin 4.1.2 Arquitectura MVC en Rails de la

pgina 104, las clases del Controlador responden a la interaccin del usuario e invocan
a la lgica de la aplicacin, que a su vez manipula los datos de las clases del Modelo y
muestra los resultados usando las Vistas.
4
Solamente se trasladan las definiciones.
En las aplicaciones web basadas en MVC, los mtodos del controlador son invocados
por el usuario a travs de las peticiones enviadas desde el navegador web.
He implementado en el directorio app\controllers varios controladores mediante

clases con el nombre:
<nombre de la tabla>_controller.rb
para gestionar las diferentes acciones de mi aplicacin y tambin, he definido el controlador

comn de toda la aplicacin, Application Controller, del que heredan todas las clases.
c l a s s Admin : : O b r a s C o n t r o l l e r < A p p l i c a t i o n C o n t r o l l e r
Cdigo 5.11: Cabecera del controlador Admin::Obras.
En el desarrollo de los controladores podemos distinguir los siguientes pasos:
desarrollar las acciones e
implementar el enrutamiento de las peticiones web a los mtodos del controlador.
5.3.2.1. Desarrollar las acciones del controlador
Las acciones correspondientes a un modelo son gestionadas por su controlador. La

implementacin del mtodo correspondiente a la accin del controlador crea las instancias
necesarias para pasar a las Vistas de la aplicacin o tan solo redirige hacia otras acciones.
La comunicacin se realiza a travs de variables de instancia que son compartidas por las
Vistas y los Controladores.
A continuacin podemos observar, como ejemplo, la implementacin de uno de los

controladores de la aplicacin.
Lo primero que he implementado en los controladores es el tipo de codificacin que

debe admitir. UTF-8 es capaz de representar cualquier carcter en el estndar Unicode.
# e n c o d i n g : u t f 8
Cdigo 5.12: Implementacin del controlador Admin::Obras. UTF-8
Seguidamente vemos las definiciones de los helpers y los filtros del controlador.
# e n c o d i n g : u t f 8
helper_method : sort_column , : s o r t _ d i r e c t i o n
b e f o r e _ f i l t e r : set_obra ,
: o n l y => [ : show , : e d i t , : e d i t _ t r a d u c c i o n ,
: update , : d e s t r o y ]
....
private # Uso i n t e r n o por e l c o n t r o l a d o r

d e f load_data
@admin_artistas = Admin : : Artistum . f i n d ( : a l l )
@admin_coleccions = Admin : : C o l e c c i o n . f i n d ( : a l l )
@admin_seccions = Admin : : S e c c i o n . o r d e r ( " nombre ASC" )
@admin_tecnicas = Admin : : Tecnica . o r d e r ( " nombre ASC" )
@tags = Tag . f i n d ( : a l l )
end
d e f sort_column
Admin : : Obra . column_names .
i n c l u d e ? ( params [ : s o r t ] ) ? params [ : s o r t ] : " t i t u l o "
end
def sort_direction
% w[ a s c d e s c ] . i n c l u d e ? ( params [ : d i r e c t i o n ] )
? params [ : d i r e c t i o n ] : " a s c "
end
...
end
Cdigo 5.13: Implementacin del controlador Admin::Obras. Helpers y filtros
El siguiente cdigo muestra un ejemplo de alguno de los mtodos definidos en el con-

trolador para implementar las diferentes historias de usuario.
....
# GET /admin/ o b r a s
def index
# P a g i n a c i o n con l a gema w i l l _ p a g i n a t e y o r d e n a c i o n
@admin_obras = Admin : : Obra .
o r d e r ( sort_column + + s o r t _ d i r e c t i o n ) . p a g i n a t e
: page => params [ : page ] , : per_page => 5 )
store_location
respond_to do | format |
format . html # i n d e x . html . er b
format . xml { r e n d e r : xml => @admin_obras }
end
end
# GET /admin/ o b r a s /1
d e f show
store_location
format . html # show . html . e rb
format . xml { r e n d e r : xml => @admin_obra }
end
end
# GET /admin/ o b r a s /new

d e f new
load_data
@admin_obra = Admin : : Obra . new
@ p a g e _ t i t l e = Nueva Obra
@action = Crear Obra
format . html # new . html . e rb
format . xml { r e n d e r : xml => @admin_obra }
end
end . . . .
end
Cdigo 5.14: Implementacin del controlador Admin::Obras. Mtodos
5.3.2.2. Enrutamiento
El enlace entre las acciones5 y las peticiones del navegador se encuentran definidas en
el archivo routes.rb del directorio config.
5
Acciones: Mtodos de los controladores
G a l e r i a A r t e : : A p p l i c a t i o n . r o u t e s . draw do
....
# Obras
namespace : admin do
r e s o u r c e s : o b r a s end
p o s t " o b r a s / u p d a t e _ t e c n i c a s " => " o b r a s#u p d a t e _ t e c n i c a s "
end
# Internacionalizacion espanol
s c o p e ( / : l o c a l e ) , : l o c a l e => / e s / do
namespace : admin do r e s o u r c e s : c o l e c c i o n s end
namespace : admin do r e s o u r c e s : a r t i s t a end
namespace : admin do r e s o u r c e s : s e c c i o n s end
namespace : admin do r e s o u r c e s : t e c n i c a s end
end . . . .
end
Cdigo 5.15: Extracto del contenido del fichero routes.rb
Por ejemplo, la siguiente lnea de cdigo anterior
namespace : admin do
r e s o u r c e s : o b r a s end
Cdigo 5.16: Lnea de cdigo para el enrutamiento de obras
nos habilita automticamente las siguientes URLs para el controlador admin/obras:
Verbo URL Accin Usado para

GET /admin/obras index Muestra un listado de todas las obras.
GET /admin/obras/new new Devuelve un formulario para crear una obra.
POST /admin/obras create Crea una nueva obra.
GET /admin/obras/1/edit edit Devuelve un formulario para editar una obra.
GET /admin/obras/1 show Muestra una determinada obra.
PUT /admin/obras/1 update Actualiza una determinada obra.
DELETE /admin/obras/1 destroy Borra una obra determinada.
Tabla 5.1: URLs habilitadas del enrutamiento de obras

Un listado de todas las rutas disponibles en la aplicacin se obtiene a travs de la

orden:
$>rake routes
Figura 5.3: Extracto del listado de rutas de la aplicacin
5.3.3. Implementacin de la Vista
La Vista es el objeto que maneja la presentacin visual de los datos representados por
el Modelo. Genera una representacin visual del Modelo y muestra los datos al usuario.
La interaccin con el usuario en una aplicacin web se realiza mediante un navegador

que interpreta las pginas HTML enviadas desde el servidor.
Aunque existen muchas maneras de gestionar las Vistas, el mtodo por defecto que se
emplea en Rails es Ruby Empotrado, que consiste en fragmentos de cdigo HTML con
algo de cdigo en Ruby, generando as HTML dinmico. Podemos diferenciar el cdigo
Ruby ya que se representa mediante el uso de:
Scriptlets. Cdigo situado entre las etiquetas < % %>.
Expresiones. Cdigo situado entre las etiquetas < %= %>.
Un ejemplo podemos verlo en los Cdigos 5.17 y 5.18 de la pgina 155.
Las vistas del proyecto las podemos localizar dentro del directorio app\views, donde
cada controlador tiene su propio directorio en el que se guardan todas las plantillas
RHTML con la siguiente estructura:
<nombre del controlador>\<accion>.html.erb

5.3.3.1. Layout
RoR permite utilizar una plantilla comn para toda la aplicacin llamada layout
donde, segn la peticin recibida, se incrusta la plantilla de la vista solicitada. Esta, que
ser la plantilla principal de mi aplicacin, modela los elementos comunes de la aplicacin
como: el encabezado, el men principal, el pie de pgina. . .
Podemos localizarla tambin dentro del directorio app\views con la siguiente es-
tructura:
\layouts\application.html.erb
5.3.3.2. Partials
Siguiendo uno de los principios de la filosofa de Rails Dont Repeat Yourself

descrito en el Prrafo Filosofa de la pgina 268, he trabajado con los llamados par-
tials que son fragmento de cdigo html.erb que pueden ser insertados en cualquier
vista. La ventaja de su uso es eliminar la duplicacin innecesaria de cdigo.
Los partials implementados para la aplicacin podemos encontrarlos dentro de cada

uno de los directorios que componen las vistas con la siguiente estructura:
<_nombre del partial>.html.erb
Figura 5.4: Ejemplo de los partials de las Vistas de Obras
A continuacin, a modo de ejemplo, podemos ver el cdigo de la vista new.html.erb

en donde se introduce el uso de varios partials para implementar el formulario. Podemos
observar que se consigue un cdigo limpio y fcil de seguir.
<d i v i d="page_content">
< %= form_for ( @admin_obra , @admin_artistas ,
@admin_coleccions , @tags ,
: html => { : m u l t i p a r t => t r u e } ) do | f | %>
< %= r e n d e r form_1 , : f => f %>
< %= r e n d e r form_2_new_tit , : f => f %>
< %= r e n d e r form_3 , : f => f %>
< %= r e n d e r form_4_new_com , : f => f %>
< %= r e n d e r form_5 , : f => f %>
< %= r e n d e r form_6_boton , : f => f %>
< % end %>
< %= l i n k _ t o , admin_obras_path , : c l a s s => " back " ,

: t i t l e => " R e t r o c e d e r" %>
</div>
Cdigo 5.17: Implementacin de la vista new.html.erb utilizando partial
En el siguiente cdigo podemos ver la implementacin del primero de los partials a

los que se hace referencia en el cdigo anterior.
< % i f @admin_obra . e r r o r s . any ? %>

<d i v i d="e r r o r _ e x p l a n a t i o n ">
<h2>
< %= t ( e r r o r s . t e m p l a t e . header ,
: count=>@admin_obra . e r r o r s . s i z e ,
: model=>t ( a c t i v e r e c o r d . models . admin_obra ) ) %>:
</h2>
<ul>
< % @admin_obra . e r r o r s . f u l l _ m e s s a g e s . each do | msg | %>
<l i >< %= raw msg %></l i >
< % end %>
</ul>
</div>
< % end %>
Cdigo 5.18: Implementacin del partial _form_1.html.erb

5.3.3.3. Hojas de estilo
Para realizar la maquetacin de la aplicacin he usado las Hojas de Estilo en

Cascada (CSS) las cuales son bsicas para que los HTML se vean como deseamos.
stas son muy importantes en el proceso de la creacin de un sitio Web, por eso he
procurado que sean sencillas, entendibles y, sobre todo, que estn bien estructuradas de
forma que sean fcilmente modificables.
Podemos localizarla dentro del directorio public\stylesheets con la siguiente

estructura:
\nombre_hoja_estilo.css
/ Catalogo /
/ Botones en c a t a l o g o /
a . img_recent {
t e x t d e c o r a t i o n : none ;
d i s p l a y : i n l i n e b l o c k ;
width : 2 2 px ;
h e i g h t : 2 2 px ;
backgroundimage : u r l ( . . / images / l a s t _ a r t . png ) ;
}
a . img_recent : hover {
width : 2 2 px ;
h e i g h t : 2 2 px ;
backgroundimage : u r l ( " . . / images / l a s t _ a r t o v e r . png " ) ;
backgroundc o l o r : t r a n s p a r e n t ;
}
a . img_cesta {
t e x t d e c o r a t i o n : none ;
width : 2 2 px ;
h e i g h t : 2 2 px ;
backgroundimage : u r l ( . . / images / cart_24 . png ) ;
}
a . img_cesta : hover {
width : 2 2 px ;
h e i g h t : 2 2 px ;
backgroundimage : u r l ( " . . / images / cart_24o v e r . png " ) ;

backgroundc o l o r : t r a n s p a r e n t ;
}
...
Cdigo 5.19: Extracto de hoja de estilo (catalogo.css)
5.3.4. Sesiones y Autenticacin
El sistema de sesiones y autenticacin de la aplicacin se ha delegado en la librera de

Ruby on Rails Authlogic [Johnson, Ben; ASCIIcasts]. Se caracteriza por:
Ser muy fcil de configurar, utilizar y extender.

Tiene muy buen nivel de seguridad y muchas funcionalidades extremadamente tiles
que, de hacerlas a mano, tomara mucho tiempo de implementar.
No genera controladores o vistas sino que slo trabaja con el cdigo que gestiona la
autenticacin de los usuarios. Debido a esto lleva un poco ms de tiempo hacer que
la aplicacin funcione con Authlogic ya que hay que escribir un poco ms de cdigo,
pero se gana flexibilidad y control acerca de cmo se presenta la autenticacin al
usuario.
En la implementacin del sistema de autenticacin he creado la clase del modelo User,

que gestiona la informacin bsica necesaria para el registro de los usuarios (nombre de
usuario y contrasea). Este modelo incluye acts_as_authentic para activar la funcio-
nalidad de authlogic.
He creado tambin el modelo UserSession, el cual se encarga de administrar todo lo

que tiene que ver con una sesin en nuestro sitio: su creacin (login) y su destruccin
(logout).
c l a s s U s e r S e s s i o n < A u t h l o g i c : : S e s s i o n : : Base
Cdigo 5.20: Cabecera del modelo UserSession (models\user_session.rb)
Hay que destacar que este modelo hereda de Authlogic::Session::Base, lo cual permite
configurarlo fcilmente.
Authlogic se encarga simplemente de la autenticacin de usuarios (el encriptamiento

de la contrasea lo realiza de forma automtica), pero permite restringirles el acceso en
los controladores. Para ello he definido los siguientes mtodos:
c l a s s A p p l i c a t i o n C o n t r o l l e r < A c t i o n C o n t r o l l e r : : Base
def require_usuario
unless current_user
store_location
r e d i r e c t _ t o ( new_user_session_url ,
: n o t i c e => " Usted debe e s t a r c o n e c t a d o
para t e n e r a c c e s o " )
return f a l s e
end
end
def require_no_usuario
i f current_user
store_location
r e d i r e c t _ t o ( catalogo_path ,
: n o t i c e => " Usted debe c e r r a r su s e s i o n
para a c c e d e r a e s t a pagina " )
return f a l s e
end
end . . .
Cdigo 5.21: Restriccin de acceso (controllers\application_controller.rb)
los cuales utilizo a travs de filtros en los controladores. Por ejemplo, solo los usuarios
registrados podrn realizar compras de obras de arte.
# app\ c o n t r o l l e r s \ c h e c k o u t _ c o n t r o l l e r . rb
c l a s s CheckoutController < ApplicationController
...
# Se r e q u i e r e s e r u s u a r i o r e g i s t r a d o
b e f o r e _ f i l t e r : require_usuario
...
end
Cdigo 5.22: Restriccin de acceso a la cesta de la compra
De esta forma, si un usuario visitante intenta realizar una compra, ser redirigido
automticamente al formulario de Inicio de sesin para que se se registre o se identifique
con su usuario antes de poder continuar.
5.3.5. Bsqueda de obras
En la aplicacin se ha implementado la opcin de que se puedan realizar bsquedas

de obras de arte.
Esta parte me ha llevado bastante tiempo implementarla, ya que al principio me decid

hacerlo utilizando la gema Sunspot [Brown, Mat], que permite aadir bsqueda de texto
completo en la aplicacin y, adems, tiene muchas caractersticas interesantes. sta me
dio bastantes quebraderos de cabeza y una vez que consegu que funcionara, cuando pase
a probar la aplicacin en Heroku, me encontr con la sorpresa de que el manejo de esa
gema en el servidor costaba dinero para los desarrolladores. As que tuve que buscar una
nueva solucin para implementarla, la gema MetaSearch [Miller; Railscasts].
Esta gema aade una forma muy til de realizar bsquedas sobre un modelo desde un
formulario, que consiste en llamar a un mtodo llamado search sobre cualquier modelo
pasndole los parmetros de bsqueda, tras lo que se recuperan los registros que casan
con dicha consulta.
# c o n t r o l l e r s \admin\ o b r a s _ c o n t r o l l e r . rb
...
def index
...
# Busqueda con l a gema meta_search
@search = Admin : : Obra . s e a r c h ( params [ : s e a r c h ] )
@admin_obras =
@search . o r d e r ( sort_column + + s o r t _ d i r e c t i o n ) .
p a g i n a t e ( : page => params [ : page ] , : per_page => 5 )
...
end
...
end
Cdigo 5.23: Llamada al mtodo Search con gema MetaSearch
En el ejemplo anterior de la aplicacin, he creado la bsqueda invocando a Ad-

min::Obra.search, pasndole los parmetros del formulario. A continuacin se invoca
a @search.order para recuperar la lista de productos correspondiente de forma ordenada
y paginada.
En el cdigo de la vista, el nombre de cada campo del formulario determinan las

condiciones de bsqueda.
<d i v c l a s s =" f i e l d ">

< %= f . l a b e l : admin_artistum_i_alias_contains ,
t ( . a r t i s t a ) %><br />
< %= f . t e x t _ f i e l d : admin_artistum_i_alias_contains %>
<br /><br />
</div>
<d i v c l a s s =" f i e l d ">

< %= f . l a b e l : t i t u l o _ c o n t a i n s , t ( . t i t u l o ) %><br />
< %= f . t e x t _ f i e l d : t i t u l o _ c o n t a i n s %><br /><br />
</div>
...
Cdigo 5.24: Nombre de los campos para la bsqueda con gema MetaSearch
En el ejemplo anterior, el campo de texto llamado titulo_contains quiere decir que

se buscarn los registros cuyo titulo contenga el valor introducido por el usuario en dicho
campo.
5.3.6. Notificaciones por correo electrnico
En la instalacin por defecto de Rails existe una librera llamada ActionMailer [Lind-
saar, Mikel; ASCIIcasts], cuya funcin es la de implementar el envo de correos electrnicos
de una manera sencilla (figura 5.5).
Sabiendo esto, crear un mailer para la aplicacin ha resultado bastante sencillo, a

travs de la siguiente orden en la lnea de comandos, dentro del directorio de la aplicacin:
$>rails g mailer <clase Mailer>
En esta instruccin, la clase Mailer ser una clase que se crear en el directorio
app\mailers, que heredar de la clase principal de la librera ActionMailer. Cada una
de las notificaciones que sea implementada dentro de esta clase, tendr su correspondiente
mtodo dentro de la misma.
Tambin se crea mediante la instruccin anterior, dentro del directorio app\views,

una carpeta con el mismo nombre de la clase, que contendr una vista por cada uno de
los mtodos del mail creados, donde se codificarn las distintas plantillas de las diferentes
notificaciones que se deseen enviar por correo electrnico.
La aplicacin web que he desarrollado tambin se encarga de enviar notificaciones

por correo electrnico (figura 5.5), al cliente y/o a la galera, concretamente cuando un
usuario:
Figura 5.5: Ejemplo de email de confirmacin de pedido al cliente

se registra en la web,
no recuerda su contrasea y
cuando realiza un pedido a la Galera de Arte.
Configuracin del correo
Para la aplicacin he especificado una configuracin SMTP durante la inicializacin.
Las opciones de dicha configuracin podemos encontrarla en el fichero setup_mail.rb

del directorio config\initializers.
# E s t a b l e c e e l metodo de e n t r e g a
A c t i o n M a i l e r : : Base . delivery_method = : smtp
# Opciones para l a e n t r e g a smtp

A c t i o n M a i l e r : : Base . s m t p _ s e t t i n g s = {
: e n a b l e _ s t a r t t l s _ a u t o => t r u e ,
: address => "smtp . gmail . com " ,
: port => "5 87 " ,
: user_name => " g a d e i r a r t @ g m a i l . com " ,
: password => <password >,
: authentication => " p l a i n " ,
: e n a b l e _ s t a r t t l s _ a u t o => t r u e
}
# Despliegue
A c t i o n M a i l e r : : Base . d e f a u l t _ u r l _ o p t i o n s [ : h o s t ] =
" g a d e i r a r t . heroku . com"
A c t i o n M a i l e r : : Base . d e f a u l t : c h a r s e t => " u t f 8"

A c t i o n M a i l e r : : Base . d e f a u l t : content_type => " t e x t / html "
Cdigo 5.25: Configuracin del servidor de correos (setup_mail.rb)
Implementacin
La clase mailer se comportan de manera parecida a los controladores normales de la

aplicacin por lo que comparten gran parte del cdigo.
Por cada notificacin de correo que va a enviar la aplicacin he aadido un mtodo a

esta clase. Veamos, como ejemplo, el mtodo para la confirmacin del registro de usuarios
en la web de la galera:
c l a s s U s e r M a i l e r < A c t i o n M a i l e r : : Base
# Los e m a i l s s i e m p r e s e e n v i a n desde l a misma d i r e c c i o n
d e f a u l t : from => " g a d e i r a r t @ g m a i l . com"
# C o nf i r m a ci o n de r e g i s t r o
def confirmacion_registro ( user )
@usuario_registrado = user
mail ( : t o => u s e r . email ,

: s u b j e c t => I18n . t ( . n o t i f i c a c i o n _ r e g i s t r o ) )
do | format |
format . t e x t # c o n f i r m a c i o n _ r e g i s t r o . t e x t . e r b
format . html # c o n f i r m a c i o n _ r e g i s t r o . html . e r b
end
end
...
end
Cdigo 5.26: Metodo de confirmacin de registro (user_mailer.rb)
Lo que hace el mtodo anterior es invocar el mtodo mail pasndole un hash con
argumentos tales como: :to, :from, y :subject.
Los mailers de correo, al igual que los controladores, tienen asociado un archivo de
vista, en el que se coloca el cuerpo del correo que se desea enviar. Para la aplicacin he
implementado correos en:
texto plano: <nombre del mtodo del correo>.text.erb
HTML: <nombre del mtodo del correo>.html.erb
Los emails se envan cuando se esta interactuando directamente con la propia apli-
cacin, en cuyo caso se est pasando por el controlador. Continuando con el ejemplo
anterior, vemos como se invoca al mtodo desde el controlador.
class UsersController < ApplicationController

...
def create
...
# Envia un e m a i l de c o n f i r m a c i o n de r e g i s t r o
U s e r M a i l e r . c o n f i r m a c i o n _ r e g i s t r o ( @user ) . d e l i v e r
...
end
...
end
Cdigo 5.27: Controlador invocando al mtodo del correo (user_controller.rb)
5.3.7. Pasarela de pago
La Galera de Arte desea un sistema de procesamiento, para los pedidos de sus clientes,
a travs de una pasarela de pago.
Este sistema se ha delegado en dos librera de Ruby on Rails:
Active Merchant [Luetke, Tobias; Fauser, Cody]: Nos permite el acceso de forma
sencilla a la pasarela de pago, haciendo frente a las tarjetas de crdito.
Authorize-Net [Center]: Nos facilita la conexin a la pasarela de pago Autho-

rize.Net, la cual proporciona la infraestructura compleja y de seguridad necesaria
para garantizar transacciones seguras, rpidas y fiables.
He seleccionado Authorize.Net, como pasarela de pago debido a que no he encon-

trado ninguna espaola que tuviera facilidad para su implementacin, ya que para ello
necesitaba datos reales y recordamos que la Galera de Arte es ficticia.
Authorize.Net dispone de un apartado sandbox (caja de arena) donde poder realizar

pruebas durante el desarrollo de la pasarela de pago. Para ello tuve que crearme una cuenta
ficticia, la cual me permite ver que el pago a travs de la pasarela funciona correctamente.
A continuacin veremos el cdigo a travs del cual conectamos con la pasarela de

pagos Authorize.Net, en el modo de prueba.
G a l e r i a A r t e : : A p p l i c a t i o n . c o n f i g u r e do
...
# P a s a r e l a de pagos
c o n f i g . a f t e r _ i n i t i a l i z e do
# Envia una s o l i c i t u d a l s e r v i d o r de prueba
# de l a p a s a r e l a de pagos
ActiveMerchant : : B i l l i n g : : Base . mode = : t e s t
# Crea un o b j e t o p a s a r e l a a l s e r v i c i o AuthorizeNetGateway
: :GATEWAY =
ActiveMerchant : : B i l l i n g : : AuthorizeNetGateway . new (
# API C r e d e n t i a l AuthorizeNetGateway
: login => 8gNzqAW9S8d ,
: password => 9 6 2 ZT2Grx7h9jv5C
)
end
end
Cdigo 5.28: Conexin con Authorize.net (config\environments\development.rb)
En la imagen 5.28 podemos ver los datos de la API Credentials facilitados al crear la
cuenta.
El acceso a sta se consigue a travs de la gema Active Merchant. Para ello he imple-
mentado el siguiente procedimiento:
d e f process_with_active_merchant
# Crea una t a r j e t a c r d i t o para e l comprador
c r e d i t _ c a r d = ActiveMerchant : : B i l l i n g : : CreditCard . new (
: fi r s t _ n a me => entregar_a_nombre ,
: last_name => e n t r e g a r _ a _ a p e l l i d o s ,
: type => t i p o _ t a r j e t a ,
: number => numero_tarjeta ,
: month => mes_caducidad ,
: year => anio_caducidad ,
: v e r i f i c a t i o n _ v a l u e => c o d i g o _ v e r i f i c a c i o n
)
i f credit_card . valid ?
# I n f o r m a c i o n d e l comprador para su pedido
options = {
# I n f o r m a c i n d e l pedido
: order_id => s e l f . id ,
: description => Obras de . . . GadeirArt ,
# I n f o r m a c i n de f a c t u r a c i n
: billing_address => {
: address1 => d i r e c c i o n _ d e _ e n t r e g a ,
: city => poblacion_de_entrega ,
: state => ciudad_de_entrega ,
: zip => cp_entrega ,
: country => p a i s _ e n t r e g a ,
: phone => t e l e f o n o ,
},
: email => email ,
# I n f o r m a c i n de e n v o
: s h i p p i n g _ a d d r e s s => {
: fi r s t _ n a me => entregar_a_nombre + " "
+ entregar_a_apellidos ,
: address1 => d i r e c c i o n _ d e _ e n t r e g a ,
: city => poblacion_de_entrega ,
: state => ciudad_de_entrega ,
: zip => cp_entrega ,
: country => p a i s _ e n t r e g a
}
}
# A u t o r i z a c i n para una c a n t i d a d de d i n e r o
response =
GATEWAY. p u r c h a s e ( t o t a l , c r e d i t _ c a r d , o p t i o n s )
...
end
Cdigo 5.29: Proceso con Active Merchant (models\pedido.rb)
En el cdigo 5.29 se crea una tarjeta de crdito a travs de los datos facilitados por el
cliente y se recoge la informacin relacionada con la facturacin del pedido.
Figura 5.6: Ejemplo de transacciones recibidas por Authorized.net

Cuando un cliente realiza un pedido y decide pagarlo a travs de su tarjeta de crdito,

la pasarela de pagos Authorize.Net recibe la informacin sobre el pedido y autoriza su
cobro (figura 5.6) informando de ello, a travs de un email, a la galera. Podemos ver uno
de esos email en la figura 5.7.
Figura 5.7: Correo enviado por Authorized.net con la aprobacin del cobro
5.3.8. Internacionalizacin
Primeramente voy a definir un par de trminos que creo importantes para esta seccin.
Internacionalizacin proceso en el que se desarrolla una aplicacin que puede adap-

tarse a distintos idiomas y regiones sin necesidad de realizar cambios de ingeniera.
Localizacin proceso de adaptar el software a una regin o lenguaje especfico aadiendo
componentes especficamente locales y traduciendo el texto pertinente.
Recordemos que uno de los requisitos del sistema es que las pginas web de la tienda
virtual puedan verse tanto en espaol como en ingls. Para la internacionalizacin/loca-
lizacin de la aplicacin he utilizado dos gemas.
I18n: Para traducir el texto esttico de la web, guardando su traduccin en ficheros

YAML dentro de la aplicacin.
Globalize3 [Stachewicz, Tomasz]: Para mostrar el texto de la base de datos en
diferentes idiomas.
I18n
Esta gema proporciona todos los medios necesarios para la internacionalizacin/lo-

calizacin y viene incluida en Rails, por lo que simplemente he tenido que configurar la
aplicacin para que utilice dicha funcionalidad. Los pasos seguidos han sido:
Crear un fichero yml por cada uno de los idiomas que utiliza la aplicacin en el direc-
torio config\locales: espaol (es.yml) e ingls (en.yml) . Como ejemplo
muestro el mismo extracto de cada uno de estos ficheros.
# Traduccion en e s p a n o l
" es ":
...
layouts :
application :
catalogo : " Catalogo "
etiquetas : " Etiquetas "
contactar : " Contactar "
quienes_somos : " Quienes somos "
condiciones : " Condiciones "
bienvenido : " Bienvenid@ "
mi_cuenta : "Mi cuenta "
salir : " Salir "
registrarse : " Registrarse "
login : " Iniciar sesion "
es : " Espanol "
en : " Ingles "
mi_cesta : "Mi compra "
...
Cdigo 5.30: Fichero de traduccin al espaol
# Traduccion en i n g l e s
en :
...
layouts :
application :
catalogo : " Catalog "
etiquetas : " Tags "
contactar : " Contact us "
quienes_somos : "Who we a r e "

condiciones : "Terms"
bienvenido : "Welcome"
mi_cuenta : "My account "
salir : " Exit "
registrarse : " Register "
login : "LogIn "
es : " Spanish "
en : " English "
mi_cesta : "My shopping c a r t "
Cdigo 5.31: Fichero de traduccin al ingls
Indicar a la aplicacin que cargue los diferentes archivos de idioma, para lo he creado
el archivo de inicializacin config\initializers\i18n.rb.
# Decimos a l a b i b l i o t e c a I18n donde e n c o n t r a r l a s

# t r a d u c c i o n e s para que l a s c a r g u e
I18n . load_path +=
Dir [ R a i l s . r o o t . j o i n ( l i b , l o c a l e , . { rb , yml } ) ]
Cdigo 5.32: Carga de diferentes archivos de idioma
Seleccionar el idioma con el que deseo que se muestre la aplicacin, es decir, espaol.
# Idioma por d e f e c t o
I18n . d e f a u l t _ l o c a l e = : e s
Cdigo 5.33: Idioma por defecto
Con esto ha quedado configurada la aplicacin para utilizar I18n. La traduccin de

las cadena de texto las he obtenido utilizando el helper I18n.translate a travs de su alias
t.
...
<body>
...
<d i v i d="top_banner">
<d i v i d="top_menu">
<u l c l a s s ="menu">
...
<l i ><a h r e f ="/ i n i c i o " c l a s s ="nav">
< %= t ( . i n i c i o ) %>
</a></ l i >
<l i ><a h r e f ="/ g a l e r i a / n o s o t r o s /1" c l a s s ="nav">
< %= t ( . quienes_somos ) %>
</a></ l i >
<l i ><a h r e f ="/ c a t a l o g o " c l a s s ="nav">
< %= t ( . c a t a l o g o ) %>
</a></ l i >
<l i ><a h r e f ="/ g a l e r i a / c o n d i c i o n e s / i n d e x _ u s u a r i o "
c l a s s ="nav">
< %= t ( . c o n d i c i o n e s ) %>
</a></ l i >
<l i ><a h r e f ="/ c o n t a c t a r " c l a s s ="nav">
< %= t ( . c o n t a c t a r ) %>
</a></ l i >
</ul>
</div>
</div>
...
Cdigo 5.34: Idioma por defecto
En el ejemplo anterior de la aplicacin, t(.quienes_somos) nos devuelve Quienes

somos para el idioma espaol y Who we are si la pgina se esta mostrando en ingls,
segn el correspondiente fichero de traduccin.
Globalize3
Globalize3 tambin provee servicios para la internacionalizacin y localizacin en Rails.
Como coment anteriormente, esta gema me ha ayudado a mostrar el texto de la base

de datos en diferentes idiomas, para lo que crea una tabla independiente para cada uno
de los modelos de la aplicacin donde almacena las diferentes traducciones. Segn la zona
seleccionada por el usuario en la web pasar a mostrar la interpretacin correspondiente.
c l a s s CreateObras < ActiveRecord : : M i g r a t i o n

d e f s e l f . up
...
# Traduccion
Admin : : Obra . c r e a t e _ t r a n s l a t i o n _ t a b l e !
: titulo => : s t r i n g ,
: c o m e n t a r i o => : t e x t ,
: estado => : s t r i n g
end
d e f s e l f . down
...
Admin : : Obra . d r o p _ t r a n s l a t i o n _ t a b l e !
end
end
Cdigo 5.35: Tabla para la traduccin del modelo Obras
El cdigo anterior crea una tabla para la traduccin del modelo Obras con los campos
que se desean traducir.
Captulo 6
Pruebas del Sistema
Las pruebas de software (testing) [Wikipedia] son los procesos que permiten verificar
y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos
de implementacin, calidad o usabilidad de un programa. Bsicamente es una fase en el
desarrollo de software consistente en probar las aplicaciones construidas.
Para ello, seguir un desarrollo guiado por pruebas - TDD con el que lograr un cdigo
limpio que funcione. Este consiste en dos prcticas:
Escribir las pruebas primero (Test First Development), y se verifica que estas
fallen, luego se implementa el cdigo que haga que la prueba pase satisfactoriamente.
Refactorizacin (Refactoring) del cdigo escrito.
La descripcin de las diferentes pruebas que llevar a cabo durante el desarrollo del
proyecto se encuentra en el anexo F Pruebas y tendrn dos finalidades:
Dar soporte y guiar la fase de desarrollo e implementacin.
Dar una garanta del correcto funcionamiento de las distintas funcionalidades im-
plementadas, para poder as asegurar la calidad del producto final entregado.
6.1. Pruebas en Rails
Rails posee, en su rbol de directorios, una carpeta denominada test orientada a la

implementacin de las pruebas, la cual posee los siguientes subdirectorios:
fixtures: Donde se incluirn una serie de ficheros YAML, en los cuales ser posible
crear, de forma sencilla e intuitiva, las instancias que sern empleadas en las distintas
pruebas.
173
174 CAPTULO 6. PRUEBAS DEL SISTEMA
functional: En esta carpeta se codificarn las pruebas encargadas de garantizar el

correcto funcionamiento de los distintos controladores de la aplicacin.
integration: Se guardarn las pruebas realizadas para comprobar la interaccin

entre los diferentes controladores.
unit: Se almacenarn las distintas pruebas unitarias que se lleven a cabo sobre los
modelos de datos de los distintos mdulos a probar.
La creacin de los ficheros con las plantillas para poder programar los test, incluidos
en los subdirectorios anteriores, se realiza de forma automtica cuando se utilizan algunos
de los scripts incluidos en Rails, como por ejemplo el Scaffold (ver seccin 5.2).
La aplicacin web que voy a desarrollar est basada en el patrn de diseo MVC
(Modelo, Vista y Controlador) (ver seccin 4.1.2), siendo cada uno de estos compo-
nentes independientes entre s. Este hecho, trasladado a la fase de pruebas, lleva como
consecuencia que algunas de las pruebas que se realicen se centren en aspectos cuya fun-
cionalidad resida en el modelo, en el controlador o en la vista; y que segn donde se
establezca, las pruebas necesiten un enfoque o unas herramientas concretas.
6.2. Pruebas unitarias
Los modelos de datos incluye una serie de normas, excepciones y relaciones adaptados
al problema a resolver. Para poder comprobar su correcto cumplimiento, he realizado
una serie de pruebas unitarias, cuyo objetivo ser el de garantizar el cumplimiento de las
condiciones de validacin tratando que ningn tipo de informacin que las vulnere sea
almacenada en la base de datos. Podemos localizar todas estas pruebas en el directorio
test\unit de la aplicacin con la siguiente estructura de nombre:
<nombre del modelo>_test.rb
A continuacin, a modo de ejemplo, muestro un extracto de las pruebas unitarias

realizadas sobre el modelo Obras.
c l a s s Admin : : ObraTest < A c t i v e S u p p o r t : : TestCase

...
##############################################
# Test para comprobar que no puede g u a r d a r s e #
# una obra s i n t i t u l o #
##############################################
t e s t " Test no guardar obra s i n t i t u l o " do
obra = Admin : : Obra . new (
6.2. PRUEBAS UNITARIAS 175
#: t i t u l o => Gato pardo ,

: referencia => 1 2 3 ,
: anio_realizacion => 2 0 1 0 ,
: medidas => 2 0 x 2 0 ,
: precio => 3 5 . 5 0 ,
: admin_coleccion_id => 1 ,
: admin_artistum_id => 1 ,
: admin_seccion_id => 1 ,
: admin_tecnica_id => 1 )
a s s e r t ! obra . save , "Guardado obra s i n t i t u l o "
end
#################################################
# Test para comprobar que e l p r e c i o e s p o s i t i v o #
#################################################
t e s t " Test p r e c i o de l a obra debe s e r p o s i t i v o " do
: titulo => Gato pardo ,
: referencia => 3 2 1 ,
: medidas => 1 0 x 1 5 ,
: precio => 3 5 . 5 0 ,
: admin_tecnica_id => 1 ,
: imagen_file_name => cuadro . jpg ,
: imagen_content_type => image / jpeg ,
: imagen_file_size => 34714)
obra . p r e c i o = 1
a s s e r t obra . i n v a l i d ?
a s s e r t _ e q u a l " debe s e r mayor que o i g u a l a 0 . 0 1 " ,
obra . e r r o r s [ : p r e c i o ] . j o i n ( ; )
obra . p r e c i o = 0
a s s e r t obra . i n v a l i d ?
a s s e r t _ e q u a l " debe s e r mayor que o i g u a l a 0 . 0 1 " ,
obra . e r r o r s [ : p r e c i o ] . j o i n ( ; )
obra . p r e c i o = 3 5 . 5 0
a s s e r t obra . v a l i d ?
end
...
##############################################
# Test para v e r i f i c a r que s e puede a c c e d e r a #
# una c o n j u n t o de o b r a s de un a r t i s t a #
##############################################
t e s t " has_many_and_belongs_to_artista " do
# Mira en l o s a r t i s t a s y v e r i f i c a que hay a l menos
# una obra en e l c o n j u n t o de o b r a s i n s e r t a d a por
# f i x t u r e a l comienzo d e l t e s t .
artista =
Admin : : Artistum . f i n d _ b y _ i _ a l i a s ( " Pedro Gonzlez " )
a s s e r t _ e q u a l 2 , a r t i s t a . admin_obras . s i z e
# Creamos una nueva obra

: titulo => V i s t a de l a C a t e d r a l
de Cdiz ,
: referencia => fot_511 ,
: medidas => 1 0 x 1 5 ,
: precio => 5 . 0 0 ,
: admin_coleccion_id => Admin : : C o l e c c i o n . f i n d ( 3 ) . id ,
: admin_artistum_id => Admin : : Artistum . f i n d ( 1 ) . id ,
: admin_seccion_id => Admin : : S e c c i o n . f i n d ( 5 ) . id ,
: admin_tecnica_id => Admin : : Tecnica . f i n d ( 1 1 ) . id ,
: imagen_file_name => c a d i z 0 0 2 . jpg ,
: imagen_file_size => 29315)
# Aadimos l a nueva obra a l a r t i s t a

a r t i s t a . admin_obras << obra
# Recargamos en l a BD l o s d a t o s
artista . reload
obra . r e l o a d
# V e r i f i c a m o s que ahora hay dos o b r a s para e l a r t i s t a

a s s e r t _ e q u a l 3 , a r t i s t a . admin_obras . s i z e
end
...
###################################################
# Test para comprobar que s e puede c r e a r una obra #
###################################################
t e s t " Test d e b e r a c r e a r una obra " do
obra = Admin : : Obra . new
6.2. PRUEBAS UNITARIAS 177
obra . t i t u l o = Lo que e l v i e n t o s e dejo

obra . r e f e r e n c i a = "15983"
obra . a n i o _ r e a l i z a c i o n = 2011
obra . medidas = 10 x 15
obra . p r e c i o = 135.50
obra . admin_coleccion_id = 1
obra . admin_artistum_id = 1
obra . admin_seccion_id = 1
obra . admin_tecnica_id = 1
obra . imagen_file_name = cuadro . jpg
obra . imagen_content_type = image / jpeg
obra . i m a g e n _ f i l e _ s i z e = 34714
a s s e r t obra . s a v e
end
...
end
Cdigo 6.1: Pruebas unitarias sobre el modelo obras
Podemos observar en el cdigo que se realizan pruebas sobre: las validaciones imple-
mentadas al modelo, sobre las relaciones establecidas entre entidades (mostradas en los
ejemplos de la seccin 5.3.1.2) y por ltimo se establece un contexto donde se comprueba
la creacin de una nueva instancia de la clase.
Para la ejecucin de las pruebas de unidad he utilizado el comando
$>rake test:units
con el que he obtenido el siguiente resultado al aplicarla sobre la aplicacin:
Figura 6.1: Resultado de la ejecucin de las pruebas unitarias

6.3. Pruebas de integracin
El objetivo de las pruebas de integracin es probar la interaccin entre varios contro-

ladores. Usualmente se utilizan para probar el flujo de trabajo dentro de la aplicacin.
Estas pruebas han sido creadas en el directorio test\integration de la aplicacin

con la siguiente estructura de nombre:
<nombre de la prueba>_test.rb
Para el desarrollo de stas, he empleado un lenguaje especfico de dominio (DSL) en

Ruby [Dodero, Juan Manuel], utilizando mdulos y bloques para definirlo.
Ello podemos observarlo en el siguiente cdigo, el cual corresponde a un extracto del

test de integracin para comprobar el correcto funcionamiento de la administracin de las
obras de la Galera. Las acciones llevadas a cabo para ello vienen como comentarios.
c l a s s ObraTest < A c t i o n D i s p a t c h : : I n t e g r a t i o n T e s t
# E s p e c i f i c o f i x t u r e s que deben c a r g a r s e
f i x t u r e s : users
# Comprueba e l c o r r e c t o f u n c i o n a m i e n t o de l a
# a d m i n i s t r a c i o n de o b r a s
t e s t " G e s t i o n de o b r a s " do
# Crear nueva c o l e c c i o n
c o l e c c i o n = Admin : : C o l e c c i o n . c r e a t e (
: nombre => E s c u l t u r a s Romanas )
# Crear nuevo a r t i s t a
artista = Admin : : Artistum . c r e a t e (
: i_alias => Marcos Torres ,
: nombre => Marcos T o r r e s Sanz ,
: c u r r i c u l u m => Nacio en S e v i l l a en 1 9 5 5 )
...
# I n i c i a r s e s i o n como u s u a r i o
u s u a r i o = new_session_as ( : usuario_001 )
# Anadir una nueva obra ( con e t i q u e t a s )

obra_nueva = u s u a r i o . add_obra
: t a g s => E s c u l t u r a , Estatua , Romana ,
: obra => {
: titulo => Busto de emperador ,
: referencia => esc_201 ,
6.3. PRUEBAS DE INTEGRACIN 179
: anio_realizacion => 2011 ,

: medidas => 30 x 40 ,
: precio => 95.00 ,
: admin_coleccion_id => c o l e c c i o n . id ,
: admin_artistum_id => a r t i s t a . id ,
: admin_seccion_id => s e c c i o n . id ,
: admin_tecnica_id => t e c n i c a . id ,
: imagen_file_name => busto . jpg ,
: imagen_file_size => 478591
}
# Ver e l l i s t a d o de o b r a s
usuario . list_obras
...
# I n i c i a r s e s i o n con o t r o u s u a r i o
u s u a r i o 2 = new_session_as ( : usuario_002 )
# E l i m i n a r una obra
u s u a r i o 2 . d e l e t e _ o b r a obra_nueva
end
private
module ObraTestDSL
a t t r _ w r i t e r : name
# L i s t a d o de o b r a s
def list_obras
g e t "/ admin/ o b r a s "
assert_response : success
a s s e r t _ t e m p l a t e "admin/ o b r a s / i n d e x "
end
# Anadir obra
d e f add_obra ( p a r a m e t e r s )
c o l e c c i o n = Admin : : C o l e c c i o n . f i n d ( : a l l ) . f i r s t
artista = Admin : : Artistum . f i n d ( : a l l ) . f i r s t
g e t "/ admin/ o b r a s /new"

a s s e r t _ t e m p l a t e " o b r a s /new"
a s s e r t _ t a g : t ag => op ti o n ,
: a t t r i b u t e s => { : v a l u e => c o l e c c i o n . i d }
a s s e r t _ t a g : t ag => op ti o n ,
: a t t r i b u t e s => { : v a l u e => a r t i s t a . i d }
p o s t "/ admin/ o b r a s " , p a r a m e t e r s
obra = Admin : : Obra . f i n d _ b y _ t i t u l o (

p a r a m e t e r s [ : obra ] [ : t i t u l o ] )
assert_equal parameters [ : tags ] . s p l i t ( , ) . s i z e ,
obra . t a g s . s i z e
r e t u r n obra
end
# B o r r a r obra
d e f d e l e t e _ o b r a ( obra )
d e l e t e "/ admin/ o b r a s/#{obra . i d }"
assert_response : redirect
follow_redirect !
a s s e r t _ t e m p l a t e "admin/ o b r a s / i n d e x "
end
...
end
# I nicia lizar sesion

d e f new_session_as ( name )
o p e n _ s e s s i o n do | s e s s i o n |
s e s s i o n . extend ( ObraTestDSL )
s e s s i o n . name = name
y i e l d s e s s i o n i f block_given ?
end
end
end
Cdigo 6.2: Pruebas de integracin para la administracin de obras
El extracto anterior verifica que las historias de usuarios aadir obras, listar obras
de arte y eliminar obras funcionan correctamente.
Se puede observar que, a diferencia de las pruebas funcionales, las pruebas de integra-
cin pueden:
6.4. PRUEBAS DE SISTEMA 181
abarcar varios controladores, en el ejemplo se utilizan diferentes para crear una

nueva coleccin, un nuevo artista y para realizar las acciones sobre las obras de
arte,
abrir varias sesiones, en el ejemplo se abren dos: una para usuario y otra para un
usuario diferente: usuario2.
Para la ejecucin de las pruebas de integracin he utilizado el comando
$>rake test:integration
Figura 6.2: Resultado de la ejecucin de las pruebas de integracin
6.4. Pruebas de sistema
Mediante la realizacin de estas pruebas se asegura que el sistema cumple con to-
dos los requisitos establecidos: funcionales, de almacenamiento, reglas de negocio y no
funcionales.
6.4.1. Pruebas funcionales
Las clases y funciones involucradas en el controlador contienen la mayor parte de la

funcionalidad que se espera de la aplicacin. Segn la operacin a realizar, la informacin
que se obtenga del modelo de datos ser transformada y preparada para ser mostrada al
usuario por pantalla.
Para garantizar que todas estas operaciones concernientes a la lgica de la aplicacin

se realizan correctamente, he realizado una serie de pruebas funcionales que podemos
localizar en el directorio test\functional de la aplicacin con la siguiente estructura
de nombre:
<nombre del controlador>_controller_test.rb

A modo de ejemplo, muestro un extracto de las pruebas funcionales realizadas sobre

el controlador Obras.
c l a s s Admin : : O b r a s C o n t r o l l e r T e s t < A c t i o n C o n t r o l l e r : : TestCase

...
##################################################
# Test para comprobar que s e c r e a una nueva obra #
##################################################
t e s t " D e b e r i a poder c r e a r una nueva obra " do
num_obras = Admin : : Obra . count
p o s t : c r e a t e , : admin_obra => { : t i t u l o => Gato pardo ,
: referencia => 1 ,
: medidas => 2 0 x 2 0 ,
: precio => 3 5 . 5 0 ,
: admin_tecnica_id => 1 ,
: imagen_file_name => cuadro . jpg ,
: imagen_file_size => 34714}
a s s e r t _ r e d i r e c t e d _ t o admin_obra_path ( a s s i g n s ( : admin_obra ) )
a s s e r t _ e q u a l num_obras+1, Admin : : Obra . count
end
###############################################
# Test para comprobar que s e muestra una obra #
###############################################
t e s t " D e b e r i a poder mostrar una obra " do
g e t : show , : i d => @admin_obra . to_param
a s s e r t _ t e m p l a t e admin/ o b r a s /show
a s s e r t _ e q u a l " Busto de emperador " ,
a s s i g n s ( : admin_obra ) . t i t u l o
a s s e r t _ e q u a l 2 , a s s i g n s ( : admin_obra ) . admin_seccion_id
end
...
end
Cdigo 6.3: Pruebas funcionales sobre el controlador de obras

Podemos observar en el extracto anterior la implementacin de dos test: uno para

crear una nueva obra y otro para comprobar que se muestra dicha obra.
Para la ejecucin de las pruebas funcionales he utilizado el comando
$>rake test:functionals
Figura 6.3: Resultado de la ejecucin de las pruebas funcionales
6.4.2. Pruebas no funcionales
Estas pruebas pretenden comprobar el funcionamiento del sistema, con respecto a los
requisitos no funcionales definidos en la etapa de anlisis.
El tiempo de carga de una web es importante de conocer, ya que puede que la pgina
est cargndose de forma muy lenta haciendo que muchos usuarios se pierdan algunos
contenidos, que este consumiendo muchos recursos, que tenga demasiados enlaces, o im-
genes muy pesadas, por lo que es bueno hacerle un test de velocidad.
Para comprobar la velocidad de carga de las pginas web de la aplicacin, he utilizado

la herramienta online Pingdom (http: // tools. pingdom. com/ fpt/ ).
sta lo que hace es probar la pgina web por completo rastreando todo el contenido a
travs del cdigo HTML (es capaz de detectar imgenes, CSS, Javascripts, RSS, Flash y
frames/iframes), imitando la manera en la cual se cargara la web normalmente. Adems
genera un grfico bastante sencillo de entender donde se ve la evolucin de carga en
segundos de cada uno de los archivos de la web, el cual nos permite saber cul es el origen
de una posible carga lenta y a qu archivo se debe. Posee un funcionamiento bastante
sencillo, ya que tan solo hay que ingresar la URL para obtener el test.
En la tabla 6.1 muestro los tiempos de carga de diferentes pginas web que componen
la aplicacin, pudindose observar que tardan menos de un segundo, aunque hay algunas
que se podran optimizar ms.
A modo de ejemplo voy a ensear un anlisis completo para la url http://gadeirart.

heroku.com/catalogo (figura 6.5).
Figura 6.4: Herramienta Pingdom
Perf. Load Page

Web URL grade Request time size
(ms) (kB)
Inicio /inicio 58/100 31 775 456.7
Quienes somos /galeria/nosotros/1 56/100 26 600 386.6
Catlogo /catalogo 57/100 32 674 420.5
Condiciones /galeria/condiciones/index_usuario 55/100 24 340 249.7
Contactar /contactar 56/100 25 661 253.5
Obra /catalogo/show/11 56/100 26 854 345.0
Imagen Obra /catalogo/show_photo/11 56/100 26 729 522.7
Artista /galeria/artista/3 54/100 26 632 251.9
Obras recientes /catalogo/latest 59/100 37 823 390.8
Bsqueda /catalogo/search 58/100 32 711 436.5
Bsqueda concreta /catalogo/search?utf8. . . 60/100 29 995 405.5
Registrarse /users/new 55/100 24 345 249.6
Iniciar Sesin /user_sessions/new 55/100 24 415 249.8
Olvid contrasea? /password_resets/new?locale=es 56/100 25 664 251.1
Cesta de la compra /carrito/index 53/100 25 365 249.8
Facturar /checkout/index 100/100 1 603 957.0
Administracin /admin/administracions 55/100 24 286 249.2
Listado Artistas /galeria/artista 49/100 30 717 256.8
Mostrar artista /galeria/artista/3 54/100 26 290 251.9
Editar artista /galeria/artista/3/edit 56/100 27 714 254.3
Traducir artista /admin/traduccionartista/3/edit 57/100 26 348 252.6
Listado colecciones /admin/coleccions 50/100 29 675 255.7
Listado sesiones /admin/seccions 50/100 29 735 255.4
Listado tcnicas /admin/tecnicas 50/100 29 640 255.6
Listado obras /admin/obras 51/100 35 873 333.9
Pedido /admin/pedido/show?id=1 55/100 25 487 251.7
Tabla 6.1: Velocidad de carga dentro de http://gadeirart.heroku.com/

Figura 6.5: Velocidad de carga para la url http://gadeirart.heroku.com/catalogo
Podemos ver que esta herramienta nos ensea visualmente, en un grfico de barras
(figura 6.6), el tiempo, mostrndonos la lista de objetos en el orden en que se van cargando
jerrquicamente. Esto nos permite ver los objetos que estn siendo linkeados. Un ejemplo
de los grficos obtenidos pueden contemplarlo a continuacin:
Cada test de lafigura 6.7 muestra estadsticas generales acerca de la carga de la pgina,
as como el nmero total de objetos, tiempo de carga y tamao de todos los objetos
incluidos.
He realizado un segundo anlisis y para estas pruebas he optado por New Relic (https:
//newrelic.com/), la cual es una plataforma para el monitoreo y anlisis del rendimiento
de aplicaciones que es ofrecida como un servicio en la web.
Para poder hacer uso de ella he aadido:
una nueva gema, newrelic_rpm, en el fichero Gemfile de la aplicacin y
el archivo de su configuracin newrelic.yml en el directorio config, obtenido

a travs de la web de la plataforma.
A partir de este momento, los agentes del lenguaje envan mtricas de la aplicacin
monitoreada a New Relic cada minuto, mientras se navega por las diferentes pginas
de la web. Para ver esta informacin de rendimiento, incluyendo un anlisis detallado
de las sentencias SQL, hay que abrir New Relic en el navegador (http://localhost:
3000/newrelic) y obtenemos la informacin de la figura 6.8.
Tambin se pueden visualizar los detalles, por ejemplo, para la cuarta de las URLs
que aparecen, /es/galeria/artista, en la figura 6.8. Ello lo vemos representado en la
figura 6.9.
Y contemplar, por ejemplo para la misma URL, el rendimiento obtenido por las sen-
tencias SQL que ejecuta (figura 6.10).
Un resumen lo obtenemos en la siguiente imagen 6.11.

Figura 6.6: Velocidad de carga para la url http://gadeirart.heroku.com/catalogo

Figura 6.7: Anlisis de la url http://gadeirart.heroku.com/catalogo
Figura 6.8: Monitorizacin de la aplicacin en modo de desarrollo

Figura 6.9: Detalles de la URL /es/galeria/artista
Figura 6.10: Detalles de las sentencias SQL en la URL /es/galeria/artista

6.5. PRUEBAS DE ACEPTACIN 189
Figura 6.11: Resumen para la URL /es/galeria/artista
Podemos observar en las imgenes anteriores, que hay rendimientos, marcados en rojo,
los cuales deberan ser optimizados para obtener unos mejores resultados en la aplicacin,
esto lo voy a dejar como una de las mejoras para realizar de la aplicacin. Tambin
comentar que dependiendo del navegador y del hardware que se utilice se pueden obtener
diferentes rendimientos.
6.5. Pruebas de aceptacin
El objetivo de estas pruebas es validar el sistema de desde el punto de vista funcional

y operativo.
Para la realizacin de estas pruebas, he solicitado al cliente1 y a varios usuarios ajenos

al desarrollo, que accedan a la web desde sus entornos de trabajo, realicen varias pruebas
sobre la aplicacin y verifiquen su eficacia.
El resultado de estas pruebas ha sido un producto exitoso, logrando la aprobacin por

parte de todos.
De esta manera, el producto est listo para su paso a produccin.
1
Parte III
Eplogo
191
193
En esta ltima parte de la memoria se recogen las conclusiones y los

manuales necesarios para el manejo de la tienda virtual.
194
Captulo 7
Manual de usuario
7.1. Introduccin
Este manual proporciona una gua para el usuario de la tienda virtual de la Galera
de Arte GadeirArt, detallndose las funcionalidades de la aplicacin. Los lectores no
requieren ningn conocimiento acerca de programacin ni desarrollo de software.
Veremos el funcionamiento de la aplicacin desde los siguientes roles:
Administrador cuyo objetivo ser administrar la aplicacin web.
Usuario final cuyo fin ser visualizar las obras de arte de la Galera y comprarlas
en caso de estar interesado.
7.2. Caractersticas
La aplicacin consiste en un sistema web formado por:
1. Un Front Office, con el que interactuarn los usuarios, formado por una Tienda
Online. Aqu podrn acceder al catlogo de las Obras de Arte y realizar sus compras.
2. Un Back Office, espacio restringido que permitir al administrador gestionar toda

la informacin del sistema.
195
196 CAPTULO 7. MANUAL DE USUARIO
Las funcionalidades que ofrece el sistema estn definidas en la seccin 3.2.1 Historias
de usuario y son las siguientes:
Gestin de Artistas: La Galera poseer informacin de cada uno de los Artistas.
Gestin de Colecciones: Poseer informacin de cada una de las Colecciones de Arte

que posea.
Gestin de Obras: Poseer informacin de cada una de las Obras de Arte que tenga
en su inventario.
Gestin de Secciones: La Galera de Arte clasificar sus obras en diferentes Seccio-

nes.
Gestin de Tcnicas: Cada una de las Secciones posee una serie de Tcnicas con las
que se realizan las Obras de Arte.
Gestin de Catlogo: El Catlogo servir para que el usuario1 pueda consultar la

relacin de obras que posee la Galera, as como la ficha tcnica de cada una de ella.
Gestin de Cesta de la Compra: En ella el cliente podr ir aadiendo cada una de

las obras de arte que desee comprar.
Gestin de Etiquetado: El Etiquetado tendr dos fines para la Galera de Arte:
Poder tener las obras de arte clasificadas por categora de forma que el usuario
pueda acceder a dicha clasificacin.
Recomendar obras relacionadas cuando los usuarios estn navegando por la
ficha tcnica de una obra.
Gestin de Seguridad: La Galera necesita que solo el usuario Administrador sea

el que pueda administrar la aplicacin evitando as algn que otro mal para la
empresa. Para realizar la compra los visitantes debern identificarse como clientes,
o registrarse si todava no tienen cuenta.
Gestin de Facturacin: Posee un sistema de procesamiento para los pedidos de sus

clientes a travs de una pasarela de pago.
Gestin de Internacionalizacin: Las pginas pueden verse tanto en espaol como

en ingls, para as poder acaparar una mayor clientela.
Gestin de Quienes Somos: Mediante este pgina el usuario acceder a la descripcin

de la actividad de la galera.
Gestin de Condiciones: Mediante este men el usuario acceder a las condiciones

generales de la galera.
1
Usuario: Visitante o Cliente
7.3. REQUISITOS PREVIOS 197
7.3. Requisitos previos
Los usuarios debern disponer de un ordenador que posea una tarjeta de red o una
tarjeta de red inalmbrica y un punto de acceso que les permita una conexin a Internet
para poder acceder a la aplicacin.
Tambin necesitarn la utilizacin de un navegador web para que la aplicacin pueda

ser visualizada, no siendo necesario el uso de uno especfico debido a que la aplicacin
esta adaptada para poder ser visualizada en la mayora de los navegadores disponibles.
7.4. Utilizacin
Cualquier navegante podr acceder a la web desde un navegador a travs de la direc-

cin: http://gadeirart.heroku.com/.
No hacer falta estar registrado para visualizar los contenidos de la tienda, pero s ser
necesario para poder comprar.
Figura 7.1: Captura del pgina de inicio
En cada una de las pginas de la web existir un men principal desde el que se
puede acceder a todas las funcionalidades presentes en la aplicacin segn el rol que
tenga asignado el usuario.
7.4.1. Administrador
El usuario administrador es el encargado de gestionar toda la informacin del sistema.

Sus funcionalidades se ejecutan en la interfaz de administracin.
7.4.1.1. Logarse como administrador y modificar sus datos
Para tener acceso a ella, el administrador deber logarse desde el enlace Registro/Ac-
ceso clientes (figura 7.1) con los siguientes datos iniciales:
Figura 7.2: Captura de la identificacin del administrador
Una vez registrado le aparecer una barra de men (figura 7.3), similar al del resto
de usuarios, con una opcin ms: Administracin, desde la que podr gestionar toda
la informacin de la web.
Tambin podemos ver en la imagen 7.3 que aparece un link llamado Mi cuenta que
mostrar al administrador sus datos (figura 7.4). Desde l podr modificar su clave de
acceso haciendo click sobre el botn Editar y rellenando el formulario que se presenta
(figura 7.5).
7.4. UTILIZACIN 199
Figura 7.3: Captura del men del administrador
Figura 7.4: Captura de los datos del administrador

Figura 7.5: Captura de la edicin de los datos del administrador
7.4.1.2. Panel de administracin
Desde el panel de administracin (figura 7.6), el administrador tendr acceso a una

serie de funcionalidades:
Figura 7.6: Captura del panel de administracin

7.4. UTILIZACIN 201
El panel de administracin aparece dividido en tres partes:
Gestores de contenido
Artistas: Contendr cada una de las funcionalidades de los artistas de la

Galera.
Colecciones: Desde aqu se podr administrar cada una de las colecciones de
las obras de arte.
Secciones: Las diferentes categoras de las obras de arte (dibujo, escultura,
pintura, fotografa...)
Tcnicas: Cada una de las tcnicas en que se dividen las secciones anteriores.
Obras: Obras de arte que posee la Galera.
Etiquetas: Etiquetas con las que estn clasificadas las obras de arte.
Gestores de clientes
Usuarios: Usuarios registrados en la Galera y su informacin.

Pedidos: Cada uno de los pedidos realizados a la Galera por los clientes junto
con su informacin.
Gestores generales
Quienes somos: La funcionalidad de este apartado es la de describir la acti-

vidad de la Galera.
Condiciones generales: Sirve para redactar cada una de las condiciones
generales de la Galera.
Dentro de ellos, el usuario administrador podr administrar todas las funcionalidades

de cada uno de los apartados de la galera haciendo click sobre la opcin que desee en el
panel de administracin.
7.4.1.3. Listados
Cuando hacemos click en algunas de las opciones de los gestores anteriormente co-
mentados, accedemos al listado de la opcin elegida. Por ejemplo, el listado de los artistas
se obtiene haciendo click sobre el botn Artistas (figura 7.7).
Figura 7.7: Captura de la pantalla de administracin de artistas
Voy a explicar la funcionalidad de cada uno de los botones que vemos en la pantalla
anterior u otras.
Botn Nuevo: Sirve para dar de alta a nuevos artistas de la Galera de Arte.
Para ello tendr que rellenar cada uno de los campos solicitados en el formulario
que se presenta.
Botn Mostrar: Podr visualizar los datos del artista.
Botn Editar: Sirve para editar y modificar la informacin del artista.
Botn Eliminar: Para eliminar el artista seleccionado.
Botn Traducir al ingls: Desde el que podr traducir al ingls, a travs de un

formulario, cierta informacin del artista.
Botn Retroceder: Retrocede a la pgina anterior.

7.4. UTILIZACIN 203
Dar un nuevo alta
El administrador podr dar un nuevo alta (de artista, de obras, colecciones. . . ) ha-
ciendo click en el listado, o dentro de cualquier otra pantalla, sobre el botn Nuevo.
Aparecer una nueva ventana que contiene un formulario en el que hay que rellenar todos
los campos que sean obligatorios y tras pulsar el botn se realizar un nuevo alta (figura
7.8).
Figura 7.8: Captura de la pantalla de dar de alta una nueva coleccin
Mostrar
Para tener acceso a la informacin sobre las nuevas altas haremos click sobre el botn
Mostrar que aparece en el listado o dentro de cualquier otra pantalla (figura 7.9).
En esta pantalla tambin tenemos una serie de botones que podemos utilizar para la
administracin.
Figura 7.9: Captura de la pantalla que muestra los datos de una obra
Editar
Para editar la informacin tan solo hay que pulsar sobre el botn Editar que aparece
en el listado o dentro de cualquier otra pantalla. Aparecer una nueva pantalla contenien-
do la informacin, pudiendo modificar la que deseemos. Para que las modificaciones se
lleven a cabo habr que hacer click sobre el botn Actualizar.
Figura 7.10: Captura de la pantalla de edicin de una tcnica

7.4. UTILIZACIN 205
Eliminar
Para eliminar debemos hacer click sobre el botn Eliminar que aparece en el lis-
tado y aparecer una ventana emergente que nos preguntar si deseamos o no hacer la
eliminacin.
Figura 7.11: Captura de la pantalla de confirmacin de eliminacin
Traducir al ingls
El administrador podr traducir algunos de los campos para que la informacin pueda
ser transmitida al usuario final en dos idiomas: espaol e ingls.
Para ello tendr que pulsar sobre el botn Traducir al ingls que aparece en el listado
(figura 7.9) o dentro de cualquier otra pantalla. Una vez traducido y tras pulsar el botn
Traducir (figura 7.12), podr ver como le ha quedado la traduccin.
Figura 7.12: Captura de la pantalla de traduccin

7.4.1.4. Bsqueda de obras de arte
En el listado de las obras de arte aparecer la siguiente pantalla similar a la de la

figura 7.7, pero se observa que tiene una parte nueva, la bsqueda:
Figura 7.13: Captura de ejemplo de bsquedas de obras
donde el administrador podr realizar bsquedas rellenando cualquiera de los cam-

pos del formulario que aparecen a la derecha de la pgina (figura 7.13) o seleccionando
cualquiera de las secciones. Para que se lleve a cabo, se deber pulsar sobre el botn Bus-
car y a continuacin aparecern todas las obras de arte que cumplen con los criterios
seleccionados.
El botn Limpiar sirve para eliminar las opciones elegidas para la bsqueda.
7.4.1.5. Gestores de clientes: Pedidos
Para acceder a la administracin de los pedidos de los clientes, el administrador deber

hacer click sobre la opcin Pedidos del panel de administracin (figura 7.6).
7.4. UTILIZACIN 207
Figura 7.14: Captura del listado de pedidos de los clientes
En la figura 7.14, vemos que presenta varias Vistas del estado: todos, procesado,
cerrado, fracasado. Segn la vista que seleccione aparecer el listado de los pedidos de
esa opcin.
Todos: Mostrar todos los pedidos de los clientes.
Procesado: Pedidos que estn en proceso y an no han sido enviados al cliente.
Cerrado: Pedidos que ya se han enviado al cliente.
Fracasado: Pedidos que por alguna razn han fracasado en su registro.

El usuario Administrador podr visualizar toda la informacin referente al pedido de

un cliente. Para ello tan solo tendr que hacer click sobre el botn Mostrar de la pantalla
7.14.
Figura 7.15: Captura pantalla de informacin de un pedido
El botn Cerrar pedido se pulsar una vez se haya enviado el pedido al cliente, con
lo que el estado del pedido cambiar a Cerrado como podemos ver en la figura 7.14.
7.4.2. Usuario de la tienda
7.4.2.1. Registrarse en la tienda virtual
Un usuario annimo tiene la posibilidad de registrarse como cliente de la tienda

virtual, para ello deber acceder a la pantalla de registro desde el enlace Registro/Acceso
clientes que aparece en cualquier pantalla.
7.4. UTILIZACIN 209
Figura 7.16: Captura pantalla de registro de nuevo cliente
En la figura 7.16 deber hacer click en el botn Registrarse, teniendo acceso a la

siguiente pantalla:
Figura 7.17: Captura pantalla de datos de identificacin para el registro
donde es obligatorio insertar todos los campos marcados con * y tras completar la
informacin solicitada se dar de alta al usuario en la tienda virtual. ste recibir un
correo electrnico de notificacin de registro.
Figura 7.18: Captura pantalla conteniendo la informacin del usuario registrado
7.4.2.2. Modificacin de los datos de usuario
Cualquier usuario que se encuentre logado en la web puede modificar sus datos. Para
ello deber pulsar el link Mi cuenta de cualquier pantalla y luego, en la pantalla que
aparece, sobre el botn Editar (figura 7.18 ).
Al pulsar accedemos a la zona donde el usuario puede modificar todos sus datos. Para
ello basta con modificar los datos disponibles y pulsar sobre el botn Actualizar usuario
(figura 7.19).
7.4.2.3. Catlogo
Para acceder al catlogo de la tienda virtual de la Galera, deber hacer click (figura
7.20) sobre el men Catlogo que aparece en cualquiera de las pginas.
7.4.2.4. Obras recientes de la galera
Podemos tener acceso a las ltimas adquisiciones de la Galera haciendo click sobre el
link Obras recientes que aparece dentro del catlogo (figura 7.21).
7.4. UTILIZACIN 211
Figura 7.19: Captura pantalla de edicin de datos de identificacin del usuario
Figura 7.20: Captura del catlogo

Figura 7.21: Captura de las obras recientes de la galera
7.4.2.5. Bsqueda de obras de arte
La bsqueda de obras de arte se realizar desde el link Bsqueda que nos encontramos
dentro del catlogo de obras (figura 7.20).
En la pantalla de figura 7.22 podremos realizar las bsquedas rellenando cualquiera

de los campos del formulario que aparecen a la derecha de la pgina o seleccionando
cualquiera de las secciones. Para que se lleve a cabo, se deber pulsar sobre el botn
Buscar y a continuacin aparecern todas las obras de arte que cumplen con los criterios
seleccionados.
El botn Limpiar sirve para eliminar las opciones elegidas para la bsqueda.
7.4.2.6. Consulta y seleccin de obras de arte
En este apartado se definen las posibles acciones que se pueden realizar sobre las obras
de arte de la Galera obtenidos a travs de la bsqueda o en el catlogo de la Galera.
7.4. UTILIZACIN 213
Figura 7.22: Captura pantalla de bsqueda de obras de arte
Obras que posee la galera
Independientemente de cmo se han obtenido los listados de obras de arte que posee
la galera, siempre se muestran de la siguiente forma:
Figura 7.23: Captura la apariencia de una obra de arte
y con los siguientes datos que cabe destacar:
Foto de la obra: La foto puede ampliarse pulsando sobre ella.
Ttulo de la obra: Pulsando sobre l tenemos acceso a toda la informacin de la obra

de arte.
Figura 7.24: Captura de la pantalla con la informacin de la obra
Artista: Haciendo click sobre el artista podr visualizar informacin sobre ste.
Cesta de la compra: Para comprar la obra hay que aadirla a su cesta de la compra
y para ello bastara con hacer click sobre ella.
Ver informacin de la obra
Para ver la informacin de la obra basta con pulsar sobre el ttulo de la obra que
aparece en la pantalla como la de la figura 7.23.
Pulsando sobre alguna de las etiquetas de la obra accedemos a un listado de todas las
obras que contienen dicha etiqueta.
Podemos observar que aparte de ver la informacin sobre la obra nos aparece a la
derecha una serie de recomendaciones de obras (figura 7.24).
Ver foto de la obra ampliada
Para poder ver las fotos ampliada basta con pulsar sobre la imagen, se abrir una
nueva ventana donde se visualizar la imagen de la obra de arte en un tamao superior
(figura 7.25).
7.4. UTILIZACIN 215
Figura 7.25: Captura de la imagen de la obra ampliada
Ver informacin del artista
Para ello basta con hacer click sobre el nombre del artista que aparece en la pantalla
como la de la figura 7.23 y se mostrar una nueva ventana con toda la informacin sobre
ste.
Aadir una obra a la cesta de la compra
Para aadir una obra de arte a nuestra cesta de la compra tenemos que pulsar sobre
la imagen del carrito como el que vemos en la figura 7.23.
En la figura 7.26 se nos muestra la cesta de la compra conteniendo las obras que
deseamos comprar junto con su importe.
7.4.2.7. Cesta/carrito de la compra
Desde el link Mi cesta, disponible en cualquier pantalla si se est logeado, se puede

acceder a ver la cesta de la compra (figura 7.27).
El usuario puede seguir aadiendo lneas pulsando sobre el botn Ir al catlogo o

eliminarlas pulsando sobre el botn Borrar.
Figura 7.26: Captura de la cesta de la compra
7.4.2.8. Realizar el pedido
Para realizar el pedido hay que pagar el contenido de la cesta, para acceder a esta
zona hay que pulsar sobre el botn Comprar que se encuentra en la cesta de la compra.
Logarse en la web
Para poder realizar el pedido hay que estar logado en la web.
Para ello tenemos el enlace Registro/Acceso clientes que aparece en cualquier panta-
lla y que nos enva a la pgina donde poder realizarlo. A esta pgina (figura 7.28) tambin
se accede si el usuario no esta logado y pulsar sobre el botn Comprar en la cesta de la
compra.
Introduccin de datos personales y confirmacin del pedido
Si el usuario est logado en la tienda virtual de la Galera, sus datos aparecen au-
tomticamente y estos podrn ser modificados en caso de que los datos de facturacin
varen.
7.4. UTILIZACIN 217
Figura 7.27: Captura de la cesta de la compra
Figura 7.28: Captura la pgina para logarse

Tras indicar todos los datos necesarios hay que seleccionar la forma de pago con la
que se desea pagar y pulsar el botn Continuar para realizar el pedido.
Figura 7.29: Captura de la forma de pago
Tras rellenar los datos, si son necesarios, para la forma de pago y pulsar sobre el botn
Realizar el pedido, se muestra un resumen de los datos indicados para que el usuario
confirme el pedido pulsando sobre el botn Comprar. De esta manera el pedido ya se
ha enviado a la Galera, la cual recibir un email con los datos del pedido y el usuario
recibir otro de confirmacin de pedido.
Forma de pago
Como se muestra en la figura 7.29, el usuario tiene varias formas de pago para el
pedido.
Pago con tarjeta: Si selecciona esta opcin aparecer la siguiente pantalla en la

que deber rellenar los datos de su tarjeta de crdito.
Figura 7.30: Captura del pago mediante tarjeta de crdito
Transferencia bancaria / ingreso en efectivo: Si selecciona est opcin le

aparece una pantalla con la informacin necesaria para la realizacin mediante est
forma de pago.
7.4. UTILIZACIN 219
Figura 7.31: Captura del pago mediante transferencia bancaria/ingreso en efectivo
7.4.2.9. Quienes somos
Si deseamos conocer la actividad de la galera tendremos que pulsar sobre el men

Quienes somos (figura 7.32) que aparece en cualquiera de las pginas de la tienda
virtual.
7.4.2.10. Condiciones generales
Para conocer las condiciones generales (figura 7.33) de la Galera tendremos que hacer
click sobre el men Condiciones que aparece en cualquiera de las pginas de la web.
7.4.2.11. Contactar
Obtener la informacin para poder contactar con la Galera de Arte (figura 7.34), se
hace desde el men Contactar de la barra de mens.
A travs del enlace de Google map se tendr acceso al mapa con la localizacin
exacta de la Galera.
Figura 7.32: Captura de quienes somos
Figura 7.33: Captura de las condiciones generales

7.4. UTILIZACIN 221
Figura 7.34: Captura de como contactar con la galera
7.4.2.12. Cambiar de idioma
El usuario tendr la funcionalidad de poder cambiar el idioma de la interfaz web en

cualquier momento. Para ello tendr los siguientes botones en cualquier pantalla.
Figura 7.35: Captura del botn para cambiar la pgina a ingls
Figura 7.36: Captura del botn para cambiar la pgina espaol

Pulsando sobre ellos automticamente la pgina web cambiar al idioma seleccionado.
Figura 7.37: Captura del catlogo traducido

Captulo 8
Manual de instalacin y explotacin
8.1. Introduccin
Este manual proporciona una gua para la instalacin y explotacin del sistema desa-
rrollado para la galera de arte GadeirArt.
8.2. Requisitos previos
Los requerimientos que el sistema debe tener para el correcto funcionamiento. Entre
parntesis pondr la versin con la que yo he trabajado.
S.O.: Ubuntu (Ubuntu Linux 11.04)
Lenguajes: Ruby (v. 1.8.7)
Gestor de paquetes: RubyGems
Framework: Rails (v. 3.0.9)
Base de datos: MySql (MySql Server Versin 5.1.54 - 1ubuntu4)
Cliente de subversion: Svn.
223
224 CAPTULO 8. MANUAL DE INSTALACIN Y EXPLOTACIN
8.3. Inventario de componentes
A continuacin se muestran los componentes software que se incluyen en la versin

del producto y donde se pueden localizar dentro de la aplicacin:
Gemas. La configuracin de las gemas se encuentran dentro del fichero Gemfile.
Modelos. Carpeta app\models.
Vistas. Carpeta app\views.
Controladores. Carpeta app\controllers.
Tests. Carpeta test.
8.4. Procedimientos de instalacin
Descarga de la aplicacin
Lo primero que tendremos que hacer ser bajarnos la ltima versin del repositorio de
nuestra aplicacin, para ello ejecutaremos el siguiente comando desde la lnea de consola:
$>svn co http://subversion.assembla.com/svn/pitig/
Instalar libreras adicionales
Como se ha indicado anteriormente en la seccin 8.2 Requisitos previos, se deber

tener instalados Rails, Ruby y MySql. An as, puede que necesitaremos de ciertas libreras
adicionales que permiten un correcto funcionamiento de las gemas. La instalacin de las
mismas se encuentra recogida en el script librerias.sh.
Para instalarlas nos situamos en el directorio donde se ha descargado la aplicacin

pitig y entramos en el subdirectorio galeriaArte, y ejecutamos el script librerias.sh.
$>bash librerias.sh
echo " I n s t a l a r OpenSSL para Ruby"

sudo aptg e t i n s t a l l l i b r u b y
echo " I n s t a l a r L i b r e r i a s a d i c i o n a l e s para N o k o g i r i "

sudo aptg e t i n s t a l l l i b x s l t 1 dev l i b x m l 2 dev
8.4. PROCEDIMIENTOS DE INSTALACIN 225
echo " I n s t a l a r L i b r e r i a de Java "

sudo aptg e t i n s t a l l d e f a u l t j dk
echo " I n s t a l a r L i b r e r i a a d i c i o n a l para P a p e r c l i p "

sudo aptg e t i n s t a l l imagemagick
Cdigo 8.1: Contenido del fichero librerias.sh
Instalar la aplicacin
Volvemos a situarnos en el subdirectorio galeriaArte del directorio pitig, ejecutando

posteriormente el script instalacion.sh:
$>bash instalacion.sh
Este realizar los siguientes pasos:
Instalar las gemas necesarias.
Eliminar las bases de datos.
Crear y actualizar las nuevas BBDD (cargndose el fichero de rdenes .sql incluido
en instalacion.sh).
Crear las rutas necesarias.
Iniciar el servidor.
#! / b in / bash
echo "##########################"
echo "## I n s t a l a c i o n de Gemas ##"
echo "##########################"
e x p o r t PATH=${PATH} : / var / l i b /gems
sudo bundle i n s t a l l
# N e cesi tamos l a c o n t r a s e n a de MySQL

echo "##########################"
echo "## Entrar en MySQL ##"
echo "##########################"
# Ahora vamos a e l i m i n a r l a s b a s e s de d a t o s a n t e r i o r e s
# para p o s t e r i o r m e n t e c r e a r l a s y a c t u a l i z a r l a s
echo "> E l i m i n a c i o n de l a BD"
r a k e db : drop : a l l
# Leer c o n t r a s e n a de MySQL
echo " I n t r o d u z c a su c o n t r a s e n a de r o o t para MySQL: "
mysql u r o o t p < . / db/ o r d e n e s . s q l
echo "> Creando BD"

rake db : c r e a t e RAILS_ENV=development
echo "> A c t u a l i z a n d o BD"
rake db : m i g r a t e RAILS_ENV=development
echo "> Poblando BD"
rake db : f i x t u r e s : l o a d
echo "> Cargando t e s t "
rake db : t e s t : l o a d
# Crear l a s r u t a s
echo "> Creamos l a s r u t a s "
rake routes
# Iniciamos el servidor
echo "> I n i c i a n d o s e r v i d o r de l a a p l i c a c i o n "
echo "##########################"
echo "## A b r i r a p l i c a c i o n ##"
echo "##########################"
f i r e f o x h ttp : / / l o c a l h o s t : 3 0 0 0 &
r a i l s server
Cdigo 8.2: Contenido del fichero instalacion.sh
8.5. Procedimientos de operacin y nivel de servicio
A continuacin voy a describir algunos procedimiento necesarios para asegurar el

correcto funcionamiento de la aplicacin en su mquina local.
Configuracin del entorno
En Ruby on Rails tenemos tres tipos de entornos (ver seccin 5.2 Cdigo fuente),
cada uno de los cuales ayuda a desarrollar las aplicaciones de una forma ms cmoda y
eficiente, ayudando en el ciclo de desarrollo:
8.5. PROCEDIMIENTOS DE OPERACIN Y NIVEL DE SERVICIO 227
Development: Entorno de desarrollo.
Test: Entorno para pruebas.
Production: Entorno de produccin.
Para cambiar de entorno debemos abrir el archivo config/environment.rb y reem-

plazar:
RAILS_ENV = ENV[RAILS_ENV] || production
por:
RAILS_ENV = development
Configuracin de las Gemas
Para respetar la configuracin existente, en primer lugar compruebe que tiene todas
las gemas instaladas.
La siguiente orden se encarga de comprobar las gemas e instalar las que faltan:
$>bundle install
Configuracin de la BD
Las bases de datos con las que puede interactuar la aplicacin se especifican en el
archivo de configuracin config/database.yml.
El archivo contiene secciones para los diferentes entornos en los que Rails se puede
ejecutar de forma predeterminada. ste trae una configuracin de BD predeterminada
utilizando SQLite3, as que debe de ser modificado ya que se ha elegido como BD MySQL.
El fichero de configuracin database.yml deber quedar de la siguiente manera:
development :
a d a p t e r : mysql
database : galeriaArte_development
username : g a l e r i a A r t e
password : hacked
encoding : utf8
test :
adapter : mysql
database : galeriaArte_test
password : hacked
encoding : utf8
production :
adapter : mysql
database : galeriaArte_production
password : hacked
encoding : utf8
Cdigo 8.3: Contenido del fichero database.yml
Como se ha indicado anteriormente en la seccin 8.2 Requisitos previos, deber tener

instalado MySql como gestor de BBDD.
Se debe otorgar permisos al usuario galeriaArte sobre las bases de datos: galeriaAr-
te_development y galeriaArte_test. Esta asignacin de privilegios se consigue, si el servi-
dor es la mquina local, con las ordenes:
mysql>grant all on galeriaArte_development.* to galeriaArte@localhost

identified by hacked;
mysql>grant all on galeriaArte_test.* to galeriaArte@localhost

identified by hacked;
8.6. Pruebas de implantacin
Acceso a la aplicacin
Desde nuestro navegador preferido, debemos introducir la URL:
http://localhost:3000
En caso de que el script instalacion.sh (descrito en el prrafo 8.4 Instalar la apli-

cacin) haya abierto el navegador, es recomendable recargar la pgina, ya que hay que
esperar que se cargue Rails.
8.6. PRUEBAS DE IMPLANTACIN 229
Vemos como se carga la pgina de inicio de la aplicacin:
Figura 8.1: Captura del pgina de inicio

Captulo 9
Conclusiones
En este ltimo captulo se detallan las lecciones aprendidas tras el desarrollo del
presente proyecto y se identifican las posibles oportunidades de mejora sobre la aplicacin
desarrollada.
9.1. Objetivos
Los objetivos que me marque al comienzo de este proyecto (seccin 1.2 Propsito,
objetivos y alcance del proyecto) han sido ms que satisfactorios, tanto en el plano personal
como en el profesional. Quera:
Aprender a desarrollar, implementar y poner en marcha una aplicacin Web

que pueda tener una utilidad comercial, empleando la herramienta de desarrollo
Ruby on Rails y los conocimientos adquiridos durante la carrera.
Esto se ha logrado como se puede comprobar a travs de:
las aplicaciones Web desarrolladas utilizando Ruby on Rails,

esta memoria en la que se describe todo el trabajo llevado a cabo para conseguir
el desarrollo completo de la aplicacin,
la herramienta que he utilizado para llevar el control del desarrollo y la coor-
dinacin de las actividades de mi proyecto, Assembla.
https://www.assembla.com/spaces/pitig/
231
232 CAPTULO 9. CONCLUSIONES
Adaptar la aplicacin a distintos requisitos permitindome obtener otra a un me-

nor coste. Satisfecho a travs de la aplicacin generada para el Artista reutilizando
gran parte del cdigo de la aplicacin de la Galera de Arte.
Realizar un anlisis comparativo del framework Ruby on Rails frente a otras al-
ternativas, evaluando las ventajas y caractersticas de este respecto a otros. Com-
placido con el estudio realizado en la memoria en el apartado 3.6 Estudio de alter-
nativas tecnolgicas.
La aplicacin realizada responde a las expectativas y requerimientos recogidos en la

especificacin de requisitos en el captulo 3.
9.2. Lecciones aprendidas
En esta seccin se detallan las buenas prcticas adquiridas, un anlisis de mtricas, una
comparacin cuantitativa del tiempo y el esfuerzo invertido y por ltimo, los problemas
encontrados durante el desarrollo del proyecto.
9.2.1. Buenas prcticas
Ha sido muy satisfactorio involucrarme en el proyecto completo, ya que he tenido

que desempear el papel de varios roles: jefe de proyecto, administrador de BBDD y
analista/programador, aprendiendo en cada uno de ellos algo nuevo.
He aprendido a Planificar y Gestionar un proyecto, llegando a la conclusin de que

es bastante difcil cumplir con unas fechas sino se ha estudiado, analizado y planificado
todos sus riesgos.
He puesto en prctica los pequeos conocimientos adquiridos durante el Taller de

LATEX, impartido por la Escuela, y he obtenido otros muchos realizanco esta memoria.
Durante el desarrollo he aprendido a programar utilizando un nuevo entorno de desa-

rrollo Ruby on Rails. Esto me ha llevado bastante tiempo al principio, ya que he tenido
que aprender su funcionamiento y su estructura para poder comenzar, pero luego he ido
aprendiendo a la vez que iba desarrollando la aplicacin.
Ahora puedo destacar lo cmodo y sencillo que resulta el adaptarse a este framework,
el cual facilita y acelera la funcin del desarrollador mediante unas configuraciones de
inicio muy efectivas, una estructura muy clara y, sobre todo, el uso de un lenguaje que
resulta realmente intuitivo y funcional como es Ruby.
9.2. LECCIONES APRENDIDAS 233
9.2.2. Mtricas
En esta seccin voy a mostrar las mtricas realizadas sobre la aplicacin.
9.2.2.1. Mtricas del producto
A continuacin podr visualizar algunas de las estadsticas del sistema software a

travs de la aplicacin StatsSVN (encontrar ms en la carpeta estadisticas_svn
contenida en el CD adjunto) y el anlisis de estadsticas de cdigo incluido dentro de
Ruby On Rails.
En la figuras 9.1, 9.2, 9.5, 9.4, 9.3 y 9.6 podemos ver las estadsticas de cdigo clasi-
ficadas segn extensin y ordenados por el nmero de lneas de los directorios principales
de la aplicacin.
Figura 9.1: Estadsticas del repositorio del directorio app
Figura 9.2: Estadsticas del repositorio del directorio config
Figura 9.3: Estadsticas del repositorio del directorio public

Figura 9.4: Estadsticas del repositorio del directorio lib
Figura 9.5: Estadsticas del repositorio del directorio db
Figura 9.6: Estadsticas del repositorio del directorio test
En la figuras 9.7 podemos ver el anlisis del cdigo fuente segn la estructura del
proyecto realizado en Ruby On Rails [Fowler, Martin].
Figura 9.7: Estadsticas del cdigo fuente Rails

A continuacin pasamos a describir los trminos que aparecen en la figuras 9.7 para
una mejor interpretacin de la misma:
Lines: Lneas de cdigo totales de cada una de las categoras.

LOC: Lneas de cdigo reales no autogeneradas por el framework.
Classes: Nmero de clases pertenecientes a cada una de las categoras.
Methods: Nmero de mtodos correspondientes a cada una de las categoras.
M/C: Media de mtodos por clase.
LOC/M: Media de nmero de lneas por mtodo.
A travs de estas estadsticas se deduce que es mucho ms factible programar utili-

zando el framework que hacer la aplicacin desde el comienzo sin ste, ya que se ahorra
tiempo y lneas de cdigo que nos facilita Ruby on Rails.
9.2.2.2. Mtrica del proceso
A continuacin se recoge una comparacin cuantitativa del tiempo y el esfuerzo real-

mente invertido frente al estimado y planificado. Estos datos han sido recogidos a travs de
Assembla (https://www.assembla.com/spaces/pitig/), el sistema de gestin de tareas
empleado para el seguimiento del presente proyecto.
He tenido en cuenta los siguientes parmetros:
Das a la semana: 5
A continuacin, en la figura 9.8, muestro el total de horas invertidas en el proyecto

y desarrollo de la presente memoria, equivalente a 60 semanas (20h/semana).
En la imagen 9.9, en el Sprint 14, podemos ver el total de horas invertidas en el

desarrollo de la presente memoria equivalente, aproximadamente, a 20 semanas
(20h/semana).
Visto lo anterior, podemos observar que he empleado en el desarrollo del proyecto

808,50h. equivalentes, aproximadamente, a 40 semanas de trabajo (20h/semana). Estas
horas se han sacado descontando el no de horas invertidas en la memoria (imagen ??) del
no de horas invertidas en total: proyecto y memoria (imagen 9.8).
En la figura 9.9 muestro, mas detalladamente, las horas estimadas e invertidas por
hitos, junto con el no de tickets empleados en cada uno de los sprints y en la figura 9.10
muestro su respectiva grfica.
Figura 9.8: Total de horas invertidas en el proyecto y memoria (Assembla)
Se observa que las horas estimadas para la realizacin del proyecto son 1.440h,
equivalentes, aproximadamente, a 72 semanas de trabajo (20h/semana).
A continuacin muestro el nmero de horas invertidas cada mes en el desarrollo del

proyecto y de la memoria.
Figura 9.11: Horas invertidas cada mes (Assembla)

Figura 9.9: Horas estimadas e invertidas por hitos (Assembla)
Figura 9.10: Grfica de horas por hitos (Assembla)

El esfuerzo realizado durante el proyecto tambin est recogido en la carpeta chan-

gelog del CD adjunto, la cual contiene el trabajo que he ido desarrollando cada da, es
decir, los cambios ejecutados en el proyecto.
19/ a b r i l /2012
Obras C o n t r o l a d o r Destroy
C o l e c c i o n e s C o n t r o l a d o r Destroy
M o d i f i c a c i n para que no s e b o r r e s i t i e n e o b r a s a s o c i a d a s
S e c c i o n e s C o n t r o l a d o r Destroy
M o d i f i c a c i n para que no s e b o r r e s i t i e n e o b r a s u
tcnicas asociadas
T e c n i c a s C o n t r o l a d o r Destroy
A r t i s t a s C o n t r o l a d o r Destroy
Actualizacin changelog
Memoria B i b l i o g r a f a
Memoria C a p t u l o 4 Implementacin Gemas
MetaSearch
Memoria C a p t u l o 4 A n l i s i s H i s t o r i a s de u s u a r i o s
Obras y Catlogo
Catalogo Busqueda con gema metasearch
Obras Busqueda con gema metasearch
Catalogo E l i m i n a c i n de l o r e l a c i o n a d o con gema s u n s p o t
Memoria C a p t u l o 4 Implementacin Gemas
Eliminacin sunspot
Catalogo Bsqueda Aadido botn l i m p i a r f o r m u l a r i o
Obras Bsqueda Aadido botn l i m p i a r f o r m u l a r i o
Bsqueda de i n f o r m a c i n s o b r e c o n t e n e d o r e s con p e s t a a s
en R a i l s
18/ a b r i l /2012
Catalogo Recomendaciones M o d i f i c a c i o n e s
Obras Busqueda con gema metasearch
Obras Gema meta_search I n v e s t i g a c i n
Obras , a r t i s t a s , c o l e c c i o n e s , s e c c i o n e s , t c n i c a s
M o d i f i c a c i n botn new en i n d e x
Secciones Integridad r e f e r e n c i a l
Cdigo 9.1: Extracto del contenido del fichero Changelog

Resumiendo, puedo comentar que he estimado ms o menos el nmero de semanas ne-

cesarias para la realizacin del proyecto y de la memoria. Teniendo en cuenta, que en este
estudio estn contabilizadas las 10 semanas (20h/semana) que invertir prximamente
para la realizacin de la presentacin del proyecto.
(20h/semana) (40h/semana)
Semanas estimadas 72 semanas 36 semanas
Semanas invertidas 60 semanas 30 semanas
Desviacin temporal 12 semanas 6 semanas
Tabla 9.1: Estudio del tiempo del proyecto
Para concluir, la experiencia ha sido muy grata junto con un aprendizaje muy completo
y satisfactorio.
9.2.2.3. Amortizacin del desarrollo de la aplicacin
A partir de ahora, una vez realizada la primera aplicacin, puedo generar cualquier
aplicacin web a medida para galeras y/o artistas con un coste menor , amortizando
el importe de la realizacin de la aplicacin para la Galera de Arte.
Para mostrarlo he desarrollado una segunda aplicacin, consistente en una Tienda

Virtual para un Artista (http://artista.herokuapp.com/), adaptando la realizada para
la Galera de Arte a nuevos requisitos.
Con esto quiero demostrar la ventaja de construir una nueva aplicacin, partiendo
y reutilizando el cdigo de otra, respecto al coste y el tiempo empleado inicializndola
desde cero.
A continuacin se recoge una comparacin cuantitativa del tiempo y el esfuerzo in-

vertido en la aplicacin. Estos datos tambin han sido recogidos a travs del sistema de
gestin Assembla (https://www.assembla.com/spaces/pitig_artista/).
He tenido en cuenta, al igual que antes, los siguientes parmetros:
Das a la semana: 5
En la imagen 9.12 muestro el total de horas invertidas en la aplicacin para el

Artista.
Figura 9.12: Total horas invertidas en la aplicacin para el artista (Assembla)
He reutilizado la mayora del cdigo de la aplicacin desarrollada para la Galera de

Arte: controladores, vistas, modelos . . . ya que la aplicacin viene a ser similar, cambian-
do tan solo unos cuantos requisitos. Por ejemplo, he creado un nuevo modelo para las
exposiciones del Artista junto con su controlador y sus vistas; se ha cambiado la vista del
catlogo; en lugar de mostrarse el apartado Quienes somos de la Galera se muestra el
curriculum de la Artista, con lo que este cdigo se ha ampliado para satisfacer este requi-
sito, modificndose tambin con ste la pgina de inicio de la aplicacin; se ha quitado el
apartado de contactar y algunas otras pequeas modificaciones . . .
Horas invertidas para:
Web de la Artista: 2 semanas (20h/semana), equivalentes a 1 semana (40h/se-

mana)
frente a
Web de la Galera: 30 semanas(40h/semana), equivalentes aproximadamente a 7

meses
Podemos comprobar que he ganado bastante reutilizando gran parte del cdigo de la
Galera de Arte para la nueva aplicacin, ya que tanto el coste como el tiempo empleado
es menor. De esta forma, cada vez que cree una aplicacin para una Galera y/o Artista
ir amortizando el coste de la primera aplicacin desarrollada.
Recopilando, tenemos en cuenta los siguientes parmetros para el clculo de la segunda

aplicacin:
Personas implicadas en el proyecto: 1
Das a la semana: 5
Horas invertidas por da: 8h.
Semanas empleadas: 1 semana.

A continuacin, podemos ver el coste de la aplicacin para el artista recogida en la

siguiente tabla:
Nombre Descripcin Tipo Coste Total

Personal cualificado
Personal Humano 2.375e/mes 593,75e/semana
y especializado
Equipo
PC e impresora Activo 42e/mes 10,5e/semana
informtico
Costes 10 % del coste
Tinta, luz. . . Material 59,37e/semana
indirectos del personal
Total 663,62e
Tabla 9.2: Costes del proyecto para la aplicacin del Artista
Comparativa del coste entre ambas aplicaciones (ver seccin Costes 2.5):
Nombre Coste Total Galera Total Artista

(30 semanas) (1 semana)
Personal 2.375e/mes 16.625e 593,75e/semana
Equipo 42e/mes 294e 10,5e/semana
Costes 10 % del personal 1.662,5e 59,37e/semana
Total 18.581,50e 663,62e
Tabla 9.3: Comparativa de costes de ambas aplicaciones
9.2.2.4. Estudio de la usabilidad de la aplicacin
Para medir la usabilidad de la aplicacin contar con la colaboracin de varios usuarios,

entre ellos con la galerista y voy a tener en cuenta las siguientes variables:
Efectividad: Me permite medir la exactitud con la que se alcanzan los objetivos de

una tarea concreta. En este caso voy a medir el porcentaje total de tareas completadas
por el usuario y la dificultad en realizarla.
Eficiencia: Se refiere al esfuerzo que un usuario tiene que hacer para conseguir un
objetivo. Medir el tiempo empleado en completar cada tarea.
Satisfaccin: Medir el grado de satisfaccin de los usuarios.
Tras realizar a los usuarios un pequeo test (Anexo I) con siete tareas, he obtenido
los siguientes resultados reflejados en los siguientes grficos. Los resultados de los test
podemos visualizarlos en la carpeta usabilidad contenida en el CD adjunto.
Todos los usuarios han conseguido completar las diferentes tareas que se les ha reco-
mendado en el test de usabilidad.
La media de dificultad con que se han encontrado los usuarios al realizar cada una de
las tareas la podemos ver en el grfico 9.13.
Figura 9.13: Test usabilidad - Dificultad
La grfica 9.14 muestra la media de tiempo (expresada en minutos) empleado por

todos los usuarios para completar cada una de las 7 tareas.
Figura 9.14: Test usabilidad - Tiempo empleado

A continuacin, en el grfico 9.15 vemos reflejado la media de satisfaccin de los

usuarios en cada una de las tareas realizadas.
Figura 9.15: Test usabilidad - Satisfaccin
9.2.3. Problemas encontrados
Voy a destacar algunos de ellos aunque, durante todo el desarrollo, me he ido encon-
trando con problemas que he ido solventando poco a poco.
Uno de los problemas que me encontr fue que tras tener implementada la bsqueda de
obras de arte a travs de la gema Sunspot, la cual me llevo bastante tiempo estudiar como
funcionaba y obtener su funcionamiento en mi aplicacin, me encontr que al realizar el
despliegue en Heroku1 no me permita utilizar esta gema ya que para poder hacerlo haba
que pagar por no ser de libre uso. Para solucionarlo opte por usar otra gema MetaSearch,
la cual tambin me resulto bastante til.
Otro problema similar fue el espacio donde guardar las imgenes de los artistas y
las obras de arte de la Galera, tambin en Heroku haba que pagar por este servicio de
alojamiento, as que finalmente pude solucionar el problema utilizando el servicio dropbox
para alojar las imgenes.
Lo que no he conseguido solventar ha sido el poder aadir las tasas correspondientes

al porte del pedido, ya que quise hacerlo a travs de la empresa UPS2 y tras tenerlo
1
Heroku: Servicio de Hosting en la nube
2
UPS: Compaa de transporte
implementado a falta de unos datos que me tena que facilitar la empresa y ponerme en
contacto con ellos, no podan facilitarmelos porque tena que ser cliente de la empresa.
As que lo he dejado como ampliacin para un trabajo futuro donde buscara otra forma
de poder facilitar automticamente las tasas al cliente.
Tambin me encontrado con warnings provenientes de las gemas utilizadas, en donde

se advierte que se est utilizando una orden que ya es obsoleta en las nuevas versiones y
que habra que sustituir. Para solventarlo habra que estudiar donde ocurre en las gemas
y eso no est contemplado dentro del proyecto, ya que llevara bastante tiempo debido a
que las gemas estn programadas por otros.
Finalmente, he tenido que solventar algunas vulnerabilidades en heroku, lo cual me

ha llevado un tiempo curioso ya que me ha bloqueado hasta la aplicacin.
9.3. Trabajo futuro
Para futuras ampliaciones se podra realizar:
La implementacin del seguimiento del pedido por parte del cliente.
El pago a travs de una cuenta paypal del propio usuario.
Implementar las tasas correspondientes al porte del pedido.

Captulo 10
Anexos
A continuacin se recogen cada uno de los anexos a la presente memoria de mi Proyecto

de Fin de Carrera.
245
246 CAPTULO 10. ANEXOS
A. ACRNIMOS 247
A. Acrnimos
AIR (Adobe Integrated Runtime).
AJAX JavaScript asncrono y XML (Asynchronous JavaScript And XML).
API Interfaz de Programacin de Aplicaciones (Application Programming
Interface).
B2C Del negocio al consumidor (Business-to-Consumer).
BD Base de Datos (DataBase).
BBDD Bases de Datos (DataBases).
CRUD Crear, Obtener, Actualizar y Borrar (Create, Read, Update and Dele-
te).
CSS Hojas de Estilo en Cascada (Cascading Style Sheets).
DOM Modelo de Objetos del Documento (Document Object Model).
DRY No te repitas (Dont Repeat Yourself).
DSL Lenguaje Especfico de Dominio (Domain-Specific Language).
E/R Entidad/Relacin (Entity relationship).
EER Entidad-Relacin Mejorado (Enhanced Entity-Relationship).
GNU GNU No es Unix (GNU is Not Unix).
GPL Licencia Pblica General de GNU (GNU General Public License).
HTML Lenguaje de Marcado de HiperTexto (HyperText Markup Language).
HTTP Protocolo de Transferencia de Hipertexto (Hypertext Transfer Proto-
col).
i18n Internacionalizacin (Internationalization).
IEEE Instituto de Ingenieros Elctricos y Electrnicos (Institute of Electrical
and Electronics Engineers).
JSP (JavaServer Pages).
MIT Instituto Tecnolgico de Massachusetts (Massachusetts Institute of
Technology).
MVC Modelo-Vista-Controlador (Model-View-Controller).
ORM Mapeo Objeto-Relacional ( Object-Relational Mapping).
PDF Formato de Documento Porttil (Portable Document Format).
PERT Programa o Proyecto de Evaluacin y Revisin Tcnica (Program (or
Project) Evaluation and Review Technique).
PHP (Hypertext Pre-processor).
png (Portable Network Graphics).
POO Programacin Orientada a Objetos.
RBS Estructura de desglose de recursos (Resource Breakdown Structure).
RoR Ruby on Rails.
SGBD Sistema de Gestin de Base de Datos.
SMTP Protocolo Simple de Transferencia de Correo (Simple Mail Transfer Pro-
tocol).
SQL Lenguaje de Consulta Estructurado (Structured Query Language ).
TCP/IP Protocolo de Control de Transmisin (Transmission Control Proto-
col)/Protocolo de Internet (Internet Protocol).
TDD Desarrollo Guiado por Pruebas (Test-Driven Development).
UTF-8 (8-bit Unicode Transformation Format).
VPS Servidor Privado Virtual (Virtual Private Servers).

W3C (World Wide Web Consortium).
WBS Estructura de Desglose del Trabajo (Work Breakdown Structure).
XML Lenguaje de Marcas eXtensible (eXtensible Markup Language).
YAML YAML no es otro lenguaje de marcado (YAML Aint Markup Langua-
ge).
B. DEFINICIONES 249
B. Definiciones
ActiveRecord Patrn de diseo que permite crear un objeto que envuelve una tabla
SQL, agregndole la lgica del modelo y el control de acceso. Este patrn permite
unir el mundo de la programacin orientada a objetos (POO), que es un mundo
intuitivo y natural, con el mundo matemtico y rgido de los datos relacionales
(SQL).
Administrador del Sistema Persona que tiene la responsabilidad de ejecutar, man-

tener, operar y asegurar el correcto funcionamiento de la aplicacin.
AJAX Tcnica de desarrollo web para crear aplicaciones interactivas.
Andamiaje (Scaffold) es poder realizar todas las operaciones que se nos pide con tan
solo definir la entidad.
API Conjunto de funciones y procedimientos (o mtodos, en POO) que ofrece cierta

biblioteca para ser utilizado por otro software como una capa de abstraccin.
Assembla Es una herramienta web que permite el control de desarrollo y la coordinacin

de las actividades de un proyecto.
B2C Estrategia que desarrollan las empresas comerciales para llegar directamente al
cliente o usuario final. En la prctica, suele referirse a las plataformas virtuales
utilizadas en el comercio electrnico para comunicar empresas (vendedoras) con
particulares (compradores). Por eso, el uso ms frecuente es Comercio electrnico
B2C.
Base de datos Conjunto de datos pertenecientes a un mismo contexto y almacenados

sistemticamente para su posterior uso.
Changelog Archivo que lista los cambios hechos a un proyecto informtico desde su
ltima versin.
Comercio electrnico Tambin conocido como e-commerce (electronic commerce),

consiste en la compra y venta de productos o de servicios a travs de medios elec-
trnicos, tales como Internet y otras redes informticas.
Control de versiones Gestin de los cambios que se realizan sobre los elementos de
un producto facilitando la administracin de las mismas.
CRUD Hace referencia a las funciones bsicas en bases de datos: crear, obtener, actua-
lizar y borrar
CSS Tecnologa que permite crear pginas web con un diseo ms exacto, aadien-
do mayores posibilidades a HTML y permitiendo una mayor separacin entre la
informacin y la presentacin.
El W3C es el encargado de formular la especificacin de las hojas de estilo que
servirn de estndar para los agentes de usuario o navegadores.
Dia Editor de diagramas con las herramientas necesarias para crear o modificar grficos.
Diagrama de Gantt Herramienta grfica cuyo objetivo es mostrar, para la planificacin

del desarrollo de un proyecto, el tiempo de dedicacin previsto para diferentes tareas
o actividades a lo largo de un tiempo total determinado.
Diagrama PERT Este diagrama es una representacin grfica de las relaciones entre
las tareas del proyecto que permite calcular los tiempos de ste de forma sencilla.
DOM Interfaz de programacin de aplicaciones (API) que proporciona un conjunto es-

tndar de objetos para representar documentos HTML y XML, un modelo estndar
sobre cmo pueden combinarse dichos objetos, y una interfaz estndar para acceder
a ellos y manipularlos.
Dropbox Servicio de alojamiento de archivos multiplataforma, operado por la compaa

Dropbox. Este servicio permite almacenar y sincronizar archivos en lnea y entre
computadoras, y compartir archivos y carpetas con otros.
DSL Consiste en proporcionar a los clientes un lenguaje con una sintaxis y una semntica
ms conveniente para describir la solucin al tipo de problema al que se enfrentan.
Framework Conjunto de componentes que componen un diseo reutilizable que facilita

y agiliza el desarrollo de sistemas Web.
Forja Plataforma de desarrollo colaborativo de software enfocado hacia la cooperacin

entre desarrolladores para la difusin de software y el soporte al usuario.
Gemas Plugins y/o cdigos aadidos a nuestros proyectos RoR, que nos permiten nuevas
funcionalidades como nuevos create, nuevas funciones pre-escritas o nuevas herra-
mientas para el desarrollo.
GitHub Forja para alojar proyectos utilizando el sistema de control de versiones Git.
GNU Proyecto que promociona el desarrollo colaborativo de software y conocimiento

mediante el uso de licencias libres.
Helpers Mdulo que ayuda a las vistas definiendo funciones que devuelven cdigo
HTML.
Heroku Plataforma de hosting en la nube orientada a Rails.
Hipertexto Texto que en la pantalla de un dispositivo electrnico, permite conducir a

otros textos relacionados, pulsando con el ratn en ciertas zonas sensibles y desta-
cadas. La forma ms habitual de hipertexto es la de hipervnculos que van a otros
documentos.
Hosting en la nube El alojamiento web en la nube se asienta sobre una red de ser-
vidores vinculados para formar una sola plataforma. Debido a que hay una gran
cantidad de servidores trabajando en conjunto en lugar de uno solo, se equilibra la
carga, aumenta la capacidad, y se reduce al mnimo la probabilidad de fallo.
B. DEFINICIONES 251
HTML Lenguaje sencillo de hipertexto, es decir, un lenguaje que permite escribir texto
de forma estructurada, y que est compuesto por etiquetas, que marcan el inicio y
el fin de cada elemento del documento.
Con el hipertexto lo que se consigue realmente es especificar tanto la estructura
lgica del contenido como los diferentes aspectos que se desean dar a dicho conte-
nido. Sin embargo, el uso de CSS nos permite separar ambos conceptos: estructura
y aspecto visual.
HTTP Protocolo usado en cada transaccin de la World Wide Web.
IEEE Asociacin tcnico-profesional mundial dedicada a la estandarizacin.
ImageMagick Librera muy potente para realizar manipulaciones de imgenes.
Ingeniera del Software Aquella que ofrece mtodos y tcnicas para desarrollar y
mantener software de calidad.
ISO 3166 Estndar que codifica los nombres de pases y reas dependientes as como
sus principales subdivisiones.
Java Lenguaje de programacin orientado a objetos, desarrollado a principios de los

aos 90.
jQuery Biblioteca de JavaScript que permite simplificar la manera de interactuar con

los documentos HTML, manipular el rbol DOM, manejar eventos, desarrollar ani-
maciones y agregar interaccin con la tcnica AJAX a pginas web.
JSP Tecnologa Java que permite generar contenido dinmico para web, en forma de
documentos HTML, XML o de otro tipo.
LATEX Sistema de composicin de textos, orientado especialmente a la creacin de libros,

documentos cientficos y tcnicos que contengan frmulas matemticas.
Lgica de programacin Base sobre la cual se sustenta la programacin en si.
Mquina virtual Software que emula a una computadora y puede ejecutar programas
como si fuese una computadora real.
Metaprogramacin Consiste en escribir programas que escriben o manipulan otros

programas (o a s mismos) como datos, o que hacen en tiempo de compilacin parte
del trabajo que, de otra forma, se hara en tiempo de ejecucin.
Metodologa gil Marco de trabajo conceptual de la Ingeniera de Software que pro-

mueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto.
Metodologa de desarrollo de software Marco de trabajo usado para estructurar,

planificar y controlar el proceso de desarrollo en sistemas de informacin.
Mtrica del producto Medidas de producto Software durante cualquier fase de su

desarrollo desde los requisitos hasta la instalacin.
Mtrica del proceso Medidas del proceso de desarrollo del Software tales como tiempo
de desarrollo total, esfuerzo en das/hombre o mes/hombre de desarrollo del produc-
to, tipo de metodologa utilizada o nivel medio de experiencia de los programadores.
MIT Licencia que permite reutilizar el software as licenciado tanto para ser software
libre como para ser software no libre, permitiendo no liberar los cambios realizados
al programa original.
Modelo de negocio Planificacin que realiza una empresa respecto a los ingresos y
beneficios que intenta obtener. En un modelo de negocio, se establecen las pautas
a seguir para atraer clientes, definir ofertas de producto e implementar estrategias
publicitarias, entre muchas otras cuestiones vinculadas a la configuracin de los
recursos de la compaa.
MVC Patrn arquitectnico desarrollado para interfaces grficas que resalta la impor-
tancia de una separacin clara entre la presentacin de datos y la lgica de negocio
de una aplicacin.
MySql Sistema de gestin de bases de datos relacional, multihilo y multiusuario.
Navegador web Aplicacin que opera a travs de Internet, interpretando la informacin

de archivos y sitios web para que podamos ser capaces de leerla.
Open Source Calificacin de software que cumple una serie de requisitos, principalmen-
te aquel que permite una libre redistribucin, distribuye el cdigo fuente, y permite
modificaciones y trabajos derivados.
ORM Tcnica de programacin para convertir datos entre el sistema de tipos utilizado
en un lenguaje de programacin orientado a objetos y el utilizado en una base de
datos relacional, utilizando un motor de persistencia, que en Rails es ActiveRecord.
Patrones de diseo La base para la bsqueda de soluciones a problemas comunes

en el desarrollo de software y otros mbitos referentes al diseo de interaccin o
interfaces.
png Formato grfico basado en un algoritmo de compresin sin prdida para bitmaps.
PHP Es un lenguaje de programacin libre, multiplataforma e interpretado, diseado

para la creacin de pginas web dinmicas.
POO Paradigma de programacin que usa objetos y sus interacciones, para disear
aplicaciones y programas informticos. Est basado en varias tcnicas, incluyendo
herencia, abstraccin, polimorfismo y encapsulamiento.
Rails Framework de aplicaciones web de cdigo abierto, multiplataforma, distribuido

bajo la licencia del MIT.
Rake Equivalente a make para Ruby. Sirve para crear y automatizar tareas de mante-
nimiento.
B. DEFINICIONES 253
Refactorizacin Tcnica de la Ingeniera de Software para reestructurar un cdigo

fuente, alterando su estructura interna sin cambiar su comportamiento externo.
Reglas de negocio Describen las polticas, normas, operaciones, definiciones y restric-

ciones presentes en una organizacin y que son de vital importancia para alcanzar
los objetivos.
Repositorio Sitio centralizado donde se almacena y mantiene informacin digital, ha-

bitualmente bases de datos o archivos informticos.
REST Conjunto de principios arquitectnicos por los cuales se disean servicios web
haciendo foco en los recursos del sistema, incluyendo cmo se accede al estado de
dichos recursos y cmo se transfieren por HTTP hacia clientes escritos en diversos
lenguajes.
RESTful Sistemas que siguen los principios REST.
Ruby Lenguaje de script (no compilado), totalmente orientado a objetos, multiplata-

forma y de cdigo abierto.
RubyGems Gestor de paquetes para el lenguaje de programacin Ruby que propor-

ciona un formato estndar y autocontenido (llamado gem) para poder distribuir
programas o libreras en Ruby, una herramienta destinada a gestionar la instalacin
de stos, y un servidor para su distribucin.
Ruby on Rails Entorno de desarrollo web.
Screencast Grabacin digital de la salida por pantalla de la computadora, a veces

conteniendo narraciones de audio.
Scrum Marco de trabajo para la gestin y desarrollo de software basada en un proceso

iterativo e incremental utilizado comnmente en entornos basados en el desarrollo
gil de software.
SGBD Agrupacin de programas que sirven para definir, construir y manipular una
base de datos.
Sprint Perodo en el cual se lleva a cabo el trabajo en s.
SQL Lenguaje declarativo de acceso a bases de datos relacionales que permite especificar
diversos tipos de operaciones en estas.
TCP/IP Conjunto de protocolos de red en los que se basa Internet y que permiten la
transmisin de datos entre computadoras.
Tex Sistema de tipografa.
Tienda virtual Sitio web donde se pueden comprar productos y pagarlos por cualquier
medio electrnico.
UTF-8 Formato de codificacin de caracteres Unicode e ISO 10646.

WBS Herramienta fundamental en la gestin de proyectos. Es una descomposicin

jerrquica del trabajo que va a ejecutar el equipo de proyecto, para cumplir con los
objetivos de ste.
W3C Comunidad internacional que desarrolla estndares que aseguran el crecimiento

de la Web a largo plazo.
WinEdt Editor de texto potente y verstil para Windows con una fuerte predisposicin
hacia la creacin de documentos LATEX.
Wireframe Boceto que define el contenido y la funcionalidad de una web.
World Wide Web (WWW) Sistema de distribucin de informacin basado en hiper-

texto o hipermedios enlazados y accesibles a travs de Internet.
XML Formato estndar para el intercambio de datos basado en archivos de texto plano
con una estructura de etiquetas (tags).
YAML Formato para guardar objetos de datos con estructura de rbol.

C. GEMAS 255
C. Gemas
A continuacin describo las diferentes gemas que he utilizado para el desarrollo de la

aplicacin. El cdigo de cada una de ellas se puede localizar en GitHub.
Activemerchant [Luetke, Tobias; Fauser, Cody]: Esta gema ser utilizada

para la facturacin de los pedidos, ya que conecta con la pasarela de pago para
gestionar las transacciones de los clientes a travs de su tarjeta de crdito.
(https://github.com/Shopify/active_merchant).
Acts-as-taggable-on [Kramarenko, Artem]: Nos va a permitir aadir etiquetas

a las obras para poder realizar las recomendaciones de obras similares a los clientes.
(https://github.com/mbleigh/acts-as-taggable-on).
Authlogic [Johnson, Ben; ASCIIcasts]: Esta gema sirve para gestionar la au-
tenticacin en la aplicacin. Trabaja slo con el cdigo que gestiona la autenticacin
de los usuarios, ganando con ella flexibilidad y control acerca de cmo se presenta
sta al usuario.
(https://github.com/binarylogic/authlogic).
Authorize-net [Authorize.net]: Ser utilizada para la facturacin de los pedidos.

A travs de ella se gestiona la presentacin de las transacciones de pago a las redes
de procesamiento en nombre de los clientes. Esta basado en el Protocolo de Internet
(IP), permitiendo a los comerciantes autorizar, abonar y gestionar las transacciones
de cheques electrnicos y tarjetas de crdito desde una web.
(http://rubydoc.info/gems/authorize-net/1.5.2/frames).
Country-select [Koziarski, Michael; Dean Shepherd, James]: Nos propor-

ciona una lista de pases en la que se puede seleccionar uno. Esta lista est basada
en la norma ISO 3166. La utilizar para que el cliente pueda seleccionar su pas en
el momento de realizar la facturacin de su pedido.
(https://github.com/jamesds/country-select).
Globalize3 [Stachewicz, Tomasz]: Provee servicios para la internacionalizacin

y localizacin en Rails. Facilita el poder realizar traducciones sobre los modelos y
vistas de la aplicacin. Es compatible con la API I18n de Rails.
(https://github.com/svenfuchs/globalize3).
Mail [Lindsaar, Mikel; ASCIIcasts]: Es una biblioteca de Internet para Ruby

diseada para manejar de forma sencilla todas las funciones del correo electrnico.
Las acciones de red se realizan a travs de protocolos como: SMTP, POP3. . . Esta
gema es utilizada por Action Mailer para crear los servicios de e-mail.
(https://github.com/mikel/mail).
MetaSearch [Miller; Railscasts]: Esta gema aade una forma muy til de rea-
lizar bsquedas sobre un modelo desde un formulario.
(https://github.com/ernie/meta_search).
Newrelic_rpm: Es una sistema para el monitoreo y anlisis del rendimiento de

aplicaciones que es ofrecida como un servicio en la web.
(https://github.com/newrelic/rpm).
Paperclip [Sichanugrist, Prem; Moses]: Permite adjuntar archivos de cualquier

tipo a un modelo de ActiveRecord, concretamente, en mi aplicacin la he utilizado
para adjuntar las fotos de los artistas al modelo artistum y las fotos de las obras
de arte al modelo obra. Su implementacin ha sido sencilla ya que los archivos son
tratados como un atributo ms del modelo.
A continuacin veremos, a modo de ejemplo, como le he indicado al modelo obra
que deseo un archivo adjunto con el nombre de imagen.

....
### P a p e r c l i p Almacenamiento en Dropbox ###

h a s _ a t t a c h e d _ f i l e : imagen ,
: s t o r a g e => : Dropboxstorage ,
: path => " / : attachment / : i d / : s t y l e . : e x t e n s i o n " ,
: u r l => " / : attachment / : i d / : s t y l e . : e x t e n s i o n " ,
: s t y l e s => {
: thumb => "50 x50 #",
: medium => "100 x100 >",
: l a r g e => "300 x300>"
}
....
end
Cdigo 10.1: Implementacin de la gema Paperclip en el modelo obra
Esta gema no slo se encarga de guardar el archivo en nuestro servidor, sino tambin
crea automticamente thumbnails1 de esa imagen, las cuales me vienen muy bien
para la aplicacin. Para ello, Paperclip utilizar la librera ImageMagick2 que es la
realmente permite generar los thumbnails de las imgenes.
(https://github.com/thoughtbot/paperclip).
Paperclipdropbox [Ketelle, Paul]: Esta gema la he utilizado para poder tratar

la gema Paperclip mediante el servicio de alojamiento de archivos Dropbox.
(https://github.com/dripster82/paperclipdropbox).
1
Thumbnails: Vistas en miniatura.
2
ImageMagick: Librera para realizar manipulaciones de imgenes.
C. GEMAS 257
Will_paginate [Marohnic, Mislav]: Proporciona un mtodo que, a partir de un

conjunto de elementos y un nmero de elementos por pginas, limita automtica-
mente el nmero de elementos mostrado por cada pgina y aade un paginador.
(https://github.com/mislav/will_paginate/wiki).
D. LENGUAJE RUBY 259
D. Lenguaje Ruby
Ruby es un lenguaje de programacin creado, en el ao 1995, por el japons Yukihiro

Matsumoto (Matz), el cual lo ha enfocado a la simplicidad y a la productividad, lo que
favorece un desarrollo rpido y sencillo de aplicaciones. Presenta una sintaxis elegante y
natural, hacindolo muy fcil de leer y entender. Es un lenguaje de script (no compila-
do), totalmente orientado a objetos, multiplataforma y de cdigo abierto (open source,
software libre).
Ha combinado muchas de las caractersticas positivas de Perl, PHP, Java, C, Smalltak,

Lisp haciendo un lenguaje bastante potente para el desarrollo de aplicaciones.
Es considerado un lenguaje muy intuitivo casi a un nivel de lenguaje humano, aseme-

jndose al lenguaje natural, de esta forma hace que la experiencia de programacin sea
ms divertida.
La filosofa de Ruby es Dont repeat yourself (DRY) (No te repitas), es decir, la

idea de Ruby es que no necesitamos repetir lo que ya ha definido en otro lugar. Esto hace
a Ruby muy compacto.
A continuacin veremos algunas de las caractersticas ms importantes de Ruby.
Orientado a Objetos: Ruby es un lenguaje totalmente orientado a objetos, es

decir, que sigue estrictamente el paradigma de la Programacin Orientada a Objetos
(POO).
Herramientas de creacin de tareas y gestin de dependencias: Ruby dispo-

ne de una herramienta llamada Rake3 que permite la creacin de tareas repetitivas
y la gestin de dependencias de las tareas de mantenimiento.
Multiplataforma: Ruby dispone de dos implementaciones de intrpretes:
el oficial de Ruby, que es el ms utilizado,

y el JRuby, el cual es una implementacin realizada en Java que funciona en
una mquina virtual Java.
Ambas implementaciones del intrprete las podemos encontrar en multitud de sis-

temas operativos como: Linux, Mac OS X, Microsoft Windows, Windows CE y la
mayora de Unix. Adems desde la versin 1.9 Ruby ha sido portado a Symbian OS
9.x.
3
Rake es el equivalente a make de GNU para Ruby.
Entornos de desarrollo Web (Frameworks): Ruby dispone de diversos frame-

works para el desarrollo de aplicaciones Web. El ms famoso y ms completo es
Rails que junto con Ruby forman la plataforma de desarrollo Ruby on Rails, la
cual ha sido la escogida para realizar este proyecto.
Software Libre: Ruby dispone de una licencia GPL, creada por la Free Software
Foundation la cual hace que este lenguaje de programacin sea software libre y por
tanto, los usuarios tienen total libertad para ejecutar, copiar, distribuir, estudiar,
cambiar y mejorar el software.
Gestin automtica de memoria: Ruby dispone de un recolector de basura que

gestiona automticamente la reserva de memoria del ordenador. Gracias a la gestin
automtica de memoria no se ha de invocar ninguna subrutina para liberar espacios
de memoria ocupados, ya que es el propio intrprete de Ruby el que gestiona el ciclo
de vida de los objetos creados.
Generador de documentacin: Ruby dispone de un generador de cdigo por

defecto llamado Rdoc. Este parsea los archivos .rb, .rbw y .c del proyecto y busca
los comentarios situados encima de las definiciones de las funciones. Con estos datos
se crean archivos HTML, formando una fuente de documentacin de libreras muy
til a la hora de reutilizar cdigo.
Lenguaje Interpretado: Al ser un lenguaje totalmente interpretado, no requiere

ser compilado antes de ejecutarse, ya que la ejecucin del cdigo se realiza a tra-
vs de un intrprete que crea una representacin intermedia del cdigo que se va
compilando a medida que va a ser ejecutado.
Dinamismo: En Ruby, las clases nunca estn cerrada, esto quiere decir, que siempre
se pueden aadir nuevos mtodos a esta clase. Siendo vlido tanto para las clases
incluidas con el intrprete como para las nuevas clases escritas.
Tipado Dinmico: Ruby es un lenguaje de tipos dbiles, es decir, que las variables
que usa no tienen un tipo fijo y no es necesaria su declaracin para poder usarlas.
En Ruby, se confa menos en el tipo de un objeto y ms en sus capacidades, que
significa que el tipo de un objeto est definido por lo que puede hacer, no por lo
que es.
El tipado dinmico aporta flexibilidad a la hora de programar, ya que libera al
programador de la obligacin de tener que declarar todas las variables usadas en el
desarrollo del cdigo. Esto conlleva la creacin de programa con menor nmero de
lneas y en consecuencia un aumento de productividad. Pero se puede convertir en
una desventaja, ya que el uso del tipado dinmico puede comportar la generacin
de pequeos bugs difcilmente detectables hasta la ejecucin del programa. Por esta
razn, el desarrollo de aplicaciones en Ruby requieren que se creen multitud de test
para poder detectar el correcto funcionamiento del cdigo generado.
D. LENGUAJE RUBY 261
Sintaxis concisa, compacta: La Sintaxis de Ruby permite escribir bloques de

cdigo muy compactos y en un lenguaje muy humano. En consecuencia permite
crear programas con menor nmero de lneas de cdigo que se refleja en una menor
cantidad de puntos de posibles errores de tipado.
E. METODOLOGA GIL 263
E. Metodologa gil
Una Metodologa gil es una metodologa efectiva para modelar y documentar un

proyecto de software. La forman una coleccin de valores, principios y prcticas para
modelar software, que pueden ser aplicados de manera simple y ligera.
Esta metodologa tiene varios principios que la diferencian de las metodologas tra-
dicionales, los cuales estn reflejados en el Manifiesto gil [Beck, Kent; Beedle, Mike;
Bennekum, Arie; Otros] . Segn ste se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. Las personas son el principal factor de xito de un proyecto software.
Es mejor crear un buen equipo y que ste configure su propio entorno de desarrollo
en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena documenta-

cin. La regla a seguir es no producir documentos a menos que sean necesarios de
forma inmediata para tomar una decisin importante. Estos documentos deben ser
cortos y centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se propone

que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su
xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad

de responder a los cambios que puedan surgir a los largo del proyecto (cambios en
los requisitos, en la tecnologa, en el equipo, etc. . . ) determina tambin el xito o
fracaso del mismo. Por lo tanto, la planificacin debe ser flexible y abierta.
Los valores anteriores inspiran los doce Principios del Manifiesto [Beck, Kent;
Beedle, Mike; Bennekum, Arie; Otros]. Los dos primeros principios son generales y resu-
men gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo.
Metodologa gil SCRUM
Scrum fue desarrollado por Ken Schwaber, Jeff Sutherland y Mike Beedle y es un
marco de referencia para generar una metodologa gil. Su principal objetivo es llevar los
proyectos a su realizacin final cuando estn envueltos en entornos cambiantes, como es
el mundo del software y, especialmente, el entorno web.
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible
de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en el
estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, est especialmente indicado
para proyectos en entornos complejos, donde:
se necesita obtener resultados pronto,
los requisitos son cambiantes o poco definidos,
la innovacin, la competitividad, la flexibilidad y la productividad son fundamen-

tales.
Tambin se utiliza para resolver situaciones cuando:
no se est entregando al cliente lo que necesita,
las entregas se alargan demasiado,
los costes se disparan o la calidad no es aceptable,
se necesita capacidad de reaccin ante la competencia,
la moral de los equipos es baja y la rotacin alta,
es necesario identificar y solucionar ineficiencias sistemticamente o
se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.
La metodologa de Scrum se sustenta sobre tres principios de igual importancia: trans-

parencia, inspeccin y adaptacin.
Transparencia hace referencia a que todas las personas implicadas deben estar al
corriente de los cambios, contratiempos o impedimentos que surjan.
La inspeccin quedar cubierta por medio de las reuniones y trabajos en equipo

que plantea la metodologa, para detectar las desviaciones con la mayor brevedad
posible.
Adaptacin es uno de los principios bsicos de la metodologa gil y uno de los

objetivos por los que se aplica Scrum. Consiste en introducir los cambios que puedan
surgir con la menor implicacin a los objetivos del proyecto.
F. PRUEBAS EN RAILS 265
F. Pruebas en Rails
La comprobacin del buen funcionamiento de mi aplicacin en Rails la he desarrollado

mediante las pruebas que a continuacin describo:
Pruebas unitarias: Son una forma de probar el correcto funcionamiento de un

mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione
correctamente por separado. En Rails estas pruebas se aplican a relaciones entre
modelos, as como a sus validaciones.
Pruebas funcionales: Son unas pruebas basada en la ejecucin, revisin y retroali-

mentacin de las funcionalidades previamente diseadas para el software. En Rails
verifican los efectos de la llamada directa a un mtodo de un controlador.
Pruebas de integracin: Son aquellas que se realizan en el mbito del desarrollo

de software una vez que se han aprobado las pruebas unitarias. Es la fase en la cual
mdulos individuales de software son combinados y probados como un grupo. Sirven
para probar interacciones entre los elementos. En RoR se prueba la interaccin entre
los controladores.
G. RAILS 267
G. Rails
Rails es un framework de aplicaciones web de cdigo abierto, multiplataforma y

distribuido bajo la licencia del MIT. En otras palabras, es una serie de utilidades y de
herramientas para crear aplicaciones web ms rpidamente que hacindolo desde cero.
Fue desarrollado por el dans David Heinemeier Hansson, como una herramienta
para facilitarse el trabajo al programar la aplicacin web Basecamp para la empresa
37 Signals. En julio de 2004 liber el cdigo como software libre, y en febrero de 2005
comenz a aceptar colaboraciones para mejorar Rails, formndose un amplio equipo de
programadores, el Core Team.
Rails utiliza el lenguaje Ruby siguiendo el paradigma de la arquitectura Modelo-

Vista-Controlador (MVC) el cual explicar ms adelante (ver prrafo 4.1.2 Arquitectura
MVC en Rails de la pgina 104).
Trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del

mundo real escribiendo menos cdigo que con otros frameworks y con un mnimo de
configuracin.
El lenguaje de programacin Ruby permite la metaprogramacin, de la cual Rails hace

uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible.
Rails se distribuye a travs de RubyGems, que es el formato oficial de paquete y canal

de distribucin de bibliotecas y aplicaciones Ruby.
Caractersticas de Rails
Algunas de las caractersticas de RoR son:
Arquitectura MVC.
Aprovecha la Metaprogramacin de Ruby.
Simplicidad.
Posee un potente motor de generacin de cdigo.
Conexin a varios motores de BD.

Manejo de cambios a BD a travs de migraciones.
No usa directamente SQL en las consultas a BBDD (pero se puede).
AJAX integrado (jQuery).
Gran cantidad de Helpers (ayudantes) para generar elementos repetitivos.
Posee varias tareas Rake predefinidas.
Maneja el ruteo de manera fcil y dinmico.
Soporte integrado a Internacionalizacin (i18n) y Localizacin.
Soportes de Rails
Plataformas: GNU/Linux, Unix, FreeBSD, Mac OS X, Windows.
Bases de Datos: PostGreSQL, MySQL, Oracle, SQL Server, SQLite, IBM DB2.
Servidores Web: Webrick (Servidor integrado con Rails), Apache, Lighttpd.
Filosofa
La filosofa de Ruby on Rails, se basa en dos principios fundamentales de programacin:
Dont Repeat Yourself : Las definiciones solo deben de realizarse una nica vez,
pues los componentes estn integrados de manera que no hace falta establecer puen-
tes entre ellos. Cada pieza de conocimiento en un sistema, deber ser expresada en
un slo lugar.
Este principio se basa en escribir menos lneas de cdigo para implementar la apli-
cacin. Si el cdigo es pequeo quiere decir que el desarrollo es ms rpido y con
menos errores, lo que har que el cdigo sea fcil de entender, mantener y mejorar.
Un ejemplo de esto es el utilizado por el patrn ActiveRecord , Ruby no necesita que
se le especifiquen los campos (columnas) de un objeto, este es capaz de obtenerlos a
partir de la base de datos, de modo que no es necesario replicar dicha informacin
en el cdigo.
Convention Over Configuration: Gracias a este principio el usuario solo necesita

especificar aquellas clases que tienen un comportamiento diferente. Por ejemplo, si
en el modelo existe una clase Persona esta tendr su correspondiente tabla personas,
de modo que si queremos usar una clase con dicho comportamiento no debemos
especificar nada nuevo, a menos que queramos crear un nuevo tipo Mdico que
tenga aspectos que difieran de una Persona.
G. RAILS 269
Llevando ests dos sencillas reglas a la prctica, ser muy sencillo realizar aplicaciones
web funcionales, con una sencillez y claridad en el cdigo que no se puede hacer en otros
lenguajes.
Estructura de una aplicacin Rails
En la siguiente imagen podemos apreciar cmo se gestiona Rails internamente:
Figura 10.1: Diagrama de flujo de Rails
A continuacin voy a describir algunos de los mdulos que aparecen en la imagen:
Active Record: Es el mdulo que se encarga de la conexin entre la aplicacin

y la base de datos. La base de los modelos de datos. Proporciona independencia
de la BD, relaciona modelos, funcionalidad bsica CRUD, capacidad de bsqueda
avanzada, . . .
Action View: Este mdulo se encarga de renderizar los datos que el controlador
quiere mostrar al usuario. Su uso es mediante vistas que pertenecen a acciones del
controlador. Adems da la opcin de hacer subvistas para la eficiencia de nuestra
aplicacin. Otra cosa a tener en cuenta es la opcin de poner layouts, que son vistas
que son visibles para cualquier accin del controlador, o si lo ponemos en el principal
ser vista durante toda la web, salvo que no se quiera. Puede crear HTML y XML.
Action Controller: Es la base de la aplicacin. Maneja los controladores de la

aplicacin. Procesa peticiones, extrae parmetros y ejecuta.
Action Mailer: Es el mdulo encargado de crear servicios de email. Se puede usar

para enviar, recibir y procesar stos.
Su interfaz es sencilla gracias a una rpida configuracin del servidor (que veremos
ms adelante). Uno de sus puntos fuertes es poder crear vistas para las acciones de
email a mandar, se trabaja como si fueran vistas web que el sistema se encarga de
enviar a su destinatario.
Action WebServices: Es el mdulo que se encarga de las operaciones de WebSer-

vices de la aplicacin, si se desean utilizar. Lo que consigue es que se pueda llamar
a las acciones definidas en los controladores mediante llamadas al sistema y no a
travs de las vistas. Tiene sentido, el uso de este mdulo, cuando se quiere que la
aplicacin web puede ser accedida de forma directa por otro programa va internet.
WebServer: Servidores para el desarrollo y las pruebas, en mi caso utilizar WE-

Brick.
Herramientas y componentes tiles
Rails proporciona una serie de herramientas que nos facilitan las tareas comunes. Estas
son:
Scaffolding: Mtodo de meta-programacin que genera el modelo, vista y controla-

dor correspondiente a un recurso de la aplicacin en una sola operacin y de forma
automtica. Tratar esta herramienta un poco ms en la Seccin 5.2 Esqueleto para
la aplicacin de la pgina 139.
Rake [Fowler, Martin]: Herramienta de generacin o automatizacin de cdigo es-

crito en Ruby. Los Rakefiles4 utilizan la sintaxis del lenguaje Ruby con lo que no
es necesario aprender ninguna sintaxis especfica de herramientas de generacin de
cdigo.
WEBrick: Librera de Ruby que provee de un servidor HTTP sencillo, el cual es

utilizado para probar aplicaciones en un entorno de desarrollo.
4
Los Rakefiles equivalen a los Makefiles de Make.
G. RAILS 271
Para la creacin de aplicaciones web Rails posee los siguientes componentes, la mayora
de ellos descritos en la seccin anterior:
Active Record
Action View
Action Controller
Action Mailer
Action Resource: Es un framework que gestiona la conexin entre objetos de

negocio y RESTful [De Seta, Leonardo] web services. Implementa, con la semntica
CRUD, el mapeo entre estos.
Railties: Cdigo del ncleo de Rails que crea nuevas aplicaciones y las conecta con
los framework en una sola aplicacin.
Active Support: Gran coleccin de clases y extensiones de la biblioteca estndar

de Ruby.
Base de datos en Rails
Rails:
Soporta diferentes SGBDRs para almacenar los datos, incluyendo MySQL, Post-
greSQL, SQLite, IBM DB2 y Oracle. Por defecto tiene la biblioteca SQLite.
Gestiona los accesos a la base de datos automticamente, aunque si se necesita se

pueden hacer consultas directas en SQL.
Intenta mantener:
la neutralidad con respecto a la base de datos,

la portatibilidad de la aplicacin a diferentes sistemas de base de datos y
la reutilizacin de bases de datos preexistentes.
Sin embargo, debido a la diferente naturaleza y prestaciones de los SGBDRs el

framework no puede garantizar la compatibilidad completa.
H. RELACIN DE CASOS DE USO Y MOCKUPS 273
H. Relacin de Casos de Uso y Mockups
A continuacin muestro un listado que indica para cada Caso de Uso cual es el mockup
que lo implementa. stos estn contenidos en la carpeta mockups del CD adjunto.
CU de Gestin de Artistas
Los CU de Gestin de Colecciones, Secciones y Tcnicas son implementados me-
diante mockup similares a los de la Gestin del Artista.
listado_artistas
admin_edicion_artista
admin_ficha_artista
ficha_artista
CU de Gestin de Obras
listado_obras
ficha_obra
foto_obra
CU de Gestin de Catlogo
catalogo
busqueda
obras_recientes
CU de Gestin de Cesta de la Compra
cesta_compra
CU de Gestin de Etiquetas
listado_obras_por_etiquetas
CU de Gestin de Seguridad
identificacion
listado_usuarios
registro_datos_identificacion
registro_datos_personales
registro_datos_confirmacin
notificacion_registro_cliente
restablecer_contrasea_cliente
CU de Gestin de Facturacin
listado_pedidos
informacion_pedido
admin_mostrar_pedido
pago_tarjeta
transferencia_bancaria
confirmacion_pedido_cliente
solicitud_pedido_galeria
CU de Gestin de Internacionalizacin
admin_traduccion_artista
admin_traducir_artista
CU de Quienes somos
quienes_somos
CU de Condiciones
condiciones
Otros
inicio
panel_administracion
contactar
I. TEST DE USABILIDAD 275
I. Test de Usabilidad
Figura 10.2: Test de usabilidad

Captulo 11
Glosario de trminos
LATEX, 251 Desarrollo, 138

Produccin, 138
AIR, 131, 247 Pruebas, 138
Ajax, 247, 249 ERR, 247
Andamiaje, 249
API, 247, 249 Forja, 250
Arquitectura, 93, 103 Framework, 92, 250, 260
Fsica, 103
Lgica, 104 Gantt, 19, 250
Controlador, 104, 105, 148 gedit, 129
Modelo, 104, 140 Gema, 135, 227, 250, 255
Patials, 154 Activemerchant, 255
Vista, 104, 105, 153 Acts as taggable on, 255
Pull-based, 94 Authlogic, 157, 255
Push-based, 93 Authorize net, 255
Country select, 255
B2C, 13, 247, 249 Globalize3, 167, 170, 255
BBDD, 147, 247 I18n, 168, 247
BD, 123, 130, 227, 247, 249 ImageMagick, 251, 256
Mail, 255
C, 90
MetaSearch, 159, 243, 255
C++, 90
Newrelic_rpm, 256
Caso de uso, 51, 57
Catlogo, 6 Paperclip, 256
Changelog, 249 Paperclipdropbox, 256
Comercio electrnico, 249 Will_paginate, 257
Control de versiones, 131, 249 Gestor de versiones, 132, 133
CRUD, 140, 247, 249, 271 GitHub, 250
CSS, 107, 130, 156, 247, 249 GNU, 247, 250
GPL, 247, 260
Dia, 250
DOM, 247, 250 Herramienta, 130
Dropbox, 250, 256 Adobe Reader, 131
DRY, 247, 259 Assembla, 131, 249
DSL, 178, 247, 250 Balsamiq Mockups, 131
DSS, 125 Dia, 131
Dropbox, 132, 243
E/R, 78, 247 Firebug, 132
Entorno, 138 gedit, 132
277
278 NDICE ALFABTICO
Heroku, 133, 250 Administrador del sistema, 84, 198, 249

Git, 133 Analista, 26
MySql WorkBrench, 133 Cliente, 25
Nero, 134 Jefe de proyecto, 25
New relic, 185 Programador, 26
OpenProj, 19, 134 Supervisor, 24
Pingdom, 134 PERT, 247, 250
StatsSVN, 233 PHP, 91, 247, 252, 259
StatSVN, 134 png, 247, 252
Subversion, 132 POO, 247, 252, 259
WindEdt, 135 Prestashop, 96
WinEdt, 254 Pruebas, 11, 173, 265
Herramienta:Pingdom, 183 Aceptacin, 189
Hipertexto, 250 Fixtures, 173
Hosting, 250 Funcionales, 181, 265
HTML, 103, 130, 247, 251 Implantacin, 228
HTTP, 103, 247, 251 Integracin, 178, 265
No funcionales, 183
IEEE, 247, 251
Unitarias, 265
Ingeniera del software, 251
Pruebas:Unitarias, 174
ISO 3166, 251
Java, 91, 251, 259 Rails, 27, 94, 101, 129, 252, 260, 267
jQuery, 251, 268 Action controller, 270
JSP, 247, 251 Action mailer, 160, 270
Action Pack, 105
LOC, 235 Action resource, 271
Action view, 269
Mquina virtual, 251 Action webservices, 270
Mtrica Active record, 140, 143, 249, 268, 269
Proceso, 252 Active support, 271
Producto, 251 Helpers, 250
Magento, 98 MVC, 247, 252, 267
Manifiesto gil, 263 Railties, 271
Metaprogramacin, 140, 251, 267 Rake, 252, 259, 270
Metodologa gil, 13, 251, 263 Rakefile, 139
Scrum, 14, 253, 263 Rakefiles, 270
Metodologa de desarrollo, 13, 251 Scaffold, 249
MIT, 247, 252 Scaffolding, 139, 270
Mockup, 108, 131 WEBrick, 268, 270
Modelo de negocio, 13, 252 WebServer, 270
Multiplataforma, 259 RBS, 247
MVC, 93, 104, 106, 125, 149 Refactorizacin, 253
MySql, 27, 83, 104, 130, 252, 268
Reglas de negocio, 84, 253
Repositorio, 253
Navegador, 252
REST, 253
Open source, 252, 259 RESTful, 253, 271
ORM, 247, 252 Riesgo, 29, 31, 3537
Oscommerce, 95 RoR, 129, 247
Ruby, 27, 91, 101, 129, 253, 259, 267
Pasarela de pago, 43, 164 JRuby, 259
Patrn de diseo, 252 Rdoc, 260
PDF, 247 RubyGems, 135, 253, 267
Perfil, 24 Ruby empotrado, 153
Administrador de BBDD, 26 Ruby on Rails, 129, 253, 260
NDICE ALFABTICO 279
Screencast, 253 UTF-8, 247, 253

SGBD, 247, 253
SMTP, 103, 162, 247 VPS, 248
Software libre, 260
Sprint, 14, 15, 18, 44, 253 W3C, 248, 254
SQL, 247, 253 WBS, 15, 248, 254
WEBrick, 103
TCP/IP, 247, 253 Wireframe, 131, 254
TDD, 247 WWW, 254
Tex, 253
Tienda virtual, 5, 253 XML, 248, 254
UML, 44, 78 YAML, 173, 248, 254

280 NDICE ALFABTICO
Bibliografa
AENOR (2002).
Norma espaola: UNE 157001. Criterios generales para la elaboracin de proyectos.
http://www.ehu.es/Degypi/General/norma157001.pdf.
Alarcos, UCLM-ESI. Grupo.
Gestin de riesgos en proyectos software.
http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/7/pgsi-t7.pdf.
ASCIIcasts.
160: Authlogic.
http://es.asciicasts.com/episodes/160-authlogic.
ASCIIcasts.
206: Action Mailer en Rails 3.
http://es.asciicasts.com/episodes/206-action-mailer-en-rails-3.
ASCIIcasts.
228: Sortable Table Columns.
http://asciicasts.com/episodes/228-sortable-table-columns.
ASCIIcasts.
240: Search, Sort, Paginate with AJAX.
http://asciicasts.com/episodes/240-search-sort-paginate-with-ajax.
Ataz Lpez, Joaqun (2006).
Gua casi completa de BIBTEX.
ftp://ftp.ctan.org/tex-archive/info/spanish/guia-bibtex/guia-bibtex.pdf.
Authorize.net.
Gema authorize-net.
http://rubydoc.info/gems/authorize-net/1.5.2/frames/.
AuthorizeNet (2011).
Merchant Web Services API. Automated Recurring BillingTM (ARB) XML Guide.
http://www.authorize.net/support/ARB_guide.pdf.
AVOS.
Delicious.
http://delicious.com/.
281
Beck, Kent; Beedle, Mike; Bennekum, Arie; Otros (2001a).
Manifesto for Agile Software Development.
http://agilemanifesto.org/.
Beck, Kent; Beedle, Mike; Bennekum, Arie; Otros (2001b).

Principles behind the Agile Manifesto.
http://www.agilemanifesto.org/principles.html.
Britt, James.
Module::Authlogic::I18n.
http://rubydoc.info/github/binarylogic/authlogic/master/Authlogic/I18n.
Brown, Mat.
Gema sunspot_rails.
https://github.com/outoftime/sunspot/tree/master/sunspot_rails.
BuenasTareas.com.
Patron Active Record.
http://www.buenastareas.com/ensayos/Patron-Active-Record/3226566.html.
Burgos Pintos, Aris; Cornejo Barrios, Alicia; Gmez Mellado, Antonio;

Otros (2010).
Taller de LATEX .
Center, AuthorizeNet. Developer.

AuthorizeNet.
https://github.com/binarylogic/authlogic.
Corporation, Oracle.
MySql.
http://dev.mysql.com/.
CraigsList (2012).
Craigslist Classifieds.
http://www.craigslist.org/.
De Seta, Leonardo (2008).

Introduccin a los servicios web RESTful.
http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-
restful.html.
Dodero, Juan Manuel.

DSLs en Ruby.
http://deki.uca.es/II_ApuntesRuby_on_Rails/Ruby_DSLs.
Fauser, Cody (2008).

PayPal Express Payments with ActiveMerchant.
http://www.codyfauser.com/2008/1/17/paypal-express-payments-with-
activemerchant.
282
Fowler, Martin (2006).
Rake: algunos comandos tiles.
http://dummyonrails.lacoctelera.net/post/2007/06/13/rake-algunos-comandos-utiles.
Franco Aquino, Rafael (2011).

Una introduccin a Ruby on Rails.
http://www.slideshare.net/movihus/rails-etyc-2011.
Fuchs, Sven.
Rails i18n.
https://github.com/svenfuchs/rails-i18n/tree/master/rails/locale.
Geeknet, Inc..
Documentation from Ruby Source Files.
http://rdoc.sourceforge.net/.
Geeknet, Inc..
freshmeat.net.
http://freshmeat.net/.
Global, Comercio Electrnico (2011).

Magento o Prestashop: Cul es el mejor software libre para tienda de comercio
electrnico?.
http://e-global.es/software-libre-de-comercio-electronico/magento-o-prestashop-icual-
es-el-mejor-software-libre-para-tienda-de-comercio-electronico.html.
Gmez Lpez, Rubn (2010).

PHP vs Java.
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=PHPVsJava.
Google.
Google Code.
http://code.google.com/.
Hartl, Michael (2010).

Ruby on Rails Tutorial. Learn Rails by Example.
Heinemeier Hansson, David.

Ruby on Rails.
http://rubyonrails.org/.
Hellsten, Christian; Laine, Jarkko (2006).

Beginning Ruby on Rails E-Commerce. Apress.
Heroku.
Getting Started with Heroku.
http://devcenter.heroku.com/articles/quickstart.
283
IEEE (1990).
IEEE Standard Glossary of Software Engineering Terminology.
http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.12-1990.pdf.
IEEE-SA (1998).
IEEE 830/1998. IEEE Recommended Practice for Software Requeriments Specifica-
tions.
http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirements-
specifications.
Indeed (2012).
Indeed.
http://www.indeed.com/.
Johnson, Ben.
Gema authlogic.
http://rubydoc.info/gems/authlogic/3.1.0/frames.
Johnson, Ben (2012).

Authlogic.
https://github.com/binarylogic/authlogic.
Ketelle, Paul.
Gema paperclipdropbox.
https://github.com/dripster82/paperclipdropbox.
Koziarski, Michael; Dean Shepherd, James.

Gema country-select.
https://github.com/jamesds/country-select.
Kramarenko, Artem.
Gema acts-as-taggable-on.
http://rubydoc.info/gems/acts-as-taggable-on/2.2.2/frames.
Leonardo Lemus, Jorge; Navas Muos, Jenniffer (2009).

Manual OpenProj.
http://www.uco.es/ lr1maalm/Manual-openproj.pdf.
Lindsaar, Mikel.
Gema mail.
https://github.com/mikel/mail.
Luetke, Tobias.
Gema activemerchan.
http://activemerchant.org/.
MacAulay, James; Lutke, Tobi; Fauser, Cody; Baker, Jimmy.

Gema active_shipping.
https://github.com/Shopify/active_shipping.
284
Marcelo Hernn, Schenone (2004).
Tesis: Diseo de una Metodologa gil de Desarrollo de Software.
http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf.
Marohnic, Mislav.
Gema will_paginate.
https://github.com/mislav/will_paginate/wiki.
Matake, Nov.
Gema paypal-express.
https://github.com/nov/paypal-express.
Matsuda, Akira.
Gema kaminari.
https://github.com/amatsuda/kaminari.
Microsistems, Sun.
MySQL.
http://www.mysql.com/.
Miller, Ernie. Gema meta_search.

https://github.com/ernie/meta_search.
Milln, Emmanuel N.; McCreesh, John (2005).

Cuatro das con Rails..
Moses, Brooks (2007).

The listings package.
ftp://ftp.tex.ac.uk/tex-archive/macros/latex/contrib/listings/listings.pdf.
Motion, Sparkle.
Gema nokogiri.
http://nokogiri.org/.
PAE. Portal Administracin Electrnica (2011).

Mtrica v.3.
http://administracionelectronica.gob.es/archivos/pae_000001040.pdf.
Paypal.
Incorporar pago de PayPal a su carrito de compras de terceros.
https://www.paypal.com/.
PayPal (2008).
Website Payments Standard Integration Guide.
https://www.paypalobjects.com/en_US/pdf/PP_WebsitePaymentsStandard_IntegrationGuide.pdf.
Quaranto, Nick; Otros.

RubyGems.org.
http://rubygems.org/.
285
Railscasts.
251 MetaWhere and MetaSearch.
http://railscasts.com/episodes/251-metawhere-metasearch?language=es&view=asciicast.
Ross, Phil.
Gema tzinfo.
http://tzinfo.rubyforge.org/.
Ruby, Sam; Thomas, Dave; Heinemeier Hansson, David (2010).

Agile Web Development with Rails. The Pragmatic Bookshelf, 4a edicin.
Sichanugrist, Prem.
Gema paperclip.
https://github.com/thoughtbot/paperclip.
Simonic, Aleksander.
WinEdt.
http://www.winedt.com/.
Software, Black Duck.

Ohloh.
http://www.ohloh.net/.
Somoza, Gabriel (2009).

Va Rails. Cmo Adjuntar Archivos a un Modelo en Rails. Paperclip.
http://viarails.wordpress.com/2009/11/29/como-adjuntar-archivos-a-un-modelo-en-rails/.
Stachewicz, Tomasz.
Gema globalize3.
https://github.com/svenfuchs/globalize3.
StuFF mc.
Demo globalize2.
https://github.com/joshmh/globalize2-demo.
Thomas, Dave. Api Ruby on Rails.

http://api.rubyonrails.org/.
Venkatreddy Dwarampudi; Shahbaz Singh Dhillon; Jivitesh Shah; Nikhil Joseph

Sebastian; Nitin Satyanarayan Kanigicharla (2010).
Comparative study of the Pros and Cons of Programming languages.
http://arxiv.org/pdf/1008.3431.pdf.
W3C.
World Wide Web Consortium (W3C).
http://www.w3.org/.
Welton, David N. (2005).

The Economics of Programming Languages.
http://www.welton.it/articles/programming_language_economics.html.
286
Welton, David N. (2011).
Programming Language Popularity.
http://www.langpop.com/.
Wikibooks (2011).
LATEX Wikibook.
http://en.wikibooks.org/wiki/LaTeX.
Wikipedia.
Desarrollo gil de software.
http://es.wikipedia.org/wiki/Desarrollo_ %C3 %A1gil_de_software.
Wikipedia.
Lenguaje de programacin interpretado.
http://es.wikipedia.org/wiki/Lenguaje_de_programaci %C3 %B3n_interpretado.
Wikipedia.
Pruebas de software.
http://es.wikipedia.org/wiki/Pruebas_de_software.
Wikipedia.
Ruby.
http://es.wikipedia.org/wiki/Ruby.
Wikipedia.
Ruby on Rails.
http://es.wikipedia.org/wiki/Ruby_on_Rails.
Yahoo.
Yahoo Search.
http://es.search.yahoo.com/.
287
288
GNU Free Documentation License
Version 1.3, 3 November 2008
Copyright
c 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. http://
fsf.org/.
Everyone is permitted to copy and distribute verbatim copies of this license document,
but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other functional and
useful document free in the sense of freedom: to assure everyone the effective freedom
to copy and redistribute it, with or without modifying it, either commercially or noncom-
mercially. Secondarily, this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for modifications made by
others.
This License is a kind of copyleft, which means that derivative works of the document
must themselves be free in the same sense. It complements the GNU General Public
License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because
free software needs free documentation: a free program should come with manuals provi-
ding the same freedoms that the software does. But this License is not limited to software
manuals; it can be used for any textual work, regardless of subject matter or whether it
is published as a printed book. We recommend this License principally for works whose
purpose is instruction or reference.
APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a
notice placed by the copyright holder saying it can be distributed under the terms of this
License. Such a notice grants a world-wide, royalty-free license, unlimited in duration,
to use that work under the conditions stated herein. The Document, below, refers to
289
any such manual or work. Any member of the public is a licensee, and is addressed as
you. You accept the license if you copy, modify or distribute the work in a way requiring
permission under copyright law.
A Modified Version of the Document means any work containing the Document or a
portion of it, either copied verbatim, or with modifications and/or translated into another
language.
A Secondary Section is a named appendix or a front-matter section of the Document

that deals exclusively with the relationship of the publishers or authors of the Document
to the Documents overall subject (or to related matters) and contains nothing that could
fall directly within that overall subject. (Thus, if the Document is in part a textbook of
mathematics, a Secondary Section may not explain any mathematics.) The relationship
could be a matter of historical connection with the subject or with related matters, or of
legal, commercial, philosophical, ethical or political position regarding them.
The Invariant Sections are certain Secondary Sections whose titles are designated,
as being those of Invariant Sections, in the notice that says that the Document is released
under this License. If a section does not fit the above definition of Secondary then it
is not allowed to be designated as Invariant. The Document may contain zero Invariant
Sections. If the Document does not identify any Invariant Sections then there are none.
The Cover Texts are certain short passages of text that are listed, as Front-Cover
Texts or Back-Cover Texts, in the notice that says that the Document is released under
this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.
A Transparent copy of the Document means a machine-readable copy, represented

in a format whose specification is available to the general public, that is suitable for re-
vising the document straightforwardly with generic text editors or (for images composed
of pixels) generic paint programs or (for drawings) some widely available drawing editor,
and that is suitable for input to text formatters or for automatic translation to a variety
of formats suitable for input to text formatters. A copy made in an otherwise Transpa-
rent file format whose markup, or absence of markup, has been arranged to thwart or
discourage subsequent modification by readers is not Transparent. An image format is not
Transparent if used for any substantial amount of text. A copy that is not Transparent
is called .Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without mar-
kup, Texinfo input format, LATEXinput format, SGML or XML using a publicly available
DTD, and standard-conforming simple HTML, PostScript or PDF designed for human
modification. Examples of transparent image formats include PNG, XCF and JPG. Opa-
que formats include proprietary formats that can be read and edited only by proprietary
word processors, SGML or XML for which the DTD and/or processing tools are not
generally available, and the machine-generated HTML, PostScript or PDF produced by
some word processors for output purposes only.
290
The Title Page means, for a printed book, the title page itself, plus such following
pages as are needed to hold, legibly, the material this License requires to appear in the
title page. For works in formats which do not have any title page as such, Title Page
means the text near the most prominent appearance of the works title, preceding the
beginning of the body of the text.
The publisher means any person or entity that distributes copies of the Document
to the public.
A section Entitled XYZ means a named subunit of the Document whose title either
is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in
another language. (Here XYZ stands for a specific section name mentioned below, such
as Acknowledgements, Dedications, Endorsements, or History.) To "Preserve the
Title.of such a section when you modify the Document means that it remains a section
Entitled XYZ according to this definition.
The Document may include Warranty Disclaimers next to the notice which states
that this License applies to the Document. These Warranty Disclaimers are considered to
be included by reference in this License, but only as regards disclaiming warranties: any
other implication that these Warranty Disclaimers may have is void and has no effect on
the meaning of this License.
VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or
noncommercially, provided that this License, the copyright notices, and the license notice
saying this License applies to the Document are reproduced in all copies, and that you
add no other conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the copies you make or
distribute. However, you may accept compensation in exchange for copies. If you distribute
a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may
publicly display copies.
COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers)
of the Document, numbering more than 100, and the Documents license notice requires
Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the
back cover. Both covers must also clearly and legibly identify you as the publisher of
these copies. The front cover must present the full title with all words of the title equally
prominent and visible. You may add other material on the covers in addition. Copying
291
with changes limited to the covers, as long as they preserve the title of the Document
and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put
the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest
onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100,
you must either include a machine-readable Transparent copy along with each Opaque
copy, or state in or with each Opaque copy a computer-network location from which
the general network-using public has access to download using public-standard network
protocols a complete Transparent copy of the Document, free of added material. If you use
the latter option, you must take reasonably prudent steps, when you begin distribution
of Opaque copies in quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least one year after the last time you distribute
an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well
before redistributing any large number of copies, to give them a chance to provide you
with an updated version of the Document.
MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions
of sections 2 and 3 above, provided that you release the Modified Version under precisely
this License, with the Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever possesses a copy of it.
In addition, you must do these things in the Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct from that of the
Document, and from those of previous versions (which should, if there were any,
be listed in the History section of the Document). You may use the same title as a
previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for
authorship of the modifications in the Modified Version, together with at least five
of the principal authors of the Document (all of its principal authors, if it has fewer
than five), unless they release you from this requirement.
State on the Title page the name of the publisher of the Modified Version, as the
publisher.
Preserve all the copyright notices of the Document.
Add an appropriate copyright notice for your modifications adjacent to the other
copyright notices.
292
Include, immediately after the copyright notices, a license notice giving the public
permission to use the Modified Version under the terms of this License, in the form
shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Cover
Texts given in the Documents license notice.
Include an unaltered copy of this License.
Preserve the section Entitled "History", Preserve its Title, and add to it an item
stating at least the title, year, new authors, and publisher of the Modified Version
as given on the Title Page. If there is no section Entitled "Historyn the Document,
create one stating the title, year, authors, and publisher of the Document as given
on its Title Page, then add an item describing the Modified Version as stated in the
previous sentence.
Preserve the network location, if any, given in the Document for public access to
a Transparent copy of the Document, and likewise the network locations given in
the Document for previous versions it was based on. These may be placed in the
"History"section. You may omit a network location for a work that was published
at least four years before the Document itself, or if the original publisher of the
version it refers to gives permission.
For any section Entitled .Acknowledgements.or "Dedications", Preserve the Title of
the section, and preserve in the section all the substance and tone of each of the
contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in
their titles. Section numbers or the equivalent are not considered part of the section
titles.
Delete any section Entitled .Endorsements". Such a section may not be included in
the Modified Version.
Do not retitle any existing section to be Entitled .Endorsements.or to conflict in title
with any Invariant Section.
Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify
as Secondary Sections and contain no material copied from the Document, you may at
your option designate some or all of these sections as invariant. To do this, add their titles
to the list of Invariant Sections in the Modified Versions license notice. These titles must
be distinct from any other section titles.
You may add a section Entitled Endorsements, provided it contains nothing but
endorsements of your Modified Version by various partiesfor example, statements of
peer review or that the text has been approved by an organization as the authoritative
definition of a standard.
293
You may add a passage of up to five words as a Front-Cover Text, and a passage of up
to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added
by (or through arrangements made by) any one entity. If the Document already includes
a cover text for the same cover, previously added by you or by arrangement made by the
same entity you are acting on behalf of, you may not add another; but you may replace
the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission
to use their names for publicity for or to assert or imply endorsement of any Modified
Version.
COMBINING DOCUMENTS
You may combine the Document with other documents released under this License,
under the terms defined in section 4 above for modified versions, provided that you
include in the combination all of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your combined work in its license
notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical
Invariant Sections may be replaced with a single copy. If there are multiple Invariant
Sections with the same name but different contents, make the title of each such section
unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the same adjustment
to the section titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled History in the various
original documents, forming one section Entitled History; likewise combine any sections
Entitled Acknowledgements, and any sections Entitled Dedications. You must delete
all sections Entitled .Endorsements".
COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released
under this License, and replace the individual copies of this License in the various docu-
ments with a single copy that is included in the collection, provided that you follow the
rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it indivi-
dually under this License, provided you insert a copy of this License into the extracted
document, and follow this License in all other respects regarding verbatim copying of that
document.
294
AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent
documents or works, in or on a volume of a storage or distribution medium, is called an
aggregate if the copyright resulting from the compilation is not used to limit the legal
rights of the compilations users beyond what the individual works permit. When the
Document is included in an aggregate, this License does not apply to the other works in
the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Docu-
ment, then if the Document is less than one half of the entire aggregate, the Documents
Cover Texts may be placed on covers that bracket the Document within the aggregate, or
the electronic equivalent of covers if the Document is in electronic form. Otherwise they
must appear on printed covers that bracket the whole aggregate.
TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of

the Document under the terms of section 4. Replacing Invariant Sections with translations
requires special permission from their copyright holders, but you may include translations
of some or all Invariant Sections in addition to the original versions of these Invariant
Sections. You may include a translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include the original
English version of this License and the original versions of those notices and disclaimers.
In case of a disagreement between the translation and the original version of this License
or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled Acknowledgements, Dedications, or His-

tory, the requirement (section 4) to Preserve its Title (section 1) will typically require
changing the actual title.
TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly
provided under this License. Any attempt otherwise to copy, modify, sublicense, or dis-
tribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular
copyright holder is reinstated (a) provisionally, unless and until the copyright holder
explicitly and finally terminates your license, and (b) permanently, if the copyright holder
fails to notify you of the violation by some reasonable means prior to 60 days after the
cessation.
295
Moreover, your license from a particular copyright holder is reinstated permanently if
the copyright holder notifies you of the violation by some reasonable means, this is the
first time you have received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after your receipt of the
notice.
Termination of your rights under this section does not terminate the licenses of parties
who have received copies or rights from you under this License. If your rights have been
terminated and not permanently reinstated, receipt of a copy of some or all of the same
material does not give you any rights to use it.
FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free
Documentation License from time to time. Such new versions will be similar in spirit to
the present version, but may differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document
specifies that a particular numbered version of this License .or any later version.applies
to it, you have the option of following the terms and conditions either of that specified
version or of any later version that has been published (not as a draft) by the Free Software
Foundation. If the Document does not specify a version number of this License, you may
choose any version ever published (not as a draft) by the Free Software Foundation. If
the Document specifies that a proxy can decide which future versions of this License can
be used, that proxys public statement of acceptance of a version permanently authorizes
you to choose that version for the Document.
RELICENSING
Massive Multiauthor Collaboration Site (or MMC Sit) means any World Wide
Web server that publishes copyrightable works and also provides prominent facilities for
anybody to edit those works. A public wiki that anybody can edit is an example of such
a server. A Massive Multiauthor Collaboration (or MMC) contained in the site means
any set of copyrightable works thus published on the MMC site.
CC-BY-SA means the Creative Commons Attribution-Share Alike 3.0 license pu-
blished by Creative Commons Corporation, a not-for-profit corporation with a principal
place of business in San Francisco, California, as well as future copyleft versions of that
license published by that same organization.
Incorporate means to publish or republish a Document, in whole or in part, as part

of another Document.
296
An MMC is eligible for relicensing if it is licensed under this License, and if all
works that were first published under this License somewhere other than this MMC, and
subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or
invariant sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under
CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is
eligible for relicensing.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the License in
the document and put the following copyright and license notices just after the title page:
Copyright (C) YEAR YOUR NAME. Permission is granted to copy, distribute and/or
modify this document under the terms of the GNU Free Documentation License, Version
1.3 or any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included
in the section entitled "GNU Free Documentation License".
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the
with . . . Texts. line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts
being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the
three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend re-

leasing these examples in parallel under your choice of free software license, such as the
GNU General Public License, to permit their use in free software.
297

Tvirtual Galeria

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tvirtual Galeria

Caricato da

Copyright:

Formati disponibili

ESCUELA SUPERIOR DE INGENIERA

INGENIERA TCNICA EN INFORMTICA DE GESTIN

TIENDA VIRTUAL PARA UNA GALERA DE ARTE

DEPARTAMENTO: Lenguajes y Sistemas Informticos

DIRECTOR DEL PROYECTO: Juan Manuel Dodero Beardo

AUTORA DEL PROYECTO: Silvia Mara Garbarino de la Rosa

San Fernando, Abril 2013

Fdo: Silvia Mara Garbarino de la Rosa

Despus de tanto tiempo

A mis padres y tas

Gracias a todos de corazn.

Copyright(C) 2013 Silvia Mara Garbarino de la Rosa

1.2. Propsito, objetivos y alcance del proyecto . . . . . . . . . . . . . . . . . . 5

1.3. Producto final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4. Organizacin del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.1. Organizacin de la memoria . . . . . . . . . . . . . . . . . . . . . . 10

1.4.2. Organizacin del software . . . . . . . . . . . . . . . . . . . . . . . 12

2.1. Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Planificacin del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1. Objetivo inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2. Divisin del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.3. Estimacin de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.4. Identificacin de Sprints . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.5. Planificacin temporal . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.6. Anlisis de la desviacin temporal . . . . . . . . . . . . . . . . . . . 23

2.4. Organizacin del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.1.1. Estructura interna . . . . . . . . . . . . . . . . . . . . . . 24

2.4.1.2. Roles y responsabilidades . . . . . . . . . . . . . . . . . . 24

2.4.2. Equipo informtico . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6. Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.1. Evaluacin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.1.1. Identificacin de riesgos . . . . . . . . . . . . . . . . . . . 29

2.6.1.2. Anlisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 31

2.6.1.3. Priorizacin de riesgos . . . . . . . . . . . . . . . . . . . . 35

2.6.2. Control de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.6.2.1. Reduccin de riesgos . . . . . . . . . . . . . . . . . . . . . 36

2.6.2.2. Resolucin de riesgos . . . . . . . . . . . . . . . . . . . . . 37

3.1. Catlogo de actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.2. Modelado de casos de uso . . . . . . . . . . . . . . . . . . . . . . . 51

3.2.2.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . 51

3.2.2.2. Descripcin de casos de uso . . . . . . . . . . . . . . . . . 57

3.3. Requisitos de Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.4.1. Requisitos de interfaz externa . . . . . . . . . . . . . . . . . . . . . 82

3.4.1.1. Interfaces de usuarios . . . . . . . . . . . . . . . . . . . . 82

3.4.1.2. Interfaces con el hardware . . . . . . . . . . . . . . . . . . 82

3.4.1.3. Interfaces con el software . . . . . . . . . . . . . . . . . . 82

3.4.1.4. Interfaces de comunicaciones . . . . . . . . . . . . . . . . 82

3.4.2. Requisitos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.4.3. Requisitos de eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.4.3.1. Requisitos de espacio . . . . . . . . . . . . . . . . . . . . . 83

3.4.3.2. Requisitos de rendimiento . . . . . . . . . . . . . . . . . . 83

3.4.4. Restricciones del diseo . . . . . . . . . . . . . . . . . . . . . . . . 83

3.4.5. Restricciones de base de datos . . . . . . . . . . . . . . . . . . . . . 83

3.4.6. Atributos de sistema de software . . . . . . . . . . . . . . . . . . . 83

3.5. Reglas de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.6. Estudio de alternativas tecnolgicas . . . . . . . . . . . . . . . . . . . . . . 84

3.6.1.2. Ruby como lenguaje para mi proyecto . . . . . . . . . . . 91

3.6.2. Entorno de desarrollo Web . . . . . . . . . . . . . . . . . . . . . . . 92

3.6.2.1. Rails como framework para mi proyecto . . . . . . . . . . 94

3.6.2.2. Otros frameworks . . . . . . . . . . . . . . . . . . . . . . . 95

3.7. Anlisis GAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101