• No se han encontrado resultados

Aplicación web para la gestión de peluquerías

N/A
N/A
Protected

Academic year: 2021

Share "Aplicación web para la gestión de peluquerías"

Copied!
64
0
0

Texto completo

(1)

Aplicación web para la

gestión de peluquerías

Memoria del proyecto

de Ingeniería Técnica en

Informática de Sistemas

realizado por

Mikel Trascastro Pulgar

y dirigido por

Vicenç Soler Ruiz

Escola d’Enginyeria

(2)

El abajo firmante,

Vicenç Soler Ruiz

,

profesor de “l'Escola d’Enginyeria” de la UAB,

CERTIFICA:

Que el trabajo al que corresponde la presente memoria ha estado realizado bajo su dirección por

Mikel Trascastro Pulgar

Y para que conste firma el presente.

Sabadell,

Septiembre

de

2012

---

Firmado:

Vicenç Soler Ruiz

(3)

Título del proyecto: Aplicación web para la gestión de peluquerías.

Autor: Mikel Trascastro Pulgar Fecha: Septiembre 2012

Tutor: Vicenç Soler Ruiz

Titulación: Ingeniería Técnica en Informática de Sistemas

Palabras clave (mínimo 3)

 Castellano: gestión, PHP, SQL, HTML, AJAX, JQuery y JavaScript.

 Catalán: gestió, PHP, SQL, HTML, AJAX, JQuery i JavaScript.

 Inglés: management, PHP, SQL, HTML, AJAX, JQuery and

JavaScript.

Resumen del proyecto (extensión máxima 100 palabras)

 Castellano: El proyecto consiste en una aplicación web que

permitirá gestionar todo lo relacionado con una peluquería, es decir, tener un control de los trabajadores, clientes, productos y proveedores, tener acceso a una agenda virtual para administrar citas, controlar la gestión económica de la empresa, etc.

 Catalán: El projecte consisteix en una aplicació web que

permetrà gestionar tot lo relacionat amb una perruqueria, és a dir, tenir un control dels treballadors, clients, productes i

proveïdors, tenir accés a una agenda virtual per administrar cites, controlar la gestió econòmica de l’empresa, etc.

 Inglés: The project is a web application that will manage

everything related to a hairdresser, that is, keep track of

employees, customers, products and suppliers, have access to a virtual calendar to manage appointments, have a financial management control of the company, etc.

(4)

1. INTRODUCCIÓN………..1 1.1.Descripción………..1 1.2.Objetivos………...2 1.3.Motivaciones………2 2. ESTUDIO DE VIABILIDAD………3 2.1.Introducción……….3

2.1.1. Tipología y palabras clave………3

2.1.2. Descripción………3

2.1.3. Objetivos del proyecto………...4

2.1.4. Definiciones, acrónimos y abreviaciones……….4

2.1.5. Partes interesadas………5

2.1.6. Referencias………....6

2.1.7. Producto y documentación del proyecto………6

2.2.Estudio de la situación actual……….6

2.2.1. Contexto……….6

2.2.2. Descripción física……….7

2.2.3. Usuarios y/o personal del sistema………..7

2.2.4. Diagnóstico del sistema……….8

2.2.5. Normativas y legislación………...8

2.3.Requisitos del sistema………8

2.3.1. Requisitos funcionales………....8

2.3.2. Requisitos no funcionales………..…9

2.3.3. Restricciones del sistema……….….9

2.3.4. Catalogación y priorización de los requisitos……….9

2.4.Alternativas y selección de la solución……….11

2.4.1. Alternativa 1………....11

2.4.2. Alternativa 2……….11

2.4.3. Solución propuesta………...12

2.5.Conclusiones……….12

3. PLANIFICACIÓN DEL PROYECTO………..13

3.1.Introducción………...13

3.1.1. Descripción………..13

3.1.2. Definiciones, acrónimos y abreviaciones………..…13

3.1.3. Referencias………..13

3.2.WBS (“Work Breakdown Structure”) ………14

(5)

3.3.Recursos del proyecto………15

3.3.1. Recursos del proyecto………..15

3.3.2. Calendario de los recursos……….16

3.4.Calendario del proyecto………...16

3.4.1. Dependencias……….16

3.4.2. Cuadro de tareas del proyecto……….17

3.4.3. Calendario temporal……….17 3.5.Evaluación de riesgos……….18 3.5.1. Lista de riesgos………18 3.5.2. Catalogación de riesgos……….19 3.5.3. Plano de contingencia……….19 3.6.Presupuesto………20

3.6.1. Estimación coste de personal………20

3.6.2. Estimación coste de los recursos………..20

3.6.3. Resumen y análisis coste beneficio……….20

3.7.Conclusiones……….21

4. RECURSOS UTILIZADOS………22

4.1.Lenguajes de programación………22

4.2.Herramientas y servidores………...23

5. DISEÑO………25

5.1.Arquitectura del proyecto……….25

5.2.Casos de uso……….25 5.2.1. Crear salón………..25 5.2.2. Eliminar salón………..26 5.2.3. Consultar productos………..26 5.2.4. Crear trabajador………26 5.2.5. Eliminar trabajador………27 5.2.6. Crear cliente………27 5.2.7. Eliminar cliente………28 5.2.8. Crear producto………...28 5.2.9. Eliminar producto………...29 5.2.10.Crear proveedor……….29 5.2.11.Eliminar proveedor……….29 5.2.12.Gestionar economía……….30

(6)

5.2.15.Crear cita (cliente)………....31

5.2.16.Crear cita (trabajador)……….32

5.2.17.Eliminar cita……….33

5.3.Interfaz de la aplicación web………..33

5.3.1. Visitante………33 5.3.2. Clientes……….36 5.3.3. Administrador……….38 5.3.4. Trabajador………43 6. CODIFICACIÓN Y PRUEBAS………..48 6.1.Codificación………..48 6.2.Pruebas y test……….49 7. CONCLUSIONES………51 7.1.Objetivos conseguidos………...51 7.2.Desviaciones de la planificación………51 7.3.Líneas de ampliación……….53 7.4.Valoración personal………53 8. BIBLIOGRAFIA………54 9. AGRADECIMIENTOS……….55 10.LISTA DE FIGURAS……….56 11.LISTA DE TABLAS………57

(7)

1

1.

INTRODUCCIÓN

Para la finalización de los estudios de Ingeniería Técnica en Informática de Sistemas que estoy cursando, he tenido que escoger un tema para realizar mi proyecto de final de carrera.

Después de varios días pensando temas, he decidido realizar una aplicación que gestione peluquerías, ya que mi madre es propietaria de una peluquería y sería un proyecto que se podría aprovechar.

En la peluquería no se utiliza ninguna aplicación que gestione el negocio, por eso la aplicación ha de cubrir desde cero todas las necesidades que hacen falta para realizar una buena gestión de la empresa.

Una vez tomada la decisión, le comenté a mi madre la idea de crear una aplicación web que le ayude a gestionar su negocio; le pareció una gran idea, ya que le sería muy útil para conseguir un buen control de la empresa y le ahorraría mucho tiempo para poder realizar las tareas.

1.1.

Descripción

La aplicación tiene que permitir al personal de la peluquería poder gestionar el negocio desde el ordenador fácilmente (seguimiento de los servicios prestados, control de trabajadores, clientes, del stock de los productos, etc.).

Una utilidad fundamental de la aplicación es una agenda virtual dónde los trabajadores podrán asignar las citas a los clientes, ya que actualmente las citas se apuntan en una libreta.

Los clientes registrados también podrán registrar citas en la agenda virtual.

Una función extra que tendrá la aplicación web es la posibilidad de añadir varias peluquerías, para extender el proyecto a cadenas de peluquerías. Esto permitirá tener un seguimiento de todos los establecimientos.

Todos los usuarios compartirán la misma interfaz web (administradores, trabajadores y clientes).

El hecho que sea una aplicación web permite utilizarla desde cualquier sistema operativo.

(8)

2

1.2.

Objetivos del proyecto

Los objetivos que se pretenden alcanzar son los siguientes:

1. Realizar una aplicación a nivel de usuario, es decir, que

cualquier persona de cualquier edad pueda acceder y utilizar todas las funcionalidades de la web.

2. Realizar un entorno web específico.

3. Obtener una interfaz única que permita una fácil accesibilidad,

ya sea para los administradores, trabajadores y clientes.

4. Controlar los salones que pertenezcan a la cadena de

peluquerías.

5. Gestionar todos los usuarios de la empresa (trabajadores y

clientes).

6. Administrar los productos y los proveedores de la empresa.

7. Administrar la agenda virtual para las citas de los clientes.

8. Gestionar el cobro de los servicios realizados.

Con este proyecto también se pretende alcanzar los conocimientos necesarios para poder desarrollar otros proyectos informáticos en el futuro.

1.3.

Motivaciones

La motivación principal es realizar un proyecto de ingeniería en todas sus fases.

Este proyecto está realizado para poder ayudar a personas, que como mi madre, no se han ido adaptando a las nuevas tecnologías.

Otra de mis motivaciones es poder crear una aplicación web que se pueda incorporar a un negocio y que pueda optimizar su gestión, pero sobretodo, aprender el uso de las herramientas utilizadas en el desarrollo para poder realizar otro tipo de proyectos en el futuro.

Y por último, la motivación más personal para mí es conseguir realizar el proyecto e intentar aplicar los conocimientos que aprendí en el Ciclo Formativo de Grado Superior de Administración de Sistemas Informáticos, ya que durante la carrera no he podido seguir practicando estos conocimientos.

(9)

3

2.

ESTUDIO DE VIABILIDAD

2.1.

Introducción

El estudio de viabilidad analiza si este proyecto es viable.

El proyecto se basa en la creación de una aplicación web que permita tener controlado el negocio y también exponerlo al público a través de Internet.

Pretende cubrir todas las necesidades de una peluquería, como gestionar los servicios relacionados con los trabajadores y los clientes, el control de productos y proveedores y también administrar las citas de los clientes mediante una agenda virtual.

2.1.1.

Tipología y palabras clave

Todo proyecto tiene unas palabras clave que los identifican y que dan una idea sobre qué proyecto se desarrollará.

Este proyecto se define con la tipología de desarrollo, en este caso de desarrollo de una aplicación web.

También tiene unas palabras clave que lo identifican, es decir, las palabras que se utilizarían para buscar el proyecto: gestión de una peluquería, gestión de datos, PHP, MySQL, HTML, AJAX y JQuery.

2.1.2.

Descripción

La gestión de una peluquería es una necesidad de pequeños negocios (peluquerías) y de grandes empresas (cadenas de peluquerías).

En la mayoría de estos negocios este proceso es totalmente manual, ya que no se han ido innovando con el tiempo.

Desarrollar una aplicación para este negocio puede suponer una mejora importante, tanto en el ahorro de tiempo y de costes, como en la organización.

La aplicación consistirá en un entorno web con una interfaz sencilla, que deberá permitir interactuar en ella a todo tipo de usuarios, ya que muchos clientes en este tipo de negocios son personas mayores.

Este proyecto se desarrollará, como veremos, con un bajo coste económico, ya que todo el material necesario para su desarrollo se puede obtener de manera gratuita.

(10)

4

2.1.3.

Objetivos del proyecto

En este apartado vamos a ver la prioridad que tienen cada uno de los objetivos listados en el apartado 1.2.:

1. Realizar una aplicación a nivel de usuario, es decir, que

cualquier persona de cualquier edad pueda acceder y utilizar todas las funcionalidades de la web.

2. Realizar un entorno web específico.

3. Obtener una interfaz única que permita una fácil accesibilidad,

ya sea para los administradores, trabajadores y clientes.

4. Controlar los salones que pertenezcan a la cadena de

peluquerías.

5. Gestionar todos los usuarios de la empresa (trabajadores y

clientes).

6. Administrar los productos y los proveedores de la empresa.

7. Administrar la agenda virtual para las citas de los clientes.

8. Gestionar el cobro de los servicios realizados.

En la tabla 2.1.3.1 podemos observar la prioridad que tienen cada uno de los objetivos citados anteriormente.

Tabla 2.1.3.1: Priorización de los objetivos del proyecto.

Crítico Prioritario Secundario Objetivo 1 X Objetivo 2 X Objetivo 3 X Objetivo 4 X Objetivo 5 X Objetivo 6 X Objetivo 7 X Objetivo 8 X

2.1.4.

Definiciones, acrónimos y abreviaciones

Los acrónimos que se utilizan a lo largo del estudio de viabilidad son: 1. LOPD: Ley orgánica de protección de datos.

2. Cliente: socios, clientes de la peluquería. 3. RF: Requisitos funcionales

(11)

5

2.1.5.

Partes interesadas

Todo proyecto tiene unas partes interesadas en que éste se desarrolle con éxito.

En la tabla 2.1.5.1 se muestran las partes interesadas en el desarrollo del proyecto (“stakeholders”) con sus responsabilidades correspondientes.

Tabla 2.1.5.1: Partes interesadas en el desarrollo del proyecto.

“STAKEHOLDERS”

Nombre Descripción Responsabilidad

Mikel Trascastro Responsable de la

entidad

Responsable del desarrollo de la aplicación web, de la base de datos y de la memoria.

Vicenç Soler Director del proyecto Supervisa el trabajo realizado en el proyecto. Evalúa el proyecto. En la tabla 2.1.5.2 se muestran los perfiles de usuarios de la entidad que recibirá la aplicación web junto con las responsabilidades de cada uno.

Tabla 2.1.5.2: Perfiles de usuario de la entidad.

PERFILES DE USUARIOS

Nombre Perfil Responsabilidad

Jefe de la

peluquería Administrador del sistema

Gestión y control de todas las funcionalidades del sistema, gestión de salones, usuarios (trabajadores y clientes), productos, etc.

Trabajadores Usuario experto Gestión de clientes, gestión de productos, gestión de la agenda, etc.

Clientes Usuario no experto Acceso al entorno web, asignación de citas.

En la tabla 2.1.5.3 se muestran los integrantes del equipo que trabaja para llevar a cabo el proyecto junto con sus responsabilidades.

Tabla 2.1.5.3: Equipo de proyecto.

“PROJECT TEAM”

Nombre Descripción Responsabilidad

Mikel Trascastro Jefe del proyecto Coordina a todos los integrantes de la peluquería y tiene la función de gestionar el proyecto.

(12)

6

2.1.6.

Referencias

El proyecto tiene que seguir unas normativas, unos estándares y unas leyes dentro de la normativa legal vigente:

1. Normativa de proyectos de ingeniería técnica:

http://www.uab.cat/Document/541/595/Normativa_PFCNovembre2010. pdf

2. LOPD (Ley Orgánica de Protección de Datos):

https://www.agpd.es/portalweb/canaldocumentacion/legislacion/estat al/indexies-idphp.php

3. W3C (World Wide Web Consortium): http://www.w3.org/standards

4. Validación oficial HTML para examinar el código de la página web:

http://validator.w3.org/

5. Validación oficial CSS para examinar las hojas de estilo:

http://jigsaw.w3.org/css-validator/validator.html.es

2.1.7.

Producto y documentación del proyecto

Una vez esté finalizado el proyecto: 1. Se entregará una aplicación web.

2. Se elaborará una memoria del proyecto. 3. Se implementará en el mercado.

2.2.

Estudio de la situación actual

2.2.1.

Contexto

La entidad actualmente no dispone de ninguna aplicación que gestione el negocio (peluquería).

Hasta ahora la entidad ha realizado toda la gestión manualmente, y por ello no se ha podido llevar un control organizado del negocio.

La aplicación web se desarrollará desde cero, ya que es una idea propia y no se utilizará ninguna base o plantilla para así poder adaptarla a la entidad desde el principio.

Una vez acabado el proyecto se intentará perfeccionar para que la aplicación encaje en cualquier cadena de peluquerías sin problema.

(13)

7

2.2.2.

Descripción física

El proyecto dispone de una estructura física bastante básica formada por un servidor, un ordenador y un módem.

Figura 2.2.2.1: Estructura física de la entidad.

La entidad dispone de una estructura informática básica mostrada en la tabla 2.2.2.1:

Tabla 2.2.2.1: Estructura informática de la entidad.

Cliente Servidor

Procesador: Genuine Intel(R)

CPU T1600 @ 1.66 GHz Procesador: Intel Xeon 3.0 GHz

Memoria RAM: 4GB Memoria RAM: 512 MB

Disco duro: HITACHI ATA

Device 298 GB Servidor de red

Punto de acceso (Router Telefònica)

Windows 2003 Server Standard

Windows 7 32 bits My SQL y Phpmyadmin

2.2.3.

Usuarios y/o personal del sistema

El sistema actual está formado por el personal de la entidad dónde cada uno tiene unas determinadas responsabilidades.

Tabla 2.2.3.1: Personal del sistema.

Descripción Responsabilidad

Jefe de la peluquería

Gestión y control de todas las funcionalidades del sistema, gestión de salones, usuarios (trabajadores y clientes), productos, económica, etc.

Trabajadores Gestión de usuarios (clientes), gestión de productos, gestión de la agenda. Clientes registrados Asignar cita en la agenda virtual. Actualizar datos personales.

(14)

8

2.2.4.

Diagnóstico del sistema

El sistema actual presenta las siguientes deficiencias:

o El sistema actual es muy dependiente de las personas.

o Es propenso a errores y pérdida de información.

o La gestión de los clientes es dificultosa.

o La gestión de los productos es dificultosa.

Las posibles mejoras que puede presentar el sistema son:

o Acceso eficiente a la información.

o Disminución de los errores y pérdidas de información.

o Mejora en la gestión.

2.2.5.

Normativas y legislación

Las normativas y legislaciones que deben aplicarse en el proyecto son las siguientes:

1. LOPD: Ley Orgánica de Protección de Datos.

2. Normativa de proyectos de final de carrera de la EI.

2.3.

Requisitos del sistema

2.3.1.

Requisitos funcionales

Todos los proyectos tienen unos requisitos funcionales, que son las funcionalidades que se desea que tenga el sistema. En este proyecto son los siguientes:

1. Mantenimiento (altas, bajas, modificaciones) de los perfiles de los clientes.

2. Mantenimiento (altas, bajas, modificaciones) de los perfiles de los trabajadores.

3. Gestión de la agenda virtual.

4. Gestión de productos y proveedores. 5. Gestión de salones.

6. Control de la gestión económica de los salones.

(15)

9

2.3.2.

Requisitos no funcionales

Los requisitos no funcionales de un proyecto nos describen los atributos de calidad que habrá en el sistema:

1. Cumplimiento de la LOPD en lo referente a los ficheros de datos y los derechos de los clientes.

2. Los recursos utilizados por la aplicación deben estar ajustados a la medida de la entidad.

3. Tolerancia a fallos y acciones incorrectas.

4. Control de acceso de los usuarios a la aplicación. 5. Facilidad de uso de la interfaz gráfica.

6. Control de la agenda virtual.

7. Navegación rápida, es decir, sin cargar la web con todas las acciones, para ello utilizo JQuery/AJAX.

2.3.3.

Restricciones del sistema

Las restricciones del sistema son las siguientes:

1. La aplicación debe adaptarse a los navegadores más populares. 2. La base de datos debe ser multiusuario.

3. La aplicación debe adaptarse al sistema físico disponible en la entidad.

4. El proyecto debe estar finalizado antes del 19 de Septiembre de 2012.

2.3.4.

Catalogación y priorización de los requisitos

En la tabla 2.3.4.1 se muestra la catalogación y la prioridad que tienen los requisitos funcionales del sistema.

Tabla 2.3.4.1: Prioridad de los requisitos funcionales.

RF1 RF2 RF3 RF4 RF5 RF6 RF7

Esencial X X X X

Condicional X X

(16)

10

A continuación, en la tabla 2.3.4.2 se muestra la catalogación y la prioridad que tienen los requisitos no funcionales del sistema.

Tabla 2.3.4.2: Prioridad de los requisitos no funcionales.

RNF1 RNF2 RNF3 RNF4 RNF5 RNF6 RNF7

Esencial X X X X X X

Condicional X

Opcional

Para acabar, en las tablas 2.3.4.3 y 2.3.4.4 se muestran las relaciones entre los requerimientos funcionales y los requerimientos no funcionales con los objetivos del proyecto, respectivamente.

Tabla 2.3.4.3: Relación entre requisitos funcionales y objetivos.

RF1 RF2 RF3 RF4 RF5 RF6 RF7 Objetivo 1 X X X X X X X Objetivo 2 X X X X Objetivo 3 X X X X X X X Objetivo 4 X X Objetivo 5 X X X Objetivo 6 X X Objetivo 7 X Objetivo 8 X

Tabla 2.3.4.4: Relación entre requisitos no funcionales y objetivos.

RNF1 RNF2 RNF3 RNF4 RNF5 RNF6 RNF7 Objetivo 1 X X X X Objetivo 2 X Objetivo 3 X X Objetivo 4 X X X Objetivo 5 X X X X X Objetivo 6 X X X Objetivo 7 X X X X X Objetivo 8 X X X X

(17)

11

2.4.

Alternativas y selección de la solución

2.4.1.

Alternativa 1

La primera alternativa del proyecto consiste en adquirir un sistema gestor de contenidos gratuito, como por ejemplo JOOMLA. (http://www.joomlaspanish.org).

Joomla tiene las siguientes funcionalidades:

o Organización del sitio web.

o Publicación de contenidos.

o Administrador de plantillas.

o Administración de usuarios.

o Administrador de imágenes.

o Administración de navegación y menú.

o Gestor de módulos.

o Gestor de publicidad.

o Gestor de encuestas.

o Estadísticas de visitas.

Joomla es un sistema gestor de contenidos gratuito (coste 0€).

2.4.2.

Alternativa 2

La segunda alternativa trata de desarrollar toda la aplicación y el entorno web a medida de la entidad con las siguientes características:

o Es única.

o Cumple los requerimientos de la entidad.

o Se ajusta a los recursos disponibles de la entidad.

o Se pueden añadir diferentes funcionalidades.

(18)

12

2.4.3.

Solución propuesta

Primero comparamos las características de las alternativas citadas en el apartado anterior en la tabla 2.4.3.1.

Tabla 2.4.3.1: Comparación de características.

Alternativa 1 Alternativa 2 Costes de

adquisición 0 € 0 €

Costes de

adaptación Altos Medios

Nuevos recursos Adaptables Adaptables

Soporte Página web del producto Incluido

Nivel integración Bajo Bajo

Complejidad Baja Media

Formación Manual del producto. Manual de la aplicación y el entorno web En el cuadro comparativo de características vemos que se asemejan bastante las dos alternativas, pero parece que la alternativa 2 sería la más adecuada, ya que tiene menor coste de adaptación debido a que el proyecto se realiza especialmente para cubrir las necesidades de la entidad.

2.5.

Conclusiones

Para finalizar el estudio de viabilidad tenemos las siguientes conclusiones, que sirven para saber si el proyecto es viable o no.

Los beneficios que podemos obtener según el estudio son los siguientes:

o Reducción de gastos.

o Mejora de la gestión de los usuarios de la empresa.

o Mejora de la seguridad de la información.

o Mejora del control de los productos.

o Mejora de la organización del trabajo.

o Mejora del control de los horarios.

Y los inconvenientes que nos surgen en el proyecto son:

o Necesidad de un pequeño periodo de formación de los

(19)

13

3.

PLANIFICACIÓN DEL PROYECTO

3.1.

Introducción

La planificación del proyecto recoge el conjunto de actividades que permiten desarrollar y controlar las tareas y puntos de control, los recursos, el calendario, la evaluación de riesgos y el presupuesto del proyecto.

Permite tener un mayor control sobre todo lo relacionado con el proyecto.

3.1.1.

Descripción

Para llevar una buena planificación del proyecto utilizamos el programa Microsoft Project 2007.

3.1.2.

Definiciones, acrónimos y abreviaciones.

Las definiciones, acrónimos y abreviaciones utilizados que puedan causar algún tipo de confusión durante la planificación del proyecto son los siguientes:

1. Microsoft Project: programa de Microsoft utilizado para la gestión de proyectos.

2. WBS: “Work Breakdown Structure”.

3. “Milestone”: Punto de control.

4. Diagrama de Gantt: Cronograma del proyecto.

3.1.3.

Referencias

El proyecto debe seguir unas normativas y unos estándares:

1. Normativa de proyectos de ingeniería técnica:

http://www.uab.cat/Document/541/595/Normativa_PFCNovembre2010. pdf

2. Microsoft Project:

(20)

14

3.2.

WBS (“Work Breakdown Structure”)

En este apartado se determinan las fases y actividades, los recursos y los puntos de control seguidos durante el desarrollo del proyecto.

3.2.1.

Fases y actividades del proyecto

En la tabla 3.2.1.1 se muestran las fases y actividades que se producen a lo largo del desarrollo del proyecto.

Tabla 3.2.1.1: Fases y actividades del proyecto.

Fases Descripción

Iniciación Fase de iniciación. Incluye las actividades: definición del proyecto, asignación y matriculación.

Planificación Incluye el estudio de viabilidad y plan del proyecto.

Análisis Análisis de requisitos funcionales y no funcionales. Arquitectura del sistema. Diseño Incluye el diseño de la capa de datos, de control y de interfaz. Diseño de los test.

Desarrollo Fase de desarrollo de la aplicación.

Test i pruebas Fase de prueba del sistema. Incluye test unitarios y de integración.

Implementación La aplicación se instala en su entorno real. Incluye la formación de usuarios. Generación de

documentos Fase de documentación del proyecto. Incluye manuales y memoria del proyecto. Cierre del proyecto Fase de cierre. El director del proyecto firma la aceptación y cierre del proyecto. Defensa del

proyecto Defensa del proyecto delante de la comisión.

3.2.2.

Diagrama WBS

En la figura 3.2.2.1 se muestra el diagrama "Work Breakdown Structure" que indica las actividades de las fases del proyecto.

Figura 3.2.2.1: Diagrama del punto de control WBS. Proyecto Iniciación Definición Assignación Matricula Planificación Estudio Viabilidad Plan proyecto Análisis Diseño Análisis Diseño Desarrollo Desarrollo Tests Resultado Implementación Documentación Final Cierre Defensa

(21)

15

3.2.3.

“Milestones”

En este apartado indicamos los puntos de control del proyecto.

En la tabla 3.2.3.1 mostramos las descripciones con sus correspondientes fechas de las actividades del proyecto.

Tabla 3.2.3.1: Puntos de control.

Nombre Descripción Fecha

Iniciación Matriculación 10/10/2011

Estudio Viabilidad Aprobación 12/12/2011

Plan del proyecto Aprobación 12/12/2011

Análisis Aprobación 15/02/2012

Diseño Aprobación 27/02/2012

Cierre Aceptación 11/09/2012

Defensa Evaluación 19/09/2012

3.3.

Recursos del proyecto

3.3.1.

Recursos del proyecto

El desarrollo de la aplicación web necesitará cinco tipos de recursos humanos: el director del proyecto, el jefe de proyecto, el analista, el programador y el técnico en pruebas.

En la tabla 3.3.1.1 podemos observar los diferentes recursos humanos y su coste por horas.

Tabla 3.3.1.1: Recursos humanos

Recursos humanos Valoración

Director del proyecto 0 €/h

Jefe de proyecto 100 €/h

Analista 50 €/h

Programador 40 €/h

Técnico en pruebas 15 €/h

En este caso, el director del proyecto es el tutor que se encarga de evaluar el trabajo del alumno y el jefe de proyecto, analista, programador y técnico en pruebas son el estudiante que está realizando el proyecto.

Los recursos materiales que se utilizarán son los recursos disponibles en la entidad.

(22)

16

3.3.2.

Calendario de los recursos

Los recursos humanos forman parte en todo el proyecto:

o Jefe de proyecto: Iniciación, planificación, generación de

documentos, cierre y defensa.

o Analista: Análisis y diseño, implantación y puntos de control de

análisis, diseño y desarrollo.

o Programador: Diseño, desarrollo y test. Parcialmente en la

implantación.

o Técnico de pruebas: Fase de test.

Los recursos materiales se utilizarán principalmente en las fases de desarrollo, test e implantación.

3.4.

Calendario del proyecto

El proyecto se desarrollará desde Noviembre de 2011 hasta Junio de 2012 con una dedicación de 5 horas semanales. El total de horas dedicadas al proyecto será de unas 270 horas.

o Fecha comienzo: 23 de noviembre de 2011 o Fecha de finalización: 17 de junio de 2012

o Herramientas de planificación y control: Microsoft Project

(herramienta de seguimiento y control del desarrollo de proyectos de software).

3.4.1.

Dependencias

o Las fases de desarrollo se realizan en modo evolutivo para poder

añadir nuevas funcionalidades por parte del cliente.

o Cada fase no se empieza hasta que no se ha completado la

fase anterior.

o En la fase de desarrollo se prevé un modelo ágil de tal manera

que el diseño, el desarrollo y el test sigan un modelo iterativo.

o La fase de generación de documentos se prevé al final porque

incluirá los documentos elaborados durante el desarrollo del proyecto: inicio, estudio de viabilidad, plan de proyecto, etc.

(23)

17

3.4.2.

Cuadro de tareas del proyecto

En la figura 3.4.2.1 se muestra el cuadro de tareas del proyecto.

Figura 3.4.2.1: Cuadro de tareas.

3.4.3.

Calendario temporal

En la figura 3.4.3.1 se muestra el diagrama de Gantt del proyecto.

(24)

18

3.5.

Evaluación de riesgos

3.5.1.

Lista de riesgos

El desarrollo del proyecto puede presentar los siguientes riesgos a lo largo del tiempo:

1. Planificación temporal optimista: afecta al plan de proyecto, ya que no se acaba en la fecha prevista y aumentan los recursos con sus costes.

2. Cambio de requisitos: influye en el estudio de viabilidad y al análisis, ya que desencadena una demora en el desarrollo.

3. Equipo del proyecto demasiado reducido: afecta al plan de proyecto y provoca un retraso en la finalización del proyecto e incumplimientos de los objetivos.

4. Herramientas de desarrollo inadecuadas: puede influir en el desarrollo, ya que produce un retraso en la finalización del proyecto, y por tanto, provoca menos calidad.

5. No se realiza correctamente la fase de test: afecta al desarrollo ya la implantación provocando falta de calidad, deficiencias en la operativa, insatisfacción de usuarios y pérdida económica.

6. Incumplimiento de alguna norma, estándar o legislación: puede suceder en cualquier fase y pueden tener repercusiones legales.

7. Falta de adopción de medidas de seguridad: afecta al estudio de viabilidad, al análisis y al desarrollo, ya que puede causar pérdidas de información, incumplimiento legal y pérdidas económicas.

8. Abandono del proyecto antes de la finalización: se puede producir en cualquier fase del proyecto. Produce pérdidas económicas y una gran decepción por no poder realizar el trabajo esperado.

(25)

19

3.5.2.

Catalogación de riesgos

Una vez tenemos la lista de los riesgos que pueden surgir a lo largo del proyecto, los catalogamos en la tabla 3.5.2.1 en referencia a la probabilidad que tienen de surgir y el impacto que causan.

Tabla 3.5.2.1: Probabilidad e impacto de los riesgos.

Probabilidad Impacto Riesgo 1 Alta Crítico

Riesgo 2 Alta Marginal

Riesgo 3 Alta Crítico

Riesgo 4 Baja Crítico

Riesgo 5 Alta Crítico

Riesgo 6 Media Crítico

Riesgo 7 Alta Crítico

Riesgo 8 Media Catastrófico

3.5.3.

Plano de contingencia

Una vez tenemos catalogados los riesgos debemos planear qué soluciones habría que adoptar para estar preparados en el caso que se produzca alguno.

En la tabla 3.5.3.1 se muestra qué solución debería realizarse para cada uno de los riesgos.

Tabla 3.5.3.1: Soluciones en relación a los riesgos.

Solución que se debería adoptar

Riesgo 1 Revisar la planificación del proyecto y afrontar posibles pérdidas económicas. Riesgo 2 Revisar el estudio de viabilidad, renegociar con el cliente y modificar la planificación y el presupuesto. Riesgo 3 Mejorar la formación del equipo de trabajo, contratar más personal y prevenir herramientas alternativas. Riesgo 4 Buscar nuevas herramientas de desarrollo en el mercado para

conseguir una mejor calidad.

Riesgo 5 Modificar el diseño de test y pruebas, realizar test automáticos, negociar contrato de mantenimiento y afrontar pérdidas. Riesgo 6 Revisar las normas, los estándares y la legislación relacionados con el proyecto y consultar un experto. Riesgo 7 Revisar la seguridad aplicada en cada fase y aplicar nuevas políticas de seguridad. Riesgo 8 No tiene solución.

(26)

20

3.6.

Presupuesto

3.6.1.

Estimación coste de personal

En este apartado se hace una estimación aproximada de los costes de personal suponiendo que tengan un salario. Pero en este caso al ser un proyecto de final de carrera no habrá ningún salario, y por lo tanto el coste de personal será 0€/h.

Los supuestos costes de personal asignados en el proyecto se muestran en la tabla 3.6.1.1.

Tabla 3.6.1.1: Coste de personal.

Horas Coste Jefe del proyecto 86 h 8.600 €

Analista 63,9 h 3.195 €

Programador 66,1 h 2.644 €

Técnico en pruebas 42 h 630 €

Total 15.069 €

3.6.2.

Estimación coste de los recursos

En este apartado tenemos que tener en cuenta que el software utilizado para el desarrollo del proyecto se ha obtenido gratuitamente de la web de la compañía.

La amortización de los costes de los recursos propios del proyecto se muestra en la tabla 3.6.2.1.

Tabla 3.6.2.1: Coste de los recursos.

Coste

MS Project 0 € (Gratuito 24 meses)

PC programador 500 €

Servidor 6 €

3.6.3.

Resumen y análisis coste beneficio

Coste de desarrollo del proyecto...15.069 € Coste de amortización del material...506 €

Total: 15.575 €

El coste es muy elevado a causa de los salarios aplicados y por la cantidad de horas necesitadas, ya que serían de profesionales y no tardarían tanto tiempo en acabar el proyecto.

(27)

21

3.7.

Conclusiones

Para finalizar la planificación del proyecto tenemos las siguientes actividades que sirven para saber si se ha hecho un buen control del proyecto:

o Se han determinado las fases, actividades principales y puntos

de control del proyecto.

o Se han representado gráficamente utilizando un WBS.

o Se han valorado los recursos del proyecto.

o Se ha generado el calendario del proyecto incluyendo el

diagrama de Gantt con el Microsoft Project 2007.

o Se han evaluado los riesgos del proyecto y se ha preparado un

plan de contingencia.

o Es muy posible obtener beneficios en un futuro una vez haya

finalizado el proyecto.

o El presupuesto necesario para realizar el proyecto es mínimo.

Teniendo en cuenta estas conclusiones vemos que es un proyecto viable.

(28)

22

4.

RECURSOS UTILIZADOS

En este apartado describiremos los lenguajes de programación, herramientas y servidores utilizados para programar la aplicación del proyecto.

4.1.

Lenguajes de programación

En la actualidad existe una gran variedad de lenguajes de programación con los que se puede desarrollar el proyecto, pero la idea ha sido trabajar con lenguajes accesibles y sin coste económico. Se decidió trabajar con el lenguaje de programación PHP, que se utiliza para el desarrollo de aplicaciones web, pero aparte de PHP también son necesarios otros lenguajes para el desarrollo del entorno web.

Los lenguajes de programación utilizados son los siguientes:

- PHP: Es el acrónimo de “PHP Hypertext Pre-processor”. Es un lenguaje de programación interpretado, diseñado para la creación de páginas web dinámicas con acceso a información almacenada en una base de datos.

Se ejecuta para la interpretación del lado del servidor, por lo que el código escrito en PHP es invisible al navegador web y al cliente. Tiene capacidad de conexión con la mayoría de los motores de base de datos utilizados en la actualidad, y destaca su conectividad con “MySQL” (utilizado también en el desarrollo del proyecto).

- HTML: Es el acrónimo de “HyperText Markup Language (Lenguaje de marcado de hipertexto)”. Es un lenguaje de marcado para la elaboración de páginas web.

Se utiliza para describir y traducir la estructura y la información en forma de texto, como para complementar el texto con objetos como imágenes.

- JavaScript: Es un lenguaje de programación interpretado utilizado para la generación de contenido dinámico que interpreta y ejecuta el navegador web.

A diferencia de PHP, este lenguaje se ejecuta para la interpretación del lado del usuario.

(29)

23 - CSS: Es el acrónimo de “Cascading Style Sheets (Hojas de estilo en cascada)”. Es un lenguaje utilizado para definir la presentación de un documento estructurado generado por los lenguajes HTML. - AJAX: Es el acrónimo de “Asynchronous Javascript And XML

(JavaScript asíncrono y XML)”. Es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas, sin necesidad de recargarlas.

- SQL: Es el acrónimo de “Structured Query Language (Lenguaje de

consulta estructurado)”. Es un lenguaje que permite el acceso a bases de datos y que permite realizar diversos tipos de operaciones en ellas.

Una de sus características es que permite efectuar consultas para conseguir de forma sencilla información de bases de datos.

- UML: Es el acrónimo de “Unified Modeling Language (Lenguaje Unificado de Modelado)”. Es un lenguaje gráfico que permite visualizar, especificar, construir y documentar un sistema.

4.2.

Herramientas y servidores

Para el desarrollo del proyecto se ha utilizado un servidor Apache proporcionado por WAMP y el sistema gestor de base de datos MySQL. Para el desarrollo de la programación se ha utilizado el editor de código Notepad++.

El navegador web utilizado para probar la aplicación ha sido el Mozilla Firefox.

Y por último, la herramienta utilizada para la elaboración de esta memoria ha sido el programa Microsoft Office Word 2007.

- Apache: Es un servidor web HTTP de código abierto multiplataforma.

(30)

24

- WAMP: Es el acrónimo usado para describir un sistema de infraestructura de internet que usa las siguientes herramientas:

o Windows, como sistema operativo.

o Apache, como servidor web.

o MySQL, como gestor de bases de datos.

o Php, como lenguaje de programación.

- MySQL: Es un sistema de gestión de bases de datos que utiliza el lenguaje SQL.

- Notepad++: Es un editor de texto y de código fuente libre con soporte para varios lenguajes de programación. Únicamente funciona en Microsoft Windows.

Se parece al Bloc de notas, pero incluye opciones más avanzadas que pueden ser útiles para usuarios avanzados como desarrolladores y programadores.

- Mozilla Firefox: Es un navegador web libre y de código abierto. Es compatible con varios lenguajes, incluyendo los utilizados en el proyecto HTML, CSS y JavaScript.

- Microsoft Office Word 2007: Es un software destinado al procesamiento de textos.

(31)

25

5.

DISEÑO

Este apartado consiste en valorar la manera de crear el sistema para obtener un buen funcionamiento de la aplicación.

5.1.

Arquitectura del proyecto

La arquitectura del proyecto consiste en:

- Un ordenador cliente conectado a la red:

No importa qué sistema operativo tenga el ordenador, únicamente se necesita tener un navegador instalado y conexión a Internet para poder acceder al servidor dónde se encuentra la aplicación web.

- Un servidor web Apache y de base de datos MySQL.

El servidor es un ordenador que incluye el servidor de páginas web y la base de datos MySQL.

5.2.

Casos de uso

Los casos de uso son la descripción de los pasos o actividades que deberán realizarse para llevar a cabo el proyecto. Los usuarios de la aplicación que participan en los casos de uso se denominan actores.

5.2.1.

Crear salón

Descripción: Permite a los administradores crear salones para formar una cadena de peluquerías.

Actores: Administrador.

Flujo básico:

 El sistema valida los datos del salón.

 El sistema autoriza o no la creación del salón.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas: El administrador tiene que haber iniciado sesión en el sistema.

Post-Condiciones: Si el caso de uso se cumple con éxito, el salón habrá sido almacenado en el sistema.

(32)

26

5.2.2.

Eliminar salón

Descripción: Permite a los administradores eliminar salones del sistema.

Actores: Administrador.

Flujo básico:

 El sistema identifica el salón y lo elimina.

Condiciones previas: El salón tiene que estar almacenado en el sistema.

Post-Condiciones: Todos los trabajadores, clientes y productos relacionados con el salón eliminado también se eliminarán.

5.2.3.

Consultar productos

Descripción: Permite a los administradores consultar los productos de los salones con la opción de filtrar la búsqueda con el nombre del salón, el nombre del producto y el nombre del proveedor.

Actores: Administrador.

Flujo básico:

 El sistema realiza la consulta a la base de datos con las opciones

seleccionadas.

 El sistema muestra en una tabla todos los productos que reúnen

las características seleccionadas.

Flujos alternativos:

 Si no se ha seleccionado ninguna opción:

o El sistema muestra un mensaje de error.

 Si no se ha encontrado ningún producto con esas características:

o El sistema muestra un mensaje diciendo que no existe

ningún producto con esas opciones.

Condiciones previas:

 El administrador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un producto.

Post-Condiciones: Si el caso de uso se cumple con éxito, se mostrarán todos los productos que tienen las características seleccionadas.

5.2.4.

Crear trabajador

Descripción: Permite a los administradores crear trabajadores introduciendo sus datos (nombre, apellidos, teléfono, “login”, contraseña, sueldo, tipo de trabajador y el salón donde trabaja).

(33)

27

Flujo básico:

 El sistema valida los datos del trabajador.

 El sistema autoriza o no la creación del trabajador.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas:

 El administrador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, el trabajador habrá sido almacenado en el sistema.

5.2.5.

Eliminar trabajador

Descripción: Permite a los administradores eliminar trabajadores del sistema.

Actores: Administrador.

Flujo básico:

 El sistema identifica al trabajador y lo elimina.

Condiciones previas: El trabajador tiene que estar almacenado en el sistema.

Post-Condiciones: El trabajador no tendrá cuenta y no podrá iniciar sesión.

5.2.6.

Crear cliente

Descripción: Permite a administradores y trabajadores crear clientes introduciendo sus datos (nombre, apellidos, teléfono, “login”, contraseña y su salón habitual).

Actores: Administrador y trabajador.

Flujo básico:

 El sistema valida los datos del cliente.

 El sistema autoriza o no la creación del cliente.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas:

 Los actores tienen que haber iniciado sesión en el sistema.

(34)

28

Post-Condiciones: Si el caso de uso se cumple con éxito, el cliente habrá sido almacenado en el sistema.

5.2.7.

Eliminar cliente

Descripción: Permite a administradores y trabajadores eliminar clientes del sistema.

Actores: Administrador y trabajador.

Flujo básico:

 El sistema identifica el cliente y lo elimina.

Condiciones previas: El cliente tiene que estar almacenado en el sistema.

Post-Condiciones: El cliente no podrá acceder como cliente registrado en la aplicación web.

5.2.8.

Crear producto

Descripción: Permite a los administradores crear productos introduciendo sus datos (nombre, proveedor, precio de compra y de venta, el salón donde se encuentra, la cantidad actual y la mínima).

Actores: Administrador.

Flujo básico:

 El sistema valida los datos del producto.

 El sistema autoriza o no la creación del producto.

Flujos alternativos:

 Si se ha escogido la opción “Todos”:

o El producto se creará para todos los salones existentes.

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas:

 El administrador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

 Tiene que haber como mínimo un proveedor en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, el producto habrá sido almacenado en el sistema.

(35)

29

5.2.9.

Eliminar producto

Descripción: Permite a los administradores eliminar productos del sistema.

Actores: Administrador.

Flujo básico:

 El sistema identifica el producto y lo elimina.

Condiciones previas: El producto tiene que estar almacenado en el sistema.

Post-Condiciones: El producto no aparecerá en la lista.

5.2.10.

Crear proveedor

Descripción: Permite a los administradores crear proveedores.

Actores: Administrador.

Flujo básico:

 El sistema valida los datos del proveedor.

 El sistema autoriza o no la creación del proveedor.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas: El administrador tiene que haber iniciado sesión en el sistema.

Post-Condiciones: Si el caso de uso se cumple con éxito, el proveedor habrá sido almacenado en el sistema y ahora se podrán añadir productos con este proveedor.

5.2.11.

Eliminar proveedor

Descripción: Permite a los administradores eliminar proveedores del sistema.

Actores: Administrador.

Flujo básico:

 El sistema identifica el proveedor y lo elimina.

Condiciones previas: El proveedor tiene que estar almacenado en el sistema.

Post-Condiciones: El proveedor no aparecerá en la lista y no se podrán crear productos con ese proveedor.

(36)

30

5.2.12.

Gestionar economía

Descripción: Permite a los administradores consultar la gestión económica de los salones con la opción de filtrar la búsqueda con el nombre del salón, el mes y el año.

Actores: Administrador.

Flujo básico:

 El sistema realiza la consulta a la base de datos con las opciones

seleccionadas.

 El sistema muestra en una tabla todas las operaciones realizadas

que reúnen las características seleccionadas con sus respectivos importes.

 El sistema calcula el importe total de las operaciones.

Flujos alternativos:

 Si no se ha seleccionado ninguna opción:

o El sistema muestra un mensaje de error.

 Si no se ha encontrado ningún servicio:

o El sistema muestra un mensaje diciendo que no existe

ninguna operación con esas opciones.

Condiciones previas:

 El administrador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un servicio realizado.

Post-Condiciones: Si el caso de uso se cumple con éxito, se mostrarán todas las operaciones realizadas y sus respectivos importes.

5.2.13.

Actualizar stock productos

Descripción: Permite a los trabajadores actualizar la cantidad de productos que hay en la peluquería introduciendo el número de nuevos productos.

Actores: Trabajador.

Flujo básico:

 El sistema identifica el producto y pregunta la cantidad a añadir.

 El sistema recibe la cantidad de nuevos productos a incrementar.

 El sistema actualiza la cantidad actual del producto.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

(37)

31

Condiciones previas:

 El trabajador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

 Tiene que haber como mínimo un producto en la base de datos.

 Tiene que haber llegado el pedido a la peluquería.

Post-Condiciones: El sistema incrementará la cantidad actual de los productos en el salón.

5.2.14.

Procesar cobro de servicios

Descripción: Permite a los trabajadores procesar los cobros de los servicios realizados a los clientes marcando los servicios que se le ha realizado, los productos gastados y los productos que se le ha vendido.

Actores: Trabajador.

Flujo básico:

 El sistema verifica que los datos obligatorios estén seleccionados

(cliente, salón y servicio).

 El sistema calcula a tiempo real el precio total.

 El sistema calcula el dinero a devolver al cliente.

 El sistema resta los productos gastados y vendidos en la base de

datos.

Flujos alternativos:

 Si no se han introducido los datos correctamente o no se ha

seguido el proceso correcto:

o El sistema muestra un mensaje de error.

Condiciones previas:

 El trabajador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

 Tiene que haber como mínimo un cliente en la base de datos.

 Tiene que haber como mínimo un servicio en la base de datos.

 Tiene que haber como mínimo un producto en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, los productos gastados y vendidos se actualizarán.

5.2.15.

Crear cita (cliente)

Descripción: Permite a los clientes añadir citas en la agenda virtual introduciendo los datos (salón, servicio y fecha) y marcando una hora que esté libre. No podrá ver a quién pertenecen las horas ocupadas.

(38)

32

Actores: Cliente.

Flujo básico:

 El sistema muestra la agenda con las horas libres y ocupadas.

 El sistema valida los datos de la cita.

 El sistema autoriza o no la creación de la cita.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas:

 El cliente tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

 Tiene que haber como mínimo un cliente en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, la cita habrá sido almacenado en el sistema y la hora aparecerá como ocupada.

5.2.16.

Crear cita (trabajador)

Descripción: Permite a los trabajadores añadir citas en la agenda virtual introduciendo los datos (salón, servicio, cliente y fecha) y marcando una hora que esté libre. Puede ver los datos de todas las horas ocupadas.

Actores: Trabajador.

Flujo básico:

 El sistema muestra la agenda con las horas libres y ocupadas.

 El sistema valida los datos de la cita.

 El sistema autoriza o no la creación de la cita.

Flujos alternativos:

 Si no se han introducido los datos correctamente:

o El sistema muestra un mensaje de error.

Condiciones previas:

 El trabajador tiene que haber iniciado sesión en el sistema.

 Tiene que haber como mínimo un salón en la base de datos.

 Tiene que haber como mínimo un cliente en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, la cita habrá sido almacenado en el sistema y la hora aparecerá como ocupada.

(39)

33

5.2.17.

Eliminar cita

Descripción: Permite a los trabajadores eliminar citas de la agenda virtual, en el caso que el cliente lo pida. Esto está diseñado así para que los clientes no puedan eliminar las citas a última hora.

Actores: Trabajador.

Flujo básico:

 El sistema identifica la cita y la elimina.

Condiciones previas:

 El trabajador tiene que haber iniciado sesión en el sistema.

 La cita tiene que estar almacenada en la base de datos.

Post-Condiciones: Si el caso de uso se cumple con éxito, la cita habrá sido eliminada dejando libre esa hora.

5.3.

Interfaz de la aplicación web

La aplicación está desarrollada para que pueda acceder cualquier persona que tenga acceso a internet. Pueden acceder a la web como visitantes, clientes (registrándose en la web), trabajadores o administradores según la función que tengan en la entidad.

La estética de la web está diseñada para el salón de peluquería de mi madre, pero es fácilmente modificable, ya que está diseñada con hojas de estilo CSS.

Ahora explicaremos las funcionalidades más importantes a las que pueden acceder los usuarios utilizando capturas de pantalla de la web.

5.3.1.

Visitante

Cualquier persona con acceso a internet puede acceder a esta sección, en la cual puede visitar las siguientes funcionalidades:

- INICIO: Página principal para dar la bienvenida al visitante.

- SERVICIOS: Ofrece los servicios y precios disponibles en los salones. - REGISTRO: El visitante puede registrarse para convertirse en cliente. - CONTACTO: Muestra todos los salones con su dirección y teléfono. En la figura 5.3.1.1 mostramos el diseño de la página inicial del entorno web, a la cual tienen acceso todas las personas que deseen visitar la página.

(40)

34

Figura 5.3.1.1: Diseño de la página inicial.

El visitante puede registrarse en la aplicación rellenando el formulario de la sección “registro” mostrado en la figura 5.3.1.2.

(41)

35 El cliente escogerá su salón habitual para que los trabajadores tengan un acceso rápido a sus datos.

La aplicación avisará si hay algún error en el registro, como por ejemplo si el nombre de usuario escogido ya está utilizado por algún usuario de la web, ya que se realiza una validación de los datos por JavaScript y por PHP posteriormente.

El formulario de registro es solamente para los clientes, ya que el administrador es el que se encarga de registrar a los trabajadores (trabajadores y administradores) y a los clientes si ellos lo desean.

Al contrario que el formulario de registro, la entrada a la aplicación sí que es la misma para todos los usuarios de la web y se hace mediante un formulario compuesto por el campo “usuario” y el campo “contraseña”.

Para poder acceder al sistema el usuario tiene que introducir sus datos, si estos son incorrectos se mostrará un mensaje por pantalla.

La figura 5.3.1.3 muestra el formulario de acceso situado en la página inicial.

(42)

36

5.3.2.

Clientes

Los clientes que se han registrado tienen acceso al siguiente menú: - INICIO: Página principal para dar la bienvenida al cliente.

- SERVICIOS: Muestra todos los servicios y precios disponibles en los salones.

- CITA ONLINE: El cliente puede pedir cita en el salón de peluquería que desee.

- DATOS PERSONALES: El cliente puede modificar sus datos personales.

- CONTACTO: Muestra todos los salones con su dirección, teléfono y un enlace para poder ver en “Google Maps” su ubicación.

- SALIR: El cliente cierra la sesión.

En la figura 5.3.2.1 mostramos el diseño de la página inicial de los clientes registrados.

(43)

37 - CITA ONLINE

Al acceder a este apartado el cliente puede ver las citas que tiene programadas y programar una nueva cita en la agenda virtual de la web seleccionando la fecha, el salón, el servicio que quiere y la hora, siempre y cuando esté libre.

En la figura 5.3.2.2 podemos ver el diseño principal de “cita online”.

Figura 5.3.2.2: Cita online.

Para poder programar una cita primero debe escoger una fecha, un salón y pulsar el botón “Mostrar disponibilidad” para poder ver la agenda de ese día. En la agenda podrá ver las horas libres y ocupadas. El cliente solamente verá si las horas están libres u ocupadas, es decir, no podrá ver qué cliente tiene reservada esa hora ni qué servicio recibirá.

Cuando el cliente ha seleccionado el servicio o los servicios que desea (máximo dos servicios por cita, es decir, cada media hora) podrá programarlo a la hora que desee, siempre y cuando esa hora esté libre. En la figura 5.3.2.3 vemos el diseño de la agenda virtual del cliente.

(44)

38

5.3.3.

Administrador

En la página principal de la sesión de administrador hay una lista dónde el usuario puede ver las funcionalidades a las que tiene permiso, que son las siguientes:

- SALONES: Permite gestionar los salones y consultar sus productos. - TRABAJADORES: Permite gestionar todos los trabajadores de los

salones.

- CLIENTES: Permite gestionar todos los clientes de los salones.

- PRODUCTOS: Permite gestionar todos los productos de los salones. - PROVEEDORES: Permite la gestión de los proveedores.

- GESTIÓN ECONÓMICA: Permite consultar las operaciones realizadas en cualquier centro y sus importes.

- SALIR: El administrador cierra la sesión.

En la figura 5.3.3.1 mostramos la página de inicio de la sesión administrador.

(45)

39 - SALONES

En el apartado para gestionar los salones se muestra la lista de los salones almacenados en el sistema. El administrador puede añadir o eliminar salones en la base de datos. Hay que tener en cuenta que cuando se elimina un salón, se eliminará todo lo relacionado a este (trabajadores, clientes y productos).

También hay tres listas desplegables (salón, producto y proveedor) para poder filtrar la consulta de los productos y que el administrador pueda comprobar la disponibilidad que tienen en cada peluquería rápidamente. Esta parte del proyecto me ha costado muchas horas, ya que no encontraba la manera de realizarlo con AJAX para que se realizase la búsqueda de forma dinámica.

En la figura 5.3.3.2 y 5.3.3.3 podemos ver el diseño para gestionar salones y para buscar los productos en las peluquerías respectivamente.

Figura 5.3.3.2: Gestión de salones

(46)

40

- TRABAJADORES

En la opción para la gestión de trabajadores el administrador puede ver la lista de todos los trabajadores que forman parte de esta cadena de peluquerías. Tiene permisos para poder añadir y eliminar trabajadores. En la figura 5.3.3.4 podemos ver el diseño.

Figura 5.3.3.4: Gestión de trabajadores.

- CLIENTES

En el apartado para gestionar los clientes de los salones hay una lista con todos los clientes y sus correspondientes datos. El administrador, como en la gestión de los trabajadores, puede añadir y eliminar clientes. En la figura 5.3.3.5 vemos el diseño de este apartado.

(47)

41 El sistema muestra un mensaje de información si el administrador introduce algún dato incorrecto, si el trabajador o el cliente ya están creados en la base de datos o si se deja algún campo vacío del formulario.

- PRODUCTOS

El apartado “productos” permite gestionar los productos de todos los salones mostrando una lista con todos los datos almacenados en el sistema. El administrador puede añadir y eliminar productos.

Los productos están ordenados por el nombre del producto y el proveedor para tener un mejor control.

La lista desplegable “salón” permite escoger la opción “todos” para poder añadir un producto a todos los salones de la cadena. Esto es útil para que cuando el administrador de la empresa haga un pedido para todos los salones le sea fácil de insertar en el sistema.

Antes de poder añadir productos al sistema tenemos que haber introducido proveedores para poder indicar a qué proveedor pertenece cada producto.

La figura 5.3.3.6 muestra el apartado para la gestión de los productos.

Figura 5.3.3.6: Gestión de productos.

- PROVEEDORES

En la opción del menú para gestionar proveedores, el administrador puede añadir y eliminar los proveedores de los productos que se utilizan en la cadena de peluquerías.

(48)

42

En la figura 5.3.3.7 vemos el diseño de este apartado.

Figura 5.3.3.7: Gestión de proveedores.

- GESTIÓN ECONÓMICA

Por último, el administrador puede consultar la gestión económica de los salones, es decir, puede ver toda la información de todos los servicios realizados en cada salón. Esto lo puede realizar utilizando una búsqueda mediante los filtros salón, mes y año.

Por ejemplo, el administrador puede escoger la peluquería Angelita, en el mes Septiembre y el año 2012 y verá en una tabla todos los datos de los servicios realizados que tengan esas características. Al final de la tabla se calcula el total de los importes.

En la figura 5.3.3.8 podemos ver el diseño para poder consultar la gestión económica.

Referencias

Outline

Documento similar

El objetivo del proyecto es el desarrollo de una aplicación web respaldada por una base de datos con la capacidad de gestionar los diferentes usuarios, clientes y presupuestos que

En este sentido, puede defenderse que, si la Administración está habilitada normativamente para actuar en una determinada materia mediante actuaciones formales, ejerciendo

Se propone desarrollar una aplicación que permita Gestionar los AP en Cuba y para ello controle los servicios de Certificación y Cancelación de AP y mantenga actualizada la

El Sistema para la administración centralizada de dispositivos brinda una interfaz visual en forma de aplicación web que permite al usuario gestionar cada uno

En este proyecto se ha unificado el desarrollo de aplicaciones para dispositivos móviles S40 de Nokia con la tecnología NFC, dando como resultado la aplicación “Smart-Info UPCT”,

Como se puede ver en la sección de descripción del problema los mayores inconvenientes son poder elegir una plantilla diferente sin tener que rehacer el curriculum y tener

 Para recibir todos los números de referencia en un solo correo electrónico, es necesario que las solicitudes estén cumplimentadas y sean todos los datos válidos, incluido el

Este trabajo sigue la dinámica de RUP basada en fases y flujos de trabajo, lo que permitió obtener una aplicación web con una interfaz amigable para el