TFG Jose-Maria Rodriguez Garcia 2018

Grado en Ingeniería de Sistemas de Comunicaciones 2017-
2018
Trabajo Fin de Grado
“Guía para el desarrollo y

documentación de una aplicación
web .NET”
José María Rodríguez García

Tutor Harold
Molina-Bulla
Leganés a 15-06-2018
[Incluir en el caso del interés de su publicación en el archivo abierto]

Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento – No
Comercial – Sin Obra Derivada
Guía para el desarrollo y documentació n de una aplicació n web .NET
II
RESUMEN
El presente trabajo de fin de grado trata de presentar de manera breve y concisa un ejemplo de
realización de una aplicación web y su correspondiente documentación. Dicho desarrollo y
documentación es siempre desde el punto de vista de un jefe de proyecto y de un programador.
Desde que empecé a trabajar, si he aprendido algo importante, es que una buena documentación
puede ahorrar mucho tiempo y esfuerzo en un futuro. Y no solo a la hora de volver a desarrollar
aplicaciones que utilicen funciones parecidas, sino a la hora de comunicación con el cliente,
dejar todo claro desde el principio, e incluso para nosotros mismo a la hora de desarrollar
permitiendo prever los posibles problemas que se tendrán o necesidades que pueden hacer parar
un desarrollo permitiendo así como he mencionado ya ahorrar tiempo y esfuerzo. Un análisis
funcional permite presentar al cliente como va a funcionar y cómo va a quedar exactamente la
aplicación siempre desde el punto de vista visual y de funcionamiento del aplicativo. El análisis
técnico tiene dos funciones, primero es para el cliente, puesto que nos tienen que aceptar los
métodos usados y los elementos empleados en los desarrollos, como por ejemplo entornos
aplicaciones etc., y segundo para nosotros como desarrolladores permitiéndonos así tener todo
previsto y adelantarnos a los acontecimientos, por ejemplo para ir preparando los recursos. La
realización de estos documentos permite también evitar giros en el desarrollo y en las
funcionalidades, aunque a veces es inevitable ya sea por cambios del cliente o problemas
insalvables. También hace hincapié en la toma de requisitos de cliente puesto que cuando más
se adecue la oferta a lo que la empresa necesita se tienen más probabilidades de ganar la oferta y
con ella el desarrollo. Además se ha incluido brevemente una sección de un plan de pruebas, ya
que un plan de pruebas real conllevaría muchísimos casos y haría esta memoria demasiado
larga. Aunque está más orientado hacia la parte del desarrollador y de la parte del jefe de
proyecto, también se ha incluido un módulo en el que hace hincapié en el personal necesario y
costes tanto de personal, tiempo y económico.
III
IV
DEDICATORIA
Me gustaría dedicar la finalización del TFG a mis padres y hermanos, puesto que han supuesto
un apoyo fundamental, no solo en el estudio de la carrera sino todos los días de mi vida sin el
cual no habría conseguido todo lo que soy hoy. Les agradezco todo lo que hacen por mí y
espero que el sacrificio que ellos realizaron merezca la pena en el futuro.
V
VI
Índice de imágenes
Ilustración 1: Vida del proyecto desde TI......................................................................................4

Ilustración 2: Sello indicador de accesibilidad según los estándares especificados en la AA...16
Ilustración 3: Equipo de trabajo.................................................................................................21
Ilustración 4: Arquitectura MVC.................................................................................................24
Ilustración 5b: Arquitectura de ficheros de la Vista...................................................................27
Ilustración 6: Arquitectura de ficheros del controlador.............................................................28
Ilustración 7: Arquitectura de los ficheros de las propiedades del proyecto..............................28
Ilustración 8: Arquitectura de las librerías referenciadas..........................................................29
Ilustración 9: Arquitectura de las migraciones en modificaciones.............................................29
Ilustración 10: Arquitectura del proyecto del modelo.................................................................30
Ilustración 11: Arquitectura de los parámetros de configuración..............................................30
Ilustración 12: Arquitectura de scripts........................................................................................31
Ilustración 13: Arquitectura de librerías de estilos.....................................................................32
Ilustración 14: Logo corporativo de la aplicación......................................................................33
Ilustración 15: Selector de idioma...............................................................................................34
Ilustración 16: Selector de idioma cuando se pulsa sobre él......................................................35
Ilustración 17: Enlace de registro...............................................................................................35
Ilustración 18: Enlace de registro al pasar por encima el ratón................................................36
Ilustración 19: Enlace de acceso a usuarios...............................................................................36
Ilustración 20: Enlace de acceso a usuarios cuando se pasa por encima..................................36
Ilustración 21: Párrafo de copyright...........................................................................................37
Ilustración 22: Enlace a la home.................................................................................................38
Ilustración 23: Enlace a políticas de privacidad.........................................................................38
Ilustración 24: Página maestra...................................................................................................40
Ilustración 25: Barra de scroll....................................................................................................40
Ilustración 26: Contenedor de selección de deporte...................................................................41
Ilustración 27: Contenedor 2 selección de zona..........................................................................42
Ilustración 28: contenedor 3 selector de horario........................................................................43
Ilustración 29: Página principal sin logar..................................................................................44
Ilustración 30: Página principal logado.....................................................................................44
Ilustración 31: Lista de partidos.................................................................................................45
Ilustración 32: botones para apuntarse a partido.......................................................................46
Ilustración 33: Botón crear partido.............................................................................................46
Ilustración 34: Formulario de crear partido...............................................................................48
Ilustración 35: Página de partido seleccionado..........................................................................48
VI
Ilustración 36: Imagen de pop up de login..................................................................................50

Ilustración 37: ventana de login..................................................................................................51
Ilustración 38: Validación de email............................................................................................52
Ilustración 39: Validación de contraseña...................................................................................52
Ilustración 40: Contraseña con formato puntos..........................................................................52
Ilustración 41: Validación de email formato correcto................................................................52
Ilustración 42: Cabecera logada.................................................................................................53
Ilustración 43: Cabecera logada con nombre usuario................................................................53
Ilustración 44: Formulario de registro.......................................................................................54
Ilustración 45: Formulario de perfil de usuario.........................................................................55
Ilustración 46: Riesgos de seguridad más importantes según OWASP......................................57
Ilustración 47: Esquema para establecer un nivel de confianza recomendado por OWASP ASVS
................................................................................................................................... 59
Ilustración 48: Descripción de metas y title en html...................................................................61
Ilustración 49: Url Amigable de sección de contacto en español...............................................61
Ilustración 50: Url Amigable de sección de acerca de nosotros en español..............................61
Ilustración 51: Url Amigable de sección de contacto en inglés..................................................62
Ilustración 52: Url Amigable de sección de acerca de nosotros en inglés.................................62
Ilustración 53: Importancia de cada tag en términos de SEO....................................................65
Ilustración 54: Url de la aplicación............................................................................................66
Ilustración 55: pop up de login AF..............................................................................................66
Ilustración 56: Enlace de recordar usuario AF..........................................................................67
Ilustración 57: Enlaces de usuario y salir AF............................................................................67
Ilustración 58: PopUp de confirmación de salir AF...................................................................67
Ilustración 59: Mensaje de confirmación de salida AF...............................................................68
Ilustración 60: Enlaces de vuelta de des autenticación..............................................................68
Ilustración 61: pop up de autenticación......................................................................................68
Ilustración 62: Página de recuerdo de contraseña.....................................................................69
Ilustración 63: Selección de idioma AF.......................................................................................69
Ilustración 64: Opciones de selección de idioma AF..................................................................69
Ilustración 65: Enlaces de condiciones y privacidad..................................................................70
Ilustración 66: Selección de deporte zona y horario AF.............................................................70
Ilustración 67: Pop Up para identificarse AF.............................................................................71
Ilustración 68: Formulario de registro AF..................................................................................71
Ilustración 69: Partidos disponibles AF......................................................................................72
Ilustración 70: Búsqueda de partido...........................................................................................72
Ilustración 71: Botón de crear partido........................................................................................73
Ilustración 72: Formulario de creación de partido.....................................................................73
VI
Ilustración 73: Ver perfil de usuario...........................................................................................74

Ilustración 74: Página de perfil de usuario.................................................................................74
Ilustración 75: Ejemplo del manual de usuario..........................................................................79
Ilustración 76: porcentaje de tiempo empleado en la realización del TFG................................83
Ilustración 77: Número de horas empleadas en cada apartado del TFG...................................84
Ilustración 78: Gantt del desarrollo del TFG.............................................................................84
Ilustración 79: Tabla de verificación de seguridad de OWASP..................................................88
Ilustración 80: Pautas para la accesibilidad dadas por WCAG 2.0...........................................89
Ilustración 81: Búsqueda en google para la comprobación de que se encuentra......................92
IX
Índice de tablas
Tabla 1: Versión de modificaciones de documento del proyecto de la empresa JMSOLUTIONSL

..................................................................................................................................... 5
Tabla 2: Descripción de los contenidos que se deben mostrar en la página inicial a petición de
EMPRESA_CONTRANTANTE_1................................................................................................10
Tabla 3: Descripción de los contenidos que se deben mostrar en la página de resultados a
petición de EMPRESA_CONTRANTANTE_1.............................................................................11
Tabla 4: Descripción de los contenidos que se deben mostrar en la página de crear partido a
petición de EMPRESA_CONTRATANTE_1................................................................................13
Tabla 5: Descripción de los contenidos que se deben mostrar en la página de registro a
petición de EMPRESA_CONTRATANTE_1................................................................................14
Tabla 6: Criterios para selección de oferta ganadora................................................................17
Tabla 7: Planificación inicial por parte de la empresa JMSOLUTIONSL especificando las
partes............................................................................................................................................18
Tabla 8: Explicación a la tabla 6 del porqué de la duración de cada fase.................................19
Tabla 34: Descripción de los perfiles necesitados para el desarrollo........................................22
Tabla 35: Precios según puesto...................................................................................................22
Tabla 9: Propiedades utilizadas para la clase Usuario..............................................................25
Tabla 10: Propiedades utilizadas para la clase Partido.............................................................26
Tabla 11: Propiedades utilizadas para la clase Deporte............................................................26
Tabla 12: Propiedades utilizadas para la clase Sesión...............................................................27
Tabla 13: Características de diseño del logo..............................................................................34
Tabla 14: Características de diseño del selector de idioma.......................................................34
Tabla 15: Características de diseño del enlace de registro........................................................35
Tabla 16: Características de diseño del enlace de login.............................................................36
Tabla 17: Características de diseño del párrafo de copyright....................................................37
Tabla 18: Características de diseño del enlace a la home..........................................................38
Tabla 19: Características de diseño del enlace de políticas de privacidad................................38
Tabla 20: Características de diseño del enlace de términos y condiciones................................39
Tabla 21: Características de diseño de la página maestra.........................................................40
Tabla 22: Características de diseño del contenedor 1................................................................41
Tabla 23: Características de diseño del contenedor 2................................................................42
Tabla 24: Características de diseño del contenedor 3 selector de horario................................43
Tabla 25: Características de la lista de partidos........................................................................45
Tabla 26: Lista de botones...........................................................................................................46
Tabla 27: Propiedades del botón crear partido..........................................................................47
Tabla 28: Características del formulario de crear partido.........................................................47
X
Tabla 29: Propiedades de la tabla de partido.............................................................................49

Tabla 30: propiedades de la tabla de componentes del partido..................................................50
Tabla 31: Propiedades de la ventana modal de login.................................................................51
Tabla 32: Propiedades del formulario de registro......................................................................53
Tabla 33: Propiedades del perfil de usuario...............................................................................55
Tabla 36: Coste personal del TFG..............................................................................................85
Tabla 37: Coste material del TFG...............................................................................................85
Tabla 38: Coste total del TFG.....................................................................................................85
Tabla 39: Caracteres prohibidos en campos............................................................................105
XI
Tabla de acrónimos y anglicismos
En la siguiente tabla se muestra una relación de los términos utilizados y su significado.

También hace referencia a términos en inglés que no tienen traducción literal al español y se
utiliza en dicho idioma o que en términos de programación se ha realizado con dicho nombre ya
que esta programación se ha llevado a cabo en inglés.
Acrónimo Significado
home Página principal de un portal y en la cual se

arranca la aplicación. Su nomenclatura es así
porque hace referencia al controlador
principal llamado HomeController y que
pertenece a la vista home
login Acto de identificarse en una aplicación o

programa mediante usuario y contraseña
logout Acto de salir de una aplicación de la parte

identificada a la parte anónima
responsive Aplicativo que se adapta tamaño de cualquier

dispositivo y a cualquier tamaño de pantalla
header La cabecera de la página de la aplicación.

Hace referencia dicho apartado en el código
HTML
footer El pie de página de la aplicación. Hace

referencia dicho apartado en el código HTML
normativa AA Normativa que trata garantizar que existe un

nivel mínimo en todas las páginas de
accesibilidad para las personas que tienen
necesidades especiales.
SEO Search Engine Optimization
sitemaps Mapas de sitio web ( hace referencia al

archivo Sitemap.xml)
C# Tipo de lenguaje
CSHTML HTML mezclado con C#
Context Contexto de aplicación con la que establece la

comunicación con el servidor
HTML (HyperText Markup Language) Lenguaje para web estático
XI
Razor Motor de vistas empleado
Framework Marco de trabajo
asp.net MVC Modelo de desarrollo Web unificado
partial Modo de vista
MVC ( Model , View, Controler) Patrón de diseño
DLL dynamic-link library
EntityFramework Conjunto de tecnologías para el desarrollo de

aplicaciones software orientadas a datos
Data Datos
Procedures Procedimientos almacenados encargados de

establecer comunicación con el servidor ya
sea de entrada o de salida de datos
Web.config Fichero encargado de almacenar la

información de arranque de una solución
Boostrap.js Marco de trabajo de diseño
Liberias(DLL) Ficheros de terceros con funciones ya

implementadas
.Css ( Cascading Style Sheets) Hojas de estilos
landscape Versión en horizontal
JQuery Librerías de JavaScript
Meta Etiqueta HTML para aportar información del

documento
title Etiqueta que aparecerá en la pestaña que

tengamos abierta con la aplicación
URL canónicas Url utilizadas para evitar el contenido

duplicado
Drupall Gestor de contenidos para la elaboración de

web
Wordpress Gestor de contenidos para la elaboración de

web
IT(Information Technology) Tecnologías de la información
XI
EMPRESA_CONTRANTANTE_1 Empresa ficticia la cual encarga el desarrollo

a otra empresa
JMSOLUTIONSL Empresa ficticia encargada de hacer el

desarrollo
Link Enlace
Page Speed test Aplicación de Google donde especifica la

velocidad y la optimización de una página
glyphicon-globe Clase de icono del mundo
(WCAG) 2.0 ( Web Content Accessibility Las Pautas de Accesibilidad para el Contenido
Guidelines 2.0) Web
String Tipo de variable de cadena texto
Int Tipo de variable de entero
Date Tipo de variable de fecha
Text Propiedad de clase
#333 Color en hexadecimal
Background-color Color de fondo
Color Color de letra
Font-family Tipo de letra: Arial, Helvética
Font-size Tamaño de letra
Hover:Color Color cuando el puntero pasa por encima
Barra de scroll Barra derecha que aparece cuando el

contenido es mayor que el tamaño de la
pantalla
Select Tipo de input de formulario en el cual el

usuario selecciona una opción de las dadas
Input Campo en el que el usuario introduce valores
autenticar Identificarse frente a una aplicación
desautenticar Salir de la parte autenticada
desarrollo back-end Es el desarrollo encargado de la lógica de la

aplicación
XI
desarrollo front-end Es el desarrollo de la parte visual
X
Tabla de contenido
Índice de imágenes.......................................................................................................................VII
Índice de tablas...............................................................................................................................X
Tabla de acrónimos y anglicismos...............................................................................................XII
1. Introducción............................................................................................................................1
1.1. Motivación.....................................................................................................................1
1.2 Objetivos........................................................................................................................2
1.2.1 Objetivos específicos..................................................................................................3
1.3 Organización del documento del TFG...........................................................................3
1.4 Organización del desarrollo de la aplicación.................................................................4
1.5 Control del documento del TFG.....................................................................................5
2. Toma de requisitos del cliente................................................................................................6
2.1 Cláusula de responsabilidad / confidencialidad.............................................................6
2.2 Gestión de la calidad......................................................................................................7
2.2.1 Comunicación y seguimiento del proyecto................................................................7
2.3 Visión actual del proyecto..............................................................................................8
2.3.1 Descripción de la necesidad a cubrir......................................................................8
2.3.2 Descripción de contenidos por página....................................................................9
2.3.3 Requisitos Globales..............................................................................................14
2.3.4 Requisitos de rendimiento....................................................................................14
2.3.5 Requisitos de usabilidad.......................................................................................15
2.3.6 Requisitos de accesibilidad..................................................................................15
2.3.7 Requisitos de posicionamiento.............................................................................16
2.4 Criterios que sigue el cliente para escoger a la empresa que desarrollará su aplicación.
16
3. Valoración inicial del proyecto por parte de JMSOLUTIONSL.........................................18
4. Equipo de trabajo y construcción para la realización del proyecto......................................20
5. Plan de ejecución de desarrollo de la aplicación por parte de JMSOLUTIONSL...............23
6. Descripción de la solución técnica propuesta.......................................................................24
6.1 Arquitectura..................................................................................................................24
6.1.1. Modelo..................................................................................................................25
6.1.2. Vista......................................................................................................................27
6.1.3. Controlador...........................................................................................................27
X
6.1.4. Capas....................................................................................................................28
6.2 Accesibilidad................................................................................................................32
6.3 Componentes del portal................................................................................................33
6.3.1 Header..................................................................................................................33
6.3.2 Footer...................................................................................................................37
6.3.3 Página maestra......................................................................................................39
6.3.4 Home....................................................................................................................40
6.3.5 Lista de partidos...................................................................................................44
6.3.6 Crear Partido.........................................................................................................46
6.3.7 Página de partido..................................................................................................48
6.3.8 Login....................................................................................................................50
6.3.9 Registro................................................................................................................53
6.3.10 Perfil de usuario....................................................................................................54
6.4 Seguridad......................................................................................................................55
6.4.1 Revisión de seguridad..........................................................................................59
6.5 SEO (Search Engine Optimization)..............................................................................61
6.5.1 Requisitos.............................................................................................................61
6.5.2 Colaboración con los robots.................................................................................63
7. Descripción funcional...........................................................................................................66
7.1 Acceso al portal............................................................................................................66
7.2 Login.............................................................................................................................66
7.3 Logout...........................................................................................................................67
7.4 Recuperar contraseña...................................................................................................68
7.5 Cambiar de idioma el portal.........................................................................................69
7.6 Ver las políticas de privacidad y términos y condiciones............................................70
7.7 Buscar partidos para unirse..........................................................................................70
7.8 Crear partido.................................................................................................................72
7.9 Ver perfil......................................................................................................................74
8. Plan de pruebas.....................................................................................................................76
8.1 Mapa de pruebas...........................................................................................................76
8.2 Pruebas específicas.......................................................................................................77
9. Documentación final a entregar...........................................................................................79
10. Conclusión y trabajos futuros...........................................................................................80
11. Impacto socioeconómico..................................................................................................82
12. Coste del TFG..................................................................................................................83
X
1) Costes personales............................................................................................................83
2) Costes materiales.............................................................................................................85
13. Referencias bibliográficas................................................................................................86
Anexos..........................................................................................................................................88
ANEXO A: Verificaciones recomendadas por el ASVS (Application Security Verification
Standard)..................................................................................................................................88
ANEXO B: Pautas de Accesibilidad AA.................................................................................89
ANEXO C: SiteMap de la aplicación......................................................................................89
ANEXO D Pruebas específicas................................................................................................91
CO001..................................................................................................................................91
CO002..................................................................................................................................93
CO003..................................................................................................................................94
CO004 – [Accesibilidad] Validación...................................................................................96
CO005 – [Arquitectura] Url amigables................................................................................98
CO006 – [Arquitectura] Sitemap, Robots.........................................................................100
CO007 – [Arquitectura] SEO............................................................................................102
CO008 – [Rendimiento] Análisis del rendimiento del Portal............................................103
ANEXO E: Ejemplo de cláusula de confidencialidad...........................................................104
ANEXO F: Ejemplo de validación por Modelo.....................................................................104
ANEXO G: Caracteres restringidos.......................................................................................104
ANEXO H: Protección de datos de carácter personal LEY RGPD.......................................105
X
1. Introducción
1.1. Motivación
Hoy en día el desarrollo de aplicaciones web y de desarrollos web a medida se ha convertido en

un pilar fundamental para las empresas tecnológicas de todo el mundo. Toda empresa que no
está en la web, está condenada a extinguirse, puesto que a través de esta, permite llegar a mucha
más cantidad de clientes incrementando así el volumen de negocio y por consiguiente haciendo
que la empresa y beneficios aumente. Todas las empresas desde pequeñas hasta las más grandes
poseen un rincón en la web y ya no solo para mostrarse y darse a conocer sino para hacer
negocio mediante la venta de productos y servicios vía online. Este método está siendo el gran
boom de este siglo puesto que permite reducir costes pudiendo así ser más competitivo en
precios y teniendo así más beneficios. Esto ha hecho que la confianza de los consumidores
aumente, creciendo a la par con el número de negocios que venden por internet y aun que a día
de doy queda mucho por trabajar en materia de seguridad esta ha mejorado mucho permitiendo
así poder comprar por internet de manera tranquila y segura.
También han crecido muchas empresas con base solo en internet, teniendo la mayoría de la
infraestructura en la web y sin ninguna ubicación física. Estas empresas tienen éxito debido a lo
anteriormente mencionado, ya que les permite reducir enormemente el precio pudiendo
aumentar sus ganancias. Aun teniendo presente la explosión de la burbuja del año 2000(
PuntoCom ), todavía hay muchas empresas que no acaban de ver claro el desarrollo de todo el
negocio por internet, ya que en dicha crisis solo fueron unas pocas empresas tecnológicas las
que lograron mantenerse en dicha actividad, como por ejemplo Yahoo!, EBay, Amazon,
FedEx… desapareciendo el resto o teniendo que cerrar muchas de ellas, por lo que las empresas
que usan la red hoy en día no se basan en ofrecer servicios online apareciendo y desapareciendo
rápidamente sino que usan la web como una forma más de llegar a un consumidor final.
Esto también supone el fin del aplastamiento que estaba siendo producido por las grandes
empresas hacia los pequeños comercios donde era una lucha desigual y donde estaba haciendo
desaparecer a estos comercios. Con esto llega una nueva lucha, llega un nuevo modelo de
negocio y llega una nueva forma de competir. El antiguo dueño de una tienda de arte por
ejemplo se tenía que limitar a vender en la ubicación física en la que estuviera viendo así
reducida su expectación de clientes y conllevando muchísimos gastos tanto de alquiler, luz,
calefacción, personal… pero con su presencia en la web le permite, vender en prácticamente
todo el mundo, llegando así a todos los rincones, le permite mostrarse y darse a conocer, hacer
una comunicación con el cliente inmediata, sin colas, sin horarios cuando el cliente quiera y de
la manera que quiera.
Con estos antecedentes parece lógico que el futuro de los comercios y de los negocios tienda a ir
hacia la web dando cada vez más importancia a esta y dejando otras cuestiones en un segundo
plano.
Con el aumento de comercios en la web se ve exponencialmente aumentada la necesidad de
desarrolladores web y de aplicaciones que hagan webs. Existen gestores de contenido que
generar webs prácticamente gratuitas o por muy poco dinero como puede ser Drupal o
Wordpress pero la falta de originalidad es bastante grande ya que generan dichas web por medio
1
Guía para el desarrollo y documentació n de una aplicació n web
de plantillas. En cuanto se quiere un desarrollo a medida para que se el producto sea original y
único el precio también se dispara pero debido a la gran competencia se puede tener una web o
una aplicación a un costo medio.
Ante la importancia y el aumento de la clave web como pilar fundamental de negocio hoy en
día, el desarrollo de aplicaciones para futura gestión o venta o desarrollo de aplicaciones para
terceros es un sector en los que más trabajo actualmente hay. Sin dejar de lado que es un trabajo
que me apasiona puesto que me permite estar al tanto de las nuevas tecnologías, estar en
constante evolución y que es un trabajo nada monótono. Permite poder ver otras formas de
pensar o de ver otras formas de enfocar un problema. Es un trabajo en el que tienes que trabajar
codo con codo con los compañeros de equipo y en el que la solidaridad es importantísima de
cara a futuras evoluciones de la aplicación. Una buena praxis programando, una buena
arquitectura, y una buena documentación son importantísimos pilares para el desarrollo de una
aplicación web. Una documentación detallada y cuidada le permitirá al usuario una buena guía
para el correcto funcionamiento en el caso de que los pasos a seguir no sean evidentes. También
ayudará a una futura evolución de la aplicación ya que nos permitirá encontrar fácilmente el
lugar en el código donde hacer la modificación. Un buen código y una estructura clara,
uniforme y ordenada es quizá lo más importante a la hora de desarrollar puesto que permitirá
que la escalabilidad sea rápida, precisa y fácil. Esto es de los puntos más importantes puesto que
para evoluciones de código no siempre se tiene el tiempo deseado y una buena estructura
permitirá una modificación mucho más fácil.
1.2 Objetivos
El objetivo de este trabajo de fin de grado es mostrar los pasos que serían necesarios para la
documentación de una aplicación web basada en .Net, el lenguaje C# y HTML5 a la par que se
va desarrollando dicha aplicación. La idea es mostrar a pequeña escala todas las fases de un
proyecto de desarrollo desde el punto de vista desde el jefe de proyecto de IT y de un
desarrollador que se deben dar a la hora de documentar la aplicación y a la hora de mandar
dicha información al cliente, que solicitará la información funcional, la información técnica,
hasta actas de reunión, documentos de pruebas etc.
Se va a utilizar a modo de ejemplo el diseño y documentación de una aplicación basada en web
para poder practicar deporte en equipo. En muchas ocasiones encontrar todas las personas
necesarias para poder organizar una actividad deportiva es difícil debido a la gran
incompatibilidad de horarios que se suele tener hoy en día. La idea es que se acuda a este portal
para ver si hay algún tipo de actividad deportiva de mi interés, en mi zona y en mi horario en el
que no tengo por qué conocer a nadie para poder participar.
La página home del portal muestra tres combos seleccionables en los que tú seleccionas el
deporte, la zona en la que quieres practicarlo y el horario. Si existen partidos disponibles te
mostrará una tabla con dichos eventos y el número de participantes ya adscritos a cada uno .Si
estás interesado en uno puedes acceder a dicho evento, ver las características y si te interesa
apuntarte. Acto seguido en cuanto te apuntes (si estas logado) recibirás un correo confirmándote
2
y se te dará acceso a una sala-chat dentro de la misma web para poder hablar con los integrantes
del partido.
Si no existiera un partido en los combos seleccionables se te dará la opción de crear el partido
introduciendo una serie de campos obligatorios y acto seguido se publicará. Según se vaya
incluyendo integrantes a los partidos, los integrantes irán recibiendo un correo en el que se
informa que dicho integrante se ha incorporado.
Para el login se podrá hacer mediante Facebook, Google+ o con una cuenta mediante usuario y
contraseña. Para el registro se llevara a cabo igual mediante Facebook o rellenando unos
simples datos acerca del perfil de usuario.
1.2.1 Objetivos específicos
Se plantea durante todo el TFG la necesidad de la documentación durante todos los desarrollos
y reuniones mostrando así ejemplos de lo que se tendría que presentar al cliente.
Dicha documentación constaría:
 Toma de requisitos de cliente
 Valoración inicial y formación del equipo de trabajo
 Análisis funcional
 Análisis técnico
 Plan de pruebas
 Plan de ejecución
1.3 Organización del documento del TFG
El proyecto está divido en 14 capítulos los cuales se describen brevemente a continuación.
 Capítulo 1: describe la motivación, los objetivos para la realización del TFG, y la vida
de la construcción de la app.
 Capítulo 2: muestra la toma de requisitos de cliente.
 Capítulo 3: muestra la valoración inicial realizada por la empresa que opta a la oferta,
valorando tiempo y costes.
 Capítulo 4: se describe el equipo que se va a utilizar para los desarrollos
 Capítulo 5: se muestra el ciclo de vida del proyecto especificando con detalle cuanto
tiempo se detalla para cada apartado
 Capítulos 6 y 7: se aborda la descripción tanto técnica como funcional
 Capítulo 8: muestra cómo serían las reuniones con el cliente.
 Capítulo 9: se detalla el final de la documentación.
 Capítulo 10: se muestran las conclusiones del TFG y los trabajos futuros.
3
 Capítulo 11: se muestra el impacto socioeconómico de la aplicación.

 Capítulo 12: refleja los costes del TFG
 Capítulo 13: se adjuntan los anexos.
 Capítulo 14: se adjunta las referencias bibliográficas
1.4 Organización del desarrollo de la aplicación
El ciclo de vida del desarrollo como IT se ha divido en 6 fases. Una primera enfocada a la
petición del cliente. La segunda como la propuesta inicial y valoración por parte de la empresa
que realiza el proyecto. La tercera y la cuarta para los análisis técnico y funcional del proyecto
realizado. La quinta para análisis de costes, personal y de recursos que se necesita y una última
y sexta para las pruebas de la aplicación.
A cada paso de esta organización se debería incluir una validación previa del responsable de la
empresa contratista. Dicha validación es importante ya que todo lo que quede validado sentará
precedente, y si el proyecto es cerrado no podrán modificarnos mucho los desarrollos
favoreciendo así que no haya cambios de planteamientos ni de tiempos. También nos ayudará a
tener todo claro de cómo quedará el programa sin tener que estar perdiendo tiempo en
comunicaciones con el cliente. Además el cliente se hará una idea muy cercana a cómo será el
resultado final lo que le permitirá reflexionar a tiempo sobre diferentes aspectos del portal.
Valoración inicial de rentabilidad y presentacion de propuesta

El cliente establece unos requisitos de proyecto Formación del
equipo de trabajo y construcción.
Plan de pruebas y Análisis funcional

Análisis técnico de
manual de usuario. de la solución
la solución
Ilustración 1: Vida del proyecto desde TI
El comercial sería la persona que nos haría llegar la oferta y junto con su primera valoración,
pediría al jefe de proyecto que presentara su valoración inicial y elaborara una propuesta para
presentar en la oferta del cliente. El cliente cuenta con unos medios (sino los contrata) para
determinar que oferta es la mejor y trata de intentar cumplir todas las exigencias. Una vez que
4
se ha ganado la oferta antes de empezar con el desarrollo ha y que elaborar una documentación
técnica y funcional y elaborar un plan de trabajo.
Una vez que se tiene todo eso se procede a la implementación de la solución propuesta
adaptándose lo más fielmente posible a los análisis técnicos y funcionales. No siempre la
primera idea es la que acaba siendo ganadora por lo que para eso están las reuniones con el
cliente. Una vez acabado se realiza el plan de pruebas propuesto, el cual uno real, sería mucho
más extenso que el que propongo en el apartado de plan de prueba. Para terminar se entregaría
el manual de usuario con toda la funcionalidad descrita para un usuario final.
Cuando estuviera todo se pasaría a implementar en los servidores del cliente.
1.5 Control del documento del TFG
En la siguiente tabla se muestra la evolución de dicho documento con la descripción de los

cambios realizados.
VERSIÓN FECHA DESCRIPCION DE LOS CAMBIOS

1.0 20/02/2018 Versión inicial del documento
1.1 26/02/2018 Inclusión del descripción técnica
1.2 2/03/2018 Inclusión de arquitectura
1.3 19/03/2018 Inclusión de Seo y seguridad
1.4 02/04/2018 Casos de pruebas
1.5 10/04/2018 Pruebas de aplicación
1.6 01/05/2018 Inclusión de anexos
1.7 10/05/2018 Inclusión de mapas de imágenes y tablas
1.8 06/05/2018 Inclusión costes y Gantt
Tabla 1: Versión de modificaciones de documento del proyecto de la empresa JMSOLUTIONSL
5
2. Toma de requisitos del cliente
El siguiente capítulo se presenta la documentación correspondiente que habría que presentar

debido a la toma requisitos que solicita el cliente a nivel de contenidos, objetivos que quiera que
cumpla la empresa que lo realiza, ya sea exigencias de accesibilidad o posicionamiento en la
web. En dichas peticiones realizadas por el cliente no se especifica que es o cómo hacerlo sino
que simplemente lo quiere y así lo especifica. El cómo hacerlo se trata en el capítulo de
descripción técnica.
2.1 Cláusula de responsabilidad / confidencialidad
La cláusula de confidencialidad es un pacto de confidencialidad entre la empresa contratante y

la empresa contratada en la cual se comprometen a seguir unos acuerdos para mantener la
información en secreto y de no revelar ningún tipo de dato a terceros. La duración es a elección
de la empresa contratante pero por lo general tiene una longitud de dos años. A continuación se
intenta mostrar cómo se formaría una cláusula de confidencialidad.
De aquí en adelante se han establecido dos empresas a modo de ejemplo, la que contrata los
servicios (Empresa_contrante_1) y la que realiza los desarrollos (JMSOLUTIONSL).
En primer lugar se daría la información tanto del contratista como del contratado figurando
entre esta información los nombres de las empresas, dichos números de identificación y
contratos mercantiles y declarando que son mayores de edad.
Después figuraran una serie de cláusulas pues son de obligado cumplimiento las cuales son
importantes entender bien.
Entre las cláusulas figura una primera en la que la empresa contratada se compromete y se
obliga a no divulgar información de la empresa a terceras partes o que no sacará un provecho
futuro. Una segunda y tercera por la cual se compromete a que firmará todo el equipo de la
empresa desarrolladora y se informará a los empleados de que están manejando información
sensible y confidencial. Una cuarta por la cual se comprometen a utilizar la información dada
solo para realizar los desarrollos y sin ningún objetivo más. La quinta por la cual se compromete
a proteger estos datos de la debida manera para que no haya fugas o extravíos. En la sexta se
compromete a que cumplirá según la nueva ley de protección de datos con todos los apartados
que esta informa.
Firmarían los dos participantes
El incumplimiento del contrato puede conllevar problemas para el empleado que lo viole desde
del fulminante despedido ya que el incumplimiento de confidencialidad seguramente también
conlleve incumplir el contrato firmado. Además puede ser demandado por violación e
confidencialidad llegando a tener que pagar. En extremadas situación puede conllevar hasta
cargos penales.
6
Esto es importante recordarlo ya que con la última modificación de la ley de protección de datos
(RGPD) se han endurecido las condiciones y los datos de carácter personal deben ser guardados.
La nueva ley entro el 25 de mayo de 2018 y supone la modificación de la antigua ley 15/1999
por la que endurece la gestión, almacenamiento de datos y la cesión de datos a terceros. En
dichas nuevas leyes se incluyen que todo usuario tiene que dar un consentimiento explícito para
que la empresa maneje sus datos y que dicha información puede ser solicitada, modificada y
borrada por el usuario haciendo a este último participe en cuanto el almacenamiento de sus
datos se refiere. Además se obliga a que los términos y condiciones estén expresados en un
lenguaje más coloquial en lugar de términos indescifrables para un usuario medio. Las multas a
las empresas por no cumplir la normativa pueden alcanzar desde 20 millones de euros o el 4%
de la facturación total de la empresa.
Se adjunta en anexos una cláusula de confidencialidad a modo de ejemplo.
2.2 Gestión de la calidad
En este apartado la empresa contratante pretende que la empresa contratada se comprometa a

que cumpla una serie de requisitos de traspaso de información entre ambas facilitando así la
comprensión de en lo que se está trabajando, como se está evolucionando, los posibles
problemas que se están encontrando para estar mejor informado del desarrollo de la aplicación.
2.2.1 Comunicación y seguimiento del proyecto
En la sección de comunicación y seguimiento de proyecto se establecerían los mecanismos y

tiempos de comunicación entre empresa contratante y empresa contratada incluyendo una serie
de puntos que deben de cumplir relacionados con este tema como son:
 Los documentos descritos en las diferentes fases del proyecto como son el análisis
funcional y el análisis técnico, tendrán que estar previamente validados.
 Informes de situación periódicos que incluyen:
o Planificación del proyecto actualizada desde el último informe de situación que
se envió hasta el momento, para detectar desvíos sobre la planificación inicial.
o Documento describiendo las incidencias que se han dado desde el último
informe de situación y como han repercutido en la planificación del proyecto.
o Documento describiendo los posibles riesgos, responsables e impacto que
puedan tener en la planificación del proyecto.
o Comentarios del consultor respecto a la situación actual.
 Actas de reunión
7
2.3 Visión actual del proyecto
En el siguiente apartado se trata, lo que el cliente está demandando y necesita que cumpla su
aplicación ya sea por legislación, posicionamiento, marketing… Lo que se trata de documentar
aquí es que se conoce lo que están pidiendo y se entiende que tiene un marco regulatorio y de
posicionamiento el cual se debe conocer.
2.3.1 Descripción de la necesidad a cubrir
Con el fin de evaluar uno de los criterios que tiene la empresa para escoger a la empresa que
realizará los desarrollos cada empresa tiene que expresar que ha quedado claro lo que el cliente
necesita y por esta razón se les explica lo que nosotros hemos entendido que ellos quieren.
Se expone a continuación una descripción de lo que el cliente demanda.
Se pretende el diseño de una aplicación web en la que los usuarios puedan ver, organizar y
apuntarse a partidos de una multitud de deportes. Esto se escogerá con tres combos que hay en
la parte inicial y mostraran los deportes disponibles, las zonas y los horarios disponibles para la
búsqueda. Para realizar dicha búsqueda se deberá estar logado por lo que si no se está y se
quiere buscar deberá saltar un pop up indicando que se logue. En dicho pop up deberá contener
un enlace para el caso en el que el usuario se olvide de la contraseña y un botón para poder
permanecer logado sin necesidad de tener que logarse siempre cada que vez que se entre en la
aplicación. Habrá una parte anónima y otra parte en la que el usuario tendrá que logarse. Cada
usuario poseerá un área personal en el que tendrá un histórico y los datos de su perfil. Cada
usuario podrá crear los partidos configurándolos acorde a las búsquedas de la home. Deberá
contener una mínima estructura que sea igual en todas las partes del portal. Deberá contener una
cabecera o header y un pie de página o footer en los cuales figure en el caso del header el logo
de la aplicación una opción para poder cambiar de idioma, un link para registrarse y un link para
poder acceder con tu usuario y contraseña. En el footer tendrá que contener el copyright con la
marca y los enlaces tanto a la home como a los términos y condiciones y privacidad del sitio. En
la página de los partidos se deberá mostrar en una tabla. Los colores del portal deberán ser de
los mismos del corporativo.
La aplicación debe estar construida con una tecnología moderna y escalable y a la par ser
responsive para la visualización desde todo tipo de dispositivos y para distintos tamaños de
pantalla. Debe ser segura puesto que poseerá una plataforma de pago y adaptarse a los
estándares de desarrollo mundiales.
8
2.3.2 Descripción de contenidos por página
En las siguientes tablas se muestran los contenidos que la empresa

EMPRESA_CONTRANTANTE_1 solicita a la empresa JMSOLUTIONSL contratada que quiere
que contenga tanto el orden como la forma de los elementos.
1.) PÁGINA INICIAL
Tabla en la que la empresa solicitante declara los elementos que tiene que tener cada página, en
este caso la página de resultado de búsqueda. Los elementos se nombran en el orden que deben
aparecer.
PAGINA ZONA ELEMENTO Características del

elemento
Home cabecera Logo de la aplicación A la izquierda y del

tamaño del de la
cabecera.
Selector de idioma Debe ser un

desplegable con tres
opciones de idioma,
español inglés y
portugués. Situado en
la parte derecha
Enlace para Un enlace con icono

registrarse de persona el cual
llevara a la página de
registro.
Enlace para logarse En la parte derecha

del todo. Contendrá
un icono de acceso y
mostrará una ventana
modal para poder
poner el usuario y la
contraseña
Pie de página Párrafo con el En la parte izquierda

copyright de la y en gris
empresa
Enlace a la página Primero de los 3

principal enlaces en
azul
Enlace a política de En segundo lugar
privacidad
9
Enlace a términos y En tercer lugar

condiciones
contenido Combo 1 verde Mostrará un párrafo

que indica que es lo
que muestra en este
caso el deporte y los
deportes
seleccionables
Combo 2 naranja Mostrará un párrafo

que muestra En este
caso la zona y las
zonas seleccionables
Combo 3 azul Mostrará un párrafo

que muestra En este
caso el horario y los
horarios disponibles
Botón buscar Botón azul para

buscar
Tabla 2: Descripción de los contenidos que se deben mostrar en la página inicial a petición de
EMPRESA_CONTRANTANTE_1.
2.) PÁGINA DE RESULTADOS DE BUSQUEDA
este caso la página de resultado de búsqueda. Los elementos se nombran en el orden que deben
aparecer.
PÁGINA ZONA ELEMENTO Características del

elemento

tamaño del de la
cabecera.

opciones de idioma,
español inglés y
la parte derecha
1
Enlace con el nombre Llevará a las

del usuario logado propiedades del
perfil.
Enlace para salir de la Con icono de salir.

parte logada Preguntará al usuario
si desea salir con un
pop up

empresa

principal enlaces en azul

privacidad

condiciones
contenido Texto Mostrará un título

que indica que son
los partidos
disponibles
Tabla Mostrará una tabla en

el que se muestre el
id del partido el
deporte seleccionado
el lugar el campo la
fecha y el número de
integrantes. Dicha
tabla deberá contener
un botón para
apuntarse y se deberá
negar poder apuntarse
si el número de
integrantes ya está
lleno.
Botón crear partido Botón azul encima de

la tabla
Tabla 3: Descripción de los contenidos que se deben mostrar en la página de resultados a petición de
EMPRESA_CONTRANTANTE_1
3.) PÁGINA DE CREAR PARTIDO
1
este caso la página de crear partido. Los elementos se nombran en el orden que deben aparecer.

elemento

tamaño del de la
cabecera.

opciones de idioma,
español inglés y
la parte derecha

perfil.

pop up

empresa

principal enlaces en azul.
Enlace a política de En segundo lugar.

privacidad
Enlace a términos y En tercer lugar.

condiciones
contenido Formulario para crear Deberá contener una

un partido etiqueta en el lado
izquierdo y el campo
en el lado derecho.
Los campos son
nombre deporte,
lugar, fecha
integrantes y
comentarios.
Etiqueta Etiqueta que indica

registro.
1
Tabla 4: Descripción de los contenidos que se deben mostrar en la página de crear partido a petición de
EMPRESA_CONTRATANTE_1
4.) PAGINA DE REGISTRARSE
este caso la página de registrarse. Los elementos se nombran en el orden que deben aparecer.

elemento

tamaño del de la
cabecera.

opciones de idioma,
español inglés y
la parte derecha

perfil.

pop up

empresa

principal enlaces en azul

privacidad

condiciones
contenido Formulario para Deberá contener una

registrarse etiqueta en el lado
izquierdo y el campo
en el lado derecho.
Los campos son,
nombre, apellidos,
1
fecha de nacimiento,
email, contraseña y
población.
etiqueta Etiqueta que indica

registro
Tabla 5: Descripción de los contenidos que se deben mostrar en la página de registro a petición de
EMPRESA_CONTRATANTE_1
2.3.3 Requisitos Globales
En la parte de requisitos globales se muestran una serie de requisitos que deben ser estándar en
todas las partes del aplicativo siendo funciones comunes por ejemplo temas de posicionamiento
SEO, accesibilidad etc.
Se menciona una lista de requisitos considerados globales para la web:

 La aplicación debe ser multi-idioma en contenidos, en Inglés, Portugués y Español
siendo este último, el idioma por defecto.
 Accesibilidad, siendo de obligado cumplimiento la normativa Doble A
 Todas las páginas deben ser imprimibles.
 Integración con sistemas tratamiento de errores, Log de aplicación, configuración
centralizada, SEO (Search Engine Optimization), posicionamiento en buscadores, etc.)
 Se deberá cumplir la nueva ley de protección de datos ( Ley RGPD citada en el anexo)
2.3.4 Requisitos de rendimiento
En la era digital en la que vivimos la gente consume contenidos web desde cualquier sitio y se
requiere que la carga de las páginas sea dinámica y rápida. Esto hará una experiencia de usuario
favorable a la aplicación. Además la velocidad de carga de la aplicación web puede ayudar al
posicionamiento SEO (Search Engine Optimization). A continuación se muestra, lo que la
empresa cliente pediría en cuanto a requisitos de rendimiento.
Deberá superar test de rendimiento en cuanto tiempo y velocidad de carga a una velocidad
estándar.
Dichas pruebas se realizaran en el plan de pruebas y mediante el uso de la aplicación de Google

llamada Page Speed test donde especifica la velocidad y la optimización dando una serie de
consejos para la mejora.
1
2.3.5 Requisitos de usabilidad
El dueño de la aplicación quiere que dicho aplicativo sea lo más fácil de usar posible
permitiendo así llegar a un número mayor de personas y para eso declara unos requisitos de
usabilidad de obligado cumplimiento como por ejemplo:
La aplicación debe ser los más intuitiva posible para facilitar el uso a los usuarios, con botones
y paneles grandes y pasos fácilmente identificables. El orden de las ejecuciones y de los pasos
deben seguir una lógica y debe ser la misma en todo el portal.
2.3.6 Requisitos de accesibilidad
El cliente busca con este requisito pasar una serie de normas para tener certificaciones de
accesibilidad y así una vez más llegar a más personas.
En la medida de lo que sea posible, se tendrá que garantizar que existe un nivel mínimo de
accesibilidad en todas las páginas, para las personas que tienen necesidades especiales. Por lo
que se impone que debe contener el nivel de accesibilidad doble A.
Para cumplir dicho nivel hay que seguir una serie de criterios interpuestos WCAG 2.0 (pautas
de accesibilidad del contenido en la web 2.0) tales como.
Dichas pautas se pueden resumir en:
 Todo contenido que no sea texto debe contener una alternativa textual por ejemplo a las
imágenes tener una alternativa de texto
 Que una persona con ceguera pueda tener una alternativa de audio
 Introducir subtítulos en todos los videos.
 El foco de situación del usuario tiene que estar visible y claramente diferenciado del
lugar en el que se encuentra.
 Indicación en errores a la hora de rellenar de datos de formularios.
 Uso de colores para distinguir más fácilmente los elementos visuales.
 Toda funcionalidad debe ser accesible mediante el teclado por ejemplo con el uso del
tabulador, flechas…
 El idioma predeterminado de cada página puede ser determinado por el software
 Contraste entre elementos de la web como por ejemplo textos, logotipos y cuadros.
 Múltiples vías para llegar a una misma página dentro de la aplicación
 Navegación coherente y en el mismo orden dentro del portal
Se busca poder incorporar el sello de doble A al portal web
La siguiente imagen muestra el sello de cumplir dichos requisitos.
1
Ilustración 2: Sello indicador de accesibilidad según los estándares especificados en la AA
2.3.7 Requisitos de posicionamiento
La programación de dicha aplicación debe contemplar que estará colgada en una web en la que
se buscará un mejor posicionamiento para la indexación en Google por lo que deberá cubrir
todos los requisitos que requiera Google para su correcta indexación.
Se deberán seguir los siguientes pasos para la correcta indexación:
 Crear títulos de páginas únicos y precisos

 Utilización de etiquetas “meta”
 Utilización de etiquetas de encabezado
 Utilización de etiquetas de datos estructurados
 Creación de urls amigables y lógicas.
 Creación de sitemaps y robots.
2.4 Criterios que sigue el cliente para escoger a la empresa que desarrollará
su aplicación.
En el siguiente apartado se describen los criterios que la Empresa_contratante_1 ha establecido

para elegir a la empresa que efectuará el desarrollo y así mismo para tener un peso en futuros
desarrollos.
La siguiente tabla muestra la relación de los criterios de evaluación y su peso.
Criterio Importancia Peso
Interpretación por parte del Máxima 3

equipo de la propuesta e
implicación mostrada en el
desarrollo de la misma
Entrega de ejemplos, Máxima 3

plantillas etc
Metodologia de desarrollo Alta 3

para proporcionar
escalabilidad y sencillez
Descripcion minuciosa de la Alta 2

oferta
1
Otros desarrollos de Alta 2

aplicaciones similares
Tamaño del equipo y Alta 2

diferenciación de roles
Linea de comunicación Alta 2

abierta
Coste total cercano al previsto Alta 2

y ofertado
Tiempo total para el Alta 2

desarrollo cercano al previsto
y ofertado
Experiencia aportada con la Media 1

misma tecnología
Número de proyecto Media 1

aportados como aval
Flexibilidad en cambios Media 1

anunciados
Garantía de mantenimiento Media 1
Resolución de problemas Media 1

críticos
Tabla 6: Criterios para selección de oferta ganadora
Se hará una valoración total de cada oferta y la que sume más puntos será la que resulte
ganadora.
El sacar la mayor puntuación en esta tabla significa ganar la oferta y tener el desarrollo por lo
que es fundamental que se presente unos buenos requisitos previos.
1
3. Valoración inicial del proyecto por parte de JMSOLUTIONSL
Este capítulo muestra como documentar la primera estimación que se realizará con el objetivo
de presentar la oferta. En esta, se estima tanto costes como necesidades de tiempo y personal
basándose en otras experiencias. Esto junto con la toma de requisitos debe de ser los primeros
documentos que se envíen al cliente.
En la valoración inicial, se trata de indicar aproximadamente y sin muchas especificaciones

cuanto se tardaría en el desarrollo y con qué coste aproximadamente se llevaría a cabo
mostrando así que se tiene una idea global del proyecto, lo cual es buen síntoma para dar ver
que se ha entendido. Esto no es nada vinculante pero tiene que ser una aproximación real a lo
que se debe entregar después. Hay que justificar mínimamente el porqué de cada tiempo.
Se realiza una primera valoración tomando como referencia pequeños desarrollos de prueba
para la medición de tiempo y esfuerzos. La siguiente descripción es una primera valoración
inicial para trasladar al cliente, dando una aproximación del coste, de las fases del proyecto y de
la duración del mismo. La especificación de todos los valores se realizará en el capítulo de plan
de ejecución. Esta primera valoración nos permite ver a nuestra empresa si realmente somos
competitivos y podemos optar a la oferta que presenta la empresa del cliente. Si hemos optado
por definir un coste aproximado de unos 30.000€ si la empresa cliente diera como objetivo estar
por debajo de esto, a nosotros como empresa a priori no nos compensaría pelear por este
proyecto. Habría que estudiar muchos factores más, como un posible acuerdo de mantenimiento
o posibles futuros desarrollos en los que nos permitiría ganar quizás lo que perdiéramos en el
desarrollo.
 Duración aproximada de los trabajos: 17 semanas
 Fases contempladas: Análisis, diseño, maquetación, desarrollo, despliegue y formación.
 Recursos necesarios y coste:
o Jefe de proyecto: 10.000 €
o Equipo para su desarrollo : entre 20.000 €
La planificación temporal de los trabajos a realizar sería la siguiente:
Tabla 7: Planificación inicial por parte de la empresa JMSOLUTIONSL especificando las partes
La planificación anterior se fundamenta en los siguientes puntos:
1
Fase Tareas Experiencias anteriores
Análisis y diseño técnico ·Análisis funcional detallado. Esta fase nos llevó unos dos 2
semanas.
·Diseño técnico del sistema.
·Validación por todas las

áreas implicadas.
Desarrollo ·Construcción y maquetación En otros proyectos de igual
de la aplicación. envergadura hemos utilizado
unas 10 semanas
Implantación y despliegues ·Instalación en todos los En todas las aplicaciones

entornos desarrolladas recientemente
este período ha sido mayor en
·Pruebas de validación.
la mayor parte de los casos.(2
·Test de intrusión. semanas)
·Puesta en producción.
Tabla 8: Explicación a la tabla 6 del porqué de la duración de cada fase
1
4. Equipo de trabajo y construcción para la realización del proyecto
Con el fin de la realización del proyecto y de cumplir con las exigencias que muestra el cliente o
bien satisfacer los acuerdos llegados con este mismo, hay que constituir el equipo de trabajo,
para mandárselo al cliente ya que es un punto de exigencia por el cual valoran positivamente la
división en roles y la distinción de estos mismos en distintas personas del equipo. Se trata de
mostrar que se posee un equipo variado y experimentado en el que se lleva a cabo la división
por tareas y que cada integrante tiene su rol. Es importante que la empresa cliente vea esta
división de roles para la suma de puntos según sus criterios. Hay que saber con antelación que
equipo va a formar el desarrollo aun que luego se puede hacer cambios previa información al
cliente. Además no solo está en que el equipo se variado y divido en roles sino que se busca
mostrar la experiencia de cada uno por lo que también se identifica muchas veces la experiencia
de cada integrantes llegando a aportar CV si fuera necesario. Todo va encaminado por parte de
la empresa a asegurarse que el desarrollo se hace con calidad y que todo saldrá según lo
previsto.
La siguiente información habría que enviársela al cliente o bien se presentaría en una de las
reuniones semanales que estipulan.
Para la realización del proyecto se necesitaran un grupo de trabajo formado por un director del
proyecto, un jefe de proyecto, dos programadores, un maquetado y un analista.
El director del proyecto que junto con el jefe de proyecto se encarga de estar en contacto con el
cliente para los temas económicos y posibles dudas por parte de este. El jefe de proyecto es la
persona que controla el progreso de la aplicación y la que se encarga de ajustar tiempos y
esfuerzos. Es el encargado de informar al director de proyecto de porcentaje evolucionado y de
las posibles incidencias que vayan saliendo.
Los programadores son los encargados del completo desarrollo back-end de la aplicación. Los
maquetadores serán los encargados de la parte del front-end y de ajustar los estilos y la parte
visual de la aplicación y aportando diseños de imágenes botones etc.
El analista es el encargado de formar la arquitectura y detectar posibles fallos de

funcionamiento. Es el encargado de comprobar todas las casuísticas de la aplicación y a la par
desarrollar la documentación tanto técnica como funcional para el cliente.
2
Ilustración 3: Equipo de trabajo
PERFIL DESCRIPCIÓN
Director de proyecto Su objetivo es dar un soporte a todas las

partes del proyecto. Es un perfil con una
experiencia alta en proyectos de igual alcance.
Asiste a las reuniones propuestas para el
control y seguimiento.
Jefe de proyecto Es el responsable de la ejecución y del

cumplimiento tanto de tiempos como
objetivos del proyecto. Deberá coordinar al
equipo de trabajo, coordinarse con el cliente,
… Será el encargado de revisar el transcurso
del proyecto y las incidencias ocurridas con el
fin de garantizar el cumplimiento de tiempos
y objetivos.
Analista Funcional Tendrá una gran experiencia y conocimiento

en dicho sector, y estará coordinado y en
comunicación con el Jefe de Proyecto en
todo momento. Es el encargado de todas las
pruebas y validaciones
2
Analista Programador Experto técnico en desarrollo de aplicaciones

con tecnología .NET Será el encargado de la
realización del diseño técnico-funcional en
código fuente.
Diseñador / Maquetador Experto técnico en desarrollo de aplicaciones

en el aspecto visual y renderizado.
Tabla 9: Descripción de los perfiles necesitados para el desarrollo
El equipo de JMSOLUTIONSL destinado a desarrollo de aplicaciones dispone de los recursos

hardware, software y de soporte necesarios para llevar acabo los servicios para el desarrollo de
dicha aplicación con la mayor eficacia posible.
A continuación se detallan las tarifas correspondientes a los perfiles contemplados:
PUESTO PRECIO/HORA HORAS TRABAJADAS TOTAL
Jefe de Proyecto 35 €/h 560 horas 19600€
Desarrollador senior 1 30 €/h 560 horas 16800€
Desarrollador senior 2 30 €/h 560 horas 16800€
Analista 25 €/h 120 horas 3000€
Maquetar/diseñador 25 €/h 120 horas 3000€
TOTAL 1920 59200€

Tabla 10: Precios según puesto
Los precios ofertados no incluyen el IVA.
Forma de Pago. El último día de cada mes se emitirá una factura correspondiente a los trabajos
realizados durante el mes. El vencimiento de las facturas será a 30 días desde su fecha de
emisión.
2
5. Plan de ejecución de desarrollo de la aplicación por parte de

JMSOLUTIONSL
Junto con el equipo de trabajo, es

fundamental hacer un buen
diagrama de desarrollo del
proyecto indicando en cada
momento la duración de las tareas
que se están realizando. Esto no
solo es importante para el cliente
sino para la empresa que
desarrolla puesto que le permite
tener controlados los tiempos y el
orden del desarrollo.
En el siguiente plan de ejecución

se muestra el orden en el que se ha
desarrollado las tareas y la
duración de las mismas.
En el cual se puede observar que

la mayor parte se ha dedicado al
desarrollo. Pero también cabe
destacar que la parte de análisis y
diseño previa es muy importante
ocupando así casi un tercio del
proyecto. Una fase de análisis y
diseño efectiva ayudará a una
mejor construcción y
planificación. Permite resolver
previamente futuras dudas de
diseño y programación
permitiendo anticiparse a futuras
eventualidades.
Dicho plan se le entregará al

cliente como prueba de que se
tiene todo previsto y para poder ir
haciendo un seguimiento de dicha
aplicación. También es una media
de justificación de tiempo por el
que se declara en cada momento
lo que se está haciendo y el porqué
de que haya tardado un tiempo u
otro.
23
6. Descripción de la solución técnica propuesta
En este capítulo se describe como tiene que ser la presentación de la documentación técnica que
se le manda al cliente. En dicha documentación se debe exponer el modelo de programación que
se va a realizar, detallando cada componente al mínimo para que sea validado por este. El
objetivo de este apartado es poder adelantarse a posibles problemas, fallos, errores… pudiendo
así ahorrar costes y tiempos.
Esta es una documentación que a priori podemos pensar que el cliente como sector no técnico
que es, puede no interesarle pero prestan especial atención puesto que muchas veces poseen
licencias de algunas librerías en concreto que quieren que uses, o justo lo contrario no quieren
que uses algún tipo de tecnología simplemente porque no está a la moda o no es lo demandado
hoy. Un ejemplo de esto, es la demanda por parte de las empresas de desarrollar todo utilizando
Bootstrap o Angular que como se puso de moda, las empresas requerían estos desarrollos
expresamente. Esta documentación también es requerida ya que en un futuro si quisieran
mejorar la aplicación por ejemplo pues sería parte de la documentación que ellos entregarían a
la siguiente empresa que desarrollara para que siguieran con el mismo orden y la misma
nomenclatura del modelo.
6.1 Arquitectura
MVC es un modelo de programación que está de moda actualmente y está disponible en

ASP.NET. Las aplicaciones MVC se caracterizan por una fuerte separación de la capa lógica
del código de acceso a datos y la interfaz de usuario en Modelos, Controladores y Vistas.
Ilustración 4: Arquitectura MVC
24
6.1.1. Modelo
Nuestro sitio web presenta información y contenido sobre objetos. Todas las validaciones de
todos los campos deben hacerse aquí y no en el controlador. Por ejemplo las validación de los
input, ya sea para controlar el formato, la dimensión o simplemente que no este vacío debe
hacerse aquí. Se adjunta en los anexos un ejemplo de validación por modelo.
El nombre de las propiedades de las clases han seguido la taxonomía de CLASEX+NOMBRE
DE VARIABLE. Es fundamental seguir la misma nomenclatura siempre ya que nos permite
identificar donde estamos y a que clase pertenece el elemento en cuestión.
A continuación definimos La arquitectura de nuestro modelo que ha seguido las siguientes
clases con sus propiedades.
6.1.1.1. Clase Usuario
Para la clase Usuario se han establecido las siguientes propiedades que debe contener,
especificando el nombre interno, el tipo de variable que se utiliza y la longitud máxima de esta
última.
Campo Nombre de Variable Tipo Longitud Max
Id UserID int 8 carácteres
Nombre UserName String 20 carácteres
Apellidos UserSurname String 40 carácteres

UserEmail String 40 carácteres
Email
Teléfono UserPhoneNumber String 9 caracteres
Domicilio UserAddress String 40 carácteres
Puntuación UserPoint Int 4 carácteres
Ultima Conexión UserLastSession Date
Token UserToken String 16 carácteres
Contraseña UserPassword String 8 carácteres
Fecha de nacimiento UserBirh Date
Partidos UserPartidos Partidos
Zona de juego UserZone Zona

Tabla 11: Propiedades utilizadas para la clase Usuario
25
6.1.1.2. Clase Partido
Para la clase Partido se han establecido las siguientes propiedades que debe contener,
especificando el nombre interno, el tipo de variable que se utiliza y la longitud máxima de esta
última.
Id MatchID int 6 carácteres
Fecha MatchDate Date 8 carácteres
Lugar MatchPlace String 20 carácteres
Hora MatchTime Date
Integrantes MatchPlayerNumber int 40 carácteres
Administrador MatchUserCreator String 9 caracteres
Deporte MatchType String 40 carácteres
Zona MatchZone Int 4 carácteres
Ultima Conexión UserLastSession Date

Tabla 12: Propiedades utilizadas para la clase Partido
6.1.1.3. Clase Deporte
Para la clase Deporte se han establecido los siguientes campos que debe contener especificando
el nombre interno, el tipo de variable que se utiliza y la longitud máxima de esta ultima
Id SportID int 6 carácteres
Nombre SportName String 8 carácteres
Integrantes MatchPlayerNumber int 40 carácteres

Tabla 13: Propiedades utilizadas para la clase Deporte
6.1.1.4. Clase Sesión
Para la clase Sesion se han establecido los siguientes campos que debe contener especificando el
nombre interno, el tipo de variable que se utiliza y la longitud máxima de esta última
26
Id SessionID int 16carácteres
Fecha SessionDate date Tipo estándar

Tabla 14: Propiedades utilizadas para la clase Sesión
6.1.2. Vista
Las vistas contendrán código HTML para que el navegador lo pueda mostrar. Contendrán los
modelos y representarán los objetos mostrando así la información. Dicho código HTML se
mezcla con C# para dar archivos CSHTML. La vista solo mostrar código de interfaz de usuario
dejando la lógica al modelo y al controlador. Se ha usado Razor como motor de vistas en el que
nos permite separar la sintaxis de servidor de la del framewor de asp.net MVC.
Están dividas en nuestra arquitectura dependiendo de si son vistas parciales pertenecientes a un

controlador o compartidas
Ilustración 5: Arquitectura de ficheros de la Vista
6.1.3. Controlador
Es el que una vez echa todas las comprobación de cara a la interfaz de usuario se encarga de
hacer la lógica de nuestro programa, es decir, inserción y extracción en bases de datos,
operación lógicas etc.
MVC (Model, View, Controller) será nuestro patrón de diseño, pero nuestra arquitectura se
dividirá por capas.
Tenemos 3 controladores
 HomeController : El encargado del inicio

 AccountController : el que controla la sesión y datos del usuario
 MatchController : el encargado de temas relacionados con la creación e
ilustración de partidos
Realmente el homeController no es el encargado del inicio por la nomenclatura que lleve como
podía pasar en HTML donde el que carga por defecto es el index.html sino que se ha definido
en la configuración que ese será el controlador encargado del arranque.
27
Ilustración 6: Arquitectura de ficheros del controlador
6.1.4. Capas
Las capas son:
6.1.4.1. Properties
Donde se encuentra el “AssemblyInfo.cs” con la información del proyecto como el GUID, el

copyright, el título, descripción…
Ilustración 7: Arquitectura de los ficheros de las propiedades del proyecto
6.1.4.2. References
Esta es la parte de la arquitectura donde se encuentran todas las DLL del proyecto. Dichas DLL
son código de terceros que es público y gratuito y se utilizan para ahorrar tiempo y costes. En
dichas librerías ya vienen implementadas multitud de funciones que solo consisten en llamarlas.
En este caso usamos EntityFramework .Data, System…
EntityFramework la utilizamos para realizar la comunicación con las bases de datos. La he

utilizado ya que nos permite crear la estructura de base de datos sin necesidad de introducir
lenguaje SQL en dicha base de datos sino que desde el proyecto y con pseudo-código creamos la
estructura y la comunicación.
28
Ilustración 8: Arquitectura de las librerías referenciadas
6.1.4.3. Migrations
Con las clases para la formación del tablas de datos en servidor. Con EntityFramework
formaremos las tablas sin tener que acceder a Base de datos y sin tener que usar un lenguaje
SQL
Ilustración 9: Arquitectura de las migraciones en modificaciones
Contiene una clase llamada Configuration donde tendrá la configuración inicial por defecto y
los datos por defecto.
6.1.4.4. Models
Está formado por una carpeta “Procedures” donde se almacenan las clases de los objetos con
las propiedades propuestas en el apartado Modelo. Además contiene la clase Context en la que
se establece el contexto con la base de datos y el modelo.
29
Ilustración 10: Arquitectura del proyecto del modelo
6.1.4.5. Web.config
Donde están todos los parámetros de configuración. En dicho apartado se colocaran las cadenas
de conexión para establecer la comunicación con las bases de datos. Además se definirán
atributos para dichas conexiones.
Ilustración 11: Arquitectura de los parámetros de configuración
6.1.4.6. Scripts
Está divida por librerías. En este caso utilizamos Boostrap.js, JQuery. Son códigos de terceros
que se pueden usar gratuitamente para ahorrar tiempo. En nuestro proyecto en lugar de
referenciarlas las hemos importado para evitar problemas y errores
30
Ilustración 12: Arquitectura de scripts
6.1.4.7. Content
Donde se guardan los estilos .Css tanto los pertenecientes a librerías de terceros como los
creados por nosotros. Nuestras modificaciones estarán en Site.css
31
Ilustración 13: Arquitectura de librerías de estilos
6.1.4.8. Controllers
Los ya mencionados en el apartado controlador
Tenemos 3 controladores
 HomeController : El encargado del inicio

 AccountController : el que controla la sesión y datos del usuario
 MatchController : el encargado de temas relacionados con la creación e
ilustración de partidos
6.1.4.9. Views
Las ya mencionadas en el apartado Vistas
Están dividas en nuestra arquitectura dependiendo de si son vistas parciales pertenecientes a un

controlador o compartidas
6.2 Accesibilidad
El desarrollo del proyecto se centrará en cumplir las especificaciones WCAG (Web Content
Accessibility Guidelines) o guía para la accesibilidad del contenido web. Dichas
especificaciones cubren un amplio rango de recomendaciones para crear contenido web más
accesible para un mayor número de personas con discapacidades tales como ceguera, baja
visión, sordera y deficiencias auditivas. Dichas recomendaciones son aplicables a todas las
tecnologías puesto que no se centran en ninguna en concreto y se encuentran enumeradas en su
página web. Se resumen en:
1) Los componentes de la interfaz de usuario deben ser fácilmente diferenciados y percibidos
con claridad. Aumentar el tamaño de los textos y colores que resaltan unos sobre otro
haciendo un gran contraste.
2) Hacer predecibles el orden de las páginas en la web
3) Url amigables que permiten predecir en donde se encuentra y el orden lógico a seguir.
4) Proporcionar el tiempo suficiente a los usuarios para interactuar con la aplicación.
5) Proporcionar ayuda al usuario para llegar a todos los lugares de la aplicación y a
encontrarse de donde está.
6) Permitir el control de la aplicación mediante movimientos del teclado. Dichas operaciones
no deben requerir una velocidad determinada. EL foco del teclado debe ser claro y poder
moverse con el teclado.
7) No contenga contenido que pueda provocar ataques o convulsiones
8) Interfaz fácil de comprender
9) Ayudar al usuario a rellenar los formularios y campos con validaciones y ayudas.
10) El contenido tiene que ser robusto para que pueda ser interpretado por aplicaciones de
terceros por ejemplo aplicaciones que leen el contenido para personas con ceguera.
32
6.3 Componentes del portal
A continuación se describe, componente por componente, la implementación de la solución

detallando como es técnicamente cada componente en virtud de las exigencias explicadas en el
capítulo de requisitos de cliente.
6.3.1 Header
El Header o cabecera, deberá tener fondo acorde a la estética corporativa y ser de ancho entre
1cm y 1.5 cm para una pantalla de 15 pulgadas y en su versión landscape ya que tiene que
ocupar más del ancho del logo corporativo enviado por el cliente, como así ha planteado el
diseñador gráfico. Ese tamaño se corresponde con una pantalla estándar de portátil.
El color de todo lo que vaya dentro del Header deberá ser #9d9d9d debido a que el logo
corporativo facilitado tiene ese código de color y si es un enlace cuando se pase el ratón por
encima deberá cambiar de color a blanco para resaltar lo máximo posible que es un enlace.
A continuación se detallan los componentes en el orden que se quiere que se muestren y con las
características que el cliente habría expresado.
6.3.1.1 Logo
El logo es facilitado por la empresa contratante al deberse a un asunto meramente corporativo.

Desde la empresa que se encarga del desarrollo lo único que hace es adaptarlo al portal, al lugar
donde quieren que se vea y a adaptar dicho portal con los colores, letra, tamaño, separaciones
apropiados.
Ilustración 14: Logo corporativo de la aplicación
Propiedad Valor
Text W3ToPlay
33
Tipo Texto Literal
Background-color #333
Color #9d9d9d
Font-family Arial, Helvética
Font-size 31px
Hover:Color #fff
Tabla 15: Características de diseño del logo
6.3.1.2 Selector de idioma
Como se especifica en los requisitos, hay un selector de idioma con tres posibles valores:
español, inglés y portugués.
Propiedad Valor
Text Idioma
Tipo Dropdown
Color #9d9d9d
Font-family Arial, Helvetica
Font-size 15px
Hover:Color #fff
Values de <li> Español , Inglés, Portugués
Icono glyphicon-globe
Tabla 16: Características de diseño del selector de idioma
Selector de idioma en estado normal
Ilustración 15: Selector de idioma
Selector de idioma cuando se pasa por encima con el ratón y se hace clic
34
Ilustración 16: Selector de idioma cuando se pulsa sobre él
6.3.1.3 Enlace de registro
Características técnicas del enlace de registro. Dicho enlace llevara a una página para poder
registrarse. Dichas características obedecen para respetar la estética de la marca corporativa de
la aplicación.
Propiedad Valor
Text Registrase
Tipo Enlace
Color #9d9d9d
Font-size 15px
Hover:Color #fff
Icono glyphicon-user
Tabla 17: Características de diseño del enlace de registro
Enlace en estado normal
Ilustración 17: Enlace de registro
Campo al pasar por encima con el ratón
35
Ilustración 18: Enlace de registro al pasar por encima el ratón
6.3.1.4 Enlace de login
El enlace de login es el enlace que permite que nos identifiquemos ante la aplicación como
usuario reconocido. Dicho enlace tiene las características para respetar la estética corporativa.
Propiedad Valor
Text Acceso Usuarios
Tipo Enlace
Color #9d9d9d
Font-size 15px
Hover:Color #fff
Icono glyphicon-log-in
Tabla 18: Características de diseño del enlace de login
Enlace en estado normal
Ilustración 19: Enlace de acceso a usuarios
Enlace al pasar por encima con el ratón
Ilustración 20: Enlace de acceso a usuarios cuando se pasa por encima
36
6.3.2 Footer
Se ha adaptado el pie de página para respetar las exigencias del cliente y las actuales exigencias
legales. Está formado en la parte izquierda por el copyright con el nombre de la empresa a la
que pertenece los derechos y en la parte derecha los enlaces a la home por temas de SEO y los
contratos de privacidad y los términos y condiciones
6.3.2.1 CopyRight
Párrafo en el que indica la propiedad intelectual del propietario. Sus características se deben
para respetar la identidad corporativa.
Propiedad Valor
Text Jose Maria Rodriguez García CopyRight ©

2018
Tipo Texto Literal
Color #9d9d9d
Font-size 31px
Hover:Color #fff
Tabla 19: Características de diseño del párrafo de copyright
Está en la posición inferior izquierda a petición del cliente
Ilustración 21: Párrafo de copyright
6.3.2.2 Enlace a la Home
Para cumplir con exigencias de posicionamiento en la web (SEO) se debe incluir en todas las
páginas del portal un enlace a la página principal del sitio.
37
Las características de dicho enlace obedecen para satisfacer la estética de la página
Propiedad Valor
Text Home
Tipo Enlace
Color #337ab7
Font-size 15px
Hover:Color #fff
Tabla 20: Características de diseño del enlace a la home
Ilustración 22: Enlace a la home
6.3.2.3 Política de privacidad
Por cuestiones de legalidad se debe incluir el enlace de para poder leer las políticas de
privacidad.
Propiedad Valor
Text Política de privacidad
Tipo Enlace
Color #337ab7
Font-size 15px
Hover:Color #fff
Tabla 21: Características de diseño del enlace de políticas de privacidad
Ilustración 23: Enlace a políticas de privacidad
38
6.3.2.4 Términos y condiciones
Por cuestiones de legalidad se debe incluir el enlace de para poder leer los términos y
condiciones de la aplicación.
Propiedad Valor
Text Términos y condiciones
Tipo Enlace
Color #337ab7
Font-size 15px
Hover:Color #fff
Tabla 22: Características de diseño del enlace de términos y condiciones
6.3.3 Página maestra
La página maestra es la base de la que se mostrará en todas las partes del portal. Se compone de
una cabecera o header, de un contenedor donde estará el contenido y de un footer. El contenido
del Header y del footer está definido en dichos apartados.
Las características de la página maestra se deben para satisfacer las características corporativas.
Propiedad Valor
Tipo container
Background-color header #333
Color #337ab7
Background-color footer #333
Color #337ab7
Background-color body #lavender
39
Color #333
Font-size 15px
Hover: Color #fff

Tabla 23: Características de diseño de la página maestra
Por esta razón, la página maestra, al ser un elemento común en el cual se mostrará en todas las
partes del sitio web se ha hecho una vista parcial.
Ilustración 24: Página maestra
Tanto el pie de página como la cabecera están fijados en ambos extremos del monitor o pantalla.
Si el contenido fuera más alto que el contenedor aparecería una barra de scroll en la parte
derecha para poder deslizar el contenido hacia abajo sin que se muevan ni la cabecera ni el pie
de página
Ilustración 25: Barra de scroll
6.3.4 Home
Satisfaciendo la petición del cliente del contenido de la página principal, la home tiene tres
contenedores en el cual cada uno tiene un título y un select donde se elige la opción. Debajo de
todo esto tiene el botón de buscar.
40
6.3.4.1 Contenedor 1
El contenedor 1 hace referencia al contenedor de selección del deporte y el color es uno de los
tres que posee la compañía propietaria.
Propiedad Valor
Text Selecciona un deporte
Tipo Select
Background-color #lavender
Background-color jumbo # teal
Color #fff
Font-size 31px
Tabla 24: Características de diseño del contenedor 1
Y el resultado es:
Ilustración 26: Contenedor de selección de deporte
El contenedor 2 hace referencia al contenedor de selección de la zona y el color es el segundo de

los tres que posee la compañía propietaria.
41
Propiedad Valor
Text Selecciona una zona
Tipo Select
Background-color jumbo # coral
Color #fff
Font-size 31px
Tabla 25: Características de diseño del contenedor 2
Y gráficamente queda así:
Ilustración 27: Contenedor 2 selección de zona
El contenedor 3 hace referencia al contenedor de selección del horario y el color es el tercero de

los tres que posee la compañía propietaria.
Propiedad Valor
Text Selecciona un horario
42
Tipo Select
Background-color jumbo # cornflowerblue
Color #fff
Font-size 31px
Tabla 26: Características de diseño del contenedor 3 selector de horario
Y gráficamente queda así:
Ilustración 28: contenedor 3 selector de horario
Dichos combos se rellenan con lo que trae de la base de datos de las tablas correspondientes a
deportes zonas y horarios.
Una vez definida la página maestra y el contenido de la página principal habría dos posibles
casuísticas referentes a la página principal.
Una página principal en la que todavía no se ha logado y otra en la que se ha logado el usuario.
Para satisfacer la demanda del cliente, ya se ha explicado el caso anónimo pero en el caso del
logado se deberá quitar el enlace de registro y de acceso y se deberá introducir un enlace al
perfil de usuario que hace referencia su nombre.
Home sin logar
43
Ilustración 29: Página principal sin logar
Home logado
Ilustración 30: Página principal logado
6.3.5 Lista de partidos
La lista de partido es la página por la cual una vez hecha la búsqueda, es la página que muestra
un resumen de los partidos disponibles con las características filtradas.
Es un Grid en el que se muestran los siguientes:
 Modalidad: El deporte seleccionado.

 Lugar: Lugar exacto en el que se celebra el partido.
 Campo: campo en el que se jugará
44
 Fecha: en formato estándar dd/mm/yy hh:mm

 Integrantes: El número de integrantes apuntados / número de integrantes necesarios.
 Botón para apuntarse: Si el partido está lleno, se deshabilita el botón.
 Botón para crear nuevo partido.
Campo Tipo Orden
Modalidad String 1
Lugar String 2
Campo String 3
Fecha Date 4
Integrantes Int 5
Botón para apuntarse Button 6
Botón para crear Button 7

Tabla 27: Características de la lista de partidos
Gráficamente queda así:
Ilustración 31: Lista de partidos
Dicha tabla posee dos tipos de botones un botón para apuntarse, el cual solo está disponible en
estado verde cuando todavía faltan integrantes para cerrar el partido y otro azul para crear los un
partido nuevo con las características seleccionadas previamente.
En el caso de que un partido esté completo de integrantes el botón se deshabilita y aparece en

rojo impidiéndonos acceder para apuntarnos.
45
BOTON COMPORTAMIENTO
APUNTARSE VERDE REDIRIGIR A PAGINA APUNTARSE
APUNTARSE ROJO BOTON DESHABILITADO

Tabla 28: Lista de botones
Si está completo está en rojo sino está en verde
Ilustración 32: botones para apuntarse a partido
6.3.6 Crear Partido
En el caso de que se quiera crear un partido con unas características que prefiera el usuario, hay
el botón de crear partido en la parte superior de la tabla de partidos.
Ilustración 33: Botón crear partido
46
Botón Crear partido
Propiedad Valor
Text Crear Partido
Tipo Button
Background-color #blue primary
Color #white
Font-size 15px
Hover:Color #fff
Tabla 29: Propiedades del botón crear partido
Nos redirigirá a la pantalla para rellenar un formulario para poder crear un partido.
Propiedad Valor
Text Crea tu partido
Tipo Form
Background-color #white
Color #fff
Font-size 15px
Hover:Color #fff
Nombre Input
Deporte Input
Lugar Input
Fecha Input
Integrantes Input
Comentarios Input multiline

Tabla 30: Características del formulario de crear partido
47
Todos los campos tienen validación.
Gráficamente queda así.
Ilustración 34: Formulario de crear partido
6.3.7 Página de partido
Si entramos en las características de un partido, contiene dos tablas.
Una primera con las características del partido y otra segunda con los integrantes de dicho
partido, en el lugar de nuestro usuario aparece un botón para si se quiere borrarse del partido.
Ilustración 35: Página de partido seleccionado
Las propiedades de la tabla uno son:
48
Propiedad Valor
Text Id del partido
Tipo Grid
Color #fff
Font-size 15px
Hover:Color #fff
Modalidad label
Campo label
Lugar label
Fecha label
Integrantes label
Tabla 31: Propiedades de la tabla de partido
Las propiedades de la tabla de componentes del partido son:
Propiedad Valor
Text Integrantes
Tipo Grid
Color #fff
Font-size 15px
Hover:Color #fff
Nombre label
Email label
Equipo label
Botón borrar Button
49
Tabla 32: propiedades de la tabla de componentes del partido
6.3.8 Login
La ventana de login es la encargada de reconocer nuestro usuario y contactar con la base de

datos para validar dicho usuario. Contiene los elementos básicos de una ventana de login.
Dichos elementos son, la entrada del usuario, la entrada de la contraseña el botón de comprobar,
un botón de cancelar, un botón de recordarme y un enlace para el caso de que se haya olvidado
la contraseña.
Ilustración 36: Imagen de pop up de login
Propiedad Valor
Text Crear tu partido
Tipo Form
Color #fff
Font-size 15px
Hover:Color #fff
Email Input
50
Password Input
Botón de validar Button
Botón de cancelar Button
Check de recordar credenciales CheckBox
Olvido contraseña Enlace

Tabla 33: Propiedades de la ventana modal de login
Los campos de dicha ventana son:
 Email: tipo email con dicha validación

 Password: encriptada y se ocultará
 Botón de validar: valida los campos
 Botón de cancelar: cierra el pop up
 Check de recordar credenciales (Marcado predefinido)
 Enlace de olvido de password
Ilustración 37: ventana de login
Dicho formulario tiene validación contra hacking contra inyección, prohibiendo algunos
caracteres especiales y palabras reservadas como por ejemplo “>”,”<”,”script”,”/”. El botón
tiene validación de comprobar los campos si están vacíos o si son válidos. Ese validación es en
parte del cliente, en el lado del servidor el propio modelo(si es campo requerido, longitud
máxima o mínima, caracteres prohibidos…) tendrá sus validación, en el control otro tipo de
validación y a la hora de entrar en base de datos otra.
Validación de email:
Valida que el campo email este en el formato correcto y que tenga contenido.
51
Ilustración 38: Validación de email
Validación de la contraseña
Ilustración 39: Validación de contraseña
Así mismo cuando se escribe la contraseña este campo es oculto con caracteres de asteriscos o
puntos.
Ilustración 40: Contraseña con formato puntos
Validación de que es un email y está compuesto como tal
Ilustración 41: Validación de email formato correcto
52
Si se pulsa fuera del pop up deberá salir a la página en la que estuvieras, al igual que si pulsas en
cancelar.
La cabecera una vez logado eliminará los enlaces de registrarse y logarse y mostrara el usuario
que a su vez es un enlace al perfil de usuario.
Ilustración 42: Cabecera logada
Ilustración 43: Cabecera logada con nombre usuario
6.3.9 Registro
Formulario de registro
Propiedad Valor
Text Regístrate
Tipo Form
Color #fff
Font-size 15px
Hover:Color #fff
Nombre Imput
Apellidos Imput
Fecha nacimiento Imput
Email Imput
Password Imput
Botón de registrar Button

Tabla 34: Propiedades del formulario de registro
53
Ilustración 44: Formulario de registro
6.3.10 Perfil de usuario
El perfil de usuario contiene los campos necesarios para satisfacer las demandas del cliente y
para poder completar todos los campos de la base de datos. El formulario es el mismo que el
formulario de registro solo que los campos están rellenos con los valores del usuario.
Propiedad Valor
Text Perfil de usuario
Tipo Form
Color #fff
Font-size 15px
Hover:Color #fff
Nombre Imput
Apellidos Imput
Fecha nacimiento Imput
Email Imput
Password Imput
Población Imput
54
Botón de guardar Button

Tabla 35: Propiedades del perfil de usuario
Gráficamente quedaría así:
Ilustración 45: Formulario de perfil de usuario
6.4 Seguridad
Ante el auge de las aplicaciones web y del comercio por internet han sido muchas a las
aplicaciones las cuales han sido violaciones de seguridad por que presentaban una serie de
vulnerabilidades.
En la mayoría de las aplicaciones existen fallos de código que las hacen que sean vulnerables.
Muchas veces es por no tenerse en cuenta las vulnerabilidades y otras incluso por fallos de
programación y de estructura.
Un atacante podría, acceder a datos a los cuales no tiene permisos o no está autorizado a ver o
modificar, modificar datos de otros usuarios u obtener acceso a las distintas partes del servidor
donde está integrada la aplicación web.
Http no fue ideado para ser seguro, ya que estaba diseñado para mostrar páginas estáticas y no
para lo que se usa hoy en día como puede ser para comprar, para ver contenido en línea…
No hay ningún método o técnica que haga que una aplicación web sea inviolable pero siguiendo
una serie de consejos se hará más difícil de forzar.
Existe un organismo denominado OWASP (proyecto abierto de seguridad en aplicaciones web

u open web application security project OWASP) que establece una serie de medidas u
consejos para seguir y hacer la tarea de los piratas más difícil. Los 4 objetivos de la seguridad
informática según OWASP son “integridad, autenticidad, confidencialidad y disponibilidad”).
Para que sea íntegra, los datos deben permanecer durante toda su vida exactamente igual que
55
cuando fueron introducidos por el usuario. Para que sea auténtica, los datos deben ser iguales de
quién los originó, sin ningún cambio, para que tenga confidencialidad, un usuario solo podrá ver
sus datos y que sea disponible garantiza que los datos están siempre disponibles para el usuario
que los requiere. Además se debe garantizar que un usuario no pueda negar ninguna operación
que quiera realizar otro usuario.
La seguridad es un aspecto a tener en cuenta durante todo el ciclo de vida de nuestra aplicación.
Y dado que el objetivo es que la aplicación se mantenga con el tiempo debe ser una tarea
periódica aun que se si presta especial atención en la fase de desarrollo en el futuro será una
tarea bastante menos difícil.
A continuación se muestra las secciones en las que se tiene que prestar una especial atención a
tanto a la hora de diseñar como a la de implementar una aplicación debido a que presentan
aspectos que son críticos desde el punto de vista de la seguridad.
Secciones críticas según el proyecto abierto de seguridad en aplicaciones web u open web
application security project (OWASP)
 Validación de entradas: La validación de absolutamente todas las entradas tanto a base de

datos, entradas que realice el usuario como cabeceras HTML generadas es uno de los puntos
más importantes. Se realizaran las siguientes comprobaciones de entradas:
 Rechazar todas las validaciones que resulten fallidas.
 Comprobar que los campos introducidos solo contienen caracteres ASCII
 Validar que el tipo de datos que viene es el esperado.
 Validar la longitud de los datos que vienen y que coinciden con lo esperado
 Validar todo lo que se introduzca con una lista blanca y otra lista negra.
 Los caracteres peligrosos serán restringidos( Dichos caracteres se mencionan en el
anexo)
 Hacer una gestión de campos vacíos y nulos.
 Controles criptográficos: encriptar contraseñas y datos de sesión. Se interpondrán una serie
de normas para las contraseñas y los usuarios como por ejemplo que no contengan algunos
caracteres específicos, que tengan una longitud determinada y que se forme con unas reglas
determinadas como por ejemplo que contenga mayúsculas, minúsculas, números…
 Autenticación: proceso de login ante la aplicación, junto con la validación de entradas, este
será otro aspecto a tener muy encuentra. Habrá que poner todas las validaciones
mencionadas en el punto anterior de validación de entradas. Solo se validaran los campos
cuando este todo relleno y se quiere enviar el formulario. Cuando el dato sea erróneo o no
pase la validación no habrá que indicar que parte del dato es erróneo.
 Gestión de sesiones: el proceso de abrir y cerrar y enmascarar datos de sesión. Se
contralaran los datos de cada sesión por IP para evitar la prueba de usuarios.
 Autorización: diferentes permisos en cada uno de las partes del portal por ejemplo los
permisos que tiene una persona que es admin y una persona que no lo es.
 Registro de eventos: un buen registro de logs es muy positivo para el control de errores
 Gestión de errores: La gestión de errores facilitará corregir y descubrir futuros errores de
forma rápida y precisa. Para la gestión de errores se debe seguir que:
 No hay que mostrar información sensible en la respuesta de error.
 No mostrar información confidencial en las trazas de error.
56
 Hay que mostrar mensajes genéricos sin especificar qué es lo que hay fallado en
concreto.
 Por lo general ante cualquier error debe expulsar de la aplicación.
 Todas las gestiones de errores se deben hacer desde el lado del servidor.
 Se tiene que registrar tanto los errores de la aplicación como errores de login por
parte de los usuarios para descubrir intentos de fuerza bruta.
 Habrá que registrar intentos de autenticación con tokens erróneos o caducados con
el mismo objetivo que el anterior.
Además para reforzar la seguridad hay que seguir las recomendaciones que nos indica OWASP
TOP 10.
OWASP TOP 10 es un documento de los diez riesgos de seguridad más importantes en

aplicaciones web según la organización OWASP. Esta lista es publicada y actualizada cada 3
años por dicha organización.
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10
Ilustración 46: Riesgos de seguridad más importantes según OWASP
“A1.-Injection”: Son las inyecciones de código en formularios, las cuales son el más común de
los riesgos, con los cuales se puede desde acceder sin tener usuario o contraseña hasta rescatar
datos.
“A2 Broken Authentication and Session Management”: Son los riesgos originados por el uso
incorrecto de las sesiones.
“A3 – Cross-Site Scripting (XSS)”: Ocurre debido a la excesiva confianza que se tiene en los
sitios. Cuando se duplican sitios con finalidad maliciosa con el objetivo de robar sesiones claves
etc. La práctica más común es el envío de correos que aparentemente redirigen a la web de un
banco por ejemplo pero en realidad es una clonación ilegal del sitio.
“A4.- – Insecure Direct Object References“: Puede llevar a un acceso no autorizado a

información crítica debido a errores en el desarrollo.
“A5 – Security Misconfiguration“: Corresponde a configuraciones no adecuadas.
57
“A6 – Sensitive Data Exposure“: Se refiere a la protección incorrecta de datos críticos tales
como, por ejemplo, números de tarjetas de crédito, contraseñas...
“A7 – Missing Function Level Access Control“: Corresponde a la falta de validaciones en el

servidor, dejando que un atacante acceda a funciones a las que no debería.
“A8 - Cross-Site Request Forgery (CSRF)“: Permite a un atacante generar peticiones sobre una
aplicación a partir de la sesión de un usuario/victima.
“A9 - Using Components with Known Vulnerabilities“: Corresponde a configuraciones no

adecuadas que pueden impactar en la seguridad de la aplicación.
“A10 – Unvalidated Redirects and Forwards“: Los atacantes aprovechan el uso de

redirecciones de sitios web a otros sitios utilizando información no confiable (untrusted) para
redirigir a las víctimas a sitios de phishing o que contienen malware.
Así mismo OWASP definió unos requerimientos para evitar los riesgos.
Los requerimientos de Application Security Verification Standard ASVS(28) fueron desarrollados con
los siguientes objetivos en mente:
 Proveer a los desarrolladores de un índice que indique cuan segura es su aplicación

 Utilizar una guía para desarrolladores para que se cumplan una serie de indicaciones y de
controles de seguridad con tal de evitar estos ataques.
 Proveer de unos requisitos de seguridad mínimos que se tienen que cumplir
Para establecer un nivel de confianza y de seguridad OWASP ASVS ha especificado que las
aplicaciones deben seguir el siguiente esquema.
58
"Planificación" "Implementación"
"Verificación"
"Despliegue"
"Diseño para un nivel de riesgo especifico"

"Definicion de requisitos de niveles de riesgos"
Ilustración 47: Esquema para establecer un nivel de confianza recomendado por OWASP ASVS
En primer lugar debe seguir una planificación para poder prever y contemplar todos los casos a los que
se quiere poner barreras y poder planificar tiempos costes y recursos que se necesitaran. Después se
definirá unos requisitos mínimos a cumplir para poder satisfacer cada nivel de riesgo. En tercer lugar
se realizara la programación de la aplicación teniendo en cuenta los requisitos a cumplir y la
planificación realizada. Dependiendo del nivel de riesgo que se desee aplacar se realizaran una serie de
programaciones u otras ya que todas las paginas por ejemplo no son igual de atacables o del mismo
interés de los datos. Por ejemplo no es lo mismo una página que contiene datos personales que otra
página que lo único que contiene es contenido estático de poco valor. Como quinto paso se realiza la
comprobación de que cumple los requisitos y por último se realiza el despliegue.
ASVS define los requerimientos, no indica cómo implementarlos. En el apartado anexo se adjunta una
imagen con un ejemplo de lo que especifica ASVS que hay que verificar dependiendo del grado de
seguridad e indicando a partir de que versión del documento se incluye.
6.4.1 Revisión de seguridad
La revisión de seguridad de la aplicación web deberá seguir una serie de fases para asegurarse que
además que cumple las normativas anteriormente presentadas, se pone barreras a los fallos comunes
de programación. Debido al tipo de arquitectura de nuestra aplicación se han definido 5 fases por las
cuales se hará una revisión de la seguridad del aplicativo.
59
• Revisión del SiteMap del sitio

• Revision de inserccion SQL, JS mencionadas anteriormente
• Intento de acceder a menus no existentes en la navegación mostrada
• Búsqueda de comentarios HTML que muestren pistas sobre funcionamientos aplicaciones o datos importantes
• Comprobación de certificados, firmas...
Fase 1 Revisión
• Intentar forzar formualarios mediante inyeccion
de la aplicación
• Revision de los datos de session, cookis...
en anónimo
• Revision del tipo de usuarios e intento de predecir contraseñas

• Robo de sesiones mediante el robo de cookis
• Intento de capturar iframes
• Intento de ejecución de operaciones no permitidas
• Modificación de parámetros de formularios
Fase 2 Revisión • Revision de los datos de session.
de la aplicación • Revision de inyeccion SQL y JS
con usuario
logado
• Intentar forzar directorios para detectar el esquema de directorios

• Intento de provocar errores en el servidor
• Intento de acceso a ficheros de configuración
• Revelación de credenciales
Fase 3 Revisión de • Comprobación de vulnerabilidades de servidor
los servidores de la • Localizacion de aplicaciones en servidor
aplicación • intentos acceder a la consola de la administracion central
• Comprobar reglas de filtrado

• Comprobación de Flags en TCP/IP
• Respuestas de paquetes con información sensible
Fase 4 Revisión • Comprobación del firewall
externa de los • Intento de acceso a consola de administración de forma remota
servidores
• Revisión de puertos habilitados

• Revisión de servicios vulnerables
• Evaluación de protocolos vulnerables
Fase 5 Revisión
de servicios
60
6.5 SEO (Search Engine Optimization)
El posicionamiento SEO es el encargado de mejorar la posición en los motores de búsqueda

como por ejemplo GOOGLE. Es decir aparecer más arriba o más abajo, aparecer en la primera
página del buscador o en las últimas. Cuanto más optimizado estén las reglas SEO más cerca del
primer puesto estará nuestra aplicación. El propio google establece unos requisitos para mejorar
dicho posicionamiento.
Actualmente el posicionamiento en buscadores es crucial para cualquier empresa en el mercado.

Para poder mejorar este posicionamiento es necesario mejorar y ajustar a los requisitos SEO la
información que se presenta en las páginas Web. Un buen posicionamiento seo permite aparecer
entre los primeros resultados de búsqueda y de esto dependerá de nuestro volumen de visitas.
Las medidas que como implementadores de la solución podremos tomar serán:
6.5.1 Requisitos
 Metas y titile personalizados para cada página: se incluirá los <metas> y <title> de
cada página web de manera individual y con soporte multicultural:
Ilustración 48: Descripción de metas y title en html
 Url amigables: Se realizará un estudio detallado de la información a mostrar, para crear

una estructura lógica de sitios y que la url sea claramente descriptiva de lo que se está
mostrando en dicha página. Además deberán ser consistentes con la cultura empleada,
es decir que sea en el idioma que se está manejando:
o Español
Ilustración 49: Url Amigable de sección de contacto en español
Ilustración 50: Url Amigable de sección de acerca de nosotros en español
o Inglés
61
Ilustración 51: Url Amigable de sección de contacto en inglés
Ilustración 52: Url Amigable de sección de acerca de nosotros en inglés
 Generación del Sitemap de la aplicación web siguiendo la recomendaciones de google:

o Utilizar urls amigables como anteriormente se ha comentado
o En las url no se deben introducir identificadores de sesión o tokens o
argumentos de post
o Indicar el versionado de páginas traducidas
o La codificación del Sitemap tiene que ser UTF-8
o Si el mapa de sitio es excesivamente grande se recomienda dividir en dos más
pequeños
o En lugar de utilizar caracteres no alfanuméricos se recomienda utilizar su
carácter de escape.
o Enviar y validar con google el último Sitemap utilizado.
o Debe estar en la raíz siempre
En el apartado anexo se adjunta un ejemplo de cómo esta estructura el XML del mapa del sitio
 Gestión de errores: se personalizarán las páginas de errores

o 401 Unauthorized (Sin autorización para entrar)
o 403 Forbidden (Demasiado tiempo)
o 404 Not Found (No se encuentra la página)
o 500 Internal Server Error ( Error en el servidor)
 Etiqueta de palabras claves <meta name=”keywords”…>
Cada palabra clave elegida tiene que tener una estrecha relación sobre el contenido que está
gestionando la página.
Debemos de imaginar al definir palabras claves, errores posibles del usuario o variantes para
una misma palabra. Por ejemplo si tenemos la palabra clave “baloncesto” podríamos incluir
“basket”…
 Etiqueta encabezado
Google y otros motores de búsqueda contemplan con gran importancia las etiquetas de
encabezado ya que en estas tiene que estar contenidas las palabras clave. Estas etiquetas son h1
h2…
62
 Texto de contenido
Se debe de intentar que el contenido de una página esté dedicado exclusivamente a un solo
tema.
El texto donde aparezca una palabra clave se tiene que usar con negrita, esto es bueno para el
peso de la palabra clave dentro del algoritmo de algunos motores de búsqueda.
 Las palabras clave no deben de estar ocultas
Se debe mostrar en todo momento las palabras clave de cada página y si es posible mostrándose
en negrita.
 Gráficos con palabras clave
Si una página tiene un gráfico o una imagen con una palabra clave se tiene que utilizar el
parámetro Alt con el texto alternativo para que el robot pueda percibir la aparición de la palabra
clave.
 Pie de página
El pie de página es un buen sitio para incluir un texto en el cual se utilicen palabras claves y
nombre de “partido”, “futbol”, “baloncesto”,”paddel”.
 Enlaces internos
Los robots y motores de búsqueda no indexan todas las páginas de nuestra web sino que siguen
la ruta de navegación de los enlaces principales. Cuantos más enlaces en distintas páginas es
mejor para la importancia de esta. Por ejemplo lo que haremos es incluir en la página de inicio o
home enlaces a diferentes búsquedas para que el robot las indexe. Por ejemplo en nuestra home
incluiremos enlaces a búsquedas como “Partidos en Madrid”, o “Futbol en Getafe” de tal
manera que cuando un usuario busque algo similar el motor de búsqueda la habrá indexado y
aparecerá en los resultados de búsqueda.
La página de inicio es la página que suele tener mayor cantidad de enlaces y es la que debería de
tener enlaces hacia todas las páginas de destino.
 Enlaces retorno
Aunque sean páginas de subsitios dentro de subsitios a bajo nivel, deben de contener enlaces de
retorno a la página principal. Esto a los robots les permite cerrar el círculo y retroalimentar al
esquema de enlaces. Por eso en todas las páginas debe haber enlaces a la home.
6.5.2 Colaboración con los robots
Para mejorar la indexación por parte de los robots de google se debe seguir que:
 Java Scripts
63
Los robots solo entiende código HTML. Los enlaces escritos con código javascript no son
accesibles para los robots.
document.getElementById(#IDdelElemento).href = " http://www.whentoplay.com”
Esta url no sería accesible ni indexada por parte de los buscadores
 Cookies
Las páginas web que queremos que sean indexadas deben poder funcionar sin cookies.
 Inclusión mediante mapas del sitio XML
Un SiteMap o mapa de sitio es un archivo XML el cual contiene una determinada estructura el
cual muestra todas las url que queremos que indexe. Los mapas de sitio, es un método mediante
el cual podemos decirle a los robots que es lo que está disponible para que ellos lo indexen o
simplemente pasen de ese enlace.
 Consideraciones HTML SEO
En términos de SEO cada tag HTML tiene una importancia, utilizarlos y utilizarlos bien hará
que sumen puntos de cara al posicionamiento.
La siguiente tabla muestra la importancia de cada tag HTML en términos de SEO:
Tag Importancia
<h1>...<h6> Muy alta
<title> Muy alta
<b> Alta
<i> Alta
<img> Alta
<meta> Alta
<u> Alta
<a> Media
<body> Media
<br> Media
<center> Media
<font> Media
<head> Media
<li> Media
64
<ol> Media
Media
<p>
Media
<table>
Media
<td>
Media
<tr>
Media
<ul>
<frame> Baja
<frameset> Baja
Ilustración 53: Importancia de cada tag en términos de SEO
Las etiquetas que aparecen con importancia media o incluso baja pueden llegar a ser muy
importantes en el caso de que no se cierren correctamente u estén desordenadas.
Para validar nuestro portal usaremos un validador de código HTML (31). Este sitio informa si
nuestro código final HTML de nuestro portal correcto para el robot o no y además nos indica
posibles errores y posibles mejoras.
65
7. Descripción funcional
En este capítulo se describe como es la documentación a entregar al cliente desde el punto de

vista funcional. Debe contener una descripción de cómo funciona la aplicación siguiendo paso
por paso lo que el usuario debe hacer para conseguir el funcionamiento total de la aplicación.
Esta descripción se le entrega al cliente a modo de prueba de que hace lo que el cliente solicito
en un principio y también de que lo hace de la misma manera en la que solicitó. Esto se hace
antes de empezar a desarrollar y se hace para fijar un comportamiento tanto funcional como
visual y que no haya cambios durante el desarrollo puesto que el cliente puede ver ya de manera
tangible como va a quedar finalmente. También es fundamental porque muchas veces el cliente
no es una persona técnica y no sabe que ámbitos puede o no decidir sobre el desarrollo de la
aplicación y así de esta manera se deja fijadas las bases de lo que va a ser la aplicación sin giros
ni cambios.
7.1 Acceso al portal
Se describe a continuación la manera a la que se accede a la página de la aplicación.
Se accede a través cualquier navegador a la dirección: https://www.whentoplay.com
Ilustración 54: Url de la aplicación
7.2 Login
Se describe la manera en la cual el usuario debe autenticarse frente a la aplicación.
1) Pulsar en Acceso Usuarios

2) Aparecerá una ventana modal en la que habrá que introducir el email y la contraseña
Ilustración 55: pop up de login AF
66
3) Si se quiere que se permanezca logado habrá que pulsar en Recordarme.
Ilustración 56: Enlace de recordar usuario AF
4) Pulsar en entrar. Si ha sido correcto volverá a la Home y en la parte superior derecha habrán
desaparecido los link Acceso usuarios y Registrarse y aparecerá su nombre de usuario y un
enlace para salir de su usuario.
Ilustración 57: Enlaces de usuario y salir AF
7.3 Logout
Se describe la manera en la cual el usuario se desautentica.
1)
Pulsar en
2)
Aparece un pop up preguntándonos que si se desea salir.
Ilustración 58: PopUp de confirmación de salir AF
67
3)
Si se pulsa Aceptar, si se ha desautenticado correctamente aparecerá un nuevo pop up
indicándote que has salido correctamente y volverá a la página principal en anónimo.
Ilustración 59: Mensaje de confirmación de salida AF
Ilustración 60: Enlaces de vuelta de des autenticación

4)
Si se pulsa en Cancelar se mantendrá en la misma página
7.4 Recuperar contraseña.
1) Pulsar en acceso usuarios

2) Aparecerá la ventana modal de logIn
Ilustración 61: pop up de autenticación
3) Si se olvido la contraseña, pulsar en el enlace de abajo a la derecha de la venta modal donde
dice :
68
4) Redirigirá a otra página donde se tendrá que poner el email donde se le enviará al correo
para que se cambie la contraseña. El correo deberá pertenecer a un correo guardado
anteriormente.
Ilustración 62: Página de recuerdo de contraseña
5) Al pulsar Mandar contraseña se mostrará un pop up confirmandole que se ha enviado un

correo con su password.
7.5 Cambiar de idioma el portal.
Para cambiar el idioma del portal, se dispone de una opción los enlaces superiores de la
cabecera:
1.) Pulsar en Idioma:
Ilustración 63: Selección de idioma AF
2.) Se mostrará las opciones de idioma que hay y pulsando en ellas se redirigirá a la versión
del portal en dicho idioma.
Ilustración 64: Opciones de selección de idioma AF
69
7.6 Ver las políticas de privacidad y términos y condiciones
Para ver dichos documentos se tiene que hacer clic en la parte inferior derecha.
Ilustración 65: Enlaces de condiciones y privacidad
Cada enlace abrirá una página con dicha información.
7.7 Buscar partidos para unirse
En la home disponemos de los tres combos para buscar el deporte la zona y franja horaria en la
que deseamos buscar. Marcaremos en cada uno de los combos la opción deseada y para finalizar
pulsaremos en buscar. Por ejemplo trataremos de buscar deporte futbol, zona de Chamartín y el
viernes por la tarde.
Ilustración 66: Selección de deporte zona y horario AF
Como se contempla según vas marcando se queda señalados en los combos las opciones
indicadas. Para encontrar el partido habría que pulsar “Buscar”. Si usted está logado le accederá
a la siguiente pantalla donde se muestran los partidos en una tabla pero si no está logado le
saltará una ventana emergente indicándole que no está logado e invitándole a que se logue o en
su defecto registre.
70
Ilustración 67: Pop Up para identificarse AF
Y si no está logado salta el formulario de registro.
Ilustración 68: Formulario de registro AF
Una vez logado en la aplicación muestra todos los partidos con esa configuración.
71
Ilustración 69: Partidos disponibles AF
7.8 Crear partido
Si al buscar entre las condiciones de deporte lugar y horario no hay ningún partido, el usuario
siempre podrá crear uno propio. Para crear un partido:
a) Estar logado
b) Buscar unas condiciones de partido de deporte lugar y horario y pulsar buscar
Ilustración 70: Búsqueda de partido
c) En la página de partidos disponibles pulsar el botón crear partido
72
Pulsar crear partido
Ilustración 71: Botón de crear partido
Esto llevará a la página con el formulario para anotar los datos que se requieren para la creación
del partido
d) Rellenar todos los campos y pulsar crear.
Ilustración 72: Formulario de creación de partido
e) Acto seguido el partido aparecerá si se busca por los campos adecuados.
73
7.9 Ver perfil
Para ver el perfil de usuario se debe estar logado. Para acceder al perfil y poder modificar
alguno de sus campos se deberá:
1. Pulsar sobre el enlace con tu nombre en la cabecera
Ilustración 73: Ver perfil de usuario
2. Esto redireccionará a la página de perfil
Ilustración 74: Página de perfil de usuario
74
75
8. Plan de pruebas
El objetivo del plan de pruebas es definir la especificación técnica de pruebas que corresponde a
los niveles de desarrollo y de integración para la aplicación que hemos desarrollado.
Para ello se incluye:
 Mapa de pruebas
 Descripción de casos de prueba y condiciones de prueba
 Información del resultado obtenido
Otra finalidad del plan de pruebas es la de mostrar el correcto funcionamiento de la aplicación

mediante pruebas atomizadas demostrando así que funciona correctamente tal como el cliente
pidió y tal y como se validó en el análisis funcional.
8.1 Mapa de pruebas
El mapa de pruebas muestra la granularidad de las pruebas mostrando los Elementos de Prueba
con las Condiciones y Casos de Prueba, cuyas descripciones detalladas se incluyen en el
siguiente elemento.
 Elemento de Prueba
Nombre del elemento que se va a probar.
 Condición de prueba
Código de la Condición de Prueba que se establecerá por cada elemento de prueba. Como
opción y para ser más descriptivo se podrá añadir el nombre de la condición.
El Código debe ajustarse a la siguiente nomenclatura: COnnn donde:
CO es Condición de Prueba
nnn es el número de la prueba siguiente el orden pertinente.
 Caso de prueba
Código del Caso de Prueba que se establecerá para verificar cada Condición de Prueba. . Como
opción y para ser más descriptivo se podrá añadir el nombre del caso.
El Código debe ajustarse a la siguiente nomenclatura: CAnnn dónde:
CA es Caso de Prueba
nnn es el número para cada Caso de Prueba, dentro de cada Condición de Prueba
COnnn es el Código de la Condición de Prueba.
 Resultado de la Ejecución
76
Es el resultado de la prueba del Caso de Prueba. Los posibles valores son:

o “ ”: en estado pendiente
o “OK”: resultado correcto
o “KO”: resultado incorrecto
o “NE”: no ejecutable. No se ha podido realizar la prueba por problemas
relacionados con el entorno u otros factores
 Categoría de la Condición de Prueba y del Caso de Prueba
La categoría es el valor que se le dará a la condición y caso de prueba haciendo así alusión a la
profundidad e importancia de dicha prueba. Los posibles valores serán:
o Baja
o Media
o Alta
8.2 Pruebas específicas
Condición Caso de Caso de Caso de Caso de

Elemento de Prueba
de Prueba Prueba Prueba Prueba Prueba
[Navegación] Un usuario anónimo

CO001 CA001 CA002
accede al portal
[Navegación] Un usuario anónimo

CO002 CA001 CA002
accede a los niveles principales
Resultados de búsqueda en el
buscador por parte de un usuario CO003 CA001
anónimo
[Accesibilidad] Validación de
CO004 CA001 CA002 CA003
campos
77
[Arquitectura] URL amigables CO005 CA001
[Arquitectura] Sitemap, robots CO006 CA001 CA002
[Arquitectura] SEO CO007 CA001
[Rendimiento] Análisis del

CO008 CA001
rendimiento del Portal
El desarrollo de las pruebas se incluirá en el anexo D.
78
9. Documentación final a entregar
Se ha presentado de manera breve la documentación a entregar al cliente durante la vida del

proyecto de desarrollo de la aplicación. Para terminar con dicha documentación e incluso para
cerrar el desarrollo y por lo tanto los acuerdos de trabajo entre ambas empresas se desarrollaría
un manual de usuario final, en el que se explica paso a paso desde el punto de vista de una
persona que no ha conocido nunca la aplicación el cómo y los pasos de cómo se realizan las
funciones de dicha web.
Dicho manual de usuario tendría que venir con un título, descripción de elementos, tablas,
índices… teniendo en cuenta que es para un usuario final, el cual desconoce por completo como
es la aplicación.
A continuación se pone un ejemplo de cómo sería un apartado del manual de usuario. Tiene
que ser conciso sin palabras técnicas y con imágenes señalando donde hay que hacer clic
mediante flechas y resaltados. Se expone una imagen del manual de usuario
Ilustración 75: Ejemplo del manual de usuario
79
10. Conclusión y trabajos futuros
Como conclusión acerca del TFG podría decir, que una buena elaboración de documentación
ayuda a prevenir muchas futuras dificultades y ayuda dejar claro de cara al cliente como va a ser
la aplicación y cómo va a funcionar permitiendo esto tener al cliente una visión global de todo
ya que en muchas ocasiones el cliente es alguien que no es técnico y no tiene una visión de
cómo pueden quedar por ejemplo, formularios, pop up, pies de páginas… teniendo que realizar
documentación cuando todavía no se ha llevado a cabo el desarrollo de la misma. Además como
se ha mencionado también ayuda al desarrollador a prever futuras complicaciones o dudas las
cuales pueden ser resueltas antes de que sucedan permitiendo esto elaborar nuevas estrategias o
diferentes programaciones ayudando así a que los tiempos estipulados se cumplan.
Puntos a mejorar respecto al contenido de dicho proyecto sería una elaboración de reuniones en
SCRUM método que es muy requerido y utilizado ahora mismo por el que se establece y se
reparte el trabajo entre los miembros del equipo de manera atomizada y en líneas de tiempo
realistas. Otras mejoras irían fundamentalmente basadas en el desarrollo de la documentación
realizando por ejemplo plantillas lo más genéricas pero precisas posibles para el apartado
técnico para que en cada proyecto se siguiera la misma estructura y la misma forma de
documentar.
Otro punto el cual es fundamental documentar es una gestión de errores, una para el usuario y
otra para el cliente. La gestión de errores para el cliente, consistirá la elaboración de logs de
registros y de errores, no solo para tener en cuenta los errores y poder corregirlos sino también
para la elaboración de informes de uso de clientes. La gestión de errores para el usuario final
consiste en añadir en el manual de usuario posibles errores que se pueden dar y como
corregirlos como por ejemplo cuando un usuario pone mal el email, ( no pone la @, o no pone
el .com etc.) que se informe debidamente como se debe cumplimentar todos los casos posibles.
De cara a futuros trabajos se sabe que la elaboración de un proyecto en el que es todo a medida
del cliente, no es barato ni fácil de implementar, ni de documentar, por lo que es comprensible
la proliferación de aplicaciones y webs que con muy pocos recursos montan una web “editable”
por el usuario final. Estas son más baratas y asequibles para empresas medianas y pequeñas. Las
empresas grandes, con más recursos y con una imagen que dar son las que solicitan este tipo de
servicios a otras consultoras, puesto que les sale más rentable que el desarrollo se lo haga una
tercera empresa en lugar de tener a gente en nómina que realice los proyectos y los
mantenimientos.
Otra desventaja que podría presentar las aplicaciones de edición de web es la lógica que permite
mostrar la página. Puesto que esas aplicaciones están más orientadas a la elaboración de webs
casi estáticas sin lógica alguna y es con lo que podría vencer mis desarrollos frente a estas
aplicaciones.
Teniendo en cuenta que el público cliente de mis desarrollos sería una parte de empresas
pequeñas las cuales no les interesaría un enfoque de diseño personalizado web, sería interesante
centrarse en aplicaciones web que compaginan un uso público con el uso interno. A lo actual y
contra lo que competimos podríamos dar esa ventaja.
80
Además el TFG se ha diseño en base de un punto de vista de TI sin tener en cuenta la parte de
sistemas. Por lo que otro punto de mejora seria también ofrecer y documentar el servicio de
almacenamiento y servidores. Puesto que las empresas grandes tienen dichos servicios, las
empresas pequeñas necesitan alquilar estos servicios. Pues nuestra empresa podría subcontratar
estos servicios para ofrecer un paquete en el que venga todo para el que el cliente no tenga que
preocuparse por nada.
81
11. Impacto socioeconómico
El principal impacto que se intenta dar a entender en este TFG es la reducción de costes y
tiempos en la realización de proyectos. Como se ha hecho hincapié durante todo el TFG una
buena documentación no solo sirve para que el cliente tenga la referencia de lo que se está
haciendo, sino que sirve para prever futuros problemas, futuras necesidades y poder apaliarlas
por adelantado o en paralelo a otros trabajos, permitiendo esto no tener parado a ningún
integrante del equipo y haciendo así el desarrollo más corto y por lo tanto más barato. Además
nos servirá para fijar futuras valoraciones en proyectos similares o de igual magnitud pudiendo
hacer cada vez las ofertas más precisas y por lo tanto con más ganancias. También te permite
también tener un repositorio de métodos y parámetros utilizados teniendo así una justificación
de por qué se han utilizado y poder utilizarlo en un futuro.
82
12. Coste del TFG
Este capítulo es el encargado de justificar y aclarar los costes que tengan relación con la
elaboración del trabajo de fin de grado. Los costes se clasifican en dos, los personales (tanto
míos como los del profesor) como los materiales (materiales empleados)
1) Costes personales
La duración de la elaboración del proyecto ha sido de 4 meses, empezando a mediados Febrero

y acabándolo a finales de Junio. En total he dedicado una media de 2 horas diarias de lunes a
sábado haciendo esto un total de 110 días o unas 200 horas invertidas en el Trabajo de Fin de
Grado. A estas horas, habría que “sumarle” la experiencia y el estudio previo que me ha llevado
en mi trabajo. El reparto de esas horas ha sido el siguiente.
 Investigación de patrones de diseño MVC: 20 horas (1)

 Investigación de framework CSS y JavaScript:20 horas(2)
 Investigación sobre preventa de proyectos: 5 horas(3)
 Diseño de la aplicación en HTML: 65 horas(4)
 Realización de la memoria: 90 horas(5)
Porcentaje segun el apartado
10% 1
10% 2,50% 2
45% 3
4
32,50% 5
Ilustración 76: porcentaje de tiempo empleado en la realización del TFG
83
Número de horas dedicado a cada

apartado
100
80
60
40
20
0 1 2 3 4 5
Ilustración 77: Número de horas empleadas en cada apartado del TFG
Para definir este reparto de horas me he basado en la planificación previa que hice previamente
en un diagrama de GANNT
Ilustración 78: Gantt del desarrollo del TFG
Se ha estimado que el profesor HAROLD MOLINA ha dedicado al trabajo de Fin de Grado un

total de x horas donde han intervenido tutorías emails revisiones y correcciones.
El coste de las horas escogido es el planteado por el BOE según el cual un titulado de primer
ciclo universitario cobraría 1253,16 euros en 14 pagas. Lo que hace al año 17.554,24 Euros. En
2018 hay un total de 251dias laborables por lo que el día trabajado sale a 69,93 euros, con lo
cual el día laborable con 7 horas sale un total de 9.99euros/hora.
El coste del tutor lo he obtenido prorrateando el resultado anterior a 1.5 veces. Por lo que el
coste a la hora del tutor asciende a 14,98 euros/hora.
El tiempo empleado por el profesor ha sido de una hora semanal durante las 19 semanas que ha
durado el proyecto, pero se ha prorrateado a un 1.1 por el tiempo empleado en correos recibidos
y enviados. Por lo que el tiempo total empleado por el profesor Harold ha sido de 20,9 horas.
COSTE PERSONAL DEL TRABAJO DE FIN DE GRADO
Trabajador Precio unitario (€/h) Nº horas Importe
84
José María (Alumno) 9,99 200 1998 €
Harold(Profesor) 14,98 20,9 313.08 €
Coste total 2311.08 €

Tabla 36: Coste personal del TFG
2) Costes materiales
En los costes materiales he incluido todos los medios que utilizado:
COSTE MATERIALES DEL TRABAJO DE FIN DE GRADO
PC 500 €
Coste total 500 €

Tabla 37: Coste material del TFG
Coste total del proyecto
COSTE TOTAL DEL TRABAJO DE FIN DE GRADO
Costes personales 2311.08 €
Costes materiales 500 €
TOTAL 2811.08 €
Tabla 38: Coste total del TFG
Por lo que el presupuesto final de trabajo de fin de grado “Guía para el desarrollo y
documentación de una aplicación web .NET” sería de un total de DOS MIL
OCHOCIENTOS ONCE EUROS CON 8 CÉNTIMOS.
85
13. Referencias bibliográficas
1. http://plantilla.madrid.slu.edu/uploads/docs/ANEXO_1_Clausulas_contractuales_(MOD
ELO).pdf
2. http://accesibilidadweb.dlsi.ua.es/?menu=espanola
3. https://www.40defiebre.com/guia-seo/que-es-seo-por-que-necesito/
4. https://developers.google.com/speed/pagespeed/insights/?hl=es
5. http://accesibilidadweb.dlsi.ua.es/?menu=wcag-2.0
6. http://accesibilidadweb.dlsi.ua.es/?menu=niveles-2.0
7. https://support.google.com/webmasters/answer/7451184?hl=es
8. https://msdn.microsoft.com/es-es/library/4w3ex9c2(v=vs.100).aspx
9. https://msdn.microsoft.com/es-es/library/dd410597(v=vs.100).aspx
10. https://www.w3schools.com/html/html_elements.asp
11. https://docs.microsoft.com/es-es/aspnet/core/choose-aspnet-
framework?view=aspnetcore-2.0
12. https://www.c-sharpcorner.com/UploadFile/8ef97c/using-partial-views-in-Asp-Net-mvc-
5-0-part-7/
13. https://codigofacilito.com/articulos/mvc-model-view-controller-explicado
14. https://stackoverflow.com/questions/13180543/what-is-assemblyinfo-cs-used-for
15. https://docs.microsoft.com/es-es/dotnet/framework/data/adonet/ef/overview
16. https://msdn.microsoft.com/en-us/library/wkze6zky.aspx
17. http://anexsoft.com/p/133/implementando-migraciones-con-entity-framework-y-asp-net-
mvc
18. https://devcode.la/blog/que-es-sql/
19. https://msdn.microsoft.com/es-es/library/gg416514(v=vs.108).aspx
20. https://docs.microsoft.com/es-es/sql/relational-databases/stored-procedures/create-a-
stored-procedure?view=sql-server-2017
21. https://getbootstrap.com/
22. https://jquery.com/download/
23. https://www.w3.org/TR/WCAG20/
24. https://www.uv.mx/personal/llopez/files/2011/09/presentacion.pdf
25. Https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.
0.pdf
26. https://www.owasp.org/images/a/aa/Est%C3%A1ndar_de_Verificaci%C3%B3n_de_Seg
uridad_en_Aplicaciones_3.0.1.pdf
27. https://miposicionamientoweb.es/guia-seo-para-principiantes
28. https://www.owasp.org/images/a/aa/Est%C3%A1ndar_de_Verificaci%C3%B3n_de_Seg
uridad_en_Aplicaciones_3.0.1.pdf
29. https://blog.fromdoppler.com/consejos-de-posicionamiento-seo/
31. http://validator.we.org
32. http://www.colciencias.gov.co/sites/default/files/upload/contratacion/modeloActaConfid
encialidad.pdf
33. https://developers.google.com/speed/pagespeed/insights/?hl=es&url=https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fj
osemariarodriguezcv.vacau.com&tab=mobile
86
34. https://concienciaweb.wordpress.com/2011/12/27/como-hacer-el-listado-de-
requerimientos-para-contratar-un-proyecto-web/
35. https://developers.google.com/speed/pagespeed/insights/?hl=es
37. http://www.mjusticia.gob.es/cs/Satellite/Portal/es/areas-tematicas/proteccion-datos-
personal
87
Anexos
ANEXO A: Verificaciones recomendadas por el ASVS (Application Security

Verification Standard)
ASVS (Application Security Verification Standard) o estándar para verificar la seguridad de las
aplicaciones, define los requerimientos, no indica cómo implementarlos. La siguiente tabla muestra un
ejemplo de lo que el documento de ASVS define que hay que verificar para cada grado de seguridad e
indicando la versión desde que se encuentra disponible. Dicha tabla se encuentra en su web.
Ilustración 79: Tabla de verificación de seguridad de OWASP
88
ANEXO B: Pautas de Accesibilidad AA

Las pautas de Accesibilidad AA son las encargadas de que una aplicación cumpla con unos
requisitos mínimos para que sean accesibles al mayor número de personas posible haciendo más
fácil el acceso a personas con dificultad como por ejemplo sordera o baja visibilidad
Dichas pautas se encuentran en su web, esta imagen es un ejemplo de lo que muestra.
Ilustración 80: Pautas para la accesibilidad dadas por WCAG 2.0
ANEXO C: SiteMap de la aplicación
El sitemap como ya se definió en apartados anteriores es el mapa de sitio de la aplicación web

en el cual se reflejan todas las url que se quiere que indexe el buscador. Este incluye la url, la
fecha de la última modificación como campos obligatorios y la frecuencia de cambio y la
importancia como campos opcionales. El siguiente fragmento de código es un ejemplo del
sitemap de nuestra aplicación. Las características y la estructura ya está explicado en el apartado
de SEO
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.whentoplay.com/</loc>
<lastmod>2018-05-07T09:00:10+00:00</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
89
<url>
<loc>http://www.whentoplay.com/quiensomos</loc>
<changefreq>weekly</changefreq>
</url>
<url>
<loc>http://www.whentoplay.com/partido</loc>
<changefreq>weekly</changefreq>
</url>
<url>
<loc>http://www.whentoplay.com/nuevopartido</loc>
<priority>0.3</priority>
</url>
<url>
<loc>http://www.whentoplay.com/privacidad</loc>
</url>
</urlset>
90
ANEXO D Pruebas específicas

A continuación se describen cada una de las condiciones de prueba que se requiere ser
comprobadas.
CO001
Descripción de la Condición
Se quiere comprobar el correcto acceso al portal
Variantes
Búsqueda en motor de búsqueda / a través de url
Procedimiento de la prueba
Realizar búsqueda en navegador
Acciones
Buscar en google “when to play”
Resultados
Ver la página o información adecuada.
Casos de Prueba
CASO Nombre del Caso OK Fecha NOTA
CA001 Escribir Url de portal X 7/5/2018
CA002 Realizar una búsqueda X 7/5/2018
Responsable José María Rodríguez
*Aquí posibles variantes seria:
 realizar un estudio de que palabras o frases que llevan a dicha búsqueda por lo que
habría 10-15 casos más.
 Realizar búsqueda en diferentes motores de búsqueda, otros 10 casos mas
 Realizar búsqueda y acceso con diferentes navegadores para comprobar tiempos de
carga. Otros 10 casos más.
91
Ilustración 81: Búsqueda en google para la comprobación de que se encuentra
A. CA001 Escribir Url de portal
Código CA001-CO001
Descripción del Caso
Se quiere comprobar que al escribir la Url en un navegador, sea cual sea, se accede correctamente con el
usuario anónimo.
Sin estar logado en el portal acceder a través de un navegador, sea cual sea, a una Url introducida
manualmente.
Datos de Entrada
Url
Resultados
Acceso correcto a la dirección indicada.
Resultados Obtenidos y Observaciones
OK
B. CA002 Realizar una búsqueda
Código CA002-CO001

Se quiere comprobar que el acceso al portal al realizar una búsqueda en un buscador de internet, sea cual
sea, es correcto.
92
Realizar una búsqueda en internet
Datos de Entrada
Palabra a buscar
Resultados
Acceso correcto al portal desde la búsqueda.
Resultados Obtenidos
OK
CO002
Se quiere comprobar el correcto funcionamiento del menú principal.
Variantes
Muestra las variantes de idioma y los enlaces redirigen correctamente.
Desde cualquier apartado del portal
Datos de Entrada
Resultados
Ver la página o información adecuada, así como el correcto marcado de posición
Casos de Prueba
CASO Nombre del Caso OK Fecha INC

CA001 Primer nivel OK 7/5/2018
CA002 Segundo nivel OK 7/5/2018
Responsable José María Rodríguez García
93
A. CA001 Niveles 1
Código CA001-CO002
Se comprueba el comportamiento en anónimo a los apartados principales
Hacer clic en los diferentes apartados para comprobar la navegación
Acciones a realizar
Hacer clic en menú superior derecha
Resultados Esperados
Se espera que navegue correctamente por los diferentes menús que no requieren un login

OK
B. CA002 Niveles 2
Código CA002-CO002
Se comprueba el comportamiento en anónimo a los apartados secundarios
Se profundiza en el menú.
Datos
Se espera que nos direccione a las páginas de términos y condiciones
CO003
94
Los resultados de la búsqueda realizada se muestran correctamente según sea la búsqueda además de
paginada.
Variantes
Diferentes busquedas
Introducir en el buscador palabras
Datos de Entrada y/o Acciones a realizar
futbol
Resultados correctos a cada opción
Resumen de Ejecución de los Casos de Prueba
CA001 Listado de resultados OK 7/5/2018
OK 7/5/2018
95
A. CA001 Listado de Resultados
Código CA001-CO007
Los resultados deben ser correctos.
Comprobar con negocio que salen todos los resultados
Datos
Resultados de busqueda
OK
CO004 – [Accesibilidad] Validación

Se quiere comprobar que el portal es accesible.
Variantes
Para la validación se utilizaran diferentes herramientas tales como W3C, validadores etc
Datos
Se validen todos los requisitos para cumplir la accesibilidad AA.
Casos de Prueba
96
CA001 Validación CSS. OK 5/7/2018
CA002 Validación HTML. OK 5/7/2018
CA003 Validación JavaScript. OK 5/7/2018
A. CA001 Validación CSS.
Código CA001-CO016
Se tendrán que pasar todos los validadores para css
Validación con diferentes herramientas
Datos
Resultados
Validar CSS
OK
B. CA002 Validación HTML.
Código CA002-CO016
Se tendrán que pasar todos los validadores para HTML
Validación con diferentes herramientas
Datos
97
Validar AA
Resultados
OK
C. CA003 Validación JavaScript.
Código CA003-CO016
Al desactivar el javascript no se elimina funcionalidad.
Desactivar javascript
Datos
Resultados
El portal mantiene su funcionalidad
CO005 – [Arquitectura] Url amigables

Asegurarnos que las url son “amigables y se construye correctamente la url de la página.
Variantes
Procedimiento
Navegar por el portal y ver el comportamiento de las urls
Datos
98
Mostrar las url amigables
Casos de Prueba
CA001 Url Amigables. OK 1/1/2018
Responsable JOSE MARIA RODRIGUEZ GARCIA
A. CA001 Url Amigables
Código CA001-CO018
Asegurarnos que las url son “amigables y se construye correctamente la url de la página.
Procedimiento
Navegar por el portal y ver el comportamiento de las urls
Datos de Entrada
Diferentes ramas del árbol de navegación
Resultados
Mostrar las url amigables
99
CO006 – [Arquitectura] Sitemap, Robots

Comprobar que se genera correctamente
Variantes
Variante del archivo del sitemap y del archivo para el robot
Analizar sus ficheros
Datos de Entrada
SiteMap.xml
Ficheros generados y configurados correctamente
Casos de Prueba
CA001 Sitemap Ok 1/1/2018
CA002 Robots Ok 1/1/2018
Responsable
10
A. CA001 Sitemap
Código CA001-CO020
Automático
Datos
Generación y configuración correctas
OK
B. CA002 Robots
Código CA002-CO020
Automático
Datos
Generación y configuración correctas
10
OK
CO007 – [Arquitectura] SEO

Comprobar que cumple los requisitos SEO mencionados en el análisis funcional.
Variantes
Datos
Configuraciones de SEO correctas
Casos de Prueba
CA001 SEO X 1/05/2018
A. CA001 SEO
Código CA001-CO021
Comprobar que cumple los requisitos SEO mencionados en el análisis funcional.
Revisar las condiciones de SEO que ofrece google y comprobar que están debidamente cumplimentadas
10
Dato
Configuraciones de SEO correctas
CO008 – [Rendimiento] Análisis del rendimiento del Portal

Pruebas de carga del portal
Variantes
Desde diferentes navegadores
Procedimiento
Aplicativo externo
Datos
Resultados
Resultados óptimos para el tipo de aplicativo web siempre dentro de los varemos estipulados
Casos de Prueba
CA001 Rendimiento X 1/05/2018
A. CA001 Rendimiento
Código CA001-CO024
Pruebas de Carga
Procedimiento
10
Visual Studio Test
Datos
Resultados óptimos para el tipo de aplicativo web siempre dentro de los varemos estipulados
ANEXO E: Ejemplo de cláusula de confidencialidad
En la siguiente url se encuentra un ejemplo de cláusulas de confidencialidad a modo:
https://www.inapi.cl/portal/publicaciones/608/articles-1598_recurso_1.pdf
ANEXO F: Ejemplo de validación por Modelo
En este ejemplo se muestra como se realiza la validación en el modelo. En este caso la

validación que se hace es:
 Es un campo obligatorio rellenar

 Es un campo que tienen que cumplir una longitud mínima de 8 caracteres
 El nombre que se mostrará será “Nueva contraseña”
[ Required ]
[ StringLength( 100, ErrorMessage = "La {0} contraseña debe contener al menos {2}
caracteres de largo", MinimumLength = 8 ) ]
[ DataType ( DataType.Password ) ]
[ Display ( Name = "Nueva contraseña")]
public string New_Password
get;
set;
ANEXO G: Caracteres restringidos
La siguiente lista hace relación a los caracteres restringidos en los campos a rellenar por el
usuario con el fin de evitar prácticas maliciosas.
10
<
>
“
%
(
)
¬
&
\
\\
%0d
%0a
\r
\n
Tabla 39: Caracteres prohibidos en campos
ANEXO H: Protección de datos de carácter personal LEY RGPD
Los principales puntos de la nueva ley entrada en vigor este año 2018 son:
 “Derecho de acceso”: Como usuarios tenemos derecho de poder preguntar si se están

tratando datos nuestros o no.
 “Derecho de rectificación”: Como usuarios tenemos derecho a exigir una rectificación
de nuestros datos personales.
 “Derecho de limitación”: Como usuarios tenemos derecho a que se limite el uso de
nuestros datos personales.
 “Derecho de olvido”: Como usuarios podemos exigir que se borren todos nuestros
datos personales
10

TFG Jose-Maria Rodriguez Garcia 2018

Cargado por

Copyright:

Formatos disponibles

TFG Jose-Maria Rodriguez Garcia 2018

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Jose-Maria Rodriguez Garcia 2018

Cargado por

Copyright:

Formatos disponibles

Grado en Ingeniería de Sistemas de Comunicaciones 2017-

Trabajo Fin de Grado

“Guía para el desarrollo y

José María Rodríguez García

[Incluir en el caso del interés de su publicación en el archivo abierto]

Ilustración 1: Vida del proyecto desde TI......................................................................................4

Ilustración 36: Imagen de pop up de login..................................................................................50

Ilustración 73: Ver perfil de usuario...........................................................................................74

Tabla 1: Versión de modificaciones de documento del proyecto de la empresa JMSOLUTIONSL

Tabla 29: Propiedades de la tabla de partido.............................................................................49

Tabla de acrónimos y anglicismos

En la siguiente tabla se muestra una relación de los términos utilizados y su significado.

home Página principal de un portal y en la cual se

login Acto de identificarse en una aplicación o

logout Acto de salir de una aplicación de la parte

responsive Aplicativo que se adapta tamaño de cualquier

header La cabecera de la página de la aplicación.

footer El pie de página de la aplicación. Hace

normativa AA Normativa que trata garantizar que existe un

SEO Search Engine Optimization

sitemaps Mapas de sitio web ( hace referencia al

CSHTML HTML mezclado con C#

Context Contexto de aplicación con la que establece la

HTML (HyperText Markup Language) Lenguaje para web estático

Razor Motor de vistas empleado

Framework Marco de trabajo

asp.net MVC Modelo de desarrollo Web unificado

partial Modo de vista

MVC ( Model , View, Controler) Patrón de diseño

DLL dynamic-link library

EntityFramework Conjunto de tecnologías para el desarrollo de

Procedures Procedimientos almacenados encargados de

Web.config Fichero encargado de almacenar la

Boostrap.js Marco de trabajo de diseño

Liberias(DLL) Ficheros de terceros con funciones ya

.Css ( Cascading Style Sheets) Hojas de estilos

landscape Versión en horizontal

JQuery Librerías de JavaScript

Meta Etiqueta HTML para aportar información del

title Etiqueta que aparecerá en la pestaña que

URL canónicas Url utilizadas para evitar el contenido

Drupall Gestor de contenidos para la elaboración de

Wordpress Gestor de contenidos para la elaboración de

IT(Information Technology) Tecnologías de la información

EMPRESA_CONTRANTANTE_1 Empresa ficticia la cual encarga el desarrollo

JMSOLUTIONSL Empresa ficticia encargada de hacer el

Page Speed test Aplicación de Google donde especifica la

glyphicon-globe Clase de icono del mundo

String Tipo de variable de cadena texto

Int Tipo de variable de entero

Date Tipo de variable de fecha

Text Propiedad de clase

#333 Color en hexadecimal

Background-color Color de fondo

Color Color de letra

Font-family Tipo de letra: Arial, Helvética

Font-size Tamaño de letra

Hover:Color Color cuando el puntero pasa por encima

Barra de scroll Barra derecha que aparece cuando el