TRABAJO FIN DE ESTUDIOS
|
|
- Pablo Navarrete Bustamante
- hace 8 años
- Vistas:
Transcripción
1 TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Aplicación web para la escuela de fútbol de Mareo en Logroño Abel Sierra Gómez Tutor: Juan José Olarte Larrea Curso
2 Aplicación web para la escuela de fútbol de Mareo en Logroño, trabajo fin de estudios de Abel Sierra Gómez, dirigido por Juan José Olarte Larrea (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2012 publicaciones.unirioja.es publicaciones@unirioja.es
3 UNIVERSIDAD DE LA RIOJA Facultad de Ciencias, Estudios Agroalimentarios e Informática PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Aplicación Web para la Escuela de Fútbol de Mareo en Logroño Alumno: Abel Sierra Gómez Director: Juan José Olarte Larrea Logroño, junio de 2012
4 Resumen Este proyecto pretende desarrollar un sitio Web para la Escuela de Fútbol de Mareo en Logroño que ayude a alojar toda la información referente a dicha escuela. Para ello, se creará una aplicación Web que sirva como carta de presentación de la propia escuela y añada además unas funcionalidades para los empleados que estén relacionados con la misma. El servicio principal que debe ofrecer la aplicación es la gestión de estadísticas durante la temporada para que puedan ser visibles y almacenadas en cualquier momento por los empleados. El empleado podrá mostrar, almacenar y modificar los datos de los empleados, entrenadores, jugadores, padres y equipos que conforman la Escuela, las estadísticas de todos y cada uno de los partidos jugados por cada equipo y jugador, y las faltas de asistencia al entrenamiento. Por último, al añadir una falta de asistencia al entrenamiento, la aplicación deberá enviar un mensaje de correo y un mensaje de texto a móvil al padre del jugador para informar de dicha falta. 1
5 Índice Resumen... 1 Índice... 2 Índice de Figuras... 5 Índice de Tablas... 6 Introducción... 7 Tema abordado... 7 Motivo de la elección... 7 Límites... 7 Documento de Objetivos del Proyecto... 8 Objetivo... 8 Participantes en el proyecto... 8 Comunicaciones... 8 Alcance del proyecto... 9 Requisitos mínimos alcanzables... 9 Posibles ampliaciones de la plataforma... 9 Metodología... 9 Tecnologías a utilizar Identificación de riesgos y planes de acción Riesgos posibles Actuaciones previstas ante los riesgos Entregables Descomposición de tareas Calendario de trabajo semanal Diagrama de Gantt Gestión del proyecto Introducción Factores del retraso Comparación de estimaciones y resultados Comparación de fechas Comparación de horas Análisis de resultados Análisis Introducción Objetivo Ámbito Visión general Sistema Como posibles ampliaciones de la aplicación Web cabe destacar Usuarios de la aplicación Visión general del sistema Requisitos funcionales Requisitos no funcionales
6 Ciclo 1: Aplicación Web (Administrar y visualizar información) Análisis Introducción Casos de Uso Administrar información de la aplicación Web Visualizar información de la aplicación Web Requisitos funcionales Diseño Introducción Descripción de los elementos básicos de Joomla! Prototipos de interfaz Construcción Interfaces definitivas Interfaces de administración Interfaces de visualización Ciclo 2: Gestionar estadísticas Análisis Introducción Casos de Uso Gestionar estadísticas Requisitos funcionales Requisitos no funcionales Prototipos de interfaz Clases de análisis Clases Diseño Diseño arquitectónico Diseño de la base de datos Entidad relación Modelo conceptual Diagrama de base de datos Normalización Clases de diseño Clases de negocio Especificación de pruebas unitarias Clases de equivalencia Identificación casos de prueba Construcción Tecnología utilizada Código relevante Encriptar contraseña Envío y recepción de datos del formulario Evitar inyección SQL Sesiones
7 Capa de persistencia Capa lógica de negocio Codificar y decodificar una cadena a UTF Añadir Empleado Interfaces definitivas Resultados de las pruebas unitarias Ciclo 3: Control de las faltas de asistencia a los entrenamientos Análisis Introducción Casos de Uso Gestionar control de faltas de asistencia a los entrenamientos Requisitos funcionales Clases de análisis Clases Diseño Diseño de la base de datos Entidad relación ampliado Modelo conceptual ampliado Diagrama de base de datos ampliado Clases de diseño Clases de negocio añadidas Especificación de pruebas unitarias Clases de equivalencia Identificación casos de prueba Construcción Tecnología utilizada Código relevante Enviar Enviar SMS Añadir Falta Entrenamiento Interfaces definitivas Resultados de las pruebas unitarias Pruebas de aceptación Bibliografía Anexo A: Manual usuario Administración Joomla! (Back-end) Anexo B: Actas de Reuniones Anexo C: Contenido del CD adjunto
8 Índice de Figuras Figura 1: Diagrama de Gantt. Vista general Figura 2: Diagrama de Gantt. Seguimiento del proyecto Figura 3: Diagrama de Gantt. Tareas de gestión del proyecto Figura 4: Diagrama de Gantt. Tareas del análisis del proyecto Figura 5: Diagrama de Gantt. Tareas del Ciclo 1: Administrar y visualizar aplicación Web Figura 6: Diagrama de Gantt. Tareas del Ciclo 2: Gestión estadísticas Figura 7: Diagrama de Gantt. Tareas del Ciclo 3: Control faltas de asistencia Figura 8: Diagrama de Gantt. Defensa del proyecto Figura 9: Visión general del sistema Figura 10: Diagrama de casos de uso administrar componentes Figura 11: Diagrama de casos de uso administrar contenidos de la aplicación Web Figura 12: Diagrama de casos de uso administrar usuarios de la aplicación Web Figura 13: Diagrama de casos de uso administrar multimedia de la aplicación Web Figura 14: Diagrama de casos de uso administrar inscripciones de la aplicación Web Figura 15: Diagrama de casos de uso visualizar información aplicación Web Figura 16: Tablas BD Joomla!. Menu Figura 17: Tablas BD Joomla!. Banners Figura 18: Tablas BD Joomla!. Usuarios Figura 19: Prototipo de interfaz acceso administrador. Login Figura 20: Prototipo de interfaz panel de control del administrador Figura 21: Prototipo de interfaz gestor categorías Figura 22: Prototipo de interfaz aplicación Web Figura 23: Prototipo de interfaz inscripción Figura 24: Interfaz acceso administrador. Login Figura 25: Interfaz panel de control del administrador Figura 26: Interfaz gestor categorías Figura 27: Interfaz gestor artículos Figura 28: Interfaz nuevo artículo Figura 29: Interfaz gestor multimedia Figura 30: Interfaz gestor menús Figura 31: Interfaz gestor usuarios Figura 32: Interfaz gestor extensiones Figura 33: Interfaz página principal visualización de la aplicación Web Figura 34: Interfaz inscripción a la Escuela de Fútbol de Mareo en Logroño Figura 35: Diagrama de casos de uso para la gestión de un empleado Figura 36: Diagrama de casos de uso para la gestión de un entrenador Figura 37: Diagrama de casos de uso para la gestión de un administrador Figura 38: Diagrama de casos de uso para la gestión de un equipo Figura 39: Diagrama de casos de uso para la gestión de un jugador Figura 40: Diagrama de casos de uso para la gestión de un partido Figura 41: Diagrama de casos de uso para la gestión de estadísticas Figura 42: Diagrama de casos de uso para la gestión de un padre Figura 43: Prototipo de interfaz login Figura 44: Prototipo de interfaz visualizar información Figura 45: Prototipo de interfaz añadir información Figura 46: Prototipo de interfaz modificar información Figura 47: Prototipo de interfaz eliminar información
9 Figura 48: UML. Clases de análisis Figura 49: Arquitectura tres capas Figura 50: Entidad relación Figura 51: Modelo conceptual Figura 52: Diagrama de base de datos Figura 53: Clases de diseño Figura 54: Interfaz login Figura 55: Interfaz login incorrecto Figura 56: Interfaz index administrador Figura 57: Interfaz index empleado Figura 58: Diagrama de casos de uso para la gestión de una falta de entrenamiento Figura 59: Diagrama de casos de uso para añadir una falta de asistencia a un entrenamiento Figura 60: Diagrama de casos de uso para recibir falta de asistencia a un entrenamiento Figura 61: UML. Clases de análisis ampliado Figura 62: Entidad relación ampliado Figura 63: Modelo conceptual ampliado Figura 64: Diagrama de base de datos ampliado Figura 65: Clases de diseño ampliado Figura 66: Interfaz visualizar falta entrenamiento Figura 67: Interfaz añadir falta entrenamiento (Administrador) Figura 68: Interfaz falta entrenamiento añadida correctamente (Administrador) Figura 69: Interfaz modificar falta entrenamiento (Administrador) Figura 70: Interfaz eliminar falta entrenamiento (Administrador) Índice de Tablas Tabla 1: Descomposición de tareas Tabla 2: Comparativa por fechas Tabla 3: Comparativa por horas
10 Introducción Tema abordado Este proyecto pretende desarrollar una aplicación Web para la Escuela de Fútbol de Mareo en Logroño donde pueda alojar toda la información referente a dicha escuela. También incluirá un apartado con acceso restringido para los empleados, en donde se podrá obtener y actualizar las características y resultados relacionados con los equipos y jugadores de la escuela. Además, en dichas estadísticas se llevará un control de las faltas de asistencia al entrenamiento con el objetivo de avisar al tutor/a o padre/madre del jugador mediante mensaje de texto a móvil y correo electrónico. Motivo de la elección Actualmente, entreno a dos equipos de fútbol base de dicha escuela, además de estar altamente involucrado en todo lo relacionado con ella. Desde hace unos años, la escuela ya dispone de un sitio Web, lo que le ha servido para crecer, tanto deportivamente como popularmente año tras año. Por eso, he pensado basarme en esta idea para realizar este proyecto con el objetivo de que el producto final sea lo suficientemente abierto, completo y sencillo de manejar como para que la Escuela de Fútbol de Mareo en Logroño pueda hacer uso total de ella en un futuro, y ayude a gestionar la actividad diaria de la escuela (noticias, resultados, plantillas, etc.) y a almacenar los datos de equipos, jugadores, padres, partidos, estadísticas y faltas de asistencia. Límites El proyecto está asignado a una escuela de fútbol real donde el cliente de la aplicación es la propia escuela de fútbol, en la figura de su director. Además, soy partícipe activo y futuro usuario de la aplicación por lo que tengo acceso directo a diversos empleados de la escuela a los que podré consultar requisitos, mostrar incrementos para pedir su opinión, mejoras, etc. Además, se establecerán una serie de requisitos mínimos, que explicaré más adelante en el Documento de Objetivos del Proyecto, que deberán satisfacer la aplicación, así como varias posibles mejoras que se irán llevando a cabo en función del tiempo disponible una vez alcanzados los objetivos mínimos. 7
11 Documento de Objetivos del Proyecto En este apartado se especifican las características del proyecto que se quiere realizar, su alcance, sus riesgos y otros aspectos similares. Además, se detallarán los principales entregables así como la descomposición de tareas y el plan de trabajo. Debido a que este documento se basa en estimaciones, será una de las partes más susceptibles a sufrir cambios y modificaciones. Objetivo El objetivo del proyecto es la creación de una aplicación Web para alojar toda la información referente a la Escuela de Fútbol de Mareo en Logroño. Además, los empleados de la escuela podrán almacenar, modificar y mostrar datos y estadísticas relacionadas tanto de los equipos como de los jugadores. También, se llevará un control de las faltas de asistencia a los entrenamientos con el objetivo de notificar de la falta al tutor/a o padre/madre del jugador mediante mensaje de texto a móvil y correo electrónico. El objetivo final es que la Escuela de Fútbol de Mareo en Logroño pueda hacer uso total de dicha aplicación. Participantes en el proyecto - Director: o Juan José Olarte Larrea, profesor del departamento de Matemáticas y Computación de la Universidad de La Rioja. - Alumno: o Abel Sierra Gómez Comunicaciones El director del proyecto y el alumno han llegado de mutuo acuerdo a que las comunicaciones entre ambos será mediante: - Correo electrónico: será la forma más habitual de comunicación para tratar pequeñas dudas e informar del estado del proyecto al director. También se utilizará para concretar reuniones en persona entre el director y el alumno. - Reuniones en persona: serán para tratar temas más importantes. Además, se levantará acta de cada reunión realizada. 8
12 Alcance del proyecto El alcance de un proyecto define y detalla los límites y objetivos del proyecto que se deberán haber alcanzado al término de su desarrollo. Para ello, se ha incluido una lista con los requisitos mínimos a cumplir en el proyecto y una lista de posibles ampliaciones que podrán permitir al alumno llevarlas a cabo. En todo caso, tanto las ampliaciones que se puedan incluir en el proyecto, como las que no, se documentarán a continuación. Requisitos mínimos alcanzables Creación de una aplicación Web sobre la Escuela de Fútbol de Mareo en Logroño que contendrá: - Toda la información referente a la Escuela de Fútbol de Mareo en Logroño. - Acceso restringido mediante usuario y contraseña de empleados para poder actualizar y obtener características relacionadas tanto de los equipos como de los jugadores de la Escuela de Fútbol de Mareo en Logroño. - Control de las faltas de asistencia de los jugadores a los entrenamientos, con el objetivo de notificar la falta al tutor/a o padre/madre del jugador mediante mensaje de texto a móvil o correo electrónico. Posibles ampliaciones de la plataforma - Creación de una Tienda Online, donde se podrá comprar productos relacionados con la Escuela de Fútbol de Mareo en Logroño. - Creación de un foro para todos los miembros de la Escuela de Fútbol de Mareo en Logroño. - Creación de un Chat para la comunicación en tiempo real de todos los miembros de la Escuela de Fútbol de Mareo en Logroño. Metodología El proyecto lo desarrollaré basándome en la metodología del Proceso Unificado del Desarrollo de Software, propuesto por Ivar Jacobson, Grady Booch y James Rumbaugh ([JAC00]), la cual se caracteriza por estar dirigida por casos de uso, centrada en la arquitectura y por seguir un ciclo de vida iterativo e incremental. He escogido esta metodología por ser muy conocida, y porque se adapta perfectamente al objetivo anteriormente explicado de ir añadiendo nuevas funcionalidades al sistema en cada iteración. Estas iteraciones ofrecen como resultado un incremento de la aplicación desarrollada que añade o mejora las funcionalidades del sistema en desarrollo. Esta metodología me va a permitir poder evaluar cada entregable, y de esta forma minimizar el riesgo de que el cliente esté insatisfecho, ya que sólo se desarrolla y entrega una parte de la aplicación. Además me permitirá recoger información del cliente útil para posteriores incrementos. 9
13 Tecnologías a utilizar Durante el desarrollo utilizaré diferentes tecnologías. Con el fin de elegir las más apropiadas para el proyecto, se ha realizado y hecho pruebas con diferentes tecnologías que ha derivado en la selección de las más adecuadas para la aplicación: La aplicación Web denominada Administrar y visualizar información he decidido, desde un principio, desarrollarla mediante un Sistema Gestor de Contenidos, por lo que he seleccionado las siguientes alternativas para su estudio: a) Drupal: es un sistema gestor de contenidos muy configurable que permite publicar artículos, imágenes, u otros archivos y servicios añadidos como foros, encuestas, votaciones, blogs y administración de usuarios y permisos. Además, es un sistema dinámico. Es un programa libre, con licencia GNU/GPL, escrito en PHP, desarrollado y mantenido por una activa comunidad de usuarios. Destaca por la calidad de su código y de las páginas generadas, el respeto de los estándares de la Web, y un énfasis especial en la usabilidad y consistencia de todo el sistema. Después de estudiarla, se desechó porque se comprobó que esta tecnología se utilizaba para entornos más profesionales y de alto rendimiento. Por tanto, como los usuarios que van hacer uso de la aplicación no tienen por qué disponer de un alto nivel de conocimientos informáticos, utilizaré una tecnología más sencilla y de fácil manejo. b) Joomla!: es un gestor de contenidos bastante maduro, ofrece innumerables funcionalidades y la posibilidad de instalar herramientas adicionales, puede adaptarse fácilmente a diversos proyectos Web o incluso a intranets, pueden montarse desde blogs hasta tiendas virtuales, gestores de descargas, sitios con foros o catálogos especializados, y un largo etc. En contraposición a Drupal, este gestor requiere menos control, tiene más aspectos a tener en cuenta, una curva de aprendizaje más corta, una mayor comunidad de usuarios y facilidades para la implementación de extensiones. Además su facilidad de uso y de administración, como su infinidad de plantillas hacen que para la aplicación a desarrollar sea la alternativa perfecta. Por último, su API completamente documentada y su gran popularidad, así como el interés en aprender esta nueva tecnología hace que sea la alternativa más válida y completa. Después de analizar estas dos alternativas he optado por Joomla!, ya que permite la creación de sitios Web y de completas aplicaciones online. Muchos de sus aspectos, incluyendo su facilidad de uso y su extensibilidad, lo han hecho muy popular entre desarrolladores y usuarios, habiendo sido galardonado en los años 2006 y 2007 con el CMS Award que premia a la mejor aplicación de estas características de código abierto. Su código es abierto y está escrito en PHP, usa base de datos MySQL y es un software libre, que se basa en herramientas similares, que no generan costos de licencias. Por todo esto y porque era una tecnología que quería conocer y aprender a utilizar, he decidido escogerla, además de porque creo que es la mejor alternativa ahora mismo para mi proyecto. 10
14 Tras seleccionar Joomla! como gestor de contenidos, el Sistema de Almacenamiento de información (SGBD) para toda la aplicación será: - MySQL: es un sistema de gestión de bases de datos relacional, multihilo y multiusuario. Sus principales características: o Posee un amplio subconjunto del lenguaje SQL. o Disponibilidad en gran cantidad de plataformas y sistemas. o Diferentes opciones de almacenamiento según si se desea velocidad en las operaciones o mayor número de operaciones disponibles. o Transacciones y claves foráneas. o Conectividad segura. Para la elección del lenguaje de programación para la aplicación Gestión de estadísticas y Control de faltas de asistencia al entrenamiento, se han seleccionado los siguientes para su estudio: a) ASP: es una tecnología de Microsoft del tipo "lado del servidor" para páginas Web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS). Intenta ser solución para un modelo de programación rápida ya que "programar en ASP es como programar en Visual Basic y C#", por supuesto con muchas limitaciones y algunas ventajas específicas en entornos Web. Estudié esta alternativa pero la deseché, ya que creo que es un lenguaje de programación algo limitado a solo funcionar con IIS. b) JSP: es un lenguaje multiplataforma para la creación de sitios Web dinámicos. Está orientado a desarrollar páginas Web en Java. Estudié esta alternativa para ampliar mis conocimientos obtenidos a lo largo de la carrera, en concreto, en la asignatura Programación de Bases de datos, pero decidí desecharla, ya que creo que para una mejor formación es mejor conocer diferentes lenguajes de programación. c) PHP: es un lenguaje multiplataforma para la creación de sitios Web dinámicos. Es usado principalmente en la interpretación del lado del servidor y no necesita ser compilado para ejecutarse. La mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas características específicas. Es libre, por lo que se presenta como una alternativa de fácil acceso para todos. Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. Tras estudiar las diferentes alternativas, he decidido que el lenguaje más apropiado para realizar la aplicación es PHP. Las principales razones por dicha elección son: el interés que tengo por aprender este lenguaje que es muy utilizado en aplicaciones Web y porque considero que conocerlo me va a facilitar mucho el trabajo con Joomla!, ya que como he comentado anteriormente, está escrito en PHP. 11
15 Identificación de riesgos y planes de acción En este apartado se intentará identificar todas las fuentes de riesgo para el proyecto y definir un modo de actuación para cada caso. Riesgos posibles 1. Desconocimiento de alguna herramienta necesaria por parte del alumno, como por ejemplo Joomla! o PHP. 2. Problemas personales del alumno: enfermedades, accidentes, etc. 3. Problemas hardware o software en el equipo de desarrollo. 4. Errores en la estimación de fechas, debidos a la falta de un horario estricto y fijo para el proyecto. 5. El producto final no satisface al cliente o al director. Actuaciones previstas ante los riesgos 1. Desconocimiento de alguna herramienta: ya se sabe que algunas herramientas requerirán un estudio previo, por lo dedicaré un tiempo a ello en la planificación de fechas. 2. Problemas personales del alumno: la planificación de fechas y horas dedicadas al proyecto, puede verse afectada por este problema debido a que la realización de dicho proyecto lo realiza una única persona. En este caso, se puede plantear un calendario con horas extras, para que el calendario vuelva a cuadrar. 3. Problemas hardware o software en el equipo de desarrollo: el proyecto se realizará en los dos ordenadores que el alumno dispone en casa, guardando en ellos copias de seguridad, además de en un disco duro externo para evitar pérdidas de información. 4. Errores en la estimación de fechas, debidos a la falta de un horario estricto y fijo para el proyecto: se documentará los fallos en la estimación y si hace falta se replantearán las tareas. De todas formas, se intentará comparar mis estimaciones con las de otros proyectos parecidos, además de ser realista con las estimaciones, si bien es mejor excederse en el tiempo estimado. 5. El producto final no satisface al cliente o al director: ambos estarán informados periódicamente por parte del alumno de los avances y cambios realizados. Además, como tienen acceso a cada incremento, el riesgo se minimiza. Entregables - Cada incremento: producto y documentación (porción de la memoria) asociada. - Manual de administrador de Joomla! - Aplicación final: sitio Web completo. 12
16 Descomposición de tareas Se han introducido las tareas en una tabla, asignándoles a cada una de ellas las horas estimadas para la realización de cada una de ellas. Todos estos datos son aproximados. Id Nombre de tarea Duración estimada en horas 1 Seguimiento proyecto 15 2 Revisiones 8 3 Reuniones 7 4 Gestión proyecto Generación DOP 17 6 Estudio previo 5 7 Descomposición de tareas 3 8 Asignar tiempo a tareas 2 9 Diagrama de Gantt 2 10 Documentación 4 11 Revisión 1 12 Generación memoria Estudio previo Creación memoria Revisión documento Análisis Estudio previo Establecer los límites del sistema a desarrollar 6 19 Establecer viabilidad del sistema 6 20 Especificación de requisitos 5 21 Documento de especificación de requisitos 5 22 Ciclo 1: Aplicación Web (Visualizar y administrar información) Análisis Casos de Uso 7 25 Identificar actores 1 26 Crear casos de uso 4 27 Diagramas actividades 1 28 Documentación 1 29 Clases en análisis 5 30 Identificar clases 3 31 Diagrama de clases 1 32 Generar documentación 1 33 Documentación 2 34 Revisión análisis 1 35 Diseño Diseño arquitectura del sistema 3 37 Diseño BD 3 38 Documentación 3 39 Diseño interfaces 3 40 Prototipos 3 41 Documentación 1 42 Revisión diseño 1 43 Construcción Generación de código Ciclo 2: Gestión Estadísticas Análisis Casos de Uso Identificar actores 1 49 Crear casos de uso 6 50 Diagramas actividades 1 51 Documentación 2 13
17 52 Clases en análisis 7 53 Identificar clases 3 54 Diagrama de clases 3 55 Generar documentación 1 56 Documentación 2 57 Revisión análisis 1 58 Diseño Diseño arquitectura del sistema 3 60 Diseño BD 5 61 Diagrama UML 3 62 Documentación 2 63 Diseño interfaces 4 64 Prototipos 4 65 Diseño clases Identificar clases 7 67 Diagrama de clases 5 68 Generar documentación 2 69 Documentación 2 70 Revisión diseño 1 71 Construcción Generación de código Plan de pruebas 7 74 Pruebas Unitarias, integración y sistema/aplicación 7 75 Ciclo 3: Control Faltas Asistencia Entrenamiento Análisis Casos de Uso 6 78 Identificar actores 1 79 Crear casos de uso 3 80 Documentación 2 81 Clases en análisis 6 82 Identificar clases 3 83 Diagrama de clases 2 84 Generar documentación 1 85 Documentación 2 86 Revisión análisis 1 87 Diseño Diseño arquitectura del sistema 2 89 Diseño BD 3 90 Diagrama UML 2 91 Documentación 1 92 Diseño interfaces 2 93 Prototipos 2 94 Diseño clases 6 95 Identificar clases 3 96 Diagrama de clases 2 97 Generar documentación 1 98 Documentación 2 99 Revisión diseño Construcción Generación de código Plan de pruebas Pruebas Unitarias, integración y sistema/aplicación Defensa proyecto Preparación Defensa 1 TOTAL HORAS PROYECTO 494 Tabla 1: Descomposición de tareas 14
18 Calendario de trabajo semanal A continuación se muestra el horario dedicado al desarrollo completo del proyecto: 9:00 10:00 Lunes Martes Miércoles Jueves Viernes Sábado Domingo 10:00 11:00 11:00 12:00 12:00 13:00 13:00 14:00 14:00 15:00 15:00 16:00 16:00 17:00 17:00 18:00 18:00 19:00 19:00 20:00 20:00 21:00 Horas empleadas Horas opcionales Horas dedicadas a otras tareas Diagrama de Gantt Figura 1: Diagrama de Gantt. Vista general. Figura 2: Diagrama de Gantt. Seguimiento del proyecto. 15
19 Figura 3: Diagrama de Gantt. Tareas de gestión del proyecto. Figura 4: Diagrama de Gantt. Tareas del análisis del proyecto. Figura 5: Diagrama de Gantt. Tareas del Ciclo 1: Administrar y visualizar aplicación Web. 16
20 Figura 6: Diagrama de Gantt. Tareas del Ciclo 2: Gestión estadísticas. Figura 7: Diagrama de Gantt. Tareas del Ciclo 3: Control faltas de asistencia. Figura 8: Diagrama de Gantt. Defensa del proyecto. 17
21 Gestión del proyecto Introducción Ha sido imposible seguir las fechas implantadas al inicio del proyecto debido a diversos motivos. Por ello, la finalización del proyecto y su defensa se han retrasado tres meses y medio. Factores del retraso El principal factor del retraso ha sido el no cumplimiento de las horas diarias que se especificaban en el Documento de Objetivos del Proyecto y que se iban a emplear en la realización del mismo. Esta circunstancia viene dada por diferentes motivos personales, lo que ha hecho que durante varios meses no pueda dedicar dichas horas para el desarrollo del proyecto. Comparación de estimaciones y resultados Comparación de fechas A continuación, se muestra una tabla en la que se comparan para todas las tareas las fechas de comienzo y finalización previstas con las fechas de comienzo y finalización reales. Nombre de tarea Fecha comienzo prevista Fecha comienzo real Fecha fin prevista Fecha fin real Seguimiento proyecto 03/10/2011 3/10/ /02/ /06/2012 Gestión proyecto 03/10/2011 3/10/ /02/ /06/2012 Análisis 1/11/ /01/ /11/ /01/2012 Ciclo 1: Aplicación Web (Visualizar y administrar 7/11/ /01/ /12/ /02/2012 información) Ciclo 2: Gestión Estadísticas 5/12/ /02/ /01/ /04/2012 Ciclo 3: Control Faltas Asistencia Entrenamiento 19/01/ /04/ /02/ /05/2012 Defensa proyecto 10/02/ /06/ /02/ /06/2012 Tabla 2: Comparativa por fechas Comparación de horas A continuación, se muestra una tabla en la que se comparan las horas estimadas y las horas reales de duración para todas las tareas. Nombre de tarea Horas estimadas Horas reales Seguimiento proyecto Gestión proyecto Análisis Ciclo 1: Aplicación Web (Visualizar y administrar información) Ciclo 2: Gestión Estadísticas Ciclo 3: Control Faltas Asistencia Entrenamiento Defensa proyecto 9 7 TOTAL HORAS PROYECTO Tabla 3: Comparativa por horas 18
22 Análisis de resultados Analizando la comparativa de fechas, el mayor retraso se produce al comienzo del análisis, ya que hay un salto de tiempo, de casi tres meses desde la fecha de comienzo estimada hasta la fecha de comienzo real, en el que no pude desarrollar el proyecto por lo comentado anteriormente. Además, debido a que la duración real es mayor que la estimada se produce otro retraso de más o menos medio mes, provocado por los riesgos identificados en el Documento de Objetivos del Proyecto. Por esta última causa comentada en la comparativa de fechas, se observa en la comparativa por horas, que exceptuando el seguimiento del proyecto y la defensa del proyecto, todas las tareas tienen una duración real mayor que la estimada. 19
23 Análisis Introducción Objetivo El objetivo del proyecto es desarrollar una aplicación Web para la Escuela de Fútbol de Mareo en Logroño, donde poder alojar, mantener y actualizar toda la información referente a dicha entidad. En este apartado, se pretende dar una visión global de lo que será la aplicación y sirva de apoyo vital para el diseño del software. Ámbito La aplicación Web debe permitir el acceso a todos los usuarios a la información de la Escuela de Fútbol de Mareo en Logroño. Además, debe permitir el acceso a los empleados a una zona restringida (mediante usuario y contraseña) donde deben poder obtener y actualizar las características, estadísticas y resultados. Por último, debe permitir introducir las faltas de asistencia de cada jugador y enviar, en caso de falta de asistencia a un entrenamiento, un correo electrónico y un mensaje de texto a móvil al padre, madre o tutor/a de dicho jugador. Visión general Sistema La aplicación se dividirá en tres partes: - La primera parte contendrá la información perteneciente a la Escuela de Fútbol de Mareo en Logroño, por lo que debe ser accesible desde Internet para todos los usuarios que quieran informarse sobre dicha escuela. Además contendrá todo lo necesario para administrar la aplicación Web, es decir, para mantenerla, actualizarla y modificarla mediante el gestor de contenidos. Este apartado será utilizado exclusivamente por un usuario administrador y en ella primará la facilidad de manejo. - La segunda parte estará dedicada a visualizar, almacenar, eliminar y modificar estadísticas y datos sobre los jugadores y equipos de la Escuela de Fútbol de Mareo en Logroño, es decir, incluirá una información detallada por equipos y jugadores para que los empleados, se informen a través de una zona restringida mediante usuario y contraseña. Esta aplicación será utilizada exclusivamente por todos los empleados pertenecientes a la Escuela de Fútbol de Mareo en Logroño. Existirán tres roles con distintos privilegios que explicaré más adelante: administrador, empleado y otro empleado. - Y por último, una parte para el control de faltas de asistencia a los entrenamientos de los jugadores. Esta aplicación se encargará de enviar al padre, madre o tutor/a del jugador un correo electrónico y un mensaje de texto a móvil avisando de la falta de asistencia al entrenamiento del jugador. 20
24 Como posibles ampliaciones de la aplicación Web cabe destacar - Una tienda online para la venta de productos relacionados con la Escuela de Fútbol de Mareo en Logroño. - La creación de un foro para todos los miembros de la Escuela de Fútbol de Mareo en Logroño, para que puedan exponer información, dudas o preguntas a los demás integrantes de dicha escuela. - La creación de un Chat para la comunicación en tiempo real de todos los miembros de la Escuela de Fútbol de Mareo en Logroño. Usuarios de la aplicación Diferentes usuarios accederán a la aplicación, y éstos estarán diferenciados entre sí por distintos roles que les permitirán realizar diferentes tareas. Teniendo en cuenta esto, se distinguen cuatro tipos de usuarios: - Usuario de consulta: es el usuario que accede a la aplicación Web a través de Internet para visualizar toda la información referente a la Escuela de Fútbol de Mareo en Logroño. No requiere de identificación. - Empleado: son los usuarios que pertenecen a la Escuela de Fútbol de Mareo en Logroño, tales como monitores, entrenadores, fisioterapeutas y coordinadores. Estos usuarios, podrán visualizar, almacenar y actualizar estadísticas y datos de jugadores y equipos. Cada empleado dispondrá de su usuario y contraseña para el acceso a esta zona restringida de la aplicación Web. Por último, comentar que, aunque en la escuela un coordinador tenga más funciones que un monitor o un entrenador, la aplicación les otorgará los mismos privilegios, por lo que los tres tendrán el mismo rol en la aplicación. - Administrador: es el usuario que podrá mantener, actualizar y modificar la aplicación Web. También podrá realizar las funciones del empleado. - Padre: usuario que recibirá, mediante correo electrónico y mensaje de texto a móvil, las faltas de asistencia al entrenamiento. 21
25 Visión general del sistema Para definir los requisitos iniciales de la aplicación voy a crear un diagrama de casos de uso de alto nivel para entender con una visión general cual es el problema y que soluciones voy a plantear. El diagrama de casos de uso de alto nivel obtenido es el siguiente: Figura 9: Visión general del sistema. Requisitos funcionales Del diagrama de casos de uso generado para dar una visión general de la aplicación se pueden deducir los siguientes requisitos funcionales como RF.n, donde n será el número de Requisito Funcional: RF.1: privilegios de administrador Existirá un perfil de administrador que tendrá total libertad para el acceso y control total de la aplicación. RF.2: privilegios de empleado El administrador creará perfiles para los distintos empleados de la Escuela de Fútbol de Mareo en Logroño, quienes podrán acceder a la parte restringida de la aplicación asociada a ellos. RF.3: control faltas de asistencia. Los empleados serán los encargados de controlar las faltas de asistencia. Se entiende por control al hecho de añadir las faltas para su posterior envío por parte de la aplicación de un correo electrónico y un mensaje a móvil a los padres, madres o tutores. RF.4: faltas de asistencia El padre, la madre o el/la tutor/a recibirá un mensaje de texto a móvil o un correo electrónico indicando que el jugador ha faltado al entrenamiento. Se enviará automáticamente justo después de que el empleado añada la falta a la aplicación. 22
26 Requisitos no funcionales A continuación numero los requisitos no funcionales como RNF.n, donde n será el número de Requisito no Funcional: RNF.1: requisitos de usabilidad El producto final deberá ser lo más sencillo posible de manejar, para una mayor compresión y rapidez de uso para los diferentes usuarios. RNF.2: requisitos de rendimiento El sistema deberá ser rápido y el tiempo de respuesta el mínimo posible para que la navegación sea lo más ágil posible. RNF.3: requisitos de mantenimiento La aplicación debe ser fácil de mantener una vez implementada. RNF.4: requisitos de seguridad La aplicación debe tener una gestión segura para impedir el acceso no autorizado y proteger de las amenazas más usuales como: Inyección SQL: es un método de inserción o inyección de código intruso que se vale de una vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar consultas a una base de datos. Para evitarlo en la aplicación, utilizaré el código necesario para ello. Ataques por contraseña: es cuando un atacante utiliza las técnicas necesarias para descubrir las contraseñas. Para evitarlo en la aplicación, las contraseñas serán almacenadas encriptadas y así evitar problemas al enviarlas y recibirlas con la base de datos. El algoritmo utilizado será MD5. Debilidad del sistema de autenticación: es cuando un usuario no autorizado accede a la aplicación. Para evitarlo se crearán sesiones para manejar la información que cada usuario necesita. Una vez el usuario cierre la sesión, o bien, pasen 10 minutos de inactividad, dicha sesión se destruirá. RNF.5: requisitos de concurrencia Se estudiará el problema de la concurrencia para evitar que haya problemas en el acceso concurrente de dos o más usuarios a la base de datos a la aplicación. Para ello, cuando un usuario modifique una determinada información, esta se bloqueará para que no surjan lecturas sucias u otros problemas. RNF.6: requisitos de privacidad Solo podrán acceder a la aplicación gestión de estadísticas, una vez registrados, empleados de la Escuela de Fútbol de Mareo en Logroño. La información almacenada en la aplicación, solo será utilizada para labores internas y cumplirá las disposiciones recogidas en la Ley Orgánica de Protección de Datos. 23
27 RNF.7: flexible de ampliar. Debe preverse la posibilidad de que en el futuro se desarrolle una tienda online para la venta de productos relacionados con la escuela, un foro para que puedan exponer sus dudas, preguntas, así como informar a los demás integrantes de dicha escuela, y un Chat para la comunicación en tiempo real de todos los miembros de la Escuela de Fútbol de Mareo en Logroño. RNF.8: requisitos de software La aplicación debe ser manejable en los navegadores más usados, tales como: Internet Explorer, Firefox, Chrome y Safari. 24
28 Ciclo 1: Aplicación Web (Administrar y visualizar información) Análisis Introducción Una vez definido el diagrama de casos de uso de alto nivel en el que se reflejan los requisitos generales que quiero que contenga mi sistema, y enunciados los requisitos funcionales generales del sistema que se deducen de él, voy a desglosar de una manera más detallada y específica los casos de uso anteriores, en diagramas de casos de uso que me hagan entender completamente la funcionalidad del sistema. Además, a partir de estos casos de uso podré obtener los requisitos específicos de cada una de las partes del sistema. Casos de Uso Administrar información de la aplicación Web En este apartado voy a refinar el caso de uso Administrar información generado en el diagrama de la visión general. Los diagramas de casos de uso que definen los requisitos que debe cumplir esta función son los siguientes: La figura 10 muestra el diagrama de casos de uso del administrador para la gestión de componentes de la aplicación. Figura 10: Diagrama de casos de uso administrar componentes Caso de uso 1: Administrar noticias - Definición: esta operación permitirá al administrador la gestión de las noticias mostradas en la aplicación. - Precondición: el usuario desea administrar las noticias de la aplicación. - Postcondición: se muestra el panel de control de noticias y las posibles operaciones a realizar. 25
29 Caso de uso 2: Administrar galería - Definición: esta operación permitirá al administrador la gestión de la galería mostrada en la aplicación. - Precondición: el usuario desea administrar la galería de la aplicación. - Postcondición: se muestra el panel de control de la galería y las posibles operaciones a realizar. Caso de uso 3 Administrar banner - Definición: esta operación permitirá al administrador la gestión de los banners de la aplicación. - Precondición: el usuario desea administrar los banners que contiene la aplicación. - Postcondición: se muestra el panel de control de los banners y las posibles operaciones a realizar. Caso de uso 4: Administrar contacto - Definición: esta operación permitirá al administrador gestionar los tipos de contacto de la aplicación. - Precondición: el usuario desea administrar los tipos de contacto. - Postcondición: se muestra el panel de control y las posibles operaciones a realizar. Caso de uso 5: Administrar plantillas - Definición: esta operación permitirá al administrador gestionar las plantillas de los diferentes equipos de la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea administrar las plantillas. - Postcondición: se muestra el panel de control de las plantillas y las posibles operaciones a realizar. Caso de uso 6: Administrar temporadas - Definición: esta operación permitirá al administrador gestionar las temporadas de los diferentes equipos de la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea administrar las temporadas. - Postcondición: se muestra el panel de control de las temporadas y las posibles operaciones a realizar. Caso de uso 7: Login - Definición: representa el mecanismo para identificar el rol que el usuario que accede a la aplicación asume. Consiste en la introducción del nombre de usuario y contraseña establecidos. Una vez que estos datos han sido proporcionados a la aplicación, la misma se encargará de realizar una autentificación obteniendo los privilegios que tiene el usuario en la aplicación y mostrando la interfaz apropiada para dicho usuario. - Precondición: el usuario debe estar validado dentro de la base de datos. Accede a la zona restringida mediante su nombre de usuario y su contraseña. - Postcondición: el usuario empleado podrá realizar las operaciones asignadas para su rol. 26
30 La figura 11 muestra el diagrama de casos de uso del administrador para la gestión de contenidos de la aplicación. Figura 11: Diagrama de casos de uso administrar contenidos de la aplicación Web Caso de uso 8: Agregar contenido - Definición: esta operación permitirá al administrador agregar los contenidos mostrados en la aplicación. - Precondición: el administrador desea agregar contenidos o artículos a la aplicación. - Postcondición: se muestra el panel de control de contenidos al administrador. Caso de uso 9: Modificar contenido - Definición: esta operación permitirá al administrador modificar los contenidos mostrados en la aplicación. - Precondición: el administrador desea modificar los contenidos o artículos de la aplicación. - Postcondición: se muestra el panel de control de contenidos al administrador. Caso de uso 10: Borrar contenido - Definición: esta operación permitirá al administrador borrar los contenidos de la aplicación. - Precondición: el administrador desea borrar los contenidos o artículos de la aplicación. - Postcondición: se muestra el panel de control de contenidos al administrador. 27
31 La figura 12 muestra el diagrama de casos de uso del administrador para la gestión de usuarios de la aplicación. Figura 12: Diagrama de casos de uso administrar usuarios de la aplicación Web Caso de uso 11: Registrar usuario - Definición: esta operación permitirá al administrador registrar o dar de alta a un nuevo usuario en la aplicación. - Precondición: el administrador desea registrar o dar de alta un nuevo usuario en la aplicación. - Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a realizar, con el nuevo usuario dado de alta. Caso de uso 12: Modificar usuario - Definición: esta operación permitirá al administrador modificar un usuario de la aplicación. - Precondición: el administrador desea modificar un usuario existente de la aplicación. - Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a realizar, con el usuario modificado. Caso de uso 13: Eliminar usuario - Definición: esta operación permitirá al administrador eliminar un usuario de la aplicación. - Precondición: el administrador desea eliminar un usuario existente de la aplicación. - Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a realizar, pero con el usuario eliminado. 28
32 La figura 13 muestra el diagrama de casos de uso del administrador para la gestión multimedia de la aplicación. Figura 13: Diagrama de casos de uso administrar multimedia de la aplicación Web Caso de uso 14: Subir archivo - Definición: esta operación permitirá al administrador subir archivos al servidor. - Precondición: el administrador desea subir un archivo al servidor. - Postcondición: se muestra el panel gestor de archivos con el nuevo archivo. Caso de uso 15: Bajar archivo - Definición: esta operación permitirá al administrador eliminar o bajar un archivo del servidor. - Precondición: el administrador desea eliminar o bajar un archivo del servidor. - Postcondición: se muestra el panel gestor de archivos sin el archivo eliminado. La figura 14 muestra el diagrama de casos de uso del administrador para la gestión de inscripciones. Figura 14: Diagrama de casos de uso administrar inscripciones de la aplicación Web 29
33 Caso de uso 16: Administrar inscripción campus - Definición: esta operación permitirá al administrador recibir en el correo electrónico la inscripción rellenada del campus. - Precondición: el usuario desea obtener las nuevas inscripciones para el campus. El administrador deberá estar logueado en la cuenta del correo electrónico. - Postcondición: se muestra la nueva inscripción para el campus. Caso de uso 17: Administrar inscripción escuela - Definición: esta operación permitirá al administrador recibir en el correo electrónico la inscripción rellenada para jugar en la Escuela. - Precondición: el usuario desea obtener las nuevas inscripciones para el acceso a la Escuela. El administrador deberá estar logueado en la cuenta del correo electrónico. - Postcondición: se muestra la nueva inscripción para el acceso a la Escuela. Caso de uso 18: Login correo - Definición: representa el mecanismo para identificar el rol que el usuario que accede al correo electrónico asume. Consiste en la introducción del nombre de usuario y contraseña establecidos. Una vez que estos datos han sido proporcionados a la cuenta de correo, la misma se encargará de realizar una autentificación obteniendo los privilegios que tiene el usuario en la cuenta y mostrando la interfaz apropiada para el usuario. - Precondición: el administrador debe estar validado. Accede a la zona restringida mediante su nombre de usuario y su contraseña. - Postcondición: el administrador podrá realizar las operaciones asignadas para su rol. Visualizar información de la aplicación Web En este apartado voy a refinar el caso de uso Visualizar información generado en el diagrama de la visión general. El diagrama de casos de uso que define los requisitos que debe cumplir esta función es el siguiente: Figura 15: Diagrama de casos de uso visualizar información aplicación Web 30
34 Caso de uso 19: Ver información temporada - Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web, informarse sobre los calendarios, resultados y clasificaciones de los diferentes equipos de la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea acceder a la información de las diferentes temporadas. - Postcondición: se muestra la página con la información sobre las temporadas de los diferentes equipos. Caso de uso 20: Leer noticias - Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web, informarse sobre las últimas noticias de la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea acceder a las noticias. - Postcondición: se muestra la página de noticias. Caso de uso 21: Ver información campus - Definición: esta operación permitirá a los usuarios acceder a la información referente al campus. Dependiendo de lo que considere el usuario, podrá inscribirse al campus. - Precondición: el usuario desea acceder a la información del campus. - Postcondición: se muestra la página con la información sobre el campus. Caso de uso 22: Inscripción campus - Definición: permitirá al usuario inscribirse en el campus de la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea rellenar la inscripción para apuntarse al campus. - Postcondición: se muestra al usuario un mensaje que la inscripción se ha realizado correctamente. Caso de uso 23: Ver organigrama - Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web, informarse sobre el organigrama de la Escuela de Fútbol de Mareo en Logroño, es decir, ver las competencias de cada persona que la compone. - Precondición: el usuario desea acceder al organigrama. - Postcondición: se muestra la página con la información referente al organigrama de la Escuela de Fútbol de Mareo en Logroño. Caso de uso 24: Ver plantillas - Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web, informarse sobre las diferentes plantillas que hay en la Escuela de Fútbol de Mareo en Logroño. - Precondición: el usuario desea acceder a las plantillas. - Postcondición: se muestra la página con la información referente a las diferentes plantillas de la Escuela de Fútbol de Mareo en Logroño. 31
35 Caso de uso 25: Inscripción escuela - Definición: esta operación permitirá apuntarse en la Escuela mediante un formulario de inscripción. - Precondición: el usuario desea inscribirse en la Escuela de Fútbol de Mareo en Logroño. - Postcondición: se envía un mensaje indicando al usuario que su inscripción se realizó correctamente. Caso de uso 26: Contacto - Definición: esta operación permitirá al usuario contactar con la Escuela de Fútbol de Mareo en Logroño mediante correo electrónico. Además permitirá al usuario conocer otras formas de contacto. - Precondición: el usuario desea ponerse en contacto con la Escuela de Fútbol de Mareo en Logroño. - Postcondición: se muestra la información de las diferentes formas para contactar con la escuela. Requisitos funcionales A continuación numero los requisitos funcionales como RF.n, donde n será el número de Requisito Funcional: - RF.1: gestión del contenido Gestión total sobre la configuración de la aplicación y la inclusión de nuevos contenidos o artículos. Casos de uso: el requisito se deriva de los casos de uso 8.-Agregar contenido, 9.- Modificar contenido y 10.-Borrar contenido. - RF.2: gestión de usuarios Gestión sobre los distintos tipos de usuarios que pueden acceder a la aplicación. Casos de uso: el requisito se deriva de los casos de uso 11.-Registrar usuario, 12.- Modificar usuario y 13.-Eliminar usuario. - RF.3: gestión de archivos Gestión sobre la subida y bajada de los distintos archivos que se quieren incluir o eliminar de la aplicación. Casos de uso: el requisito se deriva de los casos de uso 14.-Subir archivo y 15.-Bajar archivo - RF.4: gestión de inscripciones Gestión de las inscripciones de los usuarios a la escuela y al campus. Casos de uso: el requisito se deriva de los casos de uso 16. Administrar inscripción campus, 17.- Administrar inscripción escuela. 32
36 - RF.5: la aplicación debe mostrar información. Debe permitir a los usuarios que acceden a la aplicación informarse sobre las noticias, las temporadas, las plantillas, etc. es decir, sobre toda la información referente a la Escuela de Fútbol de Mareo en Logroño. Casos de uso: el requisito se deriva de los casos de uso 19.-Ver información temporadas, 20.- Leer noticias, 21.-Ver información campus, 23.-Ver organigrama y 24.-Ver plantillas. - RF.6: la aplicación debe permitir inscripciones. Permitir la inscripción de los usuarios a la escuela y al campus. Casos de uso: el requisito se deriva de los casos de uso 22.- Inscripción escuela y 25.- Inscripción escuela. - RF.7: contacto Permitir a los usuarios informarse y comunicarse directamente con el director de la Escuela de Fútbol de Mareo en Logroño. Casos de uso: el requisito se deriva del caso de uso 26.-Contacto. - RF.8: posibilitar el cambio de información mostrada en la aplicación La aplicación debe permitir la edición del contenido. De ello se encargará el administrador. Casos de uso: el requisito se deriva de los casos de uso 1.- Administrar noticias, 2.- Administrar galería, 3.- Administrar banner, 4.- Administrar contacto, 5.- Administrar plantillas y 6.- Administrar temporadas. - RF.9: privilegios del administrador Existirá un perfil de administrador que tendrá control total de la aplicación. El administrador podrá crear nuevos usuarios para administrar todo lo relacionado con la gestión de información de la aplicación Web. Además podrá asignarles diferentes privilegios. - RF.10: la plataforma contará con un manual para el administrador que servirá para crear una pequeña ayuda para la futura administración de la aplicación Web. 33
37 Diseño Introducción Este ciclo está desarrollado al completo por el gestor de contenidos Joomla!. Como he comentado anteriormente en el Documento de Objetivos del Proyecto, no había utilizado nunca esta tecnología, pero una vez estudiado el funcionamiento del mismo, me ha permitido realizar de una forma sencilla y rápida el diseño de la aplicación Web. La arquitectura Web necesaria para ejecutar Joomla! la he conseguido utilizando Xampp, servidor que instala Apache, MySQL, PHP y PHPMyAdmin. Una vez hecho esto, la instalación de Joomla! es muy sencilla: comprueba las versiones de PHP y MySQL instaladas para ver que todo está correcto y pide configurar la base de datos donde se va a instalar el contenido del sitio Web. La base de datos contiene todos los datos necesarios para el correcto funcionamiento de la aplicación Web, es decir, toda la información sobre usuarios, sesiones, plantillas, módulos, componentes y contenidos. A continuación, muestro varios ejemplos donde aparecen diferentes tablas utilizadas por Joomla!. Figura 16: Tablas BD Joomla!. Menu 34
38 Figura 17: Tablas BD Joomla!. Banners Figura 18: Tablas BD Joomla!. Usuarios 35
39 Descripción de los elementos básicos de Joomla! - Plantillas: la plantilla (template) proporciona el aspecto visual para la aplicación Web. Al instalar Joomla!, se incluyen varias plantillas, tanto para el Panel de Control del Administrador como para el diseño del sitio Web. Por último, es preciso comentar que existen multitud de sitios Web que ofrecen plantillas gratuitas o comerciales. En mi caso, he utilizado la plantilla GK Sporter. - Componentes: son pequeñas aplicaciones independientes entre sí que gestionan la información dentro de Joomla!. Los componentes añaden distintas funcionalidades a Joomla! y lo convierten en mucho más que una Web de artículos o noticias. La instalación estándar de Joomla! incluye: o Componente que gestiona los contenidos: com_content. o Componente que administra y muestra la página principal del sitio Web: com_frontpage. o Componente encargado de administrar los contactos y enviar los mensajes por que escriben desde el formulario los usuarios: com_contact. o Componente de administración de banner: com_banners. o Componente de encuestas y votaciones: com_poll. o Componente de gestión y publicación de enlaces: com_weblinks. o Componentes de sindicación de noticias (hacia otros sitios: com_rss y desde otros sitios: com_newsfeeds. o Componente que genera las ventanas internas que contienen otras páginas externas (iframes): com_wrapper. o Componente de mensajería interna: com_messages. o Componente del buscador interno: com_search. o Los componentes relacionados con funciones de usuario: com_login, com_user, y com_registration. - Módulos: son extensiones o complementos de Joomla! que permiten añadir bloques de información secundaria en diferentes posiciones o zonas de la plantilla. El ejemplo más claro de módulo es el menú principal (mod_mainmenu) que facilita la navegación por el sitio Web. - Plugins: son extensiones que realizan dentro de Joomla! una amplia variedad de funciones relacionadas fundamentalmente con la autentificación de usuarios, el funcionamiento del buscador interno o con la edición de contenidos. Por ejemplo, en la aplicación Web he instalado un plugin para la utilización del API de Google Maps. 36
40 Prototipos de interfaz En este apartado muestro los bocetos de los prototipos de interfaz que voy a utilizar en este primer ciclo sobre la aplicación Web. Estos prototipos los seguiré de guía a la hora de diseñar las interfaces de la aplicación, pero no necesariamente será así estructurado el diseño final de la interfaz. Acceso administrador: Figura 19: Prototipo de interfaz acceso administrador. Login Panel de control del administrador: Figura 20: Prototipo de interfaz panel de control del administrador. 37
41 Gestor categorías: Figura 21: Prototipo de interfaz gestor categorías. Página principal visualización de la aplicación Web: Figura 22: Prototipo de interfaz aplicación Web 38
42 Página inscripción visualización de la aplicación Web: Figura 23: Prototipo de interfaz inscripción 39
43 Construcción Interfaces definitivas En esta primera iteración, analizaré cuales van a ser las interfaces que presentará la aplicación Web, tanto para administrar la información como para visualizarla. Interfaces de administración Interfaz acceso administrador: Inicialmente se va a ver cuál es la interfaz de página que utilizo para administrar la aplicación Web. Para acceder a ella, se introduce la siguiente URL: y se mostrará el formulario de acceso: Figura 24: Interfaz acceso administrador. Login Una vez que me he logueado, accedo al Panel de Control del Administrador: Figura 25: Interfaz panel de control del administrador. Las diferentes partes en las que se divide el Panel de Control del Administrador son: 1) Menú para acceder a todas las funciones disponibles de administración. Además, en la parte derecha del menú se encuentra: información de los usuarios no conectados al front-end y de los conectados a la administración, los mensajes privados que ha recibido el usuario que está conectado, el enlace para ver el sitio Web que estoy creando y el enlace para finalizar sesión (Finalizar). 40
44 2) Iconos de acceso rápido a las funciones más utilizadas del Panel de Control del Administrador. 3) Información sobre los usuarios conectados, los artículos populares y los últimos artículos añadidos a la aplicación Web. El componente más importante para crear lo que los usuarios verán en la aplicación Web, es el componente contenido. A continuación voy a mostrar las interfaces para gestionar dicho contenido en Joomla! Interfaz gestor categorías: Todos los artículos se organizan en categorías. Cualquier categoría puede contener artículos y otras categorías. Figura 26: Interfaz gestor categorías. 41
45 Interfaz gestor artículos: Son los textos e imágenes que se muestran en una página de la aplicación Web. Figura 27: Interfaz gestor artículos. Para crear un nuevo artículo se pulsa sobre el icono nuevo, mostrando: Figura 28: Interfaz nuevo artículo. 42
46 Interfaz gestor multimedia: Para insertar imágenes, las subo utilizando el gestor multimedia y luego tengo que manipular las propiedades de la imagen con el botón edición Imagen en el menú editor cuando añado o edito un artículo. Figura 29: Interfaz gestor multimedia. Interfaz gestor menús: Por defecto, la instalación genera un menú principal, el cuál podré editarlo pero nunca eliminar. Además la aplicación cuenta con un menú secundario. Figura 30: Interfaz gestor menús. Interfaz gestor usuarios: En este apartado se puede añadir, editar y eliminar a los usuarios. Además podré asignar a cada uno de ellos los privilegios que desee. Figura 31: Interfaz gestor usuarios. 43
47 Interfaz gestor extensiones: Desde este panel se puede instalar módulos, plugins, extensiones, etc. para poder utilizarlos en la aplicación Web. Figura 32: Interfaz gestor extensiones. Interfaces de visualización Interfaz página inicial: En este apartado muestro las interfaces de visualización de la aplicación Web que voy a utilizar para mostrar a los usuarios toda la información perteneciente a la Escuela de Fútbol de Mareo en Logroño. Figura 33: Interfaz página principal visualización de la aplicación Web. 44
48 Interfaz inscripción escuela: Figura 34: Interfaz inscripción a la Escuela de Fútbol de Mareo en Logroño. 45
49 Ciclo 2: Gestionar estadísticas Análisis Introducción En este segundo ciclo del sistema voy a incrementar al sitio Web con las funcionalidades necesarias para poder visualizar, almacenar y actualizar las diferentes estadísticas y datos sobre los jugadores y equipos de la Escuela de Fútbol de Mareo en Logroño. A esta nueva aplicación Web se accede a través del enlace Zona Entrenadores del menú secundario de la aplicación Web del primer ciclo. Los usuarios que pueden realizar gestiones en esta aplicación, son los usuarios con roles: empleado y administrador. Estos usuarios deben acceder a esta zona restringida mediante nombre de usuario (nombre y primer apellido sin espacios) y contraseña. Casos de Uso Gestionar estadísticas En este apartado voy a refinar el caso de uso Gestionar estadísticas generado en el diagrama de la visión general. Los diagramas de casos de uso que definen los requisitos que debe cumplir esta función son los siguientes: La figura 35 muestra el diagrama de casos de uso para la gestión de un empleado. Como se puede observar, el usuario empleado solo puede visualizar los datos. Figura 35: Diagrama de casos de uso para la gestión de un empleado. Caso de uso 27: Visualizar empleado - Definición: esta operación permitirá al empleado o al administrador visualizar los datos de un empleado. - Precondición: el empleado o el administrador desea visualizar un empleado. - Postcondición: se muestran los datos del empleado. 46
50 Caso de uso 28 Añadir empleado - Definición: esta operación permitirá al administrador añadir los datos de un nuevo empleado. - Precondición: el administrador desea añadir un empleado. - Postcondición: se añaden los datos del nuevo empleado. Caso de uso 29: Modificar empleado - Definición: esta operación permitirá al administrador modificar los datos de un empleado. - Precondición: el administrador desea modificar los datos de un empleado. - Postcondición: se modifican los datos de un empleado. - Caso de uso 30: Eliminar empleado - Definición: esta operación permitirá al administrador eliminar los datos de un empleado. - Precondición: el administrador desea eliminar un empleado. - Postcondición: se eliminan los datos del empleado. Caso de uso 31: Login - Definición: representa el mecanismo para identificar el rol que el usuario que accede a la aplicación asume. Consiste en la introducción del nombre de usuario y contraseña establecidos. Una vez que estos datos han sido proporcionados a la aplicación, la misma se encargará de realizar una autentificación obteniendo los privilegios que tiene el usuario en la aplicación y mostrando la interfaz apropiada para dicho usuario. - Precondición: el usuario debe estar validado dentro de la base de datos. Accede a la zona restringida mediante su nombre de usuario y su contraseña. - Postcondición: el usuario podrá realizar las operaciones asignadas para su rol. La figura 36 muestra el diagrama de casos de uso para la gestión de un entrenador. Como se puede observar, el usuario empleado solo puede visualizar los datos. Figura 36: Diagrama de casos de uso para la gestión de un entrenador. 47
51 Caso de uso 32: Visualizar entrenador - Definición: esta operación permitirá al administrador o al empleado visualizar los datos de un entrenador. - Precondición: el empleado o el administrador desea visualizar un entrenador. - Postcondición: se muestran los datos del entrenador. Caso de uso 33: Añadir entrenador - Definición: esta operación permitirá al administrador añadir los datos de un nuevo entrenador. - Precondición: el administrador desea añadir un entrenador. - Postcondición: se añaden los datos del nuevo entrenador. Caso de uso 34: Modificar entrenador - Definición: esta operación permitirá al administrador modificar los datos de un entrenador. - Precondición: el administrador desea modificar los datos de un entrenador. - Postcondición: se modifican los datos de un entrenador. Caso de uso 35: Eliminar entrenador - Definición: esta operación permitirá al administrador eliminar los datos de un entrenador. - Precondición: el administrador desea eliminar un entrenador. - Postcondición: se eliminan los datos del entrenador. La figura 37 muestra el diagrama de casos de uso para la gestión de un administrador. Como se puede observar, el usuario empleado no tiene acceso a ninguna de estas acciones. Figura 37: Diagrama de casos de uso para la gestión de un administrador. 48
52 Caso de uso 36: Visualizar administrador - Definición: esta operación permitirá al administrador visualizar los datos de un administrador. - Precondición: el administrador desea visualizar un administrador. - Postcondición: se muestran los datos del administrador. Caso de uso 37: Añadir administrador - Definición: esta operación permitirá al administrador añadir los datos de un nuevo administrador. - Precondición: el administrador desea añadir un administrador. - Postcondición: se añaden los datos del nuevo administrador. Caso de uso 38: Modificar administrador - Definición: esta operación permitirá al administrador modificar los datos de un administrador. - Precondición: el administrador desea modificar los datos de un administrador. - Postcondición: se modifican los datos de un administrador. Caso de uso 39: Eliminar administrador - Definición: esta operación permitirá al administrador eliminar los datos de un administrador. - Precondición: el administrador desea eliminar un administrador. - Postcondición: se eliminan los datos del administrador. La figura 38 muestra el diagrama de casos de uso para la gestión de un equipo. Figura 38: Diagrama de casos de uso para la gestión de un equipo. Caso de uso 40: Visualizar equipo - Definición: esta operación permitirá al empleado o al administrador visualizar los datos de un equipo. - Precondición: el empleado o el administrador desea visualizar un equipo. - Postcondición: se muestran los datos del equipo. 49
53 Caso de uso 41: Añadir equipo - Definición: esta operación permitirá al empleado o al administrador añadir los datos de un nuevo equipo. - Precondición: el empleado o el administrador desea añadir un equipo. - Postcondición: se añaden los datos del nuevo equipo. Caso de uso 42: Modificar equipo - Definición: esta operación permitirá al empleado y al administrador modificar los datos de un equipo. - Precondición: el empleado o el administrador desea modificar los datos de un equipo. - Postcondición: se modifican los datos de un equipo. Caso de uso 43: Eliminar equipo - Definición: esta operación permitirá al empleado o al administrador eliminar los datos de un equipo. - Precondición: el empleado o el administrador desea eliminar un equipo. - Postcondición: se eliminan los datos del equipo. A partir de aquí, para que la visualización de los diagramas sea más clara, solamente se incluye el usuario empleado en los diagramas, si bien el usuario administrador tiene los mismos privilegios en todos estos casos. La figura 39 muestra el diagrama de casos de uso para la gestión de un jugador. Figura 39: Diagrama de casos de uso para la gestión de un jugador. Caso de uso 44: Visualizar jugador - Definición: esta operación permitirá al empleado o al administrador visualizar los datos de un jugador. - Precondición: el empleado o el administrador desea visualizar un jugador. - Postcondición: se muestran los datos del jugador. 50
54 Caso de uso 45: Añadir jugador - Definición: esta operación permitirá al empleado o al administrador añadir los datos de un nuevo jugador. - Precondición: el empleado o el administrador desea añadir un jugador. - Postcondición: se añaden los datos del nuevo jugador. Caso de uso 46: Modificar jugador - Definición: esta operación permitirá al empleado o al administrador modificar los datos de un jugador. - Precondición: el empleado o el administrador desea modificar los datos de un jugador. - Postcondición: se modifican los datos de un jugador. Caso de uso 47: Eliminar jugador - Definición: esta operación permitirá al empleado o al administrador eliminar los datos de un jugador. - Precondición: el empleado o el administrador desea eliminar un jugador. - Postcondición: se eliminan los datos del jugador. La figura 40 muestra el diagrama de casos de uso para la gestión de un partido. Figura 40: Diagrama de casos de uso para la gestión de un partido. Caso de uso 48: Visualizar partido - Definición: esta operación permitirá al empleado o al administrador visualizar los datos de un partido. - Precondición: el empleado o el administrador desea visualizar un partido. - Postcondición: se muestran los datos del partido. 51
55 Caso de uso 49: Añadir partido - Definición: esta operación permitirá al empleado o al administrador añadir los datos de un nuevo partido. - Precondición: el empleado o el administrador desea añadir un partido. - Postcondición: se añaden los datos del nuevo partido. Caso de uso 50: Modificar partido - Definición: esta operación permitirá al empleado o al administrador modificar los datos de un partido. - Precondición: el empleado o el administrador desea modificar los datos de un partido. - Postcondición: se modifican los datos de un partido. Caso de uso 51: Eliminar partido - Definición: esta operación permitirá al empleado o al administrador eliminar los datos de un partido. - Precondición: el empleado o el administrador desea eliminar un partido. - Postcondición: se eliminan los datos del partido. La figura 41 muestra el diagrama de casos de uso para la gestión de estadísticas. Figura 41: Diagrama de casos de uso para la gestión de estadísticas. Caso de uso 52: Visualizar estadísticas - Definición: esta operación permitirá al empleado o al administrador visualizar las estadísticas de los partidos de un jugador o de un equipo. - Precondición: el empleado o el administrador desea visualizar las estadísticas de los partidos de un jugador o de un equipo. - Postcondición: se muestran las estadísticas de los partidos de un jugador o de un equipo. 52
56 Caso de uso 53: Añadir estadísticas - Definición: esta operación permitirá al empleado o al administrador añadir las estadísticas del partido de un jugador o de un equipo. - Precondición: el empleado o el administrador desea añadir las estadísticas del partido de un jugador o de un equipo. - Postcondición: se añaden las estadísticas del partido de un jugador o de un equipo. Caso de uso 54: Modificar estadísticas - Definición: esta operación permitirá al empleado o al administrador modificar las estadísticas del partido de un jugador o de un equipo. - Precondición: el empleado o el administrador desea modificar las estadísticas del partido de un jugador o de un equipo. - Postcondición: se modifican las estadísticas del partido de un jugador o de un equipo. Caso de uso 55: Eliminar estadísticas - Definición: esta operación permitirá al empleado o al administrador eliminar las estadísticas del partido de un jugador o de un equipo. - Precondición: el empleado o el administrador desea eliminar las estadísticas del partido de un jugador o de un equipo. - Postcondición: se eliminan las estadísticas del partido de un jugador o de un equipo. La figura 42 muestra el diagrama de casos de uso para la gestión de un padre. Figura 42: Diagrama de casos de uso para la gestión de un padre. Caso de uso 56: Visualizar padre - Definición: esta operación permitirá al empleado o al administrador visualizar los datos del padre o tutor del jugador. - Precondición: el empleado o el administrador desea visualizar los datos del padre o tutor del jugador. - Postcondición: se muestran los datos del padre o tutor del jugador. 53
57 Caso de uso 57: Añadir padre - Definición: esta operación permitirá al empleado o al administrador añadir los datos de un nuevo padre o tutor del jugador. - Precondición: el empleado o el administrador desea añadir un padre o tutor del jugador. - Postcondición: se añaden los datos del nuevo padre o tutor del jugador. Caso de uso 58: Modificar padre - Definición: esta operación permitirá al empleado o al administrador modificar los datos los datos del padre o tutor del jugador. - Precondición: el empleado o el administrador desea modificar los datos del padre o tutor del jugador. - Postcondición: se modifican los datos del padre o tutor del jugador. Caso de uso 59: Eliminar padre - Definición: esta operación permitirá al empleado o al administrador eliminar los datos del padre o tutor del jugador. - Precondición: el empleado o el administrador desea eliminar los datos del padre o tutor del jugador. - Postcondición: se eliminan los datos del padre o tutor del jugador. Requisitos funcionales A continuación, se muestran los requisitos funcionales: RF.1: gestión de un empleado Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado tendrá control para visualizar los empleados y cada administrador tendrá control para visualizar, añadir, eliminar y modificar los empleados almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 27.-Visualizar empleado, 28-Añadir empleado, 29.-Modificar empleado y 30.-Eliminar empleado. RF.2: gestión de un entrenador Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado tendrá control para visualizar los entrenadores y cada administrador tendrá control para visualizar, añadir, eliminar y modificar los entrenadores almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 32.-Visualizar entrenador, 33.-Añadir entrenador, 34.- Modificar entrenador y 35.- Eliminar entrenador. RF.3: gestión de un administrador Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada administrador tendrá control para visualizar, añadir, 54
58 eliminar y modificar los administradores almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 36.-Visualizar administrador, 37.-Añadir administrador, 38.- Modificar administrador y 39.- Eliminar administrador. RF.4: gestión de un equipo Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y cada administrador tendrá control para visualizar, añadir, eliminar y modificar los equipos almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 40.-Visualizar equipo, 41.-Añadir equipo, 42.-Modificar equipo y 43.-Eliminar equipo. RF.5: gestión de un jugador Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y cada administrador tendrá control para visualizar, añadir, eliminar y modificar los jugadores almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 44.-Visualizar jugador, 45.-Añadir jugador, 46.- Modificar jugador y 47.-Eliminar jugador. RF.6: gestión de un partido Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y administrador tendrá control para visualizar, añadir, eliminar y modificar los partidos almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 48.-Visualizar partido, 49.-Añadir partido, 50.- Modificar partido y 51.- Eliminar partido. RF.7: gestión de estadísticas Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y cada administrador tendrá control para visualizar, añadir, eliminar y modificar las estadísticas almacenadas en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 52.-Visualizar estadísticas, 53.-Añadir estadísticas, 54.- Modificar estadísticas y 55.- Eliminar estadísticas. RF.8: gestión de un padre Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y administrador tendrá control para visualizar, añadir, eliminar y modificar los padres almacenados en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 56.-Visualizar padre, 57.-Añadir padre, 58.- Modificar padre y 59.- Eliminar padre. 55
59 RF.9: privilegios de administrador Existirá un perfil de administrador que tendrá total libertad para el acceso y control total de la aplicación. El nombre de usuario y la contraseña serán asignados al administrador a la entrega de la aplicación. Por último comentar que el administrador podrá crear más perfiles de administrador. RF.10: privilegios de empleado El administrador creará perfiles para los distintos empleados de la Escuela de Fútbol de Mareo en Logroño, quienes podrán acceder a la parte restringida de la aplicación asociada a ellos. El nombre de usuario (nombre y primer apellido sin espacios) y la contraseña serán asignados al empleado por el administrador. El empleado podrá cambiar la contraseña cuantas veces desee. Requisitos no funcionales A continuación, se muestran los requisitos no funcionales: RNF.1: requisitos de usabilidad El producto final deberá ser lo más sencillo posible de manejar, para una mayor compresión y rapidez de uso para los diferentes usuarios RNF.2: requisitos de seguridad La aplicación debe tener una gestión segura para impedir el acceso no autorizado y proteger de las amenazas más usuales como: Inyección SQL: es un método de inserción o inyección de código intruso que se vale de una vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar consultas a una base de datos. Para evitarlo en la aplicación, utilizaré el código necesario para ello. Ataques por contraseña: es cuando un atacante utiliza las técnicas necesarias para descubrir las contraseñas. Para evitarlo en la aplicación, las contraseñas serán almacenadas encriptadas y así evitar problemas al enviarlas y recibirlas con la base de datos. El algoritmo utilizado será MD5. Debilidad del sistema de autenticación: es cuando un usuario no autorizado accede a la aplicación. Para evitarlo se crearán sesiones para manejar la información que cada usuario necesita. Una vez el usuario cierre la sesión, o bien, pasen 10 minutos de inactividad, dicha sesión se destruirá. RNF.3: requisitos de concurrencia Se estudiará el problema de la concurrencia para evitar que haya problemas en el acceso concurrente de dos o más usuarios a la base de datos de la aplicación. Para ello, cuando un usuario modifique una determinada información, esta se bloqueará para que no surjan lecturas sucias u otros problemas. 56
60 RNF.4: requisitos de privacidad Solo podrán acceder a la aplicación, una vez registrados por el administrador, empleados de la Escuela de Fútbol de Mareo en Logroño. La información almacenada en la aplicación solo será utilizada para labores internas y cumplirá las disposiciones recogidas en la Ley Orgánica de Protección de Datos. RNF.5: requisitos de mantenimiento La aplicación debe ser fácil de mantener una vez implementada. RNF.6: requisitos de rendimiento El sistema deberá ser rápido y el tiempo de respuesta el mínimo posible para que la navegación sea lo más ágil posible. RNF.7: requisitos de software La aplicación debe ser manejable en los navegadores más usados, tales como: Internet Explorer, Firefox, Chrome y Safari. Prototipos de interfaz En este apartado se muestran los bocetos de los prototipos de interfaz que se van a utilizar en este segundo ciclo sobre la aplicación de gestión de estadísticas. Estos prototipos se seguirán como guía a la hora de diseñar las interfaces de la aplicación, pero no necesariamente será así estructurado el diseño final de la interfaz. Como he comentado anteriormente, esta aplicación es de acceso restringido para los diferentes empleados y administradores de la Escuela de Fútbol de Mareo en Logroño, por los que serán los encargados de interactuar con la interfaz para visualizar, añadir, eliminar y modificar cualquier información contenida en la aplicación. A continuación, se muestra una primera toma de cómo estará estructurada la interfaz de la aplicación: Login: Figura 43: Prototipo de interfaz login 57
61 Visualizar información: Figura 44: Prototipo de interfaz visualizar información. Añadir información: Figura 45: Prototipo de interfaz añadir información 58
62 Modificar información: Figura 46: Prototipo de interfaz modificar información Prototipo de interfaz eliminar información: Figura 47: Prototipo de interfaz eliminar información 59
63 Clases de análisis A continuación, se muestra el diagrama de clases UML referente a este segundo ciclo sobre la aplicación de gestión de estadísticas: Figura 48: UML. Clases de análisis. Clases Empleado: representa a todos los empleados que forman parte de la Escuela de Fútbol de Mareo en Logroño. De esta superclase heredan las siguientes subclases: Administrador: subclase que identifica al empleado que es administrador de la aplicación. Entrenador: subclase que identifica a los empleados que son entrenadores de los diferentes equipos de la Escuela de Fútbol de Mareo en Logroño. Jugador: representa a todos los jugadores pertenecientes a la Escuela de Fútbol de Mareo en Logroño. Equipo: representa a todos los equipos que forman la Escuela de Fútbol de Mareo en Logroño. Padre: contiene los datos de los padres que tienen a uno o varios hijos jugando en algún equipo de la Escuela de Fútbol de Mareo en Logroño. Partido: contiene los datos de los partidos jugados por los diferentes equipos de la Escuela de Fútbol de Mareo en Logroño. 60
64 Diseño Diseño arquitectónico Para el desarrollo de la aplicación voy a utilizar un diseño arquitectónico de tres capas (presentación, lógica de negocio y persistencia), en el que objetivo primordial es la separación de la lógica de negocio de la lógica de diseño. A continuación, se muestra la estructura de las capas: Figura 49: Arquitectura tres capas - Capa de presentación: es la que ve el usuario, es decir, presenta el sistema al usuario. En la aplicación, estaría compuesta por la interfaz de usuario que compone el sistema. Esta interfaz será la utilizada a través de Internet por los diferentes empleados de la Escuela de Fútbol de Mareo en Logroño. - Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Aquí es donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. En la aplicación, estaría compuesta por el código que permite gestionar y presentar toda la información que contiene la aplicación. - Capa de persistencia (datos): es donde residen los datos y es la encargada de acceder a los mismos. Reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. En la aplicación, está compuesta por el código que accede a la BD MySQL. 61
65 Diseño de la base de datos Entidad relación Para describir cuáles son las entidades y cuáles son los atributos que deberá contener cada entidad, he construido un diagrama Entidad Relación Extendido (EER) que me ayudará a entenderlo. Figura 50: Entidad relación 62
66 A continuación, se va a describir de una forma más amplia y detallada el contenido de estas entidades: - Empleado: entidad que contiene todos los datos necesarios para utilizar la aplicación. Contiene los datos personales de los empleados de la Escuela de Fútbol de Mareo en Logroño, así como nombre de usuario (nombre y primer apellido sin espacios) y contraseña para acceder a la aplicación. Además, incluye el dato rol, el cuál servirá a la aplicación para asignar los privilegios dependiendo de quién acceda a ella. La clave primaria de la entidad es DNI. - Administrador: entidad en la que se registran los datos de los empleados que son administradores. Los datos que contiene son la identificación del administrador y su DNI. La clave primaria de la entidad es el DNI. - Entrenador: entidad en la que se registran los datos de los empleados que son entrenadores. Los datos que contiene son la identificación del entrenador, el DNI y el cargo que representa en el equipo que entrena. La clave primaria de la entidad es el DNI. - Jugador: entidad que contiene todos los datos de los jugadores que pertenecen a la Escuela de Fútbol de Mareo en Logroño. Contiene un identificador único para cada jugador, todos los datos personales, la posición que ocupa en el campo y la pierna hábil. La clave primaria de la entidad es el identificador del jugador. - Equipo: entidad que contiene todos los equipos que componen la Escuela de Fútbol de Mareo en Logroño. El único campo y clave primaria de la entidad es categoría. - Partido: entidad que contiene todos los datos necesarios para almacenar los partidos jugados por los equipos de la Escuela de Fútbol de Mareo en Logroño. Los datos que contiene son el rival del partido, el campo en el que se juega, si juega de local o visitante, la fecha en la que se juega, la jornada a la que pertenece el partido y las características generales del partido, cómo son los goles de uno y otro equipo y las tarjetas. La clave primaria de la entidad es el identificador partido. - Padre: entidad que contiene los datos de los padres de los jugadores de la Escuela de Fútbol de Mareo en Logroño. Contiene el DNI, nombre, apellidos, y teléfono móvil del padre. La clave primaria de la entidad es el DNI. 63
67 Modelo conceptual Una vez detalladas las entidades necesarias para esta iteración, se va a proceder a realizar la transformación al modelo conceptual. Figura 51: Modelo conceptual 64
68 Diagrama de base de datos A partir del diagrama de entidad-relación y el conceptual se ha definido la estructura de las tablas de la base de datos. Figura 52: Diagrama de base de datos 65
69 Normalización Primera Formal Normal (1FN) Se puede decir que la base de datos está en 1FN porque todos sus atributos son monovaluados, es decir, sus valores son atómicos. Segunda Forma Normal (2FN) La base de datos que he creado se encuentra en 2FN porque puedo determinar que está en 1FN y además cualquier atributo que no figura en la clave candidata depende de toda la clave candidata en vez de solo una parte de ella. Tercera Forma Normal (3FN) Tras haber realizado un análisis de la base de datos puedo determinar que la base de datos se encuentra en 3FN, ya que todas las tablas se encuentran en 2FN y ningún atributo noprimario de la tabla es dependiente transitivamente de una clave candidata. Un atributo noprimario es un atributo que no pertenece a ninguna clave candidata. Una dependencia transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X Z por virtud de X Y e Y Z. Forma Normal de Boyce-Codd (FNBC) Llegados a este punto puedo decir que la base de datos también se encuentra en FNBC, porque en cada relación X Y, X es superclave. Por lo tanto, puedo concluir que la base de datos se encuentra normalizada hasta la Forma Normal de Boyce-Codd. 66
70 Clases de diseño En este apartado se va a detallar el diagrama de clases mostrado en el apartado de clases de análisis. A continuación, se muestran las clases de diseño junto a todos sus atributos y su constructor. Para facilitar la legibilidad solo se han incluido varias operaciones y no se han añadido los métodos Get y Set de las clases. Figura 53: Clases de diseño Clases de negocio La clase Empleado representa a todos los empleados que forman la Escuela de Fútbol de Mareo en Logroño. Por ello, contendrá todos los empleados que podrán acceder a la aplicación de gestión de estadísticas. El campo Rol servirá a la aplicación para asignar los privilegios que tiene cada empleado. De dicha clase heredan las subclases Administrador y Entrenador. Esta última posee una relación con la clase Equipo, con la cuál puedo conocer los entrenadores que dirigen a un equipo. A su vez, la clase Equipo está relacionada tanto con la clase Jugador como con la clase Partido, lo que me permite conocer los jugadores que pertenecen a un Equipo y los partidos que juega un Equipo. Por otro lado, en la clase EsJugadoPor existen dos relaciones, una con la clase Partido y otra con la clase Jugador, por lo que puedo conocer los Jugadores que han jugado el Partido, y así añadir las diferentes estadísticas de cada jugador en cada partido en EsJugadoPor. Por último, en la clase Jugador también existe otra relación con Padre, para conocer el tutor o padre que tiene el Jugador. 67
71 Especificación de pruebas unitarias En este apartado se va a especificar las pruebas mínimas a realizar una vez acabada la construcción del ciclo gestión de estadísticas. A continuación, se identifican las clases de equivalencia y después se originarán los casos de prueba correspondientes. Para que la memoria no sea demasiada extensa, solamente se van a mostrar varias pruebas. Clases de equivalencia Se separarán una por una las pantallas de la aplicación Web con el fin de facilitar su identificación. Cada clase de equivalencia se identificará con un número de identificación. Prefijo de la página que pertenezca, un guion y el número de clase de equivalencia. Acceso empleados (AE) Esta clase de equivalencia corresponde con la página de acceso de los empleados a la aplicación gestión de estadísticas. Condición de entrada Empleado Existe Contraseña Existe Clases válidas El nombre usuario existe en la BD La contraseña existe en la BD AE-1 AE-3 Rol Administrador Rol= Administrador AE-5 No administrador Rol= Entrenador Rol= Otro Empleado AE-6 Clases no válidas El nombre de usuario no existe en la BD La contraseña no existe en la BD AE-2 AE-4 Cambiar contraseña Empleado (CCE) Esta clase de equivalencia corresponde con la página cambiar la contraseña de acceso a la aplicación gestión de estadísticas (Rol no Administrador). Condición de Clases válidas entrada Contraseña 1 y Contraseña 2 Iguales Contraseña1 = Contraseña2 Contraseña 1 Nº Caracteres >= 8 caracteres <= 15 caracteres Formato La contraseña contiene números y letras Clases no válidas CCE-1 Contraseña1!= Contraseña 2 CCE-3 CCE-5 < 8 caracteres > 15 caracteres La contraseña no contiene números y letras CCE-2 CCE-4 CCE-6 68
72 Identificación casos de prueba En este apartado se crearán los casos de prueba una vez obtenidas las clases de equivalencia. Para que la memoria no sea demasiada extensa, solamente se van a mostrar los casos de prueba resueltos para las clases de equivalencia obtenidas en el apartado anterior. Acceso empleados (AE): Prueba Unitaria 1 Casos válidos Descripción Entradas Clases cubiertas Salida Esperada Acceso correcto de un Empleado con rol Administrador Nombre usuario: administrador Contraseña: proyecto2012 AE-1, AE-3, AE-5 Conectado correctamente: Rol Administrador Prueba Unitaria 2 Casos válidos Descripción Entradas Clases cubiertas Salida Esperada Acceso correcto de un Empleado con rol Entrenador Nombre usuario: abelsierra Contraseña: 6934bohece AE-1, AE-3, AE-6 Conectado correctamente: Rol Entrenador u Otro Empleado Prueba Unitaria 3 Casos no válidos Descripción Entradas Clases cubiertas Salida Esperada Acceso incorrecto de un Empleado. La contraseña no existe en la BD. Nombre usuario: abelsierra Contraseña: contrasena AE-2, AE-4 Nombre usuario o contraseña incorrectos Prueba Unitaria 4 Casos no válidos Descripción Acceso incorrecto de un Empleado. El nombre usuario y la contraseña no existen en la BD. Entradas Nombre usuario: Contraseña: Clases cubiertas AE-2, AE-4 Salida Esperada Nombre usuario o contraseña incorrectos 69
73 Cambiar Contraseña Empleado (CCE): Prueba Unitaria 5 Casos válidos Descripción Entradas Clases cubiertas Salida Esperada Modificación de la contraseña correcta de un Empleado Contraseña1: 97t242p7 Contraseña2: 97t242p7 CCE-1, CCE-3, CCE-5 La contraseña se ha modificado Prueba Unitaria 6 Casos no válidos Descripción Entradas Clases cubiertas Salida Esperada Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no son iguales. Contraseña1: aaaaaa77 Contraseña2: aaaaaa78 CCE-2 Las Contraseñas son diferentes. No se ha modificado la Contraseña Prueba Unitaria 7 Casos no válidos Descripción Entradas Clases cubiertas Salida Esperada Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no contienen números y letras. Contraseña1: aaaaaaaa Contraseña2: aaaaaaaa CCE-1, CCE-3, CCE-6 Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado Prueba Unitaria 8 Casos no válidos Descripción Entradas Clases cubiertas Salida Esperada Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no tienen el número mínimo de caracteres (8). Contraseña1: aa Contraseña2: aa CCE-1, CCE-4 Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado 70
74 Construcción Tecnología utilizada No voy a entrar en detalles de la tecnología utilizada, ya que esa descripción ya se ha realizado en el DOP (Documento de objetivos del proyecto). La implementación de la aplicación gestión de estadísticas se ha realizado utilizando la tecnología PHP. Para llevar a cabo el proyecto se han utilizado la herramienta Netbeans IDE PHP, Dreamweaver y el servidor apache XAMPP. Además para la creación de la BD MySQL se ha utilizado la herramienta PHPMyAdmin. Por último, he utilizado el conjunto de bibliotecas de base de datos para PHP ADOdb. Esto me permite tener la gran ventaja de poder cambiar de base de datos sin necesidad de rescribir cada llamada a la base de datos realizada por la aplicación. Código relevante En este apartado se va a mostrar las partes del código que he considerado más relevantes. Encriptar contraseña Para proteger la seguridad en el acceso de los empleados a la aplicación, utilizo el algoritmo de reducción criptográfico de 128 bits Md5. Para ello, siempre que se inserte o se modifique un empleado de la Escuela de Fútbol de Mareo en Logroño, o un empleado modifique la contraseña de acceso a la aplicación, se almacenará la contraseña encriptada en la base de datos. Esta contraseña será transformada a una cadena en hexadecimal (campo varchar de 32 caracteres en la base de datos). Un ejemplo de la utilización del algoritmo MD5 en la aplicación es en la función modificarcontraseña. Con esta función se modifica la contraseña de un Empleado, por lo que para guardarla encriptada en md5, se usa la función md5() de PHP. //Función que modifica la contraseña de un empleado function modificarcontrasena($nombreusuario,$contrasena) { $BD = new basedatos(); $BD-> conectar(); $BD->comenzarTransaccion(); $consulta = "UPDATE empleado SET contrasena=md5('".$contrasena."') WHERE nombre_usuario='".$nombreusuario."'"; $resultado=$bd->getconexion()->execute($consulta); } $BD->CompletarTransaccion(); $BD->desconectar(); 71
75 Envío y recepción de datos del formulario Para evitar posibles ataques a la seguridad de los formularios HTML, todos los datos serán enviados por el método Post. Este método envía ocultos todos los datos. A continuación, se muestra una parte del código de la aplicación de un formulario. En la propiedad method de la etiqueta <form> será dónde definiré como envía el formulario los datos, en este caso, como he comentado anteriormente: post. <form action="visualizarempleado1.php" method="post"> <table width="500px" cellspacing=?"0" cellpadding=?"0" border=?"0" align="center">? <tr> <th class="separador" colspan="4" bgcolor="#e1b600">visualizar Empleado</th> </tr> </tr> <tr> <td class="celdalabel"> <label for="nombre_usuario">nombre usuario:</label> </td> <td><select name="nombre_usuario"><?php $empleado = new empleado(); $empleado->sacamenudesplegablenombreusuario();?> </select> </td> </tr> <tr> <td colspan="2" class="boton"><input class="botonformulario" type="submit" value="buscar"></td> </tr> </table> </form> Para la recepción del dato del Formulario, accedo a la variable en PHP de la siguiente forma: $_POST[ nombre_usuario ]; (Siendo nombre_usuario el nombre del campo del formulario). Evitar inyección SQL La inyección SQL es un método de infiltración de código malicioso que se vale de una vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar consultas a una base de datos. Para evitar este problema de seguridad, valido todas las variables de entrada con la función de PHP mysql_real_escape_string(). Esta función me devuelve una cadena con los caracteres especiales escapados, es decir, cada vez que se encuentra un carácter especial para MySQL en la cadena del valor de la variable, le antepone una barra invertida con el fin de anular el efecto del mismo. Un ejemplo de la utilización de la función de PHP mysql_real_escape_string() en la aplicación es: a la variable $nombreusuario se le asigna el valor que devuelve mysql_real_escape_string() del dato recogido por el método de envío post. Más adelante, explicaré la función de PHP utf8_decode. //Almaceno en variables los datos recogidos en el formulario, evito inyección, y decodifico ñ y acentos $nombre_usuario = mysql_real_escape_string(utf8_decode($_post['nombre_usuario'])); 72
76 Sesiones Una sesión se define como el tiempo que un usuario permanece conectado a un sitio Web. De forma más técnica y relacionada con programación del lado del servidor, una sesión es un bloque de información que almacena todo tipo de variables y valores relacionados con los usuarios y sus visitas a un sitio Web en particular. El control de la sesión consiste en poder realizar un seguimiento del usuario mientras se mantenga navegando por el sitio Web, permitiendo mostrar contenido de las páginas en función de su nivel de autorización. A continuación, voy a explicar brevemente como he implementado las sesiones en la aplicación gestión de estadísticas. Para iniciar una sesión utilizo la función session_start(), con la cual creo un identificador de sesión nuevo, o retomo un id de sesión creado previamente, y para destruirla utilizo la función session_destroy(). En primer lugar, la página login.php se encarga de validar los datos enviados desde el formulario de acceso (nombre usuario y contraseña). Si son correctos, creo las variables de sesión: el nombre de usuario que inicia sesión, si está autentificado y la fecha y hora del último acceso. Si no son correctos, se redirige al usuario hacia la página index2.php, donde se mostrará el error, junto al formulario de acceso, de que no existen el nombre de usuario y la contraseña introducidos. El código es el siguiente: <?php include_once("../negocio/sesion/funcionessesion.php"); include_once("../negocio/empleado.php"); session_start(); //creo nombres de variables para los campos recogidos en el formulario $nombre_usuario = mysql_real_escape_string(utf8_decode($_post['nombre_usuario'])); $contrasena = mysql_real_escape_string(utf8_decode($_post['contrasena'])); if(comprobarlogin($nombre_usuario, $contrasena)==true)//si los datos están en la BD { $_SESSION['usuario'] = $nombre_usuario; //Variable que almacena el nombre del usuario que se conecta $_SESSION['autentificado']="si"; //Variable que almacena que está autentificado $_SESSION["ultimoAcceso"]= date("y-n-j H:i:s");//Variable que almacena fecha y hora de la última sesión if (isset($_session['usuario'])) { $empleado_validado = new empleado(); $rol = $empleado_validado->validarempleado($nombre_usuario, $contrasena); if ($rol == 'administrador') { //header('location: index_administrador.php'); header('location:../administrador/indexadministrador.php'); } else { header('location:../entrenador/indexentrenador.php'); //$sesion->comprobar_usuario_validado(); } } else 73
77 { header('location:../index2.php'); } } else //Si los datos no están en la BD { header('location:../index2.php'); }?> Todas las páginas Web que van a utilizar sesiones, hay que inicializarlas llamando a la función anteriormente comentada session_start(). Por ello, he creado una página llamada seguridad.php que voy a insertar al inicio de todas las páginas Web de la Aplicación gestión de estadísticas que requieren protección mediante sesiones. El código es el siguiente: <?php session_start(); if($_session['autentificado']=="si") //Si el usuario está autentificado { //Calculamos el tiempo transcurrido $fechaguardada = $_SESSION["ultimoAcceso"]; $ahora = date("y-n-j H:i:s"); //strtotime: convierte una fecha de formato Unix (número de segundos desde el 1 de Enero del 1970) $tiempo_transcurrido = (strtotime($ahora)- strtotime($fechaguardada)); if($tiempo_transcurrido >= 600){ //si han pasado 10 o más minutos session_destroy(); // destruyo la sesión header("location:../../index.php"); //envio al usuario a la página de autentificación //sino, actualizo la fecha de la sesión } else { $_SESSION["ultimoAcceso"] = $ahora; } } else { //si el usuario no está autentificado header("location:../../index.php"); }?> Este código comprueba si se está o no autentificado. Si lo está, actualiza la fecha y hora de la última sesión, en caso contrario se redirige a la página inicial de acceso a la aplicación. También, por motivo de seguridad, si la sesión está inactiva durante un periodo mayor o igual de 10 minutos, será destruida, con el consiguiente cierre de sesión. Por último, la sesión puede ser destruida por el propio empleado o administrador pulsando sobre Cerrar Sesión en la Web. El código que se ejecuta es el siguiente: <?php //Cerrar sesión session_start(); 74
78 unset($_session['usuario']); //destruye la variable de sesión usuario session_destroy(); //destruye sesión header('location:../index.php'); //redirecciona a index.php (Acceso aplicación)?> Capa de persistencia Para añadir, visualizar, modificar y eliminar los datos almacenados en la base de datos he diseñado y creado en la capa de persistencia una clase llamada basedatos que contiene todos los métodos necesarios para conectar, desconectar y manejar transacciones. Como he comentado anteriormente, he utilizado el conjunto de bibliotecas de base de datos para PHP ADOdb. Esto me permite que si un día migro, por poner un ejemplo, de Mysql a Oracle, bastará con cambiar el driver. Para poder utilizar ADOdb, me he descargado las bibliotecas y he incluido la carpeta ADOdb en el directorio de la aplicación. A continuación, explicaré el código de la clase basedatos : En primer lugar se debe incluir dos archivos de la carpeta ADOdb5: adodberrorhandler.inc.php y adodb.inc.php. Este último archivo contiene todas las funciones usadas por todas las clases de bases de datos. error_reporting(e_all); // pasa cualquier mensaje de error al manejador de errores //para poder utilizar adodb, incluimos lo siguiente (Carpeta adodb5 de nuestro proyecto): include('c:\xampp\htdocs\zonaentrenadores\adodb5\adodberrorhandler.inc.php'); include('c:\xampp\htdocs\zonaentrenadores\adodb5\adodb.inc.php'); class basedatos { private $servidor='localhost' ; //servidor donde se encuentra la BD private $usuario='root';//nombre del usuario que puede acceder a la BD private $contrasena='admin';//contraseña poder acceder a la BD private $nombrebd='efmareologrono'; //nombre de la BD private $driver='mysqlt';//tipo de servidor: mysqlt para transacciones private $conexion;//variable para la conexión //Obtener conexión public function getconexion() { return $this->conexion; } Para conectar con la base de datos tengo que crear un objeto de conexión usando la función ADONewConnection($driver). El driver que utilizo para que funcionen las transacciones sin ningún problema es mysqlt. Una vez creado el objeto conexión, llamo a la función Connect ($servidor, $usuario, $contraseña, $nombrebd) para abrir la conexión. //Conectar a la BD efmareologrono public function conectar(){ $this->conexion = ADONewConnection($this->driver); $this->conexion->connect($this->servidor,$this- >usuario,$this->contrasena,$this->nombrebd); } 75
79 Para desconectar una conexión establecida utilizo la siguiente función: //Desconectar de la BD efmareologrono public function desconectar() { $this->conexion->close(); } El último aspecto a tratar son las transacciones. Adodb5 permite tratar de una forma muy sencilla las denominadas transacciones inteligentes. Para comenzar las transacciones utilizo la función llamada comenzartransaccion(), que indica que se empieza una transacción invocando StartTrans(). Y para completar la transacción utilizo la función CompletarTransaccion(), la cuál invoca a CompleteTrans(). La gran ventaja es que detecta cuando ocurre un error SQL, y procesa, según sea necesario, Rollback o Commit. //Comenzar transacción public function comenzartransaccion() { $this->conexion->starttrans(); } //Confirmar o cancela transacción: Commit o Rollback public function CompletarTransaccion() { $this->conexion->completetrans(); } }?> Capa lógica de negocio La capa de lógica de negocio está compuesta por las clases: empleado, administrador, entrenador, equipo, partido, padre, jugador, y esjugadopor. No voy a entrar en detalles sobre todos los atributos y operaciones que tienen cada clase, pero sí voy a mostrar y explicar varios métodos. En primer lugar, he elegido el método visualizarempleados() que devuelve un array llamado Empleados con todos los datos de los Empleados de la Escuela de Fútbol de Mareo en Logroño. public function visualizarempleados() { $BD = new basedatos(); $BD->conectar(); $consulta="select * FROM empleado "; $empleados=array(); //Ejecutar consulta $resultado=$bd->getconexion()->execute($consulta); filas //Contamos el numero total de resultados, es decir, numero de $numero_filas = $resultado->recordcount(); for($i=0;$i<$numero_filas;$i++){ 76
80 $empleado=new Empleado(); //Array con el resultado de una fila y mueve el apuntador de datos interno hacia adelante. $fila= $resultado->fetchrow(); //Creo empleado con los datos de la primera fila $empleado->set_dni($fila[0]); $empleado->set_nombreusuario($fila[1]); $empleado->set_contrasena($fila[2]); $empleado->set_rol($fila[3]); $empleado->set_nombre($fila[4]); $empleado->set_apellido1($fila[5]); $empleado->set_apellido2($fila[6]); $empleado->set_telefono($fila[7]); $empleado->set_ ($fila[8]); $empleado->set_direccion($fila[9]); $empleado->set_localidad($fila[10]); $empleado->set_cp($fila[11]); $empleado->set_puesto($fila[12]); $empleados[$i]=$empleado; //Añadir al array cada empleado } $BD->desconectar(); return $empleados; } La estructura a seguir en la mayoría de métodos que forman las clases en la capa de lógica de negocio es muy similar. A continuación, la explico: En primer lugar creo un objeto de tipo basedatos, que como anteriormente he comentado pertenece a la capa de persistencia, y lo conecto a la base de datos. $BD = new basedatos(); $BD->conectar(); Después declaro una variable con el valor de la consulta MySql que voy a realizar. En este caso, la consulta devolverá todos los empleados de la Escuela de Fútbol de Mareo en Logroño. $consulta="select * FROM empleado "; Se ejecuta y guardo el resultado en una variable con ese mismo nombre. //Ejecutar consulta $resultado=$bd->getconexion()->execute($consulta); Para conocer el número de resultados que devuelve la consulta realizada utilizo la función RecordCount(), y lo almaceno en la variable numero_filas. //Contamos el numero total de resultados, es decir, numero de filas $numero_filas = $resultado->recordcount(); Una vez que conozco el número de filas, se van añadiendo, hasta que el bucle llegue a la última fila, al array empleados todos los objetos empleado creados en cada fila. for($i=0;$i<$numero_filas;$i++){ $empleado=new Empleado(); //Array con el resultado de una fila y mueve el apuntador de datos interno hacia adelante. 77
81 $fila= $resultado->fetchrow(); //Creo empleado con los datos de la primera fila $empleado->set_dni($fila[0]); $empleado->set_nombreusuario($fila[1]); $empleado->set_contrasena($fila[2]); $empleado->set_rol($fila[3]); $empleado->set_nombre($fila[4]); $empleado->set_apellido1($fila[5]); $empleado->set_apellido2($fila[6]); $empleado->set_telefono($fila[7]); $empleado->set_ ($fila[8]); $empleado->set_direccion($fila[9]); $empleado->set_localidad($fila[10]); $empleado->set_cp($fila[11]); $empleado->set_puesto($fila[12]); empleado } $empleados[$i]=$empleado; //Añadir al array cada Se desconecta de la base de datos. $BD->desconectar(); Se devuelve el array empleados con el resultado de los empleados de la Escuela de Fútbol de Mareo en Logroño. return $empleados; Codificar y decodificar una cadena a UTF-8 Para que la aplicación Web gestión de estadísticas muestre correctamente los acentos y las letras propias de nuestro idioma como puede ser la letra ñ, al igual que otras letras con diéresis, utilizaré en toda la aplicación Web la codificación de caracteres UTF-8. Por este mismo motivo, en la base de datos efmareologrono he elegido el juego de caracteres latin1_spanish_ci para definir todas las tablas que la componen. Por ello, siempre que la aplicación Web quiera mostrar información de la base de datos, y añadir o modificar en ella, debo codificar o decodificar los datos para una correcta utilización de los caracteres. A continuación, detallo como lo he realizado: Decodificar una cadena UTF-8 Tengo que utilizar esta función de PHP utf8_decode cuando voy a añadir, modificar o eliminar algún dato desde la aplicación gestión de estadísticas. Con ello consigo que la aplicación y la base de datos no tengan errores con los caracteres o acentos introducidos. Un ejemplo de código en el que utilizo esta función es el siguiente: $nombre = mysql_real_escape_string(utf8_decode($_post['nombre'])); Para que la base de datos pueda tratar la variable nombre correctamente, decodifico el valor (nombre) que ha sido enviando por un formulario. 78
82 Codificar una cadena a UTF-8 En la aplicación gestión de estadísticas tengo que utilizar esta función de PHP utf8_encode siempre que quiera mostrar información proveniente de la base de datos efmareologrono. Con ello consigo la correcta visualización de todos los caracteres en la aplicación. Un ejemplo de código en el que utilizo esta función es el siguiente: utf8_encode($nuevoempleado->get_nombre()); Codifico el valor nombre de un empleado capturado de la base de datos para mostrarlo correctamente en la aplicación gestión de estadísticas. Añadir Empleado Para acabar, voy a mostrar a continuación toda la funcionalidad necesaria para modificar la información almacenada en la aplicación gestión de estadísticas. Este ciclo conlleva a la existencia de multitud de formularios con los que poder introducir y modificar todos los datos almacenados en la aplicación. Estos datos serán validados por las funciones que se incluyen en el fichero funcionesvalidar dentro de la carpeta validar de la aplicación zonaentrenadores (carpeta principal de la aplicación gestión de estadísticas), para no permitir la entrada de valores que no cumplan los formatos establecidos. Dentro de esta página se va a diferenciar entre dos tipos de código: el que está orientado al diseño y el que obtiene la funcionalidad (recibe las solicitudes y presenta los resultados). Esto último existe en todos los archivos que componen la capa de presentación, lo que permite poder comunicarse con la capa de lógica de negocio. Código orientado al diseño: aniadirempleado.php La página empieza incluyendo el archivo seguridad.php explicado anteriormente y el archivo cabecera.php, que contiene la versión de HTML que usa la página, el enlace de la hoja de estilos, el inicio del contenedor que compone toda la página y el contenedor con la imagen utilizada para la cabecera en todas las páginas. En las siguientes líneas se declaran dos contenedores (menuprincipal y menusecundario) que componen el menú y el submenú de la página. <?php include_once("../disenoweb/cabecera.php"); include_once("../../seguridad/seguridad.php");?> <div class="menuprincipal"> <ul> <li><a href="visualizarempleado.php">empleados</a></li> <li><a href="../administrador/visualizaradministrador.php">administradores</a ></li> <li><a href="../entrenador/visualizarentrenador.php">entrenadores</a></li> <li><a href="../equipo/visualizarequipo.php">equipos</a></li> <li><a href="../jugador/visualizarjugador.php">jugadores</a></li> <li><a href="../partido/visualizarpartido.php">partidos</a></li> <li><a href="../esjugadopor/visualizaresjugadopor.php">estadísticas</a></li> <li><a href="../padre/visualizarpadre.php">padres</a></li> </ul> </div> 79
83 <div class="menusecundario"> <ul> <li><a href="visualizarempleado.php">visualizar empleados</a></li> <li><a class="webactual">añadir empleado</a></li> <li><a href="modificarempleado.php">modificar empleado</a></li> <li><a href="eliminarempleado.php">eliminar empleado</a></li> </ul> </div> A continuación, creo el formulario con todos los datos necesarios para añadir el empleado y una serie de textbox donde puede escribir el usuario. Una vez que el usuario pulse el botón, en este caso Añadir, los datos serán enviados ocultos (method=post) a la página aniadirempleado1.php (valor actión del formulario, es decir, la acción que va a realizar el formulario una vez se pulse el botón). <div class="principal"> <form action="aniadirempleado1.php" method="post"> <table width="auto" cellspacing=?"0" cellpadding=?"0" border=?"0" align="center">? <tr> <th class="separador" colspan="4" bgcolor="#e1b600">añadir Empleado</th> </tr> <tr> <td class="celdalabel"> <label for="dni">dni:</label> </td> <td><input type="text" name="dni" maxlength="9" /></td> <td class="celdaasterisco">*</td> <td class="celdacampos">formato: A</td> </tr> <tr> <td class="celdalabel"> <label for="nombre_usuario">nombre usuario:</label> </td> <td><input type="text" name="nombre_usuario" maxlength="15" /></td> <td class="celdaasterisco">*</td> <td class="celdacampos">máximo 50 carácteres, compuesto por nombre y apellido</td> </tr> <tr> <td colspan="4" class="boton"><input class="botonformulario" type="submit" value="añadir"></td> </tr> </table> </form> </div> Para acabar con el código encargado del diseño de la página, se incluye el nombre de usuario que está en la sesión, un enlace para salir de ella y el archivo footer.php que contiene la información sobre los derechos de autor de la aplicación y el cierre del contenedor que compone toda la página. <div class="pie"> <table width="100%"> <tr> <td width="50%">conectado como: <?php echo $_SESSION['usuario']?></td> 80
84 <td width="50%" align="right"><a class="cerrarsesion" href="../../seguridad/cerrarsesion.php">cerrar Sesión></a> </td> </tr> </table> </div> <?php include_once("../disenoweb/footer.php");?> Código orientado a la funcionalidad, es decir, recibe las solicitudes y presenta los resultados: aniadirempleado1.php El código empieza incluyendo las clases necesarias: <?php include_once("../../negocio/empleado.php"); include_once("../../negocio/administrador.php"); include_once("../../negocio/entrenador.php"); include_once("../../negocio/validar/funcionesvalidar.php"); Después recojo las variables enviadas por el formulario (se recogen por el método post: $_POST) y compruebo si está o no alguna vacía. Si alguna está vacía se redirige a la página datosincorrectos.php en la que se muestra el error de que los datos introducidos no cumplen los formatos establecidos, y el formulario para rellenar otra vez. if (empty($_post['dni']) empty($_post['nombre_usuario']) empty($_post['contrasena']) empty($_post['rol']) empty($_post['nombre']) empty($_post['apellido_1']) empty($_post['apellido_2']) empty($_post['telefono']) empty($_post[' ']) empty($_post['direccion']) empty($_post['localidad']) empty($_post['cp']) empty($_post['puesto'])) { include_once("datosincorrectos.php"); } Si todas las variables contienen datos, los almaceno en variables, evito inyección y decodifico caracteres. else { //Almaceno en variables los datos recogidos en el formulario, evito inyeccion, y decodifico ñ y acentos $dni = mysql_real_escape_string(utf8_decode($_post['dni'])); $nombre_usuario = mysql_real_escape_string(utf8_decode($_post['nombre_usuario'])); $contrasena = mysql_real_escape_string(utf8_decode($_post['contrasena'])); $rol = mysql_real_escape_string(utf8_decode($_post['rol'])); $nombre = mysql_real_escape_string(utf8_decode($_post['nombre'])); $apellido_1 = mysql_real_escape_string(utf8_decode($_post['apellido_1'])); $apellido_2 = mysql_real_escape_string(utf8_decode($_post['apellido_2'])); $telefono = mysql_real_escape_string(utf8_decode($_post['telefono'])); $ = mysql_real_escape_string(utf8_decode($_post[' '])); $direccion = mysql_real_escape_string(utf8_decode($_post['direccion'])); 81
85 $localidad = mysql_real_escape_string(utf8_decode($_post['localidad'])); $cp = mysql_real_escape_string(utf8_decode($_post['cp'])); $puesto = mysql_real_escape_string(utf8_decode($_post['puesto'])); Antes de añadir el Empleado, valido los datos introducidos para comprobar que son correctos. Si son correctos, compruebo si existen o no el DNI introducido, el teléfono, el nombre de usuario o el . Si existe alguno de ellos, devuelvo error (deben ser únicos) y en caso contrario añado Empleado. En este caso, el Empleado añadido puede tener el rol de Administrador, Entrenador u Otro Empleado. Sea uno u otro, se realizar uno de estos tres casos: - Si Rol es igual a Administrador, se crea el objeto Administrador y se añade con los datos introducidos un nuevo Administrador. La aplicación mostrará que el Empleado se ha añadido correctamente. - Si Rol es igual a Entrenador, redirecciono a una nueva página para que se agreguen los datos necesarios para añadir un nuevo Entrenador. Una vez agregado el Entrenador, se mostrará que el Empleado se ha añadido correctamente. - Si Rol es igual a Otro empleado, la aplicación mostrará que el Empleado se ha añadido correctamente. $empleado->aniadirempleado($dni, $nombre_usuario,$contrasena, $rol, $nombre, $apellido_1, $apellido_2, $telefono, $ , $direccion, $localidad, $cp, $puesto); if($rol=='administrador') { //No hace falta validar el DNI, ya que ya estᠶalidado al aañadir el empleado $administrador = new administrador(); $id_administrador = NULL; $administrador->aniadiradministrador($dni, $id_administrador); include_once("aniadidocorrecto.php"); } elseif ($rol=='entrenador') { include_once('aniadirentrenador.php'); } else { include_once('aniadidocorrecto.php'); } 82
86 Interfaces definitivas En el apartado anterior, prototipos de interfaz, se mostraban los bocetos de como se iban a estructurar las Interfaces de la aplicación gestión de estadísticas. A continuación, muestro las Interfaces definitivas de la aplicación con algunas modificaciones respecto a la estructura del boceto. Dos aspectos que he añadido respecto a los bocetos son: un submenú para cada componente del menú principal e información sobre el nombre del Empleado que ha iniciado sesión en la aplicación gestión de estadísticas. Login: La figura 54 muestra la interfaz de acceso a la aplicación gestión de estadísticas. Figura 54: Interfaz login Si se introduce un nombre de usuario y contraseña incorrectos la aplicación mostrará la figura 55: 83
87 Figura 55: Interfaz login incorrecto Si por el contrario, accedo correctamente a la aplicación, se mostrará el index correspondiente a los privilegios que tiene el Empleado sobre la aplicación. Es decir, si el Empleado que accede tiene rol Administrador, se mostrará la interfaz de la figura 56 y en caso contrario la interfaz de la figura 57. Index Administrador: Figura 56: Interfaz index administrador 84
88 Index Empleado: Figura 57: Interfaz index empleado Resultados de las pruebas unitarias A continuación compruebo que los resultados de las pruebas unitarias diseñadas en el proceso anterior son los esperados. Solamente se muestran varias pruebas: Prueba Unitaria 1 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Acceso correcto de un Empleado con rol Administrador Nombre usuario: administrador Contraseña: proyecto2012 AE-1, AE-3, AE-5 Conectado correctamente: Rol Administrador. Conectado correctamente: Rol Administrador. SÍ. Prueba Unitaria 2 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Acceso correcto de un Empleado con rol Entrenador Nombre usuario: abelsierra Contraseña: 6934bohece AE-1, AE-3, AE-6 Conectado correctamente: Rol Entrenador. Conectado correctamente: Rol Entrenador. SÍ. 85
89 Prueba Unitaria 3 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Acceso incorrecto de un Empleado. La contraseña no existe en la BD. Nombre usuario: abelsierra Contraseña: contrasena AE-2, AE-4 Nombre usuario o contraseña incorrectos Nombre usuario o contraseña incorrectos SÍ. Prueba Unitaria 4 Descripción Acceso incorrecto de un Empleado. El nombre usuario y la contraseña no existen en la BD. Entradas Nombre usuario: Contraseña: Clases cubiertas AE-2, AE-4 Salida Esperada Nombre usuario o contraseña incorrectos Salida Obtenida Nombre usuario o contraseña incorrectos Prueba Correcta SÍ. Prueba Unitaria 5 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Modificación de la contraseña correcta de un Empleado Contraseña1: 97t242p7 Contraseña2: 97t242p7 CCE-1, CCE-3, CCE-5 La contraseña se ha modificado La contraseña se ha modificado SÍ. Prueba Unitaria 6 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no son iguales. Contraseña1: aaaaaa77 Contraseña2: aaaaaa78 CCE-2 Las Contraseñas son diferentes. No se ha modificado la Contraseña Las Contraseñas son diferentes. No se ha modificado la Contraseña SÍ. 86
90 Prueba Unitaria 7 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no contienen números y letras. Contraseña1: aaaaaaaa Contraseña2: aaaaaaaa CCE-1, CCE-3, CCE-6 Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado SÍ. Prueba Unitaria 8 Descripción Entradas Clases cubiertas Salida Esperada Salida Obtenida Prueba Correcta Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no tienen el número mínimo de caracteres (8). Contraseña1: aa Contraseña2: aa CCE-1, CCE-4 Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado SÍ. 87
91 Ciclo 3: Control de las faltas de asistencia a los entrenamientos Análisis Introducción En este tercer y último ciclo del sistema voy a incrementar a la aplicación gestión de estadísticas las funcionalidades necesarias para gestionar las faltas de asistencia al entrenamiento. Además, cuando un empleado o administrador añada una falta de entrenamiento, la aplicación enviará automáticamente al padre, madre o tutor/a del jugador un mensaje correo electrónico y un mensaje de texto a móvil avisando de la falta de asistencia al entrenamiento del jugador. Casos de Uso Gestionar control de faltas de asistencia a los entrenamientos En este apartado voy a refinar en primer lugar el caso de uso Gestionar falta entrenamiento : Figura 58: Diagrama de casos de uso para la gestión de una falta de entrenamiento. Caso de uso 60: Visualizar falta entrenamiento - Definición: esta operación permitirá al empleado o al administrador visualizar las faltas de asistencia a un entrenamiento de un jugador. - Precondición: el empleado o el administrador desea visualizar las faltas de asistencia a un entrenamiento de un jugador. - Postcondición: se muestran las faltas de asistencia a un entrenamiento de un jugador. Caso de uso 61: Añadir falta entrenamiento - Definición: esta operación permitirá al empleado o al administrador añadir la falta de asistencia a un entrenamiento de un jugador. 88
92 - Precondición: el empleado o el administrador desea añadir la falta de asistencia a un entrenamiento de un jugador. - Postcondición: se añaden la falta de asistencia a un entrenamiento de un jugador. Caso de uso 62: Modificar falta entrenamiento - Definición: esta operación permitirá al empleado o al administrador modificar la falta de asistencia a un entrenamiento de un jugador. - Precondición: el empleado o el administrador desea modificar la falta de asistencia a un entrenamiento de un jugador. - Postcondición: se modifica la falta de asistencia a un entrenamiento de un jugador. Caso de uso 63: Eliminar falta entrenamiento - Definición: esta operación permitirá al empleado o al administrador eliminar la falta de asistencia a un entrenamiento de un jugador. - Precondición: el empleado o el administrador desea eliminar la falta de asistencia a un entrenamiento de un jugador. - Postcondición: se elimina la falta de asistencia a un entrenamiento de un jugador. Además, voy a detallar los casos de uso: Control faltas de asistencia al entrenamiento y Recibir faltas asistencia generados en el diagrama de la visión general. Los diagramas de casos de uso que definen los requisitos que debe cumplir esta función son los siguientes: La figura 59 muestra el diagrama de casos de uso del empleado y del administrador para el control de faltas de asistencia al entrenamiento. Figura 59: Diagrama de casos de uso para añadir una falta de asistencia a un entrenamiento. Caso de uso 64: Añadir falta entrenamiento - Definición: esta operación permitirá al empleado o al administrador añadir una falta de entrenamiento de un jugador. 89
93 - Precondición: el empleado o el administrador desea añadir una falta de entrenamiento. - Postcondición: se añade la falta de entrenamiento. Caso de uso 65: Enviar - Definición: esta operación enviará un al Padre notificando una falta de entrenamiento del jugador. - Precondición: la aplicación desea enviar un mail al padre con una falta de entrenamiento del jugador. - Postcondición: se envía el al padre con una falta de entrenamiento del jugador. Caso de uso 66: Enviar SMS - Definición: esta operación enviará un SMS al padre notificando una falta de entrenamiento del jugador. - Precondición: la aplicación desea enviar un SMS al padre con una falta de entrenamiento del jugador. - Postcondición: se envía el SMS al padre con una falta de entrenamiento del jugador. La figura 60 muestra el diagrama de casos de uso del padre para recibir falta de asistencia al entrenamiento de un jugador. Figura 60: Diagrama de casos de uso para recibir falta de asistencia a un entrenamiento. Caso de uso 67: Recibir - Definición: esta operación permitirá al padre recibir un notificando una falta de entrenamiento del jugador. - Precondición: el padre desea recibir un mail con una falta de entrenamiento del jugador. - Postcondición: el Padre recibe la falta de entrenamiento del jugador mediante . Caso de uso 68: Recibir SMS - Definición: esta operación permitirá al padre recibir un SMS notificando una falta de entrenamiento del jugador. 90
94 - Precondición: el padre desea recibir un SMS con una falta de entrenamiento del jugador. - Postcondición: el padre recibe la falta de entrenamiento del jugador mediante SMS. Requisitos funcionales RF.1: gestión de una falta de entrenamiento Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de Fútbol de Mareo en Logroño. Cada empleado y cada administrador tendrá control para visualizar, añadir, eliminar y modificar las faltas de entrenamientos almacenadas en la base de datos para mantenerla actualizada. Casos de uso: el requisito se deriva de los casos de uso 60.-Visualizar falta de entrenamiento, 61.-Añadir falta de entrenamiento, 62.- Modificar falta de entrenamiento y 63.- Eliminar falta de entrenamiento. RF.2: añadir una falta de entrenamiento Cualquier empleado o administrador podrá añadir la falta de asistencia a un entrenamiento de un jugador mediante la aplicación Web. Casos de uso: el requisito se deriva de los casos de uso 64.-Añadir falta de entrenamiento RF.3: enviar falta de entrenamiento por Al añadir el empleado o el administrador una falta de asistencia a un entrenamiento de un jugador, se notificará por al padre, madre o tutor del jugador que previamente ha sido almacenado en la aplicación junto al jugador. Casos de uso: el requisito se deriva de los casos de uso 65.-Enviar RF.4: enviar falta de entrenamiento por SMS Al añadir el empleado o el administrador una falta de asistencia a un entrenamiento de un jugador, se notificará por SMS al padre, madre o tutor del jugador que previamente ha sido almacenado en la aplicación junto al jugador. Casos de uso: el requisito se deriva de los casos de uso 66.-Enviar SMS RF.5: recibir falta de entrenamiento por Una vez añadida la falta de entrenamiento por el administrador o el empleado, el padre del jugador recibirá la notificación por sobre dicha falta. Casos de uso: el requisito se deriva de los casos de uso 67.-Recibir RF.6: recibir falta de entrenamiento por SMS Una vez añadida la falta de entrenamiento por el administrador o el empleado, el padre del jugador recibirá la notificación por SMS sobre dicha falta. Casos de uso: el requisito se deriva de los casos de uso 68-Recibir SMS 91
95 Clases de análisis El diagrama de clases UML de este tercer ciclo es una ampliación del segundo. Como se puede observar, me veo en la necesidad de añadir las clases entrenamiento, y SMS. Figura 61: UML. Clases de análisis ampliado. Clases Entrenamiento: contiene los datos necesarios para conocer las faltas al entrenamiento de los jugadores. representa la clase que permite a la aplicación enviar un al padre de un jugador con la falta de asistencia al entrenamiento. SMS: representa la clase que permite a la aplicación enviar un SMS al padre de un jugador con la falta de asistencia al entrenamiento. 92
96 Diseño Diseño de la base de datos Entidad relación ampliado En este ciclo me veo en la necesidad de añadir una nueva tabla a la base de datos. A continuación, muestro el diagrama de Entidad Relación creado en el segundo ciclo, con una nueva entidad llamada Entrenamiento, que contendrá todos los datos necesarios para almacenar todas las faltas al entrenamiento de los jugadores de la Escuela de Fútbol de Mareo en Logroño. Figura 62: Entidad relación ampliado 93
97 La entidad Entrenamiento contiene el identificador de la falta, la fecha, el estado de si está o no justificada y el motivo. La clave primaria de la entidad es el identificador de falta. Una vez añadida esta entidad, no hace falta insertar nada más porque ya se dispone en la entidad padre del número de teléfono como del correo electrónico al que van a ser enviados el SMS y el . Cabe destacar que la aplicación no almacena los SMS y s mandados al padre del jugador respecto a la falta de asistencia al entrenamiento de su hijo. Si bien es cierto, que los SMS son almacenados por la herramienta utilizada para enviar SMS (intellisms). Modelo conceptual ampliado Una vez detallada la nueva entidad que va a tener la base de datos, procedo a realizar la transformación al modelo conceptual. Figura 63: Modelo conceptual ampliado 94
98 Diagrama de base de datos ampliado A partir del diagrama de entidad-relación y el conceptual se ha definido la estructura final de las tablas de la base de datos. Figura 64: Diagrama de base de datos ampliado 95
99 Clases de diseño En este apartado voy a detallar el diagrama de clases mostrado en el apartado de clases de análisis. A continuación, muestro las clases de diseño, junto a todos sus atributos y su constructor. Para facilitar la legibilidad solo se han incluido varias operaciones y no se han añadido los métodos Get y Set de las clases. Figura 65: Clases de diseño ampliado 96
100 Clases de negocio añadidas La clase Entrenamiento contiene todos los datos necesarios para almacenar todas las faltas al entrenamiento de los jugadores de la Escuela de Fútbol de Mareo en Logroño. Por ello, está relacionada con la clase Jugador, lo que permite conocer las faltas de entrenamiento que tiene cada jugador. Además, las clases y SMS están relacionadas tanto con la clase Entrenamiento como con la clase Padre, lo que permite conocer la información necesaria al enviar un o un SMS. Especificación de pruebas unitarias En este apartado se va a especificar las pruebas mínimas a realizar una vez acabada la construcción del ciclo control de faltas de asistencia a los entrenamientos. Como he realizado en el segundo ciclo, primero identificaré las clases de equivalencia y después se originarán los casos de prueba correspondientes. Para no extenderme en demasía, solo se muestra una prueba. Clases de equivalencia Se separarán una por una las pantallas de la aplicación Web con el fin de facilitar su identificación. Cada clase de equivalencia se identificará con un número de identificación. Prefijo de la página que pertenezca, un guion y el número de clase de equivalencia. Añadir Falta Entrenamiento (AFE) Esta clase de equivalencia corresponde con la página de añadir una falta de entrenamiento. Condición de Clases válidas Clases no válidas entrada Fecha Formato La fecha es correcta AFE-1 La fecha no es correcta AFE-2 Jugador Existe El jugador existe en la BD AFE-3 El jugador no existe en la AFE-4 BD Fecha - Jugador Existe Falta La falta no existe Enviar Enviar SMS AFE-5 La falta ya existe AFE-6 97
101 Identificación casos de prueba En este apartado se crearán los casos de prueba una vez obtenidas las clases de equivalencia. Añadir Falta Entrenamiento (AFE) Prueba Unitaria 1 Casos válidos Descripción Falta entrenamiento añadida correctamente Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-1, AFE-3, AFE-5 Salida Esperada Falta entrenamiento añadida correctamente. Se ha enviado y SMS notificando la falta al padre del jugador. Prueba Unitaria 2 Casos no válidos Descripción Falta de entrenamiento no añadida. Ya existe la falta de entrenamiento. Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-1, AFE-3, AFE-6 Salida Esperada La falta de entrenamiento ya existe. Falta de entrenamiento no añadida. Prueba Unitaria 3 Casos no válidos Descripción Error formato fecha Entradas Fecha falta entrenamiento: Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-2 Salida Esperada La fecha introducida no cumple el formato establecido. 98
102 Prueba Unitaria 4 Casos no válidos Descripción Error no existe jugador Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-4 Salida Esperada El jugador introducido no existe. Añada primero el jugador. 99
103 Construcción Tecnología utilizada Para la implementación de este tercer ciclo he utilizado: - PHPMailer: clase PHP para enviar s basada en el componente active server ASPMail. Con PHPMailer puedo enviar s vía sendmail, PHP mail(), o con SMTP (Protocolo Simple de Transferencia de Correo). En mi caso he utilizado el envío SMTP por varias razones: o Permite enviar los s en un tiempo menor. o Permite enviar s en formato HTML y con archivos adjuntos. Actualmente en la aplicación no será necesario, pero sí en una posible actualización de la aplicación en el futuro. o Permite enviar s con múltiples destinatarios. o Y por último, y por lo que principalmente he escogido esta alternativa, permite utilizar un servidor SMTP con autentificación. Gracias a esto, puedo enviar correos, en mi caso desde una cuenta Gmail, y evitar la instalación de un servidor de correo. - IntelliSMS: es un kit de desarrollo de software (SDK) que permite enviar mensajes SMS desde un script PHP. Descargar, usar y distribuir esta librería PHP es gratuita. Por el contrario, el envío de cada SMS es de pago. Código relevante Todo el código necesario para enviar un o un SMS va incluido dentro de la clase y la clase sms. Enviar Anteriormente, he citado que la clase PHPMailer ofrece la posibilidad de enviar s de una forma sencilla a través del servidor SMTP. Para su utilización, he descargado dicha clase y he incluido la carpeta PHPmailer en el directorio de la aplicación (dentro de la carpeta Negocio ). A continuación, explico el código de la clase En primer lugar, debo instanciar dos archivos de la carpeta PHPMailer : class.phpmailer.php y class.smtp.php. Este último archivo lo añado para poder utilizar el servidor SMTP. Además, inicializo las variables con los datos necesarios para poder mandar un desde mi dirección. En mi caso, el servicio de correo electrónico que voy a utilizar es Gmail. <?php //Incluimos estas dos clases de PHPMailer para poder enviar include_once('phpmailer/class.phpmailer.php'); include_once('phpmailer/class.smtp.php'); //Para envío por SMTP class { 100
104 private $ remitente = "efmareologrono@gmail.com";// desde donde se envía el correo. private $nombreremitente = "EF Mareo Logroño>; //Nombre con el que se va a mostrar el emisor private $contrasena = "proyecto2012"; //Contraseña private $autentificacion = true; //Indica si el servidor necesita autentificación private $seguridad = "ssl"; //certificado de seguridad necesario private $host = "smtp.gmail.com"; //servidor SMTP private $puerto = 465; //puerto SMPT de Gmail private $caracteres = 'UTF-8'; //Codificación de caracteres para mostrar correctamente los acentos y las ñ Para enviar un utilizo la función enviar public function enviar ($destinatario,$asunto,$cuerpo) { $ = new PHPMailer(); En primer lugar, creo una variable $ de tipo PHPMailer que servirá para almacenar toda la información referente al - El servidor de correo utilizado es SMTP. $ ->issmtp(); - La codificación de los caracteres para su correcta visualización en el (UTF-8): $ ->charset = $this->caracteres; - Si el servidor necesita o no autentificación (True): $ ->smtpauth = $this->autentificacion; - La seguridad del servidor. En este caso el certificado de seguridad SSL utilizado por Gmail: $ ->smtpsecure = $this->seguridad; - El servidor SMTP de Gmail ( smtp.gmail.com): $ ->host = $this->host; - El puerto SMTP utilizado por Gmail (Puerto 465): $ ->port = $this->puerto; - El nombre de usuario y la contraseña del correo electrónico Gmail: $ ->username = $this-> remitente; $ ->password = $this->contrasena; - La dirección de correo al que se le quiere enviar el $ ->addaddress($destinatario); - El asunto y el cuerpo del que se quiere enviar: $ ->subject = $asunto; //asunto $ ->body = $cuerpo; //cuerpo 101
105 - El nombre que quiero mostrar al enviar el $ ->fromname = $this->nombreremitente; - El correo electrónico desde donde envio el $ ->from = $this-> remitente; Una vez almacenados todos los datos, se envía el $ ->send(); Enviar SMS Anteriormente, he comentado que el kit de desarrollo de software (SDK) de IntelliSMS permite enviar mensajes SMS desde un script PHP. Para su utilización, he descargado dicho script y lo he incluido en la carpeta intellisms en el directorio de la aplicación (dentro de la carpeta Negocio). A continuación, explico el código de la clase sms: <?php include_once("intellisms/sendscripts/intellisms.php"); //Para enviar SMS, se requiere que en el archivo php.ini este: // allow_url_fopen = On // track_errors = On Este código se tiene a disposición dentro de la página Web de IntelliSMS. Yo lo que he hecho es adaptarlo a la aplicación para poder enviar SMS. En primer lugar, debo instanciar el archivo IntelliSMS.php ubicado en la carpeta IntelliSMS. Después inicializo la variable $nombreremitente con el nombre que quiero que muestre al enviar el SMS. private $nombreremitente = "EFMareoLogroño; Por último, para enviar un SMS utilizo la siguiente función: public function enviarsms ($telefono,$cuerpo) { $objintellisms = new IntelliSMS(); $objintellisms->username = 'abelsuco'; $objintellisms->password = '97t242p7'; $nuevotelefono="34$telefono"; //34 Prefijos España $objintellisms->sendmessage($nuevotelefono, $cuerpo, $this- >nombreremitente); //Telefono donde se manda el sms, cuerpo del sms y nombre o número del remitente } Como se puedo observar, creo una variable de tipo IntelliSMS que servirá para almacenar toda la información referente al SMS: el nombre de usuario y contraseña correspondientes al registro de IntelliSMS y el teléfono junto con prefijo del país. (España =34; antes del número de teléfono). Por último, se envía el SMS mediante la función SendMessage, a la que le paso el teléfono, el cuerpo del mensaje y el nombre del remitente. 102
106 Añadir Falta Entrenamiento Las funciones enviarsms y enviar son utilizadas al añadir una falta de entrenamiento. Ya que he comentado anteriormente, en el segundo ciclo, un ejemplo de código muy parecido a este, solamente voy a entrar en detalles en lo que respecta a las funciones enviar y enviar SMS. Siempre que un empleado o un administrador añadan una falta de entrenamiento correctamente, se enviará automáticamente un y un SMS al padre del jugador. Para ello, inicializo una variable de tipo para llamar a la función enviar con los parámetros destinatario (correo electrónico del padre), asunto y cuerpo del . $mandar = new (); $mandar ->enviar ($destinatario, $asunto, $cuerpo); Por último, inicializo una variable de tipo sms para llamar a la función enviarsms con los parámetros número de teléfono y cuerpo del sms. $mandarsms = new sms(); $mandarsms->enviarsms($telefono, $cuerpo); Interfaces definitivas En este apartado voy a mostrar las interfaces que intervienen al gestionar una falta de entrenamiento de un jugador. Visualizar Falta Entrenamiento: Figura 66: Interfaz visualizar falta entrenamiento 103
107 Añadir Falta Entrenamiento: Figura 67: Interfaz añadir falta entrenamiento (Administrador) Falta Entrenamiento añadida correctamente: Figura 68: Interfaz falta entrenamiento añadida correctamente (Administrador) 104
108 Modificar Falta Entrenamiento: Figura 69: Interfaz modificar falta entrenamiento (Administrador) Eliminar Falta Entrenamiento: Figura 70: Interfaz eliminar falta entrenamiento (Administrador) 105
109 Resultados de las pruebas unitarias A continuación, compruebo que los resultados de las pruebas unitarias diseñadas en el proceso anterior son los esperados. Solamente se muestran varias pruebas: Prueba Unitaria 1 Descripción Falta entrenamiento añadida correctamente Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-1, AFE-3, AFE-5 Salida Esperada Falta entrenamiento añadida correctamente. Se ha enviado y SMS notificando la falta al padre del jugador. Salida Obtenida Falta entrenamiento añadida correctamente. Se ha enviado y SMS notificando la falta al padre del jugador. Prueba Correcta SI Prueba Unitaria 2 Descripción Falta de entrenamiento no añadida. Ya existe la falta de entrenamiento. Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-1, AFE-3, AFE-6 Salida Esperada La falta de entrenamiento ya existe. Falta de entrenamiento no añadida. Salida Obtenida La falta de entrenamiento ya existe. Falta de entrenamiento no añadida. Prueba Correcta SÍ. Prueba Unitaria 3 Descripción Error formato fecha Entradas Fecha falta entrenamiento: Datos jugador: Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-2 Salida Esperada La fecha introducida no cumple el formato establecido. Salida Obtenida La fecha introducida no cumple el formato establecido. Prueba Correcta SÍ. 106
110 Prueba Unitaria 4 Descripción Error no existe jugador Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador: Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin Clases cubiertas AFE-4 Salida Esperada El jugador introducido no existe. Añada primero el jugador. Salida Obtenida El jugador introducido no existe. Añada primero el jugador. Prueba Correcta SÍ. Pruebas de aceptación Tras realizar las pruebas de aceptación en relación a los requisitos mínimos marcados al comienzo de la aplicación, se da a la aplicación como válida y terminada. 107
111 Bibliografía Libros - El libro oficial de Joomla! Jennifer Marriott, Elin Waring Anaya Multimedia, Desarrollo Web con PHP y MySQL. (PHP 5 y MySQL 4.1 y 5) Luke Welling, Laura Thompson Anaya Multimedia, Fundamentos de Sistemas de Bases de Datos Ramez Elmasri, Shamkant B. Navathe Addison Wesley, Curso de CSS Christopher Schmitt Anaya Multimedia, 2010 Referencias Web - Programación PHP PHP Manual - PHPMailer - Joomla! - Plantillas y módulos Joomla! Gavick - ADOdb - MySQL, Developer Zone - Apache Friends XAMPP - IntelliSMS SMS Gateway 108
112 - Api Google Maps - Wikipedia, la enciclopedia libre. Apuntes - Base de datos. - Diseño de Bases de datos. - Programación de Bases de datos. - Ingeniería del Software. 109
113 Anexo A: Manual usuario Administración Joomla! (Back-end) Conceptos básicos - Plantillas: la plantilla (template) proporciona el aspecto visual para la aplicación Web. - Componentes: son pequeñas aplicaciones independientes entre sí que gestionan la información dentro de Joomla!. Los componentes añaden distintas funcionalidades a Joomla! y lo convierten en mucho más que una Web de artículos o noticias. La instalación estándar de Joomla! incluye: o Componente que gestiona los contenidos: com_content. o Componente que administra y muestra la página principal del sitio Web: com_frontpage. o Componente encargado de administrar los contactos y enviar los mensajes por que escriben desde el formulario los usuarios: com_contact. o Componente de administración de banner: com_banners. o Componente de encuestas y votaciones: com_poll. o Componente de gestión y publicación de enlaces: com_weblinks. o Componentes de sindicación de noticias (hacia otros sitios: com_rss y desde otros sitios: com_newsfeeds. o Componente que genera las ventanas internas que contienen otras páginas externas (iframes): com_wrapper. o Componente de mensajería interna: com_messages. o Componente del buscador interno: com_search. o Los componentes relacionados con funciones de usuario: com_login, com_user, y com_registration. - Módulos: son extensiones o complementos de Joomla! que nos permiten añadir bloques de información secundaria en diferentes posiciones o zonas de la plantilla. El ejemplo más claro de módulo es el menú principal (mod_mainmenu) que facilita la navegación por el sitio Web. - Plugins: son extensiones que realizan dentro de Joomla! una amplia variedad de funciones relacionadas fundamentalmente con la autentificación de usuarios, el funcionamiento del buscador interno o con la edición de contenidos. Por ejemplo, plugin Google Maps utilizado en la aplicación Web. 110
114 Acceso a la Administración (Back-end) Para acceder al panel de administración de la aplicación (Back-end), introduce la siguiente URL: y le mostrará el formulario de acceso. Introduzca el Nombre de usuario ( admin ) y contraseña ( proyecto2012 ) en los respectivos campos y pulse el botón acceder. Panel de Control Una vez haya iniciado sesión, acceda al Panel de Control del Administrador (siempre que quiera volver a esta pantalla, pulse la opción Sitio->Panel de Control en el menú): Las diferentes partes en las que se divide el Panel de Control del Administrador son: 1) Menú para acceder a todas las funciones disponibles de administración (Back-end). Además, en la parte derecha del menú se encuentra la información de los usuarios no conectados al front-end (aplicación de visualización) y de los conectados a la administración, los mensajes privados que ha recibido, el enlace para ver la visualización de la aplicación Web y el enlace para finalizar sesión (Finalizar). 2) Iconos de acceso rápido a las funciones más utilizadas del Panel de Control del Administrador. 111
115 3) Información sobre los usuarios conectados, los artículos populares y los últimos artículos añadidos a la aplicación Web. Gestor multimedia Puede acceder de varias formas: 1) Menú -> Contenido -> Gestor Multimedia 2) Acceso directo Gestor Multimedia en los iconos de acceso rápido Se mostrará la siguiente pantalla: Todas las imágenes que contiene la aplicación Web están en la carpeta imágenes_web. La lista desplegable sirve para acceder a las subcarpetas. Se recomienda añadir a la subcarpeta principal las imágenes que va a utilizar en la aplicación Web. 112
116 Administrar contenido Puede acceder de varias formas: 1) Menú -> Contenido -> Gestor de categorías o Gestor de artículos. 2) Acceso directo Gestor de categorías o Gestor de artículos en los iconos de acceso rápido. Existe una jerarquía en Joomla! para administrar el contenido: 1) Categorías: contenedores que en su interior están los Artículos de Contenido u otras subcategorías. 2) Artículos de contenido: textos e imágenes que va a mostrar la aplicación Web. Gestor de categorías: Muestra todas las categorías de su aplicación Web. Su aplicación ya está completa, no debe tocar ningún apartado de esta sección. Gestor de artículos: Muestra todos los artículos de Contenido de su aplicación Web. 113
117 Esta sección dispone de las siguientes operaciones: - Nuevo: creé un nuevo artículo de contenido para su aplicación Web. - Editar: edite un artículo ya existente en su aplicación Web. - Publicar: publique el artículo en la aplicación Web. - Despublicado: artículo que no aparece en la aplicación Web. Puede ser antiguo o que ya no tiene interés en mostrarlo. - Papelera: elimine el artículo seleccionado. Añadir artículo: Cree un nuevo artículo con la función Nuevo anteriormente citada. Solo debe modificar lo que se nombra a continuación: Título: el título que le va a dar al Artículo de Contenido. Alias: el alias que le va a dar al Artículo de Contenido. Debe ser un nombre sin espacios. Categoría: seleccione la categoría a la que pertenece el artículo. Texto Artículo: escribe el texto o añade la imagen que desee. IMPORTANTE: si añade una imagen al artículo, para su correcta visualización, debe tener 600px de anchura y 346px de altura. Creado por: pulse seleccionar usuario y seleccione el usuario que lo ha creado: EF Mareo. Se recomienda justificar el texto. Además dispone de diferentes estilos de letra a su disposición. Por último, pulsar sobre el botón Guardar y Cerrar y el artículo estará listo para su publicación. Administrar contenido módulo Puede acceder de varias formas: 1) Menú -> Extensiones -> Gestor de módulos. 2) Acceso directo Gestor de módulos en los iconos de acceso rápido. 114
118 Se mostrará la siguiente pantalla: Se muestran todos los módulos instalados en la aplicación. Módulo últimas noticias: Módulo para gestionar el contenido de las últimas noticias de la Escuela de Fútbol de Mareo en Logroño. Para actualizar la información que aparece en el módulo, siga los siguientes pasos: 1) Accede al módulo Últimas noticias del Gestor de módulos. 2) Accede al menú de la derecha a la pestaña Diapositivas. Se mostrará lo siguiente: 115
119 Visualización diapositiva. Diapositiva publicada. Si pulsa sobre el icono, puede despublicarla. Eliminar diapositiva Editar diapositiva Ordenar diapositiva. Orden de visualización en la aplicación Web. IMPORTANTE: Solo puede haber cuatro diapositivas publicadas. 3) Pulse sobre añadir nueva diapositiva. Se mostrará lo siguiente: Tipo de contenido: artículo Imagen: pulse sobre seleccionar y buscar la imagen que quiera añadir en el Gestor multimedia. Se recomienda almacenar la imagen en la subcarpeta Principal de la carpeta imágenes_web. IMPORTANTE: la imagen se debe guardar para su correcta visualización en 637 x 346. Extensión de e imagen acceso se deja como está. Estado: publicado Título: como su propio nombre indica, el título de la diapositiva que va aparecer en el módulo de la aplicación Web. Artículo: pulse sobre el botón select para añadir el artículo al que está relacionado la diapositiva. 116
120 Módulo Actualidad EF Mareo: Módulo para gestionar el contenido de la actualidad de la Escuela de Fútbol de Mareo en Logroño. Cada artículo que añade a la categoría Actualidad será insertado automáticamente por orden de fecha a este módulo. Si el artículo dispone de imagen, se mostrará en el módulo una miniatura de la imagen relacionada al artículo. 117
Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA
Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)
Más detallesPRESENTACIÓN DEL PRODUCTO
PRESENTACIÓN DEL PRODUCTO esernet, s.l. Sebastián Elcano, 32 Planta 1 Oficina 22 28012 Madrid Teléfono: 91 433 84 38 -- Fax. 91 141 21 89 www.esernet.com -- esernet@esernet.com 1. Introducción 2. Descripción
Más detallesOficina Online. Manual del administrador
Oficina Online Manual del administrador 2/31 ÍNDICE El administrador 3 Consola de Administración 3 Administración 6 Usuarios 6 Ordenar listado de usuarios 6 Cambio de clave del Administrador Principal
Más detallesPrimer avance de proyecto de software para la gestión de inscripciones en cursos
Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados
Más detallesINTRANET DE UNA EMPRESA RESUMEN DEL PROYECTO. PALABRAS CLAVE: Aplicación cliente-servidor, Intranet, Área reservada, Red INTRODUCCIÓN
INTRANET DE UNA EMPRESA Autor: Burgos González, Sergio. Director: Zaforas de Cabo, Juan. Entidad colaboradora: Colegio de Ingenieros del ICAI. RESUMEN DEL PROYECTO El proyecto consiste en el desarrollo
Más detallesGestor de Contenidos CMS. Prof: Ing. Henrry Servitá
Gestor de Contenidos CMS Que es un CMS? CMS son las siglas de Content Management System, que se traduce directamente al español como Sistema Gestor de Contenidos. Como su propio nombre indica, es un sistema
Más detallesUNIVERSIDAD DE SALAMANCA
UNIVERSIDAD DE SALAMANCA FACULTAD DE CIENCIAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Resumen del trabajo práctico realizado para la superación de la asignatura Proyecto Fin de Carrera. TÍTULO SISTEMA
Más detallesCapítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable
Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable 1. Introducción. El Sistema de Administración de Información de un Negocio Franquiciable (SAINF)
Más detallesSISTEMA DE ESPECIICACION DE REQUERIMIENTOS
SISTEMA DE ESPECIICACION DE REQUERIMIENTOS Presentado por: Jefferson Peña Cristian Álvarez Cristian Alzate 10 CONTENIDO 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. AMBITO DEL SISTEMA 1.3. DEFINICIONES, ACRÓNIMOS
Más detallesCapítulo III. Diseño del sistema. Dentro de este capítulo veremos a detalle el diseño del sistema, que como se había
Capítulo III Diseño del sistema Dentro de este capítulo veremos a detalle el diseño del sistema, que como se había mencionado anteriormente, contara con 2 módulos principales: el módulo de administración
Más detallesManual de uso de la plataforma para monitores. CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib
Manual de uso de la plataforma para monitores CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib [Manual de uso de la plataforma para monitores] 1. Licencia Autor del documento: Centro de Apoyo Tecnológico
Más detallesGuía de Apoyo Project Web Access. (Jefe de Proyectos)
Guía de Apoyo Project Web Access (Jefe de Proyectos) 1 ÍNDICE Contenido INTRODUCCIÓN... 3 CAPITULO I: ELEMENTOS INICIALES DE PROJECT WEB ACCESS... 4 Configuración General... 4 Área de Trabajo del Proyecto...
Más detallesPANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet. Revisión 1.1 Fecha 2006-08
PANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet Revisión 1.1 Fecha 2006-08 Índice 1. Acceder 2. Menú 3. Gestión Básica 3.1 Añadir 3.2 Editar 3.3 Eliminar 3.4 Eliminación de registros
Más detallesManual hosting acens
Manual hosting acens Contenido Acceso al panel de control de cliente... 3 Asociar un dominio a mi Hosting... 5 Acceso al panel de administración del hosting... 7 INICIO - Visión general del estado de nuestro
Más detallesConceptos Generales en Joomla 1.7.2.
1.- Tipos de usuarios en Joomla! JOOMLA 1.7 USUARIOS. Los usuarios de sitios web de Joomla! pueden dividirse en dos categorías principales: Invitados. Usuarios registrados. Los Invitados son sencillamente
Más detallesCIF-KM. GUÍA DE LOS PRIMEROS PASOS
CIF-KM. GUÍA DE LOS PRIMEROS PASOS Secciones 1. CONCEPTOS PREVIOS. 2. INSTALAR CIF-KM. 2.1 Descargar e instalar CIF-KM. 2.2 Configuración de CIF-KM. 2.3 Acceso externo al servidor de CIF-KM. 3. PRIMERA
Más detallesBASES DE DATOS TEMA 3 MODELO ENTIDAD - RELACIÓN
BASES DE DATOS TEMA 3 MODELO ENTIDAD - RELACIÓN 3.3 Aplicaciones Definición de Aplicación (Application). Programa informático que permite a un usuario utilizar una computadora con un fin específico. Las
Más detallesLiLa Portal Guía para profesores
Library of Labs Lecturer s Guide LiLa Portal Guía para profesores Se espera que los profesores se encarguen de gestionar el aprendizaje de los alumnos, por lo que su objetivo es seleccionar de la lista
Más detallesCÓMO MANEJAR SU NUEVO SITIO WEB SOBRE DRUPAL Manual técnico y de usuario. Pontificia Universidad Javeriana Grupo PSU 2009-1 CDI
CÓMO MANEJAR SU NUEVO SITIO WEB SOBRE DRUPAL Manual técnico y de usuario Pontificia Universidad Javeriana Grupo PSU 2009-1 CDI Sobre Drupal Instalación y configuración Drupal es un sistema de gestión de
Más detallesCapitulo 5. Implementación del sistema MDM
Capitulo 5. Implementación del sistema MDM Una vez que se concluyeron las actividades de análisis y diseño se comenzó la implementación del sistema MDM (Manejador de Documentos de MoProSoft). En este capitulo
Más detallesTRABAJO FIN DE ESTUDIOS
TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Sitio web y aplicación para la gestión de una tienda de bellas artes Tania De Pedro Sáenz Tutor: Beatriz Pérez Valle Curso 2011-2012 Sitio web y aplicación
Más detallesMANUAL EMPRESA PRÁCTICAS CURRICULARES
MANUAL EMPRESA PRÁCTICAS CURRICULARES ÍNDICE 1. Introducción... 2 2. Registro y Acceso... 2 2.1. Registro Guiado... 3 2.1. Registro Guiado Datos Básicos... 4 2.1. Registro Guiado Contactos... 4 3. Creación
Más detallesManual Oficina Web de Clubes (FBM)
Manual Oficina Web de Clubes (FBM) INTRODUCCIÓN: La Oficina Web de Clubes de Intrafeb es la oficina virtual desde la que un club podrá realizar las siguientes operaciones durante la temporada: 1. Ver información
Más detallesJoomla! La web en entornos educativos
Joomla! La web en entornos educativos Módulo : 2012 ACL (I). Usuarios. Estructura predeterminada. 4 Las versiones 2.5 de Joomla! poseen un avanzado ACL (Access Control List), que especifica qué usuarios
Más detallesG R U P O S INDICE Cómo crear una cuenta en ARQA? Cómo tener un grupo en ARQA? Secciones y funcionalidades de los grupos Configuración del grupo
INDICE Cómo crear una cuenta en ARQA? 4 Cómo tener un grupo en ARQA? 5 Secciones y funcionalidades de los grupos 6 Muro del Grupo 6 Compartir Textos 8 Compartir Imágenes 9 Compartir videos 10 Compartir
Más detallesGuía de Laboratorio Base de Datos I.
Guía de Laboratorio Base de Datos I. UNIVERSIDAD DON BOSCO FACULTAD DE INGENIERIA 1- Gestión del SQL Server Management Studio y creación de bases de datos. Objetivos: Identificar el entorno de trabajo
Más detallesMANUAL PARA EMPRESAS PRÁCTICAS CURRICULARES
MANUAL PARA EMPRESAS PRÁCTICAS CURRICULARES ÍNDICE 1. Introducción... 3. Registro y Acceso... 3.1. Registro Guiado... 4.1. Registro Guiado Datos Básicos... 5.1. Registro Guiado Contactos... 6 3. Creación
Más detallesManual del Alumno de la plataforma de e-learning.
2 Manual del Alumno de la Plataforma de E-learning 3 4 ÍNDICE 1. Página de Inicio...7 2. Opciones generales...8 2.1. Qué es el Campus...8 2.2. Nuestros Cursos...9 2.3. Cómo matricularme...9 2.4. Contactar...9
Más detallesFOROS. Manual de Usuario
FOROS Manual de Usuario Versión: 1.1 Fecha: Septiembre de 2014 Tabla de Contenidos 1. INTRODUCCIÓN... 4 1.1 Propósito... 4 1.2 Definiciones, acrónimos y abreviaturas... 4 2. ESPECIFICACIONES TÉCNICAS...
Más detallesAjustes del Curso en egela (Moodle 2.5)
Ajustes del Curso en egela (Moodle 2.5) Manual para el profesorado Versión 2 (12/05/2015) El presente manual ha sido desarrollado por el Campus Virtual de la Universidad del País Vasco / Euskal Herriko
Más detallesOasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas.
1. Manual de usuario 1.1 Esquema de Oasis Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas. Gracias a OASIS usted podrá comprar o seleccionar aplicaciones
Más detallesMANUAL DE. manual de Joomla JOOMLA
MANUAL DE manual de Joomla JOOMLA Tabla de contenido 1. Instalación de Joomla y características... 2 2. Configuración del sitio web... 3 3. Gestión de usuario... 8 4. Gestión de artículos... 11 5. Otros
Más detallesSinAuto: Captura de requisitos
SinAuto: Captura de requisitos INGENIERÍA DEL SOFTWARE 08/09 (PROFESOR: G. RIGAU) GRUPO6 Miguel Meaurio Peña... mogiokfmaster@gmail.com Cesar Peñas... kuxume@gmail.com Alexander Díaz Miguel... nator900@hotmail.com
Más detallesSkype. Inguralde [Enero 2011]
Inguralde [Enero 2011] 1. Introducción Skype es un software que permite al usuario que lo utiliza, formar parte de una gran red de telefonía por Internet. Eso quiere decir que con Skype instalado en un
Más detallesToda base de datos relacional se basa en dos objetos
1. INTRODUCCIÓN Toda base de datos relacional se basa en dos objetos fundamentales: las tablas y las relaciones. Sin embargo, en SQL Server, una base de datos puede contener otros objetos también importantes.
Más detallesAnálisis y diseño del sistema CAPÍTULO 3
Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la
Más detallesTraslado de Copias y Presentación de Escritos. Manual de Usuario V.3.1
Traslado de Copias y Presentación de Escritos Manual de Usuario V.3.1 Página: 2 45 INDICE INTRODUCCIÓN... 3 1 ACCESO A LA APLICACIÓN... 3 2 PROCESO DE FIRMA... 4 3 TRASLADOS PENDIENTES DE ACEPTAR POR EL
Más detallesProceso de cifrado. La fortaleza de los algoritmos es que son públicos, es decir, se conocen todas las transformaciones que se aplican al documento
Qué es AT-Encrypt nos permitirá dotar de contraseña a cualquier documento o carpeta. Este documento o carpeta sólo será legible por aquel que conozca la contraseña El funcionamiento del cifrado (o encriptación)
Más detallesHacemos que tu negocio se mueva. Plataforma de ventas. www.movilidapp.com. 2014 movilidapp
Hacemos que tu negocio se mueva Plataforma de ventas www.movilidapp.com 2014 movilidapp NUESTRA PLATAFORMA DE VENTAS Nuestra plataforma de ventas permite gestionar la realización de pedidos de sus productos
Más detallesGedicoPDA: software de preventa
GedicoPDA: software de preventa GedicoPDA es un sistema integrado para la toma de pedidos de preventa y gestión de cobros diseñado para trabajar con ruteros de clientes. La aplicación PDA está perfectamente
Más detallesSINAUTO. (Captura Requirimientos) GRUPO 03
SINAUTO (Captura Requirimientos) GRUPO 03 Iker Jauregi ikerjauregivicente@hotmail.com Iñigo Arregui bateman2012@gmail.com Javier Arce arcjav@hotmail.com Jorge García. jgfand@gmail.com Patxi Campos.patxi948@wanadoo.es
Más detallesGESTIÓN DOCUMENTAL PARA EL SISTEMA DE CALIDAD
GESTIÓN DOCUMENTAL PARA EL SISTEMA DE CALIDAD Manual de usuario 1 - ÍNDICE 1 - ÍNDICE... 2 2 - INTRODUCCIÓN... 3 3 - SELECCIÓN CARPETA TRABAJO... 4 3.1 CÓMO CAMBIAR DE EMPRESA O DE CARPETA DE TRABAJO?...
Más detallesGuía de Inicio Respaldo Cloud
Guía de Inicio Respaldo Cloud Calle San Rafael, 14 28108 Alcobendas (Madrid) 900 103 293 www.acens.com Contenido 1 Introducción... 3 2 Características Respaldo Cloud... 4 3 Acceso y activación... 5 - Gestión
Más detallesInternet Information Server
Internet Information Server Internet Information Server (IIS) es el servidor de páginas web avanzado de la plataforma Windows. Se distribuye gratuitamente junto con las versiones de Windows basadas en
Más detallesAplicación para la gestión de prácticas en empresas. Memoria
Aplicación para la gestión de prácticas en empresas. Memoria El proyecto se basa en la creación de una aplicación para la gestión de prácticas curriculares en empresas de los alumnos de la Facultad de
Más detallesGUÍA BÁSICA USUARIO MOODLE 2.6
GUÍA BÁSICA USUARIO MOODLE 2.6 Esta guía representa los pasos a seguir por el alumno desde la aceptación en un curso Moodle hasta su posterior utilización, pero antes de explicar la forma de acceder y
Más detallesCURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB
CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB Objetivos Generales: Al término de esta acción formativa los participantes alcanzarán los siguientes objetivos: Preparar profesionales para el desarrollo
Más detallesPerson IP CRM Manual MOBILE
Manual MOBILE División Informática BuscPerson Telecomunicaciones : Manual MOBILE 0.- Introducción 3 0.1 Configuración de los terminales 3 0.2 Acceso de Usuarios 3 1.- Funcionalidades CRM 5 1.1 Agenda del
Más detallesAPLICATECA. Guía para la contratación y gestión de. Hacemos Tu Web
APLICATECA Guía para la contratación y gestión de Hacemos Tu Web INDICE 1 QUÉ ES HACEMOS TU WEB?... 1 1.1 PARA QUÉ SIRVE?... 1 1.2 CARACTERÍSTICAS DE HACEMOS TU WEB... 1 1.3 REQUERIMIENTOS DEL SERVICIO...
Más detallesModulo I. Introducción a la Programación Web. 1.1 Servidor Web.
Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados
Más detallesGobierno Electrónico ANEXOS ANEXO A: INSTALACIÓN, CONFIGURACIÓN Y ACTUALIZACIÓN DE JOOMLA, MÓDULOS Y COMPONENTES. Alexandra Paola Guerrero Chuquín
Gobierno Electrónico NEXOS NEXO : INSTLCIÓN, CONFIGURCIÓN Y CTULIZCIÓN DE JOOML, MÓDULOS Y COMPONENTES 1 NEXO : Instalación, Configuración y ctualización de Joomla, Módulos y Componentes. Qué es Joomla?
Más detallesMANUAL DE USO DE LA APLICACIÓN
MANUAL DE USO DE LA APLICACIÓN ÍNDICE 1. Acceso a la aplicación 2. Definición de funciones 3. Plantillas 4. Cómo crear una nueva encuesta 5. Cómo enviar una encuesta 6. Cómo copiar una encuesta 7. Cómo
Más detallesGuía Rápida de Inicio
Guía Rápida de Inicio 1. Acerca de esta Guía Esta guía le ayudará a instalar y dar los primeros pasos con BitDefender Security for SharePoint. Para disponer de instrucciones detalladas, por favor, diríjase
Más detallesMANUAL DE LA APLICACIÓN CEXVEG Campañas Específicas de Exportación
MANUAL DE LA APLICACIÓN CEXVEG Campañas Específicas de Exportación http://programasnet.marm.es/cexveg/ Usuario: Operador Marzo 2012 ÍNDICE PASOS PREVIOS PARA EL USO CORRECTO DE LA APLICACIÓN... 1 1. INTRODUCCIÓN...
Más detallesDE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES
Técnico Especialista en Instalación y Configuración de CRM: Gestión de Relación con Clientes TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Duración:
Más detallesWeb ITSM -GUIA RÁPIDA DE USUARIO-
Web ITSM -GUIA RÁPIDA DE USUARIO- Manual básico de la aplicación WebITSM donde se visualiza la funcionalidad completa de la misma y la forma adecuada y eficaz de utilizarla. Ingeniería Técnica en Informática
Más detallesMultipedidos es un sistema de ventas on-line que permite gestionar pedidos por internet en tiempo real de manera económica, simple y eficaz.
Presentación Multipedidos es un sistema de ventas on-line que permite gestionar pedidos por internet en tiempo real de manera económica, simple y eficaz. El sistema está pensado para empresas que deseen
Más detallesQué necesito saber para tener mi sitio web en Internet?
Qué necesito saber para tener mi sitio web en Internet? Introducción Antes es importante tener en cuenta que Es importante considerar lo siguiente: Definir claramente tu actividad en Internet Establecer
Más detallesUNIVERSIDAD TECNOLOGICA DE HERMOSILLO SCRUM SPRINT #1. Ingenieria de Software I MAESTRO: BERNARDO PRADO DIAZ INTEGRANTES. Jorge Valdano.
UNIVERSIDAD TECNOLOGICA DE HERMOSILLO SCRUM SPRINT #1 Ingenieria de Software I MAESTRO: BERNARDO PRADO DIAZ INTEGRANTES Jorge Valdano Maria Sorte Antonio Rico Osmar Gutierrez Hermosillo, Sonora 04 de Septiembre
Más detallesINSTRUCCIONES BÁSICAS DE ACCESO AL PORTAL DEL CLIENTE
Para poder acceder a la información como Cliente debe acceder a la Plataforma Digital y registrarse, tal como hacía hasta ahora, con su usuario y contraseña. Si no cuenta con sus datos de acceso, puede
Más detallesGuías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online
Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...
Más detallesLMS: Manual de la familia
Sistema UNOi LMS: Manual de la familia En este Learning Coffee aprenderá a: Acceder a la plataforma y editar su cuenta. Acceder a sus notificaciones. Consultar el calendario. Consultar clases, proyectos
Más detallesAdicionalmente, en función de su objetivo, las Cookies puedes clasificarse de la siguiente forma:
Cookies policy a) Utilización de Cookies y Web Bugs b) Tipología, finalidad y funcionamiento de las Cookies c) Cómo deshabilitar las Cookies y los Web Bugs en los principales navegadores d) Qué ocurre
Más detallescomunidades de práctica
1. Introducción CoSpace es una plataforma web diseñada para proporcionar un espacio virtual de interacción y colaboración entre formadores en comunidades virtuales. Se originó como resultado de las necesidades
Más detallesLa plataforma educativa Helvia.
La plataforma educativa HELVIA Autores: Begoña Laínez Sanz, DNI: 31336591B José Javier Álvarez García, DNI: 31666085F Mª de los Ángeles Vilches Amado, DNI: 75744033L Juana María Álvarez Jiménez, DNI: 32042323B
Más detallesMODULO: MERCADEO. Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) MODELO DE MUESTRA SIN VALOR COMERCIAL
MODULO: MERCADEO Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) 1 Servicio de Soporte. El presente apartado constituye las condiciones de soporte y mantenimiento por parte de enncloud
Más detallesEl objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos.
Gestión de proyectos Duración: 45 horas Objetivos: El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Contenidos:
Más detallesGestión de proyectos
Gestión de proyectos Horas: 45 El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Gestión de proyectos El
Más detallesINFORME DE CIERRE ETAPA 5
INFORME DE CIERRE ETAPA 5 DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE FICHEROS VIRTUALES PARA EL APOYO DE LA DOCENCIA Y DESARROLLO DE LOS ALUMNOS DE LA UNIVERSIDAD DEL BÍO-BÍO Esta Publicación fue Desarrollada
Más detallesProyecto Fin de Carrera
Proyecto Fin de Carrera Gestión del Proyecto para una Plataforma online de intercambio, compra o venta de ayudas técnicas. Consultora: Ana Cristina Domingo Troncho Autor: Álvaro Fanego Lobo Junio de 2013
Más detallesAdministración de portales Joomla (II) antonio.duran.terres@gmail.com
Administración de portales Joomla (II) antonio.duran.terres@gmail.com Módulos Con la instalación base de Joomla vienen varios módulos Algunos ya los vimos, como encuestas o Quien está en línea? Hay otros
Más detallesPrestaciones generales. Web corporativa del despacho
La nueva y mejorada versión de Asesoriaweb, más intuitiva y eficiente, permite al asesor completar los servicios prestados a sus clientes junto con las demás aplicaciones de NCS Software. Su principal
Más detallesGUÍA RED SOCIAL FACEBOOK
GUÍA RED SOCIAL FACEBOOK Qué es una Red Social? Una Red Sociales un sitio en internet donde compartir información, mensajes, ideas, fotos, etc., con amigos, conocidos y desconocidos. Para acceder a una
Más detallesManual de Usuario SIMIN 2.0
Servicio Nacional de Geología y Minería Ministerio de Minería Gobierno de Chile Manual de Usuario SIMIN 2.0 [Sistema de Información Minera en Línea] Administrador delegado de Empresas Mandantes Programa
Más detallesIntroducción. Componentes de un SI. Sistema de Información:
Introducción. Sistema de Información: Conjunto de elementos relacionados entre sí de acuerdo a ciertas reglas, que aporta a la organización la información necesaria para el cumplimiento de sus fines, para
Más detallesIMPLEMENTAMOS y GESTIONAMOS GESTOR DE CONTENIDOS. Gestiona tu propia web
Gestiona tu propia web y Beneficios Requisitos Antecedentes PROBLEMÁTICA Sabemos que generar contenidos interesantes en nuestra web aumentan el tráfico y con ello la posibilidad de una mayor venta de nuestros
Más detallesCurso Online de Microsoft Project
Curso Online de Microsoft Project Presentación El curso a distancia estudia conceptos generales sobre las tecnologías relacionadas con Internet. Conceptos que cualquier usuario de ordenadores debe conocer
Más detallesCONFEDERACIÓN DE EMPRESARIOS DE MÁLAGA
GUÍA DEL ALUMNO 1 Introducción 2 Acceso a la plataforma 3 Cerrar sesión 4 Estructura del curso virtual 5 Foros 5.1 No quiero recibir copias de los foros en mi email 6 Mensajería Interna 7 Como subir tareas
Más detallesACCESO AL SERVIDOR EXCHANGE MEDIANTE OWA
ACCESO AL SERVIDOR EXCHANGE MEDIANTE OWA El Acceso al correo a través de OWA (Outlook Web Access) es una herramienta que permite a los usuarios consultar sus mensajes en una interfaz Web a través de un
Más detallesGestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi
Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...
Más detallesAdelacu Ltda. www.adelacu.com Fono +562-218-4749. Graballo+ Agosto de 2007. Graballo+ - Descripción funcional - 1 -
Graballo+ Agosto de 2007-1 - Índice Índice...2 Introducción...3 Características...4 DESCRIPCIÓN GENERAL...4 COMPONENTES Y CARACTERÍSTICAS DE LA SOLUCIÓN...5 Recepción de requerimientos...5 Atención de
Más detallese-mailing Solution La forma más efectiva de llegar a sus clientes.
e-mailing Solution La forma más efectiva de llegar a sus clientes. e-mailing Solution Es muy grato para nosotros presentarles e-mailing Solution, nuestra solución de e-mail Marketing para su empresa. E-Mailing
Más detallesAdministración Local Soluciones
SISTEMA INTEGRADO DE GESTIÓN DE EXPEDIENTES MODULAR (SIGM) MANUAL DE USUARIO DE ARCHIVO PRÉSTAMOS Y CONSULTAS SIGM v3 Administración Local Soluciones Control de versiones Versión Fecha aprobación Cambio
Más detallesManual para el profesor
Tus Cursos en la Web 5.0 4.2 6.3 4.2 Manual para el profesor VICERRECTORÍA DE ASUNTOS ECONÓMICOS Y GESTIÓN INSTITUCIONAL DIRECCIÓN DE GESTIÓN INSTITUCIONAL Qué es U- Cursos? U-Cursos es un servicio de
Más detallesCMS JOOMLA. Características
CMS JOOMLA Joomla es un sistema gestor de contenidos dinámicos (CMS o Content Management System) que permite crear sitios web de alta interactividad, profesionalidad y eficiencia. La administración de
Más detallesGESTIÓN DE CLÍNICAS COLEGIO OFICIAL DE VETERINARIOS DE BIZKAIA
GESTIÓN DE CLÍNICAS COLEGIO OFICIAL DE VETERINARIOS DE BIZKAIA Memoria del proyecto ÍNDICE 1 - INTRODUCCIÓN... 3 2 - OBJETIVO Y ALCANCE... 4 3 - SOLUCIÓN FUNCIONAL IMPLANTADA... 5 3.1 SENCILLEZ DE USO...
Más detallesFuncionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica)
Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica) Servinet Sistemas y Comunicación S.L. www.softwaregestionsat.com Última Revisión: Octubre 2014 FUNCIONALIDADES SAT
Más detallesGestión de la Configuración
Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de
Más detallesDISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS PARA LA ONG ASEM
Universidad Carlos III de Madrid Escuela Politécnica Superior DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS PARA LA ONG ASEM 1 Pablo Burgos Escribano Tutor: José María Sierra Cámara Ingeniería Técnica en
Más detallesWINDOWS 2008 5: TERMINAL SERVER
WINDOWS 2008 5: TERMINAL SERVER 1.- INTRODUCCION: Terminal Server proporciona una interfaz de usuario gráfica de Windows a equipos remotos a través de conexiones en una red local o a través de Internet.
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesManual de usuario investigador
Manual de usuario investigador Para poder solicitar un proyecto lo primero que tiene que hacer un investigador es iniciar sesión con su usuario en la web. Para ello debe pulsar en el icono situado en la
Más detallesManual del Usuario. Portal Web Para uso exclusivo de Ministros de Estado.
Manual del Usuario Portal Web Para uso exclusivo de Ministros de Estado. Índice de contenido Pimi 2011... 3 Ingreso al Portal... 3 Manual de Usuario... 4 Vista Perfil Privado... 5 Navegación por Perfil
Más detallesManual del Usuario. Sistema de Help Desk
Manual del Usuario Sistema de Help Desk Objetivo del Manual El siguiente manual tiene como objetivo proveer la información necesaria para la correcta utilización del sistema Help Desk. Describe los procedimientos
Más detallesGUÍA BÁSICA DE INSTALACIÓN
Bienvenido a creomicomercio.com, donde podrá crear y personalizar su propia tienda de comercio electrónico. Esta operación la podrá realizar en pocos minutos y on-line. Desde el hosting hasta la logística
Más detallesModificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.
UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:
Más detallesDiplomado en. Servicio Nacional. De Facilitadores Judiciales
Diplomado en Servicio Nacional De Facilitadores Judiciales Manual de ayuda para el alumno sobre el uso de la plataforma informática 1 Diplomado en Servicio Nacional de Facilitadores Judiciales Manejo de
Más detallesFigura 4.6: Prototipo de la pantalla de inicio.
Por lo tanto el siguiente paso ha sido realizar el prototipo a más alto nivel del sitio web, para conocer cómo quiere la empresa que se estructure el contenido y qué aspecto darle. Para ello se ha utilizado
Más detalles